[gentoo-dev] Re: Portage-2.0.51 STABLE TESTING

[Duncan <1i5t5.duncan@cox.net>]

Nicholas Jones posted <20041020014358.GA1867@twobit.net>, excerpted below,
 on Tue, 19 Oct 2004 21:43:59 -0400:

> So... We've had no bug reports on _rc9 that were beyond trivial.
> We've added a few more fixes, and now we are quickly pushing 51
> to stable.

OK, I admit this should have been bugged, but I've been lazy.  However, I
don't yet see it listed on a quick bug search on "ALL portage 51 binary"
or replacing the binary with tbz2.

This affects portage up until the last upgrade.  I haven't triggered it
yet on this version (rc9) tho I've emerged quite a bit (including the new
KDE), but that's potentially due to the issues surrounding the trigger
event.

The problem concisely is this:  Certain binary packages say they are
corrupt and refuse to install, altho the tbz2 seems to be fine as does the
ebuild tacked onto the end.  It's whatever other data is there that
portage seems to be calling corrupt.

Trigger situation setup is this:  I have hardware stability issues
apparently related to SMP on my dual Opteron (so amd64).  Thus, with
"long" ebuilds, such as gcc, glibc, xorg, and the kde ebuilds, I often
find myself rebooting in the middle of the emerge.  No problem other than
the frustration, normally, as I simply use ebuild to resume the compile or
install steps (where it usually happens, not surprisingly) and continue
from there as necessary.  Sometimes I go into the builddir and issue make
there, then when it succeeds, I go back and do the ebuild and it redoes
configure then (with most packages) zooms thru the compile since it's all
done and continues.

The actual trigger seems to be that the last ebuild session that actually
does the package, must also at least step thru portions of the compile,
and do the entire install steps, as well as the package.  If it fails in
the install or package steps, and I reinvoke ebuild package, it will
create the package, but portage will ALWAYS call the package invalid. 
The same happens if I manually complete the make and touch .compiled, so
it starts from install, altho in some cases it has been ebuild that put
the .compiled there and it /still/ fails.

Now, if I take that "invalid" package and manually untar it over the
existing file system then inject, and emerge clean to remove the old
version, all is well.

The same if I take that ready for qmerge fake install and qmerge it
directly.  That works fine.

What does NOT work is attempting to emerge the package created from the
same temporary working dataset as the qmerge that DOES work.

The qmerge works.  Manually untarring the "corrupt" tbz2 package works. 
Attempting to emerge it, the package is corrupt/invalid.

Additionally, portage continues to complain about those "invalid"
packages, every time I attempt an emerge -uD world or otherwise cause it
to scan them.

AFAIK, the only thing "invalid" about them is the checksum or other
binary data that must be included. This because the tbz2 package itself
isn't corrupt, nor does the ebuild tacked onto the end appear to be
corrupt, as it displays just fine in a text editor, at the end of the tbz2.

I don't expect this to be a stopper, as few use buildpkg or otherwise
routinely create packages, and fewer still are unstable enough to have it
occasionally crash between drop of .compiled and the successful completion
of the package step, which seems to be the critical window.  Further, it
may only happen on AMD64, and it's possible that has been fixed even tho I
can't see any bugs for it.  All that said, it'd be nice to know what's
going on and if this has come up before elsewhere than bugzilla or I
simply missed it there, and yes, I /should/ have filed a bug, but I just
never got it done. =:^(

I guess.. consider this my IRC, since I don't do IRC, but I /do/ do
newsgroups and /do/ get this list /as/ a newsgroup thru gmane.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list