<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>
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>
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>
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>
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: `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