# emerge sun-jdk >>> emerge (14 of 26) dev-java/sun-jdk-1.4.2 to / >>> Unpacking source... tail: +507: No such file or directory ACCESS DENIED open_wr: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin ./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin: Permission denied ./install.sfx: line 2: syntax error near unexpected token `)' $aKsj2sdk1.4.2/include/jvmpi.hUT)
# emerge sun-jdk >>> emerge (14 of 26) dev-java/sun-jdk-1.4.2 to / >>> Unpacking source... tail: +507: No such file or directory ACCESS DENIED open_wr: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin ./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin: Permission denied ./install.sfx: line 2: syntax error near unexpected token `)' $aKsj2sdk1.4.2/include/jvmpi.hUT)Ôò>UxPÉÔ.âüÀÄ'V?t@]·? !!! ERROR: dev-java/sun-jdk-1.4.2 failed. !!! Function src_unpack, Line 39, Exitcode 2 !!! (no error message) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-sun-jdk-1.4.2-21048.log" open_wr: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin -------------------------------------------------------------------------------- The usage of "tail +507" in this ebuild is not POSIX conform and fails with current coreutils (5.0-r1). I suggest fixing it to "tail -n 507". The -n option works also with older tail versions. This will fix the sandbox violation. Note that this affects all sun-jdk versions.
It might be that 'tail +507' is not POSIX conform. But 'tail +507 foo' means something different than 'tail -n 507 foo'. Explanation follows: 'tail +507 foo' means: take the tail of the file "foo", skipping the first 507 lines. 'tail -n 507 foo' means: take the the last 507 lines of file "foo". So unless you have a conforming way of doing things, which also does what it's suppose to. We better stick with what works ;)
You can't stick with tail +507 because it doesn't work. But how about 'tail -n +507'? I forgot the '+' in my last comment ;-) tail -n +507 was tested by me and works.
I need more information to check this, like the output of emerge info, which is the output of qpkg -f /bin/tail ?? Also, i would like to point that this ebuild has been tested a lot, we've been using tail +xxx since JDK version 1.3.
Okay, here the requested information: # emerge --info Portage 2.0.49 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r3, 2.6.0-test3-mm2) ================================================================= System uname: 2.6.0-test3-mm2 i686 AMD Athlon(tm) XP 1800+ ccache version 2.2 [enabled] ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox fixpackages" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/opt/portage /opt/portage-gnome" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 oss apm avi encode foomaticdb libg++ mikmod mpeg ncurses nls pdflib quicktime spell xmms xv gdbm berkdb slang readline arts tetex tcltk java sdl gpm libwww perl python imlib qt kde motif cdr 3dnow alsa crypt cups dvd gif -gnome gtk gtk2 imap ipv6 jpeg lcms mad maildir mmx mozilla mule oggvorbis opengl pam png sasl sse ssl -svga tcpd threads tiff truetype X xml2 zlib esd" # qpkg -f -v /bin/tail sys-apps/coreutils-5.0-r1 * # /usr/bin/tail --version tail (coreutils) 5.0 Written by Paul Rubin, David MacKenzie, Ian Lance Taylor, and Jim Meyering. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # /usr/bin/tail +507 /dev/null /usr/bin/tail: +507: No such file or directory ==> /dev/null <== As you can see with the version of tail from the coreutils, the '-n' is required and cannot be omitted like with older tail versions. Without '-n' tails interprets +507 as a file name. The 'tail +xxx' which is used since JDK version 1.3 worked fine until Gentoo switched to coreutils, which was recently.
This bug is a special case of bug #23116 which is about the general head/tail problem with the coreutils. Maybe it should be taged as a duplicate, I am not sure.
Just for the records, the new sun-jdk-1.4.2.01.ebuild is broken too, and thus cannot be installed. My proposed fix for this one: - tail +${startAt} ${DISTDIR}/${At} > install.sfx + tail -n +${startAt} ${DISTDIR}/${At} > install.sfx
I will close it as WORKSFORME since i have: sirius# /usr/bin/tail --version tail (coreutils) 5.0 sirius # qpkg -f -v /bin/tail sys-apps/coreutils-5.0-r1 * Tested with FEATURES="sandbox" and FEATURES="-sandbox" Also your error shows: ACCESS DENIED open_wr: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin ./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin: Permission You have the correct permissions on that file ? Reopen if it still happens
If the error cause would be a permission problem my fix woudn't work, would it? No, permissions have nothing to do with it. It's the tail call in the ebuild which errors out and which causes the java-installer to be unexecutable. I updated coreutils in the meantime to coreutils-5.0-r2 and after that to coreutils-5.0-r3 and still have the error. # emerge sun-jdk Calculating dependencies ...done! >>> emerge (1 of 1) dev-java/sun-jdk-1.4.2.01 to / >>> md5 src_uri ;-) j2sdk-1_4_2_01-linux-i586.bin >>> Unpacking source... tail: +473: No such file or directory ACCESS DENIED open_wr: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin ./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin: Permission denied
If the error cause would be a permission problem my fix woudn't work, would it? No, permissions have nothing to do with it. It's the tail call in the ebuild which errors out and which causes the java-installer to be unexecutable. I updated coreutils in the meantime to coreutils-5.0-r2 and after that to coreutils-5.0-r3 and still have the error. # emerge sun-jdk Calculating dependencies ...done! >>> emerge (1 of 1) dev-java/sun-jdk-1.4.2.01 to / >>> md5 src_uri ;-) j2sdk-1_4_2_01-linux-i586.bin >>> Unpacking source... tail: +473: No such file or directory ACCESS DENIED open_wr: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin ./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin: Permission denied íA-sj2sdk1.4.2_01/include/UT B?UxP: No such file or directory ./install.sfx: line 2: r/IzÄ: No such file or directory íAäNsj2sdk1.4.2_01/include/linux/UT B?UxP: No such file or directory $3Osj2sdk1.4.2_01/include/linux/jni_md.hUTØB?UxP: No such file or directory : No such file or directory $§Psj2sdk1.4.2_01/include/linux/jawt_md.hUTØB?UxP: No such file or directory $nsj2sdk1.4.2_01/include/jvmpi.hUTØB?UxP: No such file or directory $Ssj2sdk1.4.2_01/include/jvmdi.hUTØB?UxP: No such file or directory ./install.sfx: line 3: r/âüÀÄ: No such file or directory $▒j2sdk1.4.2_01/README.htmlUTØB?UxP'near unexpected token `{? $ssj2sdk1.4.2_01/src.zipUTÔB?UxP&r/ù0¥ÌO/I:P~-Ó¯ $▒j2sdk1.4.2_01/README.htmlUTØB?UxP&r/Ö&kÄ_ $O▒j2sdk1.4.2_01/THIRDPARTYLICENSEREADME.txtUTØB?UxPK' !!! ERROR: dev-java/sun-jdk-1.4.2.01 failed. !!! Function src_unpack, Line 50, Exitcode 2 !!! (no error message) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-sun-jdk-1.4.2.01-20725.log" open_wr: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin -------------------------------------------------------------------------------- I wonder why it works for you. Maybe it has something to do with gcc-3.3.1 (I use currently gcc-3.3.1-r1). In gcc's Changelog I see that they have now a coreutils patch included to fix "broken tail calls". But even recompiling coreutils with this patched gcc did'nt change anything for me. But I am not sure if this has to do anything with this issue at all. I mean patching gcc to fix broken tail calls? Common! I would fix the broken calls... But anyway, as nobody is able to confirm this error, ignore it. I won't reopen it unless I find at least one more person who expierience the same. Thanks for your time.
Just a small remark: In dev-lang/ocaml George Shapovalov just fixed a similar broken tail call (although it did'nt break for him): *ocaml-3.06-r2 (09 Sep 2003) 09 Sep 2003; George Shapovalov <george@gentoo.org> ocaml-3.06-r2.ebuild, metadata.xml : ocaml was using uotdated "head -1" construct throughout. Changed this to "head -n 1", see #27835 for details. Maybe a Gentoo-wide policy is in order: Is 'tail XXX' outdated or not? Right now it's outdated in some packages and not so in other packages. ;-)
