The following error oucured during the installation. ecompressdir: bzip2 -9 opt/x86-chroot/usr/share/man /usr/lib64/portage/bin/ecompress: line 51: /bin/rm: Die Argumentliste ist zu lang <- to many arguments Reproducible: Always Steps to Reproduce: 1.Just install x86-chroot
please be more verbose in how you encountered this problem during a normal installation, there would be no "/opt/x86-chroot" visible from inside the chroot
The error happened during the installation of the package "app-emulation/x86-chroot-2006.1". During this installation there is nothing chrooted yet. /opt/x86-chroot is the default installation location. It looks just like this: emerge --oneshot x86-chroot Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-emulation/x86-chroot-2006.1 to / * stage3-i686-2006.1.tar.bz2 MD5 ;-) ... [ ok ] * stage3-i686-2006.1.tar.bz2 RMD160 ;-) ... [ ok ] * stage3-i686-2006.1.tar.bz2 SHA1 ;-) ... [ ok ] * stage3-i686-2006.1.tar.bz2 SHA256 ;-) ... [ ok ] * stage3-i686-2006.1.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking stage3-i686-2006.1.tar.bz2 ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.22-gentoo-r6/build * Found sources for kernel version: * 2.6.22-gentoo-r6 * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking stage3-i686-2006.1.tar.bz2 to /var/tmp/portage/app-emulation/x86-chroot-2006.1/work/opt/x86-chroot >>> Source unpacked. >>> Compiling source in /var/tmp/portage/app-emulation/x86-chroot-2006.1 ... >>> Source compiled. >>> Test phase [not enabled]: app-emulation/x86-chroot-2006.1 >>> Install x86-chroot-2006.1 into /var/tmp/portage/app-emulation/x86-chroot-2006.1/image/ category app-emulation >>> Completed installing x86-chroot-2006.1 into /var/tmp/portage/app-emulation/x86-chroot-2006.1/image/ ecompressdir: bzip2 -9 opt/x86-chroot/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man ecompressdir: bzip2 -9 opt/x86-chroot/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man ecompressdir: bzip2 -9 opt/x86-chroot/usr/share/man /usr/lib64/portage/bin/ecompress: line 51: /bin/rm: Die Argumentliste ist zu lang I dont know where ecompress is started, therefor i cannot write a patch myself.
The problem is inside ecompressdir on this line: find "${dir}" -type f ${negate} -iname '*'${suffix} -print0 | ${XARGS} -0 ${binary} With all of the man pages in the chroot, the argument list is simply too long. Here is an example of a more scalable approach that unfortunately requires ${binary} to be executed once for each and every file: find "${dir}" -type f ${negate} -iname '*'${suffix} -print0 | \ while read -d $'\0' file ; do ${binary} "${file}" ; done
err, no ... the error is line 51 in *ecompress*, not ecompressdir that's the point of chaining to xargs ... so the cmdline limit is not a problem
So, the extremely long argument line isn't a problem until we get to this line inside ecompress: [[ -n ${suffix} ]] && rm -f "${@/%/${suffix}}" Here's a solution that uses built-in stat calls to avoid invoking rm too many times unnecessarily: if [[ -n ${suffix} ]] ; then for x in "${@}" ; do [[ -e ${x}${suffix} ]] && rm "${x}{suffix}" done fi
Created attachment 132009 [details, diff] fall back to using a bash loop with xargs just when the arg list is too long In most cases, this patch will perform just as good as the original method. It will only fall back to a slightly slower method when the arg list is too long.
what's wrong with the solution we came up with on irc with `tr` ? echo ${@/%/${suffix}$'\001'} | tr '\001' '\000' | xargs -0 rm -f
(In reply to comment #7) > what's wrong with the solution we came up with on irc with `tr` ? > echo -n "${@/%/${suffix}$'\001'}" | tr '\001' '\000' | ${XARGS} -0 rm -f This has been released in 2.1.3.10.
