On Wed, Oct 13, 2010 at 12:05:40PM -0700, Hilco Wijbenga wrote:
> * The 'prerm' phase of the 'www-client/arora-0.11.0' package has failed
> * with exit value -1.
> *
> * The problem occurred while executing the ebuild file named
> * 'arora-0.11.0.ebuild' located in the '/var/db/pkg/www-
> * client/arora-0.11.0' directory. If necessary, manually remove the
> * environment.bz2 file and/or the ebuild file located in that directory.
> *
> * Removal of the environment.bz2 file is preferred since it may allow the
> * removal phases to execute successfully. The ebuild will be sourced and
> * the eclasses from the current portage tree will be used when necessary.
> * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm()
> * removal phases to be skipped entirely.
>
> * Messages for package www-client/arora-0.11.0:
>
> * The 'prerm' phase of the 'www-client/arora-0.11.0' package has failed
> * with exit value -1.
> *
> * The problem occurred while executing the ebuild file named
> * 'arora-0.11.0.ebuild' located in the '/var/db/pkg/www-
> * client/arora-0.11.0' directory. If necessary, manually remove the
> * environment.bz2 file and/or the ebuild file located in that directory.
> *
> * Removal of the environment.bz2 file is preferred since it may allow the
> * removal phases to execute successfully. The ebuild will be sourced and
> * the eclasses from the current portage tree will be used when necessary.
> * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm()
> * removal phases to be skipped entirely.
> Traceback (most recent call last):
> File "/usr/bin/emerge", line 42, in <module>
> retval = emerge_main()
> File "/usr/lib/portage/pym/_emerge/main.py", line 1492, in emerge_main
> myopts, myaction, myfiles, spinner)
> File "/usr/lib/portage/pym/_emerge/actions.py", line 2305, in action_uninstall
> valid_atoms, ldpath_mtimes, ordered=ordered)
> File "/usr/lib/portage/pym/_emerge/unmerge.py", line 507, in unmerge
> scheduler=scheduler)
> File "/usr/lib/portage/pym/portage/dbapi/vartree.py", line 4509, in unmerge
> ldpath_mtimes=ldpath_mtimes)
> File "/usr/lib/portage/pym/portage/dbapi/vartree.py", line 2160, in unmerge
> vartree=self.vartree)
> File "/usr/lib/portage/pym/portage/package/ebuild/doebuild.py", line
> 793, in doebuild
> fd_pipes=fd_pipes, returnpid=returnpid)
> File "/usr/lib/portage/pym/portage/package/ebuild/doebuild.py", line
> 1261, in spawn
> buf.fromfile(f, buffsize)
> IOError: [Errno 5] Input/output error

Strange, an IO error?
Which other packages do you have this problem with?


W
--
Willie W. Wong wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire
et vice versa ~~~ I. Newton

On 13 October 2010 15:29, Dean Matzkov <bapabooiee@gmail.com> wrote:
> Have you tried upgrading to the latest version of Portage 2.2? The
> newest version in the tree is currently portage-2.2_rc95, while you're
> still using portage-2.2_rc67. Perhaps there's a bug causing this that
> was fixed in subsequent release?

I didn't really want to be running cutting edge portage but it did
solve my problem. I can unmerge again. :-)

Well, if you were running portage-2-2_rc67, that's already pretty much
bleeding edge =P

But just out of curiosity, though, is there any particular reason
you're not running a more-stable version of Portage, such as v2.1.8.3
or v2.1.9.17? The 2.2 release-candidates are hard-masked for a reason
- which includes things randomly breaking, such as this unmerge issue
you experienced.

On Wed, Oct 13, 2010 at 7:52 PM, Hilco Wijbenga
<hilco.wijbenga@gmail.com> wrote:
> I didn't really want to be running cutting edge portage but it did
> solve my problem. I can unmerge again. :-)

On Wed, 13 Oct 2010 18:52:14 -0700, Hilco Wijbenga wrote:

> > Have you tried upgrading to the latest version of Portage 2.2? The
> > newest version in the tree is currently portage-2.2_rc95, while you're
> > still using portage-2.2_rc67. Perhaps there's a bug causing this that
> > was fixed in subsequent release?
>
> I didn't really want to be running cutting edge portage but it did
> solve my problem. I can unmerge again. :-)

2.2 is cutting edge, that's why it's masked. If you're going to run
cutting edge, you may as well use the sharpest version.


--
Neil Bothwick

Life Support System Failure - Reboot Patient (Y/n)?

On 14 October 2010 00:38, Dean Matzkov <bapabooiee@gmail.com> wrote:
> Well, if you were running portage-2-2_rc67, that's already pretty much
> bleeding edge =P

Yeah, I was wondering if someone would notice that. :-)

> But just out of curiosity, though, is there any particular reason
> you're not running a more-stable version of Portage, such as v2.1.8.3
> or v2.1.9.17? The 2.2 release-candidates are hard-masked for a reason
> - which includes things randomly breaking, such as this unmerge issue
> you experienced.

I don't remember exactly but there was a feature I wanted that wasn't
in Portage 2.1. I think it was Sets. I believe I needed it (or thought
I needed it) to simplify installing KDE.

On 14 October 2010 01:36, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 13 Oct 2010 18:52:14 -0700, Hilco Wijbenga wrote:
>> > Have you tried upgrading to the latest version of Portage 2.2? The
>> > newest version in the tree is currently portage-2.2_rc95, while you're
>> > still using portage-2.2_rc67. Perhaps there's a bug causing this that
>> > was fixed in subsequent release?
>>
>> I didn't really want to be running cutting edge portage but it did
>> solve my problem. I can unmerge again. :-)
>
> 2.2 is cutting edge, that's why it's masked. If you're going to run
> cutting edge, you may as well use the sharpest version.

True. Would it be safe to downgrade to the latest 2.1?

On Thu, Oct 14, 2010 at 2:38 AM, Dean Matzkov <bapabooiee@gmail.com> wrote:
> Well, if you were running portage-2-2_rc67, that's already pretty much
> bleeding edge =P

Except there have been about 30 update releases since that one. Only
the Changelog knows how many things have been fixed in that time.