After updating to eix-0.12.1 (which built correctly under IRIX without needing any changes!), the output of 'update-eix' is as follows: $ update-eix Reading Portage settings .. Building database (/opt/portage/var/cache/eix) .. [0] "gentoo_prefix" /usr/opt/portage/usr/portage/ (cache: parse|ebuild*) Reading 0% Could not properly execute /usr/opt/portage/usr/portage//app-admin/eselect/eselect-1.0.8-r0.01.ebuild Reading % Reading % ... Reading % Reading % Could not properly execute /usr/opt/portage/usr/portage//xfce-extra/xfwm4-themes/xfwm4-themes-4.4.2.ebuild Reading 100% Applying masks .. Calculating hash tables .. Writing database file /opt/portage/var/cache/eix .. Database contains 1670 packages in 151 categories. (Note that ${EPREIX} is set to "/opt/portage", but that /opt is a symlink to /usr/opt) Are these warnings a problem, or just verbose output? What causes them to be generated?
I sincerely have no idea. I saw them on Solaris too, yesterday, but chose to ignore them.
After setting the environment variables export EBUILD="path to your ebuild" export EBUILD_PHASE=depend export dbkey=/tmp/temp-file and, if the ebuild needs, corresponding setting of the environment variables ROOT, EROOT, EPREFIX, PORTDIR_OVERLAY, PORTDIR, O, FILESDIR, ECLASSDIR, CATEGORY, PN, PVR, PF, PR, PV, P the command /usr/lib/portage/bin/ebuild.sh depend should create a metadata file for the package in /tmp/temp-file The error means that for some reason this command failed for the mentioned ebuilds, and so the ebuild is not put into the database. Maybe you can find out for the particular ebuilds what is wrong. (It might e.g. be the case, that an additional environment variable besides the above ones should have to be set?)
% bash tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ export EBUILD="/Library/Gentoo/usr/portage/app-admin/eselect/eselect-1.0.8-r0.01.ebuild" tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ export EBUILD_PHASE=depend tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ export dbkey=/tmp/temp-file tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ /Library/Gentoo/usr/lib/portage/bin/ebuild.sh depend * ERROR: / failed: * eutils.eclass could not be found by inherit() * * Call stack: /Library/Gentoo/usr/lib/portage/bin/isolated-functions.sh: line 35: basename: command not found * :1707: <call source '/Library/Gentoo/usr/portage/app-admin/eselect/eselect-1.0.8-r0.01.ebuild'> /Library/Gentoo/usr/lib/portage/bin/isolated-functions.sh: line 35: basename: command not found * : 7: <call inherit 'eutils' 'autotools'> * ebuild.sh:1199: * * If you need support, post the topmost build error, and the call stack if relevant. * S: '/' Looking around, it feels like ECLASSDIR needs to be set as well, and voila: tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ export ECLASSDIR=/Library/Gentoo/usr/portage/eclass tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ /Library/Gentoo/usr/lib/portage/bin/ebuild.sh depend tefnut /Library/Gentoo/usr/portage/app-admin/eselect $ cat /tmp/temp-file sys-apps/sed doc? ( dev-python/docutils ) || ( sys-apps/coreutils sys-freebsd/freebsd-bin app-admin/realpath ) =sys-devel/automake-1.10* >=sys-devel/autoconf-2.61 sys-devel/libtool sys-apps/sed sys-apps/gawk sys-apps/file 0 mirror://gentoo/.tar.bz2 http://www.gentoo.org/proj/en/eselect/ GPL-2 Modular -config replacement utility ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris ~x86-solaris toolchain-funcs multilib portability eutils libtool autotools doc bash-completion prefix
(In reply to comment #3) > Looking around, it feels like ECLASSDIR needs to be set as well Actually, all of the variables which I had mentioned above (including ECLASSDIR) are set by eix, so I have no idea what might be going wrong. Maybe ebuild.sh exits with nonzero status although everything went well? Another possibility is that the ECLASSDIR or PATH is false (it is very hard to judge where EPREFIX must be prepended and where not); you can of course dump the variables actually used by adding /bin/env >/tmp/env-output at the beginning of the problematic ebuild (outside of any function) before running update-eix.
Created attachment 146771 [details, diff] Fix/Enhance error reporting There is the possibility that this has nothing to do with ebuild.sh, but with the internal shell parser of eix. This patch improves the error-reporting so we can distinguish between the two before mentioned cases. Please apply and post the error message, thank you.
with patch I get things like this: /gentoo/prefix-tree//eclass/java-utils-2.eclass: line 2603: expected `)' /usr/lib/portage/bin/ebuild.sh: /gentoo/prefix-tree//eclass/java-utils-2.eclass: 603: syntax error near `=~' Two things here: /usr/lib/portage/bin/ebuild.sh isn't prefix, and because of that, it doesn't use a prefix shell (hence an old bash)
Thanks. Indeed, due to a forgotten virtual function, EPREFIX_PORTAGE_EXEC was not honoured in parse|ebuild*. New trunk should fix it.
feels fixed in 0.12.2
I don't know whether this is an eix problem or an eclass bug, but I'm now getting: $ update-eix Reading Portage settings .. Building database (/opt/portage/var/cache/eix) .. [0] "gentoo_prefix" /usr/opt/portage/usr/portage/ (exec: /opt/portage) (cache: parse|ebuild*) Reading 72%/usr/opt/portage/usr/portage//eclass/embassy.eclass: line 20: tr: command not found /usr/opt/portage/usr/portage//eclass/embassy.eclass: line 20: tr: command not found <repeated many times> /usr/opt/portage/usr/portage//eclass/embassy.eclass: line 20: tr: command not found 100% Applying masks .. Calculating hash tables .. Writing database file /opt/portage/var/cache/eix .. Database contains 1690 packages in 151 categories. The offending line in embassy.eclass is: 16: # The EMBASSY package name, retrieved from the inheriting ebuild's name 17: EN=${PN:8} 18: # The full name and version of the EMBASSY package (excluding the Gentoo 19: # revision number) 20: EF="$(echo ${EN} | tr "[:lower:]" "[:upper:]")-${PV}" ... and tr exists as '/usr/bin/tr' as well as '${EPREFIX}/usr/bin/tr' and '${EPREFIX}/bin/tr'. Is this a quoting or subshell issue? Is eix restricting $PATH for security, and removing all paths where 'tr' might exist?
I got that too, but I suspect that's something else, since /usr/bin/tr exists on my system, so if it would be a path problem another error should have been given, like you already concluded. I guess the weird quoting here might be an issue.
