Appstream metadata compose failures

[Kalev Lember]

Hi,

hughsie just did a new appstream-data compose for F29 and I noticed
there's quite a large number of packages failing in the logs:

https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html

Would be awesome if maintainers could have a look and see if they can
make their packages pass!

-- 
Thanks,
Kalev

[Robert-André Mauchin]

On vendredi 2 mars 2018 11:28:40 CET Kalev Lember wrote:
>  Hi,
>  
>  hughsie just did a new appstream-data compose for F29 and I noticed
>  there's quite a large number of packages failing in the logs:
>  
>  https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
>  
>  Would be awesome if maintainers could have a look and see if they can
>  make their packages pass!
>  
>  -- 
>  Thanks,
>  Kalev
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 

qdirstat.desktop
Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/
apps/qdirstat.png, Has no Icon

Well, what if upstream doesn't provide bigger icons?

[Kalev Lember]

On 03/02/2018 02:56 PM, Robert-André Mauchin wrote:
>  qdirstat.desktop
>  Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/
>  apps/qdirstat.png, Has no Icon
>  
>  Well, what if upstream doesn't provide bigger icons? 
I believe the answer is to work with upstream to provide updated icons.

I would personally be a bit more lax with what icon sizes we allow, but
right now we require at least a 64x64px icon.

-- 
Kalev

[Robert-André Mauchin]

On vendredi 2 mars 2018 15:10:59 CET Kalev Lember wrote:
>  On 03/02/2018 02:56 PM, Robert-André Mauchin wrote:
>  
>  > qdirstat.desktop
>  > Failed to load icon: icon was too small 32x32:
>  > /usr/share/icons/hicolor/32x32/ 
 apps/qdirstat.png, Has no Icon
>  > 
>  > Well, what if upstream doesn't provide bigger icons?
>  
>  
>  I believe the answer is to work with upstream to provide updated icons.
>  
>  I would personally be a bit more lax with what icon sizes we allow, but
>  right now we require at least a 64x64px icon.
>  
>  -- 
>  Kalev
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
Also, with what command can I check if my package is now ok?

Best regards,

Robert-André

[Richard Hughes]

On 2 March 2018 at 14:44, Robert-André Mauchin <zebob.m(a)gmail.com&gt; wrote:
>  Also, with what command can I check if my package is now ok? 
From memory, I think you can do "appstream-builder
name-of-the-file.rpm" and if it makes it into the example.xml.gz file
then it passed all the checks.

Richard.

[Richard Hughes]

On 2 March 2018 at 14:10, Kalev Lember <kalevlember(a)gmail.com&gt; wrote:
>  I believe the answer is to work with upstream to provide updated
> icons. 
Right, or patch them in the srpm. Working upstream is obviously better
than all the distros having to do the same thing...

>  I would personally be a bit more lax with what icon sizes we allow,
> but
>  right now we require at least a 64x64px icon. 
64x64 is a very low bar indeed, compared to all of the other
platforms, e.g. Windows Store or the Apple AppStore.

Richard.

[Kevin Kofler]

Richard Hughes wrote:
>  64x64 is a very low bar indeed, compared to all of the other
>  platforms, e.g. Windows Store or the Apple AppStore. 
All that's going to happen with such a requirement is that specfiles are 
going to run the icon through scale2x or hq2x if you're lucky, through a 
dumb ImageMagick convert resize if you're not.

You cannot expect the packager to draw a new icon for upstream software.

        Kevin Kofler

[Michael Schwendt]

On Fri, 02 Mar 2018 16:11:23 +0100, Kevin Kofler wrote:

>  Richard Hughes wrote:
>  > 64x64 is a very low bar indeed, compared to all of the other
>  > platforms, e.g. Windows Store or the Apple AppStore.  
>  
>  All that's going to happen with such a requirement is that specfiles are 
>  going to run the icon through scale2x or hq2x if you're lucky, through a 
>  dumb ImageMagick convert resize if you're not.
>  
>  You cannot expect the packager to draw a new icon for upstream software. 
One cannot even expect upstream to ship appdata files. The Claws Mail
developers have had some in their tarball for short time for every
plugin, then have dropped them again in the next minor release.
Probably due to maintenance overhead and missing translations.
http://git.claws-mail.org/?p=claws.git;a=tree;f=appdata;hb=HEAD

[Kevin Kofler]

PS:

I wrote:

>  Richard Hughes wrote:
> > 64x64 is a very low bar indeed, compared to all of the other
> > platforms, e.g. Windows Store or the Apple AppStore.
>  
>  All that's going to happen with such a requirement is that specfiles are
>  going to run the icon through scale2x or hq2x if you're lucky, through a
>  dumb ImageMagick convert resize if you're not. 
… or in the worst case, they will just do nothing and AppStream will keep 
ignoring the application, which is sadly the current status quo for many 
packages.

        Kevin Kofler

[Michael Schwendt]

On Sat, 03 Mar 2018 19:42:48 +0100, Kevin Kofler wrote:

>  PS:
>  
>  I wrote:
>  
>  > Richard Hughes wrote:  
>  >> 64x64 is a very low bar indeed, compared to all of the other
>  >> platforms, e.g. Windows Store or the Apple AppStore.  
>  > 
>  > All that's going to happen with such a requirement is that specfiles are
>  > going to run the icon through scale2x or hq2x if you're lucky, through a
>  > dumb ImageMagick convert resize if you're not.  
>  
>  … or in the worst case, they will just do nothing and AppStream will keep 
>  ignoring the application, which is sadly the current status quo for many 
>  packages. 
This new opt-in style has never been a good idea. The software features
an "All" button, which doesn't show all packages, which is misleading.

And then there's category "Communication & News", and an Email client
is
stored within the "Chat" subcategory. Ouch.

[Richard Hughes]

On 4 March 2018 at 12:25, Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:
>  This new opt-in style has never been a good idea. The software
> features
>  an "All" button, which doesn't show all packages, which is misleading.
It's not misleading; gnome-software is an application installed, not a
package installer. To anyone that says we should just show all
installed packages I just say "texlive".

>  And then there's category "Communication & News",
> and an Email client is
>  stored within the "Chat" subcategory. Ouch. 
I'm not sure what "ouch" means in this context. If you file a bug we
can discuss the proper category for this specific application, but I
don't think adding snide remarks is going to achieve anything.

Richard.

[Richard Shaw]

On Fri, Mar 2, 2018 at 8:10 AM, Kalev Lember <kalevlember(a)gmail.com&gt; wrote:

>  On 03/02/2018 02:56 PM, Robert-André Mauchin wrote:
>  > qdirstat.desktop
>  > Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/
>  32x32/
>  > apps/qdirstat.png, Has no Icon
>  >
>  > Well, what if upstream doesn't provide bigger icons?
>
>  I believe the answer is to work with upstream to provide updated icons.
>
>  I would personally be a bit more lax with what icon sizes we allow, but
>  right now we require at least a 64x64px icon. 

Since the freedesktop minimum[1] is a 48x48 icon, perhaps it would be best
to be aligned with it.

Thanks,
Richard

[1]
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-la...

[Dennis Gilmore]

El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió:
>  Hi,
>  
>  hughsie just did a new appstream-data compose for F29 and I noticed
>  there's quite a large number of packages failing in the logs:
>  
>  https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
>  
>  Would be awesome if maintainers could have a look and see if they can
>  make their packages pass!
>   
We were supposed to make builds fail if the appstream metadata failed,
why has that not been done?

Dennis

[Kalev Lember]

On 03/02/2018 03:59 PM, Dennis Gilmore wrote:
>  El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió:
> > Hi,
> >
> > hughsie just did a new appstream-data compose for F29 and I noticed
> > there's quite a large number of packages failing in the logs:
> >
> > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
> >
> > Would be awesome if maintainers could have a look and see if they can
> > make their packages pass!
> >
>  We were supposed to make builds fail if the appstream metadata failed,
>  why has that not been done? 
Sorry, I dropped the ball on this. I believe we need a brp script for
rpmbuild that runs:

  DESTDIR=%{buildroot} appstream-util check-root

and errors out if it fails.


-- 
Kalev

[Vít Ondruch]

Dne 2.3.2018 v 16:13 Kalev Lember napsal(a):
>  On 03/02/2018 03:59 PM, Dennis Gilmore wrote:
> > El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió:
> >> Hi,
> >>
> >> hughsie just did a new appstream-data compose for F29 and I noticed
> >> there's quite a large number of packages failing in the logs:
> >>
> >> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
> >>
> >> Would be awesome if maintainers could have a look and see if they can
> >> make their packages pass!
> >>
> > We were supposed to make builds fail if the appstream metadata failed,
> > why has that not been done?
>  Sorry, I dropped the ball on this. I believe we need a brp script for
>  rpmbuild that runs:
>
>    DESTDIR=%{buildroot} appstream-util check-root
>
>  and errors out if it fails.
>
>  
AppData packaging guidelines [1] requires every package to run
"appstream-util validate-relax". Does this check fail when the icon has
not valid size?

Of course moving this into BRP script would be probably better ...

Vít



[1]
https://fedoraproject.org/wiki/Packaging:AppData#app-data-validate%20usage

[Kalev Lember]

On 03/05/2018 10:25 AM, Vít Ondruch wrote:
>  AppData packaging guidelines [1] requires every package to run
>  "appstream-util validate-relax". Does this check fail when the icon has
>  not valid size? 
No, because the icon comes from the .desktop file and 'appstream-util
validate ... appdata.xml' only works on appdata.xml files. To have a
chance of checking the icon sizes we'd need to replace it with
'appstream-util check-root' which then checks the .desktop file and
.appdata.xml and possibly icon files as well (not entirely sure it does
icon file checks right now, but at least it's possible by design then).

>  Of course moving this into BRP script would be probably better ...
Agreed.

-- 
Kalev

[Milan Crha]

On Fri, 2018-03-02 at 11:28 +0100, Kalev Lember wrote:
>  https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
>  
>  Would be awesome if maintainers could have a look and see if they can
>  make their packages pass! 
	Hi,
even not a maintainer, why is evolution-rss in the list, please? There
is no "Vetos" section on that page for it, neither I noticed anything
in a scratch build log I ran for rawhide, finished few minutes ago.
https://koji.fedoraproject.org/koji/taskinfo?taskID=25422190

	Thanks and bye,
	Milan