2017-01-13 17:34 GMT+01:00 Jens Reyer <jre.wine...@gmail.com>:
> Thanks a lot Matthias!
> On 01/12/2017 07:40 PM, Matthias Klumpp wrote:
>>> There is a wine.desktop, but for other reasons we only ship it as an
>>> example. Still, other distros probably install it. However that
>>> .desktop file has "NoDisplay=true" so afaik it wouldn't be used for
>>> AppStream anyway.
>> That's not necessarily the case - if a metainfo file is provided, a
>> NoDisplay field is ignored.
> Did you use "metainfo" generally here, or specifically for foo.metainfo.xml?
Yes, "metainfo" is the general name for any XML stuff you put into
and should be used consistently in the spec to name the data (if you
find a place where it isn't named that way or that is misleading,
please report a bug!).
>> "desktop" btw is an outdated name, to describe applications you can
>> pick the component types "desktop-application" and
> Thanks, changed.
> <component type="desktop"> is still widespread in the documentation
> (tell me if I should file separate bugreports/submit patches somewhere):
> "Note that the XML root must have the type property set to desktop"
> "All tags defined in the generic component specification are valid for
> desktop application components as well."
> --> Suggestion: add "(and vice versa)"
Not necessarily - components that are not generic might have special
requirements, e.g. a desktop-application requires an icon, while it's
optional for a console-application.
In any case, all valid tags are described for the generic components,
and the specific typed-component pages only describe additional
restrictions or specialities.
> "<component type="desktop">"
That was intentional at some point to not confuse users - now, since
the desktop-application change has been in the wild long enough, we
can change the example.
> "you can tell by the XML root-node having a type="desktop" attribute"
> With appstream 0.10.5-1:
> $ appstream-util appdata-from-desktop foo.desktop foo.appdata.xml"
> --> type="desktop"
That isn't AppStream - appstream-util is part of GNOMEs
reimplementation, called appstream-glib, and this is a (minor) bug
(the desktop type will likely be supported for eternity).
Appstreamcli shouldn't complain.
>> For the example file:
>> The validation fails with:
>> Could not parse XML data: Entity: line 2: parser error : Start tag expected,
>> not found
>> <!-- Copyright 2017 Jens Reyer <jre.wine...@gmail.com> -->
>> I assume this is due to the < being some other character, because
>> rewriting the header worked well.
> Ouch, thanks! These were 'ZERO WIDTH SPACE' (U+200B) characters. I had
> seen "appstream-util validate" complaining, but had assumed I did the
> test wrongly.
> This was based on the example file from
> copied in Debian from firefox to emacs. If I copy to vim I indeed see
> them. So I guess the homepage needs to be fixed.
I checked, the Docbook files don't contain these lines, so unless
Publican added them, I don't think the homepage is to blame...
>> The icon types "cached", "remote" and "local" are not allowed in
>> metainfo files (reminds me to add a validator test for that), only
>> "stock" is fine.
> Sounds as if you are referring explicitly to "foo.metainfo.xml" files
> here. Should I use metainfo.xml or appdata.xml?
Doesn't matter technically, some tools are more pedantic though. If
your component type is of type desktop-application, use .appdata.xml
to be safe, in any other case use .metainfo.xml.
> says "stock icons are loaded from stock."
> I don't understand what this exactly means. Where is this stock, and how
> is it created/what does it contain? Do I as packager have any direct
> influence on what it contains?
We should probably replace the second stock with "icon theme", i.e. it
will load whatever icon is in /usr/share/hicolor/<size>/apps, just
like the Icon= field in a desktop file does.
I wonder if we should support "local" as well as "stock" (that might
require some changes on the metadata generator, but would make sense).
> Even if I address all other issues and rename to metainfo.xml I still get:
> $ appstream-util validate-relax org.winehq.wine.development.metainfo.xml
> org.winehq.wine.development.metainfo.xml: FAILED:
> • markup-invalid : <id> does not have correct extension for kind
> Validation of files failed
> Is this critical? Can I ignore it or do I need to use type "generic" (I
> want to see Wine in Gnome Software Center)?
Ignore it. The worst that can happen is users being unable to launch
Wine directly after installing it from GNOME Software. I'll talk with
Richard Hughes on how to deal with this issue properly (in fact, I
already did, but my solution for this issue is a little bit invastive
and I want more feedback from other people first (discussion will
happen on the AppSteam ML)).
But for now, you can ignore it.
Weird that appstream-util apparently doesn't show whether some issue
is a real dealbreaker or just a minor hint.
> What do you use to validate?
appstreamcli validate - it will just validate the file for conformity
with the specification, and won't do a lot of style-checks. But in
general, the stuff that passes appstreamcli validation will show in
Debian/Ubuntu/Arch metadata, since those distros use libappstream for
parsing the files.
>> Otherwise the file looks fine, a screenshot might be nice though.
> Thanks. I'll discuss screenshots and generic release info with upstream,
> once I submit it there.
Nice! Btw, you don't need a <releases/> tag ;-) - having it is nice though.
>> (Edited file is attached)
> Thanks again!
>> P.S: Let me know when an updated Wine is uploaded, this will be the
>> only app I know which does not use the metainfo file to augment a
>> .desktop file, and I am curious to see if the file is handled
> Will do, maybe later today.
I welcome VSRE emails. See http://vsre.info/