<gchristensen>
PERL5LIB="/nix/store/7yf3fh95ljf90nnw6cv70dry5jvqin0l-perl-5.28.1/lib/perl5/site_perl:/nix/store/w322q6nfg2gar4h86yh5l3p6vxb8ik1r-perl5.28.1-File-Next-1.16/lib/perl5/site_perl..." in the env-vars of the build
<gchristensen>
omg stdenv knows perl
lassulus has quit [Ping timeout: 250 seconds]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
lassulus has joined #nixos-dev
<LnL>
gchristensen: are you or somebody else still looking at a generic solution?
<gchristensen>
I stopped looking at a generic solution and started thinking about lessgeneric solutions
<gchristensen>
I think using buildEnv at choice points is a fine choice -- we already do it for many packages with many dependencies
<LnL>
the custom python builder I wrote does something similar, but links runtime dependencies to the output instead
<gchristensen>
cool, that sounds good
asymmetric has joined #nixos-dev
<gchristensen>
samueldr: should we roll back the channels or something?
asymmetric has quit [Remote host closed the connection]
asymmetric has joined #nixos-dev
Profpatsch has quit [Quit: WeeChat 0.4.3]
Profpatsch has joined #nixos-dev
<gchristensen>
the channel URLs are being rolled back
<Taneb>
If the URLs are being rolled back I think it makes sense to roll back the channels correspondingly
<gchristensen>
that does roll back (most) channels already
<gchristensen>
but not nixpkgs-channels, which we shouldn't force-push to
init_6 has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
asymmetric has quit [Quit: Leaving]
<clever>
gchristensen: it doesnt, and thats part of the problem
<gchristensen>
clever: eh?
<clever>
gchristensen: ive strace'd hydra-notify, and a decent chunk of its startup time is searching ~10 different places for every single module it imports
<clever>
that buildEnv isnt good enough
<gchristensen>
ah
<clever>
there needs to be exactly 1 path in the PERL5LIB
<gchristensen>
that'll be tough to fix, requires fixing stdenv
<clever>
gchristensen: is it the stdenv, or a setup hook, that is doing it?
<clever>
gchristensen: its a setup hook, so thats easier to modify, somewhat
<clever>
cant use a buildEnv, but you can build the env in $out
<gchristensen>
gotcha
<clever>
addEnvHooks modifies the stdenv some, and will then run addPerlLibPath for every input, and all propagating inputs (which cant be known at nix time)
<clever>
you would need to just set PERL5LIB to something like $out/lib/perl, and then lndir things into it
<clever>
would still be a mass-rebuild, i expect a lot of things to depend on perl
grw has quit [Ping timeout: 252 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
drakonis has quit [Quit: WeeChat 2.3]
<samueldr>
gchristensen: yeah, I wasn't sure about rolling back, I think we'll need to post-morten the whoe situation and see what should and could have been done?
<gchristensen>
I agree
<samueldr>
among those I'm thinking we'll maybe need to do basic tests (e.g. switch-to-configuration) for all upstream kernels?
<gchristensen>
lots of interesting stuff could come out of such a discussion
<samueldr>
(hopefully to never be needed again ever
<gchristensen>
let's ask 5-why's and get all rub-magic-salt-on-itey
<gchristensen>
"Also, if you have a CODEOWNERS file in your repository, a draft pull request will suppress notifications to those reviewers until it is marked as ready for review."
<samueldr>
nice
<gchristensen>
its a shame you can't mark as draft for a move-to-staging
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
<LnL>
so, what's the perl status?
<clever>
LnL: i'm thinking of patching the perl setup hook to handle things better
<LnL>
yeah same, I can look at it this weekend if nobody else is working on it
<gchristensen>
please do
<gchristensen>
a kernel upsteram update is the author of the offending patch agrees it should be reverted
<gchristensen>
but we should fix perl anyway
<clever>
and fixing perl will also improve performance of hydra
<clever>
we keep getting a backlog of 2k events in the notification channel
<clever>
which delays PR merging
<gchristensen>
hydra is already somewhat fixed
<gchristensen>
because it only searches 10 places, not 400
<clever>
gchristensen: hmmm, i notice hydra is using wrapProgram, rather then the #! line
<clever>
so hydra itself cant run into #! problems, just slow module loading
<clever>
use lib /nix/store/bsllvmy9vjikanbxwvmf8gbmzw7g50s9-perl-5.28.1/lib/perl5/site_perl:/nix/store/bsllvmy9vjikanbxwvmf8gbmzw7g50s9-perl-5.28.1/lib/perl5/site_perl:/nix/store/bsllvmy9vjikanbxwvmf8gbmzw7g50s9-perl-5.28.1/lib/perl5/site_perl:/nix/store/24mvl35rs6fvmlrghwzll7dcd1c6y0wm-perl5.28.1-gettext-1.07/lib/perl5/site_perl;
<{^_^}>
#55786 (by cleverca22, 1 minute ago, open): improve perl shebang lines by switching to `use lib ...;`
<gchristensen>
nice!
<LnL>
that if tho
<clever>
LnL: yeah, thats ugly
<gchristensen>
oh, haha, yeah, better to patch TestSimple
<LnL>
so q: is use lib necessary during the build if PERL5LIB is set?
<gchristensen>
env vars are too limiting for a lib set like bibir has
<clever>
LnL: probably not, but this patching of the source, is what persists to the scripts being installed to $out
<clever>
so this is what causes the $out files to be patched enough to survive at runtime
<LnL>
sure, but that can happen during fixup which is after the tests
<clever>
yeah, i could try moving it down more...
<clever>
i'll just take the entire while loop and move it down a bit...
<gchristensen>
if the tests expect to be able to use the libs the package requires, the tests will fail if it depends upon too many packages
<LnL>
also preFixupPhases+=" perlFixupPhase" is much nicer than the way it replaces preConfigure
<emily>
can't you just put the use lib on the same line as the next line
<clever>
that reminds me, of the time i tried to apply a phase based override to rp-pppoe
<emily>
rather than having an extra newline
<emily>
as a cheap and simple fix
<clever>
then i discovered, rp-pppoe, isnt even stdenv
<clever>
emily: more difficult with sed, would maybe need ed, to insert something at the start of line 2
<clever>
gchristensen: 13 pages have passed, so this may work...
<ekleog>
isn't it just 2s/^/foo/
<emily>
i feel like slightly more advanced text manipulation is perhaps still simpler than patching a test library to offset all the line numbers by one
<gchristensen>
LnL: what am I missing? we know the env var isn't sufficient :/
<ekleog>
after testing: yes, `sed '2s/^/foo'` inserts `foo` at the start of line 2
<clever>
emily: patching it after testing is simpler still
<ekleog>
erhm, `sed '2s/^/foo/'`
<tilpner>
sed '2ifoo' does too
<clever>
i think inserting it into the start of line 2 is worse, because you then have 30kb of "use lib" followed by 1 "line" of code youll never notice
<clever>
and that could make reading the script imposible
<ekleog>
tilpner: TIL the `i` command :)
<LnL>
gchristensen: we do?
<ekleog>
clever: add an inline comment that reminds the reader that there's something after all the `use lib`
<gchristensen>
yes, we have cases where the value of the env var would be much longer than the maximum value of an env var
* ekleog
doesn't know what the original problem is, just proposes solutions
<gchristensen>
like biber's perl5lib value would be way too long
<LnL>
-_-
<emily>
$code='...contents of first line...'; use lib ...; eval $code
<emily>
any questions
<clever>
ekleog: if the #! line is over 127 chars, the kernel refuses to execute the script, i think
<samueldr>
it's uh, more complicated than that
<gchristensen>
emily: first line of code includes 's?
<ekleog>
oh we're still on this problem? wasn't Kees OK to have a revert that matches our expectations?
<emily>
gchristensen: i think perl supports arbitrary delimiters with qq strings so you can just keep generating 128-bit UUIDs until you find one that doesn't clash (very important to handle that case)
<samueldr>
though I think we're on cleanup detail of perl stuff since it'd be a good idea anyway
<gchristensen>
samueldr: and for the people who successfully switched to a generatino with these busted kernels :)
<ekleog>
right, that's nice :)
<samueldr>
ooh, that's effectively nice
<ekleog>
then I'll stop pushing for hackish solutions, if it's for a cleanup
<LnL>
yeah also, other platforms like darwin have different limits aparently ack has been broken for a long time
<clever>
LnL: from what ive heard, the darwin kernel doesnt even support #!?
<clever>
LnL: and its handled by the libc?
<LnL>
could be, the whole libSystem thing is a bit of a mess
<clever>
i heard about that, because #! scripts dont work if ran in certain ways
<samueldr>
even within linux it's hard™
<samueldr>
e.g. the regression returns NOEXEC, fine, don't execute
drakonis has joined #nixos-dev
<clever>
bash does cheat, and will bash scripts that entirely lack a #!
<samueldr>
except execve from the libc will try to run the file as a /bin/sh script on noexec
<LnL>
not sure if it's still the case but scripts are not allowed, only binaries
<clever>
samueldr: i thought that was a bash level feature, but it could be libc as well?
<samueldr>
clever: I think it could be both
<samueldr>
bash had code to check failures near
<samueldr>
but man 3 execve is quite explicit
<clever>
c2d ~ # man 3 execve
<clever>
No entry for execve in section 3 of the manual
<samueldr>
so linux peeps thought "we're making it stop execute" but in actuality it was "userspace ends up executing it in the weirdest way!"
<clever>
ive only got a 2 variant of it
<samueldr>
I think it should be in a libc output
<samueldr>
but haven't tracked it yet, I was using "the google" to find it
<samueldr>
(not on my workstation) bash *also* has some code to handle shebangs on failure
<clever>
samueldr: the aux-vector also comes into play, just after exec
<samueldr>
so I'm thinking it's the common way to handle ENOEXEC, which makes me weary that the error code is also wrong assuming one wanted to truncate there :/