http://distfiles.gentoo.org/distfiles/a3/bitcoin-core-29.0-qt6.patch is not found ( I looked manually at http://distfiles.gentoo.org/distfiles/a3 and it's not there ) because https://github.com/bitcoin/bitcoin/pull/30997/commits/f9472962d1cdf58bfc1ad64c4bb44ddf5d0b4db2.patch?full_index=1 is returning 406 error code accessing the commit at https://github.com/bitcoin/bitcoin/commit/f9472962d1cdf58bfc1ad64c4bb44ddf5d0b4db2 shows it's there still but warning/error near top of github page saying "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." and looking at pull request 30997 https://github.com/bitcoin/bitcoin/pull/30997/commits I don't see the commit f9472962d1cdf58bfc1ad64c4bb44ddf5d0b4db2 there judging by the title from https://github.com/bitcoin/bitcoin/commit/f9472962d1cdf58bfc1ad64c4bb44ddf5d0b4db2 I'm guessing the commit you need is https://github.com/bitcoin/bitcoin/pull/30997/commits/6d4214925fadc36d26aa58903db5788c742e68c6 ? ============== PASTE FROM TERMINAL >>> Fetching (3 of 3) net-p2p/bitcoin-core-29.0::gentoo * bitcoin-core-29.0.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Downloading 'http://distfiles.gentoo.org/distfiles/a3/bitcoin-core-29.0-qt6.patch' --2025-04-20 11:50:26-- http://distfiles.gentoo.org/distfiles/a3/bitcoin-core-29.0-qt6.patch Resolving distfiles.gentoo.org... 2a02:6ea0:c700::112, 2a02:6ea0:c700::21, 2a02:6ea0:c700::18, ... Connecting to distfiles.gentoo.org|2a02:6ea0:c700::112|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2025-04-20 11:50:28 ERROR 404: Not Found. >>> Downloading 'https://github.com/bitcoin/bitcoin/pull/30997/commits/f9472962d1cdf58bfc1ad64c4bb44ddf5d0b4db2.patch?full_index=1' --2025-04-20 11:50:28-- https://github.com/bitcoin/bitcoin/pull/30997/commits/f9472962d1cdf58bfc1ad64c4bb44ddf5d0b4db2.patch?full_index=1 Resolving github.com... 140.82.121.4 Connecting to github.com|140.82.121.4|:443... connected. HTTP request sent, awaiting response... 406 Not Acceptable 2025-04-20 11:50:29 ERROR 406: Not Acceptable. !!! Couldn't download 'bitcoin-core-29.0-qt6.patch'. Aborting. >>> Failed to emerge net-p2p/bitcoin-core-29.0 * * The following package has failed to build, install, or execute postinst: * * (net-p2p/bitcoin-core-29.0:0/0::gentoo, ebuild scheduled for merge) *
I have the same problem.
(The title is wrong (the bug is the 406, not that some arbitrary URL doesn't exist on mirrors -- the rotation means that in theory we could have some distfiles.gentoo.org hosts w/o the new layout too)). Anyway, I guess we really shouldn't use these PR links, as I suspected before.
Thanks for the report. I'm on it now. And sorry for the annoyance. GitHub only keeps commits around if they're reachable from some branch head. Pull requests do count as branch heads for purposes of garbage collection, but pull requests can be rebased, which can leave commits unreachable and subject to garbage collection.
(In reply to Matt Whitlock from comment #3) > GitHub only keeps commits around if they're reachable from some branch head. It actually looks like this wasn't the issue here. The issue is that I was trying to be "accountable" by fetching the patch via the pull request's URI so that it would be obvious where it was coming from (and especially not from some rando's GitHub fork of bitcoin/bitcoin), but I wasn't aware that GitHub returns error 406 "Not Acceptable" if the specified commit is no longer reachable from the PR head. GitHub is perfectly happy to serve up the abandoned commit via the repo's base URI rather than the pull request URI, but it's unclear to me whether the commit will be retained forever after it is no longer reachable from the PR head, so the defensive move is to import a copy of the patch, although then that loses the provenance that GitHub provides. (In making my own copy of the patch, I could have made a subtle change that introduces a back door. That would be a lot harder to pull off if the patch were being fetched directly from a widely visible PR on GitHub.)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fda3c63f1901a294ba8fa1ad4db0c71276c08b2d commit fda3c63f1901a294ba8fa1ad4db0c71276c08b2d Author: Matt Whitlock <gentoo@mattwhitlock.name> AuthorDate: 2025-04-20 20:50:58 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-20 21:36:08 +0000 net-p2p/bitcoin-core-29.0: import Qt 6 patch from upstream Closes: https://bugs.gentoo.org/954108 Signed-off-by: Matt Whitlock <gentoo@mattwhitlock.name> Closes: https://github.com/gentoo/gentoo/pull/41677 Signed-off-by: Sam James <sam@gentoo.org> net-p2p/bitcoin-core/Manifest | 1 - net-p2p/bitcoin-core/bitcoin-core-29.0.ebuild | 3 +- net-p2p/bitcoin-core/files/29.0-qt6.patch | 394 ++++++++++++++++++++++++++ 3 files changed, 395 insertions(+), 3 deletions(-)
(In reply to Matt Whitlock from comment #4) > (In reply to Matt Whitlock from comment #3) > > GitHub only keeps commits around if they're reachable from some branch head. > > It actually looks like this wasn't the issue here. The issue is that I was > trying to be "accountable" by fetching the patch via the pull request's URI > so that it would be obvious where it was coming from (and especially not > from some rando's GitHub fork of bitcoin/bitcoin), but I wasn't aware that > GitHub returns error 406 "Not Acceptable" if the specified commit is no > longer reachable from the PR head. GitHub is perfectly happy to serve up the > abandoned commit via the repo's base URI rather than the pull request URI, > but it's unclear to me whether the commit will be retained forever after it > is no longer reachable from the PR head, so the defensive move is to import > a copy of the patch, although then that loses the provenance that GitHub > provides. (In making my own copy of the patch, I could have made a subtle > change that introduces a back door. That would be a lot harder to pull off > if the patch were being fetched directly from a widely visible PR on GitHub.) Correct. Github provides zero stability guarantees for pull/ URLs. They also do not support ?full_index=1, which you need either way to guarantee the .patch that is downloaded won't change its file contents -- and thus checksum -- whenever the value of `git describe` changes the default for --abbrev (that is to say, git by default uses the shortest unique start of the sha1 that it can get away with, and the more objects end up in the .git directory, or for github, the more git objects end up in the entire fork network, the longer that "shortest unique" value becomes). ?full_index=1 is equivalent to passing `--full-index` as an argument to `git format-patch`, and no SRC_URI should contain a github patch url unless it also contains this. Some people say that SRC_URI should never have *any* patches in it, because "in the past they have changed, clearly you can't trust it", but, that's only because they never used ?full_index=1
(In reply to Eli Schwartz from comment #6) > ?full_index=1 Right, I do always (and did) use full_index=1, but I didn't notice (until I compared the new patch versus the old while fixing this issue) that it doesn't have any effect on patches fetched from /pull/ URLs. Now I know. > Github provides zero stability guarantees for pull/ URLs. Do they provide stability guarantees for /org/repo/commit/<hash>.patch URLs? I would still prefer not to capture and distribute an independent copy of a patch when it's otherwise available direct from the source.
(In reply to Matt Whitlock from comment #7) > (In reply to Eli Schwartz from comment #6) > > ?full_index=1 > > Right, I do always (and did) use full_index=1, but I didn't notice (until I > compared the new patch versus the old while fixing this issue) that it > doesn't have any effect on patches fetched from /pull/ URLs. Now I know. > > > Github provides zero stability guarantees for pull/ URLs. > > Do they provide stability guarantees for /org/repo/commit/<hash>.patch URLs? > I would still prefer not to capture and distribute an independent copy of a > patch when it's otherwise available direct from the source. Yes -- if you use /org/repo/commit/<hash>.patch it is officially guaranteed to always be available (yes, even if you force push and the commit ID disappears from history entirely, UNLESS you directly appeal to github support staff to have that commit wiped from github's disks, which requires explaining that the commit e.g. accidentally has private key material and it needs to be purged for security reasons). ?full_index=1 is a trick that originally came from homebrew, which has maintainers working on Github internals. It is not technically documented anywhere that I am aware, but Github engineers rely on it for their own work on contributing to Homebrew and expect it to result in stability, which is a pretty good promise (to me, at least) that it is reliable and stable. I am 100% comfortable relying on it too.
(In reply to Eli Schwartz from comment #8) > I am 100% comfortable relying on it too. Excellent! So the takeaway for me here is that I need not shy away from fetching patches from GitHub, but I do need to use the base repo URI and not one that's subordinate to a pull request. (And, of course, pass ?full_index=1.) Thank you greatly for the information. I would be willing to submit another PR to pull the patch back out of files/ if that's wanted, but I'm also fine to let this one sit since it's not broken.
