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
- Queries
- All Stories
- Search
- Advanced Search
Feed Advanced Search
Advanced Search
Advanced Search
Nov 9 2020
Nov 9 2020
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
Jan 12 2020
Jan 12 2020
@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).
Sep 16 2019
Sep 16 2019
mak added a comment to T10972: KDE Applications release scripts should add release notes to appstream files.
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?
Sep 15 2019
Sep 15 2019
mak added a comment to T10972: KDE Applications release scripts should add release notes to appstream files.
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)
Aug 21 2019
Aug 21 2019
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 :)
Aug 20 2019
Aug 20 2019
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
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,
Jan 26 2019
Jan 26 2019
trivial: Fix typo
Jan 10 2019
Jan 10 2019
@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
Oct 23 2018
Oct 23 2018
@ltoscano (I've replied to the Github issue as well):
Oct 16 2018
Oct 16 2018
In D15221#342786, @elvisangelaccio wrote: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)
Sep 5 2018
Sep 5 2018
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.
Sep 3 2018
Sep 3 2018
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.
Jun 30 2018
Jun 30 2018
Jun 28 2018
Jun 28 2018
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
May 27 2018
May 27 2018
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.
Apr 28 2018
Apr 28 2018
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).
Apr 27 2018
Apr 27 2018
@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.
Apr 10 2018
Apr 10 2018
Mar 30 2018
Mar 30 2018
Mar 25 2018
Mar 25 2018
mak added a comment to T8237: Appstreamercli tests all fail due on copying some badly named file (appdatafile::desktopfile).
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.
Mar 21 2018
Mar 21 2018
mak added a comment to T8237: Appstreamercli tests all fail due on copying some badly named file (appdatafile::desktopfile).
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.
Mar 6 2018
Mar 6 2018
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
Mar 5 2018
Mar 5 2018
Mar 4 2018
Mar 4 2018
Feb 21 2018
Feb 21 2018
Update AppStream metadata
Jan 15 2018
Jan 15 2018
Oct 9 2017
Oct 9 2017
Sep 25 2017
Sep 25 2017
Aug 30 2017
Aug 30 2017
Do not hardcode path to appstream header
Aug 28 2017
Aug 28 2017
mak added inline comments to D7567: Support edit and appstream actions also for application search results.
mak added inline comments to D7567: Support edit and appstream actions also for application search results.
Aug 17 2017
Aug 17 2017
mak committed R204:23c91fbbc1b7: trivial: Use NoDisplay instead of Hidden for importer .desktop file (authored by mak).
trivial: Use NoDisplay instead of Hidden for importer .desktop file
Jul 13 2017
Jul 13 2017
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 :-)
Apr 12 2017
Apr 12 2017
mak added a comment to D5405: Create desktop file name based on organization domain unless set explicitely.
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?
Mar 20 2017
Mar 20 2017
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.
Mar 14 2017
Mar 14 2017
Any app.desktop with Type=Application needs an appdata file?
In this repo that would be simond, afaras, ksimond, sam, scc and sccd
Mar 13 2017
Mar 13 2017
Looks good to me!
Feb 5 2017
Feb 5 2017
Jan 8 2017
Jan 8 2017
Set better icon for Apper
Jan 6 2017
Jan 6 2017
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)
Jan 4 2017
Jan 4 2017
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)
Jan 3 2017
Jan 3 2017
@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 ;-)
Nov 21 2016
Nov 21 2016
Nov 14 2016
Nov 14 2016
FTR, it always worked, it was just not validated properly ;-)
Oct 31 2016
Oct 31 2016
trivial: Fix minor AppStream porting quirk
trivial: Fix terminology
Sep 20 2016
Sep 20 2016
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).
Jul 28 2016
Jul 28 2016
@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
Jul 27 2016
Jul 27 2016
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.
Jul 25 2016
Jul 25 2016
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).
Jul 22 2016
Jul 22 2016
Works well for me!
Jun 16 2016
Jun 16 2016
Jun 13 2016
Jun 13 2016
In D1844#34142, @sebas wrote:Should also have a screenshot?
Apr 15 2016
Apr 15 2016
mak committed R134:683642fb214b: Account for components having no package as installation candidate (authored by mak).
Account for components having no package as installation candidate
mak committed R134:2041064c3597: Account for components having no package as installation candidate (authored by mak).
Account for components having no package as installation candidate
Mar 7 2016
Mar 7 2016
Make libDiscoverNotifiers private too
Make libDiscoverNotifiers private too
Make libdiscover a private library
Make libdiscover a private library
Feb 17 2016
Feb 17 2016
mak committed R73:fe7ec09c52c9: trivial: Use cmake var to install AppStream metainfo (authored by mak).
trivial: Use cmake var to install AppStream metainfo
Jan 12 2016
Jan 12 2016
mak added a comment to D797: Require user to authenticate when trying to change lock screen settings.
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.
trivial: Small .desktop file style fixes
Nov 11 2015
Nov 11 2015
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.
Sep 8 2015
Sep 8 2015
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.
Sep 7 2015
Sep 7 2015
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.