Bug#1070367: linux-image-6.7.12-amd64: No WiFi

2024-05-04 Thread Kurt Meyer
Package: src:linux
X-Debbugs-Cc: yahweh19...@hailmail.net
Version: 6.7.12-1
Severity: important

Dear Maintainer,

* What led up to the situation?

Booting with the linux-image-6.7.12-amd64 kernel results in Wi-Fi not working 
and Wi-Fi isn't even an option under network-manager. This issue also 
manifested when I attempted to boot using the linux-image-6.6.15-amd64 kernel, 
so the issue may have started with that kernel.

* What exactly did you do (or not do) that was effective (or ineffective)?

Wi-Fi works when I boot using the linux-image-amd-6.6.13-1 kernel. My computer 
has a Broadcom BCM4352 802.11ac dual band wireless network adapter chip.

-- Package-specific info:
** Version:
Linux version 6.7.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.12-amd64 
root=UUID=2ce960a9-306e-407e-940e-88fb66c8e14e ro quiet

** Tainted: I (2048)
* workaround for bug in platform firmware applied

** Kernel log:
[   11.786668] Registered IR keymap rc-rc6-mce
[   11.808428] IR RC6 protocol handler initialized
[   11.838563] rc rc0: ENE eHome Infrared Remote Receiver as 
/devices/virtual/rc/rc0
[   11.838630] rc rc0: lirc_dev: driver ene_ir registered at minor = 0, raw IR 
receiver, no transmitter
[   11.838692] input: ENE eHome Infrared Remote Receiver as 
/devices/virtual/rc/rc0/input14
[   11.838828] rc rc0: nonsensical timing event of duration 0
[   11.838831] rc rc0: two consecutive events of type space
[   11.838840] ene_ir: driver has been successfully loaded
[   12.161547] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   12.202826] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input16
[   12.202904] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input17
[   12.202972] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input18
[   12.207177] intel_rapl_common: Found RAPL domain package
[   12.207181] intel_rapl_common: Found RAPL domain core
[   12.207182] intel_rapl_common: Found RAPL domain uncore
[   12.207183] intel_rapl_common: Found RAPL domain dram
[   12.239648] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC887-VD: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   12.239654] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.239656] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   12.239658] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   12.239660] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   12.239661] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
[   12.239662] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   12.247641] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input19
[   12.247785] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input20
[   12.556062] input: Advanced Silicon S.A CoolTouch(TM) System as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.1/3-1.7.1:1.0/0003:2149:230C.0001/input/input21
[   12.651379] mc: Linux media interface: v0.10
[   12.697557] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   12.722908] hid-multitouch 0003:2149:230C.0001: input,hidraw0: USB HID v1.10 
Device [Advanced Silicon S.A CoolTouch(TM) System] on 
usb-:00:1d.0-1.7.1/input0
[   12.723282] logitech-djreceiver 0003:046D:C52B.0005: hiddev2,hidraw2: USB 
HID v1.11 Device [Logitech USB Receiver] on usb-:00:1d.0-1.7.4/input2
[   12.851837] input: Logitech Wireless Device PID:4101 Keyboard as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input22
[   12.862814] input: Logitech Wireless Device PID:4101 Mouse as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input23
[   12.863043] hid-generic 0003:046D:4101.0008: input,hidraw3: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4101] on usb-:00:1d.0-1.7.4/input2:1
[   12.863622] input: Logitech Wireless Device PID:4011 Keyboard as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input27
[   12.864099] input: Logitech Wireless Device PID:4011 Mouse as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input28
[   12.865582] hid-generic 0003:046D:4011.0009: input,hidraw4: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4011] on usb-:00:1d.0-1.7.4/input2:2
[   13.045112] videodev: Linux video capture interface: v2.00
[   13.211441] usb 3-1.7.2: Found UVC 1.00 device Laptop_Integrated_Webcam_FHD 
(1bcf:2c33)
[   13.251154] usbcore: registered new interface driver uvcvideo
[  

Bug#1070353: linux-image-6.7.12-amd64: No WiFi

2024-05-04 Thread Kurt Meyer
Package: src:linux
X-Debbugs-Cc: yahweh19...@hailmail.net
Version: 6.7.12-1
Severity: important

Dear Maintainer,

* What led up to the situation?

Booting with the linux-image-6.7.12-amd64 kernel results in Wi-Fi not working 
and Wi-Fi isn't even an option under network-manager. This issue also 
manifested when I attempted to boot using the linux-image-6.6.15-amd64 kernel, 
so the issue may have started with that kernel.

* What exactly did you do (or not do) that was effective (or ineffective)?

Wi-Fi works when I boot using the linux-image-amd-6.6.13-1 kernel. My computer 
has a Broadcom BCM4352 802.11ac dual band wireless network adapter chip.

-- Package-specific info:
** Version:
Linux version 6.7.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.12-amd64 
root=UUID=2ce960a9-306e-407e-940e-88fb66c8e14e ro quiet

** Tainted: I (2048)
* workaround for bug in platform firmware applied

** Kernel log:
[   11.786668] Registered IR keymap rc-rc6-mce
[   11.808428] IR RC6 protocol handler initialized
[   11.838563] rc rc0: ENE eHome Infrared Remote Receiver as 
/devices/virtual/rc/rc0
[   11.838630] rc rc0: lirc_dev: driver ene_ir registered at minor = 0, raw IR 
receiver, no transmitter
[   11.838692] input: ENE eHome Infrared Remote Receiver as 
/devices/virtual/rc/rc0/input14
[   11.838828] rc rc0: nonsensical timing event of duration 0
[   11.838831] rc rc0: two consecutive events of type space
[   11.838840] ene_ir: driver has been successfully loaded
[   12.161547] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   12.202826] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input16
[   12.202904] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input17
[   12.202972] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input18
[   12.207177] intel_rapl_common: Found RAPL domain package
[   12.207181] intel_rapl_common: Found RAPL domain core
[   12.207182] intel_rapl_common: Found RAPL domain uncore
[   12.207183] intel_rapl_common: Found RAPL domain dram
[   12.239648] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC887-VD: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   12.239654] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.239656] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   12.239658] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   12.239660] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   12.239661] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
[   12.239662] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   12.247641] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input19
[   12.247785] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input20
[   12.556062] input: Advanced Silicon S.A CoolTouch(TM) System as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.1/3-1.7.1:1.0/0003:2149:230C.0001/input/input21
[   12.651379] mc: Linux media interface: v0.10
[   12.697557] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   12.722908] hid-multitouch 0003:2149:230C.0001: input,hidraw0: USB HID v1.10 
Device [Advanced Silicon S.A CoolTouch(TM) System] on 
usb-:00:1d.0-1.7.1/input0
[   12.723282] logitech-djreceiver 0003:046D:C52B.0005: hiddev2,hidraw2: USB 
HID v1.11 Device [Logitech USB Receiver] on usb-:00:1d.0-1.7.4/input2
[   12.851837] input: Logitech Wireless Device PID:4101 Keyboard as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input22
[   12.862814] input: Logitech Wireless Device PID:4101 Mouse as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input23
[   12.863043] hid-generic 0003:046D:4101.0008: input,hidraw3: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4101] on usb-:00:1d.0-1.7.4/input2:1
[   12.863622] input: Logitech Wireless Device PID:4011 Keyboard as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input27
[   12.864099] input: Logitech Wireless Device PID:4011 Mouse as 
/devices/pci:00/:00:1d.0/usb3/3-1/3-1.7/3-1.7.4/3-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input28
[   12.865582] hid-generic 0003:046D:4011.0009: input,hidraw4: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4011] on usb-:00:1d.0-1.7.4/input2:2
[   13.045112] videodev: Linux video capture interface: v2.00
[   13.211441] usb 3-1.7.2: Found UVC 1.00 device Laptop_Integrated_Webcam_FHD 
(1bcf:2c33)
[   13.251154] usbcore: registered new interface driver uvcvideo
[  

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

2024-04-08 Thread Kurt Roeckx
There might be a related change that doesn't allow restarting the operation 
with the same context without setting things up again.

Bug#1067584: linux-image-6.7.9-amd64: Wi-Fi Doesn't Work

2024-03-23 Thread Kurt Meyer
Package: src:linux
Version: 6.7.9-1
Severity: important

Dear Maintainer,

* What led up to the situation?

Booting with the linux-image-6.7.9-amd64 kernel results in Wi-Fi not working 
and Wi-Fi isn't even an option under network-manager. This issue also 
manifested when I attempted to boot using the linux-image-6.6.15-amd64 kernel, 
so the issue may have started with that kernel.

* What exactly did you do (or not do) that was effective (or ineffective)?

Wi-Fi works when I boot using the linux-image-amd-6.6.13-1 kernel. My computer 
has a Broadcom BCM4352 802.11ac dual band wireless network adapter chip.

* What was the outcome of this action?
* What outcome did you expect instead?

-- Package-specific info:
** Version:
Linux version 6.7.9-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-18) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.9-1 (2024-03-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.9-amd64 
root=UUID=2ce960a9-306e-407e-940e-88fb66c8e14e ro quiet

** Tainted: I (2048)
* workaround for bug in platform firmware applied

** Kernel log:
[   11.460516] asus_wmi: SFUN value: 0x0
[   11.460519] eeepc-wmi eeepc-wmi: Detected ASUSWMI, use DCTS
[   11.461898] input: Eee PC WMI hotkeys as 
/devices/platform/eeepc-wmi/input/input15
[   11.724302] input: Advanced Silicon S.A CoolTouch(TM) System as 
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.7/1-1.7.1/1-1.7.1:1.0/0003:2149:230C.0001/input/input16
[   11.724446] hid-multitouch 0003:2149:230C.0001: input,hidraw0: USB HID v1.10 
Device [Advanced Silicon S.A CoolTouch(TM) System] on 
usb-:00:1d.0-1.7.1/input0
[   11.836405] mc: Linux media interface: v0.10
[   11.838153] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   11.960653] videodev: Linux video capture interface: v2.00
[   12.067658] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   12.100090] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input17
[   12.118620] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input18
[   12.129218] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC887-VD: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   12.129224] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.129226] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   12.129228] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   12.129229] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   12.129230] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x18
[   12.129232] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   12.138884] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input20
[   12.182640] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input19
[   12.182746] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input21
[   12.233693] logitech-djreceiver 0003:046D:C52B.0005: hiddev1,hidraw2: USB 
HID v1.11 Device [Logitech USB Receiver] on usb-:00:1d.0-1.7.4/input2
[   12.290257] Bluetooth: Core ver 2.22
[   12.290278] NET: Registered PF_BLUETOOTH protocol family
[   12.290280] Bluetooth: HCI device and connection manager initialized
[   12.290283] Bluetooth: HCI socket layer initialized
[   12.290285] Bluetooth: L2CAP socket layer initialized
[   12.290288] Bluetooth: SCO socket layer initialized
[   12.369238] input: Logitech Wireless Device PID:4101 Keyboard as 
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.7/1-1.7.4/1-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input22
[   12.370861] input: Logitech Wireless Device PID:4101 Mouse as 
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.7/1-1.7.4/1-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4101.0008/input/input23
[   12.373479] hid-generic 0003:046D:4101.0008: input,hidraw3: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4101] on usb-:00:1d.0-1.7.4/input2:1
[   12.374024] input: Logitech Wireless Device PID:4011 Keyboard as 
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.7/1-1.7.4/1-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input27
[   12.374160] input: Logitech Wireless Device PID:4011 Mouse as 
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.7/1-1.7.4/1-1.7.4:1.2/0003:046D:C52B.0005/0003:046D:4011.0009/input/input28
[   12.374239] hid-generic 0003:046D:4011.0009: input,hidraw4: USB HID v1.11 
Keyboard [Logitech Wireless Device PID:4011] on usb-:00:1d.0-1.7.4/input2:2
[   12.385507] usb 1-1.7.2: Found UVC 1.00 device Laptop_Integrated_Webcam_FHD 
(1bcf:2c33)
[   12.426158] usbcore: registered new interface driver uvcvideo
[   12.486704] usbcore: registered new interface driver btusb
[   12.596389] Bluetooth: hci0: BCM: chip id 63
[   12.597380] Bluetooth: hci0: BCM: features 0x07
[   12.613384] Bluetooth: hci0: BCM20702A
[   12.613394] Bluetooth: 

Bug#1067087: GCC frame pointers

2024-03-18 Thread Kurt Roeckx
Source: gcc-14
Severity: wishlist

Please consider enabling frame pointers on 64 bit arches. See: 
https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html

Kurt

Bug#1063992: gitlab-cli: manual page for python-gitlab has no descriptive content due to an error

2024-03-17 Thread Kurt Kremitzki

Control: tags -1 patch

On Thu, 15 Feb 2024 11:21:51 + James Addison  wrote:

Package: gitlab-cli
Version: 1:4.3.0-1
Severity: important
X-Debbugs-Cc: j...@jp-hosting.net



I have opened a MR with a fix by setting PYTHONPATH during manpage 
generation:


https://salsa.debian.org/debian/python-pygitlab/-/merge_requests/3/



I cannot replicate this locally; when I build the package using
dpkg-buildpackage on my machine, a complete manual page is generated - so the
problem could be a buildsystem issue.

Regards,
James


If you already have python3-gitlab installed on the local system, it is 
picked up when building with `dpkg-buildpackage`. Another tool is 
needed, e.g. sbuild or git-buildpackage.


Cheers,
Kurt



Bug#1066974: freecad: package got copletely removed from Debian testing

2024-03-16 Thread Kurt Kremitzki
The current status of this:

- the Path workbench has a test which checks string equality on generated vs 
expected G-code for an operation. On the i386 arch only, the produced G-code is 
not what is expected, although it is consistent. In a G-code viewer, what is 
produced is visually identical, just with an increased number of arcs of 
shorter length. I've patched this test with a special-case check to use a 
different "expected" string id the arch is i386, and this works, even if not 
elegant; the further yak-shaving needed has been discussed with upstream.

- on armel, it seems FEM workbench tests are failing, but it isn't enough to 
e.g. disable that workbench, because then the failures just pop up elsewhere. 
I've repeated this "disable test, different test segfaults elsewhere" pattern 
about 5 times. It seems like, for some reason, the armel builds are no longer 
viable. It isn't ideal, but FreeCAD is probably not getting much use on the 
arch, so it may be that it ought to be removed from the architecture.

I would appreciate some feedback on these 2 items. I could do an upload with a 
patch for the Path test and request armel removal if nobody has any better 
suggestions or reservations about this approach.

Thanks,
Kurt


Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Can't connect to Active Directory with openssl

2024-03-04 Thread Kurt Roeckx
Hi,

It's unclear to me what you're reporting as error. The connection seems to be 
working. The verification of the certificate seems to fail. It seems you have 
your own CA, but the CA is not trusted because it's not in the certificate 
store.

Kurt

Bug#1060837: update-auctex-elisp --daemon creates INITFILE in /

2024-01-15 Thread Kurt Hornik
Package: auctex
Version: 13.2-1

Invoking

  /usr/sbin/update-auctex-elisp --daemon

creates and leaves behind INITFILE in /, from

if [ -n "${DAEMON_MODE}" -a "${DAEMON_MODE}" = 'true' ]; then
export _UPDATE_AUCTEX_ELISP_DAEMON_MODE=${DAEMON_MODE}
cd / && nohup ${0} ${_FLAVORS} /dev/null &

and

INITFILE=$(mktemp ./-el)

Perhaps best to always create INITFILE in /tmp?

This is with current Debian testing/unstable.

Best
-k



Bug#1016430: netgen: New upstream version 6.2.2007 available / why is the version overriden with +really?

2023-11-13 Thread Kurt Kremitzki

Hello Drew,

On 11/13/23 14:52, Drew Parsons wrote:

Package: netgen
Followup-For: Bug #1016430

I've prepared netgen 6.2.2305 in experimental. I guess we might as
well close this bug when it gets uploaded to unstable.

Still, I'd also be interested to hear what the motivation was for the
+really6.2.1905 version.



Thank you very much for working on Netgen. (Sorry Tobias for never 
getting around to replying to this!)


For convenience, let me quote for explanation my Nov 2020 Patreon post 
on this issue, but first TLDR, this was because upstream's use of 
architecture-specific assembly causing all builds except amd64 to fail, 
and patching that version was too difficult:



The problem, for those who aren't familiar, was that Netgen upstream
made several changes which are specific to the x86_64 (amd64)
architecture in the 6.2.2006 release I had originally uploaded.



Debian builds were only succeeding on amd64 but failing on all the
other architectures: i386, armel, armhf, arm64, mipsel, mips64el,
ppc64el, and s390x.



I was able to fix some of the problems by switching to an older
version (thus the version 6.2.2006+really6.2.1905) but that only
fixed builds on i386 (aka 32-bit x86.)



Problems still remained with the platform-specific usage of
_mm_pause() and __rdtsc(). For __rdtsc(), I was able to resolve it
with a patch to use C++11's std::chrono::steady_clock. For
_mm_pause(), after some research I came up with a patch that uses
architecture-specific assembly that corresponds to x86's _mm_pause()
behavior.


So, since you've gotten it working, there is indeed no reason to hold 
off on closing this bug and moving forward.


Thanks,
Kurt



Bug#1007669: lice: please consider upgrading to 3.0 source format

2023-10-03 Thread Kurt Roeckx
You seem to have moved the config file for some reason. Are you sure you wanted 
to do that?

Bug#1049866: kernelshark: segfaults with certain trace.dat files

2023-08-16 Thread Kurt Kanzenbach
Package: kernelshark
Version: 2.9.3+really2.2.0-2
Severity: important
X-Debbugs-Cc: kurt.kanzenb...@linutronix.de

Dear Maintainer,

kernelshark in Debian Bookworm segfaults on certain trace.dat files. Especially
traces taken with a lot events such as 'syscalls' cause this problem. It
basically makes kernelshark unusable.

The problem exists in kernelshark v2.2.0. It was reported and fixed upstream:

 - Bugreport Upstream: https://bugzilla.kernel.org/show_bug.cgi?id=217429
 - Patch: 
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/commit/?id=9f2097c9669fb7d5f72351343f34fb86649d1365

Please, consider updating kernelshark to v2.2.1. The diff between v2.2.0..v2.2.1
are only two bugfixes. And one of them fixes the observed segmentation fault.

Furthermore, please get the bugfix also into Debian stable.

Example:

|kurt@kurt tmp % kernelshark
|loading plugin "sched_events" from 
/usr/lib/x86_64-linux-gnu/kernelshark/plugins/plugin-sched_events.so
|loading plugin "event_field_plot" from 
/usr/lib/x86_64-linux-gnu/kernelshark/plugins/plugin-event_field_plot
|loading plugin "latency_plot" from 
/usr/lib/x86_64-linux-gnu/kernelshark/plugins/plugin-latency_plot.so
|loading plugin "kvm_combo" from 
/usr/lib/x86_64-linux-gnu/kernelshark/plugins/plugin-kvm_combo.so
|loading plugin "missed_events" from 
/usr/lib/x86_64-linux-gnu/kernelshark/plugins/plugin-missed_events.so
|Loading  "trace.dat"
|plugin "kvm_combo" failed to initialize on stream trace.dat
|[1]32612 segmentation fault (core dumped)  kernelshark

Thanks,
Kurt

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

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

Versions of packages kernelshark depends on:
ii  fonts-freefont-ttf  20120503-10
ii  libc6   2.36-9+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libkshark2  2.2.0-2
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5gui5  5.15.8+dfsg-11
ii  libqt5widgets5  5.15.8+dfsg-11
ii  libstdc++6  12.2.0-14
ii  libtraceevent1  1:1.7.1-1
ii  pkexec  122-3
ii  trace-cmd   3.1.6-1

kernelshark recommends no packages.

kernelshark suggests no packages.

-- no debconf information



Bug#1042889: Debian PR #1042889

2023-08-10 Thread Kurt Hornik
Ian/Dirk,

Have you seen

  

?

This points to a branch of VM at

  

which apparently at some point in time passed native compilation (I
never got a chance to try to far).

I can try to follow up with Uday Reddy and Mark Diekhans to try merging
the native compilation fixes into the main branch (at least).

Afaict, part of the problem was Emacs 29 not being out when this was
reported, and Emacs 28 having native compilation off by default but on
for the Debian packages.  In any case, Emacs 29 is out now, so I guess
time to ask again.

Best
-k



Bug#1035296: kicad: Program crashes

2023-05-07 Thread Serkan KURT
 Hello
After installing "libngspice0 (40+ds-1)" from experimental repository the 
problem was not recur.
Thank you for your interest.
Best regards.Serkan


Bug#1030626: Unable to print PDF file with Evince on Gnome on Debian 12.

2023-04-29 Thread Serkan KURT
Dear Maintainer,Unfortunately the problem persists.I reinstalled the system 
with the iso dated 2023-04-05. All updates have been made as of now.
yours sincerely


Bug#1034004: afl++: afl-clang(-fast) does not support -m32 due to missing afl-compiler-rt-32.o

2023-04-09 Thread Kurt Roeckx
This seems to be caused by a missing build-depends. If I build it
locally, I do get support for 32 bit builds.



Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

2023-03-03 Thread Kurt Roeckx
Hi,

Is the issue that with older glibc versions, it was silently casted
to a 32 bit value, but now that glibc supports 64 bit, it knows
it can't represent it, and gives an error?

Maybe for bookworm, we should just ignore the test error?


Kurt



Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'

2023-03-03 Thread Kurt Roeckx
Hi,

Are you waiting for something before uploading this fix?


Kurt



Bug#1023284: libevent: FTBFS with glibc 2.36

2023-03-03 Thread Kurt Roeckx
Hi,

It seems a fix for this is sitting git, but hasn't been uploaded. Is
there a reason it's not been uploaded yet?


Kurt



Bug#1030060: gforth info manual is not installed

2023-01-30 Thread T. Kurt Bond
Package: gforth
Version: 0.7.3+dfsg-9+b3

The info manual for gforth is not installed.  The emacs lisp support is, so
the info manual should be also.
-- 
T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io


Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

2023-01-23 Thread Kurt H Maier
This bug also causes the desktop to be accessible for a split second
before the lock screen kicks in when resuming from suspend, c.f
https://askubuntu.com/questions/1383379/xubuntu-desktop-visible-after-suspend-before-lock-screen/

I know disabling upower-glib support was frowned upon in the past but
modern upower does not handle suspend/resume or lid events (that
happens via other systemd components now) and xfce4-settings doesn't
need upower for xfce4-power-manager to work properly.

Recompiling wihtout upower-glib closes what is essentially a security
bug, since the expectation is that resumed systems are locked, and this
problem presents a second or two of unrestricted access to the desktop
before locking kicks in.  

I've tested this on a Thinkpad X1 Yoga Titanium and a Thinkpad X1 Yoga
Generation 3 (both with Intel graphics) and a Dell Precision 7820 with
an AMD WX 5100 card, so I don't think it's nVIDIA specific.

Please reconsider --enable-upower-glib.

Thanks,
khm



Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

2022-12-27 Thread Kurt Meyer
This is still an issue with the 0.4.13-1 upgrade. I'm downgrading once again to 
0.4.11-5 until the issue gets resolved or a proper workaround is provided, 
preferrably via apt-listchanges News.

Bug#1026103: aflplusplus: FTBFS on s390x

2022-12-14 Thread Kurt Roeckx
Source: aflplusplus
Version: 4.04c-2
Severity: serious

Hi,

Your package is failing to build on s390x:
[*] Compiling afl++ for OS Linux on ARCH s390x
./test/unittests/unit_maybe_alloc
[==] Running 6 test(s).
[ RUN  ] test_pow2
[   OK ] test_pow2
[ RUN  ] test_null_allocs
[   OK ] test_null_allocs
[ RUN  ] test_nonpow2_size
[   OK ] test_nonpow2_size
[ RUN  ] test_zero_size
[   OK ] test_zero_size
[ RUN  ] test_unchanged_size
[   OK ] test_unchanged_size
[ RUN  ] test_grow_multiple
[   OK ] test_grow_multiple
[==] 6 test(s) run.
[  PASSED  ] 6 test(s).
./test/unittests/unit_preallocable
[==] Running 2 test(s).
[ RUN  ] test_alloc_free
[   OK ] test_alloc_free
[ RUN  ] test_prealloc_overflow
[   OK ] test_prealloc_overflow
[==] 2 test(s) run.
[  PASSED  ] 2 test(s).
./test/unittests/unit_list
[==] Running 3 test(s).
[ RUN  ] test_contains
[   OK ] test_contains
[ RUN  ] test_foreach
[   OK ] test_foreach
[ RUN  ] test_long_list
[   OK ] test_long_list
[==] 3 test(s) run.
[  PASSED  ] 3 test(s).
./test/unittests/unit_rand
[==] Running 2 test(s).
[ RUN  ] test_rand_0
[   OK ] test_rand_0
[ RUN  ] test_rand_below
[   OK ] test_rand_below
[==] 2 test(s) run.
[  PASSED  ] 2 test(s).
./test/unittests/unit_hash
[==] Running 1 test(s).
[ RUN  ] test_hash
[   OK ] test_hash
[==] 1 test(s) run.
[  PASSED  ] 1 test(s).
make[3]: Leaving directory '/<>'
␛[1;90m[*] 10 test cases completed.␛[0m
␛[1;93m[-] not all test cases were executed
␛[0;31m[!] failure in tests :-(␛[0m
make[2]: *** [GNUmakefile:343: tests] Error 1

It's not at all clear why it says: "failure in tests". All the test seem
to pass. Other architectures also have the "not all test cases were
executed" message.

I've tried to build it again on the buildds, but it failed the same way.


Kurt



Bug#1025454: afl: Downloads software during build

2022-12-04 Thread Kurt Roeckx
Source: aflplusplus
Version: 4.04c-1
Severity: serious

Hi,

On the buildds, we get:
# -/usr/bin/make -C utils/plot_ui
/usr/bin/make -C frida_mode
make[3]: Entering directory '/<>/frida_mode'
mkdir -p /<>/frida_mode/build/
mkdir -p /<>/frida_mode/build/frida/
wget -qO 
/<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz
 
"https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz;
 || curl -L -o 
/<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz
 
"https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz;
/bin/sh: 1: wget: not found
/bin/sh: 1: curl: not found
make[3]: *** [GNUmakefile:313: 
/<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz]
 Error 127
make[3]: Leaving directory '/<>/frida_mode'
make[2]: [GNUmakefile:636: distrib] Error 2 (ignored)
cd nyx_mode && ./build_nyx_support.sh
=
   Nyx build script
=

[*] Performing basic sanity checks...
[*] Making sure all Nyx is checked out
./build_nyx_support.sh: line 41: git: command not found
make[2]: [GNUmakefile:637: distrib] Error 127 (ignored)
cd qemu_mode && sh ./build_qemu_support.sh
=
   QemuAFL build script
=

[*] Performing basic sanity checks...
[+] All checks passed!
[*] Making sure qemuafl is checked out
[*] cloning qemuafl
Trying to clone qemuafl (attempt 1/3)
./build_qemu_support.sh: 84: git: not found
Trying to clone qemuafl (attempt 2/3)
./build_qemu_support.sh: 84: git: not found
Trying to clone qemuafl (attempt 3/3)
./build_qemu_support.sh: 84: git: not found
[-] Not checked out, please install git or check your internet connection.
make[2]: [GNUmakefile:638: distrib] Error 1 (ignored)
cd unicorn_mode && unset CFLAGS && sh ./build_unicorn_support.sh
=
UnicornAFL build script
=
[...]

On machines that have more software installed, it will download various
things and build them. It makes at least use of software like wget,
curl, git, cargo. Packages in Debian should be build only from the
source and not download more sources from internet.


Kurt



Bug#1025443: aflplusplus: Missing lld-14 Build-Depends

2022-12-04 Thread Kurt Roeckx
Source: aflplusplus
Version: 4.04c-1

Hi,

The LTO mode is not build at runtime, the log shows:
[+] llvm_mode detected llvm 10+, enabling neverZero implementation and c++14
[+] llvm_mode detected llvm 11+, enabling afl-lto LTO implementation
GNUmakefile.llvm:229: ld.lld not found, cannot enable LTO mode

This is because there is a missing Build-Depends on lld-14.

The LTO mode is the recommended mode.


Kurt



Bug#1024631: gitlab: preinst: invalid number 9.1

2022-11-22 Thread Kurt Roeckx
On Tue, Nov 22, 2022 at 06:13:30PM +0100, Kurt Roeckx wrote:
> In any case, the default cluster points to 14, it's just not on port 5432.

That doesn't seem to be true. Commands like createdb, psql default to
port 5432 if there is nothing overriding it, like PGPORT env variable.


Kurt



Bug#1024631: gitlab: preinst: invalid number 9.1

2022-11-22 Thread Kurt Roeckx
On Tue, Nov 22, 2022 at 10:20:06PM +0530, Pirate Praveen wrote:
> 
> 
> On Tue, Nov 22 2022 at 02:27:05 PM +01:00:00 +01:00:00, Kurt Roeckx
>  wrote:
> > Package: gitlab
> > Version: 15.4.2+ds1-1~fto11+3
> > 
> > On install I get:
> > /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1
> > 
> > I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them
> > are used. 9.1 is using port 5432.
> > 
> 
> Do you have another recommendation on how to make sure we use at least
> postgresql 12?
> 
> Does adding a configuration option to skip this check
> "gitlab_pg_version_check" which can be set to "false" in
> /etc/gitlab/gitlab-debian.conf suffice?

Note that it just continues the installation because it ignores
the error.

To be able to install things, I had to edit the database.yml to set the
port number. I also had to manually create the user and database.

I think it asks for a hostname, but not for a port number. I at least
assume it supports a remote database. The check should be for that
combination, which is probably harder. In any case, the default cluster
points to 14, it's just not on port 5432.


Kurt



Bug#1024627: Acknowledgement (gitlab: Fails to install)

2022-11-22 Thread Kurt Roeckx
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 version
from backports is too new it seems, and it what gets installed when
you just do: apt install gitlab



Bug#1024631: gitlab: preinst: invalid number 9.1

2022-11-22 Thread Kurt Roeckx
Package: gitlab
Version: 15.4.2+ds1-1~fto11+3

On install I get:
/var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1

I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them
are used. 9.1 is using port 5432.


Kurt



Bug#1024627: gitlab: Fails to install

2022-11-22 Thread Kurt Roeckx
Package: gitlab
Version: 15.4.2+ds1-1~fto11+3
Severity: serious

Setting up gitlab (15.4.2+ds1-1~fto11+3) ...
Bundler could not find compatible versions for gem "omniauth-oauth2":
  In Gemfile:
omniauth-auth0 (~> 2.0) was resolved to 2.0.0, which depends on
  omniauth-oauth2 (~> 1.4) x86_64-linux

omniauth-authentiq (~> 0.3.3) was resolved to 0.3.3, which depends on
  omniauth-oauth2 (>= 1.5) x86_64-linux

omniauth-azure-activedirectory-v2 (~> 1.0) was resolved to 1.0.0, which 
depends on
  omniauth-oauth2 (~> 1.7) x86_64-linux

omniauth-dingtalk-oauth2 (~> 1.0) was resolved to 1.0.0, which depends on
  omniauth-oauth2 (~> 1.7.1) x86_64-linux

omniauth-facebook (~> 4.0) was resolved to 4.0.0, which depends on
  omniauth-oauth2 (~> 1.2) x86_64-linux

omniauth-oauth2-generic (~> 0.2.2) was resolved to 0.2.2, which depends on
  omniauth-oauth2 (~> 1.0) x86_64-linux

Could not find gem 'omniauth-oauth2 (~> 1.7.1)', which is required by gem 
'omniauth-auth0 (~> 2.0)', in any of the sources.


Kurt



Bug#993089: marked as pending in freecad

2022-10-27 Thread Kurt Kremitzki
Sorry for the noise, looks like we have an automation double-fire from 
when I merged the master branch into a PPA one and pushed it.




Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

2022-10-26 Thread Kurt Meyer
Uninstalling PulseAudio is a workaround, not a bug fix in my opinion. The 
latest wireplumber and libwireplumber-0.4-0 upgrade still results in no audio. 
Additionally, I failed to mention in my previous reply that I was also unable 
to stream video with the upgrades; e.g. YouTube.

The Debian Wiki page for Pipewire states that Pipewire as a replacement for 
PulseAudio "may be a comfortable drop-in replacement..." under Debian Testing 
and Unstable. Additionally, there's no mention that both can't or shouldn't be 
used together. If this is no longer the case, then shouldn't there have been an 
apt-listchanges News report after the recent wireplumber and 
libwireplumber-0.4-0 upgrades?


Bug#1021997: cargo: New upstream version

2022-10-18 Thread Kurt Roeckx
Source: cargo
Version: 0.57.0-7
Severity: wishlist

Hi,

Would it be possible to upload a newer version of cargo? The current
version is preventing me from building things. I think the 0.62 version
matches the 1.61 version of rustc that's currently in testing/unstable.


Kurt



Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

2022-10-10 Thread Kurt Meyer
Same issue on my end. Specs for the affected hardware below.

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.35-3
ii  libglib2.0-0  2.74.0-2
ii  libpipewire-0.3-0 0.3.59-1
ii  libwireplumber-0.4-0  0.4.11-5
ii  pipewire  0.3.59-1

Versions of packages wireplumber recommends:
pn  pipewire-pulse  

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  
pn  wireplumber-doc   

-- no debconf information

-- Audio Information:
  Device-1: Intel Haswell-ULT HD Audio driver: snd_hda_intel
  Device-2: Intel 8 Series HD Audio driver: snd_hda_intel
  Sound Server-1: ALSA v: k5.14.0-3-amd64 running: yes
  Sound Server-2: PulseAudio v: 16.1 running: yes
  Sound Server-3: PipeWire v: 0.3.59 running: yes

--Graphics Information:
  Device-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel
  Device-2: Suyin Asus Integrated Webcam type: USB driver: uvcvideo
  Display: server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
unloaded: fbdev,vesa gpu: i915 resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel HD Graphics 4400 (HSW GT2) v: 4.6 Mesa
22.2.0



Bug#1020652: [Pkg-openssl-devel] Bug#1020652: openssl: tls_process_key_exchange:internal error:../ssl/statem/statem_clnt.c:2254:

2022-09-25 Thread Kurt Roeckx
On Sun, Sep 25, 2022 at 02:16:00AM +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
> 
> >On Sat, Sep 24, 2022 at 10:34:19PM +0200, Thorsten Glaser wrote:
> >> $ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443 
> >> -legacy_renegotiation -tls1
> >
> >TLS 1.0 is not supported by default because it's insecure. You need
> >to change the security level to 0, for instance by using the cipher
> >string DEFAULT@SECLEVEL=0
>^ +colon
> 
> Hey, this used to work at @SECLEVEL=2 even, with just MinProtocol
> changed. Also openssl ciphers shows the same, independent of the
> number used for @SECLEVEL. How can I find out, for any installed
> OpenSSL, which settings this mysterious @SECLEVEL influences and
> which are available? Where is this documented?

There is /usr/share/doc/openssl/NEWS.md.gz, which says:
  * SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0,
except when RSA key exchange without SHA1 is used.

So this also works:
openssl s_client -connect www.mirbsd.org:443 -cipher AES256-SHA 
-legacy_renegotiation -tls1

That's the only cipher you have with RSA key exchange. Your server
doesn't have a preference for ciphers, so picks the first offered by the
client, so the order is important.

Security levels are documented in SSL_CTX_set_security_level(3):
https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_security_level.html

SHA1 have been moved to security level 0 because it no longer
provides enough security, even when combined with MD5.


Kurt



Bug#965041: [Pkg-openssl-devel] Bug#965041: Bug#965041: libssl3: Please stop building legacy provider

2022-09-18 Thread Kurt Roeckx
On Sun, Sep 18, 2022 at 07:09:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-07-16 08:46:43 [+0200], Kurt Roeckx wrote:
> > On Thu, Jul 16, 2020 at 03:57:17AM +0100, Dimitri John Ledkov wrote:
> > > 
> > > openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.
> > 
> > That would actually make sense.
> > 
> > We could use the include thing to ship a config file for the
> > fips module with the correct hash in it.
> 
> Kurt, what do we do here?
> Split /usr/lib/*/ossl-modules/legacy.so into its own package which is
> part of src:openssl and adds a config snippet.

I'm not sure that having the legacy provider automatically enabled by
default when it's installed is a good idea. That means once it's
installed, all applications have it by default. I think it needs to be
enabled per application.

I think the same goes for fips. Only applications that need it, and
probably support a library context should enable it. I don't know enough
details currently about fips, but I think applications need to provider
an approved RNG, and /dev/random is no longer acceptable.
But upgrading the fips provider should be as easy as possible,
just installing a new version. So I think we need to provider at least
some config file should have the hash in it.


Kurt



Bug#805646: [Pkg-openssl-devel] Bug#805646: Bug#805646: Package using openssl functions does not find default certificates

2022-09-13 Thread Kurt Roeckx
On Tue, Sep 13, 2022 at 06:40:19PM +0200, Sebastian Andrzej Siewior wrote:
> On 2022-09-13 18:30:05 [+0200], Kurt Roeckx wrote:
> > > > 3) provide a symlink from /usr/lib/ssl/cert.pem to
> > > >/etc/ssl/certs/ca-certificates.crt
> > > 
> > > Kurt, I tend to provide this symlink. Any objections?
> > > I'm kind of confused that it works for others, like curl. But I don't
> > > see anything wrong with what is done in this bug report.
> > 
> > We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages.
> 
> what I see is:
> | openat(AT_FDCWD, "/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3
> | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such 
> file or directory)
> | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such 
> file or directory)
> 
> This is X509_CERT_FILE / X509_get_default_cert_file().
> 
> So it would need a symlink from this non existing file to
> /etc/ssl/certs/ca-certificates.crt which is provided/ created by
> ca-certificates.

That works for me.


Kurt



Bug#805646: [Pkg-openssl-devel] Bug#805646: Package using openssl functions does not find default certificates

2022-09-13 Thread Kurt Roeckx
On Tue, Sep 13, 2022 at 05:23:43PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-01-04 23:50:10 [+0100], Jan Dittberner wrote:
> > I don't know whether this will have negative side effects but from my point
> > of view it would be nice if the openssl package would do one of the
> > following to properly solve this issue:
> > 
> > 1) properly load certificates from /etc/ssl/certs when
> >SSL_CTX_set_default_verify_paths is called
> 
> so I guess this works but it does not provide what it should provide,
> right Kurt?
> 
> > 2) change the default paths to /etc/ssl/certs and
> >/etc/ssl/certs/ca-certificates.crt instead of /usr/lib/ssl/certs and
> >/usr/lib/ssl/cert.pem
> > 
> > 3) provide a symlink from /usr/lib/ssl/cert.pem to
> >/etc/ssl/certs/ca-certificates.crt
> 
> Kurt, I tend to provide this symlink. Any objections?
> I'm kind of confused that it works for others, like curl. But I don't
> see anything wrong with what is done in this bug report.

We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages.


Kurt



Bug#1017817: Emacs 28.1+1-2 Upgrade

2022-08-26 Thread Kurt Meyer
Using the new upgrade causes high CPU usage on my ASUS Zenbook UX303LA laptop. 
Downgrading all emacs packages to v28.1+1-1 resolved the issue.


Bug#1017779: emacs-common dies in postinst with "corrupted double-linked list"

2022-08-21 Thread Kurt Meyer
I've upgraded emacs-common on both of my computers without issue, so the issue 
that the OP is experiencing may be unique to the emacs-lucid package, which I 
do not have installed on either of my computers.


Bug#1017798: emacs-common can't be installed

2022-08-21 Thread Kurt Meyer
I've upgraded emacs-common on both of my computers without issue, so the issue 
that the OP is experiencing may be unique to the elpa-htmlize package, which I 
do not have installed on either of my computers.

Bug#1016526: [Pkg-openssl-devel] Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

2022-08-02 Thread Kurt Roeckx
On Tue, Aug 02, 2022 at 12:50:05PM +0200, Jérémy Lal wrote:
> Package: openssl
> Version: 3.0.5-1
> Severity: normal
> Control: affects -1 nodejs
> 
> Hi,
> 
> while building nodejs 18.6.0+dfsg-4 on mips64el, some SSL tests did regress,
> https://buildd.debian.org/status/logs.php?pkg=nodejs=mips64el
> (look for "not ok" tests).
> 
> In particular, test-crypto-sign-verify test failed with an unexpected error:
> 'error:1E08010C:DECODER routines::unsupported'

For some reason it seems to expect to fail with some other error
instead.

It's currently unclear that this is an openssl bug. Can you show
what that code is trying to do, and what it expects openssl to return?

There seem to be various other test suite failures that don't seem to be
related to openssl at all.

> I suppose the root cause is similar to the one for
> [EC code appears to be broken on s390x](https://bugs.debian.org/1016290),
> but it's not the same bug.

It will be totally unrelated. That one is very specific to s390x.


Kurt



Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)

2022-07-19 Thread Kurt Roeckx
On Tue, Jul 19, 2022 at 06:11:23PM +0200, Diederik de Haas wrote:
> According to that bug report it should be fixed with 5.19-rc6 and that 
> version 
> is available in experimental. Can you verify whether it also fixes your issue?

With that version the error goes away.



Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)

2022-07-18 Thread Kurt Roeckx
This is probably https://bugzilla.kernel.org/show_bug.cgi?id=216140


Kurt



Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)

2022-07-18 Thread Kurt Roeckx
I tried older kernels, 5.17.3-1 didn't show it.



Bug#1015240: linux: rejecting DMA map of vmalloc memory

2022-07-18 Thread Kurt Roeckx
48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d c7 9e 0d 00 f7 d8 64 89 01 48
[5.655747] RSP: 002b:7ffe1524db38 EFLAGS: 0246 ORIG_RAX: 
0139
[5.655749] RAX: ffda RBX: 55c575ca17c0 RCX: 7ff9a8a32f79
[5.655749] RDX:  RSI: 7ff9a8becf0d RDI: 0006
[5.655750] RBP: 0002 R08:  R09: 55c575ca15b0
[5.655751] R10: 0006 R11: 0246 R12: 7ff9a8becf0d
[5.655751] R13:  R14: 55c575d7ffe0 R15: 55c575ca17c0
[5.655753]  
[5.655753] ---[ end trace  ]---

The oldest log I have also has, which was 5.18.2-1.

I can try to boot older kernels if needed.


Kurt



Bug#995636: transition: openssl

2022-06-05 Thread Kurt Roeckx
On Sun, Jun 05, 2022 at 08:44:22PM +0200, Sebastian Andrzej Siewior wrote:
> On 2022-06-05 19:42:43 [+0200], Sebastian Ramacher wrote:
> > Hi Sebastian
> Hi Sebastian,
> 
> > > Otherwise I'd fear that the only other options are openssl breaking
> > > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific
> > > name. Given the high number reverse dependencies involved in this
> > > transition (and also those depending on bin:openssl), I'd prefer to
> > > avoid a Breaks that could have the potential to force the libssl1.1 ->
> > > libssl3 upgrade to be more of a lockstep transition than needed.
> > 
> > I see that there was another openssl upload. Any reason a fix for this
> > issue wasn't included in the upload of 3.0.3-6?
> 
> I wasn't aware that this is something that we want do. Kurt pointed me
> to the testsuite problem which was the primary motivation for the
> upload.
> Regarding dovecot, Kurt wanted to make some time for it. The patch in
> ubuntu is working but is a giant duct tape which is not something I
> would wan to upload…
> Anyway, regarding the openssl.cnf. Do we want to use openssl-3.cnf for
> libssl3? We can't make opnenssl-1.1.cnf happen. The modification
> openssl.cnf already happend so people need to make changes manually…
> Is this the request here?

The suggestion was to make an openssl.cnf that's compatible with 1.1.1,
and so remove or comment out everything related to providers.


Kurt



Bug#995636: transition: openssl

2022-05-27 Thread Kurt Roeckx
On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote:
> 
> That leaves #1011051. What's your view on that bug?

So my understanding is that 1.1.1 doesn't understand the new
configuration file and tries to load an engine (instead of a
provider).

We could ship a file that's comptabile with 1.1.1. That would make it
a little bit harder to load some providers by default, but maybe that's
something you want to do per application anyway.


Kurt



Bug#1011243: nvidia-cuda-toolkit: Hard dependency on libssl1.1

2022-05-18 Thread Kurt Roeckx
Source: nvidia-cuda-toolkit
Version: 11.4.3-2
Severity: serious
Tags: sid bookworm

Hi,

It seems build-depends on libssl1.1 and not on libssl-dev. It also
depends on libssl1.1 and doesn't transition to libssl3 on rebuild.
Can you please move to using libssl3?


Kurt



Bug#1011242: thrift: No depends on libssl after rebuild against OpenSSL 3.0

2022-05-18 Thread Kurt Roeckx
Source: thrift
Version: 0.16.0-5
Severity: serious
Tags: sid bookworm

Hi,

It seems that thrift does not depend on libssl after being rebuild
against OpenSSL 3.0, but did depend on libssl1.1.


Kurt



Bug#1010958: sscg FTBFS with OpenSSL 3.0.3

2022-05-15 Thread Kurt Roeckx
It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247



Bug#1010128: Acknowledgement (linux-image-5.17.0-1-amd64: DKMS Module Rebuild for Broadcom Wireless Chip BCM4352 Fails to Build)

2022-05-12 Thread Kurt Meyer
Consider closing this bug report. The broadcom-sta-dkms 6.30.223.271-19 upgrade 
resolved the issue.

On Sun, Apr 24, 2022, at 19:03, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1010128: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010128.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Kernel Team 
>
> If you wish to submit further information on this problem, please
> send it to 1010...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> -- 
> 1010128: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010128
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



Bug#996276: foxeye: FTBFS with OpenSSL 3.0

2022-05-11 Thread Kurt Roeckx
On Wed, May 11, 2022 at 07:25:45PM +0300, Andriy Grytsenko wrote:
> >You can test it by installing the version from unstable.
> 
> It is not in unstable yet, see

That should have said experimental.


Kurt



Bug#996276: foxeye: FTBFS with OpenSSL 3.0

2022-05-11 Thread Kurt Roeckx
tags 996276 - bookworm-ignore experimental + bookworm sid
thanks

This is affecting the bookworm release. The release managers approved the 
upload to unstable and marked it as serious/release critical.

You can test it by installing the version from unstable.

Bug#1010128: linux-image-5.17.0-1-amd64: DKMS Module Rebuild for Broadcom Wireless Chip BCM4352 Fails to Build

2022-04-24 Thread Kurt Meyer
Package: src:linux
Version: 5.17.3-1
Severity: important

Dear Maintainer,

I received the following errors when linux-image-5.17.0-1-amd64 was installed. 
Error also occurred with the linux-headers-5.17.0-1-amd64 package. Result is I 
have no wireless connectivity when booting with kernel version 5.17.0-1. I have 
to boot with the kernel version 5.16.0-6 to have wireless connectivity.

---ERROR START---

Setting up linux-image-5.17.0-1-amd64 (5.17.3-1) ...
I: /vmlinuz is now a symlink to boot/vmlinuz-5.17.0-1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.17.0-1-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.17.0-1-amd64:Deprecated 
feature
: REMAKE_INITRD
Deprecated feature: Deprecated feature: REMAKE_INITRD
REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD

Building module:
cleaning build area...
make -j4 KERNELRELEASE=5.17.0-1-amd64 KVER=5.17.0-1-amd64...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.17.0-1-amd64 (x86_64)
Consult /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log for more 
information.

---ERROR END---

Contents of make.log:

https://pastebin.com/XUJbXbbn


** Model information
sys_vendor: ASUSTeK Computer INC.
product_name: ET2321I
product_version: 0801
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: 0801
board_vendor: ASUSTeK COMPUTER INC.
board_name: ET2321I
board_version: Rev 1.xx

** PCI devices:

03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4352 
802.11ac Wireless Network Adapter [14e4:43b1] (rev 03)
Subsystem: AzureWave BCM4352 802.11ac Wireless Network Adapter [1a3b:2123]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: wl
Kernel modules: bcma, wl

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

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

Versions of packages linux-image-5.17.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.141
ii  kmod29-1
ii  linux-base  4.8

Versions of packages linux-image-5.17.0-1-amd64 recommends:
ii  apparmor 3.0.4-2
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.17.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-2
pn  linux-doc-5.17  

Versions of packages linux-image-5.17.0-1-amd64 is related to:
ii  firmware-amd-graphics 20210818-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20210818-1
ii  firmware-misc-nonfree 20210818-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information


Bug#692917: printer-driver-escpr: color error on armel

2022-04-02 Thread Kurt Roeckx
On Sat, Apr 02, 2022 at 11:19:26AM +0200, Thorsten Alteholz wrote:
> Hi Kurt and Patrik,
> 
> thanks a lot for your reports. Can you please check whether the problem
> still exists after a few new upstream versions?

Both the printer and the armel server have been replaced in the mean time.


Kurt



Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

2022-03-22 Thread Kurt Roeckx
On Tue, Mar 22, 2022 at 10:13:25PM +0100, Sebastian Andrzej Siewior wrote:
> On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote:
> > On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote:
> > > OpenSSL signature algorithm check tightening
> > > =
> > > 
> > > The OpenSSL update included in this point release includes a change to
> > > ensure that the requested signature algorithm is supported by the
> > > active security level.
> > > 
> > > Although this will not affect most use-cases, it could lead to error
> > > messages being generated if a non-supported algorithm is requested -
> > > for example, use of SHA1 with the default security level of 2. In such
> > > cases, the security level will need to be explicitly lowered when
> > > invoking OpenSSL, using an option such as
> > > 
> > > -cipher "ALL:@SECLEVEL=1"
> > > "
> > 
> > So reading it again, I think the "when invoking OpenSSL" is confusing.
> > Not only the openssl binary is affected, but also all clients and
> > server applications making use of the library are. Some applications
> > might have a way to set the cipher in their own configuration file,
> > others might need to change the defaults in /etc/ssl/openssl.cfg
> 
> s/openssl.cfg/openssl.cnf
> 
> Kurt correct me if I'm wrong:
> This only affects clients which were using TLS1.2 while connecting to
> the server and did not send a sig-alg string which let the server
> fallback to the default (sha1) which was not checked vs security level.
> Would the client have sent sha1 as the sig-cipher then it would fail in
> the version d, too.

The client can send a list of supported sigalgs. Before the change there
were 3 options:
- the client didn't send anything, the server selected SHA1
- the client only send SHA1, the server selected SHA1
- the client send both SHA1 and SHA256, the server selected SHA256

With this change, it changes to:
- the client didn't send anything, the server selects SHA1 for security level 
<= 1,
  for security level >= 2 it returns an error.
- the client only send SHA1, the server selects SHA1 for security level <= 1,
  for security level >= 2 it returns an error.
- the client send both SHA1 and SHA256, the server selects SHA256.

The default client will send both SHA1 and SHA256 for a very long time,
but you can change the settings. If the server selects SHA1, before the
change the client will accept it, after the change it requires security
level <= 1.

When talking about SHA1 here, it's really about something RSA+SHA1, as
in an RSA signature over a SHA1 hash.

> Would the client need a lower protocol (TLSv1.0) then it would fail, too.
> In these two cases the server administrator must have lowered the
> security level to 1 (for the announced low sig-alg) and/or allow TLSv1
> in order for the client to connect. (The same for the other way around).

SHA1 can be used for various things in the protocol. Other uses of SHA1
where already properly rejected, it just allowed SHA1 as signature
algorithm.


Kurt



Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

2022-03-22 Thread Kurt Roeckx
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote:
> OpenSSL signature algorithm check tightening
> =
> 
> The OpenSSL update included in this point release includes a change to
> ensure that the requested signature algorithm is supported by the
> active security level.
> 
> Although this will not affect most use-cases, it could lead to error
> messages being generated if a non-supported algorithm is requested -
> for example, use of SHA1 with the default security level of 2. In such
> cases, the security level will need to be explicitly lowered when
> invoking OpenSSL, using an option such as
> 
> -cipher "ALL:@SECLEVEL=1"
> "

So reading it again, I think the "when invoking OpenSSL" is confusing.
Not only the openssl binary is affected, but also all clients and
server applications making use of the library are. Some applications
might have a way to set the cipher in their own configuration file,
others might need to change the defaults in /etc/ssl/openssl.cfg


Kurt



Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

2022-03-22 Thread Kurt Roeckx
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote:
> Is the note below accurate?

Yes.


Kurt



Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

2022-03-22 Thread Kurt Roeckx
On Tue, Mar 22, 2022 at 07:37:00PM +, Adam D. Barratt wrote:
> On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote:
> > The change in openssl is commit
> >cc7c6eb8135b ("Check that the default signature type is allowed")
> > 
> > Before the commit in question it connects as:
> >   - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
> > 
> > after that, the server throws:
> >   140490373015360:error:14201044:SSL
> > routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880:
> > 
> > and it appears that the security level in openssl forbids SHA1 here.
> > The argument on the s_server side
> >  -sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
> > 
> > doesn't help here but
> >  -cipher "ALL:@SECLEVEL=1"
> > 
> > does. 
> > 
> 
> If we wanted to add a note to the release announcement in case users
> face similar issue with other software, is "tls_choose:sigalg:internal
> error" a reliable signal of this situation occurring? Should the
> recommended solution be to lower the security level, or might
> specifying -sigalgs work on its own in some scenarios?

So to clarify things. The problem is that SHA1 was allowed as signature
algorithm while the security level should not have allowed it. If the
peer does not support SHA256, the security level needs to be lowered
so that SHA1 is allowed again.


Kurt



Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

2022-03-20 Thread Kurt Roeckx
On Mon, Mar 21, 2022 at 12:12:11AM +0100, Sebastian Andrzej Siewior wrote:
> 
> The change in openssl is commit
>cc7c6eb8135b ("Check that the default signature type is allowed")

So that's:
commit cc7c6eb8135be665d0acc176a5963e1eaf52e4e2
Author: Kurt Roeckx 
Date:   Thu Jan 2 22:53:32 2020 +0100

Check that the default signature type is allowed

TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the
others. TLS 1.2 sends a list of supported ciphers, but allows not sending
it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory.

When we didn't receive a list from the client, we always used the
defaults without checking that they are allowed by the configuration.

Reviewed-by: Paul Dale 
GH: #10784
(cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5)


Kurt



Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

2022-03-20 Thread Kurt Roeckx
On Sun, Mar 20, 2022 at 10:00:15PM +0100, Paul Gevers wrote:
> Dear Sebastian, Kurt,
> 
> On 19-03-2022 12:33, Adam D Barratt wrote:
> > Upload details
> > ==
> > 
> > Package: openssl
> > Version: 1.1.1n-0+deb10u1
> > 
> > Explanation: new upstream release
> 
> We're seeing a regression in buster in the autopkgtest of gnutls28 with the
> new version of openssl on all tested architectures. Can you please have a
> look and advise? (bullseye doesn't seem to have the test anymore, hence it
> doesn't fail).
> 
> https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz
> 
> Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> *** Fatal error: A TLS fatal alert has been received.
> Failure: Failed
> *** Fatal error: A TLS fatal alert has been received.
> %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)...
> Failure: Failed
> *** Fatal error: A TLS fatal alert has been received.
> Failure: Failed
> FAIL [11]../../tests/suite/testcompat-main-openssl
> 
> Which, according to me, is this check:
> https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307

That test still seems to exist, but is just moved to a different file:
https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255

My understanding is that gnutls now passes the correct list of signature
algorithms to use to OpenSSL's s_client to be able to do that test, and
that this is probably fixed by:
https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b
(and 
https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667)

I'm trying to remember what was changed and why, but I can't
find/remember it.


Kurt



Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1

2022-03-18 Thread Kurt Roeckx
On Fri, Mar 18, 2022 at 10:22:57PM +0100, Sebastian Andrzej Siewior wrote:
> On 2022-03-18 14:51:32 [+], Adam D. Barratt wrote:
> > Boo. Hope you're doing better.
> 
> Thanks, yes.
> 
> > > I would also do the upload for Buster, would that work? I remember
> > > that
> > > the packages, that broken, were already uploaded a few cycles ago.
> > 
> > Also as 1.1.1n?
> 
> Yes.
> 
> > I assume there haven't been any regressions reported with l/m/n in the
> > meantime.

I'm not aware of any regressions the past year.


Kurt



Bug#1002576: dch doesn't read email settings from config file

2021-12-24 Thread Kurt Roeckx
Package: devscripts
Version: 2.21.7

Running dch will give me:
dch warning: neither DEBEMAIL nor EMAIL environment variable is set
dch warning: building email address from username and mailname
dch: Did you see those 2 warnings?  Press RETURN to continue...

The manual says I can put it in the ~/.devscripts file, but that
doesn't have any effect. strace says it's being read. Putting it
in an environment variable does make the warning go away.


Kurt



Bug#733094: uvcdynctrl still filling the disk

2021-12-08 Thread Kurt Meyer
Thank you Paulo.

On Wed, Dec 8, 2021, at 05:57, Paulo Assis wrote:
> Guvcview functions perfectly without uvcdynctrl.
> uvcdynctrl just adds some exotic uvc ctrls for older logitech cameras, like a 
> led ctrl.
> The recommend can be droped without any problem.
> 
> Regards.
> 
> 
> A quarta, 8/12/2021, 04:12, Kurt Meyer  escreveu:
>> __
>> "Guvcview doesn't depend upon uvcdynctrl it just recommends it." Okay, but 
>> unless you disable "recommends", uvcdynctrl gets installed. Based on a 
>> little bit of research I performed, it is not recommended to disable 
>> "recommends" because recommended packages are usually needed for a more 
>> useful installation.
>> 
>> Source of info for not disabling "recommends":
>> https://unix.stackexchange.com/questions/122289/why-install-recommends-default-is-true
>> 
>> Does guvcview function or function well enough without uvcdynctrl?
>> 
>> *The following additional packages will be installed:***
>> *  libguvcview-2.0-2 libportaudio2 libwebcam0 uvcdynctrl uvcdynctrl-data***
>> *The following NEW packages will be installed:***
>> *  guvcview libguvcview-2.0-2 libportaudio2 libwebcam0 uvcdynctrl 
>> uvcdynctrl-data***
>> *0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.***
>> *Need to get 266 kB/386 kB of archives.***
>> *After this operation, 1,437 kB of additional disk space will be used.*
>> 

Bug#733094: uvcdynctrl still filling the disk

2021-12-07 Thread Kurt Meyer
"Guvcview doesn't depend upon uvcdynctrl it just recommends it." Okay, but 
unless you disable "recommends", uvcdynctrl gets installed. Based on a little 
bit of research I performed, it is not recommended to disable "recommends" 
because recommended packages are usually needed for a more useful installation.

Source of info for not disabling "recommends":
https://unix.stackexchange.com/questions/122289/why-install-recommends-default-is-true

Does guvcview function or function well enough without uvcdynctrl?

*The following additional packages will be installed:**
*
*  libguvcview-2.0-2 libportaudio2 libwebcam0 uvcdynctrl uvcdynctrl-data**
*
*The following NEW packages will be installed:**
*
*  guvcview libguvcview-2.0-2 libportaudio2 libwebcam0 uvcdynctrl 
uvcdynctrl-data**
*
*0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.**
*
*Need to get 266 kB/386 kB of archives.**
*
*After this operation, 1,437 kB of additional disk space will be used.*


Bug#999606: Acknowledgement (fetchmail: configuration requires TLS for SSH authentication)

2021-11-13 Thread Kurt Roeckx
It seems that 6.4.23 actually changed the message to:
configuration requires TLS, but STARTTLS is not permitted because of 
authenticated state (PREAUTH). Aborting connection.  If your plugin is secure, 
you can defeat STARTTLS with --sslproto '' (see manual).


See: https://gitlab.com/fetchmail/fetchmail/-/issues/39



Bug#999606: fetchmail: configuration requires TLS for SSH authentication

2021-11-13 Thread Kurt Roeckx
Package: fetchmail
Version: 6.4.22-1
Severity: serious

Hi,

With version 6.4.22-1 and 6.4.23-1 I get the following error:
configuration requires TLS, but STARTTLS is not permitted because of 
authenticated state (PREAUTH). Aborting connection.  Server permitting, try 
--ssl instead (see manual).

But I'm using ssh authentication (auth ssh), and using the plugin
command I'm remotely start the imap server (doveadm exec imap).
The imap server does not require authentication. As far as fetchmail
is concerned, it should not talk SSL/SSH, or do any authentication,
it's all done externally.

This worked until version 6.4.21-1.


Kurt



Bug#996048: [Pkg-openssl-devel] Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt, it does not conta

2021-10-18 Thread Kurt Roeckx
On Mon, Oct 18, 2021 at 10:40:59PM +0200, Julien Cristau wrote:
> On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote:
> > Hi,
> > 
> > I think the following change might be the relevant one:
> > 
> > --- a/update-ca-certificates
> > +++ b/update-ca-certificates
> > @@ -164,8 +164,6 @@
> >done
> >  fi
> > 
> > -rm -f "$CERTBUNDLE"
> > -
> >  ADDED_CNT=$(wc -l < "$ADDED")
> >  REMOVED_CNT=$(wc -l < "$REMOVED")
> > 
> > It triggers this stderr output during openssl rehash (l. 184):
> > 
> > rehash: warning: skipping ca-certificates.crt,it does not contain 
> > exactly one certificate or CRL
> > 
> Ah, that makes sense.  Annoying...
> 
> Kurt/Sebastian, do you think there's a chance openssl rehash could grow
> some sort of ignore option so update-ca-certificates could ask it to
> skip ca-certificates.crt, to avoid spitting out a warning for it?

As in rehash all files in that directory, excluding a file? I
guess that's an option. I guess it's not an option to move the
file to a different location.


Kurt



Bug#996692: Cargo: New upstream release

2021-10-17 Thread Kurt Roeckx
Source: cargo
Version: 0.47.0-3
Severity: wishlist

Hi,

Can you package a newer version of cargo? The current version
seems to be too old for some things.


Kurt



Bug#996425: hitch: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
Source: hitch
Version: 1.7.1-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
hitch.c: In function init_dh:
hitch.c:318:2: error: PEM_read_bio_DHparams is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  318 |  dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
  |  ^~
In file included from /usr/include/openssl/ui.h:30,
 from /usr/include/openssl/engine.h:30,
 from hitch.c:42:
/usr/include/openssl/pem.h:469:1: note: declared here
  469 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, DHparams, DH)
  | ^~~
hitch.c:327:3: error: DH_free is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  327 |   DH_free(dh);
  |   ^~~
In file included from /usr/include/openssl/dsa.h:51,
 from /usr/include/openssl/x509.h:37,
 from hitch.c:40:
/usr/include/openssl/dh.h:200:28: note: declared here
  200 | OSSL_DEPRECATEDIN_3_0 void DH_free(DH *dh);
  |^~~
[...]

Removing the -Werror will turn those errors in warnings and should
allow building against and using OpenSSL 3.0. The functions are still
available but marked for removal in some future version.


Kurt



Bug#996424: haskell-blogliterately: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
Source: haskell-blogliterately
Version: 0.8.7-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
[12 of 12] Compiling Text.BlogLiterately ( src/Text/BlogLiterately.hs, 
dist-ghc/build/Text/BlogLiterately.p_o )
Preprocessing executable 'BlogLiterately' for BlogLiterately-0.8.7..
Building executable 'BlogLiterately' for BlogLiterately-0.8.7..
[1 of 1] Compiling Main ( main/BlogLiterately.hs, 
dist-ghc/build/BlogLiterately/BlogLiterately-tmp/Main.o )
Linking dist-ghc/build/BlogLiterately/BlogLiterately ...
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsrsaFromPKey1_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsrsaFromPKey_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsdsaFromPKey1_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsdsaFromPKey_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(Session.o):function
 HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziSession_zdwio_info: 
error: undefined reference to 'SSL_get_peer_certificate'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function
 HsOpenSSL_EVP_MD_size: error: undefined reference to 'EVP_MD_size'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function
 HsOpenSSL_EVP_CIPHER_CTX_block_size: error: undefined reference to 
'EVP_CIPHER_CTX_block_size'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function
 HsOpenSSL_EVP_CIPHER_iv_length: error: undefined reference to 
'EVP_CIPHER_iv_length'
collect2: error: ld returned 1 exit status
`x86_64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1


Kurt



Bug#996423: haproxy: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
Source: haproxy
Version: 2.2.17-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
src/ssl_sock.c: In function ‘ctx_set_TLSv13_func’:
src/ssl_sock.c:2178:5: error: missing binary operator before token "1"
 2178 | #if SSL_OP_NO_TLSv1_3
  | ^~~~~


Kurt



Bug#996422: golang-github-mendersoftware-openssl: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
Source: golang-github-mendersoftware-openssl
Version: 1.1.0-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
github.com/mendersoftware/openssl
# github.com/mendersoftware/openssl
src/github.com/mendersoftware/openssl/fips.go:31:7: could not determine kind of 
name for C.FIPS_mode_set
dh_auto_build: error: cd _build && go install -trimpath -v -p 1 
github.com/mendersoftware/openssl github.com/mendersoftware/openssl/utils 
returned exit code 2
make: *** [debian/rules:4: binary] Error 25

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#996421: globus-proxy-utils: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
Source: globus-proxy-utils
Version: 7.2-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
make[4]: Entering directory '/<>/test'
FAIL: grid-proxy-utils-test.pl
FAIL: proxy-order-test.pl
=
   globus_proxy_utils 7.2: test/test-suite.log
=

# TOTAL: 2
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: grid-proxy-utils-test.pl
==

# PATH = 
../programs:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
# X509_CERT_DIR = /<>/test
1..33
ok 1 - create_proxy  
not ok 2 - grid-proxy-info  
#   Failed test 'grid-proxy-info  '
#   at ./grid-proxy-utils-test.pl line 38.
not ok 3 - grid-proxy-info type is RFC 3820 compliant impersonation proxy
#   Failed test 'grid-proxy-info type is RFC 3820 compliant impersonation proxy'
#   at ./grid-proxy-utils-test.pl line 41.
ok 4 - create_proxy -draft 
not ok 5 - grid-proxy-info -draft 
[...]


Kurt



Bug#996420: globus-gssapi-gsi: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
Source: globus-gssapi-gsi
Version: 14.17-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
FAIL: gssapi-thread-test-wrapper


1..1
Segmentation fault
FAIL gssapi-thread-test-wrapper (exit status: 1)

FAIL: import-cred-test.pl
=

1..3

ERROR: GSS Major Status: General failure


ERROR: GSS Minor Status Error Chain:
globus_gsi_gssapi: Unable to read credential for import
globus_gsi_gssapi: Error with GSI credential
globus_credential: Error reading proxy credential: Couldn't read PEM from bio
OpenSSL Error: ../crypto/bio/bio_lib.c:518: in library: BIO routines, function 
BIO_ctrl: unsupported method

not ok 1 - test_import_data
#   Failed test 'test_import_data'
#   at ./import-cred-test.pl line 23.

ERROR: GSS Major Status: General failure

[...]


Kurt



Bug#996275: [Pkg-erlang-devel] Bug#996275: coturn: FTBFS with OpenSSL 3.0

2021-10-13 Thread Kurt Roeckx
On Wed, Oct 13, 2021 at 07:43:26AM +0300, Sergei Golovan wrote:
> 
> This is a known issue, see https://github.com/erlang/otp/issues/4577
> and I'm afraid the fix will come only with the new major Erlang 25.
> It's expected to be released in May 2022.

As far as I know, there are 2 issues:
- The call to FIPS_mode no longer exists. This has probably never
  worked in Debian in the first place, so a possible solution for
  that would be just to remove the call.
- Warnings about deprecated functions. Those are just warnings,
  the functions aren't going to go away soon, but will at some
  point in the future. So this is something we should be able
  to ignore until upstream fixes it.

I currently don't know when the transition will start.


Kurt



Bug#996288: globus-gsi-openssl-error: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: globus-gsi-openssl-error
Version: 4.3-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
not ok 4 - Match reference output
#   Failed test 'Match reference output'
#   at ./globus-openssl-error-test.pl line 38.
# Looks like you failed 1 test of 4.
FAIL globus-openssl-error-test.pl (exit status: 1)


Kurt



Bug#996287: git-crypt: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: git-crypt
Version: 0.6.0-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
crypto-openssl-10.cpp: In constructor 
Aes_ecb_encryptor::Aes_ecb_encryptor(const unsigned char*):
crypto-openssl-10.cpp:59:60: warning: int AES_set_encrypt_key(const unsigned 
char*, int, AES_KEY*) is deprecated: Since OpenSSL 3.0 
[-Wdeprecated-declarations]
   59 |  if (AES_set_encrypt_key(raw_key, KEY_LEN * 8, &(impl->key)) != 0) {
  |^
In file included from crypto-openssl-10.cpp:38:
/usr/include/openssl/aes.h:51:5: note: declared here
   51 | int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
  | ^~~
crypto-openssl-10.cpp: In member function void Aes_ecb_encryptor::encrypt(const 
unsigned char*, unsigned char*):
crypto-openssl-10.cpp:74:41: warning: void AES_encrypt(const unsigned char*, 
unsigned char*, const AES_KEY*) is deprecated: Since OpenSSL 3.0 
[-Wdeprecated-declarations]
   74 |  AES_encrypt(plain, cipher, &(impl->key));
  | ^
In file included from crypto-openssl-10.cpp:38:
/usr/include/openssl/aes.h:57:6: note: declared here
   57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
  |  ^~~
crypto-openssl-10.cpp: At global scope:
crypto-openssl-10.cpp:78:11: error: field ctx has incomplete type HMAC_CTX {aka 
hmac_ctx_st}
   78 |  HMAC_CTX ctx;
  |   ^~~
In file included from /usr/include/openssl/evp.h:26,
 from /usr/include/openssl/hmac.h:21,
 from crypto-openssl-10.cpp:40:
/usr/include/openssl/types.h:132:16: note: forward declaration of HMAC_CTX {aka 
struct hmac_ctx_st}
  132 | typedef struct hmac_ctx_st HMAC_CTX;
  |^~~
crypto-openssl-10.cpp: In destructor Hmac_sha1_state::~Hmac_sha1_state():
crypto-openssl-10.cpp:92:2: error: HMAC_cleanup was not declared in this scope; 
did you mean EVP_cleanup?
   92 |  HMAC_cleanup(&(impl->ctx));
  |  ^~~~
  |  EVP_cleanup
make[1]: *** [: crypto-openssl-10.o] Error 1


Kurt



Bug#996286: freerdp2: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: freerdp2
Version: 2.3.0+dfsg1-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
/<>/winpr/libwinpr/utils/ssl.c
/<>/winpr/libwinpr/utils/ssl.c: In function 
‘winpr_enable_fips’:
/<>/winpr/libwinpr/utils/ssl.c:247:7: warning: implicit 
declaration of function ‘FIPS_mode’ [-Wimplicit-function-declaration]
  247 |   if (FIPS_mode() != 1)
  |   ^
/<>/winpr/libwinpr/utils/ssl.c:249:8: warning: implicit 
declaration of function ‘FIPS_mode_set’ [-Wimplicit-function-declaration]
  249 |if (FIPS_mode_set(1))
  |^
[...]
/usr/bin/ld: ../../libwinpr/libwinpr2.so.2.3.0: undefined reference to 
`FIPS_mode_set'
/usr/bin/ld: ../../libwinpr/libwinpr2.so.2.3.0: undefined reference to 
`FIPS_mode'
collect2: error: ld returned 1 exit status

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#996285: freelan: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: freelan
Version: 2.2-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
build/release/libs/cryptoplus/include/cryptoplus/bio/../cipher/../error/error.hpp:
 In function ‘int 
cryptoplus::error::get_function_error(cryptoplus::error::error_type)’:
build/release/libs/cryptoplus/include/cryptoplus/bio/../cipher/../error/error.hpp:243:11:
 error: ‘ERR_GET_FUNC’ was not declared in this scope; did you mean 
‘ERR_GET_LIB’?
  243 |return ERR_GET_FUNC(err.error_code);
  |   ^~~~
  |   ERR_GET_LIB

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#996275: coturn: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: erlang
Version: 24.0.6+dfsg-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
pkey.c:76:14: error: implicit declaration of function FIPS_mode 
[-Werror=implicit-function-declaration]
   76 | if (!FIPS_mode()) return PKEY_OK;
  |  ^

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

There are also various warnings about deprecated functions which
you might want to look at.


Kurt



Bug#996276: foxeye: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: foxeye_0.12.1-3
Version: 0.12.1-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
openssl.c:450:5: warning: implicit declaration of function FIPS_mode_set 
[-Wimplicit-function-declaration]
  450 | FIPS_mode_set(0);
  | ^
[...]
/usr/bin/ld: openssl.o: in function `module_signal':
./modules/ssl/openssl.c:450: undefined reference to `FIPS_mode_set'

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#996274: erlang-p1-tls: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: erlang-p1-tls
Version: 1.1.13-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0


Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
 EUnit 
module 'fast_tls'
  fast_tls: transmission_with_client_certificate_test...*failed*
in function fast_tls:transmission_test_with_opts/2 (fast_tls.erl, line 492)
in call from eunit_test:'-mf_wrapper/2-fun-0-'/2 (eunit_test.erl, line 273)
in call from eunit_test:run_testfun/1 (eunit_test.erl, line 71)
in call from eunit_proc:run_test/1 (eunit_proc.erl, line 522)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 347)
in call from eunit_proc:handle_test/2 (eunit_proc.erl, line 505)
in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 447)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 337)
**error:{assertEqual,[{module,fast_tls},
  {line,492},
  {expression,"Msg"},
  {expected,<<"abcdefghi">>},
  {value,{error,<<"SSL_do_handshake failed: error:1"...>>,<<>>}}]}
  output:<<"">>

  fast_tls: transmission_without_client_certificate_test...[0.409 s] ok
  fast_tls: transmission_without_server_cert_fails_test...ok
  fast_tls: not_compatible_protocol_options_test...*failed*
in function fast_tls:not_compatible_protocol_options_test/0 (fast_tls.erl, line 
510)
in call from eunit_test:'-mf_wrapper/2-fun-0-'/2 (eunit_test.erl, line 273)
in call from eunit_test:run_testfun/1 (eunit_test.erl, line 71)
in call from eunit_proc:run_test/1 (eunit_proc.erl, line 522)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 347)
in call from eunit_proc:handle_test/2 (eunit_proc.erl, line 505)
in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 447)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 337)
**error:{assertMatch,[{module,fast_tls},
  {line,510},
  {expression,"Res"},
  {pattern,"{ badmatch , { error , _ } }"},
  {value,ok}]}
  output:<<"">>

  [done in 1.244 s]


Kurt



Bug#996273: dovecot: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: dovecot
Version: 2.3.16+dfsg1-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
test_get_info_pw_encrypted ... : ok
test-crypto.c:827: Assert failed: ret == TRUE
Panic: file dcrypt-openssl.c: line 2642 (dcrypt_openssl_private_to_public_key): 
assertion failed: (priv_key != NULL && pub_key_r != NULL)
Error: Raw backtrace: ./test-crypto(+0x53775) [0x55cb6b24d775] -> 
./test-crypto(backtrace_get+0x1c) [0x55cb6b24d8ec] -> ./test-crypto(+0x2b23b) 
[0x55cb6b22523b] -> ./test-crypto(+0x2b271) [0x55cb6b225271] -> 
./test-crypto(+0x14d1a) [0x55cb6b20ed1a] -> .libs/libdcrypt_openssl.so(+0x618d) 
[0x7f5058c9018d] -> ./test-crypto(+0x253fa) [0x55cb6b21f3fa] -> 
./test-crypto(+0x2a63d) [0x55cb6b22463d] -> ./test-crypto(test_run+0x5f) 
[0x55cb6b2246df] -> ./test-crypto(main+0x4c) [0x55cb6b2136dc] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f5058cc9e4a] -> 
./test-crypto(_start+0x2a) [0x55cb6b21381a]
/bin/bash: line 1: 161575 Aborted ./$bin


Kurt



Bug#996272: crda: FTBFS with OpenSSL 3.0

2021-10-12 Thread Kurt Roeckx
Source: crda
Version: 4.14+git20191112.9856751-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
reglib.c: In function reglib_verify_db_signature:
reglib.c:122:5: error: PEM_read_RSA_PUBKEY is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  122 | rsa = PEM_read_RSA_PUBKEY(keyfile,
  | ^~~
In file included from reglib.c:24:
/usr/include/openssl/pem.h:449:1: note: declared here
  449 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, RSA_PUBKEY, RSA)
  | ^~~
reglib.c:125:6: error: RSA_verify is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  125 |  ok = RSA_verify(NID_sha1, hash, SHA_DIGEST_LENGTH,
  |  ^~
In file included from reglib.c:22:
/usr/include/openssl/rsa.h:351:27: note: declared here
  351 | OSSL_DEPRECATEDIN_3_0 int RSA_verify(int type, const unsigned char *m,
  |   ^~
reglib.c:127:5: error: RSA_free is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  127 | RSA_free(rsa);
  | ^~~~
In file included from reglib.c:22:
/usr/include/openssl/rsa.h:293:28: note: declared here
  293 | OSSL_DEPRECATEDIN_3_0 void RSA_free(RSA *r);
  |^~~~
cc1: all warnings being treated as errors

The short term solution is to drop the -Werror. Longer term the
functions need to get replaced with non-deprecated versions.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995660: clickhouse: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
11: + openssl dhparam -out /tmp/clickhouse.test..wbgfY/etc/dhparam.pem 256
11: Generating DH parameters, 256 bit long safe prime
11: dhparam: Generating DH key parameters failed
11: 40A7B5ED9C7F:error:0280007E:Diffie-Hellman 
routines:dh_builtin_genparams:modulus too small:../crypto/dh/dh_gen.c:168:
11/11 Test #11: with_server ***Failed0.06 sec

The minimum size that it now allows you to generate is 512 bit,
which might be good for a test suite, but is too short for real
parameters.


Kurt



Bug#995659: coturn: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: coturn
Version: 4.5.2-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
src/client/ns_turn_msg.c: In function stun_produce_integrity_key_str:
src/client/ns_turn_msg.c:260:7: warning: implicit declaration of function 
FIPS_mode [-Wimplicit-function-declaration]
  260 |   if (FIPS_mode()) {
  |   ^
[...]
/usr/bin/ld: lib/libturnclient.a(ns_turn_msg.o): in function 
`stun_produce_integrity_key_str':
./src/client/ns_turn_msg.c:260: undefined reference to `FIPS_mode'
collect2: error: ld returned 1 exit status

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995657: clevis: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: clevis
Version: 18-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
In file included from ../src/pins/sss/sss.c:41:
../src/pins/sss/sss.c: In function ‘sss_point’:
../src/pins/sss/sss.c:217:9: error: void value not ignored as it ought to be
  217 | if (BN_zero(yy) <= 0)
  | ^~~
../src/pins/sss/sss.c: In function ‘sss_recover’:
../src/pins/sss/sss.c:275:9: error: void value not ignored as it ought to be
  275 | if (BN_zero(k) <= 0)
  | ^~~
../src/pins/sss/sss.c:306:17: error: void value not ignored as it ought to be
  306 | if (BN_zero(tmp) <= 0)
  | ^~~
ninja: build stopped: subcommand failed.

The manpage says:
In OpenSSL 0.9.8, BN_zero() was changed to not return a value; previous 
versions returned an int.


Kurt



Bug#995644: lebiniou: Fails to upgrade: trying to overwrite '/usr/share/lebiniou/etc/schemes.json'

2021-10-03 Thread Kurt Roeckx
Package: lbeibiou
Version: 3.61.2-1
Severity: serious

Hi,

During an upgrade, I get the following:
dpkg: considering deconfiguration of lebiniou-data, which would be broken by 
installation of lebiniou ...
dpkg: yes, will deconfigure lebiniou-data (broken by lebiniou)
Preparing to unpack .../110-lebiniou_3.61.2-1+b1_amd64.deb ...
De-configuring lebiniou-data (3.54.1-1) ...
Unpacking lebiniou (3.61.2-1+b1) over (3.54.1-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-dU3HYR/110-lebiniou_3.61.2-1+b1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/lebiniou/etc/schemes.json', which is also in 
package lebiniou-data 3.54.1-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
dpkg: considering deconfiguration of lebiniou, which would be broken by 
installation of lebiniou-data ...
dpkg: yes, will deconfigure lebiniou (broken by lebiniou-data)
Preparing to unpack .../111-lebiniou-data_3.61.1-1_all.deb ...
De-configuring lebiniou (3.54.1-1) ...
Unpacking lebiniou-data (3.61.1-1) over (3.54.1-1) ...


This looks like it's missing a Replaces. A Breaks is not enough.

Trying again, it works because lebiniou-data got updated.

I'm not sure why the file moved from lebiniou-data to lebiniou.


Kurt



Bug#995643: cjose: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: cjose
Version: 0.6.1+dfsg1-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
jwk.c: In function _cjose_jwk_rsa_get:
jwk.c:58:5: error: RSA_get0_key is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
   58 | RSA_get0_key(rsa, (const BIGNUM **)rsa_n, (const BIGNUM **)rsa_e, 
(const BIGNUM **)rsa_d);
  | ^~~~
In file included from ../include/cjose/util.h:21,
 from jwk.c:12:
/usr/include/openssl/rsa.h:217:28: note: declared here
  217 | OSSL_DEPRECATEDIN_3_0 void RSA_get0_key(const RSA *r,
  |^~~~
jwk.c: In function _cjose_jwk_rsa_set:
jwk.c:82:5: error: RSA_set0_key is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
   82 | return RSA_set0_key(rsa, rsa_n, rsa_e, rsa_d) == 1;
  | ^~
[...]

The short term solution is to drop the -Werror. Longer term the
functions need to get replaced with non-deprecated versions.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995642: cfengine3: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: cfengine3
Version: 3.15.2-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
In file included from hash.c:33:
./hash.h:64:28: error: unknown type name RSA
   64 | Hash *HashNewFromKey(const RSA *rsa, HashMethod method);
  |^~~
./hash.h:163:23: error: unknown type name RSA
  163 | void HashPubKey(const RSA *key, unsigned char digest[EVP_MAX_MD_SIZE + 
1], HashMethod type);
  |   ^~~
hash.c:214:28: error: unknown type name RSA
  214 | Hash *HashNewFromKey(const RSA *rsa, HashMethod method)
  |^~~
hash.c: In function HashNewFromKey:
hash.c:226:5: error: implicit declaration of function RSA_get0_key 
[-Werror=implicit-function-declaration]
  226 | RSA_get0_key(rsa, , , NULL);
  | ^~~~
hash.c: At top level:
hash.c:531:11: error: unknown type name RSA
  531 | const RSA *const key,
  |   ^~~
cc1: some warnings being treated as errors

I'm not sure why you don't get the RSA type, it should still
exists. However, those functions have been deprecated, so you'll
need to replace them at some point.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995641: certmonger: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: certmonger
Version: 0.79.13-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
../../src/util-o.c: In function util_EVP_PKEY_id:
../../src/util-o.c:333:13: error: invalid use of incomplete typedef EVP_PKEY 
{aka const struct evp_pkey_st}
  333 |  return pkey->type;
  | ^~

This looks like it's code for compatibility with OpenSSL older
than 1.1.0 that's being build when building against 3.0.

There are also other errors and warings related to OpenSSL 3.0.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995640: boxbackup: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: boxbackup
Version: 0.13~~git20200326.g8e8b63c-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
NOTICE:  Running test bbackupd in debug mode...
ERROR:   SSL or crypto error: initialising cipher: error:0308010C:digital 
envelope routines::unsupported
WARNING: Exception thrown: CipherException(EVPInitFailure) (Failed to 
initialise Blowfish56-CBC: error:0308010C:digital envelope 
routines::unsupported) at lib/crypto/CipherContext.cpp:124
FAILED: Exception caught: EVPInitFailure: Failed to initialise Blowfish56-CBC: 
error:0308010C:digital envelope routines::unsupported
[...]

Some ciphers have been moved to the legacy provider and are
no longer available by default.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995639: botan: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: botan
Version: 2.18.1+dfsg-3
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
Thread_Pool ran 100 tests all ok
tls:
3DES ECDH ran 2 tests 2 FAILED
Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
Failure 2: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
3DES RSA ran 2 tests 2 FAILED
Failure 1: EVP_EncryptInit_ex failed: error:0386:digital envelope 
routines::initialization error
Failure 2: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
AES-128 DH ran 1 tests 1 FAILED
Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
AES-128 DHE_PSK ran 1 tests 1 FAILED
Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
AES-128 ECDH ran 2 tests 2 FAILED
Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
Failure 2: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
AES-128 ECDHE_PSK ran 1 tests 1 FAILED
Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope 
routines::unsupported
[...]

It's unclear why they would be unsupported.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995637: boinc: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: boinc
Version: 7.16.17+dfsg-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
In file included from /usr/include/openssl/x509.h:29,
 from /usr/include/openssl/ssl.h:31,
 from crypt.cpp:36:
/usr/include/openssl/evp.h:1346:22: note: declared here
 1346 | const struct rsa_st *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey);
  |  ^
crypt.cpp:676:32: error: invalid conversion from const rsa_st* to RSA* {aka 
rsa_st*} [-fpermissive]
  676 | rsa = EVP_PKEY_get0_RSA(pubKey);
  |   ~^~~~
  ||
  |const rsa_st*


The return value of EVP_PKEY_get0_RSA() has been made const in
OpenSSL 3.0, so you need to change "rsa" to "const RSA *".

Note that there are also various other warnings about
deprecated functions. For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995636: transition: openssl

2021-10-03 Thread Kurt Roeckx
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

We would like to transition to OpenSSL 3.0.0. It's currently in
experimental. It has an soname change, so the binary packages got
renamed and binNMUs will be required.

We did a rebuild of packages and currently have 105 packages
that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started
filing bugs for that:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0


Kurt



Bug#995635: azure-uamqp-python: FTBFS with OpenSSL 3.0

2021-10-03 Thread Kurt Roeckx
Source: azure-uamqp-python
Version: 1.4.1-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with errors
like:
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:
 In function load_certificate_chain:
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:81:28:
 error: invalid use of incomplete typedef SSL_CTX {aka struct ssl_ctx_st}
   81 | if (ssl_ctx->extra_certs != NULL)
  |^~
In file included from /usr/include/openssl/ssl.h:31,
 from 
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/inc/azure_c_shared_utility/x509_openssl.h:7,
 from 
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:4:
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:83:45:
 error: invalid use of incomplete typedef SSL_CTX {aka struct ssl_ctx_st}
   83 | sk_X509_pop_free(ssl_ctx->extra_certs, X509_free);
  | ^~
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:84:28:
 error: invalid use of incomplete typedef SSL_CTX {aka struct ssl_ctx_st}
   84 | ssl_ctx->extra_certs = NULL;
  |^~
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:
 In function load_key_RSA:
/<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:140:5:
 error: EVP_PKEY_get1_RSA is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  140 | RSA* privatekey = EVP_PKEY_get1_RSA(evp_key);
  | ^~~

At least some of those errors are caused by using deprecated
function in combination with -Werror. I'm not sure why you
get the other errors, since that's not changed between 1.1
and 3.0.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt



Bug#995634: autobahn-cpp: FTBFS with OpenSSL 3.0: Uses -Werror and deprecated functions

2021-10-03 Thread Kurt Roeckx
Source: autobahn-cpp
Version: 17.5.1+git7cc5d37-2.1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Your package is building using -Werror and is using functions that
have been deprecated in OpenSSL 3.0. The log contains errors like:
In file included from /<>/autobahn/wamp_session.ipp:48,
 from /<>/autobahn/wamp_session.hpp:403,
 from /<>/autobahn/autobahn.hpp:42,
 from /<>/examples/callee.cpp:33:
/<>/autobahn/wamp_auth_utils.hpp: In function std::string 
compute_wcs(const string&, const string&):
/<>/autobahn/wamp_auth_utils.hpp:169:35: error: HMAC_CTX* 
HMAC_CTX_new() is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  169 | HMAC_CTX *hmac = HMAC_CTX_new();
  |   ^

The short time solution is to remove the -Werror, which will turn
it into a warning.

For a longer term solution, see
https://www.openssl.org/docs/man3.0/man7/migration_guide.html#Deprecated-low-level-MAC-functions


Kurt



Bug#994081: libdvd-pkg: 1.4.3-1-1 Upgrade Results in 'apt-get check' Failure

2021-09-11 Thread Kurt Meyer
Package: libdvd-pkg
Version: 1.4.3-1-1
Severity: normal

Dear Maintainer,

* What led up to the situation?

I performed an upgrade (apt upgrade) with the following manually held back 
packages due to bug reports: libc6, libc6:i386, libc6-dev, libxml2, 
libxml2:i386, and lintian.

Following is a complete list of held back packages resulting from the manually 
held back packages:



The following packages have been kept back:
  cpp-9 gcc-11-base gcc-11-base:i386 gcc-9 gcc-9-base gcc-9-base:i386 libasan5
  libasan6 libatomic1 libatomic1:i386 libc-bin libc-dev-bin libc6 libc6:i386
  libc6-dev libcc1-0 libgcc-9-dev libgcc-s1 libgcc-s1:i386 libgfortran5 libgomp1
  libgomp1:i386 libitm1 liblsan0 libquadmath0 libstdc++6 libstdc++6:i386 
libtsan0
  libubsan1 libuno-sal3 libxml2 libxml2:i386 lintian locales mpv vorbis-tools



* What exactly did you do (or not do) that was effective (or ineffective)?

n/a

* What was the outcome of this action?



libdvd-pkg: Downloading orig source...
I: libdvdcss_1.4.3
/usr/bin/wget --tries=3 --timeout=40 --read-timeout=40 --continue -O 
libdvdcss_1.4.3.orig.tar.bz2 \
  
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2 \
|| /usr/bin/uscan --noconf --verbose --rename 
--destdir=/usr/src/libdvd-pkg --check-dirname-level=0 --force-download 
--download-current-version /usr/share/libdvd-pkg/debian
--2021-09-11 02:13:51--  
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2
Resolving download.videolan.org (download.videolan.org)... 213.36.253.2, 
2a01:e0d:1:3:58bf:fa02:c0de:5
Connecting to download.videolan.org 
(download.videolan.org)|213.36.253.2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 388404 (379K) [application/octet-stream]
Saving to: ‘libdvdcss_1.4.3.orig.tar.bz2’

libdvdcss_1.4.3.orig 100%[==>] 379.30K  1.35MB/sin 0.3s 
  

2021-09-11 02:13:52 (1.35 MB/s) - ‘libdvdcss_1.4.3.orig.tar.bz2’ saved 
[388404/388404]

libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...



* What outcome did you expect instead?

A normal upgrade.


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

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

Versions of packages libdvd-pkg depends on:
ii  build-essential   12.9
ii  debconf [debconf-2.0] 1.5.77
ii  debhelper [debhelper-compat]  13.5.1
ii  devscripts2.21.4
ii  wget  1.21-1+b1

Versions of packages libdvd-pkg recommends:
ii  libcap2-bin  1:2.44-1

libdvd-pkg suggests no packages.

-- debconf information:
  libdvd-pkg/post-invoke_hook-remove: false
* libdvd-pkg/build: true
* libdvd-pkg/post-invoke_hook-install: true
  libdvd-pkg/title_b-i:
* libdvd-pkg/first-install:
  libdvd-pkg/upgrade:
  libdvd-pkg/title_u:


  1   2   3   4   5   6   7   8   9   10   >