Planner needs transition from libgda2-dev to libgda3-dev

[Marco Rodrigues]

Binary package hint: planner

This package needs to transition from libgda2-dev to libgda3-dev, so it can be built in main. It's already asked to debian maintainer of planner to do that change.

http://launchpadlibrarian.net/11323837/buildlog_ubuntu-hardy-i386.planner_0.14.2-4ubuntu1_MANUALDEPWAIT.txt.gz

It builds fine in my Hardy pbuilder. I'll attach a debdiff...

[Martin-Éric Racine (q-funk)]

As I recall, Daniel Holbach pointed out earlier that simply updating the Build-Depends isn't enough to have succesfull gda3 support. The upstream code itself would need to be upgraded to correctly operate with it. This is not a trivial task.

[Daniel Holbach (dholbach)]

Martin-Éric is right. In addition to dropping --enable-database we also need to drop libgda2-dev as a Build-Depends.

[Oliver Grawert (ogra)]

it seems to build fine with gda3, the patch is lacking some stuff though, please fix the versioning of the build-dep for gda3 accordingly (the (>= 1.2.1) i mean) ...
and i doubt it will work with gda2-postgres after switching to gda3, so the recommends need update as well ...

It seems OpenSuSE uses the same planner version we have just with a gda3 build dep as well, our planner package compiled with the above patch seems to work fine too, so i think we can safely just update the build-dep ...

[Daniel Holbach (dholbach)]

Make sure libgda3 turns up in the depends after building with gda3 and is actually linked against it.

[Marco Rodrigues (gothicx)]

Ok.. I've already changed the version check to 1.2.4. I talk with Oliver, and we also need to check if gda2-postgres in Recommends works fine.

[Martin-Éric Racine (q-funk)]

On 1/16/08, Marco Rodrigues <email address hidden> wrote:
> Ok.. I've already changed the version check to 1.2.4. I talk with
> Oliver, and we also need to check if gda2-postgres in Recommends works
> fine.

No. If you upgrade to libgdda3, you also need to upgrade to gda3-postgres.

--
Martin-Éric Racine
http://q-funk.iki.fi

[Marco Rodrigues (gothicx)]

Hmm.. I didn't find gda3-postgres, we can recommend libgda3-postgres ? it's the name of it...

[Marco Rodrigues (gothicx)]

Build log: http://launchpadlibrarian.net/11395051/buildlog_ubuntu-hardy-i386.planner_0.14.2-4%7Eppa2_FULLYBUILT.txt.gz

[Martin-Éric Racine (q-funk)]

If Daniel can confirm that your patch not only builds cleanly, but also produces a usable SQL support in Planner, we'll merge it straight into the Debian package and eliminate the delta between the Debian and Ubuntu package.

[Marco Rodrigues (gothicx)]

It builds clean now as you can see in PPA build log, it needs some testing with libgda3-postgres to see if SQL works fine.

[Marco Rodrigues (gothicx)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - the Hardy Heron. It won't be fixed in previous versions of Ubuntu because the bug doesn't fit requirements for backporting. See [WWW] https://help.ubuntu.com/community/UbuntuBackports for more information.

[Marco Rodrigues (gothicx)]

Ups.. wrong bug report. I'm sorry... doing ubuntu hug day :-(

[Daniel Holbach (dholbach)]

I don't have the setup to test it. I'd prefer if somebody else tested this.

[Martin-Éric Racine (q-funk)]

checking for GDA... configure: error: Package requirements (libgda >= 1.0) were not met:

No package 'libgda' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GDA_CFLAGS
and GDA_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

make: *** [config.status] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
pbuilder: Failed autobuilding of package
### executing tmp/hooks/C10shell ###

[Martin-Éric Racine (q-funk)]

I got the above when building with pbuilder, even after "autoreconf -v --install" was run. So, the answer is, as Daniel had already pointed out ages ago, that the upstream code needs to be ported to libgda3; updating the build-depends is not enough.

[Martin-Éric Racine (q-funk)]

dnl -----------
dnl | Database/GDA check |----------------------------------------------
dnl -----------
AC_ARG_ENABLE(database, [ --enable-database=[no/yes] enable database support [default=no]], enable_database="$enableval", enable_dat$

if test "x$enable_database" = "xyes" ; then
    PKG_CHECK_MODULES(GDA, libgda >= 1.0)
    use_gda=yes
else
    use_gda=no
fi

AM_CONDITIONAL(HAVE_GDA, test x$use_gda = xyes)

if test "x$enable_database" = "xyes" ; then
    PKG_CHECK_MODULES(GDA, libgda-2.0 >= 1.0)
    have_gda2=yes
else
    have_gda2=no
fi

AM_CONDITIONAL(HAVE_GDA2, test x$have_gda2 = xyes)
dnl -----------------------------------------------------------

[Martin-Éric Racine (q-funk)]

The above configure.in segment is where this starts. I'm suspecting that other parts of the code need to be modified too.

[Oliver Grawert (ogra)]

http://lists.opensuse.org/opensuse-commit/2007-10/msg00674.html
has the suse patch ....

- PKG_CHECK_MODULES(GDA, libgda-2.0 >= 1.0)
+ PKG_CHECK_MODULES(GDA, libgda-3.0 >= 1.0)

seems to be what they do ...

[Martin-Éric Racine (q-funk)]

That could work, but it removes the check for libgda-2.0, which is not a good approach. We would instead need to ADD a check for libgda-3.0.

[Daniel Holbach (dholbach)]

Setting to incomplete for now.

[Martin-Éric Racine (q-funk)]

Upstream sent me the following:

*****
I finished my libgda3 patch. At 81K it's a rather big one:
http://www.kfk4ever.com/~griffon26/shared/planner-libgda3-fixes.patch

To summarize the changes:

- configure.in and two Makefile.am's were modified to detect the libgda
 version and pass -DGDA_VERSION=NN to the compiler

- previously all sql commands were done through a single function, but
 that is now split up into one for single queries returning data and
 one for possibly multiple commands, returning only success/failure

- return value checking is now done consistently (I think we leaked some
 GdaDataModels here and there before)

- After moving some code back and forth, the sql helper functions at the
 top of mrp-sql.c and planner-sql-plugin.c are now identical (as they
 should be). I didn't feel it would add much to move them into a
 separate shared file, unless there's already such a shared file that
 I'm not aware of (?).

I invite anyone to give this patch some testing. It's all about database
access, so you'll have to pass --enable-database=yes to configure when
building.

If nobody objects, I plan to check in this patch in a week or so.

Maurice.
*****

As seen above, the patch is actually fairly intrusive. I am thus wondering whether we should dare release it for Hardy. On the plus side, we'd regain database support for the next two years, meaning that those who upgrade from the last LTS would not loose database support. On the minus side, this patch could use proper peer review before it's merged.

[Martin-Éric Racine (q-funk)]

Planner 0.14.3-1 which just entered Debian/unstable fixes this issue.

We're a few days too late for inclusion into Hardy, but I still thought I'd notify those concerned by this bug.

[Martin-Éric Racine (q-funk)]

Marking as Fix Committed, since this is already in Debian.

[Luca Falavigna (dktrkranz)]

Intrepid has 0.14.3-2ubuntu1.