[gentoo-user] -x11-proto/xineramaproto Digest verification failed

[gentoo-user] -x11-proto/xineramaproto Digest verification failed

[kevin]

localhost ~ # emerge -e world
Calculating world dependencies... done!
>>> Verifying ebuild Manifests...

!!! Digest verification failed:
!!! /usr/portage/x11-proto/xineramaproto/ChangeLog
!!! Reason: Filesize does not match recorded size
!!! Got: 3741
!!! Expected: 3843
localhost ~ #

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -x11-proto/xineramaproto Digest verification failed

[Herbert Laubner]

See message below:

Herbert Laubner <laubner@gmx.net> posted
44213F29-50C9-4EFF-8914-8444389095DA@gmx.net, excerpted below, on   
Sat, 08
Sep 2007 10:14:01 +0200:


> I am installing xorg-x11 on an amd64 machine.
>
> On xextproto-7.0.2 the digest verification failed. Is there a change
> giong on or is there a bugy file on the server?
>

The digest on the ebuild itself or a different file?  If it's the ebuild
or something in the synced tree, try resyncing, and if that doesn't  
work,
you can wait a day and try again, or verify against the file at
http://viewcvs.gentoo.org and redigest if you trust the results.  (Note
that the viewcvs version won't exactly match either, or didn't last I  
had
to use it, as its source tracking lines are slightly different.  You can
verify the actual code, however, line by line or by downloading and with
a diff.)  If the viewcvs version is the same but for the source tracking
lines, check for a bug and file one if there's none filed.  There's a
known issue in instances when an ebuild was in the tree (likely never
unmasked), removed, and then later added again at the same version,  
where
the system gets mixed up and the digest doesn't match.  The size is off
by a specific small amount, 4 or 6 bytes, IIRC.  That's the most common
reason for a no-match not attributable to a bad sync, and one the Gentoo
maintainer is often not aware of until he gets a bug about it.

If it's something in distfiles (basically, if it's one of the tarballs),
delete it from your distfiles cache and try again.  It may have been a
problem in the download.  If that doesn't fix it, check bugs and file  
one
if necessary.

FWIW, my last sync was a couple days ago (well, three, Sept. 5, early
morning US), but updated as of then, xextproto-7.0.2.ebuild has a ctime
of Feb 6, an mtime of Feb 4, so it has been around for awhile.  The
Manifest file likewise, so no distfile changes since then, either.  I  
did
a total rebuild (emerge -e world) back in May (wow, has it been /that/
long since gcc 4.2?  seems so!), so that's when I last emerged it.  The
tar.bz2 distfile should be 68323 bytes, the ebuild 444.

Hmmm!  "Houston.  We have a problem!"

I just synced to double-check, and while the version remained the same
and neither the ebuild nor the changelog changed, the Manifest did.   
When
I looked at it above, it wasn't yet signed.  It looks like they gpg-
signed it (a part of the security they are gradually implementing in the
tree), but when they did, something happened to the distfile/tarball
size.  Above, it was 68323, now it says 68342, yet the version number is
the same!  That should NOT happen!

The previous one should I believe be the correct one.  If you get 68323
bytes and an md5sum of 242388ab65dde3a3dd313eeee265e429, it /should/ be
reasonably safe (but still it's your decision whether the risk is worth
it) to go ahead and redigest and merge it, as that's probably the real
one -- it agrees with what I have here.

Looks like there's already a bug on it (from last year):
http://bugs.gentoo.org/show_bug.cgi?id=150225

Seems upstream (xorg) silently changed the tarball without changing the
version number... back in 2006.  Maybe they pulled the same trick once
again (I see a passel of X updates waiting... on ~amd64, probably not so
many for stable... just checked, xorg 7.3 released on the sixth, must be
that).  If so, it may be a bit before all sources locations have the
correct file, since the version didn't change, so even deleting the
tarball and redownloading might not get you the new one for a few days.

FWIW, deleting and redownloading, I get the 68323 byte version, same as
before.  Maybe it's time for a new bug?  Double-checking, yes, it's time
for a new bug, as downloading manually directly from (as gotten from the
ebuild, followed to the eclass):

http://xorg.freedesktop.org/releases/individual/proto/

results in a file exactly 68323 bytes long, the old size.  Thus, the
Manifest file seems to be wrong.

OK, bug filed (with you credited as bringing it to my attention):

http://bugs.gentoo.org/show_bug.cgi?id=191676

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list


Am 08.09.2007 um 18:59 schrieb kevin:

> localhost ~ # emerge -e world
> Calculating world dependencies... done!
>>>> Verifying ebuild Manifests...
>
> !!! Digest verification failed:
> !!! /usr/portage/x11-proto/xineramaproto/ChangeLog
> !!! Reason: Filesize does not match recorded size
> !!! Got: 3741
> !!! Expected: 3843
> localhost ~ #
>
> -- 
> gentoo-user@gentoo.org mailing list

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -x11-proto/xineramaproto Digest verification failed

[Dan Farrell]

On Sat, 8 Sep 2007 19:11:11 +0200
Herbert Laubner <laubner@gmx.net> wrote:

> See message below:
> 
> Herbert Laubner <laubner@gmx.net> posted
> 44213F29-50C9-4EFF-8914-8444389095DA@gmx.net, excerpted below, on   
> Sat, 08
> Sep 2007 10:14:01 +0200:
> 
> 
> > I am installing xorg-x11 on an amd64 machine.
> >
> > On xextproto-7.0.2 the digest verification failed. Is there a change
> > giong on or is there a bugy file on the server?
> >
> 
> The digest on the ebuild itself or a different file?  If it's the
> ebuild or something in the synced tree, try resyncing, and if that
> doesn't work,
> you can wait a day and try again, or verify against the file at
> http://viewcvs.gentoo.org and redigest if you trust the results.
> (Note that the viewcvs version won't exactly match either, or didn't
> last I had
> to use it, as its source tracking lines are slightly different.  You
> can verify the actual code, however, line by line or by downloading
> and with a diff.)  If the viewcvs version is the same but for the
> source tracking lines, check for a bug and file one if there's none
> filed.  There's a known issue in instances when an ebuild was in the
> tree (likely never unmasked), removed, and then later added again at
> the same version, where
> the system gets mixed up and the digest doesn't match.  The size is
> off by a specific small amount, 4 or 6 bytes, IIRC.  That's the most
> common reason for a no-match not attributable to a bad sync, and one
> the Gentoo maintainer is often not aware of until he gets a bug about
> it.
> 
> If it's something in distfiles (basically, if it's one of the
> tarballs), delete it from your distfiles cache and try again.  It may
> have been a problem in the download.  If that doesn't fix it, check
> bugs and file one
> if necessary.
> 
> FWIW, my last sync was a couple days ago (well, three, Sept. 5, early
> morning US), but updated as of then, xextproto-7.0.2.ebuild has a
> ctime of Feb 6, an mtime of Feb 4, so it has been around for awhile.
> The Manifest file likewise, so no distfile changes since then,
> either.  I did
> a total rebuild (emerge -e world) back in May (wow, has it been /that/
> long since gcc 4.2?  seems so!), so that's when I last emerged it.
> The tar.bz2 distfile should be 68323 bytes, the ebuild 444.
> 
> Hmmm!  "Houston.  We have a problem!"
> 
> I just synced to double-check, and while the version remained the same
> and neither the ebuild nor the changelog changed, the Manifest did.   
> When
> I looked at it above, it wasn't yet signed.  It looks like they gpg-
> signed it (a part of the security they are gradually implementing in
> the tree), but when they did, something happened to the
> distfile/tarball size.  Above, it was 68323, now it says 68342, yet
> the version number is the same!  That should NOT happen!
> 
> The previous one should I believe be the correct one.  If you get
> 68323 bytes and an md5sum of 242388ab65dde3a3dd313eeee265e429,
> it /should/ be reasonably safe (but still it's your decision whether
> the risk is worth it) to go ahead and redigest and merge it, as
> that's probably the real one -- it agrees with what I have here.
> 
> Looks like there's already a bug on it (from last year):
> http://bugs.gentoo.org/show_bug.cgi?id=150225
> 
> Seems upstream (xorg) silently changed the tarball without changing
> the version number... back in 2006.  Maybe they pulled the same trick
> once again (I see a passel of X updates waiting... on ~amd64,
> probably not so many for stable... just checked, xorg 7.3 released on
> the sixth, must be that).  If so, it may be a bit before all sources
> locations have the correct file, since the version didn't change, so
> even deleting the tarball and redownloading might not get you the new
> one for a few days.
> 
> FWIW, deleting and redownloading, I get the 68323 byte version, same
> as before.  Maybe it's time for a new bug?  Double-checking, yes,
> it's time for a new bug, as downloading manually directly from (as
> gotten from the ebuild, followed to the eclass):
> 
> http://xorg.freedesktop.org/releases/individual/proto/
> 
> results in a file exactly 68323 bytes long, the old size.  Thus, the
> Manifest file seems to be wrong.
> 
> OK, bug filed (with you credited as bringing it to my attention):
> 
> http://bugs.gentoo.org/show_bug.cgi?id=191676
> 

Problem solved now, anyway.  
-- 
gentoo-user@gentoo.org mailing list