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

[Duncan]

Jason Stubbs posted <200410202121.42464.jstubbs@g.o>, excerpted
below,  on Wed, 20 Oct 2004 21:21:42 +0900:

> Try running the following on one of those broken packages. The command should
> be on one line and bash...tbz2 should of course be replaced.
>
> python -c 'import xpak; tbz2=xpak.tbz2("bash-3.0-r5.tbz2"); print
> tbz2.getelements("CATEGORY")'
>
> If it's empty, that's the problem. I had a lot of trouble following your
> previous email. Would you be able to list step-by-step how to reproduce the
> problem?

That's it.  A good package ($PORTDIR=/mnt/p, $PACKAGEDIR=/mnt/p/pkg):

"/mnt/p/pkg/All/kdepim-3.3.1.tbz2"
['kde-base']

The two bad packages (followed by a ls to verify the files exist:

"/mnt/p/pkg/All/kdelibs-3.3.1.tbz2"
[]
ls "/mnt/p/pkg/All/kdelibs-3.3.1.tbz2"
/mnt/p/pkg/All/kdelibs-3.3.1.tbz2

"/mnt/p/pkg/All/xorg-x11-6.8.0-r1.tbz2"
[]
ls "/mnt/p/pkg/All/xorg-x11-6.8.0-r1.tbz2"
/mnt/p/pkg/All/xorg-x11-6.8.0-r1.tbz2

On the statement of the problem, I really can't blame you for not
following that so well.  Let's see if this helps:

The problem (variant A):

1) ebuild /path/to/package.ebuild package

2) crash/interrupt during ebuild install or package steps

3) repeat step 1 to complete package without warning or error

4) attempt to install "successfully" created package, get invalid package.

variant B) If step 2-crash occurs during ebuild compile, step 3 and 4 work
fine.

variant C) If step 2-crash occurs during compile and one attempts to do a
manual make to complete the compile, then touches .compiled, step 3 will
of course continue with ebuild install and package steps as it should.
However, package is again invalid in step 4.

All the files are in the "invalid" tbz2 package as expected. They are
browsable from mc with its compressed tar virtual file systems, and
extract correctly with only the expected error about the tacked on portage
data.  Further, an examination with a text editor demonstrates the ebuild
in uncompressed form is tacked onto the end of the tbz2 as with the normal
packages, but the data between the EOF and the ebuild doesn't look quite
right.  (tbz2 EOF verified by deleting the extra stuff and working with
the file without error, thus confirming my guess as to where the EOF was.)

I'd guess that data that doesn't look quite right contains the corrupted
info?

However, in all cases, after the package step that creates the invalid
package, if one then issues qmerge on the still existing working dir, it
will qmerge successfully without error -- from the SAME working dir that
creates the bad package.  I have experienced NO difficulty with said
qmerged ebuilds.  They function correctly and portage seems to have the
correct data about them and functions correctly calculating dependencies
and upgrades as well, with the data.

Therefore, it appears the problem is that portage does /something/ in the
ebuild compile step that isn't retained if the process is interrupted
after that.  When portage attempts to pickup with the interrupted install
step, it's missing the data from the compile step, and doesn't complete
the package successfully.  However, the data is apparently either
recalculated or collected by some other mechanism for qmerge, since that
seems to work without issue.

Thus, the problem /only/ occurs for those with buildpkg set, and /only/ if
the interruption occurred between the completion of ebuild compile, and
successful completion of ebuild package.  As I said, I don't consider this
a release stopper.

Further, I mentioned I hadn't seen it with rc9, but that could be because
I've adjusted my behavior slightly to avoid it.  Later today, I'll try to
deliberately trigger the problem, and see if I can get it to reoccur with
now rc10 (or release, if it's out by then).

-- 
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@g.o mailing list