<LnL> bisect points me to 0186286433cccbf6faf288c22df03e63e46dd94d for the 17.09 failure
la_putin has joined #nixos-dev
<gchristensen> w00t rust is on to stage2.
ma27 has quit [Ping timeout: 256 seconds]
goibhniu has quit [Ping timeout: 264 seconds]
jtojnar has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
mbrgm_ has joined #nixos-dev
mbrgm has quit [Ping timeout: 268 seconds]
mbrgm_ is now known as mbrgm
la_putin has quit [Remote host closed the connection]
la_putin has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
jtojnar has joined #nixos-dev
la_putin has quit [Read error: Connection reset by peer]
la_putin has joined #nixos-dev
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
Dezgeg has quit [Ping timeout: 276 seconds]
la_putin has quit [Quit: Konversation terminated!]
el_putin has joined #nixos-dev
el_putin has quit [Read error: Connection reset by peer]
el_putin has joined #nixos-dev
el_putin has quit [Remote host closed the connection]
el_putin has joined #nixos-dev
ma27 has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 268 seconds]
jtojnar_ is now known as jtojnar
JosW has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 248 seconds]
ma27 has quit [Ping timeout: 276 seconds]
ma27 has joined #nixos-dev
el_putin has quit [Read error: Connection reset by peer]
el_putin has joined #nixos-dev
el_putin has quit [Read error: Connection reset by peer]
el_putin has joined #nixos-dev
Dezgeg has joined #nixos-dev
Dezgeg has quit [Client Quit]
<Mic92> gchristensen: you are currently testing the rust pr?
el_putin has quit [Ping timeout: 264 seconds]
Dezgeg has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
la_putin has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar_ is now known as jtojnar
ma27 has quit [Ping timeout: 256 seconds]
<gchristensen> I'm not, Mic92
<MichaelRaskin> Is testing borgable?
ma27 has joined #nixos-dev
<gchristensen> should be :)
<LnL> oh, I commented on the wrong pr?
<MichaelRaskin> I was not sure _which_ PR is discussed
<MichaelRaskin> LnL: probably you picked the correct one
<gchristensen> I'm not sure either :)
<LnL> what's the attribute, don't see it exposed anywhere
<gchristensen> are we talking cargo-vendor?
<LnL> yeah I see cargoVendor = ... in the source
<LnL> but it's not in rust or rustPlatform
<gchristensen> I don't know :/ so that rust build last night timed out after 10hrs
<LnL> I tested with enableParallelBuilding again, but that didn't seem to make a difference in time for me
<gchristensen> :/
<gchristensen> like it or not, rust is about to be a channel-blocker :P it'd be good to sort out
<LnL> not sure why, I got it down to ~30min last time I tried that
<LnL> not rebuilding llvm every time would also help
orivej has joined #nixos-dev
el_putin has joined #nixos-dev
la_putin has quit [Read error: Connection reset by peer]
<LnL> oh! the vendored llvm might be exactly why it's broken on 17.09
ciil has joined #nixos-dev
zarel has joined #nixos-dev
pie_ has joined #nixos-dev
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
vcunat has joined #nixos-dev
<gchristensen> I'm thinking build sampling might be a thing I could do in a horribly hacky way, of running nix-build -j0 and find the first one in the list of things to build which refers to a named attr in nixpkgs. can anyone imagine a way to do this? or do this better?
<gchristensen> the best way I can think of would involve generating the package DB which includes attr names and out paths, and doing a matchup
<vcunat> gchristensen: missing context - what exactly you want?
<gchristensen> I want to let people just ask ofborg to build without having to worry about the exact thing it should be building. ex: in this PR there is a single correct thing ofborg should attempt: https://github.com/NixOS/nixpkgs/pull/34094
<gchristensen> for https://github.com/NixOS/nixpkgs/pull/34083 I'd like to guarantee it at least builds librsvg, _maybe_ a thing or two impacted by the change
<vcunat> well, it's easy to get the list of changed attributes from the rebuild-amount script
<gchristensen> but it must be cross-architecture compatible (ie: by attribute name, and not by .drv) and preferably without having to pre-calculate the per-arch .drv's for each architecture
<vcunat> but that list won't help you much for larger rebuilds
<vcunat> so, it could be like - if the list is short enough, just pick two random attributes :-)
<gchristensen> true! :D
<vcunat> or the rebuild-amount part could just comment with the list, if it's short enough
<vcunat> BTW, I recently added actual --print option to the script
<gchristensen> I remember that. I don't actually use that script anymore, though the change looks good
<LnL> I do :)
<gchristensen> if the list is long I could do some drv parsing to get closer to the root of the change
<gchristensen> btw LnL I finally added some automatic tests to the builder :') it was hard
<LnL> nice!
<vcunat> well, you can do `nix-store -q --graph foo.drv`
<vcunat> I'm not sure if there's a convenient tool to "subtract" two dot-graphs
<MichaelRaskin> vcunat: well, you could list the vertices, sort and diff.
<vcunat> it might be best to (1) find common vertices (store names), (2) remove them from the second graph, (3) look at vertices that depend on nothing (on the augmented graph)
<vcunat> that seems bash-able on a few lines
<vcunat> or perhaps something like https://github.com/Gabriel439/nix-diff
<gchristensen> I think the depend-on-nothing version is more on the right track than nix-diff. is this something you'd be interested in taking a crack at? :)
<gchristensen> bash-or-whatever is perfectly fine...
<vcunat> well, not today
<vcunat> And I'm perfectly OK if someone else does it ;-) but I think I could manage during the next week.
<vcunat> Related: I'd actually love to have grouping by the root of failure for Hydra's newly-failed list.
<gchristensen> that would be very cool :)
<vcunat> When you have very many of them, it's hard to know if everything is caused by the same error or not.
<vcunat> I always have to resort to sampling a few of them...
zarel has quit [Quit: Leaving]
<LnL> that would be super nice
<vcunat> To be clear, I don't expect to be capable of writing in perl soon.
<gchristensen> well, let's see where ofborg leads. I'd love it if somebody were to implement this script as described by vcunat, even if it takes several days =)
<vcunat> whoever implements this, I expect it would best fit into <nixpkgs/maintainers/scripts/> intially?
<gchristensen> yeah I agree
<LnL> I should probably also add some of my aliases there
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
<vcunat> I think we miss some co-organization in creating a toolset for "common" tasks
<vcunat> (nix-related ones)
<gchristensen> I agree
<MichaelRaskin> 9999
<MichaelRaskin> «I think we miss some co-organization» is true, the rest is details
<vcunat> :-)
<LnL> aaah, if I have to rebuild llvm one more time...
<vcunat> That's the bug with ld detecting bogus macos versions?
<LnL> no, I'm looking at rust
<vcunat> With that darwin regression, I've been wondering whether to merge this version of staging to master. https://hydra.nixos.org/eval/1427837?filter=&compare=1427817&full=#tabs-now-fail Linuxes seem fine there.
<LnL> this fixes the ld issue https://github.com/NixOS/nixpkgs/pull/34088
<vcunat> Oh, great, so I can stop caring about those errors.
<LnL> yep, I tested that with a /tmp path and it seemed to work
<LnL> don't know for sure ofcorse since it changed the store path :p
<vcunat> Aha, rustc is also regressing on darwin.
<LnL> that's an intermittent failing test, thought I disabled it with the last update
<LnL> I'm looking at the 17.09 failure + trying to get rid of the vendored llvm build
<vcunat> Then I suppose I'll just wait for more builds to finish (2.5k darwin jobs in queue), check the amount of newly-failing, and merge that commit to master.
<vcunat> Probably tomorrow.
<vcunat> It would be nice if niksnut (or anyone) could unblock the darwin builders, as half of them is stuck with days-old builds.
<LnL> sounds good, then we have the cmake fix for libclang in master
<LnL> :/
<vcunat> yes
<gchristensen> vcunat: copumpkin and I both can do that, I can help with that in ~20min
<vcunat> Oh, I didn't know that. Maybe we should have a list somewhere :-)
<vcunat> They're stuck for days, so 20 minutes is perfectly fine ;-)
<gchristensen> maybe a page on the wiki?
<vcunat> Or https://nixos.org/hydra/ could have a section about our instance.
<vcunat> (I don't know.)
<gchristensen> that could work, but the page is hard to update
<vcunat> I don't expect this information would change a lot.
<vcunat> But certainly better some place than none.
<samueldr> for organizational stuff, on the wiki, it may be better to namespace it, since the wiki is otherwise built with the end-user in mind; e.g. https://nixos.wiki/wiki/Org:Hydra for the nixos organization hydra specific informations (if wanted)
<gchristensen> yeah, I sort of wish there was a place for operational docs
ma27 has quit [Quit: WeeChat 2.0]
goibhniu has joined #nixos-dev
taktoa has joined #nixos-dev
infinisil has quit [Quit: ZNC 1.6.5 - http://znc.in]
vcunat has quit [Quit: Leaving.]
infinisil has joined #nixos-dev
<gchristensen> aw vcunat is gone
JosW has quit [Quit: Konversation terminated!]
<LnL> any ideas what could cause 'SSE2 was not detected as available on an x86 platform'?
<Mic92> broken compiling test in autotools?
<Mic92> (broken for other reasons)
<LnL> it's a rust test, but it woks fine with the default llvm build: run-pass/sse2.rs ... ok
<LnL> I'll do a test with the same cmake flags instead of what we use by default
goibhniu has quit [Ping timeout: 248 seconds]