2019-05-18

<clever> why-depends doesnt work for memory references, so you cant use that to figure it out
<clever> capnp: it can also be in the closure of something else, that has a storepath in $PATH or any other env var
<clever> and with no other roots, nothing can find ffmpeg
<clever> capnp: then everything that is currently running, wont be!
<clever> capnp: simplest solution i can think of is to just reboot
<clever> capnp: is ffmpeg running? or anything that links to ffmpeg? or a nix-shell is open?
<clever> bodqhrohro_: the only way to edit it is with the nix-env command, which creates copies
<clever> bodqhrohro_: you cant modify it, its read-only
<clever> capnp: can you put all 3 into a pastebin, along with the nix-store -q --roots output fo each?
<clever> capnp: what path are you doing a query on?
<clever> capnp: yeah, its not simple
<clever> capnp: strace nix-store, as root
<clever> capnp: a running process is refering to it
<clever> drager: its in the nixpkgs manual
<clever> drager: youll want to write a derivation that will patchelf it
<clever> drager: you need to update your channel
<clever> mkoenig: oh right, private repo
<clever> mkoenig: the only variables, are the name of the cabal file, and the nixpkgs rev, and that is far more compact then what cabal2nix generates
<clever> mkoenig: https://github.com/input-output-hk/proposal-ui/blob/master/default.nix and the shell.nix nearby is how i handle things
<clever> mkoenig: callCabal2nix is one option
<clever> Izorkin: glibc will always be available when building on linux
<clever> eek!
<clever> Izorkin: try adding glib to the inputs?
<clever> Izorkin: your error mentions line 951
<clever> 2019-05-18 12:10:04 < Izorkin> How to fix build? source - https://pastebin.com/U7T0yz0p Error - Makefile:951: *** missing separator. Stop.
<clever> Izorkin: if you go back to your old code, what is line 951 of Makefile?
<clever> gchristensen: possibly by assigning to options.services.nginx.virtualHosts, giving it a submodule, that has a default extraConfig, but that may conflict due to defining extraConfig twice
<clever> Izorkin: you can use the preAutoreconf hook to put those extra things back in
<clever> Izorkin: looks like they added extra junk to their autogen.sh script
<clever> Izorkin: you want to use autoreconfHook, not autoregen
<clever> nope
<clever> bodqhrohro_: if you set i18n.supportedLocales, then nixos will trim the locales down while building nixos

2019-05-17

<clever> catern: binutils will be in the shell by default, no need to add it
<clever> 2019-04-03 01:30:01< {^_^}> If a Nix file foo.nix starts with something like `{ stdenv, cmake }:`, you can build it with `nix-build -E '(import <nixpkgs> {}).callPackage ./foo.nix {}'`
<clever> one sec
<clever> ,callPackage cizra
<clever> yeah
<clever> which would generate a db
<clever> it might be possible to run --load-db inside a derivation, with NIX_REMOTE=local?root=/tmp/dummy/
<clever> catern: and there are utils to generate a fake export, that contains the closure of a given path
<clever> catern: there is --dump-db and --load-db to deal with exporting/importing the db as a text file
<clever> and when you do remove the overlay, python.nix wont change any
<clever> tbenst_: if you add: python36 = super.python37.override {packageOverrides = self.pythonOverrides;}; to the overlays.nix, then you can just use pkgs.python37 later on
<clever> tbenst_: yep, thats one way to get it working
<clever> you then use a nixpkgs overlay (what you have now) to replace pkgs.python37 with the result
<clever> tbenst_: this will let you apply python overlays to python37, and create a new python package set
<clever> python37.override { packageOverrides = self: super: {}; }
<clever> tbenst_: found it
<clever> 20 , packageOverrides ? (self: super: {})
<clever> 19 # For the Python package set
<clever> 8009 pythonInterpreters = callPackage ./../development/interpreters/python {};
<clever> 8010 inherit (pythonInterpreters) python27 python35 python36 python37 pypy27 pypy35;
<clever> tbenst_: both forms, wipe all other values from pythonPackages
<clever> tbenst_: pythonPackages.nbdime=x; is identical to pythonPackages = { nbdime = x; };
<clever> (which will likely fail if its a python based default.nix)
<clever> so you would do pkgs.nbdime
<clever> tbenst_: line 7 is adding nbdime directly to pkgs, not the python packages
<clever> so line 11 is refering to ps.nbdime, via the `with ps`
<clever> ah, i see it
<clever> tbenst_: what error is it giving?
<clever> tbenst_: i just load the default.nix's in using callPackage in the packageOverrides or overlays
<clever> DigitalKiwi: but it will delete the generation for the booted one, so once you do reboot it has no roots, and can be GC'd
<clever> infinisil: ive found that anoying
<clever> [clever@system76:~]$ nix eval '(with import <nixpkgs> {}; hello.meta.position)'
<clever> "/nix/store/i2digbjggcjmr419j51imq0xwk4qrq69-nixos-19.09pre177651.aeb464dfd37/nixos/pkgs/applications/misc/hello/default.nix:15"
<clever> angerman: yep, that looks good
<clever> so the entire answer is wrapped with `if failed then throw else answer`
<clever> then throw "\nFailed assertions:\n${concatStringsSep "\n" (map (x: "- ${x}") failedAssertions)}"
<clever> and trace the strings if they arent
<clever> and then the top-level attr will check that they are all true, before contiuing
<clever> you instead have a "nixos option" called assertions, which is a list of bool/string pairs
<clever> angerman: nixos solved the assert problem, by not using asserts
<clever> angerman: wrap them with builtins.trace i believe
<clever> this forces it to evaluate for darwin (and use your darwin build slaves), and lets you specify overrides
<clever> nix repl '<nixpkgs>' --argstr system x86_64-darwin --arg config '{ packageOverrides = pkgs: {}; }'
<clever> nix repl '<nixpkgs>' --arg config '{ allowUnfree = true; }'
<clever> manveru: if you run it on a nix file, that defines a function
<clever> so if you are older then that rev, the --help is wrong, and it silently drops the args
<clever> this is what made it actually work
<clever> manveru: `nix repl --help` claims --arg and --argstr work
<clever> manveru: i read the source, docs can be wrong, lol
<clever> fetchtarball can now refer to channels, but its just an alias over github URL's basically
<clever> and they update the wrong one
<clever> its often just people adding the same channel to 2 users, and then one overrides the other
<clever> manveru: how are channels confusing?
<clever> heh, ok, not OOM! lol
<clever> how much ram, and how big is the initrd file?
<clever> and line 13, openssh allows itself thru the firewall automatically
<clever> ivan: the systemd.network.enable stuff may be messing with the dhcp support
<clever> what happened when you tried to kexec it?
<clever> ah, why not just run the installer directly on the target?
<clever> ive ran 2 machines on iscsi before
<clever> ive had trouble with nbd even connecting reliably in the past
<clever> have you looked into iscsi yet?
<clever> i'm guessing it cant figure out what the device will be called at boot-time, and cant generate the right config to refer to the /boot fs
<clever> yeah, it should be using p1 for stage 1.5
<clever> ivan: what does `fdisk -l /dev/nbd0` report?
<clever> ivan: grub-install must be pointed to the root of a device, not the partition
<clever> no need for nixos-rebuild or home-manager
<clever> you can also test it with just config.nix and `nix-build '<nixpkgs>' -A chromium`
<clever> yep
<clever> that error is why it is marked as broken
<clever> buffet: configuration.nix overlays wont impact home-manager
<clever> lostman: and you dont always need to use a shell.nix file, you can just run `nix-shell -p` to get a basic shell with just a compiler
<clever> man still works in nix-shell too
<clever> and `man malloc` works normally outside nix-shell
<clever> lostman: lines 41-47 joins several of the man page packages up, and then i can `nix-env -iA nixos.manymans` to install them
<clever> lostman: https://gist.github.com/cleverca22/73d96d83a34b6bba24e19af3784f6237 this is part of my config.nix file
<clever> compile time stuff and compilers in generaly just arent meant to work outside of nix-shell on nixos
<clever> ,libraries lostman
<clever> ,nix-shell lostman
<clever> ashkitten: aha

2019-05-16

<clever> ashkitten: if you run the command without &, and let it delay booting, does the tune stop correctly?
<clever> ashkitten: i cant remember where i saw that either, and google doesnt like searching for special characters
<clever> ashkitten: one min
<clever> ashkitten: you can also just tell nixos to copy the binary properly
<clever> > pkgsCross.muslStatic.hello
<clever> )
<clever> (but it will leak an entire glibc into the initrd
<clever> just ${pkgs.something}/bin/beep
<clever> ashkitten: thats fully automated
<clever> use a different beep, not the busybox beep
<clever> so when you mess with argv0, the "beep" binary doesnt know its beep anymore
<clever> oh
<clever> maybe the other way around?
<clever> ashkitten: what is the exact command you tried?
<clever> something like that, cant remember the exact details
<clever> so you dont murder the thing thats giving the rootfs
<clever> thats used for fuse and unionfs type stuff dealing with the rootfs
<clever> ashkitten: if you prefix argv[0] with an @ i think, then it wont be killed by switch-root
<clever> ashkitten: oh, there is the @ thing
<clever> Baughn: the beep command is seperate from the bel character
<clever> infinisil: ive found a computer (in pieces) in a box one day, put it together, turned it on, and discovered, windows was in hibernation, lol
<clever> infinisil: zero power usage when in hibernation
<clever> infinisil: wut
<clever> pie_: it basically just pushes everything into swap, and then cuts power
<clever> Zer0xp: configuration.nix
<clever> zeta_wolf: yes
<clever> zeta_wolf: just use chgrp, not /bin/chgrp
<clever> i should get off to bed
<clever> and its getting late here
<clever> but after the build is done, it also ensures that everything in $out is world-readable
<clever> tobiasBora: the nix sandbox ensures you can only see things in /nix/store that you need to complete your build
<clever> generally, yes
<clever> so the stuff that is reused 100's of times, is only built/downloaded once
<clever> and then just running nix-build on it
<clever> tobiasBora: it deals with 100's of computers at once efficiently, by putting all 100 machines into a single derivation
<clever> yeah
<clever> yes
<clever> hence, the pre-start with sed
<clever> but you need to modify the service files to be able to accept a secret that isnt in /nix/store/
<clever> nixops automates secrets as well, deployment.keys will be scp'd over for you
<clever> and the secrets generally dont change much
<clever> secrets would be copied in on a seperate file, that the git repo refers to
<clever> within the rpi, run a `git pull` in /etc/nixos, then nixos-rebuild switch
<clever> and in some cases, auto-provision the hardware in the cloud
<clever> to manage a set of many machines remotely, and configure them to be able to refer to each-others IP's automatically
<clever> and rather then scp, just do a `git pull`
<clever> just use nixos-rebuild
<clever> at that point, why even use nixops? :P
<clever> you can configure nixops to manage the machine its running on
<clever> so it cant be GC'd
<clever> if you enable rollback support in nixops, it will also root the closure
<clever> tobiasBora: once you have that closure, as long as you dont GC it, the next deploy will be faster
<clever> yeah, you can never have a path without its deps
<clever> tobiasBora: if you go with aarch64, then you can get help from cache.nixos.org
<clever> yep
<clever> tobiasBora: yeah, but how many machines are you actually sharing with users you dont trust?
<clever> tobiasBora: depends on if others can read your /nix/store/
<clever> using systemd prestart
<clever> tobiasBora: you would have to modify the ldap service, to run a sed command before starting the service
<clever> tobiasBora: the only way to deal with such config, is to rewrite the nixos module, to take a path, and run set at pre-start, to generate the real cfg
<clever> avn: the problem is that building electron under docker results in a binary that relies on /usr/lib, and i then need x11 working to run that binary
<clever> and built it on ubuntu, under virtualbox :P
<clever> i eventually gave up on doing the initial testing on nixos
<clever> if i'm reading the docs right
<clever> electron just has a DEPS file, and they expect you to run gclient to fetch the rest
<clever> and i'm debugging a bug in the electron event loop
<clever> but i havent found one for electron yet
<clever> avn: i think the chromium derivation is cheating with a release tarball, that has the result of running gclient, then stripping all .git's
<clever> avn: ive also been trying to build electron with nix, and ran into gclient

2019-05-15

<clever> avn: i have 1181 tabs in my main profile...
<clever> well, not segv, but sigtrap
<clever> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
<clever> #0 0x000055af7b463a59 in WTF::PartitionsOutOfMemoryUsing256M() ()
<clever> avn: oh, and youtube keeps using so much ram, the renderer process actually segfaults
<clever> avn: twitter on its own is using 2.5gig of ram
<clever> avn: i dont really use weechat, i just have it logging things
<clever> avn: the only config that isnt default, is the auth token to access slack
<clever> avn: yep
<clever> zeta_wolf: udev will redo the chmod every time the backlight driver is loaded
<clever> avn: the entire weechat config is in the nixos-configs
<clever> avn: irssi for irc, weechat for slack
<clever> zeta_wolf: correct
<clever> and re-do the chmod
<clever> since the rule will trigger every time the driver is loaded
<clever> zeta_wolf: the udev rule will also persist
<clever> zeta_wolf: but you could use those exact rules as an example to just chmod o+w the file your using
<clever> zeta_wolf: thats just telling udev "run this" any time a backlight thing is loaded
<clever> zeta_wolf: ah, thats not properly telling udev to fix the permissions as it makes things in /dev/
<clever> zeta_wolf: you need to read the nixos manual
<clever> zeta_wolf: home manager cant do anything with /sys, since it doesnt get root
<clever> brb
<clever> zeta_wolf: so you need a systemd service that runs that again next time you boot
<clever> zeta_wolf: that will be undone when you reboot
<clever> if i switch fdisk to advanced mode (via x) i have the option to change the part uuid
<clever> u change partition UUID
<clever> then your GPT tables may have been cloned, and the bios has no way to know which disk to use
<clever> which makes sense, the firmware wants to find the partition directly, without having to open (and understand) every single fs, and parse the fs uuid's
<clever> and its the partuuid that is used by efi
<clever> Boot0004* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<clever> ah, blkid is nice enough to show both
<clever> /dev/nvme0n1p1: UUID="7DBC-2698" TYPE="vfat" PARTUUID="27c99b08-455d-4dfe-a44f-6150cbc09ef8"
<clever> [root@system76:~]# blkid /dev/nvme0n1p1
<clever> with gpt, every fs now has 2 uuids, the partuuid, and the fsuuid
<clever> avn: also check what fdisk -l says about it
<clever> avn: run blkid on the block device
<clever> if bind is told that its master, it wont try to constact the authorative one, since it believes thats itself
<clever> configure them all as master, but name one as authorative in the SOA record
<clever> infinisil: yeah, thats far simpler, just make every server a master, and let nixops manage the sync
<clever> and also, if you perfectly undo a change in the nix code, and the derivation matches an older one, nix will reuse the old build, and its old serial#
<clever> both normal rollbacks, will undo the serial# and go backwards
<clever> but i can see problems with that
<clever> judson_: 2019-05-15 13:01:58< infinisil> This is the magic code: https://paste.infinisil.com/ZXmvtzD4EY.nix
<clever> judson_: infinisil is impurely using the date at build time as a serial#
<clever> avn: decide which partition should be your ESP, and fix up the config, then confirm that efibootmgr is refering to its uuid correctly, and with the right path
<clever> zeta_wolf: exactly what they said, chmod the file, probably with a systemd service
<clever> zeta_wolf: which is why the readme file didnt mention udev
<clever> zeta_wolf: so a udev rule will never fix that
<clever> zeta_wolf: udev cant manipulate the permissions of things under /sys
<clever> avn: but if anything tried to modify one of the disks on its own, the mirror will be "corrupt" and i have no idea how it will decide what the "right" state is
<clever> avn: i suspect you can do some funny bussiness with mdadm or device mapper, to mirror 2 parititions together (without a header) and then mount the result to /boot/EFI/
<clever> avn: yeah, so the efi partition must be at that path, and yeah, i dont see any support for 2 ESP's
<clever> zeta_wolf: what is the node under /dev that your trying to fix permissions on?
<clever> avn: ah, thats based on what you set boot.loader.efi.efiSysMountPoint to i think
<clever> run500: mostly that builtins.fetchgit can be impure, it happens at eval time, and doesnt cache the same way as pkgs.fetchgit
<clever> judson_: i think the best option is to have a pre-start script for the dns server, that compares the state in a runtime state dir, to the state from /nix/store, and if they differ, increment a serial# also in the runtime state dir, and sed that into the zone file
<clever> judson_: rollbacks also become an issue, if you ever do a nixos rollback, the serial# goes backwards, and dns wont update
<clever> judson_: the generation# is only assigned after the nix level builds are finished, so you cant access it then
<clever> avn: not really sure why, but the kernel copying is done by install-grub.pl, not grub-install
<clever> zeta_wolf: a: you missed the `info`, b: you need to replace SYSPATH with a path begining with /sys/
<clever> run500: nope, use pkgs.fetchgit
<clever> judson_: nope
<clever> zeta_wolf: you have to replace SYSPATH with a path under /sys/
<clever> zeta_wolf: until you ctrl+c
<clever> zeta_wolf: `udevadm monitor` will tell you what is being added/removed from the system, then you need to mess with `udevadm info` to query a device
<clever> zeta_wolf: oh wait, thats udevadm complaining, because it wasnt given a command
<clever> avn: also, why is zsh complaining, when ls should be the one accessing it??, what does `type ls` say?
<clever> avn: wait, somethings not right, kernels is rwx rx rx, so it should be world readable, yet you cant read it
<clever> avn: which user did you run that as?
<clever> avn: `mount ; ls -lhd /boot/sdb/ /boot/sdb/kernels ; ls -lh /boot/sdb/ /boot/sdb/kernels`
<clever> zeta_wolf: its always present, cant be removed
<clever> zeta_wolf: echo $PATH
<clever> zeta_wolf: you need to query that with udevadm
<clever> zeta_wolf: the KERNEL= is based on the what the kernel said about the device when udev loaded it
<clever> avn: i would also `chmod 0 /boot/sd?/efi` when both arent mounted, so it will fail to create things in the wrong dir next time
<clever> avn: otherwise, it may not boot at all, since you deleted the files it refers to (which where at the wrong place)
<clever> avn: and before you reboot, make sure efibootmgr gives the right paths
<clever> zeta_wolf: nope
<clever> avn: umount one of those, and then check the same path
<clever> avn: i always `chmod 0 /boot` so if i forget to mount /boot, it fails to create anything in /boot
<clever> avn: did you forget to mount the partitions?
<clever> that doesnt sound right
<clever> avn: all 3 nixos entries are on the same partition, just in different directories
<clever> avn: i find efi heavily depends on the firmware in the board
<clever> avn: efibootmgr -v
<clever> avn: `nixos-rebuild --install-bootloader` will force it to re-run grub-install
<clever> avn: ensure that grub-install updates every ESP and /boot partition at once
<clever> avn: i think the problem can happen if the efi binary is out of sync with the modules in the /boot/ dir
<clever> avn: and the bios loaded the old one i'm guessing
<clever> avn: in your case, i'm guessing you have 2 efi system partitions? and one of them has the "old" grub
<clever> but efi doesnt use loader.devices...
<clever> avn: i suspect its due to the stage 1.5 (from boot.loader.devices) not being updated correctly
<clever> avn: 2019-05-15 15:06:11< dhess> ugh, EC2 instance totally hosed, "error: symbol `grub_file_filters` not found."
<clever> avn: what exactly is the error you got?
<clever> avn: dhess and i just finished a long convo about that
<clever> if grub.device is set right
<clever> dhess: just letting switch-to-configuration run grub-install should sync everything to the same version
<clever> dhess: oh, and that might be why the other machine bricked itself!
<clever> dhess: but it will still update the modules in /boot/ i think, and after a while, they could become incompatible with the stage 1.5
<clever> dhess: oh, one thing i can think of, if nixops is setting device = "nodev"; on nvme machines, then it will just never update stage 1.5 and the MBR
<clever> dhess: i suspect aws did some weird stuff to make legacy boot on nvme without any trouble, so you just need to set boot.loader.device right and it will keep working
<clever> dhess: definitely looks like a legacy grub install
<clever> dhess: and right at the edge on line 50, you can see a fragment of stage 1.5
<clever> dhess: at line 25, you can see some of the grub stub, in the MBR sector
<clever> dhess: can you pastebin the output of `hexdump -C /dev/nvme0n1 | head -n50`
<clever> dhess: it also claims to be a t3.micro, which the nixops file claims doesnt support nvme
<clever> [ 0.000000] DMI: Amazon EC2 t3.micro/, BIOS 1.0 10/16/2017
<clever> dhess: next, is it mbr or gpt parttitioning?
<clever> dhess: the BOOT_IMAGE here confirms its grub booting in legacy mode
<clever> [ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/nix/store/c12hzfhwm960b64x1nsmw107kyppy6an-linux-4.14.68/bzImage systemConfig=/nix/store/vb59dplr3f4jcgps6fxfjrzvnfrpgk7p-nixos-system-unnamed-19.03pre-git init=/nix/store/vb59dplr3f4jcgps6fxfjrzvnfrpgk7p-nixos-system-unnamed-19.03pre-git/init panic=1 boot.panic_on_fail console=ttyS0 nvme_core.io_timeout=255 loglevel=4