--- Log opened Thu Aug 02 00:00:28 2018 00:01 < jonasschnelli> who own drahtbot? 00:01 < jonasschnelli> *owns 00:02 < kallewoof> jonasschnelli: MarcoFalke 00:02 < jonasschnelli> Nice work... I wasn't aware that it does also builds via gitian 00:03 < wumpus> yes it's a great bot 00:07 < fanquake> ^ It keeps getting better 00:08 < fanquake> I wonder if it'll be running/posting the results of some of the benchmarks from perfmonitor 00:10 < fanquake> https://github.com/chaincodelabs/bitcoin-perfmonitor 00:25 < fanquake> wumus 13835 & 13824 should be mergable 00:25 < fanquake> *wumpus 00:30 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 255 seconds] 00:36 -!- BillSmith4lyfe [BillSmith4@ip72-207-116-245.sd.sd.cox.net] has quit [Ping timeout: 256 seconds] 00:38 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Ping timeout: 256 seconds] 00:39 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev 00:45 -!- Arokh [~Arokh@extknot.com] has quit [Ping timeout: 256 seconds] 00:46 -!- Arokh [~Arokh@extknot.com] has joined #bitcoin-core-dev 00:47 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 260 seconds] 00:55 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 240 seconds] 00:58 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 01:11 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 01:19 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:27 < fanquake> wumups Also #13844 and 13796 01:27 < gribble> https://github.com/bitcoin/bitcoin/issues/13844 | doc: correct the help output for -prune by hebasto · Pull Request #13844 · bitcoin/bitcoin · GitHub 01:59 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:e133:6365:55e9:f838] has quit [Ping timeout: 265 seconds] 02:02 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:e133:6365:55e9:f838] has joined #bitcoin-core-dev 02:06 < fanquake> sjors I've added the gitian-build label, so I think that should trigger it. 02:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:18 -!- JackH [~laptop@2a01:4c8:102e:413d:756e:cc6f:2ed9:1e41] has joined #bitcoin-core-dev 02:18 < provoostenator> fanquake thanks 02:50 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 02:52 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 02:53 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 03:06 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 03:14 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev 03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 03:58 < wumpus> Aug 01, 12:07 - f030410e88f11c5ff1ce6c80b463a1c7f6d39830functional-test-runner@ccl-bench-hdd-1 Average time up 9.5% 03:59 < wumpus> looking at how to interpret bitcoinperf.com - does this mean that merging #13697 made the tests 10% slower on gcc, but not clang?!? 03:59 < gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub 04:01 < wumpus> it's not surprising that it makes running the functional tests fractially slower, as test cases were added, but 10% is a lot 04:04 -!- CodeShark_ [sid126576@gateway/web/irccloud.com/x-hzczqgrbsmqvktdo] has quit [Remote host closed the connection] 04:04 -!- Varunram [sid210151@gateway/web/irccloud.com/x-nndvdbbopqugvqsb] has quit [Remote host closed the connection] 04:04 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-ywnjlkttfmmhgiln] has quit [Remote host closed the connection] 04:04 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-eahofttudxynnean] has quit [Remote host closed the connection] 04:04 -!- NicolasDorier_ [sid129442@gateway/web/irccloud.com/x-qdejdtetwaoavkex] has quit [Remote host closed the connection] 04:04 -!- mariorz_ [sid490@gateway/web/irccloud.com/x-ucfgdnhlbezldwbl] has quit [Remote host closed the connection] 04:04 -!- wbnns [sid105317@21/bitcoin/binns] has quit [Remote host closed the connection] 04:06 -!- trotski2000 [sid206086@gateway/web/irccloud.com/x-wupaqzorlznlslui] has joined #bitcoin-core-dev 04:07 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 240 seconds] 04:10 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev 04:26 < provoostenator> xpub derivation is expensive 04:27 < provoostenator> You could mock the actual derivation with lookup tables. 04:27 < provoostenator> But that's pretty invasive for the functional test suite. 04:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:29 -!- Krellan [~Krellan@2601:640:4000:9258:3cf4:9188:ecd2:e19e] has quit [Read error: Connection reset by peer] 04:30 -!- Krellan [~Krellan@2601:640:4000:9258:91f9:754d:f70f:744a] has joined #bitcoin-core-dev 04:31 < wumpus> yes but what I mean is that the test framework consists of so many tests, this mean that one test takes up ~1/10th of it 04:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds] 04:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:39 -!- farmerwampum [~farmerwam@88.202.178.98] has quit [Ping timeout: 260 seconds] 04:46 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev 04:49 < provoostenator> That's not surprising because of how many derivations it's doing, trying to scan up to a thousand (?) keys for those xpub/* patterns. Using the range param for scantxoutset might help. 04:50 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:e133:6365:55e9:f838] has quit [Remote host closed the connection] 04:54 < wumpus> good point, yes true 04:54 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has joined #bitcoin-core-dev 04:55 < provoostenator> I left a note for sipa on the PR. The default is 1000 and sevearl tests use 1499, I suggest using 1 and 2. 05:20 < wumpus> thanks 05:29 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 05:43 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 05:46 -!- csknk [~csknk@unaffiliated/csknk] has quit [Ping timeout: 248 seconds] 05:47 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 05:48 < provoostenator> fanquake: no rush, but how often does that bot build things? There's only one ticket with a "Needs gitian build" label atm. 05:49 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 05:49 < fanquake> provoostenator: Not 100% sure if it's completely automated or not. MarcoFalke should be able to help out. 05:50 < wumpus> looks like we have a causality issue here, that message from provoostenator is visible here *just before* fanquake joining 05:51 * provoostenator hides time machine 05:51 < wumpus> leaky wormholes again 05:51 < fanquake> wumpus :o 05:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 06:00 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 06:00 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 06:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 06:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 06:08 < fanquake> wumpus I've retested 13823 now, thanks for pointing out the quoting issue. 06:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 06:28 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 06:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:33 -!- ken2812221_ [~androirc@2001-b400-e23b-bda3-d49a-d648-add7-1146.emome-ip6.hinet.net] has joined #bitcoin-core-dev 06:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 06:36 -!- Krellan [~Krellan@2601:640:4000:9258:91f9:754d:f70f:744a] has quit [Read error: Connection reset by peer] 06:37 -!- Krellan [~Krellan@2601:640:4000:9258:91f9:754d:f70f:744a] has joined #bitcoin-core-dev 06:37 < ken2812221_> wumpus: I think #13426 can be postponed to 0.18, I don't think this can be merged in a week. I'll open an issue to track this and seperate to several PR for easier review 06:38 < gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub 06:43 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 06:44 -!- ken2812221_ [~androirc@2001-b400-e23b-bda3-d49a-d648-add7-1146.emome-ip6.hinet.net] has quit [Remote host closed the connection] 06:44 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds] 06:50 < MarcoFalke> provoostenator: It builds on a single cpu on gce, heh. So maybe 24hours to build master and the commit for all targets ;) 06:50 < ken2812221> Also, we'll 6+months to test if there is any side effect after these changes. 06:51 < MarcoFalke> ken2812221: Yeah, was going to ask about the state of this. 06:51 < MarcoFalke> Imo we should at least fix the crash 06:51 < MarcoFalke> the crash on Windows for non-ascii wallet file name 06:54 < wumpus> fanquake: cool, thanks for retesting 06:54 < wumpus> ken2812221: ok! 06:55 < fanquake> MarcoFalke which PR/changeset do you have in mind for that? 06:55 < MarcoFalke> Idk what is causing the issue on windows 06:55 < wumpus> ken2812221: changed milestone--thanks, I sort-of expected this, it was kind of a large and reasonably risky change to merge so last minute, better to do it as one of the first things for 0.18 probably 06:55 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 06:56 < fanquake> Ah right, we're talking about #13754 here? 06:56 < gribble> https://github.com/bitcoin/bitcoin/issues/13754 | Windows crashes for -wallet=你好 · Issue #13754 · bitcoin/bitcoin · GitHub 06:56 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev 06:57 < MarcoFalke> jup 06:57 < MarcoFalke> It reports a fatal error and then hits an assertion 06:58 < ken2812221> MarcoFalke: That happen on -datadir for a really long time. 06:58 < MarcoFalke> oh 06:58 < MarcoFalke> Not a regression then 06:58 < fanquake> Ok. I'm not entirely sure how we can solve that in not very intrusive, right before 0.17.0 kind of way. 06:59 < fanquake> 13426 currently has changes to bdb and leveldb as well 07:00 < provoostenator> Afaik it used to throw a clear error and now it just crashes, but it's only a problem if you use character incompatible with your system language. 07:00 < MarcoFalke> So not really a common issue to hit 07:00 < MarcoFalke> Still, would be nice to bisect that 07:00 < MarcoFalke> Will probably do that 07:01 < provoostenator> Have fun, only takes 24 hours per build, right? :-) 07:02 < MarcoFalke> heh, I hope I can steal them from jonasschnelli nightly server 07:10 < fanquake> If someone wants to do some quick review, there is currently 13852 & 13852 for 0.16, both fairly simple backports 07:13 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 07:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:17 < provoostenator> fanquake duplicate number, what's the second one? I'll take a look. 07:18 < fanquake> provoostenator Sorry, 13796 07:20 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 256 seconds] 07:20 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 07:27 < fanquake> Another trivial one in 13853, not entirely sure how the versions got out of sync. 07:27 < provoostenator> MarcoFalke: maybe it's useful to have a "needs windows build" tag? That's the only OS where you can't avoid cross-compilation pain. 07:29 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.] 07:29 < provoostenator> fanquake: you're sure you want to bump QT to 5.9.6 in backports? 07:29 < wumpus> let's not get too specific with labels 07:29 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev 07:29 < provoostenator> wumpus: it's just that the only reason I sometimes ask for Gitian builds is that I want to test Windows binaries. 07:30 < provoostenator> Maybe others have other reasons. 07:30 < fanquake> provoostenator bump qt in backports? 07:30 < provoostenator> https://github.com/bitcoin/bitcoin/pull/13853/files#diff-0c8311709d11060c5156268e58f5f209R26 07:30 < wumpus> provoostenator: I understand, it's just that I think labels are best for keeping track of rough categories, this seems oddly specific :) 07:31 < provoostenator> Oh wait, that one isn't a backport, nvm. 07:32 < provoostenator> Maybe a Github bot listening for comments "Windows plz" is better than tags? 07:41 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:43 < wumpus> I... think we should simply make sure enough CPU capacity is available for the build bot and build everything possible 07:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 07:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 07:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 07:55 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev 07:56 < wumpus> if cloud/server costs are a problem I'm sure we can find some solution 07:59 < fanquake> Can run all the tests, fuzzers, linters, benchmarks, gitian builds, test sync times.. 08:00 < wumpus> yes, including openbsd and freebsd *ducks* 08:01 < ken2812221> In my opinion, how about uploading travis build binaries to a server? 08:02 < ken2812221> It would cost less money than own build. 08:04 < wumpus> the problem, last time we looked at that option, had to do with credentials; as well as well as with potential malware, especially if PRs automatically upload binaries 08:04 < wumpus> this is manually triggered by maintainers, so less risky 08:08 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 08:14 < ken2812221> We can print the binary hash at the end and upload them to a close server. If someone want to get the binary, they can ask maintainer to get it. The downside is that we should trust travis-ci. 08:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:26 -!- instagibbs [~instagibb@pool-100-15-122-172.washdc.fios.verizon.net] has joined #bitcoin-core-dev 08:32 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:28eb:e227:7f03:867b] has joined #bitcoin-core-dev 08:34 < MarcoFalke> ken2812221: Could do that with https://transfer.sh/ 08:36 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:28eb:e227:7f03:867b] has quit [Ping timeout: 240 seconds] 08:44 -!- Krellan [~Krellan@2601:640:4000:9258:91f9:754d:f70f:744a] has quit [Read error: Connection reset by peer] 08:45 -!- Krellan [~Krellan@2601:640:4000:9258:91f9:754d:f70f:744a] has joined #bitcoin-core-dev 08:55 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has quit [Ping timeout: 252 seconds] 09:03 -!- romanz [~romanz@185.3.147.198] has joined #bitcoin-core-dev 09:03 < ken2812221> MarcoFalke: Thanks, I'll try it. 09:25 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 09:25 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 09:46 < wumpus> labeled the risc-v PRs 0.18, would be nice to have executables for that at that time 09:48 -!- ken2812221 [~User@180.217.140.78] has quit [Ping timeout: 276 seconds] 09:49 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 09:52 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving] 10:16 -!- Krellan [~Krellan@2601:640:4000:9258:91f9:754d:f70f:744a] has quit [Remote host closed the connection] 10:21 -!- masonicboom [~masonicbo@ip68-108-243-131.sb.sd.cox.net] has joined #bitcoin-core-dev 10:21 -!- JackH [~laptop@2a01:4c8:102e:413d:756e:cc6f:2ed9:1e41] has quit [Ping timeout: 240 seconds] 10:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:25 -!- masonicboom [~masonicbo@ip68-108-243-131.sb.sd.cox.net] has quit [Ping timeout: 240 seconds] 10:30 < sipa> wumpus: sgtm 10:33 -!- Aaronvan_ is now known as AaronvanW 10:46 -!- romanz [~romanz@185.3.147.198] has quit [Quit: Leaving] 10:48 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 10:49 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 10:49 -!- ken2812221 [~User@180.217.182.131] has joined #bitcoin-core-dev 10:51 -!- romanz [~romanz@185.3.147.198] has joined #bitcoin-core-dev 11:27 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 11:28 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 11:29 < luke-jr> would be nice to have POWER9 executables ASAP; that hardware is already usable ;) 11:56 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 11:58 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 240 seconds] 11:59 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 12:00 < wumpus> luke-jr: yes 12:00 < wumpus> luke-jr: let's add that for 0.18 too then. 12:01 < wumpus> #startmeeting 12:01 < lightningbot> Meeting started Thu Aug 2 19:01:07 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01 < jnewbery> hi! 12:01 < promag> hi 12:01 < cfields> hi 12:01 < provoostenator> hi 12:01 < jonasschnelli> hi 12:02 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 12:02 < kanzure> hi. 12:02 < achow101> hi 12:02 < meshcollider> Hi 12:02 < instagibbs> ello 12:02 -!- Jbaczuk [~Jbaczuk@ec2-18-237-204-133.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev 12:03 < gmaxwell> Hi. 12:03 < wumpus> topics? 12:04 < luke-jr> crickets 12:04 -!- JackH [~laptop@2a01:4c8:102e:413d:756e:cc6f:2ed9:1e41] has joined #bitcoin-core-dev 12:04 < wumpus> crickets are... good I guess 12:04 < wumpus> 0.17 PRs: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.17.0 12:05 < wumpus> 0.17 issues: https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.17.0 12:05 < luke-jr> I guess we could discuss the CXXFLAGS stuff 12:05 < wumpus> 0.17 release schedule: #12624 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub 12:06 < luke-jr> I don't really have a good solution for it 12:06 < wumpus> #topic CXXFLAGS stuff 12:06 < gmaxwell> Whats the issue? 12:06 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 12:06 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 12:06 < luke-jr> gmaxwell: autotools forces user CXXFLAGS after our own; so when the user builds with -mno-avx2, the build simply fails 12:07 < provoostenator> #13789 12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/13789 | crypto/sha256: Use pragmas to enforce necessary intrinsics for GCC and Clang by luke-jr · Pull Request #13789 · bitcoin/bitcoin · GitHub 12:07 < cfields> eh? 12:07 < cfields> it doesn't force it, we do that ourselves 12:07 < gmaxwell> can someone please drop the registed users +q for now? sdaftuar is muted. 12:07 < luke-jr> ie, autotools calls the compiler with our -mavx2 *followed by* -mno-avx2 12:07 < wumpus> well apparaently there's a problem where the build system passes the wrong flags, and luke-jr's PR works around it with pragmas 12:07 < gmaxwell> or at least voice sdaftuar 12:07 < wumpus> that seems wrong to me 12:07 < cfields> the intention is for any user-passed flags to be able to override the ones we add. If that's not the case, it's a bug. 12:07 < luke-jr> cfields: that's the problem in this case 12:08 < luke-jr> we can't let the user override -mavx2 here 12:08 < sdaftuar> hi 12:08 -!- mode/#bitcoin-core-dev [+o sdaftuar] by ChanServ 12:08 < cfields> luke-jr: you mean we shouldn't, or we currently don't? 12:08 < luke-jr> cfields: autotools makes it impossible to override user CXXFLAGS, but for these files we must or we fail to compile 12:08 < gmaxwell> luke-jr: why would the user ever pass -mno-avx2 in the first place? We shouldn't be using -mavx except on special files that need it to compile. 12:08 < cfields> oh, I see what you mean 12:08 < luke-jr> gmaxwell: to avoid AVX2 instructions 12:09 < cfields> luke-jr: eh? 12:09 < luke-jr> gmaxwell: it's those special files that fail to compile 12:09 < sipa> hi! 12:09 < cfields> luke-jr: fail how? do we just need to check for more intrinsics? 12:09 < provoostenator> (I guess it was crickets and the muffled voice of sdaftuar in the dinstance) 12:09 < gmaxwell> luke-jr: If the user wants to avoid executing avx2 instructions they need do nothing. They don't have to pass any special options. 12:09 < gmaxwell> cfields: he is saying that if he builds with CXXFLAGS=-mno-avx2 the compile fails. 12:10 < luke-jr> gmaxwell: AVX2 is enabled by default with some -march options 12:10 < cfields> gmaxwell: I assume the issue is some failures to compile because of a busted compiler, so there's a desire to be able to avoid them entirely. 12:10 < luke-jr> https://github.com/bitcoin/bitcoin/issues/13758 12:10 < gmaxwell> luke-jr: why would anyone -march= then -mno-avx2? that just seems busted. 12:10 < cfields> ooooooh 12:11 -!- JackH [~laptop@2a01:4c8:102e:413d:756e:cc6f:2ed9:1e41] has quit [Ping timeout: 245 seconds] 12:11 < wumpus> it looks like a really contrives scenario to me 12:11 < luke-jr> gmaxwell: I'm not sure why laurentb is doing it, but there's no reason they shouldn't be able to 12:11 < gmaxwell> in any case, why not detect the -mno-avx2 and then don't even compile the file? 12:11 < wumpus> not worth it polluting the code with all kinds of compiler specific pragmas at least 12:11 < cfields> ok, there are plenty of ways to solve that. I think we can just discuss on the github issue? 12:11 < luke-jr> gmaxwell: autotools says we're supposed to allow changing CXXFLAGS after configure 12:11 < wumpus> agree with cfields , there's no hurry with this 12:11 < luke-jr> make CXXFLAGS=… 12:11 < luke-jr> okay 12:12 < gmaxwell> in any case -march= -mno-avx2 sounds like a misguided thing that we shouldn't take a lot of complexity to support, unless someone knows otherwise. 12:12 < cfields> gmaxwell: we turn off all flags except the ones we're testing when doing the autoconf checks so that they don't cause unrelated errors. 12:12 < gmaxwell> Esp because there is -mtune 12:12 < luke-jr> cfields: no we don't 12:12 < MarcoFalke> Unassigned the issues from the 0.17 milestone for now 12:12 < cfields> luke-jr: ones that we add, we do 12:13 < luke-jr> MarcoFalke: it's a must-fix for 0.17 12:13 < wumpus> no, it's not a must-fix for 0.17 12:13 < gmaxwell> I don't see how this is a must fix. 12:13 < wumpus> agree fully with MarcoFalke 12:13 < luke-jr> broken build system.. 12:13 < wumpus> any other topics? 12:13 < gmaxwell> "User sets weird options which seem to make no sense as we know, and then something that arguably should work but fails" is not really blocker material. 12:13 < meshcollider> Lol 12:14 < provoostenator> Windows 12:14 < provoostenator> (topic) 12:14 < MarcoFalke> I left the pulls for review in the 0.17 milestone, so if reviewers like them, they can still be merged 12:14 < luke-jr> provoostenator: what about Windows? :p 12:14 < provoostenator> As in: do we want to fix the Windows unicode stuff, given that there's still two weeks? 12:14 < wumpus> right, it's annoying for the specific user, but if you have really specific needs like that you can patch around it 12:14 < MarcoFalke> Let's do the unicode stuff for 0.18 12:14 < wumpus> #topic Windows (provoostenator) 12:14 < provoostenator> I think the opinion in the ticket was no. 12:14 < MarcoFalke> It would require a leveldb bump and major changes 12:14 < gmaxwell> wumpus: we should find out what the user is doing, might just be some greater confusion... like they want to benchmark each way or something. 12:15 < MarcoFalke> Not sure if we can review and test that in such a short time frame 12:15 < provoostenator> Ok, and we're not getting tons of reports about this either? 12:15 < jonasschnelli> Is the unicode stuff just about filenames (wallet)? 12:15 < wumpus> gmaxwell: right! 12:15 < MarcoFalke> I am looking into restoring the proper warning for -wallet=non-ascii, but that should be all for 0.17 12:15 < MarcoFalke> jonasschnelli: Also datadir 12:15 < sipa> only half here, but feel free to ping me 12:15 < provoostenator> I think it's mostly filename yes, but also labels. 12:16 < jonasschnelli> Yeah. We should fix that. But this seems to be open since forever and I don't see a pressing need for 0.17 12:16 < provoostenator> But afaik I know it works if your system locale is set "correctly". 12:16 < MarcoFalke> jonasschnelli: Indeed, anything that is not a regression should go into 0.18 12:17 < cfields> provoostenator: due to the nature of the bug, I think many of the people who would be reporting it may not speak english. So the significance may be a little under-represented. 12:17 < cfields> s/bug/issue/ 12:17 < gmaxwell> I was trying to say what cfields just said. 12:17 < meshcollider> Good point 12:17 < jonasschnelli> Yes. Good point. 12:17 < luke-jr> provoostenator: wait, labels are broken? 12:17 < gmaxwell> We shouldn't take few reports to mean few issues... but it the change is invasive and not ready, and the issue isn't new... 12:17 < cfields> gmaxwell: agreed. -1 from me as well. Just wanted to throw that out there. 12:17 < provoostenator> luke-jr: not sure, try with an english system locale and then adding Chinese labels, I can't remember if that works. 12:18 < luke-jr> provoostenator: last I checked, we had functional tests for non-English labels :/ 12:18 < provoostenator> But with a Chinese system locale it does work afaik, hence it doesn't seem super urgent. 12:18 < wumpus> I think it's a serious issue 12:18 < MarcoFalke> We can backport to 0.17.1, if it qualifies as bug fix 12:18 < provoostenator> Functional tests that run on linux. 12:18 < wumpus> but it's risky to do this last minute 12:18 < wumpus> and it's not a regression 12:18 < gmaxwell> MarcoFalke: +1 12:19 < wumpus> MarcoFalke: agree 12:19 < provoostenator> Maybe just merge it into master after the 0.17 split so it gets testing quickly. Then we could always backport it if there's strong demand? 12:19 < gmaxwell> it's a bug, maybe one not worth backporting depending on how tidy the fix is. 12:19 < wumpus> it's unfortunate that this requires such invasive changes for windows 12:19 < wumpus> specific changes not required for other OSes 12:19 < ken2812221> This is really hard to fix. 12:20 < wumpus> which means most of use cannot test it usefully 12:20 < luke-jr> can it be reproduced in WINE? 12:20 < provoostenator> luke-jr: I haven't tried, I just use a virtual box with Windows 10 12:20 < MarcoFalke> I don't think we should fall back to WINE for testing that issue 12:21 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:21 < provoostenator> Someone recently offered to run and maintain Windows integration builds 12:21 < meshcollider> It doesn't sound like WINE would have the same issue tbh 12:21 < gmaxwell> Health professions recommend against trying to use wine to solve your problems. 12:21 < cfields> careful we don't spiral to homebrew... 12:21 < MarcoFalke> This really needs to be tested on native Windows (Not against testing it in wine additionally, though) 12:22 < wumpus> yes 12:22 < provoostenator> #12613 12:22 < gribble> https://github.com/bitcoin/bitcoin/issues/12613 | [CI] Adding MSVC build to CI check with Appveyor · Issue #12613 · bitcoin/bitcoin · GitHub 12:22 < ken2812221> If there is a way to run functionfal test on Window 12:22 < wumpus> MSVC is a orthogonal issue, I think, to solving this in the gitian builds 12:22 < MarcoFalke> I occasionally run them on appveyro 12:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 12:23 < luke-jr> MarcoFalke: it'd be nice to have Travis test it in the meantime 12:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 12:23 < wumpus> well not orthogonal but I wouldn't be surprised if there are differences mingw versus MSVC in unicoode handling 12:23 < MarcoFalke> Sure, if you can get this to work on travis, why not 12:24 < MarcoFalke> ken2812221: I think I also got them to run on my windows vm once 12:24 < wumpus> gmaxwell: this is one of the cases where you'd recommend stronger liquior instead. 12:24 < ken2812221> MSVC adds a unicode version of fstream, but mingw does not have that. 12:24 < meshcollider> MarcoFalke: "once" sounds promising ;) 12:25 < MarcoFalke> I could try once more and then write down the steps I did, heh 12:25 < cfields> ken2812221: huh, we could potentially add it and upstream to mingw, then. 12:26 < wumpus> why does utf-8 need a special fstream 12:26 < wumpus> I'm confused 12:27 < wumpus> why does this have to be so messed up 12:27 < ken2812221> wumpus: just filename 12:27 < ken2812221> It's fine to read the stream 12:27 < wumpus> can't we just drop windows support 12:27 * wumpus ducks 12:27 < meshcollider> Lol 12:28 < provoostenator> Maybe run it inside at little Linux VM? Can't be worse than Electron :-) 12:28 < wumpus> yesss 12:28 < wumpus> windows 10 already includes ubuntu right 12:28 < midnightmagic> it's messed up because windows can still run old windows crap and they have to support old api forever, including all the crappy api they built when the company was on the rocks before they discovered scm 12:28 < wumpus> let's dump the win32 garbage and use that... 12:28 < gmaxwell> lol. really with the proposed builder stuff, would building a whole linux system really be worse? :P 12:28 < cfields> wumpus: Doesn't a brand new win10 update add a bunch of compat stuff that would avoid these issues? I don't think it'd be crazy to consider dropping support for anything less than that reasonably soon. 12:29 < wumpus> cfields: it does! that's true 12:29 < provoostenator> Not by default, but you can install it. I once did the inception thing: Gitian builder VM inside Ubuntu inside Windows inside Virtual Box on Mac. It crashed. 12:29 < gmaxwell> cfields: I dont know the details, but my understanding is that a lot of people don't want to run windows 10 due to integrated adware or something? 12:29 < provoostenator> gmaxwell: the latest update, at least for me, even forced me to allow analytics data 12:30 < cfields> whoa 12:30 < meshcollider> Yeah it's much more invasive 12:30 < provoostenator> They're definately going for the get hacked by random people on the internet or get spied on by us sales pitch. 12:30 < cfields> gmaxwell: I suppose those people would be used to running outdated versions of things, then :\ 12:30 < provoostenator> (or both) 12:31 < wumpus> ugh 12:31 < wumpus> then again, this is not a regression 12:31 < wumpus> what works on windows, works. 12:31 < gmaxwell> thats a possibility too, and better than dropping support for windows... 12:32 < wumpus> the question is whether we should change 10000 lines just to accomodate unicode in it 12:32 < gmaxwell> It seems really surprising that we'd need to change more than some wrapper functions. 12:32 < luke-jr> ^ 12:32 < wumpus> yes it seems a design error in the first place if this cannot be wrapped somehow 12:33 < cfields> agreed. And that's a reasonable thing to fix, imo. IIRC it also means we have trouble adding filesystem sandboxing. 12:33 < wumpus> I do think ken2812221's PR is fairly ok in that regard 12:34 < wumpus> yes the reason I did the fs:: stuff is to allow for filesystem sandboxing 12:35 -!- marcinja_ is now known as marcinja 12:35 < cfields> wumpus: more is required though, right? I assume something along the lines of ken2812221's PR would help? 12:36 < wumpus> cfields: I had it down to only changes in fs.h and adding a fs.cpp, afaik 12:37 < cfields> ah, ok. nm then. 12:37 < wumpus> but maybe more is needed now that the code evolved further... 12:38 < gmaxwell> I hope we can find a set of changes that a reasonable independant of windows, so that the windows fix is just a couple files changed. 12:38 < wumpus> I think my main drawback in ken2812221 's PR is that it changes .string to stringu8 or something, which seems unnecessary, all strings should be utf-8 12:38 < wumpus> if you make sure the wrapper does that you don't need to change it everywhere in the code 12:39 < ken2812221> wunpus: That's how boost's path work. It need to pass a utf8 converter. 12:40 < wumpus> ken2812221: yes... 12:40 < wumpus> but our own wrapper could do that automatically 12:40 < ken2812221> Actually I have thought that before, but it need to patch boost. 12:40 < luke-jr> didn't we want to get rid of boost anyway? 12:40 < wumpus> or wrap boost 12:40 < luke-jr> maybe this is a good opportunity 12:40 < wumpus> we'll do so, in time 12:41 < wumpus> yes 12:41 < wumpus> any other topics? 12:41 < gmaxwell> Topic suggestion: Leveldb FD usage on x86_64 12:42 < wumpus> #topic leveldb FD usage on x86_64 (gmaxwell) 12:43 < gmaxwell> There was a recent report from a user hitting the select limit on his x86_64 linux host. Inspection with lsof shows that leveldb is using a lot of FDs on nodes where we expected it to be mostly using mmap. Apparently leveldb has a number of mmaps limit, as far as I know there isn't any reason we shouldn't increase it. 12:43 < gmaxwell> (seperately we should move to using poll ... but increasing the mmap limit should be a ~1 line change, unless someone knows a reason to not do so) 12:44 < wumpus> I think this limit was increased recently 12:44 < wumpus> specifically for 64-bit OSes, as it was deemed to be no problem 12:44 < wumpus> of course, I'm not surprised it turns out to be it is... :/ 12:45 < wumpus> the reason to increase it was something with performance 12:46 < wumpus> #12495 maybe? 12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/12495 | Increase LevelDB max_open_files by eklitzke · Pull Request #12495 · bitcoin/bitcoin · GitHub 12:46 < wumpus> "utACK ccedbaf - with the comment that I think relying on undocumented behavior of leveldb is risky. " 12:46 < wumpus> yeah, of course this is going to bite us in the ass 12:47 < wumpus> so revert? 12:47 < cfields> upstream has updated a bunch of stuff lately (namely moving to c++11 by default and dropping the need for lots of platform-dependent code). Has this been addressed as well, by any chance? 12:48 < gmaxwell> wumpus: hm so reading this it sounds to me that there is a seperate limit of 1000 mmaps. And running into that limit is what is causing more FDs to be used than we expected. 12:48 < gmaxwell> wumpus: so it might be possible to not revert that patch, but instead increase the maximum mmaps. 12:48 < cfields> (that bump is going to be painful, btw) 12:49 < wumpus> gmaxwell: I like switching to anything else than select() though! 12:49 < wumpus> we've been stuck with select with no good reason 12:49 < gmaxwell> wumpus: yes, I think we should do that too! 12:49 -!- satwo [~textual@2602:306:378a:6fb0:7957:cdda:f1dd:7304] has joined #bitcoin-core-dev 12:49 < sipa> gmaxwell: that would explain why i saw exactly 999 mmaps 12:49 < wumpus> my reason used to be, well, we're going to switch to using libevent for P2P any time now! 12:49 < gmaxwell> BlueMatt: and phantomcircuit: both previously had private patches to change to poll. 12:49 < wumpus> but that's been years 12:50 < wumpus> let's just do it 12:50 < sipa> wumpus: any time now! 12:50 < wumpus> change to poll() for unix-ish OSes 12:50 < gmaxwell> sipa: my comments above about the map limit are based on ossifrage (reporter's) work, and some of the comments in that PR above. 12:50 < cfields> wumpus: sorry :( 12:51 < gmaxwell> In any case, I think there are two issues: (1) switch to poll (duh but can we do it for 0.17) and (2) leveldb should probably be allowed more maps unless we know some reason to not do that. 12:51 < wumpus> cfields: nooOO sorry I didn't mean it as an attack on you, I could have done it, many other people could have done it, but we didn't 12:51 < gmaxwell> and maybe (3) potentially revert that PR; but given my understanding, I don't think we need to. 12:51 < gmaxwell> Leveldb being map limited is probably going to end up bad for performance even if we no longer had the FD issues. 12:51 < luke-jr> man mmap doesn't talk about a specific mmap limit 12:52 < wumpus> there is no mmap limit afaik 12:52 < gmaxwell> ^ 12:52 < gmaxwell> Thats where my concern about increasing leveldb's mmap usage comes from-- I dont understand why the limit is there. 12:52 < cfields> there's definitely something that limits it. Some unrelated sysctl ? 12:52 < cfields> I know i've seen it documented somewhere. 12:52 < gmaxwell> Unless they're trying to reduce TLB thrashing or something. 12:54 < wumpus> cfields: for 0.18 we should definitely update leveldb though 12:54 < ossifrage> I bumped my mmap file limit up to 4k, currently 1180 ldb files are mapped and it isn't using any fds for ldb files 12:54 < gmaxwell> https://github.com/bitcoin/bitcoin/pull/12495#issuecomment-367815005 < eklitzke suggests increasing leveldb's mmap limit here. ossifrage also apparently did that and reported it fixed his problems, though his specific problems are likely better fixed by switching to poll. 12:55 < wumpus> for 0.17 I'd propose to keep it like this, not do anything wild... 12:55 <@sdaftuar> cfields: if i read correctly, the internet says sysctl vm.max_map_count 12:55 < gmaxwell> I thought it was probably too late to switch 0.17 to poll, but increasing the leveldb map count seems like an easy mitigation that probably improves performance. 12:56 < gmaxwell> [gmaxwell@bean ~]$ sysctl vm.max_map_count 12:56 < gmaxwell> vm.max_map_count = 65530 12:56 < cfields> is there a per-process one? 12:56 < ossifrage> vm.max_map_count = 65530 (same on my box, but that number seems a bit low to be a global count) 12:56 < cfields> gmaxwell: I'd be really nervous about that. There are so many specific quirks related to select/poll/epoll/kqueue 12:57 < ossifrage> It is per process 12:57 < cfields> (not against the change at all, only hesitant for the 0.17 cycle) 12:57 < wumpus> vm.max_map_count = 65530 12:57 < luke-jr> vm.max_map_count = 65530 12:57 < wumpus> checked on 3 linux boxes, same output 12:57 < gmaxwell> likewise. 12:57 < wumpus> I... strongly doubt this is an issue 12:58 < gmaxwell> So it might be prudent for 0.17 to bump the leveldb max to 4k or something. 12:58 < wumpus> if you manage to map 65000+ files, well, I"m not surprised you run into trouble 12:58 < gmaxwell> I still just wish I better understood why they had that 1000 default. 12:59 < luke-jr> what happens if the limit is hit? 12:59 < phantomcircuit> gmaxwell, mine only worked on linux and was actually just broken on windows 13:00 < wumpus> *dong* 13:00 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu Aug 2 20:00:19 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-02-19.01.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-02-19.01.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-02-19.01.log.html 13:00 < ossifrage> luke-jr, it falls back to using fds, does it age old read-only ldb files out or does it just grow until it hits the limit? 13:01 < midnightmagic> gah, that was a meeting? 13:01 < sipa> haha 13:02 < sipa> the best kind of meetings don't feel like meetings at all 13:02 <@sdaftuar> gmaxwell: i just saw this https://github.com/google/leveldb/issues/128 13:02 < midnightmagic> gah I'm so stupid. 13:02 <@sdaftuar> the comment there makes it sound like the 1000 mmap limit is some kind of memory limiter, but i don't know if i'm understanding correctly 13:03 < gmaxwell> yep, seems like it. 13:03 < luke-jr> ossifrage: I don't see that in the code. It looks like it just fails completely 13:04 < luke-jr> s = IOError(fname, errno); 13:04 < ossifrage> luke-jr, I was running into the 1000 map limit and then it started using a ton of FDs 13:04 < luke-jr> ossifrage: I mean hitting the OS limit 13:04 < luke-jr> ie, set your OS limit to 900 13:05 < gmaxwell> I wonder if in the issue sdaftuar links the person is hitting the OS limit. 13:05 < ossifrage> (ah, I thought you where talking about the limiter limit, duh) 13:05 < gmaxwell> So leveldb added a maximum and set it to some random value. 13:05 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 13:06 < gmaxwell> sdaftuar: thanks for finding that, though I wish it were enlightening. The user reports having enough memory. Google replies 'we fixed your running out of memory with an arbritary limit'... 13:08 < luke-jr> seems like they should have at least made it so mmap failure falls back to using fds :/ 13:08 < phantomcircuit> gmaxwell, that does seem to be explicitly saying it's to limit the mmap memory usage to 2000MB 13:08 < luke-jr> so was this a 32-bit problem only? I thought mmaps were only used on 64-bit? 13:08 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [] 13:09 < gmaxwell> So I think maybe the limit was put in for 32 bit hosts... and then it was replied to someone who was really reporting another problem. 13:09 < gmaxwell> luke-jr: we don't use mmaps on 32-bit hosts, but leveldb can... 13:10 < gmaxwell> (not our leveldb) 13:10 < wumpus> on 64 bit the limit is much higher 13:10 < gmaxwell> gah, that was unclear lemme try. We don't use mmap on 32bit with leveldb, but that is a result of our configuration, since we already manage to use all the address space ourselves. 13:11 < gmaxwell> wumpus: the leveldb mmap limit is also 1000 on 64-bit hosts. 13:11 < cfields> mmap_limit = sizeof(void*) >= 8 ? 1000 : 0 13:11 < luke-jr> so sounds like we should just set the mmap limit to infinite on 64-bit, and modify the mmap fail code to fallback? 13:12 < cfields> so it'd disable mmap for x32 (not x86) as well, right? 13:12 < cfields> (er, x86 too. but also x32 :) 13:12 < gmaxwell> luke-jr: well not infinte, but something reasonably under 65530. 13:13 < luke-jr> I guess we don't want to exhaust it for other apps 13:14 < luke-jr> 60k / number of bitcoinds launched by functional tests? :P 13:14 < gmaxwell> setting it to just 4096 would put it well above our current usage. ... and by the time we hit that, we'll hopefully be using poll and it'll just be a performance consideration. 13:14 < gmaxwell> ossifrage reports he's saying about 1180 maps. 13:15 < ossifrage> gmaxwell, after 1.5 days of uptime 13:15 < ossifrage> I started to see the socket problem after 20-30 days of uptime 13:16 < gmaxwell> well how many ldb files are there in total? 13:16 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds] 13:17 < ossifrage> from my last lsof, 992 from chainstate, 146 from txindex (currently). I have 1763 txindex ldb files and 1354 chainstate ldb files 13:18 < gmaxwell> k, so 4096 would allow you to have all your ldb files mapped. 13:18 < wumpus> leveldb's mmap limit doesn't correspond to any os-level mmap limit 13:19 < ossifrage> Yeah, is that limit per database or process wide? 13:19 < ossifrage> (the leveldb limiter limit) 13:20 < wumpus> per database 13:20 < gmaxwell> wumpus: yea, I think the history is that leveldb gained it due to 32bit. 2mb * 1000 = 2GB sounds a lot like someone trying to avoid VM exhaustion on 32bit. 13:21 < gmaxwell> and they were only thinking about one database and ... yadda yadda. 13:24 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 13:25 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 13:27 -!- felco [~felco@unaffiliated/felco] has joined #bitcoin-core-dev 13:31 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 13:39 -!- masonicboom [~masonicbo@ip68-108-243-131.sb.sd.cox.net] has joined #bitcoin-core-dev 13:44 -!- masonicboom [~masonicbo@ip68-108-243-131.sb.sd.cox.net] has quit [Ping timeout: 244 seconds] 13:50 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 13:53 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 13:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 14:00 < phantomcircuit> gmaxwell, that's so... wtf 14:08 -!- jeremyrubin [~jr@2601:645:4201:6086:99ca:8e63:c454:a2cd] has joined #bitcoin-core-dev 14:14 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 14:27 -!- jimpo_ [~jimpo@ec2-54-219-151-162.us-west-1.compute.amazonaws.com] has quit [Quit: ZNC 1.7.0 - https://znc.in] 14:29 -!- jimpo [~jimpo@ec2-54-219-151-162.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev 14:39 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Remote host closed the connection] 14:47 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 15:04 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 15:24 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:1408:3ff9:4ce8:b4c9] has joined #bitcoin-core-dev 15:28 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:1408:3ff9:4ce8:b4c9] has quit [Ping timeout: 260 seconds] 15:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:15 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 16:15 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 16:16 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 240 seconds] 16:17 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 16:20 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:e4fe:e614:7765:7912] has joined #bitcoin-core-dev 16:20 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev 16:22 -!- masonicb_ [~masonicbo@2600:8802:5501:17c0:1042:fcbf:7e8e:b686] has joined #bitcoin-core-dev 16:25 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:e4fe:e614:7765:7912] has quit [Ping timeout: 265 seconds] 16:26 -!- masonicb_ [~masonicbo@2600:8802:5501:17c0:1042:fcbf:7e8e:b686] has quit [Ping timeout: 240 seconds] 16:41 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 17:15 -!- rls [~rls@192.96.205.163] has joined #bitcoin-core-dev 17:26 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:f541:b93d:84d4:e5e1] has joined #bitcoin-core-dev 17:26 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 17:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 17:31 -!- drexl [~drexl@ppp-94-68-173-245.home.otenet.gr] has joined #bitcoin-core-dev 18:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:08 -!- drexl [~drexl@ppp-94-68-173-245.home.otenet.gr] has quit [Quit: drexl] 18:09 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection] 18:10 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 18:16 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 18:20 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 18:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer] 18:27 < gmaxwell> ossifrage: so, going to PR the mmap limit bump? 18:28 < ossifrage> gmaxwell, I thought it already was? 18:29 < gmaxwell> oh 18:29 < gmaxwell> ossifrage: Where? 18:31 < ossifrage> Oh, I was thinking of this: https://github.com/bitcoin/bitcoin/pull/12495 18:31 < ossifrage> but that isn't about the mmap thing 18:36 < gmaxwell> yea, it just mentions it. You should go open one. 18:36 < ossifrage> 4096 maps? 18:39 < gmaxwell> sounds like a fine number to me. 18:41 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:f541:b93d:84d4:e5e1] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 18:42 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:b4f0:b3eb:9200:9882] has joined #bitcoin-core-dev 18:55 < ossifrage> Huh, my pr failed in travis... 18:56 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 18:56 < fanquake> ossifrage The problem is we have a linter that barfs whenever someone edits a subtree 19:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 19:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:07 < fanquake> Somebody is in a hurry https://github.com/bitcoin/bitcoin/pull/13857#issuecomment-410120231 19:07 < gmaxwell> lol 19:12 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 19:16 -!- michaelsdunn1 [~michaelsd@2601:249:8280:1450:b4f0:b3eb:9200:9882] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 19:17 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 19:20 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 19:23 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 19:26 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 19:29 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 19:35 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 19:37 -!- jarthur [~jarthur@2605:6000:1019:41ab:bc5c:8fc6:daed:3480] has joined #bitcoin-core-dev 19:41 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 20:25 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 20:37 < kallewoof> I'm scratching my head over functional tests. It seems like the tests create wallet files before starting up nodes. At least, the single call to CWallet::CreateWalletFromFile() concludes that fFirstRun=false... 21:14 -!- jarthur [~jarthur@2605:6000:1019:41ab:bc5c:8fc6:daed:3480] has quit [Remote host closed the connection] 21:25 -!- zivl [~zivl@2601:19a:837f:e4e1:dd35:63db:b581:d413] has quit [Ping timeout: 240 seconds] 21:54 -!- jarthur [~jarthur@2605:6000:1019:41ab:bc5c:8fc6:daed:3480] has joined #bitcoin-core-dev 22:03 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:1ca2:1553:9972:6a4e] has joined #bitcoin-core-dev 22:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 22:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 22:07 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:1ca2:1553:9972:6a4e] has quit [Remote host closed the connection] 22:11 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 22:14 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 264 seconds] 22:18 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer] 22:22 -!- jarthur [~jarthur@2605:6000:1019:41ab:bc5c:8fc6:daed:3480] has quit [Remote host closed the connection] 22:28 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 22:33 -!- tryphe_ is now known as tryphe 22:51 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:5849:7ee3:3476:e737] has joined #bitcoin-core-dev 22:56 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:5849:7ee3:3476:e737] has quit [Ping timeout: 265 seconds] 23:08 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev 23:11 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds] 23:33 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 23:34 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Read error: Connection reset by peer] 23:46 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:71cb:e7be:132a:2659] has joined #bitcoin-core-dev 23:48 -!- rls [~rls@192.96.205.163] has quit [Ping timeout: 244 seconds] 23:50 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:71cb:e7be:132a:2659] has quit [Ping timeout: 240 seconds] --- Log closed Fri Aug 03 00:00:29 2018