<luc65r>
I'm tring to build my system with gcc10 and binutils 2.34: https://github.com/NixOS/nixpkgs/pull/89793. That broke systemd too. Most of the services (like journal or udev) fail with code 127. I can launch them manually without any problem. I tried to build systemd with gcc9 and gcc10, and it seems to be related to binutils-2.34. Does anyone have an
<luc65r>
idea of what could have gone wrong?
<{^_^}>
#89793 (by luc65r, 4 days ago, open): Bump gcc to gcc10 and binutils to 2.34
q3k has joined #nixos-dev
orivej has joined #nixos-dev
<luc65r>
flokli you are a maintainer of the systemd package, maybe you can help me to troubleshout this?
tilpner has quit [Quit: tilpner]
_ris has joined #nixos-dev
ris has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
evils has quit [Quit: Lost terminal]
evils has joined #nixos-dev
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<rnhmjoj>
i'm removing a broken node package, should i also edit the autogenerated set?
__monty__ has joined #nixos-dev
<flokli>
luc65r: sorry, I gave up on the binutils bumping efforts. I can't really tell why systemd is crashing when bumping it.
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
luc65r has joined #nixos-dev
luc65r has quit [Ping timeout: 264 seconds]
zarel has quit [Ping timeout: 256 seconds]
zarel has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
luc65r has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
zarel has quit [Ping timeout: 264 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
luc65r has quit [Read error: Connection reset by peer]
luc65r has joined #nixos-dev
luc65r has quit [Read error: Connection reset by peer]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
luc65r has joined #nixos-dev
<Valodim>
nix seems to know the unpacked size of substituted derivations before an operation. is there any reason not to error out when the nix store device doesn't have enough free space?
<gchristensen>
my Nix store is a bag of holding and can store more bytes than Nix thinks
<Profpatsch>
Had the same problem yesterday with a nixos-install with just 1GB of memory
<Profpatsch>
Would be nice if nix could display a warning if `df -h` shows less space remaining than it expects operation to use
<Valodim>
device of holding seems like the special case, where nix could be asked (via argument or config) to skip the check
orivej has quit [Ping timeout: 246 seconds]
luc65r has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
luc65r has joined #nixos-dev
luc65r has quit [Read error: Connection reset by peer]
luc65r has joined #nixos-dev
drakonis has joined #nixos-dev
luc65r has quit [Read error: Connection reset by peer]
luc65r has joined #nixos-dev
drakonis1 has quit [Ping timeout: 264 seconds]
luc65r has quit [Client Quit]
<Profpatsch>
oh, that was a D&D joke
drakonis has quit [Ping timeout: 272 seconds]
drakonis_ has joined #nixos-dev
<gchristensen>
Valodim: it isn't so special anymore, lots of filesystems are doing transparent compression
<gchristensen>
and free space checks are notorious for going wrong, like I think vbox refused to install if you didn't have enough space because you had too much space
<gchristensen>
but a warning seems useful
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
cole-h has joined #nixos-dev
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
ris has joined #nixos-dev
_ris has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-dev
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
<FRidh>
hydra macs are idle despite a long queue :(
<FRidh>
8 and 9 that i
<FRidh>
s
<cole-h>
How can you tell? (asking for future reference)
<LnL>
the queue runner info indicates mac1 and mac9 are blacklisted
<LnL>
the rest are building stuff
orivej has quit [Quit: No Ping reply in 180 seconds.]
<LnL>
FRidh: do I make a pr or push straight to staging-next?
<abathur>
Hoping to get a better handle on how/why something does/doesn't work. Earlier this year I noticed tintin wouldn't build on macOS. Hoped it was a transient unstable issue but still get an error. Looks like it's failed on hydra since late January (https://hydra.nixos.org/build/121877653) with the same error I see. PRs for last 3 version bumps have a gray darwin check noting the same failure, and
<abathur>
the previous PR in November has a green one.
<abathur>
I think I recall graham complaining about the overall green check showing up even when there were gray individual checks, so I assume that's the narrow answer as to how they got merged despite the failure, but I don't know/recall why the checks are gray in the first place?
<FRidh>
LnL: straight to staging-next if its darwin-only
orivej has quit [Quit: No Ping reply in 180 seconds.]
<LnL>
abathur: main issue to make the checks more visible currently I'd say is detection regressions
orivej has joined #nixos-dev
<FRidh>
LnL: thanks!
tv has quit [Ping timeout: 246 seconds]
<LnL>
with large rebuilds, especially things like clang updates, it's also not really feasible to track all regressions
tv1 has joined #nixos-dev
<abathur>
LnL guessing that unpacks to roughly: these check are gray because too many of this kind of check fail for it to be feasible to make them blockers for now? But that regressions could be blockers, if something was able to spot them?
<FRidh>
abathur: that's maybe the narrow and optimistic answer. I merge certain PR's as well even though the darwin build fails, simply because the bus factor for darwin is so much lower. If it is problematic for someone, someone will fix it up. Of course with core packages it is a different story.
<LnL>
"bus factor for darwin is so much lower"?
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-dev
justanotheruser has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<FRidh>
much fewer people capable and willing to test/fix PR's
<LnL>
ah in that way
<FRidh>
it would be good if we had, just like with the architectures, support levels for packages. That way CI could suggest how to proceed (e.g., require a fix, or permit a failure)
<LnL>
yeah
<timokau[m]>
FRidh: I think it would be great if *maintainers* could specify their intended support level. That would then imply a support level for the package (highest support level of a maintainer).
<abathur>
<3 timokau[m]
<{^_^}>
timokau[m]'s karma got increased to 1
<LnL>
abathur: also graham's point, which I agree with, was that unless the current checks become blocks it's important not to show failures for cases that are not necessarily an issue
<LnL>
currently a failure means something is definitively wrong, polluting that with intermittent/incorrect stuff means nobody will pay attention to them anymore (which was the case back with travis)
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
<LnL>
builds are a much harder thing to get this right for compared to evaluation
orivej has joined #nixos-dev
alp has joined #nixos-dev
<abathur>
I guess it feels like one more thing that could be (a little? a lot?) better with more metadata/context available in the right places
<FRidh>
timokau[m]: good idea as well. How would one deal with "core" packages that have no maintainers? Would they "inherit" maintainers from reverse dependencies?
<abathur>
for example, I'd gladly opt into a few extra seconds during rebuild if it got me a notification that a package my system depends on has been failing in master for <duration>
<abathur>
because it'd be a lot nicer to find out early, have a chance to help out before it becomes a problem, and avoid finding out about it after I update my channel and try to rebuild for <some unrelated important reason>
zarel has joined #nixos-dev
dongcarl has quit [Ping timeout: 256 seconds]
<abathur>
all the more so if anonymous stats on recent status checks (or maybe just cache hits? or both?) for packages were highly-visible to reviewers trying to decide whether to merge with a break or not
<timokau[m]>
FRidh: That's a good question. I like your idea, signing up for core maintainership could mean that you fix issues with unmaintained reverse deps as well
<timokau[m]>
For example we could have the tiers "responsive" and "self-use". "responsive" means that you're signing up for failure notifications and will usually try to respond within ~a week. "self-use" could mean you're using it and sharing it, but do not plan to support other people's use cases.
<FRidh>
timokau[m]: I meant it the other way around
<FRidh>
if you depend on something you should be willing to maintain that as well
<timokau[m]>
Yes, that's what I meant (but not what I said)
<FRidh>
ok good :)
<abathur>
FRidh it would, at minimum, be good to be able to make the status visible to maintainers, even links down the chain
<timokau[m]>
Then for something to be truly core, it should have >1 "responsive" maintainer. We may not actually have the manpower for that though
<abathur>
I'm not sure transitive maintainership is always meaningful, but if it meant the right thing and worked the right way it could be good
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<abathur>
i.e., I wouldn't mind adding myself as a maintainer of tintin since I use it, if I can figure out why it's broken, but I know nothing about zlib, a maintainerless package it depends on; I'd certainly be willing to poke at a problem in zlib if it was causing trouble with tintin, but I'd simultaneously be very uncomfortable mucking with something I see over 1k .nix files match in the repo
<timokau[m]>
Following my suggestion in the discourse thread I linked, you could do that because all reverse dependency maintainers would be pinged on build breakage
<timokau[m]>
In my view. the "unstable" in nixos-unstbale means that we should run automatic tests, but not necessarily manual ones. That's what people expect for example from the unstable branch of arch linux
<timokau[m]>
So only pinging reverse maintainers on build breakage should be fine. Any other issues would be discovered at runtime, that's why its unstable
<abathur>
that's roughly in the space of what I mean by visibility vs. notification, but it probably just hinges on implementation; something that popular would presumably need, and get, higher-quality attention so it'd be noisy for hundreds of people to get pinged off the bat
<abathur>
I'd react positively to close-proximity (build time, use time? pre channel update?) visibility that <chain of things I depend on> is broken in a way that doesn't seem to be transient; harder to say how blanket notification-on-break would go (but, on the other hand, I think I'd react positively to a way for visibility to escalate to a notification at some threshold?)
<samueldr>
I believe reverse dependencies maintainers ended up transitively pinged on failures
<samueldr>
and that's how hydra pinged everyone
<samueldr>
and the reason why it (still) doesn't send e-mail AFAIK
<eyJhb>
Wondering, are there any apparent objections to adding a preCommands and postCommands to initrd.luks.devices? Useful if the key is on a ZFS dataset, that needs to be mounted before the LUKS volume can
<ajs124>
probably not, except that we should ideally try to get something like #74842 in eventually.