2018-03-30

<clever> ryantrinkle: run nix repl on release.nix, and look at the build attribute
<clever> kandinski: the issue has to do with xauth files, we need to find a fixed path that the tokens can be found in, and pass them to xauth
<clever> kandinski: the synergy service was broken when a security problem in xorg was fixed
<clever> either by putting that into a file or by using -E
<clever> boomshroom: yeah, you still have to evaluate: with import <nixpkgs>{}; callPackage ./foo.nix {}
<clever> boomshroom: it has to be loaded with callPackage i'm guessing
<clever> ping

2018-03-29

<clever> webchat: its dynamicaly linked, but nix tracks things better, and forces a rebuild because nix thinks that the libc change could have any kind of side-effect on the build
<clever> tmplt: all attributes given to mkDerivation just become env variables at build-time
<clever> ah
<clever> proot might be forcing 32bit only, and your /bin/sh is 64bit
<clever> i just use it as a guideline and delete the checkboxes that dont count
<clever> to find out why it wont let you delete things
<clever> run nix-store --delete /nix/store/hash-name
<clever> you do
<clever> tobiasBora: nix-store --query --roots and nix-store --delete

2018-03-28

<clever> jluttine: if its in the same derivation, it will trigger a rebuild
<clever> Myrl-saki: 1404/3033 on-disk size, 133/255 network size (compression)
<clever> Myrl-saki: 0 out of 326 packages have been built, 1 is downloading, and 134/466 have been downloaded, i think
<clever> nix-repl> firefox-unwrapped
<clever> «derivation /nix/store/yr2k052z76m4rzdmzanail0169c32s1w-firefox-unwrapped-58.0.2.drv»
<clever> in the case of firefox and chrome, there is also an unwrapped package
<clever> yeah
<clever> so it only has to "recompile" the bash script when the runtime thing changes
<clever> the 2nd derivation generates a bash script that just prefixes PATH, then runs the binary from the 1st
<clever> jluttine: thats exactly how the firefox/chrome plugins are managed
<clever> jluttine: make a 2nd derivation, that wrapProgram's the PATH over the 1st's binary
<clever> jluttine: i would use makeWrapper and prefix PATH with the bin dirs
<clever> for the things that depend on it
<clever> vaibhavsagar: propagatedBuildInputs is only at build-time
<clever> vaibhavsagar: shellshock i believe was just because bash was in the workflow, but no bash scripts where involved
<clever> and given how much its used
<clever> if bash is already in-ram, the binary size doesnt really matter much
<clever> unlmtd: what will /bin/sh be then?
<clever> yeah, it can also be used for that as well if the normal shell is broken
<clever> unlmtd: i have a dedicated user called builder that is used for all remote builds
<clever> unlmtd: double-check that PATH is being handled properly for non-interactive shells
<clever> unlmtd: how did you try running it?

2018-03-27

<clever> michas_: nothing says you cant just keep using that disk image as a server
<clever> michas_: the 1st step runs the test env for justdoit, where just logging in and running justdoit will install nixos, the 2nd step runs it with just the disk image from the 1st, to confirm it boots
<clever> michas_: oh, you could also use that justdoit release.nix just to get nixos running inside qemu
<clever> michas_: ah
<clever> michas_: you could potentially chain the 2 things, so the netboot server is also a diskless nixos inside qemu!
<clever> michas_: line 6 grabs a configuration.nix that already references the netboot-base file, then builds its kernel+initrd, and boots those directly in qemu
<clever> michas_: i also have methods of booting a diskless nixos image in qemu
<clever> michas_: since your not using it to install things,line 12 and 21-26 of my version can just be commented out
<clever> michas_: thats a nixos module, just add imports = [ ./netboot_server.nix ]; to your existing configuration.nix, and set netboot_server.network = { wan = "foo"; lan = "bar"; }; with the right interface names
<clever> michas_: lines 20-27 is the config for the OS that the target machines run
<clever> michas_: originally, i had written that to turn my old laptop into a netboot server, to it could hijack the new laptop, and it also includes justdoit (line 12), which will wipe the entire machine with 1 command (run justdoit, lol :D), but you can customize it to run other services and remove that
<clever> michas_: it also handles the dhcp and dns server, and performs NAT between the internet and the LAN that the client machines are on
<clever> michas_: this is a complete diskless nixos server, without even an NFS mount, the machines run entirely from a ramdisk, and all state is lost at reboot
<clever> but a side-effect is that <lib> also works, but only when the path is set "wrong"
<clever> so <nixpkgs> still maps correctly
<clever> ottidmes: sometimes NIX_PATH can wind up set like NIX_PATH=/home/clever/nixpkgs/ and the dist tarball includes a nixpkgs symlink to .
<clever> and then registering it as valid
<clever> manually copying it into /nix/store
<clever> there was a thing on the nix mailing list, about using a nix tool to compute the output path of a given thing
<clever> throwup: since it doesnt exist for newly created users
<clever> throwup: i would expect the desktop env to replace that on login
<clever> elvishjerricco: not sure
<clever> throwup: have you rebooted yet?
<clever> infinisil: also look into tarsnap
<clever> though if you aggregate 2 links with a vpn, you can bypass that
<clever> and tcp connections cant change uplink
<clever> infinisil: but the problem is that half your facebook http connections tie up one uplink, keeping it "busy" with idle connections, then all your high bandwidth stuff is stuck on the 2nd modem
<clever> infinisil: iptables has a way to load-balance with some weights, and then bind each connection to a given interface
<clever> now i have 300mbit down and i cant max it out, lol
<clever> infinisil: i used to use tc, back when my router ran LFS and i only had 600kbyte/sec down
<clever> infinisil: #nixos-on-your-router
<clever> Myrl-saki: fun, i started linux with a 64mb P1? running redhat9
<clever> infinisil: i setup the router before i had the NAS, and it only has a single ethernet port right now
<clever> #4 has 3 monitors, and #5 is beside it, and synergy joins them up, so it behaves like a 4-monitor setup
<clever> #5 is the nixos laptop
<clever> #4 is the primary nixos desktop
<clever> #3 is the old gentoo "server", it only runs an apache and irssi now
<clever> #2 is the nas, nixos, 5 drives, zfs
<clever> infinisil: #1 is the "router", a 2U server with 3 gigabit ports
<clever> infinisil: wait, 5
<clever> the desktop alone can sometimes trip the warning just from high cpu usage
<clever> Myrl-saki: and the desktop+laptop draw enough watts to sometimes trip the overload warning on the UPS
<clever> Myrl-saki: i have 4 computers running 24/7 in my house
<clever> Myrl-saki: it was last upgraded around 2014, lol
<clever> Myrl-saki: ah, i'm just abusing the crap out of an aging gentoo machine
<clever> Myrl-saki: all of mine are on a local machine
<clever> 3.9G /home/clever/irclogs/
<clever> $ du -h ~/irclogs/
<clever> because the irc client is never closed, the timestamps are intact
<clever> Myrl-saki: i just ssh into a system where i leave irssi running in a screen session
<clever> the full args should be in a config in the image
<clever> that image is also an MBR disk image, so you can just tell hyperkit that its a hdd img and it should boot without any extraction
<clever> nineteeneightd: it sounds like its not able to access its own iso when booting

2018-03-26

<clever> nineteeneightd: was the iso modified in any way?
<clever> after serializing it into a NAR
<clever> for the contents of everything
<clever> infinisil: that includes every file within the path
<clever> Myrl-saki: it keeps the entire storepath its copying as a std::string
<clever> you can patch it with sed in the patchPhase = '' ... '';
<clever> target_link_libraries(emojicodec curses z m LLVMLTO....
<clever> ThatPako: i also ran into that issue, the problem is that the package has just curses in its cmake file, but nixos only has ncurses
<clever> try removing ninja from the inputs, i suspect something has changed with ninja, and its likely optional
<clever> id say its just a bug in nix-info then
<clever> what does nix-channel --list say?
<clever> does the nix-info change?
<clever> run nix-channel --update as paul
<clever> what is the mod-time on this file?
<clever> ls -ltrh ~/.nix-channels
<clever> each user has his own set of channels
<clever> you added a channel without using sudo
<clever> which channel?
<clever> on nixos?
<clever> yep
<clever> yeah
<clever> doesnt happen on my end
<clever> mostly preference i think
<clever> line 3 switches it to the clang stdenv
<clever> ThatPako: because you added clang to a gcc stdenv
<clever> there is an s missing on buildInputs
<clever> oh
<clever> and you would already have a build directory
<clever> ThatPako: the configurePhase already ran cmake (line 15), and the buildPhase should have already ran ninja (i think)
<clever> ThatPako: use that to find the files you want, then add in a cp command to copy them to $out
<clever> ThatPako: you probably need a custom installPhase
<clever> ThatPako: it may be that it lacks an install step in the cmake file
<clever> ThatPako: what does nix-build print when ran?
<clever> ThatPako: cmake includes its own configure script to automate that
<clever> ThatPako: add buildInputs = [ cmake ninja ]; and see what happens
<clever> ThatPako: can you gist the nix expression?
<clever> ThatPako: the revision is the sha1 in the URL
<clever> ThatPako: click on the commits link near the top, then the msg for that top commit
<clever> ThatPako: which repo are you trying to fetch?
<clever> ThatPako: a git revision
<clever> ThatPako: the main args are owner, repo, rev, sha256
<clever> dahirsch: but you could start by comparing what is in /boot and efibootmgr in each setup
<clever> dahirsch: nope, ive not done much with uefi
<clever> dahirsch: yes
<clever> yeah
<clever> you have to make that copy after running `nixos-rebuild boot`
<clever> how: oh, and that copy lacks the new nixos you just made with `nixos-rebuild boot`, thats why it cant boot
<clever> how: if you manually mount the new fs to /mnt, what does `ls /mnt` say?
<clever> how: either the new config is wrong, or the copy of the store isnt right
<clever> how: with what error?
<clever> fresheyeball: `Extra-libraries: foo` according to stack overflow
<clever> fresheyeball: it has to be put in the cabal file
<clever> fresheyeball: its a standard gcc/ld flag, has to be used any time you link against a library
<clever> fresheyeball: you need to tell cabal to -lsass, because the static library lacks that metadata
<clever> fresheyeball: what nix-shell params did you use?
<clever> fresheyeball: are you getting a syntax error?
<clever> anixos: check "ps -eH x" and see what process is near X in the tree
<clever> coconnor: X is already running and using fb0 by the time the login prompt is open
<clever> anixos: and do you have isNormalUser set on your user?
<clever> anixos: double-check the /etc/shadow file, and confirm if the hashed pw is actually in there
<clever> fresheyeball: haskellPackages = super.haskellPackages.override { overrides = { hsself: hssuper: { hlibsass = super.haskell.lib.dontCheck hssuper.hlibsass; }; }; };
<clever> fresheyeball: you must use super.haskellPackages.override { overrides = { hsself: hssuper: { ... }; }; }; to write a haskellPackages overlay
<clever> fresheyeball: // overwrites the hlibsass atttribute of the resulting haskellPackages, but it does not make other haskell packages use the new version
<clever> fresheyeball: can you gist the overlay?
<clever> anixos: i think you need to set mutableUsers = false; for that to work
<clever> anixos: are you using hashedPassword or initialHashedPassword?
<clever> yep
<clever> it will need device and fsType
<clever> neededForBoot is automatic
<clever> yeah, if the data has already been moved, you dont need it
<clever> if the data is already moved over then you just need to update configuration.nix and reboot i believe
<clever> make the new LV, format it, and move all of /nix over
<clever> then youll have a new generation in grub that expects it to be moved, and an old that doesnt
<clever> how: you can add filesystems."/nix" = ... and `nixos-rebuild boot` before you move it, to save some trouble
<clever> how: ive used that to do exactly what your doing, move my laptop /nix into its own zfs dataset
<clever> how: for rescue-boot, you add imports = [ ./rescue_boot.nix ]; to your configuration.nix, and it will generate a new grub option that boots into a rescue OS
<clever> how: boot from another system, like the installer iso or a recovery image
<clever> how: id recomend moving it while the system is not running, just rsync the data to the new filesystem, delete the old, and convince it to boot with the new fs mounted at the right place, then fix the nixos config
<clever> nick_l: line 30 says it will accept any icmp with type 8, which should be ping-request
<clever> ive written my own VPN and have brought wifi up without wpa_supplicant before
<clever> it gets every table
<clever> i also prefer using iptables-save to list the rules
<clever> and then icmp, when allowed, is accepted later on, for all interfaces
<clever> the lo interface is special-cased in the firewall to accept everything
<clever> -A nixos-fw -p icmp -m icmp --icmp-type 8 -j nixos-fw-accept
<clever> -A nixos-fw -i lo -j nixos-fw-accept
<clever> nick_l: nope
<clever> and it just skips the routing layer and goes directly to localhost, but still obeys the iptables
<clever> Dezgeg: i think the IP on every interface is special-cased in the kernel
<clever> i could never get LIO to work when i was playing with things
<clever> nyanloutre: tgtd for the daemon, and open_iscsi for the client
<clever> but you can always re-start it with smaller number, and it will resume at the last derivation
<clever> but it will entirely ignore ram usage, and may kill itself
<clever> so if things start to lag some, it will throttle itself
<clever> Hackapepper: the `--cores 10` part tells it to keep the load avg under 10
<clever> yep
<clever> yeah
<clever> together, it would run up to 100 procs, but the 2nd also limits itself to keeping the loadavg under 10
<clever> the 2nd runs 10 gcc's within each derivation
<clever> the first runs 10 derivations in parallel, but it cant do much early on
<clever> Hackapepper: -j 10 --cores 10
<clever> Hackapepper: its probably going to build 2 gcc's, and a glibc
<clever> thats my guess
<clever> krey: one of these mv's failed
<clever> krey: ah, he added a weird argument, you need pkgs.callPackage /path/to/pypi2nix { nixpkgs = pkgs; }
<clever> Hackapepper: thats the first thing it should print out
<clever> but if you run the whole thing on a single remote machine, it wont matter
<clever> Hackapepper: i meant the work-sharing build-slave logic within nix, to split the load up between many
<clever> Hackapepper: the slaves wont really work right with the store being in the wrong place
<clever> Hackapepper: i suspect that the ntfs doesnt support +x, so everything will fail
<clever> Hackapepper: ah, NTFS will likely break a lot of things
<clever> Hackapepper: run "file /home/nao/nix/store/yv06f35xnkxi42sa4srhhapaps21cfr6-busybox"
<clever> krey: pkgs.callPackage /path/to/pypi2nix {}
<clever> krey: pkgs.callPackage
<clever> krey: also, pypi2nix already has a default.nix you can just use
<clever> neonfuz: if you have never installed something with nix-env as root, then that wont exist
<clever> neonfuz: thats what .nix-profile is supposed to point to
<clever> Hackapepper: looks good
<clever> Hackapepper: this will cause the final nix binary to try to act on $HOME/nix/store, using the value of $HOME from the build host, not the target machine
<clever> override { storeDir = "'$BUILDING_MACHINE_HOME'/nix/store";
<clever> Hackapepper: you need to also use TARGET_MACHINE in the override
<clever> infinisil: the override embeds the same config into the binary its building
<clever> infinisil: they are only set once, on the build host, to temporarily make a normal nix act on an abnormal location
<clever> krey: ah, if you want it in nix-shell, then yikes, it seems i was able to permantly edit your pastebin, cant find the old version
<clever> adisbladis[m]: thats new, havent seen it before
<clever> krey: http://lpaste.net/5310280711322730496 would have the same effect when built
<clever> krey: also, buildEnv itself is a derivation, so you dont need to symlink it to $out
<clever> krey: you almost never need to set the builder attribute
<clever> so it works without the env vars
<clever> and the overrides are to make the nix within that non-standard store act on the same non-standard store, during its own runtime
<clever> infinisil: yeah, the env vars are to affect the un-modified nix, to make it act on a non-standard store
<clever> neonfuz: expanding is easy, shrinking is imposible
<clever> while debian cant really undo updates so seamlessly
<clever> kandinski: the biggest difference is that nixos has rollbacks, so you can undo any change
<clever> neonfuz: probably just personal preference
<clever> kandinski: the simplest thing right now would probably be to just run nixos-unstable for a month, its a lot more stable then the name sudjests
<clever> neonfuz: i use this bash script to install my systems
<clever> neonfuz: i always use <hostname>/root for my systems
<clever> kandinski: so it might make it into the nixos-18.03 channel after tests pass, not sure
<clever> kandinski: this one says its on master and 18.03-beta
<clever> kandinski: this page says its currently only in nixos-unstable
<clever> Hackapepper: probably, youll also want to change the confDir in the override
<clever> yeah, that will switch it over to a 32bit nix
<clever> for root itself, its just ~/.nix-defexpr/channels/nixos/
<clever> the channels_root directory points to the channels managed by root
<clever> kandinski: compare the files modified in the PR to what you have in ~/.nix-defexpr/channels_root/nixos/
<clever> allowing you to build it for a path you cant make
<clever> and then NIX_REMOTE to re-root that, so you dont need write to that final destination
<clever> and the .override, so that nix will target the same place
<clever> NIX_CONF_DIR, NIX_LOG_DIR, NIX_STORE all have to be set when running nix-build, to modify the config of where the nix its making will live
<clever> infinisil: the main limit i can see with your variant, is that the nix it initially builds still lives in the store of the nix that built it, not the paths you passed to it
<clever> infinisil: one min, i already have an expression for that
<clever> only downside it has, is that it forces a 32bit-linux build, even on darwin
<clever> so you can pkgsi686Linux.callPackage in the middle of top-level.nix or almost any other file
<clever> infinisil: pkgsi686Linux
<clever> infinisil: there is an entire pkgs tree that is 32bit only

2018-03-25

<clever> while the new behaviour, is that the nix client can choose (if trusted), and it defaults to on
<clever> MichaelRaskin: i think the old behaviour, is that being trusted just automatically turned off sig checking
<clever> MichaelRaskin: nofear sounds like pkgs.runInLinuxVm, which can run any nix derivation as root under qemu
<clever> and you needed a certain gid to access the network originally
<clever> android has something similar, no chroot, but there is one uid per application
<clever> GiGa: yep
<clever> GiGa: nixpkgs.config.packageOverrides = pkgs: { gramps = pkgs.gramps.override { enableOSM = true; }; };
<clever> GiGa: nixpkgs.config.packageOverrides or nixpkgs.config.overlays
<clever> infinisil: i dont think anything in nix should ever use sbin

2018-03-24

<clever> modesetting is a more generic one that uses kernel drivers
<clever> vidbina_: also, sometimes, its simpler to just `nixos-rebuild boot` and manually reboot, some changes cant be applied at runtime
<clever> vidbina_: the journal in that gist looks mostly like a normal reboot
<clever> typetetris: most of the tools within it rely on /proc files to work, and darwin doesnt use the same api there
<clever> vidbina_: can you also gist your configuration.nix file?
<clever> typetetris: and further checks with `git log --patch` reveal, docker-gc has been broken on darwin from the very first version
<clever> he simply cleaned the code up, it was already "wrong"
<clever> + --prefix PATH : "${stdenv.lib.makeBinPath [ docker coreutils procps gnused findutils gnugrep ]}"
<clever> - --prefix PATH : "${docker}/bin:${coreutils}/bin:${procps}/bin:${gnused}/bin:${findutils}/bin:${gnugrep}/bin"
<clever> but, that blame is false
<clever> and git blame reveals that one line was modified a few months ago
<clever> 74a3a2cd7e40 (Tuomas Tynkkynen 2016-08-23 01:06:51 +0300 23) --prefix PATH : "${stdenv.lib.makeBinPath [ docker coreutils procps gnused findutils gnugrep ]}"
<clever> typetetris: and there it is, thed generic docker-gc for all platforms, depends on procps, which is linux-only
<clever> 23 --prefix PATH : "${stdenv.lib.makeBinPath [ docker coreutils procps gnused findutils gnugrep ]}"
<clever> while evaluating 'makeSearchPathOutput' at /home/clever/apps/nixpkgs/lib/strings.nix:94:42, called from /home/clever/apps/nixpkgs/pkgs/applications/virtualization/docker/gc.nix:23:28:
<clever> and now i can just --show-trace it
<clever> i can also reproduce that issue on a random rev of nixpkgs i jsut happened to have checked out
<clever> i think
<clever> nix-instantiate pkgs/top-level/release.nix -A docker-gc.x86_64-darwin
<clever> typetetris: so now try to nix-build docker-gc on darwin and see what happens
<clever> typetetris: it sounds like docker-gc somehow depends on procps-ng
<clever> typetetris: does hydra say anything else on nearby lines?
<clever> abathur: yeah
<clever> it should use something other then errorf
<clever> things can still malfunction in fun ways if the error happens to contain a %
<clever> in this case, the string came from mysql_error
<clever> and potentialy, if an attacker can control that variable, he can exploit the machine
<clever> ah, so it was basically printf(variable1);
<clever> abathur: depends on what triggered the warning, what was the error without that setting?