emerging gentoo-sources-2.4.28-r8 triggers a bug in kernel-2.eclass,v 1.111: 469 STRICT_COUNT=$((${STRICT_COUNT} + 1)) Because STRICT_COUNT has leading zeroes, bash will interpret this as octal value, so this will fail as soon as STRICT_COUNT is larger than 000007. (00008 is no valid octal number). This fix works for me: 469 STRICT_COUNT=$((${#STRICT_COUNT} + 1)) (i.e. add a # to STRICT_COUNT) Reproducible: Always Steps to Reproduce: 1. make sure you are using kernel-2.eclass 1.111 (1.107 works, 1.110 fails, don't know about 1.108 and 1.109) 2. emerge =gentoo-sources-2.4.28-r8 You should see an error message after unpacking: >>> md5 src_uri ;-) linux-2.4.28.tar.bz2 >>> md5 src_uri ;-) gentoo-sources-2.4.28-r4.tar.bz2 >>> md5 src_uri ;-) ck-sources-2.4.28-CAN-2004-0814.patch >>> Preparing to unpack ... >>> Unpacking source... >>> Unpacking linux-2.4.28.tar.bz2 to /var/tmp/portage/gentoo-sources-2.4.28-r8/work * gentoo-sources-2.4.28-r4.tar.bz2 unpacked /usr/lib/portage/bin/ebuild.sh: line 518: 000008: value too great for base (error token is "000008") >>> Test phase [not enabled]: sys-kernel/gentoo-sources-2.4.28-r8 The Problem is that emerge will finish _SUCCESSFULLY_ but the patches will not be applied. Actual Results: kernel sources will be emerged, but no patch will be applied. Expected Results: Either apply the gentoo kernel patchset correctly _OR_ die. Installing unpatched sources is not acceptable. Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 Mobile Intel(R) Celeron(TM) CPU 1333MHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 21 2005, 00:13:14)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.2.3-r5, 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O2 -pipe -fstack-protector" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe -fstack-protector" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms userpriv" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/" LANG="C" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.ask.fh-furtwangen.de/gentoo-portage/" USE="x86 X aalib acpi alsa bitmap-fonts cdr crypt cscope curl dvd emboss encode f77 flac font-server foomaticdb fortran gtk gtk2 imap imlib jpeg junit mad mmx mp3 ncurses nptl oggvorbis opengl perl png postgres python readline samba sdl slang spell sse ssl tcltk tetex tiff truetype truetype-fonts type1-fonts userlocales xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
*** Bug 84597 has been marked as a duplicate of this bug. ***
Created attachment 53265 [details, diff] force STRICT_COUNT computation to base 10. This fixes the "value too great for base" problem. However, patches will now be applied in the correct order, and at least gentoo-sources-2.4.28-r8 breaks (gentoo-sources-2.4.vma.patch will not apply and emerge dies). It looks to me as if the "older" kernel-2.eclass applies patches in a different order than the one specified in the ebuild, and at least the gentoo-sources-2.4.28-r8 depends on the 'wrong order' behaviour.
I confirm this behaviour: patching eclass leads to: >>> Unpacking linux-2.4.28.tar.bz2 to /var/tmp/portage/gentoo-sources-2.4.28-r8/work * gentoo-sources-2.4.28-r4.tar.bz2 unpacked * Applying 01-01.3.5-useraddress.patch (-p0+)... [ ok ] * Applying 01-02.lckbase-2.4.28_rc3.patch (-p0+)... [ ok ] * Applying 01-03.readlatency.patch (-p0+)... [ ok ] * Applying 01-04.ecc-20030225.patch (-p0+)... [ ok ] * Applying 01-05.OpenSWAN-2.1.4+natt.patch (-p0+)... [ ok ] * Applying 01-06.bootsplash-3.0.7.patch (-p0+)... [ ok ] * Applying 02-01.deviceMapper-1.00.17.patch (-p0+)... [ ok ] * Applying 02-02.superMount.1.2.11a.patch (-p0+)... [ ok ] * Applying 03-01.linux-ntfs-2.1.6b.patch (-p0+)... [ ok ] * Applying 03-02.squashfs-1.3r3.patch (-p0+)... [ ok ] * Applying 04-01.GRSecurity-2.0.2.patch (-p0+)... [ ok ] * Applying 04-02.cryptoloop-jari-2.4.22.0.patch (-p0+)... [ ok ] * Applying 04-03.GCC-optimizations.patch (-p0+)... [ ok ] * Applying 04-04.speakup-20040313.patch (-p0+)... [ ok ] * Applying 04-05.GentooBootsplashLogos.patch (-p0+)... [ ok ] * Applying 08-01.OpenSWAN-CompileFix.patch (-p0+)... [ ok ] * Applying ck-sources-2.4.28-CAN-2004-0814.patch (-p0+)... [ ok ] * Applying gentoo-sources-2.4.cmdlineLeak.patch (-p0+)... [ ok ] * Applying gentoo-sources-2.4.vma.patch (-p0+)... [ !! ] * Please attach /var/tmp/portage/gentoo-sources-2.4.28-r8/temp/gentoo-sources-2.4.vma.err to any bug you may post. !!! ERROR: sys-kernel/gentoo-sources-2.4.28-r8 failed. !!! Function unipatch, Line 585, Exitcode 0 !!! Unable to dry-run patch. !!! If you need support, post the topmost build error, NOT this status message. As there is in portage tree only gentoo-sources-2.4.28-r8.ebuild, ther is no working gentoo-sources-2.4.28-r? release
fixed in cvs.
