< bitcoin-git>
[bitcoin] achow101 opened pull request #20892: tests: Run both descriptor and legacy tests within a single test invocation (master...better-descriptor-tests) https://github.com/bitcoin/bitcoin/pull/20892
< kallewoof>
jonatack: ah, thank you. was looking at the wrong repo
< kallewoof>
yes!
< jonatack>
cool
< kallewoof>
sipa: changes LGTM
< aj>
sipa: seem fine to me too
< wumpus>
i'm disappointed that my PR to pass in an existing fd to libevent http is still open https://github.com/libevent/libevent/pull/479, this is just not going to work, at this rate we'll never have UNIX sockets support for RPC
< sipa>
wumpus: that's so strange... how do other libevent users deal with local sockets
< wumpus>
sipa: they don't use libevent's http, would be my guess
< wumpus>
at least not for a *client*, the server support needs no change IIRC
< jb55>
/home/jb55/var/img/ss/Jan09-093134.png
< jb55>
sorry my kid just did that lol
< sipa>
wumpus: ah, right
< fjahr>
wumpus: has anyone ever evaluated alternatives to libevent? I have been following it because of that one crashing issue and there is really not much movement
< fjahr>
Maybe not just alternatives but also viability of swapping it
< wumpus>
fjahr: no, not really, it doesn't seem worth swapping the entire thing just for this
< fjahr>
indeed, but it's a shame :-/
< wumpus>
libevent itself works very well and robustly, it's the built-in http that is a bit too limited and an ongoing frustration to me, another thing that's not really possible is HTTP streaming (see #7759) due to the thread model
< wumpus>
there's also libevhtp which is supposed to be a better replacement for the http functionality in libevent (but using libevent's core): https://github.com/criticalstack/libevhtp never investigated it closely though if it would solve my problems
< sipa>
wumpus: we're not going to have to make our own fork, right?
< wumpus>
sipa: I think the http functionality is one c/h file, copying it into our repository would be easier
< wumpus>
that said I really don't want to maintain a http library :-)
< sipa>
do we even need much from it?
< wumpus>
pretty much all of it, we use both the client and server part after all
< sipa>
and just the client side, isn't that just printf'ing a few header lines?
< wumpus>
it's really simple *if* you can assume the server is always bitcoind
< wumpus>
there's a lot of complexity in handling http portably, but if you know exactly what your server does a lot of that falls away
< wumpus>
but 'stealing' the client parts from libevent http is an interesting idea
< sipa>
right
< wumpus>
not sure how much of the total code that is
< wumpus>
I think I considered it at the time but for some reason decided not to, don't know why anymore it's so long ago
< wumpus>
I didn't expect it to be such a long issue for them to merge my (trivial) patch
< sipa>
wumpus: it's not like we really need libevent on the client side... it's a single-threaded single-connection synchronous application
< sipa>
being able to reuse the same code as the server side is nice.of course
< wumpus>
right
< sipa>
yeah
< sipa>
maybe ping the issue?
< jb55>
perhaps it was overlooked, looks pretty trivial indeed
< sipa>
looks like CI is failing on it
< wumpus>
some unrelated timeout IIRC
< wumpus>
I can try rebasing it and re-pushing
< jamesob>
hm, do we not generate an RPC cookie file by default on macOS? (no RPC creds specified)
< sipa>
jamesob: where do you get that error?
< jamesob>
sipa: I'm trying to connect via RPC using the python-bitcoinlib stuff (which tries to autodetect a cookie, lacking RPC info in the config file), and it barfs trying to find a cookie file, and I see there isn't one generated
< sipa>
is it perhaps looking in the wrong place?
< jamesob>
I don't think so - I'm `ls`ing the datadir and seeing debug.log/bitcoin.conf I expect, but no cookie file
< sipa>
but maybe python-bitcoinlib is looking in another place?
< jamesob>
nope, it's printing the path in its stacktrace; same location I'm lsing
< sipa>
and you're sure the rpc server is running?
< sipa>
(hate to ask that...)
< sipa>
don't have -server=0 or running bitcoin-qt?
< jamesob>
running bitcoin-qt, can access RPC via the console view, but oh, can't see *8332 in lsof
< jamesob>
bitcoin-qt doesn't start the RPC server by default? I didn't see anything in the GUI configuration for it, so I assume it did it by default
< sipa>
you need -server if you're running Qt
< jamesob>
oooh :)
< sipa>
RPC server isn't enabled by default
< jamesob>
(veering off topic) what's the easiest way for non-technical end users to enable that; just editing bitcoin.conf?
< sipa>
that works
< sipa>
or run -server=1
< sipa>
it's a bit of a contradiction for non-technical users to need RPC...
< jamesob>
yeah... it's for some lightweight wallet software I'm writing that's intended to give non-tech users a gentle introduction to the commandline
< jamesob>
anyway thanks for the help - I'm a GUI newbie :)
< wumpus>
it would be nice to be able to turn on/off the RPC server in the GUI options
< jamesob>
agreed
< jamesob>
or at least give some indication of whether it's running or not, ports, whitelits, etc.
< hebasto>
re "it would be nice to be able to turn on/off the RPC server in the GUI options" -- noted
< wumpus>
that's probably overkill, most people would want to run it cookie-only on the default port on localhost
< wumpus>
a checkbox would already be great :)
< sipa>
or a status icon in the bottom
< wumpus>
and that
< bitcoin-git>
[gui] jonatack opened pull request #179: gui: add direction and type columns to peers window (master...add-peers-dir-and-type-columns) https://github.com/bitcoin-core/gui/pull/179
< bitcoin-git>
[bitcoin] glozow opened pull request #20895: p2p: mildly discourage peers that violate feefilter (master...p2p-feefilter-violations) https://github.com/bitcoin/bitcoin/pull/20895