2017-08-22

<clever> lejonet: any package you add to environment.systemPackages gets merged together, and the merged result lands at /run/current-system/sw
<clever> always getting those 2 mixed up
<clever> plopix: ah, its called pkgs.makeWrapper
<clever> plopix: try pkgs.wrapProgram ?
<clever> yeah
<clever> vagrant-: i dont think there is any way to see the full closure of what depends on X when those things arent alive
<clever> vagrant-: yeah
<clever> vagrant-: nix-store -q --roots goes up, to the GC roots that holds something in the store
<clever> vagrant-: nix-store -qR and --tree both go down from a package to all of its deps
<clever> but i dont think you can offline enough drives that data becomes unreachable
<clever> and when you online them, it will restore the missing blocks
<clever> i think in the case of raidz members, it will operate in a degraded state and track what blocks are out of sync
<clever> offline lets you temporarily suspend all activity to a drive in the array
<clever> srhb, Infinisil: there is also the offline/online commands
<clever> zfs also has hot spares, but the fully automatic replacement logic needs the bays to map to stable device nodes
<clever> lol
<clever> then drop the smaller half
<clever> and half the space will go to "waste"
<clever> srhb: so if you have enough drives, you could mutate your 4 drive raidz into a mirror between a 10 drive raidz and the 4drive raidz
<clever> srhb: i think you can also dynamicaly change a raidz into a mirror of anything + old_raidz
<clever> srhb: and it defaults to a max of 50% of your ram
<clever> srhb: zfs will automatically shrink the arc based on how much ram is used
<clever> srhb: and /sys/module/zfs/parameters/zfs_arc_max is the max number of bytes
<clever> the rest are performance counters
<clever> c is how much ram zfs wants to use, arcsz is how much its currently using
<clever> srhb: run this as root
<clever> arcstat.py -f time,read,dmis,dhit,dh%,mrug,mru,mfu,mfug,mread,c,ph%,pm%,mm%,miss,hits,mhit,mh%,mmis,hit%,eskip,arcsz 10
<clever> fixed
<clever> plopix: the wrapper will generate a bash script, that prefixes PATH, then runs the old emacsWithPackages
<clever> typing up an example...
<clever> plopix: what about making a wrapper around the entire emacsWithPackages
<clever> and that may not play nicely with the emacsWithPackages code
<clever> it needs something like postInstall, that will use makeWrapper to modify $out/bin/emacs
<clever> but you have no way to reference that derivation
<clever> and that shellHook only applies if you directly run nix-shell on myEmacs
<clever> once emacs is done compiling, they leave the picture entirely
<clever> plopix: the change you did only puts stack and mu into the $PATH while emacs is being compiled
<clever> gchristensen: and the cp needs -r
<clever> gchristensen: also needs to chmod +w -R $out
<clever> dash: but nixos-rebuild --fast both skips that, and does --show-trace
<clever> dash: and it may not pass all of the args to the first nix build
<clever> dash: behind the scenes, nixos-rebuild will first try to build nix, then use that nix to build nixos
<clever> dash: try nixos-rebuild --fast instead
<clever> dash: i think it does, but only for the nixos side, not for the nix side
<clever> __monty__: they are all the same expression
<clever> __monty__: one for each version of python
<clever> romildo: so if you add (pkgconfig.override { vanilla = true; }) to your buildInputs, you will get an unpacked version
<clever> romildo: i havent seen that bug before, but there is the optional on !vanilla in there
<clever> __monty__: try the thunderbird package first, nix-env -iA nixpkgs.thunderbird
<clever> romildo: and you have to add the deps the .pc wants to the buildInputs
<clever> romildo: i remember something about pkg-config silently dropping things, if the dependencies listed in the .pc file cant be found
<clever> disasm: is the problem happening under nix-build?
<clever> viric: it might have been off back then
<clever> viric: __impureHostDeps is another thing, its in build.cc again
<clever> viric: i just remember that it worked with a zero byte sshc-onfig in the NIX_PATH
<clever> viric: i'm not sure how that worked either, now that i think of it
<clever> viric: it might even copy the unix socket intact into the store? not sure
<clever> viric: my first guess is that because it came from NIX_PATH, maybe nix considers it a legal input to the build, and tries to copy it in
<clever> viric: that leaks in i think, let me check
<clever> it uses the NIX_PATH
<clever> also, this doesnt use env vars at all
<clever> it then acts as a proxy
<clever> viric: the socat running as root is the "client" for ssh-agent, and root is an exception to the uid lockout (so you can use things under sudo)
<clever> viric: i already have a gist that solves this
<clever> viric, gchristensen: looks like it just does getEnv as the process initiating the build (the daemon)
<clever> viric: not 100% sure though
<clever> viric: i believe they come from the nix-store -r
<clever> i usualy just throw \'s at the problem until it goes away, lol
<clever> gchristensen: sed can also use a character other then /
<clever> __monty__: the name must be config.nix, but otherwise, yes
<clever> yeah, cygwin does something special to manage them within its FS's
<clever> yeah, that should also help
<clever> then uncomment it, and switch again, so nixos creates it properly
<clever> try commenting out the user in configuration.nix and do a switch, so nixos deletes the user
<clever> maybe, does the home directory exist?
<clever> viaken: did you set isNormalUser on the user when you made it in configuration.nix?
<clever> lets see, where did i save that RDP info....
<clever> looks like i will need to start from setup-x86_64.exe
<clever> so there wont be any confusion within hydra
<clever> ah, good
<clever> viric: also, what does builtins.currentSystem eval to under cygwin64?
<clever> is the install as simple as just doing ./configure && make && make install on a nix checkout, and then initializing the store as usual?
<clever> i was thinking of running ghc to build haskell packages
<clever> ah, thats similiar to what i'm thinking
<clever> viric: how well does nix work under cygwin64, and is it possible to have a nix based toolchain that can create executables that dont depend on cygwin at runtime?
<clever> yeah
<clever> and is hardened against such things, though it relies on where libstore puts /tmp/nix-build-foo
<clever> channel unpacking its its own derivation, that can run fully in a sandbox
<clever> which is very different from how it handles channels, oddly
<clever> and basicaly runs nix-store --add-fixed on the result
<clever> it looks like nix runs tar outside of the build sandboxes, and just throws it into a random tempdir
<clever> but deleting the -unpacked variant would force it to re-unpack, which might be enough for this bug?
<clever> the .tar.gz may also be +x'd, which impacts the path to the unpacked stuff
<clever> your fs is ruining things
<clever> so the tar unpacking ISNT pure! lol
<clever> ahhh
<clever> so the garbage collector will just eat things without warning
<clever> and these symlinks arent gc roots
<clever> but if it gives the same .tar.gz, it can reuse the unpacked directory, because it knows tar is pure
<clever> because its using a hash of the url as a key
<clever> any change to the url will also trigger a re-download
<clever> but if you delete the .tar.gz itself, that -file points to, it has to re-download
<clever> if you only deleted the unpacked directory, it will just re-unpack it
<clever> then the second layer, is hash(tar.gz) + "-unpacked", which points to the unpacked version of the tar
<clever> the -file symlink points to the result of the download
<clever> the .info contains timestamp and etag info, to cache downloading the tar.gz
<clever> viric: first layer is hash(url) + ".info" and hash(url) + "-file"
<clever> viric: ls -ltrh ~/.cache/nix/tarballs/
<clever> there is also another layer of caching and timeouts
<clever> and its subject to normal garbage collection
<clever> the nix store
<clever> if 2 processes try to download the same url at once, it crashes
<clever> that code also had a race condition in it
<clever> viric: i recently read the source dealing with that, one min
<clever> just dont do it as root
<clever> that will run all of the phases
<clever> but you can manually run genericBuild to start it up
<clever> nix-shell doesnt start a build
<clever> yeah
<clever> and nix-shell doesnt automatically run the unpackPhase
<clever> the unpackPhase is what complains about it being missing
<clever> srhb: and src = ./.; wont do?
<clever> buildEnv doesnt need a src
<clever> so the overlays can chain together and apply changes in order
<clever> samae: super is the pkgs set from the previous overlay (or the original un-altered one)
<clever> samae: so trying to override foo = pkgs.foo.override would result in infinite recursion
<clever> samae: as for super vs pkgs, pkgs refers to the final set, after all overlays are applied
<clever> so thats qutebrowserWE = super.qutebrowser.override { withWebEngineDefault = true; };
<clever> and everything past the mkDerivation on line 27, is controlled via overrideAttrs
<clever> everything defined at the top is controlled via .override
<clever> yeah
<clever> samae: also, i think thats a .override option, not overrideAttrs
<clever> samae: you want to use super.qutebrowser.overrideAttrs, to start with
<clever> mal_: also, that buildEnv is useless, the buildInputs are already in the env
<clever> the code at the top is basicaly just pkgs = <nixpkgs>;
<clever> you need to import the result of fetchFromGitHub, and pass it {}
<clever> mal_: the pkgs you defined is a path to nixpkgs, not an instance of nixpkgs

2017-08-21

<clever> neonfuz1: i get that a lot on my laptop, its more like a touchscreen then a normal mouse
<clever> Startup finished in 6.382s (kernel) + 13.629s (userspace) = 20.011s
<clever> pxc: my machine has a mix of ssd, nvme, and spinning rust, but the bulk of / is on ssd's, [root@amd-nixos:~]# systemd-analyze
<clever> nwuensche: make sure rastertobrij2 is also patchelf'd fully
<clever> disasm: rastertobrij2 needs its own rpath and interperter, so it can run stand-alone
<clever> then you can see exactly what arguments rastertobrij2 is ran with, and can manually run it
<clever> "strace -f -s 3000" will give longer strings in this log
<clever> yeah, its an executable, and the path looks to already be corrected
<clever> [pid 18929] execve("/nix/store/656q3wybdk2ainlmizy8d3v0k03a3q44-mfcj47dd0dw-cupswrapper-3.0.0-1/usr/local/Brother//lpd/rastertobrij2", ["/nix/store/656q3wybdk2ainlmizy8d"..., "-pi", "/nix/store/656q3wybdk2ainlmizy8d"..., "-rc", "/nix/store/656q3wybdk2ainlmizy8d"...], [/* 69 vars */] <unfinished ...>
<clever> it may also need "strace -f"
<clever> up some more
<clever> do any lines mention rastertobrij2 ?
<clever> echo "foo" | strace ....brlpdwrapperMFC5440CN
<clever> checking what syscall it used would confirm that, run brlpdwrapperMFC5440CN under strace
<clever> "/usr/local/Brother//lpd/rastertobrij2" sounds more like an executable then a library
<clever> srhb: the teamspeak3 client has a good example
<clever> srhb: an LD_PRELOAD library that can redirect most filesystem access
<clever> srhb: up next, libredirect on /usr/local/Brother//lpd/rastertobrij2
<clever> nwuensche: what if you manualy run the filter in a shell?
<clever> and if you just throw random values at it, it will probably barf with a location
<clever> to start with, what does builtins.functionArgs say about it?
<clever> that makes things harder
<clever> it needs a string and an attrset
<clever> { a = false; b = false; c = true; }
<clever> nix-repl> builtins.functionArgs ({ a, b, c ? "default" }: "foo")
<clever> gchristensen: part 1: nix-repl> builtins.unsafeGetAttrPos "fetchgit" pkgs
<clever> { column = 3; file = "/nix/store/8h2rvq50a25gs1iasaycjlxksrqq0hbj-a905b7cd0c2dc0714195a50bf176cd8e4593502d.tar.gz/pkgs/top-level/all-packages.nix"; line = 140; }
<clever> brb
<clever> and confusingly, there are 2 with the same name
<clever> thats a buildEnv
<clever> /home/clever/apps/nixpkgs/nixos/modules/services/printing/cupsd.nix: name = "cups-progs";
<clever> xd1le: the 2nd
<clever> xd1le: cant think of anything obvious as to why pkg-config wouldnt find it when ran earlier like that
<clever> that just pulls in the entire current directory
<clever> i use src = ./.; a lot
<clever> xd1le: yes
<clever> nwuensche: yeah
<clever> nwuensche: src = ./foo.txt;
<clever> that sounds right
<clever> depends on if its loaded with dlopen or just ran
<clever> the cupsd is 64bit
<clever> even if you patchelf the driver properly with 32bit stuff
<clever> yeah, i thought that might happen
<clever> nwuensche: pkgs.callPackage_i686 is also an option, and does the same thing
<clever> nwuensche: use pkgsi686Linux.callPackage to load this nix expression
<clever> nwuensche: and where is this file being loaded?
<clever> nwuensche: can you gist your current nix expression?
<clever> srhb: the everything you get is 32bit by default
<clever> srhb: use pkgsi686Linux.callPackage to load this nix expression
<clever> nwuensche: now i can print directly from chrome, even if the printer has left the house
<clever> nwuensche: the last printer i used has google cloud print sharing built right into it, i linked it to my google account
<clever> nwuensche: hmmm, i think you need the drivers working even if your sharing via another cups?
<clever> netstat -anp | grep <pid>
<clever> lsof -p <pid>
<clever> nwuensche: netstat and lsof may also work better
<clever> nwuensche: this may find the other end of the socket
<clever> nwuensche: ls -lh /proc/*/fd/* | grep 211478
<clever> nwuensche: what are 0/1/2 going to?
<clever> no extra downtime then
<clever> i generally just dont upgrade it until it fails hard, lol
<clever> nextloop: how major is the HA setup?, my power goes out more often then the nixos router crashing
<clever> ah
<clever> nextloop: but, there is also a 3rd uplink, that is BRIDGED into the private lan, effectively bypassing the firewall
<clever> nextloop: the other uplink gives an ip in the 10.0.0.0/8 range, and has multicast service
<clever> nextloop: my ISP has 2 uplinks over the same cable using 802.1q, one uplink gives a single public ip
<clever> krav_: that would create a symlink called polybar in the current dir, pointing to the polybar path
<clever> krav_: one way, "nix-build '<nixpkgs>' -A polybar -o polybar"
<clever> nextloop: yeah, my ISP's router is pretty fishy as well, in more hidden ways
<clever> krav_: and from what context? a shell? another nix expression?
<clever> krav_: which derivation?
<clever> nextloop: something configured in bridge mode could do the same job and firewall, though the example i linked may not work as well there
<clever> the dhcp/dns doesnt have to be on the same machine, and can just be a normal system on the LAN
<clever> nextloop: or maybe 1 (or more) systems configured in bridge mode, with SPAN enabled, so there is no gateway configured
<clever> nextloop: at that point, do you even need a router?, just link the modem directly to the systems with a swich?
<clever> ah, thats a bit weird
<clever> nextloop: what IP's are inside the lan?
<clever> nwuensche: that will show every file it currently has open
<clever> nwuensche: try "ls -l /proc/<pid>/fd/" with the pid of cups
<clever> it would only work if your ISP gives you several publicly routable IP's and you just dont NAT
<clever> but the conntrack module doesnt allow inserting state, so no way to sync them
<clever> ah, that would work, but i havent seen anything about support for it in nixos
<clever> and even if you didnt have NAT, most devices only accept 1 gateway, so it has no way to fallback
<clever> any form of NAT results in state held in ram, and loosing that state breaks every single connection
<clever> nextloop: the dns and dhcp can possibly be configured for HA, but the router part cant really do that
<clever> nextloop: i have nixos on my router, let me grab an old copy of its config
<clever> krav_: which derivation?
<clever> joehh: it has a large example and a description
<clever> joehh: that sounds like it only gets cleared on reboot
<clever> joehh: every package gets its own directory, so the files can never clash, and it will never read something from another package
<clever> joehh: nix doesnt allow that
<clever> joehh: its at this path on my system, so you would need to apply a packageOverride to systemd, and then rebuild everything that depends on systemd
<clever> /nix/store/iphlqy571rhfc8z7j8dy5wh6m7vdppci-systemd-233/lib/systemd/system-sleep
<clever> lol
<clever> ?
<clever> nixos installs it automatically when enabled
<clever> odd
<clever> Nobabs27: does the journal give any errors?
<clever> i believe nix-push is incremental
<clever> dylanjust[m]: or an absolute path into the store, that the nix expressions computed
<clever> dylanjust[m]: yes
<clever> the binary cache is just a collection of smaller archives (not full closures), for every single package
<clever> dylanjust[m]: just nix-store -r /nix/store/foo and it will download foo from a cache
<clever> dylanjust[m]: you can pull the same way without a channel, if you have a binary cache setup
<clever> Nobabs27: check the journal for display-manager for more hints
<clever> dylanjust[m]: nixos already has tools to generate a AMI with nixos pre-installed, including any apps you want
<clever> gchristensen: i ran into a similiar weird bug a week ago, where it claimed things where not valid for no reason at all
<clever> cannot import ‘/nix/store/v2w72ydhc2sygmaqnzhfw7b04z3i54mv-nixpkgs-channels-25f4906da6387e132823417bc54ea86040fb9bd5-src’, since path ‘/nix/store/pkb1w9v39kz26fm109si5d6hxb699q32-nixpkgs-channels-25f4906da6387e132823417bc54ea86040fb9bd5-src.drv’ is not valid, at /tmp/dyno/nixpin.nix:5:3
<clever> while evaluating the file ‘/tmp/dyno/nixpin.nix’:
<clever> yeah, thats unrelated
<clever> Nobabs27: so you need to figure out if the config belongs under [LightDM] or [Seat:*], then either use extraSeatDefaults or patch the module
<clever> Nobabs27: maybe this: https://nixos.org/nixos/options.html#xserver.reso
<clever> Nobabs27: on my system (slim + xfce), slim runs at the wrong resolution, then after i login, xfce configures things properly
<clever> Nobabs27: a quick google says that i3 doesnt support setting the resolution, so you just need to arrange for the xrandr to run every time you login
<clever> Nobabs27: yeah
<clever> gchristensen: id say thats going to fail when garbage collection runs and eats things
<clever> Nobabs27: lightdm is the display manager, there is also a desktop manager that runs after you login
<clever> Nobabs27: the one that comes up after you login
<clever> Nobabs27: are you using a desktop manager?
<clever> it will only search what is available in the nixpkgs on your channels
<clever> it has no way of knowing which one you just copied over and want to use
<clever> dylanjust[m]: that gives it a different set of nixpkgs to search within
<clever> dylanjust[m]: the nix-env search commands always search nixpkgs, not what has been copied over
<clever> gchristensen: you can also "nix-env -i /nix/store/foo" directly on the path you copied
<clever> oscarvarto: i run it on most of my systems
<clever> yeah
<clever> Dezgeg: ahh, so it takes a disk image and a cmd
<clever> how did you run grub-fstest?
<clever> Dezgeg: ive also heard that grub totally ignores the journal, so things may read back corrupted after an improper shutdown
<clever> Dezgeg: ive also found that ls on zfs is far far far worse then a simple lookup
<clever> so those inode warnings probably where on my end
<clever> i had used a nixos-in-place variant, and couldnt change the FS to what i prefer
<clever> Dezgeg: oh, and i think my netbook has an xfs / without /boot
<clever> Dezgeg: ahh
<clever> xfs and zfs have the same issue in grub
<clever> i believe i was passing on information i heard from another user
<clever> 2017-07-30 20:42:14< clever> gchristensen: when /boot is on the same fs as /, grub has to navigate the horrors of /nix/store to find kernels, and spits out many warnings about invalid inodes
<clever> and due to timezones, that was on the 30th here
<clever> hmmm, thats barely a month ago
<clever> Dezgeg: heh, can you pastebin it to remind me?, or give a date

2017-08-20

<clever> Dezgeg: probly somebody else, i always go for a safe ext4 for /boot
<clever> this allows the "ds9" user to only run those 2 commands
<clever> ds9 ALL=(root) NOPASSWD: /root/reload_lighty , /root/ubc
<clever> this line allows the members of the wheel group to do anything
<clever> 2015-07-11 03:48:59< bubs> %wheel ALL = (ALL) NOPASSWD: ALL
<clever> id say its just not safe in general to run the entire desktop as root
<clever> so the neo user cant read $XAUTHORITY
<clever> yeah, the problem there is that the X server is running as root
<clever> freeman42x: what about "sudo -u neo xterm"
<clever> try something simple like: sudo -u neo 'id'
<clever> freeman42x: it works perfectly when i run it
<clever> $ sudo -u root 'id'