Bugzilla Bug 113826

This is a dependency for hal.

Adding GNOME and KDE as it affects both of them

0.50 ebuilds include some good cleanage.

This is PPC64. I am running dbus-0.50* quite some time now. No problems so far.

so where are we? still stable request? I haven't seen a solid statement from
KDE/Gnome herd if it can go stable.

(In reply to comment #3)
> I haven't seen a solid statement from KDE/Gnome herd if it can go stable.

See the blocking bug(s). I for one don't even use hal/dbus at all, read - can't
argue for KDE on the stabilisation, but I'd also guess that bug 113818 isn't
really blocked, but that the corresponding hal/dbus versions should go stable
at once, so blockers on dbus are blockers on hal as well, if I'm not wrong.

dbus 0.50 seems fine on sparc.
however... shouldn't the ebuild contain upgrade info about running
revdep-rebuild? since current stable -> 0.50+ breaks the ABI.

Basically this is a coordination bug. So everyone knows what we need to do to
get KDE & Gnome in.

We're now going to aim for dbus-0.60 because it's the new API and suppose to be
the 1.0 API as well... while 0.50 is going to start hitting bit-rot.

So get your compilers ready folks.

What about at least latest totem & sound-juicer not building against
dbus-0.60+?
If we do dbus-0.60 stable without fixing that first we'll get another of those
nice upgrade/downgrade loops with totem currently being locked to dbus <0.60.

how can this dbus 0.60 be marked stable when its still in package.mask?

It would seem to be that until it has been out of package.mask for at least 30
days it can't be stabilised - is it ready to come out of package.mask yet? I
will start testing KDE 3.4 and 3.5 with it if this is going to be the stable
candidate, but it will be at least another month now anyway. It does at least
compile with the qt bindings now.

It would seem dbus-0.60-r2 does not create a symlink for
/usr/bin/dbus-daemon-1, which would prevent a marking of stable no matter what.

(In reply to comment #10)
> It would seem dbus-0.60-r2 does not create a symlink for
> /usr/bin/dbus-daemon-1, which would prevent a marking of stable no matter what.
> 

The problem continues in dbus-0.60-r3 as well...

It does not look like dbus-0.60 is ready for stable marking as it still was
package.masked last time I checked so please readd us when the month in ~x86 is
up and no bugs are open.

Actually it does not. -r2 contained the fix an hour later. -r3 was just a bump
to clean it up for those that sync'd. You must run etc-update after emerging.

This bug is here as a tracker as what's required for Gnome 2.12 and KDE 3.5
stablization. This is still part of the dependancy tree for stablization,
that's why it's here.

It was also masked by someone who had no clue what they were doing.

(In reply to comment #14)
> This bug is here as a tracker as what's required for Gnome 2.12 and KDE 3.5
> stablization. This is still part of the dependancy tree for stablization,
> that's why it's here.
> 
> It was also masked by someone who had no clue what they were doing.
> 

So pleas help me understand why this "perfect" version of dbus brakes most of
my gnome applications...

Ron: Unfortunatly it does not. If you read the source code for Gnome 2.12.2,
it's the defaultly used version. There are fallback #ifdef's to use the old API
as well. So what I do recommend you do, read the instructions and run
revdep-rebuild.

(In reply to comment #16)
> Ron: Unfortunatly it does not. If you read the source code for Gnome 2.12.2,
> it's the defaultly used version. There are fallback #ifdef's to use the old API
> as well. So what I do recommend you do, read the instructions and run
> revdep-rebuild.
> 

Well, i did that. But it didn't work for me ... sory.
revdep-rebuild did not solv the problem for me in priviuce versions nor did
emerging ths whole system/world. In fact after downgrading dbus to version
0.50-r2 i had to emerge everithing again ...  

Because dbus-0.50 and dbus-0.60 use different SO filenames... so programs need
to be re-linked against each.

Well, I also ran into troubles with my GNOME and dbus-0.60-r3.
gnome-volume-manager obviously does not work anymore, devices are no longer
mounted automatically, totem is not able to recognize DVDs, either, even if
they are mounted manually.
In fact, I did run revdep-rebuild, but the only programs that were rebuilt,
were hal and nautilus-cd-burner. I guess, that's not enough. After some
investigation, I found out, that pmount for example was also broken (linked
against the old library) but it was not rebuilt while running revdep-rebuild. I
guess, that there are other programs and libraries on my system, that were
built against the old dbus, but not accordingly rebuilt by revdep-rebuild.

(In reply to comment #19)
> Well, I also ran into troubles with my GNOME and dbus-0.60-r3.
> gnome-volume-manager obviously does not work anymore, devices are no longer
> mounted automatically, totem is not able to recognize DVDs, either, even if
> they are mounted manually.
> In fact, I did run revdep-rebuild, but the only programs that were rebuilt,
> were hal and nautilus-cd-burner. I guess, that's not enough. After some
> investigation, I found out, that pmount for example was also broken (linked
> against the old library) but it was not rebuilt while running revdep-rebuild. I
> guess, that there are other programs and libraries on my system, that were
> built against the old dbus, but not accordingly rebuilt by revdep-rebuild.
> 

I think its a problem of revdep-rebuild, after I rebuild all these packages, it
works greate on my system.

Working pretty well on my system too (after revdep-rebuild of course)

sparc stable.
note that bluez-libs-2.22 & bluez-utils-2.22-r1 will need to go stable with
this.

@gentopia: see the comment on the main 2.12 bug about also stabling

>=dev-util/monodoc-0.16 and
>=dev-util/mono-tools-1.1.9

Perhaps these are ready to go stable as well?

Thanks

I've just put an update on the gnome related bug about the monodoc/mono-tools
stuff. See comment #4 on bug #119634.

stable on x86

amd64 done

stable on ppc64

stable on ppc

Removing bug #119737 since ia64 hadn't started the process of stabilizing gnome
and its dependencies for the release snapshot.

ia64 done, closing