2019-02-04

<clever> daniele-: run `nix log /nix/store/foo`
<clever> daniele-: it wont help, since nix will just recreate the same output
<clever> daniele-: i only see a single .so on the ifles you pasted above
<clever> daniele-: its more of a c level problem, not a php problem
<clever> ,paste daniele-
<clever> yeah
<clever> > stdenv.isDarwin
<clever> then throw in if statements and lib.optional's
<clever> > stdenv.isLinux
<clever> glesica: maybe, ive not done much darwin stuff
<clever> endorphin: $out will be the path it gets installed to, which is the same path pkgs.emacs returns
<clever> glesica: for darwin, you want otool
<clever> oops
<clever> WilliButz: 46
<clever> (emacsWithPackages (...)).overrideAttrs (drv: { name = "foo"; })
<clever> but, you can just take its result, and .overrideAttrs it
<clever> endorphin: the emacsWithPackages function eventually calls mkDerivation
<clever> ,paste endorphin
<clever> endorphin: set the name= on the derivation, you could change it with overrideAttrs
<clever> gchristensen: only 32mb on my end
<clever> iqubic: this is why my desktop is still dual-boot
<clever> half a typo*
<clever> QPU is half a type, but also the internals of the rpi GPU, lol
<clever> GPU i mean
<clever> iqubic: QPU passthru will be a major problem

2019-02-03

<clever> root is a trusted user by default
<clever> though ive found .net games still dont work
<clever> iqubic: proton has been patched to fix most of those issues
<clever> nice
<clever> srhb: you can force protono? :O
<clever> iqubic: what if you run ldd on libnative.so?
<clever> srhb: it assumes any error loading the 64bit one means wrong arch, and doesnt bother showing that error
<clever> iqubic: then you want the 32bit mono, nix-build '<nixpkgs>' -A mono --argstr system i686-linux && ./result/bin/mono ./somehting
<clever> srhb: ive also noticed, if minecraft cant load the 64bit so (due to missing rpath), it will try the 32bit so, then only report the "wrong arch" error
<clever> iqubic: does `file` say its 32bit or 64bit?
<clever> ,locate libnative.so
<clever> pie__: this is what (cabal|stack)2nix was doing, to handle that kind of situation
<clever> postUnpack = "sourceRoot+=/socket-io; echo source root reset to \$sourceRoot";
<clever> then you can delete the old generations as normal
<clever> jluttine: if you uninstall everything with nix-env -e, then the current generation will be empty
<clever> possibly
<clever> ah
<clever> tilpner: ?
<clever> tilpner: what does the eval say, exactly?
<clever> you now have a patch you can jam into the patches array
<clever> and thru the magic of github!
<clever> tilpner: that passes...
<clever> this should force hydra master, to use nixpkgs master
<clever> [clever@amd-nixos:~/apps/hydra-will-build]$ nix-build release.nix -A build.x86_64-linux --arg nixpkgs ~/apps/nixpkgs
<clever> tilpner: what error did unstable fail with?
<clever> lets see...
<clever> tilpner: ah, thats a new one, and i recently ran into it on my own machines: https://hydra.angeldsis.com/build/88770/nixlog/1
<clever> *looks*
<clever> what error? i have a patch for it
<clever> i think the perl bindings can be mismatched a bit, since you dont care that much about which nix the perl end uses
<clever> has to at least be meta.passthru
<clever> so it cant be an attr on the derivation itself
<clever> the perl bindings depend on the nix they are added to
<clever> they are jammed on in a weird way, so .overrideDerivation looses therm
<clever> thats how i delt with it in one repo
<clever> + nix = (import /home/clever/apps/nix-master/release.nix {}).build.x86_64-linux // { perl-bindings = pkgs.nix.perl-bindings; };
<clever> tilpner: only a few spots care about it, the bigger issue is the perl bindings, those dont carry over when you override
<clever> tilpner: double-check your gitrev against the 2 places i linked
<clever> tilpner: i think 2.1.3 is newer then 2.1pre, so it should have it
<clever> Hydra 0.1.1234.1d613d (using nix-2.1pre6148_a4aac7f). You are signed in as clever.
<clever> tilpner: which version of nix (it says that at the bottom of hydra)
<clever> tilpner: try without the trailing /
<clever> but other then that, yeah, its prefix based
<clever> tilpner: there are some funky rules, involving /, so https://github.com/Nix wont match NixOS
<clever> tilpner: that pokes holes into the restrictions hydra has, allowing you to fetch urls
<clever> tilpner: allowed-uris
<clever> pie__: its a weird attempt to dedup git repos, by sharing a single object store for every call to fetchGit
<clever> pie__: the cache in ~/.cache/nix/git/ might be corrupt
<clever> ${toString ./.} in nix is trivial
<clever> pie__: made harder by darwin
<clever> pie__: yeah, ive had to deal with that mess before
<clever> that will then run whatever is in the shellHook (and the exit makes it not open a normal shell), and provide whatever is in the buildInputs
<clever> pie__: and then `nix-shell -A fixYarnLock`
<clever> pie__: ive just been using shellHook in shell.nix files, and ignoring the #! entirely
<clever> pie__: i think that mode is generally used with -p, not -A
<clever> `git show 9d608a6f592`
<clever> pie__: nix eval nixpkgs.lib.version, if you used <nixpkgs>
<clever> Could not find Shlomif_Common.cmake - you can find it here:
<clever> CMake Warning at cmake/shlomif_common_bootstrap.cmake:7 (MESSAGE):
<clever> vonfry: can you pastebin the error, and push your nixpkgs changes to a branch somewhere?
<clever> ah, then its not really a nix-env level problem
<clever> vonfry: does it also fail with nix-build <path to nixpkgs> -A pkgname?
<clever> vonfry: what args are you passing to nix-env?
<clever> vonfry: sounds like it needs to be imported or included first
<clever> vonfry: cmake and gcc will break if you nix-env them
<clever> vonfry: include files and gcc will only ever work inside nix-shell and nix-build
<clever> nixops should automatically put the keypair its creating on the newly made machine
<clever> yl[m]: did you also delete the ec2 keypair?
<clever> yl[m]: has this machine worked before? did you rename any keypairs in the deployment?
<clever> pmahoney: sounds like they sorely need an immutable store of files (*eyes /nix/store/*) and rather then do that, they hide things in xattrs where nobody knows to find it :P
<clever> pmahoney: can you disable its use of xattr?
<clever> which can then be a potential security exploit
<clever> but then its possible for a nix build to generate a binary, that is setuid nixbld1
<clever> pmahoney: oh, the nix.conf flag filter-syscalls can disable it
<clever> pmahoney: that stuff ignores the state of the sandbox flag
<clever> pmahoney: the nix daemon disables extended attributes within the build sandbox
<clever> yeah, no need for an -I now, that we have a usable override
<clever> petersjt014: you want pkgs in that case
<clever> petersjt014: under packageOverrides
<clever> petersjt014: then you just want nix = super.nix.override { withAWS = false; };
<clever> petersjt014: ah, that wasnt in the version i checked
<clever> pie___: setupHaskellDepends only works under overrideCabal
<clever> petersjt014: foo = haskell.lib.overrideCabal super.foo (drv: { ... }); is how overrideCabal works
<clever> pie___: also, your not using myhaskellpackages anywhere,s so those overrides have zero effect
<clever> pie___: i think you want overrideCabal
<clever> nope, infinisil
<clever> ghostyy: *doh*, i had filter backwards when running that in my head
<clever> ghostyy: it can be that simple, if you want it to be
<clever> petersjt014: https://imgur.com/a/GWH0ncV
<clever> ghostyy: chattr and lsattr
<clever> petersjt014: https://imgur.com/a/VoKGjSO
<clever> petersjt014: the only functional language i learned before haskell, was nix
<clever> ottidmes: xmonad works pretty much the same way
<clever> i didnt really check if ratpoison is supported fully, but this is enough for a media frontend
<clever> jasongrossman: i also run ratpoison on my media player
<clever> petersjt014: but note, nix.nixPath only takes effect after nixos-rebuild, so you need -I nixpkgs=/path/to/your/custom/repo to bypass that
<clever> petersjt014: pretty much
<clever> and delete all references to aws-sdk-cpp, in the above file
<clever> petersjt014: at this point, it would be simpler to just edit a clone of nixpkgs, on the same rev your currently using
<clever> petersjt014: ah, i see, it will try to do an override against aws-sdk-cpp, and can then fail due to it being null
<clever> petersjt014: nixos-rebuild always obeys nixpkgs.config from configuration.nix
<clever> petersjt014: one sec...
<clever> petersjt014: under nixpkgs.config.packageOverrides
<clever> petersjt014: you have to override one of its inputs to null, nix = pkgs.nix.override { aws-sdk-cpp = null; };
<clever> petersjt014: the same place you do all other packageOverrides
<clever> petersjt014: you could override nix and set aws-sdk-cpp = null;
<clever> petersjt014: i think nix depends on it, to support s3://bucket as a store

2019-02-02

<clever> laas: outputHashMode can either be flat or recursive, the rest are simple enough to figure out
<clever> > let f = pkgs.hello.src; in "${f.outputHashMode} ${f.outputHashAlgo} ${f.outputHash}"
<clever> ,tofu laas
<clever> laas: simplest answer is to just give the wrong one, and then let nix tell you what the right one is
<clever> fixed-output derivations have the following attrs, outputHashMode, outputHashAlgo, outputHash
<clever> laas: the only way to get network access, is to define the hash of $out, and its best to do that on only the part that downloads source, or your going to have fun updating the hash every time you make a new compile
<clever> laas: use the rust framework in nixpkgs, which will handle giving cargo network at the right time
<clever> laas: what do you need network access for?
<clever> noonien: or ssh in from another machine, while its crashed, and read the journal
<clever> noonien: i would check `journalctl -b -1` to see the logs from the previous boot
<clever> noonien: sounds like a gpu issue, not a microcode issue
<clever> noonien: nix-channel --update, is what fixed it (and --upgrade runs that behind the scenes)
<clever> noonien: yeah, i use overlays any time i add packages to my systems
<clever> not that old, but it could be a bug in the nixos-channel-scripts, when the channel was made
<clever> noonien: nix eval nixpkgs.lib.version
<clever> noonien: ls -lh /nix/var/nix/profiles/per-user/root/channels/nixos
<clever> noonien: `sudo -i` and then `nix-channel --list`
<clever> noonien: do you have a channel called nixos on root?
<clever> you can also `nix-store -qR /run/current-system | grep polybar` if your current-system depends on it
<clever> nix-locate and nix-index
<clever> pbb: not easily, would be simpler to define a custom option, then have both modules check that
<clever> i just setup private-network and NAT for my containers
<clever> it would be in the guests journal, i think
<clever> otwieracz: networking.defaultGateway should still work, within the container itself
<clever> no idea
<clever> simpson: looks like nuke-references
<clever> so you can then add to it, rather then replacing it
<clever> patchelf has a flag to print the current rpath on a binary
<clever> simpler at that point to just put everything into installPhase
<clever> overriding installPhase breaks the pre/post hooks
<clever> yep
<clever> if installPhase is set, it can sometimes cause the pre/post hooks to not work
<clever> libraries should be in the lib dir, $out/lib/
<clever> it also wont find any other deps
<clever> that sets the rpath to $out, and lacks the lib subdir
<clever> > '' and ''${out} is an escaped bash var''
<clever> ,escape''
<clever> $out is a bash var, ${out} is a nix var
<clever> $out is an env var, pointing to the output
<clever> or if you want to patch it after copying
<clever> mostly preference, if you want to patch the copy in the working dir, before its copied to $out
<clever> or preInstall, or postInstall
<clever> and then the fixup phase will run --shrink-rpath, to remove un-needed things
<clever> for pre-compiled stuff, you usually just patchelf every library with the same rpath
<clever> for compiled things, there are gcc flags that just set it right from the start
<clever> when ld.so is handling DT_NEEDED, it only obeys the RPATH on the ELF file that DT_NEEDED'd the thing
<clever> ,locate bin lddtree
<clever> lddtree
<clever> the rpath has to be fixed, on the right lib
<clever> is it ROracle.so or one of its deps?
<clever> which library actually needs libmql1.so?
<clever> yeah, thats normal
<clever> `nix-shell -p` is enough
<clever> its part of glibc, which should be in the default env
<clever> you may want to use nix ldd
<clever> dckc: why is it looking in /lib/ ?
<clever> ldd wont show dlopen things
<clever> dckc: dlopen or DT_NEEDED?
<clever> -f
<clever> dckc: is libmql1.so of the right arch?
<clever> jonreeve: you would put the override into the projects default.nix, and never even touch nix-env or config.nix
<clever> dckc: strace?
<clever> jonreeve: and line 3 needs to be a key=value; set, you just have a naked value
<clever> jonreeve: the packageOverrides are missing
<clever> since your using overrideDerivation, you can just shove it into something like postInstall = '' ls $out/bin; '';
<clever> dckc: after something is compiled, you can run patchelf to modify it, or use wrapProgram to prefix LD_LIBRARY_PATH
<clever> dckc: use patchelf to add it to the RPATH
<clever> nix-env -iA nixos.newstuff, will install every value in that set
<clever> jonreeve: line 12
<clever> what file did you edit to fix things?
<clever> dckc: then you havent changed the build instructions
<clever> dckc: if the build instructions have changed, it will be a new build, and nix will redo whatever steps have changed
<clever> a left-over from when i was doing `import channels.nixos` and it failed, because nix-env had pre-imported the defexpr
<clever> likely not needed
<clever> and due to defining custom defexprs, i can: nix-env -iE 'channels: (let pkgs = channels.foo {}; in pkgs.haskell.lib.doJailbreak pkgs.haskellPackages.clay)'
<clever> import /home/clever/apps/nixpkgs
<clever> [clever@amd-nixos:~/apps/nixos-configs]$ cat ~/.nix-defexpr/test/foo/default.nix
<clever> make a config.nix that defines the expr, and install that set
<clever> it doesnt save the expr, so -u will undo it
<clever> also, i would avoid -iE whenever possible
<clever> but yeah, you need -E for jailbreak
<clever> nix-env -f '<nixpkgs>' -iA ....
<clever> oh, and -f also works
<clever> but ive also see others do, -iE '_: with import <nixpkgs>{};...' and just bypass defexpr entirely
<clever> infinisil: this is the correct way to use -E, i believe
<clever> [clever@amd-nixos:~/apps/nixos-configs]$ nix-env -iE 'channels: (let pkgs = channels.nixos {}; in pkgs.haskell.lib.doJailbreak pkgs.haskellPackages.clay)'
<clever> dckc: add unzip to the buildInputs
<clever> you dont have any channel called haskell, hence, the error
<clever> infinisil: its passing you a set of channel name -> channel path
<clever> infinisil: nix-env isnt passing you a pkgs set
<clever> remove the nixos channel from the non-root user, and nix-channel --update
<clever> they are going to cause conflicts
<clever> both root and non-root have a channel called nixos

2019-02-01

<clever> jonreeve: and in both of those?
<clever> ,callPackage
<clever> haskell.packages.ghc862.pipes-async might work then
<clever> 8.6.3 is too new
<clever> gchristensen: dang!, haskellPackages.pipes-async fails to build on master
<clever> gchristensen: how up to date are you on the cross-compile stuff? i need both a cross and native compiler in the same stdenv
<clever> gchristensen: :D
<clever> it is likely building the same version you just deleted, so no real change
<clever> nix will just remake the path again, with the same source and same output
<clever> but that wont really fix the problem
<clever> dejanr: you would have to remove the result symlink first
<clever> dejanr: the result symlink nix-build produced is a GC root, so it will never garbage collect the build
<clever> dejanr: your source hasnt changed, so its using a cached build
<clever> petersjt014: --fast just skips pre-building nix first
<clever> but, now you can chainload a netboot image
<clever> gchristensen: if it times out, or is configured for normal use, chainload grub, and boot normally
<clever> gchristensen: another option, but a bit more tricky to do securely, have ipxe as your real bootloader, which will chainload a file over https
<clever> ajs124: its $CURRENT_YEAR, just put javascript countdowns on your site!
<clever> figure out the absolute value yourself :P
<clever> so, 9 hours ago
<clever> but with the complications of timezones, i tend to give most times as relative
<clever> i would say noon or 12 noon
<clever> gchristensen: how else are we to rollback a headless machine?
<clever> gchristensen: ive had that idea already, to get ssh enabled bootloaders, for servers
<clever> elvishjerricco: also, grub has trouble if a directory has too many children
<clever> elvishjerricco: for one, certain checksum algo's arent supported, so if you set those, grub cant read it at all
<clever> The sha512, skein, and edonr checksum algorithms require enabling the appropriate features on the pool. These algorithms are not supported by GRUB and should not be set on the bootfs filesystem when using GRUB to boot the system. Please see zpool-features(5) for
<clever> elvishjerricco: yeah, a number of them
<clever> elvishjerricco: ah
<clever> elvishjerricco: ive found min-free based GC has a number of IFD related bugs
<clever> i deleted 500gig worth of snapshots today
<clever> and /nix is part of /
<clever> also, the nas above, has snapshots on /
<clever> so i rarely need to gc
<clever> the nas i mentioned above, has 2.5tb of free space
<clever> without -d
<clever> a recent GC i did on my nas
<clever> 6103 store paths deleted, 64986.73 MiB freed
<clever> lol
<clever> elvishjerricco: yeah
<clever> andrewrk: `sudo ncdu /boot/` where is all the space going?
<clever> elvishjerricco: so, you need to compute which files have to be copied, then copy them starting from the most recent generation, but check for free space at each generation, and dont copy what wont fit
<clever> elvishjerricco: nixos-rebuild switch failing, due to /boot/ being full
<clever> because it was chewing up space on / every time it made a snapshot
<clever> i originally used it to move my /nix to its own dataset in zfs
<clever> but you now have the ability to boot the install media at any time
<clever> it cost ~300mb
<clever> this puts an entire nixos livecd into the /boot/, and adds a grub option
<clever> gchristensen: i make my /boot/ 1gig or more, and put an entire nixos on it!
<clever> which is why i mentioned manually deleting a few old initrd;s
<clever> andrewrk: yeah, it only deletes old files, after copying the new files in
<clever> gchristensen: and, why cant both bootloaders, look at how much free space there is, what kernels are missing, and then compute backwards (from newest generation) which will fit?
<clever> gchristensen: this also reminds me, systemd needs the generation limit
<clever> andrewrk: you can also use nix-env --profile /nix/var/nix/profiles/system --delete-generations, to manually delete just certain ones
<clever> andrewrk: you will need to manually delete some of the older initrd's, and GC some older nixos profiles (nix-collect-garbage --delete-older-than` and then you can switch
<clever> systemd doesnt
<clever> grub has an option to limit how many generations go into /boot/
<clever> andrewrk: grub or systemd?

2019-01-31

<clever> schmittlauch[m]: i havent found any
<clever> schmittlauch[m]: nix build '(with import <nixpkgs>{}; ...)'
<clever> linkrage: there is a go framework in nixpkgs already, that handles that for you
<clever> linkrage: network can only happen in fixed-output derivations