< fanquake>
jonasschnelli: What are your thoughts on moving to macOS 10.10 as a minimum required version for 0.17.0 ?
< fanquake>
qt5.9.x supports > 10.10
< jonasschnelli>
fanquake: 10.10 is pretty "newish"... not sure.
< jonasschnelli>
That is a point.
< jonasschnelli>
qt5.9 is LTR (long term release), right?
< fanquake>
Correct, which is also why I thought a macOS bump might be ok
< jonasschnelli>
We use 10.8 as min right now, right?
< fanquake>
Qt seems to be getting more aggressive with dropping macOS support as well.
< fanquake>
Yep, 10.8 is the current minimum
< fanquake>
qt 5.10, 5.11 is macOS 10.11 +
< jonasschnelli>
I think it would be worth to do sooner then later – IF – there are clear gains (features, stability, etc.)
< jonasschnelli>
If not, we should probably wait ~1yr before upgrading to Qt5.9
< fanquake>
There is some code for supporting 10.8, fonts stuff I think, that might be able to be dropped.
< fanquake>
So for 0.17 we should just bump the 5.7.x, if there is an upgrade available?
< fanquake>
I'm going to put something together about a bump, might wrap it up in an issue for discussion.
< jonasschnelli>
We could bump to 5.7.x (if one is willing to work on that PR).
< fanquake>
Layout any benefits/downsides etc.
< jonasschnelli>
Upgrading Qt via depends was always pretty painful.
< jonasschnelli>
Yes. I think minimal system requirements are important (to keep as low as possible). Only increase if necessary
< jonasschnelli>
necessary == clear gains in UX or other area
< fanquake>
We are currently using 5.7.1, and there doesn't seem to be any more point releases for the 5.7 branch. So if we stuck to 5.7 we wouldn't need any changes for 0.17
< fanquake>
It's only compatibility patches, such as for Xcode etc
< jonasschnelli>
Okay. That makes sense... should also be not to complicated.
< jonasschnelli>
Did someone mention in the Qt5.9 PR that this will increase minimal system requieremnts for OSX?
< jonasschnelli>
And I know of a lot of OSX users stuck below 10.10
< fanquake>
I don't think anyone has mentioned yet, I'll make a comment now.
< jonasschnelli>
Thanks! I think this is a show stopper for that Qt5.9 PR
< jonasschnelli>
I looked through the RN of QT5.9,... nothing that we really would need.
< jonasschnelli>
We use only the very basics of QT
< jonasschnelli>
AFAIK the biggest problem we should make progress is HiDPI on Win/Linux. I'm not sure if this is a Qt upstream issue or something we can do better
< jonasschnelli>
Last time I checked, Bitcoin-Core looks pretty bad on Linux/Win HIDPI
< jonasschnelli>
And I have not read anything about HiDPI improvements in the last RNs,... so very likely something we can do better.
< fanquake>
mmm. Single mention of High-DPI on Windows in the Qt5.11 Release notes
< fanquake>
Will have to investigate if we can do better with 5.7
< jonasschnelli>
fanquake: That would be great. Maybe – if you can – test on HiDPI on Linux (Ubuntu?) and Windows... see if there is something we do wrong in our application that prevents those platforms from correctly rendering on HiDPI
< jonasschnelli>
It works flawless on macOS
< jonasschnelli>
(that is what me make think it is an upstream issue)
< fanquake>
jonasschnelli Yea I'll have a look.
< fanquake>
Merged all the sigs as well.
< wumpus>
jonasschnelli: I think qt5 was supposed to have better support for HiDPI, but not sure whether that's only on macosx
< wumpus>
maybe there's something that has to be enabled, it's always tricky
< jonasschnelli>
wumpus: Yes. it's on my list since month (figure out the reasons why HiDPI looks bad on Win/Linux).
< jonasschnelli>
*months
< wumpus>
jonasschnelli: FWIW on linux I always have DPI issues and have to tune things (such as display DPI) manually, and some programs ignore it, it's not very well coordinated. Wouldn't surprise me if windows is similar.
< wumpus>
jonasschnelli: then again, if other qt5 applications work and bitcoin core doesn't, yes it's something we forget to do
< fanquake>
The debug console on Windows looks particularly bad
< wumpus>
screen dpi and scaling is simply handled. On Linux/X11 it's also reported to the application / widget toolkit but in a few conflicting ways, which they usually tend to ignore...
< fanquake>
Things just seem to "break" slightly on Windows.
< wumpus>
fanquake: probably just a matter of the wrong font
< wumpus>
I vaguely remember that Wayland, the new Linux graphics stack, improved/standardized handling for screens with different DPI and such, but that's not of much use yet to most users
< wumpus>
didnt' know 0bin handled images, by the way :o
< wumpus>
arowser_: looks like you have connection issues
< wumpus>
arowser_: please fix your connection, or I'll have to ban you
< fanquake>
What are any changes in master that might stop you opening a wallet with 0.16.1?
< fanquake>
Managed to generate a wallet that wont open with 0.16.1rc1, but opens with master fine. Can't seen to recreate going either way if I nuke the data dir.
< provoostenator>
fanquake not an incompatible-bdb issue?
<@wumpus>
creating a wallet with master that can't be opened in 0.16.1 is ok, we don't generally support opening wallets created with newer versions in older ones
< fanquake>
provoostenator Shouldn't be. Using 0.16.rc1 binary, and WSL depends build with master. Both report 4.8.30 in debug log.
<@wumpus>
(the other way around would be bad, or if you open it with master once and then can't use it with 0.16.1 anymore)
<@wumpus>
but wallets *created* with master, well they are at the newest version, which might not be supported with older versions
< fanquake>
wumpus can you block Michelle155 from GH
< Arvidt>
The release notes for 0.16.1rc1 linked in the announcement email is pretty empty / in draft state (e.g. "0.16.x Example item"). I think it would be interesting for someone considering running RC version to have an overview what's new. https://github.com/bitcoin/bitcoin/blob/0.16/doc/release-notes.md
< fanquake>
Arvidt Looks like a bit of an oversight, will get some release notes PR'd shortly.
<@wumpus>
I don't think any work has been done on the release notes yet, I considered not mentioning them at all, a list of commits would have been more useful
<@wumpus>
I'll add that to the branch today
< fanquake>
wumpus ^ see above re spammer
<@wumpus>
fanquake: ah overlooked that, yes
<@wumpus>
blocked from bitcoin and bitcoin-core orgs
< kallewoof>
I've addressed jimpo's concerns in #12634 and would like to re-add it to high pri list. If you don't wanna do that outside of meetings, consider this my spiritual presence at next meeting asking to have it added as I usually can't make it for 4 am. Btw why isn't #12136 on there?
< instagibbs>
the author was busy with other stuff until recently i presume
< kallewoof>
instagibbs: Since wumpus promoted it on twitter I flat out presumed it was on that list tbh.
< instagibbs>
high priority... in our hearts
< achow101>
I asked wumpus to add it to the list a week or two ago but I didn't actually check if it got added
< gmaxwell>
The specification still probably needs work, since it unfortunately hasn't had a lot of attention since it was written.
< gmaxwell>
One of the challenges for high priority is .. like does it mean the feature is high priority or the implementation of it.
< achow101>
gmaxwell: a few people have been looking at it and have sent me comments. I have made some changes to the spec since the original was added to the bips repo
< gmaxwell>
oh good.
<@wumpus>
it's high priority to me personally
<@wumpus>
the meaning of the "high priority for review" project is to get people to look at it, it does not necessarily imply the change itself has high priority, although it does mean at least the author would like to see it merged (because it blocks further work, for example)
<@wumpus>
anyhow -- added them both to the project
< ken2812221>
Is it a good idea to clear the caches for all PR?
< ken2812221>
on travis
<@wumpus>
ken2812221: you mean after the 18.04 change?
<@wumpus>
cfields ^^
< ken2812221>
Yes, it seems there are a lot of PR tests timed out.
<@wumpus>
I don't think cleaning the caches will help for timeouts
< mryandao>
what C++ version is core currently on? do we only support C++17 and beyond?
< Varunram>
the code is on C++11 afaik
< gmaxwell>
mryandao: C++17 is a couple months old and isn't completely supported by any compiler...
< ken2812221>
wunpus: Travis will fetch caches from master if there is no cache linked to the PR.
< cfields>
wumpus: I don't think clearing caches would help at all. Each PR is going to rebuild all depends the next time it's pushed-to no matter what
< cfields>
ken2812221: ah, that's a good point though
< sipa>
mryandao: we were on c++03 until 2016, when we switched to c++11
< sipa>
as gmaxwell says, c++17 is super new, and even c++14 support is pretty novel in compilers
< sipa>
i guess gcc 5 (first with full support for c++14) is 3 years old now
< mryandao>
gcc support still experimental for 17 :/
< sipa>
mryandao: yes, it'll be years before we can adopt c++17
< gmaxwell>
mryandao: even once there is support we can't use it until distributions pick it up.
< sipa>
any reason why we can't adopt c++14 in the near future? gcc5 is in ubuntu 16.04 lts and up
< mryandao>
C++14 enables the removal of boost::chrono
< goatpig>
std::chrono is in c++11, unless it's doing something different than boost's
<@wumpus>
yes, std::chrono is c++11
< sipa>
what is the blocker to doing an s/boost::/std::/ for all of chrono and thread?
<@wumpus>
just work
<@wumpus>
though I wouldn't be surprised if cfields already has all of that somewhere
< sipa>
i remember something with interruption points
<@wumpus>
cfields: so clear all PR caches but not the branches?
<@wumpus>
sipa: yes, interruption points are one thing that would have to be implemented on our side
< sipa>
i thought we had done so though, or at least partially
<@wumpus>
I think for chrono there were no issues at all, our use of time could even easily be implemented using the C API
<@wumpus>
there's DecodeDumpTime in src/wallet/rpcdump which does some boost-related time parsing, but that's not chrono
< cfields>
wumpus: i'm not sure what 'the branches' are in that context?
<@wumpus>
cfields: 0.16, master
< cfields>
wumpus: ah yes, leave those
< cfields>
as ken2812221 mentioned, it first tries to find the per-pr cache, and resorts to the generic master cache if that one can't be found...
< cfields>
I'm not 100% if it will try to re-pull from master on a non-new PR, but the cache is useless in that case anyway, so I don't think it could hurt
<@wumpus>
thought so, all PR caches are gone now
<@wumpus>
apparently still hasn't fixed their connection
< jonasschnelli>
My testnet seed – after a report from an lnd dev – does report a high amount of ABC and BCash and classic peers.
< jonasschnelli>
They all have protocol number 80002 and may disconnect on requesting a block
< jonasschnelli>
Not sure if they are on a different chain or it they are just dishonest, spy-peers.
< jonasschnelli>
It is maybe a cat and mouse game, but eventually we should add more checks to sipa seeds, Like requesting a block around the current best known tip (would require a bitcoind on the seeder)
< jonasschnelli>
*sipas seed software
<@wumpus>
jonasschnelli: yes...
< jonasschnelli>
Maybe the only solutions are enough honest peers that will reduce the amount of served dishnoest peers
< sipa>
TIL C++11 contains regex matching, and we're even using it in bench_bitcoin
< sipa>
wumpus: are we moving away from trusty in gitian as well?
< bitcoin-git>
[bitcoin] lmanners opened pull request #13350: [tests] Add logging to provide anchor points when debugging failures. (master...testlogging) https://github.com/bitcoin/bitcoin/pull/13350
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #13351: wallet: Prevent segfault when sending to unspendable witness (master...Mf1806-walletUnspendableWitnessIsMine) https://github.com/bitcoin/bitcoin/pull/13351