<jtojnar>
it would allow us to clean up the patches at least
vcunat has joined joined #nixos-dev
vcunat has quit [(Client Quit)]
ma27 has joined joined #nixos-dev
ma27 has quit [(Ping timeout: 255 seconds)]
vcunat has joined joined #nixos-dev
orivej has quit [(Ping timeout: 248 seconds)]
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
orivej has joined joined #nixos-dev
phreedom has joined joined #nixos-dev
<orivej>
this is still relevant: all remaining nixpkgs:staging:*.x86_64-linux builds at https://hydra.nixos.org/machines are hung. may you cancel them?
<orivej>
vcunat: ^
orivej has quit [(Ping timeout: 240 seconds)]
orivej has joined joined #nixos-dev
<vcunat>
One build step is reportedly running for 26 days.
<vcunat>
I think these long-term hangs only started appearing recently.
<vcunat>
Previously it seemed that Hydra was time-outing them all properly.
<vcunat>
I cancelled steps running around day or more, where I had rights (nixos and nixpkgs projects).
<vcunat>
Some disappeared from the list, but most didn't.
FRidh has joined joined #nixos-dev
<LnL>
yeah, the macs had a similar problem a week or so ago
_ts_ has joined joined #nixos-dev
<vcunat>
I'm afraid that the remaining 3.8k x86_64-linux jobs in that evaluation won't continue, ever.
<fpletz>
vcunat: we're also seeing this on our private hydra instance, looks like a recent hydra upstream change
<fpletz>
restarting hydra-queue-runner fixes the issue temporarily, though
<fpletz>
niksnut: ping :)
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
<srhb>
Hi! I'm looking to apply for merge rights. I've done mostly small driveby contributions, but I've begun taking over maintainership on some smaller modules, and I think I'm a responsible and cautious person with regards to NixOS. :-)
<gchristensen>
cc domenkozar ^ can you give srhb and jtojnar commit bit? :)
bkchr has joined joined #nixos-dev
phreedom has joined joined #nixos-dev
fpletz has quit [(Ping timeout: 240 seconds)]
fpletz has joined joined #nixos-dev
rsa has joined joined #nixos-dev
<fpletz>
yeah, also in favour of giving srhb & jtojnar push access :)
fpletz has quit [(Changing host)]
fpletz has joined joined #nixos-dev
<orivej>
I also nominate adisbladis, if he wants to.
<gchristensen>
oh yeah
<MichaelRaskin>
Or the vanity script could be run to see if someone got forgotten.
<adisbladis>
orivej: I'd love to :)
<fpletz>
ack! :)
<gchristensen>
heads up y'all: @grahamcofborg can take another command, "eval", to re-trigger evals. editing a PR description will no longer trigger a new eval check. please see: https://github.com/grahamc/ofborg#commands
ma27 has joined joined #nixos-dev
<gchristensen>
another problem to solve is getting more workers for the eval checks, that is often bottlenecked
<vcunat>
the dependency on gnome-backgrounds seems a little weird, though
<jtojnar>
so a derivation is only added to the runtime closure when the path can be grepped in the package?
<vcunat>
15MB of images seem a bit strange to justify as a build helper
<vcunat>
jtojnar: the notion of runtime closure is defined by mutual references
<vcunat>
(of the hash-parts, those after /nix/store/)
<vcunat>
It doesn't always work, like for *.jar but it's surprisingly good in practice.
<jtojnar>
so if I understand it correctly the wrapGAppsHook will then add it to the runtime closure of packages depending on gtk3 but gtk3 itself will be free?
goibhniu1 has joined joined #nixos-dev
<vcunat>
well, the point is that the gtk3 build creates several "outputs"
<vcunat>
but only the one with libraries remains in most closures
goibhniu has quit [(Ping timeout: 264 seconds)]
<vcunat>
$dev will typically only be used during builds
<vcunat>
(but some derivations do "misbehave" and keep a reference to $dev outputs)
<jtojnar>
yes, but if I add the schemas to propagatedBuildInputs, it will be stored to nix-support/propagated-build-inputs
<jtojnar>
from there added to buildInputs of packages depending on gtk3
<jtojnar>
If we do not want to add backgrounds to every GTK application we could split the schemas package (but that will probably be nasty)
<jtojnar>
or we could eschew the default backgrounds, since they are replaced anyway by the nixos module
<jtojnar>
vcunat: and now I am really confused by nativeBuildInputs
<jtojnar>
if the mutual reference is what decides on inclusion to the closure
taktoa has quit [(Remote host closed the connection)]
<jtojnar>
s/closure/runtime closure/
<vcunat>
jtojnar: you don't need to distinguish between native and non-native inputs
<vcunat>
as long as you don't want to cross-compile
<jtojnar>
I keep moving the build tools like meson, ninja, gobjectIntrospection to nativeBuildInputs
<vcunat>
"(non)native" is much more about whether it should be run by the builder or the target system, which matters e.g. if they have different architectures
<vcunat>
yes, correct
<vcunat>
well, not for the introspection
<vcunat>
most likely
<vcunat>
That contains libs to be used during runtime, does it not?
<vcunat>
But anyway, who is going to cross-compile gnome apps? I don't think we need to worry at this point.
<jtojnar>
I meant when generating the gir files
<jtojnar>
for apps that use the library, I am keeping it in buildInputs
<vcunat>
OK
<vcunat>
Then it's a package that might need to be in both in some cases, as it is packaged now.
<vcunat>
But I haven't seen people cross-compiling such big apps anyway.