Re: uploading new rasterio version during transition
On 19-08-15 17:27, Johan Van de Wauw wrote:
> Like many other packages rasterio currently can not be built on sid
> because of the libstdc++ transition.
> But I'd like to add support for python3 (which means going through new).
> I thought about creating a package for experimental (so updates to
> unstable are possible without going through new).
> Does it make sense to upload now or should I just wait a bit until the
> package actually builds?
If the package cannot be built by the buildds for sid nor experimental,
it doesn't make much sense to upload it already. It it only builds in
experimental, upload it there instead.
> Slightly similar, I could also create a package with just a targeted
> fix for #790549 (FTBS on i386, which I fixed upstream). Should I also
> wait uploading that until it builds or should I prepare it already?
I recommend to make any changes you need for the packaging in git,
preparing it as much as possible for an upload but wait with the actual
upload until the build dependency issues are resolved.
For qgis, osm2pgsql and the new osmium packages I've done that, they are
pretty much ready for upload in git, but first we need to get gdal
rebuilt in unstable now that libdap is no longer a blocker.
Hopefully the NetCDF 4.4.0 final release is published soon, I'd like to
use that for the netcdf transition. I had expected the release already,
but so far no new release but still much activity in the upstream git.
I don't want to wait much longer for the 4.4.0 final release, the
4.4.0~rc2 packages are ready in experimental and the netcdf-fortran
update is blocking the GCC 5 gfortran modules transition.
After getting netcdf updated in unstable, it's a good time to move gdal
to unstable too. The spatialite->postgis->gdal->spatialite circular
dependency may also be an issue for the gdal transition like it is for
the geos transition.
Because all these recursive transitions will take some time to complete,
it doesn't make much sense to wait before working on your packages. It's
reasonably easy to rebuild broken build dependencies and use those in
pbuilder to test your builds locally.
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1