After updating via emerge-webrsync: gpg: Signature made Tue 24 Jan 2012 12:55:25 AM UTC gpg: using RSA key 0xEC590EEAC9189250 gpg: Good signature from "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" Calculating dependencies - * Missing digest for '/usr/portage/app-misc/pax-utils/pax-utils-0.3.0.ebuild' ... done! >>> Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/app-misc/pax-utils/ChangeLog !!! Reason: Filesize does not match recorded size !!! Got: 19466 !!! Expected: 19343 There ought to be some QA in place to prevent such amateur commits.
If you are planning on continuing using such tone, you might as well do a bit of research before saying it out loud: Nothing wrong with Manifest, or ChangeLog: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/pax-utils/ ~/gentoo-x86/app-misc/pax-utils $ grep ChangeLog Manifest MISC ChangeLog 19466 RMD160 449161f746e5b662bc3bca20f8ab421665d26915 SHA1 d3da8021a03474b840823430814f2ced7af004a4 SHA256 85ccdedabeac56a49ac99d85b8bba18e785ea97974f61f1b218e446b9bfd62d7 ~/gentoo-x86/app-misc/pax-utils $ ls -l ChangeLog -rw-r--r-- 1 ssuominen users 19466 Jan 24 11:56 ChangeLog You likely just synced at a bad moment, retry in hour or two.
Please reread my bug report — I used emerge-webrsync, which is the only way I am aware of to update to a signed portage tree. The portage snapshot used by emerge-webrsync persists for 24 hours. > You likely just synced at a bad moment, retry in hour or two. No, the amateur commit was done at a bad moment, causing problems to many users for 24 hours. Now, which "such tone" do you refer to? I am reopening the bug, because I want it to be acknowledged by Mike Frysinger: 24 Jan 2012; Mike Frysinger <vapier@gentoo.org> +pax-utils-0.3.0.ebuild: Version bump. in the hope that such commits will be prevented in the future.
(In reply to comment #2) > Please reread my bug report — I used emerge-webrsync, which is the only way I > am aware of to update to a signed portage tree. The portage snapshot used by > emerge-webrsync persists for 24 hours. Then you'll need to wait for the 24 hours, or simply redigest it yourself. > Now, which "such tone" do you refer to? The one used here and in bug 398931.
> Then you'll need to wait for the 24 hours, or simply redigest it yourself. You are missing the point - such commits are a reoccurring problem, especially since even core developers are prone to do them. There needs to be a QA mechanism in place to prevent them. > The one used here and in bug 398931. Didn't see you commenting in that bug, I assume that's because I was right. I guess you wouldn't be so quick to teach me manners in this bug either, if you read it carefully for the first time. I don't see anything wrong in pointing out incompetence, and if you think I was trolling in bug #398931, you are wrong. That bug should have been escalated to someone else.
(In reply to comment #4) > > Then you'll need to wait for the 24 hours, or simply redigest it yourself. > > You are missing the point - such commits are a reoccurring problem, especially > since even core developers are prone to do them. There needs to be a QA > mechanism in place to prevent them. > Bugzilla is not the proper place to discuss this, use a mailing list instead. The issue at hand has been fixed, there is nothing else we can do, especially not about the 24-hour wait for webrsync users. As such, this bug is resolved, do NOT reopen it. Thanks.
