Oxygen font error: font-metainfo-but-no-font

[jbicha]

Ubuntu 17.04
appstream-generator 0.6.3

The same version (5.4.3-3) of fonts-oxygen is present in both Debian and Ubuntu, but Ubuntu's appstream generator gives an error:

font-metainfo-but-no-font
A metainfo file with component-type font was found, but we could not find any matching
font file (TrueType or OpenType) in the package.
This can mean that the <provides> - <font> tags contain wrong values that we could not
map to the actual fonts, or that the package simply contained no fonts at all. 

http://appstream.ubuntu.com/zesty/universe/issues/fonts-oxygen.html

https://appstream.debian.org/sid/main/metainfo/fonts-oxygen.html
(No issues page on Debian)

fonts-oxygen does contain these fonts:

/usr/share/fonts/truetype/oxygen/Oxygen-Sans-Bold.ttf
/usr/share/fonts/truetype/oxygen/Oxygen-Sans.ttf
/usr/share/fonts/truetype/oxygen/OxygenMono-Regular.ttf

https://sources.debian.net/src/oxygen-fonts/unstable/debian/patches/01_add-metainfo.patch

A different font works

I recently added appstream metainfo for Cantarell in Ubuntu 17.04. I didn't specify any Provides but it shows up in Software (only if you explicitly search for Cantarell; I don't see it listed in any Category or in Installed.)

[iainlane]

I reprocessed the package and now it shows up (not exported yet).

Type: font
ID: org.kde.oxygen-fonts
Package: fonts-oxygen
Name:
  C: Oxygen Fonts
Summary:
  C: A desktop/gui font family for integrated use with the KDE desktop

etc.

I would guess that the time of the upload of oxygen-fonts, our version of asgen was behind what Debian had deployed.

It would be a good contribution for someone to provide a forget/retry action for the generator so that uploaders can do this themselves.

I think you should forward that metainfo if you didn't already.

[ximion]

It would be a good contribution for someone to provide a forget/retry action for the generator so that uploaders can do this themselves.

What would you have in mind? The generator itself providing a REST API somewhere, or just writing a config file somewhere (created by another tool) which is read by asgen to reprocess stuff?

To make this work sanely directly in asgen, asgen would need some kind of task queue in the database, where people can add requests like "reprocess X" or "run cleanup next time" or even "process Y" if there is an interface with the archive software.
Don't know if that's overengineered though.

[iainlane]

On Tue, Mar 14, 2017 at 07:21:15AM -0700, Matthias Klumpp wrote: > It would be a good contribution for someone to provide a forget/retry action for the generator so that uploaders can do this themselves. What would you have in mind? The generator itself providing a REST API somewhere, or just writing a config file somewhere (created by another tool) which is read by asgen to reprocess stuff? To make this work sanely directly in asgen, asgen would need some kind of task queue in the database, where people can add requests like "reprocess X" or "run cleanup next time" or even "process Y" if there is an interface with the archive software. Don't know if that's overengineered though.

I don't know TBH, that would be up the implementer. Having it external would probably be easier. Cheers,

…

-- Iain Lane [ iain@orangesquash.org.uk ] Debian Developer [ laney@debian.org ] Ubuntu Developer [ laney@ubuntu.com ]

[ximion]

@iainlane Yeah, external sounds better at time...
(I am still thinking about making asgen use MongoDB as backend from time to time, but Mongo is a huge dependency and having it would hurt people who just want a simple tool to generate data for a small repo - while Debian and Ubuntu would benefit from it)

[jbicha]

I didn't realize Ubuntu didn't run the generator across the whole archive daily (in the development release), but just against updated packages. I would at least have expected a full rebuild after a new asgen was deployed.

How long does a full rebuild take?

Is Debian's asgen deployment incremental too?

[ximion]

@jbicha Depending on how much RAM and CPU is available, a full rebuild takes multiple hours. Every package in the archive needs to be opened up, which takes a bit of time. Asgen has a remove-found option which just drops the information about found components, and doesn't also wipe the contents cache. In that case, processing is faster but still takes an hour or more time.

Debian's rebuilds are incremental too, but I refresh the data from time to time using remove-found, normally after a new AppStream or asgen release when I know that things have changed (if there's something bigger, I usually mention that in the NEWS file too).

[ximion]

@jbicha Btw, by looking at http://appstream.ubuntu.com/zesty/universe/metainfo/fonts-cantarell.html: The file should really have one or multiple provides->font entries. If there are none, asgen will just try to guess the font and that usually works out poorly, for example a random font face will be picked for the default font example screenshot and for the font's icon.
If a provides entry is there, the first font in the list is picked as the main font face to represent the specific font family.

See https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Fonts.html for information on font metainfo files.
Asgen just warns about this at time, since it sort of works for maybe 70% of all fonts, but it's not really recommended to rely on that.