--- Log opened Wed Sep 16 00:00:20 2020
01:07 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]
01:11 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-builds
02:02 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
02:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
02:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-builds
03:19 -!- Willy37Pollich [~Willy37Po@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-builds
03:23 -!- jonatack [~jon@37.166.247.142] has quit [Read error: Connection reset by peer]
04:04 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-builds
04:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
04:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-builds
06:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-builds
07:00 < hebasto> meeting?
07:01 < cfields> hi :)
07:01 < hebasto> hi
07:01 < fanquake> hi
07:01 < dongcarl> Hello
07:02 < dongcarl> Thanks everyone for coming
07:02 < dongcarl> Anyone got small discussion topics before we get into our PR showcase?
07:03 < cfields> A quick disclaimer (becoming the usual one, I'm afraid): I've been really distracted by DCI stuff for the last few weeks, and probably for a few more. So I'm pretty much just here at the discussion/concept ACK/NACK level for now :(
07:03 < fanquake> I haven’t got any topics.
07:03 < hebasto> quick topic: experimental QML builds
07:04 < dongcarl> Link?
07:04  * hebasto https://github.com/bitcoin/bitcoin/pull/16883
07:05 < hebasto> the question is could we combine QML with QWidgets?
07:05 < dongcarl> So I've heard a bit about this QML thing, but never quite understood it
07:06 < dongcarl> Is this bundled with QT itself? Or is it another depends package?
07:06 < hebasto> or should have two different builds?
07:06 < hebasto> it requires additional module to build for our gitian builds
07:08 < hebasto> as it is an experimental for now, I'd suggest to combine technologies if it is possible
07:08 < cfields> hebasto: Are you suggesting that this would eventually replace our qt gui, or be an additional one?
07:09 < hebasto> in long run -- replace it
07:09 < cfields> The build side of this seems reasonable, but this is part of a much larger discussion, I think.
07:09 < dongcarl> hebasto: Has this been discussed in the main meeting yet?
07:10 < hebasto> currently I'm asking about experimental builds only
07:10 < hebasto> dongcarl: yes
07:10 < hebasto> dongcarl: recently
07:11 < fanquake> hebasto: so do you essentially just want a flag in depends that builds QML stuff if you opt in? Similar to multiprocess
07:11 < hebasto> fanquake: yes
07:11 < fanquake> I hope the project doesn’t have to maintain two GUIs in parallel at all
07:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
07:12 < dongcarl> Is there consensus that QML is the direction to go towards?
07:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-builds
07:12 < cfields> Yeah, I'm having trouble not weighing in on the concept here...
07:12 < dongcarl> I don't know QT stuff that well... But I also hear there's QT Quick or the like
07:13 < cfields> hebasto: what's the build question? Is it just a depends flag like fanquake said, or is there something else?
07:13 < hebasto> it requires to build additional module besides qbase
07:14 < cfields> I see
07:14 < cfields> It might make sense to look at it on top of the qt bump, then? With the qt stuff more split up.
07:15 < cfields> Actually
07:15 < fanquake> Is the plan that people will be actively experimenting/building on top of the new flag?
07:15 < cfields> is it even needed for experimentation? Can't you just experiment with system qt?
07:15 < cfields> ...ah, right, Android.
07:16 < hebasto> making experiments with GUI without static builds?
07:17 < hebasto> not only Android. Many designers could be involved in QML GUI stuff
07:17 < cfields> Core worked for years without depends and static builds ;)
07:17 < hebasto> cfields: sure :)
07:18 < cfields> Ok, let's not spend the whole meeting on this.. I think there's a much wider debate to be had, but the build-specific question seems to be about depends. So how about splitting out the depends changes to another PR and we can discuss those on merit separate from the larger discussion?
07:18 < hebasto> but how to test on other platforms without depends?
07:18 < hebasto> cfields: ok
07:19 < dongcarl> Sure, I think we can also take a look at the convo in the main meeting w/re this
07:19 < cfields> dongcarl: ack.
07:19 < hebasto> http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-03-19.00.log.txt
07:20 < dongcarl> Alright, fanquake do you want to start us off? Let's do 2 PRs each
07:20 < dongcarl> hebasto: thanks for the link
07:20 < fanquake> Sure
07:20 < fanquake> #19959 is my alternative to splitting libpng out of the qt build. Looking for one more (concept) ACK. That should unblock PowerPC builds for 0.21.
07:20 < gribble> https://github.com/bitcoin/bitcoin/issues/19959 | build: patch qt libpng to fix powerpc build by fanquake · Pull Request #19959 · bitcoin/bitcoin · GitHub
07:21 < hebasto> a half-line change :)
07:21 < cfields> hmm
07:21 < fanquake> I’d also like to try get #19522 in at some point. Seem to have consensus on the approach. Just need final review. Have addressed some recent comments.
07:22 < gribble> https://github.com/bitcoin/bitcoin/issues/19522 | build: fix building libconsensus with reduced exports for Darwin targets by fanquake · Pull Request #19522 · bitcoin/bitcoin · GitHub
07:22 < cfields> I think I'd actually prefer building libpng for the sake of being more in control and explicit...
07:22 < cfields> fanquake: do you have an aversion to building libpng?
07:23 < hebasto> besides libpng we use others Qt builtin stuff
07:23 < fanquake> I think the any performance related arguments for splitting it out are weak/irrelevant to us. Also CVEs shouldn’t really be any issue if Qt being slowish to update is a concern.
07:23 < cfields> hebasto: sure, but we've broken things out too.
07:24 < dongcarl> I think we should decide and document "what _should_ stay in QT and what doesn't"
07:24 < hebasto> and why
07:24 < dongcarl> s/doesn't/shouldn't/
07:24 < fanquake> If we break this out should we just break everything out? We are already going to be building a bunch more stuff for 5.15.x. All the xlibs etc
07:24 < cfields> so, I'll speak to that quickly because I think it's changed over the years...
07:24 < dongcarl> Perhaps cfields can give us context
07:26 < cfields> At first, it was: let qt build everything it can so we don't have to. But over time, we've run into issues/incompatibilities with nearly all of those things. So I'm more of the opinion these days that we should build everything we can to be more in control, because we're likely going to have to take it on at some point anyway (that's been the trend, anyway)
07:26 < cfields> I don't care strongly one way or the other about libpng, I just see it as part of the trend of us needing more control.
07:27 < dongcarl> Okay question from me: if we want to be more in control, can't we simply patch the subtree'd code inside QT? Are there things that we need control over that's more than just patching?
07:28 < dongcarl> (I'm not advocating for anything, just exploring the space of possibilities)
07:28 < cfields> dongcarl: we'll need to keep an eye on what qt does with libpng with every new release, as opposed to building it ourselves where it would remain unchanged.
07:29 < cfields> I think ^^ is the heart of my argument.
07:29 < cfields> But again, I don't feel too strongly. I was mostly just curious if fanquake had any specific reason to not build it ourselves.
07:30 < fanquake> Are you saying more so than we have to already? Note that the patch we are applying for this next release only comes from upstream, and we’ll drop it for 0.22 when we switch to 5.15
07:30 < hebasto> https://github.com/bitcoin/bitcoin/pull/19751#issuecomment-678622165
07:31 < cfields> heh, I'm trying hard not to argue either way and to just understand the reason(s) against.
07:31 < fanquake> I also just wanted to avoid building more things that we don’t even use directly.
07:32 < cfields> It gets built either way, though?
07:32 < hebasto> maybe "direct usage" could be a criteria to build or not to build?
07:33 < cfields> hebasto: yeah, I think that's roughly the rule-of-thumb that has evolved.
07:33 < fanquake> Sure, but in the qt case we don’t have to maintain it as much. Although you can argue against that
07:33 < dongcarl> To me, I think that there may potentially be patches QT applies to its dependencies which are crucial to QT's operations. w/re keeping an eye on what qt does with its dependencies, we should just diff the dependency repos and make it a habit to do so every time we bump QT
07:34 < cfields> ok, sure, I'm clearly in the minority here. Go for it :)
07:34 < fanquake> Tangentially related. Building things ourselves is also going to become slightly more annoying as dependencies switch away from autotools based build systems. I.e for the 5.15 bump, I’ve held back one package, as later versions dumped autotools for meson
07:35 < fanquake> We should probably discuss that at some point, but not now, as need to get to others PRs.
07:35 < cfields> dongcarl: I don't think that one's a strong argument, though. If qt is hacking libpng itself, that's a pretty big red flag.
07:36 < dongcarl> Okay, sounds like this point warrants more discussion in an issue or sth
07:36 < dongcarl> Let's look at fanquake's second PR
07:36 < cfields> I'll just concept ACK the one-line patch. It's a silly thing to spend much time on.
07:37 < cfields> Other than the time it probably took to hunt down that one line :p
07:38 < dongcarl> RE = reduced exports?
07:38 < fanquake> Yah
07:38 < fanquake> cfields: heh one silly line with some big potential
07:40 < dongcarl> fanquake: Looking at the diff here...
07:40 < fanquake> Did I mess up a rebase
07:41 < cfields> fanquake kinda buried the lede with 19522. It fixes the visibility attribute checks for some platforms including darwin.
07:42 < dongcarl> Would this work if you _just_ added RE_CXXFLAGS to AM_CXXFLAGS?
07:43 < cfields> dongcarl: the macro in ax_gcc_func_attribute.m4 is broken.
07:45 < dongcarl> Okay I need to take a closer look then
07:46 < fanquake> Okay. No need to discuss this one any further. Does someone else have PRs we should look at?
07:46 < dongcarl> hebasto?
07:46 < hebasto> #19882
07:46 < gribble> https://github.com/bitcoin/bitcoin/issues/19882 | depends: Export PATH variable rather passing it to the `call` function by hebasto · Pull Request #19882 · bitcoin/bitcoin · GitHub
07:47 < cfields> dongcarl: basically: there are different values for visibility, and the macro attempts to check "visibility=protected", which doesn't exist for some compilers. So it decides that the whole visibility attribute is unavailable.
07:47 < dongcarl> cfields: Ah, makes sense!
07:47 < hebasto> actually, it is required to build other qt modules, and is noop for now
07:48 < cfields> hebasto: hmm, that looks reasonable. Will review and ACK/NACK.
07:49 < dongcarl> I'm confused as to why this changes anything
07:49 < cfields> I tried to avoid exporting as much as possible to avoid affecting sub-shells, but I think doing PATH like that should be fine.
07:50 -!- Willy37Pollich [~Willy37Po@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]
07:50 < dongcarl> Oh I see.
07:50 < hebasto> dongcarl: PATH within make, and PATH in environment are distinct
07:50 < cfields> dongcarl: vars don't get re-exported to subshells when set like "FOO=1 ./bar"
07:51 < hebasto> may I quickly mention another PR?
07:51 < dongcarl> Yup
07:51 < hebasto> #19868
07:51 < gribble> https://github.com/bitcoin/bitcoin/issues/19868 | build: Fix target name by hebasto · Pull Request #19868 · bitcoin/bitcoin · GitHub
07:52 < hebasto> cfields: it seems your code, right?
07:52 < cfields> hebasto: yep, I've been meaning to take a look at that one. Will look in detail.
07:53 < dongcarl> cfields: This is an alternative to my fix for the situation where "HOST=darwin, you build a non-native package using `make boost` or sth, and cctools doesn't get built first for some reason"
07:53 < cfields> Oh, wait, _unpacked doesn't even exist??
07:53 < hebasto> correct
07:54 < cfields> Heh, definitely a typo. Conceptually, that should be "_extracted".
07:54 < cfields> Will comment on the PR.
07:54 < hebasto> I'll change it
07:54 < cfields> Well, I'm not sure if _extracted will actually work. But that's definitely what I intended.
07:56 < dongcarl> Glad we got that sorted. Last 5 mins, anyone got anything before we call it?
07:56 < cfields> Conceptually it means: never start working on a target package (first step is extraction) before all build packages are done.
07:56 < hebasto> dongcarl: your prs?
07:57 < dongcarl> #19764 should go in after hebasto's fix we just discussed
07:57 < gribble> https://github.com/bitcoin/bitcoin/issues/19764 | depends: Split boost into build/host packages + bump + cleanup by dongcarl · Pull Request #19764 · bitcoin/bitcoin · GitHub
07:57 < dongcarl>  #19683 is a blocker for Guix right now, but it's understandably more involved to review
07:57 < gribble> https://github.com/bitcoin/bitcoin/issues/19683 | WIP: depends: Explicitly specify clang search paths for darwin host by dongcarl · Pull Request #19683 · bitcoin/bitcoin · GitHub
07:58 < cfields> dongcarl: ah, thanks for saying that. What's WIP about it?
07:59 < dongcarl> cfields: Actually, I don't think it is anymore, since we resolved the param expansion with an extra $
07:59 < dongcarl> Will update
07:59 < cfields> ACK
07:59 < fanquake> Glad that’s resolved
08:00 < dongcarl> Alright
08:00 < dongcarl> I think that's it for this round
08:00 < dongcarl> #endmeeting
08:00 < dongcarl> Many thanks for everyone's attendance!
08:00 < hebasto> thanks to all
08:00 < dongcarl> hebasto, fanquake, cfields see y'all next time!
08:00 < cfields> Thanks, and thanks dongcarl for organizing!
08:00 < fanquake> thanks
08:42 -!- Vita16Walsh [~Vita16Wal@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-builds
08:46 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-builds
08:47 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
11:04 -!- Vita16Walsh [~Vita16Wal@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]
11:07 -!- Jamir5Keeling [~Jamir5Kee@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-builds
12:00 -!- Jamir5Keeling [~Jamir5Kee@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
13:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
13:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-builds
13:05 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-builds
13:06 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
15:08 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-builds
15:11 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
15:12 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-builds
15:14 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
15:28 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
15:55 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-builds
--- Log closed Thu Sep 17 00:00:21 2020