Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Andreas Metzler]

On 2024-05-29 Luca Boccassi  wrote:
> On Wed, 29 May 2024 20:15:36 +0200 Michael Biebl  wrote:
>> On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi  wrote:
>>> On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl >> wrote:
[...]

 Please do not not ship conflicting configuration for /run/lock

 /usr/lib/tmpfiles.d/debian.conf:d /run/lock    1777 root root -  
> -
 /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -

 triggering unnecessary warnings.

>>> This is needed to apply debian-specific changes, just ignore it,
>>> it's
>>> harmless
[...]
> No. The current approach is just fine. If you don't like seeing the
> harmless notice-level log, just add a local override in /etc/.

>> Btw, please don't close bug reports without CCing the bug submitter. 
>> That's rude.

> Please stop playing ping pong with the BTS, this is staying as it is.

Hello,

Let me upvote this bug-report. I have unnecessarly spent time
investigating the issue, checking whether this is a known bug. Having
read through the bug I still have not read an explanation why the
current state "is just fine". If it really was systemd would not throw
a warning. What is the huge benefit of shipping conflicting configurations
instead of shipping one that is correct for Debian that justifies
wasting our contributors' time?

cu Andreas
-- 
`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#1072642: curl: FTBFS (TESTFAIL: These test cases failed: 241 507) (also applies to autopkgtest)

[Andreas Metzler]

On 2024-06-07 Carlos Henrique Lima Melara  wrote:
> On Wed, 5 Jun 2024 18:39:40 +0200 Andreas Metzler  wrote:
[...] 
>> TESTFAIL: These test cases failed: 241 507

> Were you able to consistently get those exact failures? We are getting
> some random and unreproducible failures since we have enabled parallel
> tests - but the speed up is jaw dropping.

> We have reported it to upstream already [1], but it's not very easy to
> debug. I also tried to build locally with sbuild and using debci [2] and
> they have succeeded, so maybe it's just a hicup.

> If you were able to consistently reproduce this, please let us know more
> about your build environment.
[...]

Hello Carlos,

at the specific point in time I looked into this I was getting exactly
these errors (241 507) both for a rebuild and when running
autopkgtest --no-built-binaries --output-dir=/tmp/CURL/ci-out -- null
in a regular sid chroot (using schroot). The ci-test produced these errors
both for the openssl and the gnutls subtest.

I will give rebuilding another shot and report back.

cu Andreas
-- 
`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#1072642: curl: FTBFS (TESTFAIL: These test cases failed: 241 507) (also applies to autopkgtest)

[Andreas Metzler]

Package: curl
Version: 8.8.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

I did a local rebuild on sid which failed:
srcdir=. /usr/bin/perl -I. ./runtests.pl -a -p ~flaky ~timing-dependent -n -j35 
~300 ~301 ~303 ~304 ~306 ~309 ~310 ~325 ~364 ~400 ~401 ~403 ~406 ~407 ~408 ~409 
~410 ~414 ~417 ~560 ~678 ~987 ~988 ~989 ~1112 ~1272 ~1470 ~1561 ~1562 ~1630 
~1631 ~1632 ~2034 ~2037 ~2041 ~3000 ~3001 ~3102
Using curl: ../src/curl
[...]
test 0241...[HTTP-IPv6 GET (using ip6-localhost)]

 241: protocol FAILED!
 There was no content at all in the file log/5/server.input.
 Server glitch? Total curl failure? Returned: 7
== Contents of files in the log/5/ dir after test 241
=== Start of file http_ipv6_server.log
 16:19:15.385882 Running HTTP IPv6 version on port 36339
 16:19:15.385966 Wrote pid 68256 to log/5/server/http_ipv6_server.pid
 16:19:15.385990 Wrote port 36339 to log/5/server/http_ipv6_server.port
 16:19:16.348256 > Client connect
 16:19:16.348285 accept_connection 3 returned 4
 16:19:16.348310 accept_connection 3 returned 0
 16:19:16.348377 Read 88 bytes
 16:19:16.348397 Process 88 bytes request
 16:19:16.348427 Got request: GET /verifiedserver HTTP/1.1
 16:19:16.348443 Are-we-friendly question received
 16:19:16.348471 Wrote request (88 bytes) input to log/5/server.input
 16:19:16.348499 Identifying ourselves as friends
 16:19:16.348570 Response sent (56 bytes) and written to log/5/server.response
 16:19:16.348589 special request received, no persistency
 16:19:16.348604 > Client disconnect 0
=== End of file http_ipv6_server.log
=== Start of file http_ipv6_verify.log
 *   Trying [::1]:36339...
 * Connected to ::1 (::1) port 36339
 > GET /verifiedserver HTTP/1.1
 > Host: [::1]:36339
 > User-Agent: curl/8.8.0
 > Accept: */*
 > 
 * Request completely sent off
 < HTTP/1.1 200 OK
 < Content-Length: 17
 < 
 { [17 bytes data]
 * Connection #0 to host ::1 left intact
=== End of file http_ipv6_verify.log
=== Start of file http_ipv6_verify.out
 WE ROOLZ: 68256
=== End of file http_ipv6_verify.out
=== Start of file server.cmd
 Testnum 241
=== End of file server.cmd
=== Start of file server.response
 HTTP/1.1 200 OK
 Content-Length: 17
 WE ROOLZ: 68256
=== End of file server.response
=== Start of file stderr241
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
 
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
 curl: (7) Failed to connect to ip6-localhost port 36339 after 106 ms: Couldn't 
connect to server
=== End of file stderr241
=== Start of file trace241
 16:19:16.524170 == Info: Host ip6-localhost:36339 was resolved.
 16:19:16.524215 == Info: IPv6: (none)
 16:19:16.524217 == Info: IPv4: 31.15.64.248
 16:19:16.524231 == Info:   Trying 31.15.64.248:36339...
 16:19:16.567508 == Info: connect to 31.15.64.248 port 36339 from 
192.168.178.20 port 40168 failed: Connection refused
 16:19:16.567523 == Info: Failed to connect to ip6-localhost port 36339 after 
106 ms: Couldn't connect to server
 16:19:16.567663 == Info: Closing connection
=== End of file trace241
[...]
test 0507...[multi interface get with non-existing host name]

lib507 returned 0, when expecting 6
 507: exit FAILED
== Contents of files in the log/31/ dir after test 507
=== Start of file server.cmd
 Testnum 507
=== End of file server.cmd
=== Start of file stderr507
 URL: http://non-existing-host.haxx.se/
 Test ended with result 0
=== End of file stderr507
=== Start of file stdout507
 HTTP/1.1 200 OK
 Date: Wed, 05 Jun 2024 16:19:18 GMT
 Server: Apache/2.4.59 (Debian)
 Last-Modified: Sun, 14 Feb 2016 17:00:04 GMT
 ETag: "0-52bbdd4e2cd00"
 Accept-Ranges: bytes
 Content-Length: 0
 Content-Type: text/html
=== End of file stdout507
[...]
2)
TESTDONE: 1700 tests were considered during 522 seconds.
TESTINFO: 195 tests were skipped due to these restraints:
TESTINFO: "curl lacks debug support" 99 times (159, 356, 358, 359, 363, 412, 
413, 437, 438 and 90 more)
TESTINFO: "curl lacks unittest support" 49 times (1300, 1302, 1303, 1304, 1305, 
1306, 1308, 1309, 1323 and 40 more)
TESTINFO: "configured as DISABLED" 16 times (323, 594, 836, 882, 938, 1182, 
1184, 1209, 1211 and 7 more)
TESTINFO: "failed starting HTTP/2 server" 7 times (1700, 1701, 1702, 2402, 
2403, 2404, 2405)
TESTINFO: "curl lacks Schannel support" 6 times (2033, 2070, 2079, 2087, 3023, 
3024)
TESTINFO: "no gnutls-serv (with SRP support)" 4 times (320, 321, 322, 324)
TESTINFO: "curl lacks http/3 support" 3 times (2500, 2502, 2503)
TESTINFO: "curl has idn support" 3 times (959, 960, 961)
TESTINFO: "curl lacks TrackMemory support" 2 times (96, 558)
TESTINFO: "curl has ipv6 support" 1 time (1454)
TESTINFO: "curl has threaded-resolver support" 1 time (506)
TESTINFO: "curl has proxy support" 1 time (375)

Bug#1072492: gnupg2: [INTL:nl] Dutch translation for the gnupg2 package

[Andreas Metzler]

On 2024-06-02 Frans Spiesschaert  wrote:
> Package: gnupg2 
> Severity: wishlist 
> Tags: l10n patch 

> Dear Maintainer, 

> Please find attached the updated Dutch po file for the gnupg2 package. 
> A draft has been posted to the debian-l10n-dutch mailing list allowing for
> review. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 
[...]

Hello Frans,

thank you. On what gnupg version did you base the translation? Has it
already been sent upstream?

cu Andreas
-- 
`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#1072278: scute: FTBFS against libassuan without libassuan-config

[Andreas Metzler]

Source: scute
Version: 1:1.5.0-1.1
Severity: important
User: ametz...@debian.org
Tags: patch
Usertags: libassuan-config-removal

scute will FTBFS against the next major libassuan release which drops
libassuan-config. That is because scute includes an outdated copy of
AM_PATH_LIBASSUAN() in m4/libassuan.m4 which cannot handle this upstream
change. Simply deleting m4/libassuan.m4 lets the build succeed. (A
slightly more involved fix would be to simply swthch to pkg-config.)

You can verify your fix by rebuilding after diverting libassuan-config like
this
dpkg-divert --rename --divert  /usr/bin/libassuan-config-disabled  --add 
/usr/bin/libassuan-config  # divert on

This change can be reverted with 
dpkg-divert --rename --remove /usr/bin/libassuan-config

cu Andreas

Bug#1072277: kleopatra: Searches for libassuan with libassuan-config

[Andreas Metzler]

Source: kleopatra
Version: 4:22.12.3-2
Severity: important
User: ametz...@debian.org
Usertags: libassuan-config-removal

kleopatra relies on libassuan-config to locate libassuan.
libassuan-config is scheduled for removal and will be dropped in
the next major libassuan release. Please use pkg-config/pkgconf instead.

You can verify your fix by rebuilding after diverting libassuan-config like
this
dpkg-divert --rename --divert  /usr/bin/libassuan-config-disabled  --add 
/usr/bin/libassuan-config  # divert on

This change can be reverted with 
dpkg-divert --rename --remove /usr/bin/libassuan-config

cu Andreas

Bug#1071864: gnupg-pkcs11-scd: Searches for libgcrypt with libgcrypt-config

[Andreas Metzler]

Control: notfound 1071864 7.0-005-1
Control: found 1071864 0.10.0-3
Control: clone 1071864 -1
Control: retitle -1 gnupg-pkcs11-scd: Searches for libassuan with 
libassuan-config

On 2024-05-25 Andreas Metzler  wrote:
> Source: gnupg-pkcs11-scd
> Version: 7.0-005-1
> Severity: important
> User: ametz...@debian.org
> Usertags: libgcrypt-config-removal
> Control: block 714589 by -1

> gnupg-pkcs11-scd relies on libgcrypt-config to locate libgcrypt.
> libgcrypt-config is scheduled for removal and will be dropped in
> libgcrypt 1.11. Please use pkg-config/pkgconf instead.

> A development snapshot of the yet-unreleased libgcrypt 1.11 is available
> in experimental.

Hello,

the same issue applies to searching for libassuan. Cloning (after fixing
the bug versioning info, sorry).

libassuan has not yet had a beta release without libassuan-config, but you
can simply dpkg-divert it for testing.

cu Andreas

Bug#1071552: Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG

[Andreas Metzler]

On 2024-05-27 Daniel Kahn Gillmor  wrote:
[...]
> Would anyone be willing to try to backport the patches from upstream's
> fixes for T6481 to the 2.2.x series?

Hello Daniel,

the issue report refers to two patches, one of these is already part of
2.2.43. The other one[1] seemed pretty straightforward to backport
(functions moved to other files and cipher_filter_ocb instead of
cipher_filter_aead). I would appreciate a second pair of eyes.

cu Andreas
[1] https://dev.gnupg.org/rG2f872fa68c6576724b9dabee9fb0844266f55d0d
-- 
`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'
>From 2f872fa68c6576724b9dabee9fb0844266f55d0d Mon Sep 17 00:00:00 2001
From: NIIBE Yutaka 
Date: Wed, 24 May 2023 10:36:04 +0900
Subject: [PATCH] gpg: Report BEGIN_* status before examining the input.

* common/miscellaneous.c (is_openpgp_compressed_packet)
(is_file_compressed): Moved to ...
* common/iobuf.c: ... in this file.
(is_file_compressed): Change the argument to INP, the iobuf.
* common/util.h (is_file_compressed): Remove.
* common/iobuf.h (is_file_compressed): Add.
* g10/cipher-aead.c (write_header): Don't call write_status_printf
here.
(cipher_filter_aead): Call write_status_printf when called with
IOBUFCTRL_INIT.
* g10/cipher-cfb.c (write_header): Don't call write_status_printf
here.
(cipher_filter_cfb): Call write_status_printf when called with
IOBUFCTRL_INIT.
* g10/encrypt.c (encrypt_simple): Use new is_file_compressed function,
after call of iobuf_push_filter.
(encrypt_crypt): Likewise.
* g10/sign.c (sign_file): Likewise.

--

GnuPG-bug-id: 6481

--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -2750,5 +2750,125 @@ iobuf_skip_rest (iobuf_t a, unsigned lon
   remaining -= count;
 	}
 	}
 }
 }
+
+
+/* Check whether (BUF,LEN) is valid header for an OpenPGP compressed
+ * packet.  LEN should be at least 6.  */
+static int
+is_openpgp_compressed_packet (const unsigned char *buf, size_t len)
+{
+  int c, ctb, pkttype;
+  int lenbytes;
+
+  ctb = *buf++; len--;
+  if (!(ctb & 0x80))
+return 0; /* Invalid packet.  */
+
+  if ((ctb & 0x40)) /* New style (OpenPGP) CTB.  */
+{
+  pkttype = (ctb & 0x3f);
+  if (!len)
+return 0; /* Expected first length octet missing.  */
+  c = *buf++; len--;
+  if (c < 192)
+;
+  else if (c < 224)
+{
+  if (!len)
+return 0; /* Expected second length octet missing. */
+}
+  else if (c == 255)
+{
+  if (len < 4)
+return 0; /* Expected length octets missing */
+}
+}
+  else /* Old style CTB.  */
+{
+  pkttype = (ctb>>2)&0xf;
+  lenbytes = ((ctb&3)==3)? 0 : (1<<(ctb & 3));
+  if (len < lenbytes)
+return 0; /* Not enough length bytes.  */
+}
+
+  return (pkttype == 8);
+}
+
+
+/*
+ * Check if the file is compressed, by peeking the iobuf.  You need to
+ * pass the iobuf with INP.  Returns true if the buffer seems to be
+ * compressed.
+ */
+int
+is_file_compressed (iobuf_t inp)
+{
+  int i;
+  char buf[32];
+  int buflen;
+
+  struct magic_compress_s
+  {
+byte len;
+byte extchk;
+byte magic[5];
+  } magic[] =
+  {
+   { 3, 0, { 0x42, 0x5a, 0x68, 0x00 } }, /* bzip2 */
+   { 3, 0, { 0x1f, 0x8b, 0x08, 0x00 } }, /* gzip */
+   { 4, 0, { 0x50, 0x4b, 0x03, 0x04 } }, /* (pk)zip */
+   { 5, 0, { '%', 'P', 'D', 'F', '-'} }, /* PDF */
+   { 4, 1, { 0xff, 0xd8, 0xff, 0xe0 } }, /* Maybe JFIF */
+   { 5, 2, { 0x89, 'P','N','G', 0x0d} }  /* Likely PNG */
+  };
+
+  if (!inp)
+return 0;
+
+  for ( ; inp->chain; inp = inp->chain )
+;
+
+  buflen = iobuf_ioctl (inp, IOBUF_IOCTL_PEEK, sizeof buf, buf);
+  if (buflen < 0)
+{
+  buflen = 0;
+  log_debug ("peeking at input failed\n");
+}
+
+  if ( buflen < 6 )
+{
+  return 0;  /* Too short to check - assume uncompressed.  */
+}
+
+  for ( i = 0; i < DIM (magic); i++ )
+{
+  if (!memcmp( buf, magic[i].magic, magic[i].len))
+{
+  switch (magic[i].extchk)
+{
+case 0:
+  return 1; /* Is compressed.  */
+case 1:
+  if (buflen > 11 && !memcmp (buf + 6, "JFIF", 5))
+return 1; /* JFIF: this likely a compressed JPEG.  */
+  break;
+case 2:
+  if (buflen > 8
+  && buf[5] == 0x0a && buf[6] == 0x1a && buf[7] == 0x0a)
+return 1; /* This is a PNG.  */
+  break;
+default:
+  break;
+}
+}
+}
+
+  if (buflen >= 6 && is_openpgp_compressed_packet (buf, buflen))
+{
+  return 1; /* Already compressed.  */
+}
+
+  return 0;  /* Not detected as compressed.  */
+}
--- a/common/iobuf.h
+++ b/common/iobuf.h
@@ -595,10 +595,13 @@ void iobuf_set_partial_body_length_mode
Recall: a filter can return EOF.  In this case, it and all

Bug#1072176: autogen.1: some remarks and editorial changes for this man page

[Andreas Metzler]

On 2024-05-29 Bjarni Ingi Gislason  wrote:
> Package: autogen
> Version: 1:5.18.16-5+b1
> Severity: minor
> Tags: patch

> [Copy is sent to autogen-us...@lists.sourceforge.net]

> Dear Maintainer,

>* What led up to the situation?

>   Checking for defects with

> [test-]groff -mandoc -t -K utf8 -ww -b -z 

>   [test-groff is a script in the repository for "groff"]

>* What was the outcome of this action?

> troff: backtrace: file '':30
> troff::30: warning: register 'Pp' not defined
> troff: backtrace: file '':319
> troff::319: warning: macro 'Ss' not defined

>* What outcome did you expect instead?

>   No output (warnings).

> -.-

>   Where are these undefined variables ment to be defined?

>   Where are these variables documented?

>   Notes and a patch are in the attachments.
[...]

Hello Bjarni,

autogen.1 is an autogenerated file there is litle use in trying to patch
it. Since autogen itself (which generates the manpage) is also EOL this
is very unlikely to be touched.

cu Andreas
-- 
`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#911189: gpgme-json packaging

[Andreas Metzler]

On 2024-05-17 Detlef Eppers  wrote:
[...]
> So I'm throwing my hat in the ring for gpgme-json :)
[...]

Given that iirc Ubuntu has gone with gpgme-json we will probably go this
avenue, when we package it.

cu Andreas
-- 
`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#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-29 Marco d'Itri  wrote:
> On May 28, Andreas Metzler  wrote:

>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, and imho this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.

> I strongly disagree: it is a bad choice to change on upgrades a default 
> which may cause data loss.

Hello,

That is false dichotomy. data-loss will occur when people use /tmp or
/var/tmp for persistent data-storage because "This has (for a couple of
years) worked on Debian systems" not because "This has (for a couple of
years) worked on *this* *specific* Debian system.".

cu Andreas

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-28 Luca Boccassi  
wrote:
[...]
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
[...]

Hello,

I think it is bad choice to deliberately have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.

cu Andreas
-- 
`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#1071552: Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG

[Andreas Metzler]

Control: severity -1 serious

On 2024-05-27 Daniel Kahn Gillmor  wrote:
> Control: affects 1071552 + emacs-el
> Control: retitle 1071552 GnuPG 2.2.42+ breaks emacs' EasyPG

> On Tue 2024-05-21 13:05:02 +0900, Youhei SASAKI wrote:
> > Package: gnupg
> > Version: 2.2.43-6
> > Severity: critical

> I see that Andreas has reduced the severity of 1071552 from 'critical'
> to 'important'.  I think that the bugs we're seeing with easypg are
> pretty severe.  I would personally mark this bug report "serious",
> because i think it is unfit to be merged into testing until the package
> can work correctly with EasyPG.
[...]

Hello,

I had second thoughts about how far to downgrade, too

but "critical" was evidently not correct. Let's go with "in the package
maintainer's [...] opinion". ;-)

cu Andreas
-- 
`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#1071962: wput: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: wput
Version: 0.6.2+git20130413-12
Severity: normal
Tags: patch

wput build-depends on libgcrypt20-dev but afaict does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/wput-0.6.2+git20130413$ grep -rli gcryp
debian/changelog
debian/control
debian/patches/13-configure.in--gcrypt-link.patch
debian/patches/series
debian/autoreconf.before
debian/autoreconf.after
.pc/applied-patches
.pc/13-configure.in--gcrypt-link.patch/configure.in
configure~

cu Andreas

Bug#1071960: weechat: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: weechat
Version: 4.1.1-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

weechat uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071958: tpm2-initramfs-tool: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: tpm2-initramfs-tool
Version: 0.2.2-2.1
Severity: normal
Tags: patch

tpm2-initramfs-tool build-depends on libgcrypt20-dev but afaict does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/tpm2-initramfs-tool-0.2.2$ grep -rli gcryp
debian/control

cu Andreas

Bug#1071956: stress-ng: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: stress-ng
Version: 0.17.08-1
Severity: normal
Tags: patch

stress-ng build-depends on libgcrypt20-dev but afaict does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/stress-ng-0.17.08$ grep -rli gcry
.travis.yml
Dockerfile
stress-crypt.c
README.md
debian/changelog
debian/control
debian/.debhelper/generated/stress-ng/dh_installchangelogs.dch.trimmed

and the only match for gcrypt in stress-crypt.c is:
#else
stressor_info_t stress_crypt_info = {
.stressor = stress_unimplemented,
.class = CLASS_CPU | CLASS_COMPUTE,
.opt_set_funcs = opt_set_funcs,
.verify = VERIFY_ALWAYS,
.help = help,
.unimplemented_reason = "built without gcrypt library"
};
#endif


which is the else to
#if defined(HAVE_LIB_CRYPT) &&  \
(defined(HAVE_CRYPT_H) ||   \
 defined(__FreeBSD__))

i.e. a typo, should read crypt.
cu Andreas

Bug#1071955: shishi: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: shishi
Version: 1.0.3-4
Severity: important
Tags: ftbfs patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

shishi FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
Since it ships an outdated version of AM_PATH_LIBGCRYPT() in
lib/gl/m4/libgcrypt.m4 that cannot handle this dh_autoreconf does not
solve this automatically.

Simply removing lib/gl/m4/libgcrypt.m4 lets the build succeed.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071954: sngrep: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: sngrep
Version: 1.8.1-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

sngrep uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071953: qtkeychain: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: qtkeychain
Version: 0.14.3-1
Severity: normal
Tags: patch

qtkeychain build-depends on libgcrypt20-dev but afaict does not use
libgcrypt.

cu Andreas

Bug#1071952: purple-lurch: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: purple-lurch
Version: 0.7.0-2
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

purple-lurch uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071951: poldi: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: poldi
Version: 0.4.2+git20161115.553060d-1.3
Severity: important
Tags: ftbfs patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

poldi FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
Since it ships an outdated version of AM_PATH_LIBGCRYPT() in
m4/libgcrypt.m4 that cannot handle this dh_autoreconf does not
solve this automatically.

Simply removing m4/libgcrypt.m4 lets the build succeed.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071950: openvas-scanner: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: openvas-scanner
Version: 23.0.1-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

openvas-scanner uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071946: openconnect: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: openconnect
Version: 9.12-1
Severity: normal
Tags: patch

openconnect build-depends on libgcrypt20-dev but afaict does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/openconnect-9.12$ grep -rli gcryp
android/fetch.sh
debian/changelog
debian/control

cu Andreas

Bug#1071945: netatalk: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: netatalk
Version: 3.1.18~ds-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

netatalk uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071944: mpd: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: mpd
Version: 0.23.14-2
Severity: normal
Tags: patch

mpd build-depends on libgcrypt20-dev but afaict does not use
libgcrypt. The only notion I can find about it is related to
mpd-0.23.14/src/lib/gcrypt/meson.build

if libavutil_dep.found()
  # if we have FFmpeg, we can use its MD5 implementation and we don't
  # need libgcrypt
  gcrypt_dep = dependency('', required: false)
  subdir_done()
endif
[...]

The Debian packages b-ds on libavformat-dev.

cu Andreas

Bug#1071941: monkeysphere: FTBFS against libgcrypt 1.11 (and next libassuan)

[Andreas Metzler]

Source: monkeysphere
Version: 0.43-3.1
Severity: important
Tags: ftbfs patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,
monkeysphere FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
(It will also fail when libassuan drops its config script.) Please use
pkgconf instead. Patch attached.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas
diff -Nru monkeysphere-0.43/debian/changelog monkeysphere-0.43/debian/changelog
--- monkeysphere-0.43/debian/changelog	2021-01-02 18:04:05.0 +0100
+++ monkeysphere-0.43/debian/changelog	2024-05-26 11:35:22.0 +0200
@@ -1,3 +1,12 @@
+monkeysphere (0.43-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS against libgcrypt 1.11 (and next libassuan), add patch to use
+pkgconf instead of libassuan-config/libgcrypt-config, and also search for
+gpg-error and add b-d on pkgconf.
+
+ -- Andreas Metzler   Sun, 26 May 2024 11:35:22 +0200
+
 monkeysphere (0.43-3.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru monkeysphere-0.43/debian/control monkeysphere-0.43/debian/control
--- monkeysphere-0.43/debian/control	2019-05-10 22:55:04.0 +0200
+++ monkeysphere-0.43/debian/control	2024-05-26 11:35:22.0 +0200
@@ -16,10 +16,12 @@
  libassuan-dev,
  libcrypt-openssl-rsa-perl ,
  libdigest-sha-perl ,
+ libgpg-error-dev,
  libgcrypt20-dev,
  lockfile-progs | procmail ,
  openssh-server ,
  openssl ,
+ pkgconf,
  socat ,
 Standards-Version: 4.3.0
 Homepage: https://web.monkeysphere.info/
diff -Nru monkeysphere-0.43/debian/patches/series monkeysphere-0.43/debian/patches/series
--- monkeysphere-0.43/debian/patches/series	2019-05-10 22:55:04.0 +0200
+++ monkeysphere-0.43/debian/patches/series	2024-05-26 11:35:22.0 +0200
@@ -4,3 +4,4 @@
 0004-tests-basic-ensure-functionality-with-output-of-stan.patch
 0005-Use-gpg-s-reworked-quick-interface-for-adding-revoki.patch
 0006-mh-import-key-use-ssh-add-and-gpg-agent-for-import-C.patch
+use-pkg-config-instead-of-foo.-config.diff
diff -Nru monkeysphere-0.43/debian/patches/use-pkg-config-instead-of-foo.-config.diff monkeysphere-0.43/debian/patches/use-pkg-config-instead-of-foo.-config.diff
--- monkeysphere-0.43/debian/patches/use-pkg-config-instead-of-foo.-config.diff	1970-01-01 01:00:00.0 +0100
+++ monkeysphere-0.43/debian/patches/use-pkg-config-instead-of-foo.-config.diff	2024-05-26 11:35:22.0 +0200
@@ -0,0 +1,26 @@
+Description: Fix FTBFS against libgcrypt 1.11 (and next libassuan)
+ Use pkgconf instead of libassuan-config/libgcrypt-config.
+ Also explicitely link against libgpg-error since we use gpg_strerror()
+Author: Andreas Metzler 
+Last-Update: 2024-05-26
+
+--- a/Makefile
 b/Makefile
+@@ -13,15 +13,13 @@ ETCPREFIX ?=
+ ETCSUFFIX ?= 
+ PREFIX ?= /usr
+ MANPREFIX ?= $(PREFIX)/share/man
+ LOCALSTATEDIR ?= /var/lib
+ 
+-CFLAGS += $(shell libassuan-config --cflags)
+-CFLAGS += $(shell libgcrypt-config --cflags)
++CFLAGS += $(shell pkg-config --cflags gpg-error libassuan libgcrypt)
+ CFLAGS += --pedantic -Wall -Werror -std=c99
+-LIBS += $(shell libassuan-config --libs)
+-LIBS += $(shell libgcrypt-config --libs)
++LIBS += $(shell pkg-config --libs gpg-error libassuan libgcrypt)
+ 
+ REPLACEMENTS = src/monkeysphere src/monkeysphere-host		\
+ src/monkeysphere-authentication src/share/defaultenv $(wildcard	\
+ src/transitions/*)
+ 

Bug#1071942: mcabber: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: mcabber
Version: 1.1.2-2
Severity: normal
Tags: patch

mcabber build-depends on libgcrypt20-dev (and mcabber-dev depends
on it) but afaict does not use libgcrypt.

cu Andreas

Bug#1071938: mate-power-manager: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: mate-power-manager
Version: 1.26.1-1
Severity: normal
Tags: patch

mate-power-manager build-depends on libgcrypt20-dev but does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/mate-power-manager-1.26.1$ grep -r gcrypt
.build.yml:- libgcrypt20-dev
.build.yml:- libgcrypt20-dev
debian/control:   libgcrypt20-dev,

cu Andreas

Bug#1071937: libxslt: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: libxslt
Version: 1.1.35-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

libxslt uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071935: libprelude: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: libprelude
Version: 5.2.0-5.5
Severity: normal
Tags: patch

libprelude build-depends on libgcrypt20-dev (and libprelude-dev depends
on it) but does not use libgcrypt.

sid)ametzler@argenau:/dev/shm/GCRY/libprelude-5.2.0$ grep -rl gcrypt
NEWS
ChangeLog
debian/changelog
debian/control
debian/libprelude-dev/DEBIAN/control

Quote from NEWS: 
- Get rid of libgcrypt

Nowadays, libgcrypt functions that we used are now available
directly from GnuTLS, which uses libnettle.

cu Andreas

Bug#1071934: libpam-ccreds: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: libpam-ccreds
Version: 10-8
Severity: important
Tags: ftbfs patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

libpam-ccreds FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
Since it ships an outdated version of AM_PATH_LIBGCRYPT() in
acinclude.m4 that cannot handle this autoreconf does not help.

Simply removing acinclude.m4 lets the build succeed.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071933: libccrtp: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: libccrtp
Version: 2.0.9-4
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

libccrtp FTBFS against libgcrypt 1.11 which drops libgcrypt-config.  It
ships an outdated customized version of AM_PATH_LIBGCRYPT() called
AM_PATH_LIBGCRYPT_CCRTP in m4/libgcrypt_local.m4 that cannot handle the
removal of libgcrypt-config.

Replacing AM_PATH_LIBGCRYPT_CCRTP with upstream's AM_PATH_LIBGCRYPT
would probably help but I would suggest to simply use pkg-config/pkgconf
instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071932: libbdplus: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: libbdplus
Version: 0.2.0-3
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

libbdplus uses libgcrypt-config to locate libgcrypt. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config anymore.
Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071931: libaacs: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: libaacs
Version: 0.5.0-2
Severity: important
Tags: ftbfs patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

libaacs FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
Since it ships an outdated version of AM_PATH_LIBGCRYPT() in
m4/libgcrypt.m4 that cannot handle this autoreconf does not help.

Simply removing this copy (m4/libgcrypt.m4) lets the build succeed.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071930: kwallet-pam: Searches for libgcrypt with libgcrypt-config

[Andreas Metzler]

Source: kwallet-pam
Version: 5.27.11-1
Severity: important
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

kwallet-pam relies on libgcrypt-config to locate libgcrypt. libgcrypt-config
is scheduled for removal and will be dropped in libgcrypt 1.11. On
rebuild kwallet-pam does not FTBFS but loses support for the features
that require gcrypt.

Please simply use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071929: kwallet-kf5: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: kwallet-kf5
Version: 5.115.0-3~exp1
Severity: normal

Hello,
afaict kwallet-kf5 does not use its build-dependency on libgcrypt20-dev
anymore, it seems to be only used for kwalletd:
ametzler@argenau:/dev/shm/GCRY/kwallet-kf5-5.115.0$ grep -rli gcryp
cmake/FindLibGcrypt.cmake
src/runtime/kwalletd/backend/kwalletbackend.cc
src/runtime/kwalletd/backend/CMakeLists.txt
debian/control
debian/copyright
debian/libkf5wallet-data/usr/share/doc/libkf5wallet-data/copyright
debian/libkf5wallet-dev/usr/share/doc/libkf5wallet-dev/copyright
debian/libkf5wallet-doc/usr/share/doc/libkf5wallet-doc/copyright
debian/libkf5wallet5/usr/share/doc/libkf5wallet5/copyright
debian/libkf5wallet-bin/usr/share/doc/libkf5wallet-bin/copyright

cu Andreas

Bug#1071869: iputils: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: iputils
Version: 3:20240117-1
Severity: normal
Tags: patch

iputils build-depends on libgcrypt20-dev but does not use libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/iputils-20240117$ grep -rli gcrypt
Documentation/RELNOTES.old
debian/control

cu Andreas

Bug#1071867: gogglesmm: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: gogglesmm
Version: 1.2.5-4
Severity: normal
Tags: patch

Hello,
afaict gogglesmm does not use its build-dependency on libgcrypt20-dev.

cu Andreas

Bug#1071866: goldencheetah: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: goldencheetah
Version: 0.2.0-3
Severity: normal
Tags: patch

goldencheetah build-depends on libgcrypt20-dev but does not use
libgcrypt.

(sid)ametzler@argenau:/dev/shm/GCRY/goldencheetah-3.5$ grep -rli gcrypt
debian/control

cu Andreas

Bug#1071864: gnupg-pkcs11-scd: Searches for libgcrypt with libgcrypt-config

[Andreas Metzler]

Source: gnupg-pkcs11-scd
Version: 7.0-005-1
Severity: important
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

gnupg-pkcs11-scd relies on libgcrypt-config to locate libgcrypt.
libgcrypt-config is scheduled for removal and will be dropped in
libgcrypt 1.11. Please use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas


signature.asc
Description: PGP signature

Bug#1071862: gfsecret: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: gfsecret
Version: 0.5.0-2
Severity: important
Tags: ftbfs patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

gfsecret FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
Since it ships an outdated version of AM_PATH_LIBGCRYPT() in
m4/libgcrypt.m4 that cannot handle this autoreconf does not help.

Removing this m4/libgcrypt.m copy the build succeed.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071860: fis-gtm: Searches for libgcrypt with libgcrypt-config

[Andreas Metzler]

Source: fis-gtm
Version: 7.0-005-1
Severity: important
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

fis-gtm relies on libgcrypt-config to locate libgcrypt. libgcrypt-config
is scheduled for removal and will be dropped in libgcrypt 1.11. Please
use pkg-config/pkgconf instead.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071859: filetea: unused (build-)dependency on libgcrypt20-dev

[Andreas Metzler]

Source: filetea
Version: 0.1.18-2
Severity: normal
Tags: patch

filetea build-depends on libgcrypt20-dev and actualy has -lgcrypt in
Makefile*, however it does not use any gcrypt functions.

cu Andreas

Bug#1071858: event-dance: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: event-dance
Version: 0.2.0-3
Severity: normal
Tags: patch

cadaver build-depends on libgcrypt20-dev but does not use libgcrypt.

cu Andreas

Bug#1071838: clamz: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: clamz
Version: 0.5-2.1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

clamz uses AM_PATH_LIBGCRYPT but does not use dh_autoreconf. This breaks
against libgcrypt 1.11 which does not ship libgcrypt-config (used by the
old included version of AM_PATH_LIBGCRYPT) anymore.

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071837: chntpw: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

[Andreas Metzler]

Source: chntpw
Version: 140201-1
Severity: important
Tags: patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

cu Andreas
--- chntpw-140201.orig/Makefile
+++ chntpw-140201/Makefile
@@ -6,10 +6,10 @@
 CC=gcc
 
 # Force 32 bit
-CFLAGS= -DUSELIBGCRYPT -I. $(shell libgcrypt-config --cflags) -Wall -m32
+CFLAGS= -DUSELIBGCRYPT -I. $(shell pkg-config --cflags libgcrypt) -Wall -m32
 OSSLLIB=$(OSSLPATH)/lib
 
-LIBS=$(shell libgcrypt-config --libs)
+LIBS=$(shell pkg-config --libs libgcrypt)
 
 
 all: chntpw cpnt reged samusrgrp sampasswd samunlock

Bug#1071836: cadaver: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: cadaver
Version: 0.24+dfsg-3
Severity: normal
Tags: patch

cadaver build-depends on libgcrypt20-dev but does not use libgcrypt.

cu Andreas

Bug#1071835: libxml2-dev: pkgconfig libxml-2.0.pc has Requires.private: liblzma without (even indirect) dependeny on liblzma-dev

[Andreas Metzler]

Package: libxml2-dev
Version: 2.12.7+dfsg-1
Severity: important
Affects: booth

this breaks pkgconf:

(sid)ametzler@argenau:/dev/shm/GCRY/booth-1.1$ pkg-config --exists 
--print-errors "libxml-2.0" ; echo $?
Package liblzma was not found in the pkg-config search path.
Perhaps you should add the directory containing `liblzma.pc'
to the PKG_CONFIG_PATH environment variable
Package 'liblzma', required by 'libxml-2.0', not found
1

cu Andreas

Bug#1071833: aria2: unused build-dependency on libgcrypt20-dev

[Andreas Metzler]

Source: aria2
Version: 1.37.0+debian-1
Severity: normal

aria2 build-depends on libgcrypt20-dev but does not use libgcrypt.

cu Andreasa


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

Kernel: Linux 6.7.12-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
-- 
`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#1071832: aircrack-ng: FTBFS against libgcrypt 1.11

[Andreas Metzler]

Source: aircrack-ng
Version: 1.7+git20230807.4bf83f1a-1
Severity: important
Tags: ftbfs
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

aircrack-ng FTBFS against libgcrypt 1.11 which drops libgcrypt-config.
Since it ships an outdated copy of libgcrypt.m4 in
./build/m4/libgcrypt.m4 that cannoz handle this autoreconf does not
help.

Removing this copy lets the build continue but it later fails with:
libtool: link: gcc -DUSE_GCRYPT -DEXPENSIVE_TESTS -Wall -O3 -std=gnu99 -fcommon 
-Wstrict-overflow=2 -fvisibility=hidden -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/dev/shm/GCRY/aircrack-ng-1.7+git20230807.4bf83f1a=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -rdynamic -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -o .libs/test-calc-one-pmk test/unit/calc_one_pmk-test-calc-one-pmk.o  
-L/usr/lib/x86_64-linux-gnu ./.libs/libaccrypto.a ./.libs/libaircrack-ce-wpa.so 
./.libs/libaircrack.a -lpthread -lz 
/dev/shm/GCRY/aircrack-ng-1.7+git20230807.4bf83f1a/.libs/libaircrack-osdep.so 
-lnl-3 -lnl-genl-3 -lpcre2-8 -lgcrypt -lhwloc -lcmocka -ldl -lm -pthread
/usr/bin/ld: ./.libs/libaircrack-ce-wpa.so: undefined reference to 
`Digest_SHA256_Destroy'
/usr/bin/ld: ./.libs/libaircrack-ce-wpa.so: undefined reference to 
`Digest_SHA256_Create'
/usr/bin/ld: ./.libs/libaircrack-ce-wpa.so: undefined reference to 
`Digest_SHA256_Update'
/usr/bin/ld: ./.libs/libaircrack-ce-wpa.so: undefined reference to 
`Digest_SHA256_Init'
/usr/bin/ld: ./.libs/libaircrack-ce-wpa.so: undefined reference to 
`Digest_SHA256_Finish'
collect2: error: ld returned 1 exit status

A development snapshot of the yet-unreleased libgcrypt 1.11 is available
in experimental.

cu Andreas

Bug#1071368: [gpgv] cmd-arg parse error with apt/aptitude update

[Andreas Metzler]

Control: reasign -1 apt 2.9.3
Control: affects -1 gpgv-from-sq

On 2024-05-18 Lyndon Brown  wrote:
> On Sat, 2024-05-18 at 16:24 +0200, Andreas Metzler wrote:
>> On 2024-05-17 Lyndon Brown  wrote:
>>> Package: gpgv
>>> Version: 2.2.43-4
>>> Severity: important

>>> Since sometime last night I'm seeing an error as below when using
>>> `apt-
>>> get update` or `aptitude update`. I'm guessing wrt. the earliest
>>> affected version. I've no idea how important an issue this may be,
>>> so
>>> cautiously marking important.
>> [...]
>>> $ sudo aptitude update
>>> Hit https://deb.debian.org/debian sid InRelease
>>> Hit https://deb.debian.org/debian rc-buggy InRelease
>>> W: https://deb.debian.org/debian/dists/sid/InRelease: Unknown
>>> response from gpgv to --assert-pubkey-algo check: gpgv:   error:
>>> Error parsing command-line arguments
>> [...]

>> afaict that happens in apt-key, what does

>> env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo

>> output on your system?

> $ env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo
> gpgv:   error: Error parsing command-line arguments
> gpgv: because: Unknown argument "assert-pubkey-algo"

Good morning,

that two-line output is generated by gpgv-from-sq which diverts gpgv. I
think this should fix it:
diff -NurBbp apt-2.9.3/cmdline/apt-key.in newapt-2.9.3/cmdline/apt-key.in
--- apt-2.9.3/cmdline/apt-key.in2024-05-14 13:01:31.0 +0200
+++ newapt-2.9.3/cmdline/apt-key.in 2024-05-19 08:10:25.017202993 +0200
@@ -819,6 +819,9 @@ case "$command" in
;;
*[Ii]"nvalid option"*"assert-pubkey-algo"*)
;;
+   *"Error parsing command-line arguments"*)
+   # gpgv-from-sq
+   ;;
*)
apt_warn "Unknown response from gpgv to 
--assert-pubkey-algo check: $test"
;;
cu Andreas
-- 
`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#1071368: [gpgv] cmd-arg parse error with apt/aptitude update

[Andreas Metzler]

On 2024-05-18 Lyndon Brown  wrote:
> On Sat, 2024-05-18 at 16:24 +0200, Andreas Metzler wrote:
> > On 2024-05-17 Lyndon Brown  wrote:
> > > Package: gpgv
> > > Version: 2.2.43-4
> > > Severity: important
[...]
> > afaict that happens in apt-key, what does
> > 
> > env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo
> > 
> > output on your system?

> $ env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo
> gpgv:   error: Error parsing command-line arguments
> gpgv: because: Unknown argument "assert-pubkey-algo"

Good morning

Thanks for the quick reply. You have installed gpgv-from-sq which
diverts "our" gpgv. (I will check a little bit more and reassign to
apt.)

Could you perhaps use reportbug to send bug-reports - in future it
automatically includes info like this? - Thanks!

cu Andreas
-- 
`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#1071393: graphicsmagick-imagemagick-compat: svg to png conversion fails with Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb)

[Andreas Metzler]

Package: graphicsmagick-imagemagick-compat
Version: 1.4+really1.3.43-1
Severity: normal

For unknown reasons salsa CI installed graphicsmagick-imagemagick-compat
instead of imagemagick and I wound up with a build error.

(sid)ametzler@argenau:/tmp/GNUPG2/gnupg2-2.4.5$ convert doc/gnupg-module-overvie
w.svg gnupg-module-overview.png
convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).

cu Andreas


gnupg-module-overview.svg.gz
Description: application/gzip

Bug#1071368: [gpgv] cmd-arg parse error with apt/aptitude update

[Andreas Metzler]

On 2024-05-17 Lyndon Brown  wrote:
> Package: gpgv
> Version: 2.2.43-4
> Severity: important

> Since sometime last night I'm seeing an error as below when using `apt-
> get update` or `aptitude update`. I'm guessing wrt. the earliest
> affected version. I've no idea how important an issue this may be, so
> cautiously marking important.
[...]
> $ sudo aptitude update
> Hit https://deb.debian.org/debian sid InRelease
> Hit https://deb.debian.org/debian rc-buggy InRelease
> W: https://deb.debian.org/debian/dists/sid/InRelease: Unknown response from 
> gpgv to --assert-pubkey-algo check: gpgv:   error: Error parsing command-line 
> arguments
[...]

Hello,

afaict that happens in apt-key, what does

env LC_ALL=C.UTF-8 gpgv --assert-pubkey-algo

output on your system?

cu Andreas
-- 
`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#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-05-18 Elliott Mitchell  wrote:
> On Sat, May 18, 2024 at 08:16:25AM +0200, Andreas Metzler wrote:
[...]

>> You seem to argue that it is major problem for a gnutls client to *send*
>> e.g. "127.0.0.1" as SNI. My point is that this is not a problem but at
>> most uncomely since client-side certificate verification will fail.
>> Even for a trusted certificate name checking is done (if gnutls is
>> correctly used). And this will not succeed if the CN or SAN is an IP
>> address. (I have tried with test certificates and gnutls-cli/-serv. My
>> testing might be flawed of course.)

> This is purely hypothetical since this case isn't being observed.

> What #1070033 is about is, a program was configured to directly connect
> to a server via IPv6.  This address was provided to libgnutls.  libgnutls
> sent the provided address to the server as SNI without verifying it was
> valid for SNI.

> The usual approach is be conservative in what you send, but liberal in
> what you accept.  This means libgnutls needs to check whether what is
> provided is acceptable before sending it, but the server side could
> allow an IP address which violates RFC 6066.

> `gnutls-cli` is a very poor simulcrum for this case.  `gnutls-cli` does
> lots of checking which specialized clients may skip.  `gnutls-cli` also
> assumes name service is fully available.  Whereas `nslcd` cannot rely on
> name service being operational as it may provide name service.

Hello,

Let's assume
a) _gnutls_server_name_send_params() was changed to reject
   e.g. "127.0.0.1"[1] and
b) this stopped libgnutls from sending "127.0.0.1" to the server as SNI.

How would this help you, or how is this related to this bug report? In
this bug report perhaps an IPv6 address was used which is already
rejected by _gnutls_server_name_send_params().

cu Andreas

-- 
`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#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-05-18 Elliott Mitchell  wrote:
> On Sat, May 18, 2024 at 07:40:13AM +0200, Andreas Metzler wrote:
>> On 2024-05-18 Elliott Mitchell  wrote:
>>> On Sat, May 18, 2024 at 06:55:06AM +0200, Andreas Metzler wrote:
[...]
>>>> Afaict it is a short-cut to save more expensive processing for obvious
>>>> errors. gnutls_session_get_verify_cert_status() (with
>>>> gnutls_session_set_verify_cert() set correctly) or
>>>> gnutls_x509_crt_check_hostname()/gnutls_certificate_verify_peers3()
>>>> does more elaborate stuff on the data,
>>>> gnutls_certificate_verify_peers2() requires a separate
>>>> gnutls_x509_crt_check_hostname().

>>> Which seems to argue the more urgent issue is
>>> _gnutls_server_name_send_params() needs to do checking of the provided
>>> server hostname before sending it as SNI.

>> Why is this urgent or even relevant? Certificate checking (client-side)
>> will not accept IP adresses as SNI field.

> Not relevant.  If the certificate comes from a local file, it is assumed
> trusted.  If the certificate comes from the server, then it is only
> available *after* connection and the SNI has already been sent.
[...]

Hello,


You seem to argue that it is major problem for a gnutls client to *send*
e.g. "127.0.0.1" as SNI. My point is that this is not a problem but at
most uncomely since client-side certificate verification will fail.
Even for a trusted certificate name checking is done (if gnutls is
correctly used). And this will not succeed if the CN or SAN is an IP
address. (I have tried with test certificates and gnutls-cli/-serv. My
testing might be flawed of course.)

cu Andreas

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-05-18 Elliott Mitchell  wrote:
> On Sat, May 18, 2024 at 06:55:06AM +0200, Andreas Metzler wrote:
[...]
> > > > I notice the `_gnutls_dnsname_is_valid()` function in
> > > > gnutls28-3.8.5/lib/str.h accepts IPv4 addresses (which are NOT valid in
> > > > DNS), but rejects IPv6 addresses.

> > At a very bare level an IPv4 address is a valid DNS name (alnum, dashes,
> > and dots), an IPv6 adress is not. That is what gnutls is checking here.

> No, there isn't any IPv4 address which is a valid DNS name.  No top-level
> domain consists purely of decimal digits, whereas IPv4 addresses consist
> of purely decimal digits.  In fact I don't believe there are any
> top-level domains which have even a single decimal digit in them.

Hello,

which is totally irrelevant if my reading (quoted below) that this is
not a policy check but a performance optimization is correct.

> > Afaict it is a short-cut to save more expensive processing for obvious
> > errors. gnutls_session_get_verify_cert_status() (with
> > gnutls_session_set_verify_cert() set correctly) or
> > gnutls_x509_crt_check_hostname()/gnutls_certificate_verify_peers3()
> > does more elaborate stuff on the data,
> > gnutls_certificate_verify_peers2() requires a separate
> > gnutls_x509_crt_check_hostname().

> Which seems to argue the more urgent issue is
> _gnutls_server_name_send_params() needs to do checking of the provided
> server hostname before sending it as SNI.

Why is this urgent or even relevant? Certificate checking (client-side)
will not accept IP adresses as SNI field.

cu Andreas
-- 
`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#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-05-17 Elliott Mitchell  wrote:
> On Thu, May 16, 2024 at 07:06:49PM -0700, Elliott Mitchell wrote:
> > On Tue, May 14, 2024 at 06:22:09PM +0200, Andreas Metzler wrote:
[...]
> > > Could you please post the requested output, although there are no
> > > obvious clues there to your eyes?
> > 
> > Problem is that provides rather a lot of data about this network setup.
> > The quantity of information is enough for me to be rather uncomfortable
> > with providing it via public channel.
[...]

> > I notice the `_gnutls_dnsname_is_valid()` function in
> > gnutls28-3.8.5/lib/str.h accepts IPv4 addresses (which are NOT valid in
> > DNS), but rejects IPv6 addresses.

Hello,

At a very bare level an IPv4 address is a valid DNS name (alnum, dashes,
and dots), an IPv6 adress is not. That is what gnutls is checking here.
Afaict it is a short-cut to save more expensive processing for obvious
errors. gnutls_session_get_verify_cert_status() (with
gnutls_session_set_verify_cert() set correctly) or
gnutls_x509_crt_check_hostname()/gnutls_certificate_verify_peers3()
does more elaborate stuff on the data,
gnutls_certificate_verify_peers2() requires a separate
gnutls_x509_crt_check_hostname().

cu Andreas

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-05-14 Elliott Mitchell  wrote:
> On Wed, May 01, 2024 at 01:45:00PM +0200, Andreas Metzler wrote:
[...]
>> well you could post the complete output of
>> gnutls-cli --port 636 fd12:3456:7890:abcd::3
>> perhaps even with -d10? I would reassign to openldap then if there are
>> no obvious clues.

> `gnutls-cli` doesn't yield anything obvious.
[...]

Hello,

Could you please post the requested output, although there are no
obvious clues there to your eyes?

TIA, cu Andreas

Bug#1070879: please make mail-transfer-agent optional

[Andreas Metzler]

Control: reassign -1 gnupg 2.4.4-1
Control: tags -1 pending

On 2024-05-11 Michael Tokarev  wrote:
> 11.05.2024 09:14, Michael Tokarev wrote:
> ..
> > Please note the function gnupg uses email for is very rarely used, -
> > it's been many years when gpg-wks-server has been built without even
> > specifying path to sendmail binary, it's been fixed only in #1025782
> > in 2024.

> Okay, it looks like I was wrong.  gpg-wks-server is the one which actually
> uses email (for confirmation)...

> > Even better if gpg-wks-server itself becomes "more optional", - right
> > now it is installed on all my (at least desktop) systems.  But this
> > is a different matter it seems (looks more like bugs in other packages
> > who blindly depend on whole gnupg instead of certain components they
> > actually use).

> but it is the other packages which wrongly require whole gnupg, including
> gpg-wks-server, while actually using only main part of it.  I just filed
> #1070882 against devscripts - which seems to be the main reason all my
> desktop systems has gpg-wks-server which is not used by anything.  Also
> #1070880 against dput-ng.

Hello Micheal,

Thank you for submitting these bugs.

FWIW I have downgraded the metapackage gnupg2's dependency on
gpg-wks-server to a suggests in GIT. (Which IIRC mirrors Ubuntu's
choice.)

cu Andreas

-- 
`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'


signature.asc
Description: PGP signature

Bug#714589:

[Andreas Metzler]

On 2024-05-10 Andreas Metzler  wrote:
[...]
> However that was quite painful. codesearch.debian.net lists 78 packages
> matching libgcrypt-config. I suspect the majority will be using the
> macros from libgcrypt.m4 and therefore already use gpgrt-config but
> I also suspect that about a quarter of these either do not or do not or
> do not use/autoupdate the current libgcrypt.m4

Hello,

I have taken a peek, but will stop for now. The new version of
AM_PATH_LIBGCRYPT() does not work without libgcrypt-config unless
AM_PATH_GPG_ERROR() is used before. There are many rdeps that do not use
libgpg-error. I have asked upstream on how to move on from here.

https://dev.gnupg.org/T7114

cu Andreas

-- 
`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#1070905: collectd: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

[Andreas Metzler]

Source: collectd
Version: 5.12.0-18
Severity: normal
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

(Please do not switch from collectd's handwritten detection code to
AM_PATH_LIBGCRYPT() unless you invoke AM_PATH_GPG_ERROR() first. The
former rcurrently requires the latter to work without libgcrypt-config.
Just go for pkg-config instead.)

cu Andreas


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

Kernel: Linux 6.7.12-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
-- 
`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#1070904: bitlbee: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

[Andreas Metzler]

Package: bitlbee
Version: 3.6-1.4
Severity: normal
Tags: patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

cu Andreas
-- 
`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'
diff -Nru bitlbee-3.6/debian/changelog bitlbee-3.6/debian/changelog
--- bitlbee-3.6/debian/changelog	2024-03-23 22:05:25.0 +0100
+++ bitlbee-3.6/debian/changelog	2024-05-11 13:42:43.0 +0200
@@ -1,3 +1,11 @@
+bitlbee (3.6-1.5) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use pkgconf to locate libgcrypt, libgcrypt-config is scheduled for
+removal.
+
+ -- Andreas Metzler   Sat, 11 May 2024 13:42:43 +0200
+
 bitlbee (3.6-1.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff
--- bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff	1970-01-01 01:00:00.0 +0100
+++ bitlbee-3.6/debian/patches/bitlbee_locate_gcrypt_with_pkg-config.diff	2024-05-11 13:42:43.0 +0200
@@ -0,0 +1,38 @@
+Description: Use pkgconf to locate libgcrypt.
+ libgcrypt-config is scheduled for removal.
+Author: Andreas Metzler 
+Last-Update: 2024-05-11
+
+--- bitlbee-3.6.orig/configure
 bitlbee-3.6/configure
+@@ -402,8 +402,8 @@ detect_gnutls()
+ {
+ 	if $PKG_CONFIG --exists gnutls; then
+ 		cat <>Makefile.settings
+-EFLAGS+=$($PKG_CONFIG --libs gnutls) $(libgcrypt-config --libs)
+-CFLAGS+=$($PKG_CONFIG --cflags gnutls) $(libgcrypt-config --cflags)
++EFLAGS+=$($PKG_CONFIG --libs gnutls) $($PKG_CONFIG --libs libgcrypt)
++CFLAGS+=$($PKG_CONFIG --cflags gnutls) $($PKG_CONFIG --cflags libgcrypt)
+ EOF
+ 		ssl=gnutls
+ 		if ! $PKG_CONFIG gnutls --atleast-version=2.8; then
+@@ -762,15 +762,15 @@ fi
+ if [ "$otr" = 1 ]; then
+ 	# BI == built-in
+ 	echo '#define OTR_BI' >> config.h
+-	echo "EFLAGS+=$($PKG_CONFIG --libs libotr) $(libgcrypt-config --libs)" >> Makefile.settings
+-	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $(libgcrypt-config --cflags)" >> Makefile.settings
++	echo "EFLAGS+=$($PKG_CONFIG --libs libotr) $($PKG_CONFIG --libs libgcrypt)" >> Makefile.settings
++	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $($PKG_CONFIG --cflags libgcrypt)" >> Makefile.settings
+ 	echo 'OTR_BI=otr.o' >> Makefile.settings
+ elif [ "$otr" = "plugin" ]; then
+ 	# for some mysterious reason beyond the comprehension of my mortal mind,
+ 	# the libgcrypt flags aren't needed when building as plugin. add them anyway.
+ 	echo '#define OTR_PI' >> config.h
+-	echo "OTRFLAGS=$($PKG_CONFIG --libs libotr) $(libgcrypt-config --libs)" >> Makefile.settings
+-	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $(libgcrypt-config --cflags)" >> Makefile.settings
++	echo "OTRFLAGS=$($PKG_CONFIG --libs libotr) $($PKG_CONFIG --libs libgcrypt)" >> Makefile.settings
++	echo "CFLAGS+=$($PKG_CONFIG --cflags libotr) $($PKG_CONFIG --cflags libgcrypt)" >> Makefile.settings
+ 	echo 'OTR_PI=otr.so' >> Makefile.settings
+ fi
+ 
diff -Nru bitlbee-3.6/debian/patches/series bitlbee-3.6/debian/patches/series
--- bitlbee-3.6/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ bitlbee-3.6/debian/patches/series	2024-05-11 13:42:43.0 +0200
@@ -0,0 +1 @@
+bitlbee_locate_gcrypt_with_pkg-config.diff

Bug#1070903: axc: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

[Andreas Metzler]

Source: axc
Version: 0.3.7-1
Severity: normal
Tags: patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

cu Andreas

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

Kernel: Linux 6.7.12-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
-- 
`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'
Description: Use pkg-config to locate gcrypt
 libgcrypt-config is scheduled for removal.
Author: Andreas Metzler 
Origin: vendor
Last-Update: 2024-05-11

--- axc-0.3.7.orig/Makefile
+++ axc-0.3.7/Makefile
@@ -24,8 +24,8 @@ SQLITE3_LDFLAGS ?= $(shell $(PKG_CONFIG)
 SIGNAL_CFLAGS ?= $(shell $(PKG_CONFIG) --cflags libsignal-protocol-c)
 SIGNAL_LDFLAGS ?= $(shell $(PKG_CONFIG) --libs libsignal-protocol-c)
 
-LIBGCRYPT_CONFIG ?= libgcrypt-config
-LIBGCRYPT_LDFLAGS ?= $(shell $(LIBGCRYPT_CONFIG) --libs)
+LIBGCRYPT_CFLAGS ?= $(shell $(PKG_CONFIG) --cflags libgcrypt)
+LIBGCRYPT_LDFLAGS ?= $(shell $(PKG_CONFIG) --libs libgcrypt)
 
 
 SDIR = src

Bug#1070892: abiword: Please use pkg-config instead of libgcrypt-config to locate libgcrypt

[Andreas Metzler]

Source: abiword
Version: 3.0.5~dfsg-3.2
Severity: normal
Tags: patch
User: ametz...@debian.org
Usertags: libgcrypt-config-removal
Control: block 714589 by -1

Hello,

Please switch from using libgcrypt-config to pkg-config to locate
libgcrypt. libgcrypt-config will be dropped in the next libgcrypt major
release.

Upstream's AM_PATH_LIBGCRYPT() nowadays uses gpgrt-config iff
AM_PATH_GPG_ERROR() is also used. However a) abiword ships an old copy of
libgcrypt.m4 so the newer code is not used by autoreconf and b) abiword
does not use AM_PATH_GPG_ERROR(). Find attached a trivial patch to
simply switch to pkg-config (which is a lot faster than gpgrt-config.)

cu Andreas
-- 
`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'
Description: Use pkg-config to locate gcrypt
 abiword has an old copy AM_PATH_LIBGCRYPT that alsways uses libgcrypt-config.
 Newer versions of that macro would use gpgrt-config when used with
 AM_PATH_GPG_ERROR() which abiword does not.
 pkgconf does the same job faster.
Author: Andreas Metzler 
Origin: vendor
Last-Update: 2024-05-11

--- a/configure.ac
+++ b/configure.ac
@@ -982,19 +982,16 @@ fi
 AM_CONDITIONAL(DEBUG, test "$abi_cv_debug" = "yes")
 
 #
 # Optional dependencies handling
 #
-AM_PATH_LIBGCRYPT( 1.4.5,
-		   [
-		   abi_cv_gcrypt=no
- 		   AC_DEFINE([HAVE_GCRYPT], [1], [Use gcrypt for the cryptos])
-		   ],
-		   [
-		   abi_cv_gcrypt=yes
-		   ] )
-AM_CONDITIONAL(HAVE_GCRYPT, test "$abi_cv_gcrypt" = "yes")
+PKG_CHECK_MODULES([LIBGCRYPT], [libgcrypt >= 1.4.5],
+	   [AC_DEFINE([HAVE_GCRYPT], [1], [Use gcrypt for the cryptos])]
+	   gcryptfound="yes",
+	   [AC_MSG_NOTICE([gcrypt not found])]
+	   gcryptfound="no")
+AM_CONDITIONAL(HAVE_GCRYPT, test "$gcryptfound" = "yes")
 
 if test "$abi_cv_gnomevfs" = "yes"; then 	 
 AC_DEFINE([WITH_GNOMEVFS], [1], [Define if using gnome-vfs]) 	 
 fi 	 
 	

Bug#714589:

[Andreas Metzler]

On 2024-05-09 Alex Henrie  wrote:
> This packaging bug is a big problem for Proton's Wine fork, which
> needs both /usr/lib/i386-linux-gnu/libgcrypt.so and
> /usr/lib/x86_64-linux-gnu/libgcrypt.so to be available at build time.
> Currently, Proton built for Debian can only support ECDH in 32-bit
> games or 64-bit games, but not both. See
> https://github.com/ValveSoftware/wine/commit/8ae2eb018d5b6ea97879f2acc4623afa4de6bc83

> However, it won't do much good to fix libgcrypt20-dev without fixing
> its dependency libgpg-error-dev first. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933713

Hello,

changing libgpg-error-dev might be feasible now that we got rid of
gpg-error-config.

However that was quite painful. codesearch.debian.net lists 78 packages
matching libgcrypt-config. I suspect the majority will be using the
macros from libgcrypt.m4 and therefore already use gpgrt-config but
I also suspect that about a quarter of these either do not or do not or
do not use/autoupdate the current libgcrypt.m4

cu Andreas
-- 
`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#1064486: rnp: FTBFS: Errors while running CTest

[Andreas Metzler]

Control: tags -1 fixed-upstream

On 2024-05-05 Andreas Metzler  wrote:
> On 2024-05-04 Santiago Vila  wrote:
> > found 1064486 0.16.3-1
> > tags 1064486 + ftbfs bookworm trixie sid
> > thanks

> > El 20/4/24 a las 14:12, Andreas Metzler escribió:
> > > FWIW I also get testsuite errors on current sid on amd64
> > > The following tests FAILED:
> > >   83 - rnp_tests.test_ffi_decrypt_wrong_mpi_bits (Failed)
> > >   90 - rnp_tests.test_ffi_security_profile (Failed)
> > >  174 - rnp_tests.test_key_add_userid (Failed)
> > >  254 - cli_tests-EncryptElgamal (Failed)

> > Hello. This is also happening in bookworm, I assume that for the same 
> > underlying reason,
> > so I'm adding the bookworm version.
> [...]

> Hmm. Perhaps a timebomb, i.e. one of the keys used in the testsuite
> expired.


Hello,

Indeed it is a timebomb. Since 0.17.1 works I had a look at
git log src/tests/key-add-userid.cpp
and found

commit 07745e2e5fa6078b95fb5c24575929eb2a19ca03
Author: Nickolay Olshevsky 
Date:   Fri Jan 19 16:05:32 2024 +0200

Update tests to match SHA1 cutoff date for key signatures.
[...]
 selfsig0.primary = false;
+auto curtime = global_ctx.time();
+global_ctx.set_time(curtime > SHA1_KEY_FROM ? SHA1_KEY_FROM - 100 : 0);


SHA1_KEY_FROM is #defined in src/tests/support.h to 1705629600, which
was Fri Jan 19 03:00:00 CET 2024.

cu Andreas
-- 
`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#1064486: rnp: FTBFS: Errors while running CTest

[Andreas Metzler]

On 2024-05-04 Santiago Vila  wrote:
> found 1064486 0.16.3-1
> tags 1064486 + ftbfs bookworm trixie sid
> thanks

> El 20/4/24 a las 14:12, Andreas Metzler escribió:
> > FWIW I also get testsuite errors on current sid on amd64
> > The following tests FAILED:
> >   83 - rnp_tests.test_ffi_decrypt_wrong_mpi_bits (Failed)
> >   90 - rnp_tests.test_ffi_security_profile (Failed)
> >  174 - rnp_tests.test_key_add_userid (Failed)
> >  254 - cli_tests-EncryptElgamal (Failed)

> Hello. This is also happening in bookworm, I assume that for the same 
> underlying reason,
> so I'm adding the bookworm version.
[...]


Hmm. Perhaps a timebomb, i.e. one of the keys used in the testsuite
expired.

cu Andreas

Bug#1070396: exim4: FTBFS on hurd-i386

[Andreas Metzler]

Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=3044

On 2024-05-05 Andreas Metzler  wrote:
[...]
> afaict at a quick glance the second patch works around a real bug. -
> src/tls.c calls tls_server_creds_invalidate() but the source code for
> this function is #ifdefined while the invocation is not.

> I will consult with upstream.

This had been reported upstream by Samuel Thibault, I have added the
first patch there, too.

cu Andreas
-- 
`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#1070396: exim4: FTBFS on hurd-i386

[Andreas Metzler]

On 2024-05-04 Svante Signell  wrote:
> Source: exim4
[...]

> - src_tls-gnu.c.patch:
> Define tls_{client,server}_creds_invalidate() for Hurd too by adding
> #defined(__GNU__) to the condition. Functions gnutls_priority_deinit()
> and gnutls_certificate_free_credentials() already defined in
> libgnutls.so.30 (and libgnutls.a)
[...]

> --- a/src/tls-gnu.c   2023-11-04 13:55:49.0 +0100
> +++ b/src/tls-gnu.c   2024-05-04 17:02:04.0 +0200
> @@ -1720,7 +1720,7 @@
>  }

> -#if defined(EXIM_HAVE_INOTIFY) || defined(EXIM_HAVE_KEVENT)
> +#if defined(EXIM_HAVE_INOTIFY) || defined(EXIM_HAVE_KEVENT) || 
> defined(__GNU__)


Hello Svante,

afaict at a quick glance the second patch works around a real bug. -
src/tls.c calls tls_server_creds_invalidate() but the source code for
this function is #ifdefined while the invocation is not.

I will consult with upstream.

cu Andreas
-- 
`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#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-04-30 Elliott Mitchell  wrote:
> On Tue, Apr 30, 2024 at 05:55:15AM +0200, Andreas Metzler wrote:
> > On 2024-04-29 Elliott Mitchell  wrote:
[...] 
> > > From `nslcd` on clients I was getting the message:
> > > nslcd[12345]: [1a2b3c]  failed to bind to LDAP 
> > > server ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: The 
> > > TLS connection was non-properly terminated.: Resource temporarily 
> > > unavailable
[...] 
> > > Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// ldapi:///'
> > > is two arguments, the ldaps and ldapi are a single argument).  I got
> > > traces from `slapd`: (serial numbers filed off)
> > 
> > > tls_read: want=5, got=5
> > >   :  16 03 01 01 8f
> > 
> > > tls_read: want=399, got=399
> > >   0160:fd12  
> > >   0170::3456:7890:abcd:  
> > >   0180::3.-.@.   
> > > TLS: can't accept: A disallowed SNI server name has been received..
> > > connection_read(13): TLS accept failure error=-1 id=1005, closing
[...]
> > I guess you used the IPv6 address as either CN or Subject Alternative
> > Name. Both take names, not IP addresses. There is a different field for
> > IP addresses.
> > 
> > gnutls-cli --port 636 fd12:3456:7890:abcd::3 
> > 
> > will probably give more info.
> > 
> > FWIW I have just generated a local test certificate with "IPAddress:"
> > set to '::1' and things work for me as expected.

> Hmm, `gnutls-cli --port ldaps` gave a different result.  The connection
> successfully established and I was left being able to type to `slapd`.
[...]
> Anything further is purely guesswork.


Hello,

well you could post the complete output of
gnutls-cli --port 636 fd12:3456:7890:abcd::3
perhaps even with -d10? I would reassign to openldap then if there are
no obvious clues.

cu Andreas
-- 
`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#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Andreas Metzler]

On 2024-04-29 Elliott Mitchell  wrote:
> Package: libgnutls30
> Version: 3.7.9-2+deb12u2
> Severity: important

> Long story to finding this one.  Trying to get LDAP setup on this
> network.  As a recent deployment it seemed appropriate to use IPv6.

> From `nslcd` on clients I was getting the message:
> nslcd[12345]: [1a2b3c]  failed to bind to LDAP server 
> ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: The TLS 
> connection was non-properly terminated.: Resource temporarily unavailable

> Running `nslcd` in debug mode failed to yield any additional useful
> information.

> Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// ldapi:///'
> is two arguments, the ldaps and ldapi are a single argument).  I got
> traces from `slapd`: (serial numbers filed off)

> tls_read: want=5, got=5
>   :  16 03 01 01 8f

> tls_read: want=399, got=399
>   0160:fd12  
>   0170::3456:7890:abcd:  
>   0180::3.-.@.   
> TLS: can't accept: A disallowed SNI server name has been received..
> connection_read(13): TLS accept failure error=-1 id=1005, closing

> Further tracing of the error message appears to point to the function
> `_gnutls_dnsname_is_valid()` in gnutls/lib/str.h.  Seems libgnutls30 is
> incompatible with numeric IPv6 addresses.

> While IPv6-only hosts are presently uncommon, there is now quite a bit of
> IPv6 traffic in many places.  I think this is worthy of having a severity
> of "critical" as "bookworm" may remain as "stable" past when there is
> more IPv6 traffic than IPv4 traffic.  For "trixie" this seems very
> likely.
[...]

Good morning,

I guess you used the IPv6 address as either CN or Subject Alternative
Name. Both take names, not IP addresses. There is a different field for
IP addresses.

gnutls-cli --port 636 fd12:3456:7890:abcd::3 

will probably give more info.

FWIW I have just generated a local test certificate with "IPAddress:"
set to '::1' and things work for me as expected.

cu Andreas
-- 
`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#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29

[Andreas Metzler]

On 2024-04-20 Lucas Nussbaum  wrote:
> Source: libsoup2.4
> Version: 2.74.3-7
> Severity: serious
> Justification: FTBFS
[...]
> > (hsts-test:547071): GLib-Net-WARNING **: 04:03:06.247: Failed to load TLS 
> > database: System trust contains zero trusted certificates; please 
> > investigate your GnuTLS configuration

FWIW I could not reproduce this on amdahl.debian.org, the build
succeeded.

cu Andreas
-- 
`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#1067915: veusz: diff for NMU version 3.6.2-1.1

[Andreas Metzler]

Control: tags 1067915 + patch
Control: tags 1067915 + pending

Dear maintainer,

I've prepared an NMU for veusz (versioned as 3.6.2-1.1) and
uploaded it to DELAYED/00.

kind regards Andreas
diff -Nru veusz-3.6.2/debian/changelog veusz-3.6.2/debian/changelog
--- veusz-3.6.2/debian/changelog	2023-03-20 07:10:18.0 +0100
+++ veusz-3.6.2/debian/changelog	2024-04-21 14:19:21.0 +0200
@@ -1,3 +1,10 @@
+veusz (3.6.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop runtime library packages (not -dev) from b-d. Closes: #1067915
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 14:19:21 +0200
+
 veusz (3.6.2-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru veusz-3.6.2/debian/control veusz-3.6.2/debian/control
--- veusz-3.6.2/debian/control	2023-03-20 07:10:18.0 +0100
+++ veusz-3.6.2/debian/control	2024-04-21 14:18:16.0 +0200
@@ -6,12 +6,6 @@
 Build-Depends: debhelper-compat (= 13),
dh-exec,
dh-python,
-   libqt5core5a,
-   libqt5dbus5,
-   libqt5gui5,
-   libqt5svg5,
-   libqt5widgets5,
-   libqt5xml5,
python3-all,
python3-all-dev,
python3-astropy,


signature.asc
Description: PGP signature

Bug#1068224: deepin-movie-reborn: diff for NMU version 5.10.8-2.1

[Andreas Metzler]

Control: tags 1068224 + patch
Control: tags 1068224 + pending

Dear maintainer,

I've prepared an NMU for deepin-movie-reborn (versioned as 5.10.8-2.1) and
uploaded it to DELAYED/00.

kind regards
Andreas

-- 
`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'
diff -Nru deepin-movie-reborn-5.10.8/debian/changelog deepin-movie-reborn-5.10.8/debian/changelog
--- deepin-movie-reborn-5.10.8/debian/changelog	2022-12-01 00:12:34.0 +0100
+++ deepin-movie-reborn-5.10.8/debian/changelog	2024-04-21 13:23:59.0 +0200
@@ -1,3 +1,11 @@
+deepin-movie-reborn (5.10.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Change hardcoded dependency to libqt5concurrent5t64 instead of
+libqt5concurrent5. Closes: #1068224
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 13:23:59 +0200
+
 deepin-movie-reborn (5.10.8-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru deepin-movie-reborn-5.10.8/debian/control deepin-movie-reborn-5.10.8/debian/control
--- deepin-movie-reborn-5.10.8/debian/control	2022-11-30 23:22:11.0 +0100
+++ deepin-movie-reborn-5.10.8/debian/control	2024-04-21 13:23:54.0 +0200
@@ -55,7 +55,7 @@
  libgstreamer1.0-0,
  libmpris-qt5-1 (>= 0.1.0.1),
  libpulse0,
- libqt5concurrent5,
+ libqt5concurrent5t64,
  va-driver-all,
  ${libmpv:Depends},
  ${misc:Depends},
@@ -99,7 +99,7 @@
  libgstreamer-plugins-base1.0-0,
  libmpris-qt5-1 (>= 0.1.0.1),
  libpulse0,
- libqt5concurrent5,
+ libqt5concurrent5t64,
  ${libmpv:Depends},
  ${misc:Depends},
  ${shlibs:Depends},


signature.asc
Description: PGP signature

Bug#1068226: trantor: diff for NMU version 1.5.12+ds-1.1

[Andreas Metzler]

Control: tags 1068226 + patch
Control: tags 1068226 + pending

Dear maintainer,

I've prepared an NMU for trantor (versioned as 1.5.12+ds-1.1) and
uploaded it to DELAYED/00.

kind regards
Andreas
-- 
`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'
diff -Nru trantor-1.5.12+ds/debian/changelog trantor-1.5.12+ds/debian/changelog
--- trantor-1.5.12+ds/debian/changelog	2023-09-13 13:45:24.0 +0200
+++ trantor-1.5.12+ds/debian/changelog	2024-04-21 12:04:17.0 +0200
@@ -1,3 +1,12 @@
+trantor (1.5.12+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Pull fix from Ubuntu by Michael Hudson-Doyle:
++ Drop spurious Depends on libssl3 as package is currently built with no
+  TLS provider. Closes: #1068226
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 12:04:17 +0200
+
 trantor (1.5.12+ds-1) unstable; urgency=medium
 
   * New upstream release 1.5.12+ds (Closes: #1042181)
diff -Nru trantor-1.5.12+ds/debian/control trantor-1.5.12+ds/debian/control
--- trantor-1.5.12+ds/debian/control	2023-06-13 14:51:48.0 +0200
+++ trantor-1.5.12+ds/debian/control	2024-04-21 12:04:17.0 +0200
@@ -11,7 +11,7 @@
 
 Package: libtrantor1
 Architecture: any
-Depends: libssl3, libc-ares2, ${misc:Depends}, ${shlibs:Depends}
+Depends: libc-ares2, ${misc:Depends}, ${shlibs:Depends}
 Description: Non-blocking I/O cross-platform TCP network library
  Trantor is a non-blocking I/O cross-platform TCP network library, using C++14.
  Drawing on the design of Muduo Library


signature.asc
Description: PGP signature

Bug#1068608: tfortune dependencies unsatisfiable on 32-bit non-i386 architectures.

[Andreas Metzler]

On 2024-04-08 Andre Noll  wrote:
> On Sun, Apr 07, 22:02, Peter Michael Green wrote:

> > After being rebuilt for the time64 transition, tfortune
> > depends on both liblopsub1 and liblopsub1t64. 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 liblopsub1.
> > 
> > https://launchpadlibrarian.net/720835658/tfortune_1.0.1-1build1_1.0.1-1ubuntu1.diff.gz

> This was fixed already on February 2nd as suggested by Steve, see
> upstream commit f40f0aae211f. Please let me know if any further action
> is required on my part.

Hello Andre,

Well, it needs to be uploaded.

cu Andreas
-- 
`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'


signature.asc
Description: PGP signature

Bug#1068689: urfkill: diff for NMU version 0.5.0-7.2

[Andreas Metzler]

Control: tags 1068689 + patch
Control: tags 1068689 + pending

Dear maintainer,

I've prepared an NMU for urfkill (versioned as 0.5.0-7.2) and
uploaded it to DELAYED/00.

Regards Andreas
diff -Nru urfkill-0.5.0/debian/changelog urfkill-0.5.0/debian/changelog
--- urfkill-0.5.0/debian/changelog	2023-09-06 15:48:31.0 +0200
+++ urfkill-0.5.0/debian/changelog	2024-04-21 11:43:27.0 +0200
@@ -1,3 +1,10 @@
+urfkill (0.5.0-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop hardcoded dependency on libglib2.0-0. Closes: #1068689
+
+ -- Andreas Metzler   Sun, 21 Apr 2024 11:43:27 +0200
+
 urfkill (0.5.0-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru urfkill-0.5.0/debian/control urfkill-0.5.0/debian/control
--- urfkill-0.5.0/debian/control	2023-09-06 15:47:18.0 +0200
+++ urfkill-0.5.0/debian/control	2024-04-21 11:42:51.0 +0200
@@ -10,7 +10,7 @@
 Architecture: linux-any
 Multi-Arch: foreign
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, libglib2.0-0, libdbus-1-3, libdbus-glib-1-2, dbus, libgudev-1.0-0, libpolkit-gobject-1-0, libexpat1, default-logind | logind
+Depends: ${shlibs:Depends}, ${misc:Depends}, libdbus-1-3, libdbus-glib-1-2, dbus, libgudev-1.0-0, libpolkit-gobject-1-0, libexpat1, default-logind | logind
 Description: wireless killswitch management daemon for laptops
  The urfkill daemon allow managing the rfkill-related hotkeys
  and the killswitches in a more configurable way for the common RF


signature.asc
Description: PGP signature

Bug#1069307: FTBFS: configure: error: must specify --with-locking-method option

[Andreas Metzler]

Control: tags -1 patch

On 2024-04-19 Andrey Rakhmatullin  wrote:
> Source: courier
> Version: 1.0.16-3.2
> Severity: serious
> Tags: ftbfs

> https://buildd.debian.org/status/fetch.php?pkg=courier=armel=1.0.16-3.2%2Bb4=1712019536=0

> checking for locking method... configure: error: must specify --with-locking-
> method option
> configure: error: ./configure failed for libs/liblock
[...]

Multiple autoconf tests are thrown by
-Wno-error=implicit-function-declaration.

cu Andreas
-- 
`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'
Description: Fixx FTBFS due to implicit declarations in autoconf tests.
Author: Andreas Metzler 
Bug-Debian: https://bugs.debian.org/1069307
Origin: vendor
Last-Update: 2024-04-20

--- a/libs/ldapaddressbook/configure.ac
+++ b/libs/ldapaddressbook/configure.ac
@@ -52,10 +52,11 @@ then
 	AC_TRY_LINK([
 #include 
 #if HAVE_LBER_H
 #include 
 #endif
+#define LDAP_DEPRECATED 1
 #include 
 ],
 [
 	LDAP *p=NULL;
 
--- a/libs/liblock/locktest.c
+++ b/libs/liblock/locktest.c
@@ -15,10 +15,13 @@
 #endif
 #include	
 #include	
 #include	
 #include	
+#include	
+#include	
+
 
 int main()
 {
 #define FILENAME	"courier-imap.locktest.XX"
 int	fd[2];
--- a/libs/tcpd/configure.ac
+++ b/libs/tcpd/configure.ac
@@ -221,10 +221,11 @@ AC_TRY_RUN(
 
 changequote(<<,>>)
 
 #include	
 #include	
+#include	
 
 int main(int argc, char **argv)
 {
 int	pipefd[2];
 char	c;
--- a/libs/waitlib/confwait.c
+++ b/libs/waitlib/confwait.c
@@ -22,10 +22,12 @@
 #include	
 
 #define	INCLUDED_FROM_CONFIGURE
 #include	"waitlib.c"
 
+#include	
+
 #define	NUMPROCS	10
 
 static int numterminated=0;
 
 

Bug#1066396: lftp: diff for NMU version 4.9.2-2.1

[Andreas Metzler]

Control: tags 1066396 + pending

Dear maintainer,

I've prepared an NMU for lftp (versioned as 4.9.2-2.1) and uploaded it
to unstable. This the implements the minimal fix I sent to this bug
almost a month ago.

cu Andreas
-- 
`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'
diff -Nru lftp-4.9.2/debian/changelog lftp-4.9.2/debian/changelog
--- lftp-4.9.2/debian/changelog	2022-07-16 12:24:04.0 +0200
+++ lftp-4.9.2/debian/changelog	2024-04-20 14:28:35.0 +0200
@@ -1,3 +1,14 @@
+lftp (4.9.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Minimal change to fix FTBFS with -Werror=implicit-function-declaration
++ ftbfs_implicit.diff - Fixup configure*.
++ Use selective touch in debian/rules to allow changing configure*
+  without using dh_autoreconf.
+Closes: #1066396
+
+ -- Andreas Metzler   Sat, 20 Apr 2024 14:28:35 +0200
+
 lftp (4.9.2-2) unstable; urgency=medium
 
   * lftp.tech domain doesn't work anymore; switch back to lftp.yar.ru
diff -Nru lftp-4.9.2/debian/patches/ftbfs_implicit.diff lftp-4.9.2/debian/patches/ftbfs_implicit.diff
--- lftp-4.9.2/debian/patches/ftbfs_implicit.diff	1970-01-01 01:00:00.0 +0100
+++ lftp-4.9.2/debian/patches/ftbfs_implicit.diff	2024-04-20 14:24:10.0 +0200
@@ -0,0 +1,20 @@
+--- lftp-4.9.2.orig/configure
 lftp-4.9.2/configure
+@@ -57429,6 +57429,7 @@ else
+   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ /* end confdefs.h.  */
+ 
++	#include 
+ 	 int main()
+ 	 {
+ 	unsigned long long x=0,x1;
+--- lftp-4.9.2.orig/m4/needtrio.m4
 lftp-4.9.2/m4/needtrio.m4
+@@ -9,6 +9,7 @@ AC_DEFUN([LFTP_NEED_TRIO],[
+   else
+ 
+   AC_RUN_IFELSE([AC_LANG_SOURCE([[
++	#include 
+ 	 int main()
+ 	 {
+ 	unsigned long long x=0,x1;
diff -Nru lftp-4.9.2/debian/patches/series lftp-4.9.2/debian/patches/series
--- lftp-4.9.2/debian/patches/series	2022-07-16 12:24:04.0 +0200
+++ lftp-4.9.2/debian/patches/series	2024-04-20 14:27:34.0 +0200
@@ -1,3 +1,4 @@
 config-dns-inet6_before_inet.patch
 lftp_sys-stdint-kfreebsd.patch
 lftp_gnutls_certificate_verify_peers2-verify_server_certificates.patch
+ftbfs_implicit.diff
diff -Nru lftp-4.9.2/debian/rules lftp-4.9.2/debian/rules
--- lftp-4.9.2/debian/rules	2018-09-17 09:33:33.0 +0200
+++ lftp-4.9.2/debian/rules	2024-04-20 14:27:19.0 +0200
@@ -19,6 +19,9 @@
 
 #configure: configure-stamp
 configure-stamp:
+	# Avoid autoconf rebuild due to patching input files.
+	touch --reference=aclocal.m4 configure m4/needtrio.m4
+	touch --reference=Makefile.am m4/needtrio.m4
 	dh_testdir
 	# Add here commands to configure the package.
 	CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure \


signature.asc
Description: PGP signature

Bug#1064486: rnp: FTBFS: Errors while running CTest

[Andreas Metzler]

On 2024-02-23 Bo YU  wrote:
> Source: rnp
> Version: 0.17.0-3
> Severity: serious 

> Dear Maintainer,

> The package has a ftbfs issue on my local amd64 build:

> ```
> 260/260 Test #255: cli_tests-Encryption 
> ..   Passed   60.86 
> sec

> 98% tests passed, 6 tests failed out of 260

> Total Test time (real) =  71.61 sec

> The following tests FAILED:
>  90 - rnp_tests.test_ffi_security_profile (Failed)
> 159 - rnp_tests.test_rnp_access (Failed)
> 166 - rnp_tests.rnpkeys_generatekey_verifykeyHomeDirNoPermission 
> (Failed)
> 174 - rnp_tests.test_key_add_userid (Failed)
> 258 - cli_tests-EncryptElgamal (Failed)
> 259 - cli_tests-Misc (Failed)

FWIW I also get testsuite errors on current sid on amd64
The following tests FAILED:
 83 - rnp_tests.test_ffi_decrypt_wrong_mpi_bits (Failed)
 90 - rnp_tests.test_ffi_security_profile (Failed)
174 - rnp_tests.test_key_add_userid (Failed)
254 - cli_tests-EncryptElgamal (Failed)

Upstream's GIT head does not fail. I tried bisecting but gave up, there
are too many errors, especially when gtest was integrated and tried to
build itself with -Werror. Ouch.

cu Andreas

Bug#1010965: db5.3: New upstream (comdb2's embedded copy)

[Andreas Metzler]

On 2022-05-14 Bastian Germann  wrote:
> Source: db5.3
> Severity: wishlist
> X-Debbugs-Cc: 987...@bugs.debian.org

> There is a Sleepycat-licensed fork of BerkeleyDB at
> https://github.com/bloomberg/comdb2/tree/master/berkdb.  Maybe this is
> a way forward as long as #987013 (removal) is not resolved and bugs
> like #928441 are lurking.

Hello,

Afaict from
#define DB_VERSION_MAJOR4
#define DB_VERSION_MINOR2
#define DB_VERSION_PATCH52
#define DB_VERSION_STRING   "Sleepycat Software: Berkeley DB 4.2.52: 
(December  3, 2003)"
that is fork of 4.2.52.

cu Andreas
-- 
`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#1065538: bind9-libs hard-codes a dependency on libuv1

[Andreas Metzler]

On 2024-03-06 Ondřej Surý  wrote:
>> On 6. 3. 2024, at 12:45, Matthias Klose  wrote:
 
>> Package: bind9-libs
>> Version: 1:9.19.21-1
>> Severity: serious
>> Tags: sid trixie

>> bind9-libs hard-codes a dependency on libuv1, that should be
>> libuv1t64 now. But better derive it form the libuv1-dev dependency.

> The reason why we do so is that libuv has some changes between version
> that don’t propagate to ABI. I might be able to drop this in unstable
> though and just keep it for backports.

Hello,

does the reported issue actually exist?

I just cannot find the hardcoded dependency in the source package.

ametzler@argenau:/dev/shm//bind9-9.19.21$ dpkg-parsechangelog -SVersion
1:9.19.21-1
ametzler@argenau:/dev/shm//bind9-9.19.21$ grep -r libuv1 debian/
debian/changelog:  * Add libuv1-dev, libcmocka-dev, libedit-dev and zlib1g-dev 
to B-D
debian/control:   libuv1-dev,
(sid)ametzler@argenau:/dev/shm//bind9-9.19.21$ apt-cache show bind9-libs | 
grep -E '^Version|^Dep'
Version: 1:9.19.21-1+b1
Depends: libc6 (>= 2.34), libfstrm0 (>= 0.2.0), libgssapi-krb5-2 (>= 1.17), 
libjemalloc2 (>= 4.0.0), libjson-c5 (>= 0.15), libkrb5-3 (>= 1.6.dfsg.2), 
liblmdb0 (>= 0.9.7), libmaxminddb0 (>= 1.3.0), libnghttp2-14 (>= 1.12.0), 
libprotobuf-c1 (>= 1.0.1), libssl3t64 (>= 3.0.0), liburcu8t64 (>= 0.13.0), 
libuv1t64 (>= 1.38.0), libxml2 (>= 2.7.4), zlib1g (>= 1:1.1.4)

cu Andreas
-- 
`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#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Andreas Metzler]

On 2024-03-23 Diederik de Haas  wrote:
[...]
> 2) near the end of your build log is the following message:
> "../os/meson.build:63:8: ERROR: Problem encountered: secure-rpc requested, 
> but 
> neither libtirpc or libc RPC support were found"
> And that matches the build issue mentioned in #1065184.

> If you agree, please merge these two bugs.
> FTR: Bug #1065184 is already fixed in git.

FWIW I can cobnfirm that xwayland builds successfully if libtirpc-dev is
installed.

cu Andreas
-- 
`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#1017361: ITA: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix

[Andreas Metzler]

On 2024-04-12 Abhijith PA  wrote:
> On 12/04/24 03:34 PM, Andreas Metzler wrote:
[...]
>>> On Sun, 11 Jun 2023 23:09:11 +0530 Abhijith PA  wrote:
>>>> I would like to adopt this package. I maintain a mailing list server
>>>> where I am already using postsrsd.


>> I guess you are not interested anymore?

> I am interested. I have pushed latest upstream source to 
> salsa.(https://salsa.debian.org/debian/postsrsd). Made an upload for 
> Raju (Cc'ed). But I failed to package latest upstream to Debian repo. 
> I tried and hit at obstacle and then left at there. 

> I am happy to pass it you and Raju. Let me know.

Hello,

I am not going to adopt it (Using exim). It is just that I browsed over
the open RC bug list and found both an RC bug (#1068053) and a ITA that
did not look like it was going anywhere and wondered what was up.

FWIW I played a little bit with 2.0.8 and got it to build with:
a) extending b-d by libconfuse-dev, check, pkgconf, systemd-dev
b) Patching cmake/FindCheck.cmake
-find_path(Check_subunit_LIBRARY subunit HINTS ${PC_SUBUNIT_LIBRARY_DIRS})
+find_library(Check_subunit_LIBRARY subunit HINTS 
${PC_SUBUNIT_LIBRARY_DIRS})
[This is now upstream issue #176)
c) Invoking cmake with -DFETCHCONTENT_TRY_FIND_PACKAGE_MODE=ALWAYS
(Borrowed from OpenSuse ;-)

It is not enough to get a functioning package, but it is packaging and
not compilation from there on.

cu Andreas
-- 
`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#1017361: ITA: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix

[Andreas Metzler]

On 2023-07-17 Oxan van Leeuwen  wrote:
> On 16-07-2023 22:35, Timo Röhling wrote:
> > I think this was not forwarded to Oxan, so I'm resending it to

> You're right, thanks for the forward.

> On Sun, 11 Jun 2023 23:09:11 +0530 Abhijith PA  wrote:
> > I would like to adopt this package. I maintain a mailing list server
> > where I am already using postsrsd.

> That's great! The packaging is currently hosted in the Debian group on
> Salsa, so as a DD you should already have access to it. I'm not aware of
> anything that needs to be done for the handover, so feel free to take over
> that repository (or move it elsewhere, if you prefer), and to upload a new
> version with you listed as Maintainer.

> If you've any questions about the current packaging, don't hesitate to reach
> out!

Hello Abhijith,

I guess you are not interested anymore?

cu Andreas
-- 
`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#1068644: gnutls-bin: "Fatal error: The encryption algorithm is not supported" appeared with 3.8.5 upgrade

[Andreas Metzler]

Control: severity -1 serious
Control: forwarded -1 https://gitlab.com/gnutls/gnutls/-/issues/1540

On 2024-04-08 Sanjoy Mahajan  wrote:
> Package: gnutls-bin
> Version: 3.8.5-1
> Severity: normal
> X-Debbugs-Cc: none, Sanjoy Mahajan 
> File: /usr/bin/gnutls-cli

> After dist-upgrading today, exim4 could no longer talk to my usual
> outgoing mail server.  I reproduced the problem using just gnutls-cli.
> The problem started after today's upgrade of the various gnutls
> packages.  They were upgraded from 3.8.4-2 to 3.8.5-1.

> The following command with the given input lines reproduces the problem:

>   $ gnutls-cli -V -d 9 --starttls --crlf --port 587 -V outgoing.mit.edu
>   EHLO randomhost
>   STARTTLS
>   ctrl-D [to send EOF]

> It fails with "*** Fatal error: The encryption algorithm is not supported."
[...]

Thank you and sorry. I have done a bisect and will try reverting the
offending upstream commit as a hotfix.

cu Andreas

Bug#1066010: dvdisaster: diff for NMU version 0.79.10-3.1

[Andreas Metzler]

Control: tags 1066010 + patch
Control: tags 1066010 + pending

Dear maintainer,

I've prepared an NMU for dvdisaster (versioned as 0.79.10-3.1) and
uploaded it to DELAYED/00.

Kind regards
Andreas
-- 
`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'
diff -Nru dvdisaster-0.79.10/debian/changelog dvdisaster-0.79.10/debian/changelog
--- dvdisaster-0.79.10/debian/changelog	2024-01-13 16:05:58.0 +0100
+++ dvdisaster-0.79.10/debian/changelog	2024-04-07 18:38:18.0 +0200
@@ -1,3 +1,10 @@
+dvdisaster (0.79.10-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration Closes: #1066010
+
+ -- Andreas Metzler   Sun, 07 Apr 2024 18:38:18 +0200
+
 dvdisaster (0.79.10-3) unstable; urgency=medium
 
   * Team upload
diff -Nru dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff
--- dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff	1970-01-01 01:00:00.0 +0100
+++ dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff	2024-04-07 18:37:13.0 +0200
@@ -0,0 +1,33 @@
+Description: Fix FTBFS with -Werror=implicit-function-declaration
+Author: Andreas Metzler 
+Bug-Debian: https://bugs.debian.org/1066010
+Origin: vendor
+Forwarded: no
+Last-Update: 2024-04-07
+
+--- dvdisaster-0.79.10.orig/scripts/bash-based-configure
 dvdisaster-0.79.10/scripts/bash-based-configure
+@@ -1188,6 +1188,7 @@ function REQUIRE_MOTIF()
+ 
+cat >conftest.c <
++#include 
+ int main()
+ {  printf("%d.%d.%d\n",XmVERSION,XmREVISION,XmUPDATE_LEVEL);
+ }
+@@ -1215,6 +1216,7 @@ EOF
+ 
+cat >conftest.c <
++#include 
+ int main()
+ {  printf("%s\n",LesstifVERSION_STRING);
+ }
+@@ -1373,6 +1375,7 @@ EOF
+ 
+cat >conftest.c <
++#include 
+ int main(int argc, char *argv[])
+ { g_malloc(1024); 
+ 
diff -Nru dvdisaster-0.79.10/debian/patches/series dvdisaster-0.79.10/debian/patches/series
--- dvdisaster-0.79.10/debian/patches/series	2024-01-13 16:05:58.0 +0100
+++ dvdisaster-0.79.10/debian/patches/series	2024-04-07 18:35:42.0 +0200
@@ -17,3 +17,4 @@
 36-fix-parallelism.patch
 37-suggest-dvdisaster-doc.patch
 0032-Fix-for-compilation-error-under-gcc-10.patch
+38-ftbfs-implicit-functions.diff


signature.asc
Description: PGP signature

Bug#1068219: chatty, dependencies unsatisfiable on 32-bit non-i386 architectures.

[Andreas Metzler]

Control: tags -1 patch

On 2024-04-02 Peter Michael Green  wrote:
> Package: chatty
> Version: 0.8.2-1
> Severity: serious
> User: debian-...@lists.debian.org
> Usertag: time-t

> After being rebuilt for the time64 transition, chatty depends
> on both libpurple0 and libpurple0t64. As a
> result it is uninstallable on architectures that are undergoing
> the time64 transition (armel, armhf and some debian-ports
> archictures).

Hello,

This is caused by
(sid_armhf-dchroot)ametzler@abel:~/TRDY$ head debian/shlibs.local
libjabber 0 libpurple0
and 
(sid_armhf-dchroot)ametzler@abel:~/TRDY$ objdump -p 
chatty-0.8.2/debian/chatty/usr/bin/chatty  | grep NEEDE | grep jab
  NEEDED   libjabber.so.0
(sid_armhf-dchroot)ametzler@abel:~/TRDY$ ldd -r 
chatty-0.8.2/debian/chatty/usr/bin/chatty | grep jabb
libjabber.so.0 => /usr/lib/arm-linux-gnueabihf/purple-2/libjabber.so.0 
(0xb69b6000)
(It uses an rpath to find it.)

So afaiui this could be fixed by pointing to libpurple0t64 in
debian/shlibs.local.

cu Andreas

-- 
`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#1066005: epic4: FTBFS on arm{el,hf}: gailib.c:95:17: error: implicit declaration of function ‘strlcpy’; did you mean ‘strncpy’? [-Werror=implicit-function-declaration]

[Andreas Metzler]

Control: tags -1 fixed-upstream

On 2024-03-10 Sebastian Ramacher  wrote:
> Source: epic4
> Version: 1:2.10.10-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=epic4=armhf=1%3A2.10.10-1%2Bb5=1709806588=0

> gcc -g -O2 -Werror=implicit-function-declaration 
> -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  
> -I./../include -I../include -c gailib.c
> gailib.c: In function ‘get_name’:
> gailib.c:95:17: error: implicit declaration of function ‘strlcpy’; did you 
> mean ‘strncpy’? [-Werror=implicit-function-declaration]
>95 | strlcpy((ai)->ai_canonname, (str), strlen(str) + 1);\
>   | ^~~

This is fixed in 2.10.11.

cu Andreas

Bug#1060457: /usr/sbin/exim4: SIGSEGV when remote smtp reject the message

[Andreas Metzler]

Control: found 1060457 4.96-15+deb12u2

On 2024-04-02 Didier Raboud via Pkg-exim4-maintainers 
 wrote:
> wrote:
>> Il giorno ven, 12/01/2024 alle 18.15 +0100, Andreas Metzler ha scritto:
>>> Is this a regression in 4.96-15+deb12u4? i.e. can you still reprroduce
>>> the issue after downgrading exim4-daemon-heavy to 4.96-15+deb12u3 [1]
>>> (and re-reproduce after upgrading again)?
[...]
> This does not seem to be a regression; I tried as far back as deb12u2 and
> the same issue could be reproduced.

Thank you.

Would you be able to check with 4.97, too? I intend to provide backports
once testing has stopped being stuck due to t64.

cu Andreas
-- 
`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#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   | 

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#1065221: O: py7zr -- pure Python 7-zip library

[Andreas Metzler]

On 2024-03-30 yokota  wrote:
> I'm interested in py7zr because it is required by Calibre.

> New py7zr requires some other modules that not packaged by Debian yet.
> I make those modules into Debian packages.
> https://salsa.debian.org/yokota/python-multivolumefile
> https://salsa.debian.org/yokota/python-bcj
> https://salsa.debian.org/yokota/python-brotlicffi
> https://salsa.debian.org/yokota/python-inflate64
> https://salsa.debian.org/yokota/python-pyppmd
> https://salsa.debian.org/yokota/python-pyzstd

> And here is my py7zr repository.
> https://salsa.debian.org/yokota/py7zr

> I am a Debian Maintainer, so I want mentor to upload these packages.

Amazing. :-)  Thank you very much for the heads-up.

I am not yet confident enough in python packaging to sponsor the
uploads. I trust you'll find knowledgeable helpers in Debian Python
Team, of which you are already a member.

cu Andreas
-- 
`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#1067905: mpg321: Does not work on modern system (pipewire)

[Andreas Metzler]

On 2024-03-30 Peter B  wrote:
> "mpg321 simply produces no sound output here on a system running pipewire."

> How strange!

> Just wondering; have you got pipewire-alsa installed?


Hello Peter,

yes, I have got the recommended meta-package (pipewire-audio)
installed.

cu Andreas
-- 
`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#1065221: O: py7zr -- pure Python 7-zip library

[Andreas Metzler]

On 2024-03-02 Sandro Tosi  wrote:
[...]
> I intend to orphan the py7zr package.

> The package description is:
>  py7zr is a library and command-line utility to support 7zip archive
>  compression, decompression, encryption and decryption.

I will take a look, since I use calibre. (Just a heads-up, I will
happily step back if if other adopters with strong python-foo come
forth.)

cu Andreas
-- 
`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#1067844: c-evo-dh: Depends on dead-upstream mpg321 instead of mpg123

[Andreas Metzler]

On 2024-03-28 Peter B  wrote:
> On 27/03/2024 14:57, Andreas Metzler wrote:
>> mpg321 is dead upstream
> I don't see that as a show stopper.

>> Please consider moving to another player, e.g. mpg123.
> I moved away from ffmpeg after c-evo-dh showed a puiparts fail
> stemming from libnettle8. c-evo-dh does not use any crypto stuff,
> that library was brought in by ffmpeg.

> I picked mpg321 over mpg123 because it it has fewer dependencies.

Hello Peter,

> Also, mpg123 is broken
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067562

it works perfectly fine in trixie and both maintainers and upstream are
actively working together to resolve the issue in sid.

> mpg321 uses fixed point arithmetic, and is likely to be a better
> choice on low spec architectures with no floating point (armel).

> I would prefer to keep mpg321 as the sound option for c-evo-dh

> Noting the user-tag mpg321-removal on your bug report,
> I could instead maintain mpg321 myself if it were orphaned...

I recently had a look at mpg321 because it had a FTBFS bug, I hotfixed
this by NMU and looking at the package got the distinct impression of
having stumbled over a package that we would better be off without in
trixie.

There are loads of old bugs including rather severe ones at first
glance. The fact that the packaging is very dated is not the real
problem (Updating to dh could probably be done in in an , since it os
basically a single binary package.) There is just a lot of technical
debt due to missing upstream, it does not need maintainership but a new
upstream author.

On my local system there simply is no sound output, I suspect it cannot
work when pipewire or pulseaudio is used.

cu Andreas
-- 
`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#1067883: terminatorx: Depends on dead-upstream mpg321 instead of mpg123

[Andreas Metzler]

Source: terminatorx
Version: 4.2.0-1
Severity: normal
X-Debbugs-Cc: ametz...@bebt.de
User: ametz...@debian.org
Usertags: mpg321-removal

Hello,

this package depends on mpg321. mpg321 is dead upstream (last change
2012, about 12 years ago), it was initially created because of license
issues with mpg123, however mpg123 moved to Debian main in 2006.

Please consider moving to another player, e.g. mpg123. mpg123 license
nowadays is LGPL-2.1, while mpg321 uses GPL-2+. Since LGPL-2.1 can be
relicensed to GPL-2+ there should not be any problemds on that side.

cu Andreas

Bug#1067882: snd-common: recommends dead-upstream mpg321 instead of mpg123

[Andreas Metzler]

Source: snd-common
Version: 24.2-1
Severity: normal
X-Debbugs-Cc: ametz...@bebt.de
User: ametz...@debian.org
Usertags: mpg321-removal

Hello,

this package recommends mpg321. mpg321 is dead upstream (last change
2012, about 12 years ago), it was initially created because of license
issues with mpg123, however mpg123 moved to Debian main in 2006.

Please consider moving to another player, e.g. mpg123. mpg123 license
nowadays is LGPL-2.1, while mpg321 uses GPL-2+. Since LGPL-2.1 can be
relicensed to GPL-2+ there should not be any problemds on that side.

cu Andreas