date:20230627

Processing control commands:

> fixed -1 1:15.0.7-2
Bug #1036614 [python3-lldb-15] python3-lldb-15: broken symlinks: 
/usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/_lldb.cpython-311-x86_64-linux-gnu.so,
 /usr/lib/llvm-15/lib/python3/dist-packages/lldb/libLLVM-15.so.1, ...
Marked as fixed in versions llvm-toolchain-15/1:15.0.7-2.
> close -1
Bug #1036614 [python3-lldb-15] python3-lldb-15: broken symlinks: 
/usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/_lldb.cpython-311-x86_64-linux-gnu.so,
 /usr/lib/llvm-15/lib/python3/dist-packages/lldb/libLLVM-15.so.1, ...
Marked Bug as done

-- 
1036614: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036614
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1036614: python3-lldb-15: broken symlinks: /usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/_lldb.cpython-311-x86_64-linux-gnu.so, /usr/lib/llvm-15/lib/python3/dist-packages/lldb/libLLVM-15.so.1

2023-06-27 Thread Gianfranco Costamagna


control: fixed -1 1:15.0.7-2
control: close -1

This is fixed for llvm-15+

G.
On Tue, 23 May 2023 11:13:34 +0200 Andreas Beckmann  wrote:

Package: python3-lldb-15
Version: 1:15.0.6-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
broken symlinks:

0m35.3s ERROR: FAIL: Broken symlinks:
  
/usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/_lldb.cpython-311-x86_64-linux-gnu.so
 -> ../../../../../lib/liblldb.so (python3-lldb-15)
  /usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/lldb-argdumper -> 
../../../../../bin/lldb-argdumper (python3-lldb-15)
  /usr/lib/llvm-15/lib/python3/dist-packages/lldb/libLLVM-15.0.6.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1 (python3-lldb-15)
  /usr/lib/llvm-15/lib/python3/dist-packages/lldb/libLLVM-15.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1 (python3-lldb-15)

lldb-argdumper has one level of '..' too much, otherwise it could be
found.
The correct target for libLLVM-15.0.6.so.1 would be
/usr/lib//libLLVM-15.so.1
and _lldb.cpython-311-.so should be linked to
/usr/lib/llvm-15/lib/python3/dist-packages/lldb/_lldb.so or
/usr/lib//liblldb-15.so.1

cheers,

Andreas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039633: r-bioc-bioccheck: autopkgtest failure with r-base (4.3.1-1)

2023-06-27 Thread Bas Couwenberg

Source: r-bioc-bioccheck
Version: 1.34.2+dfsg-1
Severity: serious
Justification: autopkgtest failure

Dear Maintainer,

The autopkgtest of your package fails with r-base (4.3.1-1):

 209s RUNIT TEST PROTOCOL -- Tue Jun 27 15:46:32 2023 
 209s *** 
 209s Number of test functions: 48 
 209s Number of deactivated test functions: 3 
 209s Number of errors: 0 
 209s Number of failures: 1 
 209s 
 209s  
 209s 1 Test Suite : 
 209s BiocCheck RUnit Tests - 48 test functions, 0 errors, 1 failure
 209s FAILURE in test_checkBBScompatibility: Error in 
checkTrue(.BiocCheck$getNum("note") == 1, "citation produces note") : 
 209s   Test not TRUE
 209s citation produces note
 209s DEACTIVATED test_checkExportsAreDocumented: Skip this test, it requires a 
package non-available in Debian
 209s DEACTIVATED test_checkUsageOfDont: Skip this test, it requires a package 
non-available in Debian
 209s DEACTIVATED test_remotesUsage: Skip this test, it requires a package 
non-available in Debian
 209s 
 209s Test files with failing tests
 209s 
 209stest_BiocCheck.R 
 209s  test_checkBBScompatibility 
 209s  test_checkExportsAreDocumented 
 209s  test_checkUsageOfDont 
 209s  test_remotesUsage 
 209s 
 209s 
 209s Error in BiocGenerics:::testPackage("BiocCheck") : 
 209s   unit tests failed for package BiocCheck

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-bioccheck/34907238/log.gz

Kind Regards,

Bas

Processed: Re: r-cran-rgeos: autopkgtest failure with GEOS 3.12

Processing commands for cont...@bugs.debian.org:

> severity 1038733 serious
Bug #1038733 {Done: Andreas Tille } [src:r-cran-rgeos] 
r-cran-rgeos: autopkgtest failure with GEOS 3.12
Severity set to 'serious' from 'important'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1038733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038733
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1039621: marked as done (libngs-jni: Installs shared object in wrong directory)

Your message dated Wed, 28 Jun 2023 02:54:54 +
with message-id 
and subject line Bug#1039621: fixed in sra-sdk 3.0.3+dfsg-6
has caused the Debian Bug report #1039621,
regarding libngs-jni: Installs shared object in wrong directory
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1039621: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039621
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libngs-jni
Version: 3.0.3+dfsg-5
Severity: serious

Hi

This package installs the shared object in the following _literal_
pathname:

  /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so

Where the variable has not been expanded and appears as is. So the
shared object will not be found.

Thanks,
Guillem
--- End Message ---
--- Begin Message ---
Source: sra-sdk
Source-Version: 3.0.3+dfsg-6
Done: Aaron M. Ucko 

We believe that the bug you reported is fixed in the latest version of
sra-sdk, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1039...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aaron M. Ucko  (supplier of updated sra-sdk package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 27 Jun 2023 22:14:41 -0400
Source: sra-sdk
Architecture: source
Version: 3.0.3+dfsg-6
Distribution: unstable
Urgency: high
Maintainer: Debian Med Packaging Team 

Changed-By: Aaron M. Ucko 
Closes: 1039621
Changes:
 sra-sdk (3.0.3+dfsg-6) unstable; urgency=high
 .
   * debian/rules: Expand $(DEB_HOST_MULTIARCH) in libngs-java.links.in.
 (Closes: #1039621.)
Checksums-Sha1:
 824ae734fe5cdd509aedcde335adb8a17a926345 2889 sra-sdk_3.0.3+dfsg-6.dsc
 b9789224703ec6025eaf27b94eab24c4a43bdae4 3785120 
sra-sdk_3.0.3+dfsg-6.debian.tar.xz
 448dc70905a880852f5c37b63fa32409f99de3c5 16870 
sra-sdk_3.0.3+dfsg-6_source.buildinfo
Checksums-Sha256:
 b569b2618b3701068b2f52b85f60be4f858dc38250ce39de898768802b72f7ce 2889 
sra-sdk_3.0.3+dfsg-6.dsc
 de219aef3432a70c2a9279b70e9f7cedc5676368d20e644dd6356e5e490273f0 3785120 
sra-sdk_3.0.3+dfsg-6.debian.tar.xz
 badb55b7b8e6ceda3fd06844185ac5c3bf1ab389b4576a7907d4d5776cb672fd 16870 
sra-sdk_3.0.3+dfsg-6_source.buildinfo
Files:
 7435f17bf1bed941b64bb766eb2eae93 2889 science optional sra-sdk_3.0.3+dfsg-6.dsc
 62606e509d04b8bdca9558fb45e85c97 3785120 science optional 
sra-sdk_3.0.3+dfsg-6.debian.tar.xz
 ae4fac50a2f06a1f48e1a18a34827f29 16870 science optional 
sra-sdk_3.0.3+dfsg-6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfDq5z9IwvTDdAJxZHnCRsfFKZKIFAmSbmL0ACgkQHnCRsfFK
ZKL3rRAAiThKFJFfuQuljT2E70KlWDCEBzZj+hjZ5EQ6fzvHeL3LpoXmEeNhml97
3zOYlT5QNyz7okplbskPhBIqdynsmYnEHc56TsTfUfzjXheJpux1s3Loksd7ZTDb
jGAz/lDfvnCnXWykKK26tR/RL/typrFv8UIvsYKRW2/TnZoR+mQV30bwo5K+S+I3
0y/z7XEHhFE+EqEOik7x+D2bzjMS4+tjNQ2onje8w58p1rygb62S10mVqnqSRqIe
WzDs3T8A7EA2ICbZnLetU+ebqwNlM5+Q2QyS4aGCgI3hfX4PAno7lK96JyHZSwB1
NnzM25wfONIGzbmEDhkHF+gujtYMTNiAdom7gVMyUFzjByg9N1WCmWKLklgYdfzJ
8qvSm1oh8LodUWoQ8DtV55+hm1gguCBWaNHKIqXXpFo/1SMeW4rzfi54wnXXBE5U
L9Ajf1yTgXtlX18tlNCgMUcREtcKB5+XrAEl3KQCxHGQYv/32SKw1vmtEd8U5crM
FFsG9jqu+pzkGJ1cjfnw2ZYLtmsgeP9J6FMCXyT16Q0VkmxmhNoFgGPnh+ceq5aF
GcmAJFYv/Zjx0LBJdFsexTi8kaiRDNkmhNb629aPXIfExjI1bvkkC/ZVNJoAez0I
XO/2C/JpaRH2TzpXaKIsAFnpLEOyhbCCKqyLq61Dr+8dwvp+eJo=
=XFIF
-END PGP SIGNATURE End Message ---

Bug#1036113: libpurple0: license conflict with libsasl2


On 2023-06-27 17:35, Bastian Germann wrote:

Am 28.06.23 um 00:13 schrieb Richard Laager:


The last bugfix release took them more than 3 years and when #767 is 
released is unknown.


When a release happens is irrelevant, as you can carry #767 as a patch 
in the Debian package until then.


Even when that happens, upstream still has to eliminate the last 
instance of the RSA-MD license.


What is the remaining instance of RSA-MD licensed code after #767?

License compliance will not just magically happen by ignoring the 
problematic parts in Debian.


I didn't suggest it would, nor am I ignoring anything. My point is that, 
in this particular case, it seems that you have everything solved or 
close to solved by yourself.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

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

The original submitter replied off the tracker (probably by accident). 
I'll summarize here.


The ntp.conf he included is the stock ntp.conf.

He indicated he will try to get a backtrace.

--
Richard

Bug#1039621: libngs-jni: Installs shared object in wrong directory

2023-06-27 Thread Aaron M. Ucko

Guillem Jover  writes:

>   /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so
>
> Where the variable has not been expanded and appears as is. So the
> shared object will not be found.

Oops, so it does; automatic testing evidently missed that due to running
with libncbi-ngs-dev installed.  I went with a minimal fix, in part to
facilitate getting it into a stable update if anyone considers that
warranted.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1038648: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#1038648: fixed in xserver-xorg-video-qxl 0.1.6-1)

2023-06-27 Thread Frank Heckenbach

Doesn't fix the problem.

Bug#1039625: marked as done (sl-modem-dkms: module fails to build for Linux 6.3, 6.4)

Your message dated Wed, 28 Jun 2023 00:52:20 +
with message-id 
and subject line Bug#1039625: fixed in sl-modem 2.9.11~20110321-18
has caused the Debian Bug report #1039625,
regarding sl-modem-dkms: module fails to build for Linux 6.3, 6.4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1039625: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039625
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sl-modem-dkms
Version: 2.9.11~20110321-17
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts


1.) There is an autopkgtest regression with the -cloud kernel,
preventing migration to testing (therefore severity serious):

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sl-modem/34615715/log.gz

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.1.0-9-cloud-amd64 
(x86_64)
Mon Jun 19 06:58:35 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o 
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.1.0-9-cloud-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.o
  LD [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.o
  MODPOST /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers
ERROR: modpost: "usb_alloc_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_free_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_register_driver" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_clear_halt" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_submit_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_control_msg" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_set_interface" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_deregister" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_unlink_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
make[2]: *** 
[/usr/src/linux-headers-6.1.0-9-common/scripts/Makefile.modpost:126: 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers] Error 1
make[1]: *** [/usr/src/linux-headers-6.1.0-9-common/Makefile:1989: modpost] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
make: *** [Makefile:138: all] Error 2
make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
make: Entering directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'
make modules -C /lib/modules/6.1.0-9-cloud-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.o
  MODPOST 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/Module.symvers
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.mod.o
  LD [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
  BTF [M] 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
Skipping BTF generation for 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko 
due to unavailability of vmlinux
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
make: Leaving directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'

You probably need to add this line to your dkms.conf:

BUILD_EXCLUSIVE_CONFIG="CONFIG_USB"

in order to skip building the module for kernels without CONFIG_USB.



2.) the module fails to build for Linux 6.4

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.4.0-0-amd64 (x86_64)
Tue Jun 27 10:00:31 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.4.0-0-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory

Bug#1039572: marked as done (sl-modem-dkms: module fails to build for -cloud kernel, retitle -1 sl-modem-dkms: module fails to build for Linux 6.4)

Your message dated Wed, 28 Jun 2023 00:52:19 +
with message-id 
and subject line Bug#1039572: fixed in sl-modem 2.9.11~20110321-18
has caused the Debian Bug report #1039572,
regarding sl-modem-dkms: module fails to build for -cloud kernel, retitle -1 
sl-modem-dkms: module fails to build for Linux 6.4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1039572: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039572
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sl-modem-dkms
Version: 2.9.11~20110321-17
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts


1.) There is an autopkgtest regression with the -cloud kernel,
preventing migration to testing (therefore severity serious):

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sl-modem/34615715/log.gz

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.1.0-9-cloud-amd64 
(x86_64)
Mon Jun 19 06:58:35 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o 
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.1.0-9-cloud-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.o
  LD [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.o
  MODPOST /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers
ERROR: modpost: "usb_alloc_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_free_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_register_driver" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_clear_halt" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_submit_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_control_msg" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_set_interface" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_deregister" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_unlink_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
make[2]: *** 
[/usr/src/linux-headers-6.1.0-9-common/scripts/Makefile.modpost:126: 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers] Error 1
make[1]: *** [/usr/src/linux-headers-6.1.0-9-common/Makefile:1989: modpost] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
make: *** [Makefile:138: all] Error 2
make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
make: Entering directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'
make modules -C /lib/modules/6.1.0-9-cloud-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.o
  MODPOST 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/Module.symvers
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.mod.o
  LD [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
  BTF [M] 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
Skipping BTF generation for 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko 
due to unavailability of vmlinux
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
make: Leaving directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'

You probably need to add this line to your dkms.conf:

BUILD_EXCLUSIVE_CONFIG="CONFIG_USB"

in order to skip building the module for kernels without CONFIG_USB.



2.) the module fails to build for Linux 6.4

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.4.0-0-amd64 (x86_64)
Tue Jun 27 10:00:31 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.4.0-0-amd64/build

Processed: cloning 1039572, retitle -1 to sl-modem-dkms: module fails to build for Linux 6.3

Processing commands for cont...@bugs.debian.org:

> clone 1039572 -1
Bug #1039572 [sl-modem-dkms] sl-modem-dkms: module fails to build for -cloud 
kernel, retitle -1 sl-modem-dkms: module fails to build for Linux 6.4
Bug 1039572 cloned as bug 1039626
> retitle -1 sl-modem-dkms: module fails to build for Linux 6.3
Bug #1039626 [sl-modem-dkms] sl-modem-dkms: module fails to build for -cloud 
kernel, retitle -1 sl-modem-dkms: module fails to build for Linux 6.4
Changed Bug title to 'sl-modem-dkms: module fails to build for Linux 6.3' from 
'sl-modem-dkms: module fails to build for -cloud kernel, retitle -1 
sl-modem-dkms: module fails to build for Linux 6.4'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1039572: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039572
1039626: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039626
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: cloning 1039572 ...

Processing commands for cont...@bugs.debian.org:

> clone 1039572 -1
Bug #1039572 [sl-modem-dkms] sl-modem-dkms: module fails to build for Linux 
6.3, 6.4
Bug 1039572 cloned as bug 1039625
> retitle 1039572 sl-modem-dkms: module fails to build for -cloud kernel, 
> retitle -1 sl-modem-dkms: module fails to build for Linux 6.4
Bug #1039572 [sl-modem-dkms] sl-modem-dkms: module fails to build for Linux 
6.3, 6.4
Changed Bug title to 'sl-modem-dkms: module fails to build for -cloud kernel, 
retitle -1 sl-modem-dkms: module fails to build for Linux 6.4' from 
'sl-modem-dkms: module fails to build for Linux 6.3, 6.4'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1039572: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039572
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

2023-06-27 Thread Mike Hommey

On Tue, Jun 27, 2023 at 11:39:12AM +0200, Philipp Marek wrote:
> Package: firefox
> Version: 114.0-1
> Severity: grave
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Websites that need randomness ([1]) are broken,
> on both Debian FF 113.0.2 and 114.0 (114.0.2 not yet available for amd64).
> 
> Reproduced with a new profile without any plugins.
> 
> strace shows FF being able to use getrandom(),
> so it seems to be a userspace problem.
> 
> 
> 114.0.2 from upstream works as expected;
> Mozilla chat recommended asking the packaging team.
> 
> 
> Ad 1:
> - banking.bank99.at uses crypto.getRandomValues() even before login

"The server at banking.bank99.at is taking too long to respond."

> - RedHat support webpage uses getRandomUUID after login
> Both fail with "OperationError: The operation failed for an 
> operation-specific reason"

Obviously, I can't reproduce with this since I can't login...

I also can't reproduce calling the crypto.randomUUID and
crypto.getRandomValues functions from the devtools console...

Try downgrading libnss3.

Mike

Bug#1036113: libpurple0: license conflict with libsasl2

2023-06-27 Thread Bastian Germann

Am 28.06.23 um 00:13 schrieb Richard Laager:

Wait a minute... You are a maintainer for cyrus-sasl.

Just the package maintainer in Debian.

You have already addressed the BSD-4-clause-KTH in the latest upload.

That is true, which I have noted on the other bug.

You also fixed debian/copyright to reference BSD-3-Clause-Attribution in the latest upload. That license is fine for the
reasons I mentioned.

That is your legal take on it. My take is that BSD-3-Clause-Attribution is GPL-incompatible because it has a further
restriction on distribution.

That just leaves the MD5 stuff, right? You have authored a fix for that, which
it looks like will be merged shortly:
https://github.com/cyrusimap/cyrus-sasl/pull/767

If BSD-3-Clause-Attribution was GPL-compatible then, yes, RSA-MD license is the last license that causes an
GPL-incompatibility.

It seems like you can have this fixed any time (by merging in upstream #767)
and will have it fixed shortly.

I do not have commit access to upstream nor do I have any particular role there.
The last bugfix release took them more than 3 years and when #767 is released
is unknown.
Even when that happens, upstream still has to eliminate the last instance of
the RSA-MD license.

So why do I need to do anything?

You don't need to. But you should if you want to keep pidgin in testing.

License compliance will not just magically happen by ignoring the problematic
parts in Debian.
Actually, I am also happy when you appeal to any of the Debian bodies (TC?) about the severity of this bug so that there
is a decision made on it.

Bug#1036113: libpurple0: license conflict with libsasl2


Wait a minute... You are a maintainer for cyrus-sasl.

You have already addressed the BSD-4-clause-KTH in the latest upload.

You also fixed debian/copyright to reference BSD-3-Clause-Attribution in 
the latest upload. That license is fine for the reasons I mentioned.


That just leaves the MD5 stuff, right? You have authored a fix for that, 
which it looks like will be merged shortly:

https://github.com/cyrusimap/cyrus-sasl/pull/767

It seems like you can have this fixed any time (by merging in upstream 
#767) and will have it fixed shortly.


So why do I need to do anything?

--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039621: libngs-jni: Installs shared object in wrong directory

2023-06-27 Thread Guillem Jover

Package: libngs-jni
Version: 3.0.3+dfsg-5
Severity: serious

Hi

This package installs the shared object in the following _literal_
pathname:

  /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so

Where the variable has not been expanded and appears as is. So the
shared object will not be found.

Thanks,
Guillem

Bug#1036113: libpurple0: license conflict with libsasl2

2023-06-27 Thread Bastian Germann

Am 27.06.23 um 23:34 schrieb Richard Laager:
Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500. Quickly taking that list through UDD gives me
just over 4,500 source packages. Surely, a large number of those are going to be GPL licensed. Is your plan to file
Severity: serious bugs against all of them?

No, but at least the ones that directly depend on cyrus-sasl.
There are not many; most reverse dependencies are via libldap.

If so, isn't that an MBF that needs discussion on debian-devel first?

I do not have the capacity for a mass bug filing.
Once in a while I will look at the list of direct reverse dependencies and send
a bug.

If not, then why are you singling out Pidgin, a project that is
struggling to stay alive right now?

I am not singling out Pidgin. I have files similar bugs on other direct reverse
deps.

Your position in bug #996892 is that cyrus-sasl2 / libsasl2 should be considered a system library. If libsasl2 can be
considered a system library, then by your own position, there is no bug in libpurple0. I don't see how you can have it
both ways.

I would like to have a decision on it. No FTP Master has had the time to answer
the bug.
As long as there is no official stance from the responsible group in Debian
the library is not to be considered a system library and the serious severity
is valid.

If I were the package maintainer I would disable SASL and send the
unstable/testing users
who want it back to comment on #996892 to get a decision.

Bug#1036113: libpurple0: license conflict with libsasl2


Bastian,

I see you have raised the severity on this bug again.

What is your goal here?

Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500. 
Quickly taking that list through UDD gives me just over 4,500 source 
packages. Surely, a large number of those are going to be GPL licensed. 
Is your plan to file Severity: serious bugs against all of them?


  If so, isn't that an MBF that needs discussion on debian-devel first?

  If not, then why are you singling out Pidgin, a project that is
  struggling to stay alive right now?

Your position in bug #996892 is that cyrus-sasl2 / libsasl2 should be 
considered a system library. If libsasl2 can be considered a system 
library, then by your own position, there is no bug in libpurple0. I 
don't see how you can have it both ways.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018018: marked as done (wmforkplop: FTBFS with imlib2 1.9.1)

Your message dated Tue, 27 Jun 2023 21:20:27 +
with message-id 
and subject line Bug#1018018: fixed in wmforkplop 0.9.3-3
has caused the Debian Bug report #1018018,
regarding wmforkplop: FTBFS with imlib2 1.9.1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1018018: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018018
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wmforkplop
Version: 0.9.3-2.2
Severity: important
Tags: ftbfs sid bookwork
User: a...@debian.org
Usertags: imlib2-1.9.1
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

your package fails to build from source with imlib2 1.9.1 in
experimental. imlib2-config has been dropped by upstream in favor of
pkg-config. Please adjust your build system accordingly. I intend to
upload imlib2 1.9.1 to unstable in one or two months. Feel free to
reply to this bug report if you have any questions.

Regards,

Markus




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

Kernel: Linux 5.10.0-17-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 wmforkplop depends on:
ii  fonts-dejavu2.37-2
ii  libc6   2.31-13+deb11u3
ii  libglib2.0-02.66.8-1
pn  libgtop-2.0-10  
ii  libgtop-2.0-11  2.40.0-2
ii  libice6 2:1.0.10-1
pn  libimlib2   
ii  libsm6  2:1.2.3-1
ii  libx11-62:1.7.2-1
ii  libxext62:1.3.3-1.1
pn  ttf-dejavu  

wmforkplop recommends no packages.

wmforkplop suggests no packages.
--- End Message ---
--- Begin Message ---
Source: wmforkplop
Source-Version: 0.9.3-3
Done: Boyuan Yang 

We believe that the bug you reported is fixed in the latest version of
wmforkplop, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1018...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Boyuan Yang  (supplier of updated wmforkplop package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 27 Jun 2023 16:43:04 -0400
Source: wmforkplop
Architecture: source
Version: 0.9.3-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Boyuan Yang 
Closes: 1018018
Changes:
 wmforkplop (0.9.3-3) unstable; urgency=medium
 .
   * QA upload.
   * debian/control:
 + Orphan the package. (See #1035724)
   * debian/patches/0006-configure.ac-IMLIB2-use-PKG_CHECK_MODULES.patch:
 Add patch to fix compatibility with imlib2 1.9+. (Closes: #1018018)
   * debian/: Apply "wrap-and-sort -abst".
   * debian/copyright: Migrate to machine-readable format.
Checksums-Sha1:
 b02cbd0d08020d01c2c184be32a4d9c418c031bb 1938 wmforkplop_0.9.3-3.dsc
 13a2f3747f5dab420c8a0d542fca773a65ca6b53 186250 wmforkplop_0.9.3.orig.tar.gz
 a9736be4999304467142680e2592d140dcd650d0 6976 wmforkplop_0.9.3-3.debian.tar.xz
 96c4d25efd368d7d3bd64938ef4d6d456cccedf4 12755 
wmforkplop_0.9.3-3_amd64.buildinfo
Checksums-Sha256:
 25676a8dce73754e80b8b176892afe5542b7e831b83c9ae89a81bda548ef5af6 1938 
wmforkplop_0.9.3-3.dsc
 59f2194e855678866901cb469de50ff76b67698ba9e9f346fbacaccc4451216c 186250 
wmforkplop_0.9.3.orig.tar.gz
 06fd7f62695fc90b978e88c65dc326c4675026c49c2ea0d1e50e8570a1454e6a 6976 
wmforkplop_0.9.3-3.debian.tar.xz
 a80d56d527cd4fb0b56b9f6581d0503a6c8056e618715b0c3543253e98e56e58 12755 
wmforkplop_0.9.3-3_amd64.buildinfo
Files:
 ef48296831400690133111e5af43b228 1938 x11 optional wmforkplop_0.9.3-3.dsc
 e78eed8382e4dc1629dc946cb55c69f4 186250 x11 optional 
wmforkplop_0.9.3.orig.tar.gz
 07e03c6ec15e86a8eb48f65aced68416 6976 x11 optional 
wmforkplop_0.9.3-3.debian.tar.xz
 a6e43393781daf4789bc318bac0bd1b7 12755 x11 optional 
wmforkplop_0.9.3-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmSbSn0ACgkQwpPntGGC
Ws68MA/9Fph5QVYzVuiEzZ4GTSRyiXuHSPi4il65NkTJO0kN7ny/xe3ev4bTN+jR
un3HPNNU2uw6WV6DdTlx75hrBe9FELXVoA/TwQf+Iw43JOKiaWafthIWlXWazlct

Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt


Control: tag -1 patch

On 27/06/2023 19.21, Richard Lewis wrote:

header.txt has not been modified since 2015.


I've found three versions (with sightly different spelling):
* lenny
* squeeze, wheezy, jessie
* stretch .. today


it is a simple yext file that is installed with debian/logcheck.install

the only change is that it used to be installed into /usr/share but got
moved to /etc to be a conffile in 2021. This didnt trigger any piuparts
issues and there was no change to the contents of header.txt.


It has been copied during initial install only and was never upgraded. 
If the system was installed before stretch, the header.txt does not 
match the current one and dpkg will complain when replacing it with a 
proper conffile.



So i dont understand how piuparts found an issue - is it possible to tell
us what difference piuparts actually detected?


dpkg found that the files are different. This is a non-default piuparts 
test, testing every package starting from jessie (or even earlier) and 
upgrading release by release to testing takes a lot of time (and didn't 
finish before the release happened), but sometimes reveals interesting 
things ;-)


Attached patch should fix this long upgrade path. The preinst checks 
whether header.txt matches a known shipped (but not current) variant and 
tries to update it to the current variant. It seems to work fine when 
starting from jessie, more tests will be running over night.


Andreas

PS: please don't mix this fix with other changes not intended for 
bookworm, s.t. it can go to sid as 1.4.3 and be rebuilt for bookworm as 
1.4.3~deb12u1 in order not to break the version constraintsFrom 869fcc671751e3a5309848541df2d82744cdfba8 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Tue, 27 Jun 2023 21:29:06 +0200
Subject: [PATCH] update ancient header.txt in preinst

---
 debian/changelog|  8 
 debian/logcheck.preinst | 21 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/logcheck.preinst

diff --git a/debian/changelog b/debian/changelog
index 3c46c56e..567896a7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+logcheck (1.4.3) UNRELEASED; urgency=medium
+
+  * Add logcheck.preinst to upgrade header.txt if it matches a known shipped
+version predating stretch to avoid dpkg complaining about a modified
+conffile.  (Closes: #1039591)
+
+ -- Andreas Beckmann   Tue, 27 Jun 2023 20:05:42 +0200
+
 logcheck (1.4.2) unstable; urgency=medium
 
   * More explicitly mention the default checking of the systemd journal
diff --git a/debian/logcheck.preinst b/debian/logcheck.preinst
new file mode 100644
index ..a2bc04d0
--- /dev/null
+++ b/debian/logcheck.preinst
@@ -0,0 +1,21 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = "install" ] || [ "$1" = "upgrade" ]; then
+	if dpkg --compare-versions "$2" lt-nl "1.4.3~" ; then
+		# Update /etc/logcheck/header.txt if it matches a known
+		# shipped version predating stretch to avoid dpkg
+		# complaining about a modified conffile
+		if [ -f "/etc/logcheck/header.txt" ] && [ -f "/usr/share/logcheck/header.txt" ]; then
+			# d9206d89f2f8d85d346a23da90459862 (lenny)
+			# a32fc12d69628d96756fd3af3f8b3ecd (squeeze-jessie)
+			md5=$(md5sum "/etc/logcheck/header.txt" | awk '{print $1}')
+			if [ "$md5" = "d9206d89f2f8d85d346a23da90459862" ] ||
+			   [ "$md5" = "a32fc12d69628d96756fd3af3f8b3ecd" ]; then
+cp -p -v /usr/share/logcheck/header.txt /etc/logcheck
+			fi
+		fi
+	fi
+fi
+
+#DEBHELPER#
-- 
2.20.1

Processed: Re: Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt

Processing control commands:

> tag -1 patch
Bug #1039591 [logcheck] logcheck: prompting due to modified conffiles which 
were not modified by the user: /etc/logcheck/header.txt
Added tag(s) patch.

-- 
1039591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039591
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 1028124

Processing commands for cont...@bugs.debian.org:

> tags 1028124 + sid
Bug #1028124 {Done: Andreas Tille } [r-cran-hunspell] 
r-cran-hunspell: old copy of internal hunspell headers breaks (autopkg)test 
with hunspell 1.7.2
Added tag(s) sid.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1028124: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: severity of 1028124 is serious

Processing commands for cont...@bugs.debian.org:

> # hunspell 1.7.2 is now in unstable
> severity 1028124 serious
Bug #1028124 {Done: Andreas Tille } [r-cran-hunspell] 
r-cran-hunspell: old copy of internal hunspell headers breaks (autopkg)test 
with hunspell 1.7.2
Severity set to 'serious' from 'important'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1028124: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1035347: marked as done (boxer-data: generates dependencies on no longer installable lightning)

Your message dated Tue, 27 Jun 2023 20:07:47 +
with message-id 
and subject line Bug#1035347: fixed in boxer-data 10.8.28+deb11u1
has caused the Debian Bug report #1035347,
regarding boxer-data: generates dependencies on no longer installable lightning
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1035347: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035347
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: boxer-data
Version: 10.8.28
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: fixed -1 10.9.4
Control: block 1000737 with -1
Control: block 1035344 with -1

src:thunderbird has stopped building the lightning package as part of a
stable update, rendering parl-desktop and design-desktop uninstallable
in stable. In order to rebuild them with changed dependencies,
boxer-data needs to be updated in bullseye first.


Andreas
--- End Message ---
--- Begin Message ---
Source: boxer-data
Source-Version: 10.8.28+deb11u1
Done: Andreas Beckmann 

We believe that the bug you reported is fixed in the latest version of
boxer-data, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1035...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Beckmann  (supplier of updated boxer-data package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 26 Jun 2023 17:34:18 +0200
Source: boxer-data
Architecture: source
Version: 10.8.28+deb11u1
Distribution: bullseye
Urgency: medium
Maintainer: Boxer developers 
Changed-By: Andreas Beckmann 
Closes: 1035347
Changes:
 boxer-data (10.8.28+deb11u1) bullseye; urgency=medium
 .
   [ Andreas Beckmann ]
   * Non-maintainer upload.
   * Backport thunderbird compatibility fixes from sid.
 .
   [ Jonas Smedegaard ]
   * update class Desktop.scheduling.lightning:
 stop install package lightning (gone)
   * update class Desktop.email.thunderbird.locale:
 + update subclass ASIA to stop include package thunderbird-l10n-si
 (Closes: #1035347)
Checksums-Sha1:
 02ec5bf72966a0741876a3aa4b91108d382ea688 1780 boxer-data_10.8.28+deb11u1.dsc
 5b554bba4defdcc5330a3555c8de7c66ffbae455 94428 
boxer-data_10.8.28+deb11u1.tar.xz
 aeb6936658841de3d80ff56b25f1d24c6e1db153 8016 
boxer-data_10.8.28+deb11u1_source.buildinfo
Checksums-Sha256:
 3991bc5c1061d79b63fe3b75743948a4927d42569d3c058752ef7f821d0bdaa1 1780 
boxer-data_10.8.28+deb11u1.dsc
 d3fe8c35f7c42f69729d601f513207075192ad1aecf3d6744f4be72987f337cd 94428 
boxer-data_10.8.28+deb11u1.tar.xz
 a3bf493375b1c2489b504e9701544816751bb981088bc79b1252d21fafc73e98 8016 
boxer-data_10.8.28+deb11u1_source.buildinfo
Files:
 f8da43f03960e7a22c51235a9da6f977 1780 misc optional 
boxer-data_10.8.28+deb11u1.dsc
 4761f881c8ee156e3444e2ff60e2bf53 94428 misc optional 
boxer-data_10.8.28+deb11u1.tar.xz
 44eabeeb4a02b7d6f36062ae004a2c60 8016 misc optional 
boxer-data_10.8.28+deb11u1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAmSZsX0QHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCB6HD/9SNGrCyahwX2KmBpZnMOC7Tmzm6mDdL3Nq
zIPI0q19XDml/+q7SmjQXXoVPoi/Ek3QtmwPYYoNZ5I+JzASWd8/Dx4YwEmBxr5C
TdNPq2IGv2nOu/5j9XYjrmu30Gjrc6D2PwhSrf+xrZqOAv4oh0FVE35siWyCyS8f
UhfcN1Z175gXn+Sm/cn8v3i8GzzSRCsI/Ko4k4EABx4g3/RQy0Wbixenthd3MFCQ
8ocu2IODSkiYnB0u5GDe8mqd4AlnbJC+wVl9GWBfHWHt72r/K4VplGRlCFtjlhVu
5t7JFuEkmbeI6hUKP2m9Ccmv2GkFdC7FlIqTiZYXsuypy0cF5C1/x3e/8JcxLQQE
oQExAhanatweuZSe64tw45wUFuFahS1+b6g/36lZX3Hfl/FZJoR6flulx6qUCO/O
qGez7mX5/YzzGGlFbzYjdNUJgkzWzU0q5oOHyu2Zs1Fr4LY820OFiVEO7OM4omat
+e6pQAjMBRWcylgnNAHSnzpTi83fXuN0Tneve8WH09tiQPnHBFo30pg6tIcwxCDF
TpiI3lPf9j3QAl1jAnMm4saVh3EWu1RJ96MuWue1BhzUJxUBRtkqDgMcq4mk6eKm
D3qgvCl/6Tqz/PULykkHQ3cBHnU/Q0Dpt8SYLihNaQI2l22en9e/In9Pk/t0LxO5
XJ5NV4XD4w==
=bN1V
-END PGP SIGNATURE End Message ---

Bug#1037926: marked as done (wike: version 2.0.1-2 failed to start)

Your message dated Tue, 27 Jun 2023 19:59:10 +
with message-id 
and subject line Bug#1037926: fixed in wike 2.0.1-3
has caused the Debian Bug report #1037926,
regarding wike: version 2.0.1-2 failed to start
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1037926: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037926
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wike
Version: 2.0.1-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: edo...@gmail.com

Hi, after upgrading the package from wike:amd64 1.8.2-1 -> 2.0.1-2 it doesn't
work anymore.

Starting it from a terminal throws the error:

-
(wike:456499): Gtk-CRITICAL **: 09:14:42.409: Error building template class
'Window' for an instance of type 'Window': .:0:0 Invalid object type
'AdwTabOverview'
Traceback (most recent call last):
  File "/usr/share/wike/wike/application.py", line 105, in do_activate
self._window = Window(self, self._launch_uri)
   ^^
  File "/usr/share/wike/wike/window.py", line 57, in __init__
tabpage = self.tabview.append(self.page)
  ^^^
AttributeError: 'NoneType' object has no attribute 'append'
-

And hangs there, you need to kill the process.

Downgrading back to 1.8.2-1 using snapshot.debian.org make it work again so the
problem is with the new version or some dependency. I'm not used to Python, but
seems to try to use a class that doesn't exists in the new version of some
dependency?.

Thanks for all and let me know if you need anything else to help solving this
issue.
Ernesto


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

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

Versions of packages wike depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-adw-1 1.2.4-1
ii  gir1.2-webkit-6.02.40.2-1
ii  python3  3.11.2-1+b1
ii  python3-requests 2.28.1+dfsg-1

wike recommends no packages.

wike suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: wike
Source-Version: 2.0.1-3
Done: Jeremy Bícha 

We believe that the bug you reported is fixed in the latest version of
wike, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1037...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jeremy Bícha  (supplier of updated wike package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 27 Jun 2023 14:54:57 -0400
Source: wike
Built-For-Profiles: noudeb
Architecture: source
Version: 2.0.1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers 

Changed-By: Jeremy Bícha 
Closes: 1037926
Changes:
 wike (2.0.1-3) unstable; urgency=medium
 .
   * Bump minimum libadwaita to 1.3 (Closes: #1037926)
   * Add a Build-Depends on libadwaita 1.3
Checksums-Sha1:
 eff4ee5a27dbdd9e1d36b632cffc4c0933d6c2c0 2020 wike_2.0.1-3.dsc
 305a03673c0b7b0bb6a30eb8d812f01503027b46 8796 wike_2.0.1-3.debian.tar.xz
 813bd7b61ac28604544a753b1468c42d1c2ce9ed 16677 wike_2.0.1-3_source.buildinfo
Checksums-Sha256:
 0f9626654b3f96baf1c7cfcd00e0db0b14fcbf7ae51c02ca9e092a26e80f845e 2020 
wike_2.0.1-3.dsc
 493e815f8c89ec1546b775da551ed31aafc54b8dc8f8fbffb61545759a92682f 8796 
wike_2.0.1-3.debian.tar.xz
 df39929d2bb8af43036b6bb45e60e584f31c752b1a0b3c998d019625e2766c8b 16677 
wike_2.0.1-3_source.buildinfo
Files:
 20b257321c01ddf6a743775a9d019a38 2020 gnome optional wike_2.0.1-3.dsc
 1e86d382e2c810c648dedc2640a94a1a 8796 gnome optional wike_2.0.1-3.debian.tar.xz
 7825f255626b1638fae6e9d9e978f63b 16677 gnome optional 
wike_2.0.1-3_source.buildinfo

-BEGIN PGP SIGNATURE-

Bug#1039614: python-can: autopkgtest regression on amd64 and s390x: KeyError: 'link_type'


Source: python-can
Version: 4.2.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-can the autopkgtest of python-can fails 
in testing when that autopkgtest is run with the binary packages of 
python-can from unstable on amd64 or s390x. It passes when run with only 
packages from testing. In tabular form:


   passfail
python-can from testing4.2.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-can

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-can/34896619/log.gz

=== FAILURES 
===
 64s __ TestDetectAvailableConfigs.test_content_socketcan 
___
 64s  64s self = 
testMethod=test_content_socketcan>

 64s  64s def test_content_socketcan(self):
 64s >   configs = detect_available_configs(interfaces="socketcan")
 64s  64s test_detect_available_configs.py:44:  64s _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  64s 
/usr/lib/python3/dist-packages/can/interface.py:186: in 
detect_available_configs
 64s bus_class._detect_available_configs()  # pylint: 
disable=protected-access
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/socketcan.py:878: 
in _detect_available_configs

 64s for channel in find_available_interfaces()
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: in 
find_available_interfaces
 64s interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]
 64s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _  64s  64s .0 = 
 64s  64s >   interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]

 64s E   KeyError: 'link_type'
 64s  64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: 
KeyError
 64s  TestDetectAvailableConfigs.test_count_returned 

 64s  64s self = 
testMethod=test_count_returned>

 64s  64s def test_count_returned(self):
 64s # At least virtual has to always return at least one interface
 64s >   self.assertGreaterEqual(len(detect_available_configs()), 1)
 64s  64s test_detect_available_configs.py:18:  64s _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  64s 
/usr/lib/python3/dist-packages/can/interface.py:186: in 
detect_available_configs
 64s bus_class._detect_available_configs()  # pylint: 
disable=protected-access
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/socketcan.py:878: 
in _detect_available_configs

 64s for channel in find_available_interfaces()
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: in 
find_available_interfaces
 64s interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]
 64s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _  64s  64s .0 = 
 64s  64s >   interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]

 64s E   KeyError: 'link_type'
 64s  64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: 
KeyError
 64s  TestDetectAvailableConfigs.test_general_values 

 64s  64s self = 
testMethod=test_general_values>

 64s  64s def test_general_values(self):
 64s >   configs = detect_available_configs()
 64s  64s test_detect_available_configs.py:27:  64s _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  64s 
/usr/lib/python3/dist-packages/can/interface.py:186: in 
detect_available_configs
 64s bus_class._detect_available_configs()  # pylint: 
disable=protected-access
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/socketcan.py:878: 
in _detect_available_configs

 64s for channel in find_available_interfaces()
 64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: in 
find_available_interfaces
 64s interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]
 64s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _  64s  64s .0 = 
 64s  64s >   interfaces = [i["ifname"] for i in output_json if 
i["link_type"] == "can"]

 64s E   KeyError: 'link_type'
 64s  64s 
/usr/lib/python3/dist-packages/can/interfaces/socketcan/utils.py:69: 
KeyError
 64s === short test summary info 

 64s FAILED

Processed: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

Processing control commands:

> found -1 nmap/7.94+dfsg1-1
Bug #1039613 [src:nmap, src:udptunnel] nmap breaks udptunnel autopkgtest: 
UDPTunnel communication failed
Marked as found in versions nmap/7.94+dfsg1-1.
> found -1 udptunnel/1.1-9
Bug #1039613 [src:nmap, src:udptunnel] nmap breaks udptunnel autopkgtest: 
UDPTunnel communication failed
Marked as found in versions udptunnel/1.1-9.

-- 
1039613: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039613
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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


Source: nmap, udptunnel
Control: found -1 nmap/7.94+dfsg1-1
Control: found -1 udptunnel/1.1-9
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of nmap the autopkgtest of udptunnel fails in 
testing when that autopkgtest is run with the binary packages of nmap 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
nmap   from testing7.94+dfsg1-1
udptunnel  from testing1.1-9
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of nmap to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=nmap

https://ci.debian.net/data/autopkgtest/testing/amd64/u/udptunnel/34896613/log.gz

33s udp0  0 127.0.0.1:5500  0.0.0.0:*
36s tcp0  0 0.0.0.0:64910.0.0.0:* 
LISTEN
39s udp0  0 0.0.0.0:66610.0.0.0:* 
   39s 1,7d0

39s < THIS
39s <  IS
39s <   THE
39s

Bug#1039612: libtool: Incorrect check for += operator causes func_append to fail

2023-06-27 Thread Ernesto Alfonso

Package: libtool
Version: 2.4.6-15
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: erjoa...@gmail.com

Dear Maintainer,

While building isc-dhcpd-server, I tried using autoreconf as per instructions
to generate the ./configure file.
But running `autoreconf -i` on this project failed with this error:

/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
/usr/bin/libtoolize: 1: eval: hookable_fns+=: not found
libtoolize:   error: 'func_options_prep' does not accept hook functions.
autoreconf: libtoolize failed with exit status: 1

Some others have reported this error, but the solution mentioned in that thread
was to run as root, which I shouldn't have to do to build in a local directory:

https://github.com/libsndfile/libsndfile/issues/132#issue-153391414

Looking at the source, I noticed the problem is not that
`func_options_prep does not accept hook functions`,
but that the script assumes the append operator `+=` works when it doesn't.

This assumption is based on the value of BASH_VERSION, but unfortunately this 
is not reliable:


if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then
: ${_G_HAVE_ARITH_OP="yes"}
: ${_G_HAVE_XSI_OPS="yes"}
# The += operator was introduced in bash 3.1
case $BASH_VERSION in
  [12].* | 3.0 | 3.0*) ;;
  *)
: ${_G_HAVE_PLUSEQ_OP="yes"} # not really!
;;
esac
  fi


It's not reliable because on my system, plain debian 11, /bin/sh is linked to
/usr/bin/dash, but the BASH_VERSION environment variable appears to have been
inherited from the bash process on my terminal and it is not
modified or deleted by dash. And += doesn't work in dash:

█[debian-x1-7th][isc-dhcp-4.4.1][0]$ ls -l /usr/bin/sh
lrwxrwxrwx 1 root root 4 Apr 27 17:06 /usr/bin/sh -> dash
█[debian-x1-7th][isc-dhcp-4.4.1][130]$ dash
\[\]█\[\][\h][\W][0]$ \[\]echo $BASH_VERSION
5.1.4(1)-release
\[\]█\[\][\h][\W][0]$ \[\]a=1
\[\]█\[\][\h][\W][0]$ \[\]a+=2
dash: 3: a+=2: not found
\[\]█\[\][\h][\W][127]$ \[\]


There's some advice online about how to find the true name of the shell:
https://stackoverflow.com/questions/23011370/ but I think it is too
complicated and error prone, and I think
the simplest way to correct this is to actually test for the feature directly
as is already being done in the script:

(eval 'x=a; x+=" b"; test "a b" = "$x"') && _G_HAVE_PLUSEQ_OP=yes


There is a comment expressing concern about speed of the test above and about
minimizing forks:


# We should try to minimise forks, especially on Windows where they are
# unreasonably slow, so skip the feature probes when bash or zsh are
# being used:

But I don't see any reason for needing a fork here:

if test -z "$_G_HAVE_PLUSEQ_OP" &&  \
__PLUSEQ_TEST="a" &&  \
__PLUSEQ_TEST+=" b" 2>/dev/null &&  \
test "a b" = "$__PLUSEQ_TEST"; then
  _G_HAVE_PLUSEQ_OP=yes
fi


Even if a fork were needed, I don't think the possible speedup of avoiding the
a one-line feature probe is worth the risk of breaking users who
invoke this script from a parent bash terminal.

I'm including my suggested patch inline below:


527,547c527,535
<   # We should try to minimise forks, especially on Windows where they are
<   # unreasonably slow, so skip the feature probes when bash or zsh are
<   # being used:
<   if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then
< : ${_G_HAVE_ARITH_OP="yes"}
< : ${_G_HAVE_XSI_OPS="yes"}
< # The += operator was introduced in bash 3.1
< case $BASH_VERSION in
<   [12].* | 3.0 | 3.0*) ;;
<   *)
< : ${_G_HAVE_PLUSEQ_OP="yes"}
< ;;
< esac
<   fi
< 
<   # _G_HAVE_PLUSEQ_OP
<   # Can be empty, in which case the shell is probed, "yes" if += is
<   # useable or anything else if it does not work.
<   test -z "$_G_HAVE_PLUSEQ_OP" \
< && (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null \
< && _G_HAVE_PLUSEQ_OP=yes
---
> # _G_HAVE_PLUSEQ_OP
> # Can be empty, in which case the shell is probed, "yes" if += is
> # usable or anything else if it does not work.
> if test -z "$_G_HAVE_PLUSEQ_OP" &&  \
> __PLUSEQ_TEST="a" &&  \
> __PLUSEQ_TEST+=" b" 2>/dev/null &&  \
> test "$__PLUSEQ_TEST" = "a b"; then
>   _G_HAVE_PLUSEQ_OP=yes
> fi

Thanks,

Ernesto

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')

Processed: celery breaks python-django-celery-beat autopkgtest: 'zoneinfo.ZoneInfo' object has no attribute 'zone'

Processing control commands:

> found -1 celery/5.3.1-1
Bug #1039611 [src:celery, src:python-django-celery-beat] celery breaks 
python-django-celery-beat autopkgtest: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'
Marked as found in versions celery/5.3.1-1.
> found -1 python-django-celery-beat/2.4.0-1
Bug #1039611 [src:celery, src:python-django-celery-beat] celery breaks 
python-django-celery-beat autopkgtest: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'
Marked as found in versions python-django-celery-beat/2.4.0-1.

-- 
1039611: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039611
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1039611: celery breaks python-django-celery-beat autopkgtest: 'zoneinfo.ZoneInfo' object has no attribute 'zone'


Source: celery, python-django-celery-beat
Control: found -1 celery/5.3.1-1
Control: found -1 python-django-celery-beat/2.4.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of celery the autopkgtest of 
python-django-celery-beat fails in testing when that autopkgtest is run 
with the binary packages of celery from unstable. It passes when run 
with only packages from testing. In tabular form:


  passfail
celeryfrom testing5.3.1-1
python-django-celery-beat from testing2.4.0-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of celery to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=celery

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-celery-beat/34896121/log.gz

=== FAILURES 
===
 63s _ test_ModelEntry.test_entry_is_due__no_use_tz 
_
 63s  63s self = 0x7f96b9886b90>

 63s  63s @override_settings(
 63s USE_TZ=False,
 63s DJANGO_CELERY_BEAT_TZ_AWARE=False
 63s )
 63s @pytest.mark.usefixtures('depends_on_current_app')
 63s @timezone.override('Europe/Berlin')
 63s @pytest.mark.celery(timezone='Europe/Berlin')
 63s def test_entry_is_due__no_use_tz(self):
 63s old_tz = os.environ.get("TZ")
 63s os.environ["TZ"] = "Europe/Berlin"
 63s if hasattr(time, "tzset"):
 63s time.tzset()
 63s >   assert self.app.timezone.zone == 'Europe/Berlin'
 63s E   AttributeError: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'

 63s  63s t/unit/test_schedulers.py:162: AttributeError
 63s _ 
test_ModelEntry.test_entry_and_model_last_run_at_with_utc_no_use_tz __
 63s  63s self = 0x7f96b90f5ad0>
 63s monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 
0x7f96b9364050>

 63s  63s @override_settings(
 63s USE_TZ=False,
 63s DJANGO_CELERY_BEAT_TZ_AWARE=False
 63s )
 63s @pytest.mark.usefixtures('depends_on_current_app')
 63s @timezone.override('Europe/Berlin')
 63s @pytest.mark.celery(timezone='Europe/Berlin')
 63s def test_entry_and_model_last_run_at_with_utc_no_use_tz(self, 
monkeypatch):

 63s old_tz = os.environ.get("TZ")
 63s os.environ["TZ"] = "Europe/Berlin"
 63s if hasattr(time, "tzset"):
 63s time.tzset()
 63s >   assert self.app.timezone.zone == 'Europe/Berlin'
 63s E   AttributeError: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'

 63s  63s t/unit/test_schedulers.py:194: AttributeError
 63s __ 
test_ModelEntry.test_entry_is_due__celery_timezone_doesnt_match_time_zone 
___
 63s  63s self = 0x7f96b90f5350>

 63s  63s @override_settings(
 63s USE_TZ=False,
 63s DJANGO_CELERY_BEAT_TZ_AWARE=False,
 63s TIME_ZONE="Europe/Berlin",
 63s CELERY_TIMEZONE="America/New_York"
 63s )
 63s @pytest.mark.usefixtures('depends_on_current_app')
 63s @timezone.override('Europe/Berlin')
 63s @pytest.mark.celery(timezone='America/New_York')
 63s def 
test_entry_is_due__celery_timezone_doesnt_match_time_zone(self):

 63s old_tz = os.environ.get("TZ")
 63s os.environ["TZ"] = "Europe/Berlin"
 63s if hasattr(time, "tzset"):
 63s time.tzset()
 63s >   assert self.app.timezone.zone == 'America/New_York'
 63s E   AttributeError: 'zoneinfo.ZoneInfo' object has no 
attribute 'zone'

 63s  63s t/unit/test_schedulers.py:230: AttributeError
 63s === warnings summary 
===

 63s ../../../../usr/lib/python3/dist-packages/django/http/request.py:1
 63s   /usr/lib/python3/dist-packages/django/http/request.py:1: 
DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 
3.13

 63s import cgi
 63s  63s 
../../../../usr/lib/python3/dist-packages/django/utils/encoding.py:266
 63s   /usr/lib/python3/dist-packages/django/utils/encoding.py:266: 
DeprecationWarning: Use setlocale(), getencoding() and getlocale() instead

 63s encoding = locale.getdefaultlocale()[1] or 'ascii'
 63s  63s -- Docs: 
https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 63s === short test summary info 

 63s FAILED 
t/unit/test_schedulers.py::test_ModelEntry::test_entry_is_due__no_use_tz
 63s FAILED

Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?

2023-06-27 Thread Dirk Eddelbuettel



Hi Paul,

On 27 June 2023 at 20:08, Paul Gevers wrote:
| Hi Dirk,
| 
| On 26-06-2023 22:21, Dirk Eddelbuettel wrote:
| > I really appreciate the diligence and detail you put into this.
| > 
| > But I would like to offer a simple shortcut.  I am also CCing debian-r again
| > as this has come up time and time again, is guaranteed to come up again for
| > as long as combine autopkgtests with letting packages go stake.
| 
| Somehow I feel you missed my point. In Debian we also care about 
| preventing partial upgrades doing the wrong thing. I explicitly noted 
| that in unstable everything is fine, so I think I acknowledge what you 
| said. However, for the migration to automatically happen and to 
| (possibly, I leave that for you (packages maintainers) to judge) prevent 
| issues with partial upgrades there needs to be some *versioned* package 
| relation somewhere.

I am not a fan of accomodating outdated packages in Debian by means of
imposed constraints _which then differ from perfectly viable and sane
upstream uses_ and am not here for it.  Life is too short: just under 20k
CRAN packages, (last I checked) just over 1k in Debian -- and once you allow
for "random" package combination (which, I repeat, are untested upstream in
these combinations) you essentially get yourself an infinity of possible
combinations.  There lies madness.

Dirk

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

Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?


Hi Dirk,

On 26-06-2023 22:21, Dirk Eddelbuettel wrote:

I really appreciate the diligence and detail you put into this.

But I would like to offer a simple shortcut.  I am also CCing debian-r again
as this has come up time and time again, is guaranteed to come up again for
as long as combine autopkgtests with letting packages go stake.


Somehow I feel you missed my point. In Debian we also care about 
preventing partial upgrades doing the wrong thing. I explicitly noted 
that in unstable everything is fine, so I think I acknowledge what you 
said. However, for the migration to automatically happen and to 
(possibly, I leave that for you (packages maintainers) to judge) prevent 
issues with partial upgrades there needs to be some *versioned* package 
relation somewhere.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012232: freespace2: FTBFS with libsdl1.2-compat-dev: 'malloc_usable_size' was not declared in this scope

2023-06-27 Thread Simon McVittie

Control: retitle -1 freespace2: FTBFS with libsdl1.2-compat-dev: 
'malloc_usable_size' was not declared in this scope

(cc'ing adetiste because he was looking at this package recently; the
SDL2-based new upstream version will close both #1038352 and this bug,
assuming the SDL2 version compiles successfully)

On Mon, 20 Feb 2023 at 09:35:59 +0100, Andreas Beckmann wrote:
> The actual problem are missing
>   Build-Depends: pkg-config, libglu1-mesa-dev
> These were pulled in transitively in bullseye.

The actual actual problem :-) is that freespace2 build-depends on
libsdl-dev, a virtual package, and not on libsdl1.2-dev, a concrete
implementation of that virtual package. This means that buildds and other
build environments will choose either libsdl1.2-dev (currently "classic"
SDL 1.2) or libsdl1.2-compat-dev, arbitrarily. That makes this bug RC,
while in other packages with "FTBFS with libsdl1.2-compat-dev" bugs,
the bug is usually not RC yet.

libsdl1.2-compat-dev didn't exist in bullseye, and "classic" SDL 1.2 always
pulled in libglu1-mesa-dev (see #1039072) and pkg-config (see #1039074),
which is why this worked in bullseye. It will not be reliable in bookworm,
which does have libsdl1.2-compat-dev available.

libsdl1.2-compat-dev (>= 1.2.64-3) works around this class of bug by
depending on pkgconf and libglu1-mesa-dev, so this part is not critical
to address in freespace2.

It is still a good idea to have an explicit build-dependency on anything
that the package explicitly uses, to avoid being broken by "action at
a distance" in a dependency.

It would also be a good idea to switch the build-dependency to
the concrete package, libsdl1.2-dev. At the moment, this is "classic"
SDL 1.2. My intention is that before the trixie freeze, sdl12-compat
will take over that binary package name, so Build-Depends: libsdl1.2-dev
will still be the correct thing for SDL 1.2 codebases to use.

The other part of this FTBFS *is* release-critical to address in
freespace2 if not worked around in libsdl1.2-compat-dev:

> Then you need to make the inclusion of malloc.h unconditional in
> code/windows_stub/stubs.cpp (or fix the build system s.t. it checks for
> malloc.h and populates HAVE_MALLOC_H accordingly).

This is also triggered by using libsdl1.2-compat-dev. The headers in
that package aim to be compatible with the ones in libsdl1.2-dev, but for
licensing reasons they are partially a rewrite, and for maintainability
reasons they differ in various implementation details.

In this case, the error seen is:

windows_stub/stubs.cpp: In function 'void* _vm_malloc(int, char*, int, int)':
windows_stub/stubs.cpp:49:32: error: 'malloc_usable_size' was not declared in 
this scope
   49 | #define MALLOC_USABLE(pointer) malloc_usable_size(pointer)
  |^~
windows_stub/stubs.cpp:627:28: note: in expansion of macro 'MALLOC_USABLE'
  627 | size_t used_size = MALLOC_USABLE(ptr);
  |^
windows_stub/stubs.cpp: In function 'void* _vm_realloc(void*, int, char*, int, 
int)':
windows_stub/stubs.cpp:49:32: error: 'malloc_usable_size' was not declared in 
this scope
   49 | #define MALLOC_USABLE(pointer) malloc_usable_size(pointer)
  |^~
windows_stub/stubs.cpp:649:27: note: in expansion of macro 'MALLOC_USABLE'
  649 | size_t old_size = MALLOC_USABLE(ptr);
  |   ^
windows_stub/stubs.cpp: In function 'void _vm_free(void*, char*, int)':
windows_stub/stubs.cpp:49:32: error: 'malloc_usable_size' was not declared in 
this scope
   49 | #define MALLOC_USABLE(pointer) malloc_usable_size(pointer)
  |^~
windows_stub/stubs.cpp:731:21: note: in expansion of macro 'MALLOC_USABLE'
  731 | TotalRam -= MALLOC_USABLE(ptr);
  | ^

This appears to be because freespace2 checks #ifdef HAVE_MALLOC_H,
but never actually checks for malloc.h, so it was accidentally relying
on SDL's SDL_config.h to leak information about the headers that SDL
uses internally. Here is a patch that is sufficient to resolve this part
of the bug:

8<
diff --git a/configure.ac b/configure.ac
index d850f85..af54a1e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -311,6 +311,7 @@ AM_CONDITIONAL(FS2_DEBUG,  test "$fs2_debug"  = 
"yes")
 AM_CONDITIONAL([am__fastdepOBJC],  test "$fs2_os_osx"  = "yes")

 AC_CHECK_HEADER(stdlib.h)
+AC_CHECK_HEADERS_ONCE([malloc.h])

 dnl From licq: Copyright (c) 2000 Dirk Mueller
 dnl Check if the type socklen_t is defined anywhere
8<

If a SDL2 version cannot be uploaded any time soon, please apply that
patch.

I might work around this in sdl12-compat too (I'll see what upstream
think) but this is really not SDL's job, so please add that check anyway.

Thanks,
smcv

Processed: Re: Bug#1012232: freespace2: FTBFS with libsdl1.2-compat-dev: 'malloc_usable_size' was not declared in this scope

Processing control commands:

> retitle -1 freespace2: FTBFS with libsdl1.2-compat-dev: 'malloc_usable_size' 
> was not declared in this scope
Bug #1012232 [src:freespace2] freespace2: missing B-D: pkg-config, 
libglu1-mesa-dev
Changed Bug title to 'freespace2: FTBFS with libsdl1.2-compat-dev: 
'malloc_usable_size' was not declared in this scope' from 'freespace2: missing 
B-D: pkg-config, libglu1-mesa-dev'.

-- 
1012232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012232
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt

2023-06-27 Thread Richard Lewis

header.txt has not been modified since 2015.

it is a simple yext file that is installed with debian/logcheck.install

the only change is that it used to be installed into /usr/share but got
moved to /etc to be a conffile in 2021. This didnt trigger any piuparts
issues and there was no change to the contents of header.txt.

So i dont understand how piuparts found an issue - is it possible to tell
us what difference piuparts actually detected?




On Tue, 27 Jun 2023, 15:30 Andreas Beckmann,  wrote:

> Package: logcheck
> Version: 1.4.2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package failed the piuparts
> upgrade test because dpkg detected a conffile as being modified and then
> prompted the user for an action. As there is no user input, this fails.
> But this is not the real problem, the real problem is that this prompt
> shows up in the first place, as there was nobody modifying this conffile
> at all, the package has just been installed and upgraded...
>
> This is a violation of policy 10.7.3, see
> https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
> which says "[These scripts handling conffiles] must not ask unnecessary
> questions (particularly during upgrades), and must otherwise be good
> citizens."
>
> https://wiki.debian.org/DpkgConffileHandling should help with figuring
> out how to do this properly.
>
> In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
> followups it has been agreed that these bugs are to be filed with
> severity serious.
>
> From the attached log (scroll to the bottom...):
>
>   Setting up logcheck (1.4.2) ...
>
>   Configuration file '/etc/logcheck/header.txt'
>==> File on system created by you or by a script.
>==> File also in package provided by package maintainer.
>  What would you like to do about it ?  Your options are:
>   Y or I  : install the package maintainer's version
>   N or O  : keep your currently-installed version
> D : show the differences between the versions
> Z : start a shell to examine the situation
>The default action is to keep your current version.
>   *** header.txt (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing
> package logcheck (--configure):
>end of file on stdin at conffile prompt
>   Processing triggers for debianutils (5.7-0.5~deb12anbe1) ...
>   Processing triggers for libc-bin (2.36-9) ...
>   Errors were encountered while processing:
>logcheck
>
>
> This happens up upgrade paths starting in jessie, upgrading release by
> release to bookworm.
>
>
> cheers,
>
> Andreas
>

Processed: Re: sl-modem-dkms: module fails to build for Linux 6.4

Processing control commands:

> retitle -1 sl-modem-dkms: module fails to build for Linux 6.3, 6.4
Bug #1039572 [sl-modem-dkms] sl-modem-dkms: module fails to build for Linux 6.4
Changed Bug title to 'sl-modem-dkms: module fails to build for Linux 6.3, 6.4' 
from 'sl-modem-dkms: module fails to build for Linux 6.4'.

-- 
1039572: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039572
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1039572: sl-modem-dkms: module fails to build for Linux 6.4

Followup-For: Bug #1039572
Control: retitle -1 sl-modem-dkms: module fails to build for Linux 6.3, 6.4

it also fails on i386 for Linux 6.3:

https://ci.debian.net/data/autopkgtest/testing/i386/s/sl-modem/34615841/log.gz

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.1.0-9-686-pae (i686)
Tue Jun 20 06:28:46 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m=slamr.o  slusb.o
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.1.0-9-686-pae/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-686-pae'
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/amrmo_init.o
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/amrmo_init.c: In function 
‘amrmo_unlocked_ioctl’:
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/amrmo_init.c:473:17: 
warning: ignoring return value of ‘copy_from_user’ declared with attribute 
‘warn_unused_result’ [-Wunused-result]
  473 | copy_from_user(, (unsigned long *)parg, 
sizeof(arg));
  | ^~~~
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/sysdep_amr.o
  LD [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slamr.o
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.o
  LD [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.o
  MODPOST /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers
WARNING: modpost: /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slamr.o: 
section mismatch in reference: amrmo_pci_driver (section: .data) -> 
amrmo_pci_probe (section: .init.text)
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/.amrlibs.o.cmd: No such 
file or directory
make[2]: *** 
[/usr/src/linux-headers-6.1.0-9-common/scripts/Makefile.modpost:126: 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers] Error 1
make[1]: *** [/usr/src/linux-headers-6.1.0-9-common/Makefile:1989: modpost] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-686-pae'
make: *** [Makefile:138: all] Error 2
make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
make: Entering directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'
make modules -C /lib/modules/6.1.0-9-686-pae/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-686-pae'
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.o
  MODPOST 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/Module.symvers
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.mod.o
  LD [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-686-pae'
make: Leaving directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'


Andreas

Bug#1039528: marked as done (plastimatch: FTBFS: Could not find a package configuration file provided by "VTK")

Your message dated Tue, 27 Jun 2023 16:23:07 +
with message-id 
and subject line Bug#1039528: fixed in insighttoolkit5 5.3.0-4
has caused the Debian Bug report #1039528,
regarding plastimatch: FTBFS: Could not find a package configuration file 
provided by "VTK"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1039528: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039528
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: plastimatch
Version: 1.9.4+dfsg.1-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=plastimatch=amd64=1.9.4%2Bdfsg.1-1%2Bb1=1687808525=0

-- Found HDF5: 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.so;/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so;/usr/lib/x86_64-linux-gnu/libcrypto.so;/usr/lib/x86_64-linux-gnu/libcurl.so;/usr/lib/x86_64-linux-gnu/libpthread.a;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.a;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so;/usr/lib/x86_64-linux-gnu/libcrypto.so;/usr/lib/x86_64-linux-gnu/libcurl.so;/usr/lib/x86_64-linux-gnu/libpthread.a;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.a;/usr/lib/x86_64-linux-gnu/libm.so
 (found version "1.10.8") found components: CXX C HL 
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/Modules/ITKVtkGlue.cmake:16 
(find_package):
  Could not find a package configuration file provided by "VTK" with any of
  the following names:

VTKConfig.cmake
vtk-config.cmake

  Add the installation prefix of "VTK" to CMAKE_PREFIX_PATH or set "VTK_DIR"
  to a directory containing one of the above files.  If "VTK" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKModuleAPI.cmake:76 (include)
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKModuleAPI.cmake:31 
(itk_module_load)
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKModuleAPI.cmake:129 
(_itk_module_config_recurse)
  /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKConfig.cmake:89 (itk_module_config)
  CMakeLists.txt:573 (find_package)


-- Configuring incomplete, errors occurred!
cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
==> CMakeCache.txt <==
# This is the CMakeCache file.
# For build in directory: /<>/obj-x86_64-linux-gnu
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Build plastimatch as shared library
BUILD_SHARED_LIBS:BOOL=ON

//Build the testing tree.
BUILD_TESTING:BOOL=ON

//Path to a program.
CMAKE_ADDR2LINE:FILEPATH=/usr/bin/addr2line

//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//No help, variable specified on the command line.
CMAKE_BUILD_TYPE:STRING=RELEASE

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//A wrapper around 'ar' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-12

//A wrapper around 'ranlib' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-12

//Flags used by the CXX compiler during all build types.
CMAKE_CXX_FLAGS:STRING=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2

//Flags used by the CXX compiler during DEBUG builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the CXX compiler during RELEASE builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//A wrapper around 'ar' adding the appropriate '--plugin' option
//

Bug#1039528: plastimatch: FTBFS: Could not find a package configuration file provided by "VTK"

2023-06-27 Thread Steven Robbins

On Monday, June 26, 2023 6:15:06 P.M. CDT Adrian Bunk wrote:
> Control: reassign -1 libinsighttoolkit5-dev 5.3.0-3
> Control: affects -1 src:plastimatch
> 
> There are actually tow separate issues, both in libinsighttoolkit5-dev:

Thanks for bringing this to my attention.

> 1. The VTK build dependencies for the recent VTK changes also hae to
>become dependencies of libinsighttoolkit5-dev.

I confirmed this bug, and fixed it in a rev -4 upload of ITK.  I confirmed the 
issue and the fix by building elastix, which depends on ITK in the same manner.

> In file included from
> /<>/src/plastimatch/base/dcmtk_config.h:16, from
> /<>/src/plastimatch/base/metadata.h:12, from
> /<>/src/plastimatch/base/astroid_dose.h:8, from
> /<>/src/plastimatch/base/astroid_dose.cxx:7:
> /usr/include/dcmtk/config/osconfig.h:1153:2: error: invalid preprocessing
> directive #errorDCMTK 1153 | #error\
> 
>   |  ^~
> 
>  1154 | DCMTK was configured to use C++17 features, but your compiler does
> not or was not configured to provide them.
>   | ~
> 
> 2. This is caused by libinsighttoolkit5-dev injecting -std=c++14 into
>reverse dependencies, the fix is likely something like

This is less clear to me.  Elastix also build-depends on dcmtk and doesn't 
show this issue.  I think ITK uses C++14 as a minimum but you ought to be able 
to build with higher levels.  At work, we build with a C++20 compiler.

Thus: I am closing this bug with rev -4 fixing the first mentioned issue.  If I 
am wrong about the second, please open a second bug.

Regards,
-Steve

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

Processed: your mail

Processing commands for cont...@bugs.debian.org:

> severity 1038242 serious
Bug #1038242 [rust-ashpd] Does not build against gtk 0.5
Severity set to 'serious' from 'normal'
> retitle 1038242 'Needs wayland 0.30'
Bug #1038242 [rust-ashpd] Does not build against gtk 0.5
Changed Bug title to ''Needs wayland 0.30'' from 'Does not build against gtk 
0.5'.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1038242: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038242
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1029434: marked as done (python3-pydrive2: ships md5sums without files: /usr/lib/python3/dist-packages/pydrive2/test/*)

Your message dated Tue, 27 Jun 2023 14:53:50 +
with message-id 
and subject line Bug#1029434: fixed in pydrive2 1.15.0-3
has caused the Debian Bug report #1029434,
regarding python3-pydrive2: ships md5sums without files: 
/usr/lib/python3/dist-packages/pydrive2/test/*
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1029434: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029434
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: python3-pydrive2
Version: 1.15.0-2
Severity: serious

https://piuparts.debian.org/sid/fail/python3-pydrive2_1.15.0-2.log

...
0m28.4s ERROR: FAIL: debsums reports modifications inside the chroot:
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/__init__.py (from python3-pydrive2 
package)
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/test_apiattr.py (from 
python3-pydrive2 package)
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/test_drive.py (from 
python3-pydrive2 package)
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/test_file.py (from 
python3-pydrive2 package)
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/test_filelist.py (from 
python3-pydrive2 package)
  debsums: missing file /usr/lib/python3/dist-packages/pydrive2/test/test_fs.py 
(from python3-pydrive2 package)
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/test_oauth.py (from 
python3-pydrive2 package)
  debsums: missing file 
/usr/lib/python3/dist-packages/pydrive2/test/test_util.py (from 
python3-pydrive2 package)
...
--- End Message ---
--- Begin Message ---
Source: pydrive2
Source-Version: 1.15.0-3
Done: Sebastien Bacher 

We believe that the bug you reported is fixed in the latest version of
pydrive2, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1029...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sebastien Bacher  (supplier of updated pydrive2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 27 Jun 2023 16:12:16 +0200
Source: pydrive2
Built-For-Profiles: noudeb
Architecture: source
Version: 1.15.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team 
Changed-By: Sebastien Bacher 
Closes: 1029434
Changes:
 pydrive2 (1.15.0-3) unstable; urgency=medium
 .
   * debian/rules:
 - exclude tests files from the binary package in a way that isn't
   confusing for the md5sum controls (Closes: #1029434)
Checksums-Sha1:
 9dbfffa6289e62c81b6adf4f78d1afde8fe59f2a 2057 pydrive2_1.15.0-3.dsc
 453fd769e1a18bba2ca2cb7103b0becd0455bf34 2128 pydrive2_1.15.0-3.debian.tar.xz
 ba09e834b7bdc9f8751b0964bcbb7e1dd9db79ae 9260 
pydrive2_1.15.0-3_source.buildinfo
Checksums-Sha256:
 50d9ff7088a4d938d6c0b026c624be66918f1f99415bdf5934692a6edb1b17bb 2057 
pydrive2_1.15.0-3.dsc
 2815ffcd77742fb714dbd5755fcb57c02d4b4117e7c2305d38802bb21d52b92e 2128 
pydrive2_1.15.0-3.debian.tar.xz
 df5aae7c68e00865685ece4e3de0c4b6bb8f21af6a37268abd09da267805957e 9260 
pydrive2_1.15.0-3_source.buildinfo
Files:
 bbc71c66deb49b10ce8b930daec2dba4 2057 python optional pydrive2_1.15.0-3.dsc
 16f45120022d93b9edca7cc4e332dc6f 2128 python optional 
pydrive2_1.15.0-3.debian.tar.xz
 300d9384166f40541c71f93bc33d237d 9260 python optional 
pydrive2_1.15.0-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEERyS4b0fgKRXe6kniPr1EkD7bBJYFAmSa7nkACgkQPr1EkD7b
BJZmig//bPjDIQUk3MKysUp5XnoHDFk7IIOrySge83EqZ5Aqg/y+DspXMlfOYiax
LH7IymZZ2qvVXHuI1HP/P5KDfrxnl6grIRSaoypJN9bYleQJGBflJcvMDe1FbvZA
a4GnNbkBSewgFpekS+HzIcWQK9wbqZQj5D2ElqT2J8upG8Go62xjGLm57CwYJo60
X4IErynwyCaywfX1VvN3qySvstvUeC2SZwzOtHLxIzRXTjQRRN7mfY2W0TVVfCDZ
nlKEbys77WRmZ2dTKxH7uaSIOTS7FbKzjcl4fISkDGzeK65zUK1ucRZPCdYHhK36
qs6ciuNpBesKR2tumgjSAKbxXo2KvnJ22hOuFsrUPrWKmiuY9nvFnsnLP8OJhgkT
yk6yiHT8gLxV/Bp6FmmaWVwUQb9Dpt7ubyo7Ji0CWjYZ+dJiYAsTlxJqQSRHPsjk
GqAz+v8voSbpwfbcfaDInhTgV9hW1ot0oQxKPlV9GOkDl4l2q7RKnwoYwSxj6HYi
hZxe8hTsT/Y2ms1gBKsHzH8RyL9Kqns3em59Pofj9Kkk06zSvvI2sO+smZlMtW/L
VPxVBhC/L+0orfP2xWe8kMv2XR/GcDn5Eb6V1wNstFCJCn054dU40ag3mxwB78mj
un4K/3uQe5TvRvfwWBNSnMF+PuZR8NwxJzIxfKKB6abbQZRM+eY=
=nLLc
-END PGP

Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt

Package: logcheck
Version: 1.4.2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

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

  Setting up logcheck (1.4.2) ...
  
  Configuration file '/etc/logcheck/header.txt'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** header.txt (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
logcheck (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for debianutils (5.7-0.5~deb12anbe1) ...
  Processing triggers for libc-bin (2.36-9) ...
  Errors were encountered while processing:
   logcheck


This happens up upgrade paths starting in jessie, upgrading release by
release to bookworm.


cheers,

Andreas


logcheck_1.4.2.log.gz
Description: application/gzip

Bug#1029434: marked as pending in pydrive2

2023-06-27 Thread Sebastien Bacher

Control: tag -1 pending

Hello,

Bug #1029434 in pydrive2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/pydrive2/-/commit/315d85f9b2a5c8dffa3843841b89ed9765373625


* debian/rules:
  - exclude tests files from the binary package in a way that isn't
confusing for the md5sum controls (Closes: #1029434)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1029434

Processed: Bug#1029434 marked as pending in pydrive2

Processing control commands:

> tag -1 pending
Bug #1029434 [python3-pydrive2] python3-pydrive2: ships md5sums without files: 
/usr/lib/python3/dist-packages/pydrive2/test/*
Added tag(s) pending.

-- 
1029434: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029434
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 1039531, tagging 1038746, tagging 1039480, tagging 1038890, tagging 1039529 ...

Processing commands for cont...@bugs.debian.org:

> tags 1039531 + sid trixie
Bug #1039531 [src:autoconf2.64] autoconf2.64: Keep out of testing
Added tag(s) trixie and sid.
> tags 1038746 + sid trixie
Bug #1038746 [src:python-cryptography] build dependency missing in testing
Added tag(s) trixie and sid.
> tags 1039480 + sid trixie
Bug #1039480 [src:astroplan] [astroplan] Please update to 0.8 for astropy 5.3 
compatibility
Added tag(s) trixie and sid.
> tags 1038890 + trixie
Bug #1038890 [src:pyparted] pyparted: Testsuite fails against parted 3.6
Added tag(s) trixie.
> tags 1039529 - bookworm + trixie
Bug #1039529 [src:sight] sight: FTBFS: 
/<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ 
has not been declared
Removed tag(s) bookworm.
Bug #1039529 [src:sight] sight: FTBFS: 
/<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ 
has not been declared
Added tag(s) trixie.
> notfixed 395295 nbd-client/1:3.19-3
Bug #395295 {Done: Wouter Verhelst } [nbd-client] 
nbd-client: awkward device creation, probably not udev-compliant
The source nbd-client and version 1:3.19-3 do not appear to match any binary 
packages
No longer marked as fixed in versions nbd-client/1:3.19-3.
> fixed 395295 1:3.19-3
Bug #395295 {Done: Wouter Verhelst } [nbd-client] 
nbd-client: awkward device creation, probably not udev-compliant
Marked as fixed in versions nbd/1:3.19-3.
> notfixed 941953 1:3.24-1.1
Bug #941953 {Done: Wouter Verhelst } [nbd-client] nbd-client 
package name is 3.19 but reports and behaves like 3.18
No longer marked as fixed in versions src:nbd/1:3.24-1.1.
> fixed 941953 1:3.24-1.1
Bug #941953 {Done: Wouter Verhelst } [nbd-client] nbd-client 
package name is 3.19 but reports and behaves like 3.18
Marked as fixed in versions nbd/1:3.24-1.1.
> notfixed 586183 nbd-client/1:3.25-1
Bug #586183 {Done: Wouter Verhelst } [nbd-client] 
ndb-server(1) has no details about SDP
The source nbd-client and version 1:3.25-1 do not appear to match any binary 
packages
No longer marked as fixed in versions nbd-client/1:3.25-1.
> fixed 586183 1:3.25-1
Bug #586183 {Done: Wouter Verhelst } [nbd-client] 
ndb-server(1) has no details about SDP
Marked as fixed in versions nbd/1:3.25-1.
> fixed 1034998 6.0.5-1
Bug #1034998 {Done: Andreas Metzler } 
[pcp-export-pcp2elasticsearch] pcp-export-pcp2elasticsearch: missing 
Breaks+Replaces for pcp when upgrading from bullseye
Marked as fixed in versions pcp/6.0.5-1.
> fixed 1034983 6.0.5-1
Bug #1034983 {Done: Andreas Metzler } 
[pcp-export-pcp2json] pcp-export-pcp2json: missing Breaks+Replaces for pcp when 
upgrading from bullseye
Marked as fixed in versions pcp/6.0.5-1.
> fixed 1034973 6.0.5-1
Bug #1034973 {Done: Andreas Metzler } 
[pcp-export-pcp2zabbix] pcp-export-pcp2zabbix: missing Breaks+Replaces for pcp 
when upgrading from bullseye
Marked as fixed in versions pcp/6.0.5-1.
> fixed 1034932 6.0.5-1
Bug #1034932 {Done: Andreas Metzler } 
[pcp-export-pcp2spark] pcp-export-pcp2spark: missing Breaks+Replaces for pcp 
when upgrading from bullseye
Marked as fixed in versions pcp/6.0.5-1.
> fixed 1034922 6.0.5-1
Bug #1034922 {Done: Andreas Metzler } [pcp-export-pcp2xml] 
pcp-export-pcp2xml: missing Breaks+Replaces for pcp when upgrading from bullseye
Marked as fixed in versions pcp/6.0.5-1.
> fixed 1034895 6.0.5-1
Bug #1034895 {Done: Andreas Metzler } [pcp-zeroconf] 
pcp-zeroconf: missing Replaces: pcp (<< ?)
Marked as fixed in versions pcp/6.0.5-1.
> reassign 1027043 x11vnc 0.9.16-8
Bug #1027043 {Done: Mike Gabriel } [libvncserver1] 
libvncserver1: 0.9.13+dfsg-2+deb11u1 make x11vnc slow.  0.9.13+dfsg-2 works 
fine.
Bug reassigned from package 'libvncserver1' to 'x11vnc'.
No longer marked as found in versions libvncserver/0.9.13+dfsg-2.
No longer marked as fixed in versions x11vnc/0.9.16-9.
Bug #1027043 {Done: Mike Gabriel } [x11vnc] 
libvncserver1: 0.9.13+dfsg-2+deb11u1 make x11vnc slow.  0.9.13+dfsg-2 works 
fine.
Marked as found in versions x11vnc/0.9.16-8.
> fixed 1027043 0.9.16-9
Bug #1027043 {Done: Mike Gabriel } [x11vnc] 
libvncserver1: 0.9.13+dfsg-2+deb11u1 make x11vnc slow.  0.9.13+dfsg-2 works 
fine.
Marked as fixed in versions x11vnc/0.9.16-9.
> fixed 418431 2.1a+cvs1.2458+20070509-1
Bug #418431 {Done: Guillem Jover } [libtool] libtool: 
provided m4 files produce autoconf warnings
Marked as fixed in versions libtool/2.1a+cvs1.2458+20070509-1.
> reassign 1033286 src:flatpak-kcm 5.27.2-1
Bug #1033286 {Done: Patrick Franz } [systemsettings] 
systemsettings crashes when trying to access the Flatpak permission module
Bug reassigned from package 'systemsettings' to 'src:flatpak-kcm'.
No longer marked as found in versions systemsettings/4:5.27.2-1.
No longer marked as fixed in versions flatpak-kcm/5.27.2-3.
Bug #1033286 {Done: Patrick Franz } [src:flatpak-kcm] 
systemsettings crashes when trying to access the Flatpak permission module
Marked as found in versions flatpak-kcm/5.27.2-1.
> fixed 1033286 5.27.2-1
Bug #1033286 {Done: Patrick Franz } [src:flatpak-kcm]

Processed: retitle attempt three, hope for no automatic line breaking

Processing commands for cont...@bugs.debian.org:

> retitle 1038197 "enigma: Depends on SDL 1.2; unmaintained (1.30 is SDL2)"
Bug #1038197 [src:enigma] enigma: Depends on SDL 1.2 and is unmaintained 
(upstream
Changed Bug title to '"enigma: Depends on SDL 1.2; unmaintained (1.30 is 
SDL2)"' from 'enigma: Depends on SDL 1.2 and is unmaintained (upstream'.
> retitle 1039438 "enigma: Contains an outdated lua copy and is unmaintained"
Bug #1039438 [src:enigma] enigma: Contains/uses an outdated lua copy and is
Changed Bug title to '"enigma: Contains an outdated lua copy and is 
unmaintained"' from 'enigma: Contains/uses an outdated lua copy and is'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1038197: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038197
1039438: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039438
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 2 errors): retitle to indicate that the package is not maintained

Processing commands for cont...@bugs.debian.org:

> retitle 1038197 enigma: Depends on SDL 1.2 and is unmaintained (upstream
Bug #1038197 [src:enigma] enigma: Depends on SDL 1.2
Changed Bug title to 'enigma: Depends on SDL 1.2 and is unmaintained (upstream' 
from 'enigma: Depends on SDL 1.2'.
> 1.30 uses SDL 2)
Unknown command or malformed arguments to command.
> retitle 1039438 enigma: Contains/uses an outdated lua copy and is
Bug #1039438 [src:enigma] enigma: Embded and use lua copy (outdated)
Changed Bug title to 'enigma: Contains/uses an outdated lua copy and is' from 
'enigma: Embded and use lua copy (outdated)'.
> unmaintained
Unknown command or malformed arguments to command.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1038197: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038197
1039438: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039438
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1039572: sl-modem-dkms: module fails to build for Linux 6.4

Package: sl-modem-dkms
Version: 2.9.11~20110321-17
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts


1.) There is an autopkgtest regression with the -cloud kernel,
preventing migration to testing (therefore severity serious):

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sl-modem/34615715/log.gz

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.1.0-9-cloud-amd64 
(x86_64)
Mon Jun 19 06:58:35 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o 
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.1.0-9-cloud-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.o
  LD [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.o
  MODPOST /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers
ERROR: modpost: "usb_alloc_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_free_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_register_driver" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_clear_halt" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_submit_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_control_msg" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_set_interface" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_deregister" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
ERROR: modpost: "usb_unlink_urb" 
[/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/slusb.ko] undefined!
make[2]: *** 
[/usr/src/linux-headers-6.1.0-9-common/scripts/Makefile.modpost:126: 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/Module.symvers] Error 1
make[1]: *** [/usr/src/linux-headers-6.1.0-9-common/Makefile:1989: modpost] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
make: *** [Makefile:138: all] Error 2
make: Leaving directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
make: Entering directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'
make modules -C /lib/modules/6.1.0-9-cloud-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem
make[1]: Entering directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.o
  MODPOST 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/Module.symvers
  CC [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.mod.o
  LD [M]  
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
  BTF [M] 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko
Skipping BTF generation for 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem/ungrab-winmodem.ko 
due to unavailability of vmlinux
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-9-cloud-amd64'
make: Leaving directory 
'/var/lib/dkms/sl-modem/2.9.11~20110321/build/ungrab-winmodem'

You probably need to add this line to your dkms.conf:

BUILD_EXCLUSIVE_CONFIG="CONFIG_USB"

in order to skip building the module for kernels without CONFIG_USB.



2.) the module fails to build for Linux 6.4

DKMS make.log for sl-modem-2.9.11~20110321 for kernel 6.4.0-0-amd64 (x86_64)
Tue Jun 27 10:00:31 UTC 2023
make: Entering directory '/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers'
obj-m= slusb.o
slamr-objs=amrmo_init.o sysdep_amr.o amrlibs.o
make modules -C /lib/modules/6.4.0-0-amd64/build 
M=/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers
make[1]: Entering directory '/usr/src/linux-headers-6.4.0-0-amd64'
  CC [M]  /var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.o
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.c:243:33: error: 
macro "DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given
  243 | static DEFINE_SEMAPHORE(open_sem);
  | ^
In file included from 
/usr/src/linux-headers-6.4.0-0-common/include/linux/fs.h:25,
 from 
/usr/src/linux-headers-6.4.0-0-common/include/linux/poll.h:10,
 from 
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.c:55:
/usr/src/linux-headers-6.4.0-0-common/include/linux/semaphore.h:34: note: macro 
"DEFINE_SEMAPHORE" defined here
   34 | #define DEFINE_SEMAPHORE(_name, _n) \
  |
/var/lib/dkms/sl-modem/2.9.11~20110321/build/drivers/st7554.c:243:8:

Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

2023-06-27 Thread Philipp Marek

Package: firefox
Version: 114.0-1
Severity: grave
X-Debbugs-Cc: phil...@marek.priv.at

Websites that need randomness ([1]) are broken,
on both Debian FF 113.0.2 and 114.0 (114.0.2 not yet available for amd64).

Reproduced with a new profile without any plugins.

strace shows FF being able to use getrandom(),
so it seems to be a userspace problem.


114.0.2 from upstream works as expected;
Mozilla chat recommended asking the packaging team.


Ad 1:
- banking.bank99.at uses crypto.getRandomValues() even before login
- RedHat support webpage uses getRandomUUID after login
Both fail with "OperationError: The operation failed for an 
operation-specific reason"


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.9-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.36-9
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.8-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s113.1.0-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.90-3
ii  libpango-1.0-0   1.50.14+ds-1
ii  libstdc++6   13.1.0-6
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.3-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec59  7:5.1.3-1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-2
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

-- debsums errors found:
debsums: can't check firefox file /usr/share/doc/firefox/NEWS.Debian.gz (Wide 
character in subroutine entry)
debsums: can't check firefox file /usr/share/doc/firefox/changelog.Debian.gz 
(Wide character in subroutine entry)
debsums: can't check firefox file 
/usr/share/firefox/browser/chrome/icons/default/default128.png (Wide character 
in subroutine entry)
debsums: can't check firefox file 
/usr/share/firefox/browser/chrome/icons/default/default16.png (Wide character 
in subroutine entry)
debsums: can't check firefox file 
/usr/share/firefox/browser/chrome/icons/default/default32.png (Wide character 
in subroutine entry)
debsums: can't check firefox file 
/usr/share/firefox/browser/chrome/icons/default/default48.png (Wide character 
in subroutine entry)
debsums: can't check firefox file 
/usr/share/firefox/browser/chrome/icons/default/default64.png (Wide character 
in subroutine entry)
debsums: can't check firefox file /usr/share/man/man1/firefox.1.gz (Wide 
character in subroutine entry)

Processed: your mail

Processing commands for cont...@bugs.debian.org:

> block 1038197 with 902855
Bug #1038197 [src:enigma] enigma: Depends on SDL 1.2
1038197 was not blocked by any bugs.
1038197 was blocking: 1038036 1038037 1038070
Added blocking bug(s) of 1038197: 902855
> block 1039438 with 902855
Bug #1039438 [src:enigma] enigma: Embded and use lua copy (outdated)
1039438 was not blocked by any bugs.
1039438 was not blocking any bugs.
Added blocking bug(s) of 1039438: 902855
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1038197: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038197
1039438: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039438
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

2023-06-27 Thread Georg Faerber

Hi,

On 23-06-26 10:27:37, Antoine Beaupré wrote:
> Just to make sure, someone still is working on this to make sure it's
> fixed in bookworm?

I'll take care of it.

> I guess the first step is to wait for the package to transition to
> trixie and then do the -pu? I suspect it will be hard to test this in
> trixie since you'd need to upgrade from buster to trixie, right?

Right, it needs some more days. CI reported regressions, which I believe
are unrelated to the issue and hand the fix. As of now it should migrate
within five days.

Regarding the test: I'll seek comments of the Ruby team before filling
the -pu; I believe the risk of regressions should be fairly low, as
arel, as described, has been part of activerecord since quite some time.
I'll test this especially in combination with schleuder, which exposed
this issue; to ease future maintenance and increase the chances of
spotting these issues earlier, ideally before release, I added a
"piuparts multi distro upgrade" test job to the Salsa CI [1].

I'll keep this bug updated.

Cheers,
Georg

[1] 
https://salsa.debian.org/ruby-team/schleuder/-/commit/08fd9a91a938346f5cad3cf216f8225b6f6cdd0e

Bug#1039561: seqan3's autopkg tests fail to build

2023-06-27 Thread Matthias Klose


Package: src:seqan3
Version: 3.2.0+ds-6
Severity: serious
Tags: sid trixie

seqan3's autopkg tests fail to build, letting the tests to not succeed:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/seqan3/34898359/log.gz

Bug#1039460: marked as done (libjxl-gdk-pixbuf: fails to purge: gdk-pixbuf-query-loaders: not found)

Your message dated Tue, 27 Jun 2023 07:34:21 +
with message-id 
and subject line Bug#1039460: fixed in jpeg-xl 0.9.0~git20230623.689da0f-3
has caused the Debian Bug report #1039460,
regarding libjxl-gdk-pixbuf: fails to purge: gdk-pixbuf-query-loaders: not found
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1039460: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039460
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libjxl-gdk-pixbuf
Version: 0.9.0~git20230612.38b629f-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge due
to a command not found. According to policy 7.2 you cannot rely on the
depends being available during purge, only the essential packages are
available for sure.

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

  Purging configuration files for libjxl-gdk-pixbuf:amd64 
(0.9.0~git20230612.38b629f-3) ...
  /var/lib/dpkg/info/libjxl-gdk-pixbuf:amd64.postrm: 2: 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: not found
  dpkg: error processing package libjxl-gdk-pixbuf:amd64 (--purge):
   installed libjxl-gdk-pixbuf:amd64 package post-removal script subprocess 
returned error exit status 127


cheers,

Andreas


libjxl-gdk-pixbuf_0.9.0~git20230612.38b629f-3.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: jpeg-xl
Source-Version: 0.9.0~git20230623.689da0f-3
Done: Mathieu Malaterre 

We believe that the bug you reported is fixed in the latest version of
jpeg-xl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1039...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mathieu Malaterre  (supplier of updated jpeg-xl package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 27 Jun 2023 09:07:22 +0200
Source: jpeg-xl
Architecture: source
Version: 0.9.0~git20230623.689da0f-3
Distribution: experimental
Urgency: medium
Maintainer: Debian PhotoTools Maintainers 

Changed-By: Mathieu Malaterre 
Closes: 1039460
Changes:
 jpeg-xl (0.9.0~git20230623.689da0f-3) experimental; urgency=medium
 .
   [ Julian Wollrath ]
   * d/postrm: Fix gdk-pixbuf-query-loaders: not found. Closes: #1039460
 .
   [ Mathieu Malaterre ]
   * d/rules: Increase timeout to 5h
Checksums-Sha1:
 478dd19e010fae4bcd7e1de7ea3f73b3725c4bab 3504 
jpeg-xl_0.9.0~git20230623.689da0f-3.dsc
 2647308f9bec9a3aee55a5c8999ac3cf97f5c0f7 13680 
jpeg-xl_0.9.0~git20230623.689da0f-3.debian.tar.xz
 93e3bed3ab27be72fa1adf5e59c4544bdc72350d 12287 
jpeg-xl_0.9.0~git20230623.689da0f-3_source.buildinfo
Checksums-Sha256:
 232ff7ad682a7ae432aec7cf9e10c1ec8dd10319f23343b9a3575b2eda48b662 3504 
jpeg-xl_0.9.0~git20230623.689da0f-3.dsc
 8eb5cbef4d45d309db803dce34f9b51c48878cb7ce70b94ae4c67dc14bb5a2e9 13680 
jpeg-xl_0.9.0~git20230623.689da0f-3.debian.tar.xz
 2b3e144f2f5763d6cde12d0463c4d47c47b598e136b4143dbc5812faaa2ded73 12287 
jpeg-xl_0.9.0~git20230623.689da0f-3_source.buildinfo
Files:
 e22840271ff2b6a3724ef1542136ab34 3504 graphics optional 
jpeg-xl_0.9.0~git20230623.689da0f-3.dsc
 fc71a67b20d2c68339ded45927713dc4 13680 graphics optional 
jpeg-xl_0.9.0~git20230623.689da0f-3.debian.tar.xz
 9f6525b2df33212e45ad5746671b2f46 12287 graphics optional 
jpeg-xl_0.9.0~git20230623.689da0f-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEaTNn/67NjqrNHwY7AXHhgorgk0UFAmSaiucRHG1hbGF0QGRl
Ymlhbi5vcmcACgkQAXHhgorgk0Xhew//dm6cnbyRO4vzzBRM0eo5yMZRxJTmkwYC
tbkvdlSfs3YMMHFozJMLajd417sdhiJAjECE/6KjXPvkACSN2ihcDHihfxWdyI2k
I20h61cGkVPR+TcM/ouPkdoesDF8FG3D/C2OyGB4C7JZZ+RZ5TGSqeRcGdo8HBg3
yF6wBDWkPFa/6/OK/fBFjGe8caewPNkSpy84O6RWSdHafohbYx4hws37Kb0NFDEN
IquMKeEzgV6ma9n2X9zb7owPG/YEKot69QkR/RdspMCd0HT2gVbHLUkcJDZBLhv4
SI+G2TLMe2YlhsnBwj2MTS6ROnxoJZs7GvNcnsVyloY/L63WVz7CeIZb9gm4CwXy
sgJkbScVXcjQhwR7HPSZLatjhPf1Z6lg0Ow89RlvNH2vqYSaGhyO+/goAupU6BDK
H4hnO2HlkXc0+3VoKISx5kL4Dt2X+UZ6zvW5AAr4ykPx1pr6vU/EKJBolGx9xk2r
e05CrNW9sGjGgITcQBK6t6MaSfhpYCAZ7QJBJsme9qvRoHW74BbrCwK2wPJ//lK6
cz5rEmAN5Od4Xbhj1VjxhrOQVzOV2Bs9yEYy3JEoG1elVsGIzezsCmzK62iczJ5y

Bug#1039087: epic-base: embed yajl

2023-06-27 Thread Andrius Merkys


Hi,

On Sun, 25 Jun 2023 15:02:18 + =?utf-8?q?Bastien_Roucari=C3=A8s?= 
 wrote:

Your package embed a copy of yajl.


I agree with un-embedding.


Could you:
- compile against the packaged yajl package


I spent some time trying, but did not find an unintrusive way to do so. 
Adding OP_SYS_INCLUDES passes the compilation:


override_dh_auto_build:
make LINKER_USE_RPATH=NO OP_SYS_INCLUDES=-I/usr/include/yajl

But I could not make the linker use the yajl library, arriving at the 
following failure:


/usr/bin/g++ -o yajl_test 
-L/home/merkys/epics-base-7.0.3.1/lib/linux-x86_64   -rdynamic 
-m64 yajl_test.o-lCom

/usr/bin/ld: yajl_test.o: in function `main':
yajl_test.c:(.text.startup+0x62): undefined reference to `yajl_alloc'
/usr/bin/ld: yajl_test.c:(.text.startup+0xde): undefined reference to 
`yajl_parse'
/usr/bin/ld: yajl_test.c:(.text.startup+0x119): undefined reference to 
`yajl_complete_parse'
/usr/bin/ld: yajl_test.c:(.text.startup+0x129): undefined reference to 
`yajl_free'
/usr/bin/ld: yajl_test.c:(.text.startup+0x212): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x26b): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x31b): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x343): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x374): undefined reference to 
`yajl_get_error'
/usr/bin/ld: yajl_test.c:(.text.startup+0x39d): undefined reference to 
`yajl_free_error'
/usr/bin/ld: yajl_test.c:(.text.startup+0x3fd): undefined reference to 
`yajl_free'

collect2: error: ld returned 1 exit status


- remove by repacking the embded code copy in order to avoid accidental
compilation of the embed code copy

This should be doable when the build succeeds.

Best,
Andrius

Bug#1034624: marked as done (zfs-dkms: Please revert corruption-causing optimization in 2.1.10 release)

Your message dated Tue, 27 Jun 2023 14:12:20 +0800
with message-id 

and subject line 
has caused the Debian Bug report #1034624,
regarding zfs-dkms: Please revert corruption-causing optimization in 2.1.10 
release
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1034624: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034624
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: zfs-dkms
Version: 2.1.9-1~bpo11+1
Severity: critical
Tags: upstream
Justification: causes serious data loss

Dear Maintainer,

For the 2.1.10 release please revert the commit referenced in 

It appears an optimization brought forth a bug that was apready fixed
once. https://github.com/openzfs/zfs/pull/13368 is the commit.

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dkms   2.8.4-3
ii  file   1:5.39-3
ii  libc6-dev [libc-dev]   2.31-13+deb11u5
ii  libpython3-stdlib  3.9.2-3
ii  lsb-release11.1.0
ii  perl   5.32.1-4+deb11u2
ii  python3-distutils  3.9.2-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.10.162-1
ii  zfs-zed 2.1.9-1~bpo11+1
ii  zfsutils-linux  2.1.9-1~bpo11+1

Versions of packages zfs-dkms suggests:
ii  debhelper  13.3.4

-- debconf-show failed
--- End Message ---
--- Begin Message ---
Closing this report since the mentioned issue did not appear in the
Debian archive.

Regards,
Aron--- End Message ---

Processed: your mail