< wumpus>
I don't think there's a reason to bump libevent, wide compatibility is good, we don't bump minimum dependency versions just for fun
< wumpus>
fixing a bug like #15363 would be a valid reason, it's just that libevent's release schedule was a mess for a long time, there were lots of betas but never a new stable, so everyone tended up with the same old version ... don't know in how far that's still the case
< gribble>
https://github.com/bitcoin/bitcoin/issues/15363 | wip: http: Exit the event loop as soon as there are no active events by promag · Pull Request #15363 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/0.19 cd1e7bb Wladimir J. van der Laan: build: Fix boost detection on Ubuntu ARM 18.04
< wumpus>
ok, going to tag 0.19.0rc1 in a bit
< meshcollider>
\o/
< wumpus>
I've split the "needs backport" label per branch
< wumpus>
this separates it from "milestone" which is something different (e.g. something might be tagged for backport to a branch without targeting a specific release)
< fanquake>
wumpus \o/
< fanquake>
I think splitting makes sense. It was always a bit confusing when milestones could have multiple meanings
< wumpus>
fanquake: exactly; it is quite rare to backport to the previous major release, but especially so close to a major release it's more common and it can get confusing
< wumpus>
also, a bot could potentially automatically remove the "Needs backport" tag now when it detects a certain PR has been backported to that branch
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17050: tests: Add fuzzing harnesses for DecodeRawPSBT(...), ParseHDKeypath(...), ParseScript(...), various number parsing functions and various JSON/univalue parsing functions (master...fuzzers) https://github.com/bitcoin/bitcoin/pull/17050
< hebasto>
gitian-build.py fails for 0.19.0rc1; digging...
< fanquake>
hebasto what's the error?
< MarcoFalke>
hebasto: There is no tag yet
< MarcoFalke>
oh wait there is
< MarcoFalke>
[05:27] <wumpus> I've split the "needs backport" label per branch
< MarcoFalke>
thx ^
< fanquake>
MarcoFalke: In the ARM CI PR, have you been seeing the permissions errors the whole time?
< MarcoFalke>
Might be something with DOCKER_EXEC, as it is a bash function
< hebasto>
fanquake: line 245 subprocess.CalledProcessError: Command '['git', 'pull']' returned non-zero exit status 128.
< MarcoFalke>
I've seen some github git fetch timeouts yesterday
< fanquake>
hebasto: yea I'd just retry
< hebasto>
fanquake: nm; it was my own branch of gitian-builder; sorry
< dognosewhiskers>
Bitcoin.conf has "proxy = 127.0.0.1:9150" but the GUI options doesn't have the checkboxes for the proxy settings checked.
< sdaftuar>
dognosewhiskers: just a guess as i'm not very familiar with the gui, but i seem to recall there being some longstanding issues around qt preferences being stored/tracked differently from bitcoin.conf
< bitcoin-git>
[bitcoin] GChuf opened pull request #17052: scripts: update copyright_header script to include additional files (master...copyright-header-script) https://github.com/bitcoin/bitcoin/pull/17052
< dognosewhiskers>
sdaftuar: Hmm! That is very scary/confusing!
< promag>
with my suggestion you can avoid adding Intro::on_prune_stateChanged
< promag>
and the actual call to setSizeWarningLabel is simpler
< emilengler>
promag: With a connect()?
< promag>
yes
< emilengler>
I did it because my approach was common
< promag>
emilengler: it's not the best though
< emilengler>
I don't like to change the syntax of a project just becasue of a simple bugfix
< emilengler>
I totally agree, I don't like the cuurent situation either
< promag>
emilengler: actually your change is worst
< emilengler>
How?
< promag>
what Qt does is it iterates all slots and if it finds that syntax (on_<obj name>_<signal>) it automatically connects to that slots. but this is dynamically, and not compiler checked. for instance, if you rename the object then the connect won't happen unless you also rename the slot
< emilengler>
Oh
< promag>
that's why we also dropped SIGNAL() SLOT() connections
< emilengler>
Yeah it is ugly...
< emilengler>
But like I said, not only my function is doing this
< emilengler>
There are several others in the code
< promag>
new code should not use dynamic connections
< emilengler>
I thought it should follow the syntax...
< promag>
this is not syntax
< promag>
this is not code format
< promag>
There are several others in the code -> you are free to fix that
< emilengler>
But is the approach with connect often used in the code? In intro.cpp connect is only used with the FreespaceChecker