LibreOffice 5 Linux / Python Macros = failure (#NAME? error)


I have OpenSUSE 13.2 x64, and today I updated LibreOffice to version 5.
Unfortunately, all python Macros stopped working (#NAME? error everywhere).

LibreOffice 5 uses one of these config dirs (depending upon build,
either from either from SuSE factory) for storing Macros:

All python Macros are here, and were working with LibreOffice 4.x just
prior upgrade to v5.

Security setting are the same as before, allowing execution of macros.

Tools → Organize → macros → Python Macros - still lists all of them.

Anyone have any idea what went wrong?
Thanks in advance.

[Edit: added OpenSUSE13.2 + lo5 tags]

Finally I have solved this problem.
For whatever reason (I think its a bug or glitch), new LibreOffice 5.x on first start simply overwrites XML config file script.xlb, it need to be re-created manually or from backup.

More details in my blog:

Youre complaining about #Name?-Error so my guess is, some Calc-addin-functions written in python are not available
( NUMBERTEXT ? , MONEYTEXT ? ) maybe you need to reinstall these AddinExtensions ?

“my” LODev5-beta has created a different Userconfig ~/.config/libreofficedev/4

My still the same location from LO 4.x

Hi, karolus,

Thanks for reply. Unfortunately, NONE out of about my 50 functions work anymore. Some are quite simple, some complex. Looks like a bug somewhere in LO, but I can’t figure where.

We can’t either - because we know nothing about the functions nor where they are stored?

did you talk about ~50 Addin-functions written in python ?

what was your previous LO-version ?

Hi, Karolus,

My current version is 5, previous was 4.4.
Python macros are plain text *.py files, stored in both (for compatibility between SuSE and builds)

Additionally, there custom modules *.xba installed in
These are “glue” functions between LO Basic and Python, and its seems LO5 for whatever reason don’t see them anymore.

For the avoidance of doubt:-

5.x uses the identical Profile directory to 4.x versions.

3.x uses a different Profile dir to 4.x versions (/3/ rather than /4/).


(following Doug’s comment):

Choosing to make the 5.x Profile directory layout identical to the 4.x layout is for me potentially a deeply stupid decision. It may be the source of the problem in this question. The reason for my statement becomes clear as soon as I say that the palette layout for LO4/OO4 was changed from the LO3 standard of 10 columns to the LO4 standard of 12 columns (and, as I understand it, a corresponding change in the format of the .soc file). Thus, if every LO5 layout is identical to the corresponding LO4 layout, then no problem. However, if that is true then why did the version change from 4 to 5?

As I understand the LO macros (which is not fully) they need to be imported/exported from within LO rather than just physically moved. That is supposed to occur as part of the upgrade process but, using the .soc files as an example once again, they were over-written with new defaults during some previous upgrades, causing all previous changes to be lost.


so they just need to be moved physically to the new profile, right? Then that would fix the error.

Right, but in case of Extensions you have move at minimum the whole .../uno_packages/cache/ not only some folders below .../uno_packages/cache/uno_packages/
@AlexKemp for example palette.soc stores only the mapping from colorname to color-(hexvalue) nothing about the layout how it should shown in the GUI.