Added AppStream metadata XML listing supported hardware. #1399
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi, and Thanx.
Please update that prose (and wherever it came from) this sounds like maybe
a 2005 version of those paragraphs. Boasting about PDA support - and dozens
of others - that we removed long ago isn't cool.
We support a ton of hardware without unique USB identifiers. (May gps are
receivers on the other end of generic USB/serial bridges) How to best
handle those?
…On Wed, Jan 15, 2025, 11:59 AM petterreinholdtsen ***@***.***> wrote:
The AppStream metadata is package metadata shared across Linux
distributions, see
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html .
It include support for mapping to relevant hardware IDs, like USB IDs in
this case. This allow programs like isenkram to map relevant hardware to
this package, and propose to install the package when supported hardware is
available or inserted in a computer.
This patch was originally submitted to Debian as
https://bugs.debian.org/1077343 .
The patch include installation rules to install the XML file and referred
XDG desktop file.
------------------------------
You can view, comment on, or merge this pull request online at:
#1399
Commit Summary
- 1040fb8
<1040fb8>
Added AppStream metadata XML listing supported hardware.
File Changes
(4 files <https://github.com/GPSBabel/gpsbabel/pull/1399/files>)
- *M* CMakeLists.txt
<https://github.com/GPSBabel/gpsbabel/pull/1399/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20a>
(4)
- *M* gui/CMakeLists.txt
<https://github.com/GPSBabel/gpsbabel/pull/1399/files#diff-c6a6d5a45a2ed1ea6787303875556a824d973664b51261d3555ecd6a6a8679f2>
(5)
- *A* gui/org.gpsbabel.gui.metainfo.xml
<https://github.com/GPSBabel/gpsbabel/pull/1399/files#diff-6c4199656ab03da99f7433d2cdd85b066dd68c08d5011b4440bf6c365f9a4542>
(20)
- *A* org.gpsbabel.tool.metainfo.xml
<https://github.com/GPSBabel/gpsbabel/pull/1399/files#diff-e4f18ba64d817b72da4b536fbd197e416db0c18743b7e96304f93dc41685ce18>
(32)
Patch Links:
- https://github.com/GPSBabel/gpsbabel/pull/1399.patch
- https://github.com/GPSBabel/gpsbabel/pull/1399.diff
—
Reply to this email directly, view it on GitHub
<#1399>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VAD4BYJUNZG7L6YEPH732K2OWZAVCNFSM6AAAAABVH2DU5SVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44TANBZGMYDAMA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
[GPSBabel]
Please update that prose (and wherever it came from) this sounds like
maybe a 2005 version of those paragraphs. Boasting about PDA support -
and dozens of others - that we removed long ago isn't cool.
I would be happy to. The description came from the Debian package
description a while back. What should I put in there instead?
We support a ton of hardware without unique USB identifiers. (May gps
are receivers on the other end of generic USB/serial bridges) How to
best handle those?
I guess it depend on how you identify them? Do they have another unique
ID presented by a Linux driver in a modalias in /sys/devices/, then this
one can be added to the list.
…--
Happy hacking
Petter Reinholdtsen
|
tsteven4
requested changes
Jan 16, 2025
There was a problem hiding this comment.
I am amenable to accepting the metainfo.xml files, but I am reluctant to accept the cmake changes. We don't use the cmake install command at all, instead we require the linux packagers to install the files they want where the want them. Historically it has been difficult to implement a linux install that works for everyone.
|
[tsteven4]
I am amenable to accepting the metainfo.xml files, but I am reluctant
to accept the cmake changes.
OK. Dropped the cmake install rules.
Delorme, Streets and Trips, and Magellan have are no longer supported.
Dropped, rephrased the description for both XML files.
This list is incorrect. The current list of supported formats is:
OK, replaced format list with the one you provided. :)
+ <provides>
+ <modalias>usb:v091Ep0003d*</modalias>
This appears to be some kind of Garmin device (vendor id 091e). I
don't what the p field corresponds to. Some Garmin usb devide ids are
listed in http://www.linux-usb.org/usb.ids.
The p is the product ID, according to usb.ids it is v091e Garmin
International and p0003 GPS (various models). The ID provided is one
used by a GPS I own and that work with gpsbabel. I do not know the
complete list of supported devices.
There are a lot of Gamin RS232 serial devices supported. I don't know
how you would handle those.
In my experience, RS232 devices can not be reliably autodetected, and
thus can not be automatically mapped to packages using any modalias.
USB and Bluetooth devices on the other hand provide quite unique IDs.
…--
Happy hacking
Petter Reinholdtsen
|
|
@petterreinholdtsen Thanks for introducing this. After looking at the documentation link you provided I suggest the following changes included in the attached patch. Do they look OK to you? They do pass "appstreamcli validate". @GPSBabelDeveloper are you OK with the proposed metadata license MIT? Or would you prefer one of the others from https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license? |
|
[tsteven4]
@petterreinholdtsen Thanks for introducing this. After looking at the
documentation link you provided I suggest the following changes
included in the attached patch. Do they look OK to you? They do pass
"appstreamcli validate".
It look good to me. :)
@GPSBabelDeveloper are you OK with the proposed metadata license MIT?
I am fine with any of them, I just picked MIT as it is simple and
compatible with almost anything. :)
…--
Happy hacking
Petter Reinholdtsen
|
|
Is there anything more I can do to get this change ready to go into master? |
After I hear from @robertlipe about the metadata license I will push the patch and merge. Thanks. |
|
I'm fine with that. Was there a decision on how to handle the serial units? The comment was marked 'resolved', but I didn't see any code change. |
|
[Robert Lipe]
Was there a decision on how to handle the serial units? The comment
was marked 'resolved', but I didn't see any code change.
They are not handled, as far as I know, because there is no way to
automatically identify them. This system can only work with the
information available, not do magic.
…--
Happy hacking
Petter Reinholdtsen
|
|
The list of devices is incomplete, but it is difficult to see what to add without having each device in hand. Some hints can be found at https://gitlab.com/gpsd/gpsd/-/blob/master/gpsd.rules.in?ref_type=heads, but without testing I am reluctant to add more modaliases. I note the referenced file has commented out entries for some popular serial port converters, e.g. "FTDI 8U232AM / FT232" and "Prolific Technology, Inc. PL2303 Serial Port". It remarks: "rule disabled because it matches way too many generic serial converters and creates more harm than good" |
|
That's reasonable. Well, it's NOT reasonable that almost 30 years into USB
vendors still use generic serial IDs to present packetized interfaces, but
here we are... the trend of adopting mass storage and GPX files dulled that
pain anyway.
I suspect there's little expectation that we're presented in a
plug-and-play manner when a device is attached; people seek us out to solve
a specific problem. Likewise, for a large percentage of OUR users, GPSd is
not relevant. (I knew about it when I created GPSBabel. We grew into
somewhat touching spaces, but we have very little actual overlap.)
Does this present any speed bump to people trying to use us where they have
to learn to get GPSD (or any other app with Garmin VIDs) out of their way,
the way people have had to find and remove "helpful" Linux GPS solutions
<https://www.gpsbabel.org/os/Linux_Hotplug.html> for years? The situation
would be very much like attaching a single-board computer that used a
Prolific driver for upload and console use and being offered GPSd to talk
to their ESP32 or something.
I don't remember anyone coming to us with this problem, and it doesn't
sound like there's much we can do about it, so just not playing that game
seems the best move. They're a pretty small percentage of our base these
days anyway.
Thanx,
RJL
…On Wed, Jan 22, 2025 at 8:18 AM tsteven4 ***@***.***> wrote:
The list of devices is incomplete, but it is difficult to see what to add
without having each device in hand. Some hints can be found at
https://gitlab.com/gpsd/gpsd/-/blob/master/gpsd.rules.in?ref_type=heads,
but without testing I am reluctant to add more modaliases.
I note the referenced file has commented out entries for some popular
serial port converters, e.g. "FTDI 8U232AM / FT232" and "Prolific
Technology, Inc. PL2303 Serial Port". It remarks: "rule disabled because it
matches way too many generic serial converters and creates more harm than
good"
—
Reply to this email directly, view it on GitHub
<#1399 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD37D7GJDB35FXVRZLLL2L6SEZAVCNFSM6AAAAABVH2DU5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGM3TCOBYGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The macos regression failures seem to be related to a change in a homebrew package. If the cache has been flushed we pick up a new version of jing-trang: |
tsteven4
approved these changes
Jan 22, 2025
The AppStream metadata is package metadata shared across Linux distributions, see https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html . It include support for mapping to relevant hardware IDs, like USB IDs in this case. This allow programs like isenkram to map relevant hardware to this package, and propose to install the package when supported hardware is available or inserted in a computer. This patch was originally submitted to Debian as https://bugs.debian.org/1077343 . The patch do not include installation rules to install the XML file and referred XDG desktop file on request from tsteven4. The XML files include metainfo enhancments from tsteven4.
petterreinholdtsen
force-pushed
the
appstream-metainfo-hw-mapping
branch
from
248d4f0 to
a544923
Compare
|
I squashed the change into one unified commit.
…--
Happy hacking
Petter Reinholdtsen
|
thanks, I do like to keep the history clean. I usually just hit the squash and merge button. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The AppStream metadata is package metadata shared across Linux distributions, see https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html . It include support for mapping to relevant hardware IDs, like USB IDs in this case. This allow programs like isenkram to map relevant hardware to this package, and propose to install the package when supported hardware is available or inserted in a computer.
This patch was originally submitted to Debian as https://bugs.debian.org/1077343 .
The patch include installation rules to install the XML file and referred XDG desktop file.