<Sonarpulse> bgamari: perhaps ar
<Sonarpulse> or ranlib
<Sonarpulse> like ar did wrong ranlib-esque
goibhniu has quit [(Ping timeout: 250 seconds)]
<bgamari> Sonarpulse, hmm
<Sonarpulse> bgamari: the follow up change I want to do
<Sonarpulse> which we might now have to do
<Sonarpulse> or revert
<Sonarpulse> is to make binutils wrapper add "--arch" and friends
<Sonarpulse> and don't pass --target to binutils
<Sonarpulse> and prefix the binaries accordingly
<Sonarpulse> so we only build binutils once
<bgamari> hmm
<bgamari> so the prefixed tools will be wrappers which pass the appropriate --arch?
<gchristensen> anyone know the oldest kernel we support?
<gchristensen> no no no no no this is terrible
<copumpkin> what is terrible?
<gchristensen> $work is marooned on nixos 17.03
<copumpkin> oh no!
<gchristensen> "FATAL: kernel too old"
<copumpkin> for what?
<LnL> rip
<gchristensen> that is a glibc error when it can't support how ancient your kernel is
<gchristensen> anything that uses glibc will emit that when used
<cransom> i was using mptcp for something which was stuck at 4.1 and i think it required a 4.3... maybe 4.4? for setuid wrappers to work
<gchristensen> RHEL 6 uses Linux Kernel 2.6.32 and our glibc supports as ancient history as linux kernel 3.2
<copumpkin> wat, 2.6
<copumpkin> yay RHEL
<gchristensen> Its Enterprise
<copumpkin> impressive to be two major versions behind
<copumpkin> did 7 get onto 3 at least?
<gchristensen> 3.10
<copumpkin> amazing!
<copumpkin> that's new enough to have user namespaces
<gchristensen> this is so bad
<gchristensen> nix was supposed to rescue me from this tar pit!
<copumpkin> can you patchelf a global /lib glibc back into it so it'll run on rhel?
<copumpkin> or possibly set up an overlay that pulls in glibc from an older nixpkgs
<copumpkin> you'll have to build a lot of stuff though :/
<gchristensen> yeah I don't love the idea of having to maintain that patchset ...
<Dezgeg> well, I guess we could revert to glibc 2.25 if someone volunteers to dig up security patches for that
<gchristensen> I don't think that is fair
<gchristensen> unless we had #s showing a substantial user base are people on RHEL6 looking for a way out
<copumpkin> is there some build flag we can set on our glibc build to enable legacy support maybe?
<copumpkin> or did they just drop code from it
<Dezgeg> no, they dropped the legacy code
<Dezgeg> would be interesting to know how much code that was (and whether some of those features have been backported to rhel's frankenkernel)
<gchristensen> RHEL6 appears to lose all support in december 2018
<gchristensen> the unfortunate thing is the part of the stack I work in is inherently slow to migrate to shiny kernels that haven't been broken in for a decade
<copumpkin> a decade? we should wait for two decades just to be safe
<gchristensen> don't suggest it too loudly
<hl> nuke it from orbit, it's the only way to be sure
<gchristensen> wait, no, crap, 2020. RHEL6 will still be officially a thing until the end of 2020
<gchristensen> see y'all in 2030 when I'm upgrading to linux kernel 3.10.734
<copumpkin> lol
<dtzWill> lol
<Sonarpulse> bgamari: yes
<Sonarpulse> sorry for delayed response
<Sonarpulse> bgamari: also heh I finished updating https://github.com/NixOS/nixpkgs/pull/31292 but did not run nixborg befoe
<Sonarpulse> kicked off, now
mbrgm has quit [(Ping timeout: 248 seconds)]
mbrgm has joined joined #nixos-dev
<bgamari> Sonarpulse, thanks!
<bgamari> Sonarpulse, you aren't doing that now, are you?
<bgamari> if not I'll give it a try
<Sonarpulse> bgamari: doing what?
<Sonarpulse> building?
<Sonarpulse> I just kicked off the bot
<Sonarpulse> you can fetch it's builds
<Sonarpulse> but it rebases before buidling
<bgamari> the binutils wrapper
<bgamari> multi-arch fix
<Sonarpulse> oh that
<Sonarpulse> nah I hadn't started it
<Sonarpulse> I just looked in the man pages
<Sonarpulse> each utility has a like a different one ugh
<Sonarpulse> --arch
<Sonarpulse> --target
<Sonarpulse> -m
<bgamari> naturally
<Sonarpulse> it's a mess ugh
<Sonarpulse> at least everything that uses --target uses it the same way
<Sonarpulse> so hypothetically that could be added to all of them
* Sonarpulse and his upstream musings
<bgamari> Sonarpulse, well, it seems like it would be easy enough to make each of the wrappers pass a different flag, no?
<Sonarpulse> yeah
<Sonarpulse> just more work
<Sonarpulse> /
<Sonarpulse> based on the ranlib problem
<Sonarpulse> we might need no wrappers for strip, ar, ranlib, etc
<bgamari> which ranlib problem is this?
<Sonarpulse> the libc onen
<Sonarpulse> your cross libc discovery
<bgamari> I don't see why this means we need no wrapper
<Sonarpulse> well, *if* ranlib is being wrong
<Sonarpulse> and *if* it is somehow defaulting to the wrong target
<Sonarpulse> and *if* that causes the problem
<Sonarpulse> then it will need an --arch or similar wrapper too
<bgamari> well, in the case of ranlib I don't even see any way to set the architecture
<Sonarpulse> I wish a remember, but something I saw had all the options side by side
<Sonarpulse> I do remember things I didn't expect to care at least took an argument
<bgamari> I suspect ranlib doesn't care
<bgamari> afterall, I think the archive index format is platform independent
<bgamari> Sonarpulse, out of curiosity, is this multilib patch truly necessary for cross-compilation?
<Sonarpulse> no
<Sonarpulse> it is not
<Sonarpulse> that's why i felt bad
<Sonarpulse> now I've merged stuff which gives us more work
<bgamari> I see
* bgamari can't figure out how to get ld to print the default emulation
<bgamari> it seems you can set an environment variable to set the emulation as well
<bgamari> I wonder if that works for all binutils tools
<Sonarpulse> oo neat
<bgamari> both the name (LDEMULATION) and the documentation suggest that this only applies to ld
<bgamari> Sonarpulse, why is ld-wrapper.sh in cc-wrapper/?
<Sonarpulse> bgamari: well before bintools-wrapper PR
<Sonarpulse> it's one wrapper for both
<Sonarpulse> that's the way it was the last 14 years!
<bgamari> but that was merged, no?
<bgamari> oh, I guess not yet
<Sonarpulse> yeah
<Sonarpulse> that one I made dependent on stdenv-topo
<Sonarpulse> but I can do that
<bgamari> alright, I'm going to first try reverting the multi-arch patch for now
<bgamari> just tio try to get something work
<bgamari> ing
<Sonarpulse> sure
<Sonarpulse> deserved :)
<Sonarpulse> I might call it for tonight
<Sonarpulse> but next thing will be that
<bgamari> hmm
<bgamari> back to infinite recursion
<Sonarpulse> heh, ...great
<bgamari> debugging these things is a bear
<bgamari> alright, yeah, I think I'll let this sit for a bit
<bgamari> I was just able to get a native ARM image built
<Sonarpulse> sorry for all the complications
<Sonarpulse> that's cool
<bgamari> so the need for cross-compilation is somewhat lessened
<bgamari> quite alright
<bgamari> thanks for everything you are doing on this
<Sonarpulse> glad that's working, at least
<bgamari> and I would still like to contribute
<bgamari> but I may wait for the dust to settle a bit
<Sonarpulse> sure
Sonarpulse has quit [(Ping timeout: 255 seconds)]
jtojnar has quit [(Quit: jtojnar)]
vcunat has joined joined #nixos-dev
vcunat has quit [(Ping timeout: 240 seconds)]
vcunat has joined joined #nixos-dev
orivej has quit [(Ping timeout: 240 seconds)]
jtojnar has joined joined #nixos-dev
FRidh has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 268 seconds)]
FRidh has joined joined #nixos-dev
_ts_ has joined joined #nixos-dev
<jtojnar> vcunat: could you review the pull requests blocking GNOME 3.26? Or point me to someone who could? https://github.com/NixOS/nixpkgs/pull/29392#issuecomment-344473213
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined joined #nixos-dev
<vcunat> jtojnar: I'll try to find time for those that don't get reviewed soon. It seems you've done really lots of work on GNOME, and we certainly don't want to waste it.
orivej has joined joined #nixos-dev
FRidh has quit [(Ping timeout: 240 seconds)]
<Mic92> should I backport this as a whole? https://github.com/NixOS/nixpkgs/pull/31657 (crashes on startup)
FRidh has joined joined #nixos-dev
romildo has joined joined #nixos-dev
<jtojnar> vcunat: https://github.com/NixOS/nixpkgs/pull/28826 should not be controversial, analogous code is already used in other libraries like GStreamer, just want someone to double check the C code
<jtojnar> The other two, however, might be controversial, there might be better solutions or issues I am not aware of.
<gchristensen> jtojnar: OOPS! I thought I merged dleyna!
FRidh has quit [(Quit: Konversation terminated!)]
FRidh has joined joined #nixos-dev
<jtojnar> nope :)
<gchristensen> jtojnar: can you rebase on master?
<jtojnar> gchristensen: done
<gchristensen> let's see what borg thinks of it ...
<gchristensen> it thinks "graham, you can't type"
orivej has quit [(Ping timeout: 250 seconds)]
orivej has joined joined #nixos-dev
<gchristensen> jtojnar: any reason I shouldn't merge 28826 right now?
<jtojnar> I would prefer someone to go over the C code
<jtojnar> but since nobody reviewed it so far I do not think any more waiting will help
<jtojnar> gchristensen: unless you know of someone who would be able to review it, merging right away will have to do
<gchristensen> maybe having it merged will give someone the proper motivation to review it
<jtojnar> I also sent a PR upstream so maybe we will get review there someday
<jtojnar> gchristensen: why would changing glib show 0 rebuilds? https://github.com/NixOS/nixpkgs/pull/31683
<gchristensen> uhh
<LnL> evaluation error?
<gchristensen> shouldn't be ... I don't know ...
<gchristensen> jtojnar: I'm going to make a noop edit to your PR description to watch the check log.
<jtojnar> ok
<gchristensen> it could very well be an evaluation error that I'm not properly catching
romildo has quit [(Quit: Leaving)]
JosW has joined joined #nixos-dev
phreedom has quit [(Ping timeout: 258 seconds)]
<gchristensen> jtojnar: ok your PR just started checking.
<gchristensen> oops, sure enough, eval error
infinisil has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
infinisil has joined joined #nixos-dev
<gchristensen> jtojnar: would you mind opening bugs against grahamc/ofborg w.r.t. https://github.com/NixOS/nixpkgs/pull/31683#issuecomment-344609559
<vcunat> Well, so far I haven't bothered to have eval-error checking in the estimator.
<vcunat> IIRC the eval errors are shown on the (error) output, and I originally intended it for human usage.
<gchristensen> yeah, as part of that bug fix I'm going to stop using the script as it exists in the repo
<gchristensen> as it is, I calculate the drv list FAR too often and can easily cache the results _and_ catch the errors
<Dezgeg> remember to calculate the out list, not drv list :)
<gchristensen> right.
<gchristensen> I'll use the same thing the script uses, just apply it differently
<disasm> fpletz: tig cherry-pick doesn't use -x by default :( how do you get around that? do you just copy the commit hash from tig and manually run cherry-pick -x?
<vcunat> well, you can cache the list per commit hash
<vcunat> I planned to add that into the script, but haven't done it so far
<orivej> Dezgeg: are you sure it is possible for the out path to change while the drv path stays the same?
<vcunat> it might save something under half of the evaluations (the second commit - one from the PR will always be different)
<vcunat> anyway, it would be nice to contribute the improvements back to the script (in time)
<Dezgeg> yes, modifying a fixed-output derivation (like fetchurl) changes .drv but keeps the out the same
<vcunat> Dezgeg: that's the other way around
<Dezgeg> err, yes :P
<vcunat> I can only think of hash collisions
<vcunat> but I may be missing something - I'm not that sure what exactly goes as input to each hash
FRidh has quit [(Ping timeout: 250 seconds)]
<disasm> I'm going to merge this if borg builds it successfully: https://github.com/NixOS/nixpkgs/pull/31360 Looking at release notes, I think it makes sense to backport to 17.09, you agree vcunat?
<gchristensen> vcunat: yeah, and actually every new PR gets evaluated twice for ... reasons ... so it'll save a bunch of time there :P
<disasm> gchristensen: is there a command to get grahamcofborg to evaluate all the stuff it does automatically for a PR it hasn't been done on (like number of builds it affects, etc..)
<gchristensen> there is a secret / dirty workaround ...
<gchristensen> no command yet
<vcunat> gchristensen: you might also scrap the pure evaluation check, as the estimator will do the evaluation anyway
<gchristensen> but if a) the PR is rebased, or b) the PR description is edited, it'll re-evaluate
<gchristensen> vcunat: you mean "grahamcofborg-eval"?
<vcunat> gchristensen: I'm not sure - just something I saw in the CI box seemed so
<vcunat> gchristensen: the last sent link here shows a strange borg error
<gchristensen> oh?
<vcunat> it's like mixing up the two platforms
<gchristensen> cc LnL
<gchristensen> that is an issue with lnl's builder
<vcunat> oh, I see now
<vcunat> it just failed to ssh into the machine
<LnL> link?
<gchristensen> ideally that builder would just run on the directly, LnL https://github.com/NixOS/nixpkgs/pull/31360
<LnL> yeah maybe I should just move it
<vcunat> disasm: my release management starts with 18.03, but it's claimed to be bugfix-only update, so it seems OK (although not really required as I see no security fix)
<LnL> gchristensen: disabled it for now, not sure if I can fix it from here
<gchristensen> ok
<LnL> it's back online
Sonarpulse has joined joined #nixos-dev
orivej has quit [(Remote host closed the connection)]
orivej has joined joined #nixos-dev
<domenkozar> the string context is really really bad for secrets:
<vcunat> The whole design wasn't meant for secrets.
<vcunat> Maybe it will be better to create a few functions in lib to handle these things, so that people don't repeat the same mistakes and the code is better readable.
orivej_ has joined joined #nixos-dev
orivej has quit [(Ping timeout: 248 seconds)]
<domenkozar> vcunat: agreed
<disasm> 10.rebuild-darwin: 11-100 10.rebuild-linux: 101-500 -- that's fine to go straight to master, gith?
<disasm> right :)
<orivej_> disasm: most likely yes
orivej_ has quit [(Quit: orivej_)]
orivej has joined joined #nixos-dev
<orivej> Dezgeg: "modifying a fixed-output derivation (like fetchurl) changes .drv but keeps the out the same" - in fact this is correct :)
<orivej> A fixed-output derivation may have only one output, and the store path of that output is fixed by the name and the outputHash. But the path of .drv is computed as usual and changes whenever the Nix value of the derivation changes.
<orivej> And this is right, otherwise .drv would be violating the immutability of the store.
<vcunat> disasm: yes, I think so
<clever> orivej: the tree of hashes for .drv files ignores all fixed-output rules, and also, every .drv file is stored at the hash of its contents
<disasm> orivej: you think I should cherry-pick -x https://github.com/NixOS/nixpkgs/pull/31360 to 17.09? it's a maintenance update, but no security updates involved.
<orivej> clever: this is what I'm saying, because Dezgeg said to the contrary
<disasm> btw thanks for all the help and constructive criticism orivej, it's been a great learning experience
<orivej> disasm: That I don't know. But lsix said that he will backport this himself.
<gchristensen> yeah, orivej, you've been doing great work
<orivej> thank you!
vcunat has quit [(Ping timeout: 250 seconds)]
<copumpkin> given a fixed-output derivation path
<copumpkin> is there some way I can get the output hash?
<copumpkin> I guess I can instantiate, get the .drv, and parse it out of there
<copumpkin> nix-shell -p nixUnstable jq --command 'nix show-derivation $(nix-instantiate ...) | jq '"'"'.["/nix/store/c37mrmajlhp6j1530y8xhjnyz2yskp26-source.drv"].env.outputHash'"'"''
* copumpkin barfs
<copumpkin> I guess I need to instantiate it twice
<clever> those quotations!! lol
<Dezgeg> nix-store -q --binding outputHash $(nix-instantiate -A hello.src)
<clever> --binding, that ones new to me....
<clever> Dezgeg: nice, that simplifies this example: https://gist.github.com/cleverca22/5dbc9a06572cae84f716cce92e513694
JosW has quit [(Quit: Konversation terminated!)]
<orivej> nix-instantiate --eval -A hello.src.outputHash
<copumpkin> oh!
<copumpkin> duh, thanks :)
<copumpkin> build produced path '/nix/store/g7fqf192qhwdnnddr4wclvs61n2d7yb6-source' with sha256 hash '1mbsz125c9y7jsb3bm1n162a3w0qgdxg52178f3rwbmr914s9dpz'
<copumpkin> is there a machine-readable version of that output? :)
<clever> copumpkin: you can run "nix-store --query --hash" on the storepath i believe
<clever> and it should return the 1mb hash
<gchristensen> clever: do you have a link about scopedImport for setting NIX_PATH params?
<copumpkin> it tells me that the store path is not valid
<copumpkin> which I guess it isn't when I use --hash?
<clever> gchristensen: yeah
<clever> gchristensen: ive also heard that this only effects the search path for the private.nix and nothing that private.nix imports (its not recursive)
<Dezgeg> there's no solution besides grepping the 'build produced path' error: https://github.com/NixOS/nix/issues/1172
<clever> gchristensen: and to make it recursive, you have to overwrite import globally
<gchristensen> ack...!
<clever> gchristensen: replacing import with a wrapper, that does scopedImport and spreads the infection
<gchristensen> nice
<clever> which reminds me, *looks*
<copumpkin> Dezgeg: ouch :)
<copumpkin> okay
<copumpkin> Dezgeg: do you have magic output splitting code handy so I can just use yours?
<copumpkin> oh I see there's a linked PR
<Dezgeg> pkgs/common-updater/scripts/update-source-version
<Dezgeg> that doesn't use --hash but rather greps the hash mismatch message though
<clever> gchristensen: the reason a scopedImport setting __nixPath works, is because of https://github.com/NixOS/nix/blob/master/src/libexpr/parser.y#L380-L386
<gchristensen> nice, thank you clever
<clever> gchristensen: every instance of <nixpkgs> gets turned into (__findFile __nixPath "nixpkgs")
<clever> 2017-07-14 11:19:58< gchristensen> copumpkin: builtins = { foldr = foldl; };
<gchristensen> the devil
<clever> gchristensen: ah, and it was you that brought up that joke when this topic last came up
<clever> 2017-07-14 11:13:36< copumpkin> niksnut: I'm starting to think a more useful primitive is something like "deepScopedImport" might be easier to implement (with caching) and cover 90% of use cases (and all of mine)
<copumpkin> I still think that, fwiw
<copumpkin> :P
<clever> 2017-07-14 11:17:15< copumpkin> so one of the first combinators I wrote over scopedImport was a recursive thing that replaces a few functions all the way down an import chain
* clever heads to bed
<gchristensen> thank you clever :)
<clever> yep
<copumpkin> gchristensen: whatcha doing with scopedImport?
taktoa has quit [(Remote host closed the connection)]
<gchristensen> digging myself in to a hole, to get out of a different hole
<copumpkin> fun!
<gchristensen> I have 2 repos, both with pinned nixpkgs
<gchristensen> one imports the other and needs to override the pinned nixpkgs
<gchristensen> taking suggestions on how to handle this bucket of fun
orivej has quit [(Ping timeout: 248 seconds)]
<copumpkin> I'm setting NIX_REMOTE to nothing and my nix commands are still trying to connect to the daemon
<copumpkin> what else are they looking for when they try that?
FRidh[m] has quit [(Ping timeout: 276 seconds)]
FRidh[m] has joined joined #nixos-dev
<LnL> 1.12 automatically uses the daemon if the db is not writable IIRC
goibhniu1 has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 268 seconds)]
orivej has joined joined #nixos-dev
vcunat has joined joined #nixos-dev
<copumpkin> yeah
<domenkozar> if someone feels like reviewing some string vs path trickery
vcunat has quit [(Ping timeout: 250 seconds)]
taktoa has joined joined #nixos-dev
taktoa has quit [(Remote host closed the connection)]
_ts_ has quit [(Ping timeout: 255 seconds)]