Bug#1013867: closed by Richard Laager (Re: Bug#1013867: Don't use user ntpsec if package ntp is installed)

[Klaus Ethgen]

Am So den 23. Jul 2023 um 22:18 schrieb Debian Bug Tracking System:
> The ntpsec namespacing is by design.

Well, also by design is by design wrong.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1041837: libreoffice-draw: undeclared file conflict with libreoffice-impress-nogui <= trixie: /usr/lib/libreoffice/share/config/soffice.cfg/simpress/*.xml

[Rene Engelhard]

Hi,


Am 24.07.23 um 06:52 schrieb Helmut Grohne:


libreoffice-draw installs
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
and
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml
which are also contained in libreoffice-impress-nogui from bullseye to
trixie.


Mmh, indeed.


Already fixed in experimental (well, NEW since ~ 2 months) already though:

Package: libreoffice-uiconfig-impress
Section: misc
Architecture: all
Replaces: libreoffice-common (<< 4:7.6.0~beta1),
  libreoffice-draw (<< 4:7.6.0~rc1),
  libreoffice-draw-nogui (<< 4:7.6.0~rc1),
  libreoffice-impress (<< 4:7.6.0~rc1),
  libreoffice-impress-nogui (<< 4:7.6.0~rc1)


Leaves "just" sid.


Regards,


Rene

Bug#1041834: libclang-rt-16-dev: undeclared file conflict with libclang-rt-16-dev-wasm{32,64} on /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm*.a

[Helmut Grohne]

Control: clone -1 -2
Control: reassign -2 libclang-rt-17-dev

On Mon, Jul 24, 2023 at 06:45:00AM +0200, Helmut Grohne wrote:
> libclang-rt-16-dev installs
> /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm{32,64}.a,
> which are also installed by libclang-rt-16-dev-wasm{32,64} respectively.
> Trying to coinstall these packages in unstable results in an unpack
> error. I guess that these files should only be contained in the
> respective wasm packages. Don't forget to include the necessary
> Breaks+Replaces when fixing this.

The same issue exists for version 17.

Helmut

Bug#1041837: libreoffice-draw: undeclared file conflict with libreoffice-impress-nogui <= trixie: /usr/lib/libreoffice/share/config/soffice.cfg/simpress/*.xml

[Helmut Grohne]

Package: libreoffice-draw
Version: 4:7.5.5-2
Severity: serious

libreoffice-draw installs
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/layoutlist.xml
and
/usr/lib/libreoffice/share/config/soffice.cfg/simpress/objectlist.xml
which are also contained in libreoffice-impress-nogui from bullseye to
trixie. Trying to install libreoffice-draw may result in an unpack
error. Please add the necessary Breaks and Replaces.

Helmut

Bug#1041836: libc6 2.36-9+deb12u1 stack smashing on some but not all amd64

[Mike Bird]

Package: libc6
Version: 2.36-9
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Installing libc6_2.36-9+deb12u1_amd64.deb on some but not all systems
results in every dynamically linked program dying with a spurious
report of stack smashing.  Getting back to a working system required
use of busybox to get bash-static and also creating a fake perl as a
shell script containing exit 0 (because /bin/true is dynamic) and
then busybox again to wget and dpkg install the 2.36-9.

I repeated this three times to be sure.

Works OK on e.g. Intel(R) Xeon(R) CPU L5520  @ 2.27GHz
Stack smashing on e.g. Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz

Preparing to unpack .../libc6_2.36-9+deb12u1_amd64.deb ...
Unpacking libc6:amd64 (2.36-9+deb12u1) over (2.36-9) ...
*** stack smashing detected ***: terminated
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Aborted)
*** stack smashing detected ***: terminated
E: Sub-process /usr/bin/dpkg exited unexpectedly
# ls -l
*** stack smashing detected ***: terminated
Aborted
#

Both successes and failures were on multiarch systems with i386
although that does not seem to be relevant.


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (2000, 'stable-updates'), (2000, 'stable-security'), (2000, 
'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash-static
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc-s1  12.2.0-14

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.3-1+b1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.82
ii  glibc-doc  2.36-9+deb12u1
ii  libc-l10n  2.36-9+deb12u1
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.36-9

-- no debconf information

Bug#1041835: gretl: installs empty directory /usr/lib/pkgconfig

[Helmut Grohne]

Source: gretl
Version: 2023b-1
Severity: important
Tags: patch

gretl contains an empty directory /usr/lib/pkgconfig. Due to having
implemented the /usr-merge using directory aliasing, this directory is
prone to loss.

Looking into gretl, it becomes evident that this directory is not
needed. It is an artifact of splitting files to different binary
packages. As such, the directory can be deleted without loss of
functionality. What does not exist, cannot be lost, problem solved. I'm
attaching a patch for your convenience.

Helmut
diff -Nru gretl-2023b/debian/changelog gretl-2023b/debian/changelog
--- gretl-2023b/debian/changelog2023-07-23 16:34:54.0 +0200
+++ gretl-2023b/debian/changelog2023-07-24 06:32:35.0 +0200
@@ -1,3 +1,10 @@
+gretl (2023b-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not ship empty directory /usr/lib/pkgconfig. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 24 Jul 2023 06:32:35 +0200
+
 gretl (2023b-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gretl-2023b/debian/gretl.overrides gretl-2023b/debian/gretl.overrides
--- gretl-2023b/debian/gretl.overrides  2018-08-12 23:12:16.0 +0200
+++ gretl-2023b/debian/gretl.overrides  2023-07-24 06:29:59.0 +0200
@@ -13,8 +13,5 @@
 gretl: package-contains-empty-directory usr/share/gretl/fonts/
 gretl: package-contains-empty-directory usr/share/gretl/gtksourceview/
 gretl: package-contains-empty-directory usr/share/gretl/scripts/misc/
-gretl: package-contains-empty-directory usr/lib/pkgconfig/
 gretl: package-contains-empty-directory usr/share/gretl/db/
-gretl: postinst-has-useless-call-to-ldconfig
-gretl: postrm-has-useless-call-to-ldconfig
 gretl: package-contains-empty-directory usr/share/gretl/ui/
diff -Nru gretl-2023b/debian/rules gretl-2023b/debian/rules
--- gretl-2023b/debian/rules2023-05-23 20:08:51.0 +0200
+++ gretl-2023b/debian/rules2023-07-24 06:32:33.0 +0200
@@ -138,6 +138,7 @@
dh_installdocs  -p$(docpack)README* doc/
dh_installexamples  -p$(docpack)utils/
 #dh_movefiles  --sourcedir=debian/$(package) -p$(docpack)
+   find debian/$(package)/usr/lib/pkgconfig -type d -empty -delete
 
 # edd 19 Mar 2009  remove fonts deemed non-free
rm -vrf debian/$(compack)/usr/share/gretl/fonts

Bug#1041834: libclang-rt-16-dev: undeclared file conflict with libclang-rt-16-dev-wasm{32,64} on /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm*.a

[Helmut Grohne]

Package: libclang-rt-16-dev
Version: 1:16.0.6-5
Severity: serious

libclang-rt-16-dev installs
/usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm{32,64}.a,
which are also installed by libclang-rt-16-dev-wasm{32,64} respectively.
Trying to coinstall these packages in unstable results in an unpack
error. I guess that these files should only be contained in the
respective wasm packages. Don't forget to include the necessary
Breaks+Replaces when fixing this.

Helmut

Bug#1041833: libafl-persistent-ocaml: undeclared file conflict with libafl-persistent-ocaml-dev/bookworm

[Helmut Grohne]

Package: libafl-persistent-ocaml
Version: 1.4-2
Severity: serious

libafl-persistent-ocaml installs /usr/lib/ocaml/afl-persistent/META,
which is also installed by libafl-persistent-ocaml-dev/bookworm. As
such, upgrades may result in an unpack error. If this is an intentional
move, please add corresponding Breaks+Replaces.

Helmut

Bug#1041832: libsequoia-octopus-librnp: undeclared file conflict with thunerbird

[Helmut Grohne]

Package: libsequoia-octopus-librnp
Version: 1.4.1-1
Severity: serious

libsequoia-octopus-librnp installs /usr/lib/thunderbird/librnp.so, which
happens to also be installed by thunerbird from bullseye to
experimental. Since there currently are no Replaces nor Conflicts nor
diversions, unpacking both yields an unpack error.

Helmut

Bug#1041831: very-long-line-length-in-source-file should not check MacBinary file

[肖盛文]

Package: lintian
Version: 2.116.3
Severity: minor
X-Debbugs-Cc: atzli...@sina.com

Hi,
 MacBinary file should not check by very-long-line-length-in-source-file.

For exmaple:
https://sources.debian.org/src/libicns/0.8.1-3.1/samples/test3.bin/

file test3.bin

test3.bin:  MacBinary, busy, char. code 0x80, Sun Feb  9 19:14:58 2003, 
modified Sun Feb  9 19:14:58 2003, creator 'Mngl', type 'Icon' "Gnu_III", at 
0x80 41026 bytes resource  Apple HFS/HFS+ resource fork, map offset 0xa006, map 
length 0x3c, data length 0x9f06, nextResourceMap 0xe9084, fileRef 0x75, list 
offset 0x1c, name offset 0x32, 1 type, 0x69636e73 'icns' * 1 resource offset 0xa


Thanks!


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.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 lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.22
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.22
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-5
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1041830: very-long-line-length-in-source-file should not check Apple HFS/HFS+ resource fork file

[肖盛文]

Package: lintian
Version: 2.116.3
Severity: minor
X-Debbugs-Cc: atzli...@sina.com

Hi,
   The Apple HFS/HFS+ resource fork in source code should not check by 
very-long-line-length-in-source-file.

One example:

https://sources.debian.org/src/libicns/0.8.1-3.1/samples/test2.rsrc/

file test2.rsrc

test2.rsrc: Apple HFS/HFS+ resource fork, map offset 0x95fe, map length 0x3c, 
data length 0x94fe, nextResourceMap 0xe9084, fileRef 0x5a, list offset 0x1c, 
name offset 0x32, 1 type, 0x69636e73 'icns' * 1 resource offset 0xa



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

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.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 lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.22
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.22
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-5
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#691469: postifx apprently uses mboxo format, which irrecoverably corrupts mail

[Alban Browaeys]

notforwarded 691469
forwarded 691469 https://marc.info/?l=postfix-users=135129541824896=2
thanks


Update the broken gmane link to the postfix user mailing list.

TLDR; sum up status of this issue. Fix would probably be to switch to
maildir as default.
Still, this would require to know if any Debian  mail clients relies on
/var/spool/mail/ to be in the mbox format.


A short term option could be to document this mboxo spurious corruption
in the postfix README.

All in all this is not a data corruption that renders the emails
unreadeable.
It merely confuses the reader by changing the quote state of line
starting with ">From " if his mail client unquote the quoted From_
lines per mboxo specifications.




With mboxo, the email body:
>From 1
>From 2
>>From 3
becomes:
>From 1
>From 2
>>From 3

A simple upgrade path exists to mboxrd
>From 1
>>From 2
>>>From 3



That was deemed a mostly wontfix in 2012 at least for breaking backward
compatibilty. https://marc.info/?l=postfix-users=135145804930171=2 
(ie ok but an optin)
Though it makes no sense to me. A program that read mboxo can also read
mboxrd, the only difference is that with the mboxo the program will get
an inconsistent content (well corrupted content) while with mboxrd the
message could be restored to its intial state (by removoing one '>'
from each line starting with any number of '>' followed by "From ".

I hope the reason for this wontfix is that no analysis of the changes
in behavior was made.

This http://jdebp.info/FGA/mail-mbox-formats.html also conclude the
same, even if it makes no sense to me:
> Conversely, when an "mboxo" reader is used, less message corruption
will be observed in the final results if the messages were written by
an "mboxo" tool than if they were written by an "mboxrd" tool.

To me if an mboxo reader cannot unquote any better than an mboxrd
reader would.
The difference would be for a reader that does not unescape mbox quoted
"From " lines. Emails that had no lines starting with "From " but any
starting with any number of '>' followed by "From " would get an extra
'>'.

This still would require analysis and testing, as all actors tell taht
the behavior of mobox readers would change (but they do not give their
sources, so the work has to be done anew even if they are right).

I still do not see how mboxrd would make mboxo only readers badly
behave.

Though I believe this should be brought to the upstream mailing list, I
am for now trying to update this bug and remove the confusion out of
it.


Also it was told in 2019 that postfix does not use mboxo for local
transport (though it would require checking the code, the documentation
is an intent not a proof of the implementation)
https://marc.info/?l=postfix-users=156158209919449=2
"
List:   postfix-users
Subject:Re: mbox format?
From:   Viktor Dukhovni 
Date:   2019-06-26 20:47:23
Message-ID: 20190626204723.GK84864 () straasha ! imrryr ! org
[Download RAW message or body]

On Wed, Jun 26, 2019 at 04:27:06PM -0400, Wietse Venema wrote:

> Viktor Dukhovni:
>
> > On Wed, Jun 26, 2019 at 12:39:02PM -0700, Ronald F. Guilmette wrote:
> > 
> > > When Postfix hands a message to something... say a script invoked via
> > > some ~/.forward file... which one of these four formats will the message
> > > be in?
> > 
> > See: 
> > https://github.com/vdukhovni/postfix/blob/master/postfix/src/global/mail_copy.c#L235
> > 
> > So the answer is mboxo.
> 
> According to 'man 8 local', section 'EXTERNAL COMMAND DELIVERY':
>The local(8) daemon prepends a "From sender time_stamp" envelope header
>to each message, prepends an X-Original-To: header with  the  recipient
>address  as given to Postfix, prepends an optional Delivered-To: header
>with the final recipient  envelope  address,  prepends  a  Return-Path:
>header with the sender envelope address, and appends no empty line.

Oops, sorry, my answer was about delivery by local(8) directly to a mailbox,
not a command invoked via a pipe.
"


>From an inspection of the code the local daemon call
mail_copy: 
https://github.com/vdukhovni/postfix/blob/0abb45ca0732fc039e0f43b66ed441d283eb2565/postfix/src/local/mailbox.c#L212
the same as
pipe:https://github.com/vdukhovni/postfix/blob/e5e46ec03f77e0bf837b1ad00cba2663d74a92c3/postfix/src/global/pipe_command.c#L587


mail_copy which translate to mboxo if the MAIL_COPY_QUOTE flag is set.
This flag is included in the  MAIL_COPY_MBOX one.
https://github.com/vdukhovni/postfix/blob/0abb45ca0732fc039e0f43b66ed441d283eb2565/postfix/src/local/mailbox.c#L188


though the pipe only has MAIL_COPY_QUOTE if the pipe '>' flag is set in
the "flags=" pipe attribute.
https://github.com/vdukhovni/postfix/blob/master/postfix/src/pipe/pipe.c#L913
https://www.postfix.org/pipe.8.html




An alternative to mboxrd is client MIME quoted/printable for "From "
lines in the body
https://marc.info/?l=postfix-users=135161915820930=2 , though it
does  not fix all thes mboxo 

Bug#1041824: src:volume-el: Enable merge request on salsa

[Manphiz]

retitle 1041824 src:volume-el: disable d/watch and sync to latest head version
tag 1041824 patch
severity 1041824 minor
thanks

Apparently I misunderstood how "Control:" and cont...@bugs.debian.org
work.  Hopefully this time it should work.

Bug#1025917: rust-phf: please upgrade to v0.11

[Peter Green]

ok rust-selectors is now in testing and count_omega confirmed on
irc that he was ok with updating ruma-common. So I moved on to
actually preparing packages, building them and running their
autopkgtests.

phf-shared and phf-generator now have passing autopkgtests.
the others are still to be tested in the Debian packaged
environment.

On 22/07/2023 03:14, Peter Green wrote:

I just did a preliminary analysis of the reverse dependencies and it's looking 
pretty good.
(details below). Though I would like to wait until I have confirmation that 
rust-selectors
has migrated to testing.

Matthias, would you object to me updating rust-ruma-common to 0.11.x as part of 
this update?

rust-chrono-tz - fixed upstream in 0.6.3 (and also higher semver-breaking 
versions)
rust-chrono-tz-build - fixed upstream in 0.0.3 (and other higher versions but 
this is the one needed for chrono-tz)
rust-coreutils - no change needed, dependency already allows 0.11 and upstream 
already uses 0.11
rust-cssparser - no change needed, dependency already allows 0.11 and upstream 
already uses 0.11
rust-markup5ever - cargo test --all --all-targets --all-features passes after 
dependency bump.
rust-phf-codegen - presumablly meant to be upgraded in lockstep with phf
rust-phf-generator - presumablly meant to be upgraded in lockstep with phf
rust-phf-macros - presumablly meant to be upgraded in lockstep with phf
rust-phf-shared - presumablly meant to be upgraded in lockstep with phf
rust-rust-code-analysis - already broken and not in testing
rust-selectors - RUSTC_BOOTSTRAP=1 cargo test --all --all-targets 
--all-features passes after dependency bump, currently undergoing it's own 
semver transition
rust-string-cache - cargo test --all --all-targets --all-features passes after 
dependency bump.
rust-string-cache-codegen - cargo test --all --all-targets --all-features 
passes after dependency bump.
rust-tls-parser - RUSTC_BOOTSTRAP=1 cargo test --all --all-targets 
--all-features passes after dependency bump and some fixes for unrelated issues.
rust-tokio-postgres - dependency patch needs dropping.
rust-ruma-common - fixed upstream in 0.11.3 (which is semver-breaking but there 
are no rdeps, I asked count_omega on irc if updating was reasonable, if not 
then I suspect patching will also be an options)

Bug#1041824: src:volume-el: Enable merge request on salsa

[Manphiz]

retitle -1 src:volume-el: disable d/watch and sync to latest head version
tag -1 patch
severity -1 minor
thanks

Nicholas D Steeves  writes:

> Xiyue Deng  writes:
>
>> Source: volume-el
>> Severity: wishlist
>> X-Debbugs-Cc: none, Xiyue Deng 
>>
>> Dear maintainers,
>>
>> I have been trying to fix uscan error of Emacs addon packages.  When
>> working on volume-el, I found that the repo on salsa didn't accept merge
>> requests while most other packages did.  If it can open up merge request
>> access it would be great and I have some pending d/watch fixes.  Thanks
>> in advance!
>
> This may indicate that the Uploader wants patches rather than MRs, and
> at the very least may indicate the Uploader doesn't want to monitor
> Salsa for MRs.
>

Thanks for the explanation, Nicolas!  Totally make sense.

> You can use git-format-patch to prepare a patch series from your git
> history, and can attach those to a bug report here.
>

Done.

> To retitle this bug, but this as the first line in your reply (won't
> work with HTML email, of course):
>
> Control: retitle -1 src:volume-el: Useful subject of choice
> Control: tag -1 patch
>
> If you attach a patch, I recommend updating the metadata with that
> second line.
>

Done.  A little bit of explanation for the changes:

* Upstream never had any tags, so uscan will always fail, so disable
  d/watch for now.  This will result in an empty uscan results.

* Sync to latest head version, which basically just incorporated Sean's
  patch upstream so that we don't need to host the patch anymore.

Please see the patches attached.

> Cheers,
> Nicholas
>

-- 
Manphiz
>From 22464e7bee7a9ed7a18401109640a02502478fdb Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Tue, 19 Jan 2021 16:05:45 -0700
Subject: [PATCH 1/4] Pass correct number of arguments to
 define-obsolete-...-alias

Recent Emacs master branch fails to bytecompile volume.el due to this.
---
 volume.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/volume.el b/volume.el
index 35a2614..689bd4a 100644
--- a/volume.el
+++ b/volume.el
@@ -452,7 +452,7 @@ This corresponds to the `-D' option of amixer."
 
 (when (fboundp 'define-obsolete-variable-alias)
   (define-obsolete-variable-alias 'volume-amixer-control
-'volume-amixer-default-channel))
+'volume-amixer-default-channel "1.0"))
 
 (defvar volume-amixer-current-channel volume-amixer-default-channel
   "The name of the ALSA mixer channel to manipulate.")
@@ -654,7 +654,7 @@ Return either the new volume or nil, depending on the backend."
 
 (when (fboundp 'define-obsolete-function-alias)
   (define-obsolete-function-alias 'volume-channel-name
-'volume-channel-label))
+'volume-channel-label "1.0"))
 
 (defun volume-channels ()
   "Return the list of available channels."
-- 
2.39.2

>From 6ca047fcec9e9e8aeae380c1594cac2c392ce4ac Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Sun, 23 Jul 2023 05:08:05 -0700
Subject: [PATCH 2/4] Sync to current head (050d3e6).

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index cc07223..65a4e66 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+volume-el (1.0+git.20220904.050d3e6-1) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Sync to current head (050d3e6).
+
+ -- Xiyue Deng   Sun, 23 Jul 2023 05:06:07 -0700
+
 volume-el (1.0+git.20201002.afb75a5-3) unstable; urgency=medium
 
   * Pass correct number of arguments to define-obsolete-variable-alias.
-- 
2.39.2

>From 898fa2cdfbd3620f6a81e30f21f5f74cd21f5643 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Sun, 23 Jul 2023 05:09:17 -0700
Subject: [PATCH 3/4] Drop debian-changes.  Merged upstream.

---
 debian/changelog  |  1 +
 debian/patches/debian-changes | 37 ---
 debian/patches/series |  1 -
 3 files changed, 1 insertion(+), 38 deletions(-)
 delete mode 100644 debian/patches/debian-changes
 delete mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 65a4e66..8cc2f70 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ volume-el (1.0+git.20220904.050d3e6-1) UNRELEASED; urgency=medium
 
   * Team upload.
   * Sync to current head (050d3e6).
+  * Drop debian-changes.  Merged upstream.
 
  -- Xiyue Deng   Sun, 23 Jul 2023 05:06:07 -0700
 
diff --git a/debian/patches/debian-changes b/debian/patches/debian-changes
deleted file mode 100644
index c60df9d..000
--- a/debian/patches/debian-changes
+++ /dev/null
@@ -1,37 +0,0 @@
-The Debian packaging of volume-el is maintained in git, using the merging
-workflow described in dgit-maint-merge(7).  There isn't a patch
-queue that can be represented as a quilt series.
-
-A detailed breakdown of the changes is available from their
-canonical representation - git commits in the packaging repository.
-For example, to see the changes made by the Debian maintainer in
-the first upload of upstream version 1.2.3, 

Bug#884648: mate-panel occasionally crashes with segfault - upstream report

[correctmost]

There's an upstream bug report for the gtk_drag_finish crash:
https://github.com/mate-desktop/mate-panel/issues/1356

Bug#1041748: snapper: created gist with all the code

[Anchal Nigam]

Package: snapper
Version: 0.10.4-1
Followup-For: Bug #1041748

Dear Maintainer,

I created a gist with the relevant code/changes.

https://gist.github.com/imthenachoman/f722f6d08dfb404fed2a3b2d83263118


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

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

Versions of packages snapper depends on:
ii  libboost-thread1.74.0  1.74.0+ds1-21
ii  libc6  2.36-9+deb12u1
ii  libdbus-1-31.14.8-2~deb12u1
ii  libgcc-s1  12.2.0-14
ii  libjson-c5 0.16-2
ii  libmount1  2.38.1-5+b1
ii  libsnapper60.10.4-1
ii  libstdc++6 12.2.0-14
ii  libtinfo6  6.4-4

snapper recommends no packages.

snapper suggests no packages.

-- Configuration Files:
/etc/apt/apt.conf.d/80snapper changed [not included]
/etc/default/snapper changed [not included]

-- no debconf information

Bug#1041816: pyequihash: Uses obsolete Debian Python Modules Team as uploader/Vcs field

[Joost van Baal-Ilić]

On Sun, Jul 23, 2023 at 04:44:48PM -0400, Boyuan Yang wrote:
> Source: pyequihash
> Version: 0.2-2
> Severity: normal
> X-Debbugs-CC: joos...@debian.org
> Tags: sid
> 
> Dear Debian pyequihash package maintainer,
> 
> Your package is one of the few packages left that still uses Debian
> Python Modules Team ( 
> https://qa.debian.org/developer.php?email=python-modules-team%40lists.alioth.debian.org
>  )
> in package maintainer or uploader field. This has been long been obsolete
> according to past discussion on debian-python mailing list. Besides, your
> package has Vcs-* fields that are 404 not found. Please fix these issues
> in the next package upload.

Thanks for reporting this, will get to it.

(And thanks for your pyreadstat upload!)

Bye,

Joost

Bug#1034348: at: autopkgtest regression on arm64

[Joost van Baal-Ilić]

Hi,

Another happy at user here.

Jose M Calhariz  wrote:
> Hi, I believe my last update fixed the problem can someone double check?

That was at 3.2.5-2, right?  Closing this bug: afaik nobody has been able to
reproduce the issue.  Therefore better to close and see what happens next.

Please reopen if you feel this is not appropriate.

Thanks!  Bye,

Joost

Bug#999583: Rearranging window list causes segfaults - upstream report

[correctmost]

There's an upstream bug report with further debugging info:
https://github.com/mate-desktop/mate-panel/issues/1356

Bug#1041829: lf: lf is outdated

[debian]

Package: lf
Version: 28-1+b3
Severity: normal

Dear Maintainer,

The last lf version is 30 (since 20/04/2023, see 
https://github.com/gokcehan/lf/releases).
The Debian testing and sid version is 28.

Perhaps I am misunderstood something but is there any policy reason to not 
update the lf package?

Regards


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


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

lf depends on no packages.

Versions of packages lf recommends:
ii  ueberzug  18.1.9-4+b1

Versions of packages lf suggests:
ii  libimage-exiftool-perl [exiftool]  12.63+dfsg-2

-- no debconf information

Bug#967570: libdbusmenu: depends on deprecated GTK 2

[Simon McVittie]

On Tue, 04 Aug 2020 at 11:51:24 +0100, s...@debian.org wrote:
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

It seems there are only two blockers for disabling the GTK 2 parts
of libdbusmenu:

1. libayatana-appindicator still builds GTK 2 libraries that depend
   on libdbusmenu (#967567)
2. waybar has an apparently unnecessary build-dependency on
   libdbusmenu-gtk-dev (bug filed)

After those are both resolved, please drop the gir1.2-dbusmenu-gtk-0.4,
libdbusmenu-gtk-dev, libdbusmenu-gtk-doc, libdbusmenu-gtk4 binary packages
and any build-dependencies that were only needed for those (in particular
libgtk2.0-dev).

The GTK 3 parts of libdbusmenu are out of scope for this bug.

Thanks,
smcv

Bug#1041828: waybar: build-depends on libdbusmenu-gtk-dev, and indirectly on GTK 2

[Simon McVittie]

Source: waybar
Version: 0.9.20-1
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967570 by -1
Control: block 947713 by -1

waybar build-depends on libdbusmenu-gtk-dev, which in turn
depends on GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its
upstream developer and no longer receives any upstream maintenance.

The built binary package doesn't depend on GTK 2, which makes me think
that this build-dependency is probably unnecessary. If so, please
remove it, bringing us one step closer to being able to clean up this
technical debt.

The GTK 3 equivalent of libdbusmenu-gtk-dev is libdbusmenu-gtk3-dev.
It's OK to continue to build-depend on that.

Thanks,
smcv

Bug#1041824: src:volume-el: Enable merge request on salsa

[Nicholas D Steeves]

Xiyue Deng  writes:

> Source: volume-el
> Severity: wishlist
> X-Debbugs-Cc: none, Xiyue Deng 
>
> Dear maintainers,
>
> I have been trying to fix uscan error of Emacs addon packages.  When
> working on volume-el, I found that the repo on salsa didn't accept merge
> requests while most other packages did.  If it can open up merge request
> access it would be great and I have some pending d/watch fixes.  Thanks
> in advance!

This may indicate that the Uploader wants patches rather than MRs, and
at the very least may indicate the Uploader doesn't want to monitor
Salsa for MRs.

You can use git-format-patch to prepare a patch series from your git
history, and can attach those to a bug report here.

To retitle this bug, but this as the first line in your reply (won't
work with HTML email, of course):

Control: retitle -1 src:volume-el: Useful subject of choice
Control: tag -1 patch

If you attach a patch, I recommend updating the metadata with that
second line.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Otto Kekäläinen]

OK, package pending approval in NEW now:
https://ftp-master.debian.org/new/mariadb_1:10.11.4-0+deb12u1.html

Bug#967567: libayatana-appindicator: depends on deprecated GTK 2

[Simon McVittie]

On Thu, 29 Jun 2023 at 00:04:17 +0200, Bastian Germann wrote:
> Please consider applying the attached patch which will drop the unused gtk2 
> binary packages.

It looks as though this would break growl-for-linux (#967462):

smcv@coccia ~ % dak rm -R -n -b libayatana-appindicator1 
gir1.2-ayatanaappindicator-0.1 libayatana-appindicator-dev 
libayatana-appindicator0.1-cil libayatana-appindicator0.1-cil-dev
Will remove the following packages from unstable:

gir1.2-ayatanaappindicator-0.1 |   0.5.92-1 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x
libayatana-appindicator-dev |   0.5.92-1 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x
libayatana-appindicator0.1-cil |   0.5.92-1 | amd64, arm64, armel, armhf, i386, 
mipsel, ppc64el, s390x
libayatana-appindicator0.1-cil-dev |   0.5.92-1 | amd64, arm64, armel, armhf, 
i386, mipsel, ppc64el, s390x
libayatana-appindicator1 |   0.5.92-1 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x
...
# Broken Build-Depends:
growl-for-linux: libayatana-appindicator-dev

so #967462 will need to be fixed first.

growl-for-linux has no runtime dependency on these libraries, which
suggests that it might be possible to fix #967462 by removing its
(unused?) build-dependency.

smcv

Bug#967521: haskell-yi-frontend-pango: depends on deprecated GTK 2

[Simon McVittie]

On Tue, 04 Aug 2020 at 11:48:28 +0100, s...@debian.org wrote:
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

It seems nothing in Debian depends or build-depends on
haskell-yi-frontend-pango. Is it still useful? If not, can we remove it
from unstable before the Debian 13 release, to discourage the addition
of new software that depends on GTK 2?

Thanks,
smcv

Bug#967519: haskell-diagrams-gtk: depends on deprecated GTK 2

[Simon McVittie]

On Tue, 04 Aug 2020 at 11:48:20 +0100, s...@debian.org wrote:
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

It seems nothing in Debian depends or build-depends on
haskell-diagrams-gtk. Is it still useful? If not, can we remove it from
unstable before the Debian 13 release, to discourage the addition of
new software that depends on GTK 2?

Thanks,
smcv

Bug#967580: libgsf: depends on deprecated GTK 2

[Simon McVittie]

Control: tags -1 + patch

On Mon, 24 Jul 2023 at 01:25:49 +0100, Simon McVittie wrote:
> On Mon, 17 Jul 2023 at 15:36:41 +0200, Bastian Germann wrote:
> > The package builds fine without the build dependency libgtk2.0-dev.
> > Please just drop it with your next upload.
> 
> This doesn't seem to be the correct change: it has the side-effect of
> disabling code paths that rely on gdk-pixbuf-2.0, which is not obsolete.
> 
> Swapping the build-dependency from libgtk2.0-dev to libgdk-pixbuf-2.0-dev
> seems more correct. I'm testing that change now.

I have confirmed using diffoscope that the attached patch (also available
as https://salsa.debian.org/debian/libgsf/-/merge_requests/4) does not
alter the contents of the binary packages.

Removing the libgtk2.0-dev B-D without replacing it with
libgdk-pixbuf-2.0-dev *does* affect the contents of the binary packages,
so is probably undesired.

smcv
>From 940df51d1039fa7f70cb953a08d06ddbe0e9b89f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 24 Jul 2023 01:18:33 +0100
Subject: [PATCH] Build-depend on libgdk-pixbuf-2.0-dev instead of
 libgtk2.0-dev

GTK 2 is obsolete, but this package was relying on libgtk2.0-dev to
pull in gdk-pixbuf (which is not obsolete) as a dependency. Swap the
build-dependency to the library that is actually used.

Closes: #967580
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9073837..5607aae 100644
--- a/debian/control
+++ b/debian/control
@@ -7,10 +7,10 @@ Build-Depends: debhelper-compat (= 13), dh-buildinfo
   ,gtk-doc-tools
   ,intltool
   ,libbz2-dev
+  ,libgdk-pixbuf-2.0-dev
   ,libgirepository1.0-dev
   ,libglib2.0-dev
   ,libglib2.0-doc
-  ,libgtk2.0-dev
   ,libxml2-dev
   ,unzip 
   ,zlib1g-dev
-- 
2.40.1

Bug#1041827: Check for mkimage in u-boot-install-sunxi no longer needed

[harry88]

Package: u-boot-sunxi
Version: 2023.07+dfsg-1
Severity: normal
Tags: patch

Hi Vagrant,

Following commit 4f2f06b8 ("Drop support for using a FIT generator..."),
the u-boot-install-sunxi script no longer uses mkimage, so the check for
it can be safely removed, as in the suggested patch below.

(This is one of the small improvements I mentioned previously in
bug#979688 and meant to file separately.)

Thanks very much for looking after U-Boot for Debian all this time.

Best wishes,
Harold.


diff --git a/debian/bin/u-boot-install-sunxi
b/debian/bin/u-boot-install-sunxi
index a10fda96ed..b3af2c0b80 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -65,11 +65,6 @@ case "$1" in
exit 1;;
 esac

-if [ -z "$(which mkimage)" ]; then
-   echo >&2 "$0: mkimage: command not found. Please install u-boot-tools."
-   exit 1
-fi
-
 DEV="$1"
 if [ -z "$DEV" ] || ! shift || [ -n "$*" ]; then
 echo >&2 "Usage: $0 /dev/your-sd-or-mmc-or-image"

Bug#967580: libgsf: depends on deprecated GTK 2

[Simon McVittie]

On Mon, 17 Jul 2023 at 15:36:41 +0200, Bastian Germann wrote:
> The package builds fine without the build dependency libgtk2.0-dev.
> Please just drop it with your next upload.

This doesn't seem to be the correct change: it has the side-effect of
disabling code paths that rely on gdk-pixbuf-2.0, which is not obsolete.

Swapping the build-dependency from libgtk2.0-dev to libgdk-pixbuf-2.0-dev
seems more correct. I'm testing that change now.

smcv

Bug#1040053: gjs: autopkgtest regression: free(): invalid pointer

[Jeremy Bícha]

We can close this bug since the autopkgtests are passing now with gjs
1.76.2-3. But I am surprised that this RC bug did not block the
migration of gjs 1.76.2-3 to Testing today.

Thank you,
Jeremy Bicha

Bug#1041791: darkradiant: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Control: tags -1 + patch

On Sun, 23 Jul 2023 at 18:06:28 +0100, Simon McVittie wrote:
> From a quick look at the binary package dependencies and source code,
> it looks as though darkradiant is a GTK 3 application already, and the only
> reference to gtkmm seems to be in
> plugins/dm.objectives/util/TwoColumnTextCombo.h, which is not compiled
> when using Debian toolchains, only when using MSVC or Xcode. If that's the
> case, then this build-dependency can probably just be dropped.

That was almost true: the darkradiant packaging was also relying on
libgtkmm-2.4-dev to pull in its dependencies libglib2.0-dev and
libsigc++-2.0-dev, which *are* needed.

Adding B-D on libglib2.0-dev and libsigc++-2.0-dev allows libgtkmm-2.4-dev
to be dropped. Please consider the attached patches, also available at
.

(I have successfully built this, but I have not otherwise tested the
resulting binaries.)

smcv
>From e29948a72c14c43eeb2dbe4b964821be9254005f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 23 Jul 2023 18:19:36 +0100
Subject: [PATCH 1/2] Explicitly depend on libglib2.0-dev, libsigc++-2.0-dev

darkradiant explicitly checks for these, so they should be direct
dependencies. Adding them will allow the gtkmm2.4 dependency to be
dropped.
---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 2b6ab69..dcbad2a 100644
--- a/debian/control
+++ b/debian/control
@@ -17,10 +17,12 @@ Build-Depends: asciidoctor,
libeigen3-dev,
libftgl-dev,
libglew-dev,
+   libglib2.0-dev,
libgtkmm-2.4-dev,
libjpeg-dev,
libopenal-dev,
libpython3-dev,
+   libsigc++-2.0-dev,
libvorbis-dev,
libwxgtk3.2-dev,
libxml2-dev,
-- 
2.40.1

>From 2380dee34b4474ed9cd0e42c91f7d0943419fc09 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 23 Jul 2023 18:03:41 +0100
Subject: [PATCH 2/2] Remove unnecessary B-D libgtkmm-2.4-dev

This is only used in plugins/dm.objectives/util/TwoColumnTextCombo.h,
which is not compiled with Debian toolchains (only with MSVC or Xcode).

Closes: #1041791
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index dcbad2a..9ef4707 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,6 @@ Build-Depends: asciidoctor,
libftgl-dev,
libglew-dev,
libglib2.0-dev,
-   libgtkmm-2.4-dev,
libjpeg-dev,
libopenal-dev,
libpython3-dev,
-- 
2.40.1

Bug#1041826: nala: Running nala history as an unprivileged user causes excessive resource consumption

[Johannes Silverfox]

Package: nala
Version: 0.12.2
Severity: normal
X-Debbugs-Cc: johannes_silver...@tutanota.com

Dear Maintainer,

When running nala history as an unprivileged user, the process appears to hang 
and uses excessive CPU and memory resources.  In my case, while running this on 
a Raspberry Pi, it eventually exhausted physical memory and caused several 
processes to crash.

The direct cause of this is that the program doesn't know how to handle a case 
where it doesn't have permissions to read /var/lib/nala/history.json, as shown 
in this strace sample:

openat(AT_FDCWD, "/var/lib/nala/history.json", O_RDONLY|O_CLOEXEC) = -1 EACCES 
(Permission denied)
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c15c9000  
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c14c9000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c13c9000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c12c9000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c11c9000

These mmap calls continue infinitely, sequentially running through memory 
locations until a SIGINT is sent, upon which python returns

Error in sys.excepthook:
  
Traceback (most recent call last):  
  
  File "/usr/lib/python3/dist-packages/typer/main.py", line 72, in except_hook
rich_tb = Traceback.from_exception( 
  
 
  ^
  File "/usr/lib/python3/dist-packages/rich/traceback.py", line 335, in 
from_exception
rich_traceback = cls.extract(
  
  File "/usr/lib/python3/dist-packages/rich/traceback.py", line 448, in extract
locals={  
   ^  
  File "/usr/lib/python3/dist-packages/rich/traceback.py", line 449, in 

key: pretty.traverse(
 
  File "/usr/lib/python3/dist-packages/rich/pretty.py", line 887, in traverse   
 
node = _traverse(_object, root=True)
   ^
  File "/usr/lib/python3/dist-packages/rich/pretty.py", line 637, in _traverse  
   
def _traverse(obj: Any, root: bool = False, depth: int = 0) -> Node:

After KeyBoardInterrupt, the error messages conclude with
PermissionError: [Errno 13] Permission denied: '/var/lib/nala/history.json'

I was also able to reproduce this on amd64.

The program should be able to handle this issue by erroring out with something 
like "Cannot read /var/lib/nala/history.json" and terminating immediately.

(If possible, please close bug #1041821 as a duplicate.)

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

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

Versions of packages nala depends on:
ii  apt2.6.1
ii  python33.11.2-1+b1
ii  python3-anyio  3.6.2-1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-httpx  0.23.3-1
ii  python3-pexpect4.8.0-4
ii  python3-rich   13.3.1-1
ii  python3-tomli  2.0.1-2
ii  python3-typer  0.7.0-1
ii  python3-typing-extensions  4.4.0-1

Versions of packages nala recommends:
ii  python3-socksio  1.0.0-2

nala suggests no packages.

-- no debconf information

Bug#1041825: libopenraw: new upstream release 0.3.6

[Simon McVittie]

Source: libopenraw
Version: 0.1.2-0.2
Severity: wishlist
X-Debbugs-Cc: tumb...@packages.debian.org
Control: affects -1 + tumbler-plugins-extra

While investigating whether libopenraw's dependency on GTK 2 can be
removed (which it can, see #967585), I noticed that the version of
libopenraw in Debian is from 2018 and there have been 12 new upstream
releases since then.

With this being file parsing code, I'm concerned that this might mean
unfixed security issues (although I don't see any obvious security fixes
in the upstream NEWS).

tumbler-plugins-extra seems to be the only package in Debian that makes
use of libopenraw (gegl also has a Build-Depends on it, but it seems to
be unused there) so the maintainers of tumbler might be interested in
salvaging libopenraw to have a high-quality version to depend on if its
current Debian maintainer is no longer active?

smcv

Bug#1036240: bullseye-pu: package kscreenlocker/5.20.5-1+deb11u1

[Patrick Franz]

Hi Jonathan,

On Sun, 23 Jul 2023 13:45:57 +0100 Jonathan Wiltshire  
wrote:
> Control: tag -1 confirmed
> 
> On Wed, May 17, 2023 at 10:56:53PM +0200, Patrick Franz wrote:
> > When trying to unlock the screen and entering a wrong password,
> > it can lead to an endless loop when using the PAM module.
> > This fix applies a patch from upstream that fixes the
> > behaviour.
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035732
> 
> Please go ahead.
> 
> Thanks,

Package has been uploaded.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#967585: libopenraw: depends on deprecated GTK 2

[Simon McVittie]

On Tue, 04 Aug 2020 at 11:52:20 +0100, s...@debian.org wrote:
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

In fact this build-dependency appears to be useles: libopenraw doesn't
need GTK, it only builds a gdk-pixbuf plugin. Please consider the attached
patch, also available from
.

(libopenraw does use GTK's pkg-config module to find the directory to
install its plugin into if gdk-pixbuf is old, but Debian's gdk-pixbuf
is not that old, so that code doesn't run.)

I've verified using diffoscope that this change has no effect on the
resulting binary packages. It significantly reduces the number of
build-dependencies, so it would be worth applying even if GTK 2 wasn't
obsolete and unmaintained.

smcv

Bug#1041824: src:volume-el: Enable merge request on salsa

[Xiyue Deng]

Source: volume-el
Severity: wishlist
X-Debbugs-Cc: none, Xiyue Deng 

Dear maintainers,

I have been trying to fix uscan error of Emacs addon packages.  When
working on volume-el, I found that the repo on salsa didn't accept merge
requests while most other packages did.  If it can open up merge request
access it would be great and I have some pending d/watch fixes.  Thanks
in advance!


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

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

Bug#1041823: python-typing-extensions: package maintenance

[Sandro Tosi]

Source: python-typing-extensions
Severity: normal
X-Debbugs-Cc: mo...@debian.org

Hello,
the last time this package received a maintainer upload was in Oct 2021, at
version  3.10.0.2. Since then, only team uploads have happend, and now upstream
released 4.7.1 .

I maintian a downstream pacakge, fastapi, which now needs 4.7.1 to get upgraded
to its last upstream release. but there are tens of other packages depending on
typing_extensions that may benefit from uploads happening more frequently.

I'm wondering if typing_extensions maintenance should change in a more explicit
way than just let it me in DPT and have team members casually upload it when
needed.

Regards,
Sandro


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

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

Bug#1041809: groff-base: man pages cause troff warning "cannot select font 'C'"

[Colin Watson]

On Sun, Jul 23, 2023 at 11:25:37PM +0100, Colin Watson wrote:
> https://gitlab.com/man-db/man-db/-/issues/26, and in particular
> https://gitlab.com/man-db/man-db/uploads/e7434daee5d71e37ec4cbcce892abdc5/0001-Improve-lexgrog-1-portability.patch,
> might be a useful reference here.

Oh, and also note the follow-up
https://gitlab.com/man-db/man-db/-/issues/27.

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

Bug#1041809: groff-base: man pages cause troff warning "cannot select font 'C'"

[Colin Watson]

Control: reassign -1 python3-docutils
Control: affects -1 groff-base
Control: retitle -1 rst2man: uses non-portable 'C' font, causing warnings from 
groff >= 1.23.0

On Sun, Jul 23, 2023 at 07:09:51PM +, Peter Wienemann wrote:
> I see troff warnings "cannot select font 'C'" for several man pages. Here are 
> the corresponding Lintian warnings for two examples from different packages:
> 
> W: python3-lark: groff-message troff::1032: warning: cannot 
> select font 'C' [usr/share/man/man7/lark.7.gz:28]
> [more similar lines]
> 
> and
> 
> W: charliecloud-builders: groff-message troff::1066: warning: 
> cannot select font 'C' [usr/share/man/man1/ch-image.1.gz:15]
> [more similar lines]

No groff output device has a C font, so this is very probably a typo, or
perhaps a reference to some other *roff system.  In this case, these
pages all seem to be generated by "rst2man" from the python3-docutils
package, so I'm reassigning this there.

https://gitlab.com/man-db/man-db/-/issues/26, and in particular
https://gitlab.com/man-db/man-db/uploads/e7434daee5d71e37ec4cbcce892abdc5/0001-Improve-lexgrog-1-portability.patch,
might be a useful reference here.  This sort of relatively complicated
thing is ideal for fixing properly in manual page generators so that it
only has to be done in a much smaller number of places.

> This issue looks similar to
> 
> https://bugs.debian.org/1040975

The warning was made visible by the same upstream change, yes.  However,
the CW font at least exists in one groff device (dvi); the C font does
not.  As a result, I'm somewhat less inclined to work around it.

Thanks,

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

Bug#1040467: file: /sys/firmware/acpi/bgrt/image strange behaviour

[frank]

Package: file
Followup-For: Bug #1040467

Indeed if I only read 4096 bytes, I get:
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 5.5761e-05 s, 73.5 MB/s
/dev/stdin: data

If I read the entire file size, except for the last byte, I still get:
$ dd if=/tmp/image bs=$(( $(stat --format=%s /tmp/image) - 1)) count=1 | file -
1+0 records in
1+0 records out
565109 bytes (565 kB, 552 KiB) copied, 0.00157071 s, 360 MB/s
/dev/stdin: data

Only when I read the whole file, then I get:
$ dd if=/tmp/image bs=$(stat --format=%s /tmp/image) count=1 | file -
1+0 records in
1+0 records out
565110 bytes (565 kB, 552 KiB) copied, 0.00156589 s, 361 MB/s
/dev/stdin: PC bitmap, Windows 3.x format, 434 x 432 x 24, image size 565056, 
cbSize 565110, bits offset 54

So it appears the very last byte is still important for correct detection of 
the image file through `file` and 4096 bytes will never be enough in this case.

For unknown reasons, this workaround does not work, because nbytes=4096 is 
still being used:
$ 

Bug#1037349: pulseaudio: PulseAudio daemon does not start after upgrade to Debian 12

[Alois Schlögl]

I observe the same issue on an Lenovo L480 laptop. After upgrading from 
Debian11 to Debian12, audio/sound did not work anymore.

Running these commands

        systemctl --user stop pulseaudio.socket
    systemctl --user stop pulseaudio.service
    systemctl --user start pulseaudio.socket
    systemctl --user start pulseaudio.service

enables the the audio system. But the settings do not survive a reboot.

I'm using the Mate desktop.

Let me know if you need anymore information.

Cheers,
   Alois

Bug#1040355: ntpdate: obsolete conffiles

[Richard Laager]

Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117

Feedback welcome!

1. I brought back some of the (manual) postrm bits for the ntp &
   ntpdate packages.  This was something I should have preserved when
   making the transitional packages.

   ntpsec.service has ntp.service as an alias, so we do not mask
   ntp.service.

   I did not bring back the apparmor bits, as the apparmor profile
   still exists in the ntpsec package.

   I did not bring back the /etc/network/if-up.d/ntpdate removal in
   ntpdate, as that was conditionalized on 1:4.2.8p12+dfsg-2~, so that
   transition was completed in buster.

2. sntp needs to cleanup /var/lib/sntp because of /var/lib/sntp/kod.
   This seems to be a pre-existing bug in the ntp package.  (Though, if
   it wasn't, I still would have missed it with everything else.)

3. The obsolete ntp & ntpdate conffiles need to be cleaned up.  For
   most, this is accomplished by listing them in PACKAGE.conffiles with
   the "remove-on-upgrade" flag.

4. For /etc/default/ntp and /etc/ntp.conf, which are handled special in
   ntpsec.preinst, I'm not sure if the "remove-on-upgrade" functionality
   would even work; it seems like it would remove them too soon.

   The dpkg-maintscript-helper rm_conffile support seemed problematic
   too...

   If I run that in the ntpsec scripts (so I can get it to happen after
   the special handling), I don't think it would work, as it checks that
   the package in question owns the files, and in the ntp -> ntpsec
   case, it does not.

   If I run that in the ntp scripts, then it would run too early, so
   I'd need to make ntpsec.preinst look at some backup file.  I'm not
   sure how much ordering is guaranteed between the ntp and ntpsec
   maintainer scripts, so I might have to look at both the .dpkg-backup
   and .dpkg-bak versions.  It's also not clear to me whether I should
   care about the original name.

   Given that this already released in this state and I'm going to need
   a stable release update to fix this, it seems I should be
   conservative.  Policy 10.7.3 says I "should" remove these during
   upgrade, not that I "must".

   Ultimately, I am leaving these two files alone during the upgrade
   and removing them on purge of the ntp transitional package.

--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036443: ntpsec: leftover files on purge

[Richard Laager]

Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117

Feedback welcome!

1. I brought back some of the (manual) postrm bits for the ntp &
   ntpdate packages.  This was something I should have preserved when
   making the transitional packages.

   ntpsec.service has ntp.service as an alias, so we do not mask
   ntp.service.

   I did not bring back the apparmor bits, as the apparmor profile
   still exists in the ntpsec package.

   I did not bring back the /etc/network/if-up.d/ntpdate removal in
   ntpdate, as that was conditionalized on 1:4.2.8p12+dfsg-2~, so that
   transition was completed in buster.

2. sntp needs to cleanup /var/lib/sntp because of /var/lib/sntp/kod.
   This seems to be a pre-existing bug in the ntp package.  (Though, if
   it wasn't, I still would have missed it with everything else.)

3. The obsolete ntp & ntpdate conffiles need to be cleaned up.  For
   most, this is accomplished by listing them in PACKAGE.conffiles with
   the "remove-on-upgrade" flag.

4. For /etc/default/ntp and /etc/ntp.conf, which are handled special in
   ntpsec.preinst, I'm not sure if the "remove-on-upgrade" functionality
   would even work; it seems like it would remove them too soon.

   The dpkg-maintscript-helper rm_conffile support seemed problematic
   too...

   If I run that in the ntpsec scripts (so I can get it to happen after
   the special handling), I don't think it would work, as it checks that
   the package in question owns the files, and in the ntp -> ntpsec
   case, it does not.

   If I run that in the ntp scripts, then it would run too early, so
   I'd need to make ntpsec.preinst look at some backup file.  I'm not
   sure how much ordering is guaranteed between the ntp and ntpsec
   maintainer scripts, so I might have to look at both the .dpkg-backup
   and .dpkg-bak versions.  It's also not clear to me whether I should
   care about the original name.

   Given that this already released in this state and I'm going to need
   a stable release update to fix this, it seems I should be
   conservative.  Policy 10.7.3 says I "should" remove these during
   upgrade, not that I "must".

   Ultimately, I am leaving these two files alone during the upgrade
   and removing them on purge of the ntp transitional package.

--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040354: ntp: obsolete conffiles

[Richard Laager]

Fix pending as:
https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117

Feedback welcome!

1. I brought back some of the (manual) postrm bits for the ntp &
   ntpdate packages.  This was something I should have preserved when
   making the transitional packages.

   ntpsec.service has ntp.service as an alias, so we do not mask
   ntp.service.

   I did not bring back the apparmor bits, as the apparmor profile
   still exists in the ntpsec package.

   I did not bring back the /etc/network/if-up.d/ntpdate removal in
   ntpdate, as that was conditionalized on 1:4.2.8p12+dfsg-2~, so that
   transition was completed in buster.

2. sntp needs to cleanup /var/lib/sntp because of /var/lib/sntp/kod.
   This seems to be a pre-existing bug in the ntp package.  (Though, if
   it wasn't, I still would have missed it with everything else.)

3. The obsolete ntp & ntpdate conffiles need to be cleaned up.  For
   most, this is accomplished by listing them in PACKAGE.conffiles with
   the "remove-on-upgrade" flag.

4. For /etc/default/ntp and /etc/ntp.conf, which are handled special in
   ntpsec.preinst, I'm not sure if the "remove-on-upgrade" functionality
   would even work; it seems like it would remove them too soon.

   The dpkg-maintscript-helper rm_conffile support seemed problematic
   too...

   If I run that in the ntpsec scripts (so I can get it to happen after
   the special handling), I don't think it would work, as it checks that
   the package in question owns the files, and in the ntp -> ntpsec
   case, it does not.

   If I run that in the ntp scripts, then it would run too early, so
   I'd need to make ntpsec.preinst look at some backup file.  I'm not
   sure how much ordering is guaranteed between the ntp and ntpsec
   maintainer scripts, so I might have to look at both the .dpkg-backup
   and .dpkg-bak versions.  It's also not clear to me whether I should
   care about the original name.

   Given that this already released in this state and I'm going to need
   a stable release update to fix this, it seems I should be
   conservative.  Policy 10.7.3 says I "should" remove these during
   upgrade, not that I "must".

   Ultimately, I am leaving these two files alone during the upgrade
   and removing them on purge of the ntp transitional package.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041821: Running nala history as an unprivileged user causes excessive resource consumption

[Johannes Silverfox]

Package: nalaVersion: 0.12.2Severity: normal
Dear Maintainer,

When running nala history as an unprivileged user, the process appears to hang 
and uses excessive CPU and memory resources.  In my case, while running this on 
a Raspberry Pi, it eventually exhausted physical memory and caused several 
processes to crash.

The direct cause of this is that the program doesn't know how to handle a case 
where it doesn't have permissions to read /var/lib/nala/history.json, as shown 
in this strace sample:

openat(AT_FDCWD, "/var/lib/nala/history.json", O_RDONLY|O_CLOEXEC) = -1 EACCES 
(Permission denied)
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c15c9000  
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c14c9000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c13c9000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c12c9000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f93c11c9000

These mmap calls continue infinitely, sequentially running through memory 
locations until a SIGINT is sent, upon which python returns

Error in sys.excepthook:
  
Traceback (most recent call last):  
  
  File "/usr/lib/python3/dist-packages/typer/main.py", line 72, in except_hook
    rich_tb = Traceback.from_exception( 
  
 
  ^
  File "/usr/lib/python3/dist-packages/rich/traceback.py", line 335, in 
from_exception
debian@e911b6bb987c:~$ rich_traceback = cls.extract(
  
  File "/usr/lib/python3/dist-packages/rich/traceback.py", line 448, in extract
    locals={  
   ^  
  File "/usr/lib/python3/dist-packages/rich/traceback.py", line 449, in 

    key: pretty.traverse(
 
  File "/usr/lib/python3/dist-packages/rich/pretty.py", line 887, in traverse   
 
    node = _traverse(_object, root=True)
   ^
  File "/usr/lib/python3/dist-packages/rich/pretty.py", line 637, in _traverse  
   
    def _traverse(obj: Any, root: bool = False, depth: int = 0) -> Node:

After KeyBoardInterrupt, the error messages conclude with
PermissionError: [Errno 13] Permission denied: '/var/lib/nala/history.json'

I was also able to reproduce this on amd64.

The program should be able to handle this issue by erroring out with something 
like "Cannot read /var/lib/nala/history.json" and terminating immediately.

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

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

Versions of packages nala depends on:
ii  apt    2.6.1
ii  python3    3.11.2-1+b1
ii  python3-anyio  3.6.2-1
ii  python3-apt    2.6.0
ii  python3-debian 0.1.49
ii  python3-httpx  0.23.3-1
ii  python3-pexpect    4.8.0-4
ii  python3-rich   13.3.1-1
ii  python3-tomli  2.0.1-2
ii  python3-typer  0.7.0-1
ii  python3-typing-extensions  4.4.0-1

Versions of packages nala recommends:
ii  python3-socksio  1.0.0-2

nala suggests no packages.

-- no debconf information

Bug#1041441: Bug#1018206: luatex loses or changes text when discretionaries with priorities are used

[Preuße]

On 19.07.2023 00:19, Preuße...@buxtehude.debian.org, Hilmar wrote:

Control: clone 1018206 -1
Control: reopen -1


Hi Peter,

Oh my gosh.  Losing formatting would indeed be not severe.  Distorting 
contents is IS severe, especially if this goes unnoticed.  Heaven 
knows how much text has already been and will be silently changed in 
all the years of Debian 12.  Therefore, a kind request: please push it 
into the next update of Debian (12.1) or at least one of the next 
updates.



Clone this bug to create a fix for bookworm.

I've uploaded the revision -8 to unstable, which is a prereq for having 
a fix in bookworm. I've uploaded packages for bookworm to here [1]. 
Would be nice if you could patch your system and test them. At least 
your example is solved.


Hilmar

[1] https://freeshell.de/~hille42/1041441/
--
testmail


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041820: RFS: zynaddsubfx/3.0.6-6 [RC] [Team] -- Realtime software synthesizer for Linux

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : zynaddsubfx
   Version  : 3.0.6-6
   Upstream contact : Nasca Otavian Paul 
 * URL  : https://zynaddsubfx.sourceforge.io
 * License  : ISC, Expat, GPL-2+, GPL-3+, LGPL-2.1+, bitstream-vera, 
ZLIB
 * Vcs  : https://salsa.debian.org/multimedia-team/zynaddsubfx
   Section  : sound

The source builds the following binary packages:

  zynaddsubfx - Realtime software synthesizer for Linux
  zynaddsubfx-data - Realtime software synthesizer for Linux (data)
  zynaddsubfx-dssi - dssi plugin of zynaddsubfx
  zynaddsubfx-lv2 - lv2 plugin of zynaddsubfx
  zynaddsubfx-vst - vst plugin of zynaddsubfx

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zynaddsubfx/zynaddsubfx_3.0.6-6.dsc

Changes since the last upload:

 zynaddsubfx (3.0.6-6) unstable; urgency=medium
 .
   * Team upload.
   * Add fix-gcc-13.patch to fix gcc-13 build issue. (Closes: 1037910)
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#967575: libg3d: depends on deprecated GTK 2

[Simon McVittie]

On Tue, 04 Aug 2020 at 11:51:42 +0100, s...@debian.org wrote:
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

It looks as though libg3d actually only needs gdk-pixbuf (which is a
separate source package), so please consider the attached patch.

It builds successfully, but I'm intentionally not tagging this +patch
because I haven't confirmed that libg3d's gdk-pixbuf plugin still works
correctly with this change - please test carefully!

Thanks,
smcv
>From 6a79b1642e575382ca6ab31c2c4a452564ebc0ed Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 23 Jul 2023 20:48:11 +0100
Subject: [PATCH] Avoid build-dependency on obsolete GTK 2

Instead, use gdk-pixbuf directly, since that's what this package
actually needs.

Closes: #967575
---
 debian/control|  2 +-
 ...ly-instead-of-via-the-obsolete-GTK-2.patch | 61 +++
 debian/patches/series |  1 +
 3 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/Use-gdk-pixbuf-directly-instead-of-via-the-obsolete-GTK-2.patch

diff --git a/debian/control b/debian/control
index 609d9ea..2c42fe2 100644
--- a/debian/control
+++ b/debian/control
@@ -12,9 +12,9 @@ Build-Depends:
  debhelper-compat (= 13),
  flex,
  gtk-doc-tools,
+ libgdk-pixbuf-2.0-dev,
  libglib2.0-dev,
  libgsf-1-dev | libgsf-gnome-1-dev,
- libgtk2.0-dev,
  libtool,
  libxml2-dev,
  libz-dev,
diff --git a/debian/patches/Use-gdk-pixbuf-directly-instead-of-via-the-obsolete-GTK-2.patch b/debian/patches/Use-gdk-pixbuf-directly-instead-of-via-the-obsolete-GTK-2.patch
new file mode 100644
index 000..a68bc21
--- /dev/null
+++ b/debian/patches/Use-gdk-pixbuf-directly-instead-of-via-the-obsolete-GTK-2.patch
@@ -0,0 +1,61 @@
+From: Simon McVittie 
+Date: Sun, 23 Jul 2023 20:45:58 +0100
+Subject: Use gdk-pixbuf directly, instead of via the obsolete GTK 2
+
+Bug-Debian: https://bugs.debian.org/967575
+---
+ configure.in  | 10 ++
+ plugins/image/img_gdkpixbuf.c | 12 
+ 2 files changed, 2 insertions(+), 20 deletions(-)
+
+diff --git a/configure.in b/configure.in
+index 79fc9da..0ec37bb 100644
+--- a/configure.in
 b/configure.in
+@@ -48,14 +48,8 @@ GTK_DOC_CHECK
+ AM_PATH_GLIB_2_0(2.0.0,,AC_MSG_ERROR([glib >= 2.0 is needed]), gmodule gobject)
+ 
+ # gdk-pixbuf
+-AM_PATH_GTK_2_0(2.0.0, have_gtk2=true)
+-if test "x$have_gtk2" = "xtrue" ; then
+-GDKPIXBUF_CFLAGS=$GTK_CFLAGS
+-GDKPIXBUF_LIBS=$GTK_LIBS
+-AC_SUBST(GDKPIXBUF_CFLAGS)
+-AC_SUBST(GDKPIXBUF_LIBS)
+-fi
+-AM_CONDITIONAL([HAVE_GDKPIXBUF], test "x$have_gtk2" = "xtrue")
++PKG_CHECK_MODULES([GDKPIXBUF], [gdk-pixbuf-2.0], [have_gdkpixbuf=true], [have_gdkpixbuf=false])
++AM_CONDITIONAL([HAVE_GDKPIXBUF], test "x$have_gdkpixbuf" = "xtrue")
+ 
+ # libxml2
+ PKG_CHECK_MODULES(XML, libxml-2.0 >= 2.0.0, [have_libxml2=true], [have_libxml2=false])
+diff --git a/plugins/image/img_gdkpixbuf.c b/plugins/image/img_gdkpixbuf.c
+index 5a4984d..90b2178 100644
+--- a/plugins/image/img_gdkpixbuf.c
 b/plugins/image/img_gdkpixbuf.c
+@@ -24,7 +24,6 @@
+ #include 
+ #include 
+ 
+-#include 
+ #include 
+ 
+ #include 
+@@ -141,17 +140,6 @@ gchar **plugin_extensions(G3DContext *context)
+ 
+ static gboolean gdkpixbuf_init(void)
+ {
+-	static gboolean init = TRUE;
+-
+-	if(init) {
+-		/* initialize GDK */
+-		/* FIXME: problem if already initialized with gtk_init()? */
+-		gint argc = 0;
+-		if(!gdk_init_check(, NULL))
+-			return FALSE;
+-		init = FALSE;
+-	}
+-	return TRUE;
+ }
+ 
+ static gboolean gdkpixbuf_postprocess(GdkPixbuf *pixbuf, G3DImage *image,
diff --git a/debian/patches/series b/debian/patches/series
index 6f52c0c..97c48c2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -11,3 +11,4 @@ Fix-build-with-automake-1.11.3.patch
 Fix-implicit-declarations-of-functions.patch
 Fix-spelling-errors.patch
 Switch-libxml2-lookup-from-xml2-config-to-pkg-config.patch
+Use-gdk-pixbuf-directly-instead-of-via-the-obsolete-GTK-2.patch
-- 
2.40.1

Bug#1041819: mysql-8.0: CVE-2023-22058 CVE-2023-22057 CVE-2023-22056 CVE-2023-22054 CVE-2023-22053 CVE-2023-22048 CVE-2023-22046 CVE-2023-22038 CVE-2023-22033 CVE-2023-22008 CVE-2023-22007 CVE-2023-22

[Salvatore Bonaccorso]

Source: mysql-8.0
Version: 8.0.33-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for mysql-8.0.

CVE-2023-22058[0]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: DDL).  Supported versions that are affected are
| 8.0.33 and prior. Difficult to exploit vulnerability allows high
| privileged attacker with network access via multiple protocols to
| compromise MySQL Server.  Successful attacks of this vulnerability
| can result in unauthorized ability to cause a hang or frequently
| repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score
| 4.4 (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-22057[1]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: Replication).  Supported versions that are
| affected are 8.0.33 and prior. Easily exploitable vulnerability
| allows high privileged attacker with network access via multiple
| protocols to compromise MySQL Server.  Successful attacks of this
| vulnerability can result in unauthorized ability to cause a hang or
| frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1
| Base Score 4.9 (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-22056[2]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: Optimizer).  Supported versions that are
| affected are 8.0.33 and prior. Easily exploitable vulnerability
| allows high privileged attacker with network access via multiple
| protocols to compromise MySQL Server.  Successful attacks of this
| vulnerability can result in unauthorized ability to cause a hang or
| frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1
| Base Score 4.9 (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-22054[3]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: Optimizer).  Supported versions that are
| affected are 8.0.33 and prior. Easily exploitable vulnerability
| allows high privileged attacker with network access via multiple
| protocols to compromise MySQL Server.  Successful attacks of this
| vulnerability can result in unauthorized ability to cause a hang or
| frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1
| Base Score 4.9 (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-22053[4]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Client programs).  Supported versions that are affected
| are 5.7.42 and prior and  8.0.33 and prior. Difficult to exploit
| vulnerability allows low privileged attacker with network access via
| multiple protocols to compromise MySQL Server.  Successful attacks
| of this vulnerability can result in unauthorized ability to cause a
| hang or frequently repeatable crash (complete DOS) of MySQL Server
| and  unauthorized read access to a subset of MySQL Server accessible
| data. CVSS 3.1 Base Score 5.9 (Confidentiality and Availability
| impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H).


CVE-2023-22048[5]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: Pluggable Auth).  Supported versions that are
| affected are 8.0.33 and prior. Difficult to exploit vulnerability
| allows low privileged attacker with network access via multiple
| protocols to compromise MySQL Server.  Successful attacks of this
| vulnerability can result in  unauthorized read access to a subset of
| MySQL Server accessible data. CVSS 3.1 Base Score 3.1
| (Confidentiality impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N).


CVE-2023-22046[6]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: Optimizer).  Supported versions that are
| affected are 8.0.33 and prior. Easily exploitable vulnerability
| allows high privileged attacker with network access via multiple
| protocols to compromise MySQL Server.  Successful attacks of this
| vulnerability can result in unauthorized ability to cause a hang or
| frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1
| Base Score 4.9 (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


CVE-2023-22038[7]:
| Vulnerability in the MySQL Server product of Oracle MySQL
| (component: Server: Security: Privileges).  Supported versions that
| are affected are 8.0.33 and prior. Easily exploitable vulnerability
| allows high privileged attacker with network access via multiple
| protocols to compromise MySQL Server.  Successful attacks of this
| vulnerability can result in  unauthorized update, insert or delete
| access to some of MySQL Server accessible data. CVSS 3.1 Base Score
| 2.7 (Integrity impacts).  CVSS 

Bug#1036113: libpurple0: license conflict with libsasl2

[Evangelos Ribeiro Tzaras]

On Wed, 28 Jun 2023 10:14:00 +0200 Bastian Germann  wrote:
> Am 28.06.23 um 04:42 schrieb Richard Laager:
> > What is the remaining instance of RSA-MD licensed code after #767?
> 
> https://github.com/cyrusimap/cyrus-sasl/issues/769

Fyi: that issue has now been closed with
https://github.com/cyrusimap/cyrus-sasl/pull/770

-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1041818: openssl: CVE-2023-2975

[Salvatore Bonaccorso]

Source: openssl
Version: 3.0.9-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for openssl.

CVE-2023-2975[0]:
| Issue summary: The AES-SIV cipher implementation contains a bug that
| causes it to ignore empty associated data entries which are
| unauthenticated as a consequence.  Impact summary: Applications that
| use the AES-SIV algorithm and want to authenticate empty data
| entries as associated data can be mislead by removing adding or
| reordering such empty entries as these are ignored by the OpenSSL
| implementation. We are currently unaware of any such applications.
| The AES-SIV algorithm allows for authentication of multiple
| associated data entries along with the encryption. To authenticate
| empty data the application has to call EVP_EncryptUpdate() (or
| EVP_CipherUpdate()) with NULL pointer as the output buffer and 0 as
| the input buffer length. The AES-SIV implementation in OpenSSL just
| returns success for such a call instead of performing the associated
| data authentication operation. The empty data thus will not be
| authenticated.  As this issue does not affect non-empty associated
| data authentication and we expect it to be rare for an application
| to use empty associated data entries this is qualified as Low
| severity issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-2975
https://www.cve.org/CVERecord?id=CVE-2023-2975
[1] https://www.openssl.org/news/secadv/20230714.txt

Regards,
Salvatore

Bug#1041817: openssl: CVE-2023-3446

[Salvatore Bonaccorso]

Source: openssl
Version: 3.0.9-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.1.1n-0+deb11u4
Control: found -1 1.1.1n-0+deb11u5

Hi,

The following vulnerability was published for openssl.

CVE-2023-3446[0]:
| Issue summary: Checking excessively long DH keys or parameters may
| be very slow.  Impact summary: Applications that use the functions
| DH_check(), DH_check_ex() or EVP_PKEY_param_check() to check a DH
| key or DH parameters may experience long delays. Where the key or
| parameters that are being checked have been obtained from an
| untrusted source this may lead to a Denial of Service.  The function
| DH_check() performs various checks on DH parameters. One of those
| checks confirms that the modulus ('p' parameter) is not too large.
| Trying to use a very large modulus is slow and OpenSSL will not
| normally use a modulus which is over 10,000 bits in length.  However
| the DH_check() function checks numerous aspects of the key or
| parameters that have been supplied. Some of those checks use the
| supplied modulus value even if it has already been found to be too
| large.  An application that calls DH_check() and supplies a key or
| parameters obtained from an untrusted source could be vulernable to
| a Denial of Service attack.  The function DH_check() is itself
| called by a number of other OpenSSL functions. An application
| calling any of those other functions may similarly be affected. The
| other functions affected by this are DH_check_ex() and
| EVP_PKEY_param_check().  Also vulnerable are the OpenSSL dhparam and
| pkeyparam command line applications when using the '-check' option.
| The OpenSSL SSL/TLS implementation is not affected by this issue.
| The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this
| issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3446
https://www.cve.org/CVERecord?id=CVE-2023-3446
[1] https://www.openssl.org/news/secadv/20230719.txt

Regards,
Salvatore

Bug#1041816: pyequihash: Uses obsolete Debian Python Modules Team as uploader/Vcs field

[Boyuan Yang]

Source: pyequihash
Version: 0.2-2
Severity: normal
X-Debbugs-CC: joos...@debian.org
Tags: sid

Dear Debian pyequihash package maintainer,

Your package is one of the few packages left that still uses Debian
Python Modules Team ( 
https://qa.debian.org/developer.php?email=python-modules-team%40lists.alioth.debian.org
 )
in package maintainer or uploader field. This has been long been obsolete
according to past discussion on debian-python mailing list. Besides, your
package has Vcs-* fields that are 404 not found. Please fix these issues
in the next package upload.

Thanks,
Boyuan Yang


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

Bug#1041686: Add support for HTTP Status Code 308 as described in RFC 7238 (with patch)

[Thomas Dickey]

On Sat, Jul 22, 2023 at 09:05:17AM +0200, Joey Schulze wrote:
> Package: lynx
> Version: 2.9.0dev.12-1
> Severity: wishlist
> Tags: patch upstream
> X-Debbugs-Cc: j...@infodrom.org
> 
> Hi,
> 
> please add support for HTTP Status Code 308 (Permanent Redirect) to
> lynx, at least for the request method GET.  This new code has been
> specified in RFC 7238 in 2014.
> 
> Attached please find a patch for the quilt system which can be easily
> integrated.

The patch duplicates the check for 301 as 308 (including copying a comment
by "FM", who's not been active for about 25 years.  I'm assuming that
modifying the if-statement for 301 would be what you had in mind.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1041815: keepassxc: wrong homepage

[ss4qtr+6dtvdfaqe75eg]

Package: keepassxc
Severity: normal

Dear Maintainer,

https://packages.debian.org/bookworm/keepassxc and 
https://tracker.debian.org/pkg/keepassxc currently list the wrong homepage for 
the keepassxc project.

Debian uses https://www.keepassxc.org/ however this hasn't worked in a while.

https://en.wikipedia.org/wiki/KeePassXC and 
https://github.com/keepassxreboot/keepassxc instead link https://keepassxc.org/ 
which works.

Note the difference between https://keepassxc.org/ which doesn't have the www 
like the nonfunctional https://www.keepassxc.org/

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Otto Kekäläinen]

Hi!

I updated the changelog, tagged as
https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/1%2510.11.4-0+deb12u1
and uploaded binary packages as this will need to go via NEW queue.

However, it was rejected in NEW queue with error message:

mariadb_10.11.4-0+deb12u1.dsc: lack of required files for format 3.x (quilt)

I am currently trying to figure out what is supposedly missing, but
did not figure it out at least during the first 15 minutes of
research.

Bug#1041814: python-mechanicalsoup: CVE-2023-34457

[Salvatore Bonaccorso]

Source: python-mechanicalsoup
Version: 0.10.0-6
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.10.0-4

Hi,

The following vulnerability was published for python-mechanicalsoup.

The severity choosen for the bugreport might be slightly overrated,
but I am aiming to understand if the package is actively maintained
and might rather be removed from testing if not updated to a more
recent version.

CVE-2023-34457[0]:
| MechanicalSoup is a Python library for automating interaction with
| websites. Starting in version 0.2.0 and prior to version 1.3.0, a
| malicious web server can read arbitrary files on the client using a
| `` inside HTML form. All users of
| MechanicalSoup's form submission are affected, unless they took very
| specific (and manual) steps to reset HTML form field values. Version
| 1.3.0 contains a patch for this issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-34457
https://www.cve.org/CVERecord?id=CVE-2023-34457
[1] 
https://github.com/MechanicalSoup/MechanicalSoup/security/advisories/GHSA-x456-3ccm-m6j4
[2] 
https://github.com/MechanicalSoup/MechanicalSoup/commit/d57c4a269bba3b9a0c5bfa20292955b849006d9e

Regards,
Salvatore

Bug#1041689: [Pkg-utopia-maintainers] Bug#1041689: Bug#1041689: Bug#1041689: Bug#1041689: udisks2: After upgrading to 2.10.0-3 on trixie, the service udisks2 does not start.

[Michael Biebl]

Am 23.07.23 um 12:07 schrieb Marc Bres Gil:

Hello Michael,

I went to upstream with the traces, and found an already reported bug 
there on issues after updating to 2.10 with kde plasma 
(https://github.com/storaged-project/udisks/issues/1139 
) . Added the 
info to that bug report, for what I understand from the gdb trace, seems 
related to some nvme function. Will see if it helps there.




I do think your issue is different.
The upstream issue 1139 is about a timeout which can happen when 
collection file system info.

Your particular issue is udisksd crashed with a SIGABRT.
So I think this should be filed as as separate upstream issue.

Regards,
Michael





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041774: [Pkg-utopia-maintainers] Bug#1041774: udisks2: Hangs for about 20 secs. and timeout error after upgrading to 2.10.0-3 on trixie

[Michael Biebl]

Am 23.07.23 um 16:06 schrieb Ricardo Pérez:

Package: udisks2
Version: 2.10.0-3
Severity: important
X-Debbugs-Cc: rica...@ubuntu.com

Dear Maintainer,

After upgrading to 2.10.0-3 on trixie, when I try to run Thunar or
something similar, it hangs for about 20 secs. and then I got the
following error message:

Error creating proxy: Error calling StartServiceByName for 
org.gtk.vfs.UDisks2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)


This should be https://github.com/storaged-project/udisks/issues/1139

It's supposedly both a bug in Thunar (for not running the query async) 
and should be mitigated by installing util-linux 2.39 (from experimental).


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041384: librust-derive-builder-dev: impossible to install

[Peter Michael Green]

Version: 0.12.0-1

rust-derive-builder has now been updated to match rust-derive-builder-core.

Bug#1041813: orthanc: test failing on s390x (skipped)

[Étienne Mollier]

Source: orthanc
Version: 1.12.1+dfsg-1
Severity: important
Tags: upstream

The orthanc test suite fails after the build on s390x:

./OrthancFramework/UnitTestsSources/ImageTests.cpp:124: Failure
Expected equality of these values:
  "1cca552b6bd152b6fdab35c4a9f02c2a"
  md5
Which is: "92186150927d2f2c883ea72155597056"
[  FAILED  ] PngWriter.Color16Pattern (4 ms)
[…]
[--] Global test environment tear-down
[==] 270 tests from 63 test suites ran. (2030 ms total)
[  PASSED  ] 269 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] PngWriter.Color16Pattern

 1 FAILED TEST

This test is currently skipped in version 1.12.1+dfsg-2, but I
proceeded pretty bluntly, so at least the skip should be big
endian specific, or better the root cause should be fixed.

From my current investigations, the resulting png image from the
PngWriter.Color16Pattern shows two problems:

 1. it can't be opened by image viewers, but it is indeed
recognized as a PNG by file(1) and examining it with an
hexadecimal editor doesn't raise any obvious issues (apart
that they are different);

 2. analyzing the images pixel per pixel using sng(1) highlights
the image itself is byte swapped compared to the image
produced on little endian system; this is very visible when
using side by side comparison on the sng files:

$ diff --side-by-side --width=80 Color16Pattern_amd64.sng 
Color16Pattern_s390x.sng | head -n20
#SNG: from Color16Pattern_amd64.png   | #SNG: from 
Color16Pattern_s390x.png
IHDR {  IHDR {
width: 17; height: 61; bitdepth:width: 17; height: 61; 
bitdepth: 
using color alpha;  using color alpha;
}   }
IMAGE { IMAGE {
pixels hex  pixels hex
00ff 00ff 00f <
ff00 ff00 ff0   ff00 
ff00 ff0
00ff 00ff 000 | 00ff 
00ff 00f
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 000 | 00ff 
00ff 000
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 000 | 00ff 
00ff 000
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 00f | 00ff 
00ff 000
ff00 ff00 ff0   ff00 
ff00 ff0
00ff 00ff 000 | 00ff 
00ff 00f
ff00 ff00 000   ff00 
ff00 000
00ff 00ff 000 | 00ff 
00ff 000

(Thanks diffoscope(1) for introducing me to the use of sng by
the way!)

With some luck, the mitigation may be as simple as applying a
swab(3) on the pixel array produced by the test, but that still
wouldn't explain why the image was completely unreadable by
image readers (it may or may not work, I still have to check).
It is also possible my approach is wrong and the problem
genuinly lies in the png converter in Orthanc.

The bug should at least remain open until the test item is back
for little endian architectures.

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

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

-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/8, please excuse my verbosity
   `-on air: Erik Norlander - Surreal (Feat. Lana Lane)


signature.asc
Description: PGP signature

Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker

[Paul Gevers]

Package: light-locker
Version: 1.8.0-3
Followup-For: Bug #1039957

Hi,

I just found this coredump in my journal. Like the original reporter,
I'm a user of KDE (on trixie). I removed light-locker to see if I spotted any
change and I'm not seeing it yet.

Paul

Here's the dump:

jul 23 20:11:29 mulciber systemd-coredump[2250]: Process 2157 (light-locker) of 
user 1000 dumped core.
 
 Module libsystemd.so.0 from 
deb systemd-253.5-1.amd64
 Stack trace of thread 2157:
 #0  0x7f43ad4f6557 
g_log_structured_array (libglib-2.0.so.0 + 0x61557)
 #1  0x7f43ad4f69ae 
g_log_default_handler (libglib-2.0.so.0 + 0x619ae)
 #2  0x7f43ad4f6c20 g_logv 
(libglib-2.0.so.0 + 0x61c20)
 #3  0x7f43ad4f6ecf g_log 
(libglib-2.0.so.0 + 0x61ecf)
 #4  0x5570baa14085 n/a 
(light-locker + 0xb085)
 #5  0x7f43ad61015b 
g_type_create_instance (libgobject-2.0.so.0 + 0x3815b)
 #6  0x7f43ad5f3e60 n/a 
(libgobject-2.0.so.0 + 0x1be60)
 #7  0x7f43ad5f5496 
g_object_new_with_properties (libgobject-2.0.so.0 + 0x1d496)
 #8  0x7f43ad5f6311 
g_object_new (libgobject-2.0.so.0 + 0x1e311)
 #9  0x5570baa168e2 
gs_listener_new (light-locker + 0xd8e2)
 #10 0x5570baa124c2 n/a 
(light-locker + 0x94c2)
 #11 0x7f43ad61015b 
g_type_create_instance (libgobject-2.0.so.0 + 0x3815b)
 #12 0x7f43ad5f3e60 n/a 
(libgobject-2.0.so.0 + 0x1be60)
 #13 0x7f43ad5f5496 
g_object_new_with_properties (libgobject-2.0.so.0 + 0x1d496)
 #14 0x7f43ad5f6311 
g_object_new (libgobject-2.0.so.0 + 0x1e311)
 #15 0x5570baa12b02 
gs_monitor_new (light-locker + 0x9b02)
 #16 0x5570baa113fa main 
(light-locker + 0x83fa)
 #17 0x7f43ad2056ca 
__libc_start_call_main (libc.so.6 + 0x276ca)
 #18 0x7f43ad205785 
__libc_start_main_impl (libc.so.6 + 0x27785)
 #19 0x5570baa1154a _start 
(light-locker + 0x854a)
 
 Stack trace of thread 2196:
 #0  0x7f43ad263156 
__futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
 #1  0x7f43ad265818 
__pthread_cond_wait_common (libc.so.6 + 0x87818)
 #2  0x7f439a50c059 n/a 
(iris_dri.so + 0x10c059)
 #3  0x7f439a4be17b n/a 
(iris_dri.so + 0xbe17b)
 #4  0x7f439a50bf97 n/a 
(iris_dri.so + 0x10bf97)
 #5  0x7f43ad2663ec 
start_thread (libc.so.6 + 0x883ec)
 #6  0x7f43ad2e6a1c 
__clone3 (libc.so.6 + 0x108a1c)
 
 Stack trace of thread 2199:
 #0  0x7f43ad263156 
__futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
 #1  0x7f43ad265818 
__pthread_cond_wait_common (libc.so.6 + 0x87818)
 #2  0x7f439a50c059 n/a 
(iris_dri.so + 0x10c059)
 #3  0x7f439a4be17b n/a 
(iris_dri.so + 0xbe17b)
 #4  0x7f439a50bf97 n/a 
(iris_dri.so + 0x10bf97)
 #5  0x7f43ad2663ec 
start_thread (libc.so.6 + 0x883ec)
 #6  0x7f43ad2e6a1c 
__clone3 (libc.so.6 + 0x108a1c)
 
 Stack trace of thread 2200:
 #0  0x7f43ad263156 
__futex_abstimed_wait_common64 (libc.so.6 + 0x85156)
 

Bug#1040735: ms-gsl: autopkgtest failure due to new CMake deprecation warning

[Timo Röhling]

Hi,

On Sun, 09 Jul 2023 23:03:07 +0200 roehl...@debian.org wrote:

your package ms-gsl will soon experience autopkgtest failures because
the new CMake release 3.27 will issue a deprecation warning on stderr
if cmake_minimum_required() asks for compatibility with CMake 3.4 or
older.

I just did an NMU to DELAY/3. Please tell if you want me to cancel.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/changelog b/debian/changelog
index 9cb2e41..117793e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ms-gsl (4.0.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autopkgtest regression due to CMake warning (Closes: #1040735)
+
+ -- Timo Röhling   Sun, 23 Jul 2023 21:10:48 +0200
+
 ms-gsl (4.0.0-2) unstable; urgency=medium
 
   * Ignore -Wpsabi warnings on PowerPC.
diff --git a/debian/patches/1040735.patch b/debian/patches/1040735.patch
new file mode 100644
index 000..f580449
--- /dev/null
+++ b/debian/patches/1040735.patch
@@ -0,0 +1,18 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?= 
+Date: Sun, 23 Jul 2023 21:10:02 +0200
+Subject: Fix for #1040735
+
+---
+ tests/CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
+index 845ee26..b75648e 100644
+--- a/tests/CMakeLists.txt
 b/tests/CMakeLists.txt
+@@ -1,4 +1,4 @@
+-cmake_minimum_required(VERSION 3.0.2)
++cmake_minimum_required(VERSION 3.13)
+ 
+ project(GSLTests CXX)
+ enable_testing()  # again, for support standalone testing
diff --git a/debian/patches/series b/debian/patches/series
index 235bb02..5eb1697 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 PowerPC-warn-suppression.patch
+1040735.patch
diff --git a/debian/tests/smoke b/debian/tests/smoke
index bb52f69..7e6f409 100755
--- a/debian/tests/smoke
+++ b/debian/tests/smoke
@@ -8,7 +8,7 @@ BASH_XTRACEFD=1
 set -x
 
 tee CMakeLists.txt <

signature.asc
Description: PGP signature

Bug#1041812: curl: CVE-2023-32001

[Salvatore Bonaccorso]

Source: curl
Version: 7.88.1-10
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for curl.

CVE-2023-32001[0]:
| fopen race condition


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-32001
https://www.cve.org/CVERecord?id=CVE-2023-32001
[1] https://curl.se/docs/CVE-2023-32001.html

Regards,
Salvatore

Bug#1041811: libvirt: CVE-2023-3750

[Salvatore Bonaccorso]

Source: libvirt
Version: 9.5.0-1
Severity: important
Tags: security upstream
Forwarded: https://listman.redhat.com/archives/libvir-list/2023-July/240776.html
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 8.3.0-1

Hi,

The following vulnerability was published for libvirt.

CVE-2023-3750[0]:
| improper locking in virStoragePoolObjListSearch may lead to denial
| of service


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3750
https://www.cve.org/CVERecord?id=CVE-2023-3750
[1] https://listman.redhat.com/archives/libvir-list/2023-July/240776.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=210

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1041810: librsvg: CVE-2023-38633

[Salvatore Bonaccorso]

Source: librsvg
Version: 2.54.5+dfsg-3
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/librsvg/-/issues/996
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for librsvg.

CVE-2023-38633[0]:
| A directory traversal problem in the URL decoder of librsvg before
| 2.56.3 could be used by local or remote attackers to disclose files
| (on the local filesystem outside of the expected area), as
| demonstrated by href=".?../../../../../../../../../../etc/passwd" in
| an xi:include element.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-38633
https://www.cve.org/CVERecord?id=CVE-2023-38633
[1] https://gitlab.gnome.org/GNOME/librsvg/-/issues/996

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1041809: groff-base: man pages cause troff warning "cannot select font 'C'"

[Peter Wienemann]

Package: groff-base
Version: 1.23.0-2
Severity: normal

Dear Maintainer,

I see troff warnings "cannot select font 'C'" for several man pages. Here are 
the corresponding Lintian warnings for two examples from different packages:

W: python3-lark: groff-message troff::1032: warning: cannot 
select font 'C' [usr/share/man/man7/lark.7.gz:28]
[more similar lines]

and

W: charliecloud-builders: groff-message troff::1066: warning: 
cannot select font 'C' [usr/share/man/man1/ch-image.1.gz:15]
[more similar lines]

This issue looks similar to

https://bugs.debian.org/1040975

Best regards,

Peter

Bug#1041808: cura-engine: Several unit test failures on i686

[Gregor Riepl]

Here's an excerpt of the failing tests:

test 21
  Start 21: PolygonConnectorTest

21: Test command: cura-engine/obj-i686-linux-gnu/PolygonConnectorTest
21: Working Directory: cura-engine/tests/
21: Test timeout computed to be: 1500
5: [   OK ] 
InfillTestcases/InfillTest.TestInfillSanity/InfillTestParameters_P6_Z0_C1_L600__2 
(5 ms)
5: [ RUN  ] 
InfillTestcases/InfillTest.TestInfillSanity/InfillTestParameters_P6_Z0_C0_L800__2
6: [   OK ] AllCombinations/AddTravelTest.NoRetractionIfDisabled/62 
(4 ms)

6: [ RUN  ] AllCombinations/AddTravelTest.NoRetractionIfDisabled/63
21: [==] Running 6 tests from 1 test suite.
21: [--] Global test environment set-up.
21: [--] 6 tests from PolygonConnectorTest
21: [ RUN  ] PolygonConnectorTest.getBridgeNestedSquares
21: ./tests/utils/PolygonConnectorTest.cpp:71: Failure
21: Expected equality of these values:
21:   LinearAlg2D::getDist2BetweenLineSegments(bridge->a.from_point, 
bridge->a.to_point, bridge->b.from_point, bridge->b.to_point)

21: Which is: 9801
21:   100 * 100
21: Which is: 1
21: The bridges should be spaced 1 line width (100 units) apart.
21: [  FAILED  ] PolygonConnectorTest.getBridgeNestedSquares (0 ms)
21: [ RUN  ] PolygonConnectorTest.getBridgeAdjacentSquares
21: ./tests/utils/PolygonConnectorTest.cpp:91: Failure
21: Expected equality of these values:
21:   LinearAlg2D::getDist2BetweenLineSegments(bridge->a.from_point, 
bridge->a.to_point, bridge->b.from_point, bridge->b.to_point)

21: Which is: 9801
21:   100 * 100
21: Which is: 1
21: The bridges should be spaced 1 line width (100 units) apart.



test 18
  Start 18: IntPointTest

18: Test command: cura-engine/obj-i686-linux-gnu/IntPointTest
18: Working Directory: cura-engine/tests/
18: Test timeout computed to be: 1500
18: [==] Running 1 test from 1 test suite.
18: [--] Global test environment set-up.
18: [--] 1 test from IntPointTest
18: [ RUN  ] IntPointTest.TestRotationMatrix
18: ./tests/utils/IntPointTest.cpp:24: Failure
18: Expected equality of these values:
18:   rotated_in_place
18: Which is: (11,20)
18:   rotated_in_place_2
18: Which is: (10,20)
18: Matrix composition with translate and rotate failed.
18: [  FAILED  ] IntPointTest.TestRotationMatrix (0 ms)
18: [--] 1 test from IntPointTest (0 ms total)
18:
18: [--] Global test environment tear-down
18: [==] 1 test from 1 test suite ran. (0 ms total)
18: [  PASSED  ] 0 tests.
18: [  FAILED  ] 1 test, listed below:
18: [  FAILED  ] IntPointTest.TestRotationMatrix
18:
18:  1 FAILED TEST
15/26 Test #18: IntPointTest .***Failed0.00 sec
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from IntPointTest
[ RUN  ] IntPointTest.TestRotationMatrix
./tests/utils/IntPointTest.cpp:24: Failure
Expected equality of these values:
  rotated_in_place
Which is: (11,20)
  rotated_in_place_2
Which is: (10,20)
Matrix composition with translate and rotate failed.
[  FAILED  ] IntPointTest.TestRotationMatrix (0 ms)
[--] 1 test from IntPointTest (0 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] IntPointTest.TestRotationMatrix

Bug#1041808: cura-engine: Several unit test failures on i686

[Gregor Riepl]

Source: cura-engine
Version: 5.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Usertags: i686
Forwarded: https://github.com/Ultimaker/CuraEngine/issues/1192
X-Debbugs-Cc: onit...@gmail.com

On i686, CuraEngine 5.x fails to build due to failing unit tests.

This is a longstanding issue, going back to 4.4, where it was fixed by adding a
larger tolerance to test values.
However, the issue was not investigated thoroughly and returns in 5.0 with more
failing unit tests.

The root cause of these failures are rounding errors on i686, where the x87 FPU
produces different results than floating point units in other processors. These
differences are tiny, and usually not more than a few ULPs.

CuraEngine uses integer math in most places, but resorts to double-precision
floating-point calculations in certain cases. Afterwards, the results are
truncated to 64-bit integers (C type long long), and subsequent calculation is
done on the integer values. Truncation (aka round-toward-zero) is often ok and
works fine on amd64 (SSE2 floating-point math) and other CPUs, but produces
different results on the x87 FPU. When truncating, these produce off-by-one
errors in many cases, and the these errors can accumulate and lead to huge
differences in the unit tests.

By strategically adding explicit rounding (round-to-nearest) in the right
places, these errors can be eliminated. While this will produce subtly
different results in some cases, it is arguably more correct than always
truncating.

And at least on amd64, there is no performance difference between truncation
and rounding: The SSE2 CVTTSD2SI and CVTSD2SI instructions have the same
performance.


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

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

-- no debconf information

Bug#1041805: Acknowledgement (RM: beignet -- RoM; FTBFS with LLVM > 9, mostly replaced by intel-opencl-icd)

[Rebecca N. Palmer]

sorry, discussion on pkg-opencl-devel / debian-devel around 19 June, not 
actually in #974792

Bug#1041807: geany-plugins: build-depends on libwnck-dev, and indirectly on GTK 2

[Simon McVittie]

Source: geany-plugins
Version: 1.38+dfsg-2
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967592 by -1
Control: block 947713 by -1

geany-plugins build-depends on libwnck-dev, which in turn depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance.

None of the built binary packages depend on libwnck22, which makes me
think that this build-dependency is probably unnecessary? If so, please
remove it, bringing us one step closer to being able to clean up this
technical debt.

Thanks,
smcv

Bug#1041806: compiz-plugins-extra: depends on libxsettings-client, and indirectly GTK 2

[Simon McVittie]

Source: compiz-plugins-extra
Version: 2:0.8.18-3
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967594 by -1

compiz-plugins-extra is the only package in Debian that depends
on libxsettings-client, which is orphaned and depends on GTK 2. GTK 2 was
superseded by GTK 3 in 2011 (see ). It
has been discontinued by its upstream developer and no longer receives
any upstream maintenance at all.

Please look into whether this dependency chain can either be broken,
or upgraded to GTK 3.

Thanks,
smcv

Bug#1041805: RM: beignet -- RoM; FTBFS with LLVM > 9, mostly replaced by intel-opencl-icd

[Rebecca N. Palmer]

Package: ftp.debian.org

beignet FTBFS with LLVM > 9 (#974792), and hence cannot be built in 
current unstable.  (The existing package probably still works, because 
beignet statically links LLVM to avoid #852746, but unbuildable packages 
are unreleasable by policy.)


beignet is abandoned upstream and mostly replaced by intel-opencl-icd.

Some older hardware (Ivy Bridge/Haswell) is supported by 
beignet-opencl-icd but not intel-opencl-icd.  This hardware can use 
pocl-opencl-icd, but a rough estimate suggests that this will be ~8-16x 
slower.  This was raised during the discussion in #974792, and I am 
CCing those people in case they want to object to removal, but they 
didn't have a way to fix beignet.

Bug#1041804: showq: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: showq
Version: 0.4.1+git20200907-1
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

This package Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#825098: pcb2gcode: new upstream homepage and new release (1.2.3)

[Simon McVittie]

Control: severity -1 serious

On Mon, 23 May 2016 at 16:59:07 +0200, Graham Inggs wrote:
> The upstream pcb2gcode project has relocated to GitHub [1].
> 
> There is also a new upstream release (1.2.3) [2].
> 
> [1] https://github.com/pcb2gcode/pcb2gcode
> [2] https://github.com/pcb2gcode/pcb2gcode/releases/tag/v1.2.3

There have been several more recent upstream releases, most recently
v2.5.0 in 2022. This makes the git snapshot currently in Debian unstable
literally a decade out of date. Having such an old version of a package
that is actively maintained upstream seems like it is doing a disservice
to our users.

smcv

Bug#1041803: hyperspy: FTBFS test_image fails

[Rebecca N. Palmer]

Package: hyperspy
Version: 1.7.3-1
Severity: serious

hyperspy currently FTBFS with several failing tests:
https://launchpadlibrarian.net/678551154/buildlog_ubuntu-mantic-amd64.hyperspy_1.7.3-1_BUILDING.txt.gz

Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

[Richard Laager]

Is this reproducible for you? If you have experience with building from 
source, upstream has proposed the following patch. Otherwise, I could 
build a test package for you.


diff --git a/ntpd/nts_cookie.c b/ntpd/nts_cookie.c
index 166d0230f..a73955fb7 100644
--- a/ntpd/nts_cookie.c
+++ b/ntpd/nts_cookie.c
@@ -382,6 +382,9 @@ bool nts_unpack_cookie(uint8_t cookie, int cookielen,

if (NULL == cookie_ctx)
return false;   /* We aren't initialized yet. */
+
+   if (0 == nts_nKeys)
+   return false;   /* No cookies.  We are not an NTS server. */

/* We may get garbage from the net */
if (cookielen > NTS_MAX_COOKIELEN)
return false;
--
Richard

Bug#1041792: httpie: phones home for version check

[ss0buh+5z7qu6hu1fgzw]

Package: httpie
Followup-For: Bug #1041792

Further testing with help of people on IRC revealed the following information:

If you simply install httpie, and don't create any config directories, it will 
perform the version check every single time you run httpie.

If you create the directory ~/.config/httpie/ then httpie will download the 
file https://packages.httpie.io/latest.json and save it in 
~/.config/httpie/version_info.json

If you delete ~/.config/httpie/version_info.json and create the file 
~/.config/httpie/config.json with this content:

{
  "disable_update_warnings": true
}

then the version checks stop and ~/.config/httpie/version_info.json stops being 
created. This is poorly documented upstream.

I don't know if it is a permanent solution, or if it only temporarily stops 
this. I'm providing this as a workaround before it is fixed in the debian 
package.

In any case, this behavior should be patched out in httpie as distributed by 
debian.

Bug#1040467: file: /sys/firmware/acpi/bgrt/image strange behaviour

[Christoph Biedl]

Control: tags 1040467 upstream

fr...@gmail.com wrote...

> UEFI systems make the boot logo accessible for reading at the path 
> /sys/firmware/acpi/bgrt/image
>
> The file can be displayed directly using for example:
> $ feh /sys/firmware/acpi/bgrt/image
>
> Strange things happen when you copy this file elsewhere:
> $ cp /sys/firmware/acpi/bgrt/image /tmp/image
>
> and then run `file` on it:
> $ file /sys/firmware/acpi/bgrt/image /tmp/image
> /sys/firmware/acpi/bgrt/image: data
> /tmp/image:PC bitmap, Windows 3.x format, 434 x 432 x 24, 
> image size 565056, cbSize 565110, bits offset 54

While that particular sysfs file does not exist on my system, there's
already enough clue to get an idea what is happening here, and you
already almost got it:

(...)
> If you then diff those logfiles, you can notice that that
> /tmp/sys-firmware-acpi-bgrt-image.log only uses nbytes=4096, whereas
> /tmp/tmp-image.log uses nbytes=565110.

This difference comes from the read() syscall file/libmagic does to get
the file content: When reading a file in /sys/, that call only reads
4096 bytes and returns an according result. However, some bits used to
identify the file are likely beyond that limit. To confirm, try file on
the first 4096 bytes only, this should again result in "data", or:

$ dd if=/tmp/image bs=4096 count=1 | file -
data

As a workaround, you could again use file(1) in a pipe, i.e.

$ 

signature.asc
Description: PGP signature

Bug#1041802: pcb2gcode: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: pcb2gcode
Version: 1.1.4-git20120902-1.1
Severity: normal
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

This package Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Unfortunately, it looks as though the much newer upstream releases
referenced in #825098 still have this dependency.

Thanks,
smcv

Bug#1041801: miaviewit: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: miaviewit
Version: 1.0.5-3
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

This package Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1041800: vocproc: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: vocproc
Version: 0.2.1-2
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

This package Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1041798: RM: tcpcrypt -- ROM; dead upstream, not in stable

[Daniel Kahn Gillmor]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: tcpcr...@packages.debian.org, d...@fifthhorseman.net
Control: affects -1 + src:tcpcrypt

https://tcpcrypt.org has been non-responsive for quite some time, and
the tcpcrypt.org domain claims to have nameservers that are not
responding as well.  The project has been idle for years, and the
protocol development is stalled in the IETF.

I think it's time for this package to be removed from Debian.

  --dkg

Bug#1041799: lv2-c++-tools: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: lv2-c++-tools
Version: 1.0.5-4
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

This package depends on packages from src:gtkmm2.4, a C++
binding for GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its
upstream developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1041797: jstest-gtk: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: jstest-gtk
Version: 0.1.1~git20160825-4
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

This package Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1041796: hexxagon: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: hexxagon
Version: 1.0pl1-4
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

hexxagon Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1041795: eq10q: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: eq10q
Version: 2.2~repack0-4
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

eq10q Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#848972: Ping

[farblos]

Pinging this issue as I can see it as well in my bullseye system ...

Using an ugly service override

/etc/systemd/system/console-setup.service.d/override.conf:
[Unit]
Wants=systemd-tmpfiles-setup.service
After=systemd-tmpfiles-setup.service

helps as work-around.

Bug#1041794: mrtrix3: build-depends on unmaintained GTK-2-related packages

[Simon McVittie]

Source: mrtrix3
Version: 3.0.3-3
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967733 by -1
Control: block 967492 by -1
Control: block 967497 by -1

mrtrix3 Build-Depends on libgtkmm-2.4-dev and libgtkglext1-dev, which
in turn depend on the obsolete/unmaintained GTK 2 library.

>From a quick look at the binary package dependencies and source code,
it looks as though this package is a Qt application with no references to
GTK at all, other than a mention of pygtk in a comment. Presumably an
older version used GTK and these dependencies are leftovers?

If my assessment was correct, please remove the unused build-dependencies
so that we can be one step closer to removing libgtkmm-2.4-dev and
libgtkglext1-dev from Debian.

debian/mrtrix3.desktop also mentions GTK, and probably needs updating.

Unrelated to GTK, it's not clear to me whether the libgsl-dev and
libeigen3-dev dependencies are necessary, since they don't seem to be
reflected in the binary package's dependencies, so this might be a good
time to evaluate whether those can be removed too.

Thanks,
smcv

Bug#967559: lablgtk2: depends on deprecated GTK 2

[Bastian Germann]

On Tue, 4 Aug 2020 14:42:44 +0100 Simon McVittie wrote:

> I can however disable gtkspell in lablgtk2 (as I've done for
> gtksourceview2 and glade2) if it helps.

Can you tell how many dependent packages would be broken by that change?


I have uploaded an experimental NMU.
Every mentioned reverse dependency that is still in Debian builds without the 
gtkspell support.


If none actually use lablgtk2's gtkspell support, maybe it would be good
to disable it in the next upload. (No hurry to upload just for that.)
If you do, please unblock #967849 and remove the gtkspell usertag.


Please include the change in unstable and unblock after that.diff -Nru lablgtk2-2.18.13/debian/changelog lablgtk2-2.18.13/debian/changelog
--- lablgtk2-2.18.13/debian/changelog   2023-06-18 19:12:29.0 +0200
+++ lablgtk2-2.18.13/debian/changelog   2023-07-23 17:25:37.0 +0200
@@ -1,3 +1,10 @@
+lablgtk2 (2.18.13-1.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove gtkspell support.
+
+ -- Bastian Germann   Sun, 23 Jul 2023 17:25:37 +0200
+
 lablgtk2 (2.18.13-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru lablgtk2-2.18.13/debian/control lablgtk2-2.18.13/debian/control
--- lablgtk2-2.18.13/debian/control 2023-06-18 19:09:25.0 +0200
+++ lablgtk2-2.18.13/debian/control 2023-07-23 17:25:37.0 +0200
@@ -13,7 +13,6 @@
  libncurses-dev,
  libgtk2.0-dev,
  librsvg2-dev,
- libgtkspell-dev,
  ocaml-findlib
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
@@ -52,7 +51,6 @@
 Suggests: liblablgtk2-gnome-ocaml-dev
 Depends:
  libgtk2.0-dev,
- libgtkspell-dev,
  ${ocaml:Depends},
  ${shlibs:Depends},
  ${misc:Depends}
diff -Nru lablgtk2-2.18.13/debian/liblablgtk2-ocaml-dev.install.in 
lablgtk2-2.18.13/debian/liblablgtk2-ocaml-dev.install.in
--- lablgtk2-2.18.13/debian/liblablgtk2-ocaml-dev.install.in2023-06-18 
19:07:11.0 +0200
+++ lablgtk2-2.18.13/debian/liblablgtk2-ocaml-dev.install.in2023-07-23 
17:25:37.0 +0200
@@ -66,7 +66,6 @@
 @OCamlStdlibDir@/lablgtk2/gutf8.*
 @OCamlStdlibDir@/lablgtk2/gWindow.*
 @OCamlStdlibDir@/lablgtk2/liblablgtk2.a
-@OCamlStdlibDir@/lablgtk2/liblablgtkspell.a
 @OCamlStdlibDir@/lablgtk2/ml_domain.h
 @OCamlStdlibDir@/lablgtk2/ml_gdk.h
 @OCamlStdlibDir@/lablgtk2/ml_gdkpixbuf.h
@@ -119,5 +118,3 @@
 @OCamlStdlibDir@/lablgtk2/ogtkTreeProps.*
 OPT: @OCamlStdlibDir@/lablgtk2/lablgtk.a
 OPT: @OCamlStdlibDir@/lablgtk2/lablgtk.cmxa
-OPT: @OCamlStdlibDir@/lablgtk2/lablgtkspell.a
-OPT: @OCamlStdlibDir@/lablgtk2/lablgtkspell.cmxa
diff -Nru lablgtk2-2.18.13/debian/liblablgtk2-ocaml.install.in 
lablgtk2-2.18.13/debian/liblablgtk2-ocaml.install.in
--- lablgtk2-2.18.13/debian/liblablgtk2-ocaml.install.in2023-06-18 
19:03:59.0 +0200
+++ lablgtk2-2.18.13/debian/liblablgtk2-ocaml.install.in2023-07-23 
17:25:37.0 +0200
@@ -1,7 +1,4 @@
 debian/META  @OCamlStdlibDir@/lablgtk2
-@OCamlStdlibDir@/lablgtk2/dlllablgtkspell.so @OCamlDllDir@
 @OCamlStdlibDir@/lablgtk2/dlllablgtk2.so @OCamlDllDir@
 @OCamlStdlibDir@/lablgtk2/lablgtk.cma
-@OCamlStdlibDir@/lablgtk2/lablgtkspell.cma
 DYN: @OCamlStdlibDir@/lablgtk2/lablgtk.cmxs
-DYN: @OCamlStdlibDir@/lablgtk2/lablgtkspell.cmxs
diff -Nru lablgtk2-2.18.13/debian/META lablgtk2-2.18.13/debian/META
--- lablgtk2-2.18.13/debian/META2023-06-18 19:03:59.0 +0200
+++ lablgtk2-2.18.13/debian/META2023-07-23 17:25:37.0 +0200
@@ -13,9 +13,3 @@
   archive(byte) = "gtkInit.cmo"
   archive(native) = "gtkInit.cmx"
 )
-
-package "gtkspell" (
-  requires = "lablgtk2"
-  archive(byte) = "lablgtkspell.cma"
-  archive(native) = "lablgtkspell.cmxa"
-)
diff -Nru lablgtk2-2.18.13/debian/rules lablgtk2-2.18.13/debian/rules
--- lablgtk2-2.18.13/debian/rules   2023-06-18 19:07:11.0 +0200
+++ lablgtk2-2.18.13/debian/rules   2023-07-23 17:25:37.0 +0200
@@ -16,7 +16,7 @@
 override_dh_auto_configure:
cp  src/.depend debian/src.depend.backup
dh_auto_configure -- --without-gl --without-glade --with-rsvg   \
-   --without-gnomecanvas --with-gtkspell --without-gnomeui \
+   --without-gnomecanvas --without-gtkspell --without-gnomeui \
--without-gtksourceview2
 
 .PHONY: override_dh_auto_build

Bug#1041793: ocamlviz: Syntax error during build

[Bastian Germann]

Source: ocamlviz
Version: 1.01-6
Severity: important

https://buildd.debian.org/status/fetch.php?pkg=ocamlviz=all=1.01-6=1642843755=0
shows an error during the build:

   dh_ocamldoc -i
File "debian/libocamlviz-ocaml-dev/usr/lib/ocaml/ocamlviz/camlp4/pa_ocamlviz.ml", line 34, 
characters 6-8:

34 | | <:binding< $x$ and $y$ >> ->
   ^^
Error: Syntax error

I do not know ocaml well enough to judge if it is important or not but file 
this anyway.

Bug#1041792: httpie: phones home for version check

[ss0buh+5z7qu6hu1fgzw]

Package: httpie
Version: 3.2.1-1
Severity: serious

Dear Maintainer,

httpie makes a request to packages.httpie.io every time you start it. It does 
this presumably to check for a newer version, which is irrelevant in debian. It 
also smells like a policy violation, though I didn't find an exact paragraph 
that covers this.

This can be seen in the source code here:
https://sources.debian.org/src/httpie/3.2.1-1/httpie/internal/update_warnings.py/?hl=16#L16

Upstream has some documentation here:
https://httpie.io/docs/cli/update-warnings

Please remove this update check, not only is it irrelevant in debian, but it 
also causes a mess in logs due to unintended DNS requests.
thanks


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

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

Versions of packages httpie depends on:
ii  python3 3.11.2-1+b1
ii  python3-charset-normalizer  3.0.1-2
ii  python3-defusedxml  0.7.1-2
ii  python3-multidict   6.0.4-1+b1
ii  python3-pip 23.0.1+dfsg-1
ii  python3-pkg-resources   66.1.1-1
ii  python3-pygments2.14.0+dfsg-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-requests-toolbelt   0.10.1-1
ii  python3-rich13.3.1-1
ii  python3-socks   1.7.1+dfsg-1

httpie recommends no packages.

httpie suggests no packages.

-- no debconf information

Bug#1041791: darkradiant: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: darkradiant
Version: 3.7.0-1
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967733 by -1
Control: block 967497 by -1

darkradiant Build-Depends on packages from src:gtkmm2.4, a C++ binding
for GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance.

>From a quick look at the binary package dependencies and source code,
it looks as though darkradiant is a GTK 3 application already, and the only
reference to gtkmm seems to be in
plugins/dm.objectives/util/TwoColumnTextCombo.h, which is not compiled
when using Debian toolchains, only when using MSVC or Xcode. If that's the
case, then this build-dependency can probably just be dropped.

Thanks,
smcv

Bug#1027215: Proposed RM: theano, keras, deepnano -- broken by numpy 1.24, theano mostly abandoned upstream

[Rebecca N. Palmer]

Control: reopen -1 1026539

theano has been mostly abandoned upstream since 2018.  (The Aesara fork 
is not abandoned, but includes interface changes including the import 
name, so would break reverse dependencies not specifically altered for it.)


It is currently broken (FTBFS due to multiple test failures), probably 
by numpy 1.24 (#1027215).


Its reverse dependencies (keras and deepnano) are both also broken by 
this.  (keras _also_ has apparently unrelated problems, #1026738, and is 
orphaned, #1027938.)


This was previously discussed in #1027215, where it was noted that 
removing keras would also block the addition of qmean (ITP #976981), but 
attempts to fix it failed.  (Note that what is in Salsa isn't actually a 
fix: theano skips most of its tests in Salsa CI because they take 
several hours.)

Bug#1041790: dbus-c++: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: dbus-c++
Version: 0.9.0-11
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967733 by -1
Control: block 967497 by -1

dbus-c++ Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance.

If dbus-c++ can be either updated to GTK 3, updated to drop the GTK
dependency or removed, then that would reduce the amount of technical
debt in the archive.

>From a quick look at the binary package dependencies and source code,
it looks as though simply dropping the build-dependency should work: this
will result in the dbus-browser example not being compiled any more, but
no changes to the installed files.

Thanks,
smcv

Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

[Gordon Fyodor Lyon]

Thanks Paul.  We did make some changes in Nmap 7.94 which could have caused
regressions.  I've opened an issue for this on our upstream tracker (
https://github.com/nmap/nmap/issues/2685).  Please let us know if you
figure anything else out.

-Gordon

Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged

[Bastian Germann]

Source: unison-2.51+4.13.1
Version: 2.51.5-1
Severity: serious

Why is unison-2.51+4.13.1 not removed yet when unison-2.52 is available?

Bug#1041788: [PATCH] Two formatting errors (broken new paragraph commands) in clisp.1 man page

[Erik Auerswald]

Package: clisp
Version: 1:2.49.20210628.gitde01f0f-3
Tags: patch, upstream

Dear Debian Common Lisp Team,

the clisp.1 man page contains two instances where the .PP macro is not
preceded by a newline. This results in literal .PP inside the rendered
man page instead of creating a new paragraph with the .PP macro:

Instance one:

   -on-error action
   Establish global error handlers, depending on action:.PP appease
   continuable[17] ERROR[18]s are turned into WARNING[19]s (with
   EXT:APPEASE-CERRORS) other ERROR[18]s are handled in the
   default way

   debug
   ERROR[18]s INVOKE-DEBUGGER[20] (the normal read-eval-print
   loop[2] behavior), disables batch mode imposed by -c, -x, and
   lisp-file,

Instance two:

USING AND EXTENDING CLISP
   Common Lisp[1] is a programmable programming language. —John
   Foderaro[47].PP When CLISP[6] is invoked, the runtime loads the initial
   memory image and outputs the prompt; at which one can start typing
   DEFVAR[48]s, DEFUN[49]s and DEFMACRO[50]s.

The fix is simple, just add a newline in front of the two .PP macros,
as done in the attached patches. The result looks as follows:

Instance one:

   -on-error action
   Establish global error handlers, depending on action:

   appease
   continuable[17] ERROR[18]s are turned into WARNING[19]s (with
   EXT:APPEASE-CERRORS) other ERROR[18]s are handled in the
   default way

   debug
   ERROR[18]s INVOKE-DEBUGGER[20] (the normal read-eval-print
   loop[2] behavior), disables batch mode imposed by -c, -x, and
   lisp-file,

Instance two:

USING AND EXTENDING CLISP
   Common Lisp[1] is a programmable programming language. —John
   Foderaro[47]

   When CLISP[6] is invoked, the runtime loads the initial memory image
   and outputs the prompt; at which one can start typing DEFVAR[48]s,
   DEFUN[49]s and DEFMACRO[50]s.


At the end of last year, I reported this bug to the upstream
CLISP bug tracker at 
as described on the CLISP home page 
(identical to  and
), please see
.

I did not receive any feedback there. The bug is still present in the
upstream development repository.

This May, I reported the bug to Ubuntu, because I am actually using
Ubuntu on my personal computer:


There I was asked to report this to Debian:


Since upstream did not react to the report and patches for over half a
year, even though there has been some activity in the upstream git repo
during that time, it seems to me as if it might be prudent to add this
fix to the Debian clisp package.

The attached patches are against upstream git sources, but they should
apply to the current Debian snapshot of the sources, too, since it has
been years since the patched upstream files have changed.

The patches can be put into the "debian/patches" directory and appended
to the "debian/patches/series" file.

The first one fixes the two current .PP formatting errors in the clisp
man page.  The second one adds a correction step for the .PP problem to
makemake.in, in order to adjust possible new cases of this problem that
might introduced in the future.  Either one fixes the known problems.
They can both be applied, or just one of them.

Perhaps third time is the charm….

Best regards,
Erik
-- 
The computing scientist’s main challenge is not to get confused by
the complexities of his own making.
-- Edsger W. Dijkstra
diff --git a/doc/_clisp.1 b/doc/_clisp.1
index f9ca51022..cdd17f16d 100644
--- a/doc/_clisp.1
+++ b/doc/_clisp.1
@@ -435,7 +435,8 @@ is equivalent to
 \fB\-on\-error\fR \fIaction\fR
 .RS 4
 Establish global error handlers, depending on
-\fIaction\fR:.PP
+\fIaction\fR:
+.PP
 appease
 .RS 4
 \m[blue]\fBcontinuable\fR\m[]\&\s-2\u[17]\d\s+2
@@ -907,7 +908,8 @@ Otherwise, the symbol you are currently typing is completed\&.
 is a
 \fIprogrammable\fR
 programming language\&.
-\(em\m[blue]\fBJohn Foderaro\fR\m[]\&\s-2\u[47]\d\s+2.PP
+\(em\m[blue]\fBJohn Foderaro\fR\m[]\&\s-2\u[47]\d\s+2
+.PP
 When
 \m[blue]\fB\fBCLISP\fR\fR\m[]\&\s-2\u[6]\d\s+2
 is invoked, the
diff --git a/src/makemake.in b/src/makemake.in
index f2f6db977..f8427d761 100644
--- a/src/makemake.in
+++ b/src/makemake.in
@@ -3997,6 +3997,8 @@ for f in $TXT_FILES ; do
   line="${HERE}${g}"
   test $f = clisp.1 -o $f = clisp-link.1 && \
 line=$line" | \$(GREP) -v ${ARGQ1}^ *\$\$${ARGQ1}"
+  test "$f" = clisp.1 && \
+line=$line" | sed -e 's/\(.\)\.PP/\1\n.PP/p'"
   # *-1.html is for chunked impnotes and does not depend on user hyperspec
   test \(