2017-03-21

<clever> joepie91: that url is a mirror for all tarballs downloaded via fetchurl
<clever> joepie91: thats the one
<clever> joepie91: hardware.32bit something in configuration.nix
<clever> viric: and if real-onlu is an option, squashfs
<clever> viric: i generaly just go zfs for that kind of thing
<clever> spinus: but qtbase is an attribute within qt5, and overriding the qtbase passed to other qt utils will be tricky
<clever> NickHu: nix-store --query --tree
<clever> cant currently open links
<clever> McK: i'm also unable to build chrome with widevine
<clever> nope, it doesnt
<clever> hotfuzz: forcing rpcbind to on may break the recursion
<clever> hotfuzz: and the status of rpcbind depends on the presense of nfs in the list of supported filesystems, which depends on the entire filesystems attrset
<clever> hotfuzz: if rpcbind is enabled, the rpc user gets auto-created
<clever> Bisecting: 8686 revisions left to test after this (roughly 13 steps)
<clever> hotfuzz: i can confirm that ~11000 commits ago, nixpkgs accepted that
<clever> thats my first guess
<clever> and now the fs list depends on the user list
<clever> hotfuzz: i think the list of supported filesystems has an impact on the available users, automaticaly installing programs (and users) to add fs support
<clever> ah, which is also in your config
<clever> hotfuzz: and its somehow involved in users.extraUsers
<clever> hotfuzz: this does appear in the backtrace
<clever> while evaluating the option `fileSystems./var/lib/mpd/music.options':
<clever> hotfuzz: and that kind of config is better put into configuration.nix
<clever> dtzWill: no matter how little you delete, nix wants to review .links for any file with a link-count of 1 (only the .link entry)
<clever> dtzWill: i have also been thinking about tiering, trying to delete even 1 storepath with nix-store --delete takes anywhere from 2 minutes to 30minutes
<clever> sziszi: nix-env -f .nixpkgs/config.nix just wont work, you have to point -f to the default.nix at the root of a nixpkgs tree, and that nixpkgs then has to load a config.nix
<clever> just missed him
<clever> oops
<clever> nil: its in the nixUnstable attribute
<clever> globin: and the new nixUnstable has "nix log" which i think can query the binary cache for logs
<clever> globin: "if you urgently need a log, you can find them at URIs like: https://cache.nixos.org/log/l9qmwi2q0dk4ji8pcycc188gank0q5pb-pointedalternative-0.1.0.0.drv"
<clever> globin: he is, they are now in the binary cache
<clever> 200 here
<clever> c74d: looks like a bunch of qt things are timing out on build slaves
<clever> bkchr: they all go into the main /nix/store/
<clever> MichaelRaskin: there are also 2 things keeping the boot profile in the store, /run/booted-system is the main one, but the /proc/*/exe symlinks also root anything running, so the old systemd and dbus and stuff that cant easily restart, are rooting their closures
<clever> and i prefer to test rebooting before deleting generations
<clever> yeah, but if you set a 30d limit, it will keep 1 generation from beyond that 30d limit
<clever> c74d: so it knows when you stopped using x
<clever> c74d: i think --delete-older-than uses the timestamp of generation x+1 to figure out if it should delete x
<clever> MichaelRaskin: so its better to pin an exact build with readlink
<clever> MichaelRaskin: ahh yeah, the system-0-link will point to the currently booted nixos, not the one the bootloader points to
<clever> c74d: that will leave several backups in place
<clever> c74d: i generaly dont garbage collect everything, there is also --delete-older-than
<clever> MichaelRaskin: i have been interested in configuring fallback in grub to make nixos more bullet proof in remote settings
<clever> do you always want 0 to change to the last thing you booted with?, or do you want to pin the current one as 0?
<clever> depends a lot on what you want also
<clever> then 0 will always be the one you booted with now
<clever> might be better to ln -sv $(readlink /run/booted-system) /nix/var/nix/profiles/system-0-link
<clever> that should work, though gen 0 will change each time you reboot
<clever> c74d: same rules should apply with any bootloader
<clever> and /run/booted-system is only a gc root to prevent garbage collection, but it wont force it into the grub.conf
<clever> but only generations listed in /nix/var/nix/profiles/system* will be in grub.conf
<clever> and similiar problem, the system just rolling back all changes at every reboot
<clever> then it just doesnt know about the only generation left, and cant boot
<clever> so it updated the grub.conf in the rootfs, and not on the /boot partition
<clever> i have also seen problems in the past, where people managed to not mount /boot
<clever> c74d: you have to re-run nixos-rebuild switch/boot to regen that
<clever> c74d: nix-collect-garbage doesnt know how to update the bootloader
<clever> steveeJ: it looks like busybox has been used to cross-compile in the past: https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/busybox/default.nix#L79
<clever> ToxicFrog: you could also inspect the env vars of the main steam gui, that should have /steamrt in it

2017-03-20

<clever> that causes # Restore write permissions to make building work\nchmod -R u+w $strippedName to just try to chmod nothing, and fail
<clever> __Sander__: but strippedName is set right on 16.09
<clever> __Sander__: oh yeah, strippedName isnt set right when i use a node-env.nix from an older project on unstable or 17.03
<clever> niksnut: so the nix-daemon appears to be unable to sign things its passing to nix copy?
<clever> niksnut: even if i put a secret-key-files and matching binary-cache-public-keys in nix.conf
<clever> niksnut: oh yeah, when using "nix copy --to local?root=/mnt" it complains about things not being signed, i had to pass a --option to entirely disable signatures
<clever> i sometimes had to dig thru 5 pages of hydra jobs to find the right jobset and build for something
<clever> ah, that would solve the problem ive noticed that "nix-store -l" can only get logs for locally built things
<clever> srhb: after typing in part of a command and the "(reverse-i-search)`pub': vi pubkeys" stuff appears, you can just hit up/down arrow to cancel the search, and it will seek the history relative to the result
<clever> niksnut: yeah, and you can also use up/down arrow to seek relative to the result it found
<clever> niksnut: ive always used <ctrl+r>nix-b style
<clever> and /proc/PID/root is a special symlink, that can lead into (and out of!) chroots
<clever> ToxicFrog: that lets you inspect the env variables for any process
<clever> ToxicFrog: it may help to check "strings /proc/PID/environ"
<clever> ToxicFrog: nix will build a directory and a wrapper script, and running that wrapper will automaticaly chroot into a dir and run steam
<clever> sophiag: then nix-env and nixos-rebuild will share the overrides
<clever> sophiag: you can also do nixpkgs.config = import /home/clever/.nixpkgs/config.nix;

2017-03-19

<clever> joepie91: so line and column are available directly as int
<clever> joepie91: oh, and the Pos passed to a previous function is at https://github.com/NixOS/nix/blob/master/src/libexpr/nixexpr.hh#L25
<clever> you can add a new module, but it will conflict if the old one also exists
<clever> joepie91: there is currently no way to override modules
<clever> joepie91: only issue with that form, is that it will checkout the latest 16.09 every time you eval, and may update things without you noticing
<clever> oops, thats 15.09, but close enough
<clever> joepie91: let nixpkgs1609 = import (builtins.fetchurl https://github.com/NixOS/nixpkgs-channels/archive/nixos-15.09.tar.gz) { config = {}; };
<clever> joepie91: one min
<clever> overrides.nix: util = pkgs.callPackage ./util.nix {};
<clever> that will supply all of the arguments for you
<clever> arianvp2_: you need to load it with callPackage
<clever> arianvp2_: this nix file creates 3 bash scripts at once, and embeds things like the xterm path into them
<clever> arianvp2_: probably simpler to use runCommand
<clever> joepie91: its usingthe macro on 117 to programaticaly generate classes
<clever> joepie91: the most complex part i can see is where Error gets defined, on line 124 of types.hh
<clever> joepie91: currently, it will prefix the prefix_ variable with the line of stack, you could then either parse the whole thing, or store the data in a more structured manner
<clever> joepie91: i just noticed, its calling .addPrefix on the error object that it keeps throwing to itself
<clever> joepie91: oh, correction to the previous stack trace stuff
<clever> ndowens08: i have ssh to a darwin box
<clever> ndowens08: i get a bit OCD about knowing how things work, and have read a large chunk of the source behind the stdenv
<clever> ndowens08: ah, i avoid editing those kinds of files, and i just know all of the mass-rebuild like things off the top of my head
<clever> ndowens08: i never really bothered with nox review
<clever> joepie91: ah, sounds like it needs to be a single global token for all of nixops, and ignore the per-machine ones
<clever> joepie91: or is it that you need to inform nixops about the new token?
<clever> joepie91: is it being remembered within a file nixops baked into the VM?
<clever> joepie91: but usualy when tokens get rotated, the old token should become invalid
<clever> joepie91: so i would either file a bug with digital ocean for needing a token from months ago, or store the token create used into the nixops database, so it knows how to destroy an instance
<clever> joepie91: but its not clear how much time there can be between create and destroy
<clever> joepie91: not sure what the right fix would be, sounds like there needs to be a global variable or some state somewhere, to remember which token to use at destroy
<clever> joepie91: ive looked at its source and how it works, but i havent used nixops yet
<clever> ndowens08: what happens if you try to "git fsck"?
<clever> yeah
<clever> joepie91: yeah, reversing it will be rather difficult
<clever> jophish: this, without any runtime libraries
<clever> std::cout << termcolor::red << termcolor::on_blue << "Red text on blue background!" < termcolor::reset << std::endl;
<clever> and it will just substitute in the name of the lambda, and the position
<clever> joepie91: looks like this instance of the function is responsible
<clever> error, string, lambda, int i think
<clever> addErrorPrefix(e, "while evaluating %1%, called from %2%:\n", lambda, pos);
<clever> but accessing the data from the previous/next line will be more difficult
<clever> you can easily re-format what is currently displayed on one line
<clever> until the eval in nix-instantiate errors
<clever> and each time it throws, a different frame of callFunction catches it
<clever> it will imperatively print each frame of the stack, as it re-throws the exception up the c++ stack
<clever> so as the c stack unwinds, it can print the nix stack
<clever> joepie91: it looks like every callFunction in the entire stack will catch the exception, print a line of nix stack, then re-throw the exception
<clever> joepie91: hmmm, yeah, i can see the issue
<clever> so you arent likely to break other platforms
<clever> termcolor also supports windows, mac, unix, and linux
<clever> i was thinking about adding the colors directly to the output from nix
<clever> bennofs: but those errors are from nix-store -r, called via nix-build, within nixos-rebuild
<clever> joepie91: termcolor is a header-only c++ library, to get colors on stdout
<clever> oops
<clever> jophish: have you heard of termcolor? https://github.com/cleverca22/fusenar/blob/master/termcolor.nix
<clever> jophish: ooo, nice
<clever> then i realized, LD_PRELOAD can do the same with zero changes
<clever> jophish: i also met resistance trying to get a PR into toxcore, that would log every privatekey it deals with
<clever> wireshark doesnt have dev headers, so you have to build against the same dir wireshark was built in
<clever> but the plugin build process on nixos is still rather messy
<clever> jophish: i had made the dumpcap for https://github.com/cleverca22/tox_decoder, since wireshark refuses to load plugins when running as root
<clever> bennofs: yeah, just realized that after i finished fixing it
<clever> jophish: though setcap might be better, should add it to my todo list
<clever> jophish: updated my gist, only users in the wireshark group can access dumpcap via the setuid wrapper
<clever> ah, permissions should still work
<clever> oh, and that fix probably isnt as secure, let me look into it more
<clever> but it got broke by recent changes
<clever> i used something similar for wireshark without root
<clever> jophish: all setuid programs must be configured within security.wrappers from a nixos module, which will make a setuid wrapper within /run/wrappers/bin at runtime
<clever> jophish: nothing in the store can have permissions other then 444 or 555
<clever> jophish: its not setuid at build time
<clever> ndowens08: try using a more minimal configuration.nix
<clever> ndowens08: what configuration.nix are you using?
<clever> gchristensen: thanks :)
<clever> gbbrt: yep, and its got #musnix
<clever> ah, thats what it was called
<clever> gbbrt: there was also another project about getting low-jitter audio on nixos, trying to find it
<clever> gbbrt: you can then add libraries to multiPkgs and those will land in /usr/lib
<clever> gbbrt: https://gist.github.com/cleverca22/147fec9a51f7390d9026dd2ca86d978b is my first thought, this will put the already packaged&patched bitwig into an FHS env
<clever> ndowens08: change it from http to https
<clever> and i dont think fetchurl can follow redirects
<clever> ndowens08: they are redirecting you to an https:// url
<clever> ndowens08: what do you see when you run this?
<clever> ndowens08: can you gist the nix expression?
<clever> gbbrt: here is how steam sets up its FHS env
<clever> ndowens08: what if you try to download it with "curl -D -"
<clever> gbbrt: it would still be limited to only accessing libraries you put into the FHS env
<clever> gbbrt: what changes have you done and what error is it having?
<clever> ndowens08: -I nixpkgs=/home/clever/nixpkgs
<clever> gbbrt: and with the strict licensing stuff of VST, i can see how it could be hard to fix
<clever> gbbrt: but if the VST starts to execute its own stuff, yeah, an FHS might help more
<clever> gbbrt: if they are dyn libs loaded by bitwig, then it should also use the rpath of bitwig
<clever> gbbrt: callPackage_i686 also works
<clever> gbbrt: can you throw what you already have on gist.github.com?
<clever> gbbrt: you need to use the 32bit ld.so and the 32bit libs when patching a 32bit program
<clever> gbbrt: and also setting builder in a derivation disables a lot of support code that is normaly active
<clever> gbbrt: its usually better to use patchelf first
<clever> gbbrt: 99% of the time, buildFHSUserEnv is the wrong way to package something
<clever> arianvp2_: some programs arent patched to read from a configurable location, so those read from /etc instead
<clever> rmrfroot: yep, just works bare
<clever> rmrfroot: { ${lan} = "blabla"; }

2017-03-18

<clever> DMZ__: there is no need to put the stdenv in the builtInputs, its always available
<clever> and in this case, it unpacked to /tmp/fooo
<clever> so you can do it without root, if you only want to inspect
<clever> ocharles: another example, to directly download from the binary cache
<clever> 2017-03-13 15:49:05< clever> [clever@amd-nixos:/tmp/fooo]$ curl cache.nixos.org/nar/0b1c57kbqjl78yh5wvna3lgfzldjk12s5a5kkyq49qd07jgy4p0p.nar.xz | unxz | nix-store --restore bdjyhh70npndlq3rzmggh4f2dzdsj4xy-hello-2.10
<clever> ocharles: a random example from a month ago, this one copies a->b, recursively
<clever> 2017-02-22 22:23:23< clever> $ nix-store --dump a | nix-store --restore b
<clever> ocharles: ah, looks like your using --repair-path to un-delete it
<clever> that will completely ignore liveless/roots, and bypass all safeties, and just forcibly replace it with the nar contents
<clever> so you could just the nix db, rm -rf a given storepath, then nix-store --restore a nar to un-delete it
<clever> another option, i believe nix-store --restore behaves the same as tar -xf
<clever> yeah
<clever> LnL: its usualy better to nix-store --query --roots, and manualy delete each root, and be aware of what your deleting
<clever> LnL: in one case, it deleted the target of /run/current-system/
<clever> LnL: ive massively broken my system before with --ignore-liveness
<clever> but you can also pass "--option build-cores 8" to almost any nix command, to bypass nix.conf
<clever> and due to how nix.conf and nixos work, changes to nix.buildCores only take effect after the "nixos-rebuild switch" has finished
<clever> and nix.buildCores in configuration.nix controls how nix.conf is generated
<clever> ozer: enableParallelBuilding is per package
<clever> ozer: this line of code checks enableParallelBuilding, and if its true, it will use -j with the build-cores from nix.conf
<clever> ozer: and a derivation needs enableParallelBuilding=true; in its expression to actualy use -j

2017-03-17

<clever> tnias: this redirects both xen and dom0(linus) output to com1 at 38400 baud, you could then hook up a serial console on another machine and view output without a gpu
<clever> tnias: virtualisation.xen.bootParams = [ "loglvl=all guest_loglvl=all com1=38400,8n1 console=com1" ]; boot.kernelParams = [ "console=hvc0 earlyprintk=xen" ];
<clever> tnias: does it have a hardware serial port?
<clever> tnias: ive had issues with nvidia and xen before, can you change the GPU?
<clever> bennofs: thats a good question, i would switch it over to RPATH, and see what breaks
<clever> tnias: what hardware do you have on the machine?
<clever> tnias: its far more stable when xorg isnt enabled
<clever> tnias: i have had GPU problems with certain drivers in the past, before i used nixos
<clever> tnias: i have tested it before, and i know of 2 people that are running nixos on dom0
<clever> test and increment until you find something good
<clever> i think it was git checkout HEAD~1000, goes 1000 commits backwards
<clever> just run a normal bisect on nixpkgs, nix-build -A atom, and test
<clever> git bisect
<clever> 4th*
<clever> joepie91: looks like i updated my channel on the 4tb, and have made another ~15 generations since
<clever> lrwxrwxrwx 1 root root 88 Feb 4 16:38 /nix/var/nix/profiles/system-286-link -> /nix/store/wflkl26hv28fx45g819j5564rb17bjnf-nixos-system-amd-nixos-17.03pre99759.f66d782
<clever> lrwxrwxrwx 1 root root 88 Jan 13 22:55 /nix/var/nix/profiles/system-285-link -> /nix/store/wl9nfdjkr0yyqpv81i1vsfi8cxvpvhg8-nixos-system-amd-nixos-17.03pre96925.1c50bdd
<clever> joepie91: this will list every build of nixos
<clever> [clever@amd-nixos:~]$ ls -l /nix/var/nix/profiles/system*
<clever> joepie91: there is a git hash for nixpkgs in the name of the generation
<clever> bennofs: or its rpath improve more to not need a wrapper
<clever> bennofs: then atom will need to be patched to unset the wrapper env variables when forking out children
<clever> bennofs: ahh, then add a glibc 2.25 uname into $PATH
<clever> and only things built against 2.25 work on the new glibc
<clever> it sounds like atom was built against atom was built against glibc 2.24, and is breaking the same as uname
<clever> is atom built from source or patchelf'd?
<clever> bennofs: so that glibc clearly isnt broken, its just not cross-compatible with older 2.24 builds
<clever> [clever@amd-nixos:~]$ nix-store -qR $(which uname) | grep glibc
<clever> /nix/store/68sa3m89shpfaqq1b9xp5p1360vqhwx6-glibc-2.25
<clever> bennofs: my nixos-unstable desktop is running the "broken" 2.25 as the primary glibc
<clever> i have a desktop on 2.25, checking it
<clever> bennofs: my nas is built against 2.24, and 2.25 is the one breaking everything
<clever> [root@nas:~]# nix-store -qR $(which uname) | grep glibc
<clever> /nix/store/m71hw9kw0z74w93lq44l1xdcy2nq155f-glibc-2.24
<clever> bennofs: they appear to be failing hard
<clever> writev(2, [{iov_base="uname", iov_len=5}, {iov_base=": ", iov_len=2}, {iov_base="\200L\300\262\374\177", iov_len=6}, {iov_base=": ", iov_len=2}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0}, {iov_base="xY\225U\372\177", iov_len=6}, {iov_base=": ", iov_len=2}, {iov_base="Error 1422603048", iov_len=16}, {iov_base="\n", iov_len=1}], 10uname: �L��: xY�U�: Error 1422603048
<clever> arch_prctl(ARCH_SET_FS, 0x7ffa5594f680) = 0
<clever> [root@nas:~]# strace sh -c "LD_LIBRARY_PATH=/nix/store/68sa3m89shpfaqq1b9xp5p1360vqhwx6-glibc-2.25/lib/ uname -a"
<clever> not even strace works
<clever> strace: PZ_�: x�(�: Error 18446744073197728552
<clever> [root@nas:~]# LD_LIBRARY_PATH=/nix/store/68sa3m89shpfaqq1b9xp5p1360vqhwx6-glibc-2.25/lib/ strace uname -a
<clever> bennofs: oh god, what happened, lol
<clever> uname: p�m��: x�R�y: Error 18446744072829317928
<clever> [root@nas:~]# LD_LIBRARY_PATH=/nix/store/68sa3m89shpfaqq1b9xp5p1360vqhwx6-glibc-2.25/lib/ uname -a
<clever> anything in the binary cache can just be downloaded like that
<clever> bennofs: this will download the faulty libXScrnSaver, allowing you to inspect it more directly
<clever> [root@nas:~]# nix-store -r /nix/store/vx1p69szgv9jbwrgmssxbdljpwn1yczl-libXScrnSaver-1.2.2
<clever> joepie91: and LD_PRELOAD forcibly loads things, rather then just putting them in the search path
<clever> joepie91: i think the glibc used by libxscreensaver is not backwards compatible with the uname binary
<clever> and passthru behaves the same as meta
<clever> bkchr: the original error you pasted sounds like what happens when you set it to sda1
<clever> bkchr: what did you set boot.loader.grub.device to?
<clever> barrucadu: you must use ghcWithPackages

2017-03-16

<clever> ndowens08: this is about the only way, other then guessing
<clever> ls -l /nix/store/*/lib/libudev.so*
<clever> ndowens08: the udev libs are in systemd.lib
<clever> { bin = «derivation /nix/store/iv73mdzcl2qy16vhn2y44ak2grbiqsa4-systemd-232.drv»; lib = «derivation /nix/store/iv73mdzcl2qy16vhn2y44ak2grbiqsa4-systemd-232.drv»; }
<clever> nix-repl> systemd.udev
<clever> ndowens08: systemd
<clever> steveeJ: nix will just automaticaly download them
<clever> steveeJ: nix-shell uses some perl code to assemble a nearly identical runCommand when you use -p
<clever> steveeJ: that allows routing a complex set of buildInputs into nix-shell
<clever> steveeJ: the runcommand you linked, will run the commands in "", which will fail to produce $out, its designed for use with nix-shell, which doesnt actualy run them
<clever> yeah
<clever> hyper_ch: every time you hash a given password, it will come up differently
<clever> hyper_ch: thats the salt, it prevents brute forcing
<clever> just the minor cost of loosing the benefits of shadow
<clever> hyper_ch: it also lets me make users on remote boxes that already have my pass
<clever> hyper_ch: i just steal the hash out of /etc/shadow
<clever> hyper_ch: then either the wrapper is missing, or somebody hard-coded the path for it
<clever> a reboot would be needed to confirm
<clever> which may or may not be related
<clever> hyper_ch: and the comment you linked first, appears to be a lack of a setuid root wrapper on a vbox program
<clever> hyper_ch: so $PATH is wrong and cant find the right sudo
<clever> hyper_ch: 22914 is a result of upgrading nixos and the location of sudo changing
<clever> hyper_ch: ive mainly used vbox with the user nat mode, so it didnt need any special config
<clever> hyper_ch: becomes an issue when you have a multi-user system
<clever> hyper_ch: otherwise, anybody that can read /nix/store can find your password
<clever> hyper_ch: also, i prefer setting initialPasswordHash in configuration.nix
<clever> yep