Bug#1049458: celluloid: fails to start due to failed assertion in stream.c

[Stefan Breunig]

Hi,

I didn't manage to compile the provided package:

The folder structure is
/tmp/celluloid_0.25.orig.tar.gz
/tmp/celluloid_0.25-2.dsc
/tmp/cell/debian (extracted from celluloid_0.25-2.debian.tar.xz)

$ cd /tmp/cell && dpkg-buildpackage
dpkg-buildpackage: info: source package celluloid
dpkg-buildpackage: info: source version 0.25-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Leandro Cunha 


dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean --buildsystem=meson
   dh_auto_clean -O--buildsystem=meson
   dh_autoreconf_clean -O--buildsystem=meson
   debian/rules override_dh_clean
make[1]: Entering directory '/tmp/cell'
dh_clean
rm -f po/*.gmo po/stamp-po
make[1]: Leaving directory '/tmp/cell'
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building celluloid using existing 
./celluloid_0.25.orig.tar.gz

dpkg-source: info: using patch list from debian/patches/series
dpkg-source: warning: ignoring deletion of file autogen.sh, use 
--include-removal to override

   ...
dpkg-source: warning: ignoring deletion of file po/fi.po, use 
--include-removal to override

dpkg-source: info: building celluloid in celluloid_0.25-2.debian.tar.xz
dpkg-source: info: building celluloid in celluloid_0.25-2.dsc
 debian/rules binary
dh binary --buildsystem=meson
   dh_update_autotools_config -O--buildsystem=meson
   dh_autoreconf -O--buildsystem=meson
   dh_auto_configure -O--buildsystem=meson
    cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb 
LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain 
--prefix=/usr --sysconfdir=/etc --localstatedir=/var 
--libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1


ERROR: Neither source directory '..' nor build directory None contain a 
build file meson.build.
dh_auto_configure: error: cd obj-x86_64-linux-gnu && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu 
-Dpython.bytecompile=-1 returned exit code 1

make: *** [debian/rules:21: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


I am not sure what's wrong here.

Bug#1044095: cockpit: Fails to build source after successful build

[Martin Pitt]

Control: tag -1 upstream pending
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19232

Lucas Nussbaum [2023-08-13 16:33 +0200]:
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
> > dpkg-source: error: cannot represent change to 
> > tmp/wheel/cockpit-298-py3-none-any.whl: binary file contents changed
> > dpkg-source: error: add tmp/wheel/cockpit-298-py3-none-any.whl in 
> > debian/source/include-binaries if you want to store the modified binary in 
> > the debian tarball

Thanks for your report! I sent a packaging fix upstream.

Martin

Bug#1050387: debsign: please run with --no-auto-check-trustdb (or allow it to be set)

[Mattia Rizzolo]

On Wed, Aug 23, 2023 at 04:44:58PM -0400, Nicholas D Steeves wrote:
> An up-to-date trustdb isn't needed to sign a changes file, so I think 
> --no-auto-check-trustdb should be debsign's default.  Alternatively, please 
> allow it to be set as a config option.
> 
> It looks like this would be a trivial patch, but I'd like to confirm with 
> others that this would be a good idea, and that I'm not just biased!


It sounds like a very sensible flag also to me, yes.
In fact, isn't this something that changed between gpg1 and gpg2?  I
reckon it simply didn't bother others enough to do something about it…
in my system it only takes roughtly 20-30 seconds, and I can wait that
much.

For what I'm concerned, you can directly push such change to git,
provided it's only this much :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1050352: backside USB-ports stop working after some time

[Rolf Reintjes]

On 23.08.23 19:39, Diederik de Haas wrote:

Control: reassign -1 src:linux/6.1.38-4

On Wednesday, 23 August 2023 18:39:50 CEST Rolf Reintjes wrote:

Here are more of the near dmesg meassages:


[   28.747758] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[  344.813681] DMAR: DRHD: handling fault status reg 2
[  344.813692] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault
addr 0xfffad000 [fault reason 0x06] PTE Read access is not set
[  344.813917] DMAR: DRHD: handling fault status reg 102
[  344.813923] xhci_hcd :05:00.0: WARNING: Host System Error
[  344.813923] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault
addr 0xfffad000 [fault reason 0x06] PTE Read access is not set


A page fault doesn't sound good and I wouldn't be surprised if that wes the
reason for the issues.
On https://snapshot.debian.org/binary/linux-image-amd64/ you'll find a whole
bunch of kernel version and it would be really helpful if you can determine
what the last version of the 6.1 series was where the USB ports work as
expected and then the first version where it stopped working.

You could start with (one of) the earliest 6.1 kernels to verify whether it
has worked properly in a 6.1 kernel at all.


I tried some older kernels. They all have the problem.

linux-image-6.1.0-0-amd64_6.1.1-1~exp2_amd64.deb no
linux-image-6.0.0-6-amd64_6.0.12-1_amd64.deb no
linux-image-6.0.0-1-amd64_6.0.2-1_amd64.deb  no

Bug#1050396: RM: pangoterm -- RoQA; low popcon; depends on gtk2

[James McCoy]

Control: forcemerge 967680 -1

On Thu, Aug 24, 2023 at 01:49:47AM +0200, Bastian Germann wrote:
> pangoterm does not seem to be used a lot and is unmaintained upstream.

It's not unmaintained upstream.

> I intend to file a RM bug.
> If you have any reasons to keep it in Debian please voice them here.

If more concrete plans develop to force gtk2 out of the archive, then
this package can be removed along with those.  Until then, leave it be.

> To get people's attention, I am filing as a serious bug and will reassign to
> the FTP team when the package is autoremoved from testing.

There was already a bug noting that this still depends on gtk2.  Merging
with that one and keeping its Severity: normal.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1049975: rust-oxhttp - consider moving to rustls 0.21

[Peter Green]

On 17/08/2023 19:26, Peter Green wrote:

It would be nice to only need a single version of rustls in Debian,
with my recent round of uploads, most of the reverse dependencies
are now moved to version 0.21, leaving oxhttp as one of the few
remaining on 0.20.


rust-oxhttp is now the last one remaining.


Upstream has moved in git, but have not yet made a release based
on the new version


Upstream has now make a new release, including the switch to
rustls 0.21 and also switching from rust-webpki (which we would like to
get rid of) to rust-rustls-webpki.

Please consider uploading it.

Bug#1050397: 1: yosys-src is huge

[Daniel Gröber]

Hi Samuel,

On Thu, Aug 24, 2023 at 02:01:16AM +0200, Samuel Thibault wrote:
> The yosys-src package is huge, it contains a 2.2GiB tarball, perhaps it
> should at least be compressed?

Yowza! something definetly went wrong there, thanks for pointing this out.

I'm about to remove this binpkg again anyhow, it was intended to be used to
run the testsuite in the autopkgtests of yosys' most flaky/critical
dependency (berkeley-abc) but I didn't realise rdepends with broken
autopkgtests will block migration anyhow. So this shouldn't actually be
necessary.

As long as nobody installs this package at least it won't waste space in
the archive as the deb is compressed anyway. Post mortem wise, I'm not sure
what's going on here. When I unpack the tarball the directory only ends up
being around 50M (as it should be).

I'll have a closer look tomorrow.

Thanks,
--Daniel

Bug#809931: org-mode: Correction to report

[Nicholas D Steeves]

Hello Reuben,

Reuben Thomas  writes:

> Package: org-mode
> Version: 8.3.2-1
> Followup-For: Bug #809931
>
> The correct value for org-odt-data-dir is actually
>
> /usr/share/emacs/site-lisp/org-mode/etc
>
> (not …/styles as I previously said).

Wow, it seems no one saw this bug for quite some time...  I recently did
some Debian Emacsen Team uploads for org-mode, and I noticed that the
following are not currently installed in the elpa-org package:

  etc/csl/locales-en-US.xml
  etc/styles/OrgOdtContentTemplate.xml
  etc/styles/OrgOdtStyles.xml

however, emacs-common installs this:

  /usr/share/emacs/28.2/etc/org/OrgOdtStyles.xml

Do you know if the copy bundled with Emacs is sufficient, or if we
should be setting org-odt-data-dir to a value specific to elpa-org?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1050030: Similar reproduction

[Elliott Mitchell]

On Fri, Aug 18, 2023 at 02:05:31PM -0700, Elliott Mitchell wrote:
> >From reading the available information I suspect Tianocore/EDK2 may have
> tried to move some functionality to a distinct build and neither setup
> quite works.  Notably there is now a "OvmfPkg/OvmfXen.dsc" build
> configuration.  The OVMF.fd for Qemu for Xen functionality may have been
> moved /here/.  There might also be an attempt at functionality similar to
> "ArmVirtPkg/ArmVirtXen.dsc" (Debian 978595) for x86.

Now confirmed reverting to 2020.11-2+deb11u1 takes care of the issues I'm
running into.  I've been able to build OvmfPkg/OvmfXen.dsc, but haven't
gotten it to do anything.  I'm suspecting the support for running
headless didn't get into OvmfXen.  I'm interacting with someone
knowledgeable, but nothing yet.

I suspect the "ovmf" package needs to be split.  I've gotten the
impression the build needed for normal `qemu` isn't going to be the same
as the build needed for xen-qemu.

I think what is really needed is for xen-utils-X.YY to Recommend a
virtual package "xen-domu-bootloader" which is then provided by tools
which can load VMs.  The current other in-service tool is grub-xen-host,
but it appears OvmfXen may also be able to provide the service.

I'm attaching two patches which should help organize the source package.
These leave all the "./edksetup.sh" lines identical.  Perhaps make use
of this to make the build cleaner?


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


>From 910f6592733dbef2166ceb469320b8e21c4fa977 Mon Sep 17 00:00:00 2001
Message-Id: <910f6592733dbef2166ceb469320b8e21c4fa977.1692832840.git.ehem+deb...@m5p.com>
From: Elliott Mitchell 
Date: Wed, 20 Jan 2021 17:40:15 -0800
Subject: [PATCH 1/2] debian/rules: Rework edksetup.sh invocations

Instead of using "set -e", instead overtly test return codes using
a conditional.  Move commonly used build flags to front of command as a
precursor to merging into a macro.  This also makes the varying flags
more overt by being on the end.
---
 debian/rules | 45 +++--
 1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/debian/rules b/debian/rules
index 116c9c74b7..36b1ffc045 100755
--- a/debian/rules
+++ b/debian/rules
@@ -59,8 +59,7 @@ undefine CONF_PATH
 override_dh_auto_build: build-qemu-efi-aarch64 build-qemu-efi-arm build-ovmf build-ovmf32
 
 debian/setup-build-stamp:
-	set -e; . ./edksetup.sh; \
-	make -C BaseTools ARCH=$(EDK2_BUILD_ARCH)
+	. ./edksetup.sh && make -C BaseTools ARCH=$(EDK2_BUILD_ARCH)
 	touch $@
 
 OVMF_INSTALL_DIR = debian/ovmf-install
@@ -95,11 +94,10 @@ build-ovmf32: $(OVMF32_BINARIES) $(OVMF32_IMAGES)
 $(OVMF32_BINARIES) $(OVMF32_IMAGES): debian/setup-build-stamp
 	rm -rf $(OVMF32_INSTALL_DIR)
 	mkdir $(OVMF32_INSTALL_DIR)
-	set -e; . ./edksetup.sh; \
-		build -a IA32 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a IA32 \
 			-p OvmfPkg/OvmfPkgIa32.dsc \
-			$(OVMF32_4M_SMM_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF32_4M_SMM_FLAGS)
 	cp $(OVMF32_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF32_INSTALL_DIR)/OVMF32_CODE_4M.secboot.fd
 	cp $(OVMF32_BUILD_DIR)/FV/OVMF_VARS.fd \
@@ -109,38 +107,34 @@ build-ovmf: $(OVMF_BINARIES) $(OVMF_IMAGES) $(OVMF_PREENROLLED_VARS)
 $(OVMF_BINARIES) $(OVMF_IMAGES): debian/setup-build-stamp
 	rm -rf $(OVMF_INSTALL_DIR)
 	mkdir $(OVMF_INSTALL_DIR)
-	set -e; . ./edksetup.sh; \
-		build -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a X64 \
 			-p OvmfPkg/OvmfPkgX64.dsc \
-			$(OVMF_2M_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF_2M_FLAGS)
 	cp $(OVMF_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF_BUILD_DIR)/FV/OVMF.fd $(OVMF_INSTALL_DIR)/
 	cp $(OVMF_BUILD_DIR)/FV/OVMF_VARS.fd $(OVMF_INSTALL_DIR)/
 	rm -rf Build/OvmfX64
-	set -e; . ./edksetup.sh; \
-		build -a IA32 -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a IA32 -a X64 \
 			-p OvmfPkg/OvmfPkgIa32X64.dsc \
-			$(OVMF_4M_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF_4M_FLAGS)
 	cp $(OVMF3264_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF_INSTALL_DIR)/OVMF_CODE_4M.fd
 	cp $(OVMF3264_BUILD_DIR)/FV/OVMF_VARS.fd \
 		$(OVMF_INSTALL_DIR)/OVMF_VARS_4M.fd
 	rm -rf Build/OvmfX64
-	set -e; . ./edksetup.sh; \
-		build -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a X64 \
 			-p OvmfPkg/OvmfPkgX64.dsc \
-			$(OVMF_2M_SMM_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF_2M_SMM_FLAGS)
 	cp $(OVMF_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF_INSTALL_DIR)/OVMF_CODE.secboot.fd
 	rm -rf Build/OvmfX64
-	set -e; . ./edksetup.sh; \
-		build -a IA32 -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t 

Bug#1050399: RM: starplot -- RoQA; low popcon; depends on gtk2

[Bastian Germann]

Source: starplot
Severity: serious

starplot does not seem to be used a lot and is unmaintained upstream.

I intend to file a RM bug.
If you have any reasons to keep it in Debian please voice them here.
To get people's attention, I am filing as a serious bug and will 
reassign to the FTP team when the package is autoremoved from testing.

Bug#1050398: RM: transcalc -- RoQA; depends on gtk2; low popcon; orphaned; dead upstream

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:transcalc

Please remove transcalc. The package has a low popcon and depends on 
gtk2. It is dead upstream and orphaned.

Bug#1050397: yosys-src is huge

[Samuel Thibault]

Package: yosys-src
Version: 0.30-5
Severity: normal

Hello,

The yosys-src package is huge, it contains a 2.2GiB tarball, perhaps it
should at least be compressed?

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-- no debconf information

Bug#967710: procmeter3: depends on deprecated GTK 2

[Bastian Germann]

Please just drop gtk2 support by dropping the libgtk2.0-dev build 
dependency. gtk3 is still supported then.

Bug#1041807: geany-plugins: build-depends on libwnck-dev, and indirectly on GTK 2

[Bastian Germann]

Please just drop the libwnck-dev build dependency which used to be 
required for the devhelp component (which was disabled) but is not 
anymore. Consequently, there is no binary package that depends on 
libwnck22 and the package builds without it.

Bug#1050396: RM: pangoterm -- RoQA; low popcon; depends on gtk2

[Bastian Germann]

Source: pangoterm
Severity: serious

pangoterm does not seem to be used a lot and is unmaintained upstream.

I intend to file a RM bug.
If you have any reasons to keep it in Debian please voice them here.
To get people's attention, I am filing as a serious bug and will 
reassign to the FTP team when the package is autoremoved from testing.

Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Guillem Jover]

Hi!

On Fri, 2023-08-18 at 08:07:44 -0300, Antonio Terceiro wrote:
> FWIW, I have been maintaining vagrant in Debian for several years.

BTW, thank you for having done that, it's been much appreciated!

> TL;DR: I will not be maintaining vagrant anymore.

> On Fri, Aug 18, 2023 at 02:56:28PM +0900, Kentaro HAYASHI wrote:
> > * What was the outcome of this action?

> > Plan A.
[…]

> > Plan B.
[…]

> On Fri, Aug 18, 2023 at 09:37:54AM +, gwili.stif...@easymailer.live wrote:
> > Plan C.
[…]

There's perhaps a:

Plan D.

- Package Vagrunt (https://github.com/vaagrunt/vagrunt) a fork of
  Vagrant, that is stated should remain free software. And as it does
  not have a CLA, if it gets several contributions it will be
  increasingly hard to relicense.
- Transition from vagrant to vagrunt via a transitional package.

(We use Vagrant at work, and I'm not planning on relying on a non-free
tool, so a fork would do, otherwise I'd have to look into alternatives
for us to switch to.)

> Hopefully, being burned a second time will teach me to not put my
> volunteer time in non-copyleft packages provided by a single
> corporation.

While it's certainly true that contributing into a project with
single-corp-control + non-copyleft has uncertain odds to take, at
least everyone is on the same footing. I think, as Lucas has mentioned,
the most problematic aspect in this kind of cases is where there are
both single-corp-control and a CLA, as that's what grants the possibility
of a relicense and this asymmetrical relationship, which could have
happened here as well even with a copyleft license. (Out of principle
I never sign CLAs for my volunteer work, with the exception of the one
for the FSF due to its nature and its assurances, but which I supposedly
rescinded some time ago anyway.)

Thanks,
Guillem

Bug#967790: urfkill: depends on deprecated GTK 2

[Bastian Germann]

Please just drop the gir1.2-gtk-2.0 build dependency.
The package builds fine without it.

Bug#1050395: RM: cccd -- RoQA; depends on gtk2; low popcon; unmaintained; dead upstream

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:cccd

Please remove cccd. It has a low popcon and depends on gtk2. It is dead 
upstream and unmaintained in Debian (last maintainer upload in 2012).

There are tons of alternatives in Debian.

Bug#1050394: RM: gcx -- RoQA; depends on gtk2; low popcon; unmaintained

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gcx

Please remove gcx. It has a low popcon and depends on gtk2. It is 
essentially unmaintained (both upstream and in Debian). Nobody cared to 
import the newer (but also decade old) release.

Bug#1041804: showq: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Bastian Germann]

Control: forwarded -1 https://github.com/evandelisle/showq/issues/35

A GTK3 port was being worked on but that effort has stalled.

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[John Zaitseff]

Package: emacs-common
Version: 1:29.1+1-4

The latest (Sid) version of emacs-common now depends on
"dconf-gsettings-backend | gsettings-backend", which in turn
eventually installs dbus-daemon -- which is problematic in a Debian
build chroot environment.  Can that dependency be downgraded to
Recommends or Suggests?

Yours truly,

John Zaitseff

-- 
John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
Australia Inc.  ╰───╯   https://www.zap.org.au/~john/

Bug#1050392: RM: sdlbasic -- ROM (team); depends on gtk2; low popcon; unmaintained

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:sdlbasic

Please remove sdlbasic. It has a low popcon and depends on gtk2. It is 
essentially unmaintained (both upstream and in Debian). Nobody cared to 
import the newer (but also decade old) release.

Bug#967843: yabause: depends on deprecated GTK 2

[Bastian Germann]

Please just drop the yabause-gtk package. It will not be ported to any 
later GTK version as upstream is dead.

Bug#1050391: Debian version is out of date

[Bjarni Ingi Gislason]

Package: diffutils
Version: 1:3.8-4
Severity: normal

Dear Maintainer,

  Debian has missed version 3.9 (2023-01-16) and 3.10 (2013-05-21).


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

Kernel: Linux 6.4.4-2 (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 diffutils depends on:
ii  libc6  2.37-7

diffutils recommends no packages.

Versions of packages diffutils suggests:
pn  diffutils-doc  
ii  wdiff  1.2.2-5

-- no debconf information

Bug#1050390: ftp.debian.org: Please process the loadlin BYHAND

[Samuel Thibault]

Package: ftp.debian.org
Severity: important

Hello,

Could somebody do something about the loadlin BYHAND currently pending?
This prevents me from uploading a newer version.

The updated loadlin.exe and loadlin.txt should be installed in
http://deb.debian.org/debian/tools/

Samuel

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Alexandru,

On Fri, 18 Aug 2023 02:07:46 +0300 Alexandru Mihail 
 wrote:

> >After that, let's talk about uploading.  Think about whether you'd
> >like
> >to start gaining practice with dput (or dput-ng), or whether you'd
> >like
> >me to sponsor directly from git.
> I'm pretty ambivalent to both..are you more comfortable with either one
> ? I'd reckon practice with dput might help me in the case where I
> become an uploading maintainer with full rights?

They're about the same for me.  Honestly I'd prefer to do a git upload
at this time, and save the GPG key discussion for your next upload.  We
can use dput and mentors then, and I think we'll both agree that we've
both worked hard enough for this first upload haha.

> Cheers, we're getting close :D !

Indeed, I just merged, congratulations!

At this point, please do a "dch -r" and ensure that the changelog entry
is refinalised; this will update the date stamp.  Hint: you may have to
make do a noop edit like + to make this work properly.
Commit the new changelog entry with a message like:

Release 1.30-4 to unstable.

And push that to the remote we're using for your MR.  Then make an
annotated and optionally GPG signed tag.  I like to use "gbp tag" for
this, but you can use whatever method you prefer.  Please make sure the
annotated tag is on the master branch and not a detached head.  Let me
know, and I'll review, and upload when everything looks good, as it no
doubt will.

Then I'll give you push permissions so you can push the release commit
and tag to the actual project repository :)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#967770: threadscope: depends on deprecated GTK 2

[Bastian Germann]

Control: forwarded -1 https://github.com/haskell/ThreadScope/issues/100

There is a discussion to port the program away from gtk2.
I do not think this is going to happen soon.

Bug#967641: mozc Qt

[Bastian Germann]

On Sun, 17 Apr 2022 08:04:42 +0900 SHITAMORI Akira wrote:> Upstream has 
moved to QT based


Seems like the build system has to be switched over to bazel to build 
everything including moz_renderer with Qt.

Bug#1050168: FTBFS: test_no_local_cert: tlsv13 alert certificate required

[Alberto Bertogli]

On Mon, Aug 21, 2023 at 05:32:53PM +0800, Shengjing Zhu wrote:

Source: kxd
Version: 0.15-4
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: albert...@blitiri.com.ar, z...@debian.org

I'm not sure if it's related to golang-defaults -> golang-1.21 recently.


[...]

Traceback (most recent call last):
 File "/<>/tests/run_tests", line 360, in test_no_local_cert
   self.assertEqual(err.reason, "SSLV3_ALERT_BAD_CERTIFICATE")
AssertionError: 'TLSV13_ALERT_CERTIFICATE_REQUIRED' != 
'SSLV3_ALERT_BAD_CERTIFICATE'
- TLSV13_ALERT_CERTIFICATE_REQUIRED
+ SSLV3_ALERT_BAD_CERTIFICATE


Thanks for filing this!

Yeah I think it's likely, this looks like a more specific and accurate 
error is now reported in this case, either due to the Go TLS library, or 
OpenSSL (which the tests use because they're written in Python).


I have a patch in the `next` branch that should update the test 
accordingly:


https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340/

https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340.patch

Would you mind giving it a try? It should solve the problem.

Thanks!
Alberto

Bug#1016558: ITA: muse-el

[Nicholas D Steeves]

Manphiz  writes:

> Nicholas D Steeves  writes:
>>> Nicholas D Steeves  writes:
>>
>
> Should have removed the redundant signatures and reuploaded to
> https://keys.openpgp.org, though I don't think I had 5 signatures on the
> same IDs? Anyway, PTAL.

Web interface:
keys.openpgp.org
Error: No key found for email address manp...@gmail.com

$ gpg --search-keys manp...@gmail.com
gpg: data source: https://keys.openpgp.org:443
gpg: key "manp...@gmail.com" not found on keyserver
gpg: keyserver search failed: Not found

Strictly speaking, you don't need to worry about your key until you
start wanting to make uploads (mentors, Debian Maintainer per-package
upload privileges, Debian Developer uploading), so we can defer this.

>> What is your intention here?  Are you rebasing our package onto this
>> fork, or are you using the fork as a code dump, or something else?
>>
>
> Well to be honest I didn't realize the github one was a fork as the
> d/watch file had been pointing there.

"git blame debian/watch" to see who is to blame, and fix fdde4981, which
introduced this problem.

This is a blocker to uploading the package.

> Also from your other mail:

Thank you for merging these emails.

>> I found that this UTF8 issue was already fixed upstream:
>> 
>>   @@ -412,11 +433,11 @@
>>   
>> https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?h=externals/muse=be347db7f1ad56f0384f76011bfd148ff3352610
>> 
>> and note that it's now an official GNU project (via copyright assignment)
>> 
>>   Copyright (C) 2004-2020 Free Software Foundation, Inc.
>
> So it should be clear that the Savannah one should be considered the
> canonical upstream.  I'll update my question on github to ask for
> whether Alex want to forward the patches in his repo to Savannah as
> well.

Thanks.

> Also as a result, I've marked the patch as "Forwarded: not-needed".

Thank you.  Alternatively you can either cherry pick the upstream commit
(and export as quilt patch) and drop mine, or package a new upstream
snapshot from the savannah source, since that's what we're tracking.

>> Oh, there's one more thing that needs to be fixed before we upload:
>> Bug #1048114
>
> Attempted to fix it in [2] where I just regenerated the changing file in
> sbuild.
>
> [1] https://github.com/alexott/muse/issues/16
> [2] 
> https://salsa.debian.org/emacsen-team/muse-el/-/commit/f5c217162d9c6f45c971cec2b8c70b2794bb77fe

This doesn't look like the right approach to me, the changelog entries
related to it are unclear/misleading, and a description is missing in
the patch header.  Have you checked Savannah for a fix?  Rather than a
Debian-specific approach, it's best to stay close to upstream source
whenever possible.

If the issue is truly Debian-specific, then why not use dh_auto_clean or
dh_clean, or another cleaner method?


Thank you for your attention to detail.  We're just about done!
Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1050389: puppetserver: ExecReload fails when kill is not installed

[Jesse Hathaway]

Package: puppetserver
Version: 7.9.5-2
Severity: normal
X-Debbugs-Cc: je...@mbuki-mvuki.org

Dear Maintainer,

The systemd unit's ExecReload tries to use the kill binary directly, but
puppetserver does not depend on procps, it should either be added as a
dependency or the kill statement should be wrapped in sh -c so that the
kill shell builtin can be used instead:

  puppetserver.service: Failed at step EXEC spawning kill: No such file or 
directory

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

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

Versions of packages puppetserver depends on:
ii  default-jre-headless 2:1.17-74
pn  facter   
ii  jruby9.3.9.0+ds-8
pn  libclj-time-clojure  
pn  libclj-yaml-clojure  
pn  libclojure-java  
pn  libcomidi-clojure
pn  libcommons-exec-java 
ii  libcommons-io-java   2.11.0-2
pn  libcommons-lang-java 
pn  libdropwizard-metrics-java   
pn  libdujour-version-check-clojure  
pn  libjruby-utils-clojure   
pn  libkitchensink-clojure   
pn  libliberator-clojure 
pn  libprismatic-schema-clojure  
pn  libpuppetlabs-http-client-clojure
pn  libpuppetlabs-i18n-clojure   
pn  libpuppetlabs-ring-middleware-clojure
pn  libraynes-fs-clojure 
pn  libsemver-clojure
pn  libshell-utils-clojure   
pn  libslingshot-clojure 
pn  libssl-utils-clojure 
pn  libtrapperkeeper-authorization-clojure   
pn  libtrapperkeeper-clojure 
pn  libtrapperkeeper-comidi-metrics-clojure  
pn  libtrapperkeeper-filesystem-watcher-clojure  
pn  libtrapperkeeper-metrics-clojure 
pn  libtrapperkeeper-scheduler-clojure   
pn  libtrapperkeeper-status-clojure  
pn  libtrapperkeeper-webserver-jetty9-clojure
ii  libyaml-snake-java   1.33-2
ii  puppet-agent [hiera] 7.25.0-1bullseye
ii  ruby 1:3.1
pn  ruby-deep-merge  
pn  ruby-fast-gettext
pn  ruby-gettext 
pn  ruby-hocon   
pn  ruby-locale  
pn  ruby-puppet-resource-api 
pn  ruby-puppetserver-ca-cli 
pn  ruby-semantic-puppet 
pn  ruby-text

Versions of packages puppetserver recommends:
pn  puppet-module-puppetlabs-augeas-core   
pn  puppet-module-puppetlabs-cron-core 
pn  puppet-module-puppetlabs-host-core 
pn  puppet-module-puppetlabs-mount-core
pn  puppet-module-puppetlabs-selinux-core  
pn  puppet-module-puppetlabs-sshkeys-core  

puppetserver suggests no packages.

Bug#1050388: canu: autopkgtest generates unreasonably large artifacts

[Paul Gevers]

Source: canu
Version: 2.2+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: other

Dear maintainer(s),

Your package has an autopkgtest, great. However, it breaks the 
infrastructure. In the last version upload to unstable, the package 
started to save unreasonably large files as artifacts:


root@ci-worker13:/tmp/debci-worker-37061072-xELMvGodQM/autopkgtest-incoming/unstable/amd64/c# 
du -h --max-depth=0 canu/

256Mcanu/

which is more than our communication infrastructure can handle. Yes, 
we'll implement sane handling, but at the moment this test breaks the 
ci.d.n infrastructure. I have therefore put the package on our reject 
list, until either this bug is fixed, or our tooling handles this better.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050206: rust-test-case: Failed autopkgtest after 3.1.0-3

[Jonas Smedegaard]

Quoting Simon Quigley (2023-08-22 05:55:52)
> Since Jonas is in LowNMU, I've uploaded this patch to DELAYED/2 and committed 
> it in Git.
> 
> Jonas, feel free to cancel the upload (or tell me to) if you have a better 
> solution.

Oh, I saw this only after releasing the patch myself.

Thanks anyway!

 - Jonas

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

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

signature.asc
Description: signature

Bug#1050368: please provide full set of uAPI headers

[Dmitry Baryshkov]

On Wed, 23 Aug 2023 at 22:36, Bastian Blank  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Dmitry
>
> On Wed, Aug 23, 2023 at 08:10:17PM +0300, Dmitry Baryshkov wrote:
> > The linux-libc-dev package provides only a limited set of uAPI headers.
> > For example, scsi, drm, video, etc. headers are missing from the
> > package.
>
> scsi headers are shipped by libc6-dev, see #550130:
>
> | libc6-dev:amd64: /usr/include/scsi/scsi.h

This is a different header.

$ ls -1R include/uapi/scsi/
include/uapi/scsi/:
cxlflash_ioctl.h
fc
scsi_bsg_fc.h
scsi_bsg_mpi3mr.h
scsi_bsg_ufs.h
scsi_netlink_fc.h
scsi_netlink.h

include/uapi/scsi/fc:
fc_els.h
fc_fs.h
fc_gs.h
fc_ns.h

$ ls -1R /usr/include/scsi/
/usr/include/scsi/:
scsi.h
scsi_ioctl.h
sg.h


For example I wanted to use scsi_bsg_ufs.h to compile qbootctl.

> drm headers are shipped by libdrm-dev, see #572067.

This is not complete. Compare /usr/include/libdrm and include/uapi/drm.

armada_drm.h, etnaviv_drm.h, exynos_drm.h, habanalabs_accel.h,
ivpu_accel.h, lima_drm.h and several other headers are missing.
I checked msm_drm.h, the header which I care about, it is heavily outdated.

> video headers are shipped by linux-libc-dev:
>
> | linux-libc-dev:amd64: /usr/include/video/edid.h

Ack, these are up-to-date.

-- 
With best wishes
Dmitry

Bug#1043088: O: cvsutils -- CVS utilities for use in working directories

[Gioele Barabucci]

retitle 1043088 O: cvsutils -- CVS utilities for use in working directories
noowner 1043088
thanks

I'm marking cvsutils back as orphaned after the discussion in #1049461 and the upload of 
version 0.2.6 (last supported upstream release) in #1050386.


--
Gioele Barabucci

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Nicholas D Steeves]

"Adam D. Barratt"  writes:

> On Thu, 2023-08-03 at 10:39 -0400, Nicholas D Steeves wrote:
>> 
>> Thanks for the ACK, and for the reminder!  I had forgotten to run dch
>> with "--team", so I fixed that, and uploaded.
>> 
>
> I'm not sure what happened to the upload, but there appears to be no
> sign of it in either the queued or dak logs.

Oh my!  Thank you for letting me know, I truly appreciate it.

I checked my local build output and to-upload directory/queue and found
that the package hadn't been signed, which means that my sign+upload
command timed out requesting key signing password...which happened due
to a horribly timed trustdb check (then I ran out of time).  Gah.  I've
filed a debsign bug requesting feedback, since --no-auto-check-trustdb
should probably be default for signing changes file.

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#967759: sugar-artwork: depends on deprecated GTK 2

[Bastian Germann]

Please just drop gtk2-engines-sugar and the libgtk2.0-dev build 
dependency. The sugar framework has moved on to gtk3 in Debian.

Bug#1050387: debsign: please run with --no-auto-check-trustdb (or allow it to be set)

[Nicholas D Steeves]

Package: devscripts
Version: 2.23.4
Severity: normal

Earlier this month I attempted to upload a security-related stable-pu;
however, "debsign foo.changes && dput foo.changes" never reached the
dput stage, because GPG decided that it was a good time to update the
trustdb.  Updating the trustdb takes about five minutes on my system,
and it runs this before running pinentry to actually make the
signature.  I ran out of free time while waiting.

An up-to-date trustdb isn't needed to sign a changes file, so I think 
--no-auto-check-trustdb should be debsign's default.  Alternatively, please 
allow it to be set as a config option.

It looks like this would be a trivial patch, but I'd like to confirm with 
others that this would be a good idea, and that I'm not just biased!


Thank you,
Nicholas

I consulted the changelog of 2.23.6 to confirm this bug is still outstanding.

-- Package-specific info:

--- /etc/devscripts.conf ---
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_MAINTTRAILER=yes
DEBSIGN_KEYID=E2A6261E3900AED7CDC667085A8830475F7D1061
DPKGSIG_KEYID=E2A6261E3900AED7CDC667085A8830475F7D1061
NMUDIFF_DELAY=7
USCAN_DESTDIR=/home/sten/devel/tarballs

--- ~/.devscripts ---
Empty.

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

Kernel: Linux 6.1.0-11-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
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  gnupg22.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libc6 2.36-9+deb12u1
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.68-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.2-1+b1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.1
ii  curl7.88.1-10+deb12u1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput1.1.3
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.26-3
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.17-1
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  at   3.2.5-1+b1
ii  autopkgtest  5.28
pn  bls-standalone   
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
ii  diffoscope   240
pn  disorderfs   
ii  dose-extra   7.0.0-1+b2
pn  duck 
ii  elpa-devscripts  40.5
ii  faketime 0.9.10-2.1
ii  gnuplot  5.4.4+dfsg1-2
ii  gnuplot-qt [gnuplot] 5.4.4+dfsg1-2+b2
ii  how-can-i-help   17
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
ii  libyaml-syck-perl1.34-2+b1
ii  mailutils [mailx]1:3.15-4
pn  mmdebstrap   
pn  mozilla-devscripts   
ii  mutt 2.2.9-1+b1
ii  openssh-client [ssh-client]  1:9.2p1-2
ii  piuparts 1.1.7
pn  postgresql-client
pn  pristine-lfs 
ii  quilt

Bug#967654: nitrogen: depends on deprecated GTK 2

[Bastian Germann]

Control: forwarded -1 https://github.com/l3ib/nitrogen/issues/27

Bug#1050386: RFS: cvsutils/0.2.6-1 [QA] -- CVS utilities for use in working directories

[Gioele Barabucci]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cvsutils":

 * Package name : cvsutils
   Version  : 0.2.6-1
   Upstream contact : Pavel Roskin 
 * URL  : https://www.red-bean.com/cvsutils/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/cvsutils
   Section  : devel

The source builds the following binary packages:

  cvsutils - CVS utilities for use in working directories

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/cvsutils/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cvsutils/cvsutils_0.2.6-1.dsc


Changes since the last upload:

 cvsutils (0.2.6-1) unstable; urgency=medium
 .
   * QA upload
   * New upstream version 0.2.6

Regards,

--
Gioele Barabucci

Bug#1050195: libwebsockets: Unfortunately the change from #977637 has been lost

[GCS]

Hi Joachim,

On Mon, Aug 21, 2023 at 9:03 PM Joachim Zobel  wrote:
> Unfortunately the change that sets LWS_WITH_EXTERNAL_POLL to ON has been lost
> together with the changelog entry for 4.0.20-2.
 Indeed, it's not enabled anymore. It's still don't recommended by its
developers, the option itself states:
option(LWS_WITH_EXTERNAL_POLL "Support external POLL integration using
callback messages (not recommended)" OFF)

I'm going to re-enable it, but you should refactor your code in the
long run not to depend on it.

Regards,
Laszlo/GCS

Bug#1050196: exim4: EBADF when looking up .forward files

[Erik Huelsmann]

Hi Andreas,

On Tue, Aug 22, 2023 at 10:17 AM Andreas Metzler  wrote:

> is thisv reproducible for you?


Yes.


> What do the logfiles say for this delivery?


$ zgrep 1qTkmU-00F3DW-2D /var/log/exim4/mainlog*
/var/log/exim4/mainlog.10.gz:2023-08-13 00:10:02 1qTkmU-00F3DW-2D internal
problem in userforward router (recipient is ehuelsm...@common-lisp.net):
failure to transfer data from subprocess: status= readerror='Bad file
descriptor'


> Can you tell me more about the forward files, are they
> exim-filter ones or classic ones?
>

$ cat /home/ehuelsmann/.forward
ehu...@gmail.com


> For debugging I just used
>
> | logger
>
> as .forward and ended up with the expected in mainlog
> 2023-08-22 10:10:58 1qYMTa-Vw-05 <= ametz...@bebt.de H=localhost (
> argenau.bebt.de) [::1] P=esmtps
> X=TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=no S=531
> id=20230822101057.001...@argenau.bebt.de
> 2023-08-22 10:10:58 1qYMTa-Vw-05 => | logger 
> R=userforward T=address_pipe
> 2023-08-22 10:10:58 1qYMTa-Vw-05 Completed
>
> and journal
> Aug 22 10:10:58 argenau ametzler[1984]: From ametz...@bebt.de Tue Aug 22
> 10:10:58 2023
> Aug 22 10:10:58 argenau ametzler[1984]: Received: from localhost ([::1]
> helo=argenau.bebt.de)
> [...]
>
>
Thanks. There's nothing specific in the "journalctl" data. The logs from
mainlog were included above.

By the way, this happens to a whole slew of users, not just this one.


Regards,

Erik.

Bug#1050385: driftnet: Import new upstream release

[Bastian Germann]

Source: driftnet
Severity: normal
Version: 1.4.0-2
Control: block 967319 by -1

driftnet version 1.5.0 was released with gtk3 support.
Please update the version in Debian.

Bug#1050384: bookworm-pu: package awstats/7.8-3+deb12u1

[Lourisvaldo Figueredo Junior]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: awst...@packages.debian.org, lourisva...@figueredo.tec.br
Control: affects -1 + src:awstats

[ Reason ]
The package has a policy violation caused by an error in the postinst file.

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

The bug was introduced in version 7.8-2+deb11u1 (bullseye), and I am fixing it
backwards.

[ Impact ]
If not fixed, the package will not be able to move on to testing and will be
out of trixie.

[ Tests ]
Manual tests only. I have tested following the upgrade from buster to bullseye
and then to bookworm and sid.

[ Risks ]
Trivial

[ 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 stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
  * debian/awstats.postinst: part of the code was moved to the awstats.preinst
file, to avoid creating the
/etc/logrotate.d/httpd-prerotate/awstats.dpkg-new file, and thus requiring
user interaction when updating. See #1037213.
  * debian/awstats.preinst: created.
diffstat for awstats-7.8 awstats-7.8

 awstats.postinst |7 ---
 awstats.preinst  |   28 
 changelog|   11 +++
 3 files changed, 39 insertions(+), 7 deletions(-)

diff -Nru awstats-7.8/debian/awstats.postinst 
awstats-7.8/debian/awstats.postinst
--- awstats-7.8/debian/awstats.postinst 2022-12-04 16:52:31.0 -0300
+++ awstats-7.8/debian/awstats.postinst 2023-08-22 22:10:53.0 -0300
@@ -17,13 +17,6 @@
chown www-data:www-data /var/cache/awstats
chmod 750 /var/cache/awstats
fi
-   # clean-up old script that didn't run
-   if [ -n "$2" ]; then
-   if dpkg --compare-versions "$2" lt '7.8-1~'; then
-   rm -f /etc/logrotate.d/httpd-prerotate/awstats/prerotate.sh
-   rmdir /etc/logrotate.d/httpd-prerotate/awstats/ || true
-   fi
-   fi
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
diff -Nru awstats-7.8/debian/awstats.preinst awstats-7.8/debian/awstats.preinst
--- awstats-7.8/debian/awstats.preinst  1969-12-31 21:00:00.0 -0300
+++ awstats-7.8/debian/awstats.preinst  2023-08-22 22:10:53.0 -0300
@@ -0,0 +1,28 @@
+#! /bin/sh
+
+set -e
+
+case "$1" in
+upgrade)
+   # clean-up old script that didn't run
+   if [ -n "$2" ]; then
+   if dpkg --compare-versions "$2" lt '7.8-1~'; then
+   rm -f /etc/logrotate.d/httpd-prerotate/awstats/prerotate.sh
+   rmdir /etc/logrotate.d/httpd-prerotate/awstats/ || true
+   fi
+   fi
+;;
+
+install|abort-upgrade|abort-remove|abort-deconfigure)
+
+;;
+
+*)
+echo "preinst called with unknown argument \`$1'" >&2
+exit 0
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff -Nru awstats-7.8/debian/changelog awstats-7.8/debian/changelog
--- awstats-7.8/debian/changelog2022-12-04 16:52:31.0 -0300
+++ awstats-7.8/debian/changelog2023-08-22 22:10:53.0 -0300
@@ -1,3 +1,14 @@
+awstats (7.8-3+deb12u1) bookworm; urgency=medium
+
+  * QA upload.
+  * debian/awstats.postinst: part of the code was moved to the awstats.preinst
+file, to avoid creating the
+/etc/logrotate.d/httpd-prerotate/awstats.dpkg-new file, and thus requiring
+user interaction when updating. See #1037213.
+  * debian/awstats.preinst: created.
+
+ -- Lourisvaldo Figueredo Junior   Tue, 22 Aug 
2023 22:10:53 -0300
+
 awstats (7.8-3) unstable; urgency=medium
 
   * QA upload.

Bug#1050383: setup-storage confused by valid md device names

[norman]

Package: fai-setup-storage
Version: 6.0.3
Severity: important

(setup-storage identifies itself as 6.0.3; to be precise it's the
version pre-installed in the faicd64-ubuntu-only_6.0.3.iso
CD image.  The bug was also present in 5.10.1/faicd64-ubuntu-only_5.10.1+3.iso
but we were too harried back then to remember to report the problem;
sorry about that.)

Setup-storage expects a numeric /dev/mdN device to have at least
three digits: /dev/md123 or /dev/md000 is expected, /dev/md0 or
/dev/md12 is not.  It's mistaken: /dev/md0 and /dev/md12 (and any
md device with one or two digits) are valid to Linux.

The effect is that if told to partition /dev/md0, setup-storage
doesn't understand that partition 1 on that device is /dev/md0p1;
it tries /dev/md01.  That in turn is diagnosed as an invalid
device name; setup-storage aborts; so does the install.

The problem seems to be in two regexps in setup-storage/Init.pm,
which use md\d{3,} (i.e. match three or more digits).  I worked
around the problem by changing it to md\d+ (i.e. one or more digits).
Maybe what was originally intended was md\d{1,3} (at least one digit,
at most three), and that would work for now because (as I understand
it) the current md implementation can't handle more than 512 arrays;
but it seems wiser to lift the limit as future-proofing.

Here's a diff -c showing what I did to get our installs working:


*** Init.pm.stock   Wed Aug 23 13:51:21 2023
--- Init.pm Wed Aug 23 13:52:14 2023
***
*** 207,213 
  return (1, "/dev/$1", $2);
}
elsif ($dev =~
! 
m{^/dev/(loop\d+|cciss/c\d+d\d+|ida/c\d+d\d+|md\d{3,}|md/\w+\d*|rd/c\d+d\d+|ataraid/d\d+|etherd/e\d+\.\d+|nvme\d+n\d+|mmcblk\d+)(p(\d+))?$})
{
  defined($2) or return (1, "/dev/$1", -1);
  return (1, "/dev/$1", $3);
--- 207,213 
  return (1, "/dev/$1", $2);
}
elsif ($dev =~
! 
m{^/dev/(loop\d+|cciss/c\d+d\d+|ida/c\d+d\d+|md\d+|md/\w+\d*|rd/c\d+d\d+|ataraid/d\d+|etherd/e\d+\.\d+|nvme\d+n\d+|mmcblk\d+)(p(\d+))?$})
{
  defined($2) or return (1, "/dev/$1", -1);
  return (1, "/dev/$1", $3);
***
*** 289,295 
  sub make_device_name {
my ($dev, $p) = @_;
$dev .= "p" if ($dev =~
! 
m{^/dev/(loop\d+|cciss/c\d+d\d+|ida/c\d+d\d+|md\d{3,}|md/\w+\d*|rd/c\d+d\d+|ataraid/d\d+|etherd/e\d+\.\d+|nvme\d+n1|mmcblk\d+)$});
$dev .= $p;
internal_error("Invalid device $dev") unless (::phys_dev($dev))[0];
return $dev;
--- 289,295 
  sub make_device_name {
my ($dev, $p) = @_;
$dev .= "p" if ($dev =~
! 
m{^/dev/(loop\d+|cciss/c\d+d\d+|ida/c\d+d\d+|md\d+|md/\w+\d*|rd/c\d+d\d+|ataraid/d\d+|etherd/e\d+\.\d+|nvme\d+n1|mmcblk\d+)$});
$dev .= $p;
internal_error("Invalid device $dev") unless (::phys_dev($dev))[0];
return $dev;


And here's a snippet from fai.log showing the original error.
We have a hooks/partition.CLASS that initializes the md (after
using some local heuristics to decide which disks may be used
safely), then sets disklist=/dev/md, then returns to task_partition
which (with the original Init.pm) complaints and aborts:


Starting setup-storage 3.0
Using config file: /var/lib/fai/config/disk_config/UBUNTU_22_04
INTERNAL ERROR in setup-storage:
Invalid device /dev/md01
Please report this error to the Debian Bug Tracking System.
 at /usr/share/fai/setup-storage/Init.pm line 294, <$config_file> line 1.
FAI::make_device_name("/dev/md0", 1) called at 
/usr/share/fai/setup-storage/Parser.pm line 318
FAI::init_part_config("primary") called at (eval 86) line 7624

Parse::RecDescent::namespace01::type(Parse::RecDescent=HASH(0x560538a6c6c8),
 
"primary\x{9}/\x{9}72000\x{9}ext4\x{9}rw,errors=remount-ro\x{9}createopts=\"-m3\"\x{a}pr"...,
 1, undef, CODE(0x5605393d1048), undef) called at (eval 86) line 9569

Parse::RecDescent::namespace01::volume(Parse::RecDescent=HASH(0x560538a6c6c8),
 
"primary\x{9}/\x{9}72000\x{9}ext4\x{9}rw,errors=remount-ro\x{9}createopts=\"-m3\"\x{a}pr"...,
 1, undef, CODE(0x5605393e24b0), undef) called at (eval 86) line 716

Parse::RecDescent::namespace01::config(Parse::RecDescent=HASH(0x560538a6c6c8),
 
"primary\x{9}/\x{9}72000\x{9}ext4\x{9}rw,errors=remount-ro\x{9}createopts=\"-m3\"\x{a}pr"...,
 1, undef, CODE(0x5605393d0030), undef) called at (eval 86) line 3373

Parse::RecDescent::namespace01::line(Parse::RecDescent=HASH(0x560538a6c6c8),
 
"primary\x{9}/\x{9}72000\x{9}ext4\x{9}rw,errors=remount-ro\x{9}createopts=\"-m3\"\x{a}pr"...,
 1, undef, CODE(0x5605392109a0), undef) called at 
/usr/share/perl5/Parse/RecDescent.pm line 3275
Parse::RecDescent::_parserepeat(Parse::RecDescent=HASH(0x560538a6c6c8), 
"# \$Header: /admin/cvsroot/debian/FAI/fai/disk_config/UBUNTU_2"..., 
CODE(0x560538bc8920), 0, 1, undef, 
Parse::RecDescent::Expectation=HASH(0x5605393d1f70), CODE(0x5605392109a0), ...) 
called at (eval 86) line 2621

Bug#967459: gringotts: depends on deprecated GTK 2

[Bastian Germann]

There is a porting effort at
https://github.com/shlomif/gringotts/tree/convert-to-gtk3

I have not checked if it actually runs.

Bug#967329: etw: depends on deprecated GTK 2

[Bastian Germann]

Please consider removing etw. Its popcon is quite low and upstream seems 
to be dead.

Bug#1050368: please provide full set of uAPI headers

[Bastian Blank]

Control: tags -1 moreinfo

Hi Dmitry

On Wed, Aug 23, 2023 at 08:10:17PM +0300, Dmitry Baryshkov wrote:
> The linux-libc-dev package provides only a limited set of uAPI headers.
> For example, scsi, drm, video, etc. headers are missing from the
> package.

scsi headers are shipped by libc6-dev, see #550130:

| libc6-dev:amd64: /usr/include/scsi/scsi.h

drm headers are shipped by libdrm-dev, see #572067.

video headers are shipped by linux-libc-dev:

| linux-libc-dev:amd64: /usr/include/video/edid.h

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.

Bug#1050348: ITP: melonds -- nintendo DS emulator

[Jonathan Dowland]

On Wed, Aug 23, 2023 at 03:07:15PM +, Mae Miller wrote:

I'm going to be packaging this as my first package partially because
it's a program I use and care about and partially in order to learn how
the system works and to make my first contribution to debian.


Those are great reasons!

Can melonDS be usefully used without a BIOS/firmware dump from a DS?

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1040370: marked as pending in python-zeep

[Alexandre Detiste]

Hi,

I verified: python3-six also needs to be dropped from Depends:

Greetings



>
> debian/control
> Update Build-Deps (Closes: #1040370).
>
>
> https://bugs.debian.org/1040370
>

Bug#1050356: RFS: melonds/0.9.5 [ITP] -- nintendo DS emulator

[Mae Miller]

Mae Miller  writes:

> Bo YU  writes:
>
>> Hi!
>>
>> On Thu, Aug 24, 2023 at 12:15 AM Mae Miller  wrote:
>>>
>>> Package: sponsorship-requests
>>> Severity: wishlist
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "melonds":
>>>
>>>  * Package name : melonds
>>>Version  : 0.9.5
>>>Upstream contact : Arisotura
>>>  * URL  : https://melonds.kuribo64.net/
>>>  * License  : GPL-3
>>>  * Vcs  : https://github.com/melonDS-emu/melonDS
>>>Section  : games
>>>
>>> The source builds the following binary packages:
>>>
>>>   melonds - nintendo DS emulator
>>>
>>> To access further information about this package, please visit the 
>>> following URL:
>>>
>>>   https://mentors.debian.net/package/melonds/
>>>
>>> Alternatively, you can download the package with 'dget' using this command:
>>>
>>>   dget -x 
>>> https://mentors.debian.net/debian/pool/main/m/melonds/melonds_0.9.5.dsc
>>
>> I am not a DD but got:
>> ```
>> dpkg-buildpackage: info: host architecture amd64
>>  fakeroot debian/rules clean
>> dh clean
>>dh_clean
>>  debian/rules build
>> dh build
>>dh_update_autotools_config
>>dh_autoreconf
>>dh_auto_configure
>> cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake
>> -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_
>> SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
>> -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
>> -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND
>> _PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON
>> -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=O
>> N "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
>> -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
>> Can't exec "cmake": No such file or directory at
>> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 518.
>> dh_auto_configure: error: exec (for cmd: cmake
>> -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None
>> -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_
>> INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
>> -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
>> -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGI
>> STRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON
>> -DCMAKE_INSTALL_RUNSTATEDIR=/run
>> -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DC
>> MAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu
>> ..) failed: No such file or directory
>> dh_auto_configure: error: cd obj-x86_64-linux-gnu &&
>> DEB_PYTHON_INSTALL_LAYOUT=deb cmake -DCMAKE_INSTALL_PREFIX=/usr
>> -DCMAKE_BUILD_TYPE=Non
>> e -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
>> -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTR
>> Y=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
>> -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run
>> -DCMAKE_SKIP_INSTAL
>> L_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
>> -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 2
>> make: *** [debian/rules:3: build] Error 2
>> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 
>> 2
>>
>> ```
>> maybe you need build the package in a pure chroot.
>>
>> BR,
>> Bo
>>>
>>> Changes for the initial release:
>>>
>>>  melonds (0.9.5) UNRELEASED; urgency=medium
>>>  .
>>>* Initial release. (Closes: #1050348)
>>>
>>> Regards,
>>>
>>> --
>>> Mae Miller (it/she)
>>
> Oh shoot, thank you!
>
> -- 
> Mae Miller (it/she)

Ok tested in a chroot and it should be working now.

-- 
Mae Miller (it/she)


signature.asc
Description: PGP signature

Bug#1050382: libusbgx-dev: package description wrongly refers to libpng

[Daniele Forsi]

Package: libusbgx-dev
Version: 0.2.0-2
Severity: minor
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

the last line of the description of the package libusbgx-dev reads:
This package contains the header and development files needed to build programs 
and packages using libpng.

however the name of the library should be libusbgx instead of libpng.

thanks,
Daniele

Bug#1042246: gdcm: FTBFS: make[1]: *** [debian/rules:107: override_dh_auto_configure] Error 2

[Aurelien Jarno]

Hi,

On 2023-07-26 22:24, Lucas Nussbaum wrote:
> Source: gdcm
> Version: 3.0.21-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230726 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 

I have started to investigate this, but my cmake knowledge is quite
limited, so I am progressing slowly. Here are my findings:

- The issue has been introduced by cmake 3.27. gdcm builds fine with
  cmake from stable and everything else from sid.

- The reported issue seems to be linked to a cache issue between the two
  libexpat detection: the one from gdcm in CMakeLists.txt:423 and using
  find_package() and the one shipped by libvtk9-dev in 
  $DEB_HOST_MULTIARCH/cmake/vtk-9.1/FindEXPAT.cmake: using
  find_library(). Dropping the first one or passing NO_CACHE to
  find_library() is enough to get rid of the issue.

- The issue is only visible with DGDCM_USE_SYSTEM_EXPAT:BOOL=ON which is
  not the default, so it is likely that the issue hasn't been noticed
  before.

- Independently of the reported issue, gdcm still uses find_package()
  with PythonInterp or PythonLibs which have been removed from cmake
  3.27, so fixing it is not enough to get gdcm working.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1050381: unison-2.52: Please drop after 2.53 import

[Bastian Germann]

Source: unison-2.52
Severity: wishlist
Control: block 967559 by -1

#880541 requests unison-2.53. When that is packaged (maybe as 
reintroduction of the old unison source package?) please drop 
unison-2.52, which is the most popular lablgtk2 package.

Bug#1047444: t50: Fails to build source after successful build

[Peter Wienemann]

Control: tags -1 + patch

See https://salsa.debian.org/pkg-security-team/t50/-/merge_requests/1

Bug#1049683: t50: Fails to build binary packages again after successful build

[Peter Wienemann]

Control: tags -1 + patch

See https://salsa.debian.org/pkg-security-team/t50/-/merge_requests/1

Bug#1042023: opm-common: FTBFS on armel and mipsel

[Markus Blatt]

Hi,


FYI the binary packages for architecture armel and mispel have now been removed 
from unstable.

As the FTBFS is not fixed and never will be I won't close this bug but leave it 
as it is.

If other prefer to close it that is of course fine with me.

Cheers,

Markus

Bug#1050380: dhcpcd-run-hooks.8 man page missing

[Joey Hess]

Package: dhcpcd
Version: 1:10.0.2-4
Severity: normal

The man pages refer to this man page, but it's not included in the
binary package. (It is in the source, hooks/dhcpcd-run-hooks.8.in)

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

Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 dhcpcd depends on:
pn  dhcpcd-base
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.07-1

dhcpcd recommends no packages.

Versions of packages dhcpcd suggests:
pn  dhcpcd-gtk  

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#880541: RFP: unison2.48.3 -- file-synchronization tool for Unix and Windows

[Bastian Germann]

Control: retitle -1 RFP: unison-2.53 -- file-synchronization tool
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org, glo...@debian.org

On Thu, 2 Nov 2017 01:11:32 +0100 Vincent Lefevre  
wrote:

* Package name: unison2.48.3
  Version : 2.48.3
  Upstream Author : Benjamin Pierce 
* URL : see unison package from stretch
* License : see unison package from stretch
  Programming Lang: OCaml
  Description : file-synchronization tool for Unix and Windows


That old package version should not be introduced in Debian anymore.
Please package version 2.53.x, which depends on lablgtk3 instead of 
lablgtk2.

Bug#1003724: I would like to help implement this item

[Maarten van Geijn]

Hi all,

Looks like this request is out there for a while. I am a user of this 
package as well and I have been looking into how to upgrade this 
upstream version and I would like to help with this.


I found the most recent version is 7.8.1, I would suggest to upgrade to 
this version instead, unless there is any objection against it.


I just need a little guidance on how to get seasoned for debian package 
maintenance (am responsible for package maintenance for production 
systems, but not within the debian context).


I have the new version building locally, but someone experienced will 
need to review this and all being well approve.


Regards

Maarten

Bug#1003724: I would like to help implement this item

[Maarten van Geijn]

Hi all,

Looks like this request is out there for a while. I am a user of this 
package as well and I have been looking into how to upgrade this 
upstream version and I would like to help with this.


I found the most recent version is 7.8.1, I would suggest to upgrade to 
this version instead, unless there is any objection against it.


I just need a little guidance on how to get seasoned for debian package 
maintenance (am responsible for package maintenance for production 
systems, but not within the debian context).


I have the new version building locally, but someone experienced will 
need to review this and all being well approve.


Regards

Maarten

Bug#1050001: Unwinding directory aliasing

[Ansgar]

Hi,

On Wed, 2023-08-23 at 17:04 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"):
> > What do you consider to be the end goal of this proposal?
> 
> Desired end state
> =
> 
> This is a very good question.  I had a very constructive conversation
> with Helmut via video chat.  It seems that there's a misunderstanding
> about the desired end state.
> 
> My idea of a desired end state is as follows:
> 
> /bin and /lib etc. remain directories (so there is no aliasing).  All
> actual files are shipped in /usr.  / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is
> needed
> (which is far from all of them).  Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.

Cool, so we need to touch all packages shipping packages in /usr/bin to
also include a /bin symlink? Like /bin/python3 -> /usr/bin/python3?
(And yes, users use these, so they are necessary unless you want to
break working systems; if so please provide good reasons).

How do you decide when to remove a link? Is there a simple mechanism to
detect when users no longer use it?

> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.

Why should we invent again another, incompatible filesystem layout?

Is there any good technical reason to do so? One that was not discussed
already?

Sorry, I feel like we are going back ignoring any discussion in the
last years and would invite you to read what was discussed about these
approaches in previous discussions first.  So far it looks like NIH
syndrome, similar to the need to invent yet another daemon readiness
protocol when systemd was the topic.


> Looking towards the future
> --
> 
> It seems to me that directory aliasing will continue to be a source
> of very annoying bugs indefinitely, well after the transition is
> fully complete.  In another 20 years we'll still be debugging strange
> installation breakage that will turn out to be due to directory
> aliasing.

But introducing an incompatible filesystem where we only detect that
something references files in the wrong path (as presumably only a
random subset will be in /bin) will not give any bugs?

We already *had* these bugs for several releases and found them only
after release (even before usrmerge which makes them non-bugs).

Please provide a plan how to fix these ahead of time; please be aware
that they might only occur with some hardware / configurations.


Ansgar

Bug#1050379: ITP: qmidictl -- graphical application sending MIDI data over the network

[Nicolas Boulenguez]

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 
X-Debbugs-Cc: debian-de...@lists.debian.org, benoit.delc...@gmail.com

* Package name: qmidictl
  Version : 0.9.10
  Upstream Contact: rncbc at rncbc dot org
* URL : https://www.rncbc.org
* License : GPL-2+, LGPL-2.1, FSFAP
  Programming Lang: C++, Qt
  Description : graphical application sending MIDI data over the network

Originally inspired by multimidicast, the qmidictl application
displays a window with controls imitating a MIDI control surface.  It
emits the MIDI instructions over the network using UDP/IP multicast.

Programs like qmidinet on Linux or ipMIDI on Windows are then able to
receive, translate and forward the MIDI flow.

A friend intends to use it on its Pinephone.
There is no similar package in Debian yet.

Bug#1050001: Unwinding directory aliasing

[Helmut Grohne]

Hi Ian,

On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> Desired end state
> =
> 
> This is a very good question.  I had a very constructive conversation
> with Helmut via video chat.  It seems that there's a misunderstanding
> about the desired end state.

I concur. Thank you for taking the time to write this down. It now makes
a lot more sense to me.

> My idea of a desired end state is as follows:
> 
> /bin and /lib etc. remain directories (so there is no aliasing).  All
> actual files are shipped in /usr.  / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is needed
> (which is far from all of them).  Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.

This end state vaguely makes sense to me in principle. I think it does
have a two noteworthy limitations though.

 * Basically every other distro uses aliasing now. I expect that
   a few upstreams have stopped paying attention to systems in your end
   state. Therefore, they may not only hard code paths in /usr/bin, but
   also the other way round assume that everything is to be found in /.
   I see that we already use #!/bin/python3 e.g. in
   https://sources.debian.org/src/uchardet/0.0.7-1/script/langs/sv.py/?hl=1#L1
   and expect more of that in future.
 * A key motivation cited for doing the merged-/usr work is called
   "hermetic /usr". I'm not a hermetic /usr expert, but roughly speaking
   the idea is that the entire OS actually lives below /usr and
   everything else is either the user's data or constructed in a
   straight forward way. Setting up the aliasing symlinks is easier and
   less prone to change over time than setting up the symlink farm that
   you are proposing.

> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.

What situation is desirable is dependent on whom you ask. We also have a
number of people who'd say that the aliasing approach is more desirable
than your approach. And then we have a large body of people who simply
want this to be over and not having to thing about /usr-merge
consequences anymore.

> Aliasing is EBW, and "Only use canonical names" is not good enough
> ==
> 
> There is basically one underlying technical reason for preferring the
> un-aliased usrmerge approach: aliasing directories in this way leads
> to great complication in file management, especially in package
> management software and in individual packages.

I'm not sure I follow this argument precisely. Ubuntu has shipped this
aliasing approach since quite a while including LTS releases. Debian has
defaulted to it in two stable releases. While there are complications,
my impression is that these complications mostly affect ourselves and
our package management while end users are mostly unaffected. Then once
packages have moved their files to canonical locations (as is proposed
in DEP-17), are there that much complications that remain?

> The DEP-17 problem list is a survey of the aliasing-induced problems
> which have been discovered so far.  But we (still!) keep discovering
> new ones.

Indeed, my main worry about this approach is discovering new classes of
problems. (And effects on downstreams and derivatives as you also point
out.)

> The current plan, as I understand it, is that we will fix these
> problems by arranging to *always* name files by their canonical paths,
> ie the ones in /usr.

I confirm.

> Naming files by their canonical names will have to be done everywhere.
> This is because any time a file is named by a non-canonical path, a
> program that tries to manipulate that file might malfunction.
> (Whether it malfunctions in practice depends on the precise details
> and gets very complicated.)

This seems overgeneralized to me. If you look into the list of known
problems from DEP-17, it's not like any program would be affected. It is
more like most of the problems affect dpkg. Also keep in mind that while
we want all files to be named canonically (according to DEP-17), the
problems we may see tend to scale with the number of exceptions to the
rule. So if we canonicalize most files, chances are that most users
don't experience symptoms anymore.

> Spotting and mitigating violations is hard
> --
> 
> We do not currently have good tooling that will spot violations of
> this rule.  It's not clear precisley what the right behaviour of our
> tools would be; we need to alert *the right set of users* to the
> mistakes, and *with the right level of severity*.  Many of our key
> tools don't have a good way to produce "critical warnings".  The
> consequences of violations are unpredicatable and can depend on event
> ordering.  But they can be very severe.  So we are creating a source
> of bad heisenbugs.

We already have the Debian Usr Merge Analysis Tool 

Bug#1040636: Kernel bug

[Hendrik Jaeger]

Hi

Regarding the kernel bug:
I found the following bug about this:
https://bugs.archlinux.org/task/78908
which led me to:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master=3e70489721b6c870252c9082c496703677240f53

Talking to people about it indicated that this bug is fixed in linux 6.1.43.

It might be better to reassign this to the linux kernel package.
Since this pretty much breaks a security relevant component in some scenarios 
and nftables is the default, I think severity should be raised to important.
And it would be nice to get an updated kernel without this issue into stable.

Cheers

henk


pgp9jw65qI30d.pgp
Description: OpenPGP digital signature

Bug#1050378: python3-selenium can't find a driver

[Frank de Bruijn]

Package: python3-selenium
Version: 4.11.2+dfsg-1
Severity: normal

After upgrading to version 4.11.2+dfsg-1, python3-selenium fails with:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/driver_finder.py", 
line 38, in get_path
path = SeleniumManager().driver_location(options) if path is None 
else path

   ^^
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/selenium_manager.py", 
line 73, in driver_location

args = [str(self.get_binary()), "--browser", browser]
^
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/common/selenium_manager.py", 
line 57, in get_binary
raise WebDriverException(f"Unable to obtain working Selenium 
Manager binary; {path}")
selenium.common.exceptions.WebDriverException: Message: Unable to obtain 
working Selenium Manager binary; 
/usr/lib/python3/dist-packages/selenium/webdriver/common/linux/selenium-manager


Reverting to 4.10.0+dfsg-1 clears the problem.

Using: Debian Testing 64-bit
Kernel: Linux asus 6.4.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-3 
(2023-08-08) x86_64 GNU/Linux

libc6: 2.37-7

Installed versions of packages python3-selenium depends on or recommends:
ii  python3 3.11.4-5+b1
ii  python3-certifi 2022.9.24-1
ii  python3-trio0.22.2-1
ii  python3-trio-websocket  0.10.3-1
ii  python3-urllib3 1.26.16-1
ii  chromium-driver 115.0.5790.170-1


This appears to be the same issue as reported here:
https://bugs.launchpad.net/ubuntu/+source/python-selenium/+bug/2032687

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[Vincent Blut]

Hi Björn,

Le 2023-08-15 07:49, Björn Persson a écrit :
> Hello, has there been any progress with this?

I started working on this a few days ago. I’ll try to send a merge request
over the weekend.

> […]
>
> Björn Persson

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#967294: coinst: depends on deprecated GTK 2

[Bastian Germann]

Please consider dropping the coinst-viewer package and the 
libcairo-ocaml-dev build dependency.

Bug#1050001: Unwinding directory aliasing

[Simon McVittie]

On Wed, 23 Aug 2023 at 17:04:36 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"):
> > What do you consider to be the end goal of this proposal?
> 
> My idea of a desired end state is as follows:
> 
> /bin and /lib etc. remain directories (so there is no aliasing).  All
> actual files are shipped in /usr.  / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is needed
> (which is far from all of them).  Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.

This is not merged-/usr with the meaning used by the technical committee's
past resolutions, and by most (all?) non-Debian distributions (among
which Fedora and Arch were among prominent early adopters).

I recognise that you don't want merged-/usr, and instead you want
this non-merged-/usr layout, which shares some of the properties of
merged-/usr; but it isn't the same thing, and it makes discussion
and reasoning unnecessarily difficult if we use the same name for two
different things, so please could you avoid the term "merged /usr"
for this?

> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.

The meaning ascribed to "merged /usr" or "the /usr merge" by previous
TC resolutions is exactly the layout where /bin and /lib (and so on)
are symlinks. Outside Debian, that's also the layout described in
documents like "The Case for the /usr Merge".

I acknowledge that, whatever we choose to call it, you would prefer not
to end at that state, and this is a point on which our opinions differ.

> The current plan, as I understand it, is that we will fix these
> problems by arranging to *always* name files by their canonical paths,
> ie the ones in /usr.

Using the word "canonical" is not necessarily helpful here, because
there are two reasonable-but-contradictory things you might mean by
it. Depending who you ask, the canonical path of /bin/sh on a system
with some sort of unified /usr might be:

* /usr/bin/sh, because that's the physical path as returned by realpath()
  (I believe this is what you mean when you say "canonical", because
  you're thinking in terms of the path canonicalization operation done
  by realpath() and similar things);

* or /bin/sh, because that's the interoperable path that has worked on
  all Linux distributions since time immemorial (even though this might
  not have anything to do with the physical path)

May I suggest we avoid saying "canonical" as ambiguous, and use something
like "physical path" and "traditional path" for these two concepts?

If by "name files" you mean references to filenames from elsewhere, then
that is not the plan as I understand it (see below).

If by "name files" you mean "name files in dpkg's database", then yes,
I believe the current plan is that we end up with dpkg's idea of the list
of installed files referring to every file by its physical path, so that
for example the dpkg database contains the physical path /usr/bin/sh,
even though the traditional path is /bin/sh. Another way to express
this is that if you install a Debian chroot and pack it into an archive
in the obvious way, what you should get (in the absence of any uses of
dpkg-divert, etc.) is the union of the data.tar of all the installed
packages, plus additional non-dpkg-managed files like /etc/passwd.

> Naming files by their canonical names will have to be done everywhere.

I would dispute that. We routinely name system-critical files by
non-physical paths - for example /bin/sh is really /{usr/,}bin/dash,
and /lib64/ld-linux-x86-64.so.2 is really
/{usr/,}lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 - and have done so
for a long time.

> violations of the "use only [physical] names" rule are not only
> expected, they are *necessary*:

Right, and that's why that is not a rule we are following.

One of the reasons that merged-/usr appeals to me personally is
that it takes an entire equivalence class of bugs, and turns them
into non-bugs. If merged-/usr is ubiquitous, then we don't need to
expect third-party software developers to "just know" that /bin/sh and
/usr/bin/perl are the traditionally "correct" paths, because /usr/bin/sh
and /bin/perl become equally valid and interoperable things to put at
the beginning of a script.

In the state we had before bookworm, where merged-/usr was supported but
not mandatory, we required Debian maintainers to be careful to refer to
files by their traditional name, even though on a newly-installed Debian
system with merged-/usr, the "other" name would have worked equally well;
and we were also implicitly expecting upstream and third-party developers
to also know that they had to use the traditional name, even if if was
unnecessary in their (maybe non-Debian) environment.

Of course, one of the problems with a simplifying assumption is that
it's one-way: as soon as we start to rely on /bin and /usr/bin being

Bug#1025568: gparted: diff for NMU version 1.3.1-1.1

[Phillip Susi]

Hugh McMaster  writes:

> I didn't see a need to build-depend on libpolkit-gobject-1-dev, but
> I'm not overly familiar with gparted's requirements.

I think something changed in 1.5 that made it require a file that moved
to this package in trixie, so I had to add it to get it to build.

> Please let me know if I should submit a PR for the NMU on salsa
> (noting you'd have to update the changelog to account for your recent
> changes), or whether I should cancel the upload.

Sorry for the late reply.  I would have said cancel it but it looks like
it already went through.  It sounds like it shouldn't hurt for me to
just upload my build though, so I'll do that now that I sorted out my
new signing subkey.

Bug#1050376: libocamlnet-gtk2-ocaml-dev: Drop this package

[Bastian Germann]

Package: libocamlnet-gtk2-ocaml-dev
Version: 4.1.9-2
Severity: wishlist
Control: block 967559 by -1

Please consider dropping the libocamlnet-gtk2-ocaml-dev, which does not 
seem to be used in Debian, and the liblablgtk2-ocaml-dev from the 
Build-Depends. I am filing this to track the reverse dependencies of 
lablgtk2.

Bug#1050377: ikiwiki: highlight plugin broken with highlight 4.x

[David Bremner]

Package: ikiwiki
Version: 3.20200202.3-1
Severity: important
Tags: patch upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The latest upload of highlight effectively breaks any ikiwiki install
using the highlight plugin, since the plugin crashes trying to run the
searchDataDir() method.

The attached patch switches to calling initSearchDirectories, per
upstream's migration guide. It seems to work on my site.

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

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

Versions of packages ikiwiki depends on:
ii  libhtml-parser-perl 3.81-1
ii  libhtml-scrubber-perl   0.19-2
ii  libhtml-template-perl   2.97-2
ii  libjson-perl4.1-1
ii  libmarkdown22.2.7-2
ii  libtext-markdown-discount-perl  0.16-1
ii  liburi-perl 5.19-2
ii  libyaml-libyaml-perl0.86+ds-1
ii  perl5.36.0-7

Versions of packages ikiwiki recommends:
ii  gcc [c-compiler] 4:13.2.0-1
ii  gcc-12 [c-compiler]  12.3.0-7
ii  gcc-13 [c-compiler]  13.2.0-2
ii  git [git-core]   1:2.40.1-1
ii  libauthen-passphrase-perl0.008-3
ii  libc6-dev [libc-dev] 2.37-7
ii  libcgi-formbuilder-perl  3.10-6
ii  libcgi-pm-perl   4.57-1
ii  libcgi-session-perl  4.48-4
ii  libcrypt-ssleay-perl 0.73.06-2+b1
ii  libgravatar-url-perl 1.07-2
ii  liblwpx-paranoidagent-perl   1.12-3
ii  libmail-sendmail-perl0.80-3
ii  libnet-openid-consumer-perl  1.18-2
ii  librpc-xml-perl  0.82-1
ii  libterm-readline-gnu-perl1.46-1
ii  libtimedate-perl 2.3300-2
ii  libxml-simple-perl   2.25-2

Versions of packages ikiwiki suggests:
ii  dvipng 1.15-1.1+b1
ii  file   1:5.44-3
ii  gettext0.21-13
ii  ghostscript10.01.2~dfsg-1
ii  graphviz   2.42.2-7+b3
ii  libfile-mimeinfo-perl  0.33-1
ii  libhighlight-perl  4.7-1
ii  libhtml-tree-perl  5.07-3
ii  libimage-magick-perl [perlmagick]  8:6.9.11.60+dfsg-1.6
ii  libimage-magick-q16-perl [perlmagick]  8:6.9.11.60+dfsg-1.6
ii  liblocale-gettext-perl 1.07-5
ii  libmagickcore-6.q16-6-extra [libmagickcore-extra]  8:6.9.11.60+dfsg-1.6
ii  libmailtools-perl  2.21-2
pn  libnet-amazon-s3-perl  
pn  libnet-inet6glue-perl  
pn  libsearch-xapian-perl  
ii  libsort-naturally-perl 1.03-4
pn  libsparkline-php   
ii  libtext-csv-perl   2.02-2
pn  libtext-multimarkdown-perl 
pn  libtext-textile-perl   
pn  libtext-typography-perl
pn  libtext-wikicreole-perl
pn  libtext-wikiformat-perl
ii  libxml-feed-perl   0.63+dfsg-1
ii  libxml-writer-perl 0.900-2
ii  po4a   0.69-1
pn  polygen
ii  python33.11.4-5+b1
ii  python3-docutils   0.19+dfsg-7
pn  texlive
ii  tidy   2:5.6.0-11
pn  viewvc | gitweb | viewcvs  
pn  xapian-omega   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmTmS5kACgkQA0U5G1Wq
FSHMSQ/9FVzXXphWk9RKdxdDrxIlAVJMIYgXEzMdnQAOre2YL/m2Zn4Y+DOaPa47
YOg7ZKdrr1TOCAuONX43Y/O0yMRbh0p9pvRwbn1lPYXpgeByzA2UwPerPmdqmqyH
ODXr9e7/by/0gjxYXF30lgZfZJDbuRzTuiLpPuFDICqdXJpIKgZeQVJqUjTa5mX4
2m0goEwZZ/m2Wt9C50UNGr/9bABPx+X01EH+6NEYoKjuU/EaYESLCc0v5KDPYced
ut3bRdhK5EAEtODE6l49iPax20sVJn814utWqwACrDuLgeqT2mIpOE1hzyfUW+kI
8cmFB1AEOyDFZrq+f9wvv14Z8k+UWJ+iQ8WBDrcCqvHncKGvGf904pQ5BcKvKWW8
P+JEZmkT8H59puF/UpPlJgQ0bCP7JWqgGXpIAvxUyBVN9R2oRDn6X/7TBgF1T1d0
6L6gXERCF0ZCLRQWgk7p6sXZzSHqxb4DiigtElITDXpstOUO4XhVfFNl5hGHxXY9
GB3AuLhpJ1724GbbzKB4U9CfHGjJfuiO5wlBKVDHBuG5AHXd6v+GepWZIGonyth1
M0GzXvG7whpqsCnPXnX8PK9E9Wi7dsTOVx/32wGn95xPc76V0kaFYdDz/ShWDF9O

Bug#1050375: Invalid command name "pg_connect"

[Christoph Berg]

Package: pfm
Version: 2.0.8-3
Severity: grave

pfm doesn't do anything useful here, it just produces a message popup
saying

Connection to database foo has failed:

invalid command name "pg_connect"

I guess Tcl/Tk has changed since this package was last updated 10 years ago.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de:en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pfm depends on:
ii  itcl3  3.4.4-2
ii  libpgtcl   1:3.0.0-1
ii  postgresql-client  15+253.pgdg+1
ii  postgresql-client-10 [postgresql-  10.23-2.pgdg+1
client]
ii  postgresql-client-11 [postgresql-  11.21-1.pgdg+1
client]
ii  postgresql-client-12 [postgresql-  12.16-1.pgdg+1
client]
ii  postgresql-client-13 [postgresql-  13.12-1.pgdg+1
client]
ii  postgresql-client-14 [postgresql-  14.9-1.pgdg+1
client]
ii  postgresql-client-15 [postgresql-  15.4-1.pgdg+1
client]
ii  postgresql-client-16 [postgresql-  16~beta2-2.pgdg+~20230807.1056.ge8386b2
client]
ii  postgresql-client-17 [postgresql-  17~~devel-1.pgdg+~20230820.0934.g1951d21
client]
ii  postgresql-client-8.2 [postgresql  8.2.23-11.pgdg+1
-client]
ii  postgresql-client-8.4 [postgresql  8.4.22-9.pgdg+1
-client]
ii  postgresql-client-9.3 [postgresql  9.3.25-9.pgdg+1
-client]
ii  postgresql-client-9.4 [postgresql  9.4.26-8.pgdg+1
-client]
ii  postgresql-client-9.5 [postgresql  9.5.25-6.pgdg+1
-client]
ii  postgresql-client-9.6 [postgresql  9.6.24-5.pgdg+1
-client]
ii  sensible-utils 0.0.20
ii  tcl8.6.13
ii  tk 8.6.13

pfm recommends no packages.

Versions of packages pfm suggests:
ii  postgresql  15+253.pgdg+1

-- no debconf information

Christoph

Bug#939170: linux: does not suspend completely, locks up

[Nolan]

On Wed, 23 Aug 2023 09:31:50 -0700 Nolan  wrote:> 
Looks like between bullseye and bookworm TPM support switched from
modular to built in, so the old workaround will not work without a 
kernel rebuild.


bullseye:~# grep TPM /boot/config-5.10.0-25-amd64
CONFIG_TCG_TPM=m
CONFIG_HW_RANDOM_TPM=y
CONFIG_TCG_VTPM_PROXY=m

bookworm:~# grep TPM /boot/config-6.1.0-11-amd64
CONFIG_TCG_TPM=y
CONFIG_TCG_VTPM_PROXY=m


I tried another workaround that appears to work.

Disable the TPM in the BIOS. It is in the BIOS setup under the 
"Security" tab: "Security Chip". I set that to disabled and "systemctl 
suspend" now looks like it works, all the keyboard lights go out. 
Pressing power resumes normally.

Bug#939170: linux: does not suspend completely, locks up

[Diederik de Haas]

On Wednesday, 23 August 2023 19:32:19 CEST Diederik de Haas wrote:
> diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ grep -r CONFIG_TCG_TPM
> debian/config/ debian/config/arm64/config:CONFIG_TCG_TPM=m
> debian/config/kernelarch-x86/config:CONFIG_TCG_TPM=m
> debian/config/config.cloud:CONFIG_TCG_TPM=m
> 
> The Debian kernel configuration didn't change, so I guess it's one of its
> dependencies which turned the `=m` into `=y`?

This seems the same or similar to https://bugs.debian.org/1041007


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

Bug#967666: ocamlviz: depends on deprecated GTK 2

[Bastian Germann]

Please consider dropping ocamlviz-gui and the liblablgtk2-ocaml-dev 
build dependency.

Bug#1050374: RM: ocamlodbc -- RoQA; depends on gtk2; leaf package; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:ocamlodbc

Please remove ocamlodbc. It has a low popcon, depends transitively on 
gtk2, and is a leaf library package. There are no human uploaders listed 
anymore in this team-maintained package.

Bug#1050001: Unwinding directory aliasing

[Ian Jackson]

Also, one other thing I noticed:

tl;dr: *no* version of usrmerge relieves us of the obligation of
naming files correctly, via the proper name in /usr rather than /.

Ian Jackson writes ("Bug#1050001: Unwinding directory aliasing"):
> The current plan, as I understand it, is that we will fix these
> problems by arranging to *always* name files by their canonical paths,
> ie the ones in /usr.
> 
> Naming files by their canonical names will have to be done everywhere.
> This is because any time a file is named by a non-canonical path, a
> program that tries to manipulate that file might malfunction.
> (Whether it malfunctions in practice depends on the precise details
> and gets very complicated.)
...

But Simon writes:
> > This does some but not all of what merged-/usr does: calling /usr/bin/sh
> > would become a non-bug, but calling /bin/env would still be an error,
> > /bin would still represent non-trivial on-disk and/or in-dpkg-database
> > state,

This suggests that a goal of the project is to "make it not be a bug
to refer to a file in /usr/bin by its name in /bin".

However, in the aliased-usrmerge such an incorrect reference *remains*
a bug (unless it can be demonstrated that the reference is only
read-only and no-one will take that path and use it in a non-read-only
context).

It's just that the consequences of the bug are different.


Without usrmerge, or with un-aliased-usrmerge for a file where there
is no compat symlink, the reseult is a "file not found" error.  No
references via that path can work.  (Except maybe transitionally,
while the file is moving.)  Such a bug is not likely to survive long.

With un-aliased usrmerge for files which still have compat symlinks
(eventually, a handful of files considered quite special), using the
reference for mutation might result in breaking the symbolic link; or
it might result in errors from filename lookups in package management
databasesa, where the filename would be not recorded in / or not
recorded as a file.  Broken symlinks could be detected post-hoc on the
affected system, and it could be detected simply and automatically by
QA tooling.  But, this is a good reason to try to reduce the number of
compat symlinks to a very small number.

With aliased usrmerge, for all files forever, using the path in /
might result in confusing behaviour by package management and system
administration tooling.  Reasoning about the consequences is
difficult, but in the worst case it might render the affected
subsystem totally broken.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1050373: RM: lablgtk-extras -- RoQA; depends on gtk2; leaf package; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:lablgtk-extras

Please remove lablgtk-extras. It has a very low popcon, depends 
transitively on gtk2, and is a leaf library package.

Bug#1050365: transition: yaml-cpp

[Graham Inggs]

Control: tags -1 confirmed

Hi Gianfranco

On Wed, 23 Aug 2023 at 17:09, Gianfranco Costamagna
 wrote:
> Only openimageio and qtcreator have issues finding the new libyaml-cpp 
> release, and this can be easily solved
> by dropping the Findyaml-cpp.cmake
>
> excluding unrelated failures and packages out of testing, it's a 18 packages 
> transition.

Please go ahead.

Regards
Graham

Bug#1043591: transition: libnfs

[Graham Inggs]

Control: tags -1 confirmed

Hi Balint

On Sun, 13 Aug 2023 at 11:33, Bálint Réczey  wrote:
> I would like to update libnfs in unstable to the 5.0.2 version.
>
> It is built for all release architectures in experimental.
> The transition would involve libnfs and its reverse
> dependencies:
>  far2l gvfs mpd kodi mpd qemu vlc
>
> All of them build with the new libnfs version:
> https://people.debian.org/~rbalint/transitions/libnfs-5/

Please go ahead.

Regards
Graham

Bug#1050372: RM: prooftree -- RoQA; depends on gtk2; no human uploader; unmaintained upstream; low popcon

[Bastian Germann]

Source: prooftree
Severity: serious

Please consider removing prooftree. It has a very low popcon, lists no 
Uploaders (team maintained), and depends transitively on gtk2. The last 
upstream release was in 2017.


I intend to file a RM bug.
If you have any reasons to keep it in Debian please voice them here.
To get people's attention, I am filing as a serious bug and will 
reassign to the FTP team when the package is autoremoved from testing.

Bug#1050352: backside USB-ports stop working after some time

[Diederik de Haas]

Control: reassign -1 src:linux/6.1.38-4

On Wednesday, 23 August 2023 18:39:50 CEST Rolf Reintjes wrote:
> Here are more of the near dmesg meassages:
> 
> 
> [   28.747758] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
> [  344.813681] DMAR: DRHD: handling fault status reg 2
> [  344.813692] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault
> addr 0xfffad000 [fault reason 0x06] PTE Read access is not set
> [  344.813917] DMAR: DRHD: handling fault status reg 102
> [  344.813923] xhci_hcd :05:00.0: WARNING: Host System Error
> [  344.813923] DMAR: [DMA Read NO_PASID] Request device [05:00.0] fault
> addr 0xfffad000 [fault reason 0x06] PTE Read access is not set

A page fault doesn't sound good and I wouldn't be surprised if that wes the 
reason for the issues.
On https://snapshot.debian.org/binary/linux-image-amd64/ you'll find a whole 
bunch of kernel version and it would be really helpful if you can determine 
what the last version of the 6.1 series was where the USB ports work as 
expected and then the first version where it stopped working.

You could start with (one of) the earliest 6.1 kernels to verify whether it 
has worked properly in a 6.1 kernel at all.

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

Bug#1050371: djbdns: Fix for tests with new glibc 2.38

[Danilo Egea Gondolfo]

Source: djbdns
Version: 1:1.05-15ubuntu1
Severity: normal

Dear Maintainer,

djbdns is failing autopkgtests with the glibc 2.38.

This is the error: "/usr/sbin/tinydns: error while loading shared 
libraries: libc.so.6: cannot map zero-fill pages\n"


Please, find a proposed fix in my Salsa clone repository 
https://salsa.debian.org/danilogondolfo/djbdns/-/tree/glibc_2_38_fixes


I'd submit a merge request but this repository appears to not accept it.

I'm also including a fix for auto autopkgtest timeouts we are observing 
on Ubuntu on arm64 and armhf. It would be great to have them included.


Thank you!


-- System Information:
Debian Release: trixie/sid
APT prefers mantic
APT policy: (500, 'mantic'), (100, 'mantic-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-7-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1050370: hamexam: question pools need updating

[Austen, Jeffrey]

Package: hamexam
Version: 1.7.0-3

The question pools need updating. There appears to be a newer version, 
with some but not all updates, at 
https://launchpad.net/~jnogatch/+archive/ubuntu/hamexam .

Bug#1040445: udev creates wrong symlink from rule after upgrade to bookworm

[Karl Schmidt]

I'm not up on the steps to do to get the debug (if you can list the command(s) 
to run?).

BUT -

After the last reboot which has 252.12-1~deb12u1  I saw

lrwxrwxrwx 1 root root   9 2023-08-17 16:29 ttyUSB-nut -> gpiochip0

Which is wrong - So I unplugged and replugged the cable and looked again and 
see:

lrwxrwxrwx 1 root root 15 2023-08-23 11:57 ttyUSB-nut -> bus/usb/001/003

Which is also wrong...

Nothing unusual in syslog:

2023-08-23T11:57:33.070249-05:00 localhost kernel: [502060.481676] ftdi_sio ttyUSB0: FTDI USB Serial Device converter 
now disconnected from ttyUSB0

2023-08-23T11:57:33.070259-05:00 localhost kernel: [502060.481724] ftdi_sio 
1-8:1.0: device disconnected
2023-08-23T11:57:35.772093-05:00 localhost kernel: [502063.187387] usb 1-8: new full-speed USB device number 3 using 
xhci_hcd
2023-08-23T11:57:35.924035-05:00 localhost kernel: [502063.341331] usb 1-8: New USB device found, idVendor=0403, 
idProduct=6001, bcdDevice= 6.00
2023-08-23T11:57:35.924054-05:00 localhost kernel: [502063.341345] usb 1-8: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

2023-08-23T11:57:35.924056-05:00 localhost kernel: [502063.341352] usb 1-8: 
Product: FT232R USB UART
2023-08-23T11:57:35.924058-05:00 localhost kernel: [502063.341358] usb 1-8: 
Manufacturer: FTDI
2023-08-23T11:57:35.924060-05:00 localhost kernel: [502063.341363] usb 1-8: 
SerialNumber: AJV9MKOY
2023-08-23T11:57:35.928058-05:00 localhost kernel: [502063.345376] ftdi_sio 1-8:1.0: FTDI USB Serial Device converter 
detected

2023-08-23T11:57:35.928077-05:00 localhost kernel: [502063.345482] usb 1-8: 
Detected FT232R
2023-08-23T11:57:35.928080-05:00 localhost kernel: [502063.346643] usb 1-8: FTDI USB Serial Device converter now 
attached to ttyUSB0



--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street  Ph (785) 841-3089
Lawrence, KS 66049

Being wrong, is the natural state of experts.
-Malcolm Kendrick

Bug#939170: linux: does not suspend completely, locks up

[Diederik de Haas]

On Wednesday, 23 August 2023 18:31:50 CEST Nolan wrote:
> Looks like between bullseye and bookworm TPM support switched from
> modular to built in, so the old workaround will not work without a
> kernel rebuild.
> 
> bullseye:~# grep TPM /boot/config-5.10.0-25-amd64
> CONFIG_TCG_TPM=m
> CONFIG_HW_RANDOM_TPM=y
> CONFIG_TCG_VTPM_PROXY=m
> 
> bookworm:~# grep TPM /boot/config-6.1.0-11-amd64
> CONFIG_TCG_TPM=y
> CONFIG_TCG_VTPM_PROXY=m

diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ grep -r CONFIG_TCG_TPM 
debian/config/
debian/config/arm64/config:CONFIG_TCG_TPM=m
debian/config/kernelarch-x86/config:CONFIG_TCG_TPM=m
debian/config/config.cloud:CONFIG_TCG_TPM=m

The Debian kernel configuration didn't change, so I guess it's one of its
dependencies which turned the `=m` into `=y`?

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

Bug#1050369: RM: freetennis -- RoQA; dead upstream; depends on gtk2

[Bastian Germann]

Source: freetennis
Severity: serious

freetennis does not seem to be used a lot and is unmaintained upstream.
With tennix, there is a similar alternative available.

I intend to file a RM bug.
If you have any reasons to keep it in Debian please voice them here.
To get people's attention, I am filing as a serious bug and will 
reassign to the FTP team when the package is autoremoved from testing.

Bug#900598: [desmume] Include non free file

[Bastian Germann]

This is fixed at least in the new upstream version 0.9.13 which does not 
contain the file anymore and was released over a year ago.

Bug#1042026: dlt-daemon: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j8 test ARGS\+=--verbose ARGS\+=-j8 returned exit code 2

[Gianfranco Costamagna]

control: close -1

Hello, this is a test environment issue.
dlt-logging has a multiple_log_file on /tmp check that deletes the latest .log 
file,
and then tries to delete the build log

Remove file /tmp/dlt-daemon_2.18.9-2_unstable.log failed! error=Operation not 
permitted
debug test: /tmp/dlt.log
configure dlt logging using file limits


And fails.

G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1043144: transition: mutter/gnome-shell 44

[Graham Inggs]

On Wed, 23 Aug 2023 at 12:04, Simon McVittie  wrote:
> Please consider adding hints as follows:
>
> remove gnome-shell-extension-arc-menu/49+forkv29-3
> remove gnome-shell-extension-dashtodock/75-1
> remove gnome-shell-extension-easyscreencast/1.7.0-2
> remove gnome-shell-extension-flypie/21-1
> remove gnome-shell-extension-freon/52+dfsg-1
> remove gnome-shell-extension-gamemode/8-2
> remove gnome-shell-extension-hamster/0.10.0+git20210628-4
> remove gnome-shell-extension-impatience/0.4.8-2
> remove gnome-shell-extension-panel-osd/1.0.50.gc032923-3
> remove gnome-shell-extension-system-monitor/40-5
> remove gnome-shell-extension-vertical-overview/10-1
> remove gnome-shell-extension-weather/119-1

Hints added, thanks.

> If I understand britney syntax correctly, if extension maintainers do
> a new sourceful upload fixing the "needs update for GNOME Shell 44" RC
> bugs, those removal hints would not match the updated package because
> its version would be higher, so the newer version would still be allowed
> to migrate and stay in testing.

Yes, the removal hints only apply to the specified version.

Bug#1050368: please provide full set of uAPI headers

[Dmitry Baryshkov]

Package: linux-libc-dev
Version: 6.4.4-3
Severity: normal

The linux-libc-dev package provides only a limited set of uAPI headers.
For example, scsi, drm, video, etc. headers are missing from the
package. These headers are not a part of any standard, but are still
useful for the userspace programs, they provide information about the
kernel-userspace interfaces. Without these headers in the linux-libc-dev
package (or any other package) we have either to install them manually
or (for Debian packages needing them) bundle respective headers.

-- 
With best wishes
Dmitry


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

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1050367: qtcreator: FTBFS with newer yaml-cpp [PATCH]

[Gianfranco Costamagna]

Source: qtcreator
Version: 10.0.2-1ubuntu1
Severity: important
tags: patch

Hello, looks like the new yaml-cpp version is making the embedded cmake fail to 
detect it.
An easy workaround/patch is the following:

diff -Nru qtcreator-10.0.2/debian/rules qtcreator-10.0.2/debian/rules
--- qtcreator-10.0.2/debian/rules   2022-11-29 08:15:58.0 +
+++ qtcreator-10.0.2/debian/rules   2023-08-23 08:59:59.0 +
@@ -32,6 +32,10 @@
 %:
dh $@ --builddirectory=builddir
 
+override_dh_auto_clean:

+   dh_auto_clean
+   rm -rf cmake/Findyaml-cpp.cmake
+
 override_dh_auto_configure:
dh_auto_configure --buildsystem=cmake -- \
-DBUILD_DEVELOPER_DOCS=ON \

thanks for considering it, this bug will become serious once yaml-cpp 
transition is ack'd by Release Team
G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050366: opencolorio: FTBFS with newer yaml-cpp [PATCH]

[Gianfranco Costamagna]

Source: opencolorio
Version: 2.1.2+dfsg1-4
Severity: important
tags: patch

Hello, looks like the new yaml-cpp version is making the embedded cmake fail to 
detect it.
An easy workaround/patch is the following:

diff -Nru opencolorio-2.1.2+dfsg1/debian/rules 
opencolorio-2.1.2+dfsg1/debian/rules
--- opencolorio-2.1.2+dfsg1/debian/rules2022-12-04 20:34:15.0 
+
+++ opencolorio-2.1.2+dfsg1/debian/rules2023-08-22 16:40:28.0 
+
@@ -12,6 +12,10 @@
 %:
dh $@ -Scmake -B$(BLDDIR) --with python3
 
+override_dh_auto_clean:

+   dh_auto_clean
+   rm -f share/cmake/modules/Findyaml-cpp.cmake
+
 override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_BUILD_TYPE=Release \

thanks for considering it, this bug will become serious once yaml-cpp 
transition is ack'd by Release Team
G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050365: transition: yaml-cpp

[Gianfranco Costamagna]

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


All the packages are building properly, I checked in an Ubuntu ppa (and most of 
them are in sync w Debian).

Only openimageio and qtcreator have issues finding the new libyaml-cpp release, 
and this can be easily solved
by dropping the Findyaml-cpp.cmake

excluding unrelated failures and packages out of testing, it's a 18 packages 
transition.

Ben file:

title = "yaml-cpp";
is_affected = .depends ~ "libyaml-cpp0.7" | .depends ~ "libyaml-cpp0.8";
is_good = .depends ~ "libyaml-cpp0.8";
is_bad = .depends ~ "libyaml-cpp0.7";


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050364: RM: m17n-im-config -- RoQA; depends on gtk2; orphaned; dead upstream; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:m17n-im-config

Please remove m17n-im-config. It has a very low popcon, which suggests 
that is is not used anymore to configure m17n-lib. It is orphaned, dead 
upstream, and depends on gtk2.

Bug#1050362: python3-poetry should depend on python3-poetry-core 1.6.1

[Daniele Ricci]

Package: python3-poetry
Version: 1.5.1+dfsg-3
Severity: important

Dear Maintainer,

When using poetry in Debian testing, some commands fail. For example:

$ poetry env list -vvv
  TypeError

  unsupported operand type(s) for /: 'str' and 'str'

  at /usr/lib/python3/dist-packages/poetry/json/__init__.py:41 in
validate_object
   37│
   38│ errors.append(message)
   39│
   40│ core_schema = json.loads(
→  41│ (CORE_SCHEMA_DIR / "poetry-
schema.json").read_text(encoding="utf-8")
   42│ )
   43│
   44│ properties = {*schema["properties"].keys(),
*core_schema["properties"].keys()}
   45│ additional_properties = set(obj.keys()) - properties

This happens because this poetry version is incompatible with the poetry-core
version available in testing. In fact, poetry version 1.5.1 depends on poetry-
core 1.6.1 in upstream: https://github.com/python-
poetry/poetry/blob/1.5.1/pyproject.toml#L35

Since upstream sets this as a fixed dependency (no caret or tilde), the two
packages (poetry and poetry-core) should maybe be upgraded together to always
be compatible.

Installing poetry-core from unstable works around the issue. Additional
information in this bug report states version 1.6.1-2 but this is because I've
already installed that from unstable. The version in testing (and probably
stable too) is 1.4.0-4.


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

Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 python3-poetry depends on:
ii  python3 3.11.4-5+b1
ii  python3-build   0.10.0-1
ii  python3-cachecontrol0.13.1-1
ii  python3-cleo2.0.1-5
ii  python3-crashtest   0.4.1-1
ii  python3-dulwich 0.21.5-1
ii  python3-filelock3.12.2-1
ii  python3-html5lib1.1-3
ii  python3-importlib-metadata  4.12.0-1
ii  python3-installer   0.7.0+dfsg1-2
ii  python3-jsonschema  4.10.3-2
ii  python3-keyring 24.2.0-1
ii  python3-lockfile1:0.12.2-3
ii  python3-packaging   23.1-1
ii  python3-pexpect 4.8.0-4
ii  python3-pkginfo 1.8.2-2
ii  python3-platformdirs3.10.0-1
ii  python3-poetry-core 1.6.1-2
ii  python3-pyproject-hooks 1.0.0-2
ii  python3-requests2.31.0+dfsg-1
ii  python3-requests-toolbelt   1.0.0-1
ii  python3-shellingham 1.5.1-1
ii  python3-tomlkit 0.12.1-1
ii  python3-trove-classifiers   2023.7.6-1
ii  python3-urllib3 1.26.16-1
ii  python3-virtualenv  20.24.1+ds-1

python3-poetry recommends no packages.

python3-poetry suggests no packages.

-- no debconf information

Bug#1050363: flit ftbfs in unstable

[Matthias Klose]

Package: src:flit
Version: 3.9.0-1
Severity: serious
Tags: sid trixie

flit ftbfs in unstable,

[...]
__ test_sdist __

rel_path = 'README.rst', proj_dir = PosixPath('.'), guess_mimetype = True

def description_from_file(rel_path: str, proj_dir: Path, 
guess_mimetype=True):
if osp.isabs(rel_path):
raise ConfigError("Readme path must be relative")

desc_path = proj_dir / rel_path
try:
>   with desc_path.open('r', encoding='utf-8') as f:

flit_core/config.py:281:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = PosixPath('README.rst'), mode = 'r', buffering = -1, encoding = 'utf-8'
errors = None, newline = None

def open(self, mode='r', buffering=-1, encoding=None,
 errors=None, newline=None):
"""
Open the file pointed by this path and return a file object, as
the built-in open() function does.
"""
if "b" not in mode:
encoding = io.text_encoding(encoding)
>   return io.open(self, mode, buffering, encoding, errors, newline)
E   FileNotFoundError: [Errno 2] No such file or directory: 'README.rst'

/usr/lib/python3.11/pathlib.py:1045: FileNotFoundError

During handling of the above exception, another exception occurred:

tmp_path = '/tmp/pytest-of-buildd/pytest-0/test_sdist0', cwd_project = None

def test_sdist(tmp_path, cwd_project):
tmp_path = str(tmp_path)
>   filename = buildapi.build_sdist(tmp_path)

flit_core/tests/test_build_thyself.py:51:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
flit_core/buildapi.py:82: in build_sdist
path = SdistBuilder.from_ini_path(pyproj_toml).build(Path(sdist_directory))
flit_core/sdist.py:90: in from_ini_path
ini_info = read_flit_config(ini_path)
flit_core/config.py:79: in read_flit_config
return prep_toml_config(d, path)
flit_core/config.py:106: in prep_toml_config
loaded_cfg = read_pep621_metadata(d['project'], path)
flit_core/config.py:454: in read_pep621_metadata
desc_content, mimetype = description_from_file(readme, path.parent)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

rel_path = 'README.rst', proj_dir = PosixPath('.'), guess_mimetype = True

def description_from_file(rel_path: str, proj_dir: Path, 
guess_mimetype=True):
if osp.isabs(rel_path):
raise ConfigError("Readme path must be relative")

desc_path = proj_dir / rel_path
try:
with desc_path.open('r', encoding='utf-8') as f:
raw_desc = f.read()
except IOError as e:
if e.errno == errno.ENOENT:
>   raise ConfigError(
"Description file {} does not exist".format(desc_path)
)
E   flit_core.config.ConfigError: Description file README.rst does 
not exist


flit_core/config.py:285: ConfigError
=== short test summary info 
FAILED flit_core/tests/test_build_thyself.py::test_prepare_metadata - flit_co...
FAILED flit_core/tests/test_build_thyself.py::test_wheel - flit_core.config.C...
FAILED flit_core/tests/test_build_thyself.py::test_sdist - flit_core.config.C...
= 3 failed, 87 passed in 0.38s =

Bug#1050340: [Pkg-puppet-devel] Bug#1050340: puppetserver: incompatibility with system hiera-eyaml

[Cyril Brulebois]

Antoine Beaupré  (2023-08-23):
> Oh i meant the upstream version, the package in Debian is obviously out
> of date here. :)

Sure, I meant I would have tried (package relationship permitting) a
newer package if there was one available.

> Same here, I was just curious if you thought the manual gem update fixed
> this because it's a new upstream or just because "some gem thing".

“Yes.” ;p


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


signature.asc
Description: PGP signature

Bug#1050361: RM: mangler -- RoQA; dead upstream; depends on gtk2

[Bastian Germann]

Source: mangler
Severity: serious
Version: 1.2.5-5

mangler does not seem to be used a lot and is dead upstream. I doubt 
that Ventrilo is still a thing nowadays.


I intend to file a RM bug.
If you have any reasons to keep it in Debian please voice them here.
To get people's attention, I am filing as a serious bug and will 
reassign to the FTP team when the package is autoremoved from testing.