Bug 14971 - gtk-update-icon-cache run from scriplets and triggers has errors during upgrade
Summary: gtk-update-icon-cache run from scriplets and triggers has errors during upgrade
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: has_procedure advisory MGA4-32-OK mga...
Keywords: validated_update
: 14120 15061 15294 15297 (view as bug list)
Depends on:
Blocks: 15013
  Show dependency treegraph
 
Reported: 2015-01-06 23:19 CET by David Walser
Modified: 2015-03-05 20:34 CET (History)
9 users (show)

See Also:
Source RPM: gtk+2.0-2.24.25-3.mga5.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2015-01-06 23:19:49 CET
Upgrading from Mageia 4 to Mageia 5, when gnome-icon-theme is upgraded to adwaita-icon-theme, you see these:
gtk-update-icon-cache: No theme index file.
warning %postin(gnome-icon-theme-3.10.0-2.mga4.noarch) scriplet failed, exit status 1

(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

Reproducible: 

Steps to Reproduce:
Comment 1 Olav Vitters 2015-01-07 14:57:20 CET
(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.
Comment 2 David Walser 2015-01-07 16:37:43 CET
So, does something need to be changed in gtk+2.0 in the filetrigger, or in rpm?
Comment 3 Jani Välimaa 2015-01-11 10:43:39 CET
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

claire robinson 2015-01-12 11:03:47 CET

Blocks: (none) => 15013

Comment 4 Olav Vitters 2015-01-12 15:04:11 CET
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.
Comment 5 David Walser 2015-01-14 21:49:50 CET
CC'ing tv since Olav thinks rpm shouldn't be complaining for this scriptlet.

CC: (none) => thierry.vignaud

Comment 6 Thierry Vignaud 2015-01-15 09:01:24 CET
Patch was done by Colin, not by me

CC: (none) => mageia

Comment 7 David Walser 2015-01-17 17:25:50 CET
*** Bug 15061 has been marked as a duplicate of this bug. ***

CC: (none) => dvgevers

Dick Gevers 2015-01-17 17:42:48 CET

CC: dvgevers => (none)

Comment 8 Rémi Verschelde 2015-02-03 21:17:24 CET
Colin, any idea on this one?

CC: (none) => remi

Comment 9 Colin Guthrie 2015-02-03 23:11:59 CET
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?
Rémi Verschelde 2015-02-05 20:54:33 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=15032

Comment 10 David Walser 2015-02-06 20:22:53 CET
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?
Comment 11 David Walser 2015-02-15 02:27:38 CET
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
Comment 12 Colin Guthrie 2015-02-15 11:02:09 CET
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?
Comment 13 David Walser 2015-02-15 15:03:11 CET
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?
Comment 14 ben mcmonagle 2015-02-16 05:58:28 CET
*** Bug 15297 has been marked as a duplicate of this bug. ***

CC: (none) => westel

Comment 15 Olav Vitters 2015-02-16 12:57:14 CET
*** Bug 15294 has been marked as a duplicate of this bug. ***

CC: (none) => wilcal.int

Comment 16 Thierry Vignaud 2015-02-18 21:50:18 CET
*** Bug 14120 has been marked as a duplicate of this bug. ***

CC: (none) => thomas

Comment 17 claire robinson 2015-02-24 15:37:49 CET
still valid
Comment 18 Colin Guthrie 2015-02-24 16:08:40 CET
(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?
Comment 19 David Walser 2015-02-24 16:13:39 CET
(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.
Comment 20 David Walser 2015-02-24 16:22:16 CET
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

Comment 21 claire robinson 2015-02-24 18:00:22 CET
Testing now. We currently have some other upgrade issues but should be able to check for this anyway.
Comment 22 claire robinson 2015-02-25 12:18:09 CET
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 :(
Comment 23 David Walser 2015-02-28 00:20:56 CET
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.
Comment 24 claire robinson 2015-02-28 08:50:03 CET
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.
Comment 25 David Walser 2015-02-28 15:03:05 CET
Yeah, hopefully the issues you had in that one test were just because of things changing on the mirror during the installation.
Comment 26 David Walser 2015-03-02 21:25:22 CET
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

Comment 27 claire robinson 2015-03-05 17:08:28 CET
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

Comment 28 claire robinson 2015-03-05 18:00:24 CET
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

Comment 29 Mageia Robot 2015-03-05 20:34:50 CET
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


Note You need to log in before you can comment on or make changes to this bug.