Bug#1053296: RFS: kcollectd/0.12.1-1 -- simple collectd graphing front-end for KDE

[Amin Bandali]

X-Debbugs-CC: Tobias Frost 

Hello Antonio,

Antonio Russo writes:

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "kcollectd":
>
>  * Package name : kcollectd
>Version  : 0.12.1-1
>Upstream contact : Antonio Russo 
>  * URL  : https://www.antonioerusso.com/projects/kcollectd
>  * License  : GFDL-1.3+, PUBLIC-DOMAIN, GPL-3+
>  * Vcs  : https://salsa.debian.org/qt-kde-team/extras/kcollectd
>Section  : utils
>
> The source builds the following binary packages:
>
>   kcollectd - simple collectd graphing front-end for KDE
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/kcollectd/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.12.1-1.dsc
>
> Changes since the last upload:
>
>  kcollectd (0.12.1-1) unstable; urgency=medium
>  .
>* New upstream release 0.12.1.
>   - Align translations with source code (Closes: #1048793)
>* Bump Standards-Version to 4.6.2, no changes required.
>
> Best,
> Antonio Russo
>
>

Thank you, looks good to me.  I've tested and I confirm that I can't
reproduce #1048793 with kcollectd 0.12.1-1.

Small feedback: please consider updating debian/copyright with the
current information/years in one of your future uploads. :-)

Tobi, would you please sponsor this to unstable?  Thanks in advance.

-a


signature.asc
Description: PGP signature

Bug#1053442: gcc-riscv64-unknown-elf: Compiler uses incorrect libraries if flags are given on -march

[Peter Chubb]

Package: gcc-riscv64-unknown-elf
Version: 12.2.0-14+11+b1
Severity: important

Dear Maintainer,

When building for softfloat targets, riscv64-unknown-elf-gcc can pick
the wrong multilib crtbegin.o and libgcc.a, etc.

Compare:
  $ riscv64-unknown-elf-gcc -march=rv64imac -mabi=lp64 --print-file-name 
crtbegin.o
  /usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64imac/lp64/crtbegin.o

with
  $ riscv64-unknown-elf-gcc -march=rv64imac_zicsr_zfencei -mabi=lp64 
--print-file-name crtbegin.o
  /usr/lib/gcc/riscv64-unknown-elf/12.2.0/crtbegin.o

The second and first should be the same, as the base architecture is
the same.

Symptom is:
   
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/../../../riscv64-unknown-elf/bin/ld: 
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/crtbegin.o: can't link double-float 
modules with soft-float modules

This appears to have been fixed before version 14 upstream.

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

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

Versions of packages gcc-riscv64-unknown-elf depends on:
ii  binutils-riscv64-unknown-elf  2.41-4+6
ii  libc6 2.37-11
ii  libgcc-s1 13.2.0-4
ii  libgmp10  2:6.3.0+dfsg-2
ii  libisl23  0.26-3
ii  libmpc3   1.3.1-1
ii  libmpfr6  4.2.1-1
ii  libstdc++613.2.0-4
ii  zlib1g1:1.2.13.dfsg-3

gcc-riscv64-unknown-elf recommends no packages.

gcc-riscv64-unknown-elf suggests no packages.

-- no debconf information

Bug#1053441: pavucontrol: Speaker balance destroyed by lower clamping

[Eric Towers]

Package: pavucontrol
Version: 5.0-2
Severity: normal
X-Debbugs-Cc: fuzzye...@gmail.com

Dear Maintainer,

I have a 5.1 speaker system.  The speakers are not and cannot be equally 
distant, so I set different volumes for each speaker in the sink USB Audio 
Speakers.  Since I find no way to set a virtual sink on the input of this sink 
that enforces the loudness ratios on the 6 channels, I use
pactl -- set-sink-volume @DEFAULT_SINK@ 55% 55% 70% 100% 89% 100% 100% 100% 
to set these ratios.  Note that the front left and front right channels are set 
to the lowest volume and the rear left to the next lowest volume and that these 
are -15.58 dB, -15.58 dB, and -9.29 dB, respectively.

I have a USB volume control that sends mute, volUp, and volDown keyboard 
events.  Since I want to retain the relative volumes, I have set these keyboard 
events to, respectively,
pactl -- set-sink-mute @DEFAULT_SINK@ toggle
pactl -- set-sink-volume @DEFAULT_SINK@ +1dB
pactl -- set-sink-volume @DEFAULT_SINK@ -1dB
(Offsetting by % or "magic pulseaudio" cubic values does not retain relative 
loudness.)  I'd like to change the volume by more that only +/- 1 dB, but using 
a larger increment with rapid volume changes is likely to exhibit the following 
defect.

When I turn the volume down far enough by this method (or equivalently using 
the above pactl commands repeatedly), so that the lowest three volumes are 
-222.15 dB (although the same number of dB should have been subtracted from all 
three) and the remainder are greater than -211 dB, turning the volume back up 
does not restore the relative loudness of the three channels that all clamped 
at -222.15 dB.  In fact, if it is reduced until all volumes clamp at -222.15 
dB, all volumes raise together.  In short, arithmetic does not work: 
subtracting and then adding the same numbers of 1 dBs does not return the 
speakers to the same relative loudness.
A similar behaviour happens when hitting the upper clamp at 3276800%(270.93 
db), destroying speaker balance.

I have not perfomed this test on a 2-channel output, but I suspect one could 
recreate the behaviour in that simpler setting with the two channels set to 
wildly different relative volumes, then pushing the volume up or down far 
enough to cause clamping, eliminating the difference.

Interestingly, until recently, the bahaviour in pavucontrol was to display 
"0%(-\infty dB)" when volumes got below about -120 dB, with the behaviour that 
once a finite number of negative increments had somehow sent the volume to 
-\infty, it was permanently trapped there and no amount of pactl ... +1dB would 
ever change that channel's volume again.  Additionally, this older version 
would upper-clamp at 150%, distorting balance when quickly raising volume 
overshot this bound.

PulseAudio does not document a virtual sink that could permanently store the 
attenuations to balance speakers.  pavucontrol displays the failure of 
PulseAudio to retain speaker balance and provides no mechanism to lock-in or 
enforce this balance.  pavucontrol is the only UI suitable for acquiring these 
ratios from users, but has no method to do so.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/48 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 pavucontrol depends on:
ii  libatkmm-1.6-1v5 2.28.3-1
ii  libc62.36-9+deb12u1
ii  libcanberra-gtk3-0   0.30-10
ii  libcanberra0 0.30-10
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.6-2
ii  libglibmm-2.4-1v52.66.5-2
ii  libgtk-3-0   3.24.37-2
ii  libgtkmm-3.0-1v5 3.24.7-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsigc++-2.0-0v52.12.0-1
ii  libstdc++6   12.2.0-14

Versions of packages pavucontrol recommends:
ii  pulseaudio  16.1+dfsg1-2+b1

pavucontrol suggests no packages.

-- no debconf information

Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)

[Amin Bandali]

Hiya,

Manphiz writes:

> Manphiz  writes:
>
>> Another finding is that in 28.x, if the term buffer have any further
>> questions to ask, debian-bug seems to consider the process stuck and
>> would just ignore everything and proceed.  In 29.x however, the term
>> buffer seems to be able to accept user input and can process the output
>> accordingly - even if the script requires sudo and prompt for password,
>> and debian-bug can properly include the output in the generated email
>> for bug report.  So with the merge request[4] it would instead skip all
>> potential additional information unfortunately.
>>
>
> Actually 28.x also works for user inputs if running term-exec without my
> problematic hooks so yeah!
>
>> As we do want to handle process termination better, while trying to keep
>> process from failing, I think temporarily disable term-exec-hook when
>> processing the output and restore after the report is generated should
>> probably work in most cases.  Just wondering whether this is acceptable
>> in the process of debian-bug?
>>
>
> Forgot to mention that this is implemented as the 2nd commit in the
> MR[4] and tested on bookworm and trixie to be working.
>
>> [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11

Thank you for the patch. :-)  This seems like a reasonable fix to me,
and if David has no comments or objections I'd be happy to merge it
in the coming days.

Quick request: would you please amend your patch/MR to add a
debian/changelog entry for the change(s)?  It would be good to
do a new upload soon, and it'd be nice to have debian/changelog
in tiptop shape for that.

Thanks,
-a

Bug#1053440: rust-sequoia-openpgp - incompatible with new regex-syntax.

[Peter Green]

Package: rust-sequoia-openpgp
Version: 1.16.0-3
Severity: serious

rust-sequoia-openpgp depends on an old version of regex-syntax, I tried bumping
the dependency but the build failed.

I have filed an issue about this upstream at
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1056

Bug#1053439: rsync: Please add support for specifying the SSH port used in SSH transfers

[Ron Murray]

Package: rsync
Version: 3.2.7-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   Please add support for specifying an SSH port other than 22 for SSH
transfers. The "--port=xxx" option only seems to affect rsync transfers.

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

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

Versions of packages rsync depends on:
ii  init-system-helpers1.65.2
ii  libacl12.3.1-3
ii  libc6  2.37-10
ii  liblz4-1   1.9.4-1
ii  libpopt0   1.19+dfsg-1
ii  libssl33.0.11-1
ii  libxxhash0 0.8.2-2
ii  libzstd1   1.5.5+dfsg2-2
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.08-1
ii  zlib1g 1:1.2.13.dfsg-3

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client   1:9.4p1-1
ii  openssh-server   1:9.4p1-1
ii  python3  3.11.4-5+b1
pn  python3-braceexpand  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmUcuqoOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52GQbw//UDSMfdB4waRUow/uTblDKgDMUPDwVFIbas0j
RmjFhe8Oj5SNzZrd340AsgkBZLeP0bGYVS/MtvfkCxutEDNnDtNmOfVHGkvuBQrZ
jvCKQ1T7kHRQJokTuRERm6zrS0hRWfZrYovd6KcRM70WAdMwCTGwFIiqHeYRGofa
jQz5TAUgKdbYRsoZM/VIRCb8P1d1mWW40O/1sGDyrHhxworU2J02VQQozo/CvaHt
OLakfl1/vAd/g2XwzFOwrc1ybIqjx6NWUMU5kV6HxTkPSBReBDXHsEWEJlzvQxes
3vGRmaT7d5oaJxERMtNMqJwk0JLkCzJL2SmOVVhgoX7t7Y9nvSAEbBn67BouOeON
LGcAvjOimjbdfiZcNcbHPX3+9H8is2qA3yjamtuTlQAbwIlD4qhgCUAuDBlrYcPy
pkmtV/L45pgzOtKuuCjL8OatLWCVBvDqRXmphydXaJ3K4WpW2HLO4stczdKlEZki
X/m6CB8HZ0qQfKBrII2jqCLc30afUVrwen9FCv5I6D7LRHELCuPyTBkd5cUVu4hb
LOsonBCGl1CZFe/F+/mvgm6Unv5YWM0lacrASXtBJK/iHbxMrtCCQ2tER5GIbl+b
qBIa80xpE3R7o0/SfVuHh0MhV6VIZYfyJiT1uQFQUzk/95l71qpA2j3ha9lf9TXn
+PM7fV8=
=ScwT
-END PGP SIGNATURE-

Bug#1053438: molly-guard: Support configuration management tools like Ansible

[Andrew Ruthven]

Package: molly-guard
Version: 0.7.2
Severity: wishlist
Tags: patch

Dear Maintainer,

While working on adding a snippet to molly-guard to check for running VMs
and prompt if there are any, we discovered that the standard approach for
systems managed by Ansible is to bypass molly-guard completely. See
https://docs.ansible.com/ansible/8/collections/ansible/builtin/reboot_module.html
and search for molly-guard.

We use Ansible, and I think this sucks, as I want molly-guard to protect
reboots for other situations.

I have modified molly-guard to detect being run by Ansible and not ask
questions, just exit 1 and refuse to take action. We have deployed this to
some of our fleet and have found it to work fine. Would you please consider
merging this change?

Changes are here:
  https://salsa.debian.org/puck/molly-guard/-/commits/conf-mgmt

This also includes patches for general housekeeping of the package.

In addition, I have considered whether the prompt logic and sigh() should
be moved into shutdown.in and allowed to be generic. I'd be interested to
hear your thoughts, and I'd be happy to have a punt at that.

Kind regards,
Andrew

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

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

Versions of packages molly-guard depends on:
ii  procps  2:4.0.2-3

molly-guard recommends no packages.

molly-guard suggests no packages.

-- no debconf information

Bug#1053437: opendmarc: Support for sqlite

[Guillem Jover]

Package: opendmarc
Version: 1.4.2-3
Severity: wishlist

Hi!

It looks like MySQL/MariaDB is only used by the reports/ scripts, and
the schema in db/schema.mysql is indeed MySQL specific.

It would be nice if these scrips could use SQLite instead (well in
addition that is).

Thanks,
Guillem

Bug#1051910: mirror submission for ossmirror.mycloud.services

[OSSMirror@OnboardCloud]

Hi Adam, Thanks for sharing. It seems that we have crossed the 50 mark and our mirror is listed! Do you know roughly how long does it usually take for the mirrors@ folks to check/reply amidst their busy schedule? Cheers, -Original Message-From: Adam D. Barratt Date: Friday, 29 September 2023 at 12:11 AMTo: OSSMirror@OnboardCloud , 1051...@bugs.debian.org <1051...@bugs.debian.org>Subject: Re: Bug#1051910: mirror submission for ossmirror.mycloud.servicesHi, mirrors@ is the correct address. I suspect people are simply busy.(Well, I know people are.) Regards, Adam On Thu, 2023-09-28 at 13:10 +0800, OSSMirror@OnboardCloud wrote:> Hi Adam,>  > Thanks for sharing. Looks like we are almost near the ½ way mark to> reaching 50 points today.>  > Separately, we have written in to mirr...@debian.org on 14/9 to ask> about hosting official “.country.” mirrors but did not receive any> reply till date. Do you know if we have written to the correct> address or are you able to refer us to the correct party to> discuss/review this?>  > Best regards,>  > -Original Message-> From: Adam D. Barratt > Date: Tuesday, 26 September 2023 at 1:54 AM> To: OSSMirror@OnboardCloud > Cc: 1051...@bugs.debian.org <1051...@bugs.debian.org>> Subject: Re: Bug#1051910: mirror submission for> ossmirror.mycloud.services> > Hi,>  > The published list is generated by an automated process that checks> on> the status of the mirror in recent days. You can see the current> status> of your mirror at> https://mirror-master.debian.org/status/mirror-info/ossmirror.mycloud.services.html>  > The score needs to reach at least 50 currently before the automation> will consider including it.>  > Regards,>  > Adam>  > On Mon, 2023-09-25 at 09:52 +0800, OSSMirror@OnboardCloud wrote:> > Hi Adam,> >  > > We were looking at the mirror listing and our mirror does not seem> to> > have been listed yet.> >  > > https://www.debian.org/mirror/list-full#SG> >  > >  > > May I enquire do you know roughly how long does it take for the> > mirror to be listed?> >  > > Best regards,> >  > > -Original Message-> > From: OSSMirror@OnboardCloud > > Date: Sunday, 24 September 2023 at 3:31 AM> > To: Adam D. Barratt > > Cc: 1051...@bugs.debian.org <1051...@bugs.debian.org>> > Subject: Re: Bug#1051910: mirror submission for> > ossmirror.mycloud.services> >> > Thanks Adam for the clarification and kind assistance!> >  > > On 24 Sep 2023, at 2:56 AM, Adam D. Barratt <> a...@adam-barratt.org.uk> > > wrote:> >  > > On Sun, 2023-09-24 at 01:57 +0800, OSSMirror@OnboardCloud wrote:> > > Hi Adam,> > >> > > Thanks for the reply. Could you elaborate further what do you> mean> > as> > > the /debian/ works:> > >> > > http://ossmirror.mycloud.services/debian/> > >> >  > > Ah, right - I was mislead by the index of> > http://ossmirror.mycloud.services implying that only /os/ existed,> > and> > didn't check for an alias.> >  > > Regards,> >  > > Adam> >  > >  > >  >  >  >  >  

Bug#1053436: dhcpcd-base: dhcpcd stops listening on port 68 after several days

[Ron Murray]

Package: dhcpcd-base
Version: 9.4.1-22
Severity: normal

Dear Maintainer,

   dhcpcd stops listening on udp port 68 after several days. Still
listening on raw port 17. I've tried re-installing the package and I
still get the same result.

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

Kernel: Linux 6.1.0-12-amd64 (SMP w/2 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 dhcpcd-base depends on:
ii  adduser   3.134
ii  libc6 2.36-9+deb12u3
ii  libudev1  252.12-1~deb12u1

Versions of packages dhcpcd-base recommends:
pn  wpasupplicant  

Versions of packages dhcpcd-base suggests:
pn  resolvconf | openresolv | systemd-resolved  

-- Configuration Files:
/etc/dhcpcd.conf changed:
allowinterfaces enp1s0
denyinterfaces enp3s0 enp4s4
ipv4only
debug
hostname
duid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
option interface_mtu
require dhcp_server_identifier
slaac private
nohook lookup-hostname, resolv.conf
noipv6rs# disable routing solicitation (says so in the 
man page)
interface enp1s0
ipv4only
interface enp3s0
ipv4only
static ip_address=192.168.14.1/23


-- no debconf information

Bug#1053435: opendmarc: No longer used OpenDBX Recommends

[Guillem Jover]

Source: opendmarc
Source-Version: 1.4.2-3
Severity: normal

Hi!

While checking this package I noticed that OpenDBX is no longer used,
as I see no references to it at all from the code, where the last ones
got removed in upstream commit 572cdedad70fb7101ee8a2c2ff58ce5e0b8435f0.

So it looks to me like the Recommends can be dropped.

Thanks,
Guillem

Bug#1053434: gettext does not extract strings inside Python f-strings

[Jonathan Kamens]

Package: gettext
Version: 0.21-13+b1
Severity: normal

Save this as /tmp/foo.py:

---cut here---
_("bare string")
f'{_("string inside f-string")}'
Dear Maintainer,
---cut here---

Run gettext on it. The resulting messages.po file will have "bare
string" but not "string inside f-string" in it.

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

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

Versions of packages gettext depends on:
ii  gettext-base   0.21-13+b1
ii  libc6  2.37-10
ii  libgomp1   13.2.0-4
ii  libunistring5  1.1-2
ii  libxml22.9.14+dfsg-1.3

Versions of packages gettext recommends:
ii  curl  8.2.1-2
ii  lynx  2.9.0dev.12-1
ii  wget  1.21.4-1+b1

Versions of packages gettext suggests:
ii  autopoint 0.21-13
pn  gettext-doc   
pn  libasprintf-dev   
pn  libgettextpo-dev  

-- no debconf information

Bug#1049455: Binutils: mips-gold patch was refreshed incorrectly

[YunQiang Su]

On Fri, 18 Aug 2023 09:48:44 +0200 Matthias Klose  wrote:
> Control: tags -1 + moreinfo
> 
> please get that accepted upstream, and then backported to the 2.41 branch.

I think that we can use '--enable-targets=all’ for all mips ports:

diff --git a/debian/rules b/debian/rules
index 7a5d4f5..5b133c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -531,29 +531,29 @@ CONFARGS_TARGET_riscv64   = --with-isa-spec=2.2
 
 CONFARGS_TARGET_kfreebsd-i386  = --enable-targets=x86_64-kfreebsd-gnu
 
-CONFARGS_TARGET_mips   = 
--enable-targets=mips64-linux-gnuabi64,mips64-linux-gnuabin32
+CONFARGS_TARGET_mips   = --enable-targets=all
 
-CONFARGS_TARGET_mipsel = 
--enable-targets=mips64el-linux-gnuabi64,mips64el-linux-gnuabin32 
--enable-mips-fix-loongson3-llsc=yes
+CONFARGS_TARGET_mipsel = --enable-targets=all 
--enable-mips-fix-loongson3-llsc=yes
 
-CONFARGS_TARGET_mipsn32= 
--enable-targets=mips64-linux-gnuabi64,mips-linux-gnu
+CONFARGS_TARGET_mipsn32= --enable-targets=all
 
-CONFARGS_TARGET_mipsn32el  = 
--enable-targets=mips64el-linux-gnuabi64,mipsel-linux-gnu 
--enable-mips-fix-loongson3-llsc=yes
+CONFARGS_TARGET_mipsn32el  = --enable-targets=all 
--enable-mips-fix-loongson3-llsc=yes
 
-CONFARGS_TARGET_mips64 = 
--enable-targets=mips64-linux-gnuabin32,mips-linux-gnu
+CONFARGS_TARGET_mips64 = --enable-targets=all
 
-CONFARGS_TARGET_mips64el   = 
--enable-targets=mips64el-linux-gnuabin32,mipsel-linux-gnu 
--enable-mips-fix-loongson3-llsc=yes
+CONFARGS_TARGET_mips64el   = --enable-targets=all 
--enable-mips-fix-loongson3-llsc=yes
 
-CONFARGS_TARGET_mipsr6 = 
--enable-targets=mipsisa64r6-linux-gnuabi64,mipsisa64r6-linux-gnuabin32
+CONFARGS_TARGET_mipsr6 = --enable-targets=all
 
-CONFARGS_TARGET_mipsr6el   = 
--enable-targets=mipsisa64r6el-linux-gnuabi64,mipsisa64r6el-linux-gnuabin32
+CONFARGS_TARGET_mipsr6el   = --enable-targets=all
 
-CONFARGS_TARGET_mipsn32r6  = 
--enable-targets=mipsisa64r6-linux-gnuabi64,mipsisa32r6-linux-gnu
+CONFARGS_TARGET_mipsn32r6  = --enable-targets=all
 
-CONFARGS_TARGET_mipsn32r6el= 
--enable-targets=mipsisa64r6el-linux-gnuabi64,mipsisa32r6el-linux-gnu
+CONFARGS_TARGET_mipsn32r6el= --enable-targets=all
 
-CONFARGS_TARGET_mips64r6   = 
--enable-targets=mipsisa64r6-linux-gnuabin32,mipsisa32r6-linux-gnu
+CONFARGS_TARGET_mips64r6   = --enable-targets=all
 
-CONFARGS_TARGET_mips64r6el = 
--enable-targets=mipsisa64r6el-linux-gnuabin32,mipsisa32r6el-linux-gnu
+CONFARGS_TARGET_mips64r6el = --enable-targets=all
 
 CONFARGS_TARGET_aarch64= --enable-targets=aarch64_be-linux-gnu
 

Bug#1052043: RM: rust-sequoia-net [mips64el ppc64el s390x] -- RoM; build-depends on rust-trust-dns-client which is NBS there

[Jeremy Bícha]

Control: tags -1 +moreinfo

I'm adding the moreinfo tag for the same reason as

https://bugs.debian.org/1053135

Thank you,
Jeremy Bícha

Bug#1053433: mate-panel: mate-clock segfaults on return from hibernation

[Olly Betts]

Package: mate-panel
Version: 1.27.1-2
Severity: normal

Frequently (but not every time) I unhibernate I get a pop up telling me
that mate-clock has crashed.  I do at least get the option to restart
it, and doing so has always worked so far.

I'm seeing this on two different machines now, and both i386 and amd64.
It's taken me a while to sit down and work out how to get a useful
backtrace, but I think it must have started with the update to 1.27.1-1
or 1.27.1-2.

(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7fa842435472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7fa84241f4b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7fa84276d5dd in  ()
#5  0x in  ()

I read that as it's already aborting when it segfaults, so maybe that's
not helpful in knowing the root cause.  I'm happy to debug further if
someone tells me what to try.

Cheers,
Olly

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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libatk1.0-0  2.49.91-2
ii  libc62.37-10
ii  libcairo21.17.8-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-1
ii  libgtk-3-0   3.24.38-5
ii  libgtk-layer-shell0  0.8.1-1
ii  libice6  2:1.0.10-1
ii  libmate-desktop-2-17 1.26.1-1
ii  libmate-menu21.26.0-3
ii  libmate-panel-applet-4-1 1.27.1-2
ii  libmateweather1  1.26.0-1.1
ii  libpango-1.0-0   1.51.0+ds-2
ii  librda0  0.0.5-1.1
ii  libsm6   2:1.2.3-1
ii  libwayland-client0   1.22.0-2.1
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.6-1
ii  libxrandr2   2:1.5.2-2+b1
ii  mate-desktop 1.26.1-1
ii  mate-menus   1.26.0-3
ii  mate-panel-common1.27.1-2
ii  mate-polkit  1.26.1-4

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#1053432: apt-listchanges: [INTL:pt] Update on Portuguese translation of MANPAGE

[Américo Monteiro]

Package: apt-listchanges
Version: 4.0
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for apt-listchanges's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro



apt-listchanges_4.0_pt.po.gz
Description: application/gzip

Bug#1033052: eviacam quits with "cvCreateCameraCapture doesn't support legacy API anymore"

[Olly Betts]

Control: forwarded -1 https://github.com/cmauri/eviacam/issues/22
Control: severity -1 serious

I'm raising the severity since important is defined as "a bug which has
a major effect on the usability of a package, without rendering it
completely unusable to everyone", but this bug means the eviacam package
is completely unusable to everyone.

https://github.com/cmauri/eviacam/pull/38 (which has been merged
upstream but isn't in a release yet) may fix this, but I haven't
attempted to test this (

Cheers,
Olly

Bug#1032647: nvidia-driver: Intermittent black screen after updating to 525.89.02-1

[Andreas Beckmann]

Followup-For: Bug #1032647
Control: severity -1 important

There have been no reports that this bug still happens with the current
525.* driver version, therefore I'm downgrading the severity to avoid
autoremoval.

Andreas

Bug#1053431: rust-grep-regex - depends/build-depends on old version of regex-syntax

[Peter Green]

Package: rust-grep-regex
Version: 0.1.11-1
Severity: serious

rust-grep-regex depends on an old version of rust-regex-syntax, this
is fixed in upstream git, but looking at the commit messages it's not
something I feel comfortable cherry-picking.

I have opened an upstream issue enquiring about the possibility of a
new release at https://github.com/BurntSushi/ripgrep/issues/2619

Bug#1053430: linux-source-6.1: No sound out of the box with the kernel 6.1.0-12 on Dell XPS 13 (SKU 0C10)

[Andrey Kamenshchikov]

Source: linux-source-6.1
Severity: important
X-Debbugs-Cc: akamenshchi...@gmail.com

Dear Maintainer,

Debian 12 comes with no sound (built-in speakers and microphone) on Dell XPS 13 
(SKU 0C10). This is an old issue and a patch is upstream for almost an year, 
see the thread:

https://lore.kernel.org/all/20221110225432.144184-1-pierre-louis.boss...@linux.intel.com/

In particular, these commits: 

https://lore.kernel.org/all/20221110225432.144184-2-pierre-louis.boss...@linux.intel.com/
https://lore.kernel.org/all/20221110225432.144184-3-pierre-louis.boss...@linux.intel.com/

The kernel 6.4.0-0 from backports has it in, so there is no issue there. But 
the basic Debian 12 kernel (6.1) doesn't have the patch applied, so manual 
patching and rebuilding the kernel is required after each kernel update. I did 
it and it proofed working.

Is it possible to add the patch to the future kernel 6.1 releases?

Thank you,
Andrey


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

Kernel: Linux 6.1.52 (SMP w/16 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)
LSM: AppArmor: enabled

-- no debconf information

Bug#1053429: rust-papergrid: autopkgtest failures

[Jeremy Bícha]

Source: rust-papergrid
Version: 0.10.0-1
Severity: serious

rust-papergrid cannot migrate to Testing because its autopkgtests are failing.

https://ci.debian.net/packages/r/rust-papergrid/testing/amd64/

Thank you,
Jeremy Bícha

Bug#1052487: aide-common: please recommend canonical "cron | cron-daemon"

[Alexandre Detiste]

Le mar. 3 oct. 2023 à 21:24, Marc Haber
 a écrit :
> I am just contemplating dropping the Recommends. A sysv system is likely
> to have cron installed anyway.

Then it's fine.

BTW: to make systemd-cron life easier, the .service/.timer
name has to exactly match the cron job name.

That is not possible if there is already a .service
for the daemon of this name.

So the heuristic table is the most
practical stop-gap thing to do.


Greets

Bug#1032462: ITA: argon2 -- memory-hard hashing function

[Sven Geuer]

X-Debbugs-CC: Debian QA Group , Samuel Henrique 
, Debian Security Tools Packaging Team 
, 

I forked the argon2 package from the Debian group [1] to my personal
projects [2] and started to work on it.

In the end I would like to maintain the package under the umbrella of
the Debian Security Tools Packaging Team.

@Samuel: Would you mind to create a repo under the group [3]?

[1] https://salsa.debian.org/debian/argon2
[2] https://salsa.debian.org/sven-geuer/argon2
[3] https://salsa.debian.org/pkg-security-team
-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1029944: A couple of patches

[Jeremy Sowden]

Control: tags -1 upstream fixed-upstream

On 2023-03-26, at 20:51:50 +0100, Jeremy Sowden wrote:
> Actually, it wasn't much more work to get all the failing tests to
> pass.  Version 2 of the patches attached.

Merged upstream:

  https://github.com/notroj/neon/pull/114

J.


signature.asc
Description: PGP signature

Bug#915583: fix release version contrast

[Stéphane Blondon]

Hi Russ,

> My inclination is to merge this in a future release of Policy.

I will clean the CSS file and add it to a new message to this bug
report to help the merge.


> The one minor thing that I noticed was that the version number of Policy
> in the left sidebar at the top is very difficult to read because it's
> almost the same color as the background.

You're right. I made a little patch on debian.css for improve it. It's
visible at http://stephane.yaal.fr/tmp/policy/

Other feedbacks are welcome!

-- 
Stéphane

Bug#1053314: Depends: python3-h5py-mpi without python3-h5py

[Nilesh Patra]

On Sun, 01 Oct 2023 15:25:43 +0200 Drew Parsons  wrote:

Package: xmds2
Version: 3.1.0+dfsg2-4
Severity: serious
Justification: debci

xmds2 Depends: python3-h5py-mpi without depending on python3-h5py

python3-h5py-mpi only provides the h5py._debian_h5py_mpi namespace,
not h5py.  Hence tests using h5py without specifying _debian_h5py_mpi
fail.  This is the case with h5py 3.9.0. (Marking Severity: serious due
to debci failure)

python3-h5py provides the h5py namespace, so if xmds2 strictly needs
the mpi build, but accessing via the generic h5py namespace, then the
Depends should specify both packages
  Depends: python3-h5py python3-h5py-mpi
  
  
Note there seems to be an inconsistency in the xmds2 package

configuration. It has MPI dependencies (python3-h5py-mpi, also
mpi-default-dev, libfftw3-mpi-dev), but with respect to hdf5 it has
 Depends: libhdf5-serial-dev
Should that instead be
 Depends: libhdf5-mpi-dev ?


Seems you're right, taking a brief look at it. I've CC'ed Rafael to further 
comment/upload a fix.

@Rafael, this seems to be the last blocker on h5py transition to testing, so 
prompt action would
be really cool!

Best,
Nilesh

Bug#1043153: empire-lafe: please consider upgrading to 3.0 source format

[Drake Diedrich]

Thanks Bastien.  I'm not currently using this package or set up to upload.


On Mon, Oct 2, 2023, 1:15 PM Bastian Germann  wrote:

> I am uploading a NMU to DELAYED/10 in order to fix this.
> Please find the debdiff attached.

Bug#1023519: python3-wxgtk4.0: Windows do not follow "dark" mode in Gnome

[Olly Betts]

Control: forwarded -1 https://github.com/wxWidgets/wxWidgets/pull/23764

On Mon, Jul 17, 2023 at 11:19:15AM -0400, Scott Talbert wrote:
> While evaluating this issue,
> it seems even a lot of native Gnome/GTK apps do not even provide a dark mode
> (e.g., even the gtk-demo application doesn't).  So it seems there is a lot
> of work still to be done here.

It looks like this has been implemented upstream very recently.  There
seem to be follow-on changes happening still (which also means it's
not a single patch to cherry-pick), so probably we just pick this up in
the next upstream release once it's stabilised.

Cheers,
Olly

Bug#1053428: RFP: k9s -- Kubernetes CLI To Manage Your Clusters In Style!

[Luca Matei Pintilie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: l...@lucamatei.com

* Package name: k9s
  Version : 0.27.4
  Upstream Author : Fernand Galiana 
* URL : https://k9scli.io/
* License : Apache-2.0
  Programming Lang: Go
  Description : Kubernetes CLI To Manage Your Clusters In Style!

K9s provides a terminal UI to interact with your Kubernetes clusters.
The aim of this project is to make it easier to navigate, observe and
manage your applications in the wild. K9s continually watches Kubernetes
for changes and offers subsequent commands to interact with your observed
resources.

This package would be used by kubernetes administrators running debian.

It's a TUI alternative to kubectl, and it depends on it as well.
As far as I can tell kubectl is not packaged for debian at this time
either.

I do not have any intentions of maintaining the package.

Please consider adding k9s.

Best regards,
Luca


signature.asc
Description: PGP signature

Bug#1053427: firefox-esr: YubiKey stopped working on firefox-esr, but works on firefox from official website

[Yaroslav Molochko]

Package: firefox-esr
Version: 115.2.1esr-1
Severity: normal
X-Debbugs-Cc: ono...@gmail.com

Dear Maintainer,

After the upgrade few versions back, my YubiKey become unusable, but
firefox downloaded from official mozilla site - keeps working. 

You can reproduce it on: https://demo.yubico.com/webauthn-technical/registration
My firefox-esr reports:

> The request is not allowed by the user agent or the platform in the current 
> context,
> possibly because the user denied permission.

firefox from main site - does registration and authentication without
any problem. 

This impacts my personal and most probably others experience and
security. 

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (600, 'unstable'), (500, 'oldstable-updates'), 
(500, 'oldstable-security'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.13
ii  fontconfig   2.14.2-6
ii  libasound2   1.2.9-2
ii  libatk1.0-0  2.49.91-2
ii  libc62.37-10
ii  libcairo-gobject21.17.8-3
ii  libcairo21.17.8-3
ii  libdbus-1-3  1.14.10-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-2
ii  libgtk-3-0   3.24.38-5
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libpango-1.0-0   1.51.0+ds-2
ii  libstdc++6   13.2.0-4
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.3-1
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages firefox-esr recommends:
ii  libavcodec58  10:4.4.4-dmo5
ii  libavcodec59  10:5.1.3-dmo6
ii  libavcodec60  10:6.0-dmo9

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-4
pn  pulseaudio 

-- no debconf information

Bug#1053426: vlc: interface insists on using wrong locale language

[boruch baum]

Package: vlc
Version: 3.0.18-2
Severity: minor
Tags: l10n
X-Debbugs-Cc: boruch_b...@gmx.com

Dear Maintainer,

Ever since upgrading to bookworm, vlc has been presenting its
interface in my secondary locale. I can remediate this as follows:

  LC_ALL="garbage-value" vlc

Using a valid value for LC_ALL, ie. en_US.UTF-8, does not fix the
issue.

The only other command for which I've noticed a similar issue is the
'su' command of debian package 'util-linux'.

-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (680, 'stable-security'), (660, 'stable-updates'), (650, 
'stable'), (500, 'oldstable-security'), (450, 'testing'), (400, 'oldstable'), 
(300, 'oldoldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.18-2
ii  vlc-plugin-base  3.0.18-2
ii  vlc-plugin-qt3.0.18-2
ii  vlc-plugin-video-output  3.0.18-2

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.18-2
ii  vlc-plugin-access-extra3.0.18-2
ii  vlc-plugin-notify  3.0.18-2
ii  vlc-plugin-samba   3.0.18-2
ii  vlc-plugin-skins2  3.0.18-2
ii  vlc-plugin-video-splitter  3.0.18-2
ii  vlc-plugin-visualization   3.0.18-2

Versions of packages vlc suggests:
ii  vlc-plugin-fluidsynth  3.0.18-2
pn  vlc-plugin-jack
pn  vlc-plugin-pipewire
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.36-9+deb12u3
ii  libvlc5  3.0.18-2

Versions of packages libvlc5 depends on:
ii  libc62.36-9+deb12u3
ii  libvlccore9  3.0.18-2

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.18-2

Versions of packages vlc-bin depends on:
ii  libc6   2.36-9+deb12u3
ii  libvlc-bin  3.0.18-2
ii  libvlc5 3.0.18-2

Versions of packages vlc-plugin-access-extra depends on:
ii  libc62.36-9+deb12u3
ii  libsrt1.5-gnutls 1.5.3-1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.18-2
ii  libvncclient10.9.14+dfsg-1
ii  libxcb-composite01.15-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.6.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.8-1+b1
ii  libass9  1:0.17.1-1
ii  libavahi-client3 0.8-10
ii  libavahi-common3 0.8-10
ii  libavc1394-0 0.5.4-5
ii  libavcodec59 7:5.1.3-1
ii  libavformat597:5.1.3-1
ii  libavutil57  7:5.1.3-1
ii  libbluray2   1:1.3.4-1
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2+b1
ii  libdav1d61.0.0-2
ii  libdbus-1-3  1.14.8-2~deb12u1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.4-1
ii  libfaad2 2.10.1-1
ii  libflac121.4.2+ds-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s113.2.0-4
ii  libgcrypt20  1.10.1-3
ii  libglib2.0-0 2.78.0-2
ii  libgnutls30  3.8.1-4+b1
ii  libgpg-error01.46-1
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-7.2
ii  liblua5.2-0  5.2.4-3
ii  libmad0  0.15.1b-10.1+b1
ii  libmatroska7 1.7.1-1
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.31.2-1
ii  libmtp9  1.1.20-1
ii  

Bug#1053425: util-linux: su uses wrong locale for interface

[boruch baum]

Package: util-linux
Version: 2.38.1-5+b1
Severity: minor
Tags: l10n
X-Debbugs-Cc: boruch_b...@gmx.com

Dear Maintainer,

I have two locales installed on my system, with the contents of
/etc/default/locale as follows:

LANG=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_ALL=en_US.UTF-8

Ever since upgrading to bookworm, the su command asks for a password
in the language of one of the alternate locales, ie. not English.

Note 1: This can be remediated by replacing prefacing the command with
LC_ALL=posix or LC_ALL=C LC_ALL="garbage-variable-contents"

   LC_ALL=posix su -

Note 2: Prefacing the command with LC_ALL=en_US.UTF-8 does NOT fix the
issue.

Note 3: No other tested util-linux commands display a similar bug.

Note 4: Only one other command seems to have a similar bug, and it can
be remediated the same way: vlc.


-- System Information:
Debian Release: 12.1
  APT prefers stable-security
  APT policy: (680, 'stable-security'), (660, 'stable-updates'), (650, 
'stable'), (500, 'oldstable-security'), (450, 'testing'), (400, 'oldstable'), 
(300, 'oldoldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages util-linux depends on:
ii  libblkid1 2.38.1-5+b1
ii  libc6 2.36-9+deb12u3
ii  libcap-ng00.8.3-1+b3
ii  libcrypt1 1:4.4.33-2
ii  libmount1 2.38.1-5+b1
ii  libpam0g  1.5.2-6
ii  libselinux1   3.4-1+b6
ii  libsmartcols1 2.38.1-5+b1
ii  libsystemd0   252.12-1~deb12u1
ii  libtinfo6 6.4-4
ii  libudev1  252.12-1~deb12u1
ii  libuuid1  2.38.1-5+b1
ii  util-linux-extra  2.38.1-5+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.17+nmu1

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1+b1
ii  util-linux-locales  2.38.1-5

-- no debconf information

Bug#1053306: libxapp1: xapp-sn-watcher.desktop file should be in the xapp-sn-watcher debian package

[Fabio Fantoni]

Il 03/10/2023 21:21, Alban Browaeys ha scritto:

$ apt policy libxapp1
libxapp1:
   Installé : 2.6.1-1
   Candidat : 2.6.1-1
  Table de version :
  *** 2.6.1-1 500
  90 http://ftp.debian.org/debian sid/main amd64 Packages
 500 http://deb.debian.org/debian trixie/main amd64 Packages
 100 /var/lib/dpkg/status
  2.4.2-3 500
 500 http://deb.debian.org/debian bookworm/main amd64 Packages
  1.2.2-1 500
 500 http://httpredir.debian.org/debian buster/main amd64 Packages

ls /etc/xdg/autostart/xapp-sn-watcher.desktop
/etc/xdg/autostart/xapp-sn-watcher.desktop

dpkg -S  /etc/xdg/autostart/xapp-sn-watcher.desktop
libxapp1:amd64: /etc/xdg/autostart/xapp-sn-watcher.desktop

dpkg-query -W -f='${Conffiles}\n' | grep obsolete$ |grep xapp-sn
  /etc/xdg/autostart/xapp-sn-watcher.desktop a9fa3be7aaf46761adcdb856c63c125f 
obsolete


It could still be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389
still all the report I found in it, tell the files are owned by the new
package but still marked as obsolete.

Here, the file is still owned by the old package. I do not even have
the new package xapp-sn-watcher installed.

So maybe it is the same bug but without installing the new package the
ownership is also not removed from the old package.
This might help define the origin of this bug.

Cheers,
Alban

this is for xapp-sn-watcher not installed in this case rm_conffile will 
works correctly but installing also xapp-sn-watcher will remove 
xapp-sn-watcher.desktop broking it after the upgrade so I couldn't do it 
as I wrote, I did some tests looking for a workaround but unfortunately 
I didn't find any and the "best" solution was to not to use rm_conffile.


after this new issue (with people that don't install recommends) I 
thinked about increase to depends but I think is a problem have circular 
depends (xapp-sn-watcher depends on libxapp1)


so I suppose that the best thing it would fix that old bug in dpkg, but 
I don't know how


or someone have another idea? any advice is welcome



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1053424: cargo: flaky autopkgtest:

[Paul Gevers]

Source: cargo
Version: 0.66.0+ds1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it fails very often.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

E.g.
https://ci.debian.net/data/autopkgtest/testing/armhf/c/cargo/38257775/log.gz

401s failures:
401s publish::api_error_200
401s publish::api_other_error
401s
401s test result: FAILED. 2461 passed; 2 failed; 142 ignored; 0 
measured; 0 filtered out; finished in 199.82s



https://ci.debian.net/data/autopkgtest/testing/amd64/c/cargo/38436894/log.gz

183s failures:
183s
183s  credential_process::publish stdout 
183s running 
`/tmp/autopkgtest-lxc.37ebfcox/downtmp/build.Dyo/src/target/debug/cargo 
build`
183s running 
`/tmp/autopkgtest-lxc.37ebfcox/downtmp/build.Dyo/src/target/debug/cargo 
publish --no-verify --registry alternative -Z credential-process`

183s req: Request {
183s url: Url {
183s scheme: "http",
183s cannot_be_a_base: false,
183s username: "",
183s password: None,
183s host: Some(
183s Ipv4(
183s 127.0.0.1,
183s ),
183s ),
183s port: Some(
183s 39447,
183s ),
183s path: "/api/v1/crates/new",
183s query: None,
183s fragment: None,
183s },
183s method: "put",
183s authorization: Some(
183s "sekrit",
183s ),
183s if_modified_since: None,
183s if_none_match: None,
183s }
183s thread 'credential_process::publish' panicked at '
183s test failed running 
`/tmp/autopkgtest-lxc.37ebfcox/downtmp/build.Dyo/src/target/debug/cargo 
publish --no-verify --registry alternative -Z credential-process`

183s error: process exited with code 101 (expected 0)
183s --- stdout
183s
183s --- stderr
183s Updating `alternative` index
183sPackaging foo v0.1.0 
(/tmp/autopkgtest-lxc.37ebfcox/downtmp/build.Dyo/src/target/tmp/cit/t810/foo)
183sUploading foo v0.1.0 
(/tmp/autopkgtest-lxc.37ebfcox/downtmp/build.Dyo/src/target/tmp/cit/t810/foo)

183s error: failed to publish to registry at http://127.0.0.1:39447/
183s
183s Caused by:
183s   [55] Failed sending data to the peer (Send failure: Broken pipe)
183s ', tests/testsuite/credential_process.rs:203:10
183s note: run with `RUST_BACKTRACE=1` environment variable to display a 
backtrace

183s
183s
183s failures:
183s credential_process::publish
183s
183s test result: FAILED. 2463 passed; 1 failed; 142 ignored; 0 
measured; 0 filtered out; finished in 68.41s



https://ci.debian.net/data/autopkgtest/testing/i386/c/cargo/38284747/log.gz

2413s failures:
2413s
2413s  credential_process::publish stdout 
2413s running 
`/tmp/autopkgtest-lxc.8p0qkl9z/downtmp/build.rLB/src/target/debug/cargo 
build`
2413s running 
`/tmp/autopkgtest-lxc.8p0qkl9z/downtmp/build.rLB/src/target/debug/cargo 
publish --no-verify --registry alternative -Z credential-process`

2413s req: Request {
2413s url: Url {
2413s scheme: "http",
2413s cannot_be_a_base: false,
2413s username: "",
2413s password: None,
2413s host: Some(
2413s Ipv4(
2413s 127.0.0.1,
2413s ),
2413s ),
2413s port: Some(
2413s 44181,
2413s ),
2413s path: "/api/v1/crates/new",
2413s query: None,
2413s fragment: None,
2413s },
2413s method: "put",
2413s authorization: Some(
2413s "sekrit",
2413s ),
2413s if_modified_since: None,
2413s if_none_match: None,
2413s }
2413s thread 'credential_process::publish' panicked at '
2413s test failed running 
`/tmp/autopkgtest-lxc.8p0qkl9z/downtmp/build.rLB/src/target/debug/cargo 
publish --no-verify --registry alternative -Z credential-process`

2413s error: process exited with code 101 (expected 0)
2413s --- stdout
2413s
2413s --- stderr
2413s Updating `alternative` index
2413sPackaging foo v0.1.0 
(/tmp/autopkgtest-lxc.8p0qkl9z/downtmp/build.rLB/src/target/tmp/cit/t810/foo)
2413sUploading foo v0.1.0 
(/tmp/autopkgtest-lxc.8p0qkl9z/downtmp/build.rLB/src/target/tmp/cit/t810/foo)

2413s error: failed to publish to registry at http://127.0.0.1:44181/
2413s
2413s Caused by:
2413s   [55] Failed sending data to the peer (Send failure: Broken pipe)
2413s ', tests/testsuite/credential_process.rs:203:10
2413s note: run with `RUST_BACKTRACE=1` environment variable to display 
a backtrace

2413s
2413s
2413s failures:
2413s credential_process::publish
2413s
2413s test result: FAILED. 2462 passed; 1 failed; 142 

Bug#1053394: dash should not propagate aliases to subshells

[Lawrence Velázquez]

On Tue, Oct 3, 2023, at 5:54 AM, Дилян Палаузов wrote:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03_01
>  
> says:
>
> 2.3.1 Alias Substitution
>
> When used as specified by this volume of POSIX.1-2017, alias definitions 
> shall not be inherited by separate invocations of the shell or by the 
> utility execution environments invoked by the shell.
>
>
> So a subshell shall have no knowledge about the aliases from the 
> supershell

You are mistaken; subshells are not "separate invocations".  See
section 2.12:

A subshell environment shall be created as a duplicate of
the shell environment, except that signal traps that are
not being ignored shall be set to the default action.

> These programs
>
> #!/bin/bash
> alias wslpath=echo
> find `wslpath /tmp`
>
> and
>
> #!/bin/dash
> alias wslpath=echo
> find `wslpath /tmp`
>
> produce different results (bash 5.2.15-3.fc38,  dash 0.5.12-1.fc38) when 
> executed on a WSL2 system.  The former program shows the content of the 
> current directory, the latter program shows the content of /tmp .

That is because aliases are not expanded at all in noninteractive
bash "native mode" shells.  If you were to run bash as "sh" or with
its "--posix" option, then you would see the same behavior as with
dash.

-- 
vq

Bug#1028157: cython: please upgrade to 3.0.0 alpha

[Boyuan Yang]

Control: affects -1 src:compreffor

On Sat, 07 Jan 2023 17:27:26 -0500 Sandro Tosi  wrote:
> Source: cython
> Severity: normal
> X-Debbugs-Cc: mo...@debian.org
> 
> Hello,
> packages are starting to depend on 3.0.0~aX of cython, f.e.
> python-levenshtein, 
> https://github.com/maxbachmann/Levenshtein/blob/main/pyproject.toml#L5
> 
> please package that new upstream release

Just to let you know that I am starting to encounter packages that require 
cython 3.x
in their new releases. While doing patches is available, it would really be 
great
if cython 3.x is available somewhere in Debian, either as separate source 
package
or not. Thank you for your work!

Best Regards,
Boyuan Yang


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

Bug#1052487: aide-common: please recommend canonical "cron | cron-daemon"

[Marc Haber]

On Tue, Oct 03, 2023 at 04:33:37PM +0200, Alexandre Detiste wrote:
>  a écrit :
> > On systemd systems, aide already uses a systemd timer. Given that the
> > users of other init systems have to do manual work anyway, I intend to
> > fully drop the cron dependency with one of the next uploads.
> >
> > Is that the right thing to do from your point of view, and would you
> > recommend doing so?
> 
> I don't recommend breaking non-systemd systems.
> 
> I guess it's better for them a cron job with sane defaults than nothing.

I am just contemplating dropping the Recommends. A sysv system is likely
to have cron installed anyway.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1053423: src:alex: fails to migrate to testing for too long: B-D missing on i386 and involved in haskell transition

[Paul Gevers]

Source: alex
Version: 3.2.7.1-3
Severity: serious
Control: close -1 3.3.0.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:alex has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable can't be 
build on i386 and the package is also involved in the ongoing stalled 
haskell transition.


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053421: src:sreview: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: sreview
Version: 0.9.0-1
Severity: serious
Control: close -1 0.9.2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1052919

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053422: src:nautilus: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: nautilus
Version: 44.2.1-2
Severity: serious
Control: close -1 45.0-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1050733

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053306: libxapp1: xapp-sn-watcher.desktop file should be in the xapp-sn-watcher debian package

[Alban Browaeys]

On Sun, 1 Oct 2023 13:49:56 +0200 Fabio Fantoni
 wrote:
> Il 01/10/2023 12:33, Alban Browaeys ha scritto:
> > Package: libxapp1
> > Version: 2.6.1-1
> > Severity: normal
> >
> > Dear Maintainer,
> > I get this error in my logs:
> > oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]:
Exec binary '/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-
watcher' does not exist: No such file or directory
> > oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]:
/etc/xdg/autostart/xapp-sn-watcher.desktop: not generating unit, error
parsing Exec= line: No such file or directory
> >
> > it turns out I have libxapp1:amd64 2.6.1-1 installed but not xapp-
sn-watcher.
> >
> > I believe the xapp-sn-watcher.desktop shipped by libxapp1 should be
shipped by
> > the xapp-sn-watcher package.
> 
> Hi, from the version you are reporting xapp-sn-watcher.desktop is 
> already in xapp-sn-watcher package: 
> https://packages.debian.org/sid/amd64/xapp-sn-watcher/filelist
> 
> file was moved latest time in 2.4.2-1 (from xapp package) and first
time 
> in 2.2.6-1 (from libxapp1)
> 
> I suppose the issue you spotted is related to old conffile moved (in 
> case your system was upgraded and was installed intially with version
< 
> 2.2.6-1, where there was the first move from libxapp1), relating to
it 
> there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983441 but
is 
> blocked by another bug in dpkg (that I'm unable to fix it) and as
wrote 
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389 is 
> impossible use rm_conffile in case of move from one binary package to
> another of the same source or the file of the new package will be 
> removed broking it
> 
> since the unexpected case you spotted is more that simply "mark as 
> obsolete" I think is good to reply on bug #886389 that now seems 
> considered minor and without progress
> 

I reported to both bug reports because there is something specific to
my issue.

In my case the desktop file is not only marked as obsolete in the
database. It is also still marked as owned by the old package libxapp1
... weird:

$ dpkg -L libxapp1  

 
/.  
   
/usr
   
/usr/lib

  
/usr/lib/x86_64-linux-gnu   
   
/usr/lib/x86_64-linux-gnu/libxapp.so.2.6.1  

  
/usr/share  
   
/usr/share/doc  
   
/usr/share/doc/libxapp1 
   
/usr/share/doc/libxapp1/changelog.Debian.gz 
   
/usr/share/doc/libxapp1/changelog.gz
   
/usr/share/doc/libxapp1/copyright   
   
/usr/lib/x86_64-linux-gnu/libxapp.so.1  
   
/etc/xdg/autostart/xapp-sn-watcher.desktop 


$ apt policy libxapp1   

 
libxapp1:   
   
  Installé : 2.6.1-1

  
  Candidat : 2.6.1-1

  
 Table de version : 
   
 *** 2.6.1-1 500
   
 90 http://ftp.debian.org/debian sid/main amd64 Packages
   
500 http://deb.debian.org/debian trixie/main amd64 Packages 
   
100 /var/lib/dpkg/status
   
 2.4.2-3 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
 1.2.2-1 500
500 http://httpredir.debian.org/debian buster/main amd64 

Bug#1053420: rust-matchers - incompatible with mew regex-automata

[Peter Green]

Package: rust-matchers
Version: 0.1.0-1
Severity: serious
tas: trixie, sid

rust-regex-automata was recently updated to 0.3, rendering
the dependencies and build-dependencies of rust-matchers
uninstallable.

The changes seem to be fairly major, there is an upstream
pull request but details are still being discussed, so I
don't think we should pull it into Debian at this time.

Bug#1053419: unblock: glibc/2.37-12

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: security
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gl...@packages.debian.org
Control: affects -1 + src:glibc

[ Reason ]
glibc/2.37-12 fixes a local root vulnerability, I believe the package
should migrate as soon as the possible in testing, bypassing the debci
tests.

[ Impact ]
Users of testing will be left with a local root vulnerability.

[ Tests ]
The testsuite has been updated to check for the security issue. In
addition manual testing has been done to confirm the security
vulnerability has been fixed.

[ Risks ]
The diff between glibc/2.37-11 and glibc/2.37-12 are minimal, with the
exception of XFAILing a test on hurd-i386, and slightly adjusting the
allowed accuracy in the test of the y0_towardzero function.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Without packages with flaky autopkgtests, glibc/2.37-11 should have been
in testing for a few days already, so I have considered that version as
a basis for filling this unblock.
diff --git a/debian/changelog b/debian/changelog
index deca040f..c3f116c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+glibc (2.37-12) unstable; urgency=critical
+
+  [ Samuel Thibault ]
+  * debian/testsuite-xfail-debian.mk: Update xfails for hurd-i386.
+
+  [ Aurelien Jarno ]
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix a buffer overflow in the dynamic loader's processing of the
+  GLIBC_TUNABLES environment variable (CVE-2023-4911).
+  * Set urgency to critical given the security issue.
+
+ -- Aurelien Jarno   Tue, 03 Oct 2023 19:14:06 +0200
+
 glibc (2.37-11) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff --git a/debian/patches/git-updates.diff b/debian/patches/git-updates.diff
index d8549680..ecaf3162 100644
--- a/debian/patches/git-updates.diff
+++ b/debian/patches/git-updates.diff
@@ -1,10 +1,10 @@
 GIT update of https://sourceware.org/git/glibc.git/release/2.37/master from 
glibc-2.37
 
 diff --git a/NEWS b/NEWS
-index ad5196a5f1..3725cc4820 100644
+index ad5196a5f1..b351537a78 100644
 --- a/NEWS
 +++ b/NEWS
-@@ -5,6 +5,50 @@ See the end for copying conditions.
+@@ -5,6 +5,55 @@ See the end for copying conditions.
  Please send GNU C library bug reports via 
  using `glibc' in the "product" field.
  
@@ -34,6 +34,11 @@ index ad5196a5f1..3725cc4820 100644
 +  an application calls getaddrinfo for AF_INET6 with AI_CANONNAME,
 +  AI_ALL and AI_V4MAPPED flags set.
 +
++  CVE-2023-4911: If a tunable of the form NAME=NAME=VAL is passed in the
++  environment of a setuid program and NAME is valid, it may result in a
++  buffer overflow, which could be exploited to achieve escalated
++  privileges.  This flaw was introduced in glibc 2.34.
++
 +The following bugs are resolved with this release:
 +
 +  [20975] Deferred cancellation triggers in __check_pf and looses lock 
leading to deadlock
@@ -55,7 +60,7 @@ index ad5196a5f1..3725cc4820 100644
  Version 2.37
  
  Major new features:
-@@ -105,6 +149,8 @@ The following bugs are resolved with this release:
+@@ -105,6 +154,8 @@ The following bugs are resolved with this release:
  coincides with offset change
[30039] stdio: __vsprintf_internal does not handle unspecified buffer
  length in fortify mode
@@ -638,6 +643,42 @@ index d35a725415..32a8bfcf74 100644
  #endif
  
/* Store the result for later runs.  */
+diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c
+index 327b9eb52f..985b69c180 100644
+--- a/elf/dl-tunables.c
 b/elf/dl-tunables.c
+@@ -187,11 +187,7 @@ parse_tunables (char *tunestr, char *valstring)
+   /* If we reach the end of the string before getting a valid name-value
+pair, bail out.  */
+   if (p[len] == '\0')
+-  {
+-if (__libc_enable_secure)
+-  tunestr[off] = '\0';
+-return;
+-  }
++  break;
+ 
+   /* We did not find a valid name-value pair before encountering the
+colon.  */
+@@ -251,9 +247,16 @@ parse_tunables (char *tunestr, char *valstring)
+   }
+   }
+ 
+-  if (p[len] != '\0')
+-  p += len + 1;
++  /* We reached the end while processing the tunable string.  */
++  if (p[len] == '\0')
++  break;
++
++  p += len + 1;
+ }
++
++  /* Terminate tunestr before we leave.  */
++  if (__libc_enable_secure)
++tunestr[off] = '\0';
+ }
+ #endif
+ 
 diff --git a/elf/dl-tunables.list b/elf/dl-tunables.list
 index a685f5cdbc..695ba7192e 100644
 --- a/elf/dl-tunables.list
@@ -999,6 +1040,97 @@ index f6ab991398..f6dfbbe202 100644
/* Verify that dlmopen creates a new namespace.  */
void *dlmopen_handle = xdlmopen (LM_ID_NEWLM, LIBC_SO, RTLD_NOW);
TEST_VERIFY (dlmopen_handle != handle);
+diff --git a/elf/tst-env-setuid-tunables.c 

Bug#1053418: RM: libppd -- ROM; Dead upstream, binary package name collision

[Christoph Biedl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: lib...@packages.debian.org, g...@packages.debian.org, 
till.kamppe...@gmail.com, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:libppd

Greetings,

As previously announced in #1052056 ("Intent To Remove: src:libppd"),
I'm asking you to remove the libppd package from Debian unstable.

The ressons boil down to:

First, upstream is dead, last release was in 2002-ish (by looking at
the latest timestamp in the orig.tar).

Second, some binary package names collide with a different libppd
implementation provided by CUPS. Several months ago I made an attempt to
resolve this by renaming the package here, but I gave up on this -
besides some obstacles I've changed my mind and doubt all this was worth
the efforts. (An RM for that libppd-legacy package will follow shortly.)


There is one reverse dependency outstide src:libppd, it's the gpr
package. It's likewise upstream-dead and dropped out of testing
recently for other reasons, and I doubt it's going to come back. The
maintainer was included in the Intent To Remove above, no reaction.

Christoph (maintainer of src:libppd)


signature.asc
Description: PGP signature

Bug#1043085: cl-getopt: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cl-getopt-1.2.0/debian/changelog cl-getopt-1.2.0/debian/changelog
--- cl-getopt-1.2.0/debian/changelog2023-10-03 20:43:21.0 +0200
+++ cl-getopt-1.2.0/debian/changelog2023-10-03 20:39:16.0 +0200
@@ -1,3 +1,10 @@
+cl-getopt (1.2.0-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0 (Closes: #1043085).
+
+ -- Bastian Germann   Tue, 03 Oct 2023 20:39:16 +0200
+
 cl-getopt (1.2.0-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cl-getopt-1.2.0/debian/source/format 
cl-getopt-1.2.0/debian/source/format
--- cl-getopt-1.2.0/debian/source/format1970-01-01 01:00:00.0 
+0100
+++ cl-getopt-1.2.0/debian/source/format2023-10-03 20:39:12.0 
+0200
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1053417: debian-mirror.sakura.ne.jp: want to make it "Hub" mirror in JP region

[Hideki Yamane]

Package: mirrors
Severity: wishlist
X-Debbugs-Cc: henr...@debian.org

Dear mirror admins,

 I'm admin of debian-mirror.sakura.ne.jp.
 Until June, hanzubon.jp pushed repository changes to it, but unfortunately
 with some reasons hanzubon.jp was terminated and there's no upstream mirror
 in JP region. So, I want to step up to it.

 Could you help me to set up, please?

-- 
Regards,

 Hideki Yamane 

Bug#1043084: chrootuid: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU in order to fix this.
The debdiff is attached.diff -Nru chrootuid-1.3/chrootuid.1 chrootuid-1.3/chrootuid.1
--- chrootuid-1.3/chrootuid.1   2023-10-03 20:34:41.0 +0200
+++ chrootuid-1.3/chrootuid.1   2001-07-25 18:46:59.0 +0200
@@ -8,7 +8,7 @@
 .SH SYNOPSIS
 .na
 .nf
-\fBchrootuid\fR [-i] \fInewroot newuser command\fR...
+\fBchrootuid\fR \fInewroot newuser command\fR...
 .SH DESCRIPTION
 .ad
 .fi
@@ -24,32 +24,19 @@
 in the restricted environment.
 
 Only the superuser can use the \fBchrootuid\fR command.
-
-.SH OPTIONS
-.ad
-.fi
-There is only one option for \fBchrootuid\fR: -i. That option makes it
-run in \fIinteractive\fR mode. Errors will be printed on stderr instead of 
through 
-syslog and the exit status will be 1 if there are any errors.
-
-.SH RETURN CODES
-.ad
-.fi
-The exit status of \fBchrootuid\fR when running on \fIdaemon\fR mode 
-(default) is always 0. 
-
-If it is running on \fIinteractive\fR mode, it will exit with an exit status of
-1 if there is any error in its invocation, otherwise the exit status is the
-exit status of \fIcommand\fR.
 .SH DIAGNOSTICS
 .ad
 .fi
-Problems are reported to the syslog daemon if running on \fIdaemon\fR mode.
-If running on \fIinteractive\fR mode, errors are reported on stderr.
+The exit status is 1 when \fBchrootuid\fR has a problem, otherwise
+the exit status is the exit status of \fIcommand\fR.
 .SH SEE ALSO
 .na
 .nf
 chroot(8), su(1)
+.SH DIAGNOSTICS
+.ad
+.fi
+Problems are reported to the syslog daemon.
 .SH AUTHOR(S)
 .na
 .nf
@@ -68,7 +55,7 @@
 .SH LAST MODIFICATION
 .na
 .nf
-Mon May 20 22:49:02 CEST 2007
+Wed Jul 25 11:25:08 EDT 2001
 .SH VERSION/RELEASE
 .na
 .nf
diff -Nru chrootuid-1.3/chrootuid.c chrootuid-1.3/chrootuid.c
--- chrootuid-1.3/chrootuid.c   2023-10-03 20:34:41.0 +0200
+++ chrootuid-1.3/chrootuid.c   2001-07-25 18:47:44.0 +0200
@@ -50,23 +50,15 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-extern char *optarg;
-extern int optind, opterr, optopt;
-
 
 int main(argc, argv)
 int argc;
 char  **argv;
 {
 struct passwd *pwd;
-int interactive = 1;
-int optstart = 0;
 
 /*
  * Open a channel to the syslog daemon. Older versions of openlog()
@@ -85,91 +77,45 @@
  * No need to make inetd complain, too.
  */
 
-/* If we use -i, skip it over and increment optstart */
-/* we cannot use the getopt library using:
- * if (getopt(argc, argv, "i") != -1) {
- * in order to preserve the arguments provided to the command
- * This means that -i must be the *first* (and only) argument */
-if ( argv[1] != NULL && strncmp(argv[1], "-i", 2) == 0 ) {
-   interactive = 0;
-optstart++;
-}
-
-if (argc-optstart < 4) {
-   if (interactive) {
-   syslog(LOG_ERR, "usage: %s [-i] path user command", argv[0]);
-   } else {
-  fprintf(stderr,"usage: %s [-i] path user command\n", argv[0]);
-  return (1);
-   }
+if (argc < 4) {
+   syslog(LOG_ERR, "usage: %s path user command", argv[0]);
return (0);
 }
 /* Must step into the new subtree. */
 
-if (chdir(argv[1+optstart])) {
-   if (interactive) {
-   syslog(LOG_ERR, "chdir(%s): %m", argv[1+optstart]);
-   return (0);
-   } else {
-   fprintf(stderr, "chdir(%s): %s\n", argv[1+optstart], 
strerror(errno));
-  return (1);
-   }
+if (chdir(argv[1])) {
+   syslog(LOG_ERR, "chdir(%s): %m", argv[1]);
+   return (0);
 }
 /* The user must be known in the *unrestricted* universe... */
 
-if ((pwd = getpwnam(argv[2+optstart])) == 0) {
-   if (interactive) {
-   syslog(LOG_ERR, "%s: user unknown", argv[2+optstart]);
-   return (0);
-   } else {
-   fprintf(stderr, "%s: user unknown\n", argv[2+optstart]);
-   return (1);
-   }
+if ((pwd = getpwnam(argv[2])) == 0) {
+   syslog(LOG_ERR, "%s: user unknown", argv[2]);
+   return (0);
 }
 /* initgroups() accesses the group file in the unrestricted universe... */
 
 if (initgroups(pwd->pw_name, pwd->pw_gid) < 0) {
-   if (interactive) {
-   syslog(LOG_ERR, "initgroups: %m");
-   return (0);
-   } else {
-   fprintf(stderr, "initgroups: %s\n", strerror(errno));
-   return (1);
-   }
+   syslog(LOG_ERR, "initgroups: %m");
+   return (0);
 }
 endgrent();
 
 /* Do the chroot() before giving away root privileges. */
 
-if (chroot(argv[1+optstart])) {
-   if (interactive) {
-   syslog(LOG_ERR, "chroot(%s): %m", argv[1+optstart]);
-   return (0);
-   } else {
-   fprintf(stderr, "chroot(%s): %s\n", argv[1+optstart], 
strerror(errno));
-   return (1);
-   }
-
+if (chroot(argv[1])) {
+   syslog(LOG_ERR, "chroot(%s): %m", 

Bug#1050329: sexpp: diff for NMU version 0.8.7-3.1

[Boyuan Yang]

Control: tags 1050329 + pending

Dear maintainer,

I've prepared an NMU for sexpp (versioned as 0.8.7-3.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru sexpp-0.8.7/debian/changelog sexpp-0.8.7/debian/changelog
--- sexpp-0.8.7/debian/changelog2023-08-14 20:17:57.0 -0400
+++ sexpp-0.8.7/debian/changelog2023-10-03 14:20:43.0 -0400
@@ -1,3 +1,11 @@
+sexpp (0.8.7-3.1) unstable; urgency=medium
+
+  [ Helmut Grohne ]
+  * Non-maintainer upload.
+  * debian/rules: Fix typo that causes nocheck FTBFS. (Closes: #1050329)
+
+ -- Boyuan Yang   Tue, 03 Oct 2023 14:20:43 -0400
+
 sexpp (0.8.7-3) unstable; urgency=medium
 
   * drop .symbols file, since the C++ name mangling makes it too fragile
diff -Nru sexpp-0.8.7/debian/rules sexpp-0.8.7/debian/rules
--- sexpp-0.8.7/debian/rules2023-06-27 17:56:59.0 -0400
+++ sexpp-0.8.7/debian/rules2023-10-03 14:20:36.0 -0400
@@ -8,7 +8,7 @@
 CONFIGURE_OPTIONS = -DBUILD_SHARED_LIBS=on
 
 ifneq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-CONFIGURE_OPTIONS += -DWITH_SEXPP_TESTS=off
+CONFIGURE_OPTIONS += -DWITH_SEXP_TESTS=off
 endif
 
 override_dh_auto_configure:


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

Bug#1053416: git: mangles curl proxy setting and breaks AF_UNIX proxies

[Michael Gold]

Package: git
Version: 1:2.42.0-1
Tags: patch

Dear Maintainer,

git does not support AF_UNIX proxies, despite the git-config manual page
suggesting it will accept anything supported by curl:
  http.proxy
  Override the HTTP proxy, normally configured using the http_proxy,
  https_proxy, and all_proxy environment variables (see curl(1)). In
  addition to the syntax understood by curl, it is possible to
  specify a proxy string with a user name but no password,

I tried to use "torsocks git fetch" with a .onion remote I'd cloned from
in the past, and got an error:
fatal: unable to access 'http://[elided].onion/git/': Not resolving 
.onion address (RFC 7686)

It seems to be a known problem, and I tried working around it by setting
an AF_UNIX proxy as documented for --proxy in the curl(1) manual:
export all_proxy=socks5h://localhost/run/tor/socks

That works for curl, but "git fetch" gives an error:
fatal: unable to access 'http://[elided].onion/git/': Failed to connect 
to localhost port 1080 after 0 ms: Couldn't connect to server

While debugging, I found that git was reading this environment variable,
parsing it poorly, and overriding it by giving libcurl a proxy string of
just "localhost"; seeing no path or port number, curl tries AF_INET6 and
AF_INET with port 1080.

I'm attaching a patch that fixes this.  I haven't tested thoroughly, but
tried to avoid unnecessary changes to the credential code (which I think
should use libcurl to parse URLs).  The flags for curl_url_set() are the
same as in curl's own parse_proxy() function.

  Permission is hereby granted, irrevocably and free of charge, to any
  person obtaining a copy of this software and associated documentation
  files (the "Software"), to deal in the Software without restriction,
  including without limitation the rights to use, copy, modify, merge,
  publish, distribute, sublicense, and/or sell copies of the Software,
  and to permit persons to whom the Software is furnished to do so.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
  CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
  TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
  SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

- Michael


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

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

Versions of packages git depends on:
ii  git-man  1:2.42.0-1
ii  libc62.37-11
ii  libcurl3-gnutls  8.3.0-2
ii  liberror-perl0.17029-2
ii  libexpat12.5.0-2
ii  libpcre2-8-0 10.42-4
ii  perl 5.36.0-9
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages git recommends:
ii  ca-certificates  20230311
ii  less 590-2
ii  openssh-client [ssh-client]  1:9.4p1-1
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-13+b1
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
ii  git-doc   1:2.42.0-1
ii  git-email 1:2.42.0-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.42.0-1
pn  gitweb

-- no debconf information

diff --git a/http.c b/http.c
index e138b4b96fb9..7ba155a77406 100644
--- a/http.c
+++ b/http.c
@@ -1135,32 +1135,39 @@ static CURL *get_curl_handle(void)
 */
curl_easy_setopt(result, CURLOPT_PROXY, "");
} else if (curl_http_proxy) {
-   if (starts_with(curl_http_proxy, "socks5h"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5_HOSTNAME);
-   else if (starts_with(curl_http_proxy, "socks5"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5);
-   else if (starts_with(curl_http_proxy, "socks4a"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4A);
-   else if (starts_with(curl_http_proxy, "socks"))
-   curl_easy_setopt(result,
-   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);
-#ifdef 

Bug#1007437: cdde: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.diff -Nru cdde-0.3.1/debian/changelog cdde-0.3.1/debian/changelog
--- cdde-0.3.1/debian/changelog 2023-10-03 20:14:51.0 +0200
+++ cdde-0.3.1/debian/changelog 2023-10-03 20:09:10.0 +0200
@@ -1,3 +1,11 @@
+cdde (0.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0 (Closes: #1007437).
+  * Fix FTBFS on hurd (Closes: #647965).
+
+ -- Bastian Germann   Tue, 03 Oct 2023 20:09:10 +0200
+
 cdde (0.3.1-1) unstable; urgency=low
 
   * Initial release (Closes: #493593).
diff -Nru cdde-0.3.1/debian/patches/hurd.patch 
cdde-0.3.1/debian/patches/hurd.patch
--- cdde-0.3.1/debian/patches/hurd.patch1970-01-01 01:00:00.0 
+0100
+++ cdde-0.3.1/debian/patches/hurd.patch2023-10-03 20:09:10.0 
+0200
@@ -0,0 +1,16 @@
+diff -ur cdde-0.3.1.orig/src/cdde.c cdde-0.3.1/src/cdde.c
+--- cdde-0.3.1.orig/src/cdde.c 2008-08-25 15:33:49.0 +0200
 cdde-0.3.1/src/cdde.c  2011-11-08 01:55:13.0 +0100
+@@ -41,7 +41,12 @@
+ #include 
+ #include  
+ #include 
++#ifdef __linux__
+ #include 
++#endif
++#ifdef __GNU__
++#include 
++#endif
+ #include 
+ #include 
+ #include 
diff -Nru cdde-0.3.1/debian/patches/series cdde-0.3.1/debian/patches/series
--- cdde-0.3.1/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ cdde-0.3.1/debian/patches/series2023-10-03 20:09:10.0 +0200
@@ -0,0 +1 @@
+hurd.patch
diff -Nru cdde-0.3.1/debian/source/format cdde-0.3.1/debian/source/format
--- cdde-0.3.1/debian/source/format 1970-01-01 01:00:00.0 +0100
+++ cdde-0.3.1/debian/source/format 2023-10-03 20:09:10.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1007557: cconv: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru cconv-0.6.2/debian/changelog cconv-0.6.2/debian/changelog
--- cconv-0.6.2/debian/changelog2023-10-03 20:04:14.0 +0200
+++ cconv-0.6.2/debian/changelog2023-10-03 19:52:25.0 +0200
@@ -1,3 +1,14 @@
+cconv (0.6.2-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007557)
+  * d/rules: Do not require configure for config.status (Closes: #1049645)
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Let dh_auto_configure pass --host to configure. (Closes: 
#991168)
+
+ -- Bastian Germann   Tue, 03 Oct 2023 19:52:25 +0200
+
 cconv (0.6.2-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cconv-0.6.2/debian/rules cconv-0.6.2/debian/rules
--- cconv-0.6.2/debian/rules2023-10-03 20:04:14.0 +0200
+++ cconv-0.6.2/debian/rules2023-10-03 19:52:25.0 +0200
@@ -1,16 +1,9 @@
 #!/usr/bin/make -f
 
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
-config.status: configure
+config.status:
dh_testdir
dh_autoreconf
-   ./configure --prefix=/usr \
-   --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info \
+   dh_auto_configure -- \
CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
 
 build: build-stamp
diff -Nru cconv-0.6.2/debian/source/format cconv-0.6.2/debian/source/format
--- cconv-0.6.2/debian/source/format1970-01-01 01:00:00.0 +0100
+++ cconv-0.6.2/debian/source/format2023-10-03 19:52:25.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1053090: libxsimd-dev: arm64 error in xtensor: usage of batch type with unsupported type

[Drew Parsons]

Package: libxsimd-dev
Followup-For: Bug #1053090
Control: reassign 1053090 libxtensor-dev
Control: forwarded 1053090 https://github.com/xtensor-stack/xtensor/issues/2733

xsimd upstream https://github.com/xtensor-stack/xsimd/issues/945 
identified the problem that neon64 does not support bool.

A minimal test case using xtensor only was found:

#include 

int main()
{
{
xt::xtensor a{0., 1.};
xt::xtensor b = a && 0.;
}

{
xt::xtensor a{false, true};
//xt::xtensor b = a && false;
}

return 0;
}


That contains the problem inside xtensor, so transferring this bug to
the xtensor package.

Bug#1053415: ITP: vaticinator -- Python 'fortune' implementation/library

[Matt Barry]

Package: wnpp
Severity: wishlist
Owner: Matt Barry 
X-Debbugs-Cc: debian-de...@lists.debian.org, m...@hazelmollusk.org

* Package name: vaticinator
  Version : 0.0.4
  Upstream Contact: Matt Barry 
* URL : https://github.com/hazelmollusk/vaticinator
* License : MIT
  Programming Lang: Python
  Description : Python 'fortune' implementation/library

 The vaticinator package provides a Python reimplemention of the
 'fortune' program.  The 'vaticinator' command supports most/all
 of the functionality of the original; also provided is a
 library of reusable fortune cookie functionality.

Bug#1053414: fail2ban: Creates the chain in iptables but does not add the banned IPs.

[Bruno Meirelles]

Package: fail2ban
X-Debbugs-Cc: bmeirel...@gmail.com
Version: 1.0.2-2
Severity: important

Dear Maintainer,

He creates the chain in iptables, but doesn't add the banned IPs. I 
switched to using nftables, and it's working correctly."


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

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-12-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en

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

Versions of packages fail2ban depends on:
ii  python3  3.11.2-1+b1

Versions of packages fail2ban recommends:
ii  iptables   1.8.9-2
ii  nftables   1.0.6-2+deb12u1
ii  python3-pyinotify  0.9.6-2
ii  python3-systemd    235-1+b2
ii  whois  5.5.17

Versions of packages fail2ban suggests:
ii  bsd-mailx [mailx]    8.1.2-0.20220412cvs-1
pn  monit    
ii  rsyslog [system-log-daemon]  8.2302.0-1
pn  sqlite3  

-- Configuration Files:
/etc/fail2ban/action.d/iptables.conf changed [not included]
/etc/fail2ban/action.d/nftables.conf changed [not included]
/etc/fail2ban/jail.conf changed [not included]

-- no debconf information

Bug#1007468: abootimg: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.diff -Nru abootimg-0.6/debian/changelog abootimg-0.6/debian/changelog
--- abootimg-0.6/debian/changelog   2023-10-03 19:35:06.0 +0200
+++ abootimg-0.6/debian/changelog   2023-10-03 19:25:11.0 +0200
@@ -1,3 +1,12 @@
+abootimg (0.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Move Homepage to GitHub (Closes: #974609)
+  * Convert to source format 3.0 (Closes: #1007468)
+  * Prevent unpacking initrd to '/' (Closes: #955037)
+
+ -- Bastian Germann   Tue, 03 Oct 2023 19:25:11 +0200
+
 abootimg (0.6-1) unstable; urgency=low
 
   * New upstream release
diff -Nru abootimg-0.6/debian/control abootimg-0.6/debian/control
--- abootimg-0.6/debian/control 2023-10-03 19:35:06.0 +0200
+++ abootimg-0.6/debian/control 2023-10-03 19:25:06.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Heiko Stuebner 
 Build-Depends: debhelper (>= 7), cdbs (>= 0.4.49), libblkid-dev
 Standards-Version: 3.9.2
-Homepage: http://gitorious.org/ac100/abootimg
+Homepage: https://github.com/ggrandou/abootimg
 
 Package: abootimg
 Architecture: any
@@ -17,4 +17,4 @@
  The original mkbootimg from Android can only create these images
  where abootimg can also extract and modify them.
  Handling android boot images is necessary when bringing other
- operating systems to android devices.
\ Kein Zeilenumbruch am Dateiende.
+ operating systems to android devices.
diff -Nru 
abootimg-0.6/debian/patches/0001-always-unpack-initrd-to-relative-paths.patch 
abootimg-0.6/debian/patches/0001-always-unpack-initrd-to-relative-paths.patch
--- 
abootimg-0.6/debian/patches/0001-always-unpack-initrd-to-relative-paths.patch   
1970-01-01 01:00:00.0 +0100
+++ 
abootimg-0.6/debian/patches/0001-always-unpack-initrd-to-relative-paths.patch   
2023-10-03 19:25:11.0 +0200
@@ -0,0 +1,25 @@
+From: Andrey Skvortsov 
+Date: Fri, 27 Mar 2020 11:40:21 +0300
+Subject: always unpack initrd to relative paths
+
+If cpio archive contains absolute filenames, files are unpacked
+relative to host root '/', not 'ramdisk' directory.
+If abootimg-unpack-initrd is run as root, that could break host system
+and make it unbootable by overwriting important system files.
+
+Signed-off-by: Andrey Skvortsov 
+---
+ abootimg-unpack-initrd | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/abootimg-unpack-initrd b/abootimg-unpack-initrd
+index 987239c..0113f3a 100755
+--- a/unpack-initrd
 b/unpack-initrd
+@@ -16,5 +16,5 @@ fi
+ 
+ mkdir -p $ramdisk
+ 
+-zcat $initrd | ( cd $ramdisk; cpio -i )
++zcat $initrd | ( cd $ramdisk; cpio -i --no-absolute-filenames)
+ 
diff -Nru abootimg-0.6/debian/patches/series abootimg-0.6/debian/patches/series
--- abootimg-0.6/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ abootimg-0.6/debian/patches/series  2023-10-03 19:25:11.0 +0200
@@ -0,0 +1 @@
+0001-always-unpack-initrd-to-relative-paths.patch
diff -Nru abootimg-0.6/debian/source/format abootimg-0.6/debian/source/format
--- abootimg-0.6/debian/source/format   1970-01-01 01:00:00.0 +0100
+++ abootimg-0.6/debian/source/format   2023-10-03 19:25:11.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1006292: bullseye-pu: package plasma-discover/5.20.5-3

[Patrick Franz]

Hej,

Am Montag, 2. Oktober 2023, 19:04:00 CEST schrieb Jonathan Wiltshire:
[...]
> Ping on this? It's urgent given the point release is planned for the
> coming weekend, and we're currently unsure if the related fix is safe
> to release without this one. If there's no answer we'll have to play
> safe and hold plasma-desktop back until the next cycle as well.

I've fixed it and it builds now. I'm attaching a debdiff to the version 
that was supposed to be uploaded.


-- 
Med vänliga hälsningar

Patrick Franzdiffstat for plasma-discover-5.20.5 plasma-discover-5.20.5

 changelog  |8 
 plasma-discover-common.install |1 -
 plasma-discover.install|1 -
 3 files changed, 8 insertions(+), 2 deletions(-)

diff -Nru plasma-discover-5.20.5/debian/changelog plasma-discover-5.20.5/debian/changelog
--- plasma-discover-5.20.5/debian/changelog	2022-02-22 22:20:28.0 +0100
+++ plasma-discover-5.20.5/debian/changelog	2023-10-03 19:11:07.0 +0200
@@ -1,3 +1,11 @@
+plasma-discover (5.20.5-3+deb11u2) bullseye; urgency=medium
+
+  [ Patrick Franz ]
+  * Team upload.
+  * Update list of installed files.
+
+ -- Patrick Franz   Tue, 03 Oct 2023 19:11:07 +0200
+
 plasma-discover (5.20.5-3+deb11u1) bullseye; urgency=medium
 
   * Team upload.
diff -Nru plasma-discover-5.20.5/debian/plasma-discover-common.install plasma-discover-5.20.5/debian/plasma-discover-common.install
--- plasma-discover-5.20.5/debian/plasma-discover-common.install	2022-02-22 22:20:28.0 +0100
+++ plasma-discover-5.20.5/debian/plasma-discover-common.install	2023-10-03 19:09:08.0 +0200
@@ -1,6 +1,5 @@
 usr/share/discover/
 usr/share/icons/hicolor/*/apps/plasmadiscover.*
-usr/share/knsrcfiles/
 usr/share/kxmlgui5/plasmadiscover/
 usr/share/libdiscover/categories/packagekit-backend-categories.xml
 usr/share/locale/
diff -Nru plasma-discover-5.20.5/debian/plasma-discover.install plasma-discover-5.20.5/debian/plasma-discover.install
--- plasma-discover-5.20.5/debian/plasma-discover.install	2022-02-22 22:20:28.0 +0100
+++ plasma-discover-5.20.5/debian/plasma-discover.install	2023-10-03 19:07:36.0 +0200
@@ -5,7 +5,6 @@
 usr/lib/*/libexec/kf5/discover/runservice
 usr/lib/*/plasma-discover/
 usr/lib/*/qt5/plugins/discover-notifier/DiscoverPackageKitNotifier.so
-usr/lib/*/qt5/plugins/discover/kns-backend.so
 usr/lib/*/qt5/plugins/discover/packagekit-backend.so
 usr/share/applications/org.kde.discover.apt.urlhandler.desktop
 usr/share/applications/org.kde.discover.desktop

Bug#1053405: darktable: FTBFS on arm64 (gcc bug?)

[David Bremner]

Gianfranco Costamagna  writes:

> Source: darktable
> Version: 4.4.2-1
> Severity: serious
> forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
> tags: ftbfs
>

Do you think maybe there should be a debian gcc bug? after all, the
distinction you point to is a difference of debian version.

d

Bug#1053413: RFP: tox-current-env -- tox plugin to run tests in current Python environment

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: tox-current-env
  Version : 0.0.11
  Upstream Contact: Miro Hrončok 
* URL : https://github.com/fedora-python/tox-current-env
* License : MIT
  Programming Lang: Python
  Description : tox plugin to run tests in current Python environment

The tox-current-env plugin adds these options:

tox --current-env
Runs the tox testenv's commands in the current Python environment
(that is, the environment where tox is invoked from and installed
in). Unlike regular tox invocation, this installs no dependencies
declared in deps. An attempt to run this with a Python version
that doesn't match will fail (if tox is invoked from an Python 3.7
environment, any non 3.7 testenv will fail).

tox --print-deps-to=FILE
Instead of running any commands, simply prints the declared
dependencies in deps to the specified FILE. This is useful for
preparing the current environment for tox --current-env. Use - for
FILE to print to standard output.

tox --print-extras-to=FILE
Instead of running any commands, simply prints the names of the
declared extras in extras to the specified FILE. This is useful
for preparing the current environment for tox --current-env. Use -
for FILE to print to standard output.

It is possible to use the two printing options together, as long as
the FILE is different.

Invoking tox without any of the above options should behave as regular
tox invocation without this plugin. Any deviation from this behavior
is considered a bug.

The plugin disables tox's way of providing a testing environment, but
assumes that you supply one in some other way. Always run tox with
this plugin in a fresh isolated environment, such as Python
virtualenv, Linux container or chroot. See other caveats below.

Obviously, tox was created to run tests in isolated Python virtual
environments. The --current-env flag totally defeats the purpose of
tox. Why would anybody do that, you might ask?

Well, it turns out that tox became too popular and gained another purpose.

The Python ecosystem now has formal specifications for many pieces of
package metadata like versions or dependencies. However, there is no
standardization yet for declaring test dependencies or running
tests. The most popular de-facto standard for that today is tox, and
we expect a future standard to evolve from tox.ini. This plugin lets
us use tox's dependency lists and testing commands for environments
other than Python venvs.

We hope this plugin will enable community best practices around tox
configuration to grow to better accomodate non-virtualenv environments
in general – for example, Linux distros, Conda, or containers.

Specifically, this plugin was created for Fedora's needs. When we
package Python software as RPM packages, we try to run the project's
test suite during package build. However, we need to test if the
software works integrated into Fedora, not with packages downloaded
from PyPI into a fresh environment. By running the tests in current
environment, we can achieve that.



In my case, I want to avoid constantly downloading unverified code
from the internet, or, even worse, *compile* code (e.g. for
python3-ldap, in my case) which involves a whole other pile of stuff
to install.

Other Tox plugins are currently maintained by the Python team (and
Peter Pentchev), so it would probably be the same for this one.

Bug#1042521: Will Trixie be on Perl 5.38?

[Niko Tyni]

On Mon, Oct 02, 2023 at 03:39:59PM +0200, Joachim Zobel wrote:
> Will Trixie be with Perl 5.38? If so it is ponitless to put any effort
> into the polymake package. If not there might be enough time for the
> transition to Julia.

I'm aiming to get Perl 5.38 into testing (trixie) in the next month
or two.

I expect trixie will eventually release with Perl 5.40, but we'll see
how the timing works out.
-- 
Niko Tyni   nt...@debian.org

Bug#1053412: postfix config script overwrites explicitly set destinations with default postfix value

[Jonathan Kamens]

Package: postfix
Version: 3.8.2-1
Severity: normal

Note: I am specifically discussing the postfix/destinations debconf
setting and the corresponding mydestination setting in
/etc/postfix/main.cf, but looking at the code in the postfix config
script, I suspect this issue may apply to other settings as well.

If I preload the postfix settings I want into the debconf database --
in particular if I set postfix/destinations to "localhost" -- and then
call dpkg-reconfigure -fnoninteractive postfix, here's what happens:

1. The config script notices that I have set postfix/destinations.
2. It calls postfix -hx mydestination, which returns the value of
   mydestination in /etc/postfix/main.cf OR THE DEFAULT VALUE IF THERE
   IS NO VALUE IN THE FILE.
3. It overwrites the postfix/destinations debconf setting with
   whatever postconf returned.
4. The postinst script is called and writes the value from
   postfix/destinations into /etc/postfix/main.cf.

As a result, the value that I explicitly put into the debconf setting
is lost, AND the wrong, default value that I don't want is explicitly
hard-coded into /etc/postfix/main.cf, perpetuating the error.

I kind of get the argument that if there is a value explicitly set in
/etc/postfix/main.cf it should override the debconf value, but if
there's no value in /etc/postfix/main.cf, then I don't think the
default value returned by postconf should overwrite an explicitly set
debconf value!

I think the fix for this would probably be to modify the config script
so that it calls postconf -nhx instead of postconf -hx and then only
replaces the setting in debconf if postconf returns a non-empty value.

Thanks,

Jonathan Kamens

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

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

Versions of packages postfix depends on:
ii  adduser3.137
ii  cpio   2.13+dfsg-7.1
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.22.0
ii  e2fsprogs  1.47.0-2+b1
ii  init-system-helpers1.65.2
ii  libc6  2.37-10
ii  libdb5.3   5.3.28+dfsg2-2
ii  libicu72   72.1-3
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.28+dfsg1-3
ii  libssl33.0.11-1
ii  netbase6.4
ii  ssl-cert   1.1.2

Versions of packages postfix recommends:
ii  ca-certificates  20230311
ii  python3  3.11.4-5+b1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]1:29.1+1-5
ii  evolution [mail-reader]3.50.0-1
ii  libsasl2-modules   2.1.28+dfsg1-3
ii  mailutils [mail-reader]1:3.16-1+b1
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mta-sts-resolver   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
pn  postfix-sqlite 
ii  procmail   3.22-27
ii  systemd-resolved [resolvconf]  254.4-1
ii  thunderbird [mail-reader]  1:115.2.2-1
ii  ufw0.36.2-1

-- debconf information excluded

Bug#1053411: sra-sdk: FTBFS with re2 >= 20230601 (which requires abseil)

[Stefano Rivera]

Source: sra-sdk
Version: 3.0.3+dfsg-6
Severity: normal
Tags: upstream
Control: affects -1 + src:re2

The next RE2 transition is waiting for sra-sdk to support libre2-11
(re2 >= 20230601), available in experimental.

Upstream, RE2 added a dependency on Abseil, changing its API a little.

It looks like only sharq in sra-tools requires re2, and it currently
expects 2021-09-01:
https://github.com/ncbi/sra-tools/blob/6d1e74850ad399f671da13e8aee39bcef926e551/tools/loaders/sharq/CMakeLists.txt#L89

[ 78%] Linking CXX static library ../../../lib/libncbi-ngs-c++.a
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu/ngs/ncbi/ngs-c++ && /usr/bin/cmake -P 
CMakeFiles/ncbi
-ngs-c++.dir/cmake_clean_target.cmake
In file included from /<>/test/loaders/sharq/test-regexpr.cpp:30:
/<>/test/loaders/sharq/../../../tools/loaders/sharq/regexpr.hpp: 
In member functi
on ‘bool CRegExprMatcher::Matches(const std::string_view&)’:
/<>/test/loaders/sharq/../../../tools/loaders/sharq/regexpr.hpp:56:40:
 error: cannot convert ‘const std::string_view’ {aka ‘const 
std::basic_string_view’} to ‘absl::debian3::string_view’
   56 | return re2::RE2::PartialMatchN(input, *re, args.empty() ? 
nullptr : [0], (int)args.size());
  |^
  ||
  |const std::string_view {aka 
const std::basic_string_view}
In file included from 
/<>/test/loaders/sharq/../../../tools/loaders/sharq/regexpr.hpp:13:
/usr/include/re2/re2.h:343:47: note:   initializing argument 1 of ‘static bool 
re2::RE2::PartialMatchN(absl::debian3::string_view, const re2::RE2&, const Arg* 
const*, int)’
  343 |   static bool PartialMatchN(absl::string_view text, const RE2& re,
  | ~~^~~~

Stefano


sra-sdk_3.0.3+dfsg-6_amd64.build.xz
Description: application/xz

Bug#1053410: foliate: Failed to load shared library 'libwebkit2gtk-4.0.so.37'

[Kacper Perschke]

Package: foliate
Version: 2.6.4-1+dfsg3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

‣ What led up to the situation?

  Any attempt to run foliate

  Exact exception is as follow
  - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

  ** (com.github.johnfactotum.Foliate:125952): WARNING **: 16:53:39.078:
  Failed to load shared library 'libwebkit2gtk-4.0.so.37' referenced by
  the typelib: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: undefined
  symbol: gst_transcoder_get_sync_signal_adapter

  (com.github.johnfactotum.Foliate:125952): Gjs-CRITICAL **:
  16:53:39.082: JS ERROR: Error: Unsupported type void, deriving from
  fundamental void
  @resource:///com/github/johnfactotum/Foliate/js/main.js:38:20
  @/usr/bin/com.github.johnfactotum.Foliate:9:1


  (com.github.johnfactotum.Foliate:125952): Gjs-CRITICAL **: 
  16:53:39.082: Script /usr/bin/com.github.johnfactotum.Foliate threw an
  exception
  - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

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

  I've tried to guess if foliate shows libwebkit2gtk-4.0.so.37 as it's
  dependency.

‣ What was the outcome of this action?

  I've found that foliate 2.6.4-1+dfsg3 wants gir1.2-webkit2-4.0, which
  as of version 2.42.1-1 wants libwebkit2gtk-4.0-37 (= 2.42.1-1).

‣ What outcome did you expect instead?

  Possibility to run foliate.

Yours faithfully

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

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

Versions of packages foliate depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-webkit2-4.0   2.42.1-1
ii  gjs  1.76.2-4
ii  python3  3.11.4-5+b1

Versions of packages foliate recommends:
ii  gnome-epub-thumbnailer  1.7-3

foliate suggests no packages.

-- no debconf information

Bug#749788: I think this is an apt request, not an apt-listchanges

[David Kalnischkies]

Control: reassign -1 apt-listchanges 2.85.13

Hi,

On Mon, Oct 02, 2023 at 05:43:00PM -0400, Jonathan Kamens wrote:
> The timing of when apt-listchanges gets called vs. when packages get
> installed is controlled by apt, not by apt-listchanges. While it would

apt doesn't hardcode calling apt-listchanges. apt-listchanges opts in to
being called at a specific point with `/etc/apt/apt.conf.d/20listchanges`.

Specifically the `DPkg::Pre-Install-Pkgs` setting. Other hook places
exist, they do have other informations available through. In any case,
as the premise for reassigning is wrong… return to sender.


> certainly be possible to add an option to apt to call apt-listchanges after
> rather than before the upgrade, and to omit the --confirm option when doing
> so since it obviously makes no sense to ask the user for confirmation afrer
> the upgrade has already happened, this change would need to be made in apt,
> not in apt-listchanges.

You could already now gather the info with a non-blocking hook and add
an additional one after dpkg finishes which does whatever is requested
here via `DPkg::Post-Invoke` hook if you so choose.


That said, my `/etc/apt/listchanges.conf` contains:
|[apt]
|frontend=browser
|browser=/etc/apt/apt-listchanges-browser
|confirm=0
|which=both

I have to admit that my browser is kinda special so I will not bore you
with too many details, what you need here is going from 'root' to a
'normal' user (with some environment variables like DISPLAY). I think
apt-listchanges even tries to do that for you if you use `sudo` to call
apt (or whatever front end ends up calling listchanges), so it might just
work for you or you need a bit of scripting (my solution involves a
systemd user session, a user account just for browsing and sandboxing,
but as this is total overkill and not a generic solution).

In any case, the behaviour is that apt-listchanges will format its output
as HTML, calls the browser on it (ensure that either a browser is running
or double fork to the background I suppose) after which it will continue
without a confirmation as requested in the bugreport.

I use that for years to read the changelog entries (not just NEWS) and
occasionally the linked bugs while apt/dpkg are busy doing their thing.


So, I suppose, with a bit more documentation and testing this bugreport
could be closed in apt-listchanges without any code changes. In any
case, there is nothing I can see we as apt maintainers need to do here.


If you think you (I see that you intend to adopt apt-listchanges, good
luck with that & thanks for contributing to Debian in this way!) need
something from apt feel free to contact us on IRC/mailinglist before
reassigning bugs over as they tend to get lost in our heap – and
usually, with some trickery existing facilities can be reused instead of
busy-waiting for apt in stable to support whatever someone needs now…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1053408: qt6-webengine: FTBFS with re2 >= 20230601 (which requires abseil)

[Stefano Rivera]

Source: qt6-webengine
Version: 6.4.2-final+dfsg-11
Severity: normal
Tags: upstream
Affects: src:re2

The next RE2 transition is waiting for qt6-webengine to support
libre2-11 (re2 >= 20230601), available in experimental.

Upstream, RE2 added a dependency on Abseil, changing its API a little.

Chromium has supported this since around 116. (Debian's chromium
currently builds with the bundled re2). The relevant commits are by
https://chromium-review.googlesource.com/q/owner:jun...@chromium.org and
reference bug 1447090

Stefano

Bug#1053407: network-manager: wake on WLAN suddenly not working

[Jonathan Kamens]

Package: network-manager
Version: 1.44.0-1
Severity: normal

I have two laptops running debian testing. (i.e., "deb
http://deb.debian.org/debian/ testing main non-free-firmware contrib
non-free" in my sources.list). They are both up-to-date. I have
wake-on-wlan set to 0x8 on the wifi interface on both laptops; see
`nmcli c show` output below.

I am able to use etherwake to wake one of the laptops when it's
asleep, but not the other.

This was working for the longest time on both laptops and just stopped
working within the last few days, not sure when.

The laptop on which it's working is a Framework 12th gen. The laptop
on which it's not working is a ThinkPad X1 Carbon 6th gen.

nmcli c show output (lines with the value "--" and DHCP options lines
with private info have been deleted, other private info elided):

connection.id:  [deleted]
connection.uuid:[deleted]
connection.type:802-11-wireless
connection.autoconnect: yes
connection.autoconnect-priority:0
connection.autoconnect-retries: -1 (default)
connection.multi-connect:   0 (default)
connection.auth-retries:-1
connection.timestamp:   1696343954
connection.autoconnect-slaves:  -1 (default)
connection.gateway-ping-timeout:0
connection.metered: unknown
connection.lldp:default
connection.mdns:-1 (default)
connection.llmnr:   -1 (default)
connection.dns-over-tls:-1 (default)
connection.mptcp-flags: 0x0 (default)
connection.wait-device-timeout: -1
connection.wait-activation-delay:   -1
802-11-wireless.ssid:   [deleted]
802-11-wireless.mode:   infrastructure
802-11-wireless.channel:0
802-11-wireless.generate-mac-address-mask:--
802-11-wireless.mac-address-randomization:default
802-11-wireless.mtu:auto
802-11-wireless.seen-bssids:[deleted]
802-11-wireless.hidden: no
802-11-wireless.powersave:  2 (disable)
802-11-wireless.wake-on-wlan:   0x8 (magic)
802-11-wireless.ap-isolation:   -1 (default)
802-11-wireless-security.key-mgmt:  wpa-psk
802-11-wireless-security.wep-tx-keyidx: 0
802-11-wireless-security.pmf:   0 (default)
802-11-wireless-security.wep-key0:  
802-11-wireless-security.wep-key1:  
802-11-wireless-security.wep-key2:  
802-11-wireless-security.wep-key3:  
802-11-wireless-security.wep-key-flags: 0 (none)
802-11-wireless-security.wep-key-type:  unknown
802-11-wireless-security.psk:   
802-11-wireless-security.psk-flags: 0 (none)
802-11-wireless-security.leap-password: 
802-11-wireless-security.leap-password-flags:0 (none)
802-11-wireless-security.wps-method:0x0 (default)
802-11-wireless-security.fils:  0 (default)
ipv4.method:auto
ipv4.dns:   [deleted]
ipv4.dns-search:[deleted]
ipv4.dns-priority:  0
ipv4.route-metric:  -1
ipv4.route-table:   0 (unspec)
ipv4.replace-local-rule:-1 (default)
ipv4.ignore-auto-routes:no
ipv4.ignore-auto-dns:   yes
ipv4.dhcp-timeout:  0 (default)
ipv4.dhcp-send-hostname:yes
ipv4.dhcp-hostname-flags:   0x0 (none)
ipv4.never-default: no
ipv4.may-fail:  yes
ipv4.required-timeout:  -1 (default)
ipv4.dad-timeout:   -1 (default)
ipv4.link-local:0 (default)
ipv4.auto-route-ext-gw: -1 (default)
ipv6.method:auto
ipv6.dns-priority:  0
ipv6.route-metric:  -1
ipv6.route-table:   0 (unspec)
ipv6.replace-local-rule:-1 (default)
ipv6.ignore-auto-routes:no
ipv6.ignore-auto-dns:   no
ipv6.never-default: no
ipv6.may-fail:  yes
ipv6.required-timeout:  -1 (default)
ipv6.ip6-privacy:   2 (enabled, prefer temporary IP)
ipv6.addr-gen-mode: default-or-eui64
ipv6.ra-timeout:0 (default)
ipv6.mtu:   auto
ipv6.dhcp-timeout:  0 (default)
ipv6.dhcp-send-hostname:yes
ipv6.dhcp-hostname-flags:   0x0 (none)
ipv6.auto-route-ext-gw: -1 (default)
proxy.method:   none
proxy.browser-only: no
GENERAL.NAME:   [deleted]
GENERAL.UUID:   [deleted]
GENERAL.DEVICES:wlp2s0
GENERAL.IP-IFACE:

Bug#1053406: skanpage: should depend on qml-mnodule-org-kde-kquickimageeditor

[Alvin Cheung]

Package: skanpage
Version: 23.08.1-1
Severity: important
X-Debbugs-Cc: ayhche...@gmail.com

Dear Maintainer,

On launching skanpage via Plasma, no window appears.

When launching skanpage via the command line, I get the following message:

module "org.kde.kquickimageeditor" is not installed

Manually installing qml-module-org-kde-kquickimageeditor fixes the problem.

Proposed fix: list qml-module-org-kde-kquickimageeditor as a dependency of 
skanpage

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

Kernel: Linux 6.5.5-1-siduction-amd64 (SMP w/16 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 skanpage depends on:
ii  libc6   2.37-11
ii  libgcc-s1   13.2.0-4
ii  libkf5configcore5   5.107.0-1
ii  libkf5configgui55.107.0-1
ii  libkf5coreaddons5   5.107.0-1
ii  libkf5crash55.107.0-1
ii  libkf5i18n5 5.107.0-1+b1
ii  libkf5xmlgui5   5.107.0-1+b1
ii  libksanecore1   23.08.1-2
ii  liblept51.82.0-3+b3
ii  libqt5core5a5.15.10+dfsg-3
ii  libqt5gui5  5.15.10+dfsg-3
ii  libqt5printsupport5 5.15.10+dfsg-3
ii  libqt5qml5  5.15.10+dfsg-2
ii  libqt5quick55.15.10+dfsg-2
ii  libqt5widgets5  5.15.10+dfsg-3
ii  libstdc++6  13.2.0-4
ii  libtesseract5   5.3.0-2
ii  qml-module-org-kde-purpose  5.107.0-1

skanpage recommends no packages.

skanpage suggests no packages.

-- no debconf information

Bug#1021978: spamassassin: non-standard version numbers break spamassassin's AIDE script

[Thomas Dorner]

On Tue, 3 Oct 2023 16:32:35 +0200
Thomas Dorner  wrote:

> > The current version of the rule does things differently. Can you
> > verify whether the current version in sid works for you as well?  
> 
> Sorry Marc, I switched my systems to Bullseye a few months ago and no
> longer have a Sid to test with.

Ooops, I meant Bookworm!

Best regards, Thomas
-- 
퓣퓱퓸퓶퓪퓼 퓓퓸퓻퓷퓮퓻

Bug#1021978: spamassassin: non-standard version numbers break spamassassin's AIDE script

[Thomas Dorner]

> The current version of the rule does things differently. Can you
> verify whether the current version in sid works for you as well?

Sorry Marc, I switched my systems to Bullseye a few months ago and no
longer have a Sid to test with.

Best regards, Thomas
-- 
퓣퓱퓸퓶퓪퓼 퓓퓸퓻퓷퓮퓻

Bug#1052487: aide-common: please recommend canonical "cron | cron-daemon"

[Alexandre Detiste]

Le mar. 3 oct. 2023 à 16:21, Marc Haber
 a écrit :
> On systemd systems, aide already uses a systemd timer. Given that the
> users of other init systems have to do manual work anyway, I intend to
> fully drop the cron dependency with one of the next uploads.
>
> Is that the right thing to do from your point of view, and would you
> recommend doing so?

I don't recommend breaking non-systemd systems.

I guess it's better for them a cron job with sane defaults than nothing.

> > (this is a list of cron job that does
> >  "[ -d /run/systemd/system ] && exit 0")
>
> As my cron job is using a slightly different idiom, would I make things
> easier for you if I wrote "[ -d /run/systemd/system ] && exit 0"
> explicitly instad of my if construct?

This old idea was dropped in the upstream project altogether
because it was growing in a full blown bash AST parser.

Greetings,

And thank you

Bug#1033537: aide-common: More configurable MTA command when run as non-root

[Marc Haber]

Control: retitle -1 [patch appreciated] aide-common: More configurable MTA 
command when run as non-root
thanks

Bug#1052487: aide-common: please recommend canonical "cron | cron-daemon"

[Marc Haber]

On Sat, Sep 23, 2023 at 01:10:59AM +0200, Alexandre Detiste wrote:
> Please recommends the canonical "cron | cron-daemon"
> instead of plain "cron".
> 
> This way apt won't say anything about cron being
> recommended when the stop-gap systemd-cron stub is already installed.

On systemd systems, aide already uses a systemd timer. Given that the
users of other init systems have to do manual work anyway, I intend to
fully drop the cron dependency with one of the next uploads.

Is that the right thing to do from your point of view, and would you
recommend doing so?

For the time being, I have committed the change recommended by you.

> On my side I have added to systemd-cron an ignore rule for aide-common:
> 
> https://salsa.debian.org/detiste-guest/systemd-cron/-/commit/356bfedd393b0bd8663b7737e7ba5b987916b403
> 
> (this is a list of cron job that does 
>  "[ -d /run/systemd/system ] && exit 0")

As my cron job is using a slightly different idiom, would I make things
easier for you if I wrote "[ -d /run/systemd/system ] && exit 0"
explicitly instad of my if construct?

Greetings
Marc

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Marc Haber]

Control: tags -1 
thanks

On Tue, Jul 11, 2023 at 02:47:52PM +0200, Marc Haber wrote:
> I'd rather not add that Suggests to aide, but I'm open to new arguments.

I plan to close this bug by the End of October 2023.

Greetings
Marc

Bug#1021978: spamassassin: non-standard version numbers break spamassassin's AIDE script

[Marc Haber]

On Tue, Oct 18, 2022 at 10:08:32AM +0200, Thomas Dorner wrote:
> On a recently installed Sid system I tried to set-up  AIDE using
> aideinit.  This failed with the following error messages:
> 
>   ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: stderr> 
> /etc/aide/aide.conf.d/21_aide_spamassassin: line 13: printf: 4.0.0~rc3-3.1: 
> invalid number
>   ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: stderr> 
> /etc/aide/aide.conf.d/21_aide_spamassassin: line 13: printf: 4.0.0~rc3-3.1: 
> invalid number
>   ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: stderr> 
> /etc/aide/aide.conf.d/21_aide_spamassassin: line 13: printf: 4.0.0~rc3-3.1: 
> invalid number
>   ERROR: /etc/aide/aide.conf.d/21_aide_spamassassin: execution failed (exit 
> status: 1)
> 
> The problem is that the current version number 4.0.0~rc3-3.1 does not
> match the expected schema of N.N.N-N.  As only the first 3 numbers are
> used anyway, I've created a patch (attached) making the regular
> expression less rigid by ignoring everything after those 3 numbers.
> This works for me.

The current version of the rule does things differently. Can you verify
whether the current version in sid works for you as well? Thanks!

Greetings
Marc

Bug#1053404: iipimage-server: New upstream release of version 1.2

[Ruven]

Package: iipimage-server
Severity: normal

Dear Maintainer,

   * New upstream release of version 1.2
   * Note that new release has new build dependencies on libwebp-dev 
and libpng-dev
   * The Depends on Apache or Lighttpd should be changed to Recommends 
as it is possible to start using systemd



--
---
http://iipimage.sourceforge.net
---

Bug#1053395: Resolving valgrind dependency, take 2

[Antoine Beaupré]

Control: tags -1 +pending +patch

On 2023-10-03 11:02:03, Christoph Biedl wrote:
> Package: pv
> Version: 1.8.0-2
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
>
> Hi there,
>
> thanks for resolving the valgrind dependency issue for armel and a few
> more release archs. Unfortunatly, there are several port archs where pv
> still fails to build. As a solution, may I ask you to build-depend on
> valgrind-if-available instead? That solved the problem on all archs I
> rebuild pv - except x32 which has other issues, and for quite some time
> already.

Yep, I have that commit ready on salsa actually, I figured it was a noop
because we already fixed the issue for the major architectures so I must
admit I just plainly overlooked ports...

Let me make yet another upload to fix this formally. :)

a.

-- 
I believe that if someone choose arts as their subject but do not
criticize the issues of their society, they have have betrayed
themselves, their conscience, and their society.
- Atena Farghadani

Bug#1053403: whatmaps: apt complains /usr/bin/whatmaps not found after apt remove whatmaps

[Jonathan Kamens]

Package: whatmaps
Version: 0.0.13-1
Severity: minor

1. Install whatmaps.
2. Remove (but do not purge) whatmaps.
3. Run apt upgrade.
4. Observe: "/bin/sh: 1: /usr/bin/whatmaps: not found".

Fix: DPkg::Pre-Install-Pkgs in /etc/apt/apt.cofn.d/50whatmaps_apt
should only execute /usr/bin/whatmaps if it exists, something like:

DPkg::Pre-Install-Pkgs { [ -f /usr/bin/whatmaps ] && "/usr/bin/whatmaps --apt 
--restart --print-cmds=/var/lib/whatmaps/restart.sh || true" };

Bug#1053402: audiotools: cddaplay only reproduces first track of a cd

[david]

Package: audiotools
Version: 3.1.1-1.1+b12
Severity: normal

Dear Maintainer,

I use it with ALSA, because pulse (via pipewire-pulse) doesn't work at all.
With "mpv cdda://" same cds work without problem.

-- 
David

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

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

Versions of packages audiotools depends on:
ii  libasound2 1.2.9-2
ii  libc6  2.37-10
ii  libcdio-cdda2  10.2+2.0.1-1
ii  libcdio-paranoia2  10.2+2.0.1-1
ii  libcdio19  2.1.0-4
ii  libmp3lame03.100-6
ii  libmpg123-01.31.3-2
ii  libopus0   1.4-1
ii  libopusfile0   0.12-4
ii  libpulse0  16.1+dfsg1-2+b1
ii  libtwolame00.4.0-2
ii  libvorbisenc2  1.3.7-1
ii  libvorbisfile3 1.3.7-1
ii  libwavpack15.6.0-1
ii  python33.11.4-5+b1

Versions of packages audiotools recommends:
ii  faad   2.10.1-1
ii  python3-urwid  2.1.2-4+b1

Versions of packages audiotools suggests:
pn  faac  

-- no debconf information

Bug#1053401: RFS: radsecproxy/1.10.0-1 -- RADIUS protocol proxy supporting RadSec

[Sven Hartge]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : radsecproxy
   Version  : 1.10.0-1
   Upstream contact : Fabian Mauchle 
 * URL  : https://radsecproxy.github.io/
 * License  : BSD-3-clause
 * Vcs  : https://salsa.debian.org/debian/radsecproxy
   Section  : net

The source builds the following binary packages:

  radsecproxy - RADIUS protocol proxy supporting RadSec

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/radsecproxy/radsecproxy_1.10.0-1.dsc


Changes since the last upload:

 radsecproxy (1.10.0-1) unstable; urgency=medium
 .
   * New upstream version 1.10.0
   * Remove patches applied upstream
   * Add patch to fix spelling detected by lintian

Grüße,
Sven!

Bug#1053400: konsole: configuration partially lost after last upgrade

[Erwan David]

Package: konsole
Version: 4:23.08.1-1
Severity: normal

After last upgrade (yesterday), konsole has no more menu bar, I configured tabs 
to be at bottom, they are at top.

No menu bar means it is very complicated tyo get to configuration.

Luckily profiles definition was not lost.


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'testing'), (800, 
'stable-security'), (500, 'proposed-updates'), (500, 'unstable'), (400, 
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages konsole depends on:
ii  kio5.107.0-1
ii  konsole-kpart  4:23.08.1-1
ii  libc6  2.37-10
ii  libkf5configcore5  5.107.0-1
ii  libkf5configwidgets5   5.107.0-2
ii  libkf5coreaddons5  5.107.0-1
ii  libkf5crash5   5.107.0-1
ii  libkf5dbusaddons5  5.107.0-1
ii  libkf5globalaccel-bin  5.107.0-2
ii  libkf5globalaccel5 5.107.0-2
ii  libkf5guiaddons5   5.107.0-1
ii  libkf5i18n55.107.0-1+b1
ii  libkf5kiowidgets5  5.107.0-1
ii  libkf5notifyconfig55.107.0-1
ii  libkf5service-bin  5.107.0-1
ii  libkf5service5 5.107.0-1
ii  libkf5widgetsaddons5   5.107.0-1
ii  libkf5windowsystem55.107.0-1
ii  libkf5xmlgui5  5.107.0-1+b1
ii  libqt5core5a   5.15.10+dfsg-3
ii  libqt5gui5 5.15.10+dfsg-3
ii  libqt5widgets5 5.15.10+dfsg-3
ii  libstdc++6 13.2.0-4

konsole recommends no packages.

Versions of packages konsole suggests:
pn  lrzsz  

-- no debconf information

Bug#1053398: gnome-online-accounts: I cannot add a proxy Google account

[Jeremy Bícha]

On Tue, Oct 3, 2023 at 8:00 AM Felix  wrote:
> I have a work email ending in "@ucd.ie" which is really a Google account, even
> though it does not end in "@gmail.com"
>
> In Debian 11 I could add my work account normally by running Gnome Online
> Accounts, and then choosing Google.
>
> The program would then redirect me to the two-factor authentication system in
> my university and the account would be set up for Evolution, etc.
>
> However, after upgrading to Debian 12, when I add my @ucd.ie account through
> Gnome Online Accounts (choosing Google), after pressing "Next" I get the error
> message
>
> "Forbidden
>
> You don't have permission to access this resource."

Please talk to your workplace's system administrator. I am regularly
able to use GNOME Online Accounts to add Google accounts for work or
school that don't have @gmail.com domains.

One other thing to try is whether you are able to add the account to
your mobile phone.

I think we should close this bug because I don't think this is
something that is broken in Debian or can be fixed in Debian.

Thank you,
Jeremy Bícha

Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC

[Reinhard Tartler]

I believe all dependencies are now in sid:

- https://tracker.debian.org/pkg/rust-prettyplease
- https://tracker.debian.org/pkg/rust-hyper-timeout

anything else that is missing?

-rt

On 9/25/23 8:12 AM, Reinhard Tartler wrote:



On 9/22/23 1:42 PM, Jonas Smedegaard wrote:

Quoting Reinhard Tartler (2023-09-22 13:09:08)

How about I take care of hyper-timeout and prettyplease in debcargo-conf
(i.e., the rust team mass-packaging repo), and try to assist you with packaging
the workspace builds of tonic (which includes tonic-build, cf. 
https://github.com/hyperium/tonic/tree/master/tonic-build)
and axum?


Deal! :-)


hyper-timeout: https://ftp-master.debian.org/new/rust-hyper-timeout_0.4.1-1.html
prettyplease: https://tracker.debian.org/pkg/rust-prettyplease

both versions currently in the archive should satisfy requirements for tonic.

Let me know what other dependencies are missing, happy to add them to 
debcargo-conf.git

-rt

Bug#1053399: ITP: fonts-albert-sans

[Gioele Barabucci]

Package: wnpp
Severity: wishlist

* Package name: fonts-albert-sans
  Version : 1.25
* URL : https://github.com/usted/Albert-Sans
* License : OFL
  Description : Modern geometric sans-serif font

Albert Sans is a modern geometric sans serif family, inspired by the 
type characteristics of Scandinavian architects and designers in the 
early 20th century. The Albert Sans family includes ten weights from 
Thin to Black and supports over two hundred languages.


Designed by the Danish type designer Andreas Rasmussen from a.Foundry.

--
Gioele Barabucci

Bug#1053398: gnome-online-accounts: I cannot add a proxy Google account

[Felix]

Package: gnome-online-accounts
Version: 3.48.0-2
Severity: important

Dear Maintainer,

I would like to report a bug which started happening after upgrading Debian 11
to Debian 12.

I have a work email ending in "@ucd.ie" which is really a Google account, even
though it does not end in "@gmail.com"

In Debian 11 I could add my work account normally by running Gnome Online
Accounts, and then choosing Google.

The program would then redirect me to the two-factor authentication system in
my university and the account would be set up for Evolution, etc.

However, after upgrading to Debian 12, when I add my @ucd.ie account through
Gnome Online Accounts (choosing Google), after pressing "Next" I get the error
message

"Forbidden

You don't have permission to access this resource."

After the error message I am not able to complete the process of adding my
account.

I even updated gnome-online-accounts to version 3.48.0-2 (in the unstable
repository) to see whether the problem would go away, but unfortunately the
issue persists.

The problem does *not* happen if I use a "@gmail.com" account.

Kind regards

Fizolas


-- System Information:
Debian Release: 12.2
  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-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-online-accounts depends on:
ii  libc6 2.36-9+deb12u2
ii  libgcr-base-3-1   3.41.1-1+b1
ii  libglib2.0-0  2.78.0-2
ii  libgoa-1.0-0b 3.48.0-2
ii  libgoa-backend-1.0-1  3.48.0-2
ii  libkrb5-3 1.20.1-2+deb12u1
ii  librest-1.0-0 0.9.1-6
ii  libwebkit2gtk-4.1-0   2.40.5-1~deb12u1

Versions of packages gnome-online-accounts recommends:
ii  gnome-control-center  1:43.6-2~deb12u1

gnome-online-accounts suggests no packages.

-- no debconf information

Bug#1053246: Security support ended for Xen 4.14 in Bullseye

[Holger Levsen]

control: tags -1 + moreinfo
thanks

On Mon, Oct 02, 2023 at 02:18:49PM -0300, Santiago Ruano Rincón wrote:
> Could you please wait a little bit before moving forward. In the Debian
> bullseye LTS context, we would like to know if there are interest from
> LTS users, and look for help to maintain it. At least, partially.


-- 
cheers,
Holger

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

„If you don't like vaccination, try the disease.“ (Herwig Kollaritsch)


signature.asc
Description: PGP signature

Bug#1053135: RM tungstenite

[Matthias Geiger]

Control: tag -1 moreinfo

ring 0.17 has finally been released upstream supporting mips, s390x and 
riscv64. Once this gets uploaded rustls will also be installable on 
those arches,


resulting in tungstenite being installable again.

Leaving open until this is resolved.

best,

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



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1053397: ytree: new upstream version available

[Ricardo Mones]

Source: ytree
Version: 1.99pl1-2.1
Severity: wishlist
X-Debbugs-Cc: mo...@debian.org

Dear Maintainer,

On ytree's homepage a new upstream version is listed (2.05 at the moment
of writting this message).

As usually, would be nice to have it packaged for Debian.

best regards and thanks in advance,

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

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

Bug#1053396: keepassxc: AutoType does not work with Wayland

[Harald Niemeczek]

Package: keepassxc
Version: 2.7.4+dfsg.1-2
Severity: normal
Tags: patch
X-Debbugs-Cc: oyg...@gmail.com

Hi!

Keepassxc has disabled AutoType functionality on Wayland
[https://keepassxc.org/docs/KeePassXC_UserGuide#_auto_type].
I don't know why it has been implemented this way, but running keepassxc with
-platform xcb command-line flag or running
export QT_QPA_PLATFORM=xcb
before fixes the problem (See above linked documentation).

Pleas add one of these options to the .desktop file so keepassxc has enabled
autotype-functionality when using wayland.

(Note: In case there are Debian versions that don't ship with wayland this may
need to be implemented conditionally)


Thanks!



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

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

Versions of packages keepassxc depends on:
ii  libargon2-10~20171227-0.3+deb12u1
ii  libbotan-2-19  2.19.3+dfsg-1
ii  libc6  2.36-9+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libminizip11.1-8+b1
ii  libpcsclite1   1.9.9-2
ii  libqrencode4   4.1.1-1
ii  libqt5concurrent5  5.15.8+dfsg-11
ii  libqt5core5a   5.15.8+dfsg-11
ii  libqt5dbus55.15.8+dfsg-11
ii  libqt5gui5 5.15.8+dfsg-11
ii  libqt5network5 5.15.8+dfsg-11
ii  libqt5svg5 5.15.8-3
ii  libqt5widgets5 5.15.8+dfsg-11
ii  libqt5x11extras5   5.15.8-2
ii  libreadline8   8.2-1.3
ii  libstdc++6 12.2.0-14
ii  libusb-1.0-0   2:1.0.26-1
ii  libx11-6   2:1.8.4-2+deb12u1
ii  libxtst6   2:1.2.3-1.1
ii  libzxcvbn0 2.5+dfsg-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages keepassxc recommends:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1

Versions of packages keepassxc suggests:
ii  webext-keepassxc-browser  1.8.4+repack1-7
pn  xclip 

-- no debconf information

Bug#933017: Please add source link and bug reporting info to footer

[Ian Jackson]

Control: reopen -1
Control: retitle -1 Please make page source code link appear in every page 
footer

> From: Thomas Lange 
...
> We have this info not on all web pages but on our startpage www.d.org.

Thanks.  However, I think it should be at the very least in this page:

> [Ian Jackson:]
> > I looked for this information in the footer of this page
> >   https://www.debian.org/legal/privacy
> > and it wasn't there.

Ideally it would be on every page.  Do you agree ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1053394: dash should not propagate aliases to subshells

[Дилян Палаузов]

To: 1053...@bugs.debian.org, d...@vger.kernel.org

Hello,

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03_01 
says:


2.3.1 Alias Substitution

When used as specified by this volume of POSIX.1-2017, alias definitions 
shall not be inherited by separate invocations of the shell or by the 
utility execution environments invoked by the shell.



So a subshell shall have no knowledge about the aliases from the 
supershell, and backticks start a subshell.


These programs

#!/bin/bash
alias wslpath=echo
find `wslpath /tmp`

and

#!/bin/dash
alias wslpath=echo
find `wslpath /tmp`

produce different results (bash 5.2.15-3.fc38,  dash 0.5.12-1.fc38) when 
executed on a WSL2 system.  The former program shows the content of the 
current directory, the latter program shows the content of /tmp .


Moreover, I filled this initially towards the Debian Bug tracking system 
(cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053394) , and 
was then told to check http://gondor.apana.org.au/~herbert/dash/ .


Please include in the repository 
https://git.kernel.org/pub/scm/utils/dash/dash.git links to 
http://gondor.apana.org.au/~herbert/dash/ and d...@vger.kernel.org , for 
instance in src/dash.1, so that it is documented where to report 
problems in dash.


Kind regards
  Dilyan

Bug#1053394: dash should not propagate aliases to subshells

[Andrej Shadura]

Control: tag -1 upstream

Hello,

On Tue, 3 Oct 2023, at 10:53, Дилян Палаузов wrote:
> I use actually dash on Fedora version 0.5.12-1.fc38, but the only way to 
> report bugs towards dash seems to be the Debian bug tracker system.

You can report bugs directly to the dash upstream developer at 
d...@vger.kernel.org as described here: 
http://gondor.apana.org.au/~herbert/dash/

If would be great if you submitted this issue to them.

Thanks!

-- 
Cheers,
  Andrej

Bug#1053301: udev.postinst removes valid /etc/rc*.d/ symlinks

[Mark Hindley]

Control: reopen -1 "Bill Brelsford "
Control: reassign -1 udev 254.3-1
Control: severity -1 severe
Justification: Breaks unrelated software; causes boot failure on some systems

Dear systemd maintainers,

As Bill has reported here, the new udev.postinst is breaking systems not using
systemd as PID 1.

On Fri, Sep 29, 2023 at 09:51:21PM -0700, Bill Brelsford wrote:
> When upgrading (with aptitude), initscripts (3.08-1) is set up
> before udev (254.4-1). Udev claims to remove the "obsolete
> conffile /etc/init.d/udev", but it's still there. However, the
> rc*.d symlinks are not -- "update-rc.d udev defaults" fixes it.

It is reproducible by installing trixie udev and initscripts in a bookworm
chroot:

bookworm-chroot:/# dpkg --no-pager -l udev initscripts
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
+++-==---=
ii  initscripts3.06-4   all  scripts for initializing and 
shutting down the system
ii  udev   252.12-1~deb12u1 amd64/dev/ and hotplug management 
daemon
bookworm-chroot:/# ls -l /etc/rc?.d/*udev*
lrwxrwxrwx 1 root root 14 Oct  3 08:36 /etc/rc0.d/K01udev -> ../init.d/udev
lrwxrwxrwx 1 root root 14 Oct  3 08:36 /etc/rc6.d/K01udev -> ../init.d/udev
lrwxrwxrwx 1 root root 14 Oct  3 08:36 /etc/rcS.d/S02udev -> ../init.d/udev
bookworm-chroot:/# apt install --no-install-recommends -t trixie udev 
initscripts
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libudev1 systemd systemd-dev
Suggested packages:
  systemd-container systemd-homed systemd-userdbd systemd-boot systemd-resolved 
libfido2-1 libqrencode4 libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0
  polkitd python3:any python3-pefile
Recommended packages:
  default-dbus-system-bus | dbus-system-bus systemd-timesyncd | time-daemon
The following NEW packages will be installed:
  systemd systemd-dev
The following packages will be upgraded:
  initscripts libudev1 udev
3 upgraded, 2 newly installed, 0 to remove and 60 not upgraded.
Need to get 5299 kB of archives.
After this operation, 11.8 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian trixie/main amd64 udev amd64 254.4-1 [1756 
kB]
Get:2 http://deb.debian.org/debian trixie/main amd64 systemd-dev all 254.4-1 
[54.7 kB]
Get:3 http://deb.debian.org/debian trixie/main amd64 systemd amd64 254.4-1 
[3304 kB]
Get:4 http://deb.debian.org/debian trixie/main amd64 libudev1 amd64 254.4-1 
[120 kB]
Get:5 http://deb.debian.org/debian trixie/main amd64 initscripts all 3.08-1 
[64.5 kB]
Fetched 5299 kB in 1s (4686 kB/s)  
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 6627 files and directories currently installed.)
Preparing to unpack .../udev_254.4-1_amd64.deb ...
Unpacking udev (254.4-1) over (252.12-1~deb12u1) ...
Selecting previously unselected package systemd-dev.
Preparing to unpack .../systemd-dev_254.4-1_all.deb ...
Unpacking systemd-dev (254.4-1) ...
Selecting previously unselected package systemd.
Preparing to unpack .../systemd_254.4-1_amd64.deb ...
Unpacking systemd (254.4-1) ...
Preparing to unpack .../libudev1_254.4-1_amd64.deb ...
Unpacking libudev1:amd64 (254.4-1) over (252.12-1~deb12u1) ...
Setting up libudev1:amd64 (254.4-1) ...
(Reading database ... 7562 files and directories currently installed.)
Preparing to unpack .../initscripts_3.08-1_all.deb ...
Unpacking initscripts (3.08-1) over (3.06-4) ...
Setting up initscripts (3.08-1) ...
Installing new version of config file /etc/init.d/brightness ...
Setting up systemd-dev (254.4-1) ...
Setting up systemd (254.4-1) ...
Setting up udev (254.4-1) ...
Removing obsolete conffile /etc/init.d/udev ...
Processing triggers for libc-bin (2.36-9+deb12u1) ...
bookworm-chroot:/# ls -l /etc/rc?.d/*udev*
ls: cannot access '/etc/rc?.d/*udev*': No such file or directory

It appears that the udev postinst is running after initscripts has been
configured and removing the /etc/rc?.d/ udev symlinks.

bookworm-chroot:/# dpkg-reconfigure initscripts
bookworm-chroot:/# ls -l /etc/rc?.d/*udev*
lrwxrwxrwx 1 root root 14 Oct  3 08:50 /etc/rc0.d/K01udev -> ../init.d/udev
lrwxrwxrwx 1 root root 14 Oct  3 08:50 /etc/rc6.d/K01udev -> ../init.d/udev
lrwxrwxrwx 1 root root 14 Oct  3 08:50 /etc/rcS.d/S02udev -> ../init.d/udev

The relevant code in udev's postinst has:

 if dpkg --compare-versions "$2" lt-nl "254.1-4~"; then
update-rc.d udev remove || true
fi

I think there are 2 issues here:-

 1) update-rc.d shouldn't be called if /etc/init.d/udev exists and is not owned
by bin:udev.

 2) There appears to be a typo: the version of 

Bug#1053387: reportbug: querybts crashes when more than one bug number is passed on the command line

[Nis Martensen]

On 03.10.2023, Asher Gordon wrote:
> This code is problematic for several reasons.
> 
> 1. The elements of 'package' are integers, not strings (I am not sure
> under what circumstances they would be strings). This is what causes the
> crash.

This function is not only called by querybts, but also by reportbug, in
which case the elements are usually strings.

Sorry, but querybts is basically unmaintained. There have been thoughts
of dropping it for many years, it only has not been done yet because it
still mostly works. Maybe we should finally do it, to avoid people
(i.e., you in this case) wasting their time analysing its bugs?

Reportbug is nowadays superior to querybts in querying the bts (if you
don't know the bug number(s) yet). And if you already have the bug
number(s), I find it more convenient to look them up in the browser
directly.

Thanks for your detailed report and analysis, though. About the patch -
did you try it in the text console where xdg-open starts a text browser
and must return to reportbug/querybts after closing the browser? Not
sure if this still works if you start the browser in the background.

Bug#1053395: Resolving valgrind dependency, take 2

[Christoph Biedl]

Package: pv
Version: 1.8.0-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Hi there,

thanks for resolving the valgrind dependency issue for armel and a few
more release archs. Unfortunatly, there are several port archs where pv
still fails to build. As a solution, may I ask you to build-depend on
valgrind-if-available instead? That solved the problem on all archs I
rebuild pv - except x32 which has other issues, and for quite some time
already.

Christoph


signature.asc
Description: PGP signature

Bug#1053394: dash should not propagate aliases to subshells

[Дилян Палаузов]

Package: dash
Version: 0.5.12-6

Hello,

I use actually dash on Fedora version 0.5.12-1.fc38, but the only way to 
report bugs towards dash seems to be the Debian bug tracker system.


https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03_01 
says:


2.3.1 Alias Substitution

When used as specified by this volume of POSIX.1-2017, alias definitions 
shall not be inherited by separate invocations of the shell or by the 
utility execution environments invoked by the shell.



So a subshell shall have no knowledge about the aliases from the 
supershell, and backticks start a subshell.


These programs

#!/bin/bash
alias wslpath=echo
find `wslpath /tmp`


and

#!/bin/dash
alias wslpath=echo
find `wslpath /tmp`

produce different results (bash 5.2.15-3.fc38) when executed on a WSL2 
system.  The former program shows the content of the current directory, 
the latter program shows the content of /tmp .


Kind regards
  Dilyan

Bug#1053380: qgit: Segmentation fault (during ld binding of libGL.so.1)

[Andrey Rakhmatullin]

On Tue, Oct 03, 2023 at 12:05:44AM +0200, Michel Briand wrote:
> Package: qgit
> Version: 2.10-2
> Severity: important
> 
> Dear Maintainer,
> 
> after upgrade from debian 11 to debian 12, some qt application will crash 
> (Segmentation fault).
> 
> qgit crashes, but also qt5ct, 2048-qt, qbittorrent.
> 
> After searching the web, I've found [1] and [2] that point me to an idea, a 
> possible digging.
> 
> [1] https://github.com/FrodeSolheim/fs-uae/issues/31
> [2] http://fs-uae.net/2015/01/27/fs-uae-2-4-3-released
> 
> Many thanks to NVIDIA which actually tracked down the bug in FS-UAE! The 
> problem was an unused function (mprotected),
>   a legacy from older WinUAE code, which was exported and caused the 
> NVIDIA drivers to load this function instead of the
>   correct one from libc. I’m quite impressed that they contacted me with 
> information about the bug, and I think this shows
>   how serious they are about their Linux drivers 
> 
> My idea was related to the use of libGL by the qt libraries.
> 
> And, finally, I've found that article [3] that tell about the possibility of 
> testing my idea.
> 
> [3] 
> https://forum.qt.io/topic/90786/turn-off-opengl-optimization-via-qt-environment-variable
> 
> Here is the behavior I observed and the digging into the problem.
> I've found that the last symbol binded was sigaddset, so I searched for it. 
> Maybe I'd have to search for the last lib?
Sorry, do you mean you think it's a bug in qgit?
If so, so far it doesn't look actionable unfortunately.

Bug#1053393: O: mysqltuner -- high-performance MySQL tuning script

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: mysqltu...@packages.debian.org
Control: affects -1 + src:mysqltuner

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: high-performance MySQL tuning script
 High-performance MySQL tuning script written in perl that will provide
 you with a snapshot of a MySQL server?s health. Based on the statistics
 gathered, specific recommendations will be provided that will increase a
 MySQL server's efficiency and performance. The script gives you
 automated MySQL tuning that is on the level of what you would receive
 from a MySQL DBA.
 .
 Features:
 .
* Memory Usage: Calculates MySQL memory usage at max load and makes
  recommendations for increasing or decreasing the MySQL memory
  footprint. Per-thread and server-wide buffer data is calculated
  separately for an accurate snapshot of the server?s configuration.
* Slow Queries: Reviews the amount of slow queries relative to the
  total queries. Slow query time limits are also analyzed and
  recommendations are made.
* Connections: Current and historical connection counts are
  reviewed.
* Key Buffer: Takes configuration data and compares it to the actual
  indexes found in MyISAM tables. Key cache hit rates are calculated
  and variable adjustments are suggested.
* Query Cache: Query cache hit rates and usage percentages are used
  to make recommendations for the query cache configuration
  variables.
* Sorting & Joins: Per-thread buffers that affect sorts and joins
  are reviewed along with the statistics from the queries run
  against the server.
* Temporary Tables: Variable recommendations are made to reduce
  temporary tables that are written to the disk.
* Table Cache: Compares total tables opened to the currently open
  tables. Calculates the table cache hit rate in order to make
  suggestions.
* Open Files: Determines if the server will approach or run into the
  open file limit set by the operating system or the MySQL server
  itself.
* Table Locks: Finds table locking that forces queries to wait and
  makes suggestions for reducing locks that require a wait.
* Thread Cache: Calculates how many times MySQL must create a new
  thread to respond to a query.
* Aborted Connections: Finds applications that are not closing
  connections to MySQL properly.
* Read/Write Ratios: Calculates the percentage of read and write
  operations on your MySQL installation.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1053392: O: yaskkserv -- small and fast SKK dictionary server intended for embedded use

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: yaskks...@packages.debian.org
Control: affects -1 + src:yaskkserv

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: small and fast SKK dictionary server intended for embedded use
 yaskkserv is a dictionary server for the SKK Japanese input method
 system. yaskkserv is written in C++ from scratch in consideration of
 embedded environment, but is compatible with skkserv on the protocol
 behavior.
 .
 yaskkserv can use multiple dictionaries and also supports server
 completion.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1053391: O: goldencheetah -- set of analysis tools for cycling performance

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: goldenchee...@packages.debian.org
Control: affects -1 + src:goldencheetah

Satoru KURASHIKI  intends to orphan package,
but he does not have his time.  So I do it for him acked by him.

Description: set of analysis tools for cycling performance
 GoldenCheetah is a software package that:
  * Provides a rich set of analysis tools, including a critical power graph,
   BikeScore calculation, histogram analysis, a best interval finder, and
   a pedal force versus pedal velocity chart, to name just a few.
  * Downloads ride data directly from supported devices.
  * Imports ride data downloaded with other programs, including
   TrainingPeaks WKO+ and the manufacturers' software for the Ergomo,
   Garmin, Polar, PowerTap, and SRM devices.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#656665: ITP: libglobalplatform -- library to handle communication with GlobalPlatform cards

[Simon Josefsson]

retitle 656665 ITP: globalplatform -- library to handle communication with 
GlobalPlatform cards
owner 656665 Simon Josefsson 
tag 656665 + pending
thanks

Hi.

I have discovered that upstream is active again, and have made releases
in recent years:

https://github.com/kaoh/globalplatform

That projects merges all three of the earlier globalplatform, gpshell,
and gppcscconnectionplugin projects.  Now only one Debian source
packages would be necessary for the three earlier upstream projects.
Thus I think #656959 and #656957 could be closed once #656665 is fixed
with an upload of the new merged package.

For references, here are my earlier packaging effort which was never
uploaded into Debian but only used locally:

https://github.com/Yubico/globalplatform-dpkg
https://github.com/Yubico/gpshell-dpkg
https://github.com/Yubico/gppcscconnectionplugin-dpkg

The following is where I experiment with new packaging, it is work in
progress:

https://salsa.debian.org/auth-team/globalplatform

/Simon


signature.asc
Description: PGP signature

Bug#1034015: exim4: exim paniclog on lenovo has non-zero size

[Peter Bex]

On Mon, Oct 02, 2023 at 07:12:28PM +0200, Marc Haber wrote:
> On Mon, Oct 02, 2023 at 04:55:40PM +0200, Peter Bex wrote:
> > I have the same issue on my server.  It seems to happen any time the
> > exim4 daemon gets restarted.  Logs indicate that the process is not shut
> > down correctly, leaving a stale daemon listening on the old port, which
> > causes the error on startup for the new daemon.
> 
> If this is reproducible,it is probably unrelated to this bug report.
> Does the last exim process eventually vanish if you wait a while? It
> might stil be doing something, such as waiting for a timeout.

I just waited for 15 minutes after "systemctl stop exim4", and the
process is still alive.  I can also still connect to port 25, exim
is still actively listening on both ipv4 and ipv6 interfaces.
Journalctl contains no errors, it just claims it stopped cleanly:

Oct 03 09:23:29 scully.more-magic.net systemd[1]: Stopping exim4.service - LSB: 
exim Mail Transport Agent...
Oct 03 09:23:29 scully.more-magic.net exim4[592530]: Stopping MTA:.
Oct 03 09:23:29 scully.more-magic.net systemd[1]: exim4.service: Deactivated 
successfully.
Oct 03 09:23:29 scully.more-magic.net systemd[1]: exim4.service: Unit process 
575519 (exim4) remains running after unit stopped.
Oct 03 09:23:29 scully.more-magic.net systemd[1]: Stopped exim4.service - LSB: 
exim Mail Transport Agent.
Oct 03 09:23:29 scully.more-magic.net systemd[1]: exim4.service: Consumed 
4.140s CPU time.


It only complains about the left-over process when I start it again:


Oct 03 09:38:40 scully.more-magic.net systemd[1]: exim4.service: Found 
left-over process 575519 (exim4) in control group while starting unit. Ignoring.
Oct 03 09:38:40 scully.more-magic.net systemd[1]: This usually indicates 
unclean termination of a previous run, or service implementation deficiencies.
Oct 03 09:38:40 scully.more-magic.net systemd[1]: Starting exim4.service - LSB: 
exim Mail Transport Agent...
Oct 03 09:38:40 scully.more-magic.net exim4[592898]: Starting MTA: exim4.
Oct 03 09:38:40 scully.more-magic.net systemd[1]: Started exim4.service - LSB: 
exim Mail Transport Agent.


This is also usually when exim itself notices and creates the paniclog
entry.  Strangely enough, it didn't do that this time...

Cheers,
Peter


signature.asc
Description: PGP signature