< fanquake>
wumpus From what I could see, brew tries to upgrade Python, but fails during the linking step, so I assumed it was related to that. I can have a proper look into it tonight given it's affecting everything.
< elichai2>
how do people feel about some re-organizing includes such that we "include only what we use"? (hopefully it will make compilation faster and make it more obvious what parts are still highly connected)
< elichai2>
ha thanks :) well IWYU itself has a problem with boost. boost isn't built with the IWYU idea in mind
< elichai2>
I assume we still want the `fs.h` separation even though it can increase compile time? (a lot of units only need the path.hpp and not the whole fs)
< Chris_Stewart_5>
Is there a document anywhere on bitcoin core's key handling and storage procedures? Or is this a "read the code" situation?
< wumpus>
after filesystem lands in c++ itself and we can use that, we can discuss splitting it up (depending on how the standard library does it), but before that this is supposed to abstract out that particular boost usage
< elichai2>
makes sense
< wumpus>
(also, having the fs functions in one header is useful for sandboxing platforms that don't have direct file access)
< wumpus>
MarcoFalke: I'm okay with doing a meeting today
< elichai2>
MarcoFalke: how do you feel about the `for XXXX` comments IWYU leaves?
< MarcoFalke>
elichai2: spammy unless a header is used for 3 things or less
< elichai2>
and easily gets out of date
< MarcoFalke>
Jup
< MarcoFalke>
I guess most useful would be documentation on how to run it on a single file (e.g. a freshly created file)
< elichai2>
that's the easiest actually. but still requires fixing the problems it makes
< elichai2>
I want to make a PR showing how the changes look, altough this is something that isn't reviewable easily
< elichai2>
where should I document how to use this?
< MarcoFalke>
Maybe in my issue or in our developer docs
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
< sipa>
From Wikipedia, the free encyclopedia. HNY may refer to: Happy New Year (2014 film) Hengyang Nanyue Airport, IATA code HNY.
< gleb>
Hi
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
< sipa>
must be heavy on their poor Ruby infrastructure
< sipa>
MarcoFalke: ^
< MarcoFalke>
So packaging is still an unsolved problem for Linux distros. We stopped maintaining the Ubuntu PPA due to numerous problems and provided flatpak and snapcraft packages.
< wumpus>
oh, the ppa is no longer maintained?
< MarcoFalke>
Though, that uncovered other issues
< luke-jr>
MarcoFalke: Matt stopped maintaining the PPA. I didn't.
< luke-jr>
wumpus: the bitcoin/bitcoin one Matt used to have is unmaintained now
< MarcoFalke>
luke-jr: There are still issues with the ppa, even if maintained.
< wumpus>
yes, if it was just a matter of maintenance we could try to find someone else to do it
< achow101>
what are the issues?
< luke-jr>
IMO flatpak/snapcraft aren't comparable, but go on
< MarcoFalke>
achow101: On the top of my head: * not reproducible builds, no way to verify what happened on the build servers. * People installing the ubuntu ppa on non-ubuntu distros (https://wiki.debian.org/DontBreakDebian )
< luke-jr>
(non-determinism isn't an issue IMO since it's built by the distro co)
< wumpus>
is there a ppa-like system for debian?
< luke-jr>
wumpus: you can manually add repos, but nothing as easy as PPA AFAIK :/
< MarcoFalke>
* The ppa is also updated only after the OS has been released, so upgrading the Ubuntu might lead to issues
< luke-jr>
QuickBuild.io provides PPAs for Debian, but in my experience they don't work :/
< luke-jr>
MarcoFalke: I don'
< luke-jr>
MarcoFalke: I don't understand what you mean there
< MarcoFalke>
* The ppa only supports one version of Bitcoin Core, so (not) updating Bitcoin Core might lead to issues
< wumpus>
I'm interested in that problem, yes, auto-update kind of sucks for bitcoin
< wumpus>
it should be a user decision to upgrade
< luke-jr>
auto-update is the entire point of PPAs, though
< MarcoFalke>
luke-jr: The ppa was only compiled for (let's say Ubuntu 18.04 after it has been released. I.e. Apr 18) So it is harder to install it for the Ubuntu Beta?
< wumpus>
could we do better?
< luke-jr>
MarcoFalke: not if we update the PPA timely
< wumpus>
(apart from having a new package for every new release0
< jamesob>
Wouldn't it be better just to provide a shell script that people can curl that builds from source than trying to cater to bad distro build infra?
< luke-jr>
jamesob: eww, no
< achow101>
MarcoFalke: is your suggestion that we also build debs and upload them to bitcoincore.org?
< wumpus>
I mean ,we already have binary builds for linux
< wumpus>
they should work on most distros
< wumpus>
definitely debian and fedora
< luke-jr>
I've been keeping an archive of PPA-generated .debs locally FWIW
< jamesob>
Yeah, so what's wrong with saying "ppa build infra isn't up to our standards, so go to these other places"
< luke-jr>
wumpus: they only work on Ubuntu in my experience; at least not on Gentoo
< wumpus>
the only exception really is non-glibc
< MarcoFalke>
luke-jr: Are you volunteering to update the PPA timely for the full matrix of distros/version of Bitcoin Core?
< luke-jr>
jamesob: I see no problem w/ the build infra
< jamesob>
didn't someone say the buids aren't reproducible?
< luke-jr>
MarcoFalke: I can only update the PPA for Launchpad-supported distros, but yes, I have been and intend to continue updating it
< luke-jr>
jamesob: neither is the rest of the OS
< luke-jr>
jamesob: PPAs are Canonical built for Canonical distros
< wumpus>
so anyway: what is the proposal here?
< MarcoFalke>
And also, PPAs are not friendly for new users (novice linux users). E.g. I avoid them because it is easy to break the whole system with them.
< MarcoFalke>
wumpus: My proposal is to have vanilla packages
< wumpus>
how would you do that?
< MarcoFalke>
in the vanilla package manager of the distro
< luke-jr>
MarcoFalke: we explicitly advise distros NOT to do that..
< wumpus>
that's up to the distros, right?
< luke-jr>
also, that has the same problems as the PPA?
< MarcoFalke>
luke-jr: Why?
< luke-jr>
MarcoFalke: 1) their LevelDB packages don't meet consensus-safety standards, and they will not use embedded copies
< luke-jr>
MarcoFalke: 2) they won't deploy even minor fixes to stable versions
< fanquake>
Hi
< * luke-jr>
looks up our advisement to see if there's anything else
< MarcoFalke>
1) We release versions of Bitcoin Core with different versions of leveldb. So the versioning shouldnt' be an issue. If the packaging is an issue, it can be changed, maybe
< wumpus>
bleh, not using the embedded leveldb would really be inadvisable
< MarcoFalke>
2) Releasing new versions can be done with "backports", like it is done with clang-8 on Bionic Ubuntu and security fixes are alwasy deployed
< luke-jr>
MarcoFalke: backports are no less trouble than PPAs
< luke-jr>
PPAs are better because users already have them
< luke-jr>
(for the initial install)
< luke-jr>
also, the existence of bad PPAs doesn't mean *our* PPAs need to be bad; and not using a PPA ourselves doesn't make the bad ones go away
< MarcoFalke>
PPAs are bad pratice in general
< luke-jr>
they aren't
< wumpus>
I don't think PPAs are bad practice in general, not on ubuntu at least, installing them to other distros like debian is obviously bad
< MarcoFalke>
And the bitcoin Core PPA is being used against best practices, so providing one is like encouraging those bad practices
< sipa>
MarcoFalke: what do you mean by that (just curious, i know very little about them)
< luke-jr>
yes, PPAs target a specific distro/release and shouldn't be used on others
< wumpus>
in any case, I think we need to be really careful to reconsider the advisement
< wumpus>
we don't want zillions of nodes running years-old software by accident, not because they want to but just because there's no upgrade path
< MarcoFalke>
sipa: PPAs are usually compiled for a specific OS version and might break things if installed on a different OS version. E.g. install an Bionic ppa on Ubuntu 19.10 or even Debian
< sipa>
agreed
< luke-jr>
distro packages are likely to end up with *new* users installing obsolete versions
< sipa>
luke-jr: perhaps - but is that really the alternative? given things like snap/flatpak?
< wumpus>
MarcoFalke: at least the ppa-add script avoids that, it will only add the ppa for the release that a user has
< MarcoFalke>
Ok, so if the preference is to stick with PPAs, we should maintain them
< luke-jr>
sipa: that's the topic ;)
< sipa>
luke-jr: i think a reasonable conclusion could be that for our use case both distro packages and PPAs are bad
< luke-jr>
sipa: PPAs aren't bad though.. :/
< luke-jr>
yes, they're targetted, but that's kinda the point
< sipa>
luke-jr: i said for our use case
< wumpus>
I'm not convinced PPAs are really bad
< sipa>
if they result in people running old unupgradable versions
< luke-jr>
sipa: they don't
< wumpus>
though I prefer people to use the deterministic binaries from bitcoincore.org
< luke-jr>
PPAs can be updated for every release
< wumpus>
but distro packages wouldn't improve that
< luke-jr>
every Core release*
< MarcoFalke>
Well, some people use curl $latest_release, so they end up with no upgrade path through $package_manager update
< luke-jr>
sipa: for example, my PPA currently has 0.19.0.1 for every supported Ubuntu version; when 0.19.1 is out, it will get that for all versions too
< wumpus>
no, PPAs (at least used to) be updated with every release of core
< sipa>
ok
< MarcoFalke>
So I don't really like the bitcoincore.org/bin/* either
< wumpus>
the bitcoin/bitcoin ones are unmaintained at the moment but that's not a fault in PPA
< wumpus>
well, nothing is ideal
< luke-jr>
I suppose I could update bitcoin/bitcoin if Matt wants to give me access - I just figured it made more sense to retire it
< MarcoFalke>
wumpus: True :)
< luke-jr>
perhaps it should be updated with a .txt package saying to switch to another source
< bitcoin-git>
bitcoin/master 4d88c3d Wladimir J. van der Laan: net: Log to net category for exceptions in ProcessMessages
< bitcoin-git>
bitcoin/master 4bdd68f Wladimir J. van der Laan: Add missing typeinfo includes
< bitcoin-git>
bitcoin/master 190a405 Wladimir J. van der Laan: Merge #17762: net: Log to net category for exceptions in ProcessMessages
< bitcoin-git>
[bitcoin] laanwj merged pull request #17762: net: Log to net category for exceptions in ProcessMessages (master...2019_12_network_exceptions) https://github.com/bitcoin/bitcoin/pull/17762
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17851: tests: Add std::to_string to list of locale dependent functions (master...locale-dependence-of-to_string) https://github.com/bitcoin/bitcoin/pull/17851