Bugzilla Bug 113818

This has been in portage for quite some time as unstable.  It also is required
to fix another issue.  Requesting to move to stable.

stable on amd64

re-adding amd64 until dbus 0.36.2 will be requested for stable

before marking stable, theres a lot of things to be tested:

1.  Upgrade / Downgrade cycles with things that are marked = for hal 4*.
2.  Will this break current GNOME / KDE stable installs(think automounting)? (
some api changed between 4 and 5, so a lot of packs are = 4* )

Just those 2 things require a bunch of testing :)

Please make sure all packages relying on hal are tested before marking stable.

Thanks

adding KDE and GNOME to CC as this affects both

(In reply to comment #3) 
> 2.  Will this break current GNOME / KDE stable installs(think automounting)?  
 
kdebase will definitely need to be recompiled after hal-0.5 is marked stable. 
Maybe the ebuild could give a message in pkg_postinst along the lines of the 
one in media-libs/flac? 
 
 

sparc never had hal stable, in fact other than the development profiles it's
masked.

A newer K3B version needs to go stable as well (I don't even know, if those
work
reliably with the currently unstable hal/dbus combination).

greg_g: Done.  Added an upgrade warning in pkg_postinst.
carlo: Could you make a bug and have it block this one please?

KDE team: what does everyone think about using this hal and dbus on kde-3.5 and 
making a hard dep on the previous versions for kde-3.4?  This would help 
resolve this issue. 

This would also block Gnome 2.12 from going stable, which is the main reason I 
spent so long making sure KDE could work with either version. This should be 
considered, or may be we do a hard dep now, and then a rev bump when they move 
forward? 

(In reply to comment #9)
> KDE team: what does everyone think about using this hal and dbus on kde-3.5 and 
> making a hard dep on the previous versions for kde-3.4?  This would help 
> resolve this issue. 

Not that I care (since I don't use hal/dbus), but I wonder what it would help.
Those who use the currently stable hal/dbus combination have to rebuild anyways.
As with other dependencies, the "classic" (and mildly annoying) revdep-rebuild
run is necessary, as long as we don't have proper reverse dependency support
built into Portage. What I do more care about is, that the less broken
revdep-rebuild version is still in a marked testing gentoolkit ebuild, while the
currently stable one is hideous broken.

0.5.5.1 is much needed improvement over 0.5.4

This is PPC64. I ran hal-0.5.5.1 quite some time and just updated to
hal-0.5.5.1-r1.

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

PPC64 is not hitting the k3b problem as we don't have it marked ~ppc64 or even
stable.

Now that I have looked at the dependecies of hal-0.5.5.1-r1 I saw that it
requires >=sys-fs/udev-071. So which version is going to be stabilized? I am
currently running 072 and have no problems so far.

I ran into problem with hal-0.5.5.1 with udev-071 - udev-073.  Those versions
of udev weren't reporting usb hotplug events correctly.  This meant that USB
sticks weren't able to automount.  I've tested that udev-079 doesn't miss the
USB hotplug events and correctly reports such events to HAL.  This problem
occured on my two computers.

can you please verify this behaviour with udev-072. I've also issues with 071
and 073, but 072 is just working fine here.

I went and tested udev-072 and it does catch the usb hotplug events correctly. 
udev-071, and udev-073 don't catch the usb hotplug events correctly.  udev-079
also catches the usb hotplug events correctly.

It would seem that bug 116530 tells us that dbus doesn't know about
mdassembler.
This makes dbus not build successfuly with USE="doc mono".

I have been running baselayout-1.11.14 and udev-079 and hal-0.5.5.1-r1,
dbus-0.60-r3, no problem, works fine with gnome-2.12.2

stable on x86

amd64 done.

ppc stable

stable on ppc64

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

ia64 done, which possibly means that this bug can be closed...

Adding alpha as it is the only remaining arch.

alpha? any word?

alpha done by our very own kloeri. YEY.