Summary: | app-office/gnucash - assertion `g_key_file_is_key_name (key)' failed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fred Krogh <fkrogh> |
Component: | Current packages | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
Status: | RESOLVED UPSTREAM | ||
Severity: | minor | CC: | gnome-office+disabled, jsled, leio |
Priority: | Highest | ||
Version: | 2006.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Fred Krogh
2006-12-20 11:05:45 UTC
*** This bug has been marked as a duplicate of 158646 *** Reopening as this isn't strictly a glib bug. gnucash possibly deviates from the standard in different ways than gnome-vfs, and GKeyFile doesn't have an exception for that. I'm talking of the desktop entry specification, more specifically the key names format given by it - http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html "Key names must contain only the characters A-Za-z0-9-." Due to gnome-vfs it has exception for the following characters in 2.12.6 (2.12.4 and earlier had very forgiving validation or no validation of all for key names format): '_', '/', '+', '.' http://cvs.gnome.org/viewcvs/glib/glib/gkeyfile.c?r1=1.46.2.4&r2=1.46.2.5 So if gnucash uses GKeyfile, it shouldn't use characters other than alphanumeric, a hyphen or if necessary an underscore, slash, plus sign or dot in the key name strings. http://bugzilla.gnome.org/show_bug.cgi?id=343191 for upstream bug about adding the validation of key names. glib-2.12.7 changes the assertion error to a critical warning in these cases. HEAD and therefore future stable 2.14 series still has it as an assert, so gnucash should still fix it upstream. The conversion to critical warnings was done precisely mostly due to gnucash, see the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=390532 (In reply to comment #3) > glib-2.12.7 changes the assertion error to a critical warning in these cases. > HEAD and therefore future stable 2.14 series still has it as an assert, so > gnucash should still fix it upstream. > The conversion to critical warnings was done precisely mostly due to gnucash, > see the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=390532 FWIW, it looks like trunk/ is back to being liberal - <http://svn.gnome.org/viewcvs/glib?rev=5254&view=rev> Yes, both trunk and 2-10 branch, including the 2.12.9 release that is now in portage, error when a key name is used that GKeyFile itself won't be able to read back again. Josh, I leave this to you to handle upstream (In reply to comment #6) > Josh, I leave this to you to handle upstream Already resolved, but for completeness: http://svn.gnucash.org/trac/changeset/15458 has the trunk commit which resolves the issue. This will be in 2.1 (beta)/2.2 (stable). |