Broken dependencies in Fedora 11 - 2009-07-01
by Michael Schwendt
======================================================================
The results in this summary consider Test Updates!
======================================================================
Summary of broken packages (by src.rpm name):
beagle
f-spot
gauche-gl
gauche-gtk
gbrainy
gnome-do
gnome-keyring-sharp
gnome-phone-manager
ipod-sharp
lat
liferea
muine
notify-sharp
podsleuth
ppl
python-repoze-what
sunbird
tomboy
wine
======================================================================
Broken packages in fedora-11-i386:
gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13
gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13
liferea-WebKit-1.4.26-2.fc11.i586 requires liferea = 0:1.4.26
======================================================================
Broken packages in fedora-11-ppc:
gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13
gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13
liferea-WebKit-1.4.26-2.fc11.ppc requires liferea = 0:1.4.26
======================================================================
Broken packages in fedora-11-ppc64:
liferea-WebKit-1.4.26-2.fc11.ppc64 requires liferea = 0:1.4.26
======================================================================
Broken packages in fedora-11-x86_64:
gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13
gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13
liferea-WebKit-1.4.26-2.fc11.x86_64 requires liferea = 0:1.4.26
======================================================================
Broken packages in fedora-updates-11-i386:
ppl-yap-0.10.2-2.fc11.i586 requires libYap.so
======================================================================
Broken packages in fedora-updates-11-ppc:
ppl-yap-0.10.2-2.fc11.ppc requires libYap.so
======================================================================
Broken packages in fedora-updates-11-ppc64:
ppl-yap-0.10.2-2.fc11.ppc64 requires libYap.so()(64bit)
tomboy-0.14.2-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0
tomboy-0.14.2-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0
tomboy-0.14.2-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0
tomboy-0.14.2-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0
tomboy-0.14.2-1.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
======================================================================
Broken packages in fedora-updates-11-x86_64:
ppl-yap-0.10.2-2.fc11.x86_64 requires libYap.so()(64bit)
wine-esd-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11
wine-jack-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11
wine-nas-1.1.23-1.fc11.i586 requires wine-core = 0:1.1.23-1.fc11
======================================================================
Broken packages in fedora-updates-testing-11-i386:
gnome-phone-manager-0.65-2.fc11.i586 requires libgnome-bluetooth.so.2
python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8
thunderbird-lightning-1.0-0.5.20090513hg.fc11.i586 requires thunderbird >= 0:3.0-2.4.b3pre
======================================================================
Broken packages in fedora-updates-testing-11-ppc:
gnome-phone-manager-0.65-2.fc11.ppc requires libgnome-bluetooth.so.2
python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8
thunderbird-lightning-1.0-0.5.20090513hg.fc11.ppc requires thunderbird >= 0:3.0-2.4.b3pre
======================================================================
Broken packages in fedora-updates-testing-11-ppc64:
beagle-0.3.9-8.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0
beagle-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0
beagle-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
beagle-0.3.9-8.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2
beagle-evolution-0.3.9-8.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0
beagle-gnome-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0
beagle-gnome-0.3.9-8.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
beagle-thunderbird-0.3.9-8.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0
f-spot-0.5.0.3-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0
f-spot-0.5.0.3-9.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0
f-spot-0.5.0.3-9.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0
f-spot-0.5.0.3-9.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0
f-spot-0.5.0.3-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
gbrainy-1.1-4.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0
gbrainy-1.1-4.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0
gbrainy-1.1-4.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0
gnome-do-0.8.1.3-6.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0
gnome-do-0.8.1.3-6.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0
gnome-do-0.8.1.3-6.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0
gnome-keyring-sharp-1.0.1-0.3.115768svn.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
gnome-phone-manager-0.65-2.fc11.ppc64 requires libgnome-bluetooth.so.2()(64bit)
ipod-sharp-0.8.1-3.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
lat-1.2.3-7.fc11.ppc64 requires dbus-sharp
muine-0.8.10-5.fc11.ppc64 requires ndesk-dbus-glib
notify-sharp-0.4.0-0.7.20080912svn.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0
notify-sharp-0.4.0-0.7.20080912svn.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
podsleuth-0.6.3-3.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0
python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8
thunderbird-lightning-1.0-0.5.20090513hg.fc11.ppc64 requires thunderbird >= 0:3.0-2.4.b3pre
======================================================================
Broken packages in fedora-updates-testing-11-x86_64:
gnome-phone-manager-0.65-2.fc11.x86_64 requires libgnome-bluetooth.so.2()(64bit)
python-repoze-what-docs-1.0.8-1.fc11.noarch requires python-repoze-what-1.0.8
thunderbird-lightning-1.0-0.5.20090513hg.fc11.x86_64 requires thunderbird >= 0:3.0-2.4.b3pre
14 years, 10 months
RFC: Kernel changes that may affect desktops
by Matthew Garrett
ACPI docking stations are mildly complicated creatures that require the
OS to handle part of the undocking process. We're currently doing this
entirely within the kernel, but this has the significant downside that
there's no way to handle cleanly unmounting any block devices that are
contained within the dock - they'll simply vanish.
I've been working with David Zeuthen to flesh out proper desktop support
for this, and we're now at the point where there's not a great deal of
code to write to get this working cleanly. Unfortunately this requires a
certain level of integration between the kernel and the desktop -
something has to prompt the user about unmounting the device and then
trigger the completion of the undock. The kernel still handles the
actual ACPI execution, but policy now lives in the desktop.
Once this code is ready I'd like to change the kernel defaults to allow
this. The problem is that this will cause a reduction in functionality
for desktops that don't have this integration. How should this kind of
situation be handled?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
14 years, 10 months
Re: RFC: Kernel changes that may affect desktops
by Ding Yi Chen
----- "Matthew Garrett" <mjg(a)redhat.com> wrote:
> On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote:
> > Matthew Garrett wrote:
> > What changes are needed to the desktop?
> >
> > The big problem we've been facing integrating new features of core
> system
> > services into KDE so far was lack of documentation. What do we need
> to
> > change?
>
> An event will be generated and a policy agent then needs to choose
> what
> to do in terms of unmounting any media. The precise interface doesn't
>
> exist yet, but will be documented.
>
> > If this will be all handled within DeviceKit, then this will come by
> itself
> > with the Solid DeviceKit backend ltinkl is working on, but if we
> need to
> > add some desktop interaction for it, we have to know what it should
> be.
>
> So, what you'll get is a notification that a block device has
> requested
> removal along with a notification that a dock device is being
> undocked.
> What you do with the block device is up to you, but in general you'll
>
> want to unmount it. Whether you're willing to kill applications that
> have open files on it is a policy decision. After the unmount you'll
> then trigger the completion of the undock and tell the user that it's
>
> now safe to remove their hardware.
IMHO, it is pretty much similar to the way that we handle USB hubs and devices.
In terms of UI, it may have a nice dock status icon to show status and to be pressed
if users want to un-dock safely.
Yet we still need to handle the force-undock event, just like we handle the
forced unplug USB devices.
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
14 years, 10 months