Description of problem: LibreOffice Extension manager fails to register extensions Version-Release number of selected component (if applicable): 1:4.0.3.3-2.fc19 How reproducible: Consistent Steps to Reproduce: 1. Install fedora-19 RC2-4 2. Fire up LibreOffice 3. Attempt to register an extension via the Extension Manager (I used MRI and my own extension) Actual results: You get an error message (com.sun.star.lang.DisposedException) { { { Message = "Binary URP bridge disposed during call", Context = (com.sun.star.uno.XInterface) @7fb7d95019c0 } } } Expected results: Extension should register and be available to LibreOffice Additional info: This error doesn't show in LibreOffice downloaded straight from Document Foundation (LibreOffice) Website.
I cannot reproduce. Installing mri-1-1-4.oxt obtained from <http://extensions.libreoffice.org/extension-center/mri-uno-object-inspection-tool/releases/1.1.4/mri-1-1-4.oxt> in libreoffice-4.0.3.3-2.fc19.x86_64 works fine here. Onyeibo, what is the output of "unopkg list" for you when run in a terminal? Also, does the problem go away if you temporarily move away your ~/.config/libreoffice directory (a new one will be created; you can restore the original one afterwards to not loose any of your custom settings)?
I have spotted the problem. The OS was installed from F19-RC2 live media and libreoffice-pyuno package was not included in the composition. This is a major omission IMHO. MRI and my extension both require pyuno to function.
(In reply to Stephan Bergmann from comment #1) > I cannot reproduce. Installing mri-1-1-4.oxt obtained from > <http://extensions.libreoffice.org/extension-center/mri-uno-object- > inspection-tool/releases/1.1.4/mri-1-1-4.oxt> in > libreoffice-4.0.3.3-2.fc19.x86_64 works fine here. As it turns out, the file mri-1-1-4.oxt that currently gets downloaded from <http://extensions.libreoffice.org/extension-center/mri-uno-object-inspection-tool/releases/1.1.4/mri-1-1-4.oxt> is some junk HTML content misleadingly named with an ".oxt" extension, and when asked to install it as an extension, LibreOffice installs a bogus "empty" extension but does not give an error. That's why trying this specific mri-1-1-4.oxt would always have succeeded trivially (though the problem can be reproduced fine with the older version <http://extensions.libreoffice.org/extension-center/mri-uno-object-inspection-tool/releases/1.1.2>). (I fixed upstream LibreOffice master towards LO 4.2 to fail with an error in such a case now with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b562710cb8051e921726899246b421b197d49f0> "Let package_ucp::ContentProvider::createPackage throw exceptions on failure," but the fix is a bit risky and does not provide enough benefit to warrant backporting.) (In reply to Onyeibo from comment #2) > I have spotted the problem. The OS was installed from F19-RC2 live media > and libreoffice-pyuno package was not included in the composition. This is > a major omission IMHO. MRI and my extension both require pyuno to function. I improved on this problem (trying to install a Python extension when pyuno is not installed) somewhat with a commit to upstream LibreOffice master towards LO 4.2, <http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b91e84c72596d8d1dc3687292c9946f172c4df6> "Optional pyuno module should have its own services/pyuno.rdb." But again, the benefit (a slightly less cryptic error message) is arguably too little to warrant any backporting.