--- Log opened Fri Apr 10 00:00:48 2020
00:26 -!- jonatack_ [~jon@37.166.238.163] has joined #bitcoin-builds
00:29 -!- jonatack [~jon@37.164.104.82] has quit [Ping timeout: 250 seconds]
00:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
00:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
01:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
01:15 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
02:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
02:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
02:05 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
02:36 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-builds
03:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
03:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
03:06 -!- Anabelle88Murazi [~Anabelle8@ns334669.ip-5-196-64.eu] has joined #bitcoin-builds
03:42 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-builds
03:45 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
04:47 -!- Anabelle88Murazi [~Anabelle8@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 265 seconds]
05:11 -!- jonatack_ [~jon@37.166.238.163] has quit [Ping timeout: 258 seconds]
05:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
06:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
06:16 -!- jonatack [~jon@82.102.27.195] has joined #bitcoin-builds
06:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
06:51 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-builds
06:55 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
07:11 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
07:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
07:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
07:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
08:14 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-builds
08:17 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:59 -!- Netsplit *.net <-> *.split quits: BlueMatt
11:03 -!- Netsplit over, joins: BlueMatt
12:48 < achow101> fanquake: dongcarl: For the macOS 10.14 SDK, does it matter what version of xcode I download?
12:50 < dongcarl> achow101: I'd stick with the one in the README
12:50 < achow101> well what's that?
12:51 < achow101> oh 10.2.1. buried in the commands
12:52 < dongcarl> achow101: yeah it's also specified later with a link. Lmk if you run into trouble
12:52 < achow101> It's not linked
13:24 < hebasto> dongcarl: did you see #18556 ?
13:24 < gribble> https://github.com/bitcoin/bitcoin/issues/18556 | build: Drop make dist in gitian builds by hebasto · Pull Request #18556 · bitcoin/bitcoin · GitHub
14:26 < achow101> I'm trying to do the macos 0.20.rc1 gitian build and I keep running into "fatal error: 'unistd.h' file not found"
14:26 < achow101> any ideas
14:40 < hebasto> achow101: do you have the latest SDK in inputs?
14:40 < achow101> yeah
14:40 < achow101> and I checked it has unistd.h
14:56 < fanquake> achow101: is it untarred?
14:56 < achow101> in inputs/ ?
14:57 < fanquake> Yea
14:57 < achow101> no
14:57 < achow101> it's just the MacOSX10.14.sdk.tar.gz that the readme commands produce
14:57 < fanquake> Also check that the folder is named correctly. 10.14.sdk IIRC, you can check in darwin.mk
14:57 < fanquake> Ok, you will need to untar it
14:58 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Ping timeout: 260 seconds]
14:59 < achow101> I thought gitian did that. didn't have to do that with the previous sdk
15:01 < fanquake> Unsure. Lmk if it doesn’t work though
15:02 < achow101> The gitian descriptor expects the tar.gz file
15:02 < fanquake> Then it’s possible that the folder name after it’s untarred is incorrect
15:05 < achow101> ah that's probably it. the naming pattern isn't the same as the 10.11 sdk
15:05 < fanquake> Also I’m 99% sure you can just untar it manually and it’ll work, that’s what I normally do
15:05 < fanquake> Ok
15:25 < achow101> yeah, that worked. so the readme is wrong
15:40 < MarcoFalke> cfields: Are you assuming that multiprocess was merged for 0.20.0rc1?
15:40 < cfields> MarcoFalke: no. It's an enormous change even for master.
15:40 < fanquake> No. We are just confused why it was merged at all
15:40 < cfields> afaik we've never merged a half-decided feature?
15:41 < fanquake> Regardless of the questions Cory posted. Having a single ACK for what is the basis of a major architectural change for a project seems a bit weak.
15:41 < MarcoFalke> I have reviewed the changes as well (not libmultiprocess)
15:42 < MarcoFalke> If it is controversial, it should be reverted
15:42 < cfields> to be clear: I don't have a problem with this way forward afaik. I just think it deserves way more discussion.
15:42 < cfields> Rather, I don't know if I have a problem. I assume anything ryanofsky comes up with is reasonable :)
15:43 < MarcoFalke> It was not clear from the discussion in the pull request that this was not ready
15:44 < cfields> MarcoFalke: I don't see how it can be ready unless the overall approach is agreed upon.
15:46 < MarcoFalke> multiprocess has been discussed for three years as an idea to split the gui from the node (or even longer). I must have missed the discussions that multiprocess is unwanted.
15:47 < MarcoFalke> Or controversial
15:47 < fanquake> As Cory has just mentioned, we can't do it in 0.21.0 anyways, if it requires c++17 ?
15:48 < MarcoFalke> Ok, so the goal is to revert and then schedule for 0.22, together with C++17?
15:48 < fanquake> Given the discussion in #16684
15:48 < gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
15:48 < cfields> MarcoFalke: again, I'm not arguing against the idea. I just don't think the the specifics have been discussed.
15:49 < MarcoFalke> Though, it doesn't require C++17, if the user doesn't ask for it
15:50 < fanquake> MarcoFalke: can you clarify https://github.com/chaincodelabs/libmultiprocess/blob/master/CMakeLists.txt#L84 ?
15:50 < MarcoFalke> fanquake: If you opt out of multiprocess, which is the default, you can go with C++11
15:51 < cfields> So we've merged something we can't build?
15:51 < fanquake> Sure, but that means we can't actually use multiprocess until after c++17 is a requirement for the project.
15:51 < MarcoFalke> cfields: Gitian could use it
15:52 < MarcoFalke> Aren't we building releases for 0.21.0 with C++17?
15:52 < MarcoFalke> The project stays at C++11
15:53 < MarcoFalke> Ok, to sum up: People like multiprocess as a concept, but the current implementation was not agree upon?
15:53 < MarcoFalke> *agreed
15:53 < ryanofsky> cfields, just to make sure there's no confusion, you know the whole multiprocess feature is implemented to be an optional add-on?
15:54 < ryanofsky> it's not like there's a switch from single process to multiprocess, it's an option to build a new set of binaries alongside existing ones
15:57 < MarcoFalke> ryanofsky: I think the disagreement is mostly about the additions to the depends/bitcoind Makefile and general concerns about libmultiprocess being ready
15:58 < ryanofsky> right but this doesn't seem that different than the build change that added support for rapidcheck
15:58 < ryanofsky> just an optional thing turned off by default that we had build/depends support for
15:59 < cfields> ryanofsky: yes, but again, I thought that approach was at the RFC stage. When I reviewed it, I reviewed it on-merit, without arguing potential alternatives yet.
16:00 < cfields> ryanofsky: I really really don't want to discourage this, that's not my aim. But I doubt I'm alone in being caught off-guard by the merge.
16:00 < ryanofsky> sure, i'm just making sure there isn't some misunderstanding about the change
16:02 < ryanofsky> whatever people think the next steps should be is fine with me
16:07 < MarcoFalke> It is more invasive than rapidcheck, but to me it felt like the same concept: Merge it early when the code has received review, but mark it experimental so that it can be pulled out and reverted quickly if needed.
16:09 < cfields> MarcoFalke: yeah, I see that now. To me, the merge implied a commitment to eventual default-ness because afaik that's the path we've always taken for things like this (thinking of univalue/secp256k1, at least).
16:10 < fanquake> I think it would still be good for someone to outline how they expect this integration to play out. When does it get turned on by default? When do Cores build requirements change? When is review of the libmultiprocess lib/repo happening etc
16:11 < cfields> ^^ +1
16:11 < MarcoFalke> All of this must happen before it is taken out of experimental
16:11 < fanquake> I'd also like to hear any potential alternatives from cfields+others etc
16:12 < MarcoFalke> As long as it is in experimental, a dev must set the flag explicitly to build it
16:12 < MarcoFalke> Maybe this should be discussed in the weekly meeting?
16:12 < MarcoFalke> I mean broader meeting, not the build-meeting
16:13 < cfields> MarcoFalke: I think that'd be a good idea.
16:14 < cfields> ryanofsky: thanks for your infinite patience with this so far.
16:18 < MarcoFalke> Is there anything to do before next weeks meeting? Right now it would be a clean git revert and I think everyone would be ok with reverting it until at least next week's meeting.
16:19 < cfields> MarcoFalke: up to you. I feel heard either way :)
16:20 < ryanofsky> either way's fine with me too
16:20 < MarcoFalke> fanquake: Mind flipping a coin?
16:21 < fanquake> I don't mind leaving it in, looking forward to thrashing all this out in some discussion
16:34 < MarcoFalke> I think I will revert it for now. This is going to help us to wait for more explicit ACKs, since it only has one. (Mine didn't make it in)
16:47 < MarcoFalke> fanquake, ryanofsky, cfields: #18588
16:47 < gribble> https://github.com/bitcoin/bitcoin/issues/18588 | Revert "Merge #16367: Multiprocess build support" by MarcoFalke · Pull Request #18588 · bitcoin/bitcoin · GitHub
16:47 < MarcoFalke> Should be trivial to review ;)
16:48 -!- Jackielove4u_ [uid43977@gateway/web/irccloud.com/x-cmynczamhlrpxplj] has quit [Quit: Connection closed for inactivity]
16:48 < MarcoFalke> diff should be empty
19:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
19:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
20:05 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
20:08 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-builds
20:14 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-builds
20:15 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
20:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
20:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
21:37 -!- molly [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
21:38 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-builds
23:16 -!- mfoolb [~mfoolb@gateway/tor-sasl/mfoolb] has quit [Ping timeout: 240 seconds]
23:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
23:21 -!- mfoolb [~mfoolb@gateway/tor-sasl/mfoolb] has joined #bitcoin-builds
23:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-builds
--- Log closed Sat Apr 11 00:00:49 2020