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