First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 156339
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Patrick McLean <chutzpah@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Fernando Garcia Bermudez <fernando@movrev.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 156339 depends on: Show dependency tree
Show dependency graph
Bug 156339 blocks: 154521
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2006-11-26 12:55 0000
bmpx-0.34.4 depends on dbus-glib-0.72 which depends on dbus >= 0.94, which
means 
on either dbus-1.0.1 or dbus-1.01-r1. All of the previous packages are
hard-masked; bmpx-0.34.4, supposedly because of cairomm which has been unmasked
recently; and the rest due to waiting for the new mono bindings and testing.

I unmasked all and emerged them having the dbus system break on me, which makes
their hard-mask necessary. However, I've contacted bmpx's main developer and he
told me that bmpx requires only dbus >=0.61. Because of this, I modified the
ebuild's requirement to require dbus >=0.62-r1, which was the one I have
working on my system and I could make bmpx work. Here's the corresponding diff:

39c39
<       >=dev-libs/dbus-glib-0.72
---
>       >=sys-apps/dbus-0.62-r1

I did a second modification because with gst-plugins-mad-0.10.3 I couldn't play
mp3's, but I can now (note that 0.10.4 didn't work as well). The diff is:

53c53
<       mad? ( >=media-plugins/gst-plugins-mad-0.10.3 )
---
>       mad? ( >=media-plugins/gst-plugins-mad-0.10.4-r1 )

bmpx is not completely stable, so it should keep it's ~amd64 flag, but at least
it's usable and can be tested after the required changes to the ebuild and some
more testing before taking the hard-mask off. Here's my emerge --info if you
need further details on my system.

Portage 2.1.1-r2 (default-linux/amd64/2005.0, gcc-3.4.6, glibc-2.4-r4,
2.6.17-gentoo-r8 x86_64)
=================================================================
System uname: 2.6.17-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.12.6
Last Sync: Fri, 24 Nov 2006 17:20:01 +0000
ccache version 2.3 [enabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.3.5-r2, 2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r4
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-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/revdep-rebuild /etc/splash /etc/terminfo
/etc/texmf/web2c"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildpkg ccache distlocks fixpackages
metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo
ftp://mirror.datapipe.net/gentoo http://gentoo.mirrors.tds.net/gentoo"
LANG="en_US"
LINGUAS="en en_US"
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'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="amd64 X aac alsa arts audiofile beagle berkdb bitmap-fonts
blender-game bonobo bzip2 cdparanoia cdr cli cracklib crypt cups dbus
dlloader doc dri dvd dvdr eds elibc_glibc emboss encode esd exif ffmpeg
fftw firefox flac foomaticdb fortran gaim gcc64 gif gmail gnome gpm
gstreamer gtk gtk2 gtkhtml hal iconv imap imlib input_devices_evdev
input_devices_keyboard input_devices_mouse ipv6 isdnlog java javascript
jpeg jpeg2k kerberos kernel_linux lapack lcms ldap linguas_en
linguas_en_US lzw lzw-tiff mad maildir mbox mikmod mng mono mp3 mpeg
musepack nas ncurses nls nptl nptlonly nsplugin nvidia ogg openal opengl
oss pam pcre pdf perl png pop pppd python qt3 qt4 quicktime readline
reflection sasl sdl session spell spl ssl svg tcpd theora tiff timidity
truetype truetype-fonts type1-fonts unicode usb userland_GNU
video_cards_nvidia vorbis xinerama xml xorg xpm xscreensaver xv xvid zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

------- Comment #1 From Jakub Moc (RETIRED) 2006-11-26 13:11:25 0000 -------
*** Bug 156341 has been marked as a duplicate of this bug. ***

------- Comment #2 From Jakub Moc (RETIRED) 2006-11-26 13:17:41 0000 -------
Fails to run how? Need to post some info to fix the problem, changing the
dependencies is no solution.

------- Comment #3 From Fernando Garcia Bermudez 2006-11-26 13:29:22 0000 -------
When I installed dbus-glib-0.72 and dbus > 0.62-r1 due to the requirements of
the original ebuild for bmpx-0.34.4, I got this error when running bmpx:

/usr/libexec/beep-media-player-2-bin: error while loading shared libraries:
libdbus-1.so.2: cannot open shared object file: No such file or directory

I ran revdep-rebuild which recognized this error, and rebuilt all dbus
dependent apps, which were broken + it built (went back to) dbus-0.62 resulting
in the following error:

/usr/libexec/beep-media-player-2-bin: error while loading shared libraries:
libdbus-1.so.3: cannot open shared object file: No such file or directory

I suppose the problem was having dbus-0.62-r1 + dbus-glib-0.72 together.

If I ran emerge --update --deep --newuse world, it tried to reinstall dbus >
0.62, which brought me back into the first problem.

Needless it is to say that not only bmpx couldn't ran, but all dbus dependent
apps and even hal had problems with this configuration while they don't with
0.62-r1. I obviously restarted the dbus and hal systems after having them
rebuilt.

That is why I decided to try modifying the ebuild, and it worked so far.

------- Comment #4 From Doug Goldstein 2006-12-02 12:18:31 0000 -------
dbus-glib is for D-Bus 1.0. You can not have dbus-0.62 installed at the same
time. 

You need to install sys-apps/dbus-1.0 & dbus-glib-0.72 then revdep-rebuild.

------- Comment #5 From Fernando Garcia Bermudez 2006-12-02 14:27:23 0000 -------
Yes, I agree. Read carefully my two previous posts as they show the main
problem I have as it relates to what you're saying.

As a summary, when I take off the hardmask, dbus-glib-0.72 and dbus > 0.94 get
compiled while dbus-0.62-r1 gets cleaned out. However, this new dbus
configuration fails to run all of my dbus dependent apps and I'm forced to
revdep-rebuild. After this script finds the broken dependencies, it recompiles
all dbus dependent apps and then dbus-0.62-r1, keeping for the time being
dbus-glib, which gives a further error because of what you note. I then tried
updating world and it tries to revert me to dbus > 0.94, which makes the
dependency problems circular. So, because of this, I agree that both
dbus-glib-0.72 and dbus > 0.94 should stay hard-masked for now.

On the other hand, reinstating what I said above, bmpx only requires dbus >=
0.61 according to it's main developer. Changing the dependency requirements in
the ebuild, in my case, let me run bmpx and all other related apps without
greater problems.

Note, though, that bmpx is slightly unstable when it comes to hal and I saw the
following two errors at startup, when starting Automounter, which I assume are
related to bmpx.

9381: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL
|| !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 243.
This is normally a bug in some application using the D-BUS library.

libhal.c 373 : No property volume.mount_point on device with id
/org/freedesktop/Hal/devices/volume_uuid_4642adef_b233_4754_8cda_4d4d9bd58843

I tried to transcribe them as best as I could by switching vt's as I don't know
where this bootup procedure is logged. The first error appears 5 times, one
after the other, on screen while the latter just at the end before giving the
[ok] and continuing loading other daemons.

(Note: I know this last bug might be better related to Automounter, Hal, or
even Dbus, but since I think bmpx might be causing it because of it's dbus
dependency, I'll post it here for now)

------- Comment #6 From Milosz Derezynski 2006-12-03 00:26:30 0000 -------
9381: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL
|| !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 243.
This is normally a bug in some application using the D-BUS library.

libhal.c 373 : No property volume.mount_point on device with id
/org/freedesktop/Hal/devices/volume_uuid_4642adef_b233_4754_8cda_4d4d9bd58843

That looks both like HAL bugs to me. The first one is known to appear also with
Rhythmbox (although they seem to have fixed it client-side, so i assume we can
fix it too by properly dealing with the DBusConnection instance used for HAL)

The second problem is while not directly a HAL "bug", rather weird, since BMP
only asks for volume.mount_point when the MOUNTABLE_FILESYSTEM flag is set on
the appropriate HAL volume, so it seems like an inconsistency with HAL and
while it's sure odd it's nothing critical (the first error is, while also not
critical since a few people have experienced it, more severe).

(Just FWIW, the logs go into ~/.config/bmpx/logs/*)

------- Comment #7 From Patrick McLean 2006-12-04 13:50:04 0000 -------
Fixed with media-sound/bmpx-0.34.9 which is now in the tree.

------- Comment #8 From Bolek Tekielski 2006-12-05 02:27:30 0000 -------
When trying to run bmp2 (0.34.9) I get :
** Message: #1 Error: Could not get owner of name 'org.beepmediaplayer.bmp': no
such name
and a popup which suggest using /usr/libexec/beep-media-player-2-bin --no-log
to check what's wrong.

When I try to run /usr/libexec/beep-media-player-2-bin --no-log i got:

BMP-Message: sm.cc:270: Connection opened, client id is
11c0a80106000116531424600000066150007
BMP-Message: sm.cc:53: XSMP Version: 1  Revision: 0
BMP-Message: sm.cc:56: Session manager: GnomeSM 
BMP-Message: sm.cc:60: Release: 2.16.1
BMP-Message: Running: CServiceCore (DBus:org.beepmediaplayer.bmp)
BMP-Message: Transport plugin 'http' loaded.
BMP-Message: Transport plugin 'file' loaded.
BMP-Message: Container plugin 'Folder Container Plugin' loaded
BMP-Message: Container plugin 'M3U Playlist' loaded
BMP-Message: Container plugin 'PLS Playlist' loaded
BMP-Message: Container plugin 'MLQ Playlist' loaded
BMP-Message: Container plugin 'XSPF Playlist' loaded
BMP-Message: Container plugin 'Query Parser' loaded
BMP-Message: Running: Monitor
BMP-INFO: Starting UI
segmentation fault.

I can run /usr/libexec/beep-media-player-2-bin --no-log only as a root, but
still when I try bmp2 as a root I get the same error:

** Message: #1 Error: Could not get owner of name 'org.beepmediaplayer.bmp': no
such name

------- Comment #9 From Milosz Derezynski 2006-12-05 10:30:27 0000 -------
Ok i've got to rename the message names, Message "#1" is not an error and
shouldn't be called a such. Message "#1" just means that BMPx isn't running yet
when the remote binary tries to start it up. (This of course doesn't change the
rest of this bug report, that BMPx doesn't want to or doesn't seem to start up)

------- Comment #10 From David Joaquim 2006-12-10 12:46:50 0000 -------
(In reply to comment #8)
I had the same problem. I upgraded to dbus-1.0.1-r2 and it works fine now.

First Last Prev Next    No search results available      Search page      Enter new bug