Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#16636 - [go-openoffice] python uno broken

Attached to Project: Arch Linux
Opened by Francisco Pina (Stunts) - Wednesday, 14 October 2009, 08:11 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 13 May 2010, 10:19 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Python-uno seems to be broken on go-openoffice.
I have found out about this issue using bibus, which can be found in AUR (http://aur.archlinux.org/packages.php?ID=8069).
Initially I tought the problem was in Bibus itself, and submitted a bug in Sourceforge. However, after attempting several thing with the help of the author it seems that the problem is in go-oo itself. You can follow the bug report here:
http://sourceforge.net/tracker/?func=detail&atid=657832&aid=2824340&group_id=110943 .
It seems to be working just fine in Ubuntu's go-oo.

Additional info:
* package version(s)
At least since version 3.1.0.98, but current version is still affected (3.1.1.3-1). I have tested in both x86_64 and i686.

Steps to reproduce:
As in the Sourceforge bug report:
$export PYTHONPATH=/usr/lib/go-openoffice/basis-link/program
$export LD_LIBRARY_PATH=/usr/lib/go-openoffice/basis-link/program:/usr/lib/go-openoffice/basis-link/ure-link/lib
$export URE_BOOTSTRAP=file:///usr/lib/go-openoffice/program/fundamentalrc
$python
>>> import uno
>>> from com.sun.star.util import URL
(1st error)
>>> uno.getClass("com.sun.star.util.URL")
(error again)

Thanks in advance.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Thursday, 13 May 2010, 10:19 GMT
Reason for closing:  Works for me
Comment by Andreas Radke (AndyRTR) - Friday, 16 October 2009, 18:58 GMT
When there's something broken in go-oo code (vanilla too?) you should talk to the upstream (go)OOo devs and file the bug there. I cannot see a pckaging bug.
Comment by Francisco Pina (Stunts) - Saturday, 17 October 2009, 11:22 GMT
Since this isn't present in Ubuntu go-oo, I just assumed it would be wrong with this one. If it's a vanilla bug, then Ubuntu's package is surely patched.
I'll dig a bit into it and see what I can find.
Thanks for your feedback anyway, but please don't close this just yet.
Comment by Francisco Pina (Stunts) - Saturday, 31 October 2009, 13:04 GMT
Damn, I just can't seem to find the ubuntu patch that makes go-oo pyUNO work.
I think it might be http://packages.ubuntu.com/source/karmic/openoffice-python
but I'm not experienced enough to be sure or make it work on Arch...
Any chance you could please look into it? Thanks.
Comment by Andreas Radke (AndyRTR) - Thursday, 05 November 2009, 06:18 GMT
Is our vanilla openoffice-base pkg also broken?
Comment by Francisco Pina (Stunts) - Thursday, 05 November 2009, 09:08 GMT
Last time I checked, openoffice-base pkg was working fine with Bibus. Since it requires python UNO to function, I assume it's OK.
Comment by Andreas Radke (AndyRTR) - Friday, 27 November 2009, 15:45 GMT
If the vanilla OOo version is working it's a bug in Novell's go-oo. Then please file a bug in the Novell tracker and post link to the url here. then we can close this one as upstream.
Comment by Francisco Pina (Stunts) - Sunday, 29 November 2009, 21:53 GMT
I will do just that then.
I will just do something first - download and compile the vanilla go-oo and see if python uno also fails there (they will probably ask me to do it anyway).
I will repost back once I've done that (I am already downloading it).
Thank you for your time.
Comment by Francisco Pina (Stunts) - Sunday, 06 December 2009, 00:20 GMT
Bug reported upstream:

https://bugzilla.novell.com/show_bug.cgi?id=561162

Let's see where it goes from here.
Comment by Francisco Pina (Stunts) - Sunday, 06 December 2009, 01:07 GMT
Wow, they were fast!
Upstream seems to believe that it's a packaging issue...
Where do we go from here?
Comment by Andreas Radke (AndyRTR) - Monday, 07 December 2009, 10:07 GMT
If our Vanilla OOo package is working well you should compare the build settings in our PKGBUILDs what you cause it. If everything is similar/equal I'd rather expext incompatibilities in the Novell code with packages from our system we link against. I won't be able to help here. I don't have any other report about python-uno to be broken.
Comment by Francisco Pina (Stunts) - Monday, 07 December 2009, 22:02 GMT
Comparing the PKGBUILDs there is one difference that meets the eye:
in vanilla OOo the ./configure has a line that reads: "--with-system-python\".

This is missing from the go-oo PKGBUILD. I have also noticed that the go-oo PKGBUILD is much more spartan then vanilla OOo, so this might just be an unnecessary step in the go-oo PKGBUILD.

Do you thing this could be related to it?
Comment by Francisco Pina (Stunts) - Tuesday, 08 December 2009, 12:11 GMT
I've used the official PKGBUILD and added the line "--with-system-python\" to the ./configure options.
The problem remains, so that is not it...
Comment by Andreas Radke (AndyRTR) - Tuesday, 08 December 2009, 16:42 GMT
you can try to build with internal python.

and most distro build ooptions are hidden and preset in go-oo:
http://cgit.freedesktop.org/ooo-build/ooo-build/tree/distro-configs/ArchLinux.conf.in?id=OOO_BUILD_3_1_1_5

you can change them or overwrite in configure. i still have no clue if it fails because go-oo is built using a different system lib and the vanilla against one internal. if not i assume a bug present only in go-oo code.
Comment by Francisco Pina (Stunts) - Tuesday, 08 December 2009, 17:56 GMT
Before diving into the different libs in arch vs. suse, I'd like to attempt building go-oo using internal python.
Do I just pass the option --disable-system-python to ./configure?
Comment by Francisco Pina (Stunts) - Wednesday, 16 December 2009, 10:51 GMT
I've returned to this.
I've checked the link you provided and I have found an interesting pattern:
Neither Ubuntu nor Suse use the option "--with-system-python", like it is present in Arch.
So I'm guessing this is a likely culprit. How can I override the option? What arguments should I pass to ./configure in the PKGBUILD in order to revert to using internal python?
Comment by Francisco Pina (Stunts) - Monday, 18 January 2010, 22:38 GMT
I've been doing some research, but I just can't seem to find a way to build go-oo using the builtin python...
Got any more tips? At least some resource I can research myself. Your last link (despite providing me with lots of info regarding the building of go-oo) was not enough for me to be able to figure it out (or maybe I'm just too inexperienced in building stuff from source). Can you think of anywhere I can start searching, so this bug can finally get closed?
Thanks again.
Comment by Francisco Pina (Stunts) - Monday, 01 February 2010, 10:56 GMT
Confirming the bug is still present with the latest go-oo (3.2.0).
Comment by Andreas Radke (AndyRTR) - Monday, 01 February 2010, 17:14 GMT
add --without-system-python to the configure switches and it will use the internal python:

"checking which python to use... internal"

Good luck and a lot of cpu cycles ;)
Comment by Francisco Pina (Stunts) - Monday, 01 February 2010, 18:02 GMT
Thank you!
I'm working on it right now.
I'll post back the results.
Comment by Francisco Pina (Stunts) - Monday, 01 February 2010, 18:59 GMT
Adding --without-system-python to the PKGBUILD configure switches outputs the following during build:
configure: WARNING: unrecognized options: --with-build-version, --with-dict, --disable-ldap, --enable-lockdown, --with-system-boost, --with-system-cairo, --enable-crashdump, --without-gpc, --enable-opengl, --enable-minimizer, --enable-presenter-console, --enable-pdfimport, --enable-wiki-publisher, --enable-ogltrans, --with-ant-home, --with-system-saxon, --with-saxon-jar, --with-system-beanshell, --with-system-vigra, --with-system-altlinuxhyph, --with-system-lpsolve, --without-system-python, --without-stlport.
And I don't see "checking which python to use... internal" anywhere. Not even a line with "checking which python to use... system".
What am I doing wrong?
Comment by Andreas Radke (AndyRTR) - Monday, 01 February 2010, 20:50 GMT
nothing. just keep it going. real configure checks come later.
Comment by Francisco Pina (Stunts) - Monday, 01 February 2010, 20:59 GMT
Glad I didn't Cancel.
It's still happily going on. I'll probably leave it at it all night.
Comment by Francisco Pina (Stunts) - Tuesday, 02 February 2010, 10:49 GMT
OK, so this didn't work either.
I got the exact same error.
I have found a workaround tough. It's really very crude and I don't like using it, but it does get the job done.
I have traced back the python error and it comes down to setting the URE_BOOTSTRAP variable. Thus, I just went to /usr/lib/go-openoffice/basis-link/program/uno.py and commented out line 36, replacing it with a '' not to break the indentation in the "if" condition.
Fact is that it's now working. But I don't know what else I might have broken...
So, any more suggestions on the build options?
Comment by Andreas Radke (AndyRTR) - Wednesday, 03 February 2010, 16:24 GMT
Maybe you should now open a bug at openoffice's issuezilla and bring both parts of the developers together to find out where the reason is. When it also fails with internal python I assume it's not related to our way we package it.
Comment by Francisco Pina (Stunts) - Wednesday, 03 February 2010, 21:05 GMT
OK, so here's something else I tried:
If I run go-oo's python, I also get an error, here's how:
$/usr/lib/go-openoffice/program/python
>>>import uno
>>> from com.sun.star.util import URL
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/go-openoffice/basis-link/program/uno.py", line 301, in _uno_import
raise ImportError( "type "+ name + "." +x + " is unknown" )
ImportError: type com.sun.star.util.URL is unknown

This of course, after resetting "/usr/lib/go-openoffice/basis-link/program/uno.py" back to the original.

This means that it's not python's fault, since using go-oo's python I get the error too.

Before I go to issuezilla, just to be sure I don't get an answer like Novell's, do you suspect any other culprit?
Comment by Thomas Dziedzic (tomd123) - Saturday, 06 February 2010, 15:44 GMT
Stunts, just open the issue already! XD
Comment by Francisco Pina (Stunts) - Sunday, 07 February 2010, 10:26 GMT
Bug reported upstream... again. =-)

http://qa.openoffice.org/issues/show_bug.cgi?id=109024

Hope it gets sorted out this time.
Comment by Francisco Pina (Stunts) - Monday, 08 February 2010, 17:50 GMT
They seem to have dropped the issue...
I'll do some research on builds, patches, etc, and see what I can come up with...
Comment by Thomas Dziedzic (tomd123) - Thursday, 06 May 2010, 19:01 GMT
python uno seems to be working in go-openoffice, maybe the test case above is missing something...

open oowriter -> Tools -> Macros -> Run Macro -> OpenOffice.Org Macros -> pythonSamples -> TableSample -> createTable -> Run

This will run /usr/lib/go-openoffice/basis3.2/share/Scripts/python/pythonSamples/TableSample.py with no problems.
Comment by Francisco Pina (Stunts) - Friday, 07 May 2010, 08:21 GMT
You are right. However, I have some more info.
I just tried the test case in the new Ubuntu 10.04 and it's also there! (they are using version 3.2.0 of go-oo)
However, in there, Bibus works "out of the box".
It is strange that the guys form Novell told me they had no issues with it...
So... Now what?

Comment by Thomas Dziedzic (tomd123) - Wednesday, 12 May 2010, 21:39 GMT
afaict, python uno works in go-openoffice. If you're having problems with bibus, ask the aur package maintainer for help.
Comment by Andreas Radke (AndyRTR) - Wednesday, 12 May 2010, 21:43 GMT
so can we close this one?
Comment by Francisco Pina (Stunts) - Thursday, 13 May 2010, 08:38 GMT
Although there is a bug here somewhere it is clearly not in Arch.
I guess it's safe to close this one. Thanks for your support.
I must add that I have learned a lot with this bug report nevertheless.

Loading...