Bug#1060429:

[Philip Rinn]

Control: reassign -1 python-django-solo

Hi Helmut,

thanks for the bug report, but I guess you missed that solo1-cli.ships this 
file for years (in stable, testing, unstable) while  python-django-solo was 
just uploaded yesterday. So I think the bug is in python-django-solo actually.

Best,
Philip

Bug#1060430: ITP: python-django-test-migrations -- Testing database migrations for Django

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 


* Package name: python-django-test-migrations
  Version : 1.3.0
  Upstream Contact: Nikita Sobolev 
* URL : https://github.com/wemake-services/django-test-migrations
* License : Expat
  Programming Lang: Python
  Description : Testing database migrations for Django

 This framework allows one to test migrations with respect to:
  * schema and data
  * forward and rollback
  * order, names
  * database configuration
 It also features fully typed annotations.
 .
 Django is a high-level Python web development framework.

This package will be maintained in python team.

It is a test dependency of awx.
It seems to be a nice piece for testing in Django, and is alive.

Bug#1060429: solo1-cli has an undeclared file conflict on /usr/lib/python3/dist-packages/solo/__init__.py

[Helmut Grohne]

Package: solo1-cli
Version: 0.1.1-5
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + python3-django-solo

solo1-cli has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/lib/python3/dist-packages/solo/__init__.py is contained in
the packages
 * python3-django-solo/2.1.0-1 as present in unstable
 * solo1-cli/0.1.1-5 as present in experimental

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

Kind regards

The Debian Usr Merge Analysis Tool

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

Bug#1057442: onboard ftbfs with Python 3.12

[Graham Inggs]

There's no _cairo.cpython-312-x86_64-linux-gnu.so in python3-cairo
because pycairo no longer builds extensions for all supported Python
versions, see #1055488.

Bug#1060386: fail2ban: Fail2ban Debian 12 fails to start

[Guido van Brakel]

Yeah but that shouldn't be needed like in previous distributions fail2ban 
should just start automatically after install the package

From: Guido van Brakel 
Sent: Wednesday, January 10, 2024 3:06:47 PM
To: sub...@bugs.debian.org 
Subject: Bug#1060386: fail2ban: Fail2ban Debian 12 fails to start

Package: fail2ban
X-Debbugs-Cc: guido.vanbra...@outlook.com
Version: 1.0.2-2
Severity: important
Dear Maintainer,

   * What led up to the situation? Installing fail2ban on Debian 12
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action? Fail2ban fails to start
   * What outcome did you expect instead? Fail2ban just starting without 
needing to
-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-16-cloud-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: 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  python3-pyinotify  0.9.6-2
ii  python3-systemd235-1+b2
ii  whois  5.5.17
Versions of packages fail2ban suggests:
Versions of packages fail2ban suggests:
pn  mailx  
pn  monit  
pn  sqlite3
pn  system-log-daemon  
-- Configuration Files:
/etc/fail2ban/jail.conf changed:
[INCLUDES]
before = paths-debian.conf
[DEFAULT]
ignorecommand =
bantime  = 10m
findtime  = 10m
maxretry = 5
maxmatches = %(maxretry)s
backend = systemd

Bug#1060428: kmail: on new ssl certificate infinite loop of "The server failed the authenticity check"

[Russell Coker]

Package: kmail
Version: 4:22.12.3-1
Severity: normal
Tags: upstream

My workstation runs 24*7 and one of the servers it uses for IMAP has a
certificate name that doesn't match.  I tell it to "trust forever" and it
works.  Then the server gets a new certificate (part of an automated
process) and it gives an error (which is good).  But when this happens
while I'm not at my desk it keeps polling the IMAP server and giving a new
message dialogue every time it fails the check, which leads to CTRL-ALT-ESC
being required as the only way to close all those windows.  I'll send a
screen-shot after the bug number is assigned.

I think this should only give one error dialogue about it and should
refrain from talking to the IMAP server after that until the user
responds to the dialogue.

-- System Information:
Debian Release: 12.4
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-13-amd64 (SMP w/18 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: unable to detect

Versions of packages kmail depends on:
ii  akonadi-server   4:22.12.3-1
ii  kdepim-runtime   4:22.12.3-1
ii  kio  5.103.0-1
ii  libc62.36-9+deb12u3
ii  libgcc-s113.1.0-9
ii  libgpgmepp6  1.18.0-3+b1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22  4:22.12.3-1
.12]
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.12]  4:22.12.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1
ii  libkf5akonadisearch-bin  4:22.12.3-1
ii  libkf5akonadisearch-plugins  4:22.12.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug  4:22.12.3-1
5-22.12]
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22  4:22.12.3-1
.12]
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22  4:22.12.3-1
.12]
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5calendarcore5abi2  5:5.103.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.12]4:22.12.3-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5contacts5  5:5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5grantleetheme-plugins  22.12.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-22.12]  4:22.12.3-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement  22.12.3-1
5-22.12]
ii  libkf5identitymanagementwidgets5 [libkf5identityman  22.12.3-1
agementwidgets5-22.12]
ii  libkf5itemmodels55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-22  22.12.3-1
.12]
ii  libkf5ksieveui5 [libkf5ksieveui5-22.12]  4:22.12.3-1
ii  libkf5ldap5abi1 [libkf5ldap5-22.12]  22.12.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-22.12]4:22.12.3-1
ii  libkf5libkleo5 [libkf5libkleo5-22.12]4:22.12.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-22.12]  4:22.12.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportako  22.12.3-1
nadi5-22.12]
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-  4:22.12.3-2~deb12u1
22.12]
ii  libkf5messagecore5abi1 [libkf5messagecore5-22.12]4:22.12.3-2~deb12u1
ii  libkf5messagelist5abi1 [libkf5messagelist5-22.12]4:22.12.3-2~deb12u1
ii  libkf5messageviewer5abi1 [libkf5messageviewer5-22.1  4:22.12.3-2~deb12u1
2]
ii  libkf5mime5abi1 

Bug#1059713: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#1059713: fixed in linux 6.7-1~exp1)

[Salvatore Bonaccorso]

Hi,

On Wed, Jan 10, 2024 at 09:42:17PM -0800, Alison Chaiken wrote:
> On 2024-01-09 00:15, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the linux-image-6.6.8-amd64-dbg package:
> > 
> > #1059713: linux-image-6.6.8-amd64-dbg: vmlinux-6.6.8-amd64 is stripped
> > 
> > It has been closed by Debian FTP Masters
> >  (reply to Bastian Blank
> > ).
> > 
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Debian FTP
> > Masters  (reply to Bastian Blank
> > ) by
> > replying to this email.
> 
> Unfortunately the linux-image-6.6.9-amd64-dbg package has the same problem
> as 6.6.8:

The fixed version is in experimental, uploaded as 6.7-1~exp1, so the
change is not contained in the most recent unstable version.

Regards,
Salvatore

Bug#1060427: python3-appdirs: Do not release with trixie

[Scott Kitterman]

Package: python3-appdirs
Version: 1.4.4-4
Severity: serious
Justification: maintainer determination

This is dead upstream and easily replacable with platformdirs.  Rather
than release trixie with appdirs, remaining users should port to
platformdirs instead.

Scott K

Bug#1059713: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#1059713: fixed in linux 6.7-1~exp1)

[Alison Chaiken]

On 2024-01-09 00:15, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the linux-image-6.6.8-amd64-dbg package:

#1059713: linux-image-6.6.8-amd64-dbg: vmlinux-6.6.8-amd64 is stripped

It has been closed by Debian FTP Masters
 (reply to Bastian Blank
).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP
Masters  (reply to Bastian Blank
) by
replying to this email.


Unfortunately the linux-image-6.6.9-amd64-dbg package has the same 
problem as 6.6.8:


$ file $(find /usr/lib/debug/boot -name "vmlinux*")
/usr/lib/debug/boot/vmlinux-6.6.8-amd64:   ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), statically linked, 
BuildID[sha1]=144f4fcbb5d506514b6552bbd7c7d03fd7ddadde, stripped
/usr/lib/debug/boot/vmlinux-6.6.9-amd64:   ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), statically linked, 
BuildID[sha1]=d069eaec45f8c788a647d37705161ff112618d2f, stripped
/usr/lib/debug/boot/vmlinux-6.5.0-2-amd64: ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), statically linked, 
BuildID[sha1]=1921e63a5a6fcc611ae79e17f64ec58225ec23eb, with debug_info, 
not stripped


$ sudo drgn tools/workqueue/wq_monitor.py
warning: missing some debugging symbols (see 
https://drgn.readthedocs.io/en/latest/getting_debugging_symbols.html):
  /usr/lib/debug/boot/vmlinux-6.6.9-amd64 (libdwfl error: No DWARF 
information found)
  kernel modules (could not find loaded kernel modules: could not find 
'struct module')


Thanks,
Alison

---
Alison Chaiken   ali...@she-devel.com
http://she-devel.com
If you don't keep up the running battle, you will cede the battlefield. 
-- Herb Sutter

Bug#1060404: libdata-streamserializer-perl: FTBFS on ppc64el: t/05_memory_leak.t failure

[Niko Tyni]

Control: severity -1 normal

On Wed, Jan 10, 2024 at 09:00:27PM +0200, Niko Tyni wrote:
> Source: libdata-streamserializer-perl
> Source Version: 0.07-1
> Severity: serious
> Tags: ftbfs
> Control: block 1055955 with -1
> 
> This package failed to build from source on ppc64el against Perl 5.38.
> 
> After two failures it looks deterministic but giving it back for a retry
> might still be worth a try.

It built on the third try, so lowering severity.

> This is currently a blocker for the Perl 5.38 transition.

Happily no longer :)
-- 
Niko

Bug#1060426: autopkgtest-build-qemu doesn't pass --mirror (or the obsolete mirror positional argument) to setup-testbed

[Santiago Ruano Rincón]

Package: autopkgtest
Version: 5.31.2
Severity: normal
Tags: patch

Dear maintainers,

autopkgtest-build-qemu ends up in error when trying to build an image
for Freexian's stretch ELTS. The image is successfully built for the
archived (as in archive.d.o) stretch. This is the relevant part of the
log:

/usr/share/autopkgtest/setup-commands/setup-testbed: Attempting to set up 
Debian/Ubuntu apt sources automatically
Failed to auto-detect apt mirror; set $MIRROR explicitly
ERROR: Program failed: 1
ERROR: RuncmdError('Program failed: 1')
Something went wrong, cleaning up!

I'll prepare a MR, but in the meantime, the attache patch fixes the
issue.

Thanks!

 -- S

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

Kernel: Linux 6.6.9-amd64 (SMP w/16 CPU threads; PREEMPT)
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 autopkgtest depends on:
ii  apt-utils   2.7.8
ii  libdpkg-perl1.22.2
ii  mawk1.3.4.20231126-1
ii  procps  2:4.0.4-2+b1
ii  python3 3.11.6-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.32.2-1+b1

Versions of packages autopkgtest suggests:
ii  docker.io20.10.25+dfsg1-2+b3
pn  fakemachine  
ii  genisoimage  9:1.1.11-3.4
ii  lxc  1:5.0.3-2
pn  lxd  
ii  ovmf 2023.11-4
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.7
ii  qemu-efi-aarch64 2023.11-4
ii  qemu-efi-arm 2023.11-4
ii  qemu-system  1:8.2.0+ds-4
ii  qemu-utils   1:8.2.0+ds-4
ii  schroot  1.6.13-3+b3
ii  util-linux   2.39.3-6
ii  vmdb20.28-1
ii  zerofree 1.1.1-1

-- no debconf information
From b21a596e11a2f5daf9ef4886a81911519ac4337e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?= 
Date: Wed, 10 Jan 2024 22:11:21 -0500
Subject: [PATCH] autopkgtest-build-qemu pass MIRROR to setup-testbed

---
 tools/autopkgtest-build-qemu | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/autopkgtest-build-qemu b/tools/autopkgtest-build-qemu
index c3938b0..a7d135c 100755
--- a/tools/autopkgtest-build-qemu
+++ b/tools/autopkgtest-build-qemu
@@ -587,6 +587,7 @@ class BuildQemu:
 'shell': (
 'export AUTOPKGTEST_BUILD_QEMU=1; ' +
 'export RELEASE=' + shlex.quote(release) + '; ' +
+'export MIRROR=' + shlex.quote(mirror) + '; ' +
 shlex.quote(s) + ' "$ROOT"'
 ),
 'root-fs': 'root',
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1058613: [External] Re: Source archive of DSS missing

[Wu, Hao]

Thanks. Just done that. Hopefully it’ll work this time.

Hao


From: "Shepherd, Lori" 
Date: Wednesday, January 10, 2024 at 8:30 PM
To: "Wu, Hao" , Andreas Tille , Harry Feng 

Cc: "1058...@bugs.debian.org" <1058...@bugs.debian.org>, Debian R 
, Bioconductor Package Maintainer 

Subject: Re: [External] Re: Source archive of DSS missing

Two points:
1.  You need a valid version bump for it to propagate on Bioconductor 
systems. so it devel you would need to push a bump to 1.51.1
2.   There are always two active branches in Bioconductor. devel and the 
current release found currently on branch RELEASE_3_18.  You would have to push 
to RELEASE_3_18 branch in order fo the change to be active in release. (with a 
valid version bump of 1.50.1)

Hope this helps!
Cheers,



Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Wu, Hao 
Sent: Tuesday, January 9, 2024 5:29 PM
To: Kern, Lori ; Andreas Tille 
; Hao Feng 
Cc: 1058...@bugs.debian.org <1058...@bugs.debian.org>; Debian R 
; Bioconductor Package Maintainer 

Subject: Re: [External] Re: Source archive of DSS missing


I thought I have fixed this. Just checked, at least from my end I have added 
edgeR to suggests, and have pushed the change. What else can I do?



@Lori, if the change is not there, could you please help me to make this 
change? DSS is pretty widely used and I certainly don’t want it to be 
deprecated. Thank you so much.



Regards,

Hao











From: "Shepherd, Lori" 
Date: Tuesday, January 9, 2024 at 11:51 PM
To: Andreas Tille , "Wu, Hao" , Harry Feng 

Cc: "1058...@bugs.debian.org" <1058...@bugs.debian.org>, Debian R 
, Bioconductor Package Maintainer 

Subject: [External] Re: Source archive of DSS missing





DSS is unavailable because it has yet to build this release.  The DSS 
maintainers have been notified multiple times but have yet to fix the package; 
DSS is currently at risk of deprecation if it is not fixed.

https://bioconductor.org/checkResults/release/bioc-LATEST/DSS/



Per the build report the solution is very simple. DSS needs to add the needed 
dependency edgeR to the list of Suggests package in the DESCRIPTION and push a 
valid version bump.







Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263



From: Andreas Tille 
Sent: Tuesday, January 9, 2024 10:32 AM
To: Hao Wu ; Hao Feng 
Cc: 1058...@bugs.debian.org <1058...@bugs.debian.org>; Debian R 
; Bioconductor Package Maintainer 

Subject: Re: Source archive of DSS missing



Hi again,

putting Bioconductor Package Maintainer in CC since I can not yet find
the source archive of DSS 2.50.0 neither at

   
https://secure-web.cisco.com/1IXs1DXRx2Y9dsRzzvLX84yK4Ym9eNeMVhLE8Z1rSs1XEmkvc9TlBtwJTB7DOPYrI0g0KgeG9hBwAaYvDvLqRK1ebqhCu939zH8_Ck55gAkqlcowiWK7FEtyGnoy96fpqFd5u8Kq4cTsmPqXSGOGVe3Ee8qt1XYN4fraNRyxTAewqnC9SkVz0R1nQdaUPBhbBNAJo5E-R9em72gaphy1VOuwNul219-EPQug_O_SL0CFbt7Twf2Xgmt2U8Y0Zml2cIDGiSRYkPfiQxbJMohb-19idtd9WZ813UCm9Twqayf_KuxiqzTKEcPRDqbpKVcTT/https%3A%2F%2Fbioconductor.org%2Fpackages%2Frelease%2Fbioc%2Fhtml%2FDSS.html

We need the source code to update the Debian package.

Kind regards
   Andreas.

Am Tue, Dec 12, 2023 at 03:09:29PM +0100 schrieb Andreas Tille:
> Hi,
>
> could someone please have a look at the source download?
>
> Thank you
>Andreas.
>
> Am Fri, Dec 08, 2023 at 04:04:27PM +0100 schrieb Andreas Tille:
> > Hi,
> >
> > when looking at
> >
> > 
> > https://secure-web.cisco.com/1IXs1DXRx2Y9dsRzzvLX84yK4Ym9eNeMVhLE8Z1rSs1XEmkvc9TlBtwJTB7DOPYrI0g0KgeG9hBwAaYvDvLqRK1ebqhCu939zH8_Ck55gAkqlcowiWK7FEtyGnoy96fpqFd5u8Kq4cTsmPqXSGOGVe3Ee8qt1XYN4fraNRyxTAewqnC9SkVz0R1nQdaUPBhbBNAJo5E-R9em72gaphy1VOuwNul219-EPQug_O_SL0CFbt7Twf2Xgmt2U8Y0Zml2cIDGiSRYkPfiQxbJMohb-19idtd9WZ813UCm9Twqayf_KuxiqzTKEcPRDqbpKVcTT/https%3A%2F%2Fbioconductor.org%2Fpackages%2Frelease%2Fbioc%2Fhtml%2FDSS.html
> >
> > and following the link "Source Archive" at bottom of the page linking
> > to
> > 
> > 

Bug#1060402: liblinux-termios2-perl: FTBFS on ppc64el: OS unsupported - no struct termios2

[Alexander Zangerl]

On Wed, 10 Jan 2024 20:37:37 +0200, Niko Tyni writes:
>> This package has never built on riscv64.
>Sorry, s/riscv64/ppc64el/ here.
>
...
>>   test-8985-0.c:4:19: error: storage size of ‘t’ isn’t known
>>4 |   struct termios2 t;
>>  |   ^
>>OS unsupported - no struct termios2

i no idea what is going wrong there. the TCGETS2
syscall (with the associated termios2 structure) was added to the
linux kernel many ages ago (in 2.6.20 apparently), and i cannot
find any indications anywhere that this isn't supported on all architectures.

it's certainly part of the termbits.h and ioctls.h of the
linux-libc-dev:ppc64el package...

for now i'll tag this package with the archs that seem
to work - but a better explanation for the gotcha would be welcome.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
Application has reported a "Not My Fault" in module KRNL.EXE 
in line 0200:103F


signature.asc
Description: Digital Signature

Bug#1060425: Font spacing and text encoding broken in version 9.31-1+b1.

[pthfdr]

Package: rxvt-unicode
Version: 9.31-1+b1

After upgrading the package from 9.31-1 to 9.31-1+b1, duo-spaced fonts 
always use 2 spaces for each character, even when displaying ASCII.


Attached screenshots:
1. Behavior in 9.31-1. Please note that upgrading Perl by itself does not 
cause the issue. The font is k8x12L: https://littlelimit.net/k8x12.htm
2. Behavior in 9.31-1+b1. Note the double spacing and the garbled 
scrollbar.
3. Changed the font to Unifont and the issue persists. It only occurs 
with duo-spaced fonts (which is typical when you need to display CJK). 
"Pure" monospaced fonts do not cause the issue.

4. Downgrade the package to 9.31-1 solves the issue.

Configurations (/etc/X11/Xresources/x11-common) attached in the 
"x11-common.txt" file. There is no user-level configuration.Xft.dpi: 96
*buffered:true
*cursorBlink:true
*cursorOffTime:200
*cursorOnTime:200
pointerMode:0
*skipScroll:true
*borderless:true
*scrollBar:false
*scrollbar.width:3
*rightScrollBar:true
*secondaryScroll:true
*multiScroll:on
*jumpScroll:on
*scrollTty*:false
*intensityStyles:true
*lineSpace:0
*letterSpace:0
*saveLines:8192
*ptyInitialErase:true
*form.Thickness:0
*borderWidth:0
*utf8:2
*scaleHeight:1.0
*cjkWidth:false
*font:xft:k8x12L:pixelsize=12
*boldFont:xft:k8x12L:pixelsize=12
*italicFont:xft:k8x12L:pixelsize=12
*boldItalicFont:xft:k8x12L:pixelsize=12
*VT100*colorMode:on
*VT100*boldColors:on
*VT100*dynamicColors:on
*VT100*underLine:on
*internalBorder:0
*externalBorder:0
*.foreground:   #F0F0F0
*.background:   #00
*.cursorColor:  #FF
*.color0:   #00
*.color1:   #F05858
*.color2:   #58F058
*.color3:   #F0F058
*.color4:   #5858F0
*.color5:   #F058F0
*.color6:   #58F0F0
*.color7:   #F0F0F0
*.color8:   #585858
*.color9:   #FFABAB
*.color10:   #ABFFAB
*.color11:   #AB
*.color12:   #ABABFF
*.color13:   #FFABFF
*.color14:   #AB
*.color15:   #FF

Bug#1037281: Please add support for MediaTek MT7986 in U-Boot

[Vagrant Cascadian]

On 2023-08-29, Diederik de Haas wrote:
> On 10 Jun 2023-06-10 Vagrant Cascadian  wrote:
>> On 2023-06-10, Bernhard wrote:
>> > I'm interested in the Router BANANA Pi R3 from Sinovoip:
>> > https://wiki.banana-pi.org/Banana_Pi_BPI-R3
>> >
>> > This Banana Pi has MediaTek MT7986 (Filogic 830).

There are now two board configs in u-boot 2024.01 that might be
relevent:

configs/mt7986a_bpir3_emmc_defconfig  configs/mt7986a_bpir3_sd_defconfig

>> I cannot say what it will take to support it in debian for sure...
>> ...
>> The other main thing is to check what support is needed in the linux
>> kernel...
>
> The good news is that it appears to be supported in the upstream kernel.
...
> I have a script which helps with identifying which kernel modules would be 
> needed based on the "compatible" strings in the dts file and running it on 
> the 
> mt7986a-bananapi-bpi-r3.dts revealed 1 missing component ... but a rather 
> important one, which AFAICT is related to ARCH_MEDIATEK not being enabled.

CONFIG_ARCH_MEDIATEK is now enabled in the Debian kernel configuration,
although there are probably still other kernel configurations needed.

Is this script available anywhere? :)


Still outstanding is arm-trusted-firmwawre, only mediatek 81xx platforms
so far:

plat/mediatek/mt8173/  plat/mediatek/mt8186/  plat/mediatek/mt8192/
plat/mediatek/mt8183/  plat/mediatek/mt8188/  plat/mediatek/mt8195/

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1060424: udisks2: Permission denied (Chromebook)

[Dan Jacobson]

Package: udisks2
Version: 2.10.1-5

Seen on Chromebook.

Setting up udisks2 (2.10.1-5) ...
vda: Failed to write 'change' to 
'/sys/devices/platform/1.pci/pci:00/:00:04.0/virtio3/block/vda/uevent':
 Permission denied
vdb: Failed to write 'change' to 
'/sys/devices/platform/1.pci/pci:00/:00:05.0/virtio4/block/vdb/uevent':
 Permission denied
vdc: Failed to write 'change' to 
'/sys/devices/platform/1.pci/pci:00/:00:06.0/virtio5/block/vdc/uevent':
 Permission denied
loop0: Failed to write 'change' to '/sys/devices/virtual/block/loop0/uevent': 
Permission denied
...
loop7: Failed to write 'change' to '/sys/devices/virtual/block/loop7/uevent': 
Permission denied

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

Kernel: Linux 6.1.60-08594-g03a802b9a072 (SMP w/8 CPU threads; PREEMPT)

Bug#346162: zsh: jobs -p is not POSIX-compliant

[Aaron Franke]

I see that this bug report hasn't received activity since 2006. I am still 
experiencing this issue in 2024 with zsh 5.9, where jobs -p is outputting more 
than just the PIDs.
I think the most optimal solution is for zsh to update the output of jobs -p to 
be POSIX-compliant and match bash.
However, if the zsh developers do not want to break compatibility, another 
option is to add a new flag that has the correct behavior. For example, a 
capitalized version, -P.

Thanks,Aaron Franke

Bug#1060397: libsys-syscall-perl: FTBFS on riscv64: t/01-epoll.t failure

[Eric Wong]

Eric Wong  wrote:
> Attached patch adds support for riscv64 and loongarch64

tested loongarch64 on cfarm400
tested aarch64 on cfarm103 (so no regression)

> I can't access loongarch64 machines on cfarm atm

I forgot 400/401 are on a nonstandard port :x

Bug#1033497: u-boot-imx: cubox-i does not reboot after installation

[Vagrant Cascadian]

Control: tags 1033497 confirmed

On 2023-03-26, Rainer Dorsch wrote:
> I installed bookworm on a cubox-i. After the installation was
> finished, the installed reported that it reboots now. The reboot did
> never complete tough. After I unplugged the power supply and replugged
> it, it booted normally, therefore the functionality of the system is
> not affected and it is a minor issue.

I have also seen this on several occasions as well, marking as
confirmed.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1060423: Postfix integration instructions appear to be erroneous

[Rob Leslie]

Package: mailman3
Version: 3.3.8-2~deb12u1
Severity: normal
File: /usr/share/doc/mailman3/README.Debian

Dear Maintainer,

The instructions for integrating Mailman3 with Postfix include the
following Postfix configuration parameters:

transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps 
hash:/var/lib/mailman3/data/postfix_lmtp
relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} 
hash:/var/lib/mailman3/data/postfix_domains

However, this appears to be inconsistent and can lead to a situation
where messages addressed to invalid recipients in the Mailman3 domains
are rejected with a mail "loops back to myself" message rather than a
more appropriate "User unknown". This is because local_recipient_maps is
only checked for recipient addresses in the local domain class (e.g.
domains listed in the mydestination parameter) and not for recipient
addresses in the relay domain class (relay_domains).

I believe it is more appropriate to use relay_recipient_maps instead of
local_recipient_maps together with relay_domains, e.g.:

transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp
relay_recipient_maps = hash:/var/lib/mailman3/data/postfix_lmtp
relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} 
hash:/var/lib/mailman3/data/postfix_domains

This configuration causes messages with invalid recipients in the
Mailman3 domains to be properly rejected with "User unknown".


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

Kernel: Linux 6.1.0-17-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 mailman3 depends on:
ii  cron 3.0pl1-162
ii  dbconfig-mysql   2.0.24
ii  dbconfig-sqlite3 2.0.24
ii  debconf [debconf-2.0]1.5.82
ii  init-system-helpers  1.65.2
ii  logrotate3.21.0-1
ii  python3  3.11.2-1+b1
ii  python3-aiosmtpd 1.4.3-1.1
ii  python3-alembic  1.8.1-2
ii  python3-authheaders  0.15.2-1
ii  python3-authres  1.2.0-3
ii  python3-click8.1.3-2
ii  python3-dateutil 2.8.2-2
ii  python3-dnspython2.3.0-1
ii  python3-falcon   3.1.1-1+b1
ii  python3-flufl.bounce 4.0-3
ii  python3-flufl.i18n   3.0.1-3
ii  python3-flufl.lock   5.0.1-4
ii  python3-gunicorn 20.1.0-6
ii  python3-importlib-resources  5.1.2-2
ii  python3-lazr.config  2.2.3-3
ii  python3-passlib  1.7.4-3
ii  python3-public   2.3-4
ii  python3-pymysql  1.0.2-2
ii  python3-requests 2.28.1+dfsg-1
ii  python3-sqlalchemy   1.4.46+ds1-1
ii  python3-zope.component   5.1.0-1
ii  python3-zope.configuration   4.4.1-1
ii  python3-zope.event   4.4-3
ii  python3-zope.interface   5.5.2-1+b1
ii  ucf  3.0043+nmu1

Versions of packages mailman3 recommends:
ii  postfix [mail-transport-agent]  3.7.9-0+deb12u1

Versions of packages mailman3 suggests:
pn  anacron
ii  lynx [www-browser] 2.9.0dev.12-1
pn  mailman3-doc   
ii  mariadb-server [virtual-mysql-server]  1:10.11.4-1~deb12u1

-- debconf information excluded

Bug#1056471: python-fabio's autopkg tests fail with Python 3.12

[Emmanuel Arias]

Hello,

I've just uploaded the patch. Thanks Yogeswaran!

Please consider merge this MR [0]

[0] https://salsa.debian.org/science-team/python-fabio/-/merge_requests/1


cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: FA9DEC5DE11C63F1
 ⠈⠳⣄

Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed

[Luca Boccassi]

Source: partman-crypto
Tags: patch

Dear Maintainer(s),

cryptsetup 2.7.0, currently in experimental, added support for self
encrypting drives using the OPAL functionality as the encryption layer
(managed by the kernel, not by the TCG utilities), both in standalone
mode and with a nested dm-crypt layer. Key management is done using
LUKS2, just like with dm-crypt, so that all existing functionality
works out of the box (tokens, passphrases, keyfiles, etc). A standard
LUKS2 header is used, which sits unencrypted on the disk as with dm-
crypt, and the nested range is then encrypted using OPAL's
functionality.

I have added support for these new options in partman-crypto, MR on
Salsa is open:

https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/7

The new options are shown only in the manual partitioning mode, and
only if the kernel, cryptsetup and the device all support this
functionality, otherwise they are hidden. A factory reset option for
the disk is also exposed. A small utility to call the required ioctl to
check for support on a given disk is added too.

I have tested this with a Kingston drive and it seems to work as
expected.

-- 
Kind regards,
Luca Boccassi


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

Bug#1060421: python3-botocore: botocore as a (useless) undeclared dependency on python3-six

[Alexandre Detiste]

Package: python3-botocore
Version: 1.31.49+repack-1
Severity: important
X-Debbugs-Cc: debian-pyt...@lists.debian.org

python3-core is importing python3-six for absolutely no reason

this package only work by luck for now because the
library got pulled-in by something else
(most likely python3-urllib2)

$ grep ' six' /usr/lib/python3/dist-packages/botocore -r | grep import
/usr/lib/python3/dist-packages/botocore/compat.py:import six

Greetings,



A possibility to catch this earlier would be to add
a deprecation warning inside python3-six ?



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-botocore depends on:
ii  python3   3.11.4-5+b1
ii  python3-dateutil  2.8.2-3
ii  python3-jmespath  1.0.1-1
ii  python3-requests  2.31.0+dfsg-1
ii  python3-urllib3   2.0.7-1

python3-botocore recommends no packages.

python3-botocore suggests no packages.

-- no debconf information

Bug#1060420: less: Fix build failure on GNU/Hurd

[Guillem Jover]

Source: less
Source-Version: 590-2
Severity: important
Tags: patch
Forwarded: https://github.com/gwsw/less/pull/469
X-Debbugs-Cc: debian-h...@lists.debian.org

Hi!

This package has been failing to build for a while on GNU/Hurd, due to
the assumption that PATH_MAX is defined on all systems, which is not
the case on GNU/Hurd as it tries to impose no arbitrary limits
gratuitously.

I've prepared a patch fixing this and submitted that upstream, and
adapted that for the current version in Debian, which I'm attaching.

Thanks,
Guillem
From d29a630e1a112613e20bff4917fee879951a6112 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 11 Jan 2024 02:18:07 +0100
Subject: [PATCH] Do not assume PATH_MAX is defined
Origin: vendor
Forwarded: https://github.com/gwsw/less/pull/469

On systems such as GNU/Hurd, PATH_MAX is not defined, because the system
intends to impose no arbitrary limits. In other systems though it might
be defined but to a very large value.

We can use realpath() with its POSIX.1-2008 semantics, where passing a
NULL argument will make it allocate the destination buffer, but not all
systems support these semantics yet.

For now, instead of complicating the code to cope with realpath()
limitations on some systems, we simply handle the case where PATH_MAX
is not defined, where realpath() should always support these semantics.
---
 filename.c |   15 +++
 1 file changed, 15 insertions(+)

--- a/filename.c
+++ b/filename.c
@@ -800,10 +800,25 @@ lrealpath(path)
 	char *path;
 {
 #if HAVE_REALPATH
+	/*
+	 * Not all systems support the POSIX.1-2008 realpath() behavior of
+	 * allocating when passing a NULL argument. And PATH_MAX is not
+	 * required to be defined, or might contain an exceedinly big value.
+	 * We assume that if it is not defined (such as on GNU/Hurd), then
+	 * realpath() accepts NULL.
+	 */
+#ifndef PATH_MAX
+		char *rpath;
+
+		rpath = realpath(path, NULL);
+		if (rpath != NULL)
+			return rpath;
+#else
 	char rpath[PATH_MAX];
 	if (realpath(path, rpath) != NULL)
 		return (save(rpath));
 #endif
+#endif
 	return (save(path));
 }
 

Bug#1006531:

[Daniel Black]

Thought my last comment was obvious, but here's it more explicitly:

requires https://github.com/MariaDB/server/pull/2893 as debian
explicit architectures aren't neede since dh_auto_configure handles
this.

If it works, upstream welcome.

Hurd string from uname -m, "SYSTEM processor: i686-AT386" in mariadb
output. And wiki reference https://en.wikipedia.org/wiki/Uname


diff --git a/cmake/build_configurations/mysql_release.cmake
b/cmake/build_configurations/mysql_release.cmake
index 961db1b13b0..e8431ca831f 100644
--- a/cmake/build_configurations/mysql_release.cmake
+++ b/cmake/build_configurations/mysql_release.cmake
@@ -118,7 +118,10 @@ ELSEIF(DEB)
   SET(WITH_ZLIB system CACHE STRING "")
   SET(WITH_LIBWRAP ON)
   SET(HAVE_EMBEDDED_PRIVILEGE_CONTROL ON)
-  SET(PLUGIN_AUTH_SOCKET YES CACHE STRING "")
+  # No hurd implementation
+  IF(NOT CMAKE_SYSTEM_PROCESSOR STREQUAL "i686-AT386")
+SET(PLUGIN_AUTH_SOCKET YES CACHE STRING "")
+  ENDIF()
   SET(WITH_EMBEDDED_SERVER ON CACHE BOOL "")
   SET(WITH_PCRE system CACHE STRING "")
   SET(CLIENT_PLUGIN_ZSTD OFF)

Bug#1060418: ser2net 4.6.0 now available

[John Goerzen]

Source: ser2net
Version: 4.3.11-1
Severity: wishlist

Dear Maintainer,

Hi,

ser2net 4.6.0 is now available at https://github.com/cminyard/ser2net/releases .
It contains some bugfixes for things I've worked with upstream on, so it would
be great to have it packaged.

Thanks!

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

Kernel: Linux 6.1.0-16-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (wintermute) (2024-01-10 23:54:30)
> I am giving mmdebstrap-autopkgtest-build-qemu a try.

thank you!

> The following command fails:
> 
>   $ mmdebstrap-autopkgtest-build-qemu --boot=efi sid sid_amd64.img
> 
> during some package installation with "no space left on device" error,
> since I have /tmp on a somewhat small physical partition:
> 
>   $ df --si /tmp/
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/md3868M   99k  806M   1% /tmp

yes, that looks too small.

> I tried with a TMPDIR in system memory:
> 
>   $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
> --boot=efi sid sid_amd64.img
> 
> but it again fails with the following (final chunk of) output:
> 
>   [...]
>   cp: warning: behavior of -n is non-portable and may change in future; use 
> --update=none instead
>   I: running special hook: download vmlinuz '/dev/shm/tmp.uNRUbVgiOu/kernel'
>   I: running special hook: download initrd.img 
> '/dev/shm/tmp.uNRUbVgiOu/initrd'
>   I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' 
> exec /dev/shm/mmdebstrap.IXehDNUWIf
>   I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" 
> "$1/mnt/dev"' exec /dev/shm/mmdebstrap.IXehDNUWIf
>   I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L 
> autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 
> 'sid_amd64.img' '25G'' exec /dev/shm/mmdebstrap.IXehDNUWIf
>   mke2fs 1.47.0 (5-Feb-2023)
>   mkfs.ext4: Permission denied while trying to determine filesystem size
>   E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
> autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 
> 'sid_amd64.img' '25G'
>   W: hooklistener errored out: E: received eof on socket
>   
>   I: main() received signal PIPE: waiting for setup...
>   I: removing tempdir /dev/shm/mmdebstrap.IXehDNUWIf...
>   E: mmdebstrap failed to run
>   mmdebstrap failed
> 
> Does it fail because I do not have enough system memory?
> 
>   $ df --si /dev/shm/
>   Filesystem  Size  Used Avail Use% Mounted on
>   tmpfs   8.3G  108M  8.2G   2% /dev/shm
> 
> Is this the explanation?
> Otherwise, what went wrong?

Interesting! I'm unable to reproduce either of these issues and I'm also
puzzled why you get this "permission denied" error. On my system, I'm able run
your command with the default (in /tmp) as well as in /dev/shm. Here is the
free space each:

$ df --si /tmp /dev/shm
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   8.6G  4.1k  8.6G   1% /tmp
tmpfs   2.0G  418k  2.0G   1% /dev/shm

Maybe something is mounted in a funny way? Both my /tmp and my /dev/shm are
tmpfs. The former is mounted with
rw,nosuid,nodev,relatime,size=8388608k,inode64 and the latter with
rw,nosuid,nodev,inode64.

I doubt that it fails for lack of system memory unless you have less than 3.7
GB of RAM.

Maybe permissions are somehow whacky? Both my /tmp and my /dev/shm are set to
drwxrwxrwt (so there is a sticky bit set) and owned by root:root.

What happens with other locations for TMPDIR?

> By the way, the old script that used guestfish (with all its limitations)
> was able to create a QEMU image in .qcow2 format and my /dev/shm was
> enough for it to work correctly.

It should be enough. Your /dev/shm is 8G large and it works with my 2G.

> Why does the current mmdebstrap-autopkgtest-build-qemu create a QEMU
> image in .img format? Isn't the .qcow2 format better?

Maybe. It's currently .img because it's easier to debug stuff and use kpartx
with it without having to extract it first. :)

> Please clarify and/or improve mmdebstrap-autopkgtest-build-qemu .
> Thanks for your time!

Thanks for your bug! Lets hope we get to the bottom of this.

cheers, josch

signature.asc
Description: signature

Bug#1060386: fail2ban: Fail2ban Debian 12 fails to start

[Luca Capello]

tags 1060386 + moreinfo
thanks

Hi there,

On Wed, 10 Jan 2024 14:06:47 +, Guido van Brakel wrote:
> Version: 1.0.2-2
> Severity: important
> Dear Maintainer,
> 
>* What led up to the situation? Installing fail2ban on Debian 12
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action? Fail2ban fails to start
>* What outcome did you expect instead? Fail2ban just starting without 
> needing to

You should provide some more information, like the error message when
you manually launch `/usr/bin/fail2ban-server -vvv -x start`.

> 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  python3-pyinotify  0.9.6-2
> ii  python3-systemd235-1+b2
> ii  whois  5.5.17
> Versions of packages fail2ban suggests:
> Versions of packages fail2ban suggests:
> pn  mailx  
> pn  monit  
> pn  sqlite3
> pn  system-log-daemon  
> -- Configuration Files:
> /etc/fail2ban/jail.conf changed:
> [INCLUDES]
> before = paths-debian.conf
> [DEFAULT]
> ignorecommand =
> bantime  = 10m
> findtime  = 10m
> maxretry = 5
> maxmatches = %(maxretry)s
> backend = systemd

Please note that on a default Debian 12.4/bookworm you simply need to
add some lines to `jail.local`, without touching anything else:
```
[DEFAULT]
### 
banaction = nftables
banaction_allports = nftables[type=allports]
### 
backend = systemd
```

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#862348: fail2ban: fails to filter systemd ssh daemon entries from journal

[Luca Capello]

Hi there,

On Fri, 11 Aug 2023 01:08:37 +0100, Andrei Coada wrote:
> This is getting pretty annoying, especially now that Debian 12 does not
> even have a syslog service installed by default.
> Fail2ban fails to start right after its installation.
> 
> The solution is really trivial. At least an SSHD override should be added
> in  "paths-debian.conf"  file, such as:
> 
> sshd_backend = systemd
> 
> so that the fail2ban service can start after one installs it.

Andrei, please read again the submitter report, he explicitely shows
that `fail2ban` reads `/var/log/auth.log`, thus I guess the problem is
not `systemd`-related (he also has `rsyslog` installed, thus
`/var/log/auth.log` *is* present).

NB, the `systemd` issue on a default Debian 12/bookworm has been fixed
one week ago already and it is easily applied to `jail.local`:

  

Alban, 0.9.6-2 is quite an old version and you reported the bug more
than 5 years, can you try on a more up-to-date Debian?

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Francesco Poli]

On Tue, 09 Jan 2024 11:41:09 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> So... mmdebstrap-autopkgtest-build-qemu might be what you want *if* you 
> don't care about ppc64el or mips. The latter was (I think) never 
> supported my autopkgtest-qemu because there is no good option for a 
> bootloader. In case of ppc64el, there is ieee1275 booting but that is 
> not supported by mmdebstrap-autopkgtest-build-qemu.

Well, ppc64el or mips would be nice, but not a must.

I hope mips will be supported autopkgtest-qemu in the future.

As far as ppc64el is concerned, I hope a good solution for booting with
mmdebstrap-autopkgtest-build-qemu can be found, but first I would like
to see mmdebstrap-autopkgtest-build-qemu work correctly for the
supported architectures...

> 
> Could you give mmdebstrap-autopkgtest-build-qemu a try and see if it 
> does what you want? I'm preparing another mmdebstrap release and if you 
> find any issues with that script I can incorporate fixes in the next 
> release.

I have just filed bug report [#1060416].
Thanks for being willing to improve the script!

[#1060416]: 


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


pgpyQ_zHw_dqA.pgp
Description: PGP signature

Bug#770171: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#770171: fixed in fail2ban 1.0.2-3)

[Luca Capello]

found 770171 1.0.2-2
tags 770171 + upstream
forwarded 770171 https://github.com/fail2ban/fail2ban/issues/1372
user l...@pca.it
usertags 770171 + pca.it-security
thanks

Hi there,

I just got hit by this as well, plus the nftables issue:

  

On Tue, 02 Jan 2024 19:39:13 +, Debian Bug Tracking System wrote:
> Changes:
>  fail2ban (1.0.2-3) unstable; urgency=medium
>  .
>* Add banaction = nftables in the defaults-debian.conf default
>  see 
> https://github.com/fail2ban/fail2ban/discussions/3575#discussioncomment-7045315
>* Move python3-systemd as depend (Closes: #770171, #1037437)
>* Add backend = systemd to jail.d/defaults-debian.conf

The commit corresponding to the last line is:

  


For those waiting the fixed pacakge, without touching any other
packaged file I can confirm that `apt-get install python3-systemd`
plus the below `jail.local` are enough to get `fail2ban` starts on a
fresh Debian 12.4/bookworm:
```
[DEFAULT]
### 
banaction = nftables
banaction_allports = nftables[type=allports]
### 
backend = systemd
```

Thx, bye,
Gismo / Luca

PS, the upstream bug is quite interesting, especially to understand the
differences between `(|*_)backend`:

  


signature.asc
Description: PGP signature

Bug#1060417: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u3

[Hilmar Preusse]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: proftpd-d...@packages.debian.org
Control: affects -1 + src:proftpd-dfsg

[Reason]
The version currently in Debian stable suffers from two
different security issues:
- CVE-2023-48795 (Terrapin attack)
- CVE-2023-51713 one-byte out-of-bounds read, and daemon
  crash, because of mishandling of quote/backslash semantics

[ Impact ]
Proftp further suffers from the described security issues.

[ Tests ]
The upstream source package provides a test suite, which
is still running fine after applying the patch.

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

[ Changes ]
- Patch for CVE-2023-48795 (copied from upstream's repo)
- Patch for CVE-2023-51713 (copied from upstream's repo)

-- 
sigmentation fault


proftpd-dfsg_1.3.8+dfsg-4+deb12u3.debdiff.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.0-1
Severity: normal

Hello,
I am giving mmdebstrap-autopkgtest-build-qemu a try.

The following command fails:

  $ mmdebstrap-autopkgtest-build-qemu --boot=efi sid sid_amd64.img

during some package installation with "no space left on device" error,
since I have /tmp on a somewhat small physical partition:

  $ df --si /tmp/
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/md3868M   99k  806M   1% /tmp

I tried with a TMPDIR in system memory:

  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--boot=efi sid sid_amd64.img

but it again fails with the following (final chunk of) output:

  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.uNRUbVgiOu/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.uNRUbVgiOu/initrd'
  I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' exec 
/dev/shm/mmdebstrap.IXehDNUWIf
  I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" 
"$1/mnt/dev"' exec /dev/shm/mmdebstrap.IXehDNUWIf
  I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'' exec /dev/shm/mmdebstrap.IXehDNUWIf
  mke2fs 1.47.0 (5-Feb-2023)
  mkfs.ext4: Permission denied while trying to determine filesystem size
  E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'
  W: hooklistener errored out: E: received eof on socket
  
  I: main() received signal PIPE: waiting for setup...
  I: removing tempdir /dev/shm/mmdebstrap.IXehDNUWIf...
  E: mmdebstrap failed to run
  mmdebstrap failed

Does it fail because I do not have enough system memory?

  $ df --si /dev/shm/
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   8.3G  108M  8.2G   2% /dev/shm

Is this the explanation?
Otherwise, what went wrong?

By the way, the old script that used guestfish (with all its limitations)
was able to create a QEMU image in .qcow2 format and my /dev/shm was
enough for it to work correctly.
Why does the current mmdebstrap-autopkgtest-build-qemu create a QEMU
image in .img format? Isn't the .qcow2 format better?

Please clarify and/or improve mmdebstrap-autopkgtest-build-qemu .
Thanks for your time!


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
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 mmdebstrap depends on:
ii  apt  2.7.6
ii  perl 5.36.0-10+b1
ii  python3  3.11.4-5+b1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.32.2-1+b1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-2
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.6
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.36.0-10
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-3

-- no debconf information

Bug#1060217: plocate command blocks waiting io_uring operation

[Manolis Stamatogiannakis]

On Tue, 9 Jan 2024 at 19:39, Steinar H. Gunderson  wrote:

> On Tue, Jan 09, 2024 at 07:34:56PM +0100, Manolis Stamatogiannakis wrote:
> > I also gave it a shot reproducing on a RPi Zero 2, but it's either too
> fast
> > (even with cpulimit), or the issue is architecture-specific and does not
> > manifest on ARMv7.
>
> Can I claim “this is obviously a kernel bug” and pass the buck? :-)
>

Let's cc Linus then. :-D


>
> I mean, if you would be willing to give out access on your machine,
> I could SSH in and debug there, but obviously this is a pretty narrow
> case no matter what the actual issue is.
>

I wish that was straightforward, but this is a NAS box (lots of personal
files) and the OS shares the same disks with the storage array. So it is
not easy to sanitize it well enough for sharing access. Plus, it's
dog-slow, so I'm not sure you would enjoy the process ;-) : It takes around
36sec to recompile a single file and relink the binary with ninja.

But I take this as a good opportunity to learn a bit about io_uring, so
I'll give it a shot myself. From my first experiments, it appears that the
code is deadlocking somewhere in IOUringEngine::finish(). And it looks like
a timing-related bug, as adding a couple of dprintfs and running with
--debug is enough to get things rolling. I'll probably continue debugging
on Friday.

I have temporarily cloned the repo on GH [1] if you have time to check it
out. I'm not sure if this is the right place for discussing code, so maybe
we should switch to GH comments or private emails until there's some
outcome (?).

Best regards,
Manolis

[1] https://github.com/m000/plocate/pull/1

Bug#1060389: systemd: logind: HandlePowerKeyLongPress doesn't appear to work

[Michael Biebl]

Am 10.01.24 um 16:10 schrieb наб:

On Wed, Jan 10, 2024 at 03:40:27PM +0100, Michael Biebl wrote:

Am 10.01.24 um 15:26 schrieb наб:

As you can see in my logind.conf,
I have re-mapped the power key to suspend,
and long-pressing the power key to hibernate.

When I click the power key the machine suspends instantly
(and under X I see XF86PowerOff).
But this actually happens no matter how long I hold the button for,
and hibernation never occurs.

Maybe your desktop environment intercepts/interprets those keys?

It doesn't:
   $ grep XF86 .config/i3/config
   bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 
@DEFAULT_SINK@ +10% && $refresh_i3status
   bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 
@DEFAULT_SINK@ -10% && $refresh_i3status
   bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute @DEFAULT_SINK@ toggle 
&& $refresh_i3status
   bindsym XF86AudioMicMute exec --no-startup-id pactl set-source-mute @DEFAULT_SOURCE@ 
toggle && $refresh_i3status

And, well, the xev seeing them means i3 didn't eat them.


Can you confirm the issue when being logged into the kernel console only
(i.e. no desktop environment running)?

I guess I forgot to note this explicitly:
yes this happens both under X and at a getty.

Best,


I'd say you best raise this upstream then at
https://github.com/systemd/systemd/issues

we do not ship any downstream patches in that regard.

Please report back with the upstream issue number so we can mark it 
accordingly.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060405: Segmentation fault on opening .deb files

[Sergio Vavassori]

Il giorno mer 10 gen 2024 alle ore 21:54 Mike Gabriel
 ha scritto:
>
> Hi Sergio,
>
> > [...]
>
> The fix is on its way to unstable, is the change only required in
> Debian unstable, or is a stable upload to bookworm also required?

Hello Mike,

Thanks for the quick response.

I just tested with a VM and Debian Stable is working properly since
dpkg-deb has spaces in its output as shown in:
https://github.com/mate-desktop/engrampa/issues/496#issuecomment-1720468487

Regards,
Sergio

Bug#1049452: fail2ban should use nftables by default.

[Luca Capello]

fixed 1049452 1.0.2-3
user l...@pca.it
Usertags 1049452 + pca.it-security
thanks

Hi there,

On Wed, 16 Aug 2023 09:50:30 +1000, Peter Chubb wrote:
>   iptables is deprecated; fail2ban can use nft instead.
>   Please make nftables the default banning method in 
>   /etc/fail2ban/jail.conf, and consider changing the Recommends: 
>   to a Depends: for nftables.

I just got hit by this as well (plus the systemd backend issue) and
after some research I found out that Sylvestre Ledru released a fixed
package one week ago already, albeit IMHO this needs a
stable-backports or, better, a stable-proposed-updates (thus not
closing this bug):

  
   


Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Bug#1060272: libsysfs2: ""trying to overwrite shared changelog.Debian.gz', which is different"

[Guillem Jover]

Hi!

On Mon, 2024-01-08 at 15:45:41 +0100, Sven-Haegar Koch wrote:
> Package: libsysfs2
> Version: 2.1.1-5+b1
> Severity: normal

> Trying to upgrade libsysfs2 from 2.1.1-5 to 2.1.1-5+b1 seems to have
> problems with Multi-Arch installs:
> 
> Preparing to unpack .../117-libsysfs2_2.1.1-5+b1_amd64.deb ...
> De-configuring libsysfs2:i386 (2.1.1-5), to allow configuration of 
> libsysfs2:amd64 (2.1.1-5+b1) ...
> Unpacking libsysfs2:amd64 (2.1.1-5+b1) over (2.1.1-5) ...
> Preparing to unpack .../118-libsysfs2_2.1.1-5+b1_i386.deb ...
> Unpacking libsysfs2:i386 (2.1.1-5+b1) over (2.1.1-5) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-9SDLmy/118-libsysfs2_2.1.1-5+b1_i386.deb (--unpack):
>  trying to overwrite shared '/usr/share/doc/libsysfs2/changelog.Debian.gz', 
> which is different from other instances of package libsysfs2:i386
> Preparing to unpack .../119-sysfsutils_2.1.1-5+b1_amd64.deb ...
> Unpacking sysfsutils (2.1.1-5+b1) over (2.1.1-5) ...
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-9SDLmy/118-libsysfs2_2.1.1-5+b1_i386.deb
> 
> Perhaps the binary only rebuild needs to be replaced with a new source
> upload only updating changelog.

This would be due to #1059395. I'll probably try to upload a new
sysfsutils revision as a temporary workaround for that.

Thanks,
Guillem

Bug#1059780: packages.debian.org: All links under https://packages.debian.org/*/all/ will 404

[Boyuan Yang]

Hi,

On Sun, 31 Dec 2023 20:14:00 -0500 Boyuan Yang  wrote:
> Package: www.debian.org
> Severity: important
> 
> Visiting https://packages.debian.org/sid/all/ , all package you click (such as
> https://packages.debian.org/sid/all/admin/ and then
> https://packages.debian.org/sid/all/admin/0install will return 404).
> 
> The same applies when replacing "sid" with other codenames.
> 
> The original report is 
> https://lists.debian.org/debian-www/2023/12/msg00069.html .

The update from user report at 
https://lists.debian.org/debian-www/2024/01/msg5.html
indicates that the actual problem is 
https://packages.debian.org/bookworm/all/*/ page
listing binary packages that exist in other architectures (e.g., arm64) 
regardless of
whether its arch:all counterpart exist or not. These pages should be revised to 
exclude
those binary packages that are not of arch:all.

Could any Debian web team members take a look and let me know how to fix bugs of
packages.debian.org and get the bugfix deployed? My merge requests on Salsa
salsa.debian.org/webmaster-team/packages never received any reply or comment.

Thanks,
Boyuan Yang


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

Bug#1060415: freeipa: CVE-2023-5455

[Salvatore Bonaccorso]

Source: freeipa
Version: 4.10.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.9.11-1

Hi,

The following vulnerability was published for freeipa.

CVE-2023-5455[0]:
| A Cross-site request forgery vulnerability exists in
| ipa/session/login_password in all supported versions of IPA. This
| flaw allows an attacker to trick the user into submitting a request
| that could perform actions as the user, resulting in a loss of
| confidentiality and system integrity. During community penetration
| testing it was found that for certain HTTP end-points FreeIPA does
| not ensure CSRF protection. Due to implementation details one cannot
| use this flaw for reflection of a cookie representing already
| logged-in user. An attacker would always have to go through a new
| authentication attempt.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5455
https://www.cve.org/CVERecord?id=CVE-2023-5455
[1] https://www.freeipa.org/release-notes/4-10-3.html#highlights-in-4-10-3
https://pagure.io/freeipa/c/363fd5de98e883800ac08b2760e8c3150783e7e2
[2] https://www.freeipa.org/release-notes/4-9-14.html#highlights-in-4-9-14
https://pagure.io/freeipa/c/9b1a65fe3936c4d3fe237775e54f0249b740f23e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #872381

Hello.
The attached commits rebase the suggestions, take your answers into
account and slightly improved some style issues.
There may remain typos, nothing is tested this time.
>From d56d5af7fa1a01a581d0cc1901572ca9c407f538 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 29 Jul 2019 14:38:32 +0200
Subject: [PATCH 1/8] scripts/mk: stop hard-coding dpkg_datadir, protect from
 double inclusion

The Makefile snippets include each other from their common directory,
but the path differ during tests and after installation.  Instead of
rewriting the file with a hardcoded path, compute it within Make.

Use the same variables to avoid 'include' when possible, as it
involves system calls.

When setting dpkg_datadir, prefer 'ifndef' and ':=' to '?=', so that
the value is computed at most once.
---
 build-aux/subst.am |  6 --
 scripts/mk/Makefile.am | 21 -
 scripts/mk/architecture.mk |  5 +
 scripts/mk/buildapi.mk |  5 +
 scripts/mk/buildflags.mk   |  6 ++
 scripts/mk/buildopts.mk|  5 +
 scripts/mk/buildtools.mk   | 11 ++-
 scripts/mk/default.mk  | 10 +-
 scripts/mk/pkg-info.mk |  5 +
 scripts/mk/vendor.mk   | 11 ++-
 10 files changed, 55 insertions(+), 30 deletions(-)

diff --git a/build-aux/subst.am b/build-aux/subst.am
index 5515930d0..167a71257 100644
--- a/build-aux/subst.am
+++ b/build-aux/subst.am
@@ -39,9 +39,3 @@ SUFFIXES += .pl
 	@test -d `dirname $@` || $(MKDIR_P) `dirname $@`
 	$(do_perl_subst) <$< >$@
 	$(AM_V_at) chmod +x $@
-
-# Makefile support.
-
-do_make_subst = $(AM_V_GEN) $(SED) \
-	-e "s:dpkg_datadir[[:space:]]*=[[:space:]]*[^[:space:]]*:dpkg_datadir = $(pkgdatadir):" \
-	# EOL
diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index 257ba5252..6e85e17b9 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -10,24 +10,3 @@ dist_pkgdata_DATA = \
 	pkg-info.mk \
 	vendor.mk \
 	# EOL
-
-SUFFIXES =
-
-include $(top_srcdir)/build-aux/subst.am
-
-# Ideally we'd use '$(SED) -i', but unfortunately that's not portable.
-install-data-hook:
-	$(do_make_subst) <$(DESTDIR)$(pkgdatadir)/default.mk \
-	 >$(DESTDIR)$(pkgdatadir)/default.mk.new
-	mv $(DESTDIR)$(pkgdatadir)/default.mk.new \
-	   $(DESTDIR)$(pkgdatadir)/default.mk
-
-	$(do_make_subst) <$(DESTDIR)$(pkgdatadir)/buildtools.mk \
-	 >$(DESTDIR)$(pkgdatadir)/buildtools.mk.new
-	mv $(DESTDIR)$(pkgdatadir)/buildtools.mk.new \
-	   $(DESTDIR)$(pkgdatadir)/buildtools.mk
-
-	$(do_make_subst) <$(DESTDIR)$(pkgdatadir)/vendor.mk \
-			 >$(DESTDIR)$(pkgdatadir)/vendor.mk.new
-	mv $(DESTDIR)$(pkgdatadir)/vendor.mk.new \
-	   $(DESTDIR)$(pkgdatadir)/vendor.mk
diff --git a/scripts/mk/architecture.mk b/scripts/mk/architecture.mk
index c11cada16..2ffcee287 100644
--- a/scripts/mk/architecture.mk
+++ b/scripts/mk/architecture.mk
@@ -2,6 +2,9 @@
 # DEB_BUILD_* variables that dpkg-architecture can return. Existing values
 # of those variables are preserved as per policy.
 
+ifndef dpkg_architecture.mk_included
+dpkg_architecture.mk_included :=
+
 dpkg_lazy_eval ?= $$(or $$(value DPKG_CACHE_$(1)),$$(eval DPKG_CACHE_$(1) := $$(shell $(2)))$$(value DPKG_CACHE_$(1)))
 
 dpkg_architecture_setvar = export $(1) ?= $(call dpkg_lazy_eval,$(1),dpkg-architecture -q$(1))
@@ -9,3 +12,5 @@ dpkg_architecture_setvar = export $(1) ?= $(call dpkg_lazy_eval,$(1),dpkg-archit
 $(foreach machine,BUILD HOST TARGET,\
   $(foreach var,ARCH ARCH_ABI ARCH_LIBC ARCH_OS ARCH_CPU ARCH_BITS ARCH_ENDIAN GNU_CPU GNU_SYSTEM GNU_TYPE MULTIARCH,\
 $(eval $(call dpkg_architecture_setvar,DEB_$(machine)_$(var)
+
+endif
diff --git a/scripts/mk/buildapi.mk b/scripts/mk/buildapi.mk
index 668e325c8..ba6b43543 100644
--- a/scripts/mk/buildapi.mk
+++ b/scripts/mk/buildapi.mk
@@ -1,5 +1,8 @@
 # This Makefile fragment (since dpkg 1.22.0) handles the build API.
 
+ifndef dpkg_buildapi.mk_included
+dpkg_buildapi.mk_included :=
+
 # Default API level when not set.
 DPKG_BUILD_API ?= $(shell dpkg-buildapi)
 
@@ -7,3 +10,5 @@ DPKG_BUILD_API ?= $(shell dpkg-buildapi)
 # complexity given no integer operators, given that we currently have to
 # fetch the build API level anyway.
 dpkg_build_api_ge = $(shell test "$(DPKG_BUILD_API)" -ge "$(1)" && echo yes)
+
+endif
diff --git a/scripts/mk/buildflags.mk b/scripts/mk/buildflags.mk
index 4b8a3d8c4..02baa53f2 100644
--- a/scripts/mk/buildflags.mk
+++ b/scripts/mk/buildflags.mk
@@ -28,6 +28,10 @@
 # You can also export them in the environment by setting
 # DPKG_EXPORT_BUILDFLAGS to a non-empty value.
 #
+
+ifndef dpkg_buildflags.mk_included
+dpkg_buildflags.mk_included :=
+
 # This list is kept in sync with the default set of flags returned
 # by dpkg-buildflags.
 
@@ -77,3 +81,5 @@ $(foreach flag,$(DPKG_BUILDFLAGS_LIST),\
 ifdef DPKG_EXPORT_BUILDFLAGS
   export $(DPKG_BUILDFLAGS_LIST)
 endif
+
+endif
diff --git a/scripts/mk/buildopts.mk b/scripts/mk/buildopts.mk

Bug#1037551: gnome-control-center: Google account stop working. Not able to re configure it.

[sergio]

Jeremy good day,

it was fixed some months ago.

Regards.
.

El mié, 10 de ene de 2024 a las 14:54:11 PM, Jeremy Bícha 
 escribió:

Control: tags -1 moreinfo

On Tue, Jun 13, 2023 at 11:09 PM zezamoral > wrote:

 Google calendar info and files access stop working.

* What exactly did you do (or not do) that was effective (or
  ineffective)?
 Simply account stop working some days ago and data not 
available.


* What was the outcome of this action?
 Stop working. Trying to re configuring account not working 
due the

 window freeze after entering your email address and press next.

* What outcome did you expect instead?
 Getting calendar data and files access from nautilus or 
able to re
 settings the online account without the web frame freeze when login 
the account

 in gnome control center.


There have been many fixes released for Debian 12 since this bug was
reported. Please confirm whether you are still experiencing this
issue.

Thank you,
Jeremy Bícha

Bug#1060387: libc6:amd64 (2.37-13) upgrade stuck at Setting up on WSL 2

[Aurelien Jarno]

control: reassign -1 libc6
control: tags -1 + help

Hi,

On 2024-01-10 14:11, Dunkerley, Adam D. wrote:
> Package: libc6-amd64
> Version: 2.37-13
> 
> While running `sudo apt upgrade`, the process hangs while installing 
> libc6:amd64. The last line output is "Setting up libc6:amd64 (2.37-13) ...".
> 
> The dpkg logs show "status half-configured libc6:amd64 2.37-13".
> 
> I left this process running overnight to no avail. This prevents me from 
> being able to update my system.
> 
> Here is a Stack Overflow post regarding this issue: debian - Apt stucked in 
> setting up libc6 - Stack 
> Overflow
> 
> I am using Debian GNU/Linux trixie/sid, kernel 
> 5.15.133.1-microsoft-standard-WSL2 on Windows 11 x86_64.

We also got another report that telinit got stuck, it wasn't the case
before, I guess something has changed on the WSL side. Someone with
knowledge about that system should debug the issue and provide a patch.
Therefore tagging the bug with help.

Regards
Aurelien

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

Bug#1060414: src:libextractor: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: libextractor
Version: 1:1.11-8
Severity: serious
Control: close -1 1:1.13-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060405: Segmentation fault on opening .deb files

[Mike Gabriel]

Hi Sergio,

On  Mi 10 Jan 2024 20:01:16 CET, Sergio Vavassori wrote:


Package: engrampa
Version: 1.26.1-1
Severity: important


Dear Maintainer,

Since mid December 2023 engrampa (on Debian testing) has been crashing with
segmentation fault when opening any .deb files.
By looking with GDB it seems the error is thrown here (
https://github.com/mate-desktop/engrampa/blob/1.26/src/fr-command-dpkg.c#L76
). After some searches I found that the same bug was already reported to
upstream ( https://github.com/mate-desktop/engrampa/issues/496 ) and it has
been fixed since October 2023; however upstream hasn't released a new
version yet (as of today, last is 1.27.1 from Aug 22, 2023).

Taking in account that this is the patch to fix the bug (
https://github.com/mate-desktop/engrampa/commit/bdafd0c2db93e85ed0e7b19fd502e254e5b587ea
) and it is compatible with 1.26.1 code (
https://github.com/mate-desktop/engrampa/blob/1.26/src/glib-utils.c#L422-L425
), would you consider to add it to the package's patch set and release as
1.26.1-2?

$ cat /etc/issue
Debian GNU/Linux trixie/sid \n \l
$ uname -a
Linux debian-zooplus 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1
(2023-11-29) x86_64 GNU/Linux

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex
'thread apply all bt full' --args engrampa grep_3.11-3_amd64.deb >
engrampa.log
76 ./src/fr-command-dpkg.c: File o directory non esistente

engrampa.log
-
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7592e6c0 (LWP 28785)]
[New Thread 0x7fffed12d6c0 (LWP 28786)]
[New Thread 0x7512d6c0 (LWP 28787)]
[New Thread 0x748966c0 (LWP 28788)]
[New Thread 0x7fffeebff6c0 (LWP 28789)]
[Thread 0x7fffeebff6c0 (LWP 28789) exited]
[New Thread 0x7fffeebff6c0 (LWP 28790)]
[New Thread 0x7fffee3fe6c0 (LWP 28791)]
[Thread 0x7fffeebff6c0 (LWP 28790) exited]
[Thread 0x7fffee3fe6c0 (LWP 28791) exited]
[New Thread 0x7fffee3fe6c0 (LWP 28792)]
[New Thread 0x7fffeebff6c0 (LWP 28793)]
[Thread 0x7fffee3fe6c0 (LWP 28792) exited]
[Thread 0x7fffeebff6c0 (LWP 28793) exited]
[New Thread 0x7fffeebff6c0 (LWP 28794)]
[New Thread 0x7fffee3fe6c0 (LWP 28795)]
[New Thread 0x7fffedbfd6c0 (LWP 28796)]
[Thread 0x7fffee3fe6c0 (LWP 28795) exited]
[New Thread 0x7fffee3fe6c0 (LWP 28797)]
[Thread 0x7fffedbfd6c0 (LWP 28796) exited]
[New Thread 0x7fffedbfd6c0 (LWP 28798)]
[Thread 0x7fffee3fe6c0 (LWP 28797) exited]
[Thread 0x7fffedbfd6c0 (LWP 28798) exited]
[Detaching after fork from child process 28799]

Thread 1 "engrampa" received signal SIGSEGV, Segmentation fault.
0x55581fbe in process_metadata_line (comm=0x55b20350,
line=0x55a89150 "1083 bytes,26 lines  control") at
./src/fr-command-dpkg.c:76
#0  0x55581fbe in process_metadata_line (comm=0x55b20350,
line=0x55a89150 "1083 bytes,26 lines  control") at
./src/fr-command-dpkg.c:76
#1  process_data_line (line=0x55a89150 "1083 bytes,26 lines
 control", data=0x55b20350) at ./src/fr-command-dpkg.c:110
#2  0x5558e12a in fr_channel_data_read
(channel=channel@entry=0x5576b160)
at ./src/fr-process.c:144
#3  0x5558fca8 in check_child (data=0x5576b140) at
./src/fr-process.c:857
#4  0x7715702e in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x771530d9 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x77156317 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x77156930 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x77388b7d in g_application_run () from
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#9  0x5556b45a in main (argc=, argv=)
at ./src/main.c:357
#0  0x55581fbe in process_metadata_line (comm=0x55b20350,
line=0x55a89150 "1083 bytes,26 lines  control") at
./src/fr-command-dpkg.c:76
fdata = 0x55ac9dd0
fields = 0x55b082a0
name = 
fdata = 
fields = 
name = 
__func__ = 
_g_boolean_var_10 = 
#1  process_data_line (line=0x55a89150 "1083 bytes,26 lines
 control", data=0x55b20350) at ./src/fr-command-dpkg.c:110
fdata = 
comm = 0x55b20350
fields = 
time_s = 
name = 
__func__ = "process_data_line"
#2  0x5558e12a in fr_channel_data_read
(channel=channel@entry=0x5576b160)
at ./src/fr-process.c:144
line = 0x55a89150 "1083 bytes,26 lines  control"
length = 41
terminator_pos = 40
#3  0x5558fca8 in check_child (data=0x5576b140) at
./src/fr-process.c:857
process = 
info = 0x55aa46a0
pid = 
status = 0
continue_process = 
channel_error = 
__FUNCTION__ = "check_child"
#4  0x7715702e in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol 

Bug#1060413: src:emacs-posframe: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: emacs-posframe
Version: 1.1.7-3
Severity: serious
Control: close -1 1.4.2-1
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060412: src:emacs-wgrep: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: emacs-wgrep
Version: 3.0.0-1
Severity: serious
Control: close -1 3.0.0-2
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:emacs-wgrep has been trying to migrate for 
33 days [2]. Hence, I am filing this bug. The version in unstable fails 
its own autopkgtest.


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=emacs-wgrep



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060411: initramfs: can't boot bcachefs storage with multi devices

[antonio]

Package: initramfs-tools
Version: 0.142
Severity: minor
X-Debbugs-Cc: antde...@gmail.com

Dear Maintainer,
I report a problem encountered with initramfs, relating to the new bcachefs
file system.

To test it, I installed a debian/bookwork server, with kernel 6.7 vannilla
recompiled locally and prepared a storage with bcachefs (1 ssd cache + 2 hdd
for replicas):

disk1/ssd: /dev/sda -> /dev/sda1 for esp (LABEL=NEWEFI)
   /dev/sda2 for cache bcachefs
(PARTUUID=ea702a10-728b-41d3-a80f-71cbf705dc28)
disk2/hdd: /dev/sdb -> /dev/sdb1 for storage bcachefs
(PARTUUID=679d2cdd-4dca-4707-83a8-0a86c095b345)
disk2/hdd: /dev/sdc -> /dev/sdc1 for storage bcachefs
(PARTUUID=09d070a2-449d-4c31-b214-cb225a0cbbaa)


I formatted it with command:

bcachefs format -LVMTEST --label=ssd.ssd1 /dev/sdb2 --label=hdd.hdd1 /dev/sdc1
--label=hdd.hdd2 /dev/sdd1 --replicas=2 --foreground_target=ssd
--promote_target=ssd --background_target=hdd


and mounted the root in the "/etc/fstab" file by adding the entries (indicating
"partuuid" of each device):

/dev/disk/by-partuuid/ea702a10-728b-41d3-a80f-71cbf705dc28:/dev/disk/by-
partuuid/679d2cdd-4dca-4707-83a8-0a86c095b345:/dev/disk/by-
partuuid/09d070a2-449d-4c31-b214-cb225a0cbbaa /  bcachefs  defaults,noatime   0
0

LABEL=NEWEFI  /boot/efi  vfatdefaults,noatime   0
0


using systemd loader with this entry:

title NEWTEST
linux /EFI/Linux/vmlinuz
options root=/dev/disk/by-
partuuid/ea702a10-728b-41d3-a80f-71cbf705dc28:/dev/disk/by-
partuuid/679d2cdd-4dca-4707-83a8-0a86c095b345:/dev/disk/by-
partuuid/09d070a2-449d-4c31-b214-cb225a0cbbaa rootfstype=bcachefs quiet
nosplash vga=791 noresume
initrd /EFI/Linux/initrd.img


This didn't work.


The problem is in the file "/usr/share/initramfs-tools/scripts/functions" and
depends on the "get_fstype" and "resolve_device" functions that cannot locate
or determine the file system (since bcachefs uses the form
device:device:device).


I managed to get it working by modifying these functions (see below)


Of course this is only a test, I just wanted to let you know about the issues
I've encountered.


Thanks,
Antonio


 SIMPLE PATCH:

--- /usr/share/initramfs-tools/scripts/functions2023-10-04
07:43:51.432542921 +0200
+++ /desktop/functions  2024-01-10 20:52:19.103154941 +0100
@@ -198,6 +198,12 @@
 # Return value: indicates if an fs could be recognized
 get_fstype ()
 {
+   if [ "$ROOTFSTYPE" == "bcachefs" ]; then
+   FSTYPE="$ROOTFSTYPE"
+   echo "$ROOTFSTYPE"
+   return 0
+   fi
+
local FS FSTYPE
FS="${1}"

@@ -429,12 +435,16 @@
 resolve_device() {
DEV="$1"

-   case "$DEV" in
-   LABEL=* | UUID=* | PARTLABEL=* | PARTUUID=*)
-   DEV="$(blkid -l -t "$DEV" -o device)" || return 1
-   ;;
-   esac
-   [ -e "$DEV" ] && echo "$DEV"
+   if [ "$ROOTFSTYPE" != "bcachefs" ]; then
+   case "$DEV" in
+   LABEL=* | UUID=* | PARTLABEL=* | PARTUUID=*)
+   DEV="$(blkid -l -t "$DEV" -o device)" || return 1
+   ;;
+   esac
+   [ -e "$DEV" ] && echo "$DEV"
+   else
+   echo "$DEV"
+   fi
 }

 # Check a file system.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 63M Jan  8 19:04 /boot/initrd.img-6.6.10-3-liquorix-amd64
-- /proc/cmdline
audit=0 intel_pstate=disable rcupdate.rcu_expedited=1  
initrd=\EFI\Linux\initrd.img root=LABEL=DEBIAN quiet nosplash vga=791 
resume=LABEL=SWAP postazione=sat selinux=0

-- /proc/filesystems
cramfs
ext3
ext2
ext4
xfs
btrfs
nilfs2
jfs
f2fs
fuseblk
vfat

-- lsmod
Module  Size  Used by
snd_seq_dummy  12288  0
snd_hrtimer12288  1
rfcomm 69632  18
cmac   12288  3
algif_hash 12288  1
algif_skcipher 12288  1
af_alg 32768  6 algif_hash,algif_skcipher
qrtr   53248  4
bnep   20480  2
sunrpc835584  1
nls_utf8   12288  1
nls_cp437  16384  1
vfat   20480  1
fat98304  1 vfat
snd_hda_codec_hdmi 86016  1
snd_hda_codec_realtek   200704  1
snd_hda_codec_generic   114688  1 snd_hda_codec_realtek
rc_total_media_in_hand_0212288  0
si2157 16384  1
si2168 16384  1
snd_sof_pci_intel_tgl12288  0
snd_sof_intel_hda_common   192512  1 snd_sof_pci_intel_tgl
snd_soc_hdac_hda   20480  1 snd_sof_intel_hda_common
soundwire_intel57344  1 snd_sof_intel_hda_common
snd_sof_intel_hda_mlink32768  2 soundwire_intel,snd_sof_intel_hda_common
soundwire_cadence  40960  1 soundwire_intel
snd_sof_intel_hda  16384  1 snd_sof_intel_hda_common
snd_sof_pci20480  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof_xtensa_dsp 12288  1 snd_sof_intel_hda_common
intel_rapl_msr 12288  0
snd_sof   315392  3 

Bug#1051280: Gnome Online Accounts not working properly

[Jeremy Bícha]

There have been improvements to Debian 12 since this bug was reported.
Are you still experiencing this issue?

Thank you,
Jeremy Bícha

Bug#994965: closed by Jeremy Bícha (Re: gnome-control-center: "Power Mode" options not displayed)

[Xavier Bestel]

Thanks !

Bug#1055163: gnome-control-center: Intel Management Engine disabled in BIOS but reporting out-of-date (active)

[Jeremy Bícha]

Control: reassign -1 fwupd

The data in the GNOME Settings > Device Security panel is provided by
fwupd so I'm reassigning this issue.

Thank you,
Jeremy Bícha

Bug#1060410: /etc/pacpl: Full sid upgrade removed packages dependent on perl-5.36.0-10

[Bartek]

Package: pacpl
Version: 6.1.3-1
Severity: important
File: /etc/pacpl
X-Debbugs-Cc: poem...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Full sid dist-upgrade.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Did not read attentively a warning that some packages will be removed like
pacpl and its dependencies.

   * What was the outcome of this action?
Removing pacpl because it depends on other packages which depend on
perlapi-5.36.0, technically perl-5.36.0

   * What outcome did you expect instead?
Bump dependency version to packages to perlapi-5.36.0


sudo apt install pacpl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libclone-perl : Depends: perlapi-5.36.0
 libhtml-parser-perl : Depends: perlapi-5.36.0
 libnet-ssleay-perl : Depends: perlapi-5.36.0
 libparams-classify-perl : Depends: libdevel-callchecker-perl but it is not
going to be installed
   Depends: perlapi-5.36.0
E: Unable to correct problems, you have held broken packages


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

Kernel: Linux 6.6.9-x64v2-xanmod1 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.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 pacpl depends on:
ii  libaudio-flac-header-perl 2.4-5+b1
ii  libaudio-scan-perl1.01-2+b2
ii  libcddb-get-perl  2.28-4
pn  libcddb-perl  
ii  libmp3-tag-perl   1.16-1
pn  libparallel-forkmanager-perl  
ii  libstring-shellquote-perl 1.04-3
ii  perl  5.38.2-2
ii  vorbis-tools  1.4.2-1+b1

Versions of packages pacpl recommends:
ii  cdparanoia3.10.2+debian-14+b1
ii  faad  2.11.1-1+b1
ii  ffmpeg10:6.1.1-dmo1
ii  flac  1.4.3+ds-2+b1
ii  lame  1:3.100-dmo2
ii  mplayer   4:1.5.0+svn38448-dmo1
pn  musepack-tools
ii  normalize-audio   0.7.7-17
ii  opus-tools0.2-1+b1
pn  sndfile-programs  
ii  sox   14.4.2+git20190427-4
ii  speex 1.2.1-2
ii  wavpack   5.6.0-1

Versions of packages pacpl suggests:
ii  faac 1:1.30-dmo1
ii  flake0.11-4
pn  twolame  

Bug#1037551: gnome-control-center: Google account stop working. Not able to re configure it.

[Jeremy Bícha]

Control: tags -1 moreinfo

On Tue, Jun 13, 2023 at 11:09 PM zezamoral  wrote:
> Google calendar info and files access stop working.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Simply account stop working some days ago and data not available.
>
>* What was the outcome of this action?
> Stop working. Trying to re configuring account not working due the
> window freeze after entering your email address and press next.
>
>* What outcome did you expect instead?
> Getting calendar data and files access from nautilus or able to re
> settings the online account without the web frame freeze when login the 
> account
> in gnome control center.

There have been many fixes released for Debian 12 since this bug was
reported. Please confirm whether you are still experiencing this
issue.

Thank you,
Jeremy Bícha

Bug#1060397: libsys-syscall-perl: FTBFS on riscv64: t/01-epoll.t failure

[Eric Wong]

Attached patch adds support for riscv64 and loongarch64

riscv64 tested on cfarm92.cfarm.net
I can't access loongarch64 machines on cfarm atm, but I tested
the epoll_* (but not sendfile+readahead) syscalls on another
machine a while ago.
>From 8d70578ff79b4754abaf456f71fe23a44b8335b4 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Wed, 10 Jan 2024 19:28:48 +
Subject: [PATCH] add loongarch64 and riscv64 support

riscv64 tested on cfarm92.cfarm.net

I can't access cfarm40[01] right now, but I tested the epoll_*
syscall numbers a while ago for another project (not readahead
nor sendfile).

Thanks to gcc compiler farm (cfarm.net) for ssh access.
---
 lib/Sys/Syscall.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Sys/Syscall.pm b/lib/Sys/Syscall.pm
index a0a9b20..92c1024 100644
--- a/lib/Sys/Syscall.pm
+++ b/lib/Sys/Syscall.pm
@@ -126,7 +126,7 @@ if ($^O eq "linux") {
 $SYS_epoll_wait   = 409;
 $SYS_readahead= 379;
 $u64_mod_8= 1;
-} elsif ($machine eq "aarch64") {
+} elsif ($machine =~ /\A(?:loong|a)arch64\z/ || $machine eq 'riscv64') {
 $SYS_epoll_create = 20;  # (sys_epoll_create1)
 $SYS_epoll_ctl= 21;
 $SYS_epoll_wait   = 22;  # (sys_epoll_pwait)

Bug#1060408: edk2: CVE-2022-36763 CVE-2022-36764 CVE-2022-36765

[Moritz Mühlenhoff]

Source: edk2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for edk2.

CVE-2022-36763[0]:
| EDK2 is susceptible to a vulnerability in the Tcg2MeasureGptTable()
| function, allowing a user to trigger a heap buffer overflow via a
| local network. Successful exploitation of this vulnerability may
| result in a compromise of confidentiality, integrity, and/or
| availability.

https://github.com/tianocore/edk2/security/advisories/GHSA-xvv8-66cq-prwr
https://bugzilla.tianocore.org/show_bug.cgi?id=4117

CVE-2022-36764[1]:
| EDK2 is susceptible to a vulnerability in the Tcg2MeasurePeImage()
| function, allowing a user to trigger a heap buffer overflow via a
| local network. Successful exploitation of this vulnerability may
| result in a compromise of confidentiality, integrity, and/or
| availability.

https://github.com/tianocore/edk2/security/advisories/GHSA-4hcq-p8q8-hj8j
https://bugzilla.tianocore.org/show_bug.cgi?id=4118

CVE-2022-36765[2]:
| EDK2 is susceptible to a vulnerability in the CreateHob() function,
| allowing a user to trigger a integer overflow to buffer overflow via
| a local network. Successful exploitation of this vulnerability may
| result in a compromise of confidentiality, integrity, and/or
| availability.

https://github.com/tianocore/edk2/security/advisories/GHSA-ch4w-v7m3-g8wx
https://bugzilla.tianocore.org/show_bug.cgi?id=4166


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-36763
https://www.cve.org/CVERecord?id=CVE-2022-36763
[1] https://security-tracker.debian.org/tracker/CVE-2022-36764
https://www.cve.org/CVERecord?id=CVE-2022-36764
[2] https://security-tracker.debian.org/tracker/CVE-2022-36765
https://www.cve.org/CVERecord?id=CVE-2022-36765

Please adjust the affected versions in the BTS as needed.

Bug#1060409: gpac: CVE-2024-0321 CVE-2024-0322

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for gpac.

CVE-2024-0321[0]:
| Stack-based Buffer Overflow in GitHub repository gpac/gpac prior to
| 2.3-DEV.

https://huntr.com/bounties/4c027b94-8e9c-4c31-a169-893b25047769/
https://github.com/gpac/gpac/commit/d0ced41651b279bb054eb6390751e2d4eb84819a

CVE-2024-0322[1]:
| Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.3-DEV.

https://huntr.com/bounties/87611fc9-ed7c-43e9-8e52-d83cd270bbec/
https://github.com/gpac/gpac/commit/092904b80edbc4dce315684a59cc3184c45c1b70


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-0321
https://www.cve.org/CVERecord?id=CVE-2024-0321
[1] https://security-tracker.debian.org/tracker/CVE-2024-0322
https://www.cve.org/CVERecord?id=CVE-2024-0322

Please adjust the affected versions in the BTS as needed.

Bug#1060407: Multiple security issues

[Moritz Muehlenhoff]

Source: gtkwave
Version: 3.3.116-1
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

A very thorough security audit of gtkwave unveiled a total of 82 security
issues in gtkwave, all fixed in 3.3.118:

CVE-2023-32650 CVE-2023-34087 CVE-2023-34436 CVE-2023-35004
CVE-2023-35057 CVE-2023-35128 CVE-2023-35702 CVE-2023-35703
CVE-2023-35704 CVE-2023-35955 CVE-2023-35956 CVE-2023-35957
CVE-2023-35958 CVE-2023-35959 CVE-2023-35960 CVE-2023-35961
CVE-2023-35962 CVE-2023-35963 CVE-2023-35964 CVE-2023-35969
CVE-2023-35970 CVE-2023-35989 CVE-2023-35992 CVE-2023-35994
CVE-2023-35995 CVE-2023-35996 CVE-2023-35997 CVE-2023-36746
CVE-2023-36747 CVE-2023-36861 CVE-2023-36864 CVE-2023-36915
CVE-2023-36916 CVE-2023-37282 CVE-2023-37416 CVE-2023-37417
CVE-2023-37418 CVE-2023-37419 CVE-2023-37420 CVE-2023-37442
CVE-2023-37443 CVE-2023-37444 CVE-2023-37445 CVE-2023-37446
CVE-2023-37447 CVE-2023-37573 CVE-2023-37574 CVE-2023-37575
CVE-2023-37576 CVE-2023-37577 CVE-2023-37578 CVE-2023-37921
CVE-2023-37922 CVE-2023-37923 CVE-2023-38583 CVE-2023-38618
CVE-2023-38619 CVE-2023-38620 CVE-2023-38621 CVE-2023-38622
CVE-2023-38623 CVE-2023-38648 CVE-2023-38649 CVE-2023-38650
CVE-2023-38651 CVE-2023-38652 CVE-2023-38653 CVE-2023-38657
CVE-2023-39234 CVE-2023-39235 CVE-2023-39270 CVE-2023-39271
CVE-2023-39272 CVE-2023-39273 CVE-2023-39274 CVE-2023-39275
CVE-2023-39316 CVE-2023-39317 CVE-2023-39413 CVE-2023-39414
CVE-2023-39443 CVE-2023-39444

Let's first fix unstable and then we can simple build 3.3.118
for stable-security and oldstable-security as well.

Full details in these advisories from TALOS:
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1777
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1783
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1785
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1786
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1789
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1790
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1791
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1792
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1793
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1797
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1798
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1803
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1804
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1805
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1806
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1807
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1810
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1811
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1812
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1813
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1814
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1815
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1816
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1817
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1818
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1819
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1820
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1821
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1822
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1823
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1824
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1826
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1827

Cheers,
Moritz

Bug#1060013: fixed in 2.7.0+dfsg-7

[Hans-Christoph Steiner]

Control: fixed -1 2.7.0+dfsg-7
Control: tags -1 fixed fixed-upstream security pending

This has been updated with key help from upstream:
https://github.com/iBotPeaches/Apktool/commit/087f89ebc0dd87e74c8945f074f25b51b195cb83

Bug#1060406: O: django-organizations -- Django groups and multi-user account management module

[Scott Kitterman]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:django-organizations

Orphaning the package on behalf of the Debian Python Team as the sole
uploader (no one else on the team expressed interest in taking over and
I no longer use the package).

Currently the package is in good shape.  There is a new upstream release
available, which I will probably include in the upload that changes the
maintainer to Debian QA Group.

Scott K

Bug#1041552: HFS/HFS+ are insecure

[rhys]

I think the idea that HFS+ is not used on removable device is a bit of a 
fallacy.  I, myself, use this frequently on removable hard drives when moving 
large data sets back and forth from my Mac.  The Mac doesn't easily read ext 
filesystems, but Linux can read HFS, and the various Microsoft filesystems lose 
too much metadata.

--J

> On Jan 10, 2024, at 12:39, Marco d'Itri  wrote:
> 
> On Jan 10, Michael Biebl  wrote:
> 
>> While we could ship such a udev rule for udisks, I don't think it will
>> properly solve the issue. The device will still show up in nautilus, plasma
>> etc and mounting is just an additional click away.
> The threat model here is: somebody connects a crafted USB stick to 
> a computer with a locked screen.
> 
> Also, the listed file systems are not used or not used anymore on 
> removable devices.
> Certainly not on removable devices used by regular users.
> 
> -- 
> ciao,
> Marco

Bug#1024683: Interest to participate

[Richard Liebig]

Hello! 
 
I would be willing to help out with packaging helix, seeing as it is really 
useful editor and I want to use in some debian systems on which cargo would not 
be a great route to install it.
 
Therefore I would like to offer my help with packaging some of its dependencies 
and maybe the main package as well. I would need some guidance on how to 
proceed, seeing as in the salsa there are a lot of dependencies still out 
necessary to be packaged.
 
Where could I start? Is there are any low-hanging fruit depency which could be 
a great target for me? 
 
I have registered an account with the Salsa gitlab and am waiting on approval 
for it.
 
Kind regards,
 
Richard

Bug#1060405: Segmentation fault on opening .deb files

[Sergio Vavassori]

Package: engrampa
Version: 1.26.1-1
Severity: important


Dear Maintainer,

Since mid December 2023 engrampa (on Debian testing) has been crashing with
segmentation fault when opening any .deb files.
By looking with GDB it seems the error is thrown here (
https://github.com/mate-desktop/engrampa/blob/1.26/src/fr-command-dpkg.c#L76
). After some searches I found that the same bug was already reported to
upstream ( https://github.com/mate-desktop/engrampa/issues/496 ) and it has
been fixed since October 2023; however upstream hasn't released a new
version yet (as of today, last is 1.27.1 from Aug 22, 2023).

Taking in account that this is the patch to fix the bug (
https://github.com/mate-desktop/engrampa/commit/bdafd0c2db93e85ed0e7b19fd502e254e5b587ea
) and it is compatible with 1.26.1 code (
https://github.com/mate-desktop/engrampa/blob/1.26/src/glib-utils.c#L422-L425
), would you consider to add it to the package's patch set and release as
1.26.1-2?

$ cat /etc/issue
Debian GNU/Linux trixie/sid \n \l
$ uname -a
Linux debian-zooplus 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1
(2023-11-29) x86_64 GNU/Linux

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex
'thread apply all bt full' --args engrampa grep_3.11-3_amd64.deb >
engrampa.log
76 ./src/fr-command-dpkg.c: File o directory non esistente

engrampa.log
-
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7592e6c0 (LWP 28785)]
[New Thread 0x7fffed12d6c0 (LWP 28786)]
[New Thread 0x7512d6c0 (LWP 28787)]
[New Thread 0x748966c0 (LWP 28788)]
[New Thread 0x7fffeebff6c0 (LWP 28789)]
[Thread 0x7fffeebff6c0 (LWP 28789) exited]
[New Thread 0x7fffeebff6c0 (LWP 28790)]
[New Thread 0x7fffee3fe6c0 (LWP 28791)]
[Thread 0x7fffeebff6c0 (LWP 28790) exited]
[Thread 0x7fffee3fe6c0 (LWP 28791) exited]
[New Thread 0x7fffee3fe6c0 (LWP 28792)]
[New Thread 0x7fffeebff6c0 (LWP 28793)]
[Thread 0x7fffee3fe6c0 (LWP 28792) exited]
[Thread 0x7fffeebff6c0 (LWP 28793) exited]
[New Thread 0x7fffeebff6c0 (LWP 28794)]
[New Thread 0x7fffee3fe6c0 (LWP 28795)]
[New Thread 0x7fffedbfd6c0 (LWP 28796)]
[Thread 0x7fffee3fe6c0 (LWP 28795) exited]
[New Thread 0x7fffee3fe6c0 (LWP 28797)]
[Thread 0x7fffedbfd6c0 (LWP 28796) exited]
[New Thread 0x7fffedbfd6c0 (LWP 28798)]
[Thread 0x7fffee3fe6c0 (LWP 28797) exited]
[Thread 0x7fffedbfd6c0 (LWP 28798) exited]
[Detaching after fork from child process 28799]

Thread 1 "engrampa" received signal SIGSEGV, Segmentation fault.
0x55581fbe in process_metadata_line (comm=0x55b20350,
line=0x55a89150 "1083 bytes,26 lines  control") at
./src/fr-command-dpkg.c:76
#0  0x55581fbe in process_metadata_line (comm=0x55b20350,
line=0x55a89150 "1083 bytes,26 lines  control") at
./src/fr-command-dpkg.c:76
#1  process_data_line (line=0x55a89150 "1083 bytes,26 lines
 control", data=0x55b20350) at ./src/fr-command-dpkg.c:110
#2  0x5558e12a in fr_channel_data_read
(channel=channel@entry=0x5576b160)
at ./src/fr-process.c:144
#3  0x5558fca8 in check_child (data=0x5576b140) at
./src/fr-process.c:857
#4  0x7715702e in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x771530d9 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x77156317 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x77156930 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x77388b7d in g_application_run () from
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#9  0x5556b45a in main (argc=, argv=)
at ./src/main.c:357
#0  0x55581fbe in process_metadata_line (comm=0x55b20350,
line=0x55a89150 "1083 bytes,26 lines  control") at
./src/fr-command-dpkg.c:76
fdata = 0x55ac9dd0
fields = 0x55b082a0
name = 
fdata = 
fields = 
name = 
__func__ = 
_g_boolean_var_10 = 
#1  process_data_line (line=0x55a89150 "1083 bytes,26 lines
 control", data=0x55b20350) at ./src/fr-command-dpkg.c:110
fdata = 
comm = 0x55b20350
fields = 
time_s = 
name = 
__func__ = "process_data_line"
#2  0x5558e12a in fr_channel_data_read
(channel=channel@entry=0x5576b160)
at ./src/fr-process.c:144
line = 0x55a89150 "1083 bytes,26 lines  control"
length = 41
terminator_pos = 40
#3  0x5558fca8 in check_child (data=0x5576b140) at
./src/fr-process.c:857
process = 
info = 0x55aa46a0
pid = 
status = 0
continue_process = 
channel_error = 
__FUNCTION__ = "check_child"
#4  0x7715702e in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x771530d9 in ?? () from 

Bug#1058661: dipy: slow (sometimes timing out) autopkgtest

[Étienne Mollier]

Hi Rebecca,

Rebecca N. Palmer, on 2023-12-14:
> This autopkgtest, and particularly test_reconstruct_rumba, is slow enough
> that it sometimes times out and fails.  I think this is varying hardware
> speed and not a random hang because failure seems to correlate with the
> earlier tests taking longer.
> 
> This could be fixed by skipping some slow tests (-k 'not
> test_reconstruct_rumba').  Alternatively, if these tests are important it
> _may_ be possible to increase the time limit.

Thanks for the notice and hint for getting the run time a tad
bit shorter.  I'm in the process of bumping dipy to version
1.8.0, and this is taking forever notably due to the sheer time
needed for running the test suite.  Version 1.8.0 looks to
introduce further tests which substancially increase further the
runtime (I now register more than twenty minutes on my machine,
per python3 version).

I'm a bit wary to begin skipping tests for the first upload of
the new upstream version, but I guess some trimming can be done
in a second time to get the run time down to reasonable levels.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/7, please excuse my verbosity
   `-on air: Steven Wilson - Impossible Tightrope


signature.asc
Description: PGP signature

Bug#1060404: libdata-streamserializer-perl: FTBFS on ppc64el: t/05_memory_leak.t failure

[Niko Tyni]

Source: libdata-streamserializer-perl
Source Version: 0.07-1
Severity: serious
Tags: ftbfs
Control: block 1055955 with -1

This package failed to build from source on ppc64el against Perl 5.38.

After two failures it looks deterministic but giving it back for a retry
might still be worth a try.

This is currently a blocker for the Perl 5.38 transition.

  
https://buildd.debian.org/status/fetch.php?pkg=libdata-streamserializer-perl=ppc64el=0.07-1%2Bb10=1704894151=0

   #   Failed test 'Check memory leak (196608 bytes)'
   #   at t/05_memory_leak.t line 63.
   # Looks like you failed 1 test of 3.
   t/05_memory_leak.t  
   1..3
   ok 1 - use Data::StreamSerializer;
   not ok 2 - Check memory leak (196608 bytes)
   # 5100 iterations were done, 2668237 bytes were produced
   ok 3 - Check memory checker
   Dubious, test returned 1 (wstat 256, 0x100)
   Failed 1/3 subtests 
   
   Test Summary Report
   ---
   t/05_memory_leak.t  (Wstat: 256 (exited 1) Tests: 3 Failed: 1)
 Failed test:  2
 Non-zero exit status: 1
   Files=5, Tests=70,  4 wallclock secs ( 0.03 usr  0.00 sys +  3.83 cusr  0.05 
csys =  3.91 CPU)
   Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#1041552: HFS/HFS+ are insecure

[Marco d'Itri]

On Jan 10, Michael Biebl  wrote:

> While we could ship such a udev rule for udisks, I don't think it will
> properly solve the issue. The device will still show up in nautilus, plasma
> etc and mounting is just an additional click away.
The threat model here is: somebody connects a crafted USB stick to 
a computer with a locked screen.

Also, the listed file systems are not used or not used anymore on 
removable devices.
Certainly not on removable devices used by regular users.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1060402: liblinux-termios2-perl: FTBFS on ppc64el: OS unsupported - no struct termios2

[Niko Tyni]

On Wed, Jan 10, 2024 at 08:30:21PM +0200, Niko Tyni wrote:
> Source: liblinux-termios2-perl
> Version: 0.01-2 
> Severity: important
> Tags: ftbfs
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> This package has never built on riscv64.

Sorry, s/riscv64/ppc64el/ here.

>   perl Build.PL --installdirs vendor --config "optimize=-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
> "ld=powerpc64le-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
>test-8985-0.c: In function ‘main’:
>test-8985-0.c:4:19: error: storage size of ‘t’ isn’t known
>4 |   struct termios2 t;
>  |   ^
>OS unsupported - no struct termios2

-- 
Niko

Bug#1060403: libxml-hash-xs-perl: FTBFS on s390x (big endian?): test failures

[Niko Tyni]

Source: libxml-hash-xs-perl
Version: 0.56-1
Severity: important
Tags: ftbfs

This package has never built on s390x. Looking at debian-ports results,
it's probably a big endian architecture issue.

Latest s390x build log is at

  
https://buildd.debian.org/status/fetch.php?pkg=libxml-hash-xs-perl=s390x=0.56-1=1613669844=0

   # Testing XML::Hash::XS 0.56, Perl 5.032001, /usr/bin/perl
   # XML::LibXML 2.0134, libxml2 20910
   t/00-load.t  
   1..1
   ok 1 - use XML::Hash::XS;
   ok
   Invalid parameter 'canonical' at t/01-h2x.t line 21.
   # Looks like your test exited with 255 just after 1.
   t/01-h2x.t . 
   1..24
   ok 1 - default
   Dubious, test returned 255 (wstat 65280, 0xff00)
   Failed 23/24 subtests 
   t/02-h2d.t . skipped: Option 'doc' is not supported
   t/03-h2x-oop.t . 
   1..2
   ok 1 - code reference
   ok 2 - code reference
   ok
   Invalid parameter 'attr' at t/04-h2x-lx.t line 36.
   # Looks like your test exited with 255 just after 3.

   [...]

   Test Summary Report
   ---
   t/01-h2x.t   (Wstat: 65280 Tests: 1 Failed: 0)
 Non-zero exit status: 255
 Parse errors: Bad plan.  You planned 24 tests but ran 1.
   t/04-h2x-lx.t(Wstat: 65280 Tests: 3 Failed: 0)
 Non-zero exit status: 255
 Parse errors: Bad plan.  You planned 15 tests but ran 3.
   t/06-x2h.t   (Wstat: 65280 Tests: 0 Failed: 0)
 Non-zero exit status: 255
 Parse errors: Bad plan.  You planned 10 tests but ran 0.
   t/07-x2h_filter.t (Wstat: 65280 Tests: 0 Failed: 0)
 Non-zero exit status: 255
 Parse errors: Bad plan.  You planned 6 tests but ran 0.
   Files=8, Tests=7,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.28 cusr  0.02 
csys =  0.31 CPU)
   Result: FAIL
 
-- 
Niko Tyni   nt...@debian.org

Bug#1041552: HFS/HFS+ are insecure

[Michael Biebl]

On Sun, 27 Aug 2023 02:34:04 +0200 Marco d'Itri  wrote:

So I propose this content for a file like
/usr/lib/udev/rules.d/75-insecure-fs.rules:



While we could ship such a udev rule for udisks, I don't think it will 
properly solve the issue. The device will still show up in nautilus, 
plasma etc and mounting is just an additional click away.


The UI would have to updated to present some kind of information to the 
user, that mounting the FS is potentially unsafe and asking the users 
for extra confirmation.


This would need more design work though and buy in from the desktop 
environments like say GNOME or KDE.


Tagging such FSes via udev rules seems like a reasonable idea though.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060402: liblinux-termios2-perl: FTBFS on ppc64el: OS unsupported - no struct termios2

[Niko Tyni]

Source: liblinux-termios2-perl
Version: 0.01-2 
Severity: important
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64

This package has never built on riscv64.

Latest build log is at

  
https://buildd.debian.org/status/fetch.php?pkg=liblinux-termios2-perl=ppc64el=0.01-2=1600683841=0

  dh_auto_configure -a
perl Build.PL --installdirs vendor --config "optimize=-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
"ld=powerpc64le-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro"
   test-8985-0.c: In function ‘main’:
   test-8985-0.c:4:19: error: storage size of ‘t’ isn’t known
   4 |   struct termios2 t;
 |   ^
   OS unsupported - no struct termios2
   dh_auto_configure: error: perl Build.PL --installdirs vendor --config 
"optimize=-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config 
"ld=powerpc64le-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" 
returned exit code 25
   make: *** [debian/rules:4: build-arch] Error 25
   dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

-- 
Niko Tyni   nt...@debian.org

Bug#1060401: ITP: python-scooby -- A lightweight tool for easily reporting your Python environment's package versions and hardware resources

[Francesco Ballarin]

Package: wnpp
Severity: wishlist
Owner: Francesco Ballarin 
X-Debbugs-Cc: debian-de...@lists.debian.org, francesco.balla...@unicatt.it

* Package name: python-scooby
  Version : 0.9.2
  Upstream Contact: Bane Sullivan 
* URL : https://github.com/banesullivan/scooby
* License : MIT
  Programming Lang: Python
  Description : A lightweight tool for easily reporting your Python 
environment's package versions and hardware resources

This package is a dependency of pyvista, see bug #1001105
The package will be maintained at 
https://salsa.debian.org/python-team/packages/python-scooby
in collaboration with my sponsor Drew Parsons and the Debian Python Team

Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols

[Matthieu Baerts]

Hi Aurélien,

On 08/01/2024 21:18, Aurelien Jarno wrote:
> On riscv64, mptcpd fails to build from source with a segmentation fault
> in the test-mptcpwrap test:

(...)

> Investigation shows that 3 conditions are needed to trigger this issue:
> - A recent kernel that supports mptcp, to be checked with
>   /proc/sys/net/mptcp/enabled
> - Something that prevents SCTP to be used, for instance on the build
>   daemons /proc/sys/kernel/modules_disabled is set to 1, preventing the
>   sctp.ko module to be loaded
> - A system without /etc/protocols, for instance without the netbase
>   package installed.
> 
> With this three conditions, this triggers the following code path from
> the mptcpwrap-tester.c file:
> 
> | static void test_socket_data(struct socket_data const *data)
> | {
> | int const fd = socket(data->domain, data->type, data->protocol);
> | 
> | if (fd == -1) {
> | if (errno == EPROTONOSUPPORT) {
> | struct protoent const *const p =
> | getprotobynumber(data->protocol);
> | 
> | fprintf(stderr,
> | "WARNING: Ignoring unsupported "
> | "protocol: %d - %s\n",
> | data->protocol,
> | p->p_name);
> | 
> | return;
> | }
> 
> The output of getprotobynumber() is used directly, without checking for
> a NULL pointer in case of error, for instance because /etc/protocols
> does not exist. This causes a segmentation fault when trying to
> dereference it. A workaround is to build-depends on netbase, and a
> proper fix to test for this error.

Thank you for the very nice investigation and analysis!

The fixes were then easy to do:
- upstream: https://github.com/multipath-tcp/mptcpd/pull/286
- debian: https://salsa.debian.org/debian/mptcpd/-/commit/8069902

> In the latest rebuild of mptpcd, the conditions where met only on the
> riscv64 buildd, and riscv64 is not a release architecture. That said a
> few mips64el buildds also met the 3 conditions and it will be the case
> of more and more buildds once they are upgraded to bookworm. I am
> therefore filling this issue as severity serious.

Many thanks for the explanation!

I will wait for the different pipelines to be over, before sending a new
version to mentors.debian.net!

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Bug#1060400: libapp-stacktrace-perl: FTBFS on riscv64: unthreaded.t failure

[Niko Tyni]

Source: libapp-stacktrace-perl
Version: 0.09-5
Severity: important
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64

This package has never built on riscv64.

Latest build log is at

  
https://buildd.debian.org/status/fetch.php?pkg=libapp-stacktrace-perl=riscv64=0.09-5=1694400120=0

   Child exited at t/unthreaded.t line 9.
   # Looks like your test exited with 1 before it could output anything.
   t/unthreaded.t  
   1..5
   Dubious, test returned 1 (wstat 256, 0x100)
   Failed 5/5 subtests 
   
   Test Summary Report
   ---
   t/unthreaded.t  (Wstat: 256 (exited 1) Tests: 0 Failed: 0)
 Non-zero exit status: 1
 Parse errors: Bad plan.  You planned 5 tests but ran 0.
   Files=4, Tests=1,  7 wallclock secs ( 0.12 usr  0.04 sys +  5.28 cusr  0.96 
csys =  6.40 CPU)
   Result: FAIL
 
-- 
NIko Tyni   nt...@debian.org

Bug#1060399: libbson-xs-perl: FTBFS on riscv64: double.t failures

[Niko Tyni]

Source: libbson-xs-perl
Version: 0.8.4-2
Severity: important
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64

This package has never built on riscv64.

Latest build log is at

  
https://buildd.debian.org/status/fetch.php?pkg=libbson-xs-perl=riscv64=0.8.4-2=1690811919=0


   #   Failed test 'native_to_bson(bson_to_native(cB)) = cB'
   #   at t/lib/CorpusTest.pm line 144.
   # Got:
   # 116400f87f00
   # Expected:
   # 1164001200f87f00
   # Looks like you failed 1 test of 5.
   
   #   Failed test 'case: NaN with payload'
   #   at t/corpus/double.t line 13.
   # Looks like you failed 1 test of 14.

   [...]

   Test Summary Report
   ---
   t/corpus/double.t  (Wstat: 256 (exited 1) Tests: 14 Failed: 1)
 Failed test:  11
 Non-zero exit status: 1
   t/mapping/double.t (Wstat: 768 (exited 3) Tests: 39 Failed: 3)
 Failed tests:  23, 29, 35
 Non-zero exit status: 3
   Files=59, Tests=1342, 97 wallclock secs ( 2.74 usr  0.35 sys + 84.38 cusr 
11.55 csys = 99.02 CPU)
   Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#1060275: asterisk: Codec translation notice

[List Support]

Le 10/01/2024 à 18:51, Jonas Smedegaard a écrit :

Quoting List Support via Pkg-voip-maintainers (2024-01-10 18:01:22)

Le 09/01/2024 à 13:50, List Support a écrit :

[...]

We will uninstall this build and install the same 20.5.2 from unstable
to do some checks, it seems to iax + g722 related. Will come back to you
this week.

We removed self compiled stock asterisk with "make uninstall" which keep
our configuration and installed

Asterisk 20.5.2~dfsg+~cs6.13.40431414-1 built by nobody @
buildd.debian.org on a unknown running Linux on 2023-12-22 12:58:28 UTC

We place a SIP call to a mobile phone using a SIP provider with codecs
set to "allow=!all,alaw", our codecs being "allow=!all,g772,alaw", both
using PJSIP. Output is below.

We did the same before removing our self compiled stock asterisk and
didn't had this translate NOTICE, so problem is effective with Debian
Asterisk package.

Thanks for testing.

Did you notice the post by TOOTAi?

I and TOOTAi are the same ;)

  Could you also try test *without*
g772 mentioned, ie. both ends configured as "allow=!all,alaw", and tell
if that is a viable workaround?


No translation done, all is good.

Daniel

Bug#1060398: Please update path to ukify

[Michael Biebl]

Package: python3-virt-firmware
Version: Please update path to ukify
Severity: normal

Hi,

the ukify tool is no longer considered experimental and as a result has
been moved to /usr/bin/ukify in v255 [1].
Your package references the old path /usr/lib/systemd/ukify [2]

While the systemd package ships a compat symlink /usr/lib/systemd/ukify
for the time being, we'd like to drop this at some point.

Please update your package accordingly to use /usr/bin/ukify and
consider sending this change upstream.

Regards,
Michael


[1] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/NEWS?ref_type=heads#L246
[2] 
https://sources.debian.org/src/virt-firmware/23.11-1/experimental/addons.py/?hl=24#L24

Bug#1041552: HFS/HFS+ are insecure

[Michael Biebl]

On Sun, 27 Aug 2023 02:34:04 +0200 Marco d'Itri  wrote:

Control: reassign -1 udisks2
Control: retitle -1 do not mount automatically unmaintained file systems

On Jul 20, md wrote:

> You are totally correct.
> Kernel team, please blacklist HFS/HFS+ for automounting.
As discussed on debian-devel@, this policy should not be handled by the 
kernel because modules autoloading of file systems drivers should not be

disabled.

So I propose this content for a file like
/usr/lib/udev/rules.d/75-insecure-fs.rules:

# Do not automatically mount these file systems because their drivers are
# marked as "orphan" or "odd fixes" in the kernel MAINTAINERS file and so
# are more at risk of having security-sensitive defects which could be
# exploited by a crafted file system.
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"

ENV{ID_FS_TYPE}=="affs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="ecryptfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="efs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jffs2", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="jfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="qnx6", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="sysv", ENV{UDISKS_AUTO}="0"

LABEL="udisks_insecure_fs_end"


I asked udisks upstream for their input, see
https://github.com/storaged-project/udisks/issues/1239


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060397: libsys-syscall-perl: FTBFS on riscv64: t/01-epoll.t failure

[Niko Tyni]

Source: libsys-syscall-perl
Version: 0.25-7
Severity: important
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64

This package has never built on riscv64.

Latest build log is at

  
https://buildd.debian.org/status/fetch.php?pkg=libsys-syscall-perl=riscv64=0.25-7=1691061212=0


  #   Failed test 'have epoll'
  #   at t/01-epoll.t line 15.
  
  [...]
  
  Test Summary Report
  ---
  t/01-epoll.t   (Wstat: 3840 (exited 15) Tests: 20 Failed: 15)
Failed tests:  1-2, 5-12, 15-19
Non-zero exit status: 15
  Files=3, Tests=23,  3 wallclock secs ( 0.14 usr  0.02 sys +  1.99 cusr  0.33 
csys =  2.48 CPU)
  Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#1056874: [Help] Re: python-srsly: ftbfs with cython 3.0.x

[Andreas Tille]

Control: tags -1 help

Hi,

when applying the patch (thanks for this, Bas) I learned that the
package builds for other reasons.  This is also true for the latest
upstream version[1].

Any help to fix this would be welcome
   Andreas.

[1] https://salsa.debian.org/python-team/packages/python-srsly/-/jobs/5141528

-- 
http://fam-tille.de

Bug#1060275: asterisk: Codec translation notice

[Jonas Smedegaard]

Quoting List Support via Pkg-voip-maintainers (2024-01-10 18:01:22)
> Le 09/01/2024 à 13:50, List Support a écrit :
> > [...]
> > 
> > We will uninstall this build and install the same 20.5.2 from unstable 
> > to do some checks, it seems to iax + g722 related. Will come back to you 
> > this week.
> 
> We removed self compiled stock asterisk with "make uninstall" which keep 
> our configuration and installed
> 
> Asterisk 20.5.2~dfsg+~cs6.13.40431414-1 built by nobody @ 
> buildd.debian.org on a unknown running Linux on 2023-12-22 12:58:28 UTC
> 
> We place a SIP call to a mobile phone using a SIP provider with codecs 
> set to "allow=!all,alaw", our codecs being "allow=!all,g772,alaw", both 
> using PJSIP. Output is below.
> 
> We did the same before removing our self compiled stock asterisk and 
> didn't had this translate NOTICE, so problem is effective with Debian 
> Asterisk package.

Thanks for testing.

Did you notice the post by TOOTAi?  Could you also try test *without*
g772 mentioned, ie. both ends configured as "allow=!all,alaw", and tell
if that is a viable workaround?


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1060342: Please cherry-pick c1083acea707 ("ebtables: Fix corner-case noflush restore bug")

[Jeremy Sowden]

On 2024-01-09, at 21:55:13 +0100, Michael Biebl wrote:
> Package: iptables
> Version: 1.8.10-1
> Severity: normal
> Tags: patch
> 
> 
> Hi,
> 
> firewalld fails to work with the current version of iptables in Debian.
> This is exemplified by the autopkgtest which recently has been made
> available in Debian (thanks elbrus):
> https://ci.debian.net/packages/f/firewalld/unstable/amd64/41650423/
> 
> After contacting firewalld upstream in
> https://github.com/firewalld/firewalld/issues/1268
> 
> it turns out this issue has already been fixed in 
> etables (iptables-nft) commit c1083acea707 ("ebtables: Fix corner-case
> noflush restore bug").
> 
> Cherry-picking this commit for iptables, makes the firewalld test suite
> pass. I'm attaching the commit as patch file.
> 
> If you are busy, I can offer to NMU.

I'll take care of it.

J.


signature.asc
Description: PGP signature

Bug#1060323: libosp-dev: missing dependency on libosp5

[gregor herrmann]

On Tue, 09 Jan 2024 17:58:57 +0200, Niko Tyni wrote:

> the libosp-dev package in sid is missing a dependency on libosp5,
> leaving /usr/lib/libosp.so a dangling symlink and making at least
> libsgml-parser-opensp-perl (and probably other packages build-depending
> on libosp-dev) fail to build.

A quick look:

I think this is caused by bumping the debhelper cpompatibility level
from 7 to 13 … And a not really uncomplicated debian/rules file.

What's happening, with DH_VERSBOSE set, is:

#v+
 fakeroot debian/rules binary
…
: > debian/libosp-dev.substvars
…
echo "opensp:Version=opensp (= 1.5.2-14.1)">> 
debian/libosp-dev.substvars
…
echo "libosp:Version=libosp5 (= 1.5.2-14.1)" >> 
debian/libosp-dev.substvars
echo "libosp:ShlibVersion=libosp5 (>= 1.5.2-1)" >> debian/libosp-dev.substvars
…
dh_prep
rm -f -- debian/opensp.substvars debian/libosp5.substvars 
debian/libosp-dev.substvars
…
dpkg-gencontrol: warning: Depends field of package libosp-dev: substitution 
variable ${opensp:Version} used, but is not defined
dpkg-gencontrol: warning: Depends field of package libosp-dev: substitution 
variable ${libosp:Version} used, but is not defined
#v-

What works is
- remove the dh_prep call
- change it to `dh_prep -Xdebian/libosp-dev.substvars'
- probably also rewriting d/rules massively :)


What also seems to work is changing the order around by re-arranging
the target dependencies in d/rules:

#v+
diff -Nru opensp-1.5.2/debian/rules opensp-1.5.2/debian/rules
--- opensp-1.5.2/debian/rules   2023-12-29 00:09:16.0 +0100
+++ opensp-1.5.2/debian/rules   2024-01-10 17:31:57.0 +0100
@@ -95,12 +95,12 @@
 
 build-indep: build-stamp
 
-debian/copyright:  COPYING debian/copyright.Debian
+debian/copyright:  COPYING debian/copyright.Debian install-stamp
 #   to ensure we have a verbatim copy of the upstream copyright, 
 #   cat the Debian-specific stuff to the end of the upstream file
cat $^ > $@
 
-debian/$(pkg-libosp-dev).substvars:
+debian/$(pkg-libosp-dev).substvars: install-stamp
 #   indicate our providing version of shlibs; this must be
 #   sync'd with debian/control
: > $@
@@ -108,17 +108,17 @@
echo "libosp:Version=$(pkg-libosp) (= $(DEB_VERSION))" >> $@
echo "libosp:ShlibVersion=$(pkg-libosp) (>= $(SHLIBS_PKGVER))" >> $@
 
-debian/$(pkg-libosp).shlibs:
+debian/$(pkg-libosp).shlibs: install-stamp
 #   std shlibs file, with the first version that supplied the version
 #   that applications should build with
echo "libosp  $(libosp-maj-ver) $(pkg-libosp) (>= 
$(SHLIBS_PKGVER))" > $@
 
-debian/README.Debian:  debian/README.Debian.in
+debian/README.Debian:  debian/README.Debian.in install-stamp
 #   substitute the catalog paths
sed -e 's|%{default-catalogs}|$(default-catalogs)|' \
-e 's|%{default-sgml-path}|$(default-sgml-path)|' $^ > $@
 
-debian/$(pkg-libosp).README.Debian:debian/$(pkg-libosp).README.Debian.in
+debian/$(pkg-libosp).README.Debian:debian/$(pkg-libosp).README.Debian.in 
install-stamp
 #   substitute the catalog paths
sed -e 's|%{default-catalogs}|$(default-catalogs)|' \
-e 's|%{default-sgml-path}|$(default-sgml-path)|' $^ > $@
@@ -130,7 +130,7 @@
 # Install into DESTDIR, then move everything later. CURDIR is set by make.
 DESTDIR = $(CURDIR)/debian/tmp
 export DESTDIR
-install-stamp: build-stamp $(install-common)
+install-stamp: build-stamp
dh_testdir
dh_testroot
dh_prep
@@ -161,7 +161,7 @@
 # There are no architecture-independent binary packages generated from this
 # source package.
 
-binary-arch: install-stamp
+binary-arch: install-stamp $(install-common)
dh_testdir
dh_testroot
 
#v-


Cheers,
gregor 

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1058400: [Help] Re: python-stack-data: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Andreas Tille]

Control: tags -1 help

Hi,

I tried the suggested patch for the cython3 issue of bug #1056872
in the currently packaged version[1] as well also tried upgrading
to latest upstream and tried building[2] which failed as well.

I admit, I'm running out of ideas what to do next.

Any help is welcome
   Andreas.

PS: I do not have any specific interest in this package, just intended
to squash some bugs.


[1] 
https://salsa.debian.org/python-team/packages/python-stack-data/-/jobs/5141231
[2] 
https://salsa.debian.org/python-team/packages/python-stack-data/-/jobs/5141459

-- 
http://fam-tille.de

Bug#1032659: ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.

[Christopher Obbard]

Hi Mark,

Did you think about my comments below? I would like to upload this package
into the NEW queue over the next couple of weeks (so to not block a new
imminent version of debos from being included in the archive).

Please do let me know if you have time to make the changes, or alternatively
if you do not have the time. I can make the changes to the packaging, but I do
not want to duplicate effort.

Thanks!
Chris

On Thu, 2023-12-07 at 18:57 +, Christopher Obbard wrote:
> Hi Mark,
> 
> I will be willing to sponsor this package (mainly as I am looking to using
> it
> in Debos). Your packaging looks generally good, but I have noticed a few
> minor
> issues with the Git repo / packaging, let me know if you can fix these or if
> you'd like me to do so.
> 
> - d/copyright: "Copyright: 2019 Task" seems.. wrong? Also, for the record
> there is no explicit licence file in the upstream repository, but the GitHub
> page says MIT.
> 
> - The package's commit history seems to modify the original source, e.g.
> 908e6bca ("Ignore _build and quilt .pc dirs via .gitignore") which is then
> reverted by af533953 ("Import Debian changes 2.20.0-1"). It would be far
> cleaner to drop these commits.
> 
> - 6ef11ba6 ("fixup: unstable build submission") seems to be wrong. As you're
> not uploading into unstable, you should leave it as UNRELEASED.
> 
> - v3.0.0 has been released upstream. What would the plan be for importing
> that?
> 
> - The TestShuffle function seems to fail (heh, is this test even
> deterministic
> ?):
> 
> > $ gbp buildpackage --git-pbuilder
> > === RUN   TestShuffle
> >     functions_test.go:82: 
> > Error Trace:/build/golang-github-go-task-slim-sprig-
> > 2.20.0/_build/src/github.com/go-task/slim-sprig/functions_test.go:82
> > Error:  Received unexpected error:
> > Expected 'rldo HWlloe', got 'olldolr WeH'
> > Test:   TestShuffle
> > --- FAIL: TestShuffle (0.00s)
> > 
> > dh_auto_test: error: cd _build && go test -vet=off -v -p 16 github.com/go-
> > task/slim-sprig returned exit code 1
> 
> 
> 
> Thanks!
> 
> Chris

Bug#916122: pbuilder: misleading warning about missing cgroups

[Jürgen Kuri]

We still have pbuilder version 0.231 for current Debian OS 12 (Bookworm) 
and warning message about not using cgroups is still shown.


It is in shell script file "/usr/lib/pbuilder/pbuilder-checkparams":

1) The check in line 398 "systemctl is-system-running --quiet >/dev/null 
2>&1" returns with shell exit code 1 which must 0 and if-condition using 
cgroups is never fulfilled.


2) Semantically, the if-condition in line 398 and 394 does not work 
anymore for newer bash releases


391 if [ "$USECGROUP" = "yes" ]; then
392 # v215 is required for systemd-escape
393 if systemctl is-system-running --quiet >/dev/null 2>&1 && \
394 dpkg --compare-versions "$(dpkg-query -W 
--showformat='${Version}' systemd)" gt 215; then
395 # --description uses that no-spaces string because the 
quoting sucks
396 # right now, and it would end up trying to execute 
$PBUILDER_OPERATION…
397 # long-term solution is to turn $CHROOTEXEC into a 
command and properly

398 # use arrays instead of plain strings.
399 
SYSTEMD_SLICE="system-pbuilder-${PBUILDER_OPERATION}${1:+-"$(systemd-escape "$(basename "$1" .dsc)")"}-$$.slice"

400 systemctl_run=(
401 systemd-run
402 --quiet
403 --scope
404 
--description="pbuilder_${PBUILDER_OPERATION}${1:+_"$(basename "$1")"}"

405 --slice="$SYSTEMD_SLICE"
406 )
407 CHROOTEXEC="${systemctl_run[*]} $CHROOTEXEC"
408 else
409 log.w "cgroups are not available on the host, not using 
them."

410 USECGROUP=not-available
411 fi


I changed the code in this way from line 393 until 395:

391 if [ "$USECGROUP" = "yes" ]; then
392 # v215 is required for systemd-escape
393 _systemd_ver=$(systemd --version | grep 'systemd' | sed -r 
's/(^systemd[[:blank:]]+)([0-9]{3})(.*$)/\2/')

394
395 if [[ ${_systemd_ver} -gt 215 ]] ; then
396 # --description uses that no-spaces string because the 
quoting sucks
397 # right now, and it would end up trying to execute 
$PBUILDER_OPERATION…
398 # long-term solution is to turn $CHROOTEXEC into a 
command and properly

399 # use arrays instead of plain strings.
400 
SYSTEMD_SLICE="system-pbuilder-${PBUILDER_OPERATION}${1:+-"$(systemd-escape "$(basename "$1" .dsc)")"}-$$.slice"

401 systemctl_run=(
402 systemd-run
403 --quiet
404 --scope
405 
--description="pbuilder_${PBUILDER_OPERATION}${1:+_"$(basename "$1")"}"

406 --slice="$SYSTEMD_SLICE"
407 )
408 CHROOTEXEC="${systemctl_run[*]} $CHROOTEXEC"
409 else
410 log.w "cgroups are not available on the host, not using 
them."

411 USECGROUP=not-available
412 fi

1) Problematic check if systemd is running was eliminated, it was 
introduced with Debian 8, long time ago. So systemd is status quo!


2) The evaluation of the systemd version is done in line 393 using the 
"systemd --version" command


3) Line 395, simplified expression in if-clause, executing shell 
commands in clause will/may not work anymore like in my case


On Mon, 07 Jan 2019 18:01:01 +0100 Yves-Alexis Perez  
wrote:



On Mon, 2019-01-07 at 16:03 +0100, Mattia Rizzolo wrote:
> On Sun, Jan 06, 2019 at 11:47:03AM +0100, Yves-Alexis Perez wrote:
> > Also, I also have the message while I *am* using systemd as init 
system.


> Most likely that's a different issue, filed as #917354
> Check your system with `systemctl list-units --failed`.

Indeed, my system is basically half the time in degraded mode:

root@scapa:~# systemctl is-system-running
degraded
root@scapa:~# echo $?
1
root@scapa:~# systemctl --failed
UNIT LOAD ACTIVE
SUB DESCRIPTION
● mnt-scapa\x2dbackup.mount loaded failed failed /mnt/scapa-backup

(this is my external backup drive). Thanks for the tip anyway.

Regards,
 >

Bug#1058276: bart-view: FTBFS: (.text+0xa4e): undefined reference to `shared_obj_destroy'

[Martin Uecker]

Am Mittwoch, dem 10.01.2024 um 08:16 +0100 schrieb Andreas Tille:
> Hi Martin,
> 
> I tried to open an issue upstream but it seems the repository does not
> feature submitting issues.  Can you have a look please?
> 
> Kind regards
> Andreas.
> 

Hi Andreas,

I just tagged a new upstream release and also prepared a new
Debian package. Please take a look.

Martin

Bug#1060396: RM: gnome-online-miners -- RoM; unmaintained and unused

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: gnome-online-min...@packages.debian.org
Control: affects -1 src:gnome-online-miners

Please remove gnome-online-miners from Debian.

It has no upstream maintainer and was not included in Debian 12.

See https://bugs.debian.org/1014461 for more background.

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1060395: bluez: please add simple testsuite from Ubuntu

[Gianfranco Costamagna]

Package: bluez
Version: 5.67-1
Severity: normal

Dear Maintainer,
Ubuntu added a testsuite to the package. I'm attaching it to this bug report

Please consider adding it.

G.
#!/usr/bin/env python3
import unittest
import subprocess
import sys
import os

import aptdaemon.test

class TestBluezResponse(unittest.TestCase):

  devices = {}

  def setUp(self):
# bluetoothd starts on demand, so make sure it's running
subprocess.call(['service', 'bluetooth', 'start'])
p1 = subprocess.Popen(['hciconfig'],
  stdout=subprocess.PIPE,
  universal_newlines=True)
p2 = subprocess.Popen(['grep', '\(^hci\|BD\ Address\)'],
  stdin=p1.stdout, stdout=subprocess.PIPE,
  universal_newlines=True)
p1.stdout.close()
hciconf_output = p2.communicate()[0].replace('\t', ' ').split('\n')

device_id = ""
for line in hciconf_output:
  if "hci" in line:
device_id = line.split(':')[0]
  elif "BD Address" in line:
self.devices[device_id] = line.split()[2]

if len(self.devices) < 1:
  self.skipTest("No bluetooth devices available for testing")

  def testDevice(self):
for dev in self.devices:
  ret = 
subprocess.call(['/usr/share/doc/bluez-test-scripts/examples/list-devices'])
  self.assertEqual(ret, 0)

  def testAdapter(self):
for dev in self.devices:
  output = 
subprocess.check_output(['/usr/share/doc/bluez-test-scripts/examples/test-adapter',
 '-i', dev, 'address'],
   universal_newlines=True)
  self.assertIn(self.devices[dev], output)

unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, 
verbosity=2))
Tests: bluez_response
Depends: python3-aptdaemon.test:native, python3-dbus:native, bluez, 
bluez-test-scripts
Restrictions: needs-root, isolation-container


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060394: network setup for bookworm uses eth0 instead of enX0

[Valentin Kleibel]

Package: xen-tools
Version: 4.9.2-1
Tags: patch

Dear Maintainers,

The default network interface naming scheme for bookworm don-U's is 
enX[num] but the network setup script used to fill 
/etc/network/interfaces still assumes eth0 for the first network interface.


I think either the script 
/usr/share/xen-tools/common/40-setup-networking-deb should be changed or 
a changed copy should be used for 
/usr/share/xen-tools/bookworm.d/40-setup-networking instead of the symlink.


I've attached a simple patch that i used creating new bookworm domUs.

Thanks for your work,
Valentin--- /usr/share/xen-tools/common/40-setup-networking-deb.orig2024-01-09 18:22:08.130262212 +0100
+++ /usr/share/xen-tools/common/40-setup-networking-deb 2024-01-09 18:21:34.908959639 +0100
@@ -49,9 +49,9 @@
 iface lo inet loopback
 
 # The primary network interface
-auto eth0
-iface eth0 inet dhcp
-# post-up ethtool -K eth0 tx off
+auto enX0
+iface enX0 inet dhcp
+# post-up ethtool -K enX0 tx off
 
 #
 # The commented out line above will disable TCP checksumming which
@@ -105,14 +105,14 @@
 iface lo inet loopback
 
 # The primary network interface
-auto eth0
-iface eth0 inet static
+auto enX0
+iface enX0 inet static
  address ${ip1}
 ${gway}
  netmask ${netmask}
 ${bcast}
 ${point}
- # post-up  ethtool -K eth0 tx off
+ # post-up  ethtool -K enX0 tx off
 
 #
 # The commented out line above will disable TCP checksumming which
@@ -131,11 +131,11 @@
 logMessage Adding etho:${interface}
 
 cat <>${prefix}/etc/network/interfaces
-auto eth0:${interface}
-iface eth0:${interface} inet static
+auto enX0:${interface}
+iface enX0:${interface} inet static
  address ${value}
  netmask ${netmask}
- # post-up  ethtool -K eth0 tx off
+ # post-up  ethtool -K enX0 tx off
 E_O_STATIC
 count=`expr $count + 1`
 interface=`expr $interface + 1`

Bug#1060393: bluez: please update patch work-around-Logitech-diNovo-Edge-keyboard-firmware-i.patch

[Gianfranco Costamagna]

Package: bluez
Version: 5.67-1
Severity: normal

Dear Maintainer,

Can you please update the patch with this new content?

From aa73bf5039dfd2cf0a52dd6fd22501d955cc1a00 Mon Sep 17 00:00:00 2001
From: Tommy 
Date: Thu, 10 Jan 2013 09:18:43 +0100
Subject: [PATCH] work around Logitech diNovo Edge keyboard firmware issue

https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/269851
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1688663
---
 tools/hid2hci.rules |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/hid2hci.rules b/tools/hid2hci.rules
index db6bb03..7db4572 100644
--- a/tools/hid2hci.rules
+++ b/tools/hid2hci.rules
@@ -11,7 +11,10 @@ ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", 
ATTR{bInterfaceProt
   RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"
 
 # Logitech devices

-KERNEL=="hiddev*", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c70[345abce]|c71[34bc]", \
+KERNEL=="hiddev*", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c70[345abce]|c71[3bc]", \
+  RUN+="hid2hci --method=logitech-hid --devpath=%p"
+# Logitech, Inc. diNovo Edge Keyboard
+KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c7[01]4", \
   RUN+="hid2hci --method=logitech-hid --devpath=%p"
 
 ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"

--
1.8.0.1

Bug#1060275: asterisk: Codec translation notice

[List Support]

Hi Jonas

Le 09/01/2024 à 13:50, List Support a écrit :

[...]

We will uninstall this build and install the same 20.5.2 from unstable 
to do some checks, it seems to iax + g722 related. Will come back to you 
this week.


We removed self compiled stock asterisk with "make uninstall" which keep 
our configuration and installed


Asterisk 20.5.2~dfsg+~cs6.13.40431414-1 built by nobody @ 
buildd.debian.org on a unknown running Linux on 2023-12-22 12:58:28 UTC


We place a SIP call to a mobile phone using a SIP provider with codecs 
set to "allow=!all,alaw", our codecs being "allow=!all,g772,alaw", both 
using PJSIP. Output is below.


We did the same before removing our self compiled stock asterisk and 
didn't had this translate NOTICE, so problem is effective with Debian 
Asterisk package.



[2024-01-10 17:47:22] NOTICE[1174953][C-0004]: translate.c:603 
ast_translate: 28291 lost frame(s) 31002/2710 (slin@16000)->(g722@16000)

zone-s*CLI> pjsip show channelstats


...Receive. .Transmit..
 BridgeId ChannelId  UpTime.. Codec.   CountLost Pct 
Jitter   CountLost Pct  Jitter RTT


===

 a715444f 103104-000300:00:10 alaw  204   00 
0.005387   00   0.000   0.028
 a715444f zwr-freePBX-00 00:00:10 g722  387   00 
0.001355   00   0.000   0.000


Objects found: 2

[2024-01-10 17:47:27] NOTICE[1174953][C-0004]: translate.c:603 
ast_translate: 28290 lost frame(s) 31252/2961 (slin@16000)->(g722@16000)



Why slin is involved ? We also see it on our production server running 
same Debian version of Asterisk


[2024-01-10 16:22:40] NOTICE[278651][C-0ed4]: translate.c:603 
ast_translate: 5954 lost frame(s) 5955/0 (slin@8000)->(alaw@8000)


or

[2024-01-10 16:07:01] NOTICE[277190][C-0eaf]: translate.c:603 
ast_translate: 7414 lost frame(s) 41161/33746 
(slin@16000)->(slin@8000)->(alaw@8000)


Please let us know which details you want from us (verbose, dump, debug, 
...) which could help you


--
Daniel

Bug#1060392: etckeeper: move systemd units into /usr

[Sven Joachim]

Package: etckeeper
Version: 1.18.20-1.1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi,

Your package installs systemd units into /lib/systemd/system.  For the
ongoing Debian UsrMerge effort [1] these files should move to /usr in
the trixie cycle.

There are several ways to achieve this, the simplest one is probably to
add dh-sequence-movetousr to Build-Depends, so that the helper tool
dh_movetousr does the job.  See the attached build-tested patch.

Cheers,
   Sven


[1] https://wiki.debian.org/UsrMerge

From 7b9cbc1f9e6b12d1c367eaac176c007d24f1ac81 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 10 Jan 2024 17:31:53 +0100
Subject: [PATCH] Build-depend on dh-sequence-movetousr

This moves the systemd units into /usr/lib/systemd/system in trixie
and later, while keeping them in /lib/systemd/system in
bookworm-backports.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 3729659..8d0cb4b 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Build-Depends: debhelper-compat (= 13),
bats,
brz,
dh-python,
+   dh-sequence-movetousr,
fakeroot,
git,
python3:any,
--
2.43.0

Bug#1055038: libreoffice-dictionaries: Please enable Esperanto hunspell dict, hyphenation and thesaurus packages.

[Agustin Martin]

El lun, 30 oct 2023 a las 0:18, Agustin Martin () escribió:
>
> Source: libreoffice-dictionaries
> Version: 1:7.5.0-1
> Severity: wishlist
>
> Hi, Rene and Mattia
>
> Please enable Esperanto stuff from libreoffice dictionaries. This
> stuff was added in 2021
>
> I am attaching a diff with what seems to me the required changes for
> Esperanto stuff to be enabled.

Hi,

Attached slightly updated diff (include year in copyright notice and
add esperanto stuff to ass_639_code and ass_639_name variables). Did
not rebuild json list, seems there are some other new dicts.

Regards,

-- 
Agustin
From 925253a9343c290fb07d366b178b4144f9c4e558 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Sun, 29 Oct 2023 23:51:02 +0100
Subject: [PATCH] Enable esperanto hunspell dict, hyphenation and thesaurus
 packages.

---
 debian/control   | 42 ++
 debian/copyright |  4 
 debian/helper.py |  5 +++--
 debian/list.json | 15 +++
 debian/rules.install |  4 
 5 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 9b6f375..193dcb8 100644
--- a/debian/control
+++ b/debian/control
@@ -486,6 +486,48 @@ Description: English (GB) dictionary for hunspell
  terminal interface using Curses library, an Ispell pipe interface and a
  LibreOffice UNO module.
 
+Package: hyphen-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}
+Suggests: libreoffice-writer
+Provides: hyphen-hyphenation-patterns, hyphen-hyphenation-patterns-eo
+Description: Esperanto hyphenation patterns
+ This package contains the Esperanto hyphenation patterns.
+ .
+ You can use these patterns with programs which take advantage of libhyphen,
+ like LibreOffice.
+
+Package: hunspell-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}, ${hunspell:Depends}
+Suggests: hunspell, libreoffice-writer
+Provides: hunspell-dictionary, hunspell-dictionary-eo
+Breaks: myspell-eo (<< 2.1.2000.02.25-62)
+Replaces: myspell-eo (<< 2.1.2000.02.25-62)
+Description: Esperanto dictionary for hunspell
+ This is the Esperanto dictionary for use with the hunspell
+ spellchecker.
+ .
+ Hunspell is a spell checker and morphological analyzer library and program
+ designed for languages with rich morphology and complex word compounding or
+ character encoding. It is based on MySpell and features an Ispell-like
+ terminal interface using Curses library, an Ispell pipe interface and a
+ LibreOffice UNO module.
+
+Package: mythes-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}
+Suggests: libreoffice-writer
+Provides: mythes-thesaurus, mythes-thesaurus-eo
+Description: Esperanto Thesaurus for LibreOffice
+ Libreoffice is a full-featured office productivity suite that provides a
+ near drop-in replacement for Microsoft(R) Office.
+ .
+ This package contains the Esperanto thesaurus for LibreOffice.
+
 Package: hyphen-es
 Architecture: all
 Multi-Arch: foreign
diff --git a/debian/copyright b/debian/copyright
index 82fcc87..8ba57bc 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -187,6 +187,10 @@ License: custom1
  % Please contact the TUGboat editorial staff 
  % for corrections and omissions.
 
+Files: dictionaries/eo/*
+Copyright: 2010 Artur Trzewik 
+License: GPL-2+
+
 Files: dictionaries/es/*
 Copyright: Santiago Bosio 
 License: GPL-3+ or LGPL-3+ or MPL-1.1+
diff --git a/debian/helper.py b/debian/helper.py
index 9436a1e..014785a 100755
--- a/debian/helper.py
+++ b/debian/helper.py
@@ -68,6 +68,7 @@ breaks_replaces = {
  "hunspell-bg": ("myspell-bg", '<<', '4.1-5'),
  "hunspell-en-gb": ("myspell-en-gb", '<<', "1:5.0.1+dfsg-1"),
  "hunspell-en-za": ("myspell-en-za", '<<', "1:5.0.1+dfsg-1"),
+ "hunspell-eo": ("myspell-eo", '<<', "2.1.2000.02.25-62"),
  "hunspell-hr": ('myspell-hr', '<<', '1:6.0.3-2'),
  "hunspell-it": ("myspell-it", '<<', "1:5.0.1+dfsg-1"),
  "hunspell-kmr": ('myspell-ku', '<<', '1:5.1.3-2'),
@@ -171,10 +172,10 @@ Description: German dictionary for hunspell ("frami" version)
 # Code lookup: https://en.wikipedia.org/wiki/ISO_639:$code
 
 # link the pseudo-RFC639-1 used by upstream (the key) to an actual RFC639-1 or RFC638-2
-ass_639_code = {"af_ZA": "af", "an_ES": "an", "ar": "ar", "be_BY": "be", "bg_BG": "bg", "bn_BD": "bn", "bo": "bo", "br_FR": "br", "bs_BA": "bs", "ca": "ca", "cs_CZ": "cs", "da_DK": "da", "de": "de", "el_GR": "el", "en": "en", "es": "es", "et_EE": "et", "fr_FR": "fr", "gd_GB": "gd", "gl": "gl", "gu_IN": "gu", "gug": "gug", "he_IL": "he", "hi_IN": "hi", "hr_HR": "hr", "hu_HU": "hu", "id": "id", "is": "is", "it_IT": "it", "kmr_Latn": "kmr", "lo_LA": "lo", "lt_LT": "lt", "lv_LV": "lv", "mn_MN": "mn", "ne_NP": "ne", "nl_NL": "nl", "no": "no", "oc_FR": "oc", "pl_PL": "pl", "pt_BR": "pt-br", "pt_PT": "pt-pt", "ro": "ro", "ru_RU": "ru", "si_LK": "si", "sk_SK": "sk", "sl_SI": "sl", "sq_AL": "sq", "sr": "sr", "sv_SE": "sv", 

Bug#1012074: python-rocksdb: FTBFS with rocksdb 7.2+

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/NightTsarina/python-rocksdb/issues/22

-- 
http://fam-tille.de

Bug#1060391: RFS: selint/1.5.0-1 -- Static code analysis of refpolicy style SELinux policies

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: selinux-de...@lists.alioth.debian.org

Dear mentors,

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

 * Package name : selint
   Version  : 1.5.0-1
   Upstream contact : Daniel Burgener 
 * URL  : https://github.com/SELinuxProject/selint
 * License  : Apache-2.0
 * Vcs  : https://salsa.debian.org/selinux-team/selint
   Section  : devel

The source builds the following binary packages:

  selint - Static code analysis of refpolicy style SELinux policies

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/selint/selint_1.5.0-1.dsc

Changes since the last upload:

 selint (1.5.0-1) unstable; urgency=medium
 .
   * New upstream version 1.5.0
 .
   * d/patches: drop upstream applied patches
   * d/copyright: update years

Regards,
   Christian Göttsche

Bug#1060390: python3-jupyterlab: Jupyter lab does not start up

[Christian Holm Christensen]

Package: python3-jupyterlab
Version: 4.0.8+ds1-2
Severity: important
X-Debbugs-Cc: chol...@gmail.com

Jupyter lab does not start up

When executing

jupyter lab

or

jupyter-lab

I get a stack trace from Python:

>>> START
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 645, in
get
value = obj._trait_values[self.name]
~^^^
KeyError: 'core_config'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/jupyter-lab", line 33, in 
sys.exit(load_entry_point('jupyterlab==0.0.0', 'console_scripts', 'jupyter-
lab')())
^^^
  File "/usr/bin/jupyter-lab", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1147, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/jupyterlab/labapp.py", line 99, in

app_version = get_app_version()
  ^
  File "/usr/lib/python3/dist-packages/jupyterlab/commands.py", line 585, in
get_app_version
handler = _AppHandler(app_options)
  
  File "/usr/lib/python3/dist-packages/jupyterlab/commands.py", line 619, in
__init__
self.core_data = deepcopy(options.core_config._data)
  ^^^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 686, in
__get__
return self.get(obj, cls)
   ^^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 648, in
get
default = obj.trait_defaults(self.name)
  ^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1752, in
trait_defaults
return self._get_trait_default_generator(names[0])(self)
   ^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1132, in
__call__
return self.func(*args, **kwargs)
   ^^
  File "/usr/lib/python3/dist-packages/jupyterlab/commands.py", line 380, in
_default_core_config
return CoreConfig()
   
  File "/usr/lib/python3/dist-packages/jupyterlab/coreconfig.py", line 50, in
__init__
self._data = _get_default_core_data()
 
  File "/usr/lib/python3/dist-packages/jupyterlab/coreconfig.py", line 18, in
_get_default_core_data
with open(pjoin(HERE, "staging", "package.json")) as fid:
 
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/python3/dist-
packages/jupyterlab/staging/package.json'
<<< END

This looks a little like the distributed code isn't built for deployment but
for building the final package (the `staging` part of the above error).

Also, the package seems to dump code all over `/usr/lib/python3/dist-packages`,
for example

>>> START
...
/usr/lib/python3/dist-packages/docs/source
/usr/lib/python3/dist-packages/docs/source/conf.py
/usr/lib/python3/dist-packages/examples
/usr/lib/python3/dist-packages/examples/app
/usr/lib/python3/dist-packages/examples/app/main.py
...
/usr/lib/python3/dist-packages/packages
/usr/lib/python3/dist-packages/packages/extensionmanager-extension
/usr/lib/python3/dist-packages/packages/extensionmanager-extension/examples
/usr/lib/python3/dist-packages/packages/extensionmanager-
extension/examples/listings
/usr/lib/python3/dist-packages/packages/extensionmanager-
extension/examples/listings/main.py
...
/usr/lib/python3/dist-packages/scripts
/usr/lib/python3/dist-packages/scripts/i18n_check.py
<<< END

That also seems to be a mistake.  Perhaps the installation into the package
distribution is messed up?





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

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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 python3-jupyterlab depends on:
ii  node-jupyterlab  4.0.10+ds1+~cs11.25.27-1
ii  

Bug#1060389: systemd: logind: HandlePowerKeyLongPress doesn't appear to work

[наб]

On Wed, Jan 10, 2024 at 03:40:27PM +0100, Michael Biebl wrote:
> Am 10.01.24 um 15:26 schrieb наб:
> > As you can see in my logind.conf,
> > I have re-mapped the power key to suspend,
> > and long-pressing the power key to hibernate.
> > 
> > When I click the power key the machine suspends instantly
> > (and under X I see XF86PowerOff).
> > But this actually happens no matter how long I hold the button for,
> > and hibernation never occurs.
> Maybe your desktop environment intercepts/interprets those keys?
It doesn't:
  $ grep XF86 .config/i3/config
  bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 
@DEFAULT_SINK@ +10% && $refresh_i3status
  bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 
@DEFAULT_SINK@ -10% && $refresh_i3status
  bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute @DEFAULT_SINK@ 
toggle && $refresh_i3status
  bindsym XF86AudioMicMute exec --no-startup-id pactl set-source-mute 
@DEFAULT_SOURCE@ toggle && $refresh_i3status 

And, well, the xev seeing them means i3 didn't eat them.

> Can you confirm the issue when being logged into the kernel console only
> (i.e. no desktop environment running)?
I guess I forgot to note this explicitly:
yes this happens both under X and at a getty.

Best,


signature.asc
Description: PGP signature

Bug#1058031: pygame: FTBFS with Python 3.12

[s3v]

Dear Maintainer,

AssertionError comes from comparing '...' occurrences in
test result output with the number of ran tests.
I've added this code:

    with open('/tmp/debian-tmp', 'a') as f:
    import pprint, copy
    tmp_results = copy.deepcopy(results)
    for k, v in tmp_results.items():
    v['output'] = v['output'].split('\n')
    pprint.pprint(tmp_results, f, indent=2)

at line 292 in test/test_utils/run_tests.py [1]; two dicts and the diff
between Python 3.11 and 3.12 are attached. (Please note different values
for 'num_tests' keys).

Something has been changed in python 3.12 at presenting test results
when there are skipped tests:

(test.py)

import unittest

class FooTest(unittest.TestCase):
    @unittest.skip
    def test_foo(self):
    self.assertTrue(True)

    def test_bar(self):
    self.assertFalse(False)

if __name__ == '__main__':
    unittest.main()


$ python3.11 test.py
.s
--
Ran 2 tests in 0.000s

OK (skipped=1)


$ python3.12 test.py
.s
--
Ran 1 test in 0.000s

OK (skipped=1)


I don't know if this change is intended or it's a bug (I wasn't
able to find references in python 3.12 changelog).

Kind Regards

[1] 
https://sources.debian.org/src/pygame/2.5.2-1.1/test/test_utils/run_tests.py/#L292




3.11-results.tar.gz
Description: application/gzip


3.12-results.tar.gz
Description: application/gzip


diff-results.tar.gz
Description: application/gzip

Bug#1060218: xmobar: cannot run with Wireless plugin

[Ilias Tsitsimpis]

Hi Dominik,

On Sun, Jan 07, 2024 at 07:45PM, Dominik Szmek wrote:
> After removing libiw-dev dependency (#1058738) xmobar fails to run
> with Wireless plugin in the config file.

Xmobar depends on the netlink [1] Haskell library for the Wireless
functionality. Unfortunately this library seems to be unmaintained,
that's why we haven't packaged it for Debian yet. We need someone to
step up and adopt this library, if we are to package it for Debian and
enable the Wireless functionality of xmobar.

[1] https://hackage.haskell.org/package/netlink

Best,

-- 
Ilias

Bug#1055362: Crash when plugging in USB graphics tablet

[Boyuan Yang]

Control: fixed 1055392 wayfire/0.8.0-1

According to the description, this bug only affects wayfire in Debian Bookworm.
Marking accordingly.

Thanks,
Boyuan Yang


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

Bug#1060371: git-buildpackage: feature request: gbp sync

[Otto Kekäläinen]

...
> …skipping binNMUs ?

The "spec" I drafted probably forgot some more cases as well, hence
good to have a issue open for a while to collect feedback/ideas to
further refine the logic and capture corner cases :)

..
> Somewhat related is /usr/share/doc/git-buildpackage/examples/gbp-upload
> which helps to ensure that tags end up in the blessed repo when doing an
> upload.

Thanks for pointing it out, I hadn't read that and other scripts at
https://github.com/agx/git-buildpackage/tree/master/examples before.

Currently in my own workflow I gbp tag and push tags only after the
ftp-master confirmation email arrives and I know the upload was
accepted, so the gbp-upload script is a bit too simplistic for my use.
In general however I am hugely in favour of automatic recurring,
mechanical and error prone Debian packaging work steps like these so
DDs can focus their time on more complex cases. I hope I can
contribute something useful to git-buildpackage.

Thanks Guido for coming up with gbp in the first place! I have been
using it with all of my packages for almost 8+ years now.