From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6776 invoked from network); 20 Oct 2004 21:36:57 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 20 Oct 2004 21:36:57 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CKO8f-000215-1F for arch-gentoo-dev@lists.gentoo.org; Wed, 20 Oct 2004 21:36:57 +0000 Received: (qmail 24999 invoked by uid 89); 20 Oct 2004 21:36:56 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 12904 invoked from network); 20 Oct 2004 21:36:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Date: Wed, 20 Oct 2004 14:36:51 -0700 Organization: Sometimes Message-ID: References: <20041020014358.GA1867@twobit.net> <200410202121.42464.jstubbs@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-58.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news Subject: [gentoo-dev] Re: Re: Portage-2.0.51 STABLE TESTING X-Archives-Salt: 1f5de395-1ef6-4c8e-9337-cf52fce4a1e6 X-Archives-Hash: 6a1db662751c391ccb3e6419de675a95 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