Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 46377 - emerge fails when source is fetched by cvs
Summary: emerge fails when source is fetched by cvs
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-31 10:17 UTC by José Romildo Malaquias
Modified: 2004-04-12 19:42 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description José Romildo Malaquias 2004-03-31 10:17:06 UTC
I cannot emerge some packages whose source are fetched through cvs. It is always failing.

For instance:

# emerge -uv irssi-cvs
Calculating dependencies ...done!
>>> emerge (1 of 1) net-irc/irssi-cvs-0.2 to /
>>> Unpacking source...
 * Fetching CVS module irssi into /usr/portage/distfiles/cvs-src/irssi-cvs...
 * Running  cvs -q -f -z4 -d ":pserver:anonymous:@cvs.irssi.org:/home/cvs" loginLogging in to :pserver:anonymous@cvs.irssi.org:2401/home/cvs
Unknown host cvs.irssi.org.
 
!!! ERROR: net-irc/irssi-cvs-0.2 failed.
!!! Function cvs_fetch, Line 323, Exitcode 1
!!! cvs login command failed

# emerge -uv emacs-cvs
Calculating dependencies ...done!
>>> emerge (1 of 1) app-editors/emacs-cvs-21.3.50 to /
>>> Unpacking source...
 * Fetching CVS module emacs into /usr/portage/distfiles/cvs-src...
 * Running  cvs -q -f -z4 -d ":ext:anoncvs@savannah.gnu.org:/cvsroot/emacs" checkout  emacs
cvs_sshwrapper: savannah.gnu.org: Temporary failure in name resolution
cvs [checkout aborted]: end of file from server (consult above messages if any)
 
!!! ERROR: app-editors/emacs-cvs-21.3.50 failed.
!!! Function cvs_fetch, Line 421, Exitcode 1
!!! cvs checkout command failed
 
# emerge -uvO giftui-cvs
Calculating dependencies ...done!
>>> emerge (1 of 1) net-p2p/giftui-cvs-0.0.1 to /
>>> Unpacking source...
 * Fetching CVS module giFTui into /usr/portage/distfiles/cvs-src...
 * Running  cvs -q -f -z4 -d ":pserver:anonymous:@cvs.tuxfamily.org:/cvsroot/giftui" login
Logging in to :pserver:anonymous@cvs.tuxfamily.org:2401/cvsroot/giftui
Unknown host cvs.tuxfamily.org.
 
!!! ERROR: net-p2p/giftui-cvs-0.0.1 failed.
!!! Function cvs_fetch, Line 323, Exitcode 1
!!! cvs login command failed

# epm -q cvs portage
cvs-1.11.14
portage-2.0.50-r1


When run manually, cvs does work:

# cvs -q -f -z4 -d ":pserver:anonymous:@cvs.irssi.org:/home/cvs" login
Logging in to :pserver:anonymous@cvs.irssi.org:2401/home/cvs

# cvs -q -f -z4 -d ":pserver:anonymous:@cvs.irssi.org:/home/cvs" checkout irssi
cvs server: warning: cannot write to history file /home/cvs/CVSROOT/history: Permission denied
U irssi/.cvsignore
U irssi/AUTHORS
U irssi/COPYING
[...]

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Gentoo Base System version 1.4.3.13p1
Portage 2.0.50-r1 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.2-r9,
2.4.26_pre6-gentoo)
=================================================================
System uname: 2.4.26_pre6-gentoo i686 AMD Athlon(tm) XP 2000+
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref
/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="-march=athlon-xp -O2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs buildpkg ccache sandbox strict userpriv usersandbox"
GENTOO_MIRRORS="http://gentoo.oregonstate.edu
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X Xaw3d aalib acl acpi alsa apm arts avi berkdb bonobo cdr crypt cups
encode esd faad fbcon ffmpeg flac foomaticdb gdbm gif glut gnome gpm gtk gtk2
gtkhtml guile imap imlib java javascript jpeg kde libg++ libwww lirc mad mbox
md5sum mikmod mmx motif mozilla mpeg ncurses nls nntp oggvorbis opengl oss pam
pdflib perl png python qt quicktime readline rplay samba sdl slang spell sse ssl
stroke svga tcltk tcpd tetex tiff truetype x86 xml2 xmms xosd xv xvid zlib"
Comment 1 José Romildo Malaquias 2004-04-02 12:19:54 UTC
When invoked by emerge, cvs is failing with an unknown host message. If I replace the name of the cvs server in the ebuild by its IP adress (found with the help of ping or the hostx program), emerge succeeds.

So the question now is: why cvs can resolve the cvs server name when called in the command line, but fail to do so when called by emerge?
Comment 2 José Romildo Malaquias 2004-04-02 12:30:02 UTC
The program noip2 from the package net-dns/noip-updater-2.0.15 is failling to resolve dynupdate.no-ip.com, although "hostx dynupdate.no-ip.com" and "ping dynupdate.no-ip.com" succeeds, as described in bug #41608.

Maybe the issues are related.
Comment 3 SpanKY gentoo-dev 2004-04-05 22:37:26 UTC
*** Bug 45426 has been marked as a duplicate of this bug. ***
Comment 4 SpanKY gentoo-dev 2004-04-05 22:37:40 UTC
*** Bug 46879 has been marked as a duplicate of this bug. ***
Comment 5 SpanKY gentoo-dev 2004-04-05 23:16:32 UTC
coredumb: any ideas if this is a portage or cvs.eclass break ?
Comment 6 Stephane Loeuillet 2004-04-06 00:39:41 UTC
it's a portage break

it works when going back to portage 2.0.50-r1 (no more in portage tree) but still using actual cvs.eclass unmodified
Comment 7 Scott Taylor (RETIRED) gentoo-dev 2004-04-06 01:11:19 UTC
portage -r1 works, -r3 doesn't. repeatable. This suggests sandbox.

side-by-side strace -e trace=file without sandbox on left, with sandbox on
right. These are the moments surrounding cvs within ebuild dying.

Hopefully this will survive the cut-n-paste. The play-by-play as it appears to me:
chdir to kismet/kismet-devel/libpcap-2002.12.23 is attempted in both situations.
ENOENT is returned (directory doesn't exist). Side without sandbox performs
three mkdir commands in order to create the directory that didn't exist, life is
good. Sandbox side never lets these mkdir calls reach the system. CVS update fails.

unlink("CVS/Entries.Static")      = -1 ENOENT (No such file o   unlink("CVS/Entries.Static")      = -1 ENOENT (No such file o
access("CVS/Entries.Log", F_OK)   = -1 ENOENT (No such file o   access("CVS/Entries.Log", F_OK)   = -1 ENOENT (No such file o
chdir("/usr/portage/distfiles/cvs-src") = 0                     chdir("/usr/portage/distfiles/cvs-src") = 0
chdir("kismet/kismet-devel/libpcap-2002.12.23") = -1 ENOENT (   chdir("kismet/kismet-devel/libpcap-2002.12.23") = -1 ENOENT (
mkdir("kismet", 0777)             = -1 EEXIST (File exists)   | getcwd("/usr/portage/distfiles/cvs-src", 8192) = 31
mkdir("kismet/kismet-devel", 0777) = -1 EEXIST (File exists)  | lstat64("/usr/portage/distfiles/cvs-src", {st_mode=S_IFDIR|S_
mkdir("kismet/kismet-devel/libpcap-2002.12.23", 0777) = 0     | lstat64("/usr/portage/distfiles/cvs-src/kismet", {st_mode=S_I
access("kismet/kismet-devel/libpcap-2002.12.23/CVS", F_OK) =  | access("kismet/CVS", F_OK)        = 0
mkdir("kismet/kismet-devel/libpcap-2002.12.23/CVS", 0777) = 0 <
open("kismet/kismet-devel/libpcap-2002.12.23/CVS/Root", O_RDW <
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0        <
open("kismet/kismet-devel/libpcap-2002.12.23/CVS/Repository", <
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0        <
open("kismet/kismet-devel/libpcap-2002.12.23/CVS/Entries", O_ <
Comment 8 Scott Taylor (RETIRED) gentoo-dev 2004-04-06 02:13:57 UTC
Ok, here's some really verbose logs by adding -t to the cvs command... 

/usr/portage/distfiles/cvs-src *is* being added to the "addwrite" call.
The thing that jumps out at me is it doesn't seem to have trouble until it starts
getting to directories that have a period in them. Could the "." be getting 
rejected by sandbox's mkdir check?

#emerge kismet-cvs
(stuff deleted)
S-> Create_Admin (libpcap-2002.12.23, kismet/kismet-devel/libpcap-2002.12.23, /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23, , , 0, 0)
S-> unlink_file(libpcap-2002.12.23/CVS/Tag)
 -> unlink_file(CVS/Tag)
 -> ParseInfo(/home/dragorn/cvs/CVSROOT/rcsinfo, kismet/kismet-devel/libpcap-2002.12.23, ALL)
S<- Create_Admin
S-> unlink_file(libpcap-2002.12.23/CVS/Entries.Static)
 -> unlink_file(CVS/Entries.Static)
S-> unlink_file(CVS/Tag)
 -> unlink_file(CVS/Tag)
S-> Create_Admin (SUNOS4, kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, , , 0, 0)
S-> unlink_file(SUNOS4/CVS/Tag)
 -> Create_Admin (., ., /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, , , 0, 1, 1)
 -> unlink_file(./CVS/Tag)
 <- Create_Admin
 -> unlink_file(CVS/Tag)
 -> rename(CVS/Entries.Backup,CVS/Entries)
 -> unlink_file(CVS/Entries.Log)
 -> ParseInfo(/home/dragorn/cvs/CVSROOT/rcsinfo, kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, ALL)
S<- Create_Admin
S-> unlink_file(SUNOS4/CVS/Entries.Static)
 -> unlink_file(CVS/Entries.Static)
S-> unlink_file(CVS/Tag)
 -> unlink_file(CVS/Tag)
S-> rename(CVS/Entries.Backup,CVS/Entries)
S-> unlink_file(CVS/Entries.Log)
S-> Create_Admin (Win32, kismet/kismet-devel/libpcap-2002.12.23/Win32, /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/Win32, , , 0, 0)
S-> unlink_file(Win32/CVS/Tag)
cvs update: warning: server is not creating directories one at a time
 -> Create_Admin (kismet, kismet, /home/dragorn/cvs/kismet, , , 0, 0, 1)
cvs [update aborted]: there is a version in kismet already
 -> Lock_Cleanup()

!!! ERROR: net-wireless/kismet-cvs-2004.03.28 failed.
!!! Function cvs_fetch, Line 327, Exitcode 1
!!! cvs update command failed

#mkdir /usr/portage/distfiles/cvs-src/kismet/kismet-devel/libpcap-2002.12.23/Win32
#emerge kismet-cvs
(stuff deleted)
S-> unlink_file(libpcap-2002.12.23/CVS/Entries.Static)
 -> unlink_file(CVS/Entries.Static)
S-> unlink_file(CVS/Tag)
 -> unlink_file(CVS/Tag)
S-> Create_Admin (SUNOS4, kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, , , 0, 0)
S-> unlink_file(SUNOS4/CVS/Tag)
 -> unlink_file(CVS/Tag)
 -> ParseInfo(/home/dragorn/cvs/CVSROOT/rcsinfo, kismet/kismet-devel/libpcap-2002.12.23/SUNOS4, ALL)
S<- Create_Admin
S-> unlink_file(SUNOS4/CVS/Entries.Static)
 -> unlink_file(CVS/Entries.Static)
S-> unlink_file(CVS/Tag)
 -> unlink_file(CVS/Tag)
S-> rename(CVS/Entries.Backup,CVS/Entries)
S-> unlink_file(CVS/Entries.Log)
S-> Create_Admin (Win32, kismet/kismet-devel/libpcap-2002.12.23/Win32, /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/Win32, , , 0, 0)
S-> unlink_file(Win32/CVS/Tag)
 -> Create_Admin (., ., /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/Win32, , , 0, 1, 1)
 -> unlink_file(./CVS/Tag)
 <- Create_Admin
 -> unlink_file(CVS/Tag)
 -> rename(CVS/Entries.Backup,CVS/Entries)
 -> unlink_file(CVS/Entries.Log)
 -> ParseInfo(/home/dragorn/cvs/CVSROOT/rcsinfo, kismet/kismet-devel/libpcap-2002.12.23/Win32, ALL)
S<- Create_Admin
S-> unlink_file(Win32/CVS/Entries.Static)
 -> unlink_file(CVS/Entries.Static)
S-> unlink_file(CVS/Tag)
 -> unlink_file(CVS/Tag)
S-> Create_Admin (Include, kismet/kismet-devel/libpcap-2002.12.23/Win32/Include, /home/dragorn/cvs/kismet/kismet-devel/libpcap-2002.12.23/Win32/Include, , , 0, 0)
S-> unlink_file(Include/CVS/Tag)
cvs update: warning: server is not creating directories one at a time
 -> Create_Admin (kismet, kismet, /home/dragorn/cvs/kismet, , , 0, 0, 1)
cvs [update aborted]: there is a version in kismet already
 -> Lock_Cleanup()

!!! ERROR: net-wireless/kismet-cvs-2004.03.28 failed.
!!! Function cvs_fetch, Line 327, Exitcode 1
!!! cvs update command failed

Comment 9 José Romildo Malaquias 2004-04-06 05:56:20 UTC
As the reporter of this bug, I am afraid that it is not the same as bugs #45426 and #46879. The problem I originally describe here seems to be related to domain name resolution, if you look closer at it. It also happens with portage-2.0.50-r1.
Comment 10 Greg Diebel 2004-04-11 21:55:29 UTC
This bug has been resolved with portage-2.0.50-r5.
Comment 11 Nicholas Jones (RETIRED) gentoo-dev 2004-04-12 15:20:00 UTC
Fixed