2017-07-20

<clever> deltasquared: yeah, with both nixos-in-place and kexec, you only get one chance
<clever> nh2: and there is a nixops-example.nix so you can add the machine to nixops
<clever> nh2: the justdoit script is also pre-installed in that ramdisk, and does nearly the entire install
<clever> lol
<clever> deltasquared: somebody did joke that i could nixos-ify half the internet if i had a zero-day :P
<clever> nh2: then you can ssh in, wipe the disk, and nixos-install like normal
<clever> nh2: and within 5 minutes, it should be running nixos from a ramdisk
<clever> nh2: you upload a specialy made tarball to a remote server, unpack it to /, then run /kexec_nixos
<clever> nh2: have you seen my kexec trick?
<clever> /run/current-system/sw/share/doc/
<clever> yeah
<clever> leading to confusion
<clever> also, without -A, it will silently ignore broken things
<clever> yeah, without -A its much slower, and not clear which channel it will use
<clever> this is a channel name, and package name
<clever> nix-env -iA unstable.musecore
<clever> yeah
<clever> so it will only get used if you name unstable in a command
<clever> the above command calls the channel unstable
<clever> yeah, all of the nixos tools read the channel called nixos
<clever> download this, rename it to musecore.nix, and do musecore = pkgs.callPackage ./musecore.nix {};
<clever> or an override
<clever> queiw: sudo nix-channel --add https://nixos.org/channels/nixos-unstable unstable ; sudo nix-channel --update ; nix-env -iA unstable.musecore
<clever> so the new version thats not broken isnt available
<clever> queiw: ah, musecore appears to have been fixed in june, and 17.03 is from march
<clever> queiw: ah, what channel are you on?
<clever> queiw: and what happens if you do nix-env -iA nixos.musescore
<clever> queiw: what is the name of the package?
<clever> boomshroom: and then nix-build will never give a cached result, because every success modifies the source
<clever> boomshroom: if you do src = ./.; and nix-build in the directory, the result symlink becomes part of the "source"
<clever> boomshroom: ive done that, by mistake a few times, lol
<clever> boomshroom: nix refuses to allow any recursion
<clever> there was a bug in the nix-channel management code that caused it to ignore a recently passing build
<clever> yeah
<clever> canndrew: you want to patchelf it with the 32bit versions of the libs
<clever> hodapp: if you check ps aux, what is the path to the working gimp?
<clever> xd1le: add pkgconfig to the nativeBuildInputs and then insert $(pkg-config --cflags libevdev) into your gcc command
<clever> -I/nix/store/z69dmzg0h9dm7m0avha7klf0xklnch95-libevdev-1.5.6/include/libevdev-1.0/
<clever> [nix-shell:~]$ pkg-config --cflags libevdev
<clever> xd1le: pkgconfig is also in that package, so you can use that
<clever> xd1le: tab completion
<clever> (which is exactly what nix protects you from)
<clever> because the idiots wanted to prevent collisions
<clever> so you need to #include <libevdev-1.0/libevdev/libevdev.h>
<clever> lovely, lol
<clever> /nix/store/z69dmzg0h9dm7m0avha7klf0xklnch95-libevdev-1.5.6/include/libevdev-1.0/libevdev/libevdev.h
<clever> xd1le: the include dir of everything in buildInputs is added to -I automatically

2017-07-19

<clever> :D
<clever> in the same directory as Text
<clever> i think you need to run it one directory up
<clever> you would have to run nix-shell in that dir, then ghc and ghci will have the deps
<clever> and the cabal file doesnt say to compile the examples, so they arent available
<clever> nix-build creates a result symlink pointing to the finished build
<clever> not registering doesnt stop them from tracking you :P
<clever> eqyiel[m]: and whats wrong with having a google account?
<clever> you can just get a normal google account tied to any email
<clever> you dont need a gmail account to have a google account
<clever> if you turn on secure one-time tokens for pam, it turns passwords off!
<clever> there was something worse in the pam 2 factor auth
<clever> i try to keep /mnt clear because i use that for new installs
<clever> jtojnar: i keep mine under /media/
<clever> yeah, it ignores everything under /run
<clever> it might ignore /run
<clever> jtojnar: where is it mounted?
<clever> sphalerite[m]: https://github.com/cleverca22/nix-tests/blob/master/arm-baremetal.nix notes from when i last did cross-compiliner
<clever> jtojnar: is it mounted when you run nixos-generate-config?
<clever> jtojnar: add it to configuration.nix instead
<clever> Winchell1M: nixos already adds $HOME/bin/ to $PATH
<clever> GlennS: more that you can customize the partition tables, and do the entire install from real nixos, rather then mutating the root into nixos
<clever> and you now have a nixos install with zfs and custom partitions
<clever> so you just unpack the tar, run /kexec_nixos, ssh into it, and run justdoit
<clever> GlennS: this creates a kernel+initrd pair, containing the entire nixos installer
<clever> kexec lets you load a kernel+initrd into ram, and just switch control of the entire host to it
<clever> GlennS: have you seen my kexec trick?
<clever> qknight: yeah, sounds like it
<clever> qknight: i think its disabled by default
<clever> but internally, it applies no changes
<clever> so nix treats it as a transform
<clever> i would just have the derivation copy the valid config file to $out, and then return the result of the mkDerivation
<clever> ahh, your having nginx lint the config file
<clever> why does it need a whole derivation to test the value?
<clever> ah
<clever> weird, your trying to build a derivation over x, and then just use x?
<clever> no need to handle the failure specialy
<clever> qknight: it will already abort if the derivation fails
<clever> qknight: what are you trying to do?
<clever> id just throw an alias into .bashrc
<clever> that works
<clever> odd, not sure then
<clever> cinimod: try export TERM=xterm
<clever> qknight: mkDerivation returns a string pointing to where the derivation will be installed to, but its not yet known if it has passed or not
<clever> :D
<clever> but then you may as well not even hash it, users.users.clever.initialPassword = "hunter2";
<clever> you could use a secondary password there, so you can at least login and run passwd
<clever> yeah, thats the only downside
<clever> and then my pw is always right
<clever> i just set users.users.clever.initialHashedPassword
<clever> systemd-nspawn wont really work right away, the nixos inside the root has to be built with boot.isContainer=true;
<clever> ah
<clever> why do you want to imperatively set passwords before the first boot?
<clever> but that code is absent in the master version of the script
<clever> i think it wants the nixbldX users from the host
<clever> aha, then it will create users on the host and store the passwords on the guest!!
<clever> because of the umount, it will modify the guest passwd when it asks for the root pw at the end
<clever> and also line 236 un mounts them
<clever> but it wont persist, and the guest will create its own later
<clever> yeah, it uses a bind mount to "copy" the host passwd into the guest
<clever> i thought it was only directories
<clever> yeah, i was also surprised that files can be bind mounted
<clever> yeah, it mounted something over /etc/passwd
<clever> any bind mounts over passwd?
<clever> catern: what does "mount" say when ran both inside and outside?
<clever> ben: that will depend on if you have enabled or disabled mutable users

2017-07-18

<clever> tep
<clever> ah, it was -t
<clever> Apr 27 16:10:23 router kernel: rejected connection: IN=wan OUT
<clever> -- Logs begin at Mon 2017-04-24 18:42:51 UTC, end at Tue 2017-07-18 22:26:19 UTC. --
<clever> [root@router:/etc/nixos/nixcfg]# journalctl -t kernel -b 0
<clever> i think it might be in "-k kernel" or something like that
<clever> pshendry: what about just journalctl -f ?
<clever> though if you think it wont crash and its only a chown and chmod, that can owrk
<clever> the last guy i saw using activation hooks tried to do network, it errored out, and then that broke the entire boot process
<clever> it would probably be safer to use a one-shot systemd unit
<clever> nixos can only manage /etc and /nix
<clever> there is no way to manage things under /home with nixos
<clever> where does folder_name exist?
<clever> WinchellsM: by setting mode and uid on an environment.etc entry, you can control what user owns it
<clever> spinus: something came up, cant type much now
<clever> spinus: there is also the build slave stuff, and brb
<clever> spinus: nix-copy-closure can take a .drv from nix-instantiate, then you can run nix-store -r on that remotely
<clever> WinchellsM: rerun with -j1 to unscramble the download progress
<clever> 1.4.111 and 2.3.8 are the versions i get
<clever> WinchellsM: the names are non-obvious
<clever> pkgs/top-level/all-packages.nix: bittorrentSync20 = callPackage ../applications/networking/bittorrentsync/2.0.x.nix { };
<clever> pkgs/top-level/all-packages.nix: bittorrentSync14 = callPackage ../applications/networking/bittorrentsync/1.4.x.nix { };
<clever> pkgs/applications/networking/bittorrentsync/generic.nix: name = "btsync-${version}";
<clever> you would need to clone nixpkgs, checkout the right version for your host, and then edit that file
<clever> it looks like it should be doing entry.knownHosts
<clever> but with this syntax, all arguments are put into a set called args
<clever> { pkgs, config, ... } @ args:
<clever> on its own, the arguments are just dropped, so you cant access the things you havent named
<clever> NickHu: it makes it accept any argument
<clever> it downloads a given nar, and unpacks it to a new dir called <hash>-hello-<version>
<clever> gchristensen: and an example closer to what you wanted
<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> no nix.sqlite metadata is involved, no need for root, and you can just treat it as a tar replacement if you wanted
<clever> this will copy a to b, serializing it in the process
<clever> 2017-02-22 22:23:23< clever> $ nix-store --dump a | nix-store --restore b
<clever> all paths start at the root of $out, so $out/bin/foo exists as just "bin/foo" in the nar
<clever> and /nix/store/ isnt a prefix on the paths
<clever> its a custom format, that omits fields like uid/read/write/mtime
<clever> yeah, its not a tar file
<clever> gchristensen: one min, i have a trick somewhere
<clever> bennofs: oh, i think the -p was breaking it
<clever> so if you use cc and c++, it will work on both stdenv's
<clever> but the clangStdenv includes a wrapper called cc
<clever> dang, clangStdenv sets CC, but the normal stdenv doesnt!
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ nix-shell -E 'with import <nixpkgs>{}; clangStdenv.mkDerivation { name = "name"; }'
<clever> bennofs: i think $CC and $CXX are set right
<clever> S0rin: the nixPath entry in the configuration.nix lands in a file in /etc after the rebuild, then you must relaunch the shell
<clever> cinimod: the above creates an override on diagrams, to make it use a jailbroken version of cautious file
<clever> [clever@amd-nixos:~]$ nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [ pkgs.chart-unit pkgs.numhask pkgs.numhask-range ])" 'haskellPackages.diagrams-haddock.override { cautious-file = haskell.lib.doJailbreak haskellPackages.cautious-file; }'
<clever> and diagrams-haddock depends on cautious-file
<clever> its in cautious-file's cabal file
<clever> the problem isnt in your cabal file
<clever> the condition is right in the cabal file the error said it was in
<clever> [root@amd-nixos:/tmp]# grep directory cautious-file-1.0.2/cautious-file.cabal build-Depends: base >= 4, base < 5, directory >= 1.1, directory < 1.3, filepath >= 1.2, filepath < 1.4, bytestring >= 0.9, bytestring < 0.11
<clever> which cabal file did you read?
<clever> builder for ‘/nix/store/ghy607jzpy4ifhxpl486ffgvxbb7gclk-cautious-file-1.0.2.drv’ failed with exit code 1
<clever> the output in the console when it gives the error
<clever> there should be more lines that give context
<clever> pastebin the entire error
<clever> from which derivation?
<clever> try restoring $TERM to a more normal value
<clever> cinimod: i'm thinking this, now diagrams will be in path, rather then ghc
<clever> [clever@amd-nixos:~]$ nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [ pkgs.chart-unit pkgs.numhask pkgs.numhask-range ])" haskellPackages.diagrams-haddock
<clever> and `ghc-pkg list` ?
<clever> cinimod: error: attribute ‘numeric-ode’ missing, at (string):1:106

2017-07-17

<clever> i think adding it to the propagatedBuildInputs of gcr would be best in this situation
<clever> but thats not in the search path when building pinentry
<clever> because pkg-config is dumb, and wants to find the glib.pc file as well
<clever> you need to add glib to the buildInputs for pkg-config to allow you to use gcr
<clever> jtojnar: thought so, pkg-config is weird like that
<clever> jtojnar: what if you try to ask pkg-config for the ldflags of gcr-base-3?
<clever> jtojnar: investigating...
<clever> can you gist the nix files you have modified?
<clever> jtojnar: is pkgconfig also in the builtInputs?
<clever> yegortimoshenko: it appears to do absolutely nothing
<clever> whatever that is, it needs to be added to the buildInputs of the package
<clever> and --pure isolates it better
<clever> so it was only working because something you installed was leaking in
<clever> jtojnar: try adding --pure to the nix-shell
<clever> which is always a subset of all of your build-time inputs
<clever> tnks: nix will just auto-detect what you need at runtime, by what paths exists in $out when your done
<clever> tnks: there is also the fact, that you cant really ever define the runtime deps
<clever> tnks: so if somebody ever tries to cross-compile your package 2 years down the road, it will try to make a build of cmake for the wrong platform, then run that on a cpu that cant run it
<clever> but most of the time, your doing a native build, so the buildInputs are just transparently appended to the nativeBuildInputs
<clever> tnks: and buildInputs come from the target arch (all libs go here)
<clever> tnks: when cross-compiling, nativeBuildInputs come from the host arch (cmake goes in there)
<clever> tnks: no way to merge derivations, you would need to put the ghcWithPackages into the buildInputs of a new derivation, that also depends on the python things
<clever> alex-v: id just throw strace at it, but that will generate 1000's of lines of logs, and then you need a pastebin
<clever> i cant think of anything else to check
<clever> those things are usually off by default
<clever> alex-v: anything like apparmour/gesecurity/selinux active?
<clever> alex-v: dmesg?
<clever> alex-v: and what about the mount for /opt/revr/tmp?
<clever> alex-v: or the output of dmesg?
<clever> alex-v: what about the output of mount?
<clever> alex-v: how are you able to access irc but not a pastebin?
<clever> nixer: you can also just add the module to the imports of a configuration.nix
<clever> nixer: --eval maybe, but it wont confirm things like the mkOption calls having valid arguments
<clever> alex-v: what does this output?
<clever> alex-v: (mount ; ls -lha /nix/store ) | curl -F 'text=<-' http://nixpaste.lbr.uno
<clever> alex-v: why can you not access gist?
<clever> alex-v: can you gist the entire error?
<clever> alex-v: if something was ran as root in the past, the ownership may be mixed
<clever> alex-v: does the user own everything in the store?
<clever> yeah
<clever> bennofs: i think https://hackage.haskell.org/package/th-lift makes everything simpler though
<clever> bennofs: pretty sure only string worked with lift when i was messing with it
<clever> probably need to dive into more complex parts of it, or use the th-lift thing i saw somewhere
<clever> i have noticed that out of the box, template-haskell can only insert a plain String (a linked list of characters!) into the source, but not any other type
<clever> i'm pretty sure nix flattens the array down to a space seperated list, and then your hosed
<clever> what about how the stdenv treats $buildInputs as a space seperated list of inputs?
<clever> i believe its invalid to have a space in the name of a derivation, so even $out/bin would be safe
<clever> Infinisil: bash is a bit weird, and should eval both of those identically
<clever> qknight: its currently in a let block, so there is no way to reference it
<clever> qknight: you would need to expose the config as its own attribute within the config attrset
<clever> yeah
<clever> the-kenny: ah nice, logs of juicy details in there
<clever> that has the size of each partition
<clever> and cat /proc/partitions
<clever> setting the format to raw removes the restrictions
<clever> and given that its usb, its very likely to jump around anyways
<clever> i try to do everything with uuid or label, so it doesnt matter
<clever> in theory, if the guest writes the correct headers to the file, qemu can start to interpret it as a copy-on-write image of something else, and read an attacker controlled path
<clever> may also need a format=raw
<clever> yeah
<clever> -drive index=3,id=usb,file=/dev/sdc
<clever> to just directly expose the block device as a whole
<clever> you can also -drive /dev/sdc i think
<clever> ah
<clever> dont think so
<clever> qemu does also have an option to emulate a usb drive if it still needs to be over usb
<clever> sphalerite[m]: also, i would just use -drive to create a virtual drive, then dd it to the usb stick after its shutdown
<clever> i would just chown the dev node on the host, no need to mess with udev
<clever> oh, and rules.d is read-only, no other option
<clever> sphalerite[m]: either add it to configuration.nix and "nixos-rebuild test", then undo the config change
<clever> yegortimoshenko: there are no stable channels for darwin, only nixpkgs-unstable is officialy supported
<clever> `ghc-pkg list | wc -l` -> 40
<clever> tnks: and in here, are symlinks to every package in the closure of shake
<clever> lrwxrwxrwx 1 root root 101 Dec 31 1969 array-0.5.1.1.conf -> /nix/store/8v64zpyci6rgrzzbhc2bfa911yfmnfw5-ghc-8.0.2/lib/ghc-8.0.2/package.conf.d/array-0.5.1.1.conf
<clever> [nix-shell:~/apps/hydra-configs]$ ls /nix/store/7w38kjm300d6mwbc0y5hf1mv3khdh7bs-ghc-8.0.2-with-packages/lib/ghc-8.0.2/package.conf.d/ -l
<clever> building path(s) ‘/nix/store/7w38kjm300d6mwbc0y5hf1mv3khdh7bs-ghc-8.0.2-with-packages’
<clever> [clever@amd-nixos:~/apps/hydra-configs]$ nix-shell -p 'haskellPackages.ghcWithPackages (hpkgs: [ hpkgs.shake ])'
<clever> tnks: but ghc is very different, you use the ghcWithPackages function to create a special instance of ghc, that has those packages in its default search path
<clever> tnks: for both python and gcc, nix will mutate the search path (the include path or pythonpath), based on the buildInputs
<clever> tnks: everything ran after this point up setup.sh will then be visible
<clever> tnks: this creates a runCommand derivation, that depends on simplejson and nose, and also sets a preHook that turns on a bash debug feature
<clever> nix-shell -E 'with import <nixpkgs> {}; runCommand "dummy" { preHook = "set -x"; buildInputs = [ pythonPackages.simplejson pythonPackages.nose ]; } ""'
<clever> and also anything in the stdenv, so the setup-hook for gcc gets sourced
<clever> the setup-hook for package1 and package2, and everything listed in the propagated inputs, recursively
<clever> so the phases of nose, only become available if you nix-shell '<nixpkgs>' -A pythonPackages.nose
<clever> but the setup hook is for when it gets put into the inputs of another package
<clever> yeah, the phases are only for build time
<clever> which iterates over all inputs, and adds them to PYTHONPATH
<clever> tnks: and because its acting like python was in the list of inputs, it will source this script
<clever> /nix/store/zq0lf0fdc7n12zcdcs2qq3viz6mc87vr-python-2.7.13/nix-support/setup-hook
<clever> tnks: because of this file, it will behave as if you had added coverage, python, and setuptools to the -p list as well
<clever> /nix/store/5q51zmjqrcz8qn7kspi5qhcldnzy1x1l-python2.7-coverage-4.0.1 /nix/store/zq0lf0fdc7n12zcdcs2qq3viz6mc87vr-python-2.7.13 /nix/store/hr25ww5b8jcgjz5wmmqb4zqm8yz2ipnx-python2.7-setuptools-30.2.0
<clever> [nix-shell:~/apps/hydra-configs]$ cat /nix/store/2qqn05m1nj2q1p7infamx3dhpzxjlmpk-python2.7-nose-1.3.7/nix-support/propagated-native-build-inputs
<clever> do you have an example nix-shell i can run on this end?
<clever> only the setup hooks, which are defined seperately
<clever> it will run neither of the shell hooks
<clever> it might also be setup by a setup hook in python, try to print it before and after the nix-shell and see what happens
<clever> tnks: it wont run the phase things for anything listed
<clever> tnks: -p creates a new derivation, using runCommand, that has everything listed in the buildInputs
<clever> yeah, i see
<clever> ah yeah
<clever> not what the hash is hashing over
<clever> as base32 text, or as raw binary
<clever> its more about how the hash is displayed
<clever> bennofs: so it turns into a 20 byte string of raw binary, then the hashmap might be a little faster
<clever> bennofs: something else i have been thinking of, is taking the hash in the <hash>.narinfo, and undoing the base32
<clever> yegortimoshenko: nix-build -E 'with import <nixpkgs>{}; callPackage ./default.nix {}'
<clever> dtzWill: all narinfo files go into a hashmap in ram, while the nar files are currently uncached (i plan to cache them to disk)