Bug 18797 - rpm fails to run glib-2.0 %transfiletriggerin which breaks gnote
Summary: rpm fails to run glib-2.0 %transfiletriggerin which breaks gnote
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: Mageia 7
Assignee: RPM stack maintainers
QA Contact:
Keywords: UPSTREAM
: 19221 (view as bug list)
Depends on:
Reported: 2016-06-27 17:17 CEST by Barry Jackson
Modified: 2017-09-13 15:44 CEST (History)
8 users (show)

See Also:
Source RPM: rpm, glib2.0
Status comment: Workaround pushed in cauldron

svn diff of working patch (863 bytes, patch)
2017-03-23 18:32 CET, Barry Jackson
Details | Diff
Debug patch (8.13 KB, patch)
2017-06-20 20:03 CEST, Pascal Terjan
Details | Diff
Log generated with the debug patch (70.31 KB, text/plain)
2017-06-20 20:09 CEST, Pascal Terjan

Description Barry Jackson 2016-06-27 17:17:28 CEST
Description of problem:
[baz@localhost ~]$ gnote

(gnote:2950): GLib-GIO-ERROR **: Settings schema 'org.gnome.gnote' is not installed

Trace/breakpoint trap (core dumped)

Version-Release number of selected component (if applicable):

How reproducible:
I have this in two systems, plasma and a fresh test install of LXDE with gnote installed cleanly (no previous configs).

This was working until quite recently.

Steps to Reproduce:
1. Install gnote
2. Try to run it
Comment 1 Barry Jackson 2016-06-27 18:03:37 CEST
This seems to be a gsettings issue.

[baz@localhost ~]$ gsettings list-schemas | grep gnote
[baz@localhost ~]$

[root@localhost baz]# ll /usr/share/glib-2.0/schemas|grep gnote
-rw-r--r-- 1 root root 13892 May 15 14:07 org.gnome.gnote.gschema.xml
[root@localhost baz]# glib-compile-schemas /usr/share/glib-2.0/schemas

[baz@localhost ~]$ gsettings list-schemas | grep gnote
[baz@localhost ~]$ gnote

(gnote:19281): Gtk-WARNING **: Theme directory base/ of theme oxygen has no size field

...and it works.

So I guess that either gnote is not compiling the schema or some file-trigger is not working after gnote is installed, I have no idea how this is set up.

However there is maybe another issue. In Plasma (where I am now) it launches to the task bar with a continuously circling waiting icon this goes on until it is clicked whereupon it opens into the full window.
I will test again in a clean system as my desktop configs may be affecting this.
Comment 2 Barry Jackson 2016-06-27 18:16:18 CEST
Repeating the same as above in a clean cauldron LXDE:

[baz@localhost ~]$ gsettings list-schemas | grep gnote
[baz@localhost ~]$ su
[root@localhost baz]# gsettings list-schemas | grep gnote
[root@localhost baz]# ll /usr/share/glib-2.0/schemas|grep gnote
-rw-r--r-- 1 root root 13892 May 15 14:07 org.gnome.gnote.gschema.xml
[root@localhost baz]# glib-compile-schemas /usr/share/glib-2.0/schemas
[root@localhost baz]# gsettings list-schemas | grep gnote
[root@localhost baz]# exit
[baz@localhost ~]$ gnote

...it's running with no warnings. However there are lots of:
(gnote:2937): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
...on closing, but IIRC this is normal.
Marja Van Waes 2016-06-27 22:10:51 CEST

CC: (none) => marja11
Assignee: bugsquad => juan.baptiste

Comment 3 Barry Jackson 2016-06-28 12:50:47 CEST
Apparently this should now be handled by the following in the glib2.0 spec
(thanks to Luigi on irc :)

%transfiletriggerin -n %{name}-common --  %_datadir/glib-2.0/schemas/
if [ -x /usr/bin/glib-compile-schemas ]; then
        /usr/bin/glib-compile-schemas --allow-any-name %_datadir/glib-2.0/schemas/

... which for some reason is not working in this case.
Comment 4 Barry Jackson 2016-06-28 13:24:23 CEST
Further testing confirms that the filetrigger is not working for either install or removal of gnote.
The exact command and conditional in the trigger script do work correctly when run manually.

So this appears to be an rpm/glib-2.0 bug.

Changing summary.

Source RPM: gnote => rpm, glib-2
Priority: Normal => High
Summary: gnote fails to run => rpm fails to run glib-2.0 %transfiletriggerin which breaks gnote

Barry Jackson 2016-06-28 13:24:43 CEST

Assignee: juan.baptiste => bugsquad

Rémi Verschelde 2016-06-28 13:29:03 CEST

CC: (none) => thierry.vignaud

Marja Van Waes 2016-06-29 16:59:58 CEST

Assignee: bugsquad => thierry.vignaud

Comment 5 Thierry Vignaud 2016-06-30 11:45:00 CEST
Indeed "urpmi --debug-librpm yelp shows:

D: %triggerin(glib2.0-common-2.48.1-1.mga6.x86_64): scriptlet start
fdio:       2 writes,      172 total bytes in 0.000011 secs
D: %triggerin(glib2.0-common-2.48.1-1.mga6.x86_64): execv(/bin/sh) pid 14431
+ '[' -x /usr/bin/glib-compile-schemas ']'
+ /usr/bin/glib-compile-schemas --allow-any-name /usr/share/glib-2.0/schemas/
D: %triggerin(glib2.0-common-2.48.1-1.mga6.x86_64): waitpid(14431) rc 14431 status 0

But "urpmi --debug-librpm gnote" doesn't
Comment 6 Thierry Vignaud 2016-07-01 16:07:05 CEST
I think we'll have to report this upstream

Keywords: (none) => UPSTREAM

Samuel Verschelde 2016-10-10 17:43:40 CEST

Assignee: thierry.vignaud => rpmstack

Thierry Vignaud 2016-10-10 18:18:07 CEST

Status comment: (none) => to be reported upstream

Comment 7 Thierry Vignaud 2016-11-07 14:52:31 CET
It's hopefully fixed in rpm-4.13.0-3.mga6

See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1284645

Thierry Vignaud 2016-11-07 14:52:59 CET

Status comment: to be reported upstream => (none)

Comment 8 Thierry Vignaud 2016-11-07 17:10:44 CET
Humm it'sn't ...
Comment 9 Thierry Vignaud 2016-11-11 16:34:25 CET
I just backported an upstream patch that now warns:
error: line 210: file trigger condition must begin with '/':   /usr/share/glib-2.0/schemas/

Source RPM: rpm, glib-2 => glib-2
Assignee: rpmstack => olav

Thierry Vignaud 2016-11-11 16:34:34 CET

Source RPM: glib-2 => glib2.0

Thierry Vignaud 2016-11-12 10:12:13 CET

Source RPM: glib2.0 => rpm, glib2.0

Comment 10 Samuel Verschelde 2017-03-17 12:37:24 CET
Is this issue still present?
Comment 11 Barry Jackson 2017-03-17 12:50:58 CET

[baz@localhost ~]$ gnote

(gnote:10314): GLib-GIO-ERROR **: Settings schema 'org.gnome.gnote' is not installed

Trace/breakpoint trap (core dumped)
[baz@localhost ~]$
Samuel Verschelde 2017-03-17 12:52:55 CET

Target Milestone: --- => Mageia 6

Comment 12 Olav Vitters 2017-03-20 19:05:23 CET
Thiery: I don't get the warning message.  It starts with a '/', no? I tried compiling with removing one of the spaces, but that doesn't seem to be it. I also don't get any error or warning message?
Comment 13 Thierry Vignaud 2017-03-22 22:26:10 CET
I fear that somebody will have to take time to debug rpm...
Comment 14 Barry Jackson 2017-03-23 18:12:16 CET
Could we simply use a sledgehammer to workaround this in the gnote spec as Fedora seem to have done, by running glib-compile-schemas in %postun and %posttrans (or %post?):

From Fedora spec:
if [ $1 -eq 0 ] ; then
    /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null
    /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
    /usr/bin/glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :

/usr/bin/glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
/usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : 


This needs fixing in rpm, but for Mga6 this approach would fix the gnote breakage until such time as rpm is fixed.
Comment 15 Barry Jackson 2017-03-23 18:32:41 CET
Created attachment 9147 [details]
svn diff of working patch

Tested in VM and gnote runs without error after updating to this version.
Comment 16 Thierry Vignaud 2017-03-23 22:23:35 CET
That wouldn't solve other similar issues to other packages having files in /usr/share/glib-2.0/schemas
Comment 17 Barry Jackson 2017-03-23 23:22:31 CET
I'm not suggesting it would, but it would fix gnote.

I opened this against gnote until the root cause was found.

I think https://bugs.mageia.org/show_bug.cgi?id=19221 is the only possible duplicate.
Comment 18 Barry Jackson 2017-04-05 14:41:31 CEST
*** Bug 19221 has been marked as a duplicate of this bug. ***

CC: (none) => magnux77

Comment 19 Pascal Terjan 2017-06-20 18:02:37 CEST
From adding some logging, rpm correctly finds the list of file triggers that are triggered by this transaction.

Then it merges duplicates.

Then for each of those, it searches again the matching files in the transaction (in runHandleTriggersInPkg) and sometimes doesn't find them, I still haven't found why.

It seems to happen in 2 cases:
- If same file triggers 2 file triggers from 2 different packages
- If 2 packages in the transaction trigger the same file trigger

CC: (none) => pterjan

Comment 20 Pascal Terjan 2017-06-20 20:03:35 CEST
Created attachment 9433 [details]
Debug patch
Comment 21 Pascal Terjan 2017-06-20 20:09:10 CEST
Created attachment 9434 [details]
Log generated with the debug patch
Jani Välimaa 2017-06-21 20:08:06 CEST

CC: (none) => jani.valimaa

Comment 22 Pascal Terjan 2017-07-09 23:29:14 CEST
I still don't understand why it fails to find matching files in the transaction the second time, but it should always be fine as they matched previously so I committed an ugly patch which I confirmed in my tests fixes the problem.
Comment 23 Neal Gompa 2017-07-10 00:04:23 CEST
I'm not sure why this wasn't set to rpmstack@, as this is an rpm bug, but reassigning to rpmstack@

Assignee: olav => rpmstack
CC: (none) => ngompa13

Rémi Verschelde 2017-07-10 12:00:41 CEST

Priority: High => release_blocker

Rémi Verschelde 2017-07-10 12:01:18 CEST

Status comment: (none) => Patch pushed in SVN by Pascal (comment 22), not released yet

Comment 24 Rémi Verschelde 2017-07-10 23:02:35 CEST
Pascal's workaround was pushed in Cauldron and will be on the next ISOs, so decreasing priority and severity.

Keeping the bug open as reference for upstream though.

Severity: critical => major
Status comment: Patch pushed in SVN by Pascal (comment 22), not released yet => Workaround pushed in cauldron
Target Milestone: Mageia 6 => Mageia 7
Priority: release_blocker => High

Comment 25 Panu Matilainen 2017-09-13 12:15:50 CEST
Got reminded of this last week, and then remembered Thierry actually provided me a reproducer at some point even if not exactly a very minimal one. But together with Pascal's findings were enough to get on the trail, and after two and half days chase, actually nail the bugger:


CC: (none) => pmatilai

Comment 26 Neal Gompa 2017-09-13 12:16:39 CEST
Comment 27 Pascal Terjan 2017-09-13 13:01:05 CEST
Wow, nice one, thanks!
Comment 28 Thierry Vignaud 2017-09-13 14:56:35 CEST
Fix will be in rpm-4.14.0-0.rc1.2.mga7

Resolution: (none) => FIXED

Comment 29 Barry Jackson 2017-09-13 15:02:48 CEST
(In reply to Thierry Vignaud from comment #28)
> Fix will be in rpm-4.14.0-0.rc1.2.mga7

What about Mga6? 
Can this be applied to 4.13.x?
Comment 30 Pascal Terjan 2017-09-13 15:06:21 CEST
It would be nice to include it in an update but not worth doing one just for that as there was a workaround
Comment 31 Thomas Backlund 2017-09-13 15:10:20 CEST
Queue it in mga6 svn so it gets added in case we do need another rpm update

CC: (none) => tmb

Comment 32 Panu Matilainen 2017-09-13 15:44:46 CEST
The fix should apply cleanly and work in 4.13.x too.

FWIW the idea is to ship an upstream bugfix release to 4.13.x branch sooner or later (think "within year 2017" or so). File triggers was one of the big new features in that release so a bug of this magnitude deserves (maybe even demands) a fix there as well.

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