Gnumeric On Eabi, Importing xls solved by new packages from ZDevil !! Options

[Chero]

Hi,

I've got a problem with gnumeric on eabi :
When importing an xls (95) I get the following message :
**(gnumeric:26547): CRITICAL **: workbook_iteration_tolerance: assertion 'tolerance >= 0' failed

(26547 is the process number - the real error are the iterations)
All the "number" cells have strange values. (e.g. 0:30 changes to 0:02) and all reals change really high numbers (E8 or E12).

Anyone has noticed this ?
Anyone has a clue ?

It seems to be an old problem rising again : http://mail.gnome.org/archives/gnumeric-li...y/msg00027.html

This doesn't happen on oabi (Titchy).


Chero.

[jpmatrix]

Hi,

I've got a problem with gnumeric on eabi :
When importing an xls (95) I get the following message :
**(gnumeric:26547): CRITICAL **: workbook_iteration_tolerance: assertion 'tolerance >= 0' failed

(26547 is the process number - the real error are the iterations)
All the "number" cells have strange values. (e.g. 0:30 changes to 0:02) and all reals change really high numbers (E8 or E12).

Anyone has noticed this ?
Anyone has a clue ?

It seems to be an old problem rising again : http://mail.gnome.org/archives/gnumeric-li...y/msg00027.html

This doesn't happen on oabi (Titchy).


Chero.

i've tried to import an xls from excel and got the same problem
however i've tried an xls from openoffice and it seems good...

[dlj0]

Hi,

I've got a problem with gnumeric on eabi :
When importing an xls (95) I get the following message :
**(gnumeric:26547): CRITICAL **: workbook_iteration_tolerance: assertion 'tolerance >= 0' failed

(26547 is the process number - the real error are the iterations)
All the "number" cells have strange values. (e.g. 0:30 changes to 0:02) and all reals change really high numbers (E8 or E12).

Anyone has noticed this ?
Anyone has a clue ?

It seems to be an old problem rising again : http://mail.gnome.org/archives/gnumeric-li...y/msg00027.html

This doesn't happen on oabi (Titchy).


Chero.

i've tried to import an xls from excel and got the same problem
however i've tried an xls from openoffice and it seems good...

I finally got around to checking this. I have the same problem, and it also shows up on *.xls files made by gnumeric (at least those from a different machine, and maybe a year or so ago). It seems that random entries, those with formulas and maybe some pure data entries, get messed up.

*.gnumeric files, even older ones, seem to display just fine.

[Chero]

problem solved by new packages compiled by ZDevil !!!

Upload will probably follow soon.

I'm a happy guy now and ZDevil saved my Z from being reflashed with titchy !!!

Having fun,
Chero.

[dlj0]

problem solved by new packages compiled by ZDevil !!!

Upload will probably follow soon.

I'm a happy guy now and ZDevil saved my Z from being reflashed with titchy !!!

Having fun,
Chero.

Where are these? BTW, as a workaround, if you have another machine with gnumeric, you can load your xls files in it, save them as gnumeric format, and they work properly on the Z. But a better solution would be nice.

[ZDevil]

The packages will be up really soon. Now only waiting for smplayer to get packaged.

[ZDevil]

Uploaded. Please note that you also need the patched libgsf package to enable importing from Microsoft Excel.
Enjoy.

[dlj0]

Uploaded. Please note that you also need the patched libgsf package to enable importing from Microsoft Excel.
Enjoy.

Thanks. It works perfectly. We should have you have a go with iceweasel and icedove.

[ZDevil]

In fact I tried Iceweasel 2.0.0.9 some time ago. The build still suffered from the same mysterious seg fault without any further error message, even with the debugging package. Is there any pointer or patch to refer to? I will surely try again if there are workarounds.

[jpmatrix]

In fact I tried Iceweasel 2.0.0.9 some time ago. The build still suffered from the same mysterious seg fault without any further error message, even with the debugging package. Is there any pointer or patch to refer to? I will surely try again if there are workarounds.

yes it is very curious because iceweasel was working just great under Debian OABI ..........

[apink]

I am trying to get gnumeric working on debian. It is a must have for me, otherwise it is back to pdax.

I have tried several things: I successfully did apt-get gnumeric using the oregon state debian feed and manually installing an older version of gnumeric-common before installing gnumeric. But then it didn't work. The program would not recognize the "1" key and did haywire other things.

I have tried installing ZDevil's packages, but cannot get past the libgoffice depends. apt-get reports that libgoffice-0-5 version 0.5.2 or above is required, but that version 0.5.1-2 is to be installed. I have searched the repositories for libgoffice-0-5 version 0.5.2 with no luck. I can find libgoffice-0-6 but that does not satisfy apt-get. I have tried to do apt-get install -f gnumeric but get nowhere there also.

I am sure that this is a newbie mistake as I am a tried and true newbie. Any help would be greatly appreciated.

[ZDevil]

This seems to be a known bug in GNOME:
http://ubuntuforums.org/showthread.php?p=3777542#post3777542

I also run into a strange issue in epiphany and galeon when the num key "1" launches the help browser.

Tried the fix here: http://bugzilla.gnome.org/show_bug.cgi?id=500881 , but i can only see "1" echo as a screen output in the terminal (when gumeric is launched from the terminal) but does not actually insert "1" in gnumeric.

Any idea? :-?

[ZDevil]

Hey! This seems to work!

First install yelp (the gnome helper) if you didn't: apt-get install yelp

Second do this:

CODE

sudo mv /usr/bin/yelp /usr/bin/yelp1
sudo echo "xmodmap -e 'keysym 0x31 = 1'" > /usr/bin/yelp
sudo chmod 755 /usr/bin/yelp

Now the key "1" is recognized and is inserted as usual in gumeric.

[ZDevil]

Another update:

Don't use my packages. Now armel lenny has all the right packages in place.
So change your /etc/apt/sources.list to the official lenny feeds (see below), followed by a apt-get update
Next first apt-get remove libgoffice*
Then apt-get install gnumeric.
Apply the trick in post #13, if "1" is not recognized (but I got it working without the trick). That's it!

I've tested gnumeric 1.8.1 and it works great.

Here is the feed I use. Quite stable and fast.

CODE

deb http://debian.ethz.ch/debian/ lenny main contrib non-free

[apink]

Another update:

Don't use my packages. Now armel lenny has all the right packages in place.
So change your /etc/apt/sources.list to the official lenny feeds (see below), followed by a apt-get update
Next first apt-get remove libgoffice*
Then apt-get install gnumeric.
Apply the trick in post #13, if "1" is not recognized (but I got it working without the trick). That's it!

I've tested gnumeric 1.8.1 and it works great.

Here is the feed I use. Quite stable and fast.

CODE

deb http://debian.ethz.ch/debian/ lenny main contrib non-free

Thanks for the fixes. Both work and I am using the debian.ethz.ch feed gnumeric.

Now some smaller gnumeric bugs that have popped up. When I enter a 4 for the first character in a cell the cell is filled with the previous value that I entered, wherever that may have been, as if I had entered the paste command. I can get around this by entering "4" as "04". Similarly when I enter a 9 for the first character in a cell nothing happens that I have detected. No 9 and no nothin else. "09" works here also, that is if the first character is not a 4 or a 9 then any succeeding characters can be a 4 or a 9. Interesting.

I had noticed the bug with the 4 in previous gnumeric versions I was using on Lenny. I don't know if the 9 bug is new or was there also. This behavior is similar to the problem with the 1, so I would think that a kludge fix such as echo "xmodmap -e 'keysym 0x31 = 1'" > /usr/bin/yelp would do. Except yelp is not involved in this one. Any ideas are appreciated.

This is not a deal breaker for me but an annoyance I could live without.