xfree 4.2.1 ebuild failed when applying patches to X sources. I'm using the Oct 20, 2002 snapshot of the portage tree. Here's the tail end of the build log: + echo -e ' * 001_all_4.2.0-G450.patch.bz2...' * 001_all_4.2.0-G450.patch.bz2... + bzip2 -dc /usr/portage/x11-base/xfree/files/4.2.1-patches/001_all_4.2.0-G450.patch.bz2 + patch -p2 + diefunc src_unpack 208 1 'Failed Patch: 001_all_4.2.0-G450.patch.bz2!' + local funcname=src_unpack lineno=208 exitcode=1 + shift 3 + echo + echo '!!! ERROR: The ebuild did not complete successfully.' !!! ERROR: The ebuild did not complete successfully. + echo '!!! Function src_unpack, Line 208, Exitcode 1' !!! Function src_unpack, Line 208, Exitcode 1 + echo '!!! Failed Patch: 001_all_4.2.0-G450.patch.bz2!' !!! Failed Patch: 001_all_4.2.0-G450.patch.bz2! + echo + exit 1 ...done!
Created attachment 4869 [details] Full log from emerge -d xfree
the same bug here...
I deleted /usr/portage/x11* from my portage tree and re-extracted the portage snapshot today. The problem has now gone away. It seems that by using the daily snapshots the xfree ebuid was picking up some old stuff, whereas using rsync the old stuff is deleted. What is the correct way to handle this situation?
you are right i clean my portage tree every time before uncompress the daily snapshot.
i delete every directory except distfile (there are the downloaded source)
Should cleaning the portage tree then be standard practice before opening the snapshot tarball? In which case it needs to be documented.
Yep, guess not many devs use the snapshots, and this is the first time we had a problem like this. Collin, can you fix the docs please ?
from #7115: ------- Additional Comment #3 From Daniel Ahlberg 2002-08-29 06:26 ------- You need to completly remove the /usr/portage to get rid of old ebuild files from earlier snapshots, just overwriting with the new snapshots isn't enough. Since the ebuild has been removed from CVS I can't update it :-/.
zhen please watch Additional Comment #7
Is this in a specific guide, or should I add this to the FAQ? Cheers, //ZhEN
Is there docs about the daily snapshots ?
I do not think so, but I am not positive. I checked both the portage user guide and the developers guide, and it does not seem to be in either. Maybe this info needs to be included in them?
Not sure, as not my 'domain' ... Err, who is handling the snapshots and stuff ?
Carpaski maybe? I will add him to the cc list. //zhen
drobbins does this by crontab afaik
OK, well let's narrow down the problem. If Grant had old ebuilds or data in his Portage tree, either: 1) He didn't rsync recently 2) He synced with a rsync mirror that was stale 3) He is using an older version of Portage and didn't use the "--clean" option with rsync, which used to be required to clean out "old stuff" I don't know if there is a way to determine at this point what exactly happened, unless it's #3 and he hasn't upgraded Portage since then, and we can verify that it was old enough to require the --clean option. Probably it's best to ensure that he can get the new data, and that our current build is correct, and then close this bug.
Daniel, he was using the daily snapshots .... This is where the problems came into. He just untarred the new tarball without cleaning out /usr/portage first ...
On that note, it might be advisable (if we add to docs) to remind the user about /usr/portage/distfiles if he may want to keep it.
In other words, remove all portage-relevant files from distfiles if they want to use snapshots? //zhen
Err, no. Lets try again .. the issue is about not clearing /usr/portage when using snapshots (almost like the 'emerge rsync --clean' which is done by default now ...). We should just also maybe mention that if the user want to keep /usr/portage/distfiles, he should move it aside, or change where it is in make.conf.
Looks like developer docs to me.. //zhen
portage now runs clean automagically
