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. The apps include:
* albumart * apitrace-gui * appstream * asylum * audience * bomber * bovo * calligra-braindump * cervisia * choqok * classified-ads * crrcsim * cube * curblaster * dsi * escape * ettercap * font-manager * freedink-engine * gap-core * gnofract4d * gvrng * hgview * hyperrogue * kaddressbook * key-mon * kgraphviewer * knotes * konqueror * LabPlot * nextcloud-client (maybe fixed in distgit) * openms * openvibe * owncloud-client * pingus * pioneer * portecle * qdigidoc * qjackctl * qsynth * qtikz * recoll * renku * rodent * screengrab * screenruler * simple-ccsm * slashem * spectacle * speed-dreams * tennix * tilp2 * tortoisehg * trophy * tzclock * uzbl-defaults * vdrift * vegastrike * wireshark-gtk * xfce4-power-manager * xfpanel-switch * xskat * yakuake * zanshin * zathura
The full list, along with what failed is available here: https://dl.fedoraproject.org/pub/alt/screenshots/f26/failed.html
If you want any suggestions or advice, I'm happy to help. Most of the failures are pretty self explanatory, e.g. "No <summary> in AppData" or "icon was too small 24x24" -- our guidelines are here: https://github.com/hughsie/appstream-glib/blob/master/README.md#guidelines-f...
As a reminder, you can validate AppData files using: appstream-util validate-relax file.appdata.xml
Thanks, and comments welcome. I can set up a script that sends email to the package maintainer if this would be helpful, but I thought we might be able to get the majority of these sorted with this email.
Richard.
Dne 5.1.2017 v 12:56 Richard Hughes napsal(a):
As a reminder, you can validate AppData files using: appstream-util validate-relax file.appdata.xml
Just to clarify, according to the guidelines, the validation is a *MUST*:
https://fedoraproject.org/wiki/Packaging:AppData#app-data-validate_usage
Vít
On Thu, Jan 5, 2017 at 1:56 PM, Richard Hughes hughsient@gmail.com wrote: [...]
- portecle
[...]
If you want any suggestions or advice, I'm happy to help.
This one has the too small icon "problem". It only has a 32x32 one, and with my (also wearing the Portecle upstream hat) graphical skills a new, better one simply will not appear, and simply resizing/scaling the current one is not IMO an option. Icon contributions are welcome.
On 5 January 2017 at 13:41, Ville Skyttä ville.skytta@iki.fi wrote:
This one has the too small icon "problem". It only has a 32x32 one, and with my (also wearing the Portecle upstream hat) graphical skills a new, better one simply will not appear, and simply resizing/scaling the current one is not IMO an option. Icon contributions are welcome.
The problem is really with modern HiDPI screens. A 32x32 icon scaled up to 64x64 and then again to 128x128 just looks really bad, and the software center designers really don't want apps that just make everything else look ugly.
I don't normally suggest this, but could you take an existing stock icon perhaps from the GNOME icon theme and modify it for your needs? The Portecle icon doesn't look particularly "branded" and it would be pretty easy for someone with inkscape skillz to make distinctive. I'm pretty sure there's a fedora design mailing list too, and that's full of helpful suitably qualified people :)
Richard.
On 05/01/17 05:52 AM, Richard Hughes wrote:
On 5 January 2017 at 13:41, Ville Skyttä ville.skytta@iki.fi wrote:
This one has the too small icon "problem". It only has a 32x32 one, and with my (also wearing the Portecle upstream hat) graphical skills a new, better one simply will not appear, and simply resizing/scaling the current one is not IMO an option. Icon contributions are welcome.
The problem is really with modern HiDPI screens. A 32x32 icon scaled up to 64x64 and then again to 128x128 just looks really bad, and the software center designers really don't want apps that just make everything else look ugly.
I don't normally suggest this, but could you take an existing stock icon perhaps from the GNOME icon theme and modify it for your needs? The Portecle icon doesn't look particularly "branded" and it would be pretty easy for someone with inkscape skillz to make distinctive. I'm pretty sure there's a fedora design mailing list too, and that's full of helpful suitably qualified people :)
Richard. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Wearing designer hat, I will take a look at making a set of icons for PorteClé (keychain in english). Could you submit a request on Fedora Design team page and assign it to my email?
Thanks
On Fri, Jan 6, 2017 at 3:50 AM, Luya Tshimbalanga luya@fedoraproject.org wrote:
Wearing designer hat, I will take a look at making a set of icons for PorteClé (keychain in english). Could you submit a request on Fedora Design team page and assign it to my email?
Thanks! Issue filed, but I cannot seem to find a way to assign it to you: https://pagure.io/design/issue/497
On Thu, Jan 05, 2017 at 03:41:56PM +0200, Ville Skyttä wrote:
This one has the too small icon "problem". It only has a 32x32 one, and with my (also wearing the Portecle upstream hat) graphical skills a new, better one simply will not appear, and simply resizing/scaling the current one is not IMO an option. Icon contributions are welcome.
As a quick fix, I ran the existing icon through Inkscape's "Trace Pixel Art" feature. That gives https://mattdm.fedorapeople.org/misc/portecle.svg, which is not the *worst* thing ever and might serve as a temporary workaround.
For better, you could try https://fedoraproject.org/wiki/Design#Request_Design_Help
On Thu, Jan 5, 2017 at 4:50 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 05, 2017 at 03:41:56PM +0200, Ville Skyttä wrote:
This one has the too small icon "problem". It only has a 32x32 one, and with my (also wearing the Portecle upstream hat) graphical skills a new, better one simply will not appear, and simply resizing/scaling the current one is not IMO an option. Icon contributions are welcome.
As a quick fix, I ran the existing icon through Inkscape's "Trace Pixel Art" feature. That gives https://mattdm.fedorapeople.org/misc/portecle.svg, which is not the *worst* thing ever and might serve as a temporary workaround.
Thanks, I'll look into this.
On Thu, Jan 5, 2017 at 6:56 AM, Richard Hughes hughsient@gmail.com wrote:
- tilp2
It turns out that I am very silly, and, when writing the appstream file for tilp2, never changed "comical.desktop" in the template here [1] to "tilp.desktop".
...whoops! I can, uh, fix that.
However, interestingly, it seems that "appstream-util validate-relax --nonet" doesn't seem to care. It happily validates tilp2's appstream information [2], which is why I never noticed this at the time. I would think that "referenced desktop file doesn't exist on system" should at least be a warning or something when validating?
Ben Rosser
[1] https://fedoraproject.org/wiki/Packaging:AppData#.appdata.xml_file_creation
[2] As evidenced by this scratch-build build I just ran https://koji.fedoraproject.org/koji/taskinfo?taskID=17172267
On 6 January 2017 at 02:16, Ben Rosser rosser.bjr@gmail.com wrote:
It turns out that I am very silly, and, when writing the appstream file for tilp2, never changed "comical.desktop" in the template here [1] to "tilp.desktop". ...whoops! I can, uh, fix that.
:)
However, interestingly, it seems that "appstream-util validate-relax --nonet" doesn't seem to care. It happily validates tilp2's appstream information [2], which is why I never noticed this at the time. I would think that "referenced desktop file doesn't exist on system" should at least be a warning or something when validating?
Well, to do a full validation we need to search for the icon, look for the desktop file and validate the appdata file. This is what you can do with:
$ appstream-util check-root
Although it's best used in the package build system, e.g. for RPM you can do:
DESTDIR=%{buildroot} appstream-util check-root
It's lightly tested, so it if works or breaks please let me know.
Richard.
This amount of breakage (65 packages, *despite* validation), is a sign of a bigger problem. The "validation" is weak, and the filtering applied in gnome-software, i.e. the user interface, is strong and unexpected and silent. IMHO things should be reversed: validation should be proactive and warn about things which are wrong now or will be considered wrong in the future, and no filtering should be done during display.
If there are some issues with an appdata entry, both users and the package maintainers would be much better served if it is displayed, even imperfect and ugly, than not at all. It would be much easier to diagnose things, and would probably encourage more people to fix those visual issues. Currently it's just too easy to never see the problem. Filtering in this final "user" stage just seems to be in the wrong place, and goes against the principle of gentle degradation.
Zbyszek
On Fri, Jan 06, 2017 at 07:26:52PM +0000, Richard Hughes wrote:
On 6 January 2017 at 02:16, Ben Rosser rosser.bjr@gmail.com wrote:
It turns out that I am very silly, and, when writing the appstream file for tilp2, never changed "comical.desktop" in the template here [1] to "tilp.desktop". ...whoops! I can, uh, fix that.
:)
However, interestingly, it seems that "appstream-util validate-relax --nonet" doesn't seem to care. It happily validates tilp2's appstream information [2], which is why I never noticed this at the time. I would think that "referenced desktop file doesn't exist on system" should at least be a warning or something when validating?
Well, to do a full validation we need to search for the icon, look for the desktop file and validate the appdata file. This is what you can do with:
$ appstream-util check-root
Although it's best used in the package build system, e.g. for RPM you can do:
DESTDIR=%{buildroot} appstream-util check-root
It's lightly tested, so it if works or breaks please let me know.
On 11 January 2017 at 15:52, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
This amount of breakage (65 packages, *despite* validation)
Most of those packages don't validate the AppData file...
and no filtering should be done during display.
It isn't -- that status page is for apps that don't even get into the metadata.
If there are some issues with an appdata entry, both users and the package maintainers would be much better served if it is displayed, even imperfect and ugly, than not at all.
You mean just display a stock broken image for the application icon? No description for markup problems?
It would be much easier to diagnose things, and would probably encourage more people to fix those visual issues. Currently it's just too easy to never see the problem. Filtering in this final "user" stage just seems to be in the wrong place, and goes against the principle of gentle degradation.
I think the opposite might be the solution; fail the rpmbuild if the appdata is invalid. Then the packager knows at build time rather than having to check some random status page.
Richard
On Wed, Jan 11, 2017 at 04:03:36PM +0000, Richard Hughes wrote:
On 11 January 2017 at 15:52, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
This amount of breakage (65 packages, *despite* validation)
Most of those packages don't validate the AppData file...
and no filtering should be done during display.
It isn't -- that status page is for apps that don't even get into the metadata.
If there are some issues with an appdata entry, both users and the package maintainers would be much better served if it is displayed, even imperfect and ugly, than not at all.
You mean just display a stock broken image for the application icon? No description for markup problems?
Yeah, I do think that this would be better.
It would be much easier to diagnose things, and would probably encourage more people to fix those visual issues. Currently it's just too easy to never see the problem. Filtering in this final "user" stage just seems to be in the wrong place, and goes against the principle of gentle degradation.
I think the opposite might be the solution; fail the rpmbuild if the appdata is invalid. Then the packager knows at build time rather than having to check some random status page.
Exactly. Make this check the most stringent, to catch the errors in a verbose way. But if it passes, even with warnings, don't filter the application out in later steps.
Zbyszek
Sorry for resurrecting this old thread. But it is again (still?) relevant.
I have just noticed that for example GVim is not visible in Gnome Software. The failure listed here [1] is "Vetos Has no Icon" and I believe this [2] is the fix.
The situation is pretty complex to my taste. But in the GVim case, if the `<launchable>` tag is not included, the `appstream-builder` (also used to build the metadata for `appstream-data` RPM) inserts there this autogenerated version
~~~
<launchable type="desktop-id">org.vim.Vim.desktop</launchable>
~~~
However, if you check the vim-X11 package, it provides `gvim.desktop` file. I think this might be common case for other Apps listed in [1].
BTW if you wonder how the data (including the report [1]) for `appstream-data` RPM are created, here [3] is the script. Locally, you can test the app data as follows. Given that you have your RPMs in current directory such as:
~~~
$ ll total 2176 -rw-r--r--. 1 mockbuild mock 2142482 Oct 10 18:24 'vim-X11-9.1.737-1^1.fc42.x86_64.rpm' -rw-r--r--. 1 mockbuild 1000 81103 Oct 14 15:32 vim-command-t-5.0.5-1.fc42.x86_64.rpm
~~~
You can build the data:
~~~
$ appstream-builder --verbose --packages-dir=. --output-dir=./repodata --basename=fedora-41 --origin=fedora
~~~
Install them into some DESTDIR:
~~~
$ DESTDIR=test appstream-util -v install-origin fedora repodata/{fedora-41.xml.gz,fedora-41-icons.tar.gz}
~~~
And copy them into location, where they are typically installed by `appstream-data` RPM:
~~~
$ sudo cp ~/test/usr/share/app-info/xmls/fedora.xml.gz /usr/share/swcatalog/xml/
~~~
(Stop and) Start the Gnome Software from CLI:
~~~
$ gnome-software --quit; gnome-software --verbose
~~~
But please note that there are other ways G-S can obtain the AppData, such as pulling the from repos (Copr should be able to build those, but not sure if that works, it did not work for me today, but I might be wrong or it does not work for addons, not sure).
HTH
Vít
[1]: https://dl.fedoraproject.org/pub/alt/screenshots/f41/failed.html
[2]: https://src.fedoraproject.org/rpms/vim/pull-request/32
[3]: https://github.com/hughsie/appstream-scripts/blob/master/fedora/fedora-rawhi...