Re: [pkg-firebird-general] Uncoordinated firebird transition (closes: Re: Accepted firebird3.0 3.0.1.32609.ds4-3 (source) into unstable)

2016-10-11 Thread Rene Engelhard
Hi,

On Mon, Oct 10, 2016 at 02:52:46PM +, Damyan Ivanov wrote:
> So my suggestion is to fall back to either of:
> 
>  - disabling firebird support in LO - perhaps bad for users

That's status quo in git now. (for 5.2, 5.3 (so buster) will get it back,
using 3.0)

Looking at popcon, the "Vote" count is sufficiently small enough to "risk" it:
https://qa.debian.org/popcon-graph.php?packages=libreoffice-base vs.
https://qa.debian.org/popcon-graph.php?packages=libreoffice-sdbc-firebird :)

>  - switching to internal copy - more future work backporting security 
>fixes

If you get it to build and work with gcc6 on all archs (or disable non-working
ones, like currently all BE archs)...

I am not eager to do that, and then there's security, yes.
(and I even tried to apt-get -b source firebird2.5, that even FTBFSed here.[1],
which is probably why you wanted to get rid of it ;))

>  - switch to fb3 in LO - incompatibility with upstream/others

That would be a bit more easy, just needs big(ger) patches...

> Do you want me to file a bug against LO so that this isn't forgotten?

Well, I need a (stop-gap) solution soon, given LO will soonish need a rebuild
for the poppler transition and it's unbuildable right now due to this mess.

Regards,

Rene

[1]
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: configure.in: not using Automake
autoreconf: Leaving directory `.'
cp: will not overwrite just-created 'builds/make.new/config/install-sh' with 
'/usr/share/automake-1.15/install-sh'
debian/rules:105: recipe for target 'autogen-stamp' failed
make[1]: *** [autogen-stamp] Error 1
make[1]: Leaving directory '/home/rene/firebird2.5-2.5.6.27020.ds4'
debian/rules:154: recipe for target 'build-super-and-classic-stamp' failed
make: *** [build-super-and-classic-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2




Re: [pkg-firebird-general] Uncoordinated firebird transition (closes: Re: Accepted firebird3.0 3.0.1.32609.ds4-3 (source) into unstable)

2016-10-10 Thread Damyan Ivanov
-=| Rene Engelhard, 07.10.2016 14:53:22 +0200 |=-
> Hi,
> 
> On Fri, Oct 07, 2016 at 12:04:06PM +, Damyan Ivanov wrote:
> > Sorry about that, I needed to be more public about my plans.
> 
> Yeah, that would have been nice. :)
> 
> > Thing is, FB2.5's end of life is planned¹ for 2017, which means more 
> > or less a full Debian release cycle without upstream support. I am 
> > simply not ready to maintain that. Therefore I aimed at dropping 2.5 
> > before the release of stretch.
> 
> OK, understandable.
> 
> > > (And even if it built, one might want to keep whatever upstream uses 
> > > for file format compatibility... Maybe I'll use the internal 
> > > firebird copy or just disable libreoffice-sdbc-firebird then...)
> > 
> > File format compatibility will be a problem whenever LO switches from 
> > fb2.5 to fb3.0. E.g. an user upgrades (jessie->stretch or 
> > stretch->stretch+1) and their databases can't be opened anymore.
> 
> I know. (well, feared). The whole firebird stuff is basically experimental
> anyway, though, so. My comment above was more aimed at our LO vs. upstream LO
> or our LO vs. other distributions' LO (in the same version).

I see.

> > May be I can keep libfbebmed2.5 (plus dependencies) for stretch, 
> > removing only the server/util/fbclient packages. Would that work for 
> > libreoffice.org? I'd still prefer to drop 2.5 entirely, but it helps 
> 
> The problem is firebird-dev.

The idea is to have everything in one or two packages, isolated 
somewhere under /usr/lib/libfbembed2.5 and LO build-depending on 
libfbembed2.5-dev, but...

> > to have a backup plan.
> 
> As said, I could either use the internal copy or simply disable it ;-)

... the more I think about keeping libfbembed2.5 for stretch, the more 
I don't want to do it :) We had releases with two firebird versions 
before, and backporting security fixes was pain. And I am shorter on 
time these days than back then.

So my suggestion is to fall back to either of:

 - disabling firebird support in LO - perhaps bad for users
 - switching to internal copy - more future work backporting security 
   fixes
 - switch to fb3 in LO - incompatibility with upstream/others

Do you want me to file a bug against LO so that this isn't forgotten?


-- Damyan


signature.asc
Description: Digital signature


Re: [pkg-firebird-general] Uncoordinated firebird transition (closes: Re: Accepted firebird3.0 3.0.1.32609.ds4-3 (source) into unstable)

2016-10-07 Thread Rene Engelhard
Hi,

On Fri, Oct 07, 2016 at 12:04:06PM +, Damyan Ivanov wrote:
> Sorry about that, I needed to be more public about my plans.

Yeah, that would have been nice. :)

> Thing is, FB2.5's end of life is planned¹ for 2017, which means more 
> or less a full Debian release cycle without upstream support. I am 
> simply not ready to maintain that. Therefore I aimed at dropping 2.5 
> before the release of stretch.

OK, understandable.

> > (And even if it built, one might want to keep whatever upstream uses 
> > for file format compatibility... Maybe I'll use the internal 
> > firebird copy or just disable libreoffice-sdbc-firebird then...)
> 
> File format compatibility will be a problem whenever LO switches from 
> fb2.5 to fb3.0. E.g. an user upgrades (jessie->stretch or 
> stretch->stretch+1) and their databases can't be opened anymore.

I know. (well, feared). The whole firebird stuff is basically experimental
anyway, though, so. My comment above was more aimed at our LO vs. upstream LO
or our LO vs. other distributions' LO (in the same version).

> May be I can keep libfbebmed2.5 (plus dependencies) for stretch, 
> removing only the server/util/fbclient packages. Would that work for 
> libreoffice.org? I'd still prefer to drop 2.5 entirely, but it helps 

The problem is firebird-dev.

> to have a backup plan.

As said, I could either use the internal copy or simply disable it ;-)

> The embedded access that required linking with libfbembed with 2.5 is 
> now possible with 3.0's libfbclient, which can load the appropriate 
> "engine library" and work without a server. So it seems to me that the 
> changes shouldn't be that severe. (But yes, this should have been 
> coordinated to avoid the bad surprise effect).

Yes, that's what LO did for 5.3.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=e5d48f12faec6027bf79411cb69111d90f4e4129
+
https://cgit.freedesktop.org/libreoffice/core/commit/?id=de899f0b350e51b1932fa4674f7ce2ae386cd1ce
+
https://cgit.freedesktop.org/libreoffice/core/commit/?id=45f42681f4d1260c42140a313560534e605f81a4

(some more, but those are the main ones, afaics)

Regards,

Rene



Re: [pkg-firebird-general] Uncoordinated firebird transition (closes: Re: Accepted firebird3.0 3.0.1.32609.ds4-3 (source) into unstable)

2016-10-07 Thread Damyan Ivanov
-=| Rene Engelhard, 07.10.2016 12:23:29 +0200 |=-
> On Fri, Oct 07, 2016 at 10:05:25AM +, Damyan Ivanov wrote:
> [...]
>  firebird3.0 (3.0.1.32609.ds4-3) unstable; urgency=medium   
> [...]
> >* Upload to unstable
> [...]
> 
> Erm, what? This should have been coordinated. There's libfbclient2.5
> reverse-deps..
> 
> While it doesn't get uninstallable (firebird2.5 exists), firebird-dev now
> points to 3.0, making stuff using 2.5 unbuildable I mean stuff expecting
> libfbembed.. I'd need to backport all the FB3 stuff which went into LO 5.3...

Sorry about that, I needed to be more public about my plans.

Thing is, FB2.5's end of life is planned¹ for 2017, which means more 
or less a full Debian release cycle without upstream support. I am 
simply not ready to maintain that. Therefore I aimed at dropping 2.5 
before the release of stretch.

 ¹ http://www.firebirdsql.org/en/roadmap/
   "Firebird v2.5 series is still maintained, it will be discontinued 
   as soon as Firebird v4.0 is released (circa 2017)."

> (And even if it built, one might want to keep whatever upstream uses 
> for file format compatibility... Maybe I'll use the internal 
> firebird copy or just disable libreoffice-sdbc-firebird then...)

File format compatibility will be a problem whenever LO switches from 
fb2.5 to fb3.0. E.g. an user upgrades (jessie->stretch or 
stretch->stretch+1) and their databases can't be opened anymore.

May be I can keep libfbebmed2.5 (plus dependencies) for stretch, 
removing only the server/util/fbclient packages. Would that work for 
libreoffice.org? I'd still prefer to drop 2.5 entirely, but it helps 
to have a backup plan.

> # grep-dctrl -FDepends libfbembed2.5 
> /var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_binary-amd64_Packages
>  
> -sPackage
> Package: firebird-dev
> Package: firebird2.5-classic
> Package: firebird2.5-classic-common
> Package: firebird2.5-superclassic
> Package: libdbd-firebird-perl
> Package: libreoffice-sdbc-firebird

I am one of the upstream authors of dbd-firebird, so I'll take care of 
it.

I'll take a look at LO next week.

The embedded access that required linking with libfbembed with 2.5 is 
now possible with 3.0's libfbclient, which can load the appropriate 
"engine library" and work without a server. So it seems to me that the 
changes shouldn't be that severe. (But yes, this should have been 
coordinated to avoid the bad surprise effect).


-- Damyan


signature.asc
Description: Digital signature


Uncoordinated firebird transition (closes: Re: Accepted firebird3.0 3.0.1.32609.ds4-3 (source) into unstable)

2016-10-07 Thread Rene Engelhard
Hi,

On Fri, Oct 07, 2016 at 10:05:25AM +, Damyan Ivanov wrote:
[...]
 firebird3.0 (3.0.1.32609.ds4-3) unstable; urgency=medium   
[...]
>* Upload to unstable
[...]

Erm, what? This should have been coordinated. There's libfbclient2.5
reverse-deps..

While it doesn't get uninstallable (firebird2.5 exists), firebird-dev now
points to 3.0, making stuff using 2.5 unbuildable I mean stuff expecting
libfbembed.. I'd need to backport all the FB3 stuff which went into LO 5.3...

(And even if it built, one might want to keep whatever upstream uses for file
format compatibility... Maybe I'll use the internal firebird copy or just
disable libreoffice-sdbc-firebird then...)

Regards,

Rene



Re: Uncoordinated firebird transition (closes: Re: Accepted firebird3.0 3.0.1.32609.ds4-3 (source) into unstable)

2016-10-07 Thread Rene Engelhard
Hi,

On Fri, Oct 07, 2016 at 12:23:29PM +0200, Rene Engelhard wrote:
> Erm, what? This should have been coordinated. There's libfbclient2.5
> reverse-deps..

OK, only two:

# grep-dctrl -FDepends libfbembed2.5 
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_binary-amd64_Packages
 -sPackage
Package: firebird-dev
Package: firebird2.5-classic
Package: firebird2.5-classic-common
Package: firebird2.5-superclassic
Package: libdbd-firebird-perl
Package: libreoffice-sdbc-firebird

Regards,
 
Rene