Bug#1080439: [SPAM] Bug#1080439: transition: exiv2 0.28.x
exiv2 has been trying to migrate for two weeks now, it's going to need some help. I don't understand the reasons given in the britney update_output. Did the gexiv2 binNMU break the dependencies on it in testing? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1077814: nmu: mapnik rdeps
On 8/2/24 7:12 PM, Bas Couwenberg wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libapache2-mod-t...@packages.debian.org, python-map...@packages.debian.org, ti...@packages.debian.org Control: affects -1 + src:libapache2-mod-tile src:python-mapnik src:tirex User: release.debian@packages.debian.org Usertags: binnmu Please rebuild the mapnik rdeps with the new version in unstable: nmu libapache2-mod-tile_0.7.1-2 . ANY . unstable . -m "Rebuild with libmapnik-dev (>= 4.0.1)" nmu python-mapnik_1:0.0~20240222-5ab32f020-1 . ANY . unstable . -m "Rebuild with libmapnik-dev (>= 4.0.1)" nmu tirex_0.7.1-3 . ANY . unstable . -m "Rebuild with libmapnik-dev (>= 4.0.1)" Thanks for scheduling these in unstable. nmu libapache2-mod-tile_0.8.0~beta-1~exp1 . ANY . experimental . -m "Rebuild with libmapnik-dev (>= 4.0.1)" Please also schedule this one in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
On 8/3/24 7:56 PM, Sebastian Ramacher wrote: On 2024-07-31 09:50:40 +0200, Sebastiaan Couwenberg wrote: On 7/30/24 5:17 AM, Sebastiaan Couwenberg wrote: Now that the s390x builds found their way to the mirrors, most of the autopkgtest regressions got fixed. The remaining autopkgtest regressions for packages that could not be rebuilt during the transition will need a little help to unblock the testing migration of gsl and its rdeps. With the force-skiptest hint britney attempted the migration, but because libgsl27 & libgsl28 are not co-installable due to their dependency on exact versions of libgslcblas0 this failed. gsl 2.8 won't be able to migrate until the unrebuilt rdeps are removed from testing. ipe on i386 is a little problematic as it cannot be removed without removing cgal and its rdeps. This is now blocked on the recent upload of qgis. Which you can hint out of testing. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
On 7/30/24 5:17 AM, Sebastiaan Couwenberg wrote: Now that the s390x builds found their way to the mirrors, most of the autopkgtest regressions got fixed. The remaining autopkgtest regressions for packages that could not be rebuilt during the transition will need a little help to unblock the testing migration of gsl and its rdeps. With the force-skiptest hint britney attempted the migration, but because libgsl27 & libgsl28 are not co-installable due to their dependency on exact versions of libgslcblas0 this failed. gsl 2.8 won't be able to migrate until the unrebuilt rdeps are removed from testing. ipe on i386 is a little problematic as it cannot be removed without removing cgal and its rdeps. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
Now that the s390x builds found their way to the mirrors, most of the autopkgtest regressions got fixed. The remaining autopkgtest regressions for packages that could not be rebuilt during the transition will need a little help to unblock the testing migration of gsl and its rdeps. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1070852: transition: gdal *removed* libgdal34
On 6/4/24 8:46 AM, Emmanuel Charpentier wrote: (Manually) upgrading the spdep and spatial R packages failed, for lack of libgdal.so.34, which *was* installed on my system. The r-cran-sf & r-cran-terra Debian packages have been rebuilt to depend on the libgdal35, you'll need to do the same with any of your local R packages linking to gdal. I was expecting to be able to reinstall libgdal34, which is no longer available. libgdal35 is now in testing, libgdal34 was removed because no packages depend on it any more after the transition completed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1070852: transition: gdal
On 5/24/24 11:46 AM, Sebastiaan Couwenberg wrote: On 5/24/24 11:29 AM, Emilio Pozuelo Monfort wrote: On 24/05/2024 11:02, Sebastiaan Couwenberg wrote: On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote: If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. gdal, grass, and libgdal-grass just need to be tested together. I'd rather drop the autopkgtest test than having to maintain the Breaks in gdal. *shrug*. If that's a runtime check, then there's an issue with the dependencies/breaks, as one could have old libgdal-grass with newer gdal (as is happening in the autopkgtest) and then libgdal-grass is broken. The dependencies of the rebuilt libgdal-grass correctly reflects the required versions of gdal & grass. If it's a check that's being done in libgdal-grass, then maybe that check can be dropped? That likely results in silent breakage. The situation is already better since grass (8.2.0-3) which was patched to not include the build time in the version check. The autopkgtest was added to detect the breakage after grass was updated in stable, but libgdal-grass wasn't rebuilt (#1022768). With the information that autopkgtest has, the current situation is broken and testing migration will be (rightly) blocked. The autopkgtest just needs to use the affected packages from unstable like we've done before. I'd schedule these CI jobs myself, but britney ignores test results it did not schedule itself. gdal, grass, and libgdal-grass all get rebuilt during gdal transitions, expecting libgdal-grass from testing to work with only gdal from unstable is a broken assumption. What are we going to do about the autopkgtest? I've retried older jobs created by britney with gdal, grass, and libgdal-grass from unstable which succeed, and also with only gdal and libgdal-grass from unstable which likewise succeed as expected. Jobs I've scheduled myself with gdal and libgdal-grass from unstable fail because they don't actually use libgdal-grass from unstable as requested. Because autopkgtests are just a hindrance to testing migration dropping the one from libgdal-grass makes sense. It doesn't resolve the blocked testing migration however, because the new revision can't migrate without the new gdal. We'd need an RC bug to get libgdal-grass autoremoved from testing, make britney use the autopkgtest results which succeed when using both gdal and libgdal-grass from unstable, or hint it to ignore the autopkgtest failure. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1070852: transition: gdal
On 5/24/24 11:29 AM, Emilio Pozuelo Monfort wrote: On 24/05/2024 11:02, Sebastiaan Couwenberg wrote: On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote: If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. gdal, grass, and libgdal-grass just need to be tested together. I'd rather drop the autopkgtest test than having to maintain the Breaks in gdal. *shrug*. If that's a runtime check, then there's an issue with the dependencies/breaks, as one could have old libgdal-grass with newer gdal (as is happening in the autopkgtest) and then libgdal-grass is broken. The dependencies of the rebuilt libgdal-grass correctly reflects the required versions of gdal & grass. If it's a check that's being done in libgdal-grass, then maybe that check can be dropped? That likely results in silent breakage. The situation is already better since grass (8.2.0-3) which was patched to not include the build time in the version check. The autopkgtest was added to detect the breakage after grass was updated in stable, but libgdal-grass wasn't rebuilt (#1022768). With the information that autopkgtest has, the current situation is broken and testing migration will be (rightly) blocked. The autopkgtest just needs to use the affected packages from unstable like we've done before. I'd schedule these CI jobs myself, but britney ignores test results it did not schedule itself. gdal, grass, and libgdal-grass all get rebuilt during gdal transitions, expecting libgdal-grass from testing to work with only gdal from unstable is a broken assumption. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1070852: transition: gdal
On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote: If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. gdal, grass, and libgdal-grass just need to be tested together. I'd rather drop the autopkgtest test than having to maintain the Breaks in gdal. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1070852: transition: gdal
On 5/22/24 8:40 AM, Emilio Pozuelo Monfort wrote: Go ahead. Thanks. gdal (3.9.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1061179: Bug#1060019: transition: poppler 24.02
On 5/20/24 5:23 PM, Dmitry Shachnev wrote: Also, one of the affected packages (lmms) currently FTBFS on i386: https://bugs.debian.org/1068155. Would it be possible to remove it from testing on i386 (or completely) so it doesn't block Qt migration? dak reports no rdeps on mirror.ftp-master.d.o: $ dak rm -Rn -a i386 lmms W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: lmms | 1.2.2+dfsg1-6 | source lmms | 1.2.2+dfsg1-6+b1 | i386 lmms-vst-server | 1.2.2+dfsg1-6+b1 | i386 Maintainer: Debian Multimedia Maintainers --- Reason --- -- Checking reverse dependencies... No dependency problem found. So I've filed: #1071530. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Is it possible to use ben offline?
On 5/14/24 2:17 AM, Charles Plessy wrote: I see that ben has a --mirror option. But will it work if the "mirror" is a local archive containing only Bioconductor packages? Or is there a way that I can express the concept that "this local archive should be seen as an additional layer on top of the official mirror", like a PPA or a backports suite? The mirror option is used like in apt sources.list to select which host to download the Packages and Sources files from. As `ben download` uses this, you'll need to skip this step and provide the Packages and Sources files yourself. `ben tracker` should work offline assuming the cache directory has the Packages files for all architectures and the Sources file. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1064810: transition: mpi-defaults
On 2/26/24 7:40 AM, Alastair McKinstry wrote: OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH. This transition is blocking many of the remaining packages rebuilt for 64-bit time_t. The autopkgtest for slurm-wlm on i386 is blocking testing migration of mpich: https://qa.debian.org/excuses.php?package=mpich Testing migration of openmpi is likewise blocked by autopkgtest failures on i386 of several rdeps: https://qa.debian.org/excuses.php?package=openmpi I'm starting to think that it'd be better to drop support for 32bit architectures from all these rdeps so they can just use openmpi everywhere and not have i386 autopkgtest failures able to block testing migration. Should we advocate this to the maintainer of these packages or is there something else we can do to improve this situation? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: R 4.4.0 coming April 24
On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: R upstream no longer releases or tests for 32 bits (and has not since the R 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the release team may need to override this to unblock. Wouldn't it be better then to add architecture-is-64-bit to the r-base build dependencies to prevent it from building on 32bit architectures and then file partial RM bugreports for r-base and its rdeps to get them removed from the 32bit architectures? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1067813: nmu: spatialite_5.1.0-3
Control: merge 1067812 1067813 I already requested this a little earlier. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1
Keeping an eye on the Release Calendar can help too: https://release.debian.org/release-calendar.ics Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1036884: Schedule
On 2/7/24 08:10, Mattias Ellert wrote: Personally I think it would have made more sense to file these bugs with minor or normal severity (since they are simply informational at this stage) and then upgrade them to serious when the transition starts (at which point they become RC). I'd downgrade the severity to important like we do for FTBFS bugreports of rdeps involved in not yet started transitions. Once the transition starts with the upload of dpkg to unstable the severity should be raised to serious. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1059330: transition: shapelib
It turns out that plplot FTBFS on armhf: #1055228 I've requested partial removal of plplot and its rdeps from armhf since a fix is unlikely in the short term: - plplot (1059682) # Broken Depends: - munipack (1059683) - psfex (1059684) # Broken Build-Depends: - coyote (1059685) - gnudatalanguage (1059686) # Broken Depends: - coyote (1059685) - idlastro (1059689) - mpfit (1059690) # Broken Build-Depends: - coyote (1059685) - idlastro (1059689) - mpfit (1059690) - munipack (1059683) - psfex (1059684) - scamp (1059687) # Broken Build-Depends: - theli (1059688) - theli (1059688) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1059330: transition: shapelib
On 12/27/23 21:16, Sebastian Ramacher wrote: On 2023-12-22 16:39:57 +0100, Bas Couwenberg wrote: Shapelib 1.6.0 bumps the SONAME requiring a transition. All rdeps built successfully with the new version as summarized below. Please go ahead. Thanks. shapelib (1.6.0-1) has been uploaded to unstable and is now built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1028489: boost1.83 as default
Please also binNMU icinga2 in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1028489: boost1.83 as default
Don't forget to raise the severity of the FTBFS bugreports to serious now that the new boost-defaults is in unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
On 11/22/23 14:47, Paul Gevers wrote: I mean, in the ideal situation, this class of issues is prevented by proper package relations, but I also want to avoid manual labor that's a PITA to maintain and prone to wrong in the future. To prevent that manual labor, I can drop the autopkgtest from libgdal-grass as it just hinders testing migration. The version mismatches it detects (like #1006446) are less likely since grass got fixed (in 8.2.0-3). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
On 11/19/23 09:34, Paul Gevers wrote: On 19-11-2023 09:06, Sebastiaan Couwenberg wrote: britney only schedules: gdal/3.8.0+dfsg-1 src:gdal from unstable Likely because there is no new version for the libgdal-grass source package, only a binNMU. Well, because there's no relation that tells britney this combination is no good. If there is a newer version of the libgdal-grass source or binary packages britney should also try with those in addition to just gdal. libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight coupling: grass831 (provided by grass-core) libgdal34 (>= 3.8.0) It *might* [1] be missing the upper limit (or some binary of gdal missing a breaks relation)? In other words, yes, libgdal-grass from unstable will pull in the right (current) version, but libgdal-grass (or other binary from libgdal-grass) in testing doesn't know it's broken with the version of src:gdal from unstable. grass is not the most problematic dependency, gdal is: ERROR 1: OGR/GRASS driver was compiled against GDAL 3.7, but the current library version is 3.8 This will never work with libgdal-grass from testing, you need the version from unstable which was rebuilt as part of the transition. grass-core in testing depends on the old libgdal33, hence the need to also get grass and libgdal-grass from unstable when running autopkgtest with gdal from unstable. Why? (In other words, what breaks exactly?) Is this a case where some binaries load the old library and others load the new one leading to symbol clashes? It should work with the version from testing, the version check in libgdal-grass will succeed with the grass version from testing. Just tested in a trixie chroot, both libgdal-grass and gdal packages from unstable are required, grass from testing suffices. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
On 11/19/23 08:54, Paul Gevers wrote: On 19-11-2023 07:32, Sebastiaan Couwenberg wrote: For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, and libgdal-grass from unstable due to the tight coupling. If it doesn't happen automatically and there is a tight coupling, where is the tight coupling missing in the package relations? britney only schedules: gdal/3.8.0+dfsg-1 src:gdal from unstable Likely because there is no new version for the libgdal-grass source package, only a binNMU. libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight coupling: grass831 (provided by grass-core) libgdal34 (>= 3.8.0) grass-core in testing depends on the old libgdal33, hence the need to also get grass and libgdal-grass from unstable when running autopkgtest with gdal from unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, and libgdal-grass from unstable due to the tight coupling. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
cmake on mips64el will also need a higher priority to unblock the rebuilds of several rdeps. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
grass is now also built & installed on all release architectures. libgdal-grass & qgis can be rebuilt. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
On 11/17/23 07:45, Sebastian Ramacher wrote: On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote: For the Debian GIS team I'd like to transition to GDAL 3.8.0. Please go ahead. Thanks. gdal (3.8.0+dfsg-1) has been uploaded to unstable and is now built and installed on all release architectures except mips64el, the priority may need to be increased to not have the package in Needs-Build status for three weeks. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1051395: bookworm-pu: package pywinrm/0.3.0-4+deb12u1
With the upload window closing next week, I've uploaded these changes to bookworm. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1042896: transition: armadillo
Control: block -1 by 1028633 On 8/30/23 09:13, Kumar Appaiah wrote: I could not build mlpack since the build failed, but I am sure it's not due to pip. Here is the extract from the failed build log: -- After much of the build mkdir: cannot create directory '/usr/lib/python3.11/site-packages/': Permission denied /usr/bin/python3: No module named pip CMake Error at /build/mlpack-4.1.0/src/mlpack/bindings/python/PythonInstall.cmake:23 (message): Error installing Python bindings! Call Stack (most recent call first): src/mlpack/bindings/python/cmake_install.cmake:66 (include) src/mlpack/bindings/cmake_install.cmake:50 (include) src/mlpack/cmake_install.cmake:68 (include) cmake_install.cmake:55 (include) That's a known issue: #1028633 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1043045: transition: spatialite
On 8/5/23 15:50, Sebastian Ramacher wrote: Please go ahead. Thanks. spatialite (5.1.0-1) has been uploaded to unstable and is built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Bug#1039030: transition: qtbase-abi-5-15-10
On 7/29/23 19:20, Dmitry Shachnev wrote: So I will probably drop support for mipsel sooner or later. The RM bugreports were just processed, qtwebengine-opensource-src and its rdeps are gone from mipsel now. The next upload of qtwebengine-opensource-src should ideally drop mipsel to prevent this issue for reoccurring. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Bug#1039030: transition: qtbase-abi-5-15-10
On 7/25/23 14:29, Sebastiaan Couwenberg wrote: On 7/25/23 09:39, Sebastiaan Couwenberg wrote: On 7/9/23 18:03, Dmitry Shachnev wrote: Unfortunately, qtwebengine FTBFS on mipsel again. We are working on it together with Adrian Bunk (huge thanks to him for that). There are RM bugreports for qtwebengine-opensource-src and some of its rdeps, but more are required to unblock the removal. I went over the rdep tree with `dak rm -Rn -a mipsel` on coccia to get an idea of what other packages need to be dealt with: Packages that used qtwebengine-opensource-src only on architectures where it's available have patches to remove mipsel from the architecture list. All rdeps that prevent the removal of qtwebengine-opensource-src from mipsel also have RM bugs. I think we're good once all the issues in the list have been dealt with. Now that qtwebengine-opensource-src has been built on mipsel after all, should we close the RM bugreports for the partial removal from mipsel of the rdeps? Or will the next upload of qtwebengine-opensource-src remove the mipsel from its list of architectures? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Bug#1039030: transition: qtbase-abi-5-15-10
On 7/25/23 09:39, Sebastiaan Couwenberg wrote: On 7/9/23 18:03, Dmitry Shachnev wrote: Unfortunately, qtwebengine FTBFS on mipsel again. We are working on it together with Adrian Bunk (huge thanks to him for that). There are RM bugreports for qtwebengine-opensource-src and some of its rdeps, but more are required to unblock the removal. I went over the rdep tree with `dak rm -Rn -a mipsel` on coccia to get an idea of what other packages need to be dealt with: Packages that used qtwebengine-opensource-src only on architectures where it's available have patches to remove mipsel from the architecture list. All rdeps that prevent the removal of qtwebengine-opensource-src from mipsel also have RM bugs. I think we're good once all the issues in the list have been dealt with. qtwebengine-opensource-src (#1041268) - akregator (#1041947) - algobox (#1041948) - angelfish (#1041267) - ball (#1041949) - cantor (#1041950) - labplot [fixed: 2.10.1-1] - digikam [fixed: 4:8.1.0-2] - falkon (#1041903) - fcitx-libpinyin (#1041954, #1041904) - fcitx5-chinese-addons (#1041961, #1041959) - fcitx5-quwei (#1041962) - libime-jyutping (#1041963) - freecad (#1041906) - gambas3 [fixed: 3.18.2-3] (#1041967, #1041909) - gammaray [fixed: 2.11.3-4] - ghostwriter (#1041968) - goldendict-webengine (#1041910) - gpsbabel [fixed: 1.8.0+ds-6] - viking - grantlee-editor (#1041913) - kaccounts-providers [fixed: 4:22.12.3-2] - kalgebra (#1041516) - kbibtex (#1041914) - kdenlive (#1041915) - kdepim-addons (#1041916) - kdepim-runtime [fixed: 4:22.12.3-2] - akonadi-calendar-tools - meta-kde - kaddressbook - kdepim-addons (#1041916) - meta-kde - kalendar (#1041515) - kmail (#1041971) - knotes - meta-kde - kontact - korganizer - meta-kde - kdeplasma-addons [fixed: 4:5.27.5-3] - meta-kde - kf5-messagelib (#1041983) - akonadi-import-wizard (#1041984) - kdepim-addons (#1041916) - akonadiconsole (#1041985) - akregator (#1041947) - grantlee-editor (#1041913) - kdepim-addons (#1041916) - kmail (#1041971) - libkf5mailcommon (#1041987) - akonadi-import-wizard (#1041984) - kalendar (#1041515) - kdepim-addons (#1041916) - kmail (#1041971) - mbox-importer (#1041988) - pim-data-exporter (#1041989) - mbox-importer (#1041988) - pim-data-exporter (#1041989) - kimagemapeditor (#1041970) - kiwix (#1041917) - kmail (#1041971) - konqueror [fixed: 4:22.12.3-2] - meta-kde - kontact (#1041972) - ktorrent [fixed: 22.12.3-2] - ktp-text-ui (#1041974) - lgogdownloader [fixed: 3.11-2] - libkf5ksieve (#1041977) - kdepim-addons (#1041916) - kmail (#1041971) - pim-sieve-editor (#1041978) - mathgl (#1041979, #1041920) - 3depict (#1041980) - debian-pan [arch:all] - merkaartor [fixed: 0.19.0+ds-4] - minizinc-ide (#1041921) - morph-browser (#1041923) - nextcloud-desktop (#1041925) - nmapsi4 (#1041926) - notepadqq (#1041927) - pageedit (#1041928) - parley (#1041981) - pep8-simul (#1041929) - privacybrowser (#1041930) - pyqt5webengine (#1041931) - anki [arch:all] - cyclograph [arch:all] - finalcif [arch:all] - frescobaldi (#1041932) - mnemosyne [arch:all] - openlp [arch:all] - pampi [arch:all] - python-qtpy [arch:all] - qutebrowser [arch:all] - spyder [arch:all] - pyside2 [fixed: 5.15.10-3] - cegui-mk2 - email-reminder [arch:all] - freecad - graide [arch:all] - onionshare [arch:all] - pivy - freecad - pysph - streamdeck-ui [arch:all] - syncplay [arch:all] - qmapshack (#1041601) - qtwebview-opensource-src (#1041266) - piperka-client (#1041933) - plasma-discover [fixed: 5.27.5-3] - quassel [fixed: 1:0.14.0-2] - qutebrowser [arch:all] - radare2-cutter (#1041935) - rssguard (#1041936) - sigil (#1041937) - supercollider (#1041938) - sonic-pi (#1041939) - supercollider-sc3-plugins (#1041940) - syncthingtray (#1041942) - tellico [fixed 3.5.1-2] - zeal (#1041943) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Bug#1039030: transition: qtbase-abi-5-15-10
On 7/9/23 18:03, Dmitry Shachnev wrote: Unfortunately, qtwebengine FTBFS on mipsel again. We are working on it together with Adrian Bunk (huge thanks to him for that). There are RM bugreports for qtwebengine-opensource-src and some of its rdeps, but more are required to unblock the removal. I went over the rdep tree with `dak rm -Rn -a mipsel` on coccia to get an idea of what other packages need to be dealt with: qtwebengine-opensource-src (#1041266) - akregator - algobox - angelfish (#1041267) - ball - cantor - labplot - digikam - falkon - fcitx-libpinyin - fcitx5-chinese-addons - fcitx5-quwei - libime-jyutping - freecad - gambas3 - gammaray - ghostwriter - goldendict-webengine - gpsbabel - viking - grantlee-editor - kaccounts-providers - kalgebra (#1041516) - kbibtex - kdenlive - kdepim-addons - kdepim-runtime - akonadi-calendar-tools - meta-kde - kaddressbook - kdepim-addons - meta-kde - kalendar (#1041515) - kmail - knotes - meta-kde - kontact - korganizer - meta-kde - kdeplasma-addons - meta-kde - kf5-messagelib - akonadi-import-wizard - kdepim-addons - akonadiconsole - akregator - grantlee-editor - kdepim-addons - kmail - libkf5mailcommon - akonadi-import-wizard - kalendar (#1041515) - kdepim-addons - kmail - mbox-importer - pim-data-exporter - mbox-importer - pim-data-exporter - kimagemapeditor - kiwix - kmail - konqueror - meta-kde - kontact - ktorrent - ktp-text-ui - lgogdownloader - libkf5ksieve - kdepim-addons - kmail - pim-sieve-editor - mathgl - 3depict - debian-pan [arch:all] - merkaartor - minizinc-ide - morph-browser - nextcloud-desktop - nmapsi4 - notepadqq - pageedit - parley - pep8-simul - privacybrowser - pyqt5webengine - anki [arch:all] - cyclograph [arch:all] - finalcif [arch:all] - frescobaldi - mnemosyne [arch:all] - openlp [arch:all] - pampi [arch:all] - python-qtpy [arch:all] - qutebrowser [arch:all] - spyder [arch:all] - pyside2 - cegui-mk2 - email-reminder [arch:all] - freecad - graide [arch:all] - onionshare [arch:all] - pivy - freecad - pysph - streamdeck-ui [arch:all] - syncplay [arch:all] - qmapshack (#1041601) - qtwebview-opensource-src (#1041266) - piperka-client - plasma-discover - quassel - qutebrowser [arch:all] - radare2-cutter - rssguard - sigil - supercollider - sonic-pi - supercollider-sc3-plugins - syncthingtray - tellico - ugene - zeal Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1038115: transition: gdal
On 6/23/23 10:45, Sebastiaan Couwenberg wrote: On 6/21/23 12:31, Sebastiaan Couwenberg wrote: On 6/20/23 23:49, Sebastian Ramacher wrote: On 2023-06-15 17:15:27 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1030129 998833 1037920 984398 1037976 For the Debian GIS team I'd like to transition to GDAL 3.7.0. Please go ahead. gdal (3.7.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. Please also binNMU mysql-workbench which builds successfully now that the ca-certificates-java workaround is in unstable. mysql-workbench still needs to be rebuilt in unstable. r-base is blocking testing migration of r-cran-rgdal/r-cran-sf/r-cran-terra which in turn prevents the removal of libgdal32 from testing. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1038115: transition: gdal
On 6/21/23 12:31, Sebastiaan Couwenberg wrote: On 6/20/23 23:49, Sebastian Ramacher wrote: On 2023-06-15 17:15:27 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1030129 998833 1037920 984398 1037976 For the Debian GIS team I'd like to transition to GDAL 3.7.0. Please go ahead. gdal (3.7.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. Please also binNMU mysql-workbench which builds successfully now that the ca-certificates-java workaround is in unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1038115: transition: gdal
On 6/21/23 12:31, Sebastiaan Couwenberg wrote: On 6/20/23 23:49, Sebastian Ramacher wrote: On 2023-06-15 17:15:27 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1030129 998833 1037920 984398 1037976 For the Debian GIS team I'd like to transition to GDAL 3.7.0. Please go ahead. gdal (3.7.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. To make the libgdal-grass autopkgtest pass it needs both gdal and libgdal-grass from unstable. I've scheduled jobs for this, but it seems britney ignores tests it hasn't scheduled itself. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1038115: transition: gdal
On 6/20/23 23:49, Sebastian Ramacher wrote: On 2023-06-15 17:15:27 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1030129 998833 1037920 984398 1037976 For the Debian GIS team I'd like to transition to GDAL 3.7.0. Please go ahead. gdal (3.7.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1031410: Closing p-u requests for fixes included in 11.7
> Should I file another bug report for this?
Yes.
On unstable:
gis=# SELECT
ST_AsGeoJSON(ST_Transform(ST_SetSRID('010120110F04F0844A1349264120ED527FE9DD5841'::geometry,
3857), 31466));
st_asgeojson
---
{"type":"Point","crs":{"type":"name","properties":{"name":"EPSG:31466"}},"coordinates":[2539841.861857439,5586869.519378289]}
(1 row)
On bullseye:
bagv2=# SELECT
ST_AsGeoJSON(ST_Transform(ST_SetSRID('010120110F04F0844A1349264120ED527FE9DD5841'::geometry,
3857), 31466));
st_asgeojson
---
{"type":"Point","crs":{"type":"name","properties":{"name":"EPSG:31466"}},"coordinates":[5586869.519378289,2539841.861857439]}
(1 row)
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1035017: unblock: pdl/1:2.081-2
Control: tags -1 - moreinfo On 4/29/23 10:51, Sebastian Ramacher wrote: On 2023-04-27 16:52:36 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:pdl Please unblock package pdl [ Reason ] It fixed the upgrade failure from bullseye reported in #1034942. [ Impact ] Upgrade from bullseye to bookworm fails. [ Tests ] autopkgtest, Salsa CI, and upstream test suite. I've manually verified the fix for #1034942 by upgrading a bullseye chroot to bookworm using the fixed pdl from my local repo. [ Risks ] Low, the other changes that were pending in git since 1:2.081-1 don't risk breakage. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] The package has been uploaded to unstable. unblock pdl/1:2.081-2 diff -Nru pdl-2.081/debian/changelog pdl-2.081/debian/changelog --- pdl-2.081/debian/changelog 2022-10-27 18:57:46.0 +0200 +++ pdl-2.081/debian/changelog 2023-04-27 15:54:44.0 +0200 @@ -1,3 +1,22 @@ +pdl (1:2.081-2) unstable; urgency=medium + + * Team upload. + + [ Bas Couwenberg ] + * Add Rules-Requires-Root to control file. + * Add a debhelper sequence to run dh_pdl. Would you mind re-uploading without that change? It doesn't seem to provide a targetted fix for a bug report. I'd rather not. While not a targeted fix, it also doesn't risk introducing regressions. + * Bump Standards-Version to 4.6.2, no changes. + * Add Breaks/Replaces on libpdl-stats-perl to fix upgrade. +(closes: #1034942) + + [ Debian Janitor ] + * Update lintian override info to new format: ++ debian/source/lintian-overrides: line 2 ++ debian/pdl.lintian-overrides: line 6, 10, 22, 28 + * Use secure URI in Homepage field. + + -- Bas Couwenberg Thu, 27 Apr 2023 15:54:44 +0200 + pdl (1:2.081-1) unstable; urgency=medium * Team upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1034206: unblock: owslib/0.27.2-3
On 4/11/23 06:48, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ows...@packages.debian.org Control: affects -1 + src:owslib Please unblock package owslib It is affected by CVE-2023-27476 reported in #1034182. [ Reason ] Fixes security issue and missing recommended dependencies. [ Impact ] Unfixed security issue. [ Tests ] Upstream test suite. [ Risks ] Low, the changes are pretty straight forward. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Testing autoremoval of rdeps would remove qgis which is one of, if not the, most important GIS packages for users. The package has not been unloaded to unstable yet. unblock owslib/0.27.2-3 Since there was no objection to the pending changes from git that were included in tirex (#1034242), owslib (0.27.2-3) has been uploaded to unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1034242: unblock: tirex/0.7.0-3
Control: tags -1 - moreinfo On 4/15/23 18:03, Sebastian Ramacher wrote: Please remove the moreinfo tag once the package is available in unstable. tirex (0.7.0-3) is built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1031410: bullseye-pu: package postgis/3.1.1+dfsg-1+deb11u1
On 4/1/23 21:23, Adam D. Barratt wrote: On Thu, 2023-02-16 at 19:38 +0100, Bas Couwenberg wrote: As reported in #1031392, postgis 3.1.1 has an important issue with polar stereographic projections which was resolved in 3.1.2. [ Impact ] Unusable coordinates from transformations. Please go ahead. Thanks, postgis (3.1.1+dfsg-1+deb11u1) has been upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1031410: bullseye-pu: package postgis/3.1.1+dfsg-1+deb11u1
Can we get this into the upcoming 11.7 point release? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1028452: unblock: golang-1.19/1.19.5-1
On 1/19/23 10:26, Shengjing Zhu wrote: On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: The history record for golang point release doesn't show regressions. That's good, are you talking about point release in general, or releases to stable? Missed this one. I'm talking about the upstream point release. We haven't met regression so far when we update golang-1.x packages in unstable. I remember 1.18.4 introducing a regression that broke icingadb: https://bugs.debian.org/1015088 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1027283: transition: tiff
Please also binNMU grass in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1027853: transition: muparserx
On 1/4/23 23:48, Sebastian Ramacher wrote: On 2023-01-04 04:40:43 +0100, Andreas Bombe wrote: This is still a package with a soname coupled to its release number, so there isn't really anything significantly changed. It has genomicsdb, otb and qiskit-aer as rdepds and I successfully built all three against the new version. For both genomicsdb and qiskit-aer the build time testsuite completed without failures. otb does not appear to have a testsuite. The auto-muparserx ben tracker appears correct. Please go ahead muparserx (4.0.11-2) is built & installed on all release architectures, the binNMUs can be scheduled. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2
On 12/15/22 20:15, Ondřej Surý wrote: I think everything is mostly ready in experimental. I'll try to sort out the rest of the missing extensions over the weekend (imagick, memcached, redis and maybe few others). php-igbinary needs to be moved to unstable, php-apcu is built & installed on all release architectures. php-raphf is also built & installed on all release architectures, but php-pecl-http was not staged in experimental and will need to pass NEW. php-memcached and php-redis were not uploaded to experimental either. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1014460: transition: php8.2
On 7/14/22 15:23, Paul Gevers wrote: https://release.debian.org/transitions/html/php8.2.html [...] title = "php8.2"; is_affected = .depends ~ "phpapi-20210902" | .depends ~ "phpapi-20210903"; is_good = .depends ~ "phpapi-20210903"; is_bad = .depends ~ "phpapi-20210902"; Tracker file set up and will be available in a short while. is_good doesn't match what's currently used for builds with php8.2: phpapi-20220829 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1026825: python3.11 as default
On 1/6/23 08:23, Paul Gevers wrote: On 06-01-2023 07:39, Sebastiaan Couwenberg wrote: What's your plan to deal with these entanglements? I have bumped the priority of php8.2 on ppc64el and s390x as a start. Thanks, gtk+3.0 is also blocking several packages on s390x. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1026825: python3.11 as default
On 1/2/23 16:28, Graham Inggs wrote: qtbase-opensource-src is done, there's been no progress with PHP 8.2, but we can deal with mapserver and zeroc-ice if they become entangled. php-defaults got updated in unstable, now mapserver is BD-Uninstallable until php8.2 gets built on ppc64el & s390x which is going to take a while thanks to the massive Needs-Build backlog of binNMUs for the python3.11-default transition. What's your plan to deal with these entanglements? Hint mapserver out of testing? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 14:13, Simon McVittie wrote: 2. If there is already a version in experimental that is unsuitable for the next stable release, because there's only one experimental, in the rare case that upstream bumps the SONAME of the "old" branch, we can't do as asked. For example: - libfoo_1.0-1 (libfoo-1.so.0) is in testing/unstable - libfoo_2.0-1 (libfoo-2.so.0) is in experimental but not yet ready - maintainer wants to get libfoo 1.5 (libfoo-1.so.1) into testing/unstable This seems unlikely to happen often, because upstreams usually focus development of intrusive changes that can break ABI onto one branch at a time. Presumably if a maintainer finds that they need this, the ftp team would read a justification in debian/changelog and relax this rule? If bikesheds ever become available, then they would solve all instances of the "only one experimental" problem, including this one. When I've needed experimental for an older version I filed an RM bugreport for the package in experimental. Being blocked by two ftp-master actions is not ideal, but it works. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 12:26, Paul Gevers wrote: Are there objections against this workflow? (Or voices from people who This has been a best practice for quite a while, high time to make it hard requirement. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1026933: Transition Qt 6.4.2
On 12/30/22 12:43, Sebastian Ramacher wrote: On 2022-12-30 05:07:54 +0100, Patrick Franz wrote: Qt 6.4.2~rc1 has now been built successfully on every architecture except s390x where the builds have been queued. However, we don't see a reason why 6.4.2 couldn't be built on s390x. Please go ahead. Testing migration is blocked by this hint: # 2022-12-31 # uncorrdinated change of -dev package names block qt6-base Can you elaborate what the maintainer needs to do to get this transition unblocked? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2
On 10/22/22 21:46, Ondřej Surý wrote: I'll be uploading the PECL extensions for PHP 8.2 to experimental as I will update them for PHP 8.2 - I haven't started yet, but should be able to do before or around the PHP 8.2.0 release. Do you plan to include php-imagick in this? I had to rebuild it with php8.2 from experimental for icingaweb2. Kind regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023535: transition: protobuf
On 11/24/22 21:03, Sebastian Ramacher wrote: protobuf's autopkgtests are failing. Could you please take a look at them? Thanks Patch available in: https://bugs.debian.org/1024677 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
On 11/23/22 19:22, Paul Gevers wrote:
On 23-11-2022 05:28, Sebastiaan Couwenberg wrote:
The libgdal-grass autopkgtest in testing is failing because it
requires gdal, grass, and libgdal-grass from unstable.
https://qa.debian.org/excuses.php?package=gdal
This combination needs to be tested to fix the regressions shown and
unblock testing migration of gdal and the related rebuilt packages.
I'll schedule the set, but I have the feeling that a proper versioned
relation (maybe an upper limit??) is missing somewhere. As there are
quite a few versioned binaries involved already, it's obvious that
there's a design. But if there's a runtime check for a version, ideally
that should be expressed in dependencies too. Unless I'm missing
something of course. (If that dependency would be there, britney would
ask apt to pin packages from the source providing it from unstable if
they are not fulfilled in testing).
"""
ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying
to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
"""
This is not reflected in the dependencies, only the ABI dependency
provided by grass-core is set:
grass820
The dependency is set with a dh_gencontrol override.
This version check in grass is much stricter than it should be, the
builds from the upstream git repo use the commit hash of include
directory to check whether the code using grass is still compatible.
Because this requirement to rebuild libgdal-grass everytime grass is
rebuilt annoyed me, I dug into this issue and had it changed upstream to
use the full GRASS version (e.g. 8.2.0) like the virtual ABI dependency
provided by grass-core for tarball builds.
GRASS 8.2.1 will contain this change, with their release process slower
than expected, it's not sure whether it will be released before the
bookworm freeze.
For future gdal transitions pulling in only the new gdal from unstable
may suffice, although grass from testing still using the old gdal may
cause different problems than just this version check. Like the crssync
segfaults tend that happen with qgis when its dependencies are linked to
different libproj versions.
"""
ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current
library version is 3.6
ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the
current library version is 3.6
"""
This is reflected in the libgdal-grass (1:1.0.2-2) dependencies:
libgdal32 (>= 3.6.0)
Those are the normal ${shlibs:Depends} set via symbols files.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
On 11/22/22 21:56, Paul Gevers wrote: On 22-11-2022 11:26, Sebastiaan Couwenberg wrote: How can we schedule autopkgtest runs for testing with gdal & libgdal-grass from unstable? Most of the time britney and autopkgtest handle it automatically if dependencies are rightly versioned (although not ideally during transitions). If you see issues more than a day after a binNMU, please be specific and let us know, then we can check and if needed schedule manually. The libgdal-grass autopkgtest in testing is failing because it requires gdal, grass, and libgdal-grass from unstable. https://qa.debian.org/excuses.php?package=gdal This combination needs to be tested to fix the regressions shown and unblock testing migration of gdal and the related rebuilt packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
How can we schedule autopkgtest runs for testing with gdal & libgdal-grass from unstable? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
On 11/20/22 20:19, Sebastiaan Couwenberg wrote: On 11/19/22 20:18, Sebastian Ramacher wrote: On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead > Thanks. gdal (3.6.0+dfsg-2) has been uploaded to unstable and took a while to get built on s390x, but is not built & installed on all release architectures. grass is built & installed on all release architectures, libgdal-grass can be binNMUed. qgis had a source upload to fix the FTBFS with python3.11 and cmake 3.25. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023731: BioC Transition blocked by new dependencies
On 11/21/22 17:21, Andreas Tille wrote: Am Mon, Nov 21, 2022 at 04:49:43PM +0100 schrieb Sebastiaan Couwenberg: This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. You can rebuild the packages that are already in the archive and include them in a local repo (e.g. managed with reprepro) and used by the chroot where the rebuilds are performed. Use that to prepare the NEW uploads to experimental, file the transition bugreport once all packages have passed NEW, and move those to unstable once the transition is ACKed. Well, probably everything is possible, but as I said the tracker comes pretty handy to know the dependency relation. I really would like to know what might be the real problem of the delay of the transition in this specific case. Making me understand this problem would increase the motivation to do something else than currently. To prepare for GIS transition sI run my own ben instance to generate the trackers (for testing, unstable, and experimental), it's relatively easy to setup. If you'd like help to setup a ben instance for the R team, let me know. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023731: BioC Transition blocked by new dependencies
On 11/21/22 16:39, Andreas Tille wrote: Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: Some of the BioConductor packages need new dependencies. I have pushed these to new queue and set the ITP bugs as blocker. As this is happening every r-bioc transition, could this be handled before starting the transition the next time? This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. You can rebuild the packages that are already in the archive and include them in a local repo (e.g. managed with reprepro) and used by the chroot where the rebuilds are performed. Use that to prepare the NEW uploads to experimental, file the transition bugreport once all packages have passed NEW, and move those to unstable once the transition is ACKed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
On 11/19/22 20:18, Sebastian Ramacher wrote: On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead Thanks. gdal (3.6.0+dfsg-2) has been uploaded to unstable and took a while to get built on s390x, but is not built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1021984: (some kind of) transition: add python3.11 as a supported python3 version
Please also binNMU gdal & python-shapely in experimental: nmu gdal_3.6.0+dfsg-1~exp1 . ANY . experimental . -m "Rebuild with Python 3.11 as supported" nmu python-shapely_2.0~b2-1~exp1 . ANY . experimental . -m "Rebuild with Python 3.11 as supported" Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2
On 10/22/22 16:25, David Prévot wrote: I believe there are no more blockers that could be spotted with debci. Since not all packages have tests, and those tests can’t spot every regressions, there will probably be more issues, but I believe it looks good for now (especially compared to previous transitions). I believe the first (non RC) PHP 8.2 release is expected upstream in a month, so, if that’s the targeted version for Bookworm, I hope this transition could happen as soon as possible. icingaweb2 explicitly doesn't support php8.2 upstream yet, their php8.1 support took many months to land, getting php8.2 into unstable before the bookworm freeze will most likely result in not shipping icingaweb2. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1018067: calibre: Remove unsuppoted architecture package from unstable distribution, and enable testing migration
On 8/25/22 07:24, yokota wrote: Please remove Calibre 5.44.0+dfsg-1 mips64el/mips package from unstable distribution, and enable testing migration. Removal from unstable is done by the FTP team: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removing-packages Once the package is removed from unstable, it will be removed from testing automatically. `dak rm -Rn -a mipsel -a mips64el calibre` on mirror.ftp-master.debian.org shows an issue: # Broken Build-Depends: dpmb: calibre It's an arch:all package, so not a blocker. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1016496: nmu: abinit_9.6.2-1
On 8/1/22 22:34, Paul Gevers wrote: On 01-08-2022 22:18, Bas Couwenberg wrote: nmu abinit_9.6.2-1 . ANY . unstable . -m "Rebuild with libnetcdff7 (>= 4.6.0+ds-1)" To resolve the autopkgtest failure reported in #1016414, the package needs to be rebuilt. That normally means it's papering over the real issue. Are you sure libnetcdff shouldn't have bumped it's SONAME? Based on the symbols changes I'd say no, only a few new symbols were introduced. But it's fortran of which I know little to nothing, so... I don't want to diverge from upstream nor go through NEW for an issue I don't understand, so feel free to close this issue and we'll wait for autoremoval or a new upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1010937: transition: gdal
On 6/11/22 18:14, Sebastiaan Couwenberg wrote: On 6/11/22 11:06, Sebastiaan Couwenberg wrote: On 6/11/22 01:32, Sebastian Ramacher wrote: Please go ahead Thanks. gdal (3.5.0+dfsg-1) has been uploaded to unstable and is built and installed on all release architectures. libgdal-grass (1:1.0.0-1) has also been uploaded to unstable. Thanks for the binNMUs. qgis can bin rebuilt now that grass is built and installed on all release architectures. Please also binNMU gazebo and postgis in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1010937: transition: gdal
On 6/11/22 11:06, Sebastiaan Couwenberg wrote: On 6/11/22 01:32, Sebastian Ramacher wrote: Please go ahead Thanks. gdal (3.5.0+dfsg-1) has been uploaded to unstable and is built and installed on all release architectures. libgdal-grass (1:1.0.0-1) has also been uploaded to unstable. Thanks for the binNMUs. qgis can bin rebuilt now that grass is built and installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1010937: transition: gdal
On 6/11/22 01:32, Sebastian Ramacher wrote: Please go ahead Thanks. gdal (3.5.0+dfsg-1) has been uploaded to unstable and is built and installed on all release architectures. libgdal-grass (1:1.0.0-1) has also been uploaded to unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1010937: transition: gdal
On 5/13/22 16:45, Bas Couwenberg wrote: mysql-workbench (8.0.26+dfsg-1) FTBFS due to gcc-11 (#998833). vtk6 (6.3.0+dfsg2-8.1) FTBFS due to gcc-11 (#984398). Neither of these are in testing, and they still depends qgis (3.22.5+dfsg-1) FTBFS due to sip6 (#1009939) and not supporting Multi-Arch paths for gdal which is fixed in git. sip6 (6.6.1+dfsg-2) fixed the issue causing qgis to FTBFS, and the gdal issue was subsequently fixed in qgis (3.22.6+dfsg-1). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1006944: transition: proj
On 3/23/22 08:09, Sebastiaan Couwenberg wrote: On 3/22/22 16:58, Sebastiaan Couwenberg wrote: On 3/22/22 09:44, Sebastiaan Couwenberg wrote: On 3/21/22 22:43, Sebastian Ramacher wrote: Please go ahead Thanks. proj (9.0.0-1) has been uploaded to unstable and is now built & installed on all release architectures. Thanks for scheduling the binNMUs. Dependency level 2 and 3 are done, level 4 can be scheduled. grass and r-cran-sf are done, qgis and r-cran-lwgeom can be binNMUed. vtk9 is done, therion can be binNMUed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1006944: transition: proj
On 3/22/22 16:58, Sebastiaan Couwenberg wrote: On 3/22/22 09:44, Sebastiaan Couwenberg wrote: On 3/21/22 22:43, Sebastian Ramacher wrote: Please go ahead Thanks. proj (9.0.0-1) has been uploaded to unstable and is now built & installed on all release architectures. Thanks for scheduling the binNMUs. Dependency level 2 and 3 are done, level 4 can be scheduled. grass and r-cran-sf are done, qgis and r-cran-lwgeom can be binNMUed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1006944: transition: proj
On 3/22/22 09:44, Sebastiaan Couwenberg wrote: On 3/21/22 22:43, Sebastian Ramacher wrote: Please go ahead Thanks. proj (9.0.0-1) has been uploaded to unstable and is now built & installed on all release architectures. Thanks for scheduling the binNMUs. Dependency level 2 and 3 are done, level 4 can be scheduled. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1006944: transition: proj
On 3/21/22 22:43, Sebastian Ramacher wrote: Please go ahead Thanks. proj (9.0.0-1) has been uploaded to unstable and is now built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1006446: nmu: libgdal-grass_3.2.2-1
On 2/25/22 17:07, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libgdal-grass_3.2.2-1 . ANY . bullseye . -m "Rebuild with grass (>= 7.8.5-1+deb11u1)" libgdal-grass is unusable since the stable update of grass: # ogrinfo -ro -so /tmp/spearfish/PERMANENT/vector/roads/head Warning 1: GRASS warning: GISBASE environment variable was not set, using: /usr/lib/grass78 ERROR: Module built against version 2020-12-21T21:08:55+00:00 but trying to use version 2021-12-06T03:01:50+00:00. You need to rebuild GRASS GIS or untangle multiple installations. Can this be included in the bullseye (11.3) point release? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1
On 1/1/22 10:18, Kunal Mehta wrote: On 1/1/22 00:01, Paul Gevers wrote: It seems I don't understand how PHP packaging works. I scheduled rebuilds of several packages that were yesterday on the tracker page [1] when that still only had the phpapi-* listed. Several packages can't be build yet it seems (because they depend on packages that need new uploads), but e.g. wikidiff2 built fine *but disappeared* from the tracker. I looked at a build log [2] and noticed that the binary has files in /etc/php8.1 (and not in /etc/php7.4), but doesn't tell otherwise (in package relations) that it's meant for php8.1 and not for php7.4. Why did that phpapi-* thing disappear? Is that intended? The built binaries already migrated to testing, while the default there is still php7.4. I assume we can consider php-wikidiff2 (partially?) broken now *in testing*? Same for php-luasandbox [3], php-geos [4], and php-excimer [5] (which also FTBFS on mipsel). Previously the dh_php step would add the phpapi- dependency, however this was removed[1] and the new php-common dependency is added via pkg-pecl.mk[2]. The packaging for wikidiff2/luasandbox/excimer/wmerrors (all basically identical) only uses the dh_php step, and not pkg-pecl.mk. The removal of the phpapi dependency should be reverted. php-geos now only depends on: php-common (>= 1:7.0+33~) But it installs files in /etc/php/8.1/mods-available and /usr/lib/php/20210902 which are not provided by older php-common versions. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#998887: transition: gdal
On 12/10/21 17:32, Sebastiaan Couwenberg wrote: On 12/10/21 14:33, Sebastiaan Couwenberg wrote: On 12/8/21 20:59, Sebastiaan Couwenberg wrote: Thanks. gdal (3.4.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. pdal is built & installed on all release architectures, grass & paraview can be binNMUed. openscenegraph is also ready, sumo can also be binNMUed. grass is built & installed on all release architectures, libgdal-grass & qgis can be binNMUed now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#998887: transition: gdal
On 12/10/21 14:33, Sebastiaan Couwenberg wrote: On 12/8/21 20:59, Sebastiaan Couwenberg wrote: Thanks. gdal (3.4.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. pdal is built & installed on all release architectures, grass & paraview can be binNMUed. openscenegraph is also ready, sumo can also be binNMUed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#998887: transition: gdal
On 12/8/21 20:59, Sebastiaan Couwenberg wrote: Thanks. gdal (3.4.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. pdal is built & installed on all release architectures, grass & paraview can be binNMUed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#998887: transition: gdal
On 12/8/21 12:30, Sebastian Ramacher wrote: On 2021-11-09 15:07:50 +0100, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 998833 998827 984398 984401 984283 984284 For the Debian GIS team I'd like to transition to GDAL 3.4.0. Please go ahead Thanks. gdal (3.4.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. libgdal-grass doesn't need a binNMU as the 3.4.0 version will be uploaded to unstable instead. libgdal-grass (3.4.0-1) has been uploaded to unstable too, even though pdal & grass haven't been rebuilt yet, as I got complaints that it didn't migrate to testing along with gdal with the previous transition. As it has linked to the old libgdal, it will need a binNMU too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1000454: bullseye-pu: package gdal/3.2.2+dfsg-2+deb11u1
Control: tags -1 - moreinfo On 12/3/21 17:16, Adam D. Barratt wrote: On Tue, 2021-11-23 at 14:34 +0100, Bas Couwenberg wrote: The LVBAG driver in GDAL 3.2.2 is unable to process BAG 2.0 Extract files correctly. Since October 2021 BAG 1.0 Extract files are no longer updated, so users are expected to switch their processing to BAG 2.0. GDAL 3.3.0 and 3.4.0 contain changes required to process BAG 2.0 Extract files correctly. diff -Nru gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch --- gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch 1970-01-01 01:00:00.0 +0100 +++ gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch 2021-11-23 10:11:54.0 +0100 @@ -0,0 +1,170 @@ +Description: Add a cppcheck_2004 CI target, and fix related issues +Author: Even Rouault +Origin: https://github.com/OSGeo/gdal/commit/6ff924dfc704776cbdeff1e0e23da6452cf06933 +Bug: https://github.com/OSGeo/gdal/pull/3516 + +--- a/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp b/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp This is a little confusing. The upstream commit in question touches 24 files, but this patch only changes one. Is that intentional? If so, the patch header could do with some more information, because it doesn't appear that the patch actually includes the change mentioned in the description. The description comes from the commit message. The patch only includes the cppcheck fixes for the LVBAG driver. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1000454: bullseye-pu: package gdal/3.2.2+dfsg-2+deb11u1
On 11/23/21 14:34, Bas Couwenberg wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org [ Reason ] The LVBAG driver in GDAL 3.2.2 is unable to process BAG 2.0 Extract files correctly. Since October 2021 BAG 1.0 Extract files are no longer updated, so users are expected to switch their processing to BAG 2.0. GDAL 3.3.0 and 3.4.0 contain changes required to process BAG 2.0 Extract files correctly. [ Impact ] Unable to update their BAG databases with current data. [ Tests ] The changes are covered by the upstream CI, and have been manually tested on a bulleye system. [ Risks ] Low, only the relevant changes for this specific driver are added. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] The branch for the stable update is updated in gbp.conf & the Vcs-Git URL. The relevant upstream changes are added as patches, and stripped from unrelated changes. Can we get this into the 11.2 point release? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1
On 11/21/21 21:44, Otto Kekäläinen wrote: mariadb-10.5 (1:10.5.13-0+deb11u1) bullseye; urgency=medium * New upstream version 10.5.13. Includes security fixes for: - CVE-2021-35604 * Drop MIPS and libatomic patches applied now upstream -- Otto Kekäläinen Sat, 20 Nov 2021 12:53:28 -0800 Please also fix #994284 in this PU as it still affects the version in bullseye. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976811: transition: php8.1
On 11/19/21 21:27, Paul Gevers wrote: On 19-11-2021 20:50, David Prévot wrote: Le 10/11/2021 à 05:16, Sebastian Ramacher a écrit : On 2021-09-05 19:26:39, Ondřej Surý wrote: the PHP 8.1 RC1 was released, so I think it would be better to skip php8.0 […] I’ll update this issue when I am ready. It seems that php-defaults (85) was uploaded to unstable, pushing PHP 8.1 as default in unstable before this was even a default in experimental. Did I miss some communication, has this transition already started? Not that I'm aware of, and I don't think it's a good idea to have it started already as there is so much fall out. Can this please be reverted and staged in experimental first? Bugs filed for all issues with autopkgtest? Such that there's a good overview (and fixes) *before* we transition? swig is not included in the transition tracker, but it should support PHP 8 from 4.2.0 onward which has not been released yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version
On 11/19/21 12:58, Antonio Terceiro wrote: On Thu, Nov 18, 2021 at 10:01:17AM +0100, Sebastiaan Couwenberg wrote: On 11/18/21 09:49, Matthias Klose wrote: On 11/18/21 06:51, Sebastiaan Couwenberg wrote: On 11/16/21 14:23, Matthias Klose wrote: I'm planning to upload python3-defaults later tonight, adding 3.10 as a supported Python version. Packages are able to migrate on their own, there are no blockages introduced on other transitions. numpy rdeps (e.g. pyproj) are a bit problematic, they fail with the 3.10 as long as numpy is not built with it yet. numpy is in stage6 of the transition. so please be a bit patient until all the binNMUs up to stage6 are built. There has been no communication about this transition outside this bugreport, you should probably follow the example for perl transitions to alert the developer base about the expected ImportError issues with the new version until the rebuilds are completed. This Python transition is different from the Perl transitions. Python has multiple simultaneously supported versions, in this case 3.9 and 3.10. The transition involves rebuilding the packages with C extensions so that they carry the associated binary files compiled for both support Python versions. Any errors due to missing support in dependencies affect only people building Python packages. The default Python is still Python 3.9, so users using Python programs are not affected during this transition. Perl, on the other hand, has only a single version at the archive at any time. This is why during the Perl transition, it's possible that users running Perl programs are affected by missing C extensions during the time it takes to rebuild all packages for the new Perl version. Both transition affect a large number of packages which the maintainers need to be aware of. And the advice to not upload packages involved in the transition is good for the Python transitions as well. People running the test target for their Python packages using pybuild will be unhappy that their dependencies are not available yet for the new Python version breaking the build. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version
On 11/18/21 09:49, Matthias Klose wrote: On 11/18/21 06:51, Sebastiaan Couwenberg wrote: On 11/16/21 14:23, Matthias Klose wrote: I'm planning to upload python3-defaults later tonight, adding 3.10 as a supported Python version. Packages are able to migrate on their own, there are no blockages introduced on other transitions. numpy rdeps (e.g. pyproj) are a bit problematic, they fail with the 3.10 as long as numpy is not built with it yet. numpy is in stage6 of the transition. so please be a bit patient until all the binNMUs up to stage6 are built. There has been no communication about this transition outside this bugreport, you should probably follow the example for perl transitions to alert the developer base about the expected ImportError issues with the new version until the rebuilds are completed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version
On 11/16/21 14:23, Matthias Klose wrote: I'm planning to upload python3-defaults later tonight, adding 3.10 as a supported Python version. Packages are able to migrate on their own, there are no blockages introduced on other transitions. numpy rdeps (e.g. pyproj) are a bit problematic, they fail with the 3.10 as long as numpy is not built with it yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#996204: transition: numerical library stack
Hi Anton, On 10/26/21 08:56, Anton Gladky wrote: OK, I will upload it into unstable very soon. What abou #997664? The package should go to NEW actually. Or leave it as it is for the moment? The upload to experimental is built on all release architectures. Is there anything preventing the upload to unstable? sundials is part of the octave dependency chain, which is currently uninstallable preventing the rebuild of octave-octproj as part of the proj transition. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/23/21 08:27, Sebastiaan Couwenberg wrote: On 10/22/21 6:17 PM, Sebastiaan Couwenberg wrote: On 10/22/21 5:51 PM, Sebastiaan Couwenberg wrote: On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote: On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: On 10/21/21 11:17 PM, Sebastian Ramacher wrote: On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345 For the Debian GIS team I'd like to transition to PROJ 8. Please go ahead. Please also raise the remaining FTBFS bugs to serious. proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to unstable. And the severity of the bugreports has been raised to serious. Thanks for already scheduling the dependency level 2 NMUs, these are almost done except for mips64el where they had to wait for proj to be installed which it is now. libgeotiff & spatialite are built & installed on all release architectures, dependency level 3 can be NMUed now. magics++ is built and installed on all release architectures, cdo can be NMUed now. gdal is now also built & installed on all release architectures, the rest of dependency level 4 can be NMUed now too. grass and r-cran-sf are built & installed on all release architectures, qgis and r-cran-lwgeom can be NMUed. The rest of dependency level 5 is waiting for vtk9 which will take a bit more time. vtk9 is now also built & installed on all release architectures, the rest of dependency level 5 can also be NMUed now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/22/21 6:17 PM, Sebastiaan Couwenberg wrote: > On 10/22/21 5:51 PM, Sebastiaan Couwenberg wrote: >> On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote: >>> On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: >>>> On 10/21/21 11:17 PM, Sebastian Ramacher wrote: >>>>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >>>>>> Package: release.debian.org >>>>>> Severity: normal >>>>>> User: release.debian@packages.debian.org >>>>>> Usertags: transition >>>>>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>>>>> Control: forwarded -1 >>>>>> https://release.debian.org/transitions/html/auto-proj.html >>>>>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 >>>>>> 983345 >>>>>> >>>>>> For the Debian GIS team I'd like to transition to PROJ 8. >>>>> >>>>> Please go ahead. Please also raise the remaining FTBFS bugs to serious. >>>> >>>> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to >>>> unstable. And the severity of the bugreports has been raised to serious. >>>> >>>> Thanks for already scheduling the dependency level 2 NMUs, these are >>>> almost done except for mips64el where they had to wait for proj to be >>>> installed which it is now. >>> >>> libgeotiff & spatialite are built & installed on all release >>> architectures, dependency level 3 can be NMUed now. >> >> magics++ is built and installed on all release architectures, cdo can be >> NMUed now. > > gdal is now also built & installed on all release architectures, the > rest of dependency level 4 can be NMUed now too. grass and r-cran-sf are built & installed on all release architectures, qgis and r-cran-lwgeom can be NMUed. The rest of dependency level 5 is waiting for vtk9 which will take a bit more time. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/22/21 5:51 PM, Sebastiaan Couwenberg wrote: > On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote: >> On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: >>> On 10/21/21 11:17 PM, Sebastian Ramacher wrote: >>>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >>>>> Package: release.debian.org >>>>> Severity: normal >>>>> User: release.debian@packages.debian.org >>>>> Usertags: transition >>>>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>>>> Control: forwarded -1 >>>>> https://release.debian.org/transitions/html/auto-proj.html >>>>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 >>>>> 983345 >>>>> >>>>> For the Debian GIS team I'd like to transition to PROJ 8. >>>> >>>> Please go ahead. Please also raise the remaining FTBFS bugs to serious. >>> >>> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to >>> unstable. And the severity of the bugreports has been raised to serious. >>> >>> Thanks for already scheduling the dependency level 2 NMUs, these are >>> almost done except for mips64el where they had to wait for proj to be >>> installed which it is now. >> >> libgeotiff & spatialite are built & installed on all release >> architectures, dependency level 3 can be NMUed now. > > magics++ is built and installed on all release architectures, cdo can be > NMUed now. gdal is now also built & installed on all release architectures, the rest of dependency level 4 can be NMUed now too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote: > On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: >> On 10/21/21 11:17 PM, Sebastian Ramacher wrote: >>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >>>> Package: release.debian.org >>>> Severity: normal >>>> User: release.debian@packages.debian.org >>>> Usertags: transition >>>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>>> Control: forwarded -1 >>>> https://release.debian.org/transitions/html/auto-proj.html >>>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 >>>> 983345 >>>> >>>> For the Debian GIS team I'd like to transition to PROJ 8. >>> >>> Please go ahead. Please also raise the remaining FTBFS bugs to serious. >> >> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to >> unstable. And the severity of the bugreports has been raised to serious. >> >> Thanks for already scheduling the dependency level 2 NMUs, these are >> almost done except for mips64el where they had to wait for proj to be >> installed which it is now. > > libgeotiff & spatialite are built & installed on all release > architectures, dependency level 3 can be NMUed now. magics++ is built and installed on all release architectures, cdo can be NMUed now. > The rebuild of octave-octproj is blocked by sundials not having been > rebuilt with the new petsc yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote: > On 10/21/21 11:17 PM, Sebastian Ramacher wrote: >> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>> Control: forwarded -1 >>> https://release.debian.org/transitions/html/auto-proj.html >>> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345 >>> >>> For the Debian GIS team I'd like to transition to PROJ 8. >> >> Please go ahead. Please also raise the remaining FTBFS bugs to serious. > > proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to > unstable. And the severity of the bugreports has been raised to serious. > > Thanks for already scheduling the dependency level 2 NMUs, these are > almost done except for mips64el where they had to wait for proj to be > installed which it is now. libgeotiff & spatialite are built & installed on all release architectures, dependency level 3 can be NMUed now. The rebuild of octave-octproj is blocked by sundials not having been rebuilt with the new petsc yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#993680: transition: proj
On 10/21/21 11:17 PM, Sebastian Ramacher wrote: > On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >> Control: forwarded -1 >> https://release.debian.org/transitions/html/auto-proj.html >> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345 >> >> For the Debian GIS team I'd like to transition to PROJ 8. > > Please go ahead. Please also raise the remaining FTBFS bugs to serious. proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to unstable. And the severity of the bugreports has been raised to serious. Thanks for already scheduling the dependency level 2 NMUs, these are almost done except for mips64el where they had to wait for proj to be installed which it is now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#995587: transition: ruby3.0-add
On 10/20/21 2:45 PM, Antonio Terceiro wrote: > On Sat, Oct 16, 2021 at 03:46:11PM +0200, Sebastian Ramacher wrote: >> On 2021-10-15 06:44:36 -0300, Antonio Terceiro wrote: >>> On Sat, Oct 02, 2021 at 03:14:39PM -0300, Antonio Terceiro wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition We would like to add support for ruby3.0 in ruby-defaults. Ben file: title = "ruby3.0-add"; is_affected = (.depends ~ /ruby2.7 | .depends ~ /ruby3.0/) & !.source ~ /^(ruby2.7|ruby3.0|ruby-defaults)$/); is_good = .depends ~ /ruby3.0/; is_bad = .depends ~ /ruby2.7/ & !.depends ~ /ruby3.0/; We already did a mass rebuild some time ago, and the results don't look bad. We should be doing a new one soon, and will come up with a list of binNMUs >>> >>> This is a friendly ping. We would like to make the switch in unstable >>> soon and start doing binNMUs. >>> >>> We have these bugs related to this transition: >>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby3.0;users=debian-r...@lists.debian.org >>> >>> Most of those bugs are for leaf libraries. We already started fixing the >>> ones that block a lof of other (e.g. the ones with C extensions that >>> FTBFS with ruby3.0) so they are ready to be binNMUed. >> >> ruby3.0 isn't in testing yet - it currently fails to build on ppc64el. >> So let's at least wait until it migrated. > > ruby3.0 is now in testing. Can we go ahead with this? There are 169 packages affected by the transition according to the tracker, the ruby3.0 usertag has 152 unresolved ftbfs bugreports. Does it really make sense to start this transition when most rdeps fail to build? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#994086: transition: netcdf
Testing still lacks a few rebuilt packages for this transition. labplot should migrated in two days. pymol will be rebuilt in unstable after it gets out the DELAYED according to #995666, although I don't see it at ftp://ftp.upload.debian.org/pub/UploadQueue/DELAYED/ magics++ & metkit are blocked by eckit which is no longer built on 32bit architectures, and is waiting for ftpmaster to act on #993624. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#994086: transition: netcdf
On 9/29/21 4:19 PM, Sebastiaan Couwenberg wrote: > On 9/29/21 10:02 AM, Sebastian Ramacher wrote: >> Please go ahead > > Thanks. netcdf (1:4.8.1-1) has been uploaded to unstable and is built & > installed on all release architectures. eccodes and gdal have been fixed, dependency level 3 can be binNMUed now. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#994086: transition: netcdf
On 9/29/21 10:02 AM, Sebastian Ramacher wrote: > Please go ahead Thanks. netcdf (1:4.8.1-1) has been uploaded to unstable and is built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
