Bug#940595: transition: hypre
On 2019-10-18 15:56, Emilio Pozuelo Monfort wrote: On 17/10/2019 17:05, Drew Parsons wrote: Hi Emilio, this is rather awkward. Hypre upstream has just released 2.18.1, so this would be the one to run the transition on. ... "The hypre team currently does nothing to ensure application binary interface (ABI) compatibility. As a result, all releases (major, minor, or patch) should be treated as incompatible." It means we have to run a new library package for each patch release, and therefore have to jump back into the NEW queue with libhypre-2.18.1. It's either that, or provide only a generic libhypre package and apply rigidly strict shlib files depending strictly on a given version. ... Right, the strict dependency via shlibs and provides would make testing migrations harder as everything would need to transition at the same time (hypre and all rdeps). However there are three rdeps and you control two of them, so it doesn't look like a terrible situation. hypre 2.18.1 is now ready in experimental. I've implemented the common libhypre option with shlibs patch-version dependency. If this approach proves problematic in practice then we can switch back to version-based library package names afterwards if we need to. I've confirmed petsc and sundials build successfully. Let's do this transition. Drew
Bug#940595: transition: hypre
On 2019-10-30 15:21, Drew Parsons wrote: hypre 2.18.1 is now ready in experimental. I've implemented the common libhypre option with shlibs patch-version dependency. If this approach proves problematic in practice then we can switch back to version-based library package names afterwards if we need to. I've confirmed petsc and sundials build successfully. Let's do this transition. p.s. for bonus lols, I just checked and yes, 2.18.2 has just been released... So yes, the unversioned libhypre package name is certainly the option that will preserve the greatest sanity (I'll proceed directly with 2.18.2 once you give the thumbs up). (they're releasing unusually rapidly lately. Previously there have been less than 2 releases each year).
NEW changes in oldstable-new
Processing changes file: gnustep-base_1.24.9-3.1+deb9u1_armhf.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: gnustep-base_1.24.9-3.1+deb9u1_mipsel.changes ACCEPT
Re: Scheduling 10.2
Hi all Sorry for the late reply El 21/10/19 a las 21:26, Adam D. Barratt escribió: > Hi, > > It's (really past) time to consider a date for the second buster point > release. > > I've listed some suggested dates below; please indicate which you would > be available for. > > - November 2nd > - I'm not available; also means that the freeze would have to be this > coming weekend > - November 9th > - November 16th > - November 23rd > - November 30th > - a little late, and I'm not available Any weekend of November (except the 2nd) works for publicity. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Processed: Re: Bug#941738: buster-pu: package network-manager/1.14.6-2+deb10u1
Processing commands for cont...@bugs.debian.org: > retitle 941738 buster-pu: package network-manager/1.14.6-2+deb10u1 Bug #941738 [release.debian.org] buster-pu: package network-manager/1.14.6-3 Changed Bug title to 'buster-pu: package network-manager/1.14.6-2+deb10u1' from 'buster-pu: package network-manager/1.14.6-3'. > thanks Stopping processing here. Please contact me if you need assistance. -- 941738: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941738 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#941738: buster-pu: package network-manager/1.14.6-2+deb10u1
retitle 941738 buster-pu: package network-manager/1.14.6-2+deb10u1
thanks
Am 04.10.19 um 15:20 schrieb Michael Biebl:
> Am 04.10.19 um 15:09 schrieb Michael Biebl:
>> +network-manager (1.14.6-3) stable; urgency=medium
>
> 1.14.6-3 is unused so far, but I guess it would be better us use
> 1.14.6-2+deb10u1 instead?
I guess the latter is more in line with current practice, so retitling
the bug report accordingly. Updated debdiff attached.
Please let me know if I can proceed with the upload.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/changelog b/debian/changelog
index 7cb171e5a..13658c1c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+network-manager (1.14.6-2+deb10u1) stable; urgency=medium
+
+ * core: fix file permissions for "/var/lib/NetworkManager/secret_key"
+Patch cherry-picked from upstream.
+ * Fix permissions of /var/lib/NetworkManager/secret_key on upgrades.
+The file mode is supposed to be 0600. (Closes: #941609)
+ * Install directories as created by upstream build system.
+Drop network-manager.dirs and instead use the directories created by the
+upstream build system. Fix permissions of /var/lib/NetworkManager to be
+0700 as it contains possibly sensitive data and should not be
+world-readable.
+ * d/gbp.conf: Set debian-branch to buster
+
+ -- Michael Biebl Fri, 04 Oct 2019 15:03:20 +0200
+
network-manager (1.14.6-2) unstable; urgency=medium
* supplicant: fix setting pmf when the supplicant doesn't advertise support
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 478d845ce..3c81df87a 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,4 @@
[DEFAULT]
pristine-tar = True
patch-numbers = False
-debian-branch = master
+debian-branch = buster
diff --git a/debian/network-manager.dirs b/debian/network-manager.dirs
deleted file mode 100644
index e09403be4..0
--- a/debian/network-manager.dirs
+++ /dev/null
@@ -1,10 +0,0 @@
-etc/NetworkManager/conf.d/
-etc/NetworkManager/dispatcher.d/no-wait.d/
-etc/NetworkManager/dispatcher.d/pre-down.d/
-etc/NetworkManager/dispatcher.d/pre-up.d/
-etc/NetworkManager/dnsmasq.d/
-etc/NetworkManager/dnsmasq-shared.d/
-etc/NetworkManager/system-connections/
-usr/lib/NetworkManager/conf.d/
-usr/lib/NetworkManager/VPN/
-var/lib/NetworkManager/
diff --git a/debian/network-manager.install b/debian/network-manager.install
index 0f1e82ae5..3f94d7a46 100644
--- a/debian/network-manager.install
+++ b/debian/network-manager.install
@@ -2,10 +2,7 @@ usr/sbin/NetworkManager
usr/bin/nm-online
usr/bin/nmcli
usr/bin/nmtui*
-usr/lib/NetworkManager/nm-dhcp-helper
-usr/lib/NetworkManager/nm-iface-helper
-usr/lib/NetworkManager/nm-dispatcher
-usr/lib/NetworkManager/nm-initrd-generator
+usr/lib/NetworkManager/
usr/lib/*/NetworkManager/*/libnm-settings-plugin-ifupdown.so
usr/lib/*/NetworkManager/*/libnm-device-plugin-*.so
usr/lib/*/NetworkManager/*/libnm-ppp-plugin.so
@@ -18,7 +15,8 @@ usr/share/dbus-1/system.d/org.freedesktop.NetworkManager.conf
usr/share/dbus-1/system.d/nm-dispatcher.conf
usr/share/polkit-1/
usr/share/bash-completion/
-etc/NetworkManager/dispatcher.d/
+etc/NetworkManager/
+var/lib/NetworkManager/
lib/udev/rules.d/*.rules
lib/systemd/system/NetworkManager.service
lib/systemd/system/NetworkManager-dispatcher.service
diff --git a/debian/network-manager.postinst b/debian/network-manager.postinst
index 0f95087f8..7f0589da6 100644
--- a/debian/network-manager.postinst
+++ b/debian/network-manager.postinst
@@ -24,6 +24,9 @@ case "$1" in
# org.freedesktop.NetworkManager.settings.modify.system without prior
authentication
addgroup --quiet --system netdev
+# This directory can contain sensitive data and should not be
world-readable
+chmod 0700 /var/lib/NetworkManager
+
NIF=/etc/network/interfaces
if [ -z "$2" ] && [ -f $NIF ]; then
ifaces=`grep -v '^#' $NIF | awk '/iface/ {print $2}' | sort -u |
sed -e 's/lo//' -e '/^$/d' -e 's/^/- /'`
@@ -44,6 +47,12 @@ case "$1" in
ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
fi
fi
+
+if dpkg --compare-versions "$2" lt-nl "1.14.6-3"; then
+if [ -f /var/lib/NetworkManager/secret_key ]; then
+chmod 0600 /var/lib/NetworkManager/secret_key
+fi
+fi
;;
abort-upgrade|abort-deconfigure|abort-remove)
diff --git
a/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
b/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
new file mode 100644
index 0..8e51fa6a4
--- /dev/null
+++
b/debian/patches/core-fix-file-permissions-for-var-lib-NetworkManager-secr.patch
@@ -0,0 +1,40 @@
+From: Thomas Haller
+Date: Tue, 14 May 2019 13:55:41 +0200
+Subject: core: fix file permissions for "/var/lib/NetworkManager/sec
Bug#943846: buster-pu: package python-cryptography/2.6.1-3+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
(This is a followup update on top of the +deb10u1 already in s-p-u,
I've reached out to Tristan beforehand)
Attached debdiff fixes a memory leak in python-cryptography, which
was noticed in an ACME-related service
(https://wikitech.wikimedia.org/wiki/Acme-chief)
running on Buster. It has been verified that the updated packages
fix the memory leak (and are otherwise working fine as well).
Debdiff below.
Cheers,
Moritz
diff -Nru python-cryptography-2.6.1/debian/changelog
python-cryptography-2.6.1/debian/changelog
--- python-cryptography-2.6.1/debian/changelog 2019-09-30 20:55:00.0
+0200
+++ python-cryptography-2.6.1/debian/changelog 2019-10-18 16:08:59.0
+0200
@@ -1,3 +1,13 @@
+python-cryptography (2.6.1-3+deb10u2) buster; urgency=medium
+
+ * Cherrypick 92241410b5b0591d849443b3023992334a4be0a2 and
+9a22851fab924fd58482fdad3f8dd23dc3987f91 from upstream which
+addresses a memory leak triggerable when parsing x509
+certificate extensions like AIA, thanks to Valentin
+Gutierrez for the report (Closes: #941413)
+
+ -- Moritz Mühlenhoff Fri, 18 Oct 2019 16:08:59 +0200
+
python-cryptography (2.6.1-3+deb10u1) buster; urgency=medium
* Non-maintainer upload.
diff -Nru python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
--- python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
1970-01-01 01:00:00.0 +0100
+++ python-cryptography-2.6.1/debian/patches/aia-memleak-1.patch
2019-10-18 16:08:35.0 +0200
@@ -0,0 +1,94 @@
+From 92241410b5b0591d849443b3023992334a4be0a2 Mon Sep 17 00:00:00 2001
+From: Paul Kehrer
+Date: Thu, 11 Apr 2019 20:57:13 +0800
+Subject: [PATCH] fix a memory leak in AIA parsing (#4836)
+
+* fix a memory leak in AIA parsing
+
+* oops can't remove that
+---
+ src/_cffi_src/openssl/x509v3.py | 3 +++
+ .../hazmat/backends/openssl/decode_asn1.py| 9 +++-
+ tests/hazmat/backends/test_openssl_memleak.py | 21 ++-
+ 3 files changed, 31 insertions(+), 2 deletions(-)
+
+diff --git a/src/_cffi_src/openssl/x509v3.py b/src/_cffi_src/openssl/x509v3.py
+index 193d2e233b..5968120652 100644
+--- a/src/_cffi_src/openssl/x509v3.py
b/src/_cffi_src/openssl/x509v3.py
+@@ -177,6 +177,7 @@
+ typedef void (*sk_GENERAL_NAME_freefunc)(GENERAL_NAME *);
+ typedef void (*sk_DIST_POINT_freefunc)(DIST_POINT *);
+ typedef void (*sk_POLICYINFO_freefunc)(POLICYINFO *);
++typedef void (*sk_ACCESS_DESCRIPTION_freefunc)(ACCESS_DESCRIPTION *);
+ """
+
+
+@@ -228,6 +229,8 @@
+ Cryptography_STACK_OF_ACCESS_DESCRIPTION *, int
+ );
+ void sk_ACCESS_DESCRIPTION_free(Cryptography_STACK_OF_ACCESS_DESCRIPTION *);
++void sk_ACCESS_DESCRIPTION_pop_free(Cryptography_STACK_OF_ACCESS_DESCRIPTION
*,
++ sk_ACCESS_DESCRIPTION_freefunc);
+ int sk_ACCESS_DESCRIPTION_push(Cryptography_STACK_OF_ACCESS_DESCRIPTION *,
+ACCESS_DESCRIPTION *);
+
+diff --git a/src/cryptography/hazmat/backends/openssl/decode_asn1.py
b/src/cryptography/hazmat/backends/openssl/decode_asn1.py
+index 773189d4f8..75d5844bc1 100644
+--- a/src/cryptography/hazmat/backends/openssl/decode_asn1.py
b/src/cryptography/hazmat/backends/openssl/decode_asn1.py
+@@ -379,7 +379,14 @@ def _decode_authority_key_identifier(backend, akid):
+
+ def _decode_authority_information_access(backend, aia):
+ aia = backend._ffi.cast("Cryptography_STACK_OF_ACCESS_DESCRIPTION *", aia)
+-aia = backend._ffi.gc(aia, backend._lib.sk_ACCESS_DESCRIPTION_free)
++aia = backend._ffi.gc(
++aia,
++lambda x: backend._lib.sk_ACCESS_DESCRIPTION_pop_free(
++x, backend._ffi.addressof(
++backend._lib._original_lib, "ACCESS_DESCRIPTION_free"
++)
++)
++)
+ num = backend._lib.sk_ACCESS_DESCRIPTION_num(aia)
+ access_descriptions = []
+ for i in range(num):
+diff --git a/tests/hazmat/backends/test_openssl_memleak.py
b/tests/hazmat/backends/test_openssl_memleak.py
+index ed22b5db9e..f9ae1c46b9 100644
+--- a/tests/hazmat/backends/test_openssl_memleak.py
b/tests/hazmat/backends/test_openssl_memleak.py
+@@ -210,7 +210,7 @@ class TestOpenSSLMemoryLeaks(object):
+ @pytest.mark.parametrize("path", [
+ "x509/PKITS_data/certs/ValidcRLIssuerTest28EE.crt",
+ ])
+-def test_x509_certificate_extensions(self, path):
++def test_der_x509_certificate_extensions(self, path):
+ assert_no_memory_leaks(textwrap.dedent("""
+ def func(path):
+ from cryptography import x509
+@@ -226,6 +226,25 @@ def func(path):
+ cert.extensions
+ """), [path])
+
++@pytest.mark.parametrize("path", [
++"x509/cryptography.io.pem",
++])
++def test_pem_x509_certificate_extensions(self, path):
++
Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm The rust-crossbeam-utils-0.5 package is no longer in use. All reverse dependencies either migrated to a non-semver-suffixed version of rust- crossbeam-utils or don't depend on it anymore at all. The only remaining dependency as of now is rust-crossbeam-epoch-0.5 for which I asked the maintainer to file a RM request as well.
Upcoming stable point release (10.2)
Hi, The next point release for "buster" (10.2) is scheduled for Saturday, November 16th. Processing of new uploads into buster-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2
On Wed, 2019-10-30 at 21:16 +0100, Wolfgang Silbermayr wrote: > The rust-crossbeam-utils-0.5 package is no longer in use. All reverse > dependencies either migrated to a non-semver-suffixed version of > rust- > crossbeam-utils or don't depend on it anymore at all. > The only remaining dependency as of now is rust-crossbeam-epoch-0.5 > for which I > asked the maintainer to file a RM request as well. Are you requesting removal from unstable? Regards, Adam
Bug#894663: transition: wxwidgets3.0
On Fri, Oct 25, 2019 at 09:27:48AM +1300, Olly Betts wrote: > On Tue, Oct 22, 2019 at 08:58:42AM +1300, Olly Betts wrote: > > * mrpt was updated but the build failed on mipsel due to running out of > > memory and it's now entangled in auto-opencv. But it's due for AUTORM > > on 2019-10-28 so that should resolve itself within a week. > > No change here. The AUTORM happened for mrpt. > However, checking with "dak rm" on coccia, I discovered four packages > which build-depend on libwxgtk3.0-dev but without a resulting runtime > dependency. I've filed bugs against these and set them as blocking this > bug. They should at least be easy to address. Fixes for these extra four have now been uploaded and checking again: olly@coccia:~$ dak rm -Rn -b libwxgtk3.0-dev [...] # Broken Depends: wxsvg: libwxsvg-dev wxwidgets3.0: libwxgtk-media3.0-dev # Broken Build-Depends: amule: libwxgtk3.0-dev codeblocks: libwxgtk3.0-dev cubicsdr: libwxgtk3.0-dev objcryst-fox: libwxgtk3.0-dev pcsx2: libwxgtk3.0-dev sooperlooper: libwxgtk3.0-dev treesheets: libwxgtk3.0-dev ucblogo: libwxgtk3.0-dev wxsvg: libwxgtk3.0-dev Which is just the packages which are only in unstable, so aren't blockers. The codeblocks maintainers never responded, but taffit is preparing an update to the latest upstream release so that at least should be off the list fairly soon. I've uploaded wxwidgets3.0 dropping the GTK2 flavour packages, so I think we can consider this transition complete. I'll leave actually closing this bug to someone on the release team in case I've missed something. Upstream wx are making noises about actually releasing 3.2 early next year, so we may have another wx transition before bullseye. We've managed to prune many of the rdeps which are inactive upstream and unmaintained in Debian, so the next one should hopefully be less work. Cheers, Olly
Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2
On 10/30/19 10:34 PM, Adam D. Barratt wrote: > On Wed, 2019-10-30 at 21:16 +0100, Wolfgang Silbermayr wrote: >> The rust-crossbeam-utils-0.5 package is no longer in use. All reverse >> dependencies either migrated to a non-semver-suffixed version of >> rust- >> crossbeam-utils or don't depend on it anymore at all. >> The only remaining dependency as of now is rust-crossbeam-epoch-0.5 >> for which I >> asked the maintainer to file a RM request as well. > > Are you requesting removal from unstable? Yes, that's correct. I selected that in `reportbug`, seems it didn't get pre-filled or I accidentially deleted it. I initially attempted to report that bug against the `ftp.debian.org` pseudo-package, selecting RoM from unstable as described in the developers reference section 5.9.2, but it showed a final dialog telling that I should report the bug against `release.debian.org`. Sorry if that's the wrong pseudo-package. Best regards, Wolfgang.
Processed: Re: Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2
Processing control commands: > reassign -1 ftp.debian.org Bug #943855 [release.debian.org] RM: rust-crossbeam-utils-0.5/0.5.2-2 Bug reassigned from package 'release.debian.org' to 'ftp.debian.org'. Ignoring request to alter found versions of bug #943855 to the same values previously set Ignoring request to alter fixed versions of bug #943855 to the same values previously set -- 943855: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943855 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2
Control: reassign -1 ftp.debian.org On Thu, 2019-10-31 at 05:57 +0100, Wolfgang Silbermayr wrote: > On 10/30/19 10:34 PM, Adam D. Barratt wrote: > > On Wed, 2019-10-30 at 21:16 +0100, Wolfgang Silbermayr wrote: > > > The rust-crossbeam-utils-0.5 package is no longer in use. All > > > reverse > > > dependencies either migrated to a non-semver-suffixed version of > > > rust- > > > crossbeam-utils or don't depend on it anymore at all. > > > The only remaining dependency as of now is rust-crossbeam-epoch- > > > 0.5 > > > for which I > > > asked the maintainer to file a RM request as well. > > > > Are you requesting removal from unstable? > > Yes, that's correct. > > I selected that in `reportbug`, seems it didn't get pre-filled or I > accidentially deleted it. > > I initially attempted to report that bug against the `ftp.debian.org` > pseudo-package, selecting RoM from unstable as described in the > developers reference section 5.9.2, but it showed a final dialog > telling > that I should report the bug against `release.debian.org`. Sorry if > that's the wrong pseudo-package. I'm not sure quite what happened with the reportbug flow there then, but ftp.d.o was the correct choice; reassigning. Regards, Adam
