<gchristensen>
I did a thing as a quick two-evening hack, calculating how reproducible our minimal ISO is. Out of 1,244 build steps, 1,225 are bit-for-bit reproducible (98.473%)! check it out https://r13y.com/
<thoughtpolice>
gchristensen: That's an awesome domain name to snag for that, imo
<gchristensen>
thanks :)
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 268 seconds]
lassulus_ is now known as lassulus
pie__ has joined #nixos-dev
pie___ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 244 seconds]
lassulus has quit [Quit: WeeChat 2.2]
__Sander__ has joined #nixos-dev
<Taneb>
I'm a little surprised that the manual isn't reproducible
<clever>
Taneb: the inter-section links use randomly generated id's to make them unique
<Taneb>
clever: :(
<clever>
Taneb: i'm not entirely sure what the rules are, but the weird part is that only a small number of the links vary in a few digits
lassulus has joined #nixos-dev
<timokau[m]>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 69
<timokau[m]>
We could probably just fix the seed right?
<tilpner>
Only if it's single-threaded and doesn't use the same rng for anything else
<tilpner>
And at that point, you might as well use a sequential counter for id allocation
<timokau[m]>
Yeah, or some sort of hashing
<tilpner>
(And doesn't have any iteration order indeterminism. I probably forgot something else)
<clever>
tilpner: that reminds me, the json encoder in perl (and used by hydra) is non-deterministic
<clever>
tilpner: that resulted in the PR fetching stuff generating a "different" json every time, and flooding hydra with new evals
<tilpner>
Well, that's great :(
<clever>
i added a jq invocation, to sort all json objects by key
<Profpatsch>
gchristensen: Awesome!
<Profpatsch>
This also shows that early cutoff would gain us a *lot*
<Profpatsch>
(although everything that depends on these unreproducible compilers directly would need to be rebuilt)
<Profpatsch>
(So maybe not all that much since gcc is in that list)
Jackneill has quit [Ping timeout: 240 seconds]
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
LnL has quit [Ping timeout: 245 seconds]
<timokau[m]>
Debian has a ton of patches for gcc, does anyone know if their gcc is reproducible?
<ekleog>
gchristensen: do you have some procedure to get the diffoscope? it'd be nice to have it, so as to be able to check locally are fixed
<ekleog>
(me learns grammar and come back) so as to be able to check locally that things are fixed after a supposed reproducibility-fixing change
<gchristensen>
like how to use diffoscope?
<ekleog>
(also, after disorderfs the next step is integrating a “check reproducibility” phase to ofborg :D)
<ekleog>
like, how to trigger two builds and diffoscope
<gchristensen>
oh I see
<gchristensen>
you're asking the question of "I think I fixed it, how do I check it like r13y.com does"?
<ekleog>
I assume you can't just use --check as it'd fail
<ekleog>
yup
<gchristensen>
great question
<ekleog>
well, especially for “I think I fixed part of it”, as if I think I fixed it all I can just --check (though it wouldn't check two kernel versions I couldn't really do it anyway, I'm running only one) ; like if I add some faketime to the perl builder, how do I check the only remaining impurity is the kernel version one
<gchristensen>
right
<gchristensen>
btw, I fixed perl already
<ekleog>
\o/
<gchristensen>
I'm writing some instructions
<ekleog>
♥
<arianvp>
gchristensen: I saw you're working o. T
<arianvp>
On this reproduciblity checker
<arianvp>
Are you aware nix 2.0 can run diffoscope as a hook?
<gchristensen>
I published a report
<gchristensen>
I do know that :)
<arianvp>
At least,in theory. It's currently broken :D
<gchristensen>
I started playing around with a cute version of the NixOS logo being like ... photocopied, or slightly bitrotten, but nothing nice turned out so I didn't
<samueldr>
hm, I see nothing about cpu features, only a passing note... not sure how they verify it
<samueldr>
testing with sysbench, which ours may be failing... thinking about it it could be the embedded third-party luajit
<gchristensen>
samueldr: a slightly weird thing about debian's reproducible builds is some packages check in the results of configure
<clever>
i believe the cpuid opcode works by putting a special number into a certain register, and then running cpuid
<clever>
and the cpu will then fill in a bunch of registers with answers
<clever>
the KVM_SET_CPUID function in kvm, lets you supply a list of "questions" and the "answer" to each
<clever>
and kvm will fake things, when the guest tries to query
<clever>
2019-02-05 11:43:16 < clever> pm215: though, i notice its x86 specific, what does arm have in this region?
<clever>
2019-02-05 11:44:25 < pm215> arm doesn't currently support lying to the guest about its CPU identity
<clever>
2019-02-05 11:44:34 < pm215> (in the kernel; the architecture has facilities for it)
<gchristensen>
that'd be a really nice kernel patch
<clever>
2019-02-05 11:45:05 < clever> pm215: and at a hardware level, how does both arm and x86 do it? can the cpu trigger a fault when you try to query it? or is kvm rewriting opcodes in ram?
<clever>
2019-02-05 11:45:52 < pm215> dunno about x86; on arm the hypervisor sets control bits to enable traps when the guest tries to read certain ID registers; it can then emulate the insn
<clever>
gchristensen: so for x86, the #osdev guys say that kvm will set the page tables incorrectly (no-execute), and then when a fault occurs, it copy the page of ram, and replace all calls to cpuid, with trap opcodes
<clever>
for arm, the hypervisor flags in the cpu allow you to automatically fault out when trying to read the cpu registers, and then kvm could fake the answer (with a patch)
<gchristensen>
I've gotten confirmation that libvirt have a personality-like thing
<gchristensen>
poking the worksonarm bear about teaching the kernel directly
drakonis has quit [Quit: WeeChat 2.3]
<gchristensen>
clever: would you be interested in creating a nixos configuration which puts /nix on disorderfs?
<clever>
gchristensen: that sounds fun! :D
<gchristensen>
I thought you might like that ;D
<gchristensen>
if you do it, I'll set it up on the machine I run these tests from.
<ekleog>
suggestion: add r13y.com to the /topic
<clever>
gchristensen: related, local?root=/home/clever/, would let you disorder just a subset of your builds
<samueldr>
gchristensen: just so you know, I think the personality thing is different than masking cpu features (still would be immensely useful to have personality for 32 bits)
<gchristensen>
samueldr: no personality means it is hard to safely use 32b-capable machines in hydra :(
<clever>
samueldr: if a 32bit capable build slave is setup on hydra, some 32bit builds may detect the 64bit features, and upgrade the produced binaries
<samueldr>
gchristensen: hmm, aarch64 with aarch32 machines will emit code using aarch32 features? I thought it would only be useful the other way around
<ekleog>
gchristensen: :)
<gchristensen>
samueldr: not all aarch64 machines are 32b capable, so if something does decide to do that, it would be bad
<gchristensen>
but yes also the reverse
<samueldr>
yes, maybe I need to re-read the personality man page, maybe it also can handle that case of 64 software on no-32 hardware
<clever>
pkgs/tools/filesystems/disorderfs/default.nix: name = "disorderfs-${version}";
<clever>
gchristensen: dang, somebody beat me to it!
<gchristensen>
yeah, I know those tools
<clever>
git blame puts it in 2015!
<clever>
that at least makes things easy, just a nixos module then
<clever>
and i have done /nix/store/ on fuse before
<clever>
yuck, the src for disorderfs, lacks a root dir
<clever>
it just barfed all over one of my git repos
<clever>
it even overwrite my .gitignore!
<clever>
gchristensen: is /nix on its own filesystem, or part of the rootfs?
<gchristensen>
probably the rootfs
__Sander__ has quit [Quit: Konversation terminated!]
<gchristensen>
samueldr: that PR from tilpner lgty?
<samueldr>
need to look at it to say, like `make` the thing, and verify there is a decrease, but if it does what's on the tin, and jq was already a dep, gut reaction says it looks fine
<samueldr>
(jq is already a dep)
<tilpner>
I built packages.html and it seems to wor
<tilpner>
Wonder what that's for... so I can't even test the change properly
<samueldr>
iirc the python web server doesn't play well with the gz data, instead of sending it with the right headers so the browser handles it, it will use the .gz data compressed
<tilpner>
Ah, okay. It fails with file:// urls, works with python -m http.server
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
<ekleog>
Is there any reason not to have directory indexing turned on on releases.nixos.org?
<ekleog>
I always feel it'd be convenient to be able to quickly access old release tarballs
<aminechikhaoui>
ekleog is that possible for an s3 bucket ?
<ekleog>
oh it's a direct s3 bucket? didn't know, so maybe it's not possible indeed
<LnL>
listing is enabled
<LnL>
gchristensen: niksnut: is that intentional?, don't see listbucket in the terraform config
<clever>
LnL: i believe store-paths.xz is a list of every single $out in the entire release.nix, and the binary cache has a special file, with the dir listing of a thing
<clever>
nix-index uses those 2 things combined, to generate the index
<LnL>
yeah, I mean like the page itself
<ekleog>
clever: oh fun, I've never actually noticed it :D
<clever>
oh, i didnt know it was even linking the hydra eval
<LnL>
with a bit of extra styling this could be linked to directly and used as a ui