Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: GNUser on March 06, 2020, 04:33:14 PM
-
I discovered this puzzling thing today. If gnumeric.tcz is in onboot.lst (in the beginning, middle, or end of the file--it makes no difference) then the extension works perfectly.
However, if I remove the extension from onboot.lst and manually load it after boot with tce-load -i gnumeric then my terminal fills up with several messages like these for over a minute before opening a spreadsheet:
** (gnumeric:10777): CRITICAL **: 16:25:09.078: go_conf_add_monitor: assertion 'node || key' failed
** (gnumeric:10777): CRITICAL **: 16:25:09.078: go_conf_get_node: assertion 'parent || key' failed
** (gnumeric:10777): CRITICAL **: 16:25:09.078: go_conf_add_monitor: assertion 'node || key' failed
** (gnumeric:10777): CRITICAL **: 16:25:09.078: go_conf_get_node: assertion 'parent || key' failed
** (gnumeric:10777): CRITICAL **: 16:25:09.078: go_conf_add_monitor: assertion 'node || key' failed
** (gnumeric:10777): CRITICAL **: 16:25:09.078: go_conf_get_node: assertion 'parent || key' failed
I looked through /etc/init.d/tc-config to see what happens after extensions are loaded, but I can't find anything that would obviously remedy the above errors.
Please, what command do I need to run manually after tce-load -i gnumeric so that the application works well when loaded manually?
-
Sorry, I forgot to mention: I'm on Pure64 11.0
One more piece of information, I tried removing gnumeric.tcz from onboot.lst and loading it via a job in ~/.X.d/
Result: The same "CRITICAL" messages filling my terminal.
So to summarize, if gnumeric.tcz is loaded:
- via onboot.lst: works fine
- via ~/.X.d: CRITICAL messages in terminal
- manually in terminal emulator after boot process is complete: CRITICAL messages in terminal
So something happens between loading of extensions in onboot.lst and running the jobs in ~/X.d/ that's important for gnumeric.tcz to function properly. Any ideas?
-
Hi GNUser
... So something happens between loading of extensions in onboot.lst and running the jobs in ~/X.d/ that's important for gnumeric.tcz to function properly. Any ideas?
Maybe ldconfig ?
When booting, tc-config calls tce-setup passing it a "booting" parameter. tce-setup calls tce-load passing it a "booting" parameter.
I'll leave it to you to try to trace what's going on with that. My scripting comprehension stinks.
-
Thank you, Rich. ldconfig is a good thought but didn't do the trick. It must be something of that sort.
Thanks for clarifying the relevant steps after tc-config . I'll investigate.
-
I'm not having any luck. Tried everything that looked promising, to no avail:
sudo /sbin/depmod -a
sudo /sbin/udevadm trigger
sudo /sbin/ldconfig
curaga, any ideas what's the magic sauce that makes gnumeric.tcz happy only if it's loaded via onboot.lst ?
-
Hi GNUser
Try:
sudo /usr/local/tce.installed/adwaita-icon-themeor:
sudo /usr/local/tce.installed/hicolor-icon-theme
-
Rich,
Alas, no luck with either.
FWIW I was able to find the source code of the go_conf_get_node and go_conf_add_monitor functions. Those functions are called from gnumeric but are actually defined in goffice's source code (in go-conf-settings.c). Maybe it gives some clue as to what we're looking for:
GOConfNode *
go_conf_get_node (GOConfNode *parent, gchar const *key)
{
GOConfNode *node;
char *formatted;
g_return_val_if_fail (parent || key, NULL);
formatted = go_conf_format_id (key);
node = g_new0 (GOConfNode, 1);
node->ref_count = 1;
if (parent) {
if (key && !parent->key) {
node->path = g_strconcat (parent->path, "/", key, NULL);
node->id = g_strconcat (parent->id, ".", formatted, NULL);
} else {
node->path = g_strdup (parent->path);
node->id = g_strdup (parent->id);
node->key = g_strdup (key? key: parent->key);
}
} else {
if (key[0] == '/') {
node->path = g_strdup (key);
node->id = g_strconcat ("org.gnome", formatted, NULL);
} else {
node->path = g_strconcat ("/apps/", key, NULL);
node->id = g_strconcat ("org.gnome.", formatted, NULL);
}
}
node->settings = g_hash_table_lookup (installed_schemas, node->id)? g_settings_new (node->id): NULL;
g_free (formatted);
if (!node->settings) {
char *last_dot = strrchr (node->id, '.');
*last_dot = 0;
node->settings = g_hash_table_lookup (installed_schemas, node->id)? g_settings_new (node->id): NULL;
if (node->settings) {
g_free (node->key);
node->key = g_strdup (last_dot + 1);
} else {
go_conf_free_node (node);
node = NULL;
}
}
return node;
}
guint
go_conf_add_monitor (GOConfNode *node, G_GNUC_UNUSED gchar const *key,
GOConfMonitorFunc monitor, gpointer data)
{
guint ret;
GOConfClosure *cls;
g_return_val_if_fail (node || key, 0);
g_return_val_if_fail (monitor != NULL, 0);
cls = g_new (GOConfClosure, 1);
cls->monitor = monitor;
cls->node = node;
cls->data = data;
cls->key = g_strdup (key? key: node->key);
cls->real_key = (key)? g_strconcat (node->path, '/', key, NULL): g_strdup (node->path);
ret = g_signal_connect
(node->settings,
"changed", G_CALLBACK (cb_key_changed),
cls);
g_hash_table_insert (closures, GUINT_TO_POINTER (ret), cls);
return ret;
}
-
This is gnumeric's source code (gnumeric-conf.c), where it calls go_conf_get_node:
static GOConfNode *
get_node (const char *key, gpointer watch)
{
GOConfNode *res = g_hash_table_lookup (node_pool, key);
if (!res) {
res = go_conf_get_node (key[0] == '/' ? NULL : root, key);
g_hash_table_insert (node_pool, (gpointer)key, res);
if (watch)
g_hash_table_insert (node_watch, res, watch);
}
return res;
}
I'm going to see if the g_hash_table_lookup function has any hints.
-
I figured it out. It seems that if gnumeric.tcz is loaded after boot, the necessary "gsettings schemas" don't get compiled.
The trouble is that after boot they cannot be compiled in-situ:
$ tce-load -i gnumeric
$ sudo glib-compile-schemas /tmp/tcloop/gnumeric/usr/local/share/glib
-2.0/schemas
Failed to create file “/tmp/tcloop/gnumeric/usr/local/share/glib-2.0/schemas/gschemas.compiled.V89GH0”: Read-only file system
So we have to work around the read-only filesystem:
$ cp -r /tmp/tcloop/gnumeric/usr/local/share/glib-2.0/schemas/ ~/schemas
$ glib-compile-schemas ~/schemas
$ export GSETTINGS_SCHEMA_DIR=~/schemas
$ gnumeric /path/to/some/spreadsheet
-> it works perfectly :)This was a tough one!
-
A way around the whole issue is to include the gschemas.compiled file with the extension and use a wrapper script with the environmental variable. I'll fix the extension and will re-submit it this week.
-
Hi GNUser
I don't see this issue under TC10 X86. I have the the following:
tc@E310:~$ cat /usr/local/tce.installed/gtk3
#!/bin/sh
gtk-query-immodules-3.0 --update-cache
glib-compile-schemas /usr/local/share/glib-2.0/schemas
read USER < /etc/sysconfig/tcuser
if [ ! -d /home/"$USER"/.config/gtk-3.0 ]; then
mkdir -p /home/"$USER"/.config/gtk-3.0
chown -R "$USER":staff /home/"$USER"/.config
fi
if [ ! -f /home/"$USER"/.config/gtk-3.0/settings.ini ]; then
cp /usr/local/share/gtk-3.0/files/settings.ini /home/"$USER"/.config/gtk-3.0
chown -R "$USER":staff /home/"$USER"/.config/gtk-3.0
fi
tc@E310:~$
This is the resulting schemas directory:
tc@E310:~/gtk$ ls -l /usr/local/share/glib-2.0/schemas/
total 16
lrwxrwxrwx 1 root root 62 Feb 29 01:45 gschema.dtd -> /tmp/tcloop/glib2/usr/local/share/glib-2.0/schemas/gschema.dtd
-rw-r--r-- 1 root staff 15671 Mar 7 01:24 gschemas.compiled
lrwxrwxrwx 1 root root 92 Mar 7 00:15 org.gnome.gnumeric.dialogs.gschema.xml -> /tmp/tcloop/gnumeric/usr/local/share/glib-2.0/schemas/org.gnome.gnumeric.dialogs.gschema.xml
lrwxrwxrwx 1 root root 84 Mar 7 00:15 org.gnome.gnumeric.gschema.xml -> /tmp/tcloop/gnumeric/usr/local/share/glib-2.0/schemas/org.gnome.gnumeric.gschema.xml
lrwxrwxrwx 1 root root 91 Mar 7 00:15 org.gnome.gnumeric.plugin.gschema.xml -> /tmp/tcloop/gnumeric/usr/local/share/glib-2.0/schemas/org.gnome.gnumeric.plugin.gschema.xml
lrwxrwxrwx 1 root root 74 Feb 29 01:45 org.gtk.Demo.gschema.xml -> /tmp/tcloop/gtk3/usr/local/share/glib-2.0/schemas/org.gtk.Demo.gschema.xml
lrwxrwxrwx 1 root root 91 Feb 29 01:45 org.gtk.Settings.ColorChooser.gschema.xml -> /tmp/tcloop/gtk3/usr/local/share/glib-2.0/schemas/org.gtk.Settings.ColorChooser.gschema.xml
lrwxrwxrwx 1 root root 84 Feb 29 01:45 org.gtk.Settings.Debug.gschema.xml -> /tmp/tcloop/gtk3/usr/local/share/glib-2.0/schemas/org.gtk.Settings.Debug.gschema.xml
lrwxrwxrwx 1 root root 91 Feb 29 01:45 org.gtk.Settings.EmojiChooser.gschema.xml -> /tmp/tcloop/gtk3/usr/local/share/glib-2.0/schemas/org.gtk.Settings.EmojiChooser.gschema.xml
lrwxrwxrwx 1 root root 90 Feb 29 01:45 org.gtk.Settings.FileChooser.gschema.xml -> /tmp/tcloop/gtk3/usr/local/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml
lrwxrwxrwx 1 root root 80 Feb 29 01:45 org.gtk.exampleapp.gschema.xml -> /tmp/tcloop/gtk3/usr/local/share/glib-2.0/schemas/org.gtk.exampleapp.gschema.xml
tc@E310:~/gtk$
-
You should not include gschemas.compiled, it should be created by including "glib-compile-schemas /usr/local/share/glib-2.0/schemas" in the startup script.
-
Hi GNUser
... So something happens between loading of extensions in onboot.lst and running the jobs in ~/X.d/ that's important for gnumeric.tcz to function properly. Any ideas?
If I interpreted the scripts correctly, tce.installed scripts get run as a batch after all the extensions have been loaded when booting.
That means the gtk3 installed script runs after gnumeric loads onboot. See if running this fixes the issue:
sudo /usr/local/tce.installed/gtk3
-
OK, but each extension that adds gschemas needs to run glib-compile-schemas.
(it would also be good if the gnumeric startup script ran "gtk-update-icon-cache -q -f -t /usr/local/share/icons/hicolor", the extension didn't contain help files and the desktop file included "X-FullPathIcon=/usr/local/share/pixmaps/gnumeric.png" ;) )
-
Thank you both very much for the help and insights.
juanito, I'll rectify all those issues when I clean up the extension this week.
-
See if running this fixes the issue:
sudo /usr/local/tce.installed/gtk3
Yes, it does. I guess the gtk3 startup script normally waits until after all applications in onboot.lst are loaded? The script looks too simple for that. There must be something else going on.
OK, but each extension that adds gschemas needs to run glib-compile-schemas.
That sounds like a cleaner, more standard solution than bundling pre-compiled schemas.
I just submitted a cleaned-up gnumeric.tcz with all the above fixes. It works as expected whether loaded via onboot.lst or later.
-
Hi GNUser
... Yes, it does. I guess the gtk3 startup script normally waits until after all applications in onboot.lst are loaded? The script looks too simple for that. There must be something else going on. ...
Guess you missed this post:
... If I interpreted the scripts correctly, tce.installed scripts get run as a batch after all the extensions have been loaded when booting.
That means the gtk3 installed script runs after gnumeric loads onboot. ...
Look for references to /tmp/setup.lst in tce-load and tce-setup.
-
Bingo! Sorry, I did miss that detail. Yup, that explains everything.