Sebastian Ramacher a écrit le 16/06/2021 à 17:22 :
Thanks for uploading the fix!
Unfortunately, the changes to the S3 virtual file driver caused
regressions in hdf5's reverse dependencies (some of them are caused by
missing dependencies for -lcrypto and -lcurl). See
Hi
On 2021-06-14 20:21:05, Gilles Filippini wrote:
> Hi Andreas,
>
> Andreas Beckmann a écrit le 14/06/2021 à 10:18 :
> > On 08/06/2021 13.05, Sebastian Ramacher wrote:
> > > > Here it is. Now testing upgrades ...
> > > > There were some new symbols ... but they appeared independently of my
> >
Hi Andreas,
Andreas Beckmann a écrit le 14/06/2021 à 10:18 :
On 08/06/2021 13.05, Sebastian Ramacher wrote:
Here it is. Now testing upgrades ...
There were some new symbols ... but they appeared independently of my
changes (I built in bullseye, not sid, in case it does matter).
Tests have
On 08/06/2021 13.05, Sebastian Ramacher wrote:
Here it is. Now testing upgrades ...
There were some new symbols ... but they appeared independently of my
changes (I built in bullseye, not sid, in case it does matter).
Tests have not shown any problems. And in combination with patched gdal
and
On 2021-06-08 11:57:13, Andreas Beckmann wrote:
> On 08/06/2021 08.27, Andreas Beckmann wrote:
> > Or, wait, easier: we can reintroduce metapackages libhdf5*-103 depending
> > on libhdf5*-103-1 and all the other packages containing libraries that
> > were in the merged package in buster.
>
> > I
On 6/8/21 12:42 PM, Gilles Filippini wrote:
> But the actual bug will still need to be addressed: postgis requires
> previous runtime to be able to migrate data.
That's an upstream issue, which they don't take very seriously. Some
upstream developers don't like the status quo either, hence the
Andreas Beckmann a écrit le 08/06/2021 à 11:57 :
On 08/06/2021 08.27, Andreas Beckmann wrote:
Or, wait, easier: we can reintroduce metapackages libhdf5*-103
depending on libhdf5*-103-1 and all the other packages containing
libraries that were in the merged package in buster.
I actually like
On 08/06/2021 08.27, Andreas Beckmann wrote:
Or, wait, easier: we can reintroduce metapackages libhdf5*-103 depending
on libhdf5*-103-1 and all the other packages containing libraries that
were in the merged package in buster.
I actually like that solution and will try to come up with a
Control: reassign -1 postgresql-13-postgis-3
Andreas Beckmann a écrit le 08/06/2021 à 08:27 :
An alternative solution would be to rename libhdf5*-103-1 back to
libhdf5*-103 and add dependencies on the split out libraries (s.t. e.g.
dependencies of a buster package depending on libhdf5-103 for
On 08/06/2021 08.27, Andreas Beckmann wrote:
A small problem are the fortran libraries that had their SOVERSION
bumped from 100 to 102,
That is luckily no problem at all since I couldn't find any occurrence
of them being used by Debian packages ;-)
That would have to be carefully checked for
On 07/06/2021 22.04, Gilles Filippini wrote:
I'm not in favor of that. I can't understand why we'd need to bump the
HDF5 C library's SONAME for no reason but postgis wants an old runtime
to properly run a migration. That's awkward.
An alternative solution would be to rename libhdf5*-103-1
Hi,
On Wed, 2 Jun 2021 22:22:04 +0200 Sebastian Ramacher
wrote:
Hi Gilles, hi Andreas,
On 2021-06-01 14:15:52 +0200, Andreas Beckmann wrote:
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder wrote:
> > One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> > Breaks: libgdal20
Hi Andreas
On 2021-06-03 01:41:37 +0200, Andreas Beckmann wrote:
> On 02/06/2021 22.22, Sebastian Ramacher wrote:
> > So, what if we use the free versions between 103 and 200 to transition
> > to a Debian-specific version? Attached is a patch that does that. It's
> > not an optimal solution as we
On 03/06/2021 01.41, Andreas Beckmann wrote:
BUT: This would still only solve the co-installability mess of hdf5,
the gdal problem is still there.
gdal could rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from
On 02/06/2021 22.22, Sebastian Ramacher wrote:
So, what if we use the free versions between 103 and 200 to transition
to a Debian-specific version? Attached is a patch that does that. It's
not an optimal solution as we would have a release with a
Debian-specific SOVERSIONs. For good reason, we
Hi Gilles, hi Andreas,
On 2021-06-01 14:15:52 +0200, Andreas Beckmann wrote:
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder wrote:
> > One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> > Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> > and
On Tue, Jun 01, 2021 at 02:15:52PM +0200, Andreas Beckmann wrote:
> What would be needed to reintroduce postgresql-11-postgis-2.5 (i.e.
> src:postgis-2.5) (built against bullseye libraries) into bullseye? Probably
> libraries and -dev packages from postgresql-11, too.
> Here I assume that
On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder wrote:
One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
and postgresql-11-postgis-2.5 depends on that. libgdal28 depends on
gdal-data (>=3.2.1+dfsg-1). To me
On Tue, May 18, 2021 at 06:47:38PM +0200, Christoph Berg wrote:
> Can you share the apt command and output that led to this removal?
One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
and postgresql-11-postgis-2.5
Control: reassign -1 hdf5 1.10.5+repack-1~exp6
On Tue, May 18, 2021 at 07:48:08PM +0200, Dennis Filder wrote:
> X-Debbugs-CC: d.fil...@web.de
>
> On Tue, May 18, 2021 at 06:47:38PM +0200, Christoph Berg wrote:
>
> > Can you share the apt command and output that led to this removal?
>
> I
X-Debbugs-CC: d.fil...@web.de
On Tue, May 18, 2021 at 06:47:38PM +0200, Christoph Berg wrote:
> Can you share the apt command and output that led to this removal?
I attached the output from "apt full-upgrade" until the "Do you want
to continue?"
Having gimp-gmic (recommended by
Re: Dennis Filder
> During an upgrade from Buster to Bullseye I also had to upgrade a
> cluster from postgresql 11 to 13. The cluster had the postgis
> extension enabled (postgis 2.5.1) and one table with columns of types
> from postgis. My typescript tells me that during "apt full-upgrade"
>
Package: postgresql-common
Architecture: amd64
Version: 225
Severity: serious
Justification: Potential data loss (lower at your discretion)
Tags: bullseye
X-Debbugs-CC: d.fil...@web.de
During an upgrade from Buster to Bullseye I also had to upgrade a
cluster from postgresql 11 to 13. The cluster
23 matches
Mail list logo
