<clever>
ilya-fedin: nerdfonts will never be written to .ro-store
<clever>
ilya-fedin: the size is fixed when the image was made, and it never has free space
<clever>
ilya-fedin: you cant, its read-only
<clever>
JonReed: ${my-var} should work in bash
<clever>
pie_: and all-packages.nix has an area where it calls that function a bunch
<clever>
pie_: the result of linuxPackagesFor is a linuxPackages set
<clever>
pie_: yeah, there should be a block in all-packages.nix, that generates things like linux_5_2 with callPackage
<clever>
inkbottle: nix-shell gets the dev stuff automatically
<clever>
,library inkbottle
<clever>
pie_: you probably want to start by adding a kernel under os-specific/linux, callPackage'ing in all-packages.nix, and then run linuxPackagesFor linuxSurface; to generate a linuxPackages set
<clever>
pie_: the stuff in all-packages mostly deals with building modules for every kernel
<clever>
inkbottle: probably, start with `nix-shell -p cairo` and see what fails next
<clever>
yeah
<clever>
which only updates the nixos channel
<clever>
`nixos-rebuild --upgrade` will automatically do `nix-channel --update nixos` for you
<clever>
and sudo should be setting the new $HOME correctly
<clever>
probably just nix-channel --update
<clever>
sudo chown brad -R /home/brad/.cache/
<clever>
you should own everything in your ~/.cache
<clever>
ah
<clever>
the permissions on your /nix/var/nix/profiles/per-user/brad may be broken
<clever>
nix-channel --update also shouldnt need root
<clever>
bdju: and there should now be a home-manager in `ls -lh /home/brad/.nix-defexpr/channels/`
<clever>
i would just delete the symlink and remake it, pointing to the right path
<clever>
Ericson2314: the problems i can remember having, is getting c++ support in the gcc, and getting the gcc to be able to find crt0 and newlib
<clever>
this seems to at least start to eval, and now its building something
<clever>
[clever@amd-nixos:~/apps/nixpkgs-vc4]$ nix-build -A vc4-gcc-stage1
<clever>
Ericson2314: i think its trying to cross-compile the binutils to the target?
<clever>
[clever@amd-nixos:~/apps/nixpkgs-vc4]$ nix-build test.nix -A vc4-binutils
<clever>
error: Package ‘binutils-vc4’ in /home/clever/apps/nixpkgs-vc4/pkgs/development/misc/vc4/binutils.nix:4 is not supported on ‘vc4-none’, refusing to evaluate.
<clever>
no idea then
<clever>
magnetophon: what about `type pinentry` ?
<clever>
magnetophon: and then try signing again?
<clever>
magnetophon: and if you restart the agent with gpg-agent /bye ?
<clever>
magnetophon: sounds dbus related, any differences if ran as root?
<clever>
nschoe: and there are helper functions in the stdenv to add to a : seperated list
<clever>
nschoe: then something else will just use wrapProgram to persist the current value of GIO_MODULE_DIR
<clever>
nschoe: your setup hook likely just needs to add @out@ to GIO_MODULE_DIR
<clever>
infinisil: there is a pkgs.substituteAll that does almost that
<clever>
nschoe: addEnvHooks will run your thing for every buildInput, but you likely want to just export a var and not define any function
<clever>
wedens[m]: not currently, but it could be written, callCabal2nix basically does the same thing, it just uses cabal2nix to generate an expr, then callPackage to load it, and whatever it referenced
<clever>
pkgconfig has an example of a setup hook
<clever>
yeah
<clever>
but nothing that uses glib-networking later on
<clever>
nschoe: thats only wrapping the programs under libexec, for glib-networking itself
<clever>
so if you put glib-networking into the buildInputs, then the glib-networking setup hook gets ran
<clever>
a setup hook behaves similar to a shellHook, but works one derivation later
<clever>
wrapProgram just creates a shell script to wrap a program, 100's of examples are in nixpkgs
<clever>
nschoe: for setup hooks, look at things like pkgconfig
<clever>
nschoe: at build and shell time, you can use a setup hook to set that var, then something else needs to wrapProgram the final binaries
<clever>
but i havent found where yet
<clever>
i expect its there, because systemd can report it when services stop
<clever>
something ive been wanting to do, is see how much network a given cgroup or pid is using
<clever>
and then include it into the FHS, like any other library
<clever>
just make a normal package, that has a library in $out/lib/
<clever>
and you dont need to use the extra commands any
<clever>
so just throw the libraries into $out/lib and it should work out
<clever>
i checked under `steam-run bash`, and /lib and /usr/lib have identical contents
<clever>
why?
<clever>
wrl: does it even need to be using an FHS env?
<clever>
wrl: try adding files to $out/lib/dssi and see what happens
<clever>
wrl: i think /usr is just a symlink
<clever>
wrl: try putting it at /lib/dssi instead
2019-11-01
<clever>
__marlene__: you can also use --option key value, to change flags
<clever>
bbarker: yes, you put it into the .serviceConfig of a service, in a nixos module
<clever>
bbarker: those flags can go under the .serviceConfig
<clever>
bbarker: `man systemd.exec`
<clever>
kolaente: for postgresql, you would pgdump the DB's, upgrade things, then re-import the DB's
<clever>
bbarker: all systemd services
<clever>
kolaente: nixos uses the stateVersion to keep you on an older postgresql, until you read the release notes, and follow the migration directions
<clever>
nixos has no way to do that
<clever>
so, you must repair the ~/.ssh/known_hosts for every remote machine
<clever>
updating to the new type, results in mitm warnings for every remote machine that ssh's into the nixos box
<clever>
kolaente: openssh host keys for example, changed the default type
<clever>
kolaente: that not currently implemented, and sometimes the actions you must take extend to other machines
<clever>
any attempt to change stateVersion (automated or manual) will result in postgresql loosing the database
<clever>
and nixos uses stateVersion to figure out what format you used when you first installed, so it can keep using that format
<clever>
for example, postgresql likes to change the on-disk format of the db's with every version
<clever>
zeta_0: the stateVersion shouldnt be changing, and the whole point is to record what version your "state" is
<clever>
,stateVersion kolaente
<clever>
kolaente: pretty much
<clever>
so youll only start to notice it as you update again in the future
<clever>
zeta_0: the difference is more that unstable updates often, and may sometimes break your configuration
<clever>
zeta_0: all nix-channel --list does, is cat ~/.nix-channels
<clever>
zeta_0: yes, each user has its own channel list
<clever>
bbarker: security.pam.loginLimits
<clever>
wrl: the import function will take the path to a file, and return whatever nix expr is in that file
<clever>
100's of examples are in nixpkgs
<clever>
yes
<clever>
then use wrapProgram to add a LD_LIBRARY_PATH to the main binary, that is loading the plugins
<clever>
you can just use a bash for loop, to apply the patchelf to everything automatically
<clever>
wrl: even if you fix LD_LIBRARY_PATH, the interperter is wrong, so you cant run any binaries
<clever>
wrl: why do you not want to use patchelf?
<clever>
enteee: nix-shell can test everything except for the copy to /nix/store/
<clever>
enteee: if you want to test things, you either need to re-export $out to point somewhere else, or use nix-build to test
<clever>
enteee: installPhase will never work in nix-shell, since only nix-build gives you write access to $out
<clever>
enteee: yes, and if you lack +w access, it will do it via nix-daemon
<clever>
enteee: nix-build should just work on non-root without any env vars
<clever>
CMCDragonkai: and if you use too much, then allocations will just begin to fail, causing all kinds of problems
<clever>
CMCDragonkai: if you try to write too much to a tmpfs, it will swap out the same as normal app ram, whatever was used the least
<clever>
yep
<clever>
i should get to bed, its now 3am
<clever>
and `devnull` in this context, is a python file handle, that results from opening /dev/null on the host
<clever>
Miyu-saki: all of stdin/out/err are pipes, likely going to the parent process
<clever>
CMCDragonkai: the dhcp config in here tells machines to run boot.php (legacy name, lol) which then says to chainload netboot.ipxe (which release.nix is generating for you)
<clever>
Miyu-saki: ah, i last saw that under the name bumblebee, and none of my hardware supports it
<clever>
Miyu-saki: hadnt heard of it
<clever>
Miyu-saki: weird
<clever>
zeta_0: looks right at a glance, try it and see what happens
<clever>
drakonis1: HDCP is used to encrypt video as its sent over an HDMI cable, so only approved devices (tv's) can play the content, and un-approved devices (capture cards) cant
<clever>
notgne2: hdcp has also been cracked wide open, so the only thing stopping you is law suits if you try to sell a product to strip crypto
<clever>
notgne2: so any drm riddled player wont trust the kernel, and wont give it a copy of the video stream
<clever>
notgne2: yeah, if i load an unsigned kernel module (anything built with nix), then the kernel is tainted and could be sniffing the video stream
<clever>
notgne2: it does things like refuses to playback content until the kernel can proove that the kernel hasnt been modified, and the hdmi channel is encrypted