Hi,
On 1/21/20 5:51 AM, Sebastiaan Couwenberg wrote:
On 1/20/20 5:38 AM, Sebastiaan Couwenberg wrote:
Looks like britney needs some help to migrate everything to testing. The
update_output.txt shows most rdeps, I can't make sense of why it's not
migrating them.
Paul asked me to look at this.
On 1/20/20 5:38 AM, Sebastiaan Couwenberg wrote:
> Looks like britney needs some help to migrate everything to testing. The
> update_output.txt shows most rdeps, I can't make sense of why it's not
> migrating them.
DDPO shows 3.0.3+dfsg-1 in testing-proposed-updates, is that intended?
Kind
Looks like britney needs some help to migrate everything to testing. The
update_output.txt shows most rdeps, I can't make sense of why it's not
migrating them.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Hi Sebastiaan,
On 12-01-2020 08:18, Sebastiaan Couwenberg wrote:
>> Probably I am saying something stupid, but e.g. gdal-data () breaks
>> libgdal* . I notice that the library already has a larger than
>> relation on gdal-data, but apparently there should have been a smaller
>> than relation as
On 1/11/20 9:48 PM, Paul Gevers wrote:
> gdal triggers autopkgtest regressions in two packages and looking at the
> logs I am wondering if that point to a missing dependency relation, as
> the tests pass in unstable once they were binNMU'ed.
>
> In both tests, libgdal20 from testing is installed
Hi,
On 11-01-2020 17:38, Sebastiaan Couwenberg wrote:
> On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
>> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>>
>>> Please schedule the binNMUs.
>>
>> Thanks for
On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>
>> Please schedule the binNMUs.
>
> Thanks for scheduling the initial batch, everything has built now.
> Please
On 1/10/20 11:06 PM, Sebastiaan Couwenberg wrote:
> On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
>> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>>
>>> Please schedule the binNMUs.
>>
>> Thanks for scheduling the
On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>
>> Please schedule the binNMUs.
>
> Thanks for scheduling the initial batch, everything has built now.
> Please
On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>
> Please schedule the binNMUs.
Thanks for scheduling the initial batch, everything has built now.
Please schedule the rest of Dependency level 1.
Kind Regards,
Bas
--
On 1/8/20 5:48 AM, Sebastiaan Couwenberg wrote:
> On 1/8/20 5:31 AM, Sebastiaan Couwenberg wrote:
>> On 1/7/20 10:21 PM, Paul Gevers wrote:
>>> I hinted libvigraimpex just now, once it migrates, please go ahead.
>>
>> Today GDAL 3.0.3RC1 will be released, it's probably a good idea to wait
>> for
On 1/8/20 5:31 AM, Sebastiaan Couwenberg wrote:
> On 1/7/20 10:21 PM, Paul Gevers wrote:
>> I hinted libvigraimpex just now, once it migrates, please go ahead.
>
> Today GDAL 3.0.3RC1 will be released, it's probably a good idea to wait
> for its final release, likely a week later.
On second
On 1/7/20 10:21 PM, Paul Gevers wrote:
> On 24-11-2019 08:44, Sebastiaan Couwenberg wrote:
>> Let's see what happens first: this, or the QGIS 3.10.4 release which
>> makes use of GDAL 3 features.
>
> So, did the release of QGIS 3.10.4 or higher already happened?
No, it's scheduled for February
Processing control commands:
> tags -1 confirmed
Bug #939989 [release.debian.org] transition: gdal
Added tag(s) confirmed.
--
939989: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939989
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 confirmed
Hi Sebastiaan,
On 24-11-2019 08:44, Sebastiaan Couwenberg wrote:
>> Once both networkx packages have migrated to testing we're good to go
>> with the gdal transition.
This happened yesterday.
> Let's see what happens first: this, or the QGIS 3.10.4 release which
>
On 11/23/19 10:15 PM, Paul Gevers wrote:
> On 08-11-2019 06:43, Sebastiaan Couwenberg wrote:
>> python-networkx is finally fixed, please remove the block to let gdal
>> migrate to testing, and let's move on with this transition.
>
> python-networkx doesn't want to migrate, probably due to
Hi
On 08-11-2019 06:43, Sebastiaan Couwenberg wrote:
> python-networkx is finally fixed, please remove the block to let gdal
> migrate to testing, and let's move on with this transition.
python-networkx doesn't want to migrate, probably due to networkx not
migrating. That in turn may (or may
python-networkx is finally fixed, please remove the block to let gdal
migrate to testing, and let's move on with this transition.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
signature.asc
Description: OpenPGP
Hello Emilio,
On Wed, Oct 2, 2019 at 4:57 AM Emilio Pozuelo Monfort wrote:
> As it's been said, we need to disentangle the gdal library transition from the
> python2 removal. So either python2 support gets added back to 3.0.1 so that we
> can transition to that without the new lib getting stuck
On 01/10/2019 19:23, Sebastiaan Couwenberg wrote:
> And for the record, the next upload of gdal to unstable which will
> likely be of the 2.4 series will also drop the Python 2 support, so not
> providing python-gdal won't be an argument to block this transition.
As it's been said, we need to
Hi Sebastiaan,
On 01-10-2019 21:15, Sebastiaan Couwenberg wrote:
> On 10/1/19 8:15 PM, Paul Gevers wrote:
>> Please stop. We don't need the python2 removal that urgent that we need
>> to break stuff. And yes, breaking piuparts is a NOGO in my opinion.
>
> piuparts is unrelated to python-gdal,
On 10/1/19 8:15 PM, Paul Gevers wrote:
> Please stop. We don't need the python2 removal that urgent that we need
> to break stuff. And yes, breaking piuparts is a NOGO in my opinion.
piuparts is unrelated to python-gdal, and hence not relevant to the gdal
transition.
Important packages like
Hi Sebastiaan,
Please stop. We don't need the python2 removal that urgent that we need
to break stuff. And yes, breaking piuparts is a NOGO in my opinion. As
is breaking all kind of other stuff while you know you break it. Give it
time, please. We may even ship python2 in bullseye if we need to.
On 10/1/19 6:26 PM, Sandro Tosi wrote:
>> On Tue, Oct 01, 2019 at 05:42:56PM +0200, Sebastiaan Couwenberg wrote:
>>> We shouldn't block removal of Python 2 support on badly and unmaintained
>>> packages.
>
> you can make your case to debian-python@ , but calling networkx or any
> of its rdeps
> On Tue, Oct 01, 2019 at 05:42:56PM +0200, Sebastiaan Couwenberg wrote:
> > We shouldn't block removal of Python 2 support on badly and unmaintained
> > packages.
you can make your case to debian-python@ , but calling networkx or any
of its rdeps "badly and unmaintained packages" it's borderline
On Tue, Oct 01, 2019 at 05:42:56PM +0200, Sebastiaan Couwenberg wrote:
> We shouldn't block removal of Python 2 support on badly and unmaintained
> packages.
we should. as some people didnt respect this, piuparts is now broken in
testing.
i do however agree, that it doesnt make much sense to
On 9/17/19 2:41 PM, Sandro Tosi wrote:
> While it's true we are trying to remove python 2 from Debian
> (https://wiki.debian.org/Python/2Removal), this shouldnt be done while
> reverse dependencies are still present in the archive (quoting from
> the previous link "NOTE: If there are reverse
Hello Release Team,
On Tue, Sep 10, 2019 at 3:54 PM Bas Couwenberg wrote:
> For the Debian GIS team I'd like to transition to GDAL 3.x. This is the
> next step in the major update of the GIS stack after PROJ 6.
>
> All reverse dependencies rebuilt successfully with GDAL 3.0.1 from
> experimental
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 939872 939891 931944
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html
For the Debian GIS team I'd like to transition to GDAL 3.x.
29 matches
Mail list logo
