--- Log opened Fri Dec 11 00:00:44 2020
03:20 -!- Emma51Wiegand [~Emma51Wie@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-builds
04:22 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer]
04:22 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
04:43 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #bitcoin-builds
07:17 < hebasto> reminder  "dongcarl> Next meeting settled: 15:30:00 UTC | Friday, December 11, 2020" :)
07:29 < dongcarl> Hello!
07:29 < hebasto> hi
07:29 < dongcarl> #startmeeting
07:29 < dongcarl> Ping cfields fanquake
07:29 < hebasto> waiting for fanquake?
07:30 < cfields> hi
07:30 < dongcarl> Yeah let's wait a few mins to make sure everyone's here
07:30 < hebasto> sure
07:31 < dongcarl> Meh let's get started
07:31 < dongcarl> Hope everyone's doing well
07:32 < dongcarl> hebasto: you wanna start us off with 2 things you want to discuss?
07:32 < hebasto> ok
07:32 < hebasto> first is small https://github.com/bitcoin/bitcoin/pull/18298
07:33 < hebasto> second is https://github.com/bitcoin/bitcoin/pull/20600 not mine
07:33 < hebasto> 18298 fixes DEBUG=1 for non-linux depends build that is useful for Qt stuff testing
07:34 < cfields> Looking
07:34 < dongcarl> what was broken when DEBUG=1?
07:34 < hebasto> lib suffixes
07:35 < cfields> Ah
07:35 < hebasto> our configure script does not recognise debug suffixes
07:36 < cfields> Is there no way to make qt not add the suffixes?
07:37 < hebasto> maybe patching Qt? could be conflicts?
07:37 < cfields> If not, concept ACK. Makes sense to me.
07:37 < cfields> Nah, not worth patching it. Was only asking if there's an easy configure option.
07:38 < hebasto> no such option
07:38 < dongcarl> Concept ACK from me then
07:38 < hebasto> ^^ if I read docs correctly
07:38 < hebasto> second item to discuss?
07:38 < cfields> Sure. Will comment on the PR before I forget.
07:39 < dongcarl> Looking at the second one now
07:40 < hebasto> it seems inevitable to use qml stuff in qt gui, so static build with qml is a problem, that 20600 is trying tosolve
07:40 < hebasto> the most problem inter-dependencies between qt packages
07:40 < dongcarl> So I hate to bring this up, when there's so much QT build work going on...
07:41 < dongcarl> But I think we should seriously investigate Qt 6.x and its compat layer
07:41 < hebasto> hop direct into Qt 6?
07:42 < hebasto> we have problems even with 5.15 (
07:42 < cfields> Lol, just saw sipa's comment.
07:42 < dongcarl> Mostly because: 1. Better support for arm Macs should we need them, 2. Revamped cmake-based build system
07:42 < cfields> Ugh, we really need fanquake here for this.
07:43 < hebasto> I just asking cory to comment 20600 :)
07:43 < dongcarl> Yeah :-/ shame
07:43 < hebasto> my items are done
07:44 < dongcarl> My view is that all this shuffling around for qmake might be for nothing if we eventually move to Qt6 and use cmake instead
07:44 < cfields> What's the qt (copy).mk here ?
07:44 < cfields> dongcarl: right
07:45 < hebasto> the pr author tries to reproduce top level build mechanics
07:45 < hebasto> Qt6 still uses qmake as well
07:45 < dongcarl> hebasto: qmake is being slowly deprecated in Qt6
07:46 < hebasto> is cmake compatible with autotools?
07:46 < dongcarl> "The CMake build system is now the default one.
07:46 < dongcarl> There is no need to pass -cmake anymore to select the CMake build.
07:46 < dongcarl> Pass -qmake to enable the qmake build, but be prepared that it is going to vanish anytime soon."
07:46 < hebasto> ^ I see
07:46 < cfields> Heh, take qt guarantees with a grain of salt.
07:46 < dongcarl> hebasto: We have some support for cmake in depends already, and it's definitely better maintained than qmake
07:47 < hebasto> good to know
07:47 < cfields> dongcarl: are they trying to force CMake on the downstream projects like the did with QMake?
07:47 < cfields> Or just using CMake internally?
07:47 < dongcarl> cfields: Not sure, will have to check
07:48 < cfields> Just curious if it's going to complicate our configure
07:48 < dongcarl> Anyway, glad hebasto brought this up. I think I should open a Qt6 issue (not committing to doing the actual changes)
07:48 < cfields> Yeah, kinda hard to discuss 20600 without having a plan for next steps.
07:49 < dongcarl> Okay, let's do cfields next?
07:49 < hebasto> fiy https://github.com/bitcoin/bitcoin/issues/20104
07:49 < cfields> dongcarl: making me say outloud I have no interesting PRs outstanding, huh? :p
07:49 < hebasto> *fyi
07:50 < dongcarl> Hahahaha I wish I were that cunning
07:50 < cfields> :)
07:50 < cfields> dongcarl: you're up!
07:50 < dongcarl> sec
07:51 < dongcarl> So the series of PRs that are needed for macOS Guix builds are at their final form
07:51 < cfields> woohoo!
07:51 < dongcarl> 1. #20470
07:51 < gribble> https://github.com/bitcoin/bitcoin/issues/20470 | build: Replace genisoimage with xorriso by dongcarl · Pull Request #20470 · bitcoin/bitcoin · GitHub
07:51 < dongcarl> 2. #19683
07:51 < gribble> https://github.com/bitcoin/bitcoin/issues/19683 | depends: Pin clang search paths for darwin host by dongcarl · Pull Request #19683 · bitcoin/bitcoin · GitHub
07:51 < dongcarl> 3. #20619
07:52 < gribble> https://github.com/bitcoin/bitcoin/issues/20619 | guix: Quality of life improvements by dongcarl · Pull Request #20619 · bitcoin/bitcoin · GitHub
07:52 < hebasto> dongcarl: is it whole roadmap for guix replaces gitian?
07:52 < dongcarl> And finally: #17920
07:52 < gribble> https://github.com/bitcoin/bitcoin/issues/17920 | guix: Build support for macOS by dongcarl · Pull Request #17920 · bitcoin/bitcoin · GitHub
07:52 < dongcarl> hebasto: The two remaining things after #17920 are: 1. code-signing 2. distribution method
07:52 < gribble> https://github.com/bitcoin/bitcoin/issues/17920 | guix: Build support for macOS by dongcarl · Pull Request #17920 · bitcoin/bitcoin · GitHub
07:53 < dongcarl> Then we can replace everything.
07:53 < dongcarl> Code-signing I can just bang out on the keyboard.
07:53 < hebasto> mind elaborating 2. distribution method?
07:53 < dongcarl> Distribution I need to talk more on a Thursday meeting
07:53 < hebasto> ok
07:54 < hebasto> I'll review 20470 by next Monday
07:54 < cfields> dongcarl: For the first, does xorriso make comparable (or better?) dmgs?
07:54 < dongcarl> hebasto: Right, mostly: gitian.sigs transition... Getting builders set up with new stack... Bunch of READMEs...
07:54 < dongcarl> hebasto: thanks!
07:54 < dongcarl> cfields: How would you characterize "better-ness"?
07:55 < cfields> dongcarl: I think I'm asking about "worse-ness". It was a struggle to make mkisofs/genisoimage produce a dmg that macOS was happy with. Just want to make sure it's not a step backwards in any way.
07:56 < dongcarl> cfields: Oh yeah I've tested the DMG, it opens, it has the background, everything!
07:56 < cfields> Cool
07:56 < hebasto> are any difference for "apple notarization"?
07:57 < cfields> For the last few years I've had the slight fear with each new version of macOS that they'll start requiring more "correct" dmgs, but it hasn't happened yet.
07:57 < dongcarl> hebasto: Huh... I'm not up to date on that... Are we doing notarization now?
07:57 < dongcarl> cfields: Yeah... If they end up doing that we might be better off using ZIPs?
07:57 < hebasto> no, I think
07:57 < cfields> dongcarl: ack
07:58 < dongcarl> hebasto: So if I remember correctly, you can notarize ZIPs, .app's, and DMGs... So if notarization doesn't like our DMG, we can probably just notarize the .app...
07:58 < hebasto> got it
07:59 < dongcarl> Remains to be seen, but should affect this PR's validity (unless the unmaintained genisoimage somehow produced DMGs that notarization likes)
07:59 < dongcarl> s/should/should not/
08:00 < cfields> dongcarl: Still going through these.
08:00 < dongcarl> Sure!
08:00 < dongcarl> cfields: It'd mean a lot if you could take a closer look at #19683 for me, since you have some (lingering) context there
08:01 < gribble> https://github.com/bitcoin/bitcoin/issues/19683 | depends: Pin clang search paths for darwin host by dongcarl · Pull Request #19683 · bitcoin/bitcoin · GitHub
08:01 < hebasto> did https://github.com/bitcoin/bitcoin/pull/19683#issuecomment-732702943 resolved?
08:01 < dongcarl> hebasto: Yup! I had a much fancier solution but ended up just doing: https://github.com/bitcoin/bitcoin/pull/19683/commits/24b43daf443d63edabe2ea4bd494bbbbd7b8427a#diff-4e4af46a1ce34a4dd31f9da0da8686e40c20e8113ba72c7c7015c00100caf5e8
08:03 < cfields> dongcarl: Didn't end up needing the PATH tricks? Or are those just not part of this chain?
08:04 < dongcarl> Doing that hunk above avoided needing PATH tricks... I would still like to fix that though...
08:04 -!- Emma51Wiegand [~Emma51Wie@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
08:05 < cfields> I see.
08:05 < hebasto> PATH variable(s) in depends is a quite wild :)
08:05 < cfields> Much nicer to have a solution for guix first, imo. Then clean that up once it's all working.
08:05 < dongcarl> cfields: BTW, https://github.com/bitcoin/bitcoin/pull/19683#issuecomment-732702943 is an example of "one tool calling another tool and not being able to specify the other tool's full path".
08:06 < cfields> hebasto: yeah, heh.
08:06 < dongcarl> Just thinking through this now, I have a small concern...
08:06 < cfields> dongcarl: is that ccache and clang++ ?
08:08 < dongcarl> cfields: No, it's that because we don't prepend the depends bindir to CC, and the depends bindir is not in the PATH at make-time, we can't find clang.
08:08 < cfields> dongcarl: Will review and weigh in on 19683 for sure. I'm excited that's the last of the depends hacking (for now) to get guix working.
08:08 < cfields> oh oh, that exact problem. gotcha.
08:09 < dongcarl> I just realized that previously, cross-builders targeting macOS didn't have to append depends bindir manually to PATH for `make` to work, and now they do (hence: https://github.com/bitcoin/bitcoin/pull/19683/commits/24b43daf443d63edabe2ea4bd494bbbbd7b8427a#diff-4e4af46a1ce34a4dd31f9da0da8686e40c20e8113ba72c7c7015c00100caf5e8)
08:09 < dongcarl> This might not be desirable...
08:10 < cfields> Yeah, that's not great.
08:10 < hebasto> why?
08:12 < dongcarl> hebasto: Because PATH at make-time does not include the depends bindir, and we're referring to `clang` as `env <...> -- clang` now instead of `$(toolchain_path)$(host_CC)`
08:12 < hebasto> ah, I see
08:12 < dongcarl> Seems like a PATH change is still needed... Will see what I can do that's simple...
08:13 < hebasto> re-open the closed pr?
08:13 < dongcarl> hebasto: I might, will look into it more to see if there's something simpler
08:13 < dongcarl> I talked to cfields last time about it and he's right that it could be much simpler
08:14 < cfields> simpler is better :)
08:14 < dongcarl> Will experiment, and write out thoughts
08:15 < dongcarl> hebasto: I saw that you closed the `export` change...
08:15 < dongcarl> (that's it for me)
08:15 < dongcarl> hebasto: I feel like that PR has merit by itself, no?
08:16 < dongcarl> Talking about: #19882
08:16 < gribble> https://github.com/bitcoin/bitcoin/issues/19882 | depends: Export variables from make to environment explicitly by hebasto · Pull Request #19882 · bitcoin/bitcoin · GitHub
08:16 < hebasto> fanquake's https://github.com/bitcoin/bitcoin/pull/20504 works fine with it, btw
08:17 < hebasto> but initial goal were to fix static build with qml
08:17 < dongcarl> hebasto: I think your PR also makes depends more "correct" in general, yes?
08:17 < cfields> Hmm, can we not just export those from the qt build rather than funks.mk ?
08:18 < hebasto> on current master it does not change anything (but makes things in right way)
08:18 < hebasto> dongcarl: yes (slow typing on my side :p)
08:19 < cfields> dongcarl: I avoided exporting as much as possible to keep from forwarding config vars into make.
08:19 < dongcarl> cfields: Well _{config,build,stage}_env are part of the overall depends machinery I think, so we should honor them?
08:19 < cfields> Funny that you don't like that, it's the same thing you're objecting to with our build :)
08:20 < cfields> dongcarl: I just meant that as the first step of the configure/build stages, you could export there.
08:20 < cfields> like qt does with PKG_CONFIG stuff.
08:20 < dongcarl> cfields: Oh I see what you mean, like don't do it _for_ the package, make the package author do it themselves for more flexibility
08:21 < cfields> dongcarl: right
08:21 < dongcarl> Okay yeah that sounds like the right solution. We should document that then...
08:21 < cfields> I'm just not sure what the effect of having all of those new env vars exposed to Make would be.
08:22 < dongcarl> Sure, sounds reasonable to me!
08:22 < dongcarl> Alright, not much time left. Who's got something they wanna mention real quick?
08:22 < hebasto> are we going to bump clang in master?
08:23 < cfields> Happy to argue it out if you think I'm wrong about which is more correct. You've been looking into this stuff much more than me lately.
08:23 < dongcarl> cfields: No you're absolutely right. I want flexibility more than anything, cuz you never know what kind of situation you're gunna end up in.
08:24 < dongcarl> hebasto: Hmmm, another thing that might be solved with Qt6! xp
08:24 < hebasto> yep
08:24 < cfields> Heh
08:24 < cfields> Also, probably time to look at lld again. I haven't tested it in a few months.
08:24 < dongcarl> Yeah I ought to put up the issue ASAP just so we don't get people pouring their heart and soul into making Qt5 work
08:25 < cfields> Maybe we'll be able to drop cctools with the next clang bump :)
08:25 < dongcarl> cfields: WOOHOO
08:25 < cfields> dongcarl: +1
08:25 < dongcarl> Alright I'd say we had a successful meeting
08:25 < dongcarl> #endmeeting
08:25 < cfields> Thanks for arranging!
08:25 < hebasto> thanks!
08:25 < dongcarl> Thanks all for joining! hebasto cfields!
08:27 < wumpus> ...qt is finally ditching qmake? *tries not to cheer* now if we can get boost to dump b2...
08:27 < dongcarl> Hehe
08:28 < dongcarl> At least b2/boost was an easy split for me when I was doing the native/build split for them...
08:28 < dongcarl> qmake/qt was just too much of a mess to make that work properly
08:28 < wumpus> that's good to know that it's not as bad
08:29 < dongcarl> Now the true chaotic evil is to use b2 to build qt: https://github.com/boostorg/build/tree/develop/example/qt
08:35 < wumpus> w-whyyyy
08:36 < dongcarl> ¯\_(ツ)_/¯
08:53 < cfields> hahahaha
09:28 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Quit: freebsd 12.2 update]
09:39 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-builds
10:10 < wumpus> faq "When will Guix be packaged in debian?"  hah
10:16 < dongcarl> wumpus: I should actually update that... It's in experimental right now
10:16 < dongcarl> vagrantc has been making very good progress
10:26 -!- jonatack [~jon@213.152.186.40] has quit [Ping timeout: 240 seconds]
10:45 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
10:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-builds
10:50 -!- jonatack [~jon@37.170.61.94] has joined #bitcoin-builds
11:03 -!- jonatack [~jon@37.170.61.94] has quit [Read error: Connection reset by peer]
11:12 < wumpus> good to know; for this time I've installed from the binary install (as root) but I get "guix time-machine: error: remounting /gnu/store writable: Permission denied" while running bitcoin's guix build script (as user)
11:12 < wumpus> it's clearly some permission issue
11:14 < wumpus> my user isn't permitted to remount that
11:19 < wumpus> nm, probably trying to run it in a unprivileged LXC wasn't that great an idea
11:25 < wumpus> (I don't think anything can do any mounting at all, I"ll try in a proper VM)
11:26 -!- jonatack [~jon@213.152.161.244] has joined #bitcoin-builds
13:04 -!- tylerchambers [uid477594@gateway/web/irccloud.com/x-raafweykxwvatycu] has joined #bitcoin-builds
13:23 < wumpus> that works better
16:06 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
--- Log closed Sat Dec 12 00:00:44 2020