The ebuild fetches this archive:
as this file:
but the filesize check fails. The checksums do not match the manifest either.
Additionally, I checked jdk8u262-b10.tar.bz2 from the website. That has a different checksum and also doesn't match, despite corresponding to the same changeset.
From the manifest:
DIST openjdk-8.262_p10.tar.bz2 455868 BLAKE2B 22637a8ecd2af97b8cdc335fff5d4a14c56f53a26f0fe1ccb61f7f6542961126f4a2dadfc596ae561ea27cfdbc5f23fb10350d1533f43f1740540367565cb160 SHA512 196e201cbbd53132a78f276df7407346ba611798d813272c68cd3d654f34b84874009cda1df62e51fd5e33c5bc4aa4bdda6bd0ef7cac9857c609fcdb3fa3fd53
and here's what I observe from the "-ga" file I downloaded:
It looks like the distfiles acquired from a gentoo mirror do match the manifest.
I'm guessing that the files on hg.openjdk.java.net have been updated, but I haven't any idea why.
I’m not sure if hg tarballs are stable.
Try comparing 2. Downloaded from mirrors and downloaded upstream. diff -u will work on unpacked directories.
I’ll compare a bit later out of curiosity.
there's no real file difference, looks like while generating new release something went wrong and new nag was added to old -ga changeset.
Not a big deal, because bump to 8.265 (ga) happens tomorrow.
> diff -r -u gentoo-tarball hg
> diff -r -u gentoo-tarball/.hg_archival.txt hg/.hg_archival.txt
> --- gentoo-tarball/.hg_archival.txt 2020-06-27 15:21:42.000000000 -0700
> +++ hg/.hg_archival.txt 2020-06-27 15:21:42.000000000 -0700
> @@ -3,3 +3,4 @@
> branch: default
> tag: jdk8u262-b10
> tag: jdk8u262-ga
> +tag: jdk8u265-b00
Is 8.265 being stabilized soon, or must I switch to ~amd64?
you can already add keywords just for that new version.
Yes, I knew I could keyword just the one package version, but I was a little confused by the idea of leaving a broken ebuild in portage. With 265 stabilized, I assume 262 will be dropped soon, which is why it's not worth fixing, is that correct?
Thank you for preparing and stabilizing 265!
The bug has been closed via the following commit(s):
Author: Georgy Yakovlev <firstname.lastname@example.org>
AuthorDate: 2020-08-04 21:44:55 +0000
Commit: Georgy Yakovlev <email@example.com>
CommitDate: 2020-08-04 21:58:23 +0000
dev-java/openjdk: drop old
Package-Manager: Portage-3.0.1, Repoman-2.3.23
Signed-off-by: Georgy Yakovlev <firstname.lastname@example.org>
dev-java/openjdk/Manifest | 17 --
.../openjdk/files/openjdk-11.0.7_p10-sigsegv.patch | 55 ----
.../openjdk/files/openjdk-8-detect-gcc10.patch | 49 ----
dev-java/openjdk/openjdk-11.0.7_p10.ebuild | 280 ---------------------
dev-java/openjdk/openjdk-8.252_p09.ebuild | 231 -----------------
dev-java/openjdk/openjdk-8.262_p10.ebuild | 226 -----------------
6 files changed, 858 deletions(-)
yeah, did not want to keep it, and tarballs are still accessible via mirrors, so it was not completely broken.
fetching tarballs from HG is highly not recommended.
is there a reason you used direct fetch instead of mirrors?
Oh, I didn't realize I was unusual in not using the Gentoo mirrors. I think I was frustrated by unreliability and slow download speeds from the mirrors I had originally chosen.
If using the Gentoo mirrors is so strongly encouraged, I'll turn them back on now.
depends on region. for me mirrors actually help. especially with openjdk.
app-portage/mirrorselect can be a bit useful
but I'd just manually select 1-2 mirrors from that list and test manually with wget to see if speed works for you.