View previous topic :: View next topic |
Author |
Message |
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Wed Oct 22, 2008 5:24 pm Post subject: |
|
|
ok, i understand that. thanks for the explanation.
does emerge catch this situation fully during the upgrade of package A?
i can't remember an output of "emerge -uDNav --with-bdeps 1 @system @world" that showed an forthcoming unmerge. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Wed Oct 22, 2008 6:26 pm Post subject: |
|
|
alex.blackbit wrote: | does emerge catch this situation fully during the upgrade of package A? | Not during the upgrade (-u will never unmerge something), but emerge --depclean does afterwards. |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Wed Oct 22, 2008 8:33 pm Post subject: |
|
|
i am confused again.
since it is necessary to run depclean after upgrading packages either way, why is it a bad idea to use the output of "'UPGRADE_TO_HIGHEST_SLOT=false eix -u" to get information about newer packages? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Oct 23, 2008 9:50 am Post subject: |
|
|
alex.blackbit wrote: | why is it a bad idea to use the output of "'UPGRADE_TO_HIGHEST_SLOT=false eix -u" to get information about newer packages? | It is ok to use it to get information about which packages/versions are available/stable - that's what eix was made for. But it was not made for determining which packages in which versions should be on your system so that all packages behave well: To know this you have to know which packages you want (i.e. the world-file) and their dependencies - which eix completely ignores. The dependency resolver of your package manager (i.e. typically portage) is the only tool for this job and therefore should be used as the (only) reliable source on this question. |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Thu Oct 23, 2008 3:02 pm Post subject: |
|
|
your explanation is understandably, thanks again for taking the time to explain it.
here is a different story: Code: | # update-eix
Reading Portage settings ..
Building database (/var/cache/eix) ..
[0] "gentoo" /usr/portage/ (cache: metadata-flat)
Reading 100%
[1] "blackbit's portage overlay" /usr/portage/local/blackbit (cache: parse|ebuild*)
Reading 100%
[2] "mozilla" /usr/portage/local/layman/mozilla (cache: parse|ebuild*)
Reading 100%
[3] "arcon" /usr/portage/local/layman/arcon (cache: parse|ebuild*)
Reading 60%/usr/portage/local/layman/arcon/net-im/kadu-amarok_mediaplayer/kadu-amarok_mediaplayer-20071220.ebuild: line 3: kde-config: command not found
/usr/portage/local/layman/arcon/net-im/kadu-arts_sound/kadu-arts_sound-0.6.0.ebuild: line 4: artsc-config: command not found
/usr/portage/local/layman/arcon/net-im/kadu-arts_sound/kadu-arts_sound-0.6.0.ebuild: line 5: artsc-config: command not found
/usr/portage/local/layman/arcon/net-im/kadu-dcopexport/kadu-dcopexport-0.11.3.20071129-r2.ebuild: line 3: kde-config: command not found
100%
[4] "sunrise" /usr/portage/local/layman/sunrise (cache: parse|ebuild*)
Reading 100%
Applying masks ..
Calculating hash tables ..
Writing database file /var/cache/eix ..
Database contains 13964 packages in 151 categories.
# |
the executed commands seem to be in back-quotes Code: | % sed '3!d' /usr/portage/local/layman/arcon/net-im/kadu-amarok_mediaplayer/kadu-amarok_mediaplayer-20071220.ebuild
KDEDIR="`kde-config --prefix`"
% sed '4!d' /usr/portage/local/layman/arcon/net-im/kadu-arts_sound/kadu-arts_sound-0.6.0.ebuild
MOD_CXXFLAGS="`artsc-config --cflags`"
% sed '5!d' /usr/portage/local/layman/arcon/net-im/kadu-arts_sound/kadu-arts_sound-0.6.0.ebuild
MOD_LDFLAGS="`artsc-config --libs`"
% sed '3!d' /usr/portage/local/layman/arcon/net-im/kadu-dcopexport/kadu-dcopexport-0.11.3.20071129-r2.ebuild
KDEDIR="`kde-config --prefix`"
% |
is this related to the following ewarn messages? Code: | Security Warning:
Since >=eix-0.12.0, eix uses by default OVERLAY_CACHE_METHOD="parse|ebuild*"
This is rather reliable, but ebuilds may be executed by user "portage". Set
OVERLAY_CACHE_METHOD=parse in /etc/eixrc if you do not trust the ebuilds. |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Oct 23, 2008 4:20 pm Post subject: |
|
|
alex.blackbit wrote: | Code: | kde-config: command not found
artsc-config: command not found |
|
So these ebuild rely even during the depend phase on "kde-config" and "artsc-config" being in PATH which IMHO is a bug in these ebuilds. As a workaround you can use cache method "parse|ebuild" (i.e. ebuild without *); to my surprise, I just observed that portage somehow uses a longer PATH than when ebuild.sh is called directly. |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Sat Oct 25, 2008 11:31 am Post subject: |
|
|
i did what you suggested, mv.
the result, however, is not very joyful. Code: | # update-eix
Reading Portage settings ..
Building database (/var/cache/eix) ..
[0] "gentoo" /usr/portage/ (cache: metadata-flat)
Reading 100%
[1] "blackbit's portage overlay" /usr/portage/local/blackbit (cache: parse|ebuild)
Reading 100%
[2] "mozilla" /usr/portage/local/layman/mozilla (cache: parse|ebuild)
Reading 100%
[3] "arcon" /usr/portage/local/layman/arcon (cache: parse|ebuild)
Reading 0%*** glibc detected *** update-eix: free(): invalid pointer: 0x00000000006cbf78 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f9ca579fb88]
/lib/libc.so.6(cfree+0x76)[0x7f9ca57a1746]
update-eix[0x42f0aa]
update-eix[0x43e113]
update-eix[0x43f1e2]
update-eix[0x426582]
update-eix[0x42777e]
update-eix[0x49c9aa]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f9ca5749486]
update-eix(__gxx_personality_v0+0x1e1)[0x4055b9]
======= Memory map: ========
00400000-004ca000 r-xp 00000000 08:05 29755708 /usr/bin/eix
006ca000-006cb000 r--p 000ca000 08:05 29755708 /usr/bin/eix
006cb000-006cc000 rw-p 000cb000 08:05 29755708 /usr/bin/eix
006cc000-02a78000 rw-p 006cc000 00:00 0 [heap]
7f9ca0000000-7f9ca0021000 rw-p 7f9ca0000000 00:00 0
7f9ca0021000-7f9ca4000000 ---p 7f9ca0021000 00:00 0
7f9ca4ef4000-7f9ca4efe000 r-xp 00000000 08:01 2624770 /lib64/libnss_files-2.8.so
7f9ca4efe000-7f9ca50fe000 ---p 0000a000 08:01 2624770 /lib64/libnss_files-2.8.so
7f9ca50fe000-7f9ca50ff000 r--p 0000a000 08:01 2624770 /lib64/libnss_files-2.8.so
7f9ca50ff000-7f9ca5100000 rw-p 0000b000 08:01 2624770 /lib64/libnss_files-2.8.so
7f9ca5100000-7f9ca510a000 r-xp 00000000 08:01 2624775 /lib64/libnss_nis-2.8.so
7f9ca510a000-7f9ca5309000 ---p 0000a000 08:01 2624775 /lib64/libnss_nis-2.8.so
7f9ca5309000-7f9ca530a000 r--p 00009000 08:01 2624775 /lib64/libnss_nis-2.8.so
7f9ca530a000-7f9ca530b000 rw-p 0000a000 08:01 2624775 /lib64/libnss_nis-2.8.so
7f9ca530b000-7f9ca5320000 r-xp 00000000 08:01 2621665 /lib64/libnsl-2.8.so
7f9ca5320000-7f9ca551f000 ---p 00015000 08:01 2621665 /lib64/libnsl-2.8.so
7f9ca551f000-7f9ca5520000 r--p 00014000 08:01 2621665 /lib64/libnsl-2.8.so
7f9ca5520000-7f9ca5521000 rw-p 00015000 08:01 2621665 /lib64/libnsl-2.8.so
7f9ca5521000-7f9ca5523000 rw-p 7f9ca5521000 00:00 0
7f9ca5523000-7f9ca552a000 r-xp 00000000 08:01 2624777 /lib64/libnss_compat-2.8.so
7f9ca552a000-7f9ca5729000 ---p 00007000 08:01 2624777 /lib64/libnss_compat-2.8.so
7f9ca5729000-7f9ca572a000 r--p 00006000 08:01 2624777 /lib64/libnss_compat-2.8.so
7f9ca572a000-7f9ca572b000 rw-p 00007000 08:01 2624777 /lib64/libnss_compat-2.8.so
7f9ca572b000-7f9ca5876000 r-xp 00000000 08:01 2624761 /lib64/libc-2.8.so
7f9ca5876000-7f9ca5a76000 ---p 0014b000 08:01 2624761 /lib64/libc-2.8.so
7f9ca5a76000-7f9ca5a7a000 r--p 0014b000 08:01 2624761 /lib64/libc-2.8.so
7f9ca5a7a000-7f9ca5a7b000 rw-p 0014f000 08:01 2624761 /lib64/libc-2.8.so
7f9ca5a7b000-7f9ca5a80000 rw-p 7f9ca5a7b000 00:00 0
7f9ca5a80000-7f9ca5a95000 r-xp 00000000 08:01 1586154 /lib64/libgcc_s.so.1
7f9ca5a95000-7f9ca5c94000 ---p 00015000 08:01 1586154 /lib64/libgcc_s.so.1
7f9ca5c94000-7f9ca5c95000 r--p 00014000 08:01 1586154 /lib64/libgcc_s.so.1
7f9ca5c95000-7f9ca5c96000 rw-p 00015000 08:01 1586154 /lib64/libgcc_s.so.1
7f9ca5c96000-7f9ca5d18000 r-xp 00000000 08:01 2621719 /lib64/libm-2.8.so
7f9ca5d18000-7f9ca5f17000 ---p 00082000 08:01 2621719 /lib64/libm-2.8.so
7f9ca5f17000-7f9ca5f18000 r--p 00081000 08:01 2621719 /lib64/libm-2.8.so
7f9ca5f18000-7f9ca5f19000 rw-p 00082000 08:01 2621719 /lib64/libm-2.8.so
7f9ca5f19000-7f9ca6000000 r-xp 00000000 08:05 47240197 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6.0.10
7f9ca6000000-7f9ca6200000 ---p 000e7000 08:05 47240197 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6.0.10
7f9ca6200000-7f9ca6207000 r--p 000e7000 08:05 47240197 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6.0.10
7f9ca6207000-7f9ca6209000 rw-p 000ee000 08:05 47240197 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6.0.10
7f9ca6209000-7f9ca621c000 rw-p 7f9ca6209000 00:00 0
7f9ca621c000-7f9ca622b000 r-xp 00000000 08:01 2624747 /lib64/libbz2.so.1.0.5
7f9ca622b000-7f9ca642a000 ---p 0000f000 08:01 2624747 /lib64/libbz2.so.1.0.5
7f9ca642a000-7f9ca642b000 r--p 0000e000 08:01 2624747 /lib64/libbz2.so.1.0.5
7f9ca642b000-7f9ca642c000 rw-p 0000f000 08:01 2624747 /lib64/libbz2.so.1.0.5
7f9ca642c000-7f9ca6448000 r-xp 00000000 08:01 2624752 /lib64/ld-2.8.so
7f9ca661e000-7f9ca6621000 rw-p 7f9ca661e000 00:00 0
7f9ca6645000-7f9ca6648000 rw-p 7f9ca6645000 00:00 0
7f9ca6648000-7f9ca6649000 r--p 0001c000 08:01 2624752 /lib64/ld-2.8.so
7f9ca6649000-7f9ca664a000 rw-p 0001d000 08:01 2624752 /lib64/ld-2.8.so
7fffae634000-7fffae649000 rw-p 7ffffffea000 00:00 0 [stack]
7fffae7fe000-7fffae7ff000 r-xp 7fffae7fe000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
# |
if i can do anything to trace down the problem, please tell me. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Oct 25, 2008 1:33 pm Post subject: |
|
|
It seems that you are running into a bug which was introduced in eix-0.14.1; in eix-0.14.2 this bugs was fixed. |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Fri Oct 31, 2008 10:05 am Post subject: |
|
|
mv, first i would like to thank you for taking the users wishes in account, even if you don't agree.
since 0.14.2 appeared in the portage tree, i gave the new "bestslotsupgrade" a try.
it did Code: | % UPGRADE_TO_HIGHEST_SLOT=false eix -u --format "<category>"/"<name>"-"<bestslotsupgrade>"
dev-lang/nasm-(~)2.05.01
perl-core/File-Spec-(~)3.29
virtual/perl-File-Spec-(~)3.29
Found 3 matches.
% |
is this how you intended it? so, for use as input to portage this is not usable, because of the "(~)" and the summary line.
or do i use it wrong?
and, while playing around i got this Code: | % eix -u --format "<fullavailabe>"/"<bestslotsupgrade>"
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)4.5
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/3.1!t
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)4.0!t
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)2.3.2
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)2.3.2
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)3.2
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/6.0.18
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)2.05.01
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)2.8.9.1-r1
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/2.5
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)3.0.2
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)3.29
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)2.6.27-r2!b!s
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe'
/(~)3.29
Found 14 matches.
% |
which does not look to me like it should be printed. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Oct 31, 2008 11:02 am Post subject: |
|
|
alex.blackbit wrote: | Code: | --format "<category>"/"<name>"-"<bestslotsupgrade>" |
|
I think what you want is --format "<fullbestslotsupgrade>".
Quote: | Code: | % eix -u --format "<fullavailabe>"/"<bestslotsupgrade>"
std::string get_package_property(const PrintFormat*, const void*, const std::string&): Unknown property 'fullavailabe' |
|
fullavailable |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Fri Oct 31, 2008 12:30 pm Post subject: |
|
|
you are right in both cases, mv. Code: | % UPGRADE_TO_HIGHEST_SLOT=false eix --format "<fullbestslotsupgrade>"
(~)dev-java/junit-4.5
(~)perl-core/File-Spec-3.29
(~)sys-devel/gcc-4.3.2
(~)virtual/perl-File-Spec-3.29
[1] "blackbit" /usr/portage/local/blackbit
Found 4 matches.
% |
the "(~)" is still there, the overlay is not interesting in this situation (non of the 4 packages come from the overlay) and the summary line is also still there. is this intended?
the packages with versions are although correct and what i want. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Fri Oct 31, 2008 5:25 pm Post subject: |
|
|
alex.blackbit wrote: | the "(~)" is still there, the overlay is not interesting in this situation (non of the 4 packages come from the overlay) and the summary line is also still there. is this intended? |
Change of the format is not intended to change the "tail" (overlays and summary) output: Use the option --pure-package to suppress both. Even if your particular format prints information only for some packages, nevertheless all packages are selected (although most produce empty output), and so the overlay information is correct, since it concerns all packages; with option -u you would select only these four packages (but with --pure-packages you won't see the overlays anyway).
Yes, the "(~)" is still there: It could easily be avoided with TAG_FOR_EX_UNSTABLE="", but if <full...> would imply the latter, it could not be brought back by users who want it. But after thinking about it, I cannot imagine a reason why somebody would want it, so it is perhaps reasonable that the next eix version should never output any tags with <full...>. |
|
Back to top |
|
|
cruzki123 Apprentice
Joined: 16 May 2008 Posts: 262
|
Posted: Mon Nov 03, 2008 5:59 pm Post subject: |
|
|
I have a very extrange problem. eix didn't index my layman overlays. This is what I get when I try to do an update-eix.
Code: |
$ sudo update-eix
Reading Portage settings ..
'ailed to source '/usr/local/portage/layman/make.conf
Building database (/var/cache/eix) ..
[0] "gentoo" /usr/portage/ (cache: metadata-flat)
Reading 100%
[1] "local-overlay" /usr/local/portage/overlay (cache: parse|ebuild*)
Reading 100%
Applying masks ..
Calculating hash tables ..
Writing database file /var/cache/eix ..
Database contains 13078 packages in 150 categories.
|
I already try to unmerge and delete al my eix and layman config files, but nothing helps. Any idea?
Code: |
$ ls -l /usr/local/portage/layman/make.conf
-rw-r--r-- 1 root root 110 nov 3 17:33 /usr/local/portage/layman/make.conf
$ cat /usr/local/portage/layman/make.conf
PORTDIR_OVERLAY="
/usr/local/portage/layman/java-overlay
/usr/local/portage/layman/science
$PORTDIR_OVERLAY
"
|
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon Nov 03, 2008 6:41 pm Post subject: |
|
|
cruzki123 wrote: | Code: | 'ailed to source '/usr/local/portage/layman/make.conf |
|
Does it really look like this, i.e. the ' symbol is at the beginning of the line? In this case, I guess that the last symbol of the name is \r (i.e. a line feed). If you have written Code: | source /usr/local/portage/layman/make.conf |
in /etc/make.conf this may happen if /etc/make.conf obeys the DOS convention for lineends instead of the unix convention.
Edit: Current eix svn trunk (>=eix-0.14.3) is also able to parse files with DOS convention properly, i.e. you need not convert your /etc/make.conf if you use that version. |
|
Back to top |
|
|
cruzki123 Apprentice
Joined: 16 May 2008 Posts: 262
|
Posted: Mon Nov 03, 2008 8:48 pm Post subject: |
|
|
Thanks for the tip
Using dos2unix to make.conf resolve my problem |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Mon Nov 03, 2008 9:05 pm Post subject: |
|
|
mv, for me the feature request is now fully filled.
i now have the alias Code: | alias updates='TAG_FOR_EX_UNSTABLE=\"\" UPGRADE_TO_HIGHEST_SLOT=false eix --pure-packages --format \"<fullbestslotupgrade>\"' |
which gives me exactly the output i was looking for. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Tue Nov 04, 2008 8:21 am Post subject: |
|
|
alex.blackbit wrote: | Code: | alias updates='TAG_FOR_EX_UNSTABLE=\"\" UPGRADE_TO_HIGHEST_SLOT=false eix --pure-packages --format \"<fullbestslotupgrade>\"' |
which gives me exactly the output i was looking for. |
It might still break for e.g. manually unmasked (in contrast to stabilized) packages, i.e. you might need to set more TAG_FOR... variables to "". With current eix svn trunk (>=eix-0.14.3) you will not need to set these variables.
Moreover, if you use <=fullbestslotupgrade> or <=emptybestslotupgrade> (in >=eix-0.14.3) you can use the output directly for emerge. |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Fri Nov 07, 2008 11:12 pm Post subject: |
|
|
i just tried version 0.15.0. Code: | # UPGRADE_TO_HIGHEST_SLOT=false eix --pure-packages --format "<=fullbestslotupgrade>"
=app-admin/gkrellm:2-2.3.2
=app-text/acroread-8.1.3
=dev-libs/libgcrypt-1.4.3-r1
=dev-libs/libgweather-2.24.1
=dev-libs/libksba-1.0.4
=dev-libs/libtasn1-1.5
=dev-texlive/texlive-context-2008-r1
=dev-texlive/texlive-latex-2008-r1
=dev-texlive/texlive-latexextra-2008-r1
=dev-texlive/texlive-latexrecommended-2008-r2
=dev-texlive/texlive-pictures-2008-r1
=dev-texlive/texlive-pstricks-2008-r1
=gnome-extra/yelp-2.24.0-r10
=media-libs/libtheora-1.0
=media-libs/openal-1.5.304
=media-video/vlc-0.9.6
=net-libs/gnutls-2.6.0
=net-misc/dhcpcd-4.0.4
=sys-apps/hdparm-9.3
=sys-boot/grub-0.97-r8
=sys-fs/device-mapper-1.02.28
=x11-libs/libpciaccess-0.10.5
# |
in this case app-admin/gkrellm seems to be the only package that is slotted. here the output seems to be wrong.
wv, what do you think?
although, this seems to be usable: Code: | # UPGRADE_TO_HIGHEST_SLOT=false eix --pure-packages --format "<=emptybestslotupgrade>"
app-admin/gkrellm:2
app-text/acroread
dev-libs/libgcrypt
dev-libs/libgweather
dev-libs/libksba
dev-libs/libtasn1
dev-texlive/texlive-context
dev-texlive/texlive-latex
dev-texlive/texlive-latexextra
dev-texlive/texlive-latexrecommended
dev-texlive/texlive-pictures
dev-texlive/texlive-pstricks
gnome-extra/yelp
media-libs/libtheora
media-libs/openal
media-video/vlc
net-libs/gnutls
net-misc/dhcpcd
sys-apps/hdparm
sys-boot/grub
sys-fs/device-mapper
x11-libs/libpciaccess
# |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Nov 08, 2008 5:46 am Post subject: |
|
|
alex.blackbit wrote: | in this case app-admin/gkrellm seems to be the only package that is slotted. |
The output is not restricted to versions which have more than one slot: Every version has at least the trivial slot. Use option --slotted or --slots (i.e. -1 or -2) if you want to restrict the output to versions with a nontrivial slot / more than one slot.
Oh... now I see what you mean: Portage only accepts the confusing opposite order =app-admin/gkrellm-2.3.2:2. You are right. This should be changed in eix. For the moment, the best solution is probably to use PRINT_SLOTS=false.
Edit: Actually, the change already is in svn trunk. For those who cannot wait for 0.15.1: Here is a patch to change order |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Sat Nov 08, 2008 10:51 am Post subject: |
|
|
thanks for the fix, mv.
in such a case, is it useful to output the full version AND the slot? i think i will stick with PRINT_SLOTS=false. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sun Nov 09, 2008 6:05 am Post subject: |
|
|
alex.blackbit wrote: | in such a case, is it useful to output the full version AND the slot? |
It depends on the purpose: If you want to use the output for e.g. /etc/portage/package.mask and perhaps later change "=" to ">=", then the slot added is probably what you want.
Quote: | i think i will stick with PRINT_SLOTS=false. |
That's why it is there Since this option exists, I think it makes no sense to introduce further forms of empty.../=empty.../full.../=full.. - all these possibilities are somewhat hackish anyway. |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Sat Nov 29, 2008 12:41 am Post subject: |
|
|
with "OVERLAY_CACHE_METHOD='parse|ebuild'" i am experiencing the following: Code: | * Running update-eix
Reading Portage settings ..
Building database (/var/cache/eix) ..
[0] "gentoo" /usr/portage/ (cache: metadata-flat)
Reading 100%
[1] "mozilla" /usr/portage/local/layman/mozilla (cache: parse|ebuild)
Reading 61%/usr/lib64/portage/bin/ebuild.sh: line 2061: 9: Bad file descriptor
Ebuild failed with status 1
Reading 61%
Tempfile /var/cache/edb/dep/aux_db_key_temp is not a file
Reading 61%
Could not properly execute /usr/portage/local/layman/mozilla/net-libs/xulrunner/xulrunner-1.9.1_beta1-r1.ebuild
Reading 100%
[2] "sunrise" /usr/portage/local/layman/sunrise (cache: parse|ebuild)
Reading 100%
[3] "blackbit's portage overlay" /usr/portage/local/blackbit (cache: parse|ebuild)
Reading 100%
Applying masks ..
Calculating hash tables ..
Writing database file /var/cache/eix ..
Database contains 13657 packages in 151 categories. |
with standard settings (parse|ebuild*) everything is fine.
here is the xulrunner ebuild: Code: | # Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-libs/xulrunner/xulrunner-1.9.0.1.ebuild,v 1.4 2008/07/30 10:42:58 armin76 Exp $
WANT_AUTOCONF="2.1"
inherit flag-o-matic toolchain-funcs eutils mozconfig-3 makeedit multilib java-pkg-opt-2 python autotools
PATCH="${P}-patches-0.1"
MY_PV="${PV/_beta/b}"
MY_PV="${MY_PV/1.9/3}"
DESCRIPTION="Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications"
HOMEPAGE="http://developer.mozilla.org/en/docs/XULRunner"
SRC_URI="http://releases.mozilla.org/pub/mozilla.org/firefox/releases/${MY_PV}/source/firefox-${MY_PV}-source.tar.bz2"
# mirror://gentoo/${PATCH}.tar.bz2"
KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86"
SLOT="1.9"
LICENSE="|| ( MPL-1.1 GPL-2 LGPL-2.1 )"
IUSE=""
RDEPEND="java? ( >=virtual/jre-1.4 )
>=sys-devel/binutils-2.16.1
>=dev-libs/nss-3.12
>=dev-libs/nspr-4.7.1
media-libs/alsa-lib"
DEPEND="java? ( >=virtual/jdk-1.4 )
${RDEPEND}
dev-util/pkgconfig"
S="${WORKDIR}/mozilla-central"
# Needed by src_compile() and src_install().
# Would do in pkg_setup but that loses the export attribute, they
# become pure shell variables.
export MOZ_CO_PROJECT=xulrunner
export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
pkg_setup(){
if ! built_with_use x11-libs/cairo X; then
eerror "Cairo is not built with X useflag."
eerror "Please add 'X' to your USE flags, and re-emerge cairo."
die "Cairo needs X"
fi
if ! built_with_use --missing true x11-libs/pango X; then
eerror "Pango is not built with X useflag."
eerror "Please add 'X' to your USE flags, and re-emerge pango."
die "Pango needs X"
fi
java-pkg-opt-2_pkg_setup
}
src_unpack() {
unpack ${A}
# Apply our patches
cd "${S}" || die "cd failed"
EPATCH_SUFFIX="patch" \
EPATCH_FORCE="yes" \
epatch "${FILESDIR}"/${PV}
eautoreconf || die "failed running eautoreconf"
# We need to re-patch this because autoreconf overwrites it
# epatch "${FILESDIR}"/patch/000_flex-configure-LANG.patch
}
src_compile() {
declare MOZILLA_FIVE_HOME="/usr/$(get_libdir)/${PN}-1.9"
####################################
#
# mozconfig, CFLAGS and CXXFLAGS setup
#
####################################
mozconfig_init
mozconfig_config
mozconfig_annotate '' --enable-extensions="${MEXTENSIONS}"
mozconfig_annotate '' --disable-mailnews
mozconfig_annotate 'broken' --disable-mochitest
mozconfig_annotate 'broken' --disable-crashreporter
# mozconfig_annotate '' --enable-system-hunspell
#mozconfig_annotate '' --enable-system-sqlite
mozconfig_annotate '' --enable-image-encoder=all
mozconfig_annotate '' --enable-canvas
#mozconfig_annotate '' --enable-js-binary
mozconfig_annotate '' --enable-embedding-tests
mozconfig_annotate '' --with-system-nspr
mozconfig_annotate '' --with-system-nss
# mozconfig_annotate '' --enable-system-lcms
mozconfig_annotate '' --with-system-bz2
# Bug 60668: Galeon doesn't build without oji enabled, so enable it
# regardless of java setting.
mozconfig_annotate '' --enable-oji --enable-mathml
mozconfig_annotate 'places' --enable-storage --enable-places --enable-places_bookmarks
mozconfig_annotate '' --enable-safe-browsing
# Other ff-specific settings
mozconfig_annotate '' --enable-jsd
mozconfig_annotate '' --enable-xpctools
mozconfig_annotate '' --disable-libxul
mozconfig_annotate '' --with-default-mozilla-five-home=${MOZILLA_FIVE_HOME}
#disable java
if ! use java ; then
mozconfig_annotate '-java' --disable-javaxpcom
fi
# Finalize and report settings
mozconfig_final
# -fstack-protector breaks us
if gcc-version ge 4 1; then
gcc-specs-ssp && append-flags -fno-stack-protector
else
gcc-specs-ssp && append-flags -fno-stack-protector-all
fi
filter-flags -fstack-protector -fstack-protector-all
####################################
#
# Configure and build
#
####################################
CPPFLAGS="${CPPFLAGS} -DARON_WAS_HERE" \
CC="$(tc-getCC)" CXX="$(tc-getCXX)" LD="$(tc-getLD)" \
econf || die
# It would be great if we could pass these in via CPPFLAGS or CFLAGS prior
# to econf, but the quotes cause configure to fail.
sed -i -e \
's|-DARON_WAS_HERE|-DGENTOO_NSPLUGINS_DIR=\\\"/usr/'"$(get_libdir)"'/nsplugins\\\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\\\"/usr/'"$(get_libdir)"'/nsbrowser/plugins\\\"|' \
"${S}"/config/autoconf.mk \
"${S}"/toolkit/content/buildconfig.html
emake || die "emake failed"
}
src_install() {
declare MOZILLA_FIVE_HOME="/usr/$(get_libdir)/${PN}-1.9"
emake DESTDIR="${D}" install || die "emake install failed"
rm "${D}"/usr/bin/xulrunner
dodir /usr/bin
dosym ${MOZILLA_FIVE_HOME}/xulrunner /usr/bin/xulrunner-1.9
# Add vendor
echo "pref(\"general.useragent.vendor\",\"Gentoo\");" \
>> "${D}"${MOZILLA_FIVE_HOME}/defaults/pref/vendor.js
if use java ; then
java-pkg_dojar "${D}"${MOZILLA_FIVE_HOME}/javaxpcom.jar
rm -f "${D}"${MOZILLA_FIVE_HOME}/javaxpcom.jar
fi
} |
can anything be fixed here? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Nov 29, 2008 8:00 am Post subject: |
|
|
The ebuild alone does not cause any problems here; perhaps the problem lies in an eclass it inherits. Does Code: | /usr/bin/ebuild [path_to_the_ebuild] depend | work? And if yes, what if you call it with a clear environment (prepend env -i in front of the above command)? |
|
Back to top |
|
|
alex.blackbit Advocate
Joined: 26 Jul 2005 Posts: 2397
|
Posted: Sat Nov 29, 2008 10:15 am Post subject: |
|
|
Code: | # ebuild /usr/portage/local/layman/mozilla/net-libs/xulrunner/xulrunner-1.9.1_beta1-r1.ebuild depend
/usr/lib64/portage/bin/ebuild.sh: line 2061: 9: Bad file descriptor
# env -i ebuild /usr/portage/local/layman/mozilla/net-libs/xulrunner/xulrunner-1.9.1_beta1-r1.ebuild depend
/usr/lib64/portage/bin/ebuild.sh: line 2061: 9: Bad file descriptor
# |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Nov 29, 2008 11:04 am Post subject: |
|
|
Now I downloaded the whole mozilla overlay with layman, but still cannot reproduce the problem with portage-2.2_rc16 on amd64.
I would say that it is some bug in portage (either the environment variable dbkeys or file descriptor #9 should have been opened by /usr/bin/ebuild before it calls ebuild.sh, but neither seems to be the case). If my diagnosis is correct, cache method "ebuild" will fail on all ebuilds with your portage version. |
|
Back to top |
|
|
|