2019-02-20

<clever> its listening on /tmp/hax
<clever> thats normal
<clever> reallymemorable: thats just normal sudo rules, you must know your own pw, or set one with something like `passwd reallymemorable`, as root
<clever> and now you can start the socat as root, pointing to the unix socket the agent is running on
<clever> and the agent will never give the key out, only sign things for you
<clever> nixbld talks to the agent, which has a copy of the key loaded in memory
<clever> thats the whole point of the agent
<clever> thats a warning that anybody in your group can read your ssh key, you may want it to be chmod 600
<clever> just copy/paste those back into the terminal
<clever> reallymemorable: when you run ssh-agent, it will print a few lines out
<clever> reallymemorable: it sounds like SSH_AUTH_SOCK still isnt set right, so the ssh-add is failing
<clever> and ssh-agent has an exception to allow root, so `sudo ssh` can still use the agent
<clever> so you have to setup an socat to act as a proxy, which is connecting from root
<clever> reallymemorable: the main uid issue, is that when a member of nixbld connects to $SSH_AUTH_SOCK, ssh-agent rejects them hard, for security reasons
<clever> reallymemorable: not really that different, just make sure the $SSH_AUTH_SOCK is pointing to the socket for the users ssh-agent
<clever> reallymemorable: as a normal user, except for the socat, which the example shows being used with sudo
<clever> reallymemorable: the commands in that gist will allow fetchgitPrivate to talk to ssh-agent
<clever> Aleksejs: looks like a problem inside pycurl, you could maybe disable printer support temporarily (since config-printer depends on pycurl)
<clever> you didnt correctly eval the output of ssh-agent
<clever> but, ssh-agent itself has some security options that get in the way, it wont the nixbld users talk to the agent, so you need to bypass that with socat: https://gist.github.com/cleverca22/ef075e5dfe092fa6b08cec0ae1dfde66
<clever> just ssh-add, without eval
<clever> reallymemorable: running ssh-add, will add ~/.ssh/id_rsa to the currently running agent
<clever> reallymemorable: you need to run ssh-agent, and then export the vars it prints, then also run ssh-add
<clever> srhb: lddtree isnt like `find .`, but rather, it will show the dep-tree of the DT_NEEDED's
<clever> dcol: lddtree should reveal that
<clever> dcol: if it is needed by another lib, and not the executable, the it uses that libs rpath
<clever> dcol: when one of those libraries tries to load another, it uses its own rpath, not the rpath on the executable
<clever> dcol: does the package have its own libraries?
<clever> srhb: thats practically what tgt-admin was, it would diff the config against the daemon state, and then run modify commands to re-sync it
<clever> because its actually managing "services" within the tgtd proc
<clever> and 25-38 is also a one-shot, with an execstop
<clever> srhb: how would i get the service on lines 25-38, to restart any time the service on 59 restarts?
<clever> srhb: but, you need to restart those target units, any time tgtd restarts, and other fun problems
<clever> srhb: i decided to skip that perl script, and make a systemd unit for every single target, and just call tgtadm directly, to add/remove things from tgtd, rather then re-sync the daemon to the cfg
<clever> srhb: then you have tgt-admin, a perl script, that parses the config file, and calls tgtadm, to configure the daemon correctly
<clever> srhb: then you have tgtadm, an ELF binary, that will RPC into tgtd, and add/remove things
<clever> srhb: behind the scenes, there is a tgtd daemon, which runs the iscsi target, but it doesnt support its own config files!
<clever> srhb: ive got a complex systemd unit that ive had trouble getting the wants and neededby right on
<clever> it will recursively add .override to every attr in the set
<clever> 531 arphic-ukai arphic-uming;
<clever> 530 inherit (callPackages ../data/fonts/arphic {})
<clever> srhb: i believe thats what callPackages is for
<clever> and it does, in normal nixpkgs
<clever> > pkgs.ceph.override
<clever> hmmm, that should just work?
<clever> 1835 ceph = callPackage ../tools/filesystems/ceph {
<clever> srhb: callPackages is supposed to prevent that kind of issue
<clever> lejonet: .override is added by .callPackage(s)
<clever> in my case, its just another nixos pc, with 3 4tb drives in a raidz1 setup (all zfs)
<clever> load times are slower, but i never have to worry about the desktop getting low
<clever> iqubic: yeah, the games can be pretty heavy, ive been installing them to my NAS with 10tb of space
<clever> Richard[m]: there is also #nix-tools
<clever> steell: yep
<clever> Richard[m]: i believe you need to use nix-tools to cross-compile haskell, due to complications within cabal
<clever> steell: you could just append an extra line to the installPhase (similar to how you did set -x), and just mv that lib to the right spot
<clever> or just throw in a mv to put the file in the right spot
<clever> you may want to patch it to: "$out/usr/lib/plexmediaserver:$out/usr/lib/plexmediaserver/lib"
<clever> steell: or usr/lib/plexmediaserver ?
<clever> steell: under /lib/ ?
<clever> ,locate libsoci_core.so
<clever> steell: is libsoci_core.so in /nix/store/09g97li05qmmqkd8s8h27rll3qsjp11d-plex-x.xx.x.xxx ?
<clever> ,unstable steell
<clever> fixed in sept
<clever> that file isnt in nixpkgs master, and isnt in your rpm file
<clever> steell: is there a file which doesnt exist?
<clever> steell: you would need to add a `set -x` at the start of installPhase, to be able to debug this further
<clever> steell: 2>&1 > out.txt
<clever> steell: its possible that the new version is missing key files, can you pastebin the entire error?
<clever> steell: are you using an rpm package?
<clever> steell: yeah, looks like you simply want to use that override, with the URL plex gives you
<clever> and thats the backend
<clever> steell: this will run plex-media-player on full-screen on my tv
<clever> steell: ive set things up, without the plex pass
<clever> NemesisD: its a kernel driver, kvm-intel or kvm-amd, just modprobe it
<clever> NemesisD: having /dev/kvm on the build machine counters most of that perf cost
<clever> /nix/store/alv34l2647n40h7svsrd52hjq28b399q-coreutils-8.30/bin/coreutils
<clever> $ realpath /run/current-system/sw/bin/chmod
<clever> NemesisD: build-time performance
<clever> NemesisD: runAsRoot has performance costs, due to needing to fire up a full qemu VM, i try to do things at runtime to avoid that
<clever> benwaffle[m]: but if your already using substituteInPlace, it would be simpler to --replace "@shell@" "$shell"
<clever> benwaffle[m]: which will replace @shell@ with the value of $shell for you
<clever> benwaffle[m]: its usually handled by substituteAll
<clever> benwaffle[m]: replace @shell@ with $shell
<clever> benwaffle[m]: yeah, thats one solution
<clever> reallymemorable: using build slaves makes fetchgitPrivate a lot more complicated to use, which is why builtins.fetchGit is the better replacement
<clever> reallymemorable: it is a function within nixpkgs, that is used to download focus-phonepush-worker
<clever> reallymemorable: something that ghci-backend is doing involves calling fetchgitPrivate somehow
<clever> reallymemorable: https://gist.github.com/cleverca22/ef075e5dfe092fa6b08cec0ae1dfde66 is the notes from when i was last using fetchgitPrivate

2019-02-19

<clever> reallymemorable: just pastebin the full output, including the error msg, and whatever command you ran to cause it
<clever> reallymemorable: can you pastebin the full output from running nix-shell?
<clever> reallymemorable: does ssh-auth-sock appear in any file?
<clever> reallymemorable: mostly, the old fetchgitPrivate is deprecated
<clever> reallymemorable: somebody that knows what that code is doing would need to edit it to use builtins.fetchGit
<clever> reallymemorable: i think this is the code that is causing the issues
<clever> focus/obelisk/lib/command/src/Obelisk/Command/Thunk.hs: , " fetch = { private ? false, ... }@args: if private && builtins.hasAttr \"fetchGit\" builtins"
<clever> reallymemorable: it would be a string within a file, grep -r --color fetchgit -i
<clever> reallymemorable: looks entirely normal, does `fetchgit` appear anywhere in that directory?
<clever> reallymemorable: it could also be called default.nix
<clever> reallymemorable: in the directory you ran nix-shell in
<clever> reallymemorable: what is in your shell.nix?
<clever> reallymemorable: what nix function are you calling, that results in the error your getting?
<clever> reallymemorable: its a function, used to fetch git repos
<clever> iqubic: ncdu
<clever> reallymemorable: instead of using pkgs.fetchgitPrivate, you use builtins.fetchGit
<clever> iqubic: yep
<clever> reallymemorable: you want builtins.fetchGit
<clever> you can also set the zfs property `com.sun:auto-snapshot:weekly=false` to just stop weekly entirely, read the description of .enable for more examples
<clever> iqubic: you cant change how often they happen (as far as i know), but you can limit how many daily it keeps, and the same for every other category
<clever> yeah
<clever> reallymemorable: so, the user you login as, must never be in the nixbld group
<clever> reallymemorable: when it selects a user, it kills everything in that user
<clever> reallymemorable: thats the problem, nix will use the members of nixbld as build users
<clever> iqubic: read the description of each of these options: https://nixos.org/nixos/options.html#zfs.autosnapshot
<clever> reallymemorable: did you add yourself to the nixbld group?
<clever> iqubic: after you fix things, you can edit the nixos config for the automatic snapshots
<clever> dmj`: if you are using flat hashing, then its just the plain old sha256 of the file
<clever> iqubic: 2019-02-19 18:46:58 < clever> and this will delete a single snapshot
<clever> iqubic: 2019-02-19 18:46:51 < clever> zfs destroy -v amd/home@zfs-auto-snap_hourly-2019-02-18-19h00
<clever> iqubic: then destroy a single one of those gig large snapshots
<clever> iqubic: you can likely get enough back to GC, from destroying 1 snapshot
<clever> iqubic: the `used` column from `zfs list -t snapshot -r -o name,used,refer,written amd/home` tells you how much space youll get back if you destroy that 1 snapshot
<clever> asymmetric: gist fork updated
<clever> asymmetric: oh, i forgot to import
<clever> and this will delete a single snapshot
<clever> zfs destroy -v amd/home@zfs-auto-snap_hourly-2019-02-18-19h00
<clever> this will then show every snapshot for amd/home
<clever> zfs list -t snapshot -r -o name,used,refer,written amd/home
<clever> iqubic: this will tell you which dataset is using the most space via snapshots
<clever> zfs list -t filesystem -o name,used,referenced,logicalused,logicalreferenced,written,usedbysnapshots,usedbydataset,refcompressratio,compressratio,compression
<clever> iqubic: do you have snapshots enabled?
<clever> iqubic: you can now delete some files you dont care about, and then nix-collect-garbage
<clever> elgoosy: yeah, if your paranoid, you can turn on pure or restricted eval, to stop it
<clever> iqubic: `mount -t zfs tank/home /home/iqubic`
<clever> asymmetric: the overlays attr of nixpkgs will handle that for you, and you usually dont want to be calling it yourself
<clever> iqubic: `mount -t zfs tank/home /home/iqubic`
<clever> iqubic: then mount it, delete one or 2 files, get nix-collect-garbage working, then install and run ncdu on home
<clever> elgoosy: which are set via `--option restrict-eval` or `--option pure-eval`
<clever> elgoosy: either restricteval, or pureeval
<clever> elgoosy: there is a special flag you can turn on to make it more pure, hydra enables it by default
<clever> iqubic: thats to be expected
<clever> iqubic: did it list your datasets? or fail before that?
<clever> iqubic: then its just not mounted, you need to mount it to see the files
<clever> iqubic: what does `zfs list` say?
<clever> asymmetric: you need to use a second copy of nixpkgs, from `import <nixpkgs> {}` to get your fetchFromGitHub
<clever> iqubic: deleted, or just not mounted? is /home on its own dataset?
<clever> iqubic: try deleting some normal files, until nix-collect-garbage does work
<clever> iqubic: are you able to manually delete a file anywhere, a non-nix file?
<clever> iqubic: what happens when you run nix-collect-garbage?
<clever> asymmetric: line 12 needs a + and the /overlay.nix has to be quoted, and maybe some more () so import applies last
<clever> asymmetric: thats how i usually do it
<clever> asymmetric: thats not valid nix, one min
<clever> iqubic: that should free up enough space to make it run normally
<clever> iqubic: normal nix-collect-garbage
<clever> almost to 100!
<clever> das_j: --add-root result --indirect
<clever> das_j: you can still use nix-instantiate
<clever> iqubic: add ` single` to the kernel cmdline in grub
<clever> iqubic: several years worth of irc logs are only taking up 5gig here
<clever> i recently found that $HOME on a server i help manage, was twice the size of /nix/store/
<clever> iqubic: ncdu can also be used
<clever> iqubic: try adding ` single` to the end of the kernel command line in grub
<clever> iqubic: text mode login fails?
<clever> iqubic: nix-collect-garbage
<clever> nivpgir: the nixos name will cause conflicts with the nixos on root, so its best to avoid that name most of the time
<clever> betawaffle: nixops will add resources, nodes, and deploymentName
<clever> betawaffle: then it will error out, and reveal the names of things you didnt claim to accept
<clever> betawaffle: if you remove the ... element, then you will stop accepting args you didnt name yourself
<clever> lejonet: -o can also be used to put the result elsewhere
<clever> argent0: its in both NIX_CFLAGS_COMPILE and NIX_LDFLAGS
<clever> env | grep zlib --color
<clever> argent0: its added to an env variable that cc-wrapper will force gcc to look into
<clever> and then any <nixpkgs> mistakes will fail, rather then cause problems
<clever> i prefer fetchTarball, because i can then unset NIX_PATH entirely
<clever> bsima: fetchTarball is better for fetching nixpkgs itself, since you need a nixpkgs to use fetchFromGitHub
<clever> tokudan[m]: my name pulls up 190 million hits...
<clever> ive also used local?root= with nix copy, to unpack a tarball of a store, then merge it into an existing store, that may not be at /
<clever> catern: i think the sandboxing mechanics are the only time it does chroot like stuff
<clever> (technically, it doesnt chroot, it just prefixes all paths automatically, it has some bugs too)
<clever> and chroot automatically
<clever> that would dump everything into /tmp/deletethis/nix/store/
<clever> catern: NIX_REMOTE=local?root=/tmp/deletethis/
<clever> catern: if you set NIX_REMOTE, it wont even need a daemon
<clever> benwaffle: i think one of them depends on glibc
<clever> nixos-unstable wont have darwin cache coverage
<clever> benwaffle: nixpkgs-unstable is 7 days old, so it may just be that
<clever> benwaffle: ah, when did you last do nix-channel --update?
<clever> benwaffle: if you try to install it when no changes exist, it wont do anything
<clever> benwaffle: its best to install it again with nix-env -iA, or switch to a more declarative setup
<clever> benwaffle: nix-env -u has issues finding the right thing to update to
<clever> thomasd: you may need to use a different nixpkgs version
<clever> thomasd: looks like a build failure within ghc 8.4.4 itself
<clever> thomasd: can you pastebin more of the error?
<clever> but then its harder to debug the other packages
<clever> yep
<clever> thomasd: it tells it to lookup that attribute, in the set default.nix returns
<clever> thomasd: nix-build -A parallel-julia
<clever> thomasd: you forgot the -A param, so its trying to build everything
<clever> thomasd: oops, thats pkgs.haskell
<clever> and a minor typo
<clever> updated the gist to fix syntax errors
<clever> thomasd: you can also move parallel-julia up into the haskell overrides
<clever> thomasd: instead of using pkgs.haskellPackages on line 5, use haskell.packages.ghc844, and rename the part on the left of the =, so it wont conflict with things

2019-02-18

<clever> thomasd: can you pastebin your current default.nix file?
<clever> spacekitteh[m]: those jobs must pass, and every single thing in the eval must finish (pass or fail)
<clever> spacekitteh[m]: check the tested job it links to
<clever> samueldr: thats the one i always use
<clever> > pkgs.gist.meta.description
<clever> yep
<clever> Alling: type will tell you if its in PATH or not, and if its a function/alias, what the definition is
<clever> Alling: which only searches PATH, you want type
<clever> sb0: iputils is the one nixos uses
<clever> ,locate bin ping
<clever> Alling: you can also run `type patchShebangs` inside nix-shell to see tht
<clever> illegalprime: yeah
<clever> illegalprime: so it wants the cross-compiled cmake, when it shouldnt
<clever> illegalprime: its more likely that somebody put cmake into the buildInputs, rather then nativeBuildInputs
<clever> illegalprime: i think?....
<clever> illegalprime: i dont think you need to cross-compile cmake, since rust doesnt need cmake at runtime
<clever> illegalprime: yep, thats also a common thing
<clever> Alling: its a bash function, not a binary in PATH
<clever> illegalprime: the above files generate a linux ELF makensis binary, and some exe stubs, and makensis will then join the stubs with compressed blobs, to create working windows installers
<clever> you could also just fire if statements at it
<clever> > stdenv.cc.isGNU
<clever> illegalprime: $CC will be set at build time
<clever> yep
<clever> yeah
<clever> rydnr: pkgsi686Linux.callPackage will supply all dependencies from the 32bit set
<clever> pkgs.Moz2D instead of letting pkgsi686Linux.callPackage load the 32bit one
<clever> rydnr: you need to get moz2d from the other pkgs set, or modify moz2d to properly set the right arch when building
<clever> rydnr: yeah, pkgsi686Linux is the 32bit version of nixpkgs
<clever> and moz2d has a 64bit arch hard-coded into it
<clever> rydnr: that forces everything to do a 32bit build
<clever> rydnr: can you pastebin that pharo nix expression as well, and the `nix show-derivation` of its .drv file?
<clever> rydnr: and then you just have moz2d in your systemPackages somewhere?
<clever> rydnr: sounds like everything should just work, how is nixos-rebuild loading that copy of nixpkgs?, what args was nixos-rebuild called with?
<clever> rydnr: and how did you load the file from that last link?
<clever> rydnr: and where is the nix code loading that file?
<clever> rydnr: can you pastebin the output of `nix-diff` and also `nix show-derivation`?
<clever> sevanspowell: its still running as the nixbld1 user, which lacks access to the socket, its better to rewrite such tests to not depend on docker
<clever> sevanspowell: the nix sandbox doesnt allow it access to the docker socket
<clever> rydnr: looks entirely normal, which derivation are you having trouble with?
<clever> nisstyre: security groups must be in the resources, down between 52&56
<clever> nisstyre: i dont see the securitygroup under resources
<clever> nisstyre: thats a bug in nixops, it doesnt warn you when the names collide like that
<clever> nisstyre: do the names of the machine and security group overlap?
<clever> nisstyre: are you using --include any?
<clever> rydnr: yeah, it will default to the arch of the nix-build binary, which we already confirmed is 64bit
<clever> rydnr: can you pastebin your configuration.nix file?
<clever> that looks good as well
<clever> rydnr: what about `which nixos-rebuild` ?
<clever> rydnr: not really
<clever> rydnr: are you setting the system param anywhere in configuration.nix?
<clever> rydnr: and `file /nix/store/rffcxk0l94lc96yl07r26sdnfql6x0h4-nix-2.1.3/bin/nix-build` ?
<clever> rydnr: and what does `which nix-build` return?
<clever> rydnr: which one is i686-linux? and what is the host cpu?
<clever> schneid3306: if you use `#!/usr/bin/env python` and happen to have python already installed, it can work, but its often better to package the script properly
<clever> kk
<clever> cbarrett: what is your goal?
<clever> i do have plans to add it to nixops in the future
<clever> then just ssh back in, execute a second command, and it now has nixos instaled
<clever> cbarrett: you basically build a special tarball, upload it to any linux machine, unpack it, execute 1 file, and the machine is now running nixos from a ramdisk
<clever> cbarrett: ive made my own framework for that, justdoit + kexec
<clever> cbarrett: i cant see any reason you cant use it

2019-02-17

<clever> the link its creating, is the 2nd argument
<clever> yes
<clever> you have the arguments backwards
<clever> then rm the destination first
<clever> thats how ln has always worked
<clever> iqubic: if the destination already exists as a directory, it puts the symlink inside that dir
<clever> iqubic: why do you think its not working?
<clever> iqubic: ln -s
<clever> Nivpgir: but you may also want to check smartctl -a, and see whats up with the diks
<clever> Nivpgir: nix-store --verify --check-contents
<clever> Nivpgir: nix can detect corrupt files without a reinstall
<clever> and /boot is NOT updated, so all changes are lost at reboot
<clever> wedens: test will build and activate, but not make a generation
<clever> wedens: then youll want to use a mix of `nixos-rebuild build` and `nixos-rebuild test`
<clever> wedens: are you testing a normal package, or a nixos module?