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