Q: LO 2026.02 / pip / Python Macros

CNCman · February 19, 2026, 12:31pm

Hi,

I have some difficulty (on Debian 12 ARM64) with switching from LibreOffice 25.2.3.2 (stock debs from distro) to 26.2 (debs from libreoffice.org).
There will be no 26.2 version of LO for Debian 12 even in backports. Upgrading to higher version to Debian is quite cumbersome since its Raspberry Pi used to control machinery, and LO is integral part of this system.
In general, LO 26.2 (debs from libreoffice.org) works as expected on Debian 12 ARM64 except Python macros called from within Calc spreadsheet.

New LO 2026.2 uses built-in Python interpreter instead of default provided by host OS.

I installed modules with pip (as root, since everything inside /opt/libreoffice26.2/program/ is owned by root):

/opt/libreoffice26.2/program/python -m pip install pyfirmata paho-mqtt distro bitstring tendo schedule jsonpickle tqdm

Installation went fine, yet none of these modules could be loaded by Python script (invoked from within Calc spreadsheet) located in ~./config/libreoffice/4/user/Scripts/python.
This is quite strange since everything installed with pip should be in default Python search path.

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

karolus · February 19, 2026, 2:06pm

Debian 13 (trixie) is »stable« since August 2025!

DONT pip as root!…NEVER!
but now you have to uninstall the mentioned packages as root and then (as normal user):

/opt/libreoffice26.2/program/python -m pip install pyfirmata paho-mqtt distro bitstring tendo schedule jsonpickle tqdm

CNCman · February 19, 2026, 7:48pm

I know pip is not recommended to run as root, but this time I wanted to install everything inside /opt/libreofffice26.2. If necessary I can delete DEBs from system and wipe out entire /opt/libreoffice26.2 dir.

I have run as ordinary user (NOT root):

$ /opt/libreoffice26.2/program/python -c "import sys; print('\n'.join(sys.path))"

/opt/libreoffice26.2/program
/opt/libreoffice26.2/program/python-core-3.12.12/lib
/opt/libreoffice26.2/program/python-core-3.12.12/lib/lib-dynload
/opt/libreoffice26.2/program/python-core-3.12.12/lib/site-packages
/opt/libreoffice26.2/program/python-core-3.12.12/lib/python312.zip
/opt/libreoffice26.2/program/python-core-3.12.12/lib/python3.12
/opt/libreoffice26.2/program/python-core-3.12.12/lib/python3.12/lib-dynload
/opt/libreoffice26.2/program/python-core-3.12.12/lib/python3.12/site-packages

and

$ /opt/libreoffice26.2/program/python -m pip list
Package    Version
---------- -------
bitarray   3.8.0
bitstring  4.3.1
distro     1.9.0
jsonpickle 4.1.1
paho-mqtt  2.1.0
pyFirmata  1.1.0
pyserial   3.5
schedule   1.2.2
six        1.17.0
tendo      0.3.0
tqdm       4.67.3

Everything seems to be just fine, I can’t understand why it’s not working…

robleyd · February 20, 2026, 10:58am

Cross posted on the OpenOffice forum.

If you cross post, as a courtesy please let us know that you have done so, otherwise it leads to several discussions and a waste of time because several identical answers may be posted by different users.

karolus · February 20, 2026, 11:12am

nothing new! …

The packages from TDF have always used embedded Python versions.
Only the LO packages provided by Linux distributions use the Python environment of the operating system.

CNCman · February 20, 2026, 6:44pm

After some tricky and time consuming experiments I can draw a definitive conclusion - don’t use LibreOffice.org binary packages with spreadsheets relying on complex Python macros. Period. Stock packages from host Linux distro is the only way to go.

Correct way to install extra modules with LO embedded Python interpreter is this:
Run as user, not root.

mkdir ~/.config/libreoffice/4/user/Scripts/python/pythonpath/
/opt/libreoffice26.2/program/python -m pip install  --target ~/.config/libreoffice/4/user/Scripts/python/pythonpath <your_extras>

Modules could be loaded by Python script (invoked from within Calc spreadsheet), yet abort with errors:

# Could not find platform independent libraries <prefix>
# Could not find platform dependent libraries <exec_prefix>

Possible cause - when LO uses its embedded Python, there’s a critical issue with shared library extensions on Linux. The embedded Python looks for .so files with a different naming pattern than what pip installs .
Specifically:
pip installs: module.cpython-3x-x86_64-linux-gnu.so (with platform tag)
Embedded Python looks for: module.cpython-3x.so (without platform tag)

AI suggested hackwork to switch built-in LO Python interpreter to OS-hosted doesn’t work.

Hope this will help someone to save a lot of time and energy.