Created attachment 746829 [details] emerge --info portage seem to fail with "Exception in callback AsynchronousTask" when installing a package from haskell overlay. This happens only when some temporary files in "/var/tmp/portage/" exist. Here is the actual output of the failure. temanbk /var/tmp/portage # emerge -av pandoc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-text/pandoc-2.14.2:0/2.14.2::haskell USE="-doc -embed-data-files -hoogle -hscolour -profile -test -trypandoc" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] yes >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-text/pandoc-2.14.2::haskell rm: cannot remove '/var/tmp/portage/app-text/pandoc-2.14.2/files': Is a directory * pandoc-2.14.2.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7fe02a18b820>>) handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7fe02a18b820>>)> Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/portage/package/ebuild/prepare_build_dirs.py", line 484, in _prepare_fake_filesdir link_target = os.readlink(symlink_path) File "/usr/lib/python3.9/site-packages/portage/__init__.py", line 282, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 22] Invalid argument: b'/var/tmp/portage/app-text/pandoc-2.14.2/files' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.9/asyncio/events.py", line 80, in _run self._context.run(self._callback, *self._args) File "/usr/lib/python3.9/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb listener(self) File "/usr/lib/python3.9/site-packages/_emerge/EbuildPhase.py", line 187, in _async_start_exit self._start_lock() File "/usr/lib/python3.9/site-packages/_emerge/EbuildPhase.py", line 210, in _start_lock self._start_ebuild() File "/usr/lib/python3.9/site-packages/_emerge/EbuildPhase.py", line 248, in _start_ebuild _prepare_fake_filesdir(self.settings) File "/usr/lib/python3.9/site-packages/portage/package/ebuild/prepare_build_dirs.py", line 486, in _prepare_fake_filesdir os.symlink(real_filesdir, symlink_path) File "/usr/lib/python3.9/site-packages/portage/__init__.py", line 282, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) FileExistsError: [Errno 17] File exists: b'/var/lib/layman/haskell/app-text/pandoc/files' -> b'/var/tmp/portage/app-text/pandoc-2.14.2/files' Terminated The structure of the /var/tmp/app-text directory that triggers the failure: temanbk /var/tmp/portage # tree /var/tmp/portage/app-text/ /var/tmp/portage/app-text/ └── pandoc-2.14.2 ├── distdir │ └── pandoc-2.14.2.tar.gz -> /usr/portage/distfiles/pandoc-2.14.2.tar.gz ├── empty ├── files │ ├── pandoc-2.13-haddock-library-1.10.patch │ └── pandoc-2.13-trypandoc.patch ├── homedir ├── temp │ ├── build.log │ ├── eclass-debug.log │ ├── environment │ └── logging └── work 8 directories, 6 files
This might “just” be leftover files in tmp/portage from an intermediate broken Portage version.
This is very likely to be the case. However, it seems that portage can handle this a bit better than failing with a system error.
*** This bug has been marked as a duplicate of bug 815871 ***
(In reply to Artem Shinkarov from comment #2) > This is very likely to be the case. However, it seems that portage can > handle this a bit better than failing with a system error. Yeah, it's similar to bug 815871 but not identical.
(In reply to Artem Shinkarov from comment #0) > >>> Emerging (1 of 1) app-text/pandoc-2.14.2::haskell > rm: cannot remove '/var/tmp/portage/app-text/pandoc-2.14.2/files': Is a > directory The __dyn_clean function fails here to remove the directory here: > rm -f "${PORTAGE_BUILDDIR}/files" It will only be a directory if it was created by one of the portage versions prior to portage-3.0.28, and portage-3.0.28 reverted the behavior in this commit: https://gitweb.gentoo.org/proj/portage.git/commit/?id=c2da00e04086fa8eefc981e97ae3559d42c4937d
It's unlikely anyone has leftover files from affected portage versions at this point.
