- User Since
- Jul 29 2015, 9:35 AM (186 w, 1 d)
Sat, Jan 26
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
@ltoscano (I've replied to the Github issue as well):
Oct 16 2018
Sep 5 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 28 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
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
@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
Mar 30 2018
Mar 25 2018
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
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 5 2018
Mar 4 2018
Feb 21 2018
Jan 15 2018
Oct 9 2017
Sep 25 2017
Aug 30 2017
Aug 28 2017
Aug 17 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
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
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
Looks good to me!
Feb 5 2017
Jan 8 2017
Jan 6 2017
Jan 4 2017
(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
@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 14 2016
FTR, it always worked, it was just not validated properly ;-)
Oct 31 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
@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
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
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
Works well for me!
Jun 16 2016
Jun 13 2016
Apr 15 2016
Mar 7 2016
Feb 17 2016
Jan 12 2016
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
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
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.