<clever>
relative rpaths wont help for the initrd side of things, and only partialy help for the bootstrap, which still needs to be merged, which also breaks the relative paths
<clever>
jasom: and the initrd stuff uses that to omit un-used libs, and docs, from the initrd
<clever>
jasom: and use that to bootstrap the entire stdenv
<clever>
jasom: the bootstrap tools use this to create a single .tar.gz, that contains a fully working compiler toolchain, and nixpkgs will unpack that to yet another $out, and re-patchelf it once more
<clever>
jasom: so you can merge them into a single derivation, often omiting libs that arent needed, and docs
<clever>
jasom: in both cases, you are taking the ELF binaries, and libraries from dozens of derivations, copying them to a new $out/{bin,lib}, and then re-running patchelf to fix the RPATH's
<clever>
jasom: have you seen what the bootstrap and initrd stuff does?
<clever>
which broke the sandboxing in chromium for instance
<clever>
copumpkin: so even if i run a setuid root program, its not root root
<clever>
copumpkin: ah, same as the uid namespaces and mapping i saw in nix's build.cc recently
<clever>
copumpkin: ah, that must be some new features, but what stops me from creating a namespace where i control the contents of /etc/shadow?
<clever>
jasom: most of that patching is done at compile time, once its compiled, the length of the string is encoded in weird places and it cant easily be re-patched
<clever>
copumpkin: from what ive seen before, you have to specialy configure things like chroots for users, and make a special root where they own /nix
<clever>
but an admin would probably have to set that up for you
<clever>
it is flagged as being supported on 32bit, but has no pre-built binaries available
<clever>
SuprDewd: i discovered this a month ago, when i tried to do a 32bit install on my laptop
<clever>
SuprDewd: chromium for example, only has 64bit builds on hydra, and only for the stable channel
<clever>
SuprDewd: and then you cant tell which one is the right one
<clever>
SuprDewd: ah, i think the problem is that youtube-dl is an alias, to one of the pythonPackages variants, and the tools are trying to hide the duplicate
<clever>
SuprDewd: but if you just try to use pkgs.youtube-dl, what happens?
<clever>
SuprDewd: what problem are you having when you try to use pkgs.youtube-dl?
<clever>
SuprDewd: pkgs.youtube-dl is in hydra, but some of the ones under pythonPackages arent
<clever>
SuprDewd: i had the same problem, i was installing youtube-dl from the wrong attribute
<clever>
SuprDewd: it could just be that your accessing packages that hydra doesnt build, do you have thinks like youtube-dl?
<clever>
SuprDewd: what does nix-channel --list say?
<clever>
dd directly to the root of the usb device
<clever>
NixkorN: so you dont need any special tools to make it boot on usb
<clever>
NixkorN: the iso has both a cdrom bootloader, and grub in it already, complete with an MBR partition table
<clever>
so, why do i have a /run/current-system/sw/lib folder?
<clever>
gchristensen: installing curl to fix the shell script, also fixed the so, and nobody put the 2 things together, they dont think to test again until they have ran the shell sript
<clever>
gchristensen: but a major lesson, that nix prevents, is side-effects
<clever>
so it dereferences a null pointer
<clever>
and then assumes nobody will ever not have it
<clever>
i believe it was using dlopen on libcurl
<clever>
as for the segfault, its not listing curl in ldd either
<clever>
gchristensen: none of those users realized, installing curl (to fix the shell script) also fixed the libflashplayer.so file
<clever>
even though i did exactly the same thing the shell script does!
<clever>
gchristensen: but, firefox segfaults any time i attempt to load flash, and googling around, i found users that mysteriously made it work by running the shell script
<clever>
gchristensen: so i just wget it and manualy install it, simple, right?
<clever>
the shell script for flash uses curl to download a tar, then unpacks the .so
<clever>
gchristensen: i sucessfully got my system going, without any libcurl present, then i tried to install flash
<clever>
i had wget, why do i need curl in my closure?
<clever>
i was on gentoo, and i decided to build firefox without the built in error reporting tool (it depended on curl)
<clever>
and that reminds me of a bug i had years ago
<clever>
yeah, those could become a target
<clever>
ah, nice
<clever>
but thats mostly ran in a sandbox with no network, and all of the input data is controled tightly
<clever>
yeah, in the non-fixedoutput stuff, it could potentialy do more harm
<clever>
gchristensen: excluding dirtycow type exploits in the kernel,i cant see much in curl being able to escape a fixed-output derivation
<clever>
JonReed: on its own, that would probably do the same thing as just booting with boot.debug1devices in the kernel args
<clever>
JonReed: and the build-vm options wont use a filesystem for the rootfs, so testing luks woudl be tricky
<clever>
JonReed: and boot.debug1mounts will shell after it mounts everything
<clever>
JonReed: and there is boot.shell_on_fail which lets you gain a shell upon fatal errors
<clever>
JonReed: you could also insert the fail command into your script, to manualy open a shell
<clever>
then it increments the number at the end to avoid a collision
<clever>
but nix doesnt know how to umount, and gets confused while trying to rm -rf, causing it to leave NIX_BUILD_TOP behind
<clever>
lonokhov: which allowed me to perform fuse mounts inside NIX_BUILD_TOP!!
<clever>
lonokhov: the only time ive managed to break this, is when the build was not running in a sandbox, and i was able to execute a fuse setuid program
<clever>
yep
<clever>
$TEMP and $TMP have also been modified, so you use the dir nix-daemon is going to wipe
<clever>
lonokhov: the stdenv will typicaly drop you in $NIX_BUILD_TOP/foo, where foo is a name coming from $src
<clever>
lonokhov: and the nix file that produced it is in the same directory
<clever>
seku: the code i just linked from github solves similar 64/32 bit problems, it makes linux lie to the builder, and claim its a 32bit only kernel
<clever>
seku: yeah, it detected an armv7 cpu, so its doing a v7 arm build