Bug#986975: libgdal28: please add Breaks: libgdal20
Control: tags -1 moreinfo Hi Andreas, This issue cannot be fixed in bullseye because gdal cannot be updated via unstable. The release team is unlikely to unblock the package in unstable because it also has changes for 3.2.2 which was uploaded to unstable by mistake. The issue cannot be reproduced when only gdal-bin and its dependencies are installed. `apt full-upgrade` has no issues. When monteverdi is installed, after `apt upgrade && apt full-upgrade` apt finds a solution when the kept back packages are explicitly installed/upgraded. Shouldn't this issue be fixed in hdf5 since that causes the problem? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#986970: qgis: QGIS cannot detect installed OpenCL drivers unless `ocl-icd-opencl-dev` package is installed
On 4/14/21 9:36 PM, Pedro Ângelo wrote: > Sure, but isn't 3.10 the version going into next stable, or will 3.16 migrate > before release? See: https://lists.debian.org/debian-gis/2021/02/msg1.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#986572: unblock: osm2pgsql/1.4.1+ds-2 (pre-approval)
Control: trags -1 - moreinfo On 4/8/21 8:31 PM, Sebastian Ramacher wrote: > On 2021-04-07 16:17:45 +0200, Bas Couwenberg wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> To fix two important issues affecting the version in bullseye, >> I would like to upload these changes to unstable. >> >> Do you agree that these changes are appropriate for a freeze exception? > > Assuming that the upload happens soon, please go ahead. Please remove > the moreinfo tag once the version is available in unstable. Thanks for the feedback, the package was just uploaded to unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#986465: [Pkg-nagios-devel] Bug#986465: icinga2-bin: Add --close-stdio to systemd service file
The issue is fixed in git. Due to the freeze it won't be uploaded to unstable until after the bullseye release. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
On 3/31/21 7:30 PM, Lee Garrett wrote: > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried > getting the unit tests from 2.9.16 to work with python 3.9, but I had to give > up. I don't feel comfortable with maintaining such a large package over the > lifecycle of bullseye without unit tests, official py3.9 support, and security > support running out in a few months, so please remove ansible from bullseye. Shipping bullseye without ansible is going to make many users unhappy. Will you actively maintain the package in bullseye-backports instead? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#950167: [Pkg-nagios-devel] Bug#950167: icinga2-bin - Racy timeout in API: No data received on new API connection
On 3/27/21 8:22 PM, Jerome Charaoui wrote: > I also have this problem on a medium icinga2 installation, about 50 > hosts and 1 master. Every day almost, clients are intermittently losing > the connection to the master, it very annoying and seriously affecting > the useability of this package on buster. > > Disabling TLS 1.3 system-wide is not a workaround that we can deploy. I > don't think anyone should be doing that, either... > > Would it be possible to publish a backport to buster to fix this? With the release of bullseye on the horizon, that's probably not worth the effort. Why not rebuild the 2.12.3 package for buster yourself? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#985691: [Pkg-nagios-devel] Bug#985691: nagios-nrpe-server: Defaultcheck_load limits are unnecessarily low.
On 3/22/21 11:04 AM, Pavel Polacek wrote: > Important is that configuration comes from upstream, so I should try > to change upstream version. Yes, the default NRPE configuration should be fixed upstream. NRPE is deprecated however, so upstream won't work on this. https://raw.githubusercontent.com/NagiosEnterprises/nrpe/master/README.md Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983256: postgis: FTBFS with PROJ 8.0.0
Control: tags -1 fixed-upstream pending Upstream has two changes to fix this issue. Those have been added as patches to the package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983235: gnudatalanguage: FTBFS with PROJ 8.0.0
Control: tags -1 fixed-upstream Upstream merged changes to support proj.h: https://github.com/gnudatalanguage/gdl/commit/a9ce82083f04fdd4071513497508105dbe5581a6 -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#985404: qa.debian.org: Packages overview VCS field doesn't consider a debian/experimental branch
On 3/17/21 5:07 PM, Mattia Rizzolo wrote: > On Wed, Mar 17, 2021 at 05:05:15PM +0100, Andreas Ronnquist wrote: >> Ah, thanks. I was looking at python-cartopy but didn't notice that >> there gbp.conf is also updated with proper branch info for each branch. >> I guess that is why that package don't report a problem, and mine does. > > It's not about gbp.conf. src:python-cartopy has this in d/control: > Vcs-Git: https://salsa.debian.org/debian-gis-team/python-cartopy.git -b > experimental > note the "-b experimental". We update both when switching away from the master branch: https://salsa.debian.org/debian-gis-team/python-cartopy/-/commit/e8131f281c67a1e9b348051e06c654a91d4f3bdc And those commits get reverted when switching back. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983299: vtk9: FTBFS with PROJ 8.0.0
Control: tags -1 fixed-upstream Patch is available upstream: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7731 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#984428: release.debian.org: add list of (future) codenames
On 3/3/21 6:32 PM, Julian Andres Klode wrote: > I never have any idea what the codenames are, I know they are in a > release team announcement somewhere, but it would be great to just have > a list on release.debian.org, of future codenames, and maybe a couple > old ones too. It's already on the wiki: https://wiki.debian.org/DebianReleases#Production_Releases Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983875: sphinx-argparse: KeyError: 'prog'
On 3/2/21 4:48 PM, Bas Couwenberg wrote:
> This change in pytest_prog_name_varies.patch is the cause:
>
> --- sphinx-argparse.orig/sphinxarg/parser.py
> +++ sphinx-argparse/sphinxarg/parser.py
> @@ -37,7 +37,7 @@
> if not isinstance(attribval, str):
> return
> if len(attribval) > 0:
> -data[attribname] = attribval
> +data[attribname] = attribval % {'prog': data['prog']}
>
>
> def _format_usage_without_prefix(parser):
>
> Reverting this change fixes the issue.
>
> If the change is required for other cases, something like the following may
> be appropriate to fix the KeyError:
>
> if 'prog' in data:
> data[attribname] = attribval % {'prog': data['prog']}
> else:
> data[attribname] = attribval
There is another proposed patch upstream:
https://github.com/alex-rudakov/sphinx-argparse/pull/113#pullrequestreview-602011250
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983299: vtk9: FTBFS with PROJ 8.0.0
Control: tags -1 patch
On 2/25/21 1:49 PM, Sebastiaan Couwenberg wrote:
> On 2/22/21 7:29 AM, Bas Couwenberg wrote:
>> It needs to be ported to use proj.h instead of proj_api.h which has been
>> removed.
>
> While upstream has added support for proj.h this may not be easy to get
> into the vtk9 Debian package.
>
> Like with vtk6 (#931943) & vtk7 (#931943) you may want to use the
> embedded copy.
As reported in the upstream issue, vtk9 FTBFS when using only proj.h
because it still uses proj_api.h features.
The package will need to build with the embedded copy like the other vtk
packages as long as upstream doesn't support PROJ 8.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- a/debian/control
+++ b/debian/control
@@ -46,7 +46,6 @@ Build-Depends: chrpath,
libosmesa6-dev,
libpng-dev,
libpq-dev,
- libproj-dev,
libsqlite3-dev,
libswscale-dev,
libtheora-dev,
@@ -108,7 +107,6 @@ Depends: ${misc:Depends},
libnetcdf-dev,
libpng-dev,
libpq-dev,
- libproj-dev,
libpython3-dev,
libswscale-dev,
libtheora-dev,
--- a/debian/copyright
+++ b/debian/copyright
@@ -11,7 +11,6 @@ Files-Excluded:
ThirdParty/hdf5/vtkhdf5
ThirdParty/jpeg/vtkjpeg
ThirdParty/jsoncpp/vtkjsoncpp
- ThirdParty/libproj/vtklibproj
ThirdParty/libxml2/vtklibxml2
ThirdParty/lz4/vtklz4
ThirdParty/lzma/vtklzma
--- a/debian/rules
+++ b/debian/rules
@@ -48,7 +48,6 @@ extra_flags += \
-DVTK_MODULE_USE_EXTERNAL_VTK_hdf5:BOOL=ON \
-DVTK_MODULE_USE_EXTERNAL_VTK_jpeg:BOOL=ON \
-DVTK_MODULE_USE_EXTERNAL_VTK_jsoncpp:BOOL=ON \
- -DVTK_MODULE_USE_EXTERNAL_VTK_libproj:BOOL=ON \
-DVTK_MODULE_USE_EXTERNAL_VTK_libxml2:BOOL=ON \
-DVTK_MODULE_USE_EXTERNAL_VTK_lz4:BOOL=ON \
-DVTK_MODULE_USE_EXTERNAL_VTK_lzma:BOOL:BOOL=ON \
Bug#983210: atlas-ecmwf: FTBFS with PROJ 8.0.0
Control: tags -1 patch
On 2/21/21 7:23 AM, Bas Couwenberg wrote:
> Your package FTBFS with PROJ 8.0.0:
>
> /usr/include/proj.h:345:23: error: type alias redefinition with different
> types ('struct pj_ctx' vs 'struct projCtx_t') [clang-diagnostic-error]
> typedef struct pj_ctx PJ_CONTEXT;
>^
>
> /home/bas/tmp/debian/atlas-ecmwf-0.23.0/src/atlas/projection/detail/ProjProjection.h:23:7:
> note: previous definition is here
> using PJ_CONTEXT = struct projCtx_t;
>^
> 2156 warnings and 1 error generated.
> Error while processing
> /home/bas/tmp/debian/atlas-ecmwf-0.23.0/src/atlas/projection/detail/ProjProjection.cc.
The attached patch fixes the issue.
It's pretty much the same as the one for magics++ (#983236)
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- a/src/atlas/projection/detail/ProjProjection.cc
+++ b/src/atlas/projection/detail/ProjProjection.cc
@@ -9,10 +9,10 @@
*/
-#include "ProjProjection.h"
-
#include
+#include "ProjProjection.h"
+
#include "eckit/types/FloatCompare.h"
#include "eckit/utils/Hash.h"
--- a/src/atlas/projection/detail/ProjProjection.h
+++ b/src/atlas/projection/detail/ProjProjection.h
@@ -17,12 +17,14 @@
#include "atlas/util/Config.h"
+#if PROJ_VERSION_MAJOR < 8
extern "C" {
using PJ = struct PJconsts;
PJ* proj_destroy( PJ* );
using PJ_CONTEXT = struct projCtx_t;
PJ_CONTEXT* proj_context_destroy( PJ_CONTEXT* );
}
+#endif
namespace atlas {
Bug#983236: magics++: FTBFS with PROJ 8.0.0
Control: tags -1 patch
On 2/21/21 1:21 PM, Bas Couwenberg wrote:
> Your package FTBFS with PROJ 8.0.0:
>
> /usr/include/proj.h:123:4: error: #error "The proj_api.h header has been
> removed from PROJ with version 8.0.0"
>123 | #error "The proj_api.h header has been removed from PROJ with
> version 8.0.0"
>|^
> /usr/include/proj.h:345:23: error: conflicting declaration 'typedef struct
> pj_ctx PJ_CONTEXT'
>345 | typedef struct pj_ctx PJ_CONTEXT;
>| ^~
> In file included from /build/magics++-4.5.3/src/common/ProjP.cc:19:
> /build/magics++-4.5.3/src/common/ProjP.h:18:26: note: previous declaration
> as 'typedef struct projCtx_t PJ_CONTEXT'
> 18 | typedef struct projCtx_t PJ_CONTEXT;
>| ^~
> make[3]: *** [src/CMakeFiles/MagPlus.dir/build.make:4418:
> src/CMakeFiles/MagPlus.dir/common/ProjP.cc.o] Error 1
The problem is twofold.
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H is still defined in d/rules, which
triggers the first error. Since upstream uses proj.h, there is no need
for this any more. Apply the changes in magics++_4.5.3-1.1.debdiff to
fix this.
The second error is fixed by disabling the typedefs for the conflicting
declarations when PROJ_VERSION_MAJOR is >= 8. This is done by proj8.patch.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- magics++-4.5.3/debian/rules 2021-01-21 13:39:40.0 +0100
+++ magics++-4.5.3/debian/rules 2021-02-21 13:05:37.0 +0100
@@ -7,8 +7,8 @@
# To enable all, uncomment following line
# DEB_BUILD_MAINT_OPTIONS:= hardening=+all,-pie
-CXXFLAGS:= -fPIC $(shell dpkg-buildflags --get CXXFLAGS)
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H # -std=c++14
-CFLAGS:= -fPIC $(shell dpkg-buildflags --get CFLAGS)
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H=1
+CXXFLAGS:= -fPIC $(shell dpkg-buildflags --get CXXFLAGS) # -std=c++14
+CFLAGS:= -fPIC $(shell dpkg-buildflags --get CFLAGS)
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
# Set for build reproducibility
--- a/src/common/ProjP.h
+++ b/src/common/ProjP.h
@@ -14,8 +14,10 @@
#include "magics.h"
+#if PROJ_VERSION_MAJOR < 8
typedef struct PJconsts PJ;
typedef struct projCtx_t PJ_CONTEXT;
+#endif
namespace magics {
--- a/src/common/ProjP.cc
+++ b/src/common/ProjP.cc
@@ -16,8 +16,8 @@
Apr 06: update for GCC 4.0 (Stephan)
*/
-#include
#include
+#include
using namespace magics;
Bug#983299: vtk9: FTBFS with PROJ 8.0.0
On 2/22/21 7:29 AM, Bas Couwenberg wrote: > It needs to be ported to use proj.h instead of proj_api.h which has been > removed. While upstream has added support for proj.h this may not be easy to get into the vtk9 Debian package. Like with vtk6 (#931943) & vtk7 (#931943) you may want to use the embedded copy. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983345: therion: FTBFS with PROJ 8.0.0
On 2/24/21 11:29 AM, Sebastiaan Couwenberg wrote:
> On 2/24/21 10:59 AM, Sebastiaan Couwenberg wrote:
>> On 2/23/21 7:25 PM, Sebastiaan Couwenberg wrote:
>>> On 2/23/21 5:51 AM, Sebastiaan Couwenberg wrote:
>>>> On 2/22/21 11:42 PM, Wookey wrote:
>>>>> On 2021-02-22 18:23 +0100, Bas Couwenberg wrote:
>>>>>> Your package FTBFS with PROJ 8.0.0, it hung at `make samples`:
>>>>>> faketime "" /usr/bin/make samples
>>>>>
>>>>> This is an issue with faketime, which was added to make the package
>>>>> reproducible. For some reason I don't understand it works on the
>>>>> buildds bug hangs under a local sbuild build unless you do that build
>>>>> as root.
>>>>>
>>>>> Fiddling with Rule-Requires-Root doesn't seem to affect this.
>>>>>
>>>>> So I am pretty certain that this is an artifact of the way you are
>>>>> doing the build test, rather than a genuine issue with Proj v8.
>>>>>
>>>>> I would like to remove this issue because I have to remember to do
>>>>> builds as root. Knowing why it works OK on the real buildds would be
>>>>> helpful.
>>>>
>>>> You can close this issue as notfound if you can confirm that it builds
>>>> successfully with proj from experimental.
>>>>
>>>> I don't use sbuild. I used pdebuild with --use-pdebuild-internal to not
>>>> require the build dependencies outside the chroot for the clean target.
>>>
>>> Logging in to the chroot and building as root doesn't resolve the issue,
>>> sed still hangs.
>>
>> This change helps to not pass an empty string to faketime:
>>
>> --- a/debian/rules2021-01-04 03:47:31.0 +0100
>> +++ b/debian/rules2021-02-24 10:44:56.455089240 +0100
>> @@ -2,6 +2,8 @@
>>
>> export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs
>> export DH_VERBOSE=1
>> +export FAKETIME_DATE=$(shell dpkg-parsechangelog -S Date)
>> +
>> %:
>> dh $@
>>
>> @@ -11,7 +13,7 @@
>> # We need therion itself to build the samples
>> $(MAKE) therion
>> # create HTML documentation for samples
>> - faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples
>> + faketime "$(FAKETIME_DATE)" $(MAKE) samples
>> endif
>> $(MAKE) thbook
>>
>> Now we see:
>>
>> faketime "Sat, 06 Feb 2021 16:24:25 +" /usr/bin/make samples
>>
>> Instead of:
>>
>> faketime "" /usr/bin/make samples
>>
>> The build still hangs on the sed call to get the PROJ major version, though.
>
> If awk is used instead of sed like so:
>
> --- therion-5.5.7ds1.orig/Makefile
> +++ therion-5.5.7ds1/Makefile
> @@ -159,7 +159,7 @@ ifneq ($(filter $(PROJ_VER),$(PROJ_UNSUP
> $(error unsupported Proj version: $(PROJ_VER))
> endif
> PROJ_LIBS ?= $(shell $(CROSS)pkg-config proj --libs)
> -PROJ_MVER ?= $(shell echo $(PROJ_VER) | sed 's/\..*//')
> +PROJ_MVER ?= $(shell echo $(PROJ_VER) | awk -F. '{print $$1}')
> ifeq ($(shell [ "$(PROJ_MVER)" -gt 5 ] && [ "$(THPLATFORM)" = "WIN32" ]
> && [ -z "$(CROSS)" ]; echo $$?),0)
>PROJ_LIBS += -lsqlite3
> endif
>
> There is some progress, but then the build hangs with 100% CPU on:
>
> mkdir -p ./extern/poly2tri/sweep/
>
> It's proving hard to fix the arch-indep target.
Building only the binary-arch target works.
So there doesn't seem to be a PROJ 8 specific issue.
I'm not sure if closing this issue is appropriate as long as the
arch-indep issues have not been resolved.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983345: therion: FTBFS with PROJ 8.0.0
On 2/24/21 10:59 AM, Sebastiaan Couwenberg wrote:
> On 2/23/21 7:25 PM, Sebastiaan Couwenberg wrote:
>> On 2/23/21 5:51 AM, Sebastiaan Couwenberg wrote:
>>> On 2/22/21 11:42 PM, Wookey wrote:
>>>> On 2021-02-22 18:23 +0100, Bas Couwenberg wrote:
>>>>> Your package FTBFS with PROJ 8.0.0, it hung at `make samples`:
>>>>> faketime "" /usr/bin/make samples
>>>>
>>>> This is an issue with faketime, which was added to make the package
>>>> reproducible. For some reason I don't understand it works on the
>>>> buildds bug hangs under a local sbuild build unless you do that build
>>>> as root.
>>>>
>>>> Fiddling with Rule-Requires-Root doesn't seem to affect this.
>>>>
>>>> So I am pretty certain that this is an artifact of the way you are
>>>> doing the build test, rather than a genuine issue with Proj v8.
>>>>
>>>> I would like to remove this issue because I have to remember to do
>>>> builds as root. Knowing why it works OK on the real buildds would be
>>>> helpful.
>>>
>>> You can close this issue as notfound if you can confirm that it builds
>>> successfully with proj from experimental.
>>>
>>> I don't use sbuild. I used pdebuild with --use-pdebuild-internal to not
>>> require the build dependencies outside the chroot for the clean target.
>>
>> Logging in to the chroot and building as root doesn't resolve the issue,
>> sed still hangs.
>
> This change helps to not pass an empty string to faketime:
>
> --- a/debian/rules2021-01-04 03:47:31.0 +0100
> +++ b/debian/rules2021-02-24 10:44:56.455089240 +0100
> @@ -2,6 +2,8 @@
>
> export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs
> export DH_VERBOSE=1
> +export FAKETIME_DATE=$(shell dpkg-parsechangelog -S Date)
> +
> %:
> dh $@
>
> @@ -11,7 +13,7 @@
> # We need therion itself to build the samples
> $(MAKE) therion
> # create HTML documentation for samples
> - faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples
> + faketime "$(FAKETIME_DATE)" $(MAKE) samples
> endif
> $(MAKE) thbook
>
> Now we see:
>
> faketime "Sat, 06 Feb 2021 16:24:25 +" /usr/bin/make samples
>
> Instead of:
>
> faketime "" /usr/bin/make samples
>
> The build still hangs on the sed call to get the PROJ major version, though.
If awk is used instead of sed like so:
--- therion-5.5.7ds1.orig/Makefile
+++ therion-5.5.7ds1/Makefile
@@ -159,7 +159,7 @@ ifneq ($(filter $(PROJ_VER),$(PROJ_UNSUP
$(error unsupported Proj version: $(PROJ_VER))
endif
PROJ_LIBS ?= $(shell $(CROSS)pkg-config proj --libs)
-PROJ_MVER ?= $(shell echo $(PROJ_VER) | sed 's/\..*//')
+PROJ_MVER ?= $(shell echo $(PROJ_VER) | awk -F. '{print $$1}')
ifeq ($(shell [ "$(PROJ_MVER)" -gt 5 ] && [ "$(THPLATFORM)" = "WIN32" ]
&& [ -z "$(CROSS)" ]; echo $$?),0)
PROJ_LIBS += -lsqlite3
endif
There is some progress, but then the build hangs with 100% CPU on:
mkdir -p ./extern/poly2tri/sweep/
It's proving hard to fix the arch-indep target.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983345: therion: FTBFS with PROJ 8.0.0
On 2/23/21 7:25 PM, Sebastiaan Couwenberg wrote: > On 2/23/21 5:51 AM, Sebastiaan Couwenberg wrote: >> On 2/22/21 11:42 PM, Wookey wrote: >>> On 2021-02-22 18:23 +0100, Bas Couwenberg wrote: >>>> Your package FTBFS with PROJ 8.0.0, it hung at `make samples`: >>>> faketime "" /usr/bin/make samples >>> >>> This is an issue with faketime, which was added to make the package >>> reproducible. For some reason I don't understand it works on the >>> buildds bug hangs under a local sbuild build unless you do that build >>> as root. >>> >>> Fiddling with Rule-Requires-Root doesn't seem to affect this. >>> >>> So I am pretty certain that this is an artifact of the way you are >>> doing the build test, rather than a genuine issue with Proj v8. >>> >>> I would like to remove this issue because I have to remember to do >>> builds as root. Knowing why it works OK on the real buildds would be >>> helpful. >> >> You can close this issue as notfound if you can confirm that it builds >> successfully with proj from experimental. >> >> I don't use sbuild. I used pdebuild with --use-pdebuild-internal to not >> require the build dependencies outside the chroot for the clean target. > > Logging in to the chroot and building as root doesn't resolve the issue, > sed still hangs. This change helps to not pass an empty string to faketime: --- a/debian/rules2021-01-04 03:47:31.0 +0100 +++ b/debian/rules2021-02-24 10:44:56.455089240 +0100 @@ -2,6 +2,8 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs export DH_VERBOSE=1 +export FAKETIME_DATE=$(shell dpkg-parsechangelog -S Date) + %: dh $@ @@ -11,7 +13,7 @@ # We need therion itself to build the samples $(MAKE) therion # create HTML documentation for samples - faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples + faketime "$(FAKETIME_DATE)" $(MAKE) samples endif $(MAKE) thbook Now we see: faketime "Sat, 06 Feb 2021 16:24:25 +" /usr/bin/make samples Instead of: faketime "" /usr/bin/make samples The build still hangs on the sed call to get the PROJ major version, though. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
On 2/24/21 8:04 AM, Kai Pastor, DG0YT wrote: > Am 24.02.21 um 05:55 schrieb Sebastiaan Couwenberg: >> On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote: >>> Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: >>>> It's good practice to include the Find modules for any dependencies >>>> that >>>> are not part of cmake itself to not need upstream projects to install >>>> cmake modules for them. >>> I think it is deprecated legacy practice, not good practice. Find >>> modules are poorly standardized, poorly maintained, and poorly tested. >>> It would be much better to provide PROJ config files as soon as >>> possible, instead of letting more developers start using PROJ with >>> non-standard find modules picked from random internet locations. >>> >>> I wonder if there is a blocker for building debian PROJ with CMake. I >>> build PROJ for Android, macOS, Windows from Debian tarballs - with >>> cmake, not using debian/rules. >>> https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake >>> >> Switching from autotools to cmake is generally a regression, cmake >> doesn't handle multiarch as well, and because it uses absolute paths >> instead of relative paths it hinders reproducible builds. >> >> See the recent discussion on the geos-devel lists for example: >> >> https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html > > From the mailing list post and its links I learn that > > a) actively maintained projects do fix reported build system issues > quickly. > > b) there is some confusion about dealing with CMAKE_BUILD_TYPE, NDEBUG > and reproducible paths. > > I would agree that many projects have shortcoming in how they use CMake, > partly due to past shortcomings of CMake and its documentation, partly > due to ignorance of cross-platform building and packaging. But IMO it > goes to far when you imply that CMake is to blame for issues with paths > and reproducibility. CMake uses abolute paths, whereas autotools uses relative paths. How is CMake not to blame from issues that arise from that? > (Is there a Debian documentation for how to prepare CMake projects to > help with Debian multi-arch?) No that I know of, it would be good to have this in the upstream guide: https://wiki.debian.org/UpstreamGuide FWIW cmake/ProjInstallPath.cmake uses CMAKE_INSTALL_LIBDIR so it would do the right thing. >>> The CMake build of PROJ doesn't seem to provide a pkgconfig file, but >>> even for mips64el, the single proj.pc looks much less complex than the >>> set of cmake config files, or the patch proposed for FindProj4.cmake. >> We're not going to switch to cmake for the proj package as long as >> autotools is supported, because that is the best build system from a >> packaging point of view. > > Okay, so this covers your packaging point of view where autotools are > already available. But it doesn't align with my requirements as a > developer, and also not with my experience in single-arch > bundling/packaging third-party components for Android, macOS, Windows. > > (And I wouldn't even say that CMake is the best system for some purpose.) PROJ supports CMake in addition to autotools for platforms like Windows for similar reasons. You're not the only upstream who is unhappy that the proj package in Debian doesn't install the CMake bits, and as explained to support projects using CMake better PROJ should also install the cmake bits when it's built with Autotools. No one has been willing to implement that so far. That is the problem we need to solve. At least there is an upstream issue for it now: https://github.com/OSGeo/PROJ/issues/2546 >> The best solution for downstream projects not wanting to include their >> own FindProj modules is to update the autotools build system to also >> install the cmake bits. Perhaps you can provide a patch for that which >> PROJ upstream can merge? > > No, I don't think learning autotools and then teaching autotools to > provide CMake config files, possibly for multi-arch, is a good use of my > resources. But you may ask for patches for PROJ's CMake build system. > Multiarch if I can test/verify in an amd_64 environment. Since your more comfortable with CMake, maybe you can help upstream the pkg-config patch so that the Fedora package doesn't have to patch the CMake build to have proj.pc installed. We really need to get downstream projects more involved in PROJ development to help support their needs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote: > Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: >> It's good practice to include the Find modules for any dependencies that >> are not part of cmake itself to not need upstream projects to install >> cmake modules for them. > > I think it is deprecated legacy practice, not good practice. Find > modules are poorly standardized, poorly maintained, and poorly tested. > It would be much better to provide PROJ config files as soon as > possible, instead of letting more developers start using PROJ with > non-standard find modules picked from random internet locations. > > I wonder if there is a blocker for building debian PROJ with CMake. I > build PROJ for Android, macOS, Windows from Debian tarballs - with > cmake, not using debian/rules. > https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake Switching from autotools to cmake is generally a regression, cmake doesn't handle multiarch as well, and because it uses absolute paths instead of relative paths it hinders reproducible builds. See the recent discussion on the geos-devel lists for example: https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html > The CMake build of PROJ doesn't seem to provide a pkgconfig file, but > even for mips64el, the single proj.pc looks much less complex than the > set of cmake config files, or the patch proposed for FindProj4.cmake. We're not going to switch to cmake for the proj package as long as autotools is supported, because that is the best build system from a packaging point of view. The best solution for downstream projects not wanting to include their own FindProj modules is to update the autotools build system to also install the cmake bits. Perhaps you can provide a patch for that which PROJ upstream can merge? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983327: qgis: FTBFS with PROJ 8.0.0
Control: tags -1 fixed-upstream https://github.com/qgis/QGIS/commit/fc1ac8bef8dcc3194857ecd32519aca4867b4fa1 -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
On 2/23/21 7:47 PM, Kai Pastor, DG0YT wrote: > Am 21.02.21 um 16:32 schrieb Bas Couwenberg: >> Source: openorienteering-mapper >> Version: 0.9.4-2 >> Severity: important >> Tags: upstream ftbfs >> User: debian-...@lists.debian.org >> Usertags: proj-8.0 >> Control: forwarded -1 >> https://github.com/OpenOrienteering/mapper/issues/1214 >> >> Dear Maintainer, >> >> Your package FTBFS with PROJ 8.0.0: >> >> CMake Error at >> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 >> (message): >> Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR) >> >> It needs to be ported to use proj.h instead of proj_api.h which has >> been removed. >> >> Kind Regards, >> >> Bas > > Mapper source code is ported to use proj.h for modern PROJ. However, the > embedded fallback FindPROJ4.cmake module isn't, and possible won't. A patch for that was just submitted to this bugreport. > Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide > the cmake config files for PROJ. That's an upstream issue with PROJ. When it's built with autotools it doesn't install the cmake bits, it only does so when it's built with cmake. It's good practice to include the Find modules for any dependencies that are not part of cmake itself to not need upstream projects to install cmake modules for them. > openorienteering-mapper is meant to > pick up these config files. If it finds a recent PROJ in that way, it > won't use proj_api.h. Either way the FindPROJ4.cmake included in openorienteering-mapper needs to be updated to support PROJ 8: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=983254;filename=proj8.patch;msg=12 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983345: therion: FTBFS with PROJ 8.0.0
On 2/23/21 5:51 AM, Sebastiaan Couwenberg wrote: > On 2/22/21 11:42 PM, Wookey wrote: >> On 2021-02-22 18:23 +0100, Bas Couwenberg wrote: >>> Your package FTBFS with PROJ 8.0.0, it hung at `make samples`: >>> faketime "" /usr/bin/make samples >> >> This is an issue with faketime, which was added to make the package >> reproducible. For some reason I don't understand it works on the >> buildds bug hangs under a local sbuild build unless you do that build >> as root. >> >> Fiddling with Rule-Requires-Root doesn't seem to affect this. >> >> So I am pretty certain that this is an artifact of the way you are >> doing the build test, rather than a genuine issue with Proj v8. >> >> I would like to remove this issue because I have to remember to do >> builds as root. Knowing why it works OK on the real buildds would be >> helpful. > > You can close this issue as notfound if you can confirm that it builds > successfully with proj from experimental. > > I don't use sbuild. I used pdebuild with --use-pdebuild-internal to not > require the build dependencies outside the chroot for the clean target. Logging in to the chroot and building as root doesn't resolve the issue, sed still hangs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 root 22506 0.0 0.1 18944 16252 pts/3S+ 19:09 0:00 \_ /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc root 22840 0.0 0.0 2968 2260 pts/3S+ 19:09 0:00 | \_ /usr/bin/make -f debian/rules binary root 22841 0.0 0.1 16380 13708 pts/3S+ 19:09 0:00 | \_ /usr/bin/perl /usr/bin/dh binary root 28057 0.0 0.0 2972 2068 pts/3S+ 19:15 0:00 | \_ /usr/bin/make -f debian/rules override_dh_auto_build-indep root 28082 0.0 0.0 2728 628 pts/3S+ 19:15 0:00 | \_ /bin/sh -c faketime "" /usr/bin/make samples root 28083 0.0 0.0 2796 1928 pts/3S+ 19:15 0:00 | \_ faketime /usr/bin/make samples root 28085 0.0 0.0 4524 2856 pts/3S+ 19:15 0:00 | \_ /usr/bin/make samples root 28088 0.0 0.0 4280 1980 pts/3S+ 19:15 0:00 | \_ /bin/sh -c echo 8.0.0 | sed 's/\..*//' root 28090 97.2 0.0 4848 2412 pts/3R+ 19:15 5:50 | \_ sed s/\..*// root 22507 0.0 0.0 2636 548 pts/3S+ 19:09 0:00 \_ tee ../therion.build
Bug#983383: qgis-server-common: missing Breaks+Replaces: qgis-server (<< 3.16)
Control: tags -1 pending Hi Andreas, Thanks for reporting this issue, it's fixed in git. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983345: therion: FTBFS with PROJ 8.0.0
On 2/22/21 11:42 PM, Wookey wrote: > On 2021-02-22 18:23 +0100, Bas Couwenberg wrote: >> Your package FTBFS with PROJ 8.0.0, it hung at `make samples`: >> faketime "" /usr/bin/make samples > > This is an issue with faketime, which was added to make the package > reproducible. For some reason I don't understand it works on the > buildds bug hangs under a local sbuild build unless you do that build > as root. > > Fiddling with Rule-Requires-Root doesn't seem to affect this. > > So I am pretty certain that this is an artifact of the way you are > doing the build test, rather than a genuine issue with Proj v8. > > I would like to remove this issue because I have to remember to do > builds as root. Knowing why it works OK on the real buildds would be helpful. You can close this issue as notfound if you can confirm that it builds successfully with proj from experimental. I don't use sbuild. I used pdebuild with --use-pdebuild-internal to not require the build dependencies outside the chroot for the clean target. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983212: libgeotiff: FTBFS with PROJ 8.0.0
Control: tags -1 fixed-upstream https://github.com/OSGeo/libgeotiff/commit/622a4b2ac416d5907fe00025ace50f31729e55ed -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#982698: python-pyproj: FTBFS: KeyError: 'prog'
Control: tags -1 pending
On 2/13/21 6:28 PM, Lucas Nussbaum wrote:
>> Exception occurred:
>> File "/usr/lib/python3/dist-packages/sphinxarg/parser.py", line 40, in
>> _try_add_parser_attribute
>> data[attribname] = attribval % {'prog': data['prog']}
>> KeyError: 'prog'
>> The full traceback has been saved in /tmp/sphinx-err-50pn8sk5.log, if you
>> want to report the issue to the developers.
>> Please also report this if it was a user error, so that a better error
>> message can be provided next time.
>> A bug report can be filed in the tracker at
>> . Thanks!
>> make[2]: *** [Makefile:20: man] Error 2
This seems to be caused by the recent update of sphinx-argparse.
Sine it's not clear how to fix this issue, building the docs has been
removed.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#982732: librasterlite2: FTBFS: ld: cannot find -lfreexl
Control: reassign -1 src:spatialite
Control: found -1 spatialite/5.0.1-1
Control: affects -1 src:librasterlite2
Control: tags -1 pending
On 2/13/21 6:04 PM, Lucas Nussbaum wrote:
>> /usr/bin/ld: cannot find -lfreexl
>> /usr/bin/ld: cannot find -lgeos_c
This is caused by spatialite exposing the following via pkgconfig:
Libs: -L${libdir} -lspatialite -lminizip -lrttopo -lfreexl -lproj \
-lsqlite3 -lz -lsqlite3 \
-L/usr/lib/x86_64-linux-gnu -lgeos_c -lxml2 -lm
Not all of these libraries were pulled in via the libspatialite-dev
dependencies. This has been fixed in git.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#982583: cftime: annotate test dependencies
Control: tags -1 pending Hi Helmut, Thanks for the patch, it's applied in git. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#978099: libhdf4: Please add support for riscv64
On 2/5/21 7:10 AM, Graham Inggs wrote: > Any chance of an upload soon? No, riscv64 is not a release architecture and the soft freeze is next week. Ubuntu will have to carry this patch a little longer. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#981725: libdap-dev no longer provides dap-config
reopen 981725 notfixed 981725 libdap/3.20.7-5 thanks On 2/4/21 5:39 AM, Sebastiaan Couwenberg wrote: > On 2/3/21 12:37 PM, Sebastiaan Couwenberg wrote: >> On 2/3/21 12:03 PM, Sebastiaan Couwenberg wrote: >>> On 2/3/21 10:48 AM, Gianfranco Costamagna wrote: >>>> Hello, the new libdap broke in some way the gdal configure script, and now >>>> the configure step fails with: >>>> >>>> checking for libqhull/libqhull.h... yes >>>> checking for qh_new_qhull in -lqhull... no >>>> configure: error: --with-qhull requested, but library not found! >>>> >>>> >>>> I don't really understand what is going on here, looks like qhull is not >>>> found anymore. >>>> >>>> libdap might be the library to blame here, feel free to reassign if needed >>> >>> libdap-dev no longer provides /usr/bin/dap-config, gdal configure then >>> adds dap++ to LIBS which breaks the compile test for qhull. >>> >>> dap-config should really be provided by libdap-dev instead of >>> libdap-bin. Or libdap-bin needs to be a dependency of libdap-dev. >> >> This is also the cause of the autopkgtest failure which prevents testing >> migration: >> >> Test-Command: set -e >>; dap-config --help 2> /dev/null >> Depends: libdap-dev >> >> The attached patch should fix the issue. > > The patch has been updated with the changed from -4. > > To clarify the issue: > > Moving dap-config* from libdap-dev to libdap-bin is wrong, > from the Debian Library Packaging guide: > > " > -DEV package (e.g. libfooX-dev) should contain the development symlink > used when linking, static libraries, and header files, and if they > exist, package configuration scripts. > > Table 4.1. Annotated list of files that usually reside in -DEV package > > +--+ > |files |meaning| > |--+---| > |usr/lib/*.so |development linkage file, used when other | > | |programs are linked with -lxxx | > |--+---| > |usr/lib/*.a |static link files | > |--+---| > |usr/lib/*.la |libtool linkage information file | > |--+---| > |usr/include/* |Development include files | > |--+---| > |usr/bin/*-config |Some configuration script used in obtaining| > | |the library paths, like gtk-config | > |--+-- | > |usr/lib/pkgconfig/*.pc|Some information required for pkgconfig| > +--+ > " > > https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952 > > Alastair, if you won't move dap-config* back to the -dev package (e.g. > by applying the attached patch), you must add Depends: libdap-bin to > libdap-dev to have dap-config available when installing libdap-dev. Alastair, you should have applied the patch, the changes in -5 are not sufficient: * debian/control ** libdap-dev lacks: Breaks: libdap-bin (<< 3.20.7-5~) Replaces: libdap-bin (<< 3.20.7-5~) These need to be added. ** libdap-doc still has erroneous Breaks/Replaces: Breaks: libdap-dev (<< 3.20.7) Replaces: libdap-dev (<< 3.20.7) These need to be removed. * debian/libdap-bin.install Still includes: usr/bin/dap-config-pkgconfig usr/share/man/man1/dap-config.1 These should move to libdap-dev.install too. * debian/rules Installs debian/dap-config.pkg in libdap-bin via override_dh_installdocs. It should be installed in override_dh_auto_install. Now the upstream dap-config is included in libdap-dev and the debian one in libdap-bin creating a conflict. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#981725: libdap-dev no longer provides dap-config
On 2/3/21 12:37 PM, Sebastiaan Couwenberg wrote:
> On 2/3/21 12:03 PM, Sebastiaan Couwenberg wrote:
>> On 2/3/21 10:48 AM, Gianfranco Costamagna wrote:
>>> Hello, the new libdap broke in some way the gdal configure script, and now
>>> the configure step fails with:
>>>
>>> checking for libqhull/libqhull.h... yes
>>> checking for qh_new_qhull in -lqhull... no
>>> configure: error: --with-qhull requested, but library not found!
>>>
>>>
>>> I don't really understand what is going on here, looks like qhull is not
>>> found anymore.
>>>
>>> libdap might be the library to blame here, feel free to reassign if needed
>>
>> libdap-dev no longer provides /usr/bin/dap-config, gdal configure then
>> adds dap++ to LIBS which breaks the compile test for qhull.
>>
>> dap-config should really be provided by libdap-dev instead of
>> libdap-bin. Or libdap-bin needs to be a dependency of libdap-dev.
>
> This is also the cause of the autopkgtest failure which prevents testing
> migration:
>
> Test-Command: set -e
>; dap-config --help 2> /dev/null
> Depends: libdap-dev
>
> The attached patch should fix the issue.
The patch has been updated with the changed from -4.
To clarify the issue:
Moving dap-config* from libdap-dev to libdap-bin is wrong,
from the Debian Library Packaging guide:
"
-DEV package (e.g. libfooX-dev) should contain the development symlink
used when linking, static libraries, and header files, and if they
exist, package configuration scripts.
Table 4.1. Annotated list of files that usually reside in -DEV package
+--+
|files |meaning|
|--+---|
|usr/lib/*.so |development linkage file, used when other |
| |programs are linked with -lxxx |
|--+---|
|usr/lib/*.a |static link files |
|--+---|
|usr/lib/*.la |libtool linkage information file |
|--+---|
|usr/include/* |Development include files |
|--+---|
|usr/bin/*-config |Some configuration script used in obtaining|
| |the library paths, like gtk-config |
|--+-- |
|usr/lib/pkgconfig/*.pc|Some information required for pkgconfig|
+--+
"
https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952
Alastair, if you won't move dap-config* back to the -dev package (e.g.
by applying the attached patch), you must add Depends: libdap-bin to
libdap-dev to have dap-config available when installing libdap-dev.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
diff -Nru libdap-3.20.7/debian/changelog libdap-3.20.7/debian/changelog
--- libdap-3.20.7/debian/changelog 2021-02-03 13:27:57.0 +0100
+++ libdap-3.20.7/debian/changelog 2021-02-04 05:07:14.0 +0100
@@ -1,3 +1,11 @@
+libdap (3.20.7-5) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Move usr/bin/dap-config* back to libdap-dev.
+(closes: #981725)
+
+ -- Bas Couwenberg Thu, 04 Feb 2021 05:07:14 +0100
+
libdap (3.20.7-4) unstable; urgency=medium
* Update dependencies on autopkgtests to libdap-bin
diff -Nru libdap-3.20.7/debian/control libdap-3.20.7/debian/control
--- libdap-3.20.7/debian/control2021-02-03 13:27:57.0 +0100
+++ libdap-3.20.7/debian/control2021-02-04 05:07:14.0 +0100
@@ -94,6 +94,8 @@
Architecture: any
Multi-Arch: same
Depends: libdap27 ( = ${binary:Version} ), libdapserver7v5
(=${binary:Version}), libdapclient6v5 (=${binary:Version}) , ${misc:Depends},
libxml2-dev, libcurl4-gnutls-dev | libcurl-dev, uuid-dev, pkg-config
+Breaks: libdap-bin (<< 3.20.7-5~)
+Replaces: libdap-bin (<< 3.20.7-5~)
Description: Development files (headers and static libraries) for libdap
OPeNDAP provides software that allows you to access data over the internet,
from programs that weren't originally designed for that purpose, as well
@@ -109,8 +111,6 @@
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}, libjs-jquery
-Breaks: libdap-dev (<< 3.20.7)
-Replaces: libdap-dev (<< 3.20.7)
Description: Documentation for the libdap Data Access Protocol
Bug#981725: gdal: FTBFS after new libdap
Control: tags -1 patch
On 2/3/21 12:03 PM, Sebastiaan Couwenberg wrote:
> On 2/3/21 10:48 AM, Gianfranco Costamagna wrote:
>> Hello, the new libdap broke in some way the gdal configure script, and now
>> the configure step fails with:
>>
>> checking for libqhull/libqhull.h... yes
>> checking for qh_new_qhull in -lqhull... no
>> configure: error: --with-qhull requested, but library not found!
>>
>>
>> I don't really understand what is going on here, looks like qhull is not
>> found anymore.
>>
>> libdap might be the library to blame here, feel free to reassign if needed
>
> libdap-dev no longer provides /usr/bin/dap-config, gdal configure then
> adds dap++ to LIBS which breaks the compile test for qhull.
>
> dap-config should really be provided by libdap-dev instead of
> libdap-bin. Or libdap-bin needs to be a dependency of libdap-dev.
This is also the cause of the autopkgtest failure which prevents testing
migration:
Test-Command: set -e
; dap-config --help 2> /dev/null
Depends: libdap-dev
The attached patch should fix the issue.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
diff -Nru libdap-3.20.7/debian/changelog libdap-3.20.7/debian/changelog
--- libdap-3.20.7/debian/changelog 2021-02-02 10:45:43.0 +0100
+++ libdap-3.20.7/debian/changelog 2021-02-03 12:11:55.0 +0100
@@ -1,3 +1,11 @@
+libdap (3.20.7-4) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Move usr/bin/dap-config* back to libdap-dev.
+(closes: #981725)
+
+ -- Bas Couwenberg Wed, 03 Feb 2021 12:11:55 +0100
+
libdap (3.20.7-3) unstable; urgency=medium
* Add Breaks/Replaces libdap-bin on libdap-dev. for dap-config, which
diff -Nru libdap-3.20.7/debian/control libdap-3.20.7/debian/control
--- libdap-3.20.7/debian/control2021-02-02 10:32:16.0 +0100
+++ libdap-3.20.7/debian/control2021-02-03 12:11:55.0 +0100
@@ -94,6 +94,8 @@
Architecture: any
Multi-Arch: same
Depends: libdap27 ( = ${binary:Version} ), libdapserver7v5
(=${binary:Version}), libdapclient6v5 (=${binary:Version}) , ${misc:Depends},
libxml2-dev, libcurl4-gnutls-dev | libcurl-dev, uuid-dev, pkg-config
+Breaks: libdap-bin (<< 3.20.7-4~)
+Replaces: libdap-bin (<< 3.20.7-4~)
Description: Development files (headers and static libraries) for libdap
OPeNDAP provides software that allows you to access data over the internet,
from programs that weren't originally designed for that purpose, as well
@@ -109,8 +111,6 @@
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}, libjs-jquery
-Breaks: libdap-dev (<< 3.20.7)
-Replaces: libdap-dev (<< 3.20.7)
Description: Documentation for the libdap Data Access Protocol library
OPeNDAP provides software that allows you to access data over the internet,
from programs that weren't originally designed for that purpose, as well
diff -Nru libdap-3.20.7/debian/libdap-bin.install
libdap-3.20.7/debian/libdap-bin.install
--- libdap-3.20.7/debian/libdap-bin.install 2021-02-02 10:32:16.0
+0100
+++ libdap-3.20.7/debian/libdap-bin.install 2021-02-03 12:08:16.0
+0100
@@ -1,7 +1,4 @@
usr/bin/getdap
usr/bin/getdap4
-usr/bin/dap-config-pkgconfig
-usr/bin/dap-config
-usr/share/man/man1/dap-config.1
usr/share/man/man1/getdap4.1
usr/share/man/man1/getdap.1
diff -Nru libdap-3.20.7/debian/libdap-dev.install
libdap-3.20.7/debian/libdap-dev.install
--- libdap-3.20.7/debian/libdap-dev.install 2021-02-02 10:32:16.0
+0100
+++ libdap-3.20.7/debian/libdap-dev.install 2021-02-03 12:08:40.0
+0100
@@ -1,3 +1,6 @@
+usr/bin/dap-config-pkgconfig
+usr/bin/dap-config
+usr/share/man/man1/dap-config.1
usr/lib/*/pkgconfig/*.pc
usr/lib/*/*.so
usr/lib/*/*.a
diff -Nru libdap-3.20.7/debian/rules libdap-3.20.7/debian/rules
--- libdap-3.20.7/debian/rules 2021-02-02 10:32:16.0 +0100
+++ libdap-3.20.7/debian/rules 2021-02-03 12:11:55.0 +0100
@@ -34,6 +34,8 @@
override_dh_auto_install:
dh_auto_install
+ # Allow this cp to fail on arch-independent builds
+ -cp debian/dap-config.pkg debian/libdap-dev/usr/bin/dap-config
override_dh_installdocs:
dh_installdocs
@@ -42,8 +44,6 @@
ln -sf /usr/share/javascript/jquery/jquery.js
debian/libdap-doc/usr/share/doc/libdap-doc/html/jquery.js ) \
|| echo "Skipped; no jquery"
-find debian/libdap-doc -name '*.md5' -delete \;
- # Allow this cp to fail on arch-independent builds
- -cp debian/dap-config.pkg debian/libdap-bin/usr/bin/dap-config
clean:
dh clean
Bug#981725: gdal: FTBFS after new libdap
reassign -1 src:libdap found -1 libdap/3.20.7-1 retitle -1 libdap-dev no longer provides dap-config affects -1 src:gdal thanks On 2/3/21 10:48 AM, Gianfranco Costamagna wrote: > Hello, the new libdap broke in some way the gdal configure script, and now > the configure step fails with: > > checking for libqhull/libqhull.h... yes > checking for qh_new_qhull in -lqhull... no > configure: error: --with-qhull requested, but library not found! > > > I don't really understand what is going on here, looks like qhull is not > found anymore. > > libdap might be the library to blame here, feel free to reassign if needed libdap-dev no longer provides /usr/bin/dap-config, gdal configure then adds dap++ to LIBS which breaks the compile test for qhull. dap-config should really be provided by libdap-dev instead of libdap-bin. Or libdap-bin needs to be a dependency of libdap-dev. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#981725: gdal: FTBFS after new libdap
On 2/3/21 10:48 AM, Gianfranco Costamagna wrote: > Hello, the new libdap broke in some way the gdal configure script, and now > the configure step fails with: > > checking for libqhull/libqhull.h... yes > checking for qh_new_qhull in -lqhull... no > configure: error: --with-qhull requested, but library not found! > > > I don't really understand what is going on here, looks like qhull is not > found anymore. > > libdap might be the library to blame here, feel free to reassign if needed The changes in libdap are most likely the cause, previously libdap-dev did not provide /usr/bin/dap-config which it does now. Now gdal uses dap-config instead of detecting libdap itself. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#981605: protozero: annotate test dependencies
Control: tags -1 pending Hi Helmut, Thanks for the patch, it's applied in git. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#981172: [Pkg-nagios-devel] Bug#981172: nagios-plugins-contrib - check_haproxy_stats shebang line in script wrong
fixed 981172 nagios-plugins-contrib/25.20191015+2 close 981172 thanks This is fixed in nagios-plugins-contrib (25.20191015+2), which is also available in backports: $ head -1 /tmp/monitoring-plugins-contrib_28.20201207~bpo10+1_amd64/usr/lib/nagios/plugins/check_haproxy_stats #!/usr/bin/perl Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#980339: pyosmium: drop unused Build-Depends
Control: tags -1 pending Fixed in git, probably won't be uploaded any time soon though. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#979638: gpsprune: fails to start because of missing resources (texts)
Control: tags -1 pending On 1/9/21 5:58 PM, activityworkshop wrote: > After upgrade from 20 to 20.1 using stable-backports, GpsPrune now fails to > start from the main menu. > When started directly from the console, it gives the following error: > > $/usr/bin/gpsprune > Exception in thread "main" java.util.MissingResourceException: Can't find > bundle for base name tim.prune.lang.prune-texts > > It seems that all the translation files under tim/prune/lang are not present > in the jar /usr/share/gpsprune/gpsprune.jar > although they are visible here: > https://sources.debian.org/src/gpsprune/20.1-1/tim/prune/lang/ > so I guess this is just a build / packaging problem? Yes, see: #945917 which, while fixed in bullseye & unstable with javatools (0.72.11), is still present in buster with javatools (0.72.9). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#979026: r-cran-rgdal: autopkgtest failure with PROJ 7.2.1
Control: tags -1 patch
On 1/2/21 9:42 AM, Sebastiaan Couwenberg wrote:
> On 1/2/21 6:54 AM, Bas Couwenberg wrote:
>> The autopkgtest of your package fail with PROJ 7.2.1:
>>
>> Error: isTRUE(all.equal(a, matrix(c(-5.917698, -1.87195), ncol = 2),
>> is not TRUE
>> Execution halted
>> autopkgtest [23:01:36]: test run-unit-test: ---]
>> autopkgtest [23:01:36]: test run-unit-test: - - - - - - - - - - results -
>> - - - - - - - - -
>> run-unit-testFAIL non-zero exit status 1
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rgdal/9312472/log.gz
>>
>> This appears to be an issue with how upstream uses PROJ incorrectly,
>> as discussed on the PROJ list:
>>
>> https://lists.osgeo.org/pipermail/proj/2020-December/010014.html
>>
>> Upstream doesn't appear to have a public VCS, so it's unclear if the fix
>> posted on the PROJ list can be easily turned into a patch for the Debian
>> package.
>
> Further investigation shows PROJ 7.2.1 related commits at:
>
> https://github.com/r-forge/rgdal/commits/master
This issue is fixed when added the relevant upstream patches, as per the
attached debdiff.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
diff -Nru r-cran-rgdal-1.5-18+dfsg/debian/changelog
r-cran-rgdal-1.5-18+dfsg/debian/changelog
--- r-cran-rgdal-1.5-18+dfsg/debian/changelog 2020-10-15 16:39:00.0
+0200
+++ r-cran-rgdal-1.5-18+dfsg/debian/changelog 2021-01-04 07:32:27.0
+0100
@@ -1,3 +1,11 @@
+r-cran-rgdal (1.5-18+dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream patches for PROJ 7.2.1 compatibility.
+(closes: #979026)
+
+ -- Bas Couwenberg Mon, 04 Jan 2021 07:32:27 +0100
+
r-cran-rgdal (1.5-18+dfsg-1) unstable; urgency=medium
* New upstream version
diff -Nru r-cran-rgdal-1.5-18+dfsg/debian/patches/series
r-cran-rgdal-1.5-18+dfsg/debian/patches/series
--- r-cran-rgdal-1.5-18+dfsg/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ r-cran-rgdal-1.5-18+dfsg/debian/patches/series 2021-01-04
07:32:06.0 +0100
@@ -0,0 +1,4 @@
+svn-r1086.patch
+svn-r1087.patch
+svn-r1088.patch
+svn-r1089.patch
diff -Nru r-cran-rgdal-1.5-18+dfsg/debian/patches/svn-r1086.patch
r-cran-rgdal-1.5-18+dfsg/debian/patches/svn-r1086.patch
--- r-cran-rgdal-1.5-18+dfsg/debian/patches/svn-r1086.patch 1970-01-01
01:00:00.0 +0100
+++ r-cran-rgdal-1.5-18+dfsg/debian/patches/svn-r1086.patch 2021-01-04
07:32:08.0 +0100
@@ -0,0 +1,195 @@
+From 9312ef56d9158f5e3a520c733e7b7a9049e41a89 Mon Sep 17 00:00:00 2001
+From: rsbivand
+Date: Tue, 29 Dec 2020 14:58:22 +
+Subject: [PATCH] adapt ob_tran for PROJ > 7.2.0
+
+git-svn-id: svn://svn.r-forge.r-project.org/svnroot/rgdal@1086
edb9625f-4e0d-4859-8d74-9fd3b1da38cb
+
+--- a/DESCRIPTION
b/DESCRIPTION
+@@ -1,7 +1,7 @@
+ Package: rgdal
+ Title: Bindings for the 'Geospatial' Data Abstraction Library
+ Version: 1.5-18
+-Date: 2020-10-08
++Date: 2020-12-29
+ Depends: R (>= 3.5.0), methods, sp (>= 1.1-0)
+ Imports: grDevices, graphics, stats, utils
+ LinkingTo: sp
+--- a/R/project.R
b/R/project.R
+@@ -249,7 +249,7 @@ OSRIsProjected <- function(obj) {
+ }
+ }
+ coordOp <- .Call("project_ng_coordOp", proj,
+-as.logical(inv), aoi, PACKAGE="rgdal")
++as.logical(inv), aoi, as.logical(use_ob_tran),
PACKAGE="rgdal")
+ }
+ if (verbose) cat(strwrap(coordOp), sep="\n")
+ res <- .Call("project_ng",
+@@ -442,7 +442,7 @@ if (!isGeneric("spTransform"))
+ else use_ob_tran1 <- TRUE
+ if (is.null(coordOp)) {
+ out_coordOp <- .Call("project_ng_coordOp", proj,
+-as.logical(inv), NULL, #as.logical(use_ob_tran1),
++as.logical(inv), NULL, as.logical(use_ob_tran1),
+ PACKAGE="rgdal")
+ }
+ res <- .Call("project_ng", as.integer(n),
+@@ -484,7 +484,7 @@ if (!isGeneric("spTransform"))
+ else use_ob_tran1 <- TRUE
+ if (is.null(coordOp)) {
+ out_coordOp <- .Call("project_ng_coordOp", proj,
+-as.logical(inv), NULL, #as.logical(use_ob_tran1),
++as.logical(inv), NULL, as.logical(use_ob_tran1),
+ PACKAGE="rgdal")
+ }
+ res <- .Call("p
Bug#979026: r-cran-rgdal: autopkgtest failure with PROJ 7.2.1
On 1/2/21 6:54 AM, Bas Couwenberg wrote: > The autopkgtest of your package fail with PROJ 7.2.1: > > Error: isTRUE(all.equal(a, matrix(c(-5.917698, -1.87195), ncol = 2), > is not TRUE > Execution halted > autopkgtest [23:01:36]: test run-unit-test: ---] > autopkgtest [23:01:36]: test run-unit-test: - - - - - - - - - - results - - > - - - - - - - - > run-unit-testFAIL non-zero exit status 1 > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rgdal/9312472/log.gz > > This appears to be an issue with how upstream uses PROJ incorrectly, > as discussed on the PROJ list: > > https://lists.osgeo.org/pipermail/proj/2020-December/010014.html > > Upstream doesn't appear to have a public VCS, so it's unclear if the fix > posted on the PROJ list can be easily turned into a patch for the Debian > package. Further investigation shows PROJ 7.2.1 related commits at: https://github.com/r-forge/rgdal/commits/master Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#978739: chardet: Upgrading python3-chardet breaks many packages
Control: tags -1 - moreinfo On 1/1/21 10:09 AM, Sebastian Ramacher wrote: > On 2020-12-31 16:28:40 +0100, Sebastiaan Couwenberg wrote: >> On 12/31/20 4:13 PM, Daniele Tricoli wrote: >>> On Thu, Dec 31, 2020 at 05:55:17AM +0100, Bas Couwenberg wrote: >>>> Package: chardet >>>> Version: 4.0.0-1 >>>> Severity: serious >>>> Justification: makes the package in question unusable or mostly so >>>> Control: affects -1 src:requests src:qgis >>>> >>>> Dear Maintainer, >>>> >>>> Upgrading python3-chardet causes the removal of many packages: >>>> >>>> The following packages will be REMOVED: >>>>chrome-gnome-shell gnome-music pycsw pycsw-wsgi python3-astropy-helpers >>>> python3-boto3 python3-botocore python3-cupshelpers python3-gitlab >>>> python3-numpydoc python3-owslib python3-plotly python3-pycsw python3-pywps >>>> python3-qgis >>>>python3-reportbug python3-requests python3-requests-oauthlib >>>> python3-s3transfer python3-sphinx python3-sphinx-astropy >>>> python3-sphinx-automodapi python3-sphinx-gallery pywps qgis >>>> qgis-plugin-grass reportbug system-config-printer >>>>system-config-printer-common system-config-printer-udev >>>> torbrowser-launcher >>>> The following packages will be upgraded: >>>>python3-chardet >>>> 1 upgraded, 0 newly installed, 31 to remove and 0 not upgraded. >>>> >>>> python3-requests does not support version 3.1.0 or higher: >>>> >>>> python3-chardet (<< 3.1.0) >>>> >>>> With the freeze coming in a few months it may be wise to revert back to >>>> 3.0.x for bullseye. >>>> >>>> Otherwise the python3-chardet rdeps need to fixed before that time. >>> >>> As soon as noticed the chardet upload I uploaded requests 2.25.1+dfsg-1 >>> which >>> fix the problem, but there was a time window during the propagation of the >>> new >>> version when the problem was reproducible. >> >> Thanks for quickly acting on this, but the problem is not limited to >> python3-requests. Several other reverse dependencies need to be updated >> for the new chardet as well. The autopkgtest failures include some of them: >> >> https://qa.debian.org/excuses.php?package=chardet > > Do you have specific packages in mind? All autopkgtests passed and no > other reverse depedency has upper bounds on the version on chardet. With > requests fixed, all others that you marked as affected are installable again. The autopkgtests that failed before due to requests succeeded after they were retried with the new requests. symver suggests that chardet 4 broke its API, so the other reverse dependencies should be tested to ensure they still work with the new chardet. python3-requests did that and resolved the issue for the packages I care about. Not all of the python3-chardet rdeps have autopkgtest so that alone is not an indicator that nothing is broken any more. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#978739: chardet: Upgrading python3-chardet breaks many packages
reopen 978739 thanks On 12/31/20 4:13 PM, Daniele Tricoli wrote: > On Thu, Dec 31, 2020 at 05:55:17AM +0100, Bas Couwenberg wrote: >> Package: chardet >> Version: 4.0.0-1 >> Severity: serious >> Justification: makes the package in question unusable or mostly so >> Control: affects -1 src:requests src:qgis >> >> Dear Maintainer, >> >> Upgrading python3-chardet causes the removal of many packages: >> >> The following packages will be REMOVED: >>chrome-gnome-shell gnome-music pycsw pycsw-wsgi python3-astropy-helpers >> python3-boto3 python3-botocore python3-cupshelpers python3-gitlab >> python3-numpydoc python3-owslib python3-plotly python3-pycsw python3-pywps >> python3-qgis >>python3-reportbug python3-requests python3-requests-oauthlib >> python3-s3transfer python3-sphinx python3-sphinx-astropy >> python3-sphinx-automodapi python3-sphinx-gallery pywps qgis >> qgis-plugin-grass reportbug system-config-printer >>system-config-printer-common system-config-printer-udev >> torbrowser-launcher >> The following packages will be upgraded: >>python3-chardet >> 1 upgraded, 0 newly installed, 31 to remove and 0 not upgraded. >> >> python3-requests does not support version 3.1.0 or higher: >> >> python3-chardet (<< 3.1.0) >> >> With the freeze coming in a few months it may be wise to revert back to >> 3.0.x for bullseye. >> >> Otherwise the python3-chardet rdeps need to fixed before that time. > > As soon as noticed the chardet upload I uploaded requests 2.25.1+dfsg-1 which > fix the problem, but there was a time window during the propagation of the new > version when the problem was reproducible. Thanks for quickly acting on this, but the problem is not limited to python3-requests. Several other reverse dependencies need to be updated for the new chardet as well. The autopkgtest failures include some of them: https://qa.debian.org/excuses.php?package=chardet > Happy new year! The same to you! Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#978099: Please add support for riscv64
On 12/27/20 12:13 AM, Aurelien Jarno wrote: > On 2020-12-26 08:05, Sebastiaan Couwenberg wrote: >> On 12/25/20 11:17 PM, Logan Rosen wrote: >>> libhdf4 currently FTBFS on riscv64. William Grant applied a patch in >>> Ubuntu to add support for the architecture. >>> >>> Thanks for considering the patch. >> >> Thanks for the patch, it failed to apply, however. The existing patches >> have been updated manually. > > Thanks Logan for submitting the patch and Sebastiaan for applying it. > This patch has been taken from debian-ports, however in the meantime we > got an updated version that makes the testsuite to pass. Please find > attach an update against the current diff. Could you please apply it? Thanks for the additional patch, it's also applied in git. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#978236: otb: FTBFS: unsatisfiable build-dependency: libnifti-dev (versioned dep on a virtual pkg?)
reassign 978236 src:insighttoolkit4 found 978236 insighttoolkit4/4.13.3withdata-dfsg1-3 affects 978236 src:otb thanks On 12/26/20 10:40 PM, Lucas Nussbaum wrote: >> The following packages have unmet dependencies: >> libinsighttoolkit4-dev : Depends: libnifti-dev This is not an issue in otb, but in insighttoolkit4, reassigning accordingly. More specifically it's caused by the package split in nifticlib (3.0.1-1) to fix #968730. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#978099: Please add support for riscv64
Control: tags -1 pending On 12/25/20 11:17 PM, Logan Rosen wrote: > libhdf4 currently FTBFS on riscv64. William Grant applied a patch in > Ubuntu to add support for the architecture. > > Thanks for considering the patch. Thanks for the patch, it failed to apply, however. The existing patches have been updated manually. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#977868: osmcoastline: FTBFS in bullseye and sid
Control: tags -1 upstream Control: forwarded -1 https://github.com/osmcode/osmcoastline/issues/39 Thanks for reporting this issue, I've forwarded it upstream. A possible cause may be the upgrade of GEOS to 3.9.0. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#977337: [Pkg-nagios-devel] Bug#977337: icingaweb2: Not compatible with php8.0
icingaweb2 (2.8.2-2~exp1) currently available in experimental mostly works with php8.0, but the dashboard does not. The browser console shows: Uncaught ReferenceError: Icinga is not defined This appears to be caused by the JShrink failing, from the apache error log: PHP Fatal error: Maximum execution time of 30 seconds exceeded in /usr/share/icingaweb2/library/vendor/JShrink/Minifier.php on line 292 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#975593: python-mapnik: FTBFS against boost_1.74
Control: reassign -1 src:mapnik Control: found -1 mapnik/3.0.23+ds-2 Control: tags -1 pending This turns out to be an issue in mapnik, Fedora has a patch for boost1.73 which fixes the python-mapnik FTBFS. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#973600: transition: gdal
On 12/7/20 12:30 PM, Sebastiaan Couwenberg wrote: > On 12/6/20 12:37 PM, Sebastian Ramacher wrote: >> On 2020-11-02 12:49:04 +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 >>> >>> For the Debian GIS team I'd like to transition to GDAL 3.2.0. >>> >>> All reverse dependencies rebuilt successfully with GDAL 3.2.0 from >>> experimental as summarized below, except mysql-workbench. >>> >>> libgdal-grass doesn't need a binNMU as the 3.2.0 version will be >>> uploaded to unstable instead. >> >> Please go ahead with the uploads to unstable. > > Thanks for quickly scheduling the binNMU even before it was installed on > all release architectures. > > Please also binNMU grass & postgis in experimental. What should we do about r-cran-sf which cannot be built on most release archs due to r-cran-s2 failing to build there (#976473). Should be file an RM bugreport to have r-cran-sf (and possible rdeps) removed from those release architectures, or should it be hinted out of testing? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976795: gdal: Please build with -fno-guess-branch-probability on sh4 to prevent compiler segfault
Control: tags -1 pending Hi John, Thanks for the patch, it's applied in git and will be included in the next upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#973600: transition: gdal
On 12/6/20 12:37 PM, Sebastian Ramacher wrote: > On 2020-11-02 12:49:04 +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 >> >> For the Debian GIS team I'd like to transition to GDAL 3.2.0. >> >> All reverse dependencies rebuilt successfully with GDAL 3.2.0 from >> experimental as summarized below, except mysql-workbench. >> >> libgdal-grass doesn't need a binNMU as the 3.2.0 version will be >> uploaded to unstable instead. > > Please go ahead with the uploads to unstable. Thanks for quickly scheduling the binNMU even before it was installed on all release architectures. Please also binNMU grass & postgis in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976144: librttopo1: buggy/missing geojson support
On 12/4/20 7:54 PM, Roman K wrote: >> Понедельник, 30 ноября 2020, 15:56 +03:00 от Sebastiaan Couwenberg >> : >> On 11/30/20 1:31 PM, Roman Kurakin wrote: >>> Since librttopo is suggested as a replacement for liblwgeom, and the part >>> of it >>> functionality is missing (switched off by ifdef) the bug becomes critical. >>> >>> Functionality is switched off due to missing code in configure. Looks like >>> it >>> was lost while fork from original liblwgeom (part of postgis project). >>> >>> All of the versions currently in debian are affected by this problem. >> >> Thanks for the patch, but I'm hesitant to apply it as it's a little >> invasive. >> >> Currently libspatialite is the only user of librttopo, and it likely >> doesn't need the geojson support. > > But what should do packages that are not part of debian? > liblwgeom is removed from postgis 3.0... That's up to those projects, if they can't wait for librttopo to get fixed they could consider embedding a patched copy. Or reinstate the shared library changes in the postgis package for their own local package repo for example. >> Please forward your changes upstream: >> >> https://git.osgeo.org/gitea/rttopo/librttopo >> >> Once the changes are applied upstream we can consider included them in >> the Debian package. > > Already done, but project doesn’t look as actively maintained, the bug was > described three years ago, > but bug reporter was unable to provide a patch. > https://git.osgeo.org/gitea/rttopo/librttopo/issues/21#issuecomment-8877 librttopo is indeed not developed very actively, but it so far serves it purpose of enabling the topology support in spatialite. With the postgis Debian package no longer providing liblwgeom it is not unlikely that librttopo will get more users which may motivate more active development. Especially if that's in the form of pull requests that can be merged easily. If you want to raise more awareness of this issue, you may also want to discuss it on the mailinglist: librttopo-...@lists.osgeo.org Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976162: closed by Sebastiaan Couwenberg (Re: Bug#976162: postgis v3.0.3 pdpg package for amd64 for Ubuntu focal missing)
On 11/30/20 9:02 PM, Tomas Pospisek wrote: > Sebastiaan Couwenberg wrote on Mon, 30 Nov: > >> On 11/30/20 7:56 PM, Tomas Pospisek wrote: >> >>> There is no 3.0.3 package for postgis for focal on pdgd for amd64: >> >> The Debian BTS is not appropriate for this issue, use the >> pgsql-pkg-deb...@postgresql.org mailing list, or >> https://redmine.postgresql.org/projects/pgapt/issues instead. > > Ah, thanks. I was pointed to https://wiki.postgresql.org/wiki/Apt#Bugs > and it reads there: > >> Bugs >> >> Please report bugs: >> >> * on the pgsql-pkg-deb...@postgresql.org mailing list, or >> * open an issue in Redmine, or >> * open a bug in the Debian BTS. > > Which as you explained should probably read > > * open a bug in the Debian BTS only if it's a bug in a package > released through Debian's own package repository. Third party repos should not suggest reporting bugs in Debian the prevent issues like this. But at least they list it as last resort. The PGDG packages use the same source packages as Debian so many packaging issues affect Debian as well, so the BTS can be used for those issues that affect Debian as well. This bugreport is not about packaging, and not even about Debian. So definitely not appropriate for the Debian BTS. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976144: librttopo1: buggy/missing geojson support
reassign 976144 src:librttopo found 976144 librttopo/1.1.0-2 thanks Hi Roman, On 11/30/20 1:31 PM, Roman Kurakin wrote: > Since librttopo is suggested as a replacement for liblwgeom, and the part of > it > functionality is missing (switched off by ifdef) the bug becomes critical. > > Functionality is switched off due to missing code in configure. Looks like it > was lost while fork from original liblwgeom (part of postgis project). > > All of the versions currently in debian are affected by this problem. Thanks for the patch, but I'm hesitant to apply it as it's a little invasive. Currently libspatialite is the only user of librttopo, and it likely doesn't need the geojson support. Please forward your changes upstream: https://git.osgeo.org/gitea/rttopo/librttopo Once the changes are applied upstream we can consider included them in the Debian package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#973600: transition: gdal
On 11/2/20 12:49 PM, 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 > > For the Debian GIS team I'd like to transition to GDAL 3.2.0. > > All reverse dependencies rebuilt successfully with GDAL 3.2.0 from > experimental as summarized below, except mysql-workbench. > > libgdal-grass doesn't need a binNMU as the 3.2.0 version will be > uploaded to unstable instead. Can we do this after the python3-defaults transition (#972253)? I really want to get this done before the transition freeze. > Transition: gdal > > libgdal27 (3.1.4+dfsg-1) -> libgdal28 (3.2.0~rc1+dfsg-1~exp1) > > The status of the most recent rebuilds is as follows. > > fiona (1.8.17-1)OK > gazebo (11.1.0+dfsg-3) OK > gmt (6.1.1+dfsg-1)OK > libcitygml (2.0.9-2) OK > libosmium (2.15.6-1)OK > mapcache(1.10.0-1)OK > mapnik (3.0.23+ds-1) OK > mapproxy(1.12.0-2)OK > mapserver (7.6.1-1) OK > merkaartor (0.18.4+ds-4) OK > mysql-workbench (8.0.19+dfsg-1) FTBFS >(#937102) > ncl (6.6.2-6) OK > node-srs(1.2.0+~2.2.0~git20200927.f30387d8-2) OK > octave-mapping (1.4.1-1) OK > openorienteering-mapper (0.9.4-1) OK > openscenegraph (3.6.5+dfsg1-6) OK > pdal(2.2.0+ds-1) OK > pgsql-ogr-fdw (1.0.12-2)OK > pktools (2.6.7.6+ds-2)OK > postgis (3.0.2+dfsg-4)OK > python-django (2:2.2.16-1) OK > qmapshack (1.15.0-1)OK > r-cran-rgdal(1.5-18+dfsg-1) OK > r-cran-sf (0.9-5+dfsg-1)OK > rasterio(1.1.8-1) OK > saga(7.3.0+dfsg-4)OK > sumo(1.4.0+dfsg1-1) OK > vtk6(6.3.0+dfsg2-5) OK > vtk7(7.1.1+dfsg2-4) OK > > cloudcompare(2.10.3-4)OK > grass (7.8.4-2) OK > opencv (4.2.0+dfsg-6)OK > osmcoastline(2.2.4-1) OK > paraview(5.7.0-5) OK > pyosmium(3.0.1-2) OK > > libgdal-grass (3.1.4-1 / 3.2.0~rc1-1~exp1) FTBFS/OK > otb (7.2.0+dfsg-1)OK > qgis(3.10.11+dfsg-1) OK Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#975593: python-mapnik: FTBFS against boost_1.74
Control: tags -1 upstream Control: forwarded -1 https://github.com/mapnik/python-mapnik/issues/236 Hi Anton, Thanks for reporting this issue, it's been forwarded upstream. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#975416: [Pkg-nagios-devel] Bug#975416: icinga2: FTBFS against boost_1.74
Control: tags -1 upstream Control: forwarded -1 https://github.com/Icinga/icinga2/issues/8493 Hi Anton, Thanks for reporting this issue, I've forwarded it upstream. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#975277: postgis: autopkgtests missing "skippable" keyword
Control: tags -1 pending Control: fixed -1 postgis/3.1.0~alpha1+dfsg-1~exp5 This was already fixed in the experimental branch, the fix for unstable will be uploaded soon. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#974769: qgis: New LTR release 3.16
tags 974769 wontfix thanks The qgis package in Debian tracks the version in the upstream LTR repo, which will remain at 3.10.x until January, see: https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule With the 3.16.4 release scheduled for February, after the Soft Freeze, we're unlikely to get in into bullseye. The version in bullseye at time of release is irrellevant as the recent LTR from testing made available in backports. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#974640: Spatialite GUI /CLI and shp
Hi Michel, Please report issues using reportbug: https://www.debian.org/Bugs/Reporting The HTML in your message prevented processing it correctly. As this is not a packaging issue, it has been forwarded upstream: https://www.gaia-gis.it/fossil/spatialite_gui/tktview/5887c6811b4543c60e22abc5d6f2344ca2c99e26 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#968912: transition: perl 5.32
Please also binNMU gdal in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#974104: merkaartor FTBFS: error: field ‘thePath’ has incomplete type ‘QPainterPath’
This is likely caused by the recent update to Qt 5.15.1, and seems to be fixed upstream: https://github.com/openstreetmap/merkaartor/commit/e72553a7ea2c7ba0634cc3afcd27a9f7cfef089c Jerome, will you take care of this? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#973910: gpsprune: When tile cache "root" doesn't exists there is no error message but no bckground map either
forwarded 973910 https://github.com/activityworkshop/GpsPrune/issues/29 thanks Hi Peter, As this is not a packaging issue, it has been forwarded upstream. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#973164: python-deprecated: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.8" returned exit code 13
Control: tags -1 upstream pending This is fixed upstream, the commit in question will be included as a patch. Kind Regards, Bas
Bug#973177: python-geojson: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.8" returned exit code 13
Control: tags -1 upstream pending This is fixed upstream, the commit in question will be included as a patch. Kind Regards, Bas
Bug#972911: qgis FTBFS on mips64el: Error: branch out of range
Control: tags -1 pending Hi Adrian, Thanks for the patch, it's applied in git and will be included in the next upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
Hi Paul, On 10/21/20 4:30 PM, Sebastiaan Couwenberg wrote: > On Thu, 15 Oct 2020 10:07:28 +0200 Paul Gevers wrote: >> On Mon, 5 Oct 2020 06:30:51 +0200 Sebastiaan Couwenberg wrote: >>>> The binaries for the 32-bit architectures were removed in #962915 [1], >>>> but only for version 4.13.0-1 in unstable. >>> >>> This was not sufficient to let it migrate to testing. >>> >>> The britney output logs a bunch of packages on i386. >>> >>> i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see: >> >> [Release Team member hat on]: I have added hints to allow the breakage >> on i386 as this was now done on purpose. I've been watching this issue >> since August, but was waiting for all the right binary packages in >> unstable to be removed. This bug at severity serious was preventing >> swt4-gtk from migrating to testing, but as the 32 bit packages were >> removed, this bug should no longer blocking migration, hence I downgrade >> it now. > > openjfx is still not migrating to testing, the britney output complains > about several arch:all packages on i386: > > trying: openjfx > skipped: openjfx (1, 0, 30) > got: 91+0: a-1:a-0:a-0:a-0:i-89:m-0:m-0:p-0:s-1 > * i386: josm, libafterburner.fx-java, libjavafxsvg-java, > libopenjfx-java, mediathekview, pdfsam, starlink-topcat-java, topcat, > topcat-doc, zeroc-ice-all-runtime, zeroc-ice-utils-java, zeroc-icegridgui > > Some more allow-uninst hints are likely needed for the other packages. Thanks for the additional allow-uninst hints, it finally let openjfx migrate to testing. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
Hi Paul, On Thu, 15 Oct 2020 10:07:28 +0200 Paul Gevers wrote: > On Mon, 5 Oct 2020 06:30:51 +0200 Sebastiaan Couwenberg wrote: > > > The binaries for the 32-bit architectures were removed in #962915 [1], > > > but only for version 4.13.0-1 in unstable. > > > > This was not sufficient to let it migrate to testing. > > > > The britney output logs a bunch of packages on i386. > > > > i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see: > > [Release Team member hat on]: I have added hints to allow the breakage > on i386 as this was now done on purpose. I've been watching this issue > since August, but was waiting for all the right binary packages in > unstable to be removed. This bug at severity serious was preventing > swt4-gtk from migrating to testing, but as the 32 bit packages were > removed, this bug should no longer blocking migration, hence I downgrade > it now. openjfx is still not migrating to testing, the britney output complains about several arch:all packages on i386: trying: openjfx skipped: openjfx (1, 0, 30) got: 91+0: a-1:a-0:a-0:a-0:i-89:m-0:m-0:p-0:s-1 * i386: josm, libafterburner.fx-java, libjavafxsvg-java, libopenjfx-java, mediathekview, pdfsam, starlink-topcat-java, topcat, topcat-doc, zeroc-ice-all-runtime, zeroc-ice-utils-java, zeroc-icegridgui Some more allow-uninst hints are likely needed for the other packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#972524: [Pkg-nagios-devel] Bug#972524: monitoring-plugins: FTBFS on buster (dh_compress)
On 10/20/20 1:55 PM, Jakob Bohm wrote: > On 2020-10-20 06:05, Sebastiaan Couwenberg wrote: >> Control: tags -1 unreproducible >> Control: severity -1 important >> >> Hi Jakob, >> >> Thanks for reporting this issue, but unfortunately I cannot reproduce it. >> >> Building 2.2-6 in a buster chroot works as expected: >> >> gbp clone \ >> https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git >> git checkout -b buster debian/2.2-6 >> gbp buildpackage --git-pbuilder \ >> --git-dist=buster \ >> --git-debian-branch=buster >> >> Kind Regards, >> >> Bas >> > > Did your test include the use of backported packages, as stated? No, just plain buster. Note that 2.2-6 still uses a deprecated debhelper compat level, this has been changed in git. If you need a backport for buster, you may need to cherry-pick some unreleased commits from the master branch. > When checking out from git, I didn't select any specific branch, as the > "please use the git source" message just said to clone the tree, thus HEAD. > > Also, I notice that your build commands differ from mine, what is "gbp"? git-buildpackage, it's the tools we use to build packages from the git repo. See: https://wiki.debian.org/PackagingWithGit Or a more specific guide that includes setting up the cowbuilder chroots: https://debian-gis-team.pages.debian.net/policy/packaging.html#git-pbuilder > As a local sysadmin, I don't have my own installs of automated build > daemons such as pbuilder. pbuilder & cowbuilder are not automated build daemons, they are chroot environments to ensure that the package is built in a clear environment just like on the official build daemons (which use sbuild instead of pbuilder). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#972524: [Pkg-nagios-devel] Bug#972524: monitoring-plugins: FTBFS on buster (dh_compress)
Control: tags -1 unreproducible Control: severity -1 important Hi Jakob, Thanks for reporting this issue, but unfortunately I cannot reproduce it. Building 2.2-6 in a buster chroot works as expected: gbp clone \ https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git git checkout -b buster debian/2.2-6 gbp buildpackage --git-pbuilder \ --git-dist=buster \ --git-debian-branch=buster Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#972168: pykdtree/kdtree.c ships without the cython source
Control: tags -1 pending On 10/13/20 4:13 PM, Matthias Klose wrote: > pykdtree/kdtree.c ships without the cython source. So you cannot rebuild the > file from cython (and fixing the build failure with python 3.9). De repo on salsa now uses the git release tags for the source tree, but setup.py does not cythonize the sources. Antonio, do you think we should fix this upstream or just do it in d/rules like we do for _kdtree_core.c (which should also move to setup.py then)? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#972169: pykdtree points to the wrong upstream page
On 10/13/20 4:18 PM, Matthias Klose wrote: > debian/control and debian/copyright refer to: > > Homepage: https://github.com/pytroll/pykdtree > > which doesn't have any 1.3.x releases. Where does this package come from? d/watch answers your question: https://pypi.debian.net/pykdtree/ > Setting this to serious, because the pykdtree.pxd file is missing in the > Debian > source tarball, and there's no way to download it with the current > information. The upstream repo has the .pyx file: https://github.com/pytroll/pykdtree/blob/master/pykdtree/kdtree.pyx It's not included in the PyPI sources because it's not included in MANIFEST.in. If the repo tagged its releases to PyPI the git tags could be unused instead to have the complete source tree. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#971698: Spatialite GUI and unicode
Control: tags -1 upstream Control: forwarded -1 https://www.gaia-gis.it/fossil/spatialite_gui/tktview/4fe74419ba5367c1e835749a6599fd7c545ca23d Hi Michel, Thanks for reporting this issue, I've forwarded it upstream. Please follow up there and/or on the spatialite-users list: https://groups.google.com/forum/#!forum/spatialite-users Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
On 10/5/20 6:04 AM, tony mancill wrote: > On Sun, Oct 04, 2020 at 04:34:17PM +0200, Sebastiaan Couwenberg wrote: >> Control: severity -1 serious >> Control: affects -1 src:openjfx >> >> This issue is preventing testing migration of swt4-gtk, it also blocks >> openjfx builds on the architectures where swt4-gtk FTBFS preventing the >> fix for #967185 from migrating to testing. >> >> Either fix the build or request removal of swt4-gtk and its rdeps from >> these architectures. > > The binaries for the 32-bit architectures were removed in #962915 [1], > but only for version 4.13.0-1 in unstable. This was not sufficient to let it migrate to testing. The britney output logs a bunch of packages on i386. i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see: https://release.debian.org/britney/britney.conf > bullseye still contains the > binaries [2]. From the RM email: > >> Packages are usually not removed from testing by hand. Testing tracks >> unstable and will automatically remove packages which were removed >> from unstable when removing them from testing causes no dependency >> problems. The release team can force a removal from testing if it is >> really needed, please contact them if this should be the case. > > Is the problem here that we need to RM all of the rdeps on those > architectures from unstable as well? At least in the case of openjfx (and its non-arch:all rdeps). > If that's sufficient, I can put > together that RM request. > > Also, shouldn't we explicitly enumerate the supported Architectures in > the next upload of swt4-gtk instead of specifying "Architecture: all" ? You mean "Architecture: any" I presume? If so, you could do that, but maintaining the list of architectures over time is a PITA from my experience, I wouldn't recommend it unless swt4-gtk only sometimes fails to build on these architectures. If it's persistent removing the packages from those architectures should suffice. Once its rdeps are removed as well they will be in BD-Uninstallable state on those archs. But because of the RM the missing binaries won't block testing migration. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
Control: severity -1 serious Control: affects -1 src:openjfx This issue is preventing testing migration of swt4-gtk, it also blocks openjfx builds on the architectures where swt4-gtk FTBFS preventing the fix for #967185 from migrating to testing. Either fix the build or request removal of swt4-gtk and its rdeps from these architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#971538: qgis: "Couldn't load SIP module." error message when started
Control: tags -1 upstream Control: forwarded -1 https://github.com/qgis/QGIS/issues/39117 Thanks for reporting this issue, I've forwarded it upstream as doesn't seem to be specific to the Debian package. As noted in the upstream issue, it may be caused by the recent update of pyqt5 to 5.15.1. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#971435: qmapshack: fails to start: missing library libCharLS.so.2
Control: block -1 by 971425 Control: affects 971425 src:qmapshack On 9/30/20 4:13 PM, Norbert Preining wrote: > but there seems to be some case-hiccup and qmapshack needs recompilation > or some more fixes? charls was updated to 2.1.0+dfsg-1 yesterday which caused this, see: #971425 It FTBFS on several architectures, so we won't be able to rebuild qmapshack on all architectures at the moment. As mentioned in #971425 this breaking change in charls needs to be reverted or a transition is required. In case of the latter this issue will be fixed once qmapshack is rebuilt with the new charls. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#970966: python-cartopy: autopkgtest must be marked superficial
Control: tags -1 pending On 9/26/20 1:06 AM, Sudip Mukherjee wrote: > On closer look, it looks like you have a different problem with autopkgtest. > You have a test script which is called "python3", but you are doing > "Test-Command: python3", so that is not executing your test script but > is executing "/usr/bin/python3". > Please modify your "debian/tests/control" file and use "Tests" instead > of "Test-Command". > Your debian/tests/control should look like: > > Tests: python3 > Depends: python3-cartopy, python3-pytest > Restrictions: allow-stderr Fixed in git. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#964132: qgis: Please switch from sip4 to sip5
On 9/21/20 5:16 PM, Sebastiaan Couwenberg wrote: > On 9/21/20 5:10 PM, Dmitry Shachnev wrote: >> On Mon, Sep 21, 2020 at 04:44:06PM +0200, Sebastiaan Couwenberg wrote: >>>> But SIP 6 won't be released before Qt 6, which is expected in the beginning >>>> of 2021. >>> >>> Are there any packagers for Qt 6 yet? If not, we'll have qt5 in Debian >>> for quite awhile still. >> >> SIP doesn't depend on Qt, just the upstream SIP/PyQt6 developer wants >> to coordinate his release schedule with Qt. >> >>> Your patches to the upstream buildsystem have been been added to the >>> master branch on salsa as well. They will be included in the next upload >>> which likely won't happen before 3.10.10+dfsg-1 migrates to testing, at >>> the latest when 3.10.11 is released next month. >>> >>> Once PyQt5 is moved to unstable, the changes for (build) dependencies >>> will be adopted on the master branch as well. >> >> Can I ask you to test the current QGIS package from unstable with PyQt5 >> 5.15.1 from experimental? >> >> I could do it myself, but you know this package more so can probably perform >> more extensive testing. > > We've already tested that it builds as proven by the package in > experimental. > > I don't use QGIS much, so there is not much runtime testing I can do. A quick test in an unstable VMs doesn't turn up any issues, adding an OSM standard layer and a BAG woonplaats WMS layer worked successfully. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#964132: qgis: Please switch from sip4 to sip5
On 9/21/20 5:10 PM, Dmitry Shachnev wrote: > On Mon, Sep 21, 2020 at 04:44:06PM +0200, Sebastiaan Couwenberg wrote: >>> But SIP 6 won't be released before Qt 6, which is expected in the beginning >>> of 2021. >> >> Are there any packagers for Qt 6 yet? If not, we'll have qt5 in Debian >> for quite awhile still. > > SIP doesn't depend on Qt, just the upstream SIP/PyQt6 developer wants > to coordinate his release schedule with Qt. > >> Your patches to the upstream buildsystem have been been added to the >> master branch on salsa as well. They will be included in the next upload >> which likely won't happen before 3.10.10+dfsg-1 migrates to testing, at >> the latest when 3.10.11 is released next month. >> >> Once PyQt5 is moved to unstable, the changes for (build) dependencies >> will be adopted on the master branch as well. > > Can I ask you to test the current QGIS package from unstable with PyQt5 > 5.15.1 from experimental? > > I could do it myself, but you know this package more so can probably perform > more extensive testing. We've already tested that it builds as proven by the package in experimental. I don't use QGIS much, so there is not much runtime testing I can do. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#964132: qgis: Please switch from sip4 to sip5
On 9/21/20 4:19 PM, Dmitry Shachnev wrote: > On Mon, Sep 21, 2020 at 04:05:08PM +0200, Sebastiaan Couwenberg wrote: >> No sure how feasible that is, QGIS upstream also supports older >> Debian/Ubuntu releases which may not support the SIP5/6 buildsystem. > > I'm afraid it will be hard to support SIP 4 and 6 at the same time. Then SIP 6 & Qt 6 support will likely become something for QGIS 4.x. > But SIP 6 won't be released before Qt 6, which is expected in the beginning > of 2021. Are there any packagers for Qt 6 yet? If not, we'll have qt5 in Debian for quite awhile still. >> The changes to the upstream parts just added support for SIP5, the >> packaging was updated to use those packages from experimental. >> >> We can merge the upstream bits to have the support for the sip5 >> buildsystem, and can keep the packaging to use sip4 (i.e. don't update >> (build) dependencies). > > Yes, that's what I was suggesting. > > When I filed this bug report in July, I thought it's not possible to mix > different SIP versions in the same project, i.e. use SIP 4 together with > PyQt5 that is built with SIP 5. > > But now upstream assured me that it actually is possible. In any case, > please test that configuration before I upload PyQt5 to unstable. Your patches to the upstream buildsystem have been been added to the master branch on salsa as well. They will be included in the next upload which likely won't happen before 3.10.10+dfsg-1 migrates to testing, at the latest when 3.10.11 is released next month. Once PyQt5 is moved to unstable, the changes for (build) dependencies will be adopted on the master branch as well. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#964132: qgis: Please switch from sip4 to sip5
On 9/21/20 3:53 PM, Dmitry Shachnev wrote: > On Mon, Sep 21, 2020 at 01:59:35PM +0200, Sebastiaan Couwenberg wrote: >> Control: forwarded -1 https://github.com/qgis/QGIS/issues/38911 > > Thanks! Maybe retitle that to “Please migrate to the new SIP 5/6 buildsystem”? No sure how feasible that is, QGIS upstream also supports older Debian/Ubuntu releases which may not support the SIP5/6 buildsystem. >> Thanks for the updated, forwarded upstream in: >> >> https://github.com/qgis/QGIS/issues/38911 >> >> The experimental branch on salsa still has the sip5 changes, perhaps >> it's best to merge those and use that until support for SIP 6 arrives. > > That will work only if upstream migrates to the new buildsystem *before* > I package sip6 for Debian. > > Because SIP 5 and 6 won't be co-installable, I will probably rename sip5 > source package to (simply) sip, and update it to a new upstream version > when SIP 6 is released. > > But I guess in the worst case you will be able to revert back to SIP 4 > if the SIP 6 port cannot be done for some reason. The changes to the upstream parts just added support for SIP5, the packaging was updated to use those packages from experimental. We can merge the upstream bits to have the support for the sip5 buildsystem, and can keep the packaging to use sip4 (i.e. don't update (build) dependencies). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#964132: qgis: Please switch from sip4 to sip5
Control: forwarded -1 https://github.com/qgis/QGIS/issues/38911 On 9/21/20 1:19 PM, Dmitry Shachnev wrote: > Hi again Sebastiaan! > > On Wed, Jul 22, 2020 at 12:08:39PM +0200, Sebastiaan Couwenberg wrote: >> I'm planning to cherry-pick your changes to the experimental branch for >> testing with QGIS 3.10.x LTR, if that also builds fine I'll upload it to >> experimental as well. Assuming there are not major complication I can >> keep that branch updated with the monthly LTR releases until pyqt5 moves >> to unstable. > > I have an update on PyQt5 vs. SIP 5 status. > > Unfortunately, things got a bit more complicated recently. Upstream is > going to release SIP 6 in the beginning of next year, which will be not > co-installable together with SIP 5, and which will not have /usr/bin/sip5 > “legacy” script: > > https://www.riverbankcomputing.com/pipermail/pyqt/2020-September/043201.html > https://www.riverbankcomputing.com/pipermail/pyqt/2020-September/043162.html > > sip5 was a script to ease upgrades from SIP 4, and it has a set of options > similar to SIP 4's /usr/bin/sip. Upstream now recommends using their new > tools, sip-build and similar ones. See the documentation: > > https://www.riverbankcomputing.com/static/Docs/sip/ > > This means that next year we will have SIP 4 and SIP 6 in Debian, but not > SIP 5. My upstream work on QGIS made use of /usr/bin/sip5, so it will need to > be ported to the new tools in order to support SIP 6 (and PyQt6). > > At the same time, upstream says that it will remain possible to compile > applications with SIP 4 even when PyQt5 uses newer SIP. So now I think the > best plan is: > > - Please keep using SIP 4 for QGIS for now. > - Please test that it still works fine with PyQt5 in experimental. > - Ask upstream to migrate to the new tools to be prepared for SIP 6 / PyQt6. Thanks for the updated, forwarded upstream in: https://github.com/qgis/QGIS/issues/38911 The experimental branch on salsa still has the sip5 changes, perhaps it's best to merge those and use that until support for SIP 6 arrives. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)
Control: tags -1 - moreinfo On 9/18/20 6:13 PM, Sven Joachim wrote: > On 2020-09-18 16:55 +0200, Bas Couwenberg wrote: >> Upgrading sid & experimental pbuilder chroots fails due to the new ncurses: >> >> Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ... >> Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ... >> Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ... >> Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ... >> rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version >> `NCURSES6_TINFO_6.2.current' not found (required by >> /lib/x86_64-linux-gnu/libncurses.so.6) >> dpkg: error while cleaning up: >> rm command for cleanup subprocess returned error exit status 1 >> dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version >> `NCURSES6_TINFO_6.2.current' not found (required by >> /lib/x86_64-linux-gnu/libncurses.so.6) >> rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version >> `NCURSES6_TINFO_6.2.current' not found (required by >> /lib/x86_64-linux-gnu/libncurses.so.6) >> dpkg: error processing archive >> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack): >> rm command for cleanup subprocess returned error exit status 1 >> Errors were encountered while processing: >> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb >> E: Sub-process /usr/bin/dpkg returned an error code (1) > > I cannot reproduce this, but my pbuilder chroots do not have libncurses6 > installed at all. What about cowbuilder chroots? > What is this rm binary in your chroot, apparently it > is linked to libncurses.so.6? # which rm /bin/rm # dpkg -S /bin/rm coreutils: /bin/rm # ldd /bin/rm linux-vdso.so.1 (0x7ffea75fb000) /usr/lib/cowdancer/libcowdancer.so (0x7f2e6a6db000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2e6a512000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2e6a50c000) libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 (0x7f2e6a4e3000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f2e6a4b4000) /lib64/ld-linux-x86-64.so.2 (0x7f2e6a6f9000) # aptitude why libncurses6 i cowdancer Depends libncurses6 (>= 6) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#970252: [Pkg-nagios-devel] Bug#970252: Bug#970252: CVE-2020-14004
On 9/14/20 6:38 AM, Sebastiaan Couwenberg wrote: > On 9/14/20 5:41 AM, Sebastiaan Couwenberg wrote: >> On 9/13/20 10:39 PM, Moritz Muehlenhoff wrote: >>> Please see https://www.openwall.com/lists/oss-security/2020/06/12/1 >> >> This is fixed upstream in: >> >> v2.12.0 v2.11.5 v2.11.4 >> >> The former is already in experimental, and the 2.11 package in unstable >> will be updated to .5 to have the fix as well. > > icinga2 (2.11.5-1) has been uploaded to unstable. The update for buster is also available: https://salsa.debian.org/nagios-team/pkg-icinga2/-/commits/buster Is it alright to upload the -sa build to security-master? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#970252: [Pkg-nagios-devel] Bug#970252: CVE-2020-14004
Control: fixed -1 icinga2/2.12.0-1~exp1 Control: tags -1 pending On 9/13/20 10:39 PM, Moritz Muehlenhoff wrote: > Please see https://www.openwall.com/lists/oss-security/2020/06/12/1 This is fixed upstream in: v2.12.0 v2.11.5 v2.11.4 The former is already in experimental, and the 2.11 package in unstable will be updated to .5 to have the fix as well. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#969976: transition: pdal
On 9/11/20 11:10 AM, Sebastiaan Couwenberg wrote: > On 9/10/20 3:13 PM, Sebastiaan Couwenberg wrote: >> On 9/10/20 9:06 AM, Emilio Pozuelo Monfort wrote: >>> On 09/09/2020 17:53, 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-pdal.html >>>> >>>> PDAL bumped its SONAME requiring a transition. >>>> >>>> All packages except paraview rebuilt successfully as summarized below. >>>> >>>> The paraview FTBFS is unrelated to PDAL. >>>> >>>> >>>> Transition: pdal >>>> >>>> libpdal-base10 (2.1.0+ds-2+b1) -> libpdal-base12 (2.2.0+ds-1~exp1) >>>> libpdal-util10 (2.1.0+ds-2+b1) -> libpdal-util12 (2.2.0+ds-1~exp1) >>>> >>>> The status of the most recent rebuilds is as follows. >>>> >>>> cloudcompare (2.10.3-4) OK >>>> grass(7.8.3-1) OK >>>> paraview (5.7.0-4) FTBFS (#957660) >>> >>> Go ahead. >> >> Thanks! pdal (2.2.0+ds-1) has been uploaded to unstable and is built & >> installed on all release architectures. > > Thanks for scheduling the binNMUs, grass has built successfully. It > looks like openmpi 4.0.5 broke things (#970036), preventing cloudcompare > and paraview from being rebuilt. openmpi (4.0.5-3) has a fix for #970036, but it FTBFS on at least armel & mipsel due to #970194. Hence cloudcompare can still not be rebuilt on mipsel for this transition. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#970215: otb-bin: programs fail with symbol lookup error
Control: block -1 by 957653 On 9/13/20 6:15 AM, Andrew Harvey wrote: > /usr/bin/otbApplicationLauncherCommandLine: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libOTBApplicationEngine-7.1.so.1: undefined > symbol: > _ZN3itk9Directory16GetNumberOfFilesEv Aka itk::Directory::GetNumberOfFiles(). otb may need to be rebuilt for recent changes in insighttoolkit4, but for that it will first need to built successfully with gcc-10. (#957653) otb is no longer in testing due to that, so don't expect it to work in unstable either until that is resolved. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#969976: transition: pdal
On 9/10/20 3:13 PM, Sebastiaan Couwenberg wrote: > On 9/10/20 9:06 AM, Emilio Pozuelo Monfort wrote: >> On 09/09/2020 17:53, 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-pdal.html >>> >>> PDAL bumped its SONAME requiring a transition. >>> >>> All packages except paraview rebuilt successfully as summarized below. >>> >>> The paraview FTBFS is unrelated to PDAL. >>> >>> >>> Transition: pdal >>> >>> libpdal-base10 (2.1.0+ds-2+b1) -> libpdal-base12 (2.2.0+ds-1~exp1) >>> libpdal-util10 (2.1.0+ds-2+b1) -> libpdal-util12 (2.2.0+ds-1~exp1) >>> >>> The status of the most recent rebuilds is as follows. >>> >>> cloudcompare (2.10.3-4) OK >>> grass(7.8.3-1) OK >>> paraview (5.7.0-4) FTBFS (#957660) >> >> Go ahead. > > Thanks! pdal (2.2.0+ds-1) has been uploaded to unstable and is built & > installed on all release architectures. Thanks for scheduling the binNMUs, grass has built successfully. It looks like openmpi 4.0.5 broke things (#970036), preventing cloudcompare and paraview from being rebuilt. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#969976: transition: pdal
On 9/10/20 9:06 AM, Emilio Pozuelo Monfort wrote: > On 09/09/2020 17:53, 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-pdal.html >> >> PDAL bumped its SONAME requiring a transition. >> >> All packages except paraview rebuilt successfully as summarized below. >> >> The paraview FTBFS is unrelated to PDAL. >> >> >> Transition: pdal >> >> libpdal-base10 (2.1.0+ds-2+b1) -> libpdal-base12 (2.2.0+ds-1~exp1) >> libpdal-util10 (2.1.0+ds-2+b1) -> libpdal-util12 (2.2.0+ds-1~exp1) >> >> The status of the most recent rebuilds is as follows. >> >> cloudcompare (2.10.3-4) OK >> grass(7.8.3-1) OK >> paraview (5.7.0-4) FTBFS (#957660) > > Go ahead. Thanks! pdal (2.2.0+ds-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
Bug#969236: [Pkg-nagios-devel] Bug#969236: libmonitoring-livestatus-perl: please switch away from netcat
Fixed in git, please raise the severity of this issue once the transitional package goes away and no new upload of this package has happened. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#969155: [Pkg-nagios-devel] Bug#969155: RFP: icinga database -- database for icinga 2
On 8/28/20 11:44 AM, Kunz David wrote: > icinga database is a new database backend > for icinga 2 Since the PostgreSQL backend works fine for me, and Icinga DB only seems to support MySQL, I do not intend to package it. Would you be willing to maintain the icingadb package for Debian within the Nagios team? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#968833: [Pkg-nagios-devel] Bug#968833: CVE-2020-24368
On 8/22/20 4:26 PM, Moritz Muehlenhoff wrote: > On Sat, Aug 22, 2020 at 07:58:34AM +0200, Sebastiaan Couwenberg wrote: >> Hi Moritz, >> >> This is fixed in icingaweb2 (2.8.2-1) which was just uploaded to unstable. >> >> I've also prepared an update for buster, see: >> >> https://salsa.debian.org/nagios-team/pkg-icingaweb2/-/commits/buster >> >> Do you want to upload that to security-master or shall I? > > Thanks, looks good! Please upload to security-master (security-master > and ftp-master have separate dak installs and since this is the first > DSA for icingaweb2 in buster it needs to be built with -sa to include > the orig tarball) Already did that this morning per Dev Ref 5.8.5. Just uploaded it to security-master. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#968833: [Pkg-nagios-devel] Bug#968833: CVE-2020-24368
Control: tags -1 pending Hi Moritz, This is fixed in icingaweb2 (2.8.2-1) which was just uploaded to unstable. I've also prepared an update for buster, see: https://salsa.debian.org/nagios-team/pkg-icingaweb2/-/commits/buster Do you want to upload that to security-master or shall I? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#966983: Most likely fixed in sphinx (2.4.3-5)
On 8/11/20 9:41 AM, Andreas Tille wrote: > On Tue, Aug 11, 2020 at 07:17:30AM +0200, Sebastiaan Couwenberg wrote: >> A smiliar issue was reported for mapproxy in #966979, which was not an >> issue in mapproxy but in sphinx, and fixed in sphinx (2.4.3-5). >> >> I have not tested the build of this package, but the dh_sphinxdoc issue >> is mostl likely fixed with sphinx (2.4.3-5) as well. > > Thanks for the hint but I get: > > reading sources... [ 0%] generated/skbio.alignment.AlignmentStructure > /build/python-skbio-0.5.6/.pybuild/cpython3_3.8_skbio/build/skbio/stats/ordination/_principal_coordinate_analysis.py:143: > RuntimeWarning: The result contains negative eigenvalues. Please compare > their magnitude with the magnitude of some of the largest positive > eigenvalues. If the negative ones are smaller, it's probably safe to ignore > them, but if they are large in magnitude, the results won't be useful. See > the Notes section for more details. The smallest eigenvalue is > -0.011492611219229537 and the largest is 16.021722090908206. > warn( > /build/python-skbio-0.5.6/.pybuild/cpython3_3.8_skbio/build/skbio/stats/ordination/_ordination_results.py:285: > UserWarning: Tight layout not applied. The left and right margins cannot be > made large enough to accommodate all axes decorations. > fig.tight_layout() > > Extension error: > Handler for event > 'autodoc-process-docstring' threw an exception (exception: module, class, > method, function, traceback, frame, or code object was expected, got > method_descriptor) > make[1]: *** [debian/rules:20: override_dh_auto_build-indep] Error 2 That's not the dh_sphinxdoc error this issue was filed for. This failure is most likely caused by an extension not being compatible with sphinx 3.2.0. sphinx was upgraded in unstable from 2.4.3-5 to 3.2.0-1 two days ago. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#966929: Most likely fixed in sphinx (2.4.3-5)
A smiliar issue was reported for mapproxy in #966979, which was not an issue in mapproxy but in sphinx, and fixed in sphinx (2.4.3-5). I have not tested the build of this package, but the dh_sphinxdoc issue is mostl likely fixed with sphinx (2.4.3-5) as well. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#966519: RM: pysal -- ROM; Unmaintained
Control: tags -1 - moreinfo On 8/6/20 7:23 PM, Sean Whitton wrote: > On Thu 30 Jul 2020 at 05:51AM +02, Bas Couwenberg wrote: >> Please remove pysal from the archive, >> it is unmaintained and has a low popcon score. > > popcon is not low and there are no open bugs? 11 votes is low. No one has stepped up to package the many projects PySAL upstream has split into, so it should be removed instead of remaining stuck at an outdated version indefinitely. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
