How to generate AppStream metadata for Fedora

I’m generating all the Fedora AppStream metadata by hand at the moment. Long term this is going to move to koji, but since we’re still tweaking the generator, adding features and fixing bugs it seems too early to fully integrate things. This is fine if you just care about the official Fedora sources, but a lot of people want to use applications from other less, ahem, free repos.

If you manage a repository and want to generate AppStream metadata yourself it’s really quite easy if you follow these instructions, although building the metadata can take a long time. Lets assume you run a site called MegaRpms and you want to target Fedora 20.

First, checkout the latest version of fedora-appstream and create somewhere we can store all the temporary files. You’ll want to do this on a SSD if possible.

$ mkdir megarpms
$ cd megarpms

Then create a project file with all the right settings for your repo. Lets assume you have two seporate trees, ‘megarpms’ and ‘meagarpms-updates’.

$ cat project.conf
[AppstreamProject]
DistroTag=f20
RepoIds=megarpms,megarpms-updates
DistroName=megarpms-20
ScreenshotMirrorUrl=http://www.megarpms.org/screenshots/

The screenshot mirror URL is required if you want to be able to host screenshots for applications. If you don’t want to (or can’t afford the hosting costs) then you can comment this out and no screenshots will be generated.

Then we can actually download the packages we need to extract. Ensure that both megarpms and megarpms-updates are enabled in /etc/yum.conf.d/ and then start downloading:

$ sudo ../fedora-download-cache.py

This requires root as it uses and updates the system metadata to avoid duplicating the caches you’ve probably already got. After all the interesting packages are downloaded you can do:

$ ../fedora-build-all.py

Now, go and make a cup of tea and wait patiently if you have a lot of packages to process. After this is complete you can do:

$ ../fedora-compose.py

This spits out megarpms-20.xml.gz and megarpms-20-icons.tar.gz — and you now have two choices what to do with these files. You can either upload them with the rest of the metadata you ship (e.g. in the same directory as repomd.xml and primary.sqlite.bz2) which will work with Fedora 21 and higher.
For Fedora 20, you have to actually install these files, so you can do something like this in the megarpms-release.spec file:

Source1: http://www.megarpms.org/temp/megarpms-20.xml.gz
Source2: http://www.megarpms.org/temp/megarpms-20-icons.tar.gz
mkdir -p %{buildroot}%{_datadir}/app-info/xmls
cp %{SOURCE1} %{buildroot}%{_datadir}/app-info/xmls
mkdir -p %{buildroot}%{_datadir}/app-info/icons/megarpms-20
tar xvzf %{SOURCE2}
cd -

This ensures that gnome-software can access both data files when starting up. If you have any other questions, concerns or patches, please get in touch. This is all very Fedora specific (rpm files, Yum API, various hardcoded package names) but if you’re interested in using fedora-appstream on your distro and want to actually do the work I’d welcome patches to make it less fedora-centric. SUSE generates the AppStream files in a completely different way.

How to take 16:9 Screenshots

A few people contacted me after discovering that screenshots should be taken in a 16:9 aspect ratio. The question was basically, how do I do that?

After trying to do this myself for my applications, I too discovered it’s hard. The wmctrl command doesn’t seem to play very nicely with CSD, and certainly won’t work in wayland. So, Owen Taylor (GNOME hacker extraordinaire) to the rescue.

Owen wrote a GNOME Shell extension (which I’ve modified a little) which resizes the current window to a 16:9 size when you press Ctrl+Alt+S. If you press it again, the window will get larger, to the next recommended 16:9 size. Press Ctrl+Alt+Shift+S and the window will get smaller to the previous size. Get the code on github or on extensions.gnome.org. I probably need some more testing as well. Patches very welcome if you’re good at shell extensions :)

With this extension installed I was able to screenshot all my applications that I maintain in no time at all. I’ve been uploading the screenshots into ${projects}/data/appdata and referencing the git.gnome.org URL in the AppData file so anyone can easily update them when the code changes, but this is completely up to you.

AppData Validation Tool Update 2

There’s a new version of the AppData validation tool, and this one actually downloads and validates the screenshots you’ve included in the .appdata.xml files. See the AppData specifications for guidelines on how to make good screenshots.

Get it while it’s hot, appdata-tools-0.1.4.tar.xz or I’ve built Fedora RPMs too.

Please yell if you think you’ve written a valid file, and it fails to validate using the tool. We’ve added a lot more checks, and we’re getting more strict — so please revalidate your file if you’ve already done so. Thanks!

Copyright in AppData files

More AppData news! I’ve been contacted by someone connected to Debian Legal, who apparently want me to add copyright information to the AppData files for licence compliance. Whilst most of the files are CC0 (basically public domain) it doesn’t seem super important, but it is technically required. If you ship an AppData file, I’d appreciate it if you could add <!-- Copyright 2013 First Lastname --> on the second line in the file. I’ve updated the AppData specification examples accordingly.

Additionally, the appdata-validate tool will warning you about missing copyright information if you use the –strict command line argument in the next release.