Bug#989291: unblock: fabric/2.5.0-0.3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org
Please unblock package fabric
The package has a missing dependency, and the bug has been marked RC:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956320
Adding the missing dependency fixes the issue. I have uploaded the fix
(debdiff inlined) to DELAYED/2, so it will be in sid on Wednesday.
unblock fabric/2.5.0-0.3
--
Kind regards,
Luca Boccassi
diff -Nru fabric-2.5.0/debian/changelog fabric-2.5.0/debian/changelog
--- fabric-2.5.0/debian/changelog 2019-12-08 15:58:47.0
+
+++ fabric-2.5.0/debian/changelog 2021-05-31 11:00:56.0
+0100
@@ -1,3 +1,10 @@
+fabric (2.5.0-0.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add dependency on python3-decorator (Closes: #956320)
+
+ -- Luca Boccassi Mon, 31 May 2021 11:00:56 +0100
+
fabric (2.5.0-0.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fabric-2.5.0/debian/control fabric-2.5.0/debian/control
--- fabric-2.5.0/debian/control 2019-12-08 15:55:45.0 +
+++ fabric-2.5.0/debian/control 2021-05-31 10:57:31.0 +0100
@@ -20,6 +20,7 @@
Package: fabric
Architecture: all
Depends: python3-fabric (>= ${source:Version}),
+ python3-decorator,
python3-pkg-resources,
${misc:Depends},
${python3:Depends},
signature.asc
Description: This is a digitally signed message part
Bug#986044: unblock: nvidia-graphics-drivers/460.67-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org Please unblock package nvidia-graphics-drivers [ Reason ] The new upstream LTS version 460.67 fixes several bugs, including an X.org crash. [ Impact ] X.org crash under certain conditions, and other minor bugs. There's also support for at least one new graphic card. [ Tests ] Tested with appropriate hardware and workload on a Bullseye desktop. [ Risks ] It's a proprietary non-free driver, so it is never possible to know the full extent of the changes. But the 460 series is intended for LTS. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] The debdiff excludes the binary blobs. unblock nvidia-graphics-drivers/460.67-1 $ debdiff --exclude NVIDIA-Linux-* nvidia-graphics-drivers_460.56-1.dsc nvidia- graphics-drivers_460.67-1.dsc diff -Nru --exclude 'NVIDIA-Linux-*' nvidia-graphics- drivers-460.56/debian/changelog nvidia-graphics-drivers-460.67/debian/changelog --- nvidia-graphics-drivers-460.56/debian/changelog 2021-02-27 23:26:36.0 + +++ nvidia-graphics-drivers-460.67/debian/changelog 2021-03-21 19:51:46.0 + @@ -1,3 +1,33 @@ +nvidia-graphics-drivers (460.67-1) unstable; urgency=medium + + * New upstream production branch release 460.67 (2021-03-18). +- Fixed a bug where using ray tracing extensions on multi-GPU setups could + result in application instability if the GPUs did not match. +- Fixed an issue that prevented G-SYNC from working properly after a mode + switch on Kepler-based GPUs. + * New upstream release 450 series. +- Fixed a driver installation failure on Linux kernel 5.11 release + candidates, where the NVIDIA kernel module failed to build with error + "error: implicit declaration of function 'sys_close'". + * New upstream release 390 series. +- Fixed a bug where vkCreateSwapchain could cause the X Server to crash when + an invalid imageFormat was provided. +- Fixed a driver installation failure on Linux kernel 5.11 release + candidates, where the NVIDIA kernel module failed to build with error + "fatal error: asm/kmap_types.h: No such file or directory". + + [ Luca Boccassi ] + * Update nv-readme.ids. + + -- Andreas Beckmann Sun, 21 Mar 2021 20:51:46 +0100 + +nvidia-graphics-drivers (460.56-2) unstable; urgency=medium + + * Add libnvidia-ml.so slave alternative if libnvidia-ml-dev is installed. +(Closes: #984881) + + -- Andreas Beckmann Wed, 10 Mar 2021 21:03:59 +0100 + nvidia-graphics-drivers (460.56-1) unstable; urgency=medium * New upstream production branch release 460.56 (2021-02-25). diff -Nru --exclude 'NVIDIA-Linux-*' nvidia-graphics- drivers-460.56/debian/nvidia-alternative.postinst.in nvidia-graphics- drivers-460.67/debian/nvidia-alternative.postinst.in --- nvidia-graphics-drivers-460.56/debian/nvidia-alternative.postinst.in 2021-02-27 23:26:36.0 + +++ nvidia-graphics-drivers-460.67/debian/nvidia-alternative.postinst.in 2021-03-21 19:51:46.0 + @@ -84,10 +84,14 @@ $(add_slave /etc/nvidia/nvidia-modprobe.conf nvidia- modprobe.conf /etc/#PRIVATE#/nvidia-modprobe.conf) $(add_slave /etc/nvidia/nvidia-load.conf nvidia-load.conf /etc/#PRIVATE#/nvidia-load.conf) " + libnvidia_ml_so_slave= + if [ -f /usr/include/nvml.h ]; then + libnvidia_ml_so_slave="$(add_multiarch_slave /usr/lib "" libnvidia-ml.so /usr/lib #PRIVATE#/)" + fi if echo "$slaves" | grep -q "slave" ; then - update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves + update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves $libnvidia_ml_so_slave # work around #916799 and re-register the alternative to clean- up leftover slaves - update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves + update-alternatives --install /usr/lib/nvidia/nvidia nvidia /usr/lib/#PRIVATE# #MAJOR# $slaves $conf_slaves $libnvidia_ml_so_slave else update-alternatives --remove nvidia /usr/lib/#PRIVATE# fi diff -Nru --exclude 'NVIDIA-Linux-*' nvidia-graphics- drivers-460.56/debian/nvidia-alternative.triggers.in nvidia-graphics- drivers-460.67/debian/nvidia-alternative.triggers.in --- nvidia-graphics-drivers-460.56/debian/nvidia-alternative.triggers.in 2021-02-27 23:26:36.0 + +++ nvidia-graphics-drivers-460.67/debian/nvidia-alternative.triggers.in 2021-03-21 19:51:46.0 + @
Bug#986409: unblock: azure-cosmos-python/3.1.1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package azure-cosmos-python
The new upload fixes a warning that appears to users on every package
installation/upgrade.
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985021
It also updates the source package metadata after the (somewhat) recent re-
organization of Python packages on Salsa.
unblock azure-cosmos-python/3.1.1-4
diff -Nru azure-cosmos-python-3.1.1/debian/changelog
azure-cosmos-python-3.1.1/debian/changelog
--- azure-cosmos-python-3.1.1/debian/changelog 2020-03-07 10:58:01.0
+
+++ azure-cosmos-python-3.1.1/debian/changelog 2021-03-12 12:02:24.0
+
@@ -1,3 +1,22 @@
+azure-cosmos-python (3.1.1-4) unstable; urgency=medium
+
+ [ Debian Janitor ]
+ * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
+Repository-Browse.
+
+ [ Ondřej Nový ]
+ * d/control: Update Maintainer field with new Debian Python Team
+contact address.
+ * d/control: Update Vcs-* fields with new Debian Python Team Salsa
+layout.
+
+ [ Luca Boccassi ]
+ * Bump Standards-Version to 4.5.1, no changes
+ * Bump debhelper-compat to 13
+ * Add patch to fix syntax warning on package install (Closes: #985021)
+
+ -- Luca Boccassi Fri, 12 Mar 2021 12:02:24 +
+
azure-cosmos-python (3.1.1-3) unstable; urgency=medium
* Remove build-dependency on pytest, all tests require connection to
diff -Nru azure-cosmos-python-3.1.1/debian/control
azure-cosmos-python-3.1.1/debian/control
--- azure-cosmos-python-3.1.1/debian/control2020-03-07 10:57:39.0
+
+++ azure-cosmos-python-3.1.1/debian/control2021-03-12 12:01:33.0
+
@@ -1,18 +1,18 @@
Source: azure-cosmos-python
-Maintainer: Debian Python Modules Team
+Maintainer: Debian Python Team
Uploaders: Luca Boccassi ,
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
dh-python,
python3-all,
python3-setuptools,
python3-sphinx,
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Section: python
Priority: optional
Rules-Requires-Root: no
Homepage: https://github.com/Azure/azure-cosmos-python
-Vcs-Browser: https://salsa.debian.org/python-team/modules/azure-cosmos-python
-Vcs-Git: https://salsa.debian.org/python-team/modules/azure-cosmos-python.git
+Vcs-Browser: https://salsa.debian.org/python-team/packages/azure-cosmos-python
+Vcs-Git: https://salsa.debian.org/python-team/packages/azure-cosmos-python.git
Testsuite: autopkgtest-pkg-python
Package: python3-azure-cosmos
diff -Nru azure-cosmos-python-3.1.1/debian/patches/series
azure-cosmos-python-3.1.1/debian/patches/series
--- azure-cosmos-python-3.1.1/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ azure-cosmos-python-3.1.1/debian/patches/series 2021-03-12
12:01:33.0 +
@@ -0,0 +1 @@
+syntax_warning.patch
diff -Nru azure-cosmos-python-3.1.1/debian/patches/syntax_warning.patch
azure-cosmos-python-3.1.1/debian/patches/syntax_warning.patch
--- azure-cosmos-python-3.1.1/debian/patches/syntax_warning.patch
1970-01-01 01:00:00.0 +0100
+++ azure-cosmos-python-3.1.1/debian/patches/syntax_warning.patch
2021-03-12 12:02:09.0 +
@@ -0,0 +1,15 @@
+Author: Luca Boccassi
+Forwarded: https://github.com/Azure/azure-cosmos-python/pull/207
+Description: fix syntax warning
+Bug-Debian: https://bugs.debian.org/985021
+--- a/azure/cosmos/session.py
b/azure/cosmos/session.py
+@@ -183,7 +183,7 @@
+ session_token =
response_headers[http_constants.HttpHeaders.SessionToken]
+
+ id_to_sessionlsn = {}
+-if session_token is not '':
++if session_token != '':
+ ''' extract id, lsn from the token. For p-collection,
+ the token will be a concatenation of pairs for each collection'''
+ token_pairs = session_token.split(',')
diff -Nru azure-cosmos-python-3.1.1/debian/upstream/metadata
azure-cosmos-python-3.1.1/debian/upstream/metadata
--- azure-cosmos-python-3.1.1/debian/upstream/metadata 1970-01-01
01:00:00.0 +0100
+++ azure-cosmos-python-3.1.1/debian/upstream/metadata 2021-03-12
12:01:33.0 +
@@ -0,0 +1,5 @@
+---
+Bug-Database: https://github.com/Azure/azure-cosmos-python/issues
+Bug-Submit: https://github.com/Azure/azure-cosmos-python/issues/new
+Repository: https://github.com/Azure/azure-cosmos-python.git
+Repository-Browse: https://github.com/Azure/azure-cosmos-python
Bug#986409: unblock: azure-cosmos-python/3.1.1-4
On Tue, 2021-04-06 at 21:40 +0200, Sebastian Ramacher wrote: > Control: tags -1 moreinfo confirmed > > On 2021-04-05 13:45:46 +0100, Luca Boccassi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package azure-cosmos-python > > > > The new upload fixes a warning that appears to users on every package > > installation/upgrade. > > See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985021 > > It also updates the source package metadata after the (somewhat) recent re- > > organization of Python packages on Salsa. > > > > unblock azure-cosmos-python/3.1.1-4 > > diff -Nru azure-cosmos-python-3.1.1/debian/changelog > > azure-cosmos-python-3.1.1/debian/changelog > > --- azure-cosmos-python-3.1.1/debian/changelog 2020-03-07 > > 10:58:01.0 + > > +++ azure-cosmos-python-3.1.1/debian/changelog 2021-03-12 > > 12:02:24.0 + > > @@ -1,3 +1,22 @@ > > +azure-cosmos-python (3.1.1-4) unstable; urgency=medium > > + > > + [ Debian Janitor ] > > + * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, > > +Repository-Browse. > > + > > + [ Ondřej Nový ] > > + * d/control: Update Maintainer field with new Debian Python Team > > +contact address. > > + * d/control: Update Vcs-* fields with new Debian Python Team Salsa > > +layout. > > + > > + [ Luca Boccassi ] > > + * Bump Standards-Version to 4.5.1, no changes > > + * Bump debhelper-compat to 13 > > + * Add patch to fix syntax warning on package install (Closes: #985021) > > + > > + -- Luca Boccassi Fri, 12 Mar 2021 12:02:24 + > > + > > azure-cosmos-python (3.1.1-3) unstable; urgency=medium > > > >* Remove build-dependency on pytest, all tests require connection to > > diff -Nru azure-cosmos-python-3.1.1/debian/control > > azure-cosmos-python-3.1.1/debian/control > > --- azure-cosmos-python-3.1.1/debian/control2020-03-07 > > 10:57:39.0 + > > +++ azure-cosmos-python-3.1.1/debian/control2021-03-12 > > 12:01:33.0 + > > @@ -1,18 +1,18 @@ > > Source: azure-cosmos-python > > -Maintainer: Debian Python Modules Team > > > > +Maintainer: Debian Python Team > > Uploaders: Luca Boccassi , > > -Build-Depends: debhelper-compat (= 12), > > +Build-Depends: debhelper-compat (= 13), > > Changes to the debhelper compat are no longer appropriate at this point > in the freeze. Please revert that. Once the new version is available in > unstable, please remove the moreinfo tag. Thanks for the review - I would rather not change this again. The package is trivial, and thus this version bump is trivial too, and has no discernible effect bar silencing Lintian. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#986758: unblock: systemd/247.3-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org
Please unblock package systemd
As requested by Michael, opening unblock ticket. Debdiff attached. Two
high-impact patches are backported from upstream and should be included
in Bullseye.
* Backport patch to fix assert with invalid LoadCredentials=
Regression introduced in v247, fixed in v249, see:
https://github.com/systemd/systemd/issues/19178
(Closes: #986302)
* network: Delay addition of IPv6 Proxy NDP addresses.
Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
networkd adds them". (Closes: #985510)
The first patch fixes a crash when a malformed option is set in any
unit.
unblock systemd/247.3-4
--
Kind regards,
Luca Boccassi
diff -Nru systemd-247.3/debian/changelog systemd-247.3/debian/changelog
--- systemd-247.3/debian/changelog 2021-03-11 17:09:35.0 +
+++ systemd-247.3/debian/changelog 2021-04-11 15:06:46.0 +0100
@@ -1,3 +1,18 @@
+systemd (247.3-4) unstable; urgency=medium
+
+ [ Luca Boccassi ]
+ * Backport patch to fix assert with invalid LoadCredentials=
+Regression introduced in v247, fixed in v249, see:
+https://github.com/systemd/systemd/issues/19178
+(Closes: #986302)
+
+ [ Michael Biebl ]
+ * network: Delay addition of IPv6 Proxy NDP addresses.
+Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
+networkd adds them". (Closes: #985510)
+
+ -- Michael Biebl Sun, 11 Apr 2021 16:06:46 +0200
+
systemd (247.3-3) unstable; urgency=medium
* pkg-config: make prefix overridable again (Closes: #984763)
diff -Nru systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch
--- systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch 2021-03-11 17:09:35.0 +
+++ systemd-247.3/debian/patches/debian/Downgrade-a-couple-of-warnings-to-debug.patch 2021-04-11 15:06:46.0 +0100
@@ -16,7 +16,7 @@
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
-index 4964249..2d48783 100644
+index 5b66fb1..df5669a 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -372,6 +372,7 @@ static int patch_var_run(
diff -Nru systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
--- systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch 1970-01-01 01:00:00.0 +0100
+++ systemd-247.3/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch 2021-04-11 15:06:46.0 +0100
@@ -0,0 +1,34 @@
+From: Luca Boccassi
+Date: Thu, 1 Apr 2021 22:18:29 +0100
+Subject: LoadCredentials: do not assert on invalid syntax
+
+LoadCredentials=foo causes an assertion to be triggered, as we
+are not checking that the rvalue's right hand side part is non-empty
+before using it in unit_full_printf.
+
+Fixes #19178
+
+# printf [Service]nLoadCredential=passwd.hashed-password.rootn > hello.service
+# systemd-analyze verify ./hello.service
+...
+Assertion 'format' failed at src/core/unit-printf.c:232, function unit_full_printf(). Aborting.
+Aborted (core dumped)
+
+(cherry picked from commit f7a6f1226e800f7695c2073675523062ea697aa4)
+---
+ src/core/load-fragment.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
+index 4964249..5b66fb1 100644
+--- a/src/core/load-fragment.c
b/src/core/load-fragment.c
+@@ -4569,7 +4569,7 @@ int config_parse_load_credential(
+ r = extract_first_word(&p, &word, ":", EXTRACT_DONT_COALESCE_SEPARATORS);
+ if (r == -ENOMEM)
+ return log_oom();
+-if (r <= 0) {
++if (r <= 0 || isempty(p)) {
+ log_syntax(unit, LOG_WARNING, filename, line, r, "Invalid syntax, ignoring: %s", rvalue);
+ return 0;
+ }
diff -Nru systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch
--- systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch 1970-01-01 01:00:00.0 +0100
+++ systemd-247.3/debian/patches/network-Delay-addition-of-IPv6-Proxy-NDP-addresses.patch 2021-04-11 15:06:46.0 +0100
@@ -0,0 +1,86 @@
+From: "Kevin P. Fleming"
+Date: Sat, 6 Feb 2021 10:58:43 -0500
+Subject: network: Delay addition of IPv6 Proxy NDP addresses
+
+Setting of IPv6 Proxy NDP addresses must be done at the same
+time as static addresses, static routes, and other link attributes
+that must be configured when the
Bug#986409: unblock: azure-cosmos-python/3.1.1-4
On Sun, 2021-04-11 at 14:29 +0200, Ivo De Decker wrote: > Hi, > > On Tue, Apr 06, 2021 at 09:21:10PM +0100, Luca Boccassi wrote: > > > Changes to the debhelper compat are no longer appropriate at this > > > point > > > in the freeze. Please revert that. Once the new version is > > > available in > > > unstable, please remove the moreinfo tag. > > > > Thanks for the review - I would rather not change this again. The > > package is trivial, and thus this version bump is trivial too, and > > has > > no discernible effect bar silencing Lintian. > > See the last entry at > https://release.debian.org/bullseye/FAQ.html "Changing the debhelper compat version changes the resulting packages, sometimes in complicated or unintended ways. Carefully checking the details of these changes is too much work when processing an unblock request." As mentioned, it's identical before/after. The only difference you can see is that a generated comment in a script doesn't end with a colon anymore: $ diffoscope python3-azure-cosmos_3.1.1-3_all.deb python3-azure-cosmos_3.1.1-4_all.deb --- python3-azure-cosmos_3.1.1-3_all.deb +++ python3-azure-cosmos_3.1.1-4_all.deb ├── file list │ @@ -1,3 +1,3 @@ │ --rw-r--r-- 0004 2020-03-07 10:58:01.00 debian-binary │ --rw-r--r-- 000 2328 2020-03-07 10:58:01.00 control.tar.xz │ --rw-r--r-- 00051572 2020-03-07 10:58:01.00 data.tar.xz │ +-rw-r--r-- 0004 2021-03-12 12:02:24.00 debian-binary │ +-rw-r--r-- 000 2324 2021-03-12 12:02:24.00 control.tar.xz │ +-rw-r--r-- 00051812 2021-03-12 12:02:24.00 data.tar.xz ├── control.tar.xz │ ├── control.tar │ │ ├── file list │ │ │ @@ -1,5 +1,5 @@ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2020-03-07 10:58:01.00 ./ │ │ │ --rw-r--r-- 0 root (0) root (0) 464 2020-03-07 10:58:01.00 ./control │ │ │ --rw-r--r-- 0 root (0) root (0) 4868 2020-03-07 10:58:01.00 ./md5sums │ │ │ --rwxr-xr-x 0 root (0) root (0) 266 2020-03-07 10:58:01.00 ./postinst │ │ │ --rwxr-xr-x 0 root (0) root (0) 415 2020-03-07 10:58:01.00 ./prerm │ │ │ +drwxr-xr-x 0 root (0) root (0)0 2021-03-12 12:02:24.00 ./ │ │ │ +-rw-r--r-- 0 root (0) root (0) 443 2021-03-12 12:02:24.00 ./control │ │ │ +-rw-r--r-- 0 root (0) root (0) 4868 2021-03-12 12:02:24.00 ./md5sums │ │ │ +-rwxr-xr-x 0 root (0) root (0) 265 2021-03-12 12:02:24.00 ./postinst │ │ │ +-rwxr-xr-x 0 root (0) root (0) 414 2021-03-12 12:02:24.00 ./prerm │ │ ├── ./control │ │ │ @@ -1,12 +1,12 @@ │ │ │ Package: python3-azure-cosmos │ │ │ Source: azure-cosmos-python │ │ │ -Version: 3.1.1-3 │ │ │ +Version: 3.1.1-4 │ │ │ Architecture: all │ │ │ -Maintainer: Debian Python Modules Team │ │ │ +Maintainer: Debian Python Team │ │ │ Installed-Size: 383 │ │ │ Depends: python3-requests, python3-six (>= 1.6), python3:any │ │ │ Section: python │ │ │ Priority: optional │ │ │ Homepage: https://github.com/Azure/azure-cosmos-python │ │ │ Description: Azure DocumentDB Python SDK │ │ │ This package provides the Python 3 modules for the Azure DocumentDB API. │ │ ├── ./md5sums │ │ │ ├── ./md5sums │ │ │ │┄ Files differ │ │ ├── ./postinst │ │ │ @@ -1,11 +1,11 @@ │ │ │ #!/bin/sh │ │ │ set -e │ │ │ │ │ │ -# Automatically added by dh_python3: │ │ │ +# Automatically added by dh_python3 │ │ │ if which py3compile >/dev/null 2>&1; then │ │ │ py3compile -p python3-azure-cosmos │ │ │ fi │ │ │ if which pypy3compile >/dev/null 2>&1; then │ │ │ pypy3compile -p python3-azure-cosmos || true │ │ │ fi │ │ ├── ./prerm │ │ │ @@ -1,11 +1,11 @@ │ │ │ #!/bin/sh │ │ │ set -e │ │ │ │ │ │ -# Automatically added by dh_python3: │ │ │ +# Automatically added by dh_python3 │ │ │ if which py3clean >/dev/null 2>&1; then │ │ │ py3clean -p python3-azure-cosmos │ │ │ else │ │ │ dpkg -L python3-azure-cosmos | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' │ │ │ find /usr/lib/python3/dist-packages/ -type d -name __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir │ │ │ fi ├── data.tar.xz │ ├── data.tar │ │ ├── file list │ │ │ @@ -1,25 +1,25 @@ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2020-03-07 10:58:01.00 ./ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2020-03-07 10:58:01.00 ./usr/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2020-03-07 10:58:01.00 ./usr/lib/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2020-0
Bug#987256: unblock: nvidia-graphics-drivers-legacy-390xx/390.143-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org
Please unblock package nvidia-graphics-drivers-legacy-390xx
The new upstream LTS version 390.143 fixes a CVE and a crash in X.org,
both of which affect Bullseye.
X.org crash under certain conditions, and a security vulnerability
(CVE-2021-1076 and #987218) has been found in the kernel driver:
https://nvidia.custhelp.com/app/answers/detail/a_id/5172
The inlined debdiff excludes the binary blobs.
unblock nvidia-graphics-drivers-legacy-390xx/390.143-1
--
Kind regards,
Luca Boccassi
diff -Nru --exclude 'NVIDIA*.run'
nvidia-graphics-drivers-legacy-390xx-390.141/debian/changelog
nvidia-graphics-drivers-legacy-390xx-390.143/debian/changelog
--- nvidia-graphics-drivers-legacy-390xx-390.141/debian/changelog
2021-03-13 21:39:29.0 +
+++ nvidia-graphics-drivers-legacy-390xx-390.143/debian/changelog
2021-04-20 01:04:19.0 +0100
@@ -1,3 +1,16 @@
+nvidia-graphics-drivers-legacy-390xx (390.143-1) unstable; urgency=medium
+
+ * New upstream legacy branch release 390.143 (2021-04-19).
+* Fixed CVE-2021-1076. (Closes: #987218)
+ https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+- Fixed a bug where vkCreateSwapchain could cause the X Server to crash
+ when an invalid imageFormat was provided.
+- Fixed a driver installation failure on Linux kernel 5.11 release
+ candidates, where the NVIDIA kernel module failed to build with error
+ "fatal error: asm/kmap_types.h: No such file or directory".
+
+ -- Andreas Beckmann Tue, 20 Apr 2021 02:04:19 +0200
+
nvidia-graphics-drivers-legacy-390xx (390.141-3) unstable; urgency=medium
* nvidia-legacy-390xx-alternative: Add libnvidia-ml.so slave alternative if
diff -Nru --exclude 'NVIDIA*.run'
nvidia-graphics-drivers-legacy-390xx-390.141/debian/control.md5sum
nvidia-graphics-drivers-legacy-390xx-390.143/debian/control.md5sum
--- nvidia-graphics-drivers-legacy-390xx-390.141/debian/control.md5sum
2021-03-13 21:39:29.0 +
+++ nvidia-graphics-drivers-legacy-390xx-390.143/debian/control.md5sum
2021-04-20 01:04:19.0 +0100
@@ -1,5 +1,5 @@
a1db8e174e35b30f771fffdf4690ea8b debian/control
0a204645020c143be44b04bd5daf7b85 debian/control.in
db12f898b07cdaf431ad34bd68a1662e debian/gen-control.pl
-365281fc24d824d688be59ab97ae1ca5 debian/rules
+e0a6daa55d2509f44d21bbb591ccbad1 debian/rules
181fae6bc60df1e667ef475560be4fdf debian/rules.defs
diff -Nru --exclude 'NVIDIA*.run'
nvidia-graphics-drivers-legacy-390xx-390.141/debian/rules
nvidia-graphics-drivers-legacy-390xx-390.143/debian/rules
--- nvidia-graphics-drivers-legacy-390xx-390.141/debian/rules 2021-03-13
21:39:29.0 +
+++ nvidia-graphics-drivers-legacy-390xx-390.143/debian/rules 2021-04-20
01:04:19.0 +0100
@@ -138,9 +138,9 @@
cat $^ | sort -u > $@
nv-readme.ids: unpack-stamp debian/nv-readme.ids
- sed -e '0,/A. Supported\|APPENDIX A: SUPPORTED/d' \
- -e '0,/Appendix A. Supported\|APPENDIX A: SUPPORTED/d' \
- -e '0,/^Below\|APPENDIX B/{/ 0x/s/.*
0x\([0-9a-fA-F]\{4\}\).*/10de\1/p; /^.\{41\} [0-9a-fA-F]\{4\} /s/^.\{41\}
\([0-9a-fA-F]\{4\}\) .*/10de\1/p};d' \
+ sed -r -e '0,/A. Supported|APPENDIX A: SUPPORTED/d' \
+ -e '0,/Appendix A. Supported|APPENDIX A: SUPPORTED/d' \
+ -e '0,/^Below|APPENDIX B/{/ 0x/s/.*
0x([0-9a-fA-F]{4}).*/10de\1/p; /^(.{41}|.{49}) [0-9a-fA-F]{4} /s/^(.{41}|.{49})
([0-9a-fA-F]{4}) .*/10de\2/p};d' \
NVIDIA-Linux/README.txt \
| tr a-f A-F | sort -u > $@
@set -e -x ; \
signature.asc
Description: This is a digitally signed message part
Bug#987305: unblock: nvidia-graphics-drivers-tesla-418/418.197.02-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org
Please unblock package nvidia-graphics-drivers-tesla-418
The new upstream version 418.197.02 fixes a CVE and a crash in X.org,
both of which affect Bullseye.
X.org crash under certain conditions, and a security vulnerability
(CVE-2021-1076 and #987219) has been found in the kernel driver:
https://nvidia.custhelp.com/app/answers/detail/a_id/5172
The inlined debdiff excludes the binary blobs.
unblock nvidia-graphics-drivers-tesla-418/418.197.02-1
--
Kind regards,
Luca Boccassi
diff -Nru --exclude 'NVIDIA*.run'
nvidia-graphics-drivers-tesla-418-418.181.07/debian/changelog
nvidia-graphics-drivers-tesla-418-418.197.02/debian/changelog
--- nvidia-graphics-drivers-tesla-418-418.181.07/debian/changelog
2021-03-12 19:11:00.0 +
+++ nvidia-graphics-drivers-tesla-418-418.197.02/debian/changelog
2021-04-20 15:15:04.0 +0100
@@ -1,3 +1,23 @@
+nvidia-graphics-drivers-tesla-418 (418.197.02-1) unstable; urgency=medium
+
+ * New upstream Tesla release 418.197.02 (2021-04-19).
+* Fixed CVE-2021-1076. (Closes: #987219)
+ https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+
+ -- Andreas Beckmann Tue, 20 Apr 2021 16:15:04 +0200
+
+nvidia-graphics-drivers (418.197.02-1) buster; urgency=medium
+
+ * New upstream Tesla release 418.197.02 (2021-04-19).
+* Fixed CVE-2021-1076. (Closes: #987216)
+ https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+
+ [ Andreas Beckmann ]
+ * nvidia-alternative: Add libnvidia-ml.so slave alternative if
+libnvidia-ml-dev is installed (460.56-2). (Closes: #984881)
+
+ -- Andreas Beckmann Tue, 20 Apr 2021 15:01:59 +0200
+
nvidia-graphics-drivers-tesla-418 (418.181.07-2) unstable; urgency=medium
* Switch to dh-sequence-dkms (460.56-1).
@@ -717,6 +737,19 @@
-- Andreas Beckmann Sun, 22 Apr 2018 13:59:45 +0200
+nvidia-graphics-drivers (390.143-1) UNRELEASED; urgency=medium
+
+ * New upstream legacy branch release 390.143 (2021-04-19).
+* Fixed CVE-2021-1076.
+ https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+- Fixed a bug where vkCreateSwapchain could cause the X Server to crash
+ when an invalid imageFormat was provided.
+- Fixed a driver installation failure on Linux kernel 5.11 release
+ candidates, where the NVIDIA kernel module failed to build with error
+ "fatal error: asm/kmap_types.h: No such file or directory".
+
+ -- Andreas Beckmann Mon, 19 Apr 2021 22:38:56 +0200
+
nvidia-graphics-drivers (390.141-1) UNRELEASED; urgency=medium
* New upstream legacy branch release 390.141 (2021-01-07).
diff -Nru --exclude 'NVIDIA*.run'
nvidia-graphics-drivers-tesla-418-418.181.07/debian/control.md5sum
nvidia-graphics-drivers-tesla-418-418.197.02/debian/control.md5sum
--- nvidia-graphics-drivers-tesla-418-418.181.07/debian/control.md5sum
2021-03-12 19:11:00.0 +
+++ nvidia-graphics-drivers-tesla-418-418.197.02/debian/control.md5sum
2021-04-20 15:15:04.0 +0100
@@ -1,5 +1,5 @@
2b166b1ac6588e638946982df3fde7df debian/control
7e76ad93933bc9855c55a24a0a29739f debian/control.in
db12f898b07cdaf431ad34bd68a1662e debian/gen-control.pl
-c7cc02af2fecdcf0d2be8781c0036133 debian/rules
+1c2e4bda5c346493c1e55efebba869c2 debian/rules
5c030ac5e276798b2e17c170aa15d998 debian/rules.defs
diff -Nru --exclude 'NVIDIA*.run'
nvidia-graphics-drivers-tesla-418-418.181.07/debian/rules
nvidia-graphics-drivers-tesla-418-418.197.02/debian/rules
--- nvidia-graphics-drivers-tesla-418-418.181.07/debian/rules 2021-03-12
19:11:00.0 +
+++ nvidia-graphics-drivers-tesla-418-418.197.02/debian/rules 2021-04-20
15:15:04.0 +0100
@@ -169,9 +169,9 @@
sed 's/__NV_VK_ICD__/libGL.so.1/' $< > $@
nv-readme.ids: unpack-stamp
- sed -e '0,/A. Supported\|APPENDIX A: SUPPORTED/d' \
- -e '0,/Appendix A. Supported\|APPENDIX A: SUPPORTED/d' \
- -e '0,/^Below\|APPENDIX B/{/ 0x/s/.*
0x\([0-9a-fA-F]\{4\}\).*/10de\1/p; /^.\{41\} [0-9a-fA-F]\{4\} /s/^.\{41\}
\([0-9a-fA-F]\{4\}\) .*/10de\1/p};d' \
+ sed -r -e '0,/A. Supported|APPENDIX A: SUPPORTED/d' \
+ -e '0,/Appendix A. Supported|APPENDIX A: SUPPORTED/d' \
+ -e '0,/^Below|APPENDIX B/{/ 0x/s/.*
0x([0-9a-fA-F]{4}).*/10de\1/p; /^(.{41}|.{49}) [0-9a-fA-F]{4} /s/^(.{41}|.{49})
([0-9a-fA-F]{4}) .*/10de\2/p};d' \
NVIDIA-Linux/README.txt \
| tr a-f A-F | sort -u > $@
@set -e -x ; \
signature.asc
Description: This is a digitally signed message part
Bug#987384: unblock: nvidia-graphics-drivers-tesla-450/450.119.03-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org Please unblock package nvidia-graphics-drivers-tesla-450 The new upstream version 450.119.03 fixes a CVE and a several bugs, all of which affect Bullseye. X.org crash under certain conditions, and a security vulnerability (CVE-2021-1076 and #987221) has been found in the kernel driver: https://nvidia.custhelp.com/app/answers/detail/a_id/5172 The inlined debdiff excludes the binary blobs. unblock nvidia-graphics-drivers-tesla-450/450.119.03-1 -- Kind regards, Luca Boccassi diff -Nru --exclude 'NVIDIA*.run' nvidia-graphics-drivers-tesla-450-450.102.04/debian/changelog nvidia-graphics-drivers-tesla-450-450.119.03/debian/changelog --- nvidia-graphics-drivers-tesla-450-450.102.04/debian/changelog 2021-03-13 17:43:15.0 + +++ nvidia-graphics-drivers-tesla-450-450.119.03/debian/changelog 2021-04-22 20:13:14.0 +0100 @@ -1,3 +1,21 @@ +nvidia-graphics-drivers-tesla-450 (450.119.03-1) unstable; urgency=medium + + * New upstream Tesla release 450.119.03 (2021-04-19). +* Fixed CVE-2021-1076. (Closes: #987221) + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 +- Fixed a driver installation failure on Linux kernel 5.11 release + candidates, where the NVIDIA kernel module failed to build with error + "error: implicit declaration of function 'sys_close'". +- Fixed a bug where calls to vkCreateDevice could fail on Ampere GPUs when + ray tracing extensions were enabled and the application was running within + the Steam Linux Runtime. +- Fixed a regression that could cause display corruption when using + a scaled resolution after resuming from power management suspend. +- Fixed a bug that could intermittently cause NvFBC applications to fail + with the error message "Unable to send exported fds". + + -- Andreas Beckmann Thu, 22 Apr 2021 21:13:14 +0200 + nvidia-graphics-drivers-tesla-450 (450.102.04-2) unstable; urgency=medium * Switch to dh-sequence-dkms (460.56-1). @@ -258,7 +276,6 @@ display offload sinks, also known as "Reverse PRIME". See the chapter titled "Offloading Graphics Display with RandR 1.4" in the README for additional information. -- Removed 'libGL.la' libtool archive from the install package. * New upstream release 440 series. - Fixed a bug where a Vulkan application under PRIME render offload would not always be correctly throttled to vsync despite @@ -816,6 +833,26 @@ -- Andreas Beckmann Sat, 25 May 2019 13:49:09 +0200 +nvidia-graphics-drivers-tesla-418 (418.197.02-1) unstable; urgency=medium + + * New upstream Tesla release 418.197.02 (2021-04-19). +* Fixed CVE-2021-1076. (Closes: #987219) + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 + + -- Andreas Beckmann Tue, 20 Apr 2021 16:15:04 +0200 + +nvidia-graphics-drivers (418.197.02-1) buster; urgency=medium + + * New upstream Tesla release 418.197.02 (2021-04-19). +* Fixed CVE-2021-1076. (Closes: #987216) + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 + + [ Andreas Beckmann ] + * nvidia-alternative: Add libnvidia-ml.so slave alternative if +libnvidia-ml-dev is installed (460.56-2). (Closes: #984881) + + -- Andreas Beckmann Tue, 20 Apr 2021 15:01:59 +0200 + nvidia-graphics-drivers-tesla-418 (418.181.07-2) unstable; urgency=medium * Switch to dh-sequence-dkms (460.56-1). @@ -1535,6 +1572,19 @@ -- Andreas Beckmann Sun, 22 Apr 2018 13:59:45 +0200 +nvidia-graphics-drivers (390.143-1) UNRELEASED; urgency=medium + + * New upstream legacy branch release 390.143 (2021-04-19). +* Fixed CVE-2021-1076. + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 +- Fixed a bug where vkCreateSwapchain could cause the X Server to crash + when an invalid imageFormat was provided. +- Fixed a driver installation failure on Linux kernel 5.11 release + candidates, where the NVIDIA kernel module failed to build with error + "fatal error: asm/kmap_types.h: No such file or directory". + + -- Andreas Beckmann Mon, 19 Apr 2021 22:38:56 +0200 + nvidia-graphics-drivers (390.141-1) UNRELEASED; urgency=medium * New upstream legacy branch release 390.141 (2021-01-07). diff -Nru --exclude 'NVIDIA*.run' nvidia-graphics-drivers-tesla-450-450.102.04/debian/control.md5sum nvidia-graphics-drivers-tesla-450-450.119.03/debian/control.md5sum --- nvidia-graphics-drivers-tesla-450-450.102.04/debian/control.md5sum 2021-03-13 17:43:15.0 + +++ nvidia-graphics-drivers-tesla-450-450.119.03/debian/control.md5sum 2021-04-22 20:13:14.0 +0100 @@ -1,5 +1,5 @@ f7eb3755f20b606b6c02febfa92cbb6d debian/control 807ae812aa88a6bd3515fc4e4ea95ce3 debian/control.in
Bug#987256: unblock: nvidia-graphics-drivers/460.73.01-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org Please unblock package nvidia-graphics-drivers The new upstream LTS version 460.73.01 fixes two CVEs and a crash in X.org, both of which affect Bullseye. It also adds support for a few new cards. X.org crash under certain conditions, and a security vulnerability (CVE-2021-1076, CVE-2021-1077 and #987216) has been found in the kernel driver: https://nvidia.custhelp.com/app/answers/detail/a_id/5172 The inlined debdiff excludes the binary blobs. unblock nvidia-graphics-drivers/460.73.01-1 -- Kind regards, Luca Boccassi diff -Nru --exclude 'NVIDIA*.run' nvidia-graphics-drivers-460.67/debian/changelog nvidia-graphics-drivers-460.73.01/debian/changelog --- nvidia-graphics-drivers-460.67/debian/changelog 2021-03-21 19:51:46.0 + +++ nvidia-graphics-drivers-460.73.01/debian/changelog 2021-04-23 07:59:01.0 +0100 @@ -1,3 +1,17 @@ +nvidia-graphics-drivers (460.73.01-1) unstable; urgency=medium + + * New upstream production branch release 460.73.01 (2021-04-14). +* Fixed CVE-2021-1076, CVE-2021-1077. (Closes: #987216) + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 +- Added support for the following GPUs: A10, A10G, A30, PG506-232, + RTX A4000, RTX A5000, T400, T600. + + [ Andreas Beckmann ] + * Update nv-readme.ids. + * Restrict watch file to releases from the 460.xx production branch. + + -- Andreas Beckmann Fri, 23 Apr 2021 08:59:01 +0200 + nvidia-graphics-drivers (460.67-1) unstable; urgency=medium * New upstream production branch release 460.67 (2021-03-18). @@ -5,16 +19,6 @@ result in application instability if the GPUs did not match. - Fixed an issue that prevented G-SYNC from working properly after a mode switch on Kepler-based GPUs. - * New upstream release 450 series. -- Fixed a driver installation failure on Linux kernel 5.11 release - candidates, where the NVIDIA kernel module failed to build with error - "error: implicit declaration of function 'sys_close'". - * New upstream release 390 series. -- Fixed a bug where vkCreateSwapchain could cause the X Server to crash when - an invalid imageFormat was provided. -- Fixed a driver installation failure on Linux kernel 5.11 release - candidates, where the NVIDIA kernel module failed to build with error - "fatal error: asm/kmap_types.h: No such file or directory". [ Luca Boccassi ] * Update nv-readme.ids. @@ -31,15 +35,9 @@ nvidia-graphics-drivers (460.56-1) unstable; urgency=medium * New upstream production branch release 460.56 (2021-02-25). -- Added support for the following GPUs: GeForce RTX 3060, CMP 40HX +- Added support for the following GPUs: GeForce RTX 3060, CMP 40HX, CMP 30HX. - Fixed a bug with indexed ray payloads in Vulkan. - * New upstream release 450 series. -- Fixed a bug where calls to vkCreateDevice could fail on Ampere GPUs when - ray tracing extensions were enabled and the application was running - within the Steam Linux Runtime. -- Fixed a regression that could cause display corruption when using - a scaled resolution after resuming from power management suspend. [ Luca Boccassi ] * Update nv-readme.ids. @@ -65,9 +63,6 @@ - Added support for the following GPUs: GeForce RTX 3080 Laptop GPU, GeForce RTX 3070 Laptop GPU, GeForce RTX 3060 Laptop GPU, GeForce GT 1010. - * New upstream release 450 series. -- Fixed a bug that could intermittently cause NvFBC applications to fail - with the error message "Unable to send exported fds". [ Andreas Beckmann ] * Update nv-readme.ids. @@ -280,6 +275,24 @@ -- Andreas Beckmann Thu, 24 Sep 2020 21:52:54 +0200 +nvidia-graphics-drivers (450.119.03-1) UNRELEASED; urgency=medium + + * New upstream Tesla release 450.119.03 (2021-04-19). +* Fixed CVE-2021-1076, CVE-2021-1077. + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 +- Fixed a driver installation failure on Linux kernel 5.11 release + candidates, where the NVIDIA kernel module failed to build with error + "error: implicit declaration of function 'sys_close'". +- Fixed a bug where calls to vkCreateDevice could fail on Ampere GPUs when + ray tracing extensions were enabled and the application was running within + the Steam Linux Runtime. +- Fixed a regression that could cause display corruption when using + a scaled resolution after resuming from power management suspend. +- Fixed a bug that could intermittently cause NvFBC applications to fail + with the error message "Unable to send exported fds". + + -- Andreas Beckmann Thu, 22 Apr 2021 21:13:14 +0200 + nvidia-graphics-drivers (450.102.04-1) UNRELEASE
Bug#987427: unblock: nvidia-graphics-drivers-tesla-460/460.73.01-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org Please unblock package nvidia-graphics-drivers-tesla-460 The new upstream version 460.73.01 fixes a CVE and a several bugs, all of which affect Bullseye. It also adds support for a few new cards. X.org crash under certain conditions, and a security vulnerability (CVE-2021-1076 and CVE-2021-1077, and #987222) has been found in the kernel driver: https://nvidia.custhelp.com/app/answers/detail/a_id/5172 The inlined debdiff excludes the binary blobs. unblock nvidia-graphics-drivers-tesla-460/460.73.01-1 -- Kind regards, Luca Boccassi diff -Nru --exclude 'NVIDIA*.run' nvidia-graphics-drivers-tesla-460-460.32.03/debian/changelog nvidia-graphics-drivers-tesla-460-460.73.01/debian/changelog --- nvidia-graphics-drivers-tesla-460-460.32.03/debian/changelog 2021-03-13 20:31:33.0 + +++ nvidia-graphics-drivers-tesla-460-460.73.01/debian/changelog 2021-04-23 14:20:03.0 +0100 @@ -1,3 +1,87 @@ +nvidia-graphics-drivers-tesla-460 (460.73.01-1) unstable; urgency=medium + + * New upstream production branch release 460.73.01 (2021-04-14). +* Fixed CVE-2021-1076, CVE-2021-1077. (Closes: #987222) + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 +- Added support for the following GPUs: A10, A10G, A30, PG506-232, + RTX A4000, RTX A5000, T400, T600. + + [ Andreas Beckmann ] + * Update nv-readme.ids. + + -- Andreas Beckmann Fri, 23 Apr 2021 15:20:03 +0200 + +nvidia-graphics-drivers (460.73.01-1) unstable; urgency=medium + + * New upstream production branch release 460.73.01 (2021-04-14). +* Fixed CVE-2021-1076, CVE-2021-1077. (Closes: #987216) + https://nvidia.custhelp.com/app/answers/detail/a_id/5172 +- Added support for the following GPUs: A10, A10G, A30, PG506-232, + RTX A4000, RTX A5000, T400, T600. + + [ Andreas Beckmann ] + * Update nv-readme.ids. + * Restrict watch file to releases from the 460.xx production branch. + + -- Andreas Beckmann Fri, 23 Apr 2021 08:59:01 +0200 + +nvidia-graphics-drivers (460.67-1) unstable; urgency=medium + + * New upstream production branch release 460.67 (2021-03-18). +- Fixed a bug where using ray tracing extensions on multi-GPU setups could + result in application instability if the GPUs did not match. +- Fixed an issue that prevented G-SYNC from working properly after a mode + switch on Kepler-based GPUs. + + [ Luca Boccassi ] + * Update nv-readme.ids. + + -- Andreas Beckmann Sun, 21 Mar 2021 20:51:46 +0100 + +nvidia-graphics-drivers (460.56-2) unstable; urgency=medium + + * nvidia-alternative: Add libnvidia-ml.so slave alternative if +libnvidia-ml-dev is installed. (Closes: #984881) + + -- Andreas Beckmann Wed, 10 Mar 2021 21:03:59 +0100 + +nvidia-graphics-drivers (460.56-1) unstable; urgency=medium + + * New upstream production branch release 460.56 (2021-02-25). +- Added support for the following GPUs: GeForce RTX 3060, CMP 40HX, + CMP 30HX. +- Fixed a bug with indexed ray payloads in Vulkan. + + [ Luca Boccassi ] + * Update nv-readme.ids. + + [ Andreas Beckmann ] + * Switch to dh-sequence-dkms. + * Simplify dh_dkms usage. + + -- Andreas Beckmann Sun, 28 Feb 2021 00:26:36 +0100 + +nvidia-graphics-drivers (460.39-1) unstable; urgency=medium + + * New upstream production branch release 460.39 (2021-01-26). +- Updated the NVIDIA driver to restore functionality of some features, + including runtime power management, hotplugging audio-capable display + devices, and S0ix-based system suspend, with recent kernels such as + Linux 5.10. (Closes: #981187) +- Fixed a bug that caused bindless texture samplers to be incorrectly + counted towards the MAX_COMPUTE_TEXTURE_IMAGE_UNITS limit. +- Fixed a bug that could cause the GPU to hang when attempting to + perform link training on an HDMI 2.1 Fixed Rate Link (FRL) display, + while the display is powered off. +- Added support for the following GPUs: GeForce RTX 3080 Laptop GPU, + GeForce RTX 3070 Laptop GPU, GeForce RTX 3060 Laptop GPU, + GeForce GT 1010. + + [ Andreas Beckmann ] + * Update nv-readme.ids. + + -- Andreas Beckmann Thu, 28 Jan 2021 01:33:29 +0100 + nvidia-graphics-drivers-tesla-460 (460.32.03-3) unstable; urgency=medium * Switch to dh-sequence-dkms (460.56-1). @@ -152,10 +236,6 @@ xf86-video-intel driver. - Fixed a bug in a Vulkan barrier optimization that allowed some back-to-back copies to run unordered. - * New upstream release 450 series. -- Fixed a performance regression in the NVIDIA X driver which affected - some X11 RENDER extension use cases. -- Added AMD Secure Memory Encryption compatibility. [ Andreas Beckmann ] * Update nv-readme.ids. @@ -168,11 +248,6 @@ - Fixed a bug that caused X to cras
Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)
On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote: > > Hi Kurt, hi Luca, hi everyone, > Hi Michael, > > > That said, I'm not a lawyer and reading license texts hurts my brain. > > So my goal is is mainly to raise awareness of this issue and seek input from > > the community. > > GPL code which linked against OpenSSL usually has a "gpl-exception > clause for OpenSSL". This should be still accepted since it refers > specifically to OpenSSL. Many projects do not have that. Also to be extremely pedantic it needs to be checked if it just references OpenSSL as a project, or specifically the OpenSSL license which is a specific and well defined document: https://spdx.org/licenses/OpenSSL.html AFAIK there's no "standard" clause, everyone uses their own wording, more or less. More importantly, as far as I understand and I was told recently these are not transitive - ie, it's fine for an executable, but if it concerns a library, it does not "transfer" to external programs linking to that library. > Additionally OpenSSL is considered system library, see > https://bugs.debian.org/951780 > https://bugs.debian.org/972181 Even if that interpretation holds, and it's not a universal interpretation (eg: lawyers from Canonical strongly disagree as far as I know), again that applies to first-party binaries only as far as I understand. It's not as clear-cut with libraries used by third parties. The core issue as always is uncertainty: any time there are doubts and conflicting interpretations, we all lose, especially our users, and especially those that are then forced to have awkward conversations with their corporate lawyers. Which is why it's really unfortunate that , in order to fix compatibility issues with the GPL, among all the permissive licenses available out there, the OpenSSL project picked the _one_ that has serious compatibility questions with the GPL :-( But of course this doesn't mean we shouldn't move to the new version, quite the contrary - I'll simply be careful about the projects I am involved in and what it means for them and their license clarity, and what I can do to make it better, if anything. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1032441: unblock: ovn/23.03.0-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org
Please unblock package ovn
As discussed and agreed in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024322
We have uploaded dpdk/ovs/ovn back in December, with git snapshots, to
ensure the ABI transition could be completed on time for the transition
freeze. This has worked well, and the only thing left to do is to
update src:ovn from the git snapshot to the final release, which was
tagged a couple of days ago. Only bug fix changes were merged since the
git snapshot that is currently in bookworm.
I have uploaded to unstable today, so with the 10 days migration delay
it will not migrate in time for the next freeze, hence filing this
unblock request.
Debdiff attached.
Thank you!
--
Kind regards,
Luca Boccassi
diff -Nru ovn-23.03.0~git20230221.038cfb1/.ci/ovn-kubernetes/Dockerfile ovn-23.03.0/.ci/ovn-kubernetes/Dockerfile
--- ovn-23.03.0~git20230221.038cfb1/.ci/ovn-kubernetes/Dockerfile 2023-02-17 21:40:31.0 +
+++ ovn-23.03.0/.ci/ovn-kubernetes/Dockerfile 2023-03-03 18:37:48.0 +
@@ -1,5 +1,5 @@
ARG OVNKUBE_COMMIT=master
-ARG LIBOVSDB_COMMIT=8081fe24e48f
+ARG LIBOVSDB_COMMIT=a6a173993830
FROM fedora:37 AS ovnbuilder
diff -Nru ovn-23.03.0~git20230221.038cfb1/controller/chassis.c ovn-23.03.0/controller/chassis.c
--- ovn-23.03.0~git20230221.038cfb1/controller/chassis.c 2023-02-17 21:40:31.0 +
+++ ovn-23.03.0/controller/chassis.c 2023-03-03 18:37:48.0 +
@@ -99,9 +99,9 @@
get_hostname(const struct smap *ext_ids, const char *chassis_id)
{
const char *hostname = get_chassis_external_id_value(ext_ids, chassis_id,
- "hostname", "");
+ "hostname", NULL);
-if (strlen(hostname) == 0) {
+if (!hostname) {
static char hostname_[HOST_NAME_MAX + 1];
if (gethostname(hostname_, sizeof(hostname_))) {
diff -Nru ovn-23.03.0~git20230221.038cfb1/controller/encaps.c ovn-23.03.0/controller/encaps.c
--- ovn-23.03.0~git20230221.038cfb1/controller/encaps.c 2023-02-17 21:40:31.0 +
+++ ovn-23.03.0/controller/encaps.c 2023-03-03 18:37:48.0 +
@@ -77,7 +77,7 @@
for (int i = 0; i < UINT16_MAX; i++) {
const char *idx = get_chassis_idx(tc->ovs_table);
char *port_name = xasprintf(
-"ovn%s-%.*s-%x", idx, strlen(idx) ? 5 : 6, chassis_id, i);
+"ovn%s-%.*s-%x", idx, idx[0] ? 5 : 6, chassis_id, i);
if (!sset_contains(&tc->port_names, port_name)) {
return port_name;
diff -Nru ovn-23.03.0~git20230221.038cfb1/controller/lflow.c ovn-23.03.0/controller/lflow.c
--- ovn-23.03.0~git20230221.038cfb1/controller/lflow.c 2023-02-17 21:40:31.0 +
+++ ovn-23.03.0/controller/lflow.c 2023-03-03 18:37:48.0 +
@@ -18,7 +18,6 @@
#include "lflow.h"
#include "coverage.h"
#include "ha-chassis.h"
-#include "lib/id-pool.h"
#include "lflow-cache.h"
#include "local_data.h"
#include "lport.h"
@@ -99,9 +98,9 @@
static void
consider_lb_hairpin_flows(const struct ovn_controller_lb *lb,
+ const struct hmap *local_datapaths,
bool use_ct_mark,
- struct ovn_desired_flow_table *flow_table,
- struct simap *ids);
+ struct ovn_desired_flow_table *flow_table);
static void add_port_sec_flows(const struct shash *binding_lports,
const struct sbrec_chassis *,
@@ -1731,114 +1730,38 @@
static void
add_lb_ct_snat_hairpin_for_dp(const struct ovn_controller_lb *lb,
const struct sbrec_datapath_binding *datapath,
+ const struct hmap *local_datapaths,
struct match *dp_match,
struct ofpbuf *dp_acts,
struct ovn_desired_flow_table *flow_table)
{
-match_set_metadata(dp_match, htonll(datapath->tunnel_key));
-ofctrl_add_or_append_flow(flow_table, OFTABLE_CT_SNAT_HAIRPIN, 200,
- lb->slb->header_.uuid.parts[0],
- dp_match, dp_acts, &lb->slb->header_.uuid,
- NX_CTLR_NO_METER, NULL);
-}
-
-static void
-add_lb_ct_snat_hairpin_dp_flows(const struct ovn_controller_lb *lb,
-uint32_t id,
-struct ovn_desired_flow_table *flow_table)
-{
-/* If "hairpin_snat_ip" is not specified on this LB, we do not need
- to add these flows because no conjunctive flows have
Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2
On Wed, 15 Mar 2023 at 21:07, Jonathan Wiltshire wrote: > > Control: tag -1 moreinfo > > Hi, > > On Wed, Dec 07, 2022 at 08:11:11PM +0000, Luca Boccassi wrote: > > An improvement to reduce the number of dependencies pulled down by the > > usr-merged debootstrapped image has been available in unstable, > > bookworm and bullseye-backports for a while. I'd like to make this > > improvement available in bullseye as well, as it saves ~50MB on a > > minbase image. See: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025657 > > This sounds like a behaviour change in stable, which would be very unusual > unless it fixes significant issues. Can it really be justified? > > Thanks, We already changed debootstrap's behaviour via p-u to add support for merged-usr, these are further fixups to improve those changes, so I think it is justified. Kind regards, Luca Boccassi
Bug#1013418: bullseye-pu: package dbus-broker/26-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-utopia-maintain...@lists.alioth.debian.org
Dear release team,
A low-severity CVE has been published for dbus-broker, and it affects
bullseye. In accordance with the Security Team, it does not warrant a
DSA, so we would like to fix it via p-u instead. The fix is a clean
backport, and the diff is minimal. Debdiff attached.
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013343
--
Kind regards,
Luca Boccassi
diff -Nru dbus-broker-26/debian/changelog dbus-broker-26/debian/changelog
--- dbus-broker-26/debian/changelog 2021-01-22 00:00:39.0 +
+++ dbus-broker-26/debian/changelog 2022-06-22 22:27:17.0 +0100
@@ -1,3 +1,10 @@
+dbus-broker (26-1+deb11u1) bullseye; urgency=medium
+
+ * Backport strnspn-fix-buffer-overflow.patch to fix CVE-2022-31212
+(Closes: #1013343)
+
+ -- Luca Boccassi Wed, 22 Jun 2022 22:27:17 +0100
+
dbus-broker (26-1) unstable; urgency=low
* Update upstream source from tag 'upstream/26'
diff -Nru dbus-broker-26/debian/gbp.conf dbus-broker-26/debian/gbp.conf
--- dbus-broker-26/debian/gbp.conf 2020-12-13 22:03:47.0 +
+++ dbus-broker-26/debian/gbp.conf 2022-06-22 22:27:17.0 +0100
@@ -1,6 +1,6 @@
[DEFAULT]
pristine-tar = True
-debian-branch = debian/sid
+debian-branch = debian/bullseye
upstream-branch = upstream
[pristine-tar]
diff -Nru dbus-broker-26/debian/patches/series dbus-broker-26/debian/patches/series
--- dbus-broker-26/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ dbus-broker-26/debian/patches/series 2022-06-22 22:27:17.0 +0100
@@ -0,0 +1 @@
+strnspn-fix-buffer-overflow.patch
diff -Nru dbus-broker-26/debian/patches/strnspn-fix-buffer-overflow.patch dbus-broker-26/debian/patches/strnspn-fix-buffer-overflow.patch
--- dbus-broker-26/debian/patches/strnspn-fix-buffer-overflow.patch 1970-01-01 01:00:00.0 +0100
+++ dbus-broker-26/debian/patches/strnspn-fix-buffer-overflow.patch 2022-06-22 22:27:17.0 +0100
@@ -0,0 +1,53 @@
+Author: David Rheinsberg
+Origin: backport, https://github.com/c-util/c-shquote/commit/7fd15f8e272136955f7ffc37df29fbca9ddceca1
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013343
+Description: strnspn: fix buffer overflow
+ Fix the strnspn and strncspn functions to use a properly sized buffer.
+ It used to be 1 byte too short. Checking for `0xff` in a string will
+ thus write `0xff` once byte beyond the stack space of the local buffer.
+ .
+ Note that the public API does not allow to pass `0xff` to those
+ functions. Therefore, this is a read-only buffer overrun, possibly
+ causing bogus reports from the parser, but still well-defined.
+--- a/subprojects/c-shquote/src/c-shquote.c
b/subprojects/c-shquote/src/c-shquote.c
+@@ -85,7 +85,7 @@
+ size_t c_shquote_strnspn(const char *string,
+ size_t n_string,
+ const char *accept) {
+-bool buffer[UCHAR_MAX] = {};
++bool buffer[UCHAR_MAX + 1] = {};
+
+ for ( ; *accept; ++accept)
+ buffer[(unsigned char)*accept] = true;
+@@ -100,7 +100,7 @@
+ size_t c_shquote_strncspn(const char *string,
+ size_t n_string,
+ const char *reject) {
+-bool buffer[UCHAR_MAX] = {};
++bool buffer[UCHAR_MAX + 1] = {};
+
+ if (strlen(reject) == 1) {
+ const char *p;
+--- a/subprojects/c-shquote/src/test-private.c
b/subprojects/c-shquote/src/test-private.c
+@@ -148,6 +148,9 @@
+
+ len = c_shquote_strnspn("ab", 2, "bc");
+ c_assert(len == 0);
++
++len = c_shquote_strnspn("ab", 2, "\xff");
++c_assert(len == 0);
+ }
+
+ static void test_strncspn(void) {
+@@ -167,6 +170,9 @@
+
+ len = c_shquote_strncspn("ab", 2, "cd");
+ c_assert(len == 2);
++
++len = c_shquote_strncspn("ab", 2, "\xff");
++c_assert(len == 2);
+ }
+
+ static void test_discard_comment(void) {
diff -Nru dbus-broker-26/debian/salsa-ci.yml dbus-broker-26/debian/salsa-ci.yml
--- dbus-broker-26/debian/salsa-ci.yml 2020-12-13 22:03:47.0 +
+++ dbus-broker-26/debian/salsa-ci.yml 2022-06-22 22:27:17.0 +0100
@@ -2,3 +2,6 @@
include:
- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+ RELEASE: 'bullseye'
signature.asc
Description: This is a digitally signed message part
Bug#1016168: bullseye-pu: package debootstrap/1.0.123+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-b...@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
While preparing for the usrmerge transition as per [0], we have done
some work on debootstrap [1] to ensure that, as per CTTE decision,
buildd machines (and CI machines) can remain unmerged-usr.
The new version of debootstrap with these changes is in unstable,
testing and stable-backports.
While talking with the buildd team, it was noted that some buildd
machines are still running oldstable, and there is no hard deadline for
the upgrade to stable. This means stable-backports is not enough to
ensure we can begin the transition, and blocking it on the buildd full
upgrades (which is difficult and time consuming) would put unduly
pressure on the DSA team and risk long delays, as the Bookworm freeze
approaches.
A selected backport of the changes for stable-proposed-updates and
oldstable-proposed-updates seems like a safe approach that removes the
buildd team/DSA from the critical path, and the buildd team/DSA would
prefer to go down that route.
The backport was tested by creating a sid chroot with local packages
that pull in usrmerge|usr-is-merged, and veryfing that with --no-
merged-usr and/or --variant buildd the chroot is still unmerged-usr as
expected.
Debdiff attached.
[0] https://lists.debian.org/debian-ctte/2022/07/msg00019.html
[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/71
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.123/debian/changelog debootstrap-1.0.123+deb11u1/debian/changelog
--- debootstrap-1.0.123/debian/changelog 2020-03-14 01:07:20.0 +
+++ debootstrap-1.0.123+deb11u1/debian/changelog 2022-07-28 12:04:03.0 +0100
@@ -1,3 +1,12 @@
+debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * setup_merged_usr: create skip flag when merged-usr is disabled on
+bookworm+
+ * Add usr-is-merged to the required set on testing/unstable
+
+ -- Luca Boccassi Thu, 28 Jul 2022 12:04:03 +0100
+
debootstrap (1.0.123) unstable; urgency=medium
* Reinstate safeguard removed in 1.0.121, which is absolutely needed
diff -Nru debootstrap-1.0.123/functions debootstrap-1.0.123+deb11u1/functions
--- debootstrap-1.0.123/functions 2020-03-14 00:53:38.0 +
+++ debootstrap-1.0.123+deb11u1/functions 2022-07-28 11:55:40.0 +0100
@@ -1341,7 +1341,23 @@
MERGED_USR="no"
fi
- if [ "$MERGED_USR" = "no" ]; then return 0; fi
+ if [ "$MERGED_USR" = "no" ]; then
+ # With the usrmerge becoming pseudo-essential we need to use this flag
+ # to ensure that even if it gets installed the buildd is not converted
+ # when debootstrap needs to create an unmerged-usr installation.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ mkdir -p "$TARGET/etc"
+ echo "this system will not be supported in the future" > "$TARGET/etc/unsupported-skip-usrmerge-conversion"
+ if ! doing_variant buildd; then
+ warning SANITYCHECK "Upgrading non-merged-/usr environments post-bookworm is unsupported. Only do this for CI/QA infrastructure that will be re-bootstrapped rather than upgraded."
+ fi
+ ;;
+ esac
+ return 0;
+ fi
local link_dir
case $ARCH in
diff -Nru debootstrap-1.0.123/scripts/debian-common debootstrap-1.0.123+deb11u1/scripts/debian-common
--- debootstrap-1.0.123/scripts/debian-common 2020-03-13 02:04:21.0 +
+++ debootstrap-1.0.123+deb11u1/scripts/debian-common 2022-07-28 11:55:40.0 +0100
@@ -40,6 +40,20 @@
esac
;;
esac
+
+ # On suites >= bookworm, either we set up a merged-/usr system
+ # via setup_merged_usr, or we deliberately avoided that migration
+ # by creating the flag file. This means there's no need for the
+ # live migration 'usrmerge' package and its extra dependencies:
+ # we can install the empty 'usr-is-merged' metapackage to indicate
+ # that the transition has been done.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ required="$required usr-is-merged"
+ ;;
+ esac
}
first_stage_install () {
signature.asc
Description: This is a digitally signed message part
Bug#1016169: buster-pu: package debootstrap/1.0.114+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-b...@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
While preparing for the usrmerge transition as per [0], we have done
some work on debootstrap [1] to ensure that, as per CTTE decision,
buildd machines (and CI machines) can remain unmerged-usr.
The new version of debootstrap with these changes is in unstable,
testing and stable-backports.
While talking with the buildd team, it was noted that some buildd
machines are still running oldstable, and there is no hard deadline for
the upgrade to stable. This means stable-backports is not enough to
ensure we can begin the transition, and blocking it on the buildd full
upgrades (which is difficult and time consuming) would put unduly
pressure on the DSA team and risk long delays, as the Bookworm freeze
approaches.
A selected backport of the changes for stable-proposed-updates and
oldstable-proposed-updates seems like a safe approach that removes the
buildd team/DSA from the critical path, and the buildd team/DSA would
prefer to go down that route.
The backport was tested by creating a sid chroot with local packages
that pull in usrmerge|usr-is-merged, and veryfing that with --no-
merged-usr and/or --variant buildd the chroot is still unmerged-usr as
expected.
Debdiff attached.
[0] https://lists.debian.org/debian-ctte/2022/07/msg00019.html
[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/71
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.114/debian/changelog debootstrap-1.0.114+deb10u1/debian/changelog
--- debootstrap-1.0.114/debian/changelog 2019-01-09 13:00:04.0 +
+++ debootstrap-1.0.114+deb10u1/debian/changelog 2022-07-28 12:18:59.0 +0100
@@ -1,3 +1,12 @@
+debootstrap (1.0.114+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * setup_merged_usr: create skip flag when merged-usr is disabled on
+bookworm+
+ * Add usr-is-merged to the required set on testing/unstable
+
+ -- Luca Boccassi Thu, 28 Jul 2022 12:18:59 +0100
+
debootstrap (1.0.114) unstable; urgency=medium
* Revert changes from 1.0.113 (closes: #918722)
diff -Nru debootstrap-1.0.114/functions debootstrap-1.0.114+deb10u1/functions
--- debootstrap-1.0.114/functions 2019-01-09 12:59:11.0 +
+++ debootstrap-1.0.114+deb10u1/functions 2022-07-28 12:16:24.0 +0100
@@ -1323,7 +1323,23 @@
MERGED_USR="no"
fi
- if [ "$MERGED_USR" = "no" ]; then return 0; fi
+ if [ "$MERGED_USR" = "no" ]; then
+ # With the usrmerge becoming pseudo-essential we need to use this flag
+ # to ensure that even if it gets installed the buildd is not converted
+ # when debootstrap needs to create an unmerged-usr installation.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ mkdir -p "$TARGET/etc"
+ echo "this system will not be supported in the future" > "$TARGET/etc/unsupported-skip-usrmerge-conversion"
+ if ! doing_variant buildd; then
+ warning SANITYCHECK "Upgrading non-merged-/usr environments post-bookworm is unsupported. Only do this for CI/QA infrastructure that will be re-bootstrapped rather than upgraded."
+ fi
+ ;;
+ esac
+ return 0;
+ fi
local link_dir
case $ARCH in
diff -Nru debootstrap-1.0.114/scripts/debian-common debootstrap-1.0.114+deb10u1/scripts/debian-common
--- debootstrap-1.0.114/scripts/debian-common 2018-11-20 18:55:53.0 +
+++ debootstrap-1.0.114+deb10u1/scripts/debian-common 2022-07-28 12:16:24.0 +0100
@@ -32,6 +32,20 @@
base="$base apt-transport-https ca-certificates"
;;
esac
+
+ # On suites >= bookworm, either we set up a merged-/usr system
+ # via setup_merged_usr, or we deliberately avoided that migration
+ # by creating the flag file. This means there's no need for the
+ # live migration 'usrmerge' package and its extra dependencies:
+ # we can install the empty 'usr-is-merged' metapackage to indicate
+ # that the transition has been done.
+ case "$CODENAME" in
+ etch*|lenny|squeeze|wheezy|jessie*|stretch|buster|bullseye)
+ ;;
+ *)
+ required="$required usr-is-merged"
+ ;;
+ esac
}
first_stage_install () {
signature.asc
Description: This is a digitally signed message part
Bug#1016655: bullseye-pu: package dbus-broker/26-1+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-utopia-maintain...@lists.alioth.debian.org j...@inutil.org
Dear release team,
In accordance with the Security Team, we want to fix CVE-2022-31213 via
a p-u upload rather than a DSA.
https://security-tracker.debian.org/tracker/CVE-2022-31213
I have prepared the backports for the CVE fix, a memory leak fix, and
an assertion fix that were merged upstream in the latest release.
I have tested the new version in a bullseye nspawn container and found
no issue.
I have already done the upload as dbus-broker was approved for
bullseye-p-u already in the past. debdiff attached.
--
Kind regards,
Luca Boccassi
diff -Nru dbus-broker-26/debian/changelog dbus-broker-26/debian/changelog
--- dbus-broker-26/debian/changelog 2022-06-22 22:27:17.0 +0100
+++ dbus-broker-26/debian/changelog 2022-08-04 12:55:19.0 +0100
@@ -1,3 +1,11 @@
+dbus-broker (26-1+deb11u2) bullseye; urgency=medium
+
+ * Backport patch to fix assertion failure when disconnecting peer groups
+ * Backport patch to fix memory leak
+ * Backport patches to fix null pointer dereference (CVE-2022-31213)
+
+ -- Luca Boccassi Thu, 04 Aug 2022 12:55:19 +0100
+
dbus-broker (26-1+deb11u1) bullseye; urgency=medium
* Backport strnspn-fix-buffer-overflow.patch to fix CVE-2022-31212
diff -Nru dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch
--- dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch 1970-01-01 01:00:00.0 +0100
+++ dbus-broker-26/debian/patches/c-stdaux-add-c_memcpy.patch 2022-08-04 12:55:19.0 +0100
@@ -0,0 +1,64 @@
+Author: David Rheinsberg
+Origin: backport, https://github.com/c-util/c-stdaux/commit/7a8493bebc595f94ea57fa1cb6a765a66185aa95
+Description: add c_memcpy()
+ Alongside c_memset(), this adds c_memcpy() with the same trick of
+ allowing empty copies.
+--- a/subprojects/c-stdaux/src/c-stdaux.h
b/subprojects/c-stdaux/src/c-stdaux.h
+@@ -488,6 +488,24 @@
+ return p;
+ }
+
++/**
++ * c_memcpy() - copy memory area
++ * @dst:pointer to target area
++ * @src:pointer to source area
++ * @n: length of area to copy
++ *
++ * Copy the memory of size @n from @src to @dst, just as `memcpy(3)` does,
++ * except this function allows either to be NULL if @n is zero. In the latter
++ * case, the operation is a no-op.
++ *
++ * Return: @p is returned.
++ */
++static inline void *c_memcpy(void *dst, const void *src, size_t n) {
++if (n > 0)
++memcpy(dst, src, n);
++return dst;
++}
++
+ /*
+ * Common Destructors
+ *
+--- a/subprojects/c-stdaux/src/test-api.c
b/subprojects/c-stdaux/src/test-api.c
+@@ -188,6 +188,7 @@
+ void *fns[] = {
+ (void *)c_errno,
+ (void *)c_memset,
++(void *)c_memcpy,
+ (void *)c_free,
+ (void *)c_close,
+ (void *)c_fclose,
+--- a/subprojects/c-stdaux/src/test-basic.c
b/subprojects/c-stdaux/src/test-basic.c
+@@ -332,6 +332,19 @@
+ abort();
+ c_assert(p == NULL);
+ }
++
++/*
++ * Test c_memcpy() with a simple 8-byte copy.
++ */
++{
++uint64_t v1 = (uint64_t)-1, v2 = (uint64_t)0;
++
++c_assert(v1 == (uint64_t)-1);
++c_memcpy(&v1, &v2, sizeof(v1));
++c_assert(v1 == (uint64_t)0);
++
++c_memcpy(NULL, NULL, 0);
++}
+ }
+
+ /*
diff -Nru dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch
--- dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch 1970-01-01 01:00:00.0 +0100
+++ dbus-broker-26/debian/patches/c-stdaux-add-c_memset.patch 2022-08-04 12:55:19.0 +0100
@@ -0,0 +1,85 @@
+Author: David Rheinsberg
+Origin: backport, https://github.com/c-util/c-stdaux/commit/1257244f886a4799a1ed739aa2c632e9eb033b8d
+Description: add c_memset()
+ The memset(3) function causes UB if its area pointer is NULL, even if
+ the area is 0-bytes in length. This is very unfortunate and requires
+ unnecessary guards in most callers. We really want to be able to call
+ memset(3) with NULL pointers on empty areas to avoid needless branching
+ and complexity.
+ .
+ Provide c_memset() which is exactly like memset(3) for non-NULL areas,
+ but a no-op for empty areas.
+--- a/subprojects/c-stdaux/src/c-stdaux.h
b/subprojects/c-stdaux/src/c-stdaux.h
+@@ -470,6 +470,24 @@
+ return _c_likely_(errno > 0) ? errno : ENOTRECOVERABLE;
+ }
+
++/**
++ * c_memset() - fill memory region with constant byte
++ * @p: pointer to memory region, if non-empty
++ * @c: value to fill with
++ * @n: size of the memory region in bytes
++ *
++ * This function works
Bug#1016871: transition: dpdk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: z...@debian.org bott...@debian.org team+colle...@tracker.debian.org pkg-dpdk-de...@lists.alioth.debian.org Dear Release Team, The new DPDK 21.11 LTS is ready for unstable/testing, and we wish to begin the transition. It was already uploaded to experimental: https://tracker.debian.org/pkg/dpdk The reverse dependencies are collectd, uhd and openvswitch: https://tracker.debian.org/pkg/collectd https://tracker.debian.org/pkg/uhd https://tracker.debian.org/pkg/openvswitch src:collectd currently suffers from an unrelated FTBFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016187 With a local workaround for that, it builds fine with the new src:dpdk, so I don't think it should block the transition. src:uhd rebuilds without any changes. src:openvswitch needs a new version, and thus its reverse dep src:ovn needs one too, which we already uploaded to experimental and are ready for unstable. Auto-transition page: https://release.debian.org/transitions/html/auto-dpdk.html Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1024322: transition: dpdk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org Hello Thomas and Release Team, As we did for Bullseye, we are proposing the following plan to allow Bookworm to ship with the latest LTS versions of DPDK and OVS. This will let us make use of the full LTS support windows for both projects, as we have done for the past few releases. Upload OVS built from git (with new sonames/package renames if necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable, ideally before the 16th as we go on vacation after that, to finish the transition. Then, after OVS 3.1 releases in February, upload it unstable (no soname/transition required, as only bug fixes will go in at that point). The upstream release might happen before or after the 2023/02/12 soft freeze, and if it is after we will ask for an exception. Would this plan work for everyone? Bullseye tickets for reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974588 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974667 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-b...@lists.debian.org
debian-wb-t...@lists.debian.org
Dear release team,
An improvement to reduce the number of dependencies pulled down by the
usr-merged debootstrapped image has been available in unstable,
bookworm and bullseye-backports for a while. I'd like to make this
improvement available in bullseye as well, as it saves ~50MB on a
minbase image. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025657
I have tested this locally and seems to work as expected.
Debdiff attached. It also enables usrmerge on hurd.
--
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.123+deb11u1/debian/changelog debootstrap-1.0.123+deb11u2/debian/changelog
--- debootstrap-1.0.123+deb11u1/debian/changelog 2022-07-28 12:04:03.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/changelog 2022-12-07 15:31:02.0 +
@@ -1,3 +1,19 @@
+debootstrap (1.0.123+deb11u2) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Samuel Thibault ]
+ * Enable usrmerge on hurd-i386 too
+
+ [ Ansgar ]
+ * debootstrap: optionally exclude specific dependencies
+ * debian-common: exclude usrmerge when installing usr-is-merged
+
+ [ Tianon Gravi ]
+ * Apply "EXCLUDE_DEPENDENCY" during "resolve_deps" (Closes: #1025657)
+
+ -- Luca Boccassi Wed, 07 Dec 2022 15:31:02 +
+
debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
* Non-maintainer upload.
diff -Nru debootstrap-1.0.123+deb11u1/debootstrap debootstrap-1.0.123+deb11u2/debootstrap
--- debootstrap-1.0.123+deb11u1/debootstrap 2022-07-28 11:55:11.0 +0100
+++ debootstrap-1.0.123+deb11u2/debootstrap 2022-12-07 15:30:03.0 +
@@ -41,6 +41,7 @@
UNPACK_TARBALL=""
ADDITIONAL=""
EXCLUDE=""
+EXCLUDE_DEPENDENCY=""
VERBOSE=""
CERTIFICATE=""
CHECKCERTIF=""
diff -Nru debootstrap-1.0.123+deb11u1/functions debootstrap-1.0.123+deb11u2/functions
--- debootstrap-1.0.123+deb11u1/functions 2022-07-28 11:55:40.0 +0100
+++ debootstrap-1.0.123+deb11u2/functions 2022-12-07 15:30:03.0 +
@@ -1361,7 +1361,6 @@
local link_dir
case $ARCH in
- hurd-*) return 0 ;;
amd64) link_dir="lib32 lib64 libx32" ;;
i386) link_dir="lib64 libx32" ;;
mips|mipsel)
@@ -1555,6 +1554,9 @@
NEWPKGS="$NEWPKGS $("$PKGDETAILS" GETDEPS "$pkgdest" $PKGS)"
done
done
+ if [ -n "${EXCLUDE_DEPENDENCY:-}" ]; then
+ NEWPKGS="$(without "$NEWPKGS" "$EXCLUDE_DEPENDENCY")"
+ fi
PKGS=$(echo "$PKGS $NEWPKGS" | tr ' ' '\n' | sort | uniq)
local REALPKGS=""
for s in $SUITE $EXTRA_SUITES; do
diff -Nru debootstrap-1.0.123+deb11u1/scripts/debian-common debootstrap-1.0.123+deb11u2/scripts/debian-common
--- debootstrap-1.0.123+deb11u1/scripts/debian-common 2022-07-28 11:55:40.0 +0100
+++ debootstrap-1.0.123+deb11u2/scripts/debian-common 2022-12-07 15:30:03.0 +
@@ -52,6 +52,7 @@
;;
*)
required="$required usr-is-merged"
+ EXCLUDE_DEPENDENCY="$EXCLUDE_DEPENDENCY usrmerge"
;;
esac
}
signature.asc
Description: This is a digitally signed message part
Bug#1024322: transition: dpdk
Control: tags -1 -moreinfo On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher wrote: > > Control: tags -1 moreinfo > > On 2022-11-17 14:27:25 +, Luca Boccassi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org > > > > Hello Thomas and Release Team, > > > > As we did for Bullseye, we are proposing the following plan to allow > > Bookworm to ship with the latest LTS versions of DPDK and OVS. This > > will let us make use of the full LTS support windows for both projects, > > as we have done for the past few releases. > > > > Upload OVS built from git (with new sonames/package renames if > > necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable, > > ideally before the 16th as we go on vacation after that, to finish the > > transition. > > > > Then, after OVS 3.1 releases in February, upload it unstable (no > > soname/transition required, as only bug fixes will go in at that > > point). The upstream release might happen before or after the > > 2023/02/12 soft freeze, and if it is after we will ask for an > > exception. > > > > Would this plan work for everyone? > > Sounds like that should work like last time. Please remove the moreinfo > tag once dpdk is ready for the upload to unstable. Hi, We are now ready. dpdk, openvswitch and ovn are ready in experimental. uhd and collectd in unstable will need a simple binary rebuild and are already compatible. Kind regards, Luca Boccassi
Bug#1026845: bullseye-pu: package systemd/247.3-7+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org Dear release team, We'd like to upload several bug fixes, including security fixes, for systemd to bullseye. The fixes come from the upstream stable branches which are covered by CI and confirmed by reporters. Please find the debdiff attached. Kind regards, Luca Boccassi pu.debdiff Description: Binary data
Bug#1024322: transition: dpdk
On Sat, 17 Dec 2022 14:52:30 +0100 Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Hi Luca > > On 2022-12-17 02:12:56 +, Luca Boccassi wrote: > > Control: tags -1 -moreinfo > > > > On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher wrote: > > > > > > Control: tags -1 moreinfo > > > > > > On 2022-11-17 14:27:25 +, Luca Boccassi wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org > > > > > > > > Hello Thomas and Release Team, > > > > > > > > As we did for Bullseye, we are proposing the following plan to allow > > > > Bookworm to ship with the latest LTS versions of DPDK and OVS. This > > > > will let us make use of the full LTS support windows for both projects, > > > > as we have done for the past few releases. > > > > > > > > Upload OVS built from git (with new sonames/package renames if > > > > necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable, > > > > ideally before the 16th as we go on vacation after that, to finish the > > > > transition. > > > > > > > > Then, after OVS 3.1 releases in February, upload it unstable (no > > > > soname/transition required, as only bug fixes will go in at that > > > > point). The upstream release might happen before or after the > > > > 2023/02/12 soft freeze, and if it is after we will ask for an > > > > exception. > > > > > > > > Would this plan work for everyone? > > > > > > Sounds like that should work like last time. Please remove the moreinfo > > > tag once dpdk is ready for the upload to unstable. > > > > Hi, > > > > We are now ready. dpdk, openvswitch and ovn are ready in experimental. > > uhd and collectd in unstable will need a simple binary rebuild and are > > already compatible. > > Please go ahead Only src:uhd has been rebuilt, please rebuild src:collectd too (it only has Recommends instead of Depends as it's a plugin-based software, so it won't show in apt rdepends et al). -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#934308: buster-pu: package dpdk/18.11.2-2+deb10u1
On Tue, 2019-08-20 at 23:49 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > This request never made it to debian-release, most likely due to the > size of the diff. Sorry, didn't notice that! > On Fri, 2019-08-09 at 13:54 +0100, Luca Boccassi wrote: > > We would like to upload a new LTS release version of DPDK to > > buster. > > We have already done this previously in stretch, and it was > > approved > > for the 16.11 LTS series [1][2][3], but given this is a new Debian > > release in combination with a new LTS release train I have not yet > > uploaded to p-u and will wait for an explicit ACK. We would like to > > upload new 18.11 LTS versions as they are released upstream to > > buster > > - > > EOL is projected in November 2020. > > What's the plan for after that point? Same as for stretch and 16.11 LTS - if there are critical and/or security related bugs that affect the branch, we will do our best to backport the fixes as downstream maintainers. > > As with the 16.11 LTS, the 18.11 LTS point release has only bug > > fixes and no API/ABI changes and has been tested extensively and > > deployed on Debian Buster and more distros, which includes running > > regression tests. > > Please go ahead. > > Regards, > > Adam > > -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#934308: buster-pu: package dpdk/18.11.2-2+deb10u1
On Mon, 2019-09-02 at 14:03 +0100, Adam D. Barratt wrote: > On 2019-08-21 12:48, Luca Boccassi wrote: > > On Tue, 2019-08-20 at 23:49 +0100, Adam D. Barratt wrote: > > > Control: tags -1 + confirmed > > > > > > This request never made it to debian-release, most likely due to > > > the > > > size of the diff. > > > > Sorry, didn't notice that! > > > > > On Fri, 2019-08-09 at 13:54 +0100, Luca Boccassi wrote: > > > > We would like to upload a new LTS release version of DPDK to > > > > buster. > > > > We have already done this previously in stretch, and it was > > > > approved > > > > for the 16.11 LTS series [1][2][3], but given this is a new > > > > Debian > > > > release in combination with a new LTS release train I have not > > > > yet > > > > uploaded to p-u and will wait for an explicit ACK. We would > > > > like to > > > > upload new 18.11 LTS versions as they are released upstream to > > > > buster > > > > - > > > > EOL is projected in November 2020. > > > > > > What's the plan for after that point? > > > > Same as for stretch and 16.11 LTS - if there are critical and/or > > security related bugs that affect the branch, we will do our best > > to > > backport the fixes as downstream maintainers. > > This is partly my fault for assuming what you'd done, rather than > checking, but it appears that the fixes included in this upload are > not > currently in unstable, which is one of the basic requirements for > updates via p-u. Further, p-u now has a higher version number than > the > package in unstable. > > As it stands currently, our choices for Saturday's point release are > either deciding to skip the dpdk update until 10.2, or asking ftp- > master > to push the package from p-u to unstable (and testing) during the > point > release. > > Regards, > > Adam Hello Adam, First of all, sorry for any troubles caused and thanks for checking. I'm slightly confused though: unstable has 18.11.2-2, and p-u has a +deb10u1 changelog-only rebuild of that - is this not the right procedure? What is missing from unstable/testing? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#934308: buster-pu: package dpdk/18.11.2-2+deb10u1
On Mon, 2019-09-02 at 14:14 +0100, Adam D. Barratt wrote: > On 2019-09-02 14:09, Luca Boccassi wrote: > > I'm slightly confused though: unstable has 18.11.2-2, and p-u has a > > +deb10u1 changelog-only rebuild of that - is this not the right > > procedure? What is missing from unstable/testing? > > Ah, I see. In which case, the lack of fixes isn't an issue, but the > version is instead. > > 18.11.2-2+deb10u1 is a higher version than 18.11.2-2 - a changelog- > only > rebuild should be *~*deb10u1 so as to sort lower, in the same way as > ~bpo is used for uploads to -backports. > > Packages in stable should not have higher version numbers than > testing > or unstable, so we will still need to ask ftp-master to push the > package > from p-u into those suites as part of the point release, in order not > to > violate that constraint. > > Apologies for the confusion and for not having checked more > carefully > before accepting the package in order to have avoided the issue. > > Regards, > > Adam Agh sorry, my bad! Would it make your life easier if I uploaded a new revision to unstable? There's a few small cosmetic cleanups I can do, like bumping standards-version and such. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#934308: buster-pu: package dpdk/18.11.2-2+deb10u1
On Mon, 2019-09-02 at 18:02 +0100, Adam D. Barratt wrote: > On Mon, 2019-09-02 at 14:19 +0100, Luca Boccassi wrote: > > Would it make your life easier if I uploaded a new revision to > > unstable? There's a few small cosmetic cleanups I can do, like > > bumping standards-version and such. > > If you've got enough changes to usefully justify a -3 that we could > age > to get into testing before the weekend, that would certainly help. > > Regards, > > Adam I had 3/4 small cleanups queued up for the next upload, I just pushed -3 to unstable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#944794: stretch-pu: package dpdk/16.11.11+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org
Dear release team,
We would like to upload a new LTS release version of DPDK to Stretch.
We have already done this previously, and it was approved, for 16.11.4
[1] and 16.11.6 [2] and 16.11.8 [3] and 16.11.9 [4], therefore I
already proceeded to upload to stretch-pu in accordance with the new
workflow.
As before, the LTS point release has only bug fixes and no API changes
and has been tested with regression tests.
The source debdiff is attached. Patches merged upstream have been
dropped.
This release has only one bug fix, which fixes a regression introduced
by the fix for CVE-2019-14818 released on Tuesday via stretch-security.
--
Kind regards,
Luca Boccassi
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884711
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896689
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907584
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925154
diff -Nru dpdk-16.11.9/debian/changelog dpdk-16.11.11/debian/changelog
--- dpdk-16.11.9/debian/changelog 2019-11-12 11:15:47.0 +
+++ dpdk-16.11.11/debian/changelog 2019-11-15 14:15:07.0 +
@@ -1,3 +1,13 @@
+dpdk (16.11.11-1+deb9u1) stretch; urgency=medium
+
+ * New upstream version 16.11.11
+* https://mails.dpdk.org/archives/announce/2019-November/000297.html
+* Fixes CVE-2019-14818
+* Fixes vhost regression introduced by 16.11.10 and CVE fix
+ * Drop patches merged in 16.11.10
+
+ -- Luca Boccassi Fri, 15 Nov 2019 14:15:07 +
+
dpdk (16.11.9-1+deb9u2) stretch-security; urgency=high
* Backport patches to fix CVE-2019-14818. A denial of service security
diff -Nru dpdk-16.11.9/debian/patches/0001-vhost-validate-virtqueue-size.patch dpdk-16.11.11/debian/patches/0001-vhost-validate-virtqueue-size.patch
--- dpdk-16.11.9/debian/patches/0001-vhost-validate-virtqueue-size.patch 2019-11-12 11:14:06.0 +
+++ dpdk-16.11.11/debian/patches/0001-vhost-validate-virtqueue-size.patch 1970-01-01 01:00:00.0 +0100
@@ -1,43 +0,0 @@
-From 5fbb5c2919b6aecc98264528064e96f3dbb43e71 Mon Sep 17 00:00:00 2001
-From: Stefan Hajnoczi
-Date: Mon, 5 Feb 2018 13:16:00 +0100
-Subject: [PATCH 1/4] vhost: validate virtqueue size
-
-[ backported from upstream commit eb7c574b21cc92792ea5a1f219ddf6dd3cf3b1e1 ]
-
-Check the virtqueue size constraints so that invalid values don't cause
-bugs later on in the code. For example, sometimes the virtqueue size is
-stored as unsigned int and sometimes as uint16_t, so bad things happen
-if it is ever larger than 65535.
-
-Signed-off-by: Stefan Hajnoczi
-Reviewed-by: Maxime Coquelin
- lib/librte_vhost/vhost_user.c | 11 +++
- 1 file changed, 11 insertions(+)
-
-diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
-index 618d413fe1..8a01c295e7 100644
a/lib/librte_vhost/vhost_user.c
-+++ b/lib/librte_vhost/vhost_user.c
-@@ -189,6 +189,17 @@ vhost_user_set_vring_num(struct virtio_net *dev,
-
- vq->size = state->num;
-
-+ /* VIRTIO 1.0, 2.4 Virtqueues says:
-+ *
-+ * Queue Size value is always a power of 2. The maximum Queue Size
-+ * value is 32768.
-+ */
-+ if ((vq->size & (vq->size - 1)) || vq->size > 32768) {
-+ RTE_LOG(ERR, VHOST_CONFIG,
-+ "invalid virtqueue size %u\n", vq->size);
-+ return -1;
-+ }
-+
- if (dev->dequeue_zero_copy) {
- vq->nr_zmbuf = 0;
- vq->last_zmbuf_idx = 0;
---
-2.20.1
-
diff -Nru dpdk-16.11.9/debian/patches/0002-vhost-add-number-of-fds-to-vhost-user-messages.patch dpdk-16.11.11/debian/patches/0002-vhost-add-number-of-fds-to-vhost-user-messages.patch
--- dpdk-16.11.9/debian/patches/0002-vhost-add-number-of-fds-to-vhost-user-messages.patch 2019-11-12 11:14:06.0 +
+++ dpdk-16.11.11/debian/patches/0002-vhost-add-number-of-fds-to-vhost-user-messages.patch 1970-01-01 01:00:00.0 +0100
@@ -1,112 +0,0 @@
-From 3863340f93b8d3e32cc9c2b048765b2855f701c5 Mon Sep 17 00:00:00 2001
-From: Maxime Coquelin
-Date: Fri, 12 Oct 2018 14:40:35 +0200
-Subject: [PATCH 2/4] vhost: add number of fds to vhost-user messages
-
-As soon as some ancillary data (fds) are received, it is copied
-without checking its length.
-
-This patch adds the number of fds received to the message,
-which is set in read_vhost_message().
-
-This is preliminary work to support sending fds to Qemu.
-
-Signed-off-by: Dr. David Alan Gilbert
-Signed-off-by: Maxime Coquelin
-(cherry picked from commit c00bb88d35fe975ede0ea35bdf4f765a2cece7e8)
-Signed-off-by: Maxime Coquelin
- lib/librte_vhost/socket.c | 22 +-
- lib/librte_vhost/vhost_user.c | 2 +-
- lib/librte_vhost/vhost_user.h | 4 +++-
- 3 files changed, 21 insertions(+), 7 deletions(-)
-
-diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
-index 805b2e5b23..4a19280f
Bug#944794: stretch-pu: package dpdk/16.11.11+deb9u1
On Fri, 2019-11-15 at 15:00 +, Adam D. Barratt wrote: > On 2019-11-15 14:26, Luca Boccassi wrote: > > This release has only one bug fix, which fixes a regression > > introduced > > by the fix for CVE-2019-14818 released on Tuesday via stretch- > > security. > > I assume that's not a sufficiently important regression that it > needs > fixing via -security? The next stretch point release is probably not > for > a couple of months. > > Regards, > > Adam Hi, It breaks some important functionality, but it does not introduce a new security issues. Does the security process allow a new -security upload in this case? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#944794: stretch-pu: package dpdk/16.11.11+deb9u1
On Fri, 2019-11-15 at 16:22 +, Adam D. Barratt wrote: > On 2019-11-15 16:04, Luca Boccassi wrote: > > On Fri, 2019-11-15 at 15:00 +, Adam D. Barratt wrote: > > > On 2019-11-15 14:26, Luca Boccassi wrote: > > > > This release has only one bug fix, which fixes a regression > > > > introduced > > > > by the fix for CVE-2019-14818 released on Tuesday via stretch- > > > > security. > > > > > > I assume that's not a sufficiently important regression that it > > > needs > > > fixing via -security? The next stretch point release is probably > > > not > > > for > > > a couple of months. > > > > > > Regards, > > > > > > Adam > > > > Hi, > > > > It breaks some important functionality, but it does not introduce a > > new > > security issues. Does the security process allow a new -security > > upload > > in this case? > > That's up to the Security Team. I'd suggest asking them and seeing > what > they think. > > Regards, > > Adam Hi, The security team is OK with another DSA if it's a critical breakage. I talked with the co-maintainer and we decided that it's uncommon enough that we'll go through -pu unless someone raises a bug, and only then consider an additional DSA. We'd like the latest release in -pu regardless, so it should be independent of this request. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance
On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt wrote: > > On Fri, 2020-10-16 at 17:05 +, Adam D Barratt wrote: > > Package: dpdk > > Version: 18.11.10-1~deb10u1 > > > > Explanation: new upstream stable release; fix remote code execution > > issue [CVE-2020-14374], TOCTOU issues [CVE-2020-14375], buffer > > overflow [CVE-2020-14376], buffer over read [CVE-2020-14377] and > > integer underflow [CVE-2020-14377] > > Unfortunately, this FTBFS on armhf (in three attempts across two > different buildds): > > --- start log extract --- > > FAILED: drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o > cc -Idrivers/a715181@@tmp_rte_pmd_i40e@sta -Idrivers -I../drivers > -Idrivers/net/i40e -I../drivers/net/i40e -Idrivers/net/i40e/base > -I../drivers/net/i40e/base -Ilib/librte_ethdev -I../lib/librte_ethdev -I. > -I../ -Iconfig -I../config -Ilib/librte_eal/common -I../lib/librte_eal/common > -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include > -Ilib/librte_eal/common/include/arch/arm > -I../lib/librte_eal/common/include/arch/arm > -I../lib/librte_eal/linuxapp/eal/include > -Ilib/librte_eal/linuxapp/eal/../../../librte_compat > -I../lib/librte_eal/linuxapp/eal/../../../librte_compat -Ilib/librte_eal > -I../lib/librte_eal -Ilib/librte_kvargs/../librte_eal/common/include > -I../lib/librte_kvargs/../librte_eal/common/include -Ilib/librte_kvargs > -I../lib/librte_kvargs -Ilib/librte_compat -I../lib/librte_compat > -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf > -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring > -I../lib/librte_ring -Ilib/librte_cmdline/../librte_eal/common/include > -I../lib/librte_cmdline/../librte_eal/common/include -Ilib/librte_cmdline > -I../lib/librte_cmdline -Idrivers/bus/pci -I../drivers/bus/pci > -I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci > -Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash > -I../lib/librte_hash -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 > -include rte_config.h -Wsign-compare -Wcast-qual -Wno-pointer-to-int-cast > -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -fPIC -march=armv7-a -mfpu=neon -Wno-format-truncation > -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF -DX722_A0_SUPPORT > -DALLOW_EXPERIMENTAL_API -MD -MQ > 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -MF > 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o.d' -o > 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -c > ../drivers/net/i40e/i40e_rxtx_vec_neon.c > ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘desc_to_olflags_v’: > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: warning: implicit > declaration of function ‘vqtbl1q_u8’; did you mean ‘vtbl1_u8’? > [-Wimplicit-function-declaration] > vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags, >^~ >vtbl1_u8 > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: error: incompatible type for > argument 1 of ‘vreinterpretq_u32_u8’ > vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags, >^~ >vreinterpretq_u8_u32(vlan1))); > [...] > ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘_recv_raw_pkts_vec’: > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:320:11: error: incompatible types > when assigning to type ‘uint8x16_t’ from type ‘int’ >pkt_mb4 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[3]), shuf_msk); >^ > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:321:11: error: incompatible types > when assigning to type ‘uint8x16_t’ from type ‘int’ >pkt_mb3 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[2]), shuf_msk); >^ > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:351:11: error: incompatible types > when assigning to type ‘uint8x16_t’ from type ‘int’ >pkt_mb2 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[1]), shuf_msk); >^ > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:352:11: error: incompatible types > when assigning to type ‘uint8x16_t’ from type ‘int’ >pkt_mb1 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[0]), shuf_msk); >^ > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:383:13: error: incompatible types > when assigning to type ‘uint8x16_t’ from type ‘int’ > eop_bits = vqtbl1q_u8(eop_bits, eop_shuf_mask); > > ^ > > --- end log extract --- > > Regards, > > Adam Mh that looks familiar, I thought it was already fixed. I'll have a look on Monday morning, and also see why the CI missed it. Kind regards, Luca Boccassi
Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance
On Sun, 2020-10-25 at 12:11 +, Luca Boccassi wrote: > On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt > wrote: > > On Fri, 2020-10-16 at 17:05 +, Adam D Barratt wrote: > > > Package: dpdk > > > Version: 18.11.10-1~deb10u1 > > > > > > Explanation: new upstream stable release; fix remote code execution > > > issue [CVE-2020-14374], TOCTOU issues [CVE-2020-14375], buffer > > > overflow [CVE-2020-14376], buffer over read [CVE-2020-14377] and > > > integer underflow [CVE-2020-14377] > > > > Unfortunately, this FTBFS on armhf (in three attempts across two > > different buildds): > > > > --- start log extract --- > > > > FAILED: > > drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o > > cc -Idrivers/a715181@@tmp_rte_pmd_i40e@sta -Idrivers -I../drivers > > -Idrivers/net/i40e -I../drivers/net/i40e -Idrivers/net/i40e/base > > -I../drivers/net/i40e/base -Ilib/librte_ethdev -I../lib/librte_ethdev -I. > > -I../ -Iconfig -I../config -Ilib/librte_eal/common > > -I../lib/librte_eal/common -Ilib/librte_eal/common/include > > -I../lib/librte_eal/common/include -Ilib/librte_eal/common/include/arch/arm > > -I../lib/librte_eal/common/include/arch/arm > > -I../lib/librte_eal/linuxapp/eal/include > > -Ilib/librte_eal/linuxapp/eal/../../../librte_compat > > -I../lib/librte_eal/linuxapp/eal/../../../librte_compat -Ilib/librte_eal > > -I../lib/librte_eal -Ilib/librte_kvargs/../librte_eal/common/include > > -I../lib/librte_kvargs/../librte_eal/common/include -Ilib/librte_kvargs > > -I../lib/librte_kvargs -Ilib/librte_compat -I../lib/librte_compat > > -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf > > -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring > > -I../lib/librte_ring -Ilib/librte_cmdline/../librte_eal/common/include > > -I../lib/librte_cmdline/../librte_eal/common/include -Ilib/librte_cmdline > > -I../lib/librte_cmdline -Idrivers/bus/pci -I../drivers/bus/pci > > -I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci > > -Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash > > -I../lib/librte_hash -fdiagnostics-color=always -pipe > > -D_FILE_OFFSET_BITS=64 -include rte_config.h -Wsign-compare -Wcast-qual > > -Wno-pointer-to-int-cast -D_GNU_SOURCE -g -O2 > > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -march=armv7-a -mfpu=neon -Wno-format-truncation -DPF_DRIVER -DVF_DRIVER > > -DINTEGRATED_VF -DX722_A0_SUPPORT -DALLOW_EXPERIMENTAL_API -MD -MQ > > 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -MF > > 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o.d' > > -o 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' > > -c ../drivers/net/i40e/i40e_rxtx_vec_neon.c > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘desc_to_olflags_v’: > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: warning: implicit > > declaration of function ‘vqtbl1q_u8’; did you mean ‘vtbl1_u8’? > > [-Wimplicit-function-declaration] > > vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags, > >^~ > >vtbl1_u8 > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: error: incompatible type > > for argument 1 of ‘vreinterpretq_u32_u8’ > > vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags, > >^~ > >vreinterpretq_u8_u32(vlan1))); > > [...] > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘_recv_raw_pkts_vec’: > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:320:11: error: incompatible types > > when assigning to type ‘uint8x16_t’ from type ‘int’ > >pkt_mb4 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[3]), shuf_msk); > >^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:321:11: error: incompatible types > > when assigning to type ‘uint8x16_t’ from type ‘int’ > >pkt_mb3 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[2]), shuf_msk); > >^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:351:11: error: incompatible types > > when assigning to type ‘uint8x16_t’ from type ‘int’ > >pkt_mb2 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[1]), shuf_msk); > >^ > > ../drivers/net/i40e/i40e_rxtx_vec_neon.c:352:11: error: incompatible types > > when assigning to type ‘uint8x16_t’ from type ‘int’ > > pkt_mb1 = vqtbl1q_u8(vreinterp
Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance
On Mon, 2020-10-26 at 17:56 +, Adam D. Barratt wrote: > On Mon, 2020-10-26 at 15:18 +0000, Luca Boccassi wrote: > > On Sun, 2020-10-25 at 12:11 +0000, Luca Boccassi wrote: > > > On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt < > > > a...@adam-barratt.org.uk> wrote: > [...] > > > > Unfortunately, this FTBFS on armhf (in three attempts across two > > > > different buildds): > [...] > > I found the issue, and I have a patch ready (a mainline commit was > > mistakenly not tagged for backport). Also found that the armv7 CI was > > disabled due to infra issues - I'll fix that too. > > Cool, thanks for the quick turnaround. > > > In terms of process, how do I proceed? A deb10u2 upload to stable? > > Yes, as the archive already contains ~deb10u1. > > > Do I need to create a new bug? > > As this is a build fix for the upload tracked by this bug, then > continuing to use this bug is fine in this instance. If it were a new > set of changes then it should be tracked in a separate bug. > > Please do attach an updated debdiff to this bug though. > > Regards, > > Adam Uploaded and debdiff attached. Tested the build on the harris armhf porterbox. -- Kind regards, Luca Boccassi diff -Nru dpdk-18.11.10/debian/changelog dpdk-18.11.10/debian/changelog --- dpdk-18.11.10/debian/changelog 2020-09-28 15:35:37.0 +0100 +++ dpdk-18.11.10/debian/changelog 2020-10-26 10:44:57.00000 + @@ -1,3 +1,9 @@ +dpdk (18.11.10-1~deb10u2) buster; urgency=medium + + * Backport patch to fix armhf build with NEON + + -- Luca Boccassi Mon, 26 Oct 2020 10:44:57 + + dpdk (18.11.10-1~deb10u1) buster; urgency=medium * New upstream version 18.11.10 diff -Nru dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch --- dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch 1970-01-01 01:00:00.0 +0100 +++ dpdk-18.11.10/debian/patches/0008-net-i40e-support-aarch32.patch 2020-10-26 10:44:57.0 + @@ -0,0 +1,42 @@ +Author: Ruifeng Wang +Origin: https://git.dpdk.org/dpdk/commit/?id=78bfe1666b2063e3fc3fa51e757159f53e1fc779 +Description: fix armhf build with NEON +--- a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc +@@ -45,7 +45,6 @@ CONFIG_RTE_LIBRTE_CXGBE_PMD=n + CONFIG_RTE_LIBRTE_E1000_PMD=n + CONFIG_RTE_LIBRTE_ENIC_PMD=n + CONFIG_RTE_LIBRTE_FM10K_PMD=n +-CONFIG_RTE_LIBRTE_I40E_PMD=n + CONFIG_RTE_LIBRTE_IXGBE_PMD=n + CONFIG_RTE_LIBRTE_MLX4_PMD=n + CONFIG_RTE_LIBRTE_VMXNET3_PMD=n +--- a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile +@@ -74,7 +74,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_dcb.c + + SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev.c + SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c +-ifeq ($(CONFIG_RTE_ARCH_ARM64),y) ++ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) + SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_neon.c + else ifeq ($(CONFIG_RTE_ARCH_PPC_64),y) + SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_altivec.c +--- a/drivers/net/i40e/i40e_rxtx_vec_neon.c b/drivers/net/i40e/i40e_rxtx_vec_neon.c +@@ -6,6 +6,7 @@ + #include + #include + #include ++#include + + #include "base/i40e_prototype.h" + #include "base/i40e_type.h" +@@ -13,7 +14,6 @@ + #include "i40e_rxtx.h" + #include "i40e_rxtx_vec_common.h" + +-#include + + #pragma GCC diagnostic ignored "-Wcast-qual" + diff -Nru dpdk-18.11.10/debian/patches/series dpdk-18.11.10/debian/patches/series --- dpdk-18.11.10/debian/patches/series 2020-09-28 15:17:35.0 +0100 +++ dpdk-18.11.10/debian/patches/series 2020-10-26 10:44:37.0 + @@ -2,3 +2,4 @@ 0005-build-use-dependency-instead-of-find_library.patch 0006-build-reorder-libraries-and-build-eal-before-cmdline.patch 0007-build-use-dependency-for-libbsd-instead-of-manual-ap.patch +0008-net-i40e-support-aarch32.patch signature.asc Description: This is a digitally signed message part
Bug#978157: buster-pu: package iproute2/4.20.0-2+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: formo...@debian.org
Dear release team,
I would like to do a bugfix upload of iproute2 to buster-proposed-
updates. This would be the first upload for this source package, so
waiting for feedback before uploading.
The version would backport 3 bug fixes, which have been fixed in the
latest upstream release, and which were reported on Debian Buster by
users. They make some subcommands unusable or downright dangerous.
The first two are about fixing invalid json output - these bugs make
the affected subcommands output unusable, as consumers need valid
formatted json:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961278
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972784
The third bug is about a nasty race condition - if "ip netns add foo"
is used concurrently, it might get in a loop and create thousands of
mount points on the system, causing a self-dos.
The reporter found the issue when using the command in startup scripts
executed at boot.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949235
The fixes were validated by the reporters as well.
The source debdiff is attached.
Thank you!
--
Kind regards,
Luca Boccassi
diff -Nru iproute2-4.20.0/debian/changelog iproute2-4.20.0/debian/changelog
--- iproute2-4.20.0/debian/changelog 2019-01-10 20:04:14.0 +
+++ iproute2-4.20.0/debian/changelog 2020-12-03 18:42:49.0 +
@@ -1,3 +1,15 @@
+iproute2 (4.20.0-2+deb10u1) buster; urgency=medium
+
+ * Backport ip-route-print-route-type-in-JSON-output.patch. Fixes bug in
+json output, backported from upstream. (Closes: #961278)
+ * Backport tc-mqprio-json-ify-output.patch. Fixes bug in json output,
+backported from upstream. (Closes: #972784)
+ * Backport ip-netns-use-flock-when-setting-up-run-netns.patch. Fixes
+race condition that DOSes the system when using ip netns add at boot.
+(Closes: #949235)
+
+ -- Luca Boccassi Thu, 03 Dec 2020 18:42:49 +
+
iproute2 (4.20.0-2) unstable; urgency=medium
* Upload to unstable.
diff -Nru iproute2-4.20.0/debian/gbp.conf iproute2-4.20.0/debian/gbp.conf
--- iproute2-4.20.0/debian/gbp.conf 2019-01-09 15:03:12.0 +
+++ iproute2-4.20.0/debian/gbp.conf 2020-12-03 18:42:49.0 +
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = master
+debian-branch = buster
upstream-branch = upstream
pristine-tar = True
compression = xz
diff -Nru iproute2-4.20.0/debian/.gitlab-ci.yml iproute2-4.20.0/debian/.gitlab-ci.yml
--- iproute2-4.20.0/debian/.gitlab-ci.yml 2019-01-09 15:03:12.0 +
+++ iproute2-4.20.0/debian/.gitlab-ci.yml 2020-12-03 18:42:49.0 +
@@ -1,17 +1,8 @@
-include: https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-
-build:
-extends: .build-unstable
-
-reprotest:
-extends: .test-reprotest
-
-lintian:
-extends: .test-lintian
-
-autopkgtest:
-extends: .test-autopkgtest
-
-piuparts:
-extends: .test-piuparts
-
+---
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+ RELEASE: 'buster'
+ SALSA_CI_DISABLE_REPROTEST: 1
diff -Nru iproute2-4.20.0/debian/patches/ip-netns-use-flock-when-setting-up-run-netns.patch iproute2-4.20.0/debian/patches/ip-netns-use-flock-when-setting-up-run-netns.patch
--- iproute2-4.20.0/debian/patches/ip-netns-use-flock-when-setting-up-run-netns.patch 1970-01-01 01:00:00.0 +0100
+++ iproute2-4.20.0/debian/patches/ip-netns-use-flock-when-setting-up-run-netns.patch 2020-12-03 18:42:49.0 +
@@ -0,0 +1,86 @@
+Origin: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=975c4944e8d57b9f51960611e2bc2c0da6cd6864
+Bug-Debian: https://bugs.debian.org/949235
+Description: ip/netns: use flock when setting up /run/netns
+ If multiple ip processes are ran at the same time to set up
+ separate network namespaces, and it is the first time so /run/netns
+ has to be set up first, and they end up doing it at the same time,
+ the processes might enter a recursive loop creating thousands of
+ mount points, which might crash the system depending on resources
+ available.
+ Try to take a flock on /run/netns before doing the mount() dance, to
+ ensure this cannot happen. But do not try too hard, and if it fails
+ continue after printing a warning, to avoid introducing regressions.
+--- a/ip/ipnetns.c
b/ip/ipnetns.c
+@@ -1,5 +1,6 @@
+ /* SPDX-License-Identifier: GPL-2.0 */
+ #define _ATFILE_SOURCE
++#include
+ #include
+ #include
+ #include
+@@ -645,6 +646,7 @@
+ char netns_path[PATH_MAX];
+ const char *name;
+ int fd;
++ int lock;
+ int made_netns_run_dir_mount = 0;
+
+ if (argc < 1) {
+@@ -663,12 +665,37 @@
+ * namespace file in one namespace will unmount the network namespace
+ * file in all namespaces allowin
Bug#978157: buster-pu: package iproute2/4.20.0-2+deb10u1
On Thu, 31 Dec 2020 at 16:56, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > On Sat, 2020-12-26 at 19:20 +, Luca Boccassi wrote: > > I would like to do a bugfix upload of iproute2 to buster-proposed- > > updates. This would be the first upload for this source package, so > > waiting for feedback before uploading. > > > > The version would backport 3 bug fixes, which have been fixed in the > > latest upstream release, and which were reported on Debian Buster by > > users. They make some subcommands unusable or downright dangerous. > > > > The first two are about fixing invalid json output - these bugs make > > the affected subcommands output unusable, as consumers need valid > > formatted json: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961278 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972784 > > The metadata for #961278 implies that it still affects the package in > unstable. I assume that's simply an oversight? If so, please add an > appropriate fixed version, and go ahead with the upload; if not, please > fix unstable first. > > Regards, > > Adam Hi, Yes it was fixed upstream long before it was reported, so I forgot to close it. Done now, and uploaded. Thanks! Kind regards, Luca Boccassi
Bug#974667: nmu: collectd_5.12.0-4
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org Dear Release Team, Now that src:dpdk and src:openvswitch have migrated to testing, could you please do a rebuild of src:collectd ? It has Recommends on libraries from src:dpdk rather than Depends so it doesn't block upgrades, but it should get rebuilt so that it can recommend the new ABI packages. nmu collectd_5.12.0-4 . ANY . -m 'Rebuild against the new libdpdk-dev' Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#954661: transition: dpdk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: z...@debian.org pkg-dpdk-de...@lists.alioth.debian.org Dear Release Team, The new DPDK 19.11 LTS is ready for unstable/testing, and we wish to begin the transition. It was already uploaded to experimental: https://tracker.debian.org/pkg/dpdk The reverse dependencies are collectd and openvswitch: https://tracker.debian.org/pkg/collectd https://tracker.debian.org/pkg/openvswitch Collectd rebuilds without any changes. Openvswitch needs a new version, 2.13, which Thomas already uploaded to experimental and that is ready for unstable. There's no auto-transition tracker for some reason, if I understand the obscure syntax it should be something like: Affected: .build-depends ~ /libdpdk-dev/ Good: .depends ~ /librte-eal20.0/ Bad: .depends ~ /librte-eal18.11/ Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#954661: transition: dpdk
On Fri, 2020-03-27 at 13:32 +0100, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 22/03/2020 13:31, Luca Boccassi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-CC: z...@debian.org > > pkg-dpdk-de...@lists.alioth.debian.org > > > > Dear Release Team, > > > > The new DPDK 19.11 LTS is ready for unstable/testing, and we wish > > to > > begin the transition. It was already uploaded to experimental: > > > > https://tracker.debian.org/pkg/dpdk > > > > The reverse dependencies are collectd and openvswitch: > > > > https://tracker.debian.org/pkg/collectd > > https://tracker.debian.org/pkg/openvswitch > > > > Collectd rebuilds without any changes. Openvswitch needs a new > > version, > > 2.13, which Thomas already uploaded to experimental and that is > > ready > > for unstable. > > > > There's no auto-transition tracker for some reason, if I understand > > the > > obscure syntax it should be something like: > > > > Affected: .build-depends ~ /libdpdk-dev/ > > Good: .depends ~ /librte-eal20.0/ > > Bad: .depends ~ /librte-eal18.11/ > > There's no automatic tracker because librte-eal18.11 has no reverse > dependencies. collectd only recommends it (via shlibs:Recommends, so > we can > binNMU it) and I don't see openvswitch having any kind of dependency > on > librte-eal18.11. Am I missing something? > > In any case you can go ahead already. > > Cheers, > Emilio Uploaded to sid. Thomas, please go ahead and upload the new version of OVS once the builds are done. OVS doesn't link directly to the libraries, but dlopen() them (or something along those lines). It depends on the generic dpdk binary package which pulls in everything that is needed for that. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#954661: transition: dpdk
On Wed, 2020-04-08 at 11:29 +0200, Emilio Pozuelo Monfort wrote: > On 27/03/2020 14:27, Luca Boccassi wrote: > > On Fri, 2020-03-27 at 13:32 +0100, Emilio Pozuelo Monfort wrote: > > > Control: tags -1 confirmed > > > > > > On 22/03/2020 13:31, Luca Boccassi wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > X-Debbugs-CC: z...@debian.org > > > > pkg-dpdk-de...@lists.alioth.debian.org > > > > > > > > Dear Release Team, > > > > > > > > The new DPDK 19.11 LTS is ready for unstable/testing, and we > > > > wish > > > > to > > > > begin the transition. It was already uploaded to experimental: > > > > > > > > https://tracker.debian.org/pkg/dpdk > > > > > > > > The reverse dependencies are collectd and openvswitch: > > > > > > > > https://tracker.debian.org/pkg/collectd > > > > https://tracker.debian.org/pkg/openvswitch > > > > > > > > Collectd rebuilds without any changes. Openvswitch needs a new > > > > version, > > > > 2.13, which Thomas already uploaded to experimental and that is > > > > ready > > > > for unstable. > > > > > > > > There's no auto-transition tracker for some reason, if I > > > > understand > > > > the > > > > obscure syntax it should be something like: > > > > > > > > Affected: .build-depends ~ /libdpdk-dev/ > > > > Good: .depends ~ /librte-eal20.0/ > > > > Bad: .depends ~ /librte-eal18.11/ > > > > > > There's no automatic tracker because librte-eal18.11 has no > > > reverse > > > dependencies. collectd only recommends it (via shlibs:Recommends, > > > so > > > we can > > > binNMU it) and I don't see openvswitch having any kind of > > > dependency > > > on > > > librte-eal18.11. Am I missing something? > > > > > > In any case you can go ahead already. > > > > > > Cheers, > > > Emilio > > > > Uploaded to sid. Thomas, please go ahead and upload the new version > > of > > OVS once the builds are done. > > > > OVS doesn't link directly to the libraries, but dlopen() them (or > > something along those lines). It depends on the generic dpdk binary > > package which pulls in everything that is needed for that. > > dpdk has migrated to testing, and since there's no tracker for us to > follow > progress, I'll assume this is done and am closing the report. > > If something is still missing and needs action from us (e.g. some > binNMUs), > please let us know and will look at it. > > Cheers, > Emilio Both openvswitch and collectd had new source uploads shortly after the dpdk upload, and the resulting binaries linked with the new version have migrated to testing for both reverse dependencies, so we are indeed all good. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#843334: transition: czmq
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped from 3 to 4. https://packages.qa.debian.org/c/czmq.html Reverse dependencies source packages: rsyslog The reverse dependency rebuild cleanly without any patches. binNMU rebuilds should be all that's needed. libczmq4 is in experimental and it has rebuilt most architectures, with the mips and armv7 queued. I built locally in qemu and it was all fine so I do not expect trouble. I know it's a bit late, but given it's a very simple case I hope it can be authorized, to avoid having to maintain an old version for many years! Upstream will not release bug fixes for 3.0.x anymore. Thank you! Kind regards, Luca Boccassi
Bug#843334: transition: czmq
On Sat, 5 Nov 2016 22:43:46 + Luca Boccassi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped > from 3 to 4. > > https://packages.qa.debian.org/c/czmq.html > > Reverse dependencies source packages: > > rsyslog > > The reverse dependency rebuild cleanly without any patches. binNMU > rebuilds should be all that's needed. > > libczmq4 is in experimental and it has rebuilt most architectures, > with the mips and armv7 queued. I built locally in qemu and it was all > fine so I do not expect trouble. > > I know it's a bit late, but given it's a very simple case I hope it > can be authorized, to avoid having to maintain an old version for many > years! Upstream will not release bug fixes for 3.0.x anymore. > > Thank you! > > Kind regards, > Luca Boccassi Transition tracker item has been autogenerated now, here's the link: https://release.debian.org/transitions/html/auto-czmq.html Kind regards, Luca Boccassi
Bug#843334: transition: czmq
On Sun, 2016-11-06 at 11:01 +0100, Emilio Pozuelo Monfort wrote: > On 06/11/16 00:43, Luca Boccassi wrote: > > On Sat, 5 Nov 2016 22:43:46 +0000 Luca Boccassi > > wrote: > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: transition > >> > >> Dear release team, > >> > >> czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped > >> from 3 to 4. > >> > >> https://packages.qa.debian.org/c/czmq.html > >> > >> Reverse dependencies source packages: > >> > >> rsyslog > >> > >> The reverse dependency rebuild cleanly without any patches. binNMU > >> rebuilds should be all that's needed. > >> > >> libczmq4 is in experimental and it has rebuilt most architectures, > >> with the mips and armv7 queued. I built locally in qemu and it was all > >> fine so I do not expect trouble. > >> > >> I know it's a bit late, but given it's a very simple case I hope it > >> can be authorized, to avoid having to maintain an old version for many > >> years! Upstream will not release bug fixes for 3.0.x anymore. > >> > >> Thank you! > >> > >> Kind regards, > >> Luca Boccassi > > > > Transition tracker item has been autogenerated now, here's the link: > > > > https://release.debian.org/transitions/html/auto-czmq.html > > Go ahead. > > Cheers, > Emilio Thank you! Will upload tonight as I'm travelling. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#843334: transition: czmq
On Sun, 2016-11-06 at 10:44 +, Luca Boccassi wrote: > On Sun, 2016-11-06 at 11:01 +0100, Emilio Pozuelo Monfort wrote: > > On 06/11/16 00:43, Luca Boccassi wrote: > > > On Sat, 5 Nov 2016 22:43:46 + Luca Boccassi > > > wrote: > > >> Package: release.debian.org > > >> Severity: normal > > >> User: release.debian@packages.debian.org > > >> Usertags: transition > > >> > > >> Dear release team, > > >> > > >> czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped > > >> from 3 to 4. > > >> > > >> https://packages.qa.debian.org/c/czmq.html > > >> > > >> Reverse dependencies source packages: > > >> > > >> rsyslog > > >> > > >> The reverse dependency rebuild cleanly without any patches. binNMU > > >> rebuilds should be all that's needed. > > >> > > >> libczmq4 is in experimental and it has rebuilt most architectures, > > >> with the mips and armv7 queued. I built locally in qemu and it was all > > >> fine so I do not expect trouble. > > >> > > >> I know it's a bit late, but given it's a very simple case I hope it > > >> can be authorized, to avoid having to maintain an old version for many > > >> years! Upstream will not release bug fixes for 3.0.x anymore. > > >> > > >> Thank you! > > >> > > >> Kind regards, > > >> Luca Boccassi > > > > > > Transition tracker item has been autogenerated now, here's the link: > > > > > > https://release.debian.org/transitions/html/auto-czmq.html > > > > Go ahead. > > > > Cheers, > > Emilio > > Thank you! > > Will upload tonight as I'm travelling. > > Kind regards, > Luca Boccassi Hi, I have uploaded czmq 4.0.0-3 to unstable: https://packages.qa.debian.org/c/czmq/news/20161107T214955Z.html Will rsyslog be rebuilt automatically, or manually by the ftp/release team? Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#843334: transition: czmq
On Tue, 2016-11-08 at 19:07 +0100, Emilio Pozuelo Monfort wrote: > On 07/11/16 23:04, Luca Boccassi wrote: > > On Sun, 2016-11-06 at 10:44 +0000, Luca Boccassi wrote: > >> On Sun, 2016-11-06 at 11:01 +0100, Emilio Pozuelo Monfort wrote: > >>> On 06/11/16 00:43, Luca Boccassi wrote: > >>>> On Sat, 5 Nov 2016 22:43:46 + Luca Boccassi > >>>> wrote: > >>>>> Package: release.debian.org > >>>>> Severity: normal > >>>>> User: release.debian@packages.debian.org > >>>>> Usertags: transition > >>>>> > >>>>> Dear release team, > >>>>> > >>>>> czmq 4.0.0 was released yesterday, and it breaks ABI, which was bumped > >>>>> from 3 to 4. > >>>>> > >>>>> https://packages.qa.debian.org/c/czmq.html > >>>>> > >>>>> Reverse dependencies source packages: > >>>>> > >>>>> rsyslog > >>>>> > >>>>> The reverse dependency rebuild cleanly without any patches. binNMU > >>>>> rebuilds should be all that's needed. > >>>>> > >>>>> libczmq4 is in experimental and it has rebuilt most architectures, > >>>>> with the mips and armv7 queued. I built locally in qemu and it was all > >>>>> fine so I do not expect trouble. > >>>>> > >>>>> I know it's a bit late, but given it's a very simple case I hope it > >>>>> can be authorized, to avoid having to maintain an old version for many > >>>>> years! Upstream will not release bug fixes for 3.0.x anymore. > >>>>> > >>>>> Thank you! > >>>>> > >>>>> Kind regards, > >>>>> Luca Boccassi > >>>> > >>>> Transition tracker item has been autogenerated now, here's the link: > >>>> > >>>> https://release.debian.org/transitions/html/auto-czmq.html > >>> > >>> Go ahead. > >>> > >>> Cheers, > >>> Emilio > >> > >> Thank you! > >> > >> Will upload tonight as I'm travelling. > >> > >> Kind regards, > >> Luca Boccassi > > > > Hi, > > > > I have uploaded czmq 4.0.0-3 to unstable: > > > > https://packages.qa.debian.org/c/czmq/news/20161107T214955Z.html > > > > Will rsyslog be rebuilt automatically, or manually by the ftp/release > > team? > > Manually by the release team. I scheduled that earlier today. > > Cheers, > Emilio Hi, The rebuild of rsyslog has not yet migrated to stretch, is that a manual process as well? Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#916351: transition: dpdk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, We would like to move the new DPDK LTS release 18.11-1 from experimental to unstable. This breaks the various libraries ABI compat, so a transition is needed. https://tracker.debian.org/pkg/dpdk The new DPDK packages are all in experimental, having passed the NEW que ue, and have built on all supported architectures. Note that from this project follows a boost-like model, so the ABI revision is named after the upstream major version (eg: librte- eal17.11 -> librte-eal18.11). This is done because most libraries built from DPDK break ABI compat on every single major release. Reverse build dependency source packages: collectd: The reverse dependency builds needs a source update to build with this new version, to do with autoconf. The fix has been merged upstream [1] and backported to the stable branch currently in sid [2]. I have opened a bug and attached a patch, which I verified works [3]. It seems like there's another bug which should be fixed to allow migration, but the change is quite simple. I have prepared a source NMU which I could upload if necessary. Note that although collectd only recommends the dpdk libraries, it does so because the plugin is optional. The plugin still needs to be rebuilt against the new libraries ABIs to work. virtio-forwarder: This package has never entered testing as of yet, due to another bug (which seems very simple to solve). The issue with DPDK is that virtio- forwarder imports DPDK's makefiles rather than shipping its own, and these are deprecated. I reported this downstream [4] and upstream [5]. Given it's not in testing I have not yet prepared a patch. I might do so in the next few days. Thanks! -- Kind regards, Luca Boccassi [1] https://github.com/collectd/collectd/pull/3015 [2] https://github.com/collectd/collectd/pull/3017 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915419 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915417 [5] https://github.com/Netronome/virtio-forwarder/issues/3 signature.asc Description: This is a digitally signed message part
Bug#916351: transition: dpdk
On Thu, 13 Dec 2018 13:26:33 + Luca Boccassi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > We would like to move the new DPDK LTS release 18.11-1 from > experimental to unstable. This breaks the various libraries ABI compat, > so a transition is needed. > > https://tracker.debian.org/pkg/dpdk > > The new DPDK packages are all in experimental, having passed the NEW > que > ue, and have built on all supported architectures. > > Note that from this project follows a boost-like model, so > the ABI revision is named after the upstream major version (eg: librte- > eal17.11 -> librte-eal18.11). This is done because most libraries built > from DPDK break ABI compat on every single major release. > > Reverse build dependency source packages: > > collectd: > > The reverse dependency builds needs a source update to build with this > new version, to do with autoconf. The fix has been merged upstream [1] > and backported to the stable branch currently in sid [2]. > I have opened a bug and attached a patch, which I verified works [3]. > It seems like there's another bug which should be fixed to allow > migration, but the change is quite simple. I have prepared a source NMU > which I could upload if necessary. > > Note that although collectd only recommends the dpdk libraries, it does > so because the plugin is optional. The plugin still needs to be rebuilt > against the new libraries ABIs to work. > > virtio-forwarder: > > This package has never entered testing as of yet, due to another bug > (which seems very simple to solve). The issue with DPDK is that virtio- > forwarder imports DPDK's makefiles rather than shipping its own, and > these are deprecated. I reported this downstream [4] and upstream [5]. > Given it's not in testing I have not yet prepared a patch. I might do > so in the next few days. > > Thanks! > > -- > Kind regards, > Luca Boccassi > > [1] https://github.com/collectd/collectd/pull/3015 > [2] https://github.com/collectd/collectd/pull/3017 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915419 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915417 > [5] https://github.com/Netronome/virtio-forwarder/issues/3 I have a tentative fix for virtio-forwarder, sent upstream and debdiff attached to the relevant bug. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#916351: transition: dpdk
Control: block -1 915419 915692 On Wed, 2018-12-19 at 11:34 +0100, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 13/12/2018 22:05, Luca Boccassi wrote: > > On Thu, 13 Dec 2018 13:26:33 +0000 Luca Boccassi > > wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Dear release team, > > > > > > We would like to move the new DPDK LTS release 18.11-1 from > > > experimental to unstable. This breaks the various libraries ABI > > > > compat, > > > so a transition is needed. > > > > > > https://tracker.debian.org/pkg/dpdk > > > > > > The new DPDK packages are all in experimental, having passed the > > > NEW > > > que > > > ue, and have built on all supported architectures. > > > > > > Note that from this project follows a boost-like model, so > > > the ABI revision is named after the upstream major version (eg: > > > > librte- > > > eal17.11 -> librte-eal18.11). This is done because most libraries > > > > built > > > from DPDK break ABI compat on every single major release. > > > > > > Reverse build dependency source packages: > > > > > > collectd: > > > > > > The reverse dependency builds needs a source update to build with > > > > this > > > new version, to do with autoconf. The fix has been merged > > > upstream > > > > [1] > > > and backported to the stable branch currently in sid [2]. > > > I have opened a bug and attached a patch, which I verified works > > > [3]. > > > It seems like there's another bug which should be fixed to allow > > > migration, but the change is quite simple. I have prepared a > > > source > > > > NMU > > > which I could upload if necessary. > > > > > > Note that although collectd only recommends the dpdk libraries, > > > it > > > > does > > > so because the plugin is optional. The plugin still needs to be > > > > rebuilt > > > against the new libraries ABIs to work. > > > > > > virtio-forwarder: > > > > > > This package has never entered testing as of yet, due to another > > > bug > > > (which seems very simple to solve). The issue with DPDK is that > > > > virtio- > > > forwarder imports DPDK's makefiles rather than shipping its own, > > > and > > > these are deprecated. I reported this downstream [4] and upstream > > > > [5]. > > > Given it's not in testing I have not yet prepared a patch. I > > > might do > > > so in the next few days. > > > > > > Thanks! > > > > > > -- > > > Kind regards, > > > Luca Boccassi > > > > > > [1] https://github.com/collectd/collectd/pull/3015 > > > [2] https://github.com/collectd/collectd/pull/3017 > > > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915419 > > > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915417 > > > [5] https://github.com/Netronome/virtio-forwarder/issues/3 > > > > I have a tentative fix for virtio-forwarder, sent upstream and > > debdiff > > attached to the relevant bug. > > Go ahead. > > Cheers, > Emilio Thanks, the virtio-forwarder patch should be ready and agreed with upstream by the end of the week, I will then proceed with the source upload of DPDK and the source NMUs of collectd and virtio-forwarder (unless they get updated by the maintainers beforehand). -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#916351: transition: dpdk
On Wed, 19 Dec 2018 15:59:48 +0100 Luca Boccassi wrote: > Control: block -1 915419 915692 > > On Wed, 2018-12-19 at 11:34 +0100, Emilio Pozuelo Monfort wrote: > > Control: tags -1 confirmed > > > > On 13/12/2018 22:05, Luca Boccassi wrote: > > > On Thu, 13 Dec 2018 13:26:33 + Luca Boccassi > > > wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > > > > > Dear release team, > > > > > > > > We would like to move the new DPDK LTS release 18.11-1 from > > > > experimental to unstable. This breaks the various libraries ABI > > > > > > compat, > > > > so a transition is needed. > > > > > > > > https://tracker.debian.org/pkg/dpdk > > > > > > > > The new DPDK packages are all in experimental, having passed the > > > > NEW > > > > que > > > > ue, and have built on all supported architectures. > > > > > > > > Note that from this project follows a boost-like model, so > > > > the ABI revision is named after the upstream major version (eg: > > > > > > librte- > > > > eal17.11 -> librte-eal18.11). This is done because most libraries > > > > > > built > > > > from DPDK break ABI compat on every single major release. > > > > > > > > Reverse build dependency source packages: > > > > > > > > collectd: > > > > > > > > The reverse dependency builds needs a source update to build with > > > > > > this > > > > new version, to do with autoconf. The fix has been merged > > > > upstream > > > > > > [1] > > > > and backported to the stable branch currently in sid [2]. > > > > I have opened a bug and attached a patch, which I verified works > > > > [3]. > > > > It seems like there's another bug which should be fixed to allow > > > > migration, but the change is quite simple. I have prepared a > > > > source > > > > > > NMU > > > > which I could upload if necessary. > > > > > > > > Note that although collectd only recommends the dpdk libraries, > > > > it I have done the source upload of DPDK 18.11-2 to unstable. I have done the source NMU of collectd to DELAYED/2 on Saturday, which means it will be uploaded in 12 hours. I will do the source sponsored upload of virtio-forwarder, as requested by the maintainer, in a few hours once DPDK has built on all architectures. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#916351: transition: dpdk
Control: close -1 On Mon, 2018-12-24 at 11:19 +0100, Luca Boccassi wrote: > On Wed, 19 Dec 2018 15:59:48 +0100 Luca Boccassi > wrote: > > Control: block -1 915419 915692 > > > > On Wed, 2018-12-19 at 11:34 +0100, Emilio Pozuelo Monfort wrote: > > > Control: tags -1 confirmed > > > > > > On 13/12/2018 22:05, Luca Boccassi wrote: > > > > On Thu, 13 Dec 2018 13:26:33 + Luca Boccassi > > > or > > g> > > > > wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > > > > > > Dear release team, > > > > > > > > > > We would like to move the new DPDK LTS release 18.11-1 from > > > > > experimental to unstable. This breaks the various libraries > > > > > ABI > > > > > > > > > > > > compat, > > > > > so a transition is needed. > > > > > > > > > > https://tracker.debian.org/pkg/dpdk > > > > > > > > > > The new DPDK packages are all in experimental, having passed > > the > > > > > NEW > > > > > que > > > > > ue, and have built on all supported architectures. > > > > > > > > > > Note that from this project follows a boost-like model, so > > > > > the ABI revision is named after the upstream major version > > > > > (eg: > > > > > > > > > > > > librte- > > > > > eal17.11 -> librte-eal18.11). This is done because most > > libraries > > > > > > > > built > > > > > from DPDK break ABI compat on every single major release. > > > > > > > > > > Reverse build dependency source packages: > > > > > > > > > > collectd: > > > > > > > > > > The reverse dependency builds needs a source update to build > > with > > > > > > > > this > > > > > new version, to do with autoconf. The fix has been merged > > > > > upstream > > > > > > > > > > > > [1] > > > > > and backported to the stable branch currently in sid [2]. > > > > > I have opened a bug and attached a patch, which I verified > > works > > > > > [3]. > > > > > It seems like there's another bug which should be fixed to > > allow > > > > > migration, but the change is quite simple. I have prepared a > > > > > source > > > > > > > > > > > > NMU > > > > > which I could upload if necessary. > > > > > > > > > > Note that although collectd only recommends the dpdk > > > > > libraries, > > > > > it > > I have done the source upload of DPDK 18.11-2 to unstable. > I have done the source NMU of collectd to DELAYED/2 on Saturday, > which > means it will be uploaded in 12 hours. > > I will do the source sponsored upload of virtio-forwarder, as > requested > by the maintainer, in a few hours once DPDK has built on all > architectures. Hi, Both collectd and virtio-forwarder have migrated to testing, with the new version of DPDK. The old packages appear to have been already removed from buster, so I think this can be closed now. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#924126: unblock: czmq/4.2.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
Please consider unblocking migration of czmq 4.2.0-2 to buster to fix
#923695. It will be eligible to migrate in 5 days on the 14th, which is
past the deadline.
It is a tiny change (added 2 missing dependencies in the -dev package)
that fixes reverse dependencies builds in minimal chroots. There are
downstream users that would be affected by this bug in buster.
Background:
Version 4.2.0 uses Requires.private in the pkg-config file, which means
that if a program depends on libczmq-dev, it needs uuid-dev and
libsystemd-dev [linux-any] installed or pkg-config --cflags libczmq
will fail due to the missing uuid.pc and libsystemd.pc.
Despite having done this change upstream myself, AND despite having
done myself the upstream release noting this in the changelog and
explicitly saying that packagers should update the -dev or -devel list
of dependencies accordingly, and despite having done the 4.2.0-1 upload
to Debian myself, I then of course proceeded to _completely forget_ to
update said dependency list, because I am very silly.
Debdiff inlined below.
Thank you in advance!
--
Kind regards,
Luca Boccassi
diff -Nru czmq-4.2.0/debian/changelog czmq-4.2.0/debian/changelog
--- czmq-4.2.0/debian/changelog 2019-02-10 18:41:55.0
+
+++ czmq-4.2.0/debian/changelog 2019-03-03 22:23:19.0
+
@@ -1,3 +1,10 @@
+czmq (4.2.0-2) unstable; urgency=medium
+
+ * Add uuid-dev and libsystemd-dev dependencies on libczmq-dev,
required
+by pkg-config --cflags libczmq.pc. (Closes: #923695)
+
+ -- Luca Boccassi Sun, 03 Mar 2019 22:23:19 +
+
czmq (4.2.0-1) unstable; urgency=medium
* New upstream version 4.2.0
diff -Nru czmq-4.2.0/debian/control czmq-4.2.0/debian/control
--- czmq-4.2.0/debian/control 2019-02-10 18:41:55.0
+
+++ czmq-4.2.0/debian/control 2019-03-03 22:11:35.0
+
@@ -41,6 +41,8 @@
Architecture: any
Depends: ${misc:Depends},
libzmq3-dev,
+ uuid-dev,
+ libsystemd-dev [linux-any],
libczmq4 (= ${binary:Version})
Multi-Arch: same
Description: High-level C binding for ZeroMQ (development files)
signature.asc
Description: This is a digitally signed message part
Bug#924306: unblock: live-build/1:20190311
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
Please consider unblocking migration of live-build 1:20190311 to buster
to fix #924293. It will be eligible to migrate in 10 days on the 21st,
which is past the deadline.
The small fix is necessary to fully support building buster images with
live-build.
An additional, welcome fix is a switch away from the deprecated
httpredir.debian.org to deb.debian.org as the default mirror URL.
The fix for the former is adding a symlink to a directory, which
debdiff shows as a bunch of new files which is not strictly true, so
I've truncated that from the debdiff inlined below.
Thank you!
--
Kind regards,
Luca Boccassi
diff -Nru live-build-20180925/debian/changelog
live-build-20190311/debian/changelog
--- live-build-20180925/debian/changelog2018-09-25 14:28:19.0
+0100
+++ live-build-20190311/debian/changelog2019-03-11 10:08:38.0
+
@@ -1,3 +1,14 @@
+live-build (1:20190311) unstable; urgency=medium
+
+ [ Hideki Yamane ]
+ * use deb.debian.org as default
+ * We should add buster for release. (Closes: #924293)
+
+ [ Luca Boccassi ]
+ * Bump Standards-Version to 4.3.0, no changes.
+
+ -- Luca Boccassi Mon, 11 Mar 2019 10:08:38 +
+
live-build (1:20180925) unstable; urgency=medium
[ Raphaël Hertzog ]
diff -Nru live-build-20180925/debian/control live-build-20190311/debian/control
--- live-build-20180925/debian/control 2018-09-21 11:41:00.0 +0100
+++ live-build-20190311/debian/control 2019-03-11 10:08:20.0 +
@@ -8,7 +8,7 @@
debhelper (>= 10~),
po4a,
gettext,
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
Rules-Requires-Root: no
Homepage: https://debian-live.alioth.debian.org/live-build/
Vcs-Browser: https://salsa.debian.org/live-team/live-build
diff -Nru live-build-20180925/functions/defaults.sh
live-build-20190311/functions/defaults.sh
--- live-build-20180925/functions/defaults.sh 2018-06-07 18:29:28.0
+0100
+++ live-build-20190311/functions/defaults.sh 2019-03-11 10:05:40.0
+
@@ -326,12 +326,12 @@
# Setting mirror to fetch packages from
case "${LB_MODE}" in
debian)
-
LB_MIRROR_BOOTSTRAP="${LB_MIRROR_BOOTSTRAP:-http://ftp.debian.org/debian/}";
+
LB_MIRROR_BOOTSTRAP="${LB_MIRROR_BOOTSTRAP:-http://deb.debian.org/debian/}";
LB_PARENT_MIRROR_BOOTSTRAP="${LB_PARENT_MIRROR_BOOTSTRAP:-${LB_MIRROR_BOOTSTRAP}}"
;;
progress-linux)
-
LB_PARENT_MIRROR_BOOTSTRAP="${LB_PARENT_MIRROR_BOOTSTRAP:-http://ftp.debian.org/debian/}";
+
LB_PARENT_MIRROR_BOOTSTRAP="${LB_PARENT_MIRROR_BOOTSTRAP:-http://deb.debian.org/debian/}";
LB_MIRROR_BOOTSTRAP="${LB_MIRROR_BOOTSTRAP:-http://cdn.archive.progress-linux.org/packages/}";
;;
esac
@@ -355,12 +355,12 @@
# Setting mirror which ends up in the image
case "${LB_MODE}" in
debian)
-
LB_MIRROR_BINARY="${LB_MIRROR_BINARY:-http://httpredir.debian.org/debian/}";
+
LB_MIRROR_BINARY="${LB_MIRROR_BINARY:-http://deb.debian.org/debian/}";
LB_PARENT_MIRROR_BINARY="${LB_PARENT_MIRROR_BINARY:-${LB_MIRROR_BINARY}}"
;;
progress-linux)
-
LB_PARENT_MIRROR_BINARY="${LB_PARENT_MIRROR_BINARY:-http://ftp.debian.org/debian/}";
+
LB_PARENT_MIRROR_BINARY="${LB_PARENT_MIRROR_BINARY:-http://deb.debian.org/debian/}";
LB_MIRROR_BINARY="${LB_MIRROR_BINARY:-${LB_MIRROR_CHROOT}}"
;;
esac
signature.asc
Description: This is a digitally signed message part
Bug#863549: unblock: nvidia-graphics-drivers/375.66-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package nvidia-graphics-drivers nvidia-graphics-drivers in stretch (non-free) is affected by the following "high" priority CVEs: CVE-2017-0350 CVE-2017-0351 CVE-2017-0352 [1] Tracked by Debian bug #863515 [2] and fixed by upstream version 375.66. 375.66-1 has just been uploaded to unstable. Please consider unblocking the new version 375.66-1 to allow it to migrate to testing, if possible in 5 days to allow plenty time before the deadline of June the 9th. Given this is a non-free package that includes upstream proprietary binary blobs, the attached debdiff only covers the changes in the debian/ directory. The changes with the previous versions are: - Update changelog to mention upstream changes - Update changelog to sync with updates to stable and oldstable - Drop kernel modules patches merged upstream - Adjust symbols files for library changes in 375.66 - Adjust list of supported hardware IDs (nv-readme.ids) - Adjust source package metadata to mark the kernel modules as tested up to Linux 4.10 Kind regards, Luca Boccassi [1] https://security-tracker.debian.org/tracker/CVE-2017-0350 https://security-tracker.debian.org/tracker/CVE-2017-0351 https://security-tracker.debian.org/tracker/CVE-2017-0352 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863515diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.39/debian/changelog nvidia-graphics-drivers-375.66/debian/changelog --- nvidia-graphics-drivers-375.39/debian/changelog 2017-02-23 15:36:38.0 + +++ nvidia-graphics-drivers-375.66/debian/changelog 2017-05-28 12:03:11.0 +0100 @@ -1,3 +1,58 @@ +nvidia-graphics-drivers (375.66-1) unstable; urgency=medium + + * New upstream long lived branch release 375.66 (2017-05-04). +* Fixed CVE-2017-0350, CVE-2017-0351, CVE-2017-0352. (Closes: #863515) +- Added support for the following GPUs: GeForce GTX 1080 Ti, Quadro P3000, + Quadro M520, TITAN Xp +- Fixed a bug that could cause EGL applications to crash when calling + eglInitialize() multiple times on X11-backed displays. +- Fixed a regression that could cause rendering corruption on a monitor + connected via DisplayPort upon a modeset event (for example, changing + resolutions or power cycling the monitor). +- Updated the display configuration page in the nvidia-settings control + panel to accurately reflect HDMI 3D refresh rates. +- Fixed a bug that could cause OpenGL applications to crash when VT + switching between multiple X servers. +- Fixed a bug that caused the system to become unresponsive after resuming + from power management suspend/hibernate. Additional symptoms of this bug + included display flickering and "Xid 56" errors in the kernel log. +- Fixed a bug that caused backlight brightness to not be controllable on + some notebooks with DisplayPort internal panels. +- Fixed a bug that left HDMI and DisplayPort audio muted after a + framebuffer console mode was restored. For some displays, this caused the + display to remain blank. +- Fixed a bug that caused audio over DisplayPort to stop working when the + monitor was unplugged and plugged back in or awoken from DPMS + power-saving mode. +- Restored support for the following GPU: GRID K520 +- Fixed a regression that caused corruption in certain applications, such + as window border shadows in Unity, after resuming from suspend. +- Installation of the nvidia-drm kernel module is now optional. The new + '--no-drm' option can be used to prevent nvidia-installer from building + and installing nvidia-drm, on systems where this kernel module fails to + build and/or load. +- Fixed a bug that could cause some applications to crash when running with + PRIME Sync. +- Fixed a bug that prevented PRIME Sync from working on notebooks with + GeForce GTX 4xx and 5xx series GPUs. +- Fixed a bug that caused OpenGL apps to have excessive CPU usage when + running with PRIME Sync but without native displays enabled. +- Fixed a bug that could cause PRIME Sync to deadlock in the kernel, + particularly common on Linux 4.10. +- Fixed a bug that caused PRIME Sync to run slowly on systems with Pascal + GPUs. + + [ Andreas Beckmann ] + * Merge changes from 340.102-1 (jessie). + + [ Luca Boccassi ] + * Update nv-readme.ids + * Update symbols files + * Drop deprecated-cpu-events.patch, dma-fence-rename.patch and +vmf-address.patch, fixed upstream + + -- Luca Boccassi Sun, 28 May 2017 12:03:11 +0100 + nvidia-graphics-drivers (375.39-1) unstable; urgency=medium * New upstream long lived branch release 375.39 (2017-02-14). @@ -851,6 +906,7 @@ * Drop incomplete Perfkit support. * nvidia-detect: Drop support for squeeze(-l
Bug#863549: unblock: nvidia-graphics-drivers/375.66-1
On May 28, 2017 14:30, "Jonathan Wiltshire" wrote: Control: tag -1 moreinfo Hi, On Sun, May 28, 2017 at 01:08:58PM +0100, Luca Boccassi wrote: > - Update changelog to sync with updates to stable and oldstable This isn't right. Packages updated in stable are divergent; the changelog for a package in stretch should include only its history in experimental, unstable and maybe stretch if tpu has been used. We are strict about this because the BTS uses this information for calculating affected suites. Thanks, Hello Jonathan, Sorry, I should have been clearer: what we try to keep synched is not the upstream code, but the packaging code. Scripts to fetch the upstream installers and create source tarballs, to create dkms packages, package individual libraries separately, etc. Maintaining this upstream proprietary driver is quite complex, and this really helps a lot keeping things sane. Hope this helps. Kind regards, Luca Boccassi
Bug#864350: unblock: czmq/4.0.2-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package czmq A memory leak was found a few days ago upstream in a hash table implementation offered by this library. This has been fixed upstream and has been tested there for a few days now [1]. I opened a bug to track it in Debian [2] and I have backported the fix, it's a single line patch that adds the missing free() call and I have uploaded it to unstable this morning. The debdiff is attached and as you can see it consists in just the patch and the single changelog entry. Please consider allowing this for Stretch, so unblock with a 2 day delay. I believe a fix for a memory leak should qualify as an exception. Thank you! Kind regards, Luca Boccassi [1] https://github.com/zeromq/czmq/pull/1675 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864342diff -Nru czmq-4.0.2/debian/changelog czmq-4.0.2/debian/changelog --- czmq-4.0.2/debian/changelog 2017-01-24 13:33:14.0 + +++ czmq-4.0.2/debian/changelog 2017-06-07 10:22:32.0 +0100 @@ -1,3 +1,11 @@ +czmq (4.0.2-7) unstable; urgency=medium + + * Add 0007-zhashx_purge-leak-when-shrinking.patch backported from +upstream to fix memory leak in zhashx_purge when shrinking the table. +(Closes: #864342) + + -- Luca Boccassi Wed, 07 Jun 2017 10:22:32 +0100 + czmq (4.0.2-6) unstable; urgency=medium * Set version of symbols added by patch to 4.0.2-4~ to fix L:E diff -Nru czmq-4.0.2/debian/patches/0007-zhashx_purge-leak-when-shrinking.patch czmq-4.0.2/debian/patches/0007-zhashx_purge-leak-when-shrinking.patch --- czmq-4.0.2/debian/patches/0007-zhashx_purge-leak-when-shrinking.patch 1970-01-01 01:00:00.0 +0100 +++ czmq-4.0.2/debian/patches/0007-zhashx_purge-leak-when-shrinking.patch 2017-06-07 10:14:48.0 +0100 @@ -0,0 +1,27 @@ +From 80624b71a112ff95e9f72ec379bca0c321d87623 Mon Sep 17 00:00:00 2001 +From: Jim Klimov +Date: Thu, 1 Jun 2017 18:15:36 +0200 +Subject: [PATCH] Problem: zhashx_purge() seems to leak when shrinking + +Solution: freen() the old self->items before reassigning to the newly allocated smaller one + +Signed-off-by: Jim Klimov +--- + src/zhashx.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/zhashx.c b/src/zhashx.c +index 0631db14..bafab82b 100644 +--- a/src/zhashx.c b/src/zhashx.c +@@ -395,6 +395,7 @@ zhashx_purge (zhashx_t *self) + size_t limit = primes [INITIAL_PRIME]; + item_t **items = (item_t **) zmalloc (sizeof (item_t *) * limit); + assert (items); ++free (self->items); + self->prime_index = INITIAL_PRIME; + self->chain_limit = INITIAL_CHAIN; + self->items = items; +-- +2.11.0 + diff -Nru czmq-4.0.2/debian/patches/series czmq-4.0.2/debian/patches/series --- czmq-4.0.2/debian/patches/series 2017-01-24 11:32:31.0 + +++ czmq-4.0.2/debian/patches/series 2017-06-07 09:58:19.0 +0100 @@ -4,3 +4,4 @@ 0004-zpoller_remove-does-not-always-fail.patch 0005-zsys_shutdown-does-not-call-zmq_term.patch 0006-public-API-changes-depending-on-libzmq-version.patch +0007-zhashx_purge-leak-when-shrinking.patch signature.asc Description: This is a digitally signed message part
Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
The non-free proprietary nvidia-graphics-drivers version 375.66 in
Stretch is affected by CVE-2017-6257 and CVE-2017-6259. Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869783
Please consider allowing the new upstream version 375.82, which fixes
these CVEs, in proposed-updates. As usual with these proprietary
drivers, we cannot just cherry-pick the fixes for the CVEs as they are
in the binary blobs.
I have tested this new version on a Stretch amd64 desktop and didn't
encounter any issue.
The debdiff from 375.66-2~deb9u1 to 375.82-1 is attached.
Apart from the new upstream version, the other bug fixes are:
- update binary library blobs symbols files reflecting upstream changes
- allow parallel dkms builds if requested (#864639) by a user
- re-allow dkms ccache usage if enabled by a user
- switch watch files protocol to https, as upstream deprecated ftp
(#868815)
- mark the dkms modules as build-tested up to kernel 4.11
- add support for buster in the nvidia-detect script (#866126), that
helps the users choose the correct drivers that support their hardware
Kind regards,
Luca Boccassidiff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/bug-control.mk nvidia-graphics-drivers-375.82/debian/bug-control.mk
--- nvidia-graphics-drivers-375.66/debian/bug-control.mk 2017-02-23 15:37:37.0 +
+++ nvidia-graphics-drivers-375.82/debian/bug-control.mk 2017-07-26 20:22:43.0 +0100
@@ -46,6 +46,7 @@
libdrm-nouveau2
xserver-xorg-video-nouveau
make
+ ccache
libopencl1
opencl-icd
libvulkan1
diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/changelog nvidia-graphics-drivers-375.82/debian/changelog
--- nvidia-graphics-drivers-375.66/debian/changelog 2017-07-16 13:35:22.0 +0100
+++ nvidia-graphics-drivers-375.82/debian/changelog 2017-07-26 21:42:00.0 +0100
@@ -1,3 +1,43 @@
+nvidia-graphics-drivers (375.82-1) unstable; urgency=high
+
+ * New upstream long lived branch release 375.82 (2017-07-24).
+* Fixed CVE-2017-6257, CVE-2017-6259. (Closes: #869783)
+- Fix a bug with GLX_EXT_buffer_age where incorrect buffer age values would
+ be reported for SLI AFR configurations. In such configurations buffer age
+ may now be greater than 3, the previous maximum buffer age.
+- Fixed a bug that could cause hanging and Xids when performing RandR
+ transforms with Overlay and SLI enabled.
+- Improved handling of framebuffer console restore on systems booted in
+ UEFI mode.
+- Extended the information reported by the NVIDIA Xinerama X extension to
+ report PRIME displays in addition to directly-connected displays.
+- Fixed a bug that caused HDMI audio devices to appear or disappear
+ inconsistently when HDMI devices were hotplugged or unplugged.
+- Fixed a bug that could cause driver errors when setting modes on X
+ screens running at Depth 8 or Depth 15.
+- Fixed a bug that could cause intermittent kernel panics when running with
+ PRIME Sync.
+- Fixed a bug that caused a kernel panic when hotplugging HDMI displays on
+ some Zotac mini PCs.
+- Updated nvidia-installer to label kernel modules with SELinux file type
+ 'modules_object_t'. Some system SELinux policies only permit loading of
+ kernel modules with this SELinux file type.
+- Removed support for checking for and downloading updated driver packages
+ and precompiled kernel interfaces from nvidia-installer. This
+ functionality was limited to unencrypted ftp and http, and was
+ implemented using code that is no longer actively maintained.
+
+ [ Andreas Beckmann ]
+ * nvidia-kernel-dkms: Honor parallel setting from dkms. (Closes: #864639)
+ * Do not prevent ccache usage. The bug was fixed in ccache 3.0 (in squeeze).
+ * Switch watch URL from ftp:// to https://. (Closes: #868815)
+
+ [ Luca Boccassi ]
+ * Add support for buster/sid in nvidia-detect. (Closes: #866126)
+ * Update symbols files.
+
+ -- Luca Boccassi Wed, 26 Jul 2017 21:42:00 +0100
+
nvidia-graphics-drivers (375.66-2~deb9u1) stretch; urgency=medium
* Rebuild for stretch.
diff -Nru --exclude '*.run' nvidia-graphics-drivers-375.66/debian/detect/nvidia-detect.in nvidia-graphics-drivers-375.82/debian/detect/nvidia-detect.in
--- nvidia-graphics-drivers-375.66/debian/detect/nvidia-detect.in 2017-07-16 13:35:22.0 +0100
+++ nvidia-graphics-drivers-375.82/debian/detect/nvidia-detect.in 2017-07-26 20:22:43.0 +0100
@@ -139,7 +139,7 @@
else
echo "Oops. Internal error 8 ($NVGA)"
fi
- elif grep -q "stretch\|^9\|buster\|^10" /etc/debian_version
+ elif grep -q "stretch\|^9" /etc/debian_version
then
if [[ -n ${VERSIONS[999]} ]]; then
if [[ -n ${VERSIONS[340]} ]]; then
@
Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1
Control: tags -1 - moreinfo On Sun, 2017-07-30 at 23:04 +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2017-07-26 at 22:51 +0100, Luca Boccassi wrote: > > The non-free proprietary nvidia-graphics-drivers version 375.66 in > > Stretch is affected by CVE-2017-6257 and CVE-2017-6259. Debian bug: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869783 > > > > Please consider allowing the new upstream version 375.82, which > > fixes > > these CVEs, in proposed-updates. As usual with these proprietary > > drivers, we cannot just cherry-pick the fixes for the CVEs as they > > are > > in the binary blobs. > > > > I have tested this new version on a Stretch amd64 desktop and > > didn't > > encounter any issue. > > > > The debdiff from 375.66-2~deb9u1 to 375.82-1 is attached. > > While I'm sure it's probably fine, could we have a diff of the > proposed > 375.82-1~deb9u1, as built and tested on stretch, please? > > Regards, > > Adam Hi Adam, There were no changes when I opened the bug apart from the new changelog entry. Andreas has since committed 2 small fixes to the changelog as well, inlined, just minor clarifications. I still find the way upstream compiles their changelog quite confusing and often make mistakes when copying over :-) Kind regards, Luca Boccassi @@ -1,14 +1,18 @@ +nvidia-graphics-drivers (375.82-1~deb9u1) stretch; urgency=medium + + * Rebuild for stretch. + + -- Luca Boccassi Sun, 30 Jul 2017 23:09:12 +0100 + nvidia-graphics-drivers (375.82-1) unstable; urgency=high * New upstream long lived branch release 375.82 (2017-07-24). * Fixed CVE-2017-6257, CVE-2017-6259. (Closes: #869783) -- Fix a bug with GLX_EXT_buffer_age where incorrect buffer age values would - be reported for SLI AFR configurations. In such configurations buffer age - may now be greater than 3, the previous maximum buffer age. +- Fix a bug with GLX_EXT_buffer_age where incorrect buffer age values + would be reported for SLI AFR configurations. In such configurations + buffer age may now be greater than 3, the previous maximum buffer age. - Fixed a bug that could cause hanging and Xids when performing RandR transforms with Overlay and SLI enabled. -- Improved handling of framebuffer console restore on systems booted in - UEFI mode. - Extended the information reported by the NVIDIA Xinerama X extension to report PRIME displays in addition to directly-connected displays. - Fixed a bug that caused HDMI audio devices to appear or disappear @@ -15,17 +19,13 @@ inconsistently when HDMI devices were hotplugged or unplugged. - Fixed a bug that could cause driver errors when setting modes on X screens running at Depth 8 or Depth 15. +- Added support for the following GPUs: GeForce GTX 1080 with Max-Q + Design, GeForce GTX 1070 with Max-Q Design, + GeForce GTX 1060 with Max-Q Design. - Fixed a bug that could cause intermittent kernel panics when running with PRIME Sync. -- Fixed a bug that caused a kernel panic when hotplugging HDMI displays on - some Zotac mini PCs. -- Updated nvidia-installer to label kernel modules with SELinux file type - 'modules_object_t'. Some system SELinux policies only permit loading of - kernel modules with this SELinux file type. -- Removed support for checking for and downloading updated driver packages - and precompiled kernel interfaces from nvidia-installer. This - functionality was limited to unencrypted ftp and http, and was - implemented using code that is no longer actively maintained. +- Fixed a bug that caused a kernel panic when hotplugging HDMI displays + on some Zotac mini PCs. [ Andreas Beckmann ] * nvidia-kernel-dkms: Honor parallel setting from dkms. (Closes: #864639) @@ -33,7 +33,7 @@ * Switch watch URL from ftp:// to https://. (Closes: #868815) [ Luca Boccassi ] - * Add support for buster/sid in nvidia-detect. (Closes: #866126) + * Add support for buster in nvidia-detect. (Closes: #866126) * Update symbols files. -- Luca Boccassi Wed, 26 Jul 2017 21:42:00 +0100 signature.asc Description: This is a digitally signed message part
Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1
On Sun, 2017-07-30 at 23:19 +0100, Luca Boccassi wrote: > Control: tags -1 - moreinfo > > On Sun, 2017-07-30 at 23:04 +0100, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Wed, 2017-07-26 at 22:51 +0100, Luca Boccassi wrote: > > > The non-free proprietary nvidia-graphics-drivers version 375.66 > > > in > > > Stretch is affected by CVE-2017-6257 and CVE-2017-6259. Debian > > > bug: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869783 > > > > > > Please consider allowing the new upstream version 375.82, which > > > fixes > > > these CVEs, in proposed-updates. As usual with these proprietary > > > drivers, we cannot just cherry-pick the fixes for the CVEs as > > > they > > > are > > > in the binary blobs. > > > > > > I have tested this new version on a Stretch amd64 desktop and > > > didn't > > > encounter any issue. > > > > > > The debdiff from 375.66-2~deb9u1 to 375.82-1 is attached. > > > > While I'm sure it's probably fine, could we have a diff of the > > proposed > > 375.82-1~deb9u1, as built and tested on stretch, please? > > > > Regards, > > > > Adam > > Hi Adam, > > There were no changes when I opened the bug apart from the new > changelog entry. > > Andreas has since committed 2 small fixes to the changelog as well, > inlined, just minor clarifications. I still find the way upstream > compiles their changelog quite confusing and often make mistakes when > copying over :-) > > Kind regards, > Luca Boccassi To further clarify, the debdiff I attached originally is the one from the source I built and tested on Stretch. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1
On Sun, 2017-07-30 at 23:44 +0100, Adam D. Barratt wrote: > On Sun, 2017-07-30 at 23:23 +0100, Luca Boccassi wrote: > > On Sun, 2017-07-30 at 23:19 +0100, Luca Boccassi wrote: > > > Control: tags -1 - moreinfo > > > > > > On Sun, 2017-07-30 at 23:04 +0100, Adam D. Barratt wrote: > > > > Control: tags -1 + moreinfo > > > > > > > > On Wed, 2017-07-26 at 22:51 +0100, Luca Boccassi wrote: > > > > > The non-free proprietary nvidia-graphics-drivers version > > > > > 375.66 > > > > > in > > > > > Stretch is affected by CVE-2017-6257 and CVE-2017-6259. > > > > > Debian > > > > > bug: > > > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869783 > > > > > > > > > > Please consider allowing the new upstream version 375.82, > > > > > which > > > > > fixes > > > > > these CVEs, in proposed-updates. As usual with these > > > > > proprietary > > > > > drivers, we cannot just cherry-pick the fixes for the CVEs as > > > > > they > > > > > are > > > > > in the binary blobs. > > > > > > > > > > I have tested this new version on a Stretch amd64 desktop and > > > > > didn't > > > > > encounter any issue. > > > > > > > > > > The debdiff from 375.66-2~deb9u1 to 375.82-1 is attached. > > > > > > > > While I'm sure it's probably fine, could we have a diff of the > > > > proposed > > > > 375.82-1~deb9u1, as built and tested on stretch, please? > > [...] > > > There were no changes when I opened the bug apart from the new > > > changelog entry. > > > > > > Andreas has since committed 2 small fixes to the changelog as > > > well, > > > inlined, just minor clarifications. I still find the way upstream > > > compiles their changelog quite confusing and often make mistakes > > > when > > > copying over :-) > > > > > > Kind regards, > > > Luca Boccassi > > > > To further clarify, the debdiff I attached originally is the one > > from > > the source I built and tested on Stretch. > > That's rather confusing, given that it had the changelog set to > "unstable"... > > Regards, > > Adam It was confusing, sorry about that. It was a local build from SVN on my Stretch machine to test it, so I hadn't updated the changelog with the stable entry yet. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#884695: transition: dpdk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, We would like to move the new DPDK LTS release 17.11-2 from experimental to unstable. This breaks the various libraries ABI compat, so a transition is needed. https://tracker.debian.org/pkg/dpdk Reverse build dependency source package: collectd The reverse dependency builds fine with the new version of DPDK without any source changes. Note that it currently FTBS due to a different and unrelated build-dep [1]. Tested by disabling that other plugin and rebuilding with the new DPDK version. The new DPDK packages are all in experimental, having passed the NEW queue, and have built on all supported architectures. Note that from this release we started to follow a boost-like model, so the ABI revision is named after the upstream major version (eg: librte- eal3 -> librte-eal17.11). This is done because most libraries built from DPDK break ABI compat on every single major release. Thanks! -- Kind regards, Luca Boccassi [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881641 signature.asc Description: This is a digitally signed message part
Bug#884695: transition: dpdk
On Mon, 2017-12-18 at 19:33 +0100, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 18/12/17 13:16, Luca Boccassi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > We would like to move the new DPDK LTS release 17.11-2 from > > experimental to unstable. This breaks the various libraries ABI > > compat, > > so a transition is needed. > > > > https://tracker.debian.org/pkg/dpdk > > > > Reverse build dependency source package: > > > > collectd > > > > The reverse dependency builds fine with the new version of DPDK > > without > > any source changes. Note that it currently FTBS due to a different > > and > > unrelated build-dep [1]. Tested by disabling that other plugin and > > rebuilding with the new DPDK version. > > > > The new DPDK packages are all in experimental, having passed the > > NEW > > queue, and have built on all supported architectures. > > > > Note that from this release we started to follow a boost-like > > model, so > > the ABI revision is named after the upstream major version (eg: > > librte- > > eal3 -> librte-eal17.11). This is done because most libraries built > > from DPDK break ABI compat on every single major release. > > There are no rdeps so no transition tracker... Since you confirm the > only > build-rdep is fine, please go ahead. > > Emilio Ah I see, I though reverse-recommends needed a transition as well. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#884695: transition: dpdk
On Mon, 2017-12-18 at 18:42 +, Luca Boccassi wrote: > On Mon, 2017-12-18 at 19:33 +0100, Emilio Pozuelo Monfort wrote: > > Control: tags -1 confirmed > > > > On 18/12/17 13:16, Luca Boccassi wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Dear release team, > > > > > > We would like to move the new DPDK LTS release 17.11-2 from > > > experimental to unstable. This breaks the various libraries ABI > > > compat, > > > so a transition is needed. > > > > > > https://tracker.debian.org/pkg/dpdk > > > > > > Reverse build dependency source package: > > > > > > collectd > > > > > > The reverse dependency builds fine with the new version of DPDK > > > without > > > any source changes. Note that it currently FTBS due to a > > > different > > > and > > > unrelated build-dep [1]. Tested by disabling that other plugin > > > and > > > rebuilding with the new DPDK version. > > > > > > The new DPDK packages are all in experimental, having passed the > > > NEW > > > queue, and have built on all supported architectures. > > > > > > Note that from this release we started to follow a boost-like > > > model, so > > > the ABI revision is named after the upstream major version (eg: > > > librte- > > > eal3 -> librte-eal17.11). This is done because most libraries > > > built > > > from DPDK break ABI compat on every single major release. > > > > There are no rdeps so no transition tracker... Since you confirm > > the > > only > > build-rdep is fine, please go ahead. > > > > Emilio > > Ah I see, I though reverse-recommends needed a transition as well. > Thanks! The upload to unstable is done. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#884711: stretch-pu: package dpdk/16.11.4-1+deb9u1
On Sat, 2018-02-10 at 09:47 +0100, Julien Cristau wrote: > Control: tags -1 confirmed > > On Sun, Jan 14, 2018 at 20:14:14 +0000, Luca Boccassi wrote: > > > Thank you for the review, I have reworked the debdiff - rather than > > taking the last 16.11.x version we uploaded in Sid and reverting a > > few > > changes, instead I've taken the version in Stretch and merged the > > LTS > > point releases and a couple of small changes, details below. > > > > Great, thanks. Go ahead and upload to stretch. > > Cheers, > Julien Done, thanks. There will be one LTS bugfix release every 3 months until at least November. I think there is no whitelisting system like Ubuntu has, and so I will need to create a release.debian.org bug each time, right? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900111: transition: xorg-server 1.20
On Sat, 2018-05-26 at 11:33 +0200, Emilio Pozuelo Monfort wrote: > Package: release.debian.org > Severity: normal > Tags: confirmed > User: release.debian@packages.debian.org > Usertags: transition > Control: forwarded -1 https://release.debian.org/transitions/html/xse > rver1.20.html > > Hi, > > I started the transition to xserver 1.20 as there were no conflicts > and > it was looking good. > > Andreas, the nvidia drivers need an update for the new video driver > ABI. Can > you take a look? > > Thanks, > Emilio Hi, I'll push nvidia-driver 390.59, which supports 1.20, shortly. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900111: transition: xorg-server 1.20
On Sun, 2018-05-27 at 09:38 +0200, Emilio Pozuelo Monfort wrote: > On 26/05/18 20:05, Luca Boccassi wrote: > > On Sat, 2018-05-26 at 11:33 +0200, Emilio Pozuelo Monfort wrote: > > > Package: release.debian.org > > > Severity: normal > > > Tags: confirmed > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > Control: forwarded -1 https://release.debian.org/transitions/html > > > /xse > > > rver1.20.html > > > > > > Hi, > > > > > > I started the transition to xserver 1.20 as there were no > > > conflicts > > > and > > > it was looking good. > > > > > > Andreas, the nvidia drivers need an update for the new video > > > driver > > > ABI. Can > > > you take a look? > > > > > > Thanks, > > > Emilio > > > > Hi, > > > > I'll push nvidia-driver 390.59, which supports 1.20, shortly. > > Thanks. Any updates planned for the legacy drivers? > > Emilio The 304xx series is dead&buried so I assume Nvidia won't update it anymore. 340xx in theory should still be supported, but nothing is out as of today. IIRC in the past they have updated Xorg ABI compat in legacy releases, so I'd expect it to happen soon enough. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#803410: jessie-pu: package libvdpau/0.8-3+deb8u2
On Fri, 2015-10-30 at 14:32 +0100, Alessandro Ghedini wrote: > On Thu, Oct 29, 2015 at 07:52:23pm +, luca wrote: > > Package: release.debian.org > > Severity: normal > > Tags: jessie > > User: release.debian@packages.debian.org > > Usertags: pu > > > > Dear release team, > > > > We would like to update libvdpau in jessie to address a segmentation fault > > in a > > particular use case. > > > > 0.8-3+deb8u1 was uploaded through jessie-security with an upstream fix for 3 > > security bugs: CVE-2015-5198 CVE-2015-5199 CVE-2015-5200 (see > > https://bugs.debian.org/797895). > > > > The upstream patch unfortunately introduced a regression when running with > > DRI_PRIME=1, as reported by a user in https://bugs.debian.org/802625 and > > upstream has committed a fix for it. > > > > We already uploaded a fixed version to unstable, and now we would like to > > backport it to jessie as well. The debdiff follows. I have verified that it > > fixes the problem on a vanilla jessie amd64 installation. > > > > Thank you! > > > > Kind regards, > > Luca Boccassi > > > > > > diff -Nru libvdpau-0.8/debian/changelog libvdpau-0.8/debian/changelog > > --- libvdpau-0.8/debian/changelog 2015-09-05 13:14:50.0 +0100 > > +++ libvdpau-0.8/debian/changelog 2015-10-29 19:30:28.0 + > > @@ -1,3 +1,10 @@ > > +libvdpau (0.8-3+deb8u2) jessie; urgency=medium > > The diff looks good, could you change the target to jessie-security and upload > to security-master? Committed in git, but I'll have to ask Andreas to upload as I lack the supercow powers :-) Andreas, the new version is tested and ready in the jessie branch in git [1], could you please upload to security-master when you have time? Thanks! > Also, do you plan to prepare an update for wheezy-security as well? I'll have access to a wheezy guinea pig machine on Monday, so if the regression is present there as well I'll test a patched version and reply back here. Kind regards, Luca Boccassi [1] https://anonscm.debian.org/cgit/pkg-nvidia/libvdpau.git/log/?h=jessie signature.asc Description: This is a digitally signed message part
Re: dash: remove unnecessary diversion of /bin/sh
On Wed, 9 Jun 2021 12:18:58 +0200 Helmut Grohne
wrote:
> > Upshot: the proposal below doesn't bring us closer to that ideal,
> but
> > it doesn't bring us further away either. And I like the idea of
> > making the default configuration simpler.
>
> \o/
>
> > Summary: I like what this patch aims to do; I think it needs some
> tweaking to
> > be easier to read but then it should be good to apply.
>
> Updated patch attached.
I've rebased the patch, including the change currently in the
debian/experimental branch to drop the ash diversion upgrade path, and
done the following testing in a bookworm amd64 chroot:
Without sh -> bash diversion:
upgrade dash bookworm -> dash patched
upgrade dash bullseye -> dash bookworm -> dash patched
upgrade dash bullseye -> dash patched
downgrade dash patched -> dash bookworm
downgrade dash patched -> dash bullseye
Then, downgrade dash to bullseye, install sh -> bash diversion via
debconf ('echo "dash dash/sh boolean false" | debconf-set-selections'
and then 'dpkg-reconfigure dash'), then repeated the set above.
In all upgrade cases we end up with no diversions configured and sh ->
dash. In the downgrade to bullseye case without setting debconf we go
back to having the diversion in place.
In the downgrade from patched to bullseye case with debconf set to
false there is no diversion in place, but from current bookworm to
bullseye the bash diversion is restored - is this something that needs
to be fixed? Changing debconf back to 'true' and doing a reconfigure
readds it already as things stand. Do we care about this use case?
Given bash as /bin/sh is really not supported anymore, I tend to think
that we don't and it's fine as-is.
MR: https://salsa.debian.org/debian/dash/-/merge_requests/19
I think we should ship these changes in bookworm. Why?
- we get diversion-less essential package set already in bookworm
- we get diversion-less uber-essential dash already in bookworm
- we get maintainer-script free uber-essential dash in trixie
- in case we need to go down the canonicalization-by-dh forced
migration path in trixie to lift the moratorium on moving files, we
don't have /bin/sh diversions as a blocker and the path remains open
Yes, I realize it is late, and I wish I had come across this ticket
some months ago. But we still have time, and the benefits are great :-)
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1035304: bullseye-pu: package systemd/247.3-7+deb11u3
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org Dear release team, I have uploaded two new bugfixes for systemd in bullseye. One fixes a regression introduced by a security fix in udev rules, that has been reported by a bullseye user. The other fixes an old memory leak. The source debdiff is attached. Kind regards, Luca Boccassi debdiff Description: Binary data
Re: dash: remove unnecessary diversion of /bin/sh
On Sat, 29 Apr 2023 16:32:23 +0100 Luca Boccassi wrote: > > MR: https://salsa.debian.org/debian/dash/-/merge_requests/19 > > I think we should ship these changes in bookworm. Why? > > - we get diversion-less essential package set already in bookworm > - we get diversion-less uber-essential dash already in bookworm > - we get maintainer-script free uber-essential dash in trixie > - in case we need to go down the canonicalization-by-dh forced > migration path in trixie to lift the moratorium on moving files, we > don't have /bin/sh diversions as a blocker and the path remains open > > Yes, I realize it is late, and I wish I had come across this ticket > some months ago. But we still have time, and the benefits are great :-) Alright, this is now in experimental (thanks Andrej), please help with testing if you can! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: dash: remove unnecessary diversion of /bin/sh
On Mon, 1 May 2023 at 08:55, Helmut Grohne wrote: > > Hi, > > On Mon, May 01, 2023 at 12:07:52AM +0100, Luca Boccassi wrote: > > On Sat, 29 Apr 2023 16:32:23 +0100 Luca Boccassi > > wrote: > > > > > > MR: https://salsa.debian.org/debian/dash/-/merge_requests/19 > > > > > > I think we should ship these changes in bookworm. Why? > > > > > > - we get diversion-less essential package set already in bookworm > > > - we get diversion-less uber-essential dash already in bookworm > > > - we get maintainer-script free uber-essential dash in trixie > > > - in case we need to go down the canonicalization-by-dh forced > > > migration path in trixie to lift the moratorium on moving files, we > > > don't have /bin/sh diversions as a blocker and the path remains open > > > > > > Yes, I realize it is late, and I wish I had come across this ticket > > > some months ago. But we still have time, and the benefits are great > > :-) > > > > Alright, this is now in experimental (thanks Andrej), please help with > > testing if you can! > > Let me record this in email: > * I am the primary author of these changes and still think we should >perform them at a convenient time. > * As far as I understand it, the main motivation from Luca is improving >the /usr-merge transition. > * Given that dash is one of the rare cases diverting files from itself >rather than from other packages, I think that the benefit to the >/usr-merge transition of doing this before bookworm is minor. >Removing other kinds of unnecessary diversions would be more useful >to the transition. > * I think these changes are not in line with the freeze policy. > * For these reasons, I recommend not trying to ship them in bookworm >(despite removing unnecessary diversions being a good thing in >general). > * Breakage can happen in unexpected places (e.g. DPKG_ROOT, which is >the origin of my work on this). > * If you proceed in bookworm anyway, I expect you to own any kind of >breakage that results from this (including DPKG_ROOT breakage). > > And with this, I'll leave it up to you until bookworm is released. Actually my main motivation is that diversions in /usr are fundamentally incompatible with the concept of a read-only /usr vendor partition. As far as I can tell this is the only diversion that is installed by default in the essential set, so I am very very keen on seeing it gone. Having this change in bookworm means in trixie we can be rid of it completely, and otherwise we'd have to wait yet another full cycle. The fact that it also helps with the merge transition is really icing on the cake. Yes, I wish I had noticed and had time for this earlier, but if wishes were horses etc etc. To me it seems a fairly straightforward change, and it is in experimental now for us to prove it otherwise, so I'd be really keen in getting an unblock for bookworm for this. And yes I'm happy to help if anything goes awry. Kind regards, Luca Boccassi
Bug#1035745: unblock: dash/0.5.12-4 (preapproval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-debbugs-CC: andrew.shad...@collabora.co.uk
Dear Release Team,
Filing this on request of the dash maintainer. We have recently
implemented a much needed cleanup that removes an unnecessary diversion
on /bin/sh, that makes the essential set nice and clean and diversion-
free, so that it can be set up without complex machinery.
This cleanup has been uploaded last week to experimental with
dash/0.5.12-3. We have tested it and cannot see any issues with it. The
autopkgtest has been enhanced to cover the case, and a new job testing
the downgrade/upgrade paths has been added to Salsa CI.
Given it simplifies an essential package, it is my opinion that it
would be beneficial to ship this in Bookworm, hence we are filing this
book to gather your feedback.
There is one ulterior advantage: in case we decide to finish the
usrmerge transition in Trixie via diverts, this is a necessary fix for
that to work, so having this in place already in Bookworm would make
things easier on that too, in case we go down that path. [1]
dash ticket: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989632
Debdiff from current bookworm to the version in experimental attached.
Note that 0.5.12-4 does not exist yet as this is a pre-approval
request, but it would be a changelog-only upload. The only changes in
the debdiff are in the maintainer scripts to drop the diversion, and in
the added autopkgtest to cover it.
[1] https://lists.debian.org/debian-devel/2023/04/msg8.html
--
Kind regards,
Luca Boccassi
diff -Nru dash-0.5.12/debian/changelog dash-0.5.12/debian/changelog
--- dash-0.5.12/debian/changelog 2023-01-05 13:20:48.0 +
+++ dash-0.5.12/debian/changelog 2023-04-30 14:53:24.0 +0100
@@ -1,3 +1,19 @@
+dash (0.5.12-3) experimental; urgency=medium
+
+ [ Andrej Shadura ]
+ * Fix bug number in the patch description
+
+ [ Helmut Grohne ]
+ * dash.postinst: Remove upgrade path from pre-sarge ash. (Closes:
+#989419)
+ * Remove unnecessary diversion in case /bin/sh points to dash. (Closes:
+#989632)
+
+ [ Luca Boccassi ]
+ * dash.postinst: remove unused function
+
+ -- Andrej Shadura Sun, 30 Apr 2023 15:53:24 +0200
+
dash (0.5.12-2) unstable; urgency=medium
* Fix the changelog entry.
diff -Nru dash-0.5.12/debian/dash.postinst dash-0.5.12/debian/dash.postinst
--- dash-0.5.12/debian/dash.postinst 2023-01-05 13:20:48.0 +
+++ dash-0.5.12/debian/dash.postinst 2023-04-30 14:53:24.0 +0100
@@ -33,7 +33,7 @@
diverter=$(dpkg-divert --listpackage $dfile)
truename=$(dpkg-divert --truename $dfile)
- if [ "$diverter" = dash ]; then
+ if [ -z "$diverter" ]; then
# good.
return
fi
@@ -43,9 +43,9 @@
return
fi
- if [ -n "$diverter" ] && [ "$diverter" != bash ]; then
- # Let dpkg-divert error out; we are not taking
- # over the diversion, unless we added it
+ if [ "$diverter" != bash ]; then
+ # Let dpkg-divert error out; we are not removing the
+ # diversion, unless we added it
# ourselves on behalf of bash.
dpkg-divert --package dash --no-rename --remove $dfile
echo "This should never be reached"
@@ -53,7 +53,6 @@
fi
dpkg-divert --package bash --no-rename --remove $dfile
- dpkg-divert --package dash --no-rename --divert $distrib --add $dfile
# remove the old equivalent of $distrib, if it existed.
if [ -n "$DPKG_ROOT$truename" ]; then
rm -f "$DPKG_ROOT$truename"
@@ -61,62 +60,23 @@
replace_with_link $dfile $ltarget $distrib
}
-unclaim_binsh() {
+drop_obsolete_diversion() {
dfile=$1 ltarget=$2 distrib=${3:-$dfile.distrib}
- diverter=$(dpkg-divert --listpackage $dfile)
- truename=$(dpkg-divert --truename $dfile)
+ diverter=$(dpkg-divert --listpackage "$dfile")
+ truename=$(dpkg-divert --truename "$dfile")
+ actualtarget=$(readlink "$dfile")
- if [ "$diverter" != dash ]; then
- # good.
+ if [ "$diverter" != dash ] || [ "$truename" != "$distrib" ] || [ "$actualtarget" != "$ltarget" ]; then
+ # Not our diversion or a non-trivial one.
return
fi
-
- # Donate the diversion and sh symlink to the bash package.
- ltarget=$(echo $ltarget | sed s/dash/bash/)
- dpkg-divert --package dash --no-rename --remove $dfile
- dpkg-divert --package bash --no-rename --divert $distrib --add $dfile
- if [ -n "$truename" ]; then
- rm -f "$truename"
- fi
- replace_with_link $dfile $ltarget $distrib
-}
-
-initial_binsh_setup() {
- dfile=$1 ltarget=$2 distrib=${3:-$dfile.distrib} ashfile=$4
- diverter=$(dpkg-divert --listpackage $dfile)
- truename=$(dpkg-divert --truename $dfile)
-
- if [ -z "$diverter" ]; then
- # good.
- return
- fi
-
- if [ "$diverter" = ash ]; then
- dpkg-divert --package ash --no-rename --remove
Bug#1035745: unblock: dash/0.5.12-4 (preapproval)
On Fri, 12 May 2023 at 06:01, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > On Mon, 08 May 2023 16:54:32 +0100 Luca Boccassi wrote: > > This cleanup has been uploaded last week to experimental with dash/0.5.12-3. > > We have tested it and cannot see any issues with it. > > dash in experimental breaks the autopkgtest of mmdebstrap. I've fixed these > problems already and uploaded the fixed version of mmdebstrap to unstable. > > I can also confirm that dash in experimental does not break my work on > chrootless bootstrap. > > I will file the unblock request for mmdebstrap as soon as the breakages with > the recent doc-debian upload are resolved. Good find, thanks! Kind regards, Luca Boccassi
Bug#1036014: unblock: amazon-ec2-utils/2.0.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-cl...@lists.debian.org Dear Release Team, As one of the owners of udev, and having an agreement with the maintainer of amazon-ec2-utils, I'd like the following bug fixed in Bookworm: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035667 amazon-ec2-utils used to take over a file from udev, and this has been fixed in the latest upload to unstable. For maintainability and supportability reasons, we the systemd/udev maintainers prefer that files from the udev package are not diverted. This is the only such case distro-wide. The change is very straightforward and restricted to the maintainer scripts and the install file. Debdiff attached. Thank you! -- Kind regards, Luca Boccassi diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install --- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install 2022-12-23 22:15:25.0 + +++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install 2023-05-13 01:11:47.0 +0100 @@ -1,4 +1,4 @@ ebsnvme-id /usr/sbin/ ec2-metadata /usr/bin/ ec2nvme-nsid /lib/udev/ -60-cdrom_id.rules 70-ec2-nvme-devices.rules /lib/udev/rules.d/ +70-ec2-nvme-devices.rules /lib/udev/rules.d/ diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst --- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst 1970-01-01 01:00:00.0 +0100 +++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst 2023-05-13 01:11:47.0 +0100 @@ -0,0 +1,15 @@ +#!/bin/sh + +set -e + +if [ "configure" = "$1" ]; then + # TODO: can be dropped in Trixie + diverter=$(dpkg-divert --listpackage /lib/udev/rules.d/60-cdrom_id.rules) + if [ "$diverter" = "amazon-ec2-utils" ]; then + dpkg-divert --package amazon-ec2-utils --remove --rename \ + --divert /lib/udev/rules.d/60-cdrom_id.rules.disabled \ + /lib/udev/rules.d/60-cdrom_id.rules + fi +fi + +#DEBHELPER# diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm --- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm 2022-12-23 22:01:44.0 + +++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm 1970-01-01 01:00:00.0 +0100 @@ -1,11 +0,0 @@ -#!/bin/sh - -set -e - -if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then - dpkg-divert --package amazon-ec2-utils --remove --rename \ - --divert /lib/udev/rules.d/60-cdrom_id.rules.disabled \ - /lib/udev/rules.d/60-cdrom_id.rules -fi - -#DEBHELPER# diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst --- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst 2022-12-23 22:01:44.0 + +++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst 1970-01-01 01:00:00.0 +0100 @@ -1,9 +0,0 @@ -#!/bin/sh - -set -e - -dpkg-divert --package amazon-ec2-utils --add --rename \ - --divert /lib/udev/rules.d/60-cdrom_id.rules.disabled \ - /lib/udev/rules.d/60-cdrom_id.rules - -#DEBHELPER# diff -Nru amazon-ec2-utils-2.0.1/debian/changelog amazon-ec2-utils-2.0.1/debian/changelog --- amazon-ec2-utils-2.0.1/debian/changelog 2022-12-23 22:17:54.0 + +++ amazon-ec2-utils-2.0.1/debian/changelog 2023-05-13 01:11:47.0 +0100 @@ -1,3 +1,10 @@ +amazon-ec2-utils (2.0.1-2) unstable; urgency=medium + + [ Luca Boccassi ] + * Remove diversion of udev rule 60-cdrom_id.rules (Closes: #1035667) + + -- Noah Meyerhans Fri, 12 May 2023 17:11:47 -0700 + amazon-ec2-utils (2.0.1-1) unstable; urgency=medium * New upstream release signature.asc Description: This is a digitally signed message part
Bug#1036354: unblock: iptables-persistent/1.0.20
On Fri, 19 May 2023, 15:39 gustavo panizzo, wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: bl...@debian.org > > Please unblock package iptables-persistent > > (Please provide enough (but not too much) information to help > the release team to judge the request efficiently. E.g. by > filling in the sections below.) > > [ Reason ] > The package is using alternatives to manage (systemd) aliases, > this is not recommended by the systemd maintainers. > > See bug report #1036147 > > > I've added alternatives to this package back in 2019 to solve #926927 > as a point of coordination with other firewall managers in Debian > (see https://lists.debian.org/debian-firewall/2019/08/msg0.html) but > the initiative never took off > > > [ Impact ] > This is (was) the only package in Debian which uses alternatives to > manage aliases, which makes it different from what admins expect > > [ Tests ] > This version of the package is clean in lintian and piuparts, > I've upgraded my systems and found no problems > > > [ Risks ] > I see no risks, if an admin locally have changed the override files, > we'll keep them as dpkg-bak > > > [ Checklist ] > [x] all changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in testing > > > unblock iptables-persistent/1.0.20 > Thanks for taking care of this - I just checked and cannot see the upload to unstable though? Kind regards, Luca Boccassi >
Bug#1036354: unblock: iptables-persistent/1.0.20
On Sat, 20 May 2023 at 11:29, gustavo panizzo wrote: > > Hi > > On May 20, 2023 10:20:50 AM UTC, Luca Boccassi wrote: > >On Fri, 19 May 2023, 15:39 gustavo panizzo, wrote: > > > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: unblock > >> X-Debbugs-Cc: bl...@debian.org > >> > >> Please unblock package iptables-persistent > >> > >> (Please provide enough (but not too much) information to help > >> the release team to judge the request efficiently. E.g. by > >> filling in the sections below.) > >> > >> [ Reason ] > >> The package is using alternatives to manage (systemd) aliases, > >> this is not recommended by the systemd maintainers. > >> > >> See bug report #1036147 > >> > >> > >> I've added alternatives to this package back in 2019 to solve #926927 > >> as a point of coordination with other firewall managers in Debian > >> (see https://lists.debian.org/debian-firewall/2019/08/msg0.html) but > >> the initiative never took off > >> > >> > >> [ Impact ] > >> This is (was) the only package in Debian which uses alternatives to > >> manage aliases, which makes it different from what admins expect > >> > >> [ Tests ] > >> This version of the package is clean in lintian and piuparts, > >> I've upgraded my systems and found no problems > >> > >> > >> [ Risks ] > >> I see no risks, if an admin locally have changed the override files, > >> we'll keep them as dpkg-bak > >> > >> > >> [ Checklist ] > >> [x] all changes are documented in the d/changelog > >> [x] I reviewed all changes and I approve them > >> [x] attach debdiff against the package in testing > >> > >> > >> unblock iptables-persistent/1.0.20 > >> > > > >Thanks for taking care of this - I just checked and cannot see the upload > >to unstable though? > > I'd prefer to wait for an ack from the release team Ok, in that case I think it should be explicitly mentioned that this is a 'preapproval' request. Kind regards, Luca Boccassi
Bug#1035710: unblock: doc-debian/11.3
Control: tags -1 confirmed On Sat, 20 May 2023 16:21:47 +0200 Sebastian Ramacher wrote: > Control: tags -1 moreinfo cofnirmed > > On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote: > > reopen 1035710 > > retitle 1035710 unblock: doc-debian/11.3 > > thanks > > > > Please unblock package doc-debian > > > > [ Reason ] > > The doc-debian package claims to ship the Constitution for the Debian Project, > > the Debian Social Contract and other Debian documents. The versions of those > > documents are obsolete [obsolete], which makes the package as now in testing > > very buggy. > > > > [ Impact ] > > Shipping obsolete foundational documents is misleading and therefore might > > lead to confusion. > > > > [ Tests ] > > None. (The package ships documentation only, no code is shipped in the > > binary package.) > > > > [ Risks ] > > None. The doc-debian package is a key package due to Priority: standard. It > > acts as a leaf package: Its only true reverse depends is the live- task-standard > > package.[reverse-depends] In bug #1035913 however, it was shown that some > > autopkgtests failed with the new doc-debian due to changes in build > > environment. This issue now has been properly documented. > > > > [ Checklist ] > > [x] all changes are documented in the d/changelog > > [x] I reviewed all changes and I approve them > > [x] attach debdiff against the package in testing > > > > [ Other info ] I made a mistake uploading doc-debian 11.0 to unstable; that got > > accepted. The version 11.3 is now available from experimental. I've kept the > > diff minimal. Earlier planned and implemented non-related fixes will, via > > experimental and unstable, end up in 13/trixie. > > > > unblock doc-debian/11.3 > > Please go ahead with the upload to unstable. Remove the moreinfo tag > once the package is available. Typo in the control string, fixed it for you -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
Control: tags -1 -moreinfo On Sat, 20 May 2023 13:54:14 +0200 Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Sebastian Ramacher (2023-05-20 13:38:20) > > > some of the packages uploaded to unstable or experimental are breaking the > > > mmdebstrap autopkgtest: > > > > > > - doc-debian rebuilt with debhelper (>= 13.4) changes the doc- base paths. This > > > is recorded as #1035913 and the change is intentional. Thus the mmdebstrap > > > autopkgtest has to be adjusted. The unblock bug for doc-debian was #1035710. > > > - dash has an upload in experimental which removes its diversions. See bug > > > #989632 for details. The unblock bug is #1035745. I also adjusted the > > > autopkgtest to cope with those changes. > > > - if it is decided for adduser to become Essential:yes or pseudo-essential > > > (instead of using Protected:yes) more changes are required. I didn't > > > implement those yet, because I'm still hoping that it will be decided to use > > > Protected:yes (in which case no changes are needed). Please consider > > > replying to my idea in #1035654 > > > > > > All of the needed changes only affect the autopkgtest. Nothing touches the > > > functionality shipped by the mmdebstrap binary package and thus, this unblock > > > cannot break anything (other than autopkgtest results). > > > > Could you please provide a debdiff of the proposed changes? > > this is the debdiff between mmdebstrap in testing and unstable: I think the rel team expects the moreinfo tag to be removed when the info is provided, so that they can sort out triaging, done that now. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036354: unblock: iptables-persistent/1.0.20
On Sat, 20 May 2023 13:23:09 + gustavo panizzo wrote: > How to do that? I hope is done now Yes, I believe it is enough to mention it in the thread. Gentle ping for the release team - would really like to have this merged for Bookworm, so that we don't have to maintain this setup for the duration of the release. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hello Release Team, If we were to do a MBF against packages that in _Bookworm_ have introduced new files in /bin, /sbin or /lib*, would you accept the consequent mass unblock request? I am asking beforehand as there's no point in going through the effort if you don't, the advantage is only if we can sort it before Bookworm ships, and the bugs would become invalid and be closed as soon as it does as per moratorium otherwise. By Helmut's count, there's around 178 such files to move. The project should probably have added this as a distro-wide rule as part of the moratorium, but that ship has sailed. Thanks! Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > Re: Luca Boccassi > > If we were to do a MBF against packages that in _Bookworm_ have > > introduced new files in /bin, /sbin or /lib*, would you accept the > > consequent mass unblock request? > > Fwiw, I would restrict that to packages that didn't have files in > these directories before. Telling a maintainer that they should > continue install foo.service to /lib/systemd, but the newly introduced > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > work and asking for bugs to happen. Yes, this (the number of files mentioned) already excludes things that are installed by dh addons and so, such as unit files. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote: > > On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > > > Re: Luca Boccassi > > > If we were to do a MBF against packages that in _Bookworm_ have > > > introduced new files in /bin, /sbin or /lib*, would you accept the > > > consequent mass unblock request? > > > > Fwiw, I would restrict that to packages that didn't have files in > > these directories before. Telling a maintainer that they should > > continue install foo.service to /lib/systemd, but the newly introduced > > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > > work and asking for bugs to happen. > > Yes, this (the number of files mentioned) already excludes things that > are installed by dh addons and so, such as unit files. Here's the list of affected packages for binaries: abpoa eprover coq-hierarchy-builder intel-cmt-cat nbd-server systemd toybox drbd-utils finit finit-plugins multipath-tools runit nut-modbus nut-i2c nut-server open-iscsi openrc resolvconf iproute2 f2fs-tools ifupdown-ng multipath-tools libpam-modules-bin PAM modules: cockpit-tests libpam-python libpam-alreadyloggedin libpam-chroot google-compute-engine-oslogin systemd-homed Library new ABI or minor versions: libbrlapi0.8 libc6 libcap2 libcgroup2 libdbus-1-3 libdmraid1.0.0.rc16 libcap-ng0 libexpat1 libfuse3-3 libgpg-error0 xfsprogs libreadline8 libkeyutils1 liblzma5 libncurses6 libncursesw6 libntfs-3g89 libnutclient2 libnutscan2 libparted-fs-resize0 libparted2 libproc2-0 libsepol2 libtinfo6 libupsclient6 zlib1g The libraries are just minor version increase in most cases, so the symlinks are often unchanged and cannot be moved, so I'd leave them where they are. So that's 23 packages for binaries and 5 for PAM modules moving from un-triplet to triplet location. Kind regards, Luca Boccassi
Bug#1036554: unblock: iproute2/6.1.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
A small regression w.r.t. Bookworm has just been reported on iproute2.
It is a trivial fix so I'd like to have it in the release if possible.
debdiff attached.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036534
Thanks!
--
Kind regards,
Luca Boccassi
diff -Nru iproute2-6.1.0/debian/changelog iproute2-6.1.0/debian/changelog
--- iproute2-6.1.0/debian/changelog 2023-02-25 19:46:35.0 +
+++ iproute2-6.1.0/debian/changelog 2023-05-22 14:19:52.0 +0100
@@ -1,3 +1,9 @@
+iproute2 (6.1.0-3) unstable; urgency=medium
+
+ * Ensure 'ip mo' resolves to 'ip monitor' (Closes: #1036534)
+
+ -- Luca Boccassi Mon, 22 May 2023 14:19:52 +0100
+
iproute2 (6.1.0-2) unstable; urgency=medium
* Add Romanian language translation for debconf (Closes: #1031917)
diff -Nru iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch
--- iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch 2023-02-25 19:04:02.0 +
+++ iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch 2023-05-22 14:19:19.0 +0100
@@ -3,7 +3,7 @@
Forwarded: no, critical value-add business feature for Debian
--- a/ip/ip.c
+++ b/ip/ip.c
-@@ -86,6 +86,19 @@
+@@ -87,6 +87,19 @@
return 0;
}
@@ -23,11 +23,11 @@
static const struct cmd {
const char *cmd;
int (*func)(int argc, char **argv);
-@@ -104,6 +117,7 @@
- { "fou", do_ipfou },
- { "ila", do_ipila },
- { "macsec", do_ipmacsec },
+@@ -125,6 +138,7 @@
+ { "ioam", do_ioam6 },
+ { "help", do_help },
+ { "stats", do_ipstats },
+ { "moo", do_moo },
- { "tunnel", do_iptunnel },
- { "tunl", do_iptunnel },
- { "tuntap", do_iptuntap },
+ { 0 }
+ };
+
signature.asc
Description: This is a digitally signed message part
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 20:22, Sam Hartman wrote: > > >>>>> "Luca" == Luca Boccassi writes: > > Luca> Hello Release Team, If we were to do a MBF against packages > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > Luca> /lib*, would you accept the consequent mass unblock request? > Luca> I am asking beforehand as there's no point in going through > Luca> the effort if you don't, the advantage is only if we can sort > Luca> it before Bookworm ships, and the bugs would become invalid > Luca> and be closed as soon as it does as per moratorium otherwise. > > This sounds like a really bad idea. > While technically this is consistent with the TC's advice, what you are > proposing to do increases the chance that you're going to trigger the > dpkg disappearing file bug. > > Consider: > > * User installs version from testing with file in /bin > * Maintainer quickly moves the file to /usr/bin per your MBF > * Bookworm releases; user does not upgrade at this point > * Package reorganization; file moves between packages > * User upgrades; file disappears What "package reorganization" would that be? Are you aware of any such thing happening in the next couple of weeks before release? > I suspect the reason you want to make this MBF is that you believe it > will somehow make the transition easier if there are fewer files in /bin > or /usr/bin. No, the main reason is that Helmut asked for this. And the ask makes sense: it's something that should have been part of the TC guidance, introducing new files in the wrong locations makes little sense. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 20:34, Sam Hartman wrote: > > >>>>> "Luca" == Luca Boccassi writes: > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman > wrote: > >> > >> >>>>> "Luca" == Luca Boccassi writes: > >> > Luca> Hello Release Team, If we were to do a MBF against packages > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > Luca> /lib*, would you accept the consequent mass unblock request? > Luca> I am asking beforehand as there's no point in going through > Luca> the effort if you don't, the advantage is only if we can sort > Luca> it before Bookworm ships, and the bugs would become invalid > Luca> and be closed as soon as it does as per moratorium otherwise. > >> > >> This sounds like a really bad idea. While technically this is > >> consistent with the TC's advice, what you are proposing to do > >> increases the chance that you're going to trigger the dpkg > >> disappearing file bug. > >> > >> Consider: > >> > >> * User installs version from testing with file in /bin * > >> Maintainer quickly moves the file to /usr/bin per your MBF * > >> Bookworm releases; user does not upgrade at this point * Package > >> reorganization; file moves between packages * User upgrades; file > >> disappears > > Luca> What "package reorganization" would that be? Are you aware of > Luca> any such thing happening in the next couple of weeks before > Luca> release? > > Who said anything about next couple of weeks. This affects testing and > unstable users *after the release*. It is my experience of Debian that > outside of freezes package reorganizations happen regularly. So what you are worried is the combination of a testing installation from~one year ago, that is otherwise never touched for say another year, and also that has one of those 23 packages installed in the old version, and also that same package of those 23 gets rearranged? That seems vanishingly unlikely, and I am not sure how supported it is to upgrade from "testing as bookworm" to "testing as trixie" without passing from bookworm stable, given we don't support skipping releases I'd have imagined that would not be supported either, but what do I know. Anyway, this is Helmut's request, so I'll leave the decision to him. > I think your plan is safe for stable users if we actually find a > solution to canonicalize paths during the next cycle. I do not think > your plan is safe for people who track testing, and for me there's not > enough benefit to justify breaking testing. Please stop saying "your plan", as I have already mentioned it was someone else's request: Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 22:13, Étienne Mollier wrote: > > Luca Boccassi, on 2023-05-22: > > On Mon, 22 May 2023 at 20:34, Sam Hartman wrote: > > > > > > >>>>> "Luca" == Luca Boccassi writes: > > > > > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman > > > wrote: > > > >> > > > >> >>>>> "Luca" == Luca Boccassi writes: > > > >> > > > Luca> Hello Release Team, If we were to do a MBF against packages > > > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > > > Luca> /lib*, would you accept the consequent mass unblock request? > > > Luca> I am asking beforehand as there's no point in going through > > > Luca> the effort if you don't, the advantage is only if we can sort > > > Luca> it before Bookworm ships, and the bugs would become invalid > > > Luca> and be closed as soon as it does as per moratorium otherwise. > > > >> > > > >> This sounds like a really bad idea. While technically this is > > > >> consistent with the TC's advice, what you are proposing to do > > > >> increases the chance that you're going to trigger the dpkg > > > >> disappearing file bug. > > > >> > > > >> Consider: > > > >> > > > >> * User installs version from testing with file in /bin * > > > >> Maintainer quickly moves the file to /usr/bin per your MBF * > > > >> Bookworm releases; user does not upgrade at this point * Package > > > >> reorganization; file moves between packages * User upgrades; file > > > >> disappears > > > > > > Luca> What "package reorganization" would that be? Are you aware of > > > Luca> any such thing happening in the next couple of weeks before > > > Luca> release? > > > > > > Who said anything about next couple of weeks. This affects testing and > > > unstable users *after the release*. It is my experience of Debian that > > > outside of freezes package reorganizations happen regularly. > > > > So what you are worried is the combination of a testing installation > > from~one year ago, that is otherwise never touched for say another > > year, and also that has one of those 23 packages installed in the old > > version, and also that same package of those 23 gets rearranged? That > > seems vanishingly unlikely, > > Against all odds, I can see very well this happening, so I guess > it shouldn't hurt to flag somehow packages having had to proceed > per the MBF. Big "warning" comments at a few strategic points > in d/control and install files might probably be a bare minimum, > so team fellows or future self won't trip on the carpet when > tempted to reorganize files. In case such an update is a supported use case, then yes, adding a comment to the install file where the change is applied would make perfect sense, as that's where it would be hypothetically removed from in that example. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 22:40, Sam Hartman wrote: > > ;>>>>> "Luca" == Luca Boccassi writes: > Luca> So what you are worried is the combination of a testing > Luca> installation from~one year ago, that is otherwise never > Luca> touched for say another year, and also that has one of those > Luca> 23 packages installed in the old version, and also that same > Luca> package of those 23 gets rearranged? > > I find I'm joining the growing number of people who cannot assume good > faith. > I'm disappointed that you choose to diminish others arguments, working > to find the quickest way to dismiss the contributions of people who are > interacting with you rather than to explore what they are saying and > see if there is something you can learn from their contributions. This is how you started your "contribution" to an otherwise normal and tension-less thread: > This sounds like a really bad idea. ... > I suspect the reason you want to make this MBF is that you believe it will somehow make the transition easier if there are fewer files in /bin or /usr/bin. IE, you immediately escalated it with aggressiveness followed by baseless accusations verging on the conspiratorial. So next time you might want to consider getting off that high horse first, before giving others lessons in how to approach a thread. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 23:07, Sam Hartman wrote: > > >>>>> "Luca" == Luca Boccassi writes: > > >> I suspect the reason you want to make this MBF is that you > >> believe it > Luca> will somehow make the transition easier if there are fewer > Luca> files in /bin or /usr/bin. > > Luca> IE, you immediately escalated it with aggressiveness followed > Luca> by baseless accusations verging on the conspiratorial. > > I regret that my second statement came across as an accusation and > certainly that you heard it as a conspiracy. > I'd like to be heard differently. > My understanding at the time (which you have since corrected) is that > you were making the proposal because you believed it would make a > transition to canonical paths easier. > In my mind that would be a good reason for advocating for such a > transition. > That is the spirit in which I made the assumption about your reasoning. > Again, I regret that you heard things in a different tone. > > I read your original message as a valuable contribution that in my > analysis I thought was a bad idea because of the dpkg disappearing file > bug. Thank you for your clarification, I think the example you brought up is worth considering. Do you feel that Étienne's suggestion of documenting it in the place where such a change would necessarily have to take place so that it can't be missed (e.g.: the install file) would be an adequate safeguard? Kind regards, Luca Boccassi
Bug#1036354: unblock: iptables-persistent/1.0.20
Control: tags -1 -moreinfo
On Sun, 21 May 2023 21:48:19 +0200 Sebastian Ramacher
wrote:
> Control: tags -1 moreinfo confirmed
>
> On 2023-05-20 13:23:09 +, gustavo panizzo wrote:
> > >> >> unblock iptables-persistent/1.0.20
> > >> >>
> > >> >
> > >> >Thanks for taking care of this - I just checked and cannot see
the upload
> > >> >to unstable though?
> > >>
> > >> I'd prefer to wait for an ack from the release team
> > >
> > >Ok, in that case I think it should be explicitly mentioned that
this
> > >is a 'preapproval' request.
> >
> >
> > How to do that? I hope is done now
>
> Please go ahead and remove the moreinfo tag once the package is
> available in unstable.
It is now in unstable, debdiff attached.
--
Kind regards,
Luca Boccassi
diff -Nru iptables-persistent-1.0.19/debian/changelog iptables-persistent-1.0.20/debian/changelog
--- iptables-persistent-1.0.19/debian/changelog 2023-02-28 07:02:38.0 +
+++ iptables-persistent-1.0.20/debian/changelog 2023-05-19 12:27:33.0 +0100
@@ -1,3 +1,16 @@
+iptables-persistent (1.0.20) unstable; urgency=medium
+
+ [ Luca Boccassi ]
+ * [3d8a9b] Use aliases instead of overrides for alternative names
+(Closes: #1036147)
+ * [418c74] Install drop-ins in /lib/ instead of /etc/ (Closes: #1036147)
+
+ [ gustavo panizzo ]
+ * [06509f] Handle obsolete conffile removal
+ * [633371] Remove obsolete dependency (lsb-base)
+
+ -- gustavo panizzo Fri, 19 May 2023 13:27:33 +0200
+
iptables-persistent (1.0.19) unstable; urgency=medium
* [49d9ca] Debconf templates translation to Romanian.
diff -Nru iptables-persistent-1.0.19/debian/control iptables-persistent-1.0.20/debian/control
--- iptables-persistent-1.0.19/debian/control 2023-02-28 07:02:01.0 +
+++ iptables-persistent-1.0.20/debian/control 2023-05-19 12:27:33.0 +0100
@@ -10,7 +10,7 @@
Package: netfilter-persistent
Architecture: all
-Depends: lsb-base, ${misc:Depends}
+Depends: ${misc:Depends}
Suggests: iptables-persistent
Pre-Depends: ${misc:Pre-Depends}
Description: boot-time loader for netfilter configuration
diff -Nru iptables-persistent-1.0.19/debian/ipset.override iptables-persistent-1.0.20/debian/ipset.override
--- iptables-persistent-1.0.19/debian/ipset.override 2021-11-17 07:58:54.0 +
+++ iptables-persistent-1.0.20/debian/ipset.override 2023-05-19 12:27:33.0 +0100
@@ -1,2 +1,2 @@
-[Unit]
-Conflicts=ipset.service
+[Install]
+Alias=ipset.service
diff -Nru iptables-persistent-1.0.19/debian/ipset-persistent.install iptables-persistent-1.0.20/debian/ipset-persistent.install
--- iptables-persistent-1.0.19/debian/ipset-persistent.install 2021-11-17 07:58:54.0 +
+++ iptables-persistent-1.0.20/debian/ipset-persistent.install 2023-05-19 12:27:33.0 +0100
@@ -1,4 +1,4 @@
#! /usr/bin/dh-exec
plugins/10-ipset usr/share/netfilter-persistent/plugins.d/
plugins/40-ipset usr/share/netfilter-persistent/plugins.d/
-debian/ipset.override => etc/systemd/system/netfilter-persistent.service.d/ipset.conf
+debian/ipset.override => lib/systemd/system/netfilter-persistent.service.d/ipset.conf
diff -Nru iptables-persistent-1.0.19/debian/ipset-persistent.maintscript iptables-persistent-1.0.20/debian/ipset-persistent.maintscript
--- iptables-persistent-1.0.19/debian/ipset-persistent.maintscript 1970-01-01 01:00:00.0 +0100
+++ iptables-persistent-1.0.20/debian/ipset-persistent.maintscript 2023-05-19 12:27:33.0 +0100
@@ -0,0 +1 @@
+rm_conffile /etc/systemd/system/netfilter-persistent.service.d/ipset.conf
diff -Nru iptables-persistent-1.0.19/debian/ipset-persistent.postinst iptables-persistent-1.0.20/debian/ipset-persistent.postinst
--- iptables-persistent-1.0.19/debian/ipset-persistent.postinst 2021-11-17 07:58:54.0 +
+++ iptables-persistent-1.0.20/debian/ipset-persistent.postinst 2023-05-19 12:27:33.0 +0100
@@ -2,8 +2,10 @@
set -e
-# Setup alternatives
-update-alternatives --install /lib/systemd/system/ipset.service ipset.service /lib/systemd/system/netfilter-persistent.service 40
+# Can be dropped in Trixie
+if update-alternatives --query ipset.service 2>/dev/null; then
+update-alternatives --remove-all ipset.service
+fi
# Source debconf library
. /usr/share/debconf/confmodule
@@ -29,4 +31,11 @@
;;
esac
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
+# Ensure the drop-in is loaded
+if [ -d /run/systemd/system ]; then
+systemctl --system daemon-reload >/dev/null || true
+fi
+fi
+
#DEBHELPER#
diff -Nru iptables-persistent-1.0.19/debian/ipset-persistent.postrm iptables-persistent-1.0.20/debian/i
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Tue, 23 May 2023 at 17:48, Paul Gevers wrote: > > Hi, > > On 21-05-2023 21:22, Luca Boccassi wrote: > > If we were to do a MBF against packages that in _Bookworm_ have > > introduced new files in /bin, /sbin or /lib*, would you accept the > > consequent mass unblock request? > > Short answer is no, it's too late. Understandable, thanks for checking. Kind regards, Luca Boccassi
Bug#1036554: unblock: iproute2/6.1.0-3
On Mon, 22 May 2023 14:30:50 +0100 Luca Boccassi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Dear Release Team, > > A small regression w.r.t. Bookworm has just been reported on iproute2. > It is a trivial fix so I'd like to have it in the release if possible. > debdiff attached. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036534 The regression this fixes is w.r.t. Bullseye, I meant. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1035710: unblock: doc-debian/11.3
On Tue, 23 May 2023 06:46:19 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= wrote: > On Sat, May 20, 2023 at 04:21:47PM +0200, Sebastian Ramacher wrote: > > > On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote: > > > reopen 1035710 > > > retitle 1035710 unblock: doc-debian/11.3 > > > thanks > > > > > > Please unblock package doc-debian > > > > > > [ Reason ] > > > The doc-debian package claims to ship the Constitution for the Debian Project, > > > the Debian Social Contract and other Debian documents. The versions of those > > > documents are obsolete [obsolete], which makes the package as now in testing > > > very buggy. > > > > > > > unblock doc-debian/11.3 > > > > Please go ahead with the upload to unstable. Remove the moreinfo tag > > once the package is available. > > Thank you. Unfortunately I don't think I'll make it before the deadline / in > the next couple of hours, real life currently doesn't allow me that. > > If anybody else has time to take a shot at it: here's the current issue's: I > made a mistake in the upload to experimental: it says 'experimental' in the top > of debian/changelog; should probably be 'unstable'. And the last commit on > salsa is misguided. > > If nobody steps up I can probably prepare an upload for the first bookworm > point release. I can take care of this, I'll do a changelog-only upload of the current version that's in experimental to unstable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1035710: unblock: doc-debian/11.3
Control: retitle -1 unblock: doc-debian/11.3+nmu1 Control: tags -1 -moreinfo On Tue, 23 May 2023 23:37:23 +0100 Luca Boccassi wrote: > On Tue, 23 May 2023 06:46:19 +0200 Joost van =?utf-8?Q?Baal- Ili=C4=87?= > wrote: > > On Sat, May 20, 2023 at 04:21:47PM +0200, Sebastian Ramacher wrote: > > > > > On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote: > > > > reopen 1035710 > > > > retitle 1035710 unblock: doc-debian/11.3 > > > > thanks > > > > > > > > Please unblock package doc-debian > > > > > > > > [ Reason ] > > > > The doc-debian package claims to ship the Constitution for the > Debian Project, > > > > the Debian Social Contract and other Debian documents. The > versions of those > > > > documents are obsolete [obsolete], which makes the package as now > in testing > > > > very buggy. > > > > > > > > > > unblock doc-debian/11.3 > > > > > > Please go ahead with the upload to unstable. Remove the moreinfo > tag > > > once the package is available. > > > > Thank you. Unfortunately I don't think I'll make it before the > deadline / in > > the next couple of hours, real life currently doesn't allow me that. > > > > If anybody else has time to take a shot at it: here's the current > issue's: I > > made a mistake in the upload to experimental: it says 'experimental' > in the top > > of debian/changelog; should probably be 'unstable'. And the last > commit on > > salsa is misguided. > > > > If nobody steps up I can probably prepare an upload for the first > bookworm > > point release. > > I can take care of this, I'll do a changelog-only upload of the current > version that's in experimental to unstable. Done, you can find the changelog-only commit to pull from at: https://salsa.debian.org/bluca/doc-debian/-/commits/master?ref_type=heads -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
On Wed, 24 May 2023 09:59:31 +0200 Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Sebastian Ramacher (2023-05-24 09:48:31) > > mmdebstrap's autopkgtest seem to depend quite extensively on the state of > > other packages in the archive. Maybe it would be better to make them as > > flaky. > > I don't think that would be wise. We do these tests for packages to find out > when something breaks and we run those as autopkgtests so that things do not > transition to testing when they break other things. Because the mmdebstrap > autopkgtest tests so many things it found bugs earlier than many other > mechanisms we use for QA. There are packages with autopkgtests depending on > many more things than what the mmdebstrap autopkgtest depends on. Marking it as > flaky would also be wrong because its output is not random but depends > precisely on the state of the archive and produces the same result for the same > state every time. Marking it as flaky would just hide problems. I think it's > expected that a tool creating Debian chroots has tests that are affected by > things happening in the Essential:yes set. > > > In any case, if you want to have this change in bookworm, be aware that the > > window is closing quickly. > > I do not need this change in bookworm as the change only covers the > autopkgtest. The contents of the mmdebstrap binary package are not affected by > any of this, so even if this change gets approved it would not change what is > shipped in bookworm (except of course the source package itself). > > I filed this pre-approval because maybe it is important for the release team > that autopkgtests pass and thus I prepared for the changes that recently > happened in doc-debian as well as in dash and adduser. doc-debian is now uploaded and unblocked. Regarding dash, would it be possible for the autopkgtest to support both the versions in unstable and experimental, so that it works and you can get it unblocked? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1035745: unblock: dash/0.5.12-4 (preapproval)
On Wed, 24 May 2023 at 15:14, Paul Gevers wrote: > > Hi Luca, > > On 08-05-2023 17:54, Luca Boccassi wrote: > > Filing this on request of the dash maintainer. We have recently > > implemented a much needed cleanup that removes an unnecessary diversion > > on /bin/sh, that makes the essential set nice and clean and diversion- > > free, so that it can be set up without complex machinery. > > Let's do this in trixie. This request has been uneasy since you filed > it, that's why it took so long to reply. Today I discussed with Andrej > and we agreed this is too late for bookworm. Ok, no worries. I had hoped that two weeks ago when I filed it there was still enough time, but today it is indeed very late. Kind regards, Luca Boccassi
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
On Thu, 25 May 2023 at 11:04, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Luca Boccassi (2023-05-24 10:52:08) > > Regarding dash, would it be possible for the autopkgtest to support both the > > versions in unstable and experimental, so that it works and you can get it > > unblocked? > > yes. The current version in unstable does exactly that. But as the dash > unblock > request got denied I guess I should revert that change now and do another > upload. I think it makes sense to support both situations, in the very unlikely but not impossible case that we'll need a later dash p-u upload for any reason. Kind regards, Luca Boccassi
Bug#1038451: bullseye-pu: package systemd/247.3-7+deb11u4
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org at packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-systemd-maintainers at lists.alioth.debian.org
Dear release team,
I have uploaded one new bugfix for systemd in bullseye. It is a
backport of two upstream patches to fix a calendar spec calculation
hang on DST change when TZ=Europe/Dublin as reported by Bullseye users
at #1033540.
The source debdiff is attached.
--
Kind regards,
Luca Boccassi
diff -Nru systemd-247.3/debian/changelog systemd-247.3/debian/changelog
--- systemd-247.3/debian/changelog 2023-04-30 13:56:31.0 +0100
+++ systemd-247.3/debian/changelog 2023-06-18 15:55:54.0 +0100
@@ -1,3 +1,10 @@
+systemd (247.3-7+deb11u4) bullseye; urgency=medium
+
+ * backport patches to fix a calendar spec calculation hang on DST change
+if TZ=Europe/Dublin (Closes: #1033540)
+
+ -- Luca Boccassi Sun, 18 Jun 2023 15:55:54 +0100
+
systemd (247.3-7+deb11u3) bullseye; urgency=medium
* udev: fix creating /dev/serial/by-id/ symlinks for USB devices.
diff -Nru systemd-247.3/debian/patches/series systemd-247.3/debian/patches/series
--- systemd-247.3/debian/patches/series 2023-04-30 13:51:17.0 +0100
+++ systemd-247.3/debian/patches/series 2023-06-18 15:55:16.0 +0100
@@ -37,6 +37,8 @@
time-util-fix-buffer-over-run.patch
machined-varlink-fix-double-free.patch
Always-free-deserialized_subscribed-on-reload.patch
+shared-calendarspec-abort-calculation-after-1000-iteratio.patch
+shared-calendarspec-when-mktime-moves-us-backwards-jump-f.patch
debian/Use-Debian-specific-config-files.patch
debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch
debian/Make-run-lock-tmpfs-an-API-fs.patch
diff -Nru systemd-247.3/debian/patches/shared-calendarspec-abort-calculation-after-1000-iteratio.patch systemd-247.3/debian/patches/shared-calendarspec-abort-calculation-after-1000-iteratio.patch
--- systemd-247.3/debian/patches/shared-calendarspec-abort-calculation-after-1000-iteratio.patch 1970-01-01 01:00:00.0 +0100
+++ systemd-247.3/debian/patches/shared-calendarspec-abort-calculation-after-1000-iteratio.patch 2023-06-18 15:55:16.0 +0100
@@ -0,0 +1,55 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?=
+Date: Sun, 21 Mar 2021 20:59:32 +0100
+Subject: shared/calendarspec: abort calculation after 1000 iterations
+
+We have a bug where we seem to enter an infinite loop when running in the
+Europe/Dublin timezone. The timezone is "special" because it has negative SAVE
+values. The handling of this should obviously be fixed, but let's use a
+belt-and-suspenders approach, and gracefully fail if we fail to find an answer
+within a specific number of attempts. The code in this function is rather
+complex, and it's hard to rule out another bug in the future.
+
+(cherry picked from commit 169615c9a8cdc54d748d4dfc8279be9b3c2bec44)
+---
+ src/shared/calendarspec.c | 14 +-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
+index 7162592..80acc57 100644
+--- a/src/shared/calendarspec.c
b/src/shared/calendarspec.c
+@@ -1211,6 +1211,10 @@ static bool matches_weekday(int weekdays_bits, const struct tm *tm, bool utc) {
+ return (weekdays_bits & (1 << k));
+ }
+
++/* A safety valve: if we get stuck in the calculation, return an error.
++ * C.f. https://bugzilla.redhat.com/show_bug.cgi?id=1941335. */
++#define MAX_CALENDAR_ITERATIONS 1000
++
+ static int find_next(const CalendarSpec *spec, struct tm *tm, usec_t *usec) {
+ struct tm c;
+ int tm_usec;
+@@ -1224,7 +1228,7 @@ static int find_next(const CalendarSpec *spec, struct tm *tm, usec_t *usec) {
+ c = *tm;
+ tm_usec = *usec;
+
+-for (;;) {
++for (unsigned iteration = 0; iteration < MAX_CALENDAR_ITERATIONS; iteration++) {
+ /* Normalize the current date */
+ (void) mktime_or_timegm(&c, spec->utc);
+ c.tm_isdst = spec->dst;
+@@ -1321,6 +1325,14 @@ static int find_next(const CalendarSpec *spec, struct tm *tm, usec_t *usec) {
+ *usec = tm_usec;
+ return 0;
+ }
++
++/* It seems we entered an infinite loop. Let's gracefully return an error instead of hanging or
++ * aborting. This code is also exercised when timers.target is brought up during early boot, so
++ * aborting here is problematic and hard to diagnose for users. */
++_cleanup_free_ char *s = NULL;
++(void) calendar_spec_to_string(spec, &s);
++return log_warning_errno(SYNTHETIC_ERRNO(EDEADLK),
++ "Infinite loop in calendar calculation: %s", strna(s));
+ }
+
+ static int calendar_spec_next_usec_impl(const CalendarSpec *spec, usec_t usec, usec_t *ret_next) {
diff -Nru systemd-247.3/debian/patches/shared-calendarspec-wh
Bug#1037420: bookworm-pu: package systemd/252.11-1~deb12u1
On Mon, 12 Jun 2023 15:33:45 +0100 Luca Boccassi wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org > > Dear Release Team, > > We would like to upload the latest stable point release of systemd 252 > to bookworm-p-u. Stable release branches are maintained upstream with > the intention of providing bug fixes only and no compatibility > breakages, and with automated non-trivial CI jobs that also cover > Debian and Ubuntu. This is the first upload to bookworm-p-u so this is > a pre-approval request. > > Debdiff attached. No packaging changes besides refreshing patches. As suggested, to save some roundtrips, I've gone ahead with the upload to p-u already. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
On Wed, 30 Aug 2023 16:27:12 +0100 Simon McVittie wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: debootst...@packages.debian.org, hel...@subdivi.de > Control: affects -1 + src:debootstrap > Control: block 1025708 by -1 > > [ Reason ] > Part of the transition to merged-/usr, and more specifically, allowing > us to stop shipping files in trixie whose physical path on disk does > not match their path in the dpkg database due to directory aliasing. > > This change needs to be in bookworm (and bullseye, and maybe buster) > before that process can continue, because official buildds run debootstrap > from stable (or older). > > I also took the opportunity to backport changes that make the autopkgtests > pass. Dear Release Team, I think it would be nice to let this bake in proposed-updates for a while before 12.2 is released, just to be extra-extra-safe. Any chance for a quick review so we can upload it? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
On Tue, 5 Sep 2023 17:33:27 +0100 Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Tue, Sep 05, 2023 at 10:30:09AM +0100, Luca Boccassi wrote: > > On Wed, 30 Aug 2023 16:27:12 +0100 Simon McVittie > > wrote: > > > Part of the transition to merged-/usr, and more specifically, > > allowing > > > us to stop shipping files in trixie whose physical path on disk does > > > not match their path in the dpkg database due to directory aliasing. > > > > > > This change needs to be in bookworm (and bullseye, and maybe buster) > > > before that process can continue, because official buildds run > > debootstrap > > > from stable (or older). > > > > > > I also took the opportunity to backport changes that make the > > autopkgtests > > > pass. > > > > I think it would be nice to let this bake in proposed-updates for a > > while before 12.2 is released, just to be extra-extra-safe. Any chance > > for a quick review so we can upload it? > > It will need a d-i ack as a pre-requisite. Thanks Jonathan - d-i team, would it be possible for a quick review of this and #1025708 please? This was tested with d-i as such: > Philip Hands built a d-i mini.iso with the proposed version, and it seems to have installed GNOME successfully under openQA. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1051545: bookworm-pu: package systemd/252.16-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian.org at packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-systemd-maintainers at lists.alioth.debian.org Dear Release Team, We would like to upload the latest stable point release of systemd 252 to bookworm-p-u. Stable release branches are maintained upstream with the intention of providing bug fixes only and no compatibility breakages, and with automated non-trivial CI jobs that also cover Debian and Ubuntu. I have already uploaded to p-u. Debdiff attached. No packaging changes apart from refreshing patches and adjusting salsa-ci.yml. -- Kind regards, Luca Boccassi diff -Nru systemd-252.14/debian/changelog systemd-252.16/debian/changelog --- systemd-252.14/debian/changelog 2023-08-11 02:42:44.0 +0100 +++ systemd-252.16/debian/changelog 2023-09-09 02:24:49.0 +0100 @@ -1,3 +1,10 @@ +systemd (252.16-1~deb12u1) bookworm; urgency=medium + + * New upstream version 252.16 + * Refresh patches for v252.16 + + -- Luca Boccassi Sat, 09 Sep 2023 02:24:49 +0100 + systemd (252.14-1~deb12u1) bookworm; urgency=medium * New upstream version 252.14 diff -Nru systemd-252.14/debian/patches/p11kit-switch-to-dlopen.patch systemd-252.16/debian/patches/p11kit-switch-to-dlopen.patch --- systemd-252.14/debian/patches/p11kit-switch-to-dlopen.patch 2023-08-11 02:42:44.0 +0100 +++ systemd-252.16/debian/patches/p11kit-switch-to-dlopen.patch 2023-09-09 02:24:18.0 +0100 @@ -41,7 +41,7 @@ librt, libseccomp, diff --git a/src/shared/pkcs11-util.c b/src/shared/pkcs11-util.c -index f5f6617..4d7edf8 100644 +index 11cdccc..daee267 100644 --- a/src/shared/pkcs11-util.c +++ b/src/shared/pkcs11-util.c @@ -3,6 +3,7 @@ diff -Nru systemd-252.14/debian/salsa-ci.yml systemd-252.16/debian/salsa-ci.yml --- systemd-252.14/debian/salsa-ci.yml 2023-08-11 02:42:44.0 +0100 +++ systemd-252.16/debian/salsa-ci.yml 2023-09-09 02:24:49.0 +0100 @@ -9,3 +9,4 @@ # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011649 SALSA_CI_DISABLE_PIUPARTS: 1 RELEASE: 'bookworm' + SALSA_CI_LINTIAN_SUPPRESS_TAGS: "bad-distribution-in-changes-file" diff -Nru systemd-252.14/man/coredump.conf.xml systemd-252.16/man/coredump.conf.xml --- systemd-252.14/man/coredump.conf.xml 2023-08-10 09:43:05.0 +0100 +++ systemd-252.16/man/coredump.conf.xml 2023-09-09 02:21:12.0 +0100 @@ -57,18 +57,22 @@ Storage= Controls where to store cores. One of none, -external, and journal. When -none, the core dumps may be logged (including the backtrace if -possible), but not stored permanently. When external (the -default), cores will be stored in /var/lib/systemd/coredump/. -When journal, cores will be stored in the journal and rotated -following normal journal rotation patterns. +external, and journal. When none, the core +dumps may be logged (including the backtrace if possible), but not stored permanently. When +external (the default), cores will be stored in +/var/lib/systemd/coredump/. When journal, cores will be +stored in the journal and rotated following normal journal rotation patterns. -When cores are stored in the journal, they might be -compressed following journal compression settings, see +When cores are stored in the journal, they might be compressed following journal compression +settings, see journald.conf5. -When cores are stored externally, they will be compressed -by default, see below. +When cores are stored externally, they will be compressed by default, see below. + +Note that in order to process a coredump (i.e. extract a stack trace) the core must be written +to disk first. Thus, unless ProcessSizeMax= is set to 0 (see below), the core will +be written to /var/lib/systemd/coredump/ either way (under a temporary filename, +or even in an unlinked file), Storage= thus only controls whether to leave it +there even after it was processed. @@ -84,7 +88,7 @@ ProcessSizeMax= The maximum size in bytes of a core which will be processed. Core dumps exceeding -this size may be stored, but the backtrace will not be generated. Like other sizes in this same +this size may be stored, but the stack trace will not be generated. Like other sizes in this same config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E). Defaults to 1G on 32bit systems, 32G on 64bit systems. diff -Nru systemd-252.14/man/daemon.xml systemd-252.16/man/daemon.xml --- systemd-252.14/man/daemon.xml 2023-08-10 09:43:05.0 +0100 +++ systemd-252.16/man/daemon.xml 2023-09-09 02:21:12.0 +0100 @@ -553,7 +553,7 @@ unit installation path during source
