public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Re: Portage-2.0.51 STABLE TESTING
Date: Wed, 20 Oct 2004 14:36:51 -0700	[thread overview]
Message-ID: <pan.2004.10.20.21.36.50.96533@cox.net> (raw)
In-Reply-To: 200410202121.42464.jstubbs@gentoo.org

Jason Stubbs posted <200410202121.42464.jstubbs@gentoo.org>, 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@gentoo.org mailing list


  reply	other threads:[~2004-10-20 21:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-20  1:43 [gentoo-dev] Portage-2.0.51 STABLE TESTING Nicholas Jones
2004-10-20  5:14 ` [gentoo-dev] " Duncan
2004-10-20 12:10   ` Paul de Vrieze
2004-10-20 12:53     ` Jason Stubbs
2004-10-20 12:21   ` Jason Stubbs
2004-10-20 21:36     ` Duncan [this message]
2004-10-23  1:28       ` [gentoo-dev] " Duncan
2004-10-20 18:14 ` [gentoo-dev] " Alexander Futász
2004-10-20 18:29   ` Nicholas Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2004.10.20.21.36.50.96533@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox