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
prev parent 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