Processed: Re: Bug#980847: pre-approval: qutebrowser/2.0.0-1
Processing control commands: > retitle -1 pre-approval: qutebrowser/2.0.1-2 Bug #980847 [release.debian.org] pre-approval: qutebrowser/2.0.0-1 Changed Bug title to 'pre-approval: qutebrowser/2.0.1-2' from 'pre-approval: qutebrowser/2.0.0-1'. -- 980847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980847 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
question regarding possible needed further action on package arduino
Hi there, after a month of concentrate work together with Rock Storm on the arduino package , and some related build depending packages the Debian Electronics Team is happy we have now an updated Arduino IDE package in unstable. https://tracker.debian.org/pkg/arduino The current migration checking says that the build on architecture all is missing. The arduino package now doesn't have an 'all' architecture package any more as we needed to melt all together into architecture related. So here is my question, do I need to contact the FTP Team to clear this non solvable dependency (I remember I needed something similar in the past for Thunderbird) or can this issue get managed by the RT? Thanks! -- Regards Carsten
Bug#981232: unblock: perl/5.32.1-1
Hi, On 28-01-2021 22:36, Dominic Hargreaves wrote: >> Would you have also asked us if you wouldn't have needed the binNMU's? > > Yes, since https://release.debian.org/bullseye/freeze_policy.html says > changes to build-essential may only be made with pre-approval... Right. Thank you, I should learn that list by heart. The pseudo excuses [1] report quite some autopkgtest regressions. Can you please check them, fix them if relevant or explain why they are not relevant for bullseye (e.g. unstable only)? Paul [1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl OpenPGP_signature Description: OpenPGP digital signature
Re: planning to upload binutils 2.35.2
Hi Matthias, On 29-01-2021 12:13, Matthias Klose wrote: >> We would be happy with either of the following: >> 1) upload to unstable with PR27218 only >> 2) upload to experimental first (with a 2.36+really2.35.2 version) to >> check all is fine. > > so I don't see what an upload for 2) would provide you with more information. I hope you would expect the test to pass instead of to fail to prove the failure with 2.36 is not to worry about for the changes you are proposing in 2.35.2. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-28 00:28:03 [+0100], Kurt Roeckx wrote: > On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote: > > There are a whole bunch of other issues and pull requests related to > > this. I hope this is the end of the regressions in the X509 code. > > So there is something else now: > https://github.com/openssl/openssl/issues/13931 > https://github.com/openssl/openssl/pull/13982 So what is the plan here? Upload to unstable and prepare a pu once it migrate to testing or right away? > Kurt Sebastian
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
On Fri, 29 Jan 2021, Adam D. Barratt wrote: > Control: tags -1 + confirmed > On Fri, 2021-01-29 at 13:27 -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote: > > The 3.20201118.1~deb10u1 version of the package (the one I am > > > proposing for the stable update) contains changes not (yet?) in > > > unstable to address the Skylake D0/R0 issue: they had their updates > > > frozen to the same revision currently in Debian stable. > > > > I better explain that in a more direct, clear way: > > Thanks. > > Please feel free to upload, bearing in mind that the window for 10.8 > closes during this weekend. Uploaded (source, i386, amd64). Thank you! -- Henrique Holschuh
Processed: Re: Bug#981345: buster-pu: package systemd/241-7~deb10u6
Processing control commands: > tags -1 + confirmed d-i Bug #981345 [release.debian.org] buster-pu: package systemd/241-7~deb10u6 Added tag(s) confirmed and d-i. -- 981345: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981345 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#981345: buster-pu: package systemd/241-7~deb10u6
Control: tags -1 + confirmed d-i Hi, On Fri, 2021-01-29 at 17:47 +0100, Michael Biebl wrote: > I'd like to make a stable upload for systemd fixing #975561: > > journal: do not trigger assertion when journal_file_close() get > NULL > > The rest is autopkgtest updates, as the current state is a bit sad > [1] on stable. That looks fine to me, thanks. > > CCed kibi/debian-boot, as usual. > The udev package should not be affected, as the above change only > affects the journal, which is not used in d-i. CCed and tagged for completeness. Regards, Adam
Processed: Re: Bug#981339: buster-pu: package device-tree-compiler/1.4.7-4
Processing control commands: > tags -1 + confirmed Bug #981339 [release.debian.org] buster-pu: package device-tree-compiler/1.4.7-4 Added tag(s) confirmed. -- 981339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981339 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#981339: buster-pu: package device-tree-compiler/1.4.7-4
Control: tags -1 + confirmed On Fri, 2021-01-29 at 16:31 +0100, Cyril Brulebois wrote: > I'd like to propose a fix for a dtc segfault in buster, which can > prevent people from checking what their device-tree looks like, > making it harder to debug why device-tree overlays don't work: > https://bugs.debian.org/981033 > Please go ahead, thanks. Regards, Adam
Processed: Re: Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
Processing control commands: > tags -1 + confirmed Bug #980962 [release.debian.org] buster-pu: package intel-microcode/3.20201118.1~deb10u1 Added tag(s) confirmed. -- 980962: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980962 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
Control: tags -1 + confirmed On Fri, 2021-01-29 at 13:27 -0300, Henrique de Moraes Holschuh wrote: > On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote: > The 3.20201118.1~deb10u1 version of the package (the one I am > > proposing for the stable update) contains changes not (yet?) in > > unstable to address the Skylake D0/R0 issue: they had their updates > > frozen to the same revision currently in Debian stable. > > I better explain that in a more direct, clear way: Thanks. Please feel free to upload, bearing in mind that the window for 10.8 closes during this weekend. Regards, Adam
Bug#981345: buster-pu: package systemd/241-7~deb10u6
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, k...@debian.org,
debian-b...@lists.debian.org
Hi,
I'd like to make a stable upload for systemd fixing #975561:
journal: do not trigger assertion when journal_file_close() get NULL
The rest is autopkgtest updates, as the current state is a bit sad [1]
on stable.
The full (annotated) changelog is
systemd (241-7~deb10u6) buster; urgency=medium
* journal: do not trigger assertion when journal_file_close() get NULL
(Closes: #975561)
https://salsa.debian.org/systemd-team/systemd/-/commit/42f62d560748cf79353d0a66d1ccf49517f951d3
* test-bpf: skip test when run inside containers.
The test reliably fails inside LXC and Docker when run on a new enough
kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
issue and apparently there is no real interest to get this fixed, so
let's skip this test.
https://salsa.debian.org/systemd-team/systemd/-/commit/de5350a0090a51ba391baf57e5d3e549bf126a6b
* autopkgtest: mark networkd-test.py as flaky.
See https://github.com/systemd/systemd/issues/18357
and https://github.com/systemd/systemd/issues/18196
https://salsa.debian.org/systemd-team/systemd/-/commit/996babe874059cc70f54f4edbd3e00a46a208bb7
CCed kibi/debian-boot, as usual.
The udev package should not be affected, as the above change only
affects the journal, which is not used in d-i.
The regression potential is rather low. The fix itself is a cherry-pick
from upstream and has been part of sid/testing since quite a while.
Regards,
Michael
[1] https://ci.debian.net/packages/s/systemd/
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 8c3b276..61dcee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+systemd (241-7~deb10u6) buster; urgency=medium
+
+ * journal: do not trigger assertion when journal_file_close() get NULL
+(Closes: #975561)
+ * test-bpf: skip test when run inside containers.
+The test reliably fails inside LXC and Docker when run on a new enough
+kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
+issue and apparently there is no real interest to get this fixed, so
+let's skip this test.
+ * autopkgtest: mark networkd-test.py as flaky.
+See https://github.com/systemd/systemd/issues/18357
+and https://github.com/systemd/systemd/issues/18196
+
+ -- Michael Biebl Fri, 29 Jan 2021 15:16:06 +0100
+
systemd (241-7~deb10u5) buster; urgency=medium
* basic/cap-list: parse/print numerical capabilities (Closes: #964926)
diff --git a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
index 231158c..78c2d01 100644
--- a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
+++ b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
@@ -30,7 +30,7 @@ index 2791678..3a9e20a 100644
systemd.journald.forward_to_syslog,
systemd.journald.forward_to_kmsg,
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index 2a960eb..7fe0f82 100644
+index ba0b35d..cd45212 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1835,6 +1835,7 @@ int server_init(Server *s) {
diff --git
a/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
new file mode 100644
index 000..9cb536b
--- /dev/null
+++
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
@@ -0,0 +1,46 @@
+From: Yu Watanabe
+Date: Tue, 28 May 2019 12:40:17 +0900
+Subject: journal: do not trigger assertion when journal_file_close() get NULL
+
+We generally expect destructors to not complain if a NULL argument is passed.
+
+Closes #12400.
+
+(cherry picked from commit c377a6f3ad3d9bed4ce7e873e8e9ec6b1650c57d)
+---
+ src/journal/journal-file.c| 3 ++-
+ src/journal/journald-server.c | 7 ++-
+ 2 files changed, 4 insertions(+), 6 deletions(-)
+
+diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
+index 56827f9..04cf1ef 100644
+--- a/src/journal/journal-file.c
b/src/journal/journal-file.c
+@@ -335,7 +335,8 @@ bool journal_file_is_offlining(JournalFile *f) {
+ }
+
+ JournalFile* journal_file_close(JournalFile *f) {
+-assert(f);
++if (!f)
++
Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1
On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote: Regressions were indeed reported (as expected). A few days ago, Intel > published relevant information pinpointing the regression on Skylake D0 > and Skylake R0 processors to specific conditions (detailed below for > completeness). > > The 3.20201118.1~deb10u1 version of the package (the one I am proposing > for the stable update) contains changes not (yet?) in unstable to > address the Skylake D0/R0 issue: they had their updates frozen > to the same revision currently in Debian stable. I better explain that in a more direct, clear way: The reason why I want to update the package in stable is: the updated microcode in this package have security mitigations for a few newer speculative execution sidechannel attacks, and fix some critical defects/"errata" on many recent processor models, *other than Skylake R0/D0*. The s-p-u version of the intel-microcode package I am proposing has *less* changes than the packages currently in unstable/testing. The microcode updates have been tested in unstable since 2020-12-27, and in testing since 2020-01-02. Issues with it were reported in Ubuntu and Arch Linux, for specific system vendors and computer models (not processor models -- i.e. it does not look like a general issue with the microcode updates) when running outdated firmware. A *general* microcode update issue was reported only for Skylake D0/R0. The offending microcode changes for Skylake D0/R0 are *reverted* in this s-p-u package. To do that, the package keeps the microcode for these two processor models *exactly the same* as they already are in Debian stable. The package changes when compared to the packages currently in Debian stable are: 1. microcode binary data (except for Skylake D0 and R0) 2. upstream documentation 3. Debian metadata (changelog, version). Thanks! -- Henrique Holschuh
Bug#981339: buster-pu: package device-tree-compiler/1.4.7-4
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to propose a fix for a dtc segfault in buster, which can
prevent people from checking what their device-tree looks like,
making it harder to debug why device-tree overlays don't work:
https://bugs.debian.org/981033
Case in point, I was following this upstream doc and thought maybe
I should be using the in-tree (linux.git) dtc executable instead,
which was a red herring:
https://www.raspberrypi.org/documentation/configuration/device-tree.md
As Héctor pointed out, there's an unaffected package available in
buster-backports, but I thought it would be worth it to fix the
package in buster proper as well, and Héctor is fine with my
handling that.
I've tested the patched package successfully, in a buster/arm64
environment (Pi3-like environments).
Changelog entry (there was no -4 upload to the archive):
device-tree-compiler (1.4.7-4) buster; urgency=medium
* Fix segfault on “dtc -I fs /proc/device-tree” by backporting
9619c8619c, first released in 1.5.0 (Closes: #981033). With huge
thanks to Uwe Kleine-König for the debugging and general guidance:
- 03-Kill-bogus-TYPE_BLOB-marker-type.patch
* Adjust gbp configuration for the buster branch.
-- Cyril Brulebois Wed, 27 Jan 2021 19:53:55 +0100
Full source debdiff attached.
Thanks for your time!
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru device-tree-compiler-1.4.7/debian/changelog
device-tree-compiler-1.4.7/debian/changelog
--- device-tree-compiler-1.4.7/debian/changelog 2018-09-11 09:51:07.0
+0200
+++ device-tree-compiler-1.4.7/debian/changelog 2021-01-27 19:53:55.0
+0100
@@ -1,3 +1,13 @@
+device-tree-compiler (1.4.7-4) buster; urgency=medium
+
+ * Fix segfault on “dtc -I fs /proc/device-tree” by backporting
+9619c8619c, first released in 1.5.0 (Closes: #981033). With huge
+thanks to Uwe Kleine-König for the debugging and general guidance:
+ - 03-Kill-bogus-TYPE_BLOB-marker-type.patch
+ * Adjust gbp configuration for the buster branch.
+
+ -- Cyril Brulebois Wed, 27 Jan 2021 19:53:55 +0100
+
device-tree-compiler (1.4.7-3) unstable; urgency=medium
* Add Build-Depends on pkg-config, which is used to check for valgrind.
diff -Nru device-tree-compiler-1.4.7/debian/gbp.conf
device-tree-compiler-1.4.7/debian/gbp.conf
--- device-tree-compiler-1.4.7/debian/gbp.conf 2018-09-11 07:47:55.0
+0200
+++ device-tree-compiler-1.4.7/debian/gbp.conf 2021-01-27 19:50:38.0
+0100
@@ -1,6 +1,6 @@
[DEFAULT]
pristine-tar = True
debian-tag = debian/%(version)s
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
patch-numbers = False
diff -Nru
device-tree-compiler-1.4.7/debian/patches/03-Kill-bogus-TYPE_BLOB-marker-type.patch
device-tree-compiler-1.4.7/debian/patches/03-Kill-bogus-TYPE_BLOB-marker-type.patch
---
device-tree-compiler-1.4.7/debian/patches/03-Kill-bogus-TYPE_BLOB-marker-type.patch
1970-01-01 01:00:00.0 +0100
+++
device-tree-compiler-1.4.7/debian/patches/03-Kill-bogus-TYPE_BLOB-marker-type.patch
2021-01-27 19:49:45.0 +0100
@@ -0,0 +1,139 @@
+From ec8c8cd0fd71d33da07d388d391e6211bef5d757 Mon Sep 17 00:00:00 2001
+From: Greg Kurz
+Date: Thu, 30 Aug 2018 12:01:59 +0200
+Subject: [PATCH] Kill bogus TYPE_BLOB marker type
+
+Since commit 32b9c6130762 "Preserve datatype markers when emitting dts
+format", we no longer try to guess the value type. Instead, we reuse
+the type of the datatype markers when they are present, if the type
+is either TYPE_UINT* or TYPE_STRING.
+
+This causes 'dtc -I fs' to crash:
+
+Starting program: /root/dtc -q -f -O dts -I fs /proc/device-tree
+/dts-v1/;
+
+/ {
+
+Program received signal SIGSEGV, Segmentation fault.
+__strlen_power8 () at ../sysdeps/powerpc/powerpc64/power8/strlen.S:47
+47 ld r12,0(r4) /* Load doubleword from memory. */
+(gdb) bt
+#0 __strlen_power8 () at ../sysdeps/powerpc/powerpc64/power8/strlen.S:47
+#1 0x77de3d10 in __GI__IO_fputs (str=,
+fp=) at iofputs.c:33
+#2 0x1000c7a0 in write_propval (prop=0x100525e0,
+f=0x77f718a0 <_IO_2_1_stdout_>) at treesource.c:245
+
+The offending line is:
+
+fprintf(f, "%s", delim_start[emit_type]);
+
+where emit_type is TYPE_BLOB and:
+
+static const char *delim_start[] = {
+[TYPE_UINT8] = "[",
+[TYPE_UINT16] = "/bits/ 16 <",
+[TYPE_UINT32] = "<",
+[TYPE_UINT64] = "/bits/ 64 <",
+[TYPE_STRING] = "",
+};
+
+/* Data blobs */
+enum markertype {
+TYPE_NONE,
+REF_PHANDLE,
+REF_PATH,
+LABEL,
+TYPE_UINT8,
+TYPE_UINT16,
+TYPE_UINT32,
+TYPE_UINT64,
+TYPE_BLOB,
+TYPE_STRING,
+};
+
+Because TYPE_BLOB < TYPE_STRING and delim_start[] is a static array,
Bug#981232: unblock: perl/5.32.1-1
On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote: > Hi Dominic, > > On 28-01-2021 22:05, Dominic Hargreaves wrote: > >>> 5.32.1 would need a binnmu of a few leaf packages > >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl > >>> libcommon-sense-perl) as usual. > >> > >> Just to be clear, these binNMU's would be needed too if we would go for > >> the cherry-pick option? > > > > No, the binaries relate to a change of upstream version number > > which ends up being encoded in these packages. If we cherry pick > > fixes, the binNMUs wouldn't be needed. > > But then, that relation is strictly speaking too tight? Is that > something that can be improved (without jumping through hoops)? Maybe > not for this time, but for future changes. Normally perl packages look > for the perl-something-api right? Which would make it clear that this is > no transition. There's a reason for each of them of course. libpar-packer-perl (#551356) would definitely involve jumping through hoops. It's the worst one of the four I think and really requires a tight dependency. The version skew warning in libdevel-cover-perl (#562214) could probably be patched away easily, but that seems a bit risky to me. Presumably upstream has a reason for the check. I'm not sure if we've ever asked though, and OTOH autopkgtest runs should notice if the newer Perl version breaks something. For libcommon-sense-perl, I quote #722332: > Not sure if all the internals that common::sense fiddles with are under > the 'no ABI changes in minor Perl version updates' promise. I suspect they > are, but we might still be best off rebuilding it even for minor updates. libclass-xsaccessor-perl only has this changelog entry: * Add dependency on same upstream version of perl to make sure #define PERL_CORE never breaks things. [...] -- Ansgar Burchardt Wed, 18 Aug 2010 13:21:04 +0900 Not sure if that one could be relaxed but keeping it tight seems prudent to me. As Dominic said, the related binNMUs have not been much of an issue in the past. -- Niko Tyni nt...@debian.org
Re: planning to upload binutils 2.35.2
On 1/28/21 8:36 PM, Paul Gevers wrote: > Hi Matthias, > > On 27-01-2021 22:42, Matthias Klose wrote: >> I have been following the way the linux source package was uploaded. >> Apparently >> the package entered unstable with just an announcement like this. And more >> than >> one time. > > For linux there was alignment, but see below. > >>> So, can you please clarify why you think these changes are needed? What >>> are the risks of including or not including these changes? How are the >>> risks mitigated? >> >> staging in experimental is not possible, unless you remove 2.36, or override >> it >> bumping the epoch. > > (or a +really version number). > >> - PR27218 is an obvious bug fix, avoiding a segfault. >> - DWARF5 is not enabled by default, the DWARF5 fixes are >>required for GCC 11 defaulting to use DWARF5. And no, >>I'm not planning to upload gcc-11 to unstable. >> >> I'm very unhappy about the private decision making for some uploads, while >> showing a pedantic attitude towards others. > > I must confess that indeed the alignment with the Release Team on linux > uploads happened in private. It shouldn't have, or at least the outcome > should have been public. > >> - PR27218 is an obvious bug fix, avoiding a segfault. > > Sound OK to have. > >> - DWARF5 is not enabled by default, the DWARF5 fixes are >>required for GCC 11 defaulting to use DWARF5. > > https://release.debian.org/britney/pseudo-excuses-experimental.html#binutils > (for 2.36-1) shows a regression for glibc. Hence we're not totally > confident. If it's not the default, why do we want this feature now? the log ends with: 8<8<8<- WARNING: log file truncated at 20 MB (before compression) 8<8<8<- autopkgtest [01:21:39]: summary rebuild FAIL non-zero exit status 2 > We would be happy with either of the following: > 1) upload to unstable with PR27218 only > 2) upload to experimental first (with a 2.36+really2.35.2 version) to > check all is fine. so I don't see what an upload for 2) would provide you with more information.
