Bug 55005 - macro libraries from previous version, copied with whole user/basic folder, are not available - scripts.xlc in /user/basic is changed on first start of LibreOffice
Summary: macro libraries from previous version, copied with whole user/basic folder, a...
Status: RESOLVED DUPLICATE of bug 51267
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
3.6.2.1 rc
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-17 10:14 UTC by Cor Nouws
Modified: 2014-11-18 15:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2012-09-17 10:14:43 UTC
macro libraries from previous version, copied with whole user/basic folder, are not available - scripts.xlc in /user/basic is changed on first start of LibreOffice 3.6.2rc1


Background:

I work on Ubuntu with many (test) versions and often copy the user-registry from an older version to the path for a new version


What hapened:

- Copied my .config/libreoffice/356/user tree to 362rc1/user
- Started 3.6.2rc1
- From the macro's, only Stadard library was available.
Normal for me, is that all are available.


Analyses:

cono@cono-tm-new:~/.config/libreoffice$ ls -l 362rc1/user/basic/script*
-rw-rw-r-- 1 cono cono 6701 sep 17 11:08 362rc1/user/basic/script.xlc
-rw-r--r-- 1 cono cono 6574 sep 17 11:08 362rc1/user/basic/script.xlc~
cono@cono-tm-new:~/.config/libreoffice$ ~/scrpts/362rc1  ' STARTING LibreOffice
cono@cono-tm-new:~/.config/libreoffice$ ls -l 362rc1/user/basic/script*
-rw-rw-r-- 1 cono cono  406 sep 17 11:09 362rc1/user/basic/script.xlc
-rw-r--r-- 1 cono cono 6574 sep 17 11:08 362rc1/user/basic/script.xlc~

So when I start 3.6.2rc1 for the first time (after copying the user-tree from 356) the script.xlc is changed

All libreries are still in the path and declared in script.xlc~
So this of course cures the problem:
$ mv 362rc1/user/basic/script.xlc 362rc1/user/basic/script.xlc_BAK
$ mv 362rc1/user/basic/script.xlc~ 362rc1/user/basic/script.xlc
Comment 1 Noel Power 2012-09-17 14:03:52 UTC
ok I tried ( more than once ) and failed to reproduce this, perhaps I am doing something wrong. Ok worth mentioning I am using recent branch versions of 3.5 and 3.6 builds ( but I doubt there is any relevant in that fact )

here's what I did.

1) modified bootstraprc in 3.5 installation to point to new location ( presumably this is what you do for your .config/libreoffice/356 & .config/libreoffice/362rc1/user trees
2) same for bootstraprc in 3.6, now both installations point to somewhere other than the default ~/.config/libreoffice/3 location
3) started both 3.5 & 3.6 versions to populate the user registry directories, shut both office instances down
4) started 3.5 office, then created 2 (user) libraries, shut down office
5) started 3.6 office, made sure I didn't see the new libraries ( yes, I am prone to making stupid mistakes so this step was necessary )
6) cp -a {patch to 3.5}/UserInstallation/user/basic/* {Path to 3.6}/UserInstallation/user/basic/
7) start libreoffice, libraries are visible :/

what did I do wrong ?
Comment 2 Noel Power 2012-09-17 14:06:25 UTC
maybe might be an idea to upload the entire ( but broken ) basic user folder too ( can mail it too me if sensitive etc. )
Comment 3 Cor Nouws 2012-09-18 21:24:44 UTC
Hi Noel,

Thanks for looking, trying...

(In reply to comment #1)

> 5) started 3.6 office, made sure I didn't see the new libraries ( yes, I am
> prone to making stupid mistakes so this step was necessary )

(something I do recognise ;-) )

> 6) cp -a {patch to 3.5}/UserInstallation/user/basic/* {Path to
> 3.6}/UserInstallation/user/basic/
> 7) start libreoffice, libraries are visible :/
> 
> what did I do wrong ?

I copied the whole user registry tree (contrary to your step #6)

Prolly the presense of an 'alien' registrymodifications.xcu (or so), triggers the (a) change(s) further down in that tree?
Also key customizations are lost, I found out today. (So that is the  registrymodifications.xcu)

(Stupid is that I have looked at this month or so ago, but have completely lost track of the findings/thoughts, due to some overload :-\ )
Comment 4 tommy27 2012-11-24 09:29:24 UTC
I don't know if this may help, but with previous versions I was able to make the macro appear again just overwriting the "User\LibreOffice 3\user\basic" subfolder twice...

I mean, the first copy of the "basic subfolder" from old LibO version into the new version has no effect since at first launch LibO doesn't recognize the macros, as described in the issue report.

but if you close LibO and erase the "basic subfolder" and copy  it again from the old profile, the 2nd lauch of LibO will recognize the macros.

this was my experience using portable version of LibO (X-LibreOffice:  http://www.winpenpack.com/main/download.php?view.1338 )

my idea is that something gets screwed up in the basic subfolder during first launch of LibO... however at 2nd launch things work again if you copy again the basic subfolder in the meantime.

did anybody try to copy the "basic" subfolder twice?
it worked for me in several Windows versions using X-LibO.
Comment 5 Cor Nouws 2012-11-24 09:42:41 UTC
(In reply to comment #4)
> I don't know if this may help, but with previous versions I was able to make
> the macro appear again just overwriting the "User\LibreOffice 3\user\basic"
> subfolder twice...
> 
> I mean, the first copy of the "basic subfolder" from old LibO version into
> the new version has no effect since at first launch LibO doesn't recognize
> the macros, as described in the issue report.
> 
> but if you close LibO and erase the "basic subfolder" and copy  it again
> from the old profile, the 2nd lauch of LibO will recognize the macros.

Thanks, this makes perfect sense in the light of the explanation of Bug 52022.

- on the first start, something makes that the oosetupcompleted info in the older registrymodifications is not reached, which triggers the recreation of (some) xml files, that in the case of the basic library, thus are clean and do not have entries for the libraries (that do exist in the basic folder).

Thus overwriting the basic/script.xlc and basic/dialog.xlc is enough.
Comment 6 tommy27 2013-05-03 00:55:52 UTC
@Cor
are you still experiencing this issue with latest 4.x.x versions?
Comment 7 Cor Nouws 2013-05-03 09:05:55 UTC
@ Tommy,

(In reply to comment #6)
> are you still experiencing this issue with latest 4.x.x versions?

Thanks for asking. Alas, the problem is still there...
Comment 8 tommy27 2013-05-03 09:16:12 UTC
however keep in mind that the "overwrite twice" trick solves the issue
Comment 9 Cor Nouws 2013-06-08 22:33:15 UTC
(In reply to comment #8)
> however keep in mind that the "overwrite twice" trick solves the issue

So I tried to copy the basic libraries from 4.0.3 to 4.1.0beta...
Does not work. Still.

And worse: copying the basic/script.xlc and basic/dialog.xlc again, does not help :(
Comment 10 tommy27 2013-06-09 04:13:33 UTC
mmmhhh... sounds like a MAB...
Comment 11 Cor Nouws 2013-06-09 08:43:45 UTC
(In reply to comment #10)
> mmmhhh... sounds like a MAB...

My mistake: the copy 2nd time does help.
(I modified the folder in bootstraprc but not the full path - sorry!)
Still, annoying.
Comment 12 Cor Nouws 2014-11-18 14:29:28 UTC
(In reply to Cor Nouws from comment #0)

> What hapened:
> 
> - Copied my .config/libreoffice/356/user tree to 362rc1/user
> - Started 3.6.2rc1
> - From the macro's, only Stadard library was available.
> Normal for me, is that all are available.

Hard to say now, but probably I copied all _except_ the registrymodifications.xcu


(In reply to Noel Power from comment #1)

> here's what I did.
> [...]
> 3) started both 3.5 & 3.6 versions to populate the user registry
> directories, shut both office instances down

So this resulted in two fresh office-instances including the  registrymodifications.xcu


(In reply to tommy27 from comment #4)
> I don't know if this may help, but with previous versions I was able to make
> the macro appear again just overwriting the "User\LibreOffice 3\user\basic"
> subfolder twice...

Indeed, the second time there already is a registrymodifications.xcu, so the basic.xlb and script.xlb are left untouched ;)


(how long can some things take ;) mark as duplicate now)

*** This bug has been marked as a duplicate of bug 51267 ***
Comment 13 tommy27 2014-11-18 15:32:29 UTC
(In reply to Cor Nouws from comment #12)
> ...
> 
> (In reply to tommy27 from comment #4)
> > I don't know if this may help, but with previous versions I was able to make
> > the macro appear again just overwriting the "User\LibreOffice 3\user\basic"
> > subfolder twice...
> 
> Indeed, the second time there already is a registrymodifications.xcu, so the
> basic.xlb and script.xlb are left untouched ;)

cool, now there's a rational explanation to it!!!


> (how long can some things take ;) mark as duplicate now)

sooner or later, it's always better than never.

> *** This bug has been marked as a duplicate of bug 51267 ***