<puck>
samueldr: i'd really like to somehow be able to configure the /bin/sh used inside a specific derivation, instead of having it be provided ambiently, tbh :p
<samueldr>
I'd like it to be a property of the derivation itself
<puck>
yeah
<samueldr>
in a play thing I was doing I had to "root" all my derivations with a custom "mkDerivation" that initially looks at /bin/sh and fails if it exists
<samueldr>
since that ambient impurity is not part of the hash
<puck>
yeah
<samueldr>
even though it can be disabled at the CLI!
<puck>
it's a really interesting impurity
<puck>
oh, wait, is it not privileged?
<samueldr>
maybe my user is privileged
<puck>
pretty sure sandbox paths is privileged to configure :p
<samueldr>
trustedUsers contains @wheel
<samueldr>
and I'm feeling wheely great
<samueldr>
but still, the fact that a busybox bug could make reproducibility fail arbitrarily is not great
<gchristensen>
nice to make it clear that it is a community effort and not a one person team, thank you so much cole-h
<puck>
samueldr: i'm unsure as to why the /bin/sh stuff would leak, but having control over it would be very nice; i'll provide my own shell where necessary, tyvm etc etc :p
<cole-h>
And with that, ofborg redeploy is finished!
<puck>
samueldr: "would leak" as in cause the wrong shell to happen (i guess busybox sh has different behavior execing into non-runnable shebang scripts?)
<cole-h>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 432
<samueldr>
puck: in my "just for fun" thing I was trying to see how hard it would be to start without any sh-like shell
<samueldr>
ah, I see what you mean
<samueldr>
I need the gnu libc exec man page stat!
<{^_^}>
nix#4358 (by puckipedia, 11 weeks ago, closed): Change builder argv[0] to full path, instead of only basename
<samueldr>
>> If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)
<puck>
ahahah. and ENOEXEC is what responds if the shebang is of wrong arch
<samueldr>
so if #!/.../armv7l-bash/bin/sh fails to exec
<samueldr>
that'll /bin/sh !
<puck>
hahahah
<samueldr>
wicked, right?
<puck>
that was basically what i guessed indeed :p
<samueldr>
just like the time perl scripts were ran through /bin/sh because the kernel refused to read our shebangs
<rmcgibbo[m]>
iiuc the kernel limits on shebang length are ridiculously short.
<puck>
samueldr: so i actually have a small experiment where i compile a shell without /bin/sh
<samueldr>
rmcgibbo[m]: no
<rmcgibbo[m]>
256 chars is not enough for everyone
<samueldr>
:)
<samueldr>
they are pretty accepting, but they broke userland accidentally
<gchristensen>
luckily modern programming environments like Perl work around it
<samueldr>
the issue is that instead of continuing on with a truncated shebang, it failed if it had to truncate
<puck>
samueldr: i took a pre-generated mksh, looked at its build script, and wrote a small Nix script that builds a derivation that builds the entirety in a few commands, abusing builtins.placeholder to output the .o files into the store, and linking it into a binary
<samueldr>
puck: my sh-free "fun" play thing starts with execline
<puck>
samueldr: right, but how do you get execline into your env? :p
<samueldr>
that was something to be solved, but I was actually thinking of doing it like you said
<rmcgibbo[m]>
"128 bytes should be enough for everyone" i guess
<samueldr>
I was setting my starting point as "to be solved: bootstrap this small binary seed"
<samueldr>
which consists IIRC in only toybox+execline
<samueldr>
oh, and tcc
<puck>
tcc is tricky to bootstrap anything modern tbh
<samueldr>
I wasn't actually trying to bootstrap a full linux, just playing around :)
<puck>
i got a subset of musl to compile with it though, probably enough to get an older gcc up
<puck>
but then just went and grabbed a compiler from musl.cc and patched its specfile to work under the nix env
<puck>
still need lots of shell to be able to configure stuff though :(
<{^_^}>
onetrueawk/awk#74 (by Ypnose, 1 year ago, closed): New release
<siraben>
what kind of response is "We don't do releases. Anyone wanting the code should simply clone the repo and run make. Preferably, they should also run the tests as described in the README.md file. Closing this issue."
* puck
shrugs
<puck>
the main branch should be functional always either way :p
<siraben>
without releases we're left to guess when incompatible changes arise
<puck>
it's an awk
<puck>
and there is a new maintainer anyways since recently
<siraben>
sure but so is GNU awk and they have releases
BaughnLogBot has quit [Read error: Connection reset by peer]
BaughnLogBot has joined #nixos-dev
orivej has joined #nixos-dev
jonringer has joined #nixos-dev
<rmcgibbo[m]>
V: It adds these inline "annotations", they're not exactly the same as reviews.
<V>
seems preferable. less obnoxious
<rmcgibbo[m]>
They do show up on the "Files changed" tab, but unlike a "Review" they don't show up in the main thread of comments and they can't be responded to, yeah.
<rmcgibbo[m]>
V: Anyways, here's the integration issue I guess: https://github.com/NixOS/ofborg/issues/552. I'm not sure what the next steps would be, but at this point they seem more organizational that technical?
<{^_^}>
ofborg#552 (by cole-h, 1 day ago, open): Investigate integration of nixpkgs-hammering
rmcgibbo has joined #nixos-dev
rmcgibbo has left #nixos-dev [#nixos-dev]
julm has joined #nixos-dev
<samueldr>
siraben: you may need to do a nix derivation, as in a barebones derivation, and add wha you want in, but it will come with absolutely no bell nor any whistle
<samueldr>
(maybe there is a more barebones derivation in Nixpkgs, but I don't know)