<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
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.
<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
<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>
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
<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: ive also heard that this only effects the search path for the private.nix and nothing that private.nix imports (its not recursive)
<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