In D6628#676722, @bam wrote:

Thanks for clarifying.

In D6628#676721, @mak wrote:

So, this change looks fine to me now, as it is :-)

And yet it was changed again! :-D
https://github.com/KDE/plasma-desktop/commit/05c230733a1b9d16c0e52eb54955c62d340b94e3

In D6628#676720, @sitter wrote:

These aren't SPDX identifiers but kaboutlicense keywords https://api.kde.org/frameworks/kcoreaddons/html/kaboutdata_8cpp_source.html#l00397

@ngraham Did this have AppStream metadata before? Probably the distribution data still lists this as component, while the new file lists it as addon. The distro data is preferred, so that's why this shows up as app. You need your distro to ship this as update, or set PreferLocalMetainfoData=true in /etc/appstream.conf (that should override the distro-provided data with local one, which is nice for development but not usually desired).

In T10972#200505, @ltoscano wrote:

In T10972#200504, @mak wrote:

Unfortunately even then KDEs translation system makes every metainfo translation *really* hard compared to how GNOME does it, where stuff like this is much simpler)

If the release notes are complete when the freeze happens, which is the rule that should be followed, I don't see how the translation system could get in the way. What is the technical difference with the Gnome system (apart from their recent switch to pure gettext for appdata files), and how would impact the translations?

New versions of appstreamcli can add release information from NEWS files as well as YAML files containing the change information. That should make it easier for people to adopt this feature, if integrated into the build process (I could create an example for that with cmake, I guess).
Remoting release information to web locations will definitely take a while, because not only does this need to be specified, but it also needs to percolate through the whole stack so this works even on older distributions. So, it's better not to wait completely for that solution, but rather start with the existing one and then switch to the other once it becomes available.
(If people would write release notes while working on the release, translators would have a chance to actually translate them before a release is made. Unfortunately even then KDEs translation system makes every metainfo translation *really* hard compared to how GNOME does it, where stuff like this is much simpler)

I didn't test this, but I wrote the code which will handle this and it works in other cases ;-)
My comment was to confirm that the commit does indeed what you intend it to do, according to the spec and code.

Effect is kdesystemsettings.desktop not being shown in any software center.
LGTM

In D23306#515666, @kossebau wrote:

In D23306#515662, @mak wrote:

In D23306#515616, @kossebau wrote:

Thanks! Though reading it, leaves open questions with me:

• what is meant by "referenced"? only via <launchable>?

In modern metainfo files yes, only via launchable. However, if a component id has a .desktop suffix, as was required in the past, and a matching .desktop file is found, that also counts as referenced and the desktop-entry file will be read.

As developer trying to write metainfo files, I would welcome this logic also documented n the docs. The current content of the docs is confusing to me at least.

• if there are two desktop files referenced by <launchable> where one has the ignore entry set, will this overrule the "Data will only be fetched from a desktop file if one <launchable/> tag is present" rules above?

No. A launchable tag always beats whatever was defined in the desktop-entry file itself, so if there is one launchable tag, the .desktop entry file will be taken into consideration no matter what was defined in it (to e.g. merge in category information). Any equivalent data in the metainfo file beats that of the desktop-entry file though. If there are multiple launchable entries, the generator has no idea which .desktop file to read, so rather than reading any and getting information wrong, it will read none (requiring the metainfo author to add all data they want in there explicitly).
This could maybe be made smarter, but tbh this case is so rare that just making the metainfo files more complete in such events seems like the better approach.

So, in our case here, <launchable type="desktop-id">systemsettings.desktop</launchable> actually means there is no need to add X-AppStream-Ignore=true to "kdesystemsettings.desktop" ? Because the generators would ignore it already due to a <launchable> present and pointing to the other desktop file?

This patch looks like it should work as intended to me :)

In D23306#515616, @kossebau wrote:

In D23306#515609, @mak wrote:

@kossebau How to hide .desktop files from AppStream is now more visible in https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#spec-appdata-introduction as a hint.

Thanks! Though reading it, leaves open questions with me:

• what is meant by "referenced"? only via <launchable>?

In D23306#515595, @ngraham wrote:

In fact there are three possible relationships:

• App is associated with desktop, but not required by it or limited to it (e.g. Dolphin, Gwenview, Nautilus, GNOME Music)

In D23306#515592, @ngraham wrote:

In D23306#515589, @mak wrote:

In D23306#515577, @ngraham wrote:

Adjust according to review comments

This will work. I would change <name>System Settings</name> to <name> KDE System Settings</name> or <name>Plasma System Settings</name>, just like GNOME sets a name like "GNOME Videos" instead of "Videos" in their metadata. Otherwise this name will confuse users of GNOME, I guess.

This gets at the original reason why System Settings has two .desktop files: one adds "KDE" onto the beginning of the name when it's not run in Plasma. Ideally we would want the same thing in AppStream:

• Show "KDE Plasma System Settings" in search and browse lists, where the fact that it's for KDE Plasma is otherwise not apparent
• Show "System Settings" in Discover's Updates lists, where the fact that it's for KDE Plasma is implied and redundant because you're seeing it in Plasma's software updater
  
  Is such a thing possible?

Adding a project_group may also be a nice idea: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group

In D23306#515585, @kossebau wrote:

@mak: tnanks for the hint. will also see to use X-AppStream-Ignore for kdevelop then. any chance we can see this trick documented on https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html , please? :)

In D23306#515577, @ngraham wrote:

Adjust according to review comments

@kossebau You'll also want to annotate the .desktop files correctly to hide them. See https://phabricator.kde.org/D23306#515575 for details.

There's also a FAQ entry for this, apparently I only documented this for Debian Developers back in the day ^^
--> https://wiki.debian.org/AppStream/Guidelines#How_to_exclude_.desktop_files_from_the_metadata

@ngraham

Alternative to D23302. According to the AppStream documentation (https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html),
adding an AppStream metadata file with multiple launchable tags will prevent AppStream
info generators from parsing desktop files to determine metadata,

@jriddell This was actually planned for AppStream for a while - we are currently reviewing a spec addition for a new operating-system component. Let's see with what we end up implementation-wise. => https://github.com/ximion/appstream/commit/b4e40f562204e12f866b48a3c04da8b3483bdbf5

@ltoscano (I've replied to the Github issue as well):

In D15221#342786, @elvisangelaccio wrote:

@mak

What if some day someone changes the Dolphin's ID from <id>org.kde.dolphin.desktop</id> to <id>org.kde.dolphin</id> ?
Will it break this appstream file? (since I'm hardcoding .desktop in the IDs)

In D15221#320993, @elvisangelaccio wrote:

[...]
Yeah but appstream requires you to set a specific application's .desktop file that the addon is supposed to extend. So for appstream clients it would become "a dolphin addon", not a generic KIO addon.

You maybe don't want this to be a generic component, but instead make it an addon component instead. See https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html
The addon could extend file manages like Dolphin/Konqueror, or even the Plasma Shell itself.

In D13772#284459, @ngraham wrote:

FWIW, @mak, appstrealcli validate doesn't like my launchable tag, though I can't see anything wrong with it.

dev@dev-pc:~/repos/ksysguard$  (appstream-metadata) appstreamcli validate gui/org.kde.ksysguard.appdata.xml
W - org.kde.ksysguard.appdata.xml:org.kde.ksysguard:7
    Found invalid tag: 'launchable'. Non-standard tags must be prefixed with "x-".

Validation failed: warnings: 1

Checking for the dpkg and rpm binaries isn't really foolproof, because you can install rpm on Debian and dpkg on Fedora & Co. easily.
The only issue proof thing that I can imagine would be checking for the distribution name in /etc/os-release, or maybe checking for the presence of /etc/debian_version.

The intent of the "short summary" wording in the AppStream spec for release descriptions is that people don't start to list every single commit that went into the release there, but give a user-friendly translatable overview there instead.
Future releases of AppStream will contain some tooling to add release entries from easier to write formats (Markdown files, YAML, ...), but doing that will not work with KDEs translation process (it would involve translating the XML metainfo file at build-time, while at the moment translations are injected directly into the file by the KDE l10n script - so, to use that KDE would need to use xgettext at build time in combination with e.g. Weblate).

@sitter How do you generate this data? All fields from the custom tag should end up in the YAML, if raw libappstream is used. If appstream-generator is used, the custom entries that should end up in the final output need to be whitelisted via the AllowedCustomKeys list field in the asgen configuration file.

LGTM

The particular code hasn't been touched in any recent AppStream version, and as far as I can see (at least from the log I found when searching on Jenkins), your AppStream is up to date.
So, I guess it's something else in the image that is broken (especially since this seems to work on other images, I would look for the images generally having no network access, or for some recent curl updates). If appstreamcli is run with the --nonet flag, all actions that require network access are disabled, which can be used as a temporary workaround.

Which version of AppStream do these SUSE images use? In older versions, AppStream was making only header requests, which some webservers did not allow. So newer versions try to download the first byte of a document instead, which should always work.

In D11052#219997, @vanini wrote:

I also modified the template in the wiki page with the suggested changes. I hope that's fine.
https://community.kde.org/Guidelines_and_HOWTOs/AppStream

Looks good to me :-)

Is there any reason not to use the SPDX license IDs here? => https://spdx.org/licenses/ (e.g. GPL-2.0+ in this case).
In any case, this patch makes things way better, so +1 from me :-)

In D5405#101574, @ltoscano wrote:

I'm still confused. Documentation or not, bad usage or not, is it correct that desktop file name is constructed from both the organization domain AND the homepage?

Looks good to me! :-)

Hmm, for some weird reason the diff is the same as before...
In order to have the AppStream metadata generator ignore .desktop files that are in /usr/share/applications/ you must add an X-AppStream-Ignore=true field to them (likely to all except for the org.kde.simon.desktop one).
Otherwise, the other .desktop files might show up in software centers as well.

Any app.desktop with Type=Application needs an appdata file?
In this repo that would be simond, afaras, ksimond, sam, scc and sccd

Looks good to me!

Looks good!

In D3923#73574, @anthonyfieroni wrote:

In D3923#73375, @mak wrote:

In any case, knowing the distro might be useful to check whether their packaging makes sense ;-)

KaOS don't have appstream nor appstreamQt nor Discover (it's a fairly normal when first two are missing)

Looks good!
(appstreamPool is a bit verbose for my taste, AppStream interally calls it dpool (DataPooL) asPool or just pool - but that's just me being lazy and having to type too much n C anyways)

@davidedmundson What do you mean with big dependency chain? libappstream and libappstreamQt depend in total on only libxml2, libyaml, GLib and Qt5Core which pretty much any distro, especially with Plasma on it, should already have anyway.
Didn't you use Neon? Or was it Manjaro/Arch? In any case, knowing the distro might be useful to check whether their packaging makes sense ;-)

FTR, it always worked, it was just not validated properly ;-)

Hard thing to do, because we only allow components of type addon to extend anything, so this can not work (changing that assumption would be massive breakage which I don't want to do).

@sitter Depends on the amount of pain you want to have with this ^^
I would really not merge the Debian data, because:

• It might use the wrong packages
• It might be for a much more recent release than what Ubuntu had available

Ah, and for incomplete data: If you upload a fixed-up package into Neon, asgen should pick it up and generate valid data. reprocessing the Ubuntu data with a newer asgen isn't possible though, since the Ubuntu data is frozen in time.
(of course you could reprocess the full Ubuntu archive, but that's meh...) reprocessing would IMHO only be interesting as soon as asgen can handle fonts properly.

@sitter Oh, looks like you misunderstood me there ^^
I think it's fine to fetch the appstream.debian.org output for your Snappy-description hacks - for actually shipping the data with Neon, you should really run asgen on your packages.

Hack and Source Code Pro are beautiful fonts for programming - from a Debian perspective, there is no reason to not use Hack, we have it in the archive already (I don't know about Source Code Pro though).

Works well for me!

In D1844#34142, @sebas wrote:

Should also have a screenshot?

In D797#15210, @davidedmundson wrote:

This breaks every user's backup script by having root files in the user's home. So I am very much not happy with this idea at all.
Especially as it acheives very little anyway, if you have a malicious app on your system - why on Earth does it want to modify your lock screen settings when it has access to everything the user has already?

We want to sandbox apps that might misbehave from the user, not elevate user processes above the user.

Okay, I made the latest release available in the vivid suite of that PPA. Adding the PPA will also upgrade glib2 and cmake in the process, I hope that doesn't cause any problems (it actually shouldn't). At least the dependency on a recent GLib2 is necessary.
For Wily, no additional dependencies had to be added, and Xenial already has the latest release in the official repos.

The PPA in question already exists, and I use it for Limba, PackageKit and AppStream: https://launchpad.net/~ximion/+archive/ubuntu/packagekit/+packages
The Vivid suite currently holds an up2date AppStream and PackageKit, so other packages that could interfere with something.
I could also create a PPA containing *only* the AppStream package, if you want - but IMHO the ASLIPK repo should be fine :-)

I think it would make sense to have a very recent version of appstreamcli, so in case some new checks are added we can benefit from them immediately.
That said, Debian has the latest version in Testing and Unstable, the version in Wily is a little bit outdated and the version in Vivid is very outdated.

I just made a release of AppStream which contains the new validate-tree subcommand (still marked as unstable though, means I might change the name of the command or its semantics, although that's not very likely to happen).
Users of Debian unstable just need to upgrade to get it (and have the appstream package installed). I am thinking about filling a sync request for Ubuntu, since their version in the archive is broken with current DEP-11 metadata.

Oh, I forgot to add: You can get an up-to-date Git snapshot of AppStream via

git clone https://github.com/ximion/appstream.git
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make && sudo make install

The dependencies are pretty light, and should be available on any Linux distribution.