Apache OpenOffice (AOO) Bugzilla – Issue 56955
Remove instsetoo_native/inc_openoffice/unix/shellscripts_pyuno.txt
Last modified: 2007-06-18 10:42:28 UTC
It is desirable to prepare minimal shellscripts as far as possible at installation part, and possibly, no shellscripts. However, unfortunately three things had done at shellscripts_pyuno.txt. 1. symlink to python.sh -> python 2. chmod +x program/python-core-2.3.4/bin/python 3. symlink to python-core-2.3.4 -> python-core solution 0. apply following patch. full build confirmed for SRC680_m134, FreeBSD 5.4-RELEASE. 1. Done in scp2 project: prepare scp2/source/python/shortcut_python.scp and scp2/util/makefile.mk, and make a symlink to python.sh -> python. (3. is impossible to solve in this way since we only have python-core-2.3.4.zip in files in scp2.) 2. Do not use program/python-core-2.3.4/bin/python, use program/python.bin instead. python.sh now executes program/python.bin. this is usual way; see e.g., spadmin etc. 3. change from symlinking python-core-2.3.4->python-core to adding version number (by replacing by sed) to python.sh which invoke python in OOo, and we don't have to make a symlink. suggestion (and not yet done): 4. we can also remove symlink from python.sh to python and rename python.sh to python. apparently intermidiate python.sh is unnecessary. currently: python -> python.sh -> python.bin suggested: python -> python.bin delivering a shell script python can harm since we have python binary from python project as well. but this is safe since python (shell script) and python.bin are delivered, at the same time.
Created attachment 31011 [details] remove post process script for python pyuno projects
obr: is this for you?
Add Cc: jbu.
I took another approach in i56189 to solve the script problem by utilizing the fact that the shechscript.txt is just appended to the generated epm list file and does not necessary contain only shellscripts. However, if this solution works, I would be happy to go with it. I still would lite to give the python core zip the "USE_INTERNAL_RIGHTS" flag introduced in CWS sdkinstaller (not yet integrated).
obo: > I still would lite to give the python core zip the "USE_INTERNAL_RIGHTS" flag if we use this we can remove chmod +x for python.bin, but still we cannot make a symlink to python(.bin) to python-core-2.3.4/bin/python.
this could be solved making shellscripts_pyuno.txt look like this: %system linux $group=root %system !linux $group=bin %system all %if !${SYSTEM_PYTHON} l 0000 root ${group} ${base-dir}/program/python-core python-core-2.3.4 l 0000 root ${group} ${base-dir}/program/python python.sh %endif The patch attached to i56189 also contains the code to run epm with base-dir=/opt/openofice.org2 argument. However, I like your approach much better. All I was saying is that even if we integrate your approach, I still would want to give python.zip the new scp flag.
Hi, - renaming python.sh to python: the python executable is delivered as python in the build env. Where do you place the python shell script, so that it is not overwritten ? How do you ensure, that python script, not the executable gets packaged ? - moving python binary to program/python.bin Can be done this way - getting rid of python-core Make sure, that in scp2/source/python/files_python.scp the PYVERSION is also included in the path list of gid_Profileitem_Pythonloader_Pythonpath item (bottom of file). The last 2 modifications make it more difficult, to replace the python runtime in an installed office (as described in http://udk.openoffice.org/python/python-bridge.html#replacing) because you need to change more files (python script, pythonloader.unorc, python executable)), so this is not a change, I really like. However, if the current solution really bears too many problems for some platforms, I would not object to this change. After your modifications, you should test, wether an import uno in python itself still works and you should fire up the office, and check, whether you can find in Tools/Macro/Run Macro dialog a pythonSamples/TableSample/createTable script, then python still runs within the office successfully. Bye, Joerg
jbu: that's exaclty same as what's I experienced when I worked for this patch :) so, do you think it is okay to integrate my patch? with my patch, python.bin will be in /programs/python.bin, not python-core-2.3.4/bin/ obo can move it when cws sdkinstaller get integrated. and also he can rename python-core-2.3.4/bin pyton.bin to python-core-2.3.4/bin/python so that python-core-2.3.4.zip becomes more natural. but this is a cosmetic change. FreeBSD and MacOSX suffer from this, so sooner integration is desirable, namely integrate my patch first, please :)
The gates for 2.0.1 are almost closed - at least I will not have time to apply/build/test this change in the remaining time frame. If the patch gets applied as is for 2.0.1, please leave detailed instructions for me what to change back later (when sdkinstaller is integrated).
obo: > If the patch gets applied as is for 2.0.1, please leave detailed instructions > for me what to change back later (when sdkinstaller is integrated). okay. MacOSX version of 2.0.0 is just released and broken at python part. so inclusion is urgent. I assume when sdkinstaller is integrated we can chmod +x inside of the zipfile (or unalter) changes after the includsion of my patch: o we don't have to deliver python.bin anymore. and we can left python in python-core-2.3.4.zip. no solenv change is required. two pythons are delivered as python and pytho.bin, but we don't need python.bin since python-core-2.3.4.zip now contains executable python. o python.sh should be changed to execute python in python-core-2.3.4.zip instead of execute pytho.bin. o python-core -> python-core-2.3.4: nothing should be changed. replace by sed is the answer, IMHO :) obo: could you please accept issue and set target milestone?
maho: I am obr, not obo ;-). Similar, but different. I only could accept this issue for 2.0.2, since - as stated earlier - I do not have the time to do the necesarry building / testing now. If this issue is urgent enough for 2.0.1, it has to be picked / accepted by someone else. Sorry about that.
obr: sorry I made a mistake about your alias. and understand this is not acceptable for 2.0.1. pjanik: if you are possible to handle this issue, please commit it in your cws. otherwise, I'll wait for 2.0.2. thanks for you all!
maho: I just thought you might have taken me for the real obo (Sun RE). And not accepting this issue for me is really just a matter of time for testing. Just to avoid any ambiguity.
obr: thanks for your advice. I'll add obo in Cc:
obo: this issue is urgent esp. for MacOSX. is it possible for you to handle this issue? sorry for disturbing you so much, and thanks for your generosity.
Hi Maho, I'm sorry but I can't. I've set MH on cc. Regards, Oliver.
maho: why don't you create cws yourself? ;-)
Hi, from my point of view, the part - renaming python.sh to python: is not yet solved. So when you intregate you patch as it is, you'll still need to create the link python->python.sh. Do you still want to change this (and if yes, how) ? Bye, Joerg
pjanik: I'll make it :) jbu: Yes, we need symbolic link python to python.sh. and it is done at scp2/source/python/shortcut_python.scp @@ -0,0 +1,49 @@ <snip> +#include "macros.inc" + +#ifndef SYSTEM_PYTHON +#ifdef UNX + +Shortcut gid_Shortcut_Python_Sh + FileID = gid_File_Python_Sh; + Dir = gid_Dir_Program; + Name = "python"; + Styles = (RELATIVE); +End + +#endif +#endif no additional script is needed.
reassign to maho and set target milestone as 2.0.1
change status to STARTED
fixed in cws_src680_pythonlinkfix
jbu: I aplogize for being late; pythonlinkfix has been nominated. but, could you please approve my cws to be integrated?
Hi, Have you checked whether your changes changes don't cause any harm in build process (at least on linux x86) ? Have you tried a import uno in python executable and have you checked, whether the python macros are still visible in 'Run macro ...' dialog ? I currently do a m138 build to finally test your cws, but this will probably take till next weekend. Is this ok ? Bye, Joerg
jbu: I'm very sorry to say, it has already been integrated (m140). Apologize for this. I haven't tried on GNU/Linux machine, but <ooo>/program/python and import uno works with this patch for FBSD.
Hi, unfortunately this change has introduced a regression, because scp2/source/python/profileitem_python.scp has not been adapted to point to the concrete python version path. The result is, that python components inside the office don't work anymore (and thus the python scripting framework). I have added a patch, which fixes this problem. I hope, I can find someone to introduce the patch before 2.0.1 is out. Bye, Joerg
Created attachment 31649 [details] scp2/source/python/profileitem_python.scp-patch
regression was integrated in m140.
I have asked on release@openoffice.org, if someone can integrate the patch. For the integrator: to qa the fix, start the office on unix, choose Tools/Macros/Run Macro ... , then choose OpenOffice.org Macros , scroll down, at the bottom of the list should be a pythonSamples directory. If it is there, the patch has worked. Bye, Joerg
Hi Jörg, your patch has been introduced as masterfix into m142. Nice to hear from you :-). Oliver.
jbu: I tried with : 2.0m142 at FreeBSD 6.0-RELEASE. I verified o Your patch (profileitem_pytho.scp-patch) is applied correctly o full clean build, and install i found pythonSamples menu Menu : Tools->Macros->Run Macros->OpenOffice.org Macros scroll down ->pythonSamples. Thanks for your kindness.
jbu: I also confirmed that in m141, we cannot find pythonSamples as described. so this regression by me was really solved.
This issue has been "RESOLVED" for quite a time, I assume I can close it ...