| 1 |
Nicholas Jones posted <20041020014358.GA1867@××××××.net>, excerpted below, |
| 2 |
on Tue, 19 Oct 2004 21:43:59 -0400: |
| 3 |
|
| 4 |
> So... We've had no bug reports on _rc9 that were beyond trivial. |
| 5 |
> We've added a few more fixes, and now we are quickly pushing 51 |
| 6 |
> to stable. |
| 7 |
|
| 8 |
OK, I admit this should have been bugged, but I've been lazy. However, I |
| 9 |
don't yet see it listed on a quick bug search on "ALL portage 51 binary" |
| 10 |
or replacing the binary with tbz2. |
| 11 |
|
| 12 |
This affects portage up until the last upgrade. I haven't triggered it |
| 13 |
yet on this version (rc9) tho I've emerged quite a bit (including the new |
| 14 |
KDE), but that's potentially due to the issues surrounding the trigger |
| 15 |
event. |
| 16 |
|
| 17 |
The problem concisely is this: Certain binary packages say they are |
| 18 |
corrupt and refuse to install, altho the tbz2 seems to be fine as does the |
| 19 |
ebuild tacked onto the end. It's whatever other data is there that |
| 20 |
portage seems to be calling corrupt. |
| 21 |
|
| 22 |
Trigger situation setup is this: I have hardware stability issues |
| 23 |
apparently related to SMP on my dual Opteron (so amd64). Thus, with |
| 24 |
"long" ebuilds, such as gcc, glibc, xorg, and the kde ebuilds, I often |
| 25 |
find myself rebooting in the middle of the emerge. No problem other than |
| 26 |
the frustration, normally, as I simply use ebuild to resume the compile or |
| 27 |
install steps (where it usually happens, not surprisingly) and continue |
| 28 |
from there as necessary. Sometimes I go into the builddir and issue make |
| 29 |
there, then when it succeeds, I go back and do the ebuild and it redoes |
| 30 |
configure then (with most packages) zooms thru the compile since it's all |
| 31 |
done and continues. |
| 32 |
|
| 33 |
The actual trigger seems to be that the last ebuild session that actually |
| 34 |
does the package, must also at least step thru portions of the compile, |
| 35 |
and do the entire install steps, as well as the package. If it fails in |
| 36 |
the install or package steps, and I reinvoke ebuild package, it will |
| 37 |
create the package, but portage will ALWAYS call the package invalid. |
| 38 |
The same happens if I manually complete the make and touch .compiled, so |
| 39 |
it starts from install, altho in some cases it has been ebuild that put |
| 40 |
the .compiled there and it /still/ fails. |
| 41 |
|
| 42 |
Now, if I take that "invalid" package and manually untar it over the |
| 43 |
existing file system then inject, and emerge clean to remove the old |
| 44 |
version, all is well. |
| 45 |
|
| 46 |
The same if I take that ready for qmerge fake install and qmerge it |
| 47 |
directly. That works fine. |
| 48 |
|
| 49 |
What does NOT work is attempting to emerge the package created from the |
| 50 |
same temporary working dataset as the qmerge that DOES work. |
| 51 |
|
| 52 |
The qmerge works. Manually untarring the "corrupt" tbz2 package works. |
| 53 |
Attempting to emerge it, the package is corrupt/invalid. |
| 54 |
|
| 55 |
Additionally, portage continues to complain about those "invalid" |
| 56 |
packages, every time I attempt an emerge -uD world or otherwise cause it |
| 57 |
to scan them. |
| 58 |
|
| 59 |
AFAIK, the only thing "invalid" about them is the checksum or other |
| 60 |
binary data that must be included. This because the tbz2 package itself |
| 61 |
isn't corrupt, nor does the ebuild tacked onto the end appear to be |
| 62 |
corrupt, as it displays just fine in a text editor, at the end of the tbz2. |
| 63 |
|
| 64 |
I don't expect this to be a stopper, as few use buildpkg or otherwise |
| 65 |
routinely create packages, and fewer still are unstable enough to have it |
| 66 |
occasionally crash between drop of .compiled and the successful completion |
| 67 |
of the package step, which seems to be the critical window. Further, it |
| 68 |
may only happen on AMD64, and it's possible that has been fixed even tho I |
| 69 |
can't see any bugs for it. All that said, it'd be nice to know what's |
| 70 |
going on and if this has come up before elsewhere than bugzilla or I |
| 71 |
simply missed it there, and yes, I /should/ have filed a bug, but I just |
| 72 |
never got it done. =:^( |
| 73 |
|
| 74 |
I guess.. consider this my IRC, since I don't do IRC, but I /do/ do |
| 75 |
newsgroups and /do/ get this list /as/ a newsgroup thru gmane. |
| 76 |
|
| 77 |
-- |
| 78 |
Duncan - List replies preferred. No HTML msgs. |
| 79 |
"They that can give up essential liberty to obtain a little |
| 80 |
temporary safety, deserve neither liberty nor safety." -- |
| 81 |
Benjamin Franklin |
| 82 |
|
| 83 |
|
| 84 |
|
| 85 |
-- |
| 86 |
gentoo-dev@g.o mailing list |
Archives