(In reply to David Walser from comment #0)
> (and then at the end of the transaction):
> warning: [filetriggers] could not write matches to script STDIN for trigger
> gtk-icon-cache-HighContrastwarning: [filetriggers] could not write matches
> to script STDIN for trigger gtk-icon-cache-adwaita

RPM is giving that message. IIRC that was changed later? Anyway, not reading STDIN is not something to warn about.

So, does something need to be changed in gtk+2.0 in the filetrigger, or in rpm?

The warning in comment 0 says %postin, but there's no such scriptlet in gnome-icon-theme.spec.

However there's %postun and it will fail because it tries to update the icon cache, but index.theme file (which gtk-update-icon-cache tries to read when updating the cache) is already removed. We have %clean_icon_cache macro which will check the existence of index.theme before updating the cache, but the macro isn't used in gnome-icon-theme.spec.

CC: (none) => jani.valimaa

1. gtk+: don't know. gtk+2.0 vs gtk+3.0 have changed various times. I remember someone making a change to this some time ago, but the specifics I've forgot.
2. RPM shouldn't complain about input not being read. I thought it didn't anymore though.

CC'ing tv since Olav thinks rpm shouldn't be complaining for this scriptlet.

CC: (none) => thierry.vignaud

Patch was done by Colin, not by me

CC: (none) => mageia

*** Bug 15061 has been marked as a duplicate of this bug. ***

CC: (none) => dvgevers

Colin, any idea on this one?

CC: (none) => remi

So there are two things conflated together in this bug.


Yeah, the warning about not being able to write to the trigger scripts stdin really is just a warning - in this case the process probably completes too quickly and stdin write can't happen in time. This is totally harmless and I've updated the RPM patch to remove this warning (I only added this logged warning to silence compiler warnings anyway).


However, the main problem listed in this patch is really about the old, MGA4 package: http://svnweb.mageia.org/packages/updates/4/gnome-icon-theme/current/SPECS/gnome-icon-theme.spec?view=markup#l54

This runs unconditionally on postun, including, critically, when completely uninstalled. As the package has been renamed in MGA5, this is effectively what happens - the old named package is seen by RPM to have been completely uninstalled.

Sadly this bug is in the MGA4 package NOT the MGA5 one.

Really, the MGA4 package should check $1 == 1 so as not to run on full uninstall.

I'm not sure what else to suggest to rectify this issue. I guess just we can update the MGA4 package to put in more protection, or just simply tell users to ignore the warning?

Yes, we'll have to fix the Mageia 4 package for this.  Should we use the %clean_icon_cache macro that Jani mentioned in Comment 3 (assuming that's available on Mageia 4) and would that be sufficient, or do we need the $1 == 1 check?

As %clean_icon_cache checks for the existence of the index.theme file before running gtk-update-icon-cache, this should be sufficient without the $1 == 1.

I tried to upload the fixed package, but it was rejected, claiming empty %post/%postun, but %clean_icon_cache is provided by rpm-mageia-setup-build, which has to be installed for every package build, so this is bogus. 

QA notes below, to save for later.

Test procedure:
install the updated package and upgrade to mga5/Cauldron and make sure you don't get the error when gnome-icon-theme is upgraded to adwaita-icon-theme (which will be shown in a GUI dialog at the end of installing packages if you use the installer to do the upgrade).

Advisory:
----------------------------------------

This update fixes the post-installation/uninstallation script used by the
package to update the icon cache, which causes an error when upgrading to
Mageia 5, due to the theme index file having been removed.
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
gnome-icon-theme-3.10.0-2.1.mga4

from gnome-icon-theme-3.10.0-2.1.mga4.src.rpm

Checking the built RPM, the scripts do indeed look empty :(

[colin@jimmy Download]$ rpm -qp --scripts 20150215011812.luigiwalser.valstar.18115_gnome-icon-theme-3.10.0-2.1.mga4.noarch.rpm
postinstall program: /bin/sh
postuninstall program: /bin/sh


I think the problem is that the macro itself has some magic to expand to nothing, if the icon caches are cleared through a filetrigger:

%clean_icon_cache() %{expand: %%{!?icon_cache_through_filetrigger_%1...

So perhaps this is why it reduces to empty? The logic is also a bit broken anyway. If the package that provides the clean filetrigger is the one that is removed, then it cannot clean itself on removal anyway. So perhaps just reverting back to the manual call and protecting it with a $1 check or a -f .../index.theme check would be better in this case?

So the %clean_icon_cache macro is broken and useless.  No wonder I couldn't find any packages using it.

If this is handled through filetriggers, then the scriplets shouldn't even be needed then, right?

*** Bug 15297 has been marked as a duplicate of this bug. ***

CC: (none) => westel

*** Bug 15294 has been marked as a duplicate of this bug. ***

CC: (none) => wilcal.int

*** Bug 14120 has been marked as a duplicate of this bug. ***

CC: (none) => thomas

still valid

(In reply to David Walser from comment #13)
> So the %clean_icon_cache macro is broken and useless.  No wonder I couldn't
> find any packages using it.
> 
> If this is handled through filetriggers, then the scriplets shouldn't even
> be needed then, right?

I guess not, but I cannot say for certain. At least in this case I really don't think it matters too much. Personally I'd just make it conditional on it being an upgrade, not an uninstall and forget about it!

Also this is a bug against MGA4, so shouldn't we change the version accordingly?

(In reply to Colin Guthrie from comment #18)
> I guess not, but I cannot say for certain. At least in this case I really
> don't think it matters too much. Personally I'd just make it conditional on
> it being an upgrade, not an uninstall and forget about it!

Sure, well I guess copying the macro code and checking for the existence of the theme index file should work just as well too:
if [ -x %{_bindir}/gtk-update-icon-cache -a -r %{_iconsdir}/gnome/index.theme ]\
; then
  %{_bindir}/gtk-update-icon-cache --force --quiet %{_iconsdir}/gnome
fi

> Also this is a bug against MGA4, so shouldn't we change the version
> accordingly?

Yep.

OK, let's try this again.

Test procedure:
install the updated package and upgrade to mga5/Cauldron and make sure you don't get the error when gnome-icon-theme is upgraded to adwaita-icon-theme (which will be shown in a GUI dialog at the end of installing packages if you use the installer to do the upgrade).

Advisory:
----------------------------------------

This update fixes the post-installation/uninstallation script used by the
package to update the icon cache, which causes an error when upgrading to
Mageia 5, due to the theme index file having been removed.
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
gnome-icon-theme-3.10.0-2.2.mga4

from gnome-icon-theme-3.10.0-2.2.mga4.src.rpm

CC: (none) => olav
Version: Cauldron => 4
Assignee: olav => qa-bugs
Whiteboard: (none) => has_procedure

Testing now. We currently have some other upgrade issues but should be able to check for this anyway.

Performed an online upgrade with mgaapplet --testing with this update installed and never saw any errors, it said upgrade was successful but logging isn't very complete, just install/erase in the journal.

Yesterday I tried an online upgrade using the dvd with medias added and ran into lots of failures, including this, so I'll roll back the VM and try that again. It may have been mirror sync causing the majority of issues there so will prevent the sync before the upgrade begins.

It takes hours each time :(

Starting an upgrade test with this now.  It's in a VM at work, using boot.iso to run the installer from my local Cauldron mirror.  I'll know the results when I get back on Monday.

yes, sorry I didn't get back to this. I had alot of issues during the upgrade which made testing this impossible at the time.

Yeah, hopefully the issues you had in that one test were just because of things changing on the mirror during the installation.

Upgrade was successful, fix verified on i586.  Since fix isn't arch-dependent, just making sure the package installs fine on x86_64 should be sufficient to validate this.

Whiteboard: has_procedure => has_procedure MGA4-32-OK

Testing complete mga4 64

More simply..

Before
------
# rpm -e --nodeps gnome-icon-theme
gtk-update-icon-cache: No theme index file.
warning: %postun(gnome-icon-theme-3.10.0-2.mga4.noarch) scriptlet failed, exit status 1

# urpmi gnome-icon-theme


After
-----
# rpm -e --nodeps gnome-icon-theme
# urpmi gnome-icon-theme

Whiteboard: has_procedure MGA4-32-OK => has_procedure MGA4-32-OK mga4-64-ok

Validating. Advisory uploaded.

Please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA4-32-OK mga4-64-ok => has_procedure advisory MGA4-32-OK mga4-64-ok
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0017.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED