<supersandro2000>
siraben: we just included all packages. nixpkgs surpassed it a while ago
<siraben>
supersandro2000: why not?
<siraben>
ah
<supersandro2000>
we didn't recurse into some things
<siraben>
how did Nix grow so much faster than AUR?
<supersandro2000>
we have entire hackage, a lot of python packages, darwin and linux things
<supersandro2000>
also servers and website only packages which are probably a small part
<supersandro2000>
lots of games
<ehmry>
would be nice to collect a list of the games somewhere. or move them to a flake
<samueldr>
how come?
jonringer has joined #nixos-dev
<andi->
what is the equivalent of nix-env -qa --json with flakes? I only seem to get the flakes (nixpkgs) metadata when I run nix flake info but not the list of packages.
<andi->
Ugh, nix flake show --legacy is pretty close but just missing the JSON :/
<ehmry>
samueldr: just to make them easier to browse, and none of the games should be dependencies of non-games
<elvishjerricco>
siraben: Yea nixpkgs has a lot of automated package definitions that aren't curated or tested. It's pretty useful but it does unfairly skew package counts in NixOS's favor.
<andi->
We are missing categories/tags for packages in nixpkgs. The directory structure has that but we are throwing it away the moment we import it into all-packages.nix
<samueldr>
I restarted the aborted jobs a couple of times
<samueldr>
there's a selection of hosts, and AFAICT some (or all?) are not in your link
<samueldr>
oh, sorry
<samueldr>
some are, I didn't scroll
<samueldr>
I guess all are... it's sign it's time I get to bed
<andi->
Nah, I just had breakfast ;)
page has quit [Ping timeout: 265 seconds]
jonringer has quit [Ping timeout: 260 seconds]
AlwaysLivid has joined #nixos-dev
page has joined #nixos-dev
__monty__ has joined #nixos-dev
<gchristensen>
andi-: is there a problem to look at or are we ok?
<ekleog>
timokau[m]: a thought just came to me: a place where marvin might make sense to advertise might be the “PRs ready for review _” discourse thread… but knowing it's still alpha, I'm wary of advertising it anywhere public for now to avoid putting undue load on you, so… what do you think? :)
<andi->
gchristensen: it sounded a like an awful lot of SSH connect errors. Maybe worth investigating at least one machine.
greaka has joined #nixos-dev
thibm has joined #nixos-dev
cole-h has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
cole-h has quit [Ping timeout: 256 seconds]
Cadey is now known as Guest57365
Guest57365 has quit [Killed (egan.freenode.net (Nickname regained by services))]
<supersandro2000>
Please do not merge any nodePackages updates until #108235 is done
<{^_^}>
#107394 (by yorickvP, 1 week ago, open): beam-packages: move wxSupport arg up to package set, add beam_nox
jonringer has quit [Remote host closed the connection]
Baughn has quit [Ping timeout: 240 seconds]
Baughn has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<andi->
supersandro2000: regarding failing builds with nixpkgs-review vs ofBorg: For most of the comments where someone states that it doesn't build on darwin there is no log.. I prefer the situation with ofBorg where there is *always* a log of a build (carried over from #nixos-chat).
<{^_^}>
#108164 (by mweinelt, 1 day ago, open): solanum: init at unstable-2020-12-14
<lassulus>
wouldn't it be cool, if the tooling for ofborg and nixpkgs-review would be the same? maybe with an option to not build all dependant packages for ofborg?
<hexa->
or if we had darwin builders
<supersandro2000>
andi-: fair enough. Missing log is still a problem I try to solve. I could just put them on gist or termbin or something
<abathur>
gh comments accept attachments, not sure if there are asterisks that would make it unsuitable
<supersandro2000>
hexa-: running
<supersandro2000>
lassulus: then I would need to learn rust...
<hexa->
supersandro2000: thanks
<hexa->
supersandro2000: yeah, that last log was glitching the rendering in my firefox, gist or termbin would be preferable
<hexa->
termbin is lovely
<supersandro2000>
hexa-: I tried adding one but the service failed for me with various errors and then the internet and power connection of the server was flaky and I have up
<supersandro2000>
hexa-: that was not your browser but I had color escape codes in it and coping from my terminal mangels new lines and replaced them with spaces...
<supersandro2000>
termbin has one problem: it does not store the logs forever
<hexa->
yeah, that sounds like it :)
<hexa->
forever is a big ask anyway
<abathur>
said generally, with no sense of how: I think there's value in being able to easily (small downside/barriers) experiment with automation improvements in a way that won't disrupt the "live" triage pipeline, but also having a clear path for folding productive experiments into the existing tools
<hexa->
and we don't care about those guarantees anyway, being on the free tier of github and all of that :)
<supersandro2000>
forever like the next years instead only the next month
<andi->
abathur++
<{^_^}>
abathur's karma got increased to 10
<andi->
termbin is also racy
<lassulus>
supersandro2000: or ofborg just runs nixpkgs-review?
<supersandro2000>
also if andi- does not like the reports I can add a blacklist
<andi->
you can upload two files to the same name and only realize afterwars
<hexa->
having the build log of a failed bin on (not linux-x86_64)
<hexa->
is the best case scenario for getting things fixed
<supersandro2000>
I'll try to realize that this evening. Thansk for the feedback.
<andi->
supersandro2000: my problem is more that it gives a false sense of "working" to whoever might look at the results. I generally believe that a review should not be just building everything. It should involve scrutinizing the PR and questioning whatever has been done in a reasonable way. I do not have numbers but I fear we are very strong on the building side and weak on the "testing"/scrutinizing
<andi->
part.
<andi->
If I do not have knowledge of a package I can hardly review it. I an build it but how do you know if it is good?
<hexa->
supersandro2000: probbaly some fancy test suite render
<supersandro2000>
yeah
<hexa->
guess I'll disable the test phase on darwin if you have no other ideas
<supersandro2000>
about the testing I am not sure how we want to do this without slowing down PRs merging by a lot
<supersandro2000>
hexa-: would be fine for me
<andi->
Why do we have to be fast?
<andi->
If neither the contributor nor the review can review it/can provide instructions: Why do we care about it at all?
<andi->
Perhaps packages where nobody knows how to test it should be removed instead of rotting/being carried around in unknown state.
<supersandro2000>
people are already frustrated if there PR sits there for months
<supersandro2000>
if we have such packages that are broken and no one knows how to get it working and it is basically a Karteileiche then we should remove it
<supersandro2000>
but how do we find such packages?
<supersandro2000>
no idea
<symphorien[m]>
maybe there should be two levels of maintainership: "I know how to write a nix expression that builds it" and "I know how to test it (I wrote the package request)"
<abathur>
I guess the ideal case is that everything comes with not-entirely-trivial tests, though I don't really understand the set well enough
<abathur>
are the problem packages things with no tests of their own, or with suites that have to be disabled for some reason?
<abathur>
or are the problems packages that are passing their tests in build-env, but with some sort of packaging problem that renders them useless as you'd actually consume them in the wild?
<abathur>
I assume the real answer is "yes" :D
<supersandro2000>
abathur: for python packages tests are sometimes not shipped with pypi. Github has those usually. Imports check is better than nothing for the rest.
<supersandro2000>
probably we need something similar for other eco systems
<energizer>
for executables `foo --help` is a good first test
<abathur>
I think I've wished aloud on discourse, with little sense of how it could work, but with a sense that the community could be a lever on that sort of thing, for some sort of [nudge, toolchain, and capture system] that we can use to provide ~regular non-drastic pressure towards better testing
<abathur>
i.e., someone builds a package that is below the arbitrary (global? per package?) well-tested threshold, they get a nudge asking if they can submit a nontrivial usage example, with a tool for capturing it and shipping it off
<energizer>
a standard file indicating how to run tests would be nice
<abathur>
I don't know if that can be sophisticated enough to tell the difference between someone running nix-shell -p randompackage, and someone running nix-shell in a local directory that has a shell.nix defining their web app or phd project or whatever; if so, some nudges could be much more contextual
<ekleog>
Random idea: what about adding `meta.tests.runs = runCommand "check" "${self}/bin/foo --help | grep ${version}";` to packages?
<ekleog>
uh passthru.tests actually, forgot about the rename again
<ekleog>
energizer: actually I had missed your message, that's the idea of passthru.tests (but it's only for tests that can be run automatically, having a readme file might make sense for packages that need GUI or the like, but IMO such documentation should just be placed in a comment just besides the sha256 so we never forget it when it's set)
<symphorien[m]>
someone had proposed automated but non vm test for gui apps
<abathur>
a little old-fashioned bureaucrac/red tape could maybe work for guis... i.e., attach a screenshot to your review comment of a specific view on every package rev
<abathur>
not sure how often they're too broken to open, but if regularly just making sure a monkey proves they opened it should be a good marginal improvement
<ekleog>
I wonder what we actually get that's broken in practice… guess we could see how we get broken things by looking at PRs that fix things
<symphorien[m]>
proving that the file chooser opens without crash because a gtk schema is missing would be valuable
<ekleog>
though that would also catch cases where updating a dependency breaks a GUI software, and IMO such cases we should just ignore because it's a very hard to solve by process alone (apart from by eg. adding some passthru.tests = someReverseDependency.passthru.tests to lib derivations)
<supersandro2000>
symphorien[m]: can't we test this another way? e.g. loading some dummy program with the same enviroment? or something?
<symphorien[m]>
given that each program loads schemas differently, I doubt that
<ekleog>
Hmmmmm I wonder how easy or hard it'd be to port MichaelRaskin's test framework to NixOS tests, with the aim of making it easy to write tests — for this discussion I'm thinking speed of running the test doesn't matter, the mere fact that it'd be there in passthru.tests to be auto-tested by ofborg/r-ryantm/nixpkgs-review would be enough (well… so long as it doesn't take 3 hours to run), and
<ekleog>
while I very much like non-VM tests I believe it'd be much easier to get a NixOS-ified version of those tests to land
<abathur>
if it's a leaf-node package that isn't directly exercised by anything in nixpkgs, it'd be nice to collect an external ~integration test; if it's a branch node that is used all over the place, it would be both good to know if the update built but broke 80% of consumers, but also probably a shrug if it broke 1% (aside perhaps from auto-marking it broken and auto-opening a fix issue?)
<ekleog>
(well, either that or try to put #36842 through the RFC process and hope a lot)
<symphorien[m]>
my point was mainly that sometimes the packager forgot to do these extra steps
<symphorien[m]>
for example, I use xfce-terminal and when I lauch a gui app from xfce-terminal the app inherits the wrapper of xfce-terminal, and it does not crash
<symphorien[m]>
only later, when I run the same app with the desktop file do I realize it crashes on File>Open
<symphorien[m]>
Jan Tojnar do you think it would be reasonable to generate such patch with coccinelle at build time automatically ?
<symphorien[m]>
with some `coccinelleSchemaPatchHook` ?