It's difficult to explain, but. After doing sudo eix-sync -- I have a feeling that deps cache corrupts, because when I try to emerge smth after that, I check dependencies VERY VERY long -- I never wait for it. And htop (or just top) shows that it's checking very strange dependencies (i.e. trying to emerge ut2003 it's checking kde deps!) And the solution! rm -r /var/cache/edb/dep/ emerge --metadata After that deps are checking quickly. I'm not the specialist so ask for details. localhost edb # eix eix [D] app-portage/eix Available versions: 0.7.9 0.8.8 ~0.9.1 Installed versions: 0.9.1(09:03:13 04.03.2007)(sqlite) [I] sys-apps/portage Available versions: 2.0.51.22-r3 2.1.1-r2 2.1.2.2 ~2.1.2.3 Installed versions: 2.1.2.2(17:35:11 18.03.2007)(-build doc -elibc_FreeBSD elibc_glibc -elibc_uclibc -epydoc -linguas_pl -selinux -userland_Darwin userland_GNU) Reproducible: Always
I forgot to add that I use sqlite for portage (as http://gentoo-wiki.com/TIP_speed_up_portage_with_sqlite )
does the same happen with emerge --sync? You can have a look at the eix-sync scrypt. It basically just does that.
Does eix-sync show (among others) the steps * Removing old portage-cache in /var/cache/edb/dep * Running emerge --metadata? If yes, does the problem re-occur after you try your solution and then run sudo update-eix?
(In reply to comment #2) > does the same happen with emerge --sync? You can have a look at the eix-sync > scrypt. It basically just does that. > It's strange but emerge --sync works fine.
(In reply to comment #2) > does the same happen with emerge --sync? You can have a look at the eix-sync > scrypt. It basically just does that. > It's strange but emerge --sync works fine.(In reply to comment #3) > Does eix-sync show (among others) the steps > * Removing old portage-cache in /var/cache/edb/dep > * Running emerge --metadata? > > If yes, does the problem re-occur after you try your solution and then run > sudo update-eix? > The first two steps are not shown. Here is eix-sync.log: Reading Portage settings .. 2 Building database (/var/cache/eix) .. 3 [0] /usr/portage/ (cache: metadata) 4 Reading ... 5 [1] /usr/portage/local/layman/xeffects (cache: none) 6 Reading ... 7 Applying masks .. 8 Database contains 11594 packages in 149 categories.
> The first two steps are not shown. It is very strange that the first step is not shown. > Here is eix-sync.log: This is also strange - the log should contains also at least all output of emerge --sync. It seems to me that you are either implicitly using an obsoleted version of eix-sync or have set some strange defaults for the options: "type -a eix-sync" should show only one entry (/usr/bin/eix-sync). Do you have perhaps created an /etc/eix-sync.conf file? Does eix-sync -ir produce a different output (showing the first step about deleting /var/cache/edb/dep). Anyway, I would like to know whether "update-eix" alone re-creates your cache curruption problem - this would be a very serious issue.
I'm sorry, that was running under crontab so the output was a little bit suppressed. There's an output: * Removing old portage-cache in /var/cache/edb/dep ... * Running emerge --sync ... * Copying old /var/cache/eix cache to /var/cache/eix.previous ... * Running update-eix ... The configuration must be ok, because I did nothing with it. And eix-sync is the only file. The experiment depicted that: 1) eix-sync -- problem occures 2) emerge --metadata -- problem disappears 3) update-eix -- (!!!) no problems again! 4) deleting /var/cache/edb/dep && update-eix -- problem appears!!!
(In reply to comment #7) > * Removing old portage-cache in /var/cache/edb/dep ... > * Running emerge --sync ... > * Copying old /var/cache/eix cache to /var/cache/eix.previous ... > * Running update-eix ... So that is exactly what eix-sync does. Since you say that running update-eix is not the cause and copying the old eix-cache can hardly damage anything, you should be able to produce the problem alone with rm -r /var/cache/edb/dep/* && emerge --sync. Normally, the latter should implicitly call emerge --metadata at the end. Maybe you have disabled this, i.e. maybe you have FEATURES='-metadata-transfer' in your /etc/make.conf (or in the environment) or you do *not* have FEATURES='metadata-transfer' in your /etc/make.globals? This is not admissible with cache method sqlite.
It had to be the first thing to do. mudiller@localhost ~ $ emerge --info Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 Mobile AMD Sempron(tm) Processor 3000+ Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 07 Apr 2007 21:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=k8 -mtune=k8 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=k8 -mtune=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache confcache digest distlocks metadata-transfer prelink sandbox sfperms strict" GENTOO_MIRRORS="ftp://194.85.81.190/Gentoo" LANG="ru_RU.UTF-8" LC_ALL="" LINGUAS="ru en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/xeffects" SYNC="rsync://194.85.81.190/gentoo-portage" USE="3dnow 3dnowext 7zip X aac aalib acpi aiglx alsa apache2 arts berkdb bitmap-fonts bluetooth cairo cdr cli cracklib crypt cups dbus dedicated dga dri dvb dvd dvdr eds emboss encode esd fam firefox flac fortran gdbm gif gpm gtk hal iconv ipv6 irda isdnlog java jpeg kde kdehiddenvisibility ldap libcaca libg++ lirc mad madwifi midi mikmod mmx mmxext mp3 mpeg mplayer mysql ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre pdf perl physfs png ppds pppd python qt3 qt4 quicktime readline reflection reiserfs samba sdl session slang spell spl sse sse2 ssl symlink tcpd tiff truetype truetype-fonts type1-fonts unicode utf8 vim vlm vorbis wifi win32codecs x86 xml xorg xv xvid zlib" ALSA_CARDS="atiixp" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="ru en" USERLAND="GNU" VIDEO_CARDS="fglrx radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #8) > (In reply to comment #7) > > * Removing old portage-cache in /var/cache/edb/dep ... > > * Running emerge --sync ... > > * Copying old /var/cache/eix cache to /var/cache/eix.previous ... > > * Running update-eix ... > > So that is exactly what eix-sync does. Since you say that running update-eix is > not the cause and copying the old eix-cache can hardly damage anything, you > should be able to produce the problem alone with rm -r /var/cache/edb/dep/* && > emerge --sync. Normally, the latter should implicitly call emerge --metadata at !!! emerge --sync works well, because it really calls emerge --metadata in the end. But! Maybe I had written it not so brightly, because update-eix works badly! It doesn't corrupt anything if /var/cache... is already created, BUT it fails to create it if it is NOT created! > 4) deleting /var/cache/edb/dep && update-eix -- problem appears!!!
(In reply to comment #10) > > > * Removing old portage-cache in /var/cache/edb/dep ... > > > * Running emerge --sync ... > !!! emerge --sync works well, because it really calls emerge --metadata in > the end. And it really works well even after deleting /var/cache/edb/dep? And after that update-eix does not damage anything either? Then I have no idea where your problem might come from, because eix-sync does nothing else than executing these three steps: As I understand, if you execute the three steps (deleteing /var/cache/edb/dep, emerge --sync, update-eix) manually in this order, there is no problem, but if you let eix-sync do the same there is a problem. But eix-sync really shows everything it does. I really cannot help here... > 4) deleting /var/cache/edb/dep && update-eix -- problem appears!!! This is clear and not a bug: update-eix should only modify the eix cache and not the portage cache. So you cannot expect that portage's cache is recreated by update-eix - actually update-eix might even give you a warning and produces an empty cache in this case, because there is no (portage) sqlite-cachefile from which it can successfully read. [I had asked about update-eix, because it is impossible to open the sqlite database in readonly-mode: Hence, I cannot claim for sure that update-eix will *never* modify portage's cache (although update-eix only tries to read data and so no modification should happen unless update-eix has a serious bug). But since you have written that the problem does not occur when you run update-eix alone (with a working portage cache, e.g. after emerge --metadata), there is probably no such bug in update-eix.] So summerizing: I have really no idea what might go wrong, since none of the three executed commands seems to be the cause.
we need more of your info to solve this
It could be my mistake. I don't encounter with it anymore. Maybe I deleted dependencies and I didn't create it again (see my comment N7). I hope, it can be closed (or WRONG, or something like this)
