2019-11-26

<clever> dredozubov: sounds like you want something like hydra, which is meant to do CI jobs
<clever> dredozubov: why not?
<clever> dredozubov: but ive notices some weirdness with people trying to force all remote jobs, try `--max-jobs 1` ?
<clever> dredozubov: then your on a singleuser mode and it should just work
<clever> dredozubov: is nix-daemon running
<clever> dredozubov: single or multiuser mode?
<clever> dredozubov: are you running it as root or a trusted user?
<clever> dredozubov: the caches configured on the remote machine
<clever> dredozubov: and the machine triggering the build already has all of the inputs to the drv
<clever> dredozubov: after building any given derivation, only the result of that derivation is copied back
<clever> pbb: builtins.elem
<clever> dredozubov: so there will be less things you have to copy from the local machine
<clever> dredozubov: if you `--option builders-use-substitutes true`, the remote machine will be allowed to use cache.nixos.org
<clever> dredozubov: it will download the inputs to the local machine, then copy those inputs to a remote machine, build the product there, then copy the result back
<clever> 0xff!!
<clever> yep
<clever> jlv: sounds like hardware.opengl isnt linking to it properly
<clever> and only when its recursively making things non-lazy, does it have a backtrace
<clever> the problem is that nix is tossing lazy values all over the place
<clever> and you have no idea where b came from
<clever> so if you do `let a = 5*5;` and then pass `a` to a function like `a_in: { b = a_in; }`, then try to read b, the --show-trace may point towards b, rather then a
<clever> its not the reference call-chain, but the force callchain
<clever> zeta_0: i think the most complicated to try and figure out is the --show-trace output
<clever> --- Log opened Thu Jun 25 11:13:00 2015
<clever> $ head ~/irclogs/freenode/#nixos.log
<clever> zeta_0: ive been using nixos for ~3-4 years
<clever> zeta_0: did you get the quotes right?
<clever> zeta_0: you will want to `watch -d 'grep Dirty /proc/meminfo'` and wait until it gets near zero
<clever> zeta_0: and if you check it again, has the number gone down?
<clever> zeta_0: `grep Dirty /proc/meminfo` again, what does it say?
<clever> notgne2: i looked into it, and it was literally just bind+nginx with 2 config files
<clever> notgne2: i once saw somebody showing off a docker image that can act as a steam content server cache, so you can setup a lan party and download games at gigabit speeds
<clever> hodapp: just ignore the smell of poo coming from it!
<clever> hodapp: who needs to potty train your software when you can just slap a daiper on it and call it done!!
<clever> zeta_0: other programs will take just as long to write the image
<clever> :D
<clever> and it ignores all volume controls
<clever> notgne2: it produced ear-splitting noises if you happened to be wearing headphones
<clever> notgne2: one of my laptops lacked that speaker, and routed it thru the sound card
<clever> notgne2: almost caught fire?
<clever> notgne2: maybe start by undoing changes on debian, to see what breaks it and what is actually needed, then document what is needed first
<clever> zeta_0: i still need to order a 4
<clever> hodapp: then it will just give a shout out to the nearby dhcp server
<clever> hodapp: docker has other network modes, like bridging, which will just give the container its own ip on the real lan
<clever> zeta_0: it should work on nixos just fine
<clever> zeta_0: the script to update the rpi4 firmware is just a regular bash script that runs a static elf binary
<clever> hodapp: either tell docker to stop touching iptables (see above) or find a way to tell docker "i broke it, re-do whatever you did to the firewall"
<clever> hodapp: nixos isnt aware of docker messing with things, and just undid it
<clever> hodapp: that sounds likely
<clever> zeta_0: and i'm pretty sure you can update the firmware from nixos as well
<clever> zeta_0: the only part of the firmware you can update on the rpi4 is fairly small, and i dont know of any world-breaking bugs with it yet
<clever> notgne2: it might even be broken by restarting the nixos firewall service!
<clever> hodapp: then you can thank docker for opening the service to the world without asking
<clever> zeta_0: is it an rpi4?
<clever> hodapp: and if you stop the docker container, does it disapear?
<clever> hodapp: is the port listed in the output of `iptables-save` ?
<clever> notgne2: that sounds likely
<clever> hodapp: localhost isnt blocked by the firewall
<clever> hodapp: how did you test that its open?
<clever> hodapp: ssh?
<clever> zeta_0: looks like a freshly partitioned disk, with zero partitions, you should be safe to try `unzip -p 2019-09-26-raspbian-buster-full.zip | sudo dd of=/dev/sda bs=4M status=progress conv=fsync`
<clever> zeta_0: hmmm, and one last thing, just because i'm curious, what does `blkid /dev/sda` and `fdisk -l /dev/sda` report?
<clever> zeta_0: you shouldnt need to zero things out
<clever> zeta_0: and to doubly confirm it, does sda vanish from `lsblk` when you unplug the usb adapter?
<clever> zeta_0: https://pastebin.com/Za9gaMXT that closely matches the rasbian image i have
<clever> notgne2: some packages still dont cross compile, and ive not tried cross-building the kexec image yet
<clever> notgne2: you would need to first install nix on arm, and build the entire linux image for kexec, which would take a while on an rpi
<clever> zeta_0: what does `hexdump -C /dev/sda | head` report?
<clever> zeta_0: but dd erased everything, so its not labeled anymore
<clever> zeta_0: /run/media/wolf only exists if you have a drive labeled wolf
<clever> zeta_0: is it a usb adapter or a real SD reader in a laptop?
<clever> zeta_0: what does lsblk print out?
<clever> Dirty: 64 kB
<clever> and dirty slowly shrinks
<clever> Dirty: 500108 kB
<clever> then it just hangs, while the actual write runs
<clever> [clever@system76:~]$ grep Dirty /proc/meminfo
<clever> Dirty: 724512 kB
<clever> in my case, pv shows progress, but the kernel cheats and makes it claim to write at nearly 1gig/second
<clever> 2.09GiB 0:00:02 [1002MiB/s] [====================================================================================================================================================================>] 100%
<clever> [root@system76:~]# pv 2019-09-26-raspbian-buster-lite.img > /dev/mmcblk0
<clever> zeta_0: maybe, just make sure sda is the SD card
<clever> -rw-r--r-- 1 root root 2.1G Sep 25 21:24 2019-09-26-raspbian-buster-lite.img
<clever> [root@system76:~]# ls -lh 2019-09-26-raspbian-buster-lite.img
<clever> notgne2: yep, thats right
<clever> zeta_0: you can also use `pv` to get better feedback, one minute
<clever> zeta_0: yep
<clever> that tells you how much is still pending to be written
<clever> notgne2: you can also `grep Dirty /proc/meminfo`
<clever> zeta_0: how long it takes depends on how big the .img file is
<clever> zeta_0: was it actually frozen? or was it just busy writing the image and you didnt wait for it to finish?
<clever> jlv: there are ~3 components, the driver itself (c code in the linux kernel), the firmware, and then the opengl libraries that talk to the driver
<clever> zeta_0: its pretty hard to break an SD card with dd
<clever> jlv: so hardware.firmware = [ unstable.firmwareLinuxNonfree ]; may do it
<clever> jlv: i can see that the file exists on my machine, and is part of the linux firmware non-free package
<clever> /nix/store/pxdhpx9mllm8rsmi2y21qbzpyaawiw33-firmware-linux-nonfree-2019-10-22/lib/firmware/amdgpu/navi10_gpu_info.bin
<clever> $ realpath /run/current-system/firmware/amdgpu/navi10_gpu_info.bin
<clever> notgne2: the specific error he pasted above is earlier in the chain then hardware.opengl
<clever> zeta_0: there is no need to format before you dd it over
<clever> zeta_0: yeah, thats a regular disk image, dd'ing it to the SD card will replace all filesystems and partitions
<clever> jlv: so you need to shove some unstable package (that contains a navi10_gpu_info.bin file) into hardware.firmware
<clever> List of packages containing firmware files. Such files will be loaded automatically if the kernel asks for them (i.e., when it has detected specific hardware that requires firmware to function). If multiple packages contain firmware files with the same name,
<clever> hardware.firmware
<clever> jlv: which came from hardware.firmware
<clever> 59 ln -s ${config.hardware.firmware}/lib/firmware $out/firmware
<clever> $ vi nixos/modules/system/activation/top-level.nix
<clever> jlv: the firmware is usually in /run/current-system/firmware
<clever> jlv: the driver loaded fine, but it cant find the firmware for the card
<clever> zeta_0: what does `unzip -l 2019-09-26-raspbian-buster-full.zip` report?
<clever> zeta_0: what are the contents of the zip file?
<clever> zeta_0: how did you mess up the SD card using dd?
<clever> zeta_0: there are no nix files in that repo, so you need to start by writing an expression that will build etcher, likely using yarn2nix
<clever> > let key1="value1"; key2 = "value2"; in key1 + key2
<clever> zeta_0: usually, something that refers to the keys you assigned using let
<clever> zeta_0: its always in the form of: let key1="value1"; key2 = "value2"; in expr
<clever> zeta_0: the let keyword must always have an `in` after the things its assigning
<clever> jlv: you want { config = self.config; }
<clever> jlv: the {} on line 6 is telling nixpkgs to load the config.nix in your home dir, rather then obeying the nixos option nixpkgs.config
<clever> jlv: can you pastebin your nix code?
<clever> jlv: did you import <nixpkgs> {} ?
<clever> nh2: so something like `nix-collect-garbage --max-freed 10m` will start with the invalid paths
<clever> nh2: also of note, nix-collect-garbage will delete those invalid paths first, before moving to valid but garbage
<clever> nh2: then it will be in the remote machines store
<clever> nh2: they do exist after failure, but arent registered as valid
<clever> nh2: `grep -r --color /nix/store/gmx041hj1b07c3hcgzz4jmi5bpx57jaf-mesa-19.1.5 /nix/store/drrpq7xcifkdimqgcb32mh4rwhhjzwxr-mesa-19.1.5-drivers`
<clever> nh2: `grep -r --color /nix/store/drrpq7xcifkdimqgcb32mh4rwhhjzwxr-mesa-19.1.5-drivers /nix/store/gmx041hj1b07c3hcgzz4jmi5bpx57jaf-mesa-19.1.5`
<clever> nh2: grep each dir for references to the other one
<clever> last i heard, they didnt want to leave a `nixos-rebuild build` going overnight, because it would cook the laptop even when idle
<clever> gchristensen: i think i saw somebody mention that in this channel within the last 48 hours
<clever> pbb: though due to the complications within kexec, you would want to add a kexec binary to things at a minimum
<clever> pbb: this generates an initrd with a haskell binary at /init, and absolutely nothing else in the initrd!
<clever> pbb: have you seen haskell-init?
<clever> samueldr: also try playing with chvt
<clever> samueldr: `echo foo > /dev/tty1` before you start X up
<clever> samueldr: try to echo to both /dev/tty and /dev/console and see what happens? and if you booted with console= then /dev/console goes there
<clever> samueldr: if you have framebuffer, then fbcon should work?
<clever> pbb: yep
<clever> samueldr: it would have to be a kernel that can work on that device, with a userland gui that can deal with the drivers, then kexec things based on user input
<clever> samueldr: ^^ and it could be used as a bootloader menu on android devices
<clever> pbb: then you could unbrick things in the cloud
<clever> pbb: ive wanted similar to get ssh access to the bootloader, so you could access the rollback menu
<clever> and youcompleteme gives some of that for python
<clever> yeah, ive had some of those with java before in eclipse
<clever> jared-w: so if i open the other files in tabs in vim, it can complete the functions they export
<clever> jared-w: i use youcompleteme in vim, and in the default mode, it just auto-complete any symbol found in any open file
<clever> there is nothing to even configure with ghcid, you just run it on a repl/ghci command
<clever> jared-w: most of the time, you can get away with just: runhaskell Setup.hs configure ; ghcid -c "runhaskell Setup.hs repl"
<clever> jared-w: ive found ghcid is plenty

2019-11-25

<clever> you would have to add your own feature to enforce things
<clever> so preferLocalBuild can still build remotely, if local is busy
<clever> the local flag only exists when hydra is checking mandatory features, but not supported features
<clever> so you can whitelist hydra to build such things on localhost
<clever> "local" refers to anything that is tagged with preferLocalBuild = true;
<clever> hydra also has a non-standard mandatory feature
<clever> so non-benchmark stuff doesnt hog the system
<clever> that is a machine that supports both kvm and benchmark, and will only ever build things that require benchmark
<clever> there is another column after supported features, mandatory features
<clever> a,b,c
<clever> pbb: which drv file is failing to build?
<clever> builder@192.168.2.126 armv6l-linux,armv7l-linux /etc/nixos/keys/distro 1 1 big-parallel
<clever> # cat /etc/nix/machines
<clever> did you declare that your build machine has big-parallel?
<clever> you can also set system-features in the core2duo's nix.conf file
<clever> just use `--option system-features 'benchmark kvm nixos-test'` to declare that your local machine cant do big parallel jobs
<clever> pbb: a kernel requires the big-parallel flag already, so no need to change the derivation
<clever> $ nix show-config | grep feat
<clever> system-features = benchmark big-parallel kvm nixos-test
<clever> pbb: then use the supported-features flag
<clever> pbb: i think it still wants to do some builds locally, and then ran out due to a limit of 0
<clever> pistache: you can also just import nixpkgs/nixos, and pass it a file like this
<clever> pistache: line 3 has an example nix-build command, `-I nixos-config=...` is the same as `configuration = ...` in an expr
<clever> yep
<clever> pistache: you want to just `import <nixpkgs/nixos> { configuration = ...; }`
<clever> ah
<clever> but the nix sandbox blocks all of that
<clever> pistache: nixos-generate-config needs to access all kinds of state for the host, to see what config you need
<clever> m3lt99034: builtins.readFile lets you turn a file into a string
<clever> m3lt99034: services.udev.extraRules
<clever> red[evilred]: should be fairly simple, but there wont be a binary cache building for it, youll first need to get nix installed on the device, and use nix-build to build things like the closure of nixos
<clever> run500: did you run it as root (or a trusted user) ?
<clever> steell: a variation of that, yes
<clever> red[evilred]: what was the problem again?
<clever> steell: i used https://gist.github.com/a73cb1ab33c4561482478d360fd1a206 before, when building mesa from source
<clever> pbb: and then things deadlock
<clever> pbb: if you form a cycle, then the remote build machine may try to go backwards to the one requesting the build
<clever> pbb: and if the build user is marked as a trusted user, you dont have to setup the signing
<clever> pbb: just a normal build machine, not --build-host
<clever> pbb: configure it as a build machine
<clever> jared-w: its called nix-serve, and the module is already in nixos
<clever> yep
<clever> run500: and nix copy can be told to not check sigs
<clever> run500: there is also `nix copy-sigs`
<clever> kraem: tricky question, you would have to review the release notes and see what has been fixed and what type of problems your open to
<clever> kraem: if you switch back to normal nixos-unstable, then hydra will always have things built
<clever> run500: you can also use `local?root=/foo` instead, and it will create a complete store that could be chroot'd into, or copied from
<clever> kraem: nixos hydra or your own hydra? which channel are you on?
<clever> CptCaptain: its in the default systemPackages, so it cant easily be removed
<clever> raboof: also, you generally dont want to set builder, that just makes things harder for yourself
<clever> raboof: i would just do something like use $out as a seed for the prng that generates the guid
<clever> lemsip: for example, line 31-43 generates a fake electron cache, so electron-builder doesnt have to fetch anything
<clever> raboof: why do you need only the hash?
<clever> lemsip: i already have electron-builder working fully under nix-build
<clever> lemsip: why is it futile?
<clever> lemsip: or your scripts fixed to work without the FHS
<clever> lemsip: then the FHS env will need to be fixed to include them
<clever> lemsip: are the .pc files in /usr/lib/ ?
<clever> lemsip: why are you trying to build things in an FHS?
<clever> CptCaptain: it wont format things on its own, it will just stop mounting, or try to mount with the wrong flags, causing it to not boot
<clever> lemsip: and you generally dont need to use FHS
<clever> lemsip: ive found that pkgconfig only works right under normal nix-shell
<clever> CptCaptain: try just imports = []; to start with, and see what happens from there
<clever> CptCaptain: you may need to try removing it, see what breaks, and then find a working minimal config to replace it with, and get the docs updated
<clever> CptCaptain: but if you remove that, it may cease to boot, so a new option must exist, that sets the right options for an rpi
<clever> CptCaptain: so yes, sd-image-aarch64.nix is your problem
<clever> CptCaptain: which enables ssh, but disables auto-start!
<clever> CptCaptain: one min...
<clever> CptCaptain: imports = [ <nixpkgs/nixos/modules/installer/cd-dvd/sd-image-aarch64.nix> ];
<clever> and that would have bricked nixos
<clever> gchristensen: DO also needed this, because you could pause/resume, or even duplicate a VM, and the IP would change
<clever> yeah, thats exactly what DO's script does
<clever> func fetchMetadata() (metadata *Metadata) { setupLinkLocalNetworking()
<clever> gchristensen: something you may need to confirm with packet.net admins, but i think you could link-local it (169 ip)
<clever> edef: oh, that was you in the nixops issue over 2 years ago! heh
<clever> gchristensen: that will then query http://something/metadata/v1.json, find out what IP it should have, and generate systemd units automatically
<clever> gchristensen: it disables dhcp, and runs systemd-digitalocean-generator on bootup
<clever> gchristensen: and packet.net does have similar api's
<clever> gchristensen: the digital ocean thing i linked above, is a systemd service that will configure the network on bootup, without baking it in
<clever> gchristensen: i could see some less experienced users just breaking everything if they copy a configuration.nix over, and dont import your auto-generated stuff, and having it auto-config on bootup
<clever> gchristensen: the network auto-config could help others too, less to bake into your configuration.nix files
<clever> gchristensen: i think packet.net can do similar? and you could just auto-config the network on boot, without having to bake it in
<clever> gchristensen: this is a systemd service, that will query the instance data on bootup, and configure the right IP
<clever> gchristensen: that reminds me, there was a similar solution for digital ocean, let me find it...
<clever> gchristensen: i can see some issues with recv, since the IP's still have to be customized
<clever> gchristensen: also on the subject of packet.net, what do you think about `curl | zfs recv` vs `nixos-install` ?
<clever> gchristensen: and then use one of the sd-image scripts as an example to fix the bootloader, so it can boot
<clever> gchristensen: lines 39-71 of my gist dont care about the target arch, you just need to swap out the config.system.build.toplevel reference (or force lines 37&33 to use an x86 pkgs on an arm build)
<clever> raboof: builtins.placeholder "out"
<clever> ikwildrpepper: youll likely have less to change, since my gist is already able to generate and upload working AMI's, i forget what was left to finish
<clever> gchristensen: you might be able to get away with using an x86 runInLinuxVM to generate an arm image, the only tricky part is line 72 of my gist, where you fix the bootloader
<clever> gchristensen: ive been curious if 32bit zfs would work better there, since it has less ram and the heap size stuff wouldnt be an issue
<clever> gchristensen: ah, ive wanted that too, but havent looked into it yet
<clever> ikwildrpepper: what where you thinking of with zfs disk images?
<clever> gchristensen: its loosely based on the AMI generation, but amazon-image.nix is problematic, it has both aws things and ext3 things mixed together
<clever> gchristensen: https://gist.github.com/cleverca22/db751e05561e7c74a1f1121242b00985 is the most recent version i think
<clever> gchristensen: yes
<clever> jschievink: the moment you start using the arch gcc, nix has lost control and cant stop you from doing things the wrong way
<clever> jschievink: and installing any compiler tools will not work with nix, you must always build inside nix-shell or nix-build
<clever> jschievink: you must use cc-wrapper (a shell script around gcc) for things to correctly use nix
<clever> jschievink: was it built manually or with nix-build?
<clever> jschievink: is the nix sandbox enabled?
<clever> jschievink: sounds like you used the wrong -L flags when compiling
<clever> CptCaptain: restarting wont make much of a difference
<clever> jschievink: yes
<clever> jschievink: nix is supposed to ignore the dynamic libraries the host provides, but LD_LIBRARY_PRELOAD can leak in
<clever> CptCaptain: you have to manually `systemctl start sshd.service` until you stop including the installer profile
<clever> CptCaptain: it may have already had ssh enabled, but auto-start disabled
<clever> CptCaptain: and is this on the installer iso or a normal install of nixos?
<clever> CptCaptain: try `systemctl status sshd.service` ?
<clever> CptCaptain: does sshd.service exist in /etc/systemd/system/ ?
<clever> tilpner: :D
<clever> mananamenos: if you replace a few characters with 0's, it will try to download and find the real hash
<clever> mananamenos: because you lied to nix and claimed that the output has the same hash
<clever> mananamenos: if it can find something with the given sha256 in /nix/store, it will blindly use that, even if its an older version
<clever> mananamenos: if you want the dart binary, then you need `nix-shell -I nixpkgs=. -p dart`
<clever> mananamenos: and you want to aim nix-shell at the default.nix in the root of the repo, `nix-shell nixpkgs/default.nix -A dart`
<clever> mananamenos: you need all of the other nix files in that nixpkgs rev, or the versions wont line up right
<clever> mananamenos: do you want to build dart or use dart?
<clever> srid: `nix-env -q` will list the package names
<clever> srid: you must uninstall the conflicting package with `nix-env -e name`
<clever> gchristensen: mksquashfs is also very good at hammering all cores, so you could forward it to a machine with lots of cores
<clever> gchristensen: i think you can change the block size with squashfs, which would make it compress faster (but not as much)
<clever> yep
<clever> christianpoveda: as root, nix-channel --add https://nixos.org/channels/nixos-unstable nixos, then nix-channel --update
<clever> the rollback stuff makes it easy to undo things if the rolling-release does break things
<clever> christianpoveda: i also use nixos-unstable on all of my machines
<clever> it could have also just been a single let block with a bunch of cross-referencing functions
<clever> the kexec stuff is using it a bit differently, i'm just abusing it as a fixed-point thing, so i can change a number of variables
<clever> nh2: so you can now build daedalus installers, from the wallet repo, without having to commit wallet, push wallet, then update the pin in daedalus
<clever> nh2: but for testing purposes, this makes wallet depend backwards on daedalus, and overrideScope itself in
<clever> nh2: normally, daedalus depends on wallet, to build installers
<clever> i use that pattern any time i'm making a file with more then 2 expr
<clever> nh2: using newScope and makeScope together, you can create a new set of packages, that automatically gets its own scoped callPackage and overrideScope'
<clever> nh2: one other thing...
<clever> others left it as overrideScope
<clever> some sets renamed it to extend
<clever> but i think overrideScope had a typo (self/super swapped) and they had to make a ' version to fix it
<clever> yeah
<clever> i'm also not sure why there is both overrideScope and extend