2017-05-18

<clever> LnL: yep, ignoreCollisions makes it complain a ton, but not actualy produce a /etc
<clever> LnL: i'm dealing with a pair of etc/ImageMagick-6's
<clever> LnL: thats because your dealing with etc/ImageMagick-6 and etc/ImageMagick-7
<clever> kiloreux: i'm trying to make it ignore everything that isnt /bin/
<clever> LnL: https://gist.github.com/cleverca22/dcda8193ccff05e3a1e7c53f22b4e29a this complains about a collision in /etc/
<clever> the if statement will need to check which version of imagemagick you want, i dont know where you save that
<clever> LnL: trying another example, but buildEnv with pathsToLink=["/bin"]; is still trying to link /etc
<clever> and i gave him a very similiar example yesterday (see the gist history)
<clever> LnL: very similiar to what i linked above
<clever> kiloreux: only the yourscript package will be installed, not imagemagick{1,2}
<clever> kiloreux: line 3-7 of the file i just linked, that switches the env out
<clever> Myrl-saki: it has to be loaded with callPackage from another default.nix, see the directory up one level
<clever> kiloreux: one minute
<clever> kiloreux: your supposed to just reference imagemagic from the scripts that use it, rather then installing it
<clever> let me try something on this end
<clever> kiloreux: line 33 of the old.nix, you rename things to 1.2 again
<clever> kiloreux: line 33 of the new file, you rename everything to 1.2
<clever> Myrl-saki: you may want to copy more, depending on how much code the project has, ${./.} would get the entire directory
<clever> Myrl-saki: that copies the source file from the dir the nix file is in, to the dir the build is happening in
<clever> dash: lol, never seen that before
<clever> lol
<clever> gchristensen: in theory, rebooting every computer on the plannet at once would exterminate the virus, lol
<clever> gchristensen: that worm is also completely unable to make the infection last, it only lives in ram
<clever> yeah, if you cant find another recent ticket
<clever> no need to wait for replies
<clever> gchristensen: thats a recipe for backbone breaking levels of traffic, because every infected node can just spray the internet blindly
<clever> gchristensen: there was an sql exploit many years ago, that could infect a machine with a single udp packet
<clever> gchristensen: heh, nice
<clever> { inherit foo; } is identical to { foo = foo; }
<clever> inherit will work on any value
<clever> johnramsden: pass some arguments on using inherit, when calling the base one
<clever> dev -> /nix/store/bfv2kva3jl2hqc8fh0y75nrd77c7hasl-libffi-3.2.1-dev
<clever> this derivation produced the following outputs:
<clever> nix-repl> :b libffi
<clever> dhess`: for ghc?
<clever> johnramsden: i think you may have /var/lib/containers in the list twice
<clever> i think you want { mount = bed; }
<clever> valid*
<clever> which is not a value key=value attrset
<clever> you are passing it { "astring" }
<clever> johnramsden: i think bed is of type string, but makeZfsDataset wants an attrset
<clever> johnramsden: line 27 is calling a function, and passing it an invalid attribute set
<clever> making them relative to the file the path was in
<clever> if you put any relative paths into a file, nix will turn them into absolute for you
<clever> it will always be absolute
<clever> alphor: if you try to append a string to a path, it will parse the result as a path, and force it to become absolute
<clever> its both path and string i think
<clever> alphor: you can concat a string to a path, ./. + "/foo/bar"
<clever> alphor: nix will import a copy of that path to /nix/store, and substitute in the storepath
<clever> just dont give the argument to a command
<clever> that will temporarily turn binary caches off
<clever> --option binary-caches ""
<clever> plll: what does 'git diff' say has changed?
<clever> plll: there are some ways, but first, what command are you running?
<clever> i think
<clever> postInstall = ''for x in $out/bin/*; do mv -v $x $''{x}-1.2;done'';
<clever> oops, and the ${ needs to be escaped
<clever> postInstall = "for x in $out/bin/*; do mv -v $x ${x}-1.2;done";

2017-05-17

<clever> kiloreux: you could modify the postInstall for each imagemagick, to rename everything in $out/bin/
<clever> kiloreux: with this, you can now nix-shell default.nix -A env1
<clever> oops, no, needs to be a bit more complex
<clever> kiloreux: its much simpler to just use nix-shell like this, nix-shell default.nix -A imagemagick2
<clever> kiloreux: you would need to write a custom package, that makes a renamed version of every binary
<clever> plll: nix will detect if things have changed, and if its using the cache, then maybe you arent overriding nixpkgs right, or the change you made truely has no effect
<clever> only one version of imagemagic can be used system wide
<clever> which means they wont collide
<clever> kiloreux: this allows you to use both of them, without having to install them
<clever> no idea, the nix expression in the pastebin should just default to the host arch
<clever> kiloreux: what happens if you run nix-store --verify --check-contents
<clever> ah, id try to avoid making it look artificialy big
<clever> i just make a PR and wait for somebody else to do it
<clever> Sonarpulse: i'm not up to date on what the rules are about merging things in nixpkgs
<clever> kiloreux: build it with -K and then check the config.log file it made in /tmp/
<clever> kiloreux: what is the exact error its giving?
<clever> and all it does right now, is enable a bunch of firmware
<clever> johnramsden: it will import that file into your config, https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/scan/not-detected.nix
<clever> and losetup would require root, so you would need to use the helper to run everything in a vm
<clever> dd cant do that, so it defaults to expecting 1.5 to be on the next sector
<clever> manveru: the stage1 in the MBR needs to have a certain offset filled in, with the LBA location of stage 1.5
<clever> but the state of the pci device must be untouched, for the windows driver to boot
<clever> vt-d/iommu is required to safely perform dma, so the guest cant attack the host
<clever> johnramsden: thats a seperate requirement
<clever> johnramsden: the pci card state must be untouched for windows to boot, so you have to reset the entire host if windows needs to reboot
<clever> johnramsden: ive tried that before, and if your motherboard doesnt support pci device reset, your better off just dual-booting
<clever> thats about the only downside i can think of
<clever> then the source can be GC'd
<clever> but you could copy that one .rules file to a new derivation, and refer to the copy
<clever> samueldr: the entire source will be kept around
<clever> AndreasO: it has to be written to sdb, not sdb1
<clever> directly to the root of the device?
<clever> AndreasO: how did you image the usb?
<clever> kugelblitz: https://nixos.org/nixos/options.html#udev.extraru
<clever> [root@amd-nixos:~]# nix-env -p /nix/var/nix/profiles/per-user/root/channels -q
<clever> nixos-17.09pre106299.7f3b857d0d
<clever> nix-repl> pkgsi686Linux.mumble_overlay
<clever> philipp[m]: which has 32bit versions of everything in nixpkgs
<clever> philipp[m]: there is also pkgsi686Linux
<clever> zsnes = callPackage_i686 ../misc/emulators/zsnes { };
<clever> philipp[m]: if you load the file with callPackage_i686, everything it gets will be 32bit
<clever> :)
<clever> hke: nix-env will read the other config.nix, the error should give you the path
<clever> there is a pr for that
<clever> and with each step, it applies less overrides, until it has built everything with the defaults in nixpkgs
<clever> then at 150, it uses that as a normal stdenv to build a binutils/perl, and anything else the next stage asks nixpkgs for
<clever> then it uses that 1st dummy stdenv as a base, applying a few overrides (lines 128-146) to make a dummy stdenv that just uses the bootstrap tools
<clever> gchristensen: this file starts out on line 108, to create a dummy stdenv that has no usable tools
<clever> but ghc wont need anything that crazy, because it has a fully working stdenv to stand on
<clever> this uses a raw call to derivation to build that
<clever> gchristensen: and then using only plaintext scripts, it fixes the tools to work under nix
<clever> gchristensen: i believe in total, this takes in a staticly linked busybox, not even in a tar, and the bootstrap tools tarball
<clever> that allows patchelf to fix itself
<clever> and if you poppulate LD_LIBRARY_PATH, you dont have to fix rpath
<clever> if you directly run ld.so on an elf binary, you dont have to fix the ld.so path
<clever> and includes a script that can patchelf patchelf without needing a patched patchelf
<clever> gcc's bootstrap puts the entire closure into a single tar
<clever> gchristensen: i'm guessing you just need to tar up a ghc build from nixpkgs, then patchelf it at a later point
<clever> gchristensen: then we can stop relying on somebody to put out a bootstrap thats 3 generations old
<clever> gchristensen: i think it would help a lot, if nixpkgs could make its own bootstraps, like it does with gcc
<clever> LnL: there is also a helper function in nix (not bash), called substituteAll, which just calls the bash version for you
<clever> simpler then trying to escape everything for an echo
<clever> and everything you put into the attribute set becomes an env variable
<clever> substituteAll will replace @out@ with the value of $out, and so on
<clever> then you can call substituteAll on it
<clever> if you already have the bulk of the text in a file (and src could be a writeText, but a bare file is probably simpler)
<clever> LnL: you reminded me that stage-1 and some other nearby scripts use something like this
<clever> oh right, there is a second way
<clever> you can also use >> to append to the file, or normal bash heredoc's
<clever> this makes 1 line out of 2
<clever> normal bash, \ at the end of each line
<clever> that doesnt change the fact that bash runs each line seperately
<clever> thats a bash script, that runs echo, then bind
<clever> the problem is the newlines you added
<clever> rcschm: can you gist the full nix expression and the error output?
<clever> rcschm: try runnng this, then look at the result file it makes
<clever> nix-build -E 'with import <nixpkgs>{}; runCommand "name" {} "echo foo bar $out baz > $out"'
<clever> radvendii: it will write foo bar <ownpath> baz to the output file
<clever> rcschm: $out is the path that the derivation will output to
<clever> rcschm: probably would be simpler with this: runCommand "name" {} "echo foo bar $out baz > $out";
<clever> radvendii: can you gist the nix expression and i can look at it here
<clever> ah, sounds like its a collision within the ghc layers, not at the normal linux $PATH
<clever> it will ignore the collision, so whatever appears first in $PATH will win
<clever> radvendii: then nix-shell should give you a shell with ghc and everything
<clever> radvendii: with import <nixpkgs>{}; runCommand "shell" { buildInputs = [ (haskellPackages.ghcWithHoogle ....) ]; } "exit 1"
<clever> radvendii: you should be able to write a file like this in shell.nix
<clever> Rotaerk: yeah
<clever> Rotaerk: and 7.4.2 is currently coming from a tarball on on the haskell site
<clever> Rotaerk: and ghc 7.8.4 needs ghc ghc 7.4.2 to build
<clever> Rotaerk: ghc 8.0.2 needs ghc 7.8+ to build
<clever> gchristensen: but ghcHead needs 7.10+, so there will always been one at that level
<clever> gchristensen: was able to get some of the ghc's to use an older boostrap, so there is 1 less link in the chain
<clever> and in either case, you can just set the mountPoint option
<clever> and it will internally treat it like you did fileSystems.unnamed-1 = ....
<clever> johnramsden: you can pass it a list, instead of an attribute set
<clever> i am creating it right there, not reading it
<clever> and concating 2 lists
<clever> your just manualy creating the same thing that the map is returning
<clever> fileSystems = [ { mountPoint="/"; device="foo"; fsType="bar"; } ] ++ (map ....);
<clever> oops, and a ] before ++
<clever> johnramsden: fileSystems = [ { mountPoint="/"; device="foo"; fsType="bar"; } ++ (map ....);
<clever> johnramsden: need to either use 2 files and imports, or switch them all over to a list
<clever> so you need to add nfs to the nixos config, and then supportedFilesystems isnt required again
<clever> it shuts the network off before trying to umount, and then its literaly imposible to shut off properly
<clever> but even then, systemd doesnt like it when i manualy mount nfs
<clever> about the only time i need supportedFilesystems is when i want to add nfs support
<clever> yeah
<clever> johnramsden: boot.supportedFilesystems will default to every fsType listed in fileSystems
<clever> johnramsden: something else that i see a lot of people overlook is like 215
<clever> overrideAttrs
<clever> Ralith: you could maybe make an override that sets outputs=["out"];
<clever> johnramsden: oh, line 119, if you try to set autoResize=true on an entry, it just adds "x-nixos.autoresize" to the options list instead
<clever> it will add a device="proc"; for you
<clever> so if you give it { mountPoint="/proc"; fsType="proc"; }
<clever> if the fsType is one of the special ones, device defaults to fsType
<clever> johnramsden: oh, line 63 is neat
<clever> and since unnamed-1 isnt a valid mountPoint, a new one has to be set
<clever> so the list items just silently turn into attributes, unnamed-1, and so on
<clever> on second thought, i think the nixos option framework will silently invent keys, fileSystems.unnamed-1.1.fsTtype
<clever> but if you pass it a list, it has no key, so you need to set mountPoint directly
<clever> johnramsden: and line 62 sets the default mountPoint to the key, "/"
<clever> johnramsden: and line 28, it will call coreFileSystemOpts and pass it the key "/" and config {device="/dev/sda1; fsType="ext4";} for each filesystem
<clever> johnramsden: the type is set to loaOf, list of attribute something something
<clever> johnramsden: but nixos is just going to turn the attrset back into a list anyways
<clever> { a = 1; }
<clever> nix-repl> lib.listToAttrs [ {name="a"; value=1; } ]
<clever> i think
<clever> nix-repl> lib.listToAttrs
<clever> but its not needed now
<clever> there is also a function that does what you wanted
<clever> johnramsden: and it will internaly use the key from the attrset as a default mountPoint
<clever> johnramsden: some options in nixos can be either an attrset or a list
<clever> johnramsden: pushed a change, i think it does what you want now
<clever> johnramsden: i believe the fileSystems attr in nix supports a list
<clever> so its all up to the ghc build ignoring the lack of colour
<clever> but its only putting it into buildInputs, which i think can silently skip nulls
<clever> at least 802, doesnt flag it as optional with a ?null
<clever> it may just disable that feature
<clever> dhess`: the current state of ghc's: https://gist.github.com/cleverca22/81e6f84355412f8e13c685a1bac6f6d3
<clever> 1 less dependency in the chain, but its still a total of 2 extra ghc's
<clever> dhess`: but i think i have 802 building directly with 784 now
<clever> dhess`: 802 was building with 7103, which built with 784
<clever> configure: error: GHC version 7.8 or later is required to compile GHC.
<clever> dhess`: i believe i am now building hscolour using 704
<clever> it will use 32bit everything, and if sandboxes are on, uname will even lie and claim its a 32bit cpu
<clever> yeah, just set system with argstr
<clever> oops, i fixed ghchead, then tested 802
<clever> strange, it grabbed 802 from the binary cache
<clever> gchristensen: let me throw nix-build at it here and see what happens
<clever> getting an hscolour right out of the bootstrap would be more complex, but make things more direct
<clever> and 704 already has a full packageset, so no need to deal with hscolour changes
<clever> but that depends on if 704 can build 802
<clever> gchristensen: i'm guessing you can just change the 7103 on line 67, to 704, and that will cut it down to only 1 intermediate ghc
<clever> gchristensen: it seems simple enough to try changing things and see if it builds, somebody just needs to invest some cpu hours to try building it
<clever> gchristensen: look at which ghc each of them uses as the bootPkgs or ghc input: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/haskell-packages.nix#L23-L86
<clever> 2017-05-16 20:44:37 < clever> so building ghc802 requires building 3 other ghc's, and patchelfing a binary
<clever> 2017-05-16 20:44:21 < clever> then ghc802 uses ghc7103, which uses ghc784, which uses ghc742, which uses ghc704binary
<clever> gchristensen: ive also noticed some insanity in the dependancy chain in nixpkgs ghc's
<clever> and half a dozen gists from when i keep making new examples to link
<clever> enless you count 2 dozen zfs snapshots
<clever> i currently dont have config.nix saved anywhere
<clever> so it can recreate things every time
<clever> and because its a nix file, it supports (and saves) the full nix expression
<clever> adelbertc: and it will atomicly install/update/remove everything in the list
<clever> adelbertc: if i put this into config.nix, i can nix-env -iA nixos.mystuff
<clever> adelbertc: thats why i prefer to always use a buildenv when possible
<clever> adelbertc: so -e can only match on the name, and -u has to search for the name and guess
<clever> adelbertc: after installing, the attribute path is lost

2017-05-16

<clever> ah
<clever> dhess`: as a first step, i would try making a ghc without hscolour, and see if it can build using your binary
<clever> you cant build them in parallel on hydra
<clever> but it forces hydra to serialize everything
<clever> i'm not 100% sure why its got so much overhead, it might be that you need a minimum version to build each
<clever> dhess`: ar is over in binutils
<clever> yay overhead!
<clever> so building ghc802 requires building 3 other ghc's, and patchelfing a binary
<clever> then ghc802 uses ghc7103, which uses ghc784, which uses ghc742, which uses ghc704binary
<clever> its using the binary ghc on lines 35-45, to make the 1st stage of nixpkgs ghc, without hscolour
<clever> but why are the binary ones not getting their own packages
<clever> and that creates a haskellPackages tree, built against that compiler
<clever> it calls haskell-modules, and passes it a ghc and compiler-config
<clever> dhess`: line 111 and onward
<clever> so we want to see where packages.ghc784 came from
<clever> because of the rec on line 53, the inherit on 55 is referencing 54's bootPkgs
<clever> dhess`: ah, i see what you mean, hscolour is being added to some of them
<clever> a list of compilers
<clever> so haskell-packages.nix .packages.<ghc version> should be an attrset
<clever> haskell = callPackage ./haskell-packages.nix { };
<clever> dhess`: ok, so the main haskellPackages set comes from https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L5315
<clever> dhess`: let me double-check some of the expressions
<clever> dhess`: i'm guessing so ghc can colorize the haskell in error messages
<clever> they didnt spell color right!
<clever> dhess`: that lets you access the bootPkgs as the .bootPkgs attribute on the derivation, without it directly impacting the hash of the derivation
<clever> kk
<clever> dhess`: yep
<clever> maurer: or if you can mmap something and use dma
<clever> maurer: sometimes, the performance is just better if your passing binary to ioctl, rather then writing data to a file directly
<clever> kiloreux: line 6-16 is an attribute set, and each line inside that uses pkgs.callPackage to load another nix file up
<clever> one min
<clever> then you can use nix-env -iA <attrname> to pick one
<clever> if the default.nix returns an attribute set with 2 derivations in it
<clever> you can use it the same way there
<clever> and in nixos, you may want to avoid installing, and just reference things by absolute paths
<clever> kiloreux: you would need to rename the binaries, or they will conflict in $PATH and only 1 will ever work
<clever> but nix-env is an exception, you would need -f '<nixpkgs>' to make it check the path
<clever> add a package name or -A <attrname> at the end
<clever> kiloreux: you need to tell it which package to install
<clever> so it doesnt need a fork to recompile things
<clever> i have seen some IDE's that merge the compiler into the editor
<clever> harder to cause syntax errors with the editing, if you just grab the entire tree as one unit
<clever> Infinisi1: i do think it would be usefull to have the ability to cut&paste chunks of code whole, and having an AST aware editor would let you select a node, and all children at once
<clever> joachifm: nix wont care, but if the user ever wants to read the file again, they will
<clever> joachifm: i dont think it supports comments and whitespace
<clever> Infinisi1: i have been wanting an AST library for nix, so i can parse configuration.nix, programaticaly apply changes, then serialize it back out
<clever> dtz: and that auto-detection stuff works pretty well so i just left it like that
<clever> dtz: yeah, i had installed it for c++ code, then never got around to configuring it properly
<clever> dtz: but its a fairly dumb auto-complete, has no sense of context
<clever> dtz: so if i open <nixpkgs/lib/lists.nix> with :tabe, i can auto-complete every lib function
<clever> dtz: youcompleteme in vim is able to auto-complete any word in any file currently open
<clever> Ivanych: /usr/bin/env doesnt exist in a sandbox, you need to run patchShebangs on the directory the script is in
<clever> joepie91: and your image doesnt load