WilliButz has quit [(Quit: WeeChat 1.9)]
WilliButz has joined joined #nixos-dev
orivej has quit [(Ping timeout: 260 seconds)]
orivej has joined joined #nixos-dev
mbrgm has quit [(Ping timeout: 248 seconds)]
mbrgm has joined joined #nixos-dev
vcunat has joined joined #nixos-dev
disasm has quit [(Remote host closed the connection)]
FRidh has joined joined #nixos-dev
fpletz has quit [(Quit: ^D)]
<jtojnar> vcunat: why merge master to the gnome-libs?
fpletz has joined joined #nixos-dev
zarel has joined joined #nixos-dev
fpletz has quit [(Changing host)]
fpletz has joined joined #nixos-dev
zarel has quit [(Remote host closed the connection)]
<vcunat> jtojnar: in case we were to merge it soon, I wanted Hydra to have binaries ready instead of building some that have no chance of being used for channels
<jtojnar> vcunat: would not that still go to staging?
<vcunat> the point of staging is to have binaries ready
<vcunat> (most of them at least)
<vcunat> a separate jobset achieves that by itself
<vcunat> current staging won't go to master as it is anyway, as I'll add a full rebuild there (there's CVE in glibc)
<jtojnar> oh, that makes sense, thanks
JosW has joined joined #nixos-dev
vcunat has quit [(Quit: Leaving.)]
vcunat has joined joined #nixos-dev
<Dezgeg> anyone wanna try restarting kodiPlain from https://hydra.nixos.org/eval/1407901?compare=1407805#tabs-now-fail
<Dezgeg> probably intermittent, fails on one of my machines but not on the other...
<vcunat> yes, kodi does this all the time
<vcunat> Dezgeg: restarted
<vcunat> I'd hope we can merge the branch tomorrow or so
<Dezgeg> yes it looks good to me so far
<vcunat> just before the next batch of security mass rebuilds comes
Sonarpulse has joined joined #nixos-dev
<Sonarpulse> anyone know why the setup hook for cc-wrapper exands the path?
<Sonarpulse> seems unnecessary
<Sonarpulse> the wrapper scripts manage their own paths
goibhniu has joined joined #nixos-dev
<bgamari-> Sonarpulse, Would you mind if this went in before you patches? https://github.com/NixOS/nixpkgs/pull/31292
<Sonarpulse> bgamari-: !!! :)
<Sonarpulse> looking carefully
<Sonarpulse> but I hightly doubt it!
<bgamari-> it's just a refactoring
<bgamari-> but as such it may conflict
<Sonarpulse> I'm rebasing things all over anyways
<Sonarpulse> I don't mind
<Sonarpulse> bgamari-: cool so this doesn't change the logic for now
<bgamari-> right
<Sonarpulse> that's fair
<Sonarpulse> I wouldn't mind you changing the logic either :)
<Sonarpulse> but one step at at time
<bgamari-> I'm still trying to work out how
<Sonarpulse> sure
<Sonarpulse> I think it will still be a mass rebuild
<Sonarpulse> but that's ok Too
<Sonarpulse> btw I move stuff between gcc versions
<Sonarpulse> *move changes
<Sonarpulse> by doing
<Sonarpulse> git diff --staged pkgs/development/compilers/gcc/$NEW/default.nix | sed "s_/""$NEW""/_/""$OLD""/_" | git apply -3
<Sonarpulse> sometimes doing that in a loop too!
<bgamari-> cool
<bgamari-> yes, that makes sense
<Sonarpulse> I'm happy to merge very soon
<Sonarpulse> this shouldn't be controversial
<bgamari-> cool
<Sonarpulse> what's the base branch btw?
<bgamari-> master
<bgamari-> as of a few days ago
<Sonarpulse> ok
<Sonarpulse> I'd say newest nixpkgs-unstable
<Sonarpulse> but realistically
<Sonarpulse> I am not sure who will review my changes soon
<Sonarpulse> so it probably won't matter
<bgamari-> by the way, do you know what machine gcc's --with-native-system-header-dir= refers to?
<bgamari-> is this the target's headers?
<Sonarpulse> bgamari-: no idea
<Sonarpulse> I sort of guessed and stuff before
<bgamari-> yeah
<bgamari-> the documentation is sparse
<Sonarpulse> bgamari-: wait CC_FOR_BUILD is a logic change?
<bgamari-> yeah, I just noticed that
<bgamari-> I meant to revert that one
<bgamari-> just pushed a new branch
<bgamari-> the gcc expression is a bit messy on the whole
<bgamari-> some things seem to be set in the builder
<Sonarpulse> yes it is an abomination
<bgamari-> others in the derivation attributes
<bgamari-> I didn't dare change much
<Sonarpulse> did I mention how Exherbo almost builds gcc itself + runtime libraries separately?
goibhniu has quit [(Ping timeout: 264 seconds)]
<bgamari-> I'm unsure of whether that is ultimately a good thing in sum
<bgamari-> Sonarpulse, by the way, have you finished rebasing your work?
<bgamari-> if so I should rebase as well
<Sonarpulse> bgamari-: well then we can avoid this "stage static" business"
<Sonarpulse> which really uglifies cross stuff
<Sonarpulse> and no, not yet
<Sonarpulse> doing stuff again
<Sonarpulse> but somewhat creative rebasing
<Sonarpulse> so need to build again
<bgamari-> Sonarpulse, also, be aware that I rebased some of your patches
<Sonarpulse> in your huge PR?
<bgamari-> right
<bgamari-> I probably should have mentioned this earlier
<bgamari-> it wasn't that hard
<bgamari-> I think boost was slightly problematic
<bgamari-> but otherwise it went pretty smoothly
<bgamari-> specifically the changes in "misc pkgs: Fix in light of stdenv and cc-wrapper changes" iirc
<Sonarpulse> bgamari-: oh i forget if I squashed
<Sonarpulse> but I had another boost change later
<Sonarpulse> I hope I did
<bgamari-> Sonarpulse, I pushed a rebased version of ben-cross
<Sonarpulse> bgamari-: ah on top of the gcc pr? thanks
<bgamari-> yep
<Sonarpulse> bgamari-: looks great!
vcunat has quit [(Ping timeout: 264 seconds)]
<bgamari-> Sonarpulse, by the way, any thoughts on https://github.com/NixOS/nixpkgs/pull/30883 ?
vcunat has joined joined #nixos-dev
<Sonarpulse> bgamari-: oh right
<Sonarpulse> I forgot
<Sonarpulse> bgamari-: merging
<Sonarpulse> bgamari-: merged!
<bgamari-> Sonarpulse, ahh, lovely
<Sonarpulse> bgamari-: are you building anything?
<Sonarpulse> I am about to push new binutils-wrapper
mguex_ has joined joined #nixos-dev
catern_ has joined joined #nixos-dev
<Sonarpulse> vcunat: I'm hoping this new trend of you being on IRC continues :D
<vcunat> yes, I figured I should be there, at least during my release management
catern_ is now known as catern
<Sonarpulse> vcunat: yay!
<Sonarpulse> vcunat: also I forgot you were doing this next one
jtojnar has quit [(Quit: jtojnar)]
<orivej> Intense green color for small rebuild count labels ("10.rebuild-linux: 1") is too distracting, I would like to tone them down e.g. to #efe, as can be currently seen on https://github.com/NixOS/nixpkgs/pulls . Does anyone object?
<vcunat> you/someone did the change already, right?
<vcunat> (seems OK to me)
JosW has quit [(Quit: Konversation terminated!)]
FRidh has quit [(Quit: Konversation terminated!)]
vcunat has quit [(Quit: Leaving.)]
<Sonarpulse> let the bikeshedding begin!
* bgamari- looks
grahamc has quit [(Ping timeout: 240 seconds)]
pstn has quit [(Ping timeout: 246 seconds)]
stites[m] has quit [(Ping timeout: 264 seconds)]
nocent has quit [(Ping timeout: 240 seconds)]
hedning[m] has quit [(Ping timeout: 255 seconds)]
sphalerite has quit [(Ping timeout: 276 seconds)]
moredread[m] has quit [(Ping timeout: 264 seconds)]
florianjacob has quit [(Ping timeout: 248 seconds)]
olejorgenb[m] has quit [(Ping timeout: 248 seconds)]
peterhoeg has quit [(Ping timeout: 276 seconds)]
regnat[m] has quit [(Ping timeout: 276 seconds)]
goibhniu has joined joined #nixos-dev
florianjacob has joined joined #nixos-dev
pstn has joined joined #nixos-dev
stites[m] has joined joined #nixos-dev
hedning[m] has joined joined #nixos-dev
sphalerite has joined joined #nixos-dev
olejorgenb[m] has joined joined #nixos-dev
grahamc has joined joined #nixos-dev
regnat[m] has joined joined #nixos-dev
nocent has joined joined #nixos-dev
copumpkin has joined joined #nixos-dev
hl has joined joined #nixos-dev
rycee has joined joined #nixos-dev
peterhoeg has joined joined #nixos-dev
FRidh[m] has joined joined #nixos-dev
moredread[m] has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 246 seconds)]
<bgamari-> How does one specify which autoconf version autoreconfHook should use?
<Sonarpulse> bgamari-: in some PR
<Sonarpulse> I made a new hook
<Sonarpulse> bgamari-: did you skip the boost stuff temporarily you said?
<bgamari-> Sonarpulse, well, I tried to port it
<bgamari-> I don't recall what ended up happening
<Sonarpulse> ok
<bgamari-> it did fight back
<Sonarpulse> looks it it was skipped
<Sonarpulse> I am rebasing your branch now
<Sonarpulse> on my binutils-wrapper
<Sonarpulse> bgamari-: no
<Sonarpulse> but
<Sonarpulse> I bet with your fix
<Sonarpulse> it's not needed anymore!
<bgamari-> hopefully
<Sonarpulse> ok that is something
<bgamari-> It looks like I need to remove the -B's as well
<bgamari-> otherwise the build gcc dies as it tries to link against the host's glibc
* bgamari- just tries cutting out all of the bits he doesn't understand and hopes for the best
<bgamari-> Sonarpulse, yeah, you should probably throw out my "boost: enable cross-compilation" patch
<bgamari-> it's completely wrong
<Sonarpulse> bgamari-: I'm rebasing it
<Sonarpulse> well you errored on the side of the old one
<Sonarpulse> which needn't be wrong per se
<bgamari-> well, it certainly doesn't cross :)
<bgamari-> hmm, does the new `nix build` not support -j?
<Sonarpulse> bgamari-: haskell or otherwise?
<Sonarpulse> 1.12?
<bgamari-> ahh, yes use --option
<bgamari-> Sonarpulse, 1.12, right
<Sonarpulse> also pushed rebase with fixed boost rebase
<bgamari-> lovely
<Sonarpulse> all I know is Cale had some trouble with -j for haskell builds on our ios-refresh-2 branch
<Sonarpulse> but I'd guess that is unrelated
<bgamari-> it seems that `nix build` doesn't support it
<bgamari-> but you can use `nix --option max-jobs $N --option cores $M build ...`
<Sonarpulse> bgamari-: interesting
* bgamari- wishes he could build a basic nixos image
<bgamari-> it would be quite nice to actually test these things
<bgamari-> I've found that build testing doesn't offer very high assurance when it comes to cross-compilation
<Sonarpulse> bgamari-: oh no
<Sonarpulse> what sort of failures?
<Sonarpulse> OTOH
<Sonarpulse> perhaps build testings catches *regressions* the most
<Sonarpulse> that would be my hope
<Sonarpulse> if not actual correctness
<bgamari-> well, if the wrong #include is picked up
<Sonarpulse> (i.e. it could easily rot into not building, but less easily rot into wrong building)
<Sonarpulse> that wouldn't cause linking error?
<bgamari-> and you end up with, for instance, some mistaken word-size assumption
<Sonarpulse> oh in user code
<Sonarpulse> hmm
<bgamari-> right
<Sonarpulse> ideally that would creat a compile problem
<Sonarpulse> ...but C
<bgamari-> right
<Sonarpulse> btw I noticed one buildPackages.stdenv.cc
<Sonarpulse> was a nativeBuildinput
<Sonarpulse> those should be depsBuildBuild
<bgamari-> oh?
<Sonarpulse> (also, per niksnut's request, I am removing all the __ prefixes, eventually)
<bgamari-> alright
<bgamari-> what is nativeBuildInput for in that case?
<bgamari-> It might be nice to have a summary of all of the various build input attributes and their differences
<bgamari-> I know there is a bit of language in the manual
<bgamari-> but IIRC it doesn't mention how nativeBuildInput and buildInput fit with the deps$A$B attributes
<Sonarpulse> bgamari-: oops it should of
<Sonarpulse> nativeBuildInputs is depsBuildHost
<Sonarpulse> buildInputs is depsHostTarget
<bgamari-> ahh
<Sonarpulse> (the n -> n + 1 ones)
<bgamari-> yeah, I don't see any reference to either in the cross-compilation section