regression compared to 3.3.2.

Alex

The same in Windows. Changing OS to All.

Hmm, this should have been fixed by http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4&id=3709e6a8ecdd18dec008094a11f90b3d99d837f9

It might be related to the bug #33355.

see https://bugs.freedesktop.org/show_bug.cgi?id=36915#c7
and 
https://bugs.freedesktop.org/attachment.cgi?id=46541

*** Bug 35139 has been marked as a duplicate of this bug. ***

I will have a look

well for beanshell it seems that the bsh.jar isn't found, I guess we need to either put it in the classpath or in the root of the extension ( iirc the scriptframework adds that to it's custom classpath )

sigh I am looking at the wrong bug, this one is to do with the packaging of the scriptproviders, I thought I was looking at the bug #36915

I see all four: Basic, BeanShell, Python, JS in Tools/Macros/Organize Macros on Linux with LO-3.4.0-beta5

I did not see them with LO-3.4.0-beta5 build on Windows. They appeared after I installed the optional "Python-UNO Bridge" component => they are included but not installed by default

=> FIXED

Please open new bug if you want to have them installed on Windows by default.

Whoa, that "Python-UNO Bridge" component is then seriously misnamed in the installer. One more reason to have *less* optionality in the installer.

Not fixed in 34b5 (clean install) on Mac OSX, I can still only see the LibreOffice Basic entry.


Re-opening.

Alex

Enclosing a screenshot taken today of the Extensions manager where it can be seen that all of the scripting extensions are alleged to be installed, but where the beanshell extension displays an error as to its status and is in a dimmed state.


Alex

Created attachment 46777 [details]
screenshot of GUI extensions manager in 3.4b5 on mac osx

Thorsten, could you please have a look? It seems that the problem remains only on MAC.

Please, make sure that you use the following configure options:

    --enable-ext-scripting-beanshell
    --enable-ext-scripting-javascript
    --enable-ext-scripting-python

Ah, I read it more carefully and see that the scripting support is actually available. "Just" the beanshell stuff does not work. This is being solved in the bug #36915.

Let's close this bug because the original problem has been solved. Let's discuss the Beanshell problem in the other bug.

Apart from the python one, I really wonder if the others are *ever* really used in the real world.

If they aren't (but as I commented on the Beanshell, I suspect that one is used in the realworld), then the minimum would be to provide the extensions as a separate download, so that people don't have to build the whole of LibO just to have them.


Alex

Re-opening.


Just tested RC1 for Mac OSX Intel 10.6.7.
Clean install - removed the app bundle and the User/Library/Application Support/LibreOffice folder before installing.


I still only see the Basic entry in the Tools > Macros > Manage Macros.


Alex

@Thorsten : can you check this for me ?


Alex

(In reply to comment #19)
> @Thorsten : can you check this for me ?
> 
> 
> Alex


My build version :

LibreOffice 3.4.0 
OOO340m1 (Build:11)


Alex

Changed platform to Mac OS as others have reported it fixed for other OSes.


Alex

Sigh, this isn't bug 34699 again is it ? In the Extensions Manager, the scripts are considered to be installed correctly but the corresponding UI entries do not appear. 


Alex

Created attachment 46951 [details]
screenshot of beanshell script failure

Tried installing some extra extensions via the Extension Manager UI. Restarted the application. The script menu entries now appear, but some fail to execute with the error shown in the screenshot (for that particular Beanshell script).


Alex

Created attachment 46953 [details]
screenshot python script failure

Reducing the severity a bit. It is used only by extensions => not a core functionality => can't  block the 3.4.0 release

Errm, have I misunderstood something here ? Before during the betas, it was considered a blocker, and now it suddenly isn't anymore ? I'm sorry I really don't understand.


Alex

(In reply to comment #27)
> Errm, have I misunderstood something here ? Before during the betas, it was
> considered a blocker, and now it suddenly isn't anymore ? I'm sorry I really
> don't understand.

I started to clean up the severity of blocker bugs a week ago. I wanted to see where we were for the release. I did not mind about bugs that were fixed or about to be fixed. Otherwise, I would have lowered the severity of this bug a week ago as well.

Note that LO has another release criteria because we use the time based release, see http://wiki.documentfoundation.org/Release_Criteria

By other words, we do not want to wait 3 months until all known annoying bugs are fixed. There were always annoying bugs found after the release and people need to wait another 3-4 months for the fix. Also most of the bugs were annoying only for a selected group of users. We want to release early, do bugfix release every month, inform people about known most annoying bugs in the release notes. This way we make the release predictable and will make bigger and bigger group of users happy every month. Note that we do not stop producing 3.3.x bug fix releases after 3.4.0 is out. The 3.3.x code base will be suggested over 3.4.0 for users that want a perfect stability and usability.

Update :

The same problem currently exists in the master nightly builds from 27/06 and 28/06.

In 27/06 build, only Python scripting was unavailable in the UI and non-functional (despite being installed).

In 28/06 build, all of the scripts other than Basic are no longer available in UI (although they appear in the Extensions Manager). The Python scripting provider is greyed out.


Alex

deploying a python extension, i end with

/basis-link/program/libpyuno.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8

(3.4.0 branch, linux, built --without-system-python)

same --with-system-python (ubuntu 10.10)
/basis-link/program/libpyuno.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8

regarding PyUnicodeUCS4_DecodeUTF8 error

solved by cleaning and rebuilding pyuno after changes wi the configure python switch

(15:19:28) caolan: lgodard: looks to me that this *specific* error is that pyuno_util.o was created from pyuno_util.cxx on the original setup with external system python, and there are no rules to rebuild it when relinked against the internal one or something like that

*** Bug 36915 has been marked as a duplicate of this bug. ***

ok, 

a) so, reportedly now on mac for python:

Christian Lohmaier wrote: "On both 3.4.2 as well as on master all the supplied samples work."

if there are remaining problem, lets open new bugs for them (feel free to assign/cc me on them), its gets really messy when a bug gets reopened as similar symptoms may not be the same problem as the original.