[gentoo-user] Re: revdep-rebuild problem

2009-04-05 Thread ABCD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John P. Burkett wrote:
 Doing revdep-rebuild on an amd64 machine, I received a response
 the included the following lines:
 * All prepared. Starting rebuild
 emerge --oneshot  app-text/xpdf:0
 gnome-base/gnome-panel:0
 kde-base/kdegraphics:3.5
 mail-client/-MERGING-evolution:2.0
 media-plugins/gst-plugins-faad:0.8
 media-plugins/xmms-alsa:0
 media-plugins/xmms-vorbis:0
 media-video/totem:0
 ..
 Calculating dependencies... done!
 emerge: there are no ebuilds to satisfy
 mail-client/-MERGING-evolution:2.0.
 
 After doing emerge -C evolution, I redid revdep-rebuild but got the same
 response. After doing emerge evolution, I again redid revdep-rebuild,
 with the same results.
 
 Suggestions for how to successfully run revdep-rebuild would be most
 welcome.  I'm willing to sacrifice evolution if that would help.
 

A directory named $(portageq vdb_path)/*/-MERGING-* (where $(portageq
vdb_path) is usually /var/db/pkg) is created when portage is installing
a new version of a package/a new package.  It is then moved to the same
name without the -MERGING- part after the old version (if any) is
removed.  The only way that that directory would be able to exist in
normal usage is if either 1) you are in the middle of a merge, or 2)
emerge suddenly quit in the middle of an operation.  Usually, when I've
had this happen, and didn't catch it right away, I would `emerge -C
package`, then mv /var/db/pkg/cat/-MERGING-pkg-ver
/var/db/pkg/cat/pkg-ver, then `emerge -C package` again, to ensure a
clean system.  Then all that would remain is `emerge -1 package` to get
it back on the system.  This might not be the best way to do it, but
I've found it to work.

- --
ABCD
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknYi5sACgkQOypDUo0oQOqFfgCcDOqwbMHbA7oGOuKX0T7Y5nS7
hlcAnA2bnew6N7B6x1X0uzDWXtfgBega
=tYX3
-END PGP SIGNATURE-




Re: [gentoo-user] Re: revdep-rebuild problem

2009-04-05 Thread John P. Burkett
ABCD wrote:
 John P. Burkett wrote:
 Doing revdep-rebuild on an amd64 machine, I received a response
 the included the following lines:
 * All prepared. Starting rebuild
 emerge --oneshot  app-text/xpdf:0
 gnome-base/gnome-panel:0
 kde-base/kdegraphics:3.5
 mail-client/-MERGING-evolution:2.0
 media-plugins/gst-plugins-faad:0.8
 media-plugins/xmms-alsa:0
 media-plugins/xmms-vorbis:0
 media-video/totem:0
 ..
 Calculating dependencies... done!
 emerge: there are no ebuilds to satisfy
 mail-client/-MERGING-evolution:2.0.
 
 After doing emerge -C evolution, I redid revdep-rebuild but got the same
 response. After doing emerge evolution, I again redid revdep-rebuild,
 with the same results.
 
 Suggestions for how to successfully run revdep-rebuild would be most
 welcome.  I'm willing to sacrifice evolution if that would help.
 
 
 A directory named $(portageq vdb_path)/*/-MERGING-* (where $(portageq
 vdb_path) is usually /var/db/pkg) is created when portage is installing
 a new version of a package/a new package.  It is then moved to the same
 name without the -MERGING- part after the old version (if any) is
 removed.  The only way that that directory would be able to exist in
 normal usage is if either 1) you are in the middle of a merge, or 2)
 emerge suddenly quit in the middle of an operation.  Usually, when I've
 had this happen, and didn't catch it right away, I would `emerge -C
 package`, then mv /var/db/pkg/cat/-MERGING-pkg-ver
 /var/db/pkg/cat/pkg-ver, then `emerge -C package` again, to ensure a
 clean system.  Then all that would remain is `emerge -1 package` to get
 it back on the system.  This might not be the best way to do it, but
 I've found it to work.
Your suggestions worked perfectly.  Thank you very much!
-John




Re: [gentoo-user] Re: revdep-rebuild problem with ACCEPT_KEYWORDS=~x86

2006-08-28 Thread Xavier MOGHRABI
Thanks a lot for that information it solved the previous problem.

But now when I launch revdep-rebuild, I got that :
  broken /usr/lib/libsystray4j.so (requires  libkdecore.so.4 libkdeui.so.4)
  broken /usr/lib/openoffice/program/kdebe1.uno.so (requires  libkdecore.so.4 
libkdeui.so.4 libkio.so.4)
  broken /usr/lib/openoffice/program/kdefilepicker (requires  libkdecore.so.4 
libkdeui.so.4 libkio.so.4)
  broken /usr/lib/openoffice/program/libkabdrv1.so (requires  libkabc.so.1 
libkdecore.so.4 libkdeui.so.4)
  broken /usr/lib/openoffice/program/libvclplug_kde680li.so (requires  
libkdecore.so.4 libkdeui.so.4)

It's strange since when all those librairies are well located in the 
directory /usr/kde/3.5/lib/.

Moreover the compilation failed when it tries to compile openoffice-2.0.3

=
Building project solenv
=
deliver -- version: 1.100
LINK: 
build.lst - 
/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/solenv/build.lst
Use of uninitialized value in string eq 
at 
/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/bin/deliver.pl
 
line 793.
LOG: 
writing 
/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/solenv/deliver.log
Statistics:
Files copied: 1
Files unchanged/not matching: 0

=
Building project boost
=
/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/boost

ERROR: Error 11 occurred while 
making 
/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/boost
make: *** [stamp/build] Erreur 1

!!! ERROR: app-office/openoffice-2.0.3 failed.
Call stack:
  ebuild.sh, line 1543:   Called dyn_compile
  ebuild.sh, line 938:   Called src_compile
  openoffice-2.0.3.ebuild, line 252:   Called die

!!! Build failed
!!! If you need support, post the topmost build error, and the call stack if 
relevant.

Regards


Le dimanche 27 août 2006 21:36, Harm Geerts a écrit :
 Note the difference, there are 2 different versions of liblzo.
 net-im/wengophone seems to depend on version 1 but does not enforce this in
 the ebuild, you should report a bug about this. You can install it yourself
 untill this dep is fixed.

 emerge =dev-libs/lzo-1*

 The other broken libs will probably be solved after running revdep-rebuild
 again.

-- 
Xavier MOGHRABI - Consortium ObjectWeb
Jabber: [EMAIL PROTECTED] - Phone: +33 4 76 61 52 35

-- 
gentoo-user@gentoo.org mailing list



[gentoo-user] Re: revdep-rebuild problem with ACCEPT_KEYWORDS=~x86

2006-08-27 Thread Harm Geerts
On Sunday 27 August 2006 20:08, Xavier MOGHRABI wrote:
 dear all,

 I'm using gentoo with the option ACCEPT_KEYWORDS=~x86 in make.conf file.

 For 5 days, I've had some problem when I run revdep-rebuild.
 It seems that I've some librairies missing as the result is :
   broken /usr/bin/qtwengophone (requires  liblzo.so.1)
   broken /usr/lib/azureus/libswt-cairo-gtk-3139.so (requires 
 libcairo.so.1) broken /usr/lib/vlc/codec/libffmpeg_plugin.so (requires 
 liblzo.so.1) broken /usr/lib/wengophone/libphapi.so (requires  liblzo.so.1
 libowcurl.so)

 When I try to rebuild any of the packages net-im/wengophone-2.0_rc2 or
 media-video/vlc-0.8.5-r5, the compilation failed with the error :
 cannot find -llzo

 Indeed, in my lib directory I can find liblzo2.so.2 but I don't have
 liblzo2.so.1.

Note the difference, there are 2 different versions of liblzo.
net-im/wengophone seems to depend on version 1 but does not enforce this in 
the ebuild, you should report a bug about this. You can install it yourself 
untill this dep is fixed.

emerge =dev-libs/lzo-1*

The other broken libs will probably be solved after running revdep-rebuild 
again.
-- 
gentoo-user@gentoo.org mailing list