--- Log opened Tue Jun 18 00:00:45 2019
05:39 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 256 seconds]
05:47 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-builds
08:26 < cfields> nothingmuch: we should strive for that as well, but yes, that's not an immediate problem.
08:29 < cfields> fanquake / dongcarl: see https://github.com/bitcoin-core/univalue/pull/19
08:29 < cfields> I've had these changes sitting around for a while, figure I should go ahead and upstream them.
08:33 < cfields> The goal is to improve the coordination between core/univalue/secp256k1/minisketch. ATM some flags go missing, we build too much, and we lose control over internal build config.
08:33 < cfields> So rather than hacking together more configure switches, we can just integrate the buildsystems similar to the way that leveldb is done.
08:38 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Read error: Connection reset by peer]
08:39 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-builds
10:46 < nothingmuch> cfields: fwiw to make the binary splitting idempotent is just a matter of adding -and -not -name '*.dbg' to the find command in contrib/guix/build.sh, but that kind of change seems like a slippery slope of paranoia in the guise of defensive programming
10:48 < nothingmuch> also i assume the long term plan is to eventually have a guix package with controlled inputs and outputs, and working directory pollution won't be a problem anyway?
10:49 < dongcarl> nothingmuch: yes
10:53 < nothingmuch> did you guys put the output tarballs themselves somewhere, or just diffoscope outputs?
10:53 < dongcarl> nothingmuch: diffoscop outputs... I'm going to put up some tarballs this week that are more systematically created though
10:54 < nothingmuch> and is there any use in me posting mine? 3rd attempt finished this morning produced bit identical results to 2nd build from 2 days ago
10:54 < dongcarl> nothingmuch: Hmmm... How long are the builds taking for you?
10:54 < nothingmuch> more systematically - the docker based distro comparison?
10:55 < nothingmuch> i'm going to guess about 5-6 hrs, but i didn't exactly keep track i left it overnight all 3 times
10:55 < dongcarl> nothingmuch: Yeah, I'm trying to basically `git bisect` the difference between guix-build-on-arch-real-hardware and guix-build-on-debian-on-vms
10:56 < dongcarl> nothingmuch: I'd recommend playing with the Guix build system a little and understand what the `gnu-build-system` preset does in Guix
10:57 < dongcarl> I think the doable next step would be to make all of depends a Guix package
10:57 < dongcarl> I think that's very doable
10:57 < dongcarl> Take a look at what the preset does, esp when it patches shebangs and things like that
10:59 < nothingmuch> cool, i already started looking into it but had to fill quite a few gaps in my autotools knowledge (the only complex C project where i needed to touch the build system was perl)
10:59 < dongcarl> nothingmuch: Let me get you started, sec.
10:59 < nothingmuch> i think i have a good handle on how make depends works now, i read through all the makefiles
11:00 < nothingmuch> my next step was going to figure out how to get static builds out of gnu-build-system, and whether or not that's reasonable to do by inheriting
11:01 < dongcarl> nothingmuch: I actually started out with much of the same goals as you
11:01 < dongcarl> But I don't think it's worthwhile to attempt fully-static builds yet
11:01 < dongcarl> They will make the binaries way too large and unruly
11:02 < nothingmuch> fwiw i only meant to make one of the static make depends builds happen through guix instead, not the entire binary, zlib seemed like the simplest dep
11:03 < dongcarl> nothingmuch: Oh I see! Yes do that.
11:04 < nothingmuch> also guix zlib uses the exact same tarball in HEAD, so i suspect comparing the results of the make depends build and butchered guix package should be easiest
11:04 < dongcarl> nothingmuch: One tip: Let's say you're trying to make package `foo` from depends work with Guix
11:05 < dongcarl> Make sure that you call `make foo_postprocessed` before you patch the shebangs
11:05 < dongcarl> sorry
11:05 < dongcarl> `foo_preprocessed`
11:05 < dongcarl> see here for more details: https://github.com/bitcoin/bitcoin/pull/15446
11:06 < dongcarl> because the Guix system has to patch the shebangs because sh and file and such aren't in the assumed places
11:06 < dongcarl> But you need the source code in order for the patch to work
11:06 < dongcarl> so `preprocessed` makes sure that the source code is extracted out of the tarball and we've already applied our own depends patches
11:07 < nothingmuch> this preprocessing is bitcoin specific patching etc, right?
11:07 < dongcarl> Lmk if that makes sense
11:07 < dongcarl> Yes
11:07 < nothingmuch> yep makes a lot of sense
11:07 < nothingmuch> thanks!
11:07 < dongcarl> :-)
11:08 < nothingmuch> btw thanks a lot for pakcages.md it was very helpful
11:09 < nothingmuch> unor
11:09 < nothingmuch> unfortunately dyslexic brain read that as packages.mk and i confused it with the nested one so i missed it for a while
11:09 < dongcarl> Great! I make sure to update it with weird rules I introduce to make the system more robust
11:10 < dongcarl> (or so I think)
11:12 < dongcarl> cfields: Looking at the univalue pull...
11:21 < dongcarl> cfields: Not sure I'm 100% on "the sources are listed separately from the build recipes"
11:22 < dongcarl> I understand we were doing subconfigures before... And that led to flags being dropped? How does this help?
13:23 < cfields> dongcarl: for example, we add -std=c++11 during our configure.
13:24 < cfields> But that doesn't end up carrying through to Univalue because modifying CXX would break the autoconf cache, which makes it really really grumpy.
13:25 < cfields> Now the files are just integrated directly into our build. So we're in direct control over how everything is built.
14:07 < dongcarl> Ah I see, will do some exploring to see that for myself
--- Log closed Wed Jun 19 00:00:47 2019