19:00:11 <wumpus> #startmeeting
19:00:11 <lightningbot> Meeting started Thu Mar 12 19:00:11 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:11 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:19 <MarcoFalke> hi
19:00:21 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
19:00:22 <sipsorcery> hi
19:00:23 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
19:00:25 <kanzure> hi
19:00:26 <jkczyz> hi
19:00:27 <emilengler> hi
19:00:33 <fjahr> hi
19:00:36 <promag> hi
19:00:38 <jonatack> hello
19:00:46 <provoostenator> hi (though distracted)
19:00:57 <hebasto> hi
19:01:01 <wumpus> one proposed topic in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt : PPA URI (luke-jr) if he's here
19:01:07 <achow101> hi
19:01:28 <amiti> hi
19:01:33 <kanzure> other topic: status of coredev.tech survey about meeting options, or any results, or when to expect as much
19:01:42 <kanzure> (i don't have that information)
19:01:50 <luke-jr> here for now
19:01:53 <wumpus> good thing that it was decided to cancel coredev last week, because people from Europe aren't even allowed to travel to the US anymore
19:02:29 <wumpus> #topic Features for 0.20
19:02:49 <sipa> hi
19:02:50 <wumpus> as you might know, the feature freeze for 0.20 is in three days (the 15th)
19:03:34 <wumpus> is there anything in progress, that only needs a bit of review to go, could still be ready before then?
19:03:56 <hebasto> #16224 ?
19:03:58 <gribble> https://github.com/bitcoin/bitcoin/issues/16224 | gui: Bilingual GUI error messages by hebasto · Pull Request #16224 · bitcoin/bitcoin · GitHub
19:04:30 <wumpus> hebasto: yes, good one
19:04:39 <achow101> #17509?
19:04:41 <gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors · Pull Request #17509 · bitcoin/bitcoin · GitHub
19:05:01 <achow101> I'd like #18204 too
19:05:07 <gribble> https://github.com/bitcoin/bitcoin/issues/18204 | descriptors: improve descriptor cache and cache xpubs by achow101 · Pull Request #18204 · bitcoin/bitcoin · GitHub
19:05:12 <emilengler> hebasto: Will review this PR tomorrow
19:05:16 <provoostenator> ^ I'll try to conserve ACKs but can quickly address feedback if needed on
19:05:29 <wumpus> that would be really nice to have
19:07:23 <wumpus> achow101: is 18204 a feature or performance improvement?
19:07:52 <wumpus> (I mean if the latter it could potentially go in after the feature freeze)
19:08:07 <achow101> it can go in after the feature freeze I guess
19:08:28 <achow101> it's really a performance improvement
19:08:41 <sipa> i think it's a weak performance improvement, but also a necessity for descriptor wallets
19:08:51 <wumpus> but it has quite some ACKs, I see, so might not need to wait that long anyhow
19:09:06 <achow101> I just don't want it to get stuck for another few months with 2 acks
19:09:47 <wumpus> it's always ok to remind me if something is almost ready for merge btw no need to wait until the meeting
19:10:53 <wumpus> #topic PPA URI (luke-jr)
19:11:32 <sipa> pinging BlueMatt
19:11:47 <sipa> ah, he's going through airport security
19:11:54 <cncr04s> remove that 3 second wait on the send button
19:12:05 <sipa> ?
19:12:05 <cncr04s> or at least add an option
19:12:06 <wumpus> I'll let BlueMatt and luke-jr fight this out
19:12:16 <MarcoFalke> I think the only question was whether to use deterministic builds or not
19:12:28 <MarcoFalke> I can't see an argument for non-deterministic builds
19:12:36 <sipa> and whether we want to support PPAs at all
19:12:43 <wumpus> I think that's the main question
19:12:55 <achow101> there's various documentation written by other people that refer to the ppa
19:13:24 <sipa> if we can make the PPA deterministic (or even identical to the release builds), that would be ideal
19:13:53 <wumpus> yes, definitely
19:13:54 <luke-jr> I am maintaining the PPA
19:14:03 <sipa> <BlueMatt> Note that ppa has two series’ of issues that releases did not: GUI issues that persisted for two releases and weren’t ever solved and the 32-bit test failures.
19:14:13 <luke-jr> I don't really know why anyone else needs to be involved in this fact..
19:14:25 <sipa> <BlueMatt> The second one especially scares me
19:14:36 <wumpus> what do you need from us then?
19:14:37 <luke-jr> the only question in my mind is whether it should remain at 'bitcoin' as some have suggested, or move to my own launchpad
19:14:37 <MarcoFalke> That was the gcc compiler bug
19:14:54 <sipa> <BlueMatt> But if people want it, it should be maintained as a part of the packaging repo
19:15:10 <achow101> I think it should remain at 'bitcoin' as that's where a bunch of docs that mention the ppa point to
19:15:29 <luke-jr> BlueMatt seems to not only want to stop maitnaining it, but also suppress others from doing so. hence the meeting topic
19:16:01 <MarcoFalke> I think we shouldn't offer software that is impossible to audit
19:16:37 <MarcoFalke> determinisitic builds in the ppa are fine, though
19:16:37 <wumpus> well the "bitcoin" PPA is his so as for maintining that that's his decision, if you maintain youre own somewhere else that's fine, but we likely won't link to it
19:16:57 <wumpus> (we never even linked from the repo to his ppa either afaik)
19:17:22 <sipa> bitcoincore
19:17:32 <achow101> wumpus: the ppa has been linked to before from both our repo and bitcoincore.org. those were removed, but it has been "official"
19:17:47 <sipa> bitcoincore.org or bitcoin.org linked to it as a way of installing
19:18:01 <MarcoFalke> Yes, I remember removing that link
19:18:05 <wumpus> achow101: I think the ppa was only linked as a means to install bdb4
19:18:16 <wumpus> oh okay
19:19:33 <MarcoFalke> I think there is no one objecting a ppa that wraps our normal release builds
19:19:45 <wumpus> like the snap does, right?
19:20:07 <MarcoFalke> jup
19:20:29 <MarcoFalke> But some people don't like the snap, because it doesn't install it in the "classic" location etc
19:20:57 <luke-jr> … how much of that made it :/
19:21:09 <luke-jr> Canonical is ultimately responsible for the PPA builds
19:21:09 <sipa> it's also not what you'd get by building from source and knstalling
19:21:22 <luke-jr> the gitian builds are terrible; they have a purpose, sure, but they're not even close to what users ideally would use
19:21:24 <wumpus> luke-jr: your last message was "BlueMatt seems to not only want to stop maitnaining it, but also suppress others from doing so. hence the meeting topic"
19:21:25 <luke-jr> the PPA is built by the OS vendor, and produces binaries specifically for the OS
19:21:44 <luke-jr> wumpus: after that was [19:16:12] <luke-jr> so I guess the questions are 1) do we want to keep the PPA at the old URI, and 2) can we satisfy BlueMatt to allow that?
19:21:49 <wumpus> make the gitian builds less horrible then
19:21:59 <luke-jr> wumpus: that's incompatible with the goal of them
19:22:03 <wumpus> it's what everything is based on and the only auditable one
19:22:13 <luke-jr> wumpus: gitian builds are intended to run anywhere, but that's incompatible with being targetted to a specific distro
19:22:39 <achow101> luke-jr: how so? something that runs anywhere should also run on a specific distro
19:22:46 * dongcarl is so confused
19:22:49 <MarcoFalke> agree with achow101
19:22:57 <sipa> luke-jr: just because of UI theming etc?
19:22:58 <luke-jr> achow101: ideally, binaries should dynamic link to system libraries for ~everything
19:23:01 <wumpus> things like GUI costomization/integration I guess
19:23:10 <luke-jr> sipa: that's a symptom
19:23:26 <wumpus> not that that ever worked well for the PPA
19:23:37 <wumpus> we had more UI issues with the PPA than ever with the gitian builds
19:23:43 <sipa> seema like a small price to pay for auditabke builds
19:23:47 <achow101> luke-jr: but we don't necessarily support the specific system libraries that may be installed
19:23:50 <sipa> sorry, car tyoing
19:23:50 <luke-jr> nobody is suggesting removing the gitian option
19:23:51 <achow101> there may be version differences, etc.
19:23:58 <luke-jr> achow101: we do
19:24:03 <wumpus> although at least the crazyness with ubuntu unity is gone now
19:24:05 <luke-jr> achow101: the preferred install is from source
19:24:35 <luke-jr> achow101: (and PPAs don't support distros without the required versions)
19:25:14 <luke-jr> logical order of preference, for an Ubuntu user, is build-from-source > PPA > gitian
19:25:23 <wumpus> but I agree with sipa, deterministic builds are worth a little bit of GUI integration annoyance
19:25:29 <MarcoFalke> If someone really wants to use the system libs, why can't they build from source?
19:25:37 <luke-jr> it might be nice if we could deterministically make the PPA debs, but Launchpad doesn't support that
19:25:47 <achow101> if a distro version lacks the requisite system libs, gitian would still work there, no? I think that's a good thing
19:25:49 <luke-jr> MarcoFalke: many users don't know how, or don't want to spend the time
19:25:50 <dongcarl> Very naive thought: is it possible to have 2 PPAs, 1 for gitian built binaries, 1 for specifically OS-integrated?
19:25:57 <luke-jr> achow101: absolutely
19:26:05 <MarcoFalke> dongcarl: I'd support that
19:26:08 <luke-jr> achow101: PPAs are not a replacement for gitian, they are an alternative for certain users
19:26:17 <luke-jr> dongcarl: should be
19:26:24 <MarcoFalke> bitcoin/bitcoin would be deterministic and luke-jr/bitcoin is built with system libs
19:26:25 <luke-jr> dongcarl: sounds like a good idea, even
19:26:33 <luke-jr> MarcoFalke: that seems backward
19:26:46 <luke-jr> bitcoin/bitcoin has always been system libs
19:27:00 <sipa> luke-jr: you seem to be the only one arguing for system libs
19:27:14 <luke-jr> sipa: so?
19:27:17 <achow101> I think anything "official" should only be determinisitic
19:27:22 <MarcoFalke> agree
19:27:23 <sipa> agree
19:27:24 <wumpus> achow101: +1
19:28:01 <dongcarl> agree
19:28:12 <fanquake> +1
19:28:13 <luke-jr> achow101: why?
19:28:20 <luke-jr> Distro-built is equivalent security
19:28:31 <luke-jr> if your distro is compromised, a gitian build won't help you
19:28:36 <wumpus> because it's the only one we can vouch for based on the sha256 hashes
19:28:58 <MarcoFalke> luke-jr: We are talking about the ppa infrastructure being compromised, not the normal package build infra
19:29:07 <luke-jr> MarcoFalke: isn't it the same?
19:29:18 <MarcoFalke> I hope for Ubuntu that they are different, at least different datacenters
19:29:34 <sipa> MarcoFalke: i doubt that
19:29:45 <wumpus> so I think we've pretty much reached an agreement here, any other topics?
19:29:47 <luke-jr> anyway, how about adding a disclaimer to the effect of "These are built by Canonical, not the Bitcoin Core project"?
19:29:48 <achow101> luke-jr: how is it the same?
19:30:01 <luke-jr> achow101: PPAs are built by Canonical
19:30:12 <sipa> luke-jr: and maintained by the PPA maintainer
19:30:33 <wumpus> yes but their build infrastructure runs arbitrary builds of arbitrary software, in the PPA case, so it's not that far fetched it could be compromised
19:30:39 <luke-jr> sipa: just like the snaps are..
19:30:56 <MarcoFalke> luke-jr: The snap you can check against the signed hash
19:31:11 <luke-jr> MarcoFalke: our website says you can't last I checked
19:31:13 <wumpus> right, the snap packages the gitian-built executables so you can verify them in the same way
19:31:27 <MarcoFalke> luke-jr: I coldn't find a cross-platform way to do it
19:31:45 <MarcoFalke> But on my machine it works last time I tried
19:31:53 <wumpus> this would also be true for a PPA that packages the gitian-built binaries
19:32:22 <jonatack> wumpus: I am not sure the blockers are a topic this week, but FWIW it looks like #16426 is currently replaced by #17954
19:32:26 <gribble> https://github.com/bitcoin/bitcoin/issues/16426 | Reverse cs_main, cs_wallet lock order and reduce cs_main locking by ariard · Pull Request #16426 · bitcoin/bitcoin · GitHub
19:32:29 <gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub
19:32:44 <luke-jr> MarcoFalke: it verifies the entire snap, not just the chosen binaries installed?
19:32:45 <jonatack> which, by mutual agreement of the PR authors, apparently should be merged in first
19:33:03 <wumpus> jonatack: I've forgone blockers because of focusing on things that need to go in before the feature freeze which is imminent, but sure I'll swap them
19:33:05 <luke-jr> I'm not entirely sure what argument sipa is trying to make..
19:33:20 <MarcoFalke> luke-jr: Of course you'd still have to trust the snapd
19:33:30 <luke-jr> there is no way I could as maintainer compromise the PPA without it being publicly visible
19:34:31 <achow101> but it's possible for canonical to compromise it invisibly
19:34:37 <luke-jr> achow101: absolutely.
19:34:42 <luke-jr> just like they can compromise the OS
19:34:52 <luke-jr> in which case gitian does no good to prevent it
19:35:54 <achow101> but at least users can verify that the ppa was not compromised with gitian
19:36:03 <hebasto> are any estimation of a ppa share among all users?
19:36:06 <achow101> and IIRC, PPAs can still be used on ubuntu derivatives
19:36:14 <achow101> and other distros which are not necessarily canonical
19:36:19 <luke-jr> hebasto: very few have noticed the URI changed
19:36:30 <sipa> luke-jr: it didn't cba ge
19:36:37 <sipa> it was discontinued
19:36:47 <luke-jr> sipa: no, I am still maintaining it
19:36:47 <sipa> you have your own PPA
19:37:32 <luke-jr> hebasto: 2019-09, there were still around 8000 users of the PPA at bitcoin/bitcoin
19:37:53 <wumpus> so we already discussed a compromise acceptable with most people here (two PPAs), I'm not sure it makes sense to continue arguing this
19:37:56 <luke-jr> who are now stuck on 0.18.0 until they switch to the new PPA
19:38:40 <luke-jr> wumpus: anyone can make a 2nd PPA, but I'm not sure there's a need with the snap doing the gitian binaries already
19:38:43 <sipa> maybe we should, until we resolve this, push an update to the PPA that installs a binary that just prints "this is not maintained, see page X"
19:38:56 <luke-jr> sipa: or at least deletes the binary
19:39:02 <sipa> right
19:39:29 <sipa> i agree there are probably people stuck at 0.18 by not noticing the ppa page that says it's not maintained
19:39:30 <luke-jr> maybe less invasive to patch 0.18.0 with a message, but.. not sure I like the idea of doing a known-vulnerable "release"
19:39:31 <wumpus> at least make sure it doesn't delete the wallet ...
19:39:55 <sipa> wumpus: i don't think system installs can delete user files
19:40:18 <wumpus> sipa: I think that was a risk wit hthe snap at some point
19:40:22 <luke-jr> I guess that's one potentially scary thing about Snaps
19:40:24 <luke-jr> yeah
19:40:31 <sipa> wumpus: i know nothing about snap
19:40:39 <luke-jr> sipa: it's basically a chroot AIUI
19:40:58 <wumpus> but yes unintalling a deb shouldn't remove user files (or even system configuration files without --purge)
19:41:16 <MarcoFalke> Snap creates a snapshot of your wallet on uninstall
19:41:32 <sipa> MarcoFalke: scary
19:41:37 <luke-jr> I suppose that might be a reason to support a second gitian-binary PPA
19:41:59 <MarcoFalke> sipa: Less scary than deleting it
19:42:07 <sipa> fair
19:42:13 <luke-jr> back to the original topic though, bitcoin/bitcoin seems like a bad URI IMO
19:42:25 <luke-jr> bumping it with a move message seems like a good solution
19:42:35 <luke-jr> and that can refer to the two new PPAs with clarification of distinction
19:42:36 <luke-jr> ?
19:43:19 <luke-jr> could be luke-jr/bitcoincore & luke-jr/bitcoincore-deterministic, or bitcoincore/bitcoincore-{system,deterministic} or something along those lines?
19:43:43 <luke-jr> (not promising I'll make the gitian binary PPA - just throwing out ideas for discussion)
19:44:02 <luke-jr> advantage of the former is that it's obvious who maintains it; but the latter will work even if multiple people or maintainers change
19:44:22 <achow101> I think we have to keep bitcoin/bitcoin just to keep existing docs working and not confusing existing users further
19:44:28 <luke-jr> downside of the latter is it implies the project is responsible for it, which seems undesirable
19:45:06 <wumpus> if there's two PPAs then docs have to be updated anyway
19:45:09 <luke-jr> achow101: currently only BlueMatt has a monopoly on the 'bitcoin' name
19:45:22 <wumpus> WITH documentation on what the choice is and why
19:45:44 <luke-jr> even providing a notice-bump on the old PPA will require BlueMatt's cooperation
19:47:13 <MarcoFalke> In launchpad it is possible to change the email address to something@bitcoincore.org, so that whoever has access to that can reset it
19:47:27 <MarcoFalke> That is how I set up the snap
19:49:02 <luke-jr> MarcoFalke: I don't know how BlueMatt setup the Launchpad stuff - I suspect the account is his personal account, and ~bitcoin is just a team with only him
19:49:11 <luke-jr> would be nice if we could come to some agreement here to present to BlueMatt.. maybe "two new PPAs, and bump bitcoin/bitcoin with a notice"?
19:49:51 <luke-jr> actually, notice should mention the gitian builds and Snap too for completeness IMO
19:51:14 <wumpus> yes +1 with adding a notice to bitcoin/bitcoin at least, no matter if there's any new PPAs
19:52:01 <luke-jr> it would be IMO absurd to say that BlueMatt is allowed to maintain a PPA and I am not
19:52:55 <luke-jr> (which is what would be implied by refusing to tell users of the new URI)
19:52:56 <wumpus> well we all think an 'official' PPA should be built from the gitian-built binaries, and you disagree with that, so that's not entirely unexpected
19:53:20 <luke-jr> wumpus: it never has been
19:53:21 <ryanofsky> does PPA require a single maintainer? with snaps we have a github packaging repository that gets normal review and a something@bitcoincore.org owner like marco mentioned
19:53:40 <luke-jr> ryanofsky: the PPA stuff is in the same repo
19:54:01 <luke-jr> ryanofsky: I have a PR open for the gitian YML that submits it to Canonical, but nobody seem to care to review it
19:54:49 <wumpus> that's another point to simply package the gitain-built binaries; it doens't require as much maintenance or separate testing
19:54:49 <ryanofsky> oh, well it seems kind of important to get that merged so we can have multiple maintainers
19:54:53 <MarcoFalke> luke-jr: It seems to be pending on the further steps we take
19:55:18 <luke-jr> ryanofsky: I wasn't aware anyone else was interested ;)
19:56:10 <luke-jr> MarcoFalke: ultimately, it's a question of whether someone is trying to dictate to users how they use Core, or let them make an informed decision
19:57:21 <luke-jr> it'd be one thing if nobody was willing to maintain the PPA at all; it's another to try to stop someone
19:57:59 <wumpus> well you're maintaining it, we're definitely not able to stop you doing that
19:58:28 <wumpus> or even interested in doing so
19:58:42 <MarcoFalke> Filed an issue here: https://github.com/bitcoin-core/packaging/issues/36
19:58:43 <luke-jr> wumpus: right, but it's also inappropriate to suddenly pretend it doesn't exist, or block users from finding it
19:59:02 <wumpus> the point is *if* you want 'official' recognition for it, you'll also have to have other people agree with you how to do things
19:59:23 <wumpus> if you do it your own way in your own ppa, fine, topic closed :)
19:59:37 <wumpus> #endmeeting