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
org.gnome.gnote.export-html
org.gnome.gnote.insert-timestamp
org.gnome.gnote.note-directory-watcher
org.gnome.gnote.global-keybindings
org.gnome.gnote.sync.wdfs
org.gnome.gnote.sync
org.gnome.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.

Repeating the same as above in a clean cauldron LXDE:

[baz@localhost ~]$ gsettings list-schemas | grep gnote
[baz@localhost ~]$ su
Password: 
[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
org.gnome.gnote.insert-timestamp
org.gnome.gnote.export-html
org.gnome.gnote.note-directory-watcher
org.gnome.gnote.global-keybindings
org.gnome.gnote.sync
org.gnome.gnote.sync.wdfs
org.gnome.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.

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/
fi

... which for some reason is not working in this case.

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

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

I think we'll have to report this upstream

Keywords: (none) => UPSTREAM

It's hopefully fixed in rpm-4.13.0-3.mga6

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

Humm it'sn't ...

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

Is this issue still present?

Yes

[baz@localhost ~]$ gnote

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

Trace/breakpoint trap (core dumped)
[baz@localhost ~]$

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?

I fear that somebody will have to take time to debug rpm...

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:
-----------------------------------------------
%postun
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 || :
fi
/sbin/ldconfig

%posttrans
/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.

Created attachment 9147 [details]
svn diff of working patch

Tested in VM and gnote runs without error after updating to this version.

That wouldn't solve other similar issues to other packages having files in /usr/share/glib-2.0/schemas

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.

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

CC: (none) => magnux77

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

Created attachment 9433 [details]
Debug patch

Created attachment 9434 [details]
Log generated with the debug patch

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.

I'm not sure why this wasn't set to rpmstack@, as this is an rpm bug, but reassigning to rpmstack@

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

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.

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

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:

https://github.com/rpm-software-management/rpm/commit/e760730738a2383f3ab2d558a3f2bff9d4450044

CC: (none) => pmatilai

Woohoo!

Wow, nice one, thanks!

Fix will be in rpm-4.14.0-0.rc1.2.mga7

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

(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?

It would be nice to include it in an update but not worth doing one just for that as there was a workaround

Queue it in mga6 svn so it gets added in case we do need another rpm update

CC: (none) => tmb

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.