<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>
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>
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>
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>
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/