2017-03-03

<clever> jophish_: i think it can find them, but isnt listing them
<clever> LnL: yeah
<clever> you will need to kill that process before nix can delete it
<clever> what comes out?
<clever> jophish_: now run strings on the matching environ, and grep that
<clever> jophish_: #3 grep path /proc/*/environ
<clever> jophish_: #2 grep path /proc/*/maps
<clever> jophish_: double-check these things: #1 ls -l /proc/*/fd/* | grep path
<clever> jophish_: of note, -q --roots can check /proc for any open files, and env variables
<clever> jophish_: ive broken everything with --ignore-liveness
<clever> this is the zfs version i had at boot, solved!
<clever> [root@amd-nixos:~]# /run/booted-system/sw/bin/zpool events -v
<clever> i cant "zpool events" because my zfs utils got upgraded, and are incompatible with the kernel
<clever> heh, and nixos saves the day again!
<clever> oh, if you have push, then cherry-pick should also work
<clever> bennofs: id think that you can open a PR againt 17.03 to fix bugs it has, it just wont gain version bumps or new features
<clever> while the $out inside those, obey fixed-output rules, and cut the impurity off at the source
<clever> the hashes on the .drv tree, ignore fixed-output rules, and depend on the hashes of the curl nix was built against
<clever> jophish_: the .drv path depends on the nix version used to eval it, but the $out of the drv doesnt
<clever> jophish_: the outpath or the .drv path?
<clever> either mu needs to use a newer webkit, or webkit needs a version bump
<clever> i havent seen that before, but it explains the failure
<clever> and checking the webkit 2.4 file, i see meta.knownVulnerabilities is set
<clever> if you put that into systemPackages, youll get a webkit-less mu
<clever> (mu.override { withMug = false; })
<clever> and if false, it just lacks webkit support
<clever> which default to true on linux
<clever> LnL: so that nix-intantiate will probably also fail
<clever> and i confirmed, mu fails to eval on nixpkgs master
<clever> can you try just removing mu and see what happens?
<clever> you have mu in your systemPackages
<clever> samae: can you pastebin your configuration.nix?
<clever> and mu is somehow tied to systemd and dbus
<clever> samae: line 58, i think the problem webkit is in mu
<clever> samae: did --show-trace say anything?

2017-03-02

<clever> romildo: --show-trace maybe?, *runs off to bed*
<clever> heading off to bed
<clever> smw_: i believe the platform is mainly for kernel stuff, so it shouldnt impact nix-repl, you can just rename config.nix temporarily
<clever> smw_: .nix-defexpr is setup by nix-channel, but since you cloned nixpkgs, you skipped that step
<clever> and if you dont have any channel, nix-env -f /root/nixpkgs/ -iA nix-repl
<clever> smw_: you need to install it first, nix-env -iA nixpkgs.nix-repl
<clever> smw_: and then try to eval config.system.build in the REPL
<clever> smw_: what if you run this: nix-repl /root/nixpkgs/nixos/ -I nixos-config=/root/nixpkgs/nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix
<clever> greymalkin: its part of an attributeset that nixops passes to your configuration
<clever> yeah
<clever> apriori: sadly, that path will change every time you reboot
<clever> apriori: nix-shell -p qt5.qtbase, then run "which qmake", make note of its path, and run "qtcreator", and configure a kit based on qmake's path
<clever> apriori: i was only able to get it to work by running qtcreator under a nix-shell that had included QT, and i had to point qtcreator to the path of qmake that nix-shell had setup (which qmake)
<clever> i found that on one of my EFI motherboards
<clever> some of the more powerful firmwares, are capable of connecting to the internet and downloading their own updates
<clever> and suddenly, a press + release turns into a press by itself, and key-repeat kicks in!
<clever> gchristensen: and because of the rather short keyboard buffer, some key events would be dropped in that 0.5 seconds
<clever> gchristensen: in my case, i believe the kernel was trying to calibrate the bogomips thing every time the freq changed, causing a 0.5 second lockup
<clever> gchristensen: this reminds me of a key-repeat issue i had years ago, caused by cpufreq scalling
<clever> hyper_ch: if this pattern holds, he is due back in 2 days :P
<clever> what the...., 4th of dec as well!
<clever> 2016-12-04 16:44:33-!- vcunat [~admin@nat-34.starnet.cz] has quit [Quit: Leaving.]
<clever> he seems to connect on the 4th of every month? heh
<clever> 2017-01-04 04:39:31-!- vcunat [~admin@nat-34.starnet.cz] has joined #nixos
<clever> 2017-01-04 04:40:08-!- vcunat [~admin@nat-34.starnet.cz] has quit [Client Quit]
<clever> and he was online for ~1.5 hours, a month ago
<clever> 2017-02-04 17:34:10-!- vcunat [~admin@nat-34.starnet.cz] has quit [Quit: Leaving.]
<clever> 2017-02-04 17:17:20< vcunat> (and the machine is rather fast :-)
<clever> 2017-02-04 17:17:00< vcunat> I haven't noticed any slowness (vim + C), but I haven't used it on any really big project either
<clever> make a default.nix for that project and run nix-build or nix-shell against it
<clever> amosbird: i generaly define those in ~/.nixpkgs/config.nix as proper nix packages, then all of the nix tools will know how to build them
<clever> so i can just "nix-shell -p nmap" any time i want to do a quick port scan, and once i exit the shell, nmap is gone
<clever> and also gives virtenv style effects on all languages
<clever> include files are usualy ignored by nix-env -i, so libraries only work if you run nix-shell -p on the derivations
<clever> amosbird: you generaly dont install tools like gcc with nix, but rather, you open a shell with it available: nix-shell -p gcc
<clever> greymalkin: nix-repl -I nixos-config=./configuration.nix '<nixpkgs/nixos>'
<clever> id just try it, and see what happens
<clever> LnL: the glibc that nix-env downloads may not like the centos kernel
<clever> ive not noticed any problems, and ive ran it on a 3.8 machine
<clever> amosbird: on my system, 2.24
<clever> amosbird: it uses normal glibc, which is stored in /nix/store/
<clever> gchristensen: or even this, lol
<clever> "foo"
<clever> nix-repl> "${ { type = "derivation"; outPath = "foo"; } }"
<clever> "baz"
<clever> nix-repl> ( (builtins.derivation { name = "foo"; system = builtins.currentSystem; builder = "/bin/sh"; }) // { bar = "baz"; }).bar
<clever> "foo"
<clever> nix-repl> (builtins.derivation { name = "foo"; system = builtins.currentSystem; builder = "/bin/sh"; }).name
<clever> gchristensen: every attribute you pass to a derivation, can still be read from the resulting derivation, and you can // more attributes ontop of it
<clever> gchristensen: sounds like a derivation just has an attribute on it, containing another derivation
<clever> avn: biggest problem debuging it, is that when all core spinlock, i have no way to control it to get a backtrace, i need to look into getting either a pcie serial card, or usb debugging
<clever> avn: i have talked to the zfs channels a few times
<clever> avn: but, if i replug any usb device, it resumes all disk io like nothing was ever wrong
<clever> avn: and often, it can spinlock all 8 cores, and now the machine is just locked up solid
<clever> avn: the really really weird part of my problem, is that when zfs decides to stop disk io, it tends to spinlock whatever core it was on
<clever> avn: ow!
<clever> avn: so i cant see the DDT being the cause
<clever> i have had updatedb crippled the machine, even when it had 2gig of ram free
<clever> 340mb of ram
<clever> this says that there are 1 million records, and they take 357 bytes each in ram
<clever> dedup: DDT entries 1000631, size 1106 on disk, 357 in core
<clever> [root@amd-nixos:~]# zpool status -D
<clever> avn: but its weird, it just randomly stops all disk io, 0 io/sec
<clever> avn: ive done the math on my DDT and its not taking up enough memory to cause my issues, and all future dedup is off
<clever> gchristensen: i'm also in the middle of redoing the test framework for one of my network protocols, its some custom binary stuff over SSL
<clever> avn: what kind of problems?, one of my zfs machines has very weird issues
<clever> and then the whole lvm is on luks!
<clever> avn: ive heard of issues with swap on zvol, so my laptop has swap on lvm, and zfs on lvm
<clever> gchristensen: the shutdown on line 31 gets in the way when i'm trying to do manual testing, but any change to that config eats another gig of disk space
<clever> gchristensen: i have been thinking about a similar problem in https://gist.github.com/cleverca22/010456d1d1895f760bd8244fd62ffd9f
<clever> i dont know if the test framework goes thru that route or not, and some tests may involve rebooting and wouldnt be happy with this kind of change
<clever> gchristensen: it fires up a whole qemu, and then runs your original builder script as stage2
<clever> gchristensen: but reading this further, i believe this is only for when you wrap a derivation with vmTools.runInLinuxVM
<clever> gchristensen: i did see a comment about interactive debuging if it fails with -K
<clever> gchristensen: oh, then your previous question may work then, try QEMU_OPTS="-serial stdio" ./result/bin/run-nixos-vms
<clever> when the perl script starts a vm, uts using the qemu options on line 145
<clever> gchristensen: then lines 120 and 147 of this file: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/test-driver/Machine.pm#L120
<clever> gchristensen: this runs a root shell on /dev/hvc0, which the perl scripts use to control the VM's during testing
<clever> gchristensen: ah, those do have a side-channel that includes a root shell, let me find it
<clever> let me check their source
<clever> oh, the test vm's
<clever> so that isnt needed
<clever> the -nographic from virtualisation.graphics = false; already routes the serial port to stdio
<clever> just nix-build && ./result/bin/run-nixos-vm
<clever> gchristensen: i forgot that the nixos module already gives a login prompt on stdio when you turn graphics off, so it just needs some auto-login in mingetty
<clever> gchristensen: confirming it works and then uploading to github
<clever> gchristensen: it appears to drop me at a login prompt, so the normal auto-login is needed
<clever> gchristensen: QEMU_OPTS is an env variable that result/bin/nixos-run-vm will obey, and virtualisation.qemu.options would let you embed it in from the configuration.nix
<clever> gchristensen: qemu, let me double-check the source
<clever> LnL: the only method i can see is to block /*.narinfo and /nar/* in the http server that protects hydra, but that stops all cache access
<clever> LnL: oh, downloading from hydra, not hydra itself downloading
<clever> LnL: from the binary cache?, that appears to be off by default in the newer versions of hydra
<clever> gchristensen: and nixos can run a shell on that
<clever> gchristensen: with -serial stdio or -serial mon:stdio, you get a serial port on stdin/stdout
<clever> LnL: what kind of downloads?
<clever> gchristensen: i might have something for that, i'll look at it after i finish this issue
<clever> yeah
<clever> avn: and even if those arent enabled, any user on the machine can read it via ls -l /nix/store/*identity
<clever> avn: and now your private key is in the store, and depending on what else you have configured (hydra, nix-serve) available for the world to download
<clever> it could potentialy even allow it to work with remote build slaves
<clever> but as others mentioned in the issue, it would greatly simplify things if nix-build and nix-daemon did that agent proxy
<clever> the socat is running as root, so it gets an exception, and it acts as a proxy, stripping that user info from the session
<clever> so even if you try to authorize it by using chmod on the unix socket, the agent rejects it hard
<clever> the reason i needed to add socat into the mix, is because the ssh-agent can detect when the "wrong" user is connecting to the unix socket
<clever> in my latest case, the source is in the same repo as the release.nix, so that 1 fetch by hydra is all that needs a key, and the actual build can be done without fetchgitprivate
<clever> mguentner: if you just "sudo -u hydra -i" and "ssh-keygen", then the hydra-evaluator will have a keypair, and it can checkout git projects over ssh
<clever> mguentner: i also recently found a trick that works for cases where you control hydra
<clever> mguentner: i cant remember if the /tmp/hax path was impacted by sandboxes or not
<clever> i'm looking for the gist
<clever> mguentner: one method i used involved an ssh agent
<clever> mguentner: i have played with various ways of fetching a private repo
<clever> bbl
<clever> by default, the checkPhase is disabled, but if you set doCheck = true; it will run "make test" before it does the installPhase
<clever> Kendos-Kenlen: only if doCheck = true; is set in the derivation
<clever> ah, hydra.useSubstitutes
<clever> its making the build slave do every single binary cache fetch
<clever> and also, this new install of hydra i have, doesnt seem capable of using the binary cache directly
<clever> gchristensen: if you know your going to reboot anyways, its usualy safer/faster to use "nixos-rebuild boot", that wont activate until after the reboot
<clever> i did help somebody a few days ago that had sudo up and vanish
<clever> as long as it builds fast, that isnt an issue
<clever> mogria: nix-build will just do everything at once, i generaly just add debug code directly to the nix expression and re-run nix-build
<clever> fxp: if you can find vim's version of include, you can do vimrcConfig.customRC = '' include ${./vimrc} '';
<clever> mogria: one option is to just clone all of nixpkgs, edit the file in the nix expression, and then use nix-build on that new nixpkgs tree as normal
<clever> hyper_ch: can just hop over here
<clever> and the details page in hydra shows that path
<clever> this works for anything in the cache, and you dont need the nix expression that made it
<clever> if you run "nix-store -r /nix/store/hash-foo-1.2.3" it will download it from the cache
<clever> the binary cache can still easily be used
<clever> __Sander__: that was disabled months ago, it now pushes everything to S3
<clever> Ralith: i asked where server xyz was, giving an ip, they said "all servers are working fine", and they rebooted every box without asking
<clever> Ralith: and ive had far worse support from another datacenter
<clever> Ralith: the only time ive had network trouble is when somebody with a backhoe severed a dozen fiber optic lines
<clever> yeah, it is pretty cheap and powerfull
<clever> but i plan to put nixos on the next machine
<clever> not yet, havent had time to schedule downtime to wipe it
<clever> eacameron: and with root in that recovery netboot, you can do https://nixos.org/wiki/Install_NixOS_on_Linode
<clever> eacameron: from the web ui, you can change the boot order between a rescue netboot, and the hdd, and on bootup, it will email you the root pw
<clever> eacameron: ive got a dedicated box at soyoustart, and the control panel is good
<clever> nix-instantiate ~/apps/nixpkgs/nixos/ -A config.system.build.sdImage -I nixos-config=/home/clever/apps/nixpkgs/nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix --argstr system armv7l-linux
<clever> it should be working
<clever> and there is a modules dir in /root/nixpkgs/nixos/modules/ ?
<clever> smw_: what does it give if you give it a path to the nixos subdir of your nixpkgs checkout?
<clever> nix-build /home/clever/nixpkgs/nixos/ -I nixos-config=nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix -A config.system.build.sdImage
<clever> it has been for over a year
<clever> yes
<clever> the wiki is outdated and read-only
<clever> ah, then your on master
<clever> smw_: and what channel are you getting nixpkgs from?
<clever> i see, that is what you ran before
<clever> ah, there is a comment right on line 2 giving a command similar to mine
<clever> did you get that part?
<clever> and configuration.nix must contain imports = [ <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix> ];
<clever> yeah
<clever> and configuration.nix must contain imports = [ <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix> ];
<clever> smw_: you to use nix-build '<nixpkgs/nixos>' -A config.system.build.sdImage -I nixos-config=./configuration.nix
<clever> ahh
<clever> and the mountpoint is the key name
<clever> smw_: fileSystems should be an attribute set, not a list

2017-03-01

<clever> chattered: i usualy just do src = ./.; and that works great
<clever> ibrahims: why dont you have access to the systemd config file?
<clever> services.avahi.enable
<clever> is avahi enabled?
<clever> hodapp: services.printing.browsing maybe
<clever> hodapp: the same info is also in "man configuration.nix"
<clever> MP2E: this can be used to force a single derivation to build with 6, but it wont cover the dependencies
<clever> 2017-02-27 06:35:14< LnL> alternatively you can use foo.override { stdenv = stdenvAdapters.overrideCC gcc6; }
<clever> with nix, you can keep trying and there wont be side-effects from other attempts
<clever> thats what i do a lot of the time
<clever> and the recent rpi2's now also have the 64bit cpu, and just lack the bt/wifi
<clever> the 3 also has bluetooth and wifi built in, in addition to the 64bit cpu
<clever> i believe that just refers to which default config to use from the kernel source
<clever> the rpi3 is backwards compat to rpi2 software
<clever> i think armv7 defaults to something else
<clever> you may need to switch to this: (import <nixpkgs> { config = {}; }).platforms.raspberrypi2
<clever> to run the 64bit compiler
<clever> if you comment out the platform entry, it should default to armv7 and be much simpler to setup
<clever> yeah, but you will need at least a 64bit kernel and a 64bit bootstrap tools to start 64bit builds
<clever> ah, i believe thats still a 32bit kernel
<clever> smw_: what does uname -a say?
<clever> but aarch64 is harder, because there is less aarch64 support
<clever> armv6 and armv7 are easy, because you can just boot rasbian, build nix from source, and then let nix build everything in nixpkgs
<clever> main issue on arm right now is the lack of binary cache support
<clever> after that, its just making sure one arch doesnt try to GC the other arch
<clever> the key, is that each platform used a different bootloader, so they used different builds of nixos from the store
<clever> it used the same rootfs and nix store for both
<clever> heh, when i started out with nixos, i made a uSD card that could boot on both x86-64, and armv6
<clever> platform = (import <nixpkgs> { config = {}; }).platforms.aarch64-multiplatform;
<clever> try this way
<clever> i think the problem is that recent changes in nixpkgs make the value of pkgs.platforms depend on the config
<clever> yeah, i do see a }; after swap on the wiki, that isnt valid
<clever> smw_: can you pastebin the configuration.nix?
<clever> when nix-daemon picks a target build user, it will kill off every process in that uid, so they have to be new users, not people who will be using nix
<clever> you just need to setup some build users in the nixbld group, chown 0:0 -R /nix/store, run nix-daemon as a service, and set NIX_REMOTE=daemon in the env
<clever> i usualy just modify the single-user install from the curl command
<clever> shanemikel: 78c68f2 is the git revision it came from

2017-02-28

<clever> what are you trying to download?
<clever> and that would require evaling a copy of nixpkgs to get pkgs.tar
<clever> you would need to run ${pkgs.tar}/bin/tar
<clever> ah
<clever> and a recent change, makes it such that curl it no longer ran as a normal process
<clever> builder = "builtin:fetchurl";
<clever> contrapumpkin: when you build nix, the paths for curl and openssl are embeded into a config file, that these corepkgs will reference
<clever> ?
<clever> yes
<clever> ah, i must have also added curses to the buildInputs
<clever> what is the error?
<clever> the above export will do that
<clever> i think curses is already in the buildinputs, and you just need to add -lncurses and it will work
<clever> auntie: a note i made ~2 months ago to remind myself how to get "make menuconfig" working
<clever> 2016-12-03 23:28:04<@clever> [nix-shell:~/rpi/linux]$ export NIX_LDFLAGS="${NIX_LDFLAGS} -lncurses"
<clever> but for when you dont have the .nix files, it has to work in the other direction, recursively following the References
<clever> for builds where you have the .nix files, nix will work its way up from the libraries to the final product, because it already knows the dependency tree
<clever> yeah, it will list off everything else X depends on, who signed it, and what url to dl it at
<clever> eacameron: here is an example of what the narinfo files should contain
<clever> curl cache.nixos.org/nqf3kxj6s69qswar8bgidag71yj917sl.narinfo
<clever> eacameron: if it is truely down, nix will transparently build it locally
<clever> eacameron: 10000's of requests going to a single web-server
<clever> a 404 is normal for things not in the cache
<clever> thats just nix checking every single derivation in your closure, to see what ones are available on the cache
<clever> eacameron: did it look like this?
<clever> download-from-binary-cache.pl: still waiting for ‘https://cache.nixos.org/94zxprfc3nnbvwm22d09cdac8jhdlscl.narinfo’ after 5 seconds...
<clever> what was the exact error?
<clever> eacameron: a 404 on the narinfo just means that that file isnt in the cache
<clever> laboon: try building the 1.11.6 tag of nix, rather then master
<clever> so it will request many files, until it finds a match
<clever> thoughtpolice: and it will search for a matching firmware, starting at the newest and working its way backwards
<clever> thoughtpolice: ive noticed with another linux wifi driver, is that the device<->host api version is in the filename, and the linux driver supports a range of api's
<clever> laboon: looks like some work has been started, you should be able to compile nix from source, and then use nix-build and nix-env to build almost anything in nixpkgs
<clever> laboon: ah, acording to somebody in another channel, the syscalls arent compatible
<clever> laboon: as long as the kernel can handle binaries compiled for linux, it should just work as-is
<clever> smw: the initrd has to be built against the right kernel, to include dm_mod.ko in the initrd

2017-02-27

<clever> i'm guessing the main key in ~/.ssh/ will work
<clever> sphalerite: yeah
<clever> sphalerite: when the targetEnv is set to none, it will just ssh into root, and nix-copy-closure to upload a pre-built nixos, but the config you give to nixops has to keep the machine bootable
<clever> dcz__: ah, last time i was fixing that, i had deleted and remade /boot bigger
<clever> dcz__: systemd will refuse to let you mount the "wrong" filesystem to /boot, you need "nixos-rebuild test" to update fstab, after you fix fileSystems."/boot"
<clever> or chown them
<clever> did you run it with sudo at any point?
<clever> mine still restores tabs correctly, even if its not default
<clever> and nobody has patched that
<clever> i think the problem is that the actual browser isnt aware of the nixpkgs wrappers
<clever> but now there are 2 chromium binaries, not even counting chromium-browser yet
<clever> since they are in different derivations, you can recompile the bash script, and reuse the pre-compiled chromium
<clever> the bash script adds the configured plugins to env vars, before running the 2nd chromium
<clever> that runs /nix/store/mprk6qiibik8aixslv4jwgb1a7dnfl62-chromium-55.0.2883.87/libexec/chromium/chromium
<clever> /nix/store/vn267yxglzz5wfil9ry32mspbs9f3y9x-chromium-55.0.2883.87/bin/chromium is a bash script
<clever> i just set it right and turn the warning off
<clever> but you need to run the nix wrapper to make it start right
<clever> some browsers will want the un-wrapped version of their binary in the config
<clever> :)
<clever> srhb: as long as its not using mmap to read the offending string, you will see exactly where the data came from
<clever> srhb: this will show you every single syscall its doing, so you can "grep --color Nightly logfile*"