Run strict validation on AppData file

[Alexander Larsson]

On Wed, May 22, 2019 at 2:41 PM Stephan Bergmann <sbergman at redhat.com> wrote:
>
> An issue started to appear when I tried building a new version of
> LibreOffice for Flathub.  While recent test build
> <https://flathub.org/builds/#/builders/32/builds/3710> was successful
> (albeit with warnings), the corresponding official build
> <https://flathub.org/builds/#/builders/32/builds/3811> fails now due to
> validation errors at <https://flathub.org/builds/#/builders/24/builds/370>:
>
> > flatpak run org.freedesktop.appstream-glib validate-strict builddir/*/share/appdata/org.libreoffice.LibreOffice.appdata.xml
> >  in dir /srv/buildbot/worker/build-i386-3/build (timeout 1200 secs)
> >  watching logfiles {}
> >  argv: b'flatpak run org.freedesktop.appstream-glib validate-strict builddir/*/share/appdata/org.libreoffice.LibreOffice.appdata.xml'
> >  using PTY: False
> > builddir/files/share/appdata/org.libreoffice.LibreOffice.appdata.xml: FAILED:
> > • tag-missing           : <translation> not specified
> > • value-missing         : <!-- Copyright [year] [name] --> is not present
> > • aspect-ratio-invalid  : <screenshot> aspect ratio not 16:9 [https://hub.libreoffice.org/screenshots/writer-01.png]
> > • aspect-ratio-invalid  : <screenshot> aspect ratio not 16:9 [https://hub.libreoffice.org/screenshots/calc-02.png]
> > • aspect-ratio-invalid  : <screenshot> aspect ratio not 16:9 [https://hub.libreoffice.org/screenshots/impress-01.png]
> > • aspect-ratio-invalid  : <screenshot> aspect ratio not 16:9 [https://hub.libreoffice.org/screenshots/draw-02.png]
> > • aspect-ratio-invalid  : <screenshot> aspect ratio not 16:9 [https://hub.libreoffice.org/screenshots/base-02.png]
> > • translations-required  : <name> has no translations
> > • translations-required  : <summary> has no translations
> > • translations-required  : <description> has no translations
> > Validation of files failed
> > program finished with exit code 1
> > elapsedTime=3.802360
>
> The previous test build had failed hard due to a missing content_rating
> element in the AppData file.  I complained about that rather surprising
> change of things and thought that I was done for now with massaging
> LibreOffice's AppData after I had added that.  But apparently I was wrong.

Yes, we have been experimenting with being a bit harder on the
requirements on appdata contents.
At some point we were running a pretty strict check as required which
was breaking all sort of builds, but the required stuff are now dialed
down quite a bit.

However, we also run the strict validation as a helper for people. Any
failures here are just a warning and will not really affect anything.
Do with the results as you wish. Ignoring them is fine too.

> Now, I can probably add a copyright comment and do something about the
> screenshot aspect ratios, but the rest of the complaints above leave me
> clueless:
>
> LibreOffice does internally use gettext by now, and it contains various
> /app/share/runtime/locale/*/resource/*/LC_MESSAGES/*.mo files, so I
> should probably add a translation element with attribute type="gettext".
>   But what should the content of that element be?

I'm really not the right guy to ask, but looking at existing practice
it seems the end result looks like:

<component type="desktop">
<id>PTBatcherGUI.desktop</id>
<pkgname>hugin</pkgname>
<name>Hugin batch processor</name>
<name xml:lang="cs">Hugin - Dávkový zpracovatel</name>
<name xml:lang="de">Hugin - Stapelverarbeitung</name>
<name xml:lang="fr">Hugin - Interface grahique pour le traitement par
lots PTBatcher</name>
<name xml:lang="hu">Hugin kötegelt feldolgozó</name>
<name xml:lang="it">Hugin - Elaboratore in serie</name>
<name xml:lang="ru">Графический интерфейс к PTBatcher</name>

But (and this is me guessing here) i think the other tag is a way to
generat this. I.e. you'd have "<translation
type="gettext">gedit</translation>" plus a bunch of gedit.mo files for
various languages, and then some tool would generate the above
xml:lang lines.

Flatpak-builder runs appstream-compose on the upstream appdata file,
which takes it, and the desktop file + icons and generates the final
appstream xml.  Its possible that this does said gettext extraction
too, but don't quote me on this.