--- Log opened Sun Jun 16 00:00:45 2019 04:35 <@dongcarl> New clue: might be kernel version 05:30 < nothingmuch> https://gist.github.com/nothingmuch/635fc42680b25110e32c7ea9617acfb9 05:31 <@dongcarl> nothingmuch: Much appreciated! What does `/proc/version` say on your machine? 05:32 < nothingmuch> Linux version 4.14.119-2.pvops.qubes.x86_64 (user@build-fedora4) (gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 SMP Wed May 15 06:43:11 UTC 2019 05:33 <@dongcarl> nothingmuch: thank you! 05:34 * dongcarl beginning to think that it _must_ be a kernel version problem 05:40 < nothingmuch> fwiw file 5.33 from guix has this to say: 05:40 < nothingmuch> output/bitcoin-0.18.99-x86_64-linux-gnu-debug.tar.gz: gzip compressed data, max compression, from Unix, original size 1058201600 06:29 <@dongcarl> nothingmuch: Thanks! 06:30 <@dongcarl> The kernel underlying that guix is the qubes kernel? or the debian kernel? Did you run debian as a container in qubes or a vm? 06:30 <@dongcarl> fanquake: Using your docker scripts to check if kernel is the issue... very useful! 06:31 < fanquake> dongcarl ok! 06:31 < fanquake> Let me know if you'd like a hand with anything, and I'll take a stab tomorrow. 06:32 <@dongcarl> fanquake: Thank you :-) I think cross-distro reproducibility hasn't been researched much, so we might be running into some unique problems, but that's a good thing for the long run! 07:05 < nothingmuch> dongcarl: qubes supplied kernel, my dev sandbox appvm, based on mostly unmodified debian 9 templatevm, with guix (/gnu & /var/guix bind mounted from /rw) 07:13 <@dongcarl> nothingmuch: I'm guessing the vm has its own kernel? Guess what I'm asking is "effective kernel" 07:19 < nothingmuch> appvm kernels are supplied by dom0, i'm using the latest stock one 07:20 <@dongcarl> nothingmuch: Ah I see! Sorry I'm not too familiar with Qubes 07:20 < nothingmuch> i think it's an old fedora kernel with some patches for the memory mgmt but i never investigated very deeply 07:20 <@dongcarl> nothingmuch: chill 07:22 < nothingmuch> https://github.com/QubesOS/qubes-linux-kernel/commits/master 07:22 <@dongcarl> nothingmuch: Huh... Looks like they're moving towards 5.x too 07:23 < nothingmuch> i can't find any docs but the patches all seem to be related to qubes' specific xen setup 07:23 <@dongcarl> nothingmuch: I'm guessing you're on stable/LTS some kind of thing? 07:24 < nothingmuch> afaik there's no LTS stuff for qubes, i'm on 4.0 and i think 3.2 was unsupported a few months back 07:25 <@dongcarl> nothingmuch: what I meant was they're moving towards Linux 5.x 07:26 < nothingmuch> yep, but i don't think it's released yet, i'm checkingto see how hard it is to run 07:37 < nothingmuch> if it's available in some unstable channel i couldn't figure it out. i have to go afk for a few hrs, but i don't mind building a kernel if you want me to try a 5.x 07:38 <@dongcarl> nothingmuch: Oh no worries, just curious about how Qubes works 07:38 < nothingmuch> i'm a bit of a redhat pleb so i don't actually know if i exhausted searching w/ the dom0 package manager 07:38 < nothingmuch> ah 07:39 <@dongcarl> Haha redhat pleb 09:54 <@dongcarl> not the kernel... alpine docker build also differs... 16:28 < nothingmuch> dongcarl: updated https://gist.github.com/nothingmuch/635fc42680b25110e32c7ea9617acfb9 16:29 < nothingmuch> tl;dr - 5.1 kernel produces same results as 4.14, but there were two differences in output - the first is that a .pyc file leaked into the source tarball 16:30 < nothingmuch> the second one is probably the result of me running in a dirty env, but i ended up with some almost empty binaries and proper ones with ext .dbg.dbg 16:32 < nothingmuch> and fwiw the .pyc file is bitcoin-0.18.99/share/rpcauth/__pycache__/rpcauth.cpython-35.pyc, not much info apart from that in the supplied diffoscope json --- Log closed Mon Jun 17 00:00:44 2019