FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu Development

 
 
LinkBack Thread Tools
 
Old 05-25-2012, 09:12 AM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Hello all,

Also sending this to kubuntu-devel@, but as I'm not a subscriber
someone needs to moderate; CC'ing Scott and Harald directly.

As discussed at UDS and in [1] we want to dramatically simplify the
machinery for installing extra drivers (NVidia, bcmwl, and friends).
Jockey was originally designed to do a lot more than we are using it
for, and be compatible with other distros as well (I had it working on
Fedora 14 back then, when we discussed it in the Linux Foundation
driver backports workgroup). But we don't use it to that extent, other
distros have moved into a different direction, and thus it has way too
much code and bugs. So Ubuntu will drop it and replace with with
something much simpler and robust, and also use upstream friendly APIs
(PackageKit).

The logic of detecting drivers and providing PackageKit/aptdaemon
plugins is now in the ubuntu-drivers-common package (formerly known
as "nvidia-common"). This now mostly makes PackageKit/aptdaemon able
to answer a "WhatProvides(MODALIAS, pci:s0000DEADv0000BEEF...)" query
to map a piece of hardware to a driver package. It also contains a
command line tool "ubuntu-drivers" with a few commands (list,
autoinstall, and debug at the moment) which replaces jockey's usage in
the installer (which called jockey-text --no-dbus ...).

The user interface will be made a lot simpler and less confusing, and
move into software-properties-gtk (or perhaps software-center at some
point).

The question arises what to do with Kubuntu. We have a few obvious
options:

* Kubuntu uses software-properties-kde, so as long as we keep
software-properties, the new design could be implemented there as
well, and jockey-kde be dropped.

* Kubuntu implements a similar (or their own) design using the
ubuntu-drivers-common API in the KDE control center as an embedded
tab. Then we can also drop jockey-kde.

* Kubuntu keeps jockey-kde, and takes over the Jockey maintenance.
ubuntu-drivers-common does not break Jockey, but it would still
need some maintenance to adapt to newer nvidia driver versions,
changing Qt/KDE APIs, and the like.

* Kubuntu keeps the jockey-kde UI, but drops the backend
(jockey-common) and changes the UI to work with the
ubuntu-drivers-common API.

In either case, automatic driver installation by Ubiquity will Just
Work (e. g. for the Broadcom wifi cards) but there should still be an
UI for enabling or changing drivers (like NVidia, which is not
auto-installed) manually.

Opinions?

Thanks,

Martin

[1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-third-party-driver-installation
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-25-2012, 01:09 PM
Jonathan Thomas
 
Default Overview of Jockey replacement; options for Kubuntu?

Hello,

On Fri, May 25, 2012 at 5:12 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Hello all,
>
> Also sending this to kubuntu-devel@, but as I'm not a subscriber
> someone needs to moderate; CC'ing Scott and Harald directly.
>
> As discussed at UDS and in [1] we want to dramatically simplify the
> machinery for installing extra drivers (NVidia, bcmwl, and friends).
> Jockey was originally designed to do a lot more than we are using it
> for, and be compatible with other distros as well (I had it working on
> Fedora 14 back then, when we discussed it in the Linux Foundation
> driver backports workgroup). But we don't use it to that extent, other
> distros have moved into a different direction, and thus it has way too
> much code and bugs. So Ubuntu will drop it and replace with with
> something much simpler and robust, and also use upstream friendly APIs
> (PackageKit).
>
> The logic of detecting drivers and providing PackageKit/aptdaemon
> plugins is now in the ubuntu-drivers-common package (formerly known
> as "nvidia-common"). This now mostly makes PackageKit/aptdaemon able
> to answer a "WhatProvides(MODALIAS, pci:s0000DEADv0000BEEF...)" query
> to map a piece of hardware to a driver package. It also contains a
> command line tool "ubuntu-drivers" with a few commands (list,
> autoinstall, and debug at the moment) which replaces jockey's usage in
> the installer (which called jockey-text --no-dbus ...).

I think that we'd rather not use PackageKit (for Kubuntu at least). We
already have python-apt and QApt as part of the default Kubuntu
install, so having a third apt worker implementation would be
undesirable. Could the new jockey communicate with a "what
provides-helper" written with libqapt that uses DBus for
communication, and use the qaptworker for running installs if I were
to implement such a helper?

>
> The user interface will be made a lot simpler and less confusing, and
> move into software-properties-gtk (or perhaps software-center at some
> point).
>
> The question arises what to do with Kubuntu. We have a few obvious
> options:
>
> ** Kubuntu uses software-properties-kde, so as long as we keep
> * software-properties, the new design could be implemented there as
> * well, and jockey-kde be dropped.

This could work, although it would (obviously) require some additional
GUI work on the KDE side of things. Though if we're already going to
have to write additional GUI...

>
> ** Kubuntu implements a similar (or their own) design using the
> * ubuntu-drivers-common API in the KDE control center as an embedded
> * tab. Then we can also drop jockey-kde.
... then I think it would be beneficial to write a KConfig Module so
that it could be integrated as a sub-page of the "Display and Monitor"
page in KDE's System Settings. I attempted to write a Jockey frontend
for this a few years back, but was foiled due to the multithreading in
jockey not playing nice with the KDE plugin apis.

>
> ** Kubuntu keeps jockey-kde, and takes over the Jockey maintenance.
> * ubuntu-drivers-common does not break Jockey, but it would still
> * need some maintenance to adapt to newer nvidia driver versions,
> * changing Qt/KDE APIs, and the like.

This is undesirable, but could be a fallback as a worst-case scenario.

>
> ** Kubuntu keeps the jockey-kde UI, but drops the backend
> * (jockey-common) and changes the UI to work with the
> * ubuntu-drivers-common API.

This could also be another fallback mode, if we get
ubuntu-drivers-common working with QApt as a backend, but don't get
the GUI done in time, etc.

>
> In either case, automatic driver installation by Ubiquity will Just
> Work (e. g. for the Broadcom wifi cards) but there should still be an
> UI for enabling or changing drivers (like NVidia, which is not
> auto-installed) manually.
>

Anyways, those are my opinions.

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-25-2012, 07:28 PM
Jussi Schultink
 
Default Overview of Jockey replacement; options for Kubuntu?

Hi all

On Fri, May 25, 2012 at 4:09 PM, Jonathan Thomas <echidnaman@gmail.com> wrote:
> Hello,
>
> On Fri, May 25, 2012 at 5:12 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
>> Hello all,
>>
>> Also sending this to kubuntu-devel@, but as I'm not a subscriber
>> someone needs to moderate; CC'ing Scott and Harald directly.
>>
>> As discussed at UDS and in [1] we want to dramatically simplify the
>> machinery for installing extra drivers (NVidia, bcmwl, and friends).
>> Jockey was originally designed to do a lot more than we are using it
>> for, and be compatible with other distros as well (I had it working on
>> Fedora 14 back then, when we discussed it in the Linux Foundation
>> driver backports workgroup). But we don't use it to that extent, other
>> distros have moved into a different direction, and thus it has way too
>> much code and bugs. So Ubuntu will drop it and replace with with
>> something much simpler and robust, and also use upstream friendly APIs
>> (PackageKit).
>>
>> The logic of detecting drivers and providing PackageKit/aptdaemon
>> plugins is now in the ubuntu-drivers-common package (formerly known
>> as "nvidia-common"). This now mostly makes PackageKit/aptdaemon able
>> to answer a "WhatProvides(MODALIAS, pci:s0000DEADv0000BEEF...)" query
>> to map a piece of hardware to a driver package. It also contains a
>> command line tool "ubuntu-drivers" with a few commands (list,
>> autoinstall, and debug at the moment) which replaces jockey's usage in
>> the installer (which called jockey-text --no-dbus ...).
>
> I think that we'd rather not use PackageKit (for Kubuntu at least). We
> already have python-apt and QApt as part of the default Kubuntu
> install, so having a third apt worker implementation would be
> undesirable. Could the new jockey communicate with a "what
> provides-helper" written with libqapt that uses DBus for
> communication, and use the qaptworker for running installs if I were
> to implement such a helper?
>
>>
>> The user interface will be made a lot simpler and less confusing, and
>> move into software-properties-gtk (or perhaps software-center at some
>> point).
>>
>> The question arises what to do with Kubuntu. We have a few obvious
>> options:
>>
>> ** Kubuntu uses software-properties-kde, so as long as we keep
>> * software-properties, the new design could be implemented there as
>> * well, and jockey-kde be dropped.
>
> This could work, although it would (obviously) require some additional
> GUI work on the KDE side of things. Though if we're already going to
> have to write additional GUI...
>
>>
>> ** Kubuntu implements a similar (or their own) design using the
>> * ubuntu-drivers-common API in the KDE control center as an embedded
>> * tab. Then we can also drop jockey-kde.
> ... then I think it would be beneficial to write a KConfig Module so
> that it could be integrated as a sub-page of the "Display and Monitor"
> page in KDE's System Settings. I attempted to write a Jockey frontend
> for this a few years back, but was foiled due to the multithreading in
> jockey not playing nice with the KDE plugin apis.

This is definately my preferred solution - make it fit with other KDE
items and ways of doing things as much as possible. Also, if the
module can be written so that it would support other backends it
perhaps even could be forwarded upstream, which would be ideal.
>
>>
>> ** Kubuntu keeps jockey-kde, and takes over the Jockey maintenance.
>> * ubuntu-drivers-common does not break Jockey, but it would still
>> * need some maintenance to adapt to newer nvidia driver versions,
>> * changing Qt/KDE APIs, and the like.
>
> This is undesirable, but could be a fallback as a worst-case scenario.
>
>>
>> ** Kubuntu keeps the jockey-kde UI, but drops the backend
>> * (jockey-common) and changes the UI to work with the
>> * ubuntu-drivers-common API.
>
> This could also be another fallback mode, if we get
> ubuntu-drivers-common working with QApt as a backend, but don't get
> the GUI done in time, etc.
>
>>
>> In either case, automatic driver installation by Ubiquity will Just
>> Work (e. g. for the Broadcom wifi cards) but there should still be an
>> UI for enabling or changing drivers (like NVidia, which is not
>> auto-installed) manually.
>>
>
> Anyways, those are my opinions.
>
> --
> kubuntu-devel mailing list
> kubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Hope my 2c are useful

Jussi

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-29-2012, 05:23 AM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Hello Jonathan,

Jonathan Thomas [2012-05-25 9:09 -0400]:
> I think that we'd rather not use PackageKit (for Kubuntu at least).

Please note that it just provides a PackageKit API. We don't use the
actual PackageKit in Ubuntu as well, but the python-aptdaemon.pkcompat
wrapper. Kubuntu does the same.

This provides an upstream friendly API, so that our GUIs for driver
detection do not have to stay distro specific for all times. However,
you don't have to use it, of course.

> We already have python-apt and QApt as part of the default Kubuntu
> install, so having a third apt worker implementation would be
> undesirable. Could the new jockey communicate with a "what
> provides-helper" written with libqapt that uses DBus for
> communication, and use the qaptworker for running installs if I were
> to implement such a helper?

ubuntu-drivers-common also provides a simple custom API:

UbuntuDrivers.detect.system_driver_packages()

→ give me all driver packages for this system

UbuntuDrivers.detect.packages_for_modalias(apt_cac he, modalias)

→ give me the driver package(s) for this piece of hardware

which you can use and wrap however you like.

> > ** Kubuntu implements a similar (or their own) design using the
> > * ubuntu-drivers-common API in the KDE control center as an embedded
> > * tab. Then we can also drop jockey-kde.
> ... then I think it would be beneficial to write a KConfig Module so
> that it could be integrated as a sub-page of the "Display and Monitor"
> page in KDE's System Settings. I attempted to write a Jockey frontend
> for this a few years back, but was foiled due to the multithreading in
> jockey not playing nice with the KDE plugin apis.

That could work better now. The "basic" API (system_driver_packages()
and packages_for_modalias()) does not use anything fancy like threads,
D-BUS, async, etc, just plain python-apt.

I agree.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-29-2012, 12:24 PM
Jonathan Thomas
 
Default Overview of Jockey replacement; options for Kubuntu?

Hi,

On Tue, May 29, 2012 at 1:23 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Hello Jonathan,
>
> Jonathan Thomas [2012-05-25 *9:09 -0400]:
>> I think that we'd rather not use PackageKit (for Kubuntu at least).
>
> Please note that it just provides a PackageKit API. We don't use the
> actual PackageKit in Ubuntu as well, but the python-aptdaemon.pkcompat
> wrapper. Kubuntu does the same.

This is incorrect, Kubuntu does not use aptdaemon at all, and doing so
would bring in a considerable amount of GTK libraries, not to mention
yet another apt implementation. If at all I possible, I would like to
write a QApt backend for ubuntu-drivers-common.

>
> This provides an upstream friendly API, so that our GUIs for driver
> detection do not have to stay distro specific for all times. However,
> you don't have to use it, of course.

Currently it's being dragged in by nvidia-common, so it's not exactly
optional if you have an nvidia card...

>
>> We already have python-apt and QApt as part of the default Kubuntu
>> install, so having a third apt worker implementation would be
>> undesirable. Could the new jockey communicate with a "what
>> provides-helper" written with libqapt that uses DBus for
>> communication, and use the qaptworker for running installs if I were
>> to implement such a helper?
>
> ubuntu-drivers-common also provides a simple custom API:
>
> *UbuntuDrivers.detect.system_driver_packages()
>
> *→ give me all driver packages for this system
>
> *UbuntuDrivers.detect.packages_for_modalias(apt_c ache, modalias)
>
> *→ give me the driver package(s) for this piece of hardware
>
> which you can use and wrap however you like.
>
>> > ** Kubuntu implements a similar (or their own) design using the
>> > * ubuntu-drivers-common API in the KDE control center as an embedded
>> > * tab. Then we can also drop jockey-kde.
>> ... then I think it would be beneficial to write a KConfig Module so
>> that it could be integrated as a sub-page of the "Display and Monitor"
>> page in KDE's System Settings. I attempted to write a Jockey frontend
>> for this a few years back, but was foiled due to the multithreading in
>> jockey not playing nice with the KDE plugin apis.
>
> That could work better now. The "basic" API (system_driver_packages()
> and packages_for_modalias()) does not use anything fancy like threads,
> D-BUS, async, etc, just plain python-apt.
>
> I agree.
>
> Thanks,
>
> Martin
> --
> Martin Pitt * * * * * * * * * * * *| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) *| Debian Developer *(www.debian.org)
>
> --
> kubuntu-devel mailing list
> kubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-29-2012, 09:28 PM
Rafael Belmonte
 
Default Overview of Jockey replacement; options for Kubuntu?

I think something like qapt-drivers-installer would be the best option.
Making a solution for all GNU/Linux distribution is a complex project.

2012/5/29 Jonathan Thomas <echidnaman@gmail.com>:
> Hi,
>
> On Tue, May 29, 2012 at 1:23 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
>> Hello Jonathan,
>>
>> Jonathan Thomas [2012-05-25 *9:09 -0400]:
>>> I think that we'd rather not use PackageKit (for Kubuntu at least).
>>
>> Please note that it just provides a PackageKit API. We don't use the
>> actual PackageKit in Ubuntu as well, but the python-aptdaemon.pkcompat
>> wrapper. Kubuntu does the same.
>
> This is incorrect, Kubuntu does not use aptdaemon at all, and doing so
> would bring in a considerable amount of GTK libraries, not to mention
> yet another apt implementation. If at all I possible, I would like to
> write a QApt backend for ubuntu-drivers-common.
>
>>
>> This provides an upstream friendly API, so that our GUIs for driver
>> detection do not have to stay distro specific for all times. However,
>> you don't have to use it, of course.
>
> Currently it's being dragged in by nvidia-common, so it's not exactly
> optional if you have an nvidia card...
>
>>
>>> We already have python-apt and QApt as part of the default Kubuntu
>>> install, so having a third apt worker implementation would be
>>> undesirable. Could the new jockey communicate with a "what
>>> provides-helper" written with libqapt that uses DBus for
>>> communication, and use the qaptworker for running installs if I were
>>> to implement such a helper?
>>
>> ubuntu-drivers-common also provides a simple custom API:
>>
>> *UbuntuDrivers.detect.system_driver_packages()
>>
>> *→ give me all driver packages for this system
>>
>> *UbuntuDrivers.detect.packages_for_modalias(apt_c ache, modalias)
>>
>> *→ give me the driver package(s) for this piece of hardware
>>
>> which you can use and wrap however you like.
>>
>>> > ** Kubuntu implements a similar (or their own) design using the
>>> > * ubuntu-drivers-common API in the KDE control center as an embedded
>>> > * tab. Then we can also drop jockey-kde.
>>> ... then I think it would be beneficial to write a KConfig Module so
>>> that it could be integrated as a sub-page of the "Display and Monitor"
>>> page in KDE's System Settings. I attempted to write a Jockey frontend
>>> for this a few years back, but was foiled due to the multithreading in
>>> jockey not playing nice with the KDE plugin apis.
>>
>> That could work better now. The "basic" API (system_driver_packages()
>> and packages_for_modalias()) does not use anything fancy like threads,
>> D-BUS, async, etc, just plain python-apt.
>>
>> I agree.
>>
>> Thanks,
>>
>> Martin
>> --
>> Martin Pitt * * * * * * * * * * * *| http://www.piware.de
>> Ubuntu Developer (www.ubuntu.com) *| Debian Developer *(www.debian.org)
>>
>> --
>> kubuntu-devel mailing list
>> kubuntu-devel@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>
> --
> kubuntu-devel mailing list
> kubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-30-2012, 05:07 AM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Hello Jonathan,

Jonathan Thomas [2012-05-29 8:24 -0400]:
> > Please note that it just provides a PackageKit API. We don't use the
> > actual PackageKit in Ubuntu as well, but the python-aptdaemon.pkcompat
> > wrapper. Kubuntu does the same.
>
> This is incorrect, Kubuntu does not use aptdaemon at all

Both aptdaemon and python-aptdaemon.pkcompat are on the Kubuntu
images.

> and doing so would bring in a considerable amount of GTK libraries

It does depend on glib and python-gi, but there's little chance of
avoiding glib in Kubuntu. I'm less sure about python-gi, though, that
might be new.

> not to mention yet another apt implementation

aptdaemon does not reimplement apt, it provides the python-apt
functionality over D-BUS (similar to PackageKit, but it's a lot faster
on Ubuntu).

> If at all I possible, I would like to write a QApt backend for
> ubuntu-drivers-common.

Sure, I don't have an opinion about whether or not this is better, as
I don't know QApt myself.

> > This provides an upstream friendly API, so that our GUIs for driver
> > detection do not have to stay distro specific for all times. However,
> > you don't have to use it, of course.
>
> Currently it's being dragged in by nvidia-common, so it's not exactly
> optional if you have an nvidia card...

nvidia-common was renamed to ubuntu-drivers-common, as it is not just
for NVidia, but also for fglrx and the pvr-omap4 driver. As it is
taking over Jockey's functionality, it is pretty much mandatory in
12.10, but in exchange we can drop Jockey.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-30-2012, 12:19 PM
Jonathan Thomas
 
Default Overview of Jockey replacement; options for Kubuntu?

Hello,

On Wed, May 30, 2012 at 1:07 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Hello Jonathan,
>
> Jonathan Thomas [2012-05-29 *8:24 -0400]:
>> > Please note that it just provides a PackageKit API. We don't use the
>> > actual PackageKit in Ubuntu as well, but the python-aptdaemon.pkcompat
>> > wrapper. Kubuntu does the same.
>>
>> This is incorrect, Kubuntu does not use aptdaemon at all
>
> Both aptdaemon and python-aptdaemon.pkcompat are on the Kubuntu
> images.

Well, yes, now that nvidia-common is forcing the dependency via
ubuntu-drivers-common. But they were not as of precise:
http://cdimage.ubuntu.com/kubuntu/precise/daily-live/20120529.1/precise-desktop-amd64.manifest
and such a dependency is undesirable.

>
>> and doing so would bring in a considerable amount of GTK libraries
>
> It does depend on glib and python-gi, but there's little chance of
> avoiding glib in Kubuntu. I'm less sure about python-gi, though, that
> might be new.

We'd also need a debconf frontend which would mean bringing in the
grk3widgets aptdaemon stuff, which is undesirable as well.

>
>> not to mention yet another apt implementation
>
> aptdaemon does not reimplement apt, it provides the python-apt
> functionality over D-BUS (similar to PackageKit, but it's a lot faster
> on Ubuntu).

I didn't mean re-implement the whole thing. ;-) But already we have
the QApt Worker which can do this, making duplication a needless
waste.

>
>> If at all I possible, I would like to write a QApt backend for
>> ubuntu-drivers-common.
>
> Sure, I don't have an opinion about whether or not this is better, as
> I don't know QApt myself.

QApt is perfectly capable of providing installation stuff over DBus,
so it would be better from a dependencies/ISO space standpoint. Do you
know if ubuntu-drivers-common currently supports multiple backends,
and if it could be made to do so?

>
>> > This provides an upstream friendly API, so that our GUIs for driver
>> > detection do not have to stay distro specific for all times. However,
>> > you don't have to use it, of course.
>>
>> Currently it's being dragged in by nvidia-common, so it's not exactly
>> optional if you have an nvidia card...
>
> nvidia-common was renamed to ubuntu-drivers-common, as it is not just
> for NVidia, but also for fglrx and the pvr-omap4 driver. As it is
> taking over Jockey's functionality, it is pretty much mandatory in
> 12.10, but in exchange we can drop Jockey.

Well then an aptdaemon dependency is really unwanted in this case.

>
> Thanks,
>
> Martin

Thanks,
Jonathan

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-30-2012, 01:21 PM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas [2012-05-30 8:19 -0400]:
> > Both aptdaemon and python-aptdaemon.pkcompat are on the Kubuntu
> > images.
>
> Well, yes, now that nvidia-common is forcing the dependency via
> ubuntu-drivers-common. But they were not as of precise:
> http://cdimage.ubuntu.com/kubuntu/precise/daily-live/20120529.1/precise-desktop-amd64.manifest
> and such a dependency is undesirable.

Ah, oops. Dropped:

https://github.com/tseliot/ubuntu-drivers-common/commit/5d0bdefd48

> > It does depend on glib and python-gi, but there's little chance of
> > avoiding glib in Kubuntu. I'm less sure about python-gi, though, that
> > might be new.
>
> We'd also need a debconf frontend which would mean bringing in the
> grk3widgets aptdaemon stuff, which is undesirable as well.

Why is that? This just uses python-apt, it needs a frontend no more or
less than anything else that uses apt?

> > aptdaemon does not reimplement apt, it provides the python-apt
> > functionality over D-BUS (similar to PackageKit, but it's a lot faster
> > on Ubuntu).
>
> I didn't mean re-implement the whole thing. ;-) But already we have
> the QApt Worker which can do this, making duplication a needless
> waste.

I think we are just talking past each other: current u-d-common
_enables_ PackageKit/aptdaemon to ask for "what package provides a
driver for this device". It does not require you to use it (you can
use the native UbuntuDrivers module). I was just explaining why the
aptdaemon stuff is there.

> QApt is perfectly capable of providing installation stuff over DBus,
> so it would be better from a dependencies/ISO space standpoint.

Sounds fine.

> Do you know if ubuntu-drivers-common currently supports multiple
> backends, and if it could be made to do so?

u-d-common is a backend already. It currently provides these
interfaces:

* Native UbuntuDrivers Python module (Ubuntu specific)
* ubuntu-drivers CLI tool (Ubuntu specific)
* PackageKit "WhatProvides" API (upstream friendly for GUI
integration)

Of course we can easily add QApt integration there, too. This is a
native Ubuntu package which is meant to bundle all the Ubuntu specific
knowledge and backends that we need to implement easy and
non-distro-specific GUIs and integration for driver handling.

So I guess the short answer is "yes" :-)

> Well then an aptdaemon dependency is really unwanted in this case.

Right, understood. It should be gone with the next upload, sorry about
that.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-30-2012, 01:41 PM
Jonathan Thomas
 
Default Overview of Jockey replacement; options for Kubuntu?

Hi,

On Wed, May 30, 2012 at 9:21 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Jonathan Thomas [2012-05-30 *8:19 -0400]:
>> > Both aptdaemon and python-aptdaemon.pkcompat are on the Kubuntu
>> > images.
>>
>> Well, yes, now that nvidia-common is forcing the dependency via
>> ubuntu-drivers-common. But they were not as of precise:
>> http://cdimage.ubuntu.com/kubuntu/precise/daily-live/20120529.1/precise-desktop-amd64.manifest
>> and such a dependency is undesirable.
>
> Ah, oops. Dropped:
>
> *https://github.com/tseliot/ubuntu-drivers-common/commit/5d0bdefd48
>
>> > It does depend on glib and python-gi, but there's little chance of
>> > avoiding glib in Kubuntu. I'm less sure about python-gi, though, that
>> > might be new.
>>
>> We'd also need a debconf frontend which would mean bringing in the
>> grk3widgets aptdaemon stuff, which is undesirable as well.
>
> Why is that? This just uses python-apt, it needs a frontend no more or
> less than anything else that uses apt?
>
>> > aptdaemon does not reimplement apt, it provides the python-apt
>> > functionality over D-BUS (similar to PackageKit, but it's a lot faster
>> > on Ubuntu).
>>
>> I didn't mean re-implement the whole thing. ;-) But already we have
>> the QApt Worker which can do this, making duplication a needless
>> waste.
>
> I think we are just talking past each other: current u-d-common
> _enables_ PackageKit/aptdaemon to ask for "what package provides a
> driver for this device". It does not require you to use it (you can
> use the native UbuntuDrivers module). I was just explaining why the
> aptdaemon stuff is there.

Ah, ok. I think it was just a misunderstanding about whether or not
aptdaemon was a requirement, due to its status as a hard dependency.
Glad to see that resolved, and no hard feelings at any rate. I was
just a bit annoyed at the (apparent at the time) unilateral
introduction of a new dependency that duplicated existing
functionality to a core package, without any discussion, so I'm sorry
if I came off as a bit terse in my replies.

>
>> QApt is perfectly capable of providing installation stuff over DBus,
>> so it would be better from a dependencies/ISO space standpoint.
>
> Sounds fine.
>
>> Do you know if ubuntu-drivers-common currently supports multiple
>> backends, and if it could be made to do so?
>
> u-d-common is a backend already. It currently provides these
> interfaces:
>
> ** Native UbuntuDrivers Python module (Ubuntu specific)
> ** ubuntu-drivers CLI tool (Ubuntu specific)
> ** PackageKit "WhatProvides" API (upstream friendly for GUI
> * integration)
>
> Of course we can easily add QApt integration there, too. This is a
> native Ubuntu package which is meant to bundle all the Ubuntu specific
> knowledge and backends that we need to implement easy and
> non-distro-specific GUIs and integration for driver handling.
>
> So I guess the short answer is "yes" :-)

Nice. :-)

So if I understand correctly, detect.py currently loads a backend
plugin from /usr/share/ubuntu-drivers-common/detect/ (currently the
PackageKit plugin) and uses the what_provides_modalias() and
system_driver_packages() methods in PackageKit.py for discovering
which packages need to be installed? And then if I were to write a
backend for QApt I could write a analogous QApt.py that implements
those two functions and install that to
/usr/share/ubuntu-drivers-common/detect/?

>
>> Well then an aptdaemon dependency is really unwanted in this case.
>
> Right, understood. It should be gone with the next upload, sorry about
> that.

Thanks again.

>
> Thanks,
>
> Martin
> --
> Martin Pitt * * * * * * * * * * * *| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) *| Debian Developer *(www.debian.org)

Jonathan

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 07:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org