2018-04-24

<clever> Myrl-saki: pkgs.buildenv
<clever> yeah
<clever> Myrl-saki: thats a bit weird of a mode, it allows nobody to access it, and things often use nobody to strip all privs
<clever> Myrl-saki: ls -l /dev/kvm
<clever> and do you have permissions to open it
<clever> does /dev/kvm exist?
<clever> make sure default-extensions stay dead :P
<clever> :D
<clever> mbrgm: i think services like route53 automate all that
<clever> to generate the new records
<clever> only other option is to have a script that updates the dns, and reads the previous records at runtime
<clever> which will always be newer then the last date&time
<clever> mbrgm: when you do any change, set the serial# to the current date&time
<clever> and throw in time as well to allow several updates per day
<clever> mbrgm: oops, wrong m name, ^^^
<clever> Myrl-saki: i think most systems get away from that state, by using a "serial number" of 20180424
<clever> and set the new extra-platforms field i mentioned earlier, to claim you can run armv7l
<clever> also set NIX_CONF_DIR to point to a directory with a nix.conf
<clever> it expects it to take arguments, just ignore em
<clever> Myrl-saki: nix-env -E '{ ... }: ... '
<clever> robstr: then it should be using root still
<clever> robstr: you may be running a different nixos version locally
<clever> robstr: and your script runs it as root, which now lacks access
<clever> robstr: so the createdb has to be ran as postgres if your on a 18.03
<clever> robstr: on nixos 17.09 and older, the superUser is "root", but on 18.03 and newer, its "postgres"
<clever> robstr: oh, it might be that the default role changed and createdb doesnt know that
<clever> robstr: are you able to destroy and re-deploy the aws machine?
<clever> robstr: cant see any obvious problems with that code
<clever> is your config on github?
<clever> robstr: does stateVersion exist anywhere in your config?
<clever> state cant always be updated
<clever> robstr: the problem is more that you previously ran an older version on the aws machine
<clever> so, it needs to know the version of the state, which is defined in the stateVersion
<clever> but if your upgrading postgresql to a new version, it doesnt like the old state
<clever> robstr: its more that postgresql works fine if the first time it booted is on the currentl nixos version
<clever> robstr: if you dont care about the db, you can wipe the postgresql state and it will fix itself
<clever> robstr: you changed the stateVersion
<clever> angerman: something else that could help with incremental builds, seperate each library, executable, test, and benchmark into its own derivation
<clever> on a diff port
<clever> run your own sshd inside there maybe?
<clever> Myrl-saki: ssh based clients?
<clever> no
<clever> nix-build -E '(import <nixpkgs> { overlays = [ (import ./nixos-configs/overlays/qemu-user.nix)]; }).patchedNix.overrideAttrs (drv: { doCheck = false; }) ' --cores 24 --max-jobs 8
<clever> you can .overrideAttrs it
<clever> doCheck = false;
<clever> that looks right
<clever> ?
<clever> :D
<clever> that changes where it looks for nix.conf
<clever> Myrl-saki: ah, for single-user nix, you can just set NIX_CONF_DIR
<clever> and then edit /etc/nix/nix.conf to say it can run armv7l-linux
<clever> or rather, nix-env -iA nixpkgs.patchedNix
<clever> if its single-user nix, just get that overlay into scope and nix-env -iA nixpkgs.nix
<clever> which comes from the overlay on 36
<clever> Myrl-saki: and line 44 uses the patched version that has such an option
<clever> Myrl-saki: line 46 configures nix to blindly think it can run arm binaries
<clever> that is part of what my qemu.nix module does
<clever> nix-daemon hasnt been patched&configured to use binfmt-misc
<clever> Myrl-saki: your trying to do a native arm->arm build, so it expects the cpu to be able to run arm binaries
<clever> Myrl-saki: pong
<clever> bgamari: angerman has been working on ghc cross-compile lately
<clever> you would need some custom c code to even set that to see what happens
<clever> thats likely also not valid
<clever> i dont think dups and lacking = is valid
<clever> sphalerite: vars can be set to nothing, i have seen users often doing `set NIX_REMOTE=` when i tell them to unset, and then it has a totally different effect
<clever> though its not as obvious how its done
<clever> hyper_ch2: so you never have scrollbars on your VM
<clever> hyper_ch2: the gpu inside the virtualbox guest will change its resolution to match the window on the host
<clever> grafoo: why does it need root?
<clever> fyuuri: that is only used on the guest side
<clever> sphalerite: so the client could only query the area a single monitor covers
<clever> sphalerite: something else i just remembered, is that the vnc protocol allows you to query for changes within a certain region
<clever> so you just resize the guest window, and the "monitor" shrinks to fit
<clever> vbox with integrations also resizes the virtual gpu to match the window
<clever> adisbladis: qemu does have an option to embed an smb share into the nat, but its not as nice as vbox's sharing
<clever> fyuuri: virtualbox has a dedicated file sharing thing you can enable, which shows up as a drive in the vm
<clever> i have win 10 in virtualbox
<clever> srid: only system services
<clever> srid: ah, it doesnt auto-restart user services
<clever> srid: and also "${import /path/to/some.nix}"
<clever> srid: do `import /path/to/some.nix` in nix repl
<clever> srid: so if you move some.nix, and update the path, it would return the same value, and then systemd doesnt restart, because nothing actually changed
<clever> srid: it depends on what the import returns, not the path given to it
<clever> srid: you can also just specify ExecStart = foo;
<clever> srid: yes
<clever> and there is an old xorg module that can be loaded into the primary x
<clever> sphalerite: ah, for that, you have 2 options, x0vncserver will basically screenshot constantly, and serve that up
<clever> ah
<clever> and the bash script vncserver deals with launching it for you
<clever> sphalerite: there is also Xvnc, which is an entirely seperate x server, that uses vnc rather then a gpu

2018-04-23

<clever> its in its own package
<clever> /nix/store/pnjn1fv5s5a89vpqa63cvb407dapzy6c-which-2.21/bin/which
<clever> sphalerite: which isnt part of bash
<clever> thats nixos, not macos
<clever> blame apple for having non-standard commands
<clever> with 2 -'s?
<clever> pikajude: what does `which --all nix-store` say?
<clever> what has changed?
<clever> if nix-daemon is not running, nixops will try to auto-configure the target machine as a build slave
<clever> you need to manually configure a linux build slave in /etc/nix/machines
<clever> is nix-daemon running?
<clever> that breaks the automatic build-slave setup in nixops
<clever> did you switch to multi-user nix?
<clever> pikajude: what os is the local machine?
<clever> hyper_ch: nice
<clever> fendor: any idea what was causing it?
<clever> and then nix GC'd itself
<clever> gchristensen: so nix-collect-garbage didnt detect his profile as a root
<clever> gchristensen: the user had ~/.nix-profile pointing to a weird place
<clever> gchristensen: i have seen a similar issue from somebody that was more interested in getting help
<clever> ShalokShalom: can you give examples?
<clever> can you give examples?
<clever> ShalokShalom: what filesystem are you using?
<clever> ShalokShalom: are they made by you or a build?
<clever> ShalokShalom: what symlinks are disapearin?
<clever> yeah, these events only trigger when importing the pool
<clever> just use 660 :P
<clever> even a nix build can shred your drive
<clever> thats bad :P
<clever> ANYTHING
<clever> and if you make the last digit a 6, the group doesnt matter, anything on the machine can access it
<clever> my zvol is 660
<clever> hyper_ch: how did you check the zvol?
<clever> mine are 660 by default
<clever> you want 660 or 666
<clever> also, block devices shouldnt be executable
<clever> if its 777, then the group doesnt matter
<clever> hyper_ch: and thats how you would change the mode
<clever> hyper_ch: MODE="0666"
<clever> hyper_ch: this would chgrp whatever the dev-nodes as it creates them
<clever> hyper_ch: KERNEL=="zd*", SUBSYSTEM=="block", GROUP="whatever"
<clever> hyper_ch: do you care about only getting access to a specific zvol, or just getting all?
<clever> hyper_ch: so you cant rely on it
<clever> hyper_ch: *doh*, i used the wrong syntax to convert the timestamp, neither one is within 10 years of now :P
<clever> fgaz: that variable is set
<clever> IN_NIX_SHELL=1
<clever> ]$ env | grep SHELL
<clever> nick_l: thats what the drv in overrideAttrs (drv: { ... }) is for
<clever> nick_l: it needs to be overrideAttrs, but basically that
<clever> nick_l: an override
<clever> hyper_ch: did you try hooking your irc client up to a microwave?
<clever> hyper_ch: either your block is off, or your irc client is sending messages to the past
<clever> hyper_ch: which is somehow 60 seconds after the time when you pasted it
<clever> hyper_ch: the timestamp you pasted translates to the above
<clever> hyper_ch: 'Mon Apr 23 2018 10:42:36 GMT-0300 (ADT)'
<clever> nick_l: no, line 79 of the default.nix i linked is the problem
<clever> hyper_ch: reboot and see if it changes
<clever> and none of that output is unique to the device in question
<clever> hyper_ch: yep, i get the same output with -a
<clever> hyper_ch: 404
<clever> nick_l: you will want t package override to add more to the list
<clever> nick_l: datadog already handles python specially, and it can only ever load these python packages
<clever> nick_l: one minute
<clever> nick_l: you have to use the python that pythonWithPackages generates
<clever> and you cant copy/paste that
<clever> ctrl+b also works
<clever> nick_l: can you pastebin your nix expressions?
<clever> nick_l: pythonWithPackages
<clever> its not the block size
<clever> depending on the order you import pools, and if other volumes get created
<clever> it may
<clever> 2018-04-23 10:32:44 < clever> that number will be different every time you boot
<clever> and i dont see any fields we can use to key it properly
<clever> my -a shows it in a different format
<clever> hyper_ch: also, add -a to the info command
<clever> but once you find the right one, you will see the constant parts
<clever> that number will be different every time you boot
<clever> hyper_ch: now you can just change the 16 at the end and look around for the existing one
<clever> hyper_ch: udevadm info -q property -p /devices/virtual/block/zd16
<clever> hyper_ch: and the latency spiked
<clever> hyper_ch: i saw a video of a guy in a datacenter graphing the latency of the hdd requests, and then he shouted at the server
<clever> hyper_ch: on, now we need to query a param on that, let me see
<clever> nick_l: lol
<clever> nh: the nixos channel contains nixpkgs
<clever> nick_l: that was for nh
<clever> nh: thats why its doubling up
<clever> nh: only one should have nixos
<clever> nh: on one or both users?
<clever> hyper_ch: which is why i said to spam-create more volumes, to see what the names look like
<clever> nick_l: what does nix-channel --list show as both root and not?
<clever> robstr: and it needs root to work
<clever> robstr: its in iputils
<clever> hyper_ch: you need to start with `udevadm monitor` to find the sysfs path when the device is created (spam more volumes? import/export?), then use some other cmd i cant remember to query the params on it, and write a rule based on them
<clever> but it also cant pass thru a gateway/router/nat
<clever> arping cant be blocked by firewalls

2018-04-22

<clever> mikka231: even when dd'd correctly?
<clever> also, the dd overwrites the filesystem, so it doesnt matter what it was before, and there is no need to mkfs.vfat it
<clever> kisik21: ive not used the imperative containers, so i dont know how they differ
<clever> but you can use declarative containers to just push a host image, that contains containers
<clever> it doesnt support that
<clever> kisik21: nixops can deploy either to a remote host, or to a local container
<clever> :D
<clever> keith_analog: then all of the variables are in one block and you only have a single let .. in ...
<clever> keith_analog: its also a lot cleaner to do let foo=bar; foo=bar; foo=bar; in stdenv.mkDerivation { ...
<clever> keith_analog: so bash is running each --flag as its own command
<clever> keith_analog: line 86, 90, 94 and 98 are each on their own line
<clever> keith_analog: you have newlines in your installPhase
<clever> keith_analog: can you pastebin the nix file?
<clever> kisik21: oops, wrong nick
<clever> kisik21: can you pastebin the nix file?
<clever> yep
<clever> kisik21: thats pretty much how nixops works
<clever> ragaba: .la files are not static libraries
<clever> you have to override libXft to enable static libraries there
<clever> ragaba: only dynamic libraries exist in that directory
<clever> ls -l /nix/store/vg5sfgsg3kg7kk3081vi3xwxb4zb8ja7-libXft-2.3.2/lib
<clever> ragaba: what is it not finding?
<clever> ragaba: you may also need to override each of its inputs to enable static libraries on those
<clever> once the client has booted, the server is no longer required
<clever> this configures a netboot server, that runs the clients from a ramdisk
<clever> kisik21: ive also done it with ramdisks
<clever> kisik21: ive done it with iscsi
<clever> kisik21: probably
<clever> yep
<clever> nixck: and you cant just iterate over the buildInputs either, because of how string context works
<clever> nixck: i dont think thats possible
<clever> and hydra no longer even stores anything locally
<clever> it has since been configured to upload to S3 the instant a build finishes
<clever> but that became a major bottleneck
<clever> originally, hydra.nixos.org would build up the entire package set, and then bulk-upload to S3 when the eval passed
<clever> that could explain it
<clever> Dezgeg: the number has probably grown since i last heard it
<clever> its never cleared
<clever> also, cache.nixos.org has everything that hydra has ever built
<clever> yeah
<clever> kisik21: and when there is a mass-rebuild, it will need another 80gigs
<clever> kisik21: last i heard, it was around 80gigs
<clever> nixck: check the docs for exportReferencesGraph
<clever> nor a way to get reliably bit-identical files when given the same input
<clever> avn: i dont think tar has a way to enforce sorting and no duplicates in the tar file
<clever> the files in the NAR are also require that everything be sorted
<clever> that is how you manipulate nar files
<clever> nix-store --restore output < input.nar
<clever> nix-store --dump input > output.nar
<clever> nix doesnt need timestamps, uids, or chmod bits
<clever> its like tar, but it lacks timestamps, uid, and chmod bits
<clever> everything that nix-serve servers over http is runtime generated
<clever> yeah
<clever> hydra and nix-serve format the data and show it inside .narinfo files
<clever> for the local store, it keeps that data in /nix/var/nix/db/db.sqlite
<clever> drv files are build-time dependencies, narinfo are runtime
<clever> the narinfo file
<clever> yep
<clever> kisik21: also, you cant paste the path of anything that depends on users-groups.json, like the target of /run/current-system
<clever> yeah
<clever> kisik21: but the attacker will need to know the hash of the file to download it
<clever> kisik21: both nix-serve and hydra will share the entire store, including users-groups.json
<clever> kisik21: and in some special setups like hydra.nixos.org, it will push the data up to amazon S3, which is what powers cache.nixos.org
<clever> kisik21: hydra will also root everything it potentially needs, so the garbage collector cant eat it
<clever> kisik21: nix-serve and hydra can present an http interface to the local /nix/store directory, and serve it to other users
<clever> jluttine: ah, that would explain things
<clever> freeman42x]NixOS: also, your probably better off just fixing the nix expression for ghcjs, then redoing it from scratch
<clever> freeman42x]NixOS: autoreconfHook automatically runs the autoreconf for you before the configurePhase
<clever> tazjin: nearly all of the builtins are in c++
<clever> tazjin: it can also use ~/.ssh/id, and whatever else ssh uses by default
<clever> it can just use your ssh agent
<clever> tazjin: builtins.fetchgit doesnt need such hacks
<clever> tazjin: the entire /nix/store/ ?
<clever> tazjin: builtins.fetchgit can also use your ssh agent
<clever> so it can just use your keys
<clever> it runs the git clone outside of the nix sandbox
<clever> tazjin: i believe builtins.fetchgit just works on private repos
<clever> drakonis: they are still around currently
<clever> tazjin: there was a bug in nix1 that allowed an empty hash
<clever> tazjin: fetchgit needs a hash or it wont work
<clever> tazjin: what does --show-trace print?
<clever> and the --max-freed limits the damage it does to your cache
<clever> it deletes invalid files before moving on to the garbage
<clever> check that first
<clever> it probably already ate the problem lock file
<clever> does the lock file still exist?
<clever> and it cant delete 1% of a file
<clever> the first thing it found was probably 95mb
<clever> tells it to stop after deleting 1024 bytes
<clever> elvishjerricco: try nix-collect-garbage --max-freed 1024
<clever> elvishjerricco: you can also use sudo -i to get a root shell
<clever> what does this output?
<clever> elvishjerricco: in a root shell: ls -l /proc/*/fd/* | grep a6sa5z744wqh4w92331hcsf0mwh821m7
<clever> elvishjerricco: what is the full path to that file?
<clever> elvishjerricco: check `ps aux | grep nix` and see if you have a nix still running on that file
<clever> and its from about a month ago
<clever> periklis: ah, once you pass that commit, it will be static by default
<clever> periklis: i think so
<clever> sudo nix-channel --add https://nixos.org/channels/nixos-18.03 nixos
<clever> xmr-nixos-user: you missed the -18.03 in the command i gave
<clever> kisik21: i think anything namespace based (both docker and nixos-container) will have trouble stopping root
<clever> kisik21: but the guests can also see any files you have in /nix/store, which might include secrets or private software
<clever> kisik21: nixos-container shares /nix/store between every guest, so it takes up less disk space
<clever> xmr-nixos-user: add the channel under the name nixos, and remove the one under nixos-18.03
<clever> xmr-nixos-user: and also sudo nix-channel --remove nixos-18.03
<clever> xmr-nixos-user: you probably want sudo nix-channel --add https://nixos.org/channels/nixos-18.03 nixos