Summary: | app-portage/eix: eix-update shows line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect with >=sys-apps/portage-3.0.24 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael <voron1> |
Component: | Current packages | Assignee: | Mikle Kolyada (RETIRED) <zlogene> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andrewammerlaan, brokendreams1981, christian, fedeliallalinea, flaviocamilo, gabemarcano, gem, joakim.tjernlund, jsmolic, leho, linder.gabriel, martin, mgorny, sam, urmet.saar |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=820731 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
full eix-update log
eix-update log test ebuild for eix-0.36 |
Same here. But only on one of my Gentoo hosts. The one that has "guru" and "brother" and "vifino" overlays. "Plain" Gentoo unaffected for me. Created attachment 741801 [details]
eix-update log
eix-update log
I see the first eix-update log fails in the "local" and "rion" overlays. Not on the "gentoo" overlay. So like mine, overlay related. https://github.com/pentoo/pentoo-overlay/blob/master/app-forensics/maltego/maltego-4.2.6.12502.ebuild is probably the simplest ebuild that triggers this for me. A me too, portage-3.0.26: Reading Portage settings... Building database (/var/cache/eix/portage.eix)... [0] "gentoo" /usr/portage (cache: metadata-md5-or-flat) Reading category 172|172 (100) Finished [1] "tmv3-cross-overlay" /var/lib/layman/tmv3-cross-overlay (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 147|172 ( 85): sys-devel.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 147|172 ( 85): sys-devel... cannot properly execute /var/lib/layman/tmv3-cross-overlay/sys-devel/binutils-config/binutils-config-3-r3.ebuild Reading category 172|172 (100) Finished [2] "transmode" /var/lib/layman/transmode (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 4|172 ( 2): app-admin.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 4|172 ( 2): app-admin... cannot properly execute /var/lib/layman/transmode/app-admin/join-domain/join-domain-0.5.ebuild Reading category 23|172 ( 13): app-office.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 23|172 ( 13): app-office... cannot properly execute /var/lib/layman/transmode/app-office/teams-for-linux/teams-for-linux-1.0.10.ebuild Reading category 28|172 ( 16): app-text.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 28|172 ( 16): app-text... cannot properly execute /var/lib/layman/transmode/app-text/discount/discount-2.2.2.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-1.0.0.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/dtc/dtc-20061013.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/dtc/dtc-20070511.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/hardhat/hardhat-1.0.0-r1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/hex2fd/hex2fd-20070717.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/hex2fd/hex2fd-20070829.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/hitech-tools/hitech-tools-1.0.0-r1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/hitech-tools/hitech-tools-1.0.0.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/mpc_mpfr/mpc_mpfr-20130212-r1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/mpc_mpfr/mpc_mpfr-20130212.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/mpc_mpfr/mpc_mpfr-20150330.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/mplabx/mplabx-1.30.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/mplabx/mplabx-3.20.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/powerpc-e300c2/powerpc-e300c2-20101005.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/powerpc-tools/powerpc-tools-20070403-r1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/powerpc-tools/powerpc-tools-20070403.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/powerpc-tools-gcc/powerpc-tools-gcc-20120313-r1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/powerpc-tools-gcc/powerpc-tools-gcc-20120313.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-1.0.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-1.1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-1.2.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-1.3.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-20080118.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-20080211.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/rpd2fd/rpd2fd-20080523.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/tm-hostenv/tm-hostenv-1.0.0.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/tm-hostenv/tm-hostenv-1.0.1.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/tm-hostenv/tm-hostenv-1.1.0.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/xc8/xc8-1.01.ebuild Reading category 39|172 ( 22): dev-embedded.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 39|172 ( 22): dev-embedded... cannot properly execute /var/lib/layman/transmode/dev-embedded/xilinx-ise/xilinx-ise-9.2i-r1.ebuild Reading category 80|172 ( 46): gnome-extra.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 80|172 ( 46): gnome-extra... cannot properly execute /var/lib/layman/transmode/gnome-extra/eiciel/eiciel-0.9.6.1.ebuild Reading category 169|172 ( 98): x11-themes.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 169|172 ( 98): x11-themes... cannot properly execute /var/lib/layman/transmode/x11-themes/clearlooks-phenix/clearlooks-phenix-5.0.7-r1.ebuild Reading category 169|172 ( 98): x11-themes.../usr/lib/portage/python3.8/ebuild.sh: line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect ebuild failed with status 1 Reading category 169|172 ( 98): x11-themes... cannot properly execute /var/lib/layman/transmode/x11-themes/clearlooks-phenix/clearlooks-phenix-6.0.3.ebuild Reading category 172|172 (100) Finished Applying masks... Calculating hash tables... Writing database file /var/cache/eix/portage.eix... Database contains 19565 packages in 172 categories Same problem here. i can also confirm this. seems to be happening on all overlays. My guess would be that eix used deep Portage internals that have been deprecated for almost 10 years and were removed as part of modernizing the internal metadata transfer. I am currently busy in RL. My guess is that with the new portage version some new environment variable must be set when called ebuild.sh. Until I find time to look at it, please use as fallback the cache method ebuild instead of ebuild* (which is much slower but more reliable). (I have currently no time to look up which variable you have to tweak - look at eix --dump for ebuild*). Or even better generate metadata for your overlays by portage (as is recommended anyway - see Section SPEEDUP in man eix). I planned to deprecate cache method ebuild* many years ago, but since it always worked so far or was easy to fix, I had no reason for it. Let us see how hard it is to fix this time. The issue indeed went away after setting up chache generation as per SPEEDUP section in man eix. (In reply to Michał Górny from comment #8) > My guess would be that eix used deep Portage internals that have been > deprecated for almost 10 years and were removed as part of modernizing the > internal metadata transfer. this is my assumption too. it seemed to happen after the move from auxdbkeys to metadata_keys. according to my brief research it appears ambiguous redirects can also be caused when certain variables arent encased in quotation marks. im still no closer to figuring out where exactly the problem is though. (In reply to jeremy mills from comment #11) > > this is my assumption too. it seemed to happen after the move from auxdbkeys > to metadata_keys. The reason is clear to me now: If the variable "dbkey" was set, ebuild.sh would output its result in that file for <=sys-apps/portage-3.0.23. With >=sys-apps/portage-3.0.24, ebuild.sh only outputs into a filedescriptor with number taken from the variable "PORTAGE_PIPE_FD". This is ugly to solve from C++ if I do not want to rewrite the whole execution logic by setting up a pipe. An easier workaround would be to call a wrapper script which honors dbkey. Not clear yet whether/how I want to solve this. The problem seems relatively easy to fix. I realized now that the workaorund "ebuild" (instead of "ebuild*") which I suggested does not work, either. And this seems harder to fix: ebuild <path-to-ebuild> depend is no longer supported... Don't forget that the data format changed too. (In reply to Martin Väth from comment #13) > The problem seems relatively easy to fix. > > I realized now that the workaorund "ebuild" (instead of "ebuild*") which I > suggested does not work, either. And this seems harder to fix: > > ebuild <path-to-ebuild> depend > > is no longer supported... i noticed that about "ebuild" it was causing some failing on some eclasses in the main repo. "parse" and "parse*" seem to work ok though at least for now. eix-0.36.0 with the fix is now relased. Note that you have to set now EBUILD_PORTAGE3_0_24=true (which is default) if and only if you use >=portage-3.0.24. This is because of: (In reply to Michał Górny from comment #14) > Don't forget that the data format changed too. The alternative would have been to use a heuristics for "guessing" the format which somehow sounds wrong. Moreover, unfortunately, the new release will factically deprecate cache method ebuild (by making it act like ebuild* if EBUILD_PORTAGE3_0_24 is true): Since ebuild ... depend is apparently no longer semi-officially supported, it does not make sense to create some hack to make it work anyway; it seems then cleaner to only use ebuild.sh directly (the former was cache method ebuild, the latter cache method ebuild*). Unfortunately, this means that eix now is forced to stay closer to the internals of portage than I'd like. (In reply to Martin Väth from comment #16) > The alternative would have been to use a heuristics for "guessing" the > format which somehow sounds wrong. It should actually be quite trivial and reliable. In the key=value format, every line must contain a "=", so you can just choose one line (IUSE? EAPI?) that couldn't contain a "=" in the old format and check for that. (In reply to Michał Górny from comment #17) > (In reply to Martin Väth from comment #16) > > The alternative would have been to use a heuristics for "guessing" the > > format which somehow sounds wrong. > > It should actually be quite trivial and reliable [...] just choose one line (IUSE? EAPI?) that couldn't contain a "=" in the old format. I had thought about exactly this approach, but it is somehow wrong (e.g., although unlikely, there is no guarantee that there will never be some = in an EAPI, and it requires duplicate reading. Moreover, something is needed anyway to deprecate the ebuild method for new portage. I think the configuration variable is the best approach. For a moment, I thought about making the default value of that variable configurable through a new ./configure option, but I guess that portage will be stabilized before the new eix anyway. Moreover, nothing bad will happen if this is not the case: eix will lack some data if users install the new eix before portage and without reading anything. And this will fix itself with the portage upgrade. (In reply to Martin Väth from comment #18) > (In reply to Michał Górny from comment #17) > > (In reply to Martin Väth from comment #16) > > > The alternative would have been to use a heuristics for "guessing" the > > > format which somehow sounds wrong. > > > > It should actually be quite trivial and reliable [...] just choose one line (IUSE? EAPI?) that couldn't contain a "=" in the old format. > > I had thought about exactly this approach, but it is somehow wrong (e.g., > although unlikely, there is no guarantee that there will never be some = in > an EAPI, and it requires duplicate reading. Moreover, something is needed > anyway to deprecate the ebuild method for new portage. I think the > configuration variable is the best approach. > See https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-240003.1.8. = is not a valid character for an EAPI. (In reply to Martin Väth from comment #16) > eix-0.36.0 with the fix is now relased. Could we have it in Gentoo too? Created attachment 742545 [details]
test ebuild for eix-0.36
(In reply to Joakim Tjernlund from comment #20) > (In reply to Martin Väth from comment #16) > > eix-0.36.0 with the fix is now relased. > > Could we have it in Gentoo too? drop the attached ebuild in a local overlay and give it a test. its also available in the mv overlay. It's in ::gentoo since https://gitweb.gentoo.org/repo/gentoo.git/commit/app-portage/eix?id=ebca16f9869ceb1ac8bb489c7eff29fcbe590dcd. Same here for me, all packages in "wine" overlay only *** Bug 820737 has been marked as a duplicate of this bug. *** (In reply to Phazeus from comment #24) > Same here for me, all packages in "wine" overlay only Please emerge —-sync and update eix. |
Created attachment 741750 [details] full eix-update log With >=sys-apps/portage-3.0.24 any consecutive eix-update shows line 778: ${PORTAGE_PIPE_FD}: ambiguous redirect Full log attached. Particularly cross-avr/gdb is a symlink to the in-tree ebuild, so there can't be anything wrong with the ebuild itself I don't think.