Overview of Jockey replacement; options for Kubuntu?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
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)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas-5
Hello,

On Fri, May 25, 2012 at 5:12 AM, Martin Pitt <[hidden email]> 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.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Jussi Schultink-2
Hi all

On Fri, May 25, 2012 at 4:09 PM, Jonathan Thomas <[hidden email]> wrote:

> Hello,
>
> On Fri, May 25, 2012 at 5:12 AM, Martin Pitt <[hidden email]> 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
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Hope my 2c are useful

Jussi

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
In reply to this post by Jonathan Thomas-5
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_cache, 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)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas-5
Hi,

On Tue, May 29, 2012 at 1:23 AM, Martin Pitt <[hidden email]> 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_cache, 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
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
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)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas-5
Hello,

On Wed, May 30, 2012 at 1:07 AM, Martin Pitt <[hidden email]> 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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
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)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas-5
Hi,

On Wed, May 30, 2012 at 9:21 AM, Martin Pitt <[hidden email]> 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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
Hello Jonathan,

Jonathan Thomas [2012-05-30  9:41 -0400]:
> Glad to see that resolved, and no hard feelings at any rate.

No worries :)

> 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?

UbuntuDrivers.detect is fully self-contained and only needs apt. What
it does is (1) finding all modaliases in the system by parsing /sys,
(2) mapping modaliases to packages with the help of packages'
"Modalises:" headers, and a few other stuff around that.

We try hard to make most packages just declare proper "Modaliases:"
headers. However, for some special cases that's not possible.
/usr/share/ubuntu-drivers-common/detect/ has python snippets that
these special cases can provide; for example, sl-modem-daemon needs to
decide whether or not it should be installed based on checks of
/proc/asound/cards and "aplay -l". But this should remain an internal
implementation detail of system_driver_packages().

The PackageKit plugin (UbuntuDrivers.PackageKit) is just an adapter to
use the what_provides_modalias() function (which is Ubuntu specific)
in PackageKit/aptdaemon, so that WhatProvides(MODALIAS, pci:12345)
works on Ubuntu; i. e.  PackageKit/aptdaemon will call
what_provides_modalias() through that plugin.

> 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/?

I don't think you need to write anything in that regard. If you
implement a GUI for KDE which displays available drivers and offers to
install them, you should either use the PackageKit WhatProvides() API
(which allows you to submit that code upstream, as it works for all
distros), or directly use the methods in UbuntuDrivers.detect (they do
not need any special privileges) to get the list of packages, and then
use QApt to get these packages installed.

Martin

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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Barry Warsaw-2
In reply to this post by Martin Pitt-4
On May 30, 2012, at 07:07 AM, Martin Pitt wrote:

>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.

Does this mean we can drop the jockey-common and jockey-gtk rows from the
Applications sheet of the Python 3 porting spreadsheet?

http://tinyurl.com/78ummch

?

If so, I think that means we can also drop python-xkit.

-Barry

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
Barry Warsaw [2012-05-30 10:20 -0400]:
> Does this mean we can drop the jockey-common and jockey-gtk rows from the
> Applications sheet of the Python 3 porting spreadsheet?

I very much hope so :)

> If so, I think that means we can also drop python-xkit.

No, u-d-common (i. e. the NVidia specific parts) still need it.

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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Dmitrijs Ledkovs-2
On 30/05/12 18:00, Martin Pitt wrote:
> Barry Warsaw [2012-05-30 10:20 -0400]:
>> Does this mean we can drop the jockey-common and jockey-gtk rows from the
>> Applications sheet of the Python 3 porting spreadsheet?
>
> I very much hope so :)
>

ok. Done. And tracker updated.

>> If so, I think that means we can also drop python-xkit.
>
> No, u-d-common (i. e. the NVidia specific parts) still need it.
>

Is that build in python3? Or with python3 in mind? And needs tracking?

--
Regards,
Dmitrijs.



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Steve Langasek-6
In reply to this post by Martin Pitt-4
Hi Martin,

On Tue, May 29, 2012 at 07:23:23AM +0200, Martin Pitt wrote:
> 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.

I have vague recollections that the reason we never adopted packagekit
itself was because it was designed for an RPM-centric world, an in
particular did not allow packages to interact with users (i.e., debconf and
conffile prompts), and packagekit upstream was not interested in
accomodating dpkg requirements.  Does using the PackageKit API introduce the
same limitations on package interaction?

Thanks,
--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas-5
Hi Steve,

On Wed, May 30, 2012 at 1:29 PM, Steve Langasek
<[hidden email]> wrote:

> Hi Martin,
>
> On Tue, May 29, 2012 at 07:23:23AM +0200, Martin Pitt wrote:
>> 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.
>
> I have vague recollections that the reason we never adopted packagekit
> itself was because it was designed for an RPM-centric world, an in
> particular did not allow packages to interact with users (i.e., debconf and
> conffile prompts), and packagekit upstream was not interested in
> accomodating dpkg requirements.  Does using the PackageKit API introduce the
> same limitations on package interaction?

Thanks to work by Daniel Nicoletti PackageKit now supports debconf in
its apt worker implementation. The aptcc backend supports debconf via
the passthrough DEBIAN_FRONTEND, specifically by setting the
DEBCONF_PIPE env var to the pipe of the debconf frontend currently in
use.

So technically the PackageKit still doesn't support things like
debconf from an API POV, but the PackageKit backend can provide
debconf via passthrough as part of the install. I'd assume that the
packagekit compatibility layer that aptdaemon has runs the debconf
stuff "behind the scenes" in regards to PK calls.

>
> Thanks,
> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                    http://www.debian.org/
> [hidden email]                                     [hidden email]
>
> --
> kubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Barry Warsaw-2
In reply to this post by Dmitrijs Ledkovs-2
On May 30, 2012, at 06:24 PM, Dmitrijs Ledkovs wrote:

>On 30/05/12 18:00, Martin Pitt wrote:
>> Barry Warsaw [2012-05-30 10:20 -0400]:
>>> Does this mean we can drop the jockey-common and jockey-gtk rows from the
>>> Applications sheet of the Python 3 porting spreadsheet?
>>
>> I very much hope so :)
>>
>
>ok. Done. And tracker updated.

Thanks!

>>> If so, I think that means we can also drop python-xkit.
>>
>> No, u-d-common (i. e. the NVidia specific parts) still need it.
>
>Is that build in python3? Or with python3 in mind? And needs tracking?

I'm not sure why it's not in the spreadsheet, but it's in the tracker under
dependency level 5.

-Barry

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Dmitrijs Ledkovs-2
On 30/05/12 19:02, Barry Warsaw wrote:

> On May 30, 2012, at 06:24 PM, Dmitrijs Ledkovs wrote:
>
>> On 30/05/12 18:00, Martin Pitt wrote:
>>> Barry Warsaw [2012-05-30 10:20 -0400]:
>>>> Does this mean we can drop the jockey-common and jockey-gtk rows from the
>>>> Applications sheet of the Python 3 porting spreadsheet?
>>>
>>> I very much hope so :)
>>>
>>
>> ok. Done. And tracker updated.
>
> Thanks!
>
>>>> If so, I think that means we can also drop python-xkit.
>>>
>>> No, u-d-common (i. e. the NVidia specific parts) still need it.
>>
>> Is that build in python3? Or with python3 in mind? And needs tracking?
>
> I'm not sure why it's not in the spreadsheet, but it's in the tracker under
> dependency level 5.
>
Ben - the tracker software is smart =)))

ubuntu-drivers-common
Dependencies: aptdaemon, packagekit, pygobject, x-kit

Awesome =)))

> -Barry
>
>
>


--
Regards,
Dmitrijs.



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
In reply to this post by Steve Langasek-6
Steve Langasek [2012-05-30 10:29 -0700]:
> I have vague recollections that the reason we never adopted packagekit
> itself was because it was designed for an RPM-centric world, an in
> particular did not allow packages to interact with users (i.e., debconf and
> conffile prompts), and packagekit upstream was not interested in
> accomodating dpkg requirements.  Does using the PackageKit API introduce the
> same limitations on package interaction?

No, it doesn't. While you can use the API from the actual PackageKit,
this is not what we are going to use. Since Oneiric or so we have an
aptdaemon compatibility layer (python-aptdaemon.pkcompat) which
provides the PK API in aptdaemon.

Also, this merely provides the detection, i. e. "which driver packages
do I need here". u-d-common has no code whatsoever to actually
install/remove packages, and there is no need to: We already have
python-apt, aptdaemon, sessioninstaller, QApt, and the PackageKit
APIs for that, after all.

Martin

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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Martin Pitt-4
In reply to this post by Jonathan Thomas-5
Jonathan Thomas [2012-05-30 13:37 -0400]:
> Thanks to work by Daniel Nicoletti PackageKit now supports debconf in
> its apt worker implementation.

Right, but NB that we don't actually need this. We only need to handle
a rather small and known set of packages here (such as
bcmwl-kernel-source and nvidia-current); none of those actually use
debconf, and it should stay that way. There is no reason to ask the
user any debconf question when he already made his choices in the
"hardware drivers" GUI.

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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Overview of Jockey replacement; options for Kubuntu?

Mario Limonciello-2
In reply to this post by Martin Pitt-4


On Fri, May 25, 2012 at 4:12 AM, Martin Pitt <[hidden email]> 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 ...).

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

I think a simpler code base is great.  I noticed that Jockey is still included in Quantal daily builds today.  Couple of related questions:

1) Once there is support directly in software center to indicate which packages support your hardware, will Jockey be dropped from ubuntu ISOs?

2) Have you considered expanding the auto_install_filter to also install the packages in the archive that improve the virtualization experience so that this is set up on first boot if appropriate?



--
Mario Limonciello
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
12