[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How is the state of GDAl 2.0 package?

On 2015-10-13 16:36, Amedeo Fadini wrote:
Hi everybody, I'm interested in the Gdal 2.0 package: Paolo told me
that is available in debian experimental repo but I'm not able to find

Experimental has GDAL 1.11.3 packages (available in the experimental branch in git), packaging for GDAL 2.0.1 is currently only available in git (in the experimental-2.0 branch).


I've seen some posts about it in july and september, how is the state
of this package right now? I'm not expert in the packaging process,
but I'd like to contribute.. what should i do?

As mentioned in the previous GDAL threads, we need to test all the reverse dependencies to verify that they still build with GDAL 2.0. Merkaartor was one of the packages that was known not to work with GDAL 2.0, I've recently updated the merkaartor package to resolve this blocker, it's available in unstable since a couple of days.

Another round of rebuilds is required to find out if we can switch to GDAL 2.0.x or need to stick to 1.11.x a little longer and use that time to resolve further issues in reverse dependencies. Rebuilding all these dependencies takes quite some time, and you need to make sure to include the rebuilt packages in the local repository to have those used instead of the packages from the official archive still depending on GDAL 1.11.2 from unstable.

You can find the list of affected packages in my test transition tracker:


If you have a reasonable powerful multi-core machine (because you really need DEB_BUILD_OPTIONS="parallel=<N>" to not wait forever for large packages to build) with a cowbuilder setup using a local repository for the gdal 2.0.1 package and its rebuilt reverse dependencies, you can do a round of rebuilds and report the results. Have a look at the previous transition overview for an example of the status report:


This report needs to be updated to include all the packages now listed on the transition tracker, and needs to include both the versions in unstable as well as those in experimental. Those versions and links to their .dsc files can be found on the Tracker pages for the packages in question.

You should use a dedicated cowbuilder chroot for the gdal rebuilds to not contaminate your builds with other packages not related to the GDAL transition, and to not accidentally build packages for actual use with GDAL 2.0.x not yet available in the archive.

I mostly need a large chunk of time without other packages needing my attention to focus on the GDAL rebuilds. We recently had the hdf5 & armadillo transitions which required gdal rebuilds so my 2.0.1 packages aren't installable anymore and need to be rebuilt again. You need to keep an eye on any similar transitions that are starting or ongoing and account for those during the rebuild process.

All FTBFS issues need to be investigated, and if not caused by another ongoing transition reported in the BTS and usertagged for the gdal-2.0 transition. Have a look at the first two bugs that were reported in preparation of the GDAL 2.0 transition:


If you cannot help with the actual rebuild testing, you can investigate the GDAL support in the various packages by hunting down any issues in their bug trackers about GDAL 2.0 that we need to keep in mind.

Kind Regards,


Reply to: