<aminechikhaoui>
so I'm struggling with something and looking for ideas, I started using https://github.com/manveru/nix-inclusive in a project to limit files that can trigger rebuilds but with hydra inputs that doesn't really help :/
<aminechikhaoui>
as hydra relies on nix-prefetch-git so with every revision change even when the relevant files for build do not change, filter source would generate a new src path
<aminechikhaoui>
anyone has a trick to limit rebuilds with a Hydra context ?
<cole-h>
Yayyyyy, nixpkgs-20.09-darwin finally appeared on s.n.o!
<cole-h>
The only outstanding "issue" with s.n.o is the lack of "EOL" labelling on 19.09.
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
rajivr has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej_ has quit [Ping timeout: 258 seconds]
LnL has quit [Quit: exit 1]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
<samueldr>
someone with triage rights on the Nix repo will need to close and mark as invalid nix#4096 ... what a waste of such a good round numbe
<flokli>
niksnut: TLDR: upstream introduced a circular dependency between out and lib, as libsystemd started to provided some path lookup stuff inside libsystemd
<flokli>
we might be able to patch these paths to /run/current-system instead, but I'm not entirely certain about other implications
<flokli>
(which should be documented in further detail in that issue)
<niksnut>
it increases the closure size of packages like emacs by 85 MiB (especially because systemd depends on another copy of systemd for some reason...)
<niksnut>
it's even worse, for instance everything that depends on dbus now depends on two copies of systemd
<worldofpeace>
yorick: I didn't see the other link a changelog or mention what changes happened. usually the best way to be sure about merging an update is to look at that (if there is one)
<worldofpeace>
* I didn't see a link to
<yorick>
someone made the usual r-ryantm pr manually, probably to get a t-shirt
<yorick>
I should add passthru.tests to it
<yorick>
oh, r-ryantm broke because it renamed from VictoriaMetrics to victoriametrics
<worldofpeace>
yorick: even if it was a hacktoberfest PR it was an acceptable one
<yorick>
yep, very much so
<yorick>
just a waste of humanity's effort :P
<worldofpeace>
(not like some terrible halloween trick)
<aminechikhaoui>
niksnut what if there was a builtins.fetch<something> that generates a content addressable store path out of an input path, which we could use for hydra inputs
<{^_^}>
nix#4097 (by jorsn, 14 hours ago, open): support arbitrary files in flakes or filter them out
<ryantm>
yorick: The Repology source is a lot more laggy and picky than the GitHub one though, because it has to wait for the unstable channel update and then the version in master has to exactly match what Repology has.
timokau[m] has joined #nixos-dev
<aminechikhaoui>
I don't know if that idea solves the problem I have, but basically what I want is a filter(dir, allowedPaths)->out, where out is the same as long as the allowedPaths in the filter didn't change even if the `dir` directory had other changes
<timokau[m]>
This eval error looks like an ofBorg fluke to me, is that right? Safe to ignore?
<aminechikhaoui>
so I guess that will require some hash calculation of the allowed paths or generating a store path that is content addressable out of that filter
<gchristensen>
timokau[m]: eval errors are almost never faulty, and almost never safe to ignore
justanotheruser has joined #nixos-dev
<timokau[m]>
gchristensen: That's why I'm asking. The error complains about something with pandoc though, which seems entirely unrelated to the PR. I was thinking that there might have been an issue on master 26 days ago when the PR was created.
<timokau[m]>
I did, and a bunch of eval-subtasks passed near-immediately. The main "grahamcofborg-eval" stays red though. Or does it just take a while for the status to be updated?
<timokau[m]>
I assumed that the old status would be invalidated immediately and replaced by a pending one, but that might be wrong now that I think about it
alp has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
alp has joined #nixos-dev
<niksnut>
I'm trying to backport digikam 7.1.0 to 20.09, since digikam 6.4 is broken
<niksnut>
however, the unpackPhase fails with: /nix/store/333six1faw9bhccsx9qw5718k6b1wiq2-stdenv-linux/setup: line 834: /nix/store/9x8vjfxjz2wv7xb90vwv5i697z6gr7d2-xz-5.2.5-bin/bin/xz: Argument list too long
<niksnut>
which appears to be because the environment is too big
<niksnut>
and all those cmake hooks do generate enormous environment variables
<niksnut>
anybody know why this doesn't happen on master?
<niksnut>
okay, it's probably because there are multiple versions of qt in the input closure
<niksnut>
as a result a variable like CMAKE_PREFIX_PATH is 95 KB on master, but 132 KB on 20.09
orivej has quit [Ping timeout: 260 seconds]
ris has joined #nixos-dev
cole-h has joined #nixos-dev
hax404 has quit [Remote host closed the connection]
hax404 has joined #nixos-dev
hax404 has quit [Remote host closed the connection]
hax404 has joined #nixos-dev
<cole-h>
worldofpeace / yorick: I'm actually inclined to say it's a Nixpkgs problem (related to https://github.com/NixOS/nix/issues/4003) -- pkgs/top-level/default.nix should have an ellipsis to fix this.
<{^_^}>
nix#4003 (by Ma27, 3 weeks ago, open): `nix-shell` breaks with an eval-error in `nixpkgs` with Nix 3.0pre
<cole-h>
Rather, the problematic arg, `supportedSystems` is used there ^
gleber has quit [*.net *.split]
thonkpod has quit [*.net *.split]
rajivr has quit [*.net *.split]
georgyo has quit [*.net *.split]
teehemkay has quit [*.net *.split]
thoughtpolice has quit [*.net *.split]
angerman has quit [*.net *.split]
michaelpj1 has quit [*.net *.split]
stew has quit [*.net *.split]
fadenb has quit [*.net *.split]
michaelpj1 has joined #nixos-dev
thoughtpolice has joined #nixos-dev
georgyo has joined #nixos-dev
teehemkay has joined #nixos-dev
angerman has joined #nixos-dev
gleber has joined #nixos-dev
thonkpod has joined #nixos-dev
fadenb has joined #nixos-dev
stew has joined #nixos-dev
<cole-h>
timokau[m]: btw, ofborg doesn't clear any of its statuses when it's told to re-eval, so you just have to wait (in fact, it looks like ofborg is done now, sans the darwin check)
<timokau[m]>
cole-h: Thanks! Looks like this doesn't play well with the wait-for-borg action, but that's probably a not too important edge case
* cole-h
is personally not a fan of the wait-for-borg action anyways.
<timokau[m]>
Are the nixos org invites for maintainers still going on? (cc gchristensen)
<timokau[m]>
cole-h: Its a bit weird that it is red-by-default instead of pending-by-default
<{^_^}>
rfc39#3 (by cole-h, 1 week ago, open): Create a database of already-invited users and don't invite them again
saschagrunert has quit [Quit: Leaving]
<timokau[m]>
gchristensen: Ah, thanks. Is it possible to invite people manually?
<cole-h>
Yes, but needs org owner intervention IIRC.
<gchristensen>
it would be really nice if somebody fixed that issue
<gchristensen>
manually managing the invitations isn't very practical imo
<cole-h>
I'm planning on it, but free time is at a premium due to school + work x)
<gchristensen>
yeah understood
<timokau[m]>
Yeah, agreed that it would be nice ;) Unfortunately I'm (perpetually, it seems) in avoid-new-commitments mode.
<gchristensen>
sounds healthy :)
<timokau[m]>
Still if someone with the right permissions reads this: I would like turion and glittershark invited. They're helping me test marvin-mk2 and it would make things easier if they were org members (assignees, reviwers, all the reasons we started the rfc in the first place)
<samueldr>
worldofpeace: that's not designer intricacies though, that's good concern
<samueldr>
also why I asked, had *some* reservations about the pose, but not enough to block
<samueldr>
its scream, to me, screams powerfully
<samueldr>
or is it singing?
<worldofpeace>
hmm, now that u mention it it's now for being a songbird and they assume that pose
<worldofpeace>
* it's known
<worldofpeace>
I just think maybe it's not very "pretty" (well it is a bird). I just think that pose shows off more aesthetically pleasing features like the wing and tail feathers.
<samueldr>
I can see how both can be observed, that's why I didn't mention my reservation beforehand
<samueldr>
I think mog works from public domain illustrations, not 100% positive on that
<samueldr>
so it might limit availability
alp has joined #nixos-dev
<worldofpeace>
that is true. I figure if it's unreasonable they'll tell me