Bug#1069869: flash-kernel fails for kernel vmlinux-*

[Heinrich Schuchardt]

Please, review merge request
https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/59

Bug#1069870: linux-image-6.7.7-686-pae: please enable i915 mtl_* modules

[Martin-Éric Racine]

Package: src:linux
Version: 6.7.7-1
Severity: normal


W: Possible missing firmware /lib/firmware/i915/mtl_gsc_1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/mtl_huc_gsc.bin for module i915
W: Possible missing firmware /lib/firmware/i915/mtl_guc_70.bin for module i915


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

Kernel: Linux 6.7.7-686-pae (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.7.7-686-pae depends on:
ih  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod31+20240202-2
ii  linux-base  4.9

Versions of packages linux-image-6.7.7-686-pae recommends:
ii  apparmor 3.0.13-2
ii  firmware-linux-free  20200122-4

Versions of packages linux-image-6.7.7-686-pae suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.12-2~deb13u1
pn  linux-doc-6.7   

Versions of packages linux-image-6.7.7-686-pae is related to:
ii  firmware-amd-graphics 20230625-2
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230625-2
pn  firmware-libertas 
ii  firmware-linux-nonfree20230625-2
ii  firmware-misc-nonfree 20230625-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20230625-2
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1069869: flash-kernel fails for kernel vmlinux-*

[Heinrich Schuchardt]

Package: flash-kernel
Version: 3.107+b1
Severity: normal

Package linux-image-6.7.9-riscv64 installs file /boot/vmlinux-6.7.9-riscv64.

Flash-kernel fails with:

sudo flash-kernel $(uname -r)
Can't find /boot/vmlinuz-6.7.9-riscv64 (see
/tmp/flash-kernel-no-kernel-error.log)

Please, change flash-kernel to accept vmlinux*.

In /usr/share/flash-kernel/functions we find

   kfile="/boot/vmlinuz-$kvers"
   if [ ! -e $kfile ]; then

Changing this to

   kfile="/boot/vmlinuz-$kvers"
   if [ ! -e $kfile ]; then
   kfile="/boot/vmlinux-$kvers"
   fi
   if [ ! -e $kfile ]; then

would be sufficient to resolve the issue.

Best regards

Heinrich

Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 --test-arg

[Julian Gilbey]

On Sat, Apr 20, 2024 at 01:59:57PM +0200, Lucas Nussbaum wrote:
> Source: cpp-httplib
> Version: 0.14.3+ds-1.1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on arm64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_test -- \
> > --timeout-multiplier=3 \
> > --test-args='--gtest_filter=-*_Online'
> > cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb 
> > LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 
> > --test-args=--gtest_filter=-\*_Online
> > ninja: Entering directory `/<>/obj-aarch64-linux-gnu'
> > ninja: no work to do.
> > 1/1 main TIMEOUT900.12s   killed by signal 15 SIGTERM

Hi Andrea,

It looks like it's just that arm64 is slow (as are several other
archs).  Changing the command to read --timeout-multiplier=30 should
fix this FTBFS serious bug and allow cpp-httplib to migrate to
testing.

Best wishes,

   Julian

Bug#1059960: flash-kernel: Please add loong64 binary output for Loongarch

[zhangdandan]

Dear Maintainer,

On Thu, 4 Jan 2024 14:26:16 +0800 yalingfang wrote:

> Source: flash-kernel
> Version: 3.107
> Severity: wishlist
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
>
>
> Dear Maintainer,
>      Currently no loong64 binary output for flash-kernel in Loongarch 
env.

> The buildd link is following:
> https://buildd.debian.org/status/package.php?p=flash-kernel=sid
>
> I have verified and compiled pass by adding loong64 to debian/control
> file in my local env.

We need to update the patch to support loongarch64.
Please consider the patch I attached.
Could you add the loongarch64 support in the next upload?

Thanks,
Dandan Zhang


diff -Nru flash-kernel-3.107/debian/control flash-kernel-3.107/debian/control
--- flash-kernel-3.107/debian/control   2023-04-19 21:02:35.0 +
+++ flash-kernel-3.107/debian/control   2023-04-19 21:12:53.0 +
@@ -11,7 +11,7 @@
 Rules-Requires-Root: no
 
 Package: flash-kernel
-Architecture: arm64 armel armhf riscv64
+Architecture: arm64 armel armhf riscv64 loong64
 Depends: ${misc:Depends},
  devio,
  initramfs-tools (>= 0.92f),
@@ -31,7 +31,7 @@
 Priority: standard
 Package-Type: udeb
 Build-Profiles: 
-Architecture: arm64 armel armhf riscv64
+Architecture: arm64 armel armhf riscv64 loong64
 XB-Subarchitecture: kirkwood orion5x s3c24xx mx5 generic
 Provides: bootable-system
 Depends: cdebconf-udeb, installed-base

Bug#1069867: autopkgtest to test %U substitution in included config files

[Santiago Ruano Rincón]

Source: samba
Severity: wishlist
Tags: patch

Dear samba maintainers,

Please, find attached an autopkgtest that checks if %U variable
substitution in include config files works correctly.

I have include it and verified it works in the recent buster update
https://tracker.debian.org/news/1520926/accepted-samba-2495dfsg-5deb10u5-source-into-oldoldstable/
to confirm it didn't introduce regressions like the one described at:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2003867

Cheers,

  -- Santiago
#!/bin/sh -x
#
# Test to check regressions such as:
# https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2003867

username="smbtest$$"
password="$$"

cat >> /etc/samba/smb.conf <> /etc/samba/${username}.conf  ${userhome}/data
chown ${username}:${username} ${userhome}/data
cd ${userhome}
md5sum data > data.md5

rm -f downloaded-data
echo "Downloading file and comparing its md5"
smbclient //localhost/${username} -U ${username}%${password} -c "get data 
downloaded-data"

mv -f downloaded-data data
md5sum -c data.md5


signature.asc
Description: PGP signature

Bug#1069866: scribus: List AUto-indent and second line tabs both don't work properly

[Gary Dale]

Package: scribus
Version: 1.5.8+dfsg-5
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I was trying to clean up a bulletted list in an existing document. It had used 
manual bullets, 
 line breaks and spaces for item continuations when they didn't fit on the line 
with the bullet.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I removed all the bulletsm line breaks and extra spaces then created a new 
style that used the 
bulletted list feature. This correctly inserted the bullets and allowed me to 
adjust the spacing
between the bullet and the text. However, the Auto-Indent feature simply did 
not work. No matter
what settings I tried, the spillover did not indent.

Next I tried to use the paragraph indent feature. No matter what settings I 
used, I could not 
get it to only indent the spillover lines.

I eventually turned off the spaxcing between the bullet & text, manually 
inserted spaces and
hard line-breaks (that don't trigger a new paragraph) to achieve the look I 
wanted.


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


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

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

Versions of packages scribus depends on:
ii  ghostscript   10.02.1~dfsg-3
ii  libc6 2.37-18
ii  libcairo2 1.18.0-1+b1
ii  libcdr-0.1-1  0.1.7-1
ii  libcups2  2.4.7-1+b1
ii  libfontconfig12.15.0-1.1
ii  libfreehand-0.1-1 0.1.2-3
ii  libfreetype6  2.13.2+dfsg-1+b4
ii  libgcc-s1 14-20240330-1
ii  libgraphicsmagick-q16-3   1.4+really1.3.42-1+b1
ii  libharfbuzz-icu0  8.3.0-2
ii  libharfbuzz-subset0   8.3.0-2
ii  libharfbuzz0b 8.3.0-2
ii  libhunspell-1.7-0 1.7.2+really1.7.2-10+b2
ii  libicu72  72.1-4+b1
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  liblcms2-22.14-2+b1
ii  libmspub-0.1-10.1.4-3+b3
ii  libopenscenegraph161  3.6.5+dfsg1-8+b4
ii  libopenthreads21  3.6.5+dfsg1-8+b4
ii  libpagemaker-0.0-00.0.4-1
ii  libpng16-16t64 [libpng16-16]  1.6.43-5
ii  libpodofo0.9.80.9.8+dfsg-3+b2
ii  libpoppler126 22.12.0-2+b1
ii  libpython3.11 3.11.8-1
ii  libqt5core5a  5.15.10+dfsg-7
ii  libqt5gui55.15.10+dfsg-7
ii  libqt5network55.15.10+dfsg-7
ii  libqt5opengl5 5.15.10+dfsg-7
ii  libqt5printsupport5   5.15.10+dfsg-7
ii  libqt5widgets55.15.10+dfsg-7
ii  libqt5xml55.15.10+dfsg-7
ii  libqxp-0.0-0  0.0.2-1+b3
ii  librevenge-0.0-0  0.0.5-3
ii  libstdc++614-20240330-1
ii  libtiff6  4.5.1+git230720-4
ii  libvisio-0.1-10.1.7-1+b3
ii  libxml2   2.9.14+dfsg-1.3+b2
ii  libzmf-0.0-0  0.0.2-1+b6
ii  scribus-data  1.5.8+dfsg-5
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages scribus recommends:
ii  cups-bsd2.4.7-1+b1
ii  fonts-dejavu2.37-8
ii  fonts-liberation1:2.1.5-3
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  hyphen-sh [hyphen-hyphenation-patterns] 1:3.3.0-4
ii  icc-profiles-free   2.0.1+dfsg-1.1
ii  xfonts-scalable 1:1.0.3-1.3

Versions of packages scribus suggests:
ii  icc-profiles   2.1-2
pn  scribus-doc
pn  scribus-template   
ii  texlive-latex-recommended  2023.20240207-1

-- no debconf information

Bug#1069865: scribus: Importing PDFs that contain PNG images appears to leave a border around the PNG image

[Gary Dale]

Package: scribus
Version: 1.5.8+dfsg-5
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I have a template that allows me to create a document divided into 3 equal 
columns 
for narrow or 3-fold flyers (the ones you may see in a literature rack). In 
this case
I use the same image for all 3 panels on the page for cutting after printing.

I create the content as a PDF file with the correct 1/3 page dimensions then 
import it into the 3 sections of the template as an image frame. However I 
noticed
that the imported PDFs were showing a thin border around the PNG file they 
contained
that was not visible in when the source PDF is viewed directly.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I verified that I was importing the correct file, that the source didn't 
contain the
border, and that it wasn't and older version somehow cached  in the .sla 
template file.

   * What was the outcome of this action?
THe border is still there,

   * What outcome did you expect instead?
The importing of a PDF should dispaly the PDF as it would in any other viewer.

NOTES: the source .sla for the PDF I imported is a modified version of one I've 
been
using for years, updating it as needed. This time I added a QR code image to 
it. 

I also noted the border around a JPEG image but this disappeared when I set the 
image fill colour property to none. The line colour property was also none. I 
note that I cannot actually remove the line nor set its thickness to 0. Anyway,
the same thing didn't remove the border from the PNG QR code image.

The workaround was to export the .sla to a .png file instead of to a PDF. While
this worked, it left the full-page .sla and the exported PDF a lot larger than 
when 
I simply used PDFs.

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


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

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

Versions of packages scribus depends on:
ii  ghostscript   10.02.1~dfsg-3
ii  libc6 2.37-18
ii  libcairo2 1.18.0-1+b1
ii  libcdr-0.1-1  0.1.7-1
ii  libcups2  2.4.7-1+b1
ii  libfontconfig12.15.0-1.1
ii  libfreehand-0.1-1 0.1.2-3
ii  libfreetype6  2.13.2+dfsg-1+b4
ii  libgcc-s1 14-20240330-1
ii  libgraphicsmagick-q16-3   1.4+really1.3.42-1+b1
ii  libharfbuzz-icu0  8.3.0-2
ii  libharfbuzz-subset0   8.3.0-2
ii  libharfbuzz0b 8.3.0-2
ii  libhunspell-1.7-0 1.7.2+really1.7.2-10+b2
ii  libicu72  72.1-4+b1
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  liblcms2-22.14-2+b1
ii  libmspub-0.1-10.1.4-3+b3
ii  libopenscenegraph161  3.6.5+dfsg1-8+b4
ii  libopenthreads21  3.6.5+dfsg1-8+b4
ii  libpagemaker-0.0-00.0.4-1
ii  libpng16-16t64 [libpng16-16]  1.6.43-5
ii  libpodofo0.9.80.9.8+dfsg-3+b2
ii  libpoppler126 22.12.0-2+b1
ii  libpython3.11 3.11.8-1
ii  libqt5core5a  5.15.10+dfsg-7
ii  libqt5gui55.15.10+dfsg-7
ii  libqt5network55.15.10+dfsg-7
ii  libqt5opengl5 5.15.10+dfsg-7
ii  libqt5printsupport5   5.15.10+dfsg-7
ii  libqt5widgets55.15.10+dfsg-7
ii  libqt5xml55.15.10+dfsg-7
ii  libqxp-0.0-0  0.0.2-1+b3
ii  librevenge-0.0-0  0.0.5-3
ii  libstdc++614-20240330-1
ii  libtiff6  4.5.1+git230720-4
ii  libvisio-0.1-10.1.7-1+b3
ii  libxml2   2.9.14+dfsg-1.3+b2
ii  libzmf-0.0-0  0.0.2-1+b6
ii  scribus-data  1.5.8+dfsg-5
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages scribus recommends:
ii  cups-bsd2.4.7-1+b1
ii  fonts-dejavu2.37-8
ii  fonts-liberation1:2.1.5-3
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  hyphen-sh [hyphen-hyphenation-patterns] 1:3.3.0-4
ii  icc-profiles-free   2.0.1+dfsg-1.1
ii  xfonts-scalable 1:1.0.3-1.3

Versions of packages scribus suggests:
ii  icc-profiles   2.1-2
pn  scribus-doc
pn  scribus-template   
ii  texlive-latex-recommended  2023.20240207-1

-- no debconf information

Bug#1069864: busybox: Please enable "install" applet

[Robert Paciorek]

Package: busybox
Version: 1:1.35.0-4+b3
Severity: wishlist
Tags: patch

Hi,

BusyBox can provide a simple version of "install" command
(https://busybox.net/downloads/BusyBox.html#install).

Unfortunately, in the package configuration, the options responsible
for enabling this applet are not set:

# CONFIG_INSTALL is not set
# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set

(for all 3 packages - regular, static and udeb)

This is a quite frequently used command that is part of coreutils,
so it is worth making it available in the minimal environment
provided by BusyBox.

Simple patch (for regular package) attached.

Regards,
Robert Paciorek


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages busybox depends on:
ii  libc6  2.36-9+deb12u4

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information
--- busybox-1.36.1.org/debian/config/pkg/deb2023-11-13 13:46:07.0 
+
+++ busybox-1.36.1/debian/config/pkg/deb2024-04-24 02:07:05.532609382 
+
@@ -265,8 +265,8 @@
 CONFIG_HOSTID=y
 CONFIG_ID=y
 CONFIG_GROUPS=y
-# CONFIG_INSTALL is not set
-# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set
+CONFIG_INSTALL=y
+CONFIG_FEATURE_INSTALL_LONG_OPTIONS=y
 CONFIG_LINK=y
 CONFIG_LN=y
 CONFIG_LOGNAME=y

Bug#1069863: ITP: python-opt-einsum -- Optimized Einsum is a tensor contraction order optimizer

[Yogeswaran Umasankar]

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

* Package name: python-opt-einsum
  Version : 3.3.0
  Upstream Contact: Daniel Smith 
* URL : https://github.com/dgasmith/opt_einsum
* License : Expat
  Programming Lang: Python
  Description : Optimized Einsum is a tensor contraction order optimizer

Optimized einsum can significantly reduce the overall execution time
 of einsum-like expressions by optimizing the expression's contraction
 order and dispatching many operations to canonical BLAS, cuBLAS, or
 other specialized routines. Planned to maintain it under DPT, need
 sponsorship.

Bug#1060083: cgroupfs-mount: diff for NMU version 1.4+nmu1

[Tianon Gravi]

On Sun, 21 Apr 2024 at 17:03, Chris Hofstaedtler  wrote:
> I've prepared an NMU for cgroupfs-mount (versioned as 1.4+nmu1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

Sorry for the delay in getting to this!  Your NMU looks sane, thank you!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Craig Small]

Hi Andreas,
  Congratulations on your appointment, hopefully you can find a way to
balance work, life and DPL because it seems like a very busy role.

Not sure if Sean/the TC have reached out yet but in your first DPL email
you mentioned checking on the various teams to see what they need you to
do, here's one thing.

No idea what the administrative stuff Sean is talking about, I guess I'll
find out soon.

 - Craig


On Sat, 13 Apr 2024 at 13:47, Sean Whitton  wrote:

> Ping again.  Thanks.
>
> On Thu 28 Mar 2024 at 01:33pm +08, Sean Whitton wrote:
>
> > Hello,
> >
> > On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote:
> >
> >> The vote has concluded.  The result is that the Technical Committee
> >> recommends that Craig Small  be appointed by the Debian Project
> >> Leader to the Technical Committee.
> >>
> >> Jonathan, over to you.
> >
> > Quick ping about this.  The appointment holds up some administrative
> > stuff for us.  Thanks.
>
> --
> Sean Whitton
>

Bug#1069828: [debian trixie] [package procps] w segmentation fault

[Craig Small]

Control: forwarded -1 https://gitlab.com/procps-ng/procps/-/issues/301
Control: tags -1 fixed-upstream

On Thu, 25 Apr 2024 at 22:36, David  wrote:

> Hello, it seems there is a bug in the debian package "procps" with the
> "w"utility.
> it produce a segfault when using the "-s" argument.
> I tried download and compile from source, and the bug is not present.
> it is only present with the debian system package (debian trixie).
>
If you enabled systemd and compiled 4.0.4 you would probably get the same
result.
The issue is the utmp structure doesn't get filled in with the short
options and there is a null pointer.

The next procps release will have the fix at
https://gitlab.com/procps-ng/procps/-/commit/79042e07fab9956135a21b1df7a69d1fbde7ef79
I'll leave this Debian bug open until 4.0.5 makes it into Debian.

 - Craig

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Sam Hartman]

> "Lukas" == Lukas Grässlin  writes:

Lukas> We have a scenario where we need to disable reverse lookups for 
Lukas> canonicalization in Kerberos as the customer's PTR records are not 
Lukas> consistent and lead to wrongly requested SPNs otherwise (see 
Lukas> 
https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-dns-mismatches)

How are you actually triggering the GSS-API authentication?
ldapsearch in all cases?
And you are confident that libkrb5 is triggering the reverse lookup not
your application?
(I realize that you may be using the same application on Debian and RH,
but there could be differences in the application code).

Bug#1069862: blktrace: FTBFS on ppc64el in Ubuntu (-O3?) due to wrong code analysis

[Steve Langasek]

Package: blktrace
Version: 1.2.0-5
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch

Dear maintainers,

In Ubuntu, we found that blktrace was failing to rebuild on ppc64el because
the compiler was wrongly identifying problems with format string handling:

[...]
gcc -o blkparse.o -c -D__DEB_CANARY_CPPFLAGS_4e732ced3463d06de0ca9a15b6153677__ 
-Wdate-time -D_FORTIFY_SOURCE=3 -g -O3 -Werror=implicit-function-declaration 
-Werror=array-bounds -Werror=clobbered -Werror=volatile-register-var 
-D__DEB_CANARY_CFLAGS_4e732ced3463d06de0ca9a15b6153677__ 
-fno-omit-frame-pointer -ffile-prefix-map=/<>=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-fno-stack-clash-protection 
-fdebug-prefix-map=/<>=/usr/src/blktrace-1.2.0-5build1 -Wall 
-Wextra -Wno-shadow -Werror -g -Wl,-Bsymbolic-functions 
-Wl,-z,deb-canary-4e732ced3463d06de0ca9a15b6153677 -flto=auto -ffat-lto-objects 
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -D_GNU_SOURCE -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 blkparse.c
blkparse.c: In function ‘main’:
blkparse.c:376:56: error: ‘%s’ directive argument is null 
[-Werror=format-overflow=]
  376 | fprintf(stderr, "Out of memory, device %s (%d)\n", 
name, size);
  |^~
[...]
blkparse.c:1885:68: error: ‘):’ directive output may be truncated writing 2 
bytes into a region of size between 1 and 41 [-Werror=format-truncation=]
[...]

  (https://launchpad.net/ubuntu/+source/blktrace/1.2.0-5build1/+build/27931723)

It's possible/likely that this build failure is caused by the use of -O3 by
default for ppc64el builds in Ubuntu; so the attached patch, while it fixes
the problem in Ubuntu and should be harmless in Debian, may not be something
you want to apply as-is.  Perhaps you would prefer to use $(filter -O3,...)
instead?

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru blktrace-1.2.0/debian/control blktrace-1.2.0/debian/control
--- blktrace-1.2.0/debian/control   2024-03-16 02:13:36.0 -0700
+++ blktrace-1.2.0/debian/control   2024-03-22 19:17:48.0 -0700
@@ -1,8 +1,7 @@
 Source: blktrace
 Section: utils
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Bas Zoetekouw 
+Maintainer: Bas Zoetekouw 
 Uploaders: Dmitry Smirnov 
 Build-Depends:
 debhelper (>= 11),
diff -Nru blktrace-1.2.0/debian/rules blktrace-1.2.0/debian/rules
--- blktrace-1.2.0/debian/rules 2019-02-23 14:17:21.0 -0800
+++ blktrace-1.2.0/debian/rules 2024-03-22 19:17:33.0 -0700
@@ -10,6 +10,9 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+all qa=+all 
reproducible=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+ifeq ($(DEB_HOST_ARCH),ppc64el)
+  export DEB_CFLAGS_MAINT_APPEND = -Wno-error=format-overflow 
-Wno-error=format-truncation
+endif
 # make sure TeX/dvipdfm generates reproducable builds
 export FORCE_SOURCE_DATE=1
 

Bug#1069846: dpkg: dpkg-deb fails to build package w/ incomplete changelog entry

[Guillem Jover]

Hi!

On Thu, 2024-04-25 at 18:42:50 +0100, Rainer Weikusat wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: minor
> Tags: patch
> X-Debbugs-Cc: rweiku...@cyberadapt.com

> The /usr/share/dpkg/pkg-info.mk file invokes dpkg-parsechangelog to
> set the SOURCE_DATE_EPOCH environment variable to the date of the
> last changelog entry for the package being built. If this changelog
> entry hasn't yet been finalized with a date, eg, if it looks like this
> (actual example):
> 
> apache2 (2.4.59-ca001-1-deb12u2) unstable; urgency=medium
> 
>   * updated to Debian 12 sources
> 
>  --
> 
> SOURCE_DATE_EPOCH is set to an empty string. This causes the
> parse_timestamp routine in build.c to fail and print the (rather
> confusing) error message:
> 
> unable to parse timestamp '': Success
> 
> (Success being printed because errno isn't set). Package generation then
> fails because dpkg-deb afterwards terminates with an exit code of 2.
> 
> Building such packages may not be a supported feature but I've been
> using it for dev builds of packages for about 20 years (and plan to
> continue doing so). The included patch avoids the issue by ignoring the
> value of SOURCE_DATA_EPOCH when it's empty.

Thanks for the report and the patch! I've queued the attached patch,
in addition to another one improving the error messages to avoid the
above confusing output, and I'll also add yet another one refactoring
the functions (which I had pending on doing).

Thanks,
Guillem
From 93e7b2268fabc35d754ffe6389b5172b5917eb8c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 25 Apr 2024 22:44:19 +0200
Subject: [PATCH] src: Check whether SOURCE_DATE_EPOCH is set before parsing it

The dpkg-deb and dpkg-split program try to parse this environment
variable to use it for their timestamps inside files to generate
reproducible artifacts. But when the environment variable is set
but empty then the parsing function fails with a confusing error
message.

This is an issue when building a package directly via debian/rules
that uses the pkg-info.mk fragment file, because that one tries to
set the SOURCE_DATE_EPOCH and can end up setting it to an empty value
if the changelog contains an unfinished trailer. This is not an issue
when using dpkg-buildpackage, though because the code there will
fallback to use the current time if it there is no value from the
changelog.

Closes: #1069846
Based-on-patch-by: Rainer Weikusat 
---
 src/deb/build.c   | 2 +-
 src/split/split.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/deb/build.c b/src/deb/build.c
index 1f0c050ee..16f2bafdf 100644
--- a/src/deb/build.c
+++ b/src/deb/build.c
@@ -597,7 +597,7 @@ do_build(const char *const *argv)
   m_output(stdout, _(""));
 
   timestamp_str = getenv("SOURCE_DATE_EPOCH");
-  if (timestamp_str)
+  if (str_is_set(timestamp_str))
 timestamp = parse_timestamp(timestamp_str);
   else
 timestamp = time(NULL);
diff --git a/src/split/split.c b/src/split/split.c
index 771de626c..04d41b281 100644
--- a/src/split/split.c
+++ b/src/split/split.c
@@ -162,7 +162,7 @@ mksplit(const char *file_src, const char *prefix, off_t maxpartsize,
 	version = versiondescribe(>available.version, vdew_nonambig);
 
 	timestamp_str = getenv("SOURCE_DATE_EPOCH");
-	if (timestamp_str)
+	if (str_is_set(timestamp_str))
 		timestamp = parse_timestamp(timestamp_str);
 	else
 		timestamp = time(NULL);
-- 
2.43.0

Bug#1069861: skyfield: please remove the extraneous python3-mock dependency

[Alexandre Detiste]

Source: skyfield
Version: 1.48+ds-1
Severity: normal

Dear Maintainer,

Upstream has fully switched to newer unittest.mock in skyfield/charting.py;
I will send a PR for further cleanup.

unittest.mock is part of the standard Python library.

Greetings


tchet@quieter:/tmp/skyfield$ grep mock -r -C 2
.github/workflows/ci.yml:python -m pip install mock pandas
--
debian/control:   python3-mock ,
--
requirements.txt-html5lib==1.0.1
requirements.txt-lxml==4.9.1
requirements.txt:mock==2.0.0
requirements.txt-numpy==1.15.4
requirements.txt-matplotlib==3.3.0
--
skyfield/charting.py:from unittest.mock import patch
--
skyfield/tests/test_io.py-try:
skyfield/tests/test_io.py:from unittest.mock import patch
skyfield/tests/test_io.py-except ImportError:
skyfield/tests/test_io.py:from mock import patch

Bug#1069860: lightdm-gtk-greeter: should not recommend the transitional package policykit-1

[Vincent Lefevre]

Package: lightdm-gtk-greeter
Version: 2.0.9-1
Severity: normal

lightdm-gtk-greeter 2.0.9-1 has

  Recommends: [...], polkitd | policykit-1

policykit-1 is now a transitional package. lightdm-gtk-greeter should
not recommend it (even in an OR dependency), otherwise apt or aptitude
cannot propose its removal.

This is even more important now that deborphan has been removed from
Debian.

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

Kernel: Linux 6.6.15-amd64 (SMP w/16 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 lightdm-gtk-greeter depends on:
ii  libayatana-ido3-0.4-00.10.1-1+b2
ii  libayatana-indicator3-7  0.9.4-1
ii  libc62.37-18
ii  libcairo21.18.0-3+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b3
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  liblightdm-gobject-1-0   1.32.0-5
ii  libx11-6 2:1.8.7-1

Versions of packages lightdm-gtk-greeter recommends:
ii  adwaita-icon-theme  46.0-1
ii  desktop-base12.0.6+nmu1
ii  gnome-themes-extra  3.28-2+b2
ii  policykit-1 124-2
ii  polkitd 124-2

lightdm-gtk-greeter suggests no packages.

-- Configuration Files:
/etc/lightdm/lightdm-gtk-greeter.conf changed [not included]

-- no debconf information

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

Bug#1069859: atop: Fix atop for 64-bit time_t on arm

[Steve Langasek]

Package: atop
Version: 2.10.0-2
Severity: grave
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hi Marc,

Although atop currently builds successfully on armhf and armel, it is broken
at runtime because it tries to use a time_t in a format string which now no
longer uses the correct size for the data.  This was found in Ubuntu via
autopkgtests (unfortunately, Debian does not run autopkgtests for binNMUs):

358s /tmp/autopkgtest.Nzaczp/build.Xps/src/debian/tests/01-numcpus: line 15:  
1136 Segmentation fault  (core dumped) atop -P cpu 5 1 1>&2
 
Please see attached a patch that fixes this issue.  It has been uploaded to
Ubuntu.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru atop-2.10.0/debian/patches/64-bit-time-t-compat.patch 
atop-2.10.0/debian/patches/64-bit-time-t-compat.patch
--- atop-2.10.0/debian/patches/64-bit-time-t-compat.patch   1969-12-31 
16:00:00.0 -0800
+++ atop-2.10.0/debian/patches/64-bit-time-t-compat.patch   2024-03-22 
11:11:06.0 -0700
@@ -0,0 +1,22 @@
+Description: compatibility with 64-bit time_t
+Author: Steve Langasek 
+Forwarded: no
+Last-Update: 2024-03-22
+
+Index: atop-2.10.0/parseable.c
+===
+--- atop-2.10.0.orig/parseable.c
 atop-2.10.0/parseable.c
+@@ -214,10 +214,10 @@
+   convdate(curtime, datestr);
+   convtime(curtime, timestr);
+ 
+-  snprintf(header, sizeof header, "%s %s %ld %s %s %d",
++  snprintf(header, sizeof header, "%s %s %lld %s %s %d",
+   labeldef[i].label,
+   utsname.nodename,
+-  curtime,
++  (long long)curtime,
+   datestr, timestr, numsecs);
+ 
+   /*
diff -Nru atop-2.10.0/debian/patches/series atop-2.10.0/debian/patches/series
--- atop-2.10.0/debian/patches/series   2024-01-14 12:18:53.0 -0800
+++ atop-2.10.0/debian/patches/series   2024-03-22 11:10:13.0 -0700
@@ -15,3 +15,4 @@
 no-atopgpud
 handle-default-file
 default
+64-bit-time-t-compat.patch

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Lukas Grässlin]

Package: libkrb5-3 


Version: 1.20.1-2+deb12u1
Severity: normal
X-Debbugs-Cc: lukas.graess...@adfinis.com

We have a scenario where we need to disable reverse lookups for 
canonicalization in Kerberos as the customer's PTR records are not 
consistent and lead to wrongly requested SPNs otherwise (see 
https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-dns-mismatches)


Therefore we have set "rdns = false" in /etc/krb5.conf as follows:

# cat /etc/krb5.conf

[libdefaults]
udp_preference_limit = 0
default_realm = EMEA.EXAMPLE.COM
rdns = false

However this setting seems to get ignored for some reason. I tried to do 
some debugging and comparisons as we don't have the same issue for 
example on a RHEL8 (using krb5-libs-1.18.2-26.el8_9.x86_64) machine.


On those RHEL machines the setting seems to do exactly what it's 
supposed to, in fact I can reproduce the issue we have on Ubuntu on RHEL 
as well if I remove the "rdns = false" line from the configuration.


Kerberos authentication (in our test we use a simple ldapsearch with 
GSSAPI auth) fails then randomly as it sometimes gets a wrong SPN due to 
using a wrong PTR for canonicalization.


On our Ubuntu 22.04 LTS (with libkrb5-3:amd64 1.19.2-2ubuntu0.3) however 
the setting does not seem to have any effect. I then re-did the same 
test with Debian oldstable, stable and sid as well, all with the exact 
same result.


I actually ran a tcpdump while trying to do a Kerberos auth with the 
"rdns = false" setting in place and I can still see the reverse lookup 
being performed in the tcpdump (I anonymized some things so don't get 
confused about the IPs):


10:47:58.382684 IP 1.2.3.4.55001 > 123.123.123.123.53: 12962+ [1au] A? 
domaincontroller01.emea.example.com. (55)
10:47:58.382809 IP 1.2.3.4.37669 > 123.123.123.123.53: 38376+ [1au] 
? domaincontroller01.emea.example.com. (55)

10:47:58.412041 IP 123.123.123.123.53 > 1.2.3.4.37669: 38376* 0/1/1 (143)
10:47:58.412564 IP 123.123.123.123.53 > 1.2.3.4.55001: 12962* 1/9/10 A 
5.6.7.8 (602)
10:47:58.442326 IP 1.2.3.4.51232 > 123.123.123.123.53: 16995+ [1au] PTR? 
8.7.6.5.in-addr.arpa. (55)
10:47:58.471669 IP 123.123.123.123.53 > 1.2.3.4.51232: 16995 2/2/3 PTR 
emea.example.com., PTR DOMAINCONTROLLER.emea.example.com. (238)


As you see there it does the PTR lookup and retrieves two entries 
(emea.example.com and DOMAINCONTROLLER.emea.example.com)


If I do the same test on the RHEL8 machine I can actually see in tcpdump 
that with the "rdns = false" setting the reverse lookup is correctly NOT 
performed.


I am a bit puzzled why this is the case as I have not seen other people 
reporting it (maybe everyone else has their reverse DNS under control 
;)) even though as said in a quick test I was also able to get the same 
wrong result with multiple Debian releases and the mentioned Ubuntu release.


The only thing I've found in the past where this exact issue was 
mentioned was many years ago: 
https://mailman.mit.edu/pipermail/krb5-bugs/2011-June/008684.html


However this has been fixed ever since. I have not done yet any actual 
code comparison with the version that RHEL uses, also I'm not sure if 
the issue actually really exists in libkrb5 itself or if it might be a 
sideeffect from some other lib.


How to reproduce on your own:
Even if you don't have erroneous reverse DNS entries you could still try 
to reproduce it by just looking at tcpdump and checking if you see 
reverse lookups performed with and without the option.


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

Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-15-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash

Versions of packages libkrb5-3 depends on:
ii  libc62.36-9+deb12u6
ii  libcom-err2  1.47.0-2
ii  libk5crypto3 1.20.1-2+deb12u1
ii  libkeyutils1 1.6.3-2
ii  libkrb5support0  1.20.1-2+deb12u1
ii  libssl3  3.0.11-1~deb12u2

Versions of packages libkrb5-3 recommends:
ii  krb5-locales  1.20.1-2+deb12u1

Versions of packages libkrb5-3 suggests:
pn  krb5-doc   
ii  krb5-user  1.20.1-2+deb12u1

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068365: FTBFS on mips64el in lsfd/mkfds-multiplexing-pselect6 test et al

[Diederik de Haas]

Control: forwarded -1 https://github.com/util-linux/util-linux/issues/2867 
https://lore.kernel.org/all/20240328-mips_save_syscall-v1-1-9e1d62d69...@flygoat.com/

On Thursday, 25 April 2024 22:10:12 CEST Chris Hofstaedtler wrote:
> reassign 1068365 src:linux
> affects 1068365 src:util-linux
> thanks

It's already marked as 'upstream' and 'fixed-upstream', so the tags are fine.

Upstream commit 4370b673ccf240bf7587b0cb8e6726a5ccaf1f17 titled
"MIPS: scall: Save thread_info.syscall unconditionally on entry"

That commit is part of 6.9-rc4 and autoselected for 6.8, 6.1 and 5.10
on 2024-04-22 by Sasha Levin, but I haven't seen them in their
respective Stable queues yet?


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

Bug#1069857: google-i18n-address: please drop python3-mock dependency

[Alexandre Detiste]

Source: google-i18n-address
Version: 2.4.0-2
Severity: normal

Dear Maintainer,

python3-mock is an obsolete library we try to slowly remove from Debian.

This project will prefer unittest.mock
that has been part of the standard library since Python 3.3

Greetings


tests/test_downloader.py-try:
tests/test_downloader.py:from unittest import mock
tests/test_downloader.py-except ImportError:
tests/test_downloader.py:import mock
--
debian/control- dh-python,
debian/control- python3-all,
debian/control: python3-mock ,
debian/control- python3-pytest ,
debian/control- python3-pytest-cov ,

Bug#1069856: port-for: please drop python3-mock build depedency

[Alexandre Detiste]

Source: port-for
Version: 0.7.2-1
Severity: normal

Dear Maintainer,

Please remove python3-mock from d/control;
this library is obsolete and upstream
has switched to newer unittest.mock
from the standard library.

Greetings



tchet@quieter:/tmp/port-for$ grep mock -r
debian/control: python3-mock,
tests/test_cases.py:from unittest import mock

Bug#1069855: ark may remove archive on SMB share

[Andreas B. Mundt]

Source: ark
Version: 4:23.08.1-2
Severity: normal

Dear Maintainer,

when adding a file to an archive on a (samba) SMB share, the archive 
disappears completely:

In '/etc/fstab':
  //192.168.122.184/share/ /media/sambashare cifs 
user,nobrl,user=andi,password=123 0 0

Mount the share, then:

  cd /media/sambashare/
  tar zcf test.tar.gz /usr/share/doc/cifs-utils
  ls test.tar.gz
  …
  ark --add-to test.tar.gz /usr/share/images/desktop-base/desktop-grub.png
  ls test.tar.gz
  ls: cannot access 'test.tar.gz': No such file or directory

A share provided by ksmbd does not show show the issue.
This has been found when trying to understand the issue reported in [1]. 

Thanks and best regards,

  Andi


[1] https://bugs.debian.org/1069835

mount: 
//192.168.122.157/homedirs on /media/ksmbdshare type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=smbuser,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.122.157,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=ansible,user=smbuser)

//192.168.122.184/homes on /media/sambashare type cifs 
(rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=andi,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.122.184,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,nobrl,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,user=ansible,user=andi)

-- 

GPG key: 4096R/617B586D 2010-03-22 Andreas B. Mundt--
   Andreas B. Mundt--
   Andreas B. Mundt--
   Andreas B. Mundt--

 938A 5CEE 1E29 0DE2 55D9  AC98 B01F EA84 617B 586D

 https://keys.openpgp.org/

Bug#1069842: rjava: FTBFS: /usr/bin/ld: cannot find -ldeflate: No such file or directory

[Santiago Vila]

found 1069842 4.4.0-1
affects 1069842 + src:rjava
thanks

Thanks for the quick reply!

[ I'm adding the affects so that the bug is shown on the web page
for src:rjava. This helps to avoid duplicates, as there are more people
reporting FTBFS bugs ]

Thanks.

Bug#1069844: More debug info

[Alex Bennée]

Alex Bennée  writes:

> Julian Andres Klode  writes:
>
>> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
>>> 
>>> Continuing to debug on QEMU it seems there is an incompatibility with
>>> the images and the peloader (which overrides the normal efi loader):
>>> 

>
>> In the error case you can see though, that one of the section
>> addresses in the Xen binary to be relocated points into the (PE)
>> header of the binary, which obviously seems wrong.
>>
>> So go check your PE sections and check which one is wrong?
>
> Is there any tooling for examining PE sections?

Nothing really jumps out from objdump:

1:08:50 [root@debian-arm64:~] # objdump -h /boot/xen

  /boot/xen: file format pei-aarch64-little

  Sections:
  Idx Name  Size  VMA   LMA   File off  Algn
0 .reloc        2**0
ALLOC, LOAD, READONLY, DATA
1 .text 00107ea8  0160  0160  0160  2**4
CONTENTS, ALLOC, LOAD, CODE
  21:08:53 [root@debian-arm64:~] # objdump -h /boot/vmlinuz

  /boot/vmlinuz: file format pei-aarch64-little

  Sections:
  Idx Name  Size  VMA   LMA   File off  Algn
0 .text 018c  0001  0001  0001  2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0090a200  018d  018d  018d  2**2
CONTENTS, ALLOC, LOAD, DATA


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Bug#1069854: O: universal-detector -- library for character set autodetection

[Bastian Germann]

Package: wnpp

Hereby I orphan the package universal-detector.
It is an Objective-C wrapper for the uchardet package by Mozilla.
Its intended use is filename encoding detection.

Bug#1069853: pbuilder: add support for '--debootstrap mmdebstrap'

[Holger Levsen]

Package: pbuilder
Version: 0.231
Severity: wishlist

Dear Maintainer,

please add support for '--debootstrap mmdebstrap'.


-- 
cheers,
Holger

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

figures don't lie, but liars figure.


signature.asc
Description: PGP signature

Bug#1069852: RFS: minidb/2.0.8-1 -- simple SQLite3-based store for Python objects

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : minidb
   Version  : 2.0.8-1
   Upstream contact : Thomas Perl 
 * URL  : https://thp.io/2010/minidb/
 * License  : ISC
 * Vcs  : https://salsa.debian.org/mwerlen/minidb
   Section  : python

The source builds the following binary packages:

  python3-minidb - simple SQLite3-based store for Python objects

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/minidb/minidb_2.0.8-1.dsc

Changes since the last upload:

 minidb (2.0.8-1) unstable; urgency=medium
 .
   * New upstream release
   * Remove patch now included upstream

Regards,

Bug#1069844: More debug info

[Alex Bennée]

Julian Andres Klode  writes:

> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
>> 
>> Continuing to debug on QEMU it seems there is an incompatibility with
>> the images and the peloader (which overrides the normal efi loader):
>> 
>>   Thread 1 hit Breakpoint 3.2, grub_load_normal_mode () at 
>> ../../../grub-core/kern/main.c:241
>>   241 in ../../../grub-core/kern/main.c  
>>  
>>  
>>   (grub gdb) hbreak do_load_image
>>  
>>  
>>   Hardware assisted breakpoint 4 at 0x23bdf0e00: do_load_image. (2 
>> locations)   
>>
>>   (grub gdb) c   
>>  
>>  
>>   Continuing.
>>  
>>  
>>   add symbol table from file "bli.module" at 
>>  
>>  
>>   .text_addr = 0x23ba772e0   
>>  
>>  
>>   .bss_addr = 0x0
>>  
>>  
>>   .module_license_addr = 0x23ba7764a 
>>   .data_addr = 0x0   
>>  
>>  
>>   .rodata.str1.1_addr = 0x23ba77560  
>>  
>>  
>>   .rodata_addr = 0x23ba77550 
>>  
>>  
>>   add symbol table from file "xen_boot.module" at
>>  
>>  
>>   .text_addr = 0x23bcef3c0   
>>  
>>  
>>   .bss_addr = 0x23bcf0370
>>  
>>  
>>   .module_license_addr = 0x23bcf035e 
>>
>>   .data_addr = 0x0   
>>
>>   .rodata.str1.1_addr = 0x23bcefff8
>> 
>>   Thread 1 hit Breakpoint 4.1, do_load_image (boot_policy=0 '\000', 
>> parent_image_handle=0x23e889f18, file_path=0x237d1bce0, 
>> source_buffer=0x239f0, source_size=1081352, 
>>   image_handle=0x4766c498) at ../../../grub-core/loader/efi/peimage.c:745
>>   warning: 745../../../grub-core/loader/efi/peimage.c: No such file or 
>> directory
>>   (grub gdb) hbreak grub_error
>>   Hardware assisted breakpoint 5 at 0x6db0: grub_error. (2 locations)
>>   (grub gdb) c
>>   Continuing.
>> 
>>   Thread 1 hit Breakpoint 4.2, 0x00023bdf0e4c in do_load_image 
>> (boot_policy=, parent_image_handle=, 
>> image_handle=, 
>>   source_size=, source_buffer=, 
>> file_path=) at ../../../grub-core/loader/efi/peimage.c:751
>>   751 in ../../../grub-core/loader/efi/peimage.c
>>   (grub gdb) c
>>   Continuing.
>> 
>>   Thread 1 hit Breakpoint 5.2, grub_error (n=GRUB_ERR_BAD_OS, 
>> fmt=0x23bdf1703 "section inside header") at ../../../grub-core/kern/err.c:41
>>   warning: 41 ../../../grub-core/kern/err.c: No such file or directory
>>   (grub gdb) bt
>>   #0  grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 "section inside 
>> header") at ../../../grub-core/kern/err.c:41
>>   #1  0x00023bdf0e34 in do_load_image (boot_policy=, 
>> parent_image_handle=, file_path=, 
>> source_buffer=, 
>>   source_size=, image_handle=) at 
>> ../../../grub-core/loader/efi/peimage.c:747
>>   #2  0x00023bedabdc in grub_arch_efi_linux_boot_image (addr=9561964544, 
>> size=1081352, 
>>   args=0x23bbb8b00 "placeholder dom0_mem=4G,max:4G loglvl=all 
>> guest_loglvl=all no-real-mode edd=off") at 
>> ../../../grub-core/loader/efi/linux.c:210
>>   #3  0x00023bff41bc in grub_loader_boot 

Bug#1069851: ITP: python-calendra -- Worldwide holidays and working days helper and toolkit

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-calendra
  Version : 7.9.0
  Upstream Contact: Jason R. Coombs 
* URL : https://github.com/jaraco/calendra
* License : Expat
  Programming Lang: Python
  Description : Worldwide holidays and working days helper and toolkit

 Calendra is a Python module that offers classes able to handle calendars, list
 legal / religious holidays and gives working-day-related computation functions.
 It is a fork of Workalendar designed to be more extensible and introspectable,
 adding interfaces where Workalendar is philosophically opposed for the sake of
 simplicity.
 .
 What can Calendra do that Workalendar cannot?
  * Provides descriptions for holidays for the "day indicated" for each Holiday
(such as '3rd Monday in August').
  * Keeps distinct the indicated and observed dates for Holidays, such that it's
possible to determine on what day a given holiday is observed.
  * Allows the number of Holidays in a calendar year to be counted.
Consolidates observance logic in the core code rather than requiring each
calendar implementation to implement its own.

This is a fork of workalendar and I intend to maintain it as part of DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmYqrfkbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqb+sH/j4jWmToO9OgNHs/ylPu
94Uf4n75Opms3G7gWy45qs8+ZDAfTFBgHiWNF5RvbugvBBSMDGm0nhCK9rYaO6e6
SLkguvk9iv1XrpC7sDiPrCylvzGbHPu5ZXyhOGEKl+rZroS4bAfxdTADZN/nRmuc
8YcQKsNSndaEl2WeRmEM+LjkMX3KqLy3RHvF6IP2bnhn4MDFee1ONX6xKUUetCoy
79L80bx+MVuzCvcYUf+eVxuv3cf+DtZjOIY/EC2WaxOXv/yoIQPvCLzg/pLM1ecR
5f+NNKKO1t6ZpOP85lVQwiZws4HRJv2iE4spRXHhUs/d7NRVl/HgJYTdfBW8UxWr
jU0=
=tvyi
-END PGP SIGNATURE-

Bug#1069727: libsequoia-octopus-librnp: Thunderbird integration autopkgtests

[Holger Levsen]

On Tue, Apr 23, 2024 at 10:02:13AM -0400, Daniel Kahn Gillmor wrote:
> It would be great to have an autopkgtest that confirms that it actually
> interoperates with Thunderbird as expected.
[...] 
> Perhaps upstream could help us assemble a comparable test that would run
> reliably in ci.debian.org.

upstream pointed me to 
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/pipelines/1258177075 
and said "note jobs in the tb_test column", which at least is something
in that direction, though I think eg
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/jobs/6656045653
(1st link from that 1st url in that column mentioned above) is not
really easily comprehensible and I would also love to see something with
screenshots (and a video) where one can see thunderbird started,
email being written, pgp icon clicked, etc, as I've seen being done
eg with openqa.


-- 
cheers,
Holger

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

The past is over.


signature.asc
Description: PGP signature

Bug#1069242: official bookworm-backports of rust packages unlikely

[Holger Levsen]

control: tags -1 + wontfix

hi Jérôme,

backports of rust packages at least currently are very unlikely, because
one cannot simply backport one package plus one or two libraries maybe,
or 5 libraries, but instead one would need to backport 
src:rust-sequoia-octopus-librnp
which would need around 10 other src:rust-sequoia* packages, which 
then need a 100 (or 200?) or so other src:rust* packages backported and
then these backports (besides being a huge effort already) need to be
maintained until after one year of the release of trixie, which translates
to more backports of these hundreds of packages plus any new dependencies...

So right now I don't see *this* happen, sorry.

OTOH, if the unstable libsequoia-octopus-librnp binary package works for you
on bookworm, it's trivial to put it in a local apt repo and be done. :)


-- 
cheers,
Holger

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

Stop saying that we are all in the same boat.
We’re all in the same storm. But we’re not all in the same boat.


signature.asc
Description: PGP signature

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

[Andreas Rönnquist]

Control: tags -1 + pending

I have NMU'd this package fixing this bug with Steve's patch - Thanks
Steve! I have uploaded this to DELAYED/2 - please let me know if I
should delay it further.

Debdiff attached.

best
/Andreas Rönnquist
gus...@debian.org


acm_time_t64.debdiff
Description: Binary data

Bug#456533: Egbbprobe in toga 2

[Petter Reinholdtsen]

[2007-12-16]
> I have asked Daniel to clear the license questions that I have, see below.

Was any conclusion reached regarding the licensing of this library?
-- 
Happy hacking
Petter Reinholdtsen

Bug#1069850: python3-locust: internal version is wrongly reported as 0.0.0

[Michael R. Crusoe]

Package: python3-locust
Version: 2.12.1-1
Severity: normal
Tags: patch
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

I noticed that your package dosage doesn't know its own version number, due to 
upstream using setuptools-scm:

> /usr/lib/python3/dist-packages/locust-0.0.0.dist-info/INSTALLER
> /usr/lib/python3/dist-packages/locust-0.0.0.dist-info/METADATA
> /usr/lib/python3/dist-packages/locust-0.0.0.dist-info/WHEEL
> /usr/lib/python3/dist-packages/locust-0.0.0.dist-info/entry_points.txt
> /usr/lib/python3/dist-packages/locust-0.0.0.dist-info/top_level.txt

https://packages.debian.org/sid/all/python3-locust/filelist

Attached is a patch to fix this. And for your convenience, I've opened a MR on 
Salsa https://salsa.debian.org/morph/locust/-/merge_requests/1

commit 6ff25b492074b540ae83807f532f09f925b2a9a3
Author: Michael R. Crusoe 
Date:   Thu Apr 25 21:24:24 2024 +0300

d/control: build-dep on setuptools-scm to fix wrong "0.0.0" version

diff --git a/debian/control b/debian/control
index 152e334..c2cf63d 100644
--- a/debian/control
+++ b/debian/control
@@ -18,6 +18,7 @@ Build-Depends: debhelper-compat (= 13),
python3-retry ,
python3-roundrobin ,
python3-setuptools,
+   python3-setuptools-scm,
python3-typing-extensions ,
python3-zmq (>= 16.0.2) ,
 Standards-Version: 4.6.2.0
diff --git a/debian/rules b/debian/rules
index a7d2f09..4de9e15 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,6 @@
 #! /usr/bin/make -f
 
 export PYBUILD_NAME=locust
-export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
 
 %:
 	dh $@ --with python3 --buildsystem=pybuild


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069849: publickey auth does not work when GSSAPI is also used

[Vincent Danjean]

Package: openssh-server
Version: 1:8.4p1-5+deb11u3
Severity: important
X-Debbugs-Cc: vdanj...@debian.org

  Hi,

  In an kerberos environment, I'm gradually migrating machines from
bullseye to bookworm. Doing this, I observe a regression concerning
openssh-server.

  Openssh is configurated to allow kerberos authentification.
sshd_config has the following lines:
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIStoreCredentialsOnRekey yes
and ssh_config has the following lines:
Host *
GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
GSSAPITrustDNS yes

  When trying to log from a kerberos account into a remote local
(non kerberos) account with a public key, it works on bulleyes machines,
but on bookworm machines, I got the following error:
$ ssh -v -l remote-local-login bookworm-machine
[...]
OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/local.conf
debug1: /etc/ssh/ssh_config.d/local.conf line 6: Applying options for *
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to bookworm-machine.domain.fr [10.0.0.3] port 22.
debug1: Connection established.
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_rsa type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_rsa-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa_sk-cert type 
-1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519 type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519_sk-cert 
type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_xmss type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_xmss-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_dsa type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 
Debian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u2 pat OpenSSH* 
compat 0x0400
debug1: Authenticating to bookworm-machine.domain.fr:22 as 'remote-local-login'
debug1: load_hostkeys: fopen /home/domain.fr/kerberos-user/.ssh/known_hosts2: 
No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or 
directory
debug1: Offering GSSAPI proposal: 
gss-group14-sha256-toWM5Slw5Ew8Mqkay+al2g==,gss-group16-sha512-toWM5Slw5Ew8Mqkay+al2g==,gss-nistp256-sha256-toWM5Slw5Ew8Mqkay+al2g==,gss-curve25519-sha256-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha256-eipGX3TCiQSrx573bT1o1Q==,gss-group16-sha512-eipGX3TCiQSrx573bT1o1Q==,gss-nistp256-sha256-eipGX3TCiQSrx573bT1o1Q==,gss-curve25519-sha256-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: gss-group14-sha256-toWM5Slw5Ew8Mqkay+al2g==
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
debug1: Received GSSAPI_COMPLETE
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
debug1: Rekey has happened - updating saved versions
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: kerberos-u...@domain.fr@di3937su RSA 
SHA256:LVQ9Rw8lBcFd5DPN0NXfU8Heo2+7sBrEhzkTdNgcDVA agent
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_rsa
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ecdsa
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ed25519
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_xmss
debug1: Will attempt key: 

Bug#1069848: vonsh FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: vonsh
Version: 1.0+ds-0.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vonsh fails to cross build from source, because it strips with the build
architecture strip. Once I looked into the package, I encountered more
issues. It does not generate a -dbgsym package. It does not honour
DEB_BUILD_OPTIONS=nostrip. It does not honour dpkg-buildflags and thus
uses 32bit time still. The attached patch fixes all of this.

Is this really a package worth keeping in Debian? No maintainer upload
in 5 years, 2 NMUs. Consider RoQA.

Helmut
--- vonsh-1.0+ds/debian/changelog
+++ vonsh-1.0+ds/debian/changelog
@@ -1,3 +1,12 @@
+vonsh (1.0+ds-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make CFLAGS, LDFLAGS and strip configurable.
++ Force a non-stripping strip
+
+ -- Helmut Grohne   Thu, 25 Apr 2024 16:40:11 +0200
+
 vonsh (1.0+ds-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
--- vonsh-1.0+ds/debian/patches/cross.patch
+++ vonsh-1.0+ds/debian/patches/cross.patch
@@ -0,0 +1,22 @@
+--- vonsh-1.0+ds.orig/Makefile
 vonsh-1.0+ds/Makefile
+@@ -9,14 +9,16 @@
+ SRC = $(wildcard $(SRC_DIR)/*.c)
+ OBJ = $(SRC:$(SRC_DIR)/%.c=$(OBJ_DIR)/%.o)
+ EXE = $(EXE_DIR)/vonsh
+-CFLAGS = -I$(INC_DIR) -DVERSION_STR=\"$(VERSION_STR)\" -Wall -Wformat 
-Werror=format-security
+-LDFLAGS = -Wl,-z,relro,-z,now
++STRIP ?= strip
++CFLAGS ?= -Wall -Wformat -Werror=format-security
++CFLAGS += -I$(INC_DIR) -DVERSION_STR=\"$(VERSION_STR)\"
++LDFLAGS ?= -Wl,-z,relro,-z,now
+ LDLIBS = -lSDL2 -lSDL2main -lSDL2_image -lSDL2_mixer
+ .PHONY: all clean install
+ all: release
+ release: CFLAGS += -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong
+ release: $(EXE)
+-  strip --strip-all $^
++  $(STRIP) --strip-all $^
+ debug: CFLAGS += -g
+ debug: $(EXE)
+ $(EXE): $(OBJ)
--- vonsh-1.0+ds/debian/patches/series
+++ vonsh-1.0+ds/debian/patches/series
@@ -0,0 +1 @@
+cross.patch
--- vonsh-1.0+ds/debian/rules
+++ vonsh-1.0+ds/debian/rules
@@ -3,6 +3,8 @@
 #export DH_VERBOSE=1
 include /usr/share/dpkg/pkg-info.mk
 export VERSION_STR=$(DEB_VERSION)
+# Do not strip.
+export STRIP=true
 
 %:
dh $@

Bug#1069847: rolo FTCBFS: multiple issues

[Helmut Grohne]

Source: rolo
Version: 019-4.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rolo fails to cross build from source for two distinct reasons.

For one thing, configure.ac hard codes the build architecture
pkg-config. It is recommended to use the PKG_CHECK_MODULES macro which
automatically gets this right.

For another, tests/Makefile.am runs tests during the all target which is
usually run during build. Hence tests fail despite passing
DEB_BUILD_OPTIONS=nocheck. Moving tests to the check target causes tests
to not be run during all, but still be run in a debian package build as
dh_auto_test runs make check (unless DEB_BUILD_OPTIONS contains
nocheck).

I'm attaching a patch for your convenience.

Helmut
--- rolo-019.orig/configure.ac
+++ rolo-019/configure.ac
@@ -19,12 +19,13 @@
 CFLAGS="$CFLAGS -I/usr/include/ncursesw/"
 
 # Glib settings
-LIBS="$LIBS $(pkg-config glib-2.0 --libs)"
-CFLAGS="$CFLAGS $(pkg-config glib-2.0 --cflags)"
+PKG_CHECK_MODULES([GLIB],[glib-2.0])
 
 # Libunac settings
-LIBS="$LIBS $(pkg-config unac --libs)"
-CFLAGS="$CFLAGS $(pkg-config unac --cflags)"
+PKG_CHECK_MODULES([UNAC],[unac])
+
+LIBS="$LIBS $GLIB_LIBS $UNAC_LIBS"
+CFLAGS="$CFLAGS $GLIB_CFLAGS $UNAC_CFLAGS"
 
 # Checks for header files.
 AC_CHECK_INCLUDES_DEFAULT
--- rolo-019.orig/test/Makefile.am
+++ rolo-019/test/Makefile.am
@@ -1,4 +1,4 @@
-all:
+check:
 	@if [ "$(HAS_SHUNIT2)" = yes ] ; then	\
 	./run-tests ; 			\
 	else	\

Bug#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)

[Vincent Lefevre]

Control: tags -1 unreproducible - fixed-upstream
Control: close -1

On 2022-11-09 17:16:06 +0100, Vincent Lefevre wrote:
> I've tried a couple of cold boots, but this did not reproduce the
> issue. Perhaps the bug is rare with my laptop and more common with
> some other hardware.

AFAIK, I've never had the issue again.

On 2024-04-25 17:39:16 +, Debian Bug Tracking System wrote:
> > # remote status report for #1023192 (http://bugs.debian.org/1023192)
> > # Bug title: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: 
> > Reading Intel version command failed (-110)
> > #  * http://bugzilla.kernel.org/show_bug.cgi?id=215167
> > #  * remote status changed: NEW -> RESOLVED
> > #  * remote resolution changed: (?) -> OBSOLETE
> > #  * closed upstream
> > tags 1023192 + fixed-upstream

No, the bug was closed as OBSOLETE, with the following comment:

"This bug report has become unintelligible. 

Please file a new one if you're still affected.

Make sure you have verified kernel 6.6.13 or 6.7.1 with the latest firmware."

So I'm retagging and closing the bug (I was the reporter, and no other
users got affected).

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

Bug#1069841: python-icalendar: FTBFS with tzdata 2024a: UnknownTimeZoneError: 'America/Godthab'

[Benjamin Drung]

On Thu, 2024-04-25 at 18:13 +0100, Simon McVittie wrote:
> Control: retitle -1 python-icalendar: FTBFS with tzdata 2024a: 
> UnknownTimeZoneError: 'America/Godthab'
> 
> On Thu, 25 Apr 2024 at 18:27:15 +0200, Santiago Vila wrote:
> > E   pytz.exceptions.UnknownTimeZoneError: 'America/Godthab'
> 
> This was presumably triggered by this change in tzdata 2024a-2:
> 
> tzdata (2024a-2) unstable; urgency=medium
> ...
>   * Replace America/Godthab by America/Nuuk
> 
> which appears to have been an intentional compatibility break?

America/Godthab has been moved to tzdata-legacy. The package could
depend on tzdata-legacy or better do this replacement in
WINDOWS_TO_OLSON as well.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1069845: ncl: FTBFS (ld: cannot find -lNGras: No such file or directory)

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: user debian-...@lists.debian.org
Control: usertag -1 hdf-4.3

On 4/25/24 7:35 PM, Bas Couwenberg wrote:

The buildlogs shows many instances of these:

  /usr/bin/ld: cannot find -lNGctrans: No such file or directory
  /usr/bin/ld: cannot find -lNGras: No such file or directory

The full buildlog is attached.


It also shows:

 hdf.c:56:10: fatal error: dfgr.h: No such file or directory
56 | #include 
   |  ^~~~

This header is no longer provided by hdf 4.3.0, see:


https://github.com/HDFGroup/hdf4/blob/hdf4.3.0/doc/HDF-4.2-to-4.3-migration.md#appendix-list-of-removed-header-files

Kind Regards,

Bas

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

Bug#1069844: More debug info

[Julian Andres Klode]

On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> 
> Continuing to debug on QEMU it seems there is an incompatibility with
> the images and the peloader (which overrides the normal efi loader):
> 
>   Thread 1 hit Breakpoint 3.2, grub_load_normal_mode () at 
> ../../../grub-core/kern/main.c:241
>   241 in ../../../grub-core/kern/main.c   
>   
>
>   (grub gdb) hbreak do_load_image 
>   
>
>   Hardware assisted breakpoint 4 at 0x23bdf0e00: do_load_image. (2 locations) 
>   
>
>   (grub gdb) c
>   
>
>   Continuing. 
>   
>
>   add symbol table from file "bli.module" at  
>   
>
>   .text_addr = 0x23ba772e0
>   
>
>   .bss_addr = 0x0 
>   
>
>   .module_license_addr = 0x23ba7764a 
>   .data_addr = 0x0
>   
>
>   .rodata.str1.1_addr = 0x23ba77560   
>   
>
>   .rodata_addr = 0x23ba77550  
>   
>
>   add symbol table from file "xen_boot.module" at 
>   
>
>   .text_addr = 0x23bcef3c0
>   
>
>   .bss_addr = 0x23bcf0370 
>   
>
>   .module_license_addr = 0x23bcf035e  
>   
>   .data_addr = 0x0
>   
>   .rodata.str1.1_addr = 0x23bcefff8
> 
>   Thread 1 hit Breakpoint 4.1, do_load_image (boot_policy=0 '\000', 
> parent_image_handle=0x23e889f18, file_path=0x237d1bce0, 
> source_buffer=0x239f0, source_size=1081352, 
>   image_handle=0x4766c498) at ../../../grub-core/loader/efi/peimage.c:745
>   warning: 745../../../grub-core/loader/efi/peimage.c: No such file or 
> directory
>   (grub gdb) hbreak grub_error
>   Hardware assisted breakpoint 5 at 0x6db0: grub_error. (2 locations)
>   (grub gdb) c
>   Continuing.
> 
>   Thread 1 hit Breakpoint 4.2, 0x00023bdf0e4c in do_load_image 
> (boot_policy=, parent_image_handle=, 
> image_handle=, 
>   source_size=, source_buffer=, 
> file_path=) at ../../../grub-core/loader/efi/peimage.c:751
>   751 in ../../../grub-core/loader/efi/peimage.c
>   (grub gdb) c
>   Continuing.
> 
>   Thread 1 hit Breakpoint 5.2, grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 
> "section inside header") at ../../../grub-core/kern/err.c:41
>   warning: 41 ../../../grub-core/kern/err.c: No such file or directory
>   (grub gdb) bt
>   #0  grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 "section inside header") 
> at ../../../grub-core/kern/err.c:41
>   #1  0x00023bdf0e34 in do_load_image (boot_policy=, 
> parent_image_handle=, file_path=, 
> source_buffer=, 
>   source_size=, image_handle=) at 
> ../../../grub-core/loader/efi/peimage.c:747
>   #2  0x00023bedabdc in grub_arch_efi_linux_boot_image (addr=9561964544, 
> size=1081352, 
>   args=0x23bbb8b00 "placeholder dom0_mem=4G,max:4G loglvl=all 
> guest_loglvl=all no-real-mode edd=off") at 
> ../../../grub-core/loader/efi/linux.c:210
>   #3  0x00023bff41bc in grub_loader_boot () at 
> ../../../grub-core/commands/boot.c:211
>   #4  grub_loader_boot () at ../../../grub-core/commands/boot.c:190
>   #5  

Bug#1069846: dpkg: dpkg-deb fails to build package w/ incomplete changelog entry

[Rainer Weikusat]

Package: dpkg
Version: 1.21.22
Severity: minor
Tags: patch
X-Debbugs-Cc: rweiku...@cyberadapt.com

The /usr/share/dpkg/pkg-info.mk file invokes dpkg-parsechangelog to
set the SOURCE_DATE_EPOCH environment variable to the date of the
last changelog entry for the package being built. If this changelog
entry hasn't yet been finalized with a date, eg, if it looks like this
(actual example):

apache2 (2.4.59-ca001-1-deb12u2) unstable; urgency=medium

  * updated to Debian 12 sources

 --

SOURCE_DATE_EPOCH is set to an empty string. This causes the
parse_timestamp routine in build.c to fail and print the (rather
confusing) error message:

unable to parse timestamp '': Success

(Success being printed because errno isn't set). Package generation then
fails because dpkg-deb afterwards terminates with an exit code of 2.

Building such packages may not be a supported feature but I've been
using it for dev builds of packages for about 20 years (and plan to
continue doing so). The included patch avoids the issue by ignoring the
value of SOURCE_DATA_EPOCH when it's empty.

-- patch:
--- a/src/deb/build.c
+++ b/src/deb/build.c
@@ -598,7 +598,7 @@ do_build(const char *const *argv)
   m_output(stdout, _(""));
 
   timestamp_str = getenv("SOURCE_DATE_EPOCH");
-  if (timestamp_str)
+  if (timestamp_str && *timestamp_str)
 timestamp = parse_timestamp(timestamp_str);
   else
 timestamp = time(NULL);
--

-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/24 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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9+deb12u4
ii  liblzma5 5.4.1-0.2
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b6
ii  libzstd1 1.5.4+dfsg2-5
ii  tar  1.34+dfsg-1.2+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.6.1
pn  debsig-verify  

-- no debconf information

Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

[Mo Zhou]

Control: close -1

I merged your files and uploaded to unstable.
The source name is hyprlang directly without the lib prefix.
https://salsa.debian.org/debian/hyprlang

On 4/18/24 03:16, Alan M Varghese wrote:

Hello Mo,

Thank you for granting me access.


I believe this would require me to force push from local repo? 
Wouldn't this result


in the loss of your own commit history?


Or we could merge the two from a different branch. But that feels like 
too much


work :p


If you feel it is worth it to push from my repo, please feel free to 
do so.


Or, I am also okay with it if you just keep what you have done there

and we can iterate on top of it without pushing from my repo (from a 
cursory look,


we just need to bring in latest upstream version, add a watch file etc).


PS: Are you active on IRC? I am usually active daytime, Indian 
Standard Time.


What are your preferred timings?

Bug#1069844: More debug info

[Alex Bennée]

Continuing to debug on QEMU it seems there is an incompatibility with
the images and the peloader (which overrides the normal efi loader):

  Thread 1 hit Breakpoint 3.2, grub_load_normal_mode () at 
../../../grub-core/kern/main.c:241
  241 in ../../../grub-core/kern/main.c 

   
  (grub gdb) hbreak do_load_image   

   
  Hardware assisted breakpoint 4 at 0x23bdf0e00: do_load_image. (2 locations)   

   
  (grub gdb) c  

   
  Continuing.   

   
  add symbol table from file "bli.module" at

   
  .text_addr = 0x23ba772e0  

   
  .bss_addr = 0x0   

   
  .module_license_addr = 0x23ba7764a 
  .data_addr = 0x0  

   
  .rodata.str1.1_addr = 0x23ba77560 

   
  .rodata_addr = 0x23ba77550

   
  add symbol table from file "xen_boot.module" at   

   
  .text_addr = 0x23bcef3c0  

   
  .bss_addr = 0x23bcf0370   

   
  .module_license_addr = 0x23bcf035e

  .data_addr = 0x0  

  .rodata.str1.1_addr = 0x23bcefff8

  Thread 1 hit Breakpoint 4.1, do_load_image (boot_policy=0 '\000', 
parent_image_handle=0x23e889f18, file_path=0x237d1bce0, 
source_buffer=0x239f0, source_size=1081352, 
  image_handle=0x4766c498) at ../../../grub-core/loader/efi/peimage.c:745
  warning: 745../../../grub-core/loader/efi/peimage.c: No such file or 
directory
  (grub gdb) hbreak grub_error
  Hardware assisted breakpoint 5 at 0x6db0: grub_error. (2 locations)
  (grub gdb) c
  Continuing.

  Thread 1 hit Breakpoint 4.2, 0x00023bdf0e4c in do_load_image 
(boot_policy=, parent_image_handle=, 
image_handle=, 
  source_size=, source_buffer=, 
file_path=) at ../../../grub-core/loader/efi/peimage.c:751
  751 in ../../../grub-core/loader/efi/peimage.c
  (grub gdb) c
  Continuing.

  Thread 1 hit Breakpoint 5.2, grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 
"section inside header") at ../../../grub-core/kern/err.c:41
  warning: 41 ../../../grub-core/kern/err.c: No such file or directory
  (grub gdb) bt
  #0  grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 "section inside header") 
at ../../../grub-core/kern/err.c:41
  #1  0x00023bdf0e34 in do_load_image (boot_policy=, 
parent_image_handle=, file_path=, 
source_buffer=, 
  source_size=, image_handle=) at 
../../../grub-core/loader/efi/peimage.c:747
  #2  0x00023bedabdc in grub_arch_efi_linux_boot_image (addr=9561964544, 
size=1081352, 
  args=0x23bbb8b00 "placeholder dom0_mem=4G,max:4G loglvl=all 
guest_loglvl=all no-real-mode edd=off") at 
../../../grub-core/loader/efi/linux.c:210
  #3  0x00023bff41bc in grub_loader_boot () at 
../../../grub-core/commands/boot.c:211
  #4  grub_loader_boot () at ../../../grub-core/commands/boot.c:190
  #5  0x00023bf42158 in grub_command_execute (name=0x23bf4e72c "boot", 
argc=0, argv=0x0 <_start>) at ../../../include/grub/command.h:126
  #6  grub_menu_execute_entry (entry=entry@entry=0x23bd17660, 
auto_boot=auto_boot@entry=0) at 

Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland

[Mo Zhou]

Control: close -1

Sponsored directly from git.

On 4/17/24 11:19, Mo Zhou wrote:

I have forked your repo to here:
https://salsa.debian.org/debian/hyprland-protocols

Will sponsor later when I get my other computer.

On 4/15/24 12:19, Alan M Varghese wrote:

Control: tags -1 - moreinfo

Then the upstream version should be >> 0.2, e.g, 0.2+20230811, not 
<< 0.2

as it is now.
Also, as the package is arch:all it shouldn't use ${shlibs:Depends} 
(which

will be emoty anyway).

Done and done.

Alan M Varghese (NyxTrail)

Bug#979617: tcplay: VeraCrypt support

[GCS]

On Mon, Apr 22, 2024 at 8:33 PM Daniel Kahn Gillmor  wrote:
> On Sun 2024-04-21 15:44:12 +0200, László Böszörményi (GCS) wrote:
> >  I prefer communication first. :) Currently I'm travelling so I can
> > only check it on Tuesday.
>
> That's why i uploaded to DELAYED/15 :)  thanks for offering to take a
> look at it later this week, László!
 I meant to reach a consensus first and then do the upload. There's no
point in an upload that needs to be cancelled.

Best,
Laszlo/GCS

Bug#1069841: python-icalendar: FTBFS with tzdata 2024a: UnknownTimeZoneError: 'America/Godthab'

[Simon McVittie]

Control: retitle -1 python-icalendar: FTBFS with tzdata 2024a: 
UnknownTimeZoneError: 'America/Godthab'

On Thu, 25 Apr 2024 at 18:27:15 +0200, Santiago Vila wrote:
> E   pytz.exceptions.UnknownTimeZoneError: 'America/Godthab'

This was presumably triggered by this change in tzdata 2024a-2:

tzdata (2024a-2) unstable; urgency=medium
...
  * Replace America/Godthab by America/Nuuk

which appears to have been an intentional compatibility break?

smcv

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Andreas B. Mundt]

Control: found -1 libreoffice/4:24.2.3~rc1-3
Control: notfixed -1 libreoffice/4:24.2.2-1
Control: reopen -1
Control: tags -1 - moreinfo

Hi again,

On Thu, Apr 25, 2024 at 06:43:17PM +0200, Rene Engelhard wrote:
> Am 25.04.24 um 18:37 schrieb Andreas B. Mundt:
> > On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote:
> > > Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:
> > > > For now, we traced the issue back to libreoffice-kf5.  If this package
> > > > is removed, neither the document disappears on closing libreoffice nor
> > > > the popup is shown when 'nobrl' is removed from the mount options.
> > > Which doesn't do IO itself though? But maybe the KDE file picker (over 
> > > kio)
> > > does something weird? But saving (ttbomk) isn't done by the file picker
> > > itself?
> > I just tried a trixie XFCE desktop and cannot reproduce the issue
> > there.  Then I installed KDE and switched the DE. In KDE again the
> > issue is reproducable, removing libreoffice-kf5 makes the problem go
> > away.  Installing libreoffice-kf5 again: Issue is back.
> Shrugs.
> > However, back in XFCE, even with libreoffice-kf5 installed, the issue
> > does not show up.
> 
> Because in XFCE you don't get the KDE File Picker but the Gtk one.
> 
> Unless you force kf5, which I don't think you do.

Right.

> >   The different file chooser GUIs seem to trigger the
> > issue.
> Interesting.
> > Removing libreoffice-kf5 or switching to XFCE results in a
> > different file chooser, which somehow causes the problem.  So the bug
> > is probably not in libreoffice-kf5 …
> 
> -kf5 does contain the KDE file picker used in LibreOffice.
> 
> 
> In any case, try with >= 24.2.2 (so sid). If that commit was it (which I
> somehow doubt, see my previous reply) sid should work.

I upgraded libreoffice to the version in sid now -- it seems not to
happen as often as before, but I could reproduce it still a few more
times.

Not sure which package to reassign the bug to.

Best regards,

  Andi

Bug#1069671: further tests

[Michael Becker]

after further testing I found that the problem somehow is related to xfce4

if I switch the Display manager to KDE everything works as expected – no matter 
if I use KDE with Wayland or with Xorg


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069842: rjava: FTBFS: /usr/bin/ld: cannot find -ldeflate: No such file or directory

[Dirk Eddelbuettel]

reassign 1069842 r-base
thanks

On 25 April 2024 at 18:27, Santiago Vila wrote:
| Package: src:rjava
| Version: 1.0-11-1
| Severity: serious
| Tags: ftbfs
| 
| Dear maintainer:
| 
| During a rebuild of all packages in unstable, your package failed to build:

Thanks for this. It is caused by the just released R 4.4.0 which now uses
libdeflate, gets it somehow already via its Build-Depends but then does not
implicitly pass it on via its virtual (child) package r-base-dev and its
depends. (Both have a list of lib*-dev compression packages.)

I will make a r-base 4.4.0-2 either today or tomorrow to correct this and
have r-base-dev explicitly list libdeflate-dev.

Dirk

| 
| 

| [...]
|   debian/rules build
| dh build --buildsystem R
| dh_update_autotools_config -O--buildsystem=R
| cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
| cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
| dh_autoreconf -O--buildsystem=R
| dh_auto_configure -O--buildsystem=R
| dh_auto_build -O--buildsystem=R
| dh_auto_test -O--buildsystem=R
| create-stamp debian/debhelper-build-stamp
|   fakeroot debian/rules binary
| dh binary --buildsystem R
| dh_testroot -O--buildsystem=R
| dh_prep -O--buildsystem=R
| dh_auto_install --destdir=debian/r-cran-rjava/ -O--buildsystem=R
| I: R Package: rJava Version: 1.0-11
| I: Building using R version 4.4.0-1
| I: R API version: r-api-4.0
| I: Using built-time from d/changelog: Fri, 26 Jan 2024 11:10:09 -0600
|   mkdir -p /<>/debian/r-cran-rjava/usr/lib/R/site-library
|   R CMD INSTALL -l 
/<>/debian/r-cran-rjava/usr/lib/R/site-library --clean . 
"--built-timestamp='Fri, 26 Jan 2024 11:10:09 -0600'"
| * installing *source* package ‘rJava’ ...
| files ‘configure’, ‘jri/tools/config.guess’, ‘jri/tools/config.sub’, 
‘src/config.h.in’ have the wrong MD5 checksums
| ** using staged installation
| checking for gcc... gcc
| checking whether the C compiler works... yes
| checking for C compiler default output file name... a.out
| checking for suffix of executables...
| checking whether we are cross compiling... no
| checking for suffix of object files... o
| checking whether the compiler supports GNU C... yes
| checking whether gcc accepts -g... yes
| checking for gcc option to enable C11 features... none needed
| checking for sys/wait.h that is POSIX.1 compatible... yes
| checking for stdio.h... yes
| checking for stdlib.h... yes
| checking for string.h... yes
| checking for inttypes.h... yes
| checking for stdint.h... yes
| checking for strings.h... yes
| checking for sys/stat.h... yes
| checking for sys/types.h... yes
| checking for unistd.h... yes
| checking for string.h... (cached) yes
| checking for sys/time.h... yes
| checking for unistd.h... (cached) yes
| checking for an ANSI C-conforming const... yes
| configure: checking whether gcc supports static inline...
| yes
| checking whether setjmp.h is POSIX.1 compatible... yes
| checking for gcc options needed to detect all undeclared functions... none 
needed
| checking whether sigsetjmp is declared... yes
| checking whether siglongjmp is declared... yes
| checking Java support in R... present:
| interpreter : '/usr/lib/jvm/default-java/bin/java'
| archiver: '/usr/lib/jvm/default-java/bin/jar'
| compiler: '/usr/lib/jvm/default-java/bin/javac'
| header prep.: ''
| cpp flags   : '-I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux'
| java libs   : '-L/usr/lib/jvm/default-java/lib/server -ljvm'
| checking whether Java run-time works... yes
| checking whether -Xrs is supported... yes
| checking whether -Xrs will be used... yes
| checking whether JVM will be loaded dynamically... no
| checking whether JNI programs can be compiled... yes
| checking whether JNI programs run... yes
| checking JNI data types... ok
| checking whether JRI should be compiled (autodetect)... yes
| checking whether debugging output should be enabled... no
| checking whether memory profiling is desired... no
| checking whether threads support is requested... no
| checking whether callbacks support is requested... no
| checking whether JNI cache support is requested... no
| checking whether headless init is enabled... no
| checking whether JRI is requested... yes
| configure: creating ./config.status
| config.status: creating src/Makevars
| config.status: creating R/zzz.R
| config.status: creating src/config.h
| === configuring in jri (/<>/jri)
| configure: running /bin/bash ./configure --disable-option-checking 
'--prefix=/usr/local'  'CC=gcc' 'CFLAGS=-g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' --cache-file=/dev/null --srcdir=.
| checking 

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Andreas B. Mundt]

Control: found -1 libreoffice/4:24.2.0-1 

Hi Rene,

thanks for your quick reply and sorry for not providing detailed
version information!

On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote:
> 
> Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:
> > For now, we traced the issue back to libreoffice-kf5.  If this package
> > is removed, neither the document disappears on closing libreoffice nor
> > the popup is shown when 'nobrl' is removed from the mount options.
> 
> Which doesn't do IO itself though? But maybe the KDE file picker (over kio)
> does something weird? But saving (ttbomk) isn't done by the file picker
> itself?

I just tried a trixie XFCE desktop and cannot reproduce the issue
there.  Then I installed KDE and switched the DE. In KDE again the
issue is reproducable, removing libreoffice-kf5 makes the problem go
away.  Installing libreoffice-kf5 again: Issue is back.

However, back in XFCE, even with libreoffice-kf5 installed, the issue
does not show up.  The different file chooser GUIs seem to trigger the
issue. Removing libreoffice-kf5 or switching to XFCE results in a
different file chooser, which somehow causes the problem.  So the bug
is probably not in libreoffice-kf5 …

Best regards,

  Andi

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

Hi,

Am 25.04.24 um 18:37 schrieb Andreas B. Mundt:

On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote:

Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl' is removed from the mount options.

Which doesn't do IO itself though? But maybe the KDE file picker (over kio)
does something weird? But saving (ttbomk) isn't done by the file picker
itself?

I just tried a trixie XFCE desktop and cannot reproduce the issue
there.  Then I installed KDE and switched the DE. In KDE again the
issue is reproducable, removing libreoffice-kf5 makes the problem go
away.  Installing libreoffice-kf5 again: Issue is back.

Shrugs.

However, back in XFCE, even with libreoffice-kf5 installed, the issue
does not show up.


Because in XFCE you don't get the KDE File Picker but the Gtk one.

Unless you force kf5, which I don't think you do.


  The different file chooser GUIs seem to trigger the
issue.

Interesting.

Removing libreoffice-kf5 or switching to XFCE results in a
different file chooser, which somehow causes the problem.  So the bug
is probably not in libreoffice-kf5 …


-kf5 does contain the KDE file picker used in LibreOffice.


In any case, try with >= 24.2.2 (so sid). If that commit was it (which I 
somehow doubt, see my previous reply) sid should work.


Regards,


Rene

Bug#1069837: python3-doc8: internal version is wrongly reported as 0.0.0

[Michael R. Crusoe]

I have also added a commit to the MR which enables the use of pybuild to run 
the tests, and then turns on pybuild-autopkgtest to enable a quicker migration 
of the package to testing:

https://salsa.debian.org/openstack-team/libs/python-doc8/-/merge_requests/4/diffs?commit_id=29e749091707ef49d7c531c702124a832fe5e4b8



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069844: grub-efi-arm64: grub fails to load Xen hypervisor on arm64 EFI systems (AVA & QEMU)

[Alex Bennée]

Package: grub-efi-arm64
Version: 2.12-2~deb13u1
Severity: serious

Attempting to boot Xen on an arm64 EFI system fails. Further attempts to
select another boot entry fails and the system needs to be rebooted
before you can load the kernel without Xen. This is likely due to boot
services having been unloaded.

Running on the Ampere AVA platform with additional diagnostics
(xen,xen_loader,efiemu,fdt,linux) gets the following:

  loader/arm64/xen_boot.c:116:xen_loader: Xen Hypervisor cmdline : placeholder
  no-real-mode edd=off @ 0x807ff98a6e0 size:33
  loader/arm64/xen_boot.c:224:xen_loader: Module @ 0xf283b000 size:0x1f2c75b
  loader/arm64/xen_boot.c:139:xen_loader: Module node name module@f283b000 
  loader/arm64/xen_boot.c:161:xen_loader: Module
  loader/arm64/xen_boot.c:183:xen_loader: Module has no bootargs!
  loader/arm64/xen_boot.c:224:xen_loader: Module @ 0xef17d000 size:0x3514a00
  loader/arm64/xen_boot.c:139:xen_loader: Module node name module@ef17d000 
  loader/arm64/xen_boot.c:161:xen_loader: Module
  loader/arm64/xen_boot.c:172:xen_loader: Module cmdline : placeholder
  root=UUID=06e49159-b374-445c-bf5f-2bf93e3f4d6b ro @ 0x807ffa1a3a0 size:62
  loader/arm64/xen_boot.c:224:xen_loader: Module @ 0xf4769000 size:0x3514a00
  loader/arm64/xen_boot.c:139:xen_loader: Module node name module@f4769000 
  loader/arm64/xen_boot.c:161:xen_loader: Module
  loader/arm64/xen_boot.c:172:xen_loader: Module cmdline : placeholder
  root=UUID=06e49159-b374-445c-bf5f-2bf93e3f4d6b ro @ 0x807fd65a280 size:62
  loader/efi/fdt.c:136:fdt: Installed/updated FDT configuration table @
  0xef16
  error: cannot load image.

So it appears EFI boot services can successfully stat the various bits
and pieces but once it gets to the stage of
grub_arch_efi_linux_boot_image it fails. As debugging grub on the AVA
platform is hard I replicated the setup in QEMU. At which point I
obtained the following backtrace:

  Thread 1 hit Breakpoint 6.2, grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bedbbbd 
"cannot load image") at ../../../grub-core/kern/err.c:41
  41grub_errno = n;
  (grub gdb) bt
  #0  grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bedbbbd "cannot load image") at 
../../../grub-core/kern/err.c:41
  #1  0x00023bedabf0 in grub_arch_efi_linux_boot_image (addr=9561964544, 
size=1081352, 
  args=0x23bbb8b00 "placeholder dom0_mem=4G,max:4G loglvl=all 
guest_loglvl=all no-real-mode edd=off") at 
../../../grub-core/loader/efi/linux.c:214
  #2  0x00023bff41bc in grub_loader_boot () at 
../../../grub-core/commands/boot.c:211
  #3  grub_loader_boot () at ../../../grub-core/commands/boot.c:190
  #4  0x00023bf42158 in grub_command_execute (name=0x23bf4e72c "boot", 
argc=0, argv=0x0 <_start>) at ../../../include/grub/command.h:126
  #5  grub_menu_execute_entry (entry=entry@entry=0x23bd17660, 
auto_boot=auto_boot@entry=0) at ../../../grub-core/normal/menu.c:306
  #6  0x00023bf41e2c in show_menu (autobooted=, 
nested=, menu=) at 
../../../grub-core/normal/menu.c:925
  #7  grub_show_menu (menu=menu@entry=0x23bd1a940, nested=nested@entry=1, 
autoboot=autoboot@entry=0) at ../../../grub-core/normal/menu.c:940
  #8  0x00023bf408a8 in grub_normal_execute (config=, 
nested=nested@entry=1, batch=batch@entry=0) at 
../../../grub-core/normal/main.c:291
  #9  0x00023bf32260 in grub_cmd_source (cmd=, argc=1, 
args=0x23bd1fcc8) at ../../../grub-core/commands/configfile.c:48
  #10 grub_cmd_source (cmd=, argc=, 
args=0x23bd1fcc8) at ../../../grub-core/commands/configfile.c:30
  #11 0x00023bf48d0c in grub_script_execute_cmdline (cmd=) 
at ../../../grub-core/script/execute.c:1034
  #12 0x00023bf478c0 in grub_script_execute_cmd (cmd=cmd@entry=0x23bd190c8) 
at ../../../grub-core/script/execute.c:819
  #13 0x00023bf4874c in grub_script_execute_cmdlist (list=) 
at ../../../grub-core/script/execute.c:1079
  #14 0x00023bf478c0 in grub_script_execute_cmd (cmd=) at 
../../../grub-core/script/execute.c:819
  #15 0x00023bf489b4 in grub_script_execute (script=) at 
../../../grub-core/script/execute.c:1191
  #16 0x00023bf497fc in grub_normal_parse_line (line=line@entry=0x23bd20060 
"configfile $prefix/grub.cfg", getline=getline@entry=0x23bf40430 
, 
  getline_data=getline_data@entry=0x23bd20380) at 
../../../grub-core/script/main.c:36
  #17 0x00023bf409a0 in read_config_file (config=0x23bd20780 
"(hd0,gpt1)/EFI/debian/grub.cfg") at ../../../grub-core/normal/main.c:179
  #18 grub_normal_execute (config=config@entry=0x23bd20780 
"(hd0,gpt1)/EFI/debian/grub.cfg", nested=nested@entry=0, batch=batch@entry=0)
  at ../../../grub-core/normal/main.c:277
  #19 0x00023bf40ca4 in grub_enter_normal_mode 
(config=config@entry=0x23bd20780 "(hd0,gpt1)/EFI/debian/grub.cfg") at 
../../../grub-core/normal/main.c:304
  #20 0x00023bf40da0 in grub_try_normal_prefix (prefix=0x23bd209a0 
"(hd0,gpt1)/EFI/debian") at ../../../grub-core/normal/main.c:356
  #21 0x00023bf40ea0 in grub_try_normal (variable=0x23bf4e492 

Bug#1069841: python-icalendar: FTBFS: pytz.exceptions.UnknownTimeZoneError: 'America/Godthab'

[Santiago Vila]

Package: src:python-icalendar
Version: 5.0.11-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:129: Building wheel for python3.12 with "build" 
module
I: pybuild base:311: python3.12 -m build --skip-dependency-check --no-isolation --wheel 
--outdir /<>/.pybuild/cpython3_3.12_icalendar
* Building wheel...
running bdist_wheel
running build
running build_py
creating build
creating build/lib
creating build/lib/icalendar
copying src/icalendar/__init__.py -> build/lib/icalendar
copying src/icalendar/windows_to_olson.py -> build/lib/icalendar
copying src/icalendar/timezone_cache.py -> build/lib/icalendar
copying src/icalendar/prop.py -> build/lib/icalendar
copying src/icalendar/caselessdict.py -> build/lib/icalendar
copying src/icalendar/tools.py -> build/lib/icalendar
copying src/icalendar/parser.py -> build/lib/icalendar
copying src/icalendar/cli.py -> build/lib/icalendar
copying src/icalendar/cal.py -> build/lib/icalendar
copying src/icalendar/parser_tools.py -> build/lib/icalendar
creating build/lib/icalendar/tests
copying 
src/icalendar/tests/test_issue_322_single_strings_characters_split_into_multiple_categories.py
 -> build/lib/icalendar/tests
copying src/icalendar/tests/test_unit_parser_tools.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_recurrence.py -> build/lib/icalendar/tests
copying src/icalendar/tests/__init__.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_348_exception_parsing_value.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_cli_tool.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_500_vboolean_for_parameter.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_unit_tools.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_time.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_unit_cal.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_318_skip_default_parameters.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_168_parsing_invalid_calendars_no_warning.py 
-> build/lib/icalendar/tests
copying src/icalendar/tests/test_icalendar.py -> build/lib/icalendar/tests
copying src/icalendar/tests/conftest.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_fixed_issues.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_557_encode_native_parameters.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_unit_caselessdict.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_27_period.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_issue_165_missing_event.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_examples.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_property_params.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_timezoned.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_with_doctest.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_equality.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_multiple.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_components_break_on_bad_ics.py -> 
build/lib/icalendar/tests
copying src/icalendar/tests/test_parsing.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_encoding.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_unit_prop.py -> build/lib/icalendar/tests
copying src/icalendar/tests/test_period.py -> build/lib/icalendar/tests
creating build/lib/icalendar/tests/hypothesis
copying src/icalendar/tests/hypothesis/test_fuzzing.py -> 
build/lib/icalendar/tests/hypothesis
running egg_info
creating src/icalendar.egg-info
writing src/icalendar.egg-info/PKG-INFO
writing dependency_links to src/icalendar.egg-info/dependency_links.txt
writing entry points to src/icalendar.egg-info/entry_points.txt
writing requirements to src/icalendar.egg-info/requires.txt
writing top-level names to src/icalendar.egg-info/top_level.txt
writing manifest file 'src/icalendar.egg-info/SOURCES.txt'
reading manifest file 'src/icalendar.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files matching '*.pyc' found under directory 
'src/icalendar'
warning: no previously-included files matching '*~' found under directory 
'src/icalendar'
adding license file 'LICENSE.rst'
writing manifest file 'src/icalendar.egg-info/SOURCES.txt'
copying src/icalendar/tests/test_create_release.sh -> build/lib/icalendar/tests
creating 

Bug#1069843: zarr: FTBFS: failing tests

[Santiago Vila]

Package: src:zarr
Version: 2.17.2+ds-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:129: Building wheel for python3.12 with "build" 
module
I: pybuild base:311: python3.12 -m build --skip-dependency-check --no-isolation --wheel 
--outdir /<>/.pybuild/cpython3_3.12_zarr
* Building wheel...
running bdist_wheel
running build
running build_py
creating build
creating build/lib
creating build/lib/zarr
copying zarr/hierarchy.py -> build/lib/zarr
copying zarr/__init__.py -> build/lib/zarr
copying zarr/storage.py -> build/lib/zarr
copying zarr/meta_v1.py -> build/lib/zarr
copying zarr/creation.py -> build/lib/zarr
copying zarr/types.py -> build/lib/zarr
copying zarr/util.py -> build/lib/zarr
copying zarr/core.py -> build/lib/zarr
copying zarr/indexing.py -> build/lib/zarr
copying zarr/codecs.py -> build/lib/zarr
copying zarr/convenience.py -> build/lib/zarr
copying zarr/errors.py -> build/lib/zarr
copying zarr/version.py -> build/lib/zarr
copying zarr/attrs.py -> build/lib/zarr
copying zarr/n5.py -> build/lib/zarr
copying zarr/context.py -> build/lib/zarr
copying zarr/sync.py -> build/lib/zarr
copying zarr/meta.py -> build/lib/zarr
creating build/lib/zarr/_storage
copying zarr/_storage/__init__.py -> build/lib/zarr/_storage
copying zarr/_storage/absstore.py -> build/lib/zarr/_storage
copying zarr/_storage/v3.py -> build/lib/zarr/_storage
copying zarr/_storage/store.py -> build/lib/zarr/_storage
copying zarr/_storage/v3_storage_transformers.py -> build/lib/zarr/_storage
creating build/lib/zarr/tests
copying zarr/tests/test_sync.py -> build/lib/zarr/tests
copying zarr/tests/__init__.py -> build/lib/zarr/tests
copying zarr/tests/test_meta.py -> build/lib/zarr/tests
copying zarr/tests/test_core.py -> build/lib/zarr/tests
copying zarr/tests/test_dim_separator.py -> build/lib/zarr/tests
copying zarr/tests/test_storage_v3.py -> build/lib/zarr/tests
copying zarr/tests/test_convenience.py -> build/lib/zarr/tests
copying zarr/tests/test_n5.py -> build/lib/zarr/tests
copying zarr/tests/test_storage.py -> build/lib/zarr/tests
copying zarr/tests/test_hierarchy.py -> build/lib/zarr/tests
copying zarr/tests/util.py -> build/lib/zarr/tests
copying zarr/tests/test_attrs.py -> build/lib/zarr/tests
copying zarr/tests/test_creation.py -> build/lib/zarr/tests
copying zarr/tests/conftest.py -> build/lib/zarr/tests
copying zarr/tests/test_info.py -> build/lib/zarr/tests
copying zarr/tests/test_filters.py -> build/lib/zarr/tests
copying zarr/tests/test_util.py -> build/lib/zarr/tests
copying zarr/tests/test_indexing.py -> build/lib/zarr/tests
copying zarr/tests/test_meta_array.py -> build/lib/zarr/tests
running egg_info
creating zarr.egg-info
writing zarr.egg-info/PKG-INFO
writing dependency_links to zarr.egg-info/dependency_links.txt
writing requirements to zarr.egg-info/requires.txt
writing top-level names to zarr.egg-info/top_level.txt
writing manifest file 'zarr.egg-info/SOURCES.txt'
reading manifest file 'zarr.egg-info/SOURCES.txt'
adding license file 'LICENSE.txt'
writing manifest file 'zarr.egg-info/SOURCES.txt'
installing to build/bdist.linux-x86_64/wheel
running install
running install_lib
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/wheel
creating build/bdist.linux-x86_64/wheel/zarr
copying build/lib/zarr/hierarchy.py -> build/bdist.linux-x86_64/wheel/zarr
copying build/lib/zarr/__init__.py -> build/bdist.linux-x86_64/wheel/zarr
copying build/lib/zarr/storage.py -> build/bdist.linux-x86_64/wheel/zarr
creating build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_sync.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/__init__.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_meta.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_core.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_dim_separator.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_storage_v3.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_convenience.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_n5.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_storage.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_hierarchy.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/util.py -> 
build/bdist.linux-x86_64/wheel/zarr/tests
copying build/lib/zarr/tests/test_attrs.py -> 

Bug#1069842: rjava: FTBFS: /usr/bin/ld: cannot find -ldeflate: No such file or directory

[Santiago Vila]

Package: src:rjava
Version: 1.0-11-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules build
dh build --buildsystem R
   dh_update_autotools_config -O--buildsystem=R
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
   dh_autoreconf -O--buildsystem=R
   dh_auto_configure -O--buildsystem=R
   dh_auto_build -O--buildsystem=R
   dh_auto_test -O--buildsystem=R
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary
dh binary --buildsystem R
   dh_testroot -O--buildsystem=R
   dh_prep -O--buildsystem=R
   dh_auto_install --destdir=debian/r-cran-rjava/ -O--buildsystem=R
I: R Package: rJava Version: 1.0-11
I: Building using R version 4.4.0-1
I: R API version: r-api-4.0
I: Using built-time from d/changelog: Fri, 26 Jan 2024 11:10:09 -0600
mkdir -p /<>/debian/r-cran-rjava/usr/lib/R/site-library
R CMD INSTALL -l /<>/debian/r-cran-rjava/usr/lib/R/site-library 
--clean . "--built-timestamp='Fri, 26 Jan 2024 11:10:09 -0600'"
* installing *source* package ‘rJava’ ...
files ‘configure’, ‘jri/tools/config.guess’, ‘jri/tools/config.sub’, 
‘src/config.h.in’ have the wrong MD5 checksums
** using staged installation
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for string.h... (cached) yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
configure: checking whether gcc supports static inline...
yes
checking whether setjmp.h is POSIX.1 compatible... yes
checking for gcc options needed to detect all undeclared functions... none 
needed
checking whether sigsetjmp is declared... yes
checking whether siglongjmp is declared... yes
checking Java support in R... present:
interpreter : '/usr/lib/jvm/default-java/bin/java'
archiver: '/usr/lib/jvm/default-java/bin/jar'
compiler: '/usr/lib/jvm/default-java/bin/javac'
header prep.: ''
cpp flags   : '-I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux'
java libs   : '-L/usr/lib/jvm/default-java/lib/server -ljvm'
checking whether Java run-time works... yes
checking whether -Xrs is supported... yes
checking whether -Xrs will be used... yes
checking whether JVM will be loaded dynamically... no
checking whether JNI programs can be compiled... yes
checking whether JNI programs run... yes
checking JNI data types... ok
checking whether JRI should be compiled (autodetect)... yes
checking whether debugging output should be enabled... no
checking whether memory profiling is desired... no
checking whether threads support is requested... no
checking whether callbacks support is requested... no
checking whether JNI cache support is requested... no
checking whether headless init is enabled... no
checking whether JRI is requested... yes
configure: creating ./config.status
config.status: creating src/Makevars
config.status: creating R/zzz.R
config.status: creating src/config.h
=== configuring in jri (/<>/jri)
configure: running /bin/bash ./configure --disable-option-checking '--prefix=/usr/local'  
'CC=gcc' 'CFLAGS=-g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection' 
'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' --cache-file=/dev/null 
--srcdir=.
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for 

Bug#1069838: khard: FTBFS: ERROR: test_query (unittest.loader._FailedTest.test_query)

[Santiago Vila]

Package: src:khard
Version: 0.19.1-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:311: python3.12 setup.py config
running config
I: pybuild base:311: python3.11 setup.py config
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
cd doc && \
make html && \
make text && \
make man
make[2]: Entering directory '/<>/doc'
Running Sphinx v7.2.6
making output directory... done
[AutoAPI] Reading files... [  7%] /<>/khard/__init__.py
[AutoAPI] Reading files... [ 14%] /<>/khard/khard.py
[AutoAPI] Reading files... [ 21%] /<>/khard/__main__.py
[AutoAPI] Reading files... [ 29%] /<>/khard/actions.py
[AutoAPI] Reading files... [ 36%] /<>/khard/query.py
[AutoAPI] Reading files... [ 43%] /<>/khard/carddav_object.py
[AutoAPI] Reading files... [ 50%] /<>/khard/address_book.py
[AutoAPI] Reading files... [ 57%] /<>/khard/version.py
[AutoAPI] Reading files... [ 64%] /<>/khard/cli.py
[AutoAPI] Reading files... [ 71%] /<>/khard/formatter.py
[AutoAPI] Reading files... [ 79%] /<>/khard/config.py
[AutoAPI] Reading files... [ 86%] /<>/khard/helpers/__init__.py
[AutoAPI] Reading files... [ 93%] /<>/khard/helpers/typing.py
[AutoAPI] Reading files... [100%] 
/<>/khard/helpers/interactive.py

[AutoAPI] Mapping Data... [  7%] /<>/khard/__init__.py
[AutoAPI] Mapping Data... [ 14%] /<>/khard/khard.py
[AutoAPI] Mapping Data... [ 21%] /<>/khard/__main__.py
[AutoAPI] Mapping Data... [ 29%] /<>/khard/actions.py
[AutoAPI] Mapping Data... [ 36%] /<>/khard/query.py
[AutoAPI] Mapping Data... [ 43%] /<>/khard/carddav_object.py
[AutoAPI] Mapping Data... [ 50%] /<>/khard/address_book.py
[AutoAPI] Mapping Data... [ 57%] /<>/khard/version.py
[AutoAPI] Mapping Data... [ 64%] /<>/khard/cli.py
[AutoAPI] Mapping Data... [ 71%] /<>/khard/formatter.py
[AutoAPI] Mapping Data... [ 79%] /<>/khard/config.py
[AutoAPI] Mapping Data... [ 86%] /<>/khard/helpers/__init__.py
[AutoAPI] Mapping Data... [ 93%] /<>/khard/helpers/typing.py
[AutoAPI] Mapping Data... [100%] 
/<>/khard/helpers/interactive.py

[AutoAPI] Rendering Data... [  7%] khard
[AutoAPI] Rendering Data... [ 14%] khard.khard
[AutoAPI] Rendering Data... [ 21%] khard.__main__
[AutoAPI] Rendering Data... [ 29%] khard.actions
[AutoAPI] Rendering Data... [ 36%] khard.query
[AutoAPI] Rendering Data... [ 43%] khard.carddav_object
[AutoAPI] Rendering Data... [ 50%] khard.address_book
[AutoAPI] Rendering Data... [ 57%] khard.version
[AutoAPI] Rendering Data... [ 64%] khard.cli
[AutoAPI] Rendering Data... [ 71%] khard.formatter
[AutoAPI] Rendering Data... [ 79%] khard.config
[AutoAPI] Rendering Data... [ 86%] khard.helpers
[AutoAPI] Rendering Data... [ 93%] khard.helpers.typing
[AutoAPI] Rendering Data... [100%] khard.helpers.interactive

[autosummary] generating autosummary for: bench.rst, commandline.rst, 
contributing.rst, davcontroller.rst, index.rst, indices.rst, man.rst, 
man/khard.conf.rst, man/khard.rst, scripting.rst
building [mo]: targets for 0 po files that are out of date
writing output...
building [html]: targets for 10 source files that are out of date
updating environment: [new config] 25 added, 0 changed, 0 removed
reading sources... [  4%] autoapi/index
reading sources... [  8%] autoapi/khard/__main__/index
reading sources... [ 12%] autoapi/khard/actions/index
reading sources... [ 16%] autoapi/khard/address_book/index
reading sources... [ 20%] autoapi/khard/carddav_object/index
reading sources... [ 24%] autoapi/khard/cli/index
reading sources... [ 28%] autoapi/khard/config/index
reading sources... [ 32%] autoapi/khard/formatter/index
reading sources... [ 36%] autoapi/khard/helpers/index
reading sources... [ 40%] autoapi/khard/helpers/interactive/index
reading sources... [ 44%] autoapi/khard/helpers/typing/index
reading sources... [ 48%] autoapi/khard/index
reading sources... [ 52%] autoapi/khard/khard/index
reading sources... [ 56%] autoapi/khard/query/index
reading sources... [ 60%] autoapi/khard/version/index
reading sources... [ 64%] bench
reading sources... [ 68%] commandline
reading sources... [ 72%] contributing
reading sources... [ 76%] davcontroller
reading sources... [ 80%] index
[AutoAPI] Adding AutoAPI TOCTree [autoapi/index] to index.rst
reading sources... [ 84%] indices
reading sources... [ 88%] man
reading sources... [ 92%] man/khard
reading sources... [ 96%] man/khard.conf
reading sources... [100%] scripting

Bug#1069839: libcommons-fileupload-java: FTBFS: failing tests

[Santiago Vila]

Package: src:libcommons-fileupload-java
Version: 1.5-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
mh_patchpoms -plibcommons-fileupload-java --debian-build --keep-pom-version 
--maven-repo=/<>/debian/maven-repo
   dh_auto_build
/usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar 
-Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml 
-Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode 
package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were 
deprecated in JDK 13 and will likely be removed in a future release.
[INFO] Scanning for projects...
[WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin 
org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been downloaded 
from it before.
[WARNING] The artifact org.apache.maven.plugins:maven-clean-plugin:jar:2.5 has 
been relocated to org.apache.maven.plugins:maven-clean-plugin:jar:3.2.0
[WARNING] The artifact org.apache.maven.plugins:maven-resources-plugin:jar:2.6 
has been relocated to org.apache.maven.plugins:maven-resources-plugin:jar:3.3.0
[WARNING] The artifact org.apache.maven.plugins:maven-jar-plugin:jar:2.4 has 
been relocated to org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0
[WARNING] The artifact org.apache.maven.plugins:maven-compiler-plugin:jar:3.1 
has been relocated to org.apache.maven.plugins:maven-compiler-plugin:jar:3.10.1
[WARNING] The artifact 
org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4 has been relocated to 
org.apache.maven.plugins:maven-surefire-plugin:jar:2.22.3
[WARNING] The POM for org.apache.maven.plugins:maven-install-plugin:jar:2.4 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-install-plugin:2.4: Plugin 
org.apache.maven.plugins:maven-install-plugin:2.4 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-install-plugin:jar:2.4 has not been downloaded 
from it before.
[WARNING] The POM for org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-deploy-plugin:2.7: Plugin 
org.apache.maven.plugins:maven-deploy-plugin:2.7 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 has not been downloaded 
from it before.
[WARNING] The POM for org.apache.maven.plugins:maven-site-plugin:jar:3.3 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-site-plugin:3.3: Plugin 
org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies could 
not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) 
in offline mode and the artifact 
org.apache.maven.plugins:maven-site-plugin:jar:3.3 has not been downloaded from 
it before.
[WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 is 
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin 
org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been downloaded 
from it before.
[WARNING] The POM for 
org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-5 is missing, no 
dependency information available
[WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its 
dependencies could not be resolved: Cannot access central 

Bug#1069840: maven-dependency-analyzer: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile (default-testCompile) on project maven-dependency-analyz

[Santiago Vila]

Package: src:maven-dependency-analyzer
Version: 1.13.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
mh_patchpoms -plibmaven-dependency-analyzer-java --debian-build --keep-pom-version 
--maven-repo=/<>/debian/maven-repo
   dh_auto_build
/usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar 
-Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml 
-Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode 
package -DskipTests -Dnotimestamp=true -Dlocale=en_US
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were 
deprecated in JDK 13 and will likely be removed in a future release.
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.apache.maven.shared:maven-dependency-analyzer >--
[INFO] Building Apache Maven Dependency Analyzer 1.13.0
[INFO] [ jar ]-
[WARNING] The artifact org.apache.maven.plugins:maven-resources-plugin:jar:2.6 
has been relocated to org.apache.maven.plugins:maven-resources-plugin:jar:3.3.0
[WARNING] The artifact org.apache.maven.plugins:maven-compiler-plugin:jar:3.1 
has been relocated to org.apache.maven.plugins:maven-compiler-plugin:jar:3.10.1
[WARNING] The artifact 
org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4 has been relocated to 
org.apache.maven.plugins:maven-surefire-plugin:jar:2.22.3
[WARNING] The artifact org.apache.maven.plugins:maven-jar-plugin:jar:2.4 has 
been relocated to org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0
[INFO]
[INFO] --- maven-resources-plugin:3.3.0:resources (default-resources) @ 
maven-dependency-analyzer ---
[INFO] skip non existing resourceDirectory /<>/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:compile (default-compile) @ 
maven-dependency-analyzer ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 19 source files to /<>/target/classes
[INFO] 
/<>/src/main/java/org/apache/maven/shared/dependency/analyzer/DefaultProjectDependencyAnalyzer.java:
 
/<>/src/main/java/org/apache/maven/shared/dependency/analyzer/DefaultProjectDependencyAnalyzer.java
 uses or overrides a deprecated API.
[INFO] 
/<>/src/main/java/org/apache/maven/shared/dependency/analyzer/DefaultProjectDependencyAnalyzer.java:
 Recompile with -Xlint:deprecation for details.
[INFO]
[INFO] --- sisu-maven-plugin:0.3.5:main-index (index-project) @ 
maven-dependency-analyzer ---
[INFO]
[INFO] --- maven-resources-plugin:3.3.0:testResources (default-testResources) @ 
maven-dependency-analyzer ---
[INFO] skip non existing resourceDirectory /<>/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @ 
maven-dependency-analyzer ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 11 source files to /<>/target/test-classes
[INFO] 
/<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ProjectDependencyAnalysisTest.java:
 
/<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ProjectDependencyAnalysisTest.java
 uses unchecked or unsafe operations.
[INFO] 
/<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ProjectDependencyAnalysisTest.java:
 Recompile with -Xlint:unchecked for details.
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java:[67,13]
 exception java.io.IOException is never thrown in body of corresponding try statement
[INFO] 1 error
[INFO] -
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  2.735 s
[INFO] Finished at: 2024-04-25T13:27:25Z
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile 
(default-testCompile) on project maven-dependency-analyzer: Compilation failure
[ERROR] 
/<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java:[67,13]
 exception java.io.IOException is never thrown in body of corresponding try statement
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.

Bug#1069837: python3-doc8: internal version is wrongly reported as 0.0.0

[Michael R. Crusoe]

Package: python3-doc8
Version: 0.10.1-1
Severity: normal
Tags: patch
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

I noticed that your package dosage doesn't know its own version number, due to 
upstream using setuptools-scm:

> /usr/lib/python3/dist-packages/doc8-0.0.0.dist-info/INSTALLER
> /usr/lib/python3/dist-packages/doc8-0.0.0.dist-info/METADATA
> /usr/lib/python3/dist-packages/doc8-0.0.0.dist-info/WHEEL
> /usr/lib/python3/dist-packages/doc8-0.0.0.dist-info/entry_points.txt
> /usr/lib/python3/dist-packages/doc8-0.0.0.dist-info/top_level.txt

https://packages.debian.org/sid/all/python3-doc8/filelist

Attached is a patch to fix this. And for your convenience, I've opened a MR on 
Salsa 
https://salsa.debian.org/openstack-team/libs/python-doc8/-/merge_requests/4

Author: Michael R. Crusoe 
Date:   Thu Apr 25 19:03:38 2024 +0300

d/control: build-dep on setuptools-scm to fix wrong "0.0.0" version

diff --git a/debian/control b/debian/control
index 781f221..ba65eba 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,8 @@ Build-Depends:
  pybuild-plugin-pyproject,
  python3-all,
  python3-pbr,
- python3-poetry-core,
+ python3-setuptools,
+ python3-setuptools-scm,
  python3-sphinx,
  python3-sphinx-rtd-theme,
 Build-Depends-Indep:


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069831: kaddressbook: KAddressBook is not in the application launcher.

[Patrick Franz]

Hej Olaf,

Am Donnerstag, 25. April 2024, 14:56:01 CEST schrieb olaf:
> Package: kaddressbook
> Version: 4:22.12.3-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> the term used in the KDE Help Center (KDE-Hilfezentrum) is
> "KAddressBook" ("Das Handbuch zu KAddressBook").
> 
> There is no "KAddressBook" in the "KDE application launcher"
> ("Anwendungsstarter", my translation, what this launcher is called in
> the original is unknown to me).
> 
> However, there is an "Addressbuch" which becomes "KAddressBook" after
> startup.
> 
> Maybe it has something to do with the infantilization of program
> names, as GNOME has done, maybe it is a translation error into German?

I think this is one of those "It's not a bug, it's a feature."

When you type a term into the search field in your application launcher, 
I think it only searches the fields for your system language, highly 
likely by design. I KAddressbook's example, the German translation lists 
"Addresbuch" and therefore the app will show up in your launcher. 
However, it will not show up when you type "kaddressbook" as this term 
is not listed under German.

If you switched your system language to English, it would list the app 
when you search for "kaddressbook", but not when you search for 
"Adressbuch". And this is intentional as you wouldn't want tons of 
results just because your search term matches something in French or 
Swaheli, now would you ?

I'm inclined to close this bug as I don't think that this is a bug...


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1067453: gnat: Ada.Calendar.Clock crashes on time_t64 architectures

[Nicolas Boulenguez]

Source: gcc-13
Followup-For: Bug #1067453

The gettimeofday import issue seems specific to the time_t 64
transition in Debian.

When building C on armhf, a #define replaces gettimeofday with
__gettimeofday64 so the linker finds the 64 bits version in the libc.

When linking Ada code, the linker searches for the gettimeofday symbol
and links with the 32 bits version, as demonstrated by the reproducer
script below.  Here is the output.

./c_part
 timeval size: 128
 tv_sec   offset: 0   size: 64   value: 662A7756
 tv_usec   offset: 8   size: 64   value: 1C54
 56 77 2A 66 00 00 00 00 54 1C 00 00 00 00 00 00
./ada_part
 timeval size: 128
  tv_sec offset: 0   size: 64   value:16#27A9662A7756#
  tv_usec offset: 8   size: 64 value:-16#80B1C0708345E00#
 56 77 2A 66 A9 27 00 00 00 A2 CB F7 F8 E3 F4 F7

Changing the External_Name from "gettimeofday" to "__gettimeofday64"
fixes the mismatch (except for the lower microseconds of course).

./c_part
 81 76 2A 66 00 00 00 00 0F E2 0C 00 00 00 00 00
./ada_part
 81 76 2A 66 00 00 00 00 CB EC 0C 00 00 00 00 00

So we have two possible work-arounds.

 * build a C source with a __gnat_gettimeofday wrapper.
   This option, implemented by my last commit, patches
 gcc/ada/Makefile.rtl
 gcc/ada/cal.c
 gcc/ada/gcc-interface/Makefile.in
 gcc/ada/libgnat-s-osprim__posix.adb
   and interfers with the previous commit.

 * simply patch gcc/ada/libgnat/s-osprim__posix.adb with
-  pragma Import (C, gettimeofday, "gettimeofday");
+  pragma Import (C, gettimeofday, "__gettimeofday64");
  This seems better, but must only be applied on targets affected by
  the t64 transition.

I do not know which one is the best, but at least the second one
explains why the first one did work.

Just in case, here is the reproducer script:

--
#!/bin/sh
set -efuv

cat > hexdump.h < hexdump.c <
#include "hexdump.h"
void hexdump(char* p, int length)
{
  while (length--)
  {
printf(" %02hhX", *p++);
  }
  printf("\n");
}
EOF

cat > c_part.c <
#include 
#include 
#include 
#include "hexdump.h"
int main(int argc, const char* argv[]) {
  struct timeval tv;
  if (argc == 1)
  {
printf(" gettimeofday returned %i\n", gettimeofday(, NULL));
printf(" timeval size: %lli\n", (long long int)( CHAR_BIT * sizeof(tv)));
printf(" tv_sec");
printf("   offset: %lli", (long long int)((char*)(&(tv.tv_sec)) - 
(char*)()));
printf("   size: %lli",   (long long int)(CHAR_BIT * sizeof(tv.tv_sec)));
printf("   value: %llX",  (long long int)tv.tv_sec);
printf("\n");
printf(" tv_usec");
printf("   offset: %lli", (long long int)((char*)(&(tv.tv_usec)) - 
(char*)()));
printf("   size: %lli",   (long long int)(CHAR_BIT * sizeof(tv.tv_usec)));
printf("   value: %llX",  (long long int)tv.tv_usec);
printf("\n");
hexdump((char*)(), sizeof(tv));
  }
  else
  {
printf("   time_t_bits  : constant := %lli;\n",
   (long long int)(CHAR_BIT * sizeof(tv.tv_sec)));
printf("   suseconds_t_bits : constant := %lli;\n",
   (long long int)( CHAR_BIT * sizeof(tv.tv_usec)));
  }
  return EXIT_SUCCESS;
}
EOF

cat > ada_part.adb < C;
   type suseconds_t is range -2**(suseconds_t_bits - 1) ..
  2**(suseconds_t_bits - 1) - 1
 with Convention => C;
   type timeval is record
  tv_sec  : time_t;
  tv_usec : suseconds_t;
   end record with Convention => C;
   function gettimeofday (tv : access timeval; tz : Address) return int
 with Import, Convention => C,
  External_Name => "gettimeofday"; --  Here
   Tv : aliased timeval;
   function Offset (A, B : Address) return String is
 (Long_Long_Integer'Image (Long_Long_Integer'Value (A'Img)
 - Long_Long_Integer'Value (B'Img)));
   I : constant int := gettimeofday(Tv'Access, Null_Address);
   procedure hexdump(p : Address; count : Integer)
 with Import, Convention => C, External_Name => "hexdump";
begin
  Put_Line (" gettimeofday returned" & I'Img);
  Put_Line (" timeval size:" & Integer'Image (Tv'Size));
  Put ("  tv_sec offset:" & Offset (Tv.tv_sec'Address, Tv'Address)
   & "   size:" & Integer'Image (Tv.tv_sec'Size)
   & "   value:");
  Put (Long_Long_Integer (Tv.tv_sec), Width => 0, Base => 16);
  New_Line;
  Put ("  tv_usec offset:" & Offset (Tv.tv_usec'Address, Tv'Address)
   & "   size:" & Integer'Image (Tv.tv_usec'Size)
   & " value:");
  Put (Long_Long_Integer (Tv.tv_usec), Width => 0, Base => 16);
  New_Line;
  hexdump (Tv'Address, Tv'Size / 8);
end Ada_Part;
EOF

gcc -c -Wall -Wextra hexdump.c -o hexdump.o
gcc -Wall -Wextra c_part.c hexdump.o -o c_part
gnatmake -gnat2022 -gnatwa -gnatya ada_part.adb -largs hexdump.o

./c_part
./ada_part

Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates

[Santiago Vila]

severity 1065660 serious
tags 1065660 + ftbfs
thanks

Hello.

I noticed that chemicaltagger currently FTBFS and I believe it is because
of this problem, so to avoid duplicate reports, I'm raising this one to serious.

A build log for chemicaltagger is available here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html

By raising the severity of this bug, I'm assuming that this will be eventually 
fixed
in antlr4-maven-plugin and chemicaltagger will not need to be changed to build 
again,
but I really have no idea if such thing will happen. If it does not, we would 
need
a different FTBFS bug for chemicaltagger so that it's fixed there.

Thanks.

Bug#1069836: bullseye-pu: package libkf5ksieve/20.08.3-1+deb11u1

[Patrick Franz]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: delta...@debian.org
User: release.debian@packages.debian.org
Usertags: pu

This is the same request as for bookworm (#1069690).
Relevant bug report is #1069163.

[ Reason ]
There is a bug in libkf5sieve where the password instead of the
username is sent when using managesieve and could therefore be
logged on a server as the login will fail.

[ Impact ]
Potentially sensitive passwords are logged on a server.

[ Tests ]
Affected user has successfully tested the patched version.

[ Risks ]
The patch is trivial (1 line is changed) and it's quite obvious
that it was a bug in the first place.

[ 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 ]
1-line patch to fix the bug.
diffstat for libkf5ksieve-20.08.3 libkf5ksieve-20.08.3

 changelog   |8 
 patches/password_leak.patch |   30 ++
 patches/series  |1 +
 3 files changed, 39 insertions(+)

diff -Nru libkf5ksieve-20.08.3/debian/changelog 
libkf5ksieve-20.08.3/debian/changelog
--- libkf5ksieve-20.08.3/debian/changelog   2020-12-16 01:50:06.0 
+0100
+++ libkf5ksieve-20.08.3/debian/changelog   2024-04-25 12:37:50.0 
+0200
@@ -1,3 +1,11 @@
+libkf5ksieve (4:20.08.3-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Add patch to prevent leaking passwords into server-side logs
+(Closes: #1069163).
+
+ -- Patrick Franz   Thu, 25 Apr 2024 12:37:50 +0200
+
 libkf5ksieve (4:20.08.3-1) unstable; urgency=medium
 
   [ Sandro Knauß ]
diff -Nru libkf5ksieve-20.08.3/debian/patches/password_leak.patch 
libkf5ksieve-20.08.3/debian/patches/password_leak.patch
--- libkf5ksieve-20.08.3/debian/patches/password_leak.patch 1970-01-01 
01:00:00.0 +0100
+++ libkf5ksieve-20.08.3/debian/patches/password_leak.patch 2024-04-25 
12:36:16.0 +0200
@@ -0,0 +1,30 @@
+From 6b460ba93ac4ac503ba039d0b788ac7595120db1 Mon Sep 17 00:00:00 2001
+From: Laurent Montel 
+Date: Wed, 8 Mar 2023 06:51:22 +0100
+Subject: [PATCH] Fix 467034: libksieve/src/kmanagesieve/session.cpp assigns
+ password to username & gets logged(
+
+Bug investigate by "bib" thanks
+BUG: 467034
+BUG: 437858
+FIXED-IN: 5.23.0
+---
+ src/kmanagesieve/session.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/kmanagesieve/session.cpp b/src/kmanagesieve/session.cpp
+index 26fd7b59..0e40d721 100644
+--- a/src/kmanagesieve/session.cpp
 b/src/kmanagesieve/session.cpp
+@@ -273,7 +273,7 @@ KManageSieve::AuthDetails 
Session::requestAuthDetails(const QUrl )
+ AuthDetails ad;
+ ad.valid = false;
+ if (dlg->exec()) {
+-ad.username = dlg->password();
++ad.username = dlg->username();
+ ad.password = dlg->password();
+ ad.valid = true;
+ }
+-- 
+GitLab
+
diff -Nru libkf5ksieve-20.08.3/debian/patches/series 
libkf5ksieve-20.08.3/debian/patches/series
--- libkf5ksieve-20.08.3/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libkf5ksieve-20.08.3/debian/patches/series  2024-04-25 12:36:09.0 
+0200
@@ -0,0 +1 @@
+password_leak.patch

Bug#1069690: bookworm-pu: package libkf5ksieve/4:22.12.3-1+deb12u1

[Patrick Franz]

Hi,

forgot to mention: The relevant bug report for libkf5ksieve is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069163


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1024889: Pending

[Andreas Tille]

Control: tags -1 pending
Control: block -1 by 1064596
thanks

Pplacer needs to be build against the old version of MCL
which is featuring some OCAML patch.  This old version was
just uploaded to new.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Bug#1062965: Re: Bug#1069810: qt6-tools:6.4.2: Please add support for loongarch64

[Patrick Franz]

Hej,

Am Donnerstag, 25. April 2024, 13:49:46 CEST schrieb 王怀卿:
[...]
> Would you
> please provide an approximate timeline for the release of the 6.6.2
> version of qt6-tools by the Debian community?

I'm sorry, but I cannot. I doubt anyone can. 

The time_t transition is quite complex and the first packages have 
started to migrate to testing, but It's unknown when all relevant 
packages for Qt 6 can migrate.
What you can do is check when qt6-base migrates. That might give you an 
idea how long it's going to take until 6.6.2 is available.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

Hi,

Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl' is removed from the mount options.


Which doesn't do IO itself though? But maybe the KDE file picker (over 
kio) does something weird? But saving (ttbomk) isn't done by the file 
picker itself?



There also is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935182 
since some time.



It looks a bit like the issue found in [2].


Which doesn't touch any KDE stuff either. In fact it caused 32bit builds 
to fail[1] and I don't know what more regressions this caused. I would 
be wary of "just" backporting it in a point release...



Regards,

Rene

[1] by relying on internal glibc/kernel types, see 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/libreoffice_24.2.2_rc1-2/patches/fix-32bit-build.diff?ref_type=tags 
-


 later updated upstream for 
https://cgit.freedesktop.org/libreoffice/core/commit/sal/osl/unx/file.cxx?id=434065478d35fe8e144aec916ac06438c0150270

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Rene Engelhard]

close 1069835 4:24.2.2-1

forwarded 1069835 https://bugs.documentfoundation.org/show_bug.cgi?id=55004

tag 1069835 + moreinfo

thanks


Am 25.04.24 um 17:03 schrieb Andreas B. Mundt:

Package: libreoffice-kf5


Version?



Severity: grave


Come on... Not downgrading just yet, but I don't believe it's grave.


we run Debian bookworm KDE plasma clients with home directories
mounted from an SMB share.  From time to time, users reported that

Ah, bookworm. You should have mentioned it in Version:

libreoffice documents have disappeared completely when closing
libreoffice.  We were now able to reproduce the issue on both,
the current bookworm and bookworm-backports version of libreoffice.

Mount an SMB share. I use the following in fstab:
   //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0

Open/create an ODT document, write some text, save the file and check
it's appearance on the share.  Then click Insert → Image and (perhaps
with the image still selected in the document) close libreoffice.
The file disappears on the share.  This is almost always reproducible
(we tested multiple SMB servers) if not, just open the file again,
insert another image, Ctrl-S, Ctrl-Q, the file is gone!

If 'nobrl' is removed from the mount options (but we need it for other
programs to work properly), instead of the file disappearing, a popup
shows:

   Error saving the document Untitled 1:
   Error creating object.
   Could not create backup copy.

This looks like already reported upstream [1].

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl'
It looks a bit like the issue found in [2].


So fixed in sid?

(If I only could update the bookworm backport to 24.2.2+, but given it's 
sstill stuck behind time_t...)



Regards,


Rene

Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares

[Andreas B. Mundt]

Package: libreoffice-kf5
Severity: grave

Dear Rene, everybody,

we run Debian bookworm KDE plasma clients with home directories
mounted from an SMB share.  From time to time, users reported that
libreoffice documents have disappeared completely when closing
libreoffice.  We were now able to reproduce the issue on both,
the current bookworm and bookworm-backports version of libreoffice.

Mount an SMB share. I use the following in fstab:
  //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0

Open/create an ODT document, write some text, save the file and check
it's appearance on the share.  Then click Insert → Image and (perhaps
with the image still selected in the document) close libreoffice.
The file disappears on the share.  This is almost always reproducible
(we tested multiple SMB servers) if not, just open the file again,
insert another image, Ctrl-S, Ctrl-Q, the file is gone!

If 'nobrl' is removed from the mount options (but we need it for other
programs to work properly), instead of the file disappearing, a popup
shows:

  Error saving the document Untitled 1:
  Error creating object.
  Could not create backup copy.

This looks like already reported upstream [1].

For now, we traced the issue back to libreoffice-kf5.  If this package
is removed, neither the document disappears on closing libreoffice nor
the popup is shown when 'nobrl' is removed from the mount options.

It looks a bit like the issue found in [2].

Thanks for maintaining libreoffice,
best regards,

  Andi


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=160315 
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=55004#c56

Bug#1069834: sccache FTBFS with itoa != 0.3.4

[Adrian Bunk]

Source: sccache
Version: 0.8.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=sccache=0.8.0-1

...
test test_rust_cargo_cmd_readonly_preemtive_block ... FAILED

failures:

 test_rust_cargo_cmd_readonly_preemtive_block stdout 
Error: Unexpected failure.
code=101
stderr=``
error: failed to select a version for the requirement `itoa = \"^0.3.4\"` 
(locked to 0.3.4)
candidate versions found which didn\'t match: 1.0.9
location searched: directory source `/<>/debian/cargo_registry` 
(which is replacing registry `crates-io`)
required by package `test-crate v0.1.0 (/<>/tests/test-crate)`
perhaps a crate was updated and forgotten to be re-vendored?
```
```
command=`cd "tests/test-crate" && CARGO_INCREMENTAL="0" 
CARGO_TARGET_DIR="/<>/debian/sccache_test_rust_cargoG4h5iT/cargo" 
RUSTC_WRAPPER="/<>/target/x86_64-unknown-linux-gnu/release/sccache"
 TEST_ENV_VAR="1" "/usr/bin/cargo" "build" "--color=never"`
code=101
stdout=""
stderr=```
error: failed to select a version for the requirement `itoa = \"^0.3.4\"` 
(locked to 0.3.4)
candidate versions found which didn\'t match: 1.0.9
location searched: directory source `/<>/debian/cargo_registry` 
(which is replacing registry `crates-io`)
required by package `test-crate v0.1.0 (/<>/tests/test-crate)`
perhaps a crate was updated and forgotten to be re-vendored?
```



Stack backtrace:
   0: 
   1: 
   2: 
   3: 
   4: 
   5: 
   6: 
   7: 
   8: 
   9: 
  10: 


failures:
test_rust_cargo_cmd_readonly_preemtive_block

test result: FAILED. 2 passed; 1 failed; 5 ignored; 0 measured; 0 filtered out; 
finished in 11.18s

error: test failed, to rerun pass `--test sccache_cargo`
dh_auto_test: error: env DEB_BUILDDIR= 
/<>/debian/dh-cargo/bin/cargo test returned exit code 101
make[1]: *** [debian/rules:29: override_dh_auto_test] Error 25

Bug#1069833: git-cola: internal version is wrongly reported as 0.0.0

[Michael R. Crusoe]

Package: git-cola
Version: 4.3.2-1
Severity: normal
Tags: patch
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

I noticed that your package dosage doesn't know its own version number, due to 
upstream using setuptools-scm:

> /usr/lib/python3/dist-packages/git_cola-0.0.0.dist-info/INSTALLER
> /usr/lib/python3/dist-packages/git_cola-0.0.0.dist-info/METADATA
> /usr/lib/python3/dist-packages/git_cola-0.0.0.dist-info/WHEEL
> /usr/lib/python3/dist-packages/git_cola-0.0.0.dist-info/entry_points.txt
> /usr/lib/python3/dist-packages/git_cola-0.0.0.dist-info/top_level.txt

https://packages.debian.org/sid/all/git-cola/filelist

Attached is a patch to fix this.

--- debian/control.orig	2024-04-25 14:15:31.419546205 +
+++ debian/control	2024-04-25 14:12:30.645724504 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Build-Depends: debhelper-compat (= 13), dh-python, pybuild-plugin-pyproject
-Build-Depends-Indep: python3, python3-qtpy, python3-sphinx, rsync, git-core, gettext, asciidoc (>= 8.2), xmlto
+Build-Depends-Indep: python3, python3-setuptools-scm, python3-qtpy, python3-sphinx, rsync, git-core, gettext, asciidoc (>= 8.2), xmlto
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://git-cola.github.io/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml

[Andrey Rakhmatullin]

Control: reopen -1

On Fri, Apr 26, 2024 at 12:12:06AM +1000, Dmitry Smirnov wrote:
> > Source: gnucash
> > Version: 1:5.5-1.1
> > Severity: serious
> > 
> > Simply build the package from source produces a source package that doesn't
> > contain debian/.gitlab-ci.yml in debian.tar, one needs to rebuild the
> > source package separately, skipping the clean target. The reason for that
> > is that the file is listed debian/clean for some reason (alternatively, if
> > it shouldn't be in the package, please remove it from the package).
> 
> This is ridiculous. 
I agree.

> Obviously '.gitlab-ci.yml' is a repository-specific file with
> configuration of Gitlab CI on Salsa. There is no reason to ship it with
> source package 
Yet you are shipping it, maybe you should reconsider that?

$ tar tvf gnucash_5.5-1.2.debian.tar.xz debian/.gitlab-ci.yml
-rw-rw-r-- 0/0 759 2024-02-23 22:55 debian/.gitlab-ci.yml


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#985017: python3-whoosh: SyntaxWarning during package installation

[Patrik Schindler]

Issue still exists after being reported over three years ago.

:wq! PoC

Bug#949969: transmission-gtk uses 100% of a CPU core

[Francois Gouget]

On Thu, 25 Apr 2024, Alexandre Rossi wrote:
> Hi,
> 
> The example torrent is not available anymore.
>
> Downloading a torrent with transmission 4 from unstable does not use 100%
> CPU core.
> 
> Can you reproduce?

I have upgraded to 4.0.2-1 since then and I am now using the QT client. 
But using the updated torrent (see http://osm.cquest.org/torrents) top 
still reports Transmission using a full core:

$ top -n1 | grep trans
  10472 fgouget   20   0 3520476 328540  62496 S 118.8   1.0 330:01.80 transmi+ 

So 118% CPU.

But in ps the CPU usage is stuck at 3.7%:
$ ps aux | grep trans
fgouget10472  3.7  1.0 3520476 329364 ?  Sl   Apr19 329:41 
/usr/bin/transmission-qt -session 
10cae0c76f00017076185990334600170_1710862333_885767

This is while downloading the current osm.pdf.torrent file at a reported 
150 MB/s average speed (1200 Mbps). While this is a 1 Gbps Internet 
connection and it is indeed maxed out, that still at most 125 MB/s. So I 
think the data must be compressed and transmission is reporting the 
uncompressed data transfer rate.

Also now that the transfer is complete transmission is back to 0% CPU 
usage.

So maybe transmission was just kept busy by the fast transfer rate? 
(i7-4790K, verifying and uncompressing the data)


> Special parameters?

Nothing that I know of. I'm not limiting the download speed obviously.
Here are some possibly relevant settings from 
~/.config/transmission/settings.json:

"alt-speed-enabled": false,
"cache-size-mb": 4,
"dht-enabled": true,
"encryption": 1,
"lazy-bitfield-enabled": true,
"lpd-enabled": false,
"peer-congestion-algorithm": "",
"peer-limit-global": 240,
"peer-limit-per-torrent": 60,
"peer-socket-tos": "",
"pex-enabled": true,
"port-forwarding-enabled": true,
"proxy-auth-enabled": false,
"proxy-enabled": false,
"queue-stalled-enabled": true,
"queue-stalled-minutes": 30,
"speed-limit-down-enabled": false,
"speed-limit-up-enabled": false,
"utp-enabled": true,


-- 
Francois Gouget   http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene 
Wigner

Bug#1069832: dosage: internal version is wrongly reported as 0.0.0

[Michael R. Crusoe]

Package: dosage
Version: 3.0+dfsg-1
Severity: normal
Tags: patch
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

I noticed that your package dosage doesn't know its own version number, due to 
upstream using setuptools-scm:

> /usr/lib/python3/dist-packages/dosage-0.0.0.dist-info/INSTALLER
> /usr/lib/python3/dist-packages/dosage-0.0.0.dist-info/METADATA
> /usr/lib/python3/dist-packages/dosage-0.0.0.dist-info/WHEEL
> /usr/lib/python3/dist-packages/dosage-0.0.0.dist-info/entry_points.txt
> /usr/lib/python3/dist-packages/dosage-0.0.0.dist-info/top_level.txt

https://packages.debian.org/sid/all/dosage/filelist

Attached is a patch to fix this. And for your convenience, I've opened a MR on 
Salsa: https://salsa.debian.org/debian/dosage/-/merge_requests/1
commit 5fce4d3021304f19e7bb58886f0917e1a3959388
Author: Michael R. Crusoe 
Date:   Thu Apr 25 16:39:05 2024 +0300

d/control: build-dep on setuptools-scm to fix wrong "0.0.0" version

diff --git a/debian/control b/debian/control
index 47413bb..dbc2ff4 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,8 @@ Build-Depends: debhelper-compat (= 13),
pybuild-plugin-pyproject,
python3,
python3-colorama,
-   python3-setuptools
+   python3-setuptools,
+   python3-setuptools-scm
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://dosage.rocks


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#949969: transmission-gtk uses 100% of a CPU core

[Alexandre Rossi]

Hi,

The example torrent is not available anymore.

Downloading a torrent with transmission 4 from unstable does not use 100%
CPU core.

Can you reproduce? Special parameters?

Thanks,

Alex

Bug#464122: Forgot filename

[Petter Reinholdtsen]

[Bartek Kania 2008-02-05]
> Forgot to specify that the problem is in output.c

I suspect the patch you propose is this one:

diff --git a/output.c b/output.c
index dbd85be..b0ab93b 100644
--- a/output.c
+++ b/output.c
@@ -84,7 +84,7 @@ void output()
 if (language == PERL) {
   fprintf(code_file, "sub new {\n");
   if (perl5005flag) {
-   fprintf(code_file, "  my %s $p = bless [\\%FIELDS], $_[0];\n",
+   fprintf(code_file, "  my %s $p = bless [\\%%FIELDS], $_[0];\n",
perl_package);
   }
   else {


Unfortunately I do not have any way to test if it work or not.  Do you
have some test files that can be used to demonstrate the problem?
-- 
Happy hacking
Petter Reinholdtsen

Bug#1069258: ruby-curb: test regression with curl 8.7.1: client read function EOF fail, only only 4/5 of needed bytes read

[Simon McVittie]

Control: retitle -1 ruby-curb: test regression with curl 8.7.1: client read 
function EOF fail, only only 4/5 of needed bytes read
User: debian...@lists.debian.org
Usertags: breaks needs-update

On Thu, 18 Apr 2024 at 22:42:11 +0200, Sebastian Ramacher wrote:
> Error: test_easy_http_verbs(TestCurbCurlEasy): Curl::Err::ReadError: Failed 
> to open/read local data from file/application: client read function EOF fail, 
> only only 4/5 of needed bytes read
...
> Error: test_put_data(TestCurbCurlEasy): Curl::Err::ReadError: Failed to 
> open/read local data from file/application: client read function EOF fail, 
> only only 6/7 of needed bytes read
...
> Error: test_put_data_null_bytes(TestCurbCurlEasy): Curl::Err::ReadError: 
> Failed to open/read local data from file/application: client read function 
> EOF fail, only only 2/3 of needed bytes read

These messages with "only only (n)/(n+1) of needed bytes read" seem to
be characteristic. As well as being a FTBFS, this is also an autopkgtest
regression when upgrading curl, which is one of several factors preventing
curl from migrating; that, in turn, blocks elfutils, which blocks GLib,
which will likely be blocking a significant chunk of the 64-bit time_t
transition.

This could either be a regression in curl, or a pre-existing bug in
ruby-curb that was exposed by a behaviour change in curl (for example
maybe curl started applying stricter checks). I don't know curl well
enough to say which, but perhaps the curl maintainers can help? This
upstream commit introduced the new error message and seems relevant:
https://github.com/curl/curl/commit/9369c30cd87c041cf983bcdfabd1570980abbaf6

Here is a convenient reproducer in an unprivileged container:

$ podman run -v $(pwd):$(pwd):rw -w $(pwd) -it debian:trixie-slim
# sed -i -e 's/Types: deb/& deb-src/' /etc/apt/sources.list.d/debian.sources
# apt update
# apt upgrade
# apt install --no-install-recommends build-essential
# apt source ruby-curb
# cd ruby-curb-*
# apt --no-install-recommends build-dep .
# dpkg-buildpackage -us -uc -B
... succeeds ...
# sed -i -e 's/Suites: trixie /Suites: sid /'
# apt --no-install-recommends install curl
...
The following additional packages will be installed:
  libcurl3t64-gnutls libcurl4-gnutls-dev libcurl4t64
Suggested packages:
  libcurl4-doc libgnutls28-dev libidn-dev libkrb5-dev libldap2-dev librtmp-dev 
libssh2-1-dev pkgconf zlib1g-dev
The following packages will be REMOVED:
  libcurl3-gnutls
The following NEW packages will be installed:
  curl libcurl3t64-gnutls libcurl4t64
The following packages will be upgraded:
  libcurl4-gnutls-dev
...
# dpkg-buildpackage -us -uc -B
... fails as seen in the buildd log ...

Thanks,
smcv

Bug#1069831: kaddressbook: KAddressBook is not in the application launcher.

[olaf]

Package: kaddressbook
Version: 4:22.12.3-1+b1
Severity: normal

Dear Maintainer,

the term used in the KDE Help Center (KDE-Hilfezentrum) is
"KAddressBook" ("Das Handbuch zu KAddressBook").

There is no "KAddressBook" in the "KDE application launcher"
("Anwendungsstarter", my translation, what this launcher is called in
the original is unknown to me).

However, there is an "Addressbuch" which becomes "KAddressBook" after
startup.

Maybe it has something to do with the infantilization of program
names, as GNOME has done, maybe it is a translation error into German?


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

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

Versions of packages kaddressbook depends on:
ii  akonadi-server  4:22.12.3-1+b1
ii  kaddressbook-data   4:22.12.3-1
ii  kdepim-runtime  4:22.12.3-2
ii  libc6   2.38-6
ii  libgcc-s1   14-20240330-1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.12] 4:22.12.3-1+b1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]   4:22.12.3-1+b1
ii  libkf5akonadisearch-bin 4:22.12.3-1+b1
ii  libkf5akonadisearch-plugins 4:22.12.3-1+b1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-2  4:22.12.3-1+b1
2.12]
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.12  4:22.12.3-1+b1
]
ii  libkf5configcore5   5.107.0-1+b1
ii  libkf5configgui55.107.0-1+b1
ii  libkf5configwidgets55.107.0-2+b1
ii  libkf5contacts5 5:5.107.0-1
ii  libkf5coreaddons5   5.107.0-1+b1
ii  libkf5crash55.107.0-1+b1
ii  libkf5grantleetheme5 [libkf5grantleetheme5-22.12]   22.12.3-2+b1
ii  libkf5i18n5 5.107.0-1+b1
ii  libkf5itemmodels5   5.107.0-1+b1
ii  libkf5kcmutils5 5.107.0-2+b1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-22.12  22.12.3-1+b1
]
ii  libkf5libkdepim5 [libkf5libkdepim5-22.12]   4:22.12.3-1
ii  libkf5parts55.107.0-1+b1
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-22.12]   4:22.12.3-1
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-2  4:22.12.3-1
2.12]
ii  libkf5widgetsaddons55.107.0-1+b1
ii  libkf5xmlgui5   5.107.0-1+b1
ii  libkpimaddressbookimportexport5 [libkpimaddressbookimp  4:22.12.3-1+b1
ortexport5-22.12]
ii  libkuserfeedbackcore1   1.3.0-3+b1
ii  libkuserfeedbackwidgets11.3.0-3+b1
ii  libqt5core5t64 [libqt5core5a]   5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64 [libqt5dbus5]5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64 [libqt5gui5]  5.15.10+dfsg-7.2+b1
ii  libqt5printsupport5t64 [libqt5printsupport5]5.15.10+dfsg-7.2+b1
ii  libqt5widgets5t64 [libqt5widgets5]  5.15.10+dfsg-7.2+b1
ii  libstdc++6  14-20240330-1

Versions of packages kaddressbook recommends:
ii  kdepim-addons  22.12.3-1

kaddressbook suggests no packages.

-- no debconf information

Bug#716290: [Mayhem] Bug report on perl-byacc: pbyacc crashes with exit status 139

[Petter Reinholdtsen]

Control: tags -1 + patch

I believe the following patch fixes the problem, and it was just added
to the Debian package uploaded to the archive.

--- perl-byacc-2.0.orig/main.c
+++ perl-byacc-2.0/main.c
@@ -314,6 +314,12 @@ end_of_option:;
 if (language != PERL && perl5005flag)
 fprintf(stderr, "%s: Warning: -5 has no effect without Perl mode.\n",
myname);
+if (language == PERL && !perl_package)
+{
+fprintf(stderr, "%s: Perl mode require package name.\n",
+   myname);
+   exit(1);
+}
 
 no_more_options:;
 if (i + 1 != argc) usage();

Bug#1069830: libccrtp-doc: missing Breaks+Replaces: libccrtp-dev (<< 2.0.9-3)

[Andreas Beckmann]

Package: libccrtp-doc
Version: 2.0.9-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libccrtp-doc_2.0.9-3_all.deb ...
  Unpacking libccrtp-doc (2.0.9-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libccrtp-doc_2.0.9-3_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/libccrtp-dev/NEWS.gz', which is also in 
package libccrtp-dev 2.0.9-2.3
  Errors were encountered while processing:
   /var/cache/apt/archives/libccrtp-doc_2.0.9-3_all.deb

This is probably caused by a behavior change of dh_installdocs (w.r.t.
the doc main package) in newer compat levels.

cheers,

Andreas


libccrtp-dev=2.0.9-2.3_libccrtp-doc=2.0.9-3.log.gz
Description: application/gzip

Bug#1069758: sorry for the duplicate!

[Manny]

> Sorry, why report again?
> You don't get anything by reporting the same issue  multiple times.
> 
> Closing.

Sorry for the dupe!

Sometimes my submissions don’t make it to the BTS for some reason and
due to some tech issues on my side I thought this was one of those
cases. You apparently fixed it so fast that when I did a search today
to see if the report was filed, it was already resolved.

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Julian Andres Klode]

Control: severity -1 important

Control: user release.debian@packages.debian.org
Control: usertags -1 time-t-downgrade

On Thu, Mar 07, 2024 at 04:10:17PM +0100, Vincent Lefevre wrote:
> Package: libgtk2.0-0t64
> Version: 2.24.33-4
> Severity: serious
> 
> During an upgrade with aptitude:
> 
> dpkg: dependency problems prevent removal of libgtk2.0-common:
>  libgtk2.0-bin depends on libgtk2.0-common.
>  libgtk2.0-0t64:amd64 depends on libgtk2.0-common.
> 
> dpkg: error processing package libgtk2.0-common (--purge):
>  dependency problems - not removing
> Errors were encountered while processing:
>  libgtk2.0-common
> 
> Note that "apt install -f" has nothing to fix; this upgrade just
> triggered a dpkg error (similar to bugs 1065603 and 1065625).
> 
> Moreover, like in these bugs, aptitude did not propose the removal
> of libgtk2.0-common:
> 
> Aptitude 0.8.13: log report
> Thu, Mar  7 2024 16:01:36 +0100
> 
>   IMPORTANT: this log only lists intended actions; actions which fail
>   due to dpkg problems may not be completed.
> 
> Will install 5 packages, and remove 2 packages.
> 2048 B of disk space will be used
> 
> [...]
> [HOLD, DEPENDENCIES] libgtk2.0-common:amd64 2.24.33-3
> [...]
> [INSTALL, DEPENDENCIES] libgail18t64:amd64 2.24.33-4
> [INSTALL, DEPENDENCIES] libgtk2.0-0t64:amd64 2.24.33-4
> [REMOVE, DEPENDENCIES] libgail18:amd64 2.24.33-3
> [REMOVE, DEPENDENCIES] libgtk2.0-0:amd64 2.24.33-3
> [...]
> [UPGRADE] gtk2-engines-pixbuf:amd64 2.24.33-3 -> 2.24.33-4
> [UPGRADE] libgail-common:amd64 2.24.33-3 -> 2.24.33-4
> [UPGRADE] libgtk2.0-bin:amd64 2.24.33-3 -> 2.24.33-4
> 


Downgrading this bug to important as it is currently a blocker
for aptitude migration due to the dual assignment, and even for
libgtk2.0-0t64, I'd argue getting it migrated is more important
than a aptitude ordering issue.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1069829: ITP: python-samsung-mdc -- Samsung Multiple Display Control

[Hugh McMaster]

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

* Package name: python-samsung-mdc
  Version : 1.12.1
  Upstream Contact: Victor Gavro 
* URL : https://pypi.org/project/python-samsung-mdc
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Samsung Multiple Display Control

Samsung-MDC is an implementation of the Samsung Multiple Display Control
Protocol using python and asyncio.

Samsung-MDC allows users to control compatible Samsung displays through the
built-in RS-232C or Ethernet interface. 74 commands are supported.

This package includes a command-line interface and python module.

This is the Python 3 version of the package.



I usually install python-samsung-mdc via PyPi and use it to control multiple
Samsung large format displays.

Bug#1069828: [debian trixie] [package procps] w segmentation fault

[David]

Package: procps
Version: 2:4.0.4-4

Hello, it seems there is a bug in the debian package "procps" with the
"w"utility.
it produce a segfault when using the "-s" argument.
I tried download and compile from source, and the bug is not present.
it is only present with the debian system package (debian trixie).

david@debian12:~/procps/procps-4.0.4/src$ ./w -s
 00:10:33 up 53 min,  1 user,  load average: 0,47, 0,64, 0,64
USER TTY IDLE WHAT
davidtty7  53:23  xfce4-session
david@debian12:~/procps/procps-4.0.4/src$ w -s
 00:10:38 up 53 min,  1 user,  load average: 0,43, 0,63, 0,64
UTIL.TTY  DEIDLE QUOI
Erreur de segmentation
david@debian12:~/procps/procps-4.0.4/src$ uname -a
Linux debian12 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2
(2024-02-04) x86_64 GNU/Linux
david@debian12:~/procps/procps-4.0.4/src$

Bug#1069793: wrong package name mnt-reform-setup-wizard -- should be reform-setup-wizard

[Andreas Beckmann]

Followup-For: Bug #1069793

reform-setup-wizard misses
  Breaks+Replaces: mnt-reform-setup-wizard (<< 0.1.0-3)
for the package rename.


Andreas

Bug#1069827: RM: python-workalendar -- ROM; Abandoned upstream; leaf-package

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The last update by upstream was 2 years ago and there is an active fork[0] under
a different name that I intend to package for Debian.

[0] https://github.com/jaraco/calendra

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmYqSNYbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqQzoIAIMsE7mlVo+8rpcYW5Cu
/w1HiUaYI9B8fJxbrALqE2bG2BoO+Qzy+7YG6eYUhNJwhRGKORa2dXZ8IN4BScPq
dDGJN3kMz0qwIQ3kvu+YrosPaUUaTWSE+Ln76J+6Sm5xoSMBiY+wisLscOjQOSrg
u1UDzbGb71sLb5m7xj3WGbvZNh0gYivbQrbn5Fi3mZsXjiK9OjrPHBd6hCDbgE0U
YBuWyOAJ4b4s92ZChPZEwJL2G7xc6j/f8OP843EjA7GV8Q9wqdFw6XnoGNX/bkw6
NJ6Bx70bYx4AUm/jpYn/n77EmSnuuJapN0IzIH6FGPztAkuptWE8ix8bAwwCrdxQ
iHM=
=XxrQ
-END PGP SIGNATURE-

Bug#1069826: stravalib: FTBFS: tests fail with ModuleNotFoundError: No module named 'pytz'

[Andreas Beckmann]

Source: stravalib
Version: 1.3.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

stravalib recently started to FTBFS, probably due to a change in on eof
its (transitive) build-depends:

 ERRORS 
__ ERROR collecting stravalib/tests/unit/test_client_utils.py __
ImportError while importing test module 
'/build/stravalib-1.3.0/stravalib/tests/unit/test_client_utils.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
stravalib/__init__.py:1: in 
from stravalib.client import Client
stravalib/client.py:19: in 
import pytz
E   ModuleNotFoundError: No module named 'pytz'
...

Comparing the current build log with the last successful one from March
16, I noticed that python3-tz does no longer get installed.


Andreas


stravalib_1.3.0-1.log.gz
Description: application/gzip

Bug#1062965: Re: Bug#1069810: qt6-tools:6.4.2: Please add support for loongarch64

[王怀卿]

> -原始邮件-
> 发件人: "Patrick Franz" 
> 发送时间:2024-04-25 18:19:55 (星期四)
> 收件人: sub...@bugs.debian.org, debian-qt-...@lists.debian.org, 王怀卿 
> , 1069...@bugs.debian.org
> 抄送: 王洪虎 , 宋鼎 , 杨小娟 
> , 桑猛 , 1062...@bugs.debian.org
> 主题: Re: Bug#1069810: qt6-tools:6.4.2: Please add support for loongarch64
> 
> Hej,
> 
> I will likely not add this patch for 6.4.2 as my plan regarding Qt 6 is 
> the following:
> 
> During the time_t transition, I only want to change or fix what is 
> absolutely necessary for the transition to succeed. Adding support for 
> loong64 is not among that. 
> Once the transition is completed for Qt 6, I want to push Qt 6.6.2 to 
> unstable which builds successfully on loong64.
> 
> Thanks for your understanding.
> 
> 
> -- 
> Med vänliga hälsningar
> 
> Patrick Franz
> 

Thank you for your reply and explanation.

As shown below the dashed line, I noticed that the issue has been resolved in 
the control file of version 6.6.2 of qt6-tools.
Would you please provide an approximate timeline for the release of the 6.6.2 
version of qt6-tools by the Debian community?
-
Source: qt6-tools
Section: libs
Priority: optional
Maintainer: Debian Qt/KDE Maintainers 
Uploaders: Patrick Franz ,
Build-Depends: clang-17,
   cmake (>= 3.24~),
   debhelper-compat (= 13),
   libclang-17-dev,
   libcurl4-openssl-dev | libcurl4-dev,
   libgl-dev,
   liblitehtml-dev (>= 0.6~),
   libssl-dev,
   libvulkan-dev [linux-any],
   libxcb-xkb-dev,
   libzstd-dev (>= 1.3),
   llvm-17-dev,
   ninja-build,
   pkgconf,
   pkg-kde-tools,
   qt6-base-dev (>= 6.6.2+dfsg~),
   qt6-base-private-dev (>= 6.6.2+dfsg~),
   qt6-declarative-dev (>= 6.6.2+dfsg~),
   qt6-declarative-private-dev (>= 6.6.2+dfsg~),
Build-Depends-Indep: qt6-base-dev (>= 6.6~) ,
 qt6-documentation-tools (>= 6.6~) ,
Standards-Version: 4.6.2
Homepage: https://www.qt.io/developers/
Vcs-Browser: https://salsa.debian.org/qt-kde-team/qt6/qt6-tools
Vcs-Git: https://salsa.debian.org/qt-kde-team/qt6/qt6-tools.git
Rules-Requires-Root: no

本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
 
This email and its attachments contain confidential information from Loongson 
Technology , which is intended only for the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, reproduction or 
dissemination) by persons other than the intended recipient(s) is prohibited. 
If you receive this email in error, please notify the sender by phone or email 
immediately and delete it. 

Bug#1069825: clamav-daemon stops working with LibClamAV Error: cl_engine_addref: engine == NULL

[Michael Braun]

Package: clamav
Version: 0.103.10+dfsg-0+deb11u1
Severity: important

Hi,

I'm scanning incoming mails using clamav-daemon and clamav-milter.
From time to time, my mailserver stops working due to clamav-daemon locking up.

The clamav logs read:

   6889 Apr 25 11:28:12 gate clamd[939931]: Thu Apr 25 11:28:11 2024 -> 
!accept() failed: Too many open files
  1 Apr 25 11:32:11 gate systemd-journald[311]: Suppressed 490085 messages 
from clamav-daemon.service

(with many repetitions)

  1 Apr 25 11:33:41 gate clamd[939931]: LibClamAV Error: cl_engine_addref: 
engine == NULL
  1 Apr 25 11:33:41 gate clamd[939931]: Thu Apr 25 11:33:41 2024 -> 
!cl_engine_addref() failed
  1 Apr 25 11:33:41 gate clamd[939931]: Thu Apr 25 11:33:41 2024 -> 
!Command dispatch failed

(with many repetitions)

Workaround: systemctl restart clamav-daemon fixes the problem temporarely.


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload disabled
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertBrokenMedia disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
ExcludeDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled

Bug#1067727: RFS: tcpslice/1.7-1 -- extract pieces of and/or glue together tcpdump files

[Jeroen Ploemen]

Control: tags -1 moreinfo

On Tue, 26 Mar 2024 02:35:25 -0300
Bruno Naibert  wrote:

> I am looking for a sponsor for my package tcpslice:

hi Bruno,

the package looks mostly fine; some minor remarks and questions:

* docs: rm? The README and CREDITS files don't serve any purpose as
  end user documentation; CHANGES is the upstream changelog and would
  be automatically detected and installed as such by
  dh_installchangelogs (i.e. no need to list it anywhere).
* control: why 'root-requires-root: binary-targets'? What exactly
  needs root?
* salsa-ci.yml: is that allow_failure for reprotest still needed?

As for the git repo on salsa: the tags for the packaging should
include the revision, e.g. debian/1.7-1 instead of 'debian/1.7' or
'1.5', as there could be multiple debian revisions for a single
upstream release.


Please remove the moreinfo tag (and CC me when doing so) once you have
an updated package ready.


pgp0tjcfm_uii.pgp
Description: OpenPGP digital signature

Bug#1069824: paryfor: FTBFS: add support for loongarch64

[zhangdandan]

Source: paryfor
Version: 0.1-7
Severity: normal
Tags: FTBFS patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the paryfor failed (failed five times in the past) for loong64 
in the Debian Package Auto-Building environment.

The error log is as follows,
```
In file included from /<>/test.cpp:5:
/<>/paryfor.hpp:64:2: error: #error "Unknown CPU architecture."
   64 | #error "Unknown CPU architecture."
  |  ^
..
```

The Full log can be found at 
https://buildd.debian.org/status/logs.php?pkg=paryfor=0.1-7=loong64.


I have added support for loongarch in paryfor package and built 
successfully on my local ENV.

Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

Description: Add support for loongarch64 
Last-Update: 2024-04-25

--- paryfor-0.1.orig/paryfor.hpp
+++ paryfor-0.1/paryfor.hpp
@@ -60,6 +60,15 @@ static inline void spin_loop_pause() noe
 }
 } // namespace atomic_queue
 } // namespace paryfor
+#elif defined(__loongarch64)
+namespace paryfor {
+namespace atomic_queue {
+constexpr int CACHE_LINE_SIZE = 64;
+static inline void spin_loop_pause() noexcept {
+asm volatile ("nop" ::: "memory");
+}
+} // namespace atomic_queue
+} // namespace paryfor
 #else
 #error "Unknown CPU architecture."
 #endif

Bug#1069823: libmsv: FTBFS: update the outdated config.{guess,sub} to recognize the LoongArch

[zhangdandan]

Source: libmsv
Version: 1.1.1-4
Severity: normal
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the libmsv failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
UNAME_MACHINE = loongarch64
UNAME_RELEASE = 6.1.27
UNAME_SYSTEM  = Linux
UNAME_VERSION = #6 SMP PREEMPT Mon Jul 31 10:17:50 UTC 2023
configure: error: cannot guess build type; you must specify one
make: *** [debian/rules:31: stamp-build] Error 1
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned 
exit status 2

```

The Full log can be found at [1].

The version of config.guess and config.sub in the libmsv package are too 
old for the LoongArch architecture.
LoongArch architecture has been supported in config upstream [2] and 
autotools-dev source package [3].


Please consider the patch I have attached.
Your opinions are welcome.


[1]:https://buildd.debian.org/status/logs.php?pkg=libmsv=1.1.1-4=loong64
[2]:https://git.savannah.gnu.org/cgit/config.git/commit/?id=20403c5701973a4cbd7e0b4bbeb627fcd424a0f1
[3]:https://packages.debian.org/bookworm/autotools-dev


Thanks,
Dandan Zhang

diff -Nru libmsv-1.1.1/debian/rules libmsv-1.1.1/debian/rules
--- libmsv-1.1.1/debian/rules   2023-08-10 16:23:39.0 +
+++ libmsv-1.1.1/debian/rules   2023-08-10 16:23:39.0 +
@@ -28,6 +28,7 @@
 build-indep: build-arch
 build-arch: stamp-build
 stamp-build: configure
+   dh_update_autotools_config
./configure $(CONFARGS) --prefix=/usr CFLAGS="$(CFLAGS)" 
CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
$(MAKE)
doxygen libmsvdox.cfg

Bug#1068174: Debian FPGA toolchain update and testing

[Daniel Gröber]

Hi Jonathan & Philipp,

On Sat, Apr 20, 2024 at 09:07:41PM +0200, J. Neuschäfer wrote:
> > @Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?
> 
> Count me in!

Excellent, thanks!

> If you find a good answer, let me know, and it's probably a good idea to
> write it down as a recommendation somewhere, so it doesn't get lost in time.
> 
> https://github.com/olofk/corescore might be an interesting option, but I
> haven't looked at it in depth.

That does look to depend on https://github.com/olofk/fusesoc which would
mean additional packaging work just to use it for testing. I'd really
prefer something stand-alone i.e. plain verilog or VHDL.

On Sun, Apr 21, 2024 at 03:00:56PM +0200, Philipp Klaus Krause wrote:
> > Neat, are the GateMates finally available on the open market then? I'd love
> > to get my hands on some dev hardware.
> 
> Yes, I got the GateMateA1-EVB board from Olimex, since it is
> substantially cheaper than the official CologneChips one, and I have no
> use for most of the extra features of the CologneChips board:
> https://www.olimex.com/Products/FPGA/GateMate/GateMateA1-EVB/open-source-hardware

Nice. I like the olimex pricing too :)

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

Double Nice. I only test on amd64. Maybe it's time to start looking at
whether yosys/nextpnr produce reproducible output across architectures? I'm
curious.

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

Neat. That does have the same problem as Jonathan's proposal: additional
packaging work just for testing. Unless you're volunteering for maintaining
sv2v? Happy to sponsor uploads and whatnot.

As for the blinkies on a softcore: that sure does provide a lot of test
coverage already and would be fine to start with if we can find one that
doesn't need additional tooling, but in my mind some kind of complicated
math procedure that can verify it's result and only blinks if it verifies
would be ideal :D

On Tue, Apr 23, 2024 at 01:40:48PM +0200, Philipp Klaus Krause wrote:
> I have done a quick test of the latest upstream release, yosys 0.40 on
> my Debian GNU/Linux (mixture of testing and unstable) amd64 system.

All sounds good. I'll be at mini DebConf Berlin in a couple of weeks and
I'll be working on this stuff there. Would be good if you have some time
while that's going on (14-21th May) to do testing.

> the FPGA board yet. Just like in 0.38, I had to use -nomx8, as the
> defaults generate MX8 cells that haven't been supported by the P tool
> for many months: https://github.com/YosysHQ/yosys/issues/4355

Sounds like something we could paper over with a patch, but I'm not sure we
should really.

Thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1069822: python-gvm: please make the build reproducible

[Chris Lamb]

Source: python-gvm
Version: 24.3.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-gvm could not be built reproducibly.

This is because the docs embed the current build year. A patch is
attached that uses SOURCE_DATE_EPOCH [1] if available.

 [0] https://reproducible-builds.org/
 [0] https://reproducible-builds.org/docs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/Reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/Reproducible-build.patch   2024-04-25 11:55:22.120958744 
+0100
@@ -0,0 +1,33 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-25
+
+--- python-gvm-24.3.0.orig/docs/conf.py
 python-gvm-24.3.0/docs/conf.py
+@@ -16,7 +16,13 @@
+ 
+ import os
+ import sys
+-from datetime import datetime
++import time
++import datetime
++
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
+ 
+ sys.path.insert(0, os.path.abspath(".."))
+ 
+@@ -24,10 +30,8 @@ import gvm  # noqa: E402
+ 
+ # -- Project information -
+ 
+-year = datetime.now().year
+-
+ project = "python-gvm"
+-copyright = f"2018 - {year}, Greenbone AG"
++copyright = f"2018 - {build_date.year}, Greenbone AG"
+ author = "Greenbone AG"
+ 
+ # The short X.Y version
--- a/debian/patches/series 2024-04-25 11:43:24.482946466 +0100
--- b/debian/patches/series 2024-04-25 11:55:21.240959905 +0100
@@ -1,2 +1,3 @@
 change-path-unix-sockets.patch
 Remove-furo-theme-in-docs.patch
+Reproducible-build.patch

Bug#1069821: FTBFS: tests failed

[Andrey Rakhmatullin]

Source: satpy
Version: 0.47.0-2
Severity: serious
Tags: ftbfs

 ERRORS

___ ERROR collecting satpy/tests/reader_tests/test_viirs_edr_active_fires.py
___
satpy/tests/reader_tests/test_viirs_edr_active_fires.py:30: in 
import dask.dataframe as dd
/usr/lib/python3/dist-packages/dask/dataframe/__init__.py:81: in 
from dask.dataframe import backends, dispatch, rolling
/usr/lib/python3/dist-packages/dask/dataframe/backends.py:15: in 
from dask.dataframe.core import DataFrame, Index, Scalar, Series, _Frame
/usr/lib/python3/dist-packages/dask/dataframe/core.py:36: in 
from dask.dataframe import methods
/usr/lib/python3/dist-packages/dask/dataframe/methods.py:34: in 
from dask.dataframe.utils import is_dataframe_like, is_index_like,
is_series_like
/usr/lib/python3/dist-packages/dask/dataframe/utils.py:20: in 
from dask.dataframe import (  # noqa: F401 register pandas extension types
/usr/lib/python3/dist-packages/dask/dataframe/_dtypes.py:9: in 
from dask.dataframe.extensions import make_array_nonempty, make_scalar
/usr/lib/python3/dist-packages/dask/dataframe/extensions.py:8: in 
from dask.dataframe.accessor import (
/usr/lib/python3/dist-packages/dask/dataframe/accessor.py:126: in 
class DatetimeAccessor(Accessor):
/usr/lib/python3/dist-packages/dask/dataframe/accessor.py:81: in
__init_subclass__
_bind_property(cls, pd_cls, attr, min_version)
/usr/lib/python3/dist-packages/dask/dataframe/accessor.py:35: in _bind_property
setattr(cls, attr, property(derived_from(pd_cls,
version=min_version)(func)))
/usr/lib/python3/dist-packages/dask/utils.py:858: in wrapper
method.__doc__ = _derived_from(
/usr/lib/python3/dist-packages/dask/utils.py:811: in _derived_from
method_args = get_named_args(method)
/usr/lib/python3/dist-packages/dask/utils.py:572: in get_named_args
s = inspect.signature(func)
/usr/lib/python3.11/inspect.py:3263: in signature
return Signature.from_callable(obj, follow_wrapped=follow_wrapped,
/usr/lib/python3.11/inspect.py:3011: in from_callable
return _signature_from_callable(obj, sigcls=cls,
/usr/lib/python3.11/inspect.py:2599: in _signature_from_callable
call = _descriptor_get(call, obj)
/usr/lib/python3.11/inspect.py:2432: in _descriptor_get
return get(descriptor, obj, type(obj))
E   TypeError: descriptor '__call__' for 'type' objects doesn't apply to a
'property' object


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

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