gnumeric takes minutes to open some spreadsheets

[GNUser]

I'm on TC64 10.1 with gnumeric 1.12.9 from the repository.

To open some spreadsheets, only a few seconds are required. To open certain other spreadsheets, however, I have to wait over a minute while literally millions of error messages scroll by. The spreadsheets that take a long time to open in TC can be opened instantly with gnumeric in Debian, so the files are not corrupt.

I saved the error log last time:

Code: [Select]

bruno@box:~$ gnumeric some-spreadsheet.ods >error.log 2>&1

bruno@box:~$ wc -l <error.log
6294954

bruno@box:~$ ls -lh error.log # note the size of error.log
-rw-r--r--    1 bruno    staff     275.2M Sep 30 22:43 error.log

bruno@box:~$ head -n 50 <error.log

** (gnumeric:14053): CRITICAL **: 22:42:10.795: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.795: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.795: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.795: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.795: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.795: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.809: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.810: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.810: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.810: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_add_monitor: assertion 'node || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.811: go_conf_get_node: assertion 'parent || key' failed

** (gnumeric:14053): CRITICAL **: 22:42:10.852: go_conf_add_monitor: assertion 'node || key' failed
Any idea how to get rid of the millions of errors so that spreadsheets can be opened in a reasonable amount of time?

[GNUser]

I found this thread http://forum.tinycorelinux.net/index.php/topic,18732.15.html?PHPSESSID=4DQoFNuscmGdfMHTt83ie1
But last post in thread sounds similar to my issue, without a solution.

[Rich]

Hi GNUser
I ran into the same problem in TC10 x86 which has version 1.12.7. After I got tired of trying to track down the problem I compiled
Gumeric 1.10.17 and Goffice 0.8.17 and packaged them for my system. Those were the versions that worked for me under TC4.

[GNUser]

I sensed recompiling these two extensions was in my future

Would you happen to have saved your build notes? Knowing the build dependencies would be especially helpful--the list of build deps I'm getting from Debian is very long (I doubt I'd actually need all of it in TC) and, besides, the package names are different across distros

[GNUser]

Never mind, I'm making progress. It seems this fetches all necessary build deps for goffice in TC:

Code: [Select]

tce-load -wi compiletc gtk3-dev libgsf-dev librsvg-dev libxslt-dev intltool glib2-dev libdrm-dev
I also needed to get glib2-dev.tcz and libdrm-dev.tcz from TC9.x for the .la files which are not present in the TC10.x extensions. (BTW why were the .la files removed from the TC10.x *-dev extensions? Their absence causes a lot of grief.)

I'll update the thread when I've solved or hit a brick wall.

[Rich]

Hi GNUser
I modified some old scripts form the repo to handle that. I'll post them a little later today.

[GNUser]

Thanks, Rich. It will be interesting to compare notes.

Meanwhile, I've compiled goffice and tried it with the existing gnumeric extension from repository. The issue persists.

I'm working on recompiling gnumeric against the new goffice. This seems to fetch all of gnumeric's build deps:

Code: [Select]

tce-load -wi compiletc itstool rarian-dev gtk3-dev intltool libgsf-dev librsvg-dev glib2-devAgain, I needed to also get the .la files from glib2-dev.tcz from TC9.x

[Rich]

Hi GNUser
The attached tarball contains:

Code: [Select]

gnumeric-1.10.17.item-grid.diff
gnumeric.build
gnumeric.desktop
goffice.build
itstool.builditstool.build  was only needed for gnumeric 1.12.x because the current version was too old.

Place  goffice.build  in its own directory and run it:

Code: [Select]

./goffice.build > goffice.log 2>&1The only extension that depends on  goffice  is  abiword  (as far as I know). and may not be compatible with it.

Place  gnumeric-1.10.17.item-grid.diff,  gnumeric.build,  gnumeric.desktop, and  libdrm.la  in their own directory.
You can find  libdrm.la  here:
http://tinycorelinux.net/10.x/x86_64/tcz/src/libdrm/la/
Then run:

Code: [Select]

./gnumeric.build > goffice.log 2>&1gnumeric-1.10.17.item-grid.diff  is a patch I wrote to fix an error message caused by freeing a non-existent object.

[GNUser]

Thank you, Rich. I will try to build it that way as an alternative. However, I figured out how the long way to do it:

Code: [Select]

-> First, copy all .la files from TC9.x version of glib2-dev.tcz and libdrm-dev.tcz into /usr/local/lib

-> For goffice:
$ tce-load -wi compiletc gtk3-dev libgsf-dev librsvg-dev libxslt-dev intltool glib2-dev libdrm-dev
$ cd goffice-extracted-source-tarball
$ ./configure --prefix=/usr/local
$ make
$ make DESTDIR=/opt/destgoffice

-> create goffice.tcz from /opt/destgoffice
-> in goffice.tcz.dep: libgsf.tcz librsvg.tcz libxslt.tcz gtk3.tcz bzip2-lib.tcz
-> load the new goffice.tcz extension (reboot if old goffice.tcz is currently loaded)

-> For gnumeric:
$ tce-load -wi compiletc itstool rarian-dev gtk3-dev intltool libgsf-dev librsvg-dev glib2-dev libdrm-dev
$ cd gnumeric-extracted-source-tarball
$ ./configure --prefix=/usr/local
$ make
$ make DESTDIR=/opt/destgnumeric

-> create gnumeric.tcz from /opt/destgnumeric
-> in gnumeric.tcz.dep: goffice.tcz libglade.tcz

I can confirm that with the rebuilt goffice.tcz and gnumeric.tcz the problem is gone.

Rich, as always, you are the best. Thanks for pinpointing the problem. I was going around in circles and lost quite a bit of sleep last night--wish I had just asked here first

[Rich]

Hi GNUser
I compiled gnumeric 1.12.7 and 1.12.45 (along with goffice and itstools) and in both cases they spewed the errors shown in your
original post. So I reverted back to 1.10.17 which showed this error:

Code: [Select]

(gnumeric:4554): GLib-CRITICAL **: Source ID 161 was not found when attempting to remove itThis error was always present but older versions of glib ignored it instead of reporting it. The included patch fixes that. After
I fixed it I found out it had also been fixed in later versions.

Aside from all the error messages in the current version, it won't save your preferences.

[GNUser]

Hi, Rich.

I compiled goffice 0.10.32 and gnumeric 1.12.32 on TC10.1 64-bit. (I chose these particular versions because I have a complete Debian Stretch mirror--including source packages--and these are the versions in my mirror. I compiled the upstream tarball I grabbed from my mirror, without any of the Debian patches.)

The build steps I took are exactly what I detailed in my prior post.

I do not see the "Source ID...not found when attempting to remove it" error when I run the gnumeric 1.12.32 extension that I created. The only error I get now is this one when I open any spreadsheet:

Code: [Select]

Glib-GIO-Message: 11:37:55.659: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.There are no other errors when opening or closing spreadsheets, and they open immediately. It doesn't bother me if it doesn't save my settings--I just need to view, edit, and save spreadsheets; default settings are good enough for me.

[Rich]

Hi GNUser

... The only error I get now is this one when I open any spreadsheet:

Code: [Select]

Glib-GIO-Message: 11:37:55.659: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. ...

Try installing  dconf.tcz.

If the toolbar icons along the top of gnumeric all look like little terminals, install  gnome-icon-theme.tcz.

[GNUser]

Hi, Rich. Installing dconf.tcz made the error disappear, so no more errors of any kind! gnumeric is a must-have application for me, so I'm really happy that it is running without any errors. THANK YOU!

All icons show up fine even though gnome-icon-theme is not installed. The only icon themes I have installed are adwaita-icon-theme.tcz and hicolor-icon-theme.tcz (dependencies of gparted.tcz).

[Rich]

Hi GNUser

... All icons show up fine even though gnome-icon-theme is not installed. The only icon themes I have installed are adwaita-icon-theme.tcz and hicolor-icon-theme.tcz (dependencies of gparted.tcz).

You are right. I think there is a script that got fixed in one of the extensions to tell GTK to use those other icon packages
if they are installed.

[curaga]

Regarding the .la files, it's an upstream change, not one by us. Those packages changed build systems from autotools to meson, and as a consequence no longer generate .la files.