Bug#1000486: buster-pu: package btrbk/0.27.1-1+deb10u2

2021-11-23 Thread Thorsten Alteholz 

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu


The attached debdiff for btrbk fixes a regression of CVE-2021-38173 in 
Buster.


The regression was reported in #996260 [1] and a pointer to the fix was 
provided. There was at least one report about a now working version 
+deb10u2.


  Thorsten

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996260diff -Nru btrbk-0.27.1/debian/changelog btrbk-0.27.1/debian/changelog
--- btrbk-0.27.1/debian/changelog   2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/changelog   2021-11-23 16:03:02.0 +0100
@@ -1,3 +1,11 @@
+btrbk (0.27.1-1+deb10u2) buster; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * regression fix for CVE-2021-38173
+(Closes: #996260, #996266)
+
+ -- Thorsten Alteholz   Tue, 23 Nov 2021 16:03:02 +0100
+
 btrbk (0.27.1-1+deb10u1) buster; urgency=high
 
   * Non-maintainer upload by the LTS Team.
diff -Nru btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 
btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch
--- btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 1970-01-01 
01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 2021-11-23 
15:52:28.0 +0100
@@ -0,0 +1,51 @@
+commit c03e960d9044961fcfbeaa5d5aeb5bcc1bc0cc7a
+Author: Axel Burri 
+Date:   Tue Nov 19 22:07:37 2019 +0100
+
+ssh_filter_btrbk.sh: exclude "btrfs subvolume show|list" from restrict-path
+
+btrbk requires "btrfs subvolume list|show" queries from the mount
+point in order to build btrfs trees. This conflicts with tightly set
+--restrict-path.
+
+Index: btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc
+===
+--- btrbk-0.27.1.orig/doc/ssh_filter_btrbk.1.asciidoc  2021-11-23 
15:52:22.921452288 +0100
 btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc   2021-11-23 
15:52:22.917452292 +0100
+@@ -34,8 +34,8 @@
+ 
+ The following commands are always allowed:
+ 
+- - "btrfs subvolume show"
+- - "btrfs subvolume list"
++ - "btrfs subvolume show" (not affected by "--restrict-path")
++ - "btrfs subvolume list" (not affected by "--restrict-path")
+  - "readlink"
+  - "cat /proc/self/mountinfo"
+  - pipes through "gzip", "pigz", "bzip2", "pbzip2", "xz", "lzop",
+@@ -79,7 +79,8 @@
+ Allow btrfs receive command: "btrfs receive".
+ 
+ -p, --restrict-path ::
+-Restrict btrfs commands to .
++Restrict commands to . Note that "btrfs subvolume show",
++"btrfs subvolume list" are NOT affected by this option.
+ 
+ -l, --log::
+ Log ACCEPT and REJECT messages to the system log.
+Index: btrbk-0.27.1/ssh_filter_btrbk.sh
+===
+--- btrbk-0.27.1.orig/ssh_filter_btrbk.sh  2021-11-23 15:52:22.921452288 
+0100
 btrbk-0.27.1/ssh_filter_btrbk.sh   2021-11-23 15:52:22.921452288 +0100
+@@ -161,8 +161,9 @@
+ shift
+ done
+ 
+-allow_cmd "${sudo_prefix}btrfs subvolume show"; # subvolume queries are 
always allowed
+-allow_exact_cmd "${sudo_prefix}btrfs subvolume list ${file_match}"; # 
subvolume queries are always allowed
++# NOTE: subvolume queries no NOT affected by "--restrict-path":
++# btrbk also calls show/list on the mount point of the subvolume
++allow_exact_cmd "${sudo_prefix}btrfs subvolume (show|list)( ${option_match})* 
${file_match}";
+ allow_cmd "${sudo_prefix}readlink"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mountinfo"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mounts" # legacy, for btrbk < 0.27.0
diff -Nru btrbk-0.27.1/debian/patches/series btrbk-0.27.1/debian/patches/series
--- btrbk-0.27.1/debian/patches/series  2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/patches/series  2021-11-23 15:52:21.0 +0100
@@ -1 +1,2 @@
 CVE-2021-38173.patch
+CVE-2021-38173-regression.patch

Bug#1000485: bullseye-pu: package btrbk/0.27.1-1.1+deb11u2

2021-11-23 Thread Thorsten Alteholz 

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

The attached debdiff for btrbk fixes a regression of CVE-2021-38173 in
Bullseye.

The regression was reported in #996260 [1] and a pointer to the fix was
provided. There was at least one report about a now working version 
+deb10u2 in Buster, which is based on the same version as Bullseye.


  Thorsten

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996260
diff -Nru btrbk-0.27.1/debian/changelog btrbk-0.27.1/debian/changelog
--- btrbk-0.27.1/debian/changelog   2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/changelog   2021-11-23 20:03:02.0 +0100
@@ -1,3 +1,11 @@
+btrbk (0.27.1-1.1+deb11u2) bullseye; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * regression fix for CVE-2021-38173
+(Closes: #996260, #996266)
+
+ -- Thorsten Alteholz   Tue, 23 Nov 2021 20:03:02 +0100
+
 btrbk (0.27.1-1.1+deb11u1) bullseye; urgency=high
 
   * Non-maintainer upload by the LTS Team.
diff -Nru btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 
btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch
--- btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 1970-01-01 
01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 2021-11-23 
20:03:02.0 +0100
@@ -0,0 +1,51 @@
+commit c03e960d9044961fcfbeaa5d5aeb5bcc1bc0cc7a
+Author: Axel Burri 
+Date:   Tue Nov 19 22:07:37 2019 +0100
+
+ssh_filter_btrbk.sh: exclude "btrfs subvolume show|list" from restrict-path
+
+btrbk requires "btrfs subvolume list|show" queries from the mount
+point in order to build btrfs trees. This conflicts with tightly set
+--restrict-path.
+
+Index: btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc
+===
+--- btrbk-0.27.1.orig/doc/ssh_filter_btrbk.1.asciidoc  2021-11-23 
15:52:22.921452288 +0100
 btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc   2021-11-23 
15:52:22.917452292 +0100
+@@ -34,8 +34,8 @@
+ 
+ The following commands are always allowed:
+ 
+- - "btrfs subvolume show"
+- - "btrfs subvolume list"
++ - "btrfs subvolume show" (not affected by "--restrict-path")
++ - "btrfs subvolume list" (not affected by "--restrict-path")
+  - "readlink"
+  - "cat /proc/self/mountinfo"
+  - pipes through "gzip", "pigz", "bzip2", "pbzip2", "xz", "lzop",
+@@ -79,7 +79,8 @@
+ Allow btrfs receive command: "btrfs receive".
+ 
+ -p, --restrict-path ::
+-Restrict btrfs commands to .
++Restrict commands to . Note that "btrfs subvolume show",
++"btrfs subvolume list" are NOT affected by this option.
+ 
+ -l, --log::
+ Log ACCEPT and REJECT messages to the system log.
+Index: btrbk-0.27.1/ssh_filter_btrbk.sh
+===
+--- btrbk-0.27.1.orig/ssh_filter_btrbk.sh  2021-11-23 15:52:22.921452288 
+0100
 btrbk-0.27.1/ssh_filter_btrbk.sh   2021-11-23 15:52:22.921452288 +0100
+@@ -161,8 +161,9 @@
+ shift
+ done
+ 
+-allow_cmd "${sudo_prefix}btrfs subvolume show"; # subvolume queries are 
always allowed
+-allow_exact_cmd "${sudo_prefix}btrfs subvolume list ${file_match}"; # 
subvolume queries are always allowed
++# NOTE: subvolume queries no NOT affected by "--restrict-path":
++# btrbk also calls show/list on the mount point of the subvolume
++allow_exact_cmd "${sudo_prefix}btrfs subvolume (show|list)( ${option_match})* 
${file_match}";
+ allow_cmd "${sudo_prefix}readlink"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mountinfo"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mounts" # legacy, for btrbk < 0.27.0
diff -Nru btrbk-0.27.1/debian/patches/series btrbk-0.27.1/debian/patches/series
--- btrbk-0.27.1/debian/patches/series  2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/patches/series  2021-11-23 20:03:02.0 +0100
@@ -1 +1,2 @@
 CVE-2021-38173.patch
+CVE-2021-38173-regression.patch

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

2021-11-23 Thread David Prévot 

Hi,

Le 23/11/2021 à 15:57, Paul Gevers a écrit :

On 23-11-2021 11:52, Ondřej Surý wrote:

On 22. 11. 2021, at 22:28, David Prévot  wrote:



I’ve just uploaded a version with your fix.


Thanks a lot.


+1.


David, can we now agree on a timeframe when we start the transition?



[…] it's not up to him to decide.


[…] David, I think you already said you wouldn't 
mind if the transition already started now, is that the stance of the 
Debian PHP PEAR Maintainers?


AFAICT, nobody objects (the team is CCed, since a few mails). We’re also 
holding on some updates because some packages already require PHP 8 
(other are still after PHP 5 compatibility, the world is a mess ;).


How much of the broken reverse dependencies 
are outside that teams maintenance (approximately)?


No clue, sorry. Not sure autopkgtest are used a lot outside of the PHP 
PEAR (and Composer) and Horde teams, that doesn’t help to get a quick grasp.



And I would prefer if we roughly agree on a timeframe when we start
the transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it
is ready upstream

[…]
The Release Team _very much_ welcomes staging/testing these things in 
experimental exactly as you propose. So by all means, upload early, 
including the relevant php-defaults too.

[…]
But it also depends a bit on 
the cooperation of the maintainers of your reverse dependencies and/or 
NMU actions. This takes time and coordination.


Thanks for sharing your plans in advance, happy to try and make this 
timeframe work.


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Re: 11.2 planning

2021-11-23 Thread Cyril Brulebois 
Adam D. Barratt  (2021-11-23):
> It's (a little past) time that we organised the next point release. As
> an "every other" release, this time will only be for stable.
> 
> Any of the first three weekends of December would work for me, although
> the 4th is my least preferred as it means freezing over the coming
> weekend and I'm not sure if I'll have time to do a fair job of dealing
> with things before that.
> 
> tl;dr, suggested dates:
> 
> December 4th [least preferable for me]
> December 11th
> December 18th

Any of those would work for me.

(I'm over-* anyway, so I'll make myself available for whatever you choose.)

Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1000480: buster-pu: package jtharness/6.0-b15-1~deb10u1

2021-11-23 Thread Moritz Muehlenhoff 
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ebo...@apache.org, d...@debian.org

The build requirements for openjdk-11 were bumped, starting with
11.0.13 jtreg 5 (and along with it a jtharness 6) are required to
run the test suite. Since we need to follow 11.0.x releases for
security updates, this blocks an update of 11.0.13 for buster-security.

Attached are debdiffs against the versions relative to what's in
bullseye. Fortunately openjdk is the only reverse dep of jtreg/jtharness.

That's not great, but still less worse than firefox/rust :-)

Debdiff below.

diff -Nru jtharness-6.0-b15/debian/changelog jtharness-6.0-b15/debian/changelog
--- jtharness-6.0-b15/debian/changelog  2021-01-21 15:33:45.0 +
+++ jtharness-6.0-b15/debian/changelog  2021-11-19 16:17:12.0 +
@@ -1,3 +1,10 @@
+jtharness (6.0-b15-1~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster, needed for latest OpenJDK 11.x release
+- Switch to debhelper 12
+
+ -- Moritz Muehlenhoff   Fri, 19 Nov 2021 16:17:12 +
+
 jtharness (6.0-b15-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru jtharness-6.0-b15/debian/compat jtharness-6.0-b15/debian/compat
--- jtharness-6.0-b15/debian/compat 1970-01-01 00:00:00.0 +
+++ jtharness-6.0-b15/debian/compat 2021-11-19 16:17:12.0 +
@@ -0,0 +1 @@
+12
diff -Nru jtharness-6.0-b15/debian/control jtharness-6.0-b15/debian/control
--- jtharness-6.0-b15/debian/control2021-01-21 15:18:46.0 +
+++ jtharness-6.0-b15/debian/control2021-11-19 16:17:12.0 +
@@ -5,7 +5,7 @@
 Uploaders: Guillaume Mazoyer 
 Build-Depends:
  ant,
- debhelper-compat (= 13),
+ debhelper,
  default-jdk,
  javahelper,
  junit4,

Bug#1000479: buster-pu: package jtreg/5.1-b01-2~deb10u1

2021-11-23 Thread Moritz Muehlenhoff 
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ebo...@apache.org, d...@debian.org

The build requirements for openjdk-11 were bumped, starting with
11.0.13 jtreg 5 (and along with it a jtharness 6) are required to
run the test suite. Since we need to follow 11.0.x releases for
security updates, this blocks an update of 11.0.13 for buster-security.

Attached are debdiffs against the versions relative to what's in
bullseye. Fortunately openjdk is the only reverse dep of jtreg/jtharness.

That's not great, but still less worse than firefox/rust :-)

Debdiff below.

diff -Nru jtreg-5.1-b01/debian/changelog jtreg-5.1-b01/debian/changelog
--- jtreg-5.1-b01/debian/changelog  2020-07-15 04:28:47.0 +
+++ jtreg-5.1-b01/debian/changelog  2021-11-19 16:26:05.0 +
@@ -1,3 +1,10 @@
+jtreg (5.1-b01-2~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster, needed for latest OpenJDK 11.x release
+- Switch to debhelper 12
+
+ -- Moritz Muehlenhoff   Fri, 19 Nov 2021 16:26:05 +
+
 jtreg (5.1-b01-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru jtreg-5.1-b01/debian/compat jtreg-5.1-b01/debian/compat
--- jtreg-5.1-b01/debian/compat 1970-01-01 00:00:00.0 +
+++ jtreg-5.1-b01/debian/compat 2021-11-19 16:26:05.0 +
@@ -0,0 +1 @@
+12
diff -Nru jtreg-5.1-b01/debian/control jtreg-5.1-b01/debian/control
--- jtreg-5.1-b01/debian/control2020-07-15 04:28:47.0 +
+++ jtreg-5.1-b01/debian/control2021-11-19 16:26:05.0 +
@@ -5,7 +5,7 @@
 Uploaders: Guillaume Mazoyer 
 Build-Depends:
  ant,
- debhelper-compat (= 13),
+ debhelper,
  default-jdk,
  help2man,
  javahelp2,

Re: 11.2 planning

2021-11-23 Thread Andy Simpkins 

On 23/11/2021 20:18, Steve McIntyre wrote:

Hey Adam!

On Tue, Nov 23, 2021 at 08:12:11PM +, Adam Barratt wrote:


It's (a little past) time that we organised the next point release. As
an "every other" release, this time will only be for stable.

Any of the first three weekends of December would work for me, although
the 4th is my least preferred as it means freezing over the coming
weekend and I'm not sure if I'll have time to do a fair job of dealing
with things before that.

tl;dr, suggested dates:

December 4th [least preferable for me]
December 11th
December 18th


4th December is a no-go for me, but the 11th and 18th look OK.



Likewise 11th & 18th December are good for us (can't do 4th either)

/Andy & Isy

Bug#1000477: bullseye-pu: package gmp/2:6.2.1+dfsg-1+deb11u1

2021-11-23 Thread Anton Gladky 
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu


Dear release team,

I have prepared a fix for bullseye, fixing CVE-2021-43618.
The fix was also successfully fixed in unstable and testing.
Gitlab-CI is employed for the package testing. Diff is aattached.

[ Checklist ]
 [x] *all* changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [x] attach debdiff against the package in (old)stable
 [x] the issue is verified as fixed in unstable

Thanks

Anton
diff -Nru gmp-6.2.1+dfsg/debian/changelog gmp-6.2.1+dfsg/debian/changelog
--- gmp-6.2.1+dfsg/debian/changelog 2020-11-15 19:04:37.0 +0100
+++ gmp-6.2.1+dfsg/debian/changelog 2021-11-23 21:37:19.0 +0100
@@ -1,3 +1,10 @@
+gmp (2:6.2.1+dfsg-1+deb11u1) bullseye; urgency=medium
+
+  * [ba91bc2] Add .gitlab-ci.yml
+  * [a848ad6] Avoid bit size overflows. CVE-2021-43618
+
+ -- Anton Gladky   Tue, 23 Nov 2021 21:37:19 +0100
+
 gmp (2:6.2.1+dfsg-1) unstable; urgency=medium
 
   [ Steve Robbins ]
diff -Nru gmp-6.2.1+dfsg/debian/.gitlab-ci.yml 
gmp-6.2.1+dfsg/debian/.gitlab-ci.yml
--- gmp-6.2.1+dfsg/debian/.gitlab-ci.yml1970-01-01 01:00:00.0 
+0100
+++ gmp-6.2.1+dfsg/debian/.gitlab-ci.yml2021-11-23 21:31:26.0 
+0100
@@ -0,0 +1,6 @@
+include:
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
+variables:
+  RELEASE: 'bullseye'
+  SALSA_CI_DISABLE_REPROTEST: 1
+  SALSA_CI_DISABLE_BLHC: 1
diff -Nru gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch 
gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch
--- gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch  1970-01-01 
01:00:00.0 +0100
+++ gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch  2021-11-23 
21:36:27.0 +0100
@@ -0,0 +1,25 @@
+# Origin: https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e
+# HG changeset patch
+# User Marco Bodrato 
+# Date 1634836009 -7200
+# Node ID 561a9c25298e17bb01896801ff353546c6923dbd
+# Parent  e1fd9db13b475209a864577237ea4b9105b3e96e
+mpz/inp_raw.c: Avoid bit size overflows
+
+Index: gmp/mpz/inp_raw.c
+===
+--- gmp.orig/mpz/inp_raw.c
 gmp/mpz/inp_raw.c
+@@ -88,8 +88,11 @@ mpz_inp_raw (mpz_ptr x, FILE *fp)
+ 
+   abs_csize = ABS (csize);
+ 
++  if (UNLIKELY (abs_csize > ~(mp_bitcnt_t) 0 / 8))
++return 0; /* Bit size overflows */
++
+   /* round up to a multiple of limbs */
+-  abs_xsize = BITS_TO_LIMBS (abs_csize*8);
++  abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8);
+ 
+   if (abs_xsize != 0)
+ {
diff -Nru gmp-6.2.1+dfsg/debian/patches/series 
gmp-6.2.1+dfsg/debian/patches/series
--- gmp-6.2.1+dfsg/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ gmp-6.2.1+dfsg/debian/patches/series2021-11-15 22:20:32.0 
+0100
@@ -0,0 +1 @@
+CVE-2021-43618.patch

Processed: icingaweb2: Does not work with PHP 8.1

2021-11-23 Thread Debian Bug Tracking System 
Processing control commands:

> forwarded -1 https://github.com/Icinga/icingaweb2/issues/4609
Bug #1000474 [src:icingaweb2] icingaweb2: Does not work with PHP 8.1
Set Bug forwarded-to-address to 
'https://github.com/Icinga/icingaweb2/issues/4609'.
> block 976811 by -1
Bug #976811 [release.debian.org] transition: php8.1
976811 was blocked by: 977396 977403 977377 977404 977373 977388 977389 977340 
980567 978457 977385 977186 977379 977378 977401 977687 978151 977376 977337 
977384 977400 977658
976811 was not blocking any bugs.
Added blocking bug(s) of 976811: 1000474

-- 
1000474: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000474
976811: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1000473: buster-pu: package gmp/gmp_6.1.2+dfsg-4+deb10u1

2021-11-23 Thread Anton Gladky 
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu


Dear release team,

I have prepared a fix for buster, fixing CVE-2021-43618.
The fix was also successfully fixed in unstable and testing.
Gitlab-CI is employed for the package testing. Diff is applied.
Thanks

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

Thanks

Anton
diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog
--- gmp-6.1.2+dfsg/debian/changelog 2018-12-02 07:39:34.0 +0100
+++ gmp-6.1.2+dfsg/debian/changelog 2021-11-23 21:09:08.0 +0100
@@ -1,3 +1,10 @@
+gmp (2:6.1.2+dfsg-4+deb10u1) buster; urgency=medium
+
+  * [1f4ce6d] Add .gitlab-ci.yml
+  * [df6d314] Avoid bit size overflows. CVE-2021-43618
+
+ -- Anton Gladky   Tue, 23 Nov 2021 21:09:08 +0100
+
 gmp (2:6.1.2+dfsg-4) unstable; urgency=medium
 
   * Team Upload.
diff -Nru gmp-6.1.2+dfsg/debian/.gitlab-ci.yml 
gmp-6.1.2+dfsg/debian/.gitlab-ci.yml
--- gmp-6.1.2+dfsg/debian/.gitlab-ci.yml1970-01-01 01:00:00.0 
+0100
+++ gmp-6.1.2+dfsg/debian/.gitlab-ci.yml2021-11-23 21:04:00.0 
+0100
@@ -0,0 +1,6 @@
+include:
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
+variables:
+  RELEASE: 'buster'
+  SALSA_CI_DISABLE_REPROTEST: 1
+  SALSA_CI_DISABLE_BLHC: 1
diff -Nru gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch 
gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch
--- gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch  1970-01-01 
01:00:00.0 +0100
+++ gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch  2021-11-23 
21:06:22.0 +0100
@@ -0,0 +1,25 @@
+# Origin: https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e
+# HG changeset patch
+# User Marco Bodrato 
+# Date 1634836009 -7200
+# Node ID 561a9c25298e17bb01896801ff353546c6923dbd
+# Parent  e1fd9db13b475209a864577237ea4b9105b3e96e
+mpz/inp_raw.c: Avoid bit size overflows
+
+Index: gmp/mpz/inp_raw.c
+===
+--- gmp.orig/mpz/inp_raw.c
 gmp/mpz/inp_raw.c
+@@ -89,8 +89,11 @@ mpz_inp_raw (mpz_ptr x, FILE *fp)
+ 
+   abs_csize = ABS (csize);
+ 
++  if (UNLIKELY (abs_csize > ~(mp_bitcnt_t) 0 / 8))
++return 0; /* Bit size overflows */
++
+   /* round up to a multiple of limbs */
+-  abs_xsize = BITS_TO_LIMBS (abs_csize*8);
++  abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8);
+ 
+   if (abs_xsize != 0)
+ {
diff -Nru gmp-6.1.2+dfsg/debian/patches/series 
gmp-6.1.2+dfsg/debian/patches/series
--- gmp-6.1.2+dfsg/debian/patches/series2018-12-02 07:39:27.0 
+0100
+++ gmp-6.1.2+dfsg/debian/patches/series2021-11-23 21:06:09.0 
+0100
@@ -1 +1,2 @@
 gmp-exception-sigfpe.patch
+CVE-2021-43618.patch

Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

2021-11-23 Thread Roberto C. Sanchez 
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

SRM,

In preparing the rustc 1.51 upload/backport (to support backports of the
latest firefox-esr and thunderbird packages) it has been suggested that
to avoid some issues associated with providing a significant new version
of rustc in the rustc binary package (along with the associated library
packages), that I prepare the 1.51 rustc package with a different name.
Following the model of what was done for gcc, nasm, and nodejs, I was
considering source package rustc-mozilla with a single binary package
(also rustc-mozilla) to ensure that rdeps don't end up getting surprised
by a new rustc.  Would this be considered acceptable for the bullseye
and buster uploads of rustc 1.51?

(I intend to file a separate bug for buster-pu once I receive some
direction via this bug.)

Regards,

- -Roberto


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAmGdTOEACgkQLNd4Xt2n
sg+m+Q/7BN5tycR2w/9DjyOIHAlC/rrOOfsJraa1gORDKf5pT9GMk7J3oJanKLOI
YsWSUlC1a+4anQWGhGE+IMz50r5U01hZ7JhdnJhcSiLv+18gWY5LZB0fgbO/TvRG
2C95uubCYAePg7TTOd9fQRhuEBCgh+h0R+jN8EdNlJRRfEGZ7pkYQ3YOlkVJYztU
LQjWALZiMBbsh9ZxVq/zvys5nD2CO326M3PILGOFyqp/GFWrraEpppQlcjEqjemv
v7ygEzDvSJasv0AMAVIbQGrWWO/UeqMPAcwOVR0JGhz/06gDXxr5ubV53RbuhSai
Nwub60JaufIhm6clvbMmto+w0tTyeIM9IGTgyQq1j7ah9belvK43Rx2lScnfs+4c
kimppFDI4xei4aMzct+3/RgSBsijibH2cWfIPwiH6R8PuBZRDglAEaABsmT08WrS
EpVmT9gO+7Bkqo+v7uysvLQYlJ0R14WC4VB/yoWJSwmIqAg3yuHhdmJtSYbehFuA
Y5fKNwg4/hAvdTLwU9s9Q+cCEId2RWbnIKyS0wNgEStNTe12ue9P7POSFKGnXLGx
sVo4bg8FG+U2sJ12P0nVrRdxGT/OuKjqp5PpZZ+JF00sqKEArqkiphMiwnnkCnUD
k1YcSIn+E0xh+k8+GK1NxkJX8V9Vsteoba34SqadJ6LRvBF3Lz0=
=i90C
-END PGP SIGNATURE-

Re: 11.2 planning

2021-11-23 Thread Steve McIntyre 
Hey Adam!

On Tue, Nov 23, 2021 at 08:12:11PM +, Adam Barratt wrote:
>
>It's (a little past) time that we organised the next point release. As
>an "every other" release, this time will only be for stable.
>
>Any of the first three weekends of December would work for me, although
>the 4th is my least preferred as it means freezing over the coming
>weekend and I'm not sure if I'll have time to do a fair job of dealing
>with things before that.
>
>tl;dr, suggested dates:
>
>December 4th [least preferable for me]
>December 11th
>December 18th

4th December is a no-go for me, but the 11th and 18th look OK.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

11.2 planning

2021-11-23 Thread Adam D. Barratt 
Hi,

It's (a little past) time that we organised the next point release. As
an "every other" release, this time will only be for stable.

Any of the first three weekends of December would work for me, although
the 4th is my least preferred as it means freezing over the coming
weekend and I'm not sure if I'll have time to do a fair job of dealing
with things before that.

tl;dr, suggested dates:

December 4th [least preferable for me]
December 11th
December 18th

Thanks,

Adam

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

2021-11-23 Thread Paul Gevers 

Hi Ondřej,

On 23-11-2021 11:52, Ondřej Surý wrote:

On 22. 11. 2021, at 22:28, David Prévot  wrote:

I’m happy to upload it if you or the release team agree. I don’t
mind if the transition gets started right now either (even if we
have no proper php8.1 as default in experimental to get a grasp of
expected issues). >

I’ve just uploaded a version with your fix.


Thanks a lot.


David, can we now agree on a timeframe when we start the transition?


As a Release Team member I value the input from David on this matter, 
but it's not up to him to decide. That said, I'd love the PHP community 
in Debian (I assume I can take Debian PHP Maintainers + Debian PHP PEAR 
Maintainers for that, please correct me if I'm wrong) to align on a 
transition plan and share that with us. As a Release Team member, I'd 
like to see a plan (maybe I outlined it below already) where we can hope 
for a reasonable short time where php-defaults in unstable and testing 
are out of sync. Practically that means that most of the issues need to 
be identified, and sufficient progress needs to be made, *before* the 
upload to unstable, which starts the transition. We can remove some 
packages where progress isn't reasonably achievable in a timely matter, 
but we can't remove half the reverse dependencies of php.


Experimental is the ideal place to find that out. I does require 
somebody to go through the regressions and file bug though, this doesn't 
happen magically. I think David offered help there. I (Release Team 
member hat *off*) am willing to help a bit too. I welcome everybody to 
file issues related to switching from php7.4 to php8.1 and add a block 
on this bug. That way, we can generate a good overview of where we 
stand. (The cacti issue seems to have been resolved with my latest 
upload; one issue down). David, I think you already said you wouldn't 
mind if the transition already started now, is that the stance of the 
Debian PHP PEAR Maintainers? How much of the broken reverse dependencies 
are outside that teams maintenance (approximately)?



And I would prefer if we roughly agree on a timeframe when we start
the transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it
is ready upstream, so the ftp-masters have time, and keep uploading
rcN versions (this will usually take few months) and start the
transition right away when 8.2.0 is golden (December 2022). Would
that work?
The Release Team _very much_ welcomes staging/testing these things in 
experimental exactly as you propose. So by all means, upload early, 
including the relevant php-defaults too. Similar as for the current 
situation, if the amount of fall out has been identified, bugs filed and 
(most) solutions available we can go ahead. We can't commit to an ACK 
already (it really depends on the amount of open issues), but with the 
right preparation I'd say it's very doable. But it also depends a bit on 
the cooperation of the maintainers of your reverse dependencies and/or 
NMU actions. This takes time and coordination.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

2021-11-23 Thread Christoph Biedl 
Julien Cristau wrote...

> Would you mind providing the old/new/proposed versions of http_parser.h?
> (this is me being lazy, sorry, if I'm being too much of a pain I can go
> and figure them out for myself, just let me know).

Not that much on my side, so find the files attached. The name for the
first (old version) might be a bit odd but this way tools meld "meld
*.h" will pick them in chronological order.

Christoph
/* Copyright Joyent, Inc. and other Node contributors. All rights reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to
 * deal in the Software without restriction, including without limitation the
 * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
 * sell copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 * IN THE SOFTWARE.
 */
#ifndef http_parser_h
#define http_parser_h
#ifdef __cplusplus
extern "C" {
#endif

/* Also update SONAME in the Makefile whenever you change these. */
#define HTTP_PARSER_VERSION_MAJOR 2
#define HTTP_PARSER_VERSION_MINOR 8
#define HTTP_PARSER_VERSION_PATCH 1

#include 
#if defined(_WIN32) && !defined(__MINGW32__) && \
  (!defined(_MSC_VER) || _MSC_VER<1600) && !defined(__WINE__)
#include 
typedef __int8 int8_t;
typedef unsigned __int8 uint8_t;
typedef __int16 int16_t;
typedef unsigned __int16 uint16_t;
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
#else
#include 
#endif

/* Compile with -DHTTP_PARSER_STRICT=0 to make less checks, but run
 * faster
 */
#ifndef HTTP_PARSER_STRICT
# define HTTP_PARSER_STRICT 1
#endif

/* Maximium header size allowed. If the macro is not defined
 * before including this header then the default is used. To
 * change the maximum header size, define the macro in the build
 * environment (e.g. -DHTTP_MAX_HEADER_SIZE=). To remove
 * the effective limit on the size of the header, define the macro
 * to a very large number (e.g. -DHTTP_MAX_HEADER_SIZE=0x7fff)
 */
#ifndef HTTP_MAX_HEADER_SIZE
# define HTTP_MAX_HEADER_SIZE (80*1024)
#endif

typedef struct http_parser http_parser;
typedef struct http_parser_settings http_parser_settings;


/* Callbacks should return non-zero to indicate an error. The parser will
 * then halt execution.
 *
 * The one exception is on_headers_complete. In a HTTP_RESPONSE parser
 * returning '1' from on_headers_complete will tell the parser that it
 * should not expect a body. This is used when receiving a response to a
 * HEAD request which may contain 'Content-Length' or 'Transfer-Encoding:
 * chunked' headers that indicate the presence of a body.
 *
 * Returning `2` from on_headers_complete will tell parser that it should not
 * expect neither a body nor any futher responses on this connection. This is
 * useful for handling responses to a CONNECT request which may not contain
 * `Upgrade` or `Connection: upgrade` headers.
 *
 * http_data_cb does not return data chunks. It will be called arbitrarily
 * many times for each string. E.G. you might get 10 callbacks for "on_url"
 * each providing just a few characters more data.
 */
typedef int (*http_data_cb) (http_parser*, const char *at, size_t length);
typedef int (*http_cb) (http_parser*);


/* Status Codes */
#define HTTP_STATUS_MAP(XX) \
  XX(100, CONTINUE,Continue)\
  XX(101, SWITCHING_PROTOCOLS, Switching Protocols) \
  XX(102, PROCESSING,  Processing)  \
  XX(200, OK,  OK)  \
  XX(201, CREATED, Created) \
  XX(202, ACCEPTED,Accepted)\
  XX(203, NON_AUTHORITATIVE_INFORMATION,   Non-Authoritative Information)   \
  XX(204, NO_CONTENT,  No Content)  \
  XX(205, RESET_CONTENT,   Reset Content)   \
  XX(206, PARTIAL_CONTENT, Partial Content) \
  XX(207, MULTI_STATUS,Multi-Status)\
  XX(208, ALREADY_REPORTED,

Processed: Re: Bug#998057: transition: r-api-bioc-3.14

2021-11-23 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 = confirmed
Bug #998057 [release.debian.org] transition: r-api-bioc-3.14
Added tag(s) confirmed.

-- 
998057: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998057
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#998057: transition: r-api-bioc-3.14

2021-11-23 Thread Sebastian Ramacher 
Control: tags -1 = confirmed

On 2021-11-23 23:32:46, Nilesh Patra wrote:
> Hi Sebastian,
> 
> On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher  
> wrote:
> > > Hi,
> > > Bioconductor 3.14 was released [1].
> > > 
> > > [1] https://bioconductor.org/news/bioc_3_14_release/
> > > 
> > > Like for previous r-api-bioc transitions, all reverse dependencies
> > > need a manual upgrade to the new upstream releases, they are not
> > > binNMU-able. The Debian R Packages team will do so.
> > > 
> > > Please set up a tracker manually, since this is a transition of a
> > > virtual package name.
> > 
> > Let's do this one after gsl
> 
> Sorry to get on your nerves, but since it has been a little more than two 
> weeks since
> you sent this email, is there any update on gsl transition, or is it nearing 
> completion or so?
> Can bioc start sometime soon?

Please go ahead. If the two transitions need to be untangled, I'll
temporarily remove r-bioc-dirichletmultinomial and r-bioc-tfbstools from
testing.

Cheers

> 
> Let me know.
> 
> Regards,
> Nilesh



-- 
Sebastian Ramacher

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

2021-11-23 Thread Dirk Eddelbuettel 


On 22 November 2021 at 09:08, Patrick Alken wrote:
| Hi all, sorry for all this trouble. I will try to make a new GSL release 
| with the correct numbers.

Much appreciate it!

Sebastian, we'll then run a new transition with gsl 2.8 (or whichever version
number it will be) and its new somajor.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#998057: transition: r-api-bioc-3.14

2021-11-23 Thread Nilesh Patra 
Hi Sebastian,

On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher  
wrote:
> > Hi,
> > Bioconductor 3.14 was released [1].
> > 
> > [1] https://bioconductor.org/news/bioc_3_14_release/
> > 
> > Like for previous r-api-bioc transitions, all reverse dependencies
> > need a manual upgrade to the new upstream releases, they are not
> > binNMU-able. The Debian R Packages team will do so.
> > 
> > Please set up a tracker manually, since this is a transition of a
> > virtual package name.
> 
> Let's do this one after gsl

Sorry to get on your nerves, but since it has been a little more than two weeks 
since
you sent this email, is there any update on gsl transition, or is it nearing 
completion or so?
Can bioc start sometime soon?

Let me know.

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

2021-11-23 Thread Julien Cristau 
On Mon, Nov 01, 2021 at 12:01:51AM +0100, Christoph Biedl wrote:
> Adam D. Barratt wrote...
> 
> > Do you already have a proposed new upload / debdiff?
> 
> After many more tests and some more discussion with Hilko, find attached
> a debdiff that in my opinion is ready for upload. The patch itself is
> unmodified, I just enhanced the description for posterity.
> 
> About next steps, I would do the upload in the next days. Let me know if
> you prefer other things to happen first or instead.
> 
Hi Christoph,

Would you mind providing the old/new/proposed versions of http_parser.h?
(this is me being lazy, sorry, if I'm being too much of a pain I can go
and figure them out for myself, just let me know).

Thanks,
Julien

Bug#1000458: bullseye-pu: package wget/1.21-1+deb11u1

2021-11-23 Thread plugwash 
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

When downloading a file greater than 2GB on a 32-bit system wget on bullseye
will truncate it to 2GB. No error is reported, the length of the file is simply
reported as less than it's true length. This was reported to me by raspberry pi
staff, but I can reproduce it in a Debian i386 environment, so it's not
raspberry pi, raspbian or arm specific.

I confirmed that the issue did not affect bookworm and after some searching
found the upstream commit and bug report that fix it. 
https://gitlab.com/gnuwget/wget/-/commit/90631a6fe54eabd9c80ede5c70bc916719e76cfe

I have rated this issue as important, being unable to download large files (for
example OS images) is a significant restriction on the usefulness of wget. There
is a possible argument that it deserves grave severity based on "non-serious
data loss" (for example if someone used wget to copy a file to another system
before deleting the original) but I think that argument is tenuous, so I decided
to stick with important.

I filed this as bug 999744 in Debian  on the 15th November and have not received
a maintainer response, hence I am starting the PU process myself. I have tested
the fix in raspbian bullseye and also in a debian bullsyeye i386 chroot. I have
also released the fix to raspbian bullseye.
diff -Nru wget-1.21/debian/changelog wget-1.21/debian/changelog
--- wget-1.21/debian/changelog  2021-01-02 10:58:25.0 +
+++ wget-1.21/debian/changelog  2021-11-23 14:34:25.0 +
@@ -1,3 +1,11 @@
+wget (1.21-1+deb11u1) bullseye-staging; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix downloads over 2GB on 32-bit systems.
+closes: bug#999744
+
+ -- Peter Michael Green   Tue, 23 Nov 2021 14:34:25 +
+
 wget (1.21-1) unstable; urgency=medium
 
   * new upstream release from 2020-12-31
diff -Nru wget-1.21/debian/patches/fix-large-downloads-on-32-bit 
wget-1.21/debian/patches/fix-large-downloads-on-32-bit
--- wget-1.21/debian/patches/fix-large-downloads-on-32-bit  1970-01-01 
00:00:00.0 +
+++ wget-1.21/debian/patches/fix-large-downloads-on-32-bit  2021-11-23 
14:31:49.0 +
@@ -0,0 +1,26 @@
+Debian patch based on the upstream commit below, defuzzed
+in the context of the debian package.
+
+commit 90631a6fe54eabd9c80ede5c70bc916719e76cfe
+Author: Tim Rühsen 
+Date:   Sun Apr 11 12:53:16 2021 +0200
+
+* src/wget.h: Use strtoll() for str_to_wgint
+
+This fixes a regression reported at https://savannah.gnu.org/bugs/?60353.
+
+Reported-by: Michal Ruprich
+
+Index: wget-1.21/src/wget.h
+===
+--- wget-1.21.orig/src/wget.h
 wget-1.21/src/wget.h
+@@ -144,7 +144,7 @@ typedef int64_t wgint;
+ #define WGINT_MAX INT64_MAX
+ typedef wgint SUM_SIZE_INT;
+ 
+-#define str_to_wgint strtol
++#define str_to_wgint strtoll
+ 
+ #include "options.h"
+ 
diff -Nru wget-1.21/debian/patches/series wget-1.21/debian/patches/series
--- wget-1.21/debian/patches/series 2019-07-20 16:10:06.0 +
+++ wget-1.21/debian/patches/series 2021-11-23 14:31:49.0 +
@@ -1,3 +1,4 @@
 wget-doc-remove-usr-local-in-sample.wgetrc
 wget-doc-remove-usr-local-in-wget.texi
 wget-passive_ftp-default
+fix-large-downloads-on-32-bit

Impossible to verify GPG signature on Debian Release file

2021-11-23 Thread john doe 

Hi,

I'm trying to verify the Debian's Release file but to no avail:

$gpg --keyserver keyring.debian.org --keyserve
r-options auto-key-retrieve --verify Release.gpg Release
gpg: Signature made 10/9/2021 11:35:49 AM Romance Daylight Time
gpg:using RSA key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
gpg: requesting key 0x648ACFD622F3D138 from hkp://keyring.debian.org
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: No public key
gpg: Signature made 10/9/2021 11:35:49 AM Romance Daylight Time
gpg:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
gpg: requesting key 0x0E98404D386FA1D9 from hkp://keyring.debian.org
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: No public key
gpg: Signature made 10/9/2021 11:49:02 AM Romance Daylight Time
gpg:using RSA key A4285295FC7B1A81600062A9605C66F00D6C9793
gpg:issuer "debian-release@lists.debian.org"
gpg: requesting key 0x605C66F00D6C9793 from hkp://keyring.debian.org
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: Can't check signature: No public key
$ gpg --locate-keys debian-release@lists.debian
.org
gpg: error retrieving 'debian-release@lists.debian.org' via WKD:
Certificate exp
ired
gpg: error reading key: Certificate expired


The Release file and signature file are downloaded from (1) and (2).

It looks like some keys are missing from the Debian keyring.


1)  http://ftp.debian.org/debian/dists/stable/Release
2)  http://ftp.debian.org/debian/dists/stable/Release.gpg

--
John Doe

Bug#1000454: bullseye-pu: package gdal/3.2.2+dfsg-2+deb11u1

2021-11-23 Thread Bas Couwenberg 
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org

[ Reason ]
The LVBAG driver in GDAL 3.2.2 is unable to process BAG 2.0 Extract files
correctly. Since October 2021 BAG 1.0 Extract files are no longer updated,
so users are expected to switch their processing to BAG 2.0.

GDAL 3.3.0 and 3.4.0 contain changes required to process BAG 2.0 Extract
files correctly.

[ Impact ]
Unable to update their BAG databases with current data.

[ Tests ]
The changes are covered by the upstream CI, and have been manually tested
on a bulleye system.

[ Risks ]
Low, only the relevant changes for this specific driver are added.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The branch for the stable update is updated in gbp.conf & the Vcs-Git URL.

The relevant upstream changes are added as patches, and stripped from
unrelated changes.

[ Other info ]
N/A

Kind Regards,

Bas
diff -Nru gdal-3.2.2+dfsg/debian/changelog gdal-3.2.2+dfsg/debian/changelog
--- gdal-3.2.2+dfsg/debian/changelog2021-06-21 21:06:09.0 +0200
+++ gdal-3.2.2+dfsg/debian/changelog2021-11-23 10:11:54.0 +0100
@@ -1,3 +1,11 @@
+gdal (3.2.2+dfsg-2+deb11u1) bullseye; urgency=medium
+
+  * Update branch in gbp.conf & Vcs-Git URL.
+  * Add upstream patches to fix BAG 2.0 Extract support in LVBAG driver.
+(closes: #1000437)
+
+ -- Bas Couwenberg   Tue, 23 Nov 2021 10:11:54 +0100
+
 gdal (3.2.2+dfsg-2) unstable; urgency=medium
 
   * Drop Breaks from gdal-data to make libgdal20 & libgdal28 co-installable.
diff -Nru gdal-3.2.2+dfsg/debian/control gdal-3.2.2+dfsg/debian/control
--- gdal-3.2.2+dfsg/debian/control  2021-06-21 21:05:55.0 +0200
+++ gdal-3.2.2+dfsg/debian/control  2021-11-23 10:11:54.0 +0100
@@ -62,7 +62,7 @@
 Build-Conflicts: automake1.11
 Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/debian-gis-team/gdal
-Vcs-Git: https://salsa.debian.org/debian-gis-team/gdal.git
+Vcs-Git: https://salsa.debian.org/debian-gis-team/gdal.git -b bullseye
 Homepage: http://www.gdal.org/
 
 Package: libgdal28
diff -Nru gdal-3.2.2+dfsg/debian/gbp.conf gdal-3.2.2+dfsg/debian/gbp.conf
--- gdal-3.2.2+dfsg/debian/gbp.conf 2021-06-21 21:05:55.0 +0200
+++ gdal-3.2.2+dfsg/debian/gbp.conf 2021-11-23 10:11:54.0 +0100
@@ -6,7 +6,7 @@
 
 # The default name for the Debian branch is "master".
 # Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = bullseye
 
 # git-import-orig uses the following names for the upstream tags.
 # Change the value if you are not using git-import-orig
diff -Nru 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
--- 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
  1970-01-01 01:00:00.0 +0100
+++ 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
  2021-11-23 10:11:54.0 +0100
@@ -0,0 +1,170 @@
+Description: Add a cppcheck_2004 CI target, and fix related issues
+Author: Even Rouault 
+Origin: 
https://github.com/OSGeo/gdal/commit/6ff924dfc704776cbdeff1e0e23da6452cf06933
+Bug: https://github.com/OSGeo/gdal/pull/3516
+
+--- a/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp
 b/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp
+@@ -76,7 +76,7 @@ OGRLVBAGLayer::~OGRLVBAGLayer()
+ {
+ delete m_poFeature;
+ poFeatureDefn->Release();
+-CloseUnderlyingLayer();
++OGRLVBAGLayer::CloseUnderlyingLayer();
+ }
+ 
+ //
+@@ -217,7 +217,7 @@ void OGRLVBAGLayer::CreateFeatureDefn( c
+ OGRFieldDefn oField0("oorspronkelijkBouwjaar", OFTInteger);
+ 
+ poFeatureDefn->AddFieldDefn();
+-
++
+ AddIdentifierFieldDefn();
+ AddDocumentFieldDefn();
+ AddOccurrenceFieldDefn();
+@@ -235,14 +235,14 @@ void OGRLVBAGLayer::CreateFeatureDefn( c
+ OGRFieldDefn oField3("postcode", OFTString);
+ OGRFieldDefn oField4("typeAdresseerbaarObject", OFTString);
+ OGRFieldDefn oField5("openbareruimteRef", OFTString);
+-  
++
+ poFeatureDefn->AddFieldDefn();
+ poFeatureDefn->AddFieldDefn();
+ poFeatureDefn->AddFieldDefn();
+ poFeatureDefn->AddFieldDefn();
+ poFeatureDefn->AddFieldDefn();
+ poFeatureDefn->AddFieldDefn();
+- 
++
+ AddIdentifierFieldDefn();
+ AddDocumentFieldDefn();
+ AddOccurrenceFieldDefn();
+@@ -293,7 +293,7 @@ void OGRLVBAGLayer::CreateFeatureDefn( c
+

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

2021-11-23 Thread Ondřej Surý 
> On 22. 11. 2021, at 22:28, David Prévot  wrote:
> 
> I’m happy to upload it if you or the release team agree. I don’t mind if the 
> transition gets started right now either (even if we have no proper php8.1 as 
> default in experimental to get a grasp of expected issues).

I’ve just uploaded a version with your fix.

David, can we now agree on a timeframe when we start the transition?

And I would prefer if we roughly agree on a timeframe when we start the 
transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it is ready 
upstream, so the ftp-masters have time, and keep uploading rcN versions (this 
will usually take few months) and start the transition right away when 8.2.0 is 
golden (December 2022). Would that work?

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org