<LnL>
ikwildrpepper: hi, do you know who got us the macstadium builder and who has access to it?
<domenkozar>
oh I broke 18.03
<domenkozar>
:o
<domenkozar>
niksnut: yeah we figured at iohk that fixed-output derivations are a glorified remote shell exploit
<domenkozar>
niksnut: so fetchcargo uses a Cargo.lock from nix store?
<domenkozar>
btw yarn2nix works the same way
<niksnut>
yes (i.e. $src/Cargo.lock)
<clever>
one issue i noticed, is how paths are treated in nix
<niksnut>
I added a builtins.fromTOML btw
<clever>
if you pass mkYarn2nix a `src = ./.;` and then mkYarn2nix does `src + "/package.json"`, it will make a new path, and import the json file directly into the store
<clever>
so it only rebuilds when the json changes
<niksnut>
this should enable Cargo.lock to be processed in a more pure way (relying only on fetchurl)
<clever>
but if you instead do `src = lib.cleanSource ./.;`
<clever>
then the `src + "/package.json"` is appending a string to a storepath, so it doesnt re-import package.json
<clever>
the derivation now depends on the entire src, and rebuilds constantly
<domenkozar>
well sometimes you want one or the other
<clever>
the difference is that `./. + "package.json"` will turn a path into a path, then import just the file
<clever>
and `(lib.cleanSource ./.) + "/package.json"` knows the left half is already immutable, so it doesnt bother importing the file again
<domenkozar>
yeah
<domenkozar>
although best to use builtins.path
<domenkozar>
if you don't need Nix 1.x comp
<clever>
luckily, mkYarn2nix has an attribute to specify custom paths to package.json, so i can just packageJson = ./package.json;
<clever>
and then it does minimal rebuilds
<infinisil>
This lib.filterSource method of filtering files is horrible imo
<infinisil>
I always spend like 15 minutes just to relearn how to nicely filter what I want gone. I wouldn't mind a less flexible but easier to use alternative
<clever>
but if the tree is dirty, it returns zero information about the rev it has checked out
<infinisil>
Ohh neat
orivej has joined #nixos-dev
<gchristensen>
maybe we could get some branded yubikeys :)
<adisbladis[m]>
I have some connections there :)
pierron has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
ixxie has joined #nixos-dev
adisbladis has joined #nixos-dev
<infinisil>
How much testing should be done before merging a version update?
<infinisil>
E.g. #43008 (and lots of other r-ryantm updates), this looks fine to me, it's a library too, so probably it compiling just means that it works
<infinisil>
Should these minor updates (even with binaries) be merged even without proper testing in the hopes that the minor update couldn't have broken too much? And deal with breakages as they come (get reported)?
<gchristensen>
probably just as much testing as any other pr
<infinisil>
gchristensen: "As much as any other pr", there are PRs that require more testing than others though
<infinisil>
E.g. I wouldn't wanna test a doc update or a minor version update as much as a change to grub's module
Lisanna has joined #nixos-dev
jtojnar has joined #nixos-dev
phreedom has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
<Profpatsch>
infinisil: There is a library that does what you want.
<Profpatsch>
You can always specify more general behavoir.
<Profpatsch>
infinisil: Sorry, I meant library function
<infinisil>
Oh for the filtering?
<Profpatsch>
sourceByRegex in lib/sources.nix
<infinisil>
Neat!
<infinisil>
That's probably exactly what I was looking for, but the fetchGit way is probably even neater
<infinisil>
Since you don't need to specify everything twice (assuming .gitignore is exactly the same as what you actually want to ignore)
ixxie has quit [Ping timeout: 240 seconds]
<orivej>
infinisil: re. ryantm updates, we often do not have to do any testing at all if the update is trivial and the bot output is expected. it is still good to wait a bit for meta.maintainers to notice the update and do their own testing; and those who merge PRs should monitor https://hydra.nixos.org/jobset/nixpkgs/trunk for new breakages in the next evaluation after the merge.
<gchristensen>
orivej++
<{^_^}>
orivej's karma got increased to 1
<gchristensen>
nice to see you on IRC! =)
<orivej>
thanks!
<infinisil>
orivej: All right thanks, I'll try to keep an eye on that :)
drakonis has joined #nixos-dev
ixxie has joined #nixos-dev
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
disasm has quit [Ping timeout: 260 seconds]
disasm has joined #nixos-dev
<dtz>
gchristensen: omg I'd love a branded yubikey haha :D
drakonis has quit [Read error: Connection reset by peer]
<gchristensen>
niksnut: I'm going to go ahead and revert that in ~25min if I don't hear back
aristid has quit [Ping timeout: 268 seconds]
aristid has joined #nixos-dev
<gchristensen>
ok here goes
<niksnut>
what's the problem?
<gchristensen>
nix-instantiate ./pkgs/top-level/release.nix -A tarball -> error: access to URI '/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci' is forbidden in restricted mode
<niksnut>
eh
<niksnut>
isn't that an ofborg problem?
<gchristensen>
well, it may be something we should fix in ofborg
<gchristensen>
https://github.com/NixOS/nixpkgs/pulls but we should probably revert the commit so PRs can be green again, so people retain their trust in ofborg, until ofborg can be fixed
<gchristensen>
which is my proposal -- reverting until ofborg passes the nixpkgs arg on each call
<LnL>
what's the benefit of copying nixpkgs to the store when using release.nix?
<niksnut>
it ensures an unpolluted tree
<niksnut>
sorry, that was the answer to "why use fetchGit ./."
<niksnut>
nixpkgs needs to be copied because it's an input to makeTarball
<gchristensen>
does that sound acceptable for at least the next few hours or next day?
<LnL>
hmm, but hydra won't use that either right?
<niksnut>
no
<niksnut>
it's for local use
<niksnut>
e.g. when you do nix-build release.nix -A makeTarball
<LnL>
kk, should be pretty easy to do the same with ofborg
<gchristensen>
niksnut: I'm going to take this as an OK for reverting, with the plan to revert-the-revert ASAP
<niksnut>
meh, it's not really important
<gchristensen>
ofborg should handle it, it is definitely a bug :)
<LnL>
what me to make a pr or are you already looking into it?
<gchristensen>
if you can, please do!
<LnL>
kind of waiting for a clang build anyway :)
clever has quit [Ping timeout: 240 seconds]
clever has joined #nixos-dev
clever has quit [Changing host]
clever has joined #nixos-dev
<LnL>
using <nix/config.nix> looks completely broken on my desktop