public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dan Farrell <dan@spore.ath.cx>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] -x11-proto/xineramaproto Digest verification failed
Date: Sat, 8 Sep 2007 21:07:56 -0500	[thread overview]
Message-ID: <20070908210756.707630e6@pascal.spore.ath.cx> (raw)
In-Reply-To: <1958BF7A-F070-4FB8-982F-B0EF7BC9FEBF@gmx.net>

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



      reply	other threads:[~2007-09-09  2:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-08 16:59 [gentoo-user] -x11-proto/xineramaproto Digest verification failed kevin
2007-09-08 17:11 ` Herbert Laubner
2007-09-09  2:07   ` Dan Farrell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070908210756.707630e6@pascal.spore.ath.cx \
    --to=dan@spore.ath.cx \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox