After over a year since the last release, I'd like to announce the
release of usbutils 0.81. It can be found at the traditionally horrible
sf.net download page:
https://sourceforge.net/project/showfiles.php?group_id=3581
We've switched over to using git for development now, which makes things
much easier than the old cvs tree. The tree can be found on both
kernel.org and github.com if you want to fork it and send us changes
easier:
http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git
http://github.com/gregkh/usbutils/tree/master
I've pushed all patches that were in the Gentoo and SuSE usbutils trees
into this release. If there are outstanding patches from other distros,
I'd be very interested in getting them integrated in.
thanks,
greg k-h
-----------
Shortlog of changes since last release (0.73):
Bj?rn Mork (1):
usbutils: Adding support for Device Firmware Upgrade functional descriptors
David Brownell (9):
Update ChangeLog Ran autoreconf (for version 0.73).
Make "update-usbids.sh" work better from cronjobs; update usb.ids
Build on FreeBSD
Use autotools for FreeBSD support; autoreconf. Grab the latest usb.ids file.
use AC_C_BIGENDIAN, update usb.ids, minor layout fix, autoreconf
refresh usb.ids
Add libusb compat code
refresh usb.ids
add attribution omitted from a few years back
Greg Kroah-Hartman (12):
added .gitignore
update usb.ids based on Stephen's latest version
fix compile warning in lsusb.c
fix compile warning in usbmisc.c
update .gitignore
Add PTP gadget id for the Linux Foundation vendor id.
Note in the ChangeLog to look at the git changelog instead.
fix patch corruption in DFU patch
lsusb: make strtoul to use base 10
lsusb: make -t option work if proc file is not present.
lsusb.8 - remove old comments and /proc/bus/usb lines
0.81 release
Kay Sievers (11):
rename configure.in -> configure.ac
delete spec file
delete generated autotools file
update usb.ids
clean up autotools files
remove autotools cache on distclean
bump version to 0.80 to pass "make distcheck"
fix wrong copy-pasted mail address
remove obsolete usbmodules
delete .cvsignore
/proc/bus/usb -> /dev/bus/usb
On Mon, 27 Apr 2009, Greg KH wrote:
> Kay Sievers (11):
> rename configure.in -> configure.ac
> delete spec file
Why delete the spec file? Don't you want to keep it for people who
would like to build an RPM?
Alan Stern
On Mon, Apr 27, 2009 at 04:48:00PM -0400, Alan Stern wrote:
> On Mon, 27 Apr 2009, Greg KH wrote:
>
> > Kay Sievers (11):
> > rename configure.in -> configure.ac
> > delete spec file
>
> Why delete the spec file? Don't you want to keep it for people who
> would like to build an RPM?
Do people build rpms out of tarballs that aren't coming from their
distro anymore? I didn't realise this, and can put it back, but it's
one more thing to forget to bump the version number on :(
thanks,
greg k-h
On Mon, Apr 27, 2009 at 22:48, Alan Stern <[email protected]> wrote:
> On Mon, 27 Apr 2009, Greg KH wrote:
>
>> Kay Sievers (11):
>> rename configure.in -> configure.ac
>> delete spec file
>
> Why delete the spec file? Don't you want to keep it for people who
> would like to build an RPM?
Spec files are much too distro specific, they all contain custom
distro variables, reference package names which are not the same
across distros. They usually don't even agree on the directories the
stuff is installed into. The usb.ids file as an example, is in a
different location on every distro i have seen. :)
There is in most cases no point in keeping outdated spec files or
debian directories in upstream source packages. The best when updating
a package, is to start with the one that is in the source rpm of the
distro one uses.
Thanks,
Kay
On Mon, 27 Apr 2009, Greg KH wrote:
> On Mon, Apr 27, 2009 at 04:48:00PM -0400, Alan Stern wrote:
> > On Mon, 27 Apr 2009, Greg KH wrote:
> >
> > > Kay Sievers (11):
> > > rename configure.in -> configure.ac
> > > delete spec file
> >
> > Why delete the spec file? Don't you want to keep it for people who
> > would like to build an RPM?
>
> Do people build rpms out of tarballs that aren't coming from their
> distro anymore?
Sure they do. If you've got an RPM-based system, and you want to
install a package version that's more recent than the one bundled in
your distribution (or if your distribution doesn't include the package
at all), then you'd want to build your own RPM.
> I didn't realise this, and can put it back, but it's
> one more thing to forget to bump the version number on :(
It's not urgent. You're going to be making other changes too... new
output formats and replacing libusb, right? So include the spec file
again when you do the next release.
(BTW, the spec file probably wants a little updating anyhow to match
the changes you and Kay have been doing. Not to mention that older
versions of RPM used a different specification for the kind of
licensing -- IIRC, the old RPM used a "copyright" tag whereas the
current RPM uses a "license" tag.)
Alan Stern
On Mon, Apr 27, 2009 at 23:21, Alan Stern <[email protected]> wrote:
> On Mon, 27 Apr 2009, Greg KH wrote:
>
>> On Mon, Apr 27, 2009 at 04:48:00PM -0400, Alan Stern wrote:
>> > On Mon, 27 Apr 2009, Greg KH wrote:
>> >
>> > > Kay Sievers (11):
>> > > rename configure.in -> configure.ac
>> > > delete spec file
>> >
>> > Why delete the spec file? Don't you want to keep it for people who
>> > would like to build an RPM?
>>
>> Do people build rpms out of tarballs that aren't coming from their
>> distro anymore?
>
> Sure they do. If you've got an RPM-based system, and you want to
> install a package version that's more recent than the one bundled in
> your distribution (or if your distribution doesn't include the package
> at all), then you'd want to build your own RPM.
>
>> I didn't realise this, and can put it back, but it's
>> one more thing to forget to bump the version number on :(
>
> It's not urgent. You're going to be making other changes too... new
> output formats and replacing libusb, right? So include the spec file
> again when you do the next release.
Having a spec file in the repo needs configure.ac pre-processing to
create a proper spec file to use, to find out where to install the
files. As an example, SUSE puts the ids file in /usr/share/ Fedora in
/usr/share/hwdata/ (not even shipped with the usbutil package), other
distros put it in /usr/share/misc/.
Having multiple files installed, because we didn't find the right
place, may break other packages build which search for them at build
time, like udev-extras.
There is really not a good chance to get this stuff right, without
using the spec file that comes with the original package from the
distro that is used.
Thanks,
Kay
On Mon, 27 Apr 2009, Kay Sievers wrote:
> On Mon, Apr 27, 2009 at 22:48, Alan Stern <[email protected]> wrote:
> > On Mon, 27 Apr 2009, Greg KH wrote:
> >
> >> Kay Sievers (11):
> >> rename configure.in -> configure.ac
> >> delete spec file
> >
> > Why delete the spec file? Don't you want to keep it for people who
> > would like to build an RPM?
>
> Spec files are much too distro specific, they all contain custom
> distro variables, reference package names which are not the same
> across distros. They usually don't even agree on the directories the
> stuff is installed into. The usb.ids file as an example, is in a
> different location on every distro i have seen. :)
>
> There is in most cases no point in keeping outdated spec files or
> debian directories in upstream source packages. The best when updating
> a package, is to start with the one that is in the source rpm of the
> distro one uses.
But what if the distro doesn't ship that package at all? Then it's
good to at least have a starting point that you can adapt to your own
needs. (Although I don't know of any major distributions that doesn't
include usbutils...)
This isn't a big deal. If you and Greg don't want to include a spec
file then don't.
Alan Stern
On Mon, Apr 27, 2009 at 23:54, Alan Stern <[email protected]> wrote:
> On Mon, 27 Apr 2009, Kay Sievers wrote:
>> There is in most cases no point in keeping outdated spec files or
>> debian directories in upstream source packages. The best when updating
>> a package, is to start with the one that is in the source rpm of the
>> distro one uses.
>
> But what if the distro doesn't ship that package at all? Then it's
> good to at least have a starting point that you can adapt to your own
> needs. (Although I don't know of any major distributions that doesn't
> include usbutils...)
Maybe add a link to a distro spec file in the README? So this gets
updated automatically by the people who do the packaging? Like this:
http://cvs.fedora.redhat.com/viewvc/devel/usbutils/usbutils.spec?revision=HEAD
Kay
Alan Stern <stern-nwvwT67g6+6dFdvTe/[email protected]>
writes:
> Sure they do. If you've got an RPM-based system, and you want to
> install a package version that's more recent than the one bundled in
> your distribution (or if your distribution doesn't include the package
> at all), then you'd want to build your own RPM.
In that case you grab the source package from the distribution, install
it, bump the version number and add the tar file to the SOURCES
directory. (And then you remove the patches which were upstreamed in the
meantime).
It isn't as easy as rpmbuild -ta, but it gets everything placed in the
right location and it preserves the distro-specific patches.
/Benny
On Wed, 29 Apr 2009, Benny Amorsen wrote:
> Alan Stern <stern-nwvwT67g6+6dFdvTe/[email protected]>
> writes:
>
> > Sure they do. If you've got an RPM-based system, and you want to
> > install a package version that's more recent than the one bundled in
> > your distribution (or if your distribution doesn't include the package
> > at all), then you'd want to build your own RPM.
>
> In that case you grab the source package from the distribution, install
> it, bump the version number and add the tar file to the SOURCES
> directory. (And then you remove the patches which were upstreamed in the
> meantime).
You didn't read all that I wrote. What if the package isn't included
in the distribution at all?
Alan Stern
On Mon, Apr 27, 2009 at 15:35, Greg KH wrote:
> After over a year since the last release, I'd like to announce the
> release of usbutils 0.81. It can be found at the traditionally horrible
> sf.net download page:
> https://sourceforge.net/project/showfiles.php?group_id=3581
>
> We've switched over to using git for development now, which makes things
> much easier than the old cvs tree. The tree can be found on both
> kernel.org and github.com if you want to fork it and send us changes
> easier:
> http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git
> http://github.com/gregkh/usbutils/tree/master
>
> I've pushed all patches that were in the Gentoo and SuSE usbutils trees
> into this release. If there are outstanding patches from other distros,
> I'd be very interested in getting them integrated in.
looks like update-usbids.sh was forgotten from EXTRA_DIST in
Makefile.am so the released tarball doesnt have the script ;(
having to manually run `sed` on the scripts/man pages is annoying when
moving the ids file ... any chance of converting those to normal
configure generated files ? or is there hard resistance to that ?
i see `usbmodules` has been punted. was there a reason for that ? i
find being able to run `usbmodules` pretty useful ... i wrote a script
for fun:
http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
-mike
On Wed, Apr 29, 2009 at 01:53:32PM -0400, Mike Frysinger wrote:
> On Mon, Apr 27, 2009 at 15:35, Greg KH wrote:
> > After over a year since the last release, I'd like to announce the
> > release of usbutils 0.81. ?It can be found at the traditionally horrible
> > sf.net download page:
> > ? ? ? ?https://sourceforge.net/project/showfiles.php?group_id=3581
> >
> > We've switched over to using git for development now, which makes things
> > much easier than the old cvs tree. ?The tree can be found on both
> > kernel.org and github.com if you want to fork it and send us changes
> > easier:
> > ? ? ? ?http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git
> > ? ? ? ?http://github.com/gregkh/usbutils/tree/master
> >
> > I've pushed all patches that were in the Gentoo and SuSE usbutils trees
> > into this release. ?If there are outstanding patches from other distros,
> > I'd be very interested in getting them integrated in.
>
> looks like update-usbids.sh was forgotten from EXTRA_DIST in
> Makefile.am so the released tarball doesnt have the script ;(
Care to send a patch?
> having to manually run `sed` on the scripts/man pages is annoying when
> moving the ids file ... any chance of converting those to normal
> configure generated files ? or is there hard resistance to that ?
No objection from me, have a patch? :)
> i see `usbmodules` has been punted. was there a reason for that ?
It was for 2.4 kernels only.
> find being able to run `usbmodules` pretty useful ... i wrote a script
> for fun:
> http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
Did that work on any 2.6 kernel?
There's no reason we can't add "-k" support to lsusb like lspci has to
show the modules assigned to different devices.
thanks,
greg k-h
On Wed, Apr 29, 2009 at 14:07, Greg KH wrote:
> On Wed, Apr 29, 2009 at 01:53:32PM -0400, Mike Frysinger wrote:
>> On Mon, Apr 27, 2009 at 15:35, Greg KH wrote:
>> > After over a year since the last release, I'd like to announce the
>> > release of usbutils 0.81. It can be found at the traditionally horrible
>> > sf.net download page:
>> > https://sourceforge.net/project/showfiles.php?group_id=3581
>> >
>> > We've switched over to using git for development now, which makes things
>> > much easier than the old cvs tree. The tree can be found on both
>> > kernel.org and github.com if you want to fork it and send us changes
>> > easier:
>> > http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git
>> > http://github.com/gregkh/usbutils/tree/master
>> >
>> > I've pushed all patches that were in the Gentoo and SuSE usbutils trees
>> > into this release. If there are outstanding patches from other distros,
>> > I'd be very interested in getting them integrated in.
>>
>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
>> Makefile.am so the released tarball doesnt have the script ;(
>
> Care to send a patch?
>
>> having to manually run `sed` on the scripts/man pages is annoying when
>> moving the ids file ... any chance of converting those to normal
>> configure generated files ? or is there hard resistance to that ?
>
> No objection from me, have a patch? :)
np, i'll send patches for both
>> i see `usbmodules` has been punted. was there a reason for that ?
>
> It was for 2.4 kernels only.
that's a good reason :)
>> find being able to run `usbmodules` pretty useful ... i wrote a script
>> for fun:
>> http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
>
> Did that work on any 2.6 kernel?
it's the only version ive tested it with ... but it doesnt parse any
kernel module directly, it reads the generated modules.usbmap file
> There's no reason we can't add "-k" support to lsusb like lspci has to
> show the modules assigned to different devices.
the method i posted above only needs the module to be compiled, not loaded
-mike
On Wed, Apr 29, 2009 at 02:17:12PM -0400, Mike Frysinger wrote:
> >> find being able to run `usbmodules` pretty useful ... i wrote a script
> >> for fun:
> >> http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
> >
> > Did that work on any 2.6 kernel?
>
> it's the only version ive tested it with ... but it doesnt parse any
> kernel module directly, it reads the generated modules.usbmap file
>
> > There's no reason we can't add "-k" support to lsusb like lspci has to
> > show the modules assigned to different devices.
>
> the method i posted above only needs the module to be compiled, not loaded
As the map files are depreciated, I wouldn't continue to rely on it, it
will break in the future when the kernel stops generating those files.
thanks,
greg k-h
On Wed, Apr 29, 2009 at 11:51:12AM -0400, Alan Stern wrote:
>
>
>
> On Wed, 29 Apr 2009, Benny Amorsen wrote:
>
> > Alan Stern <stern-nwvwT67g6+6dFdvTe/[email protected]>
> > writes:
> >
> > > Sure they do. If you've got an RPM-based system, and you want to
> > > install a package version that's more recent than the one bundled in
> > > your distribution (or if your distribution doesn't include the package
> > > at all), then you'd want to build your own RPM.
> >
> > In that case you grab the source package from the distribution, install
> > it, bump the version number and add the tar file to the SOURCES
> > directory. (And then you remove the patches which were upstreamed in the
> > meantime).
>
> You didn't read all that I wrote. What if the package isn't included
> in the distribution at all?
What rpm based distro does not have usbutils?
Just curious,
greg k-h
On Wed, Apr 29, 2009 at 11:51, Alan Stern wrote:
> On Wed, 29 Apr 2009, Benny Amorsen wrote:
>> Alan Stern writes:
>> > Sure they do. If you've got an RPM-based system, and you want to
>> > install a package version that's more recent than the one bundled in
>> > your distribution (or if your distribution doesn't include the package
>> > at all), then you'd want to build your own RPM.
>>
>> In that case you grab the source package from the distribution, install
>> it, bump the version number and add the tar file to the SOURCES
>> directory. (And then you remove the patches which were upstreamed in the
>> meantime).
>
> You didn't read all that I wrote. What if the package isn't included
> in the distribution at all?
install a different distro. any distro even remotely worth its salt
is going to package usbutils. this is a devils advocate question, not
anything resembling reality.
otherwise, anyone who is going to build a rpm should be familiar with
the myriad of possibilities out there that handle exactly this case
(such as checkinstall).
-mike
On Wed, Apr 29, 2009 at 20:17, Mike Frysinger <[email protected]> wrote:
>>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
>>> Makefile.am so the released tarball doesnt have the script ;(
> np, i'll send patches for both
Ah missed that, sorry. Sounds good if you add it to the tarball, but
please don't add it to "make install", as packages should not ship
scripts which change the installed package content, unless it's a
config file.
Thanks,
Kay
On Wed, 29 Apr 2009, Kay Sievers wrote:
> >>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
> >>> Makefile.am so the released tarball doesnt have the script ;(
>
> > np, i'll send patches for both
>
> Ah missed that, sorry. Sounds good if you add it to the tarball, but
> please don't add it to "make install", as packages should not ship
> scripts which change the installed package content, unless it's a
> config file.
Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
Both have working "update-usbids" scripts (might be the one from upstream,
or something different). They also have the original file in /usr/share, I
don't know if usbutils was changed to check /var first then /usr, or what.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Wed, Apr 29, 2009 at 21:18, Henrique de Moraes Holschuh
<[email protected]> wrote:
> On Wed, 29 Apr 2009, Kay Sievers wrote:
>> >>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
>> >>> Makefile.am so the released tarball doesnt have the script ;(
>>
>> > np, i'll send patches for both
>>
>> Ah missed that, sorry. Sounds good if you add it to the tarball, but
>> please don't add it to "make install", as packages should not ship
>> scripts which change the installed package content, unless it's a
>> config file.
>
> Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
> Both have working "update-usbids" scripts (might be the one from upstream,
> or something different). They also have the original file in /usr/share, I
> don't know if usbutils was changed to check /var first then /usr, or what.
Having several files on the same system sounds crazy from a distro
standpoint. There needs to be only a single database by default. Users
can do whatever they want anyway, but packages should not support such
a thing.
If the user updates it, what does a new ids file do? Overwrite it
unconditionally? Keep the old outdated hanging around, and lsusb does
not pick the new one up? That sounds like total a mess.
Thanks,
Kay
On Wed, Apr 29, 2009 at 08:59:31PM +0200, Kay Sievers wrote:
> On Wed, Apr 29, 2009 at 20:17, Mike Frysinger <[email protected]> wrote:
>
> >>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
> >>> Makefile.am so the released tarball doesnt have the script ;(
>
> > np, i'll send patches for both
>
> Ah missed that, sorry. Sounds good if you add it to the tarball, but
> please don't add it to "make install", as packages should not ship
> scripts which change the installed package content, unless it's a
> config file.
Distros ship uppdate-usbids.sh, like they do the same for the pci ids
file. And you can consider the usb.ids file a "config file" :)
thanks,
greg k-h
On Wed, Apr 29, 2009 at 04:18:41PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 29 Apr 2009, Kay Sievers wrote:
> > >>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
> > >>> Makefile.am so the released tarball doesnt have the script ;(
> >
> > > np, i'll send patches for both
> >
> > Ah missed that, sorry. Sounds good if you add it to the tarball, but
> > please don't add it to "make install", as packages should not ship
> > scripts which change the installed package content, unless it's a
> > config file.
>
> Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
> Both have working "update-usbids" scripts (might be the one from upstream,
> or something different). They also have the original file in /usr/share, I
> don't know if usbutils was changed to check /var first then /usr, or what.
Yeah, I was looking into doing some kind of "where to look first" type
thing like lspci does.
Any suggestions? Specific directory locations and hierarchy that
distros are already using?
thanks,
greg k-h
On Wed, Apr 29, 2009 at 21:26, Greg KH <[email protected]> wrote:
> On Wed, Apr 29, 2009 at 04:18:41PM -0300, Henrique de Moraes Holschuh wrote:
>> On Wed, 29 Apr 2009, Kay Sievers wrote:
>> > >>> looks like update-usbids.sh was forgotten from EXTRA_DIST in
>> > >>> Makefile.am so the released tarball doesnt have the script ;(
>> >
>> > > np, i'll send patches for both
>> >
>> > Ah missed that, sorry. Sounds good if you add it to the tarball, but
>> > please don't add it to "make install", as packages should not ship
>> > scripts which change the installed package content, unless it's a
>> > config file.
>>
>> Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
>> Both have working "update-usbids" scripts (might be the one from upstream,
>> or something different). They also have the original file in /usr/share, I
>> don't know if usbutils was changed to check /var first then /usr, or what.
>
> Yeah, I was looking into doing some kind of "where to look first" type
> thing like lspci does.
>
> Any suggestions? Specific directory locations and hierarchy that
> distros are already using?
Yeah, don't do it. There should be only a single place for it. This is
the reason udev rules are no longer in /etc, it is a nightmare to
support people thinking of "databases" as config files, they are not.
If you want to do that, introduce a directory, and merge all the the
entries based on the file order, then people can drop their content to
merge/overwrite there, but please don't do this with a single file
database.
You also really don't want to mark it in the package as a config file,
it should be overwritten with every package update, as long as there
is a single file only.
Thanks,
Kay
On Wed, 29 Apr 2009, Kay Sievers wrote:
> > Debian places it in /var/lib/usbids/ for a good reason. ?So does Ubuntu.
> > Both have working "update-usbids" scripts (might be the one from upstream,
> > or something different). ?They also have the original file in /usr/share, I
> > don't know if usbutils was changed to check /var first then /usr, or what.
>
> Having several files on the same system sounds crazy from a distro
> standpoint. There needs to be only a single database by default. Users
We are talking about two files, here. Not several.
> can do whatever they want anyway, but packages should not support such
> a thing.
If they are to be useful, yes, they do. Or do you want us to package just
the usb-ids text file by itself and keep updating it all the time? That's
the only other possibility, and it is done for the tzdata.
But update-usbids (like update-pciids and update-intel-microcode) works just
fine, so likely the usbutils maintainer didn't have any reasons to move from
update-usbids to a volatile package.
> If the user updates it, what does a new ids file do? Overwrite it
Well, the package overwrites the older one if the download suceeds with a
mv. No mess. If the download fails, the temp file is removed, and the
older one remains untouched.
There is no mess here. And it might be a simple case of the package
creating /var/lib/usbids/usb.ids at post-install time from the static
packaged data, and usbutils always using just /var/lib/usbids/usb.ids. I am
not the maintainer of that package, and sincerely, given your tone, I am not
inclined to go fetch the source and read the scripts.
Now, I am not sure there is any checking against partial downloads. That is
one thing a more controlled volatile package would be better at.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Wed, Apr 29, 2009 at 21:50, Henrique de Moraes Holschuh
<[email protected]> wrote:
> On Wed, 29 Apr 2009, Kay Sievers wrote:
>> > Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
>> > Both have working "update-usbids" scripts (might be the one from upstream,
>> > or something different). They also have the original file in /usr/share, I
>> > don't know if usbutils was changed to check /var first then /usr, or what.
>>
>> Having several files on the same system sounds crazy from a distro
>> standpoint. There needs to be only a single database by default. Users
>
> We are talking about two files, here. Not several.
>
>> can do whatever they want anyway, but packages should not support such
>> a thing.
>
> If they are to be useful, yes, they do. Or do you want us to package just
> the usb-ids text file by itself and keep updating it all the time? That's
> the only other possibility, and it is done for the tzdata.
>
> But update-usbids (like update-pciids and update-intel-microcode) works just
> fine, so likely the usbutils maintainer didn't have any reasons to move from
> update-usbids to a volatile package.
>
>> If the user updates it, what does a new ids file do? Overwrite it
>
> Well, the package overwrites the older one if the download suceeds with a
> mv. No mess. If the download fails, the temp file is removed, and the
> older one remains untouched.
>
> There is no mess here. And it might be a simple case of the package
> creating /var/lib/usbids/usb.ids at post-install time from the static
> packaged data, and usbutils always using just /var/lib/usbids/usb.ids. I am
> not the maintainer of that package, and sincerely, given your tone, I am not
> inclined to go fetch the source and read the scripts.
>
> Now, I am not sure there is any checking against partial downloads. That is
> one thing a more controlled volatile package would be better at.
And if your distro updates the package, it overwrites the changes you
did to the file, and they are lost?
Kay
On Wed, 29 Apr 2009, Kay Sievers wrote:
> And if your distro updates the package, it overwrites the changes you
> did to the file, and they are lost?
I suppose so, and not just for package updates: if you run update-usbids,
the old one is overwritten AFAIK. I didn't check the scripts, though. But
as a long time Debian Developer and user, that's what is implied by its
location in /var.
If local admin changes are to be preserved, Debian policy mandates that it
belongs on /etc.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
This thread is getting a bit ridiculous (especially with the annoying
GMANE redirections and challenges), and it's not an important issue, so
this will be my last word on the subject.
On Wed, 29 Apr 2009, Greg KH wrote:
> On Wed, Apr 29, 2009 at 11:51:12AM -0400, Alan Stern wrote:
> >
> >
> >
> > On Wed, 29 Apr 2009, Benny Amorsen wrote:
> >
> > > Alan Stern <stern-nwvwT67g6+6dFdvTe/[email protected]>
> > > writes:
> > >
> > > > Sure they do. If you've got an RPM-based system, and you want to
> > > > install a package version that's more recent than the one bundled in
> > > > your distribution (or if your distribution doesn't include the package
> > > > at all), then you'd want to build your own RPM.
> > >
> > > In that case you grab the source package from the distribution, install
> > > it, bump the version number and add the tar file to the SOURCES
> > > directory. (And then you remove the patches which were upstreamed in the
> > > meantime).
> >
> > You didn't read all that I wrote. What if the package isn't included
> > in the distribution at all?
>
> What rpm based distro does not have usbutils?
As far as I know, all of them have it.
But that's not the point. The point is this: The first quote above
("Sure they do...") was in response to Greg's question
Do people build rpms out of tarballs that aren't coming from
their distro anymore?
Although it was asked in the context of a discussion about usbutils, it
is a general question. (Notice that Benny's comment doesn't mention
usbutils either.) Consequently I gave a general answer.
Maybe this sounds like sophistry... and maybe it is. That's just the
way my mind works -- very literally at times.
Alan Stern
On Wed, Apr 29, 2009 at 22:00, Henrique de Moraes Holschuh
<[email protected]> wrote:
> On Wed, 29 Apr 2009, Kay Sievers wrote:
>> And if your distro updates the package, it overwrites the changes you
>> did to the file, and they are lost?
>
> I suppose so, and not just for package updates: if you run update-usbids,
> the old one is overwritten AFAIK. I didn't check the scripts, though. But
> as a long time Debian Developer and user, that's what is implied by its
> location in /var.
Ah, ok, that sounds fine, if that is still one and the same file, and
not a "lookup in several locations and pick one" logic.
> If local admin changes are to be preserved, Debian policy mandates that it
> belongs on /etc.
Sounds a bit special, but if that is the ways it works, and people
know that, it's fine I guess.
Thanks,
Kay
On Wed, 29 Apr 2009 12:23:09 PDT, Greg KH said:
> Distros ship uppdate-usbids.sh, like they do the same for the pci ids
> file. And you can consider the usb.ids file a "config file" :)
So my Fedora Rawhide box still has usbutils 0.73. I go snarf usbutils 0.81
from SourceForge and I find:
[~/src/usbutils-0.81] ls
AUTHORS Makefile.am aclocal.m4 depcomp list.h missing usbmisc.c
COPYING Makefile.in config.h.in devtree.c lsusb-t.c names.c usbmisc.h
ChangeLog NEWS configure devtree.h lsusb.8 names.h
INSTALL README configure.ac install-sh lsusb.c usb.ids
[~/src/usbutils-0.81] grep update-usb *
ChangeLog: * update-usbids.sh: add "-q" (quiet) option for cron jobs;
ChangeLog: * update-usbids.sh: add, based on update-pciids.sh
[~/src/usbutils-0.81]
So it's not in the tarball, and it's apparently not created by the Makefile.
So where is it?
On Wed, Apr 29, 2009 at 23:42, <[email protected]> wrote:
> On Wed, 29 Apr 2009 12:23:09 PDT, Greg KH said:
>
>> Distros ship uppdate-usbids.sh, like they do the same for the pci ids
>> file. And you can consider the usb.ids file a "config file" :)
>
> So my Fedora Rawhide box still has usbutils 0.73. I go snarf usbutils 0.81
> from SourceForge and I find:
>
> [~/src/usbutils-0.81] ls
> AUTHORS Makefile.am aclocal.m4 depcomp list.h missing usbmisc.c
> COPYING Makefile.in config.h.in devtree.c lsusb-t.c names.c usbmisc.h
> ChangeLog NEWS configure devtree.h lsusb.8 names.h
> INSTALL README configure.ac install-sh lsusb.c usb.ids
> [~/src/usbutils-0.81] grep update-usb *
> ChangeLog: * update-usbids.sh: add "-q" (quiet) option for cron jobs;
> ChangeLog: * update-usbids.sh: add, based on update-pciids.sh
> [~/src/usbutils-0.81]
>
> So it's not in the tarball, and it's apparently not created by the Makefile.
>
> So where is it?
Only in the source tree:
http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git;a=tree
not in the tarball. Next version will have it.
Kay
On Wed, Apr 29, 2009 at 05:42:53PM -0400, [email protected] wrote:
> On Wed, 29 Apr 2009 12:23:09 PDT, Greg KH said:
>
> > Distros ship uppdate-usbids.sh, like they do the same for the pci ids
> > file. And you can consider the usb.ids file a "config file" :)
>
> So my Fedora Rawhide box still has usbutils 0.73. I go snarf usbutils 0.81
> from SourceForge and I find:
>
> [~/src/usbutils-0.81] ls
> AUTHORS Makefile.am aclocal.m4 depcomp list.h missing usbmisc.c
> COPYING Makefile.in config.h.in devtree.c lsusb-t.c names.c usbmisc.h
> ChangeLog NEWS configure devtree.h lsusb.8 names.h
> INSTALL README configure.ac install-sh lsusb.c usb.ids
> [~/src/usbutils-0.81] grep update-usb *
> ChangeLog: * update-usbids.sh: add "-q" (quiet) option for cron jobs;
> ChangeLog: * update-usbids.sh: add, based on update-pciids.sh
> [~/src/usbutils-0.81]
>
> So it's not in the tarball, and it's apparently not created by the Makefile.
>
> So where is it?
As was pointed out by Mike, a bug in the Makefile prevented it from
being added to the tarball.
If youreally want it, you can grab it from the git tree, or wait a day
or so for me to implement Mike's changes he so nicely sent me, so I can
do a new release.
thanks,
greg k-h
On Wed, 29 Apr 2009 14:56:23 PDT, Greg KH said:
> As was pointed out by Mike, a bug in the Makefile prevented it from
> being added to the tarball.
Yeah, I managed to miss that 3-line part of that e-mail some 259 emails back.
Sometimes the LKML firehose sucks. :)
> If youreally want it, you can grab it from the git tree, or wait a day
> or so for me to implement Mike's changes he so nicely sent me, so I can
> do a new release.
Admittedly, it was mostly the sudden "Wait - why isn't there a update-usbids
on my laptop?" panic - at least now I understand what happened.
So I grabbed it from the GIT tree, turns out Fedora is already packaging the
current version of usb.ids as part of the 'hwdata' RPM rather than 'usbutils',
so the practical impact of the whole thing dropped a big chunk. Still need to
get them to upgrade from 0.73 to 0.82 though.
Thanks for the clue-by-four... ;)
On Wed, Apr 29, 2009 at 14:30, Greg KH wrote:
> On Wed, Apr 29, 2009 at 02:17:12PM -0400, Mike Frysinger wrote:
>> >> find being able to run `usbmodules` pretty useful ... i wrote a script
>> >> for fun:
>> >> http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
>> >
>> > Did that work on any 2.6 kernel?
>>
>> it's the only version ive tested it with ... but it doesnt parse any
>> kernel module directly, it reads the generated modules.usbmap file
>>
>> > There's no reason we can't add "-k" support to lsusb like lspci has to
>> > show the modules assigned to different devices.
>>
>> the method i posted above only needs the module to be compiled, not loaded
>
> As the map files are depreciated, I wouldn't continue to rely on it, it
> will break in the future when the kernel stops generating those files.
guess i'll have to rewrite it to parse the .ko modules directly like
the usbmap is generated now
-mike
On Thu, Apr 30, 2009 at 01:38, Mike Frysinger <[email protected]> wrote:
> On Wed, Apr 29, 2009 at 14:30, Greg KH wrote:
>> On Wed, Apr 29, 2009 at 02:17:12PM -0400, Mike Frysinger wrote:
>>> >> find being able to run `usbmodules` pretty useful ... i wrote a script
>>> >> for fun:
>>> >> http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
>>> >
>>> > Did that work on any 2.6 kernel?
>>>
>>> it's the only version ive tested it with ... but it doesnt parse any
>>> kernel module directly, it reads the generated modules.usbmap file
>>>
>>> > There's no reason we can't add "-k" support to lsusb like lspci has to
>>> > show the modules assigned to different devices.
>>>
>>> the method i posted above only needs the module to be compiled, not loaded
>>
>> As the map files are depreciated, I wouldn't continue to rely on it, it
>> will break in the future when the kernel stops generating those files.
>
> guess i'll have to rewrite it to parse the .ko modules directly like
> the usbmap is generated now
Can't you use the modules.aliases file? That should stay around and
there should be the same information contained.
Kay
On Wed, Apr 29, 2009 at 20:45, Kay Sievers wrote:
> On Thu, Apr 30, 2009 at 01:38, Mike Frysinger wrote:
>> On Wed, Apr 29, 2009 at 14:30, Greg KH wrote:
>>> On Wed, Apr 29, 2009 at 02:17:12PM -0400, Mike Frysinger wrote:
>>>> >> find being able to run `usbmodules` pretty useful ... i wrote a script
>>>> >> for fun:
>>>> >> http://sources.gentoo.org/sys-apps/usbutils/files/usbmodules.sh
>>>> >
>>>> > Did that work on any 2.6 kernel?
>>>>
>>>> it's the only version ive tested it with ... but it doesnt parse any
>>>> kernel module directly, it reads the generated modules.usbmap file
>>>>
>>>> > There's no reason we can't add "-k" support to lsusb like lspci has to
>>>> > show the modules assigned to different devices.
>>>>
>>>> the method i posted above only needs the module to be compiled, not loaded
>>>
>>> As the map files are depreciated, I wouldn't continue to rely on it, it
>>> will break in the future when the kernel stops generating those files.
>>
>> guess i'll have to rewrite it to parse the .ko modules directly like
>> the usbmap is generated now
>
> Can't you use the modules.aliases file? That should stay around and
> there should be the same information contained.
should be fine if it's going to be sticking around
any comments on the attached file ? in theory, it could be easily
extended for pci and other busses ...
-mike
On Wed, 2009-04-29 at 14:56 -0700, Greg KH wrote:
> If youreally want it, you can grab it from the git tree, or wait a day
> or so for me to implement Mike's changes he so nicely sent me, so I can
> do a new release.
How about this? It substitutes the script and the man page with the
given --datadir=.
Git is here:
git://git.kernel.org/pub/scm/linux/kernel/git/kay/usbutils.git
It installs the update script, which will overwrite the original
location, so we don't need to put several files on the system, and avoid
confusing other packages who look for them.
The right fix for the users of the ids file would probably be to drop a
usbutils pkg-config file which can point users to the location of the
database, so other packages could use that value without starting to
search for the file.
We already need do this silly search in the udev-extras build, and there
seems not two known distros, who share the same location of that
file. :(
Thanks,
Kay
diff --git a/.gitignore b/.gitignore
index fc743f1..cc378da 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,4 +15,5 @@ depcomp
install-sh
missing
lsusb
-
+lsusb.8
+update-usbids.sh
diff --git a/Makefile.am b/Makefile.am
index 7c20acb..a88c3b4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -10,6 +10,9 @@ endif
sbin_PROGRAMS = \
lsusb
+sbin_SCRIPTS = \
+ update-usbids.sh
+
lsusb_SOURCES = \
lsusb.c \
lsusb-t.c \
@@ -25,17 +28,28 @@ lsusb_CPPFLAGS = \
lsusb_LDADD = \
$(LIBUSB_LIBS)
-dist_man_MANS = \
+man_MANS = \
lsusb.8
EXTRA_DIST = \
- usb.ids
+ usb.ids \
+ update-usbids.sh.in \
+ lsusb.8.in
+
+update-usbids.sh: update-usbids.sh.in
+ sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
+ chmod 755 $@
+
+lsusb.8: lsusb.8.in
+ sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
usb.ids.gz: usb.ids
gzip -c -9 usb.ids > usb.ids.gz
clean-local:
rm -f usb.ids.gz
+ rm -f lsusb.8
+ rm -f update-usbids.sh
distclean-local:
rm -rf autom4te.cache
diff --git a/configure.ac b/configure.ac
index 9bf677c..8b6bd2f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -39,6 +39,7 @@ echo "
=============
prefix: ${prefix}
+ datadir: ${datadir}
datarootdir: ${datarootdir}
mandir: ${mandir}
diff --git a/lsusb.8 b/lsusb.8.in
similarity index 98%
rename from lsusb.8
rename to lsusb.8.in
index 14e662c..1922b0a 100644
--- a/lsusb.8
+++ b/lsusb.8.in
@@ -55,7 +55,7 @@ If the specified device is not found, a non-zero exit code is returned.
.SH FILES
.TP
-.B /usr/share/usb.ids
+.B @usbids@
A list of all known USB ID's (vendors, products, classes, subclasses and protocols).
.SH SEE ALSO
diff --git a/update-usbids.sh b/update-usbids.sh.in
similarity index 98%
rename from update-usbids.sh
rename to update-usbids.sh.in
index 3072f03..4a487ed 100755
--- a/update-usbids.sh
+++ b/update-usbids.sh.in
@@ -6,7 +6,7 @@
set -e
SRC="http://www.linux-usb.org/usb.ids"
-DEST=usb.ids
+DEST=@usbids@
# if usb.ids is read-only (because the filesystem is read-only),
# then just skip this whole process.
On Thu, Apr 30, 2009 at 03:48, Mike Frysinger <[email protected]> wrote:
> On Wed, Apr 29, 2009 at 20:45, Kay Sievers wrote:
>> On Thu, Apr 30, 2009 at 01:38, Mike Frysinger wrote:
>>> guess i'll have to rewrite it to parse the .ko modules directly like
>>> the usbmap is generated now
>>
>> Can't you use the modules.aliases file? That should stay around and
>> there should be the same information contained.
>
> should be fine if it's going to be sticking around
>
> any comments on the attached file ? in theory, it could be easily
> extended for pci and other busses ...
Hmm, you still use the map files? I meant if you could use:
/lib/modules/$(uname -r)/modules.alias
The map files are already gone on some distros and will no longer be
around in the future.
Thanks,
Kay
On Wed, Apr 29, 2009 at 21:48, Kay Sievers wrote:
> On Wed, 2009-04-29 at 14:56 -0700, Greg KH wrote:
>> If youreally want it, you can grab it from the git tree, or wait a day
>> or so for me to implement Mike's changes he so nicely sent me, so I can
>> do a new release.
>
> How about this? It substitutes the script and the man page with the
> given --datadir=.
i had pretty much the same changes locally, but i was going to let the
discussion on data/multiple paths finish first. at any rate, comments
below ...
> --- a/Makefile.am
> +++ b/Makefile.am
>
> +update-usbids.sh: update-usbids.sh.in
> +lsusb.8: lsusb.8.in
need $(srcdir)/ in front of the dependency
> + sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
> + sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
should use the 'g' option to sed
in theory you should use AC_PROG_SED in configure.ac and then $(SED)
in the Makefile.am
$(datadir) too should die ... $(datarootdir) is the right variable name
> clean-local:
> rm -f usb.ids.gz
> + rm -f lsusb.8
> + rm -f update-usbids.sh
after Greg merges the patches i sent for usb.ids.gz, it should be
clear that clean-local should die and you should update DISTCLEANFILES
> --- a/configure.ac
> +++ b/configure.ac
>
> + datadir: ${datadir}
we have datarootdir now, so no point in adding datadir
-mike
On Wed, Apr 29, 2009 at 21:54, Kay Sievers wrote:
> On Thu, Apr 30, 2009 at 03:48, Mike Frysinger wrote:
>> On Wed, Apr 29, 2009 at 20:45, Kay Sievers wrote:
>>> On Thu, Apr 30, 2009 at 01:38, Mike Frysinger wrote:
>>>> guess i'll have to rewrite it to parse the .ko modules directly like
>>>> the usbmap is generated now
>>>
>>> Can't you use the modules.aliases file? That should stay around and
>>> there should be the same information contained.
>>
>> should be fine if it's going to be sticking around
>>
>> any comments on the attached file ? in theory, it could be easily
>> extended for pci and other busses ...
>
> Hmm, you still use the map files? I meant if you could use:
> /lib/modules/$(uname -r)/modules.alias
yes, i got what you mean, i just forgot to update the map= setting. i
updated the important part (the awk parsing) so that it uses the
modules.alias format.
if the rest is fine i can send a git patch along to the usb lists.
-mike
On Thu, Apr 30, 2009 at 03:56, Mike Frysinger <[email protected]> wrote:
> On Wed, Apr 29, 2009 at 21:48, Kay Sievers wrote:
>> On Wed, 2009-04-29 at 14:56 -0700, Greg KH wrote:
>>> If youreally want it, you can grab it from the git tree, or wait a day
>>> or so for me to implement Mike's changes he so nicely sent me, so I can
>>> do a new release.
>>
>> How about this? It substitutes the script and the man page with the
>> given --datadir=.
>
> i had pretty much the same changes locally, but i was going to let the
> discussion on data/multiple paths finish first. at any rate, comments
> below ...
>
>> --- a/Makefile.am
>> +++ b/Makefile.am
>>
>> +update-usbids.sh: update-usbids.sh.in
>> +lsusb.8: lsusb.8.in
>
> need $(srcdir)/ in front of the dependency
>
>> + sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
>> + sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
>
> should use the 'g' option to sed
>
> in theory you should use AC_PROG_SED in configure.ac and then $(SED)
> in the Makefile.am
Fine, if that works.
> $(datadir) too should die ... $(datarootdir) is the right variable name
Then you want to specify man pages separately? I wouldn't do that.
>> clean-local:
>> rm -f usb.ids.gz
>> + rm -f lsusb.8
>> + rm -f update-usbids.sh
>
> after Greg merges the patches i sent for usb.ids.gz, it should be
> clear that clean-local should die and you should update DISTCLEANFILES
Sure, no problem.
>> --- a/configure.ac
>> +++ b/configure.ac
>>
>> + datadir: ${datadir}
>
> we have datarootdir now, so no point in adding datadir
Only if you require to set the man dir.
Kay
On Wed, Apr 29, 2009 at 22:06, Kay Sievers wrote:
> On Thu, Apr 30, 2009 at 03:56, Mike Frysinger wrote:
>> On Wed, Apr 29, 2009 at 21:48, Kay Sievers wrote:
>>> On Wed, 2009-04-29 at 14:56 -0700, Greg KH wrote:
>>>> If youreally want it, you can grab it from the git tree, or wait a day
>>>> or so for me to implement Mike's changes he so nicely sent me, so I can
>>>> do a new release.
>>>
>>> How about this? It substitutes the script and the man page with the
>>> given --datadir=.
>>
>> i had pretty much the same changes locally, but i was going to let the
>> discussion on data/multiple paths finish first. at any rate, comments
>> below ...
>>
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>>
>>> + sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
>>> + sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
>>
>> $(datadir) too should die ... $(datarootdir) is the right variable name
>
> Then you want to specify man pages separately? I wouldn't do that.
nm me, i confused the stuff i was reading about the
datadir/datarootdir changes with autoconf-2.60
-mike
On Wed, Apr 29, 2009 at 10:13:47PM -0400, Mike Frysinger wrote:
> On Wed, Apr 29, 2009 at 22:06, Kay Sievers wrote:
> > On Thu, Apr 30, 2009 at 03:56, Mike Frysinger wrote:
> >> On Wed, Apr 29, 2009 at 21:48, Kay Sievers wrote:
> >>> On Wed, 2009-04-29 at 14:56 -0700, Greg KH wrote:
> >>>> If youreally want it, you can grab it from the git tree, or wait a day
> >>>> or so for me to implement Mike's changes he so nicely sent me, so I can
> >>>> do a new release.
> >>>
> >>> How about this? It substitutes the script and the man page with the
> >>> given --datadir=.
> >>
> >> i had pretty much the same changes locally, but i was going to let the
> >> discussion on data/multiple paths finish first. ?at any rate, comments
> >> below ...
> >>
> >>> --- a/Makefile.am
> >>> +++ b/Makefile.am
> >>>
> >>> + ? ? ? sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
> >>> + ? ? ? sed 's|@usbids@|$(datadir)/usb.ids|' $< >$@
> >>
> >> $(datadir) too should die ... $(datarootdir) is the right variable name
> >
> > Then you want to specify man pages separately? I wouldn't do that.
>
> nm me, i confused the stuff i was reading about the
> datadir/datarootdir changes with autoconf-2.60
Heh.
I've merged your changes into my git tree, can someone see what I messed
up on the merge?
thanks,
greg k-h
Henrique de Moraes Holschuh
<[email protected]> writes:
> Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
> Both have working "update-usbids" scripts (might be the one from upstream,
> or something different). They also have the original file in /usr/share, I
> don't know if usbutils was changed to check /var first then /usr, or what.
No. They place a symlink from /usr/share to /var/lib:
bjorn@nemi:~$ ls -l /usr/share/misc/usb.ids
lrwxrwxrwx 1 root root 25 2009-01-24 01:36 /usr/share/misc/usb.ids -> /var/lib/usbutils/usb.ids
bjorn@nemi:~$ dpkg -S /usr/share/misc/usb.ids
usbutils: /usr/share/misc/usb.ids
The symlink is probably there for compatibility with other (possibly
non-Debian) utilities. Debian usbutils does not use the /usr/share path
itself:
bjorn@nemi:~$ strings /usr/sbin/lsusb |grep usb.ids
./usb.ids
./usb.ids.gz
/var/lib/usbutils/usb.ids
/var/lib/usbutils/usb.ids.gz
However, looks like the Debian hal uses it. That's probably the main
reason for the symlink:
bjorn@nemi:~$ strings /usr/sbin/hald |grep usb.ids
/usr/share/misc/usb.ids
Couldn't stat usb.ids file '%s', errno=%d: %s
Couldn't open usb.ids file '%s', errno=%d: %s
Couldn't mmap usb.ids file '%s', errno=%d: %s
usb_ids_load
Bjørn