<clever>
NemesisD: if the user running nix has +w to /nix/store, then they are a trusted user, and can directly mess with substituters and trusted-public-keys
<clever>
NemesisD: trusted-substituters is a whitelist of what the system will allow non-trusted users to use, and substituters is what is actually in effect
<clever>
NemesisD: if your not trusted, then you can modify only substituters, and your restricted by the systems trusted-substituters + trusted-public-keys
<clever>
NemesisD: if your in that list, then you can use `--option substituters "a b c"` and `--option trusted-public-keys "a b c"` to change things
<clever>
NemesisD: nix.trustedUsers
<clever>
if you set yourself as a trusted user, then you can bypass those entirely
<clever>
yeah
<clever>
NemesisD: so a malicious build slave (or cache) can serve up a variant of that path, with changes done to it
<clever>
NemesisD: but nothing enforces a builder actually obeying those directions
<clever>
NemesisD: $out's hash is computed from the directions on how to build $out
<clever>
kalbasit: line 73 deals with that, in the default startup path
<clever>
kalbasit: main problem i ran into, is that /etc/shadow must not be world readable, so i have to chown it when the container boots (if i want sudo to work)
<clever>
NemesisD: requiring root is what ensures that the admin of the box trusts things, and its not some random user doing whatever they want
<clever>
NemesisD: the problem is that the user has to trust the cache to not provide trojan'd copies of the storepaths...
<clever>
kalbasit: if you create a file at $out/etc/passwd, and install it into the docker image, you can get nearly identical effects
<clever>
kalbasit: i try to avoid runAsRoot whenever possible, its a fairly expensive (cpu wise) step
<clever>
but i agree that my method is slower and needs a better understanding of everything
<clever>
i prefer nix-du to find the fat things, nix-store --query --roots to find out why its rooted, and then manually removing select generations, rather then all older then X
<clever>
if you run it without root, then it cant delete system (nixos) profiles
<clever>
`nix-collect-garbage -d` will delete all non-current generations from all profiles it has access to
<clever>
aveltras: what about just modifying the software to put its sockets in /tmp/ ?
<clever>
aveltras: not sure whats wrong there
<clever>
aveltras: src = lib.cleanSource ./.;
<clever>
fendor: https://html5gamepad.com/ also "just works!" (no need to restart anything, or even refresh)
<clever>
and it only works in a game, if i turn the controller on before starting the game
<clever>
so the dongle is dynamically creating/destroying usb devices, based on how many things are wirelessly connected
<clever>
it only appears in evtest when i turn on the controller
<clever>
fendor: in my case, i'm using an xbox 360 controller, with a usb dongle to deal with its non-standard wireless link
<clever>
that should confirm that its working
<clever>
,locate bin evtest
<clever>
fendor: just run evtest, and select the input device
<clever>
fendor: then it should function as a normal usb HID input
<clever>
fendor: you need to first use a special libusb based app to pair the controller with your bluetooth addr
<clever>
fendor: ive used the sixaxis android app before, and i think the linux variant works somewhat similar
<clever>
Taneb: if you use the right path to sudo (check `which sudo` outside), yes
<clever>
Aleksejs: try running nix-prefetch-url on the above url, and then try nixos-rebuild again
<clever>
Aleksejs: the problem is that M$ deleted the old version, so the package must be updated to use the new version, or you need to find a copy of skypeforlinux_8.45.0.41_amd64.deb somewhere else
<clever>
aleph-: yeah, thats pretty much it
<clever>
Aleksejs: you may want to temporarily comment out skype in your configuration.nix
<clever>
Lukas4452: libquazip.so got renamed within its derivation, which breaks teamspeak
<clever>
Baughn: nixos-rebuild --option substituters '' will disable the cache entirely
<clever>
Baughn: the problem is that the config changes your offline, modify storepaths, and nixos-rebuild is dumb and checking for those paths on a cache
<clever>
Baughn: ah, then you want to just idsable the cache
<clever>
Baughn: if you prebuild the system attr, you can just ${system}/bin/switch-to-configuration {switch|boot} in a shell script
<clever>
aleph-: that may be all you need
<clever>
kraem: then you want nix-env -p /nix/var/nix/profiles/system --list-generations
<clever>
Baughn: behind the scenes, all it does is build (import <nixpkgs/nixos> {}).system and then run result/bin/switch-to-configuration boot
<clever>
Baughn: another option is to just skip nixos-rebuild
<clever>
kraem: possibly with a --profile to tell it which profile to list them from
<clever>
kraem: nix-env --list-generations
<clever>
Baughn: the install tests in nixos use system.extraDependencies to bake extra storepaths into the install media
<clever>
aleph-: bash can expand a range for you
<clever>
2019-07-28 16:33:03 < infinisil> colemickens: Ah yeah you can, e.g. with `sudo nix-env -p /nix/var/nix/profiles/system --delete-generations {541..596}`
<clever>
aleph-: switch-to-configuration would be faster
<clever>
aleph-: does 203's target exist? why did the error says 127?
<clever>
aleph-: ls -lh /nix/var/nix/profiles/system
<clever>
aleph-: aleph- ls -lh /nix/store/9j9cr9gi1ndias2qa1v1gdgff0izc923r-nixos-system-nixos-18.09.git.4dd9cd3
<clever>
aleph-: if you nixos-enter, what does `ls -lh /nix/var/nix/profiles/system-127-link` point to?
<clever>
it should be possible to repair the profiles
<clever>
gchristensen: that could break the current profile link
<clever>
aleph-: can you paste the output to me
<clever>
aleph-: ls -lh /nix/var/nix/profiles/system-127-link
<clever>
aleph-: ls -l that path, from within nixos-enter
<clever>
aleph-: try running `nixos-rebuild boot` within the `nixos-enter` shell
<clever>
aleph-: doesnt explain the missing kernel
<clever>
aleph-: was the only failure a user env?
<clever>
aleph-: nix can repair this stuff easily, lets wait for verify to finish first
<clever>
aleph-: either something had root at the wrong time and modified something it shouldnt have, or the fs is failing, or an improper shutdown corrupted something
<clever>
aleph-: any differences can mean corruption or filesystem failures
<clever>
aleph-: try `nixos-enter --root /mnt` and then `nix-store --verify --check-contents`
<clever>
aleph-: is isContainer present anywhere in the cfg?
<clever>
aleph-: nixos-install runs everything under a chroot, so the /nix its refering to can be the /mnt/nix/
<clever>
it detects that your building under a container, sets boot.isContainer = true; and that removes "kernel"
<clever>
aleph-: no, just commenting that it can make things worse
<clever>
zeta_0: but you can force it to build anwyays and try your hand at debugging it
<clever>
zeta_0: usually, its because the build fails, and its disabled to stop you from wasting time installing something that wont build
<clever>
WilliamHamilton: not clear why
<clever>
WilliamHamilton: not sure where that would go
<clever>
and shell.nix should `(import ./. {}).env`
<clever>
WilliamHamilton: you want to put the cabal2nix output into a foo.nix (named after the cabal file), then use a default.nix, that does haskellPackages.callPackage ./foo.nix {}
<clever>
WilliamHamilton: --arg and --argstr can be used to supply params
<clever>
WilliamHamilton: an empty set
<clever>
but nix will undo the changes
<clever>
taylskid: or you can use one of the permission fields to make it writeable
<clever>
taylskid: you could either link each file seperately (they will still be read-only, but the dir will be writeable)
<clever>
leo60228: mesa is a weird package in nixos, and you can use the hardware.opengl.package to override it, without rebuilding the world
<clever>
mog: ive seen a few nixos users run into problems because a .drv file got truncated, its easy to fix, but why even have that problem?
<clever>
mog: zfs stores a checksum of every single block on disk, while ive seen ext4 corrupt data numerous times after an improper shutdown
<clever>
pie_: i think zfs requires you to export the pool before you hibernate
<clever>
dminuoso: nix-shell is bash
<clever>
mog: you can (incrementally) send your entire filesystem to another machine
<clever>
mog: snapshots, zfs send|recv
<clever>
pie_: so if you have a zfs root, give up already :P
<clever>
pie_: of note, zfs doesnt support hibernation
<clever>
dminuoso: i think the 2nd argument there, is the path to the binary, so that would be something under dist/, and you may need to re-run source repeatedly
<clever>
dminuoso: oh, it says bash right there, what if you change that to zsh? :D
<clever>
dminuoso: using pkgs.runCommand, you can run `foo --bash-completion-script` at nix build time, and drop it into a .sh file, that you then simply source later on when opening shells
<clever>
dminuoso: if your putting it somewhere system wide, you could also make some optimizations
<clever>
dminuoso: in this case, its a nix-shell for using those programs, and it auto-loads their auto-completes into the shell
<clever>
elvishjerricco: install the gist command?
<clever>
elvishjerricco: enable ssh?
<clever>
pie_: try doing grub-install -vvv, with the rest of the args you previously pasted, under a `nix-enter --root /mnt/`
<clever>
gchristensen: each feature has different rules, and the man page explains them
<clever>
gchristensen: you have to know which features 0.7 supports, and check if they can be disabled, or just not enable them when creating/upgrading the pool
<clever>
gchristensen: it can, in some limited situations, `man zpool-features`
<clever>
evhan: it sounds like maybe its a bug with grub not understanding the output of `zpool status` or such?
<clever>
pie_: such as this
<clever>
-rwxr-xr-x 1 root root 15776 Oct 29 2017 /boot/grub/x86_64-efi/cryptodisk.mod
<clever>
pie_: once it can open /boot, it will load more modules from files
<clever>
pie_: so it wont include luks support if it doesnt think /boot is on luks
<clever>
pie_: when you run grub-install, it will figure out which modules it needs at early boot, and merge them into the .efi file
<clever>
Boot0004* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<clever>
pie_: that will show the partition uuid of whatever the bios is being told to boot
<clever>
pie_: run efibootmgr -v
<clever>
pie_: brb
<clever>
alienpirate5: for example, if i try to do a linux->windows cross compile, while on a mac, it will find a linux build slave to do the work
<clever>
alienpirate5: thats entirely possible, but you need to ask for a cross-compile, it wont magically cross with the right build slave
<clever>
pie_: grub-install doesnt use very many env vars, its likely more inspecting `mount` to see what is mounted where
<clever>
legacy will bake in "biosdisk" which is how you read a hdd via the legacy bios api
<clever>
pie_: reading grub-install.c, i can see a --disk-module arg, that specifies what grub driver to bake into itself, so it can find the next stage, but efi doesnt set one
<clever>
pie_: you could also then manually run grub-install in a chroot, to see what its doing
<clever>
if you dont feel like emulating perl in your brain
<clever>
pie_: you could also `strace -f -e execve -s 300 .... nixos-install ...` to see the exact commands it ran
<clever>
pie_: so you can just tell #grub what grub-install args are being used, and nix is out of the picture