Bug#1068051: tilix: FTBFS on armhf, s390x (undefined reference to `_D4core8internal5array8equality...)

[Kentaro HAYASHI]

Source: tilix
Severity: serious
Tags: ftbfs
Control: found -1 1.9.6-2
X-Debbugs-Cc: ken...@xdump.org

Dear Maintainer,

tilix fails to build on armhf, s390x.

FYI:

https://buildd.debian.org/status/fetch.php?pkg=tilix=armhf=1.9.6-2=1711367535=0
https://buildd.debian.org/status/fetch.php?pkg=tilix=s390x=1.9.6-2=1711187230=0

Regards,

Bug#1068050: RFS: gtkgreet/0.8-1 [ITP] -- GTK based greeter for greetd

[Maytham Alsudany]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : gtkgreet
   Version  : 0.8-1
   Upstream contact : Kenny Levinsen <~kennylevinsen/greetd-de...@lists.sr.ht>
 * URL  : https://git.sr.ht/~kennylevinsen/gtkgreet
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/Maytha8/gtkgreet
   Section  : utils

The source builds the following binary packages:

  gtkgreet - GTK based greeter for greetd

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gtkgreet/gtkgreet_0.8-1.dsc

Changes for the initial release:

 gtkgreet (0.8-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1065734)

Regards,
-- 
  Maytham Alsudany


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

Bug#1068049: update firefox-esr-mobile-config to latest upstream version

[Pirate Praveen]

Package: firefox-esr-mobile-config
Version: 4.2.0-1

This release includes fixes for extensions like browserpass

Bug#1068047: Suspicious commit merged in 2021 from account responsible for xz backdoor

[Wesley Schwengle]

On Fri, Mar 29, 2024 at 07:24:13PM -0700, Russ Allbery wrote:

> So far it looks like no one has been able to figure out an obvious way
> for this to be exploitable, but I wanted to make sure that you were
> aware of this upstream issue:
> 
> https://github.com/libarchive/libarchive/pull/1609
> 
> The author of this commit is the same GitHub account that was used to
> create the xz backdoor. Upstream has merged a revert of this change at:
> 
> https://github.com/libarchive/libarchive/pull/2101
> 
> It may be worth expediting getting this change into Debian in case the
> potential attacker knows something that we don't. However, I don't have
> any reason to currently believe that this is a security vulnerability,
> so I've kept the severity at important and not applied the security tag.

I also noticed this, I send an e-mail to secur...@debian.org about it,
921847da-a715-42c4-b87d-e8a1f0fb5...@schwengle.net. FWIW, this also impacts
Debian stable. The commit can be found in tags: v3.7.2 v3.7.1 v3.7.0 v3.6.2
v3.6.1 v3.6.0. Debian stable ships 3.6.2-1

Cheers,
Wesley

Bug#1068017: util-linux: please ship liblastlog2 packages

[Steve Langasek]

On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote:
> Hi OpenSSH, shadow Maintainers,
> 
> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > > It seems desirable to ship liblastlog2 in trixie, considering that the
> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > > recorded in /var/log/lastlog.

> [..]
> > At the same time, all traditional writing to /var/log/lastlog should
> > stop.

> > So, after some of the current fog clears, src:util-linux could
> > introduce new binary packages (at least libpam-lastlog2), but
> > src:pam would need to add it to the common-* config files.

> > Does this seem right?

> Answering my own question, not quite.

> Apparently, traditionally we have:

> * sshd writes to /var/log/lastlog by itself.
> * login has pam_lastlog.so in its PAM snippet. 

> Both of these would need to be replaced by pam_lastlog2.so. I don't
> really know what the other distros are doing right now, and/or if
> we should align on this.

> So we could either put pam_lastlog2.so into a common-* file from
> src:pam, or openssh and shadow should switch their setup.

> What do we all think about that?

pam should not be adding any modules to common-* that it itself does not
ship.  Instead they should be added via pam-auth-config.

I don't have an opinion about this being done in common-* vs being done in
sshd+login particularly; but putting it to common-* by default seems a
behavior change that warrants broader discussion e.g.  debian-devel.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1068042: elpa-magit-forge: forge-pull fails to get issues from salsa.debian.org

[Aymeric Agon-Rambosson]

Hello,

I had noticed in December of 2023 that forge was basically 
incapable of pulling anything (from github that time).


I had solved the issue by updating it to a newer upstream 
snapshot.


Now, for various reasons, this update has not been pushed to the 
archive yet, but it should be soon (the relevant commits have now 
been pushed to salsa).


I would be curious whether you can still reproduce the problem 
after updating to 0.3.2+git20231227.1.299bbaa-1, once it gets 
uploaded.


Sorry for the inconvenience.

Best,

Aymeric, of the debian-emacsen team

Le vendredi 29 mars 2024 à 18:12, Daniel Kahn Gillmor 
 a écrit :



[[PGP Signed Part:Undecided]]
Package: elpa-magit-forge
Version: 0.3.2-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I'm trying to do some work on impass, which is publicly hosted 
on

salsa.debian.org.

From emacs, i'm using forge in my working copy of the impass git 
repo,

and i've configured ~/.gitconfig to have:

```
[gitlab "salsa.debian.org/api/v4"]
user = dkg
```

In my local working copy's .git/config i have:

```
[remote "salsa"]
url = https://salsa.debian.org/debian/impass.git
fetch = +refs/heads/*:refs/remotes/salsa/*
pushurl = g...@salsa.debian.org:debian/impass.git
fetch = +refs/merge-requests/*/head:refs/pullreqs/*
[forge]
remote = salsa
```

However, when i try to do M-x forge-pull, i end up with this 
error

message:

```
Pulling debian/impass...
Pulling debian/impass issues...
error in process filter: ghub--errorback: HTTP Error: 400, "Bad 
Request", 
"/api/v4/projects/debian%2Fimpass/issues?per_page=100_by=updated_at_after=false", 
((error . "updated_after is invalid"))
error in process filter: HTTP Error: 400, "Bad Request", 
"/api/v4/projects/debian%2Fimpass/issues?per_page=100_by=updated_at_after=false", 
((error . "updated_after is invalid"))

```

If this is a bug on the salsa.debian.org side, feel free to 
reassign to

the appropriate metapackage.

--dkg

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

Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

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

Versions of packages elpa-magit-forge depends on:
ii  dh-elpa-helper   2.0.17
ii  elpa-closql  1.2.1-3
ii  elpa-dash2.19.1+git20220608.1.0ac1ecf+dfsg-1
ii  elpa-emacsql-sqlite  3.1.1+git20230417.6401226+ds-1
ii  elpa-ghub3.6.0-4
ii  elpa-let-alist   1.0.6-2
ii  elpa-magit   3.3.0-3
ii  elpa-markdown-mode   2.6-1
ii  elpa-yaml0.5.5-1
ii  emacsen-common   3.0.5

Versions of packages elpa-magit-forge recommends:
ii  emacs   1:29.2+1-2
ii  emacs-pgtk [emacs]  1:29.2+1-2

elpa-magit-forge suggests no packages.

-- no debconf information

[[End of PGP Signed Part]]

Bug#1068024: Or remove xz altogether?

[Guillem Jover]

On Sat, 2024-03-30 at 00:48:34 +, Stephan Verbücheln wrote:
> Maybe the people who criticized xz back in the day for being an amateur
> project implementing a defective file format were right all along?
> 
> https://www.nongnu.org/lzip/xz_inadequate.html

*Sigh*, the current situation is bad enough, and has nothing to do
with the xz format or design, or the FUD and propaganda from that
link. Please drop it…

Thanks,
Guillem

Bug#1068024: revert to version that does not contain changes by bad actor

[Mark-Oliver Wolter]

On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno  
wrote:

> Having dpkg in that list means that such downgrade has to be planned
> carefully.

Might be easier overall to spend that effort on a hard switch to zstd 
instead.


mfG mow

Bug#1068048: ITA: gnu-which -- Utility to show the full path of commands

[Zachary Liebl]

Package: wnpp
Severity: normal
Owner: Zachary Liebl 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@zachliebl.com

  Package name: gnu-which
  Version : 2.21+dfsg-2
  Upstream Contact: Carlo Wood 
  URL : https://savannah.gnu.org/projects/which
  License : GPL-3+
  Programming Lang: C
  Description : Utility to show the full path of commands

This package provides the classic unix "which" command.

It has recently been orphaned and I intend to adopt it. I have contacted the 
original debian maintainer and he as approved of this. 

This will be my first time maintaining a package, so I intentionally chose a 
simple one.


The package description is:
 This package provides GNU implementation of which command.
 This tool provides the functionality to show the full path
 of commands.

From,
Zachary Liebl

Bug#1068047: Suspicious commit merged in 2021 from account responsible for xz backdoor

[Russ Allbery]

Package: libarchive13t64
Version: 3.7.2-1.1
Severity: important
X-Debbugs-Cc: r...@debian.org

So far it looks like no one has been able to figure out an obvious way
for this to be exploitable, but I wanted to make sure that you were
aware of this upstream issue:

https://github.com/libarchive/libarchive/pull/1609

The author of this commit is the same GitHub account that was used to
create the xz backdoor. Upstream has merged a revert of this change at:

https://github.com/libarchive/libarchive/pull/2101

It may be worth expediting getting this change into Debian in case the
potential attacker knows something that we don't. However, I don't have
any reason to currently believe that this is a security vulnerability,
so I've kept the severity at important and not applied the security tag.


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

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

Versions of packages libarchive13t64 depends on:
ii  libacl12.3.2-1
ii  libbz2-1.0 1.0.8-5.1
ii  libc6  2.37-15.1
ii  liblz4-1   1.9.4-1+b2
ii  liblzma5   5.6.1+really5.4.5-1
ii  libnettle8t64  3.9.1-2.2
ii  libxml22.9.14+dfsg-1.3+b2
ii  libzstd1   1.5.5+dfsg2-2
ii  zlib1g 1:1.3.dfsg-3.1

libarchive13t64 recommends no packages.

Versions of packages libarchive13t64 suggests:
pn  lrzip  

-- no debconf information

Bug#1068022: Document the Testsuite-Triggers field

[Sean Whitton]

Hello,

On Fri 29 Mar 2024 at 08:30pm +01, Christian Kastner wrote:

> Package: debian-policy
> Version: 4.6.2.0
> Severity: wishlist
>
> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
> Testsuite-Triggers field that seems to be part of Sources files and is
> generated by dpkg-source >= 1.18.8.
>
> This field is quite useful, as given my package src:foo, I can find out
> which packages have autopkgtests that depend on it, and are thus in the
> set of reverse dependencies that I could check for breakage.
>
> I'd provide a patch based on the documentation in dsc(5), but I don't
> know what the current process is. Does anyone have a link to a doc on
> how to submit a change?

There is a chapter of Policy regarding the Policy Changes Process.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068046: /etc/firehol/ifupdown-firehol.sh: 71: [: -o: unexpected operator

[Jan Petykiewicz]

Package: firehol
Version: 3.1.7+ds-3
Severity: normal
X-Debbugs-Cc: jspam+...@mpxd.net

Dear Maintainer,

When running ifup / ifdown, I run into error messages along the lines of

/etc/network/if-up.d/firehol: 71: [: -o: unexpected operator
/etc/network/if-pre-up.d/zz-firehol: 71: [: -o: unexpected operator
/etc/network/if-up.d/firehol: 71: [: -o: unexpected operator

I've worked around them locally by modifying /etc/firehol/ifupdown-firehol.sh to
run using /bin/bash rather than /bin/sh, but there may be a better solution.

Thanks,
Jan


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

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

Versions of packages firehol depends on:
ii  firehol-common   3.1.7+ds-3
ii  init-system-helpers  1.66

Versions of packages firehol recommends:
ii  fireqos  3.1.7+ds-3

Versions of packages firehol suggests:
pn  firehol-doc
pn  firehol-tools  
pn  ulogd2 

-- Configuration Files:
/etc/default/firehol changed [not included]
/etc/firehol/firehol.conf changed [not included]
/etc/firehol/ifupdown-firehol.sh changed [not included]

-- no debconf information

Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Package: libssl3
Version: 3.0.13-1~deb12u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@security.debian.org
Control: affects -1 + yapet

Dear maintainer,

This version of libssl3 from bookworm-proposed-updates breaks YAPET.
When I try to open my passwords database, it claims the master password I type
is incorrect.  But downgrading libssl3 fixes the problem.

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

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

Versions of packages libssl3 depends on:
ii  libc6  2.36-9+deb12u5

libssl3 recommends no packages.

libssl3 suggests no packages.

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Serge E. Hallyn]

On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote:
> Hi OpenSSH, shadow Maintainers,
> 
> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > > It seems desirable to ship liblastlog2 in trixie, considering that the
> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > > recorded in /var/log/lastlog.
> > 
> [..]
> > At the same time, all traditional writing to /var/log/lastlog should
> > stop.
> > 
> > So, after some of the current fog clears, src:util-linux could
> > introduce new binary packages (at least libpam-lastlog2), but
> > src:pam would need to add it to the common-* config files.
> > 
> > Does this seem right?
> 
> Answering my own question, not quite.
> 
> Apparently, traditionally we have:
> 
> * sshd writes to /var/log/lastlog by itself.
> * login has pam_lastlog.so in its PAM snippet. 
> 
> Both of these would need to be replaced by pam_lastlog2.so. I don't
> really know what the other distros are doing right now, and/or if
> we should align on this.
> 
> So we could either put pam_lastlog2.so into a common-* file from
> src:pam, or openssh and shadow should switch their setup.
> 
> What do we all think about that?

Hi Chris,

It doesn't look like upstream shadow is specifying pam_lastlog.so,
but debian login does.

Putting pam_lastlog2.so into a common-* from src:pam sounds like a good
solution.

thanks,
-serge

Bug#1068024: Or remove xz altogether?

[Stephan Verbücheln]

Maybe the people who criticized xz back in the day for being an amateur
project implementing a defective file format were right all along?

https://www.nongnu.org/lzip/xz_inadequate.html

Regards
Stephan

Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi OpenSSH, shadow Maintainers,

On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > It seems desirable to ship liblastlog2 in trixie, considering that the
> > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > recorded in /var/log/lastlog.
> 
[..]
> At the same time, all traditional writing to /var/log/lastlog should
> stop.
> 
> So, after some of the current fog clears, src:util-linux could
> introduce new binary packages (at least libpam-lastlog2), but
> src:pam would need to add it to the common-* config files.
> 
> Does this seem right?

Answering my own question, not quite.

Apparently, traditionally we have:

* sshd writes to /var/log/lastlog by itself.
* login has pam_lastlog.so in its PAM snippet. 

Both of these would need to be replaced by pam_lastlog2.so. I don't
really know what the other distros are doing right now, and/or if
we should align on this.

So we could either put pam_lastlog2.so into a common-* file from
src:pam, or openssh and shadow should switch their setup.

What do we all think about that?

Chris

Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi Sven,
Hi Sam, Steve,

On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> It seems desirable to ship liblastlog2 in trixie, considering that the
> /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> recorded in /var/log/lastlog.
> 
> I have not looked closely yet, but I guess that would mean additional
> packages liblastlog2-2 for the library, liblastlog2-dev for the
> development files and libpam-lastlog2 for the pam module.  The lastlog2
> binary could probably be included in util-linux-extra.

I generally agree that we should ship lastlog2 and the pam module.
But this needs to be happen coordinated with src:pam. Installing the
modules and the binary and not using them is not a good plan.
At the same time, all traditional writing to /var/log/lastlog should
stop.

So, after some of the current fog clears, src:util-linux could
introduce new binary packages (at least libpam-lastlog2), but
src:pam would need to add it to the common-* config files.

Does this seem right?

PAM Maintainers, do you agree with this plan? Which timing would
work for you?

Chris


PS: the bug never made it into my mailbox. If necessary, please poke
on IRC.

Bug#1068044: openssh-client: graphical prompting does not work on wayland systems without xwayland

[Daniel Kahn Gillmor]

Package: openssh-client
Version: 1:9.7p1-2+b1
Severity: normal
Tags: patch
Forwarded: https://github.com/openssh/openssh-portable/pull/479
X-Debbugs-Cc: Daniel Kahn Gillmor 

When using a wayland graphical environment without xwayland, at least
two different parts of OpenSSH decline to prompt the user graphically,
even if ssh-askpass-gnome is installed.  (and ssh-askpass-gnome works
cleanly on wayland without xwayland).

The two places that i've noticed that don't prompt are:

- when a key has been added to ssh-agent with `-c` the confirmation
  prompt for use doesn't show.

- when a multiplexed ssh session with `ControlMaster=ask` or
  `ControlMaster=autoask` is configured and another ssh session wants to
  connect over it.


In both locations, ssh-askpass isn't used because the environment
variable DISPLAY isn't set.  I would guess that early adopters of
wayland who have declined to run XWayland have all just shrugged and
worked around this by manually setting SSH_ASKPASS_REQUIRE=force, or to
spuriously setting DISPLAY or something like that as a workaround.

But the tools should really be friendlier to this environment.

I think the attached patch, which i've also offered upstream, should
enable this use case.

   --dkg


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

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

Versions of packages openssh-client depends on:
ii  adduser   3.137
ii  libc6 2.37-15
ii  libedit2  3.1-20230828-1
ii  libfido2-11.14.0-1
ii  libgssapi-krb5-2  1.20.1-5+b1
ii  libselinux1   3.5-2
ii  libssl3t643.1.5-1.1
ii  passwd1:4.13+dfsg1-4
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1

Versions of packages openssh-client suggests:
pn  keychain 
pn  libpam-ssh   
ii  monkeysphere 0.44-1
ii  ssh-askpass-gnome [ssh-askpass]  1:9.6p1-4

-- no debconf information

From bb3412c842c8c3dc98c1e0643905229ed3fa7a6c Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 28 Mar 2024 16:22:41 -0400
Subject: [PATCH] Allow ssh-askpass on Wayland by checking for $WAYLAND_DISPLAY

Currently, no part of ssh (including the agent!) will even consider
running ssh-askpass unless $DISPLAY is set.  But some systems run a
graphical environment (e.g. Wayland) where some versions of
ssh-askpass (e.g. ssh-askpass-gnome) will still work just fine.

So expand this baseline check to to permit invoking ssh-askpass if the
sentinel wayland environment variable is present as well.
---
 readpass.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/readpass.c b/readpass.c
index b52f3d6b1..5e5cad29c 100644
--- a/readpass.c
+++ b/readpass.c
@@ -127,8 +127,9 @@ read_passphrase(const char *prompt, int flags)
 	const char *askpass_hint = NULL;
 	const char *s;
 
-	if ((s = getenv("DISPLAY")) != NULL)
-		allow_askpass = *s != '\0';
+	if s = getenv("DISPLAY")) != NULL) && (*s != '\0')) ||
+(((s = getenv("WAYLAND_DISPLAY")) != NULL) && (*s != '\0')))
+		allow_askpass = 1;
 	if ((s = getenv(SSH_ASKPASS_REQUIRE_ENV)) != NULL) {
 		if (strcasecmp(s, "force") == 0) {
 			use_askpass = 1;
@@ -262,6 +263,7 @@ notify_start(int force_askpass, const char *fmt, ...)
 		goto out;
 	}
 	if (getenv("DISPLAY") == NULL &&
+getenv("WAYLAND_DISPLAY") == NULL &&
 	((s = getenv(SSH_ASKPASS_REQUIRE_ENV)) == NULL ||
 	strcmp(s, "force") != 0)) {
 		debug3_f("cannot notify: no display");
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Thu, 28 Mar 2024 17:50:34 +0100 Christian Kastner wrote:

[...]
> Though if I understand #1061816 correctly, then this should probably be
> a separate bug, right? (Wanted to check before I clone)

Why?

I unarchived and reopened this bug report, since I found another
reason why sbuild-qemu-update cannot update a VM image created with
mmdebstrap-autopkgtest-build-qemu.

I think this bug report can be closed, once sbuild-qemu-update is able
to update such a VM image.
I don't think there's any need to clone any bug report here...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgptijtSQz_7B.pgp
Description: PGP signature

Bug#1061816: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Thu, 28 Mar 2024 10:05:53 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Could you temporarily add a symlink from OVMF_CODE.fd to OVMF_CODE_4M.fd and
> check if it still works?

Well, apparently it works:

  # ln -s /usr/share/OVMF/OVMF_CODE_4M.fd /usr/share/OVMF/OVMF_CODE.fd
  # exit
  $ sbuild-qemu-update --boot=efi ~/var/cache/sbuild/sid-amd64.img
  qemu-system-x86_64 -enable-kvm -drive 
if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE.fd 
-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
user,model=virtio -m 1024 -smp 1 -nographic 
/home/frx/var/cache/sbuild/sid-amd64.img
  root
  Linux host 6.7.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.9-2 (2024-03-13) 
x86_64
  
  The programs included with the Debian GNU/Linux system are free software;
  the exact distribution terms for each program are described in the
  individual files in /usr/share/doc/*/copyright.
  
  Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  permitted by applicable law.
  root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet update
  DEBIAN_FRONTEND=noninteractive apt-get --quiet update
  Get:1 http://deb.debian.org/debian sid InRelease [198 kB]
  [...]
  DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes autoremove
  Reading package lists...
  Building dependency tree...
  Reading state information...
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  root@host:~# sync
  sync
  root@host:~# sleep 1
  sleep 1
  root@host:~# shutdown -h now



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp0xEUTcoqGC.pgp
Description: PGP signature

Bug#1068024: revert to version that does not contain changes by bad actor

[Thorsten Glaser]

Aurelien Jarno dixit:

>Having dpkg in that list means that such downgrade has to be planned
>carefully.

Right. Not an argument against, though.
Instead, this is a very good idea.

What symbols are new? Can we somehow stub them, or at least where
those are used? Or change the soname, so that the old and new-older
versions are coïnstallable for during the upgrade?

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#1068043: BinNMU 1.11-1+b1 depends on both, libmspack0 and libmspack0t64, and is hence uninstallable (at least on armhf)

[Axel Beckert]

Package: cabextract
Version: 1.11-1
Severity: serious
X-Debbugs-Cc: a...@debian.org

>From aptitude's dependency view on armhf:

iFA (pin --\ cabextract   0   72.7 kB  1.11-1  1.11-1+b1
  --\ Depends (3)
--- libc6 (>= 2.34)
--- libmspack0 (>= 0.9.1-1)
--- libmspack0t64 (>= 0.4) (UNSATISFIED)

As libmspack0t64 breaks libmspack0 they can't be installed together.

This is likely caused by hardcoding a dependency on libmspack0 in
debian/control:

https://sources.debian.org/src/cabextract/1.11-1/debian/control/#L10

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'testing'), (110, 'experimental'), (1, 
'experimental-debug'), (1, 'buildd-experimental')
Architecture: armhf (armv7l)

Kernel: Linux 6.6.15-armmp-lpae (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages cabextract depends on:
ii  libc6   2.37-15.1
ii  libmspack0  0.11-1

cabextract recommends no packages.

cabextract suggests no packages.

-- no debconf information

Bug#1068042: elpa-magit-forge: forge-pull fails to get issues from salsa.debian.org

[Daniel Kahn Gillmor]

Package: elpa-magit-forge
Version: 0.3.2-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I'm trying to do some work on impass, which is publicly hosted on
salsa.debian.org.

From emacs, i'm using forge in my working copy of the impass git repo,
and i've configured ~/.gitconfig to have:

```
[gitlab "salsa.debian.org/api/v4"]
user = dkg
```

In my local working copy's .git/config i have:

```
[remote "salsa"]
url = https://salsa.debian.org/debian/impass.git
fetch = +refs/heads/*:refs/remotes/salsa/*
pushurl = g...@salsa.debian.org:debian/impass.git
fetch = +refs/merge-requests/*/head:refs/pullreqs/*
[forge]
remote = salsa
```

However, when i try to do M-x forge-pull, i end up with this error
message:

```
Pulling debian/impass...
Pulling debian/impass issues...
error in process filter: ghub--errorback: HTTP Error: 400, "Bad Request", 
"/api/v4/projects/debian%2Fimpass/issues?per_page=100_by=updated_at_after=false",
 ((error . "updated_after is invalid"))
error in process filter: HTTP Error: 400, "Bad Request", 
"/api/v4/projects/debian%2Fimpass/issues?per_page=100_by=updated_at_after=false",
 ((error . "updated_after is invalid"))
```

If this is a bug on the salsa.debian.org side, feel free to reassign to
the appropriate metapackage.

--dkg

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

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

Versions of packages elpa-magit-forge depends on:
ii  dh-elpa-helper   2.0.17
ii  elpa-closql  1.2.1-3
ii  elpa-dash2.19.1+git20220608.1.0ac1ecf+dfsg-1
ii  elpa-emacsql-sqlite  3.1.1+git20230417.6401226+ds-1
ii  elpa-ghub3.6.0-4
ii  elpa-let-alist   1.0.6-2
ii  elpa-magit   3.3.0-3
ii  elpa-markdown-mode   2.6-1
ii  elpa-yaml0.5.5-1
ii  emacsen-common   3.0.5

Versions of packages elpa-magit-forge recommends:
ii  emacs   1:29.2+1-2
ii  emacs-pgtk [emacs]  1:29.2+1-2

elpa-magit-forge suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1067946: dietlibc: Includes non-free Sun RPC

[Thorsten Glaser]

Bastian Germann dixit:

>dietlibc includes the sunrpc code from old glibc versions, which is
>demonstrated to be non-free in #181493.

The text in dietlibc reads thusly though:

  Users
 * may copy or modify Sun RPC without charge, but are not authorized
 * to license or distribute it to anyone else except as part of a product or
 * program developed by the user.

One could argue that dietlibc is a product developed by Fefe,
who then licences and distributes it (under GPL) to others,
which (as long as that notice is included) is covered. I see
dancer already said so, and…

| Sun has repeatedly clarified elsewhere that the intent of this is
| essentially "MIT/X11, except you may not distribute this product
| alone."

… don’t we have other things like that in the archive, with
the justification that it’s trivial to add something to it.

And I don’t follow the others in that thread who think that
the licence of the product developed by the (first) user cannot
be transitive. Note both IANAL+TINLA, but so are the folks on
d-legal. The clarification by Sun also says so.

Not that I’m adverse to replacing things with better-licenced
things, but I don’t think it warrants rc-bugginess (the lack
of the licence in d/copyright does but is a different topic).


But…

>I have already informed upstream about it.

… this is where this is best dealt with. Thanks.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#1068014: urlwatch: Please replace python3-appdirs dependency with platformdirs

[Maxime Werlen]

Hi,

A new version with the fix has been release and is waiting on mentor to be
uploaded. Here is the BTS bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068039.

Regards

Maxime

Bug#1068041: kio: low throughput with server-side copy on nfs4.2

[Bob Rosbag]

Package: kio
Version: 5.103.0-1
Severity: normal
X-Debbugs-Cc: deb...@bobrosbag.nl

Dear Maintainer,

Copying a file from a nfs share on hd1 to a nfs share on hd2 on the same server
gives a low throughput with dolphin and krusader.

The server/NAS is Openmediavault 7 (Debian 12 based) but same problem was
present with Openmediavault 6 (Debian 11 based).


Dolphin/krusader from hd1 nfs share to hd2 nfs share on the same nas through
nfs:

nfs4.2:
9 MB/s

nfs4.1:
50 MB/s

Thunar has no problems with nfs4.2


I found one other case of this bug:

https://forum.openmediavault.org/index.php?thread/47985-issues-with-server-
side-copy-using-manjaro-client-and-dolphin-file-explorer/


Copying files from the client to the NAS works correctly with Dolphin (90
MB/s).

This seems to point to problems with the server-side copy / copy_file_range
implementation in kio.



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

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

Versions of packages kio depends on:
ii  kded5 5.103.0-1
ii  libacl1   2.3.1-3
ii  libc6 2.36-9+deb12u5
ii  libgcc-s1 12.2.0-14
ii  libgssapi-krb5-2  1.20.1-2+deb12u1
ii  libkf5archive55.103.0-1
ii  libkf5authcore5   5.103.0-1
ii  libkf5configcore5 5.103.0-2
ii  libkf5configwidgets5  5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5dbusaddons5 5.103.0-1
ii  libkf5doctools5   5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libkf5itemviews5  5.103.0-1
ii  libkf5kiocore55.103.0-1
ii  libkf5kiogui5 5.103.0-1
ii  libkf5kiontlm55.103.0-1
ii  libkf5kiowidgets5 5.103.0-1
ii  libkf5notifications5  5.103.0-1
ii  libkf5service-bin 5.103.0-1
ii  libkf5service55.103.0-1
ii  libkf5solid5  5.103.0-1
ii  libkf5textwidgets55.103.0-1
ii  libkf5wallet-bin  5.103.0-1
ii  libkf5wallet5 5.103.0-1
ii  libkf5widgetsaddons5  5.103.0-1
ii  libkf5windowsystem5   5.103.0-1
ii  libqt5core5a  5.15.8+dfsg-11
ii  libqt5dbus5   5.15.8+dfsg-11
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5network55.15.8+dfsg-11
ii  libqt5qml55.15.8+dfsg-3
ii  libqt5widgets55.15.8+dfsg-11
ii  libqt5x11extras5  5.15.8-2
ii  libqt5xml55.15.8+dfsg-11
ii  libstdc++612.2.0-14
ii  libxml2   2.9.14+dfsg-1.3~deb12u1
ii  libxslt1.11.1.35-1

Versions of packages kio recommends:
ii  systemsettings  4:5.27.5-2

kio suggests no packages.

-- no debconf information

Bug#1068024: revert to version that does not contain changes by bad actor

[Aurelien Jarno]

On 2024-03-29 16:25, Joey Hess wrote:
> I'd suggest reverting to 5.3.1. Bearing in mind that there were security
> fixes after that point for ZDI-CAN-16587 that would need to be reapplied.

Note that reverted to such an old version will break packages that use
new symbols introduced since then. From a quick look, this is at least:
- dpkg
- erofs-utils
- kmod

Having dpkg in that list means that such downgrade has to be planned
carefully.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1064763: proposed fix

[Daniel Kondor]

Hi,

I have created a package with a proposed fix:
https://mentors.debian.net/package/cairo-dock-plug-ins/

The only changes from the current Debian package are:

1. Addition of one patch that replaces distutils with setuptools:
debian/patches/0011-Dbus-do-not-use-deprecated-distutils-Python-module.patch
debian/patches/series

2. Add build dependency on python3-setuptools:
debian/control

I have tested it with pbuilder, building for unstable / sid and was able 
to build successfully.


It would be great to resolve this so that cairo-dock could stay in Debian :)

Let me know if there is any other issue that I can help with!

Best,

Daniel

Bug#1067821: bookworm-pu: package nvidia-graphics-drivers/535.161.08-1~deb12u1

[Andreas Beckmann]

On 29/03/2024 19.40, Adam D. Barratt wrote:

libnvidia-pkcs11-openssl3 is a reverse dependency of libcuda1 (seems to 
get dlopen()ed by it), so we cannot avoid the openssl dependency without 
risking cuda breakage in sid.


Would uploading the 535 stack to testing-proposed-updates be helpful?


Would we be better to ship the 525 packages that are already in p-u and
revisit 535 for 12.7,


Then let's stick to the 525 from -pu for now and hope the 64bit time_t 
transition is over next time. ;-)



or skip those updates as well and just include
535 when we can?


The 525 packages are also in stable-updates for fixing module build 
breakage caused by some backported changes in src:linux in the last 
point release. So skipping them is no option ;-)



Andreas

PS: nvidia-modprobe should be independent of the driver stack and t64 
transition and could be included in 12.6

Bug#1059535: transition: abseil

[Benjamin Barenblat]

On Friday, March 29, 2024, at  1:02 PM +0100, Sebastian Ramacher wrote:
> Since the version in unstable fails to build on armel and armhf and
> blocks the time_t transition, but the version in experimental builds
> fine, let's do this transition now.
>
> With the upload to unstable, please check the FTBFS issue on risc64,
> though.

Sounds good. I never did get around to uploading 20240116 to
experimental. I’ll upload 20230802 to unstable this weekend, and I’ll
come back for 20240116 later.

Upstream has accepted [1], which should fix the FTBFS on riscv64. It
should be an easy backport to 20230802. I’ll make sure it’s included
when I do the upload this weekend.

[1] 
https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4

Bug#1068040: Update Build-Depends for the time64 library renames

[Andrey Rakhmatullin]

Source: deepin-deb-installer
Version: 5.12.4-1
Severity: serious
Tags: ftbfs

The package explicitly Build-Depends: libqt5concurrent5, libqt5widgets5, these
need to be changed to libfoot64 if they are needed at all.


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

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

Bug#1068039: RFS: urlwatch/2.28-3 -- monitors webpages for you

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : urlwatch
   Version  : 2.28-3
   Upstream contact : Thomas Perl 
 * URL  : https://thp.io/2008/urlwatch/
 * License  : BSD-3-clause
 * Vcs  : https://salsa.debian.org/mwerlen/urlwatch
   Section  : web

The source builds the following binary packages:

  urlwatch - monitors webpages for you

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.28-3.dsc

Changes since the last upload:

 urlwatch (2.28-3) unstable; urgency=medium
 .
   * Apply patch to switch from dead appdirs to platformdirs (Closes:
#1068014)
   * Update copyright years

Regards,

Bug#1068037: FTBFS: error: implicit declaration of function ‘get_file_lines’

[Andrey Rakhmatullin]

Source: mdk4
Version: 4.2-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=mdk4=arm64=4.2-3%2Bb2=1711715545=0

poc.c:148:30: error: implicit declaration of function ‘get_file_lines’
[-Werror=implicit-function-declaration]
  148 | file_lines = get_file_lines(file_name);
  |  ^~
poc.c:160:38: warning: pointer targets in passing argument 1 of ‘fgets’ differ
in signedness [-Wpointer-sign]
  160 | if(fgets(buf, sizeof(buf), fp1))
  |  ^~~
  |  |
  |  unsigned char *
In file included from /usr/include/stdio.h:906,
 from poc.c:1:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:209:25: note: expected ‘char *
restrict’ but argument is of type ‘unsigned char *’
  209 | fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
  |~^~~
poc.c:165:59: error: implicit declaration of function ‘str_to_hex’
[-Werror=implicit-function-declaration]
  165 | poc_pkts[i].pkts[j].len =
str_to_hex(buf, poc_pkts[i].pkts[j].data, sizeof(poc_pkts[i].pkts[j].data));
  |   ^~


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

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

Bug#1068036: FTBFS: no B-D: libtirpc-dev

[Andrey Rakhmatullin]

Source: snort
Version: 2.9.15.1-6
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=snort=arm64=2.9.15.1-6%2Bb4=1711721617=0

checking for bindresvport in -ltirpc... no
no

 ERROR! tirpc not found, get it by running
 apt install libtirpc-devel


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

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

Bug#1068038: FTBFS: error: ‘struct input_event’ has no member named ‘time’

[Andrey Rakhmatullin]

Source: flightgear
Version: 1:2020.3.18+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=flightgear=armhf=1%3A2020.3.18%2Bdfsg-1%2Bb2=1711729288=0

/<>/src/Input/FGLinuxEventInput.cxx: In member function ‘virtual
void FGLinuxInputDevice::Send(const char*, double)’:
/<>/src/Input/FGLinuxEventInput.cxx:418:7: error: ‘struct
input_event’ has no member named ‘time’
  418 |   evt.time.tv_sec = 0;
  |   ^~~~
/<>/src/Input/FGLinuxEventInput.cxx:419:7: error: ‘struct
input_event’ has no member named ‘time’
  419 |   evt.time.tv_usec = 0;
  |   ^~~~


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

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

Bug#1068035: FTBFS: wrong --link-doc target

[Andrey Rakhmatullin]

Source: mdbtools
Version: 1.0.0+dfsg-1.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=mdbtools=arm64=1.0.0%2Bdfsg-1.2%2Bb2=1711715505=0

dh_installdocs --no-package=mdbtools-doc --link-doc=libmdb3
dh_installdocs: error: Requested unknown package libmdb3 via --link-doc,
expected one of: mdbtools mdbtools-dev libmdb3t64 libmdbsql3t64 odbc-mdbtools
mdbtools-doc

It should be changed to libmdb3t64.


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

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

Bug#1068033: bookworm-pu: package gross/1.0.2-4.1~deb12u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Antonio Radici , t...@security.debian.org

  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)

This CVE is marked no-dsa.

Building with the bookworm debhelper adds a preinst due to #1021027.
diffstat for gross-1.0.2 gross-1.0.2

 changelog|   14 
 patches/0001-fix-misuse-of-strncat.patch |   95 +++
 patches/series   |1 
 3 files changed, 110 insertions(+)

diff -Nru gross-1.0.2/debian/changelog gross-1.0.2/debian/changelog
--- gross-1.0.2/debian/changelog2014-10-25 11:20:12.0 +0300
+++ gross-1.0.2/debian/changelog2024-03-29 22:52:55.0 +0200
@@ -1,3 +1,17 @@
+gross (1.0.2-4.1~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+
+ -- Adrian Bunk   Fri, 29 Mar 2024 22:52:55 +0200
+
+gross (1.0.2-4.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)
+
+ -- Adrian Bunk   Sat, 23 Mar 2024 23:23:34 +0200
+
 gross (1.0.2-4) unstable; urgency=low
 
   * debian/README: fixed a typo (Closes: 670596)
diff -Nru gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 
gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch
--- gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 1970-01-01 
02:00:00.0 +0200
+++ gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 2024-03-23 
23:23:34.0 +0200
@@ -0,0 +1,95 @@
+From ec697f4dd5b057ad5af17468dac7955f3d1c03c6 Mon Sep 17 00:00:00 2001
+From: Dmitry Mikhirev 
+Date: Wed, 27 Dec 2023 03:42:29 +0400
+Subject: fix misuse of strncat
+
+---
+ src/gross.c  | 11 ---
+ src/worker.c | 21 -
+ 2 files changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/src/gross.c b/src/gross.c
+index 6e1a277..f477845 100644
+--- a/src/gross.c
 b/src/gross.c
+@@ -111,7 +111,9 @@ configure_grossd(configlist_t *config)
+   configlist_t *cp;
+   const char *updatestr;
+   struct hostent *host = NULL;
+-  char buffer[MAXLINELEN] = { '\0' };
++  char buffer[MAXLINELEN];
++  char *lineend;
++  size_t len;
+   params_t *pp;
+ 
+   cp = config;
+@@ -119,11 +121,14 @@ configure_grossd(configlist_t *config)
+   while (cp) {
+   pp = cp->params;
+   *buffer = '\0';
++  lineend = buffer;
++  len = 0;
+   while (pp) {
+-  strncat(buffer, " ; ", MAXLINELEN - 1);
+-  strncat(buffer, pp->value, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, 
" ; %s", pp->value);
++  lineend = buffer + len;
+   pp = pp->next;
+   }
++  buffer[MAXLINELEN - 1] = '\0';
+   logstr(GLOG_DEBUG, "config: %s = %s%s", cp->name, 
cp->value, buffer);
+   cp = cp->next;
+   }
+diff --git a/src/worker.c b/src/worker.c
+index 24f104b..63c0f06 100644
+--- a/src/worker.c
 b/src/worker.c
+@@ -618,7 +618,8 @@ void
+ querylogwrite(querylog_entry_t *q)
+ {
+   char line[MAXLINELEN];
+-  char buffer[MAXLINELEN];
++  size_t len = 0;
++  char *lineend = line;
+   char *actionstr;
+   check_match_t *m;
+ 
+@@ -655,25 +656,27 @@ querylogwrite(querylog_entry_t *q)
+   if (NULL == q->recipient)
+   q->recipient = "N/A";
+ 
+-  snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,
+-  q->client_ip, q->sender, q->recipient);
++  len += snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,  q->client_ip, q->sender, q->recipient);
++  lineend = line +len;
+ 
+   if (q->helo) {
+-  snprintf(buffer, MAXLINELEN - 1, " h=%s", q->helo);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " h=%s", 
q->helo);
++  lineend = line + len;
+   }
+ 
+   m = q->match;
+   while (m) {
+-  snprintf(buffer, MAXLINELEN - 1, " m=%s", m->name);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " m=%s", 
m->name);
++  lineend = line + len;
+   if (m->weight) {
+-  snprintf(buffer, MAXLINELEN - 1, "%+d", m->weight);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, "%+d", 
m->weight);
++  lineend = line + len;
+   }
+   m = m->next;
+ 

Bug#1068034: bullseye-pu: package gross/1.0.2-4.1~deb11u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Antonio Radici , t...@security.debian.org

  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)

This CVE is marked no-dsa.
diffstat for gross-1.0.2 gross-1.0.2

 changelog|   14 
 patches/0001-fix-misuse-of-strncat.patch |   95 +++
 patches/series   |1 
 3 files changed, 110 insertions(+)

diff -Nru gross-1.0.2/debian/changelog gross-1.0.2/debian/changelog
--- gross-1.0.2/debian/changelog2014-10-25 11:20:12.0 +0300
+++ gross-1.0.2/debian/changelog2024-03-29 23:02:44.0 +0200
@@ -1,3 +1,17 @@
+gross (1.0.2-4.1~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+
+ -- Adrian Bunk   Fri, 29 Mar 2024 23:02:44 +0200
+
+gross (1.0.2-4.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2023-52159: Stack-based buffer overflow (Closes: #1067115)
+
+ -- Adrian Bunk   Sat, 23 Mar 2024 23:23:34 +0200
+
 gross (1.0.2-4) unstable; urgency=low
 
   * debian/README: fixed a typo (Closes: 670596)
diff -Nru gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 
gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch
--- gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 1970-01-01 
02:00:00.0 +0200
+++ gross-1.0.2/debian/patches/0001-fix-misuse-of-strncat.patch 2024-03-23 
23:23:34.0 +0200
@@ -0,0 +1,95 @@
+From ec697f4dd5b057ad5af17468dac7955f3d1c03c6 Mon Sep 17 00:00:00 2001
+From: Dmitry Mikhirev 
+Date: Wed, 27 Dec 2023 03:42:29 +0400
+Subject: fix misuse of strncat
+
+---
+ src/gross.c  | 11 ---
+ src/worker.c | 21 -
+ 2 files changed, 20 insertions(+), 12 deletions(-)
+
+diff --git a/src/gross.c b/src/gross.c
+index 6e1a277..f477845 100644
+--- a/src/gross.c
 b/src/gross.c
+@@ -111,7 +111,9 @@ configure_grossd(configlist_t *config)
+   configlist_t *cp;
+   const char *updatestr;
+   struct hostent *host = NULL;
+-  char buffer[MAXLINELEN] = { '\0' };
++  char buffer[MAXLINELEN];
++  char *lineend;
++  size_t len;
+   params_t *pp;
+ 
+   cp = config;
+@@ -119,11 +121,14 @@ configure_grossd(configlist_t *config)
+   while (cp) {
+   pp = cp->params;
+   *buffer = '\0';
++  lineend = buffer;
++  len = 0;
+   while (pp) {
+-  strncat(buffer, " ; ", MAXLINELEN - 1);
+-  strncat(buffer, pp->value, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, 
" ; %s", pp->value);
++  lineend = buffer + len;
+   pp = pp->next;
+   }
++  buffer[MAXLINELEN - 1] = '\0';
+   logstr(GLOG_DEBUG, "config: %s = %s%s", cp->name, 
cp->value, buffer);
+   cp = cp->next;
+   }
+diff --git a/src/worker.c b/src/worker.c
+index 24f104b..63c0f06 100644
+--- a/src/worker.c
 b/src/worker.c
+@@ -618,7 +618,8 @@ void
+ querylogwrite(querylog_entry_t *q)
+ {
+   char line[MAXLINELEN];
+-  char buffer[MAXLINELEN];
++  size_t len = 0;
++  char *lineend = line;
+   char *actionstr;
+   check_match_t *m;
+ 
+@@ -655,25 +656,27 @@ querylogwrite(querylog_entry_t *q)
+   if (NULL == q->recipient)
+   q->recipient = "N/A";
+ 
+-  snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,
+-  q->client_ip, q->sender, q->recipient);
++  len += snprintf(line, MAXLINELEN - 1, "a=%s d=%d w=%d c=%s s=%s r=%s", 
actionstr, q->delay, q->totalweight,  q->client_ip, q->sender, q->recipient);
++  lineend = line +len;
+ 
+   if (q->helo) {
+-  snprintf(buffer, MAXLINELEN - 1, " h=%s", q->helo);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " h=%s", 
q->helo);
++  lineend = line + len;
+   }
+ 
+   m = q->match;
+   while (m) {
+-  snprintf(buffer, MAXLINELEN - 1, " m=%s", m->name);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, " m=%s", 
m->name);
++  lineend = line + len;
+   if (m->weight) {
+-  snprintf(buffer, MAXLINELEN - 1, "%+d", m->weight);
+-  strncat(line, buffer, MAXLINELEN - 1);
++  len += snprintf(lineend, MAXLINELEN - len - 1, "%+d", 
m->weight);
++  lineend = line + len;
+   }
+   m = m->next;
+   }
+ 
++  line[MAXLINELEN - 1] = '\0';
++
+   

Bug#1068032: FTBFS: error: implicit declaration of function ‘FreeTextEvent’

[Andrey Rakhmatullin]

Source: stimfit
Version: 0.16.0-1.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=stimfit=arm64=0.16.0-1.2%2Bb5=1711722178=0

biosig4c++/t210/sopen_alpha_read.c: In function ‘sopen_alpha_read’:
biosig4c++/t210/sopen_alpha_read.c:381:41: error: implicit declaration of
function ‘FreeTextEvent’ [-Werror=implicit-function-declaration]
  381 | FreeTextEvent(hdr, n, t4);
  | ^
biosig4c++/t210/sopen_alpha_read.c:533:31: warning: assignment discards ‘const’
qualifier from pointer target type [-Wdiscarded-qualifiers]
  533 | hdr->FileName = FileName;
  |   ^
biosig4c++/t210/sopen_axg_read.c: In function ‘sopen_axg_read’:
biosig4c++/t210/sopen_axg_read.c:612:17: error: implicit declaration of
function ‘strptime’; did you mean ‘strftime’? [-Werror=implicit-function-
declaration]
  612 | strptime(strstr(Notes,"Created on ")+11, "%a %b %d %Y",
);
  | ^~~~
  | strftime


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

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

Bug#1068031: FTBFS: checking for locking method... configure: error: fcntl test failed

[Andrey Rakhmatullin]

Source: maildrop
Version: 2.9.3-2.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=maildrop=armel=2.9.3-2.1%2Bb2=1711722445=0

checking for locking method... configure: error: fcntl test failed.
configure: error: ./configure failed for libs/liblock



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

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

Bug#1068030: FTBFS on armel: undefined reference to `__atomic_load_8'

[Andrey Rakhmatullin]

Source: maildir-utils
Version: 1.10.8-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=maildir-
utils=armel=1.10.8-2%2Bb2=1711722478=0

/usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function
`std::__atomic_base::store(long long, std::memory_order)':
/usr/include/c++/13/bits/atomic_base.h:481:(.text+0xb14): undefined reference
to `__atomic_store_8'
/usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function
`std::__atomic_base::load(std::memory_order) const':
/usr/include/c++/13/bits/atomic_base.h:505:(.text+0x1384): undefined reference
to `__atomic_load_8'


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

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

Bug#1068029: FTBFS: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘time_t’ {aka ‘long long int’}

[Andrey Rakhmatullin]

Source: nfstrace
Version: 0.4.3.2+git20200805+b220d04-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=nfstrace=armhf=0.4.3.2%2Bgit20200805%2Bb220d04-3%2Bb2=1711734395=0

/<>/analyzers/src/watch/nc_windows/header_window.cpp: In member
function ‘void HeaderWindow::update()’:
/<>/analyzers/src/watch/nc_windows/header_window.cpp:77:83: error:
format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type
‘time_t’ {aka ‘long long int’} [-Werror=format=]
   77 | mvwprintw(_window, HEADER::ELAPSED_LINE, FIRST_CHAR_POS, "Elapsed
time:  \t %ld days; %ld:%ld:%ld times",
  |
~~^
  |
|
  |
long int
  |
%lld
   78 |   shift_time / SECINDAY, shift_time % SECINDAY / SECINHOUR,
shift_time % SECINHOUR / SECINMIN, shift_time % SECINMIN);
  |   ~
  |  |
  |  time_t {aka long long int}
/<>/analyzers/src/watch/nc_windows/header_window.cpp:77:93: error:
format ‘%ld’ expects argument of type ‘long int’, but argument 6 has type
‘time_t’ {aka ‘long long int’} [-Werror=format=]
   77 | mvwprintw(_window, HEADER::ELAPSED_LINE, FIRST_CHAR_POS, "Elapsed
time:  \t %ld days; %ld:%ld:%ld times",
  |
~~^
  |
|
  |
long int
  |
%lld
   78 |   shift_time / SECINDAY, shift_time % SECINDAY / SECINHOUR,
shift_time % SECINHOUR / SECINMIN, shift_time % SECINMIN);
  |  ~
  ||
  |time_t {aka
long long int}
/<>/analyzers/src/watch/nc_windows/header_window.cpp:77:97: error:
format ‘%ld’ expects argument of type ‘long int’, but argument 7 has type
‘time_t’ {aka ‘long long int’} [-Werror=format=]
   77 | mvwprintw(_window, HEADER::ELAPSED_LINE, FIRST_CHAR_POS, "Elapsed
time:  \t %ld days; %ld:%ld:%ld times",
  |
~~^
  |
|
  |
long int
  |
%lld
   78 |   shift_time / SECINDAY, shift_time % SECINDAY / SECINHOUR,
shift_time % SECINHOUR / SECINMIN, shift_time % SECINMIN);
  |
~
  |
|
  |
time_t {aka long long int}
/<>/analyzers/src/watch/nc_windows/header_window.cpp:77:101:
error: format ‘%ld’ expects argument of type ‘long int’, but argument 8 has
type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
   77 | mvwprintw(_window, HEADER::ELAPSED_LINE, FIRST_CHAR_POS, "Elapsed
time:  \t %ld days; %ld:%ld:%ld times",
  |
~~^
  |
|
  |
long int
  |
%lld
   78 |   shift_time / SECINDAY, shift_time % SECINDAY / SECINHOUR,
shift_time % SECINHOUR / SECINMIN, shift_time % SECINMIN);
  |
~
  |
|
  |
time_t {aka long long int}


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

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

Bug#1068028: qmmp: dependency freepats not included

[mike]

Package: qmmp
Version: 1.6.2-1+b1
Severity: normal
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,


midi with libwildmidi2 needs freepats for it to work out of the box.
But freepats is not a dependency in any form of qmmp.

freepats should be recommended or at least suggested.
I don't think that libwildmidi2 is the one that should depend on freepats.

Bug#1068026: FTBFS on armel: undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'

[Andrey Rakhmatullin]

Source: corectl
Version: 1.4.0+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=corectrl=armel=1.4.0%2Bds-1=1711731627=0

/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-
strong -fstack-clash-protection -Wformat -Werror=format-security
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now
CMakeFiles/test_all.dir/src/test_amdfanauto.cpp.o
CMakeFiles/test_all.dir/src/test_amdfancurve.cpp.o
CMakeFiles/test_all.dir/src/test_amdfanfixed.cpp.o
CMakeFiles/test_all.dir/src/test_amdfanmode.cpp.o
CMakeFiles/test_all.dir/src/test_amdgpuinfopm.cpp.o
CMakeFiles/test_all.dir/src/test_amdgpuinfopmoverdrive.cpp.o
CMakeFiles/test_all.dir/src/test_amdgpuinfouniqueid.cpp.o
CMakeFiles/test_all.dir/src/test_amdgpuinfovbios.cpp.o
CMakeFiles/test_all.dir/src/test_amdodfanauto.cpp.o
CMakeFiles/test_all.dir/src/test_amdodfancurve.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmadvanced.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmauto.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmautolegacy.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmautor600.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmdynamicfreq.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfixed.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfixedfreq.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfixedlegacy.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfixedr600.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfreqmode.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfreqod.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfreqrange.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmfreqvolt.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmoverclock.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmperfmode.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmpowercap.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmpowerprofile.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmpowerstate.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmvoltcurve.cpp.o
CMakeFiles/test_all.dir/src/test_amdpmvoltoffset.cpp.o
CMakeFiles/test_all.dir/src/test_amdppdpmhandler.cpp.o
CMakeFiles/test_all.dir/src/test_amdutils.cpp.o
CMakeFiles/test_all.dir/src/test_commandqueue.cpp.o
CMakeFiles/test_all.dir/src/test_commonutils.cpp.o
CMakeFiles/test_all.dir/src/test_control.cpp.o
CMakeFiles/test_all.dir/src/test_controlgroup.cpp.o
CMakeFiles/test_all.dir/src/test_controlmode.cpp.o
CMakeFiles/test_all.dir/src/test_cpu.cpp.o
CMakeFiles/test_all.dir/src/test_cpuepphandler.cpp.o
CMakeFiles/test_all.dir/src/test_cpufreq.cpp.o
CMakeFiles/test_all.dir/src/test_cpufreqmode.cpp.o
CMakeFiles/test_all.dir/src/test_cpuinfo.cpp.o
CMakeFiles/test_all.dir/src/test_cpuinfolscpu.cpp.o
CMakeFiles/test_all.dir/src/test_cpuinfoproccpuinfo.cpp.o
CMakeFiles/test_all.dir/src/test_cpuutils.cpp.o
CMakeFiles/test_all.dir/src/test_gpu.cpp.o
CMakeFiles/test_all.dir/src/test_gpuinfo.cpp.o
CMakeFiles/test_all.dir/src/test_gpuinfoopengl.cpp.o
CMakeFiles/test_all.dir/src/test_gpuinforevision.cpp.o
CMakeFiles/test_all.dir/src/test_gpuinfouevent.cpp.o
CMakeFiles/test_all.dir/src/test_gpuinfovram.cpp.o
CMakeFiles/test_all.dir/src/test_gpuinfovulkan.cpp.o
CMakeFiles/test_all.dir/src/test_hwidtranslator.cpp.o
CMakeFiles/test_all.dir/src/test_mathutils.cpp.o
CMakeFiles/test_all.dir/src/test_noop.cpp.o
CMakeFiles/test_all.dir/src/test_pmoverdrive.cpp.o
CMakeFiles/test_all.dir/src/test_pmpowerstatemode.cpp.o
CMakeFiles/test_all.dir/src/test_sensor.cpp.o
CMakeFiles/test_all.dir/src/test_stringutils.cpp.o
CMakeFiles/test_all.dir/src/test_swinfo.cpp.o
CMakeFiles/test_all.dir/src/test_swinfokernel.cpp.o
CMakeFiles/test_all.dir/src/test_swinfomesa.cpp.o
CMakeFiles/test_all.dir/src/test_sysmodel.cpp.o
CMakeFiles/catch_main.dir/src/main.cpp.o -o test_all
-Wl,-rpath,/<>/obj-arm-linux-gnueabi/src ../src/libcorectrl.so
/usr/lib/arm-linux-gnueabi/libspdlog.so.1.12.0 /usr/lib/libCatch2.a
/usr/lib/arm-linux-gnueabi/libfmt.so.9.1.0 /usr/lib/arm-linux-
gnueabi/libQt5Core.so.5.15.10
/usr/bin/ld: CMakeFiles/test_all.dir/src/test_sensor.cpp.o: undefined reference
to symbol '__atomic_load_8@@LIBATOMIC_1.0'
/usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: DSO
missing from command line


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

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

Bug#1068027: FTBFS: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘time_t’ {aka ‘long long int’}

[Andrey Rakhmatullin]

Source: tcptrack
Version: 1.4.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=tcptrack=armhf=1.4.3-1%2Bb2=1711727713=0

TextUI.cc: In member function ‘void TextUI::drawui()’:
TextUI.cc:312:35: error: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
  312 | printw("%lds",ic->getIdleSeconds());
  | ~~^   
  |   | |
  |   long int  time_t {aka
long long int}
  | %lld
TextUI.cc:314:35: error: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
  314 | printw("%ldm",ic->getIdleSeconds()/60);
  | ~~^   ~~~
  |   |   |
  |   long inttime_t {aka
long long int}
  | %lld
TextUI.cc:316:35: error: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
  316 | printw("%ldh",ic->getIdleSeconds()/3600);
  | ~~^   ~
  |   |   |
  |   long inttime_t {aka
long long int}
  | %lld


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

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

Bug#1068025: FTBFS: error: invalid conversion from ‘size_t*’ {aka ‘unsigned int*’} to ‘long unsigned int*’

[Andrey Rakhmatullin]

Source: orthanc
Version: 1.12.3+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=orthanc=armhf=1.12.3%2Bdfsg-1=1711743863=0

/<>/OrthancFramework/Sources/Images/JpegWriter.cpp: In member
function ‘virtual void Orthanc::JpegWriter::WriteToMemoryInternal(std::string&,
unsigned int, unsigned int, unsigned int, Orthanc::PixelFormat, const void*)’:
/<>/OrthancFramework/Sources/Images/JpegWriter.cpp:199:34: error:
invalid conversion from ‘size_t*’ {aka ‘unsigned int*’} to ‘long unsigned int*’
[-fpermissive]
  199 | jpeg_mem_dest(, , );
  |  ^
  |  |
  |  size_t* {aka unsigned int*}


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

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

Bug#1068024: revert to version that does not contain changes by bad actor

[Joey Hess]

Package: xz-utils
Version: 5.6.1+really5.4.5-1
Severity: important
Tags: security

I count a minimum of 750 commits or contributions to xz by Jia Tan, who
backdoored it.

This includes all 700 commits made after they merged a pull request in Jan 7
2023, at which point they appear to have already had direct push access, which
would have also let them push commits with forged authors. Probably a number of
other commits before that point as well.

Reverting the backdoored version to a previous version is not sufficient to
know that Jia Tan has not hidden other backdoors in it. Version 5.4.5 still
contains the majority of those commits.

Commits by them such as 18d7facd3802b55c287581405c4d49c98708c136 
and ae5c07b22a6b3766b84f409f1b6b5c100469068a show that they were deep
into analyzing the security of xz. They were well placed to insert a buffer
overflow that could allow eg, a targeted xz file to cause arbitrary code
execution. The impact of such a security hole could be much more stealthy and
bad than the known backdoor since it would allow chaining xz with other
unrelated software releases on an ongoing basis.

The package should be reverted to a version before their involvement,
which started with commit 6468f7e41a8e9c611e4ba8d34e2175c5dacdbeb4.
Or their early commits vetted and revert to a later point, but any arbitrary 
commit by a known bad and malicious actor almost certainly has less value
than the risk that a subtle change go unnoticed.

I'd suggest reverting to 5.3.1. Bearing in mind that there were security
fixes after that point for ZDI-CAN-16587 that would need to be reapplied.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4

[Rene Engelhard]

Hi,


Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977857


Regards,


Rene

Bug#1067242: dh-builtusing: Broken "Built-Using" field with architecture-specific invocations

[Nicolas Boulenguez]

> > On armel, the control files correctly contain no Built-Using field.

> I have not noticed the issues on armel, just armhf (with 0.0.5 or 0.0.6)
> and arm64 (with 0.0.6).

I have tried again on an armhf porterbox, all works as expected.

> > Could you please describe your build environment?

> I use sbuild with unshare chroot mode...

Thanks for the explanations.  If I understand correctly, sbuild needs
root permissions at least to create the chroot, so I cannot run it on
a porterbox.

Can you please try
# dh_builtusing -v
# cat debian/*.substvars
This should work in a clean source tree,  without spending time building.
(arm64 or armhf, the symptoms differ but the cause seems the same)

The expected output on armhf is:
In package u-boot-sunxi, substvar dh-builtusing:arm-trusted-firmware += 
disabled-by-restriction
In package u-boot-sunxi, substvar dh-builtusing:crust-firmware += 
disabled-by-restriction
In package u-boot-rockchip, substvar dh-builtusing:arm-trusted-firmware 
+= disabled-by-restriction
dh-builtusing:arm-trusted-firmware=disabled-by-restriction (= 0)
dh-builtusing:arm-trusted-firmware=disabled-by-restriction (= 0)
dh-builtusing:crust-firmware=disabled-by-restriction (= 0)

Bug#1066096: bookworm-pu: package libpod/4.3.1+ds1-8+deb12u1

[Jérôme Charaoui]

Le 2024-03-29 à 16 h 09, Jonathan Wiltshire a écrit :

Control: tag -1 moreinfo

Hi,

On Tue, Mar 12, 2024 at 10:24:16AM -0400, Jérôme Charaoui wrote:

Low, the patch is small (3 lines) and is
strictly designed to gracefully handle the
identified race condition.


The uploaded package also drops the .gitlab-ci.yml, is that intentional?


No, it isn't intentional, but it seems to me either that, or modifying 
debian/clean which specifically lists "debian/.gitlab-ci.yml". This was 
fixed in a later version of the source package.


-- Jérôme

Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4

[Rene Engelhard]

reassign 1068023 libreoffice-gtk4

thanks


Hi,

Am 29.03.24 um 21:04 schrieb Rene Engelhard:


Package: libreoffice


if it happens only with gtk4, isn't it better suited at libreoffice-gtk4?



I use other gtk applications (e.g. evince, audacity, inkscape, firefox)
in this same environment with no problems.

But those are gtk3, not gtk4. No idea whether using gtk4 makes a 
difference here.



Regards,


Rene

Bug#1066096: bookworm-pu: package libpod/4.3.1+ds1-8+deb12u1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Tue, Mar 12, 2024 at 10:24:16AM -0400, Jérôme Charaoui wrote:
> Low, the patch is small (3 lines) and is
> strictly designed to gracefully handle the
> identified race condition.

The uploaded package also drops the .gitlab-ci.yml, is that intentional?

Thanks,

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

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

Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4

[Rene Engelhard]

Package: libreoffice
Version: 4:24.2.0-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I have qtwayland5 5.15.10-2+b1 installed.  I do not have XWayland
installed at all.  I'm running from within a Wayland session, using sway
1.9-1 as a compositor.

When i try to launch libreoffice using the gtk4 VCLPLUGIN, i get a
complaint that it doesn't want to launch because there is no X11 error:


```
0 dkg@alice:~$ SAL_USE_VCLPLUGIN=gtk4 libreoffice
Failed to open display
/usr/lib/libreoffice/program/soffice.bin X11 error: Can't open display: 
  Set DISPLAY environment variable, use -display option

   or check permissions of your X-Server
   (See "man X" resp. "man xhost" for details)
0 dkg@alice:~$ ```

In this case, no libreoffice session starts up.

On the other hand, i get some warnings when using the qt5 plugin, but it
actually starts up with no problem:

```
0 dkg@alice:~$ SAL_USE_VCLPLUGIN=qt5 libreoffice
Failed to open display
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
0 dkg@alice:~$ ```

I use other gtk applications (e.g. evince, audacity, inkscape, firefox)
in this same environment with no problems.

--dkg


-- Package-specific info:
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
ii  libreoffice-qt5  4:24.2.0-1   amd64office productivity suite -- Qt 
5 integration

Java (javaldx):
/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-17-openjdk-amd64


Configuration filePackage Exists Changed
/etc/libreoffice/registry/writer.xcd  libreoffice-writer  Yes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
ii  libreoffice-qt5  4:24.2.0-1   amd64office productivity suite -- Qt 
5 integration

Java (javaldx):
/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-17-openjdk-amd64


Configuration filePackage Exists Changed
/etc/libreoffice/registry/calc.xcdlibreoffice-calcYes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
ii  libreoffice-qt5  4:24.2.0-1   amd64office productivity suite -- Qt 
5 integration

Java (javaldx):
/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64

Java:
http://openoffice.org/2004/java/framework/1.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>

file:///usr/lib/jvm/java-17-openjdk-amd64


Configuration filePackage Exists Changed
/etc/libreoffice/registry/base.xcdlibreoffice-base   

Bug#922161: Grub null src bitmap error while trying to drop background image

[Jmkr]

I can confirm this bug occurs also on my customized installers. I unfortunately 
still generate my installers from Debian 10.13 and 11.9 Netinst images (not 
enough time to migrate to Debian 12). When I recently switched to UEFI booting 
with my GRUB theme without a background image I started to get the "error: null 
src bitmap in grub_video_bitmap_create_scaled." message.

My GRUB menu does not have submenus, but the error message appears after I 
press ENTER to run any GRUB menu entry. Booting of the given entry continues 
after a delay or when one hits a key, but it still makes the user experience 
feel "buggy".

My GRUB theme uses "desktop-color" instead of "desktop-image" which is probably 
the cause of the error message. I found a workaround here:
https://github.com/grml/grml-live/commit/8a09c98f94a43bdccd8699e200b66ab81f9102bf

But on my installed systems this same GRUB theme works without that error, 
which is odd as the GRUB versions are (nearly) the same for the installers and 
installed systems. Anyway, since I want to keep my GRUB theme nice and simple + 
same for installers as well as installed systems, I do not want images in the 
theme. I use the theme just to be able to change the font, menu positioning and 
texts (title, messages). Thus, it would be nice if this bug gets fixed or if 
someone suggests a better workaround.

Regards,
Jmkr

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Rene Engelhard]

Hi,

Am 25.03.24 um 19:17 schrieb Julian Gilbey:

   * Reading and writing file formats (like CSV, Apache ORC, and Apache
 Parquet)


liborcus supports this (Apache Parquet) if built with Apache Arrow. And 
thus makes LibreOffice being able to handle it.


I didn't invest any time in Apache Arrow since I am already too low on 
time anyway and I deemed it too a "low popularity" thing anyway.



So this is a plea for anyone looking for something really helpful to
do: it would be great to have a group of developers finally package
this!

Indeed.

There was some initial work done (see the RFP bug report for
details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
but that is fairly old now.  As Apache Arrow supports numerous
languages, it may well benefit from having a group of developers with
different areas of expertise to build it.  (Or perhaps it would make
more sense to split the upstream source into a collection of different
Debian source packages for the different supported languages.  I don't
know.)


Would definitely make transitions easier.


  Unfortunately I don't have the capacity to devote any time to
it myself.


Dito.


Regards,


Rene

Bug#859458: Because of displays with very high dpi, not only the keyboard, but the font has to be configured early

[Jmkr]

Here you go. Both scripts are in the attached "SCRIPTS.txt". Note that on my 
systems I keep only the one PSF font that I actually use, so my hook script 
does not need to update cached fonts + my systems are without PLYMOUTH. Check 
Pedro's scripts if you need to handle those more complex usages.

Regards,
JmkrSCRIPT 1 "/etc/initramfs-tools/hooks/console-setup":
#!/bin/sh

case "$1" in
prereqs)
echo 'keymap'
exit 0;;
esac

. /usr/share/initramfs-tools/hook-functions

if [ -x /bin/plymouth ]; then
echo 'W: Graphical boot splash prevents setting console fonts.'
fi

fontfile=$(ls -1 -t /etc/console-setup/cached_*.psf.gz 2>/dev/null | head -n 1)

if [ -n "$fontfile" ] && [ -r "$fontfile" ]; then
copy_exec /bin/setfont
copy_file font "$fontfile"
fi

if [ ! -x "$DESTDIR"/bin/setfont ]; then
echo 'E: Failed to copy the "/bin/setfont" executable.'
exit 1
fi

if [ ! -r "$DESTDIR$fontfile" ]; then
echo "E: Failed to copy the \"$fontfile\" file."
exit 1
fi
--
SCRIPT 2 "/etc/initramfs-tools/scripts/init-top/console-setup":
#!/bin/sh

case "$1" in
prereqs)
echo 'udev keymap'
exit 0;;
esac

fontfile=$(ls -1 -t /etc/console-setup/cached_*.psf.gz 2>/dev/null | head -n 1)

if [ -x /bin/setfont ] && [ -n "$fontfile" ] && [ -r "$fontfile" ]; then
setfont "$fontfile"
fi

Bug#1062170: glw: NMU diff for 64-bit time_t transition

[Steven Robbins]

Hi,

Package glw has a serious bug against it because of an unapplied 64-bit time 
patch.  I don't know why it is not applied, but Michael Crusoe raised some 
relevant questions about it, quoted in full below.  Would the patch submitter 
be able to review and advise?

On Mon, 11 Mar 2024 13:34:42 +0100 "Michael R. Crusoe"  
wrote:
> I don't think this patch was effective. There is no package rename and 
> the build log from experimental contains the following warning:
> 
>  > dpkg-gencontrol: warning: Provides field of package libglw1-mesa: 
> substitution variable ${t64:Provides} used, but is not defined



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

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Diane Trout]

On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote:
> 
> 
> So this is a plea for anyone looking for something really helpful to
> do: it would be great to have a group of developers finally package
> this!  There was some initial work done (see the RFP bug report for
> details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
> but that is fairly old now.  As Apache Arrow supports numerous
> languages, it may well benefit from having a group of developers with
> different areas of expertise to build it.  (Or perhaps it would make
> more sense to split the upstream source into a collection of
> different
> Debian source packages for the different supported languages.  I
> don't
> know.)  Unfortunately I don't have the capacity to devote any time to
> it myself.
> 
> Thanks in advance for anyone who can step forward for this!

I've been maintain dask and anndata and saw that apache arrow was
getting increasingly popular.

I took the current science-team preliminary packaging 7.0.0 packaging
and managed to get it to build through a combination of patches and
turning off features.

I even mostly managed to get pyarrow to build. (Though some tests fail
due to pytest lazy-fixture being abandoned).

I pushed my current work in progress to.

https://salsa.debian.org/diane/arrow.git

Was anyone else planning on working on it or should I push my updates
to the science-team package?

Diane

Bug#1068022: Document the Testsuite-Triggers field

[Christian Kastner]

Package: debian-policy
Version: 4.6.2.0
Severity: wishlist

Policy 5.6.30 lists the Testsuite field, but it doesn't list the
Testsuite-Triggers field that seems to be part of Sources files and is
generated by dpkg-source >= 1.18.8.

This field is quite useful, as given my package src:foo, I can find out
which packages have autopkgtests that depend on it, and are thus in the
set of reverse dependencies that I could check for breakage.

I'd provide a patch based on the documentation in dsc(5), but I don't
know what the current process is. Does anyone have a link to a doc on
how to submit a change?

Best,
Christian

Bug#1067932: usrmerge is dangerous : lost bash and other commands

[Denis Migdal]

>This is why the conversion procedure stopped.

And it blocked my upgrade although I never asked (nor felt the need) to 
merge /usr/bin and /bin.


> Then you started thinkering with your system to "fix" it and did worse.

Indeed, I did. I was left without any instructions, a little tired and 
hurry, and I fucked up.



> This does not happen frequently enough (only you reported this) to 
justify investing development resources.


I can understand this argument. Though I do not think changing the error 
message would require much development resources.


I also think that protecting users for their own security is always 
good. If we want Linux to be more adopted in the general public, this 
kind of issues is an hindrance. Novice users are more likely to fuck up, 
while being the ones that are the less likely to report such issues (and 
to think of doing it/to know how to do it).


For me it's too late. But if it can help others, it'd be a good think.


Le 29/03/2024 à 19:22, Marco d'Itri a écrit :

On Mar 29, Denis Migdal  wrote:


Maybe I was better off reinstalling, indeed, but I prefer to properly
plan/prepare for it.

This is why the conversion procedure stopped.
Then you started thinkering with your system to "fix" it and did worse.


It'd help me if, at least, usrmerge printed the number of duplicates and sym
links. Maybe with a more explicit error message, indicating what to do, "we
strongly advise to reinstall your system", "remove duplicates, but be
careful of symlinks", or whatever.

This does not happen frequently enough (only you reported this) to
justify investing development resources.


--
 	Denis MIGDAL  - Maître de 
conférences
Enseignement: /IUT d'Aurillac 
, département STID 
/
Recherche: /Laboratoire d'Informatique, de Modélisation et 
d'Optimisation des Systèmes (LIMOS)/ 

/https://migdal.ovh/ 
 	Facebook UCA 
 Twitter UCA 
 Instagram UCA 


100 rue de l'Egalité - 15013 Aurillac
www.uca.fr 
Mail:denis.mig...@uca.fr+33 (0)4 00 00 00 00

Bug#1068021: RFS: debian-el/37.12 -- Emacs helpers specific to Debian users

[manphiz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "debian-el":

 * Package name : debian-el
   Version  : 37.12
   Upstream contact : Debian Emacsen team 
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/emacsen-team/debian-el
   Section  : lisp

The source builds the following binary packages:

  elpa-debian-el - Emacs helpers specific to Debian users
  debian-el - Transition package, debian-el to elpa-debian-el

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

  https://mentors.debian.net/package/debian-el/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/debian-el/debian-el_37.12.dsc

Changes since the last upload:

 debian-el (37.12) unstable; urgency=medium
 .
   * Bring back debian-autoloads.el (Closes: #1067902)
   * Fix comp warnings in debian-bug.el (Closes: #1067922)
   * Update distribution code names to recent releases
   * Append non-free-firmware to non-free when handling components
   * Move package info above copyright notice following existing practices
   * Bump package version to prepare for release

Regards,
-- 
Xiyue Deng

Bug#1068020: Background process seemingly paused

[Terrance Hendrik]

Package: linux-image-amd64
Version: 6.6.15-2

Debian testing/trixie, kernel 6.6.15-2 (2024-02-04)
xfce

Case 1:

Start a command that runs for a long time, say `ffmpeg`. switch to other
programs, i.e. web browser or other terminal windows, and keep using the
computer. After a while, ffmpeg cpu usage drops to 0%, switch back to
ffmpeg's terminal window, it will go back to running.

Case 2:

start ffmpeg, leave the computer untouched, then screensaver runs, then the
display turns off. No suspend, no hibernate, no shutdown. after a while,
wake up display, unlock session, ffmpeg is using 0% CPU. switch back to its
terminal window, it resumes.


I am not sure which package is causing this. This happened long before
6.6.15 kernels.

Bug#1067821: bookworm-pu: package nvidia-graphics-drivers/535.161.08-1~deb12u1

[Adam D. Barratt]

On Thu, 2024-03-28 at 18:40 +0100, Andreas Beckmann wrote:
> On 27/03/2024 21.10, Adam D. Barratt wrote:
> > Please go ahead, bearing in mind that the window for 12.6 closes
> > over
> > the coming weekend.
> 
> The whole nvidia stack has now been uploaded, 
> src:nvidia-graphics-drivers is sitting in NEW.

It's now in stable-new.

We have a bit of an issue in terms of accepting / shipping the 535
bookworm stack, however. The upload of 535 to unstable is blocked from
migration to testing by openssl, which is in turn blocked by dpkg,
which is manually blocked for the time64 transition.

Would we be better to ship the 525 packages that are already in p-u and
revisit 535 for 12.7, or skip those updates as well and just include
535 when we can?

Regards,

Adam

Bug#1067771: cdk.h file location has changed, breaks application build

[Steven Robbins]

On Thursday, March 28, 2024 8:04:30 P.M. CDT Thomas Dickey wrote:

> I suppose that I _could_ have made a symlink in /usr/include/cdk,
> to address both old/new locations.  You might consider that for
> the package...

That's a good idea.  I've implemented your suggestion and closed the bug.

Thanks!
-Steve


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

Bug#1067470: urlwatch 2.25-1 navigate fails on Debian stable (12.5)

[Maxime Werlen]

 Control: forwarded -1 https://github.com/thp/urlwatch/issues/809
Control: tags -1 bookworm
Control: fixed -1 2.28-1
Hi,

Sorry for the late reply, this mail was sent to my spam folder. I've
already responded to this question on the upsteam bug tracker (
https://github.com/thp/urlwatch/issues/809).

As explained, the crash is linked to the python 3.11 upgrade. This problem
has been fixed in urlwatch 2.27 as explained in changelog

.
I don't know how to update urlwatch 2.27 to the bookworm archive. I'm not a
debian developer. With a bit a guidance (a tutorial), I should be able to
do it.

Regards,

Maxime

Le ven. 22 mars 2024 à 00:27, Justin Piszcz  a
écrit :

> Package: urlwatch
> Version: 2.25-1
>
> Logged a case on github for this as well:
> https://github.com/thp/urlwatch/issues/809
>
> $ urlwatch --edit
>
> name: "Wyze Service Status & Known Issues"
> filter:
>   - html2text
>   - striplines
> navigate: "
> https://support.wyze.com/hc/en-us/articles/360015979872-Service-Status-Known-Issues
> "
>
> $ urlwatch --test-filter 1
> Exception while releasing resources for job:  navigate='
> https://support.wyze.com/hc/en-us/articles/360015979872-Service-Status-Known-Issues
> '
> name='Wyze Service Status & Known Issues' filter=['html2text',
> 'striplines']>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 139,
> in test_filter
> raise job_state.exception
>   File "/usr/lib/python3/dist-packages/urlwatch/handler.py", line 68,
> in __enter__
> self.job.main_thread_enter()
>   File "/usr/lib/python3/dist-packages/urlwatch/jobs.py", line 406, in
> main_thread_enter
> from .browser import BrowserContext
>   File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 42,
> in 
> class BrowserLoop(object):
>   File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 49,
> in BrowserLoop
> @asyncio.coroutine
>  ^
> AttributeError: module 'asyncio' has no attribute 'coroutine'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/urlwatch/handler.py", line 78,
> in __exit__
> self.job.main_thread_exit()
>   File "/usr/lib/python3/dist-packages/urlwatch/jobs.py", line 410, in
> main_thread_exit
> self.ctx.close()
> 
> AttributeError: 'BrowserJob' object has no attribute 'ctx'
> Traceback (most recent call last):
>   File "/usr/bin/urlwatch", line 33, in 
> sys.exit(load_entry_point('urlwatch==2.25', 'console_scripts',
> 'urlwatch')())
>
>  ^^^
>   File "/usr/lib/python3/dist-packages/urlwatch/cli.py", line 112, in main
> urlwatch_command.run()
>   File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 431, in
> run
> self.handle_actions()
>   File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 231,
> in handle_actions
> sys.exit(self.test_filter(self.urlwatch_config.test_filter))
>  ^^
>   File "/usr/lib/python3/dist-packages/urlwatch/command.py", line 139,
> in test_filter
> raise job_state.exception
>   File "/usr/lib/python3/dist-packages/urlwatch/handler.py", line 68,
> in __enter__
> self.job.main_thread_enter()
>   File "/usr/lib/python3/dist-packages/urlwatch/jobs.py", line 406, in
> main_thread_enter
> from .browser import BrowserContext
>   File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 42,
> in 
> class BrowserLoop(object):
>   File "/usr/lib/python3/dist-packages/urlwatch/browser.py", line 49,
> in BrowserLoop
> @asyncio.coroutine
>  ^
> AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you
> mean: 'coroutines'?
>
>

Bug#1067932: usrmerge is dangerous : lost bash and other commands

[Marco d'Itri]

On Mar 29, Denis Migdal  wrote:

> Maybe I was better off reinstalling, indeed, but I prefer to properly
> plan/prepare for it.
This is why the conversion procedure stopped.
Then you started thinkering with your system to "fix" it and did worse.

> It'd help me if, at least, usrmerge printed the number of duplicates and sym
> links. Maybe with a more explicit error message, indicating what to do, "we
> strongly advise to reinstall your system", "remove duplicates, but be
> careful of symlinks", or whatever.
This does not happen frequently enough (only you reported this) to 
justify investing development resources.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1068019: wireplumber: please include manpages or other documentation that would hint that wpctl accepts @DEFAULT_SINK@

[Daniel Kahn Gillmor]

Package: wireplumber
Version: 0.4.17-1+b1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I am trying to use wireplumber from the command line (or as a backend to
another controlling tool).  the wireplumber package includes `wpctl`,
which appears to be the thing that i want to use, but there is no manual
page or other local documentation.

I had set myself a basic task: be able to mute and unmute the system
volume using `wpctl`.  Even if i install the wireplumber-doc package,
the html files there don't give me suggestions about how to use wpctl to
control the system volume.  It appears i have to first read and parse
the output of `wpctl status`, which is very messy.

I had to resort to the Arch Wiki
(https://wiki.archlinux.org/title/WirePlumber) to learn that instead of
a numeric ID, i can specify @DEFAULT_SINK@ to do the simple, obvious
thing.

This was not evident from the output of "wpctl --help", and there is no
manual page installed to provide at hint.  Even knowing what to search
for, the only part of the debian packages that i could find evidence of
this critical interface for baseline usability is two places:

0 dkg@alice:~$ grep DEFAULT $(dpkg -L wireplumber-doc wireplumber) 2> /dev/null
/usr/share/doc/wireplumber/html/releases.html:wpctl now supports using 
DEFAULT_{AUDIO_,VIDEO_,}{SINK,SOURCE} as ID,
/usr/share/zsh/site-functions/_wpctl:'pw-defaults:defaults:(@DEFAULT_SINK@ 
@DEFAULT_SOURCE@)' \
2 dkg@alice:~$

Since i don't use zsh, i couldn't even get such a hint from tab
completion.

Please provide better documentation that would enable the user to
discover this from the package itself.  I shouldn't need to search the
Arch wiki (which might itself warns that it might be out of date due to
configuration changes, etc, and anyway might not be relevant to the
version of wireplumber i have installed).

--dkg

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

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

Versions of packages wireplumber depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4
ii  dbus-x11 [dbus-session-bus]   1.14.10-4
ii  init-system-helpers   1.66
ii  libc6 2.37-15
ii  libglib2.0-0  2.78.4-1
ii  libpipewire-0.3-0 1.0.3-1
ii  libwireplumber-0.4-0  0.4.17-1+b1
ii  pipewire  1.0.3-1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  1.0.3-1

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  
pn  libspa-0.2-libcamera  
pn  wireplumber-doc   

-- no debconf information


signature.asc
Description: PGP signature

Bug#1066328: Disabling the option

[Andrey Rakhmatullin]

As this is blocking quite a lot of stuff (via e.g. petsc) and there is no
progress either upstream or in Debian on this problem, and assuming it's
not viable to remove this build-dep from all reverse deps, I propose using
DEB_BUILD_MAINT_OPTIONS = qa=-bug-implicit-func and hoping that this
doesn't hide any problems that weren't present before the t64 transition
that affect code that people actually run (which may be an empty set,
especially on armel and armhf, but we may never know).


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1067980: bookworm-pu: package gpaste/43.1-3+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2024-03-29 at 15:57 +0100, Andreas Beckmann wrote:
> In order to smoothen upgrade paths I'd like to add some
> Breaks+Replaces
> to bookworm. This avoids a file conflict in case libgpaste6 (last
> released with stretch) is still installed.

Please go ahead.

Regards,

Adam

Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2

[Adam D. Barratt]

Control: tags -1 + confimred

On Fri, 2024-03-29 at 17:41 +0100, Andreas Beckmann wrote:
> To smoothen some upgrade paths from buster -> bullseye -> bookworm we
> need to add some Breaks+Replaces against obsolete packages.

Please go ahead.

Regards,

Adam

Bug#1068018: xfce4-power-manager: Brightness control keys no longer work

[ael]

Package: xfce4-power-manager
Version: 4.18.3-2
Severity: normal

After a upgrade this morning which did not include this package, the
brightness keys on this Clevo laptop no longer work.

I tried to install the version from experimental 
xfce4-power-manager_4.19.1-1_amd64.deb
but there were too many problematic dependencies to sort out for a quick
test.

After the upgrade the only way I could control the screen brightness was
using an echo as root to 
/sys/class/backlight/intel_backlight/brightness



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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.37-15
ii  libcairo-gobject2 1.18.0-1+b1
ii  libcairo2 1.18.0-1+b1
ii  libglib2.0-0  2.78.4-1
ii  libgtk-3-03.24.41-1
ii  libnotify40.8.3-1
ii  libpango-1.0-01.52.0+ds-1
ii  libpangocairo-1.0-0   1.52.0+ds-1
ii  libupower-glib3   1.90.2-8
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfce4ui-2-04.18.4-1
ii  libxfce4util7 4.18.1-2
ii  libxfconf-0-3 4.18.1-1+b1
ii  libxrandr22:1.5.4-1
ii  upower1.90.2-8
ii  xfce4-power-manager-data  4.18.3-2

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  255.4-1
ii  xfce4-power-manager-plugins  4.18.3-2

xfce4-power-manager suggests no packages.

-- no debconf information

Bug#1068017: util-linux: please ship liblastlog2 packages

[Sven Joachim]

Source: util-linux
Version: 2.40~rc2-8
Severity: wishlist

It seems desirable to ship liblastlog2 in trixie, considering that the
/var/log/lastlog file is not Y2038-safe and pam in unstable has already
dropped pam_lastlog.so, meaning that non-ssh logins are no longer
recorded in /var/log/lastlog.

I have not looked closely yet, but I guess that would mean additional
packages liblastlog2-2 for the library, liblastlog2-dev for the
development files and libpam-lastlog2 for the pam module.  The lastlog2
binary could probably be included in util-linux-extra.

Bug#1068016: bookworm-pu: package node-babel7/7.20.15+ds1+~cs214.269.168-3+deb12u2

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Yadd 
Control: block 1037234 with -1
Control: affects -1 + src:node-babel7

[ Reason ]
To smoothen some upgrade paths from buster -> bullseye -> bookworm we
need to add some Breaks+Replaces against obsolete packages.

[ Impact ]
Some upgrade paths failing with file conflicts, mostly affecting QA
tests.

[ Tests ]
Manual piuparts tests of some affected upgrade paths.

[ Risks ]
Low, adds Breaks+Replaces against packages no longer in the archive.

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

[ Changes ]
Add Breaks+Replaces against all old node-babel package names predating
version 7, cherry-picked from sid.

[ Other info ]
This package is effectively the same as 7.20.15+ds1+~cs214.269.168-5
that has been in sid at some point, so we could also upload it as
7.20.15+ds1+~cs214.269.168-5~deb12u1 instead.

Andreas
diff --git a/debian/changelog b/debian/changelog
index abcadf21f..106794aa7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+node-babel7 (7.20.15+ds1+~cs214.269.168-3+deb12u2) bookworm; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+  * Backport Breaks+Replaces fixes from 7.20.15+ds1+~cs214.269.168-4.
+
+  [ Yadd ]
+  * Add missing Breaks+Replaces against all node-babel-* that were in Debian 10
+(Closes: #1037234)
+
+ -- Andreas Beckmann   Fri, 29 Mar 2024 17:29:05 +0100
+
 node-babel7 (7.20.15+ds1+~cs214.269.168-3+deb12u1) bookworm-security; 
urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index e5dba9547..ca8f614e1 100644
--- a/debian/control
+++ b/debian/control
@@ -120,8 +120,92 @@ Depends: ${misc:Depends}
 Suggests: node-babel-plugin-polyfill-es-shims
  , node-babel7-debug
 Breaks: node-babel-core (<< 6.26.0+repack-3~)
+ , node-babel-cli (<< 7)
  , node-babel-code-frame (<< 7)
-Replaces: node-babel-code-frame (<< 7)
+ , node-babel-generator (<< 7)
+ , node-babel-helper-bindify-decorators (<< 7)
+ , node-babel-helper-builder-binary-assignment-operator-visitor (<< 7)
+ , node-babel-helper-builder-react-jsx (<< 7)
+ , node-babel-helper-call-delegate (<< 7)
+ , node-babel-helper-explode-assignable-expression (<< 7)
+ , node-babel-helper-explode-class (<< 7)
+ , node-babel-helper-function-name (<< 7)
+ , node-babel-helper-hoist-variables (<< 7)
+ , node-babel-helper-optimise-call-expression (<< 7)
+ , node-babel-helper-remap-async-to-generator (<< 7)
+ , node-babel-helper-replace-supers (<< 7)
+ , node-babel-helpers (<< 7)
+ , node-babel-plugin-external-helpers (<< 7)
+ , node-babel-plugin-syntax-async-generators (<< 7)
+ , node-babel-plugin-syntax-class-properties (<< 7)
+ , node-babel-plugin-syntax-decorators (<< 7)
+ , node-babel-plugin-syntax-do-expressions (<< 7)
+ , node-babel-plugin-syntax-dynamic-import (<< 7)
+ , node-babel-plugin-syntax-flow (<< 7)
+ , node-babel-plugin-syntax-function-bind (<< 7)
+ , node-babel-plugin-syntax-jsx (<< 7)
+ , node-babel-plugin-syntax-object-rest-spread (<< 7)
+ , node-babel-plugin-transform-async-to-generator (<< 7)
+ , node-babel-plugin-transform-exponentiation-operator (<< 7)
+ , node-babel-plugin-transform-flow-strip-types (<< 7)
+ , node-babel-plugin-transform-jscript (<< 7)
+ , node-babel-plugin-transform-proto-to-assign (<< 7)
+ , node-babel-plugin-transform-react-display-name (<< 7)
+ , node-babel-plugin-transform-react-jsx (<< 7)
+ , node-babel-plugin-transform-react-jsx-self (<< 7)
+ , node-babel-plugin-transform-react-jsx-source (<< 7)
+ , node-babel-plugin-transform-regenerator (<< 7)
+ , node-babel-plugin-transform-runtime (<< 7)
+ , node-babel-plugin-transform-strict-mode (<< 7)
+ , node-babel-preset-env (<< 7)
+ , node-babel-preset-flow (<< 7)
+ , node-babel-preset-react (<< 7)
+ , node-babel-register (<< 7)
+ , node-babel-template (<< 7)
+ , node-babel-traverse (<< 7)
+Replaces: node-babel-cli (<< 7)
+ , node-babel-code-frame (<< 7)
+ , node-babel-generator (<< 7)
+ , node-babel-helper-bindify-decorators (<< 7)
+ , node-babel-helper-builder-binary-assignment-operator-visitor (<< 7)
+ , node-babel-helper-builder-react-jsx (<< 7)
+ , node-babel-helper-call-delegate (<< 7)
+ , node-babel-helper-explode-assignable-expression (<< 7)
+ , node-babel-helper-explode-class (<< 7)
+ , node-babel-helper-function-name (<< 7)
+ , node-babel-helper-hoist-variables (<< 7)
+ , node-babel-helper-optimise-call-expression (<< 7)
+ , node-babel-helper-remap-async-to-generator (<< 7)
+ , node-babel-helper-replace-supers (<< 7)
+ , node-babel-helpers (<< 7)
+ , node-babel-plugin-external-helpers (<< 7)
+ , node-babel-plugin-syntax-async-generators (<< 7)
+ , node-babel-plugin-syntax-class-properties (<< 7)
+ , node-babel-plugin-syntax-decorators (<< 7)
+ , 

Bug#1067959: sambamba: FTBFS on armhf (supported compiler issue)

[Andreas Tille]

Hi,

Am Fri, Mar 29, 2024 at 10:32:25PM +0900 schrieb Kentaro HAYASHI:
> sambamba fails to build on armhf.

Thanks a lot for this bug report.  I'd recommend to drop 32bit architectures
for this package.

Kind regards
Andreas.

> FYI:
> 
> https://buildd.debian.org/status/fetch.php?pkg=sambamba=armhf=1.0.1%2Bdfsg-1=1699230688=0
> 
> Regards,

-- 
https://fam-tille.de

Bug#1068014: urlwatch: Please replace python3-appdirs dependency with platformdirs

[Maxime Werlen]

Owner: max...@werlen.fr
Control: forwarded -1 https://github.com/thp/urlwatch/pull/81

Thanks for reporting the issue. The fix is very simple. I've already
proposed a change upstream (https://github.com/thp/urlwatch/pull/81).
I will issue a new version with the patch.

Regards,

Maxime


Le ven. 29 mars 2024 à 16:18, Simon McVittie  a écrit :

> Package: urlwatch
> Version: 2.28-2
> Severity: important
> Control: block 1060427 by -1
> Tags: trixie sid
> User: debian-pyt...@lists.debian.org
> Usertags: appdirs-removal
>
> python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
> that it should not be included in trixie[2]. A recommended replacement is
> python3-platformdirs[3], which is a fork of appdirs with a very similar
> API.
>
> Please migrate from appdirs to platformdirs or some other replacement,
> so that appdirs can be removed.
>
> Thanks,
> smcv
>
> [1]
> https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
> [2] https://bugs.debian.org/1060427
> [3] https://pypi.org/project/platformdirs/
>

Bug#1029735: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Sun, 21 Jan 2024 12:09:30 -0500 Scott Kitterman  
wrote:

> As we approach the first anniversary for this bug, an update:
> 
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
response 
> to an RFA for both packages.  As these are somewhat security sensitive 
> packages (among my first acts after adopting the packages was to upload 
> proposed updates for both to address minor security issues in Bookworm in 
the 
> next point release - same bug in both), I do not think we should release 
> pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> If you want this package to be in Trixie, you will need to use pypdf instead 
> of pypdf2.

Now that pypdf2 has been removed from Trixie, bumping to serious.

Scott K

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

Bug#1029738: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Sun, 21 Jan 2024 12:19:23 -0500 Scott Kitterman  
wrote:

> As we approach the first anniversary for this bug, an update:
> 
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
response 
> to an RFA for both packages.  As these are somewhat security sensitive 
> packages (among my first acts after adopting the packages was to upload 
> proposed updates for both to address minor security issues in Bookworm in 
the 
> next point release - same bug in both), I do not think we should release 
> pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> If you want this package to be in Trixie, you will need to use pypdf instead 
> of pypdf2.

Now that pypdf2 is removed from Trixie, bumping to serious.

Scott K

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

Bug#1061261: odoo: Uses deprecated/to be removed PyPDF2

[Scott Kitterman]

On Sun, 21 Jan 2024 12:17:53 -0500 Scott Kitterman  
wrote:

> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
response to an RFA for both packages.  As these are somewhat security 
sensitive packages (among my first acts after adopting the packages was to 
upload proposed updates for both to address minor security issues in Bookworm 
in the next point release - same bug in both), I do not think we should 
release pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.

Now that pypdf2 is removed from Trixie, updating to serious.

Scott K

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

Bug#1029734: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Sun, 21 Jan 2024 12:08:35 -0500 Scott Kitterman  
wrote:

> As we approach the first anniversary for this bug, an update:
> 
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
response 
> to an RFA for both packages.  As these are somewhat security sensitive 
> packages (among my first acts after adopting the packages was to upload 
> proposed updates for both to address minor security issues in Bookworm in 
the 
> next point release - same bug in both), I do not think we should release 
> pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> If you want this package to be in Trixie, you will need to use pypdf instead 
> of pypdf2.

Now that pypdf2 has been removed from Trixie, bumping to serious.

Scott K

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

Bug#1029733: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Sun, 21 Jan 2024 12:07:19 -0500 Scott Kitterman  
wrote:
> As we approach the first anniversary for this bug, an update:
> 
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
response 
> to an RFA for both packages.  As these are somewhat security sensitive 
> packages (among my first acts after adopting the packages was to upload 
> proposed updates for both to address minor security issues in Bookworm in 
the 
> next point release - same bug in both), I do not think we should release 
> pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> If you want this package to be in Trixie, you will need to use pypdf instead 
> of pypdf2.

Now that pypdf2 is removed from Trixie, bumping to serious.

Scott K

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

Bug#1068015: python3-binwalk: Please consider new upstream, project is abandoned

[Michiel]

Package: python3-binwalk
Version: 2.3.4+dfsg1-5
Severity: normal
Tags: upstream

Dear Maintainer,

python3-binwalk uses as https://github.com/ReFirmLabs/binwalk their upstream.
However this repository is abandoned by their owner and indicated as such. It
has not seen any new releases in over a year.

There is an active fork at https://github.com/OSPG/binwalk/ which does make
releases and fixes actual bugs, including Python 3.12 compatibility as pointed
out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063826

Please consider switching the upstream of this package to the new location, so
we can continue to receive upstream bugfixes and features in debian.


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

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

Versions of packages python3-binwalk depends on:
ii  python3 3.11.6-1
ii  python3-zombie-imp  0.0.2-2

Versions of packages python3-binwalk recommends:
ii  7zip [p7zip-full]  23.01+dfsg-8
ii  arj3.10.22-27
ii  bzip2  1.0.8-5.1
ii  cramfsswap 1.4.2
ii  mtd-utils  1:2.1.6-1+b1
ii  ncompress  5.0-1
pn  p7zip  
ii  p7zip-full 16.02+transitional.1
ii  python3-pyqtgraph  0.13.4-2
ii  sleuthkit  4.12.1+dfsg-1
ii  squashfs-tools 1:4.6.1-1

python3-binwalk suggests no packages.

-- no debconf information

Bug#1053154: mono-xsp4: needs perl dependency for postinst

[Andreas Beckmann]

Followup-For: Bug #1053154
Control: tag -1 sid trixie

This does not seem to be an issue on bookworm:

# aptitude why perl
i   mono-xsp4  Depends mono-xsp4-base (= 4.2-2.4)
i A mono-xsp4-base Depends mono-devel
i A mono-devel Depends libmono-cil-dev (= 6.8.0.105+dfsg-3.3)
i A libmono-cil-devDepends libnunit-cil-dev (>= 2.4)
i A libnunit-cil-dev   Depends libnunit-util2.6.3-cil (= 2.6.4+dfsg-1.1)
i A libnunit-util2.6.3-cil Depends cli-common (>= 0.5.6)
i A cli-common Depends perl


Andreas

Bug#1068014: urlwatch: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: urlwatch
Version: 2.28-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068013: telegram-send: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: telegram-send
Version: 0.37-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068012: python3-subliminal: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-subliminal
Version: 2.1.0-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068011: sqlfluff: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: sqlfluff
Version: 2.3.5-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068010: snakemake: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: snakemake
Version: 7.32.4-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068009: rope: Please replace python3-appdirs build-dependency with platformdirs

[Simon McVittie]

Source: rope
Version: 1.13.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

(I also notice that this package has a Build-Depends on python3-appdirs, but
not a Depends. Is this a mistake? I would be surprised for it to need
python3-appdirs at build-time but not at runtime.)

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068008: rustc: Please package rust 1.75 or higher

[Wesley Schwengle]

Package: rustc
Version: 1.70.0+dfsg1-9
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,


I was trying to build a rust package from source when I noticed they use
traits. Async traits are supported as of 1.75. It would be beneficial to Debian 
that
we can start developing rust with these traits.

Currently upstream sits at 1.77.x, it would be nice if we could get at least to
1.75 , but 1.77.x would be preferred.

https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html


Many thanks and cheers,
Wesley

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

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

Versions of packages rustc depends on:
ii  binutils  2.42-4
ii  gcc   4:13.2.0-7
ii  libc6 2.37-15.1
ii  libc6-dev [libc-dev]  2.37-15.1
ii  libgcc-s1 14-20240315-1
ii  libstd-rust-dev   1.70.0+dfsg1-9

Versions of packages rustc recommends:
ii  cargo0.70.1+ds1-3
ii  llvm-16  1:16.0.6-24

Versions of packages rustc suggests:
ii  clang-16  1:16.0.6-24
pn  lld-16

-- debconf-show failed

Bug#1068007: python3-satpy: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-satpy
Version: 0.47.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068006: qiime: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: qiime
Version: 2024.2.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068005: pytoolconfig: Please replace python3-appdirs build-dependency with platformdirs

[Simon McVittie]

Source: pytoolconfig
Version: 1.3.1-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

(I also notice that this package has a Build-Depends on python3-appdirs, but
not a Depends. Is this a mistake? I would be surprised for it to need
python3-appdirs at build-time but not at runtime.)

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068004: python3-pytools: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-pytools
Version: 2023.1.1-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068003: python3-ulmo: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-ulmo
Version: 0.8.8+dfsg1-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068002: python3-rply: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-rply
Version: 0.7.7-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068001: python3-requests-cache: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-requests-cache
Version: 0.9.8-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068000: python3-os-faults: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-os-faults
Version: 0.2.1-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067999: python3-openstacksdk: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-openstacksdk
Version: 1.5.0-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067998: python3-npe2: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-npe2
Version: 0.7.2-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067997: python3-miio: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-miio
Version: 0.5.12-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/