date:20230627

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-aes-s...@packages.debian.org, n...@sail.ng
Control: affects -1 + src:rust-aes-soft

Deprecated upstream in favor of the aes crate.

-- 
Sdrager,
Blair Noctis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039631: RM: rust-aes-ctr -- ROM; deprecated upstream

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-aes-...@packages.debian.org, n...@sail.ng
Control: affects -1 + src:rust-aes-ctr

Deprecated upstream in favor of the aes crate.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039630: RM: rust-secret-service -- ROM; Inactive upstream, deprecated deps

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-secret-serv...@packages.debian.org, n...@sail.ng
Control: affects -1 + src:rust-secret-service

Also has a few actively developed alternatives.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039629: RM: rust-block-modes -- ROM; Deprecated upstream

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-block-mo...@packages.debian.org, n...@sail.ng
Control: affects -1 + src:rust-block-modes

Deprecated upstream in favor of https://github.com/RustCrypto/block-modes.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025053: Fwd: upx

2023-06-27 Thread Gürkan Myczko

 Original Message 
Subject: upx
Date: 28.06.2023 06:21
From: Gürkan Myczko 
To: rob...@debian.org

Czesc Robert

I really like and use upx often. And I miss it on Debian 12. So I did 
this:

https://salsa.debian.org/tar/upx-ucl

It's far from perfect, should probably mention the two CVEs. But is 
there a

plan from you? Would you mind adding myself as Uploaders?

Kind regards,
Alex.

Bug#574388: Fwd: wmnd bug (32 bit overflow)

2023-06-27 Thread Gürkan Myczko

 Original Message 
Subject: wmnd bug (32 bit overflow)
Date: 18.09.2017 10:26
From: Gürkan Myczko 
To: rob...@debian.org

Dear Robert

Do you have a plan to fix this bug? I'm still using wmnd, and I tried to 
apply the included patch, rebuild the package.
And run it on a 32-bit machine (however I didn't wait for the overflow 
to happen, yet).

I have an updated version at
http://sid.ethz.ch/debian/wmnd/

I would be glad to have that bug fixed!

And I guess the other bug can be closed too, if it's added to 
debian/README.Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574388

Thanks,
Gurkan

Bug#1025053: Fwd: upx-ucl

2023-06-27 Thread Gürkan Myczko

 Original Message 
Subject: upx-ucl
Date: 14.05.2021 13:29
From: Gürkan Myczko 
To: rob...@debian.org

Hi Robert

I've created an updated upx package from master upstream, do you have an
idea when they will release 4.x? I've wanted to try that --lzma 
compression:

https://mentors.debian.net/package/upx-ucl/

Best,

Bug#1036113: libpurple0: license conflict with libsasl2


On 2023-06-27 17:35, Bastian Germann wrote:

Am 28.06.23 um 00:13 schrieb Richard Laager:


The last bugfix release took them more than 3 years and when #767 is 
released is unknown.


When a release happens is irrelevant, as you can carry #767 as a patch 
in the Debian package until then.


Even when that happens, upstream still has to eliminate the last 
instance of the RSA-MD license.


What is the remaining instance of RSA-MD licensed code after #767?

License compliance will not just magically happen by ignoring the 
problematic parts in Debian.


I didn't suggest it would, nor am I ignoring anything. My point is that, 
in this particular case, it seems that you have everything solved or 
close to solved by yourself.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

The original submitter replied off the tracker (probably by accident). 
I'll summarize here.


The ntp.conf he included is the stock ntp.conf.

He indicated he will try to get a backtrace.

--
Richard

Bug#1039621: libngs-jni: Installs shared object in wrong directory

2023-06-27 Thread Aaron M. Ucko

Guillem Jover  writes:

>   /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so
>
> Where the variable has not been expanded and appears as is. So the
> shared object will not be found.

Oops, so it does; automatic testing evidently missed that due to running
with libncbi-ngs-dev installed.  I went with a minimal fix, in part to
facilitate getting it into a stable update if anyone considers that
warranted.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#805449: dbus: Please reboot the system when convenient. ← ?!

2023-06-27 Thread Thorsten Glaser

Hi,

I got this:

Setting up dbus (1.12.28-0+deb11u1) ...
A reboot is required to replace the running dbus-daemon.
Please reboot the system when convenient.

I read through the bugreport and I can see why it should not
just be automatically restarted.

But I could just restart dbus and then all things that use it.
This is a systemd-free shop, so… I don’t even know what would
use dbus at all. It’s there as Qt dependency :/

Is there a “needrestart”-like tool, or something like ps/netstat,
showing which programs use dbus, for restarting them afterwards?

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#1038648: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#1038648: fixed in xserver-xorg-video-qxl 0.1.6-1)

2023-06-27 Thread Frank Heckenbach

Doesn't fix the problem.

Bug#1039628: ITP: ruby-kdl -- Ruby implementation of KDL Document Language

2023-06-27 Thread Lucas Kanashiro


Package: wnpp
Severity: wishlist

* Package name: ruby-kdl
  Version: 1.0.3
  Upstream Author: Danielle Smith 
* URL: https://github.com/danini-the-panini/kdl-rb
* License: Expat
  Programming Lang: Ruby
  Description: Ruby implementation of KDL Document Language

 Ruby implementation of the KDL Document Language Spec. KDL is a cuddly
 document language with xml-like semantics that looks like you are 
invoking a
 bunch of CLI commands! It is meant to be used both as a serialization 
format

 and a configuration language, much like JSON, YAML, or XML.
 .
 More info about KDL here: https://kdl.dev/.

This package is needed by the src:camping latest upstream version which 
is blocking the ruby-rack version 3 transition. It will be maintained 
under the Ruby team's umbrella.


--
Lucas Kanashiro

Bug#989874: Your mail

2023-06-27 Thread Christian Gelinek

On Tue, 22 Nov 2022 01:25:33 +0100 "Mr. T"  wrote:
> any idea of which package i have to install in addition so that i get
> some nice icons instead of this bulky text?

Yes, as I have mentioned in #987253, installing the breeze-icon-theme 
package solved the issue for me, on both Debian 11 and 12.

Hope that helps!

Bug#1039627: python3-jedi: please do not vendor a copy of python3-typeshed

2023-06-27 Thread Alexandre Detiste

Package: python3-jedi
Version: 0.18.2-1
Severity: normal

Hi,

typeshed is already packaged in the archive as python3-typeshed,
please strip python3-jedi from it's copy.

Greetings,

$ locate waitress | grep pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/__init__.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/adjustments.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/buffers.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/channel.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/compat.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/parser.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/proxy_headers.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/receiver.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/rfc7230.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/runner.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/server.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/task.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/trigger.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/utilities.pyi
/usr/lib/python3/dist-packages/jedi/third_party/typeshed/third_party/3/waitress/wasyncore.pyi
/usr/lib/python3/dist-packages/waitress-stubs/__init__.pyi
/usr/lib/python3/dist-packages/waitress-stubs/adjustments.pyi
/usr/lib/python3/dist-packages/waitress-stubs/buffers.pyi
/usr/lib/python3/dist-packages/waitress-stubs/channel.pyi
/usr/lib/python3/dist-packages/waitress-stubs/compat.pyi
/usr/lib/python3/dist-packages/waitress-stubs/parser.pyi
/usr/lib/python3/dist-packages/waitress-stubs/proxy_headers.pyi
/usr/lib/python3/dist-packages/waitress-stubs/receiver.pyi
/usr/lib/python3/dist-packages/waitress-stubs/rfc7230.pyi
/usr/lib/python3/dist-packages/waitress-stubs/runner.pyi
/usr/lib/python3/dist-packages/waitress-stubs/server.pyi
/usr/lib/python3/dist-packages/waitress-stubs/task.pyi
/usr/lib/python3/dist-packages/waitress-stubs/trigger.pyi
/usr/lib/python3/dist-packages/waitress-stubs/utilities.pyi
/usr/lib/python3/dist-packages/waitress-stubs/wasyncore.pyi
$ dpkg -S /usr/lib/python3/dist-packages/waitress-stubs/adjustments.pyi
python3-typeshed: /usr/lib/python3/dist-packages/waitress-stubs/adjustments.pyi



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-jedi depends on:
ii  python33.11.2-1+b1
ii  python3-parso  0.8.3-1

python3-jedi recommends no packages.

python3-jedi suggests no packages.

-- no debconf information

Bug#1038789: Enable capabilities feature

Hi!

On Wed, 2023-06-21 at 17:20:35 +0100, Mark Hindley wrote:
> Many thanks for this suggestion. I appreciate the advantages of
> capabilities support.

> Openrc also has optional capabilities support in supervise-daemon which might 
> be
> an advantage to users, but isn't used by default in Debian.
> 
> It might be worth exploring adding capabilities support to src:dpkg
> start-stop-daemon. Maybe the src:openrc code would be a starting point. I
> haven't looked how much the two codebases have diverged.
> 
> Guillem,
> 
> What do you think?

Some time ago I asked on d-d whether anyone would have an issue with
dpkg.deb in Debian linking against libcap [D]. And where I had worked
on the following branch:

  https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/s-s-d-posix-caps

Which I need to go over again before merging. But otherwise support
for this in that or some other similar form should be coming soon to
s-s-d.

Thanks,
Guillem

[D] https://lists.debian.org/debian-devel/2022/07/msg00045.html

Bug#1039624: icu: reproducible-builds: embedded SHELL and build paths

Source: icu
Version: 23.06.14+git20230616+ds-4
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

various files contain embedded build paths and differing values for
SHELL:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/icu.html

  /usr/share/doc/icu-doc/html/icudocs.tag.gz

  /build/1st/icu-72.1/source/common/unicode/
  vs.
  /build/2/icu-72.1/2nd/source/common/unicode/

  /usr/lib/x86_64-linux-gnu/icu/72.1/Makefile.inc

  SHELL·=·/bin/bash
  vs.
  SHELL·=·/bin/sh

The attached patches modify debian/rules remove the build path and
consistently set SHELL to /bin/sh on the affected files.

With both these patches applied, based on my local tests, icu should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining icu!

live well,
  vagrant
From 8f05336668e04eaa580aaf01e33983d3ae0ee9f8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 14:38:11 -0700
Subject: [PATCH 1/2] debian/rules: Remove build paths from .inc and .tag
 files.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 7985886..31988b6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -50,6 +50,8 @@ override_dh_auto_install:
 	$(MAKE) -C $(CURDIR)/source/ install-doc DESTDIR=$(CURDIR)/debian/tmp/
 	# delete extra license file
 	$(RM) $(CURDIR)/debian/tmp/usr/share/icu/$(l_SONAME).?/LICENSE
+	# Remove build paths
+	sed -i -e 's,$(CURDIR),BUILDPATH,g' debian/*/usr/lib/*/icu/*/*.inc
 
 override_dh_installdocs-indep:
 	dh_installdocs -i
@@ -61,6 +63,8 @@ override_dh_installdocs-indep:
 			ln -s `basename $$normal` $$file; \
 		fi; \
 	done
+	# Remove build paths from documentation
+	sed -i -e 's,$(CURDIR),,g' debian/icu-doc/usr/share/doc/icu-doc/html/icudocs.tag
 
 override_dh_missing:
 	dh_missing --list-missing
-- 
2.39.2

From a3a054342429b7165c8bbea48a9609bf4c8d0dfb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 14:40:43 -0700
Subject: [PATCH 2/2] debian/rules: Consistently use /bin/sh SHELL in .inc
 files.

---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 31988b6..28f31ab 100755
--- a/debian/rules
+++ b/debian/rules
@@ -52,6 +52,8 @@ override_dh_auto_install:
 	$(RM) $(CURDIR)/debian/tmp/usr/share/icu/$(l_SONAME).?/LICENSE
 	# Remove build paths
 	sed -i -e 's,$(CURDIR),BUILDPATH,g' debian/*/usr/lib/*/icu/*/*.inc
+	# Consistently use /bin/sh for SHELL
+	sed -i -e 's,^SHELL =.*,SHELL = /bin/sh,g' debian/*/usr/lib/*/icu/*/*.inc
 
 override_dh_installdocs-indep:
 	dh_installdocs -i
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1038891: libdpkg-perl: unrecognized hardcoded CC flags in scripts/Dpkg/Vendor/Debian.pm

Hi!

On Thu, 2023-06-22 at 19:46:11 +0300, VSYakovetsky wrote:
> Package: libdpkg-perl
> Version: 1.21.22ubuntu1
> Severity: minor
> X-Debbugs-Cc: vsyakovet...@gmail.com

>* What led up to the situation?
>  - building deb package with dpkg-buildpackage and clang
>  - hardcoded -ffat-lto-objects cc flag in scripts/Dpkg/Vendor/Debian.pm
>
> https://git.dpkg.org/git/dpkg/dpkg.git/tree/scripts/Dpkg/Vendor/Debian.pm#n451

This has come up in the past, and while it would be nice to be able to
support multiple compilers in general for a specific vendor the build
flags default and are adapted just to the default compiler for that
distribution.

Here's mail covering what autodetection would involve if this was to
be supported:

  https://lists.debian.org/debian-dpkg/2014/06/msg00050.html

>* What exactly did you do (or not do) that was effective (or ineffective)?
>CC=clang dpkg-buildpackage ...
> 
>* What was the outcome of this action?
>  clang: warning: optimization flag '-ffat-lto-objects' is not supported 
> [-Wignored-optimization-argument]

>* What outcome did you expect instead?
>  not sorting out rare flags specific to one compiler
>  (a possible workaround was manually set 
> DEB_CFLAGS_STRIP=-ffat-lto-objects in environment)

Yes, in this case if you change the compiler, then you need to adapt
any such build flags that might not play well with it.

So, I'm afraid there's not much that can be done here. Perhaps this
could be documented somewhere more prominently, but I'm not sure
where, perhaps the dpkg-buildpackage or dpkg-buildflags man pages or
similar, not sure if that would have helped in your case?

Otherwise, I'm inclined to probably be closing this in a bit.

Thanks,
Guillem

Bug#815187: Bug debian-Installer (bookworm): Installation grub fails without error message

2023-06-27 Thread Pascal Hambourg


On 27/06/2023 at 17:55, CJ Kucera wrote:


Just popping in to say that I've run into this exact problem on Debian
12 (Bookworm) as well.  I'm installing onto a system with two drives in
a raid1 config, so the installer presents a dialog with these choices
for installing GRUB:

 - Enter device manually
 - /dev/sda  (ata-VBOX_HARDDISK_VBcb2c038a-37db3d41)
 - /dev/sdb  (ata-VBOX_HARDDISK_VB9084690a-b32386db)

If choose "Enter device manually", and type in "/dev/sda", I get two
statuses shown on the next progress bar:

 1. running "grub-install /dev/sda"
 2. running "update-grub"

If I instead pick the dropdown entry for "/dev/sda", the installer skips
the "grub-install" step and goes right to "update-grub," which leaves the
freshly-installed OS in an unbootable state.

Interestingly, if I *manually* type in /dev/sda (which installs GRUB
properly) and then go back and re-install GRUB using the dropdown entry,
from that point forward the dropdown selection works and I get the
"grub-install" step properly.


This looks like bug #1035096 (patch available but came too late for 
bookworm release).

Bug#1039623: shotcut: reproducible-builds: build paths trigger differences, embedded date-based version

Source: shotcut
Version: 23.06.14+git20230616+ds-4
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains a hash of the build path resulting in different
buildid and the SHOTCUT_VERSION is set based on a timezone-dependent
timestamp:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/shotcut.html

  /usr/share/metainfo/org.shotcut.Shotcut.metainfo.xml

  
  vs.
  

The attached patches modify debian/rules to pass
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to dh_auto_configure to use a relative
path for rpath, and modify CmakeLists.txt to set SHOTCUT_VERSION using
UTC for the timezone.

With both these patches applied, based on my local tests, shotcut should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining shotcut!

live well,
  vagrant
From 887be1759bf532e8008f213a6c7b61e81fee6c2a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 15:27:59 -0700
Subject: [PATCH 1/2] CmakeLists.txt: Use UTC for timestamp for reproducible
 builds.

Otherwise, the timestamp will be timezone dependent.

https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_cmake_issue.html
---
 CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 254020b..b1f3d72 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -5,7 +5,7 @@ if (${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.20")
 endif()
 
 if(NOT DEFINED SHOTCUT_VERSION)
-  string(TIMESTAMP SHOTCUT_VERSION "%y.%m.%d")
+  string(TIMESTAMP SHOTCUT_VERSION "%y.%m.%d" UTC)
 endif()
 
 project(shotcut
-- 
2.39.2

From a17d43a3fc983995544156adebb5fea8d3467fd2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 16:01:27 -0700
Subject: [PATCH 2/2] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 510b5de..a709184 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,6 +18,9 @@ export QT_SELECT=qt5
 %:
 	dh $@
 
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
+
 override_dh_shlibdeps:
 	dh_shlibdeps -l/usr/lib/shotcut $(DEBARCH)
 
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1038888: dpkg-buildpackage(1): mention all supported flags for DEB_BUILD_OPTIONS

Hi!

On Thu, 2023-06-22 at 17:35:15 +0200, Sebastian Kayser wrote:
> Package: dpkg-dev
> Version: 1.21.22
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: skay...@tutanota.com

> the man page for dpkg-buildpackage only includes a subset of supported flags
> for DEB_BUILD_OPTIONS and the description for the "nocheck" flags seems to
> be incorrect.

It is only supposed to include those supported or known by dpkg tools,
as the others are defined by distribution specific policies.

> The currently supported, full list of flags is available at 
> 
> https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options
> 
> I've attached an example patch to include the supported flags list in
> dpkg-buildpackage(1).

Thanks for the patch! Although in general this is backwards, the
Debian policy documents the dpkg behavior and not the other way
around. So perhaps something along the lines like the attachment
instead, while probably not what you were looking for, is something
that feels acceptable for inclusion.

Thanks,
Guillem
From dbbb968d8e92f816de9538653ee70d19b08a3681 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 23 Jun 2023 01:53:02 +0200
Subject: [PATCH] man: Document known DEB_BUILD_OPTIONS options

Itemize the options for easier reading. Include all the options
supported by dpkg-buildpackage or the dpkg tooling, and mention
which of those debian/rules might act on too.

Closes: #103
---
 man/dpkg-buildpackage.pod | 44 ++-
 1 file changed, 39 insertions(+), 5 deletions(-)

diff --git a/man/dpkg-buildpackage.pod b/man/dpkg-buildpackage.pod
index 3da341992..a28892fe9 100644
--- a/man/dpkg-buildpackage.pod
+++ b/man/dpkg-buildpackage.pod
@@ -740,14 +740,48 @@ Overridden by the B<--sign-keyfile> option.
 
 =item B
 
-If set, it will contain a space-separated list of options that might
-affect the build process in I, and the behavior of some
-dpkg commands.
+If set, it will contain a space-separated list of options that affect
+the behavior of some dpkg commands, and might affect the build process
+in I if the code in there honors them.
 
-With B the B variable will be ignored.
-With BI the parallel jobs will be set to I,
+The following are the options known and supported by dpkg tools, other
+options honored by I might be defined by distribution
+specific policies.
+
+=over
+
+=item BI
+
+The parallel jobs will be set to I,
 overridden by the B<--jobs-try> option.
 
+=item B
+
+The B variable will be ignored in B.
+The I in the packaging is not expected to run test suites
+during the build.
+
+=item B
+
+If I calls B to set up the build flags,
+those will be set to not enable any optimizations.
+
+=item B
+
+The I in the packaging should ensure that objects are not
+stripped from their debugging information. If I includes
+the B make fragment the B make variable will
+respect this option.
+
+=item B
+
+The B<--no-print-directory> flags will be appended to the B
+environment variable.
+The I in the packaging should reduce verbosity, while not
+being completely quiet.
+
+=back
+
 =item B
 
 If set, it will be used as the active build profile(s) for the package
-- 
2.40.1

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

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
I'd like to update the openjdk-8 bundled with nvidia-cuda-toolkit to the
latest version from sid, fixing a bunch of CVEs.

[ Impact ]
reduces the number of open CVEs in stable/non-free

[ Tests ]
not really testable due to hardware and driver requirements

[ Risks ]
low, openjdk-8 is ony needed by nvidia-visual-profiler which is (nearly)
a leaf 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 (old)stable
  (does not include the changed component tarballs)
  [x] the issue is verified as fixed in unstable

[ Changes ]
update some component tarballs, they have versions in their name,
therefore that is possible without replacing the whole source package

trivial Linux 6.4 patch for nvidia-fs-dkms

[ Other info ]
n/a


Andreas
diff --git a/debian/changelog b/debian/changelog
index 273dc54..7225656 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+nvidia-cuda-toolkit (11.8.0-5~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Tue, 27 Jun 2023 21:33:39 +0200
+
+nvidia-cuda-toolkit (11.8.0-5) unstable; urgency=medium
+
+  * Fix nvidia-fs kernel module build for Linux 6.4.
+  * Use a snapshot of openjdk-8-jre (8u372-ga-1).
+
+ -- Andreas Beckmann   Tue, 27 Jun 2023 18:17:09 +0200
+
 nvidia-cuda-toolkit (11.8.0-4) unstable; urgency=medium
 
   * nsight-systems: Fix symlinks to executables.
@@ -10,10 +23,10 @@ nvidia-cuda-toolkit (11.8.0-3) unstable; urgency=medium
 
   * Add clang-14 as supported compiler alternative.
   * Use vendor-specific alternatives for the driver dkms package.
-  * Backport nvfs_io_complete changes from nvidia-fs 2.15 (CUDA 12.1) to fix
-kernel module build for Linux 5.16.
-  * Backport nvfs_rw_verify_area changes from nvidia-fs 2.15 (CUDA 12.1) to
-fix kernel module build for Linux 5.18.
+  * Backport nvfs_io_complete changes from nvidia-fs 2.14.14 (CUDA 12.0.1) to
+fix kernel module build for Linux 5.16.
+  * Backport nvfs_rw_verify_area changes from nvidia-fs 2.14.14 (CUDA 12.0.1)
+to fix kernel module build for Linux 5.18.
   * Switch from prandom_u32() to get_random_u32() to fix kernel module build
 for Linux 6.1.  (Closes: #1033288)
 
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 37bb286..2f6cb15 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -10,8 +10,8 @@ component = [
'amd64',
'ppc64el',
'arm64',
-   'openjdk-8-source-8u362-ga-4',
-   'openjdk-8-jre-amd64-8u362-ga-4',
-   'openjdk-8-jre-ppc64el-8u362-ga-4',
+   'openjdk-8-source-8u372-ga-1',
+   'openjdk-8-jre-amd64-8u372-ga-1',
+   'openjdk-8-jre-ppc64el-8u372-ga-1',
]
 debian-branch = main
diff --git a/debian/patches/nvidia-fs.patch b/debian/patches/nvidia-fs.patch
index 8951951..44c20a3 100644
--- a/debian/patches/nvidia-fs.patch
+++ b/debian/patches/nvidia-fs.patch
@@ -1,9 +1,9 @@
 Author: Andreas Beckmann 
 Description: backport support for newer kernels
- * backport nvfs_io_complete changes from nvidia-fs 2.15 (CUDA 12.1) to fix
-   kernel module build for Linux 5.16
- * backport nvfs_rw_verify_area changes from nvidia-fs 2.15 (CUDA 12.1) to
-   fix kernel module build for Linux 5.18
+ * backport nvfs_io_complete changes from nvidia-fs 2.14.14 (CUDA 12.0.1) to
+   fix kernel module build for Linux 5.16
+ * backport nvfs_rw_verify_area changes from nvidia-fs 2.14.14 (CUDA 12.0.1)
+   to fix kernel module build for Linux 5.18
  * switch from prandom_u32() to get_random_u32() to fix kernel module build
for Linux 6.1
 
@@ -86,7 +86,7 @@ Description: backport support for newer kernels
  .owner = THIS_MODULE,
  };
  
-+#if LINUX_VERSION_CODE <  KERNEL_VERSION(6,2,0)
++#if LINUX_VERSION_CODE < KERNEL_VERSION(6,2,0)
  static char *nvfs_devnode(struct device *dev, umode_t *mode)
 +#else
 +static char *nvfs_devnode(const struct device *dev, umode_t *mode)
@@ -94,13 +94,25 @@ Description: backport support for newer kernels
  {
  if (!mode)
  return NULL;
+@@ -2297,7 +2309,11 @@ static int __init nvfs_init(void)
+   pr_info("nvidia_fs: registered correctly with major number %d\n",
+   major_number);
+ 
++#if LINUX_VERSION_CODE < KERNEL_VERSION(6,4,0)
+   nvfs_class = class_create(THIS_MODULE, CLASS_NAME);
++#else
++  nvfs_class = class_create(CLASS_NAME);
++#endif
+ 
+   if (IS_ERR(nvfs_class)) {
+   unregister_chrdev(major_number, DEVICE_NAME);
 --- a/nvidia-cuda/nvidia_fs/usr/src/nvidia-fs/nvfs-mmap.c
 +++ b/nvidia-cuda/nvidia_fs/usr/src/nvidia-fs/nvfs-mmap.c
 @@ -598,7 +598,11 @@ static int nvfs_mgroup_mmap_internal(str
  }
  
  /* dont allow mremap to expand and dont allow copy on fork */
-+#if LINUX_VERSION_CODE <  KERNEL_VERSION(6,3,0)

Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

2023-06-27 Thread Mike Hommey

On Tue, Jun 27, 2023 at 11:39:12AM +0200, Philipp Marek wrote:
> Package: firefox
> Version: 114.0-1
> Severity: grave
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Websites that need randomness ([1]) are broken,
> on both Debian FF 113.0.2 and 114.0 (114.0.2 not yet available for amd64).
> 
> Reproduced with a new profile without any plugins.
> 
> strace shows FF being able to use getrandom(),
> so it seems to be a userspace problem.
> 
> 
> 114.0.2 from upstream works as expected;
> Mozilla chat recommended asking the packaging team.
> 
> 
> Ad 1:
> - banking.bank99.at uses crypto.getRandomValues() even before login

"The server at banking.bank99.at is taking too long to respond."

> - RedHat support webpage uses getRandomUUID after login
> Both fail with "OperationError: The operation failed for an 
> operation-specific reason"

Obviously, I can't reproduce with this since I can't login...

I also can't reproduce calling the crypto.randomUUID and
crypto.getRandomValues functions from the devtools console...

Try downgrading libnss3.

Mike

Bug#1036113: libpurple0: license conflict with libsasl2

2023-06-27 Thread Bastian Germann

Am 28.06.23 um 00:13 schrieb Richard Laager:

Wait a minute... You are a maintainer for cyrus-sasl.

Just the package maintainer in Debian.

You have already addressed the BSD-4-clause-KTH in the latest upload.

That is true, which I have noted on the other bug.

You also fixed debian/copyright to reference BSD-3-Clause-Attribution in the latest upload. That license is fine for the
reasons I mentioned.

That is your legal take on it. My take is that BSD-3-Clause-Attribution is GPL-incompatible because it has a further
restriction on distribution.

That just leaves the MD5 stuff, right? You have authored a fix for that, which
it looks like will be merged shortly:
https://github.com/cyrusimap/cyrus-sasl/pull/767

If BSD-3-Clause-Attribution was GPL-compatible then, yes, RSA-MD license is the last license that causes an
GPL-incompatibility.

It seems like you can have this fixed any time (by merging in upstream #767)
and will have it fixed shortly.

I do not have commit access to upstream nor do I have any particular role there.
The last bugfix release took them more than 3 years and when #767 is released
is unknown.
Even when that happens, upstream still has to eliminate the last instance of
the RSA-MD license.

So why do I need to do anything?

You don't need to. But you should if you want to keep pidgin in testing.

License compliance will not just magically happen by ignoring the problematic
parts in Debian.
Actually, I am also happy when you appeal to any of the Debian bodies (TC?) about the severity of this bug so that there
is a decision made on it.

Bug#1036825: po4a: Gracefully handle unsupported fonts in man module

2023-06-27 Thread Bjarni Ingi Gislason

On Sat, May 27, 2023 at 02:02:12PM +0200, Helge Kreutzmann wrote:
> Hello,
> On Sat, May 27, 2023 at 01:57:46PM +0200, Helge Kreutzmann wrote:
> > So there are two solutions:
> > a) Reword the message to clearly state that the build is aborted
> > b) Ignore the font change, i.e. actually build the pot file
> >In this case, the warning can remain as is.
> > 
> > Obviously, I would prefer a) (and potentially a sane workaround until
> > then).
> 
> I would prefer *b)*. Sorry for the typo.

  There should exist a file "man.local" (for example in /etc/groff)
which can be augmented with

.\" "CW" is not a portable font name, but some man pages use it anyway.
.\" Uncomment this to suppress warnings produced by such pages.  This
.\" test remaps the font to roman ("R") on nroff (terminal) devices. You
.\" might prefer to remap it to bold ("B") instead.
.if n \{\
.  ftr CW R
.  ftr C R
.  ftr P R
.\}

  Something like this will be in the next (pending) groff release,
but will have to be adjusted (locally) for the fonts in question.

Bug#1036113: libpurple0: license conflict with libsasl2


Wait a minute... You are a maintainer for cyrus-sasl.

You have already addressed the BSD-4-clause-KTH in the latest upload.

You also fixed debian/copyright to reference BSD-3-Clause-Attribution in 
the latest upload. That license is fine for the reasons I mentioned.


That just leaves the MD5 stuff, right? You have authored a fix for that, 
which it looks like will be merged shortly:

https://github.com/cyrusimap/cyrus-sasl/pull/767

It seems like you can have this fixed any time (by merging in upstream 
#767) and will have it fixed shortly.


So why do I need to do anything?

--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039620: [INTL:ro] Romanian debconf templates translation-update of mdadm

2023-06-27 Thread Remus-Gabriel Chelu

Package: mdadm
Version: N/A
Severity: wishlist
Tags: l10n, patch

Hello Daniel,

Please find attached the Romanian update translation of the «debconf_mdadm» 
file.
-- 
Thanks,
Remus-Gabriel

bin70Q4umxLv5.bin
Description: Binary data

Bug#1039621: libngs-jni: Installs shared object in wrong directory

Package: libngs-jni
Version: 3.0.3+dfsg-5
Severity: serious

Hi

This package installs the shared object in the following _literal_
pathname:

  /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so

Where the variable has not been expanded and appears as is. So the
shared object will not be found.

Thanks,
Guillem

Bug#1039617: liblopsub: reproducible-builds: timestamps in gzip headers for changelog and manpage

On 2023-06-27, Andre Noll wrote:
> On Tue, Jun 27, 12:57, Vagrant Cascadian wrote:
>
>> The attached two patches (one patching the upstream Makefile, the other
>> patching debian/rules) fix this by passing -n to the gzip calls used to
>> compress changelog.Debian and the various manpages.
>> 
>> According to my local tests, with these two patches applied liblopsub
>> should build reproducibly on tests.reproducible-builds.org once it
>> migrates to debian/trixie! This alone does not resolve all
>> reproducibilitiy issues (e.g. build paths, tested in unstable and
>> experimental).
>
> This issue was addressed already four years ago when Chris Lamb (CC)
> submitted an analogous patch, see below. His patch has been part of the
> master branch since then, although no new version has been released.
>
> I therefore assume that there is nothing to do for me in this
> regard. Please let me know if this is not the case.

Given that this change was accepted in 2019, would you consider
uploading a version with the fixes applied to Debian, either by making a
new upstream version, or applying the patches to an older version?

Otherwise, my other Reproducible Builds team members and I will likely
keep wondering why it is not yet reproducible... possibly spending more
time fixing things apparently already with known fixes!

live well,
  vagrant

> commit 2d0464872cec02b53f5bb5ca2a037cb764641c1f
> Author: Chris Lamb 
> Date:   Mon Dec 2 10:44:23 2019 +0100
>
> Make the build reproducible.
> 
> Whilst working on the Reproducible Builds effort [0] we noticed that
> liblopsub could not be built reproducibly.
> 
> This is because it calls "gzip" manually without the -n
> flag. This should have been reported by lintian via the
> package-contains-timestamped-gzip tag.
> 
>   [0] https://reproducible-builds.org/
>
> diff --git a/Makefile b/Makefile
> index d1f89b1..e8fb7c0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -18,7 +18,7 @@ AR := ar
>  GROFF := groff
>  CP := cp
>  INSTALL := install
> -GZIP := gzip -f9
> +GZIP := gzip -fn9
>  ZCAT := zcat
>  
>  DATE_FMT := +%B %Y
> diff --git a/debian/rules b/debian/rules
> index 3ba7a74..3e73eac 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -49,8 +49,8 @@ binary: build
>   $(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright
>   $(INST_FILE) debian/changelog $(DOCS_DIR)/changelog.Debian
>   $(INST_FILE) debian/changelog $(DEVDOCS_DIR)/changelog.Debian
> - gzip -f9 $(DOCS_DIR)/changelog.Debian
> - gzip -f9 $(DEVDOCS_DIR)/changelog.Debian
> + gzip -fn9 $(DOCS_DIR)/changelog.Debian
> + gzip -fn9 $(DEVDOCS_DIR)/changelog.Debian
>   dh_makeshlibs
>   dh_shlibdeps
>   dh_strip


signature.asc
Description: PGP signature

Bug#996892: cyrus-sasl2: consider handling as system library


On 2023-06-27 16:19, Richard Laager wrote:

For BSD-3-Clause-Attribution


BTW, my suggestion of asking CMU to drop the clause should not be read 
as taking or agreeing to the position that it is GPL-incompatible.


I don't actually see an incompatibility with BSD-3-Clause-Attribution.

The original BSD license, which the FSF says is GPL-incompatible, said:

  All advertising materials mentioning features or use of this software
  must display the following acknowledgement: ...

BSD-3-Clause-Attribution is different:

  Redistributions of any form whatsoever must retain the following
  acknowledgment: ...

The "bad" clause requires you to put something in "advertising materials".

The actual effect of BSD-3-Clause-Attribution is that you need to retain 
the license grant block itself, which is already required by the 1st 
(for source) and 2nd (for binaries) clauses anyway, is always done by 
Debian, and is fine.


There is no practical difference between retaining (or being forced to 
retain) the following in a license block:

"This product includes software developed by ."
vs
"Copyright "

They mean literally the same thing!

--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036113: libpurple0: license conflict with libsasl2

2023-06-27 Thread Bastian Germann

Am 27.06.23 um 23:34 schrieb Richard Laager:
Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500. Quickly taking that list through UDD gives me
just over 4,500 source packages. Surely, a large number of those are going to be GPL licensed. Is your plan to file
Severity: serious bugs against all of them?

No, but at least the ones that directly depend on cyrus-sasl.
There are not many; most reverse dependencies are via libldap.

If so, isn't that an MBF that needs discussion on debian-devel first?

I do not have the capacity for a mass bug filing.
Once in a while I will look at the list of direct reverse dependencies and send
a bug.

If not, then why are you singling out Pidgin, a project that is
struggling to stay alive right now?

I am not singling out Pidgin. I have files similar bugs on other direct reverse
deps.

Your position in bug #996892 is that cyrus-sasl2 / libsasl2 should be considered a system library. If libsasl2 can be
considered a system library, then by your own position, there is no bug in libpurple0. I don't see how you can have it
both ways.

I would like to have a decision on it. No FTP Master has had the time to answer
the bug.
As long as there is no official stance from the responsible group in Debian
the library is not to be considered a system library and the serious severity
is valid.

If I were the package maintainer I would disable SASL and send the
unstable/testing users
who want it back to comment on #996892 to get a decision.

Bug#1039618: liblopsub: reproducible-builds: embedded build path in lopsubgen

2023-06-27 Thread Andre Noll

On Tue, Jun 27, 13:05, Vagrant Cascadian wrote:

> The build path is embedded in /usr/bin/lopsubgen:
> 
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/liblopsub.html
> 
>   /build/1st/liblopsub-1.0.3/lopsubgen.c:49
>   vs.
>   /build/2/liblopsub-1.0.3/2nd/lopsubgen.c:49
> 
> The attached patch fixes this by passing the -ffile-prefix-map argument
> to the compiler in the upstream Makefile.
> 
> According to my local tests, with this patch and the recently submitted
> timestamp patches applied, liblopsub should build reproducibly on
> tests.reproducible-builds.org!

I'm fine with making this change. However, the patch does not apply
to current master because it depends on the previous patches (which
don't apply). This is trivial to fix, though, as shown below. Do you
want me to apply this modified patch?

Thanks
Andre
---
commit 0a3588cdf56966a58decbbf62793dcc90217651c
Author: Vagrant Cascadian 
Date:   Tue Jun 27 23:04:56 2023 +0200

Makefile: Add -ffile-prefix-map to CC to avoid embedding build paths.

Signed-off-by: Andre Noll 

diff --git a/Makefile b/Makefile
index 548c96f..97d135a 100644
--- a/Makefile
+++ b/Makefile
@@ -28,6 +28,8 @@ INSTALL := install
 GZIP := gzip -fn9
 ZCAT := zcat
 
+CC += -ffile-prefix-map=$(CURDIR)=.
+
 dummy != $(M4) /dev/null || printf 'failed'
 ifeq ($(dummy), failed)
 $(error m4 is required to build this package)
-- 
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1039618: liblopsub: reproducible-builds: embedded build path in lopsubgen

On 2023-06-27, Andre Noll wrote:
> On Tue, Jun 27, 13:05, Vagrant Cascadian wrote:
>> The build path is embedded in /usr/bin/lopsubgen:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/liblopsub.html
>> 
>>   /build/1st/liblopsub-1.0.3/lopsubgen.c:49
>>   vs.
>>   /build/2/liblopsub-1.0.3/2nd/lopsubgen.c:49
>> 
>> The attached patch fixes this by passing the -ffile-prefix-map argument
>> to the compiler in the upstream Makefile.
>> 
>> According to my local tests, with this patch and the recently submitted
>> timestamp patches applied, liblopsub should build reproducibly on
>> tests.reproducible-builds.org!
>
> I'm fine with making this change. However, the patch does not apply
> to current master because it depends on the previous patches (which
> don't apply). This is trivial to fix, though, as shown below. Do you
> want me to apply this modified patch?

Works for me, thanks!

live well,
  vagrant

> commit 0a3588cdf56966a58decbbf62793dcc90217651c
> Author: Vagrant Cascadian 
> Date:   Tue Jun 27 23:04:56 2023 +0200
>
> Makefile: Add -ffile-prefix-map to CC to avoid embedding build paths.
> 
> Signed-off-by: Andre Noll 
>
> diff --git a/Makefile b/Makefile
> index 548c96f..97d135a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -28,6 +28,8 @@ INSTALL := install
>  GZIP := gzip -fn9
>  ZCAT := zcat
>  
> +CC += -ffile-prefix-map=$(CURDIR)=.
> +
>  dummy != $(M4) /dev/null || printf 'failed'
>  ifeq ($(dummy), failed)
>  $(error m4 is required to build this package)


signature.asc
Description: PGP signature

Bug#1039617: liblopsub: reproducible-builds: timestamps in gzip headers for changelog and manpage

2023-06-27 Thread Andre Noll

On Tue, Jun 27, 12:57, Vagrant Cascadian wrote:

> The attached two patches (one patching the upstream Makefile, the other
> patching debian/rules) fix this by passing -n to the gzip calls used to
> compress changelog.Debian and the various manpages.
> 
> According to my local tests, with these two patches applied liblopsub
> should build reproducibly on tests.reproducible-builds.org once it
> migrates to debian/trixie! This alone does not resolve all
> reproducibilitiy issues (e.g. build paths, tested in unstable and
> experimental).

This issue was addressed already four years ago when Chris Lamb (CC)
submitted an analogous patch, see below. His patch has been part of the
master branch since then, although no new version has been released.

I therefore assume that there is nothing to do for me in this
regard. Please let me know if this is not the case.

Thanks
Andre
---
commit 2d0464872cec02b53f5bb5ca2a037cb764641c1f
Author: Chris Lamb 
Date:   Mon Dec 2 10:44:23 2019 +0100

Make the build reproducible.

Whilst working on the Reproducible Builds effort [0] we noticed that
liblopsub could not be built reproducibly.

This is because it calls "gzip" manually without the -n
flag. This should have been reported by lintian via the
package-contains-timestamped-gzip tag.

  [0] https://reproducible-builds.org/

diff --git a/Makefile b/Makefile
index d1f89b1..e8fb7c0 100644
--- a/Makefile
+++ b/Makefile
@@ -18,7 +18,7 @@ AR := ar
 GROFF := groff
 CP := cp
 INSTALL := install
-GZIP := gzip -f9
+GZIP := gzip -fn9
 ZCAT := zcat
 
 DATE_FMT := +%B %Y
diff --git a/debian/rules b/debian/rules
index 3ba7a74..3e73eac 100755
--- a/debian/rules
+++ b/debian/rules
@@ -49,8 +49,8 @@ binary: build
$(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright
$(INST_FILE) debian/changelog $(DOCS_DIR)/changelog.Debian
$(INST_FILE) debian/changelog $(DEVDOCS_DIR)/changelog.Debian
-   gzip -f9 $(DOCS_DIR)/changelog.Debian
-   gzip -f9 $(DEVDOCS_DIR)/changelog.Debian
+   gzip -fn9 $(DOCS_DIR)/changelog.Debian
+   gzip -fn9 $(DEVDOCS_DIR)/changelog.Debian
dh_makeshlibs
dh_shlibdeps
dh_strip
-- 
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1036113: libpurple0: license conflict with libsasl2


Bastian,

I see you have raised the severity on this bug again.

What is your goal here?

Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500. 
Quickly taking that list through UDD gives me just over 4,500 source 
packages. Surely, a large number of those are going to be GPL licensed. 
Is your plan to file Severity: serious bugs against all of them?


  If so, isn't that an MBF that needs discussion on debian-devel first?

  If not, then why are you singling out Pidgin, a project that is
  struggling to stay alive right now?

Your position in bug #996892 is that cyrus-sasl2 / libsasl2 should be 
considered a system library. If libsasl2 can be considered a system 
library, then by your own position, there is no bug in libpurple0. I 
don't see how you can have it both ways.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996892: cyrus-sasl2: consider handling as system library


On 2023-06-27 16:19, Richard Laager wrote:
For RSA-MD, I'd imagine there are other MD5 implementations that could 
be dropped in relatively easily.


Also, Bastian Germann mentioned in bug #1036113:

"See https://github.com/cyrusimap/cyrus-sasl/issues/513 for an 
implementation that leaves only one RSA-MD licensed file."


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996892: cyrus-sasl2: consider handling as system library


On Thu, 13 Apr 2023 14:36:12 +0200 Bastian Germann  wrote:

Hi Philipp,

Thanks for clarifying that. There is one file in cyrus-sasl2 that is licensed under BSD-4-clause-KTH (which really has 
an advertisement clause), which we can get rid of; see https://github.com/cyrusimap/cyrus-sasl/pull/724.


The OpenSSL license can be eliminated by repackaging.

This leaves us with the two supposedly GPL-incompatible licenses 
BSD-3-Clause-Attribution and RSA-MD.


For RSA-MD, I'd imagine there are other MD5 implementations that could 
be dropped in relatively easily.


For BSD-3-Clause-Attribution, as anyone reached out to CMU (e.g. at 
tech-trans...@andrew.cmu.edu) to ask them to remove clause 3, like the 
University of California, Berkeley did in 1999:


https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22)

https://www.freebsd.org/copyright/license/

--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039579: gnome-terminal.wrapper does not support the '--' syntax itself

2023-06-27 Thread Christophe Lohr


Dear Simon,
  Thank you very much for your quick and comprehensive explanations. 
(Could be a manpage by itself!)


Indeed, I'm scripting some tasks needing a terminal in an agnostic way. 
So, 'x-terminal-emulator -e ...' is the best way for me.


I am grateful for your guidance.

Best regards,
Christophe

Le 27/06/2023 à 15:13, Simon McVittie a écrit :

On Tue, 27 Jun 2023 at 14:11:35 +0200, Christophe Lohr wrote:

   The code of this wrapper make several rearrangements to convert '-e' and '-x'
options into the '--' syntax, but it seems to not support itself the '--'
syntax on its command line. Isn't it?
Is this an oversight or I am wrong?
May I suggest adding support for "--"?

Please could you clarify why it would be useful for gnome-terminal.wrapper
to support the "--" syntax?

The only purpose of gnome-terminal.wrapper is to implement Debian's
x-terminal-emulator interface as defined in
,
which is a subset of xterm's command-line interface and therefore uses
"-e" to prefix a command to run. xterm does not support the GNU-style "--"
and there is no guarantee that an implementation of x-terminal-emulator
will support it either, so accepting it in gnome-terminal.wrapper
would just make it a bit more likely for people to write calls like
"x-terminal-emulator -- less /etc/hosts" which will actually only work
for a few specific terminal emulators.

If you're writing code that runs gnome-terminal (specifically) as a
subprocess, please use the gnome-terminal command and its preferred
"--" syntax.  There is no need to use the wrapper in this case, and in
fact it would be counterproductive to do so: all it does is to slow down
startup a little bit, and make some features unavailable.

If you're writing code that runs the generic x-terminal-emulator command
as a subprocess, then you will have to use the "-e" syntax, otherwise it
won't work correctly with xterm (and probably many other terminal emulators).

If you're writing code that supports multiple specific commands as ways
to run a command in a terminal, then it needs to "just know" whether
each one expects "-e", "-x", "--", or no argument at all. The table of
known terminals in

is an example of this technique. Everyone involved recognises that this
is not a pleasant interface, but that's the price we pay for portability.

 smcv

Bug#1009071: closed by matthias.geiger1...@tutanota.de ()

2023-06-27 Thread Jeremy Bícha

Jonas,

I don't understand why you reopened this bug. The NMU was done for
Debian 12 and Testing. There is a new major release in Unstable that
doesn't suffer from the bug the NMU was designed to fix. (It has a
different bug but there is already an RC bug for it.)

I don't see any action Maintainers can do here…except close this bug.

Admittedly, the new release in Unstable happened today so maybe the
situation has changed after the bug was reopened.

Thank you,
Jeremy Bícha

Bug#1039503: wrongly splits up extended grapheme clusters (like certain emoji)

2023-06-27 Thread Steinar H. Gunderson

On Tue, Jun 27, 2023 at 12:49:53AM +0200, Steinar H. Gunderson wrote:
> The attached patch seems to get us halfway there; screen now combines all of
> them correctly into one cluster. However, it's still split for whatever
> reason; only if I redraw (C-a l) the flag shows up, and the text breaking is
> wrong, so I assume there's at least something wrong with the width
> calculation, and possibly lots of other things I've not thought of. :-)

Version 2 of the patch; this seems to actually work. Only lightly tested,
though, and there are enough subtleties in the code that it probably needs
review from someone who knows screen from before.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
diff -ur /home/sesse/nmu/orig/screen-4.9.0/ansi.c ../ansi.c
--- /home/sesse/nmu/orig/screen-4.9.0/ansi.c	2023-06-27 22:53:44.0 +0200
+++ ../ansi.c	2023-06-27 23:00:26.667216364 +0200
@@ -694,9 +694,9 @@
 		}
 		  curr->w_rend.font = 0;
 		}
-	  if (curr->w_encoding == UTF8 && c >= 0x0300 && utf8_iscomb(c))
+	  if (curr->w_encoding == UTF8 && c >= 0x0300)
 		{
-		  int ox, oy;
+		  int ox, oy, c_prev;
 		  struct mchar omc;
 
 		  ox = curr->w_x - 1;
@@ -718,15 +718,35 @@
 			  omc.mbcs = 0xff;
 			}
 		}
-		  if (ox >= 0)
-		{
-		  utf8_handle_comb(c, );
-		  MFixLine(curr, oy, );
-		  copy_mchar2mline(, >w_mlines[oy], ox);
-		  LPutChar(>w_layer, , ox, oy);
-		  LGotoPos(>w_layer, curr->w_x, curr->w_y);
-		}
-		  break;
+  c_prev = omc.image | (omc.font << 8) | omc.fontx << 16;
+  if (!grapheme_cluster_break(c_prev, c))
+{
+		  if (ox >= 0)
+		{
+		  utf8_handle_comb(c, );
+		  MFixLine(curr, oy, );
+		  copy_mchar2mline(, >w_mlines[oy], ox);
+  if (!utf8_isdouble(c_prev) &&
+  utf8_isdouble(omc.image | (omc.font << 8) | omc.fontx << 16))
+{
+  /* A combining character switched us from single-width to double-width.
+ Do what the w_mbcs = 0xff path would have done below if the character
+ was double-width to begin with. */
+  omc.mbcs = 0xff;
+  if (ox < cols - 1)
+{
+		  curr->w_mlines[oy].image[ox + 1] = 0xff;
+		  curr->w_mlines[oy].font[ox + 1] = 0xff;
+		  curr->w_mlines[oy].fontx[ox + 1] = 0;
+		  curr->w_x++;
+}
+   }
+		  LPutChar(>w_layer, , ox, oy);
+		  LGotoPos(>w_layer, curr->w_x, curr->w_y);
+		}
+		  break;
+}
+  /* fall through */
 		}
 #  ifdef DW_CHARS
 		if (curr->w_encoding == UTF8 && utf8_isdouble(c))
diff -ur /home/sesse/nmu/orig/screen-4.9.0/encoding.c ../encoding.c
--- /home/sesse/nmu/orig/screen-4.9.0/encoding.c	2023-06-27 22:53:44.0 +0200
+++ ../encoding.c	2023-06-27 22:57:29.386767268 +0200
@@ -1215,6 +1233,398 @@
   return bisearch(c, combining, sizeof(combining) / sizeof(struct interval) - 1);
 }
 
+static bool
+is_grapheme_extend(c)
+int c;
+{
+  /* https://unicode.org/Public/15.0.0/ucd/DerivedCoreProperties.txt */
+  static const struct interval grapheme_extend[] = {
+{ 0x0300, 0x036F }, { 0x0483, 0x0487 }, { 0x0488, 0x0489 }, 
+{ 0x0591, 0x05BD }, { 0x05BF, 0x05BF }, { 0x05C1, 0x05C2 }, 
+{ 0x05C4, 0x05C5 }, { 0x05C7, 0x05C7 }, { 0x0610, 0x061A }, 
+{ 0x064B, 0x065F }, { 0x0670, 0x0670 }, { 0x06D6, 0x06DC }, 
+{ 0x06DF, 0x06E4 }, { 0x06E7, 0x06E8 }, { 0x06EA, 0x06ED }, 
+{ 0x0711, 0x0711 }, { 0x0730, 0x074A }, { 0x07A6, 0x07B0 }, 
+{ 0x07EB, 0x07F3 }, { 0x07FD, 0x07FD }, { 0x0816, 0x0819 }, 
+{ 0x081B, 0x0823 }, { 0x0825, 0x0827 }, { 0x0829, 0x082D }, 
+{ 0x0859, 0x085B }, { 0x0898, 0x089F }, { 0x08CA, 0x08E1 }, 
+{ 0x08E3, 0x0902 }, { 0x093A, 0x093A }, { 0x093C, 0x093C }, 
+{ 0x0941, 0x0948 }, { 0x094D, 0x094D }, { 0x0951, 0x0957 }, 
+{ 0x0962, 0x0963 }, { 0x0981, 0x0981 }, { 0x09BC, 0x09BC }, 
+{ 0x09BE, 0x09BE }, { 0x09C1, 0x09C4 }, { 0x09CD, 0x09CD }, 
+{ 0x09D7, 0x09D7 }, { 0x09E2, 0x09E3 }, { 0x09FE, 0x09FE }, 
+{ 0x0A01, 0x0A02 }, { 0x0A3C, 0x0A3C }, { 0x0A41, 0x0A42 }, 
+{ 0x0A47, 0x0A48 }, { 0x0A4B, 0x0A4D }, { 0x0A51, 0x0A51 }, 
+{ 0x0A70, 0x0A71 }, { 0x0A75, 0x0A75 }, { 0x0A81, 0x0A82 }, 
+{ 0x0ABC, 0x0ABC }, { 0x0AC1, 0x0AC5 }, { 0x0AC7, 0x0AC8 }, 
+{ 0x0ACD, 0x0ACD }, { 0x0AE2, 0x0AE3 }, { 0x0AFA, 0x0AFF }, 
+{ 0x0B01, 0x0B01 }, { 0x0B3C, 0x0B3C }, { 0x0B3E, 0x0B3E }, 
+{ 0x0B3F, 0x0B3F }, { 0x0B41, 0x0B44 }, { 0x0B4D, 0x0B4D }, 
+{ 0x0B55, 0x0B56 }, { 0x0B57, 0x0B57 }, { 0x0B62, 0x0B63 }, 
+{ 0x0B82, 0x0B82 }, { 0x0BBE, 0x0BBE }, { 0x0BC0, 0x0BC0 }, 
+{ 0x0BCD, 0x0BCD }, { 0x0BD7, 0x0BD7 }, { 0x0C00,

Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt


Control: tag -1 patch

On 27/06/2023 19.21, Richard Lewis wrote:

header.txt has not been modified since 2015.


I've found three versions (with sightly different spelling):
* lenny
* squeeze, wheezy, jessie
* stretch .. today


it is a simple yext file that is installed with debian/logcheck.install

the only change is that it used to be installed into /usr/share but got
moved to /etc to be a conffile in 2021. This didnt trigger any piuparts
issues and there was no change to the contents of header.txt.


It has been copied during initial install only and was never upgraded. 
If the system was installed before stretch, the header.txt does not 
match the current one and dpkg will complain when replacing it with a 
proper conffile.



So i dont understand how piuparts found an issue - is it possible to tell
us what difference piuparts actually detected?


dpkg found that the files are different. This is a non-default piuparts 
test, testing every package starting from jessie (or even earlier) and 
upgrading release by release to testing takes a lot of time (and didn't 
finish before the release happened), but sometimes reveals interesting 
things ;-)


Attached patch should fix this long upgrade path. The preinst checks 
whether header.txt matches a known shipped (but not current) variant and 
tries to update it to the current variant. It seems to work fine when 
starting from jessie, more tests will be running over night.


Andreas

PS: please don't mix this fix with other changes not intended for 
bookworm, s.t. it can go to sid as 1.4.3 and be rebuilt for bookworm as 
1.4.3~deb12u1 in order not to break the version constraintsFrom 869fcc671751e3a5309848541df2d82744cdfba8 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Tue, 27 Jun 2023 21:29:06 +0200
Subject: [PATCH] update ancient header.txt in preinst

---
 debian/changelog|  8 
 debian/logcheck.preinst | 21 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/logcheck.preinst

diff --git a/debian/changelog b/debian/changelog
index 3c46c56e..567896a7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+logcheck (1.4.3) UNRELEASED; urgency=medium
+
+  * Add logcheck.preinst to upgrade header.txt if it matches a known shipped
+version predating stretch to avoid dpkg complaining about a modified
+conffile.  (Closes: #1039591)
+
+ -- Andreas Beckmann   Tue, 27 Jun 2023 20:05:42 +0200
+
 logcheck (1.4.2) unstable; urgency=medium
 
   * More explicitly mention the default checking of the systemd journal
diff --git a/debian/logcheck.preinst b/debian/logcheck.preinst
new file mode 100644
index ..a2bc04d0
--- /dev/null
+++ b/debian/logcheck.preinst
@@ -0,0 +1,21 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = "install" ] || [ "$1" = "upgrade" ]; then
+	if dpkg --compare-versions "$2" lt-nl "1.4.3~" ; then
+		# Update /etc/logcheck/header.txt if it matches a known
+		# shipped version predating stretch to avoid dpkg
+		# complaining about a modified conffile
+		if [ -f "/etc/logcheck/header.txt" ] && [ -f "/usr/share/logcheck/header.txt" ]; then
+			# d9206d89f2f8d85d346a23da90459862 (lenny)
+			# a32fc12d69628d96756fd3af3f8b3ecd (squeeze-jessie)
+			md5=$(md5sum "/etc/logcheck/header.txt" | awk '{print $1}')
+			if [ "$md5" = "d9206d89f2f8d85d346a23da90459862" ] ||
+			   [ "$md5" = "a32fc12d69628d96756fd3af3f8b3ecd" ]; then
+cp -p -v /usr/share/logcheck/header.txt /etc/logcheck
+			fi
+		fi
+	fi
+fi
+
+#DEBHELPER#
-- 
2.20.1

Bug#1038000: bookworm-pu: package texlive-bin/2022.20220321.62855-5.1+deb12u1

2023-06-27 Thread Preuße


On 26.06.2023 07:56, Jonathan Wiltshire wrote:

Control: tag -1 confirmed


Hello,


On Thu, Jun 15, 2023 at 12:09:55PM +0200, Hilmar Preusse wrote:

* Stop building *jit* binaries on i386 based arches to make TL installable
   on computers not supporting sse2 (Closes: #1035461).
* Add patch for CVE-2023-32668: disable socket in luatex by default
   (Closes: #1036470).


Please go ahead.



Done.

Hilmar
--
sigfault



OpenPGP_0x0C871C4C653C1F59.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039619: wcc: reproducible-builds: embedded build path in various binaries

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

The build path is embedded in various binaries:

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

  /usr/bin/wcc

  /build/1st/wcc-0.0.2+dfsg/src/wcc/wcc.c:3989
  vs.
  /build/2/wcc-0.0.2+dfsg/2nd/src/wcc/wcc.c:3989

The attached patches fix this by appending EXTRA_CFLAGS to CFLAGS in the
upstream Makefile, and the second patch passes CFLAGS via EXTRA_CFLAGS
in debian/rules. The Default CFLAGS include -ffile-prefix-map to avoid
embedding the build path.

According to my local tests, with these patches applied, wcc should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining wcc!

live well,
  vagrant
From 1490de0c3bcb0a088c013b390d267cb0763e202a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 13:40:18 -0700
Subject: [PATCH 1/2] Makefile: Append CFLAGS_EXTRA to CFLAGS.

---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 55e2d3f..306d129 100644
--- a/Makefile
+++ b/Makefile
@@ -8,6 +8,7 @@
 #
 
 CFLAGS := -W -Wall -Wno-discarded-qualifiers -Wno-int-conversion -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -fpie -pie -fPIC -g3 -ggdb -I../../include  -I./include/sflib/ -I./include -I../../include/  -Wno-incompatible-pointer-types  -fstack-protector-all -Wl,-z,relro,-z,now -DPACKAGE -DPACKAGE_VERSION -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2
+CFLAGS += $(CFLAGS_EXTRA)
 
 all:
 	mkdir -p bin
-- 
2.39.2

From 4b0d7aa287e7a324fbea6a05d8db9b673e0efb7c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 13:41:41 -0700
Subject: [PATCH 2/2] debian/rules: Pass CFLAGS via CFLAGS_EXTRA in
 dh_auto_build.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 80f6c6d..b6d5cb6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,9 @@ override_dh_fixperms:
 	chmod 644 debian/wcc/usr/share/wcc/scripts/debug
 	dh_fixperms
 
+override_dh_auto_build:
+	CFLAGS_EXTRA="$(CFLAGS)" dh_auto_build
+
 %:
 	dh $@
 
-- 
2.39.2



signature.asc
Description: PGP signature

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

2023-06-27 Thread Sebastian Andrzej Siewior

On 2023-06-26 18:10:57 [+0100], Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> You're both going to have to help me a) understand what is the user-facing
> problem you're solving which is necessary to fix in stable and b) whether
> you're both agreed on how to fix it.

a) The bpo of manpages-de and manpages-fr contains a manpage for xz. The
   regular (non-bpo) package does not contain such the man-page nor does
   the package in the following stable contain this man-page.
   The user facing problem is the installation of both
   manpages-de|manpages-fr and xz-utils/5.2.11-0~deb11u1 because both
   provide the same man-page/file and dpkg doesn't like that.

b) I *think* we agreed on removing the man-pages from bpo of
   manpages-[de|fr] in the next upload if the upload of
   xz-utils/5.2.11-0~deb11u1 is confirmed. Otherwise it makes no sense
   to anything, the upgrade path bpo -> next-stable is working due to
   proper package relations.

> Thanks,

Sebastian

Bug#1039105: I can confirm this bug, fix works for me

2023-06-27 Thread Dirk Eddelbuettel



Hi Thomas,

On 27 June 2023 at 22:05, Thomas Lange wrote:
| Hi Dirk,
| 
| I'm a vm user for reading my mail.

So there's two of us!  :-)

| Thanks a lot for this bug report and fix. It also works for me.
| Patching /etc/emacs/site-start.d/50vm-init.el still compiles vm-vars
| and vm-version, but I can start the VM mode and read my mails with
| emacs 28 using bookworm.

I never quite grok'ed what the deal is with the identical 50vm.el and
50vm-init.el. Other packages don't do that. (But I think I no longer maintain
anything that ships .el code so I no longer look at the these much.)
 
| After this first test, I can upgrade my computer to bookworm. Yeah!

I am actually enjoying Emacs 28 quite a bit since the update. Feels snappier.

Very minor issues: The "theme" / "face" is a little off for me (I tend to run
both under x11/wayland and inside byobu/tmux and the latter is little
difference). And when running in daemon mode `emacsclient -c` no longer
starts an initial frame so I am back to old school server-start.
 
| I vote for adding this fix into a new vm version for bookworm proposed
| updates.

Yes. Have not heard yet from the maintainer but it would be good to add this,
and of course figure out why it balks with elisp compilation.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1039105: I can confirm this bug, fix works for me

2023-06-27 Thread Thomas Lange

Hi Dirk,

I'm a vm user for reading my mail.
Thanks a lot for this bug report and fix. It also works for me.
Patching /etc/emacs/site-start.d/50vm-init.el still compiles vm-vars
and vm-version, but I can start the VM mode and read my mails with
emacs 28 using bookworm.

After this first test, I can upgrade my computer to bookworm. Yeah!

I vote for adding this fix into a new vm version for bookworm proposed
updates.

-- 
reagrds Thomas

Bug#1039618: liblopsub: reproducible-builds: embedded build path in lopsubgen

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

The build path is embedded in /usr/bin/lopsubgen:

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

  /build/1st/liblopsub-1.0.3/lopsubgen.c:49
  vs.
  /build/2/liblopsub-1.0.3/2nd/lopsubgen.c:49

The attached patch fixes this by passing the -ffile-prefix-map argument
to the compiler in the upstream Makefile.

According to my local tests, with this patch and the recently submitted
timestamp patches applied, liblopsub should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining liblopsub!

live well,
  vagrant
From 06ed531c6a0a96a82441c8042ef338ac7d07d773 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 12:43:31 -0700
Subject: [PATCH 3/3] Makefile: Add -ffile-prefix-map to CC to avoid embedding
 build paths.

---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index f139597..f0cf614 100644
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,8 @@ INSTALL := install
 GZIP := gzip -n -f9
 ZCAT := zcat
 
+CC += -ffile-prefix-map=$(CURDIR)=.
+
 DATE_FMT := +%B %Y
 # To get a reproducible build, we use $(SOURCE_DATE_EPOCH) instead of the
 # current time if this variable is set.
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1039617: liblopsub: reproducible-builds: timestamps in gzip headers for changelog and manpage

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

The build timestamp is included in various gzip headers:

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

  /usr/share/doc/liblopsub-dev/changelog.Debian.gz

  
gzip·compressed·data,·was·"changelog.Debian",·last·modified:·Mon·May·20·01:26:32·2024,·max·compression,·from·Unix
  vs.
  
gzip·compressed·data,·was·"changelog.Debian",·last·modified:·Mon·Apr·17·19:04:49·2023,·max·compression,·from·Unix

  /usr/share/man/man1/lopsubgen.1.gz

  
gzip·compressed·data,·was·"lopsubgen.1",·last·modified:·Mon·May·20·01:26:29·2024,·max·compression,·from·Unix
  vs.
  
gzip·compressed·data,·was·"lopsubgen.1",·last·modified:·Mon·Apr·17·19:04:45·2023,·max·compression,·from·Unix

The attached two patches (one patching the upstream Makefile, the other
patching debian/rules) fix this by passing -n to the gzip calls used to
compress changelog.Debian and the various manpages.

According to my local tests, with these two patches applied liblopsub
should build reproducibly on tests.reproducible-builds.org once it
migrates to debian/trixie! This alone does not resolve all
reproducibilitiy issues (e.g. build paths, tested in unstable and
experimental).

Thanks for maintaining liblopsub!

live well,
  vagrant
From f92b3e462e3665bf1a4f8469ddd5ebf0c19f3f26 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 12:41:36 -0700
Subject: [PATCH 1/3] Makefile: Pass -n to gzip to avoid embedding timestamps.

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index d1f89b1..f139597 100644
--- a/Makefile
+++ b/Makefile
@@ -18,7 +18,7 @@ AR := ar
 GROFF := groff
 CP := cp
 INSTALL := install
-GZIP := gzip -f9
+GZIP := gzip -n -f9
 ZCAT := zcat
 
 DATE_FMT := +%B %Y
-- 
2.39.2

From e95dc3bf4cf0beb6afdd23a34c9b7923ffbd0c24 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 12:42:16 -0700
Subject: [PATCH 2/3] debian/rules: Pass -n to gzip to avoid embedding
 timestamps.

---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 3ba7a74..1263826 100755
--- a/debian/rules
+++ b/debian/rules
@@ -49,8 +49,8 @@ binary: build
 	$(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright
 	$(INST_FILE) debian/changelog $(DOCS_DIR)/changelog.Debian
 	$(INST_FILE) debian/changelog $(DEVDOCS_DIR)/changelog.Debian
-	gzip -f9 $(DOCS_DIR)/changelog.Debian
-	gzip -f9 $(DEVDOCS_DIR)/changelog.Debian
+	gzip -n -f9 $(DOCS_DIR)/changelog.Debian
+	gzip -n -f9 $(DEVDOCS_DIR)/changelog.Debian
 	dh_makeshlibs
 	dh_shlibdeps
 	dh_strip
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1036314: bullseye-pu: package mujs/1.1.0-1+deb11u3

Control: tag -1 confirmed

On Fri, May 19, 2023 at 10:58:10AM +0200, Bastian Germann wrote:
> [ Reason ]
> https://security-tracker.debian.org/tracker/CVE-2021-33797
> Buffer-overflow via integer overflow.

A bug number in the changelog would be nice if there is one, but go ahead
either way.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1036043: boxer-data 10.8.28+deb11u1 flagged for acceptance

package release.debian.org
tags 1036043 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: boxer-data
Version: 10.8.28+deb11u1

Explanation: backport thunderbird compatibility fixes

Bug#1039606: Don't display unimportant issues as "vulnerable"

2023-06-27 Thread Jeffrey Walton

On Tue, Jun 27, 2023 at 2:36 PM Moritz Muehlenhoff  wrote:
>
> Package: security-tracker
> Severity: wishlist
>
> "unimportant" issues don't have security impact, but currently they get shown
> as "vulnerable" in red, both in a package overview page, e.g.
> https://security-tracker.debian.org/tracker/source-package/c-ares and 
> CVE-specific pages, e.g.
> https://security-tracker.debian.org/tracker/CVE-2023-31147

Be careful with trying to classify as important (security related) and
unimportant (not security related). It depends on proper
classification, and that does not always happen. Folks missed the
unimportant TTY1 layer bug for years until it became a CVE. CF.,
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
.

I've also seen CVE-worthy bugs go without a CVE because someone could
not get the form on mitre.org to submit. At release time the Changelog
just said, "fixed bug XXX. This probably should have gotten a CVE."

And finally, many developers just fix important bugs without giving
them much thought. Fix it, check-in, move onto the next bug. No time
to analyze impact. In the past, I've cleared some memory problems and
wondered if someone could exploit them.

> This is a little misleading, since those packages are not actually vulnerable.
> It would be nice if such "unimportant" issues it would instead display
> "unfixed (no/negligible security impact)" instead. And instead of red maybe
> in grey.

Grey or orange might make a good choice to differentiate them from
important or security updates. Grey almost feels like "disabled" and
you won't be acting on it. Maybe orange would be the better choice.

Jeff

Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1

Control: tag -1 confirmed


This is much more palatable, thank you for persevering with it.

On Mon, Jun 26, 2023 at 08:18:35PM +0200, Francesco P. Lovergine wrote:
> diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 
> proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
> --- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS  2023-03-13 
> 12:24:28.0 +0100
> +++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS  2023-06-22 
> 11:15:57.0 +0200
> @@ -1,3 +1,16 @@
> +proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
> +
> +If you upgrade from 1.3.8+dfsg-4 (i.e. th 12.0 edition of bookworm) note

Tiny typo at "the". Otherwise it looks fine, please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039615: ssh/_scp_remote_files adds to many backslashes for rsync

2023-06-27 Thread Uwe Kleine-König

Package: bash-completion
Version: 1:2.11-6
Severity: normal
X-Debbugs-Cc: uklei...@debian.org

Hello,

uwe@taurus:~$ echo content > 'file with space'

After that 

uwe@taurus:~$ rsync localhost:fil

completes to:

uwe@taurus:~$ rsync localhost:file\\\ with\\\ space 

. Adding a target path and pressing Enter then results in:

uwe@taurus:~$ rsync localhost:file\\\ with\\\ space /tmp
rsync: [sender] link_stat "/home/uwe/file\ with\ space" failed: No such 
file or directory (2)
rsync error: some files/attrs were not transferred (see previous 
errors) (code 23) at main.c(1865) [Receiver=3.2.7]
rsync: [Receiver] write error: Broken pipe (32)

The right quoting is:

uwe@taurus:~$ rsync localhost:file\ with\ space /tmp

Interesting side note:

uwe@taurus:~$ scp localhost:file\\\ with\\\ space /tmp
uwe@taurus:~$ scp localhost:file\ with\ space /tmp
uwe@taurus:~$ scp localhost:file\ with\\\ space /tmp

all result in the same file being transferred.

Best regards
Uwe

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

Kernel: Linux 6.1.0-9-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

-- no debconf information

Bug#1039614: python-can: autopkgtest regression on amd64 and s390x: KeyError: 'link_type'


Source: python-can
Version: 4.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-can the autopkgtest of python-can fails 
in testing when that autopkgtest is run with the binary packages of 
python-can from unstable on amd64 or s390x. It passes when run with only 
packages from testing. In tabular form:


   passfail
python-can from testing4.2.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-can

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-can/34896619/log.gz

=== FAILURES 
===
 64s __ TestDetectAvailableConfigs.test_content_socketcan 
___
 64s  64s self = 
testMethod=test_content_socketcan>

 64s  64s def test_content_socketcan(self):
 64s >   configs = detect_available_configs(interfaces="socketcan")
 64s  64s test_detect_available_configs.py:44:  64s _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  64s 
/usr/lib/python3/dist-packages/can/interface.py:186: in 
detect_available_configs
 64s bus_class._detect_available_configs()  # pylint: 
disable=protected-access
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/socketcan.py:878: 
in _detect_available_configs

 64s for channel in find_available_interfaces()
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: in 
find_available_interfaces
 64s interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]
 64s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _  64s  64s .0 = 
 64s  64s >   interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]

 64s E   KeyError: 'link_type'
 64s  64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: 
KeyError
 64s  TestDetectAvailableConfigs.test_count_returned 

 64s  64s self = 
testMethod=test_count_returned>

 64s  64s def test_count_returned(self):
 64s # At least virtual has to always return at least one interface
 64s >   self.assertGreaterEqual(len(detect_available_configs()), 1)
 64s  64s test_detect_available_configs.py:18:  64s _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  64s 
/usr/lib/python3/dist-packages/can/interface.py:186: in 
detect_available_configs
 64s bus_class._detect_available_configs()  # pylint: 
disable=protected-access
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/socketcan.py:878: 
in _detect_available_configs

 64s for channel in find_available_interfaces()
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: in 
find_available_interfaces
 64s interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]
 64s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _  64s  64s .0 = 
 64s  64s >   interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]

 64s E   KeyError: 'link_type'
 64s  64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: 
KeyError
 64s  TestDetectAvailableConfigs.test_general_values 

 64s  64s self = 
testMethod=test_general_values>

 64s  64s def test_general_values(self):
 64s >   configs = detect_available_configs()
 64s  64s test_detect_available_configs.py:27:  64s _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  64s 
/usr/lib/python3/dist-packages/can/interface.py:186: in 
detect_available_configs
 64s bus_class._detect_available_configs()  # pylint: 
disable=protected-access
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/socketcan.py:878: 
in _detect_available_configs

 64s for channel in find_available_interfaces()
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: in 
find_available_interfaces
 64s interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]
 64s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _  64s  64s .0 = 
 64s  64s >   interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]

 64s E   KeyError: 'link_type'
 64s  64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: 
KeyError
 64s === short test summary info 

 64s FAILED

Bug#1039609: bookworm-pu: package sudo/1.9.13p3-1+deb12u1

Control: tag -1 confirmed

On Tue, Jun 27, 2023 at 09:17:36PM +0200, Marc Haber wrote:
> this pre-upload request for the sudo package is filed to ask for
> guidance whether this package is suitable for bookworm-proposed-updates.
> 
> [ Reason ]
> This upload fixes the broken log format of "ENV=..." event logging, Bug
> #1039557. This is an upstream regression since bullseye. The patch
> being applied is from Upstream, is already in unstable (since today),
> and will also be part of the next upstream release.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1039612: libtool: Incorrect check for += operator causes func_append to fail

2023-06-27 Thread Ernesto Alfonso

Package: libtool
Version: 2.4.6-15
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: erjoa...@gmail.com

Dear Maintainer,

While building isc-dhcpd-server, I tried using autoreconf as per instructions
to generate the ./configure file.
But running `autoreconf -i` on this project failed with this error:

/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
libtoolize:   error: 'func_options_prep' does not accept hook functions.
autoreconf: libtoolize failed with exit status: 1

Some others have reported this error, but the solution mentioned in that thread
was to run as root, which I shouldn't have to do to build in a local directory:

https://github.com/libsndfile/libsndfile/issues/132#issue-153391414

Looking at the source, I noticed the problem is not that
`func_options_prep does not accept hook functions`,
but that the script assumes the append operator `+=` works when it doesn't.

This assumption is based on the value of BASH_VERSION, but unfortunately this 
is not reliable:


if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then
: ${_G_HAVE_ARITH_OP="yes"}
: ${_G_HAVE_XSI_OPS="yes"}
# The += operator was introduced in bash 3.1
case $BASH_VERSION in
  [12].* | 3.0 | 3.0*) ;;
  *)
: ${_G_HAVE_PLUSEQ_OP="yes"} # not really!
;;
esac
  fi


It's not reliable because on my system, plain debian 11, /bin/sh is linked to
/usr/bin/dash, but the BASH_VERSION environment variable appears to have been
inherited from the bash process on my terminal and it is not
modified or deleted by dash. And += doesn't work in dash:

█[debian-x1-7th][isc-dhcp-4.4.1][0]$ ls -l /usr/bin/sh
lrwxrwxrwx 1 root root 4 Apr 27 17:06 /usr/bin/sh -> dash
█[debian-x1-7th][isc-dhcp-4.4.1][130]$ dash
\[\]█\[\][\h][\W][0]$ \[\]echo $BASH_VERSION
5.1.4(1)-release
\[\]█\[\][\h][\W][0]$ \[\]a=1
\[\]█\[\][\h][\W][0]$ \[\]a+=2
dash: 3: a+=2: not found
\[\]█\[\][\h][\W][127]$ \[\]


There's some advice online about how to find the true name of the shell:
https://stackoverflow.com/questions/23011370/ but I think it is too
complicated and error prone, and I think
the simplest way to correct this is to actually test for the feature directly
as is already being done in the script:

(eval 'x=a; x+=" b"; test "a b" = "$x"') && _G_HAVE_PLUSEQ_OP=yes


There is a comment expressing concern about speed of the test above and about
minimizing forks:


# We should try to minimise forks, especially on Windows where they are
# unreasonably slow, so skip the feature probes when bash or zsh are
# being used:

But I don't see any reason for needing a fork here:

if test -z "$_G_HAVE_PLUSEQ_OP" &&  \
__PLUSEQ_TEST="a" &&  \
__PLUSEQ_TEST+=" b" 2>/dev/null &&  \
test "a b" = "$__PLUSEQ_TEST"; then
  _G_HAVE_PLUSEQ_OP=yes
fi


Even if a fork were needed, I don't think the possible speedup of avoiding the
a one-line feature probe is worth the risk of breaking users who
invoke this script from a parent bash terminal.

I'm including my suggested patch inline below:


527,547c527,535
<   # We should try to minimise forks, especially on Windows where they are
<   # unreasonably slow, so skip the feature probes when bash or zsh are
<   # being used:
<   if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then
< : ${_G_HAVE_ARITH_OP="yes"}
< : ${_G_HAVE_XSI_OPS="yes"}
< # The += operator was introduced in bash 3.1
< case $BASH_VERSION in
<   [12].* | 3.0 | 3.0*) ;;
<   *)
< : ${_G_HAVE_PLUSEQ_OP="yes"}
< ;;
< esac
<   fi
< 
<   # _G_HAVE_PLUSEQ_OP
<   # Can be empty, in which case the shell is probed, "yes" if += is
<   # useable or anything else if it does not work.
<   test -z "$_G_HAVE_PLUSEQ_OP" \
< && (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null \
< && _G_HAVE_PLUSEQ_OP=yes
---
> # _G_HAVE_PLUSEQ_OP
> # Can be empty, in which case the shell is probed, "yes" if += is
> # usable or anything else if it does not work.
> if test -z "$_G_HAVE_PLUSEQ_OP" &&  \
> __PLUSEQ_TEST="a" &&  \
> __PLUSEQ_TEST+=" b" 2>/dev/null &&  \
> test "$__PLUSEQ_TEST" = "a b"; then
>   _G_HAVE_PLUSEQ_OP=yes
> fi

Thanks,

Ernesto

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')

Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed


Source: nmap, udptunnel
Control: found -1 nmap/7.94+dfsg1-1
Control: found -1 udptunnel/1.1-9
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of nmap the autopkgtest of udptunnel fails in 
testing when that autopkgtest is run with the binary packages of nmap 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
nmap   from testing7.94+dfsg1-1
udptunnel  from testing1.1-9
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of nmap to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=nmap

https://ci.debian.net/data/autopkgtest/testing/amd64/u/udptunnel/34896613/log.gz

33s udp0  0 127.0.0.1:5500  0.0.0.0:*
36s tcp0  0 0.0.0.0:64910.0.0.0:* 
LISTEN
39s udp0  0 0.0.0.0:66610.0.0.0:* 
   39s 1,7d0

39s < THIS
39s <  IS
39s <   THE
39s

Bug#1039611: celery breaks python-django-celery-beat autopkgtest: 'zoneinfo.ZoneInfo' object has no attribute 'zone'


Source: celery, python-django-celery-beat
Control: found -1 celery/5.3.1-1
Control: found -1 python-django-celery-beat/2.4.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of celery the autopkgtest of 
python-django-celery-beat fails in testing when that autopkgtest is run 
with the binary packages of celery from unstable. It passes when run 
with only packages from testing. In tabular form:


  passfail
celeryfrom testing5.3.1-1
python-django-celery-beat from testing2.4.0-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of celery to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=celery

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-celery-beat/34896121/log.gz

=== FAILURES 
===
 63s _ test_ModelEntry.test_entry_is_due__no_use_tz 
_
 63s  63s self = 0x7f96b9886b90>

 63s  63s @override_settings(
 63s USE_TZ=False,
 63s DJANGO_CELERY_BEAT_TZ_AWARE=False
 63s )
 63s @pytest.mark.usefixtures('depends_on_current_app')
 63s @timezone.override('Europe/Berlin')
 63s @pytest.mark.celery(timezone='Europe/Berlin')
 63s def test_entry_is_due__no_use_tz(self):
 63s old_tz = os.environ.get("TZ")
 63s os.environ["TZ"] = "Europe/Berlin"
 63s if hasattr(time, "tzset"):
 63s time.tzset()
 63s >   assert self.app.timezone.zone == 'Europe/Berlin'
 63s E   AttributeError: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'

 63s  63s t/unit/test_schedulers.py:162: AttributeError
 63s _ 
test_ModelEntry.test_entry_and_model_last_run_at_with_utc_no_use_tz __
 63s  63s self = 0x7f96b90f5ad0>
 63s monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 
0x7f96b9364050>

 63s  63s @override_settings(
 63s USE_TZ=False,
 63s DJANGO_CELERY_BEAT_TZ_AWARE=False
 63s )
 63s @pytest.mark.usefixtures('depends_on_current_app')
 63s @timezone.override('Europe/Berlin')
 63s @pytest.mark.celery(timezone='Europe/Berlin')
 63s def test_entry_and_model_last_run_at_with_utc_no_use_tz(self, 
monkeypatch):

 63s old_tz = os.environ.get("TZ")
 63s os.environ["TZ"] = "Europe/Berlin"
 63s if hasattr(time, "tzset"):
 63s time.tzset()
 63s >   assert self.app.timezone.zone == 'Europe/Berlin'
 63s E   AttributeError: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'

 63s  63s t/unit/test_schedulers.py:194: AttributeError
 63s __ 
test_ModelEntry.test_entry_is_due__celery_timezone_doesnt_match_time_zone 
___
 63s  63s self = 0x7f96b90f5350>

 63s  63s @override_settings(
 63s USE_TZ=False,
 63s DJANGO_CELERY_BEAT_TZ_AWARE=False,
 63s TIME_ZONE="Europe/Berlin",
 63s CELERY_TIMEZONE="America/New_York"
 63s )
 63s @pytest.mark.usefixtures('depends_on_current_app')
 63s @timezone.override('Europe/Berlin')
 63s @pytest.mark.celery(timezone='America/New_York')
 63s def 
test_entry_is_due__celery_timezone_doesnt_match_time_zone(self):

 63s old_tz = os.environ.get("TZ")
 63s os.environ["TZ"] = "Europe/Berlin"
 63s if hasattr(time, "tzset"):
 63s time.tzset()
 63s >   assert self.app.timezone.zone == 'America/New_York'
 63s E   AttributeError: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'

 63s  63s t/unit/test_schedulers.py:230: AttributeError
 63s === warnings summary 
===

 63s ../../../../usr/lib/python3/dist-packages/django/http/request.py:1
 63s   /usr/lib/python3/dist-packages/django/http/request.py:1: 
DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 
3.13

 63s import cgi
 63s  63s 
../../../../usr/lib/python3/dist-packages/django/utils/encoding.py:266
 63s   /usr/lib/python3/dist-packages/django/utils/encoding.py:266: 
DeprecationWarning: Use setlocale(), getencoding() and getlocale() instead

 63s encoding = locale.getdefaultlocale()[1] or 'ascii'
 63s  63s -- Docs: 
https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 63s === short test summary info 

 63s FAILED 
t/unit/test_schedulers.py::test_ModelEntry::test_entry_is_due__no_use_tz
 63s FAILED

Bug#1039610: pnetcdf: reproducible-builds: timestamp and build path embedded pnetcdf-config

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

The build date is embedded in /usr/bin/pnetcdf-config:

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

  
CFLAGS="-g·-O2·-ffile-prefix-map=/build/1st/pnetcdf-1.12.3=.·-fstack-protector-strong...
  vs.
  
CFLAGS="-g·-O2·-ffile-prefix-map=/build/2/pnetcdf-1.12.3/2nd=.·-fstack-protector-strong...

  config_date="Mon·Jun·19·19:34:17·-12·2023"
  vs.
  config_date="Tue·Jun·20·21:34:17·+14·2023"

The attached patch fixes this by replacing these strings with
placeholder values in debian/rules.

According to my local tests, with this patch applied pnetcdf should
build reproducibly on tests.reproducible-builds.org once it migrates to
debian/trixie!  Unfortunately, there are still other outstanding issues
with build paths, which are tested in unstable or experimental.

Thanks for maintaining pnetcdf!

live well,
  vagrant
From f19bcebd1114f70775a3596b33b16f89dec26070 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 27 Jun 2023 12:16:39 -0700
Subject: [PATCH] debian/rules: Remove timestamp and build path from
 pnetcdf-config in dh_auto_install override.

https://reproducible-builds.org/docs/timestamps/
https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index d66a066..068775a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -68,3 +68,4 @@ override_dh_auto_test:
 override_dh_auto_install:
 	$(MAKE) -C build-static install DESTDIR=$(DESTDIR)
 	find $(DESTDIR) -name '*.la' -delete
+	sed -i -e 's,config_date=.*,config_date=BUILDDATE,g' -e 's,$(CURDIR),BUILDPATH,g' ./debian/tmp/usr/bin/pnetcdf-config
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1039609: bookworm-pu: package sudo/1.9.13p3-1+deb12u1

2023-06-27 Thread Marc Haber

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: s...@packages.debian.org
Control: affects -1 + src:sudo

Dear stable release team,

this pre-upload request for the sudo package is filed to ask for
guidance whether this package is suitable for bookworm-proposed-updates.

[ Reason ]
This upload fixes the broken log format of "ENV=..." event logging, Bug
#1039557. This is an upstream regression since bullseye. The patch
being applied is from Upstream, is already in unstable (since today),
and will also be part of the next upstream release.

[ Impact ]
This bug affects log parsing and filtering, for example using logcheck.
As sudo is a security relevant package, this is a rather bad bug.

[ Tests ]
Sadly, none.

[ Risks ]
This is a one-line change adding a semicolon to a log string.

[ 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
The patch adds a verbatim, static semicolon to the logging buffer.

[ Other info ]
The change is rather fresh in unstable. I am filing this pre-upload
request to make it easier for the fixed package to find its way to
the first bookworm point release which is due soon. If the time frame
was not as tight, I'd have held back this bugreport for a week, but I
think that this fix should probably be in the first point
release already.
diff -Nru sudo-1.9.13p3/debian/changelog sudo-1.9.13p3/debian/changelog
--- sudo-1.9.13p3/debian/changelog  2023-03-08 21:17:05.0 +0100
+++ sudo-1.9.13p3/debian/changelog  2023-06-27 13:45:00.0 +0200
@@ -1,3 +1,10 @@
+sudo (1.9.13p3-1+deb12u1) bookworm; urgency=medium
+
+  * add upstream patch to fix event log format.
+Thanks to Kimmo Suominen (Closes: #1039557)
+
+ -- Marc Haber   Tue, 27 Jun 2023 13:45:00 
+0200
+
 sudo (1.9.13p3-1) unstable; urgency=medium
 
   * new upstream version:
diff -Nru sudo-1.9.13p3/debian/patches/debian-bug-1039557 
sudo-1.9.13p3/debian/patches/debian-bug-1039557
--- sudo-1.9.13p3/debian/patches/debian-bug-1039557 1970-01-01 
01:00:00.0 +0100
+++ sudo-1.9.13p3/debian/patches/debian-bug-1039557 2023-06-27 
13:45:00.0 +0200
@@ -0,0 +1,14 @@
+Desciption: fix event log format with environment variables
+Origin: 
https://github.com/sudo-project/sudo/commit/12648b4e0a8cf486480442efd52f0e0b6cab6e8b
+Bug: https://github.com/sudo-project/sudo/issues/254
+Forwarded: not-needed
+--- a/lib/eventlog/eventlog.c
 b/lib/eventlog/eventlog.c
+@@ -189,6 +189,7 @@ new_logline(int event_type, int flags, s
+   sudo_lbuf_append_esc(lbuf, LBUF_ESC_CNTRL, " %s",
+   evlog->env_add[i]);
+   }
++  sudo_lbuf_append(lbuf, " ; ");
+ }
+ if (evlog->command != NULL && evlog->argv != NULL) {
+   /* Command plus argv. */
diff -Nru sudo-1.9.13p3/debian/patches/series 
sudo-1.9.13p3/debian/patches/series
--- sudo-1.9.13p3/debian/patches/series 2023-03-08 21:17:05.0 +0100
+++ sudo-1.9.13p3/debian/patches/series 2023-06-27 13:45:00.0 +0200
@@ -1,6 +1,7 @@
 # 1004909-ftbfs-kfreebsd
 # debian-bugs-1019428
 # dont-create-ChangeLog
+debian-bug-1039557
 paths-in-samples.diff
 Whitelist-DPKG_COLORS-environment-variable.diff
 sudo-ldap-docs

Bug#1039557: Confirmed fixed in sudo_1.9.13p3-3_amd64.deb

2023-06-27 Thread Kimmo Suominen

Hi,

I have downloaded and installed sudo_1.9.13p3-3_amd64.deb from
http://ftp.fi.debian.org/debian/pool/main/s/sudo/sudo_1.9.13p3-3_amd64.deb,
and can confirm the issue fixed.

Kind regards,
+ Kimmo

Bug#1039608: RM: libbaseencode -- ROM; no longer maintained

2023-06-27 Thread Francisco Vilmar Cardoso Ruviaro

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,
Please, remove the libbaseencode from unstable because it has been
deprecated since libcotp 2.0.0, as the upstream reported:

"In particular, libbaseencode has been merged with libcotp,
so now users can call base32 functions by just including cotp.h"
https://github.com/paolostivanin/libcotp/releases/tag/v2.0.0


Thanks!
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?

2023-06-27 Thread Dirk Eddelbuettel



Hi Paul,

On 27 June 2023 at 20:08, Paul Gevers wrote:
| Hi Dirk,
| 
| On 26-06-2023 22:21, Dirk Eddelbuettel wrote:
| > I really appreciate the diligence and detail you put into this.
| > 
| > But I would like to offer a simple shortcut.  I am also CCing debian-r again
| > as this has come up time and time again, is guaranteed to come up again for
| > as long as combine autopkgtests with letting packages go stake.
| 
| Somehow I feel you missed my point. In Debian we also care about 
| preventing partial upgrades doing the wrong thing. I explicitly noted 
| that in unstable everything is fine, so I think I acknowledge what you 
| said. However, for the migration to automatically happen and to 
| (possibly, I leave that for you (packages maintainers) to judge) prevent 
| issues with partial upgrades there needs to be some *versioned* package 
| relation somewhere.

I am not a fan of accomodating outdated packages in Debian by means of
imposed constraints _which then differ from perfectly viable and sane
upstream uses_ and am not here for it.  Life is too short: just under 20k
CRAN packages, (last I checked) just over 1k in Debian -- and once you allow
for "random" package combination (which, I repeat, are untested upstream in
these combinations) you essentially get yourself an infinity of possible
combinations.  There lies madness.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1030114: picom: new upstream release

2023-06-27 Thread Nikos Tsipinakis

Hi Lev,

This has been fixed for a while.

Cheers,
Nikos

Bug#1039607: libjansi-java: causes maven to always output escape character

2023-06-27 Thread Luís Picciochi Oliveira

Package: libjansi-java
Version: 2.4.0-1
Severity: normal
X-Debbugs-Cc: pitxy...@gmail.com

Dear maintainer,

I'm running commands that use the `mvn` and capture the output coming from it.

More specifically, I'm catching the version of a Maven project with a command
like the following:

  mvn --batch-mode --quiet -DforceStdout help:evaluate
-Dexpression="project.version"


Up until Debian Bullseye, the output from the command above was a single string
with only the version, as intended. For example: "1.0.0-SNAPSHOT".

After upgrading to Debian Bookworm, the `mvn` command now outputs escape
characters, regardless of the flags passed to it.
The example above has now become: "ESC[0m1.0.0-SNAPSHOTESC[0m".

I tested with the upstream Maven package of the same version, and could narrow
down the problem as coming from the libjansi-java jar.

If I downgrade it back to the Debian-packaged version 2.4.0-1, the old
behaviour is restored.

This change seems to have been due to this commit:
https://salsa.debian.org/java-
team/jansi/-/commit/7f186cd4fc22308d7769db8eeeca26b560b81b1a


You can probably reproduce this very simply with the following:
(running `mvn` anywhere should work - it doesn't have to have a Maven project
and the error message is irrelevant to reproduce what we need)

  mvn --batch-mode --quiet | less


* With libjansi-java 2.4.0-2, escape characters are seen in the output, like
so:

ESC[0m[INFO] Scanning for projects...
[INFO] 
[INFO] BUILD FAILURE
(...)
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/NoGoalSpecifiedException
ESC[0m
(END)



* With libjansi-java 2.4.0-1 (downloaded from snapshot.debian.org), escape
characters are not seen in the output:

[INFO] Scanning for projects...
[INFO] 
[INFO] BUILD FAILURE
(...)
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/NoGoalSpecifiedException
(END)


Thank you and best regards,
Luís Picciochi Oliveira


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

Kernel: Linux 6.4.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

Bug#1039606: Don't display unimportant issues as "vulnerable"

2023-06-27 Thread Salvatore Bonaccorso

Hi,

On Tue, Jun 27, 2023 at 08:33:08PM +0200, Moritz Muehlenhoff wrote:
> Package: security-tracker
> Severity: wishlist
> 
> "unimportant" issues don't have security impact, but currently they get shown
> as "vulnerable" in red, both in a package overview page, e.g.
> https://security-tracker.debian.org/tracker/source-package/c-ares and 
> CVE-specific pages, e.g.
> https://security-tracker.debian.org/tracker/CVE-2023-31147
> 
> This is a little misleading, since those packages are not actually vulnerable.
> It would be nice if such "unimportant" issues it would instead display
> "unfixed (no/negligible security impact)" instead. And instead of red maybe
> in grey.

Right agree with that. I think it would be great and helpfull if we
have an issue which is unfixed in a particular suite source wise, and
in the above example, but is in unimportant severity, then instead of
a red vulnerable, the page would show a "greyed" (similar to fixed,
but different), with a different text something like you proposed in
wording. 

I think the color difference from red is visual wise quite important,
because together with the wording 'vulnerable' is possibly what is
what people will mostly find surprising.

So whoever wants to implement that, plese make a MR accordingly to the
security-tracker repository.

Regards,
Salvatore

Bug#1039606: Don't display unimportant issues as "vulnerable"

2023-06-27 Thread Moritz Muehlenhoff

Package: security-tracker
Severity: wishlist

"unimportant" issues don't have security impact, but currently they get shown
as "vulnerable" in red, both in a package overview page, e.g.
https://security-tracker.debian.org/tracker/source-package/c-ares and 
CVE-specific pages, e.g.
https://security-tracker.debian.org/tracker/CVE-2023-31147

This is a little misleading, since those packages are not actually vulnerable.
It would be nice if such "unimportant" issues it would instead display
"unfixed (no/negligible security impact)" instead. And instead of red maybe
in grey.

Cheers,
Moritz

Bug#1039605: perltoc.1: weird formatted text in chapter "Portability"

2023-06-27 Thread Bjarni Ingi Gislason

Package: perl-doc
Version: 5.36.0-7
Severity: normal
Tags: patch

Dear Maintainer,

  Part of the text needs correct formatting.

  The formatted text in chapter

Portability
Alphabetical Listening of Perl Functions

  begins so (with column width of 100):

   Portability
   Alphabetical Listing of Perl Functions
   -X FILEHANDLE

   , -X EXPR, -X DIRHANDLE, -X, abs VALUE  , abs, accept 
NEWSOCKET,GENERICSOCKET ,
   alarm SECONDS , alarm, atan2 Y,X, bind SOCKET,NAME , binmode 
FILEHANDLE, LAYER
, binmode FILEHANDLE, bless REF,CLASSNAME , bless REF, break, 
caller EXPR,
   caller, chdir EXPR   , chdir FILEHANDLE, chdir DIRHANDLE, chdir, 
chmod LIST   ,
   chomp VARIABLE , chomp( LIST ), chomp, chop VARIABLE , chop( 
LIST ), chop,
   chown LIST
  , chr NUMBER , chr, chroot FILENAME  , chroot, close 
FILEHANDLE , close,
   closedir DIRHANDLE , connect SOCKET,NAME , continue BLOCK , 
continue, cos EXPR
  , cos, crypt PLAINTEXT,SALT

 , dbmclose HASH , dbmopen HASH,DBNAME,MASK , defined EXPR
 , defined, delete EXPR , die LIST
, do BLOCK , do EXPR , dump LABEL   , dump EXPR, dump, each 
HASH  , each
   ARRAY , eof FILEHANDLE   , eof (), eof, eval EXPR
 

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

Kernel: Linux 6.3.7-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages perl-doc depends on:
ii  perl  5.36.0-7

perl-doc recommends no packages.

Versions of packages perl-doc suggests:
ii  groff-base1.22.4-10
ii  man-db [man-browser]  2.11.2-2

-- no debconf information

Bug#1039604: glusterfs: Drop support for 32-bit architectures

2023-06-27 Thread Sergio Durigan Junior

Source: glusterfs
Version: 10.3-5
Severity: important

Hi,

Upstream glusterfs has given several indications that they do not
care about/support 32-bit architectures, as can be seen in this
(non-exhaustive) list of issues:

- https://github.com/gluster/glusterfs/issues/3911

- https://github.com/gluster/glusterfs/issues/702

Moreover, in Ubuntu, where glusterfs is built for armhf, some issues
have been filed about problems related to this lack of 32-bit support,
like:

- https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1991441

- https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1951408

The underlying issue in these two bugs happen to be correlated:
glusterfs requires that the host supports 64-bit atomic operations, but
armhf and other 32-bit architectures don't offer such feature.

Therefore, I would like to request that the support for 32-bit
architecture in Debian's glusterfs package be dropped, please.

A quick investigation tells me that these packages will likely need to
be adjusted because they depend on glusterfs:

Reverse-Build-Depends
* fio   (for libglusterfs-dev)
* libvirt   (for libglusterfs-dev)
* nfs-ganesha   (for libglusterfs-dev)
* qemu  (for libglusterfs-dev)
* qemu  (for glusterfs-common)
* tgt   (for libglusterfs-dev)
* uwsgi (for libglusterfs-dev)

Reverse-Build-Depends-Arch
* samba (for libglusterfs-dev)

Let me know if there's anything I can do to help here.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1039603: mate-panel: Panel applets crash

2023-06-27 Thread Gottfried Schwieters

Package: mate-panel
Version: 1.27.1-1
Severity: important

After upgrade to version 1.27.1 all panel applets crash on startup.
E.g. desktop switcher, clock, battery applet, wifi applet, ...
When you try to add them to the panel, they quit at once with the
message
" terminated unexpectedly" (or the like, I have german
environment).
So I now only have the menu and the app quickstarters in the panel.
May it be the problem, that all the other parts of the mate system have
still version 1.26? Only the panel was upgraded to 1.27.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libatk1.0-0  2.48.3-1
ii  libc6    2.36-9
ii  libcairo2    1.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libgtk-layer-shell0  0.8.1-1
ii  libice6  2:1.0.10-1
ii  libmate-desktop-2-17 1.26.0-2
ii  libmate-menu2    1.26.0-3
ii  libmate-panel-applet-4-1 1.27.1-1
ii  libmateweather1  1.26.0-1.1
ii  libpango-1.0-0   1.50.14+ds-1
ii  librda0  0.0.5-1.1
ii  libsm6   2:1.2.3-1
ii  libwayland-client0   1.21.0-1
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.6-1
ii  libxrandr2   2:1.5.2-2+b1
ii  mate-desktop 1.26.0-2
ii  mate-menus   1.26.0-3
ii  mate-panel-common    1.27.1-1
ii  mate-polkit  1.26.1-3

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?


Hi Dirk,

On 26-06-2023 22:21, Dirk Eddelbuettel wrote:

I really appreciate the diligence and detail you put into this.

But I would like to offer a simple shortcut.  I am also CCing debian-r again
as this has come up time and time again, is guaranteed to come up again for
as long as combine autopkgtests with letting packages go stake.


Somehow I feel you missed my point. In Debian we also care about 
preventing partial upgrades doing the wrong thing. I explicitly noted 
that in unstable everything is fine, so I think I acknowledge what you 
said. However, for the migration to automatically happen and to 
(possibly, I leave that for you (packages maintainers) to judge) prevent 
issues with partial upgrades there needs to be some *versioned* package 
relation somewhere.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038745: dunst: Please package new upstream release 1.9.2

2023-06-27 Thread Nikos Tsipinakis

Hi Boyuan,

I see you've made a few NM uploads to dunst already, as well as pre-packaged 
1.9.2 in salsa, thanks a lot! :)

I've now made this a maintainer upload and uploaded 1.9.2.

Cheers,
Nikos

Bug#749434: mspdebug: Conflicting parameter types of function demangle

2023-06-27 Thread Colin Tuckley


This bug appears to be fixed in mspdebug V0.25 available from upstream at:
https://github.com/dlbeer/mspdebug/archive/refs/tags/v0.25.tar.gz

Please consider updating the package.

regards, Colin
DD Emeritus

--
Colin Tuckley |  PGP/GnuPG Key Id
G8TMV | 0xFA0C410738C9D903

Bug#1039602: /usr/bin/emacs-gtk: PATCH: Fix segfault in vc-revert

2023-06-27 Thread Richard Hopkins

Package: emacs-gtk
Version: 1:27.1+1-3.1+deb11u2
Severity: important
File: /usr/bin/emacs-gtk
X-Debbugs-Cc: em...@unbit.co.uk

Dear Maintainer,

   * What led up to the situation?

Using Debian 11.7 with the provided package for Emacs 27.1, performing
M-x vc-revert on a changed file caused a segfault.  I've managed to
find the following to reproduce it which uses the Emacs Git repository
along with the source file that needs to be patched to resolve it.

src/emacs -Q src/xdisp.c --eval "(add-to-list 'display-buffer-alist (list \".\" 
'display-buffer-same-window))" -f global-display-line-numbers-mode
Apply the patch below, or make any change for testing
M-x vc-revert

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

This is fixed upstream since 27.2 and has other ways of causing the
segfault - see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44111

I've reproduced this using a Git or Mercurial repository and other VC's
may be affected as it seems a general Emacs issue with line numbers.

Manually applying the fix from the upstream bug (commit
e29cace60afdab04ff20c4f4043a3ee64ec9d01d) also fixes the issue.

   * What was the outcome of this action?

Segfault. 

   * What outcome did you expect instead?

Show the *vc-diff* buffer with the changes to be reverted.
This is resolved by applying the upstream commit.

Emacs 27.2 and later releases are unaffected.

   * Extra information

I've reproduced this

- in a TTY and in a GTK session with the provided package
- ditto with a manual build from source. tag emacs-27.1
  ./configure --without-all CFLAGS='-g -O0'
  gdb backtrace

0  0x5592f1bd in face_for_char (f=0x55efd120, face=0x0, c=0, 
pos=-1, object=0x0) at fontset.c:929
1  0x555b2d03 in FACE_FOR_CHAR (f=0x55efd120, face=0x0, 
character=0, pos=-1, object=0x0) at dispextern.h:1891
2  0x555f20d8 in append_space_for_newline (it=0x7fff6730, 
default_face_p=false) at xdisp.c:21640
3  0x555f9521 in display_line (it=0x7fff6730, cursor_vpos=0) at 
xdisp.c:23674
4  0x555eb34f in try_window (window=0x55efd385, pos=..., flags=1) 
at xdisp.c:19182
5  0x555e8ae7 in redisplay_window (window=0x55efd385, 
just_this_one_p=false) at xdisp.c:18600
6  0x555e1b83 in redisplay_window_0 (window=0x55efd385) at 
xdisp.c:16314
7  0x558512ed in internal_condition_case_1 (bfun=0x555e1b41 
, arg=0x55efd385, handlers=0x76ce74fb, 
hfun=0x555e1b09 ) at eval.c:1380
8  0x555e1adf in redisplay_windows (window=0x55efd385) at 
xdisp.c:16294
9  0x555e0a0a in redisplay_internal () at xdisp.c:15762
10 0x555dedd6 in redisplay () at xdisp.c:14989
11 0x557383ea in read_char (commandflag=1, map=0x564c2f53, 
prev_event=0x0, used_mouse_menu=0x7fffbb4f, end_time=0x0) at keyboard.c:2493
12 0x557471a0 in read_key_sequence (keybuf=0x7fffbd50, prompt=0x0, 
dont_downcase_last=false, can_return_switch_frame=true, 
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9553
13 0x55735575 in command_loop_1 () at keyboard.c:1350
14 0x55851246 in internal_condition_case (bfun=0x5573512f 
, handlers=0x90, hfun=0x557348cb ) at eval.c:1356
15 0x55734df7 in command_loop_2 (ignore=0x0) at keyboard.c:1091
16 0x55850afb in internal_catch (tag=0x51f0, func=0x55734dca 
, arg=0x0) at eval.c:1117
17 0x55734d26 in command_loop () at keyboard.c:1062
18 0x5573449c in recursive_edit_1 () at keyboard.c:714de
19 0x5579c602 in read_minibuf (map=0x76b25e3b, initial=0x0, 
prompt=0x563f62e4, expflag=false, histvar=0xe340, histpos=0x2, defalt=0x0, 
allow_props=false, inherit_input_method=false) at minibuf.c:664
20 0x5579cf6c in Fread_from_minibuffer (prompt=0x563f62e4, 
initial_contents=0x0, keymap=0x76b25e3b, read=0x0, hist=0xe340, 
default_value=0x0, inherit_input_method=0x0) at minibuf.c:942
21 0x5586923c in Fyes_or_no_p (prompt=0x563f62e4) at fns.c:2813
22 0x55854d6b in funcall_subr (subr=0x55e4dae0 , 
numargs=1, args=0x7fffc400) at eval.c:2868
23 0x5585497f in Ffuncall (nargs=2, args=0x7fffc3f8) at eval.c:2795
24 0x558b76c7 in exec_byte_code (bytestr=0x56414244, 
vector=0x563d3675, maxdepth=0x3a, args_template=0x2, nargs=0, 
args=0x7fffcb60) at bytecode.c:633
25 0x558553e5 in funcall_lambda (fun=0x5640dfc5, nargs=0, 
arg_vector=0x7fffcb60) at eval.c:2990
26 0x558549c3 in Ffuncall (nargs=1, args=0x7fffcb58) at eval.c:2797
27 0x558477ca in Ffuncall_interactively (nargs=1, args=0x7fffcb58) 
at callint.c:254
28 0x55854c91 in funcall_subr (subr=0x55e4ba20 
, numargs=1, args=0x7fffcb58) at eval.c:2848
29 0x5585497f in Ffuncall (nargs=2, args=0x7fffcb50) at eval.c:2795
30 0x558538fb in Fapply (nargs=3, args=0x7fffcb50) at eval.c:2378
31

Bug#1039599: /usr/bin/uscan: CLI facility to run it from outside a packaging source directory

2023-06-27 Thread Adam D. Barratt

On Tue, 2023-06-27 at 19:17 +0200, Patrice Duroux wrote:
> So is there a possibility to be more direct like the following:
> 
> $ UDDquery -A -t -c "select watch_file from upstream where
> source='$PKG_SRC';"
> > uscan --report-status
> 

The BTS isn't a support forum for "how do I do X queries".

In any case, afaict the manpage already answers this exact question:


--package package
Specify the name of the package to check for rather than examining
debian/changelog; this requires the --upstream-version (unless a
version is specified in the watch file) and --watchfile options as
well. Furthermore, no directory scanning will be done and nothing will
be downloaded. This option automatically sets --no-download and --skip-
signature; and probably most useful in conjunction with the DEHS system
(and --dehs).


Regards,

Adam

Bug#1039601: /usr/share/openvswitch/scripts/ifupdown.sh: /usr/share/openvswitch/scripts/ifupdown.sh disregards current status for daemon on sysvinit systems

2023-06-27 Thread johan

Package: openvswitch-switch
Version: 3.1.0-2
Severity: important
File: /usr/share/openvswitch/scripts/ifupdown.sh
Tags: patch
X-Debbugs-Cc: skin_tiic...@hotmail.com

Dear Maintainer,

Previously in bullseye this script checked if the service was already running 
and if not, starting it on sysvinit systems. This is no longer the case which 
can cause a deadlock situation when it tries to bring interfaces up. Bringing 
back the old logic fixes the problem as it wont try to start it if the service 
is already running.

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

Versions of packages openvswitch-switch depends on:
ii  init-system-helpers  1.65.2
ii  kmod 30+20221128-1
ii  libbpf1  1:1.1.0-1
ii  libc62.36-9
ii  libcap-ng0   0.8.3-1+b3
ii  libnuma1 2.0.16-1
ii  libssl3  3.0.8-1
ii  libunbound8  1.17.1-2
ii  libxdp1  1.3.1-1
ii  netbase  6.4
ii  openvswitch-common   3.1.0-2
ii  procps   2:4.0.3-1
ii  python3  3.11.2-1+b1
ii  python3-netifaces0.11.0-2+b1
ii  python3-openvswitch  3.1.0-2
ii  uuid-runtime 2.38.1-5+b1

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- no debconf information
38c38
< if service openvswitch-switch status > /dev/null 2>&1; then
---
> if ! service openvswitch-switch status > /dev/null 2>&1; then

Bug#1032074: Info received (libdbd-mysql-perl: Also a problem with /usr/bin/mysql)

2023-06-27 Thread Russell King

It seems mariadb developers know about the issue:

https://github.com/mariadb-corporation/mariadb-connector-c/pull/219

Bug#1025453: Info received (additional information)

2023-06-27 Thread graeme vetterlein


Actually it looks like it's coming up on its first decade


https://bugzilla.kernel.org/show_bug.cgi?id=86311

Bug#1012232: freespace2: FTBFS with libsdl1.2-compat-dev: 'malloc_usable_size' was not declared in this scope

2023-06-27 Thread Simon McVittie

Control: retitle -1 freespace2: FTBFS with libsdl1.2-compat-dev: 
'malloc_usable_size' was not declared in this scope

(cc'ing adetiste because he was looking at this package recently; the
SDL2-based new upstream version will close both #1038352 and this bug,
assuming the SDL2 version compiles successfully)

On Mon, 20 Feb 2023 at 09:35:59 +0100, Andreas Beckmann wrote:
> The actual problem are missing
>   Build-Depends: pkg-config, libglu1-mesa-dev
> These were pulled in transitively in bullseye.

The actual actual problem :-) is that freespace2 build-depends on
libsdl-dev, a virtual package, and not on libsdl1.2-dev, a concrete
implementation of that virtual package. This means that buildds and other
build environments will choose either libsdl1.2-dev (currently "classic"
SDL 1.2) or libsdl1.2-compat-dev, arbitrarily. That makes this bug RC,
while in other packages with "FTBFS with libsdl1.2-compat-dev" bugs,
the bug is usually not RC yet.

libsdl1.2-compat-dev didn't exist in bullseye, and "classic" SDL 1.2 always
pulled in libglu1-mesa-dev (see #1039072) and pkg-config (see #1039074),
which is why this worked in bullseye. It will not be reliable in bookworm,
which does have libsdl1.2-compat-dev available.

libsdl1.2-compat-dev (>= 1.2.64-3) works around this class of bug by
depending on pkgconf and libglu1-mesa-dev, so this part is not critical
to address in freespace2.

It is still a good idea to have an explicit build-dependency on anything
that the package explicitly uses, to avoid being broken by "action at
a distance" in a dependency.

It would also be a good idea to switch the build-dependency to
the concrete package, libsdl1.2-dev. At the moment, this is "classic"
SDL 1.2. My intention is that before the trixie freeze, sdl12-compat
will take over that binary package name, so Build-Depends: libsdl1.2-dev
will still be the correct thing for SDL 1.2 codebases to use.

The other part of this FTBFS *is* release-critical to address in
freespace2 if not worked around in libsdl1.2-compat-dev:

> Then you need to make the inclusion of malloc.h unconditional in
> code/windows_stub/stubs.cpp (or fix the build system s.t. it checks for
> malloc.h and populates HAVE_MALLOC_H accordingly).

This is also triggered by using libsdl1.2-compat-dev. The headers in
that package aim to be compatible with the ones in libsdl1.2-dev, but for
licensing reasons they are partially a rewrite, and for maintainability
reasons they differ in various implementation details.

In this case, the error seen is:

windows_stub/stubs.cpp: In function 'void* _vm_malloc(int, char*, int, int)':
windows_stub/stubs.cpp:49:32: error: 'malloc_usable_size' was not declared in 
this scope
   49 | #define MALLOC_USABLE(pointer) malloc_usable_size(pointer)
  |^~
windows_stub/stubs.cpp:627:28: note: in expansion of macro 'MALLOC_USABLE'
  627 | size_t used_size = MALLOC_USABLE(ptr);
  |^
windows_stub/stubs.cpp: In function 'void* _vm_realloc(void*, int, char*, int, 
int)':
windows_stub/stubs.cpp:49:32: error: 'malloc_usable_size' was not declared in 
this scope
   49 | #define MALLOC_USABLE(pointer) malloc_usable_size(pointer)
  |^~
windows_stub/stubs.cpp:649:27: note: in expansion of macro 'MALLOC_USABLE'
  649 | size_t old_size = MALLOC_USABLE(ptr);
  |   ^
windows_stub/stubs.cpp: In function 'void _vm_free(void*, char*, int)':
windows_stub/stubs.cpp:49:32: error: 'malloc_usable_size' was not declared in 
this scope
   49 | #define MALLOC_USABLE(pointer) malloc_usable_size(pointer)
  |^~
windows_stub/stubs.cpp:731:21: note: in expansion of macro 'MALLOC_USABLE'
  731 | TotalRam -= MALLOC_USABLE(ptr);
  | ^

This appears to be because freespace2 checks #ifdef HAVE_MALLOC_H,
but never actually checks for malloc.h, so it was accidentally relying
on SDL's SDL_config.h to leak information about the headers that SDL
uses internally. Here is a patch that is sufficient to resolve this part
of the bug:

8<
diff --git a/configure.ac b/configure.ac
index d850f85..af54a1e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -311,6 +311,7 @@ AM_CONDITIONAL(FS2_DEBUG,  test "$fs2_debug"  = 
"yes")
 AM_CONDITIONAL([am__fastdepOBJC],  test "$fs2_os_osx"  = "yes")

 AC_CHECK_HEADER(stdlib.h)
+AC_CHECK_HEADERS_ONCE([malloc.h])

 dnl From licq: Copyright (c) 2000 Dirk Mueller
 dnl Check if the type socklen_t is defined anywhere
8<

If a SDL2 version cannot be uploaded any time soon, please apply that
patch.

I might work around this in sdl12-compat too (I'll see what upstream
think) but this is really not SDL's job, so please add that check anyway.

Thanks,
smcv

Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt

2023-06-27 Thread Richard Lewis

header.txt has not been modified since 2015.

it is a simple yext file that is installed with debian/logcheck.install

the only change is that it used to be installed into /usr/share but got
moved to /etc to be a conffile in 2021. This didnt trigger any piuparts
issues and there was no change to the contents of header.txt.

So i dont understand how piuparts found an issue - is it possible to tell
us what difference piuparts actually detected?




On Tue, 27 Jun 2023, 15:30 Andreas Beckmann,  wrote:

> Package: logcheck
> Version: 1.4.2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package failed the piuparts
> upgrade test because dpkg detected a conffile as being modified and then
> prompted the user for an action. As there is no user input, this fails.
> But this is not the real problem, the real problem is that this prompt
> shows up in the first place, as there was nobody modifying this conffile
> at all, the package has just been installed and upgraded...
>
> This is a violation of policy 10.7.3, see
> https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
> which says "[These scripts handling conffiles] must not ask unnecessary
> questions (particularly during upgrades), and must otherwise be good
> citizens."
>
> https://wiki.debian.org/DpkgConffileHandling should help with figuring
> out how to do this properly.
>
> In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
> followups it has been agreed that these bugs are to be filed with
> severity serious.
>
> From the attached log (scroll to the bottom...):
>
>   Setting up logcheck (1.4.2) ...
>
>   Configuration file '/etc/logcheck/header.txt'
>==> File on system created by you or by a script.
>==> File also in package provided by package maintainer.
>  What would you like to do about it ?  Your options are:
>   Y or I  : install the package maintainer's version
>   N or O  : keep your currently-installed version
> D : show the differences between the versions
> Z : start a shell to examine the situation
>The default action is to keep your current version.
>   *** header.txt (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing
> package logcheck (--configure):
>end of file on stdin at conffile prompt
>   Processing triggers for debianutils (5.7-0.5~deb12anbe1) ...
>   Processing triggers for libc-bin (2.36-9) ...
>   Errors were encountered while processing:
>logcheck
>
>
> This happens up upgrade paths starting in jessie, upgrading release by
> release to bookworm.
>
>
> cheers,
>
> Andreas
>

Bug#1039600: libclc-15: Missing bitcode for AMD RDNA GPUs

2023-06-27 Thread Miroslav Maiksnar

Package: libclc-15
Version: 1:15.0.7-6
Severity: normal
X-Debbugs-Cc: bugs.debian@m.mixi.cz

Dear Maintainer,

when running OpenCL application built using LLVM on new RDNA AMD GPU (RX 7900 
XTX
in my case), I get following error:

fatal error: cannot open file '/usr/lib/clc/gfx1100-amdgcn-mesa-mesa3d.bc': No 
such file or directory

Example of application is https://github.com/nerdralph/cl-mem (part of 
phoronix-test-suite),
but other LLVM OpenCL applications I tried crash with same error.

On page https://llvm.org/docs/AMDGPUUsage.html#processors is list of GPUs 
supported by LLVM,
but none of bitcode bundles for listed RDNA 1-3 GPUs are present in 
/usr/lib/clc/ directory.

Thanks for fixing this.
Mixi

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (100, 'stable'), 
(10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 libclc-15 depends on:
ii  libclang-common-15-dev  1:15.0.7-4
ii  libclc-15-dev   1:15.0.7-6

libclc-15 recommends no packages.

libclc-15 suggests no packages.

-- no debconf information

Bug#1039599: /usr/bin/uscan: CLI facility to run it from outside a packaging source directory

2023-06-27 Thread Patrice Duroux

Package: devscripts
Version: 2.23.5
Severity: wishlist
File: /usr/bin/uscan

Dear Maintainer,

Here is what I am currently doing to do a uscan check from dry:

$ mkdir debian
$ UDDquery -A -t -c "select watch_file from upstream where source='$PKG_SRC';"
> debian/watch
$ echo "fake (0) UNRELEASED;" > debian/changelog
$ uscan --report-status

So is there a possibility to be more direct like the following:

$ UDDquery -A -t -c "select watch_file from upstream where source='$PKG_SRC';"
| uscan --report-status

or by adding any extra option for such an ability?
Would this be useful to add?

Regards,
Patrice





-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
export DEBFULLNAME="Patrice Duroux"
export DEBEMAIL="patrice.dur...@gmail.com"

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 devscripts depends on:
ii  dpkg-dev  1.21.22
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.71-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.4-1
ii  sensible-utils0.0.20
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.1
ii  curl7.88.1-10
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2023.05.26
pn  dput | dupload  
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5
ii  libdpkg-perl1.21.22
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.27-1
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.19-2
ii  licensecheck3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-2
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-28
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages devscripts suggests:
ii  adequate  0.15.7
ii  at3.2.5-1+b1
ii  autopkgtest   5.29
pn  bls-standalone
ii  build-essential   12.10
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.11.4
pn  diffoscope
pn  disorderfs
pn  dose-extra
pn  duck  
pn  elpa-devscripts   
pn  faketime  
pn  gnuplot   
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-3
ii  libdbd-pg-perl3.16.3-1
ii  libfile-desktopentry-perl 0.22-3
pn  libterm-size-perl 
ii  libtimedate-perl  2.3300-2
pn  libyaml-syck-perl 
ii  mailutils [mailx] 1:3.16-1
ii  mmdebstrap1.3.7-2
pn  mozilla-devscripts
ii  mutt  2.2.9-1+b1
ii  openssh-client [ssh-client]   1:9.3p1-1
pn  piuparts  
ii  postgresql-client 15+248
ii  postgresql-client-15 [postgresql-client]  15.3-0+deb12u1
pn  pristine-lfs  
ii  quilt 0.67+really0.66-1
pn  ratt  
pn  reprotest

Bug#815187: Bug debian-Installer (bookworm): Installation grub fails without error message

2023-06-27 Thread CJ Kucera

Package: installation-reports
Followup-For: Bug #815187

Submitting an installation-reports bug as requested per chat in #debian
on Libera.  Details of the installation problem are in Bug #815187


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230607"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux testbox 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 
(2023-05-08) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC 
[Natoma] [8086:1237] (rev 02)
lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA 
[Natoma/Triton II] [8086:7000]
lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 
IDE [8086:7111] (rev 01)
lspci -knn: Kernel driver in use: ata_piix
lspci -knn: Kernel modules: ata_piix, ata_generic
lspci -knn: 00:02.0 VGA compatible controller [0300]: VMware SVGA II Adapter 
[15ad:0405]
lspci -knn: Subsystem: VMware SVGA II Adapter [15ad:0405]
lspci -knn: 00:03.0 Ethernet controller [0200]: Intel Corporation 82540EM 
Gigabit Ethernet Controller [8086:100e] (rev 02)
lspci -knn: Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter 
[8086:001e]
lspci -knn: Kernel driver in use: e1000
lspci -knn: Kernel modules: e1000
lspci -knn: 00:04.0 System peripheral [0880]: InnoTek Systemberatung GmbH 
VirtualBox Guest Service [80ee:cafe]
lspci -knn: 00:05.0 Multimedia audio controller [0401]: Intel Corporation 
82801AA AC'97 Audio Controller [8086:2415] (rev 01)
lspci -knn: Subsystem: Dell Device [1028:0177]
lspci -knn: Kernel driver in use: snd_intel8x0
lspci -knn: Kernel modules: snd_intel8x0
lspci -knn: 00:06.0 USB controller [0c03]: Apple Inc. KeyLargo/Intrepid USB 
[106b:003f]
lspci -knn: Kernel driver in use: ohci-pci
lspci -knn: Kernel modules: ohci_pci
lspci -knn: 00:07.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI 
[8086:7113] (rev 08)
lspci -knn: 00:0b.0 USB controller [0c03]: Intel Corporation 
82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:0d.0 SATA controller [0106]: Intel Corporation 82801HM/HEM 
(ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 02)
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 6.1.0-9-amd64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: OHCI PCI host controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 6.1.0-9-amd64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: fuse  176128  0
lsmod: battery28672  0
lsmod: dm_mod184320  8
lsmod: raid1  53248  2
lsmod: md_mod192512  5 raid1
lsmod: xfs  1945600  0
lsmod: jfs   221184  0
lsmod: btrfs1777664  0
lsmod: xor24576  1 btrfs
lsmod: raid6_pq  122880  1 btrfs
lsmod: zstd_compress 294912  1 btrfs
lsmod: libcrc32c  16384  2 btrfs,xfs
lsmod: vfat   24576  0
lsmod: fat90112  1 vfat
lsmod: ext4  983040  3
lsmod: crc16  16384  1 ext4
lsmod: mbcache16384  1 ext4
lsmod: jbd2  167936  1 ext4
lsmod: crc32c_generic 16384  7
lsmod: e1000 163840  0
lsmod: isofs  53248  0
lsmod: usb_storage81920  0
lsmod: sd_mod 65536  8
lsmod: t10_pi 16384  1 sd_mod
lsmod: sr_mod 28672  0
lsmod: crc64_rocksoft 20480  1 t10_pi
lsmod: crc64  20480  1 crc64_rocksoft
lsmod: cdrom  81920  2 isofs,sr_mod
lsmod: crc_t10dif 20480  1 t10_pi
lsmod: crct10dif_common   16384  1 crc_t10dif
lsmod: ata_generic16384  0
lsmod: ohci_pci   20480  0
lsmod: ahci   49152  6
lsmod: ata_piix   45056  0
lsmod: libahci49152  1 ahci
lsmod: ohci_hcd   61440  1 ohci_pci
lsmod: snd_intel8x0   49152  0
lsmod: ehci_pci   20480  0
lsmod: ehci_hcd  102400  1 ehci_pci
lsmod: snd_ac97_codec

Bug#1025453: additional information

2023-06-27 Thread graeme vetterlein


The following may be helpful:


1: I am running this on bare matal (no KVM, vmware etc)

2:

$cat /proc/cupinfo

processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 60
model name    : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
stepping    : 3
microcode    : 0x9
cpu MHz        : 823.533
cache size    : 8192 KB
physical id    : 0
siblings    : 8
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl 
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor 
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 
x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault 
invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida 
arat pln pts
vmx flags    : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple 
shadow_vmcs
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf 
mds swapgs taa itlb_multihit srbds mmio_unknown

bogomips    : 6799.82
clflush size    : 64
cache_alignment    : 64
address sizes    : 39 bits physical, 48 bits virtual
power management:

processor    : 1

...elided...

Bug#1039598: RM: nvidia-graphics-drivers-tesla-510, nvidia-settings-tesla-510 -- ROM; NPOASR; obsolete; superseded by the unversioned tesla driver packages

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org

Let's get rid of the obsolete Tesla 510 driver (which is a set of
transitional packages for upgrading to the unversioned tesla drivers,
i.e. src:nvidia-graphics-drivers-tesla, src:nvidia-settings-tesla).

Andreas

Bug#1025453: workaround

2023-06-27 Thread graeme vetterlein

Having seen bookworm go to stable with this bug still present, I did 
some more digging.



This comment:  https://forums.debian.net/viewtopic.php?t=150032


Points at an earlier bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867548#52



And applying their workaround, my issue disappears:


[ edit /etc/default/grub to add

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on,igfx_off"
]


However reading the forum post, it appears they hit the issue on 
upgrading to "bullseye"


I get the issue upgrading from "bullseye" to "sid (bookworm)".


Now, for me, this was very much "Monkey See, Monkey do"  I don't know 
what that line added to kernel boot args does, but:



1: Maybe it's avoiding something that broken  ..or

2: It is the correct option that should be added


I either case, something is broken. It works on one release, you 
upgrade, it breaks.



My initial guess would be something in the initrd generation or grub 
choices is going wrong during the install process.



Could somebody move this issue to a more sensible place (package) as 
it's unclear to me where the root problem lies (also tie to 867548 )

Bug#1039597: apt: misleading error message "is to be installed"

2023-06-27 Thread Thomas

Package: apt
Version: 2.6.1
Severity: minor



Hi !

I've always been puzzled by the following error message :

--8<--8<--8<--8<--8<--8<--8<--
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 firefox-l10n-fr : Depends: firefox (>= 114.0.2-1) but 114.0-1 is to be 
installed
E: Broken packages
--8<--8<--8<--8<--8<--8<--8<--

Please note that I do not complain about the unability to install
the package in question but the error message itself.

Indeed, it says "[firefox] 114.0-1 is to be installed".

It's obviously wrong. Firefox is _already_ installed :

--8<--8<--8<--8<--8<--8<--8<--
$ dpkg -l | grep firefox
ii  firefox   114.0-1   
   amd64Mozilla Firefox web browser
ii  firefox-l10n-fr   114.0-1   
   all  French language package for Firefox
--8<--8<--8<--8<--8<--8<--8<--

The error message says that firefox-l10n-fr depends on a newer
version of firefox (114.0.2-1). So, the firefox-l10n-fr package
cannot be installed because I have an "older" version of firefox.

What the error message does not tell us is why the newer version
of firefox cannot be installed and thus why the wanted package
connot be installed as a result.

The line "The following information may help to resolve the
situation:" is thus plainly wrong since the displayed message
absolutly does not help resolve the situation...


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

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

Versions of packages apt depends on:
ii  adduser 3.134
ii  debian-archive-keyring  2023.3
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.1
ii  libc6   2.36-9
ii  libgcc-s1   13.1.0-6
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  13.1.0-6
ii  libsystemd0 252.11-1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-5
ii  dpkg-dev1.21.22
ii  gnupg   2.2.40-1.1
ii  gnupg2  2.2.40-1.1
ii  powermgmt-base  1.37

-- no debconf information

Bug#1039572: sl-modem-dkms: module fails to build for Linux 6.4