in trying to fix a checksum error /w the psycopg ebuild, I moved my portage tree out of the way, and resync'd it from the server: # cd /usr && mv portage old.portage && mkdir portage && emerge sync which runs through downloading the contents of /usr/portage, and then in the section where it updating the portage cache, the system dumps at an unhandled list index error: Number of files: 117879 Number of files transferred: 98187 Total file size: 93357779 bytes Total transferred file size: 93357779 bytes Literal data: 93357779 bytes Matched data: 0 bytes File list size: 2635234 Total bytes sent: 1963889 Total bytes received: 100412363 sent 1963889 bytes received 100412363 bytes 227250.28 bytes/sec total size is 93357779 speedup is 0.91 >>> Updating Portage cache: Traceback (most recent call last): File "/usr/bin/emerge", line 2705, in ? oldcat = portage.catsplit(cp_list[0])[0] IndexError: list index out of range this list assignment appears in a long flat proceedure in the primary namespace in /usr/bin/emerge. I don't know enough about the internals of emerge to say exactly what it's doing, but it appears to be splitting the 0th element in cp_list and asigning the 0th element from that list to 'oldcat'. In the case of rebuilding the portage tree, the index assumptions here are erroneous, and should probably run inside a try/except. Reproducible: Always Steps to Reproduce: 1.mv /usr/portage to /usr/old.portage 2.emerge sync 3.program exits on uncaut exception Actual Results: the emerge sync doesn't finish, although the portage tree does appear to be largely functional. Expected Results: the emerge command should have run through a sync cycle, and finished updating the portage cache. infiltrator usr # emerge info Portage 2.0.51.22-r1 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.11-gentoo-r11 x86_64) ================================================================= System uname: 2.6.11-gentoo-r11 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.12 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.11-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -pipe -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/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="amd64 X aalib acpi adns alsa arts berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl directfb dvd dvdread eds fam flac font-server foomaticdb fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib ipv6 jabber jack java jp2 jpeg junit kde lame ldap libwww lzw lzw-tiff mad maildir mikmod motif mozilla mp3 mpeg ncurses network nls nvidia odbc ogg opengl oss pam pda pdflib perl pic png postgres python qt readline ruby samba sdl slang speex ssl tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales vorbis xine xml xml2 xmms xpm xrandr xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Sounds like an issue with per-category metadata.xml files. What does `ls -f /usr/portage/app-admin/` give you?
[Sat Jun 18 <0:33:49>]\>ls -f /usr/portage/app-admin ./ prelude-lml/ quickswitch/ logrotate/ webmin/ ../ kcmgrunlevel/ setools/ logsentry/ gentoo-rsync-mirror/ apg/ makepasswd/ systemconfigurator/ flexlm/ chrootuid/ cpu/ dirvish/ syslog-ng/ kiosktool/ partgui/ fam/ tripwire/ mailmin/ sysstat/ passook/ fpm/ durep/ zope-config/ whowatch/ paxtest/ gps/ gamin/ modlogan/ verynice/ petrovich/ mbr/ gpsui/ watchfolder/ watchdog/ prelude-manager/ mon/ hpasm/ longrun/ furball/ procinfo/ sud/ jinit/ testdisk/ gkrellm/ profiler/ sus/ kedpm/ rackview/ moodss/ klogview/ xsu/ monit/ killproc/ filewatcher/ pcihpview/ newsyslog/ psmon/ socklog/ gnomesu/ grubconfig/ ide-smart/ pwgen/ metalog/ hddtemp/ apachetop/ ccze/ sdsc-syslog/ eselect/ osiris/ otpcalc/ ctcs/ ulogd/ gentoo-bugger/ showconsole/ fetchlog/ gwcc/ gnome-system-tools/ conserver/ nologin/ livecd-ng/ lcap/ yaala/ grubconf/ ranpwd/ webalizer/ lsat/ pam_dotfile/ perl-cleaner/ scotty/ metadata.xml pydf/ xtail/ genromfs/ sysklogd/ realpath/ skey/ xstow/ bacula/ runset/ bastille/ sudo/ reportmagic/ amanda/ tenshi/ cronolog/ stow/ gtkdiskfree/ analog/ swatch/ chrpath/ sxid/ powertweak/ zprod-manager/ chroot_safe/ system-tools-backends/ xsu2/ ulog-acctd/ diradm/ torsmo/ procman/ pwcrypt/ superadduser/ localepurge/ usbview/ integrit/ addpatches/ tmpreaper/ tmpwatch/ usermin/
Wouldn't be the metadata.xml. I realized that it is sorted anyway... What filesystem is this on? Are you using anything that could possibly cause python to cache stat calls without going back to disk? The only way this seems possible is if the stat information for /usr/portage is not changing.
It's an amd64 box with a serial ATA disk running reiserfs 3.6. The volume is mounted noatime, notail. It is worth noting that I didn't experience this problem in exactly the same situation before the python environment in gentoo was updated to 2.4.1.
Same thing happened here after i rm -r /usr/portage and resynced.
*** Bug 100676 has been marked as a duplicate of this bug. ***
Created attachment 64855 [details] test_cp_all.py Attached is a test case to reproduce the reported error. Simply move your portage tree someplace other than PORTDIR and run this script to verify that len(portage.portdb.cp_all())==0. File "/usr/bin/emerge", line 2705, in ? oldcat = portage.catsplit(cp_list[0])[0] IndexError: list index out of range The length of cp_list is zero which results in the above error. I have traced this back to when portage is first imported and portage.portdb is initalized with portdb=portdbapi(settings["PORTDIR"]). Inside the portage.config constructor, the categories property is initialized from the (empty) portage tree. Since the portage tree is empty during the initial import of portage, the category list used by portage.portdb will remain empty until python exits. The categories are used in portage.portdb.cp_all() to generate the zero length cp_list that is shown in the error message.
Commited a fix to stable cvs...
*** Bug 103849 has been marked as a duplicate of this bug. ***
*** Bug 105860 has been marked as a duplicate of this bug. ***
*** Bug 106864 has been marked as a duplicate of this bug. ***
resolving this forward as a dupe of 100444, since patch attached should address it. *** This bug has been marked as a duplicate of 100444 ***
*** Bug 115830 has been marked as a duplicate of this bug. ***
*** Bug 116596 has been marked as a duplicate of this bug. ***
