https://bugs.freedesktop.org/show_bug.cgi?id=54450

--- Comment #4 from David Tardon <dtar...@redhat.com> 2012-09-07 08:27:22 UTC 
---
(In reply to comment #0)
> Created attachment 66563 [details]
> evolution address book driver registration
> 
> TEST1
> 
> Reproduction instructions:
> 
> 1) compile LibO with --enable-evolution2 passed to ./autogen.sh
>    (our official builds don't have that)
> 
> 2) run LibreOffice
> 
> 3) Menu File / Wizards / Address Data Source
> 
> Actual Behaviour: Choices "Evolution", "Groupwise" and "Evolution LDAP" are
> missing
> 
> Expected behaviour: these choices are present.

I see them just fine.

> 
> 
> TEST2
> 
> Reproduction instructions:
> 
> 1) compile LibO with --enable-evolution2 passed to ./autogen.sh
>    (our official builds don't have that)
> 
> 2) run LibreOffice
> 
> 3) open attachment 47889 [details]
> 
> 4) in the left pane, click on "tables"
> 
> 
> Actual Behaviour: Error message "no SDBC driver found for URL"
> 
> Expected behaviour: list of Evolution address books, e.g.: "Personal", appears
> in the lower right pane

Yup, works here too.

> My analysis shows that the driver (libevoablo.so) is:
> 
> 1) Not installed
> 2) Not registered
> 

My analysis shows that that is not true :-)

> This whole install / registration stuff is a bit of a magic blackbox for me.
> For example, the mozab driver somehow ends up in install/program/services.rdb,
> but I cannot find *how* so that I can do the same with evoab. Weirdly, mozab 
> is
> not in 
> workdir/unxlngx6/Rdb/ure/services.rdb, but it is in
> install/program/services/services.rdb

It is in workdir/unxlngx6/Rdb/uno_services.rdb . ure/services.rdb is for URE
services only.

> 
> I took "inspiration" from PostgreSQL-SDBC to generate a working evoab.rdb that
> I could drop there. It would maybe be better to put evoab also in services.rdb
> rather than its own file?

It has never had a rdb file of its own, i.e., its service description has
always been placed into services.rdb .

> 
> 
> I tried to hack our install system to do "the same with evoab than with 
> mozab",
> but failed to have it make what I wanted.

This happens in postprocess/packcomponents/makefile.mk .

> 
> 
> @dtardon: you switched connectivity to gbuild; could you please double-check
> that  this regression was not introduced during that switch, in that the 
> gbuild
> fails to do what the dmake did? Thanks.

Well, it is evident that it does work at least somewhere :-) It is possible
there is some other condition that is true here but not in your build and which
causes the evoab driver not to be included in the installation. I will double
check for this.

-- 
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
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to