2017-03-26

<clever> rmrfroot: heh,and this system was installed on the 24th
<clever> rmrfroot: on my laptop, it goes back to dec 24th
<clever> rmrfroot: it is, ive seen it grow to 4gig
<clever> YellowOnion: all logs are in the journal, so you need journalctl to read them
<clever> mounty: there is a project underway to redo hydra in haskell
<clever-afk> simendsjo: you still need to access it within the pkgs argument passed to configuration.nix on line 1
<clever-afk> mounty: services.hydra.enable = true;
<clever-afk> rotaerk: a list of a few of them
<clever-afk> gnupg gnupg1 gnupg1compat gnupg1orig gnupg20 gnupg21

2017-03-25

<clever-afk> simendsjo: https://github.com/NixOS/nixpkgs/issues/14721 this is it
<clever-afk> simendsjo: i saw something about that on an issue, one min

2017-03-24

<clever> praduca: as a guest or host?
<clever> c74d: you can make it depend on other variables in the current file, like a let block of booleans, but it cant depend on the config argument passed in
<clever> c74d: ah
<clever> c74d: so its always imported, but turns itself on/off
<clever> c74d: dont think thats possible, you want to use mkIf inside the target module
<clever> c74d: and its always the nixpkgs that the nixos/default.nix came from
<clever> c74d: i believe it uses the channel called nixos
<clever> maurer: you will just need to manualy fill in the pgsql config file, and configure it to play nice with its other version
<clever> maurer: with code like this, you can create a new systemd unit to run a given command as a service
<clever> maurer: one min
<clever> maurer: nixos doesnt have code for that right now
<clever> maurer: if you can just run a second pgsql and change the $HYDRA_DBI on hydra, that could do it
<clever> LnL: yeah, but you can forcibly drop that context via builtins.unsafeDiscardStringContext
<clever> maurer: and also, the sandboxes in nix basicaly create containers on the fly, for every build
<clever> maurer: so building never happens inside the container
<clever> maurer: i'm pretty sure the container just connects to /nix/var/nix-daemon/socket and tells the host to do all building
<clever> maurer: nixos containers already share the /nix/store of the host, so its still doing that anyways
<clever> maurer: id normaly add the user to nix.trustedUsers in configuration.nix, but there can only be 1 nix-daemon, so it may need to go on the host, and now the usernamespace is making it a mess
<clever> maurer: probably, maybe give it ssh to the host?
<clever> maurer: that should do it
<clever> maurer: yeah, and if your using nixos, thats done via configuration.nix, nix.buildMachines i believe
<clever> maurer: oh, you didnt configure a build slave
<clever> maurer: and hydra doesnt build on localhost by default
<clever> maurer: check the journal
<clever> either look it up, or guess until it works
<clever> [clever@amd-nixos:~]$ ls -lhRL /run/opengl-driver/ | gist -p -
<clever> benzrf: oh, and it expects the _dri.so files to be in the dri/ sub-dir
<clever> gallium_dri.so i965_dri.so mesa_dri_drivers.so nouveau_vieux_dri.so r600_dri.so radeonsi_dri.so vmwgfx_dri.so
<clever> [clever@amd-nixos:~]$ ls /run/opengl-driver/lib/dri/
<clever> benzrf: no, the whole point of /run/opengl-driver/lib is to avoid any rebuilding
<clever> maybe strace -f -e open
<clever> benzrf: id try strace next, strace -e open yourthing
<clever> dash: https://gist.github.com/cleverca22/29c05299984b9099983fa9d31f22117c it is automaticaly creating these snapshots at regular intervals, and expiring them when they hit certain ages
<clever> dash: i would just use zfs and enable auto-snapshoting
<clever> this is the value on nixos
<clever> [clever@amd-nixos:~]$ echo $LD_LIBRARY_PATH
<clever> /run/opengl-driver/lib:/run/opengl-driver-32/lib
<clever> benzrf: it should contain a directory, that will be searched to find dynamic libs
<clever> benzrf: but if glxgears gives 60fps, then its actualy using v-sync, and properly doing hardware render
<clever> benzrf: also, glxgears can be misleading, you can get 300fps from software rendering because of how simple it is
<clever> 2016-11-19 17:48:08< clever> greymalkin: opengl apps expect this derivation to be at /run/opengl-driver/ https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/hardware/opengl.nix#L13-L20
<clever> benzrf: may need to change which mesa it uses though
<clever> 2016-11-19 17:50:41< clever> if you run nix-build on this, and point LB_LIRARY_PATH to wherever it lands, it should work
<clever> 2016-11-19 17:50:22< clever> greymalkin: https://gist.github.com/cleverca22/b90233340aed91962e300d9398af78b2
<clever> benzrf: checking gist to see if i can find an old answer i had
<clever> one not found?
<clever> what does ldd say when ran on /run/opengl-driver/lib/i965_dri.so ?
<clever> but ive sort of run out of not-nixos machines i could test on, lol
<clever> it could possibly be handled via ~/.nix-profile/lib/ and use profile.d/nix.sh to do something
<clever> contrapumpkin: the problem, is that if you try to handle this at link-time, nix will need to re-compile it for your gpu, and now the binary cache is of no use
<clever> packages compiled with nix assume that /run/opengl-driver/lib has the libGL files
<clever> and thats why the directory is just missing
<clever> benzrf: it lets nixos switch out the ati libGL for an nvidia libGL at runtime, without nix trying to recompile every package under the sun
<clever> benzrf: so you need to get them from /usr/lib/
<clever> benzrf: i think its more important that the version matches the xorg, and chances are nixpkgs will have a different version
<clever> benzrf: and add it to LD_LIBRARY_PATH
<clever> benzrf: yeah
<clever> is it giving a clear linker error saying what wasnt found?
<clever> they need to be compatible with the xorg side of the gpu drivers
<clever> benzrf: which libs you put there depend on what gpu you have
<clever> benzrf: opengl is a bit tricky to get working outside of nixos, it relies on the libGL files being in /run/opengl-driver/lib
<clever> ]$ nix-instantiate --find-file nixpkgs
<clever> /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
<clever> gchristensen: and nix uses that to figure out what needs to be built first, or copied to a build slave, or put into the sandbox
<clever> gchristensen: every string in nix has context, a list of storepaths it depends on
<clever> gchristensen: ah, thats adding some context, so you depend on the .drv itself (not its outputs)
<clever> gchristensen: line 719 is where it sets the .drvPath attribute to be the string drvPath, not sure what the = is doing, *reads more*
<clever> gchristensen: at a glance, i dont think the drvPath attribute has any context, so it shouldnt trigger builds
<clever> gchristensen: checking the source
<clever> gchristensen: nix-build was a perl script that did nix-instantiate then nix-store -r
<clever> "/nix/store/lbqz5s0q65y7gsqhn35by0lf2a9mxrnh-hello-2.10.drv"
<clever> nix-repl> hello.drvPath
<clever> and nixos will concat the lists from all of them
<clever> yeah, you can still set environment.systemPackages in each file
<clever> so you can just split the settings up as you want, and then list which files to use for this machine
<clever> tjg1: and each module has the exact same syntax as configuration.nix
<clever> tjg1: you can list other nixos modules in the imports list, like imports = [ ./vim.nix ./core.nix ];
<clever> ive not done much with docker
<clever> yeah, could just change it to hbase and it should work
<clever> ertes: another derivation, that produces the thing you want to link to
<clever> ertes: runCommand "hbase" {} "mkdir -p $out/opt ; ln -sv ${hbase-raw} $out/opt/hbase";
<clever> ertes: dont think so, but runCommand would make that simple
<clever> obadz: this is how avahi handles its own dbus service, and dbus cant seem to reload, so you may need to reboot to apply it

2017-03-23

<clever> sphalerite: ah, not sure how mono plays into it
<clever> dtluna: because lua is in the buildInputs, -llua just finds it without anything special
<clever> dtluna: a random lua program i wrote in nix: https://gist.github.com/cleverca22/33b1552fcab3bd9a7f29a3e1c3ab4f10
<clever> nixpkgs-channels updates after the build passes on hydra
<clever> Unode: you want the 16.09 branch on nixpkgs-channels
<clever> bkchr: so it cant be cast to a string without passing it thru builtins.toJSON or similiar
<clever> bkchr: the srcInfo on line 2 is probably a set, not a string
<clever> bkchr: removing the true on line 5 might fix things
<clever> bkchr: so that boils down to "let ... in true stdenv.mkDerivation ..."
<clever> bkchr: you are attempting to run warn (which returns true) on a derivation
<clever> bkchr: can you paste the line of code your using?
<clever> ndowens08: i use it more for development, i can nix-shell, then make && ./foo every time i edit the code, until it does what i want
<clever> ndowens08: it gives you a shell with the same env variables that nix-build uses for the build, so you can test ./configure && make
<clever> Yaniel: you can always re-run zsh under nix-shell
<clever> bkchr: oh, and if you only care about nixos support, you can just cheat: /run/current-system/sw/share/emacs/site-lisp/nix-mode.el
<clever> bkchr: nix needs to generate a config file that refers to it, and it sounds like emacsWithPackages automates that
<clever> bkchr: eval "${pkgs.nix}/share/emacs/site-lisp/nix-mode.el" in nix to get the path
<clever> bkchr: it prints the 1st argument, then returns the 2nd argument
<clever> nix-repl> builtins.trace "print" "value"
<clever> trace: print
<clever> "value"
<clever> bkchr: builtins.trace
<clever> Unode: just keep in mind, the $out path depends on the combination of nixpkgs you used, so it will try to rebuild it, if you change that set of nixpkgs
<clever> Unode: (import /home/clever/nixpkgs {}).vmTools will give you the vmTools attributeset from a different nixpkgs, you can then run that on a different one
<clever> Unode: yeah
<clever> then to try and force it to use a specific storepath
<clever> its usually better to just pick a nixpkgs you know works
<clever> if the nixpkgs matches up, then it will just reuse it
<clever> if you wanted to use a different vmTools, you would have to do something like (import /home/clever/nixpkgs {}).vmTools
<clever> then use the non-overridden version for the system
<clever> Unode: you could .overrideDerivation the libxml2 for runInLinuxVM to disable testing
<clever> spacekitteh: getting late hear, i'm heading off to bed, good luck :)
<clever> spacekitteh: though that doesnt match up right, maybe a file got changed and i didnt notice?
<clever> spacekitteh: you can see how bash parses the entire command by looking at line 1: https://gist.github.com/spacekitteh/8417e9d24874889a20d3ded558b4ae98#file-logfiles-64-L1
<clever> spacekitteh: strange, all i can think is that its related to an env variable, "env" will dump it all, both in a build and outside
<clever> spacekitteh: does that repo init command work in a normal shell?
<clever> yeah, fails the same way as in the nix build
<clever> spacekitteh: the ? was part of the command
<clever> spacekitteh: bash or other?
<clever> spacekitteh: what does this return when ran in a normal shell? git config --get-regexp "url.*.insteadof" ; echo $?
<clever> spacekitteh: yeah, looks like file 70 is the issue, this git command is returning status 1 at line 152
<clever> spacekitteh: here, it configures a remote, everything else looks good so far
<clever> spacekitteh: the repo program appears to be reading some git config values, no error yet
<clever> spacekitteh: that appears to be just one of the log files
<clever> the output should tell you what that path is
<clever> nix leaves $out after the failure
<clever> so the logs are in $out
<clever> line 11, you did cd $out
<clever> oh
<clever> -K makes it save the dir after failing
<clever> somewhere near /tmp/nix-build-foo-0/
<clever> what about the strace output?
<clever> you could also add an echo before that, to see how nix parses it
<clever> they look fine to me
<clever> and then build with -K
<clever> id throw some strace at it next, strace -o logfiles -ff repo init ...
<clever> strange, but it sounds like network is on now
<clever> just throw in an invalid sha256, and it will grant you network
<clever> spacekitteh: i think the problem is that you didnt set the sha256, so its not a fixed-output derivation
<clever> spacekitteh: yeah, everything lines up right, let me double-check some other things
<clever> the <name> is also important to tracking it down
<clever> default
<clever> spacekitteh: can you gist more of the error, the entire console output?
<clever> spacekitteh: that isnt the same url as in test.nix, is it the same derivation?
<clever> spacekitteh: and what is the error it gives?
<clever> spacekitteh: line 2 of test.nix can be done more easily with callPackage
<clever> bobthejanitor: how are you checking what its outputing?
<clever> spacekitteh: can you gist your example and the error?
<clever> spacekitteh: how you set the url it downloads is your choice
<clever> spacekitteh: just an outputHash and outputHashAlgo, thats enough to enable the network
<clever> spacekitteh: thats purely up to you
<clever> dtz: the main issues ive ran into with the kexec stuff, is ensuring the network comes online right both times (kexec and the install), and that the install goes 100% perfect, any mistake and you cant recover
<clever> spacekitteh: but otherwise, it should just work on any distro with a linux kernel
<clever> spacekitteh: in one recent test of the kexec stuff, i discovered that kexec doesnt appear to work right when under xen's dom0
<clever> you will want to "systemctl stop autoreboot.timer" to stop it from interupting you
<clever> and if you didnt configure the ssh keys right, it will reboot itself at the end of the hour, and the previous OS boots like nothing happened
<clever> spacekitteh: if you configure the ssh keys right, you can then ssh in, format, and nixos-install like normal
<clever> spacekitteh: this generates a tarball, unpack it to / on any machine, run /kexec_nixos, and within 2 minutes, it will be running nixos from ram
<clever> spacekitteh: another fun script: https://github.com/cleverca22/nix-tests/tree/master/kexec
<clever> spacekitteh: this shows what you get from nix, when the stdenv isnt around to help
<clever> spacekitteh: and --option build-cores can override it
<clever> spacekitteh: $NIX_BUILD_CORES is set to match build-cores from nix.conf when a job starts
<clever> even if you rm -rf, the snapshots hold the previous versions
<clever> dhess: yeah, i'm liking the zfs backup stuff much better then such scripts, you have full snapshots of the entire FS
<clever> erlandsona: so it nuked all backups
<clever> erlandsona: yeah, and that was the off-site backup server, over nfs
<clever> erlandsona: guess what happens if the filename variable winds up blank?
<clever> erlandsona: ive heard something about a script doing rm -rf /backups/${filename}
<clever> spacekitteh: dont think so
<clever> spacekitteh: and optionalAttrs returns {} for false
<clever> spacekitteh: optionalString returns "" in the false case
<clever> spacekitteh: optional is for lists, and returns an empty list
<clever> [ ]
<clever> nix-repl> lib.optional false "foo"
<clever> oh, optional stuff, ''foo ${stdenv.lib.optionalString true "something"} bar'' i believe
<clever> spacekitteh: ''foo ''${bashvariable} bar''
<clever> though i forgot buildInputs = [ git];
<clever> spacekitteh: the above will flag it as fixed-output, so networking remains enabled
<clever> spacekitteh: it should, runCommand "foo.tar.gz" { outputHashAlgo = "sha256"; outputHash = "....."; } "mkdir $out; cd $out; git clone foo"
<clever> spacekitteh: oh, and runCommand has the benefit of excluding gcc from the stdenv, so it may build faster in certain edge cases
<clever> spacekitteh: and runCommand is just a shortcut to set buildCommand: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/trivial-builders.nix#L7
<clever> spacekitteh: i would go with either stdenv.mkDerivation with buildCommand, or runCommand
<clever> spacekitteh: buildCommand results in setup being sourced for you
<clever> spacekitteh: you almost always want to set buildCommand, not builder
<clever> bbl
<clever> Ralith: but you can freely set min and max on the cache
<clever> Ralith: my issue with zfs is the oposite, it drops the entire cache at the slightest sign of memory load, then perf suffers
<clever> brb
<clever> spacekitteh: if the sandbox is enabled, all network will be blocked inside normal derivations
<clever> ndowens08: as long as the gui opens when you run bitcoin-qt, it should be good
<clever> Ralith: so you dont have to set a hard-limit on the size of each fs, but you can configure them differently
<clever> Ralith: ive been going zfs for all of my new installs, each filesystem has its own config, but they all share the same zfs pool (the raw partition)

2017-03-22

<clever> ndowens08: heading out now
<clever> the let block also gets rid of the need for rec
<clever> having it in a let block avoids poluting the env some, and makes it more clear
<clever> ive seen a few users try to overrideDerivation the version, then ask why it didnt work
<clever> also, i find putting version into the attrset misleading
<clever> it has never differed
<clever> yeah
<clever> no idea
<clever> ndowens08: havent started anything yet
<clever> ndowens08: oh yeah, i was going to bump the bitcoin version from 0.13 to 0.14, but if your in the area already
<clever> dhess: i did see some code in nixops to automaticaly provision S3 buckets and RDS databases, but if your not using that, those roles could just be omitted
<clever> maurer: yeah, and set targetEnv="none"; somewhere in the nixops config
<clever> might be something from before the change
<clever> Yaniel: i believe it will be fixed soon
<clever> Yaniel: it used to, but that got broken by the recent changes to push all logs to S3
<clever> ozer: didnt say anything
<clever> Yaniel: 2017-03-20 12:45:56 < niksnut> 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> nope
<clever> bkchr: several, ipfs is one i can think of
<clever> bkchr: all attributes in the derivation become env variables
<clever> amosbird: nix-shell on 16.09 always gives gcc
<clever> amosbird: nix-shell -p gcc
<clever> amosbird: it needs nix installed before it can use a binary cache
<clever> smw: nixos did, default chain state
<clever> amosbird: and you need to generate a binary cache keypair with --generate-binary-cache-key, read "man nix-store"
<clever> ocharles: not sure what else it could be, but maybe something isnt setting $PATH right
<clever> ocharles: nixos-version is the current-system, not the booted system
<clever> ocharles: that trailing slash was actualy a typo on my end, heh
<clever> ocharles: strange
<clever> ocharles: what does ls -l /run/booted-system/ say?
<clever> ocharles: /run/wrappers/bin should be in $PATH
<clever> ocharles: what is $PATH set to?
<clever> amosbird: yeah
<clever> ocharles: you cant switch from 16.09 to 17.03 online, it needs a reboot
<clever> amosbird: nix-serve will turn a machine into a binary cache, so others can just query from it on-demand
<clever> amosbird: nix-serve and nix-copy-closure are 2 options
<clever> in the above example, you can fix it via ./foo + ("/" + bar)
<clever> ronny, domenkozar: every time you append a string to a path, it parses it, and strips un-needed elements, so ./foo + "/" + bar will strip the / in the middle
<clever> and binary caches already use public/private key pairs
<clever> if you use a .local domain for the cache, avahi would handle that for you
<clever> ronny: and also nix-serve
<clever> it might already have a back door when installed by nix
<clever> yeah, thats another matter
<clever> nix cant tell the difference between a corrupt file, and a file that has been tampered with, they are just both coming up with the wrong hahs
<clever> the above commands can also find malicious tampering with executables
<clever> dtluna: and nix-store --verify --check-contents --repair should try to repair it
<clever> nix-store --verify --check-contents will check everything for possible damage and list whats broken
<clever> dtluna: its also possible this is the result of an improper shutdown after nix-channel --update
<clever> dtluna: then your hdd is corrupted, give it an fsck pass and nix-store --verify --check-contents
<clever> smw: finding out which file provides el1_irq will explain the panic more
<clever> dtluna: can you pastebin /nix/store/9bfwq8ad5z3p4b0j2mimxgcal28a6q6c-nixos-16.09.1836.067e66a/nixos/pkgs/applications/misc/keepassx/default.nix ?
<clever> fRoping: they are also done from your profile

2017-03-21

<clever> gchristensen: weird, wasnt expecting fetchpatch to do such things
<clever> avn: ah, yeah, that sounds harder to track down
<clever> avn: find -inum can search by inode number, and all things in the hardlink share an inode
<clever> avn: i just assumed grub cant deal with zfs and always went with ext4 /boot
<clever> smw: at one time, it was used to plug cameras into PDA's and such
<clever> smw: its a general-purpose bus (like usb) but over the SD card interface
<clever> smw: i believe the wifi is over sdio on the rpi3
<clever> ive also heard, that the metadata in zfs always uses 128 bit ints, and it takes advantage of metadata compression to hide the cost
<clever> viric: ive recently been informed of lz4's insane byte/sec rates
<clever> and you can freely change the recordsize
<clever> viric: when using gzip, you can freely scale from -1 to -9, the other algos dont have those options
<clever> viric: what about seek+write?, that will change the size of a compressed block, and it may not be able to insert it at the right spot
<clever> avn: the desktop has 4 swap partitions, spread over several SSD's
<clever> avn: the laptop is zfs on lvm on luks, so i can put the swap in lvm and share the luks device
<clever> avn: and for that reason, i never put swap on zfs, not even a zvol
<clever> avn: but i have a laptop with 3gig of ram, that has never locked up, it just goes into swap-hell under over-use
<clever> avn: the 16gig machine is the one with the problem, and it happens any time chromium is using a decent amount of ram
<clever> gchristensen: ive found that defaulting the input chain to accept to be a mild security problem, while reloading the rules, you are open to any packet
<clever> avn: the low-ram systems have never had that problem, and always go into swap-hell, and eventualy recover
<clever> avn: it does tend to happen under high memory usage, but only on the machine with the most ram, heh
<clever> but i suspect it might be hardware related, i use zfs on 5 machines, and only 1 does it
<clever> avn: my main issue with zfs is not just maching killing lag, but entirely locking up
<clever> then it has to rebuild both arcs at bootup, via normal on-demand reads
<clever> so the L2ARC is essentialy lost upon reboot
<clever> also, the L2ARC is basicaly just a dedicated swap for the main ARC
<clever> viric: qcow compression is a bit simpler, because its already treating it as a block device, there are more logical places to do the compression blocks, though you still need an index to allow seeking
<clever> joepie91: so any modifications will be caught
<clever> joepie91: the url is a hash of the contents, and nix will always check the hash of fixed-output things like fetchurl