<ekleog>
delroth: the new failures from the eval you link here appear to come from valgrind that stopped building, likely due to a transient error in the builders, given https://hydra.nixos.org/build/83331959 (-> would need someone to restart the job… srhb?). What's weird is that the merge from staging to unstable appears not to have been done in this evaluation, so the jobs should have failed earlier when
<ekleog>
staging has been merged. OTOH, in the “Still failing jobs” pane, nixos.tests.ipv6.x86_64-linux appear to have already failed, so I guess hydra just gave up before running and failing the whole test suite
<delroth>
the ipv6 test has been failing for unrelated reasons in master for a week now
<delroth>
all the other failures are new to this eval.
<delroth>
(the fix for the ipv6 test is in staging-next)
<ekleog>
if you click on the job name you'll see both are propagated failures of valgrind, at least according to hydra
<delroth>
ok, so you're saying that it just reused a cached failure from a month ago and gave up basically?
<ekleog>
yup
<delroth>
in any case, that revert commit I linked to is causing tons of rebuilds
<delroth>
shouldn't it have gone into staging?
<pbogdan>
yeah, that commit seems to rebuild the world
<delroth>
also ekleog I just reproduced that valgrind failure locally
<delroth>
HEAD at 7eeb02d47b388ac4f66f4b77cddffa409042a8d8, nix-build nixos/tests/login.nix, fails in the exact same way as on hydra
<delroth>
(on nixos)
<ekleog>
delroth: ugh :( hoped a retrigger would be enough, given the error messages for packet-t2-4 (so unping srhb)
<ekleog>
(currently trying to reproduce your gnutls build failure locally)
<delroth>
guess: I think the gnutls issue might be a red herring caused by it having always been broken on !nixos linux + rebuild triggered
<delroth>
I haven't been able to reproduce the failure on nixos but it fails on !nixos linux
<ekleog>
delroth: now, you say the ipv6 test has been fixed in staging-next, so hopefully the fix for the other tests (and valgrind) would be the same and present in staging-next too
<delroth>
I fixed the ipv6 test, it has nothing to do with this.
<ekleog>
as for gnutls, I've been able to reproduce the failure locally on nixos on 7eeb02d47b388ac4f66f4b77cddffa409042a8d8, currently I'm doing a --check in HEAD^, to verify it was actually introduced by this commit
<delroth>
it was broken by last staging-next merge into master
<delroth>
(and its fix is on the current staging-next)
<delroth>
oh interesting, for me it didn't fail on nixos. not sure how that happened, but hey, as long as we agree that commit introduces breakages I'm ok with that :)
<pbogdan>
(the rebuild is via strictDeps being set in bintools-wrapper presumably)
<ekleog>
delroth: ok so I can confirm that the commit introduced a breakage of gnutls locally… though tbh given how disallowedReferences works it's likely a bug of either nix or the machine's hardware ._.
<ekleog>
s/machine/builder/ (thinking of the builder who built the gcc-post-commit, maybe an error in it or something like this)
<ekleog>
like, disallowedReferences should not affect the build product… right?
<ekleog>
just checked with `nix-build -E 'with (import ./. {});derivation {name = "hello";dep=stdenv;builder=./test.sh;system=builtins.currentSystem;disallowedReferences = [ stdenv ];}'` and `echo "Hello world! stdenv is $dep" > $out`, and it confirms that the build is supposed to fail loudly when disallowedReferences is the cause
<delroth>
yeah I'm super confused as to why this commit is causing these builds to fail too.
<delroth>
but I mean... it's definitely happening
<ekleog>
my current guess is: 1. This commit triggers a mass rebuild, 2. Some builder building basic infrastructure (gcc, ld, the like) experiences a cosmic ray flipping some bit in the output, 3. We're seeing the wth that ensues
<ekleog>
would need to run a --check on the whole dependency graph of gnutls and/or try building it from after the commit with nothing in the store, but my machine isn't powerful enough for doing that in a reasonable amount of time :/
<delroth>
my guess is there's a lot of pseudorandom brokenness that's been hidden away by caching
<delroth>
I've managed to reproduce the valgrind build failure twice now by doing a nix-build nixos/tests/login.nix
<delroth>
but then it succeeded on the 3rd try
<ekleog>
delroth: I ran `nix-build . -A gnutls --check` locally before the commit (so without using the cache), it passed a rebuild of gnutls, so it's not just the cache
<ekleog>
but yeah, there are likely still sources of transient errors hiding in lots of places
<pbogdan>
regardless, it would be nice to not have a mass rebuild on master?
pie___ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie__ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
sir_guy_carleton has quit [Quit: WeeChat 2.2]
MichaelRaskin has quit [Quit: MichaelRaskin]
makefu has quit [Ping timeout: 268 seconds]
worldofpeace has quit [Ping timeout: 252 seconds]
makefu has joined #nixos-dev
hedning has quit [Quit: hedning]
phreedom has quit [Ping timeout: 256 seconds]
phreedom has joined #nixos-dev
ckauhaus has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
worldofpeace has joined #nixos-dev
phreedom has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
worldofpeace has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 250 seconds]
Haskellfant has joined #nixos-dev
ivan_ has joined #nixos-dev
ckauhaus_ has joined #nixos-dev
sphalerite_ has joined #nixos-dev
<srhb>
delroth: Oh, interesting, I was never able to reproduce the valgrind error.
ckauhaus has quit [*.net *.split]
roberth has quit [*.net *.split]
fadenb has quit [*.net *.split]
andi- has quit [*.net *.split]
cocreature has quit [*.net *.split]
ivan has quit [*.net *.split]
sphalerite has quit [*.net *.split]
samueldr has quit [*.net *.split]
Haskellfant is now known as cocreature
samueldr has joined #nixos-dev
roberth has joined #nixos-dev
phreedom has joined #nixos-dev
fadenb has joined #nixos-dev
andi- has joined #nixos-dev
<srhb>
delroth: I don't quite understand how you reproduced it by building the test. Wouldn't it require valgrind to fail to build first?
<srhb>
delroth: ekleog: Am I understanding the current situation correctly: The strictDeps revert happened, and suddenly the new eval matched (at least) the cached valgrind failure from many days ago, and thus we are seeing a ton of (non-deterministic, irrelevant) failures?
phreedom has quit [Ping timeout: 256 seconds]
<srhb>
If that is accurate, then we'll be fine once staging-next is merged back into master, which should hopefully happen very soon, since no channels will progress until that happens anyway.
<ekleog>
srhb: I think your summary is correct about the tests
<ekleog>
for gnutls, it looks somewhat weirder: even with `--check` I was able to successfully build gnutls before-the-commit and not to build it after-the-commit (didn't try multiple times to know whether it was transient, but the error message claimed some files were not found, so I'd guess it's not at least for the failure)
<srhb>
ekleog: Ah, that was broken by the revert? OK, I'll look a bit later. :)
<ekleog>
great, thanks! I must say I'd have said before testing that a change in `disallowedReferences` couldn't make a package stop to build, but… :/ (hence the idea it maybe comes from some kind of transient failure, either in the build process or in the compilers provided by hydra or something similar)
<srhb>
ekleog: Not understood. The purpose is to stop a package from building.
<ekleog>
oh yeah sorry, I meant having disallowedReferences making a package stopping to build without actually hitting disallowedReferences (ie. the build process fails with an error unrelated to disallowedReferences after-the-commit, and not before-the-commit)
<srhb>
ekleog: If disallowedReferences doesn't change the hash, I could see all sorts of confusion arising from a cached version being allowed, but I don't recall if that's the case.
<ekleog>
it does change the hash as before-the-commit I can fetch gnutls from the cache, and after-the-commit I cannot
<srhb>
Ah, okay, good.
<ekleog>
so as the build process is supposedly the same, I can only assume that either the build fails transiently, or the build tools used for building gnutls are somehow transiently corrupted after-the-commit and not before-the-commit (due to the ensuing mass-rebuild)
<delroth>
srhb: building the test transitively rebuilt valgrind-light
<delroth>
it failed twice, succeeded the 3rd time (and now my machine has been busy rebuilding random stuff for 6h...)
<srhb>
delroth: Interesting!
<delroth>
aws-cpp-sdk is another interesting transient failure source
<delroth>
sometimes the tests end up infinite-looping
<delroth>
I've had it happen when testing my curl change last week as well
<srhb>
delroth: Do you have logs from your local failures?
<delroth>
I don't -- but the final error was the same as the one on Hydra
<delroth>
ar: libnolto_coregrind_amd64_linux_a-m_main.o: No such file or directory
<srhb>
That sounds racy. Maybe we should just disable parallelBuilding.
<delroth>
yeah, I'm looking at the coregrind Makefile and I'm not sure what automake is doing.
<delroth>
libnolto_coregrind_amd64_linux_a-m_main.o is in LIBADD for the main libcoregrind target, so it gets added to the ar command line
<delroth>
but it's not in the deps
init_6 has joined #nixos-dev
phreedom has joined #nixos-dev
orivej has joined #nixos-dev
<ekleog>
can another pair of eyes give a look to https://github.com/NixOS/nixpkgs/pull/50505/files ? it's breaking backwards-compatibility on 18.09 (and requiring a manual action from the darwin users so that they are aware of the breakage), but it's the only way to handle this security vulnerability without entering the PHP source code, or so it seems :/
<ekleog>
tl;dr of the context: recent versions of PHP don't compile with the `intl` extension enabled (as is our case by default) on darwin, and versions of PHP until the recent ones have a known security vulnerability ; so the idea is to force the 18.09 user to manually disable `intl` so it at least doesn't break silently
Lisanna has joined #nixos-dev
__Sander__ has joined #nixos-dev
ma27 has quit [Ping timeout: 245 seconds]
ma27 has joined #nixos-dev
<delroth>
ekleog: do you think the upstream issue is ever going to be fixed? it seems like the difficulty of fixing it upstream is in making it compatible with all of the supported OSes for PHP, so a NixOS custom patch might be able to get away with a simpler solution?
<delroth>
(I mean, this doesn't seem like a hard build problem to fix really)
<ekleog>
delroth: I have no idea… but the issue is with darwin, not nixos, and I don't have a mac to try to fix PHP for nix-using darwin people :/
<arianvp>
ugh
<arianvp>
this whole nscd story is so messy
init_6 has quit []
<delroth>
ekleog: I have dolphin's buildbot running on osx :) I can give it a shot tonight
<delroth>
or give you an ssh
<delroth>
either works
<delroth>
assuming you'd be ok with the approach, otherwise I won't waste my time :)
<ekleog>
delroth: if a reasonable patch can make PHP-with-intl compile on osx then it'd be the best of both worlds, I think (and it could even be posted on the PHP page for other people who might look for the same thing) :)
<ekleog>
even if it stops building on linux, we can make the patch just for darwin
<ekleog>
however I'm a bit under water these days, so if you can do it… 😇
<delroth>
sure, I'll give it a shot
<ekleog>
thank you!
drakonis1 has joined #nixos-dev
ivan_ is now known as ivan
<gchristensen>
ekleog: send a PR adding you to the trusted user list
sphalerite_ is now known as sphalerite
<ekleog>
gchristensen: done :) (based on c0bw3b's pattern)
<gchristensen>
no need to actually remove from the other list, but that is fine :) (you'll just get re-added later)
<ekleog>
oh ok didn't know, and thank you! :)
<gchristensen>
it is okay :) the known-user list is generated from the list of nixpkgs contributors
<gchristensen>
ok, deployed
hedning has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
<Profpatsch>
arianvp: I have the patch applied here locally, works like a charm (had problems with the 5 second negative cache for host resolution)
<domenkozar>
I know you all hacked over the weekend to fix recursive nix so come out :-)
hedning has quit [Quit: hedning]
<gchristensen>
how should recursive nix work w.r.t. the inner expression? my thought was something like https://gist.github.com/grahamc/1cd2ec903dceed8f86815086c8e0c6d1 but imagine the case that gcc uses recursive nix --having gcc "depend" upon every byte in nixpkgs is ugly
<domenkozar>
well nix gcc is like taking over the world
<gchristensen>
gcc might be slightly contrived, but it is pretty easy to image rust using recursive nix instead of "cached" expressions w/ carnix, and it is easy to imagine rust being used at low levels in the stack
<domenkozar>
I would imagine we'd first have an issue with ghc
<qyliss^work>
Having macOS virtualised on top of NixOS, I mean
<gchristensen>
every restart of the systemd service, the macos vm is reset to a barely-just-installed state, too. it is nice
<clever>
purity!
<gchristensen>
done with a cloud-init style thing, passed in through a virtual CDROM -- see notes.md
<qyliss^work>
Yeah, that's awesome
hedning has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.2]
Lisanna has quit [Quit: Lisanna]
worldofpeace has joined #nixos-dev
worldofpeace has quit [Remote host closed the connection]
<yl[m]>
domenkozar: thanks for the push rights :)
hedning has quit [Remote host closed the connection]
<yl[m]>
LnL: now that I can merge PRs, will you reconsider https://github.com/NixOS/ofborg/pull/219 ? If not, can I somehow make use of my Mac to help out as well? (It's mostly idle and laying around my desk)
<arianvp>
what about the new udev rules cause container detection?
<arianvp>
(I've been trying to convert nixos-container to use the upstream systemd-networkd files, but running into the issue you filed)
<arianvp>
and trying to figure out what to do to fix it :P
<arianvp>
I don't fully understand why currently container detection is broken, as that, afaik, has nothing to do with udev
<arianvp>
but with ConditionVirtualization in system
<arianvp>
systemd*
worldofpeace has joined #nixos-dev
hedning has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
drakonis1 has joined #nixos-dev
hedning has quit [Remote host closed the connection]
hedning has joined #nixos-dev
<qyliss^work>
Not -dev-related I guess, but this is related to discussion in here a few hours ago, and should probably be dealt with sooner rather than later... https://github.com/NixOS/nixpkgs/issues/51078
<qyliss^work>
(Not trying to stir up drama or anything, just figured it was something to be aware of given the earlier conversation)
<gchristensen>
domenkozar: ping
<gchristensen>
thanks qyliss^work
<samueldr>
oh wow, that domen peep is so toast (/s)
<gchristensen>
I wonder if we should lock the thread or leave it open
<Mic92>
that guy...
bennofs[m] has joined #nixos-dev
<yl[m]>
I've seen his comment on the issue he's referring to and as someone who has not seen his comments before (and I did not know about him banned from Discourse) I was left wondering what has happened in the past between him and domenkozar
<yl[m]>
s/he's referring to/he's referring to earlier today/
<bennofs[m]>
maybe they only react badly when commenting on other's work?
<zimbatm>
what's happening with my PR? :)
<zimbatm>
oh..
<Profpatsch>
He has done /nothing wrong/
<Profpatsch>
Or she? Who knowes
<drakonis1>
are we going to go into one of those x has done nothing wrong
<infinisil>
domenkozar: I think that comment is fine, xeji was complaining about not having a good issue, but that's all one can do when such a special case arises
<domenkozar>
ok fine
<domenkozar>
I'll find you a good one
<Profpatsch>
infinisil: Bit of backstory, about a year back there was a person acting exactly the same way.
<Profpatsch>
Either there’s two people, or the same person made a new account and came back.
<infinisil>
Profpatsch: Before coretemp existed?
<Profpatsch>
I haven’t confirmed, old account was 0xABAP or something similar.
<gchristensen>
butterflya, 0xabab, plus a few others all probably the same person
<drakonis1>
coretemp is 2015
<gchristensen>
the first one resulting in very interesting emails to me
<bennofs[m]>
i mean technically on that group management issues' the first comment could have been a little more constructive as well (asking for more details instead of dismissing the issue)
<drakonis1>
the oldest issue coretemp commented on was 2015
<drakonis1>
the issue, not the comment
<domenkozar>
yeah coretemp appears a few months after I banned 0xABAB
<drakonis1>
domenkozar: /r/iamverysmart incarnate
<domenkozar>
or whatever that handle was
<gchristensen>
domenkozar: just so it is real clear, I am firmly in the camp of coretemp should have been banned some time ago.
<infinisil>
domenkozar: Okay yeah that comment is pretty bad
<Profpatsch>
This one is gold, yes.
<qyliss>
My 2c is that you have to look at the big picture rather than trying to find one smoking gun issue, because that’s now how microagressions work (not that coretemp has been solely microaggressing, but whatever). Does anybody honestly believe that the project is better off for having this person in it?
<gchristensen>
I agree. I feel bad about and concerned by the people pushed away by this person
<qyliss>
^^
* infinisil
hasn't noticed any specifically bad behaviour from coretemp on his time at nixpkgs
<infinisil>
So I'm missing the bigger picture
<bennofs[m]>
it's a sad case though, since it seems like there is just something that has tripped coretemp in the wrong way and if resolved he could become good contributor. but he has too many cases of bad comments right now :(
<gchristensen>
could they? I haven't seen much actual contribution from them
<infinisil>
Well package updates are welcome all the time
<bennofs[m]>
maybe nothing major but some small things
<bennofs[m]>
so this is not pure troll, they seem to actually be using nixos?
<gchristensen>
imo the good doesn't matter in the face of th ebad
<gchristensen>
I don't care about brilliant jerks
<qyliss>
When I was getting started on Homebrew there was somebody like this
<qyliss>
Except he was a committer
<qyliss>
After a particularly frustrating review cycle another maintainer got in contact with me about it
<gchristensen>
ew :(
<qyliss>
And we talked about what had happened and then he was removed from the project
<qyliss>
If that had carried on, even though it was easy to dismiss one individual comment as not too bad, i would have given up
<qyliss>
But the other maintainer noticed the bigger picture
<bennofs[m]>
i agree that given the current situation it's probably best to ban them. still I hope that they can get better one day and get the outages under control
<domenkozar>
there's science behind the fact that every 1 bad doing needs ~10 to compensate
<domenkozar>
unfortunately on internet there's very little chance to mentor people like that
<qyliss>
And as a result I felt extremely welcome, stuck around, and eventually became a maintainer myself anyway
<domenkozar>
in real life there's hope :)
<qyliss>
(not that maintainers are fungible, but you get the idea)
<domenkozar>
as much as I feel sorry for coretemp, there's not much more I can do
<Profpatsch>
lol, he revealed his true face after a bit of snarky commenting, as 0xABAB did.
<qyliss>
they had a warning, and responded with a personal attack. that’s not a good sign.
<Profpatsch>
50 bucks it’s the same person.
<bennofs[m]>
you convinced me, we gave them enough chances
<domenkozar>
there's a very good talk from ex gentoo maintainer
<domenkozar>
he speaks how gentoo had a huge problem due to not handling people like this
<aminechikhaoui>
I think coretemp is right about the fact that NixOS doesn't have a code of conduct, if there was, the decision of banning would have been trivial
<aminechikhaoui>
would be nice if there is a formal code of conduct imho
<domenkozar>
yes :)
<bennofs[m]>
i mean, technical details: "Some recent 18.09" that must've been on purpose to trigger, don't see why you would write it like that by accident
<infinisil>
I propose just asking him if he was 0xABAB before
<gchristensen>
infinisil: why fo?
<qyliss>
NixOS doesn’t have a code of conduct??
<qyliss>
TIL
<qyliss>
Don’t know why I assumed otherwise
<srhb>
The high standards of the people involved, probably :)
<aminechikhaoui>
yeah :D
<samueldr>
let's assume it's because the peeps here are generally great?
<infinisil>
gchristensen: because it could just be a coincidence. Of course he could just lie about it (and probably will) but it's worth a try imo
<Profpatsch>
It’s obviously because we have a domenkozar banning people left and right. :3
<qyliss>
Yeah usually I get a very different vibe from projects without a CoC… :D
<qyliss>
lmao
<gchristensen>
infinisil: I don't think that would get us anywhere. they have absolutely no incentive to say yes.
<drakonis1>
the projects with a CoC tend to be surrounded with copious amounts of drama
<Profpatsch>
CoC discussion in 3 .. 2 .. 1
* Profpatsch
leaves for greener pastures
<qyliss>
I think I assumed there was one because NixCon had one
<domenkozar>
it's pretty simple, no ad hominem attacks
<infinisil>
Alright, well I'll go enjoy some series now :)
<domenkozar>
gchristensen: :D
<domenkozar>
the ban in in effect, fyi
<infinisil>
Did you properly inform him on the reason of the ban?
<infinisil>
s/of/for
<domenkozar>
yes, he has gotten an email
<domenkozar>
from github
<Profpatsch>
lol
<domenkozar>
I think the reason was stated out pretty clearly
<infinisil>
domenkozar: It was?
<infinisil>
I see now that coretemp has some problems is we're better off without them. But they should at least know exactly why they were banned, not just some handwaving. This is also such that they can't go around saying "nixpkgs people banned me without a good reason, look at how bad they're handling this"
<infinisil>
s/is/and
<qyliss^work>
they're almost certainly gonna do that no matter what
<qyliss^work>
(and/or just be back tomorrow with a new account)
qyliss_ has joined #nixos-dev
qyliss has quit [Ping timeout: 260 seconds]
qyliss_ is now known as qyliss
<zimbatm>
I'm sad we have to ban people
<LnL>
yeah same
<zimbatm>
I tried to reach out to him multiple times
<zimbatm>
I don't think he gets it
<infinisil>
qyliss^work: Hmm yeah probably..
<zimbatm>
it's always everybody else's fault but him
<gchristensen>
it is notable the nixpkgs ban list is about 5 nicknames
<gchristensen>
(I'd say people, but I feel pretty confident several of them are the same person)
<worldofpeace>
As a new contributor, this doesn't frighten me and seemed very reasonable. They don't seem interested in resolution unless that resolution makes them correct.
<infinisil>
worldofpeace: Well said
<gchristensen>
<3 worldofpeace
<qyliss>
It’s not like we have any way of knowing if they learn from their mistakes, make a new account, and come back acting appropriately
<qyliss>
So they do always have that as an option if they actually do want to positively contribute
<gchristensen>
for a long time it felt like they had learned from previous nicks :)
<gchristensen>
I wonder how much bigger adding zfs to the standard image would make it?