gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat
ashgillman has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar2 has quit [Ping timeout: 260 seconds]
pxc has quit [Ping timeout: 264 seconds]
jtojnar has quit [Remote host closed the connection]
<shlevy> Dezgeg: ping
<shlevy> niksnut: I just added a url to a fetchurl list to fix a failing build but it looks like hydra is still using the old url, any idea why that might be?
<shlevy> Manged to force it by adding a top-level job pointing tothe src
<shlevy> gchristensen: https://hydra.nixos.org/build/71094845 darwin sending inputs again
Lisanna has joined #nixos-dev
<shlevy> gchristensen: https://hydra.nixos.org/build/71206611 has been running configure for 20 hours
<shlevy> gchristensen: And this one has been on haddock for a day... haddock takes a while sometimes but seems likely a bug https://hydra.nixos.org/build/71215266
<shlevy> peti: ping
ashgillman has quit [Ping timeout: 240 seconds]
mbrgm has quit [Ping timeout: 256 seconds]
mbrgm has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
gleber_ has quit [Read error: Connection reset by peer]
gleber_ has joined #nixos-dev
ma27 has joined #nixos-dev
niksnut has quit [Ping timeout: 240 seconds]
niksnut has joined #nixos-dev
contrapumpkin has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
ma27 has quit [Ping timeout: 246 seconds]
jtojnar has joined #nixos-dev
ma27 has joined #nixos-dev
davidlt__ has joined #nixos-dev
davidlt_ has quit [Ping timeout: 256 seconds]
davidlt__ is now known as davidlt
orivej has quit [Ping timeout: 268 seconds]
<angerman> can I get a backtrace (callstack) with trace somehow?
<angerman> e.g. I know I'm ending up evaluating the same attribute twice, but apparently I'm getting there two ways... and I'd like to know how I ended up there.
<clever> angerman: i think the closest you can do is --show-trace and throwing an error?
<angerman> clever: right, that could work...a bit tedious though :-)
<clever> angerman: if you post the changes to github, i could also look at it
<angerman> clever: ha, don't want to keep you off your work :-) Most of it is in the `build-more` branch though.
<clever> angerman: i also notice some import from derivation going on, just evaluating iserv-proxy is downloading 1.5gig
<angerman> clever: ok, I don't follow right now, what you mean.
<angerman> clever: if you mean it did change since you tried the last time, yes.
<clever> i dont think iserv-proxy was in it last i checked
<angerman> no, it was't.
<angerman> clever: there's iserv-proxy, and remote-iserv in there.
<clever> once the dl is done i can poke around more
<angerman> you'll even see the `-fexternal-interpreter` settings in there.
<angerman> so it's really just the mingw32 stuff that's missing. And I'm basically reading through nix and trying to make sense of all of it.
<angerman> clever: e.g. you can try `nix-build -A pkgs.windows.pthreads --cores 0`, as that's pretty much what's missing (I believe) aside from some additional mingw configure flags which seem to have not made any difference.
<clever> ah
<angerman> Bu thtat just falls over with the `targetPackages` being only populated during the first evaluation and empty during the second.
<clever> angerman: and now its building hscolor, yeah, something is funky with this nix
<angerman> clever: there's some rather strange things going on in the cross compilation logic. But I'm with Sonarpulse, that it's likely just some minor conditionals messed up.
<angerman> clever: it's just that my nix-debugging-foo is just developing ;-)
<clever> angerman: i have a rought guess as to what the issue is, callCabal2nix
<clever> i suspect the default ghc was overriden, and it has to build ghc and cabal2nix
<clever> just to eval things
<clever> and thats easily solved, so we can just ignore it for now
<angerman> that's what I'm doing, then trying to figure out if things done't match up with my expectations. Going back, reading the expression, trying to figure out, repeat.
<clever> yeah, it took me a while to get into that, and i didnt know functional programming when i started nix
<angerman> clever: right. I try not to get stuck in issues that are just "it builds a bit too much".
<clever> i got nothing else to do while it builds :P
<angerman> haha...
<clever> ahhhh, i think i see the issue
<clever> callCabal2nix, always uses the ghc for the local package set
<angerman> clever: I've also exported the `trifecta` package, so one can try to build it in "isolation".
<clever> so haskell.packages.ghcHEAD.callCabal2nix must be compiled with ghcHEAD
<angerman> clever: hmm I'll medidate on that a bit over dinner.
<angerman> that's some rather annoying Cabal/ghc coupleing.
<clever> due to how callCabal2nix is made, there is no way to fix that in pure nix
<clever> youhave to manually run cabal2nix, and check the result into git
<clever> and then callPackage it like normal
<angerman> ugh... so callHackage and the callCandidate stuff I built, are essentially *really* expensive?
<clever> but then you have to re-run it after every update
orivej has joined #nixos-dev
<clever> if the ghc hasnt been pre-built, yeah
<clever> its having to build all of ghc 8.2.2 just to tell me what the nix assertion is
<clever> the caching in nix can also hide these expensive things
<clever> angerman: the best way to fix it and still have those features, is to modify callCabal2nix to use a haskellPackages.cabal2nix that hasnt been overridden
<clever> then it can at least get from from the binary cache
<clever> 1 { fetchurl, stdenv, mingw_headers }:
<clever> 4 assert hostPlatform != buildPlatform;
<clever> angerman: neither is in scope, so this will fail 100% of the time
<angerman> clever: ahh right, yea that one is in stdenv.hostPlatform != stdenv.buildPlaform
<clever> angerman: yeah, the lack of windows in targetPlatform is weird
<clever> targetPackages
<clever> 5895 libcCross1 = builtins.trace (builtins.toJSON (builtins.attrNames targetPackages.windows)) (
<clever> trace: ["cygwinSetup","jom","mingw_headers1","mingw_headers2","mingw_headers3","mingw_runtime","mingw_runtime_headers","mingw_w64","mingw_w64_headers","mingw_w64_pthreads","pthreads","w32api","w32api_headers","wxMSW"]
<clever> error: attribute 'windows' missing, at /home/clever/iohk/nix-hs-hello-windows/nixpkgs/pkgs/top-level/all-packages.nix:5895:70
<clever> angerman: it was able to index into windows and list the contents, then it wasnt!
<clever> and the trace should have fired twice...
<clever> ah wait
<clever> the error points to the trace itself
<angerman> clever: right it evaluate it twice: I believe for different build/host/target pairs.
<clever> trace: ["__raw","recurseForDerivations","stdenv"]
<angerman> clever: right.
<clever> aha, this is what targetPackages contains the 2nd time around
<clever> thats far too empty
<angerman> It kind of looks like we are going past the targetPackages.
<angerman> Like evaluate targetPackages for “target”. But yea... I’ve been poking at it for a while without any noteworthy results yet.
<angerman> That’s been kind of the process so far though. No incremental process for a while and then all of a sudden it’s obvious why something didn’t work ;-) and the fix ends up being tiny.
<clever> all i can think of is to page sonarpulse
<angerman> clever: I’ll probably. Maybe I’ll catch him later tonight or tomorrow morning.
<clever> also, ghc is still building, lol
ashgillman has joined #nixos-dev
Synthetica has joined #nixos-dev
<clever> sphalerite: what do you think of this PR? https://github.com/NixOS/nixpkgs/pull/37288
<clever> sphalerite: hmmm, for a no compression option, i think i would need to use cat, and tweak the extension logic a bit, should i add that as well?
<sphalerite> yeah that's what I thought. I don't really mind much, just an idea
<clever> i can add it easily
<rycee> Anybody invested in the jdk9 package? I'd like to merge https://github.com/NixOS/nixpkgs/pull/36703 but it includes a (much needed imho) change in jdk9 to use gtk3 so I'd like an ok from somebody else.
<clever> sphalerite: also, do you know anything about getting build-repeat to work?, i think you asked about it a while back, and i also havent been able to make it work
<sphalerite> I think it's only with --check that it doesn't work
<clever> i wasnt using --check
<sphalerite> oh right, maybe you just got the option name wrong then
<sphalerite> repeat vs build-repeat
<clever> tried several variations
ashgillman has quit [Ping timeout: 240 seconds]
<sphalerite> oh huh yeah it doesn't work for me either
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ nix-build nixos/release.nix -A containerTarball.x86_64-linux --repeat 5
<clever> oh!
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ sudo nix-build nixos/release.nix -A containerTarball.x86_64-linux --repeat 5
<clever> building '/nix/store/ax8rr8qmzd77yhpbi4mbis07kx5c7kjp-tarball.drv' (round 1/6)...
<clever> sphalerite: i think you have to be a trusted user?
<sphalerite> oh yes, indeed
<clever> it would help if it said so in a warning
<clever> building '/nix/store/ax8rr8qmzd77yhpbi4mbis07kx5c7kjp-tarball.drv' (round 2/6)...
<clever> it verks!
<clever> sphalerite: as i would expect, tar -c | cat > foo is deterministic
<clever> now i can check pixz!
<sphalerite> clever: are you sure? I wouldn't be surprised if it depended on filesystem order
<clever> 56 time tar --sort=name --mtime='@1' --owner=0 --group=0 --numeric-owner -c * $extraArgs | $compression $compressorFlags > $out/tarball/$fileName.tar${extension}
<clever> its already been set to sort by name
<sphalerite> oh ok
<clever> https://packages.debian.org/sid/disorderfs could also be used if you wanted to stress test that
<clever> sphalerite: i was hesitant to change the default from xz to pixz, because it may break any determinism in the make-system-tarball function
<clever> but now i can just test that
<clever> sphalerite: pixz seems to be deterministic
<clever> and PR updated
<clever> sphalerite: i also recently discovered some quirks in how paths work in nix, where lib.cleanSource makes the purity worse!
<clever> if i have a simple src = ./.; and then later do foo = src + "/yarn.lock" i get a path to the exact file, and nix will import just 1 file, and depend on the hash of its contents
<clever> so the rebuilds are minimal
<clever> but if i have src = lib.cleanSource ./.; and do src + "/yarn.lock" the result is pointing into the store, which is immutable, so nix doesnt bother copying it, and now i depend on the hash of the entre source tree!
<sphalerite> clever: just found that there are actually two distinct problems with --repeat: it being ignored for non-trusted users, *and* it being ignored in combination with --check
<clever> ah
obadz has quit [Ping timeout: 260 seconds]
obadz has joined #nixos-dev
<shlevy> dtz: Will probably dig into it myself later, but off the top of your head any idea why llvm 5 tests are failing with binutils 2.30? https://nix-cache.s3.amazonaws.com/log/inrqlk022666ii8hxwh0v76m4p2gqz07-llvm-5.0.1.drv
<shlevy> I'm testing llvm 6 now... It kind of looks like that test is based on expecting specific strings in specific places? :o
<Mic92> dtz: do you run address sanitizer on everythin?
<Mic92> *everything
davidlt_ has joined #nixos-dev
davidlt has quit [Ping timeout: 240 seconds]
<shlevy> dtz: llvm 6 fails too
<gchristensen> I'm stepping out for several hours, but I'm curious how I can improve this: https://github.com/NixOS/nixpkgs/pull/37141#issuecomment-373836810 <- tkinter was skipped on Darwin because it isn't supported on Darwin, but LnL and FRidh[m] and Mic92 all seem surprised by it.
<gchristensen> it seems we've actually lost functionality by doing the instantiation-check first: it would fail before, but at least it would tell you why
<LnL> gchristensen: yeah, I thought about that before but my assumption was that the eval checker would catch those
<gchristensen> what do you mean?
<LnL> an evaluation failure that only happens on the builder
<gchristensen> s/what do you mean/can you say more/
<gchristensen> ah
<LnL> there's no problem with meta.platforms after the merge as far as I can tell
<gchristensen> there isn't, and there is no problem with tkinter not evaluating on Darwin
<LnL> that's what I thought, but why isn't the status red then?
<LnL> oh wait, it is meta.platforms?
<LnL> yeah, I'm misremembering that then
<LnL> I think I know why I was confused, my pr-nixpkgs alias doesn't test the merge
<gchristensen> Did platforms change on master?
<gchristensen> The status isn't red because there is no reason for it to be ready. I
<gchristensen> For it to be red. Why would it be red?
<clever> gchristensen: how does this look to you?, and would there be any way for ofborg to check nixos/release.nix and see what has changed? https://github.com/NixOS/nixpkgs/pull/37288
<LnL> yeah it did, but because I checked evaluation for head instead of merge it seemed like it didn't change
<gchristensen> Oh I see. Clever I can take a look in a few hours.
<gchristensen> Cc me on it?
<clever> done
<clever> gchristensen: the change is mainly in make-system-tarball, and there is at least one entry in release.nix that can test it
ma27 has quit [Ping timeout: 246 seconds]
ma27 has joined #nixos-dev
LangeOortjes has quit [Read error: Connection reset by peer]
ma27 has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
Lisanna has quit [Quit: Lisanna]
ma27 has quit [Ping timeout: 240 seconds]
Sonarpulse has joined #nixos-dev
ma27 has joined #nixos-dev
lassulus has quit [Ping timeout: 276 seconds]
ma27 has quit [Ping timeout: 265 seconds]
ma27 has joined #nixos-dev
lassulus has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
Sonarpulse has quit [Ping timeout: 276 seconds]
<hedning[m]> hydra is down due to the DB again it seems: https://hydra.nixos.org/
<obadz> ikwildrpepper / niksnut / domenkozar - hydra's postgres is down
<domenkozar> I don't have access :(
<obadz> so just ikwildrpepper and niksnut or is there anyone else?
<gchristensen> just the two
LangeOortjes has joined #nixos-dev
<LnL> ikwildrpepper: niksnut: postgres is down
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
davidlt_ is now known as davidlt
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev