Bug#1068033: bookworm-pu: package gross/1.0.2-4.1~deb12u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Antonio Radici , t...@security.debian.org

  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)

This CVE is marked no-dsa.

Building with the bookworm debhelper adds a preinst due to #1021027.
diffstat for gross-1.0.2 gross-1.0.2

 changelog|   14 
 patches/0001-fix-misuse-of-strncat.patch |   95 +++
 patches/series   |1 
 3 files changed, 110 insertions(+)

diff -Nru gross-1.0.2/debian/changelog gross-1.0.2/debian/changelog
--- gross-1.0.2/debian/changelog2014-10-25 11:20:12.0 +0300
+++ gross-1.0.2/debian/changelog2024-03-29 22:52:55.0 +0200
@@ -1,3 +1,17 @@
+gross (1.0.2-4.1~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+
+ -- Adrian Bunk   Fri, 29 Mar 2024 22:52:55 +0200
+
+gross (1.0.2-4.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)
+
+ -- Adrian Bunk   Sat, 23 Mar 2024 23:23:34 +0200
+
 gross (1.0.2-4) unstable; urgency=low
 
   * debian/README: fixed a typo (Closes: 670596)
diff -Nru gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 
gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch
--- gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 1970-01-01 
02:00:00.0 +0200
+++ gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 2024-03-23 
23:23:34.0 +0200
@@ -0,0 +1,95 @@
+From ec697f4dd5b057ad5af17468dac7955f3d1c03c6 Mon Sep 17 00:00:00 2001
+From: Dmitry Mikhirev 
+Date: Wed, 27 Dec 2023 03:42:29 +0400
+Subject: fix misuse of strncat
+
+---
+ src/gross.c  | 11 ---
+ src/worker.c | 21 -
+ 2 files changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/src/gross.c b/src/gross.c
+index 6e1a277..f477845 100644
+--- a/src/gross.c
 b/src/gross.c
+@@ -111,7 +111,9 @@ configure_grossd(configlist_t *config)
+   configlist_t *cp;
+   const char *updatestr;
+   struct hostent *host = NULL;
+-  char buffer[MAXLINELEN] = { '\0' };
++  char buffer[MAXLINELEN];
++  char *lineend;
++  size_t len;
+   params_t *pp;
+ 
+   cp = config;
+@@ -119,11 +121,14 @@ configure_grossd(configlist_t *config)
+   while (cp) {
+   pp = cp->params;
+   *buffer = '\0';
++  lineend = buffer;
++  len = 0;
+   while (pp) {
+-  strncat(buffer, " ; ", MAXLINELEN - 1);
+-  strncat(buffer, pp->value, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, 
" ; %s", pp->value);
++  lineend = buffer + len;
+   pp = pp->next;
+   }
++  buffer[MAXLINELEN - 1] = '\0';
+   logstr(GLOG_DEBUG, "config: %s = %s%s", cp->name, 
cp->value, buffer);
+   cp = cp->next;
+   }
+diff --git a/src/worker.c b/src/worker.c
+index 24f104b..63c0f06 100644
+--- a/src/worker.c
 b/src/worker.c
+@@ -618,7 +618,8 @@ void
+ querylogwrite(querylog_entry_t *q)
+ {
+   char line[MAXLINELEN];
+-  char buffer[MAXLINELEN];
++  size_t len = 0;
++  char *lineend = line;
+   char *actionstr;
+   check_match_t *m;
+ 
+@@ -655,25 +656,27 @@ querylogwrite(querylog_entry_t *q)
+   if (NULL == q->recipient)
+   q->recipient = "N/A";
+ 
+-  snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,
+-  q->client_ip, q->sender, q->recipient);
++  len += snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,  q->client_ip, q->sender, q->recipient);
++  lineend = line +len;
+ 
+   if (q->helo) {
+-  snprintf(buffer, MAXLINELEN - 1, " h=%s", q->helo);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " h=%s", 
q->helo);
++  lineend = line + len;
+   }
+ 
+   m = q->match;
+   while (m) {
+-  snprintf(buffer, MAXLINELEN - 1, " m=%s", m->name);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " m=%s", 
m->name);
++  lineend = line + len;
+   if (m->weight) {
+-  snprintf(buffer, MAXLINELEN - 1, "%+d", m->weight);
+-  strncat(line, buffer, MAXLINEL

Bug#1068034: bullseye-pu: package gross/1.0.2-4.1~deb11u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Antonio Radici , t...@security.debian.org

  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)

This CVE is marked no-dsa.
diffstat for gross-1.0.2 gross-1.0.2

 changelog|   14 
 patches/0001-fix-misuse-of-strncat.patch |   95 +++
 patches/series   |1 
 3 files changed, 110 insertions(+)

diff -Nru gross-1.0.2/debian/changelog gross-1.0.2/debian/changelog
--- gross-1.0.2/debian/changelog2014-10-25 11:20:12.0 +0300
+++ gross-1.0.2/debian/changelog2024-03-29 23:02:44.0 +0200
@@ -1,3 +1,17 @@
+gross (1.0.2-4.1~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+
+ -- Adrian Bunk   Fri, 29 Mar 2024 23:02:44 +0200
+
+gross (1.0.2-4.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)
+
+ -- Adrian Bunk   Sat, 23 Mar 2024 23:23:34 +0200
+
 gross (1.0.2-4) unstable; urgency=low
 
   * debian/README: fixed a typo (Closes: 670596)
diff -Nru gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 
gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch
--- gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 1970-01-01 
02:00:00.0 +0200
+++ gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 2024-03-23 
23:23:34.0 +0200
@@ -0,0 +1,95 @@
+From ec697f4dd5b057ad5af17468dac7955f3d1c03c6 Mon Sep 17 00:00:00 2001
+From: Dmitry Mikhirev 
+Date: Wed, 27 Dec 2023 03:42:29 +0400
+Subject: fix misuse of strncat
+
+---
+ src/gross.c  | 11 ---
+ src/worker.c | 21 -
+ 2 files changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/src/gross.c b/src/gross.c
+index 6e1a277..f477845 100644
+--- a/src/gross.c
 b/src/gross.c
+@@ -111,7 +111,9 @@ configure_grossd(configlist_t *config)
+   configlist_t *cp;
+   const char *updatestr;
+   struct hostent *host = NULL;
+-  char buffer[MAXLINELEN] = { '\0' };
++  char buffer[MAXLINELEN];
++  char *lineend;
++  size_t len;
+   params_t *pp;
+ 
+   cp = config;
+@@ -119,11 +121,14 @@ configure_grossd(configlist_t *config)
+   while (cp) {
+   pp = cp->params;
+   *buffer = '\0';
++  lineend = buffer;
++  len = 0;
+   while (pp) {
+-  strncat(buffer, " ; ", MAXLINELEN - 1);
+-  strncat(buffer, pp->value, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, 
" ; %s", pp->value);
++  lineend = buffer + len;
+   pp = pp->next;
+   }
++  buffer[MAXLINELEN - 1] = '\0';
+   logstr(GLOG_DEBUG, "config: %s = %s%s", cp->name, 
cp->value, buffer);
+   cp = cp->next;
+   }
+diff --git a/src/worker.c b/src/worker.c
+index 24f104b..63c0f06 100644
+--- a/src/worker.c
 b/src/worker.c
+@@ -618,7 +618,8 @@ void
+ querylogwrite(querylog_entry_t *q)
+ {
+   char line[MAXLINELEN];
+-  char buffer[MAXLINELEN];
++  size_t len = 0;
++  char *lineend = line;
+   char *actionstr;
+   check_match_t *m;
+ 
+@@ -655,25 +656,27 @@ querylogwrite(querylog_entry_t *q)
+   if (NULL == q->recipient)
+   q->recipient = "N/A";
+ 
+-  snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,
+-  q->client_ip, q->sender, q->recipient);
++  len += snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,  q->client_ip, q->sender, q->recipient);
++  lineend = line +len;
+ 
+   if (q->helo) {
+-  snprintf(buffer, MAXLINELEN - 1, " h=%s", q->helo);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " h=%s", 
q->helo);
++  lineend = line + len;
+   }
+ 
+   m = q->match;
+   while (m) {
+-  snprintf(buffer, MAXLINELEN - 1, " m=%s", m->name);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " m=%s", 
m->name);
++  lineend = line + len;
+   if (m->weight) {
+-  snprintf(buffer, MAXLINELEN - 1, "%+d", m->weight);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN 

Re: What to do with d-i on armel?

[Adrian Bunk]

On Mon, Mar 04, 2024 at 09:52:14AM +0100, Gerardo Ballabio wrote:
> Gianluca Renzi wrote:
> > The same here. We never used the d-i but we are using Debian systems 
> > (kernel and root file system) as daily bases of our line of products 
> > embedded systems. Hundred of thousands of boards are using Debian since 
> > Debian Lenny 5.0. From armel to armhf 32 bit systems.
> > So a drop of the armel and/or armhf will force us to a very complicated 
> > rearrangement of our build systems.
> > Please don't do that if you can.
> 
> Hi Gianluca,
> if that is so important for your business, you might consider
> sponsoring some work on this issue.
> The Debian Long Term Support project
>  is about keeping "old stuff"
> working so that might be the right place to ask.

That's not the right place, LTS is about keeping *old Debian versions*
security supported for 2 additional years (and has dropped armel since stretch).

LTS is not doing anything at all regarding keeping older/unusual 
hardware supported, such work has to be done directly in Debian
(and upstream).

> Gerardo

cu
Adrian

Bug#1036884: transition: time64_t

[Adrian Bunk]

On Sat, Mar 02, 2024 at 02:16:59PM +0100, Sebastian Ramacher wrote:
> On 2024-03-02 15:06:15 +0200, Adrian Bunk wrote:
> > On Fri, Mar 01, 2024 at 11:10:22PM -0800, Steve Langasek wrote:
> > >...
> > > This needs to be built with dpkg-dev (>= 1.5.22), ...
> > >...
> > 
> > The correct version is 1.22.5 (and >= 1.5.22 therefore a nop).
> 
> There was already an upload by the maintainer correcting the issue.

This incorrect version seems to be pasted further, e.g. glib2.0 
extra-depends have (in addition to the now corrected missing 'd')
also the nop version 1.5.22

> Cheers

cu
Adrian

Bug#1036884: transition: time64_t

[Adrian Bunk]

On Fri, Mar 01, 2024 at 11:10:22PM -0800, Steve Langasek wrote:
>...
> This needs to be built with dpkg-dev (>= 1.5.22), ...
>...

The correct version is 1.22.5 (and >= 1.5.22 therefore a nop).

cu
Adrian

Re: chromium and rustc in bookworm

[Adrian Bunk]

On Sun, Jan 21, 2024 at 06:55:31PM -0500, Andres Salomon wrote:
>...
> b) Backport the profiler patch to bookworm's rustc, and do a s-p-u update to
> Bookworm's rustc. Since this adds a new feature, I don't view it as too
> risky, but the release team or rust team may feel differently. The main
> downsides to this are the potential for breaking existing packages in
> stable, and the fact that Chromium will undoubtedly begin to rely on newer
> Rust language features (as they do with Clang) which may not work on
> bookworm's 1.63.0. Once that happens, we'll be right back here.
> 
> c) Much like the Firefox maintainer(s) created rustc-mozilla for
> (old)oldstable, we create a 'rustc-chromium' package for bookworm. It could
> even be used for Firefox if their ESR updates start needing newer Rust
> language features (in which case, maybe 'rustc-newer' or 'rustc-browsers' is
> a better name for it? Or like Clang, include the major version and call it
> 'rustc-1.70').
> 
> 
> As I'm still messing around with bookworm's rustc(+profiler) as well as
> trying to get Chromium 121.x to build in Sid, I don't have a strong opinion
> on this yet. However, I wanted to bring it to everyone's attention, and see
> if anyone else did have strong opinions either way. If one of the teams
> feels strongly against option (b) for example, I won't bother continuing to
> work on that option.

IMHO c) would be best, with one rustc-* package shared for both browsers.

AFAIK rustc 1.78 (to be released in May) will be required by the next 
Firefox ESR 128, and bookworm will switch to 128 in September/October.

The annual rustc upgrade for Firefox in *stable does also require an 
annual addition of a new LLVM version in *stable.

Short-term a version of the bookworm rustc with the profiler patch you 
need could then be uploaded as a first version of this rustc-browsers
(or however it is named) package.

The critical question is whether the annual LLVM+rustc upgrade cadence 
for Firefox in stable is compatible with what Chromium needs.

> Thanks,
> Andres

cu
Adrian

BTW:
I am not personally involved in any of the mentioned packages, just 
pointing out what seems to be the least work while avoiding even more
rustc and LLVM versions in stable releases.

Re: Bug#1060188: transition: flatbuffers

[Adrian Bunk]

On Sun, Jan 21, 2024 at 06:58:37PM -0500, Mo Zhou wrote:
> 
> On 1/21/24 10:54, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > Should those that are not part of the transition tracker use the shared
> > library or not?
> flatbuffers is like protobuf. I'm not sure how many rdeps among the list
> links against it statically.

Not related specifically to this transition, but this likely means that 
the same issue as #1031716 exists, dependencies on python3-flatbuffers
are not strict enough to ensure matching the version of flatbuffers-compiler?

cu
Adrian

Re: openjdk-8 vs. nvidia-openjdk-8-jre

[Adrian Bunk]

On Fri, Jan 19, 2024 at 11:43:11AM +0100, Andreas Beckmann wrote:
>...
> And having openjdk-8-* installed manually should not satisfy the openjdk
> (build) dependency of any package in the archive via virtual packages.

We already have two OpenJDK version (17 and 21) in bookworm.

Everything should be fine if:
- default-jre* is always the first alternative in the dependencies, and
- everything requiring > 8 depends on a java*-runtime* >= java9-runtime*

I'm not expecting these things to be 100% bug-free, but such things 
would already blow up today when someone still has a JRE from an older 
release installed (e.g. I was for some time using the security-supported 
openjdk-8/stretch on buster for a usecase where OpenJDK 11 did not work).

> Andreas

cu
Adrian

Re: Ability to further support 32bit architectures

[Adrian Bunk]

On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
> 
> Okay, maybe more workarounds exist.  But none of them look really
> promising.
>...

gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.

But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.

> Bastian

cu
Adrian

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Sat, Dec 23, 2023 at 03:55:15PM -0700, Soren Stoutner wrote:
>...
> In a hypothetical world where Qt 6.2 LTS had shipped with bookworm, we could
> build any Qt WebEngine from 6.2, 6.3, or 6.4 against it without problem.
> Initially it might seem best to build the highest possible, but because 6.4
> updates end a full year before 6.2 LTS updates, it would be best for stable
> support if we stuck with 6.2 as long as possible.
>...

When Qt WebEngine from 6.5 is officially backportable to 6.2,
then backporting it to versions between 6.2 and 6.5 is unlikely
to be a problem.

Backporting even more recent versions to 6.4 would be expected to be 
easier than backporting to 6.2, since 6.4 is closer to what gets 
backported and backporting problems tend to increase when the 
backporting distance increases since the code differences increase.

>...
> If it ends up not being feasible to backport the entire Qt WebEngine from
> the next LTS release, then we could look at cherry-picking all of the
> security commits. This would be, by far, the most time-intensive solution.
> But, as your point out, the security fixes on the Chromium side are well
> marked. And, generally, they are small commits that only modify a few lines.
> For example:
>...

Your "generally" is not true, it misses the biggest problem.
 
Out of 20 CVEs there might be 19 easy ones, plus one that is a quite 
invasive patch requiring a lot of backporting work.

Who has both the required skills and a reliable commitment today for 
doing in the year 2027 an urgent backport of a complex fix for a 
zero-day vulnerability that is already being exploited in the wild?

> Soren Stoutner

cu
Adrian

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Sat, Dec 16, 2023 at 04:33:58PM -0700, Soren Stoutner wrote:
> On Saturday, December 16, 2023 4:10:42 PM MST Adrian Bunk wrote:
> > On Sat, Dec 16, 2023 at 01:22:13PM -0700, Soren Stoutner wrote:
> > > Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but
> > > 5.15.13+dfsg-1~deb12u1 was later uploaded.
> >
> > That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1.
>
> How does stable initially release with an ~deb12u1?

On Sat, Dec 16, 2023 at 06:00:28PM -0700, Soren Stoutner wrote:
> Digging into this a little further, it looks like the current version of 
> Angelfish does not use 
> any Qt WebEngine private headers (qtwebengine5-private-dev is not listed as a 
> build-
> depends).

I don't know what's going on with the headers, but there is a reason why 
the dependency gets generated:

$ nm -D /usr/bin/angelfish-webapp | grep Qt_5_PRIVATE_API
 U 
_ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API
 U 
_ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API
$ 

You are jumping to conclusions too fast without double-checking things,
which is not a good sign for someone who wants to provide security support
for what is perhaps the most difficult to support package in Debian.

That's also true for the whole effort:

Everyone who has looked at this before came to the conclusion that 
security support for browser engines is no longer possible on a
volunteer basis in Debian since it is:
- a lot of work for many CVEs, and
- requires deep technical skills of the browser engine
  (How much experience do you have modifying the Blink code?), and
- backporting fixes to ancient versions of software is sometimes easy
  but sometimes the kind of nasty work most people won't do unpaid

It is not fundamentally impossible, but it's in the order of magnitude 
of one full-time employed Blink engineer.

>...
> Now that is all cleared up, I think that next week I am going to build the 
> current version 
> of Qt 5 WebEngine for stable and test it on a system I have running locally, 
> focusing 
> specifically on all of the browsers that use Qt WebEngine.  If all seems to 
> work well, would 
> anyone have any objections to me uploading it to bookworm-backports?
>...

bookworm-backports are packages from trixie rebuilt for bookworm.

Whatever you want to do in backports, it has to go into unstable und 
migrate to testing first.

cu
Adrian

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Sat, Dec 16, 2023 at 01:22:13PM -0700, Soren Stoutner wrote:
>...
> Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but 
> 5.15.13+dfsg-1~deb12u1 was later uploaded.
>...

That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1.

> At this point, the biggest remaining question is what is the private header 
> that angelfish is using in Qt WebEngine and why?
>...

No matter what angelfish does, qtwebview-opensource-src will in any case 
also need a rebuild.

> Thanks,
> 
> Soren

cu
Adrian

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Thu, Dec 14, 2023 at 05:29:43PM -0700, Soren Stoutner wrote:
> On Thursday, December 14, 2023 4:19:17 PM MST Adrian Bunk wrote:
> 
> > Non-LTS oldstable is the 3rd year of stable security support,
> > this is required for giving users time to schedule the invasive
> > upgrades to a new Debian stable at a convenient time.
> >
> > LTS oldstable (after regular security support has ended) is a paid
> > endeavour outside the scope of what Debian volunteers are expected
> > to support.
> 
> That is a good point. However, I consider full coverage of security support
> for stable to be an improvement over the current situation. Explicitly
> stating that security support is not shipped for oldstable does not do any
> more harm to users than what we currently do by explicitly stating that
> security support is not shipped for either stable or oldstable.

>From a policy point of view, the duration of security support is a 
Debian-wide policy and not a per-package policy.

>From a user point of view, an organization/company running Debian on 
their user/employee desktops would not schedule upgrades to a new 
stable on release day - 1 year of migration time is really necessary.

>From a security point of view, providing updates would be an improvement.
E.g. upgrading Qt5 WebEngine in bullseye and bookworm to 5.15.15 in 
point releases might already be an option.
But that's different from calling something security supported, which
could do more harm than good by giving users a false sense of security
instead of looking for alternatives.

> > By calling this "doable" you are demonstrating that you do not fully
> > grasp why browser engines are considered unsupportable.
> >
> > In recent years, chromium had on average more than 1 CVE per day:
> > https://security-tracker.debian.org/tracker/source-package/chromium
> 
> That is true. However, not all of those bugs apply to Qt WebEngine.
>...
> A number of these patches would apply to an older LTS without modification.
> Some would need minor modifications. Some would not apply to an older LTS
> because they are fixing problems in features that were released after the
> LTS. And some would require significant effort to backport.
> 
> Additionally, a number of recent high-profile Chromium vulnerabilities have
> been in third-party libraries and not in Chromium itself.
>...

Part of the problem is that "some would require significant effort" 
might end up meaning that 5% of the CVEs take 95% of the time.

There might be a 0-day vulnerability that is already being exploited by 
nation-state actors where they had to rewrite half the browser to fix it.

>...
> Considering all of the above, handling security support in stable would
> obviously be a lot of work, but to me it feels like it is in the realm of
> what is doable.

Providing security support by backporting fixes to Qt WebEngine feels to 
me more like in the realm of one full-time employed Blink engineer.

It would be both a lot of work and requires relevant skills from the 
people doing it.

> Particularly if there was assistance by a team of interested people.

For trixie, you would need people who reliably commit in 2024 to doing
a lot of work in 2026-2028.

Even your "no support for oldstable" would keep you busy in the first 
half of 2027. What is your track record in Debian of still being active
several years later?

You are also vastly overestimating the number of people available for 
such work in Debian. Debian has few very active people, sometimes 
literally (co)maintaining > 1000 packages, but most people are only 
maintaining one or few packages. Qt6 has ~ 2 active maintainers,
and many key areas/packages of Debian have a single person.

Realistically, your effort would be a team with one member.

> Soren Stoutner

cu
Adrian

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Thu, Dec 14, 2023 at 12:48:08PM -0700, Soren Stoutner wrote:
>...
> This plan does not address oldstable security support.
>...

Non-LTS oldstable is the 3rd year of stable security support,
this is required for giving users time to schedule the invasive
upgrades to a new Debian stable at a convenient time.

LTS oldstable (after regular security support has ended) is a paid 
endeavour outside the scope of what Debian volunteers are expected
to support.

>...
> 3. When the LTS in stable is no longer supported, security patches can be
> backported from the current LTS to the one in stable.
> 
> This sounds like a doable amount of security work and I would be willing to
> undertake it.
>...

By calling this "doable" you are demonstrating that you do not fully 
grasp why browser engines are considered unsupportable.

In recent years, chromium had on average more than 1 CVE per day:
https://security-tracker.debian.org/tracker/source-package/chromium

> Soren Stoutner

cu
Adrian

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Wed, Dec 13, 2023 at 08:49:55PM -0700, Soren Stoutner wrote:
>...
> Currently there is no real security support for Qt WebEngine in stable, which 
> is an oversight that might surprise many Debian users.  The purpose of this 
> discussion is to figure out the best way to change that.

This is not a new discussion, and there aren't any simple solutions.
The release notes for squeeze[1] released nearly 13 years ago already 
had a section on limited support for browser engines.

For web browsers, shipping the latest versions is the only workable solution.

WebKitGTK is basically the GNOME equivalent of Qt WebEngine based on a 
different browser. Security support for WebKitGTK was also missing for
many years, it became feasible when upstream made commitments regarding
API/ABI compatibility and sticking to using older versions of dependencies.

Qt has nearly 30 years history of being somewhere between open source 
and freemium,[2] this is not an upstream one would expect to make such
commitments.

> Shipping LTS versions
> of Qt in stable would put us in a better position than the status quo, even if
> it doesn’t get us all the way there.  
>...

When a suitable version is available updating in (old)stable might be 
possible, e.g. updating qtwebengine-opensource-src in stable and 
oldstable might be technically feasible and rebuilding angelfish would 
be unlikely to be a dealbreaker if someone wants to discuss such a 
(tested!) update with the release team. The release team might or might
not agree with such an update, but this would not be the same as 
providing security support for qtwebengine-opensource-src.

Your "better position" might actually be worse, far more surprising than
flagging something as unsupported from the beginning would be declaring
it supported and then dropping support after a year - what are users
supposed to do at that point?

cu
Adrian

[1] https://www.debian.org/releases/squeeze/amd64/release-notes.en.txt
[2] https://en.wikipedia.org/wiki/Qt_(software)#History_of_Qt

Re: Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk]

On Wed, Dec 13, 2023 at 02:19:04PM -0700, Soren Stoutner wrote:
>...
> How feasible would it be to make sure that stable always ships with paired 
> LTS releases of 
> KDE and Qt?  As you point out above, those release windows might not line up 
> exactly with 
> Debian’s release window, but it seems like it would be an improvement on the 
> current 
> situation.
>...

What's the benefit of using upstream-supported LTS releases?
Debian stable would would anyway not follow upstream point releases
with rare exceptions like browser engines.

> If you don’t think it is feasible to ship LTS versions of KDE and Qt in 
> stable, how do you 
> propose handling proper security support for KDE and Qt?
>...

Backporting CVE fixes for these packages, as has already been done for 
many years.

Except for the browser engines, CVEs have been few and fixes easy to backport.

Security support for the 3 years non-LTS support of Debian stable 
releases is not realistically possible for Qt WebEngine unless this
is offered by upstream in an API/ABI compatible way without requiring
newer dependencies (WebKitGTK has such upstream support).

cu
Adrian

Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))

[Adrian Bunk]

On Wed, Dec 13, 2023 at 11:43:56AM +0100, Andreas Tille wrote:
>...
> I'm worried
> about issues in r-rcan-rmarkdown[3] and r-cran-flextable[4] which are
> caused by pandoc errors on ppc64el architecture *only*.  That's really
> strange and might mean that pandoc on this architecture is broken?
>...

ppc64el has Lua support disabled[1] due to [2] (#1057857),
AFAIK that's the last non-trivial issue of the Haskell transition.

I haven't confirmed that this is related, but that would be my first 
guess for the ppc64el-only [3] in pandoc.

> Kind regards
>   Andreas.
>...

cu
Adrian

[1] https://tracker.debian.org/media/packages/p/pandoc/control-3.0.1ds-3
[2] https://buildd.debian.org/status/package.php?p=haskell-lua
[3] https://tracker.debian.org/pkg/pandoc

Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)

[Adrian Bunk]

On Thu, Dec 07, 2023 at 09:38:47PM +0100, Salvatore Bonaccorso wrote:
>...
> Hmm technically likely right, but in security we cannot very well
> handle the binNMUs (only if the source is already present there,
> otherwise ftp-masters need to inject the sources first).
> 
> This is related to
> https://wiki.debian.org/DebianSecurity/AdvisoryCreation/SecFull?highlight=%28gen-DSA%29#BinNMUs
> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823820 (well
> more broadly to have source available).

This shouldn't be a problem here, we are talking about binNMUs 
immediately after sources+binaries had been uploaded to security.[1]


And the most common case (e.g. cacti or jtreg6) is that the uploads to 
security should have been source-only, AFAIK uploads to security-stable 
do not hit NEW when the source and binary packages are already in stable.


> Regards,
> Salvatore

cu
Adrian

[1] assuming no binary-all packages are involved

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Adrian Bunk]

On Thu, Dec 07, 2023 at 04:09:28PM +0100, Andreas Tille wrote:
>...
> Am Thu, Dec 07, 2023 at 01:37:02PM -0100 schrieb Graham Inggs:
>...
> > Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on
> > the tracker?
> 
> I was always wondering about this but I have no clue.  r-bioc-go.db is
> the third example in this row.  I was updating these in past transitions
> manually which is IMHO no big harm - but I simply don't understand.

Finding the root cause would be investigating the question why no 
dependency on r-api-bioc-* is generated for them.

Either that's not required and the packages are technically not part of 
the transition, or there is an (RC) bug that should be fixed.

> Kind regards
> Andreas.
>...

cu
Adrian

Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)

[Adrian Bunk]

On Thu, Dec 07, 2023 at 01:56:34PM +, Adam D. Barratt wrote:
>...
> Relatedly, if a binary upload was performed to the security archive
> then any binNMUs should likely happen there and then be synced across
> to stable, otherwise we're only resolving part of the issue.

I'd start one step earlier:

Most affected uploads should never have contained binaries.

There are some rare cases where a package in -security or -pu hits NEW,
but most cases look more like people wrongly assuming binaries would
be required for stable-new or stable-security.

You don't hit NEW in stable-security or stable-pu when the package is
already in stable.

> Regards,
> 
> Adam

cu
Adrian

Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)

[Adrian Bunk]

On Thu, Dec 07, 2023 at 11:18:42AM +0100, Paul Gevers wrote:
> Hi,

Hi Paul,

> On 07-12-2023 10:48, Adrian Bunk wrote:
> > unfortunately not, I noticed nagios-plugins-contrib on the buildds and
> > checked a few of the results after looking for "amd64" and "all" in the
> > subjects of recent months at [1].
> 
> I hope that in several hours,
> https://release.debian.org/britney/excuses_s-p-u.html will have the answer.

it should find packages like jtreg6 that are scheduled for the next 
point release, but it won't find packages like gmp that went into 
bullseye 2 years ago.

Stopping further regression on this is good, but for the ~ February 
point releases we have to discuss whether binNMUs+NMUs for packages that 
slipped through in the past should be done for bookworm (and bullseye).

> Paul

cu
Adrian

Re: reopen, has to stay on radar for the Python 3.12 transition

[Adrian Bunk]

On Thu, Dec 07, 2023 at 10:17:35AM +0100, Matthias Klose wrote:
> Control: reopen -1
> 
> please don't close issues that are only fixed in experimental.  These should
> stay on radar for the transition.

Sounds like tooling that does still not know about version tracking.

My guess would be that you are looking at
  
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-python%40lists.debian.org=python3.12
and that you want to add (or ask Stefano Rivera to add) a
  "Show bugs unfixed in unstable" 
checkbox for the code around
  
https://salsa.debian.org/qa/udd/-/blob/master/web/cgi-bin/bts-usertags.cgi#L212
that uses affects_unstable instead of done.

> There's also no way this bug will be
> properly closed when uploading to unstable, when the version from
> experimental doesn't show up in the changelog.

Either the changelog entry from experimental is kept and a new version 
"Upload to unstable" added (that's the normal case), or the changelog 
pretends the experimental version never existed and repeats all items 
(including the Closes).

Both options work fine.

> If you have to do this, please just mark these with "notfound".

"notfound" does not mark anything, it only removes "found" versions.

And with "fixed" nothing would ever close the bug after "Upload to unstable".

Since the introduction of version tracking uploads to experimental are 
supposed to close bugs, the open/close status of a bug is not reliable
regarding the status in unstable since uploads to stable or experimental
might close bugs that are not (yet) fixed in unstable.

cu
Adrian

Re: maintainer built binary package in stable release, still (Re: Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1)

[Adrian Bunk]

On Mon, Dec 04, 2023 at 05:59:44PM +, Holger Levsen wrote:
> Hi Adrian,

Hi Holger,

> thanks for bringing this to our attention!
> 
> On Sun, Dec 03, 2023 at 11:27:04PM +0200, Adrian Bunk wrote:
>...
> > There are other packages with the same issue in bookworm,
> > but these either involve binary-all packages and/or were
> > in previous point releases.
> 
> do you have a list of these? or better yet, a command to
> assemble that list?
>...

unfortunately not, I noticed nagios-plugins-contrib on the buildds and
checked a few of the results after looking for "amd64" and "all" in the
subjects of recent months at [1].

> cheers,
>   Holger

cu
Adrian

[1] https://lists.debian.org/debian-changes/

Re: OpenMPI / MPI transition

[Adrian Bunk]

On Sun, Dec 03, 2023 at 05:32:38PM +, Alastair McKinstry wrote:
> Hi,

Hi Alastair,

>...
> How do I do such a transition? I can't easily test as I lack 32-bit
> hardware. It _should_ be fine as MPICH builds and works
>...

Every amd64 hardware is also i386 hardware,
  debootstrap --arch=i386 sid i386-chroot
  chroot i386-chroot
is all that it takes for getting into a i386 Debian filesystem on amd64
(but higher level tooling or virtualization might be more convenient).


Two issues regarding this transition:


1. Two years ago I did the opposite transition on m68k+sh4, mostly for 
consistency with the other architectures.

These are nocheck architectures, so no information about runtime 
differences is available.

Switching to OpenMPI made SUNDIALS build, which in turn made Octave build.

This transition will likely require either making SUNDIALS build without 
OpenMPI on 32bit, or disabling SUNDIALS support in Octave on 32bit.


2. Packages building for both mpi implementations

The 9 yellow packages in the tracker (e.g. ScaLAPACK) currently provide
packages for both OpenMPI and MPICH.

The easiest solution would be to provide such packages only for the 
default mpi.

Hardcoding architecture lists might work.

The more sophisticated solution would be some debian/rules trickery to 
skip building the OpenMPI variants on 32bit, and for build dependencies 
creating an empty dependency package libopenmpi-dev-if-available that 
installs libopenmpi-dev on 64bit and does nothing on 32bit.


> Alastair

cu
Adrian

Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1

[Adrian Bunk]

On Sun, Dec 03, 2023 at 10:59:44AM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2023-10-23 at 13:19 +0200, Jan Wagner wrote:
> > As reported in #1033791, check_running_kernel fails to find version
> > on bookworm/(arm64|armhf).
> 
> Please go ahead.

Architecture: source amd64

Should this be binNMU'ed on amd64 before the release?
Maintainer-built binaries are not supposed to be in main.

There are other packages with the same issue in bookworm,
but these either involve binary-all packages and/or were
in previous point releases.

It might be useful if SRM tooling catches this issue,
similar to what britney does for testing.

> Regards,
> 
> Adam

cu
Adrian

BTW: The "contrib" in nagios-plugins-contrib does not refer
 to our archive section, the packages are in main.

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Adrian Bunk]

On Sun, Dec 03, 2023 at 09:51:38PM +0100, Paul Gevers wrote:
>...
> And it also means that r-bioc-biocgenerics is now blocked on the haskell
> transition. Lovely. Good thing that pandoc is supposed to be the last piece
> in that several months long transition.

It's only blocked by the pandoc part of the Haskell transition, 
it shouldn't be blocked by the other remaining parts of the
transition or by getting the transition into testing.

> Paul

cu
Adrian

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Adrian Bunk]

On Sun, Dec 03, 2023 at 09:46:31AM -0100, Graham Inggs wrote:
>...
> This is probably a good example for why new packages should be
> uploaded to experimental first, instead of directly to unstable.
>...

Not really.

It is rare that a new source package takes over a binary package from 
another binary package, and in this case the same might have happened
during an upgrade of the pandoc packages not involving NEW at all.

> Regards
> Graham
>...

cu
Adrian

Bug#1057280: bullseye-pu: package gimp/2.10.22-4+deb11u2

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Salvatore Bonaccorso 

  * Add Conflicts+Replaces: gimp-dds to remove old versions of this
plugin shipped by gimp itself since 2.10.10. (Closes: #1057149)

gimp-dds is an older version of a plugin already included
in gimp in bullseye, it also has CVE-2023-1 (DSA-5564-1)
unfixed.

Removal of gimp-dds from bullseye has already been requested
in #1056711, this update additionally removes stale versions
a user might still have installed.

The change is on top of the DSA version currently in oldstable-new.
diffstat for gimp-2.10.22 gimp-2.10.22

 changelog  |8 
 control|3 ++-
 control.in |3 ++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff -Nru gimp-2.10.22/debian/changelog gimp-2.10.22/debian/changelog
--- gimp-2.10.22/debian/changelog   2023-11-18 21:41:31.0 +0200
+++ gimp-2.10.22/debian/changelog   2023-12-02 16:47:53.0 +0200
@@ -1,3 +1,11 @@
+gimp (2.10.22-4+deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Conflicts+Replaces: gimp-dds to remove old versions of this
+plugin shipped by gimp itself since 2.10.10. (Closes: #1057149)
+
+ -- Adrian Bunk   Sat, 02 Dec 2023 16:47:53 +0200
+
 gimp (2.10.22-4+deb11u1) bullseye-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru gimp-2.10.22/debian/control gimp-2.10.22/debian/control
--- gimp-2.10.22/debian/control 2023-11-18 18:40:39.0 +0200
+++ gimp-2.10.22/debian/control 2023-12-02 16:47:53.0 +0200
@@ -83,8 +83,9 @@
   gimp-data-extras,
   gvfs-backends,
   libasound2
+Conflicts: gimp-dds
 Breaks: gimp-plugin-registry (<< 7.20140602+nmu1~)
-Replaces: gimp-plugin-registry (<< 7.20140602+nmu1~)
+Replaces: gimp-dds, gimp-plugin-registry (<< 7.20140602+nmu1~)
 Description: GNU Image Manipulation Program
  GIMP is an advanced picture editor. You can use it to edit, enhance, and
  retouch photos and scans, create drawings, and make your own images.
diff -Nru gimp-2.10.22/debian/control.in gimp-2.10.22/debian/control.in
--- gimp-2.10.22/debian/control.in  2023-11-18 18:40:39.0 +0200
+++ gimp-2.10.22/debian/control.in  2023-12-02 16:47:53.0 +0200
@@ -79,8 +79,9 @@
   gimp-data-extras,
   gvfs-backends,
   libasound2
+Conflicts: gimp-dds
 Breaks: gimp-plugin-registry (<< 7.20140602+nmu1~)
-Replaces: gimp-plugin-registry (<< 7.20140602+nmu1~)
+Replaces: gimp-dds, gimp-plugin-registry (<< 7.20140602+nmu1~)
 Description: GNU Image Manipulation Program
  GIMP is an advanced picture editor. You can use it to edit, enhance, and
  retouch photos and scans, create drawings, and make your own images.

Bug#1057274: bookworm-pu: package gimp/2.10.34-1+deb12u2

[Adrian Bunk]

The missing debdiff is attached.

cu
Adrian
diffstat for gimp-2.10.34 gimp-2.10.34

 changelog  |8 
 control|3 ++-
 control.in |3 ++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff -Nru gimp-2.10.34/debian/changelog gimp-2.10.34/debian/changelog
--- gimp-2.10.34/debian/changelog   2023-11-18 17:59:10.0 +0200
+++ gimp-2.10.34/debian/changelog   2023-12-02 15:31:27.0 +0200
@@ -1,3 +1,11 @@
+gimp (2.10.34-1+deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Conflicts+Replaces: gimp-dds to remove old versions of this
+plugin shipped by gimp itself since 2.10.10. (Closes: #1057149)
+
+ -- Adrian Bunk   Sat, 02 Dec 2023 15:31:27 +0200
+
 gimp (2.10.34-1+deb12u1) bookworm-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru gimp-2.10.34/debian/control gimp-2.10.34/debian/control
--- gimp-2.10.34/debian/control 2023-11-18 17:47:18.0 +0200
+++ gimp-2.10.34/debian/control 2023-12-02 15:31:27.0 +0200
@@ -84,8 +84,9 @@
   gimp-data-extras,
   gvfs-backends,
   libasound2
+Conflicts: gimp-dds
 Breaks: gimp-plugin-registry (<< 7.20140602+nmu1~)
-Replaces: gimp-plugin-registry (<< 7.20140602+nmu1~)
+Replaces: gimp-dds, gimp-plugin-registry (<< 7.20140602+nmu1~)
 Description: GNU Image Manipulation Program
  GIMP is an advanced picture editor. You can use it to edit, enhance, and
  retouch photos and scans, create drawings, and make your own images.
diff -Nru gimp-2.10.34/debian/control.in gimp-2.10.34/debian/control.in
--- gimp-2.10.34/debian/control.in  2023-11-18 17:47:18.0 +0200
+++ gimp-2.10.34/debian/control.in  2023-12-02 15:31:27.0 +0200
@@ -80,8 +80,9 @@
   gimp-data-extras,
   gvfs-backends,
   libasound2
+Conflicts: gimp-dds
 Breaks: gimp-plugin-registry (<< 7.20140602+nmu1~)
-Replaces: gimp-plugin-registry (<< 7.20140602+nmu1~)
+Replaces: gimp-dds, gimp-plugin-registry (<< 7.20140602+nmu1~)
 Description: GNU Image Manipulation Program
  GIMP is an advanced picture editor. You can use it to edit, enhance, and
  retouch photos and scans, create drawings, and make your own images.

Bug#1057274: bookworm-pu: package gimp/2.10.34-1+deb12u2

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Salvatore Bonaccorso 

  * Add Conflicts+Replaces: gimp-dds to remove old versions of this
plugin shipped by gimp itself since 2.10.10. (Closes: #1057149)

gimp-dds is an older version of a plugin already included
in gimp in bookworm, it also has CVE-2023-1 (DSA-5564-1)
unfixed.

Removal of gimp-dds from bookworm has already been requested
in #1056710, this update additionally removes stale versions
a user might still have installed.

Bug#1055891: transition: gdal

[Adrian Bunk]

On Sun, Nov 19, 2023 at 09:34:40AM +0100, Paul Gevers wrote:
>...
> On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
>...
> > grass-core in testing depends on the old libgdal33, hence the need to
> > also get grass and libgdal-grass from unstable when running autopkgtest
> > with gdal from unstable.
> 
> Why? (In other words, what breaks exactly?) Is this a case where some
> binaries load the old library and others load the new one leading to symbol
> clashes?

It is a case where a binary tries to load the new soversion of the 
library and plugins for the old soversion of the library.

> Paul
>...

cu
Adrian

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Adrian Bunk]

On Mon, Nov 20, 2023 at 10:59:02AM +0100, 
=?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote:
>...
> Not sure, if we need an updated breaks statement.
>...

Right now the autopkgtests block zlib migration to testing since they 
test zlib/unstable with texlive-binaries/testing - this is permitted
by the dependencies.

And this is not just a test issue:

On Sun, Nov 19, 2023 at 01:54:02PM +0100, Hilmar Preuße wrote:
> On 11/19/23 00:40, Adrian Bunk wrote:
>...
> > And it also might affects users directly, without proper dependencies
> > e.g. a bookworm -> trixie upgrade might end up with the following order
> > (among many other things happening during the upgrade):
> > 1. zlib gets upgraded
> > 2. the tex-common trigger runs
> > 3. texlive-bin gets upgraded
> > If this is permitted by the dependencies, then step 2 must not fail.
>
> I'd rather expect that the triggers run at the end of the setup process,
> i.e. after all packages replaced their files. At least this was the original
> ideal behind them IIRC.

The idea is to avoid unnecessary duplicate commands, but more than once 
might be required. And when upgrading to a new stable there are several 
cycles where triggers run at the end (you might not notice since the 
package manager takes care of it).

On a bookworm -> trixie upgrade the man-db trigger might run 5 or 10 times
instead of 1000 packages each executing the command, but it will definitely 
run more than once.

If one of the dependencies of texlive-binaries Pre-Depends on zlib1g,
this might be sufficient to ensure that all pending triggers are running 
after the upgrade of zlib1g and before the upgrade ot texlive-binaries.

> Hilmar

cu
Adrian

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Adrian Bunk]

On Mon, Nov 20, 2023 at 12:05:46AM +0100, Hilmar Preuße wrote:
> On 11/19/23 00:40, Adrian Bunk wrote:
> 
> Hi Adrian,

Hi Hilmar,

> > A proper fix would be either to:
> > 1. patch the version check out of texlive-bin (preferred), or
> > 
> Did so, see [1]. I did not remove the check completely, I just un-tightened
> the version. I can confirm that a texlive package linked on testing (zlib
> 1.2.x) is installable on unstable (zlib 1.3.x). I hope this solves the issue
> for the next 20 years. I intend to upload new packages tomorrow, this NMU
> bug can be closed, once this has been done.
> 
> I just noticed that we had this issue already 13 years ago. [2]

And from then zlib1g still has the
  Breaks: texlive-binaries (<< 2009-12)
that will also require updating again.

Is there any reason why the check exists at all?

If the only effect is breakage every 10-20 years,
then it's wrong to keep it.

This check would make sense if zlib would make buggy changes where the 
ABI changes without chaning the library soname, but that is not supposed 
to happen and if it would happen with a library as widely used as zlib 
then so much would break in unstable that the revert would be instant.

> Hilmar
>...

cu
Adrian

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Adrian Bunk]

On Sun, Nov 19, 2023 at 01:54:02PM +0100, Hilmar Preuße wrote:
>...
> I can patch out that version check as found by Samuel, but I don't see how
> that would solve the core dump or the SIGABRT, which was reported. I hope
> lua_error(L) is not the equivalent of "exit with SIGABRT". ;-)
>...

It is.

https://www.lua.org/manual/5.3/manual.html#lua_error
  int lua_error (lua_State *L);
  Generates a Lua error, using the value at the top of the stack as the 
  error object. This function does a long jump, and therefore never 
  returns (see luaL_error).

The SIGABRT is generated by calling abort():
https://sources.debian.org/src/lua5.3/5.3.6-2/src/lapi.c/#L1117
https://sources.debian.org/src/lua5.3/5.3.6-2/src/ldebug.c/#L649
https://sources.debian.org/src/lua5.3/5.3.6-2/src/ldo.c/#L130

> Hilmar

cu
Adrian

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Adrian Bunk]

On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote:
> Control: severity -1 important
> Control: block 1056183 by -1
> 
> On 11/18/23 20:18, Samuel Thibault wrote:
> 
> Hi Samuel,
> 
> > 
> > nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild 
> > against new zlib"
> > 
> 
> Thanks for filing the NMU bug.
> 
> > So a binnmu of the texlive-bin source package seems needed on all archs
> > to fix installing texlive-binaries.
> > 
> 
> I tested if recompiling solves the issue and it does. Hence I bump severity
> of the NMU bug the get a solution ASAP.

I don't see how a binNMU would solve the problem.

A proper fix would be either to:
1. patch the version check out of texlive-bin (preferred), or
2. ensure texlive-bin has package dependencies that match this runtime check

After a binNMU the migration of zlib to testing would still be 
blocked forever by the autopkgtest of packages like asymptote that
will continue to test with zlib/unstable and texlive-bin/testing.

And it also might affects users directly, without proper dependencies 
e.g. a bookworm -> trixie upgrade might end up with the following order
(among many other things happening during the upgrade):
1. zlib gets upgraded
2. the tex-common trigger runs
3. texlive-bin gets upgraded
If this is permitted by the dependencies, then step 2 must not fail.

> Hilmar

cu
Adrian

Re: OpenSSL transition to testing

[Adrian Bunk]

On Fri, Nov 17, 2023 at 05:22:35PM +0100, Sebastian Andrzej Siewior wrote:
>...
> I'm now curious to learn what could be the best way to move forward. I
> have a few ideas:
> - NMU #1055416, allow the transition to happen.
> 
> - NMU also #1052470 in order to allow an OpenSSL 3.1.4 upload. This
>   could be tricky because proposed change is based on nodejs' master-18.x
>   branch meaning new nodejs version which could lead to other issues.
>   I could try to isolate the needed bits but…
> 
> - Ignore debci for Nodejs which would allow 3.0.12-2 to migrate and
>   3.1.4 could follow to unstable shortly after.
> 
> Anyone?

Your last option is in practice equivalent to Nodejs not having any 
autopkgtest at all, disabling one or few tests would be preferable
to that since regressions in the other > 3000 tests would still be
detected. E.g. different tests in Nodejs fail with c-ares/unstable,[1]
and this will no longer be visible if the autopkgtest always fails.

> Sebastian

cu
Adrian

[1] which should also be looked at if anyone touches nodejs

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Adrian Bunk]

On Fri, Oct 27, 2023 at 10:55:48AM +0200, Bastian Blank wrote:
> On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > > ## Image packages contains more version info
> > > > 
> > > > Example: linux-image-6.5.3-cloud-arm64
> > > 
> > > > It will not longer be possible to reliably derive the package name from
> > > > kernel release (see above), as both values are not really related
> > > > anymore.
> > 
> > This package name seems to be missing the Debian release, which is
> > mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
> > parallel, which again is mandatory. That's not something we can
> > compromise on; it's absolutely vital that
> 
> Sadly in Debian there is no way to make that happen.  Think for example
> about bin-nmu.
>...

Could you give a complete list of problems?

The only problem that comes immediately into my mind is the problem that 
uploads with new binary packages are going into NEW for no good reason.

If this is the only problem, I wouldn't worry too much since I'd be 
optimistic a GR to change this will be sucessful.

> Bastian

cu
Adrian

Re: status of ghc / haskell transition

[Adrian Bunk]

On Sat, Oct 21, 2023 at 07:08:34PM +0200, Sebastian Ramacher wrote:
> Hi Adrian

Hi Sebastian,

> On 2023-10-20 08:30:21 +0200, Sebastian Ramacher wrote:
> > On 2023-10-19 18:00:29 +0300, Ilias Tsitsimpis wrote:
> > > > Do you need help from us?
> > > 
> > > Can you please schedule the necessary binNMUs for the new GHC? We have a
> > > list here [3] that is updated every 4 hours. We are currently blocked
> > > until this happens, as we need all existing packages to build with the
> > > new GHC.
> > 
> > Scheduled.
> 
> I see that you failed plenty of the haskell binNMUs. Would you mind
> reporting the corresponding bugs so that the maintainers are aware of
> what to fix? TIA

the maintainers are already aware that every new major version of 
ghc needs a source upload of > 1k packages to make the libghc-*-doc
packages installable again so that the new ghc can migrate to testing
(this was point 3 in the email from Ilias).

I've failed binNMU'ed packages that did not yet have a source upload for 
9.4 since they will anyway need an upload, and then their rdeps would 
need binNMUs again.

IMHO > 100 RC bugs for these packages would not be helpful right now,
it will be easier to report remaining issues (if any) from excuses
when the maintainers have finished upgrading/uploading all packages.

> Cheers

cu
Adrian

Bug#1054146: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b2

[Adrian Bunk]

On Wed, Oct 18, 2023 at 10:46:13PM -0400, Scott Talbert wrote:
> On Thu, 19 Oct 2023, Cyril Brulebois wrote:
> 
> > Scott Talbert  (2023-10-17):
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: binnmu
> > > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org
> > > Control: affects -1 + src:libalien-wxwidgets-perl
> > > 
> > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b2 . ANY . unstable . -m "Rebuild 
> > > against libwxgtk3.2-dev 3.2.3+dfsg-1"
> > 
> > While libalien-wxwidgets-perl shows up on the 
> > auto-upperlimit-libwxgtk3.2-dev
> > tracker, libwx-perl doesn't and this binNMU broke libwx-perl's 
> > installability,
> > also breaking d-i builds.
> > 
> >Package: libalien-wxwidgets-perl
> >Provides: wxperl-gtk-3-2-3-uni-gcc-3-4
> > 
> >Package: libwx-perl
> >Depends: […], wxperl-gtk-3-2-2-uni-gcc-3-4, […]
> 
> Indeed, libwx-perl has to be binMNU'd next.  Was waiting for the s390x build
> of libalien-wxwidgets-perl, but went ahead and submitted the binNMU request
> for libwx-perl anyway so we can get other arches fixed.
>...

Without the binNMU libalien-wxwidgets-perl was not installable with the 
new libwxgtk3.2-dev, therefore libwx-perl waits automatically on the 
buildds until the build dependency libalien-wxwidgets-perl is rebuilt 
and installable again.

> Regards,
> Scott

cu
Adrian

Bug#1053641: transition: libavif

[Adrian Bunk]

On Sat, Oct 07, 2023 at 03:33:16PM -0400, Boyuan Yang wrote:
>...
> (2) Fix current jpeg-xl in Sid properly. That won't be too trivial since the 
> new
> testing error is likely triggered by some unclear changes in 
> build-dependencies over
> the past several months.
>...

Fix below, only tested on i386 but should also fix s390x.

> Thanks,
> Boyuan Yang
>...

cu
Adrian

--- jpeg-xl-0.7.0/debian/rules.old  2023-10-07 20:36:28.728571696 +
+++ jpeg-xl-0.7.0/debian/rules  2023-10-07 20:36:51.420550561 +
@@ -23,6 +23,8 @@
   DEB_CXXFLAGS_MAINT_APPEND += -fno-tree-vectorize
 endif
 
+DEB_CXXFLAGS_MAINT_APPEND += -fexcess-precision=fast
+
 ifneq (,$(filter $(DEB_HOST_ARCH), arm64 armel armhf ppc64el))
   # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
   DEB_CXXFLAGS_MAINT_APPEND += -Wno-psabi

Bug#1028489: transition: boost1.81

[Adrian Bunk]

On Wed, Oct 04, 2023 at 03:23:46PM -0400, David James wrote:
> Hi Anton,
> 
> Is there anything I can do to help this transition along? I wish to
> package software that does not build on 1.74, but does on 1.81 and 1.82.
> If there's anyway I can assist with bumping boost-defaults to 1.81 or 1.82
> I would be happy to help.

Note that as a workaround you could temporarily use a non-default boost 
by build depending on libboost-foo1.81-dev instead of libboost-foo-dev,
and then later switch to libboost-foo-dev (>= 1.81) [1] after the 
defaults change.

> Regards,
> 
> David James

cu
Adrian

[1]   Build-Depends: libboost-foo-dev (>= 1.81) | libboost-foo1.81-dev
would then (*after* the defaults change) be an alternative option to 
make the package easily backportable since boost1.81 is already in
bookworm and even bullseye-backports

Re: Upcoming changes to Debian Linux kernel packages

[Adrian Bunk]

On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...

If the new kernel has a regression that affects the user, the user 
usually has no good choice other than downgrading to the previously-used 
kernel and continue using it until a fixed kernel is available.

How will the user get the headers matching this previously-used kernel
that are required until we provide a kernel with the regression fixed?

> Regards,
> Bastian

cu
Adrian

Bug#1042057: binNMUs needed for new pandoc in *stable

[Adrian Bunk]

On Tue, Jul 25, 2023 at 11:39:38PM +0200, Guilhem Moulin wrote:
>...
> The Security Team decided not to issue a DSA for that CVE, but it's now fixed 
> in
> buster-security (2.2.1-3+deb10u1) as well as sid (2.17.1.1-2), so it makes 
> sense
> to fix it via (o)s-pu too.
>...

In all 3 distributions this made libghc-{gitit,hakyll}-{dev,prof} 
uninstallable due to changed libghc-pandoc-{dev,prof}-* provides, e.g.:
  The following packages have unmet dependencies:
   libghc-gitit-dev : Depends: libghc-pandoc-dev-2.17.1.1-35d44

For bullseye/bookworm this should be fixed with:

  wb nmu gitit . ANY . bookworm . -m 'Rebuild against new pandoc'
  wb nmu haskell-hakyll . ANY . bookworm . -m 'Rebuild against new pandoc'

  wb nmu gitit . ANY . bullseye . -m 'Rebuild against new pandoc'
  wb nmu haskell-hakyll . ANY . bullseye . -m 'Rebuild against new pandoc'

This might result in the Provides of libghc-{gitit,hakyll}-{dev,prof} changing,
but these are leaf packages.

cu
Adrian

Bug#1053272: bookworm-pu: package rmlint/2.9.0-2.5~deb12u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Julian Gilbey , Carlos Maddela 


This adds the #1040940 fix to the #1040939 upload for an unrelated
issue that is already included for the next point release.

#1040940 happens with python3.11/sid but not with python3.11/bookworm,
but it is unclear which python3.11 change caused it or whether this
might at some point get backported as part of a security fix to
python3.11/bookworm. The fix is an obvious off-by-one fix.

Regarding the versioning:

My debdiff is against the already approved #1040939,
but I am changing the versioning from 2.9.0-2.3+deb12u*
to 2.9.0-2.5~deb12u1 for two reasons:
1. it documents that this is a backport of a version, and
2. people won't see the same changes twice in apt-listchanges

These are not very strong reasons, I wouldn't have made such a change
had 2.9.0-2.3+deb12u1 already been released.
diffstat for rmlint-2.9.0 rmlint-2.9.0

 changelog   |   19 
++-
 patches/0001-cmdline-do-not-write-NUL-byte-to-GUI-bootstrap-scrip.patch |   26 
++
 patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch  |9 
---
 patches/series  |1 
 4 files changed, 46 insertions(+), 9 deletions(-)

diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog   2023-07-12 18:18:40.0 +0300
+++ rmlint-2.9.0/debian/changelog   2023-09-30 15:52:45.0 +0300
@@ -1,10 +1,25 @@
-rmlint (2.9.0-2.3+deb12u1) bookworm; urgency=medium
+rmlint (2.9.0-2.5~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+
+ -- Adrian Bunk   Sat, 30 Sep 2023 15:52:45 +0300
+
+rmlint (2.9.0-2.5) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add upstream fix for GUI startup failure with recent python3.11.
+(Closes: #1040940)
+
+ -- Adrian Bunk   Sat, 05 Aug 2023 17:16:05 +0300
+
+rmlint (2.9.0-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
   * Fix error in other packages caused by invalid python package version
 number (cherry-picking upstream patch; closes: #1040179)
 
- -- Julian Gilbey   Wed, 12 Jul 2023 16:18:40 +0100
+ -- Julian Gilbey   Wed, 05 Jul 2023 09:31:46 +0100
 
 rmlint (2.9.0-2.3) unstable; urgency=medium
 
diff -Nru 
rmlint-2.9.0/debian/patches/0001-cmdline-do-not-write-NUL-byte-to-GUI-bootstrap-scrip.patch
 
rmlint-2.9.0/debian/patches/0001-cmdline-do-not-write-NUL-byte-to-GUI-bootstrap-scrip.patch
--- 
rmlint-2.9.0/debian/patches/0001-cmdline-do-not-write-NUL-byte-to-GUI-bootstrap-scrip.patch
 1970-01-01 02:00:00.0 +0200
+++ 
rmlint-2.9.0/debian/patches/0001-cmdline-do-not-write-NUL-byte-to-GUI-bootstrap-scrip.patch
 2023-08-05 17:13:47.0 +0300
@@ -0,0 +1,26 @@
+From e811a34bdf81f0f5366b07077432f8ab9c776ddd Mon Sep 17 00:00:00 2001
+From: Cebtenzzre 
+Date: Wed, 2 Aug 2023 21:29:15 -0400
+Subject: cmdline: do not write NUL byte to GUI bootstrap script
+
+Fixes #628
+---
+ lib/cmdline.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/cmdline.c b/lib/cmdline.c
+index d5b1338c..07ba104a 100644
+--- a/lib/cmdline.c
 b/lib/cmdline.c
+@@ -176,7 +176,7 @@ static void rm_cmd_start_gui(int argc, const char **argv) {
+ return;
+ }
+ 
+-if(write(bootstrap_fd, RM_PY_BOOTSTRAP, sizeof(RM_PY_BOOTSTRAP)) < 0) {
++if(write(bootstrap_fd, RM_PY_BOOTSTRAP, strlen(RM_PY_BOOTSTRAP)) < 0) {
+ rm_log_warning_line("Could not bootstrap gui: Unable to write to 
tempfile: %s",
+ g_strerror(errno));
+ return;
+-- 
+2.30.2
+
diff -Nru 
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
 
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
--- 
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
  2023-07-12 18:18:40.0 +0300
+++ 
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
  2023-07-05 11:31:46.0 +0300
@@ -10,11 +10,9 @@
  lib/config.h.in | 62 ++---
  1 file changed, 33 insertions(+), 29 deletions(-)
 
-diff --git a/lib/config.h.in b/lib/config.h.in
-index 44d7e5d9..d9fdeabd 100644
 --- a/lib/config.h.in
 +++ b/lib/config.h.in
-@@ -121,9 +121,13 @@
+@@ -123,9 +123,13 @@
  #  define N_(String) gettext_noop (String)
  #endif
  
@@ -30,7 +28,7 @@
  
  typedef guint64 RmOff;
  
-@@ -150,33 +154,33 @@ typedef guint64 RmOff;
+@@ -152,33 +156,33 @@
  
  ///
  
@@ -91,6 +89,3 @@
  
  /* Domain for reporting errors. Needed by GOptions */
  #define RM_ERROR_QUARK (g_quark_from_static_string("rmlint"))
--- 
-2.20.1
-
diff -Nru rmlint-2.9.0/debian/patches/series rmlint-2

Bug#1053271: bullseye-pu: package cpio/2.13+dfsg-7.1~deb11u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org, Anibal Monsalve Salazar 


This updates the cpio package in bullseye to the package
in bookworm/trixie/sid (same upstream version).

The first 3 post-bullseye uploads are CVE-2021-38185 plus
regression fixes for this change.

The 2.13+dfsg-7.1 changes are one documentation change and two
changes that look desirable (even though they alone might not have
warranted a stable update):
  * Suggest libarchive-dev (Closes: #662718).
  * d/copyright: Convert to machine-readable format.
  * Fix CRC with new ASCII format when file > 2GB (Closes: #962188).

There are no bugs in the BTS that any regressions have been caused
by any of these changes during the 1 year since they were uploaded
to bookworm/sid.
diffstat for cpio-2.13+dfsg cpio-2.13+dfsg

 changelog|   39 
 control  |2 
 copyright|   51 -
 patches/992045-CVE-2021-38185-rewrite-dynamic-string-support |  454 +++
 patches/992098-regression-of-orig-fix-for-CVE-2021-38185 |   36 
 patches/992192-Fix-dynamic-string-reallocations.patch|   80 +
 patches/Wrong-CRC-with-ASCII-CRC-for-large-files.patch   |   34 
 patches/series   |4 
 8 files changed, 685 insertions(+), 15 deletions(-)

diff -Nru cpio-2.13+dfsg/debian/changelog cpio-2.13+dfsg/debian/changelog
--- cpio-2.13+dfsg/debian/changelog 2020-09-17 14:16:18.0 +0300
+++ cpio-2.13+dfsg/debian/changelog 2023-09-30 15:18:55.0 +0300
@@ -1,3 +1,42 @@
+cpio (2.13+dfsg-7.1~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+
+ -- Adrian Bunk   Sat, 30 Sep 2023 15:18:55 +0300
+
+cpio (2.13+dfsg-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Suggest libarchive-dev (Closes: #662718).
+  * d/copyright: Convert to machine-readable format.
+  * Fix CRC with new ASCII format when file > 2GB (Closes: #962188).
+
+ -- Bastian Germann   Wed, 14 Sep 2022 21:45:55 +0200
+
+cpio (2.13+dfsg-7) unstable; urgency=medium
+
+  [ Salvatore Bonaccorso ]
+  * Fix dynamic string reallocations (Closes: #992192)
+
+ -- Anibal Monsalve Salazar   Sun, 22 Aug 2021 15:21:53 
+1000
+
+cpio (2.13+dfsg-6) unstable; urgency=high
+
+  * Fix regression of original fix for CVE-2021-38185
+Add patch 992098-regression-of-orig-fix-for-CVE-2021-38185 
+Closes: #992098
+
+ -- Anibal Monsalve Salazar   Fri, 13 Aug 2021 13:06:27 
+1000
+
+cpio (2.13+dfsg-5) unstable; urgency=medium
+
+  * Fix CVE-2021-38185
+Add patch 992045-CVE-2021-38185-rewrite-dynamic-string-support
+Closes: #992045
+
+ -- Anibal Monsalve Salazar   Wed, 11 Aug 2021 01:18:33 
+1000
+
 cpio (2.13+dfsg-4) unstable; urgency=medium
 
   * Source only upload to enable migration.
diff -Nru cpio-2.13+dfsg/debian/control cpio-2.13+dfsg/debian/control
--- cpio-2.13+dfsg/debian/control   2020-02-01 15:11:00.0 +0200
+++ cpio-2.13+dfsg/debian/control   2022-09-14 22:45:55.0 +0300
@@ -17,7 +17,7 @@
 Replaces: cpio-mt
 Conflicts: mt-st (<< 0.6), cpio-mt
 Multi-Arch: foreign
-Suggests: libarchive1
+Suggests: libarchive-dev
 Description: GNU cpio -- a program to manage archives of files
  GNU cpio is a tool for creating and extracting archives, or copying
  files from one place to another.  It handles a number of cpio formats
diff -Nru cpio-2.13+dfsg/debian/copyright cpio-2.13+dfsg/debian/copyright
--- cpio-2.13+dfsg/debian/copyright 2020-02-01 15:11:00.0 +0200
+++ cpio-2.13+dfsg/debian/copyright 2022-09-14 22:45:55.0 +0300
@@ -1,16 +1,39 @@
-This is the Debian GNU/Linux prepackaged version of GNU cpio
-(including mt).
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This is the Debian GNU/Linux prepackaged version of GNU cpio
+ (including mt).
+ .
+ This package was put together by Clint Adams .
+Source: ftp://ftp.gnu.org/gnu/cpio
 
-This package was put together by Clint Adams ,
-from sources obtained from ftp://ftp.gnu.org:/gnu/cpio
+Files: *
+Copyright: (C) 1984-2019 Free Software Foundation, Inc.
+License: GPL-3+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3, or (at your option)
+ any later version.
+Comment:
+ The text of the GPL version 3 can be found on Debian systems in
+ /usr/share/common-licenses/GPL-3.
 
-GNU cpio is Copyright (C) 1990, 1991, 1992, 2001, 2003, 2004, 2005,
-2006, 2007 Free Software Foundation, Inc.
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Softwar

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Adrian Bunk]

On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
>...
> Note that the last time the problem arised already earlier in
> experimental and Ben workarounded it there with
> https://salsa.debian.org/kernel-team/linux/-/commit/9dfe6d33a4fd220394228b30cbbfdb3b444d36ec
> We probably can do that as well here. 60443c88f3a8 ("kallsyms: Improve
> the performance of kallsyms_lookup_name()") was in fact backported to
> 6.1.42. So this is next I would try and disable MPTCP and
> FUNCTION_TRACER.
>...

Yes, that looks reasonable.

Additionally, one generic cause of bloat is:
  debian/changelog:  * Enable UNICODE. (closes: #985689)
  debian/config/config:CONFIG_UNICODE=y

That's 74 kB uncompressed, and there doesn't seem to be any 
justification for not making it modular. It's not urgent since
Bens change handles the immediate problem, but worth changing
in unstable.

cu
Adrian

Bug#1050071: llvm-defaults: move to 16

[Adrian Bunk]

On Mon, Sep 11, 2023 at 10:36:00AM +0100, Simon McVittie wrote:
> On Sat, 19 Aug 2023 at 10:39:44 +0200, Sylvestre Ledru wrote:
> > llvm-defaults has been pointing to 16 in experimental for quite sometime.
> > Opening this transition to make sure it is on your radar! :)
> > 
> > I opened bug #1050070 & #1050069 for future removals.
> 
> Mesa is a significant user of LLVM, and hard-codes its own non-default
> version of LLVM which often runs ahead of the default (currently 15).
> It seems to be relatively common for a LLVM version upgrade to cause
> regressions or uninstallability on at least one architecture, and also
> relatively common for a LLVM version upgrade to be necessary to unblock
> features or bug fixes in Mesa, which I assume is why the Mesa maintainers
> have felt the need to control this themselves.
> 
> Should Mesa try moving to -16 *before* the default changes? It would
> seem unhelpful to move the rest of the distribution to a version that
> Mesa can't use for whatever reason.
>...

Mesa is not the sole user of a non-default LLVM.

This transition is about changing the default, which affects the 
packages that use the default version.

Users of non-default LLVM like mesa/rustc/chromium/ghc/qt6-tools/... 
move at their own pace (otherwise they would use the default LLVM).

> smcv

cu
Adrian

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Adrian Bunk]

On Sat, Sep 09, 2023 at 10:15:59AM +0200, Salvatore Bonaccorso wrote:
>...
> - Relese the DSA without armel builds. This is not optimal and for the point 
> release
>   we need to have to have all builds, but this gives people who still are 
> interested
>   in this architecture to step up and propose a fix for the problem, 
> otherwise then
>   disable the image size check, and then effectively dropping some support.
>...
> armel people, can you have ideally look at it ASAP on the comments
> please, I would not like to delay the DSA for linux on
> bookworm-security too much.

Releasing this DSA without armel and sorting out the issue for the point 
release sounds like the best option to me.

> Thanks for having a look,
> 
> Regards,
> Salvatore

cu
Adrian

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Adrian Bunk]

On Wed, Aug 30, 2023 at 04:54:01PM +0100, Simon McVittie wrote:
>...
> However, if I understand correctly, Luca has been told that some official
> mips64el buildds are running mipsel user-space on mips64el hardware which
> only works with the buster kernel,
>...
> Is this true?

Yes:
https://lists.debian.org/debian-mips/2023/07/msg00052.html

>...
> If our official buildds for a release architecture are unable to run on
> either the stable or oldstable kernel, I think that raises some important
> questions about suitability for inclusion in future releases.
>...

This problem affects older (and slower) buildds, the newer buildds 
don't run with any kernel older than oldstable.

Turning off the affected buildds is an option.

>...
> >From the point of view of the project having control over its own future,
> I would have hoped that official Debian infrastructure would only be using
> suites that are supported by Debian as a whole,
>...

This problem is not limited to mips:
https://nagios.debian.org/cgi-bin/icinga/status.cgi?hostgroup=buster=overview

E.g. the Python2 removal in bullseye removed planet-venus,
which was never ported to Python3 but is used by planet.debian.org.
A replacement is being written in Perl, but it is still WIP.

> Thanks,
> smcv

cu
Adrian

Bug#1042005: transition: mumps hypre2.28.0 superlu combblas

[Adrian Bunk]

On Wed, Aug 02, 2023 at 10:58:17AM +0200, Drew Parsons wrote:
> On 2023-07-31 21:30, Sebastian Ramacher wrote:
> > > 
> > > combblas:  1.16.0 → 2.0.0
> > > superlu:5 → 6
> > > hypre: 2.26.0 → 2.28.0
> > > mumps:5.5 → 5.6
> > 
> > Please go ahead.
> 
> combblas and superlu are loaded.
> 
> Probably best to run the rebuild of superlu-dist against combblas
>...

That didn't build:

https://buildd.debian.org/status/logs.php?pkg=superlu-dist=8.1.2%2Bdfsg1-1%2Bb2

...
/usr/bin/ld: 
CMakeFiles/superlu_dist.dir/z_c2cpp_GetHWPM.cpp.o:/usr/include/CombBLAS/BipartiteMatchings/BPMaximalMatching.h:17:
 multiple definition of `GlobalMT'; 
CMakeFiles/superlu_dist.dir/d_c2cpp_GetHWPM.cpp.o:/usr/include/CombBLAS/BipartiteMatchings/BPMaximalMatching.h:17:
 first defined here
/usr/bin/ld: CMakeFiles/superlu_dist.dir/z_c2cpp_GetHWPM.cpp.o: in function 
`combblas::ThreadBuffLenForBinning(int, int)':
/usr/include/CombBLAS/BipartiteMatchings/ApproxWeightPerfectMatching.h:401: 
multiple definition of `combblas::ThreadBuffLenForBinning(int, int)'; 
CMakeFiles/superlu_dist.dir/d_c2cpp_GetHWPM.cpp.o:/usr/include/CombBLAS/BipartiteMatchings/ApproxWeightPerfectMatching.h:401:
 first defined here
...


At first sight this looks like a bug in the combblas headers to me.


> Drew

cu
Adrian

BTW: dolfin/fenics-basix/fenics-dolfinx need source-only uploads
 for testing migration.

Re: Give-backs of linux/mips{,64}el / bookworm this morning

[Adrian Bunk]

On Fri, Jul 14, 2023 at 11:03:39AM +0100, Adam D. Barratt wrote:
> Hi Adrian,

Hi Adam,

> While checking the status of the linux upload to proposed-updates this
> morning, I noticed that the packages for mipsel and mips64el were still
> in the BD-Uninstallable state, whereas those for some other
> architectures had already started building.
> 
> Further investigation showed that you requested a give-back for the
> package on those architectures while they were in Needs-Build. Could
> you please explain why you did so?
>...

to avoid building on a buildd where it would take until Monday,
like one of you did in a different way afterwards when killing
the mips64el build on mipsel-aql-02.

The next fast buildds mipsel-osuosl-04 and mipsel-osuosl-05 were still 
busy for an hour in unstable,[1] I would have given back when they would 
have been certain to be the next available buildds.

> Regards,
> 
> Adam

cu
Adrian

[1] https://buildd.debian.org/status/recent.php?pkg==mipsel%2Cmips64el

Re: Debian Kernel version and ABI in respect of #1040901

[Adrian Bunk]

On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
>...
> ### NMU
> 
> Can be easily added back by adding "bX" or so to the ABI.

That would be confusing, bX is naming convention for binNMUs in Debian 
revisions.

> ### BinNMU
> 
> Is impossible to support.  The version change requires changes in the
> names of the created packages.
>...

It should only be impossible to make them co-installable,
or what other reason requires a rename?

cu
Adrian

Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1

[Adrian Bunk]

On Sun, Jul 09, 2023 at 01:13:55AM +0300, Michael Tokarev wrote:
>...
> I'll see what can be done tomorrow. Apparently it might be better to revert
> this keyring change for bookworm and fix it for good in trixie first.
>...

And BTW, manually linking with libatomic is the correct fix here for 
your package.

"fix it for good" would be to fix gcc, but such a fix would not be 
backported to bookworm.

> Thank you!
> 
> /mjt

cu
Adrian

Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1

[Adrian Bunk]

On Sun, Jul 09, 2023 at 01:13:55AM +0300, Michael Tokarev wrote:
> 09.07.2023 01:01, Adrian Bunk wrote:
> > This does apparently need the -latomic workaround from 2:4.18.3+dfsg-3:
> > https://buildd.debian.org/status/package.php?p=samba=bookworm
> 
> Sigh!
> This is the kerberos in-kernel tickets.. :(
> 
> I haven't realized until now that atomic8 thing come into the game after
> I enabled the in-kernel kerberos tickets.  I was sure it was due to some
> toolchain changes.

FTR, the underlying toolchain bug is not new:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

> Now I know why we weren't able to reproduce this issue
> with upstream, - because it happens in the code which is enabled by this
> change.
>...

The error message is a bit cryptic, but it basically says in which lines 
in krcache.c the 64bit loads/stores are for which the CPU has no 
instructions and needs libatomic.

Not linking with libatomic automatically for C11 atomics is the gcc bug.

> Thank you!
> 
> /mjt

cu
Adrian

Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1

[Adrian Bunk]

This does apparently need the -latomic workaround from 2:4.18.3+dfsg-3:
https://buildd.debian.org/status/package.php?p=samba=bookworm

cu
Adrian

Bug#1039622: bookworm-pu: package nvidia-cuda-toolkit/11.8.0-5~deb12u1

[Adrian Bunk]

bunk@coccia:~$ cat 
/srv/ftp-master.debian.org/queue/reject/nvidia-cuda-toolkit_11.8.0-5~deb12u1_amd64-buildd.changes.reason

Version check failed:
Your upload included the binary package nvidia-openjdk-8-jre, version 
9.+8u372-ga-1~11.8.0-5~deb12u1, for amd64,
however experimental already has version 9.+8u362-ga-4~12.0.0-1.
Uploads to proposed-updates must have a lower version than present in 
experimental.
bunk@coccia:~$ 


That's a surprising reject reason, but a give-back might work if you
update the version in experimental.


cu
Adrian

Re: Bug#1034824: tomcat9 should not be released with Bookworm

[Adrian Bunk]

On Tue, May 16, 2023 at 05:28:11PM +0300, Timo Aaltonen wrote:
> Timo Aaltonen kirjoitti 16.5.2023 klo 10.12:
> > Markus Koschany kirjoitti 13.5.2023 klo 23.38:
> > > Hi Salvatore,
> > > 
> > > adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC
> > > 
> > > Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso:
> > > > Hi Markus,
> > > > 
> > > > On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote:
> > > > > I have just pushed the necessary changes to our Git repository.
> > > > > 
> > > > > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993
> > > > 
> > > > Do we need to have done more here? When Paul asked on #debian-release
> > > > I noted that pki-server depends on tomcat9-user, so reducing
> > > > libtomcat9-java only would now cause a broken dpeends for pki-server:
> > > > 
> > > > $ dak rm --suite=bookworm -n -R -b tomcat9-user
> > > > Will remove the following packages from bookworm:
> > > > 
> > > > tomcat9-user |   9.0.70-1 | all
> > > 
> > > We could simply replace tomcat9-user with tomcat10-user because it
> > > only ships a
> > > script to create a standalone tomcat instance. We have to do
> > > s/tomcat9/tomcat10/ in some debian service files as well.
> > > 
> > > The question is: If we ship libtomcat9-java in Bookworm and change the
> > > dependency from tomcat9-user to tomcat10-user, will a web
> > > application like
> > > dogtag-pki, which is designed for Tomcat 9, continue to work with
> > > Tomcat 10? I
> > > don't know yet and maybe Timo can chime in here.
> > 
> > I don't know, dogtag uses the skel files from tomcat9-user, but I diffed
> > them between tomcat9 and 10 and couldn't see why it would regress.
> 
> Had a closer look at dogtag, and it's launching the tomcat instance from
> CATALINA_HOME, so it's a one-way ticket to migrate an installed instance to
> use tomcat10 in the configuration, so I don't think moving to tomcat10-user
> would fly..

Does that mean the two bugs (in tomcat9 and tomcatjss) should be tagged 
"trixie sid" to no longer affect and bookworm will ship with two versions
of tomcat, or what else is now supposed to happen?

cu
Adrian

Bug#1035882: nmu: pvpgn_1.8.5-3

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 1034224 by -1

nmu pvpgn_1.8.5-3 . ANY . unstable . -m "Rebuild with fixed debhelper 
installing pvpgn.service to the correct place"


Files in second .deb but not in first
-
-rw-r--r--  root/root   /lib/systemd/system/pvpgn.service
-rwxr-xr-x  root/root   DEBIAN/preinst

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/lib/systemd/system/pvpgn.service


See #1034224 for background.

Re: Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10

[Adrian Bunk]

On Sun, Mar 26, 2023 at 03:23:58PM +0200, Markus Koschany wrote:
> Am Sonntag, dem 26.03.2023 um 12:15 +0300 schrieb Timo Aaltonen:
> > Markus Koschany kirjoitti 24.3.2023 klo 15.35:
> > > Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen:
> > > > Markus Koschany kirjoitti 23.3.2023 klo 19.00:
> > > > > Control: severity -1 serious
> > > > > 
> > > > > On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen 
> > > > > wrote:
> > > > >    
> > > > > > Upstream doesn't support tomcat10 yet, and tomcatjss fails to build
> > > > > > with
> > > > > > it.
> > > > > 
> > > > > Unfortunately we can only support one Tomcat version per release. We
> > > > > should
> > > > > either migrate to tomcat10 or maybe it is possible to embed some of 
> > > > > the
> > > > > required tomcat9 classes in your source package as a workaround
> > > > > provided
> > > > > the
> > > > > changes are rather small and the security impact is negligible.
> > > > 
> > > > Right, but that's for bookworm+1? By that time I'm sure
> > > > jss/tomcatjss/dogtag have gained upstream support for tomcat10.
> > > 
> > > We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in
> > > Buster
> > > and Bullseye already. Tomcat 10 also targets Java 11 and later while 
> > > Tomcat
> > > 9
> > > was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm.
> > > resteasy3.0
> > > and tomcatjss are the only packages apart from i2p that still depend on
> > > libtomcat9-java.
> > 
> > Nice, so you expect them to migrate after bookworm is already frozen?
> 
> Targeted fixes are still allowed. Including required tomcat9 classes in your
> package may be a solution too. If you can find an agreement with the security
> and release team, then even shipping libtomcat9-java might be possible. But
> then your packages will not receive any security support. 

I've added the release team to Cc, since trying to force a tomcat 9 -> 10 
transition after the start of the transition freeze and after the start of
the soft freeze sounds forbidden to me.

cu
Adrian

Bug#1033319: Suggestions for ReleaseCheckList

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Suggestions for both
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BookwormCheckList


  Before the release

Add "Notify the LTS team of the new debian-archive-keyring"


  After the release
[ ] Propose a micronews item on the #debian-publicity IRC channel

Should this be a subitem of "Notify the publicity team"
in "While Releasing"?


  After the release
[ ] Update the Project History document and upload to stable-p-u

This could be moved to (and uploaded) "Before the release".


  After the release
[ ] Check with udd maintainers that the hardcoded values are updated (see 
SuitesAndReposExtension#udd)
[ ] Check with buildd team that buildds know about trixie. (see 
SuitesAndReposExtension#wanna-build)

IMHO these should be moved to "Before the release", otherwise there might be
stress for people who realize at short notice that urgent work has to be done.


  After the release
[ ] Check with other service/package maintainers that all the other 
hardcoded suite names or codenames are updated

IMHO this should be moved to "Before the release", otherwise there might be
stress for people who realize at short notice that urgent work has to be done.

It should link to SuitesAndReposExtension, or be replaced with a list whom to 
notify,

Bug#1033313: OpenSSL 3 binNMUS for experimental

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libewf_20171104-1 . ANY . experimental . -m "Rebuild against libssl3"
nmu libre_2.0.1-1 . ANY . experimental . -m "Rebuild against libssl3"
nmu psi-plus_1.4.1456-2 . ANY . experimental . -m "Rebuild against libssl3"
nmu tinc_1.1~pre18-1 . ANY . experimental . -m "Rebuild against libssl3"

Re: EC SRM key for bookworm?

[Adrian Bunk]

On Fri, Mar 10, 2023 at 09:27:30AM +, Adam D. Barratt wrote:
> On Sat, 2023-03-04 at 16:03 +0200, Adrian Bunk wrote:
> > On Sat, Mar 04, 2023 at 01:33:13PM +, Adam D. Barratt wrote:
> > > SRM is considering using an ed25519 GPG key for bookworm. Does
> > > anyone
> > > see any issues with that?
> > > ...
> > > We know that GPG(V) 1.X can't handle EC keys,
> > > ...
> > 
> > in all releases from stretch to bookworm:
> >   Package: apt
> >   Depends: ..., gpgv | gpgv2 | gpgv1, ...
> > 
> > This has to become only[1] "gpgv" in at least bullseye and bookworm,
> > otherwise there would be users running into problems - even in
> > unstable "apt-get remove gpgv" works and installs "gpgv1" instead.
> 
> FWIW I can't replicate that on bullseye:
> 
> $ sudo apt-get remove gpgv
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
> [...]
> Use 'sudo apt autoremove' to remove them.
> The following packages will be REMOVED:
>   apt apt-utils debian.org debian.org-recommended debian.org-
> recommended-bullseye devscripts gnupg gpgv
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
>   apt gpgv (due to apt)
>...

Using fresh chroots created with
  debootstrap bullseye bullseye
and
  debootstrap sid sid
as testcases, apt in unstable does find the solution of installing gpgv1 
when removing gpgv but apt in bullseye does not.

But the following should always work:
# apt-get install gpgv1
# apt-get remove gpgv

And something like this might have happened for various odd reasons in 
the past years.

> Regards,
> 
> Adam

cu
Adrian

Re: EC SRM key for bookworm?

[Adrian Bunk]

On Sat, Mar 04, 2023 at 01:33:13PM +, Adam D. Barratt wrote:
>...
> Hi,

Hi Adam,

> SRM is considering using an ed25519 GPG key for bookworm. Does anyone
> see any issues with that?
>...
> We know that GPG(V) 1.X can't handle EC keys,
>...

in all releases from stretch to bookworm:
  Package: apt
  Depends: ..., gpgv | gpgv2 | gpgv1, ...

This has to become only[1] "gpgv" in at least bullseye and bookworm,
otherwise there would be users running into problems - even in
unstable "apt-get remove gpgv" works and installs "gpgv1" instead.

> Thanks,
> 
> Adam

cu
Adrian

[1] The "gpgv2" alternative is harmless but pointless since it
became a transitional package depending on "gpgv".

Bug#1032245: ddnet needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

The s390x binary no longer builds and has been removed (see #1025884),
but due to binary-any + binary-all the autopkgtest is still attempted
and runs into the same build error.

Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore

[Adrian Bunk]

Package: release.debian.org
Severity: normal

With the bookworm-ignore for #994758, bullseye and bookworm
will ship libsgutils2-2 packages with different so-name.

This means mixing bullseye/bookworm libsgutils2-2 and rdeps
would be brokwn in either direction.

My plan to resolve this is:
1. RC bug against libsgutils2-2 for Breaks against pre-bookworm
   versions of rdeps
2. RC bug against libsgutils2-2 to drop the symbols file,
   to ensure that rebuilt packages will depend on the bookworm version
3. Request binNMUs for rdeps to pick up stricter dependencies after 2.

Please confirm that this is the correct action
(this bug might then also be used for the binNMUs).

Bug#1031920: upstream-ontologist and lintian-brush need hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Mixing of testing/unstable upstream-ontologist/lintian-brush in either
direction gives a test-only failure due to a test adapted to changed output.


lintian-brush/unstable with upstream-ontologist/testing:

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lintian-brush/31658430/log.gz

...
FAIL: fixer test: configure for upstream-metadata-file
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.c3g0u400/downtmp/build.QVr/src/lintian_brush/tests/fixers.py",
 line 153, in runTest
self.assertEqual(stdout.decode().strip(), f.read().strip())
AssertionError: 'Set [89 chars]nty: certain\nFixed-Lintian-Tags: 
upstream-met[17 chars]sing' != 'Set [89 chars]nty: 
possible\nFixed-Lintian-Tags: upstream-me[18 chars]sing'
  Set upstream metadata fields: Bug-Submit (from ./configure), Name (from 
./configure).
- Certainty: certain
+ Certainty: possible
  Fixed-Lintian-Tags: upstream-metadata-file-is-missing
...


lintian-brush/testing with upstream-ontologist/unstable:

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lintian-brush/31650963/log.gz

...
FAIL: fixer test: configure for upstream-metadata-file
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.o1uoy7bm/downtmp/build.8P4/src/lintian_brush/tests/fixers.py",
 line 153, in runTest
self.assertEqual(stdout.decode().strip(), f.read().strip())
AssertionError: 'Set [89 chars]nty: possible\nFixed-Lintian-Tags: 
upstream-me[18 chars]sing' != 'Set [89 chars]nty: certain\nFixed-Lintian-Tags: 
upstream-met[17 chars]sing'
  Set upstream metadata fields: Bug-Submit (from ./configure), Name (from 
./configure).
- Certainty: possible
+ Certainty: certain
  Fixed-Lintian-Tags: upstream-metadata-file-is-missing
...


Unstable autopkgtest is all green:
https://ci.debian.net/packages/l/lintian-brush/

Updating both in testing is also green:
https://ci.debian.net/packages/l/lintian-brush/testing/i386/

Bug#1031589: Handling of RC bugs in firefox-esr

[Adrian Bunk]

On Fri, Feb 24, 2023 at 12:27:35PM +0100, Emilio Pozuelo Monfort wrote:
> On 24/02/2023 09:48, Adrian Bunk wrote:
> > On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote:
> > > ...
> > > Also note that one of the concerns was for armhf, which is now being built
> > > from arm64 buildds.
> > > ...
> > 
> > On armhf there is a 4 GB FTBFS for the future (like on i386),
> > and a 3 GB FTBFS today that still seems to be present on some buildds.
> > 
> > While some armhf buildds have a 4 GB userspace address space that is
> > sufficient at least today, several buildds still run into the
> > debian/rules test for 64bit:
> > https://buildd.debian.org/status/logs.php?pkg=firefox=armhf
> > https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf
> > 
> > arm-ubc-0* had out of memory before the debian/rules test for 64bit,
> > so there might be a genuine issue that firefox-esr cannot be built
> > on these buildds and still might have to be blacklisted:
> > https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1
> 
> My understanding was that those buildds were going to be decommissioned. But
> if that's not going to happen in the short term, a blacklist for firefox-esr
> and thunderbird would be in order.

antheil/hartmann/hasse/henze/hoiby have been decommissioned as planned.

I do not know whether arm-ubc-0{4,5,6} are also planned to be 
decommissioned, as of right now they are still running.

> Cheers,
> Emilio

cu
Adrian

Bug#1031589: Handling of RC bugs in firefox-esr

[Adrian Bunk]

On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote:
>...
> Also note that one of the concerns was for armhf, which is now being built
> from arm64 buildds.
>...

On armhf there is a 4 GB FTBFS for the future (like on i386),
and a 3 GB FTBFS today that still seems to be present on some buildds.

While some armhf buildds have a 4 GB userspace address space that is 
sufficient at least today, several buildds still run into the 
debian/rules test for 64bit:
https://buildd.debian.org/status/logs.php?pkg=firefox=armhf
https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf

arm-ubc-0* had out of memory before the debian/rules test for 64bit,
so there might be a genuine issue that firefox-esr cannot be built
on these buildds and still might have to be blacklisted:
https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1

> Cheers,
> Emilio
>...

cu
Adrian

Bug#1031589: Handling of RC bugs in firefox-esr

[Adrian Bunk]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: Maintainers of Mozilla-related packages 

Control: block 1021810 982794 992150 993659 993660 by -1

popcon is no longer a criteria for key packages, which makes
firefox-esr subject to autoremoval that would be permanent
for bookworm at this point of the freeze.

Currently firefox-esr is on the autoremoval list due to 5 RC bugs.

While my personal opinion is that Debian should follow Ubuntu
which is now providing Chromium and Firefox only as snap
(perhaps using a different similar technology like flatpak),
not providing Firefox as a package in bookworm due to autoremoval
based on some random RC bug would be wrong.

If for some reason firefox-esr would intentionally not be shipped
in bookworm, then reverse dependencies currently on the autoremoval
list should get RC bugs for getting the chance to adapt.

It would be good if a release team member could review which RC bugs
in firefox-esr should be downgraded/ignored/fixed for bookworm.

Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm

[Adrian Bunk]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: Dominic Hargreaves , Debian Request Tracker Group 

Control: block 1030749 by -1

https://release.debian.org/testing/freeze_policy.html#soft

...
Dropping or adding binary packages to a source package, moving binaries between 
source packages or renaming source or binary packages is no longer allowed. 
Packages with these changes will not be allowed to migrate to testing. These 
changes are also no longer appropriate in unstable.
...


The problem is that opening of #1030749 is de facto
a request-tracker4 -> request-tracker5 transition that
happened 4 weeks after the deadline for transitions.


There are two options for resolving this:
1. Treat #1030749 as a forbidden transition and ship both versions
   of request-tracker in bookworm, or
2. grant reverse dependencies an exception from the soft freeze
   rules for the request-tracker4 -> request-tracker5 transition.


For option 2 I looked at the 9 reverse dependencies of request-tracker4
in the autoremoval list:

RT extension installer that has to stop depending on
both versions:
- libmodule-install-rtx-perl

No package remame required, has to upgrade to the upstream version
that supports request-tracker5:
- librt-extension-commandbymail-perl

Ships packages for both versions and has to drop the
request-tracker4 package:
- rt-extension-assets-import-csv

request-tracker4 -> request-tracker5 transition prepared
in experimental:
- rt-extension-customfieldsonupdate
- rt-extension-calendar
- rt-extension-jsgantt
- rt-extension-nagios
- rt-extension-smsnotify

Update to latest upstream version and package rename required:
- rt-extension-repeatticket

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Fri, Feb 17, 2023 at 09:28:59PM -0500, Theodore Ts'o wrote:
> On Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote:
> > 
> > The same general problem applies in various "building non-Debian 
> > embedded Linux filesystem on Debian" situations where the target
> > chroot does not contain mkfs.ext4.
> 
> In practice, if the root file system is using ext4, the target chroot
> has to have e2fsprogs installed so that fsck.ext4 exists.  So I'm not
> sure it's all that unreasonable?
>...

In Yocto e2fsprogs-e2fsck and e2fsprogs-mke2fs are separate packages.


The general problem is also not limited to mkfs.

The target might have busybox tar, but you might want to use GNU tar for 
generating tarballs that will be unpacked on the target.

I have once seen some old version of busybox tar choke on some specific 
tarball generated by GNU tar, but that's not a reason for a general rule 
that all tarballs that might be unpackaged on the target must be created 
by busybox tar.


I do see your point that reducing differences between host tools and 
target can be desirable, but there are limits how far this is feasible
or whether it is the best solution in a given situation.

When differences exist, it is the responsibility of the image creation 
tools to deal with the differences.


> Best regards,
> 
>   - Ted

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote:
>...
> So enabling what may be
> convenient, but ultimately an anti-pattern is something that hopefully
> in the long-term Debian should be striving towards.  Yes, it's
> annoying and and extra work.  So is using build chroots if we are
> building packages for a older Distro versions.  But it's the right
> thing to do.

Don't assume "host = target" would always be possible.

Your proposed solution only works for the trivial
"building Debian on Debian" case.

The same general problem applies in various "building non-Debian 
embedded Linux filesystem on Debian" situations where the target
chroot does not contain mkfs.ext4.

Or if it is present, it would be a chroot for the target architecture 
where you might have to run mkfs.ext4 under qemu.

All image building tools that support bookworm (including all image 
building tools we ship in bookworm) have to ensure that what they
produce works on the intended target. There is no general solution
*how* to do that that could be applied in all cases.

> Secondly, (b) there may be a misapprehension that it is possible to
> get an identical file system just by controlling the contents of
> mke2fs and/or specifying the file system features on the command line.
>...

It is clear that different versions of tools like mkfs.ext4 or gzip 
might produce different output.

If identical results matter, you can just define $distribution as
build environment and then expect that for example the host tools
from Debian bookworm will always create the same output when building
a Yocto distribution.

> Best regards,
> 
>   - Ted

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 03:05:06PM -0800, Russ Allbery wrote:
>...
> Each time you change the defaults in a way that could be
> backward-incompatible, you could capture those new defaults in a
> permanently-fixed label of, say, 20230616, which is the defaults on that
> date.  Probably in the default /etc/mke2fs.conf.  I don't expect you to
> care about what systems they work with, what distributions they work with,
> or anything else other than the timeline of when you decided to change the
> defaults, something you're presumably already doing as a maintainer.  The
> only additional work would be to update these labels with the settings
> required to make mke2fs with its current defaults behave compatibly with
> whatever the defaults had been at each of those captured points in time.
> 
> (And obviously eventually you could drop the really old ones if it made no
> sense to keep supporting them, or have some single really-ancient fallback
> for really old systems, etc.)
> 
> Then, image creators can look in /etc/mke2fs.conf for the timestamp that
> most closely aligns with the target system they want to create and use
> that group of settings.  If that turns out to be inadequate, they can go
> back to a previous date.

The image creators could just set the features they enable to what they 
copied from /etc/mke2fs.conf from the target distribution, a label with 
a timestamp wouldn'tbring much benefit here.

We are talking about tools for creating filesystems and their authors,
users of these tools don't have to know anything about all that.

> Some work on their part is still required, but
> from their perspective I think this would have the advantage of not having
> to do research to reconstruct what all the options could be and how they
> changed and which ones were potentially backward-incompatible, which are
> all things you would generally already know and have in mind when you
> changed the defaults and thus could capture for them.
>...

Image creators usually support several different filesystems.

There is also the point that a tool in bookworm that supports creating 
bullseye images will also support creating bookworm images, so when 
there is a difference in the settings for bullseye and bookworm images
it should anyway be updated for the difference. Setting a new default
for bookworm or disabling a new feature for <= bullseye, the work is
trivial in any case and the hard part is all image creators being aware
that there is a difference.

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 05:24:04PM -0500, Theodore Ts'o wrote:
>...
> and that moving forward, we make it the image building tools
> problem if they want to support this highly dubious practice of using
> Debian N+X's mkfs to build images for Debian N.
>...

That's what they already have to do for many years.

But it is also our problem when we ship these image building tools,
to ensure that there are bugs against all of them that get fixed
before the release where the change is present.

> Best release engineering practice is that you use a known, controlled
> build environment, and not whatever random package versions might be
> on your desktop.  While that might be "inconvenient" when building
> packages, we've learned to live with it.  I use sbuild; others might
> use pbuild, or their own custom schroot setup.  But I dare say all
> responsible people doing release engineering use a known build
> environment.  Why should this be any different if you are building
> images --- especially images that you expect *your* users or customers
> to be depending on?
>...

controlled != identical to the target

There are different approaches to this problem with different advantages 
and disadvantages.

It is not unreasonable for an image building tool we ship in bookworm to 
use the host tools of a bookworm x86 server to create a Debian image for 
a buster ARM target.

>   - Ted

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>...
> Instead, turning on this feature should be postponed for the next release 
> cycle
> where a proper transition can be done.
>...

On Thu, Feb 16, 2023 at 08:02:11PM +0100, Daniel Leidert wrote:
>...
> You completely miss the point here. It would lead to exactly the same
> situation if 2.07 would be the *first* to support it and could be
> shipped with Bookworm as long as e2fsprogs makes this breaking change
> now. But it makes a huge difference if 2.07 with a fix is released in
> around the same time as Bookworm and can spread until Trixie is
> prepared and the breaking change is postponed to Trixie.
>...

You are contradicting yourself by first unconditionally approving making 
the change in trixie, but later trying to make this conditional on grub 
making a new upstream release around the same time as Bookworm.

We can only control what is in Debian releases, we cannot be waiting
for godot^Wgrub making a new release before making a change in Debian.

The best default assumption when discussing whether the change should be 
made in bookworm or trixie is that there will be no new grub release 
during the next 2 years - it's only 2 years since the latest release
and there was even a 5 year gap between 2.00 and 2.02.

> Daniel

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

Disclaimer:
Like everyone else except Sebastian who commented in this bug so far,
I am not a member of the release team.

Below is my attempt to give an overview of the situation,
feel free to amend/correct if anything is missing or wrong.


1. Image creation tools need special cases for older distibutions

Image creation tools that support installing older/other
distributions must be able to handle such differences in general
(e.g. debootstrap has code to handle apt-transport-https being
required in some older releases), and have to add the (trivial)
support for this difference.

Sebastian has already created #1031364 for the original vmdb2 problem.


2. How many packages are affected?

There are to at least two classes of affected packages:
- Bootloaders that can read (or even write) ext4.
- Image creation tools in bookworm that can create < bookworm images

For both classes it is unclear how many packages still require fixing.

This is a major unclear question.


3. Image creation versus target usage

The original #1030846 was from Debian Installer developers,
and everything discussed there is around image creation.

The original discussion was about installing bookworm from bookworm.

Daniel is discussing installing older/other distributions from bookworm.

Noone seems to have discussed on-target usage, e.g. when arguing in 
#1030846 why there would not be a need for
   Breaks: grub2-common (<< 2.06-8~)
in e2fsprogs.

The version of e2fsprogs currently in bookworm is in bullseye-backports,
if the version with the new default goes into bookworm and unchanged
into bullseye-backports it's pretty obvious how this could screw
on-target users ("target" might also be called "desktop" or "server")
when creating new bootable partitions.


4. e2fsprogs should add Breaks on non-fixed versions of packages

For e2fsprogs in bullseye-backports such Breaks might only be a reminder 
that both the Breaks and the changed default should be reverted there, 
but in bookworm it would ensure that users don't end up with an 
incompatible combination of packages (e.g. if an older version of
grub or an image creation tool is pinned in apt).


5. Combination/Mix of packages from two adjacent Debian releases should work

A rule of thumb is that any combination/mix of packages permitted by the 
package manager from two adjacent Debian releases should work whenever 
reasonably possible, since this reduces problems for our users during an 
upgrade, when using backports, or when temporarily going back to the 
version of a package from the previous stable due to a regression.

The normal case (e.g. shared library linking) is that package 
dependencies ensure that package managers will only permit working 
combinations of packages.

Do we have any case where mixing bullseye and bookworm would not work 
with Breaks on all unfixed versions of bootloaders and image creation tools?


6. Any data/experience from metadata_csum enabled by default in stretch?

There seems to have been a similar situation with metadata_csum being 
enabled by default in stretch.

What data/experience exists about required fixes and problems from
that change?


7. It is late in the release cycle for such a change

The answer to point 2 is relevant whether it might be too late.


8. User documentation should document such incompatible changes

In whatever release this feature gets enabled by default,
a fresh bug against the release-notes pseudo-package with text
describing the incompatibility and possible workarounds should
be filed (Ted has already provided a draft text[1]).


9.There seems to be a similar situation with XFS bigtime

XFS is a less common filesystem, but what is discussed above
might also apply there.


10. Documentation for installing Debian from other distributions

Instructions for installing Debian from other distributions
need updating in any case.

Anything like [2] in the Bullseye Installation Guide will
be broken as soon as a different distribution changes the
default and needs updating, no matter what Debian does
in bookworm.


cu
Adrian

[1] https://lists.debian.org/debian-release/2023/02/msg00250.html
[2] https://www.debian.org/releases/stable/amd64/apds03.en.html

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 08:02:11PM +0100, Daniel Leidert wrote:
>...
> Most server providers have exctly *one*
> rescue system from where I can do a clean installation with deboostrap
> (and that even usually is a Debian). I cannot choose to use one that
> hasn't an e2fsprogs that has this breaking change enabled. Say for
> example, grml, used by multiple providers I know as rescue system and
> based on Debian, picks up Bookworm with e2fsprogs with that change. Now
> users trying to install anything other than a Debian Bookworm using the
> deboostrap method will run into the situation that "grub-install" will
> fail, and it won't even indicate that they will have to tune the just
> created ext4 filesystem or even change /etc/mke2fs.conf.
>...

You are saying that a bug report is needed against grml-debootstrap for
disabling metadata_csum_seed in <= bullseye?

The fix would likely be right next to the code that disables the new
metadata_csum default in stretch for <= jessie where it was not supported.

> Daniel

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> > > ...
> > > Reasons:
> > > ...
> > > - - the change makes it impossible to create filesystems with this 
> > > version of
> > >   e2fsprogs and then run a grub-install from a target system that does 
> > > not cope
> > >   with that feature; basically breaking the debootstrap method of 
> > > installing
> > >   Debian or Ubuntu onto a server (violating #4 of the Debian social 
> > > contract)
> > > ...
> > > Instead, turning on this feature should be postponed for the next release 
> > > cycle
> > > where a proper transition can be done.
> > > ...
> > 
> > Daniel, you are contradicting yourself when claiming that a change that 
> > would allegedly violate the Debian social contract could be done in the 
> > next release cycle.
> 
> Actually, I'm not.
>...

If not being able to install bullseye from bookworm is a violation of 
the Debian social contract, then the same rationale applies to not
being able to install bullseye from trixie being a violation of
the Debian social contract.

In [1] you are arguing with problems installing Ubuntu 20.04 this
way from bookworm with the e2fsprogs change, the same will apply
to installing Ubuntu 22.04 from trixie.

QED

> I have also written in [1] how I think the transition
> should be handled (IMO)
>...

I am currently spending time trying to summarize the situation and open
questions, and I am a bit underwhelmed by the inaccuracies and lack of
technical detail in your emails.

The instructions you cite in [1] are for installing bullseye from
non-Debian systems. What bookworm ships does not matter much there,
these instructions will be wrong as soon as some *other* distribution
like Fedora changes the default.

I am wondering how exactly your often repeated "there is no grub 
upstream release with support for it" would be relevant in practice.
Whether it's 2.06-8 or 2.07-1 in bookworm shouldn't make a difference.

Sebastian has now created #1031364 for your original vmdb2 problem, 
everyone discussing in #1030939 seems to have missed that tools in 
bookworm creating images for < bookworm must handle such changes.
That's not different from debootstrap having code to handle 
apt-transport-https being required in some older releases.

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030939#108
> 
> Regards, Daniel

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>...
> Reasons:
>...
> - - the change makes it impossible to create filesystems with this version of
>   e2fsprogs and then run a grub-install from a target system that does not 
> cope
>   with that feature; basically breaking the debootstrap method of installing
>   Debian or Ubuntu onto a server (violating #4 of the Debian social contract)
>...
> Instead, turning on this feature should be postponed for the next release 
> cycle
> where a proper transition can be done.
>...

Daniel, you are contradicting yourself when claiming that a change that 
would allegedly violate the Debian social contract could be done in the 
next release cycle.

> Daniel Leidert

cu
Adrian

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Adrian Bunk]

On Wed, Feb 15, 2023 at 09:05:28PM +0800, Shengjing Zhu wrote:
> On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu  wrote:
> >
> > On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> > >
> > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > > >...
> > > > The package currently FTBFS on i386/experimental but it won't be 
> > > > problem on
> > > > unstable.
> > > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > > which has a bug https://github.com/golang/go/issues/51850.
> > > > But on unstable the dep-resolver is apt, and will choose old golang-go 
> > > > to
> > > > bootstrap.
> > > >...
> > >
> > > I gave it back on the affected architectures with an extra-depends on
> > > golang-go, which confirmed that the package builds there.
> > >
> > > But relying on resolver behaviour is incredibly fragile, please make
> > > golang-go the only (or at least the first) alternative in the build
> > > dependencies.
> >
> > In theory gccgo should be able to bootstrap golang-go.
> > And we do use gccgo to build golang-go on ppc64, and haven't met any
> > problem so far.
> > The new affected arch is because of lack of exercise, so nobody is
> > aware of this.
> > Now they are tracked at #1031349.
> >
> 
> And regarding make golang-go the first alternative, currently we have:
> + Build-Depends golang-any | golang-go | gccgo
> + golang-any Depends golang-go | gccgo-go
> Is there anything we can improve for aspcud resolver?

The resolver is not to blame for a bug in the build dependencies.

In unstable and experimental only the first alternative is considered,
therefore
  Build-Depends: golang-go | ...
would instruct the resolver to install golang-go.

Safest would be to not offer any alternatives in the build dependencies,
instead create a profile for bootstrapping golang-go from gccgo.

> Shengjing Zhu

cu
Adrian

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Adrian Bunk]

On Wed, Feb 15, 2023 at 08:53:13PM +0800, Shengjing Zhu wrote:
> On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk  wrote:
> >
> > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
> > >...
> > > The package currently FTBFS on i386/experimental but it won't be problem 
> > > on
> > > unstable.
> > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> > > which has a bug https://github.com/golang/go/issues/51850.
> > > But on unstable the dep-resolver is apt, and will choose old golang-go to
> > > bootstrap.
> > >...
> >
> > I gave it back on the affected architectures with an extra-depends on
> > golang-go, which confirmed that the package builds there.
> >
> > But relying on resolver behaviour is incredibly fragile, please make
> > golang-go the only (or at least the first) alternative in the build
> > dependencies.
> 
> In theory gccgo should be able to bootstrap golang-go.
>...

That misses my point, which is that when there are several options
the package should define and ensure which one is used.

Every buildd and every QA build and every build elsewhere should use the 
same tools for building the package.

Otherwise people might end up wasting hours and days trying to 
understand why a package that built in unstable failed to build
somewhere else (in experimental or reproducible builds or in
a derivative distribution or elsewhere).

Or even worse, if for some reason the package builds but produces 
different binaries and then someone tries to debug why this happened.
That shouldn't happen, but these are absolutely nasty and time-consuming
bugs.

> Shengjing Zhu

cu
Adrian

Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2

[Adrian Bunk]

On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote:
>...
> The package currently FTBFS on i386/experimental but it won't be problem on
> unstable.
> The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap,
> which has a bug https://github.com/golang/go/issues/51850.
> But on unstable the dep-resolver is apt, and will choose old golang-go to
> bootstrap.
>...

I gave it back on the affected architectures with an extra-depends on 
golang-go, which confirmed that the package builds there.

But relying on resolver behaviour is incredibly fragile, please make 
golang-go the only (or at least the first) alternative in the build 
dependencies.

cu
Adrian

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Adrian Bunk]

On Tue, Feb 14, 2023 at 08:46:53PM -0500, Theodore Ts'o wrote:
>...
> I will draw the analogy of building a program which links against
> glibc for Bookworm resulting in a binary that will not run on Buster.
> We expect that, and we tell people to use build chroots.  This is not
> something which is actionable, and we don't hold back glibc updates
> just because you can no longer build on Debian 10.0 something that
> won't work on Debian 9.0, or 8.0.
>...
> We can change the default for mke2fs.conf file for Debian.  I don't
> think it's warranted, and I'm not aware of any other distribution
> doing this.  The fact that file system featuers that fix certain
> problems (such as the 2038 bug) will cause older versions the
> distribution to fail to accept that file system is always going to be
> the case.  So how long do we hold back some new feature?  A year?  Two
> years?  Five years?  Ten years?  Again, we don't do this with shared
> library linkages; we just tell people to use a build chroot.
>...
> So if we are to hold e2fsprogs and xfsprogs to the standard that a
> file system created by default must work on all older Debian and
> Ubuntu distributions to some arbitrary point in history,
>...

A rule of thumb is that any combination/mix of packages permitted by the 
package manager from two adjacent Debian releases should work whenever 
reasonably possible, since this reduces problems for our users during 
an upgrade, when using backports, or when temporarily going back to the 
version of a package from the previous stable due to a regression.

For normal library dependencies
  Depends: libc6 (>= 2.34)
will do the right thing automatically.

e2fsprogs adding Breaks against older versions of bootloaders and other 
software that lacks support for the new default might be a good idea.

The situtation is different when a relationship cannot be reliably 
expressed by package dependencies.

For the kernel the answer to your "how long" is that packages should 
also work with the kernel from the previous and the kernel from the
next Debian release.

Some time ago there was a discussion regarding Qt in Debian 10 using the
getrandom syscall that was not available in the kernel in Debian 8.
This was not considered supported (or supportable) since Debian 8 and
Debian 10 are not adjacent releases, but Qt in Debian 10 using a feature
not supported by the kernel in Debian 9 might have resulted in a lot of
problems when still running the old kernel during or after an upgrade
from Debian 9 to Debian 10.

If the feature stays enabled by default in bookworm:
Everyone using grub is an x86 thing, for embedded ARM it is more common 
to use a once ported ancient u-boot on your hardware forever.[1]
A bug against the release-notes pseudo-package with text describing
the incompatibility and possible workarounds would be appreciated.

> Best regards,
> 
>   - Ted

cu
Adrian

[1] u-boot in bullseye does already "support" metadata_csum_seed
by refusing to write to filesystems that have it enabled:

https://salsa.debian.org/debian/u-boot/-/commit/2e7365518acdb8fb6e9be332c8a6c57b457188d9

Re: reason for removal of zeroc-ice on armhf and arm64.

[Adrian Bunk]

On Tue, Feb 14, 2023 at 11:56:40AM +, Peter Green wrote:
> I recently became aware that mumble's build-dependencies were no longer
> satisfiable on armhf due to a missing zeroc-ice. I looked at the build
> logs for zeroc-ice and all were green. So I looked at the removal log
> and found the following.
> 
> > [Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott Kitterman]
> > Removed the following packages from unstable:
> > 
> > libzeroc-ice-dev |  3.7.8-2.1 | arm64, armhf
> > libzeroc-ice3.7 |  3.7.8-2.1 | arm64, armhf
> > libzeroc-icestorm3.7 |  3.7.8-2.1 | arm64, armhf
> > mumble-server |1.3.4-4 | arm64, armhf
> > php-zeroc-ice |  3.7.8-2.1 | arm64, armhf
> > python3-zeroc-ice |  3.7.8-2.1 | arm64, armhf
> > zeroc-glacier2 |  3.7.8-2.1 | arm64, armhf
> > zeroc-ice-compilers |  3.7.8-2.1 | arm64, armhf
> > zeroc-ice-utils |  3.7.8-2.1 | arm64, armhf
> > zeroc-icebox |  3.7.8-2.1 | arm64, armhf
> > zeroc-icebridge |  3.7.8-2.1 | arm64, armhf
> > zeroc-icegrid |  3.7.8-2.1 | arm64, armhf
> > zeroc-icepatch2 |  3.7.8-2.1 | arm64, armhf
> > Closed bugs: 1031160
> > 
> > --- Reason ---
> > RoQA; openjfx no longer builds on arm64 and armhf, build-depends not 
> > available
> 
> This strikes me as strange in a couple of ways.
> 
> 1. The only relationships of zeroc-ice to openjfx are in build-depends-indep
>and in the binary dependencies of an arch all package. Afaict it is 
> perfectly
>normal for build-depends-indep and the binary dependencies of arch all
>packages to only be satisfiable on a subset of the architectures where
> 2. Only one of the two binaries from the mumble source package was removed.
> 
> Was this removal just a mistake? or was there a reason behind it that I am not
> seeing?

As requestor of #1031160 I would say this was a mistake,
perhaps due to

https://tracker.debian.org/pkg/openjfx
Issues preventing migration:
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
beast2-mcmc/2.7.3+dfsg-1/arm64 uninstallable
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
josm/0.0.svn18646+dfsg-1/arm64 uninstallable
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
pdfsam/4.3.4-1/arm64 uninstallable

This will require a hint from the release team I have not yet requested,
since installability of binary-all packages is tested on amd64 and arm64
but there is no requirement that a binary-all package is installable on
arm64 and several are not.[1]

cu
Adrian

[1] https://release.debian.org/britney/testing_uninst.txt

Bug#1031182: Packages that might miss bookworm only due to s390x autopkgtest slowness

[Adrian Bunk]

Package: release.debian.org
Severity: normal

The s390x autopkgtest is very slow recently, below is the list
of packages that would miss bookworm only due to that.
It would be good it packages would not miss bookworm only due to
autopkgtest slowness.


# 2 of 2 days old after the s390x autopkgtest ran
python-pantomime
rust-configparser
rust-lewton
rust-libsodium-sys
rust-test-dir

# already 5 of 5 days old
# blocked by slurm-wlm still waiting for s390x autopkgtest after 5 days
slurm-wlm-contrib

Bug#1031181: Ageing request for packages that were in bullseye

[Adrian Bunk]

Package: release.debian.org
Severity: normal

When packages disappear in one Debian release that were in the
previous one, that's a regression for users who were using them.
In many cases this is not avoidable, but it is suboptimal if age
in unstable was the only blocker from having a package that was
in bullseye also in bookworm.

The 5 packages below only need ageing (and ring also the
s390x autopkgtest) for that, it would be appreciated if
that could be done:

# 1 of 2 days old once the s390x autopkgtest ran
ring

# 3 of 5 days old
qpxtool
setcd
vienna-rna

# 4 of 5 days old
fonts-elstob

Bug#1030957: release.debian.org: please have rust-rustls ignore CI tests for s390x and ppc64el

[Adrian Bunk]

On Sat, Feb 11, 2023 at 08:48:55AM +0100, Paul Gevers wrote:
> Hi,
> 
> Disclaimer, I may be misunderstanding how things work, because I only judge
> it on observations and some comments in threads here and there.
> 
> On 11-02-2023 00:43, Adrian Bunk wrote:
> > I would be curious whether there is any technical reason why most
> > Go libraries are binary-all but most Rust libraries are binary-any.
> > 
> > Both choices look reasonable to me, but different ecosystems in Debian
> > seem to have made different decisions in the same situation.
> 
> I think go libraries are compiled statically into the other go binary
> packages, so the whole go world needs to be recompiled for security (or
> other) issues.
>...

Go libraries are source files like Rust libraries.

> Paul

cu
Adrian

Bug#1030957: release.debian.org: please have rust-rustls ignore CI tests for s390x and ppc64el

[Adrian Bunk]

On Fri, Feb 10, 2023 at 11:32:21AM +0100, Jonas Smedegaard wrote:
>...
> Reduced size in the archive: Avoids multiple identical copies of library
> source code
>...

I remember the 1990s when archive size was a problem, but a few
years ago we had the first file > 2 GB in the archive (AFAIR an 
.orig.tar.gz) and that was not a problem except for some fast fix
needed somewhere for files > INT_MAX.

> Reduced complexity of APT: Avoids replicated packaging metadata
>
> Avoids certain types of impossible-to-satisfy scenarios:
>...
> Yes, I am aware that the Rust team packages arch-all code as arch-any
> packages, but I am unaware that their reasoning is well documented
> anywhere.
>...

A scarce resource is human time. There are several people who know how 
Rust packages in Debian work. They can quickly make changes to any 
normal Rust package. If you package your Rust packages differently,
then it becomes harder and more time-consuming if anyone else ever has
to touch one of your packages (e.g. a security update for rust-rustls).

When your packages are "better" than the normal packages in an 
ecosystem, you have low benefits when most packages in the ecosystem 
stay "worse", while having the high costs associated with having 
different ways of packaging in the ecosystem.

Better benefits and fewer costs would be if you try to convince the 
ecosystem as a whole to change, and in any case use for your own 
packages whatever the ecosystem is doing.

>  - Jonas

cu
Adrian

Bug#1030957: release.debian.org: please have rust-rustls ignore CI tests for s390x and ppc64el

[Adrian Bunk]

On Fri, Feb 10, 2023 at 03:10:03PM -0700, Sam Hartman wrote:
> >>>>> "Jonas" == Jonas Smedegaard  writes:
> 
> 
> Jonas> Yes, I am aware that the Rust team packages arch-all code as
> Jonas> arch-any packages, but I am unaware that their reasoning is
> Jonas> well documented anywhere.  The only reason I was aware of
> Jonas> when I did the switch was that Debian has a convenient
> Jonas> processing of binNMUs but annoyingly require source-only
> Jonas> releases for rebuilding arch-all packages.
> 
> But the bin nmu issue is a huge deal.  I'm not sure for your case.  But
> Rust is statically linked, and so it is more likely than average to need
> bin nmus.  So if your packages will need to be rebuilt when their
> dependencies change (I am not sure if this is true for packages just
> containing crate source code), then moving from arch any to arch all
> makes things significantly more difficult for SRM, RT, security team,
> and  people doing QA woork.
> I'd definitely recommend reaching out to Adrian Bunk on this issue.

Built-Using in binary-all packages is a problem.
Extra-Source-Only means we might even have our mirrors serve sources 
that were removed from unstable years ago due to "not distributable".

No matter whether or not Built-Using is used (which should only be used
for licence compliance), the rebuild question might come up for
binary-all packages that contain binaries for an architecture that
is encoded in the package name (e.g. cross compiler libraries or
microcontroller firmware like firmware-microbit-micropython).

There are rare cases where binary-all python packages have to be rebuilt 
during every python transition, e.g. scripts that start with 
  #!/usr/bin/python3.11

And then there's the special PITA of the gcc-*-cross* packages that 
also make invalid assumptions like that the binary-any packages are not built 
after the binary-all packages from the same source package (otherwise 
the binary-any packages might have dependencies that cannot be fulfilled).

None of the above seems to apply to the package in question.

There is the real problem that all binaries that have been built using
rust-rustls might need rebuilding in security or stable when rust-rustls
gets a security or other important fix, but for that it does not make
any difference whether librust-rustls-dev is binary-any or binary-all.

> If on the other hand your packages aren't going to need to be rebuilt
> when their dependencies change, it may not be a big deal.

I would be curious whether there is any technical reason why most
Go libraries are binary-all but most Rust libraries are binary-any.

Both choices look reasonable to me, but different ecosystems in Debian 
seem to have made different decisions in the same situation.

cu
Adrian

Bug#1030993: agda+agda-stdlib need hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

binary-all packages are not installable on arm64,
where agda does FTBFS.

Bug#1030839: pyatem needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Migration status for pyatem (- to 0.8.2-1): BLOCKED: Rejected/violates 
migration policy/introduces a regression
Issues preventing migration:
∙ ∙ openswitcher/arm64 has unsatisfiable dependency
∙ ∙ openswitcher-proxy/arm64 has unsatisfiable dependency
∙ ∙ autopkgtest for pyatem/0.8.2-1: amd64: Pass, armel: Regression ♻ , armhf: 
Regression ♻ , i386: Pass, ppc64el: Regression ♻ , s390x: Regression ♻

The package currently builds only on x86 and mips* (and some ports 
architectures),
which makes:
- the binary-all package not installable on arm64, and
- autopkgtest FAIL badpkg

Bug#1030591: binNMUS for transitions in experimental

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: Andreas Beckmann 

# Qt
nmu linphone-desktop_5.0.2-2 . ANY . experimental . -m "Rebuild against 
qtbase-abi-5-15-18"
nmu mediastreamer2_1:5.2.0+dfsg-1 . ANY . experimental . -m "Rebuild against 
qtbase-abi-5-15-18"

# icu
nmu thunderbird_1:104.0~b2-1 . ANY . experimental . -m "Rebuild against 
libicu72"

# tiff
nmu dcmtk_3.6.8~git20221024.b8950f9-1 . ANY . experimental . -m "Rebuild 
against libtiff6"
nmu gimp_2.99.14-2 . ANY . experimental . -m "Rebuild against libtiff6"
nmu imagemagick_8:6.9.12.20+dfsg1-1.2 . ANY . experimental . -m "Rebuild 
against libtiff6"
nmu povray_1:3.8.0~beta.2-1 . ANY . experimental . -m "Rebuild against libtiff6"
nmu gnustep-gui_0.30.0-1 . ANY . experimental . -m "Rebuild against libtiff6"

# perl
nmu openldap_2.6.3+dfsg-1~exp1 . ANY . experimental . -m "Rebuild against perl 
5.36"

# python
nmu gemmi_0.5.8+ds-1 . ANY . experimental . -m "Rebuild with Python 3.11 as 
default"
nmu libsavitar_5.0.0-1 . ANY . experimental . -m "Rebuild with Python 3.11 only"
nmu pynest2d_5.0.0-1 . ANY . experimental . -m "Rebuild with Python 3.11 only"
nmu python-lrcalc_2.1-1 . ANY . experimental . -m "Rebuild with Python 3.11 
only"
nmu abpoa_1.4.1-4~0exp0simde . ANY . experimental . -m "Rebuild with Python 
3.11 only"
nmu fenics-basix_0.6.0-1exp1 . ANY . experimental . -m "Rebuild with Python 
3.11 only"
nmu htseq_2.0.2-1 . ANY . experimental . -m "Rebuild with Python 3.11 only"
nmu minimap2_2.24+dfsg-4~0exp . ANY . experimental . -m "Rebuild with Python 
3.11 only"
nmu fenics-dolfinx_1:0.6.0-1exp1 . ANY . experimental . -m "Rebuild with Python 
3.11 only"

Bug#1030531: More binNMUs for missing python3-h5py dependencies

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: Jochen Sprickerhof , Drew Parsons 


nmu pyfai_0.21.3+dfsg1-2 . ANY . unstable . -m "Rebuild to pick up python3-h5py 
dependency (see #1030220)"
nmu unifrac_1.2-3 . ANY . unstable . -m "Rebuild to pick up python3-h5py 
dependency (see #1030220)"
nmu xraylarch_0.9.58+ds1-5 . ANY . unstable . -m "Rebuild to pick up 
python3-h5py dependency (see #1030220)"


These are the ones I found with the same problem as #1030507 that are 
binNMUable.

Packages that require source uploads due to affected binary-all packages:
- binoculars (covered by reopening #1016598)
- hickle (#1030516)
- python-anndata (#1030512)
- python-bayespy (QA upload done)
- r-bioc-mofa (#1030514)

Re: mips64el/mipsel and testing migration

[Adrian Bunk]

On Sat, Feb 04, 2023 at 09:59:23AM -0500, Roberto C. Sánchez wrote:
>...
> If that is the case, then I am puzzled how intelrdfpmath would have
> migrated to testing without being able to build on mips64el/mipsel

intelrdfpmath having never been built on mips* is not an RC bug or
testing migration blocker for intelrdfpmath since there are no old
binaries of intelrdfpmath in unstable.[1]

> and
> it makes me think that I might need to be concerned that libmongocrypt
> might not migrate in time.

libmongocrypt is currently in testing, so the 12th is not a hard 
deadline here.

> If that is not the case, and the excuses are spurious because the lack
> of availability on mips64el/mipsel won't prevent testing migration, that
> would be good to know as well.
>...

libmongocrypt does have old binaries on mips* in unstable,
which blocks testing migration of libmongocrypt.

There are 3 options for handling this:

1. Is there a way to build libmongocrypt without intelrdfpmath?

2. Fixing intelrdfpmath on mips*

3. "reportbug ftp.debian.org" could be used to request removal of the 
old mipsel/mips64el binaries of libmongocrypt, but that requires first
making the build dependency in mongo-c-driver exclude architectures
where libmongocrypt is no longer available.
If !pkg.mongo-c-driver.no-libmongocrypt is still a usable configuration,
then [!mipsel !mips64el] could be used there.


I will look whether 2. is feasible. intelrdfpmath does build on not 
explicitely supported architectures like s390x, and MIPS might be a
victim of explicit support code that is now half-broken.


> Regards,
> 
> -Roberto

cu
Adrian

[1] https://release.debian.org/testing/rc_policy.txt

Packages must autobuild without failure on all architectures on
which they are supported. Packages must be supported on as many
architectures as is reasonably possible. Packages are assumed to
be supported on all architectures for which they have previously
built successfully. Prior builds for unsupported architectures
must be removed from the archive (contact -release or ftpmaster
if this is the case).

Bug#1029918: spring needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Issues preventing migration:
∙ ∙ spring-javaai/arm64 has unsatisfiable dependency

Package: spring-javaai
Architecture: all
Depends:
...
 spring (>= ${source:Version}),

Package: spring
Architecture: amd64 i386

The package was removed from testing in October due to an RC bug
that is now fixed.

#563686 explains why this package is x86-only.

Re: Bug#1029044: gcc-12-cross-mipsen: source and binary version go out of sync

[Adrian Bunk]

Control: tags -1 ftbfs
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10
Control: reassign -2 src:gcc-10-cross
Control: retitle -2 gcc-10-cross: source and binary version go out of sync
Control: reassign -3 src:gcc-10-cross-ports
Control: retitle -3 gcc-10-cross-ports: source and binary version go out of sync
Control: reassign -4 src:gcc-11-cross
Control: retitle -4 gcc-11-cross: source and binary version go out of sync
Control: reassign -5 src:gcc-11-cross-ports
Control: retitle -5 gcc-11-cross-ports: source and binary version go out of sync
Control: reassign -6 src:gcc-11-cross-mipsen
Control: retitle -6 gcc-11-cross-mipsen: source and binary version go out of 
sync
Control: block -6 by -4
Control: reassign -7 src:gcc-12-cross
Control: retitle -7 gcc-12-cross: source and binary version go out of sync
Control: block -1 by -7
Control: reassign -8 src:gcc-12-cross-ports
Control: retitle -8 gcc-12-cross-ports: source and binary version go out of sync
Control: reassign -9 src:gcc-13-cross
Control: retitle -9 gcc-13-cross: source and binary version go out of sync
Control: reassign -10 src:gcc-13-cross-ports
Control: retitle -10 gcc-13-cross-ports: source and binary version go out of 
sync

On Mon, Jan 16, 2023 at 09:21:52PM +0100, Paul Gevers wrote:
> Source: gcc-12-cross-mipsen
> Version: 1+c2
> Severity: serious
> 
> Dear maintainer,
> 
> The current version in unstable is stuck, because the mips64el build
> is kept in Uploaded state. Asking around on #d-buildd, I got the
> following discussion:
> 
> [20:09:34]  mips64el 3days in uploaded state feels like an issue, 
> right? https://buildd.debian.org/status/package.php?p=gcc-12-cross-mipsen
> [20:18:32]  probably means dak rejected it
> [20:18:45]  Your upload included the binary package 
> cpp-12-mips-linux-gnu, version 12.2.0-13cross1, for mips64el,
> [20:18:48]  however unstable already has version 12.2.0-14cross2.
> [20:19:09]  
> coccia:/srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c1_mips64el-buildd.changes.reason
> [20:29:57]  the higher version is
> [20:29:57]  Source: gcc-12-cross-mipsen (2+c1)
> [20:30:23]  so the generated version numbers are broken
> [20:32:07]  not for the first time afair
> [[21:04:30]  adsb: thanks for looking; but the source is 3+c1, no? or 
> did the older one generate a newer binary?
> 
> You may want to check your logic.

The packaging is copied from gcc-12-cross,
problems have to be fixed there first,
and also in the other gcc-*-cross* packages.

There are at least 3 problems:

1. The way debian/new_cross_version.sh uses "apt-cache policy" to create 
a version number makes the package not reproducible even if the same 
versions of the build dependencies are installed, and it also causes 
problems like this one here.

Other packages using {binutils,gcc-*,gdb}-source seem to get it right, e.g.:

Package: gcc-xtensa-lx106
Source: gcc-xtensa-lx106 (8)
Version: 10.2.1-6+8+b1
Built-Using: gcc-10 (= 10.2.1-6)

There is no reason why the gcc-*-cross* packages could not use similar 
versioning.


2. binary-any packages built from the same gcc-*-cross* packages 
currently have >= dependencies on binary-all packages built from
the same sources. Since the version number of the gcc-*-cross* packages
packages contains the version of the gcc-*-source package, this does
not only prevent binNMUs (which itself is already an RC bug) but also
similarly causes problems like #1028441 when packages are built later
on an architecture (in this case due to #1026129, which was caused by
#1026245 in src:gcc-12).

The correct solution is to make such binary-all packages binary-any,
which allows = dependencies and removes all such race conditions and
non-binNMUableness.


3. Built-Using in the binary-all packages is something that should IMHO 
become a non-overridable automatic REJECT in dak.

The gcc-*-cross* packages seem to avoid the 
built-using-field-on-arch-all-package
lintian tag by not declaring the Built-Using in debian/control, but 
adding it during the build.[1]

Example package: lib32gcc-s1-s390x-cross

I've just filed #1029633 asking for a lintian tag for that.


> Paul

cu
Adrian

[1] https://sources.debian.org/src/gcc-12/12.2.0-14/debian/rules.conf/#L1286

Bug#1027686: Rakudo transition is stuck ?

[Adrian Bunk]

On Fri, Jan 20, 2023 at 08:34:23PM +0100, Sebastian Ramacher wrote:
> On 2023-01-20 21:29:30 +0200, Adrian Bunk wrote:
> > On Fri, Jan 20, 2023 at 08:16:29PM +0100, Sebastian Ramacher wrote:
> > > Hi
> > > 
> > > On 2023-01-20 18:29:37 +0100, Dominique Dumont wrote:
> > > > Hi
> > > > 
> > > > Nothing is happening in rakudo transition [1], no package are rebuilt.
> > > > 
> > > > Is there a way to unblock this transition ?
> > > 
> > > I've now scheduled the binNMUs. Please take care of the FTBFS bugs filed
> > > against the involved packages.
> > 
> > The "FTBFS bugs" are #1023576 and duplicates of that.
> > 
> > Shouldn't this transition fix such bugs?
> 
> I didn't check. If that's case, somebody should reassign/merge/close as
> appropriate.

Done.

> Cheers

cu
Adrian

Bug#1027686: Rakudo transition is stuck ?

[Adrian Bunk]

On Fri, Jan 20, 2023 at 08:16:29PM +0100, Sebastian Ramacher wrote:
> Hi
> 
> On 2023-01-20 18:29:37 +0100, Dominique Dumont wrote:
> > Hi
> > 
> > Nothing is happening in rakudo transition [1], no package are rebuilt.
> > 
> > Is there a way to unblock this transition ?
> 
> I've now scheduled the binNMUs. Please take care of the FTBFS bugs filed
> against the involved packages.

The "FTBFS bugs" are #1023576 and duplicates of that.

Shouldn't this transition fix such bugs?

> Cheers

cu
Adrian

Bug#1028246: transition: liquid-dsp

[Adrian Bunk]

On Sun, Jan 08, 2023 at 10:11:46PM +0100, Andreas Bombe wrote:
>...
> i386 only, where some
> floats don't match exactly, which I'm still investigating.
>...

That's "better" results due to x87 excess precison.

The patch below fixes the tests for me.

cu
Adrian

--- debian/rules.old2023-01-08 21:43:47.055686585 +
+++ debian/rules2023-01-08 21:44:09.335667591 +
@@ -2,6 +2,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifeq ($(DEB_HOST_ARCH_CPU),i386)
+  export DEB_CFLAGS_MAINT_APPEND = -ffloat-store
+endif
+
 %:
dh ${@}
 

Bug#1004441: unblocking chromium?

[Adrian Bunk]

On Fri, Jan 06, 2023 at 10:18:16AM +0100, Moritz Muehlenhoff wrote:
>...
> We might consider to set some expectation for oldstable-security, though e.g 
> state that
> oldstable-security updates stop three months after the release of stable or 
> so.
> 
> Chromium is very fast-paced in toolchain changes (e.g. in the past new C++ 
> features
> become incompatible with GCC and we might see something similar with LLVM 
> (which
> is used these days) as well.

New LLVM versions are already added annually to *stable for Firefox, 
even in LTS (which got LLVM 13 last autumn in addition to 6, 7 and 11).

> Cheers,
> Moritz

cu
Adrian