Bug#1069590: ITP: python-ast-decompiler -- Python module to decompile AST to Python code

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-ast-decompiler
  Version : 0.7.0 
  Upstream Contact: Jelle Zijlstra 
* URL : https://github.com/JelleZijlstra/ast_decompiler
* License : Apache-2.0
  Programming Lang: Python
  Description : Python module to decompile AST to Python code

ast_decompiler is a module for generating Python code
 given an AST. Planned to maintain it under DPT, need
 sponsorship.

Bug#812326: SystemV / LSB init header: cups-browsed depends on avahi and cups

[Thorsten Alteholz]

Package: cups-browsed

Hi Mike,

unfortunately this is a feature and not a bug.

As cups-browsed only Recommends: avahi-daemon, it might not be installed 
and you can not require to wait for its start. As far as I know systemd 
has some kind of timeout and the system will still boot when avahi-daemon 
is not installed.


So, if you don't mind I will close this bug again.

  Thorsten

Bug#1068129: ITP: redict - Licensing questions

[Andrea Pappacoda]

(Ccing Drew since he's way more knowledgeable of me - great new post
btw!)

Hi Maytham, thanks for accepting my request to join the Redict team!

I've started taking a look at the work you've done, and I have a few
questions regarding the debian/copyright file you wrote. I've noticed
that you've marked all the files as LGPL-3.0-only, but I'm not sure
that's correct.

Most Redict files come from Redis 7.2.4, where they were licensed under
the BSD-3-Clause license. While Redict is distributed under the
LGPL-3.0-only, the files themselves still carry the original copyright
properties, thus the d/copyright file should list them as licensed under
the BSD-3-Clause, or under both the old and new license. Or at least,
that's my understanding of how these things work.

For example, I think that the following file block:

Files: *
Copyright:
 2006-2014 Salvatore Sanfilippo 
 2024 Redict contributors
License: LGPL-3.0-only

should instead look something like:

Files: *
Copyright:
 2006-2014 Salvatore Sanfilippo 
 2024 Redict contributors
License: LGPL-3.0-only and BSD-3-Clause

This is also one of the few cases where I think that using the top-level
optional License field is appropriate. I'd use it to indicate that,
while the individual files have historically been licensed under the
BSD-3-Clause, Redict itself is distributed under the LGPL-3.0-only:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Contact: Drew DeVault 
Upstream-Name: redict
Source: https://redict.io
License: LGPL-3.0-only

(Also, the Source field should say "https://codeberg.org/redict/redict;,
but that's a pretty minor issue).

Let me know what you think! Bye :)

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Holger Levsen]

On Sat, Apr 20, 2024 at 08:30:52PM +0200, Guillem Jover wrote:
> While I fully support properly marking obsolete packages by putting
> them in the (unfortunately misnamed :) oldlibs section (well excluding
> library-like depended on packages that get dropped as a mater of course).
> I wanted to note that I've received some pushback from the archive
> maintainers about this being considered unnecessary churn (paraphrasing
> from what ISTR). So it would be nice to clarify this with them before
> creating and proposing a procedure that might end up generating social
> friction.
 
I tend to agree. Already now maintainers forget to drop transitional
packages after having them been part of *two* releases (I have filed >400 bugs
requesting removal of such old transitional packages in the last 10y, so 
roughly 80 per release), so I don't think requiring them to do *more*
will work out nicely.

(also this adds workload to ftpmasters too.)


-- 
cheers,
Holger

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

"In just 6 decades, roughly the life span of a blue whale, humans took blue 
whale
population down from 360,000 to just 1,000. In one century, whalers killed two
million baleen whales, which together weighed twice as much as all wild mammals
on Earth today."
https://www.theatlantic.com/science/archive/2021/11/whaling-whales-food-krill-iron/620604/


signature.asc
Description: PGP signature

Bug#1069593: libsequoia-octopus-librnp: dpkg-divert in preinst doesn't happen on upgrade

[Daniel Kahn Gillmor]

Package: libsequoia-octopus-librnp
Version: 1.8.1-2
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 
Control: affects -1 thunderbird gpg-from-sq gpgv-from-sq

When i try to install thunderbird 1:115.10.1-1, i get this error:

```
Unpacking thunderbird (1:115.10.1-1) over (1:115.9.0-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/thunderbird_1%3a115.10.1-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/thunderbird/librnp.so', which is also in package 
libsequoia-octopus-librnp 1.8.1-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/thunderbird_1%3a115.10.1-1_amd64.deb
```

This looks to me like the octopus's dpkg-diversion is supposed to work
to avoid this, but i don't see it happening.

This seems to be due to the way the preinst script adds the diversion:

```
if [ "$1" != "upgrade" ] ; then
  add_diversion /usr/lib/thunderbird/librnp.so
fi
```

i had version 1.8.1-1 installed before 1.8.1-2, which meant that i
upgraded, and i didn't get the diversion added:

grep octopus /var/log/dpkg.log.1 shows:

2024-03-26 06:38:49 status installed libsequoia-octopus-librnp:amd64 1.8.1-1
2024-03-28 10:27:08 upgrade libsequoia-octopus-librnp:amd64 1.8.1-1 1.8.1-2

Why does the package exclude the diversion when preinst runs on upgrade?

i see the same issue in the use of dpkg-divert in gpg-from-sq and
gpgv-from-sq also, btw.  Compare that to the use of dpkg-divert in
/var/lib/dpkg/info/perl-doc.preinst, for example, which triggers on both
"install" and on "upgrade".

I worked around this on my system by removing libsequoia-octopus-librnp,
upgrading thunderbird, and then reinstalling libsequoia-octopus-librnp,
but it seems like the goal should be to not have to make the user do
that.

--dkg



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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)



signature.asc
Description: PGP signature

Bug#1069594: libsequoia-octopus-librnp: library diversion says "$1-thunderbid", but it probably means "$1-thunderbird"

[Daniel Kahn Gillmor]

Package: libsequoia-octopus-librnp
Version: 1.8.1-2
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

/var/lib/dpkg/info/libsequoia-octopus-librnp.preinst contains:


#!/bin/sh
set -e

add_diversion() {
  dpkg-divert --package libsequoia-octopus-librnp --add --rename \
--divert "$1-thunderbid" "$1"
}

# Add diversions for any non-upgrade operation
if [ "$1" != "upgrade" ] ; then
  add_diversion /usr/lib/thunderbird/librnp.so
fi



exit 0



I think "$1-thunderbid" is meant to be "$1-thunderbird" (there is a
missing "r")

  --dkg


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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)

Versions of packages libsequoia-octopus-librnp depends on:
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libhogweed6t64  3.9.1-2.2
ii  libnettle8t64   3.9.1-2.2
ii  libsqlite3-03.45.1-1
ii  libssl3t64  3.2.1-3

Versions of packages libsequoia-octopus-librnp recommends:
ii  zenity  4.0.1-1

Versions of packages libsequoia-octopus-librnp suggests:
ii  thunderbird  1:115.9.0-1+b1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1069595: mplayer: FTBFS with ffmpeg 7

[Lorenzo Puliti]

Source: mplayer
Version: 2:1.5+svn38446-2
Severity: important
Tags: upstream ftbfs
X-Debbugs-Cc: plore...@disroot.org

Mplayer fails to build from source with ffmpeg7 (currently in experimental);
there are patches upstream but it looks that there are still open issues, at
least with jack.

https://trac.mplayerhq.hu/ticket/2419

https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2024-April/074132.html


filing with severity important for now, until ffmpeg 7 is uploaded to unstable.


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

Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Bug#1069453: reopening 1069453

[Sebastian Ramacher]

reopen 1069453 
thanks

The fix is incorrect since buildds only take the first alternative into
account.

Cheers
-- 
Sebastian Ramacher

Bug#1069492: Seems to be an OpenMPI problem

[Markus Blatt]

Hi,

the problem occurs during startup of OpenMPI when running mpirun. I see similar 
problems for other packages during the same rebuild.

Hence I don't think this is related to us but rather to OpenMPI.

Best,

Markus

Bug#1059605: dh-runit: Consider migrating from a haskell-based testrunner

[Lorenzo]

Control: tags -1 help

Hi,
[sorry for the very late reply]

On Thu, 28 Dec 2023 22:03:21 -0600 "David (Plasma) Paul"
 wrote:

> Please consider modifying the testsuite infrastructure for dh-runit to
> not require haskell.
> 
> Given that both dh-runit and its tests are written in perl, it's a bit
> inconvenient to need a haskell compiler just to build the testrunner
> program.

I mostly agree, however the haskell testsuit runs very fast and I
believe it's also run in some kind of isolated environment
(I inherited the testsuite from previous maintainer, so I'm not 100%
sure about the isolation).

I'm fine with converting the testsuite in perl and/or shell but this is
time consuming for very little gain, so it's low priority for me
compared to other issues, not sure if/when it will happen.

If for someone this is urgent, I'm certainly going to review patches
for a testsuite in perl/shell; just make sure the test results are not
dependant on the system where the testsuite is run - it has to work in
your development system but also in a container like salsa autopkgtest
with consistent results.

Tagging help in case someone wants to provide patches.

Best,
Lorenzo
> 
> Thanks,
> 
> -- 
> Plasma
> 
> 

Bug#1069586: Chromium native Wayland support broken

[Leandro Cunha]

On Sun, Apr 21, 2024 at 1:27 AM Andres Salomon  wrote:
>
> Control: tags -1 forwarded https://crbug.com/329678163
> Control: severity -1 serious
>
> On 4/20/24 23:13, Stephan Verbücheln wrote:
> > Package: chromium
> > Version: 124.0.6367.60-1~deb12u1
> >
> > Since the last update, Chromium does work with native Wayland. It is
> > starting up, but it is displaying an invisible window. It is listed in
> > the window switchers (Alt+Tab), Gnome Shell etc., but invisible.
> >
> > Note: The default configuration uses X11 via XWayland and is working.
> >
> > The setting can be managed via command line arguments or by typing
> > chrome://flags into the URL bar (filter for ozone).
> >
> > Available settings:
> > default -> X11works
> > auto-> Wayland if available   does not work
> > x11   works
> > wayland   does not work
> >
> > I have been using Chromium with native Wayland for many months without
> > problems until the last update.
> >
>
> Thanks for the heads up. Seems like this is v124-specific, and reported
> upstream at .
>
> If they don't fix it in the stable channel, I'll backport a fix. In the
> meantime it does seem like you can get it work in wayland mode using
> command-line args, according to that bug report thread, though I haven't
> tested it myself (I'm on X11 here).
>

Very interesting, using GNOME under Wayland with Intel hardware with
no apparent problems.
Remembering that I use unstable.

-- 
Cheers,
Leandro Cunha

Bug#1068738: Patch

[Bruno Kleinert]

Hi,

here's a patch that adds the newly required dependency on python3-lxml-
html-clean.

Kind regards,
Bruno
diff --git a/debian/control b/debian/control
index 11e717a..4c24515 100644
--- a/debian/control
+++ b/debian/control
@@ -26,6 +26,7 @@ Build-Depends-Indep: appstream-util ,
  python3-html5lib,
  python3-listparser,
  python3-lxml,
+		 python3-lxml-html-clean,
  python3-pil,
  python3-pygments,
  python3-readability,
@@ -50,6 +51,7 @@ Depends: gir1.2-adw-1,
  python3-humanize,
  python3-listparser,
  python3-lxml,
+ python3-lxml-html-clean,
  python3-magic,
  python3-pil,
  python3-pygments,
diff --git a/debian/control.in b/debian/control.in
index 34fc4bd..5658308 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -22,6 +22,7 @@ Build-Depends-Indep: appstream-util ,
  python3-html5lib,
  python3-listparser,
  python3-lxml,
+		 python3-lxml-html-clean,
  python3-pil,
  python3-pygments,
  python3-readability,
@@ -46,6 +47,7 @@ Depends: gir1.2-adw-1,
  python3-humanize,
  python3-listparser,
  python3-lxml,
+ python3-lxml-html-clean,
  python3-magic,
  python3-pil,
  python3-pygments,


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

Bug#1061421: Fails to start after an upgrade

[Arto Jantunen]

Jeremy Bícha  writes:
> Please verify whether wlgreet is working for you now.

Was something changed somewhere? What, where?

On trixie the issue reproduces exactly the same (even with sway upgraded
to the binNMU'd version from sid).

-- 
Arto Jantunen

Bug#979617: tcplay: VeraCrypt support

[Daniel Kahn Gillmor]

Control: retitle 979617 tcplay: new upstream version 3.3 (includes VeraCrypt 
support)

I've just confirmed what Johannes said about tcplay 3.3 building easily
on debian.  I uploaded 3.3-0.1 to unstable as an NMU to DELAYED/15,
after cleaning up the packaging a little bit.

I've imported all the history of the tcplay package from
snapshots.debian.org into a git repo (using "gbp import-dscs --debsnap
tcplay"), and then made my packaging changes on top of that synthetic
history.

I published that git repository (history + my changes) at
https://salsa.debian.org/debian/tcplay on the debian/unstable branch.

Hopefully this NMU is welcomed in the helpful spirit i intended with it!
But if you think it's a bad idea, I don't mind it being NACK'ed.  In the
course of doing the cleanup i noticed a few weird things about the
packaging for libtcplay, that i wasn't sure how to best fix, so i just
recorded them in the BTS.

I also cleaned up upstream's manpages a bit, and reported those fixes
upstream at https://github.com/bwalex/tc-play/pull/84

There are probably more things that could be cleaned up upstream (the
modern toolchain makes a lot of complaints about the tcplay source), but
i haven't tried to fix or even report those yet.

I've also tested a backported version of 3.3-0.1 to debian stable, and
it seems to work fine to create an interoperable VeraCrypt volume
(methodology described below).  The backport to bookworm required
nothing more than a new entry in debian/changelog, which is published on
the debian/bookworm branch in salsa (but not uploaded anywhere yet).

I tested on a dual-boot x86_64 system where /dev/vda5 is a slice visible
to both a Debian stable installation with tcplay 3.3-0.1~bpo12+1 and a
Windows 11 system with VeraCrypt 1.26.7 (64-bit) installed.

On the Debian side, i did:

```
tcplay --create --device=/dev/vda5 --pbkdf-prf=SHA256-VC
cryptsetup open --type=tcrypt /dev/vda5 vera
mkfs -t vfat /dev/mapper/vera
mount /dev/mapper/vera /mnt
echo "this is a test" > /mnt/testing.txt
umount /mnt
cryptsetup close vera
```

Then i rebooted the system into Windows, and using Veracrypt, i was able
to map the volume onto the E: drive using the same password i'd entered
with tcplay and "cryptsetup open", and then read "this is a test" out of
E:\testing.txt

In my test, my password was plain 7-bit clean US-ASCII; i didn't try any
fancier passwords.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Jochen Sprickerhof]

Hi Jörg,

I have fixed the old debian/changelog entry and uploaded the new version 
to DELAYED/7. Please feel free to tell me if I should delay it longer.


The patch is attached.

Cheers Jochen

* Jochen Sprickerhof  [2024-04-10 07:25]:

Hi Jörg,

is there anything I can help with to get libhx updated?
(I agree with what Tobias said below.)

Cheers Jochen


* Tobias Frost  [2024-03-17 20:22]:

Control: tags -1 moreinfo

On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote:

tags 1065193 - moreinfo
thanks

Hi Tobias,



Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost:

Hi Jörg,

"debcheckout libhx" still gives me 4.17-1 as head.

After looking at your repo, I think I should point you to DEP-14
as a recommended git layout for packaging.
As the branch name indicates you are using per-package-revision
branches:
IMHO It makes little sense to have one branch per debian package
version/revision; (I had a similiar discussion on vzlogger lately,
so to avoid repetiions: #1064344#28)

Please clarify how you want to manage the package in git, as
this needs to be reflected in d/control's VCS-* fields correctly.
(this is now blocking the upload.)


I have been using Vincent Driessen's branching model and the corresponding git
extension gitflow-avh for at least 7 years with Debian and for a long time at
work.

The default branch is master and development takes place in the develop branch.

The release candidates are managed in the branch release. The extension
debian/debian-version is used as a tag during the transfer.

The master branch always contains the last published executable version to which
the git tag in debian/control points.


a> The procedure is described in the README.debian.

ok, won't further argue about how to organize your git repo, but I can
only tell the Debian perspective: It is breaking expectations as a
debcheckout libhx does today NOT give me a state that represents the
package in unstable. VCS-Git specifies where the (package)
development is happening [1].

[1] Policy 5.6.26

But as I am not using the git repo as base for the sponsoring, lets put
that topic to rest.



(The current fields say the package is maintained in the default branch
of your repo. I see a debian/ directory there, but that one is missing
released (it is at 4.17-1, while unstable is at 4.19-1.1)

The review is based on the .dsc, timestamped on mentors.d.n
2024-03-17 12:00

d/changelog is *STILL* changing history for the 4.19-1 changelog
block. (This issue must be fixed before upload.)



I think these were artifacts because my changes to the NMU were not adopted. Has
been corrected.


No it has not. I expect old changelog entries to be *identical* to
the ones that have been uploaded, and they still are not, so I fear
we are talking past each other. Please let me know what you think that
you have fixed, so that we can spot the different expectations.

For my perspective:
This is the diff from debian/changelog from the current
version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45
You are still rewriting history (second hunk of this diff), this hunk
should not exists.

diff -Naur archive/libhx-4.19/debian/changelog 
mentors/libhx-4.23/debian/changelog
--- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100
+++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100
@@ -1,3 +1,17 @@
+libhx (4.23-1) unstable; urgency=medium
+
+  * New upstream release (Closes: #1064734).
+  * Add debian/.gitignore
+  * Remove not longer needed debian/libhx-dev.lintian-overrides.
+  * Fix debian/libhx32t64.lintian-overrides.
+  * debian/copyright:
+- Add 2024 to myself.
+  * debian/control:
+- Readd BD dpkg-dev (>= 1.22.5).
+  Thanks to Tobias Frost 
+
+ -- Jörg Frings-Fürst   Sun, 17 Mar 2024 15:23:31 +0100
+
libhx (4.19-1.1) unstable; urgency=medium

 * Non-maintainer upload.
@@ -9,11 +23,8 @@

 * New upstream release.
   - Refresh symbols files.
-  * Remove empty debian/libhx-dev.symbols.
-  * debian/rules:
-- Remove build of libhx-dev.symbols.

- -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100

libhx (4.14-1) unstable; urgency=medium



From e82f0d623be16aad21807a7a5089fbfdbbd8ba05 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof 
Date: Sun, 21 Apr 2024 09:03:28 +0200
Subject: [PATCH] Fix old debian/changelog entry

---
 debian/changelog | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 5471467..e4c0c41 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -23,8 +23,11 @@ libhx (4.19-1) unstable; urgency=medium
 
   * New upstream release.
 - Refresh symbols files.
+  * Remove empty debian/libhx-dev.symbols.
+  * debian/rules:
+- Remove build of libhx-dev.symbols.
 
- -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100
+ -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
 
 libhx (4.14-1) unstable; 

Bug#1069591: cyckle: Fails to start

[Jean Louis]

Package: cyckle
Version: cycle
Severity: important

Dear Maintainer,

   * What led up to the situation?

$ cycle

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

I have entered name and password.

   * What was the outcome of this action?

Software cannot run.

$ cycle 
/usr/bin/cycle:35: DeprecationWarning: Use setlocale(), getencoding() and 
getlocale() instead
  dl = locale.getdefaultlocale()
WARNING: using XIM input method is unsupported and may result in problems with 
input handling and flickering. Consider unsetting GTK_IM_MODULE or setting to 
"ibus".
Traceback (most recent call last):
  File "/usr/bin/cycle", line 212, in OnInit
self.frame_init()
  File "/usr/bin/cycle", line 216, in frame_init
frame = MyFrame(None, -1, "")
^
  File "/usr/bin/cycle", line 81, in __init__
self.cal = Cal_Year(self)
   ^^
  File "/usr/share/cycle/cal_year.py", line 168, in __init__
self.Init_Year()
  File "/usr/share/cycle/cal_year.py", line 209, in Init_Year
self.SetScrollbars(20, 20, w/20, h/20)
TypeError: _ScrolledWindowBase.SetScrollbars(): argument 3 has unexpected type 
'float'
OnInit returned false, exiting...


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

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

Bug#1069592: runit: trigger_sv logic broken: enable and disable a service in the same loop

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-59
Severity: normal
X-Debbugs-Cc: plore...@disroot.org


in order to temporary counter #1069075 I've created a local copy of
elogind in /etc/sv/ ; then the elogind path is updated both in the run
script and in the .meta/bin metafile so that

~# cat /etc/sv/elogind/.meta/bin 
/usr/libexec/elogind

~# cat /etc/sv/elogind/run | grep elogind
exec /usr/libexec/elogind

also (to see more messages from the trigger)
touch /etc/runit/verbose

then I call the trigger as it would be activated in almost any apt
invocation and a not so "funny" thing happens

~# /lib/runit/trigger_sv setup
Runit triggered upgrade: setup
elogind enabled
elogind disabled


elogind service is enabled and disabled in the same loop.
basically the shadowing logic works for "enable" action
but not for "disable", resulting in bin metafiles being
processed for both the copy in /etc/sv/ and /usr/share/runit
with the latter that prevails due to be processed later.

this need to be addressed





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

Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.37-17
ii  runit-helper2.16.2
ii  sysuser-helper  1.3.9+really1.4.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-59

Versions of packages runit suggests:
ii  runit-services  0.7.1
ii  socklog 2.1.0+repack-5
ii  ucspi-unix  1.0-3
pn  zsh 

-- Configuration Files:
/etc/default/runit changed:
VERBOSE=1
DEBUG=1

/etc/runit/runsvdir/single/sulogin/run [Errno 2] No such file or directory: 
'/etc/runit/runsvdir/single/sulogin/run'

-- no debconf information

Bug#1068565: crash: isolation-machine autopkgtest fails: no .gnu_debuglink section

[Paul Gevers]

Hi,

On Sun, 7 Apr 2024 11:54:35 +0200 Paul Gevers  wrote:


153s crash: /usr/lib/debug/boot/vmlinux-6.6.15-amd64: no.gnu_debuglink section
153s 153s crash: /usr/lib/debug/boot/vmlinux-6.6.15-amd64: no
debugging

data available

Interestingly the test passes in unstable, stable and oldstable. So, 
what's special in testing? The version of the kernel?


I triggered a test in testing with the kernel from unstable (src:linux 
and src:linux-signed-amd64), it passed. So I'm guessing that this bug 
could be reassigned to the kernel package and closed as it seems the 
problem is fixed in unstable.


To prevent linux kernels that break the test like this from migrating to 
testing in the future you might be interested to add a test that uses 
the hint-testsuite-triggers restriction [1] with appropriate packages as 
Depends.


Paul

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069638: blender: crashes on startup (SIGSEGV)

[Marcus Better]

Package: blender
Version: 4.0.2+dfsg-1+b2
Severity: important

Dear Maintainer,

Starting blender crashes immediately, before any window is shown.

Stack trace:

(gdb) bt
#0  wm_window_set_drawable (activate=false, win=0x0, wm=0x7fff8fd68c08) at 
./source/blender/windowmanager/intern/wm_window.cc:1235
#1  wm_window_ghostwindow_add (title=0x58d0e545 "Blender", 
is_dialog=, win=0x7fff8fd44088, wm=0x7fff8fd68c08) at 
./source/blender/windowmanager/intern/wm_window.cc:785
#2  wm_window_ghostwindow_ensure(wmWindowManager*, wmWindow*, bool) 
(wm=0x7fff8fd68c08, win=0x7fff8fd44088, is_dialog=) at 
./source/blender/windowmanager/intern/wm_window.cc:817
#3  0x565087f5 in wm_window_ghostwindows_ensure(wmWindowManager*) 
(wm=wm@entry=0x7fff8fd68c08) at 
./source/blender/windowmanager/intern/wm_window.cc:874
#4  0x564d18f8 in WM_check(bContext*) (C=C@entry=0x7fff9436f788) at 
./source/blender/windowmanager/intern/wm.cc:483
#5  0x564e793e in wm_homefile_read_ex(bContext*, wmHomeFileRead_Params 
const*, ReportList*, wmFileReadPost_Params**)
(C=C@entry=0x7fff9436f788, 
params_homefile=params_homefile@entry=0x7fffd940, 
reports=reports@entry=0x0, 
r_params_file_read_post=r_params_file_read_post@entry=0x7fffd938)
at ./source/blender/windowmanager/intern/wm_files.cc:1476
#6  0x564ed1b8 in WM_init(bContext*, int, char const**) 
(C=C@entry=0x7fff9436f788, argc=argc@entry=1, argv=argv@entry=0x7fffdb18)
at ./source/blender/windowmanager/intern/wm_init_exit.cc:302
#7  0x55d67568 in main(int, char const**) (argc=1, argv=0x7fffdb18) 
at ./source/creator/creator.cc:537


With --debug::

> blender --debug 
Switching to fully guarded memory allocator.
Blender 4.0.2
argv[0] = blender
argv[1] = --debug
Writing: /tmp/blender.crash.txt
fish: Job 1, 'blender --debug' terminated by signal SIGSEGV (Address boundary 
error)

> cat /tmp/blender.crash.txt
# Blender 4.0.2, Unknown revision

# backtrace
blender(+0xf6d517) [0x55e4d22e6517]
blender(+0x83db0d) [0x55e4d1bb6b0d]
/lib/x86_64-linux-gnu/libc.so.6(+0x3c510) [0x7f3c00c5a510]
blender(+0xfb478c) [0x55e4d232d78c]
blender(+0xfb47f5) [0x55e4d232d7f5]
blender(+0xf7d8f8) [0x55e4d22f68f8]
blender(+0xf9393e) [0x55e4d230c93e]
blender(+0xf991b8) [0x55e4d23121b8]
blender(+0x813568) [0x55e4d1b8c568]
/lib/x86_64-linux-gnu/libc.so.6(+0x276ca) [0x7f3c00c456ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f3c00c45785]
blender(+0x839421) [0x55e4d1bb2421]

# Python backtrace

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

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

Versions of packages blender depends on:
ii  blender-data  4.0.2+dfsg-1
ii  fonts-dejavu  2.37-8
ii  libavcodec60  7:6.1.1-1
ii  libavdevice60 7:6.1.1-1
ii  libavformat60 7:6.1.1-1
ii  libavutil58   7:6.1.1-1
ii  libboost-locale1.83.0 1.83.0-2+b2
ii  libc6 2.37-15
ii  libembree4-4  4.3.0+dfsg-2
ii  libepoxy0 1.5.10-1+b2
ii  libfftw3-double3  3.3.10-1+b1
ii  libfftw3-single3  3.3.10-1+b1
ii  libfreetype6  2.13.2+dfsg-1+b1
ii  libgcc-s1 14-20240201-3
ii  libgmp10  2:6.3.0+dfsg-2+b1
ii  libgomp1  14-20240201-3
ii  libimath-3-1-29t643.1.9-3.1+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3+b1
ii  libjemalloc2  5.3.0-2+b1
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  libopenal11:1.23.1-4+b1
ii  libopencolorio2.1t64  2.1.3+dfsg-1.1+b1
ii  libopenexr-3-1-30 3.1.5-5.1+b1
ii  libopenimageio2.4t64  2.4.17.0+dfsg-1.1+b1
ii  libopenjp2-7  2.5.0-2+b2
ii  libopenvdb10.0t64 10.0.1-2.1+b1
ii  libosdcpu3.5.0t64 3.5.0-2.1
ii  libosdgpu3.5.0t64 3.5.0-2.1
ii  libpng16-16t641.6.43-5
ii  libpotrace0   1.16-2+b1
ii  libpugixml1v5 1.14-0.1+b1
ii  libpulse0 16.1+dfsg1-3
ii  libpython3.11t64  3.11.9-1
ii  libsdl2-2.0-0 2.30.1+dfsg-4
ii  libsndfile1   1.2.2-1
ii  libspnav0 1.1-2
ii  libstdc++614-20240201-3
ii  libswscale7   7:6.1.1-1
ii  

Bug#1068136: Bug#1069368: Updating golang-github-golang-protobuf-1-5 to fix FTBFS

[Anthony Fok]

On Sun, Apr 21, 2024 at 10:03 AM Mathias Gibbens  wrote:
>
> On Sat, 2024-04-20 at 22:40 +0800, Shengjing Zhu wrote:
> > On Sat, Apr 20, 2024 at 10:28 PM Mathias Gibbens  wrote:
> > >
> > > Hi Anthony,
> > >
> > >   A few weeks ago you uploaded a new version of golang-google-protobuf
> > > to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5
> > > v1.5.3 [1,2,3]. This has been blocking the transition of various golang
> > > packages from unstable to testing.
> > >
> > >   I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds
> > > fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1-
> > > 5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt`
> > > run testing for any build regressions with the newer version yet.
> > >
> >
> > This is a known regression in 1.5.3, see
> > https://github.com/golang/protobuf/issues/1596#issuecomment-1981208282
>
>   Since that appears to be the only change in v1.5.4, would there be
> any concerns with uploading that version to unstable? This breakage is
> starting to cause FTBFS bugs to be filed against affected packages,
> such as hugo (#1069371).
>
> Mathias

Hi Reinhard, Mathias and Shengjing,

Thank you for bringing this to my attention, and sorry for my late response!
Thank you also for your detailed investigation!  Very much appreciated!

I don't see any concern uploading v1.5.4 especially how it fixes the
regression and FTBFS
with v1.5.3, and I'll be uploading golang-github-golang-protobuf-1-5
1.5.4-1 very shortly.

Cheers,
Anthony

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

[Xiyue Deng]

Xiyue Deng  writes:

> Sean Whitton  writes:
>
>> Hello,
>>
>> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote:
>>
>>> Sean Whitton  writes:
>>>
 Hello,

 Rob, can you review the implementation in d/rules for Xiyue's patch to
 this bug, please?  I'm not sure it's the straightforward way to do it.

 Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
 for the relationships.
>>>
>>> Ah indeed, I should update the versions after the Emacs 29.3 upload,
>>> though I think you meant "1:29.3+1-2".  Also, as we are just moving
>>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed
>>> from emacs-pgtk to emacs-common but no the other way around, so I
>>> dropped the breaks on emacs-pgtk from emacs-common.
>>>
>>> I have updated the patch accordingly and attached here.  PTAL.
>>
>> Thanks.
>>
>>> (BTW, I'm always curious about the "+1" part of the version number.  I
>>> would expect something like "+dfsg" or "+ds" as we are dropping some
>>> of the non-DFSG conformant files, but why "+1"? :)
>>
>> It's just in case the DFSG split is done incorrectly and another attempt
>> is required -- given how complex it is.
>
> Ack, totally understandable.
>
> With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it
> and bumped the breaks/replaces version.  PTAL.

Rob suggested on IRC to be a bit more conservative by removing the file
and remove the directories upwards recursively so that we can catch
future addition to the directories more easily.  The patch has been
adjusted accordingly.  PTAL.

-- 
Xiyue Deng

>From 400a3efac8f0d2ab02ba18ac4cb5ee2324bf7c23 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Wed, 13 Mar 2024 10:22:46 -0700
Subject: [PATCH] Install GSettings schema in pgtk build only (Closes:
 #1050393)

* In PGTK build it generates the GSettings schema file
"/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which
is not needed in other variant.
* Move the file from emacs-common to emacs-pgtk, and adds proper
breaks/replaces to ensure a smooth upgrade.
---
 debian/changelog |  7 +++
 debian/control   | 11 +--
 debian/rules | 12 +++-
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 5d4e9f050ae..e2a31a36fcb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+emacs (1:29.3+1-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Install GSettings schema in pgtk build only (Closes: #1050393)
+
+ -- Xiyue Deng   Wed, 13 Mar 2024 10:22:10 -0700
+
 emacs (1:29.3+1-2) unstable; urgency=medium
 
   * Change native-comp-async-report-warnings-errors to `silent'.
diff --git a/debian/control b/debian/control
index e168717089f..3c04652c769 100644
--- a/debian/control
+++ b/debian/control
@@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader
 Recommends: fonts-noto-color-emoji
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-gtk, emacs-lucid, emacs-nox
-Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2)
-Breaks: emacs-bin-common (<< 1:29.2)
+Replaces:
+ emacs-gtk,
+ emacs-lucid,
+ emacs-nox,
+ emacs-bin-common (<< 1:29.2),
+ emacs-common (<< 1:29.3+1-3~),
+Breaks:
+ emacs-bin-common (<< 1:29.2),
+ emacs-common (<< 1:29.3+1-3~),
 Description: GNU Emacs editor (with GTK+ Wayland GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs with a graphical user interface
diff --git a/debian/rules b/debian/rules
index 6250f60ea9b..1262e568c80 100755
--- a/debian/rules
+++ b/debian/rules
@@ -489,6 +489,12 @@ override_dh_auto_install: $(autogen_install_files)
 	  rm -f $(pkgdir_common)/usr/share/info/emacs/dir.old
 
 	  install -d $(pkgdir_common)/usr/local/share/emacs/site-lisp
+
+	  # PGTK builds a GSettings schema that is PGTK specific and
+	  # should not be shipped in emacs-common
+	  cd $(pkgdir_common)/usr/share \
+	&& rm glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml \
+	&& rmdir --parents glib-2.0/schemas
 endif
 
 ##
@@ -548,7 +554,7 @@ override_dh_auto_install: $(autogen_install_files)
 
 ##
 # emacs-pgtk
-ifneq (,$(findstring emacs, $(shell dh_listpackages)))
+ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages)))
 	  $(call install_common_binpkg_bits,$(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk)
 
   # install desktop entries
@@ -557,6 +563,10 @@ override_dh_auto_install: $(autogen_install_files)
 	debian/emacs.desktop \
 	debian/emacs-term.desktop \
 	$(pkgdir_pgtk)/usr/share/applications/
+	  # install GSettings schema
+	  install -d $(pkgdir_pgtk)/usr/share/glib-2.0
+	  cp -a $(install_dir_pgtk)/usr/share/glib-2.0/* \
+	$(pkgdir_pgtk)/usr/share/glib-2.0
 endif
 
 

Bug#945092: Security: tcpxtract crash (heap-buffer-overflow) on Buster/Stretch/Jessie

[Vladimir Petko]

Dear Maintainers,

It seems that the crash was caused by the uninitialized pointer
'srch_machine'. The code checks it for NULL before initializing it
properly. Since the pointer was not initialized to NULL occasionally
the initialization did not happen and the code tried to access
uninitialized memory.

I was wondering if the attached patch could be accepted as a solution
for this issue?

Best Regards,
 Vladimir.


tcpxtract.debdiff
Description: Binary data

Bug#1068689: urfkill: diff for NMU version 0.5.0-7.2

[Andreas Metzler]

Control: tags 1068689 + patch
Control: tags 1068689 + pending

Dear maintainer,

I've prepared an NMU for urfkill (versioned as 0.5.0-7.2) and
uploaded it to DELAYED/00.

Regards Andreas
diff -Nru urfkill-0.5.0/debian/changelog urfkill-0.5.0/debian/changelog
--- urfkill-0.5.0/debian/changelog	2023-09-06 15:48:31.0 +0200
+++ urfkill-0.5.0/debian/changelog	2024-04-21 11:43:27.0 +0200
@@ -1,3 +1,10 @@
+urfkill (0.5.0-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop hardcoded dependency on libglib2.0-0. Closes: #1068689
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 11:43:27 +0200
+
 urfkill (0.5.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru urfkill-0.5.0/debian/control urfkill-0.5.0/debian/control
--- urfkill-0.5.0/debian/control	2023-09-06 15:47:18.0 +0200
+++ urfkill-0.5.0/debian/control	2024-04-21 11:42:51.0 +0200
@@ -10,7 +10,7 @@
 Architecture: linux-any
 Multi-Arch: foreign
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, libglib2.0-0, libdbus-1-3, libdbus-glib-1-2, dbus, libgudev-1.0-0, libpolkit-gobject-1-0, libexpat1, default-logind | logind
+Depends: ${shlibs:Depends}, ${misc:Depends}, libdbus-1-3, libdbus-glib-1-2, dbus, libgudev-1.0-0, libpolkit-gobject-1-0, libexpat1, default-logind | logind
 Description: wireless killswitch management daemon for laptops
  The urfkill daemon allow managing the rfkill-related hotkeys
  and the killswitches in a more configurable way for the common RF


signature.asc
Description: PGP signature

Bug#1068608: tfortune dependencies unsatisfiable on 32-bit non-i386 architectures.

[Andreas Metzler]

On 2024-04-08 Andre Noll  wrote:
> On Sun, Apr 07, 22:02, Peter Michael Green wrote:

> > After being rebuilt for the time64 transition, tfortune
> > depends on both liblopsub1 and liblopsub1t64. As a
> > result it is uninstallable on architectures that are undergoing
> > the time64 transition (armel, armhf and some debian-ports
> > architectures).
> > 
> > Ubuntu has already fixed this issue by removing the hardcoded
> > dependency on liblopsub1.
> > 
> > https://launchpadlibrarian.net/720835658/tfortune_1.0.1-1build1_1.0.1-1ubuntu1.diff.gz

> This was fixed already on February 2nd as suggested by Steve, see
> upstream commit f40f0aae211f. Please let me know if any further action
> is required on my part.

Hello Andre,

Well, it needs to be uploaded.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#1069585: apt: autoremoval forgets transitional packages in a OR dependency

[David Kalnischkies]

Control: reassign -1 synaptic 0.91.3

On Sun, Apr 21, 2024 at 03:50:27AM +0200, Vincent Lefevre wrote:
> "apt: autoremoval keeps all branches of an OR on the system even if
> I don't want one".
> 
> While I can understand the reason why this is wontfix, this reason
> makes no sense on transitional packages.

Instead of asking apt (and all other applications) to come up with
a complex set of rules what a transitional package might be (case in
point: policykit-1 is not in section oldlibs[0]) you should focus
your energy on making that transition actually happen if you care
that much about it.

[0] https://wiki.debian.org/RenamingPackages


> As an example:
> 
> qaa:~> apt autoremove -s
> NOTE: This is only a simulation!
>   apt needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 82
> 
> but policykit-1 (marked as automatically installed) could be removed:
> 
> qaa:~> aptitude remove -s policykit-1
> The following packages will be REMOVED:  
>   policykit-1 
> 0 packages upgraded, 0 newly installed, 1 to remove and 82 not upgraded.
> Need to get 0 B of archives. After unpacking 34.8 kB will be freed.
> Would download/install/remove packages.
> 
> I suppose that "apt autoremove" doesn't remove it because of
> the OR dependency:
> 
> qaa:~> aptitude why policykit-1
> i   synaptic Depends pkexec | policykit-1
> 
> (at least, this seems to be one of the reasons).

synaptics could drop the or on policykit-1 – or if for some reason
keeping it is desirable make it a versioned on, like:
|   pkexec | policykit-1 (<< first-transitional-version~)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1069597: gnulib: describe a security patch mechanism

[Simon Josefsson]

Package: gnulib
Severity: wishlist

I don't know how to implement this, so I'll describe it pending for
inspiration or someone else to come along who wants to work on this.

Let's say we are in a situation were Debian packages Build-Depends on
the gnulib package as the source for gnulib related source code.  I've
implemented this for libntlm [1], but it could be done for any package
that uses gnulib.  That approach would reduce the need to audit vendored
gnulib code from upstream tarballs.  Most packages today (e.g.,
coreutils, tar, gzip inetutils) just vendor all gnulib files into to the
tarball.  So this wishlist is more relevant in a future reality where
Build-Depends on gnulib is a more widespread solution.

If there is a security bug in gnulib code, it would make sense to
manually patch that the gnulib package, and then automatically rebuild
all the dependent packages to get the fix released.  Rather than
manually patch all packages that has vendored gnulib code in them and
release those.

The GNULIB_REVISION or --gnulib-refdir mechanism used by gnulib does not
support this way of working: the git commit to use comes from the
package (e.g., libntlm) via GNULIB_REVISION in bootstrap.conf or through
a git submodule that pins the gnulib commit.  So patching code in the
Debian gnulib package doesn't alter the code that's in the gnulib git
commit tree used.

Some mechanism that let packages pin the gnulib git commit to use AND
then let the Debian gnulib package be able to patch the resulting gnulib
code seems to be needed.

Possibly we can implement rules via the new
/usr/share/gnulib/gnulibvars.mk dpkg makefile snippet.  Then all
packages that rely on gnulib would have to include that and invoke the
hook, in order to allow the gnulib Debian package to provide a patched
gnulib source code, before the package is building it.

/Simon

[1] 
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/


signature.asc
Description: PGP signature

Bug#1069586: Chromium native Wayland support broken

[Stephan Verbücheln]

Some more tests confirm the following:

--ozone-platform=waylandworks
--ozone-platform-hint=wayland   does not work

Regards
Stephan

Bug#1069604: dahdi-linux: isolation-machine autopkgtest fails: Test DAHDI call in Asterisk timed out.

[Paul Gevers]

Source: dahdi-linux
Version:
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report. On top of that, in testing it fails because 
asterisk isn't available there.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/d/dahdi-linux/unstable/amd64/45704035/#S15


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067915: veusz: diff for NMU version 3.6.2-1.1

[Andreas Metzler]

Control: tags 1067915 + patch
Control: tags 1067915 + pending

Dear maintainer,

I've prepared an NMU for veusz (versioned as 3.6.2-1.1) and
uploaded it to DELAYED/00.

kind regards Andreas
diff -Nru veusz-3.6.2/debian/changelog veusz-3.6.2/debian/changelog
--- veusz-3.6.2/debian/changelog	2023-03-20 07:10:18.0 +0100
+++ veusz-3.6.2/debian/changelog	2024-04-21 14:19:21.0 +0200
@@ -1,3 +1,10 @@
+veusz (3.6.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop runtime library packages (not -dev) from b-d. Closes: #1067915
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 14:19:21 +0200
+
 veusz (3.6.2-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru veusz-3.6.2/debian/control veusz-3.6.2/debian/control
--- veusz-3.6.2/debian/control	2023-03-20 07:10:18.0 +0100
+++ veusz-3.6.2/debian/control	2024-04-21 14:18:16.0 +0200
@@ -6,12 +6,6 @@
 Build-Depends: debhelper-compat (= 13),
dh-exec,
dh-python,
-   libqt5core5a,
-   libqt5dbus5,
-   libqt5gui5,
-   libqt5svg5,
-   libqt5widgets5,
-   libqt5xml5,
python3-all,
python3-all-dev,
python3-astropy,


signature.asc
Description: PGP signature

Bug#1041027: rapidjson: diff for NMU version 1.1.0+dfsg2-7.2

[Micha Lenk]

Dear maintainer,

I've prepared an NMU for rapidjson (versioned as 1.1.0+dfsg2-7.2). The diff
is attached to this message.

Regards,
Micha
diff -Nru rapidjson-1.1.0+dfsg2/debian/changelog rapidjson-1.1.0+dfsg2/debian/changelog
--- rapidjson-1.1.0+dfsg2/debian/changelog	2022-10-15 18:10:14.0 +0200
+++ rapidjson-1.1.0+dfsg2/debian/changelog	2024-04-21 15:12:21.0 +0200
@@ -1,3 +1,11 @@
+rapidjson (1.1.0+dfsg2-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/rules: Switch to C++ 14 to fix FTBFS with googletest >= 1.13.0
+(Closes: #1041027)
+
+ -- Micha Lenk   Sun, 21 Apr 2024 15:12:21 +0200
+
 rapidjson (1.1.0+dfsg2-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rapidjson-1.1.0+dfsg2/debian/rules rapidjson-1.1.0+dfsg2/debian/rules
--- rapidjson-1.1.0+dfsg2/debian/rules	2019-01-31 21:17:42.0 +0100
+++ rapidjson-1.1.0+dfsg2/debian/rules	2024-04-21 15:10:49.0 +0200
@@ -3,6 +3,12 @@
 # output every command that modifies files on the build system.
 #DH_VERBOSE = 1
 
+# Needed since googletest 1.13.0 (see #1041027)
+export DEB_CXXFLAGS_MAINT_APPEND = -std=c++14
+
 %:
 	dh $@
 
+override_dh_auto_configure:
+	# Needed since googletest 1.13.0 (see #1041027)
+	dh_auto_configure -- -DRAPIDJSON_BUILD_CXX11=OFF

Bug#1068773: Subject: blhc: Stack clash and branch protection flag issues in Debian Bookworm and older releases

[Simon Ruderich]

Hi,

On Wed, Apr 10, 2024 at 09:09:13PM +, aquilamac...@riseup.net wrote:
> The ${RELEASE} variable in the context of this issue refers to the
> specific Debian release being used during the Salsa CI process. One
> potential solution that has been considered is to ensure that
> blhc:${RELEASE} correctly handles the flags for each release. This
> approach could alleviate the compilation errors and ensure consistency
> across different Debian releases.
>
> For more details, you can check the issue in the Salsa CI repository at
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/340
>
> Before proceeding with any changes, I would appreciate your input on
> this matter. Specifically, do you think it would be sensible to use blhc
> from each release? Your insights would be greatly appreciated.

I think the best solution is to use the blhc version from the
corresponding release (i.e. blhc:${RELEASE}). Otherwise each
change to flags in blhc will require manual work for earlier
releases as carnil mentioned.

The blhc version in each release should be able to handle the
flags for that release (otherwise it's a bug which should be
fixed). So the suggested first approach should work fine and
cause the less additional maintenance overhead.

Best,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1061421: Fails to start after an upgrade

[Jeremy Bícha]

On Sun, Apr 21, 2024 at 2:36 AM Arto Jantunen  wrote:
>
> Jeremy Bícha  writes:
> > Please verify whether wlgreet is working for you now.
>
> Was something changed somewhere? What, where?
>
> On trixie the issue reproduces exactly the same (even with sway upgraded
> to the binNMU'd version from sid).

There have been a huge amount of changes, but most of those changes
were in Unstable and haven't reached Testing yet.

Marc, there is a fix for sway 1.9 in wlgreet 0.5. Do you want to try
if that improves anything here?

Thank you,
Jeremy Bícha

Bug#1069596: xscreensaver does not ask password on first key hit

[Alessandro Vesely]

Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: important

Dear Maintainer,

after the last system update (6.1.0-20-amd64) 
accessing the system became really hard.  Today 
it took a quarter of an hour of random key hits
before I got a request to authenticate.

I attach a log file, starting on the first key hit.

Best
Ale

-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.65.2devuan1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u4
ii  libcrypt11:4.4.33-2
ii  libelogind-compat [libsystemd0]  246.10-5
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpam0g 1.5.2-6+deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxt6   1:1.2.1-1.1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.06+dfsg1-3

Versions of packages xscreensaver recommends:
ii  fonts-urw-base35  20200910-7
ii  libjpeg-turbo-progs   1:2.1.5-2
ii  perl  5.36.0-7+deb12u1
ii  wamerican [wordlist]  2020.12.07-2
ii  xfonts-100dpi 1:1.0.5

Versions of packages xscreensaver suggests:
ii  epiphany-browser [www-browser]  43.1-1
ii  firefox-esr [www-browser]   115.10.0esr-1~deb12u1
pn  fortune 
pn  gdm3 | kdm-gdmcompat
ii  lynx [www-browser]  2.9.0dev.12-1
pn  qcam | streamer 
ii  w3m [www-browser]   0.5.3+git20230121-2
pn  xdaliclock  
pn  xfishtank   
pn  xscreensaver-data-extra 
pn  xscreensaver-gl 
pn  xscreensaver-gl-extra   

-- debconf-show failed
xscreensaver: 11:14:13: X11 KeyPress  
xscreensaver: 11:14:13: checking init file
xscreensaver: 11:14:13: authorizing
xscreensaver: 11:14:13: grabbing mouse on 0x41a... GrabSuccess
xscreensaver: 11:14:13: pid 372: launched xscreensaver-auth --verbose
xscreensaver-auth: 11:14:13: pwnam: couldn't get password of "ale"
xscreensaver-auth: 11:14:13: initial effective uid/gid was root/staff (0/50)
xscreensaver-auth: 11:14:13: changed uid/gid to ale/staff (1000/50)
xscreensaver-auth: 11:14:13: running as user "ale"
xscreensaver-auth: 11:14:13: PAM: pam_start ("xscreensaver", "ale", ...) ==> 0 
(Success)
xscreensaver-auth: 11:14:13:   pam_set_item (p, PAM_TTY, ":0") ==> 0 (Success)
xscreensaver-auth: 11:14:13:   pam_authenticate (...) ...
xscreensaver-auth: 11:14:13: pam_conversation (ECHO_OFF="Password: ") ...
xscreensaver-auth: 11:14:13: mouse is at 420,41 on monitor 0 1280x1024+0+0 
"VGA-0"
xscreensaver-auth: 11:14:14: theme: default
xscreensaver-auth: 11:14:14: kbd layout: English (US)
xscreensaver-auth: 11:14:14: re-creating window: size changed
xscreensaver-auth: 11:14:23: XI RawKeyPress  
xscreensaver-auth: 11:14:23: XI RawKeyRelease
xscreensaver-auth: 11:14:23: XI RawKeyPress  
xscreensaver-auth: 11:14:23: XI RawKeyRelease
xscreensaver-auth: 11:14:23: XI RawKeyPress  
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress  
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress  
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress  
xscreensaver-auth: 11:14:24: XI RawKeyRelease
xscreensaver-auth: 11:14:24: XI RawKeyPress  
xscreensaver-auth: 11:14:25: XI RawKeyRelease
xscreensaver-auth: 11:14:25: XI RawKeyPress  
xscreensaver-auth: 11:14:25: XKB event 2
xscreensaver-auth: 11:14:25: kbd layout: English (US)
xscreensaver-auth: 11:14:25: XI RawKeyPress  
xscreensaver-auth: 11:14:25: XKB event 2
xscreensaver-auth: 11:14:25: kbd layout: English (US)
xscreensaver-auth: 11:14:26: XI RawKeyPress  
xscreensaver-auth: 11:14:26: XI RawKeyRelease
xscreensaver-auth: 11:14:26: XI RawKeyRelease
xscreensaver-auth: 11:14:26: XKB event 2
xscreensaver-auth: 11:14:26: kbd layout: English (US)
xscreensaver-auth: 11:14:26: XI RawKeyRelease
xscreensaver-auth: 11:14:26: XKB event 2
xscreensaver-auth: 11:14:26: kbd layout: English (US)
xscreensaver-auth: 11:14:27: XI RawKeyPress  
xscreensaver-auth: 11:14:27: XKB event 2
xscreensaver-auth: 11:14:28: kbd layout: English (US)
xscreensaver-auth: 11:14:28: XI RawKeyPress  

Bug#1069079: gnome-snapshot: No image captured, viewfinder stays black

[Matthias Geiger]

On Tue, 16 Apr 2024 08:38:36 +0200 Ralph Aichinger  wrote:
> Sorry, forgot: Cheese starts up fine and gets a picture from my camera
> (built in camera of Surface Laptop model 1867). Console messages from
> cheese, program works without problem:
>
> ralph@surface:~$ cheese
> [19:09:28.423130575] [95032] WARN IPAManager ipa_manager.cpp:154 No
> IPA found in '/usr/lib/x86_64-linux-gnu/libcamera'
> [19:09:28.423207194] [95032] INFO Camera camera_manager.cpp:284
> libcamera v0.2.0
>
> (cheese:95032): GStreamer-CRITICAL **: 08:37:33.291:
> gst_structure_get_value: assertion 'structure != NULL' failed
>
>

>

Hi Ralph,

thanks for the detailed bugreport. Would you mind submitting that to 
upstream ?


They are more likely to know the exact reason why snapshot is not 
working as there are a lot of factors at play here. pipewire 1.0.5 was 
supposed to resolve most issues but not all, it seems.


best,

--
Matthias Geiger 
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068608: tfortune dependencies unsatisfiable on 32-bit non-i386 architectures.

[Andre Noll]

On Sun, Apr 21, 11:51, Andreas Metzler wrote
> On 2024-04-08 Andre Noll  wrote:
> > On Sun, Apr 07, 22:02, Peter Michael Green wrote:
> 
> > > After being rebuilt for the time64 transition, tfortune
> > > depends on both liblopsub1 and liblopsub1t64. As a
> > > result it is uninstallable on architectures that are undergoing
> > > the time64 transition (armel, armhf and some debian-ports
> > > architectures).
> > > 
> > > Ubuntu has already fixed this issue by removing the hardcoded
> > > dependency on liblopsub1.
> > > 
> > > https://launchpadlibrarian.net/720835658/tfortune_1.0.1-1build1_1.0.1-1ubuntu1.diff.gz
> 
> > This was fixed already on February 2nd as suggested by Steve, see
> > upstream commit f40f0aae211f. Please let me know if any further action
> > is required on my part.
> 
> Hello Andre,
> 
> Well, it needs to be uploaded.

Sure, but I don't have permissions to do this myself. What's the best
way to get it uploaded?

Thanks
Andre
-- 
Max Planck Institute for Biology
Tel: (+49) 7071 601 829
Max-Planck-Ring 5, 72076 Tübingen, Germany
http://people.tuebingen.mpg.de/maan/

Bug#1068129: ITP: redict - Licensing questions

[Drew DeVault]

On Sun Apr 21, 2024 at 11:38 AM CEST, Andrea Pappacoda wrote:
> For example, I think that the following file block:
>
> Files: *
> Copyright:
>  2006-2014 Salvatore Sanfilippo 
>  2024 Redict contributors
> License: LGPL-3.0-only
>
> should instead look something like:
>
> Files: *
> Copyright:
>  2006-2014 Salvatore Sanfilippo 
>  2024 Redict contributors
> License: LGPL-3.0-only and BSD-3-Clause

Indeed it should be LGPL-3.0-only and BSD-3-Clause.

Thanks for clarifying that!


signature.asc
Description: PGP signature

Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.

[Paul Gevers]

Source: dhcpcd
Version: 1:10.0.6-1
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/d/dhcpcd/testing/amd64/45702932/#S7

 29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp: 
[---

 30s Preparing virtual interfaces...
 30s Actual changes:
 30s tx-checksum-ip-generic: off
 30s tx-tcp-segmentation: off [not requested]
 30s tx-tcp-ecn-segmentation: off [not requested]
 30s tx-tcp-mangleid-segmentation: off [not requested]
 30s tx-tcp6-segmentation: off [not requested]
 30s tx-checksum-sctp: off
 30s Preparing dnsmasq configuration...
 35s Obtaining network configuration for veth1 via dhcp...
 37s RA from non local address fdae:9322:f1cc::1
 43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit 
systemd-timesyncd.service not found.
 43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit 
systemd-timesyncd.service not found.
 48s Check if the NTP server is made available to daemon...Failed to 
parse bus message: No route to host
 49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp: 
---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069558: lomiri-ui-toolkit: FTBFS on armel: QWARN : components::UnknownTestFunc() file:///usr/lib/arm-linux-gnueabi/qt5/qml/QtTest/SignalSpy.qml:258: Error: Invalid write to global property "qtest

[Mike Gabriel]

Control: severity -1 important
Control: tags -1 moreinfo

Hi Lucas,

On  Sa 20 Apr 2024 15:21:10 CEST, Lucas Nussbaum wrote:


Source: lomiri-ui-toolkit
Version: 1.3.5100+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel

Hi,

During a rebuild of all packages in sid, your package failed to build
on armel.


Relevant part (hopefully):



[...]


The bug title seems misleading. Causes of the FTBFS are these test  
failures of the following kind:


QWARN  : components::AbstractButtonAPI::test_sensing_area(zero size,  
no margins, tap in visual) "No touch device registered. Register one  
using registerTouchDevice() before using touchClick"
FAIL!  : components::AbstractButtonAPI::test_sensing_area(zero size,  
no margins, tap in visual) 'wait for signal clicked' returned FALSE.  
()


Can this be related to a slightly different test bed? A VM without  
evdev device? (Not sure if a PC-like hardware is required for  
successfully running those tests).


Mike


--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgprC6PQ3W8Yx.pgp
Description: Digitale PGP-Signatur

Bug#1068174: Debian FPGA toolchain update and testing (Was: Bug#1068174: yosys: Please package the latest upstream release)

[Philipp Klaus Krause]

Am 20.04.24 um 16:15 schrieb Daniel Gröber:

On Mon, Apr 01, 2024 at 11:48:16AM +0200, Philipp Klaus Krause wrote:

I use yosys to synthesize for the iCE40UP and GateMate FPGAs. IMO, the
current upstream release 0.38 has substantial improvements over the 0.33
release currently in Debian.


Neat, are the GateMates finally available on the open market then? I'd love
to get my hands on some dev hardware.


Yes, I got the GateMateA1-EVB board from Olimex, since it is
substantially cheaper than the official CologneChips one, and I have no
use for most of the extra features of the CologneChips board:
https://www.olimex.com/Products/FPGA/GateMate/GateMateA1-EVB/open-source-hardware


Are you open to doing some testing for the new package version once I get
around to putting it together? I can do end-to-end testing on ICE40(HX) and
(probably) GW1N (if I can figure out how to flash this thing) maybe
@Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?


I can do some testing on iCE40UP5 (iCEBreaker board) and GateMateA1
(GateMateA1-EVB board). I run Debian on amd64, arm64, and ppc64 (but so
far used yosys on amd64 only).


I've been meaning to look into what we could use for testing beyond simple
blinkies. Perhaps some CPU? I'd like to have something that can run
internal consistency checks. If anyone has any ideas let me know.


My use-case is basically that: the experimental f8 CPU
(https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/f8/f8/). I
actually use "simple blinkies" for testing": a basic f8-based SoC, that
runs a program on the CPU that does the blinking. However, I write
System Verilog, so I use sv2v (not yet in Debian) as a preprocessor
before feeding my code into yosys.

Philipp

P.S.: I saw that yosys 0.40 was just released. I'll do a quick test of
the upstream release in the next few days.

Bug#1069611: dpdk-kmods: isolation-machine autopkgtest fails: tar: Cowardly refusing to create an empty archive

[Paul Gevers]

Source: dpdk-kmods
Version: 0~20230205+git-1
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/d/dpdk-kmods/testing/amd64/45706000/

 28s autopkgtest [13:45:23]: test test-dkms: [---
 28s tar: Cowardly refusing to create an empty archive
 28s Try 'tar --help' or 'tar --usage' for more information.
 29s autopkgtest [13:45:24]: test test-dkms: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066224: radvd_2.19-2_amd64.changes REJECTED

[Geert Stappers]

tags 1066224 pending
stop

On Sun, Apr 21, 2024 at 10:19:31AM +, Debian FTP Masters wrote:
> radvd_2.19-2_amd64.deb: trying to install to unstable, but could not find 
> source (radvd 1:2.19-2)

Oops.  On the upside: an opportunity to add an tag


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#964214: libdebhelper-perl: dh_auto_configure cannot do out-of-tree builds for qmake buildsystem

[Jiri Palecek]

On Sat, 4 Jul 2020 00:01:15 +0200 Niels Thykier wrote:
> Thorsten Glaser:
> > Package: libdebhelper-perl
> > Version: 13.1
> > Severity: normal
> >
> > Apparently, dh7 fails to tell qmake the location of the source
directory
> > when attempting an out-of-tree build:
> >
> >
> > […]
> >
> >
> > The qmake invocation syntax error message is somewhat misleading,
> > but looking at the invocation command line it becomes somewhat clearer.
> >
>
> Interesting. I am not sure out of source builds have ever been
> supported by qmake (at least not correctly at any rate). If you know
> how to do it, then I am happy to look at fixing it.

Qmake does indeed support out of source builds (and for a long time -
you can find questions about it on the forums from 2010). You can check
a possible implementation of debhelper support for it in MR 125.

Regards

    Jiri Palecek

Bug#1069408: kwin: FTBFS on arm64: present.h:20:10: fatal error: dri3.h: No such file or directory

[Aurélien COUDERC]

Control: reassign -1 libxcb
Control: found -1 1.17.0-1
Control: retitle -1 libxcb-present-dev 1.17 misses dependency on libxcb-dri3-dev
Control: affects -1 + kwin

Le samedi 20 avril 2024, 14:16:27 CEST Lucas Nussbaum a écrit :
> Source: kwin
> Version: 4:5.27.10-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on arm64.

Dear X Team,

it seems to me that libxcb-present-dev 1.17 misses dependency on 
libxcb-dri3-dev which was added as a private dependency between 1.15 and 1.17.
This is causing kwin to FTBFS.

If that’s correct you’ll find an MR against the libxcb repo adding that 
dependency at [1].


[1] https://salsa.debian.org/xorg-team/lib/libxcb/-/merge_requests/3


Happy hacking,
--
Aurélien

Bug#1069600: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found

[Paul Gevers]

Source: dm-writeboost
Version: 2.2.16-0.1
X-Debbugs-CC: a...@debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/d/dm-writeboost/testing/amd64/45702936/

 28s autopkgtest [11:08:23]: test test-dm-writeboost.sh: 
[---

 29s II: Checking for 14G available disk space...OK
 29s II: Creating loop files:
 29s II: - backing-2030.img...OK
 29s II: - cache-2030.img...OK
 29s II: Connecting to loop devices:
 29s II: - backing-2030.img -> /dev/loop0...FAILED!
 29s II: Deleting file images...
 29s 
/tmp/autopkgtest.QIZ0oY/build.oQN/src/debian/tests/test-dm-writeboost.sh: 
70: sudo: not found
 29s 
/tmp/autopkgtest.QIZ0oY/build.oQN/src/debian/tests/test-dm-writeboost.sh: 
23: sudo: not found

 29s EE: FAIL
 29s autopkgtest [11:08:24]: test test-dm-writeboost.sh: 
---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.

[Martin-Éric Racine]

su 21. huhtik. 2024 klo 14.12 Paul Gevers (elb...@debian.org) kirjoitti:
>
> Source: dhcpcd
> Version: 1:10.0.6-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: isolation-machine
>
> Dear maintainer(s),
>
> Your package has an autopkgtest, great. I recently added support for
> isolation-machine tests on ci.debian.net for amd64 and added your
> package to the list to use that. However, it fails. Can you please
> investigate the situation and fix it? I copied some of the output at the
> bottom of this report.

[...]

>   29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp:
> [---
>   30s Preparing virtual interfaces...
>   30s Actual changes:
>   30s tx-checksum-ip-generic: off
>   30s tx-tcp-segmentation: off [not requested]
>   30s tx-tcp-ecn-segmentation: off [not requested]
>   30s tx-tcp-mangleid-segmentation: off [not requested]
>   30s tx-tcp6-segmentation: off [not requested]
>   30s tx-checksum-sctp: off
>   30s Preparing dnsmasq configuration...
>   35s Obtaining network configuration for veth1 via dhcp...
>   37s RA from non local address fdae:9322:f1cc::1
>   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> systemd-timesyncd.service not found.
>   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> systemd-timesyncd.service not found.
>   48s Check if the NTP server is made available to daemon...Failed to
> parse bus message: No route to host
>   49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp:
> ---]

That service unit is provided by systemd-timesyncd, which systemd
recommends. Basically, unless your testing environment explicitly
installs another package providing time-daemon, this shouldn't happen,
since systemd would have pulled systemd-timesyncd by default.

Martin-Éric

Bug#1069606: Please package new upstream release 2.4.0

[Maia Everett]

Package: s3cmd
Version: 2.3.0-1 

s3cmd has had a new upstream release since December 2024:

https://github.com/s3tools/s3cmd/releases/tag/v2.4.0

Please package it, as 2.3.0 is broken with Python 3.12. 2.4.0 includes a
fix for this issue:

https://github.com/s3tools/s3cmd/issues/1343

Bug#1069106: openmpi: 32 bit pmix_init:startup:internal-failure: help-pmix-runtime.txt: No such file

[Drew Parsons]

Source: openmpi
Version: 4.1.6-12
Followup-For: Bug #1069106
Control: reopen 1069106

4.1.6-12 was intended to fix this bug, but it's still occuring

e.g.
https://ci.debian.net/packages/o/openmpi/unstable/i386/45630865/
https://ci.debian.net/packages/o/openmpi/unstable/armhf/45630866/

Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.

[Martin-Éric Racine]

su 21. huhtik. 2024 klo 14.59 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> su 21. huhtik. 2024 klo 14.12 Paul Gevers (elb...@debian.org) kirjoitti:
> >
> > Source: dhcpcd
> > Version: 1:10.0.6-1
> > Severity: important
> > User: debian...@lists.debian.org
> > Usertags: isolation-machine
> >
> > Dear maintainer(s),
> >
> > Your package has an autopkgtest, great. I recently added support for
> > isolation-machine tests on ci.debian.net for amd64 and added your
> > package to the list to use that. However, it fails. Can you please
> > investigate the situation and fix it? I copied some of the output at the
> > bottom of this report.
>
> [...]
>
> >   29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp:
> > [---
> >   30s Preparing virtual interfaces...
> >   30s Actual changes:
> >   30s tx-checksum-ip-generic: off
> >   30s tx-tcp-segmentation: off [not requested]
> >   30s tx-tcp-ecn-segmentation: off [not requested]
> >   30s tx-tcp-mangleid-segmentation: off [not requested]
> >   30s tx-tcp6-segmentation: off [not requested]
> >   30s tx-checksum-sctp: off
> >   30s Preparing dnsmasq configuration...
> >   35s Obtaining network configuration for veth1 via dhcp...
> >   37s RA from non local address fdae:9322:f1cc::1
> >   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> > systemd-timesyncd.service not found.
> >   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> > systemd-timesyncd.service not found.
> >   48s Check if the NTP server is made available to daemon...Failed to
> > parse bus message: No route to host
> >   49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp:
> > ---]
>
> That service unit is provided by systemd-timesyncd, which systemd
> recommends. Basically, unless your testing environment explicitly
> installs another package providing time-daemon, this shouldn't happen,
> since systemd would have pulled systemd-timesyncd by default.

Anyhow, no harm done. The following commit should fix it:

https://salsa.debian.org/debian/dhcpcd/-/commit/55e588b0d7561c697f3fedfddef3feeb6c8b34b9

Martin-Éric

Bug#1069609: RFS: mount-zip/1.0.14-1 [RFP] -- Read-only FUSE file system for ZIP archives

[Fab Stz]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "mount-zip":

 * Package name : mount-zip
   Version  : 1.0.14-1
   Upstream contact : François Degros 
 * URL  : https://github.com/google/mount-zip
 * License  : GPL-3.0-or-later
 * Vcs  : https://salsa.debian.org/bastif/mount-zip
   Section  : utils

The source builds the following binary packages:

  mount-zip - Read-only FUSE file system for ZIP archives

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

  https://mentors.debian.net/package/mount-zip/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mount-zip/mount-zip_1.0.14-1.dsc

Changes for the initial release:

 mount-zip (1.0.14-1) unstable; urgency=medium
 .
   * Initial release. Closes: #1068638

Regards,

Bug#1041027: rapidjson: diff for NMU version 1.1.0+dfsg2-7.2

[Micha Lenk]

Dear maintainer,

On Sun, 21 Apr 2024 15:23:27 +0200 Micha Lenk  wrote:

I've prepared an NMU for rapidjson (versioned as 1.1.0+dfsg2-7.2). The diff
is attached to this message.


I forgot to mention, I've pushed my changes to salsa on branch 
'NMU_fix_for_debbug_1041027':

https://salsa.debian.org/debian/rapidjson/-/commits/NMU_fix_for_debbug_1041027?ref_type=heads

Regards,
Micha

Bug#1069247: libconfig-model-dpkg-perl: test failures

[Niko Tyni]

[Copying Julian as the apt maintainer.]

On Sat, Apr 20, 2024 at 09:02:35PM +0300, Niko Tyni wrote:
> On Sat, Apr 20, 2024 at 11:09:17AM +0200, Dominique Dumont wrote:
> > On Thursday, 18 April 2024 19:21:55 CEST you wrote:
> > > Source: libconfig-model-dpkg-perl
> > > Version: 3.004
> > > Severity: serious
> > > Tags: ftbfs
> > > Justification: fails to build from source
> > 
> > This really looks like a bug with prove:
> > 
> > $ perl t/reorder.t 
> > ok 1 -  test re-ordered list
> > 1..1
> 
> > I can't see what's wrong with the output of reorder test...
> 
> Looks like something is injecting apt progress messages to stdout with
> CR characters hiding it on the terminal but obviously not from `prove`.
> 
> $ perl t/reorder.t |od -c

> 460   f   o   r   m   a   t   i   o   n   .   .   .   0   %  \r
> 500
> *
> 540  \r   o   k   1   -   t   e   s   t   r   e
> 560   -   o   r   d   e   r   e   d   l   i   s   t  \n   1   .
> 600   .   1  \n

These come from apt, via libapt-pkg-perl which I don't think has ever
filtered them away. The thing that broke this is surely output changes
in apt 2.9.

The crucial difference wrt. at least bookworm seems to be that the
apt messages used to end with a line feed "\n" before the actual TAP
format started.  Now it only has a carriage return "\r" there. Apparently
`prove` ignores unknown lines, but now interprets all the apt output to
be part of the first line that ends with the 'ok 1' part. So that gets
ignored as well.

I see the TAP format spec says at

  https://testanything.org/tap-version-14-specification.html

  A Harness should normalize line endings by replacing any instances of
  \r\n or \r in the TAP document with \n.

so I suppose this might be a normal/wishlist bug in `prove`. In that case,
please note that it needs to be fixed in libtest-harness-perl first as
src:perl just bundles an older version of it.

Not sure if apt should go back to ending its output with a line
feed. Julian, what do you think?
-- 
Niko

Bug#1069610: RFS: modernizr/3.13.0-0.1 [NMU] -- JavaScript library to detect HTML5 and CSS3 features in the user's browser

[Fab Stz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

It's an NMU and the changes of this NMU have already been approved and merged 
in salsa at https://salsa.debian.org/js-team/modernizr

 * Package name : modernizr
   Version  : 3.13.0-0.1
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://modernizr.com/
 * License  : MIT
 * Vcs  : https://salsa.debian.org/js-team/modernizr
   Section  : javascript

The source builds the following binary packages:

  libjs-modernizr - JavaScript library to detect HTML5 and CSS3 features in 
the user's browser

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/m/modernizr/
modernizr_3.13.0-0.1.dsc

Changes since the last upload:

 modernizr (3.13.0-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream release Closes: #1001203, #1067130
   * d/control:
  - update Build-Depends
  - update standards version to 4.6.2, no changes needed.
   * d/copyright:
  - add/update entries for the new version
  - remove now useless Files-Excluded (file is not shipped anymore)
   * d/install: don't install feature-detects/* anymore
   * d/rules:
  - build modernizr.js with upstream's new build script
  - remove repack suffix (not needed anymore) and add it to d/watch
   * d/s/lintian-overrides: add lintian-overrides for 'source-is-missing'
 errors (files contain test data)
   * d/watch: update URL & methodology, add repacksuffix here instead of
 d/rules (but not used because there is no Files-Excluded in d/copyright)
   * add missing source file 'file.js' and add patch to use it.

Regards,

Bug#979617: tcplay: VeraCrypt support

[GCS]

Hi,

On Sun, Apr 21, 2024 at 9:06 AM Daniel Kahn Gillmor  wrote:
> I've just confirmed what Johannes said about tcplay 3.3 building easily
> on debian.  I uploaded 3.3-0.1 to unstable as an NMU to DELAYED/15,
> after cleaning up the packaging a little bit.
[...]
> Hopefully this NMU is welcomed in the helpful spirit i intended with it!
> But if you think it's a bad idea, I don't mind it being NACK'ed.  In the
> course of doing the cleanup i noticed a few weird things about the
> packaging for libtcplay, that i wasn't sure how to best fix, so i just
> recorded them in the BTS.
 I prefer communication first. :) Currently I'm travelling so I can
only check it on Tuesday.

> I've also tested a backported version of 3.3-0.1 to debian stable, and
> it seems to work fine to create an interoperable VeraCrypt volume
> (methodology described below).
 There were some license problems in the past at least, which
prevented packaging. I will check the current situation.

Regards,
Laszlo/GCS

Bug#1069614: erfs: isolation-machine autopkgtest fails: sshfs failed

[Paul Gevers]

Source: erfs
Version: 1.4-1
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/e/erfs/testing/amd64/45706002/

 49s autopkgtest [13:48:31]: test upstream-tests: [---
 50s read: Connection reset by peer
 50s ERROR: sshfs failed.
 50s 1. The volume is already mounted.
 50s 2. Wrong SHARE-SECRET.
 50s 3. The server can not be reached.
 50s autopkgtest [13:48:32]: test upstream-tests: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069615: RM: diaspora -- ROM; unmaintained, rc-buggy

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: diasp...@packages.debian.org
Control: affects -1 + src:diaspora
User: ftp.debian@packages.debian.org
Usertags: remove

I was hoping to come back to updating diaspora, but I don't think I will 
be able to find time. It is affected by rc bugs #924109, #974014 and 
also blocking removal of its unmaintained dependencies.

Bug#1069616: rc-buggy, not needed anymore

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ruby-...@packages.debian.org
Control: affects -1 + src:ruby-eye
User: ftp.debian@packages.debian.org
Control: block -1 by 1069615

rc buggy #1031479 and originally packaged as dependency of diaspora 
which is now requested to be removed.

Bug#1037521: (no subject)

[Simon Ruderich]

Hi,

On Fri, Apr 05, 2024 at 12:48:19AM -0400, Yogeswaran Umasankar wrote:
> eribe...@debian.org, Matthias Geiger 
> Bcc: Subject: Re: false positive NONVERBOSE BUILD for rust code in Python
> modules
> Reply-To: Hi,
>
> I am having similar issue in another package 'python-cotengrust' [0].
> The link for buildlog [1].
>
> [0] https://salsa.debian.org/python-team/packages/python-cotengrust/
> [1] 
> https://salsa.debian.org/python-team/packages/python-cotengrust/-/jobs/5519541

as discussed in IRC the problem is that blhc cannot detect that
this is a rust package. In regular buildd logs the "Filtered
Build-Depends:" lines contain the build dependencies. This gives
blhc a way to enable special handling for certain situations (in
this case if a rust compiler is used).

I couldn't find a way to get this information from the salsa
build logs. If they could be modified to show the build
dependencies then I'll adapt blhc to detect this case.

Best,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1069576: blhc: False positive NONVERBOSE BUILD in src:fim

[Simon Ruderich]

Hi Rafael,

On Sat, Apr 20, 2024 at 09:13:58PM +0200, Rafael Laboissière wrote:
> Dear Maintainer,
>
> blhc triggers a NONVERBOSE BUILD error in src:fim
>
> https://salsa.debian.org/debian/fim/-/jobs/5618524
>
>   [snip]
>   $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS} 
> ${WORKING_DIR}/*.build || [ $? -eq 1 ]
>   338:NONVERBOSE BUILD: CXX  : g++
>   [snip]
>
> blhc is complaining about the output of the upstream configure script,
> which indicates to the user which C++ compiler will be used.

should be fixed in [1].

> The patch attached to this bug report fixes the problem for me.
> Hopefully, it will not introduce false negatives.

Thanks for the patch. I've fixed it slightly differently to
reduce the chance of false negatives.

Best,
Simon

[1] 
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=5d2c33804eade9a6b1463d4cb46d7cac0018274c
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1067691: FTBFS: double free or corruption

[Bernhard Übelacker]

Hello,
I found this one interesting and tried to reproduce it,
and hit this issue quite reliable with an unstable armel chroot,
inside an armhf unstable qemu VM,
or with a Android/LineageOS with real arm CPU.

Unfortunately valgrind is no longer built for armel, and a local armel rebuild
shows issues with latest "-fstack-protector-strong -fstack-clash-protection".

Finally I found this issue leads not to a crash at amd64, but
valgrind uncovers it there reliable [1].

dpkg-buildpackage with valgrind installed uses it automatically.
Therefore the change in [2] might be an improvement?


Increasing the allocation of the input buffer like in [3]
makes the valgrind errors go away.
Unfortunately I don't know what exact size this buffer is expected to have.

Kind regards,
Bernhard




[1]
...
fft const
==1105453== Invalid write of size 4
==1105453==at 0x60BFC25: ??? (in 
/usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100)
==1105453==by 0x4CE1880: av_rdft_calc (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.60.31.102)
==1105453==by 0x11246F: FFTPlanImpl::execute() (spek-fft.cc:38)
==1105453==by 0x110A76: test_const() (test-fft.cc:21)
==1105453==by 0x1105F5: test_fft() (test-fft.cc:77)
==1105453==by 0x10BF5C: main (test.cc:11)
==1105453==  Address 0x11a828c4 is 4 bytes after a block of size 64 alloc'd
==1105453==at 0x4845DA0: memalign (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1105453==by 0x4845F01: posix_memalign (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1105453==by 0x608CC14: av_malloc (in 
/usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100)
==1105453==by 0x1126A0: FFTPlan (spek-fft.h:29)
==1105453==by 0x1126A0: FFTPlanImpl::FFTPlanImpl(int) (spek-fft.cc:27)
==1105453==by 0x112745: FFT::create(int) (spek-fft.cc:24)
==1105453==by 0x1109AE: test_const() (test-fft.cc:13)
==1105453==by 0x1105F5: test_fft() (test-fft.cc:77)
==1105453==by 0x10BF5C: main (test.cc:11)
...


[2]
--- debian/control.orig 2023-01-11 07:25:51.0 +0100
+++ debian/control  2024-04-21 16:30:57.545576734 +0200
@@ -11,3 +11,4 @@ Build-Depends: debhelper-compat (= 13),
libwxgtk3.2-dev,
-   wx-common
+   wx-common,
+   valgrind-if-available
 Standards-Version: 4.6.2


[3]
--- src/spek-fft.h.orig 2023-01-10 05:00:39.0 +0100
+++ src/spek-fft.h  2024-04-21 16:28:07.0 +0200
@@ -28,3 +28,3 @@ public:
 // input data to be aligned by up to 32 bytes (e.g. AVX)
-this->input = (float*) av_malloc(sizeof(float) * input_size);
+this->input = (float*) av_malloc(sizeof(float) * (input_size + 2));
 }

Bug#1069603: [Pkg-openssl-devel] Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert

[Sebastian Andrzej Siewior]

On 2024-04-21 13:42:03 [+0200], Paul Gevers wrote:

> opensslfrom testing3.2.1-3
> libcrypt-smime-perlfrom testing0.28-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of openssl to testing
> [1]. Due to the nature of this issue, I filed this bug report against both
> packages. Can you please investigate the situation and reassign the bug to
> the right package?

The problem is that libcrypt-smime-perl < 0.29 fails with openssl >= 3.2.0. 
This was solved by the Perl team with their 0.29 upload. This and 0.30
didn't migrate to testing and in the meantime we got OpenSSL into
unstable which relies on that fix.
The migration was delayed by the time_t transition.

Could britney be hinted to migrate both at the same time? This should
solve the issue you pointed out.

Sebastian

Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)

[Paul Gevers]

Hi,

On 18-04-2024 10:25 p.m., Paul Gevers wrote:
I'll hopefully do the changes tomorrow. (RL work is a bit busy at the 
moment.)


The test ran. Unfortunately zfs-test-suite-1 failed.

https://ci.debian.net/packages/z/zfs-linux/unstable/amd64/45683824/

4089s Results Summary
4089s PASS   681
4089s FAIL 2
4089s SKIP 3

Seems like we're nearly there.

(I made a tiny mistake in that run, as I had 8GB RAM; I have now lowered 
it to 4GB which will be the setting until further discussion is warranted).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2

[Jeremy Lainé]

Hi Salvatore,

I've finished bisecting and the version that seems to introduce the
breakage is 6.1.83.

I tested the following upstream kernels:

- linux 6.1.80 => OK
- linux 6.1.82 => OK
- linux 6.1.83 => BUG
- linux 6.1.85 => BUG
- linux 6.1.87 => BUG

I looks like 6.1.83 introduced quite a few bluetooth changes, so I don't
know which one caused the breakage:

https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.83

What else can I do to assist?

Cheers,
Jeremy

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: winff: FTBFS on armel: build-dependency not installable: libreoffice-draw-nogui

[Peter B]

On 20/04/2024 21:28, Paul Gevers wrote:

Hi,

On 20-04-2024 3:22 p.m., Lucas Nussbaum wrote:

The following packages have unmet dependencies:
  sbuild-build-depends-main-dummy : Depends: libreoffice-draw-nogui 
but it is not installable

E: Unable to correct problems, you have held broken packages.
apt-get failed.


I recall rene mentioning that parts of lo are expected to not work on 
armel due to java being broken. Probably the best way forward is to 
request binary removal on armel.


Paul


Hi Paul,

Thanks for commenting.  Despite spitting out
   "Warning: failed to launch javaldx - java may not function correctly"

I gather soffice does not actually use Java, for pdf creation.
I hope to fix this by changing the build dependencies.

Cheers,
Peter

Bug#1069598: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

[tmx314]

Package: cifs-utils
Version: 2:7.0-2
Severity: important

Dear Maintainer,

When mounting a samba-share by a Debian Bookworm client, kernel 6.1.0-20-amd64, 
on this client some subdirectories and files within the mounted share are 
missing.
I didn't change the permissions on the server and all the files and directories 
are furthermore existent on the server.
After booting the Client journalctl shows on this client many lines like:
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow 
frame end of buf a18bb84d
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would overflow 
frame end of buf 2b19fed0
.. 

Booting the client with kernel 6.1.0-15-amd64 or 6.1.0-18-amd64 removes the 
error.
Using the mount-option "noserverino" or changing "vers" from default to another 
value has no effect.

Server: Debian Bookworm, Kernel 6.1.0-20-amd64, Samba 2:4.17.12+dfsg-0+deb12u1
# testparm
interfaces = 127.0.0.0/8 192.168.1.0/24
log file = /var/log/samba/log.%m
logging = file
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* 
%n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
preferred master = Yes
server min protocol = SMB2
server role = standalone server
unix password sync = Yes
usershare allow guests = Yes
workgroup = theo
idmap config * : backend = tdb

..
[daten-theo]
create mask = 0660
directory mask = 0770
force create mode = 0020
force directory mode = 0030
force group = theo
force user = theo
path = /daten/daten-theo
valid users = user1 user2 ...
write list = user1 

No errors are found in the server logs.

Client also Debian Bookworm, Kernel 6.1.0-20-amd64, cifs-utils 2:7.0-2
I am writing this message on the involved client and boots it now with the 
Kernel listed below in the System Information to avoid the error.
Same problem is found on a second Debian Bookworm client.
/etc/fstab:

//server/daten-theo /home/theo/daten-theo cifs 
vers=default,_netdev,credentials=/root/smbcredtheo,uid=theo,gid=theo,rw,file_mode=0660,dir_mode=0770,nofail
 0 0 



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

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 cifs-utils depends on:
ii  libc6 2.36-9+deb12u4
ii  libcap-ng00.8.3-1+b3
ii  libgssapi-krb5-2  1.20.1-2+deb12u1
ii  libkeyutils1  1.6.3-2
ii  libkrb5-3 1.20.1-2+deb12u1
ii  libpam0g  1.5.2-6+deb12u1
ii  libtalloc22.4.0-f2
ii  libwbclient0  2:4.17.12+dfsg-0+deb12u1
ii  python3   3.11.2-1+b1

Versions of packages cifs-utils recommends:
pn  keyutils  

Versions of packages cifs-utils suggests:
ii  bash-completion  1:2.11-6
ii  smbclient2:4.17.12+dfsg-0+deb12u1
pn  winbind  

-- no debconf information

Bug#1067006: marked as done (rpc-statd.service: State 'stop-sigterm' timed out. Killing.)

[Harald Dunkel]

Hi Salvatore,

sorry for not sending a reply. I completely forgot this bug report.
Fortunately it appears to be still open.

I ran into this problem again just a few minutes ago on running apt upgrade.
Several services were restarted in parallel, using "needrestart".

journalctl shows:

Apr 21 12:33:56 tweety.afaics.de systemd[1]: Reexecuting requested from client 
PID 1905554 ('systemctl') (unit session-5140.scope)...
Apr 21 12:33:56 tweety.afaics.de systemd[1]: Reexecuting.
Apr 21 12:33:56 tweety.afaics.de systemd[1]: systemd 255.4-1+b1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 
+LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)

Apr 21 12:33:56 tweety.afaics.de systemd[1]: Detected architecture x86-64.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping acpid.service - ACPI 
event daemon...
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping apache2.service - The 
Apache HTTP Server...
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping atd.service - Deferred 
execution scheduler...
Apr 21 12:34:21 tweety.afaics.de systemd[1]: atd.service: Deactivated 
successfully.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopped atd.service - Deferred 
execution scheduler.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Starting atd.service - Deferred 
execution scheduler...
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping autofs.service - 
Automounts filesystems on demand...
Apr 21 12:34:21 tweety.afaics.de avahi-daemon[642]: Got SIGTERM, quitting.
Apr 21 12:34:21 tweety.afaics.de avahi-daemon[642]: Leaving mDNS multicast 
group on interface br0.IPv6 with address 2003:e3:1f0c:1703:8865:8fff:feb7:694d.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping avahi-daemon.service - 
Avahi mDNS/DNS-SD Stack...
Apr 21 12:34:21 tweety.afaics.de avahi-daemon[642]: Leaving mDNS multicast 
group on interface br0.IPv4 with address 10.42.100.150.
Apr 21 12:34:21 tweety.afaics.de avahi-daemon[642]: Leaving mDNS multicast 
group on interface lo.IPv6 with address ::1.
Apr 21 12:34:21 tweety.afaics.de avahi-daemon[642]: Leaving mDNS multicast 
group on interface lo.IPv4 with address 127.0.0.1.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: auth-rpcgss-module.service - 
Kernel Module supporting RPCSEC_GSS was skipped because of an unmet condition 
check (ConditionPathExists=/etc/krb5.keytab).
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping cron.service - Regular 
background program processing daemon...
Apr 21 12:34:21 tweety.afaics.de systemd[1]: Stopping nfs-server.service - NFS 
server and services...
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Deactivated 
successfully.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1027 
(inoticoming) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1031 
(inoticoming) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1035 
(gpg-agent) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1170 
(vncserver) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1171 
(Xtigervnc) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1225 
(xstartup) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1234 
(ssh-agent) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1243 
(xstartup) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1245 
(fvwm3) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1353 
(xterm) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1354 
(xterm) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1355 
(xterm) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1356 
(xterm) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1359 
(FvwmPager) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1360 
(FvwmAuto) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1361 
(FvwmEvent) remains running after unit stopped.
Apr 21 12:34:21 tweety.afaics.de systemd[1]: cron.service: Unit process 1450 
(watch) remains running after unit stopped.
Apr 21 12:34:21 

Bug#1068226: trantor: diff for NMU version 1.5.12+ds-1.1

[Andreas Metzler]

Control: tags 1068226 + patch
Control: tags 1068226 + pending

Dear maintainer,

I've prepared an NMU for trantor (versioned as 1.5.12+ds-1.1) and
uploaded it to DELAYED/00.

kind regards
Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru trantor-1.5.12+ds/debian/changelog trantor-1.5.12+ds/debian/changelog
--- trantor-1.5.12+ds/debian/changelog	2023-09-13 13:45:24.0 +0200
+++ trantor-1.5.12+ds/debian/changelog	2024-04-21 12:04:17.0 +0200
@@ -1,3 +1,12 @@
+trantor (1.5.12+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Pull fix from Ubuntu by Michael Hudson-Doyle:
++ Drop spurious Depends on libssl3 as package is currently built with no
+  TLS provider. Closes: #1068226
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 12:04:17 +0200
+
 trantor (1.5.12+ds-1) unstable; urgency=medium
 
   * New upstream release 1.5.12+ds (Closes: #1042181)
diff -Nru trantor-1.5.12+ds/debian/control trantor-1.5.12+ds/debian/control
--- trantor-1.5.12+ds/debian/control	2023-06-13 14:51:48.0 +0200
+++ trantor-1.5.12+ds/debian/control	2024-04-21 12:04:17.0 +0200
@@ -11,7 +11,7 @@
 
 Package: libtrantor1
 Architecture: any
-Depends: libssl3, libc-ares2, ${misc:Depends}, ${shlibs:Depends}
+Depends: libc-ares2, ${misc:Depends}, ${shlibs:Depends}
 Description: Non-blocking I/O cross-platform TCP network library
  Trantor is a non-blocking I/O cross-platform TCP network library, using C++14.
  Drawing on the design of Muduo Library


signature.asc
Description: PGP signature

Bug#1068008: newer rust needed

[Carsten Schoenert]

Am Wed, Apr 17, 2024 at 09:02:14AM -0400 schrieb Yaroslav Halchenko:
> Also I thought to try to build  deno
> 
> https://github.com/denoland/deno.git
> (ITP - #961337) https://bugs.debian.org/961337 deno
> 
> but it needs 
> 
> ❯ cat rust-toolchain.toml
> [toolchain]
> channel = "1.77.2"
> components = ["rustfmt", "clippy"]
> 
> so we are indeed well behind :-/

Also Thunderbird >= 125.x is depending on a newer rust version in the
archive (equivalent to FF).
Missing a newer rust blocks me from building and adjusting the Debian
packaging of current Thunderbird beta version within experimental. So
please work on a newer rust.

Regards
Carsten

Bug#1069601: daemontools: isolation-machine autopkgtest fails: VM doesn't come up as expected after reboot

[Paul Gevers]

Source: daemontools
Version: 1:0.76-10
X-Debbugs-CC: debian...@bugs.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that (I'll remove it shortly). However, it 
fails, because it seems that after a reboot, the VM doesn't come back in 
a normally expected mode. Can you please investigate the situation and 
fix it? I copied some of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/d/daemontools/testing/amd64/45702934/

 98s autopkgtest [11:07:03]: test daemontools-run-systemd: 
---]

▸ test daemontools-run-systemd: test results
▸ preparing testbed
▸ test bed setup
▾ test run
131s autopkgtest [11:07:36]: test daemontools-run-sysvinit: 
[---

132s Killed
132s autopkgtest [11:07:37]: test process requested reboot with marker 
rebootmark
193s qemu-system-x86_64: terminating on signal 15 from pid 1174882 
(/usr/bin/python3)
193s : failure: timed out waiting for 'login prompt on 
serial console'
193s autopkgtest [11:08:38]: ERROR: testbed failure: unexpected eof from 
the testbed


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068224: deepin-movie-reborn: diff for NMU version 5.10.8-2.1

[Andreas Metzler]

Control: tags 1068224 + patch
Control: tags 1068224 + pending

Dear maintainer,

I've prepared an NMU for deepin-movie-reborn (versioned as 5.10.8-2.1) and
uploaded it to DELAYED/00.

kind regards
Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru deepin-movie-reborn-5.10.8/debian/changelog deepin-movie-reborn-5.10.8/debian/changelog
--- deepin-movie-reborn-5.10.8/debian/changelog	2022-12-01 00:12:34.0 +0100
+++ deepin-movie-reborn-5.10.8/debian/changelog	2024-04-21 13:23:59.0 +0200
@@ -1,3 +1,11 @@
+deepin-movie-reborn (5.10.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change hardcoded dependency to libqt5concurrent5t64 instead of
+libqt5concurrent5. Closes: #1068224
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 13:23:59 +0200
+
 deepin-movie-reborn (5.10.8-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru deepin-movie-reborn-5.10.8/debian/control deepin-movie-reborn-5.10.8/debian/control
--- deepin-movie-reborn-5.10.8/debian/control	2022-11-30 23:22:11.0 +0100
+++ deepin-movie-reborn-5.10.8/debian/control	2024-04-21 13:23:54.0 +0200
@@ -55,7 +55,7 @@
  libgstreamer1.0-0,
  libmpris-qt5-1 (>= 0.1.0.1),
  libpulse0,
- libqt5concurrent5,
+ libqt5concurrent5t64,
  va-driver-all,
  ${libmpv:Depends},
  ${misc:Depends},
@@ -99,7 +99,7 @@
  libgstreamer-plugins-base1.0-0,
  libmpris-qt5-1 (>= 0.1.0.1),
  libpulse0,
- libqt5concurrent5,
+ libqt5concurrent5t64,
  ${libmpv:Depends},
  ${misc:Depends},
  ${shlibs:Depends},


signature.asc
Description: PGP signature

Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert

[Paul Gevers]

Source: openssl, libcrypt-smime-perl
Control: found -1 openssl/3.2.1-3
Control: found -1 libcrypt-smime-perl/0.28-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of openssl the autopkgtest of libcrypt-smime-perl 
fails in testing when that autopkgtest is run with the binary packages 
of openssl from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
opensslfrom testing3.2.1-3
libcrypt-smime-perlfrom testing0.28-1
all others from testingfrom testing

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

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcrypt-smime-perl/45599656/log.gz


 50s not ok 14 - Load the default public key store
 50s=20
 50s #   Failed test 'Load the default public key store'
 50s #   at t/04-taint.t line 257.
 50s # died: Crypt::SMIME#setPublicKeyStore: failed to store the 
public cert at t/04-taint.t line 257.

 50s Failed 2/7 subtests=20


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069605: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

[mt22j]

Package: cifs-utils
Version: 2:7.0-2
Severity: important

Dear Maintainer,

When mounting a samba-share by a Debian Bookworm client, kernel 
6.1.0-20-amd64, on this client some subdirectories and files within the 
mounted share are missing.
I didn't change the permissions on the server and all the files and 
directories are furthermore existent on the server.

After booting the Client journalctl shows on this client many lines like:
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would 
overflow frame end of buf a18bb84d
Apr 16 14:33:08 tmx314 kernel: CIFS: VFS: directory entry name would 
overflow frame end of buf 2b19fed0

..

Booting the client with kernel 6.1.0-15-amd64 or 6.1.0-18-amd64 removes 
the error.
Using the mount-option "noserverino" or changing "vers" from default to 
another value has no effect.


Server: Debian Bookworm, Kernel 6.1.0-20-amd64, Samba 
2:4.17.12+dfsg-0+deb12u1

# testparm
interfaces = 127.0.0.0/8 192.168.1.0/24
log file = /var/log/samba/log.%m
logging = file
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n 
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

passwd program = /usr/bin/passwd %u
preferred master = Yes
server min protocol = SMB2
server role = standalone server
unix password sync = Yes
usershare allow guests = Yes
workgroup = theo
idmap config * : backend = tdb

..
[daten-theo]
create mask = 0660
directory mask = 0770
force create mode = 0020
force directory mode = 0030
force group = theo
force user = theo
path = /daten/daten-theo
valid users = user1 user2 ...
write list = user1

No errors are found in the server logs.

Client also Debian Bookworm, Kernel 6.1.0-20-amd64, cifs-utils 2:7.0-2
I am writing this message on the involved client and boots it now with 
the Kernel listed below in the System Information to avoid the error.

Same problem is found on a second Debian Bookworm client.
/etc/fstab:

//server/daten-theo /home/theo/daten-theo cifs 
vers=default,_netdev,credentials=/root/smbcredtheo,uid=theo,gid=theo,rw,file_mode=0660,dir_mode=0770,nofail 
0 0




-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 cifs-utils depends on:
ii  libc6 2.36-9+deb12u4
ii  libcap-ng00.8.3-1+b3
ii  libgssapi-krb5-2  1.20.1-2+deb12u1
ii  libkeyutils1  1.6.3-2
ii  libkrb5-3 1.20.1-2+deb12u1
ii  libpam0g  1.5.2-6+deb12u1
ii  libtalloc22.4.0-f2
ii  libwbclient0  2:4.17.12+dfsg-0+deb12u1
ii  python3   3.11.2-1+b1

Versions of packages cifs-utils recommends:
pn  keyutils  

Versions of packages cifs-utils suggests:
ii  bash-completion  1:2.11-6
ii  smbclient2:4.17.12+dfsg-0+deb12u1
pn  winbind  

-- no debconf information

Bug#1069607: retroarch is built without optimization

[Adrian Bunk]

Package: retroarch
Version: 1.18.0+dfsg-1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: Jonathan McDowell 

debian/rules:export DEB_CXXFLAGS_MAINT_STRIP=-O2
debian/rules:export DEB_CFLAGS_MAINT_STRIP=-O2

Building without optimization makes binaries
both slower and bigger.

The latter is likely also the root cause of the FTBFS
on m68k and powerpc.

Bug#1068422: possibly caused by python 3.12.3 Re: Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object

[Rebecca N. Palmer]

This bug is not *obviously* known to dask upstream, but their CI is 
failing and I haven't checked why.


It happens only in Python 3.12, not 3.11:
https://ci.debian.net/packages/d/dask/unstable/amd64/45013666/
and still doesn't happen in testing, but does happen in mostly-testing 
with 
src:python3-defaults,src:db5.3,src:keras,src:nodejs,src:openssl,src:python3-stdlib-extensions,src:python3.11,src:python3.12,src:readline,src:udisks2,src:viagee 
from unstable:

https://ci.debian.net/packages/d/dask/testing/amd64/45564690/

This suggests that the trigger may be the upgrade of Python itself 
(3.12.2-1 in testing -> 3.12.3-1 in unstable).


*Possibly* related items from the upstream Python changelog:
https://github.com/python/cpython/issues/101293
https://github.com/python/cpython/issues/117110

Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.

[Paul Gevers]

Hi,

On 21-04-2024 1:59 p.m., Martin-Éric Racine wrote:

That service unit is provided by systemd-timesyncd, which systemd
recommends. Basically, unless your testing environment explicitly
installs another package providing time-daemon, this shouldn't happen,
since systemd would have pulled systemd-timesyncd by default.


In autopkgtest context, recommends are not installed (to avoid issues 
where recommends are (sometimes) not installable). If your test needs 
it, you'll need to Depends on it explicitly in your test stanza.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069608: topplot: missing test-depends on python3-all

[Rebecca N. Palmer]

Source: topplot
Version: 0.2.2+repack-1
Tags: patch
Severity: serious
Justification: blocks testing migration of other packages

topplot tries to run its autopkgtest in all versions of Python (which is 
good), but does not test-depend on all those versions of Python.


This previously worked because numpy depended on them.  However, this 
has now been removed (see #945824), causing topplot's autopkgtests to fail.


Adding python3-all to the Depends in debian/*tests*/control should fix 
this bug, but I have not actually tested this.

Bug#1069612: drm-info: isolation-machine autopkgtest fails: /dev/dri/card0: Permission denied

[Paul Gevers]

Source: drm-info
Version: 2.6.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/d/drm-info/testing/amd64/45706001/

 33s autopkgtest [13:47:33]: test command1: [---
 33s /dev/dri/card0: Permission denied
 33s Failed to retrieve information from /dev/dri/card0
 34s autopkgtest [13:47:34]: test command1: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069613: systemd: Startup fails after apt full-upgrade

[Bud Heal]

Package: systemd
Version: 252.22-1~deb12u1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
A couple of non-Debian packages needed libc > 2.31, so I upgraded this
laptop.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I changed sources.list to point to bullseye, apt-get update, apt-get
upgrade --without-new-pkgs, apt-get full-update. Reboot at each upgrade.
I changed sources.list to point to bookworm, including non-free and
non-free-firmware, apt-get update, apt-get upgrade --without-new-pkgs,
reboot, noted that GLIB (libc) had budged to 2.36 and debian_version was
12.5, so time for apt-get full-upgrade. Things were still working fine, 
but not after another reboot.
   * What was the outcome of this action?
Now startup does not complete to login. After I enter the disk password,
a long list of messages come up as usual and the first error was that
apache could not be started. Later boots add a line, Error ucsi_acpi
USBC000:00 PPM init failed (-110)
I used a Bookworm RC3 disk (DLBD) for triage, and tail var/log/syslog
informs that gnome crashed.
I then did apt-get update, upgrade --without-new-pkgs, full-upgrade on a
laptop (installed from Bookworm RC3 and set aside because I had work to
do) and those steps worked fine.
Now, this HP Omen 6-core has been problematic, or at least difficult, in
the past, but I was able to find its firmware and I think Debian now
includes them.
When time allows, I can compare the config and binary files to see what
is different but that startup goes into an endless loop is peculiar.
   * What outcome did you expect instead?
Obviously, init should proceed to login.


-- Package-specific info:

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+deb12u1
ii  libc6  2.36-9+deb12u4
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4~deb12u2
ii  libfdisk1  2.38.1-5+deb12u1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+deb12u1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.11-1~deb12u2
ii  libsystemd-shared  252.22-1~deb12u1
ii  libsystemd0252.22-1~deb12u1
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+deb12u1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.14.10-1~deb12u1
ii  ntpsec [time-daemon]1.2.2+dfsg1-1+deb12u1

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2+b1
ii  libqrencode4  4.1.1-1
ii  libtss2-esys-3.0.2-0  3.2.1-3
ii  libtss2-mu0   3.2.1-3
ii  libtss2-rc0   3.2.1-3
ii  policykit-1   122-3
ii  polkitd   122-3
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-1~deb12u1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252.22-1~deb12u1
ii  libpam-systemd 252.22-1~deb12u1
ii  udev   252.22-1~deb12u1

-- no debconf information
[EQUIVALENT] /etc/systemd/system/mysql.service -> 
/usr/lib/systemd/system/mysql.service
[EQUIVALENT] /etc/systemd/system/mysqld.service -> 
/usr/lib/systemd/system/mysqld.service
[EXTENDED]   /usr/lib/systemd/system/rc-local.service -> 
/usr/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED]   /usr/lib/systemd/system/systemd-localed.service -> 
/usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf
[EXTENDED]   /usr/lib/systemd/system/user@.service -> 
/usr/lib/systemd/system/user@.service.d/10-login-barrier.conf

5 overridden configuration files found.
==> /var/lib/systemd/deb-systemd-helper-enabled/fstrim.timer.dsh-also <==
/etc/systemd/system/timers.target.wants/fstrim.timer

==> /var/lib/systemd/deb-systemd-helper-enabled/sysstat-collect.timer.dsh-also 
<==
/etc/systemd/system/sysstat.service.wants/sysstat-collect.timer

==> /var/lib/systemd/deb-systemd-helper-enabled/e2scrub_all.timer.dsh-also <==
/etc/systemd/system/timers.target.wants/e2scrub_all.timer

==> /var/lib/systemd/deb-systemd-helper-enabled/mysql.service <==

==> 

Bug#1067084: ruby-sigar: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Praveen Arimbrathodiyil]

On Mon, 18 Mar 2024 09:13:47 +0100 Sebastian Ramacher 
 wrote:

Justification: fails to build from source (but built successfully in the past)
This packaged can be removed once ruby-eye is removed. RM request filed 
for its only reverse dependency ruby-eye.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069596: xscreensaver does not ask password on first key hit

[Tormod Volden]

Thanks for your report. It would be worthwhile to check if this is a
bug that is already fixed in the newer version of xscreensaver 6.08
that is available in Debian unstable. Can you please try installing
the 6.08 version from Debian unstable? If the binaries don't install
as-is, the package can be safely rebuilt without changes on your
Debian stable system. (Hopefully we can get 6.08 into
bookworm-backports later.)

Regards,
Tormod

Bug#1068136: Updating golang-github-golang-protobuf-1-5 to fix FTBFS

[Mathias Gibbens]

On Sat, 2024-04-20 at 22:40 +0800, Shengjing Zhu wrote:
> On Sat, Apr 20, 2024 at 10:28 PM Mathias Gibbens  wrote:
> > 
> > Hi Anthony,
> > 
> >   A few weeks ago you uploaded a new version of golang-google-protobuf
> > to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5
> > v1.5.3 [1,2,3]. This has been blocking the transition of various golang
> > packages from unstable to testing.
> > 
> >   I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds
> > fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1-
> > 5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt`
> > run testing for any build regressions with the newer version yet.
> > 
> 
> This is a known regression in 1.5.3, see
> https://github.com/golang/protobuf/issues/1596#issuecomment-1981208282

  Since that appears to be the only change in v1.5.4, would there be
any concerns with uploading that version to unstable? This breakage is
starting to cause FTBFS bugs to be filed against affected packages,
such as hugo (#1069371).

Mathias


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

Bug#963872: RFP: automx2 - Email client configuration made easy (replaces "automx")

[Jakob Haufe]

(cc'ing Jérôme as he expressed interest)
(cc'ing Juri as he started packaging at [1])

I recently learned about automx2 and would love to see it packaged in
Debian as well.

Does either of you still plan to maintain it? Is there anything I can
help with?

Cheers,
sur5r

[1] https://salsa.debian.org/python-team/packages/automx2

-- 
ceterum censeo microsoftem esse delendam.


pgpZqVwN2NQH8.pgp
Description: OpenPGP digital signature

Bug#1069247: libconfig-model-dpkg-perl: test failures

[Julian Andres Klode]

On Sun, Apr 21, 2024 at 04:32:48PM +0300, Niko Tyni wrote:
> [Copying Julian as the apt maintainer.]
> 
> On Sat, Apr 20, 2024 at 09:02:35PM +0300, Niko Tyni wrote:
> > On Sat, Apr 20, 2024 at 11:09:17AM +0200, Dominique Dumont wrote:
> > > On Thursday, 18 April 2024 19:21:55 CEST you wrote:
> > > > Source: libconfig-model-dpkg-perl
> > > > Version: 3.004
> > > > Severity: serious
> > > > Tags: ftbfs
> > > > Justification: fails to build from source
> > > 
> > > This really looks like a bug with prove:
> > > 
> > > $ perl t/reorder.t 
> > > ok 1 -  test re-ordered list
> > > 1..1
> > 
> > > I can't see what's wrong with the output of reorder test...
> > 
> > Looks like something is injecting apt progress messages to stdout with
> > CR characters hiding it on the terminal but obviously not from `prove`.
> > 
> > $ perl t/reorder.t |od -c
> 
> > 460   f   o   r   m   a   t   i   o   n   .   .   .   0   %  \r
> > 500
> > *
> > 540  \r   o   k   1   -   t   e   s   t   r   e
> > 560   -   o   r   d   e   r   e   d   l   i   s   t  \n   1   .
> > 600   .   1  \n
> 
> These come from apt, via libapt-pkg-perl which I don't think has ever
> filtered them away. The thing that broke this is surely output changes
> in apt 2.9.
> 
> The crucial difference wrt. at least bookworm seems to be that the
> apt messages used to end with a line feed "\n" before the actual TAP
> format started.  Now it only has a carriage return "\r" there. Apparently
> `prove` ignores unknown lines, but now interprets all the apt output to
> be part of the first line that ends with the 'ok 1' part. So that gets
> ignored as well.
> 
> I see the TAP format spec says at
> 
>   https://testanything.org/tap-version-14-specification.html
> 
>   A Harness should normalize line endings by replacing any instances of
>   \r\n or \r in the TAP document with \n.
> 
> so I suppose this might be a normal/wishlist bug in `prove`. In that case,
> please note that it needs to be fixed in libtest-harness-perl first as
> src:perl just bundles an older version of it.
> 
> Not sure if apt should go back to ending its output with a line
> feed. Julian, what do you think?
> -- 
> Niko

This should be fixed in apt git already, just needs an upload,
which is waiting-ish for some more merges
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1069618: rust-process-viewer: Fails to build with rust-gtk4 0.8

[Jeremy Bícha]

Source: rust-process-viewer
Version: 0.5.8-4
Severity: important
Forwarded: https://github.com/GuillaumeGomez/process-viewer/pull/206
Tags: ftbfs

The Debian Rust team will update rust-gtk4 from 0.7 to 0.8 soon.
rust-process-viewer is not yet compatible with rust-gtk4 0.8. I
started on the porting but I don't expect to work on this more.

Thank you,
Jeremy Bícha

Bug#1069619: RM: ruby-sigar -- ROM; rc-buggy, not needed anymore

[Praveen Arimbrathodiyil]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ruby-si...@packages.debian.org
Control: affects -1 + src:ruby-sigar
User: ftp.debian@packages.debian.org
Usertags: remove
Control: block -1 by 1069616
Control: block 1067084 by -1

Affected by rc bug #1067084 (blocks t64 transition), not needed anymore 
(its only reverse dependency already has an RM request).


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052714: firmware-amd-graphics: Missing firmware for AMD Radeon RX 7000 series cards

[Richard]

I'd also like to support this. The current firmware-amd-graphics is getting
close to being a year old. While of course the Stable branch won't get
up-to-date firmware as that's not the point of firmware, I don't see a
reason at least sid or an experimental branch shouldn't be kept more
up-to-date. And I don't really see a reason why that shouldn't be the case
for testing and stable-updates or stable-backports too.

E.g., a Ryzen 7040's iGPU can't be handled by the 06/2023 firmware package,
it will complain that "amdgpu/gc_11_0_1_me" couldn't be loaded. With at
least the 09/2023 firmware that's not an issue anymore.

Greetings,
Richard

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Jeremy Bícha]

Simple patch attached.

Thank you,
Jeremy Bícha
From: Jeremy Bicha 
Date: Sun, 21 Apr 2024 13:37:18 -0400
Subject: [PATCH] Mark no-default-features autopkgtest as flaky

Closes: #1069621
---
 debian/tests/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/control b/debian/tests/control
index e97cdaa..e5008bc 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -18,7 +18,7 @@ Depends:
  librust-futures-lite-1+default-dev,
  librust-try-lock-0.2+default-dev,
  librust-waker-fn-1+default-dev,
-Restrictions: allow-stderr
+Restrictions: allow-stderr, flaky
 
 Test-Command: /usr/share/cargo/bin/cargo-auto-test event-listener 5.3.0
  --all-targets

Bug#1069574: age-old and insecure webkit package

[Dmitry Shachnev]

Hi again Hadmut,

On Sun, Apr 21, 2024 at 08:25:23PM +0300, Hadmut Danisch wrote:
> Hi Dmitry,
>
>
> even their own website
>
> https://wkhtmltopdf.org/status.html
>
> says:
>
>*Do not use wkhtmltopdf with any untrusted HTML* – be sure to
>sanitize any user-supplied HTML/JS, otherwise it can lead to
>complete takeover of the server it is running on! Please consider
>using a Mandatory Access Control system like AppArmor or SELinux,
>see recommended AppArmor policy .
>
> Wouldn't it be more than enough or a reason to throw this out of
> debian/ubuntu, until they fixed this?

First, I am the wrong person to ask about this. I am CCing the wkhtmltopdf
maintainer.

Second, wkhtmltopdf is not a leaf package, there are other packages depending
on it:

  Reverse-Recommends
  ==
  * civicrm-common
  * python3-a38

  Reverse-Depends
  ===
  * odoo-16
  * python3-django-wkhtmltopdf
  * python3-pdfkit

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server

[Mathias Gibbens]

Hi Alexandru,

  I haven't reviewed your package, however:

On Sun, 2024-04-21 at 19:42 +0300, Alexandru Mihail wrote:
> Thanks a lot and have a nice day,
> Alexandru Mihail
> mini-httpd maintainer

  It looks like you've been maintaining this package for a while now.
Have you considered applying to become a Debian Maintainer[1]? That
would allow you to eventually be given upload permissions on the mini-
httpd package, so you wouldn't need to keep filing RFS bugs. :)

  Also, I suspect people might be more hesitant to sponsor packages
after the actions of "Jia Tan" and the xz backdoor. Going through the
process to become a DM can help demonstrate your commitment to good
packaging and the Debian project as a whole. (I'm not in any way trying
to suggest you might be a malicious actor, just that there's recently
been [rightfully] a lot of scrutiny of how easy it can be for someone
to mess with packages shipped by a distribution.)

Mathias

[1] -- https://nm.debian.org/public/newnm


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

Bug#1069624: rapidfuzz: Fails to build on arch: all

[Julian Gilbey]

Hi Jeremy,

On Sun, Apr 21, 2024 at 02:01:26PM -0400, Jeremy Bícha wrote:
> Source: rapidfuzz
> Version: 3.6.2+ds-2
> Severity: serious
> Tags: ftbfs
> 
> The arch: all build for rapidfuzz is failing:
> 
> https://buildd.debian.org/status/package.php?p=rapidfuzz
> 
> If you use sbuild, I believe you can test this with
> sbuild -arch-all --no-arch-any

Thanks for flagging this.  I've only just fixed taskflow, and will be
able to look at rapidfuzz later this week, all being well.  It's
surprising how many issues new packages can throw up when they're
first build on the multiple archs by the buildds!

Best wishes,

   Julian

Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting

[David Bremner]

Control: tag -1 confirmed

Lucas Nussbaum  writes:

> Source: racket
> Version: 8.12+dfsg1-7
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on armel.

Thanks for the report. I don't know why it wasn't triggered previously,
but I can confirm the problem is not architecture specific, and I can
replicate it on amd64 with

CONFIG_ARGS_amd64 := --disable-docs --enable-bc

Rather than being architecture specific it seems related to the
configuration options that happen to only be used for armel at the
moment.

Bug#1066672: httest: diff for NMU version 2.4.23-1.6

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for httest (versioned as 2.4.23-1.6). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru httest-2.4.23/debian/changelog httest-2.4.23/debian/changelog
--- httest-2.4.23/debian/changelog	2023-12-12 10:52:16.0 +0100
+++ httest-2.4.23/debian/changelog	2024-04-21 21:15:11.0 +0200
@@ -1,3 +1,12 @@
+httest (2.4.23-1.6) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Steve Langasek ]
+  * debian/patches: Fix implicit definitions (Closes: #1066672)
+
+ -- Sebastian Ramacher   Sun, 21 Apr 2024 21:15:11 +0200
+
 httest (2.4.23-1.5) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru httest-2.4.23/debian/patches/no-implicit-declarations.patch httest-2.4.23/debian/patches/no-implicit-declarations.patch
--- httest-2.4.23/debian/patches/no-implicit-declarations.patch	1970-01-01 01:00:00.0 +0100
+++ httest-2.4.23/debian/patches/no-implicit-declarations.patch	2024-04-21 21:14:30.0 +0200
@@ -0,0 +1,43 @@
+Description: add missing includes
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066672
+Last-Update: 2024-04-10
+Forwarded: no
+
+Index: httest-2.4.23/src/socks_module.c
+===
+--- httest-2.4.23.orig/src/socks_module.c
 httest-2.4.23/src/socks_module.c
+@@ -25,6 +25,8 @@
+ /
+  * Includes
+  ***/
++#include 
++
+ #include "module.h"
+ #ifndef HAVE_NO_NETINET
+   #include 
+Index: httest-2.4.23/src/annotation_module.c
+===
+--- httest-2.4.23.orig/src/annotation_module.c
 httest-2.4.23/src/annotation_module.c
+@@ -25,6 +25,7 @@
+ /
+  * Includes
+  ***/
++#include 
+ #include "module.h"
+ 
+ /
+Index: httest-2.4.23/src/dbg_module.c
+===
+--- httest-2.4.23.orig/src/dbg_module.c
 httest-2.4.23/src/dbg_module.c
+@@ -24,6 +24,7 @@
+ /
+  * Includes
+  ***/
++#include 
+ #include "store.h"
+ #include "module.h"
+ 
diff -Nru httest-2.4.23/debian/patches/series httest-2.4.23/debian/patches/series
--- httest-2.4.23/debian/patches/series	2023-12-12 10:52:16.0 +0100
+++ httest-2.4.23/debian/patches/series	2024-04-21 21:14:30.0 +0200
@@ -4,3 +4,4 @@
 fix-gcc-10.patch
 autoconf-2.70.patch
 pcre2.patch
+no-implicit-declarations.patch

Bug#1067628: cctools: diff for NMU version 9.9-4.1

[Sebastian Ramacher]

Control: tags 1067628 + patch


Dear maintainer,

I've prepared an NMU for cctools (versioned as 9.9-4.1). The diff
is attached to this message.

Regards.


-- 
Sebastian Ramacher
diff -Nru cctools-9.9/debian/changelog cctools-9.9/debian/changelog
--- cctools-9.9/debian/changelog	2023-12-06 11:26:18.0 +0100
+++ cctools-9.9/debian/changelog	2024-04-21 22:18:03.0 +0200
@@ -1,3 +1,13 @@
+cctools (9.9-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Michael Hudson-Doyle ]
+  * Undefine _FILE_OFFSET_BITS and _TIME_BITS in rmonitor_helper.c so the library's
+interposition of open/open64 still works. (Closes: #1067628)
+
+ -- Sebastian Ramacher   Sun, 21 Apr 2024 22:18:03 +0200
+
 cctools (9.9-4) unstable; urgency=medium
 
   * Fix to build to correct globus configuration, enable broken
diff -Nru cctools-9.9/debian/patches/globus-flags.patch cctools-9.9/debian/patches/globus-flags.patch
--- cctools-9.9/debian/patches/globus-flags.patch	2023-12-06 11:26:18.0 +0100
+++ cctools-9.9/debian/patches/globus-flags.patch	2024-03-20 03:59:10.0 +0100
@@ -15,3 +15,17 @@
  CCTOOLS_GLOBUS_CCFLAGS=${globus_ccflags}
  
  export CCTOOLS_TEST_CCFLAGS=${test_ccflags}
+--- a/resource_monitor/src/rmonitor_helper.c
 b/resource_monitor/src/rmonitor_helper.c
+@@ -13,6 +13,11 @@
+ #define _GNU_SOURCE // Aah!!
+ #endif
+ 
++/* Building with these macros defines interferes with this files attempt to
++   interpose both open and open64 */
++#undef _FILE_OFFSET_BITS
++#undef _TIME_BITS
++
+ #include 
+ #include 
+ #include 

Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)

[John David Anglin]

Updated patch to fix install.

Dave

--
John David Anglin  dave.ang...@bell.net
--- control.save2024-04-21 15:25:15.368645225 +
+++ control 2024-04-21 15:14:58.183856344 +
@@ -18,7 +18,7 @@
libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el 
mipsel mips64el riscv64],
bison,
flex,
-   rustc,
+   rustc [!hppa],
libgirepository1.0-dev,
gir1.2-glib-2.0,
gir1.2-freedesktop,
--- libgstreamer1.0-0.install.save  2024-04-21 16:38:07.810032050 +
+++ libgstreamer1.0-0.install   2024-04-21 16:38:17.922110631 +
@@ -1,5 +1,4 @@
 usr/lib/*/gstreamer-1.0/*.so
 usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner
-usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper
 usr/lib/*/*.so.*
 usr/share/locale
--- rules.save  2024-04-21 15:25:23.96877 +
+++ rules   2024-04-21 16:40:18.347048541 +
@@ -44,6 +44,10 @@
 conf_flags += -Dlibunwind=disabled -Dlibdw=disabled
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH),hppa))
+conf_flags += -Dptp-helper=disabled
+endif
+
 infiles := \
libgstreamer1.0-0.postinst
 
--- libgstreamer1.0-0.postinst.in.save  2024-04-21 19:15:04.053817208 +
+++ libgstreamer1.0-0.postinst.in   2024-04-21 19:15:41.034100581 +
@@ -2,7 +2,7 @@
 
 set -e
 
-if [ "$1" = configure ]; then
+if [ "$1" = configure && test -f 
/usr/lib/@MULTIARCH@/gstreamer1.0/gstreamer-1.0/gst-ptp-helper ]; then
 # If we have setcap is installed, try setting 
cap_net_bind_service,cap_net_admin+ep,
 # which allows us to install our helper binary without the setuid bit.
 if command -v setcap > /dev/null; then

Bug#1059643: RFS: wstroke/2.1-1 [ITP] -- Mouse gesture plugin for Wayfire.

[Daniel Kondor]

Control: tags -1 - moreinfo


Thank you for the review! I've addressed the issues and lintian warnings 
mentioned. Let me know if there are more issues.


Best,

Daniel

Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)

[Jean-Marc]

On Wed, 14 Feb 2024 14:58:16 +0100 Andreas Beckmann  wrote:

Package: gstreamer1.0-plugins-good
Version: 1.23.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,
[...]


Current version in sid are the following ones:

$ apt policy gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly
gstreamer1.0-plugins-good:
 Table de version :
 1.24.2-1 500
500 https://deb.debian.org/debian unstable/main amd64 Packages

gstreamer1.0-plugins-ugly:
 Table de version :
 1.24.2-1+b1 500
500 https://deb.debian.org/debian unstable/main amd64 Packages


The following files are in conflict:

/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
/usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs


Files mentioned here in the bug report are not present in 
gstreamer1.0-plugins-ugly:1.24.2-1+b1 anymore.


Can you confirm I am not wrong and update the bug report accordingly ?


cheers,


Regards,


Andreas


--
Jean-Marc

(*)
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
/usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069574: age-old and insecure webkit package

[Dmitry Shachnev]

Hi Hadmut!

On Sat, Apr 20, 2024 at 09:23:37PM +0300, Hadmut Danisch wrote:
> Package: libqt5webkit5
>
> Version: 5.212.0~alpha4-30
>
>
> Hi,
>
> this was originally a bug report against Ubuntu 24.04 as 2061191, but since
> the package is community maintained and not by Ubuntu, they asked me to
> report it "upstreams".
>
>
> Ubuntu 24.04 beta / Debian bookworm still use libqt5webkit5.
>
> It is not obvious, where it comes from, but the version is still an alpha4,
> and the link in the README seems to suggest, that it still comes from
> https://github.com/annulen/webkit, which redirects to
> https://github.com/qtwebkit/qtwebkit, where the alpha4 tag is over 4 years
> old.
>
> There, the latest README tells:
>
> Code in this repository is obsolete. If you are looking for up-to-date
> QtWebKit use this fork: https://github.com/movableink/webkit
>
> https://github.com/movableink/webkit seems to be still maintained – more or
> less. And calls itself "inofficial mirror"

Unfortunately, movableink/webkit seems to be even less stable or ready than
qtwebkit/qtwebkit. For example, it is known that PyQt5 cannot be built
against it [1], and there are packages in Debian which need it:

  $ reverse-depends python3-pyqt5.qtwebkit
  Reverse-Recommends
  ==
  * linuxcnc-uspace [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
  * python3-ginga

  Reverse-Depends
  ===
  * frescobaldi [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
  * manuskript
  * openshot-qt
  * python3-pyface
  * python3-qgis [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
  * python3-qtpy
  * qutebrowser-qtwebkit
  * yade [amd64 arm64]

> Have a look at
>
> https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/
>
> which calls qtwebkit insecure, poorly maintained, and cites CVEs about
> remote code execution (some of them would have to be fixed in the fork, but
> probably not in the version here in ubuntu).
>
> The problem is, that tools like wkhtmltopdf do use this library and are
> typically used to pull contents from a given URL, i.e. from foreign
> websites.
>
> Processing foreign HTML and Javascript code in conjunction with
> vulnerabilities to remote code execution, this is highly dangerous.

I absolutely agree. Projects like wkhtmltopdf should stop using Qt WebKit
and should be ported to Qt WebEngine or other alternatives [2]. Once they do
that, we will be able to remove Qt WebKit from Debian.

Any help with filing bugs, both upstream and here in Debian, is welcome.

It is also worth noting that our Release Notes explicitly mention [3] that
Qt WebKit is not covered by security support, thus anyone who uses it with
untrusted input data does so on their own risk.

[1]: https://github.com/movableink/webkit/issues/16
[2]: ideally, they should be also ported from Qt 5 to Qt 6
[3]: 
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1069574: age-old and insecure webkit package

[Hadmut Danisch]

Hi Dmitry,


even their own website

https://wkhtmltopdf.org/status.html

says:

   *Do not use wkhtmltopdf with any untrusted HTML* – be sure to
   sanitize any user-supplied HTML/JS, otherwise it can lead to
   complete takeover of the server it is running on! Please consider
   using a Mandatory Access Control system like AppArmor or SELinux,
   see recommended AppArmor policy .

Wouldn't it be more than enough or a reason to throw this out of 
debian/ubuntu, until they fixed this?



regards

Hadmut

Bug#1069622: firejail: isolation-machine autopkgtest fails: firefox doesn't exist in testing

[Paul Gevers]

Source: firejail
Version: 0.9.72-2
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails if the test runs in 
testing; it passes when run in unstable. Can you please investigate the 
situation and fix it? I copied some of the output at the bottom of this 
report. It looks like the test Depends on packages that aren't available 
in testing. thunderbird and transmission-gtk should be temporarily, but 
firefox isn't going to migrate by design.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/f/firejail/45706858/log.gz

616s The following packages have unmet dependencies:
616s  autopkgtest-satdep : Depends: thunderbird but it is not installable
616s   Depends: firefox but it is not installable
616s   Depends: transmission-gtk but it is not 
installable


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069623: ganeti-instance-debootstrap: isolation-machine autopkgtest fails: http://deb.debian.org/debian/dists/jessie doesn't exist

[Paul Gevers]

Source: ganeti-instance-debootstrap
Version: 0.16-8
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/g/ganeti-instance-debootstrap/testing/amd64/45709257/

 27s autopkgtest [17:54:41]: test install-export-import: 
[---

 28s 512+0 records in
 28s 512+0 records out
 28s 536870912 bytes (537 MB, 512 MiB) copied, 0.487683 s, 1.1 GB/s
 28s Installing instance...
 29s Re-reading the partition table failed.: Invalid argument
 29s I: Retrieving InRelease
 29s I: Retrieving Release
 29s E: Failed getting release file 
http://deb.debian.org/debian/dists/jessie/Release
 30s autopkgtest [17:54:44]: test install-export-import: 
---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069624: rapidfuzz: Fails to build on arch: all

[Jeremy Bícha]

Source: rapidfuzz
Version: 3.6.2+ds-2
Severity: serious
Tags: ftbfs

The arch: all build for rapidfuzz is failing:

https://buildd.debian.org/status/package.php?p=rapidfuzz

If you use sbuild, I believe you can test this with
sbuild -arch-all --no-arch-any

Thank you,
Jeremy Bícha