Re: Proposal: Automatic selection of hardware specific packages
[Julian Andres Klode] Ubuntu developed a tool called 'jockey' for installing hardware drivers. There is an ITP for it in Bug #436722. Jockey is in my opinion the best place to do something like this. I CCed Martin Pitt, the developer of jockey (and quoted the remaining parts of the email in case he did not read the original one). Yes, it was a nice tool. I tested it for the first time a few weeks ago. I noticed in #436722 that Martin Pitt was positive to shared maintenance. What is holding you from uploading the package to Debian? The ITP haven't seen any progress for a long time. :) Note that I GUI tool would be nice for the non-free stuff, but would be a bad idea for other hardware specific packages like RAID administration tools. For this, I would like to integrate something like discover-pkginstall into the hwsetup package in debian-installer, to make sure hardware specific packages are automatically installed when it make sense. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flhbnrxxkm@login2.uio.no
Re: Proposal: Automatic selection of hardware specific packages
Hi, If you actually want a student to look at your proposal, please put it on the wiki :) http://wiki.debian.org/gsoc Cheers Arthur On Sun, Apr 4, 2010 at 1:32 PM, Petter Reinholdtsen p...@hungry.com wrote: [Julian Andres Klode] Ubuntu developed a tool called 'jockey' for installing hardware drivers. There is an ITP for it in Bug #436722. Jockey is in my opinion the best place to do something like this. I CCed Martin Pitt, the developer of jockey (and quoted the remaining parts of the email in case he did not read the original one). Yes, it was a nice tool. I tested it for the first time a few weeks ago. I noticed in #436722 that Martin Pitt was positive to shared maintenance. What is holding you from uploading the package to Debian? The ITP haven't seen any progress for a long time. :) Note that I GUI tool would be nice for the non-free stuff, but would be a bad idea for other hardware specific packages like RAID administration tools. For this, I would like to integrate something like discover-pkginstall into the hwsetup package in debian-installer, to make sure hardware specific packages are automatically installed when it make sense. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flhbnrxxkm@login2.uio.no -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/u2vc09ddae71004040437g619dacddq65461829b49fb...@mail.gmail.com
Re: Proposal: Automatic selection of hardware specific packages
[Guillem Jover] I've had this idea in my head for long, but as never found the time to work on it, didn't feel appropriate to throw it to the wall and expect someone else to implement it. Anyway, it seems to me it might be a nice GSoC project, and not necessarily too complex. As I've my plate already full, I'm not volunteering myself for mentoring, though. I'm CCing de...@l.d.o as they should be in the loop and Petter as he was working on integrating package data into discover-data at some point in the past, which might be interested in mentoring. Yeah. Note that part of your propopsal is already implemented in discover/discover-data, and the /sbin/discover-pkginstall script will install hardware dependent packages. It can for example install raid monitoring software when a supported raid is detected. It might provide a starting point. :) Keeping the mapping from hardware to packages up to date is a hard problem without cooperation from the various package maintainers, and some hardware is hard to detect, but for the easy stuff (PCI and USB), the implementation is trivial. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100403210921.gc14...@login2.uio.no
Re: Proposal: Automatic selection of hardware specific packages
On Mon, Mar 29, 2010 at 11:51:54PM +0200, Guillem Jover wrote: Hi! I've had this idea in my head for long, but as never found the time to work on it, didn't feel appropriate to throw it to the wall and expect someone else to implement it. Anyway, it seems to me it might be a nice GSoC project, and not necessarily too complex. As I've my plate already full, I'm not volunteering myself for mentoring, though. I'm CCing de...@l.d.o as they should be in the loop and Petter as he was working on integrating package data into discover-data at some point in the past, which might be interested in mentoring. Problem ~~~ I've always found it annoying that it's become very difficult to hunt all packages that might be needed for or useful with the current hardware on the system, and usually you tend to miss some. It might be even trickier for non-technical users who might not even know they need specific packages for something to work. Proposal Ideally the package manager front-ends would propose for installation to the user all hardware related packages for currently detected hardware in the system, or removal once such hardware is not present (although that might need to be disabled for pluggable hardware). This could include drivers, firmware, tools and applications [0]. There's a distinction between packages that are required for something to work, which could be handled somehow as Recommends, and packages which might have additional functionality if the hardware is present, which could be handled as Suggests. Ubuntu developed a tool called 'jockey' for installing hardware drivers. There is an ITP for it in Bug #436722. Jockey is in my opinion the best place to do something like this. I CCed Martin Pitt, the developer of jockey (and quoted the remaining parts of the email in case he did not read the original one). Each package would provide a list of patterns for the hardware it supports. Depending on their size, they could be provided in a new field (for example Hardware-Id), or on a new control file (but then that would need to get extracted from binary packages and collected into a foo-data package for example) or something else. Those patterns would match against the device IDs of cpu, pci, pnp, usb, eisa, dmi, pcmcia, acpi, ieee1394, etc. For some packages this information is already known, and can be automatically extracted from some files (and possibly converted to the chosen pattern format). For example X.Org drivers have an internal list of patterns, not sure if those can be easily extracted, for Linux kernel modules one can extract those with something like: ,--- |PATH=/sbin:$PATH | |find -name '*.ko' | xargs modinfo -F alias | \ | egrep '^(pci|pnp|eisa|pcmcia|usb|acpi|dmi|ieee1394|ssb|wmi):' `--- [0] An incomplete list from when I looked into this could include: Drivers --- xserver-xorg-video-*, xserver-xorg-input-*, *-source, firmware-* Tools - Graphic cards: gatos, radeontool, rovclock, atitvout, s3switch, i810switch, matroxset, nvclock, nvtv, libglide3. Sound cards: awesfx, ld10k1. Webcams: qcam, qpcr1k, pencam. CPUs: athcool, set6x86. Laptops: i8kutils, fnfxd, fnfx-client, toshset, toshutils, tpb, spicctrl. Printers: foomatic-db-hpijs, hpijs, hplip, hpoj. SCSI: scsitools, sg-utils. Design and Implementation ~ Things to decide and work on, would include: * The format of the patterns for each hardware type. There's existing examples that could be either reused or based for inspiration. * A tool to extract at package build time as much of the IDs as possible from existing files and convert them to the normalized form, if need be. (Ideally independent of any packaging helper.) * Consider and decide where to ship such information. * It might be a good idea to be able to have a global override, for testing purposes, and a faster initial deployment, once a working implementation is in place those could be moved to each package. * Decide how to make the front-ends use the information, for example by creating a shared library that does the detection and matching, and just returns the list of packages, or through an external program (say a new hwsel, or maybe just adapting and/or extending disover or any of the other hardware detectors to be easily integrated with the front-ends), etc. * The actual integration with the front-ends. regards, guillem -- To UNSUBSCRIBE, email to deity-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329215154.ga30...@gaara.hadrons.org -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgp8wW4Sa5mV0.pgp Description: PGP signature
Proposal: Automatic selection of hardware specific packages
Hi! I've had this idea in my head for long, but as never found the time to work on it, didn't feel appropriate to throw it to the wall and expect someone else to implement it. Anyway, it seems to me it might be a nice GSoC project, and not necessarily too complex. As I've my plate already full, I'm not volunteering myself for mentoring, though. I'm CCing de...@l.d.o as they should be in the loop and Petter as he was working on integrating package data into discover-data at some point in the past, which might be interested in mentoring. Problem ~~~ I've always found it annoying that it's become very difficult to hunt all packages that might be needed for or useful with the current hardware on the system, and usually you tend to miss some. It might be even trickier for non-technical users who might not even know they need specific packages for something to work. Proposal Ideally the package manager front-ends would propose for installation to the user all hardware related packages for currently detected hardware in the system, or removal once such hardware is not present (although that might need to be disabled for pluggable hardware). This could include drivers, firmware, tools and applications [0]. There's a distinction between packages that are required for something to work, which could be handled somehow as Recommends, and packages which might have additional functionality if the hardware is present, which could be handled as Suggests. Each package would provide a list of patterns for the hardware it supports. Depending on their size, they could be provided in a new field (for example Hardware-Id), or on a new control file (but then that would need to get extracted from binary packages and collected into a foo-data package for example) or something else. Those patterns would match against the device IDs of cpu, pci, pnp, usb, eisa, dmi, pcmcia, acpi, ieee1394, etc. For some packages this information is already known, and can be automatically extracted from some files (and possibly converted to the chosen pattern format). For example X.Org drivers have an internal list of patterns, not sure if those can be easily extracted, for Linux kernel modules one can extract those with something like: ,--- |PATH=/sbin:$PATH | |find -name '*.ko' | xargs modinfo -F alias | \ | egrep '^(pci|pnp|eisa|pcmcia|usb|acpi|dmi|ieee1394|ssb|wmi):' `--- [0] An incomplete list from when I looked into this could include: Drivers --- xserver-xorg-video-*, xserver-xorg-input-*, *-source, firmware-* Tools - Graphic cards: gatos, radeontool, rovclock, atitvout, s3switch, i810switch, matroxset, nvclock, nvtv, libglide3. Sound cards: awesfx, ld10k1. Webcams: qcam, qpcr1k, pencam. CPUs: athcool, set6x86. Laptops: i8kutils, fnfxd, fnfx-client, toshset, toshutils, tpb, spicctrl. Printers: foomatic-db-hpijs, hpijs, hplip, hpoj. SCSI: scsitools, sg-utils. Design and Implementation ~ Things to decide and work on, would include: * The format of the patterns for each hardware type. There's existing examples that could be either reused or based for inspiration. * A tool to extract at package build time as much of the IDs as possible from existing files and convert them to the normalized form, if need be. (Ideally independent of any packaging helper.) * Consider and decide where to ship such information. * It might be a good idea to be able to have a global override, for testing purposes, and a faster initial deployment, once a working implementation is in place those could be moved to each package. * Decide how to make the front-ends use the information, for example by creating a shared library that does the detection and matching, and just returns the list of packages, or through an external program (say a new hwsel, or maybe just adapting and/or extending disover or any of the other hardware detectors to be easily integrated with the front-ends), etc. * The actual integration with the front-ends. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329215154.ga30...@gaara.hadrons.org
Re: Proposal: Automatic selection of hardware specific packages
On Mon, 2010-03-29 at 23:51 +0200, Guillem Jover wrote: Hi! I've had this idea in my head for long, but as never found the time to work on it, didn't feel appropriate to throw it to the wall and expect someone else to implement it. Anyway, it seems to me it might be a nice GSoC project, and not necessarily too complex. As I've my plate already full, I'm not volunteering myself for mentoring, though. I'm CCing de...@l.d.o as they should be in the loop and Petter as he was working on integrating package data into discover-data at some point in the past, which might be interested in mentoring. Problem ~~~ I've always found it annoying that it's become very difficult to hunt all packages that might be needed for or useful with the current hardware on the system, and usually you tend to miss some. It might be even trickier for non-technical users who might not even know they need specific packages for something to work. [...] There are also some hardware-specific drivers and tools that may be useful to some users but should not be recommended because they depend on out-of-tree kernel drivers that conflict with the in-tree drivers. Any solution should avoid conflating 'works with this device' and 'recommended on systems with this device'. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Proposal: Automatic selection of hardware specific packages
Ideally the package manager front-ends would propose for installation to the user all hardware related packages for currently detected hardware in the system, or removal once such hardware is not present (although that might need to be disabled for pluggable hardware). The implementation would IMO also to some extend need to be aware of the environment into which the installation is taking place. On a Gnome desktop system it should propose Gnome packages, on a KDE desktop system it should propose equivalent KDE packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003300219.27189.elen...@planet.nl
