2021-04-26

<clever> jackdk: word-wrap sometimes breaks the lines up, and then you backspace to fix it, and delete one too many chars
<clever> so nix believes the signature is invalid, because it doesnt match your pubkey list
<clever> an a turned into an A
<clever> jackdk: you have a typo in the public key
<clever> jackdk: does `nix show-config | grep trusted-public-keys` list the iohk key?
<clever> jackdk: for which path?
<clever> jackdk: what is the exact error msg?
<clever> jackdk: if something is a validpath (in your /nix/store), it may have a copy of the sig locally
<clever> pie_: the overlay can be mounted at any time before its being used
<clever> jackdk: it might also be in /nix/var/nix/db/db.sqlite
<clever> then check dmesg
<clever> pie_: also, you can do that without overlays, `echo 1 > /proc/sys/vm/block_dump`
<clever> pie_: stage-1 would be easy
<clever> only the evil builtins.exec can do that
<clever> ,exec
<clever> no way to disable that
<clever> once the build is done, nix will purify the directory, removing all timestamps, ownership, and the read/write bits
<clever> nix wont mess with the contents of the tar, so yes

2021-04-25

<clever> catern: files downloaded with curl are fixed-output, and nix enforces that they have the expected hash
<clever> thats an impurity though
<clever> now what?
<clever> catern: nix-channel uses nix-env -i to install nixpkgs
<clever> catern: that shell needs a copy of nixpkgs
<clever> catern: that shell script needs a copy of a shell
<clever> bqv: pushed
<clever> bqv: it was this, but names have since been assigned
<clever> std::pair<string, string> decoded = decodeContext(i);
<clever> bqv: ah, yeah
<clever> oh wait, i think i see the issue
<clever> bqv: i think i.first will be in the form of !/nix/store/foo.drv!dev and then ctxS is the .drv and outputName "dev"
<clever> *looks*
<clever> bqv: rebased
<clever> bqv: conflicts!, *looks*
<clever> immae: the efi var says to load file partition (by gpt part uuid), and then load that path within the fs
<clever> [root@system76:~]# blkid /dev/nvme0n1p1
<clever> /dev/nvme0n1p1: UUID="7DBC-2698" BLOCK_SIZE="512" 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> [root@system76:~]# efibootmgr -v
<clever> immae: the files that exist dont really matter, if the firmware is working correctly

2021-04-22

<clever> then you dont have to escape every / in $out
<clever> radvendii: of note, sed lets you use different chars, so you can s@$out@$out/bin@

2021-04-18

<clever> xAr86: the key is always a string
<clever> i think you just drop the types.str
<clever> even if it was, the parens are forcing it to be evaluated the other way around
<clever> but types.str isnt a function
<clever> xAr86: your running types.str on the return-value of types.oneOf

2021-04-16

<clever> then the installer never uses sudo
<clever> if /nix is pre-made, and you own it already
<clever> evils: what part needs sudo?
<clever> i'm not sure what happens if you give non-root write, and run nix-daemon as that user...
<clever> if you lack write access, it will contact nix-daemon, which should have write
<clever> evils: if you have write access to /nix/store, you dont need root
<clever> phnom: --arg takes a value, and a nix expr, the double quotes mean your expr is a plain string literal
<clever> and its not compatible with how the nixos bootloader is working
<clever> its already a hybrid image, that can boot on either cd or usb
<clever> jumper149: ive seen people using tools to convert a bootable cd into a bootable usb before (unetbootin), and it breaks the nixos image
<clever> jumper149: how was the iso file written to a usb stick?
<clever> lunik1: a combination of find, sublist, and concatLists

2021-04-14

<clever> sshow: it can also auto-repair anything it finds as it scans
<clever> nix-store --verify [--check-contents] [--repair]
<clever> sshow: other things could also have been corrupted
<clever> sshow: it will hash the contents of every single file in /nix/store
<clever> sshow: by default, ext4 is only using the journal to protect metadata, so the FS wont catastrophically fail, but data can be lost
<clever> lukegb: exactly!
<clever> lukegb: that will probably do it
<clever> sshow: ext4 loves to silently truncate files that where not fully written
<clever> sshow: did you have an improper shutdown recently?
<clever> oh, empty!!
<clever> sshow: and `head -n1` on that perl?
<clever> sshow: what does `head -n1 /nix/store/9la7w2d567cvi71pgiy4ydzhg1lrbhss-nixos-system-prodigy-21.05pre282432.311ceed827f/bin/switch-to-configuration` report?
<clever> veleiro: all channels on root are global
<clever> sshow: what is the full path to the switch-to-configuration? what cpu arch are you on?
<clever> so the thing your linking cant be deleted until your product is first deleted
<clever> ambroisie: any symlinks in $out create extra runtime dependencies for your build product

2021-04-13

<clever> exfalso: unicode, it doesnt render on mine
<clever> sterni: my irc client only pings if my name is at the very start of a msg, like yours is here
<clever> feathers: run `nix repl` then `:?` and youll see the full help
<clever> > :p map ({email,...}: email) wireguard.meta.maintainers
<clever> > :p wireguard.meta.maintainers

2021-04-11

<clever> Kyndig: that area of impure.nix
<clever> 2021-04-11 14:54:12 < samueldr> though this is the implementation where it's being used https://github.com/NixOS/nixpkgs/blob/d600f006643e074c2ef1d72e462e218b647a096c/pkgs/top-level/impure.nix#L25-L35
<clever> Kyndig: and <nixpkgs> is what is looking at NIXPKGS_CONFIG
<clever> Kyndig: nix-env is just doing `(import <nixpkgs> {}).fzy` basically
<clever> nixops, a cluster management system, build around nixos, nixpkgs, and nix!
<clever> nixos, a distro build arround nixpkgs and nix
<clever> but now configuration.nix is root-only
<clever> Kyndig: $NIXPKGS_CONFIG is an override for config.nix, and your file is setup so all users inherit the nixpkgs.config from configuration.nix
<clever> Kyndig: and theres your problem
<clever> Kyndig: and the contents of that file?
<clever> Kyndig: ls -lh $NIXPKGS_CONFIG ?
<clever> too many k names in here, Kyndig, Kinnison, and also Kritnich!
<clever> oops, that question was for Kyndig
<clever> Kinnison: what are the contents of your config.nix?
<clever> and the overlay, then changes what pkgs.nixos-rebuild refers to
<clever> Kinnison: we are relying on the .override here, to make nixos-rebuild use a flake capable nix
<clever> Kinnison: this will cause tools/tools.nix to use unstable instead
<clever> nixpkgs.overlays = [ (self: super: { nixos-rebuild = unstable.nixos-rebuild; }) ];
<clever> but you need the override as well, or use an overlay
<clever> Kinnison: the fix is still present in that version
<clever> Kinnison: which unstable did that unstable come from?
<clever> that will apply version 3 back to the current system
<clever> Kinnison: /nix/var/nix/profiles/system-3-link/bin/switch-to-configuration switch
<clever> what does this output?
<clever> Kinnison: you can also rollback a little more manually, ls -lh /nix/var/nix/profiles/system
<clever> nixos-rebuild --rollback switch
<clever> and maybe throw in a switch?
<clever> ah, --rollback
<clever> Kinnison: nixos-rebuild rollback
<clever> ,unstable Kinnison
<clever> Kinnison: you can also use an overlay to change just pkgs.nixos-rebuild
<clever> Kinnison: nixos-unstable is far more stable, and you have an undo button in the form of rollbacks
<clever> Kinnison: the fix was applied 24 days ago, so you could just run nixos-unstable
<clever> nixos-rebuild = callPackage ../os-specific/linux/nixos-rebuild { };
<clever> > builtins.unsafeGetAttrPos "nixos-rebuild" pkgs
<clever> > builtins.unsafeGetAttrPosition "nixos-rebuild" pkgs
<clever> oh, wait, somebody moved it!
<clever> nixos-rebuild = pkgs.nixos-rebuild.override { nix = config.nix.package.out; };
<clever> Kinnison: one of the first things i did with nixos, was made an SD card that booted on both x86 and an rpi, with a single rootfs!
<clever> Kinnison: what are you trying to do?
<clever> Kinnison: nixos-rebuild is a special package and isnt in the normal package list
<clever> Kinnison: last time i netbooted an rpi, i used https://github.com/cleverca22/nixos-configs/blob/master/iscsi-boot.nix without uboot
<clever> Kinnison: oh, an rpi...

2021-04-08

<clever> kenran: add preConfigure = "set -x"; to the derivation, there is probably a hook to move things
<clever> kenran: $lib is for libraries loaded at runtime, $dev is for headers and static libraries only used at build-time, $bin or $out for the binaries you may not need
<clever> > pkgsStatic.hello
<clever> remexre: pkgsStatic
<clever> pie_: anything with networkd in the name
<clever> pie_: check /etc/systemd/system/ ?
<clever> pie_: does it have a systemd service? what does the .service file say?
<clever> yep
<clever> eacameron: you can also just run: phases="unpackPhase patchPhase configurePhase buildPhase" genericBuild
<clever> eacameron: your not doing that switching, so your always getting the bash function
<clever> eacameron: genericBuild will dynamically switch between evaluating $unpackPhase (an env var containing shell code) and running unpackPhase (a bash function by the same name)
<clever> but stdenvNoCC wont
<clever> the default stdenv has that
<clever> $NIX_CC only happens if gcc was in your buildInputs
<clever> run `echo $NIX_CC` and `ls -l $NIX_CC/nix-support/dynamic-linker` and `cat $NIX_CC/nix-support/dynamic-linker`
<clever> then you can omit the --set-rpath
<clever> eacameron: sets the rpath, so ldd can find libs
<clever> patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" --set-rpath ....
<clever> eacameron: you have to tell it what to patch
<clever> $ patchelf --help
<clever> syntax: patchelf [--set-interpreter FILENAME]
<clever> eacameron: patchelf
<clever> tpw_rules: if the interpreter on an ELF is missing, then executing it claims not found
<clever> eacameron: what about the interpreter?

2021-04-07

<clever> then it wont auto-start
<clever> eggplant: you can also mkForce the wantedBy, so its not wanted by multi-user.target
<clever> thats what i would expect
<clever> srhb: what does `which youtube-dl` report inside your `nix shell` ?
<clever> srhb: one thing that often trips people up, `nix-shell -p youtube-dl` puts youtube-dl into $PATH, while `nix-shell '<nixpkgs>' -A youtube-dl`, gives you a shell suitable for BUILDING youtube-dl
<clever> __monty__: the default value only gets set when genericBuild is stepping thru phases for you
<clever> hyper_ch: because wireguard is now part of linux itself, and you dont need extraModulePackages anymore!
<clever> result/lib/modules/5.10.18/kernel/drivers/net/wireguard/wireguard.ko.xz
<clever> [clever@amd-nixos:~/apps/rpi/nixpkgs-test]$ find result/ | grep wiregu
<clever> [clever@amd-nixos:~/apps/rpi/nixpkgs-test]$ nix-build -A linux_5_10
<clever> hyper_ch: TLDR, linuxPackages_5_10 was already "broken", and the default moved ahead when you updated
<clever> - linuxPackages = linuxPackages_5_4;
<clever> + linuxPackages = linuxPackages_5_10;
<clever> linuxPackages: 5.4 -> 5.10
<clever> 285301cd1f3ec4521be8a9b816a99a095c34715c is the first bad commit
<clever> [clever@amd-nixos:~/apps/rpi/nixpkgs-test]$ nix-instantiate --eval -A 'linuxPackages.wireguard'
<clever> Bisecting: 3629 revisions left to test after this (roughly 12 steps)
<clever> hyper_ch: because that attr is null, so you gave it [null]
<clever> > linuxPackages.wireguard
<clever> those 2 are identical
<clever> hyper_ch: did you set it in any of your configs?
<clever> yeah
<clever> or swap the conditions!, didnt think of that
<clever> but now your checking the thing twice
<clever> the only way to simplify it more is `if cfg.defaultUser == null then`
<clever> so if defaultUser IS null, then it save_file will be ""
<clever> `if condition then a else b`, return either a or b, based on the condition
<clever> matthewcroughan: mk_save is a boolean, invert its value
<clever> so changing the var wont cause a rebuild
<clever> matthewcroughan: it lets you do firefox-bin.ffmpegSupport to access the var, but the var itself doesnt impact the hashing of $out
<clever> > firefox-bin.unwrapped.meta.position
<clever> > firefox-bin.meta.position
<clever> matthewcroughan: firefox-bin is a patchelf'd copy of the official release, while firefox is built by nix itself
<clever> matthewcroughan: i'm confused about how nixos-20.09 is older, and neither seems to be in the history of the other, i think its diff branches
<clever> matthewcroughan: its 4 hours before midnight 1970, because of timezones
<clever> Modify: 1969-12-31 20:00:01.000000000 -0400
<clever> matthewcroughan: everybody west of UK gets that
<clever> matthewcroughan: when building from b02b2aa59e8, i get the new version
<clever> lrwxrwxrwx 1 root root 16 Dec 31 1969 result/lib/libwebp.so -> libwebp.so.7.1.0
<clever> when on the tip of nixos-20.09
<clever> lrwxrwxrwx 1 root root 16 Dec 31 1969 result/lib/libwebp.so -> libwebp.so.7.0.5
<clever> [clever@amd-nixos:~/apps/rpi/nixpkgs-test]$ nix-build -A libwebp && ls -lh result/lib/libwebp.so

2021-04-06

<clever> cwpubDJ[m]: also, did you nix-channel --update after adding it?
<clever> cwpubDJ[m]: try nix-env -iA unstable.hello ?
<clever> channel:... says to fetch a new copy right now, while <unstable> says to search $NIX_PATH for a local copy
<clever> ah, you just want <unstable>
<clever> ,-A
<clever> cwpubDJ[m]: -i will search the .name attribute of every package, and install the "best match", while -iA gives an attrpath saying exactly which one to use

2021-04-05

<clever> ihsan: to get differences, you need to instead use git, which then requires cloning the entire history
<clever> it was appending to the var at build time
<clever> yep, because the package never set configureFlags
<clever> but you can also use configureFlags (the nix var) to have an initial config, that the array will start out with
<clever> cinimod: preConfigure is a chunk of bash script, that gets ran between the patch phase and configure phase
<clever> cinimod: its also blank to begin with, so there is nothing to append to
<clever> > R.configureFlags
<clever> > builtins.attrNames pkgs.R
<clever> cinimod: it may just be called configureFlags
<clever> cinimod: rec is also un-needed
<clever> cinimod: oldAttrs*
<clever> cinimod: configureFlagsArray = old.configureFlagsArray ++ [ "--without-x" ];
<clever> cinimod: thats what the `old` in `.overrideAttrs (old: {` is for
<clever> tobiasBora: so, their attempt to fix the same problem nix solves, is making nix's job harder
<clever> tobiasBora: gtk is using $out/include/gtk, in an attempt to avoid conflicts when you install 2 gtk versions
<clever> tobiasBora: the stdenv will add the $out/include of everything from buildInputs to the cflags thing, so it magically works

2021-04-04

<clever> _virkony_: ive not used home-manager much, so i'm not sure whats better for that
<clever> _virkony_: if you use a channel name starting with nixpkgs, you risk breaking the machine
<clever> _virkony_: when using nixos, you must always use a channel name starting with nixos
<clever> its probably in the nixpkgs manual, if its documented
<clever> thats the raw clang, which doesnt respect NIX_CFLAGS_COMPILE
<clever> > clang.cc
<clever> > clang.unwrapped
<clever> you have to go out of your way to break things
<clever> > clang
<clever> tobiasBora: the clang in $PATH is still a cc-wrapper
<clever> some makefiles will set CFLAGS rather then append
<clever> $CC is pointing to a copy of cc-wrapper, which will inject $NIX_CFLAGS_COMPILE into the args, so nix doesnt rely on CFLAGS surviving random makefiles
<clever> $ file $(which $CC)
<clever> /nix/store/ca37d3qrydh0wpw40kswsx30j8dyzxh2-gcc-wrapper-10.2.0/bin/gcc: a /nix/store/f7jzmxq9bpbxsg69cszx56mw14n115n5-bash-4.4-p23/bin/bash script, ASCII text executable
<clever> its all handled by cc-wrapper
<clever> yeah
<clever> gtk breaks the rules, by trying to solve the same problem nix is already solving
<clever> and how the sane packages are found
<clever> this env var is the same way buildInputs sneak into the search path
<clever> gcc will invisibly add that to its args
<clever> prepend to this var in the right phase
<clever> NIX_CFLAGS_COMPILE="$(pkg-config --cflags gtk+-3.0) $NIX_CFLAGS_COMPILE"
<clever> tobiasBora: pkg-config --cflags gtk+-3.0
<clever> tobiasBora: pkgconfig is the solution to that

2021-04-03

<clever> > builtins.unsafeGetAttrPos "autoPatchelfHook" pkgs
<clever> > builtins.unsafeGetAttrPos pkgs "autoPatchelfHook"
<clever> > autoPatchelfHook.meta.position
<clever> > autoPatchelfHook

2021-04-02

<clever> it will just directly access the store
<clever> Drakeson: if a nix binary has write access to /nix/store, it wont need nix-daemon running
<clever> i think so
<clever> a use-case for the canadian cross, is to build something like an arduino IDE, that runs on the rpi, but use x86 hw to build it
<clever> so now you have 3 platforms involved!
<clever> dgpratt: the most complex case (which i dont think nix fully supports) is a canadian cross, where you could for example be building a compiler on x86, but the compiler ultimately runs on arm, and the compiler targets AVR
<clever> which doesnt make sense when building nix from inside nix, that has to happen later on
<clever> Drakeson: it was an option, to stop nix from initializing db.sqlite upon `make install`
<clever> Antkibo: thats done via the command-not-found hook
<clever> Drakeson: its just flags to ./configure
<clever> you then copy that new build to /home/example/nix/store on the target machine, and it will keep working
<clever> from a machine with nix already working in /nix/, you can create a new build of nix that lands at /home/clever/rootfs/home/example/nix/store
<clever> and thats exactly the kind of situation doit.sh was made for
<clever> nix.override { storeDir = "/home/'$X'/nix/store"; stateDir = "/home/'$X'/nix/var"; confDir = "/home/'$X'/etc"; }
<clever> Drakeson: thats what the overrides do
<clever> then if you copy that "chroot-ish" dir, to the correct location on a new box, it will keep working
<clever> the override then makes the 1st set of vars permanent within the new build of nix
<clever> NIX_REMOTE will then prefix a dir to all of them, but the code expects a chroot into that dir later
<clever> some of those env vars mutate how the current nix behaves
<clever> charly79: /usr/bin/env doesnt exist at build-time, run patchShebangs on the perl script
<clever> also depends on what style of recursion the project is doing
<clever> but nix likes to clean the intermediates up, so you cant
<clever> and it will repeat that failure, and fail instantly
<clever> at least with interactive builds, you can re-run `make -j1` after the failure
<clever> exactly
<clever> if its building with -j, it may take longer to fail
<clever> Tv`: ah yeah, that could work, ../static
<clever> Tv`: /etc/static allows you to atomicly update every symlink in /etc at once

2021-04-01

<clever> vandenoever: and the gui editor for ui stuff
<clever> vandenoever: qmake && make still works in CLI, and has far less fussing, you just loose the IDE
<clever> things may have changed since then
<clever> and those files get cleaned up when nix-shell exits
<clever> it relies on files in /tmp made by the preConfigure hook
<clever> even worse when i last tried it
<clever> and it breaks every time you re-open nix-shell
<clever> i did find qtcreator very painful to make work in nixos

2021-03-30

<clever> matthewcroughan: never heard of it before, so i cant comment on it
<clever> find another common example of that, and look at how nix solved it, it happens a lot in python
<clever> nix doesnt allow that, ever
<clever> matthewcroughan: you formed a circle
<clever> matthewcroughan: the problem is that you made macro depend on material, which depends on macro
<clever> matthewcroughan: it can, pSelf
<clever> matthewcroughan: you almost always want to use self, except when your overriding an attr with itself, then you need super to break the recursion
<clever> matthewcroughan: super.pkgs might be doing the same as self
<clever> matthewcroughan: super.pkgs might be confusing things more
<clever> matthewcroughan: super.pkgs is also pointless, super and self are both copies of pkgs
<clever> matthewcroughan: so line 30 wont be taken into account