Bug 104305 – gawk-3.1.3-r2 and gawk-3.1.4-r4 ebuilds break on unpack

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Chris Fairles 2005-08-30 14:50:44 UTC]

emerge -e system in chrooted environment, comes to gawk 

>>> Unpacking source...
>>> Unpacking gawk-3.1.4.tar.gz to /var/tmp/portage/gawk-3.1.4-r4/work
cp: target `/var/tmp/portage/gawk-3.1.4-r4/work/filefuncs/' is not a directory:
No such file or directory
!!! ERROR: sys-apps/gawk-3.1.4-r4 failed.
!!! Function src_unpack, Line 30, Exitcode 1
!!! cp failed
!!! If you need support, post the topmost build error, NOT this status message.

offending line in ebuild (both versions)
cp -pPR "${FILESDIR}"/filefuncs "${SFFS}"/ || die "cp failed"

note the trailing slash on "${SFFS}"/  <--- i'm not too sure, but i think this
expects the dir to be there, since its not created in src_unpack, breaks build. 



Reproducible: Always
Steps to Reproduce:
1.chroot /mnt/gentoo /bin/bash
2.emerge -e system
3.wait for gawk to come around

Actual Results:  
build breaks on src_unpack

Expected Results:  
filefunc's dir should unpack to .../work/filefunc

Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1,
2.6.12-gentoo-r6 i686)
=================================================================
System uname: 2.6.12-gentoo-r6 i686
Gentoo Base System version 1.12.0_pre6
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5, 2.4.1-r1
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.16.1
sys-devel/libtool:   [Not Present]
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /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/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo
http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gentoo
http://mirrors.acm.cs.rpi.edu/gentoo/ ftp://gentoo.risq.qc.ca"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X a52 aac acpi alsa apache2 apm arts avi bash-completion berkdb
bitmap-fonts browserplugin crypt cscope cups divx4linux dvd dvdr emacs emboss
encode ffmpeg fftw firefox flac foomaticdb fortran ftp gdbm gif ginac glx gnome
gpm gstreamer gtk gtk2 imlib javascript jpeg libg++ libwww mad mikmod mjpeg mmx
mmx2 motif mp3 mpeg msn ncurses netboot nis nntp nptl nsplugin nvidia ogg
oggvorbis opengl oss pam pcmcia pdflib perl png posix python qt quicktime
readline real sdl smp spell sse sse2 ssl tcpd threads truetype truetype-fonts
type1-fonts v4l v4l2 vcd verbose vorbis wifi win32codecs wxwindows xml2 xmms xv
xvid zlib userland_GNU kernel_linux elibc_glibc"Unset:  ASFLAGS, CTARGET, LANG,
LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS

[Comment 1 Chris Fairles 2005-08-30 14:52:04 UTC]

Created attachment 67297 [details, diff]
gawk-3.1.3-r2 ebuild patch

removes trailing / so src_unpack properly unpacks.

[Comment 2 Chris Fairles 2005-08-30 14:53:20 UTC]

Created attachment 67298 [details, diff]
gawk-3.1.4-r4 ebuild patch

remove trailing / so src_unpack unpacks without error

[Comment 3 Chris Fairles 2005-08-30 15:06:17 UTC]

odd things happen, if someone would care in explain.
In my chrooted environemnt:

dsotm ~ # mkdir test1
dsotm ~ # cp -R test1/ test2
dsotm ~ # ls
test1  test2
dsotm ~ # rm -rf test2
dsotm ~ # cp -R test1/ test2/
cp: target `test2/' is not a directory: No such file or directory

normal environement cp -R test1/ test2/ gives no error and creates dir.

[Comment 4 Chris Fairles 2005-08-30 15:15:13 UTC]

ok looking into this further ... I have ~x86 accept keyword which takes in
coreutils version 5.3.0 

I'm guessing cp behaves differently between 5.3.0 (~x86) and 5.2.1-r6 (latest
stable). If not I'm still clueless.

[Comment 5 SpanKY 2005-08-31 10:26:59 UTC]

no, the dir is not supposed to exist ahead of time

coreutils-5.2.1-r6 behaves just fine with your example as does 5.3.0-r1 ...

[Comment 6 SpanKY 2005-08-31 23:18:19 UTC]

seems it's a new feature in coreutils-5.3.0 ... dropped the trailing / ...

[Comment 7 SpanKY 2005-09-01 22:00:27 UTC]

*** Bug 104537 has been marked as a duplicate of this bug. ***

[Comment 8 Jakub Moc (RETIRED) 2005-09-01 23:53:56 UTC]

*** Bug 104552 has been marked as a duplicate of this bug. ***