<clever>
rrr: what is your configuration.nix and what is the error it has?
<clever>
rrr: lvm is always available in the initrd
<clever>
rrr: lvm?, mdadm?
<clever>
pie_: :D
<clever>
pie_: libredirect?
2019-05-03
<clever>
but the new haskell.nix stuff is entirely seperate from the old haskellPackages stuff
<clever>
blackriversoftwa: yeah, thats mostly done with overlays in the haskellPackages context
<clever>
blackriversoftwa: there are ~3 ways that is delt with, a translation map in cabal2nix, passing the right name when you callPackage, adding an override in the haskell overlay
<clever>
pie_: there are some functions in nixpkgs that do basically that
<clever>
nh2: `env | grep -i --color prop`
<clever>
exarkun: `avahi-browse -at` does something similar
<clever>
,locate mdns-scan
<clever>
tilpner: nix-store --verify
<clever>
so, while it keeps the known-good nixos, it wont let you boot it :P
<clever>
so that booted version wont be put back into the bootloader
<clever>
it wont GC the target of booted-system, but it can delete the generation link
<clever>
infinisil: it booted x86-64 and armv6l on the same rootfs
<clever>
have i ever mentioned the 1st frankentstein install?
<clever>
and the desktop is the 2nd install i ever made
<clever>
my desktop is up to 470
<clever>
from maybe 6 nixpkgs revs
<clever>
18.09 and 19.03 are still present
<clever>
18.03 was on the disk, but is gone now
<clever>
up to gen 154 now
<clever>
it has been keeping every single build of nixos, from day 1
<clever>
i recently discovered my laptop still had generation 1 of nixos, lol
<clever>
youll still have 100 copies of glibc
<clever>
infinisil: its also going to hella-waste disk space by giving you 100 copies of glibc!
<clever>
infinisil: thats going to make the qt version mismatch stuff 100x worse :P
<clever>
2019-05-02 23:12:27 < infinisil> So you wouldn't install hello from nixpkgs version 1e6bf25, but instead say "I want hello" and the tool would search the latest nixpkgs version that has a successful build of hello
2019-05-02
<clever>
emilsp: install nix-index, and run nix-locate
<clever>
zen_monk: yes, but that wont run a tor node on its own
<clever>
so when execve returns a new error code, it gives a sane msg
<clever>
the libc in the parent process
<clever>
gchristensen: and libc would also need to be extended to translate the error corectly
<clever>
gchristensen: i think that would be a kernel level patch
<clever>
try all of them!
<clever>
iqubic: check the device profiles on the configuration tab
<clever>
keep doing things!
<clever>
m
<clever>
iqubic: run alsamixer, select the non-pulse device with f6, and then play with the mute and volume levels on the capture page
<clever>
iqubic: you can even `export TZ=America/Halifax` to affect only the programs in one shell
<clever>
arcnmx: i think its because the nix deleting the path will exclude itself from the gcroots, but the sudo that started it isnt excluded
<clever>
so i have 4 clocks on-screen, each showing a different timezone
<clever>
roconnor: i can also reconfigure the xfce clock to show any 1 timezone, and i can put multiple clocks onto a single taskbar
<clever>
so just dont sudo it
<clever>
but you dont need sudo to delete paths
<clever>
it also checks the argv
<clever>
but, sudo nix-store --delete /nix/store/foo, will result in sudo "using" it, so it can never be deleted
<clever>
arcnmx: nix-store --delete /nix/store/foo will not depend on foo, for obvious reasons
<clever>
yeah
2019-04-30
<clever>
yeah
<clever>
arcnmx: part of it, is that if the build needs certain inputs, nix will try to push them over, and then the slave must trust those pre-built inputs
<clever>
arcnmx: ah
<clever>
arcnmx: ive used the community box as a build slave without issues
<clever>
arcnmx: weird
<clever>
arcnmx: then build slaves should also work, if you can turn off sig checking (or sign things)
<clever>
arcnmx: try using `nix-copy-closure` to copy a given drv over
<clever>
because you just save it as hash($bad), and it co-exists beside hash($good)
<clever>
i cant give you $bad, and claim its $good
<clever>
arcnmx: nope, because the .drv file is purely a hash(value)=value based DB
<clever>
so you must trust that remote machine to give you what you asked for
<clever>
the problem build slaves introduces, is that you are trusting a remote machine to just give you a tar, claiming its $out
<clever>
nix-daemon enforces that $out is made by the directions, so if you ask for the original sudo, you get the original sudo
<clever>
arcnmx: and $out is also based on that same hash
<clever>
arcnmx: evaluation is done by the user, and is turned into .drv files, that are named after the hash of the build directions
<clever>
JaakkoLuttinen[m: pkgs.substituteAll
<clever>
you can also `nix-store --verify --check-contents` to make it just test the hash of everything
<clever>
if they get out of sync, somebody has been naughty, and nix will claim the directory is corrupt
<clever>
and the above is how to query the correct hash, and compute the current hash
<clever>
camsbury: nix also tracks the hash of every directory in db.sqlite
<clever>
camsbury: but did db.sqlite claim its valid?
<clever>
camsbury: i think the problem is more that docker doesnt understand that, and it makes a new layer for every command in your compose file
<clever>
camsbury: you probably want to just generate a docker image directly from a nix expr
<clever>
camsbury: docker compose will want to re-run the commands when you change things, similiar to how nix rebuilds when you change the expr
<clever>
manveru: so the end result of the nix-build was just a single directory full of html&css, and it could then be hosted staticly
<clever>
manveru: i saw a wordpress setup before, explained in some blog, where it would spin the entire thing up in a vm, then clone it with recursive wget
<clever>
yeah
<clever>
Twey: but cc-wrapper needs to manipulate those flags
<clever>
Twey: i think gcc accepts @file in the args, and then you can put any gcc flag into the file, to get around argv length issues
<clever>
kalbasit: bind mounts can be used to get around that
<clever>
kalbasit: yeah
<clever>
aha
<clever>
hodapp: what channel are you on?
<clever>
docs make no mention of that, did you set guiAddress?
<clever>
hodapp: what does `journalctl -f -u syncthing.service` say?
<clever>
then you just need to modify the import function to both recurse/spread-like-a-virus (when importing, it should use scopedImport moar!), and also to detect the filename in question, and import the "wrong" thing
<clever>
yeah
<clever>
you can then pass the function it returns to callPackage to provide it the args it originally wanted
<clever>
that will replace what `import` does within the imported file
<clever>
i think the original goal, was to let you install QT plugins with nix-env -i, and it would then search ~/.nix-profile/lib/qt-5.9/ at runtime to discover them
<clever>
patching qt to use 5.9.0 instead of 5.9 would instantly fix this problem
<clever>
so now, it crashes on login :P
<clever>
ambro718: because an old QT was in nix-env, and had priority over the system QT, so the new QT apps from KDE (that manage the entire login session) borked
<clever>
ambro718: i have seen the KDE desktop env totally bork, when doing nixos-rebuild --upgrade
<clever>
why didnt it just put the libs into 1.2.1 and 1.2.2!?!?!
<clever>
and anoyingly, QT puts the libs into a 1.2 dir, but then if you mix 1.2.1 and 1.2.2, it complains and refuses to start
<clever>
if 2 different things both request QT via nix-support/propagated-user-env-packages, nix-env wont even tell you about the collisions
<clever>
QT has a lot of problems in this area
<clever>
well, it wont even be there for nix-env -i /nix/store/foo, only nix-env -iA nixos.foo
<clever>
and it would forget about it
<clever>
but the 2nd time around, when its only in manifest.nix, it wont be there (enless you save it to manifest.nix)
<clever>
they may be available during the first pass with nix-env -i /nix/store/foo
<clever>
yeah
<clever>
-i and -e, will read ~/.nix-profile/manifest.nix, apply some mutations (adding/removing things), then build a new env based on that result, and bake the new manifest.nix into it
<clever>
but thats different from --set
<clever>
which will remove all other packages when installing home-manager-path
<clever>
home manager might be using nix-env -ir
<clever>
as far as nix-env is concerned, your just upgrading a "package" called "home-manager-path"
<clever>
ambro718: thats what i prefer, and that behaves very similar to home-manager (from nix-env's viewpoint)
<clever>
so if a noob does nix-env -i, it will the second layer of buildenv will merge things sanely
<clever>
the perl buildenv merges everything, then the c++ buildenv merges that with /manifest.nix to create ~/.nix-profile/
<clever>
then home manager is the only thing installed, but it is a sort of double buildenv
<clever>
i dont have home manager, so i cant see what it does
<clever>
ah
<clever>
ambro718: ~/.nix-profile/manifest.nix is missing?
<clever>
what does nix-env -q report on your end?
<clever>
and that would use the perl version in your current nixpkgs
<clever>
and then just name that bash script home-manager-rebuild
<clever>
and like nixos-rebuild, you can just make a bash script that mutates the config, and then calls that for you
<clever>
you would do something like, nix-env -f '<home-manager>' -A config.system.toplevel --set ~/.nix-profile
<clever>
yeah
<clever>
no storage is on the pi, so all changes can be undone remotely
<clever>
and if i brick the pi, i can just --rollback to undo!
<clever>
my tftp dir is then pointing at that, so it just boots
<clever>
ambro718: this builds an netboot compatible image of notos (for the rpi), and puts it into a profile