Bug 1199270

Discussed at 2015-03-09 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-09/f22-blocker-review.2015-03-09-16.05.log.txt . Accepted as a Final blocker per criterion https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_application_functionality :

"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy."

and the Applications and Launchers policy, https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launchers :

"App launchers MUST have a unique 128×128 launcher icon with an alpha channel and a matching High Contrast icon."

Workstation folks, this bug *IS NOW BLOCKING* Fedora 22 Final release. i.e. if we don't have a high-contrast icon for these apps (and all others installed by default) by the day of the Final Go/No-Go meeting, we are required to delay the release. If you don't really want us to slip for releases for icon polish issues, please revise the policy before then, or propose decoupling it from the release criteria.

Thanks!

I highly doubt we would slip for an icon polish issue: that would be silly. The point of the criterion IMO is to ensure we remove the offending apps if they're not fixed in time, not to delay the release. Without the criterion we're not going to be able to keep our 100% HC coverage.

Now, this is really three separate bugs:

1) Not clear to me what's wrong with Rhythmbox. The icons are still present in gnome-themes-standard. Further investigation required.

2) Color Profile Viewer (gnome-color-manager) should probably not be installed by default. I will check with the Workstation folks to make sure it's OK to remove it from comps. Caused by https://git.gnome.org/browse/gnome-color-manager/commit/?id=649c09755bd360d4ed3e40dd4c4e4b120167bac1 where Richard assumed it was not installed by default, so not a gnome-themes-standard issue.

3) For F21 we put the setroubleshoot icon into gnome-themes-standard just to get the release out the door. It's no longer included in gnome-themes-standard (so, not a gnome-themes-standard issue) since we don't want random app icons there (especially apps that are not related to GNOME!). It should be shipped by setroubleshoot. I think Jakub believed it had already been added to setroubleshoot before removing it from gnome-themes-standard; if that's the case, maybe it's not being installed properly.

Hi Jakub. Do you see anything wrong with how Rhythmbox installs its symbolic icon [1]? It looks fine to me. Maybe the shell has gotten confused by the presence of both the symbolic icon and the PNGs in gnome-themes-standard?

[1] https://git.gnome.org/browse/rhythmbox/tree/data/icons/hicolor/scalable/apps/Makefile.am

"I highly doubt we would slip for an icon polish issue: that would be silly. The point of the criterion IMO is to ensure we remove the offending apps if they're not fixed in time"

Well, those two statements seem to contradict each other.

Removing the 'offending' app is a perfectly reasonable response to a blocker bug 'app X has no high-contrast icon', but it's still treating the bug as a blocker. The question isn't 'how should the blocker bug be resolved', but 'should it be a blocker bug at all'. If you want to slip the release if we haven't fixed *or removed* all apps without high-contrast icons, you still want the criterion to be in place.

Created attachment 1000598 [details]
screenshot of overview (F22 Alpha)

This is much more serious than I thought. I installed F22 Alpha and it looks like we have way bigger problems than rhythmbox -- the entire overview is a mess in high contrast mode. There is a mix of proper HC icons, symbolic icons that were not successfully converted to HC icons, and just a big gray square where Rhythmbox is supposed to be. Rhythmbox gets the gray square for its app menu when high contrast is turned off, too. (We also have a "nice" mix of symbolic and hicolor icons used in the app menu regardless of whether high contrast is turned on, but that is an unrelated issue.)

Clearly the applications are not to blame here: something has gone wrong with the changes in upstream bug 737990 (unless this is an intentional incompatibility, in which case we need a rethink).

P.S. We added NoDisplay=true to Color Profile Viewer for 3.15.92.

We will have to live with mix of symbolic and traditional 'hc' icons for a bit. We are transitioning from hc icons (which require black magic to create) to standard symbolic icons (which are much easier to draw). There is no 'conversion' that went wrong.

1) rhythmbox - mysteriously fixed after I ran a system update
2) color profile viewer - "fixed" in 3.15.92 (using NoDisplay=false)
3) setroubleshoot - fix available in bug #1182652

So I think we're good here.