https://bugs.freedesktop.org/show_bug.cgi?id=51252
Stephan Bergmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Severity|critical |blocker Priority|highest |high AssignedTo|[email protected] |[email protected] |desktop.org | --- Comment #35 from Stephan Bergmann <[email protected]> 2012-07-26 11:18:15 PDT --- I now understand what is going on, know how to reproduce the problem, and have found a solution. There are various factors that are involved: 1 The LO 3.6.0 installation set needs to contain a share/prereg/bundled directory (containing pre-registered information about bundled extensions, that is later copied into per-user configuration data, when a user starts LO). This is automatically created (via "unopkg sync") for standard installation sets when those installation sets are created in instsetoo_native. However, it is not created for the "make dev-install" installation set (at least not on Linux), in which case one needs to create it manually to reproduce this problem, calling "install/program/unopkg sync --verbose" (and watch out for errors, see next). 2 The LO 3.6.0 build must not be configured --enable-ext-barcode (to include the Barcode extension as a bundled extension in LO installation sets). Registering that extension as a bundled extension is broken. (Quoting from a recent mail to Kami: "The problem (building with --enable-ext-barcode leads to a broken bundled Barcode extension) is still there with Barcode version 1.3.5, but I now found out why that is so: If you start with a fresh user installation (i.e., after 'rm -rf ~/.config/libreoffice' on Linux), LO tries to register bundled extensions' components in an environment where bundled extensions' configuration data is not available. But Barcode's barcode-loader.py requires Barcode's Barcode.{xcs,xcu} to be registered (def getpath: 'config = getconfig( ctx, 'org.openoffice.%sSettings/ConfigNode'%classname )'), which raises an exception that is unhelpfully swallowed by the try: ... except: debugexception() in barcode-loader.py. Using passive component registration for Barcode should work around that problem.") That in turn causes "unopkg sync" (whether called automatically in insetsetoo_native or manually, see above) to silently fail mid-way, leading to a half-populated share/prereg/bundled that might or might not allow to reproduce the problem. 3 At least on Linux (other than on Windows) the problem cannot currently be reproduced because <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfbece50ebaeaf45ea3f016d911b5de7c878afc5> "Make --help and --version work even without $DISPLAY" added UNX-only code that already creates the service manager very early (at the start of soffice_main), before Desktop::Init decides whether or not to copy share/prereg/bundled into the per-user configuration data. That inadvertently hides this problem. (But it leads to issues of its own, like bundled extensions not working properly on first start. Those issues are fixed with the fix for this issue, too, namely to not copy share/prereg/bundled into per-user configuration data, see below) To work around that reproduction hindrance, one can temporarily disable that code in LO 3.6.0, by replacing the "#ifdef UNX" in soffice_main (desktop/source/app/sofficemain.cxx) with "#if 0". 4 One needs a LO 3.5.x installation (or maybe even older) including some bundled extension X (that contains UNO components), and that same extension also as an oxt. Also, the LO 3.6.0 installation set needs to bundle that extension (in a higher version), too. For example, I used the LO 3.5.4 that comes bundled with Fedora 17 as /usr/lib64/libreoffice/program/soffice. It bundles Presenter Console 1.1.0, and the LO 3.6.0 installation set bundles Presenter Console 1.1.1. (To produce an oxt of Presenter Console 1.1.0, one can do "(cd /usr/lib64/libreoffice/share/extensions/presenter-screen && zip -r ~/old-presenter-screen.oxt *)".) 5 Produce a clean starting point by removing any old per-user configuration data, "rm -rf ~/.config/libreoffice". 6 Start the LO 3.5.x (/usr/lib64/libreoffice/program/soffice), "Tools - Extension Manager...", "Add...", select the old-presenter-screen.oxt, install it for the current user only. (It will replace the bundled version for this user, the Extension Manager will display it without a lock now.) 7 Make sure the LO 3.6.0 share/prereq/bundled/lastsynchronized is newer than the corresponding ~/.config/libreoffice/3/user/extensions/bundled/lastsynchronized: "touch install/share/prereq/bundled/lastsynchronized" (or wherever that installation is). 8 Now start the LO 3.6.0 soffice. It will fail to start, reporting some "UNO Exception: InvalidRegistryException: file:///.../opt/program/../share/extensions/presenter-screen/components.rdb: duplicate <implementation name='com.sun.star.comp.Draw.framework.PresenterScreenJob'>." 9 The problem is that LO is careful to only ever have a single instance of an extension actually installed for a given user (even if instances of that extension are installed both bundled and per-user), but the logic to copy share/prereg/bundled into the per-user configuration data bluntly shortcuts that and breaks that carefully maintained invariant. The irony is that share/prereg/bundled is only an optimization, to save a little time at first start of LO (when started for the very first time for a user, or after an upgrade). For functionality it is not needed---rather, it is demonstrated here to be harmful, at least in its current implementation (see both this problem and the issues mentioned under (3)). Therefore, I propose to fix this by disabling the share/prereg/bundled feature. The simplest way to do so for LO 3.6.0 is by adding "if (false)" before the call to copy_bundled_recursive in Desktop::Init (desktop/source/app/app.cxx). (That way, compiling does not cause spurious warnings about unused code.) 10 However, once a user ran into this problem (which in turn can only happen if she ever ran a LO snapshot up to LO 3.6.0 rc3), her per-user configuration data is broken, and fixing LO 3.6.0 as per (9) will not help. In such a case, it is necessary to manually remove the "extensions" directory from the per-user configuration data once: "rm -rf ~/.config/libreoffice/3/user/extensions". That per-user information about bundled (and shared) extensions is strictly a cache; it is recreated upon the next start of LO without any loss of functionality. 11 I explained the above in the context of Linux, but I verified that it all works exactly the same on Windows. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
