Bug#939989: transition: gdal
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. It seems the openscenegraph binNMU picked up a dependency on the newer coin3, which can't migrate (it needs the new libglvnd, which seems to break a number of packages, I didn't investigate why). DDPO shows 3.0.3+dfsg-1 in testing-proposed-updates, is that intended? Yes. I copied gdal to t-p-u to do a rebuild of openscenegraph there, in the hope that that one would be able to migrate. Cheers, Ivo
Bug#939989: transition: gdal
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 Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#939989: transition: gdal
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
Bug#939989: transition: gdal
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 well. (As we can't fix the package in testing, I
>> proposed the breaks).
>>
>> Can you please share your view of this problem?
>
> This kind of inter-package dependency should use "(= ${source:Version})"
> like done between arch:any packages with "(= ${binary:Version})", but
> using the exact source version between arch:any and arch:all packages
> breaks arch:all binNMUs, so >= is used instead.
But that has the risk that partial upgrades get it wrong.
> I don't think the gdal source should be changed just to accommodate debci.
Nit-picking: debci has nothing to do with it, it's autopkgtest, apt and
britney that rule here. One of the things that that combination has
revealed often is missing versioned dependencies, those that could cause
issues on partial upgrades or partial migrations). Hence, we're happy
that those are caught. Obviously britney should get smarter in
scheduling tests for binNMU'ed packages from unstable, but most of the
times during transitions apt as run by autopkgtest will pull those in
anyways when failing autopkgtests are retried after binNMU's happen.
However, in this case because the package dependencies don't declare the
proper relation, britney doesn't pull in the binNMU'ed version and it
*discovers* a relation that's broken.
I don't think you should fix it to accommodate QA, I think you should
fix it to avoid issues with partial upgrades.
Paul
signature.asc
Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 (due to the package
> in testing not being build against the new library) but the new
> gdal-data package is installed. Both tests show:
> ERROR: GDAL OpenFailed [4] Unable to open EPSG support file gcs.csv.
> Try setting the GDAL_DATA environment variable to point to the directory
> containing EPSG csv files.
I saw that, and it shouldn't pull in only gdal-data from unstable. That
seems like an issue in autopkgtest.
> Is this something that needs fixing in the gdal package somehow?
I don't think so.
> 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 well. (As we can't fix the package in testing, I
> proposed the breaks).
>
> Can you please share your view of this problem?
This kind of inter-package dependency should use "(= ${source:Version})"
like done between arch:any packages with "(= ${binary:Version})", but
using the exact source version between arch:any and arch:all packages
breaks arch:all binNMUs, so >= is used instead.
I don't think the gdal source should be changed just to accommodate debci.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
signature.asc
Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 scheduling the initial batch, everything has built now. >> Please schedule the rest of Dependency level 1. > > Now that openscenegraph is built & installed everywhere, please schedule > osgearth. 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 (due to the package in testing not being build against the new library) but the new gdal-data package is installed. Both tests show: ERROR: GDAL OpenFailed [4] Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files. Is this something that needs fixing in the gdal package somehow? 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 well. (As we can't fix the package in testing, I proposed the breaks). Can you please share your view of this problem? Paul signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 schedule the rest of Dependency level 1. Now that openscenegraph is built & installed everywhere, please schedule osgearth. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 initial batch, everything has built now. >> Please schedule the rest of Dependency level 1. > > Now that pdal is built everywhere, please schedule grass & paraview. grass is built & installed everywhere too, please schedule libgdal-grass & qgis. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 schedule the rest of Dependency level 1. Now that pdal is built everywhere, please schedule grass & paraview. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 its final release, likely a week later. > > On second thought, let's start this now and have room in experimental > for 3.0.3~rc1. gdal (3.0.2+dfsg-1) is now built & installed on all release architectures. Please schedule the binNMUs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 thought, let's start this now and have room in experimental for 3.0.3~rc1. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 21st. > 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. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 > makes use of GDAL 3 features. So, did the release of QGIS 3.10.4 or higher already happened? I hinted libvigraimpex just now, once it migrates, please go ahead. Paul signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 networkx not > migrating. That in turn may (or may not) be due to the python 3.8 > transition that is currently ongoing. Looks like the update to 2.4 broke some of the networkx rdeps, bugs filed: #945390: androguard: autopkgtest failures #945392: hyperkitty: autopkgtest failures #945393: skimage: autopkgtest failures These three all have exceptions like: AttributeError: '' object has no attribute 'node' There is also a python3.8 issue: #945389: skimage: FTBFS with python3.8 (test failures) > Once both networkx packages have migrated to testing we're good to go > with the gdal transition. Let's see what happens first: this, or the QGIS 3.10.4 release which makes use of GDAL 3 features. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 not) be due to the python 3.8 transition that is currently ongoing. Once both networkx packages have migrated to testing we're good to go with the gdal transition. Paul signature.asc Description: OpenPGP digital signature
Bug#939989: transition: gdal
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 in sid, or the > removal > happens before the library transition and we wait for the py2-free gdal to > transition to testing before going ahead with gdal 3.0.1. Which given the > amount > of rdeps, it seems like that could take a while and block other transitions > that > will need gdal to get rebuilt and migrated to testing, so please don't do that > until the rdeps are ready. in case you are not aware, it was announced that even the package currently in unstable (so unrelated to the GDAL transition) will get its python2 package dropped: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932679#44 -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#939989: transition: gdal
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 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 in sid, or the removal happens before the library transition and we wait for the py2-free gdal to transition to testing before going ahead with gdal 3.0.1. Which given the amount of rdeps, it seems like that could take a while and block other transitions that will need gdal to get rebuilt and migrated to testing, so please don't do that until the rdeps are ready. Cheers, Emilio
Bug#939989: transition: gdal
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 dependencies, you cannot > remove it yet!"). We shouldn't block removal of Python 2 support on badly and unmaintained packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#939989: transition: gdal
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 as summarized below, except fiona, mysql-workbench & vtk7. > > The fiona issue is actually related to GDAL 3, mysql-workbench FTBFS due > to gcc-9 & -Werror, and vtk7 hasn't been updated for PROJ 6 yet. > > libgdal-grass doesn't need a binNMU as the 3.0.1 version will be > uploaded to unstable instead. please be aware this transition also includes dropping python-gdal from the gdal source package. In unstable, that would currently break: ``` Checking reverse dependencies... # Broken Depends: qgis: python3-qgis-common # Broken Build-Depends: python-networkx: python-gdal Dependency problem found. ``` 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 dependencies, you cannot remove it yet!"). Bas was made aware of the impossible situation of removing python-networkx (exactly due to its rdeps) in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932679#32 but that didnt change his mind. Dropping python-networkx would mean breaking ``` Checking reverse dependencies... # Broken Depends: cfflib: python-cfflib falcon: falcon [amd64 arm64 mips64el ppc64el s390x] hinge: hinge [amd64 arm64 mips64el ppc64el] nipype: python-nipype pbsuite: pbhoney pbjelly python-pbbanana pdb2pqr: pdb2pqr python-prov: python-prov ragout: ragout sagemath: sagemath [arm64 armhf i386 ppc64el] # Broken Build-Depends: cfflib: python-networkx falcon: python-networkx (>= 1.7) hinge: python-networkx nipype: python-networkx (>= 1.3) nitime: python-networkx ragout: python-networkx (>= 2.2) rdflib: python-networkx Dependency problem found. ``` (and all their transitive rdeps). That seems quite a lot, and I'm not ready to drop a package knowing others are still depending on it. Please consider this when scheduling the gdal transition Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#939989: transition: gdal
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. 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 as summarized below, except fiona, mysql-workbench & vtk7. The fiona issue is actually related to GDAL 3, mysql-workbench FTBFS due to gcc-9 & -Werror, and vtk7 hasn't been updated for PROJ 6 yet. libgdal-grass doesn't need a binNMU as the 3.0.1 version will be uploaded to unstable instead. Transition: gdal libgdal20 (2.4.2+dfsg-1+b2) -> libgdal26 (3.0.1+dfsg-1~exp3) The status of the most recent rebuilds is as follows. dans-gdal-scripts (0.24-3) OK fiona (1.8.6-2)FTBFS (#939872) gazebo (9.6.0-2)OK gmt (5.4.5+dfsg-2) OK libcitygml (2.0.9-2)OK libosmium (2.15.2-1) OK mapcache(1.8.0-1)OK mapnik (3.0.22+ds1-1) OK mapproxy(1.12.0-1) OK mapserver (7.4.1-1)OK mysql-workbench (8.0.17+dfsg-1) FTBFS (#939891) ncl (6.6.2-1)OK node-srs(0.4.8+dfsg-4) OK octave-mapping (1.2.1-4)OK openorienteering-mapper (0.8.4-2)OK openscenegraph (3.2.3+dfsg1-3) OK pdal(2.0.1+ds-1) OK pgsql-ogr-fdw (1.0.8-1)OK pktools (2.6.7.6+ds-2) OK postgis (2.5.3+dfsg-1) OK pprepair(0.0~20170614-dd91a21-3) OK prepair (0.7.1-3)OK python-django (2:2.2.5-1) OK qmapshack (1.13.1-1) OK r-cran-mi (1.0-7) OK r-cran-rgdal(1.4-4-1)OK r-cran-sf (0.7-7+dfsg-1) OK r-cran-tmvtnorm (1.4-10-3) OK rasterio(1.0.28-1) OK sumo(1.1.0+dfsg1-1) OK vtk6(6.3.0+dfsg2-3) OK vtk7(7.1.1+dfsg1-12) FTBFS (#931944) cloudcompare(2.10.3-3) OK grass (7.8.0-1)OK opencv (3.2.0+dfsg-6) OK openscenegraph-3.4 (3.4.1+dfsg1-5) OK osmcoastline(2.2.4-1)OK pyosmium(2.15.3-1) OK libgdal-grass (2.4.2-3 / 3.0.1-1~exp3) FTBFS / OK osgearth(2.10.2+dfsg-1) OK otb (6.6.1+dfsg-3) OK qgis(3.4.11+dfsg-2) OK saga(7.3.0+dfsg-1) OK Kind Regards, Bas
