| Summary: | =dev-java/openjdk-8.262_p10: filesize/checksum mismatch | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hypoon <futurehypoon> |
| Component: | Current packages | Assignee: | Georgy Yakovlev <gyakovlev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | java |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://hg.openjdk.java.net/jdk8u/jdk8u/archive/jdk8u262-ga.tar.bz2 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Hypoon
2020-07-28 19:58:49 UTC
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? in progress. https://bugs.gentoo.org/732624 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): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b2e262024d4c564b29a7da88732e2c422234549e commit b2e262024d4c564b29a7da88732e2c422234549e Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-08-04 21:44:55 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-08-04 21:58:23 +0000 dev-java/openjdk: drop old Bug: https://bugs.gentoo.org/732624 Closes: https://bugs.gentoo.org/734320 Closes: https://bugs.gentoo.org/706012 Closes: https://bugs.gentoo.org/713180 Closes: https://bugs.gentoo.org/706638 Package-Manager: Portage-3.0.1, Repoman-2.3.23 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.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. Thanks again! 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. https://www.gentoo.org/downloads/mirrors/ |
