2016-11-24

<clever> signal4: https://github.com/cleverca22/nix-tests/blob/master/config-debug.nix but at nixpkgs.config.packageOverrides
<clever> signal4: if you want it to affect nixos-rebuild, then it must go into the nixpkgs.config.packageOverrides of configuration.nix
<clever> you want to override stdenv, and modify the mkDerivation function
<clever> yeah, that should work better
<clever> some packages ignore CFLAGS or set it again, NIX_CFLAGS_COMPILE would have more effect
<clever> so the gcc one is more flexible, not sure why everybody else went the other route
<clever> and then the stdenv will parse buildInputs and build up NIX_CFLAGS
<clever> with gcc, the libs are put into $NIX_CFLAGS and $NIX_LDFLAGS, which the gcc wrapper will append to the command lines
<clever> with ghc and r, the libs are embeded into the shell script
<clever> ixxie: and it then concats those paths together, and embeds them into a bash script that passes them to chromium
<clever> ixxie: the enabled attribute in this file is a list of enabled plugins, which will depend on the options setup in the nixpkgs config
<clever> ixxie: and firefox, which obeys the same flash setting
<clever> ixxie: it now has options to enable/disable chrome and flash
<clever> ixxie: actively editing an example in https://gist.github.com/cleverca22/b38d3fab623c0288fbdea0d77999cc39
<clever> hyper_ch: is this from a cd or normal install?
<clever> hyper_ch: ah, thats a bit odd
<clever> hyper_ch: sudo gives it root
<clever> hyper_ch: nix-collect-garbage

2016-11-23

<clever> nix wont gc the resulting foo until you delete (or move) that symlink
<clever> greymalkin: this will build foo, and create a foo symlink in the current directory, that acts as a root
<clever> greymalkin: the simplest way to root something, nix-build '<nixpkgs>' -A foo -o foo
<clever> copumpkin: except /usr/bin will break on all nixos machines, while relative vs absolute will only break if things got moved
<clever> yep, line 111 of the file i just linked, nuke-refs -e $out $i
<clever> i think they use nukeReferences to blow all of them away
<clever> both the bootstrap and initrd stuff basicaly ignore all of the other paths
<clever> yeah
<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: there is a related issue i had recently, one sc
<clever> yeah
<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> pikajude: heh
<clever> releaseTools = callPackage ../build-support/release/default.nix { };
<clever> pikajude: looking
<clever> pikajude: got a link to that package on github?
<clever> pikajude: and you cant just use stdenvNoCC ?
<clever> unzip gives the unpackPhase zip support, and you can already see what cmake does
<clever> vdemeester: which allows buildInputs to alter the env
<clever> vdemeester: for every buildInput, nix will source /nix/store/foo-cmake/nix-support/setup-hook into the stdenv
<clever> vdemeester: dontUseCmakeConfigure = true; from line 61
<clever> it even has libvlc???, why!
<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> JonReed: looks like you can make it drop into a shell just before postDeviceCommands: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L184-L187
<clever> JonReed: what are you trying to do in the initrd?, and have you read stage-1.sh?
<clever> ixxie: so now i just imports = [ ./vim.nix ]; and its fully configured
<clever> ixxie: this adds a variation of vim to systemPackages, and sets things up to use vim by default
<clever> and you can also set other stuff, one sec
<clever> yeah
<clever> ixxie: and then do imports = [ ./seta.nix ./setb.nix ];
<clever> ixxie: just make several files like configuration.nix, that each have { pkgs, ... }: { environment.systemPackages = [ ... ]; }
<clever> ixxie: but imports might be better
<clever> ixxie: let foo = [ ... ]; bar = [ ... ]; in { environment.systemPackages = foo ++ bar; }
<clever> qknight: and for reference, a more active channel: http://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.rustc.x86_64-linux
<clever> bbl
<clever> and thats where the hash comes from
<clever> though if $src is a raw directory (which hydra is probably doing via fetchgit), it will just cp -r
<clever> this code will compare the listing from before tar -x, and after, and if it only made 1 directory, $sourceRoot becomes that dir
<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> lonokhov: this shows the raw env variables, setup by nix, before stdenv gets loaded: https://github.com/cleverca22/nix-tests/blob/master/bare-env.txt
<clever> lonokhov: NIX_BUILD_TOP should omit the hash, try echoing it from the build script to confirm
<clever> lonokhov: ah, its going to be /tmp/nix-build-${name}, so your name might be a bit long
<clever> and nix-daemon will clean it up for you
<clever> lonokhov: $NIX_BUILD_TOP is a fairly short path in /tmp
<clever> lonokhov: also, the /tmp/nix-build folder shouldnt be too long
<clever> lonokhov: looks like there is a dedicated failureHook
<clever> lonokhov: what are you trying to do?
<clever> and it will always turn into a different beast every time
<clever> it was gentoo to start with, but that distro has a tendency to mutate and evolve over the lifetime of an install
<clever> nope, it had a bunch of non-nix junk in it
<clever> /usr/local/share/man:/usr/share/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.3/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.24/man:/usr/lib64/php5.5/man/
<clever> i believe MANPATH was entirely unset
<clever> id file a bug against the installer
<clever> and its using the man from the host, not nix
<clever> and now --help works
<clever> clever@c2d ~ $ export MANPATH=/home/clever/.nix-profile/share/man/
<clever> shanemikel: this command put man pages into ~/.nix-profile/share/man
<clever> clever@c2d ~ $ nix-env -iA nixpkgs.nix.man

2016-11-22

<clever> i either type that into nix-build -E, or i have a second nix file with that in it
<clever> with import <nixpkgs> {}; callPackage ./foo.nix {}
<clever> mpickering: so it cant delete ghcjs until you remove shell.out, then nix-collect-garbage will do its job
<clever> mpickering: what does this output? nix-store --query --roots /nix/store/9swwjjdxgs47858m7ry031lbpw58mqk7-ghcjs-0.2.0
<clever> mpickering: there are tools you must use when deleting things
<clever> mpickering: thats still the wrong answer, nix will get very upset if you do
<clever> mpickering: can you pastebin the output of "du --max=1 -h /nix/store | sort -h" ?
<clever> mpickering: you should still have a nix-collect-garbage program in $PATH
<clever> mpickering: there is nix-collect-garbage to let it clean up unused things automaticaly
<clever> greymalkin: i would try patching the program, but runInLinuxVM can also be used
<clever> greymalkin: and it wouldnt work
<clever> but /usr and /lib are still read-only
<clever> buildFHSEnv will create a tree of symlinks that simulate /usr and /lib, and chroot automaticaly when you run it
<clever> haskell still gives me trouble sometimes
<clever> not sure what that option is for either
<clever> the kernel lacks flags to set v6 / v7 thru that personality api
<clever> its setting a PER_LINUX32 flag
<clever> which gives me an idea
<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
<clever> even though i asked for v6
<clever> LnL: and the build is already poisoned, bash is doing -DCONF_HOSTTYPE='"armv7l"' in a v6 build
<clever> seku: i havent seen any option to enable it, but i did recently notice wayland was in the closure of kde
<clever> then it just wont use the sandbox for the entire set of jobs
<clever> another option is to just nix-build --option build-use-sandbox false
<clever> Baughn: nix.conf build-use-chroot = relaxed, and __noChroot = 1; i believe
<clever> Baughn: it has to be made optional in nix.conf, and a special flag has to be set in the derivation
<clever> that would allow testing on my older pi's
<clever> LnL: hmmm, i could try doing v6 builds also, lets see
<clever> you can read files, if you know the names, but you cant list the names
<clever> and you can do interesting security stuff if you have +x and -r
<clever> cd and ls are seperate operations
<clever> LnL: you need +x on a directory to traverse it, +r only allows you to read it
<clever> it is
<clever> LnL: i think 1 is +x?
<clever> LnL: ah, that would do it
<clever> Baughn: that would be better
<clever> Baughn: one sec
<clever> then it has no way to reach the unix socket nix-daemon is on
<clever> Baughn: if sandboxes are off, you can set NIX_REMOTE=remote and i think it can talk to the nix-daemon on the host
<clever> LnL: what if you just make /nix a symlink?
<clever> ah, so something weird is going on with the filesystem stuff
<clever> LnL: and you already tried to run perl after switching to the nixbld1 user?
<clever> LnL: can you redo the strace with -s3000 ?
<clever> LnL: no weird mount options that would get in the way
<clever> LnL: can you gist /proc/mounts also?
<clever> LnL: what about "stat /nix" ?
<clever> LnL: what FS is store on?
<clever> LnL: shouldnt in this case
<clever> and the command above?
<clever> LnL: for example, what happens if you su nixbld1 and then ls -lh /nix/store/x9pkm0d2fbc4kq89v7wzf64ccphnpybc-perl-5.22.2/bin/perl
<clever> LnL: what are the permissions on perl, and the directories above it?
<clever> LnL: lines 29 and 32 of your gist appear to imply it has a nixbld user at the correct UID, which feels odd
<clever> and they take micro SD!
<clever> crud, both the v7 and v8 lack RCA composite video!
<clever> and -ff only withs with -o logfile
<clever> LnL: the -ff makes the logs easyer to read, and the -s3000 stops it from truncating strings