< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17409: build: Avoid hardcoded libfaketime dir in gitian (master...1911-gitianArm64) https://github.com/bitcoin/bitcoin/pull/17409
< wumpus> nice, travis is green for leveldb+crc32b
< sipa> wumpus: \o/
< bitcoin-git> [bitcoin] laanwj opened pull request #17410: Rename `db` log category to `walletdb` (like `coindb`) (master...2019_11_rename_db_log_category) https://github.com/bitcoin/bitcoin/pull/17410
< bitcoin-git> [bitcoin] laanwj opened pull request #17411: doc: Add some better examples for scripted diff (master...2019_11_scripted_diff_examples) https://github.com/bitcoin/bitcoin/pull/17411
< bitcoin-git> [bitcoin] Sjors opened pull request #17412: Add Boost::Process to AppVeyor dependencies (master...2019/11/msvc_boost_process) https://github.com/bitcoin/bitcoin/pull/17412
< wumpus> so yes maybe it's better to sort out the linters instead of moving around things in the tree, trying with "good first issue"... https://github.com/bitcoin/bitcoin/issues/17413
< wumpus> is there a way to see what appveyor is currently doing? I see only 'queued' PRs, even under history
< wumpus> "Current build" is in queued state too
< wumpus> BlueMatt: https://github.com/bitcoin/bitcoin/pull/15382#issuecomment-551451359 kind of reminds me what has bothing me about the rust stuff; I think the build system there also needs to focus on features, not "use rust or not", don't group them on programmings language/dependency; if someone wants to enable a feature that happens to be implemented in rust, request them to install a rust compiler :)
< wumpus> this is also why we have with-gui, not with-qt
< wumpus> though admittedly, the default there is auto, which sets it to enabled or not based on whether qt development package is installed, which is used as a proxy for 'is this a headless server or a desktop', I guess ...
< wumpus> as said I'm somewhat skeptical at those kinds of attempts to detect what the user wants
< elichai2> wumpus: I actually don't completely on that. for a long time I didn't understood a thing about bitcoin's build system and/or code and I liked that it installed basically everything I could manage (I'm one of those freaks who likes the GUI :) )
< elichai2> I think currently the build system is bloated with options such that there's no way for a naive user to even *know* what he can enable/disable
< elichai2> (though maybe auto detection isn't the right answer but splitting features into "normal" and "advanced" is the better answer )
< bitcoin-git> [bitcoin] meshcollider pushed 10 commits to master: https://github.com/bitcoin/bitcoin/compare/2fb6140d585f...99ab3a72c5ff
< bitcoin-git> bitcoin/master 10b4729 Antoine Riard: Pass block height in Chain::BlockConnected/Chain::BlockDisconnected
< bitcoin-git> bitcoin/master 5aacc3e Antoine Riard: Add m_last_block_processed_height field in CWallet
< bitcoin-git> bitcoin/master 9700fcb Antoine Riard: Replace CWalletTx::SetConf by Confirmation initialization list
< bitcoin-git> [bitcoin] meshcollider merged pull request #15931: Remove GetDepthInMainChain dependency on locked chain interface (master...2019-04-remove-external-locking) https://github.com/bitcoin/bitcoin/pull/15931
< wumpus> elichai2: sure, but how does features things based on what dependencies you happen to have installed help with that?
< wumpus> picking features*
< elichai2> wumpus: that you somehow ends up with a lot of features that at least some of them you want? :P
< elichai2> (i.e. I remember installing qt and then compiling core so I can get the GUI, and if I didn't get it I knew my QT is missing)
< wumpus> like, for example the wallet, we assume someone wants a wallet unless --disable-wallet is provided. I think that is great.
< wumpus> wouldn't it be wtf if it was determined based on whether someone has bdb headers installed
< wumpus> no, if you don't have bdb headers installed, and don't provide --disable-wallet, you get a clear message
< wumpus> so you can choose, you want a wallet and install the headers, or disable it and don't
< wumpus> a bloated build system is a different problem, and I agree it wouldn't be great if you would have to do that for 500 different things, but choosing automatically based on the phase of the moon just *hides* that problem
< elichai2> yeah but I think for the wallet 90% of users want it. GUI 50%, and then the rest idk (even those this is 100% guess according to users I know heh)
< wumpus> for a while I was frustrated that for example, tor wouldn't pass configure unless some documentation building thing is installed, or --no-docs is passed. But I think it makes sense now. Most people (should) want documentation, and having *random documentation generator* not installed doesn't automatically mean you don't.
< wumpus> and if you really don't, then tell it...
< wumpus> the only thing that makes this behavior somewhat acceptable is the summary at the end of configure :)
< wumpus> because at least you see what automatic choices it made, before you start building and conclude you're building a GUI you don't want, for ex.
< elichai2> yeah. if you're already venting, I hate that setting CFLAGS/CPPFLAGS/CC/CXX can sometimes break the configure
< wumpus> well if you set some insane flags like --no-stdlib that's expected :)
< elichai2> It happened to me a when I tried to switch a linker but ???
< bitcoin-git> [bitcoin] sipsorcery opened pull request #17416: Appveyor improvement - adds check for all required vcpkg packages (master...check-missing-vcpkgs) https://github.com/bitcoin/bitcoin/pull/17416
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/99ab3a72c5ff...4a3b6f47cd75
< bitcoin-git> bitcoin/master 01f45dd Joao Barbosa: wallet: Avoid recursive lock in CWallet::SetUsedDestinationState
< bitcoin-git> bitcoin/master 0b75a7f Joao Barbosa: wallet: Reuse existing batch in CWallet::SetUsedDestinationState
< bitcoin-git> bitcoin/master 4a3b6f4 fanquake: Merge #17354: wallet: Tidy CWallet::SetUsedDestinationState
< bitcoin-git> [bitcoin] fanquake merged pull request #17354: wallet: Tidy CWallet::SetUsedDestinationState (master...2019-11-setuseddestinationstate) https://github.com/bitcoin/bitcoin/pull/17354
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4a3b6f47cd75...8021392b825c
< bitcoin-git> bitcoin/master fad1de6 MarcoFalke: wallet: Remove unused boost::this_thread::interruption_point
< bitcoin-git> bitcoin/master 8021392 fanquake: Merge #17405: wallet: Remove unused boost::this_thread::interruption_point...
< bitcoin-git> [bitcoin] fanquake merged pull request #17405: wallet: Remove unused boost::this_thread::interruption_point (master...1911-walletNoBoost) https://github.com/bitcoin/bitcoin/pull/17405
< bitcoin-git> [bitcoin] fanquake opened pull request #17417: [0.19] cli: fix -getinfo output when compiled with no wallet (0.19...backport_17368_019) https://github.com/bitcoin/bitcoin/pull/17417
< bitcoin-git> [bitcoin] fanquake closed pull request #17412: Add Boost::Process to AppVeyor dependencies (master...2019/11/msvc_boost_process) https://github.com/bitcoin/bitcoin/pull/17412
< bitcoin-git> [bitcoin] RandyMcMillan opened pull request #17418: Build: add REPO_SLUG to fix errors in forked builds (master...repo-slug) https://github.com/bitcoin/bitcoin/pull/17418
< michaelfolkson> With the PR review club we often need to look back on old PRs that have been merged (in some cases years ago). Any thoughts (especially from maintainers, long term contributors) on asking questions or adding links/resources on a closed PR for educational purposes? Or is this too noisy and you'd prefer to not have activity on PRs once merged/closed?
< michaelfolkson> An alternative would be to ask a question on StackExchange referring to a particular PR. That would be preferable right?
< emilengler> michaelfolkson: We could create a masterthread issue on the main repo
< emilengler> And then we could link older PRs as well
< emilengler> If you look the older PR you will se that it got mentioned but IIRC no party will get a notification
< emilengler> And it is not counted as activity in that PR as well IIRC
< michaelfolkson> The no notifications sounds good. What is a masterthread issue though? A issue label "masterthread" which doesn't notify anyone? You'd set up a new issue each time you have a question on a PR? Or an issue is set up mapping to one particular PR and then all discussion for that PR is on that one issue?
< michaelfolkson> For anybody who knows about policy language, Miniscript just posted this on Bitcoin StackExchange https://bitcoin.stackexchange.com/questions/91565/what-does-bitcoin-policy-language-offer-the-developer-that-miniscript-doesnt-w
< instagibbs> ##miniscript is the place
< instagibbs> x-posted the link there
< michaelfolkson> Ah cool thanks <instagibbs>
< Bullit> Where Bernstein was a conglomerate in Aberdeen
< BlueMatt> wumpus: hmmm...could do a experimental-anticensorship-features or so, but there was some discussion of doing a gbt replacement in rust, too
< BlueMatt> which....
< BlueMatt> so, leaves me without a *great* name for it
< BlueMatt> but happy to rename it to something else if you have an idea
< sipsorcery> @fanquake you around? PR's #17412 and #17416 are a little bit orthogonal.
< gribble> https://github.com/bitcoin/bitcoin/issues/17412 | Add Boost::Process to AppVeyor dependencies by Sjors . Pull Request #17412 . bitcoin/bitcoin . GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17416 | Appveyor improvement - adds check for all required vcpkg packages by sipsorcery . Pull Request #17416 . bitcoin/bitcoin . GitHub
< fanquake> sipsorcery: yea
< sipsorcery> 17416 is a fix to allow new vcpkg's to be added without needing the appveyor cache to be invalidated.
< sipsorcery> 17412 is adding the specific package boost-process to the list of packages.
< fanquake> Yes, but isn't the reason 17412 is required because of the issue 17416 is fixing? Otherwise I don't understand why the boost packages need to be added in advance.
< sipsorcery> no. at least I don't think so.
< fanquake> I'd rather not do that, or modify the build docs until the feature that requires them is actually merged.
< fanquake> Right. So does this mean that you can basically smash appveyors global cache and break all other PR builds just buy opening a new PR with a new dependency?
< fanquake> *by
< sipsorcery> actually boost-process is being added in 15382. so 17412 seems to be a pre-emptive add to avoid future cache invalidations.
< sipsorcery> i think i understand what you're getting at now.
< sipsorcery> as far as the appveyor cache goes it's going to get regularly invalidated due to changes to the build
< sipsorcery> so it's not something that has to be avoided. it's something to minimise.
< sipsorcery> so 17416 will allow new packages to be added without manual intervention and avoid unnecessary vcpkg operations when there are no new packages.
< fanquake> That sounds like an improvement
< sipsorcery> the addition of boost-process looks like it can wait for 15382.
< sipsorcery> and 17412 can stay closed.
< sipsorcery> all good now, thx.
< fanquake> ?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17418: Build: add REPO_SLUG to fix errors in forked builds (master...repo-slug) https://github.com/bitcoin/bitcoin/pull/17418
< bitcoin-git> [bitcoin] RandyMcMillan closed pull request #17389: build: add background.tiff and .pngs to "make clean" (master...make-clean-tiff) https://github.com/bitcoin/bitcoin/pull/17389
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17420: travis: Rework CACHE_ERR_MSG (master...1911-docTravis) https://github.com/bitcoin/bitcoin/pull/17420
< bitcoin-git> [bitcoin] sdaftuar closed pull request #17332: p2p: Proof-of-concept: Improve DoS-resistance to low-work headers chains (master...2019-10-no-checkpoints-cleanedup) https://github.com/bitcoin/bitcoin/pull/17332
< meshcollider> #startmeeting
< lightningbot> Meeting started Fri Nov 8 19:00:13 2019 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< meshcollider> #bitcoin-core-dev Wallet 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
< achow101> hi
< jonatack> hi
< kanzure> hi
< meshcollider> Topics?
< jnewbery> hi
< achow101> how goes the wallet boxes review?
< jonatack> Suggested topic: deprecating getaddressinfo label in favor of labels, and adding multiple labels associated with an address (currently only one)
< phantomcircuit> hi
< achow101> jonatack: is it useful to have multiple labels with an address?
< meshcollider> #topic deprecating getsddressinfo label (jonatack)
< instagibbs> oh yeah, clocks changed
< jonatack> achow101: it seems to have been planned to be done
< jonatack> being the reason for adding the labels field?
< jonatack> in addition to the label field
< jonatack> which causes app developer confusion
< achow101> oh, i see
< jonatack> app devs wonder which field should be consumed, label or labels[]
< sipa> oh
< meshcollider> I didn't even notice labels was added
< luke-jr> me either
< jonatack> was added by jnewbery i believe? https://github.com/bitcoin/bitcoin/pull/12892
< jonatack> er, label
< jonatack> right, label[] has no tests, so added in 17283
< jonatack> labels[]*
< achow101> ack deprecating label
< sipa> is there a use case for having multiple labels per address?
< meshcollider> jnewbery: what use case did you have in mind
< sipa> i don't object, but just because we merged an API that is extensible enough to support it doesn't mean it's needed
< sipa> as in: support can be added whenever there is a use case for it
< jnewbery> meshcollider: just refreshing my memory now!
< jnewbery> logically to me, it makes sense to be able to associate multiple labels to an address
< jnewbery> From 12892: "labels are
< jnewbery> associated with addresses, instead of addresses associated with labels. (unlike
< jnewbery> with accounts.)"
< jnewbery> I picked up that work from an older wumpus PR, and I can't remember all the details right now
< luke-jr> I mean, it makes sense if people want to do short labels like GitHub does for PRs
< jnewbery> I'll review jonatack's suggested changes in #17283
< gribble> https://github.com/bitcoin/bitcoin/issues/17283 | rpc: improve getaddressinfo test coverage, help, code docs by jonatack . Pull Request #17283 . bitcoin/bitcoin . GitHub
< meshcollider> Yeah that's true actually
< luke-jr> when I do my taxes, I take the label and match multiple regexs to extract metadata - having separate labels could simplify it
< meshcollider> if it's not an enormous change to support multiple labels then concept ack
< luke-jr> that being said, there is always a primary label, so maybe we should keep / should have kept it
< jnewbery> There's no concept of a primary label
< luke-jr> eg, "bought my pet hamster" isn't likely to have more than one tx
< luke-jr> jnewbery: maybe there should be
< meshcollider> Depends if label is for categorising or label is for describing I guess
< luke-jr> I've always used it for the latter, with the former thrown in
< luke-jr> categories without a description has limited usability
< luke-jr> I'd suggest instead a "notes" with the description part, but .. we've had label for years
< jnewbery> jonatack: I'll take a look at the PR and give concept feedback
< jonatack> luke-jr: say, ability to designate one of the labels as a primary, and one only?
< achow101> I think having multiple labls would be somewhat invasive due to all of the legacy accounts stuff associated with labels
< jonatack> jnewbery: ty
< meshcollider> I mean, I don't think it matters if the distinction is in the code. Supporting multiple labels allows the user to do whatever they like with them, I don't think it needs a "primary" one
< meshcollider> Ok yeah this can be discussed in the PR
< meshcollider> Other topics?
< jonatack> a) it seems we should decide re multiple labels before deprecating
< luke-jr> jonatack: maybe
< luke-jr> achow101: maybe rename "labels" to "tags"?
< jonatack> b) back to a) :D
< meshcollider> Please not another rename lol
< luke-jr> what's the "labels" PR?
< sipa> #12892
< gribble> https://github.com/bitcoin/bitcoin/issues/12892 | [wallet] [rpc] introduce label API for wallet by jnewbery . Pull Request #12892 . bitcoin/bitcoin . GitHub
< luke-jr> PR description doesn't suggest it does that.. :/
< achow101> luke-jr: i don't think there's a PR yet
< luke-jr> ok, so it adds a "labels" array with only one possible value
< jnewbery> next topic?
< meshcollider> achow101: is there anything you want to discuss about boxes or just review beg?
< achow101> review beg
< jonatack> (yes it is indeed https://github.com/bitcoin/bitcoin/pull/12892 despite the PR name)
< jonatack> luke-jr: right
< meshcollider> #16944 is finally nearly ready too which is nice, hopefully we can get it in after provoostenator rebases
< gribble> https://github.com/bitcoin/bitcoin/issues/16944 | gui: create PSBT with watch-only wallet by Sjors . Pull Request #16944 . bitcoin/bitcoin . GitHub
< meshcollider> Alright no other topics then :)
< meshcollider> #endmeeting
< lightningbot> Meeting ended Fri Nov 8 19:24:49 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jnewbery> thanks for merging 15931 meshcollider!
< jnewbery> next one in that sequence is #16426, which ariard can rebase now
< 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
< jnewbery> it's a really fun change to reverse the cs_main-cs_wallet lock order
< jonatack> achow101: review beg for https://github.com/bitcoin/bitcoin/pull/17261 ?
< meshcollider> jonatack: review beg for all his open wallet PRs :p
< achow101> #17373
< gribble> https://github.com/bitcoin/bitcoin/issues/17373 | wallet: Various fixes and cleanup to keypool handling in LegacyScriptPubKeyMan and CWallet by achow101 . Pull Request #17373 . bitcoin/bitcoin . GitHub
< meshcollider> jnewbery: sounds good, review beg for that too then
< jonatack> thanks
< achow101> it'd be nice to merge these so I don't have to rebase the same PRs every day
< ryanofsky> i have never understood what "labels are associated with addresses, instead of addresses associated with labels" means
< ryanofsky> "bob is associated with mary, but mary is not associated with bob." huh?
< meshcollider> It means it's not bijective, there is no well defined label -> address map
< meshcollider> Because multiple addresses can have the same label
< sipa> meshcollider: that was the case with accounts too
< meshcollider> Yeah
< jnewbery> one address couldn't have multiple accounts. It was always intended that one address could have multiple labels
< sipa> i always assumed it meant "you should think as labels being the property of an address" rather than "a label is a collection of addresses"
< jnewbery> sipa: +1
< ryanofsky> so "X is associated with Y" means "a Y can only have one X"
< meshcollider> Who knows, associated probably isn't the best word
< jnewbery> ryanofsky: if the 'associated with' doesn't make sense for you, just use sipa's definition
< ryanofsky> of course, yeah, i was just wondering how that associated thing that i see repeated made sense to anyone
< jnewbery> I copied it in my PR descript from wumpus's original PR because it made sense to me, but I don't think it's used in any user-facing documentation
< jonatack> I saw it as analogous to relational databases: has one relation vs belongs to relation
< jamesob> sounds like an indexing thing: you can look up the labels associated with an address easily, but you cannot look up the addresses associated with a label easily (even though in reality it's probably quick to build that index ad hoc depending on the size of the wallet)
< luke-jr> jamesob: that's the technical side
< luke-jr> on the abstract side, a label isn't a container; it doesn't "have" transactions/addresses
< luke-jr> it's a property of those transactions
< luke-jr> so you can conceptually search for all transactiosn with a label, but not view the contents of a label
< jamesob> curious, what're the contents of a label if not the associated txns?
< jnewbery> luke-jr: yep, labels don't have a balance
< luke-jr> there are no contents, that's the point
< jamesob> gotcha
< luke-jr> it's like putting a sticker on something
< luke-jr> sure, you can find all objects with the sticker, but asking for the contents of such a sticker is silly
< meshcollider> So a sticker is associated with the thing it's stuck on, but the thing it's stuck on isn't associated with the sticker
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to 0.19: https://github.com/bitcoin/bitcoin/compare/7358ae6d71cd...84908668a0a8
< bitcoin-git> bitcoin/0.19 2a15679 fanquake: doc: reintegrate release notes from wiki
< bitcoin-git> bitcoin/0.19 8bca3ce fanquake: doc: add macOS DMG opening note to release notes
< bitcoin-git> bitcoin/0.19 8490866 Wladimir J. van der Laan: Merge #17403: doc: reintegrate 0.19.0 release notes
< bitcoin-git> [bitcoin] laanwj merged pull request #17403: doc: reintegrate 0.19.0 release notes (0.19...reintegrate_relnotes_019) https://github.com/bitcoin/bitcoin/pull/17403
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.19: https://github.com/bitcoin/bitcoin/compare/84908668a0a8...42414bfd0547
< bitcoin-git> bitcoin/0.19 42414bf Wladimir J. van der Laan: build: set CLIENT_VERSION_RC to 0 pre-final
< bitcoin-git> [bitcoin] laanwj pushed tag v0.19.0: https://github.com/bitcoin/bitcoin/compare/v0.19.0
< fanquake> ?
< jonatack> \o/
< MarcoFalke> \o/
< wumpus> yes, that's one of the next steps, I usually do that before the uploading the binaries (e.g. after the gitian process), but it doesn't really matter if it's a little sooner I guess
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8021392b825c...9e0aabe50cbb
< bitcoin-git> bitcoin/master fa56bcb MarcoFalke: ci: Run CI_WAIT only on travis
< bitcoin-git> bitcoin/master fa8a60b MarcoFalke: ci: Run non-cross-compile builds natively
< bitcoin-git> bitcoin/master faf757a MarcoFalke: ci: Guess the native host when not cross compiling
< bitcoin-git> [bitcoin] laanwj merged pull request #17367: ci: Run non-cross-compile builds natively (master...1911-ciNative) https://github.com/bitcoin/bitcoin/pull/17367
< fanquake> wumpus I'll save you the trouble
< bitcoin-git> [bitcoin] fanquake opened pull request #17422: doc: add historical 0.19.0 release notes (master...add_019_relnotes) https://github.com/bitcoin/bitcoin/pull/17422
< wumpus> fanquake: thanks!
< jnewbery> wumpus fanquake MarcoFalke: I think #15934 is ready for merge. ACKs on the head commit 083c954 from ariard, jamesob and jnewbery. Also ACKs on previous versions from fjahr and jonatack.
< gribble> https://github.com/bitcoin/bitcoin/issues/15934 | Merge settings one place instead of five places by ryanofsky . Pull Request #15934 . bitcoin/bitcoin . GitHub
< jamesob> not to mention 15934 is tested to death
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e0aabe50cbb...adceca2ba56a
< bitcoin-git> bitcoin/master fec230e fanquake: doc: add historical 0.19.0 release notes
< bitcoin-git> bitcoin/master adceca2 Wladimir J. van der Laan: Merge #17422: doc: add historical 0.19.0 release notes
< bitcoin-git> [bitcoin] laanwj merged pull request #17422: doc: add historical 0.19.0 release notes (master...add_019_relnotes) https://github.com/bitcoin/bitcoin/pull/17422
< bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/adceca2ba56a...a7aec7ad9794
< bitcoin-git> bitcoin/master dc8e1e7 Russell Yanofsky: Clarify emptyIncludeConf logic
< bitcoin-git> bitcoin/master 5a84aa8 Russell Yanofsky: Rename includeconf variables for clarity
< bitcoin-git> bitcoin/master e2e37cf Russell Yanofsky: Remove includeconf nested scope
< bitcoin-git> [bitcoin] laanwj merged pull request #15934: Merge settings one place instead of five places (master...pr/mergeset) https://github.com/bitcoin/bitcoin/pull/15934
< jnewbery> thanks wumpus!
< wumpus> thanks for improving the horror that is bitcoin core option parsing a bit :)
< midnight> inb4 option parsing gets its own scripting language
< wumpus> midnight: hah, I know you're joking, but I don't think a lack of flexibility was ever the problem, just that the code is a mess and problems are silently ignored... but also we've come a long way from #1044
< gribble> https://github.com/bitcoin/bitcoin/issues/1044 | Problems with command-line options silently ignored . Issue #1044 . bitcoin/bitcoin . GitHub
< * jamesob> waits for TheBlueMatt to suggest porting options parsing to rust
< wumpus> it's, a good lesson for new projects, get these things designed well in the first release, if not you're going to spend years cleaning up the mess while competing with PRs that add functionality etc
< wumpus> jamesob: lol
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17423: ci: Make ci system read-only on the git work tree (master...1911-ciRo) https://github.com/bitcoin/bitcoin/pull/17423
< harding> FYI, BitcoinCore.org isn't updating when new commits are merged. I DM'd BlueMatt a while ago, but I guess he's not around. I'm not sure who else has access to the server to debug it (this happens from time to time, but I'm not sure what can BlueMatt usually kicks to get things restarted).
< midnight> wumpus: Only half joking. Complex options are heading that way, it seems to me. At some point *behaviour* of programs with complex options it seems to me might be helpful to be reactive or capable of simple decision-making
< * midnight> shudders at the future
< wumpus> harding: strange, I don't have access immediately either but probably we need to poke whatever does updates
< emilengler> harding: Btw why is bitcoincore.org not hosted at github
< harding> BlueMatt: is looking into it now.
< wumpus> emilengler: cuuursed idea
< emilengler> What's wrong with GH pages? It adds an extra layer of transparency
< emilengler> Well you can't really do server side stuff though
< sipa> emilengler: we really don't want to rely on github's security for distribution of binaries
< sipa> if anything, the degree to which we depend on github already is scary
< wumpus> midnight: I don't know, I dont' think *that* is so bad with bitcoin core. I do have experiences like that with things like printer settings though, where the software tries to 'intelligently' guess what your're trying to do, correcting for some settings, so at some point you need to make second-order guesses so that the software will make the correct guess and eventually send the right value to the
< wumpus> hardware
< emilengler> sipa: +1 but GH can't fake PGP signatures and if the users aren't verifying it it is pretty much their own fault IMO
< sipa> emilengler: whether you like it or not, reality is that very few users verify PGP signatures
< harding> emilengler: I don't have any data on BitcoinCore.org, but back when the binaries were exclusively hosted on Bitcoin.org, there was less than 1% as many downloads of SHA256SUMS.asc than there was of the binary files.
< wumpus> but no, we're not going to trust github for hosting the website as well as hosting the repository
< wumpus> one thing is enough
< emilengler> Btw why isn't the repo hosted on the server then
< wumpus> probably too much, anyhow, but let's not argue for making things worse
< emilengler> ok
< wumpus> in a far future I'm imagine we can reduce our dependency on github.com, but we're at least not trying to increase it
< wumpus> (and yes, the bitcoincore.org server update verifies GPG signatures on commits independently, so someone compromising the github repository doesn't automatically compromise the website)
< midnight> neat
< midnight> I verify PGP signatures (most of the time!)