Bug#1068529: RFS: qabc/1.11-1 -- minimal GUI for ABC music notation

[Benoît Rouits]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : qabc
   Version  : 1.11-1
   Upstream contact : Benoît Rouits 
 * URL  : http://brouits.free.fr/qabc/
 * License  : FSFAP, GPL-3+
 * Vcs  : https://github.com/be1/qabc
   Section  : sound

The source builds the following binary packages:

  qabc - minimal GUI for ABC music notation

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.11-1.dsc


Changes since the last upload:

 qabc (1.11-1) unstable; urgency=medium
 .
   * New upstream release 1.11
   * Bump standards version to 4.6.2
   * Fix licences in debian/copyright

Regards,

Bug#1065086: Delay in packaging

[Patrick Winnertz]

owner 1065086  !
forwarded 1065086 https://github.com/radioacoustick/Coil64/issues/7
thanks

I've prepared a Debian package at my salsa repro, however there are currently 
license issues with the images being used.

For some of the icons images from icons8 are used. These are free (as in free 
beer) however not open source. You are needed to include a thanks stanca + link 
in your program.

I've filled a bug upstream in the hope that this gets resolved.

Greetings
Patrick

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sean Whitton]

Hello,

On Sat 06 Apr 2024 at 09:30pm +02, Sebastian Andrzej Siewior wrote:

> On 2024-04-06 17:17:45 [+0800], Sean Whitton wrote:
>> Hello,
> Hi,
>
>> It looks like the problem is opening YAPET1.0-format databases, which
>> the manpage explicitly says is meant to work.
>>
>> I've made a sample YAPET1.0 database using a stretch VM.  Using the
>> attached:
>>
>> - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it.
>> - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't.
>
> Thank you for the testcase. It asks for a password, what is it?

Sorry!  It's 'asdf'.

-- 
Sean Whitton

Bug#1068346: [ftpmas...@ftp-master.debian.org: Accepted node-express 4.19.2+~cs8.36.21-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: node-express
Source-Version: 4.19.2+~cs8.36.21-1

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 07 Apr 2024 07:52:14 +0400
Source: node-express
Architecture: source
Version: 4.19.2+~cs8.36.21-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Yadd 
Changes:
 node-express (4.19.2+~cs8.36.21-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 4.19.2+~cs8.36.21 (Closes: CVE-2024-29041)
   * Unfuzz patches
Checksums-Sha1: 
 5acf5179d1b48d8019fa3f96fb0062d6a561e8cf 4250 
node-express_4.19.2+~cs8.36.21-1.dsc
 3ae8ab3767d98d0b682cda063c3339e1e86ccfaa 12489 
node-express_4.19.2+~cs8.36.21.orig-types-express-serve-static-core.tar.gz
 c26d4a151e60efe0084b23dc3369ebc631ed192d 2699 
node-express_4.19.2+~cs8.36.21.orig-types-express.tar.gz
 0de8181cc5ac0334fbe0142b510ea66ad45920bb 148014 
node-express_4.19.2+~cs8.36.21.orig.tar.gz
 54d3fc7adacc1437efb7cb729794ee6c7b942cb0 26632 
node-express_4.19.2+~cs8.36.21-1.debian.tar.xz
Checksums-Sha256: 
 3a82fb4c483ebd00803a1b7318959c6e3ac36b1f65de447efc41173b7a603aaa 4250 
node-express_4.19.2+~cs8.36.21-1.dsc
 341f919fe2c4929497bac01a6dc29ed8b50485aa2f282896e7532b58bff88399 12489 
node-express_4.19.2+~cs8.36.21.orig-types-express-serve-static-core.tar.gz
 d292c477ae1b654d6422d7a168a86b7a680f8f0e176e854d6c7ce02e3e202f57 2699 
node-express_4.19.2+~cs8.36.21.orig-types-express.tar.gz
 08542d21662fead677b6d262ac98383030804b0e5a6c75bca9697dfd7260891a 148014 
node-express_4.19.2+~cs8.36.21.orig.tar.gz
 e0ce6a40be8f7df3271214924d0f566877b2dfb0afe48d04bbfa5295622cc6d5 26632 
node-express_4.19.2+~cs8.36.21-1.debian.tar.xz
Files: 
 77d68000e84f2b9cb03ab0d2e4bef6cf 4250 javascript optional 
node-express_4.19.2+~cs8.36.21-1.dsc
 152a87d8e5f6a37982f10c5be3d65948 12489 javascript optional 
node-express_4.19.2+~cs8.36.21.orig-types-express-serve-static-core.tar.gz
 50f392ae641a36e9cf75ae2eed0600f0 2699 javascript optional 
node-express_4.19.2+~cs8.36.21.orig-types-express.tar.gz
 755bb69941658f54651b08017ac2dbfb 148014 javascript optional 
node-express_4.19.2+~cs8.36.21.orig.tar.gz
 7c13d3b855af65df666a76a8946f900a 26632 javascript optional 
node-express_4.19.2+~cs8.36.21-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYSIGgACgkQ9tdMp8mZ
7ukYjA//b+Lm49hKE8Yx3KWD25S77PURUKnnmW9G78y9Drwb0aj9Xa0d3eYxzKp6
z1sYpbdGzJbMlLFKsxAbiWLEnM9hVlNbXQOuazmiGqfz/opIQqeq58iS7YK1RLCA
aVdIK9lL8TM64jMbysqr6ZoPIp09t7gFJU/anjm2KomPxvmYb7x7BHQZOjHmmQMg
VnHl+UphUFlIbLIjoLEcFosspTf9jDhJ5XEcxoM9d6LwcGnXZuJvl+GfcZ41hujF
v11VPZWCC9Vfei4kHgZDGlTHiP8LHcL7TwS9L+gHlCwhekVw3Ols3kjLuOTBhqWk
bRQsZM9LkxWQfHwqtPyLMQIFs72tcwSKivuBj6XYXqedSisj4EIAcBEOurTtlc0c
AGuX2TjFiZX3lajBG0zLqxgUsKESwvORuMAOmxhXsO9/vx3mW47BPWsZjK9c6Xgm
M4YBP23hEhip7iCstFdRAEjuEbmQMoSkR3tZxLQwS1E8K16iaLygygkZ0qvIKv+7
QQainMVjWCcZXfgMBhaMqdREoMBD2UgwXzoR/LQiZTvCt5IPqCKesNhua1cAvo2t
t8hTeNVsTp8wts54gpV5DffQrzlcR0uP/xxTfp5vr9a+l4YWsB8mnGpvNpOxNouf
FB7r0szSeITSRHJLcssKrsPSzd3CYcWECQ3GMS3zcmZtihqztGw=
=b+7+
-END PGP SIGNATURE-




- End forwarded message -

Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.

[Otto Kekäläinen]

Hi Daniel!

Do you think this change is still needed?

Do you want to participate in some open source development/testing to
make it work?

On Sun, 14 Jan 2024 at 16:03, Otto Kekäläinen  wrote:
>
> FYI: Discussion about this continued in
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61
>

Bug#1068528: xfce4-settings: xfce4-find-cursor does nothing without … sudo?

[T. Joseph Carter]

Package: xfce4-settings
Version: 4.18.3-1+b1
Severity: normal

Dear Maintainer,

Discovered that xfce4-find-cursor (an accessibility feature) does not
work without the use of sudo. Permissions issue of some sort? Should
this program be installed with some sgid to access something? I can't
imagine what offhand.

This isn't documented as far as I can tell. Someone asked why it was
necessary to run this with root privs two years ago on askubuntu (no
answer) and that's all I could find amongst the AI trash and unrelated
responses. If there's some optional permissions I should be changing to
make this work, the changes aren't documented and there don't appear to
be any measures in place to preserve those changes in maintainer scripts
from a quick glance.

If it turns out to matter, Xorg with xfwm4 on AMD (6700 XT) using open
source drivers.

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

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

Versions of packages xfce4-settings depends on:
ii  exo-utils4.18.0-1+b2
ii  libatk1.0-0t64   2.52.0-1
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-3
ii  libcairo21.18.0-3
ii  libcolord2   1.4.7-1+b1
ii  libexo-2-0   4.18.0-1+b2
ii  libfontconfig1   2.15.0-1.1
ii  libgarcon-1-04.18.1-1+b2
ii  libgarcon-common 4.18.1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b2
ii  libglib2.0-0t64  2.78.4-6
ii  libgtk-3-0t643.24.41-4
ii  libnotify4   0.8.3-1+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpangocairo-1.0-0  1.52.1+ds-1
ii  libupower-glib3  1.90.2-8+b1
ii  libx11-6 2:1.8.7-1
ii  libxcursor1  1:1.2.1-1
ii  libxfce4ui-2-0   4.18.4-1+b1
ii  libxfce4util74.18.1-2+b1
ii  libxfconf-0-34.18.1-1+b2
ii  libxi6   2:1.8.1-1
ii  libxklavier165.4-5+b1
ii  libxrandr2   2:1.5.4-1
ii  xfce4-helpers4.18.3-1+b1
ii  xfconf   4.18.1-1+b2

Versions of packages xfce4-settings recommends:
ii  colord 1.4.7-1+b1
ii  x11-utils  7.7+6+b1
ii  xiccd  0.3.0-2+b1

xfce4-settings suggests no packages.

-- no debconf information

Bug#1068504: mumble-server: wrong path for systemd-sysusers file

[Chris Knadle]

Greetings.

As far as I know /etc/sysconfig.d/ is a directory used by Fedora/Red Hat 
based distros, not Debian.


Looking through the Git log I see I added this on Feb 1 2023 with the 
following commit message:


    add etc/sysconfid./mumble-server.conf as the build breaks without 
it at compat 13

    (it's commit f0cdad5245c6d1de6bff9223c6ce5767c13f9e45)

/usr/lib/sysusers.d/*.conf does seem like where this file should go.

I've made local Git commits to fix this for the next bugfix upload 
(1.5.517-3). Before doing any more uploads I need to look at what's 
going on with a number of library transitions going on that could get 
negatively affected by uploads of mumble.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

On 4/6/24 09:12, Stefan Schweizer via Pkg-voip-maintainers wrote:

Package: mumble-server
Severity: normal

Hi,

mumble-server installs a systemd-sysusers file to /etc/sysconfig.d

According to the sysusers.d(5) man page sysusers files can be placed in
/etc/sysusers.d/*.conf
/run/sysusers.d/*.conf
/usr/lib/sysusers.d/*.conf

So installing the sysusers file to /etc/sysconfig.d has no
effect and it should be moved to /usr/lib/sysusers.d.

Since the mumble-server user is created by the debian package I think
the sysusers file is unnecessary and can be omitted until a switch to
sysusers is made.

Bug#1068527: test suite failures

[Antoine Beaupré]

Control: tags -1 +patch +upstream

Upstream actually fixed this issue, possibly:

https://github.com/dajva/rg.el/commit/8e2347d0a11aa64fd721702b176b1dbc7889f78e

So, woot, i guess we get this fix when upstream makes a new release (or
we import that patch).

A.
-- 
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry

Bug#1066346: sc: FTBFS: sc.c:1301:46: error: implicit declaration of function ‘list_frames’; did you mean ‘list_ranges’? [-Werror=implicit-function-declaration]

[Ying-Chun Liu (PaulLiu)]

Hi,

I've fixed the bug. And I'll do NMU if no one object in 10 days.
I'll upload it to the delay/10 queue.

Attachment is the debdiff. Please review it.

Yours,
Paul
diff -Nru sc-7.16/debian/changelog sc-7.16/debian/changelog
--- sc-7.16/debian/changelog2022-01-26 01:22:23.0 +0800
+++ sc-7.16/debian/changelog2024-04-07 09:47:51.0 +0800
@@ -1,3 +1,11 @@
+sc (7.16-4.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS by -Werror=implicit-function-declaration (Closes: #1066346)
+- Add debian/patches/fix-ftbfs-implicit-function-declaration.patch
+
+ -- Ying-Chun Liu (PaulLiu)   Sun, 07 Apr 2024 09:47:51 
+0800
+
 sc (7.16-4.1) unstable; urgency=low
 
   [ Ying-Chun Liu (PaulLiu)  ]
diff -Nru sc-7.16/debian/patches/fix-ftbfs-implicit-function-declaration.patch 
sc-7.16/debian/patches/fix-ftbfs-implicit-function-declaration.patch
--- sc-7.16/debian/patches/fix-ftbfs-implicit-function-declaration.patch
1970-01-01 08:00:00.0 +0800
+++ sc-7.16/debian/patches/fix-ftbfs-implicit-function-declaration.patch
2024-04-07 09:47:51.0 +0800
@@ -0,0 +1,27 @@
+Description: fix ftbfs caused by -Werror=implicit-function-declaration
+ For dpkg >= 1.22.6, -Werror=implicit-function-declaration is turned
+ on by default. So we need to declare every functions.
+Bug-Debian: http://bugs.debian.org/1066346
+Author: Ying-Chun Liu (PaulLiu) 
+Last-Update: 2024-04-07
+Index: sc-7.16/sc.h
+===
+--- sc-7.16.orig/sc.h
 sc-7.16/sc.h
+@@ -641,3 +641,16 @@ void leftlimit();
+ void rightlimit();
+ void gototop();
+ void gotobottom();
++void list_frames(FILE *);
++void yankrow(int);
++void yankcol(int);
++void ljustify(int, int, int, int);
++void rjustify(int, int, int, int);
++void center(int, int, int, int);
++void gotonote();
++void add_abbr(char *);
++void getframe(int);
++void getrange(char *, int);
++void doeval(struct enode *, char *, int, int, int);
++void doseval(struct enode *, int, int, int);
++void dogetkey();
diff -Nru sc-7.16/debian/patches/series sc-7.16/debian/patches/series
--- sc-7.16/debian/patches/series   2022-01-26 00:34:21.0 +0800
+++ sc-7.16/debian/patches/series   2024-04-07 09:47:51.0 +0800
@@ -4,3 +4,4 @@
 function_definitions
 nonotimeout.patch
 hardening
+fix-ftbfs-implicit-function-declaration.patch


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054822: opam: FTBFS: sed: can't read opam.install: No such file or directory

[Bo YU]

Hi,
On Fri, Oct 27, 2023 at 09:42:50PM +0200, Lucas Nussbaum wrote:

 ; windows_unicode = false
 }
 ; instrument_with = []
 }
Actual targets:
- _build/default/opam-installer.install
- _build/default/opam.install
Running[1]: (cd _build/default/src/client && /bin/sh -c 'git describe --exact HEAD || 
echo [dev]') > _build/default/src/client/git-describe 2> /dev/null
Running[2]: (cd _build/default/src/client && /bin/sh -c 'git rev-parse --quiet 
--verify HEAD || echo .') > _build/default/src/client/git-sha 2> /dev/null
sed -f process.sed opam.install > processed-opam.install
sed: can't read opam.install: No such file or directory
make[2]: *** [Makefile:166: processed-opam.install] Error 2


Just fyi, I have commited one patch to salsa:
https://salsa.debian.org/ocaml-team/opam/-/commit/ce22a7ae844e4bb9266748beb23a6750afb3c3f6

It was the same with debdiff file.

But there is one issue was unclear to me, see
https://lists.debian.org/debian-ocaml-maint/2024/04/msg00028.html

--
Regards,
--
  Bo YU

diff -Nru opam-2.1.5/debian/changelog opam-2.1.5/debian/changelog
--- opam-2.1.5/debian/changelog 2023-09-02 13:35:29.0 +0800
+++ opam-2.1.5/debian/changelog 2024-04-06 22:30:28.0 +0800
@@ -1,3 +1,10 @@
+opam (2.1.5-2) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Add 0003-opam-dune-3.11.patch to fix ftbfs issue. (Closes: #1054822)
+
+ -- Bo YU   Sat, 06 Apr 2024 22:30:28 +0800
+
 opam (2.1.5-1) unstable; urgency=medium
 
   * Team upload
diff -Nru opam-2.1.5/debian/patches/0003-opam-dune-3.11.patch 
opam-2.1.5/debian/patches/0003-opam-dune-3.11.patch
--- opam-2.1.5/debian/patches/0003-opam-dune-3.11.patch 1970-01-01 
08:00:00.0 +0800
+++ opam-2.1.5/debian/patches/0003-opam-dune-3.11.patch 2024-04-06 
22:30:28.0 +0800
@@ -0,0 +1,20 @@
+Description: fix ftbfs due to opam-dune 3.11 
+Origin: 
https://src.fedoraproject.org/rpms/opam/blob/rawhide/f/opam-dune-3.11.patch
+Bug: https://bugs.debian.org/1054822
+Last-Update: 2024-04-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Makefile
 b/Makefile
+@@ -162,7 +162,10 @@
+   $(DUNE) install --root . opam-$$p; \
+   done
+ 
+-processed-%.install: %.install
++processed-opam.install: _build/default/opam.install
++  sed -f process.sed $^ > $@
++
++processed-opam-installer.install: _build/default/opam-installer.install
+   sed -f process.sed $^ > $@
+ 
+ install: processed-opam.install processed-opam-installer.install
diff -Nru opam-2.1.5/debian/patches/series opam-2.1.5/debian/patches/series
--- opam-2.1.5/debian/patches/series2023-09-02 13:35:29.0 +0800
+++ opam-2.1.5/debian/patches/series2024-04-06 22:30:28.0 +0800
@@ -1,2 +1,3 @@
 0001-Add-a-test-target.patch
 0002-Use-HOME-env-variable-instead-of.patch
+0003-opam-dune-3.11.patch


signature.asc
Description: PGP signature

Bug#1068527: test suite failures

[Antoine Beaupre]

Package: elpa-rg
Version: 2.3.0-1
Severity: normal

The test suite currently fails on this package, and those failures
have been ignored in debian/rules to get the package to build at all.

The package *works*: i've been using it as is, in bookworm, for months
now. It *might* actually be broken in unstable, but I doubt it: i
suspect this is more a test harness problem than anything else.

So I'm filing this issue to remember about this problem and possibly
see if we can collaborate with upstream to fix it.


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

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 elpa-rg depends on:
ii  dh-elpa-helper  2.0.16
ii  elpa-wgrep  3.0.0-1
ii  emacsen-common  3.0.5
ii  ripgrep 13.0.0-4+b2

Versions of packages elpa-rg recommends:
ii  emacs  1:28.2+1-15
ii  emacs-gtk [emacs]  1:28.2+1-15

elpa-rg suggests no packages.

-- no debconf information

Bug#1068526: samba-dsdb-modules dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: samba-dsdb-modules
Version: 2:4.19.5+dfsg-4
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, samba-dsdb-modules
depends on both libgpgme11 and libgpgme11t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on libgpgme11

http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz

While poking through the ubuntu changelog, I noticed another
change that looks relavent (but non-rc)

http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz

Bug#1065221: O: py7zr -- pure Python 7-zip library

[yokota]

Hello,

I think these packages are now ready for upload to NEW queue.
Please examine them.

https://salsa.debian.org/python-team/packages/python-brotlicffi
https://salsa.debian.org/python-team/packages/python-inflate64
https://salsa.debian.org/python-team/packages/python-pyppmd
https://salsa.debian.org/python-team/packages/python-pyzstd

--
YOKOTA Hiroshi

Bug#1068487: man-db: Failed to get unit file state for man-db.service: Transport endpoint is not connected

[Bo YU]

Hi,

On Sun, Apr 7, 2024 at 12:14 AM Colin Watson  wrote:
>
> Control: reassign -1 systems
>
...
>
> Hi,
>
> This is all fairly clearly a systemd issue rather than anything
> specifically to do with man-db, so reassigning there.  I'm afraid I
> don't have any further clues though.

Thanks for correcting this. What's even more embarrassing is that I
can not reproduce this on other machines. maybe something else
unexpected happened while I was upgrading the system. So please give
me one or two days to observe more and then close the bug if
everything is okay.

Thanks.

BR,
Bo
>
> --
> Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1068525: SyntaxWarning: invalid escape sequence

[Paul Wise]

Package: python3-defcon
Version: 0.10.3-2
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

When upgrading I got syntax warnings caused by Python 3.12:

   Preparing to unpack .../python3-defcon_0.10.3-2_all.deb ...
   Unpacking python3-defcon (0.10.3-2) over (0.10.3-1) ...
   Setting up python3-defcon (0.10.3-2) ...
   /usr/lib/python3/dist-packages/defcon/objects/base.py:332: SyntaxWarning: 
invalid escape sequence '\*'
 """
   /usr/lib/python3/dist-packages/defcon/objects/base.py:355: SyntaxWarning: 
invalid escape sequence '\*'
 """
   /usr/lib/python3/dist-packages/defcon/objects/base.py:400: SyntaxWarning: 
invalid escape sequence '\*'
 """
   /usr/lib/python3/dist-packages/defcon/objects/font.py:27: SyntaxWarning: 
invalid escape sequence '\*'
 """
   /usr/lib/python3/dist-packages/defcon/objects/font.py:1651: SyntaxWarning: 
invalid escape sequence '\s'
 "\s*"  #
   /usr/lib/python3/dist-packages/defcon/objects/font.py:1653: SyntaxWarning: 
invalid escape sequence '\s'
 "\s+"  #
   /usr/lib/python3/dist-packages/defcon/objects/font.py:1654: SyntaxWarning: 
invalid escape sequence '\w'
 "(\w{4})"  # four alphanumeric characters
   /usr/lib/python3/dist-packages/defcon/objects/font.py:1655: SyntaxWarning: 
invalid escape sequence '\s'
 "\s*"  #
   /usr/lib/python3/dist-packages/defcon/objects/font.py:1656: SyntaxWarning: 
invalid escape sequence '\{'
 "\{"   # {
   /usr/lib/python3/dist-packages/defcon/test/objects/test_kerning.py:41: 
SyntaxWarning: invalid escape sequence '\('
 with self.assertRaisesRegex(KeyError, "\('NotInFont', 'NotInFont'\)"):
   
-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), 
(790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), 
(690, 'buildd-experimental'), (500, 'stable-updates'), (500, 
'stable-security-debug'), (500, 'stable-security'), (500, 'stable-debug'), 
(500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'buildd-proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-defcon depends on:
ii  libjs-sphinxdoc7.2.6-6
ii  python33.11.6-1
ii  python3-fonttools  4.46.0-1

Versions of packages python3-defcon recommends:
pn  python3-fontpens  

python3-defcon suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1068524: O: qimgv -- Qt5 image viewer with optional video support

[Boyuan Yang]

Package: wnpp
Severity: normal
Control: affects -1 src:qimgv

I intend to orphan package qimgv.

The package description is:

 Qt5 image viewer with optional video support
 .
 Qimgv is an image viewer written in Qt5. It is fast, configurable 
 and easy to use. It also provides optional video support.


Thanks,
Boyuan Yang


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

Bug#1068523: dh-debputy: To contact or to contract

[gregor herrmann]

Package: dh-debputy
Version: 0.1.27
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I was very excited when I read about `debputy lint` as I like to
automatically fix packaging errors. Alas, my first experience leaves
me a bit underexcited because (seen with several packages):

% debputy lint
warning: File: ./debian/copyright:3:0:3:16: The "Upstream-Contact" looks like a 
typo of "Upstream-Contract". [Correctable via --auto-fix]

And I'm rather sure I don't want to change Upstream-Contact to Upstream-Contract
:)


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmYR46hfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYldg//Vj1wUmaD2XSO47zsHIKmZ3wF6PBVDdUR817Gq40KAf4AoBJ/H0h0VeK6
zHRVV3ikTEZdi3Hk4FOMtvs/qUSXuBOpISgzlOu0d+gA+m/EC1hCDlKgT+09gaGE
wQq4BcZFo84kZQsBUDR8sBa8AH3O/AdR+6vWE4KvWnjLpBT6dI6KXvEU0lc6uM+c
3JfPVoJ30WWwQ/+NbL8Lhj29PEAsx4oQBSnC0WahUsMNEgsOOfbf1VCBOZt1W+AE
LzJ9E+cuHX3xBHtGEzMRDMJdoJD5sGyEnPXcqVvnOw9xjtfjHDQQfSKE9TmtAr0l
/RfKaeEEFJ1q16wbu4SdMDy/0Q81VGAHvQWqGimOySSzTXNq4y8bWCQtSA9PfN8r
CpiWxQpRtfr8NDilz6Nckc1iqSW6GOwjXr0ZTGtuyXVewym1JjS32ZqLTCFFDHsX
jSbkttyquJNFd/jeiE3Cp6QTGlj6hoxBW+a7DtTEeaRp2l1mHFZvS8FQbR9oixNi
9Sr7HaKnNxtuqh0DXKdmme1Nb9QBgFdDj1D31RoxGIxl6gpvWQ82HSYlustjYP4Z
u3222C7nQIcRsvQQHmalFK6cb40r9Shd4hGwTt2cJOEt9ZHxl3O55oTEY2t82ASh
CKtnA8ilA32GuOVjpR6Bbrk0/A4nmJWqzzckhSCZUjk1Xbg2PQY=
=AsCd
-END PGP SIGNATURE-

Bug#1068522: icmake: cross-build support for icmake

[tony mancill]

Source: icmake
Version: 12.00.01-1
Severity: normal

cross-building for armhf fails on amd64:

$ sbuild --host=armhf -d unstable

...
   dh_dwz -a
install -m0755 -d debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf
dwz -mdebian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug 
-M/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug -- 
debian/icmake/usr/bin/icmake debian/icmake/usr/bin/icmbuild 
debian/icmake/usr/libexec/icmake/icm-comp 
debian/icmake/usr/libexec/icmake/icm-dep 
debian/icmake/usr/libexec/icmake/icm-exec 
debian/icmake/usr/libexec/icmake/icm-multicomp 
debian/icmake/usr/libexec/icmake/icm-pp 
debian/icmake/usr/libexec/icmake/icm-spch debian/icmake/usr/libexec/icmake/icmun
arm-linux-gnueabihf-objcopy --compress-debug-sections 
debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug
arm-linux-gnueabihf-objcopy: 
debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug: file format 
not recognized
dh_dwz: error: arm-linux-gnueabihf-objcopy --compress-debug-sections 
debian/icmake/usr/lib/debug/.dwz/arm-linux-gnueabihf/icmake.debug returned exit 
code 1
dh_dwz: error: Aborting due to earlier error
make: *** [debian/rules:21: binary] Error 25

Bug#1056936: bookworm-pu: package glewlwyd/2.7.5-3

[Jonathan Wiltshire]

Control: tag -1 confirmed

Hi,

On Wed, Feb 14, 2024 at 05:42:24PM -0500, Nicolas Mora wrote:
> Hello,
> 
> I've updated the debdiff to add a fix for CVE-2024-25715

Sorry for the delay; please go ahead.

Thanks,

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

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

Bug#1068521: ITP: kf6-kstatusnotifieritem -- Implementation of Status Notifier Items

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: kf6-kstatusnotifieritem
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/kstatusnotifieritem
* License : LGPL, CC0
  Programming Lang: C++
  Description : Implementation of Status Notifier Items

KStatusNotifierItem provides an implementation of Status Notifier Items.

Package will be maintained within the Debian Qt/KDE team.

Bug#1068520: ITP: kf6-kcolorscheme -- Classes to read and interact with KColorScheme

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: kf6-kcolorscheme
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/kcolorscheme
* License : LGPL, BSD, CC0
  Programming Lang: C++
  Description : Classes to read and interact with KColorScheme

KColorScheme provides classes to read and interact with KColorScheme.

Package will be maintained within the Debian Qt/KDE team.

Bug#1068519: ITP: kf6-ktexttemplate -- Library to allow application developers to separate the structure of documents from the data they contain

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: kf6-ktexttemplate
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/ktexttemplate
* License : LGPL
  Programming Lang: C++
  Description : Library to allow application developers to separate the 
structure of documents from the data they contain

KTextTemplate is a library to allow application developers to separate the
structure of documents from the data they contain.

The goal of KTextTemplate is to make it easier for application developers
to separate the structure of documents from the data they contain,
opening the door for theming and advanced generation of other text such as code.

Package will be maintained within the Debian Qt/KDE team.

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Dirk Eddelbuettel]

Hi Lucas,

As Milan suggested, please sure you are current.  If in doubt, park you
current checkout and start from

git checkout https://github.com/eddelbuettel/dieharder.git

where you should see today's commit from merging PR 24.

edd@rob:~/git/dieharder(master)$ git ls | head
*   3442896 - (HEAD -> master, origin/master, origin/HEAD) Merge pull 
request #24 from mbroz/dab-monobit2-ntup (10 hours ago) 
|\  
| * d928cbf - Avoid overflow in DAB Monobit2 test. (10 hours ago) 
|/  
*   2d4763a - Merge pull request #22 from mbroz/master (6 weeks ago) 
|\  
| * 67989b4 - Do not report file input rewind if nothing was read 
repeatedly. (6 weeks ago) 
|/  
* c987a15 - Fix segfault for wrongly specified test on commandline. (#21) 
(9 weeks ago) 
*   a186d90 - Merge pull request #20 from mbroz/warning-fixes (2 months 
ago) 
edd@rob:~/git/dieharder(master)$ 

Do not rely on the Debian package, it has not been updated yet.

Cheers, Dirk

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

Bug#1067916: FTBFS: tests failed

[tony mancill]

On Fri, Mar 29, 2024 at 12:13:57AM +0500, Andrey Rakhmatullin wrote:
> Source: capnproto
> Version: 1.0.1-3
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=capnproto=armhf=1.0.1-3%2Bb2=1711652087=0

Thank you for the bug report.  I'm not able to reproduce the test
failure when cross-building on amd64, so am in the process of triaging
on a porter box.


signature.asc
Description: PGP signature

Bug#1068518: ITP: kf6-ksvg -- Library for rendering SVG-based themes with stylesheet re-coloring and on-disk caching

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: kf6-ksvg
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/ksvg
* License : GPL, LGPL, BSD, MIT, CC0
  Programming Lang: C++
  Description : Library for rendering SVG-based themes with stylesheet 
re-coloring and on-disk caching

KSvg provides both C++ classes and QtQuick components to render svgs based
on image packs. Compared to plain QSvg, it caches the rendered images on
disk with KImageCache, and can re-color properly crafted svg shapes that
include internal stylesheets.

Package will be maintained within the Debian Qt/KDE team.

Bug#1055802: bookworm-pu: package qtbase-opensource-src/5.15.8+dfsg-11+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Nov 11, 2023 at 09:36:48PM +0300, Dmitry Shachnev wrote:
> [ Reason ]
> The main goal of the proposed update is to fix bug #1055280: broken Unicode
> support in libqt5sql5-odbc because of patch for CVE-2023-24607.
> 
> Additionally, I backported fixes for three more CVEs which were discovered
> in the meantime: CVE-2023-34410, CVE-2023-37369 and CVE-2023-38197.

Sorry for the delay; please go ahead (targetting bookworm in your
debian/changelog).

Thanks,

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

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

Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).

[tony mancill]

On Wed, Apr 03, 2024 at 11:37:20AM +0200, Frank B. Brokken wrote:
> Dear Peter Green, you wrote:
> > > Also, the bootstrapping procedure is only required when icmake isn't
> > > available ...
> 
> Thanks for your bugreport: I'm about to update icmake so that the circular
> dependency between bobcat and icmake is removed. Shortly after icmake's
> update bobcat will also be updated.

icmake 12.0.01-1 [1] has landed in the archive and is being chewed on by
the buildds now [2].  Once it is installed on armhf and armel, I will
trigger givebacks for bobcat.

As noted in the icmake changelog, the icmake bootstrap was accomplished
by vendoring in the bobcat sources.  This interim measure seemed
warranted to get the r-build-deps unstuck.  The long-term approach will
be addressed by a separate bobcat-source package (#1068510 [3]).

Thank you for your help and patience with this one.
tony

[1] 
https://tracker.debian.org/news/1517256/accepted-icmake-120001-1-source-into-unstable/
[2] https://buildd.debian.org/status/package.php?p=icmake
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068510


signature.asc
Description: PGP signature

Bug#1068326: mksh 59c-28+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068326 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: mksh
Version: 59c-28+deb12u1

Explanation: handle merged /usr in /etc/shells; fix crash with nested bashism; 
fix arguments to the dot command; distinguish unset and empty in `typeset -p`

Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects

[Jay Berkenbilt]

Can you tell me where in the docs it says what you're describing?
Here's a direct quote from the current qpdf documentation:

It is not generally practical to remove objects from QDF files without
messing up object numbering, but if you remove all references to an
object, you can run qpdf on the file (after running fix-qdf), and qpdf
will omit the now-orphaned object.

To me, it seems that the documentation matches the observed and
intended behavior. Maybe there was an error in the older docs that
have been subsequently fixed.

On Tue, Mar 19, 2024, at 5:14 PM, Thorsten Glaser wrote:
> Package: qpdf
> Version: 10.1.0-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: t...@mirbsd.de, n...@naturalnet.de
> 
> The qpdf documentation states that it is possible to remove an object
> then run fix-qdf and it should renumber the remaining objects.
> 
> In an exemplary PDF, I did this:
> 
> - qpdf --qdf dings.pdf dings.qdf
> - $EDITOR dings.qdf
> - remove object '38 0' and the one reference to it
> - fix-qdf dings.qdf >dings2.qdf
> 
> It complained about the missing object:
> 
> dings.qdf:20254: expected object 38
> 
> Line 20254 here is exactly the beginning of object '39 0'
> after the end of object '37 0'.
> 
> ──┤ Workaround ├
> 
> Just removing all the references and letting qpdf clean up the
> now-unreferenced object seems to have worked here.
> 
> But this does still not work as documented…

Bug#1068517: kate: request to backport patch for upstream bug 476307

[Robert Scott]

Package: kate
Version: 4:22.12.3-1
Severity: normal

Dear Maintainer,


Upstream bug https://bugs.kde.org/show_bug.cgi?id=476307 has been reported 
resolved by MR https://invent.kde.org/utilities/kate/-/merge_requests/1441

It would be extremely helpful if you were able to pull the patch back to 
bookworm, or at least ensure the fix is included in the next stable, as
the bug causes me pain every day.


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

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

Versions of packages kate depends on:
ii  kate5-data   4:22.12.3-1
ii  kio  5.103.0-1
ii  ktexteditor-katepart 5.103.0-1.1
ii  libc62.36-9+deb12u4
ii  libkf5activities55.103.0-1
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5newstuff5  5.103.0-1
ii  libkf5newstuffcore5  5.103.0-1
ii  libkf5newstuffwidgets5   5.103.0-1
ii  libkf5parts5 5.103.0-1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5syntaxhighlighting55.103.0-3
ii  libkf5texteditor55.103.0-1.1
ii  libkf5textwidgets5   5.103.0-1
ii  libkf5wallet-bin 5.103.0-1
ii  libkf5wallet55.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libkuserfeedbackcore11.2.0-2
ii  libkuserfeedbackwidgets1 1.2.0-2
ii  libqt5concurrent55.15.8+dfsg-11
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5dbus5  5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5network5   5.15.8+dfsg-11
ii  libqt5sql5   5.15.8+dfsg-11
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libqt5xml5   5.15.8+dfsg-11
ii  libstdc++6   12.2.0-14
ii  plasma-framework 5.103.0-1+deb12u1
ii  qml-module-org-kde-kquickcontrolsaddons  5.103.0-1
ii  qml-module-qtquick-layouts   5.15.8+dfsg-3
ii  qml-module-qtquick2  5.15.8+dfsg-3

Versions of packages kate recommends:
ii  sonnet-plugins  5.103.0-1

Versions of packages kate suggests:
pn  darcs
pn  exuberant-ctags  
ii  git  1:2.39.2-1.1
ii  khelpcenter  4:22.12.3-1
ii  konsole-kpart4:22.12.3-1
ii  mercurial6.3.2-1
pn  subversion   

-- no debconf information

Bug#1051232: bookworm-pu: package 7zip/23.01+dfsg-3~deb12u1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Sun, Oct 15, 2023 at 12:55:48PM +0900, yokota wrote:
> Trivial autopkgtest was passed, but I don't know that this debdiff
> really fixes CVE-2023-31102 and CVE-2023-40481.
> 
> Please examine attached debdiff.

I am not in a position to assess that for you. You're the maintainer, you
need to be able to vouch for your proposed upload.

Thanks,

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

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

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

[Chris Hofstaedtler]

Hi,

* Iker Pedrosa  [240403 09:43]:
> Hi Chris,
> 
> I have some questions regarding your proposal:
> 
>- What is the difference between liblastlog2 and libpam-lastlog2
>binaries? Upstream util-linux only provides one binary (lastlog2) so this
>confuses me.

util-linux upstream provides three binary objects to be built:
- liblastlog2.so
- pam_lastlog2.so
- lastlog2 (program)

Debian's PAM policy says to put PAM modules into their own package,
thus libpam-lastlog2. liblastlog2.so would go into the
liblastlog2(-0) package. The lastlog2 program either into its own
lastlog2 package, or elsewhere.

>- Did you consider using a systemd service to upgrade from lastlog to
>lastlog2 data?

No, I did not consider this, as I wasn't aware of any
implementations for this. Does u-l upstream ship such a service?

> This way when the distribution is updated to the next
>version you can also remove the lastlog binary and all its dependencies. In
>addition, you can use "--disable-lastlog" in shadow to stop building this
>binary.

Chris

Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

On Mon, Feb 05, 2024 at 11:26:12AM +0100, Didier 'OdyX' Raboud wrote:
> Le samedi, 3 février 2024, 10.46:29 h CET Adam D. Barratt a écrit :
> > On Sat, 2024-02-03 at 10:33 +0100, Thomas Gaugler wrote:
> > > I am the maintainer of Nullsoft Scriptable Install System (NSIS) and
> > > propose the changes committed into the debian/bookworm branch on the
> > > 27th January 2024 to be released as updated nsis 3.08-3+deb12u1
> > > packages
> > > ().
> > 
> > Thanks, but you've still not attached a debdiff of a prepared package,
> > as requsted. Pointers to git are useful, but they're not the same as an
> > actual package debdiff, which sometimes reveals changes that aren't
> > immediately obvious from git.
> > 
> > (A debdiff attached to the bug is also there in perpetuity.)
> 
> Here comes the debdiff as I would upload it.

Thanks. The bug #1050288 isn't fixed in unstable according to the BTS,
which is a requirement. What's the status?

Thanks,

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

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

Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sat, Sep 23, 2023 at 10:54:50PM +0200, Dennis van Dok wrote:
> On 23-09-2023 22:36, Adam D. Barratt wrote:
> > > [ Checklist ]
> > >  [*] *all* changes are documented in the d/changelog
> > >  [*] I reviewed all changes and I approve them
> > >  [*] attach debdiff against the package in (old)stable
> > 
> > You appear to have forgotten the debdiff.
> 
> It could not be attached on the initial submission for some reason, so
> I attached it in message #12:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051024#12

The target distribution in d/changelog should be 'bookworm'; with that
fixed please go ahead.

> 
> > 
> > >  [ ] the issue is verified as fixed in unstable
> > 
> > Is this fixed in unstable or not?
> 
> Yes, 1.122 is accepted into unstable in the mean time.

You may wish to adjust found versions to cover current stable.

Thanks,

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

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

Bug#1053832: bookworm-pu: package ceph/16.2.11+ds-2 (CVE-2023-43040)

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Oct 12, 2023 at 11:34:58AM +0200, Thomas Goirand wrote:
> [ Reason ]
> CVE-2023-43040
> 
> [ Impact ]
> security issue with RGW with improperly verified POST keys.

Sorry for the delay; please go ahead.

Thanks,

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

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

Bug#1068516: O: sachesi -- BlackBerry 10 device utility

[Bastian Germann]

Package: wnpp

I am no longer interested in maintaining sachesi. Please consider adopting.
The upstream is not active any longer, so it is not too much effort.

Bug#1068242: bookworm-pu: package libtool/2.4.7-7~deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Apr 02, 2024 at 04:48:50PM +0200, Andreas Beckmann wrote:
> [ Reason ]
> I'd like to rebuild libtool from sid in order to fix two RC bugs:
> * missing Conflicts against an obsolete (now virtual) package name
>   causing file conflicts on some upgrade paths of systems initially
>   installed while the obsolete package was still a real package
> * incorrect detection of the += feature causing problems for packages
>   using it

Please go ahead.

Thanks,


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

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

Bug#1068411: bookworm-pu: package schleuder/4.0.3-7+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Apr 04, 2024 at 06:45:44PM +, Georg Faerber wrote:
> Schleuder, as currently present in bookworm, 4.0.3-7, is affected by
> multiple bugs, which I would like to address via this proposed-update,
> 4.0.3-7+deb12u1.

Please go ahead.

Thanks,

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

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

Bug#1068106: bookworm-pu: package libarchive/3.6.2-1+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Hi,

On Sat, Mar 30, 2024 at 08:51:10PM +0200, Peter Pentchev wrote:
> [ Reason ]
> Revert a change made by the same person that smuggled
> the backdoor into xz. See #1068047 for more details.

Please go ahead. However I wonder if you also want to wait for a patch for
https://github.com/libarchive/libarchive/issues/2107 and include that? If
so please un-confirm this bug and provide an updated debdiff when ready.

Thanks,

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

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

Bug#1068515: linux: nolapic makes live image in VM unbootable

[Roland Clobus]

Source: linux
Version: 6.7.9-2
Severity: normal

Hello maintainers of the Linux kernel,

Since the upgrade from 6.6.15-2 to 6.7.9-2 in sid, I've noticed in 
openQA [1] that in grub the boot option intended for safe booting does 
not result in a bootable VM any more. I've reduced the kernel boot 
options and 'nolapic' is the single kernel boot parameter that stops the 
VM from booting properly.

This can be seen only in UEFI boots, not when booting from BIOS.

I've looked at the code directly related, but did not see anything 
obvious [2][3].


FYI: The option 'nolapic' has been in use for the 'safe boot option' 
since 2012 in the live images.


With kind regards,
Roland Clobus

PS: No system information attached, as this was sent from my regular PC

[1] https://openqa.debian.net/tests/248490#step/bootwalk_1/4
Breadcrumb: https://openqa.debian.net/ | Debian Live | 
xxx_sid_smallest_build | walk-boot-options@uefi | bootwalk_1
[2] 
https://sources.debian.org/src/linux/6.7.9-2/arch/x86/kernel/apic/apic.c/#L2780
[3] 
https://sources.debian.org/src/linux/6.6.15-2/arch/x86/kernel/apic/apic.c/#L2782


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Santiago Vila]

Hi. I have made the upload.

But now I remember that this may get rejected for requiring
new binary packages (not sure if this has changed since the last
time), so wish me luck...

Thanks a lot for all the help!

Bug#1067085: nanobind-dev not in python path and without distribution info

[Timo Röhling]

Hi,

On Mon, 18 Mar 2024 08:16:33 + Francesco Ballarin 
 wrote:
1) The user guide at 
https://nanobind.readthedocs.io/en/latest/building.html#finding-nanobind

states that the downstream user should query
python3 -m nanobind --cmake_dir
to determine where nanobind is installed.
The `python3 -m nanobind --cmake_dir` call is only needed for the 
pip/conda package because it installs the CMake config in a location 
that is not searched by default. It is not necessary for the Debian 
package -- find_package(nanobind) works out of the box -- but does 
not hurt (much) either.


2) Downstream users or packages may have a pyproject.toml file 
which

contains

[build-system]
requires = ["nanobind"]

I added a new binary package python3-nanobind, which provides the 
nanobind module for this use case. Technically, it is not needed for 
the reason outlined above, but if it makes life easier for 
downstream users, that's good enough for me.



Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1068514: bullseye-pu: package imlib2/1.7.1-2

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: iml...@packages.debian.org, a...@debian.org
Control: affects -1 + src:imlib2

[ Reason ]

Fixing CVE-2024-25447, CVE-2024-25448 and CVE-2024-25450 in bullseye.

[ Impact ]

CVE remain unfixed in bullseye while they are already fixed in stable
and newer distributions.

[ Tests ]

Code changes are trivial

[ Risks ]

Code changes are trivial and are already present in bookworm. No
regressions have been reported.

[ 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 ]

A variable in the tgaflip function was multiplied with the height and not
the width which can cause a heap buffer overflow.
diff -Nru imlib2-1.7.1/debian/changelog imlib2-1.7.1/debian/changelog
--- imlib2-1.7.1/debian/changelog   2021-01-23 22:00:25.0 +0100
+++ imlib2-1.7.1/debian/changelog   2024-04-06 22:40:50.0 +0200
@@ -1,3 +1,11 @@
+imlib2 (1.7.1-2+deb11u1) bullseye; urgency=medium
+
+  * Fix CVE-2024-25447 and CVE-2024-25448 and CVE-2024-25450.
+A heap-buffer overflow vulnerability was discovered in imlib2 when using
+the tgaflip function in loader_tga.c
+
+ -- Markus Koschany   Sat, 06 Apr 2024 22:40:50 +0200
+
 imlib2 (1.7.1-2) unstable; urgency=medium
 
   * Drop obsolete libltdl3-dev dependency.
diff -Nru 
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
 
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
--- 
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
  1970-01-01 01:00:00.0 +0100
+++ 
imlib2-1.7.1/debian/patches/CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch
  2024-04-06 22:40:50.0 +0200
@@ -0,0 +1,26 @@
+From: Markus Koschany 
+Date: Fri, 5 Apr 2024 16:29:27 +0200
+Subject: CVE-2024-25447 and CVE-2024-25448 and CVE-2024-25450
+
+Origin: 
https://git.enlightenment.org/old/legacy-imlib2/commit/e9c09deb08047c9e902ce37144e82b6edb8aedb6
+---
+ src/modules/loaders/loader_tga.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/modules/loaders/loader_tga.c 
b/src/modules/loaders/loader_tga.c
+index e9729b0..ae96a3b 100644
+--- a/src/modules/loaders/loader_tga.c
 b/src/modules/loaders/loader_tga.c
+@@ -595,9 +595,9 @@ tgaflip(DATA32 * in, int w, int h, int fliph, int flipv)
+ x2 = fliph ? w - 1 : 0;
+ for (x = 0; x < nx; x++, x2 += dx)
+   {
+- tmp = in[y * h + x];
+- in[y * h + x] = in[y2 * h + x2];
+- in[y2 * h + x2] = tmp;
++ tmp = in[y * w + x];
++ in[y * w + x] = in[y2 * w + x2];
++ in[y2 * w + x2] = tmp;
+   }
+  }
+ }
diff -Nru imlib2-1.7.1/debian/patches/series imlib2-1.7.1/debian/patches/series
--- imlib2-1.7.1/debian/patches/series  2021-01-23 22:00:25.0 +0100
+++ imlib2-1.7.1/debian/patches/series  2024-04-06 22:40:50.0 +0200
@@ -1 +1,2 @@
 01_removed-data-dir.patch
+CVE-2024-25447-and-CVE-2024-25448-and-CVE-2024-25450.patch

Bug#1068513: dablin: FTBFS on arm{el,hf}: manually disables mpg123's large file API

[Sebastian Ramacher]

Source: dablin
Version: 1.15.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=dablin=armel=1.15.0-1%2Bb2=1712391165=0

[ 97%] Linking CXX executable dablin
cd /<>/obj-arm-linux-gnueabi/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/dablin.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -pie -z 
now -rdynamic CMakeFiles/dablin.dir/sdl_output.cpp.o 
CMakeFiles/dablin.dir/dabplus_decoder.cpp.o 
CMakeFiles/dablin.dir/ensemble_source.cpp.o 
CMakeFiles/dablin.dir/ensemble_player.cpp.o 
CMakeFiles/dablin.dir/edi_source.cpp.o CMakeFiles/dablin.dir/edi_player.cpp.o 
CMakeFiles/dablin.dir/eti_source.cpp.o CMakeFiles/dablin.dir/eti_player.cpp.o 
CMakeFiles/dablin.dir/dab_decoder.cpp.o CMakeFiles/dablin.dir/fic_decoder.cpp.o 
CMakeFiles/dablin.dir/pcm_output.cpp.o CMakeFiles/dablin.dir/tools.cpp.o 
CMakeFiles/dablin.dir/version.cpp.o CMakeFiles/dablin.dir/dablin.cpp.o -o 
dablin  ../fec/libfec.a /usr/lib/arm-linux-gnueabi/libatomic.so.1 -lmpg123 
-lSDL2 -lfaad -lc -lm 
/usr/bin/ld: CMakeFiles/dablin.dir/dab_decoder.cpp.o: in function 
`MP2Decoder::DecodeFrame(unsigned char**)':
./obj-arm-linux-gnueabi/src/./src/dab_decoder.cpp:166:(.text+0x1bb4): undefined 
reference to `mpg123_framebyframe_decode'
collect2: error: ld returned 1 exit status
make[3]: *** [src/CMakeFiles/dablin.dir/build.make:313: src/dablin] Error 1
make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[2]: *** [CMakeFiles/Makefile2:263: src/CMakeFiles/dablin.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
[100%] Linking CXX executable dablin_gtk
cd /<>/obj-arm-linux-gnueabi/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/dablin_gtk.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -pie -z 
now -rdynamic CMakeFiles/dablin_gtk.dir/sdl_output.cpp.o 
CMakeFiles/dablin_gtk.dir/dabplus_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/ensemble_source.cpp.o 
CMakeFiles/dablin_gtk.dir/ensemble_player.cpp.o 
CMakeFiles/dablin_gtk.dir/edi_source.cpp.o 
CMakeFiles/dablin_gtk.dir/edi_player.cpp.o 
CMakeFiles/dablin_gtk.dir/eti_source.cpp.o 
CMakeFiles/dablin_gtk.dir/eti_player.cpp.o 
CMakeFiles/dablin_gtk.dir/dab_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/fic_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/pcm_output.cpp.o 
CMakeFiles/dablin_gtk.dir/tools.cpp.o CMakeFiles/dablin_gtk.dir/version.cpp.o 
CMakeFiles/dablin_gtk.dir/mot_manager.cpp.o 
CMakeFiles/dablin_gtk.dir/pad_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/dablin_gtk.cpp.o 
CMakeFiles/dablin_gtk.dir/dablin_gtk_dl_plus.cpp.o 
CMakeFiles/dablin_gtk.dir/dablin_gtk_sls.cpp.o -o dablin_gtk  ../fec/libfec.a 
/usr/lib/arm-linux-gnueabi/libatomic.so.1 -lmpg123 -lSDL2 -lfaad -lc 
-lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lgtk-3 -lgdk-3 -lz -latk-1.0 
-lcairo-gobject -lgio-2.0 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 
-lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lgdk_pixbuf-2.0 -lgobject-2.0 
-lglib-2.0 -lm 
/usr/bin/ld: CMakeFiles/dablin_gtk.dir/dab_decoder.cpp.o: in function 
`MP2Decoder::DecodeFrame(unsigned char**)':
./obj-arm-linux-gnueabi/src/./src/dab_decoder.cpp:166:(.text+0x1bb4): undefined 
reference to `mpg123_framebyframe_decode'
collect2: error: ld returned 1 exit status
make[3]: *** [src/CMakeFiles/dablin_gtk.dir/build.make:377: src/dablin_gtk] 
Error 1

This is caused by

#define MPG123_NO_LARGENAME // disable large file API here

in src/dab_decoder.h

Cheers
-- 
Sebastian Ramacher

Bug#1068512: welle.io: FTBFS on arm{el,hf}: manually disables mpg123's LFS API

[Sebastian Ramacher]

Source: welle.io
Version: 2.4+ds-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=welle.io=armel=2.4%2Bds-2%2Bb3=1712391447=0

[ 99%] Linking CXX executable welle-io
/usr/bin/cmake -E cmake_link_script CMakeFiles/welle-io.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now 
-rdynamic "CMakeFiles/welle-io.dir/welle-io_autogen/mocs_compilation.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/main.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/audio_output.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/mot_image_provider.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/gui_helper.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/radio_controller.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/mpris/mpris.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/mpris/mpris_mp2.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/mpris/mpris_mp2_player.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/debug_output.cpp.o" 
"CMakeFiles/welle-io.dir/src/welle-gui/waterfallitem.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/dab-audio.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/decoder_adapter.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/dab_decoder.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/dabplus_decoder.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/charsets.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/dab-constants.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/mot_manager.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/pad_decoder.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/eep-protection.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/fib-processor.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/fic-handler.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/msc-handler.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/freq-interleaver.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/ofdm-decoder.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/ofdm-processor.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/phasereference.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/phasetable.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/tii-decoder.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/protTables.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/radio-receiver.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/tools.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/uep-protection.cpp.o" 
"CMakeFiles/welle-io.dir/src/backend/viterbi.cpp.o" 
"CMakeFiles/welle-io.dir/src/various/Socket.cpp.o" 
"CMakeFiles/welle-io.dir/src/various/Xtan2.cpp.o" 
"CMakeFiles/welle-io.dir/src/various/channels.cpp.o" 
"CMakeFiles/welle-io.dir/src/various/fft.cpp.o" 
"CMakeFiles/welle-io.dir/src/various/profiling.cpp.o" 
"CMakeFiles/welle-io.dir/src/various/wavfile.c.o" 
"CMakeFiles/welle-io.dir/src/libs/fec/decode_rs_char.c.o" 
"CMakeFiles/welle-io.dir/src/libs/fec/encode_rs_char.c.o" 
"CMakeFiles/welle-io.dir/src/libs/fec/init_rs_char.c.o" 
"CMakeFiles/welle-io.dir/src/input/input_factory.cpp.o" 
"CMakeFiles/welle-io.dir/src/input/null_device.cpp.o" 
"CMakeFiles/welle-io.dir/src/input/raw_file.cpp.o" 
"CMakeFiles/welle-io.dir/src/input/rtl_tcp.cpp.o" 
"CMakeFiles/welle-io.dir/src/input/rtl_sdr.cpp.o" 
"CMakeFiles/welle-io.dir/src/input/airspy_sdr.cpp.o" 
"CMakeFiles/welle-io.dir/src/input/soapy_sdr.cpp.o" 
"CMakeFiles/welle-io.dir/welle-io_autogen/MOX6SOXE6H/qrc_resources.cpp.o" -o 
welle-io  -lrtlsdr -lairspy -lfftw3f -lfaad 
/usr/lib/arm-linux-gnueabi/libSoapySDR.so.0.8.1 -lmpg123 
/usr/lib/arm-linux-gnueabi/libQt5Multimedia.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5Charts.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5QuickControls2.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5DBus.so.5.15.10 -pthread 
/usr/lib/arm-linux-gnueabi/libQt5Widgets.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5Quick.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5QmlModels.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5Qml.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5Network.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5Gui.so.5.15.10 
/usr/lib/arm-linux-gnueabi/libQt5Core.so.5.15.10 
/usr/bin/ld: CMakeFiles/welle-io.dir/src/backend/dab_decoder.cpp.o: in function 
`MP2Decoder::DecodeFrame(unsigned char**)':
./obj-arm-linux-gnueabi/./src/backend/dab_decoder.cpp:168:(.text+0x1c6c): 
undefined reference to `mpg123_framebyframe_decode'
collect2: error: ld returned 1 exit status

This is caused by 

#define MPG123_NO_LARGENAME // disable large file API here

in src/dab_decoder.h

Cheers
-- 
Sebastian Ramacher

Bug#1063757:

[Mario Limonciello]

Could you please also capture the value in
/sys/devices/system/cpu/intel_pstate/turbo_pct when you reproduced the
issue?

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Sven Joachim]

On 2024-04-06 21:45 +0200, Santiago Vila wrote:

> El 6/4/24 a las 20:53, Sven Joachim escribió:
>> 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11
>
> Ok, I had not read that part of Policy in a long time.
>
> One minor last thing:
>
> Assuming I make the changes and package the new available
> upstream version at the same time, can I simplify the breaks
> and replaces to just "(<< 1.3-20240307)"?

Yes, that should be fine.

Cheers,
   Sven

Bug#1068363: src:autopkgtest: flaky autopkgtest (host dependent?) on ppc64el

[Paul Gevers]

The mystery continues.

On 04-04-2024 10:08 p.m., Paul Gevers wrote:
I forgot that on amd64, autopkgtest's autopkgtest now runs in qemu which 
doesn't benefit yet as much from tmpfs as lxc does, so it's not a good 
comparison.


On ci-worker13:
"""
root@elbrus:/tmp/autopkgtest-lxc.ww6f2cls/downtmp/build.VWV/src# df -h
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   250G   44G  207G  18% /
none492K  4.0K  488K   1% /dev
tmpfs   126G 0  126G   0% /dev/shm
tmpfs51G   52K   51G   1% /run
tmpfs   5.0M 0  5.0M   0% /run/lock
root@elbrus:/tmp/autopkgtest-lxc.ww6f2cls/downtmp/build.VWV/src# 
AUTOPKGTEST_TEST_SCHROOT=testing-amd64-sbuild tests/autopkgtest 
SchrootRunner.test_copy_timeout

test_copy_timeout (__main__.SchrootRunner.test_copy_timeout)
handling copying timeout ... ok

--
Ran 1 test in 5.768s

OK
"""

So it's not only tmpfs. I ran the test on ci-worker-ppc64el-05 (no other 
tests were running at the time) with adapted timeout. If I reduce the 
current 3 sec copy-timeout to 1 sec the test passes (2 seconds is too 
long, only int allowed). If I try the same thing in the opposite 
direction on ci-worker13, raising to 4 seconds causes failure in the 
"""self.assertLess(huge_size, 100)""", with bumping to 5 seconds 
fails in the same way. ci-worker13 was running quite some tests at the 
same time, not sure if that's related.


Anyways, it looks like we could just lower the timeout to 1 second and 
hope were fine for some time to come.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067829: Fails to build on arm{el,hf} with 64bit time_t: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-We

[Chuck Lever III]

> On Apr 6, 2024, at 3:15 PM, Salvatore Bonaccorso  wrote:
> 
> Hi Chuck, hi Steve,
> 
> In Debian, as you might have heard there is a 64bit time_t
> transition[1] ongoing affecting the armel and armhf architectures.
> While doing so, nfs-utils was found to fail to build for those
> architectures after the switch, reported in Debian as [2]. Vladimir
> Petko from Ubuntu has as well filled it in [3].
> 
> [1]: https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
> [2]: https://bugs.debian.org/1067829
> [3]: https://bugzilla.kernel.org/show_bug.cgi?id=218540
> 
> The report is full-quoted below. 
> 
> Vladimir Petko has created a patch in the bugzilla which I'm attaching
> here as well. If this is not an acceptable format due to missing
> Signed-off's I'm attaching a variant with a Suggested-by for Vladimir
> to properly credit the patch origin.
> 
> Let me know if that works. I changed it slightly and only casting to
> long long, and made it almost checkpatch clean.

I suppose strftime(3) might be nicer, but this works.

Reviewed-by: Chuck Lever mailto:chuck.le...@oracle.com>>


> Regards,
> Salvatore
> 
> - Forwarded message from Sebastian Ramacher  -
> 
> From: Sebastian Ramacher 
> Resent-From: Sebastian Ramacher 
> Reply-To: Sebastian Ramacher , 1067...@bugs.debian.org
> Date: Wed, 27 Mar 2024 11:02:25 +0100
> To: Debian Bug Tracking System 
> Subject: Bug#1067829: nfs-utils: FTBFS on arm{el,hf}: export-cache.c:110:51: 
> error: format ‘%ld’ expects argument of
> type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} 
> [-Werror=format=]
> Delivered-To: sub...@bugs.debian.org
> Message-ID: 
> 
> Source: nfs-utils
> Version: 1:2.6.4-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=nfs-utils=armel=1%3A2.6.4-3%2Bb2=1711452552=0
> 
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../support/include 
> -I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
> -D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes 
> -Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2 
> -Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2 
> -Werror=init-self -Werror=implicit-function-declaration -Werror=return-type 
> -Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return 
> -Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2 
> -Werror=int-conversion -Werror=incompatible-pointer-types 
> -Werror=misleading-indentation -Wno-cast-function-type -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -c xml.c  -fPIC -DPIC -o .libs/xml.o
> export-cache.c: In function ‘junction_flush_exports_cache’:
> export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long 
> int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
>  110 | snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
>  | ~~^ ~~~
>  |   | |
>  |   | time_t {aka 
> long long int}
>  |   long int
>  | %lld
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../support/include 
> -I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
> -D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes 
> -Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2 
> -Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2 
> -Werror=init-self -Werror=implicit-function-declaration -Werror=return-type 
> -Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return 
> -Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2 
> -Werror=int-conversion -Werror=incompatible-pointer-types 
> -Werror=misleading-indentation -Wno-cast-function-type -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -c display.c -o display.o >/dev/null 2>&1
> cc1: some warnings being treated as errors
> make[3]: *** [Makefile:489: export-cache.lo] Error 1
> make[3]: *** Waiting for unfinished jobs
> 
> Cheers
> -- 
> Sebastian Ramacher
> 
> - End forwarded message -
> <0001-junction-export-cache-cast-to-a-type-with-a-known-si.patch>

--
Chuck Lever

Bug#1068233: snappy-java: please add support for loong64

[tony mancill]

On Tue, Apr 02, 2024 at 11:44:10AM +, wuruilong wrote:
> Source: snappy-java
> Severity: wishlist
> X-Debbugs-Cc: wuruil...@loongson.cn
> 
> Dear Maintainer,
> 
> According to the upstream commit, the loong64 architecture needs to update 
> the attachment code to compile correctly.
> The attached binary file libsnappyjava.so needs to be placed in the following 
> directory
> src/main/resources/org/xerial/snappy/native/Linux/loongarch64/libsnappyjava.so
> 
> wuruilong

Hi,

Thank you for the bug report and the reference to the PR against
snappy-java.  It would be helpful if upstream would include this in a
tagged release.

In the meantime, we can patch the build system for snappy-java to
support building JNI bindings for loong64.  We don't require the
libsnappyjava.so.  That'll be built and link to the loong64 build of
snappy [1].

Thank you,
tony

[1] 
https://buildd.debian.org/status/logs.php?pkg=snappy=1.1.10-1=loong64


signature.asc
Description: PGP signature

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Santiago Vila]

El 6/4/24 a las 20:53, Sven Joachim escribió:

1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11


Ok, I had not read that part of Policy in a long time.

One minor last thing:

Assuming I make the changes and package the new available
upstream version at the same time, can I simplify the breaks
and replaces to just "(<< 1.3-20240307)"?

Thanks.

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sebastian Andrzej Siewior]

On 2024-04-06 17:17:45 [+0800], Sean Whitton wrote:
> Hello,
Hi,

> It looks like the problem is opening YAPET1.0-format databases, which
> the manpage explicitly says is meant to work.
> 
> I've made a sample YAPET1.0 database using a stretch VM.  Using the
> attached:
> 
> - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it.
> - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't.

Thank you for the testcase. It asks for a password, what is it?

Sebastian

Bug#1067829: Fails to build on arm{el,hf} with 64bit time_t: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-We

[Salvatore Bonaccorso]

Hi Chuck, hi Steve,

In Debian, as you might have heard there is a 64bit time_t
transition[1] ongoing affecting the armel and armhf architectures.
While doing so, nfs-utils was found to fail to build for those
architectures after the switch, reported in Debian as [2]. Vladimir
Petko from Ubuntu has as well filled it in [3].

 [1]: https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
 [2]: https://bugs.debian.org/1067829
 [3]: https://bugzilla.kernel.org/show_bug.cgi?id=218540

The report is full-quoted below. 

Vladimir Petko has created a patch in the bugzilla which I'm attaching
here as well. If this is not an acceptable format due to missing
Signed-off's I'm attaching a variant with a Suggested-by for Vladimir
to properly credit the patch origin.

Let me know if that works. I changed it slightly and only casting to
long long, and made it almost checkpatch clean.

Regards,
Salvatore

- Forwarded message from Sebastian Ramacher  -

From: Sebastian Ramacher 
Resent-From: Sebastian Ramacher 
Reply-To: Sebastian Ramacher , 1067...@bugs.debian.org
Date: Wed, 27 Mar 2024 11:02:25 +0100
To: Debian Bug Tracking System 
Subject: Bug#1067829: nfs-utils: FTBFS on arm{el,hf}: export-cache.c:110:51: 
error: format ‘%ld’ expects argument of
type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} 
[-Werror=format=]
Delivered-To: sub...@bugs.debian.org
Message-ID: 

Source: nfs-utils
Version: 1:2.6.4-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=nfs-utils=armel=1%3A2.6.4-3%2Bb2=1711452552=0

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../support/include 
-I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes 
-Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2 
-Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2 
-Werror=init-self -Werror=implicit-function-declaration -Werror=return-type 
-Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return 
-Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2 
-Werror=int-conversion -Werror=incompatible-pointer-types 
-Werror=misleading-indentation -Wno-cast-function-type -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -c xml.c  -fPIC -DPIC -o .libs/xml.o
export-cache.c: In function ‘junction_flush_exports_cache’:
export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, 
but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
  110 | snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
  | ~~^ ~~~
  |   | |
  |   | time_t {aka 
long long int}
  |   long int
  | %lld
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../support/include 
-I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes 
-Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2 
-Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2 
-Werror=init-self -Werror=implicit-function-declaration -Werror=return-type 
-Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return 
-Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2 
-Werror=int-conversion -Werror=incompatible-pointer-types 
-Werror=misleading-indentation -Wno-cast-function-type -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -c display.c -o display.o >/dev/null 2>&1
cc1: some warnings being treated as errors
make[3]: *** [Makefile:489: export-cache.lo] Error 1
make[3]: *** Waiting for unfinished jobs

Cheers
-- 
Sebastian Ramacher

- End forwarded message -
Description: cast to a type with a known size to ensure sprintf works
Author: Vladimir Petko 
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=218540
Bug-Ubuntu:  https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2055349
Last-Update: 2024-02-29
--- a/support/junction/export-cache.c
+++ b/support/junction/export-cache.c
@@ -107,7 +107,7 @@
 		xlog(D_GENERAL, "%s: time(3) failed", __func__);
 		return FEDFS_ERR_SVRFAULT;
 	}
-	snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
+	snprintf(flushtime, sizeof(flushtime), "%lld\n", (long long int)now);
 
 	

Bug#1068511: caddy: does not satisfy httpd virtual package

[Cameron Steffen]

Package: caddy
Version: 2.6.2-5
Severity: normal

Dear Maintainer,

I would like to be able to install the wordpress package with caddy,
without installing apache2 or another server. I believe the caddy
package should fulfill the httpd package and then this would be
possible.

Thanks!
Cameron


-- 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-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.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 caddy depends on:
ii  libc6  2.36-9+deb12u4
ii  libnss3-tools  2:3.87.1-1
ii  libzstd1   1.5.4+dfsg2-5
ii  media-types10.0.0

caddy recommends no packages.

caddy suggests no packages.

-- Configuration Files:
/etc/caddy/Caddyfile changed [not included]

-- no debconf information

Bug#1022073: pUpload of new upstream version of pam-u2f pending within the next 1-2 weeks.

[Taowa]

Hello Patrick,

Patrick Winnertz, 2024-04-06 14:36 -0400:
> Currently the packaging work is done within a fork and I created a merge
> request into the main repository, in the hope that I can get part of the
> authentification team.

Welcome to the authentication tools team! I've made you a maintainer in
Salsa.

Thank you for your work!

Taowa

Bug#1068510: bobcat: provide a separate bobcat-source package for bootstrapping icmake

[tony mancill]

Source: bobcat
Version: 6.04.00-1
Severity: important

A separate bobcat-source binary package will enable icmake 12.x to be
bootstrapped without having to vendor in a copy of the bobcat sources.

Also see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051966
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068068


signature.asc
Description: PGP signature

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Sven Joachim]

On 2024-04-06 19:49 +0200, Santiago Vila wrote:

>> Patch attached, I have tested that it builds on amd64 and i386. looked
>> at the generated Dependencies and verified that lintian does not go
>> crazy, but that's it.  Note that I had to add libtool-bin rather than
>> just libtool to Build-Depends to prevent configure from complaining, and
>> also pacify dh_missing considering the not installed .la file.
>
> Awesome, thanks a lot!
>
> Regarding the static library, I can see now that keeping it does not
> really make the package more complex, so we'll keep it.
>
> A few questions:
>
> - Does this require a "transition"? I think not, because the API has not
> changed. On the other hand, packages which build-depend on libdialog-dev
> should be rebuilt with the shared library anyway, and this is usually done
> as part of a transition.

Considering that there are currently no packages in unstable which
build-depend on libdialog-dev (or on dialog, for that matter), a
transition seems unnecessary.

> - Regarding the Breaks field, I think it's not actually required and
> we should not add it (i.e. Replaces is enough).

Policy disagrees, and the piuparts maintainer might come after you if
they detect that.

> I tried creating the packages without the Breaks field, installing the
> libdialog and libdialog-dev packages on a system where dialog was
> already installed, and this is what happened:
>
> # dpkg -i libdialog-dev_1.3-20240101-2_amd64.deb 
> libdialog15_1.3-20240101-2_amd64.deb
> (Reading database ... 14174 files and directories currently installed.)
> Preparing to unpack libdialog-dev_1.3-20240101-2_amd64.deb ...
> Unpacking libdialog-dev:amd64 (1.3-20240101-2) ...
> Replacing files in old package dialog (1.3-20240101-1) ...
> Preparing to unpack libdialog15_1.3-20240101-2_amd64.deb ...
> Unpacking libdialog15:amd64 (1.3-20240101-2) over (1.3-20240101-2) ...
> Setting up libdialog15:amd64 (1.3-20240101-2) ...
> Setting up libdialog-dev:amd64 (1.3-20240101-2) ...
> Processing triggers for man-db (2.12.1-1) ...
> Not building database; man-db/auto-update is not 'true'.
> Processing triggers for libc-bin (2.37-15.1) ...
>
> i.e. no errors, dpkg takes note of the moved files, and the old dialog
> is still functional, because it's still linked statically.

Yes, but if you then decide to remove the libdialog-dev package, the
libdialog.a file is gone, although the old dialog package supposedly
still provides libdialog-dev.  That is the reason why Policy recommends
to use "Replaces" in combination with "Breaks"[1].

Cheers,
   Sven


1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11

Bug#1068436: transmission RFS

[Barak A. Pearlmutter]

Well, given that the main maintainer dropped themselves from the
debian/control file, I think the package can be freely adopted,
keeping Leo Antunes on of course in case he reappears. I'll drop the
two of them a note asking for objections, and assuming there are none,
I'd suggest we go ahead with that. What do you think? This would be:

Maintainer: Leo Antunes 
Uploaders: Alexandre Rossi ,
   Barak A. Pearlmutter 

and would allow "proper" uploads, not just NMUs.

I merged your "fix build on bookworm" patch, but the package still
builds fine on a chroot on my own machine, and fails to build on
salsa,
https://salsa.debian.org/bap/transmission/-/pipelines

If you feel like preparing a serious 4.0.5-2 candidate with
*everything* you think belongs included, rather than just a minimal
NMU, that would be great!

What I meant with the pre-built javascript business was that it's more
robust to set things up so *if* the tools to do so are available, that
stuff is rebuilt. But if not, e.g., if someone is building for a small
platform or porting or just wants to build a local copy and doesn't
want to install that stuff, it would use pre-built files instead. This
also makes it easier for porters. This seems like pretty much what
upstream advocates in web/README.md, except the idea is to automate
it. With that stuff in place, it's a lot easier to argue that using
the prebuilt files under some particular circumstance (like some
package is missing from Debian for the moment) is not serious enough
of an issue to delay progression to testing etc.

And yes, your "proper" cmake-test-based -latomic fix is the "right"
way to do it, unlike the sleazy hack I put in debian/rules.

--Barak.

Bug#1068236: autopkgtest: does not manage to uninstall non-t64 libraries

[Paul Gevers]

Control: tags -1 pending

Hi Samuel,

On 02-04-2024 2:50 p.m., Samuel Thibault wrote:

Should we perhaps make autopkgtest really try this last attempt?


We have been and still are working on several merge requests that should 
improve the situation in these weird times: 
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1022073: pUpload of new upstream version of pam-u2f pending within the next 1-2 weeks.

[Patrick Winnertz]

tags 1022073 + pending
tags 1061859 + pending
thanks

I contacted Alessio Di Mauro (Yubico) and asked if he can update the 
package in Debian to the latest upstream release. His answer was that 
Yubico has a own PPA now and has no further interest in maintaining 
packages within individual distributions. As the second uploader (nicoo) 
is currently inactive and the package has a not acknowledge NMU and is 
missing responses to bugs since several years I would  take over the 
uploadership (see [1]) but leave the Maintainer 
(team+a...@trackers.debian.org) intact, so that also in future this 
package could be team-maintained and team uploads are allowed.


Currently the packaging work is done within a fork and I created a merge 
request into the main repository, in the hope that I can get part of the 
authentification team.


With best regards
Patrick (winnie)


[1]: https://wiki.debian.org/PackageSalvaging
--

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  win...@debian.org/patr...@winnertz.eu
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43
 ⠈⠳⣄

The people who refer to the pandemic in the past tense and climate 
change in the future tense are the reason everything is going to shit.


OpenPGP_0xC6D50A4188C70E43.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068509: liferea: autopkgtest on s390x suggests liferea is partially broken there

[Paul Gevers]

Package: liferea
Version: 1.15.6-1
X-Debbugs-CC: debian-s...@lists.debian.org
Severity: normal
User: debian-s...@lists.debian.org
Usertag: s390x

Hi,

Today I was debugging the failing autopkgtest of liferea, a graphical 
rss reader, on s390x [1]. Previously I already worked around another 
crash that happens on s390x only. Although I wonder how useful a desktop 
application like liferea is on such an architecture, I tried to get it 
to work. Luckily dogtail (the framework I use to drive the test) has 
screenshot functionality and I noticed that after requesting the help or 
the FAQ, there is no text in the window that on other architectures 
shows the content of the help/FAQ. Once the tests for 1.15.6-2 or higher 
run on ci.debian.net, the screenshots will be part of the artifacts tar 
that can be downloaded from the web page.


I'm suspecting that something in the lower layers is broken, but I have 
absolutely no evidence. Filing this bug just for visibility. For 
avoidance of doubt, I consider here 3 things (which I suspect are related):

1) the crash in the "liferea.dump()" call is highly suspicious
2) the button for the Help should be the same across architectures
3) the screenshots for the help and FAQ should show the content

Paul

[1] https://ci.debian.net/packages/l/liferea/testing/s390x/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039607: libjansi-java: causes maven to always output escape character

[tony mancill]

On Sat, Apr 06, 2024 at 11:09:07AM +0200, Emmanuel Bourg wrote:
> Le 05/01/2024 à 07:22, tony mancill a écrit :
> 
> > However, for the short-term, I believe we can achieve the desired
> > behavior and fix the issue for most use cases by
> > 
> > 1. Patching the mvn wrapper script in our maven package to set
> > jansi.mode=force (and thus colorize output) unless the --batch-mode
> > option is provided.
> > 
> > 2. Moving forward with the current jansi package in experimental.
> > 
> > That restores the desired --batch-mode behavior but maintains
> > colorized output by default and during Debian package builds.
> > 
> > Would that be acceptable?
> 
> Hi Tony,
> 
> Was this plan fully implemented? Maven builds from the command line and
> inside pbuilder are no longer colorized currently.

Hi Emmanuel,

The uploads of src:maven and src:jansi were completed in mid-February.
I ended up not uploading the change to maven-debian-helper in
experimental because I didn't think it was necessary.

mvn on the command-line produced colorized output by default on my
system and in clean unstable and trixie chroots (attached screenshot).
If that's not working for you, then let me know.  Perhaps more work is
needed on the patch in src:maven.

However, I'm not seeing colorized output on my system during sbuild, so
there are still something amiss.  I notice that "--batch-mode" is being
explicitly passed to the maven invocation via this code [1], which
explains that behavior.

>   dh_auto_build -O--buildsystem=maven
>/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

I will have to look into why the tput (no longer?) succeeds during sbuild.
In fact, it's failing for plain `dpkg-buildpackage` in my terminal, even
though the following (negated condition) test generates output:

$ perl -e "if ((`tput colors 2>/dev/null` >= 8)) { print 'foo'; }"

So I think the issue is in maven-debian-helper and that the other
changes are working as expected.

You should be seeing colorized output on the terminal unless you
explicitly override it.  Let me know if you're seeing something else.

Thank you,
tony

[1] 
https://salsa.debian.org/java-team/maven-debian-helper/-/blob/c03c5403539eb4dc35947b35f51d72d74620637a/share/perl/maven.pm#L53-55


signature.asc
Description: PGP signature

Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1

[Thorsten Glaser]

Jonathan Wiltshire dixit:

>Please go ahead.

Thanks. Do you need a blurb for the point release notes
or something?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1063757:

[Mario Limonciello]

In that case can you please modify the daemon's systemd unit to run
the daemon with -vv in the ExecStart command then share the unit's
journal output from a boot this occurs to better understand it?

Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Santiago Vila]

Patch attached, I have tested that it builds on amd64 and i386. looked
at the generated Dependencies and verified that lintian does not go
crazy, but that's it.  Note that I had to add libtool-bin rather than
just libtool to Build-Depends to prevent configure from complaining, and
also pacify dh_missing considering the not installed .la file.


Awesome, thanks a lot!

Regarding the static library, I can see now that keeping it does not
really make the package more complex, so we'll keep it.

A few questions:

- Does this require a "transition"? I think not, because the API has not
changed. On the other hand, packages which build-depend on libdialog-dev
should be rebuilt with the shared library anyway, and this is usually done
as part of a transition.

- Regarding the Breaks field, I think it's not actually required and
we should not add it (i.e. Replaces is enough).

I tried creating the packages without the Breaks field, installing the
libdialog and libdialog-dev packages on a system where dialog was
already installed, and this is what happened:

# dpkg -i libdialog-dev_1.3-20240101-2_amd64.deb 
libdialog15_1.3-20240101-2_amd64.deb
(Reading database ... 14174 files and directories currently installed.)
Preparing to unpack libdialog-dev_1.3-20240101-2_amd64.deb ...
Unpacking libdialog-dev:amd64 (1.3-20240101-2) ...
Replacing files in old package dialog (1.3-20240101-1) ...
Preparing to unpack libdialog15_1.3-20240101-2_amd64.deb ...
Unpacking libdialog15:amd64 (1.3-20240101-2) over (1.3-20240101-2) ...
Setting up libdialog15:amd64 (1.3-20240101-2) ...
Setting up libdialog-dev:amd64 (1.3-20240101-2) ...
Processing triggers for man-db (2.12.1-1) ...
Not building database; man-db/auto-update is not 'true'.
Processing triggers for libc-bin (2.37-15.1) ...

i.e. no errors, dpkg takes note of the moved files, and the old dialog
is still functional, because it's still linked statically.

Thanks.

Bug#1066869: RFS: hyprpaper/0.6.0-1 [ITP] -- Wallpaper utility for Hyprland

[Alan M Varghese]

Hello Andrey,


$(MAKE) clear (as a replacement for $(MAKE) clean) should run in
override_dh_auto_clean, not override_dh_clean.

Done.


debian/watch is empty

Filled in.


There is a commented out override_dh_auto_configure.

Removed.


002-add-fortify-flags.patch adds -D_FORTIFY_SOURCE=2 explicitly, but the
proper fix is making the upstream build system respect the compile flags
set by dpkg-buildflags.

Removed the patch. Instead, export CXXFLAGS from debian/rules.

Thanks,
Alan

Bug#1068508: RFA: r4d -- Remote For Device-under-test (R4D) Daemon

[Bastian Germann]

Package: wnpp

I am hereby requesting an adopter for r4d. The package does not see regular 
releases and is in good shape generally.
I do no longer use it and it would be nice to get it off my responsibilities.

Bug#1068451: libtommath 1.2.0-6+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068451 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: libtommath
Version: 1.2.0-6+deb12u1

Explanation: fix integer overflow [CVE-2023-36328]

Bug#1068436: transmission RFS

[Alexandre Rossi]

Hi,

> In the meantime, I note that Sandro Tosi has dropped his
> maintainership of the package, but pushed a debian/4.0.5-2 tag without
> uploading. Do you know the status of that?

I have had no answer from both listed maintainers since last January. I
have tried to contact them through salsa comment, bug reports and direct
e-mail.

> The two top bugs are a missing -latomic on ARM, which should be easy
> enough to work around in debian/rules using
>   include /usr/share/dpkg/architecture.mk
>   if ...

Maybe this fix should be upstreamed with something looking like a
similar change:
https://patch-diff.githubusercontent.com/raw/ccache/ccache/pull/723.patch

> and the prebuilt javascript business, which I note from MR/16 you've
> been working on. One suggestion I have for that is to set things up so
> that *if* the tools are available, the javascript can be rebuilt; but
> if not, pre-built versions are used anyway. This would make things
> robust, and would I think allow the bug to be downgraded.

I fail to understand how using prebuild versions would fix the bug or
how handling the case where the tools are not available would help.
Would you elaborate on the use case?

> I'm also not thrilled with how the build process adds a git hook if it
> can. Should probably hot-wire that off, because it seems to present a
> potential security issue. Just a quilt patch to disable the entire
> if(GIT_FOUND) thing at the end of CMakeLists.txt seems about right.
> (The Source Control System is supposed to control the build, not vice
> versa!)

I completely agree but as we are in the context of a NMU, I wanted to
keep focused.

To sum things up, I understand that my upload needs an update for the
missing -latomic issue. I'll prepare an update.

Thanks for your interest,

Alex

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Russ Allbery]

Sean Whitton  writes:

> We have two seconded solutions, so you and I should perhaps break the
> tie.  I prefer the Bill's 'Autobuild: no' solution as the more
> conservative change: we only have data about packages that are currently
> autobuilt, not those that aren't, so we might be making those buggy if
> we just ban network access for all non-free packages.  How about you?

Yup, let's go with Bill's change since it's a bit more conservative.  I
think it accomplishes the same goal.

-- 
Russ Allbery (r...@debian.org)  

Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing

[Martin Dosch]

Dear Andrey,

On 06.04.2024 19:25, Andrey Rakhmatullin wrote:

You need to use bash_unit from the package. Likely as simple as
"./bash_unit".


thanks, that's it. Just pushed the changes and uploaded to mentors.

Best regards,
Martin


signature.asc
Description: PGP signature

Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Apr 03, 2024 at 02:59:08PM +0200, Thorsten Glaser wrote:
> I would like to ask for pre-approval to uploading a
> proposed stable update for mksh.

Please go ahead.

Thanks,

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

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

Bug#1068344: bookworm-pu: package curl/7.88.1-10+deb12u6

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Wed, Apr 03, 2024 at 04:05:17PM -0300, Guilherme Puida Moreira wrote:
> [ Reason ]
> 1. Fix CVE-2004
> 2. Fix CVE-2398

Please detail what these actually are in the changelog; other than that, go
ahead.

Thanks,


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

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

Bug#1068507: libxpresent: New upstream version

[Bastian Germann]

Source: libxpresent
Version: 1.0.0-2
Severity: wishlist

Please import the latest upstream version, which is 1.0.1 currently.

Bug#1068506: python3-traitlets: breaks jupyter

[Jörg-Volker Peetz]

Package: python3-traitlets
Version: 5.14.2-2
Severity: important

Dear Debian Python Team,

this version breaks jupyter (package jupyter-core), e.g., commanding

$ jupyter notebook list

which crashes with the following output:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 235, in
_resolve_classes
klass = self._resolve_string(klass)
^^^
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 2015, in
_resolve_string
return import_item(string)
   ^^^
  File "/usr/lib/python3/dist-packages/traitlets/utils/importstring.py", line
33, in import_item
module = __import__(package, fromlist=[obj])
 ^^^
ModuleNotFoundError: No module named 'jupyter_server'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/jupyter-notebook", line 33, in 
sys.exit(load_entry_point('notebook==6.4.12', 'console_scripts',
'jupyter-notebook')())

^
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 282,
in launch_instance
super().launch_instance(argv=argv, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line
1073, in launch_instance
app = cls.instance(**kwargs)
  ^^
  File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line
583, in instance
inst = cls(*args, **kwargs)
   
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1292, in
__new__
inst.setup_instance(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1335, in
setup_instance
super(HasTraits, self).setup_instance(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/traitlets.py", line 1311, in
setup_instance
init(self)
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 226, in
instance_init
self._resolve_classes()
  File "/usr/lib/python3/dist-packages/notebook/traittypes.py", line 238, in
_resolve_classes
warn(f"{klass} is not importable. Is it installed?", ImportWarning)
TypeError: warn() missing 1 required keyword-only argument: 'stacklevel'


Reverting to version 5.5.0-2 makes jupyter working again.

Regards,
Jörg.


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

Kernel: Linux 6.8.4 (SMP w/8 CPU threads)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Jupyter packages:
   jupyter-client  7.4.9-2
A  jupyter-core5.3.2-1
A  jupyter-nbextension-jupyter-js-widg 8.1.1-2
   jupyter-notebook6.4.12-2.2
A  python3-jupyter-client  7.4.9-2
A  python3-jupyter-core5.3.2-1
A  python3-jupyterlab-pygments 0.2.2-3
A  python3-notebook6.4.12-2.2

Python:
   python3-dev 3.11.8-1

Versions of packages python3-traitlets depends on:
ii  python3  3.11.8-1

python3-traitlets recommends no packages.

python3-traitlets suggests no packages.

-- no debconf information

Bug#1068487: man-db: Failed to get unit file state for man-db.service: Transport endpoint is not connected

[Colin Watson]

Control: reassign -1 systemd

On Sat, Apr 06, 2024 at 11:18:55AM +0800, Bo YU wrote:
> Today upgraded my riscv64 sid , I got:
> 
> ```
> Setting up man-db (2.12.1-1) ...
> Updating database of manual pages ...
> Reload daemon failed: Transport endpoint is not connected
> 
> Failed to get unit file state for man-db.service: Transport endpoint is not 
> connected
> Failed to retrieve unit state: Transport endpoint is not connected
> man-db.service is a disabled or a static unit not running, not starting it.
> Failed to get unit file state for man-db.timer: Transport endpoint is not 
> connected
> Failed to retrieve unit state: Transport endpoint is not connected
> man-db.timer is a disabled or a static unit not running, not starting it.
> ...
> Setting up openssh-sftp-server (1:9.7p1-4) ...
> Setting up openssh-server (1:9.7p1-4) ...
> Reload daemon failed: Transport endpoint is not connected
> Failed to get properties: Transport endpoint is not connected
> Reload daemon failed: Transport endpoint is not connected
> Failed to get unit file state for ssh.service: Transport endpoint is not 
> connected
> Failed to retrieve unit state: Transport endpoint is not connected
> ssh.service is a disabled or a static unit not running, not starting it.
> ^B^[[5~Reload daemon failed: Transport endpoint is not connected
> Failed to get unit file state for ssh.socket: Transport endpoint is not 
> connected
> Failed to retrieve unit state: Transport endpoint is not connected
> ...
> ```
> 
> And this process is very time-consuming also.

Hi,

This is all fairly clearly a systemd issue rather than anything
specifically to do with man-db, so reassigning there.  I'm afraid I
don't have any further clues though.

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

Bug#1055064: ITP: libsilkit4 -- library for connecting software-in-the-loop environments

[Tobias Frost]

Control: tags -1 wontfix
Control: close -1 

Details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055448#19:

Quote:
 sorry for the long wait. It took some time to fix all problems and
 synchronize efforts within Vector. Unfortunately, we do not have a plan
 for community contributions in the short/midterm.  This might change in
 the future, we (the SIL Kit team) just cannot say when it will be
 happening.

 For now, we have made the decision to post pone our efforts to package
 SIL Kit within the Debian archive.  Instead, we will shift development
 completely to the public Github repo and try to grow the community with
 the goal to accept patches in the future.


I think the best is to close this ITP and revisit it once this is not
oly stamped wit a Open Source license, but also living the principles of
FOSS.


On Mon, 30 Oct 2023 15:32:15 + =?iso-8859-1?Q?Kr=E4mer=2C_Jan?=
 wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name    : libsilkit4
>   Version : 4.0.37
>   Upstream Author : Vector Informatik GmbH
> * URL : https://github.com/vectorgrp/sil-kit
> * License : MIT
>   Programming Lang: C++
>   Description : library for connecting software-in-the-loop
environments
> 
> 
> The Vector SIL Kit is an open-source library for connecting Software-
in-the-Loop Environments. One of the design goals of SIL Kit is to
easily connect different third-party tools, such as emulators (such as
QEMU), virtual machines and simulation tools. The goal of having this
package within the Debian Package ecosystem is to provide users of SIL
Kit an easy and unified way of installing and updating their
installation of SIL Kit.
> 
> We (Vector Informatik GmbH) would offer to package and maintain SIL
Kit (libsilkit4). I (Jan Kraemer, jan.krae...@vector.com) would be the
primary contact/proposed maintainer. But since we are new to the Debian
community we are looking for a sponsor.
> 
> 
> 

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Milan Broz]

On 4/6/24 5:34 PM, Lucas Thode wrote:

Even when built a statically linked libdieharder, I still get bogus results 
(using yesterday's HEAD):


Why yesterday's? The patch landed today. git pull?

The last patch in git log should be "Avoid overflow in DAB Monobit2 test."

With older code anything with -d 209 and -n over 15 corrupts memory and cannot 
get
any useful output.

Milan

Bug#1060939: python-workalendar: FTBFS because of failing tests

[Santiago Vila]

forwarded 1060939 https://github.com/workalendar/workalendar/issues/764
tags 1060939 + bookworm
thanks

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Lucas Thode]

Even when built a statically linked libdieharder, I still get bogus results
(using yesterday's HEAD):
$ ldd dieharder/dieharder
linux-vdso.so.1 (0x7ffe9b548000)
libgsl.so.27 => /lib/x86_64-linux-gnu/libgsl.so.27 (0x7f28f3c0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f28f3b21000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f28f393f000)
libgslcblas.so.0 => /lib/x86_64-linux-gnu/libgslcblas.so.0
(0x7f28f3ef2000)
/lib64/ld-linux-x86-64.so.2 (0x7f28f4007000)
$ ./dieharder/dieharder -d 209 -n 17 -p 1
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown
   #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  8.76e+07  | 422973324|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  17|  6500|   1|0.|  FAILED
$ ./dieharder/dieharder -d 209 -n 20 -p 1
Segmentation fault

On Sat, Apr 6, 2024 at 10:23 AM Milan Broz  wrote:

> On 4/6/24 4:33 PM, Lucas Thode wrote:
> ...
> > $ ./dieharder/dieharder -d 209 -n 17 -p 1
> >
> #=#
> > #dieharder version 3.31.1 Copyright 2003 Robert G. Brown
>  #
> >
> #=#
> > rng_name|rands/second|   Seed   |
> >  mt19937|  1.75e+08  |2063877943|
> >
> #=#
> >  test_name   |ntup| tsamples |psamples|  p-value |Assessment
> >
> #=#
> >  dab_monobit2|  17|  6500|   1|1.|  FAILED
>
> This should not be possible.
>
> Are you sure you run the patched version with patched libdieharder (and
> not one from system)?
> You can avoid it by "./configure --disable-shared" to force static link.
>
> This is what I get from current code
> (https://github.com/eddelbuettel/dieharder):
>
> ./dieharder/dieharder -d 209 -n 17 -p 1
> Error:  Can only use ntup up to 15.
>  Read test description with dieharder -d 209 -h.
>
> Milan
>

Bug#993018: valgrind: vgcore files unusable in gdb / does not load debug symbols

[Bernhard Übelacker]

control: forwarded 993018 https://bugs.kde.org/show_bug.cgi?id=485134
control: found 993018 1:3.20.0-2.1


Hello,
I got recently remembered about this bug and patch.
So I try to find out what upstream thinks about this.

It can still be observed with current version in Trixie/testing.

Kind regards,
Bernhard

Bug#1068449: opentracker: libowfat headers have moved

[Bastian Germann]

Control: severity -1 serious

The FTBFS now happens with:

cc -c -o ot_mutex.o -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/bage/opentracker-0.0~git20210823.110868e=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -Wall -pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/libowfat -Wall 
-pipe -Wextra  -O3 -DWANT_ACCESSLIST_WHITE -DWANT_COMPRESSION_GZIP -DWANT_SYSLOGS -DWANT_RESTRICT_STATS 
-DWANT_ACCESSLIST_WHITE -DWANT_COMPRESSION_GZIP -DWANT_SYSLOGS -DWANT_RESTRICT_STATS -DWANT_FULLSCRAPE ot_mutex.c

scan_urlencoded_query.c:10:10: fatal error: scan.h: No such file or directory
   10 | #include "scan.h"
  |  ^~~~
compilation terminated.
make[2]: *** [Makefile:87: scan_urlencoded_query.o] Error 1
make[2]: *** Waiting for unfinished jobs
ot_mutex.c:14:10: fatal error: byte.h: No such file or directory
   14 | #include "byte.h"
  |  ^~~~
compilation terminated.
make[2]: *** [Makefile:87: ot_mutex.o] Error 1
trackerlogic.c:16:10: fatal error: byte.h: No such file or directory
   16 | #include "byte.h"
  |  ^~~~
compilation terminated.
make[2]: *** [Makefile:87: trackerlogic.o] Error 1
opentracker.c:24:10: fatal error: socket.h: No such file or directory
   24 | #include "socket.h"
  |  ^~
compilation terminated.
make[2]: *** [Makefile:87: opentracker.o] Error 1
make[2]: Leaving directory 
'/home/bage/opentracker-0.0~git20210823.110868e/opentracker-ipv4'
dh_auto_build: error: cd opentracker-ipv4 && make -j4 "INSTALL=install 
--strip-program=true" returned exit code 2

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Milan Broz]

On 4/6/24 4:33 PM, Lucas Thode wrote:
...

$ ./dieharder/dieharder -d 209 -n 17 -p 1
#=#
#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #
#=#
    rng_name    |rands/second|   Seed   |
         mt19937|  1.75e+08  |2063877943|
#=#
         test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
         dab_monobit2|  17|  6500|       1|1.|  FAILED


This should not be possible.

Are you sure you run the patched version with patched libdieharder (and not one 
from system)?
You can avoid it by "./configure --disable-shared" to force static link.

This is what I get from current code
(https://github.com/eddelbuettel/dieharder):

./dieharder/dieharder -d 209 -n 17 -p 1
Error:  Can only use ntup up to 15.
Read test description with dieharder -d 209 -h.

Milan

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Thorsten Glaser]

Rich Felker dixit:

>Is there anything weird about how these objects were declared that
>might have caused ld not to resolve them statically like it should? It
>seems odd that these data symbols, but not any other ones, would be
>left as symbolic relocations.

I don’t think so?

In  I already
posted the short version; the actual source is (mirrored):

The initcoms array is here:
https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/main.c#L77

Tdr is defined at:
https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L3055

The u_ops array is declared a few lines above that and defined at:
https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/funcs.c#L160

initvsn is defined at…
https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L713
… with the EXTERN and E_INIT macros from…
https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L657
where main.c defines EXTERN, so the string is embedded into the file using it.

Is there perhaps a misunderstanding with the gcc/binutils/glibc developers
as to what static-pie is meant to be?

bye,
//mirabilos
-- 
 cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können?  bis dahin gibts google nicht
mehr  ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Lucas Thode]

The updated version is still buggy, albeit in a different way, as it hangs
for n=18, fails the test for n=19, then segfaults for any n after that:

 ./dieharder/dieharder -d 209 -n 12 -p 1
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown
   #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  1.59e+08  |1346171031|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  12|  6500|   1|0.31742526|  PASSED
$ ./dieharder/dieharder -d 209 -n 17 -p 1
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown
   #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  1.75e+08  |2063877943|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  17|  6500|   1|1.|  FAILED
$ ./dieharder/dieharder -d 209 -n 18 -p 1
^C
$ ./dieharder/dieharder -d 209 -n 19 -p 1
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown
   #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  1.78e+08  |2027322855|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  19|  6500|   1|0.|  FAILED
$ ./dieharder/dieharder -d 209 -n 20 -p 1
Segmentation fault
$ LD_LIBRARY_PATH=libdieharder/.libs gdb --args dieharder/.libs/dieharder
-d 209 -n 20 -p 1
(gdb) run
Starting program: ~/dieharder-test/dieharder/.libs/dieharder -d 209 -n 20
-p 1
Program received signal SIGSEGV, Segmentation fault.
add_2_test (dtest=0x3ff0, test=0x5558a830, count=1)
at std_test.c:233
233 for(j = 0;j < dtest->nkps;j++){
(gdb) bt
#0  add_2_test (dtest=0x3ff0, test=0x5558a830, count=1)
at std_test.c:233
#1  0x9bac in execute_test (dtest_num=209) at run_test.c:92
#2  0x9d82 in run_test () at run_test.c:32
#3  0x633e in main (argc=7, argv=0x7fffe078) at
dieharder.c:90

Unfortunately, the trail of what looks to be stack corruption goes cold
from there...

On Fri, Apr 5, 2024 at 1:24 PM Dirk Eddelbuettel  wrote:

>
> Hi Lucas,
>
> On 30 March 2024 at 22:47, Lucas Thode wrote:
> | Package: dieharder
> | Version: 3.31.1.4-1.1
> | Severity: normal
> | X-Debbugs-Cc: thode...@gmail.com
> |
> | Dear Maintainer,
> |
> | `dieharder -d 209 -n $nvalue` crashes for $nvalue>17:
> |
> | $ dieharder -d 209
> |
> #=#
> | #dieharder version 3.31.1 Copyright 2003 Robert G. Brown
>   #
> |
> #=#
> |rng_name|rands/second|   Seed   |
> | mt19937|  1.55e+08  |2819069712|
> |
> #=#
> | test_name   |ntup| tsamples |psamples|  p-value |Assessment
> |
> #=#
> | dab_monobit2|  12|  6500|   1|0.40510331|  PASSED
> | $ dieharder -d 209 -n 12
> |
> #=#
> | #dieharder version 3.31.1 Copyright 2003 Robert G. Brown
>   #
> |
> #=#
> |rng_name|rands/second|   Seed   |
> | mt19937|  2.54e+08  | 152376536|
> |
> #=#
> | test_name   |ntup| tsamples |psamples|  p-value |Assessment
> |
> #=#
> | dab_monobit2|  12|  6500|   1|0.10580971|  PASSED
> | $ dieharder -d 209 -n 17
> |
> #=#
> | #dieharder version 3.31.1 Copyright 2003 Robert G. Brown
>   #
> |
> #=#
> |rng_name|rands/second|   Seed   |
> | 

Bug#1035312: minetest: New upstream version available (5.7.0)

[Tobias Frost]

On Thu, 7 Sep 2023 00:36:32 +0200 tuxayo  wrote:
> On Sun, 23 Jul 2023 10:10:17 +0200 Tobias Frost 
wrote:
> > --> we will need to use the bundled lua.
> 
> As a blanket solution yes. But IIUC it seems running the tests can
tell 
> if a given Debian version is affected:
> 
>
https://github.com/minetest/minetest/issues/12778#issuecomment-1250255332
>  > Effects you can expect if the test fails: Minetest continues to
work 
> mostly normally, but memory leaks can happen and error handling might 
> not work correctly in edge cases.
> 
> Cheers,
> 
> -- 
> tuxayo
> 

For documentatoon: minetest FTBFS with system-lua, upstream enforces it
in their CMakeLists.txt:

> CMake Error at src/CMakeLists.txt:718 (message):
>   It looks like you're trying to build Minetest using a system-wide
> Lua
>   installation.  This is no longer supported because PUC Lua cannot
>   interoperate with C++ correctly.  Read src/unittest/test_lua.cpp for
>   technical details.
> 

 (and if that check is disabled, it will FTBFS later.) 

I'm disabling archs where lua-jit is not possible, as the bundled lua
*might* (not verified!) have security issues unhandled and we're only
loosing ppc64el in the set of release archtitecures. [1]

[1]https://github.com/minetest/minetest/issues/12778#issuecomment-1251597494


--
tobi

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Max Nikulin]

On Mon, 1 Apr 2024 21:32:41 +0300 Antti-Pekka Känsälä wrote:

Closing the Gmail tab will not help.


I rarely use gmail web UI. At least in the case of KDE, Firefox releases
file descriptor a few seconds after compose dialog is closed. It seems
even closing the tab is not necessary. It was a file on an internal
drive, but I do not think it matters.


appe@renaissance:~$ lsof | grep -i KINGSTON
x-www-bro 83803 appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83807 glean.dis appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg

[...]

From my point of view it is in contradiction with the original complain:


I am worried Gmail in a Firefox tab is able to break out of Firefox
somehow, gaining unauthorized access to 128 files on a mounted USB stick.


Isn't /media/appe/KINGSTON/noname/file4.gpg the file you attached? What 
are other 127 files?

Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing

[Andrey Rakhmatullin]

On Sat, Apr 06, 2024 at 02:14:11PM +, Martin Dosch wrote:
> > Hi Martin, you added a B-D on itself, I assume it's to run build-time
> > tests, buit the idea of build-time tests is to use the software being
> > package,
> 
> Do you know how to achieve this? When I remove the build-dep on itself the
> built fails as the test can not be performed:
> >debian/rules override_dh_auto_test
> > make[1]: Entering directory '/<>'
> > bash_unit -f tap ./tests/test_*
> > /bin/sh: 1: bash_unit: not found
> > make[1]: *** [debian/rules:9: override_dh_auto_test] Error 127
You need to use bash_unit from the package. Likely as simple as
"./bash_unit".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing

[Martin Dosch]

Dear Andrey,

On 06.04.2024 13:36, Andrey Rakhmatullin wrote:

Hi Martin, you added a B-D on itself, I assume it's to run build-time
tests, buit the idea of build-time tests is to use the software being
package, 


Do you know how to achieve this? When I remove the build-dep on itself 
the built fails as the test can not be performed:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
bash_unit -f tap ./tests/test_*
/bin/sh: 1: bash_unit: not found
make[1]: *** [debian/rules:9: override_dh_auto_test] Error 127




not the version from repos (also B-D on itself orevents it from
being built).
Yes, as it's not yet in the repos I had to inject it locally to get it 
built.


Best regards,
Martin


signature.asc
Description: PGP signature

Bug#1067691: FTBFS: double free or corruption

[Matteo Bini]

Hi Andrey,
on my aarch64 Raspberry Pi 4, I can successfully build the armel
package.

How can I find a way to reproduce that memory error? Maybe I should
remove the fft const test.

Thanks for the help.

--
Matteo Bini

Bug#1068393: src:pytest-testinfra: unsatisfied build dependency in testing: ansible

[Baptiste Beauplat]

Control: block -1 by 1061781

Hi Paul,

On Thu, 2024-04-04 at 14:38 +0200, Paul Gevers wrote:
> Dose [1] is reporting a build issue with your package, it's missing a
> build dependency. Obviously your build dependencies shouldn't be
> removed from testing, but unfortunately there are multiple scenarios
> where that can happen nevertheless. To uphold our social contract,
> Debian requires that packages can be rebuild from source in the suite
> we are shipping them, so currently this is a serious issue with your
> package in testing.
> 
> Can you please investigate the situation and figure out how to resolve
> it? Regularly, if the build dependency is available in unstable,
> helping the maintainer of your Build-Depends to enable migration to
> testing is a great way to solve the issue. If your build dependency is
> gone from unstable and testing, you'll have to fix the build process
> in some other way.

Thanks for the hint. I'm not sure I can help ansible migrate (it would
need an update to the latest upstream and that's not a trivial task),
but I'll do the maintenance on this bug report, closing it once pytest-
testinfra is removed from testing.

Best,
-- 
Baptiste Beauplat



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

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Salvatore Bonaccorso]

Hi Sean,

On Sat, Apr 06, 2024 at 04:54:14PM +0800, Sean Whitton wrote:
> control: reassign -1 libssl3,yapet
> control: found -1 libssl3/3.1.5-1
> control: found -1 yapet/2.6-1
> control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB
> 
> Hello,
> 
> On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote:
> 
> >>
> >>> Also, yapet is unchanged in unstable. Is the problem there, too?
> >>
> 
> I have now confirmed that the problem is in unstable too.

As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is
it reassigned to yapet? (the regression is as well present in
unstable).

That said: You are right, opening 1.0 format databases should still
work that said, but is regressing with the openssl update. And as per
manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET
2.0 files are converted to YAPET 2.0 files when changing the master
password. Once converted, the files can no longer be read by pre YAPET
2.0 versions.

I can ask upstream, but currently yapet will FTBFS with problems in
the testsuite anyway, and the problems are related.

And yapet FTBFS with the new openssl in bookworm-pu in same way as in
unstable (but not with the old version).

Thus I believe #1068045 and #1064724 are actually related.

Regards,
Salvatore

Bug#1064724: yapet: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Salvatore Bonaccorso]

Hi,

On Thu, Mar 21, 2024 at 09:09:02AM +0100, Salvatore Bonaccorso wrote:
> Hi Vladimir,
> 
> On Thu, Mar 21, 2024 at 08:39:32PM +1300, Vladimir Petko wrote:
> > Package: yapet
> > Followup-For: Bug #1064724
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu noble ubuntu-patch
> > Control: tags -1 patch
> > 
> > Dear Maintainer,
> > 
> > The package fails to build due to the recent changes in openssl.
> > I have disabled the affected tests, but probably the issue should be fixed
> > upstream.
> > 
> > When investigating test failure I've also noticed that the tests fail on 
> > armhf
> > due to the usage of std::memset that was optimized away. I have replaced the
> > call with std::fill()
> > 
> > In Ubuntu, the attached patch was applied to achieve the following:
> > 
> >   * d/p/use-std-fill.patch: use std::fill to reset memory instead of
> > std::memset. This fixes armhf test failure (LP: 2058584).
> >   * d/p/disable-blowfish-tests.patch: disable failing blowfish tests.
> > See Debian bug 1064724.
> > 
> > 
> > Thanks for considering the patch.
> 
> Thanks for your work. I would like to give upstream some time to look
> at the two reported issues.

I'm not going to apply the patch for now, as the underlying issue is
triggered due to a change in openssl. Cf. #1068045.

Regards,
Salvatore

Bug#1068505: RFH: reprepro -- Move experimental multi-version feature to unstable

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:reprepro

Hi,

To tackle the much-requested #570623 multiple version management in reprepro, I took over Maintainership of the package 
and integrated the existing work in experimental. There are three important bugs that were filed against it that need to 
be fixed to finally merge that work to unstable. The bugs are


#1051537
#1016111
#1017983

One of them is surely a big endian-only bug, the other ones are database 
consistency problems that might be related.

As many in the Debian world depend on reprepro to manage their repositories, I would like to ask for help because I did 
not have the capacity in the last two years (and probably not in the remaining year to come during the trixy cycle) to 
give those bugs the attention that they deserve.


Thanks for your help,
Bastian

Bug#1068436: transmission RFS

[Barak A. Pearlmutter]

I use transmission constantly and would be happy to sponsor. In
principle of course: assuming there are no technical show-stoppers.

I already have my own fork on salsa.debian.org/bap/transmission with
some very minor tweaks.

In the meantime, I note that Sandro Tosi has dropped his
maintainership of the package, but pushed a debian/4.0.5-2 tag without
uploading. Do you know the status of that?

The two top bugs are a missing -latomic on ARM, which should be easy
enough to work around in debian/rules using
  include /usr/share/dpkg/architecture.mk
  if ...
and the prebuilt javascript business, which I note from MR/16 you've
been working on. One suggestion I have for that is to set things up so
that *if* the tools are available, the javascript can be rebuilt; but
if not, pre-built versions are used anyway. This would make things
robust, and would I think allow the bug to be downgraded.

I'm also not thrilled with how the build process adds a git hook if it
can. Should probably hot-wire that off, because it seems to present a
potential security issue. Just a quilt patch to disable the entire
if(GIT_FOUND) thing at the end of CMakeLists.txt seems about right.
(The Source Control System is supposed to control the build, not vice
versa!)

Anyway, let me know if/when you want me to dput.

Cheers,

--Barak.

Bug#1068504: mumble-server: wrong path for systemd-sysusers file

[Stefan Schweizer]

Package: mumble-server
Severity: normal

Hi,

mumble-server installs a systemd-sysusers file to /etc/sysconfig.d

According to the sysusers.d(5) man page sysusers files can be placed in
/etc/sysusers.d/*.conf
/run/sysusers.d/*.conf
/usr/lib/sysusers.d/*.conf

So installing the sysusers file to /etc/sysconfig.d has no
effect and it should be moved to /usr/lib/sysusers.d.

Since the mumble-server user is created by the debian package I think
the sysusers file is unnecessary and can be omitted until a switch to
sysusers is made.

Bug#1068503: mlterm: Please consider dropping Canna (and perhaps freewnn)

[Andreas Metzler]

On 2024-04-06 Andreas Metzler  wrote:
[...]
> I had a look at the bug and it is non-trivial to fix. (I spent some
> effort, but gave up.) So I am wondering whether it would not make sense
> to stop building the mlterm canna input method plugin:
[...]

Hello,

trivial patch attached.

Looking at debian/rules I wondered wheter dh_autoreconf couldn't be used
for mlterm and also came up with a patch. Perhaps yo'll kike it.

cu Andreas
>From 41d63723968d031e29499c3f3c9839ea555ea395 Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Sat, 6 Apr 2024 08:39:19 +0200
Subject: [PATCH 1/3] Drop Canna input method plugin

Canna has been dead upstream for decades
---
 debian/control | 14 +-
 debian/mlterm-im-canna.install |  1 -
 debian/rules   |  4 ++--
 3 files changed, 3 insertions(+), 16 deletions(-)
 delete mode 100644 debian/mlterm-im-canna.install

diff --git a/debian/control b/debian/control
index 720daeb..09eccac 100644
--- a/debian/control
+++ b/debian/control
@@ -1,11 +1,11 @@
 Source: mlterm
 Section: x11
 Priority: optional
 Maintainer: أحمد المحمودي (Ahmed El-Mahmoudy) 
 Uploaders: Hideki Yamane 
-Build-Depends: debhelper-compat (= 13), libgtk-4-dev, libtool, libx11-dev, libxext-dev, libxft-dev, x11proto-dev, libfribidi-dev, libxrender-dev, libuim-dev, libm17n-dev, libscim-dev, libgcroots-dev, libxml2-dev, libthai-dev, libibus-1.0-dev, libfcitx5gclient-dev, libfcitx5utils-dev, libssh2-1-dev, libcairo2-dev, libwnn-dev, libcanna1g-dev, libskk-dev
+Build-Depends: debhelper-compat (= 13), libgtk-4-dev, libtool, libx11-dev, libxext-dev, libxft-dev, x11proto-dev, libfribidi-dev, libxrender-dev, libuim-dev, libm17n-dev, libscim-dev, libgcroots-dev, libxml2-dev, libthai-dev, libibus-1.0-dev, libfcitx5gclient-dev, libfcitx5utils-dev, libssh2-1-dev, libcairo2-dev, libwnn-dev, libskk-dev
 Standards-Version: 4.6.2
 Rules-Requires-Root: binary-targets
 Homepage: https://mlterm.sourceforge.net
 Vcs-Git: https://salsa.debian.org/debian/mlterm.git
 Vcs-Browser: https://salsa.debian.org/debian/mlterm
@@ -162,22 +162,10 @@ Description: MultiLingual TERMinal, FreeWnn input method plugin
  various encodings, doublewidth characters, BiDi, Arabic shaping,
  and so on.
  .
  This package contains FreeWnn Input Method plugin for mlterm.
 
-Package: mlterm-im-canna
-Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, mlterm (= ${binary:Version}) | mlterm-tiny (= ${binary:Version})
-Pre-Depends: ${misc:Pre-Depends}
-Multi-Arch: same
-Description: MultiLingual TERMinal, Canna input method plugin
- mlterm is a terminal emulator for X Window System, which supports
- various encodings, doublewidth characters, BiDi, Arabic shaping,
- and so on.
- .
- This package contains Canna Input Method plugin for mlterm.
-
 Package: mlterm-im-skk
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}, mlterm (= ${binary:Version}) | mlterm-tiny (= ${binary:Version})
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
diff --git a/debian/mlterm-im-canna.install b/debian/mlterm-im-canna.install
deleted file mode 100644
index c0fe613..000
--- a/debian/mlterm-im-canna.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/*/mlterm/libim-canna.so
diff --git a/debian/rules b/debian/rules
index 3f09d13..b7618e6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,10 +25,11 @@ MLTERM_IM_FCITX=$(CURDIR)/debian/mlterm-im-fcitx
 
 OPTS_COMMON=--x-includes=/usr/X11R6/include \
 --x-libraries=/usr/X11R6/lib \
 --disable-rpath \
 --disable-iiimf \
+--disable-canna \
 --enable-vt52
   # --enable-utmp \
 
 OPTS_TINY=$(OPTS_COMMON) \
   --with-type-engines=xcore \
@@ -38,11 +39,10 @@ OPTS_TINY=$(OPTS_COMMON) \
   --disable-m17nlib \
   --disable-scim \
   --disable-fcitx \
   --disable-ibus \
   --disable-wnn \
-  --disable-canna \
   --disable-skk
 
 OPTS_MAIN=$(OPTS_COMMON) \
   --with-imagelib=gdk-pixbuf --with-type-engines=xcore,xft,cairo \
   --enable-optimize-redrawing \
@@ -76,11 +76,11 @@ override_dh_auto_build:
 	# configure again for installation (later)
 	DH_COMPAT=10 dh_auto_configure -- $(OPTS_MAIN) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed"
 
 override_dh_install:
 	# mlterm-common:
-	dh_install -pmlterm-common -Xuim -Xm17 -Xscim -Xibus -Xfcitx -Xwnn -Xcanna -Xskk -Xman1
+	dh_install -pmlterm-common -Xuim -Xm17 -Xscim -Xibus -Xfcitx -Xwnn -Xskk -Xman1
 	rm $(MLTERM_COMMON)/usr/lib/*/libpobl.so
 	rm $(MLTERM_COMMON)/usr/lib/*/libmef.so
 	for i in main font aafont key termcap xim color menu ; \
 	  do install -m 644 debian/config-$$i \
 	  $(MLTERM_COMMON)/etc/mlterm/$$i ; done
-- 
2.43.0

>From 546471fa7b354c474af163b601eeb4306e488f27 Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Sat, 6 Apr 2024 14:12:47 +0200
Subject: [PATCH 3/3] Support dh_autoreconf

---
 debian/autoreconf   |  3 +++
 debian/mlterm-tools.install |  

Bug#1068503: mlterm: Please consider dropping Canna (and perhaps freewnn)

[Andreas Metzler]

Package: mlterm
Version: 3.9.3-1
Severity: normal

Hello,

mlterm currently build-depends on canna to build "Canna input method
plugin". Canna is rc-buggy, it breaks on
-Werror=implicit-function-declaration (see #1066375 ).

I had a look at the bug and it is non-trivial to fix. (I spent some
effort, but gave up.) So I am wondering whether it would not make sense
to stop building the mlterm canna input method plugin:
* Canna is very dead upstream, 3.7p3 was uploaded to Debian in 2004.
* Canna is also orphaned in Debian, the last maintainer upload happened
  in 2007.
* Canna has only 28 popcon installations.

I am using mlterm but I do not speak or write Japanese so I really have
no idea how useful/popular the different Japanese input methods are.
However I can see that freewnn and canna are both very much dead
upstream and have been orphaned for a very long time.

cu Andreas

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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 mlterm depends on:
ii  libc62.37-15
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libx11-6 2:1.8.7-1
ii  mlterm-common3.9.3-1+b1

Versions of packages mlterm recommends:
ii  mlterm-tools  3.9.3-1+b1

Versions of packages mlterm suggests:
pn  fonts-arphic-bsmi00lp   
pn  fonts-arphic-gbsn00lp   
ii  fonts-freefont-ttf  20211204+svn4273-2
pn  fonts-noto-cjk | fonts-nanum
pn  fonts-vlgothic | fonts-japanese-gothic  
pn  mlterm-im-m17nlib   
pn  mlterm-im-scim  
pn  mlterm-im-uim   
pn  t1-cyrillic 
ii  unifont 1:15.1.01-1
ii  xfonts-efont-unicode0.4.2-12

-- no debconf information
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1063418: mdp ftbfs in unstable

[Andrey Rakhmatullin]

It currently fails even earlier:

ImportError while loading conftest '/<>/mdp/test/conftest.py'.
mdp/__init__.py:133: in 
utils.symeig = configuration.get_symeig(numx_linalg)
mdp/configuration.py:335: in get_symeig
args = getargs(numx_linalg.eigh)[0]
/usr/lib/python3.11/inspect.py:1379: in getfullargspec
raise TypeError('unsupported callable') from ex
E   TypeError: unsupported callable

This is reported upstream at
https://github.com/mdp-toolkit/mdp-toolkit/issues/99 and probably fixed at
https://github.com/mdp-toolkit/mdp-toolkit/pull/100 .

Not sure about the initially reported test_dtype_consistency failures.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068502: Dead upstream and broken, remove or switch to a fork?

[Andrey Rakhmatullin]

Source: python-pytest-flake8
Severity: serious

https://github.com/tholo/pytest-flake8/issues/98
https://github.com/tholo/pytest-flake8/issues/97
https://github.com/tholo/pytest-flake8/issues/92
https://github.com/tholo/pytest-flake8/issues/91


-- 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_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