glom: glib error gives Invalid byte sequence in conversion input

[m.rick@…]

I am not sure it is a Glib related error, but I have installed Glom in a new fresh installation and when I Stat it I get this error when i want to create a new brand new database file:

information for file '/Users/aymeric/Desktop/Nantes voirie/Nantes voirie.glom': 
Glib::ustring GlomBakery::get_file_display_name(const Glib::ustring &): uri=file:///Users/aymeric/Desktop/Nantes%20voirie/Nantes%20voirie.glom): error: Error when getting information for file '/Users/aymeric/Desktop/Nantes voirie/Nantes voirie.glom': 0
Glib::ustring GlomBakery::get_file_display_name(const Glib::ustring &): uri=file:///Users/aymeric/Desktop/Nantes%20voirie/Nantes%20voirie.glom): error: 
(<unknown>:81958): glibmm-CRITICAL **: 
unhandled exception (type Glib::Error) in signal handler:
domain: g_convert_error
code  : 1
what  : Invalid byte sequence in conversion input

It creates the database folder, but won't create the ~.glom file describing the database and it won't initialize the database and won't create the database configuration. I can create a database from the included examples and I can use already existing databases.

I didn't have it with previous versions.

I have a back-up of December and it does work well, while dbus, glib and glibmm libraries have the same versions… And the Glom binary is the same version as well. I made a packaged version of it (December) that works well too.

I installed Glom with the following steps:

1. port install gtk3 +quartz+python27
2. port install gtk2 +quartz+python27
3. port install libglade2 +quartz
4. port install py27-pygtk +quartz
5. port install avahi +gtk+gtk3+quartz+x11
6. port install libepc
7. port install libgda5 +db60+postgresql94+quartz
8. port install evince +quartz
9. port -f deactivate gtk3 @3.18.6_0+quartz
10. port install gtk3 +x11+python27
11. port install gcr
12. port -f deactivate gtk3 @3.18.6_0+x11
13. port activate gtk3 @3.18.6_0+quartz
14. port install glom +db60+postgresql94+quartz

[m.rick@…]

I have also discovered that the unworking version adds a slash after the name of the new database, like it was a path, it doesn't with the working version. ​https://trac.macports.org/attachment/ticket/50386/Capture%20d’écran%202016-01-20%20à%2022.13.32.png

It doesn't seem D-Bus related, because it happens with or without D-Bus running.

[murrayc@…]

It seems to be a failure to convert the (probably) UTF-8 error message to the current locale's encoding, during the implicit conversion that happens here, in document.cc's get_file_display_name(), when writing to std::cerr:

try {

file_info = file->query_info(G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME);

} catch(const Glib::Error& ex) {

std::cerr << G_STRFUNC << ": uri=" << uri << "): error: " << ex.what() << std::endl; return result;

}

That is strange. Maybe it's because the error message contains a badly-encoded URI (based on a badly-encoded filepath?) for some reason.

I guess we'd first want to know why Gio::File::query_info() fails the first time. The error message's explanation seems to be just "0", which is itself strange. I guess that something is odd about glib or the locale. I think this might need someone to debug the actual code as it happens.

[m.rick@…]

If I start Glom with

LC_NUMERIC=$LANG;LC_ALL=$LANG;LANGUAGE=${LANG:0:5}:${LANG:0:2};/opt/local/bin/glom

I have no change and I still get this error message:

(process:2179): Gtk-WARNING **: Locale not supported by C library.
	Using the fallback 'C' locale.
sys:1: PyGIWarning: Gda was imported without specifying a version first. Use gi.require_version('Gda', '5.0') before import to ensure that the right version gets loaded.
Glib::ustring Glom::Conversions::format_date(const tm &): exception from std::locale("")): collate_byname<char>::collate_byname failed to construct for 
Glib::ustring Glom::Conversions::format_date(const tm &):   This can happen if the locale is not properly installed or configured.
ERROR: sanity_check_date_text_representation_uses_4_digit_year(): Sanity check failed: Glom does not seem to use 4 digits to display years in a date's text representation, in this locale. Defaulting to dd/mm/yyyy though this might be incorrect for your locale. This needs attention from a translator. Please file a bug - see http://www.glom.org
  Unexpected date text: 

And it always launches in English, I can't get spaces for thousands separators and I can't get comas but dots for decimal numbers. I think it's related to GKT3 as well, because I get the same translation problem with Gnumeric for example with the parts belonging to the software in English and no support for locale numbers, but some parts strangely appearing in French. These won't happen with GTK2 apps and Gnumeric used to work well under GTK2.

Hopping it'll be fixed someday cos' Glom is a very good piece of software and is not shown off as it should be. It's perfect to be used with Gnumeric and PostgreSQL to manage datas easily.

[m.rick@…]

I have discovered something very strange… My working installation suddenly stopped working giving me bug described here… I replaced the installation by the backup of the working one and it worked again! It's like something got corrupted inside. Is there any cache somewhere? I made a clean of the Mac OS caches system + users but it didn't correct anything, so i supposed it is something inside the installation path, isn't it?

[m.rick@…]

I fixed the problem: There's a GTK2 dependency somewhere unused directly by Glom. I have added GTKmm for GTK2 and the error message is not happening anymore. I also recompiled Glibmm with +quartz+x11, I don't know if there is any incidence, but now it works well.

[murrayc@…]

There really shouldn't be any GTK2 or gtkmm2 dependency in Glom's dependencies. Please really check whether the presence of gtkmm2 makes any difference.

[m.rick@…]

Yes I confirm it does. The port actually using GTK2 is Glade2. ​http://www.macports.org/ports.php?by=library&substr=libglade2 Glade2 is a dependency of Avahi. Unfortunately Avahi's daemon doesn't work… But Avahi GUI does launch well and displays networks, but I am unable to connect with a running PostgreSQL server.

libepc-WARNING **: epc_service_monitor_constructed: Cannot create service type browser for '_glom._sub._easy-publish-https._tcp': Cannot create Avahi client: Le démon n'est pas en cours d'exécution (-26)
(The daemon is not running)

Without Glib, it's impossible to use locales… Currently, it's partially working, the thousands separators are not working and impossible to launch it in French, but I tried it in Linux and it was English only too, but all the locales worked including the thousands separators.

There's the ports list in the attachements.

[murrayc@…]

GTK2 is an _optional_ dependency of Avahi. And I doubt that the part of Avahi used by Glom uses GTK2. So you don't have to build the GTK2 part of Avahi, and I don't think it should affect Glom if you do.

Your problems with using Glom's "Shared on Network" feature might be completely unrelated. Does that work for you on Linux?

Glom should work just fine in French in a normal Linux distro. Please file a bug if it doesn't.

[m.rick@…]

Replying to murrayc@…:

GTK2 is an _optional_ dependency of Avahi. And I doubt that the part of Avahi used by Glom uses GTK2. So you don't have to build the GTK2 part of Avahi, and I don't think it should affect Glom if you do.

Yes it is completely useless, but it corrected my bug by applying this procedure. I did it twice on 2 different builds.

Your problems with using Glom's "Shared on Network" feature might be completely unrelated. Does that work for you on Linux? Glom should work just fine in French in a normal Linux distro. Please file a bug if it doesn't.

Reported on Bugzilla.

[mascguy (Christopher Nielsen)]

As with the other years-old glom tickets, perhaps this isn't an issue any longer. But we should check anyway, rather than simply closing.