<clever>
gchristensen: is that why i saw a "mast" branch a few days ago?
<clever>
cant think of anything else then
<clever>
devoid: anything in the dropdown?
<clever>
devoid: try draging that monitor?
<clever>
devoid: and df in general, the size of every mount-point is in constant flux
<clever>
devoid: cacti/snmp is also confused, it refuses to let me graph a 2nd filesystem within the same pool
<clever>
spacekitteh: yes
<clever>
but it needs xfce in full control to persist, so it can restore upon login
<clever>
i believe it uses xrandr to apply the changes, so you can probably just run it under nix-shell to test
<clever>
ah, i was wondering if xfce4-display-settings helped any
<clever>
devoid: are you using xfce?
<clever>
my driver default to mirror
<clever>
i think its more to do with the xorg default, span or mirror
<clever>
devoid: ow, lol
<clever>
but the option definitions themselves arent protected
<clever>
mkOption sort of adds a type system to the options framework
<clever>
was that the pkgs default.nix?
<clever>
no idea why it was setup like that
<clever>
devoid: by adding other forks of nixpkgs like that, i can checkout branches from any of them, and switch back to master easily, so i only need 1 copy of the nixpkgs git repo
<clever>
devoid: if you want to develop or edit expressions in a channel line 6/7 of http://pastebin.com/r5pDRFhv
<clever>
devoid: if you just want to use a channel, what gchristensen said
<clever>
but i need to finish this code
<clever>
i should get sleep soon, lol
<clever>
what gchristensen said
<clever>
nixpkgs-channels
<clever>
oops
<clever>
devoid: also, the release-17.03 branch on nixpkgs isnt the safe one, you want release-17.03 of nixpkgs-master
<clever>
devoid: the last link i gave is the 17.03 version of nvidia's package
<clever>
devoid: you can change branches right on the github web-ui
<clever>
ive also had systemd refuse to shutdown because nfs is busy umounting, when there is less then 30 seconds left on the UPS, and the entire network is down because of a power outage!
<clever>
ive had issues before where a normal umount also hangs, because the nfs client is dumb and wants a server up to disconnect cleanly
<clever>
"umount -l" is a lazy umount, it will un-hook it from the visible FS's and let it take its time (potentialy forever) in the background where it wont bother anything
<clever>
Acou_Bass: its more likely that the nfs server is to blame
<clever>
Acou_Bass: umount and the problem should go away, if umount hangs, there is umount -l
<clever>
Acou_Bass: up next is "strace df -h" to find out which mount it is
<clever>
Acou_Bass: ah, so stdin/stderr/stdout are all pointing to /dev/pts/3, and it has no open files, but its probably doing stat on an nfs mount
<clever>
df -h is usualy enough to check the nfs mounts
<clever>
Acou_Bass: and are any nfs mounts hung?
<clever>
Acou_Bass: it appears to be blocking on disk io, what does ls -l /proc/2165/fd/ say?
<clever>
Acou_Bass: can you pastebin "ps -eH x"'s output when its hung?
2017-03-03
<clever>
magnetophon: but you can just download any ISO, and switch the channel to 17.03 after it boots
<clever>
magnetophon: oh, and i dont think 17.03 has actualy released officialy yet
<clever>
magnetophon: only other thing i can think of is strace, which will generate several MB worth of logs, and include IP's that you appear to be censoring
<clever>
so you can use nixos-install to upgrade any machine that isnt capable of upgrading itself
<clever>
nixos-install is basicaly just a script for running nixos-rebuild under a chroot
<clever>
one solution is to just boot it from an install ISO, add the new channel as nixos, mount the original filesystems up, and then re-run nixos-install
<clever>
do you have physical access to the problem machine?
<clever>
and you dont need to use root on the remote machine, only the local machine
<clever>
magnetophon: next time nixos-rebuild does (test|switch), it will restore nix.conf back to the symlink it should be
<clever>
magnetophon: try this, "cd /etc/nix; cat nix.conf > nix.conf.copy; rm nix.conf; mv nix.conf.copy nix.conf" then just edit nix.conf and put in the right config
<clever>
the -1 is part of the key name, but it is NOT part of the url
<clever>
magnetophon: "--option binary-caches cache.nixos.org-1" is an invalid url, and you must use the correct pubkey for it to work against the real cache.nixos.org
<clever>
magnetophon: i mean the binary cache key
<clever>
magnetophon: how did you try adding the public key for signing?
<clever>
magnetophon: and does root have a pw set?, check /etc/shadow
<clever>
magnetophon: get a root shell via sudo and double-check the ssh keys are in place correctly
<clever>
magnetophon: either the ip has changed, or somebody is performing a mitm attack and now has your pw :P
<clever>
magnetophon: you need to either use --to root@other-machine, setup signing, or make the target user a trustedUser
<clever>
MichaelRaskin: my screens are laid out as 1,3,2, so that wouldnt look right
<clever>
devoid: the defaults on my system is to mirror it 3 ways
<clever>
devoid: only downside, is that those settings only take place after login, but i dont really need 3 monitors working correctly to type in a name+pw, lol
<clever>
devoid: i just drag them around in the xfce display settings
<clever>
bobthejanitor: yeah, and put in any info you can gather on the issue
<clever>
bobthejanitor: not sure then, i usualy see this kind of problem if somebody ran nixos-rebuild when /boot wasnt mounted, then the files wind up in the /boot folder of /, rather then the /boot partition
<clever>
bobthejanitor: and is /boot correctly mounted?, does it show up in df -h or mount?
<clever>
bobthejanitor: does that file exist in /boot/ ?
<clever>
dmj`: nixos-unstable is also on nix version 1.11.6
<clever>
or put the version into the name, so it always mismatches
<clever>
tnks: you need to change the hash, to make it re-download, and tell you the correct hash
<clever>
so it will match the old file you previously downloaded, and not update
<clever>
tnks: and you bump it to version 1.3, the name in the /nix/store wont change
<clever>
and then nix-daemon would use that value for the builder
<clever>
i was under the impression that the nix-build command would read the NIX_CURL_FLAGS from its env, then forward that to nix-daemon over the unix socket
<clever>
dmj`: that better not be a real token :P
<clever>
so the hash doesnt need to be incremented
<clever>
so any change to rev causes the name to not match, and it forces a re-download
<clever>
tnks: i think fetchFromGitHub prevents this issue by naming the derivation "${name}-${rev}.tar.gz"
<clever>
so it wont notice the hash is wrong
<clever>
the problem there, is that if the hash and name match something you already have downloaded, but the url points to a newer file, it wont try to re-download
<clever>
dtz: i always increment a random number near the end of the hash
<clever>
tnks: you could also do impureEnvVars = [ ("GITHUB_TOKEN_" + foo) ];
<clever>
tnks: sure
<clever>
which prevents that issue
<clever>
LnL: because fetchurl is fixed-output, it ignores the paths of all of its inputs
<clever>
not a problem
<clever>
which would trigger mass-rebuilds
<clever>
otherwise, the source code fetched by fetchurl will change its path every time curl updates
<clever>
yeah, it would have been like this for ages
<clever>
and if name isnt set, its the filename at the end of the url
<clever>
the path that fetchurl returned should have depended purely on the sha256+name that you gave to fetchurl
<clever>
and then downloaded it with fetchurl?
<clever>
in what case have you noticed that?
<clever>
dtzWill: and the other instances of privateNetwork in the same file
<clever>
dtzWill: every build goes into its own private network namespace, with only an lo interface
<clever>
dtzWill: normal derivations are, but fixed-output derivations are not
<clever>
tnks: for attributes within a fixed-output derivation, you can change them all you want without impacting the hash, but those attributes are readable in /nix/store/
<clever>
tnks: for NIX_CURL_FLAGS, it bypasses all hashing entirely, but there is a single value for the entire nix-build call, covering all derivations
<clever>
havent looked into what default.target covers
<clever>
keith_analog: it only runs on bootup if you make it part of the multi-user.target
<clever>
tnks: the hash in $out is based purely on the outputHash attribute, which must use the algo in outputHashAlgo
<clever>
tnks: the $out hash of a fixed-output derivation ignores its build-time dependencies
<clever>
thats easy to convert
<clever>
tnks: oh right, thats an older version from before i told dmj to switch it to impureEnvVar
<clever>
oh, i had that problem just a day ago, thought it was just me mis-using something
<clever>
tnks: this new instance of callPackage will search in self first, then pkgs
<clever>
but you need to copy ./foo/default.nix -> foo.nix, and update the src directive to re-pin a new version
<clever>
tnks: now it will decide between ./foo/default.nix or ./foo.nix, allowing more complex changes to be made in foo's dir
<clever>
foo = if (builtins.pathExists ./foo) then (callPackage ./foo {}) else (callPackage ./foo.nix {});
<clever>
another way of doing it:
<clever>
and because of how nix works, it will re-check for ./foo each time you eval the nix expressions, and if it doesnt exist, it will always return the same foo with no changes to the hash
<clever>
this will override the src if ./foo exists, and just leave foo un-altered if it doesnt
<clever>
tnks: foo = if (builtins.pathExists ./foo) then (foo.overrideDerivation (old: { src = ./foo; })) else foo
<clever>
tnks: it should be possible to conditionaly do that, one sec
<clever>
yeah, just define every dependency in nix, and fetch each private one with code like that gist
<clever>
oh, and the curl method from dmj's gist doesnt support submodules
<clever>
ah, having nix fetch a pinned version of dependency xyz, i see
<clever>
branches and tags to flag versions that are known-good
<clever>
ah
<clever>
its just a small project, 2 people with push access on a private repo
<clever>
so it never has to download private things at build-time
<clever>
tnks: in my project, there is only 1 private repo, so i can just "git pull" manualy, and run nix-build in its root dir
<clever>
tnks: i am currently writing a testframework in lua, i feel i dont need types that badly :P
<clever>
tnks: and now hydra can fetch that input from a private repo, and no build will ever have access to the keys
<clever>
tnks: the hydra case is a bit simpler for small numbers of things, you can define an input for hydra as "git@github.com:owner/project.git" and then just run ssh-keygen as the hydra user
<clever>
yep
<clever>
even if somebody does manage to steal the token, its just read-only
<clever>
i believe you can then make a dedicated github account for that, and grant it read-only access to your projects
<clever>
tnks: the function in the gist will use an auth token made on github to grant curl access to private repos
<clever>
tnks: do you want to fetch the private github from a hydra based build, or via nix-build?
<clever>
Kendos-Kenlen: and the nixos testcases just run a full test as a qemu vm, and basicaly "compile" the test results when nix tries to "build" the test derivation
<clever>
Kendos-Kenlen: any kind of test you can wrap into a nix package can also be handled by hydra
<clever>
tnks: will this be working under hydra or nix-build?
<clever>
joachifm: of note, mu is broken in master due to webkit stuff, i last checked a few hours ago
<clever>
release channels*
<clever>
ah yeah, the channels never get darwin builds, only nixpkgs-unstable has darwin
<clever>
steveeJ: builtins.readFile is the first thing that comes to my mind
<clever>
not sure
<clever>
dannyg: that can be tracked in /proc/meminfo but i cant remember which field it is
<clever>
dannyg: ive noticed similar when i ran nixos from a uSD card in a usb adapter, abnormaly low write speeds combined with 16gigs of ram, it can buffer pretty massive amounts of data in ram
<clever>
dannyg: and when the backlog has gone thru fully, the sync will return, having done exactly what its meant to do
<clever>
dannyg: maybe it isnt actualy hanging, but rather, there is a large back-log from rsync, and the sync from nixos-rebuild is waiting for that backlog to clear
<clever>
dannyg: not sure then, sounds like an issue within the nfs config
<clever>
dannyg: and backup-tud is your only nfs mount?
<clever>
nwspk: -p can also accept multiple arguments at once
<clever>
strange, what about "strace sync" ?
<clever>
dannyg: and it lists the nfs mount?
<clever>
dannyg: as a quick check, does "df -h" hang?
<clever>
dannyg: because the mount was configured to never fail and to retry forever
<clever>
dannyg: 99% of the time, the connection to the nfs server has died, and the kernel is just waiting forever for a reply
<clever>
pkg-config --cflags gdk-pixbuf-2.0
<clever>
nwspk: it likely also has pkgconfig and the same issue, all glib stuff is designed like that
<clever>
nwspk: what does "pkg-config --cflags glib-2.0" output?
<clever>
dannyg: i usualy just check the process tree when i see something complex hang, have a look at "ps -eH x"
<clever>
nwspk: you need to add -I${glib.dev}/include/glib-2.0 to the include path, -p pkgconfig and "pkg-config --cflags glib-2.0" will find it for you
<clever>
nwspk: glib is trying to prevent the kind of collisions that nix is designed to avoid, but it also breaks the logic nix adds to help make things work nicely
<clever>
nwspk: glib.h is in include/glib-2.0, but only include is in the include path
<clever>
i have my hydra setup to pre-build a few base packages, and it can take a week to catch up after nixpkgs changes
<clever>
yeah, that will probably take a while
<clever>
yep :)
<clever>
smw_: if you switch over to setting nixos-config=/etc/nixos/configuration.nix in $NIX_PATH, then you can easily override it with -I nixos-config= at any time
<clever>
smw_: yeah, that would explain everything