Postings by Richard Hughes

Removal of glibc-langpacks-all -> 1.0?kB

Hi all,

One of my package builds (fwupd) in F30 is failing in the unit tests,
with this failure comparing the expected output of a to_string()

- Size: 1.0 kB
+ Size: 1.0?kB

I assume it's due to the removal of glibc-langpacks-all from the
buildroot. I'ts not immediately obvious from reading
<a href="" title=""></a>
and <a href="" title=""></a>
what I'm supposed to do.

Got NVMe hardware? I need you!

Hi all,

I've started to look at adding firmware updates for NVMe hardware to
the LVFS project (realistically for Fedora >= 31, so don't get too
excited). Before I know which vendors to approach, and what I need to
ask for, I need to get some statistics about the NVMe hardware the
"typical linux user" is using. I've expanded a lot on the
<a href="" title=""></a>
blog entry I wrote a few days ago if you'd like some more explanation
and justification.

So, what do I would like you to do.

fwupd license change

Hi all,

Just a small unimportant notice that I'm required to do: fwupd changed
license from "GPLv2+ AND LGPLv2+" to just "LGPLv2+".

Package name of flask_oauthlib


I've packaged up flask_oauthlib to use for a project I'm developing,
and am close to submitting it for a Fedora package review. I'm
wondering if the underscore should be used, and the package guidelines
tell me to ask here. The source package could either be:

* python-flask_oauthlib
* python-flask-oauthlib

The upstream itself is somewhat conflicted, as the module name is
flask_oauthlib and the source tarball is Flask-OAuthlib.

Heads up: fwupd in rawhide (not f27) will bump the soname

The only thing in Fedora using libfwupd is currently gnome-software,
which will also be rebuilt by me (as also the upstream maintainer).

Any problems, yell.


Raising requirement for application icons in GNOME Software

Hi all,

At the moment the appstream-builder requires a 48x48px application
icon[1] to be included in the AppStream metadata. I'm sure it's no
surprise that 48x48 padded to 64x64 and then interpolated up to
128x128 (for HiDPI screens) looks pretty bad. For F28 and higher I'm
going to raise the minimum size to 64x64 which I hope people realize
is actually a really low bar.

Adding AppData <content_rating> to all games in Fedora?

Hi all,

For over a year I've been asking application authors upstream to add
support for the OARS content rating scheme for any apps that are
tagged as games. This means we can show some advisory text (note: no
apps are ever hidden) in the details panel on each game we show in the
software center. This helps parents to make a decision on what
applications are suitable to install for their children. It also
allows distros to choose what applications are going to be featured
depending on the locale they are aimed for.

New pastebin service on

I'm not sure if this is the right mailing list for this issue.
Basically, the site has been recently changed,
and it's basically useless for me now. This screenshot shows the
issue: <a href="" title=""></a>

My frustration is that with all the beautifully designed CSS and
padded chrome around everything we can only fit 22 lines of actual
text on the screen. That's about half of the lines that I can get when
using <a href="" title=""></a> and a third of what I can get with
<a href="" title=""></a>.

Applications with AppData and not visible in the software center

We've been looking at the AppStream extractor issues in Fedora, and
we've come across a few broken applications. Broken apps are not
visible in the application installer.

AppStream issues with various KDE applications

Hi all,

We've been looking at the AppStream extractor issues in Fedora 25, and
we've come across quite a few broken KDE applications.

AppData content ratings for games shipped in Fedora

Hi all,

The latest feature we want to support upstream is age classifications
for games. I've asked all the maintainers listed in the various
upstream AppData files (using the update contact email address) to
generate some OARS metadata and add it to the .appdata.xml file, but
of course some AppData files do not have any contact details and so
they got missed. I'm including this email here as I know some AppData
files are included in the various downstream spec files by Fedora

Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

Can we get somebody to revert
<a href="" title=""></a> please.
The update was built to fix CVE-2015-5203 which fixes a double free
when opening corrupt JPEG-2000 files but in doing-so breaks quite a
few apps in the desktop spin causing them to exit with an assert deep
in libjasper.

In the update the function jas_stream_memopen has been changed:

-jas_stream_t *jas_stream_memopen(char *buf, int bufsize);
+jas_stream_t *jas_stream_memopen(char *buf, size_t bufsize);

Unless I'm misunderstood things dramatically, size_t is basically
*unsigned* long integer,

Fedora 24 background is unsuitable

For the upgrade feature the designers [sensibly] want me to use the
default background for the release we're upgrading to. When doing
F23->F24 this makes the upgrade UI look like a big boring black
square: <a href="" title=""></a>

Additionally, when upgraded, the darkness makes the GNOME Shell top
bar almost disappear visually which really doesn't work at all given
the special status it has.

Including content ratings for games


I've been working on a new content rating system called OARS. I wrote
up some notes on my blog[1] but I figured I should also post here for
comments as a lot of packagers also write and update AppData files.

The content rating system I'm going to be proposing has the potential
to cause all kind of politics. We've not yet talked with the designers
about how (or if...) this is going to be shown in the Software Center.
It's probably also worth stating that I think this kind of content
rating should be informational-only, i.e.

GNOME Software 3.19.90 in F23 COPR

I've built a COPR with all the required bits to have GNOME Software
3.19.x in F23; normally this isn't an email-the-world thing but we're
planning to backport just these packages into F23 (unusually for GNOME
components) for the system upgrade-to-f24 functionality and so we
wanted some early testing.

There's no xdg-app support there intentionally (more bits to finish
before the final release) but all the application tagging and review
functionality is there.

AppData and the gettext locale

type="gettext">your_gettext_domain_here</translation> to your AppData

Longer version:

When users are searching for software it is very important to answer
the the question "Is this localized in my language?" The way we
calculate this in the AppStream builder is to look at the compiled .mo
files, breaking them apart and then using statistics to work out what
locales are included.

When we're processing distro packages we usually extract them one at a

Upgrading F24 to F25 :

Hi all,

I'm spending a bit of time getting distro upgrades using GNOME
Software working on rawhide. I've put in a lot of the lower levels of
making this work, but I'm stuck for a data source. Who is responsible
for keeping <a href="" title=""></a> up to date?
If this is obsolete, where should I be getting this high-level
information from?



Applications missing from Fedora 23

The following applications are missing from the software center in F23
beta, although they *are* shipping an AppData file (which seems to
suggest they wanted to be shown):

albumart: No 'Comment' in desktop or <summary> in AppData
albumart: No 'Name' in desktop or <name> in AppData
asylum: icon /usr/share/icons/hicolor/32x32/apps/asylum.png was too small 32x32
atomix: icon /usr/share/pixmaps/atomix-icon.png was too small 32x32
bomber: No 'Comment' in desktop or <summary> in AppData
bovo: No 'Comment' in desktop or <summary> in AppData
COPASI-gui: Uses ICO icon: /usr/share/icons/copasi/icons/Co

Desktop file renaming: ark, dolphin, dragonplayer, kig, kiriki, kshisen and picmi


The following apps changed their desktop name (and not updated the
AppData file at the same time) in the last few weeks:

* ark -> org.kde.ark
* dolphin -> org.kde.dolphin
* dragonplayer -> org.kde.dragonplayer
* kig -> org.kde.kig
* kiriki -> org.kde.kiriki
* kshisen -> org.kde.kshisen
* picmi -> org.kde.picmi

When this happens the filename of the appdata file also has to be
renamed to have to same basename, and the <id> in the AppData file has
to match too.

As it as the 7 applications have disappeared from the software center
in Fedora 22 as AppData files are compulsory now :(

libappstream-glib update

Hi all,

Next week I'm going to update to the new libappstream-glib with a
soname bump in F23 and rawhide. The only deps (gnome-software and
fwupd) just needs updating to the newest releases and these are my
packages also. Any problems, please squeak.


Fedora 22 and missing applications

Quite a few people are going to be installing Fedora 22 in the coming
days, searching for things in the software center and not finding
their esoteric GUI tool. This is because some applications still don’t
ship AppData files, which have become compulsory in the workstation
spin for this release.

Reminder about those renaming .desktop files

Hi all,

I've noticed a few projects have renamed thier .desktop files
recently, i.e. from foo.desktop to an namespace. If you do
change your application-id, please update both the filename of the
AppData file to match the basename of the new .desktop file, AND
change the <id> inside the .appdata.xml file otherwise the metadata
isn't being used.

KDE adoption of AppData is really growing now, and I really thank all
of you who have already added the extra metadata.

Proposal: Drop applications that have FTBFS for the last two releases from the AppStream metadata

The end result would be that we don't show applications that have
failed the previous two releases mass rebuilds in GNOME Software i.e.
we don't show f19 packages in f21, and we don't show f20 packages in
f22. Should be pretty non-controversial, right? The kind of software
that failed two rebuilds in a row really and is sitting unloved by the
downstream maintainer isn't really the kind of software we want to
show. They would still of course be installable on the command line
using dnf.

Speak now, or forever hold your peace, thanks.


Pushing the extra AppData files into Rawhide

In the effort to make the AppStream generation simpler I'm going to
deprecate the fedora-appstream repo[1]. This was always designed to be
a stop-gap until upstreams had done new tarball releases and to
"rescue" applications that we care a lot about, and we're now at a
point where over 50% of upstream software ships AppData and the
general consensus upstream and downstream is that AppData is a good
thing. We've now even put the requirement for AppData in our packaging

I would ask the package maintainer (or a proven packager) to move the
AppData files in the srpm itself.

gdk-pixbuf2 package splitting

I've just pushed two new gdk-pixbuf2 builds to rawhide *not* F22.

* The first splits out the modules (e.g. the ico, jpeg, gif loaders)
to a separate subpackage called gdk-pixbuf2-modules -- which we'll
certainly need on workstation but really not on cloud or text-only
* The second splits out the xlib code which hasn't been touched
upstream since about 2008.

Request for Keywords in .desktop files

Hi all,

19% of applications in Fedora use "Keywords" in the desktop files,
some of which appear in multiple languages. This is awesome, as it
allows applications like apper and gnome-software to match search
queries on the keyword and not just the name, e.g. matching "excel"
for LibreOffice Calc.

Deleting f20-gnome-3-12 copr

I'm planning to delete
<a href="" title=""></a> this
week. The original description always had "This COPR will be updated
until Fedora 21 has been released or until the entropy death of the
universe, whichever happens first." so I don't altogether feel too
guilty about abandoning it. Does anyone have any objections or wants
to volunteer to take it over before I delete the repo?


AppData/AppStream progress in KDE

Hi all,

My name is Richard Hughes, and I'm one of the guys behind the
AppData/AppStream initiative.

AppData Screenshot Requirements

If you want things to be pixel-crisp and your application ships only
one screenshot use 752x423. If you've got multiple screenshots use
624x351, or integer multiples thereof. You can still ship random sized
screenshots bigger than 312x175 and we'll pad them out to the right
size and shape, but choosing a 16:9 resolution makes everything look
consistent in the software center.

PROPOSAL: Make AppData files mandatory for applications shown in the software center

Hi all,

It will come as no surprise to many of you, but I'm going to propose
that we only show applications in the software center in F22 when they
have an AppData file. At the moment nearly 50% of applications in
Fedora 21 ship AppData files, and the ones left over are not exactly
the award winning ones, if you know what I mean. We want the software
center to be a showcase of all the awesome applications available on
Fedora, not just a wrapper around a package installer.

I've attached a list of all the applications that would be affected by
this change.