Bug#848839: AppStream metadata for Wine

[Jens Reyer]

On 01/24/2017 12:42 AM, Matthias Klumpp wrote:
> 2017-01-22 23:02 GMT+01:00 Jens Reyer :
>> On 01/22/2017 10:36 PM, Matthias Klumpp wrote:
>>> 2017-01-22 22:02 GMT+01:00 Jens Reyer :
 The new wine-development now shows up in GNOME Software Center, the
 installed status is correct and install/removal works.

 But wine is still broken in there (install status is always
 "installed"). I don't know if I just broke my system, or if everyone is
 affected.  Feedback from anyone is welcome.
[...]
> Very strange - I can't reproduce this here, everything looks as
> expected. If this persists, it's probably worth filing an upstream
> bug...

Nevermind, I had a stray /usr/share/appdata/org.winehq.wine.appdata.xml
from my tests. Now it basically works :)  So here a final thank you for
working on this with me, Matthias.

For the minor inconveniences I reported:

https://bugzilla.gnome.org/show_bug.cgi?id=777837 (Installed status of
dependencies only updated after restart)

https://bugzilla.gnome.org/show_bug.cgi?id=777838 (Please disable
"Launch" if only appdata.xml but no .desktop is provided)

Greets
jre

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

2017-01-22 23:02 GMT+01:00 Jens Reyer :
> On 01/22/2017 10:36 PM, Matthias Klumpp wrote:
>> 2017-01-22 22:02 GMT+01:00 Jens Reyer :
>>> The new wine-development now shows up in GNOME Software Center, the
>>> installed status is correct and install/removal works.
>>>
>>> But wine is still broken in there (install status is always
>>> "installed"). I don't know if I just broke my system, or if everyone is
>>> affected.  Feedback from anyone is welcome.
>>
>> Sounds like a GNOME Software bug... Maybe it assumes stuff to be
>> installed when a metainfo file exists in /usr/share/metainfo, so if
>> you manually place it there, GS gets confused. If that's not the case,
>> this is a weird GS bug - can you verify this bug with GNOME Software
>> 3.22.5 (in unstable)?
>
> Still there with 3.22.5-1.
>
> What's strange is that this only happens with wine, but not with
> wine-development, although both are identical here besides their
> AppStream id and name.
>
> While testing I indeed had placed the files manually somewhere (maybe
> only the one for wine, but not that for wine-development), but removed
> them since. With all wine packages uninstalled:
>
> $ ls /usr/share/applications/*wine*
> ls: cannot access '/usr/share/applications/*wine*': No such file or
> directory
>
> $ ls /usr/share/metainfo
> org.freedesktop.appstream.cli.metainfo.xml
>
> $ ls /var/cache/app-info/xmls/
> fwupd.xml

Very strange - I can't reproduce this here, everything looks as
expected. If this persists, it's probably worth filing an upstream
bug...

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

On 01/22/2017 10:36 PM, Matthias Klumpp wrote:
> 2017-01-22 22:02 GMT+01:00 Jens Reyer :
>> The new wine-development now shows up in GNOME Software Center, the
>> installed status is correct and install/removal works.
>>
>> But wine is still broken in there (install status is always
>> "installed"). I don't know if I just broke my system, or if everyone is
>> affected.  Feedback from anyone is welcome.
> 
> Sounds like a GNOME Software bug... Maybe it assumes stuff to be
> installed when a metainfo file exists in /usr/share/metainfo, so if
> you manually place it there, GS gets confused. If that's not the case,
> this is a weird GS bug - can you verify this bug with GNOME Software
> 3.22.5 (in unstable)?

Still there with 3.22.5-1.

What's strange is that this only happens with wine, but not with
wine-development, although both are identical here besides their
AppStream id and name.

While testing I indeed had placed the files manually somewhere (maybe
only the one for wine, but not that for wine-development), but removed
them since. With all wine packages uninstalled:

$ ls /usr/share/applications/*wine*
ls: cannot access '/usr/share/applications/*wine*': No such file or
directory

$ ls /usr/share/metainfo
org.freedesktop.appstream.cli.metainfo.xml

$ ls /var/cache/app-info/xmls/
fwupd.xml

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

2017-01-22 22:02 GMT+01:00 Jens Reyer :
> [ Wine in GNOME Software Center ]
> On 01/21/2017 12:24 AM, Jens Reyer wrote:
>> Can anybody else check this, to rule out me messing with my system
>> during working on this?
>>
>> The installed status should be correct, and install/remove work.
>> "Launch" will not work, that is known.
>
> The new wine-development now shows up in GNOME Software Center, the
> installed status is correct and install/removal works.
>
> But wine is still broken in there (install status is always
> "installed"). I don't know if I just broke my system, or if everyone is
> affected.  Feedback from anyone is welcome.

Sounds like a GNOME Software bug... Maybe it assumes stuff to be
installed when a metainfo file exists in /usr/share/metainfo, so if
you manually place it there, GS gets confused. If that's not the case,
this is a weird GS bug - can you verify this bug with GNOME Software
3.22.5 (in unstable)?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

[ Wine in GNOME Software Center ]
On 01/21/2017 12:24 AM, Jens Reyer wrote:
> Can anybody else check this, to rule out me messing with my system
> during working on this?
> 
> The installed status should be correct, and install/remove work.
> "Launch" will not work, that is known.

The new wine-development now shows up in GNOME Software Center, the
installed status is correct and install/removal works.

But wine is still broken in there (install status is always
"installed"). I don't know if I just broke my system, or if everyone is
affected.  Feedback from anyone is welcome.

Greets
jre

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

On 01/19/2017 09:14 PM, Matthias Klumpp wrote:
> Looks like GNOME Software chokes on the project_group being set to a
> group it has no knowledge of and trashes the component directly...
> Removing the group and adding categories (
> https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-categories
> ) made it show up for me.

Thanks again, indeed that worked and wine shows up in the GNOME Software
Center now.

However it is always shown as "installed", whether that's true or not.

I've uninstalled all Wine packages, made an update and restarted the
computer.

Can anybody else check this, to rule out me messing with my system
during working on this?

The installed status should be correct, and install/remove work.
"Launch" will not work, that is known.

btw, all these things work for current winetricks now.

Greets
jre

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

2017-01-19 15:13 GMT+01:00 Jens Reyer :
> Hi again Matthias
>
> On 01/17/2017 08:17 PM, Matthias Klumpp wrote:
>> Anyway, Wine is now in the metadata, and after the next dinstall run
>> it should show up in GNOME Software.
>> https://appstream.debian.org/sid/main/metainfo/wine.html
>
> Thanks, the link works fine! But unfortunately wine still doesn't show
> up in the GNOME Software Center (unless you have it installed).

Looks like GNOME Software chokes on the project_group being set to a
group it has no knowledge of and trashes the component directly...
Removing the group and adding categories (
https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-categories
) made it show up for me.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

Hi again Matthias

On 01/17/2017 08:17 PM, Matthias Klumpp wrote:
> Anyway, Wine is now in the metadata, and after the next dinstall run
> it should show up in GNOME Software.
> https://appstream.debian.org/sid/main/metainfo/wine.html

Thanks, the link works fine! But unfortunately wine still doesn't show
up in the GNOME Software Center (unless you have it installed).

Greets
jre

PS: If useful, please point me to a better suited place for following up
on this.

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

2017-01-17 18:30 GMT+01:00 Jens Reyer :
> [...]
>
> I can now see wine in the GNOME Software Center, but only if wine is
> installed.  So I assume the metainfo from the new appstream.xml is
> evaluated locally, but doesn't make it in the distro-wide AppStream dataset.
>
> Assuming this is the case, I assume it is because of the missing desktop
> file. The appstream-generator shows the following error on
> https://appstream.debian.org/sid/main/issues/wine.html:
>
> ~
> Hints for wine in main
> org.winehq.wine
> Errors
> missing-desktop-file:
> Found an AppStream metainfo XML file, but the associated .desktop file
> is missing. This often happens when the .desktop file is renamed, but
> the  tag of the AppStream metainfo file is not adapted as well, or
> if the metainfo file is located in a different package than the .desktop
> file.
> Please fix the packaging or work with upstream to resolve this issue.
> ~
>
> Did I understand you correctly previously that in your opinion this
> should work, and thus needs fixing in AppStream (appstream-generator?),
> but not in Wine?

Yes. I resolved this in appstream-generator, and it works for Wine - I
hope I didn't break anything else (but all tests completed and things
look good). 
https://github.com/ximion/appstream-generator/commit/d1e3a7d7780b52821fd34afa855905c030ed54dc

> Besides that GNOME Software Center indeed now has a "Launch" button for
> wine, which obviously doesn't work. But you already said that you're
> discussing this with Richard Hughes, so I assume there's nothing we
> (Wine) can do about this.

No - unfortunately, resolving this will require quite a bit of effort,
and will definitely not be ready for Stretch. So, my options are
disallow this feature (and thereby dropping other apps from the data
too, not just Wine) or living with this papercut. Maybe a workaround
can be implemented in GS, but until then I expect this to be broken -
I think having more apps is more important than having this feature
always working. I am not happy with this state though.

Anyway, Wine is now in the metadata, and after the next dinstall run
it should show up in GNOME Software.
https://appstream.debian.org/sid/main/metainfo/wine.html

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

Hi Matthias

tl;dr: it seems it's not working with appstream-generator (?) yet.
Can/Should we (Wine) do something?

On 01/14/2017 03:06 AM, Jens Reyer wrote:
> Thanks again, also for the quick update of the documentation!
> 
> On 01/13/2017 06:26 PM, Matthias Klumpp wrote:
 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
 correctly.
> 
> Just done, wine 1.8.6-2.
> 
> appstreamcli fails with a warning:
> ~
> $ appstreamcli validate debian/org.winehq.wine.appdata.xml
> W - org.winehq.wine.appdata.xml:org.winehq.wine:3
> Component id belongs to a desktop-application, but does not resemble
> the
> .desktop file name: "org.winehq.wine"
> 
> Validation failed.
> ~

I can now see wine in the GNOME Software Center, but only if wine is
installed.  So I assume the metainfo from the new appstream.xml is
evaluated locally, but doesn't make it in the distro-wide AppStream dataset.

Assuming this is the case, I assume it is because of the missing desktop
file. The appstream-generator shows the following error on
https://appstream.debian.org/sid/main/issues/wine.html:

~
Hints for wine in main
org.winehq.wine
Errors
missing-desktop-file:
Found an AppStream metainfo XML file, but the associated .desktop file
is missing. This often happens when the .desktop file is renamed, but
the  tag of the AppStream metainfo file is not adapted as well, or
if the metainfo file is located in a different package than the .desktop
file.
Please fix the packaging or work with upstream to resolve this issue.
~

Did I understand you correctly previously that in your opinion this
should work, and thus needs fixing in AppStream (appstream-generator?),
but not in Wine?


Besides that GNOME Software Center indeed now has a "Launch" button for
wine, which obviously doesn't work. But you already said that you're
discussing this with Richard Hughes, so I assume there's nothing we
(Wine) can do about this.

Greets!
jre

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

Thanks again, also for the quick update of the documentation!

On 01/13/2017 06:26 PM, Matthias Klumpp wrote:
>>> 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
>>> correctly.

Just done, wine 1.8.6-2.

appstreamcli fails with a warning:
~
$ appstreamcli validate debian/org.winehq.wine.appdata.xml
W - org.winehq.wine.appdata.xml:org.winehq.wine:3
Component id belongs to a desktop-application, but does not resemble
the
.desktop file name: "org.winehq.wine"

Validation failed.
~

Now I'm curious if that works :)

Greets
jre

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

2017-01-13 17:34 GMT+01:00 Jens Reyer :
> 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
/usr/share/metainfo,
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
>> "console-application"
>
> Thanks, changed.
>
>  is still widespread in the documentation
> (tell me if I should file separate bugreports/submit patches somewhere):
>
> https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html
>
> ⁠"Note that the XML root must have the type property set to desktop"
>^^^

Eww... Fixed.


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

> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
> ""
>   ^^^

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.

> https://wiki.debian.org/AppStream/Guidelines
> "you can tell by the XML root-node having a type="desktop" attribute"
>   ^^^

Changed.

> 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
>> 
>> ^
>>
>> 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
> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html,
> 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.

> https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html
> 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//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:  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 

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

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?


> "desktop" btw is an outdated name, to describe applications you can
> pick the component types "desktop-application" and
> "console-application"

Thanks, changed.

 is still widespread in the documentation
(tell me if I should file separate bugreports/submit patches somewhere):

https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html

⁠"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)"

https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
"​"
  ^^^

https://wiki.debian.org/AppStream/Guidelines
"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"



> For the example file:
> The validation fails with:
> 
> Could not parse XML data: Entity: line 2: parser error : Start tag expected, 
> '<'
> not found
> 
> ^
> 
> 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
https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html,
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.



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


https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html
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?


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

What do you use to validate?



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


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

Will do, maybe later today.

Greets!
jre



  org.winehq.wine.development
  FSFAP
  LGPL-2.1+
  Wine (development version)
  Run Windows applications on Linux, BSD, Solaris and Mac OS X

  

  Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility
  layer capable of running Windows applications on several POSIX-compliant
  operating systems, such as Linux, Mac OSX,  BSD. Instead of simulating
  internal Windows logic like a virtual machine or emulator, Wine translates
  Windows API calls into POSIX calls on-the-fly, eliminating the performance
  and memory penalties of other methods and allowing you to cleanly integrate
  Windows applications into your desktop.

  

  wine

  https://bugs.winehq.org/
  https://wiki.winehq.org/FAQ
  https://wiki.winehq.org/
  https://www.winehq.org/donate
  https://wiki.winehq.org/Translating

  

  
Bug fixes only, we are in code freeze.
  

  

  
application/x-ms-dos-executable
application/x-msi
application/x-ms-shortcut
  

Bug#848839: AppStream metadata for Wine

[Matthias Klumpp]

Hi!

2017-01-12 18:51 GMT+01:00 Jens Reyer :
> Hi Matthias,
>
> I'm working on an AppStream file for Wine (winehq.org), mainly to have
> it shown in the Software Center. I'm mostly done by now (initial version
> attached, icons are not finished yet, and stuff in there is still static).
>
> Now I got a few questions.  I hope you can help me, or tell me a better
> place to ask.
>
>
> Background:
>
> I assume you generally know Wine.
>
> 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.

> Wine itself is not a graphical application, but of course it can be used
> to run such.  On its own it has a few graphical helper applications
> (winecfg, notepad, ...), but also provides e.g. wineconsole.
>
>
> 1.) Component type "desktop" or "generic"?
>
> Which one should we use, given above described background?
> Is "generic" visible in the software center?

KDE Discover shows generic components, while GNOME Software does not.
So the answer is "it depends".

> Does "generic" accept tags which are defined only for "desktop"?

Yes.
"desktop" btw is an outdated name, to describe applications you can
pick the component types "desktop-application" and
"console-application", while KDE Discover shows both and GNOME
Software only shows desktop apps (rationale being that users who use
GS can't deal with console applications).

>
> 2.) License
>
> I'd like to stick with the upstream license LGPL-2.1+.
> Does this work for AppStream purposes?
> Alternatively I'm thinking about e.g. "LGPL2.1+ or MIT".

That's fine. For the project_license tag generally everything license
is allowed.
For the metadata itself (metadata_license tag), we need a permissive
license to merge metadata together in one big stream of data without
violating a license. I suggest using the FSFAP license for that (see
https://spdx.org/licenses/FSFAP.html )

> 3.) Which "id" should we use?
>
> Stretch will ship 2 versions of Wine:
>
> - src:wine which tracks upstreams stable branch
> - src:wine-development which tracks the development branch
>
> I thought about ignoring the desktop file completely, and use for
> upstream and our src:wine:
>
>   org.winehq.wine
>   Wine
>
> Then I'd expand the id and change the name for src:wine-development to
>
>   org.winehq.wine.development
>   Wine (development version)

In this particular case, I think you are correct, not using the
.desktop file is probably best. In case you don't use it, you need to
set an  tag in the metainfo file though (at least
for desktop-application type apps).
The IDs and names make a lot of sense to me :)

For the example file:
The validation fails with:

Could not parse XML data: Entity: line 2: parser error : Start tag expected, '<'
not found

^

I assume this is due to the < being some other character, because
rewriting the header worked well.
There were also a couple of & signs in the XML which need to be 
escaped for XML.

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.

When I validate again after fixing the issues, I get:

W - org.winehq.wine.development.appdata.xml:org.winehq.wine.development:7
The metadata itself does not seem to be licensed under a permissive license.
Please license the data under a permissive license, like FSFAP,
CC-0-1.0 or MIT to
allow distributors to include it in mixed data collections without
the risk of
license violations due to mutually incompatible licenses.

The file is still full of control characters though (open in with vim
to see them...).
Otherwise the file looks fine, a screenshot might be nice though.
(Edited file is attached)

Cheers,
Matthias

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

-- 
I welcome VSRE emails. See http://vsre.info/


  org.winehq.wine.development
  LGPL-2.1+
  LGPL-2.1+
  Wine (development version)
  Run Windows applications on Linux, BSD, Solaris and Mac OS X

  

  Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility
  layer capable of running Windows applications on several POSIX-compliant
  operating systems, such as Linux, Mac OSX,  BSD. Instead of simulating
  internal Windows logic like a virtual machine or emulator, Wine translates
  Windows API calls into POSIX calls on-the-fly, eliminating the performance
  and memory penalties of other methods and allowing you to cleanly integrate
  Windows applications into your desktop.

  

  wine
  wine.png
  http://example.com/icons/foobar.png

Bug#848839: AppStream metadata for Wine

[Jens Reyer]

Hi Matthias,

I'm working on an AppStream file for Wine (winehq.org), mainly to have
it shown in the Software Center. I'm mostly done by now (initial version
attached, icons are not finished yet, and stuff in there is still static).

Now I got a few questions.  I hope you can help me, or tell me a better
place to ask.



Background:

I assume you generally know Wine.

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.

Wine itself is not a graphical application, but of course it can be used
to run such.  On its own it has a few graphical helper applications
(winecfg, notepad, ...), but also provides e.g. wineconsole.



1.) Component type "desktop" or "generic"?

Which one should we use, given above described background?
Is "generic" visible in the software center?
Does "generic" accept tags which are defined only for "desktop"?



2.) License

I'd like to stick with the upstream license LGPL-2.1+.
Does this work for AppStream purposes?
Alternatively I'm thinking about e.g. "LGPL2.1+ or MIT".



3.) Which "id" should we use?

Stretch will ship 2 versions of Wine:

- src:wine which tracks upstreams stable branch
- src:wine-development which tracks the development branch

I thought about ignoring the desktop file completely, and use for
upstream and our src:wine:

​  org.winehq.wine
​  Wine

Then I'd expand the id and change the name for src:wine-development to

​  org.winehq.wine.development
​  Wine (development version)


Thanks in advance!
Greets
jre

​
​
​  org.winehq.wine.development
​  LGPL-2.1+
​  LGPL-2.1+
​  Wine (development version)
  ​Run Windows applications on Linux, BSD, Solaris and Mac OS X  
​
​  
​
​  Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility
  layer capable of running Windows applications on several POSIX-compliant
  operating systems, such as Linux, Mac OSX, & BSD. Instead of simulating
  internal Windows logic like a virtual machine or emulator, Wine translates
  Windows API calls into POSIX calls on-the-fly, eliminating the performance
  and memory penalties of other methods and allowing you to cleanly integrate
  Windows applications into your desktop.
​
​  

  wine
  ​wine.png
  ​http://example.com/icons/foobar.png
  ​/usr/share/pixmaps/foobar.png

  https://www.winehq.org/
  https://bugs.winehq.org/
  https://wiki.winehq.org/FAQ
  https://wiki.winehq.org/
  https://www.winehq.org/donate
  https://wiki.winehq.org/Translating
​  WineHQ

​  

​  
​Bug fixes only, we are in code freeze.
​  
​
​  

  
​application/x-ms-dos-executable
​application/x-msi
​application/x-ms-shortcut
 ​ 
​