Sync firebird2.1 2.1.1.17910-release.ds1-1from debian experimental

Sub'ing ubuntu-universe-sponsors, this package is in universe.

While we currently have a stable release in intrepid, Debian experimental has a release candidate. Wouldn't it be better to wait until the stable version is released? Or do you plan to track upstream and make sure that the new final gets into intrepid? What are the reasons why we should update to a new development release at this point?

On Tue, Sep 23, 2008 at 1:29 PM, Martin Pitt <email address hidden> wrote:
> Sub'ing ubuntu-universe-sponsors, this package is in universe.
>
> While we currently have a stable release in intrepid, Debian
> experimental has a release candidate. Wouldn't it be better to wait
> until the stable version is released? Or do you plan to track upstream
> and make sure that the new final gets into intrepid? What are the
> reasons why we should update to a new development release at this point?
The release in debian experimental is the final one ,only Damyan will
need to rename it

http://lists.alioth.debian.org/pipermail/pkg-firebird-general/2008q3/001486.html

>
> ** Changed in: firebird2.1 (Ubuntu)
> Status: New => Incomplete
>
> --
> Sync firebird2.1 2.1.1.17910-RC1.ds1-1 from debian experimental
> https://bugs.launchpad.net/bugs/271919
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
developer flamerobin.org

It’s an recomended update if you are still using firebird 2.1.1

Here are a few of the fixes I consider important for 2.1 production servers and so recommend the update:

    * Stability fixes for the monitoring tables
    * Fixed possible corruption of the users database, security2.fdb.
    * Fixed nBackup, which did not work in version 2.1.
    * Fixed a memory leak on DDL statements.

The complete list of bugs fixed and the downloads are at the Firebird SQL website.

http://firebirdsql.org/devel/doc/rlsnotes/html/bugfix210.html#bug-211

It’s an recomended update if you are still using firebird 2.1.0

sorry for typo

I have also requested Damyan to rename the package because is confusing and to drop RC from the package name

because this is taged as 2.1.1 stable release

and you can see from cvs and download area that 17910 is indeed the Final release
"firebird2.1 2.1.1.17910"

http://firebirdsql.org/index.php?op=files&id=engine_211

http://downloads.sourceforge.net/firebird/Firebird-2.1.1.17910-0.tar.bz2

Damyan Ivanov droped RC from the name and uploaded the same version in debian
So now it should be less confusing

http://lists.alioth.debian.org/pipermail/pkg-firebird-general/2008q4/001502.html

Hi,

Did you try building the package in Intrepid? Did it work?

It fails to build for me, so I'm not going to sponsor yet. Please
check whether you are able to build the package in Intrepid.

Thanks,

James

patching file builds/posix/Makefile.in.extlib
patching file configure.in

Now at patch no-spurious-linkage.patch
touch debian/stamp-patched
NOCONFIGURE=1 sh autogen.sh
AUTOCONF=autoconf
LIBTOOL=libtool
LIBTOOLiZE=libtoolize
Running libtoolize ...
cp: target `aclocal.m4' is not a directory
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `builds/make.new/config'.
libtoolize: copying file `builds/make.new/config/ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize: `/usr/share/aclocal/libtool.m4'
libtoolize: `/usr/share/aclocal/ltoptions.m4'
libtoolize: `/usr/share/aclocal/ltversion.m4'
libtoolize: `/usr/share/aclocal/ltsugar.m4'
libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Running autoheader ...
Running autoconf ...
configure.in:484: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:485: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
configure.in:486: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
make: *** [autogen-stamp] Error 1

On Fri, Oct 3, 2008 at 12:24 PM, James Westby <email address hidden> wrote:
> Hi,
>
> Did you try building the package in Intrepid? Did it work?
>
> It fails to build for me, so I'm not going to sponsor yet. Please
> check whether you are able to build the package in Intrepid.
>
> Thanks,
>
> James
>
>
> patching file builds/posix/Makefile.in.extlib
> patching file configure.in
>
> Now at patch no-spurious-linkage.patch
> touch debian/stamp-patched
> NOCONFIGURE=1 sh autogen.sh
> AUTOCONF=autoconf
> LIBTOOL=libtool
> LIBTOOLiZE=libtoolize
> Running libtoolize ...
> cp: target `aclocal.m4' is not a directory
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `builds/make.new/config'.
> libtoolize: copying file `builds/make.new/config/ltmain.sh'
> libtoolize: You should add the contents of the following files to `aclocal.m4':
> libtoolize: `/usr/share/aclocal/libtool.m4'
> libtoolize: `/usr/share/aclocal/ltoptions.m4'
> libtoolize: `/usr/share/aclocal/ltversion.m4'
> libtoolize: `/usr/share/aclocal/ltsugar.m4'
> libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> Running autoheader ...
> Running autoconf ...
> configure.in:484: error: possibly undefined macro: AC_PROG_LIBTOOL
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
> configure.in:485: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
> configure.in:486: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> make: *** [autogen-stamp] Error 1
>
> --
> Sync firebird2.1 2.1.1.17910-release.ds1-1from debian experimental
> https://bugs.launchpad.net/bugs/271919
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I have only tested the one before firebird2.1_2.1.1.17910-RC1.ds1-1
and even i released it to my ppa and i use it daily , it is rock stable

but that was before the new libtool changes in intrepid (related to
various php extensions building bugs i see around)

so i guess we need to fix this building bug

cp: target `aclocal.m4' is not a directory
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR,
`builds/make.new/config'.
libtoolize: copying file `builds/make.new/config/ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize: `/usr/share/aclocal/libtool.m4'
libtoolize: `/usr/share/aclocal/ltoptions.m4'
libtoolize: `/usr/share/aclocal/ltversion.m4'
libtoolize: `/usr/share/aclocal/ltsugar.m4'
libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Running autoheader ...
Running autoconf ...
configure.in:484: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf do...

On Fri, Oct 3, 2008 at 12:24 PM, James Westby <email address hidden> wrote:
> Hi,
>
> Did you try building the package in Intrepid? Did it work?
>
> It fails to build for me, so I'm not going to sponsor yet. Please
> check whether you are able to build the package in Intrepid.

yes it was ok on debian exp
http://ftp.de.debian.org/debian/pool/main/f/firebird2.1/

I checked intrepid and indeed it doesn't build

>
> Thanks,
>
> James
>
>
> patching file builds/posix/Makefile.in.extlib
> patching file configure.in
>
> Now at patch no-spurious-linkage.patch
> touch debian/stamp-patched
> NOCONFIGURE=1 sh autogen.sh
> AUTOCONF=autoconf
> LIBTOOL=libtool
> LIBTOOLiZE=libtoolize
> Running libtoolize ...
> cp: target `aclocal.m4' is not a directory
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `builds/make.new/config'.
> libtoolize: copying file `builds/make.new/config/ltmain.sh'
> libtoolize: You should add the contents of the following files to `aclocal.m4':
> libtoolize: `/usr/share/aclocal/libtool.m4'
> libtoolize: `/usr/share/aclocal/ltoptions.m4'
> libtoolize: `/usr/share/aclocal/ltversion.m4'
> libtoolize: `/usr/share/aclocal/ltsugar.m4'
> libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> Running autoheader ...
> Running autoconf ...
> configure.in:484: error: possibly undefined macro: AC_PROG_LIBTOOL
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
> configure.in:485: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
> configure.in:486: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> make: *** [autogen-stamp] Error 1
>
> --
> Sync firebird2.1 2.1.1.17910-release.ds1-1from debian experimental
> https://bugs.launchpad.net/bugs/271919
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
developer flamerobin.org

On debian box the build went without problems (experimental one) and it produces the right binaries (debs)

I test now the build for hardy and configure part it works also the compiling

So it must be something only related to intrepid libtool/autoconf changes in intrepid

The only thing modified was g++ requirment is down from 4.3 to 4.2
and in rules i have modified just this

export CC=gcc-4.2
export CXX=g++-4.2
export CPP=cpp-4.2
export CXXPP=cpp-4.2

I will upload today the version for hardy in my ppa repository and fix the intrepid version later

On Fri, 2008-10-03 at 15:55 +0000, Mariuz wrote:
> On debian box the build went without problems (experimental one) and it
> produces the right binaries (debs)
>
> I test now the build for hardy and configure part it works also the
> compiling
>
> So it must be something only related to intrepid libtool/autoconf
> changes in intrepid

Hi,

This is probably due to the fact that we have a new libtool in Intrepid.

autogen.sh does this:

# Generate configure from configure.in
echo "Running libtoolize ..."
LIBTOOL_M4=`$LIBTOOLIZE --copy --force --dry-run|grep 'You should add the contents of'|sed "s,^[^/]*\(/[^']*\).*$,\1,"`
if test "x$LIBTOOL_M4" != "x"; then
 rm -f aclocal.m4
 cp $LIBTOOL_M4 aclocal.m4
fi
$LIBTOOLIZE --copy --force || exit 1

so it expects the libtoolize to tell it from where to retrieve
libtool.m4.

However, the output it gets is

cp: target `aclocal.m4' is not a directory
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `builds/make.new/config'.
libtoolize: copying file `builds/make.new/config/ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize: `/usr/share/aclocal/libtool.m4'
libtoolize: `/usr/share/aclocal/ltoptions.m4'
libtoolize: `/usr/share/aclocal/ltversion.m4'
libtoolize: `/usr/share/aclocal/ltsugar.m4'
libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

so it gets a list of files and tries to do the wrong thing with the
different line that it gets.

I think this indicates a broken assumption about the output of libtool.
I don't know enough to make libtool and autotools do the right thing
without needing this hack though.

Thanks,

James

 git diff autogen.sh
diff --git a/autogen.sh b/autogen.sh
index 744d0ad..7a6ad2e 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -67,11 +67,16 @@ fi

 # Generate configure from configure.in
 echo "Running libtoolize ..."
-LIBTOOL_M4=`$LIBTOOLIZE --copy --force --dry-run|grep 'You should add
the contents of'|sed "s,^[
-if test "x$LIBTOOL_M4" != "x"; then
+#LIBTOOL_M4=`$LIBTOOLIZE --copy --force --dry-run|grep 'You should
add the contents of'|sed "s,^
+#if test "x$LIBTOOL_M4" != "x"; then
 rm -f aclocal.m4
- cp $LIBTOOL_M4 aclocal.m4
-fi
+ #cp $LIBTOOL_M4 aclocal.m4
+cat "/usr/share/aclocal/libtool.m4" >> aclocal.m4
+cat "/usr/share/aclocal/ltsugar.m4" >> aclocal.m4
+cat "/usr/share/aclocal/ltversion.m4" >> aclocal.m4
+cat "/usr/share/aclocal/lt~obsolete.m4" >> aclocal.m4
+cat "/usr/share/aclocal/ltoptions.m4" >> aclocal.m4
+#fi
 $LIBTOOLIZE --copy --force || exit 1

 echo "Running autoheader ..."

also i have added autoreconf

here is the diff
http://launchpadlibrarian.net/19239692/firebird2.1_2.1.1.17910-release.ds1-2ubuntu1_2.1.1.17910-release.ds1-2ubuntu2.diff.gz

package is uploaded to my ppa and you can see the build logs

https://edge.launchpad.net/~mapopa/+archive

Hi,

Could you please discuss this issue with the authors of firebird, as
this will become more of an issue when more people move to the new
libtool.

Thanks,

James

Yes i will send the patch and i know that we need to use the m4 folder from now on

the only thing left to fix was when i tried with the m4 folder
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

but i will send the new libtool fixes to firebird-devel

now i have requested the changes to upstream too

http://www.nabble.com/proposed-libtool-changes-to20304306.html

This bug was fixed in the package firebird2.1 - 2.1.1.17910-release.ds1-1ubuntu1

---------------
firebird2.1 (2.1.1.17910-release.ds1-1ubuntu1) jaunty; urgency=low

  * Sync from Debian experimental. (LP: #271919)
  * Call autoreconf instead of autogen.sh to fix FTBFS. Add automake as a
    Build-Depends. Thanks to Michael Casadevall for the inspiration.

firebird2.1 (2.1.1.17910-release.ds1-1) experimental; urgency=low

  * Final 2.1.1 upstream release. No code changes since rc1
  * update d/watch and d/get-orig-source for the final 2.1.1 release
  * refreshed patches to apply cleanly

  * -dev: make dev. symlinks point to the right file
  * add no-static-linkage.patch disabling static linking to stdc++
    support lib
  * Updated Swedish debconf translation by Martin Bagge
  * use-libedit.patch: link with libedit, not libeditline; accordingly
    change build-dependency to libedit-dev
  * drop unneeded build-dependency on libncurses-dev
  * replace link-as-needed.patch by no-spurious-linkage.patch; -Wl,--as-
    needed may have side-effects. Now no unneeded libraries are given to
    -l
  * firebird2.1-common: Conflict with firebird2.0-common both packages
    install the same manual pages. Closes LP#260823
  * Standards-Version: 3.8.0 (no changes needed)

firebird2.1 (2.1.1.17910-RC1.ds1-1) experimental; urgency=low

  * make_packages.sh: deterine firebird version from build_no.h
  * rules
    + deterine firebird version from build_no.h
    + add -Werror=write-strings to CFLAGS
  * better local-CFLAGS.patch description
  * add deprecated-charp-conversion.patch
  * add cvs-execute-statement-crash.patch fixing memory corruption in
    EXECUTE STATEMENT, possibly crashing the server (upstream tracker
    CORE-1919)
  * -dev: move libfbembed2.1 from Depends to Suggests

  * update get-orig-source for 2.1.1 RC1
  * New upstream release candidate, 2.1.1 RC1
  * adapt debian/copyright for new upstream sources
  * drop cvs-port-arm.patch and cvs-port-ia64.patch; applied upstream

 -- James Westby <email address hidden> Wed, 19 Nov 2008 16:45:27 +0000