<snip> >>> Install cvs-1.11.11 into /var/tmp/portage/cvs-1.11.11/image/ category dev-util * Adding group 'cvs' to your system ... * - Groupid: next available groupadd: group cvs exists !!! ERROR: dev-util/cvs-1.11.11 failed. !!! Function enewgroup, Line 661, Exitcode 9 !!! enewgroup failed -------------------------------------- # emerge info Portage 2.0.49-r18 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20031212-r0, 2.4.23-ck1) ================================================================= System uname: 2.4.23-ck1 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.3.12 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /opt/tomcat/conf /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /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/env.d" CXXFLAGS="-march=i686 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" 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="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb cdr crypt cups emacs encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg libg++ libwww mad mikmod motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png postgres python quicktime readline ruby sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
I found an older bug about this (20490) but it was fixed long ago and doesn't seem to be the culprit here. Can you please emerge --debug cvs and attach the output here ? And do you by any chance know if this only fails in the cvs ebuilds or also in other ebuilds that use enewgroup ? It seems like in the eutils.eclass at the enewgroup() function if [ "${egroup}" == "${realgroup}" ] returns false although it shouldn't (at least if your group file isn't b0rked ;), perhaps the debugging output gives more insight here
This problem seems to happen when there is a duplicate entry in /etc/group: cvs:x:1026: rajiv:x:1026: I am wondering why these eclass group adding commands are violating linux convention by adding accounts for daemons in the user space (1000+)
ok, we currently have two problems then: 1. it fails if there is a duplicate entry (needs to be fixed in the eclass) 2. we don't want to use fixed uids/gids in the ebuild but currently many ebuilds do so. There is currently no way to use a "dynamic" uid within a range of uids (e.g. <1000). This also needs to be fixed in the eclass and a way to specify that in the ebuild afterwards, of course. The problem with the cvs user not being a system user was reported here: http://bugs.gentoo.org/show_bug.cgi?id=36416 But since a) we don't want to use fixed uids/gids and b) currently the eclass doesn't support "ranged" uids those bugs are still open. Spanky is the author of the whole enewuser/enewgroup functions, so I hope he can also express his opinion on that topic :)
In my case this created a duplicate entry for uid 501. userfoo:x:501: cvs:x:501: The workaround was to change the cvs group ID to 502 and re-emerge.
*** Bug 36653 has been marked as a duplicate of this bug. ***
since cvs now uses a fixed uid/gid (350) to not violate conventions this bug is fixed regarding the cvs side of things, but not eclass-wise... I'll close this bug and open a new one so it's easier for people to find a bug related to this problem. It's bug #41657
