<disasm>
we're having the hardest time cracking that 500 PR barrier
<disasm>
Every time I think we're close we get 10 more, lol
<disasm>
also, just so I understand correctly... grahamcofborg build essentially does a nox review building anything touched by that PR and nixborg only builds packages that are in unstable-small right?
<vcunat>
disasm: I think grahamcofborg doesn't build packages automatically, only does some checks, e.g. rebuild amount, evaluation, etc.
<vcunat>
but it can be instructed to build
JosW has joined joined #nixos-dev
<gchristensen>
grahamcofborg also doesn't do a nox-review, it builds only specifically listed packages
<disasm>
ah, cool, that's a little less scary then :)
<gchristensen>
yeah, it is because people run the builder on their laptops, so #1: don't want to build every PR that comes through without manual review, and #2 don't want to build every changed package to be polite to the host
<rycee>
It complains about a segfault but I cannot reproduce locally.
mbrgm has quit [(Ping timeout: 248 seconds)]
mbrgm has joined joined #nixos-dev
<disasm>
gchristensen: did I do this right to build this packages? I'm not familiar enough with emacs ecosystem: @GrahamcOfBorg build emacsPackagesNg.melpaPackages.pdf-tools -- https://github.com/NixOS/nixpkgs/pull/31561
<disasm>
guessing not since the version it built doesn't have the right version number in it
<gchristensen>
I don't know, you'll have to figure out what attr it touches and then ask for that
FRidh has quit [(Remote host closed the connection)]
FRidh has joined joined #nixos-dev
<rycee>
Thanks to whoever restarted the protobuf job! Seems it resolved the build. Is there any way to also rebuild packages that depend on this python protobuf package?
orivej has quit [(Quit: No Ping reply in 180 seconds.)]
orivej has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
FRidh has quit [(Remote host closed the connection)]
vcunat has quit [(Ping timeout: 246 seconds)]
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
<copumpkin>
orivej_ Dezgeg: when you say it's impossible to create a deterministic ext4 partition
<copumpkin>
had you already tried with cptofs/lkl?
<copumpkin>
it seems like the mkfs.ext4 could at least try to be deterministic, and we could improve things over time when populating the fs
<copumpkin>
(re: putting faketime on mkfs.ext4, and possibly setting a fixed UUID)
<Dezgeg>
well, for starters mkfs.ext4 calls rand() :)
<Dezgeg>
even with a fixed UUID
<copumpkin>
lol
<copumpkin>
what for>
<Dezgeg>
I can't recall but I would guess for the per-directory hash seeds (to avoid collision attacks)
<copumpkin>
ah
<copumpkin>
so we patch it to optionally take a random seed in an env var? :D
<gchristensen>
gotta be real careful there
<copumpkin>
pfft, DOS
<Dezgeg>
well, presumably anybody wanting to try that could even currently download say, the ec2 base image from hydra and read the hash from the image
<copumpkin>
yup
phreedom has quit [(Quit: No Ping reply in 180 seconds.)]
<vcunat>
reproducibility has its downsides
<gchristensen>
maybe a special mkfs.ext4 for that use case?
phreedom has joined joined #nixos-dev
orivej has quit [(Quit: No Ping reply in 180 seconds.)]
orivej has joined joined #nixos-dev
vcunat has quit [(Quit: Leaving.)]
<gchristensen>
yikes another eval break introduced
<copumpkin>
how?
<gchristensen>
undefined variable ‘maintainer’ at /tmp/nix-rebuild-amount-rYaLJHav/pkgs/development/libraries/libbsd/default.nix:23:24
<gchristensen>
my checks find this problem, but don't _report_ this problem: the hydra rebuild amount calculator finds and reports the bug but then happily reports that 0 drvs were changed
orivej has quit [(Ping timeout: 268 seconds)]
<copumpkin>
it's off by default because it slows down eval
<gchristensen>
(instead of erroring out)
<gchristensen>
is there another way to check for this issue?
<gchristensen>
I'll add an eval check tonight :)
<copumpkin>
bad meta?
<copumpkin>
just set config.checkMeta = true
<gchristensen>
I mean ... hrm ...
<gchristensen>
I guess I'm wondering why my existing tools didn't find that error
<gchristensen>
but the hydra rebuild calculator did
<copumpkin>
if you're just asking for .drvs (as rebuild-amount is probably doing) you won't catch meta issues
<gchristensen>
but it _DID_ find this issue
<copumpkin>
hydra evaluator forces the meta attrset
<LnL>
the tarball eval doesn't look at maintainers