worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ https://discourse.nixos.org/t/nixos-20-09-release/9668 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.09 RMs: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
rajivr has joined #nixos-dev
supersandro2000 has quit [Ping timeout: 246 seconds]
supersandro2000 has joined #nixos-dev
tilpner_ has joined #nixos-dev
supersandro2000 has quit [Quit: The Lounge - https://thelounge.chat]
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
supersandro2000 has joined #nixos-dev
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #nixos-dev
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
ajs124 has joined #nixos-dev
srk has quit [Ping timeout: 240 seconds]
srk has joined #nixos-dev
supersandro2000 has quit [Read error: Connection reset by peer]
supersandro2000 has joined #nixos-dev
supersandro2000 has quit [Read error: Connection reset by peer]
supersandro2000 has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
jonringer has quit [Ping timeout: 260 seconds]
<siraben> Is the release schedule changing in 2021?
<supersandro2000> 21.05 is a thing
<siraben> but the branch names are still 21.03?
<samueldr> which branch? :)
<siraben> Also recently noticed Nixpkgs has overtaken AUR has largest repo, great job everyone! https://repology.org/repositories/statistics/total
<samueldr> I'm guessing it's the version unstable shows you're thinking of?
<siraben> Oops not branch, but the unstable manual says 21.03
<samueldr> yeah
<samueldr> I figure no one got to it
<siraben> I lost the link to the discourse thread where they discussed this, what was the reason for the 2 month shift?
<samueldr> it was an RFC PR
<samueldr> yes, it matches better with display environments' own release schedules
<siraben> so now releasing on month 5 and 11?
<siraben> I see
<{^_^}> rfcs#80 (by jonringer, 4 weeks ago, merged): [RFC 0080] Change NixOS releases to YY.05,YY.11
orivej has joined #nixos-dev
<supersandro2000> siraben: I hope not
<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
<lovesegfault> anyone know what's up with hydra? https://hydra.nixos.org/build/134042321
<lovesegfault> cc. gchristensen andi- flokli
<flokli> lovesegfault: that's pointing to an IP of packet
<andi-> We might have lost a builder?
<flokli> I assume the host has been reclaimed, but hydra still has it in its builder list
<flokli> kicked off a new eval
<flokli> too bad hydra just aborts it in such a case
<flokli> lovesegfault: PRs welcome I guess ;-)
<lovesegfault> yeah, that's interesting
<lovesegfault> PRs to hydra?
<supersandro2000> I would guess infra
<samueldr> andi-: flokli: things seem weird, I haven't seen an x86_64-linux build succeed with packet machines, all with the scary error message
<andi-> Hydra could need some love. There are a few interesting PRs open: https://github.com/NixOS/hydra/pulls
<samueldr> since maybe 24 hours ago
<samueldr> doesn't look like the usual reclaimed hosts
<samueldr> (I didn't pipe up earlier because I assumed it'd eventually fix itself)
<andi-> the hosts probably are the same as shown here? https://monitoring.nixos.org/grafana/d/LWthnsPmz/hydra-builders?orgId=1
<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
<{^_^}> https://github.com/NixOS/nixpkgs/pull/108235 (by SuperSandro2000, 1 minute ago, open): Combined nodePackages update and init
rajivr has quit [Quit: Connection closed for inactivity]
thibm has quit [Quit: WeeChat 2.6]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
jonringer has joined #nixos-dev
andi- has quit [Quit: WeeChat 2.8]
andi- has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<yorick> LnL: could you take a look at https://github.com/NixOS/nixpkgs/pull/107394 ?
<{^_^}> #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).
<hexa-> supersandro2000: also could you retry the solanum pr on darwin? https://github.com/NixOS/nixpkgs/pull/108164
<{^_^}> #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-> andi-++
<supersandro2000> solanum does wird things in their logs... https://termbin.com/s2a0
<{^_^}> andi-'s karma got increased to 54
<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
<symphorien[m]> MichaelRaskin iirc
<ekleog> MichaelRaskin's?
<{^_^}> #36842 (by 7c6f434c, 2 years ago, closed): [RFC] nixpkgs/tests: create nixos-independent PoC tests
<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)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/36842 (by 7c6f434c, 2 years ago, closed): [RFC] nixpkgs/tests: create nixos-independent PoC tests
<abathur> I suppose there could be designated canaries, but picking the right ones will be mostly luck unless you know all of the choices very well
<abathur> could pick canaries by some stat like download volume or whatever
<abathur> raise a red flag if more than x% of cache requests that depend on this derivation would be broken
<ekleog> do we have any public stats on the cache request hits? it'd most likely be useful indeed
<abathur> (I'm not aware, just blue-skying :)
cole-h has joined #nixos-dev
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
__monty__ has quit [Quit: leaving]
yorick has quit [Quit: reboot]
yorick has joined #nixos-dev
v0|d has joined #nixos-dev
pmy has quit [Ping timeout: 272 seconds]
pmy has joined #nixos-dev
<jtojnar> symphorien: it is possible to patch GTK with path to the schema to avoid the crash
orivej has quit [Ping timeout: 260 seconds]
<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` ?