<bitcoin-git>
[bitcoin] fanquake opened pull request #31026: ci: set a ctest test timeout of 1200 (20 minutes) (master...ctest_actually_set_timeout) https://github.com/bitcoin/bitcoin/pull/31026
<pinheadmz>
what do you recco? remove the type check before release?
<Sjors[m]>
I think the spirit of 27101 was to not change behavior for < 2.0 JSON. So maybe indeed skip the type check.
<Sjors[m]>
Though maybe run it in case you see 2.0 in stead of "2.0".
eval-exec has joined #bitcoin-core-dev
<andytoshi>
i would suggest treating the string "2.0" as meaning 2.0, and literally anything else (including the number 2) as 1.0
<fanquake>
I think I'm missing something. Their code was always incorrect right? jsonrpc is a 2.0 only, thing, and always needs to be a string (per the spec)
<andytoshi>
maybe you could log a warning if you see the number 2, to be nice
<Sjors[m]>
Right, at least do a warning otherwise I think confusion is guaranteed.
<fanquake>
So why would we relax our requirements to handle someone incorrectly trying to do 2.0 ?
<fanquake>
Or is that not what's happening here
ion- has quit [Ping timeout: 244 seconds]
<Sjors[m]>
fanquake: no there are 1.0 clients
<Sjors[m]>
* these
<pinheadmz>
a 1.0 client SHOULD include "version": "1.0"
<fanquake>
yes but jsonrpc doesn't exist in 1.0 right?
<pinheadmz>
fanquake correct AFAICT
<fanquake>
so how can a 1.0 client be sending json rpc with a 2.0 int
<fanquake>
*jsonrpc
<andytoshi>
fanquake: they're sending a 1.0 int
<fanquake>
right, so they are just sending something not even in the spec
<Sjors[m]>
Been open for a month, but it seems nobody pinged us.
<fanquake>
Regardless of what we decide to do here. v28.0 has already been tagged, just not annouced. So if further changes want to be made, it'll be in a 28.0.1 or similar.
<Sjors[m]>
Actually the Lnd issue might be a different one.
<pinheadmz>
i think it is, fork observer hit that as well
<andytoshi>
i think the current behavior is totally reasonable. but if we were having this conversation a month ago i'd have a mild preference for just allowing random crap like this in 1.0
<andytoshi>
(btw i checked my own jsonrpc impl, and i have been using the string "2.0" for years)
<sipa>
andytoshi: i agree
<sipa>
the fact that apparently some clients are in violation of the spec doesn't change the fact that this change made by us breaks things for them
<sipa>
but indeed, 28.0 is already out; depending on how hard it is for these few projects to adapt, i could see us doing a 28.0.1
ion- has joined #bitcoin-core-dev
<pinheadmz>
damn sorry folks
<sipa>
pinheadmz: not your fault
<pinheadmz>
i blame jsonrpc
<pinheadmz>
they changed "version" to "jsonrpc"
<pinheadmz>
instead of just bumping the version number - who does that
<Sjors[m]>
Javascript people :-)
<pinheadmz>
ha!
<pinheadmz>
jsonrpc: 1.00000000000003
<sipa>
hahahaha
<jonatack>
Sjors[m]: :D
<jonatack>
(agree with andytoshi and sipa)
<Sjors[m]>
I think rpc-bitcoin can fix things very quickly. But it's an NPM package, so who knows how much stuff out there uses an old version.
<Sjors[m]>
Oh, by "very quickly" I mean there's a PR with enough review, but their last release is from 2020.
<achow101>
we can do a 28.1 if this is a problem that majorly affects people
<achow101>
but I don't think there should be anything for us to do other than to keep an eye out for complaints
<jonatack>
the zen of release management
<Sjors[m]>
This library has been setting jsonrpc: 1.0 for more than 5 years. And it's being downloaded 1000+ times a week according NPM. My guess is this will break a lot of htings.
<achow101>
Sjors[m]: x.0.1 releases have typically done for build issues and without release candidates. Fixing this problem seems like it might be involved enough to want to do at least one rc
<Sjors[m]>
There's probably a limit to how much effort we should put into remaining backwards compatible with very old RPC clients, but these one or two things seem reasonable to fix imo.
<Sjors[m]>
True, we could also ship 28.0 and warn people to be very careful about upgrading if they're using the RPC.
ion- has joined #bitcoin-core-dev
<achow101>
the warnings string to array was done with a deprecation cycle
<Sjors[m]>
Ok, in that case I think only the 1.0 thing should be fixed.
aleggg has joined #bitcoin-core-dev
<sipa>
it also means fewer things are affected?
<sipa>
i guess we should proceed with releasing 28.0 normally, perhaps with a warning in the release notes about this issue, and then see if we get many reports
<achow101>
We can add more to the release notes about the jsonrpc 2.0 issue
<Sjors[m]>
So deprecatedrpc for the warning thing is now removed?
<achow101>
actually, the warnings string to array is currently in the deprecation cycle. it's not gone yet.
<Chris_Stewart_5>
hi
<jonatack>
In current master I still see deprecatedrpc=warnings
<stickies-v>
(the warnings string -> array change and -deprecatedrpc=warnings option is documented in the 28.0 release notes, btw)
<b10c>
-deprecatedrpc=warnings should give the old behavior
<jonatack>
so users have the option
<Sjors[m]>
I'm trying to find out if people who run into the 1.0 issue also rely on -deprecatedrpc=warnings.
<achow101>
we've followed our typical process for breaking rpc for that, so I think it's fine to leave alone
<sipa>
agree
<Sjors[m]>
Because they'll have to deal with both at some point in the near future.
<jonatack>
Yes. It may be
<jonatack>
good to give it a couple releases before removing, no hurry
<sipa>
we could highlight it more in the release notes, perhaps a section in the very beginning mentioning both the jsonrpc version and warning field thing
ion- has quit [Ping timeout: 265 seconds]
<stickies-v>
the warnings change is also documented in the rpc docs already, so that + existing docs in release notes probably feels like enough documentation to me? but of course no objection to mentioning it at the beginning of the release notes too
<achow101>
sipa: ack
<stickies-v>
the jsonrpc thing is probably a bit more obscure for users to figure out so i think highlighting that more seems sensible
<jonatack>
achow101: wiki edits to the release notes during the day today worth making then?
<achow101>
jonatack: yes
<Chris_Stewart_5>
can someone merge #30982 ? we discussed last week and i've edited teh release notes to add the instructions in the PR
<gribble>
https://github.com/bitcoin/bitcoin/issues/30982 | docs: Add instructions on how to self-sign bitcoin-core binaries for macOS by Christewart · Pull Request #30982 · bitcoin/bitcoin · GitHub
<jonatack>
also, i had these URLs pinned for the blockers:
<sipa>
Sjors[m]: so i did two things, i added both the ...-guix-command and /usr/bin/guix to the apparmor.d/guix file, and fixed a bug in my aa-enforce (which is what caused that error you're seeing up running aa-enforce)
<sipa>
and now it works
<sipa>
but i'm not sure which of the two did it
<sipa>
but just putting ...-guix-command there was not enough
<Sjors[m]>
I'm just as mystified. Plus I always forget what I did a few months after.
<Sjors[m]>
I generally google some error, find my own issue.
pablomartin has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master 27709f5 Chris Stewart: docs: Add instructions on how to self-sign bitcoin-core binaries for macOS
<bitcoin-git>
bitcoin/master 772928a Ava Chow: Merge bitcoin/bitcoin#30982: docs: Add instructions on how to self-sign bi...
<bitcoin-git>
[bitcoin] achow101 merged pull request #30982: docs: Add instructions on how to self-sign bitcoin-core binaries for macOS (master...2024-09-26-selfsign-mac-instructions) https://github.com/bitcoin/bitcoin/pull/30982
<achow101_>
Updated the release notes draft to mention the rpc compatibility issue
achow101_ is now known as achow101
trumae has joined #bitcoin-core-dev
ion- has quit [Ping timeout: 260 seconds]
___nick___ has joined #bitcoin-core-dev
ion- has joined #bitcoin-core-dev
pablomartin4btc has joined #bitcoin-core-dev
pablomartin has quit [Ping timeout: 252 seconds]
ion- has quit [Ping timeout: 264 seconds]
ion- has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
kashifs has quit [Quit: Client closed]
ion- has quit [Ping timeout: 265 seconds]
ion- has joined #bitcoin-core-dev
ion- has quit [Ping timeout: 264 seconds]
<bitcoin-git>
[bitcoin] marcofleon opened pull request #31028: fuzz: Add fuzz-only build mode option for targets (master...2024/10/fuzzonly-build-mode-option) https://github.com/bitcoin/bitcoin/pull/31028
abubakarsadiq has quit [Quit: Connection closed for inactivity]
Guyver2 has left #bitcoin-core-dev [Closing Window]
ion- has joined #bitcoin-core-dev
josie has quit [Read error: Connection reset by peer]
<laanwj>
i wonder if i forgot something in https://gist.github.com/laanwj/cddb2ec7d18e71066d21e5ee993fe971 , it worked for me (it allows guix to create a user namespace and otherwise keeps it unconfined) but i've heard from more people it didn't for them
ion- has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
<sipa>
laanwj: is it normal that upon running aa-enforce, the "flags=(unconfirmed)" disappears?
<laanwj>
sipa: flags=(unconfined), you mean? and no, it shouldn't disappear IIRC, it's important that it is unconfined... how are you checking this? also: which guix are you using, is the main binary installed in /usr/bin/guix ? the absolute path needs to be correct
<sipa>
ehh, now i get
<sipa>
substitute: /usr/lib/x86_64-linux-gnu/guix/guile: error while loading shared libraries: libguile-3.0.so.1: cannot open shared object file: Permission denied
<sipa>
guix time-machine: error: `/usr/bin/guix substitute' died unexpectedly
<sipa>
laanwj: guix is installed from ubuntu repository, Ubuntu 24.04.1 LTS, version 1.4.0-6build1
<sipa>
i did "guix pull" first
<laanwj>
ok yes that's where the guix package installs it, same one i'm using
<sipa>
there is /usr/bin/guix, but also my user has a ~/.config/guix/current/bin/guix (which is what "which guix" reports)
<sipa>
which is a symlink to /home/pw/.config/guix/current/bin/guix
<sipa>
aa-enforce [name], apparently really works on $(which [name])
<laanwj>
looking at.the naming convention of the other guix.files, maybe /etc/apparmor.d/guix needs to be called /etc/apparmor.d/usr.bin.guix. ... though i don't remember doing this
<sipa>
i don't believe this matters
<laanwj>
i don't know if it's possible to make it affect the one in your homedir too
<laanwj>
maybe just a matter. of specifying the full path though
<sipa>
so, i created an apparmor.d/guix file, with binary name /gnu/store/c9a2snygcp9iywbncwky5jcjp29x3hsw-guix-command
<sipa>
i ran /etc/init.d/apparmor reload
<sipa>
and then ran "aa-enforce /gnu/store/c9a2snygcp9iywbncwky5jcjp29x3hsw-guix-command"
<sipa>
this reports: Profile for /gnu/store/c9a2snygcp9iywbncwky5jcjp29x3hsw-guix-command not found, skipping
<sipa>
after which, the apparmor.d/guix file has changed; the binary name is now /home/pw/.config/guix/current/bin/guix (despite me running aa-enforce as root, not even in sudo), and the "flags=(unconfined)" is gone
<laanwj>
strange
<laanwj>
wait, it edits the file in /etc?!?
<laanwj>
i'm really confused now, i must say i haven't tried this in a while on ubuntu
<sipa>
yes, it edits the /etc/apparmor.d/guix file
<laanwj>
i didn't know aa-enforce changed the configuration, i thought it just enabled the profile in the kernel
<sipa>
laanwj: i'm starting to suspect that aa-enforce actually *only* changes the config file, and then tell apparmor to reload it
<sipa>
(evidence being that aa-enforce failed for Sjors[m], but guix building still succeeded)
<sipa>
ok, made an /etc/apparmor.d/guix file with "profile guix /gnu/store/c9a2snygcp9iywbncwky5jcjp29x3hsw-guix-command flags=(unconfined)", did /etc/init.d/apparmor reload, and guix-build works now...
PaperSword has quit [Quit: PaperSword]
brunoerg has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
PaperSword has quit [Client Quit]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
l0rinc has joined #bitcoin-core-dev
l0rinc has quit [Quit: Client closed]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
bugs_ has quit [Quit: Leaving]
trumae has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.4.2]
andrewtoth has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
andrewtoth has quit [Remote host closed the connection]
andrewtoth has joined #bitcoin-core-dev
ghost43_ has quit [Remote host closed the connection]