Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 vasild commented on pull request "RPC: add sendrawtransactiontopeer":
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3376091752)
This looked like an easy way for users to unintentionally dox themselves. Why would one want to send their transaction to a given peer(s) only and not to all like `sendrawtransaction` RPC?

1. To obfuscate the transaction origin? Doing this properly is more involved, see [#29415](https://github.com/bitcoin/bitcoin/pull/29415) which does exactly that. If we would add an assumption that there is a known trusted peer which is ok to know the transaction origin, then one might as well connect just
...
📝 fanquake opened a pull request: "[28.x] 28.3rc2"
(https://github.com/bitcoin/bitcoin/pull/33557)
Backports:
* #33482

Plus final changes for a `28.3rc2`.
💬 fanquake commented on pull request "contrib: fix macOS deployment with no translations":
(https://github.com/bitcoin/bitcoin/pull/33482#issuecomment-3376135903)
Backported to `28.x` in #33557.
💬 hebasto commented on pull request "build: Bump clang minimum supported version to 17":
(https://github.com/bitcoin/bitcoin/pull/33555#issuecomment-3376204721)
> (Apart from dropping the small workaround, this bump allows the `ci_native_nowallet_libbitcoinkernel` CI to run on riscv64 without running into an ICE with clang-16.)

Is there an open issue for this?
📝 maflcko opened a pull request: "ci: Use native platform for win-cross task"
(https://github.com/bitcoin/bitcoin/pull/33558)
Forcing the architecture to amd64 is no longer required. Dropping it should have some benefits:

* Faster CI speed on other arches (riscv64, arm, ...)
* Unlock the CI task to run on riscv64 at all
💬 maflcko commented on pull request "build: Bump clang minimum supported version to 17":
(https://github.com/bitcoin/bitcoin/pull/33555#issuecomment-3376293796)
> Is there an open issue for this?

I haven't checked, but clang-16 is long out of the support window, so it isn't going to be fixed. Also, I think the number of devs running the ci on risvc64 is limited.
📝 fanquake opened a pull request: "[30.x] Finalise v30.0"
(https://github.com/bitcoin/bitcoin/pull/33559)
Finalise `v30.0`.
Imports the release notes from https://github.com/bitcoin-core/bitcoin-devwiki/wiki/v30.0-Release-Notes-Draft.
⚠️ fanquake opened an issue: "build: depends sqlite compile failure for FreeBSD Clang cross"
(https://github.com/bitcoin/bitcoin/issues/33560)
Using master (919e6d01e93a57d991ed456bc67c43605583ada8) and doing something like:
```bash
make -C depends/ HOST=aarch64-unknown-freebsd CC=clang CXX=clang++ CFLAGS="--sysroot=/path/to/sysroot/ " CXXFLAGS="--sysroot=/path/to/sysroot/ -stdlib=libc++" LDFLAGS="-fuse-ld=lld" AR=llvm-ar STRIP=llvm-strip NM=llvm-nm RANLIB=llvm-ranlib NO_QT=1
```
Results in:
```bash
libtool: compile: clang -DPACKAGE_NAME=\"sqlite\" -DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.46.1\" "-DPACKAGE_STRING=\"sqlite 3.
...
📝 hebasto opened a pull request: "[28.x] ci: Fix Qt 5.15 URL"
(https://github.com/bitcoin/bitcoin/pull/33561)
🤔 hebasto reviewed a pull request: "ci: Use native platform for win-cross task"
(https://github.com/bitcoin/bitcoin/pull/33558#pullrequestreview-3309680688)
Tested fa6fd16f36e1240cda58a46e1717b02e8d3172a3:
```
$ uname -mo
riscv64 GNU/Linux
$ docker --version
podman version 4.3.1
$ env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'MAKEJOBS="-j3" FILE_ENV="./ci/test/00_setup_env_win64.sh" ./ci/test_run_all.sh'
<snip>
+ echo 'Creating mirror.gcr.io/ubuntu:24.04 container to run in'
Creating mirror.gcr.io/ubuntu:24.04 container to run in
+ docker buildx build --file /home/hebasto/dev/bitcoin/ci/test_imagefile --build-arg CI_IMAGE_NAME_TAG
...
📝 willcl-ark opened a pull request: "DRAFT: add a freebsd job using systemlibs"
(https://github.com/bitcoin/bitcoin/pull/33562)
Re #33438

Test a basic freebsd job in this repo using cirrus runners to get some info on how long a run will take on Cirrus Runners.

A run on GHA (free) runners is clocking in at around 50 - 60 minutes: https://github.com/willcl-ark/bitcoin/actions/runs/18309856374/job/52135663056

This will need permitting of the `vmactions/freebsd-vm@v1` action in this repo. This action seems well-maintained/used, including by [`rustup`](https://github.com/rust-lang/rustup/blob/061cf7830a61eaefaddddb8
...
💬 willcl-ark commented on issue "build: depends sqlite compile failure for FreeBSD Clang cross":
(https://github.com/bitcoin/bitcoin/issues/33560#issuecomment-3376529113)
Does adding

```
$(package)_cppflags_freebsd+=-DHAVE_MREMAP=0
```

to _depends/packages/sqlite.mk_ help?

I can't test myself easily, so not sure if that will simply progress onto another error...
💬 hebasto commented on issue "build: depends sqlite compile failure for FreeBSD Clang cross":
(https://github.com/bitcoin/bitcoin/issues/33560#issuecomment-3376536110)
cc @vasild
💬 maflcko commented on pull request "ci: Use native platform for win-cross task":
(https://github.com/bitcoin/bitcoin/pull/33558#issuecomment-3376554869)
> Error: invalid platform syntax for "linux" (use OS/ARCH[/VARIANT][,...])

thanks for testing. However, this looks like an unrelated issue with your podman version. I presume you can't run any native task at all. My recommendation would be to upgrade your os (or podman) to the latest stable version.
💬 andrewtoth commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2410469877)
It went well thanks https://github.com/bitcoin/bitcoin/commit/0030dc5ba46da402d36edd5cb32492397deeae7f
Sorry for hijacking the PR :)
📝 fanquake opened a pull request: "[29.x] build: fix depends Qt download link"
(https://github.com/bitcoin/bitcoin/pull/33563)
Fix Qt download path, so we wont always hit the fallback.
💬 hebasto commented on pull request "[28.x] ci: Fix Qt 5.15 URL":
(https://github.com/bitcoin/bitcoin/pull/33561#issuecomment-3376706733)
Closing in favour of https://github.com/bitcoin/bitcoin/pull/33563.
👍 hebasto approved a pull request: "[29.x] build: fix depends Qt download link"
(https://github.com/bitcoin/bitcoin/pull/33563#pullrequestreview-3309931772)
ACK abf4a6eeaee116917dafd56eb9caee03e13048d2.
👍 hebasto approved a pull request: "ci: remove 3rd party js from windows dll gha job"
(https://github.com/bitcoin/bitcoin/pull/32513#pullrequestreview-3310010920)
ACK 156927903d64297500dd73380908c654b07bfb1a.
🚀 fanquake merged a pull request: "[29.x] build: fix depends Qt download link"
(https://github.com/bitcoin/bitcoin/pull/33563)
💬 ryanofsky commented on issue "build: `libcapnp*.so` "warning: GCS is required by -z gcs, but this shared library lacks the necessary property note."":
(https://github.com/bitcoin/bitcoin/issues/33556#issuecomment-3376812594)
It seems like ideal solution would be to get debian to build capnproto package with GCS, maybe submitting a patch or issue requesting this. There should be no downside to enabling GCS, since it modifies return instructions but is otherwise ABI compatible, and the GCS feature can be turned on and off per thread at runtime. Only difficultly may be that capnproto dependencies (openssl and zlib) will also need to be built with GCS. There's a debian page at https://wiki.debian.org/ToolChain/GCS with
...