gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
lassulus has quit [Ping timeout: 240 seconds]
lassulus has joined #nixos-dev
lassulus has quit [Ping timeout: 246 seconds]
lassulus has joined #nixos-dev
cransom has quit [Ping timeout: 250 seconds]
cransom has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
drakonis has quit [Quit: WeeChat 2.3]
<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?
Guest5079 has joined #nixos-dev
<srhb> The rest of the gccs look like "no"
<domenkozar> gchristensen: btw, there could be false positivies
<domenkozar> not sure if you've built those with randomfs, etc
<domenkozar> also, weekly goes out tomorrow, any news missing?
<{^_^}> nixos-weekly#75 (by domenkozar, 2 weeks ago, open): Call for Content: 2019/02
<clever> domenkozar: there is also disorderfs
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
<gchristensen> domenkozar: can't prove it otherwise
<gchristensen> Taneb, timokau[m], clever, timokau[m], it is also very easy to define the IDs and make it reproducible
genesis has quit [Ping timeout: 252 seconds]
genesis has joined #nixos-dev
<domenkozar> gchristensen: I was thinking more to describe how it was tested to be reproducible
<domenkozar> build twice on the same machine
<domenkozar> different machine?
<domenkozar> different proc?
<gchristensen> right right
<gchristensen> each of these was built on two different machines, on different hardware and kernel versions
<domenkozar> maybe add that as disclaimer on the page?
<gchristensen> sure
<gchristensen> that is a good idea
<domenkozar> gchristensen++
<{^_^}> gchristensen's karma got increased to 70
<gchristensen> not using randomfs -- the next big step :)
<gchristensen> I should publish that too :)
<domenkozar> every projects starts with: this would be cool to do in a few hours
<domenkozar> and continues with "I need beer, this is endless"
<domenkozar> at least that's my rollercoaster :D
<gchristensen> yes, seaking of which, the whole project is open source if anyone wants to contribute! ;)
<domenkozar> free as in beer!
<gchristensen> please take mypuppy
drakonis has joined #nixos-dev
<gchristensen> when answering a question on lobsters, I looked up and learned hydra builds between 30,000 and 60,000 derivations a day.
<Taneb> That's a whole bunch
<gchristensen> a whoole bunch.
<Synthetica> domenkozar: or your intoxicant of choice, of course
<domenkozar> ofc
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
aminechikhaoui has quit [Quit: The Lounge - https://thelounge.github.io]
aminechikhaoui has joined #nixos-dev
<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
<arianvp> https://github.com/NixOS/nix/issues/2619 wondering if you would like to help me fix it :D
<gchristensen> I think it works in a certain scenario ... what way is it broken?
<{^_^}> nix#2619 (by arianvp, 3 weeks ago, open): Nix 2.0 deterministic build options don't do anything
<arianvp> The build-repeat option seems to be silently ignored
<gchristensen> I think you have to set them as root
<arianvp> I created a regression test
<gchristensen> ah
<arianvp> (I pass the option as a cli flag)
<gchristensen> at any rate, I don't use exactly that -- I went a lazier root
<gchristensen> Imean, I thik you have to set them in nix.conf
<arianvp> Why? I thought nix 2.0 allowed all options to be set through flags right?
<gchristensen> not all flags are accepted like that I think
<arianvp> Then maybe that was my problem
<arianvp> Should try that when I'm home
<arianvp> But what did you do instead, Graham?
<gchristensen> also if the .drv has been built before, I think, indeed, the options are ignored
<gchristensen> I'm writing that up now! :)
<arianvp> Cool
<arianvp> Would be cool to better document the built-in support though (and potentially fix it, if it's really broken)
<gchristensen> yes
<gchristensen> it has edge cases which make it _SEEM_ broken, which is why I'm not explaining it right now
<arianvp> Are your really sure not all nix conf options can be overwritten in the command line?
<arianvp> I'm trying to find something Bout this in the nix user guide
<gchristensen> for example I don't think you can turn off sandboxing
<gchristensen> ekleog: https://r13y.com#how-do-i-check
<ekleog> Thank you! didn't know of that `.check` store path :)
<gchristensen> <3
<Guest5079> do you know which of the two that one is?
Guest5079 is now known as LnL
<clever> LnL: i'm guessing the 2nd build from --check
<clever> and it would leave the original build where it was
<gchristensen> yeah
<LnL> thing is, then $out would have to be different for the check build
<clever> LnL: the sandbox can mis-match things as it maps them in
<gchristensen> I think nix mounts an empty path there, so it doens't have to be empty
<LnL> so I've wondered before how that's done
<gchristensen> just like how it already mounts just that nix path read-write
<LnL> ah, bind mounts
<samueldr> things like CPU features, thinking about aarch64 which might be having issues, any ways to increase reproducibility here?
<samueldr> maybe I should dig in the debian docs
<samueldr> yeah, digging in those docs :)
<gchristensen> yay!
<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> samueldr: this is how x86 handles the issue, https://github.com/NixOS/nix/blob/master/src/libstore/build.cc#L2761-L2766
<samueldr> clever: AFAIK there's no personality mechanisme for aarch64
<samueldr> and here I'm thinking about things on different aarch64 platforms, not even 32 bit
<clever> samueldr: the kernel would have to be modified to add such a thing
<samueldr> like, does that fix SSSE4 and friends for x86_64?
<gchristensen> no
* samueldr goes find man personality
<gchristensen> we've had problems with that in the past with a particularly old builder
<clever> let me check in #osdev ...
<samueldr> "man personality" is not the best googlable term
<gchristensen> «insert lack of»
<clever> samueldr: i suspect you can bind-mount over /proc/cpuinfo, but the tricky part will be the cpuid opcode...
<arianvp> Would fixing reproduciblity be a good project for the nlnet grant?
<andi-> I think so but it is not a one-shot thingy.. it will come up over and over again as packages evolve
<clever> andi-: oh yeah, one min
<clever> andi-: this checks an arch specific flags field in the ELF file
<clever> and will fail the build if the ELF is for the wrong sub-arch
<samueldr> clever: fun, the one binary I check, readelf -A on aarch64 has no info
<clever> samueldr: one anoying thing, is that you need an arm targeting readelf
<clever> so the x86 readelf cant see the v6 vs v7 flags
<samueldr> aarch64 on aarch64 here
<clever> 2019-02-05 11:36:34 < clever> how does qemu when not using TSC, restrict what cpu features can be seen via cpuid?
<clever> 2019-02-05 11:37:32 < pm215> clever: it asks KVM in the host kernel to lie to the guest about the CPUID values
<samueldr> good, that was what I was assuming one could do to ensure a LCD of cpu features
<samueldr> define them in qemu-kvm and build there
<samueldr> wondering if qemu-user handles it well enough
<samueldr> (e.g. qemu-user-aarch64 on qemu-user-aarch64)
<clever> i dont think qemu-user has kvm support (aarch64 on aarch64 emulation is rather silly)
<clever> however, i have done basically that to narrow down qemu TSC bugs before
<clever> qemu-system (without kvm) had problems running some software, but it took forever to boot, to even test
<clever> qemu-user, for x86-64->x86-64, used the same TSC, and produced the same fault, without having to boot an entire OS
<clever> turns out, 64bit qemu emulates a really old 64bit cpu, without sse4
<clever> by default
<clever> 2019-02-05 11:37:52 < clever> pm215: what flag to ioctl is responsible for that?
<clever> 2019-02-05 11:40:28 < pm215> clever: KVM_SET_CPUID2 ioctl, I think
<clever> samueldr: that gives me a whacky idea....
<clever> samueldr: could i use the kvm api, to make my own qemu-user style app, that is limited to same-arch...
<samueldr> conversely, can this be used to add missing cpu features through emulation?
<clever> probably
<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 :(
<gchristensen> ekleog: by all means
ekleog changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<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> gchristensen: https://reproducible-builds.org/tools/ may also be of interest to you
<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> Then again...
<tilpner> XML Parsing Error: not well-formed
<tilpner> Location: file:///home/till/dev/nixos-homepage/nixpkgs/packages.json
<tilpner> It still loads, and shows packages to search
<tilpner> And the FF network tab shows no entries, so I don't think it fetches the real thing instead
<tilpner> url: ((document.domain == 'nixos.org') ? '[%root%]nixpkgs/packages.json.gz' : '[%root%]nixpkgs/packages.json'),
<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> ekleog: the history file in here, lists every gitrev the channel has been at
<clever> you could then just use github archive URL's, if you dont care about programs.sqlite
<clever> oh, history-url solves that
<ekleog> LnL: Heh? I don't get anything on https://releases.nixos.org/nixos/18.09/
<LnL> well that's http not s3
<ekleog> clever: nice, thanks :) until now I had been using github archive URL's with the commit from howoldis, but…
<clever> 2019-02-05 15:15:33 -{^_^}:#nixos- Channel nixos-18.09-small advanced to https://github.com/NixOS/nixpkgs/commit/addb7f23ebc (from 2 hours ago, history: https://channels.nix.gsc.io/nixos-18.09-small)
<clever> ekleog: this bot has been spamming that history url for a while now
<LnL> oh, I didn't know the release link had all this info https://releases.nixos.org/nixos/18.09/nixos-18.09beta75.a015527b1b2
<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
<clever> [root@system76:~]# curl https://nixos.org/channels/nixos-unstable -v
<clever> also of note, the normal channel urls are http redirects to the one you linked
<clever> and nix-channel will try to query the directory first, then use the redir target, for all files
<clever> so it gets all the files from the same redirect
q6AA4FD has quit [Quit: ZNC 1.7.1 - https://znc.in]
drakonis has joined #nixos-dev
worldofpeace has joined #nixos-dev
q6AA4FD has joined #nixos-dev
<samueldr> LnL: if you need one of the previous url, since the bot posts it, the #bottest log is useful
<samueldr> oops #nixos-bots
<samueldr> oops, I'm wrong, I thought it had a full link including version+commit id
<samueldr> (it's the github commit URL I must have had in mind)
<LnL> yeah, but the channel log keeps track of those
<LnL> I've also only used it for a current channel revision
<samueldr> "the channel log" this is overloaded, which log?
<samueldr> right yes
<samueldr> I didn't know `history-url` was added, and it is nice
<gchristensen> might should move that to nixos.org
srhb has quit [Remote host closed the connection]
srhb has joined #nixos-dev
JosW has joined #nixos-dev
q6AA4FD has quit [Quit: ZNC 1.7.1 - https://znc.in]
JosW has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
q6AA4FD has joined #nixos-dev
q6AA4FD has quit [Quit: ZNC 1.7.1 - https://znc.in]