<gchristensen>
let's make /bin/sh on NixOS a really crappy one
<gchristensen>
(ie: not featureful like bash)
<etu>
dash!
<Profpatsch>
dash is a good solution, yes. But it might end in chaos. Is an extremely intrusive change, because lots of downstream people are probably already depending on implicit features of NixOS /bin/sh.
<gchristensen>
yeah. it'd be worth looking at how Debian made the switch
<gchristensen>
it'd be wicked hard for sure
<niksnut>
yeah, it's a good way to break everybody's scripts
<niksnut>
so let's not :-)
<gchristensen>
:D
<gchristensen>
I had an annoying fixed-output build failure because /bin/sh 's echo on macOS inside a single-user nix install's nix-shell doesn't support -n
<samueldr>
timokau[m]: running took almost 5 hours on that speed demon, here's the log; can I let you analyze and see if it gives the same errors? I'm running it again now to see if the same issues arise https://gist.github.com/9d1e41821402e447b33616e364ed58ce
<Profpatsch>
gchristensen: But exactly that would happen to all our users if we moved to dash …
<gchristensen>
right, 4/4 of my builds would have failed instead of 1/4 builds (and I wouldn't have even had 4/4 fail because I wouldn't have been tricked in to thinking -n worked locally)
<timokau[m]>
samueldr: Wow, thanks! That is the exact same set of errors, looks very promising. Especially if its reliable.
<timokau[m]>
Are you using multithreading? Even on a older core duo, 5h seems a bit excessive
<samueldr>
only two cores
<samueldr>
and yes
<samueldr>
both were pegged
<samueldr>
probably thermal throttling
<timokau[m]>
Okay makes sense I guess. Takes around 1h on my 4 cores @ 3.2GhZ and should scale pretty much linearly
<samueldr>
I say only probably because I didn't look at the speed values
<samueldr>
but the temps values were ~95°C
<samueldr>
it has terrible thermals
<timokau[m]>
samueldr: I'm currently testing sage in a loop on my laptop as well in hopes of reproducing something, but I haven't hit an issue yet
<samueldr>
I'm thinking that if I want to use it as a feature-less CPU to repro things, that I might want to rip it from its laptop chassis... it already lacks a screen anyway
<samueldr>
timokau[m]: since at first run it failed, I'm hopeful, in ~5 hours we probably will know
<timokau[m]>
Usage is `nix-rebuild sage.tests` in a nixpkgs checkout
<samueldr>
oh, I didn't find in the ~10s I took how to run only the tests :)
<samueldr>
otherwise I'd have --check'd the build
<timokau[m]>
Yeah its a bit of an annoying consequence of wrappers
<samueldr>
though that's a lovely hack timokau[m] :)
<timokau[m]>
I use the nix-rebuild script instead of `--check` because `--check` doesn't work on the first build, doesn't keep individual logs and IIRC gives an exit code of 1 if the build succeeded but wasn't reproducible
<timokau[m]>
So the script is more convenient for hunting down transient errors
<timokau[m]>
samueldr: Do you have nixos running on that machine or some other distro?
<samueldr>
NixOS
<timokau[m]>
samueldr: Okay. I ask because it may be useful to try to reproduce this with sage's own build system, but that is kind of a pain on nixos. I have used it in the past with `buildFHSUserEnv`, but it always had some issues (problems with compilers/stdlibs etc)
<samueldr>
though AFAIUI virtualization would show the same issues, meaning that it'd be fine in a VM on _that_ machine
<timokau[m]>
Also that would probably take forever anyways, since it builds up all the dependencies from scratch. I think that takes ~4h even on my desktop
<samueldr>
(and thankfully it has VT-x through a bios mod)
<samueldr>
I wonder if a full sage build on that platform would exhibit the same issues, rather than a build from whatever hydra machine running the tests on that platform
jtojnar has joined #nixos-dev
<timokau[m]>
samueldr: Good idea. sage itself is defined in `sagelib.nix`. Changing anything in `sage-src.nix` will force a rebuild of all components
<samueldr>
first I'm running the tests again to see how they might differ
ajs124 has left #nixos-dev [#nixos-dev]
ajs124 has joined #nixos-dev
<timokau[m]>
samueldr: And the tests take the longest to build, sagelib takes 20-30 mins on my machine and doesn't scale as well on multiple cpus, so probably shouldn't take that long on your laptop
<samueldr>
ah, good to know (still checking if failures are stable as they are)
<timokau[m]>
samueldr: Yeah thats a good idea. Feel free to send me a private message when you have news, we probably shouldn't monopolize -dev for this issue :) Won't be available in 5hrs though
<samueldr>
noted
<gchristensen>
should nix-community be part of search.nix.gsc.io?
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 244 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
<gchristensen>
opensuse might have a GCC-repro patch for us
<Profpatsch>
Hm, why does `derivation { …; builder = "/bin/sh" }` work but `derivation { …; builder = /bin/sh; }` doesn’t?
<gchristensen>
"/bin/sh" is a sandbox-path
<Profpatsch>
But it looks like sh is moved to the store.
<Profpatsch>
And also referenced multiple times in the .drv file
drakonis has joined #nixos-dev
<gchristensen>
you mean if builder = /bin/sh ?
<Profpatsch>
yeah
<gchristensen>
hmm it might have to do with some POLA enforcement, that you have to produce proof you know how to construct /bin/sh before you can refer to it by path
<Profpatsch>
gchristensen: Was that an answer to why "/bin/sh" works?
<gchristensen>
yeah
<Profpatsch>
I don’t understand that.
<Profpatsch>
Is “builder is a string” special cased?
<gchristensen>
no
<gchristensen>
"/bin/sh" is included in the "sandbox-paths" setting, so the Nix daemon, when setting up the chroot includes /bin/sh in the build sandbox
<gchristensen>
but when it does that, it examines /bin/sh to see if it in the nix store, and yes,
<Profpatsch>
Ah!
<gchristensen>
all of its runtime dependencies
<Profpatsch>
“Depending on how Nix was built, the default value for this option may be empty or provide /bin/sh as a bind-mount of bash”
<Profpatsch>
So I’ve used the one special case :P
<Profpatsch>
Why not use a statically built sh tho …
<{^_^}>
patchelf#123 (by lheckemann, 1 year ago, merged): Allow multiple filenames to patch
<clever>
aszlig: had no issues packaging gn, but gn needs a file called .gn, not BUILD.gn, and thats made by depot-tools, which is having trouble fetching things purely
<clever>
aszlig: i'm guessing chromium may also use depot-tools normally, so how does nixpkgs fetch chromium source?
drakonis_ has joined #nixos-dev
<makefu>
infinisil: i've added the links to the issues and changes to the reddit thread
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 259 seconds]
<aszlig>
clever: they don't use depot-tools but fetch the source tarball
<aszlig>
s/they/in nixpkgs we/
<clever>
aszlig: do you know if a source for electron+chromium exists?
<aszlig>
clever: no idea, chromium has been several years for me since i was involved with anything related
<clever>
and it takes 3+ hours to process on my laptop
<clever>
aszlig: hmmm, looking at what `gclient config` did, all it did was create a `.gclient` file, which refers to the electron repo, and the DEPS file in it
<clever>
and i'm guessing it will recursively chase the DEPS files on each repo