!!! Digest verification failed: !!! /usr/portage/media-sound/spotify/spotify-1.0.24.104.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3188 !!! Expected: 3189 manifest.bad [fatal] 1 media-sound/spotify/Manifest This issue exist on multiple rsync mirrors for about 24h. Affected packages are all off-by-one-byte, and have in common that they were committed by ago
!!! Digest verification failed: !!! /usr/portage/dev-util/android-studio/android-studio-1.5.1.0.141.2456560.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 2092 !!! Expected: 2093 !!! Digest verification failed: !!! /usr/portage/dev-util/android-studio/android-studio-1.5.1.0.141.2456560.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 2092 !!! Expected: 2093 !!! Digest verification failed: !!! /usr/portage/media-sound/spotify/spotify-1.0.24.104.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3188 !!! Expected: 3189 !!! Digest verification failed: !!! /usr/portage/media-sound/spotify/spotify-1.0.24.104.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3188 !!! Expected: 3189 !!! Digest verification failed: !!! /usr/portage/media-video/smtube/smtube-16.1.0.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1509 !!! Expected: 1510 !!! Digest verification failed: !!! /usr/portage/media-video/smtube/smtube-16.1.0.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1509 !!! Expected: 1510 !!! Digest verification failed: !!! /usr/portage/net-p2p/gtk-gnutella/gtk-gnutella-1.1.8.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1838 !!! Expected: 1839 !!! Digest verification failed: !!! /usr/portage/net-p2p/gtk-gnutella/gtk-gnutella-1.1.8.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1838 !!! Expected: 1839 !!! Digest verification failed: !!! /usr/portage/sci-visualization/ggobi/ggobi-2.1.11.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1359 !!! Expected: 1360 !!! Digest verification failed: !!! /usr/portage/sci-visualization/ggobi/ggobi-2.1.11.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1359 !!! Expected: 1360 !!! Digest verification failed: !!! /usr/portage/sys-apps/iproute2/iproute2-4.4.0.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3770 !!! Expected: 3771 !!! Digest verification failed: !!! /usr/portage/sys-cluster/neutron/neutron-7.0.2.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 11876 !!! Expected: 11877 !!! Digest verification failed: !!! /usr/portage/sys-cluster/neutron/neutron-7.0.2.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 11876 !!! Expected: 11877 !!! Digest verification failed: !!! /usr/portage/sys-apps/iproute2/iproute2-4.4.0.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 3770 !!! Expected: 3771
Debugging this further - on two independent machines: -rw-r--r-- 1 root root 3512 Mar 15 15:20 Manifest -rw-r--r-- 1 root root 3512 Mar 15 15:20 Manifest Same size and timestamp, but: 528e701c15d91d9413b55fdb543e7c89 Manifest 2fd2461631dc31cd08903e28ca476f3d Manifest First one is correct, second one is not. Last sync on 'bad' machine was: 1458361022: >>> Starting rsync with rsync://176.28.50.119/gentoo-portage 1458361029: === Sync completed for gentoo
*** Bug 577976 has been marked as a duplicate of this bug. ***
*** Bug 578016 has been marked as a duplicate of this bug. ***
!!! Digest verification failed: !!! /usr/portage/net-fs/samba/samba-4.2.9.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 6857 !!! Expected: 6848
dwfreed: I'm not sure how ago's commits are triggering this, as they don't seem to have merges in them. commit d2abc8ac0cfb05832ae809ad25dc57628f54250a was the most recent one, and there were definitely no merges involved.
*** Bug 578686 has been marked as a duplicate of this bug. ***
!!! Fetched file: tigervnc-1.3.1.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 16728 !!! Expected: 6888105
(In reply to David Flogeras from comment #8) > !!! Fetched file: tigervnc-1.3.1.tar.gz VERIFY FAILED! > !!! Reason: Filesize does not match recorded size > !!! Got: 16728 > !!! Expected: 6888105 This is an issue with a distfile and not with an ebuild / metadata. From a quick look, it seems like the releases were moved from SourceForge to GitHub and we might have lost / dropped the distfile from our mirrors. Please file a bug to the tigervnc team about this.
!!! Digest verification failed: !!! /usr/portage/media-libs/mesa/mesa-9999.ebuild !!! Reason: Failed on SHA256 verification !!! Got: e2eb88ce00f4e8f37a940c982bfc7c38d5ed015477caa3397508792ca620968d !!! Expected: eb7a5581c6001e07d6a2a817f023cfd005ee45cda03cfca498e825bf3d3104a4
I'm having the same problem with the mesa ebuild for over 24 hours, and have tried multiple sync mirrors.
Same here
*** Bug 579204 has been marked as a duplicate of this bug. ***
Still happening for me with mesa-9999
*** Bug 579450 has been marked as a duplicate of this bug. ***
(In reply to tcoppi from comment #14) > Still happening for me with mesa-9999 for mesa the ebuild was updated but not the manifest old: eb7a5581c6001e07d6a2a817f023cfd005ee45cda03cfca498e825bf3d3104a4 new: e2eb88ce00f4e8f37a940c982bfc7c38d5ed015477caa3397508792ca620968d diff -u mesa-9999.ebuild /usr/portage/media-libs/mesa/mesa-9999.ebuild --- mesa-9999.ebuild 2016-04-10 18:34:25.392200158 +0200 +++ /usr/portage/media-libs/mesa/mesa-9999.ebuild 2016-04-04 23:17:20.000000000 +0200 @@ -1,4 +1,4 @@ -# Copyright 1999-2015 Gentoo Foundation +# Copyright 1999-2016 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ @@ -75,7 +75,7 @@ ${PYTHON_REQUIRED_USE} " -LIBDRM_DEPSTRING=">=x11-libs/libdrm-2.4.64" +LIBDRM_DEPSTRING=">=x11-libs/libdrm-2.4.67" # keep correct libdrm and dri2proto dep # keep blocks in rdepend for binpkg RDEPEND=" @@ -105,7 +105,7 @@ >=dev-libs/libelf-0.8.13-r2:=[${MULTILIB_USEDEP}] ) ) ) ) - >=sys-devel/llvm-3.4.2:=[${MULTILIB_USEDEP}] + >=sys-devel/llvm-3.6.0:=[${MULTILIB_USEDEP}] ) opencl? ( app-eselect/eselect-opencl
git repo of the portage tree says for mesa: commit 42b24554189e3d80b3c356352d5d39e0b29727df Author: Matt Turner <mattst88@gentoo.org> Date: Mon Apr 4 14:16:11 2016 -0700 media-libs/mesa: Sync dependencies to 9999. diff --git a/media-libs/mesa/mesa-9999.ebuild b/media-libs/mesa/mesa-9999.ebuild index 8785e9d..6c2c4eb 100644 --- a/media-libs/mesa/mesa-9999.ebuild +++ b/media-libs/mesa/mesa-9999.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2015 Gentoo Foundation +# Copyright 1999-2016 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ @@ -75,7 +75,7 @@ REQUIRED_USE=" ${PYTHON_REQUIRED_USE} " -LIBDRM_DEPSTRING=">=x11-libs/libdrm-2.4.64" +LIBDRM_DEPSTRING=">=x11-libs/libdrm-2.4.67" # keep correct libdrm and dri2proto dep # keep blocks in rdepend for binpkg RDEPEND=" @@ -105,7 +105,7 @@ RDEPEND=" >=dev-libs/libelf-0.8.13-r2:=[${MULTILIB_USEDEP}] ) ) ) ) - >=sys-devel/llvm-3.4.2:=[${MULTILIB_USEDEP}] + >=sys-devel/llvm-3.6.0:=[${MULTILIB_USEDEP}] ) opencl? ( app-eselect/eselect-opencl commit 2f716d266a012259360596a2c5f27e4269956408 Author: Manuel Rüger <mrueg@gentoo.org> Date: Mon Apr 4 20:42:30 2016 +0200 media-libs/mesa: Remove old Package-Manager: portage-2.2.28 diff --git a/media-libs/mesa/Manifest b/media-libs/mesa/Manifest index 6999db1..76793f8 100644 --- a/media-libs/mesa/Manifest +++ b/media-libs/mesa/Manifest @@ -1,7 +1,6 @@ DIST MesaLib-10.3.7.tar.bz2 7287153 SHA256 43c6ced15e237cbb21b3082d7c0b42777c50c1f731d0d4b5efb5231063fb6a5b SHA512 bbc027c4146c42aaa160990f5281c71a342d32c10ba56f91da1a60dd4cb7d620ff49b72553d24bc1d87470e2baf9be81b5bdee9abe49d6acc57902fccb9e2e5f WHIRLPOOL 7fa32e70c6aabb84a06f2f852f77eac839aea08726c442742b3d3abdb94a0fd9f033439ab0cb16865f4ee14e1538cb86937856bbdfd1f9090e8e7c43eac52e03 DIST MesaLib-7.10.3.tar.bz2 6056837 SHA256 1e701fc839b872677ddca9ed8784d754c9da1fbeda98173980e06aa7df0e85c0 SHA512 aa1f5f068b305fae5519e11cad2db9c6dc647d3122252bbcb210f13ac6ef1b667ae750344898bca7c5bfae94934db05eff915cb7417a59590e6d3ba230817aa8 WHIRLPOOL 5c2adda647936ed4163a4e4d5afad8344eb576712f9432f697aa0fc22ca17d7aaf0aeb6ad2d4e7e0825dc27cae570660332450778f8091e9b27aad2865c9b5fc DIST mesa-11.0.6.tar.xz 7272972 SHA256 8340e64cdc91999840404c211496f3de38e7b4cb38db34e2f72f1642c5134760 SHA512 946a66803395ef0f4d3b328e981e03a87bb5173a523be5da1dd3363002fceacd8dcbfdbf9716e31bb4247b23cc5ef112b24bb4ef0709b514bc8160c6cbf1dbf3 WHIRLPOOL 19729acb5fbbcff3a99b4d7644750dff4a7a2d41c3f25f2e004938faf0c72abd33e97f5d23d2804f84b957824757b5f64f3a7f54a2dd8999b2a71eb9b1976e0b -DIST mesa-11.0.8.tar.xz 7282812 SHA256 5696e4730518b6805d2ed5def393c4293f425a2c2c01bd5ed4bdd7ad62f7ad75 SHA512 2e883761b115dece05c527d43653e5169e70ef0d8f0f9fe35027986ca543128b17be668d495cacda4ee95564ba66734ea9954d2434aefaeb9c063f4bbedc1d63 WHIRLPOOL 3a637137076d0fc8ef3f37485683be80103ce6c5a92cef796e491d570aa47aa1ca16fca1b7b74ba697a3a816a5e606d695d0b3b524587e14533d9143830a1790 DIST mesa-11.0.9.tar.xz 7282648 SHA256 a1262ff1c66a16ccf341186cf0e57b306b8589eb2cc5ce92ffb6788ab01d2b01 SHA512 8bf9c3bfe61f5d22182b9611d66051d83dfb302cc349921bc1d895acc8681b3e22e77cb360e2f12383fd928793b306f8f98998caa457dc04e3ff4e5561ea78f7 WHIRLPOOL a3477542b5ebfed9b69bd29e7f58a01b02c70d49399afb873744de08e776d712eaca3443f88dbdee25b1d3d35a4eb9dae75a3b9d7d6d652d41cded763836c59a DIST mesa-11.1.2.tar.xz 7561920 SHA256 8f72aead896b340ba0f7a4a474bfaf71681f5d675592aec1cb7ba698e319148b SHA512 4037728cbe7c5c492cf1e6d20c61250c0ff4fe82cf89ba1cd6ff029776220160359dce197582d2c3f3f7ba5d76fe6b055515210fc46b59f821fc66f453cb77ae WHIRLPOOL e7a848f542c13eae1a79c89a6bff3fbc0c82041924f1cbecac7eaba6363edebfce568353829c41eb38c0c309e0aa35f36027b0dca262ed54d6627542d74f6bca DIST mesa-11.2.0.tar.xz 7856132 SHA256 1c1fed2674abf3f16ed2623e9a5694d6752c293194e18462ebc644a19cfaafb2 SHA512 ce56d9669cb31f465b67fa056428f59c89b60480da1e0b3e293dc740a12ed2ead0574c356017c13dfb4666616843808b9a1b7501eac14fb774981739c7d363b7 WHIRLPOOL 7c2439e836072d7a046605f068c0a50414ac742df622a8a538eb910293e029d84a161531c9b1cf5ecb230c619547cf10cda7eb12e0744903b22c8e813f8b53eb diff --git a/media-libs/mesa/mesa-11.0.8.ebuild b/media-libs/mesa/mesa-11.0.8.ebuild deleted file mode 100644 index f07599c..0000000 --- a/media-libs/mesa/mesa-11.0.8.ebuild +++ /dev/null @@ -1,462 +0,0 @@ ...
same here: mesa-9999 digest verification fails, has been that way since I submitted a duplicate bug (579204) a week ago.
I used 'ebuild /usr/portage/media-libs/mesa/mesa-9999.ebuild manifest' as a temporary workaround after sync.
Also seeing this (for over a week now, various rsync mirrors but definitely the UK ones) and have had a few email reports from others who are trying to install GNOME (eg Dantrell's new 3.20 for OpenRC) and failing on the @world update after setting the GNOME profile, due to the mesa.9999 digest verification failing: >>> Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/media-libs/mesa/mesa-9999.ebuild !!! Reason: Failed on SHA256 verification !!! Got: e2eb88ce00f4e8f37a940c982bfc7c38d5ed015477caa3397508792ca620968d !!! Expected: eb7a5581c6001e07d6a2a817f023cfd005ee45cda03cfca498e825bf3d3104a4 It's an easy enough problem to work around of course, but a bit disconcerting for new users...
Found another one, which has been in the tree for several days: !!! Digest verification failed: !!! /usr/portage/kde-apps/gpgmepp/gpgmepp-15.08.3.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 320 !!! Expected: 322 It appears that the hash for gpgmepp-15.12.3.ebuild was copied over that for gpgmepp-15.08.3.ebuild: gpgmepp # ls -l total 28 -rw-r--r-- 1 portage portage 2040 Mar 27 16:21 ChangeLog drwxr-xr-x 2 portage portage 4096 Mar 10 03:10 files -rw-r--r-- 1 portage portage 320 Mar 27 16:10 gpgmepp-15.08.3.ebuild -rw-r--r-- 1 portage portage 322 Mar 26 11:46 gpgmepp-15.12.3.ebuild -rw-r--r-- 1 portage portage 1353 Mar 7 02:06 gpgmepp-4.14.10.ebuild -rw-r--r-- 1 portage portage 3420 Mar 27 16:21 Manifest -rw-r--r-- 1 portage portage 249 Jan 24 17:06 metadata.xml gpgmepp # grep gpgmepp-15.08.3.ebuild Manifest EBUILD gpgmepp-15.08.3.ebuild 322 SHA256 2468a30662b95f4f863075b3376a1a3edcd1481730536d0ad2a84fe7d38f0772 SHA512 24cf23d45f5952eb35764c084846b20ef4110325908bba29dea57530c36c0ecf0348d7830577befadf665508bd6a70c2e1392ebe10f1eaa7eab937cbe5c120e8 WHIRLPOOL 99fc5f1177c9571856e8fa44ba703584d252eee34d0f279f7379c86d700470ab1260367e13f7be042ee42a82d9ab70e720bcf6fa16164eaa9b8b804d4270aa01 gpgmepp # grep gpgmepp-15.12.3.ebuild Manifest EBUILD gpgmepp-15.12.3.ebuild 322 SHA256 2468a30662b95f4f863075b3376a1a3edcd1481730536d0ad2a84fe7d38f0772 SHA512 24cf23d45f5952eb35764c084846b20ef4110325908bba29dea57530c36c0ecf0348d7830577befadf665508bd6a70c2e1392ebe10f1eaa7eab937cbe5c120e8 WHIRLPOOL 99fc5f1177c9571856e8fa44ba703584d252eee34d0f279f7379c86d700470ab1260367e13f7be042ee42a82d9ab70e720bcf6fa16164eaa9b8b804d4270aa01 gpgmepp # diff gpgmepp-15.08.3.ebuild gpgmepp-15.12.3.ebuild 12c12 < KEYWORDS="amd64 ~arm ~x86" --- > KEYWORDS=" ~amd64 ~arm ~x86" And while it may have an "easy" workaround, it's crying wolf: the whole purpose of Manifest is to make it harder for a rogue rsync mirror to upload compromised code. So if we train the newbies to ignore it and regenerate the manifest, what's the point?
Can anyone of devs post md5/sha1 for kde-apps/gpgmepp/gpgmepp-15.08.3.ebuild here, so I'll be sure it's not modified before running `ebuild … manifest`? BTW, manifest is broken for a couple of days now, is there any reasons why it wasn't updated after receiving report here?
(In reply to Alex Efros from comment #22) > Can anyone of devs post md5/sha1 for kde-apps/gpgmepp/gpgmepp-15.08.3.ebuild > here, so I'll be sure it's not modified before running `ebuild … manifest`? > BTW, manifest is broken for a couple of days now, is there any reasons why > it wasn't updated after receiving report here? You don't need to ask, you can look at Git as the canonical source: https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/gpgmepp/gpgmepp-15.08.3.ebuild SHA1 886f6c839f6d2648a118c38df6c139c4308f5e9c The _Gentoo_ server-side Manifest is correct, but it doesn't propagate through the mirrors since the only change is a single byte, but the mtime didn't change, so mirrors don't pick up the new copy; a more in-depth fix is in the pipeline still.
*** Bug 580368 has been marked as a duplicate of this bug. ***
*** Bug 580240 has been marked as a duplicate of this bug. ***
*** Bug 580502 has been marked as a duplicate of this bug. ***
Still present with random packages and very annoying (since it makes builds fail when dependencies go awol).
*** Bug 590038 has been marked as a duplicate of this bug. ***
Does infra need assistance on fixing this? What can be done to push this forward? This is somehow still a problem after several months; a user in #gentoo just reported: >>> Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/media-plugins/gst-plugins-soup/gst-plugins-soup-0.10.31-r2.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 554 !!! Expected: 555 !!! Digest verification failed: !!! /usr/portage/media-plugins/gst-plugins-pulse/gst-plugins-pulse-0.10.31-r2.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 460 !!! Expected: 461
(In reply to Greg Kubaryk from comment #29) > Does infra need assistance on fixing this? What can be done to push this > forward? This is somehow still a problem after several months; a user in > #gentoo just reported: The newer instances of this ongoing bug are generally triggered when two developers push and one has bad time on their system. Infra did push a change out to reduce that delta: https://archives.gentoo.org/gentoo-dev/message/63e20a5ce7e6812c7e232f76f3c841a3 But I don't think your occurrence of the problem the same cause identical, because neither of the packages you reference media-plugins/gst-plugins-soup, media-plugins/gst-plugins-pulse have been touched in 3 weeks, and all the previous instances showed up really quickly after a change. Is it possible you also hit a bad mirror? In the case of gst-plugins-pulse-0.10.31-r2.ebuild, it's been 460 bytes since July 9th, and 461 bytes for a month before that.
That above will hopefully reduce future occurences, but could you all please consider regenerating Manifest files for the broken packages?
Removing Manifest from my local copy and doing --sync did the trick; perhaps it's possible to do update mtime on the broken Manifest files on the main rsync repository which should fix it for all?
(In reply to SN (Enlik) from comment #31) > That above will hopefully reduce future occurences, but could you all please > consider regenerating Manifest files for the broken packages? The ones on the master ARE correct. The problem is that they have the same timestamp (derived from the last commit in a package) as the previous version, so mirrors don't always pick it up :-( [rsync --checksum rightly considered harmful by some mirrors]. (In reply to SN (Enlik) from comment #32) > Removing Manifest from my local copy and doing --sync did the trick; perhaps > it's possible to do update mtime on the broken Manifest files on the main > rsync repository which should fix it for all? The repo is generated in a repeatable fashion from Git, the only reliable way to change the mtime is to commit something to a file that contributes to the Manifest.
Created attachment 449520 [details, diff] Bump manifest mtime if portage changed the manifest, but mtime is supposed to remain the same Currently ChangeLogs can have mtimes that end up newer than the most recent commit to that package, because the mtime is not set back to match the commit time of the latest commit they contain. This patch works around that edge case and others by bumping the manifest mtime if portage actually changed the manifest during thickening, but the mtime we think the manifest should be is its current mtime.
So that patch is still important, but it doesn't fix all the ChangeLog edge cases. dev-java/emma, for example, currently has a changelog newer than any commit that's touched it, but the manifest mtime in maybe_thicken_manifest will be less than the changelog, so changelog will be declared newest, and thickened manifest will get that mtime. I'm tempted to just omit the if from the patch, and unconditionally bump mtime by a second if it was modified.
Is https://forums.gentoo.org/viewtopic-p-7974398.html caused by this bug?
@portage: in the very near future, ChangeLogs will NOT be in the main rsync tree. The Council already approved this, Infra just hasn't turned it off yet until we're ready to publish the parallel changelog module (if users want it, they need to rsync from both repos, copying changelogs on top). We need to ensure, at that point: - if the changelog is absent on disk, and present in Manifest: NONFATAL - if changelog* is present on disk, and absent in Manifest: NONFATAL - if changelog* is present on disk, present in Manifest & does NOT match: UNDECIDED Parts of this should have been covered in my Manifest2 treesigning GLEPs, which I think got implementation in the gkeys GSOC2016 project, but need confirm before going ahead, and then we can avoid the bug in general.
The ones that are failing as of 07.10.2016 are committed by ago again. Maybe there's something wrong in his setup? https://gitweb.gentoo.org/repo/gentoo.git/commit/x11-libs/libX11?id=43e606f494bae7b050accab7ebc4263dda0fed72 https://gitweb.gentoo.org/repo/gentoo.git/commit/x11-libs/libXrender?id=3ce8f0b9dcb2177a752041b86a010458271e97ac etc.
(In reply to Simon from comment #38) > The ones that are failing as of 07.10.2016 are committed by ago again. Maybe > there's something wrong in his setup? There's nothing wrong with his commits, but apparently they broke some fragile assumptions in thicken-manifests.py.
(In reply to Robin Johnson from comment #37) > We need to ensure, at that point: > - if the changelog is absent on disk, and present in Manifest: NONFATAL The first case is already supported since Manifest2 (portage-2.1). The changelogs are categorized as MISC type, for which the Manifest2 code has always used ignoreMissingFiles=True: https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage.py?id=f993747ca501e8a70d6f6174711149a172cfc3c2#n2174 > - if changelog* is present on disk, and absent in Manifest: NONFATAL > - if changelog* is present on disk, present in Manifest & does NOT match: > UNDECIDED The last 2 cases will require portage changes.
>>> Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/x11-libs/libXtst/libXtst-1.2.3.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 831 !!! Expected: 832
Comment on attachment 449520 [details, diff] Bump manifest mtime if portage changed the manifest, but mtime is supposed to remain the same Patch moved to bug 596934
is this below caused by this bug? >>> Fetching (2 of 5) app-misc/elasticsearch-5.0.0::gentoo !!! Digest verification failed: !!! /portage/app-misc/elasticsearch/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 8045 !!! Expected: 7844 >>> Failed to emerge app-misc/elasticsearch-5.0.0 >>> Fetching (3 of 5) net-print/cups-filters-1.11.5::gentoo !!! Digest verification failed: !!! /portage/net-print/cups-filters/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 16271 !!! Expected: 15843 >>> Failed to emerge net-print/cups-filters-1.11.5 >>> Fetching (4 of 5) app-crypt/qca-2.1.1::gentoo !!! Digest verification failed: !!! /portage/app-crypt/qca/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 5471 !!! Expected: 5270 >>> Failed to emerge app-crypt/qca-2.1.1 >>> Fetching (5 of 5) net-print/hplip-3.16.10::gentoo !!! Digest verification failed: !!! /portage/net-print/hplip/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 8466 !!! Expected: 8315 >>> Failed to emerge net-print/hplip-3.16.10 * * The following 4 packages have failed to build, install, or execute * postinst: * * (app-misc/elasticsearch-5.0.0:0/0::gentoo, ebuild scheduled for merge) * (net-print/cups-filters-1.11.5:0/0::gentoo, ebuild scheduled for merge) * (app-crypt/qca-2.1.1:2/2::gentoo, ebuild scheduled for merge) * (net-print/hplip-3.16.10:0/0::gentoo, ebuild scheduled for merge) *
(In reply to jms from comment #43) > is this below caused by this bug? Please disregard comment #43 did a removing in the ebuild and distfile in portage of the above package and fetching them again all is ok now
*** Bug 598414 has been marked as a duplicate of this bug. ***
*** Bug 598434 has been marked as a duplicate of this bug. ***
!!! Digest verification failed: !!! /usr/portage/sys-kernel/gentoo-sources/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 66345 !!! Expected: 66162
*** Bug 598440 has been marked as a duplicate of this bug. ***
*** Bug 598474 has been marked as a duplicate of this bug. ***
*** Bug 598501 has been marked as a duplicate of this bug. ***
*** Bug 598513 has been marked as a duplicate of this bug. ***
*** Bug 598539 has been marked as a duplicate of this bug. ***
With dwfreed's very kind assistance, I've removed and reverted the Manifest of what should hopefully be the bulk of the broken packages. Once this hits your local mirror, feel free to report any others that are missed and I'll manually touch those too.
*** Bug 598541 has been marked as a duplicate of this bug. ***
*** Bug 598535 has been marked as a duplicate of this bug. ***
Michael, the emerge on my workstation passed all digest verifications now. I'n happily compiling and installing 202 updated packages as I write this. :-) Thank you for the quick work-around. I hope the final solution will come quick. Thanks!
ChangeLogs are now dropped.
