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 Unsupported. 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#23733 - libreoffice pyuno broken

Attached to Project: Arch Linux
Opened by Francisco Pina (Stunts) - Tuesday, 12 April 2011, 22:50 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 19 August 2011, 14:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Stéphane Gaudreault (stephane)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
pyuno is broken (not very broken, just a little bit), as can be seen in this closed bug:
https://bugs.archlinux.org/task/16636?string=uno&project=0&search_name=&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=closed&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

However, my skills have increased slightly since then and this time I have managed to find the source of the problem.

In order to solve the problem we must patch libreoffice's uno.py (/usr/lib/libreoffice/basis-link/program/uno.py)
The patch is attached. It's my first patch ever, so I hope it's ok. It seems to work on my system.
I have created it based on debian's python-uno package.
This makes pyuno work as expected with the testcase from the above mentioned closed bug. It also makes bibus work correctly.
Let me know if anything else is required.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Friday, 19 August 2011, 14:06 GMT
Reason for closing:  Works for me
Comment by Matt Neilson (machoo02) - Wednesday, 13 April 2011, 19:02 GMT
Hmmm....a fresh install of libreoffice already has this patch incorporated (so it's probably already upstream), but it does not solve the pyuno problem on my system.
Comment by Francisco Pina (Stunts) - Wednesday, 13 April 2011, 22:07 GMT
Woops! I'm sorry! the patch was reversed! Sorry about that! So newbish of me!
I have attached the patch again, this time done right.
BTW, can you please point me somewhere to learn about creating patches the right way, so that this won't happen again?
Comment by Matt Neilson (machoo02) - Saturday, 16 April 2011, 13:23 GMT
Actually, rather than trying to hard-code in ${exec_prefix}, simply including a file in /etc/profile.d that includes:

export PYTHONPATH=$PYTHONPATH:/usr/lib/libreoffice/basis-link/program

similar to what was done in the old openoffice package fixes the problem.
Comment by Francisco Pina (Stunts) - Monday, 18 April 2011, 19:53 GMT
This actually looks more sensible to me... It looks much more dynamic then my patch...
Comment by Matt Neilson (machoo02) - Wednesday, 20 April 2011, 13:03 GMT
Actually, I just tried my export PYTHONPATH suggestion on a completely fresh install, and it does not fix the problem. Your patch solves this problem, as it completely replaces ${exec_prefix} with the actual path.
Comment by Francisco Pina (Stunts) - Thursday, 21 April 2011, 18:46 GMT
So any of the devs think this is good for including? Do you require more testers?
Comment by Stéphane Gaudreault (stephane) - Sunday, 08 May 2011, 01:08 GMT
Did you sent your patch upstream ?
Comment by Francisco Pina (Stunts) - Monday, 09 May 2011, 17:43 GMT
I need some help here. I've been looking at the libreoffice source and I can't find any files that the patch could be applied to.
The only thing relevant that I have found is in the source file "libreoffice-ure-XXXXX.tar.bz2" under "pyuno/source/module/uno.py", but this file is radically different from the one I can see in our (installed) package.
I'm just not sure how to report this upstream...
Comment by Stéphane Gaudreault (stephane) - Monday, 09 May 2011, 18:57 GMT
If you are not sure, report the change against the installed file as you did here. Upstream devs will be quick to find where changes ares needed in the source.
Comment by Francisco Pina (Stunts) - Monday, 09 May 2011, 21:58 GMT
Thank you for the tip.
Reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=37037
Comment by Francisco Pina (Stunts) - Wednesday, 11 May 2011, 22:14 GMT
OK, so I've taken a closer look on the problem.
Seems that the line I have patched does not exist on the original source, however, I cannot find any evidence of it being added in our PKGBUILD.
Doing a diff between our uno.py and the upstream uno.py yelds:
26a27
> import os
27a29,32
>
> sys.path.append('${exec_prefix}/lib/libreoffice/basis-link/program')
> if getattr(os.environ, 'URE_BOOTSTRAP', None) is None:
> os.environ['URE_BOOTSTRAP'] = "vnd.sun.star.pathname:${exec_prefix}/lib/libreoffice/program/fundamentalrc"

And guess what: replacing our uno.py with the upstream one solves the testcase problems and the issues with bibus.
I only figured this out after having had a reply from upstream...
Comment by Matt Neilson (machoo02) - Sunday, 05 June 2011, 13:48 GMT
This is fixed by libreoffice 3.4.0-1, and can be closed.
Comment by John Sivak (jsivak) - Thursday, 18 August 2011, 12:40 GMT
Fresh install of libreoffice 3.4.2 and the uno.py file isn't patched/updated as described in this bug report.
I manually added the patch to uno.py and I am able to run pyuno based scripts again.
Did the fix get "undone" in the 3.4.x releases after 3.4.0-1?
or, if there is an upstream bug report that incorporated the fix exists, then let me know what it is and I'll review it.
Thanks
Comment by Francisco Pina (Stunts) - Thursday, 18 August 2011, 13:29 GMT
I have tested this on my laptop and on a fresh install on a new desktop and I cannot reproduce the error behaviour..
Seems to be working fine for me in both cases.
Anyone else can confirm this, please?
Comment by John Sivak (jsivak) - Friday, 19 August 2011, 14:00 GMT
Sorry for the noise. I'm using PyODConverter (http://www.artofsolving.com/opensource/pyodconverter) and *it* seems to not be "initializing" the environment correctly for use with libreoffice.

I went back to the original bug issue for this thread and confirmed that the current libreoffice *is* working.

Please 're-close' this bug.

Loading...