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.

Frikin’ Awesome Apps (without AppData)

In GNOME Software, we show a list of applications for each category that we think are frikin’ awesome. Some have AppData, and some don’t. For the ones that don’t yet have AppData it leaves the responsibility of writing the long description to the Linux community, where we can push the data back to upstream so that all the distributions can benefit. So far we’ve had a superb reaction from lots of upstream projects.

For Fedora 20 we want all the awesome apps to have AppData, so users can evaluate the application before installing it. It would add a really nice bit of polish to the whole experience. If you can spare 5 minutes and want to help, I’ve got another shared document here.

The list of awesome-but-unloved apps is: audacity, ardour2, gnome-banshee, rosegarden, sound-juicer, doom, openarena, xonotic, tremulous, btanks, frozen-bubble, quadrapassel, neverball, gnomine, wesnoth, supertuxkart, redeclipse, lyx, gparted, virt-manager, eclipse, gitg, monodevelop, blender, shotwell, octave, saoimage, workrave, celestia, polari, pidgin, chromium, pitivi, vlc and openshot. If you want to add any other apps there, please feel free, although I would much prefer the AppData file to go upstream if you’re a contributor or maintainer of a project. Remember, we can’t feature applications on the front page that don’t have AppData, so that’s an added incentive. I’d love to expose more people to blender for instance.

There’s no way I can do all this myself for Fedora 20, so I really need your help. Again. Thanks.

AppData Validation Tool Update

There’s a new version of the AppData validation tool, now with all the reported bug fixed, and a lot of new tests added.

Get it while it’s hot, appdata-tools-0.1.2.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’re now being a lot more strict on things like formatting and the length of paragraphs. Thanks!

 

GNOME Software on MATE and XFCE

Hi all.

tl;dr: If you want to run GNOME Software on MATE or XFCE you need to set an environment variable like GNOME_SOFTWARE_COMPATIBLE_PROJECTS=MATE,GNOME,XFCE

Long version: In the software application we have the problem where applications have the same name and summary, but are targeted against different desktops. We know when an app targets a specific desktop from the AppStream metadata (which currently uses a heuristic from the .desktop file) so we could filter these out client side. At the moment searching for notes gives you two similarly looking results results provided by two different applications: bijiben (GNOME) and xfce4-notes (XFCE). Also, because of the shared history, a lot of the MATE applications have the same name as the GNOME ones. This makes bad UI.

The default is GNOME_SOFTWARE_COMPATIBLE_PROJECTS=GNOME (well, it is gnome-software after-all…) but if you want to show MATE projects and hide the core GNOME ones, just use a setting of MATE. If you want XFCE, GNOME and MATE apps to show, just use MATE,GNOME,XFCE.

As usual, comments and suggestions welcome.