=eix-0.26.3 no write usable db only shows Overlays, not the portage Tree Reproducible: Always Steps to Reproduce: 1.emerge =app-portage/eix-0.26.3 2.try eix-update 3.show eix -e portage Actual Results: eix -e portage No matches found. Expected Results: eix should shows Packages from the portage Tree
Created attachment 322036 [details] emerge --info
works fine here, not sure what the problem could be from given info.
(In reply to comment #0) > =eix-0.26.3 no write usable db > only shows Overlays, not the portage Tree > > Reproducible: Always > > Steps to Reproduce: > 1.emerge =app-portage/eix-0.26.3 > 2.try eix-update > 3.show eix -e portage > Actual Results: > eix -e portage > No matches found. > > Expected Results: > eix should shows Packages from the portage Tree Issue is present here. Referting to app-portage/eix-0.25.5 resolves the issue.
(In reply to comment #2) > works fine here, not sure what the problem could be from given info. Sorry, I'm not sure what it is exactly Problem is with emerge -pvq eix [ebuild R ] app-portage/eix-0.26.3 USE="dep nls optimization sqlite zsh-completion -clang -debug -doc -security -strong-optimization -tools" LINGUAS="de -ru" after eix-update or eix-sync eix only show information from Overlays, and not from the gentoo Repository Workaround for me is, i pick up the old dead eix-0.26.1.ebuild from sources.gentoo.org in me local-Overlay, merge it and try eix-update - this works fine.
I'm not sure if I have the same bug since overlay isn't really picked up by eix, but I have noticed that a similar bug (0.26.3 update-eix wrecks the /var/cache/eix database, I'm not sure if it's the same bug or if it should be reported as something else) occurs only on my ~x86 machines (the two I have. The ~amd64 one is unaffected). Based on what I can gather as well, 0.26.3 eix works fine until eix-update (directly or through eix-sync) is run the first time on version 0.26.3. It seems like the reporter's machine is also x86 (i686). Can someone confirm that this only affects the x86 architecture, or at least i686 machines? Also, I ran eix (the actual program, outputting just 240 packages it "finds") version 0.26.3 on one of my i686 machines and it noticed the following (I'll only post a snip from the whole output): [D] xfce-base/xfce4-settings Available versions: (~)4.9.5 {{debug libcanberra libnotify +xklavier}} Installed versions: 4.10.0(09:31:36 PM 04/29/2012) (libnotify xklavier -debug -libcanberra) Homepage: http://www.xfce.org/projects/ Description: Configuration system for the Xfce desktop environment Notice how it thinks that the newer package is a downgrade. I don't know if this has a bearing on the problem, but just in case.
I can confirm that =app-portage/eix-0.26.3 works very well on ~amd64, but on ~x86 it doesn't work. Last working version of eix on ~x86 is 0.26.1. Maybe We can try to find commit which breaks eix for ~x86 users?
Thanks for reporting. Now I can reproduce the issue: I had -D_FILE_OFFSET_BITS=64 in my CXXFLAGS when testing, therefore it did not occur to me. So you can add this to CXXFLAGS as a temporary workaround. This is not a proper fix, of course. Maybe I can fix it on the weekend, but my time is short, currently.
same issue here after bisecting it, i'm sure it is the first commit after 0.26.1 (2976409d41f84015b8502d8cc4e1ba8ad365317a aka "Rewrite to pass Google's cpplint.py (up to some whitespace conventions)") of course this doesn't help very much, since this commit is quite big :(
I found the issue: autotools defines _FILE_OFFSET_BITS=64 in config.h, and his has effect on the dirent structure. So config.h must be either included everywhere or nowhere, since otherwise things will randomly break. I will fix this when I find the time.
Yes, i can confirm that =app-portage/eix-0.26.3 on me ~x86 (i686) System with CXXFLAGS="${CFLAGS} -D_FILE_OFFSET_BITS=64" compiled works fine. Thank you
Can't this bad #define impact more ebuilds than eix? This is a really bad side effect...
By the way, no problems on ~amd64
Same problem on ARM ! # eix-update Reading Portage settings .. Building database (/var/cache/eix/portage.eix) .. [0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat) Reading category 158|158 (100%) Finished [1] "local" /usr/local/portage/overlay (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 158|158 (100%) EMPTY! [2] "pd-overlay" /var/lib/layman/pd-overlay (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 158|158 (100%) Finished [3] "proaudio" /var/lib/layman/pro-audio (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 158|158 (100%) Finished Applying masks .. Calculating hash tables .. Writing database file /var/cache/eix/portage.eix .. Database contains 461 packages in 158 categories.
The issue should be fixed in eix' gut master on BerliOS (>=eix-0.26.4). I will release it during weekend if no further problems are reported. > Can't this bad #define impact more ebuilds than eix? This #define is not bad, it is even requested by eix (the loss of resources is negligible, and there is no reason to make artifial restrictions). The problem is that eix did not handle config.h as it apparently should: include it even in files which do not obviously use it. It is pure accident that this did not lead to problems earlier on other architectures (where more delicate things than just _FILE_OFFSET_BITS can be defined in config.h).
+*eix-0.26.4 (27 Aug 2012) + + 27 Aug 2012; Jeremy Olexa <darkside@gentoo.org> -eix-0.26.3.ebuild, + +eix-0.26.4.ebuild: + Version bump, fixes Gentoo bugs 432122, 432238, 432478
