| 1 |
Herbert Laubner <laubner@×××.net> posted |
| 2 |
44213F29-50C9-4EFF-8914-8444389095DA@×××.net, excerpted below, on Sat, 08 |
| 3 |
Sep 2007 10:14:01 +0200: |
| 4 |
|
| 5 |
> I am installing xorg-x11 on an amd64 machine. |
| 6 |
> |
| 7 |
> On xextproto-7.0.2 the digest verification failed. Is there a change |
| 8 |
> giong on or is there a bugy file on the server? |
| 9 |
|
| 10 |
The digest on the ebuild itself or a different file? If it's the ebuild |
| 11 |
or something in the synced tree, try resyncing, and if that doesn't work, |
| 12 |
you can wait a day and try again, or verify against the file at |
| 13 |
http://viewcvs.gentoo.org and redigest if you trust the results. (Note |
| 14 |
that the viewcvs version won't exactly match either, or didn't last I had |
| 15 |
to use it, as its source tracking lines are slightly different. You can |
| 16 |
verify the actual code, however, line by line or by downloading and with |
| 17 |
a diff.) If the viewcvs version is the same but for the source tracking |
| 18 |
lines, check for a bug and file one if there's none filed. There's a |
| 19 |
known issue in instances when an ebuild was in the tree (likely never |
| 20 |
unmasked), removed, and then later added again at the same version, where |
| 21 |
the system gets mixed up and the digest doesn't match. The size is off |
| 22 |
by a specific small amount, 4 or 6 bytes, IIRC. That's the most common |
| 23 |
reason for a no-match not attributable to a bad sync, and one the Gentoo |
| 24 |
maintainer is often not aware of until he gets a bug about it. |
| 25 |
|
| 26 |
If it's something in distfiles (basically, if it's one of the tarballs), |
| 27 |
delete it from your distfiles cache and try again. It may have been a |
| 28 |
problem in the download. If that doesn't fix it, check bugs and file one |
| 29 |
if necessary. |
| 30 |
|
| 31 |
FWIW, my last sync was a couple days ago (well, three, Sept. 5, early |
| 32 |
morning US), but updated as of then, xextproto-7.0.2.ebuild has a ctime |
| 33 |
of Feb 6, an mtime of Feb 4, so it has been around for awhile. The |
| 34 |
Manifest file likewise, so no distfile changes since then, either. I did |
| 35 |
a total rebuild (emerge -e world) back in May (wow, has it been /that/ |
| 36 |
long since gcc 4.2? seems so!), so that's when I last emerged it. The |
| 37 |
tar.bz2 distfile should be 68323 bytes, the ebuild 444. |
| 38 |
|
| 39 |
Hmmm! "Houston. We have a problem!" |
| 40 |
|
| 41 |
I just synced to double-check, and while the version remained the same |
| 42 |
and neither the ebuild nor the changelog changed, the Manifest did. When |
| 43 |
I looked at it above, it wasn't yet signed. It looks like they gpg- |
| 44 |
signed it (a part of the security they are gradually implementing in the |
| 45 |
tree), but when they did, something happened to the distfile/tarball |
| 46 |
size. Above, it was 68323, now it says 68342, yet the version number is |
| 47 |
the same! That should NOT happen! |
| 48 |
|
| 49 |
The previous one should I believe be the correct one. If you get 68323 |
| 50 |
bytes and an md5sum of 242388ab65dde3a3dd313eeee265e429, it /should/ be |
| 51 |
reasonably safe (but still it's your decision whether the risk is worth |
| 52 |
it) to go ahead and redigest and merge it, as that's probably the real |
| 53 |
one -- it agrees with what I have here. |
| 54 |
|
| 55 |
Looks like there's already a bug on it (from last year): |
| 56 |
http://bugs.gentoo.org/show_bug.cgi?id=150225 |
| 57 |
|
| 58 |
Seems upstream (xorg) silently changed the tarball without changing the |
| 59 |
version number... back in 2006. Maybe they pulled the same trick once |
| 60 |
again (I see a passel of X updates waiting... on ~amd64, probably not so |
| 61 |
many for stable... just checked, xorg 7.3 released on the sixth, must be |
| 62 |
that). If so, it may be a bit before all sources locations have the |
| 63 |
correct file, since the version didn't change, so even deleting the |
| 64 |
tarball and redownloading might not get you the new one for a few days. |
| 65 |
|
| 66 |
FWIW, deleting and redownloading, I get the 68323 byte version, same as |
| 67 |
before. Maybe it's time for a new bug? Double-checking, yes, it's time |
| 68 |
for a new bug, as downloading manually directly from (as gotten from the |
| 69 |
ebuild, followed to the eclass): |
| 70 |
|
| 71 |
http://xorg.freedesktop.org/releases/individual/proto/ |
| 72 |
|
| 73 |
results in a file exactly 68323 bytes long, the old size. Thus, the |
| 74 |
Manifest file seems to be wrong. |
| 75 |
|
| 76 |
OK, bug filed (with you credited as bringing it to my attention): |
| 77 |
|
| 78 |
http://bugs.gentoo.org/show_bug.cgi?id=191676 |
| 79 |
|
| 80 |
-- |
| 81 |
Duncan - List replies preferred. No HTML msgs. |
| 82 |
"Every nonfree program has a lord, a master -- |
| 83 |
and if you use the program, he is your master." Richard Stallman |
| 84 |
|
| 85 |
-- |
| 86 |
gentoo-amd64@g.o mailing list |
Archives