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: 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>
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>
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
<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
<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]