<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>
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>
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: 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>
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: 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>
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>
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>
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*"