| 17 Aug 2022 |
 @linus:schreibt.jetzt | You can also combine the impure path with a system feature which is required by the derivations, so people (and hydra) don't "accidentally" try to build them on a system that doesn't have the toolchain set up appropriately | 10:25:51 |
| @linus:schreibt.jetzt | And with impure-paths you can literally use a binary cache as opposed to just binary-cache style ;) | 10:26:18 |
 @leons:is.currently.online | Hm, that does indeed sound like a rather elegant solution. Forces users to install the toolchains to a fixed path though, if they want to obtain the (input-hash) identical derivations though, right? | 10:27:04 |
| @linus:schreibt.jetzt | No, if they use the binary cache they can get them from there | 10:27:29 |
| @linus:schreibt.jetzt | (but yes if they want to build them locally) | 10:27:41 |
| @leons:is.currently.online | Thanks for this advice! I'll see how I can make it work :D | 10:29:52 |
|  enemycube joined the room. | 17:03:16 |
|  Brad Bondurant joined the room. | 17:25:07 |
| Brad Bondurant | +1 for extra-sandbox-paths, also check out buildFHSUserEnv for running binaries that expect FHS paths to be present. Here's an example environment for Vivado https://git.m-labs.hk/M-Labs/nix-scripts/src/branch/master/artiq-fast/vivado.nix | 17:31:01 |
| Brad Bondurant | Also, has anyone figured out a good way to do proper CI/CD with Hydra using flakes? I have several repositories, each with their own flake, and then a central flake that pulls them in and defines the hydraJobs. With legacy builds it was easy - just specify a repository as an input, and as long as the revision isn't pinned then any new commits will trigger a build. In addition to the restrictive lock flags Hydra uses (https://github.com/NixOS/hydra/issues/1160), it seems that flake support is just... bad. e.g. flake inputs aren't even recorded in Hydra's DB. I've been working on patches to Hydra to allow "unlocked" flakes, but that's a good chunk of work and I'm wondering if I can hack something else together more easily. | 17:38:11 |
| Brad Bondurant | One idea I've had is to have a separate jobset that just does something like a nix flake update and copies the flake.nix and flake.lock to the output, and then use that flake as the input for the real jobset, but I'm not sure if that's doable | 17:40:03 |
| Brad Bondurant | And the absolute hackiest idea I've had is to put the flake in a local file on the server and make a cron job that updates it periodically | 17:42:07 |
 cransom | i don't know if i'm up to date with all the methods, but i think the current general practice was something like your cron job - another task that runs nix flake update, commits, and pushes. | 17:44:50 |
| Brad Bondurant | that's a bummer :/ talk about a messy git history | 17:47:57 |
|  greaka joined the room. | 20:18:07 |
|  @denna:matrix.org joined the room. | 22:09:00 |
| 18 Aug 2022 |
|  Florian | W3F changed their profile picture. | 09:20:15 |
 @grahamc:nixos.org | Brad Bondurant: we made this a bit ago to make that easier, maybe it'll help you: https://github.com/DeterminateSystems/update-flake-lock | 15:15:19 |
| Brad Bondurant | grahamc (he/him): Thank you! Funnily enough I had just settled on a very similar solution (my repos are on GitLab) and this'll be a great reference to have! | 15:37:23 |
| Brad Bondurant | In reply to @bradbqc1:matrix.org
+1 for extra-sandbox-paths, also check out buildFHSUserEnv for running binaries that expect FHS paths to be present. Here's an example environment for Vivado https://git.m-labs.hk/M-Labs/nix-scripts/src/branch/master/artiq-fast/vivado.nix Leon: just wanted to make sure you see this since I suspect there's a good chance you're using Vivado and there are other nix files in this repo that do exactly what it sounds like you're trying to do -- they build the bitstreams using Vivado and then publish them in a binary cache which users can then pull from without needing any Vivado stuff | 15:42:19 |
| @leons:is.currently.online | Brad Bondurant: that's a pretty good pointer, thanks! | 15:43:38 |
| @leons:is.currently.online | In case you care, this is my Vivado package currently: https://git.sr.ht/~lschuermann/nix-litex/tree/main/item/pkgs/vivado/vivado-2020_1.nix | 15:44:42 |
| @leons:is.currently.online | It's been working well for me, and has less quirks that one might think, but yeah it's a slight hassle to get the installer into the Nix store and has the redistribution / cache issues where you really don't want Xilinx to get angry at you for mirroring their software :) | 15:46:09 |
| Brad Bondurant | Oh wow, you wrote a whole derivation for Vivado -- impressive lol. We just use the FHS environment to run the provided installer (and resulting binaries) and then extra-sandbox-paths to make it usable from within a build | 15:48:50 |
| @leons:is.currently.online | Yeah, that is indeed much saner, but spending 2 days running the Vivado installer in a Nix derivation until it works tracks for me :D it's originally based on https://github.com/lukaslaobeyer/nix-fpgapkgs | 15:55:11 |
| @leons:is.currently.online | * Yeah, that is indeed much saner, but spending 2 days running the Vivado installer in a Nix derivation until it works tracks for me :D it's originally based on https://github.com/lukaslaobeyer/nix-fpgapkgs (Brad Bondurant this isn't really on topic for Hydra anymore, sent you a DM) | 15:56:31 |
|  @rimuru:gentoo.chat changed their profile picture. | 16:51:22 |
| 19 Aug 2022 |
|  kayla (she/they) changed their display name from kayla.fire to kayla (she/they). | 01:39:48 |
 K900 | In reply to @k900:0upti.me
OK whomst do I poke here to get https://github.com/NixOS/hydra/pull/1243 merged Bump again : | 08:38:07 |
| K900 | In reply to @k900:0upti.me
OK whomst do I poke here to get https://github.com/NixOS/hydra/pull/1243 merged * Bump again :P | 08:38:08 |
