On 2021-06-18 17:42:44 +0200, Sebastiaan Couwenberg wrote:
> On 6/18/21 5:19 PM, Andreas Beckmann wrote:
> > On 18/06/2021 09.50, Sebastiaan Couwenberg wrote:
> >> I'm increasingly in favor of removing the Breaks from gdal-data, the
> >> attached procedure works for me in buster chroot.
> >
> >>
On 6/18/21 5:19 PM, Andreas Beckmann wrote:
> On 18/06/2021 09.50, Sebastiaan Couwenberg wrote:
>> I'm increasingly in favor of removing the Breaks from gdal-data, the
>> attached procedure works for me in buster chroot.
>
>> There is much less need for gdal-data breaking libgdal20 for us than
>>
On 18/06/2021 09.50, Sebastiaan Couwenberg wrote:
I'm increasingly in favor of removing the Breaks from gdal-data, the
attached procedure works for me in buster chroot.
There is much less need for gdal-data breaking libgdal20 for us than
there is in the UbuntuGIS PPA use case. I'm not aware
Re: Sebastiaan Couwenberg
> Since the upgrade procedure documented in the release notes includes
> purging removed and obsolete packages, users are not expected to keep
> libgda20 around after the distribution upgrade.
To avoid exactly this problem, postgresql-common is maintaining a list
of PG
Re: Andreas Beckmann
> > modulo the problem I ran into. (I still have to retry it.)
>
> Didn't see this on my side.
> Your --force-depends probably affected more than just libgdal20.
Found the problem, I had not restarted postgresql-11 after the
upgrade, so it was still linked against the old
On 6/15/21 8:23 AM, Andreas Beckmann wrote:
> On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
>> From the many other packages I haven't seen other issues other than the
>> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
>>
>> I really need more concrete cases to justify
On 6/14/21 1:49 PM, Sebastiaan Couwenberg wrote:
> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
>>> What actual problems do are solved by making them co-installable?
>>>
>>> So far the only actualy problem that has been identified is the need for
On 17/06/2021 15.26, Christoph Berg wrote:
Re: Andreas Beckmann
* how do I get some tables using the postgis extension into the database to
sudo -u postgres psql -vON_ERROR_STOP=1 <
Thanks!
Once gdal is fixed,
I used my patched packages (will try to put them somewhere public tonight)
Re: Andreas Beckmann
> So packaging wise this looks good. But I have no idea about the postgresql
> side:
> * how do I get some tables using the postgis extension into the database to
> start with? Is there a package in buster that "does that for me" by just
> installing it (postgis with
OK, I tried it as well.
buster# apt-get install postgresql-11-postgis-2.5
# in a minimal chroot, pulls in postgresql-11
# I haven't done anything with postgres, so it should be essentially
empty (so only default users, tables, data exist (if any))
buster# apt-get dist-upgrade
# to bullseye
Re: Adrian Bunk
> > FEHLER: XX000: konnte Bibliothek
> > »/usr/lib/postgresql/11/lib/postgis-2.5.so« nicht laden:
> > /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required
> > by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)
> >
> > So there seems to be some additional
On Wed, Jun 16, 2021 at 06:15:45PM +0200, Christoph Berg wrote:
>...
> $ psql cb
> psql (13.3 (Debian 13.3-1), Server 11.12 (Debian 11.12-0+deb10u1))
>
> 17:38 cbe@cb =# select geom from country where geom is not null limit 1;
> FEHLER: XX000: konnte Bibliothek
Re: Sebastiaan Couwenberg
> Options for a working postgis database after distribution upgrade
> include recreating the databases by running your ETL process on the new
> cluster after upgrade, or using symlink hacks to workaround the
> version-in-extension-filename issue:
>
>
On 6/15/21 3:55 PM, Sebastian Ramacher wrote:
> On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote:
>> On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
>>> If neither you as maintainer nor upstream care about upgrade without
>>> data loss, I don't think postgis is suitable to be included in a stable
On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote:
> On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
> > If neither you as maintainer nor upstream care about upgrade without
> > data loss, I don't think postgis is suitable to be included in a stable
> > release. Best option moving forward is to
On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
> If neither you as maintainer nor upstream care about upgrade without
> data loss, I don't think postgis is suitable to be included in a stable
> release. Best option moving forward is to get postgis and its reverse
> dependencies removed from
On 2021-06-15 06:05:28, Sebastiaan Couwenberg wrote:
> On 6/14/21 9:55 PM, Sebastian Ramacher wrote:
> > On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> >>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
> What actual problems
On 6/15/21 8:23 AM, Andreas Beckmann wrote:
> On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
>> From the many other packages I haven't seen other issues other than the
>> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
>>
>> I really need more concrete cases to justify
On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
From the many other packages I haven't seen other issues other than the
partial upgrade with monteverdi which is fixed with Breaks/Replaces.
I really need more concrete cases to justify changes to gdal that I
don't like but will have to
On 6/14/21 9:55 PM, Sebastian Ramacher wrote:
> On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
>> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
>>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
What actual problems do are solved by making them co-installable?
So far
On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> > On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
> >> What actual problems do are solved by making them co-installable?
> >>
> >> So far the only actualy problem that has been identified
On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
>> What actual problems do are solved by making them co-installable?
>>
>> So far the only actualy problem that has been identified is the need for
>> `apt full-upgrade` twice when the Breaks/Replaces
On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
What actual problems do are solved by making them co-installable?
So far the only actualy problem that has been identified is the need for
`apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
present.
apt currently fails to
On 6/14/21 9:29 AM, Andreas Beckmann wrote:
> On 13/06/2021 23.44, Sebastian Ramacher wrote:
>> On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote:
>>> On 13/06/2021 22.44, Sebastian Ramacher wrote:
My goal is to make libgdal20 and libgdal28 co-installable. Adding those
Breaks is not
On 13/06/2021 23.44, Sebastian Ramacher wrote:
On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote:
On 13/06/2021 22.44, Sebastian Ramacher wrote:
My goal is to make libgdal20 and libgdal28 co-installable. Adding those
Breaks is not enough and is step into the wrong direction.
Thanks for
On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote:
> On 13/06/2021 22.44, Sebastian Ramacher wrote:
> > My goal is to make libgdal20 and libgdal28 co-installable. Adding those
> > Breaks is not enough and is step into the wrong direction.
>
> Thanks for making that clear. I'll think again
On 13/06/2021 22.44, Sebastian Ramacher wrote:
My goal is to make libgdal20 and libgdal28 co-installable. Adding those
Breaks is not enough and is step into the wrong direction.
Thanks for making that clear. I'll think again about libogdi ...
@Seb: could you upload the gdal3-data patch to
On 2021-06-13 17:57:46 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 11:32 AM, Sebastian Ramacher wrote:
> > On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> >>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> On 6/12/21
On 6/13/21 11:32 AM, Sebastian Ramacher wrote:
> On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
>> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
>>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> I have unblocked gdal.
On 2021-06-13 11:30:47 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 11:12 AM, Sebastian Ramacher wrote:
> > On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
> >> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> >>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> I have unblocked
On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> > On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> >> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> >>> I have unblocked gdal.
> >>
> >> Thanks, libgdal (3.2.2-1) will need to be
On 6/13/21 11:12 AM, Sebastian Ramacher wrote:
> On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
>>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
I have unblocked gdal.
>>>
>>> Thanks, libgdal (3.2.2-1) will need to be unblocked as
On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
>>> I have unblocked gdal.
>>
>> Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
>
> libgdal-grass ?
Obviously, yes.
>> hand in
On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> > On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> > > I have unblocked gdal.
> >
> > Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
>
> libgdal-grass ?
>
> > hand
On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
I have unblocked gdal.
Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
libgdal-grass ?
hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
version of
On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> I have unblocked gdal.
Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
version of gdal to build successfully.
> Please go ahead with an upload adding a
On 2021-06-11 21:21:09 +0200, Sebastiaan Couwenberg wrote:
> On 6/11/21 8:49 PM, Sebastian Ramacher wrote:
> > On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/9/21 12:11 PM, Andreas Beckmann wrote:
> >>> On 08/06/2021 11.56, Andreas Beckmann wrote:
> gdal can rename
On 6/11/21 8:49 PM, Sebastian Ramacher wrote:
> On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote:
>> On 6/9/21 12:11 PM, Andreas Beckmann wrote:
>>> On 08/06/2021 11.56, Andreas Beckmann wrote:
gdal can rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and
On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote:
> On 6/9/21 12:11 PM, Andreas Beckmann wrote:
> > On 08/06/2021 11.56, Andreas Beckmann wrote:
> >> gdal can rename gdal-data to gdal3-data, build with
> >> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
> >> Thus libgdal20 +
On 6/9/21 12:11 PM, Andreas Beckmann wrote:
> On 08/06/2021 11.56, Andreas Beckmann wrote:
>> gdal can rename gdal-data to gdal3-data, build with
>> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
>> Thus libgdal20 + gdal-data from buster should be co-installable with
>> libgdal28 +
On 08/06/2021 11.56, Andreas Beckmann wrote:
gdal can rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from buster should be co-installable with
libgdal28 + gdal3-data from bullseye and survive the upgrade if
On 08/06/2021 12.22, Sebastiaan Couwenberg wrote:
Please spend your time on other more deserving packages.
I'm not caring that much about postgis but about getting clean upgrade
paths if hdf5 and or gdal are involved because of the (transitive)
non-co-installability of
On 6/8/21 11:56 AM, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
>
> Let's start with the debian-release@ discussion here, this may be turned
> into an unblock request later.
>
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder wrote:
>> One more observation:
Package: release.debian.org
Severity: normal
Let's start with the debian-release@ discussion here, this may be turned
into an unblock request later.
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
44 matches
Mail list logo
