Summary: | Failure to emerge portage-2.2.00.9063 on SUSE 10 | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Rabbe Fogelholm <rabbe> |
Component: | Prefix Support | Assignee: | Gentoo non-Linux Team <alt> |
Status: | RESOLVED CANTFIX | ||
Severity: | blocker | CC: | zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build log |
Description
Rabbe Fogelholm
2007-12-29 22:14:44 UTC
that is a one-time "feature". In fact your portage is fine, so please restart the merge. After this time, you'll never see it again. It happens when upgrading from a certain portage version (in the bootstrap image) to a recent one, starting I think 3 or 4 releases back ago. Created attachment 139585 [details]
build log
(In reply to comment #1) > that is a one-time "feature". In fact your portage is fine, so please restart > the merge. After this time, you'll never see it again. It happens when > upgrading from a certain portage version (in the bootstrap image) to a recent > one, starting I think 3 or 4 releases back ago. > OK, will try it ... Looks promising. I am redoing `emerge -e system world', and portage was emerged successfully this time. Package 11 out of 69 is being emerged as I write this. So, the workaround is to retry the `emerge -e system world' once if it terminates with a nonzero status. But shouldn't this still be treated as a bug (minor, not blocker)? The only way out is to make a new snapshot, which has a newer portage such that the problem doesn't occur. Alternative would be if Portage would get fixed for this case, but I have no clue where it comes from exactly. So I'll have to do the first one. I have to do that anyway, as our 64-bits targets need them to bootstrap. However, starting from those, you no longer need to emerge subversion explicitly as it's included in the system set for prefix now. |