Bug#1054105: jigdo-file: downloads serially with long pauses between (usually small) files

[Shawn Paul Landden]

Package: jigdo-file
Version: 0.8.2-1
Severity: normal
Tags: patch
X-Debbugs-Cc: shawnland...@outlook.com

(from the patch which is included)

jigdo-lite: parallel wget download if xargs is available

Jigdo downloads are significantly slower than iso downloads because there is
a new connection between each file, with a pause. This slow-down is greater
the faster the connection, so wouldn't be that big with a 56kbps connection,
and has increased since this software was developed.

No change if "xargs" from "findutils" is not available.

There is still a pause, yet to be removed, when commiting each batch of
files to the iso9660.

Signed-off-by: Shawn Paul Landden 

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 jigdo-file depends on:
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.37-12
ii  libdb5.35.3.28+dfsg2-1
ii  libgcc-s1   13.2.0-5
ii  libstdc++6  13.2.0-5
ii  wget1.21.3-1+b2
ii  zlib1g  1:1.2.13.dfsg-1

jigdo-file recommends no packages.

jigdo-file suggests no packages.

-- no debconf information

*** 0001-jigdo-lite-parallel-wget-download-if-xargs-is-availa.patch
>From b995741f09b3b8f52d3315b063552ee63e5b5834 Mon Sep 17 00:00:00 2001
From: Shawn Paul Landden 
Date: Mon, 16 Oct 2023 21:19:09 -0700
Subject: [PATCH] jigdo-lite: parallel wget download if xargs is available

Jigdo downloads are significantly slower than iso downloads because there is
a new connection between each file, with a pause. This slow-down is greater
the faster the connection, so wouldn't be that big with a 56kbps connection,
and has increased since this software was developed.

No change if "xargs" from "findutils" is not available.

There is still a pause, yet to be removed, when commiting each batch of
files to the iso9660.

Signed-off-by: Shawn Paul Landden 
---
 debian/control | 1 +
 scripts/jigdo-lite | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index c1bab0e..190aad1 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Standards-Version: 4.1.1
 Package: jigdo-file
 Architecture: any
 Depends: wget, ${shlibs:Depends}, ${misc:Depends}
+Recommends: findutils
 Conflicts: jigdo (<< 0.6.9)
 Homepage: https://www.einval.com/~steve/software/jigdo/
 Description: Download Debian CD/DVD/USB images from any Debian mirror
diff --git a/scripts/jigdo-lite b/scripts/jigdo-lite
index e9e4f2c..1a33814 100755
--- a/scripts/jigdo-lite
+++ b/scripts/jigdo-lite
@@ -71,14 +71,18 @@ strNotEmpty() { test "x$1" != "x"; }
 # Download a file, storing it in the current dir
 fetch() {
   if test "$#" -eq 0; then return 0; fi
-  wget --user-agent="$userAgent" $wgetOpts "$@" || return 1
+  if test -n `command -v xargs`; then
+echo "$@" | xargs -n 1 -P 5 --delimiter="\x20" wget 
--user-agent="$userAgent" $wgetOpts --force-directories 
--directory-prefix="$imageTmp" -- || return 1
+  else
+wget --user-agent="$userAgent" $wgetOpts --force-directories 
--directory-prefix="$imageTmp" -- "$@" || return 1
+  fi
 }
 #__
 
 # Given URLs, fetch them into $imageTmp, then merge them into image
 fetchAndMerge() {
   if test "$#" -eq 0; then return 0; fi
-  fetch --force-directories --directory-prefix="$imageTmp" -- "$@"
+  fetch "$@"
   # Merge into the image
   $jigdoFile $jigdoOpts --no-cache make-image --image="$image" \
 --jigdo="$jigdoF" --template="$template" "$imageTmp"
-- 
2.42.0
>From b995741f09b3b8f52d3315b063552ee63e5b5834 Mon Sep 17 00:00:00 2001
From: Shawn Paul Landden 
Date: Mon, 16 Oct 2023 21:19:09 -0700
Subject: [PATCH] jigdo-lite: parallel wget download if xargs is available

Jigdo downloads are significantly slower than iso downloads because there is
a new connection between each file, with a pause. This slow-down is greater
the faster the connection, so wouldn't be that big with a 56kbps connection,
and has increased since this software was developed.

No change if "xargs" from "findutils" is not available.

There is still a pause, yet to be removed, when commiting each batch of
files to the iso9660.

Signed-off-by: Shawn Paul Landden 
---
 debian/control | 1 +
 scripts/jigdo-lite | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index c1bab0e..190aad1 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Standards-Version: 4.1.1
 Package: jigdo-file
 Architecture: any
 Depends: wget, ${shlibs:Depends}, ${misc:Depends}
+Recommends: findutils
 Conflicts: jigdo (<< 0.6.9)
 Homepage: https://www.einval.com/~steve/software/jigdo/
 Description: Download Debian CD/DVD/USB 

Bug#1054101: export WEBKIT_DISABLE_COMPOSITING_MODE=1;yelp

[肖盛文]

The other way that yelp can start under 2.42.1-1~deb11u1 version is :

export WEBKIT_DISABLE_COMPOSITING_MODE=1;yelp


--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054104: Use hardlinks in /usr/libexec/qemu-binfmt/ instead of symlinks

[Daniel Richard G.]

Package: qemu-user-static
Version: 1:8.1.1+ds-2
Severity: wishlist

I am using qemu-user-static in conjunction with binfmt-support and
Docker/Podman to allow running foreign-arch containers on amd64. This
approach works quite well, once you get past the speed hit.

The main step involved is making the appropriate static interpreter
executable available at the same path location within the container as
on the host system (because the kernel's binfmt support does not
differentiate between the two environments). For example, the aarch64
interpreter lives on the host at

/usr/libexec/qemu-binfmt/aarch64-binfmt-P

so when I create an arm64 container, I need to copy in the interpreter
executable to that same location, so that the kernel can find it
whenever it is asked to run an arm64 binary inside the container.

Now, instead of copying the interpreter into the container, a simpler
approach would be to just bind-mount the host's /usr/libexec/qemu-binfmt/
directory inside the container, at the same location. This not only
keeps the foreign-arch container "pure" (no random amd64 binaries in the
image) but also ensures the interpreter is up-to-date, since no copy is
ever made of it that could become stale.

Unfortunately, this approach is currently not possible, because the
qemu-binfmt/ directory only contains symlinks. (I could copy over the
appropriate /usr/bin/qemu-*-static file and it would work, but that then
defeats the purpose of avoiding copies.) If the directory contained
hardlinks, then it would be amenable to bind-mounting into a different
filesystem root.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#525939: python-sqlalchemy: reflection of tables in remote mssql fails

[Geoff Crompton]

Hi,

I've just checked this on a Debian 11 system, and am no longer able to 
reproduce the error. I agree with Lionel, I think this bug report can safely be 
closed.

Kind regards,
Geoff Crompton
Infrastructure Team Leader

+61 (0) 3 8341 0244
geo...@trinity.unimelb.edu.au
Trinity College | University of Melbourne | 100 Royal Parade, Parkville | 
Victoria 3052 | Australia
CRICOS Provider Code 00709G

-Original Message-
From: Lionel Élie Mamane 
Sent: Tuesday, October 17, 2023 4:24 AM
To: Piotr Ożarowski 
Cc: Geoff Crompton ; 525...@bugs.debian.org
Subject: Re: Bug#525939: python-sqlalchemy: reflection of tables in remote 
mssql fails

[You don't often get email from lio...@mamane.lu. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On Mon, May 18, 2009 at 09:11:29PM +0200, Piotr Ożarowski wrote:
> [Geoff Crompton, 2009-04-28]

>> When trying to autoload a table on a remote mssql server, sqlalchemy
>> crashes.
>> This may be related to http://www.sqlalchemy.org/trac/ticket/1312.

> please check 0.5.4p1-1 (I just uploaded it to unstable). I think this
> new upstream release fixes your problem (ticket 1405 is now closed,
> 1312 is still open, though). I don't have access to mssql, so I cannot
> really check it.

Upstream #1312 has been closed for 0.6, so it is plausible this is has been 
solved in Debian for ages (before oldoldstable)?

Anyway, I cannot reproduce with

python3-sqlalchemy 1.3.22+ds1-1
python3-pymssql 2.2.2-1+b3
libsybdb5 1.3.17+ds-2

note that I use as connection URL:

  'mssql+pymssql://%s:%s@%s/%s'

if I use

  'mssql://%s:%s@%s/%s'

then sqlalchemy tries to use PyODBC, which doesn't seem to be what the original 
bug reporter was using.

Bug#1054102: Auto-Réponse / Auto-Reply: Bug#1054102: Acknowledgement (mirror submission for debian.savoirfairelinux.net)

[File par défaut via RT]

Bonjour,

Votre message a bien été enregistré par notre système de suivi. Votre numéro de 
ticket est le 425398.

Si vous souhaitez envoyer d'autres courriels concernant cette demande, merci 
d'inclure dans le sujet le code [Ticket #425398]), ou bien répondez directement 
à ce courriel. 

Cordialement,
Centre de support Savoir-Faire Linux
supp...@savoirfairelinux.com

--

Greetings,

Your support request has been recorded in our ticket management system, and 
your ticket number is 425398.

If you wish to send additional e-mails concerning your support request, please 
include your ticket number ( [Ticket #425398] ) in the subject line, or reply 
to this e-mail.

Regards,
Savoir-Faire Linux support center
supp...@savoirfairelinux.com
-

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1054102: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054102.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Mirrors Team 

If you wish to submit further information on this problem, please
send it to 1054...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1054102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054102
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#986333: debian-security-support: Match ecosystems with limited support

[Santiago Ruano Rincón]

Control: reopen -1
Control: fixed -1 debian-security-support/1:12+2021.09.30
Control: found -1 debian-security-support/1:11+2023.05.04
Control: found -1 debian-security-support/1:10+2022.08.23

On Sat, 3 Apr 2021 15:32:02 +0200 Sylvain Beucler  wrote:
> Package: debian-security-support
> Severity: normal
> 
> Hi,
> 
> Sometimes, entire ecosystems are affected by Debian support decisions.
> 
> These source package sets comes to mind:
> - node-*
>   
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8
> - golang-*
>   
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
> 
> Currently 'check-support-status' fails to detect individual packages
> affected by these decisions, it only notifies about explicitly
> referenced packages such as 'nodejs'.
> Maybe regex matching would help.
> 
> (debian-security-support is an important tool in the Debian LTS/ELTS
> offering, so I believe we could offer help/time in this area.)
> 
> What do you think?
> 
> Cheers!
> Sylvain
> 
> 

As discussed in #debian-lts, unarchiving & reopening since this bug is
present in bullseye and bookworm: "golang*" installed packages are not
reported.

I am working on fixing this and will propose {old,}oldstable pu.

Cheers,

 -- S



signature.asc
Description: PGP signature

Bug#1054102: mirror submission for debian.savoirfairelinux.net

[Savoir-faire Linux]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.savoirfairelinux.net
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Savoir-faire Linux 
Country: CA Canada
Location: Montreal
Sponsor: Savoir-faire Linux https://savoirfairelinux.com




Trace Url: http://debian.savoirfairelinux.net/debian/project/trace/
Trace Url: 
http://debian.savoirfairelinux.net/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.savoirfairelinux.net/debian/project/trace/debian.savoirfairelinux.net

Bug#1054101: webkit2gtk: No provider of eglCreateImage found. Requires one of: EGL 15, yelp can't start

[肖盛文]

Source: webkit2gtk
Version: 2.42.1-1~deb11u1
Severity: important
X-Debbugs-Cc: atzli...@sina.com

Dear Maintainer,

I use Debian 11.8, after I apt upgrade, yelp can't start.

There are following error infos when I run yelp on console:

atzlinux@atzlinux-ff:~$ export LANG=C;yelp

No provider of eglCreateImage found.  Requires one of:
EGL 15
Aborted

After I downgrade to bullseye 2.40.5-1~deb11u1:

# apt-get install libwebkit2gtk-4.0-37:amd64/bullseye

yelp can start success.

Is this a bug of webkit2gtk new upstream version or Debian package?


Thanks!

-- System Information:
Release:11.8
Codename:   bullseye
Architecture: x86_64

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

Bug#1053089: Login procedure

[VastOne]

After the blank screen at the lxdm login, doing a ctrl alt f1 to tty1 I
login and immediately startx initiates and takes me to my desktop. This is
just information being passed along

-- 
Thank you,

VastOne
V-Ger VSIDO Developer

Bug#1054100: bullseye-pu: package iotop-c/1.23-1

[Boian Bonev]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ioto...@packages.debian.org
Control: affects -1 + src:iotop-c

[ Reason ]
This update fixes 3 bugs in iotop-c:
- the program will busy loop after pressing ESC key, eating 100% on one core
- pseudo graphs in ASCII mode display incorrect/garbage values
- the logic behind showing only IO active processes incorrectly hides active 
ones

All the bugs were reported via IRC or via the upstream tracker and have no 
debian bug ids

[ Impact ]
Each of those 3 bugs severly affects user experience

[ Tests ]
Fixes were verified by manual testing and also confirmed as fixed by the 
reporters

[ Risks ]
Risks are very low - it is a leaf package, fixes are near trivial

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are cherry-picked upstream commits

[ Other info ]
N/A
diff -Nru iotop-c-1.23/debian/changelog iotop-c-1.23/debian/changelog
--- iotop-c-1.23/debian/changelog   2023-01-23 22:56:03.0 +
+++ iotop-c-1.23/debian/changelog   2023-10-17 01:06:47.0 +
@@ -1,3 +1,13 @@
+iotop-c (1.23-1+deb12u1) bookworm; urgency=medium
+
+  * Backport fixes from 1.25
+- Fix ESC makes iotop busy loop
+- Fix the logic in 'only' option
+  * Backport fixes from 1.24
+- Fix ASCII graph problem in R, W & RW modes
+
+ -- Boian Bonev   Tue, 17 Oct 2023 01:06:47 +
+
 iotop-c (1.23-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru iotop-c-1.23/debian/patches/fix-ascii-graph.patch 
iotop-c-1.23/debian/patches/fix-ascii-graph.patch
--- iotop-c-1.23/debian/patches/fix-ascii-graph.patch   1970-01-01 
00:00:00.0 +
+++ iotop-c-1.23/debian/patches/fix-ascii-graph.patch   2023-10-17 
01:06:47.0 +
@@ -0,0 +1,33 @@
+From: Boian Bonev 
+Date: Tue Oct 17 01:23:35 UTC 2023
+Forwarded: 629d80290c34b3a6a2e6f6400d8e277597547c93
+Subject: Fix ASCII graph problem in R, W & RW modes
+
+---
+--- a/src/view_curses.c
 b/src/view_curses.c
+@@ -969,21 +969,21 @@ static inline void view_curses(struct xx
+   
v1=value2scale(s->readhist[j*2],maxvisible);
+   
v2=value2scale(s->readhist[j*2+gi],maxvisible);
+   } else
+-  
v1=value2scale(s->readhist[j*2],maxvisible);
++  
v1=value2scale(s->readhist[j],maxvisible);
+   break;
+   case E_GR_W:
+   if 
(has_unicode&) {
+   
v1=value2scale(s->writehist[j*2],maxvisible);
+   
v2=value2scale(s->writehist[j*2+gi],maxvisible);
+   } else
+-  
v1=value2scale(s->writehist[j*2],maxvisible);
++  
v1=value2scale(s->writehist[j],maxvisible);
+   break;
+   case E_GR_RW:
+   if 
(has_unicode&) {
+   
v1=value2scale(s->readhist[j*2]+s->writehist[j*2],maxvisible);
+   
v2=value2scale(s->readhist[j*2+gi]+s->writehist[j*2+gi],maxvisible);
+   } else
+-  
v1=value2scale(s->readhist[j*2]+s->writehist[j*2],maxvisible);
++  
v1=value2scale(s->readhist[j]+s->writehist[j],maxvisible);
+   break;
+   case E_GR_SW:
+   if 
(has_unicode&) {
diff -Nru iotop-c-1.23/debian/patches/fix-esc-busy-loop.patch 
iotop-c-1.23/debian/patches/fix-esc-busy-loop.patch
--- iotop-c-1.23/debian/patches/fix-esc-busy-loop.patch 1970-01-01 
00:00:00.0 +
+++ iotop-c-1.23/debian/patches/fix-esc-busy-loop.patch 2023-10-17 
01:06:47.0 +
@@ -0,0 +1,24 @@
+From: Boian Bonev 
+Date: Tue Oct 17 01:23:35 UTC 2023
+Forwarded: 4d0ccbbc62237b7b48764244461b5d47a1befb67
+Subject: Fix busy looping after ESC key
+
+---
+--- a/src/view_curses.c
 

Bug#1054099: helvum: Needs update for rust-pipewire 0.7

[Jeremy Bícha]

Source: helvum
Version: 0.4.0-4
Severity: serious
Tags: ftbfs

I just uploaded rust-pipewire 0.7 to Unstable. You will need to update
the Build-Depends version in helvum's debian/control to match and drop
the relax-deps patch.

Optionally, you may want to also update helvum to the latest 0.5.1 release.

If you do, I suggest adding Build-Depends: librust-libadwaita-0.5+v1-3-dev

(I made those changes in Ubuntu 23.10 and helvum 0.5.1 seems to work ok.)

Thank you,
Jeremy Bícha

Bug#1054022: libncursesw6: broken in GNU Screen

[Thomas Dickey]

On Mon, Oct 16, 2023 at 06:36:40PM +0200, Sven Joachim wrote:
> On 2023-10-16 04:36 +0200, Vincent Lefevre wrote:
> 
> > Package: libncursesw6
> > Version: 6.4+20231007-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > With libncursesw6 6.4+20231007-1, I get the following issue:
> >
> > $ screen -dRR mutt /usr/bin/mutt
> > [screen is terminating]
> >
> > after a few seconds (or immediately "[screen is terminating]" when
> > I hit a key). When rebuilding Mutt with debug support, this shows
> > that Mutt is actually running, but with no output, and I don't know
> > why it terminates.
> 
> The strace output you sent gives a hint.
> 
> > 659013 write(2, "Error opening terminal: screen.xterm-256color.\n", 47) = 47
> 
> This message is coming from ncurses' initscr() function, which
> terminates the program if it cannot setup the terminal.
> 
> > Downgrading the ncurses packages to 6.4+20230625-2 makes this problem
> > disappear.
> 
> Since I was able to reproduce the problem, I bisected it and found the
> following change as the culprit:
> 
> ,
> | 20231001
> | + modify setupterm to provide for using ANSI cursor-position report (in
> |   user6/user7 terminfo capabilities) to obtain screensize if neither
> |   environment variables or ioctl is used.  The ncurses test-program
> |   with options "-E -T" demonstrates this feature.
> `
> 
> Reverting ncurses/tinfo/lib_setup.c to the 20230923 patchlevel made the
> problem disappear.  I'll leave it to Thomas to work out the details.

I suppose it's timing.

I was unable to reproduce it if any tracing (ncurses or strace) was active.
Without that - once or twice out of a few dozen tries, screen exited without
any message.

I'm making the feature optional for now.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

[Ole Peder Brandtzæg]

On Mon, Oct 16, 2023 at 09:25:01AM +0200, gregor herrmann wrote:
> This should probably be named sdview, as per
> https://perl-team.pages.debian.net/policy.html#Package_Naming_Policy

Ah, indeed, thanks; will retitle.

> I've also thought about packing it after reading about it :)

=)

> Indeed!
> Please check out
> https://wiki.debian.org/Teams/DebianPerlGroup/Welcome
> as a starter

Great, looking at it now. (Side note: the «Create an account on Salsa»
link points to https://signup.salsa.debian.org/, which as far as I can
tell is for team creation; https://salsa.debian.org/users/sign_up seems
to take me to the right place.)

-- 
Ole Peder Brandtzæg | En KLST/ITK-hybrid
I have been asked to tell you
that your cries of anguish are keeping the whole neighborhood awake.

Bug#1054098: base-passwd: Fix non-linux build

[Samuel Thibault]

Package: base-passwd
Version: 3.6.2~0
Severity: important
Tags: patch

Hello,

I tried to build base-passwd on hurd-amd64, but this change

  Make it possible to configure whether to use SELinux or not.

broke the non-Linux builds. Here is a patch to fix this.

Samuel

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

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

Versions of packages base-passwd depends on:
ii  libc6  2.37-12
ii  libdebconfclient0  0.271
ii  libselinux13.5-1

Versions of packages base-passwd recommends:
ii  cdebconf [debconf-2.0]  0.271
ii  debconf [debconf-2.0]   1.5.82

base-passwd suggests no packages.

-- debconf information excluded

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules b/debian/rules
index b93e0ad..77c1849 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,11 +5,19 @@
 export DEB_BUILD_MAINT_OPTIONS := hardening=+all
 export DEB_CFLAGS_MAINT_APPEND := -Wall
 
+CONFIGURE =
+
 ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
-override_dh_auto_configure:
-   dh_auto_configure -- --disable-docs
+CONFIGURE += --disable-docs
+endif
+
+ifneq ($(DEB_BUILD_ARCH_OS),linux)
+CONFIGURE += --disable-selinux
 endif
 
+override_dh_auto_configure:
+   dh_auto_configure -- $(CONFIGURE)
+
 execute_before_dh_installdebconf:
touch debian/base-passwd.substvars
mv debian/base-passwd.substvars debian/base-passwd.substvars.real

Bug#1054097: ITP: libparse-man-perl -- Perl library for parsing nroff-formatted manpages

[Ole Peder Brandtzæg]

Package: wnpp
Severity: wishlist
Owner: Andrius Merkys 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libparse-man-perl
  Version : 0.03
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/dist/Parse-Man
* License : Perl 5
  Programming Lang: Perl
  Description : Perl library for parsing nroff-formatted manpages

Parse::Man, an abstract subclass of Parser::MGC, recognises nroff
grammar from a file or string value. It invokes methods when various
nroff directives are encountered. It is intended that this class be used
as a base class, with methods provided to handle the various directives
and formatting options. Typically a subclass will store intermediate
results in a data structure, building it as directed by these method
invocations.

This is a dependency of sdview/libapp-sdview-perl (see #1054001);
Andrius expressed interest in having Parse::Man in Debian and offered to
package it, hence I've marked him as the owner of this bug.

All the best,
Ole

Bug#987619: ITP: golang-github-dgryski-go-rendezvous -- Go implementation of rendezvous hashing

[Mathias Gibbens]

  I've just bumped into this package being a dependency of updating
another golang library, and since it's so simple I've gone ahead with
the packaging and uploaded to the NEW queue.

Mathias


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

Bug#1018865: pug-cli

[Matthias Geiger]

This [0] seems like a maintained fork of pug-cli.

[0] https://github.com/tokilabs/pug3-cli

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1030835: Current status

[Jelmer Vernooij]

Current status:

in NEW:
librust-imperative-dev
librust-libcst-dev

Need to upload:
librust-tikv-jemalloc-sys-dev
librust-tikv-jemallocator-dev

Need to update:
thiserror
thiserror-impl

Cheers,

Jelmer

Bug#1054096: bookworm-pu: package llvm-toolchain-16/16.0.6-15~deb12u1

[Andres Salomon]

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

Here's the update to stable for clang-16, like we recently did for 
oldstable.


[ Reason ]

Chromium 118 wouldn't build on clang-13, so we added clang-16 to 
oldstable (#1053761). In order to be consistent across distributions 
(and also allowing us to drop a bunch of clang-14 & clang-15 workaround 
patches from chromium), we should add clang-16 to stable as well.


[ Impact ]

There's no impact for users, as packages in stable must explicitly 
choose to build against clang-16.


[ Tests ]

Chromium 118.0.5993.70 succeeded in building and running on bookworm 
with the clang-16 packages from llvm-toolchain-16_16.0.6-15~deb12u1.


[ Risks ]

Low/no risk. Clang-16 is not currently in stable.

On oldstable, it built for all archs except mipsel 
(https://buildd.debian.org/status/package.php?p=llvm-toolchain-16=bullseye), 
so I'm not anticipating any other architecture build issues on stable.


[ Checklist ]

 [x] *all* changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [x] attach debdiff against the package in (old)stable
 [x] the issue is verified as fixed in unstable

[ Changes ]

This is the diff against llvm-toolchain-16_16.0.6-15 in trixie, since 
llvm-toolchain-16 isn't currently in bookworm:


diff -urN a/llvm-toolchain-16-16.0.6/debian/changelog 
b/llvm-toolchain-16-16.0.6/debian/changelog
--- a/llvm-toolchain-16-16.0.6/debian/changelog	2023-09-11 
13:40:42.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/changelog	2023-10-16 
13:14:10.0 +

@@ -1,3 +1,11 @@
+llvm-toolchain-16 (1:16.0.6-15~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+  * Change build-dep from sid's llvm-spirv-16 to bookworm's 
llvm-spirv-14.

+
+ -- Andres Salomon   Mon, 16 Oct 2023 13:14:10 
+

+
llvm-toolchain-16 (1:16.0.6-15) unstable; urgency=medium

  * Second attempt to refresh D158066.patch (Closes: #1049362)
diff -urN a/llvm-toolchain-16-16.0.6/debian/control 
b/llvm-toolchain-16-16.0.6/debian/control
--- a/llvm-toolchain-16-16.0.6/debian/control	2023-09-10 
06:14:34.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control	2023-10-16 
13:14:10.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv-14 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,
diff -urN a/llvm-toolchain-16-16.0.6/debian/control.in 
b/llvm-toolchain-16-16.0.6/debian/control.in
--- a/llvm-toolchain-16-16.0.6/debian/control.in	2023-09-10 
06:14:36.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control.in	2023-10-16 
13:14:10.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv-14 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,



[ Other info ]

Bug#1036277: Ship keama - The KEA Migration Assistant

[Santiago Ruano Rincón]

El 13/09/23 a las 01:25, Athos Ribeiro escribió:
> On Mon, Sep 11, 2023 at 03:35:37PM +0530, Santiago Ruano Rincón wrote:
> > 
> > Do you think it would be possible to add an autopkgtest for keama?
> > 
> 
> Hi Santiago!
> 
> Thanks for having a look at this :)
> 
> I added an autopkgtest to run some upstream provided checks and also
> changed d/rules to run the same checks during the package build.
> 
> I needed to perform some changes to ensure the tests will make the build
> process halt on failures and removed one specific test which was
> performing a DNS query.
> 
> Let me know your thoughts on this.
> 
> Thanks again!

Oi Athos,

isc-dhcp is FTBFS on s390x, and I think it is keama-related.

The relevant part of a (giveback) build log:

[snip]
cat /tmp/keama-test-errors
configdata4.in4 doesn't provide expected output
test -f /tmp/keama-test-errors
test ! -s /tmp/keama-test-errors
make[1]: *** [debian/rules:83: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:42: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2
[snip]

Full log:
https://buildd.debian.org/status/fetch.php?pkg=isc-dhcp=s390x=4.4.3-P1-3=1694824585=0

Do you have any idea why?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1053820: fixed in tomcat9 9.0.43-2~deb11u8

[Markus Koschany]

Am Dienstag, dem 17.10.2023 um 08:00 +1100 schrieb Sam Lander:
> Hi Emmanuel
> Last night, I re-enabled HTTP2 with the new (9.0.43-2~deb11u8) build.
> Unfortunately, it did not fix my problem.
> I am going to rummage with tcpdump and a purpose-installed debian VM to
> investigate further. 
> Hopefully I can either track the problem down myself (not very likely), or at
> least offer you a better quality bug report.
> 

Hello Sam,

there was another issue that we only found today. HTTP2 should work as expected
in version 9.0.43-2~deb11u9 again. It will be released shortly.

Regards,

Markus












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

Bug#1054095: ITP: golang-github-google-safetext -- Secure, syntax-aware libraries ensuring safer data formatting.

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-google-safetext
  Version : 0.0~git20230106.7156a76-1
  Upstream Author : Google
* URL : https://github.com/google/safetext
* License : Apache-2.0
  Programming Lang: Go
  Description : Secure, syntax-aware libraries ensuring safer data 
formatting.

 Libraries for producing formats such as YAML, mitigating injection
 vulnerabilities prevalent in syntax-unaware libraries like text/template
 and sprintf.

Bug#975359: RFP darkreader

[Matthias Geiger]

Control: block -1 by 877977, 879665, 922419

I created https://wiki.debian.org/Javascript/Nodejs/Tasks/dark-reader to 
keep track of the dependencies. Seems like there is still a chunk missing.


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053820: closed by Debian FTP Masters (reply to Emmanuel Bourg ) (Bug#1053820: fixed in tomcat9 9.0.43-2~deb11u8)

[Sam Lander]

Hi Emmanuel
Last night, I re-enabled HTTP2 with the new (9.0.43-2~deb11u8) build.
Unfortunately, it did not fix my problem.
I am going to rummage with tcpdump and a purpose-installed debian VM to
investigate further.
Hopefully I can either track the problem down myself (not very likely), or
at least offer you a better quality bug report.



On Mon, 16 Oct 2023 at 10:51, Sam Lander  wrote:

>
>
> -- Forwarded message -
> From: Debian Bug Tracking System 
> Date: Sun, 15 Oct 2023 at 23:51
> Subject: Bug#1053820 closed by Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> (reply to Emmanuel Bourg <
> ebo...@apache.org>) (Bug#1053820: fixed in tomcat9 9.0.43-2~deb11u8)
> To: Sam Lander 
>
>
> This is an automatic notification regarding your Bug report
> which was filed against the libtomcat9-java package:
>
> #1053820: libtomcat9-java: ERR_HTTP2_PROTOCOL_ERROR in browsers after
> upgrade 9.0.43-2~deb11u7 over u6
>
> It has been closed by Debian FTP Masters 
> (reply to Emmanuel Bourg ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> (reply to Emmanuel Bourg <
> ebo...@apache.org>) by
> replying to this email.
>
>
> --
> 1053820: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053820
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1053820-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 15 Oct 2023 12:47:25 +
> Subject: Bug#1053820: fixed in tomcat9 9.0.43-2~deb11u8
> Source: tomcat9
> Source-Version: 9.0.43-2~deb11u8
> Done: Emmanuel Bourg 
>
> We believe that the bug you reported is fixed in the latest version of
> tomcat9, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1053...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Emmanuel Bourg  (supplier of updated tomcat9 package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Thu, 12 Oct 2023 17:32:21 +0200
> Source: tomcat9
> Architecture: source
> Version: 9.0.43-2~deb11u8
> Distribution: bullseye-security
> Urgency: high
> Maintainer: Debian Java Maintainers <
> pkg-java-maintain...@lists.alioth.debian.org>
> Changed-By: Emmanuel Bourg 
> Closes: 1053820
> Changes:
>  tomcat9 (9.0.43-2~deb11u8) bullseye-security; urgency=high
>  .
>* Fixed the HTTP/2 overhead protection triggered on data frames.
>  (Closes: #1053820
> Checksums-Sha1:
>  21c4c651b718b1c50136aa05a5156f1a75dbc9c5 2906 tomcat9_9.0.43-2~deb11u8.dsc
>  5f703f84f09b2c86ed304929671c1daae78043de 56720
> tomcat9_9.0.43-2~deb11u8.debian.tar.xz
>  be48ce5a115787000c58f9c28af980446ebe44d0 12156
> tomcat9_9.0.43-2~deb11u8_source.buildinfo
> Checksums-Sha256:
>  046e5f28d4a9722132d59ac5954de69f94f9833f919df745b1ceefb13079e8d5 2906
> tomcat9_9.0.43-2~deb11u8.dsc
>  f85edc77eb8e5e816a926c9ac80f666382e7574290868ea321526a570667cc2c 56720
> tomcat9_9.0.43-2~deb11u8.debian.tar.xz
>  a252f14c178f86754f387e48ccea8f45aa527bca941c3fcd55215cf770808c7a 12156
> tomcat9_9.0.43-2~deb11u8_source.buildinfo
> Files:
>  6f79c8ab4b2cc2c0473d51c18fa75768 2906 java optional
> tomcat9_9.0.43-2~deb11u8.dsc
>  ee10311fa63eb9fa1ac9c613d46b0f13 56720 java optional
> tomcat9_9.0.43-2~deb11u8.debian.tar.xz
>  bcb2b809f03c62b09a60d659f1aee53f 12156 java optional
> tomcat9_9.0.43-2~deb11u8_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmUoM9dfFIAALgAo
> aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
> RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp
> YW4ub3JnAAoJENmtFLlRO1HkqrcQAMxtrdP7vSR0qXnQkAUjHbMb9zMlmwSzfC+M
> D8GQNXF3i7tJZRA3Op7/nAI0eemTLCmPrDGwwZUsaGeCKtU3SqzDD70FcDZANf60
> yS8Pu0TfmOeTisGodwc0zjWLlg/OxSHLL8oPDExj9RDdDeNkArwZ+VQ0OIDD5ZEh
> PTl6hKo7bwYnfzo/xuEZwXJuNYFIJtk11ea3uvhsfEQw3jEZkb9cFeJ9RukkZsi5
> BPJ4xcQs48ca13vtkxc4g/bNORtye1GL3oeA9HTCD7Gm+st4svI1YyBbuxnsg5KM
> 5pChx7k5HeL6dX9F9OE5pd/tJdWGapyyo9xiDUk5gJlgxUOImT2eij8tyBbfpniV
> L8ANb+6QjQq7btf/yVUu6IsP36PvnLMspdQq7zkneQp28Fcvlwmhw79iZ8IvuDdz
> 2fGpEsZRCpSxXadPAQfx/7XXuzU/rWVTlRt+JB965vYLaZOvdQ0/HyW4RlNm9tOd
> PRoqsJA5MA59PtYP+VUN/Ut4YmNkBFf4IBwYughbLuCSnAJFvhOwh9XnXGDylopp
> XvK46BpO+KSAJ71rGa8jxZJ0sKXuJZrTUAX/YsyvvaQVY7802gCrr3cW2FlxWcyT
> IhcdaCc7IwmJw20HxwChzGJ+9uWR5f927/PK9vQeCtuXHaOb3pqD2gi8HYRI0Edu
> 

Bug#1018865: RFP libredirect

[Matthias Geiger]

Control: block 1018865 by 877977


libredirect seems to only build-depend on web-ext and pug-cli.

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053993: RFP: emacs-eask -- CLI for building, running, testing, and managing your Emacs Lisp dependencies

[Sean Whitton]

Hello,

On Mon 16 Oct 2023 at 07:46pm +02, Martin wrote:

> Quoting Sean Whitton :
>> Typically we try to patch out the need for build-deps like this.  Have
>> you tried to do that?
>
> Thanks for the suggestion, I'll do that!
>
> I did that for the current version of the package (which uses cask, not
> eask). And I can probably keep it that way. I wonder, if that is the
> right direction for the future, in case more and more packages use such
> build tools? But maybe this bug is not the right place to discuss it.

Typically these things come in and out of fashion quite fast.  If you
find a package where it looks like stripping it out will be a lot of
labour, let's discuss.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1054094: msktutil: let dh_installsystemd choose the location of units

[Helmut Grohne]

Source: msktutil
Version: 1.2.1-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. msktutil is involved, because it installs a
systemd unit. Rather than hard code /usr now, I recommend installing the
units using dh_installsystemd such that backports to bookworm will
automatically revert back to the old location. I'm attaching a patch for
your convenience.

Helmut
diff -Nru msktutil-1.2.1/debian/changelog msktutil-1.2.1/debian/changelog
--- msktutil-1.2.1/debian/changelog 2023-10-01 20:08:14.0 +0200
+++ msktutil-1.2.1/debian/changelog 2023-10-16 19:45:04.0 +0200
@@ -1,3 +1,10 @@
+msktutil (1.2.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_installsystemd choose the location of units. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 19:45:04 +0200
+
 msktutil (1.2.1-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru msktutil-1.2.1/debian/msktutil-auto-update.service 
msktutil-1.2.1/debian/msktutil-auto-update.service
--- msktutil-1.2.1/debian/msktutil-auto-update.service  2023-10-01 
20:08:14.0 +0200
+++ msktutil-1.2.1/debian/msktutil-auto-update.service  1970-01-01 
01:00:00.0 +0100
@@ -1,8 +0,0 @@
-[Unit]
-Description=Run msktutil-auto-update if configured in /etc/default/msktutil
-Documentation=man:msktutil(8)
-
-[Service]
-EnvironmentFile=/etc/default/msktutil
-ExecCondition=/bin/sh -a -c "[ \"${AUTOUPDATE_ENABLED}\" = \"true\" ]"
-ExecStart=/usr/sbin/msktutil --auto-update $AUTOUPDATE_OPTIONS
diff -Nru msktutil-1.2.1/debian/msktutil-auto-update.timer 
msktutil-1.2.1/debian/msktutil-auto-update.timer
--- msktutil-1.2.1/debian/msktutil-auto-update.timer2023-10-01 
20:08:14.0 +0200
+++ msktutil-1.2.1/debian/msktutil-auto-update.timer1970-01-01 
01:00:00.0 +0100
@@ -1,10 +0,0 @@
-[Unit]
-Description=Run msktutil-auto-update service daily
-
-[Timer]
-OnCalendar=Mon..Sun *-*-* 06:25:00
-Persistent=true
-Unit=msktutil-auto-update.service
-
-[Install]
-WantedBy=timers.target
diff -Nru msktutil-1.2.1/debian/msktutil.msktutil-auto-update.service 
msktutil-1.2.1/debian/msktutil.msktutil-auto-update.service
--- msktutil-1.2.1/debian/msktutil.msktutil-auto-update.service 1970-01-01 
01:00:00.0 +0100
+++ msktutil-1.2.1/debian/msktutil.msktutil-auto-update.service 2023-10-01 
20:08:14.0 +0200
@@ -0,0 +1,8 @@
+[Unit]
+Description=Run msktutil-auto-update if configured in /etc/default/msktutil
+Documentation=man:msktutil(8)
+
+[Service]
+EnvironmentFile=/etc/default/msktutil
+ExecCondition=/bin/sh -a -c "[ \"${AUTOUPDATE_ENABLED}\" = \"true\" ]"
+ExecStart=/usr/sbin/msktutil --auto-update $AUTOUPDATE_OPTIONS
diff -Nru msktutil-1.2.1/debian/msktutil.msktutil-auto-update.timer 
msktutil-1.2.1/debian/msktutil.msktutil-auto-update.timer
--- msktutil-1.2.1/debian/msktutil.msktutil-auto-update.timer   1970-01-01 
01:00:00.0 +0100
+++ msktutil-1.2.1/debian/msktutil.msktutil-auto-update.timer   2023-10-01 
20:08:14.0 +0200
@@ -0,0 +1,10 @@
+[Unit]
+Description=Run msktutil-auto-update service daily
+
+[Timer]
+OnCalendar=Mon..Sun *-*-* 06:25:00
+Persistent=true
+Unit=msktutil-auto-update.service
+
+[Install]
+WantedBy=timers.target
diff -Nru msktutil-1.2.1/debian/rules msktutil-1.2.1/debian/rules
--- msktutil-1.2.1/debian/rules 2023-10-01 20:08:14.0 +0200
+++ msktutil-1.2.1/debian/rules 2023-10-16 19:45:03.0 +0200
@@ -7,16 +7,5 @@
 %:
dh $@
 
-override_dh_auto_install:
-   install -d debian/msktutil/lib/systemd/system
-   install -m 644 \
-debian/msktutil-auto-update.service \
-debian/msktutil/lib/systemd/system/msktutil-auto-update.service
-   install -m 644 \
-debian/msktutil-auto-update.timer \
-debian/msktutil/lib/systemd/system/msktutil-auto-update.timer
-   dh_auto_install
-
 override_dh_installsystemd:
-   dh_installsystemd msktutil-auto-update.service \
-   msktutil-auto-update.timer
+   dh_installsystemd --name msktutil-auto-update

Bug#1054093: monit: let dh_installsystemd choose the location of units

[Helmut Grohne]

Source: monit
Version: 1:5.33.0-2
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. monit is affected, because it installs a systemd
unit. Rather than just moving it to /usr, I recommend using
dh_installsystemd, because it will automatically revert back to the old
location for bookworm-backports. Due to the use of symbolic links,
debdiff cannot represent the patch:

sed -i -e /systemd/d debian/monit.install
ln -s ../system/startup/monit.service debian/monit.service

Helmut

Bug#1054092: atop will ship systemd units twice when dh_installsystemd installs units to /usr

[Helmut Grohne]

Source: atop
Version: 2.9.0-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, atop will install
the atop.service unit twice. Once to /lib/systemd/system via
debian/atop.install and once to /usr/lib/systemd/system via
dh_installsystemd. Doing so is a policy violation. I'm attaching a patch
that makes atop install all of its units using debhelper and thus choose
a backports-safe location that does not violate policy. I note that the
sleep hook is left as is, so more work is needed for atop down the road,
but this piece is a bit urgent, because it will become an RC bug once I
upload debhelper.

Helmut
diff -Nru atop-2.9.0/debian/atop.install atop-2.9.0/debian/atop.install
--- atop-2.9.0/debian/atop.install  2023-07-01 16:37:19.0 +0200
+++ atop-2.9.0/debian/atop.install  2023-10-16 20:31:22.0 +0200
@@ -1,3 +1 @@
 debian/atop.wrapper usr/share/atop
-debian/atop.service /lib/systemd/system
-debian/atopacct.service /lib/systemd/system
diff -Nru atop-2.9.0/debian/changelog atop-2.9.0/debian/changelog
--- atop-2.9.0/debian/changelog 2023-07-01 16:37:19.0 +0200
+++ atop-2.9.0/debian/changelog 2023-10-16 20:32:18.0 +0200
@@ -1,3 +1,11 @@
+atop (2.9.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install units only once when dh_installsystemd changes unit location.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 20:32:18 +0200
+
 atop (2.9.0-1) unstable; urgency=medium
 
   * new upstream version 2.9.0
diff -Nru atop-2.9.0/debian/rules atop-2.9.0/debian/rules
--- atop-2.9.0/debian/rules 2023-07-01 16:37:19.0 +0200
+++ atop-2.9.0/debian/rules 2023-10-16 20:32:18.0 +0200
@@ -7,7 +7,7 @@
 
 override_dh_auto_clean:
dh_auto_clean
-   rm -f debian/atop.service debian/atop.default debian/atopacct.service 
debian/atop.init debian/atopacct.init
+   rm -f debian/atop.service debian/atop.default 
debian/atop.atopacct.service debian/atop.init debian/atopacct.init 
debian/atop.atop-rotate.timer debian/atop.atop-rotate.service
rm -f atop atopsar
 
 override_dh_installinit:
@@ -18,13 +18,18 @@
dh_auto_install
make sysvinstall DESTDIR=$(shell pwd)/debian/atop
make install DESTDIR=$(shell pwd)/debian/atop
+   mv debian/atop/lib/systemd/system/atop-rotate.timer 
debian/atop.atop-rotate.timer
+   mv debian/atop/lib/systemd/system/atop-rotate.service 
debian/atop.atop-rotate.service
+   rmdir debian/atop/lib/systemd/system
cp atop.default debian/atop.default
cp atop.service debian/atop.service
cp atop.default debian/atop.default
-   cp atopacct.service debian/atopacct.service
+   cp atopacct.service debian/atop.atopacct.service
cp atop.init debian/atop.init
cp atopacct.init debian/atopacct.init
 
 override_dh_installsystemd:
-   dh_installsystemd --no-enable --no-start atop-rotate.service
-   dh_installsystemd atop-rotate.timer atop.service atopacct.service
+   dh_installsystemd --name atop-rotate atop-rotate.timer
+   dh_installsystemd --name atop-rotate --no-enable --no-start 
atop-rotate.service
+   dh_installsystemd --name atopacct
+   dh_installsystemd atop.service

Bug#1054091: redis: installs systemd units twice once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: redis
Version: 5:7.0.13-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, redis installs some
units twice. In addition to dh_installsystemd installing them to
/usr/lib/systemd/system, it also installs them to /lib/systemd/system
via currently redundant lines in debian/*.install. Doing so will be a
policy violation, so when I upload that debhelper change, redis will
become RC buggy. I'm attaching a patch for your convenience.

Helmut
diff -Nru redis-7.0.13/debian/changelog redis-7.0.13/debian/changelog
--- redis-7.0.13/debian/changelog   2023-09-08 23:04:13.0 +0200
+++ redis-7.0.13/debian/changelog   2023-10-16 20:56:13.0 +0200
@@ -1,3 +1,10 @@
+redis (5:7.0.13-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units only once. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 20:56:13 +0200
+
 redis (5:7.0.13-1) unstable; urgency=high
 
   * New upstream security release:
diff -Nru redis-7.0.13/debian/redis-sentinel.install 
redis-7.0.13/debian/redis-sentinel.install
--- redis-7.0.13/debian/redis-sentinel.install  2023-09-08 23:04:13.0 
+0200
+++ redis-7.0.13/debian/redis-sentinel.install  2023-10-16 20:55:08.0 
+0200
@@ -1,2 +1 @@
-debian/redis-sentinel.service /lib/systemd/system
 sentinel.conf  /etc/redis
diff -Nru redis-7.0.13/debian/redis-server.install 
redis-7.0.13/debian/redis-server.install
--- redis-7.0.13/debian/redis-server.install2023-09-08 23:04:13.0 
+0200
+++ redis-7.0.13/debian/redis-server.install2023-10-16 20:56:11.0 
+0200
@@ -1,2 +1 @@
-debian/redis-server.service /lib/systemd/system
 redis.conf /etc/redis

Bug#1054089: php-common: let dh_installsystemd choose the location of units

[Helmut Grohne]

Source: php-defaults
Version: 93
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. php-common is affected, because it installs
systemd units. Rather than move them, I recommend deferring the
placement to debhelper, because that'll make it revert to the previous
location for bookworm-backports to honour the file move moratorium that
still is in effect there. debdiff cannot represent the patch due to the
use of symlinks, so I'll give a script here:


ln -s ../phpsessionclean.timer debian/php-common.phpsessionclean.timer
ln -s ../phpsessionclean.service debian/php-common.phpsessionclean.service
sed -i -e /systemd/d debian/php-common.install

In debian/rules change

dh_systemd_enable --package=php-common phpsessionclean.timer

to

dh_systemd_enable --package=php-common --name phpsessionclean 
phpsessionclean.timer
dh_systemd_enable --package=php-common --name phpsessionclean --no-enable 
phpsessionclean.service

Helmut

Bug#1054090: zram-tools: let dh_installsystemd choose the location of the unit

[Helmut Grohne]

Source: zram-tools
Version: 0.3.3.1-1.1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. zram-tools is involved, because it includes a
systemd unit and hard codes its location to /lib/systemd. Rather than
simply move it, I recommend installing it using dh_installsystemd,
because that'll automatically revert back to /lib for
bookworm-backports. The patch cannot be represented using debdiff:

sed -i -e /systemd/d debian/install
ln -s ../zramswap.service debian/zram-tools.zramswap.service
printf "\noverride_dh_installsystemd:\n\tdh_installsystemd 
--name=zramswap\n" >> debian/rules

Helmut

Bug#1054088: sanoid: let dh_installsystemd choose the location of units

[Helmut Grohne]

Source: sanoid
Version: 2.2.0-1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move all aliased files from / to /usr to finalize the
/usr-merge transition via DEP17. sanoid is affected, because it installs
two systemd units. One of its units is installed via dh_installsystemd
and will move to /usr when the placement in dh_installsystemd changes.
The other unit is hard coded to /lib/systemd/system via
debian/sanoid.install. Rather than moving it to /usr, I recommend
installing it using dh_installsystemd as well, because it'll revert back
to the old location when uploading to bookworm-backports, which will
comply with the file move moratorium that still is in effect for
bookworm. I'm attaching a patch for your convenience.

Helmut
diff -Nru sanoid-2.2.0/debian/changelog sanoid-2.2.0/debian/changelog
--- sanoid-2.2.0/debian/changelog   2023-08-03 22:45:31.0 +0200
+++ sanoid-2.2.0/debian/changelog   2023-10-16 21:31:46.0 +0200
@@ -1,3 +1,10 @@
+sanoid (2.2.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_installsystemd choose the location of units. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 21:31:46 +0200
+
 sanoid (2.2.0-1) unstable; urgency=medium
 
   * [e979a85] New upstream version 2.2.0
diff -Nru sanoid-2.2.0/debian/rules sanoid-2.2.0/debian/rules
--- sanoid-2.2.0/debian/rules   2021-10-19 21:02:14.0 +0200
+++ sanoid-2.2.0/debian/rules   2023-10-16 21:31:40.0 +0200
@@ -5,3 +5,6 @@
 
 %:
dh $@
+
+execute_after_dh_install_systemd:
+   dh_installsystemd --name sanoid-prune
diff -Nru sanoid-2.2.0/debian/sanoid-prune.service 
sanoid-2.2.0/debian/sanoid-prune.service
--- sanoid-2.2.0/debian/sanoid-prune.service2019-11-11 17:21:09.0 
+0100
+++ sanoid-2.2.0/debian/sanoid-prune.service1970-01-01 01:00:00.0 
+0100
@@ -1,14 +0,0 @@
-[Unit]
-Description=Prune ZFS snapshots
-Documentation=man:sanoid(8)
-Requires=local-fs.target
-After=local-fs.target sanoid.service
-ConditionFileNotEmpty=/etc/sanoid/sanoid.conf
-
-[Service]
-Type=oneshot
-Environment=TZ=UTC
-ExecStart=/usr/sbin/sanoid --prune-snapshots --verbose
-
-[Install]
-WantedBy=sanoid.service
diff -Nru sanoid-2.2.0/debian/sanoid.install sanoid-2.2.0/debian/sanoid.install
--- sanoid-2.2.0/debian/sanoid.install  2019-11-11 17:21:09.0 +0100
+++ sanoid-2.2.0/debian/sanoid.install  2023-10-16 21:31:19.0 +0200
@@ -2,5 +2,4 @@
 sanoid /usr/sbin/
 findoid /usr/sbin/
 sanoid.defaults.conf /usr/share/sanoid/
-debian/sanoid-prune.service /lib/systemd/system
 CHANGELIST /usr/share/doc/sanoid/changelog
diff -Nru sanoid-2.2.0/debian/sanoid.sanoid-prune.service 
sanoid-2.2.0/debian/sanoid.sanoid-prune.service
--- sanoid-2.2.0/debian/sanoid.sanoid-prune.service 1970-01-01 
01:00:00.0 +0100
+++ sanoid-2.2.0/debian/sanoid.sanoid-prune.service 2019-11-11 
17:21:09.0 +0100
@@ -0,0 +1,14 @@
+[Unit]
+Description=Prune ZFS snapshots
+Documentation=man:sanoid(8)
+Requires=local-fs.target
+After=local-fs.target sanoid.service
+ConditionFileNotEmpty=/etc/sanoid/sanoid.conf
+
+[Service]
+Type=oneshot
+Environment=TZ=UTC
+ExecStart=/usr/sbin/sanoid --prune-snapshots --verbose
+
+[Install]
+WantedBy=sanoid.service

Bug#1054087: dnscrypt-proxy: will install conflicting systemd units once dh_installsystemd installs to /usr

[Helmut Grohne]

Source: dnscrypt-proxy
Version: 2.0.45+ds1-1.1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, dnscrypt-proxy will
install some units twice. It'll install units via
debian/dnscrypt-proxy.install to /lib/systemd/system and then
dh_installsystemd will install some of the same units to
/usr/lib/systemd/system. Such behaviour is prohibited by debian policy.
It is not a problem now, but will become an RC bug once I upload
debhelper. I'm attaching a patch for your convenience.

Helmut
diff -Nru dnscrypt-proxy-2.0.45+ds1/debian/changelog 
dnscrypt-proxy-2.0.45+ds1/debian/changelog
--- dnscrypt-proxy-2.0.45+ds1/debian/changelog  2023-03-25 15:24:36.0 
+0100
+++ dnscrypt-proxy-2.0.45+ds1/debian/changelog  2023-10-16 20:49:51.0 
+0200
@@ -1,3 +1,10 @@
+dnscrypt-proxy (2.0.45+ds1-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units only once using dh_installsystemd. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 20:49:51 +0200
+
 dnscrypt-proxy (2.0.45+ds1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy-resolvconf.service 
dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy-resolvconf.service
--- dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy-resolvconf.service  
2023-03-25 14:23:25.0 +0100
+++ dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy-resolvconf.service  
1970-01-01 01:00:00.0 +0100
@@ -1,21 +0,0 @@
-[Unit]
-Description=DNSCrypt proxy resolvconf support
-Documentation=https://github.com/DNSCrypt/dnscrypt-proxy/wiki
-After=dnscrypt-proxy.socket
-Requires=dnscrypt-proxy.socket
-ConditionFileIsExecutable=/sbin/resolvconf
-
-[Service]
-Type=oneshot
-RemainAfterExit=true
-ExecStart=/bin/sh -c 'systemctl show dnscrypt-proxy.socket \
-| grep "Listen.*Datagram" \
-| cut -d "=" -f 2 \
-| cut -d ":" -f 1 \
-| awk \'{ print "nameserver " $1 }\' \
-| /sbin/resolvconf -a lo.dnscrypt-proxy'
-ExecStop=/sbin/resolvconf -d lo.dnscrypt-proxy
-
-[Install]
-WantedBy=multi-user.target
-Also=dnscrypt-proxy.socket
diff -Nru 
dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.dnscrypt-proxy-resolvconf.service
 
dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.dnscrypt-proxy-resolvconf.service
--- 
dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.dnscrypt-proxy-resolvconf.service
   1970-01-01 01:00:00.0 +0100
+++ 
dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.dnscrypt-proxy-resolvconf.service
   2023-03-25 14:23:25.0 +0100
@@ -0,0 +1,21 @@
+[Unit]
+Description=DNSCrypt proxy resolvconf support
+Documentation=https://github.com/DNSCrypt/dnscrypt-proxy/wiki
+After=dnscrypt-proxy.socket
+Requires=dnscrypt-proxy.socket
+ConditionFileIsExecutable=/sbin/resolvconf
+
+[Service]
+Type=oneshot
+RemainAfterExit=true
+ExecStart=/bin/sh -c 'systemctl show dnscrypt-proxy.socket \
+| grep "Listen.*Datagram" \
+| cut -d "=" -f 2 \
+| cut -d ":" -f 1 \
+| awk \'{ print "nameserver " $1 }\' \
+| /sbin/resolvconf -a lo.dnscrypt-proxy'
+ExecStop=/sbin/resolvconf -d lo.dnscrypt-proxy
+
+[Install]
+WantedBy=multi-user.target
+Also=dnscrypt-proxy.socket
diff -Nru dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.install 
dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.install
--- dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.install 2023-03-25 
14:23:25.0 +0100
+++ dnscrypt-proxy-2.0.45+ds1/debian/dnscrypt-proxy.install 2023-10-16 
20:49:19.0 +0200
@@ -1,5 +1,2 @@
 debian/tmp/usr/bin/* usr/sbin
 debian/dnscrypt-proxy.toml /etc/dnscrypt-proxy
-debian/dnscrypt-proxy.service /lib/systemd/system
-debian/dnscrypt-proxy.socket /lib/systemd/system
-debian/dnscrypt-proxy-resolvconf.service /lib/systemd/system
diff -Nru dnscrypt-proxy-2.0.45+ds1/debian/rules 
dnscrypt-proxy-2.0.45+ds1/debian/rules
--- dnscrypt-proxy-2.0.45+ds1/debian/rules  2023-03-25 14:59:33.0 
+0100
+++ dnscrypt-proxy-2.0.45+ds1/debian/rules  2023-10-16 20:49:46.0 
+0200
@@ -9,9 +9,8 @@
 %:
dh $@ --builddirectory=_build --buildsystem=golang
 
-override_dh_installsystemd:
-   dh_installsystemd dnscrypt-proxy.service dnscrypt-proxy.socket \
-   dnscrypt-proxy-resolvconf.service
+execute_after_dh_installsystemd:
+   dh_installsystemd --name dnscrypt-proxy-resolvconf
 
 override_dh_auto_install:
dh_auto_install --destdir=debian/tmp

Bug#1054086: lsm: let dh_installsystemd choose the location of units

[Helmut Grohne]

Source: lsm
Version: 1.0.4-2
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. lsm is involved, because it installs a systemd
unit. Rather than move the unit, I recommend installing it using
dh_installsystemd, because that'll automatically revert back to the old
location for bookworm-backports and thus honour the moratorium that
still is in effect there. debdiff cannot represent this patch:

rm debian/lsm.install
ln -s ../lsm.service debian/lsm.service

Helmut

Bug#1054085: osmo-pcu will violate policy once dh_installsystemd moves units to /usr

[Helmut Grohne]

Source: osmo-pcu
Version: 1.1.0-2
Tags: patch
User: helm...@debian.org
Usertags: deb17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. In theory, osmo-pcu is covered, because it uses
dh_installsystemd. Unfortunately, the upstream build system also
installs a unit to /lib. Once dh_installsystemd installs units to /usr,
osmo-pcu will ship units in both /lib/systemd and /usr/lib/systemd.
Doing so violates policy. I'm attaching a patch that should be a noop
now and skips installing the upstream unit in favour of the Debian one
to resolve this conflict.

Helmut
diff -Nru osmo-pcu-1.1.0/debian/changelog osmo-pcu-1.1.0/debian/changelog
--- osmo-pcu-1.1.0/debian/changelog 2022-10-11 22:13:53.0 +0200
+++ osmo-pcu-1.1.0/debian/changelog 2023-10-16 17:52:34.0 +0200
@@ -1,3 +1,10 @@
+osmo-pcu (1.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install conflicting systemd units. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 17:52:34 +0200
+
 osmo-pcu (1.1.0-2) unstable; urgency=medium
 
   * upload to unstable
diff -Nru osmo-pcu-1.1.0/debian/rules osmo-pcu-1.1.0/debian/rules
--- osmo-pcu-1.1.0/debian/rules 2022-10-11 22:13:53.0 +0200
+++ osmo-pcu-1.1.0/debian/rules 2023-10-16 17:52:34.0 +0200
@@ -23,7 +23,7 @@
$(RM) .tarball-version
 
 override_dh_auto_configure:
-   dh_auto_configure -- --with-systemdsystemunitdir=/lib/systemd/system
+   dh_auto_configure -- --with-systemdsystemunitdir=no
 
 # Print test results in case of a failure
 override_dh_auto_test:

Bug#1054084: let dh_installsystemd choose the location of systemd units

[Helmut Grohne]

Source: crowdsec
Version: 1.4.6-6
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. crowdsec is involved, because it ships a systemd
unit. Rather than just move the unit, I recommend deferring the
placement to dh_installsystemd, because it'll revert to the old
placement in a bookworm backport. Consider doing the following:

sed -i -e /systemd/d debian/crowdsec.install
ln -sf ../config/crowdsec.service debian/crowdsec.service

Note that debdiff cannot represent this change as it contains a symlink.

Helmut

Bug#1054083: openvpn: installs some units twice when dh_installsystemd installs to /usr

[Helmut Grohne]

Source: openvpn
Version: 2.6.3-2
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so openvpn installs some
units twice. dh_installsystemd will then install them to
/usr/lib/systemd/system and debian/openvpn.install will also install
them to /lib/systemd/system (which currently is redundant). Doing so is
a policy violation and openvpn will be RC buggy once I upload that
debhelper change. I'm attaching a patch for your convenience.

Helmut
diff -Nru openvpn-2.6.3/debian/changelog openvpn-2.6.3/debian/changelog
--- openvpn-2.6.3/debian/changelog  2023-05-20 17:43:32.0 +0200
+++ openvpn-2.6.3/debian/changelog  2023-10-16 21:17:18.0 +0200
@@ -1,3 +1,10 @@
+openvpn (2.6.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install systemd units twice. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 21:17:18 +0200
+
 openvpn (2.6.3-2) unstable; urgency=medium
 
   * Cherry-pick two bugfix commits from upstream
diff -Nru openvpn-2.6.3/debian/openvpn.install 
openvpn-2.6.3/debian/openvpn.install
--- openvpn-2.6.3/debian/openvpn.install2023-05-20 17:43:32.0 
+0200
+++ openvpn-2.6.3/debian/openvpn.install2023-10-16 21:17:12.0 
+0200
@@ -1,3 +1 @@
-debian/openvpn@.service /lib/systemd/system
-debian/openvpn.service /lib/systemd/system
 debian/openvpn-generator /lib/systemd/system-generators

Bug#1054082: guacd: installs guacd.service twice when dh_installsystemd installs units to /usr

[Helmut Grohne]

Source: guacamole-server
Version: 1.3.0-1.1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to change dh_installsystemd to install units to /usr to finalize
the /usr-merge transition via DEP17. When doing so, guacd will contain
two copies of guacd.service. dh_installsystemd will then install it to
/usr/lib/systemd/systemd while debian/guacd.install also installs it to
/lib/systemd/system. Doing so is a policy violation, so this bug will
become release-critical once I upload debhelper. I'm attaching a patch
for your convenience.

Helmut
diff -Nru guacamole-server-1.3.0/debian/changelog 
guacamole-server-1.3.0/debian/changelog
--- guacamole-server-1.3.0/debian/changelog 2022-02-07 19:02:10.0 
+0100
+++ guacamole-server-1.3.0/debian/changelog 2023-10-16 21:40:47.0 
+0200
@@ -1,3 +1,11 @@
+guacamole-server (1.3.0-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install units only once when dh_installsystemd installs units to /usr.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Oct 2023 21:40:47 +0200
+
 guacamole-server (1.3.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru guacamole-server-1.3.0/debian/guacd.install 
guacamole-server-1.3.0/debian/guacd.install
--- guacamole-server-1.3.0/debian/guacd.install 2022-02-07 19:02:10.0 
+0100
+++ guacamole-server-1.3.0/debian/guacd.install 2023-10-16 21:40:45.0 
+0200
@@ -1,4 +1,3 @@
 bin/guacctl /usr/bin
 /usr/sbin/guacd
 /usr/share/man/man8/guacd.8
-debian/guacd.service /lib/systemd/system/

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

Control: tags -1 +pending

On 2023-10-13 09:17:49, Kyle Fazzari wrote:
> I don't entirely agree, but disagreement is okay. I do at least 
> recommend accompanying this with a cache age statistic, as we discussed 
> earlier.

Both of those have been done upstream, and I've uploaded a new snapshot
taking those into account.

I'm also planning on doing a stable update once this reaches
testing. Testers and feedback welcome!

-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#1053804: also at trixie

[Gert van de Kraats]

Same problem at Debian trixie(testing) with filezilla 3.65.0-3 :
2023-10-16T21:24:24.379086+02:00 debian systemd[1809]: Started 
app-gnome-filezilla-4525.scope - Application launched by gnome-shell.
2023-10-16T21:24:26.646156+02:00 debian kernel: [ 5791.686214] traps: 
filezilla[4525] trap invalid opcode ip:b7dc7aa3 sp:bfdb57c0 error:0 in 
libfzclient-private-3.65.0.so[b7d1b000+f9000]

Bug#1054081: ITP: librewolf -- community-maintained, privacy and security-focused browser based on firefox

[Kilian Romberg]

Package: wnpp
Severity: wishlist
Owner: Kilian Romberg 

* Package name: librewolf
  Version : 118.0.2
  Upstream Author : LibreWolf Community
* URL : https://librewolf.net/
* License : MPL 2.0
  Programming Lang: Bash, Python, CSS, TypeScript
  Description : community-maintained, privacy and security-focused browser 
based on firefox

LibreWolf is a custom and independent build of Firefox
that seeks to protect user privacy, security, and freedom
by providing appropriate settings and patches.

Closes RFP #981291

I plan uploading LibreWolf as a native package based on the script
solution at https://codeberg.org/librewolf/debian-obs. Yet, I haven't
found a team to possibly incorporate the LibreWolf packaging, but I'd
like that.


signature.asc
Description: PGP signature

Bug#1054009: RFS: runit-services/0.7.0 -- UNIX init scheme with service supervision (services)

[Nicholas D Steeves]

Hi Lorenzo,

Lorenzo  writes:

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "runit-services":
>
> 
>  * Package name : runit-services
>Version  : 0.7.0
[snip]
>* Import the runscript from mini-httpd-run package:
>  - change the runscript to use the default config file
>  - d/control: runit-services Provides mini-httpd-run

I'm unfamiliar with runit, but does anything need to be done in the
mini-httpd package to support your work in this upload?

By the way, thank you for writing such nice commit messages!

  
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/commit/566393e02ab8010405d14e38c0e02f4bea51afc8

I appreciate the thought and the openness that went into that work.  One
minor comment here: I'd recommend filing a bug against mini-httpd-run
shortly after the upload of runit-services_0.7.0, because otherwise
someone might potentially see a neglected package and then adopt it.
This bug would make the plan from your commit message more visible and
official.  It will also give the Quality Assurance team the opportunity
to support your plan, and this seems like it will be required for a
Request of QA Team (RoQA) removal--unless you adopt mini-httpd-run and
file a Request of Maintainer (RoM).  Maybe one of these approaches is
already part of your plan?

Also, thank you for thinking about smoothing the transition for users by
using Provides; although, I wonder how this will actually function,
because mini-httpd-run's version 1.0+nmu1 >> runit-services' 0.7.0.
You're right, Conflicts isn't required and it doesn't seem like Breaks
would be appropriate either.  Have you considered using versioned
Provides?  This would make it more clear, in dependency resolution, that
mini-httpd-run is now an obsolete cruft package.

  
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

Alternatively if the transition requires user/sysadmin intervention,
then why wouldn't a debian/NEWS file be a good thing?

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars

[Xiyue Deng]

Sean Whitton  writes:

> Hello,
>
> On Sun 15 Oct 2023 at 10:45pm -07, Xiyue Deng wrote:
>
>> Ah I see.  So for d/copyright we need to stick to the source
>> information.  Dropped Wilfred from the list of copyright holders for
>> now.  Also opened a PR upstream for tracking[1].
>
> Cool.  Just to note, in your commit message you wrote that he's not a
> copyright holder yet, but we can't assert that -- in fact, he probably
> is a copyright holder.  You could have written that he's not
> /documented/ as a copyright holder.
>

Ack.  Yeah I should have said that in the commit message.  I guess doing
a reword and letting everyone having to do a force pull is a no-go so I
think I'll have to leave it as-is.  Will be more precise in future.

>> As this is the first time I attempt of ITP/RFS, I'd like to go over the
>> steps for packaging as much as possible if OK.  But AIUI this package
>> will need to go through the NEW queue, so I guess if you sponsor my
>> upload to mentors.d.n it may require some extra steps, then I'm OK if
>> what you propose can save some trouble.
>
> Okay, go ahead and let me know when you've done 'dch -r'.
>
> I will still work out of git, so please don't push a signed tag there.
> See dgit-sponsorship(7) for more.

Pushed the commit with 'dch -r' to salsa and also uploaded to
mentors[1].  Please proceed as you see fit.

Thanks for the sponsorship!

[1] https://mentors.debian.net/package/bison-mode/

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1054079: roundcube: cross-site scripting (XSS) vulnerability in handling of SVG in HTML messages

[Guilhem Moulin]

Source: roundcube
Version: 1.6.3+dfsg-2
Severity: important
Tags: security upstream
Control: found -1 1.3.17+dfsg.1-1~deb10u3
Control: found -1 1.4.14+dfsg.1-1~deb11u1
Control: found -1 1.6.3+dfsg-1~deb12u1
Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/9168

In a recent post roundcube webmail upstream has announced the
following security fix:

 * Fix cross-site scripting (XSS) vulnerability in handling of SVG in
   HTML messages.

AFAICT no CVE ID has been assigned or requested yet, so I'll file a
request to that effect.  Upstream fixes for stable and LTS branches:

1.6.x 
https://github.com/roundcube/roundcubemail/commit/41756cc3331b495cc0b71886984474dc529dd31d
1.4.x 
https://github.com/roundcube/roundcubemail/commit/7b2df52ede57bab9e87e9c3bc00601eeca591a5e
  
https://github.com/roundcube/roundcubemail/commit/dc7b6850c68870570b438d79c0949a5031522127

1.3.x is no longer supported upstream but AFAICT affected nonetheless.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Simon McVittie]

On Thu, 31 Aug 2023 at 00:12:53 +0100, Simon McVittie wrote:
> I did the same testing as for bookworm's #1050868, summarized on
> .
> As with #1050868, all differences between the output of a reference
> version (from Debian 12.1) and the output of this version were expected
> or ignorable.

I have now also tried the proposed debootstrap_*.udeb via d-i, using
essentially the same steps as in
.
This time I installed XFCE rather than GNOME. Installation was successful.

Errata:
- The steps I wrote were incomplete, installing git and fakeroot on the
  build machine was also necessary
- As previously noted on #1050868, the proposed udeb needs to be copied
  into debian-installer_bullseye/build/localudebs/
- d-i 11 doesn't include "less", so the step involving viewing
  /usr/share/debootstrap/functions needs to use "more" instead

An additional note is that if you send Ctrl+Alt+F2 sufficiently early in
the "Installing the base system" step, and "ls -l /target" repeatedly, you
can see that as a result of Helmut's code changes, /target is initially
non-merged-/usr then gets converted to merged-/usr after unpacking the
Essential set.

smcv

Bug#1054078: src:sch-rnd: fails to migrate to testing for too long: uploader built arch:all

[Paul Gevers]

Source: sch-rnd
Version: 1.0.1-1
Severity: serious
Control: close -1 1.0.2-1
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sch-rnd has been trying to migrate for 31 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sch-rnd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054077: src:isc-dhcp: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: isc-dhcp
Version: 4.4.3-P1-2
Severity: serious
Control: close -1 4.4.3-P1-3
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:isc-dhcp has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on s390x.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=isc-dhcp



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars

[Xiyue Deng]

Sean Whitton  writes:

> Hello,
>
> On Mon 16 Oct 2023 at 03:51am -07, Xiyue Deng wrote:
>
>> Looks like I got confused about what you suggested as there was a "0.3"
>> tag that was from the upstream repo which I assume "git deborig" can use
>> so I thought an "upstream" may help more.
>>
>> I've now also pushed an "upstream/0.3" tag at the commit that matches
>> the "0.3" tag, but not sure whether this is what you were referring to.
>> If this works better I can remove the upstream branch to avoid further
>> complications.  Please advice.  Thanks!
>
> What I meant was simply pushing the 0.3 tag to salsa.

Ah got it, and done.  Sorry for the confusion.  I have also dropped the
unnecessary tag "upstream/0.3" and the upstream branch, which is not
actually used much in the dgit-maint-merge workflow AIUI.

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables

[Larry Doolittle]

Andreas -

On Mon, Oct 16, 2023 at 07:13:28PM +0200, Andreas Metzler wrote:
> > severity 941804 normal
> > This exim4 bug has taken on increased importance now that gmail requires 
> > DKIM
> > on all (?) incoming messages.
> 
> I do not follow: 
> 
> The smarthost transport is typically used by a machine without
> permanent internet connection to deliver *to* a smarthost. This
> smarthost the does the real delivery using M lookups et al.

Basically right.  I'd say "permanent and unimpeded Internet connection".
See below.

> google cares about the DKIM signature of the latter (the real mailserver).

Someone has to add the DKIM signature, tied to the sender address.
Google doesn't care where in the relaying chain it got added.

> OTOH if you want to use google as smarthost you need to use SMTP AUTH
> instead of adding a DKIM signature on your personal PC/laptop.

My use case is being stuck behind an ISP's firewall,
so the smarthost is supplied by the ISP.  When the ISP
delivers the mail to gmail, google needs some indication
that the mail I sent is really from me.  That's where DKIM comes in.
I _am_ me, so I can make my exim MTA "sign" the message with DKIM
on its way to the smarthost.

I don't doubt that other people have different setups.
Some will need this configuration fixed, some will not.
But before google started enforcing SPF/DKIM/DMARC earlier this year,
my smarthost routing approach could succeed without complications.
Now it needs DKIM.  Fortunately I could make that work -- after applying
a local patch to fix this bug.

  - Larry

Bug#1054076: mesa: fix name collision causing Wayland SIGSEGV on i915 machines

[Harlan Lieberman-Berg]

Source: mesa
Version: 23.2.1-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: hlieber...@debian.org
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/9889
Control: affects -1 gnome-shell

Hello maintainer,

Due to a name collision in the radeonsi module, gdm under Wayland will segfault
on any machine running an Intel Iris Plus GPU. This was reported in a variety of
distro trackers (https://bugzilla.redhat.com/show_bug.cgi?id=2238711,
https://bugs.archlinux.org/task/79831, etc.).

It can be fixed trivially with the cherry-pick of a patch upstream that is
allocated to be pulled into the 23.2 release stream
(https://gitlab.freedesktop.org/mesa/mesa/-/commit/9590bce3e249a34665b2c42b20bfdbdc7f32147f).
However, due to the impact on users, it would be nice to pull it in before Mesa
makes their next release.

I've attached the patch as well for your reference.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 9590bce3e249a34665b2c42b20bfdbdc7f32147f Mon Sep 17 00:00:00 2001
From: WinLinux1028 
Date: Tue, 11 Jul 2023 18:16:01 +0900
Subject: [PATCH] radeonsi: prefix function with si_ to prevent name collision

Fixed a build error caused by multiple gfx11_init_query symbols when building 
with iris and radeonsi specified in gallium-drivers.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9238
Part-of: 
---
 src/gallium/drivers/radeonsi/gfx11_query.c | 4 ++--
 src/gallium/drivers/radeonsi/si_pipe.c | 4 ++--
 src/gallium/drivers/radeonsi/si_pipe.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/gfx11_query.c 
b/src/gallium/drivers/radeonsi/gfx11_query.c
index bfcd8e2511050..2a331cc3bda25 100644
--- a/src/gallium/drivers/radeonsi/gfx11_query.c
+++ b/src/gallium/drivers/radeonsi/gfx11_query.c
@@ -422,13 +422,13 @@ struct pipe_query *gfx11_sh_query_create(struct si_screen 
*screen, enum pipe_que
return (struct pipe_query *)query;
 }
 
-void gfx11_init_query(struct si_context *sctx)
+void si_gfx11_init_query(struct si_context *sctx)
 {
list_inithead(>shader_query_buffers);
sctx->atoms.s.shader_query.emit = emit_shader_query;
 }
 
-void gfx11_destroy_query(struct si_context *sctx)
+void si_gfx11_destroy_query(struct si_context *sctx)
 {
if (!sctx->shader_query_buffers.next)
   return;
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index fb5c02c473b96..2b4fceb89b198 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -192,7 +192,7 @@ static void si_destroy_context(struct pipe_context *context)
si_release_all_descriptors(sctx);
 
if (sctx->gfx_level >= GFX10 && sctx->has_graphics)
-  gfx11_destroy_query(sctx);
+  si_gfx11_destroy_query(sctx);
 
if (sctx->sqtt) {
   struct si_screen *sscreen = sctx->screen;
@@ -637,7 +637,7 @@ static struct pipe_context *si_create_context(struct 
pipe_screen *screen, unsign
/* Initialize graphics-only context functions. */
if (sctx->has_graphics) {
   if (sctx->gfx_level >= GFX10)
- gfx11_init_query(sctx);
+ si_gfx11_init_query(sctx);
   si_init_msaa_functions(sctx);
   si_init_shader_functions(sctx);
   si_init_state_functions(sctx);
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 55f1d1788f1a1..389716854f9a6 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -1616,8 +1616,8 @@ void *si_create_query_result_cs(struct si_context *sctx);
 void *gfx11_create_sh_query_result_cs(struct si_context *sctx);
 
 /* gfx11_query.c */
-void gfx11_init_query(struct si_context *sctx);
-void gfx11_destroy_query(struct si_context *sctx);
+void si_gfx11_init_query(struct si_context *sctx);
+void si_gfx11_destroy_query(struct si_context *sctx);
 
 /* si_test_image_copy_region.c */
 void si_test_image_copy_region(struct si_screen *sscreen);
-- 
GitLab

Bug#1053993: RFP: emacs-eask -- CLI for building, running, testing, and managing your Emacs Lisp dependencies

[Martin]

Quoting Sean Whitton :

Typically we try to patch out the need for build-deps like this.  Have
you tried to do that?


Thanks for the suggestion, I'll do that!

I did that for the current version of the package (which uses cask, not
eask). And I can probably keep it that way. I wonder, if that is the
right direction for the future, in case more and more packages use such
build tools? But maybe this bug is not the right place to discuss it.

Bug#1054075: rust-itertools: please upgrade to v0.11

[Jonas Smedegaard]

Source: rust-itertools
Version: 0.10.5-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.11.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtc8sACgkQLHwxRsGg
ASF3tA//cye9b8WRxBjt090Q96/7o+EpjDw2NONPZxZFoudsqgqM/YCKuuSr6boO
gaserQeNyaYo+ZYQwxglIPmBwkU5NbEPwIbCcWAFtNRmHxsDaTVSyPEPuK6n6twi
T4NMGZGCEMK+ULow+fPWmAx9WR/k4/8wR3+/k1YoX4grakA1PC54XChXFWDTKkqa
/T7OWg7QE/O0CCYOy/hKobc1HBIzx76tE99W6x69XwG56vC85qomjd3OmiAUZgkX
iwGSx2ZPK3i607lI0ZW5A8NdimAfQePsMtTFhwM1UZUv0yXJJQlRcRE2Ncnkmnby
ql2CIQhpTEBKoWQ1id7+cIfB3HstVZyPpjooxhMWRRLc81Eko++ittY/16rafMzA
/LVBOMXp/l8UI4wLMXqlXpFJgJRxZxjNpN4uTpGrbhlIfG4l6OQI9eislajAAAdB
d+E7HD1/LGgMsRDdVrANkLVdZLj44kqdNJOmh5Mf4n4UaSgrgB/mX9xPd9Y3CwZU
AChZRUdTvH4yeq2vBSKmz8T0Hz5GQlv//CeE48TaYukHhJ9xCG0AStMvO0RFrDHj
pFP4nOfQuTZMjH/DvI2U0cM7Fo0hh3JA44sAt/DEZU8G0ENWUFLoz1cWjyXkj7K+
CbTJsb6ecCvFaqzxto/JOgrr93X6E4rJdPAFwpjkAvwTiojJ+cc=
=NeUm
-END PGP SIGNATURE-

Bug#1054074: psmouse: touchpad recognized as generic ps/2 mouse after each upgrade

[Jens Rapp]

Package: src:linux
Version: 6.1.55-1
Severity: important
File: psmouse
Tags: upstream
X-Debbugs-Cc: docjun...@web.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***
Whenever I do an apt upgrade and reboot the system (eg because linux-image was
involved) my touchpad is not recognized as touchpad anymore but as generic ps/2
mouse.
This leads to two main problems. First, I cannot scroll anymore which in most
cases has a workaround. Secondly, my touchpad seems to be sensitive enough to
move my mouse cursor while i'm typing which can be extremely annoying.

This happened several times now since I have this computer (Lenovo E15 Gen 2).
I re-installed the os directly after the last stable release (was using testing
before) which had no effect, so to my mind, it's no home made configuration
issue.

After some reboots, days, suspends and sacrificed frozen chicken, the touchpad
eventually becomes a fully grown touchpad again. Sadly, this is non-
deterministic so I just hope that it happens soon.

interestingly, psmouse seems to try to configure itself for the mouse and
failes.. which is about 5 seconds after mousedev has taken control of the
mouse:

$ sudo dmesg | grep mouse
[1.786098] mousedev: PS/2 mouse device common for all mice
[7.272331] psmouse serio1: Failed to deactivate mouse on isa0060/serio1: -5

so psmouse fails and stays unused

$ lsmod | grep psmouse
psmouse   184320  0

If there is anything else you need, tell me.

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


-- Package-specific info:
** Version:
Linux version 6.1.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 
root=UUID=67684b96-222a-466a-90cb-dbde1364bb8d ro quiet

** Not tainted

** Kernel log:
[4.433095] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[4.433096] Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 
38
[4.434053] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-0040-4150.sfi
[4.434057] Bluetooth: hci0: Found device firmware: intel/ibt-0040-4150.sfi
[4.434071] Bluetooth: hci0: Boot Address: 0x100800
[4.434072] Bluetooth: hci0: Firmware Version: 107-51.22
[4.436353] sof-audio-pci-intel-tgl :00:1f.3: Digital mics found on 
Skylake+ platform, using SOF driver
[4.438581] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040100
[4.438667] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[4.445381] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode
[4.447175] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, 
REV=0x370
[4.447235] thermal thermal_zone7: failed to read out thermal zone (-61)
[4.478440] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 5
[4.478445] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[4.478448] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT 
tables: 2
[4.479775] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
firmware intel/sof/sof-adl.ri
[4.479785] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
2:2:0-57864
[4.479788] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1 
Kernel ABI 3:23:0
[4.479794] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header 
type 3 size 0x30
[4.565327] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100
[4.575997] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
2:2:0-57864
[4.576002] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1 
Kernel ABI 3:23:0
[4.581904] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
firmware intel/sof-tplg/sof-hda-generic-2ch.tplg
[4.581911] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:22:1 
Kernel ABI 3:23:0
[4.582060] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not 
yet available, widget card binding deferred
[4.607553] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC257: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[4.607557] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[4.607559] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[4.607561] snd_hda_codec_realtek ehdaudio0D0:mono: mono_out=0x0
[4.607561] snd_hda_codec_realtek ehdaudio0D0:inputs:
[4.607563] snd_hda_codec_realtek ehdaudio0D0:  Mic=0x19
[4.632201] iwlwifi :00:14.3: base HW address: 18:cc:18:f6:31:37
[4.650153] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
[4.655794] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX 
overwritten
[4.655800] snd_hda_codec_realtek ehdaudio0D0: ASoC: 

Bug#525939: python-sqlalchemy: reflection of tables in remote mssql fails

[Lionel Élie Mamane]

On Mon, May 18, 2009 at 09:11:29PM +0200, Piotr Ożarowski wrote:
> [Geoff Crompton, 2009-04-28]

>> When trying to autoload a table on a remote mssql server, sqlalchemy
>> crashes.
>> This may be related to http://www.sqlalchemy.org/trac/ticket/1312.

> please check 0.5.4p1-1 (I just uploaded it to unstable). I think
> this new upstream release fixes your problem (ticket 1405 is now
> closed, 1312 is still open, though). I don't have access to mssql,
> so I cannot really check it.

Upstream #1312 has been closed for 0.6, so it is plausible this is has
been solved in Debian for ages (before oldoldstable)?

Anyway, I cannot reproduce with

python3-sqlalchemy 1.3.22+ds1-1
python3-pymssql 2.2.2-1+b3
libsybdb5 1.3.17+ds-2

note that I use as connection URL:

  'mssql+pymssql://%s:%s@%s/%s'

if I use

  'mssql://%s:%s@%s/%s'

then sqlalchemy tries to use PyODBC, which doesn't seem to be what the
original bug reporter was using.

Bug#1034832: www.debian.org: Distribution Archives: ftp.riken.jp no longer hosts debian-archives mirror

[Boyuan Yang]

X-Debbugs-CC: ftp-ad...@ftp.riken.jp a...@adam-barratt.org.uk

On Tue, 25 Apr 2023 13:35:37 -0400 Boyuan Yang  wrote:
> Hi,
> 
> Looks like the mirrors list maintained at
> https://salsa.debian.org/mirror-team/masterlist needs to be updated.
> 
> Forwarding the bug report to mirrors (at) debian.org.
> 
> Thanks,
> Boyuan Yang
> 
> 在 2023-04-25星期二的 23:49 +0700，William Poetra Yoga写道：
> > Package: www.debian.org
> > Severity: normal
> > X-Debbugs-Cc: william.poe...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > The archive mirror ftp.riken.jp no longer hosts the debian-archives
> > mirror. This has been verified on 2023-04-25.
> > 
> > Affected page: https://www.debian.org/distrib/archive

The Debian Mirrors.masterlist update request (merge request) can be found
at https://salsa.debian.org/mirror-team/masterlist/-/merge_requests/11 .

Thanks,
Boyuan Yang



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

Bug#1030164: python3-sqlalchemy: Update to 2.0

[Lionel Élie Mamane]

On Tue, Jan 31, 2023 at 08:32:48PM +0100, Piotr Ożarowski wrote:
> [Sam Bull, 2023-01-31]

>> It would be nice to have sqlalchemy 2.0 packaged in time for bookworm.
>> It would be a shame to be stuck with legacy 1.4 for atleast 2.5 years longer.

> I will not upload 2.0 to unstable now - there are way too many
> changes in the API. There's not enough time to fix all reverse
> dependencies.  I can upload 2.0 to experimental for now if you're
> interested.

I was going to ask whether now is a good time, a few months after
bookworm release, but I see:

$ apt-cache rdepends python3-sqlalchemy|wc -l
290

Darn, that's quite some quantity... Do you have any gross estimate
what percentage would be ready?

OTOH, according to the BTS it would solve bug #1042051 which is not
fixed in unstable ;-)

If not an upload to unstable, I'd be interested in 2.0.22 / thereafter
regular updates in experimental.

Thanks for maintaining the package in Debian!

Lionel

Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables

[Andreas Metzler]

On 2023-10-16 Larry Doolittle  wrote:
> Control:
> found 941804 4.94.2-7+deb11u1 
> found 941804 4.96-15+deb12u2
> found 941804 4.97~RC1-2
> severity 941804 normal
> thanks

> This exim4 bug has taken on increased importance now that gmail requires DKIM
> on all (?) incoming messages.
> I checked and can confirm its presence in the three versions above,
> as currently used in bullseye, bookworm, and trixie.

I do not follow: 

The smarthost transport is typically used by a machine without
permanent internet connection to deliver *to* a smarthost. This
smarthost the does the real delivery iusing M lookups et al.

google cares about the DKIM signature of the latter (the real mailserver).

OTOH if you want to use google as smarthost you need to use SMTP AUTH
instead of adding a DKIM signature on your personal PC/laptop.

cu andreas

Bug#1054073: mirror submission for mirror.blue3.com.br

[Samir Hanna Verza]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.blue3.com.br
Archive-architecture: amd64 arm64 armel armhf i386 mips
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Samir Hanna Verza 
Country: BR Brazil
Location: Porto Alegre,RS
Sponsor: BLUE3 INTERNET https://blue3.com.br
Comment: Extremo sul do Brasil, próximo a Uruguai e Argentina.




Trace Url: http://mirror.blue3.com.br/debian/project/trace/
Trace Url: http://mirror.blue3.com.br/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.blue3.com.br/debian/project/trace/mirror.blue3.com.br

Bug#1013345: ITP: west -- Description: meta tool for Zephyr RTOS

[Jakob Haufe]

Hi Zygmunt,

On Tue, 21 Mar 2023 12:07:03 +0100
Jakob Haufe  wrote:

> That would be great. Do you still intend to work on this?

Any news on this?

-- 
ceterum censeo microsoftem esse delendam.


pgpaEDgUyHGBz.pgp
Description: OpenPGP digital signature

Bug#1053993: RFP: emacs-eask -- CLI for building, running, testing, and managing your Emacs Lisp dependencies

[Sean Whitton]

control: tag -1 + moreinfo

Hello Martin,

On Sun 15 Oct 2023 at 01:32pm GMT, Martin wrote:

> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-emac...@lists.debian.org
>
> * Package name: emacs-eask
>   Version : 0.8.3
>   Upstream Author : Jen-Chieh Shen
> * URL or Web page : https://github.com/emacs-eask/cli
> * License : GPL-3
>   Description : CLI for building, running, testing, and managing your 
> Emacs Lisp dependencies
>
> Eask was built to use as a package development tool in your Elisp
> packages. But now, Eask supports various types of Emacs Lisp tasks.
>
> Eask is a new build dependency for emacs-dashboard.

Typically we try to patch out the need for build-deps like this.  Have
you tried to do that?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables

[Larry Doolittle]

Control:
found 941804 4.94.2-7+deb11u1 
found 941804 4.96-15+deb12u2
found 941804 4.97~RC1-2
severity 941804 normal
thanks

This exim4 bug has taken on increased importance now that gmail requires DKIM
on all (?) incoming messages.
I checked and can confirm its presence in the three versions above,
as currently used in bullseye, bookworm, and trixie.

 - Larry

Bug#1053983: dos2unix: Man page should mention that UTF-16 is converted to UTF-8 by default

[Ben Wong]

Hello Tony,

On Sun, Oct 15, 2023 at 8:26 AM tony mancill  wrote:

> Hi Ben,
>
> I believe the portion of the manpage you are referring to is:
>
> CONVERSION MODES
>   ascii
> In mode "ascii" only line breaks are converted. This is the default
> conversion mode.  [**Missing information about UTF-16 behavior.**]
>
> Although the name of this mode is ASCII, which is a 7 bit standard,
> the actual mode is 8 bit. Use  always  this  mode  when  converting
> Unicode UTF-8 files.
>

Yes, that is the section I was considering. The first sentence is quite
definite that _only_ line breaks are converted, so the conversion of UTF-16
was a surprise (a pleasant one, yes, but still a surprise).

Ideally, I'd like to see the option renamed and the man page say something
like:

CONVERSION MODES
  unix
In the default mode, "unix", line breaks are converted to newlines,
Unicode characters are encoded in UTF-8, and any BOM header is stripped.
This mode was originally called "ascii" and that name still works as an
alias for backwards compatibility.

And, yes, I had missed the reference to how -ascii actually works in the
--keep-utf16 section. It is good to see that unix2dos actually does what I
wanted rather than what it claims it does.

Thank you.

Ben Wong

Bug#1054022: libncursesw6: broken in GNU Screen

[Sven Joachim]

On 2023-10-16 04:36 +0200, Vincent Lefevre wrote:

> Package: libncursesw6
> Version: 6.4+20231007-1
> Severity: grave
> Justification: renders package unusable
>
> With libncursesw6 6.4+20231007-1, I get the following issue:
>
> $ screen -dRR mutt /usr/bin/mutt
> [screen is terminating]
>
> after a few seconds (or immediately "[screen is terminating]" when
> I hit a key). When rebuilding Mutt with debug support, this shows
> that Mutt is actually running, but with no output, and I don't know
> why it terminates.

The strace output you sent gives a hint.

> 659013 write(2, "Error opening terminal: screen.xterm-256color.\n", 47) = 47

This message is coming from ncurses' initscr() function, which
terminates the program if it cannot setup the terminal.

> Downgrading the ncurses packages to 6.4+20230625-2 makes this problem
> disappear.

Since I was able to reproduce the problem, I bisected it and found the
following change as the culprit:

,
| 20231001
|   + modify setupterm to provide for using ANSI cursor-position report (in
| user6/user7 terminfo capabilities) to obtain screensize if neither
| environment variables or ioctl is used.  The ncurses test-program
| with options "-E -T" demonstrates this feature.
`

Reverting ncurses/tinfo/lib_setup.c to the 20230923 patchlevel made the
problem disappear.  I'll leave it to Thomas to work out the details.

Cheers,
   Sven

Bug#1051241: headsup for gtk + pipewire update

[Jonas Smedegaard]

Quoting Jeremy Bícha (2023-10-16 17:50:11)
> Control: tags -1 +pending
> 
> Because the scheduled autoremoval day is today and because Jonas'
> packages are generally on the LowNMU list, I am uploading this as a
> NMU now.

Thanks to you both!

 - Jonas

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

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

signature.asc
Description: signature

Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)

[Ilias Tsitsimpis]

Hi Adrian,

On Sun, Oct 15, 2023 at 09:01PM, John Paul Adrian Glaubitz wrote:
> Unfortunately, we're running into another familiar problem which is a missing 
> -latomic
> when building hadrian using the bootstrap.py script which does not take any 
> build flags,
> the build of the »shake« package fails with the linker complaining about 
> unresolved
> references to 64-bit atomic helper functions:
> 
> Linking 
> /home/glaubitz/ghc18/ghc-9.4.7/hadrian/_build/dists/shake-0.19.4/build/shake/shake
>  ...
> /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function 
> `stmStartTransaction':
> (.text.stmStartTransaction+0xe4): undefined reference to `__atomic_load_8'
> /usr/bin/ld: (.text.stmStartTransaction+0xfc): undefined reference to 
> `__atomic_store_8'
> /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function 
> `stmCommitTransaction':
> (.text.stmCommitTransaction+0x40): undefined reference to `__atomic_load_8'
> /usr/bin/ld: (.text.stmCommitTransaction+0x118): undefined reference to 
> `__atomic_load_8'
> /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(ThreadPaused.thr_o): in function 
> `threadPaused':
> (.text.threadPaused+0x314): undefined reference to `__atomic_load_8'
> /usr/bin/ld: (.text.threadPaused+0x32c): undefined reference to 
> `__atomic_store_8'
> /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(Threads.thr_o): in function 
> `tryWakeupThread':
> (.text.tryWakeupThread+0x194): undefined reference to `__atomic_load_8'
> /usr/bin/ld: (.text.tryWakeupThread+0x1a8): undefined reference to 
> `__atomic_store_8'
> /usr/bin/ld: (.text.tryWakeupThread+0x1c4): undefined reference to 
> `__atomic_load_8'
> (...)
> /usr/bin/ld: (.text.throwToMsg+0x444): undefined reference to 
> `__atomic_load_8'
> /usr/bin/ld: (.text.throwToMsg+0x458): undefined reference to 
> `__atomic_store_8'
> /usr/bin/ld: (.text.throwToMsg+0x478): undefined reference to 
> `__atomic_load_8'
> /usr/bin/ld: (.text.throwToMsg+0x490): undefined reference to 
> `__atomic_store_8'
> /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(SpinLock.thr_o): in function 
> `acquire_spin_lock_slow_path':
> (.text.acquire_spin_lock_slow_path+0x64): undefined reference to 
> `__atomic_fetch_add_8'
> /usr/bin/ld: (.text.acquire_spin_lock_slow_path+0x80): undefined reference to 
> `__atomic_fetch_add_8'
> collect2: error: ld returned 1 exit status
> `powerpc-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)

This is a problem with your custom GHC (9.0.3). I believe you need to
use this patch as well [1], when building your custom GHC. I am
surprised this didn't fail during build time. Also, take a look at the
patches we have in Debian, there might be others that you need to use as
well.

[1] https://sources.debian.org/src/ghc/9.0.2-4/debian/patches/latomic-64bit/

> When building hadrian with "./hadrian/build -j", it's possible to pass the 
> necessary
> "-latomic" with the help of "*.*.ghc.link.opts = -latomic". I assume, for the 
> bootstrap
> python script, will have to patch either the Haskell sources or the Python 
> script.

Note that "*.*.ghc.link.opts = -latomic" is parsed by hadrian itself,
it will not affect how hadrian is built. I haven't tested it but I
believe './hadrian/build -j "*.*.ghc.link.opts = -latomic"' will fail as
well in your case.

Best,

-- 
Ilias

Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars

[Sean Whitton]

Hello,

On Mon 16 Oct 2023 at 03:51am -07, Xiyue Deng wrote:

> Looks like I got confused about what you suggested as there was a "0.3"
> tag that was from the upstream repo which I assume "git deborig" can use
> so I thought an "upstream" may help more.
>
> I've now also pushed an "upstream/0.3" tag at the commit that matches
> the "0.3" tag, but not sure whether this is what you were referring to.
> If this works better I can remove the upstream branch to avoid further
> complications.  Please advice.  Thanks!

What I meant was simply pushing the 0.3 tag to salsa.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1051241: headsup for gtk + pipewire update

[Jeremy Bícha]

Control: tags -1 +pending

Because the scheduled autoremoval day is today and because Jonas'
packages are generally on the LowNMU list, I am uploading this as a
NMU now.

Thank you,
Jeremy Bícha

Bug#1054022: libncursesw6: broken in GNU Screen

[Vincent Lefevre]

Via JuiceSSH+mosh under Android, if I hit a key, I can see spurious
escape sequences in the output after the error message:

^[[1;1R^[[49;80R^[[49;80R^[[49;80R

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1054044: iproute2: ss show wrong timer value in unit ms

[douniwan5788]

Package: iproute2
Version: 5.10.0-4
Severity: normal
Tags: l10n upstream
X-Debbugs-Cc: 16a16...@duck.com

Dear Maintainer,

When using the ‘ss’ command with the ‘–options’ parameter to display
timers, times less than 9 seconds are displayed as ‘1.234ms’. However,
this actually represents 1 second and 234 milliseconds. The use of the
period (.) is quite confusing to me. It seems to be used as a digit
group separator(thousands separator). However, I am more familiar with
using the period as a decimal separator. Could this be an issue of
internationalization (i10n)?

-- System Information:
Debian Release: 11.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libbpf01:0.3-2
ii  libbsd00.11.3-1+deb11u1
ii  libc6  2.31-13+deb11u7
ii  libcap21:2.44-1
ii  libcap2-bin1:2.44-1
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libelf10.183-1
ii  libmnl01.0.4-3
ii  libselinux13.1-3
ii  libxtables12   1.8.7-1

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- debconf information excluded

Bug#1054043: texlive: Texlive updates are too large

[Stefan Monnier]

Package: texlive
Version: 2023.20230613-3
Severity: wishlist

Dear Maintainer,

This is not a new problem, but after all these years I figured maybe
I should finally report it: I think updates to Texlive are larger than
they should.  This is probably not completely specific to Texlive but
that's where I see it in the most glaring way since some of its packages
are the largest .deb packages I have.

Let's take the example of `texlive-lang-french`: the last two `.deb`
packages I have for it in /var (I'm tracking Debian testing) are around
80MB each.

But if I use `xdelta` on their respective (uncompressed) `data.tar`
I get an 11MB result, there's a clear potential to reduce the needed
download size by a factor 7x in this case (and potentially disk space).

For the `texlive-fonts-extra` monster, the xdelta is 20MB while the
`.deb` are 500MB, a reduction by a factor 24x.

[ The above two comparisons are between 2022.20230122-4 and
  2023.20230613-2.  ]

Clearly, taking advantage of this will require changes to the Debian
infrastructure, so is outside of the scope of the Texlive team itself,
but I hope you'll know where to redirect this "bug" report.

And in the mean time: thank you for your work, of course,


Stefan "dreaming of Debian updates as efficient as
`git fetch` :-)"


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Apr  3  2016 /usr/local/share/texmf/ls-R
-rw-rw-r-- 1 root root 2302 Sep 28 12:24 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 27 17:39 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 27 17:39 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 14  2014 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 475 Oct 24  2022 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 27 17:39 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 27 17:39 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5047 Sep 22 12:54 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Aug 24  2006 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 24  2022 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 texlive depends on:
ii  texlive-fonts-recommended  2023.20230613-3
ii  texlive-latex-base 2023.20230613-3
ii  

Bug#1053803: debian-installer: grub2 2.12~rc1-10 on ARM64 daily installer makes linux image load fail

[Emanuele Rocca]

Control: reassign -1 grub-efi-arm64-bin
Control: retitle -1 grub 2.12~rc1-10 fails loading linux on Renesas RZG2L, grub 
2.06 works

Hi John, thanks for the bug report!

On 2023-10-11 04:15, John wrote:
> The ARM64 daily installer stopped working from 19-Sep-2023 due to grub2
> 2.12~rc1-10 updates with linux image load failure.
> 
> This was working ok on 04-Sep-2023 with grub 2.06-13

For now we've only been able to reproduce this on a Renesas RZG2L board
as far as I'm aware, retitling the bug accordingly. For example, I can
boot kernels with grub 2.12 on ARM systems such as the Thinkpad X13s,
Macbook M1, and RPi 3B+.

Also the problem is grub-specific and not limited to the installer, so
I've reassigned it to the grub-efi-arm64-bin binary package.

Booting with debug enabled, this is the output of a failed attempt on
the Renesas board. The grub version used in this test was 2.12~rc1-10.

loader/efi/linux.c:101:linux: UEFI stub kernel:
loader/efi/linux.c:102:linux: PE/COFF header @ 0040
loader/efi/linux.c:128:linux: LoadFile2 initrd loading enabled
loader/efi/linux.c:495:linux: kernel file size: 34445248
loader/efi/linux.c:497:linux: kernel numpages: 8410
loader/efi/linux.c:514:linux: kernel @ 0xb6b43000
loader/efi/linux.c:416:linux: Using LoadFile2 initrd loading 
protocol
loader/efi/peimage.c:242:linux: PE-COFF header checked
loader/efi/peimage.c:316:linux: sections loaded
loader/efi/peimage.c:518:linux: no relocations
loader/efi/linux.c:213:linux: linux command line: 
'BOOT_IMAGE=/linux'
error: image not loaded.

This instead is grub 2.12~rc1-11 succeeding on a RPi:

loader/efi/linux.c:101:linux: UEFI stub kernel:
loader/efi/linux.c:102:linux: PE/COFF header @ 0040
loader/efi/linux.c:128:linux: LoadFile2 initrd loading enabled
loader/efi/linux.c:495:linux: kernel file size: 34510784
loader/efi/linux.c:497:linux: kernel numpages: 8426
loader/efi/linux.c:514:linux: kernel @ 0x2c92
loader/efi/linux.c:416:linux: Using LoadFile2 initrd loading 
protocol
loader/efi/peimage.c:200:linux: PE-COFF header checked
loader/efi/peimage.c:276:linux: sections loaded
loader/efi/peimage.c:478:linux: no relocations
loader/efi/linux.c:213:linux: linux command line: 
'BOOT_IMAGE=/install.amd64/vmlinuz --- quiet'
loader/efi/linux.c:233:linux: starting image 0x351cf518

Bug#1054042: librandombytes-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/librandombytes.a

[Helmut Grohne]

Package: librandombytes-dev
Version: 0~20230919-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libnacl-dev

librandombytes-dev has an undeclared file conflict. This may result in
an unpack error from dpkg.

The file /usr/lib/x86_64-linux-gnu/librandombytes.a is contained in the
packages
 * libnacl-dev/20110221-12 as present in bookworm|trixie|unstable
 * librandombytes-dev/0~20230919-1 as present in unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Joachim Bauch]

Hi,

On 16.10.23 16:36, Christoph Anton Mitterer wrote:

Seems a new upstream version is out:
https://github.com/strukturag/libheif/releases/tag/v1.17.0


yes, packaging has already been updated and is looking for sponsorship:
https://mentors.debian.net/package/libheif/

I notified pkg-multimedia-maintainers as I did in the past for packaging
updates, so let's wait until somebody accepts it...

Cheers,
  Joachim



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054041: rust-cookie-store: please upgrade to v0.20

[Jonas Smedegaard]

Source: rust-cookie-store
Version: 0.19.1-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.20.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtTZ0ACgkQLHwxRsGg
ASFAhQ//dMg1240ZFDzdo3/CFfGen1nbLFNemwOtB3QfndtQTQML4gPlasZ847/Y
YL3eAwiTSHO/4+Z2JF/gW1VkGFcZ4lc1b+eaYEtEFEnImjcUMQ/gMI2yZZvD0dGf
sBPcGXWjhrxbGbzH7ObaeZ49vJjQESBG71sx2hyF0fR5cKah+HHjcCb+DmkRdpzj
hX0ctRPIb5olAXnB+ghzfJ/fM6wj86ZHeHRGIYGF9av3VxhDTrOr/0bHtbP0q+/t
qrrRulUYgAUvOEigkwW7Imp/z1W5WibFzTc2M/GH4WAfwqUyysAj1TTi2B3kTA8n
mOISkT3FCh1lDvSIpy/3DZ+Txcnfws6EWlr3uSgo3CXRwI56LoUXniJ9+T52uV0N
SF4rDaOJew66fHP1iOozPNCnnjWauQ8YM4U5yopxbQEguuC5hh9tOOabStFX1Ugg
FZyIEVdnLGcCaWwU3Srmb3/ewiOap26EMRrxRmSZ4JVml+7utiYglVPA43RjQj3p
mrGvADKeyV4+rKD5VJKVcB0+FACVt24NwxHyJqyVI49n47yVNy1o02gCNCkAHRq1
tFwOZiI4R/DkoLbss1poLVGymgJsqXGfKzY17m07ZxewA9fmQtAItVtGkhD6RzvF
tsUH7lJBQzPI7+384Z3ACR+2/fVWGkCnYEW+LmWXQyWLI8XS53U=
=wa/X
-END PGP SIGNATURE-

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Hey.

Seems a new upstream version is out:
https://github.com/strukturag/libheif/releases/tag/v1.17.0

Cheers,
Chris

Bug#1054036: php-geos: Triggers PHP Warning on every PHP call

[Sebastiaan Couwenberg]

Control: tags -1 pending

This is fixed in git, but note that php-geos is not well maintained 
upstream. It has test failures with GEOS 3.12, for example. You're 
better off looking for an alternative or getting involved upstream.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1054039: rust-time: please update to v0.3.29

[Jonas Smedegaard]

Source: rust-time
Version: 0.3.23-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.29.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtRd0ACgkQLHwxRsGg
ASGspw/+OMR9QJ5dyeECsjji83aYEGaydQwqBrbt8J4qavJ7vcZcOgdWpN0mvvWB
QN7bYOeozBCiFQeiIJoc0muTC70tqnv7niOEoBVehzusxkJN9gk9hOo9IkdmDANU
UcCgeXbuVlqAFu/Za4GYzNbVTEFzoMjSesFmVeUAb9mzlx698rAj4krG4N1Jub+h
7JG+bg4U/eIiidbo2gfcNX/V83d39GY9LSH4AK1+5dGsiMiqc4E1CVWATwuccksR
CzrSWVfZ1qg0qRWzujlteS4KcJRBG9ksWKmqRj3skuSj9JKzUZ6HLbKBUBbwFnU0
Og4dok/qvNo4UnH2Lz9wMByz4ZeGsncoG71r6dIu1yFK0DLUuB4B3y6Unc797ani
xhGZhjGsoqsRzeLYdvcDlzTYFwMlfwNga2VDYEMAM9FodPGlitKfE9Y7ZLW5/4nG
/Zy5EK+zk2ONNcGi+W2GKYYAeJ+pKib2k51HtJrX0r3+flL7OKFiGaxYqo5yQU0b
gxrFRKwH6vMHEoAMXd3OjQpLZIgxRPlDUP3f3NSqLc3OgKlhRrm0T8mhr8rMTp+Q
GEqP2x4O+h4s91wAi2vPX9cGAh84t5XVWbvfvoDaRH7iOi8QB523EkOFUmYil0jE
o2iiCdtcjGUTesjfg5v3DqX7vitX+e18F3YdUBaGIsXfmZw0xUI=
=lzpK
-END PGP SIGNATURE-

Bug#1054040: cups: 'make clean' fails in man/Makefile - master file 'backend.7' does not exist

[Tj]

Package: cups
Version: 2.4.2-3+deb12u4
Severity: minor
Tags: l10n

Whilst cherry-picking an upstream commit to Bookworm (2.4.2-3+deb12u4)
to fix #1039983 I discovered an 'un'build failure doing either:

debian/rules clean
make clean
...
Cleaning in man...
make[3]: Entering directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man'
make[3]: warning: -j12 forced in submake: resetting jobserver mode.
/usr/bin/rm -f mantohtml mantohtml.o
/usr/bin/rm -f cancel.1 cups.1 cups-config.1 cupstestppd.1
ippeveprinter.1 ippfind.1 ipptool.1 lp.1 lpoptions.1 lpq.1 lprm.1 lpr.1
lpstat.1 ppdc.1 ppdhtml.1 ppdi.1 ppdmerg
e.1 ppdpo.1 classes.conf.5 client.conf.5 cups-files.conf.5
cups-snmp.conf.5 cupsd.conf.5 cupsd-logs.5 ipptoolfile.5 mailto.conf.5
mime.convs.5 mime.types.5 ppdcfile.5 prin
ters.conf.5 subscriptions.conf.5 backend.7 filter.7 ippevepcl.7
notifier.7 cupsaccept.8 cupsctl.8 cupsfilter.8 cups-lpd.8 cups-snmp.8
cupsd.8 cupsd-helper.8 cupsenable.8 l
padmin.8 lpinfo.8 lpmove.8 lpc.8
for lang in de fr pt; do make -C $lang clean; done
make[4]: Entering directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/de'
/usr/bin/rm -f mantohtml mantohtml.o
make[4]: Leaving directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/de'
make[4]: Entering directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/fr'
/usr/bin/rm -f mantohtml mantohtml.o
make[4]: Leaving directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/fr'
make[4]: Entering directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/pt'
/usr/bin/rm -f mantohtml mantohtml.o
make[4]: Leaving directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/pt'
# Make sure the PO files are updated and remove generated
# translations.
po4a --previous --rm-translations ../debian/manpage-po4a/cups.cfg
../debian/manpage-po4a/cups.cfg:3: The master file 'backend.7' does not
exist.
make[3]: *** [Makefile:104: clean] Error 255
make[3]: Leaving directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man'
make[2]: *** [Makefile:92: clean] Error 1
make[2]: Leaving directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting'
dh_auto_clean: error: make -j12 distclean returned exit code 2
make[1]: *** [debian/rules:259: override_dh_auto_clean] Error 2
make[1]: Leaving directory
'/srv/NAS/Sunny/SourceCode/cups/cups-openprinting'
make: *** [debian/rules:24: clean] Error 2

It looks like

debian/patches/0016-Debian-po4a-infrastructure-and-translations-for-manp.patch

assumes the clean target is operating in the build directory
(./debian/tmp/) where a 'master' man-page does exist.

Bug#1054037: rust-crossterm: please upgrade to v0.27

[Jonas Smedegaard]

Source: rust-crossterm
Version: 0.25.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.27.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtRVUACgkQLHwxRsGg
ASFfZA/7BjllG6wCcO68svp/bJ0xjKV89qNqGydUpC1GR9YH5lRwSR11hIBzQ0Gx
07XPI0gDzU/tLGpbhLE8LUkOOUyZFuk4qg3Y141UKxf87gOdnMFFAlzvDs5W4E3l
pmerWmxNj9bJXsYdjCvieqFERLneA7T9iBn9B96Crnf+JehYFN5k5mYq52j9pJbZ
tdi1RkbgDEv3sz4krnsET/A0UaXiT3PUI/BlXg92flFxtkZFuAY+FKT94XAaEEPA
/iWAVhR+ridi8S1tc6Kss9ZBxJkFsSGU6EYhVrHMSKgXCh44/ULQgtBokxizdkuO
hUc6WlJDmNedkax9U7tvY69tYK/7elc9BmaYE8DCGt9FaCsw1uK7tfT9tc1r/xlA
zf9Ishk+OUJU4HboBpxMNFvfOhWfZ6XhiycU5oauLwlYnHKYYt2kLW6nSTXIvLwY
5zWWNyhnw92lKno4DsxOKmJpxlxl3abdcNO6k0RzhUGAbXKkrWQ36EjkBPnKSf75
iy5kpDQu+/BXq75OY5tOt1wfLRj1NcDM3fEzpAYE+lLaUm6m3AubPG+vxtITTvH1
y+oB95Kfq/Nj4FeJMYpIOblZRzBPgem/JRINTX/tLdb3s9mFc7q3LPT1yEQOlPup
Dn0KYi/ZP7OvM+gzYWruKM/kjhg6fWnkFl6i+NabS+hgRRdh4M4=
=ZxIK
-END PGP SIGNATURE-

Bug#1054038: rust-ratatui: please upgrade to v0.23

[Jonas Smedegaard]

Source: rust-ratatui
Version: 0.22.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) newer upstream branch v0.23.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtRZQACgkQLHwxRsGg
ASFs7A//ceChMm8UDO/7hSonm6WAslA4kVHW1jb3/ium+UdULKai2aFbX/JtM34X
V9UoepfEpkCwUMM3O/5wbBGRyXEynARlDHthKYo3vSAPPNBJ3cw12YtsIFFHS1ko
BXnvuuT7PKi5+hpjGATixxsj7Ue8l55GNhlV0gLld7L9I8arK5JI9sbvhTHhmXzT
5gD6bKwIKXM6LvQZt8JxhA+0M8MF45abe9e3z52jWGFYy+T8EXLlRMPr/nWxntZ3
6DfY7QCjwl6vE2F2+162RXEzNeS8J9N6yFjsbDilufJ0dRQRN0K2LUAnXca2NKFq
a2Jx5Ch3Hsr8XXyaOSZpB8IWwl1jaKqCM67wJPE/zPHRyBou8yiDNkSsiiu/WCWf
+GIPjhxTkIdsUaQaHl6pgTQoFCD7Lj7MB7h+sC0YwiH0YfcMQTQu2vGPcNDpgdm5
AWV7/EZYQzVyV3l1JEqbDA/1iW5+d51MUXXyW+4x/aOKcXvjMewoLNeMCf/RcbId
K6MckFS91BO4obL7Z0LvISonlAh9GeWAYgPhxfJc/qRPqqS1dCiYVgP/WACPimx7
5GSmLOI4hM9abz9qRWTiw4a8uVmDQc7w2fbsjGE/bL7Iqr1oJ9YYjZSwe2uKXt2F
6CNXahmGxP8XsJhRFRa7PphrIZx/E+o2KmTJJaHialJYsHS6H8g=
=Nlnt
-END PGP SIGNATURE-

Bug#1037133:

[Agustin Martin]

On Tue, Sep 19, 2023 at 11:43:16AM +, c.bu...@posteo.jp wrote:
> Upstream responded to my questions about how this was fixed.
> They pointed to two PullRequests.
> 
> https://github.com/owncloud/client/pull/10058
> https://github.com/owncloud/client/pull/10065

Hi,

According to https://github.com/owncloud/client/issues/10071 this seems to
be fixed in upstream 2.11.1 version.

Is this stll a problem in current sid/testing 4.2.0.11670+dfsg-1 version?

Regards,

-- 
Agustin

Bug#1054036: php-geos: Triggers PHP Warning on every PHP call

[Edward Nash]

Package: php-geos
Version: 1.0.0-7+b1
Severity: important
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Install php-geos and run e.g. php -i on the CLI or run any PHP script. A PHP 
warning is triggered:
PHP Warning:  GEOSGeometry::__toString() implemented without string return type 
in Unknown on line 0

The only way to prevent this and retain php-geos is to suppress reporting of 
PHP Warnings, which is
undesirable.

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

This problem is fixed in upstream with commit ee5ca8f373 
(https://git.osgeo.org/gitea/geos/php-geos/commit/ee5ca8f3739a4e3c1cdeb0abf4f1a47d9ca751a5).

Please incorporate this patch in the Debian package of php-geos and also 
consider releasing it as a
bugfix for Debian stable, as the usability of php-geos is in my opinion 
strongly affected by this bug.

Many thanks in advance for your consideration!

Best regards,

Edward Nash

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

Kernel: Linux 5.10.102.1-microsoft-standard-WSL2 (SMP w/8 CPU threads)
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: unable to detect

Versions of packages php-geos depends on:
ii  libc62.36-9+deb12u3
ii  libgeos-c1v5 3.11.1-1
ii  php-common   2:93
ii  php8.2-cli [phpapi-20220829] 8.2.7-1~deb12u1
ii  php8.2-fpm [phpapi-20220829] 8.2.7-1~deb12u1
ii  php8.2-phpdbg [phpapi-20220829]  8.2.7-1~deb12u1

php-geos recommends no packages.

php-geos suggests no packages.

-- no debconf information

Bug#1054035: mpich: FTBFS on ppc64 due to bogus architecture check in debian/rules

[John Paul Adrian Glaubitz]

Source: mpch
Version: 4.1.2-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello!

The configure scirpt for src:mpich is run with --with-ucx on ppc64 despite
the architecture not being whitelisted in the architecture check in debian/
rules [1]:

checking for rdma/fabric.h... yes
checking for fi_getinfo in -lfabric... yes
checking for ucp/api/ucp.h... no
configure: error: --with-ucx is given but not found
tail -v -n \+0 config.log

This is because the architecture check in debian/rules uses findstring()
which matches "ppc64" in "UCX_ARCH" which is set to "amd64 ppc64el arm64".

The proper approach would be to use filter() instead of findstring() since
the former matches only words separated by whitespaces [2]. I have verified
that this fixes the FTBFS on ppc64.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=mpich=ppc64=4.1.2-2=1694900148=0
> [2] https://www.gnu.org/software/make/manual/html_node/Text-Functions.html

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1054031: calc: updated version 2.15.0.1 available

[Martin Buck]

On Mon, Oct 16, 2023 at 08:18:00AM -0400, James Dietrich wrote:
> Just a note that a newer version of calc (2.15.0.1) is available. It would
> be good if this could be updated in Debian.

Already working on it, but I first had to get the packaging and my workflow
in better shape. That's why there was another upload of an old upstream
version. The next one should be 2.15.0.1, hopefully within the next few days
(but better don't hold your breath ;-)

Martin

Bug#1054034: rust-smallvec: please update to v1.11.1

[Jonas Smedegaard]

Source: rust-smallvec
Version: 1.11.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v1.11.1.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtMp4ACgkQLHwxRsGg
ASFW5w/+JozD0WO9tl/TkfWEot+0yV3VVj/irZxFw3PyvAGANCg6s+x8TEF7BkuX
y7Bso0sfWH2pM+m0ddQt3nLmVekoFwP1d9+gEuaA1k5iMb/B0FBJExE5RA3pdN8d
0W1BNFoJeiiAi4sfVibukfH67H9asMLp5w1NOUJ7UnCf7lYGcscNJmKPQYl0uaAu
qdxQJ/TbgYW89p7YFlmZwmmJXuyu2dbp/3ifU6Asj2OkLHZKU1qs02eyGecrrqFh
rOVEikZgNYj5nK7W+HYzPE93IAmXAgcQ0KZ38yvaFYUaljRKkUA2uDoe4iKYTdKY
c6BOQfMXtNVCHT/zh3kayhUav1xUW+ohdZoPYCgs4CMdpcAMHCbSPaJpUXxn6Pwv
LPNcc2TJ96J6DhBJNV+NxACwDi4q+nVgBnRWWrum6BzUD35BMuV38Qgg8fedI9AZ
1vxT0peBrt/2u5iVl1tFfSfpSl4AfVjysOP+wUA6SMmgujsB0T9skxngBtfpLRtO
ZhRHLnByruHzBnKBDB89mxNMxIVvZtPpMZjHU5B+sJAWxf9MWErI5XumNHoMtdxU
/ZEkGoy4air8G56/Xh88lKYeF/IPvCMm2tkh7nWvO900kVLguFl+wZHaNkfVcSKq
4AX+/h6QiAZBU7p/JG/Danfn64dY/j3oavU/BiWLfPjJjtAwHt8=
=ODFA
-END PGP SIGNATURE-

Bug#1054033: rust-pin-project: please update to v1.1.3

[Jonas Smedegaard]

Source: rust-pin-project
Version: 1.1.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v1.1.3.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtMgYACgkQLHwxRsGg
ASEhTQ//bdpreSGUzDWWVOfYRWSqs5rFH0dTi4IIqZZEortOw5AfK18YIG6A3wtT
4zD1yRkxqq36qI0FUAkep4SDc8HrqNwbCL6VV89s+8RCxvpshOfbnU8VPbufA0Xk
+Ef2oPCvH52P7R1BG4yHI2s0ZwB+P8NPF1fYtzr6fpI5GAWV2MGQt+v2mwQCTnTJ
cvAcmSHHXw8+rc7koICWwLpfxVvEMjrI6TL2rQt1M+oP6g14QMT0MOivmAWQmdgO
r2jia6B2IKzYh7thTManrNMICDuzadvJu8qXHub/S11lF9iDS4lG3Ouiu5MQEH4K
85BvAHbs0aycSpF+R/d1DQTEF4ProHwyM7AZQdc+tuGsNGw5f2vuUsKp53V52SH2
LxwMHBE6HueLP0f7qat8dAftmp4ge7ONN+BEeTV8LPjWyUn5fQfFumpCtdVp09pT
Xc5GvV/5nBS0DPhGJm/qUI9Jm/dMskYlqaesoYLNfqzKiBn0a7IViIEsn1AsHQZu
L2gyNw3Pl/+tU+6TLh/hbQNha+E84D7r+06sTgLxCle3uUxDXsZqY2pik0h6pH5H
oyzkwCA+3tk7svmkQsvzMK5HiEdB35tVTPCa9f8rDGMTktk6kP2hNFDTDB2U1cFS
vdemHx/M0HdQF22ZtDfGE/i3v0GS5n0Fks9CNW5I6MJ4MKOcSYI=
=Sa4E
-END PGP SIGNATURE-

Bug#1054032: rust-multihash: please update to v0.19.1

[Jonas Smedegaard]

Source: rust-multihash
Version: 0.19.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.19.1.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUtMYQACgkQLHwxRsGg
ASHgUw/+JoIEA8BEECP/oDnzmssWJTZNyrTvZsKzmyCxMnjcwVeZvjSjTnVP+1ss
hiZPj64wML3vJCZU2SBxJr1hXxq2vQinMdJJa7FGA0k2qUlVrWRb69JmNFlvwWLI
YrS5lTGD/YlxZFgwtqflvNRSpitE6I4kLsQQY4jT6AST/IzRMDDlnl9FfrPxb2pW
AGdM8rZwhpP3H7IZ+25tQ1I2fOG/3BAaaNDKOd31Tsuq0FYrMFG7zjWTxls+y+a3
AN9HOrNyll044pUlCcGQJsag9kn3r1KcOwqL46XbrRs13oMMLisMYPBxfYvZ3T8/
M61ujh493hvs/7UeLtYmYLowUKkvQZBPVFGbwcvRSqVEi6pLliJUzPr+NS8UQe2U
0wzZZG09/ZIUAfQuk6de8TWhCGA4kDrP1A/FBNO/hiiOpjpJoaxCpFTfj4Y/rHhO
Y8Br2VrIyesUn2JyI0yAHdnuKPyseDREjhLZ3C9uPR8I/3AK4Lx/JgUabPIG1Dya
MtIdJx1XDZINllJ19qE6d24HZt/IjuJBOgYPFyU5wBXVG1jlx+8dMVTvzJgwbnXn
wdQRMEgB/HkORUXVFFbnT9JCJGCvymIA7HMrbffYJ0ErjjBglz6gOnRB9Mcl6a2D
7gy2JsUqft+DYuTBXvn99gFfuHL3gf4vVSG9SVNpqQjscR6Ro+4=
=rZqI
-END PGP SIGNATURE-

Bug#1053656: Add support for loongarch64

[陈荔]

Dear maintainers,




For reviewing convenience, I have created a merge request :)  The URL is as 
following:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/121




Thanks.

Bug#1042405: [Debian-on-mobile-maintainers] Bug#1042405: squeekboard - updating to serde-yaml 0.9

[Arnaud Ferraris]

Hi,

Le 27/07/2023 à 20:17, Peter Green a écrit :

Package: squeekboard
Severity: important
Tags: trixie, sid

The rust team are currently looking at updating serde-yaml to 0.9.x
(specifically 0.9.21).

I tried patching squeekboard to use the new version but I get a bunch
of test failures. Can someone who is familiar with the codebase take
a look. I've uploaded the new rust-serde-yaml to experimental so
people can test against it.

 1/67 test_layout_ch_wide FAIL 1.55s exit 
status 101
 2/67 test_layout_am+phonetic FAIL 1.57s exit 
status 101
 3/67 test_layout_ch+de   FAIL 1.56s exit 
status 101
 4/67 test_layout_bg+phonetic FAIL 1.58s exit 
status 101
 5/67 test_layout_be  FAIL 1.59s exit 
status 101
 6/67 rstest  FAIL 1.61s exit 
status 101


etc

Debdiff attatched, obviously I won't NMU it in it's current form.


I finally had some time to look at this issue, for which I have a 
fix[1], but I'd rather check with upstream how to proceed here.


It turns out serde_yaml now has specific expectations for handling 
enums, which require patching the keyboard layouts quite extensively; 
this also affects custom user-defined layout files, which would likely 
cause *some* breakages among squeekboard users.


Cheers,
Arnaud

[1]https://salsa.debian.org/DebianOnMobile-team/squeekboard/-/commit/07dc2c103453f61674b4a1c7f24421a142e4c22e



___
Debian-on-mobile-maintainers mailing list
debian-on-mobile-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers




OpenPGP_0xD3EBB5966BB99196.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054031: calc: updated version 2.15.0.1 available

[James Dietrich]

Package: calc
Version: 2.12.7.2-4
Severity: normal

Just a note that a newer version of calc (2.15.0.1) is available. It 
would be good if this could be updated in Debian.


Thank you!

James Dietrich

Bug#1052312: cloudflare-ddns will FTFBS when systemd.pc changes the system unit? directory

[Helmut Grohne]

On Mon, Oct 16, 2023 at 09:28:08AM +0200, Andrea Pappacoda wrote:
> While this fixes this specific issue, other systemd-related paths are
> still hardcoded in the .install file. Is the approach you proposed here
> the only way? Should I manually export all the systemd pkg-config
> variables used in the upstream build system (sysusers.d, for instance)?

The paths below /lib are subject to move. For other paths, I am not
aware of such an intention. While you could discover them in a similar
way, I think that would be premature abstraction.

Besides units, what also will move is udev rules. Unfortunately, those
tend to be located in M-A:same packages and therefore require a more
elaborate mechanism for moving.

When more (types of) files are involved, I think the way to go is
dh_movetousr (which is not yet available in unstable). cloudflare-ddns
has received a patch, because this relatively simple mechanism was
sufficient to entirely solve it already. Once applied, a binNMU can
handle the conversion.

Helmut

Bug#1054010: [Pkg-utopia-maintainers] Bug#1054010: realmd: defer placement of systemd units to systemd.pc

[Helmut Grohne]

Hi Michael,

On Mon, Oct 16, 2023 at 11:12:39AM +0200, Michael Biebl wrote:
> configure.ac already contains
> 
> with_systemd_unit_dir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
> 
> so it is simpler to just use
> --with-systemd-unit-dir
> or --with-systemd-unit-dir=yes

Thanks for spotting this. I concur. I've seen other configure scripts
that don't work with the yes value, so this doesn't apply universally,
but it certainly does for realmd.

I also note (from kind feedback on #debian-devel) that the systemd-dev
dependency needs a "| systemd (<< 254.1-3~)" alternative to actually
become backportable with ease.

Helmut

Bug#1053099: cups-browsed: auto-detected color printers default to monochrome

[Stefan K]

I think this is already fixed, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039983
With version 2.4.7 it should be solved

Bug#1054030: tar: -P is "Don't strip leading slashes from file names when creating archives." but also disables stripping on extraxion

[наб]

Package: tar
Version: 1.34+dfsg-1.1
Severity: normal

Dear Maintainer,

As expected:
$ tar -cf ball.tar /bin/free
tar: Removing leading `/' from member names
$ tar -t < ball.tar
bin/free

$ tar -Pcf ball.tar /bin/free
$ tar -t < ball.tar
tar: Removing leading `/' from member names
/bin/free

However:
# tar -xvf /dev/vda
tar: Removing leading `/' from member names
/bin/free
# free
sh: free: command not found
# ls bin/free
bin/free

# tar -Pxvf /dev/vda
/bin/free
# free
free: error while loading shared libraries: libproc2.so.0: cannot open 
shared object file: No such file or directory

Best,
наб

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

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

Versions of packages tar depends on:
ii  libacl1  2.3.1-3
ii  libc62.37-12
ii  libselinux1  3.5-1

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip21.0.8-5+b1
pn  ncompress
pn  tar-doc  
pn  tar-scripts  
ii  xz-utils 5.4.4-0.1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1041731: Hyphens in man pages

[Colin Watson]

My plan, as indicated in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731#62, had been
to leave things much as they are for most of the period while trixie is
in development, and then put the ".char - \-" etc. workarounds back in
place for nroff output for trixie's release; this would have meant a
higher chance of more manual page authoring tools being updated to
handle the groff input language more strictly (although this isn't
always easy, as Russ has indicated, since sometimes the input languages
of those tools are less rich than groff).

However, after wading through an enormous amount of inordinately verbose
stuff in my inbox about this, I'm afraid I've now lost patience with the
whole thing and am definitely not willing to put up with it for another
year or more, so I'm putting the workaround back in place now.  Sorry to
anyone who will end up dissatisfied by non-terminal printed output as a
result.

  https://salsa.debian.org/debian/groff/-/commit/d5394c68d7

It is still true that being strict about the use of the "\-", "\[aq]",
"\[ga]", "\[ha]", and "\[ti]" escape sequences (as opposed to "-", "'",
"`", "^", and "~" respectively) will produce better printed output.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars

[Xiyue Deng]

Sean Whitton  writes:

> Hello,
>
> On Sun 15 Oct 2023 at 10:46pm -07, Xiyue Deng wrote:
>
>> Sean Whitton  writes:
>>
>>> Hello,
>>>
>>> On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote:
>>>
 Hello,

 On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote:

> Sure!  It's at https://salsa.debian.org/manphiz/bison-mode.  FYI I have
> also filed an RFS bug#1053987.

 Alright, pushed that to a team repo, let's work from there.
>>>
>>> It would be a good idea to push upstream's git tags to the repo, so that
>>> I can just type 'git deborig'.
>>
>> Done.  The `upstream' branch should be available now.
>
> I did mean the tags -- I myself prefer not to push an upstream branch.
> The idea is that from our point of view the upstream source is
> immutable, like tags, and unlike branches.  But of course it's fine to
> have one.

Looks like I got confused about what you suggested as there was a "0.3"
tag that was from the upstream repo which I assume "git deborig" can use
so I thought an "upstream" may help more.

I've now also pushed an "upstream/0.3" tag at the commit that matches
the "0.3" tag, but not sure whether this is what you were referring to.
If this works better I can remove the upstream branch to avoid further
complications.  Please advice.  Thanks!

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars

[Sean Whitton]

Hello,

On Sun 15 Oct 2023 at 10:45pm -07, Xiyue Deng wrote:

> Ah I see.  So for d/copyright we need to stick to the source
> information.  Dropped Wilfred from the list of copyright holders for
> now.  Also opened a PR upstream for tracking[1].

Cool.  Just to note, in your commit message you wrote that he's not a
copyright holder yet, but we can't assert that -- in fact, he probably
is a copyright holder.  You could have written that he's not
/documented/ as a copyright holder.

> As this is the first time I attempt of ITP/RFS, I'd like to go over the
> steps for packaging as much as possible if OK.  But AIUI this package
> will need to go through the NEW queue, so I guess if you sponsor my
> upload to mentors.d.n it may require some extra steps, then I'm OK if
> what you propose can save some trouble.

Okay, go ahead and let me know when you've done 'dch -r'.

I will still work out of git, so please don't push a signed tag there.
See dgit-sponsorship(7) for more.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1037439: Unlikely to be a bug in r-base

[Dirk Eddelbuettel]

On 16 October 2023 at 11:41, Andreas Beckmann wrote:
| On 05/10/2023 17.05, Dirk Eddelbuettel wrote:
| > 
| > Andreas,
| > 
| > This looks like an error:
| > 
| >  > reassign 1037439 src:r-base
| >  Bug #1037439 {Done: Dirk Eddelbuettel } 
[r-cran-rstan] r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 
1.81
| >  Bug reassigned from package 'r-cran-rstan' to 'src:r-base'.
| >  No longer marked as found in versions r-cran-rstan/2.21.8-1 and 
r-cran-bh.
| > 
| > r-base-core cannot possibly be the cause.  What we have here is that
| 
| This bug was marked as fixed (IIRC by a boost version bump) by some 
| version in (src:)r-base while it was reportted against another (source) 
| package. As this prevents bug archival (the BTS considers the bug not 
| yet fixed in the originally reported package), I reassigned the bug to 
| make the BTS happy.

Ahhh -- perfect, and sorry about possibly having created that confusion from
the r-base side.

There ~is~ was still something [else] wrong because a package ~has~ had a
hickup with Boost on one arch which then bubbles up to a current autoremmove
for six or seven packages of mine. [Just checked: Looks like that is taken
care of too so all good!

Thanks again, and cheers from Italy during a brief vacation.

Dirk
| 
| Andreas

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

Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars

[Sean Whitton]

Hello,

On Sun 15 Oct 2023 at 10:46pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello,
>>
>> On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote:
>>
>>> Hello,
>>>
>>> On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote:
>>>
 Sure!  It's at https://salsa.debian.org/manphiz/bison-mode.  FYI I have
 also filed an RFS bug#1053987.
>>>
>>> Alright, pushed that to a team repo, let's work from there.
>>
>> It would be a good idea to push upstream's git tags to the repo, so that
>> I can just type 'git deborig'.
>
> Done.  The `upstream' branch should be available now.

I did mean the tags -- I myself prefer not to push an upstream branch.
The idea is that from our point of view the upstream source is
immutable, like tags, and unlike branches.  But of course it's fine to
have one.

-- 
Sean Whitton


signature.asc
Description: PGP signature