The package's source tree is broken: * Package: dev-python/keystoneauth-2.3.0 * Repository: gentoo * Maintainer: prometheanfire@gentoo.org * USE: abi_x86_64 amd64 elibc_glibc kernel_linux python_targets_python2_7 python_targets_python3_4 userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking keystoneauth1-2.3.0.tar.gz to /var/tmp/portage/dev-python/keystoneauth-2.3.0/work >>> Source unpacked in /var/tmp/portage/dev-python/keystoneauth-2.3.0/work * ERROR: dev-python/keystoneauth-2.3.0::gentoo failed (prepare phase): * The source directory '/var/tmp/portage/dev-python/keystoneauth-2.3.0/work/keystoneauth-2.3.0' doesn't exist The directory that is created in /var/tmp/portage is actually called: /var/tmp/portage/dev-python/keystoneauth-2.3.0/work/keystoneauth1-2.3.0 Notice the "1" in "keystoneauth1". Reproducible: Always
Broken ebuilds are all to common. By this I mean ebuilds that don't build for some reason that has nothing to do with the validity of the source code being compiled. Missing dependencies, incorrect paths, etc. A deploy toolchain that included some basic CI unit testing would catch these easy mistakes. A jenkins job that simply built the package using the default USE flags for a desktop profile would do wonders. Do you need a volunteer to implement this?
https://github.com/openstack/keystoneauth The directory structure can be seen here. Sure enough the folder is called keystoneauth1. The ebuild must be fixed to work with this.
Here's the fix. Add this to the ebuild: S="${WORKDIR}/${PN}1-${PV}"
I can confirm the bug. This is indeed such a big one, the commiter clearly hasn't even tried to emerge it ...
The problem is bigger than that. This is probably not the place to start this discussion, but what the hell. An ebuild in this condition should never make it to the portage tree. There needs to be tests (automated) that happen before that point. Even the most basic CI would have caught this problem. If the packgage is committed to the repo and appears publicly, it's already too late. Please feel free to point me to the right place to have this discussion. I care about gentoo, and I would offer my services toward the implementation of a proper, modern deployment pipeline. If it is gentoo's mission to be taken seriously as a distro, then this is a must. I see problems like this at least once a month, and they are entirely avoidable.
In the meantime: add the one-line fix to the ebuild file and then run: ebuild /usr/portage/dev-python/keystoneauth/keystoneauth-2.3.0.ebuild manifest That will allow you to install the package. The next portage sync will revert the ebuild, but it won't matter because you'll already have the package installed.
Yeah, thanks, I know how to patch ebuild locally. I would like too to help hardening the 'pipeline' as you say. But i'm afraid it's too late. You lucky to find such kind of ebuilds only once a month, I meet them more often, and with years it's getting worse and worse.
This was fixed soon after and the current version is 2.4.0. When you have to update over 100 ebuilds you'll miss one or two too.
Of course. That's why I'm suggesting that we use the great tools at our disposal to catch these problems for us. That's what computers are for. I reiterate my desire to volunteer.
