[PUSHED][3-5] Re: [REVIEW-3-5] respect absolute paths for mozilla profiles, fdo#45171, lp#919659

On 03/05/12 23:19, Markus Mohrhard wrote:
> Hey,
>
> [1] fixes a nasty problem that if you use absolute paths for the
> mozilla profile in profiles.ini loading/saving password protected
> files fails. The problem has been that in the MINIMAL_PROFILEDISCOVER
> case we just ignored the IsRelative attribute and always assumed that
> the path is relative. The attached patch handles this now correctly
> and uses the path as is if the IsRelative flag is zero.

makes sense, pushed to libreoffice-3-5

> There is one more serious problem that is also mentioned in the linked
> lauchpad bug report. If the .mozilla profile is missing loading/saving
> files seem to fail in this case too but I was unable to debug this
> because libcomphelpgcc3.sois always build without symbols. If someone
> could fix this I might be able to fix the second bug too.

that is weird; on my master --dbgutil built libcomphelpgcc3.so is just
5MB, while on -3-5 --dbgutil it is 17MB... indeed on master there is -O0
on the command but no -g... ahh that Lubos done broke it, with his
newfangled per-library debug setting, turns out in case of "all" we ask
for Library_comphelper, but the known good list contains
Library_comphelp, which is because argh WTF is this
gb_Symbols_get_all=$(foreach item,$(wildcard $(SRCDIR)/*/*.mk)?

that does not work in general, see the various silly things that have
different names on windows in desktop etc.; surely there must be a
better way to do this?

pushed a workaround for comphelper on master, builds with debug now.


> I think that we should include this bug in 3-5 because it affects all
> distros and our windows builds.
>
> Regards,
> Markus
>
> [1] 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=fff2d18a08a37c0fa6a370e56591117fc08664d2