2018-02-15

<clever> gchristensen: i think i could de-bash that though, ....
<clever> gchristensen: lol, neat
<clever> once_upon_a_nixo: yep
<clever> this re-compiles htop with debug symbols, then runs that variant
<clever> nix-shell -p '(enableDebugging htop)' --run htop
<clever> and nix also makes it trivial to do other fun things
<clever> yep
<clever> once_upon_a_nixo: `nix-shell -p firefox` should give you a shell where firefox can be ran, without actually installing firefox into any profile
<clever> once_upon_a_nixo: you can also use nix-shell to load things up without adding them to your profile
<clever> once_upon_a_nixo: yeah, you can do that
<clever> once_upon_a_nixo: so different versions can co-exist trivially
<clever> once_upon_a_nixo: libraries never go into your profile, and all applications refer to libraries by absolute path
<clever> once_upon_a_nixo: what do you think would break if you dont isolate things?
<clever> once_upon_a_nixo: yeah
<clever> once_upon_a_nixo: you patch both, so they can co-exist in the same profile
<clever> once_upon_a_nixo: in general, you dont make a profile for a game, and a profile for applications
<clever> once_upon_a_nixo: thats part of why my nix store is 61gig in size, lol
<clever> once_upon_a_nixo: and locally, as an example of what GC can do, i have 7 copies of firefox in my nix store, for versions 51, 55, 53, 56, 55, 57, and 57
<clever> once_upon_a_nixo: cache.nixos.org doesnt have any garbage collection, so anything that has been built by hydra.nixos.org, will persist, forever
<clever> which would have less problems
<clever> once_upon_a_nixo: or you could change the ~/.nix-profile symlink to swap the profile out on the entire user
<clever> once_upon_a_nixo: you could manually create a second profile, but you will have to mess with $PATH to switch between them on a per-shell, and some stuff may not like it
<clever> once_upon_a_nixo: but if 2 users attempt to install the same package, they will automatically share the files, which is also why everything must be immutable
<clever> once_upon_a_nixo: by default, every user has his own environment
<clever> jmc: i dont think the internals of callPackage are documented anywhere
<clever> once_upon_a_nixo: if one user installs it with nix-env, then the executables are basially private, and nobody else gets them automatically
<clever> once_upon_a_nixo: if you install it system-wide with configuration.nix and systemPackages, the executable will be available to everybody, but the translations are per-user, so it will probably have to re-download
<clever> i think they wanted to cache the translations between users, but that requires the installation directory to be world-writable
<clever> once_upon_a_nixo: the patch redirects it into going into a directory somewhere under $HOME, which the application already used for other writable data
<clever> jmc: line 115 deals with `callPackage lambda` vs `callPackage ./default.nix`, and then i believe line 75 deals with the default.nix containing either a lambda, or something else
<clever> once_upon_a_nixo: as an example, multimc tries to save some data into its installation directory at runtime, but thats immutable, so this was required: https://github.com/NixOS/nixpkgs/blob/17020526a78b0814fc813900cabd7043d7b419e4/pkgs/games/multimc/multimc.patch
<clever> once_upon_a_nixo: yeah, some programs have nix specific patches, which are usually kept in the nixpkgs repo
<clever> once_upon_a_nixo: the nixos ISO's include a gpt partition table and can just be dd'd directly to the root of a usb drive

2018-02-14

<clever> so id rather be prepared for when that happens, be ready to apply a rollback if needed
<clever> i'm also on nixos-unstable, and things may break
<clever> yeah
<clever> so i know when its updating
<clever> i generally try to avoid `nixos-rebuild --upgrade`, and instead always use nix-channel to control it
<clever> ivanivan: it has to be undone with `nix-channel --rollback`
<clever> ivanivan: if --upgrade is present, it will first run `nix-channel --update`, and --dry-run doesnt undo that
<clever> ivanivan: the problem is that --upgrade doesnt exactly obey --dry-run
<clever> then it will run at noon
<clever> you can also just system.autoUpgrade.dates = "12:00";
<clever> ivanivan: it runs at 4:40 am by default
<clever> ivanivan: it says it will run it in 7 hours, perhaps youve just been turning the machine off before it can run?
<clever> ivanivan: what does `systemctl list-timers` say?
<clever> ivanivan: have you done a nixos-rebuild to apply that change?
<clever> ivanivan: what settings did you set on the service?
<clever> ivanivan: correction, `journalctl -f -u nixos-upgrade.service`, oops
<clever> ivanivan: it configures a systemd timer called autoUpgrade, so do `journalctl -f -u autoUpgrade.service`

2018-02-13

<clever> yeah, if its set to 0, it will run nproc to bump it up to the right number
<clever> around 4 or 5 should do
<clever> --option build-cores 8
<clever> infinisil: that does derivation parallism, not make parallism
<clever> troydm: https://nixos.org/nixos/options.html#nix.buildcores
<clever> so the compiler will conditionally apply things at compile time, based on the version of the kernel source
<clever> troydm: and the patches themselves, add #if statements, that check the versions
<clever> troydm: i think it just applied all of them, always
<clever> troydm: i believe all of those are applied
<clever> yep
<clever> infinisil: look up -q in the grep man page
<clever> lejonet: then edit the new one, and use `diff -ru` to make a patch
<clever> lejonet: nix-shell '<nixpkgs>' -A hello, then run unpackPhase, and then duplicate the entire source tree with `cp -r`, so you have a new and -orig copy
<clever> lejonet: oh, do you already know what you want to edit?, it might be simpler to use another trick i use
<clever> Myrl-saki: lol, the man page for bash uses both read-only and readonly to refer to read only variables
<clever> lejonet: heh, yeah, nix cant deal with that, all nix does is slap on a ton of -I's
<clever> Myrl-saki: have you done `which clang` and then just read the bash script it points to?
<clever> romildo: if your going to be using a lot of gnome3 packages, and/or your thing is part of gnome3, then using gnome3.callPackage is usually better
<clever> romildo: you can only do { eog, evince }: if your file is loaded via something like gnome3.callPackage
<clever> i suspect its generating a list with the state of every single page in the entire 64bit address space
<clever> and the task directory contains symlinks for every thread in the process
<clever> infinisil: thats a binary file, a bitmap of pages and some state
<clever> what files does it have open?
<clever> infinisil: then do ls -l /proc/PID/fd/
<clever> infinisil: while its hung, find the pid of the process that is hung
<clever> infinisil: there is also a root symlink under every one of those, that points to /
<clever> infinisil: and all of the numbered "directories" exist for every pid, and will vary
<clever> infinisil: also, /proc/self is a symlink to the pid that is trying to read the symlink
<clever> and that persists between opens of the handle
<clever> i think /proc/kmsg has its own read-pointer within the dmesg loop
<clever> so you can insert helpfull markers into the real dmesg logs
<clever> and if you write to /proc/kmsg, it appears in the main dmesg buffer
<clever> infinisil: so next time you read it, you only get new messages
<clever> infinisil: for example, /proc/kmsg removes bytes from a buffer as you read it
<clever> infinisil: several of the files in /proc are magic and do fun things when read
<clever> infinisil: same
<clever> so it didnt finish going into suspend
<clever> it just freezes solid, while leaving the keyboard and lcd backlights on
<clever> srhb: and my system also has a glitch, where it sometimes locks up while going into suspend
<clever> srhb: would need to actually suspend to confirm if it has any impact
<clever> srhb: writing to the wakeup "file" in the right /sys path doesnt have an effect on the /proc/acpi/wakeup output, but it might be several layers of filtering
<clever> lejonet: instead, try nix-shell -p linuxHeaders
<clever> lejonet: second, it never puts them in /usr/include, it sets up some env variables so gcc will just find them
<clever> lejonet: first, that gives you a shell suitable for building the linuxHeaders, not using them
<clever> lejonet: have you tried adding linuxHeaders to the buildInputs?
<clever> infinisil: just make sure to test it with a full reboot before you let garbage collection eat your rollbacks
<clever> infinisil: and that leads to nixos being unable to find systemd, lol
<clever> infinisil: the failure to reach the network, causes stage-2 to abort in a weird place, and then $PATH isnt configured properly
<clever> infinisil: and then months after putting it in, he rebooted
<clever> infinisil: a couple months ago, i was helping somebody that tried to do network in his activation script, and it intially worked, via nixos-rebuild switch
<clever> infinisil: its far too easy to brick the entire machine with activation scripts
<clever> infinisil: also, id use a systemd one-shot service, rather then an activation script
<clever> [root@system76:~]# cat /proc/acpi/wakeup | grep -i lid | grep enabled && echo LID0 > /proc/acpi/wakeup
<clever> so you need to grep, and then conditionally echo
<clever> it will toggle every time you `nixos-rebuild switch`
<clever> so you cant just jam it into an activation script
<clever> infinisil: and that echo appears to toggle the option!
<clever> there should be a way to disable that
<clever> infinisil: i can see that LID0 is an enabled wakeup source on my system
<clever> LID0 S3*enabled platform:PNP0C0D:00
<clever> [root@system76:~]# cat /proc/acpi/wakeup | grep -i lid
<clever> infinisil: one sec
<clever> infinisil: then the voice chat went silent, lol
<clever> infinisil: i fixed discovered that, when i was trying to get behind a desktop, while using a voice chat on the laptop, and the lcd panel was in the way, so i just closed it
<clever> infinisil: oh, that reminds me, my laptop goes into standby if i close the lid, and wakes up when i open the lid
<clever> Lisanna: so if you hard-code a storepath into your derivation, its not an input, so nix doesnt know to look for it
<clever> Lisanna: nix only checks for your inputs
<clever> i just always work in 1024, and always call it mb or MB
<clever> i can never keep those 2 straight, lol
<clever> infinisil: but what if i want 1024 based units? :D
<clever> ah
<clever> infinisil: but what if i want to accept both mb and gig?, and just convert it all down to bytes
<clever> infinisil: i dont think even haskell can do that, enless you just do `Gig 40`
<clever> infinisil: it would need to support 40G as a valid number
<clever> infinisil: heh, but how do you deal with mb and gig both being int based?
<clever> srhb: i'm not sure if the unpacked kernel would even fit inside 40mb
<clever> srhb: i forgot, that my script works in mb
<clever> srhb: when i was setting up my new laptop with 32gig of ram, i configured my justdoit.nix script to make a 40gig swap partition, just for hibernation
<clever> ive also heard that the mouse in apple laptops is partially usb based
<clever> one of my older laptops has a USB smart-card reader, directly under the pcmcia slot, but it never had working linux drivers
<clever> mpickering: it will download the latest tar over http, unpack it within /nix/store/, and your set of active channels is managed with nix-env, the same as your profile
<clever> mpickering: nix-channel manages unpacked tarballs in /nix/store/
<clever> rycee: thats why i dont see him having spoken recently, and cant tab-complete him
<clever> rycee: aha, he last spoke 3-ish hours ago, and ping timeout'd about an hour ago
<clever> rycee: what has he said most recently?, that should persist
<clever> rycee: which then heavily confuses everybody on irc, because irc doesnt show the matrix names
<clever> rycee: if 2 matrix users are in the same irc channel, it can show their matrix username, which differs from the irc nickname
<clever> from my view point, your talking to somebody that doesnt exist :P
<clever> rycee: matrix is doing weird things again, i dont see a mrkgnao on irc
<clever> mpickering: and if fetchTarball complains about signatures, its because your nix-daemon is 1.11
<clever> mpickering: there is also https://nixos.wiki/wiki/How_to_fetch_Nixpkgs_with_an_empty_NIX_PATH but ive just now identified a bug with it, the sha256 is only valid on one version of nix
<clever> not that nix allows such mixing, lol
<clever> where 1 is incremented for massive changes, 2 more for abi level changes, and 3 for minor things where you can mix the binaries between versions
<clever> Dezgeg: i generally think of 1.2.3 as major version 1, minor version 2, patch version 3
<clever> romildo: might builtins.compareVersions also handle what you want?
<clever> eacameron: thats the context from the convo i saw about zsh not working right
<clever> bindkey "\e[F" end-of-line
<clever> bindkey "\e[H" beginning-of-line
<clever> eacameron: it sounds like the terminal emulator is generating the wrong codes for the keys, and that has broken a wide range of things
<clever> eacameron: i recently heard about zsh having the same problem, and it had to be re-bound in .zshrc
<clever> how the heck did they manage to break all 3 versions so uniformly?
<clever> hodapp: this happens with a patchelf'd KSP, the unpatched KSP under the steam sandbox, and even the bloody windows KSP under wine!!!
<clever> hodapp: mods under KSP just plain cant render text, and it computes the witch of any string as 0 pixels, causing all buttons to shrink
<clever> hodapp: that reminds me of fun problems ive had with KSP
<clever> and if that path exists, builtins.fetchurl { url=; sha256=; } doesnt fail!
<clever> but import <nix/fetchurl.nix> under 1.11 can pass, and produce the exact same storepath
<clever> LnL: ok, so builtins.fetchurl { url=; sha256=; } fails with error: imported archive of ‘/nix/store/jcmcikcs1f69aj6d8415blcjpdlz6f4d-5c09cdc187b014143302551e62d4973b5bf52814.tar.gz’ lacks a signature
<clever> the only real difference between fetchurl and fetchTarball, is the boolean unpack
<clever> LnL, gchristensen: either of you remember whats up with this one, when using builtins.fetchTarball?
<clever> ah, this one again, been a while since ive seen that
<clever> error: imported archive of ‘/nix/store/jcmcikcs1f69aj6d8415blcjpdlz6f4d-5c09cdc187b014143302551e62d4973b5bf52814.tar.gz’ lacks a signature
<clever> but that also doesnt match the error i'm getting
<clever> LnL: the source implies that it allows fixed-output mode in pure mode
<clever> chreekat: which then calls the real mkDerivation, after mangling your arguments, and inserting the right ghc
<clever> chreekat: the problem, is that the haskell mkDerivation passes everything thru this function: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/generic-builder.nix#L13-L66
<clever> chreekat: (mkDerivation { ... }).overrideAttrs (drv: { dontPatchELF = true; })
<clever> chreekat: the entire mkDerivation call returns something that is both an attrset, and a derivation, and you can index into the .overrideAttrs attribute to override things
<clever> LnL: the builtins.storePath is rejecting paths that you just pulled out of nowhere, because you didnt purely define how they got made
<clever> LnL: i dont think that counts when using hydra-eval-jobs, which sets restricted mode
<clever> chreekat: use .overrideAttrs to insert it after the haskell wrapper has finished its job
<clever> https://github.com/NixOS/nix/commit/920f5fd4dda16374a6c25ae91c5f17ed749c067c is why <nix/config.nix> previously worked, it was just blindly allowing any valid storepath, rather then ones you just produced via IFD
<clever> LnL: builtins.fetchTarball with a sha256 fails hard, because its not allowed in restricted mode
<clever> LnL: <nix/config.nix> fails hard, because nix and its closure are dis-allowed as of https://github.com/NixOS/nix/commit/43f8ef73c6aeb23aee40d485556004d6262d4e3b ish
<clever> its a fixed-output fetch, but restricted mode wont allow it
<clever> and it still fails, lol
<clever> error: access to URI 'https://github.com/NixOS/nixpkgs/archive/5c09cdc187b014143302551e62d4973b5bf52814.tar.gz' is forbidden in restricted mode
<clever> LnL: and it keeps working for the final 1.12 as well
<clever> LnL: ah, nice
<clever> so there is no way to hard-code around compareVersions being dumb
<clever> and its the host nix 1.11 that has to eval the expressions to provide nixUnstable
<clever> and that led to my confusion
<clever> gchristensen: and if i just comment out the check, the 1.11 nix-shell fails, before the 1.12pre nix is ran
<clever> gchristensen: builtins.compareVersions says that 1.12pre5873_b76e282d is older then "1.12", so this nix expression doesnt try to use builtins.fetchTarball with a sha256
<clever> gchristensen: ah, i think i see the problem
<clever> wait, i think i misread something, let me test some more...
<clever> gchristensen: any ETA on nix 1.13 in nixpkgs?, i'm looking to use builtins.fetchTarball with a sha256
<clever> __monty__: if you indent a multi-line string with tabs, the tabs persist
<clever> __monty__: also, multi-line strings can stip off the common spaces, but not tabs
<clever> that is not what i would have expected from nix
<clever> srhb: oh, weird
<clever> "foo''bar"
<clever> nix-repl> ''foo'''bar''
<clever> gchristensen: it is imposible to reference it, lol
<clever> gchristensen: oh, fun, ....., perl-bindings is in a let block on the nix/default.nix
<clever> __monty__: the escape code is actually ''$, not ''${
<clever> nix-repl> ''foo''$bar''
<clever> "foo$bar"
<clever> and .override wipes all of the // junk
<clever> gchristensen: also, you cant .overrideAttrs nix, because the perl-bindings got slapped on with //, rather then .passthru
<clever> normal: `xset r rate 500 20`, and insane-fast: `xset r rate 1 1`
<clever> and i had to pre-type the undo command to even have a chance of escaping :P
<clever> iittss wweeiirrdd tthhaatt iittss ddoouubblliinngg uupp,, llooll
<clever> ii ccaanntt eevveenn ttaabb--ccoommpplleettee yyoouurr uusseerrnnaammee,, llooll
<clever> wwhheenn ttyyppiinngg nnoorrmmaallyy
<clever> aanndd tthhiiss iiss wwiitthh tthhee mmaaxx rreeppeeaatt ddeellaayy
<clever> srhb: defaults: auto repeat delay: 500 repeat rate: 20
<clever> srhb: let me see...
<clever> srhb: and i have messed with the repeat rate to cheat at some web-games, and the shell is practically unusable if you set the repeat rate to max, lol
<clever> srhb: i have done that when holding backspace to delete large blocks, lol
<clever> Myrl-saki: it would result it in downloading twice
<clever> wasnt sure it accepted it in a PM
<clever> gchristensen: yeah, lol
<clever> !tofu
<clever> sounds good to me
<clever> probably just a limit
<clever> Havvy: maybe near pandoc, if thats not inside the hackage-packages.nix blob
<clever> heh
<clever> so you can find them after you instantiate
<clever> ah, that can also query the outputs on a .drv file
<clever> Ralith: it can do fun things like this, which will get the value of the postConfigure env variable within the glibc derivation
<clever> [clever@amd-nixos:/tmp]$ nix-store --query --binding postConfigure $(nix-instantiate '<nixpkgs>' -A glibc)
<clever> also have a look at the flags in nix-store -q
<clever> or eval glibc.outputs in nix, via either nix-repl or nix-instantiate
<clever> Ralith: and also nix-store --query --outputs $(nix-instantiate '<nixpkgs>' -A glibc)
<clever> Ralith: try these 2 commands
<clever> [clever@amd-nixos:/tmp]$ ls -l result result-bin
<clever> [clever@amd-nixos:/tmp]$ nix-build '<nixpkgs>' -A glibc.out -A glibc.bin
<clever> Ralith: only for the outputs of the final derivation you pointed to with -A
<clever> Ralith: hydra doesnt have this issue, because hydra manually builds every step itself, rather then letting nix walk the tree for you
<clever> Ralith: then the result symlink wont be made, and youll need to parse some of the nix output, to follow the dependency chain of failures, and find the one that passed and failed
<clever> and then you can download the pcap, inspect the comms between the vm's, and know why it failed
<clever> ive used that to make complex qemu based tests, that can fail, but still leave pcap files in the output
<clever> hydra also checks and obeys that file
<clever> its only created upon failure
<clever> if it exists
<clever> and be aware that nix-build returning 0 is no longer a sign of success, you must now check the outputs nix-support/failed file for pass/fail
<clever> just be a bit more smart about which logs you copy, and dont crash in the crash handler
<clever> stdenv.mkDerivation { name = "foo"; failureHook = "mkdir $out ; cp configure.log $out/"; succeedOnFailure = true; }
<clever> inside the derivation
<clever> you can then copy logs to $out, and then will be in the result symlink, the same as if the build had passed
<clever> and it will put the failure code into $out/nix-support/failed
<clever> Ralith: another option, if you set succeedOnFailure = true;, then the nix-build will "pass" even if the build inside fails
<clever> -K isnt at play, so you never have to clean it up or find it
<clever> it will read the logs, from inside the sandbox, before nix cleans it up automatically
<clever> then build it without -K
<clever> so you can just add a failureHook attribute to your derivations, that cat's out the right log files
<clever> Ralith: this will run the failureHook "phase" upon build failures
<clever> Ralith: ah, i can think of something better, one minute
<clever> Ralith: from inside the builder, or after nix-build has failed?
<clever> fresheyeball: for example, /dev/sda1 ?
<clever> chreekat: i dont think there is any way to automatically clean it up
<clever> fresheyeball: what is the device path?
<clever> fresheyeball: what does /dev/disk/by-uuid/adsafsadfkl currently point to?
<clever> or was it just the boot directory on the root fs?
<clever> fresheyeball: and did you have an fs for /boot/?
<clever> i prefer zfs, and i dont trust grub with zfs, so /boot has to be an older FS
<clever> fresheyeball: the filesystem you used for / and /boot
<clever> fresheyeball: mount the rootfs to /mnt, and the boot fs to /mnt/boot/, then just run `nixos-install --chroot` and `nixos-rebuild boot`
<clever> fresheyeball: simplest fix i can see then, is to mount the root and boot fs under /mnt as normal, nixos-install --chroot, and then `nixos-rebuild boot` to repair /boot
<clever> fresheyeball: can you see the same uuid its looking for, if you run `blkid /dev/sd*` from the livecd?
<clever> fresheyeball: does it just happen when you boot the default option?
<clever> fresheyeball: can i see more to the right on that last line of text?
<clever> fresheyeball: the grub layer is working perfectly, and its failing to find the rootfs by uuid
<clever> unviewable
<clever> fresheyeball: it should be possible to fix this without the livecd, how far into the booting does it get?
<clever> samueldr: that should be a bit more stable, it will only break if you clone the entire drive to another one
<clever> samueldr: that only works until you move the drive to a different sata port
<clever> it is basically imposible to do it right with legacy booting
<clever> grub requires the root device, not a partition
<clever> all of the by-label and by-uuid symlinks, point to partitions
<clever> also, there is a major pain point here

2018-02-12

<clever> ottidmes: if you want to reuse a chunk of the config, you could make a class-name.nix file, which several hosts have added to imports
<clever> ottidmes: so it forms a tree, and i pick the most relevant starting point for that machine
<clever> ottidmes: both amd-nixos.nix and laptop.nix, have imports = [ ./core.nix ];
<clever> ottidmes: the laptop has imports = [ ./nixcfg/laptop.nix ];
<clever> ottidmes: my amd desktop just has imports = [ ./nixcfg/amd-nixos.nix ]; in the configuration, and basically nothing else
<clever> then each of those files, has a more common one in its imports field
<clever> so hostname.nix contains everything that is unique to that hostname
<clever> ottidmes: what i do, is i create a new hostname.nix file for each host, and that is the only thing i put into imports
<clever> ottidmes: imports = [ ./config/networking.nix ]; ?
<clever> ottidmes: add the file to the imports list instead?
<clever> layus:
<clever> wrass: the types are just attr sets with a few things in it, here is an example: https://github.com/NixOS/nixpkgs/blob/master/lib/types.nix#L103-L108
<clever> genesis: and also check what gchristensen linked
<clever> genesis: use lua5_3 instead of just lua
<clever> genesis: yes
<clever> genesis: can you gist what you have so far?