Bug#1035017: unblock: pdl/1:2.081-2

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-04-29 13:13:03 +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 - moreinfo
> 
> On 4/29/23 10:51, Sebastian Ramacher wrote:
> > On 2023-04-27 16:52:36 +0200, Bas Couwenberg wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: unblock
> > > X-Debbugs-Cc: p...@packages.debian.org
> > > Control: affects -1 + src:pdl
> > > 
> > > Please unblock package pdl
> > > 
> > > [ Reason ]
> > > It fixed the upgrade failure from bullseye reported in #1034942.
> > > 
> > > [ Impact ]
> > > Upgrade from bullseye to bookworm fails.
> > > 
> > > [ Tests ]
> > > autopkgtest, Salsa CI, and upstream test suite.
> > > 
> > > I've manually verified the fix for #1034942 by upgrading a bullseye 
> > > chroot to bookworm using the fixed pdl from my local repo.
> > > 
> > > [ Risks ]
> > > Low, the other changes that were pending in git since 1:2.081-1 don't 
> > > risk breakage.
> > > 
> > > [ Checklist ]
> > >[x] all changes are documented in the d/changelog
> > >[x] I reviewed all changes and I approve them
> > >[x] attach debdiff against the package in testing
> > > 
> > > [ Other info ]
> > > The package has been uploaded to unstable.
> > > 
> > > unblock pdl/1:2.081-2
> > 
> > > diff -Nru pdl-2.081/debian/changelog pdl-2.081/debian/changelog
> > > --- pdl-2.081/debian/changelog2022-10-27 18:57:46.0 +0200
> > > +++ pdl-2.081/debian/changelog2023-04-27 15:54:44.0 +0200
> > > @@ -1,3 +1,22 @@
> > > +pdl (1:2.081-2) unstable; urgency=medium
> > > +
> > > +  * Team upload.
> > > +
> > > +  [ Bas Couwenberg ]
> > > +  * Add Rules-Requires-Root to control file.
> > > +  * Add a debhelper sequence to run dh_pdl.
> > 
> > Would you mind re-uploading without that change? It doesn't seem to
> > provide a targetted fix for a bug report.
> 
> I'd rather not. While not a targeted fix, it also doesn't risk introducing
> regressions.

We are also past the point of adding new changes. Please re-upload
without this change. See also https://release.debian.org/testing/FAQ.html

Cheers

> 
> > > +  * Bump Standards-Version to 4.6.2, no changes.
> > > +  * Add Breaks/Replaces on libpdl-stats-perl to fix upgrade.
> > > +(closes: #1034942)
> > > +
> > > +  [ Debian Janitor ]
> > > +  * Update lintian override info to new format:
> > > ++ debian/source/lintian-overrides: line 2
> > > ++ debian/pdl.lintian-overrides: line 6, 10, 22, 28
> > > +  * Use secure URI in Homepage field.
> > > +
> > > + -- Bas Couwenberg   Thu, 27 Apr 2023 15:54:44 +0200
> > > +
> > >   pdl (1:2.081-1) unstable; urgency=medium
> > >* Team upload.
> 
> Kind Regards,
> 
> Bas
> 
> -- 
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 

-- 
Sebastian Ramacher

Bug#1035345: unblock: libbssolv-perl/0.17-4

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-05-01 16:19:47 +0200, Andrej Shadura wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: libbssolv-p...@packages.debian.org
> Control: affects -1 + src:libbssolv-perl
> 
> Please unblock package libbssolv-perl
> 
> Library libbssolv is used by e.g. OBS to resolve dependencies
> of packages to be built. When processing Debian packages,
> the current version doesn’t accept "0" as a valid epoch, resulting
> it packages like woff-tools that have a zero epoch (0:2009.10.04-2)
> to be skipped and be forever unresolvable.
> 
> Since the only rdep of libbssolv-perl in Debian is OBS, impact on the
> rest of Debian is near-zero. The risk of not shipping this change is also
> low, but it would help users avoid patching this package.
> 
> In the debdiff, I’m also including low-impact changes to the metadata
> that were sitting in Git for the last two years.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock libbssolv-perl/0.17-4

> diff --git a/debian/changelog b/debian/changelog
> index 9cb7ecf70812..b138325c88db 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,15 @@
> +libbssolv-perl (0.17-4) unstable; urgency=medium
> +
> +  [ Debian Janitor ]
> +  * Bump debhelper from old 12 to 13.

This change is no longer appropriate at this stage of the freeze. See
also https://release.debian.org/testing/FAQ.html. Please re-upload
without this change.

Cheers

> +  * Update standards version to 4.6.0, no changes needed.
> +
> +  [ Andrej Shadura ]
> +  * Add a patch proposed upstream to accept "0" as a valid epoch.
> +See https://github.com/openSUSE/perl-BSSolv/pull/17
> +
> + -- Andrej Shadura   Mon, 01 May 2023 16:14:28 +0200
> +
>  libbssolv-perl (0.17-3) unstable; urgency=medium
>  
>[ Debian Janitor ]
> diff --git a/debian/control b/debian/control
> index 02b5c716f1f6..7adabd60217f 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -4,11 +4,11 @@ Uploaders: Mike Gabriel 
>  Section: perl
>  Testsuite: autopkgtest-pkg-perl
>  Priority: optional
> -Build-Depends: debhelper-compat (= 12),
> +Build-Depends: debhelper-compat (= 13),
> libsolv-dev (>= 0.7),
> perl-xs-dev,
> perl:native
> -Standards-Version: 4.5.0
> +Standards-Version: 4.6.0
>  Vcs-Browser: 
> https://salsa.debian.org/perl-team/modules/packages/libbssolv-perl
>  Vcs-Git: 
> https://salsa.debian.org/perl-team/modules/packages/libbssolv-perl.git
>  Homepage: https://github.com/openSUSE/perl-BSSolv
> diff --git a/debian/patches/1001-accept-0-as-epoch.patch 
> b/debian/patches/1001-accept-0-as-epoch.patch
> new file mode 100644
> index ..e29b40182832
> --- /dev/null
> +++ b/debian/patches/1001-accept-0-as-epoch.patch
> @@ -0,0 +1,25 @@
> +From: Sjoerd Simons 
> +Date: Mon, 1 May 2023 15:35:09 +0200
> +Subject: Accept "0" as an epoch
> +
> +In Debian an zero epoch is actually valid; e.g. woff-tools actually has
> +a zero epoch (0:2009.10.04-2).
> +
> +Signed-off-by: Sjoerd Simons 
> +---
> + BSSolv.xs | 2 --
> + 1 file changed, 2 deletions(-)
> +
> +diff --git a/BSSolv.xs b/BSSolv.xs
> +index ced6823..31c7a7a 100644
> +--- a/BSSolv.xs
>  b/BSSolv.xs
> +@@ -207,8 +207,6 @@ makeevr(Pool *pool, char *e, char *v, char *r)
> + 
> +   if (!v)
> + return 0;
> +-  if (e && !strcmp(e, "0"))
> +-e = 0;
> +   if (e)
> + s = pool_tmpjoin(pool, e, ":", v);
> +   else
> diff --git a/debian/patches/series b/debian/patches/series
> new file mode 100644
> index ..65e3b6438662
> --- /dev/null
> +++ b/debian/patches/series
> @@ -0,0 +1 @@
> +1001-accept-0-as-epoch.patch

> >From f974c721737f71cde617aab37ba92eb785ac7d14 Mon Sep 17 00:00:00 2001
> From: Sjoerd Simons 
> Date: Mon, 1 May 2023 15:35:09 +0200
> Subject: [PATCH] Accept "0" as an epoch
> 
> In Debian an zero epoch is actually valid; e.g. woff-tools actually has
> a zero epoch (0:2009.10.04-2).
> 
> Signed-off-by: Sjoerd Simons 
> ---
>  BSSolv.xs | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/BSSolv.xs b/BSSolv.xs
> index ced6823..31c7a7a 100644
> --- a/BSSolv.xs
> +++ b/BSSolv.xs
> @@ -207,8 +207,6 @@ makeevr(Pool *pool, char *e, char *v, char *r)
>  
>if (!v)
>  return 0;
> -  if (e && !strcmp(e, "0"))
> -e = 0;
>if (e)
>  s = pool_tmpjoin(pool, e, ":", v);
>else


-- 
Sebastian Ramacher

Bug#1034969: Fwd: Bug#1034969: terser: missing Breaks+Replaces for uglifyjs.terser when upgrading from bullseye

[Jonas Smedegaard]

Quoting Yadd (2023-05-02 04:58:47)
> a previous "unblock" was missing here: unstable version is 5.16.5-1 
> while testing version is 5.16.4-1. What do you want to do, fix only this 
> bug with a 5.16.5-really-5.16.4-1 or a full update ?

It is a bugfix release, and as such I would consider it relevant for
stable, but I get exhausted just thinking about the need for "defending"
changes against the release team: If you do it, you can desice if you
want to try get all of it in or only a (arguably too) minimal patch.

Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1035313: pstricks causes gray output of xdvi

[alma0]

Dear Hilmar,
Thanks! Yes, your change does the job  (dropping the “+” at the start of the 
lines).
The issue has also been resolved by the yesterday update of pstricks to 
TeXLive, and your line change is part of it. These file versions seem to be 
needed:
2021-09-24 23:38:54.0 +0200 texmf-dist/tex/generic/pstricks/pstricks.con
(which is already in Debian)
2023-04-30 21:53:54.0 +0200 texmf-dist/tex/generic/pstricks/pstricks.tex
(which is new).
Please feel free to push the changes to Debian.
Cheers,
Alma

Bug#1034969: Fwd: Bug#1034969: terser: missing Breaks+Replaces for uglifyjs.terser when upgrading from bullseye

[Yadd]

Hi,

a previous "unblock" was missing here: unstable version is 5.16.5-1 
while testing version is 5.16.4-1. What do you want to do, fix only this 
bug with a 5.16.5-really-5.16.4-1 or a full update ?


On 5/1/23 08:37, Jonas Smedegaard wrote:

Thanks for the patch, Yadd - and for the bugreport, Helmut.

I am quite busy elsewhere currently - if you have the time then I would
appreciate if you would handle this issue.

Otherwise I'll try make time for it the upcoming weekend.

  - Jonas

Quoting Yadd (2023-04-28 05:38:56)

Hi Jonas,

it seems that "Breaks" fields needs to be duplicated in "Replaces":

diff --git a/debian/control b/debian/control
index 6772ac76..3d8f1174 100644
--- a/debian/control
+++ b/debian/control
@@ -34,6 +34,9 @@ Depends:
   Breaks:
uglifyjs.terser (<< 4.8.0-1~),
node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)
+Replaces:
+ uglifyjs.terser (<< 4.8.0-1~),
+ node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)
   Suggests:
terser,
   Multi-Arch: foreign
@@ -87,6 +90,8 @@ Recommends:
node-source-map-support,
   Breaks:
uglifyjs.terser (<< 4.8.0-1~),
+Replaces:
+ uglifyjs.terser (<< 4.8.0-1~),
   Suggests:
node-acorn,
   Multi-Arch: foreign

Cheers,
Yadd

 Forwarded Message 
Subject: [Pkg-javascript-devel] Bug#1034969: terser: missing
Breaks+Replaces for uglifyjs.terser when upgrading from bullseye
Resent-Date: Thu, 27 Apr 2023 13:11:12 +
Resent-From: Helmut Grohne 
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Javascript Maintainers

Date: Thu, 27 Apr 2023 14:59:55 +0200
From: Helmut Grohne 
Reply-To: Helmut Grohne , 1034...@bugs.debian.org
To: sub...@bugs.debian.org

Package: terser
Version: 5.16.4-1
Severity: serious
Justification: dpkg unpack error

Attempting to unpack terser/5.16.4-1 from Debian bookworm
on a minimal Debian bullseye with uglifyjs.terser/4.1.2-8
installed, causes an unpack error from dpkg due to
/usr/share/nodejs/terser/bin/uglifyjs being contained in both packages.

| Selecting previously unselected package terser.
| dpkg: considering deconfiguration of uglifyjs.terser, which would be
broken by installation of terser ...
| dpkg: yes, will deconfigure uglifyjs.terser (broken by terser)
| (Reading database ... 4922 files and directories currently installed.)
| Preparing to unpack ./terser_5.16.4-1_all.deb ...
| De-configuring uglifyjs.terser (4.1.2-8) ...
| Unpacking terser (5.16.4-1) ...
| dpkg: error processing archive ./terser_5.16.4-1_all.deb (--unpack):
|  trying to overwrite '/usr/share/nodejs/terser/bin/uglifyjs', which is
also in package uglifyjs.terser 4.1.2-8
| Errors were encountered while processing:
|  ./terser_5.16.4-1_all.deb


Please ensure that terser has sufficient Breaks and Replaces declarations.

Helmut

--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#983302: imagemagick: reproducible builds: Embeds date dependent on timezone

[Vagrant Cascadian]

This patch is still relevent and applies to the version currently in
bookworm, though was fixed in experimental.

live well,
  vagrant

> From 5587cea7533d43b7e264da5420389b83650cc063 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Mon, 22 Feb 2021 01:21:14 +
> Subject: [PATCH 1/4] configure.ac: Patch to ensure release date is in UTC.
>
> While it uses a reference file to produce a consistent date, the
> timezone may affect the actual date produced.
>
> https://reproducible-builds.org/docs/timezones/
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 570d04f..62ddb5c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -39,7 +39,7 @@ m4_define([magick_git_revision],
>]))
>  m4_define([magick_release_date],
>m4_esyscmd([
> -d=$(date +%F -r ./ChangeLog)
> +d=$(date -u +%F -r ./ChangeLog)
>  printf %s "$d"
>]))
>  
> -- 
> 2.20.1


signature.asc
Description: PGP signature

Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish

[Alban Browaeys]

Just a quick note that I am able to reproduce this issue with master.
Though at times it works with upstream master, running from builddir
via "make run" under the ./pw-uninstalled.sh environment.
Maybe this only works because the settings are different.

Likely an upstream issue.

Cheers,
Alban

Bug#1035366: pytorch-ignite: FTBFS: py3versions: empty set of versions

[Andreas Beckmann]

Source: pytorch-ignite
Version: 0.4.3-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + python3-torch-ignite


pytorch-ignite FTBFS in sid (it builds fine in bullseye):

 fakeroot debian/rules clean
dh clean -Spybuild --with python3
   dh_auto_clean -O-Spybuild
py3versions: empty set of versions
E: py3versions failed at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm line 53.
make: *** [debian/rules:5: clean] Error 1


Andreas

Bug#1035365: lombok: reproducible-builds: build timestamps in files inside of .jar

[Vagrant Cascadian]

Source: lombok
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in various files inside
/usr/share/java/lombok-1.18.24.jar:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/lombok.html

  META-INF/services/lombok.core.LombokApp

  #·Thu,·25·Apr·2024·11:27:09·-1200
  vs.
  #·Sat,·25·Mar·2023·07:05:45·+1400

The attached patch fixes this by removing the code in
SpiProcessorPersistence.java which adds the build timestamp.

If a date is for some reason necessary to embed in these files, another
option might be to use the SOURCE_DATE_EPOCH environment variable:

  https://reproducible-builds.org/docs/source-date-epoch/


Unfortunately, there may be other non-deterministic issues which prevent
lombok from building reproducibly, but applying this patch should
significantly reduce the noise generated from timestamps.


Thanks for maintaining lombok!


live well,
  vagrant
From 9e2381870db66336dee2ac7b1ad6ef00f131cdac Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 1 May 2023 16:27:59 -0700
Subject: [PATCH 1/3] src/spiProcessor/lombok/spi/SpiProcessorPersistence.java:
 Avoid embedding the build timestamp.

https://reproducible-builds.org/docs/timestamps/
---
 src/spiProcessor/lombok/spi/SpiProcessorPersistence.java | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/spiProcessor/lombok/spi/SpiProcessorPersistence.java b/src/spiProcessor/lombok/spi/SpiProcessorPersistence.java
index 794473a..2d91b02 100644
--- a/src/spiProcessor/lombok/spi/SpiProcessorPersistence.java
+++ b/src/spiProcessor/lombok/spi/SpiProcessorPersistence.java
@@ -141,7 +141,6 @@ class SpiProcessorPersistence {
 		FileObject output = filer.createResource(StandardLocation.CLASS_OUTPUT, "", path + serviceName);
 		Writer writer = output.openWriter();
 		writer.write("# Generated by " + name + "\n");
-		writer.write("# " + new SimpleDateFormat("EEE, d MMM  HH:mm:ss Z", Locale.US).format(new Date()) + "\n");
 		writer.write(value);
 		writer.close();
 	}
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1035312: minetest: New upstream version available (5.7.0)

[Martin Quinson]

Hello,

thanks for your interest. We will have to wait until after the freeze period
and the release of the upcoming version of Debian before we can upload another
version. This is expected for mid-june.

Please come back to us after this date if we forget to upload minetest after
that.

Thanks,
Mt

Le dimanche 30 avril 2023 à 15:14 -0300, Nelson A. de Oliveira a écrit :
> Source: minetest
> Severity: wishlist
> X-Debbugs-Cc: nao...@gmail.com
> 
> Hi!
> 
> When possible, could we have the latest upstream version (5.7.0)
> packaged, please?
> 
> Thank you!
> 
> Best regards,
> Nelson
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (100, 'unstable-debug'), (100,
> 'experimental'), (1, 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> -- no debconf information
> 

-- 
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.



signature.asc
Description: This is a digitally signed message part

Bug#1035364: lttng-modules-dkms: fails to build module on bullseye for Linux 5.10.0-22-amd64

[Andreas Beckmann]

Package: lttng-modules-dkms
Version: 2.12.5-1
Severity: serious
Tags: bullseye
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up lttng-modules-dkms (2.12.5-1) ...
  Loading new lttng-modules-2.12.5 DKMS files...
  It is likely that 6.1.20 belongs to a chroot's host
  Building for 5.10.0-22-amd64
  Building initial module for 5.10.0-22-amd64
  Error! Bad return status for module build on kernel: 5.10.0-22-amd64 (x86_64)
  Consult /var/lib/dkms/lttng-modules/2.12.5/build/make.log for more 
information.
  dpkg: error processing package lttng-modules-dkms (--configure):
   installed lttng-modules-dkms package post-installation script subprocess 
returned error exit status 10
  Processing triggers for libc-bin (2.31-13+deb11u6) ...
  Errors were encountered while processing:
   lttng-modules-dkms


DKMS make.log for lttng-modules-2.12.5 for kernel 5.10.0-22-amd64 (x86_64)
Mon May  1 23:45:42 UTC 2023
make: Entering directory '/usr/src/linux-headers-5.10.0-22-amd64'
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lttng-ring-buffer-client-discard.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lttng-ring-buffer-client-overwrite.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lttng-ring-buffer-metadata-client.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lttng-ring-buffer-client-mmap-discard.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lttng-ring-buffer-client-mmap-overwrite.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lttng-ring-buffer-metadata-mmap-client.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-clock.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-events.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-abi.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-string-utils.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-probes.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-pid.o
/var/lib/dkms/lttng-modules/2.12.5/build/probes/Kbuild:62: File 
/usr/src/linux-headers-5.10.0-22-common/arch/x86/kvm/lapic.h not found. Probe 
"kvm" x86-specific is disabled. Use full kernel source tree to enable it.
/var/lib/dkms/lttng-modules/2.12.5/build/probes/Kbuild:166: Files 
/usr/src/linux-headers-5.10.0-22-common/fs/btrfs/*.h not found. Probe "btrfs" 
is disabled. Use full kernel source tree to enable it.
/var/lib/dkms/lttng-modules/2.12.5/build/probes/Kbuild:177: Files 
/usr/src/linux-headers-5.10.0-22-common/fs/ext4/*.h not found. Probe "ext4" is 
disabled. Use full kernel source tree to enable it.
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-procname.o
/var/lib/dkms/lttng-modules/2.12.5/build/probes/Kbuild:208: File 
/usr/src/linux-headers-5.10.0-22-common/drivers/base/regmap/trace.h not found. 
Probe "regmap" is disabled. Need Linux 4.1+ kernel source tree to enable it.
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lib/ringbuffer/ring_buffer_backend.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/probes/lttng-probe-sched.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/tests/probes/lttng-test.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-prio.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-nice.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-vpid.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/probes/lttng-probe-irq.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/probes/lttng-probe-timer.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/tests/clock-plugin/lttng-clock-plugin-test.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-tid.o
  LD [M]  /var/lib/dkms/lttng-modules/2.12.5/build/tests/lttng-test.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-vtid.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-ppid.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lib/ringbuffer/ring_buffer_frontend.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lib/ringbuffer/ring_buffer_iterator.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lib/ringbuffer/ring_buffer_vfs.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lib/ringbuffer/ring_buffer_splice.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-vppid.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/probes/lttng-probe-kmem.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-cpu-id.o
  CC [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/lib/ringbuffer/ring_buffer_mmap.o
  LD [M]  
/var/lib/dkms/lttng-modules/2.12.5/build/tests/lttng-clock-plugin-test.o
  CC [M]  /var/lib/dkms/lttng-modules/2.12.5/build/lttng-context-uid.o
  CC [M]  

Bug#1035363: torrus-common: fails to install: addgroup with two arguments is an unspecified operation.

[Andreas Beckmann]

Package: torrus-common
Version: 3.00-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up torrus-common (3.00-1.1) ...
  dpkg: error processing package torrus-common (--configure):
   installed torrus-common package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.36-9) ...
  Errors were encountered while processing:
   torrus-common

Re-running the postinst script with set -x:

Setting up torrus-common (3.00-1.1) ...
+ set -e
+ dpkg-maintscript-helper rm_conffile /etc/logrotate.d/torrus-common 2.01-3 -- 
configure
+ test -L /etc/apache2/conf.d/torrus-apache2.conf
+ configure_user_group
+ adduser --quiet --system --no-create-home --home /nonexistent --force-badname 
--group Debian-torrus
+ fix_owner_perm
+ chown Debian-torrus:Debian-torrus /var/lib/torrus /var/log/torrus
+ chmod g+w /var/log/torrus
+ chmod g+w /var/lib/torrus/session_data/lock /var/lib/torrus/session_data/store
+ [ -d /var/cache/torrus ]
+ rm -rf /var/lib/torrus/db
+ addgroup www-data Debian-torrus

Re-running the last command manually in the chroot without output
redirection:

# addgroup www-data Debian-torrus
addgroup: addgroup with two arguments is an unspecified operation.


cheers,

Andreas


torrus-common_3.00-1.1.log.gz
Description: application/gzip

Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

[Andreas Beckmann]

Package: sauce
Version: 0.9.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package's logrotate
configuration causes logrotate to exit with an error after the package
has been removed (*) or when logrote is run but no logfile exists.

Usually the solution is to specify 'missingok' in the logrotate
configuration.

*) logrotate configuration files remain installed and executed after a
package has been removed, they only get removed when the package is
purged.

>From the attached log (scroll to the bottom...):

0m17.0s DEBUG: Starting command: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp6h9n6ntx', '/usr/sbin/logrotate', 
'/etc/logrotate.d/sauce']
0m17.0s DUMP: 
  warning: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755
0m17.0s DEBUG: Command ok: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp6h9n6ntx', '/usr/sbin/logrotate', 
'/etc/logrotate.d/sauce']
0m17.0s ERROR: FAIL: Logrotate file /etc/logrotate.d/sauce exits with error or 
has output with package removed


Setting severity to serious since this does not seem limited to being
emitted after package removal but always. The current logrotate version
in sid seems to be more strict.


cheers,

Andreas


sauce_0.9.1.log.gz
Description: application/gzip

Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state

[Cyril Brulebois]

[ Reordering slightly ]

Cyril Brulebois  (2023-05-02):
> Paul Seelig  (2023-05-02):
> > Attached installation logs should be sufficiently verbose about what
> > actually happened underneath.
> 
> Either it was forgotten or dropped by the BTS; please use reply-all,
> and attach it compressed (to avoid hitting size limits on either the
> BTS side or on the debian-boot ML side).

For reference:
 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035360#10
 - 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1035360;filename=installer-logs.tar.xz;msg=10

> > Apparently, the required cryptsetup-initramfs packages were removed
> > from the system during the last instalation stages, rendering the
> > resulting system unbootable.

That's not quite what happened. Instead, the cryptsetup-initramfs wasn't
available to start with:

Apr 30 16:11:44 in-target: Package cryptsetup-initramfs is not available, 
but is referred to by another package.
Apr 30 16:11:44 in-target: E: Package 'cryptsetup-initramfs' has no 
installation candidate

Later on, cryptsetup got removed along with a bunch of live packages.

Presumably, if cryptsetup-initramfs had been successfully installed, it
would have kept cryptsetup around.

Again, I'm not familiar with the live environment, it'd be great if some
with some knowledge about the way it operates and/or the way it's built
could comment on this.

Adding debian-live@ for now, but might be debian-cd@ territory…

Very wild guess: Could cryptsetup-initramfs be missing from live-setup?
  https://salsa.debian.org/images-team/live-setup.git


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


signature.asc
Description: PGP signature

Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state

[Cyril Brulebois]

Hi Paul,

and thanks for the report.

Paul Seelig  (2023-05-02):
> using the xfce4 based RC2 live ISO image[1], on a Thinkpad T480 (16GB
> RAM/256GB NVME/INTEL GRAPHICS ONLY) installation of Debian in an luks
> encrypted LVM was performed.
> 
> Apparently, the required cryptsetup-initramfs packages were removed
> from the system during the last instalation stages, rendering the
> resulting system unbootable.

Oh wow, that looks bad. Unfortunately I'm mostly familiar with the
regular d-i installer, not so much with the live counterpart.

> Manual intervention was required to fix the issue from a live rescue
> system, something a novice user will never be able to accomplish.

Can't agree with you more. (Even with a developer hat, the first time
one gets confronted with a LUKS system that cannot be unlocked leaves
traces… Still remembering that initramfs bug I encountered around 2010,
as if it were yesterday…)

FWIW: While I'm not sure about live images (and I won't check right
now), regular d-i offers a rescue mode which automates the painful
detecting and unlocking steps when it comes to LUKS stuff, so you don't
have to know about cryptsetup luksOpen and friends to get a shell into
the installed system.

> The same issue was already note with the prior RC1 variant of this
> bookworm live ISO. It can be reliably reproduced. 

Helpful data point, thanks.

> Attached installation logs should be sufficiently verbose about what
> actually happened underneath.

Either it was forgotten or dropped by the BTS; please use reply-all,
and attach it compressed (to avoid hitting size limits on either the BTS
side or on the debian-boot ML side).


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


signature.asc
Description: PGP signature

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Steve McIntyre]

On Mon, May 01, 2023 at 02:16:46PM +0200, Pascal Hambourg wrote:
>On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian 
>
>> > I ran d-i in rescue mode to get into the system, simply ran
>> > dpkg-reconfigure grub-pc (which will run grub-install *and*
>> > update-grub), and the system now boots again. It looks like what we're
>> > seeing might be a limit in what's built in to the core image by
>> > default. grub-pc is deliberately designed to build minimal images
>> > here, to minimise the chance of the image being too large to embed.
>
>I wonder how much this policy is still relevant for PC platforms. Originally
>the core image was designed to fit in the "post-MBR gap" whose typical size
>was 62 sectors (31 KiB) because the first partition used to start at sector
>63. But nowadays a 1-MiB post-MBR gap has been the standard for many years. I
>do not remember when this was introduced in fdisk and other Linux partition
>editors, but Windows 7 installer had it. Besides, I observe that the size of
>the core.img built for LVM+ext4 on my bullseye system is 34 KiB so it would
>not even fit in a 31-KiB post-MBR gap.

Even the 1MB post-MBR gap can be a struggle AIUI. BIOS booting is
fragile as hell, and there have been lots of discussions over the
years on the upstream list about the problems of embedding...

>The minimal core image policy is even less relevant for EFI images, as the
>EFI partition size is usually several MB so a few more kB won't hurt. I
>cannot tell for other platforms.

Nod, exactly. To be honest, EFI typically makes things *so* much more
sane here for exactly these reasons. Then again you get to see more
issues with broken firmware. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state

[Paul Seelig]

Package: debian-installer
Severity: grave
X-Debbugs-Cc: think...@rumbero.org

Hi all,

using the xfce4 based RC2 live ISO image[1], on a Thinkpad T480 (16GB RAM/256GB 
NVME/INTEL GRAPHICS ONLY) installation of Debian in an luks encrypted LVM was 
performed.

Apparently, the required cryptsetup-initramfs packages were removed from the 
system during the last instalation stages, rendering the resulting system 
unbootable. 
Manual intervention was required to fix the issue from a live rescue system, 
something a novice user will never be able to accomplish.

The same issue was already note with the prior RC1 variant of this bookworm 
live ISO. It can be reliably reproduced. 
Attached installation logs should be sufficiently verbose about what actually 
happened underneath.

[1] 
https://cdimage.debian.org/cdimage/bookworm_di_rc2-live/amd64/iso-hybrid/debian-live-bkworm-DI-rc2-amd64-xfce.iso

Regards,
P.Seelig

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 
'oldstable-proposed-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1034119: [INTL:ro] Translation of "ufw" to Romanian

[Jamie Strandboge]

Thanks for this! I plan to add this in the next ufw release and then
push that to Debian with the next upload.

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#1033758: [INTL:ro] Romanian debconf templates translation of ufw

[Jamie Strandboge]

Thanks for this! It will be in the next upload.

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#1034310: Another issue which is not fixed in 7.x.x

[Rainer Dorsch]

Comment 35 in upstream bugreport:

https://bugs.kde.org/show_bug.cgi?id=466170#c35

Thanks for the backtrace, the problem in slotEmptyMessageTimer() is known and 
was fixed about 5 months ago. We seem to have forgotten the backport to 
digiKam-7.x.x when I look at the history. Only with digiKam-8.0.0 will the 
problem no longer occur.


-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1035313: pstricks causes gray output of xdvi

[Hilmar Preuße]

On 4/30/23 20:28, Al Ma wrote:

Hi,


Feed mwe.tex containing
\documentclass{article}
\usepackage{pstricks}
\begin{document}
Test
\end{document}


Thanks for the report. The issue seems to have been resolved recently.
Could you look for the line

\pstVerb{0.8 setlinewidth 0 setgray}%default setting (needed for
lualatex)

(1 line) in pstricks.tex (should be around line 4250) and replace it by:

+%%% changed 20230430 by hv, confuses otherwise the dvi color handling
+\ifluatex\pstVerb{0.8 setlinewidth 0 setgray}\fi%default setting
(needed for lualatex)
+%%%

(3 lines). Does that solve your issue?

Hilmar
--
Testmail

Bug#1034568: binascii.Error: Odd-length string when asking the status

[Jamie Strandboge]

Thank you for the report. If you update hex_decode() in
/usr/lib/python3/dist-packages/ufw/util.py to use this:

return binascii.unhexlify('%2s' % h).decode("utf-8")

instead of:

return binascii.unhexlify(h).decode("utf-8")

Does it resolve the issue for you?

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#1035358: Acknowledgement (urlview does not work with URLs containing parentheses)

[Francesco Ariis]

A workaround is to `cp /etc/urlview/system.urlview ~/.urlview` and
then replace REGEXP with

REGEXP (((http|https|ftp|gopher)|mailto):(//)?[^ 
<>"\t]*|(www|ftp)[0-9]?\.[-a-z0-9.]+)[^ .,;\t\n\r<">\):]?[^, <>"\t]*[^ 
.,;\t\n\r<">:]

(i.e. erasing that last “\)”).

I would send a patch but am not a regexp expert — nor I understood where
upstream repository is —, so I am not 100% sure the modification is sensible.

Bug#1035068: linux-image-6.1.0-7-amd64: occasionally no trackpad/trackpoint on resume from hibernate

[Diederik de Haas]

On Monday, 1 May 2023 20:40:11 CEST Rusty Grove wrote:
> The script is something I did

Can you test without that script then?
IMO the proper way to deal with suspend/resume should be done by the system/
kernel and it *could* be that your script is actually interfering with that.

> I'm not quite sure what you mean by the sequence being in reverse...

if you do in pre:
unload A
unload B

Then you should do in post:
load B
load A

but your script did
load A
load B

HTH

signature.asc
Description: This is a digitally signed message part.

Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Salvatore Bonaccorso]

Hi,

On Mon, May 01, 2023 at 06:36:01PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Salvatore Bonaccorso  (2023-04-30):
> > [ Other info ]
> > As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
> > Cyril on this pre-approval request.
> 
> Thanks for that.
> 
> > Furthermore the attached debdiff still contains the UNRELEASED
> > changelog entry, which will be switched for the upload.
> 
> ACK.
> 
> With both my d-i and release hats: looks good to me, please go ahead.

Thanks Cyril for the review. Just uploaded.

Regards,
Salvatore

Bug#1035358: urlview does not work with URLs containing parentheses

[Francesco Ariis]

Package: urlview
Version: 0.9-21+b1
Severity: normal
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,

urlview does not work with URLs containing parentheses.
To reproduce:

$ echo "https://en.wikipedia.org/wiki/Close_Combat_(series)" > test.txt
$ urlview test.txt

You will get a single selection:

->1 https://en.wikipedia.org/wiki/Close_Combat_(series

Notice the missing ‘)’ at the end.



-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages urlview depends on:
ii  libc6   2.31-13+deb11u6
ii  libncurses6 6.2+20201114-2+deb11u1
ii  libtinfo6   6.2+20201114-2+deb11u1
ii  sensible-utils  0.0.14

Versions of packages urlview recommends:
ii  chromium [www-browser] 112.0.5615.138-1~deb11u1
ii  firefox-esr [www-browser]  102.10.0esr-1~deb11u1
ii  qutebrowser [www-browser]  2.0.2-2
ii  w3m [www-browser]  0.5.3+git20210102-6+deb11u1

Versions of packages urlview suggests:
ii  mutt  2.0.5-4.1+deb11u2
pn  ncftp | lftp  
ii  wget  1.21-1+deb11u1

-- no debconf information

Bug#1035342: binutils: Native binutils-TUPLE provides tool names that cross binutils-TUPLE does not

[Simon McVittie]

On Mon, 01 May 2023 at 16:21:55 +0200, Matthias Klose wrote:
> On 01.05.23 14:53, Simon McVittie wrote:
> > This seems inconsistent: I would have expected that binutils-TUPLE would
> > either always provide TUPLE-gold, or never provide TUPLE-gold.
> 
> this is an oversight, will fix this in experimental.

Thanks! This part (gold) was what prompted me to open this bug.

> > Similarly, binutils-x86-64-linux-gnu:amd64 provides TUPLE-gp-archive (and
> > other gp- tools) and TUPLE-gprofng, but binutils-x86-64-linux-gnu:ppc64el
> > doesn't provide those.
> 
> the profiling parts are not included in the cross packages by intent. Is
> there a use case where these are necessary?  Shouldn't you be able to use
> the native packages?

I didn't know and didn't check what these tools are for, I just
noticed while reporting this bug that they were present in native
binutils-x86-64-linux-gnu but not in cross binutils-x86-64-linux-gnu,
which seemed odd. Cross binutils do have TUPLE-gprof, but not
TUPLE-gprofng or the TUPLE-gp- family.

I can see that profiling a non-native executable is likely to lead to
misleading results, because even if you can run it via qemu or something,
the times are not going to reflect how fast or slow a real CPU of the
same architecture would be; so from that point of view, omitting these
makes sense.

For related CPU families like x86_64/i386 and arm64/armhf/armel,
am I correct to assume that there's enough multilib support for
binutils-x86-64-linux-gnu:amd64's gprofng to be able to profile an
i686-linux-gnu executable, and so on? But that would mean that a build
system for build=amd64, host=i386 needs to know that it's OK that
i686-linux-gnu-gprofng won't exist and it should fall back to plain
gprofng (or equivalently, x86_64-linux-gnu-gprofng).

My concern about these was that having them in native binutils but not in
cross-binutils means the command-line "API" of binutils-x86-64-linux-gnu
is different depending on what architecture's version you have. But if
those differences are considered harmless (either because build systems
are expected to fall back from i686-linux-gnu-gprofng to gprofng like
Autotools would, or because using a tuple-prefixed gprofng doesn't actually
make sense and users should stick to the unprefixed one) then that's fine.

smcv

Bug#1035332: grub-efi-arm64: "error: failed to install/update FDT." after bullseye upgrade

[Vagrant Cascadian]

On 2023-04-30, Vagrant Cascadian wrote:
> After updating to the latest point release, these apm mustang systems
> fail to boot the kernel, all I see is:
>
> error: failed to install/update FDT.
> Loading Linux 5.10.0-22-arm64 ...
> Loading initial ramdisk ...
>
> Press any key to continue...

The workaround was to uninstall shim-signed and re-install grub
(grub-install /dev/sda ; grub-install /dev/sdb).

Worked for three of three machines so far... I tested re-installing
shim-signed on one machine and re-installing grub and the problem came
back.

No idea why this started happening just now, as shim-signed and related
packages were all installed before the bullseye point release, but did
not have this problem...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Cyril Brulebois]

Hi,

James Addison  (2023-05-01):
> Also, the brcmfmac kernel module code mentions[3] that it can load
> board-specific firmware file paths.  I'm not yet sure whether that's
> relevant (either now, or in future).

Yeah, both the function you pointed to and the one handling actual
firmware requests seem to know about some alt_fw semantics, with a
fallback. But I'm not diving into that rabbit hole. :)

> Since more files with that pattern are appearing upstream in
> linux-firmware.. yes, slightly reluctantly it does seem that this will
> be needed.

[…]

> I'd generally agree with all that.  For robustness, and when it's safe
> to, it'd be nice to resolve both issues (firstly to ensure that the
> correct firmware filename is being requested in these cases -- maybe
> it already is, I'm still trying to determine whether that's a bug --
> and secondly to support spaces in firmware filenames in hw-detect).

Regarding “plans for the future”, it's worth mentioning #1033921, now
cloned as #1035356. While the former is about license acceptance for
some firmware packages specifically (and about to be fixed for bookworm)
the latter is for longer term, with a proposed patch changing the logic
around iterating over firmware filenames. I'm not saying it's going to
solve spaces-in-filenames as it is, I just thought it'd make sense to
mention it as that touches one relevant part of the hw-detect code.

 1. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1035356;filename=duplicate_stdin_for_debconf.diff;msg=45
 2. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1035356;filename=0001-check-missing-firmware-Fix-firmware-license-acceptan.patch;msg=50


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


signature.asc
Description: PGP signature

Bug#1035354: unblock: fish/3.6.0-3.1

[M. Zhou]

I'm the previous uploader of src:fish.
The change looks good to me.
Please feel free to go ahead with the nmu once the release managers say OK.

On Mon, 2023-05-01 at 19:13 +0200, Andrej Shadura wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: f...@packages.debian.org, Mo Zhou 
> Control: affects -1 + src:fish
> 
> Please unblock package fish
> 
> As described in #1000351, mc ships fragile prompt extraction code which
> was broken by a change in fish 3.3.0, leaving fish unusable in
> conjunction with mc. I had hoped that this bug would be fixed in mc by
> the time of bookworm release, but this didn’t happen. Instead, the
> upstream developers of fish proposed a workaround and shipped it
> in the bugfix release 3.6.1.
> 
> I intend to either upload an NMU or let Mo Zhou do a maintainer’s
> upload.
> 
> This fix has very limited impact, as it specifically checks for the
> presence of an mc-specific environment variable, and is a no-op
> otherwise. The workaround itself is also straightforward.
> 
> The impact of not shipping this patch is that all users of both fish and
> mc (like myself) will have to put fish on hold and stay on the version
> shipped in bullseye.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> 
> Links:
> 
> [1]: https://bugs.debian.org/1035353: the original mc bug
> [2]: https://bugs.debian.org/1000351: a clone of the above for the
>  package fish
> [3]: https://github.com/fish-shell/fish-shell/pull/9540: a pull request
>  in the upstream package.
> 
> unblock fish/3.6.0-3.1

Bug#1033953: unblock: gimp-help/2.10.34-1

[Jordi Mallach]

Hi Paul,

Sorry for the wait, just uploading this was a bit painful on my
internet link.

Attached is the debdiff of what I uploaded to experimental (new
translations need to go through NEW, if this ends up being acceptable,
I'll try to get ftp-master to review it asap).

NB: while generating the debdiff, I noticed tehre are two packaging
changes that are not reflected in the changelog:
- upstream-vcs-tag was enabled in d/gbp.conf
- all patches were disabled as they were obsolete

Both changes Iwill be documented in the -2 upload, which should have no
further modifications.

Jordi
-- 
Jordi Mallach 
Debian Project
diff -Nuar /tmp/gimp-help-2.10.0/debian/changelog gimp-help/debian/changelog
--- /tmp/gimp-help-2.10.0/debian/changelog	2020-09-03 19:55:13.0 +0200
+++ gimp-help/debian/changelog	2023-05-01 01:53:22.196877871 +0200
@@ -1,3 +1,12 @@
+gimp-help (2.10.34-1) experimental; urgency=medium
+
+  * New upstream release
+  * Add new binary packages for cs, da, en_GB, fa, fi, hr, hu, lt, pt,
+ro, uk and zh_CN.
+  * Drop obsolete override for dh_clean.
+
+ -- Jordi Mallach   Mon, 01 May 2023 01:53:14 +0200
+
 gimp-help (2.10.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nuar /tmp/gimp-help-2.10.0/debian/control gimp-help/debian/control
--- /tmp/gimp-help-2.10.0/debian/control	2020-09-03 19:55:13.0 +0200
+++ gimp-help/debian/control	2023-05-01 01:53:42.165187340 +0200
@@ -6,7 +6,7 @@
 Section: doc
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
-Uploaders: Ari Pollak , Jeremy Bicha 
+Uploaders: Ari Pollak , Jordi Mallach 
 Build-Depends: debhelper-compat (= 12),
gnome-pkg-tools,
pkg-config
@@ -35,6 +35,28 @@
  .
  This package contains the documentation for the GIMP in Catalan.
 
+Package: gimp-help-cs
+Architecture: all
+Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
+Provides: gimp-help
+Enhances: gimp
+Description: Documentation for the GIMP (Czech)
+ This package contains the documentation files for the GIMP designed for use
+ with the internal GIMP help browser or external web browsers.
+ .
+ This package contains the documentation for the GIMP in Czech.
+
+Package: gimp-help-da
+Architecture: all
+Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
+Provides: gimp-help
+Enhances: gimp
+Description: Documentation for the GIMP (Danish)
+ This package contains the documentation files for the GIMP designed for use
+ with the internal GIMP help browser or external web browsers.
+ .
+ This package contains the documentation for the GIMP in Danish.
+
 Package: gimp-help-de
 Architecture: all
 Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
@@ -68,6 +90,17 @@
  .
  This package contains the documentation for the GIMP in English.
 
+Package: gimp-help-en-gb
+Architecture: all
+Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
+Provides: gimp-help
+Enhances: gimp
+Description: Documentation for the GIMP (British English)
+ This package contains the documentation files for the GIMP designed for use
+ with the internal GIMP help browser or external web browsers.
+ .
+ This package contains the documentation for the GIMP in British English.
+
 Package: gimp-help-es
 Architecture: all
 Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
@@ -79,6 +112,28 @@
  .
  This package contains the documentation for the GIMP in Spanish.
 
+Package: gimp-help-fa
+Architecture: all
+Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
+Provides: gimp-help
+Enhances: gimp
+Description: Documentation for the GIMP (Farsi)
+ This package contains the documentation files for the GIMP designed for use
+ with the internal GIMP help browser or external web browsers.
+ .
+ This package contains the documentation for the GIMP in Farsi.
+
+Package: gimp-help-fi
+Architecture: all
+Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
+Provides: gimp-help
+Enhances: gimp
+Description: Documentation for the GIMP (Finnish)
+ This package contains the documentation files for the GIMP designed for use
+ with the internal GIMP help browser or external web browsers.
+ .
+ This package contains the documentation for the GIMP in Finnish.
+
 Package: gimp-help-fr
 Architecture: all
 Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
@@ -90,6 +145,28 @@
  .
  This package contains the documentation for the GIMP in French.
 
+Package: gimp-help-hr
+Architecture: all
+Depends: ${misc:Depends}, gimp-help-common (= ${source:Version}), gimp-helpbrowser | www-browser
+Provides: gimp-help
+Enhances: gimp
+Description: Documentation for the GIMP (Croatian)
+ This package contains the documentation files for the GIMP designed 

Bug#1035068: linux-image-6.1.0-7-amd64: occasionally no trackpad/trackpoint on resume from hibernate

[Rusty Grove]

Thanks. I've installed 6.1.25-1 and will do further testing. The script is
something I did, which in my (adminitingly unscientific) testing, seemed to
work well with occasional cases of no trackpad/trackpoint input. I'm not
quite sure what you mean by the sequence being in reverse... my thought was
to remove the module before going to suspend and then load it again after
resume. You're right, it's probably safe to remove the entry to load
elan_i2c, as psmouse should pull it in. Not sure why I have it in there.

On Fri, Apr 28, 2023 at 4:07 PM Diederik de Haas 
wrote:

> Control: tag -1 moreinfo
>
> On Friday, 28 April 2023 20:15:46 CEST Harold Grove wrote:
> > Package: src:linux
> > Version: 6.1.20-2
>
> Unstable now has version 6.1.25-1, could you try that?
>
> > I'm also seeing a possibly related kernel oops when unloading the psmouse
> > module. The module is being unloaded via a script under
> > /lib/systemd/system-sleep/ which contains:
> > #!/bin/sh
> > # Reload the trackpoint and trackpad drivers on L13 Yoga Gen 2
> > case $1 in
> > pre)
> > rmmod psmouse;
> > sleep 1;
> > rmmod elan_i2c;
> > ;;
> > post)
> > modprobe psmouse;
> > sleep 1;
> > modprobe elan_i2c;
> > ;;
> > esac
>
> Did you create that yourself or is that some a package?
> In any case, the sequence seems odd to me as I'd expect the 'post'
> sequence to
> be the reverse of the 'pre' sequence, thus first `modprobe elan_i2c` and
> then
> `modprobe psmouse`.
> Also, if `psmouse` needs `elan_i2c` it should trigger the loading by
> itself.

-- 




Confidentiality Notice: The material transmitted herein is intended 
only for the use of the addressee and may contain information that 
constitutes work product or is confidential and exempt from disclosure 
under applicable law. Distribution or copying of this communication or 
reliance upon its contents by unauthorized participants is strictly 
prohibited. If you have received this communication in error, please notify 
us immediately by telephone or email.

Bug#1035357: unblock: calamares-settings-debian/12.0.5-2

[Jonathan Carter]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: calamares-settings-deb...@packages.debian.org
Control: affects -1 + src:calamares-settings-debian

Please unblock package calamares-settings-debian

This change re-enables os-prober during installation on Debian live images
when using Calamares, so that dual-booted systems will detect other operating 
systems.

Sorry for the noise in the debdiff, it took a few times to get just right, the 
pertinent
change is on the last lines.

thanks,

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ debdiff ]
"""
diff -Nru calamares-settings-debian-12.0.5/CHANGELOG 
calamares-settings-debian-12.0.8/CHANGELOG
--- calamares-settings-debian-12.0.5/CHANGELOG  2023-03-06 19:22:24.0 
+0200
+++ calamares-settings-debian-12.0.8/CHANGELOG  2023-04-26 14:23:37.0 
+0200
@@ -1,3 +1,15 @@
+[ 10.0.8 ]
+
+ * Do grub work within the chroot
+
+[ 10.0.7 ]
+
+ * Enable os-prober /after/ grub has been installed.
+
+[ 12.0.6 ]
+
+ * Enable os-prober
+
 [ 12.0.5 ]
 
  * Update sources.list to include non-free-firmware and backports
diff -Nru calamares-settings-debian-12.0.5/debian/changelog 
calamares-settings-debian-12.0.8/debian/changelog
--- calamares-settings-debian-12.0.5/debian/changelog   2023-04-04 
09:51:03.0 +0200
+++ calamares-settings-debian-12.0.8/debian/changelog   2023-04-26 
14:25:34.0 +0200
@@ -1,3 +1,17 @@
+calamares-settings-debian (12.0.8-1) unstable; urgency=medium
+
+  * New upstream release
+- Make grub changes in the correct place (within the chroot)
+
+ -- Jonathan Carter   Wed, 26 Apr 2023 14:25:34 +0200
+
+calamares-settings-debian (12.0.7-1) unstable; urgency=medium
+
+  * New upstream release
+- Re-enable os-prober
+
+ -- Jonathan Carter   Wed, 26 Apr 2023 13:43:01 +0200
+
 calamares-settings-debian (12.0.5-2) unstable; urgency=medium
 
   * Depend on pkexec (Closes: #1033930) 
diff -Nru calamares-settings-debian-12.0.5/scripts/bootloader-config 
calamares-settings-debian-12.0.8/scripts/bootloader-config
--- calamares-settings-debian-12.0.5/scripts/bootloader-config  2023-03-06 
19:22:24.0 +0200
+++ calamares-settings-debian-12.0.8/scripts/bootloader-config  2023-04-26 
14:23:37.0 +0200
@@ -19,3 +19,7 @@
 echo " * install grub... (bios)"
 DEBIAN_FRONTEND=noninteractive chroot $CHROOT apt-get -y install grub-pc 
cryptsetup keyutils
 fi
+
+# Re-enable os-prober:
+sed -i "s/#GRUB_DISABLE_OS_PROBER=false/# OS_PROBER re-enabled by Debian 
Calamares installation:\nGRUB_DISABLE_OS_PROBER=false/g" 
$CHROOT/etc/default/grub
+chroot $CHROOT /usr/sbin/update-grub
"""

-Jonathan

unblock calamares-settings-debian/12.0.8-1

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Cyril Brulebois]

Control: retitle -1 hw-detect: firmware license cannot be accepted anymore
Control: clone -1 -2
Control: retitle -2 hw-detect: rework looping over filenames

Hi,

Pascal Hambourg  (2023-04-17):
> On 17/04/2023 at 17:52, Cyril Brulebois wrote:
> > Pascal Hambourg  (2023-04-17):
> > > > Ugly attached patch works for me as PoC.
> > > > Copy fd 0 into fd 9 (because it looked unused) before entering the
> > > > pipeline, and restore it when running install_firmware_pkg.
> > 
> > I think I'd be happy to take this patch for bookworm, as a workaround…

Let's keep -1 = #1033921 for Bookworm.

> > > Here is another patch for hw-detect moving the install_firmware_pkg()
> > > call outside the pipeline instead of playing with file descriptors.
> > 
> > … before considering a real/better fix after bookworm.

Let's use -2 post-Bookworm. Relatedly, some firmware filenames might
include spaces (why oh why), see #1029843. So we might benefit from
reworking the whole thing at some later point.

> I've never cloned a bug report, so I'd rather leave it to a more
> experienced user.

It's been a long time for me, let's see if that works. :)


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


signature.asc
Description: PGP signature

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[James Addison]

On Mon, 1 May 2023 at 17:53, Cyril Brulebois  wrote:
>
> James Addison  (2023-05-01):
> > I understand that line of thinking, but we note that we have already
> > received feedback on Salsa[1] from a user whose Bookworm installation
> > workflow has been affected, and confirmed that the reported problem
> > exists.
>
> And that user mentioned hostname=unassigned-hostname which would be
> addressed if we were to implement what I mentioned?

Yep, fair point!

> Initially it looked like specific values were expected to lead to a
> particular behaviour, but if we've been encouraging people to expect
> *any* fallback values specified there, that's indeed another story.
>
> (I had mentioned before “unassigned-hostname” wasn't to be seen in any
> packages but “unassigned-domain”/“unnassigned-domain” definitely have
> some specific handling.)

I do see that guestfs-tools references[1] them, and I suppose other
downstream software could do as well.  But within the installer's
components, I don't think that they have any special meaning.

> I have some pending yet unrelated things to investigate on the preseed
> side; I'm not sure I'll want to be testing each and every possible
> combination (esp. tweaking the configuration of the DHCP server behind
> the virtualization layer), but I should be able to test the water.

Totally reasonable, yep.  I'll try to get familiar with the process of
rebuilding the installer's initrd.

Currently I think that a relevant patch should:

  * Unset the hostname, or set the hostname to '(none)', so that the
installer's netcfg ignores[2] and is unaware of an install-time
hostname.
  * Within env2debconf, attempt to find a hostname specified on the
kernel command-line:
* The parameter may appear as a 'hostname=value', or
'hostname?=value' key=value pair.
* The parameter must appear strictly before any '---' delimiter_
in the line.
  * If a hostname was found:
* Create a local 'hostname' variable within the env2debconf'
script containing the hostname's value.
* Ensure that the 'seen' flag is assigned appropriately:
  * The value should be empty if the hostname was matched using
'hostname=value'.
  * The value should be non-empty if the hostname as matched using
'hostname?=value'.
  * If no hostname was found:
* Do nothing.

As I wrote up those criteria, they expanded and became more
complicated than I initially realized, so perhaps there could be
further hidden complexity here.  I'll do my best to prepare and test a
patch anyway.

[1] - 
https://sources.debian.org/src/guestfs-tools/1.48.3-4/customize/hostname.ml/?hl=125#L129

[2] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/?hl=578#L580

Bug#1035355: Fwd: btrbk: warnings with backported btrfs-progs in bullseye

[Paolo Consolaro]

Package: btrbk
 Version: 0.27.1-1.1

I'm using a Raspberry Pi4 with RaspberryOS bullseye. RaspberryOS is
Debian with some modified packages: in particular  a personalized
kernel.

RaspberryOS Bullseye has recently updated the kernel to 6.1 (against
Bullseye's 5.10). I have installed the backported version of
btrfs-progs for matching the kernel version (and solving some bugs),
so now I have btrfs-progs 6.1.

The problem: running btrbk now i get this (informative) warning:

WARNING: Failed to parse subvolume detail "Send transid: 0" for:
> /srv/dev-disk-by-uuid-c50a9181
> WARNING: Failed to parse subvolume detail "Send time: 2021-09-26 17:19:24
> +0200" for: /srv/dev-disk-by-uuid-c50a9181
> WARNING: Failed to parse subvolume detail "Receive transid: 0" for:
> /srv/dev-disk-by-uuid-c50a9181
> WARNING: Failed to parse subvolume detail "Receive time: -" for:
> /srv/dev-disk-by-uuid-c50a9181


This push my server to send a mail every time btrbk run.
It is discussed heare: https://github.com/digint/btrbk/issues/422

My proposed solutions (if possible):
- Backport btrbk 0.32.5-1 from testing
- or patch btrbk with the change of one code line (see
https://github.com/digint/btrbk/commit/74be074e6f0347dd729ea450fd5811dc1500f2f8)
(whitch I have done).

This problem should show up for every bullseye user with backported kernel
and btrfs-progs, not only in my setting.

Thank for yours attention.

Bug#1032671: linux: Enable USB_XHCI_PCI_RENESAS on arm64

[Cyril Brulebois]

Diederik de Haas  (2023-05-01):
> Control: forwarded -1 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/675
> 
> On Monday, 1 May 2023 09:47:48 CEST Roger Shimizu wrote:
> > Did you forget to enclose the patch?
> 
> It's here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/675

Yes, chicken and egg problem, I wanted to open a bug report first to
reference it in the commit / branch / merge request, but failed to
update the bug report afterwards; thanks for doing so, Diederik.


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


signature.asc
Description: PGP signature

Bug#1035353: fish: latest release breaks compat with mc

[Andrej Shadura]

Hi,



Today I upgraded fish from 3.1.2-3 and I noticed a regression of its
interaction with mc. The fish prompt no longer shows at the bottom part
of the screen, neither does the current directory, command entry doesn’t
work properly (unless I press ^O) — as is usual in the "shell busy"
state. As soon as I downgraded fish to the version in testing, this
regression disappeared.


Fish 3.6.1 ships a workaround for this bug:
https://github.com/fish-shell/fish-shell/pull/9540

I have submitted a merge request to fix it for bookworm:
https://salsa.debian.org/debian/fish/-/merge_requests/7

I have also created an unblock request: https://bugs.debian.org/1035354

Please let me know if I should proceed with an NMU or would you be so 
kind to upload it yourself :)


Thanks!

--
Cheers,
  Andrej

Bug#1035354: unblock: fish/3.6.0-3.1

[Andrej Shadura]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: f...@packages.debian.org, Mo Zhou 
Control: affects -1 + src:fish

Please unblock package fish

As described in #1000351, mc ships fragile prompt extraction code which
was broken by a change in fish 3.3.0, leaving fish unusable in
conjunction with mc. I had hoped that this bug would be fixed in mc by
the time of bookworm release, but this didn’t happen. Instead, the
upstream developers of fish proposed a workaround and shipped it
in the bugfix release 3.6.1.

I intend to either upload an NMU or let Mo Zhou do a maintainer’s
upload.

This fix has very limited impact, as it specifically checks for the
presence of an mc-specific environment variable, and is a no-op
otherwise. The workaround itself is also straightforward.

The impact of not shipping this patch is that all users of both fish and
mc (like myself) will have to put fish on hold and stay on the version
shipped in bullseye.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


Links:

[1]: https://bugs.debian.org/1035353: the original mc bug
[2]: https://bugs.debian.org/1000351: a clone of the above for the
 package fish
[3]: https://github.com/fish-shell/fish-shell/pull/9540: a pull request
 in the upstream package.

unblock fish/3.6.0-3.1
diff --git a/debian/changelog b/debian/changelog
index 51eef54d7c12..8e24670893ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+fish (3.6.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply an upstream workaround for Midnight Commander's issue with prompt.
+See https://github.com/fish-shell/fish-shell/pull/9540 and #1000351.
+
+ -- Andrej Shadura   Mon, 01 May 2023 19:01:01 +0200
+
 fish (3.6.0-3) unstable; urgency=medium
 
   * Cherry-pick upstream fixes from the v3.6.1 branch.
diff --git a/debian/patches/0003-workaround-for-Midnight-Commander.patch 
b/debian/patches/0003-workaround-for-Midnight-Commander.patch
new file mode 100644
index ..a744b9498963
--- /dev/null
+++ b/debian/patches/0003-workaround-for-Midnight-Commander.patch
@@ -0,0 +1,91 @@
+From d9f08d1e12a6d4dc66fdabe576bc79feb499abfd Mon Sep 17 00:00:00 2001
+From: Fabian Boehm 
+Date: Sat, 4 Feb 2023 18:57:41 +0100
+Subject: Add workaround for Midnight Commander's issue with prompt extraction
+
+When we draw the prompt, we move the cursor to the actual
+position *we* think it is by issuing a carriage return (via
+`move(0,0)`), and then going forward until we hit the spot.
+
+This helps when the terminal and fish disagree on the width of the
+prompt, because we are now definitely in the correct place, so we can
+only overwrite a bit of the prompt (if it renders longer than we
+expected) or leave space after the prompt. Both of these are benign in
+comparison to staircase effects we would otherwise get.
+
+Unfortunately, midnight commander ("mc") tries to extract the last
+line of the prompt, and does so in a way that is overly naive - it
+resets everything to 0 when it sees a `\r`, and doesn't account for
+cursor movement. In effect it's playing a terminal, but not committing
+to the bit.
+
+Since this has been an open request in mc for quite a while, we hack
+around it, by checking the $MC_SID environment variable.
+
+If we see it, we skip the clearing. We end up most likely doing
+relative movement from where we think we are, and in most cases it
+should be *fine*.
+
+Origin: upstream, https://github.com/fish-shell/fish-shell/pull/9540
+---
+
+diff --git a/src/env_dispatch.cpp b/src/env_dispatch.cpp
+index 28282f13ebd..9c3882ce02e 100644
+--- a/src/env_dispatch.cpp
 b/src/env_dispatch.cpp
+@@ -484,6 +484,14 @@ static void initialize_curses_using_fallbacks(const 
environment_t ) {
+ // Apply any platform-specific hacks to cur_term/
+ static void apply_term_hacks(const environment_t ) {
+ UNUSED(vars);
++// Midnight Commander tries to extract the last line of the prompt,
++// and does so in a way that is broken if you do `\r` after it,
++// like we normally do.
++// See https://midnight-commander.org/ticket/4258.
++if (auto var = vars.get(L"MC_SID")) {
++screen_set_midnight_commander_hack();
++}
++
+ // Be careful, variables like "enter_italics_mode" are #defined to 
dereference through cur_term.
+ // See #8876.
+ if (!cur_term) {
+diff --git a/src/screen.cpp b/src/screen.cpp
+index b6e1ea8c38a..ef8fbf16ff3 100644
+--- a/src/screen.cpp
 b/src/screen.cpp
+@@ -75,6 +75,12 @@ static size_t try_sequence(const char *seq, const wchar_t 
*str) {
+ return 0;  // this should never be executed
+ }
+
++static bool midnight_commander_hack = false;
++
++void screen_set_midnight_commander_hack() {
++midnight_commander_hack = true;
++}
++
+ /// Returns the number of columns left until the next tab 

Bug#1035351: [pre-approval] unblock: ncurses/6.4-3

[Cyril Brulebois]

Hallo Sven,

Sven Joachim  (2023-05-01):
> [ Other info ]
> Since ncurses produces udebs, I have CC'ed debian-boot and tagged the
> bug accordingly.  There should be no effect on the installer, as I
> would expect it to run all programs as root.

While I have never looked closely, that assessment seems very plausible
to me; based on this, no objections on the d-i side.


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


signature.asc
Description: PGP signature

Bug#1034372: ncurses: CVE-2023-29491

[Sven Joachim]

On 2023-04-23 08:47 +0200, Sven Joachim wrote:

> On 2023-04-18 20:15 -0400, Thomas Dickey wrote:
>
>> On Sat, Apr 15, 2023 at 07:27:45AM -0400, Thomas Dickey wrote:
>>> On Sat, Apr 15, 2023 at 09:05:25AM +0200, Sven Joachim wrote:
>>> > 
>>> > Security boundaries are only crossed for setuid/setgid programs here,
>>> > and we probably do not have many setuid binaries linked to libtinfo in
>>> > the distribution (on my system, I could not find any).  So I guess you
>>> > probably do not want to issue a DSA here, right?
>>> > 
>>> > Gentoo users have noticed a few problems after upgrading to the 20230408
>>> > patchlevel[1,2,3], most notably output of openrc being completely
>>> > broken.  While we do not have that particular problem because openrc in
>>> 
>>> It was already broken (the "(null)" strings come from its misuse of the
>>> ncurses interface, which will require fixes in OpenRC).  I'm not going
>>> to provide a patch for OpenRC itself - any maintainer should be able to
>>> do _that_.
>>> 
>>> Today I'll put out the fix for zero-parameter tsl, along with similar minor
>>> improvements, and if nothing else surfaces, use that as the basis for the
>>> security-patch.
>>
>> I had another fix, which works fine.  Except of course for programs which
>> call tparm without actually reading from the terminal database, and don't
>> check error returns.  I could digress...
>
> I am happy to reveal the bugs in theses non-conforming programs after
> the bookworm release, but for now this is too intrusive.  We are about
> to release Debian 12 within the next two months.
>
>> ...reflecting on all of this, the low-impact change would be to use the
>> --disable-root-environ configure option (possibly --disable-root-access
>> as well).
>
> The --disable-root-environ option disables _all_ use of custom terminfo
> files by the superuser.  This has some side effects.
>
> - At least one package FTBFS[1] because it runs TERMINFO=… tic under
>   fakeroot.
>
> - Rescue mode in the non-graphical Debian installer is broken if
>   ncurses-term is not installed.  The installer uses an obscure terminal
>   emulator called bogl-bterm which sets TERM=bterm, and if that terminfo
>   entry is not found on the target system, it copies it to a temporary
>   directory and sets TERMINFO accordingly before chrooting into the
>   target system.
>
> - Emacs' term.el package sets TERM=eterm-color and TERMINFO to the
>   directory where Emacs ships this terminfo entry.  If ncurses-term is
>   not installed, running programs as root is broken.
>
> - The sysadmin can no longer use private terminfo files under
>   /root/.terminfo and has to install those into the system database
>   instead, where they affect everyone.  This might not always be
>   desired.
>
> It is because of such issues that I had proposed a new configure option
> that only restricts programs running at elevated privileges[2].

Thomas was so kind to provide a new "--disable-setuid-environ" option in
the 20230423 patchlevel which does what I want.  I had looked at
backporting this option, but as that would require changes to multiple
files, and the patches did not apply cleanly without taking some
additional changes from the previous patchlevel first, I decided on a
different route.

By removing two lines in the _nc_env_access() function, the existing
"--disable-root-environ" option becomes functionally equivalent to the
new "--disable-setuid-environ" option, allowing for a rather minimal
patch.  In #1035351 I have asked for the release team's approval.

Cheers,
   Sven

Bug#1009163: import-orig: please make --upstream-vcs-tag=%(version)s strip +dfsg/+ds repack suffixes

[Guido Günther]

Hi Guilhem,
On Mon, Mar 06, 2023 at 01:37:01PM +0100, Guilhem Moulin wrote:
> Hi Guido,
> 
> On Wed, 01 Mar 2023 at 12:14:51 +0100, Guido Günther wrote:
> > On Tue, Aug 09, 2022 at 01:07:34PM +0200, Guilhem Moulin wrote:
> >> That'd work for me, thanks!  Some ideas to cover other use-cases if
> >> desired:
> >>
> >> - Always strip ‘+ds(\.\d*)?’ and ‘+dfsg(\.\d*)?’ repack suffixes
> >>   *after* version mangling.  After all, if upstream uses such suffixes
> >>   in its tags or version number, then the revision has to be mangled so
> >>   it doesn't collide with a repack suffix no?
> >> - New option --upstream-vcs-tag-strip='\+ds(\.\d*)?$'
> >
> > I wonder if a simple:
> >
> > --upstream-vcs-tag-strip
> >
> > that defaults to 'on' would already do the trick (as stripping this
> > should be the norm (as you elaborate in your first point) and the option
> > is only there if people want the old behavior.
> 
> That would cover my use-case nicely, at least :-)

Sorry for the delay. I've pushed something based on the patch in
#968329. Maybe we can even get away without another option this way.
Cheers,
 -- Guido

> 
> -- 
> Guilhem.

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

James Addison  (2023-05-01):
> I understand that line of thinking, but we note that we have already
> received feedback on Salsa[1] from a user whose Bookworm installation
> workflow has been affected, and confirmed that the reported problem
> exists.

And that user mentioned hostname=unassigned-hostname which would be
addressed if we were to implement what I mentioned?

> One datapoint isn't huge, but it's non-zero - and I'd expect that any
> installation using the 'hostname' preseed alias in combination with
> DHCP-as-hostname-provider would be similarly affected.
> 
> The bug here is essentially that the 'hostname' alias used to provide
> a fallback value, and in RC 2 d-i is used as the source of the primary
> value (ignoring DHCP).  If we know that that change has taken place, I
> think that we should either document it, or attempt to restore the
> existing behaviour.

Given the following comment above the netcfg/get_* lines, I tend to
agree.

# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.
d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain

Initially it looked like specific values were expected to lead to a
particular behaviour, but if we've been encouraging people to expect
*any* fallback values specified there, that's indeed another story.

(I had mentioned before “unassigned-hostname” wasn't to be seen in any
packages but “unassigned-domain”/“unnassigned-domain” definitely have
some specific handling.)

> The possibility about introducing other regressions with any further
> changes is a valid point.. I'm not sure how best to address that,
> other than testing the results in various configurations.
> 
> It feels to me like 'installer begins running without its own
> hostname' was likely a reasonable baseline assumption before Linux 6.0
> began reading the same-named 'hostname' parameter, and so as a result
> it feels like unsetting the hostname early in the installer
> initialization would be safe (maybe even a good idea, to reduce a
> source of input variation between install sessions).

Well, yes. But that isn't what we've been doing for several releases,
and going back to something-that-used-to-be-safe still worries me, esp.
with 12.0 around the corner.

I have some pending yet unrelated things to investigate on the preseed
side; I'm not sure I'll want to be testing each and every possible
combination (esp. tweaking the configuration of the DHCP server behind
the virtualization layer), but I should be able to test the water.


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


signature.asc
Description: PGP signature

Bug#1035352: libgetdata8: Patch for CVE-2021-20204 still present, and still breaks many regression tests

[Graeme Smecher]

Package: libgetdata8
Version: 0.11.0-6
Severity: important
X-Debbugs-Cc: gsmec...@threespeedlogic.com

Dear Maintainer,

The CVE-2021-20204 patch (debian/patches/CVE-2021-20204.patch) is still present
in the build tree. As reported in #2292437, this patch breaks many of the "make
check" tests in the upstream package. With the patch in place, libgetdata also
does not recognize many of my dirfiles (which use MPLEX or LINCOM
functionality).

I believe this patch is no longer necessary, since a fix for the CVE is
included in the current upstream source code. Please consider removing it.

Thanks again for all your efforts as a maintainer. I'm grateful for all you do.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgetdata8 depends on:
ii  libc6 2.36-8
ii  libltdl7  2.4.7-5
ii  libpcre3  2:8.39-15

libgetdata8 recommends no packages.

libgetdata8 suggests no packages.

-- no debconf information

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[James Addison]

Source: preseed
Followup-For: Bug #1031643

As requested, the hostname-param-ignores-DHCP regression bug has been filed
separately: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035349

Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Cyril Brulebois]

Hi,

Salvatore Bonaccorso  (2023-04-30):
> [ Other info ]
> As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
> Cyril on this pre-approval request.

Thanks for that.

> Furthermore the attached debdiff still contains the UNRELEASED
> changelog entry, which will be switched for the upload.

ACK.

With both my d-i and release hats: looks good to me, please go ahead.


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


signature.asc
Description: PGP signature

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[James Addison]

On Mon, 1 May 2023 at 16:00, Cyril Brulebois  wrote:
> James Addison  (2023-05-01):
> > Conditions:
> >
> >   * Preseed alias 'hostname' configured on the kernel command-line
> >   * There is a DHCP server on the installation-target's network that will 
> > provide a hostname
> >
> > Expected behaviour:
> >
> >   * Installer does not ask for installation-target hostname
> >   * Installation-target hostname is received and configured using DHCP
> >
> > Actual behaviour:
> >
> >   * [good] Installer does not ask for hostname
> >   * [bad] Hostname is configured from the command-line, ignoring the 
> > DHCP-negotiated hostname.
> >   * This is similar to 'netcfg/hostname' -- a different setting from 
> > 'netcfg/get_hostname'.
>
> Given the proximity of the tentative Bookworm release, my gut feeling
> would be to special-case the hostname=unassigned-hostname setting that's
> been documented since at least 2004, and limit “unsetting hostname” to
> this particular case.
>
> This should:
>  1. be good enough for anyone having followed the example preseed from
> any point in the past;
>  2. and equally importantly: limit possible side-effects.
>
> If that's not the case for (1), we should get bug reports with details
> about what people have actually been doing, and whether it makes sense
> to unset it unconditionally. If that's the case, we can let this thing
> mature in unstable/testing post-Bookworm, and once we're absolutely
> certain this isn't going to regress in some other weird way, we can
> consider backporting this to Bookworm, via a point release.

I understand that line of thinking, but we note that we have already
received feedback on Salsa[1] from a user whose Bookworm installation
workflow has been affected, and confirmed that the reported problem
exists.

One datapoint isn't huge, but it's non-zero - and I'd expect that any
installation using the 'hostname' preseed alias in combination with
DHCP-as-hostname-provider would be similarly affected.

The bug here is essentially that the 'hostname' alias used to provide
a fallback value, and in RC 2 d-i is used as the source of the primary
value (ignoring DHCP).  If we know that that change has taken place, I
think that we should either document it, or attempt to restore the
existing behaviour.


The possibility about introducing other regressions with any further
changes is a valid point.. I'm not sure how best to address that,
other than testing the results in various configurations.

It feels to me like 'installer begins running without its own
hostname' was likely a reasonable baseline assumption before Linux 6.0
began reading the same-named 'hostname' parameter, and so as a result
it feels like unsetting the hostname early in the installer
initialization would be safe (maybe even a good idea, to reduce a
source of input variation between install sessions).

[1] - 
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25

Bug#1035351: [pre-approval] unblock: ncurses/6.4-3

[Sven Joachim]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Tags: d-i
X-Debbugs-Cc: ncur...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:ncurses

I would like to address CVE-2023-29491[1] aka bug #1034372[2] in
Bookworm.

[ Reason ]
Various memory corruption bugs exist when loading specifically crafted
terminfo database files.  This is a security problem in programs running
with elevated privileges, as users are allowed to provide their own
terminfo files under ${HOME}/.terminfo or via the TERMINFO or
TERMINFO_DIRS environment variables.

Backporting the upstream fixes seems to be too risky this late in the
release process, but via a configure option it is possible to prevent
setuid/setgid programs from loading custom terminfo files supplied by
the user, after which the bugs are no longer security relevant.

[ Impact ]
Local users could try privilege escalations in setuid/setgid programs
linked to the tinfo library.  How easily those can be achieved probably
depends on the program.

[ Tests ]
No automatic tests exist.  I have manually verified that programs can no
longer use custom terminfo files if their effective UID or GID differs
from the real one.  Also I have verified that the terminfo database in
the ncurses-{base,term} packages is unchanged from 6.4-2.

[ Risks ]
Users who are relying on their own terminfo files under
${HOME}/.terminfo can no longer use them in setuid/setgid programs and
will have to work around that, e.g. by changing their TERM variable,
using a different terminal emulator or asking their sysadmin for help.

On my systems I did not find any setuid binaries linked to the tinfo
library, but some setgid games in the bsdgames package.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

I have slightly edited the debdiff to exclude spurious changes to the
debian/lib{32,64}tinfo6.symbols files, as these are just symlinks to
libtinfo6.symbols.  See devscripts bug #773762[3].

[ Other info ]
Since ncurses produces udebs, I have CC'ed debian-boot and tagged the
bug accordingly.  There should be no effect on the installer, as I would
expect it to run all programs as root.

Thanks for consideration.

Cheers,
   Sven


1. https://security-tracker.debian.org/tracker/CVE-2023-29491
2. https://bugs.debian.org/1034372
3. https://bugs.debian.org/773762

diff -Nru ncurses-6.4/debian/changelog ncurses-6.4/debian/changelog
--- ncurses-6.4/debian/changelog	2023-01-25 21:21:49.0 +0100
+++ ncurses-6.4/debian/changelog	2023-05-01 17:57:51.0 +0200
@@ -1,3 +1,21 @@
+ncurses (6.4-3) unstable; urgency=medium
+
+  * Configure with "--disable-root-environ" to disallow loading of
+custom terminfo entries in setuid/setgid programs, mitigating the
+impact of CVE-2023-29491 (see #1034372).
+- Update the symbols files for the newly exported symbol
+  _nc_env_access.
+- New patch fix-configure-root-args-option.diff cherry-picked from
+  the 20230415 patchlevel, fixing a copy/paste error which caused
+  the "--disable-root-environ" configure option to pick up code
+  meant to be used by the "--disable-root-args" option instead.
+- New patch debian-env-access.diff, changing the behavior of the
+  "--disable-root-environ" configure option to not restrict programs
+  run by the superuser, equivalent to the "--disable-setuid-environ"
+  option introduced in the 20230423 patchlevel.
+
+ -- Sven Joachim   Mon, 01 May 2023 17:57:51 +0200
+
 ncurses (6.4-2) unstable; urgency=medium

   * Add Breaks against vim-common (<< 2:9.0.1000-2) to ncurses-base
diff -Nru ncurses-6.4/debian/libtinfo5.symbols ncurses-6.4/debian/libtinfo5.symbols
--- ncurses-6.4/debian/libtinfo5.symbols	2023-01-22 17:54:52.0 +0100
+++ ncurses-6.4/debian/libtinfo5.symbols	2023-05-01 11:36:38.0 +0200
@@ -95,6 +95,7 @@
  _nc_curr_col@NCURSES_TINFO_5.0.19991023 6
  _nc_curr_line@NCURSES_TINFO_5.0.19991023 6
  _nc_doalloc@NCURSES_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES_TINFO_5.2.20001021 6.4-3~
  _nc_err_abort@NCURSES_TINFO_5.0.19991023 6
  _nc_fallback@NCURSES_TINFO_5.0.19991023 6
  _nc_find_entry@NCURSES_TINFO_5.0.19991023 6
diff -Nru ncurses-6.4/debian/libtinfo6.symbols ncurses-6.4/debian/libtinfo6.symbols
--- ncurses-6.4/debian/libtinfo6.symbols	2023-01-22 17:54:52.0 +0100
+++ ncurses-6.4/debian/libtinfo6.symbols	2023-05-01 11:36:38.0 +0200
@@ -94,6 +94,7 @@
  _nc_curr_col@NCURSES6_TINFO_5.0.19991023 6
  _nc_curr_line@NCURSES6_TINFO_5.0.19991023 6
  _nc_doalloc@NCURSES6_TINFO_5.0.19991023 6
+ _nc_env_access@NCURSES6_TINFO_5.2.20001021 6.4-3~
  _nc_err_abort@NCURSES6_TINFO_5.0.19991023 6
  _nc_export_termtype2@NCURSES6_TINFO_6.1.20171230 6.1
  _nc_fallback2@NCURSES6_TINFO_6.1.20171230 6.1
diff -Nru ncurses-6.4/debian/patches/debian-env-access.diff 

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Vagrant Cascadian]

On 2023-05-01, Pascal Hambourg wrote:
> On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian 
>  wrote:
>> On 2023-05-01, Steve McIntyre wrote:
>> "ls" from the grub prompt did not show the other disk...
>> ...until I made the second disk bootable from libvirt!
>> Then grub now sees both disks, and boots fine!
>> So this is possibly a quirk of the way libvirt exposes boot disks.
>
> Apparently. GRUB can only see disks exposed by the BIOS/UEFI/other 
> platform firmware. There are other known situations where a given 
> firmware may not expose some disks, including but not limited to:
> - disks connected to a SATA controller card without a BIOS expansion ROM
> - unsupported media types: USB other than the boot disk, NVMe, SD/MMC...
>
> The UEFI firmware on an old Intel board only had EFI drivers for the 
> SATA controller in IDE mode and lacked EFI drivers for AHCI and USB. It 
> has been reported that more recent boards had support for NVMe only in 
> EFI mode, not in legacy mode.
...
>> Re-running grub-install /dev/vda from debian-installer rescue mode did
>> *not* fix the issue for me
>
> Because there were two issues preventing GRUB from seeing the new PV:
> - the disk was not exposed by libvirt BIOS
> - the disk had an unsupported GPT partition scheme
>
> grub-install fixed only the second issue. Making the disk "bootable" in 
> libvirt was required to fix the first issue.
>
>> (though, now I am curious if dpkg-reconfigure
>> grub-pc would do anything more?)
>
> As Steve wrote, dpkg-reconfigure also runs update-grub to rebuild 
> grub.cfg. AFAIK here the only difference with the old grub.cfg is 
> additional "insmod part_gpt" commands to load GPT support, but the 
> module must already be embedded in the core image so this addition is 
> not required.

Well, in my original bug report, grub.cfg did contain both:

  insmod part_gpt
  insmod part_msdos

Although, maybe it is possible that was generated after running
update-grub...

Even though a perfectly reasonable stance is just to use a split /boot
partition, I may keep experimenting with this to get greater confidence
we really understand what went wrong. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Cyril Brulebois]

Control: reassign -1 xserver-xorg-core-udeb 2:21.1.1-1
Control: affects -1 debian-installer

Hello debian-x,

Cyril Brulebois  (2023-04-27):
> Tracked down to 9c81b8f5b5 upstream:
>   https://cgit.freedesktop.org/xorg/xserver/commit/?id=9c81b8f5b5
> 
> Flipping the switch and wrapping it up in a netboot mini.iso
> debian-installer build led to a successful test (with amd64) by Keith.
> We'll try and confirm the same happens with arm64.
> 
> If you're happy with that approach, feel free to reassign to the udeb,
> and check the udeb-modesetting branch in xorg-server:
>   
> https://salsa.debian.org/xorg-team/xserver/xorg-server/-/commits/udeb-modesetting

Any objections to my merging/uploading this?


> I don't have access to VirtualBox right now, but we've had reports of
> failures there as well, maybe that's the same kind of things.

For completeness:

A friend of mine tested all 3 available options (VBoxVGA, VMSVGA, and
VBoxSVGA) in VirtualBox, on both Windows and Apple hosts, and the
graphical installer worked fine for him in all cases, so it looks like
the VirtualBox reports we've received are about a different issue (and
we're lacking feedback at the moment).


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


signature.asc
Description: PGP signature

Bug#1035101: Failed to detect HD if Intel RST-RAID is active

[Cyril Brulebois]

Hi,

Thomas Viehweger  (2023-04-29):
> I am able to do one test...

OK, great!

I've just rebuilt an amd64 netinst image, bundling the extra module inside
(/lib/modules/6.1.0-7-amd64/kernel/drivers/platform/x86/intel/intel-rst.ko)
and I've verified that this module loads fine in a VM.

Whether that works and actually makes the disk visible is for you to report!
(Bonus points if the disk can actually be used, but I realize you might not
want to reinstall entirely, and only check whether the disk detection is
working…)

I've uploaded the test image here, it will go away after 15 days to avoid
hogging disk space on that shared machine:
  https://people.debian.org/~kibi/bug-1035101/


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


signature.asc
Description: PGP signature

Bug#1034077: debian-security-support: Lots of noise about DEBIAN_VERSION 12 being invalid when upgrading bullseye→bookworm

[Holger Levsen]

Hi,

On Fri, Apr 14, 2023 at 11:16:16AM +, Holger Levsen wrote:
> > Incrementing to DEB_NEXT_VER_ID=12 in the next bullseye point release seems
> > reasonable to me; also incrementing in bookworm to DEB_NEXT_VER_ID=13 would
> > be logical.
> I'll ponder about this is a bit more before doing such uploads. Like for
> 2 or 48h or so. Please do ping me if I forget.

hmpf, I indeed forgot to fix this for the last bullseye point release :/

And if also just done another bullseye2bookworm upgrade and saw this bug 
many times myself :/

Setting up libpam-modules:amd64 (1.5.2-6) ...
Installing new version of config file /etc/security/limits.conf ...
Installing new version of config file /etc/security/sepermit.conf ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
(Reading database ... 82537 files and directories currently installed.)
Preparing to unpack .../libpam-runtime_1.5.2-6_all.deb ...
Unpacking libpam-runtime (1.5.2-6) over (1.4.0-9+deb11u1) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
Setting up libpam-runtime (1.5.2-6) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
(Reading database ... 82537 files and directories currently installed.)
Preparing to unpack .../libcryptsetup12_2%3a2.6.1-4~deb12u1_amd64.deb ...
Unpacking libcryptsetup12:amd64 (2:2.6.1-4~deb12u1) over (2:2.3.7-1+deb11u1) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
Setting up libdevmapper1.02.1:amd64 (2:1.02.185-2) ...
Setting up libcryptsetup12:amd64 (2:2.6.1-4~deb12u1) ...
Setting up dmsetup (2:1.02.185-2) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
Selecting previously unselected package libsystemd-shared:amd64.
(Reading database ... 82537 files and directories currently installed.)
Preparing to unpack .../libsystemd-shared_252.6-1_amd64.deb ...
Unpacking libsystemd-shared:amd64 (252.6-1) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
Setting up libapparmor1:amd64 (3.0.8-3) ...
Setting up libkmod2:amd64 (30+20221128-1) ...
Setting up libsystemd-shared:amd64 (252.6-1) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
(Reading database ... 82545 files and directories currently installed.)
Preparing to unpack .../libsystemd0_252.6-1_amd64.deb ...
Unpacking libsystemd0:amd64 (252.6-1) over (247.3-7+deb11u2) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
Setting up libsystemd0:amd64 (252.6-1) ...
Setting up libfdisk1:amd64 (2.38.1-5+b1) ...

hmpf.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We live in a world where teenagers get more and more desperate trying to
convince adults to behave like grown ups.


signature.asc
Description: PGP signature

Bug#1035350: postfix: postinst script modifies configuration files despite local changes

[Einhard Leichtfuß]

Package: postfix
Version: 3.5.18-0+deb11u1
Severity: serious

Upon upgrade of postfix (due to `apt dist-upgrade`), the `master.cf`
[and `main.cf`] configuration files were modified by the postinst
script, despite existing local changes.

If I understand correctly, this violates Debian Policy 10.7.3 [0]:
"local changes must be preserved during a package upgrade".  This is why
I chose Severity "serious".

I would instead expect a handling similar to that of changed conffiles
(i.e., one is given an option to or is suggested to apply certain
modifications).


In `master.cf`, the following lines were appended:
> proxymap  unix  -   -   n   -   -   proxymap
> verifyunix  -   -   y   -   1   verify
> relay unix  -   -   n   -   -   smtp -o 
> smtp_fallback_relay=
> #   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5

See the `fix_master()` function in the postinst script.

(sidenote: The first two entries are the same as in
`/usr/share/postfix/master.cf.dist`, the last one is different.)


In `main.cf`, the following lines were appended:
> readme_directory = /usr/share/doc/postfix
> html_directory = /usr/share/doc/postfix/html

If I understand the postinst script correctly, this modification of
`main.cf` should only have happened upon first installation, which this
was not.  I was unable to reproduce this.  So maybe this modification
was indeed done earlier.

However, even upon initial installation (with pre-existing
configuration), this should, in my opinion, not happen.


The changes were accompanied by the following message:
> Setting up postfix (3.5.18-0+deb11u1) ...
> In master.cf:
>   adding missing entry for proxymap service
>   adding missing entry for verify service
>   adding missing entry for relay service
> 
> Postfix (main.cf) configuration was untouched.  If you need to make changes,
> edit /etc/postfix/main.cf (and others) as needed.  To view Postfix
> configuration values, see postconf(1).
> 
> After modifying main.cf, be sure to run 'systemctl reload postfix'.
The message that `main.cf` was untouched is displayed regardless of
whether the above noted modifications of `main.cf` are made.


I noticed that many actions in the postinst script are only run if
`[ "$mailer" != "No configuration" ]`.  I am unsure whether this case
would warrant the above mentioned modifications.  If so, maybe this
condition should be added to these modifications.


[0] https://www.debian.org/doc/debian-policy/ch-files.html#behavior



-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-22-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-4
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.12
ii  e2fsprogs  1.46.2-2
ii  libc6  2.31-13+deb11u6
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u4
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.0+nmu1

Versions of packages postfix recommends:
ii  ca-certificates  20210119
ii  python3  3.9.2-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20180807cvs-2
ii  dovecot-core [dovecot-common]  1:2.3.13+dfsg1-2+deb11u1
pn  postfix-cdb
ii  postfix-doc3.5.18-0+deb11u1
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
ii  postfix-pgsql  3.5.18-0+deb11u1
pn  postfix-sqlite 
pn  procmail   
pn  resolvconf 
pn  ufw

-- debconf information:
  postfix/relay_restrictions_warning:
  postfix/bad_recipient_delimiter:
  postfix/destinations: $myhostname, myfancyhostname,
localhost.localdomain, , localhost
  postfix/newaliases: false
  postfix/not_configured:
  postfix/main_cf_conversion_warning: true
  postfix/procmail: false
  postfix/mailname: myfancyhostname
  postfix/sqlite_warning:
  postfix/mailbox_limit: 0
  postfix/protocols: all
  postfix/dynamicmaps_conversion_warning:
  postfix/tlsmgr_upgrade_warning:
  postfix/kernel_version_warning:
  postfix/root_address:
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/lmtp_retired_warning: true
  postfix/retry_upgrade_warning:
  postfix/recipient_delim: +
  postfix/chattr: false
* postfix/main_mailer_type: No 

Bug#1033231: fixed in postgrey 1.37-2

[Tim Boneko]

Hello!
After a little testing i can confirm that postgrey is installed fine:
The user is created with uid=119 and gid=130, /etc/postgrey contains
the files whitelist_clients and whitelist_recipients and the daemon
seems to be running fine.
Thanks a lot!
Cheers,

tim

Tested version: 1.37-2 from unstable
Platform: amd64
Debian version: 12/testing
Recommended packages from testing



On Sun, 30 Apr 2023 23:18:59 + Debian FTP Masters
 wrote:
> Source: postgrey
> Source-Version: 1.37-2
> Done: Jordi Mallach 
> 
> We believe that the bug you reported is fixed in the latest version
of
> postgrey, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one
is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to
1033...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Jordi Mallach  (supplier of updated postgrey
package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Mon, 01 May 2023 00:57:30 +0200
> Source: postgrey
> Architecture: source
> Version: 1.37-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Jordi Mallach 
> Changed-By: Jordi Mallach 
> Closes: 1031401 1033231
> Changes:
>  postgrey (1.37-2) unstable; urgency=medium
>  .
>    * Use %H in the service file to set the hostname in the rejection
message
>  (closes: #1031401).
>    * Add missing ucf machinery so the default config file and
whitelists get
>  installed correctly (closes: #1033231).
>    * Reinstate creation of postgrey user.
>    * Ensure /var/lib/postgrey exists and is owned by postgrey.
> Checksums-Sha1:
>  55f468de0bc7b115b24b782df971dc1d315977a0 1888 postgrey_1.37-2.dsc
>  5d48d6399d98c4ff93a5298c4129a61607332284 18584 postgrey_1.37-
2.debian.tar.xz
>  f4ee4febb21d2bc5c5a256c3232ba10a64096289 6169 postgrey_1.37-
2_amd64.buildinfo
> Checksums-Sha256:
>  87c3ac7f80fab0a0bf2710ec1f4bd21614ff508d68a8c5c0a61191bce19c1455
1888 postgrey_1.37-2.dsc
>  7920f5299346b1d29b20fb18779350264fa0de7275f18a3b9e6a956e0a8b1f6e
18584 postgrey_1.37-2.debian.tar.xz
>  0c91dc74591a19387c8e82276a8d3bf1f224caac87c8d6e07830cf551a3e75da
6169 postgrey_1.37-2_amd64.buildinfo
> Files:
>  d27b863757d844ed32d511bc7d5dc441 1888 mail optional postgrey_1.37-
2.dsc
>  b1d772f1519986eead7640c64a89bef0 18584 mail optional postgrey_1.37-
2.debian.tar.xz
>  5e72d9727b2d0a152ff8a905803e6b44 6169 mail optional postgrey_1.37-
2_amd64.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

Hi James,

And thanks for the report/forward from elsewhere, much appreciated

James Addison  (2023-05-01):
> This bugreport is a subset/related-to bug #1031643, also in preseed.
> 
> When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to
> Bookworm's RC 2 installer as a kernel command-line argument, the value that
> it contains unexpectedly takes higher precedence over a hostname received from
> DHCP, contrary to the Installation Guide documentation[1] in combination with
> the corresponding netcfg documentation[2].
> 
> 
> Conditions:
> 
>   * Preseed alias 'hostname' configured on the kernel command-line
>   * There is a DHCP server on the installation-target's network that will 
> provide a hostname
> 
> Expected behaviour:
> 
>   * Installer does not ask for installation-target hostname
>   * Installation-target hostname is received and configured using DHCP
> 
> Actual behaviour:
> 
>   * [good] Installer does not ask for hostname
>   * [bad] Hostname is configured from the command-line, ignoring the 
> DHCP-negotiated hostname.
>   * This is similar to 'netcfg/hostname' -- a different setting from 
> 'netcfg/get_hostname'.

Given the proximity of the tentative Bookworm release, my gut feeling
would be to special-case the hostname=unassigned-hostname setting that's
been documented since at least 2004, and limit “unsetting hostname” to
this particular case.

This should:
 1. be good enough for anyone having followed the example preseed from
any point in the past;
 2. and equally importantly: limit possible side-effects.

If that's not the case for (1), we should get bug reports with details
about what people have actually been doing, and whether it makes sense
to unset it unconditionally. If that's the case, we can let this thing
mature in unstable/testing post-Bookworm, and once we're absolutely
certain this isn't going to regress in some other weird way, we can
consider backporting this to Bookworm, via a point release.


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


signature.asc
Description: PGP signature

Bug#1030119: Bug#1018260: openssh-server: fills the log with "deprecated reading of user environment enabled"

[Richard Lewis]

On Tue, 31 Jan 2023 10:52:54 + Colin Watson  wrote:

> There's now
> https://salsa.debian.org/ssh-team/openssh/-/merge_requests/21 for this,
> but as noted there I have documentation concerns about simply removing
> this.  Copying my comments from there:

>   At a bare minimum, this needs an entry in debian/NEWS.  But I'd go
>   further: I think this should be documented in Debian's release notes
>   (repository at https://salsa.debian.org/ddp-team/release-notes) for a
>   release before we make this change.  That won't inform everyone, but
>   it should reduce the number of people caught unawares by this.  Any
>   other practical ideas for informing affected users would be welcome.
>

Was there an update on this bug against release-notes: the MR against openssh at
https://salsa.debian.org/ssh-team/openssh/-/merge_requests/21/diffs
doesnt seem to be merged - has this been parked?

Based on the text in that MR , but if I i used this feature i would
want to know:
- can this prevent me logging in? (eg if i am doing the upgrade over ssh)
- will it drop my ssh connection (release-notes does iirc advise
upgrading inside tmux or screen)
- what do i do if i need the settings in pam-envionment - can i add
them to ssh_config? (I assume re-enabling a
 deprecated setting is not a good thing to recommend in release-notes)
(and should i do so before or after upgrading?)


The release notes could say something like:


ssh no longer reads ~/.pam-environment

  The ssh package, which allows
secure login to remote systems, no longer reads the user's
~/.pam_environment file by default.
  See  for details.
  If you used this feature, you should move variables set in
~/.pam_environment file to
~/.ssh/ssh_config before upgrading .



(should there be something about the pam deprecation itself?)

Bug#1035347: boxer-data: generates dependencies on no longer installable lightning

[Andreas Beckmann]

Followup-For: Bug #1035347
Control: notfixed -1 10.9.4
Control: fixed -1 10.9.6
Control: block 1000872 with -1

The thunderbird-l10n-si change from 10.9.6 needs to be backported to
bullseye as well.


Andreas

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[James Addison]

Source: preseed
Version: 1.115
Severity: important
Tags: d-i

Dear Maintainer,

This bugreport is a subset/related-to bug #1031643, also in preseed.

When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to
Bookworm's RC 2 installer as a kernel command-line argument, the value that
it contains unexpectedly takes higher precedence over a hostname received from
DHCP, contrary to the Installation Guide documentation[1] in combination with
the corresponding netcfg documentation[2].


Conditions:

  * Preseed alias 'hostname' configured on the kernel command-line
  * There is a DHCP server on the installation-target's network that will 
provide a hostname

Expected behaviour:

  * Installer does not ask for installation-target hostname
  * Installation-target hostname is received and configured using DHCP

Actual behaviour:

  * [good] Installer does not ask for hostname
  * [bad] Hostname is configured from the command-line, ignoring the 
DHCP-negotiated hostname.
  * This is similar to 'netcfg/hostname' -- a different setting from 
'netcfg/get_hostname'.



Context:

Since Linux 6.0, a 'hostname=...' parameter provided in the kernel command-line
is no-longer loaded into the init process environment as a variable, but is
instead used to set the hostname of the running system (skipping the
need for userspace tooling to achieve that).

That caused a conflict for the preseed aliases in the Debian Installer, because
one of the aliases is also 'hostname', mapped to 'netcfg/get_hostname'.

The fix applied in #1031643 loads the 'running system hostname' into the
environment if it is non-empty and not equal to '(none)'.  This allows
unattended installs to work again.

The 'netcfg' component that determines the system hostname (prompting for it
from the operator if required) to be installed will prefer a non-empty hostname
(as long as it is not the literal string '(none)') over one provided by DHCP
in this block of code: https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578

Thanks,
James

[1] - 
https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases

[2] - 
https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160

Bug#1035348: nbd: new upstream release

[Wouter Verhelst]

Source: nbd
Severity: wishlist

I just released an upstream version of NBD. I won't upload it to
unstable until bookworm is released, and I'm not liable to forget, but
experience tells me that in situations like that I tend to get useless
wishlist bug reports against nbd, so here's me just telling people not
to bother ;-)

Bug#1012174: Inconsistent advice wrt security archive

[Richard Lewis]

On Tue, 31 May 2022 16:13:27 +0100 Brian Potkin  wrote:
> On Tue 31 May 2022 at 14:58:00 +0200, Julien Cristau wrote:
> > On Tue, May 31, 2022 at 02:26:39PM +0200, David Prévot wrote:

> > > The [errata] advises one to use
> > >
> > >   deb http://security.debian.org/debian-security bullseye-security main 
> > > contrib non-free
> > >
> > > while the [release-notes] advises
> > >
> > >   deb https://deb.debian.org/debian-security bullseye-security main 
> > > contrib

> > >   errata: https://www.debian.org/releases/stable/errata#security
> > >   release-notes: 
> > > https://www.debian.org/releases/stable/amd64/release-notes/ch-information#security-archive
> > >
> > The release-notes version is preferred, as far as scheme and hostname.
>
> There appears to be a consensus in favour of https. For example:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692#37

In release-notes the only http:// i could find was in en/upgrading.dbk
(apart from inside xmlns markup)
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/160
has just been submitted to update this to https

I dont think the 'errata' page above is in the release-notes repository (?)

Bug#1035347: boxer-data: generates dependencies on no longer installable lightning

[Andreas Beckmann]

Package: boxer-data
Version: 10.8.28
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: fixed -1 10.9.4
Control: block 1000737 with -1
Control: block 1035344 with -1

src:thunderbird has stopped building the lightning package as part of a
stable update, rendering parl-desktop and design-desktop uninstallable
in stable. In order to rebuild them with changed dependencies,
boxer-data needs to be updated in bullseye first.


Andreas

Bug#1035346: debian-installer: Failure to eject or recognize external media ejected

[bud]

Package: debian-installer
Version: bookworm
Severity: important
Tags: d-i
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Normal installation, full DVD set, USB (external) burner/reader
I selected Graphical mode but mostly used the keyboard
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Prior to this installation I was jumping the gun and pressing Continue as soon 
as the new disk was inserted. This got into a situation where I could not 
recover. There was no Back button and manually removing the disk and 
ineffective. This is emblematic of debian-installer's problem. I tried to 
submit this bug as grave but got no email response and cannot find the report.

This time I waited for each inserted disk to settle, as one would wait for apt; 
 before the system does not show the new volume has mounted, apt is likely to 
spit out another request for a media change.

If immediately pressing Enter after closing the disk's door, d-i usually worked 
but, for instance, the previous attempt d-i stalled on disk 3, where Back and 
Continue buttons did nothing and waiting or manually ejection did nothing. 
Power down is the only option. This, again, is something d-i should handle.

This bug is about a failure to recognize a media change at the end of 
installing the userland. Perhaps, fixing this will let the above bugs at least 
limp over the line. d-i asked to use "the drive '/media/cdrom'" and not cdrom0.

I checked every available option and selected LXDM; I tried SDDM earlier with 
similar results. That is, d-i asked for a media swap when done with disk 1.

Just before the GRUB step, d-i asks for a swap back to disk 1 but d-i will not 
recognize the burner's eject button has been pressed. There is a "Go Back" 
button and I had to clicked there twice before the main menu appeared and d-i 
finally recognized the reinserted disk. For good measure, I went back to the 
software installation step, which did nothing except exit normally, at which 
point GRUB did its things without further ado.

d-i will eject the external disk when asking the user to reboot into the new 
system, but everywhere else, misses the target. Maybe a fix here can propagate 
and fix all the problems listed above, some of which have been happening for 
many releases.

   * What was the outcome of this action?

I was able to install bookworm but only in an unexpected fashion.

   * What outcome did you expect instead?

d-i should allow the user to remove the external media practically at will. 
When the eject button is pressed, d-i should recognize that and unmount and 
eject the disk as soon as possible. If a disk is inserted, d-i should recognize 
the new disk as soon as the system mounts it.

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1035342: binutils: Native binutils-TUPLE provides tool names that cross binutils-TUPLE does not

[Matthias Klose]

On 01.05.23 14:53, Simon McVittie wrote:

Source: binutils
Version: 2.40-2
Severity: normal

binutils-x86-64-linux-gnu can be compiled as a native binutils to be run on
amd64 and emit amd64 binaries, or as a cross-binutils to be run on some
other architecture like for example ppc64el (and still emit amd64 binaries).

The native binutils-x86-64-linux-gnu:amd64 contains symlinks
/usr/bin/x86_64-linux-gnu-gold -> x86_64-linux-gnu-ld.gold for the gold
linker, and
/usr/bin/x86_64-linux-gnu-ld -> x86_64-linux-gnu-ld.bfd for the traditional
BFD linker, together with their man pages.

The cross packages like binutils-x86-64-linux-gnu:ppc64el contain
/usr/bin/x86_64-linux-gnu-ld -> x86_64-linux-gnu-ld.bfd, but do not have
/usr/bin/x86_64-linux-gnu-gold -> x86_64-linux-gnu-ld.gold.

This seems inconsistent: I would have expected that binutils-TUPLE would
either always provide TUPLE-gold, or never provide TUPLE-gold.


this is an oversight, will fix this in experimental.


Similarly, binutils-x86-64-linux-gnu:amd64 provides TUPLE-gp-archive (and
other gp- tools) and TUPLE-gprofng, but binutils-x86-64-linux-gnu:ppc64el
doesn't provide those.


the profiling parts are not included in the cross packages by intent. Is there a 
use case where these are necessary?  Shouldn't you be able to use the native 
packages?

Bug#1035345: unblock: libbssolv-perl/0.17-4

[Andrej Shadura]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libbssolv-p...@packages.debian.org
Control: affects -1 + src:libbssolv-perl

Please unblock package libbssolv-perl

Library libbssolv is used by e.g. OBS to resolve dependencies
of packages to be built. When processing Debian packages,
the current version doesn’t accept "0" as a valid epoch, resulting
it packages like woff-tools that have a zero epoch (0:2009.10.04-2)
to be skipped and be forever unresolvable.

Since the only rdep of libbssolv-perl in Debian is OBS, impact on the
rest of Debian is near-zero. The risk of not shipping this change is also
low, but it would help users avoid patching this package.

In the debdiff, I’m also including low-impact changes to the metadata
that were sitting in Git for the last two years.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libbssolv-perl/0.17-4
diff --git a/debian/changelog b/debian/changelog
index 9cb7ecf70812..b138325c88db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+libbssolv-perl (0.17-4) unstable; urgency=medium
+
+  [ Debian Janitor ]
+  * Bump debhelper from old 12 to 13.
+  * Update standards version to 4.6.0, no changes needed.
+
+  [ Andrej Shadura ]
+  * Add a patch proposed upstream to accept "0" as a valid epoch.
+See https://github.com/openSUSE/perl-BSSolv/pull/17
+
+ -- Andrej Shadura   Mon, 01 May 2023 16:14:28 +0200
+
 libbssolv-perl (0.17-3) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/control b/debian/control
index 02b5c716f1f6..7adabd60217f 100644
--- a/debian/control
+++ b/debian/control
@@ -4,11 +4,11 @@ Uploaders: Mike Gabriel 
 Section: perl
 Testsuite: autopkgtest-pkg-perl
 Priority: optional
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
libsolv-dev (>= 0.7),
perl-xs-dev,
perl:native
-Standards-Version: 4.5.0
+Standards-Version: 4.6.0
 Vcs-Browser: https://salsa.debian.org/perl-team/modules/packages/libbssolv-perl
 Vcs-Git: https://salsa.debian.org/perl-team/modules/packages/libbssolv-perl.git
 Homepage: https://github.com/openSUSE/perl-BSSolv
diff --git a/debian/patches/1001-accept-0-as-epoch.patch 
b/debian/patches/1001-accept-0-as-epoch.patch
new file mode 100644
index ..e29b40182832
--- /dev/null
+++ b/debian/patches/1001-accept-0-as-epoch.patch
@@ -0,0 +1,25 @@
+From: Sjoerd Simons 
+Date: Mon, 1 May 2023 15:35:09 +0200
+Subject: Accept "0" as an epoch
+
+In Debian an zero epoch is actually valid; e.g. woff-tools actually has
+a zero epoch (0:2009.10.04-2).
+
+Signed-off-by: Sjoerd Simons 
+---
+ BSSolv.xs | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/BSSolv.xs b/BSSolv.xs
+index ced6823..31c7a7a 100644
+--- a/BSSolv.xs
 b/BSSolv.xs
+@@ -207,8 +207,6 @@ makeevr(Pool *pool, char *e, char *v, char *r)
+ 
+   if (!v)
+ return 0;
+-  if (e && !strcmp(e, "0"))
+-e = 0;
+   if (e)
+ s = pool_tmpjoin(pool, e, ":", v);
+   else
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..65e3b6438662
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+1001-accept-0-as-epoch.patch
>From f974c721737f71cde617aab37ba92eb785ac7d14 Mon Sep 17 00:00:00 2001
From: Sjoerd Simons 
Date: Mon, 1 May 2023 15:35:09 +0200
Subject: [PATCH] Accept "0" as an epoch

In Debian an zero epoch is actually valid; e.g. woff-tools actually has
a zero epoch (0:2009.10.04-2).

Signed-off-by: Sjoerd Simons 
---
 BSSolv.xs | 2 --
 1 file changed, 2 deletions(-)

diff --git a/BSSolv.xs b/BSSolv.xs
index ced6823..31c7a7a 100644
--- a/BSSolv.xs
+++ b/BSSolv.xs
@@ -207,8 +207,6 @@ makeevr(Pool *pool, char *e, char *v, char *r)
 
   if (!v)
 return 0;
-  if (e && !strcmp(e, "0"))
-e = 0;
   if (e)
 s = pool_tmpjoin(pool, e, ":", v);
   else

Bug#1035344: parl-desktop: depends on no longer installable lightning

[Andreas Beckmann]

Package: parl-desktop
Version: 1.9.27
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: fixed -1 1.9.29

parl-desktop/bullseye is no longer installable since thunderbird stopped
building the transitional lightning package in stable, too. (There is
only an uninstallable cruft lightning version left in bullseye-security.)

Please make parl-desktop installable in stable again by updating
boxer-data in stable and rebuilding src:debian-parl against that.


Andreas

Bug#992345:

[Richard Lewis]

package: release-notes

# disk space
tags 992345 + patch

# usrmerge
tags 992116 + patch

# both patches are in salsa MRs

Bug#992113: release-notes: Initial availability of Bazel build system in Debian

[Richard Lewis]

On Wed, 11 Aug 2021 15:28:12 -0400 Olek Wojnar  wrote:

> If possible, please include the following in section 2.2 (What's new in the
> distribution?) of the release notes for the following architectures:
> amd64, arm64, ppc64el, s390x, ppc64, riscv64

Is this perhaps an old bug that should be closed - bullseye seems to
have a bazel-bootstrap package, so not sure there is anything needed
for bookworm?

> 2.2.x Initial availability of the Bazel build system
> The [Bazel](https://bazel.build/) build system is available in Debian 
> starting with this release. This is a bootstrap variant that will not include 
> local versions of the extended Bazel ecosystem. However, the current package 
> **does** provide identical functionality to core upstream Bazel, with the 
> advantage of convenient Debian package management for the installation. While 
> building Debian packages is not currently recommended, any software that 
> supports Bazel builds should build normally using this Debian-native Bazel 
> package. This includes build-time downloads of required dependencies.
>
> The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working 
> to package an extensible version of Bazel for future Debian releases. This 
> extensible version will allow additional components of the Bazel ecosystem to 
> be included as native Debian packages. More importantly, this version will 
> allow Debian packages to be built using Bazel. Contributions to the team are 
> welcome!

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[Cyril Brulebois]

Hi,

James Addison  (2023-05-01):
> Source: preseed
> Followup-For: Bug #1031643
> X-Debbugs-Cc: car...@debian.org, a...@debian.org, 
> freyerm...@physik.uni-bonn.de
> 
> Hi folks,
> 
> This is nitpicky, but I think there is an important-ish further detail
> to report.

Thanks for following up on the bug report, definitely an improvement
over the MR, but I meant it when I said filing a bug report would be
best. The root cause is the same, that's a *different* issue though.

> Suggestions:
[…]
> This was found following some related documentation discussion[4] on
> Salsa.  In that discussion, Martin Samuelsson suggests a fix that I
> think should work:
> 
> We should (un)set the d-i system's hostname to the 'empty' hostname
> early in the installer session.
> 
> That could happen in env2debconf -- or it could be placed even earlier
> in the installer scripts (since it's only relatively recently that
> Linux 6.0 began reading a hostname, we should be confident that d-i
> works OK without one configured).
> 
> I'm doing some testing to confirm the fix currently.

At this stage, I'd rather consider for a minimal-impact fix, that is
unsetting only when it matches the particular setting that's been
documented since at least 2004 via svn r21378 (unassigned-hostname).


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


signature.asc
Description: PGP signature

Bug#1030040: release-notes: usrmerge and dist-upgrade

[Richard Lewis]

control: tags -1 + patch

(In case of duplication, just wanted to ensure the BTS had a link to
this MR (which covers this and the other bug about usrmerge):

 https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/155

Bug#1034248: release-notes: Document that GTK4 apps are not accessible with screen reader

[Richard Lewis]

On Thu, 27 Apr 2023 22:19:53 +0200 Holger Wansing  wrote:
> Hi Paul,
>
> Paul Gevers  wrote (Thu, 27 Apr 2023 22:10:16 +0200):
> >
> > + If you depend on a screen reader and want to upgrade to ,
> > we suggest
> > + that you install a desktop like MATE instead of GNOME.
> >
> > I guess our recommendation also holds for new installs. So maybe leave
> > out the "and want to upgrade to bookworm" part?

I think this should be very high up - first  in the file,
rather than at the end - seems like this is going
to be a really big issue for some people.

Perhaps at least tell them how to switch to mate (eg: what package to
install - is it mate-desktop or is mate-desktop-environment needed for
accessibility - i assume the latter is better?)

And can we clarify "much less accessible" mean - doesnt work at all or
something less worrying? (i couldnt find anything
aimed at users on this)

also - is a switch to mate rally all that is needed - would you not
also need to switch away from every
GTK4 app as well?, or do apps under mate revert to GTK3 again?
Especially i would want to know: does Orca work under Mate? do any
settings copy across?
 (i found a page on debian's wiki but it's not very illuminating -
hopefully because it all just works!)

Is it all screen readers (2nd para) or just orca?

Some minor word changes and markup suggestions:
(I wasnt sure if i have described GTK3/4 right - is it better to say
version 4 of GTK for example?)

  
   GNOME has reduced accessibility support for screen readers
  
Many GNOME apps have switched from the
GTK3 graphics toolkit to GTK4.
Sadly, this has made many apps much less usable with screen
readers such as Orca.
  
  
If you depend on a screen reader you should consider switching to
a different desktop such as
https://mate-desktop.org;>Mate, which has
better accessibility support. 
You can do this by installing the mate-desktop-environment package. 
Information about how to use Orca under
Mate is available at https://wiki.debian.org/Accessibility/Orca#MATE;>here.
  
 

Ideally someone who is affected by this would comment too - im sure
there are lots of questions that wouldnt occur to me that should be
included here.

Bug#1035305: Re: Bug#1035305: Bugs on Debian 12 RC2

[pham...@bluewin.ch]

Hello Cyril,
Apart from what I quoted to you, the installer works correctly.
However, there is another major bug (excluding installation) that I noticed, 
the command lines below do not work with this RC2, they generate a whole series 
of errors:
add-apt-repository "deb https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu 
lunar main" && apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
0AB215679C571D1C8325275B9BDB3D89CE49EC21 && apt update && apt install firefox -y
add-apt-repository "deb https://ppa.launchpad.net/vincent-vandevyvre/vvv/ubuntu 
lunar main" && apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
7CAA00CD3DCA73E24812D646A5ADEEFF89F92A1A && apt update && apt install qarte -y
I would have been delighted if progress had been made on the other points I 
raised (WPA3 support and boot files installing on the /boot/efi partition of 
Windows and not Debian). But reading you I'm afraid it won't happen in Debian 
12, which I deeply regret ;-(
I am also very surprised that the Nvidia drivers have not been integrated into 
this RC2. This greatly limits the possibility of migrating to this RC2 to 
perform more in-depth tests with machines with only one Nvidia card available.
Best regards and good continuation to you.
This message has been translated from French to English via google translate.
Philippe
Message d'origine
De : k...@debian.org
Date : 30/04/2023 - 16:59 (E)
À : 1035...@bugs.debian.org
Cc : pham...@bluewin.ch
Objet : Re: Bug#1035305: Bugs on Debian 12 RC2
Control: retitle -1 Bugs on Debian 12 RC2
Control: submitter -1 pham...@bluewin.ch
Hi Philippe,
pham...@bluewin.ch 
 (2023-04-29):
> Configure network: [ X]
> 
> - WAP3 support from the installer is required. My Laptop (Dell XPS
> 9520) does not have an RJ-45 connection, it only has Wifi available
> like many machines today. My router is configured in WAP3 only... This
> complicates things a lot during installation.
To reiterate my answer from debian-boot@ earlier[1], we don't support
WPA3 in the installer yet (now tracked via #1035306[2]). Be it within the
installer or outside it, a custom workaround when native connectivity
isn't working (for whatever reason) is using an USB-to-Ethernet adapter.
  1. https://lists.debian.org/debian-boot/2023/04/msg00351.html
  2. https://bugs.debian.org/1035306
> - The problem to solve which is present in all intermediate versions
> of Debian is related to sources.list. It lacks the following
> information :
> 
> # Bookworm base repository
> deb https://deb.debian.org/debian bookworm main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm main non-free-firmware
> #
> # Bookworm-updates
> deb https://deb.debian.org/debian bookworm-updates main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm-updates main non-free-firmware
> # 
> # Security updates
> deb https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> deb-src https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> #
> # Proposed-updates (versions intermédiaires)
> # deb https://deb.debian.org/debian bookworm-proposed-updates main contrib 
> non-free-firmware
> # deb-src https://deb.debian.org/debian bookworm-proposed-updates main 
> contrib non-free-firmware
I suspect this is a “just” a side-effect of having no network in the
installer (lack of WPA3 and no alternative connectivity); the problem I
was alluding to earlier was the absence of bookworm-updates specifically
(fixed in RC 2), and that's indeed a separate topic.
> - Under Cinnamon if I deactivate the Wifi network via the taskbar, at
> the next boot it is automatically reactivated (installation on an
> external hard drive for testing). After an installation on the
> internal ssd of my laptop, the problem no longer occurs !?
I'll let others comment here, this seems weird to me.
> Install boot loader: [ X]
Dual-/multi-booting isn't my area.
> Overall install: [X ]
> 
> - After testing RC2 on my workstation, I have problems installing
> Nvidia graphics drivers for my RTX 3080. Nvidia detect does not seem
> to be present and Nvidia-drivers refuses to install, it only shows the
> available version n c isn't the right one ??
> 
> - The 'reboot' command does not work in simple user, only in root ;-(
Those are definitely not installer-related topics; the former should
probably be a bug report against one of the nvidia package; the latter
isn't a bug.
Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Rainer Dorsch]

Hi Steve,

many thanks for applying the patch. I reenabled the splash screen in digikamrc 
and it seems to crash at the same location again:

rd@h370:~$ apt-cache policy digikam
digikam:
  Installed: 4:7.9.0-2
  Candidate: 4:7.9.0-2
  Version table:
 *** 4:7.9.0-2 100
100 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 4:7.9.0-1+b2 500
500 http://ftp-stud.hs-esslingen.de/debian bookworm/main amd64 
Packages
rd@h370:~$ digikam 
digikam.facedb: Cannot found faces engine model "shapepredictor.dat"
digikam.facedb: Faces recognition feature cannot be used!
digikam.facedb: Cannot found faces engine DNN model 
"openface_nn4.small2.v1.t7"
digikam.facedb: Faces recognition feature cannot be used!
kf.xmlgui: Unhandled container to remove :  Digikam::DigikamApp
ASSERT: "!isEmpty()" in file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, 
line 363
21 -- exe=/usr/bin/digikam
13 -- platform=xcb
11 -- display=:0
16 -- appname=digikam
17 -- apppath=/usr/bin
9 -- signal=6
12 -- pid=1073797
17 -- appversion=7.9.0
20 -- programname=digiKam
31 -- bugaddress=sub...@bugs.kde.org
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = digikam path = /usr/bin pid = 1073797
KCrash: Arguments: /usr/bin/digikam 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi

[2]+  Stopped digikam
rd@h370:~$

I will create a trace and append it to the upstream bugreport:

https://bugs.kde.org/show_bug.cgi?id=466170

Thanks again
Rainer

Am Montag, 1. Mai 2023, 08:21:12 CEST schrieb Steve Robbins:
> I’ve just uploaded new version with upstream patch for the splash screen. 
> Would love to know I how it works on your system.
> 
> Sent from my iPhone
> 
> > On Apr 26, 2023, at 8:24 AM, Steve Robbins  wrote:
> > 
> > I understood that upstream fixed a splash screen bug from your traces.  I
> > do plan to look into applying that patch.
> > 
> > But I thought that even after disabling the splash screen you were seeing
> > a second crash?  That is what I’m trying to figure out.
> > 
> > Sent from my iPhone
> > 
> >>> On Apr 26, 2023, at 1:24 AM, Rainer Dorsch  wrote:
> >> 
> >> Hi Steve,
> >> 
> >> Am Mittwoch, 26. April 2023, 05:49:03 CEST schrieben Sie:
> >> > On Tuesday, April 25, 2023 12:50:39 P.M. CDT Rainer Dorsch wrote:
> >> > > Am Dienstag, 25. April 2023, 03:51:44 CEST schrieben Sie:
> >> > > > I'd be interested to know if the issue persists on your system
> >> > > > after
> >> > > > upgrading.
> >> > > 
> >> > > Yes, it repros always.
> >> > 
> >> > OK.
> >> > 
> >> > > -- System Information:
> >> > > Debian Release: 12.0
> >> > > 
> >> > >   APT prefers testing-security
> >> > >   APT policy: (500, 'testing-security'), (500, 'testing-debug'),
> >> > >   (105,
> >> > > 
> >> > > 'testing')
> >> > > Architecture: amd64 (x86_64)
> >> > > Foreign Architectures: i386
> >> > > 
> >> > > Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT)
> >> > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> >> > > LANGUAGE=de:en_US
> >> > 
> >> > I'm still not able to reproduce the issue.  Today I was trying with the
> >> > same locale as you (de_DE.UTF-8).   I have seen issues in the past
> >> > with certain locales -- typically in software that isn't careful
> >> > enough and gets into trouble when a locale switches the period and
> >> > comma in number formats.>> 
> >> Be aware that upstream also was unable to repro the issue and finally
> >> they managed to understand and fix the problem by the traces I was able
> >> to generated.>> 
> >> > Even though I wasn't able to reproduce the problem here, it would be
> >> 
> >> > interesting if you can try with locale set to en_US for example:
> >> There is no change if I unset LANG:
> >> 
> >> rd@h370:~/tmp.nobackup$ unset LANG
> >> rd@h370:~/tmp.nobackup$ digikam
> >> digikam.facedb: Cannot found faces engine model "shapepredictor.dat"
> >> digikam.facedb: Faces recognition feature cannot be used!
> >> digikam.facedb: Cannot found faces engine DNN model
> >> "openface_nn4.small2.v1.t7" digikam.facedb: Faces recognition feature
> >> cannot be used!
> >> kf.xmlgui: Unhandled container to remove :  Digikam::DigikamApp
> >> ASSERT: "!isEmpty()" in file
> >> /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 363 21 --
> >> exe=/usr/bin/digikam
> >> 13 -- platform=xcb
> >> 11 -- display=:0
> >> 16 -- appname=digikam
> >> 17 -- apppath=/usr/bin
> >> 9 -- signal=6
> >> 11 -- pid=459194
> >> 17 -- appversion=7.9.0
> >> 20 -- programname=digiKam
> >> 31 -- bugaddress=sub...@bugs.kde.org
> >> KCrash: crashing... crashRecursionCounter = 2
> >> KCrash: Application Name = digikam path = /usr/bin pid = 459194
> >> KCrash: Arguments: /usr/bin/digikam
> >> KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
> >> 
> >> [1]+  Stopped digikam
> >> rd@h370:~/tmp.nobackup$
> >> 
> >> > I have no idea where else to look.  Given that no-one else has reported
> 

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[James Addison]

Source: preseed
Followup-For: Bug #1031643
X-Debbugs-Cc: car...@debian.org, a...@debian.org, freyerm...@physik.uni-bonn.de

Hi folks,

This is nitpicky, but I think there is an important-ish further detail to
report.

The fix applied does repopulate the 'hostname' variable so that env2debconf can
read from it and place it into the 'netcfg/get_hostname'[1] preseed variable; so
far, so good.


However: the hostname in the running Debian installer masks the intended
behaviour of 'netcfg/get_hostname', because netcfg's DHCP logic prefers[2]
to read the running system's hostname, when it is non-empty.

I've confirmed this behaviour by netbooting from the Bookworm RC 2 installer;
DHCP configuration of a hostname is ignored when the command-line hostname is
present.

(note: a similar setting, 'netcfg/hostname' is available that takes precedence
over DHCP[2] hostname values, but it's a separate setting, and is not our
documented[3] behaviour of the 'hostname' preseed alias)


Suggestions:

This was found following some related documentation discussion[4] on Salsa.  In
that discussion, Martin Samuelsson suggests a fix that I think should work:

We should (un)set the d-i system's hostname to the 'empty' hostname early in
the installer session.

That could happen in env2debconf -- or it could be placed even earlier in the
installer scripts (since it's only relatively recently that Linux 6.0 began
reading a hostname, we should be confident that d-i works OK without one
configured).

I'm doing some testing to confirm the fix currently.

Thanks,
James

[1] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578

[2] - 
https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160

[3] - 
https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases

[4] - 
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25

Bug#1028149: bookworm: ntp has been replaced by ntpsec

[Richard Lewis]

control: tags -1 + patch
thanks

> On Sat, Apr 15, 2023 at 04:31:45PM +0100, Richard Lewis wrote:

> > if no-one else does,  i can draft some text that says
> > - ntp is dropped (do we know why?).
>
> I think the main reason is very slow upstream development with a large
> number of known unfixed security issues.
>
> > ntpsec is a direct replacement,
> > but there is also chrony
>
> openntpd is another NTP client that I think should be recommended.
> (Not as a server though.)

proposed text is at
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/156
(i included openntpd as an alternative but didn't try and explain the
differences - didn't think it was easy to do so clearly!)

Bug#1035343: racket: Consider using CS on all architectures

[Philip McGrath]

Package: racket
Version: 8.7+dfsg1-1
Severity: normal

Dear Maintainer,

Since at least Racket 8.6, the Racket CS implementation runs even on 
architectures for which it cannot generate native code. I suggest that the 
Debian should package Racket CS for all architectures instead of falling back 
to Racket BC for some, e.g. ppc64el.

I don't fully understand the nuances of the bookworm freeze policy. (I'm sorry 
I didn't report this sooner.) It seems at least plausible that this could be a 
"small, targeted fix[]", especially from the perspective that it would amount 
to bringing a few niche architectures to parity with the popular ones, but I 
could also understand an argument to the contrary.

Some background: Racket CS (based on "Chez Scheme") is the current default 
implementation, having replaced Racket BC ("Before Chez" or "ByteCode") with 
the release of Racket 8.0. Racket CS, like Chez Scheme, compiles to machine 
code, whereas Racket BC compiles to platform-independent bytecode. Initially, 
the recommendation from upstream was to fall back to Racket BC on 
architectures which Racket CS didn't support: Debian's packaging did so as of 
8.0+dfsg1-2 and 8.0+dfsg1-3.

However, Racket CS is now able to run even on architectures for which it 
cannot generate machine code. Initially, support for a "portable bytecode" 
backend was added to Racket's variant of Chez Scheme to simplify bootstrapping 
during development. Later, variants specialized to word size and endianness 
were added (e.g. "tpb64l", suitable for any 64-bit little-endian machine), as 
was basic support for chunks of this byte code to C (which was useful for Chez 
"boot files"). These improvements are sometimes referred to as "pbarch" and 
"pbchunk", respectively.

Ultimately, this worked well enough to make Racket CS viable on architectures 
without native compilation support. Performance is reportedly comparable to 
Racket BC on those architectures, which never had JIT support on Racket BC. 
Changing to Racket CS also enables Racket's "futures" and "places" for those 
architectures. Perhaps the most significant benefit, albeit less concrete, is 
getting those niche architectures onto the Racket implementation that is 
actively developed and used.

The new support was announced with the Racket 8.5 release, but a few pieces 
turned out to be missing: there's some discussion at [1]. I maintain the Guix 
package of Racket, and we enabled Racket CS on all architectures starting with 
Racket 8.6, in particular in [2] and [3]. (Our patches were complicated by the 
fact that we expose some of Racket's internals in ways Debian doesn't.)

I'd be glad to help with this as I can, with the caveats that I have very 
little time until next week, don't have any relevant hardware, and have only 
the tiniest amount of experience with Debian packaging (though I'm a long-time 
user of Debian and downstreams).

Thanks for maintaining Racket in Debian!
Philip McGrath

[1]: https://racket.discourse.group/t/950/27
[2]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a15d72f
[3]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ed24d6b


signature.asc
Description: This is a digitally signed message part.

Bug#992345:

[Richard Lewis]

control: tags + patch
thanks

This one, on free space needed is hopefully addressed by
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/159

Bug#992116: release-notes: Add breakage from merged-/usr-via-aliased-dirs

[Richard Lewis]

control: tags + patch
thanks

Think this is covered by
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/155

Bug#1035342: binutils: Native binutils-TUPLE provides tool names that cross binutils-TUPLE does not

[Simon McVittie]

Source: binutils
Version: 2.40-2
Severity: normal

binutils-x86-64-linux-gnu can be compiled as a native binutils to be run on
amd64 and emit amd64 binaries, or as a cross-binutils to be run on some
other architecture like for example ppc64el (and still emit amd64 binaries).

The native binutils-x86-64-linux-gnu:amd64 contains symlinks
/usr/bin/x86_64-linux-gnu-gold -> x86_64-linux-gnu-ld.gold for the gold
linker, and
/usr/bin/x86_64-linux-gnu-ld -> x86_64-linux-gnu-ld.bfd for the traditional
BFD linker, together with their man pages.

The cross packages like binutils-x86-64-linux-gnu:ppc64el contain
/usr/bin/x86_64-linux-gnu-ld -> x86_64-linux-gnu-ld.bfd, but do not have
/usr/bin/x86_64-linux-gnu-gold -> x86_64-linux-gnu-ld.gold.

This seems inconsistent: I would have expected that binutils-TUPLE would
either always provide TUPLE-gold, or never provide TUPLE-gold.

Similarly, binutils-x86-64-linux-gnu:amd64 provides TUPLE-gp-archive (and
other gp- tools) and TUPLE-gprofng, but binutils-x86-64-linux-gnu:ppc64el
doesn't provide those.

(All of this seems to be equally true for architectures other than
x86_64-linux-gnu, that's just an example.)

smcv

Bug#1033675: release-notes: apt-key improves system security with 3rd party sources

[Richard Lewis]

On Wed, 29 Mar 2023 22:58:35 +0200 Rainer Dorsch  wrote:

> according to
> https://linuxnews.de/2021/04/10/debian-11-repositories-aus-3-hand-ohne-apt-key-einbinden/
> Debian 12 supports and requires a safer way to import keys for 3rd
> party repos. If that is the case, I suggest to add this to the release notes, 
> since it is a nice security enhancement feature.

hi this sounds interesting - i can help develop some text, but you
will need me more info on what the new feature is: the webpage
you link to is in german, but the title says debian 11, and the first
links is to a wiki page giving instructions for 'stretch or later'.
The bit about writing
'signed-by' in sources.list has been available since, i think, buster

so is there actually a new feature for debian 12?

Bug#958218: update-grub fails to process more than one argument to initrd

[Krzmbrzl]

Hi everyone,

In this report, there seems to be an indication that this issue was 
fixed with grub2/2.04-5. At least that's how I interpret the 
auto-generated line "No longer marked as found in versions grub2/2.04-5" 
that was somehow triggered by Colin Watson (though when checking the 
respective mail, it seems like that is only about reassignment and not 
about a resolution).


In either case, I want to report that this issue still exists when 
having grub2-common/2.06 installed (on Ubuntu 22.04), which comes with 
os-prober/1.79.


Furthermore, I can explain exactly where this issue occurs. I have 
written up a question on the Unix StackExchange about this, that 
contains the explanation: https://unix.stackexchange.com/q/744624/203826


The gist of it is that the script that parses the grub.cfg on the 
separate Arch (in my case Manjaro) partition, the initrd statement is 
parsed as expected, but the code only handles the first argument to the 
initrd command, which in Arch's case is the microcode stuff, while 
completely ignoring any subsequent arguments.


Where can I hand in a patch to fix this issue?

Bug#1034479: [pre-approval] unblock: rocprim/5.3.3-4

[Christian Kastner]

Control: tags -1 - moreinfo

On 2023-04-26 07:46, Paul Gevers wrote:
> Ack. I'm uncomfortable with the changes in -3, in particular the
> arch:any -> arch:all and associated lib -> shared move. I propose you
> upload a version -4 which reverts -3 for now and only adds the missing
> dependency. experimental and later trixie is there to take the current
> changes.
> 
> Please remove the moreinfo tag once the package is in unstable.

Bug#1035341: libvdk2-dev: Please add a .pc file

[Nilesh Patra]

Package: libvdk2-dev
Version: 2.4.0-5.6
Severity: normal
Tags: patch
Forwarded: https://sourceforge.net/p/vdkbuilder/bugs/20/
X-Debbugs-Cc: m...@debian.org

Dear Michael,

At the moment vdk2 does not vendor a .pc file and instead managed lib
and cflag info via a vdk-config-2 file. This is broken for cross-build
use as it has pkg-config invocations without triplet and hence this
causes cross-build issues.

Simple solution is to use a pkg-config file for getting all necessary
cflags and libs, which also improves the build experience for everyone.
Upstream is inactive for around a decade and so it'd be nice if this
could be taken up in the debian package (the change is in no way large
or disruptive).

I've attached a patch to get the .pc file installed with libvdk2-dev,
please consider applying.

Best,
Nilesh

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvdk2-dev depends on:
ii  libgtk2.0-dev  2.24.33-2
ii  libvdk2-2c22.4.0-5.6

libvdk2-dev recommends no packages.

Versions of packages libvdk2-dev suggests:
pn  doxygen  
pn  libvdk2-doc  

-- no debconf information
>From ec8f2dd20a1942d75fc61b2ec0a3ecb7d227a8c5 Mon Sep 17 00:00:00 2001
From: Nilesh Patra 
Date: Mon, 1 May 2023 11:46:05 +
Subject: [PATCH] Add .pc file to the package for better cross-build support

---
 debian/libvdk2-dev.dirs |  1 +
 debian/libvdk2.pc   | 13 +
 debian/rules|  1 +
 3 files changed, 15 insertions(+)
 create mode 100644 debian/libvdk2.pc

diff --git a/debian/libvdk2-dev.dirs b/debian/libvdk2-dev.dirs
index e772481..f7412ea 100644
--- a/debian/libvdk2-dev.dirs
+++ b/debian/libvdk2-dev.dirs
@@ -1 +1,2 @@
 usr/bin
+usr/lib/pkgconfig
diff --git a/debian/libvdk2.pc b/debian/libvdk2.pc
new file mode 100644
index 000..8aabae1
--- /dev/null
+++ b/debian/libvdk2.pc
@@ -0,0 +1,13 @@
+prefix=/usr
+exec_prefix=${prefix}
+libdir=${prefix}/lib/
+includedir=${prefix}/include
+pkglibdir=${libdir}/vdk
+
+Name: libvdk2
+Description: Visual Development Kit C++ library version 2
+Requires: gtk+-x11-2.0 gtk+-x11-2.0
+Version: 2.4.0
+Libs: -L${libdir} -lvdk2 -lpthread
+Libs.private: -lpthread
+Cflags: -I${includedir}/vdk2
diff --git a/debian/rules b/debian/rules
index b995da7..5b27888 100755
--- a/debian/rules
+++ b/debian/rules
@@ -138,6 +138,7 @@ libvdk2-dev: build
# Add here commands to install the files from debian/libvdk2-2c2
dh_movefiles -plibvdk2-dev --sourcedir=debian/libvdk2-2c2
cp vdk-config-2 debian/libvdk2-dev/usr/bin
+   cp debian/libvdk2.pc debian/libvdk2-dev/usr/lib/pkgconfig
 
# start copying the examples 
# here we do something not very clean, but it is working
-- 
2.40.0

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Pascal Hambourg]

On Sun, 30 Apr 2023 17:37:13 -0700 Vagrant Cascadian 
 wrote:

On 2023-05-01, Steve McIntyre wrote:

From there, I'd love to see what you get if you run "ls" here...


"ls" from the grub prompt did not show the other disk...
...until I made the second disk bootable from libvirt!
Then grub now sees both disks, and boots fine!
So this is possibly a quirk of the way libvirt exposes boot disks.


Apparently. GRUB can only see disks exposed by the BIOS/UEFI/other 
platform firmware. There are other known situations where a given 
firmware may not expose some disks, including but not limited to:

- disks connected to a SATA controller card without a BIOS expansion ROM
- unsupported media types: USB other than the boot disk, NVMe, SD/MMC...

The UEFI firmware on an old Intel board only had EFI drivers for the 
SATA controller in IDE mode and lacked EFI drivers for AHCI and USB. It 
has been reported that more recent boards had support for NVMe only in 
EFI mode, not in legacy mode.



I ran d-i in rescue mode to get into the system, simply ran
dpkg-reconfigure grub-pc (which will run grub-install *and*
update-grub), and the system now boots again. It looks like what we're
seeing might be a limit in what's built in to the core image by
default. grub-pc is deliberately designed to build minimal images
here, to minimise the chance of the image being too large to embed.


I wonder how much this policy is still relevant for PC platforms. 
Originally the core image was designed to fit in the "post-MBR gap" 
whose typical size was 62 sectors (31 KiB) because the first partition 
used to start at sector 63. But nowadays a 1-MiB post-MBR gap has been 
the standard for many years. I do not remember when this was introduced 
in fdisk and other Linux partition editors, but Windows 7 installer had 
it. Besides, I observe that the size of the core.img built for LVM+ext4 
on my bullseye system is 34 KiB so it would not even fit in a 31-KiB 
post-MBR gap.


The minimal core image policy is even less relevant for EFI images, as 
the EFI partition size is usually several MB so a few more kB won't 
hurt. I cannot tell for other platforms.


I think that when building the i386-pc core image with support for 
storage possibly involving multiple disks (LVM, RAID, btrfs), support 
for at least both MSDOS and GPT partition schemes (other partition 
schemes are unlikely to be used on PC) could be added unconditionally to 
prevent such GRUB failure after adding a disk with a different partition 
scheme to the /boot filesystem. It would add only 2 KB to the core 
image, and it is likely that the minimal size is already above 31-KiB 
anyway when the above storage drivers are embedded. Opinions ?



Re-running grub-install /dev/vda from debian-installer rescue mode did
*not* fix the issue for me


Because there were two issues preventing GRUB from seeing the new PV:
- the disk was not exposed by libvirt BIOS
- the disk had an unsupported GPT partition scheme

grub-install fixed only the second issue. Making the disk "bootable" in 
libvirt was required to fix the first issue.



(though, now I am curious if dpkg-reconfigure
grub-pc would do anything more?)


As Steve wrote, dpkg-reconfigure also runs update-grub to rebuild 
grub.cfg. AFAIK here the only difference with the old grub.cfg is 
additional "insmod part_gpt" commands to load GPT support, but the 
module must already be embedded in the core image so this addition is 
not required.

Bug#995628: qemu-system-data: desktop file is incomplete, remove it?

[Michael Tokarev]

On Sun, 3 Oct 2021 13:50:11 +0200 Laurent Bonnaud  wrote:


Package: qemu-system-data
Version: 1:6.1+dfsg-6
Severity: normal


Dear Maintainer,

when I start a KDE program I see the following error messages:

kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has 
Type= "Application" but no Exec line
kf.service.sycoca: Invalid Service :  "/usr/share/applications/qemu.desktop"

The qemu.desktop file lacks a shell command, indeed.

In fact I do not see what command could be added there.  Qemu needs at least 
some options to do something useful.  The best solution would perhaps be to 
remove the qemu.desktop completely.


This turned out to be wrong. The .desktop file is needed for wayland-based
desktop environments to associate an icon name with a running application.
Without the .desktop file, some default "unknown" icon is used in the app
switcher and the like.  So .desktop file is here to stay.

/mjt

Bug#1035310: bullseye-pu: package xz-utils/5.2.11-0~deb11u1

[Helge Kreutzmann]

Hello Sebastian,
On Sun, Apr 30, 2023 at 10:17:07PM +0200, Sebastian Andrzej Siewior wrote:
> On 2023-04-30 18:43:18 [+0200], Helge Kreutzmann wrote:
> > > - the backport package of manpages-de and manpages-fr provides a
> > >   man page for xz. These files conflict with the one provided by
> > >   xz-utils package. The bpo package and xz-utils in Bookworm have proper
> > >   Breaks: and Replaces: relation to allow smooth upgrades.
> > >   This update of xz does not provide such a relation since the current
> > >   version of manpages-{de|fr} in Bullseye does not provide this
> > >   man page. As per testing, the Breaks: in manpages-{de|fr} forbids
> > >   installing of this xz-utils. My understanding is that once these
> > >   man pages are visible in Bullseye via xz-utils, the bpo packages of
> > >   manpages-l10n stops creating them as part of the build process. They
> > >   are not present in testing/ Bookworm version of the package.
> > 
> > No, we need to coordinate about this. You previously considered doing
> > a backport and I asked you several if this is still the case; since
> > you did not respond, I did not remove the conflicting pages in my
> > bullseye packport. 
> 
> I added you to Cc: for reason of coordination. I always intended to do
> -pu instead of a bpo. I intended to respond earlier but didn't manage to
> do it until now. Sorry for that.

Thanks for adding me and we are all overloaded some times. 

> > As bookworm is about to release, I just wonder if that is really
> > necessary to introduce the translation files in your backport. I'm all
> > about translations, but this is a bit fragile with two backports with
> > all the upgrade paths. So hopefully we get this right.
> 
> Stable Bullseye, no bpo.

I don't know if this ease the situation regarding the required package
relationship.

From my side this is just a few lines in my rules file and the
appropriate package relationships, the latter are the tricky part to
get right.

> > If you still feel this is necessary for your users, then please
> > contact me and I can perform another upload with the file removed and
> > appropriate package relationships. (This implies you tell me the
> > version which introduces the files.)
> 
> I'm waiting for the stable team to confirm or deny my request. Once that
> is clear we can see how to move forward.

Ok.

> > Please tell me as well which translated man pages you ship, as there
> > are also Danish and Ukrainian ones in my backports.
> > 
> > Please not that I will not perform uploads to bullseye once bookworm
> > has been released.
> 
> Only DE and FR made it into the 5.2 series.

So we need to deal with those two "only".

Thus I'm waiting for further information from your side. 

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#725316: localepurge: debconf question points to documentation not yet installed: README.dpkg-path

[Diederik de Haas]

Package: localepurge
Version: 0.7.3.10
Followup-For: Bug #725316

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I ran into this issue on an initial install.
The contents of the file is quite good and it would've explained to me
why installing localepurge didn't purge any not-needed locales.

I added that experience to bug #780889, which provided a workaround
which entails running `dpkg-reconfigure localepurge` and *then* the file
was available and then I learned why localepurge didn't purge any
locales, while the package description and the deb-wiki page suggested
that it would do exactly that.

I do think the dpkg-path solution is great and maybe should be included
in the (normal) `locales` package? As I said in the other bug report, I
think installing 700+ MB of locale files *which I don't need* is a bit
excessive.

- -- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  locales2.36-9
ii  perl   5.36.0-7
ii  procps 2:4.0.3-1
ii  ucf3.0043+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
pn  bleachbit  
pn  debfoster  
pn  deborphan  

- -- debconf information:
* localepurge/use-dpkg-feature: true
  localepurge/verbose: false
  localepurge/quickndirtycalc: false
* localepurge/mandelete: true
  localepurge/remove_no:
  localepurge/dontbothernew: true
* localepurge/none_selected: true
* localepurge/nopurge: en, en_US.UTF-8, nl, nl_NL.UTF-8
  localepurge/showfreedspace: true

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZE+d/wAKCRDXblvOeH7b
bmUwAP4obvkurumTbXtcV6CHBhEnacJ6tIca7mEcW0qv0InG/AEAqdFE18HqGEtm
qP2Rwqit6DFkIVvMniHmoF5yoy3oFgs=
=teNv
-END PGP SIGNATURE-

Bug#929458: RFP: trivy -- A Simple and Comprehensive Vulnerability Scanner for Containers, Suitable for CI

[Damian Szuberski]

Hello,

Unfortunately, there are quite a few dependencies that haven't been
packaged yet.




































*dh-make-golang github.com/aquasecurity/trivy
...2023/05/01 10:55:44
Build-Dependency "github.com/google/licenseclassifier
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/masahiro331/go-ext4-filesystem
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/magefile/mage " is not yet
available in Debian, or has not yet been converted to use XS-Go-Import-Path
in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/masahiro331/go-disk " is
not yet available in Debian, or has not yet been converted to use
XS-Go-Import-Path in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/masahiro331/go-vmdk-parser
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/masahiro331/go-xfs-filesystem
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/CycloneDX/cyclonedx-go
" is not yet available in Debian,
or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency "k8s.io/api
" is not yet available in Debian, or has not yet been
converted to use XS-Go-Import-Path in debian/control2023/05/01 10:55:44
Build-Dependency "modernc.org/sqlite " is not
yet available in Debian, or has not yet been converted to use
XS-Go-Import-Path in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/spdx/tools-golang " is not
yet available in Debian, or has not yet been converted to use
XS-Go-Import-Path in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/aquasecurity/defsec " is
not yet available in Debian, or has not yet been converted to use
XS-Go-Import-Path in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/in-toto/in-toto-golang
" is not yet available in Debian,
or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency "github.com/samber/lo
" is not yet available in Debian, or has not
yet been converted to use XS-Go-Import-Path in debian/control2023/05/01
10:55:44 Build-Dependency "github.com/aquasecurity/go-npm-version
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/sigstore/rekor " is not yet
available in Debian, or has not yet been converted to use XS-Go-Import-Path
in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/moby/buildkit " is not yet
available in Debian, or has not yet been converted to use XS-Go-Import-Path
in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/aquasecurity/trivy-kubernetes
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/owenrumney/go-sarif " is
not yet available in Debian, or has not yet been converted to use
XS-Go-Import-Path in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/package-url/packageurl-go
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/sosedoff/gitkit " is not yet
available in Debian, or has not yet been converted to use XS-Go-Import-Path
in debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/aquasecurity/go-gem-version
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency
"github.com/aquasecurity/bolt-fixtures
" is not yet available in
Debian, or has not yet been converted to use XS-Go-Import-Path in
debian/control2023/05/01 10:55:44 Build-Dependency

Bug#780889: localepurge: does nothing if path-exclude is enabled

[Diederik de Haas]

Package: localepurge
Version: 0.7.3.10
Followup-For: Bug #780889
X-Debbugs-Cc: kilob...@angband.pl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I recently ran into this problem too.
I have 2 systems where `/usr/share/locale/` used 700+ MB, which I think
is rather excessive, so I installed localepurge to get rid of most of it
... only to find out it didn't do that.

I can also confirm that manually running `localepurge` did nothing
initially as IMO the logical configuration you'd do when installing the
package is to use path-exclude.

Thirdly I can confirm that the workaround works, but it's a bit
complicated and I did it wrong on 1 machine and thereby also removed the
locales for nl* and en*. As I normally run Testing or Sid, I expect
those to be restored when a package upgrade comes in.
People using Stable may not be so 'lucky'.

- -- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  locales2.36-9
ii  perl   5.36.0-7
ii  procps 2:4.0.3-1
ii  ucf3.0043+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
pn  bleachbit  
pn  debfoster  
pn  deborphan  

- -- debconf information:
* localepurge/none_selected: true
* localepurge/nopurge: en, en_US.UTF-8, nl, nl_NL.UTF-8
  localepurge/remove_no:
* localepurge/use-dpkg-feature: true
* localepurge/mandelete: true
  localepurge/dontbothernew: true
  localepurge/verbose: false
  localepurge/showfreedspace: true
  localepurge/quickndirtycalc: false

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZE+bRAAKCRDXblvOeH7b
bjrMAP9bxORProL77LrtvdrCFKKJvut7rZKlX26WKpfbXClY0gEAtHyPDweBgRDZ
QUV6mcEtf8dvgy3qm7g15bbo7IsHIwg=
=wvJm
-END PGP SIGNATURE-

Bug#1035340: latest openjdk-8-jdk version 8u372-b07 is not available

[pawan gupta]

package: openjdk-8-jdk

version: latest


When I invoke `apt-get update && apt-get install openjdk-8-jdk` it is
installing an older version of jdk-8 which is 8u362-b09.

Jdk version 8u372-b07 is not getting installed while running the `apt-get
install openjdk-8-jdk` even after running the `apt-get update` command.


It should always fetch the latest package available.


I an using ubuntu 22.04

Thanks,

Pawan

Bug#989632: dash: remove unnecessary diversion of /bin/sh

[Luca Boccassi]

On Mon, 1 May 2023 at 08:55, Helmut Grohne  wrote:
>
> Hi,
>
> On Mon, May 01, 2023 at 12:07:52AM +0100, Luca Boccassi wrote:
> > On Sat, 29 Apr 2023 16:32:23 +0100 Luca Boccassi 
> > wrote:
> > >
> > > MR: https://salsa.debian.org/debian/dash/-/merge_requests/19
> > >
> > > I think we should ship these changes in bookworm. Why?
> > >
> > > - we get diversion-less essential package set already in bookworm
> > > - we get diversion-less uber-essential dash already in bookworm
> > > - we get maintainer-script free uber-essential dash in trixie
> > > - in case we need to go down the canonicalization-by-dh forced
> > > migration path in trixie to lift the moratorium on moving files, we
> > > don't have /bin/sh diversions as a blocker and the path remains open
> > >
> > > Yes, I realize it is late, and I wish I had come across this ticket
> > > some months ago. But we still have time, and the benefits are great
> > :-)
> >
> > Alright, this is now in experimental (thanks Andrej), please help with
> > testing if you can!
>
> Let me record this in email:
>  * I am the primary author of these changes and still think we should
>perform them at a convenient time.
>  * As far as I understand it, the main motivation from Luca is improving
>the /usr-merge transition.
>  * Given that dash is one of the rare cases diverting files from itself
>rather than from other packages, I think that the benefit to the
>/usr-merge transition of doing this before bookworm is minor.
>Removing other kinds of unnecessary diversions would be more useful
>to the transition.
>  * I think these changes are not in line with the freeze policy.
>  * For these reasons, I recommend not trying to ship them in bookworm
>(despite removing unnecessary diversions being a good thing in
>general).
>  * Breakage can happen in unexpected places (e.g. DPKG_ROOT, which is
>the origin of my work on this).
>  * If you proceed in bookworm anyway, I expect you to own any kind of
>breakage that results from this (including DPKG_ROOT breakage).
>
> And with this, I'll leave it up to you until bookworm is released.

Actually my main motivation is that diversions in /usr are
fundamentally incompatible with the concept of a read-only /usr vendor
partition. As far as I can tell this is the only diversion that is
installed by default in the essential set, so I am very very keen on
seeing it gone. Having this change in bookworm means in trixie we can
be rid of it completely, and otherwise we'd have to wait yet another
full cycle. The fact that it also helps with the merge transition is
really icing on the cake.
Yes, I wish I had noticed and had time for this earlier, but if wishes
were horses etc etc.

To me it seems a fairly straightforward change, and it is in
experimental now for us to prove it otherwise, so I'd be really keen
in getting an unblock for bookworm for this. And yes I'm happy to help
if anything goes awry.

Kind regards,
Luca Boccassi

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[James Addison]

On Mon, 1 May 2023 at 03:00, Cyril Brulebois  wrote:
> Diederik de Haas  (2023-04-30):
> > I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
> > is its name in the upstream repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>
> Yes please.

Agreed.

I'm trying to figure out the reason that the kernel module requests
the verbose-style firmware filename (that include spaces) in the first
place.

In the case of the RPi B, the kernel source contains a device-tree
file for the brcm2711, the relevant hardware.

The 'compatible'[1] field of the brcm2711 device-tree structure file
includes the string "raspberrypi,4-model-b" -- matching one of the
files in linux-firmware.git's brcm directory -- but the 'model'[2]
field, containing "Raspberry Pi 4 Model B", could be the one that's
used when the firmware file request is issued when the module loads
(?).

Also, the brcmfmac kernel module code mentions[3] that it can load
board-specific firmware file paths.  I'm not yet sure whether that's
relevant (either now, or in future).

> Diederik de Haas  (2023-04-30):
> > And that's exactly what happens or will happen. Even though the RPi4 
> > filename
> > doesn't contain spaces, there are several in the `brcm` directory that do.
> > I didn't check other directories, but I'd expect that filenames with a 
> > space is
> > NOT an anomaly.

Since more files with that pattern are appearing upstream in
linux-firmware.. yes, slightly reluctantly it does seem that this will
be needed.

On Mon, 1 May 2023 at 03:00, Cyril Brulebois  wrote:
> We won't rewrite hw-detect for bookworm, nor will we make it “shellcheck
> compliant”. Now is definitely not the time to deal with such things, and
> yes I'm going to call system files (e.g. package-shipped) with spaces an
> anomaly.
>
> People are much than welcome to put energy into making hw-detect more
> robust in the future, but even knowing some bits about it, it's some
> kind of a maze and I *really* don't want to lose any feature for the
> generic cases (non-crazy filenames).

I'd generally agree with all that.  For robustness, and when it's safe
to, it'd be nice to resolve both issues (firstly to ensure that the
correct firmware filename is being requested in these cases -- maybe
it already is, I'm still trying to determine whether that's a bug --
and secondly to support spaces in firmware filenames in hw-detect).

[1] - 
https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L9

[2] - 
https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L10

[3] - 
https://elixir.bootlin.com/linux/v6.1/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L772

Bug#1035339: unblock: vice/3.7.1+dfsg1-1

[GCS]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:vice

Hi RMs,

[ Reason ]
Upstream source contains several ROM files for Commodore machines and
floppy drives, including printers. All these have a size of 2k and
multiples. A script under debian/ directory called mangle-source.sh
remove those. There's a printer ROM file which turned out to be an
exception to this size rule. Meaning this non-free file slipped to the
source tree and to the package itself.
This is filed as a serious bug [1] already. I've fixed it by removing
the file and updating the removal script.

[ Impact ]
It will make the package DFSG free and users can still have it in Bookworm.

[ Tests ]
This file is unused for package build and only needed if someone would
like to emulate the Commodore printer. That is, no extra tests are
required.

[ Risks ]
Nothing. The change is only a file removal, replace it with the text
'dummy' and a source repack shell script update.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Uploaded, built on all architectures and package is working.

unblock vice/3.7.1+dfsg1-1

Thanks for considering,
Laszlo/GCS
[1] https://bugs.debian.org/1035079
Binary files /tmp/Vc_Z6BwILs/vice-3.7.1+dfsg/data/PRINTER/mps803.bin and /tmp/e6SEihfSew/vice-3.7.1+dfsg1/data/PRINTER/mps803.bin differ
diff -Nru vice-3.7.1+dfsg/debian/changelog vice-3.7.1+dfsg1/debian/changelog
--- vice-3.7.1+dfsg/debian/changelog	2023-02-17 21:06:12.0 +0100
+++ vice-3.7.1+dfsg1/debian/changelog	2023-04-29 10:58:51.0 +0200
@@ -1,3 +1,9 @@
+vice (3.7.1+dfsg1-1) unstable; urgency=medium
+
+  * Remove mps803.bin printer ROM from source (closes: #1035079).
+
+ -- Laszlo Boszormenyi (GCS)   Sat, 29 Apr 2023 10:58:51 +0200
+
 vice (3.7.1+dfsg-2) unstable; urgency=medium
 
   * Clarify license of CBM.ttf (closes: #1029260).
diff -Nru vice-3.7.1+dfsg/debian/mangle-source.sh vice-3.7.1+dfsg1/debian/mangle-source.sh
--- vice-3.7.1+dfsg/debian/mangle-source.sh	2023-01-14 20:56:30.0 +0100
+++ vice-3.7.1+dfsg1/debian/mangle-source.sh	2023-04-29 10:58:51.0 +0200
@@ -24,6 +24,9 @@
   echo dummy > $FILE
 fi
   done
+  # non-standard size
+  rm data/PRINTER/mps803.bin
+  echo dummy > data/PRINTER/mps803.bin
   # replace non-free font
   echo replace font 1>&2
   rm data/common/C64_Pro_Mono-STYLE.ttf 1>&2

Bug#1032671: linux: Enable USB_XHCI_PCI_RENESAS on arm64

[Diederik de Haas]

Control: forwarded -1 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/675

On Monday, 1 May 2023 09:47:48 CEST Roger Shimizu wrote:
> Did you forget to enclose the patch?

It's here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/675

signature.asc
Description: This is a digitally signed message part.

Bug#1035338: please split off API client

[Simon Richter]

Package: docker.io
Version: 20.10.24+dfsg1-1+b2
Severity: wishlist
X-Debbugs-Cc: s...@debian.org

Hi,

I have several containers that are allowed to address the docker
instance they are running on to start additional containers, without
ever having a need to run the docker daemon themselves.

Since Docker has quite an extensive list of dependencies, it would be
nice if the client could be installed separately.

   Simon

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser3.132
ii  containerd 1.6.20~ds1-1+b1
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.36-9
ii  libdevmapper1.02.1 2:1.02.185-2
ii  libelogind0 [libsystemd0]  246.10-1debian1
ii  runc   1.1.5+ds1-1+b1
ii  sysvinit-utils [lsb-base]  3.06-4
ii  tini   0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 3.0.8-3
ii  ca-certificates  20230311
ii  cgroupfs-mount   1.4
ii  git  1:2.39.2-1.1
ii  needrestart  3.6-3
ii  xz-utils 5.4.1-0.2

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.47.0-2
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

-- no debconf information

Bug#1035009: libocct-data-exchange-dev: missing Breaks+Replaces for liboce-modeling-dev when upgrading from bullseye

[Tobias Frost]

Control: tags -1 unreproducible
Control: severity -1 important

Hi Helmut, 

On Thu, 27 Apr 2023 14:58:58 +0200 Helmut Grohne  wrote:
> Package: libocct-data-exchange-dev
> Version: 7.6.3+dfsg1-5
> Severity: serious
> Justification: dpkg unpack error
> 
> Attempting to unpack libocct-data-exchange-dev/7.6.3+dfsg1-5 from Debian 
> bookworm
> on a minimal Debian bullseye with liboce-modeling-dev/0.18.3-1
> installed, causes an unpack error from dpkg due to
> /usr/lib/x86_64-linux-gnu/libTKIGES.so being contained in both packages.
> 
> | Selecting previously unselected package libocct-data-exchange-dev:amd64.
> | (Reading database ... 17251 files and directories currently installed.)
> | Preparing to unpack .../libocct-data-exchange-dev_7.6.3+dfsg1-5_amd64.deb 
> ...
> | Unpacking libocct-data-exchange-dev:amd64 (7.6.3+dfsg1-5) ...
> | dpkg: error processing archive 
> ./libocct-data-exchange-dev_7.6.3+dfsg1-5_amd64.deb (--unpack):
> |  trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKIGES.so', which is 
> also in package liboce-modeling-dev:amd64 0.18.3-1
> | Errors were encountered while processing:
> |  ./libocct-data-exchange-dev_7.6.3+dfsg1-5_amd64.deb
> 
> 
> Please ensure that libocct-data-exchange-dev has sufficient Breaks and 
> Replaces declarations.
> 
> Helmut
 
I cannot reproduce this.  liboce-foundation-dev liboce-modeling-dev is 
deinstalled here when
trying to installing libocct-data-exchange-dev. 
libocct-data-exchange-dev depends on libocct-foundation-dev, which conflicts 
liboce-foundation-dev.
liboce-modeling-dev is depending on liboce-foundation-dev, so the conflict is 
inherited.

Any hints what I am missing?


This is what I have done:
On a bullseye pbuilder chroot:

1) Installing liboce-modeling-dev

# apt install liboce-modeling-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  liboce-foundation-dev liboce-foundation11 liboce-modeling11
The following NEW packages will be installed:
  liboce-foundation-dev liboce-foundation11 liboce-modeling-dev 
liboce-modeling11
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.6 MB of archives.
After this operation, 77.1 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

(...)

2) changing to source.list to bookworm

3) apt update

4) # apt install libocct-data-exchange-dev

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  liboce-foundation11 liboce-modeling11
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  binutils binutils-common binutils-x86-64-linux-gnu fontconfig-config 
fonts-dejavu-core gcc-12-base libbinutils libbrotli-dev libbrotli1
  libbsd0 libc-bin libc-dev-bin libc6 libc6-dev libctf-nobfd0 libctf0 
libdeflate0 libdrm-amdgpu1 libdrm-common libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-dev libegl-mesa0 
libegl1 libelf1 libffi8 libfontconfig1 libfreeimage-dev
  libfreeimage3 libfreetype-dev libfreetype6 libfreetype6-dev libgbm1 libgl-dev 
libgl1 libgl1-mesa-dev libgl1-mesa-dri libglapi-mesa
  libgles-dev libgles1 libgles2 libglu1-mesa libglu1-mesa-dev libglvnd-core-dev 
libglvnd-dev libglvnd0 libglx-dev libglx-mesa0 libglx0
  libgprofng0 libhwloc15 libice-dev libice6 libimath-3-1-29 libjansson4 
libjbig0 libjpeg62-turbo libjxr0 liblcms2-2 liblerc4 libllvm15
  libmd0 libocct-data-exchange-7.6 libocct-draw-7.6 libocct-foundation-7.6 
libocct-foundation-dev libocct-modeling-algorithms-7.6
  libocct-modeling-algorithms-dev libocct-modeling-data-7.6 
libocct-modeling-data-dev libocct-ocaf-7.6 libocct-ocaf-dev
  libocct-visualization-7.6 libocct-visualization-dev libopenexr-3-1-30 
libopengl-dev libopengl0 libopenjp2-7 libpciaccess0 libpng-dev
  libpng16-16 libpthread-stubs0-dev libraw20 libsensors-config libsensors5 
libsm-dev libsm6 libstdc++6 libtbb12 libtbbbind-2-5
  libtbbmalloc2 libtcl8.6 libtiff6 libtk8.6 libwayland-client0 
libwayland-server0 libwebp7 libwebpmux3 libx11-6 libx11-data libx11-dev
  libx11-xcb1 libxau-dev libxau6 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 
libxcb-present0 libxcb-randr0 libxcb-shm0 libxcb-sync1
  libxcb-xfixes0 libxcb1 libxcb1-dev libxdmcp-dev libxdmcp6 libxext-dev 
libxext6 libxfixes3 libxft2 libxmu-dev libxmu-headers libxmu6
  libxrender1 libxshmfence1 libxss1 libxt-dev libxt6 libxxf86vm1 libz3-4 
libzstd1 occt-misc rpcsvc-proto x11-common x11proto-dev
  xorg-sgml-doctools xtrans-dev zlib1g zlib1g-dev
Suggested packages:
  binutils-doc glibc-doc libc-l10n locales libnss-nis libnss-nisplus 
manpages-dev freetype2-doc libhwloc-contrib-plugins libice-doc
  liblcms2-utils pciutils lm-sensors libsm-doc tcl8.6 tk8.6 libx11-doc 
libxcb-doc libxext-doc libxt-doc
Recommended packages:
  manpages manpages-dev libc-devtools libhwloc-plugins libpng-tools
The 

Bug#1035009: libocct-data-exchange-dev: missing Breaks+Replaces for liboce-modeling-dev when upgrading from bullseye

[Tobias Frost]

On Thu, 27 Apr 2023 14:58:58 +0200 Helmut Grohne  wrote:
> Package: libocct-data-exchange-dev
> Version: 7.6.3+dfsg1-5
> Severity: serious
> Justification: dpkg unpack error
> 
> Attempting to unpack libocct-data-exchange-dev/7.6.3+dfsg1-5 from Debian 
> bookworm
> on a minimal Debian bullseye with liboce-modeling-dev/0.18.3-1
> installed, causes an unpack error from dpkg due to
> /usr/lib/x86_64-linux-gnu/libTKIGES.so being contained in both packages.
> 
> | Selecting previously unselected package libocct-data-exchange-dev:amd64.
> | (Reading database ... 17251 files and directories currently installed.)
> | Preparing to unpack .../libocct-data-exchange-dev_7.6.3+dfsg1-5_amd64.deb 
> ...
> | Unpacking libocct-data-exchange-dev:amd64 (7.6.3+dfsg1-5) ...
> | dpkg: error processing archive 
> ./libocct-data-exchange-dev_7.6.3+dfsg1-5_amd64.deb (--unpack):
> |  trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKIGES.so', which is 
> also in package liboce-modeling-dev:amd64 0.18.3-1
> | Errors were encountered while processing:
> |  ./libocct-data-exchange-dev_7.6.3+dfsg1-5_amd64.deb
> 
> 
> Please ensure that libocct-data-exchange-dev has sufficient Breaks and 
> Replaces declarations.
> 
> Helmut
> 
> 

src:oce is a different edition of src:opencascade, so I guess this needs to be 
a Conflicts:

-- 
tobi

Bug#1035337: RFP: apt-fast -- A shellscript wrapper for apt that speeds up downloading of packages.

[Fjords]

Package: apt-fast
Severity: wishlist

Hello, I think with other package managers like Pacman already 
supporting parallel downloading for years, it would be time for Apt to 
do the same. Apt-fast seems to be the temporary solution for now, but it 
remains an unofficial Debian/Ubuntu package with DEBs hosted via a PPA 
(https://code.launchpad.net/~apt-fast/+archive/stable).


I think something like this would be absolutely crucial for Debian-based 
systems, as there are times when Apt can be painfully slow, thus turning 
off a lot of people (especially when it comes to distribution upgrades). 
I think either making this available as a separate package or having its 
core functionality adopted for Apt would be great. Please consider 
something like this for Trixie (since we are deep in the Bookworm 
freeze). Thank you.


Upstream: https://github.com/ilikenwf/apt-fast

Bug#1035336: release-notes: libgdal-perl dropped in Bookworm

[Francesco P. Lovergine]

Package: release-notes
Severity: normal

The ubiquitous geospatial GDAL library dropped the XS-based Perl binding, 
almost one
year ago. As a consequence the Perl binding is not more directly supported at
upstream level and developers/users that need a Perl support for GDAL must
migrate to the FFI interface provided by Geo::GDAL::FFI package, available on
CPAN. As a direct consequence, Bookworm is missing a Perl binding for GDAL
(libgdal-perl in Bullseye and previous Debian releases).

A wiki page is available at https://wiki.debian.org/BookwormGdalPerl to help
users to start migration to the new interface.

Bug#1035298: pre-approval: unblock: Lazarus/2.2.6+dfsg1-2

[Abou Al Montacir]

Control: tags -1 - moreinfo

Hi Graham,

On Sun, 2023-04-30 at 12:35 +0200, Graham Inggs wrote:
> > Hi Abou
> > 
> > Please go ahead and upload to unstable, and remove the moreinfo tag
> > once the package is built.
Done.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part

Bug#973050: needrestart: Use of uninitialized value in hex at /usr/share/perl5/NeedRestart/uCode/AMD.pm line 169

[Martin-Éric Racine]

On Sun, 14 Aug 2022 11:30:22 +0300 =?utf-8?q?Martin-=C3=89ric_Racine?=
 wrote:
> Package: needrestart
> Version: 3.6-1
> Followup-For: Bug #973050
> I've already provided the requested info. Is there anything else you need to 
> fix this?

Ping.