2019-07-29

<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: my psql socket lives over here
<clever> srwxrwxrwx 1 postgres postgres 0 Jul 29 06:28 /var/run/postgresql/.s.PGSQL.5432
<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> its also missing in 18.09
<clever> but its missing in 18.03!
<clever> and 19.03 also has it
<clever> Aleksejs: which channel are you on?
<clever> Aleksejs: where do you see it in the docs?

2019-07-28

<clever> Lukas4452: dont know of one
<clever> Lukas4452: and then set LD_LIBRARY_PATH
<clever> Lukas4452: run nix-store -qR on teamspeak, find the quazip-0.8.1 path, and make a symlink to its .so file, with a new name
<clever> Lukas4452: i need to get around to updating the expr in nixpkgs master to include the latest fixes i have
<clever> Lukas4452: ive temporarily made this symlink, and then put hack into LD_LIBRARY_PATH
<clever> lrwxrwxrwx 1 clever users 74 Jul 21 19:26 hack/libquazip.so -> /nix/store/g5yvvxgc401zbhrrlnhxglp3y4kmfbbj-quazip-0.8.1/lib/libquazip5.so
<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-: either one
<clever> aleph-: yep
<clever> aleph-: nix-env --profile /nix/var/nix/profiles/system --delete-generations 127
<clever> aleph-: easily fixed
<clever> aleph-: its doing over every generation of nixos, to put rollback options into grub
<clever> aleph-: oh, i know why
<clever> ___laika: if you run `nix-shell /nix/store/foo.drv` it will drop you into that builds env
<clever> aleph-: /nix/var/nix/profiles/system/bin/switch-to-configuration boot
<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> aleph-: did you run nixos-generate-config inside a container?
<clever> sstteeffaann: you can rerun nixos-generate-config at any time to update hardware-configuration.nix

2019-07-27

<clever> infinisil: but teampseak doesnt use h264, so disable!
<clever> infinisil: it was compiled against qt 5.6, but 5.6 has broken h264 support, so it doesnt build
<clever> let me find it again...
<clever> i had to patch it to even build
<clever> and infact, the one teamspeak wants, is flagged as broken
<clever> which is much older then what nixpkgs was using
<clever> when you check the elf headers of teamspeak, you can see which qt it was originally compiled against
<clever> infinisil: it runs, but then segfaults
<clever> infinisil: a more subtle error
<clever> infinisil: i looked into it earlier, the wrong qt is being used
<clever> noonien: here is a heavily stripped down static ghc example, based on nh2's stuff: https://github.com/cleverca22/nix-tests/blob/master/haskell-init/default.nix#L3-L13
<clever> noonien: or nix-bundle for something heavier
<clever> noonien: musl-c
<clever> noonien: since its static, it doesnt care where ld.so is or any other dynlib
<clever> noonien: these nix files allow you to create a completely static haskell binary
<clever> noonien: one min
<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> niso: the docs are wrong, default.nix returns a set with 3 things, and you cant put a set in systemPackages
<clever> kiloreux: not really
<clever> kiloreux: best option is to use fewer copies of nixpkgs, and use packageOverrides to update select things
<clever> aanderse: i would check with the #zfsonlinux guys
<clever> aanderse: yeah
<clever> aanderse: you could try mounting it rw, but i'm not sure rm will work
<clever> aanderse: then rm would likely fail for the same reason, have you tried a reboot and fsck?
<clever> aanderse: nix-collect-garbage --max-freed 1
<clever> aanderse: nix should delete everything in trash next time you GC
<clever> cinimod`: yep
<clever> cinimod`: you can try an older channel like the release-17.09 branch on github
<clever> cinimod`: ive not done anything with R packages
<clever> it lets you have different sets of versions to pick from
<clever> yes
<clever> Uniaika: nix-env -iA nixpkgs.universal-ctags
<clever> Uniaika: you didnt specify your channel name
<clever> Uniaika: packages.html just assumes your channel is called nixos
<clever> Uniaika: its in all channels
<clever> ljxfstorm: { pkgs, lib, ... }:
<clever> ljxfstorm: lib.mkBefore
<clever> zeta_0: and the haskellPackages set contains every single package from hackage, with matching names
<clever> zeta_0: packages.html only shows packages, not functions
<clever> zeta_0: its a function that takes arguments and returns a package
<clever> zeta_0: you want something like haskell.packages.ghc864.ghcWithPackages
<clever> zeta_0: haskellPackages.ghc_8_6_1 is not a function
<clever> ivan: git bisect

2019-07-26

<clever> iqubic: yep
<clever> wykurz: which will obey the same flag that changes the active kernel
<clever> wykurz: the proper way (on nixos) is to use config.kernelPackages.perf
<clever> wykurz: the recomended kernel, not latest
<clever> iqubic: or run it with --help
<clever> iqubic: you need to click the icon in the tray
<clever> iqubic: thats your problem
<clever> iqubic: did you look in the tray near the clock?
<clever> iqubic: what are you expecting to happen when you run it?
<clever> wykurz: not really, you have to grab the perf from the right linuxPackages_4_14.perf
<clever> wykurz: like this
<clever> 15578 linuxPackages_5_1 = recurseIntoAttrs (linuxPackagesFor pkgs.linux_5_1);
<clever> wykurz: this function takes a kernel, and generates a package set containing all kernel stuff, built against that kernel
<clever> 15405 linuxPackagesFor = kernel: lib.makeExtensible (self: with self; {
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ vi pkgs/top-level/all-packages.nix
<clever> iqubic: did you check its manual?
<clever> iqubic: i glanced at the source code, and it looks like it just isnt supposed to open a window
<clever> wykurz: perf is under linuxPackages, which is generated by a function, that creates a variant of every package, for every kernel
<clever> linuxPackages.perf.out 2,106,048 x /nix/store/3idqjvp0kkl80ivzjrr3c73japzgqz4r-perf-linux-4.9.23/bin/perf
<clever> and the lib dir of every buildInput is added to -L automatically
<clever> oldandwise: the include dir of every buildInput is added to -I automatically
<clever> oldandwise: yeah
<clever> oldandwise: `echo $NIX_CFLAGS_COMPILE`

2019-07-25

<clever> andrewrk: and if an output with that hash exists, it wont bother running the rest of the drv to make it
<clever> andrewrk: outputHash is a promise to nix, that the output will always have the given hash
<clever> andrewrk: you likely want to remove it entirely
<clever> andrewrk: if the outputHash is uncchanged, nix will never re-run the derivation
<clever> andrewrk: can you pastebin the full nix expr?
<clever> ___laika: pretty much
<clever> ___laika: no difference for nix-shell
<clever> and recurseIntoAttrs then makes -i even slower :P
<clever> ,-A ___laika
<clever> ___laika: i think recurseIntoAttrs specially marks it so `nix-env -i` can search that whole set
<clever> ashkitten: i dont think memtest works on efi currently
<clever> ashkitten: legacy or efi?
<clever> matthuszagh: if you do src = ./file; it will need to hash the entire file on every single eval
<clever> matthuszagh: more examples in nixpkgs
<clever> matthuszagh: yeah, src = pkgs.requireFile { name = "something"; sha256 = "something"; }
<clever> matthuszagh: use pkgs.requireFile
<clever> infinisil: yeah, but you have to chase them down yourself, when --closure-size automates it already
<clever> evanjs: hmm, that makes the json a list of all deps, but --closure-size totals them for you
<clever> hmmm, --json doesnt include the deps
<clever> [{"path":"/nix/store/3qsyp7mplpmhm14wwnkg8w03bnw75cmn-hello-2.10","narHash":"sha256:0nllg4fgsl8l4bhh8yblgklwvaprblza77vdyck3ps92ib39mb87","narSize":205720,"references":["/nix/store/3qsyp7mplpmhm14wwnkg8w03bnw75cmn-hello-2.10","/nix/store/iykxb0bmfjmi7s53kfg6pjbfpd8jmza6-glibc-2.27"],"deriver":"/nix/store/3s8v7cs68wss5y0bkvhdjjnc3pqfqnmm-hello-2.10.drv","signatures":["cache.nixos.org-1:BhtKyqsI+Z3+vIcBgKnTSL9qx3pMx0a6tKksDR4Nwf9dt/lh7wGGVCYaIFS490FOvdMyUF8p
<clever> Orbstheorem: or this?
<clever> $ nix path-info --store https://cache.nixos.org /nix/store/3qsyp7mplpmhm14wwnkg8w03bnw75cmn-hello-2.10 --json
<clever> /nix/store/3qsyp7mplpmhm14wwnkg8w03bnw75cmn-hello-2.10 28352728
<clever> Orbstheorem: like this?
<clever> $ nix path-info --store https://cache.nixos.org /nix/store/3qsyp7mplpmhm14wwnkg8w03bnw75cmn-hello-2.10 --closure-size
<clever> > "${hello}"
<clever> Orbstheorem: *looks*
<clever> matthuszagh: yeah, not much can be done about that right now
<clever> matthuszagh: if all inputs to a package are unchanged, it will reuse the entire build product
<clever> matthuszagh: nix basically does the same thing as ccache, but at the package level
<clever> matthuszagh: i dont see any feasible way to make it work during nix based builds, but nix-shell could still work
<clever> matthuszagh: you still wont have write access to the directory, and turning off the sandbox has a lot of purity problems
<clever> matthuszagh: the nix sandbox wont allow access to /var/cache/ccache/
<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> dminuoso: at least when using bash, you can run something like this: https://github.com/input-output-hk/iohk-ops/blob/test-macs/shell.nix#L36-L45
<clever> dminuoso: one min
<clever> pie_: security in situations where you dont want to give root shells
<clever> pie_: dont know
<clever> then install it?
<clever> > gnome3.eog.meta.homepage
<clever> > gnome3.eog.meta.description
<clever> iqubic: run `eog` on the jpeg
<clever> iqubic: did you try ctrl+p in the image viewer?
<clever> iqubic: what type of document? the editor/viewer for that document usually has a print button
<clever> daurnimator: it usually only happens once
<clever> daurnimator: that happens sometimes, usually when ran as root, try again
<clever> daurnimator: gcc and make are in the stdenv by default, just `nix-shell -p` is enough to get both

2019-07-24

<clever> andrewrk: at one point, the rogue came was also on one of the TTY's, so you had something to do while it installed
<clever> which i consider a worse setup
<clever> andrewrk: i think raid will hide the nvme device entirely, and force you to instead configure a raid array and use a special raid driver
<clever> adamt: in my case, i migrated, and didnt update the cfg, so it couldnt find its own root disk
<clever> adamt: `nixos-generate-config` may do it for you
<clever> but you may need `boot.initrd.availableKernelModules = [ "nvme" ];` for it to boot after installing
<clever> i would expect it to auto-load when booting the ISO
<clever> andrewrk: nvme needs a special driver, `modprobe nvme`, and boot.initrd.availableKernelModules = [ "nvme" ];
<clever> elvishjerricco: ah, https://oshogbo.vexillium.org/blog/46/ seems to explain it well
<clever> andrewrk: what does lsblk report?
<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> ajs124: ahh, yeah it is
<clever> ajs124: grub only installs to that if you set https://nixos.org/nixos/options.html#asremovable
<clever> elvishjerricco: it could be an old legacy install he forgot about, or a second ESP
<clever> pie_: you didnt boot via efi, so you cant tell the bios to use the right file on the right ESP
<clever> pie_: thats half your problem then!
<clever> # blkid /dev/nvme0n1p1
<clever> /dev/nvme0n1p1: UUID="7DBC-2698" TYPE="vfat" PARTUUID="27c99b08-455d-4dfe-a44f-6150cbc09ef8"
<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
<clever> pie_: this is where it runs grub-install
<clever> pie_: i'm going to lean towards it being grub
<clever> pie_: brb
<clever> #grub !
<clever> maybe go to the grub irc channel?
<clever> blame grub for being weird
<clever> and then the problem is in linux's hands
<clever> pie_: if you put the ESP at /boot, then the linux kernel+initrd are also on the ESP
<clever> pie_: and i think your entire problem is grub's ability to deal with the crypto
<clever> pie_: why not just mount the ESP to /boot/ ?
<clever> pie_: and there is an ESP mounted to /efi ?
<clever> pie_: shouldnt that be $( ?