Bug#1022754: src:jenkins-debian-glue: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: jenkins-debian-glue
Version: 0.21.0
Severity: serious
Control: close -1 0.21.1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:jenkins-debian-glue has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=jenkins-debian-glue



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022753: speedtest-cli: the name conflicts with the official Ookla CLI tool, consider adding 'Conflicts'

[Alex Volkov]

Package: speedtest-cli
Severity: wishlist

Dear Maintainer,

as /usr/bin/speedtest conflicts with the official tool (in their .deb 
packaging), I'd propose
adding the corresponding "Conflicts: speedtest" field into debian/control. 
(Renaming it
as not to give an impression it relates to Ookla would be even better, but it's 
up to upstream.)

-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (991, 'stable-security'), (991, 'stable'), (99, 'testing'), (90, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.11-bootes1-p-1000 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages speedtest-cli depends on:
ii  ca-certificates20210119
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4

speedtest-cli recommends no packages.

speedtest-cli suggests no packages.

Bug#1022752: projectm FTCBFS: broken, outdated, embedded copy of AX_HAVE_QT

[Helmut Grohne]

Source: projectm
Version: 3.1.12-2.1
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

projectm fails to cross build from source, because it uses an broken,
outdated, embedded copy of AX_HAVEQT that is still affected by #965273
while this has been fixed in autoconf-archive already.

Please delete this copy from m4/autoconf-archive/ax_have_qt.m4 and use
the one from autoconf-archive instead. Failing that, please update your
copy and register it with the security tracker. See
https://wiki.debian.org/EmbeddedCopies for how to register embedded
copies.

Beyond this, projectm also hard codes the build architecture pkg-config
in one occasion. I'm attaching a patch for this latter issue for your
convenience.

Helmut
--- projectm-3.1.12.orig/configure.ac
+++ projectm-3.1.12/configure.ac
@@ -165,9 +165,10 @@
 AC_ARG_ENABLE([qt], AS_HELP_STRING([--enable-qt], [Enable Qt: needed for pulseaudio and jack GUIs]), [], [enable_qt=check])
 AS_IF([test "$enable_qt" != "no"],
   [
+   AC_REQUIRE([PKG_PROG_PKG_CONFIG])
 case $host_os in
   linux*)
-PATH="$PATH:`pkg-config --variable=host_bins Qt5Core`"
+PATH="$PATH:`$PKG_CONFIG --variable=host_bins Qt5Core`"
   ;;
 esac
 AX_HAVE_QT  # m4/qt.m4

Bug#1022751: debsecan: report: split obsolete packages out of "Available security updates" section

[Paul Wise]

Package: debsecan
Version: 0.4.20.1
Severity: wishlist

Please split the obsolete packages out of the currently existing
"Available security updates" section and move them into a new
"Obsolete packages" section after all sections but just before the 
"Vulnerabilities without updates" section at the end.

This would make the debsecan daily report much more usable.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages debsecan depends on:
ii  ca-certificates20211016
ii  debconf [debconf-2.0]  1.5.79
ii  python33.10.6-1
ii  python3-apt2.3.0+nmu1

Versions of packages debsecan recommends:
ii  cron [cron-daemon] 3.0pl1-150+b1
ii  exim4-daemon-light [mail-transport-agent]  4.96-6

debsecan suggests no packages.

-- debconf information:
* debsecan/mailto: root
* debsecan/suite: sid
* debsecan/report: true
* debsecan/source:

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1022544: linux-image-6.0.0-2-amd64: No more sound after upgrade to 6.0.0-2

[Ronny Rentner]

Package: src:linux
Version: 6.0.3-1
Followup-For: Bug #1022544
X-Debbugs-Cc: debian-b...@ronny-rentner.de

Dear Maintainer,

I have the same problem on a Lenovo X1 gen 10: No sound after upgrade to 6.0.x

With kernel 5.18 it still works.

Thanks in advance!

Ronny


-- Package-specific info:
** Version:
Linux version 6.0.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-7) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.3-1 (2022-10-21)

** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-2-amd64 root=/dev/mapper/yuna--main--vg-root ro quiet 
splash i915.enable_execlists=0 i915.enable_psr=0

** Tainted: UWOE (12864)
 * taint requested by userspace application
 * kernel issued warning
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   12.071924] iwlwifi :00:14.3: api flags index 2 larger than supported by 
driver
[   12.071940] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
[   12.072279] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   12.072283] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   12.072292] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   12.072295] iwlwifi :00:14.3: loaded firmware version 72.9557cb27.0 
so-a0-gf-a0-72.ucode op_mode iwlmvm
[   12.076835] i801_smbus :00:1f.4: enabling device ( -> 0003)
[   12.077014] i801_smbus :00:1f.4: SPD Write Disable is set
[   12.077083] i801_smbus :00:1f.4: SMBus using PCI interrupt
[   12.079392] intel-lpss :00:19.0: enabling device ( -> 0002)
[   12.079942] typec port0: bound usb1-port1 (ops connector_ops [usbcore])
[   12.079966] typec port0: bound usb4-port1 (ops connector_ops [usbcore])
[   12.079978] idma64 idma64.0: Found Intel integrated DMA 64-bit
[   12.079979] i2c i2c-14: 8/8 memory slots populated (from DMI)
[   12.079982] i2c i2c-14: Systems with more than 4 memory slots not supported 
yet, not instantiating SPD
[   12.087249] snd_hda_intel :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[   12.087424] snd_hda_intel :00:1f.3: Digital mics found on Skylake+ 
platform, using SOF driver
[   12.111409] usb 1-6: new full-speed USB device number 2 using xhci_hcd
[   12.268801] usb 1-6: New USB device found, idVendor=06cb, idProduct=00fc, 
bcdDevice= 0.00
[   12.268806] usb 1-6: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[   12.268808] usb 1-6: SerialNumber: 8ee93b04a845
[   12.278285] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, 
REV=0x370
[   12.278332] thermal thermal_zone8: failed to read out thermal zone (-61)
[   12.358342] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[   12.359209] sof-audio-pci-intel-tgl :00:1f.3: Digital mics found on 
Skylake+ platform, using SOF driver
[   12.359418] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040380
[   12.359763] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   12.367298] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode
[   12.407361] usb 1-8: new full-speed USB device number 3 using xhci_hcd
[   12.453320] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-so-a0-gf-a0.pnvm
[   12.453343] iwlwifi :00:14.3: loaded PNVM version 881c99e1
[   12.460616] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 5
[   12.460619] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[   12.460621] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT 
tables: 4
[   12.462584] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
firmware intel/sof/sof-adl.ri
[   12.462590] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
2:2:0-57864
[   12.462591] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1 
Kernel ABI 3:23:0
[   12.462594] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header 
type 3 size 0x30
[   12.468011] iwlwifi :00:14.3: Detected RF GF, rfid=0x2010d000
[   12.537217] iwlwifi :00:14.3: base HW address: 8c:f8:c5:ac:f2:5b
[   12.559336] usb 1-8: New USB device found, idVendor=8086, idProduct=0b63, 
bcdDevice=10.02
[   12.559340] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   12.559342] usb 1-8: Product: USB Bridge
[   12.559343] usb 1-8: Manufacturer: MCHP
[   12.561261] typec port1: bound usb1-port3 (ops connector_ops [usbcore])
[   12.561283] typec port1: bound usb4-port3 (ops connector_ops [usbcore])
[   12.563118] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
2:2:0-57864
[   12.563121] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1 
Kernel ABI 3:23:0
[   12.687511] usb 1-10: new full-speed USB device number 4 using xhci_hcd
[   12.850549] usb 1-10: New USB device 

Bug#1022750: linux-image-6.0.0-2-amd64: Random kernel crashes with all kernel versions > 5.18

[Ronny Rentner]

Package: src:linux
Version: 6.0.3-1
Severity: important
X-Debbugs-Cc: debian-b...@ronny-rentner.de

Dear Maintainer,

I am running a Lenovo Thinkpad X1 Gen 10 (2022) model and since I've upgraded
to any kernel >5.18, so including 5.19, 6.0.0 and 6.0.2 I get random crashes,
as it seems due to the i915 graphics kernel driver module.

In 50 % of the cases the system will not boot at all, in other cases it shows
many GPU hangs when using Gnome. I've attached a log from a faulty boot where I
didn't reach the GDM login screen. In such case, after entering my harddrive
encryption password, the screen stays dark and nothing happens anymore until I
hard power off the computer.

Thanks in advance!

Ronny


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 21CBCTO1WW
product_version: ThinkPad X1 Carbon Gen 10
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N3AET66W (1.31 )
board_vendor: LENOVO
board_name: 21CBCTO1WW
board_version: Not Defined

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4621] (rev 02)
Subsystem: Lenovo Device [17aa:22e7]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P 
Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Alder Lake-P Integrated Graphics Controller 
[17aa:22e7]
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: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Alder Lake 
Innovation Platform Framework Processor Participant [8086:461d] (rev 02)
Subsystem: Lenovo Alder Lake Innovation Platform Framework Processor 
Participant [17aa:22e7]
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: proc_thermal_pci
Kernel modules: processor_thermal_device_pci

00:05.0 Multimedia controller [0480]: Intel Corporation Device [8086:465d] (rev 
02)
Subsystem: Lenovo Device [17aa:22e7]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:06.0 PCI bridge [0604]: Intel Corporation 12th Gen Core Processor PCI 
Express x4 Controller #0 [8086:464d] (rev 02) (prog-if 00 [Normal decode])
Subsystem: Lenovo 12th Gen Core Processor PCI Express x4 Controller 
[17aa:22e7]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:07.0 PCI bridge [0604]: Intel Corporation Alder Lake-P Thunderbolt 4 PCI 
Express Root Port #0 [8086:466e] (rev 02) (prog-if 00 [Normal decode])
Subsystem: Lenovo Alder Lake-P Thunderbolt 4 PCI Express Root Port 
[17aa:22e7]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:07.2 PCI bridge [0604]: Intel Corporation Alder Lake-P Thunderbolt 4 PCI 
Express Root Port #2 [8086:462f] (rev 02) (prog-if 00 [Normal decode])
Subsystem: Lenovo Alder Lake-P Thunderbolt 4 PCI Express Root Port 
[17aa:22e7]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 System peripheral [0880]: Intel Corporation 12th Gen Core Processor 
Gaussian & Neural Accelerator [8086:464f] (rev 02)
Subsystem: Lenovo 12th Gen Core Processor Gaussian & Neural Accelerator 
[17aa:22e7]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:0a.0 Signal processing controller [1180]: Intel Corporation Platform 
Monitoring Technology [8086:467d] (rev 

Bug#1022748: libqt5gui5: hide() + show() + hide() on a dialog frame hides it forever under X

[Alexander Kernozhitsky]

After some testing, I determined that the bug is not present in 5.15.5+dfsg-3 
but is present in 5.15.6+dfsg-1.

-- 
Alexander Kernozhitsky

Bug#1022749: python3.10: python 3.10 incompatible with setuptools>=60.0.0

[Jeff Epler]

Package: python3.10
Severity: normal
X-Debbugs-Cc: jep...@gmail.com

Dear Maintainer,

Hi!

Apologies to bringing this to your attention as a bystander, but I've become
aware
of an incompatibility between setuptools >= 60.0.0 and debian's python package.

I'm not actually using an affected version of Debian, but this has repeatedly
affected people "on the internet" as well as people I've helped as part of my
work with Adafruit.

Some people responding on github about the issue have pointed a virtual finger
at Debian, but as far as I can tell they have not filed a debian bug so the
Debian maintainers may not be aware of the issue.

Here's how the bug can be reproduced in Debian. I ran these lines in a
throwaway environment with `docker run -it debian:testing`:

apt-get -qq update && apt-get -qq install python3 python3-pip; pip install -U
virtualenv setuptools; virtualenv venv; ls -l venv/bin/python

This fails, because files were created under venv/local/bin instead.

Here's the "best" github issue about the problem that I've encountered,
including a project member's statement about their view of how Debian could
resolve the problem:
https://github.com/pypa/setuptools/issues/3278#issuecomment-1118317549



[note: the below information pertains to my development machine, I produced
the problem above in the `debian:testing` docker image:

```
REPOSITORY   TAG   IMAGE ID   CREATED SIZE
debian   testing   500fdde3aee4   About an hour ago   118MB
```

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

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

Versions of packages python3.10 depends on:
ii  libc62.31-13+deb11u4
ii  libgcc-s110.2.1-6
ii  libpython3.9 3.9.2-1
pn  libqgis-core3.10.14  
ii  libqt5core5a 5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

python3.10 recommends no packages.

Bug#1022748: libqt5gui5: hide() + show() + hide() on a dialog frame hides it forever under X

[Alexander Kernozhitsky]

Package: libqt5gui5
Version: 5.15.6+dfsg-2
Severity: important
X-Debbugs-Cc: sh200...@mail.ru

Control: notfound -1 5.15.4+dfsg-5
Control: found -1 5.15.6+dfsg-2

Attaching the example project. There are two buttons that preform some actions
with the second window: Show does show(), and Hide does hide() + show() +
hide().

If you compile the project and first press Hide, then press Show, then the
second window won't be shown again.

The expected result is that the second window will reappear after pressing
Show.

This is a regression in 5.15.6+dfsg-2 since 5.15.4+dfsg-5 works just fine in
this case.

The bug is only reproducible under X, and Wayland is not affected.

Currently, this bug breaks code completion in ktexteditor and its dependencies
(Kate, KDevelop etc.)


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

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

Versions of packages libqt5gui5 depends on:
ii  fontconfig2.13.1-4.5
ii  libc6 2.35-3
ii  libdrm2   2.4.113-2
ii  libegl1   1.5.0-1
ii  libfontconfig12.13.1-4.5
ii  libfreetype6  2.12.1+dfsg-3
ii  libgbm1   22.2.0-1
ii  libgcc-s1 12.2.0-3
ii  libgl11.5.0-1
ii  libglib2.0-0  2.74.0-3
ii  libharfbuzz0b 5.2.0-2
ii  libice6   2:1.0.10-1
ii  libinput101.21.0-1
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libmd4c0  0.4.8-1
ii  libmtdev1 1.1.6-1
ii  libpng16-16   1.6.38-2
ii  libqt5core5a [qtbase-abi-5-15-6]  5.15.6+dfsg-2
ii  libqt5dbus5   5.15.6+dfsg-2
ii  libqt5network55.15.6+dfsg-2
ii  libsm62:1.2.3-1
ii  libstdc++612.2.0-3
ii  libudev1  251.6-1
ii  libx11-6  2:1.8.1-2
ii  libx11-xcb1   2:1.8.1-2
ii  libxcb-glx0   1.15-1
ii  libxcb-icccm4 0.4.1-1.1
ii  libxcb-image0 0.4.0-2
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.15-1
ii  libxcb-render-util0   0.3.9-1+b1
ii  libxcb-render01.15-1
ii  libxcb-shape0 1.15-1
ii  libxcb-shm0   1.15-1
ii  libxcb-sync1  1.15-1
ii  libxcb-xfixes01.15-1
ii  libxcb-xinerama0  1.15-1
ii  libxcb-xinput01.15-1
ii  libxcb-xkb1   1.15-1
ii  libxcb1   1.15-1
ii  libxkbcommon-x11-01.4.1-1
ii  libxkbcommon0 1.4.1-1
ii  libxrender1   1:0.9.10-1.1
ii  zlib1g1:1.2.11.dfsg-4.1

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.15.6-2
pn  qt5-gtk-platformtheme  

Versions of packages libqt5gui5 suggests:
ii  qt5-image-formats-plugins  5.15.6-2
ii  qtwayland5 5.15.6-2

-- no debconf information


bug.tar.gz
Description: application/gzip

Bug#898972: Changing forks

[Ben Westover]

Control: retitle -1 ITP: prismlauncher -- FOSS Minecraft launcher supporting 
multiple instances and accounts

Due to some recent changes to PolyMC that I (and most people) don't
agree with [1], I have decided to package the new Prism Launcher fork
instead of PolyMC.

Thanks,
--
Ben Westover

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018255#16


OpenPGP_signature
Description: PGP signature

Bug#861615: Changing forks

[Ben Westover]

Due to some recent changes to PolyMC that I (and most people) don't
agree with [1], I have decided to package the new Prism Launcher fork
instead of PolyMC.

Thanks,
--
Ben Westover

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018255#16


OpenPGP_signature
Description: PGP signature

Bug#898972: Changing forks

[Ben Westover]

Control: retitle -1 ITP: polymc -- FOSS Minecraft launcher supporting multiple 
instances and accounts

Due to some recent changes to PolyMC that I (and most people) don't
agree with [1], I have decided to package the new Prism Launcher fork
instead of PolyMC.

Thanks,
--
Ben Westover

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018255#16


OpenPGP_signature
Description: PGP signature

Bug#1022747: RFS: prismlauncher/5.0+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Ben Westover]

Package: sponsorship-requests
Severity: wishlist
Control: block 898972 by -1

Dear mentors,

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

  * Package name : prismlauncher
Version  : 5.0+ds-1
  * URL  : https://prismlauncher.org
  * License  : GPL-3 and Apache-2.0
  * Vcs  : https://salsa.debian.org/BenTheTechGuy/prismlauncher
Section  : contrib/games

The source builds the following binary packages:

   prismlauncher - FOSS Minecraft launcher supporting multiple instances
and accounts

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/contrib/p/prismlauncher/prismlauncher_5.0+ds-1.dsc

Changes for the initial release:

  prismlauncher (5.0+ds-1) unstable; urgency=medium
  .
* Initial Package (Closes: #898972)

Regards,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1018255: Choosing new fork

[Ben Westover]

Letting this simmer for about a week, I have decided to focus my efforts
to packaging the new Prism Launcher fork instead of PolyMC, because it
seems PolyMC is now a lost cause and the "real" upstream has moved on to
Prism Launcher.

Thanks,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1020926: Additional information

[Teresa Cancino]

Hi!

As additional information:

Public BW Uplink: 10Gbps
IPv4: Yes
IPv6: Yes
Protocols: HTTP and HTTPS

Thanks!
Regards
Teresa

Bug#1019819: qutemol: Please transition to wxwidgets3.2

[Scott Talbert]

On Sun, 23 Oct 2022, Graham Inggs wrote:


Control: tags -1 + help

Hi Scott

Thanks for driving the transition to wxwidgets3.2.

I've tried switching the Build-Depends from libwxgtk3.0-gtk3-dev to
libwxgtk3.2-dev in qutemol, but the build fails with the output below.

Any hints would be appreciated.


Hi Graham,

I sent a pull request[1] to fix the compile issue (basically, qutemol was 
using a long-deprecated API for wxGLCanvas that was finally removed in wx 
3.2).


However, after fixing that, qutemol runs into another problem, which is 
basically that wxWidgets 3.2, which is compiled to use OpenGL EGL, is 
incompatible with glew, which is compiled to use OpenGL GLX.  This is 
documented in this bug[2] and still needs to be sorted out.


Regards,
Scott

[1] https://salsa.debian.org/debichem-team/qutemol/-/merge_requests/2
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020640

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 24/10/2022 21:55, Christopher Obbard wrote:

I'm more leaning on just adding it as a direct Dependency to the Debos
package and seeing if anyone moans...

Works for me.

Bug#1022726: dillo: Upstream domain/website no more under control by the upstream developers

[Axel Beckert]

Control: retitle -1 dillo: Upstream domain/website no more under control by the 
upstream developers, maybe switch to DilloNG as upstream?

Hi again,

Axel Beckert wrote:
> It seems that the owner of the domain dillo[.]org changed on 10th of
> October 2022 and no more belongs to the Dillo upstream developers.
> 
> It still worked on 6th of October:
> https://web.archive.org/web/2022100608/https://www.dillo.org/
> 
> Also the project leader only used an @dillo[.]org e-mail address, so
> there seems no easy way to contact him. (There are a few other upstream
> developers with e.g. GMX addresses who might still be reachable.)
> 
> This unfortunately means that the upstream project has fallen asleep
> even more than before — despite there still was some demand for the
> project as could be seen by several requests for making a new release on
> the mailing list the past few years.

Someone from the orbit of Bunsenlab Linux reminded me that there is a
fork named DilloNG at https://github.com/w00fpack/dilloNG/

Bunsenlab seems to have based their Dillo package on Debian's plus
that repo as upstream version. So maybe we should do that, too. They
actually even made a 3.1X (tag name) / 3.1.0 (versions in file name)
release about 11 months ago.

I just looked through all additional commits seemingly not coming from
the original Dillo developers. They so far looked sane although some
might be a matter of taste or need to be reverted for data privacy
reasons, like preferring Google over DuckDuckGo as default search
engine which from my point of view is inacceptable.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1022746: please provide linux-image-generic / linux-headers-generic

[Patrick Schleizer]

Package: linux
Severity: normal

Dear maintainer,

In Debian, linux-headers-generic is a virtual package.

https://packages.debian.org/bullseye/linux-headers-generic

In Ubuntu, linux-headers-generic is a real package.

https://packages.ubuntu.com/linux-headers-generic

It depends at time of writing on linux-headers-5.19.0-21-generic which 
then somehow pulls the architecture specific kernel headers package.


What's the advantage of having a linux-headers-generic package?

Instructions to install packages often look like this:

sudo apt install some-package-that-builds-a-kernel-module 
linux-headers-$(dpkg --print-architecture)


The part "$(dpkg --print-architecture)" is hard to type, remember for 
many users. Bash tab competition is unsupported.


By comparison, the following looks nicer.

sudo apt install some-package-that-builds-a-kernel-module 
linux-headers-generic


But once linux-headers-generic exists, this could could be simplified 
even further. some-package-that-builds-a-kernel-module then could have a 
'Depends: linux-headers-generic'. Then it could be as simple as:


sudo apt install some-package-that-builds-a-kernel-module

The internet is full with people asking questions because package 
installation failed due to missing kernel headers packages.


Could this please be improved?

Cheers,
Patrick

Bug#1022714: dvisvgm: fails to build with Ghostscript 10: undefined reference to `gs_error_names'

[Hilmar Preuße]

Am 24.10.2022 um 18:08 teilte Adrian Bunk mit:

Hi,


https://github.com/mgieseki/dvisvgm/releases

dvisvgm 3.0 Pre-release
This is a public test version of a new major dvisvgm release. It's still
in development and some functionality might not work properly yet.
...
A new PDF handler based on mutool has been added to keep dvisvgm's PDF
conversion functionality available after the removal of Ghostscript's
old PDF interpreter announced for version 10.1.0.
...

Moving libgs-dev from Build-Depends to Build-Conflicts makes 3.0 build.

Many thanks for the hint. Removing libgs-dev from BD should solve the 
issue, but adding it to Build-Conflicts could help people trying to 
build the package. Can we do "Build-Conflict: libgs-dev (>= 10.0.0)"?



A new dependency on mupdf-tools is then likely required


I'd rather use "Recommends". OK?


I haven't checked whether the resulting package also works. >Me neither, still 
searching testers.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022143: Acknowledgement (pulseaudio: Locks up constantly)

[Phil Dibowitz]

I found the culprit!

gnome-remote-desktop caused pipewire and friends to get installed. Even 
with `pipewire-pulse` installed, audio was unusable when pipewire was 
installed.


Removing all pipewire packages allowed audio to work again.

--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#1022070: 5.10.0-19-amd64 works now on Tuxedo Aura 15 Gen1

[Jan Wedekind]

Thanks for fixing the issue!

Kind regards
Jan

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

[Punit Agrawal]

Hi Fukui-san,

Daichi Fukui  writes:

> Hello Debian Developers,
>
> On Sat, 13 Aug 2022 13:03:16 + Fukui Daichi 
>  wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Fukui Daichi 
>> X-Debbugs-Cc: debian-de...@lists.debian.org, a.dog.will.t...@akane.waseda.jp
>> 
>> * Package name: c4core
>>   Version : 0.1.9
>>   Upstream Author : Joao Paulo Magalhaes 
>> * URL : https://github.com/biojppm/c4core
>> * License : MIT
>>   Programming Lang: C++
>>   Description : library of low-level C++ utilities, written with 
>> low-latency projects in mind
>> 
>> Rationale:
>>rapidyaml [0] depends on this utility.
>>Moreover, jsonnet [1] depends on rapidyaml.
>> 
>>[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
>>[1] https://tracker.debian.org/pkg/jsonnet
>> 
>> Maintenance plan:
>>Because I am a novice in debian packaging, I would like to
>>ask for someone who can review my upload. I need a sponsor too.
>> 
>> 
>
> As mentioned in a different bugreport [0], c4core depends on biojppm/cmake, 
> debugbreak, and fast_float.
> To meet the dependency, we're now preparing for uploading debugbreak and 
> fast_float [1][2].
>
> As for biojppm/cmake, it looks like this software is used for the author's 
> project only.
> This makes me wonder if it is really reasonable to package biojppm/cmake.
> It is technically possible to package it but it could end up with no other 
> packages depending on the packaged biojppm/cmake than c4core.
> To make a clear decision, I would like to ask for your opinion on this issue.
>
> If you are interested, see also a discussion [3] similar to this one.

I'm not familiar with Debian convention regarding this so please take
any comments here with a pinch of salt.

Considering that you've found a precedent, you should be able to package
biojppm/cmake together with c4core. Does upstream provide a combined
release tarball with it included? If so, I'd suggest using that for the
upload and look to split it out of the package if required.

Hope that helps.

Regards,
Punit

> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397#35
> [1] https://ftp-master.debian.org/new/debugbreak_1.0-1.html
> [2] https://ftp-master.debian.org/new/fast-float_3.5.1-1.html
> [3] https://lists.debian.org/debian-security-tools/2020/12/msg00012.html

Bug#1019233: conserver FTBFS on IPV6-only buildds

[Bernhard Schmidt]

After some thoughts on it I've decided to make the test-suite non-fatal
in the pending 8.2.7-2 upload. 

The root cause of the test-suite error appears to be that conserver is
using AI_ADDRCONFIG, and fails to resolve localhost to 127.0.0.1 on
machines that do not have non-local IPv4 connectivity.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952740
https://lists.debian.org/debian-devel/2022/02/msg00070.html

I have briefly tried to make the test-suite cope with both situations,
but was not successful. I don't want to make any code changes breaking
some real-world application while beating the testsuite into submission,
so for now I'll ignore the failure.

Bug#1018945: transition: libbpf

[Sudip Mukherjee]

As of today only v4l-utils and bpfcc still fails to build with libbpf
in experimental.

v4l-utils is a key package, I will look into its fix and request the
libbpf transition after that.


-- 
Regards
Sudip

Bug#1020168: ecb: FTBFS: make[2]: *** [Makefile:86: ecb] Error 255

[Bálint Réczey]

Control: tags -1 confirmed help

Lucas Nussbaum  ezt írta (időpont: 2022. szept. 18., V, 9:00):
>
> Source: ecb
> Version: 2.50+git20170628-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>'
> > Makefile:44: Makefile.conf not found. Using defaults for Linux!
> > Makefile:45: Create Makefile.conf from Makefile.conf.template to override 
> > the defaults.
> > Byte-compiling ECB with LOADPATH= ...
> > emacs -batch -no-site-file -l ecb-compile-script --eval '(ecb-byte-compile 
> > t)'
> > Package cl is deprecated
> > ecb-util.el: Warning: ‘typecase’ is an obsolete alias (as of 27.1); use 
> > ‘cl-typecase’ instead.
> > Compiler-macro error for cl-typep: (error "Unknown type 
> > button-release-event")
> > Compiler-macro error for cl-typep: (error "Unknown type button-press-event")
...
> > ecb-compilation.el: Warning: ‘return’ is an obsolete alias (as of 27.1); 
> > use ‘cl-return’ instead.
> > Debugger entered--Lisp error: (error "Cannot find suitable directory for 
> > output in ‘nati...")
> >   error("Cannot find suitable directory for output in `nati...")

I think this is an result of native compilation behaviour change in
emacs 28 as discussed in this thread for example:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-01/msg00838.html

There are other similar FTBFS bugs and emacs-buttercup has been fixed
for example:
https://salsa.debian.org/emacsen-team/emacs-buttercup/-/commit/a42603de8c739681d9ae2e660af637ffb583a67d

I think the best course of action would be switching ecb to use
dh_elpa, but I don't know when I can work on that, thus help is
appreciated.

Thanks,
Balint

Bug#1022743: expat: CVE-2022-43680

[Salvatore Bonaccorso]

Source: expat
Version: 2.4.9-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libexpat/libexpat/issues/649
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for expat.

CVE-2022-43680[0]:
| In libexpat through 2.4.9, there is a use-after free caused by
| overeager destruction of a shared DTD in
| XML_ExternalEntityParserCreate in out-of-memory situations.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-43680
https://www.cve.org/CVERecord?id=CVE-2022-43680
[1] https://github.com/libexpat/libexpat/issues/649
[2] https://github.com/libexpat/libexpat/pull/616
[3] https://github.com/libexpat/libexpat/pull/650

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1022742: multipath-tools: CVE-2022-41973 CVE-2022-41974

[Salvatore Bonaccorso]

Source: multipath-tools
Version: 0.9.0-4
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.7.9-3

Hi,

The following vulnerabilities were published for multipath-tools.

CVE-2022-41973[0]:
| Symlink attack

CVE-2022-41974[1]:
| Authorization bypass

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-41973
https://www.cve.org/CVERecord?id=CVE-2022-41973
[1] https://security-tracker.debian.org/tracker/CVE-2022-41974
https://www.cve.org/CVERecord?id=CVE-2022-41974
[2] https://www.openwall.com/lists/oss-security/2022/10/24/2

Regards,
Salvatore

Bug#1022741: ITP: golang-github-scaleway-scaleway-sdk-go -- Scaleway API SDK for Go

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-scaleway-scaleway-sdk-go
  Version : 1.0.0~beta9-1
  Upstream Author : Scaleway
* URL : https://github.com/scaleway/scaleway-sdk-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Scaleway API SDK for Go

Scaleway is a European cloud computing company proposing a complete &
simple public cloud ecosystem, bare-metal servers & private datacenter
infrastructures.
.
This package provides an SDK to programmatically interact with the
Scaleway API from Go.

This is a build-dep of the Scaleway service discovery mechanism in
Prometheus. I will co-maintain this package as a member of the Debian Go
Packaging team.

Bug#1022740: miller: Maybe versions newer than 5.x siliently drop data

[Kingsley G. Morse Jr.]

Package: miller
Version: 6.4.0-1

Thank you very much for maintaining miller.

I like, use and respect it.

The main reason I'm writing is to report a
circumstance where miller 

ignores an empty row of data and 

moves all subsequent rows up.

I don't want to over-react, but I'm worried that
shifting data might lead downstream applications
to misinterpret it.

Here's a small example that elicits the behavior:

$ echo -e "a,b\n1,2\n\n5,6" | mlr --csv cut -f a

At least on my computer, it responded with

a
1
5

I expected to see

a
1

5

The guy maintaining debian's package, Stephen
Kitts, seems to think it used to work with version
5.x.

At least for me, both versions 

6.2.0-1 and 

6.4.0-1

of miller ignored the blank row, both 

with and

without

"--ragged".

Feel free to contact me with any questions or
concerns.

Kind regards,
Kingsley

PS: Normally I'd report bugs with Debian's "reportbug"
command line utility, but at the moment, at least
mine is crashing with the following python error:

AttributeError: module 'collections' has no attribute 'Mapping'

So I'm trying the instructions for sending bug
reports via e-mail at

https://www.debian.org/Bugs/Reporting
-- 
Time is the fire in which we all burn.

Bug#1022286: gnome-shell-extension-manager: FTBFS: ModuleNotFoundError: No module named 'gi'

[Heather Ellsworth]

Ah yes you are right, I have moved the dependency to the control.in file 
and regenerated the control file. The changes have been pushed to the 
debian/master branch and I'll work with Jeremy to re-upload :)


Cheers,
Heather

On 10/23/22 11:04, Simon McVittie wrote:

Control: reassign -1 blueprint-compiler 0.4.0-3
Control: affects -1 + src:gnome-shell-extension-manager

On Sun, 23 Oct 2022 at 14:38:05 +0200, Lucas Nussbaum wrote:

Program blueprint-compiler found: YES (/usr/bin/blueprint-compiler)

...

Traceback (most recent call last):
   File "/usr/bin/blueprint-compiler", line 37, in 
 from blueprintcompiler import main

...

   File "/usr/lib/python3/dist-packages/blueprintcompiler/gir.py", line 24, in 

 import gi # type: ignore
ModuleNotFoundError: No module named 'gi'


This looks like a missing dependency in blueprint-compiler.

 From a brief look at the package, it seems like python3-gi might have been
added to debian/control, instead of adding it to debian/control.in and
then regenerating debian/control with `make -f debian/rules clean`. This
effectively results in the change being reverted whenever the package
is rebuilt.

 smcv

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

On Mon, Oct 24, 2022, at 21:31, Raphaël Halimi wrote:
> I don't know how to use strace. Could you please direct me ?

If you find the process that hangs (likely a ccache process in this case) with
PID P, use

strace -p P

to attach to it and see which system call it is waiting for.

> The file does not exist on my machine; do I just need to create
> /var/cache/pbuilder/ccache/ccache.conf containing a single line "log_file=..."
> or is there something else to do ?

Yes, something like

echo "log_file = /var/cache/pbuilder/ccache/ccache.log" 
>/var/cache/pbuilder/ccache/ccache.conf

should do it.

Regards,
Joel

Bug#1022739: wxwidgets3.0: Do not release with bookworm

[Olly Betts]

Source: wxwidgets3.0
Version: 3.0.5.1+dfsg-5
Severity: serious
Justification: Opinion of package maintainer

We have packages of wxwidgets3.2 in unstable and testing, and a
transition is well under way:

https://release.debian.org/transitions/html/wxwidgets-3.2.html

The last upstream release of wxwidgets3.0 was 2½ years ago, and there's
very little upstream interest in bugs in it now.

Keeping wxwidgets3.0 for another release cycle without upstream support
doesn't seem a good idea, so opening an RC bug.

Cheers,
Olly

Bug#1016291: python-inotify: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Lucas Nussbaum]

Hi Bastian,

On 23/08/22 at 14:40 +0200, Bastian Germann wrote:
> Control: severity -1 important
> 
> I cannot reproduce this. Which kernel version did you use?

You did not send me your reply. As a reminder the bug submitter does not
get emails sent to n...@bugs.debian.org.

I used a standard bullseye VM (running on Amazon EC2), with the bullseye
kernel. I can still reproduce this failure.

Lucas

Bug#1022704: ccache: broken in cross-architecture chroot

[Raphaël Halimi]

Le 24/10/2022 à 20:17, Joel Rosdahl a écrit :

On Mon, Oct 24, 2022, at 15:26, Raphaël Halimi wrote:

Install pbuilder on an amd64 host and prepare an i386 chroot. Then, try to
build a package in it (I was rebuilding timidity). It should hang during the
configure phase.


I've never used pbuilder before, but I've tried creating an i386 chroot now,
setting CCACHEDIR according to pbuilderrc(5).

I then built timidity multiple times with "pdebuild --architecture i386", but it
works fine for me every time. I've checked that ccache 4.7.1-1 is being used and
that the ccache directory is being utilized. I'm afraid I'll need more help to
track this down.


That's weird. Before filing the bug, I tried to recreate my build 
environment in a brand new VM, and I observed the same behavior. Maybe 
the problem lies in my configuration ? Regarding ccache, I just set it 
to /var/cache/pbuilder/ccache (some packages failed to build when I 
initially put it in ~/.ccache, permissions problems I think, because 
pbuilder makes files in there owned by 1234).



1. When you say that it systematically hangs, can you check which process is
hanging and what it hangs on, e.g. using strace?


I don't know how to use strace. Could you please direct me ?


2. Would it be possible for you to set CCACHE_LOGFILE (or log_file in
ccache.conf in the ccache directory) to a file inside the pbuilder chroot 
and
then publish the created log file?


I'll try to do that. The file does not exist on my machine; do I just 
need to create /var/cache/pbuilder/ccache/ccache.conf containing a 
single line "log_file=..." or is there something else to do ?


Regards,

--
Raphaël Halimi

Bug#857132: Greetings!

[Ulyana Soroka]

Hello, I found your email on my contact list, i think we must have met
before on a social network, my name is Ulyana Soroka i am from USA, i will
be coming for vacation in your country. Would you like us to meet?



Have a nice moment!

Bug#1019416: Raising severity of remaining wxwidgets3.2 transition blockers

[Olly Betts]

severity 1019823 serious
severity 1019775 serious
severity 1019768 serious
severity 1019812 serious
severity 1019835 serious
severity 1019769 serious
severity 1019799 serious
severity 1019827 serious
severity 1019808 serious
severity 1019830 serious
severity 1019762 serious
severity 1019829 serious
severity 1019791 serious
severity 1019818 serious
severity 1019792 serious
severity 1019776 serious
severity 1019784 serious
severity 1019828 serious
severity 1019819 serious
severity 1019804 serious
severity 1019814 serious
severity 1019805 serious
severity 1019841 serious
severity 1019772 serious
severity 1019790 serious
severity 1019824 serious
severity 1019773 serious
severity 1019783 serious
severity 1019806 serious
severity 1019839 serious
severity 1019765 serious
severity 1019837 serious
severity 1019810 serious
severity 1019782 serious
severity 1019781 serious
severity 1019779 serious
thanks

Accounting for packages which are fixed in experimental or in git we're
now under 30 packages left to do, so raising the severity to "serious".

Justification: https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Please start to investigate making this transition if you haven't already.
In most cases it's proving to be an easy update, but in minority of
cases where there are obstacles it's much better to find that out sooner
rather than later.

Cheers,
Olly

Bug#1002789: still reproducible

[Lucas Nussbaum]

Control: severity -1 serious

Hi,

This is still reproducible; setting severity back to serious

Lucas

Bug#1022737: smarty3: re-enable lexer/parser generation of configfile/template parsers/lexers

[Mike Gabriel]

Package: src:smarty3
Version: 3.1.47-1
Severity: important

In 3.1.47-1 of smarty3, we disabled the generation of parsers/lexers.  
Strictly regarding this, this violates Debian policy (as we need to  
build all files from source and don't ship machine-generated code as  
source files).


This is a reminder bug that shall let us remember to undo the  
disabling as done for the 3.1.47-1 upload (in debian/rules).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpSXnydtiRQY.pgp
Description: Digitale PGP-Signatur

Bug#1022736: smarty4: re-enable lexer/parser generation of configfile/template parsers/lexers

[Mike Gabriel]

Package: src:smarty4
Version: 4.2.1-1
Severity: important

In 4.2.1-1 of smarty4, we disabled the generation of parsers/lexers.  
Strictly regarding this, this violates Debian policy (as we need to  
build all files from source and don't ship machine-generated code as  
source files).


This is a reminder bug that shall let us remember to undo the  
disabling as done for the 4.2.1-1 upload (in debian/rules).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpZ1TEg4t0L1.pgp
Description: Digitale PGP-Signatur

Bug#1022734: karabo-bridge: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Lucas Nussbaum]

Source: karabo-bridge
Version: 0.6.1-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221024 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> copying karabo_bridge/tests/test_client.py -> 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/tests
> copying karabo_bridge/tests/utils.py -> 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/tests
> creating 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/cli
> copying karabo_bridge/cli/__init__.py -> 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/cli
> copying karabo_bridge/cli/monitor.py -> 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/cli
> copying karabo_bridge/cli/glimpse.py -> 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/cli
> copying karabo_bridge/cli/simulation.py -> 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build/karabo_bridge/cli
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:240: cd 
> /<>/.pybuild/cpython3_3.10_karabo-bridge/build; python3.10 -m 
> pytest 
> = test session starts 
> ==
> platform linux -- Python 3.10.7, pytest-7.1.2, pluggy-1.0.0+repack
> rootdir: /<>
> collected 31 items
> 
> karabo_bridge/tests/test_client.py 
> E: Build killed with signal TERM after 150 minutes of inactivity


The full build log is available from:
http://qa-logs.debian.net/2022/10/24/karabo-bridge_0.6.1-3_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221024;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221024=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1022733: nova: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Lucas Nussbaum]

Source: nova
Version: 2:26.0.0-1.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221024 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> nova.tests.unit.virt.vmwareapi.test_volumeops.VMwareVolumeOpsTestCase.test_iscsi_get_host_iqn_instance_not_found
>  ... ok
> nova.tests.unit.virt.vmwareapi.test_volumeops.VMwareVolumeOpsTestCase.test_update_volume_details
> nova.tests.unit.virt.vmwareapi.test_volumeops.VMwareVolumeOpsTestCase.test_update_volume_details
>  ... ok
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_admin_context_without_token
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_admin_context_without_token
>  ... ok
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_no_microversion
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_no_microversion
>  ... ok
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_with_microversion_available
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_with_microversion_available
>  ... ok
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_with_microversion_skip_version_check
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_with_microversion_skip_version_check
>  ... ok
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_with_microversion_too_new
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_create_v3_client_with_microversion_too_new
>  ... ok
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_load_auth_plugin_failed
> nova.tests.unit.volume.test_cinder.CinderClientTestCase.test_load_auth_plugin_failed
>  ... ok
> E: Build killed with signal TERM after 150 minutes of inactivity


The full build log is available from:
http://qa-logs.debian.net/2022/10/24/nova_26.0.0-1.1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221024;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221024=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1022732: macaulay2: FTBFS: make: *** [debian/rules:18: binary] Error 25

[Lucas Nussbaum]

Source: macaulay2
Version: 1.20+ds-7
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221024 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> jdupes -rl debian/macaulay2-common/usr/share/doc/Macaulay2
> make[1]: Leaving directory '/<>'
>dh_link -O--sourcedirectory=M2
>dh_linktree -O--sourcedirectory=M2
> dpkg-query: no path found matching pattern 
> /usr/share/javascript/katex/contrib/copy-tex.css
> dh_linktree: error: dpkg --search -- 
> /usr/share/fonts-glyphicons/glyphicons-halflings-regular.eot 
> /usr/share/fonts-glyphicons/glyphicons-halflings-regular.svg 
> /usr/share/fonts-glyphicons/glyphicons-halflings-regular.ttf 
> /usr/share/fonts-glyphicons/glyphicons-halflings-regular.woff 
> /usr/share/fonts-glyphicons/glyphicons-halflings-regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_AMS-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_AMS-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_AMS-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Caligraphic-Bold.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Caligraphic-Bold.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Caligraphic-Bold.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Caligraphic-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Caligraphic-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Caligraphic-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Fraktur-Bold.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Fraktur-Bold.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Fraktur-Bold.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Fraktur-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Fraktur-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Fraktur-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Bold.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Bold.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Bold.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Main-BoldItalic.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Main-BoldItalic.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Main-BoldItalic.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Italic.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Italic.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Italic.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Main-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Math-BoldItalic.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Math-BoldItalic.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Math-BoldItalic.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Math-Italic.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Math-Italic.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Math-Italic.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Bold.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Bold.woff 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Bold.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Italic.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Italic.woff 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Italic.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_SansSerif-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Script-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Script-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Script-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Size1-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Size1-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Size1-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Size2-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Size2-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Size2-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Size3-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Size3-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Size3-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Size4-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Size4-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Size4-Regular.woff2 
> /usr/share/fonts/truetype/katex/KaTeX_Typewriter-Regular.ttf 
> /usr/share/fonts/truetype/katex/KaTeX_Typewriter-Regular.woff 
> /usr/share/fonts/truetype/katex/KaTeX_Typewriter-Regular.woff2 
> /usr/share/javascript/bootsidemenu/BootSideMenu.css 
> /usr/share/javascript/bootsidemenu/BootSideMenu.js 
> /usr/share/javascript/bootstrap/css/bootstrap.m

Bug#1022343: [Pkg-pascal-devel] Bug#1022343: Bug#1022343: view3dscene: FTBFS: view3dscene.lpr(63, 17) Fatal: Can't find unit CastleCubeMaps used by view3dscene

[Abou Al Montacir]

On Mon, 2022-10-24 at 01:34 +0200, Michalis Kamburelis wrote:
> So my preferred way to solve this would be to just have view3dscene
> 4.2.0 in Debian.
Yes, I'm working on it!
-- 
Cheers,
Abou Al Montacir



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

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Le 24/10/2022 à 18:26, Clément Hermann a écrit :

Hi,

Le 23/10/2022 à 18:27, Clément Hermann a écrit :

Hi,

Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit :

To be on safe side, explicitly confirming by upstream would be great.


Agreed. And asked upstream: 
https://github.com/onionshare/onionshare/issues/1633.


Upstream replied quickly (yay!) and confirms the known issues are 
fixed in 2.5.


Also, the detail of the vulnerable/patched versions has been updated. 
Quoting from the upstream issue:


Only affected >= 2.3 - < 2.5: CVE-2021-41867 
, CVE-2022-21691 
, CVE-2022-21695 
, CVE-2022-21696 

Only affected >= 2.2 - < 2.5: CVE-2022-21694 

Only affected >=2.0 - < 2.5: CVE-2022-21689 

Only affected >=2.0 - < 2.4: CVE-2021-41868 
 (Receive mode 
bug, fixed by changing the authentication from HTTP auth to using 
Client Auth in Tor itself)
All versions < 2.5: CVE-2022-21690 
, and possibly 
depending on the Qt version, CVE-2022-21688 



GHSA-jgm9-xpfj-4fq6 
 
is a complicated one, as a fix 
 we reduced the 
scope of access for Flatpak but you could argue that on 'native' 
Debian the whole file system, or at least the parts accessible to the 
user running OnionShare, is available not even in read-only mode. I'm 
not sure there's really a 'fix' for the deb package.


The advisories on 
https://github.com/onionshare/onionshare/security/advisories have been 
updated to reflect this.


I did more homework.

So, to summarize:
- CVE-2021-41867 , 
CVE-2022-21691 , 
CVE-2022-21695 , 
CVE-2022-21696  
aren't affecting Debian (stable has 2.2, unstable has 2.5). Which is 
good because the


- CVE-2022-21694  
affects Bullseye, but that might be an acceptable risk ? The issue is 
that CSP can only be turned on or off, not configured to allow js etc, 
so it is only useful for static websites. I believe that's the most 
common usage of a website with onionshare, and it's arguably a missing 
feature more than a vulnerability /per se/.


- CVE-2022-21689  fix 
should be easy to backport, at a glance: 
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377


- CVE-2021-41868  
doesn't affect 2.2 I think, it must have been a mistake from mig5. I 
just asked for confirmation. I do hope so since it's a bad one.


- CVE-2022-21690  
seems like a one-line patch: 
https://github.com/onionshare/onionshare/commit/8f1e7ac224e54f57e43321bba2c2f9fdb5143bb0


- CVE-2022-21688  
seems like it should be worked around with the CVE-2022-21690 
 fix (OTF-001)?


I'd welcome input on those.

Cheers,

--
nodens

Bug#1022336: xz-utils: FTBFS: Can't exec "cmake": No such file or directory at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 526.

[Sebastian Andrzej Siewior]

On 2022-10-23 15:12:35 [+0200], Lucas Nussbaum wrote:
> Relevant part (hopefully):
> >  debian/rules build
> > dh build --parallel 
> > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
> >dh_update_autotools_config -O--parallel
> >dh_auto_configure -O--parallel
> > dh_auto_configure: warning: Compatibility levels before 10 are deprecated 
> > (level 9 in use)
> > cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
> > -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
> > -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
> > -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
> > -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
> > -DFETCHCONTENT_FULLY_DISCONNECTED=ON "-GUnix Makefiles" 
> > -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
> > Can't exec "cmake": No such file or directory at 
> > /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 526.

It autodetects cmake but shouldn't. It built fine a few days ago, not
sure what changed.
Aynway, I'm going to fix the hurd build and this, too.

Sebastian

Bug#1021571: smarty3: Parse error in /usr/share/php/smarty3/sysplugins/smarty_internal_templateparser.php on line 24

[Mike Gabriel]

Control: forwarded -1 https://github.com/smarty-php/smarty/issues/822

Hi Ed,

thanks for letting me know.

On  Mo 10 Okt 2022 23:43:15 CEST, Ed Martin wrote:


Package: smarty3
Version: 3.1.45-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm testing some build scripts and testing my package on a VM  
running bookworm, my application uses smarty3


Turns out that the latest smarty3 is broken,  
smarty_internal_templateparser.php has this bit of code between two  
classes:



   // line  "./lexer/smarty_internal_templateparser.y"
   0
   // line 11 "./lexer/smarty_internal_templateparser.y"

and that stray 0 breaks the template parser...since the template  
parser is really all smarty does, this breaks the package


My test case for the bug report is:

   setTemplateDir('/var/www/html/');
   $smarty->testInstall();

   // assign some content. This would typically come from
   // a database or other source, but we'll use static
   // values for the purpose of this example.
   $smarty->assign('name', 'george smith');
   $smarty->assign('address', '45th & Harris');

   $smarty->debugging = true;

   // display it
   $smarty->display('test.tpl');
   ?>

And test.tpl:



Info




User Information:

Name: {$name}
Address: {$address}






I have just filed an upstream bug report for this:
https://github.com/smarty-php/smarty/issues/822

Let's see if we get some help with this from upstream.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpmD3kiu_NeU.pgp
Description: Digitale PGP-Signatur

Bug#1022729: RFP: luau -- A fast, small, safe, gradually typed embeddable scripting language derived from Lua

[Thomas Uhle]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Lua Team 

* Package name: luau
  Version : 0.550
  Upstream Author : Roblox Corporation
* URL or Web page : https://luau-lang.org/
* License : MIT
  Description : A fast, small, safe, gradually typed embeddable scripting 
language derived from Lua

As a language, Luau is designed to be a full superset of Lua 5.1 that 
incorporates features from later Lua releases as well, but it also 
expands the feature set (most notably with type annotations).
It is largely implemented from scratch, with the language runtime being 
a very heavily modified version of the Lua 5.1 runtime, with completely 
rewritten interpreter and other performance innovations.
Whenever possible, it aims to be backwards-compatible with Lua 5.1 API, 
so existing bindings should be more or less compatible with a few 
caveats. Luau limits the set of standard libraries exposed to the users 
and implements extra sandboxing features to be able to run unprivileged 
code side by side with privileged code. This results in an execution 
environment that is different from what is common in Lua.


To make it easier to write correct code, Luau also comes with a set of 
script analysis tools being a type checker and linter integrated into 
the command-line executable 'luau-analyze'. Given a set of input files, 
it produces errors and warnings according to the configuration that can 
be customized by using --! comments in the files or by .luaurc files.

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

On Mon, Oct 24, 2022, at 15:26, Raphaël Halimi wrote:
> Install pbuilder on an amd64 host and prepare an i386 chroot. Then, try to
> build a package in it (I was rebuilding timidity). It should hang during the
> configure phase.

I've never used pbuilder before, but I've tried creating an i386 chroot now,
setting CCACHEDIR according to pbuilderrc(5).

I then built timidity multiple times with "pdebuild --architecture i386", but it
works fine for me every time. I've checked that ccache 4.7.1-1 is being used and
that the ccache directory is being utilized. I'm afraid I'll need more help to
track this down.

1. When you say that it systematically hangs, can you check which process is
   hanging and what it hangs on, e.g. using strace?
2. Would it be possible for you to set CCACHE_LOGFILE (or log_file in
   ccache.conf in the ccache directory) to a file inside the pbuilder chroot and
   then publish the created log file?

Regards,
Joel

Bug#1022728: src:gnome-subtitles: fails to migrate to testing for too long: FTBFS on 32 bit archs

[Paul Gevers]

Source: gnome-subtitles
Version: 1.6-2.1
Severity: serious
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:gnome-subtitles has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package failed to 
build on our 32 bit architectures where it used to build successfully in 
the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=gnome-subtitles



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022727: ITP: rust-lazy-regex -- lazy static regexes checked at compile time

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-lazy-regex
  Version : 2.3.0
  Upstream Author : Canop 
* URL : https://github.com/canop/lazy-regex
* License : Expat
  Programming Lang: Rust
  Description : lazy static regexes checked at compile time

 Lazy-regex enables you to use the `regex!` macro to build regexes:
  * they're checked at compile time
  * they're wrapped in `once_cell` lazy static initializers
so that they're compiled only once
  * they can hold flags as suffix:
`let case_insensitive_regex = regex!("ab*"i);`
  * regex creation is less verbose
 .
 This macro returns references to normal instances of `regex::Regex`
 so all the usual features are available.

This package is needed to improve test coverage for package rsass.
It will be maintained in the collaborative Debian section of Salsa,
here: .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNW07AACgkQLHwxRsGg
ASEfoQ//X6EGKvSPSs7+eYsyyZkh9Kgc6tYR+SqOPaKHXmnQI0MWutOx1u2MfE2n
p862BRy+dKTrsX3OLDsab0TOaZ+Ji7DyxSHkSIo5xbVIJdUr1BQ1NhwVz1urxIdB
kyKzmAclV3HrR1pP1AXwHLq94TgaJsxOCY9cOQ2dtHT/f3iJtxKO0f9DJJup5zYg
iNUq/0gr2I4izrw4yK8wvzZvCHNItrtkGZOXQJg49s3DR/IbUXGqY9jwr5QDKE9k
GoGJY6Q8G1T/f909vYEuW3k2Bk+ySs37F8/Q+FJ/Rlq9YLIcLJVYO15MQLRKt7jq
sSMVyjE6+Z/tuBNmQnDdVu/vKA+1TpvbqS4S3hmXpfDq56xaiZksf7rFs9kxyG29
CbgkkAakBU3E+NiItl+sejrIgVAFgdxy2gT7WysdSRHRdd96SN48CXAvBIl19yBu
XGqGvxO2tyONZ7FihrSnlgsyp3Ne90BSblTalEtmRU0NUwiVU6zdFxd78eu2slwM
9K+R7WTWSUwDmItaUABT4K7UmCdJfY43Dx7UCJyidG7dXsvv34x6dDPNalIJBKCF
236tAneQ62OActf9spbCJd/fOun8P45Qhb/eFOX5AcVlGKKHBcxe+Yacsb0ag9LK
ouLfmjpnzwDUuwwOMVvZV5FleduT68yumPMUePATDQv1p70WsRI=
=TaCM
-END PGP SIGNATURE-

Bug#1021062: fixed in bash 5.2-2

[Aurelien Jarno]

control: reopen 1021062

On 2022-10-24 09:04, Debian FTP Masters wrote:
> Source: bash
> Source-Version: 5.2-2
> Done: Matthias Klose 
> 
> We believe that the bug you reported is fixed in the latest version of
> bash, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1021...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Matthias Klose  (supplier of updated bash package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> Format: 1.8
> Date: Mon, 24 Oct 2022 10:34:28 +0200
> Source: bash
> Architecture: source
> Version: 5.2-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Matthias Klose 
> Changed-By: Matthias Klose 
> Closes: 1021062
> Changes:
>  bash (5.2-2) unstable; urgency=medium
>  .
>* Apply upstream patches 001 - 002.
>  - Expanding unset arrays in an arithmetic context can cause a
>segmentation fault.
>  - Starting bash with an invalid locale specification for
>LC_ALL/LANG/LC_CTYPE can cause the shell to crash. Closes: #1021062.

This is the wrong bug number, the problem might be fixed in bash, but is
still present in libreadline8. Reopening.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1022564: locale related segmentation fault

[Aurelien Jarno]

control: reassign -1 libreadline8 
control: forcemerge 1021062 -1

Hi,

On 2022-10-24 05:16, Aleksi Suhonen wrote:
> Package: libc6
> Version: 2.35-3
> Severity: important
> 
> I ran into this issue while updating packages on a Debian/sid machine, and
> the install scripts for "ntpsec" and "tzdata" started failing with segfault.
> I couldn't find a way to reproduce it on that machine immediately. I started
> suspecting the machine might be failing.
> 
> But then I ran into the problem on another machine that runs "bird" routing
> daemon, as its control program "birdc" also started segfaulting, but started
> working if I set LC_ALL=C. Then I found I could also get the install scripts
> on the first machine to work with LC_ALL=C.
> 
> So, steps to reproduce:
> 
> root# apt-get install bird
> root# LC_ALL=asdf birdc

The problem you observed is not linked to glibc, but is a known bug in
libreadline8 affecting many packages. Please see bug#1021062. I am
therefore reassigning the bug.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1021658: Processed: autopkgtest regressions are RC (and this one also blocks the perl transition)

[Paul Gevers]

Hi,

On 24-10-2022 12:00, Adrian Bunk wrote:

On Sun, Oct 23, 2022 at 12:35:41PM +0200, Paul Gevers wrote:

We'll handle it somehow yes.


It seems someone already handled it or it disappeared by itself.


Yes, I scheduled the tests with *less* packages from unstable than 
britney and those passed.



Any further ideas how to handle the situation?


We'll handle perl, you can handle TL yourself by filling an RC bug.


The autopkgtest regression in latexml already prevents the migration of TL.


I think Hilmar was afraid of what happens after latexml is removed from 
testing. Than TL migrates and breaks latexml for users of testing that 
don't immediately remove packages that are no longer in testing.



The only possible action on the TL side will be after latexml is fixed
to add Breaks in TL against unfixed versions of latexml to avoid users
(or test environments) ending up with incompatble combinations.


That, but I think it's reasonable *for some time* to prevent TL to 
migrate even if latexml is already removed. Having said that, being 60 
days out-of-sync between unstable and testing is by default RC too, so 
the "for some time" isn't extremely long.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022726: dillo: Upstream domain/website no more under control by the upstream developers

[Axel Beckert]

Package: dillo
Severity: important

It seems that the owner of the domain dillo[.]org changed on 10th of
October 2022 and no more belongs to the Dillo upstream developers.

It still worked on 6th of October:
https://web.archive.org/web/2022100608/https://www.dillo.org/

Also the project leader only used an @dillo[.]org e-mail address, so
there seems no easy way to contact him. (There are a few other upstream
developers with e.g. GMX addresses who might still be reachable.)

This unfortunately means that the upstream project has fallen asleep
even more than before — despite there still was some demand for the
project as could be seen by several requests for making a new release on
the mailing list the past few years.

(This bug report is to track the domain loss on the one hand, but also
in the long run to me maybe remove Dillo from Debian.)

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dillo depends on:
ii  libc62.35-3
ii  libfltk1.3   1.3.8-5
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libpng16-16  1.6.38-2
ii  libssl3  3.0.5-4
ii  libstdc++6   12.2.0-7
ii  libx11-6 2:1.8.1-2
ii  wget 1.21.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages dillo recommends:
ii  perl  5.36.0-4

dillo suggests no packages.

-- no debconf information

Bug#1022703: dieharder: Broken output or infinite loop after sts_runs test

[Dirk Eddelbuettel]

Hi Jakub,

Thanks for taking the time to write a bug report!

On 24 October 2022 at 13:10, Jakub Niemczuk wrote:
| Package: dieharder
| Version: 3.31.1.2-1
| Severity: important
| X-Debbugs-Cc: jakubniemc...@gmail.com
| 
| Dear Maintainer,
| 
| Every time I try to use this package on my debian machine all tests run until
| sts_runs test. After that the program prints out only blank lines. I tried to
| redirect the output to a file but that still didn't solve the problem.
| I compiled the newest version from git but the bug is still there.
| The package works fine on my other machine runing Ubuntu 20.04.
| 
| So after running for example: dieharder -a -g 13

:-/

| I get:
| 
| 
#=#
| #dieharder version 3.31.1 Copyright 2003 Robert G. Brown  
#
| 
#=#
|rng_name|rands/second|   Seed   |
| mt19937|  1.32e+08  |2023811135|
| 
#=#
| test_name   |ntup| tsamples |psamples|  p-value |Assessment
| 
#=#
|diehard_birthdays|   0|   100| 100|0.99449351|  PASSED
| ###CUT OUT BY ME###
| sts_runs|   2|10| 100|0.93620636|  PASSED
| ###AND THEN MANY EMPTY LINES APPEARING EVERY ~30 SEC###

Darn. Would you have a moment to maybe jump into the code for sts_runs and
see what may be wrong now with its convergence criterion or count or ... ?

The upstream code is pretty 'dead' and I am being forced to update the code
every now and then for better compliance with update compilers so it could be
that I swapped in a size_t for another loop variable type and maybe created a
signed / unsigned bug?

Otherwise the only fix may be to take sts_run out of the set for 'all' tests.

Dirk

 
| -- System Information:
| Debian Release: 11.5
|   APT prefers stable-updates
|   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
| 'stable')
| Architecture: amd64 (x86_64)
| Foreign Architectures: i386
| 
| Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/32 CPU threads; PREEMPT)
| Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 dieharder depends on:
| ii  libc6  2.31-13+deb11u5
| ii  libdieharder3  3.31.1.2-1
| ii  libgsl25   2.6+dfsg-2
| 
| dieharder recommends no packages.
| 
| dieharder suggests no packages.

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

Bug#1022724: systemd restarts prometheus forever, leading to disk usage death spiral

[Antoine Beaupré]

On 2022-10-24 12:26:11, Antoine Beaupre wrote:
> (I first considered limiting the number of retries to something more
> decent than the current "infinity", but there isn't a setting directly
> for that in systemd. 

[...]

Actually, that seems incorrect. I couldn't find the setting, but
`systemctl show prometheus` shows me a `NRestarts=0` setting which might
do what we want here. It still feels, like the `StartLimit*` settings,
like fixing the symptom instead of the cause.

-- 
Premature optimization is the root of all evil
- Donald Knuth

Bug#1020847: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#1020847: fixed in llvm-toolchain-14 1:14.0.6-3)

[Kristian Høgsberg]

I see the update on https://tracker.debian.org/pkg/llvm-toolchain-14 but it
doesn't seem like it's in the bookworm repo just yet?  Am I missing
something?

On Fri, Oct 7, 2022 at 11:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the libc++-14-dev package:
>
> #1020847: libc++-14-dev: x86 symlinks in arm64 deb for libc++-14-deev
>
> It has been closed by Debian FTP Masters 
> (reply to Sylvestre Ledru ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> (reply to Sylvestre Ledru <
> sylves...@debian.org>) by
> replying to this email.
>
>
> --
> 1020847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020847
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1020847-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 07 Oct 2022 21:46:42 +
> Subject: Bug#1020847: fixed in llvm-toolchain-14 1:14.0.6-3
> Source: llvm-toolchain-14
> Source-Version: 1:14.0.6-3
> Done: Sylvestre Ledru 
>
> We believe that the bug you reported is fixed in the latest version of
> llvm-toolchain-14, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1020...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Sylvestre Ledru  (supplier of updated
> llvm-toolchain-14 package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 30 Aug 2022 16:10:33 +0200
> Source: llvm-toolchain-14
> Architecture: source
> Version: 1:14.0.6-3
> Distribution: unstable
> Urgency: medium
> Maintainer: LLVM Packaging Team 
> Changed-By: Sylvestre Ledru 
> Closes: 1004112 1010932 1018770 1020746 1020847
> Changes:
>  llvm-toolchain-14 (1:14.0.6-3) unstable; urgency=medium
>  .
>* Fix a typo to silent lintian (Closes: #1018770)
>* Fix some hardcoded paths (Closes: #1020847)
>* Suggest wasi-libc for clang
>  .
>[ Witold Baryluk ]
>* Allow libunwind-dev to be coinstallable (Closes: #1004112)
>  .
>[ Faidon Liambotis ]
>* Add better support for the WebAssembly (wasm32/wasm64) targets:
>  - Ship compiler-rt for the wasm32 and wasm64 targets. (Closes:
> #1010932)
>  - Add patch wasm-compiler-rt-default.diff to default to compiler-rt
> for
>these targets. libgcc does not currently exist for WebAssembly in
> neither
>Debian nor upstream, and therefore compiler-rt is the only option.
>  - Add patch wasm-sysroot-usr.diff to support a system-installed (i.e.
> shipped
>in /usr) wasi-libc. (Closes: #1020746)
> Checksums-Sha1:
>  098adf2679323dd7c5b3b1b184ee02c633cd69df 7205
> llvm-toolchain-14_14.0.6-3.dsc
>  bd6cabea5a20c420f36050a11fa6fa7c68628fbd 154056
> llvm-toolchain-14_14.0.6-3.debian.tar.xz
>  8f70b2ce2cb805525c34aded63924a729036f51c 30993
> llvm-toolchain-14_14.0.6-3_amd64.buildinfo
> Checksums-Sha256:
>  4e0679c9b9e6ae0d3829118976fad210a3dba72ba7db7ad0d5aef33a99d500e1 7205
> llvm-toolchain-14_14.0.6-3.dsc
>  968c214a20ec50821e62178508541e1017ae33f39d18c23788a289c5173a7820 154056
> llvm-toolchain-14_14.0.6-3.debian.tar.xz
>  8be4b307a7ccfc7e738ad101397f0b8f3c8c9ac2c9e0e431361ae084bc54884f 30993
> llvm-toolchain-14_14.0.6-3_amd64.buildinfo
> Files:
>  728e1cde592b075891f83f72ec6cc130 7205 devel optional
> llvm-toolchain-14_14.0.6-3.dsc
>  9d37910e7d446329c560300f1bc3ed5b 154056 devel optional
> llvm-toolchain-14_14.0.6-3.debian.tar.xz
>  aa04b76d7aa8bd41a99a21b3f65a3ca9 30993 devel optional
> llvm-toolchain-14_14.0.6-3_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmNAlg4ACgkQfmUo2nUv
> G+Edjg//d+eHMocD/oo3TybedE3coqVkU3Arf0uzj7+HxEJsFD2gRwYS2JdQtFHe
> FplDSMlW8APsvTjof2lV4ldyzUAkU3A5KNajljTeZjB1csRTjtn2rrnTSsALUBRD
> +oltgP0CHUYRFLH+vyWotX/xTzt8NBF0hctENgDodLuiFC6iESeDjqN+dc8PhVOV
> QG4Lv2d1CKkFaC4ExBt+SJlzRAd8ONLZUCHmBktrG2hHyqljL/pDi4qPfzB+I3vz
> uis8/IDVVEnLiVMf3tElblSEfGb0tZ50P5IMQnFpSz0qVjV/vHCjqt5c4Vn8Vfj4
> pK34mHGXx4bgsECg33zUhCTzR5Orsqyq0PDxX3G5OP6T2ldKqlrRhzYeQlX4bHv7
> Y+jVnuiq6KgCJ51zNAYWFBjhY4pF+lCVTR+Vohw9Ob4NIT35k+tX+qxr4b6yOXxk
> rlNV1sY/JCWDkNvZCfsiyjQXeg6OOX68T00/JBaapy0ef3oKftKETu4i/7gQgAZH
> CaUeyrYDLrr42+Z72BhnnJARbJLHH+6r+Yf0zD01Vi7U5KUMcTwhDDb44EbVy0E5
> 

Bug#724014: pavucontrol: Output settings are forgotten and must be set again

[Gerard ROBIN]

On Sat, 22 Oct 2022 00:37:17 +0200 Gerard ROBIN  wrote:
> 
> Same issue with bookworm but not with bullseye.
> kernel: linux-image-5.19.0-2-amd64  5.19.11-1  Linux 5.19 for 64-bit PCs 
> (signed)

I answer to myself because I believe that the bug does not concern pavucontrol
because I uninstalled puseaudio and pavucontrol works well with alsamixer I no
longer have a problem keeping my preferences. So maybe we should see on the
side of pulseaudio instead of incriminating pavucontrol?

PS
I'm using Bullsey to answer but what I'm talking about is about
bookworm.

-- 
Gerard
_
*
 Created with Mutt  2.0.5 
 under Debian Linux BULLSEYE
*

Bug#1021703: slapd crashes when too many clients connect in a short period of time.

[Rudolph Bott]

Hi Harald,

thank you for looking into this.

On Mon, Oct 24, 2022 at 4:36 PM Harald Welte  wrote:

> some miscellaneous questions that come to my mind after reading the bug
> report
>
> * if the slapd is hanging, what does a 'strace' on the PID of the slapd
> process tell you?
>
Unfortunatly I was not able to reproduce the 'hanging slapd' today, it
always crashed directly with the aforementioned assertion error.

* what is the rate of new client connections the triggers the problem for
> you (you can for example check the number of TCP SYN per second to the LDAP
> port via pcap file)?
>
 If I have interpreted the tcpdump data correctly, the issue seems to hit
at around 200 connections per second, maybe less.

* can you reproduce the problem irrespective of GSSAPI/kerberos?
>
I tried to do so by manipulating the reproducer python script to use
anonymous bind (e.g. use con.bind_s('', '') instead of SASL interactive
bind). While crashing slapd reliably with two or three machines running the
script at the same time using GSSAPI auth, I could not get it to crash
using simple/anyonmous bind. It very well may have something to do with the
delays introduced by the GSSAPI handshake (e.g. DNS lookups for service/TXT
records, Kerberos communication etc.).


-- 
 Rudolph Bott - b...@sipgate.de
 Telefon: +49 (0)211-63 55 55-55
 Telefax: +49 (0)211-63 55 55-22

 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
 HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
 Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391

 www.sipgate.de - www.sipgate.co.uk

Bug#1022725: onionshare: Please provide Apparmor profiles (GHSA-jgm9-xpfj-4fq6)

[Clément Hermann]

Package: onionshare
Version: 2.5-2
Severity: wishlist

Quoting 
https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6

> Between September 26, 2021 and October 8, 2021, Radically Open
> Security conducted a penetration test of OnionShare 2.4, funded by the
> Open Technology Fund's Red Team lab. This is an issue from that
> penetration test.


> Vulnerability ID: OTF-013
> Vulnerability type: Improper Hardening
> Threat level: Low

> Description:
>
> The filesystem restriction could be hardened and should only allow for
> pre-defined subfolders.

Upstream uses Flatpak to mitigate this, which of course makes little
sense on Debian.

However, we could provide something similar using Apparmor.

Cheers,

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

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

Versions of packages onionshare depends on:
ii  onionshare-cli 2.5-2
ii  python33.10.6-1
ii  python3-pyside2.qtcore 5.15.2-2.3+b2
ii  python3-pyside2.qtwidgets  5.15.2-2.3+b2
ii  python3-qrcode 7.3.1-1

onionshare recommends no packages.

onionshare suggests no packages.

-- no debconf information

Bug#932047: lightdm: greeter session support for elogind

[Sam Hartman]

> "Yves-Alexis" == Yves-Alexis Perez  writes:

Yves-Alexis> I'm not sure other display managers handle the greeters
Yves-Alexis> the same way (running under their own uid and stuff
Yves-Alexis> like that), so I'm unsure if we can really compare
Yves-Alexis> that.

gdm does.

Bug#1022724: patch available, bug filed upstream

[Antoine Beaupré]

Control: tags -1 +patch

I have proposed the change in:

https://salsa.debian.org/go-team/packages/prometheus/-/merge_requests/5

On 2022-10-24 12:26:11, Antoine Beaupre wrote:
> ... but the gist of it is that systemd repeatedly tried to restart the
> service and failed. And retried, and retried... this would fill the
> disk not only with logs of those attempts, but it would also grow the
> WAL every time (which is a separate issue).
>
> (Normally, prometheus fails to start and doesn't mess with its data if
> the config file is broken, since 2.20:
>
> https://github.com/prometheus/prometheus/pull/7399
>
> ... but it seems this to be a courtesy that is not extended to
> rules. will file an upstream bug on that one.)

and that was filed upstream as:

https://github.com/prometheus/prometheus/issues/11486

A.

-- 
It is a miracle that curiosity survives formal education
- Albert Einstein

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi,

Le 23/10/2022 à 18:27, Clément Hermann a écrit :

Hi,

Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit :


Thanks for the quick reply! (much appreciated). I think it would be
good to get a confirmation from upstream and if possible to have
those advisories updates. E.g.
https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v 


while mentioning "affected versions < 2.4" the patched version remains
"none". this might be that the < 2.4 just reflects the point in time
when the advisory was filled. OTOH you have arguments with the v2.5
release information that they might all be fixed.

To be on safe side, explicitly confirming by upstream would be great.


Agreed. And asked upstream: 
https://github.com/onionshare/onionshare/issues/1633.


Upstream replied quickly (yay!) and confirms the known issues are fixed 
in 2.5.


Also, the detail of the vulnerable/patched versions has been updated. 
Quoting from the upstream issue:


Only affected >= 2.3 - < 2.5: CVE-2021-41867 
, CVE-2022-21691 
, CVE-2022-21695 
, CVE-2022-21696 

Only affected >= 2.2 - < 2.5: CVE-2022-21694 

Only affected >=2.0 - < 2.5: CVE-2022-21689 

Only affected >=2.0 - < 2.4: CVE-2021-41868 
 (Receive mode bug, 
fixed by changing the authentication from HTTP auth to using Client 
Auth in Tor itself)
All versions < 2.5: CVE-2022-21690 
, and possibly 
depending on the Qt version, CVE-2022-21688 



GHSA-jgm9-xpfj-4fq6 
 
is a complicated one, as a fix 
 we reduced the 
scope of access for Flatpak but you could argue that on 'native' 
Debian the whole file system, or at least the parts accessible to the 
user running OnionShare, is available not even in read-only mode. I'm 
not sure there's really a 'fix' for the deb package.


The advisories on 
https://github.com/onionshare/onionshare/security/advisories have been 
updated to reflect this.


--
nodens

Bug#1022724: systemd restarts prometheus forever, leading to disk usage death spiral

[Antoine Beaupre]

Package: prometheus
Version: 2.24.1+ds-1+b7
Severity: important

In the systemd unit provided by this Debian package (in
`debian/service`), we have this:

[Service]
Restart=on-failure

This makes it so that systemd will try to restart prometheus if it
exits for whatever reason other than exit code 0. This may be nice:
you may want it to retry if it crashes or something.

But I had a situation where I mistakenly pushed a broken config
(broken rules, more accurately) to prometheus. The gory details are in
this incident report:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40939

... but the gist of it is that systemd repeatedly tried to restart the
service and failed. And retried, and retried... this would fill the
disk not only with logs of those attempts, but it would also grow the
WAL every time (which is a separate issue).

(Normally, prometheus fails to start and doesn't mess with its data if
the config file is broken, since 2.20:

https://github.com/prometheus/prometheus/pull/7399

... but it seems this to be a courtesy that is not extended to
rules. will file an upstream bug on that one.)

Anyways, point is maybe we shouldn't restart so aggressively. Maybe
`Restart=on-abnormal` or `Restart=on-abort` would be better? That way
systemd wouldn't try to restart prometheus on syntax errors, and
correctly fail instead of retrying the service forever.

For now, I added a local override (`Restart=no`) to get through my
day, but I'd be happy to have a discussion on the best way to deal
with this.

(I first considered limiting the number of retries to something more
decent than the current "infinity", but there isn't a setting directly
for that in systemd. There *are* things like
`StartLimitIntervalSec=interval` and `StartLimitBurst=burst` but those
were not triggered by my incident, because prometheus would take about
3 seconds to startup, which is above the default 5 restarts in 10
seconds default. So maybe that's another way to fix this, ie. raise
the StartLimitIntervalSec (to, say 30 seconds) or lower the
StartLimitBurst.)

Either way, I think we can expect prometheus to return proper exit
statuses and, in those case *not* restart prometheus, so I would
propose `Restart=on-abort` instead of the `on-failure`.

(Interestingly, the Restart=on-failure was introduced explicitly to
handle situations like this:

https://salsa.debian.org/go-team/packages/prometheus/-/commit/1a61bbb194

Excerpt:

> Subject: Change systemd service Restart directive from always to on-failure
> 
> The always value is unusual, as it ignores successful exits. The
> prometheus daemon can also be requested to exit from its API, that
> should be honored.

... but it didn't take into account non-transient failures like
configuration errors.)

I'll probably followup with a MR on the package as well.

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

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

Versions of packages prometheus depends on:
ii  adduser  3.118
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u4
pn  libjs-bootstrap4 
pn  libjs-eonasdan-bootstrap-datetimepicker  
ii  libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2.1
pn  libjs-moment 
pn  libjs-moment-timezone
pn  libjs-mustache   
pn  libjs-popper.js  
pn  libjs-rickshaw   

Versions of packages prometheus recommends:
pn  prometheus-node-exporter  

prometheus suggests no packages.

Bug#1022137:

[Jeremy Bicha]

On Mon, Oct 24, 2022 at 9:45 AM Archisman Panigrahi  wrote:
> Will the patch be backported to Debian Bookworm?

Yes, it will land in Bookworm automatically in a few days.

Thank you,
Jeremy Bicha

Bug#915869: onionshare sometimes get backtrace on shutdown

[Clément Hermann]

Hi,

have you seen the same issue with recent (2.x) versions?

(asking because I never had the issue, and I'm tempted to close this as 
fixed in current testing version at least).



Cheers,

--
nodens

Bug#1022714: dvisvgm: fails to build with Ghostscript 10: undefined reference to `gs_error_names'

[Adrian Bunk]

On Mon, Oct 24, 2022 at 03:24:59PM +0200, Jonas Smedegaard wrote:
> Control: found -1 3.0-1
> 
> Quoting Jonas Smedegaard (2022-10-24 14:57:49)
> > The dvisvgm package fails to build from source when linking against
> > Ghostscript 10:
> 
> Fails same way for experimental release 3.0-1.

https://github.com/mgieseki/dvisvgm/releases

dvisvgm 3.0 Pre-release
This is a public test version of a new major dvisvgm release. It's still 
in development and some functionality might not work properly yet.
...
A new PDF handler based on mutool has been added to keep dvisvgm's PDF 
conversion functionality available after the removal of Ghostscript's 
old PDF interpreter announced for version 10.1.0.
...



Moving libgs-dev from Build-Depends to Build-Conflicts makes 3.0 build.
A new dependency on mupdf-tools is then likely required
I haven't checked whether the resulting package also works.


> - Jonas

cu
Adrian

Bug#1022544: linux-image-6.0.0-2-amd64: No more sound after upgrade to 6.0.0-2

[Daniel Serpell]

Hi,

The revert is now queued for the next 6.0.y stable:
   
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/revert-alsa-hda-fix-page-fault-in-snd_hda_codec_shutdown.patch?id=c824ee5cb2002799f113529c68f09e28a276625f

Regards,
Daniel.

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[наб]

Control: tag -1 + patch
Control: forwarded -1 
https://salsa.debian.org/manpages-team/debian-assets/-/merge_requests/1

Hi!

On Thu, Oct 13, 2022 at 04:49:33PM +0200, Holger Wansing wrote:
> Am 13. Oktober 2022 13:26:24 MESZ schrieb "наб" 
> :
> >I'd post a patch, but, well. No clue what against, given the givens.
> The dead URLs you mention have already been reported in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960597
> (but not fixed, sadly).

Added to patch message.

> If you want to help with this and provide a proper patch, that
> would be against debian-assets:
> https://salsa.debian.org/manpages-team/debian-assets/-/blob/master/faq.tmpl
Thanks, that's what I was looking for!

No wonder this was out-of-date ‒ the last commit that touched this file
was in June of 2017.

Patches attached, also posted them as an MR there.

> Holger
Best,
наб


signature.asc
Description: PGP signature

Bug#1022211: xml2rfc: Test failures with Weasyprint 57.0

[Scott Kitterman]

On Sat, 22 Oct 2022 00:01:32 -0400 Scott Kitterman  
wrote:
> Package: xml2rfc
> Version: 3.13.1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> Using FTBFS as it's the closest thing we have to an autopkgtest
> regression severity.  xml2rfc autopkgtest fails in Unstable with
> Weasyprint 57.0:
> 
> ==
> ERROR: setUpClass (__main__.PdfWriterTests)
> --
> Traceback (most recent call last):
>   File "/tmp/autopkgtest-lxc.48kx6p_4/downtmp/build.obL/src/xxx/test.py", 
line 495, in setUpClass
> cls.elements_pdfxml = xmldoc(None, bytes=elements_pdfdoc)
>   File "/usr/lib/python3/dist-packages/xml2rfc/walkpdf.py", line 96, in 
xmldoc
> return lxml.etree.fromstring(text)
>   File "src/lxml/etree.pyx", line 3254, in lxml.etree.fromstring
>   File "src/lxml/parser.pxi", line 1913, in lxml.etree._parseMemoryDocument
>   File "src/lxml/parser.pxi", line 1793, in lxml.etree._parseDoc
>   File "src/lxml/parser.pxi", line 1082, in 
lxml.etree._BaseParser._parseUnicodeDoc
>   File "src/lxml/parser.pxi", line 615, in 
lxml.etree._ParserContext._handleParseResultDoc
>   File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult
>   File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError
>   File "", line 14199
> lxml.etree.XMLSyntaxError: PCDATA invalid Char value 23, line 14199, column 
11
> 
> --
> Ran 42 tests in 21.851s
> 
> FAILED (errors=1)
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/x/xml2rfc/27394437/
log.gz
> 
> Upstream is apparently aware since (I discovered after uploading
> Weasyprint) they have recently pinned the Weasyprint dependency to
> <57.0.
> 
> I did file an issue upstream:
> 
> https://github.com/ietf-tools/xml2rfc/issues/921
> 

I narrowed down the Weasyprint commit that leads to the failure and asked for 
feedback from that upstream:

https://github.com/Kozea/WeasyPrint/issues/1752

If that doesn't prove fruitful, I am open to patching Debian's weasyprint to 
fix the issue.

Scott K

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

Bug#994151: yt-dlp: little script

[okgomdjgbmoij]

On 24/10/2022 04:57, Andres Salomon wrote:
On Mon, 29 Aug 2022 19:09:45 -0400 (EDT) Unit 193  
wrote:
 > On Mon, 01 Aug 2022 20:10:42 +0200 michel  
wrote:
 > > I fleshed out the proposal a bit more. The simplest possibillity is 
to make symlinks, of both
 > > the executable and module, to pretend they are youtube-dl and the 
module youyube_dl. This way,

 > > also python programs that load the module could work.
 > >
 > > A little bit better is this little wraper. you link the exec and 
module to it.

 > >
 > > --
 > > #!/usr/bin/python3
 > >
 > > import sys
 > > from yt_dlp import *
 > >
 > > if __name__ == "__main__":
 > >
 > > args=sys.argv.copy()
 > > args.pop(0)
 > > args=['--compat-options','youtube-dl']+args
 > >
 > > main(args)
 > > 
 > >
 > >

Thanks for the script! We still haven't seen a youtube-dl release and 
it's pretty clear the way that things are headed, so I've gone ahead and 
prepared the package for becoming replaced by yt-dlp:


https://salsa.debian.org/debian/youtube-dl/-/commits/master

Andreas & others, any thoughts/comments on this before I upload?

Thanks,
Andres

not sure what you did. To avoid confusion. Use the wrapper as the 
executable, not as the module. It doesn't work very well as a module.


"import *" in python doesn't actually import everything...

for the module directly link to yt-dlp
/usr/lib/python3/dist-packages/youtube_dl 
/usr/lib/python3/dist-packages/yt_dlp

Bug#1020691: debos should depend on systemd-resolved

[Christopher Obbard]

On Mon, 2022-10-24 at 20:00 +0700, Arnaud Rebillout wrote:
> 
> On 24/10/2022 17:34, Christopher Obbard wrote:
>  
> > I have proposed[1] to check if systemd-resolved is available at
> > runtime, to at least let users know *why* name resolution doesn't
> > work
> > inside their fakemachine over letting the user debugging it
> > themselves.
>  
> > [1]: https://github.com/go-debos/fakemachine/pull/115
> That's nice! I thought of it as well, and I was wondering if systemd-
> resolved (and possibly other services) should be listed under
> Requires= instead of Wants= (talking about
> https://github.com/go-debos/fakemachine/blob/main/machine.go#L288).
> But then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c,
> and why using Wants= is the intention. So your approach works better.

That's been merged into Fakemachine now.


> > Perhaps we should add systemd-resolved to Suggests in
> > debos/fakemachine? Adding it as a Depends/Recommends would break
> > users
> > who have some other package on their machine handling name
> > resolution.
> > 
> > @Arnaud, how does that sound?
> Well, I'm not sure for the packaging part. If fakemachine needs
> systemd-resolved to be functional, then it should be a Depends.
> That's what Depends is for.
> At a quick glance, there's no reverse dependencies of fakemachine /
> debos. So the only users that would be surprised by the change are
> the ones who installed it explicitly, so we can assume those are
> technical users and they'll find their way? But then, what if there
> are some installations on servers (think builders), and the upgrade
> breaks the name resolution? Not a nice surprise.
> OTOH, an error message saying that "/lib/systemd/systemd-resolved is
> missing", plus a Suggests: systemd-resolved, both together gives a
> strong hint regarding what should be done. It sounds sensible as
> well.
> Sorry, that's not really a clear answer :) 
> Best,

I'm more leaning on just adding it as a direct Dependency to the Debos
package and seeing if anyone moans...

Bug#1022712: [Pkg-zfsonlinux-devel] Bug#1022712: zfsutils-linux: new trim code is broken

[M. Zhou]

Control: tags -1 +pending

Thanks for the patch. It is pending in git repo.


On Mon, 2022-10-24 at 14:44 +0200, наб wrote:
> Package: zfsutils-linux
> Version: 2.1.6-2
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> Please apply the attached patch that fixes trim.
> 
> In particular, the breakage is in the use of "local",
> but I've fixed up all the other issues I saw there
> 
> See patch message for details.
> 
> Best,
> наб
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: x32 (x86_64)
> Foreign Architectures: amd64, i386
> 
> Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 zfsutils-linux depends on:
> ii  init-system-helpers  1.65.2
> ii  libblkid1    2.38.1-1.1+b1
> ii  libc6    2.35-3
> ii  libnvpair3linux  2.1.6-2
> ii  libuuid1 2.38.1-1.1+b1
> ii  libuutil3linux   2.1.6-2
> ii  libzfs4linux 2.1.6-2
> ii  libzpool5linux   2.1.6-2
> ii  python3  3.10.6-1
> 
> Versions of packages zfsutils-linux recommends:
> ii  lsb-base   11.4
> ii  sysvinit-utils [lsb-base]  3.05-6
> ii  zfs-dkms [zfs-modules] 2.1.6-2
> ii  zfs-zed    2.1.6-2
> 
> Versions of packages zfsutils-linux suggests:
> pn  nfs-kernel-server   
> pn  samba-common-bin    
> pn  zfs-initramfs | zfs-dracut  
> 
> -- Configuration Files:
> /etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'
> 
> -- no debconf information
> ___
> Pkg-zfsonlinux-devel mailing list
> pkg-zfsonlinux-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel

Bug#1022723: remote-logon-service: FTBFS on usr-merged systems

[Simon Chopin]

Package: remote-logon-service
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch
X-Debbugs-Cc: scho...@ubuntu.com

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/1001_usr-bin-merge.patch: Fix build on usr-merged buildds
(LP: #1994041)

We've noticed the failure at least in our last test rebuild, but it
might have been failing longer than that.

Thanks for considering the patch.


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

Kernel: Linux 5.19.0-21-generic (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru remote-logon-service-1.0.2.90/debian/patches/1001_usr-bin-merge.patch 
remote-logon-service-1.0.2.90/debian/patches/1001_usr-bin-merge.patch
--- remote-logon-service-1.0.2.90/debian/patches/1001_usr-bin-merge.patch   
1970-01-01 01:00:00.0 +0100
+++ remote-logon-service-1.0.2.90/debian/patches/1001_usr-bin-merge.patch   
2022-10-24 16:06:59.0 +0200
@@ -0,0 +1,33 @@
+From e8fe4c3f2c8f3c0a3159f4e56a5dfbcc8d4f5fcd Mon Sep 17 00:00:00 2001
+From: Simon Chopin 
+Date: Mon, 24 Oct 2022 16:27:59 +0200
+Subject: [PATCH] tests/server-test: fix the tests on usr-merged systems
+
+The testsuite is failing on Ubuntu builders as they operate with /bin a
+symlink to /usr/bin. As a result, depending on how you resolve it, `ls`
+can either be `/bin/ls` or `/usr/bin/ls`. Since Debian also seems to
+transition to such a setup, it might be wise to simply relax the tests.
+---
+ tests/server-test.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+Forwarded: yes, https://github.com/ArcticaProject/remote-logon-service/pull/4
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/remote-logon-service/+bug/1994041
+
+diff --git a/tests/server-test.c b/tests/server-test.c
+index 9b55246..d339499 100644
+--- a/tests/server-test.c
 b/tests/server-test.c
+@@ -107,7 +107,8 @@ test_uccs_exec (void)
+   g_assert(server != NULL);
+   g_assert(g_strcmp0(server->name, "My Server") == 0);
+   g_assert(g_strcmp0(server->uri, "http://my.domain.com;) == 0);
+-  g_assert(g_strcmp0(UCCS_SERVER(server)->exec, "/bin/ls") == 0);
++  g_assert(g_strcmp0(UCCS_SERVER(server)->exec, "/bin/ls") == 0 ||
++   g_strcmp0(UCCS_SERVER(server)->exec, "/usr/bin/ls") == 
0);
+ 
+   g_object_unref(server);
+   g_key_file_unref(keyfile);
+-- 
+2.37.2
+
diff -Nru remote-logon-service-1.0.2.90/debian/patches/series 
remote-logon-service-1.0.2.90/debian/patches/series
--- remote-logon-service-1.0.2.90/debian/patches/series 2019-02-06 
14:39:19.0 +0100
+++ remote-logon-service-1.0.2.90/debian/patches/series 2022-10-24 
16:06:59.0 +0200
@@ -1 +1,2 @@
 0001_src-uccs-server.c-Inject-another-artificial-nm_state.patch
+1001_usr-bin-merge.patch

Bug#1021703: slapd crashes when too many clients connect in a short period of time.

[Harald Welte]

some miscellaneous questions that come to my mind after reading the bug report

* if the slapd is hanging, what does a 'strace' on the PID of the slapd process 
tell you?
* what is the rate of new client connections the triggers the problem for you 
(you can for example check the number of TCP SYN per second to the LDAP port 
via pcap file)?
* can you reproduce the problem irrespective of GSSAPI/kerberos?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1022722: tftp-hpa: missing versioned Breaks+Replaces: tftp (<< 0.17-23.1)

[Andreas Beckmann]

Package: tftp-hpa
Version: 5.2+20150808-1.3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

Since tftp was turned into a transitional package in 0.17-23.1, tftp-hpa
needs to Breaks+Replaces the older versions to ensure smooth upgrades
and prevent partial upgrades as is currently possible with the
unversioned Replaces: ftfp.

Andreas

Bug#1022721: aptly: New upstream version 1.5.0 available

[Sebastien Delafond]

Source: aptly
Version: 1.4.0+ds1-4
Severity: wishlist

1.5.0 is available, however it depends on cavaliergopher/grab
(https://github.com/cavaliergopher/grab) which is not packaged in
Debian; the corresponding RFP is here:

  https://bugs.debian.org/1022720

Cheers,

-- 
Seb

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-proposed-updates'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1022137:

[Archisman Panigrahi]

Will the patch be backported to Debian Bookworm?

Bug#1022720: RFP: golang-github-cavaliergophier-grab-dev -- Go package for downloading files from the internet

[Sebastien Delafond]

Package: wnpp
Severity: wishlist

* Package name: golang-github-cavaliergophier-grab-dev
  Version : 3.0.1
  Upstream Author : Ryan Armstrong
* URL : https://github.com/cavaliergopher/grab
* License : BSD-3
  Programming Lang: go
  Description : Go package for downloading files from the internet

Grab is a Go package for downloading files from the internet with the
following rad features:

  - monitor download progress concurrently
  - auto-resume incomplete downloads
  - guess filename from content header or URL path
  - safely cancel downloads using context.Context
  - validate downloads using checksums
  - download batches of files concurrently
  - apply rate limiters

This is a required dependency for aptly 1.5.

Bug#1022719: fonts-texgyre-math: missing Breaks: fonts-texgyre (<< 20180621-4)

[Andreas Beckmann]

Package: fonts-texgyre-math
Version: 20180621-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

There is a Breaks: tex-gyre (<< 20180621-4) that should probably have
targeted fonts-texgyre instead.


Andreas

Bug#1022711: subversion: "svn --non-interactive status -v svn-md5" started by emacs hangs

[Vincent Lefevre]

BTW, independently, svn should also stop going upward once a
working copy has been reached (I suppose that this led to the
issue with emacs).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1022704: ccache: broken in cross-architecture chroot

[Raphaël Halimi]

Le 24/10/2022 à 14:31, Joel Rosdahl a écrit :

Can you give me more some detailed hints on how I can reproduce the issue?



Install pbuilder on an amd64 host and prepare an i386 chroot. Then, try 
to build a package in it (I was rebuilding timidity). It should hang 
during the configure phase.


I have a complicated setup with several chroots, custom pbuilderrc, sudo 
snippets to let some environment variables pass, etc etc; but, from 
memory, this should work :


sudo pbuilder create --architecture i386

apt-get source somepackage (preferably something using autotools)
cd somepackage
sudo pdebuild --architecture i386

Regards,

--
Raphaël Halimi

Bug#1022714: dvisvgm: fails to build with Ghostscript 10: undefined reference to `gs_error_names'

[Jonas Smedegaard]

Control: found -1 3.0-1

Quoting Jonas Smedegaard (2022-10-24 14:57:49)
> The dvisvgm package fails to build from source when linking against
> Ghostscript 10:

Fails same way for experimental release 3.0-1.

- Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1022718: O: ghostscript -- interpreter for the PostScript language and for PDF

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have orphaned the ghostscript package, due to lack of time.

The package description is:
 GPL Ghostscript is used for PostScript/PDF preview and printing.
 Usually as a back-end to a program such as ghostview,
 it can display PostScript and PDF documents in an X11 environment.
 .
 Furthermore, it can render PostScript and PDF files as graphics
 to be printed on non-PostScript printers.
 Supported printers include common dot-matrix, inkjet and laser models.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNWkGAACgkQLHwxRsGg
ASEOfg//dBOTdLYoi/EjQq04vpCB2KxEjGpx2fv0fVXhOFFDNF9c2wz+j9t9pC5r
Kbam5dsXiMJoJH09PGe+fn32R7MBAfzBljt1aXyYmpF6j7qc00fLdyGdwG6BfpVb
NDFxS4K7sNslnCMb8dudS9WpHRaEVR9HGaJVJ2HzFVnBQaCpIZ18ZtQe6PaUQtIL
OqoNmfNlIUtghXH3LN1KfJzD3glxsQdBwLf8/mJYLWT9ymTA/euF5ZdHQrgzIWNg
+KXhym4KWciFJ2dkrkI6DF4AffuHrnS2KihXoIw1dZ8dZMJxUhdVLBuTp08sR3dd
rj2qwnJu6W369Xz9DtNTbbJ+f8xRMn9G5SGSPgD8pxj5KefSjlh5mf/FHshyjfgi
BvELjSxEFiweHbaV2wNqcbSEiGkgUO14b/Xk7ZzkRQmUbjhkqTdURQujDhQ1Mxay
Qs6fqJTXfjeiurecFDML346jYP0WnXgDHmq1D4ee3THbQ4SupdOCZhXkSOFgDJyK
ISHC0e1Svcd0yZvoNt0sHEkO9Hrmk1aaOBsVnjv5XP149e1r+tFFO3TqbWQIZYE3
WcsWZmSdfv/hLoXaAdVi9FyzAGa4PLcxYxOqV/iB1MEubSOm1GKmprjgBJrvl2vA
ZNCi18VlyY7UwomGtCoqiqihEMeOzhMkNkGqYYRkQyk2RE1+aGg=
=oVaf
-END PGP SIGNATURE-

Bug#1014017: soundmodem: Fails to build with HID support

[Alan Crosswell]

Yeah I don't know that ignoring the device code would be much of a problem.
It's not like it searches available devices to see which one to use; the
specific device to use is specified.

On Sun, Oct 23, 2022 at 3:10 PM Daniele Forsi  wrote:

> Hello Alan,
>
> I committed your patch to configure.ac in a branch and I think that we
> should merge it to master:
> https://salsa.debian.org/debian-hamradio-team/soundmodem/-/tree/hidraw
>
> I didn't commit your patch to ptt.c yet.
> What happens if we drop the check for hiddevinfo.product for C-Media
> entirely?
>
> You changed the test to work with your hardware, which is fine, but it
> seems that there are many more CM108s out there (I have one with ID
> 0d8c:013c).
> I'm copying the list from https://usb-ids.gowdy.us/read/UD/0d8c so it
> is archived with this bug report.
>
> Id Name
> 0001 Audio Device
> 0002 Composite Device
> 0003 Sound Device
> 0004 CM6631A Audio Processor
> 0005 Blue Snowball
> 0006 Storm HP-USB500 5.1 Headset
> 000c Audio Adapter
> 000d Composite Device
> 000e Audio Adapter (Planet UP-100, Genius G-Talk)
> 0012
> 0014 Audio Adapter (Unitek Y-247A)
> 001f CM108 Audio Controller
> 0029
> 0102 CM106 Like Sound Device
> 0103 CM102-A+/102S+ Audio Controller
> 0104 CM103+ Audio Controller
> 0105 CM108 Audio Controller
> 0107 CM108 Audio Controller
> 010f CM108 Audio Controller
> 0115 CM108 Audio Controller
> 0134
> 0139 Multimedia Headset [Gigaware by Ignition L.P.]
> 013c CM108 Audio Controller
> 0201 CM6501
> 5000 Mass Storage Controller
> 5200 Mass Storage Controller(0D8C,5200)
> b213 USB Phone CM109 (aka CT2000,VPT1000)
>
> --
> 73 de IU5HKX Daniele
>

Bug#1022705: unplanned transition: ghostscript

[Jonas Smedegaard]

Quoting Emilio Pozuelo Monfort (2022-10-24 13:41:51)
> Have you tested if the rdeps build fine against this new version?

I had not (shame on me!).

I have now tested these packages (thanks to `build-rdeps libgs-dev`):
dvisvgm
gimp
libspectre
roger-router
xdvik-ja
xfig

Of those, dvisvgm fails to build (both 2.14-1 and experimental 3.0-1),
and I have filed bug#1022714 about that issue.


> Also, it would have been nice to disentangle the -common rename from the 
> SONAME 
> bump.

Yes, I agree that would have been more elegant.

On a related note, I have decided to orphan Ghostscript.  Obviously I
will help get through the current mess that I started.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1022717: O: pantalaimon -- E2EE aware proxy daemon for matrix clients

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: d...@jones.dk

The package was orphaned with version 0.10.4-2 without filing an orphan 
bug. Doing that now.

Bug#1022716: O: p8-platform -- Pulse-Eight's platform support library

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: bal...@balintreczey.hu

The package was orphaned with version 2.1.0.1+dfsg1-4 without filing an 
orphan bug. Doing that now.

Bug#1022715: O: libtrio -- printf and string functions

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: bal...@balintreczey.hu

The package was orphaned with version 1.16+dfsg1-4 without filing a O 
bug. Doing that now.

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 24/10/2022 17:34, Christopher Obbard wrote:

I have proposed[1] to check if systemd-resolved is available at
runtime, to at least let users know *why* name resolution doesn't work
inside their fakemachine over letting the user debugging it themselves.
[1]:https://github.com/go-debos/fakemachine/pull/115


That's nice! I thought of it as well, and I was wondering if 
systemd-resolved (and possibly other services) should be listed under 
Requires= instead of Wants= (talking about 
https://github.com/go-debos/fakemachine/blob/main/machine.go#L288). But 
then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c, and why 
using Wants= is the intention. So your approach works better.




Perhaps we should add systemd-resolved to Suggests in
debos/fakemachine? Adding it as a Depends/Recommends would break users
who have some other package on their machine handling name resolution.

@Arnaud, how does that sound?


Well, I'm not sure for the packaging part. If fakemachine needs 
systemd-resolved to be functional, then it should be a Depends. That's 
what Depends is for.


At a quick glance, there's no reverse dependencies of fakemachine / 
debos. So the only users that would be surprised by the change are the 
ones who installed it explicitly, so we can assume those are technical 
users and they'll find their way? But then, what if there are some 
installations on servers (think builders), and the upgrade breaks the 
name resolution? Not a nice surprise.


OTOH, an error message saying that "/lib/systemd/systemd-resolved is 
missing", plus a Suggests: systemd-resolved, both together gives a 
strong hint regarding what should be done. It sounds sensible as well.


Sorry, that's not really a clear answer :)

Best,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1022714: dvisvgm: fails to build with Ghostscript 10: undefined reference to `gs_error_names'

[Jonas Smedegaard]

Package: dvisvgm
Version: 2.14-1
Severity: important
Tags: ftbfs upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The dvisvgm package fails to build from source when linking against
Ghostscript 10:

libtool: link: g++ -Wall -Wnon-virtual-dtor -I../libs/clipper 
-I../libs/variant/include -I/usr/include/freetype2 -I/usr/include/libpng16 -g 
-O2 -ffile-prefix-map=/build/dvisvgm-2.14=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-mismatched-tags -Wl,-z -Wl,relro -o dvisvgm 
dvisvgm.o  ./.libs/libdvisvgm.a ../libs/clipper/libclipper.a -lfreetype 
../libs/ff-woff/libfontforge.a -lwoff2enc -lbrotlienc -lcrypto -lz -lxxhash 
-lpotrace -lgs -lkpathsea
/usr/bin/ld: ./.libs/libdvisvgm.a(Ghostscript.o): in function 
`Ghostscript::error_name(int)':
./src/Ghostscript.cpp:382: undefined reference to `gs_error_names'

It seems to me that dvisvgm attempts to extract private information from
the libgs library, which is no longer provided since release 10 of
Ghostscript.

I have filed this bugreport only with severity important, due to my
uncoordinated release into unstable of Ghostscript 10 (see bug#1022705)
but arguably severity should be higher...


Kind regards, Jonas


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNWi8YACgkQLHwxRsGg
ASGQYg/+J/9+2hKyu+zmSKlosvj1iu7TxdALoQeNHoWXP6JQdFKxn0t7WPEDfqKV
pEB5zmQHBmfhVONiUNh8I8wb38LMUwVBV8Ak2TffGo0ti+Xeuel2q8mQDMyEbyqV
YDAksx24otN/jybjPsLAwUICmtW6xbz7FF9KJ4daJjFAo+jjkn0ErkkQIButM5G0
8QrzHvqWo2gmr89Kh9rOj9/hC+a0vCdlVA2bGgkf/UaIqDIsXsjheJXuZzCvOcwm
WxwdOhv2zLJ7W45pw8jR272KRvynSKl6tUWJrCcEjz9rm9ptY/dEHt6EvQqtZg4Z
ApkrZm4ysyT0eLpELTL759xi91i6yDrQB1+/e9YVJMVlCSJs1tFIUcy3QO/5hsiZ
rT9SBsQDFTVMe6tep9usfrzpTjzkSUSDm22ktiBJUSb/TtUqC9rOVX4XvAUXn8f9
FqZFHDRWaMNTgHnqA87DJ5mf8hcVdu0L8V6pAKBhqbpBwbwc8prwcYE/LgqcczpW
YN+0Zm7vSCq6pI3uL4vI0r0cGWAxpp7iY1+/obdkTbTIUsUlSu5zbwvCKAAmudWe
feMxN42OiNvho0alaua/5jboVWR/tM9SkevStVgzOAZSAneAKuj5kzRAk0IznvsL
k8IlOjN72VtvJh6rH4PdqirODRq9vSS9N05I8gupmaB0q41uowc=
=HKql
-END PGP SIGNATURE-

Bug#1022574: [Pkg-samba-maint] Bug#1022574: samba: Kerberos 22H2 Samba problem in Debian stable | Backports Version or Stable Update?

[Michael Tokarev]

24.10.2022 15:47, Samuel Wolf wrote:


Is the backports Samba package also monitored for security issues?


It is not. Just like bullseye samba package.

For security and general bugfix support, we basically rely on upstream
samba team. Once a security update is out, I tend to make it available
to debian almost available in terms of unstable/testing and backports.
Debian bullseye/stable version only receives "easily backportable"
fixes.

/mjt

Bug#1022711: subversion: "svn --non-interactive status -v svn-md5" started by emacs hangs

[Vincent Lefevre]

Control: retitle -1 svn tries to read a directory on a different filesystem and 
hangs
Control: severity -1 grave
Control: tags -1 security

On 2022-10-24 14:21:53 +0200, Vincent Lefevre wrote:
> I have a file called "svn-md5". When I want to open this file with
> emacs (including "emacs -Q"), emacs runs
> 
>   svn --non-interactive status -v svn-md5
> 
> (I don't know why), but "svn --non-interactive status -v svn-md5"
> hangs, so that I can't read the file.

Reproducible with just a "svn info". The reason is that svn tries
to read "/home/.svn", which belongs to another filesystem and
possibly to another user. In addition to the hang, which affects
other applications like emacs, this is potentially a security issue.
svn should stop going up in the hierarchy once the mount point (or
home directory?) has been reached, or at least once the owner of the
directory changes.

FYI, git doesn't have such an issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1022713: O: gplaycli -- Google Play downloader command line interface

[Bastian Germann]

Package: wnpp

The package was orphaned by the 3.29+dfsg-4 without filing an oprhan bug.

Bug#1022574: samba: Kerberos 22H2 Samba problem in Debian stable | Backports Version or Stable Update?

[Samuel Wolf]

> Yes it is possible, more, it is trivial to _patch_ it. But it is not that easy
> to make the resulting binaries into the archive.
>
> Tomorrow expected another security update for samba, - if that affects 
> bullseye
> too, I hope to get all fixes together for the next update.

Thank you Michael.

> This is a preferred way regardless.  4.13 is not supported upstream anymore,
> and all our support of 4.13 in debian is even more limited than that.  More.
> 4.16 in bpo is much more accurate.

Is the backports Samba package also monitored for security issues?

Thanks.

Bug#1022712: zfsutils-linux: new trim code is broken

[наб]

Package: zfsutils-linux
Version: 2.1.6-2
Severity: normal
Tags: patch

Dear Maintainer,

Please apply the attached patch that fixes trim.

In particular, the breakage is in the use of "local",
but I've fixed up all the other issues I saw there

See patch message for details.

Best,
наб

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 zfsutils-linux depends on:
ii  init-system-helpers  1.65.2
ii  libblkid12.38.1-1.1+b1
ii  libc62.35-3
ii  libnvpair3linux  2.1.6-2
ii  libuuid1 2.38.1-1.1+b1
ii  libuutil3linux   2.1.6-2
ii  libzfs4linux 2.1.6-2
ii  libzpool5linux   2.1.6-2
ii  python3  3.10.6-1

Versions of packages zfsutils-linux recommends:
ii  lsb-base   11.4
ii  sysvinit-utils [lsb-base]  3.05-6
ii  zfs-dkms [zfs-modules] 2.1.6-2
ii  zfs-zed2.1.6-2

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  

-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'

-- no debconf information
From ad741bc8bc4635c73ddbcc5b5ef9bb4f1ca8351f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Mon, 24 Oct 2022 14:28:39 +0200
Subject: [PATCH] trim: clean up, fix

This does:
  * fix get_transp() on non-bash
  * re-indent of the code from #990745
  * fix terminology: it's pool
  * remove -e: I originally actually fixed -e,
but it turns out literally every bit that could fail
is already either || : or wasn't by accident (like in the #990745 code)
  * simplify get_transp() and explain why we do it instead of matching nvme path
  * use remove -L from the data we feed to lsblk, zpool w/o -L is measurably faster
  * pipe the devices into while read to match rest of code
  * use read -r in main loop
  * match the userprop with case/esac instead of if tree
  * shellcheck-clean the script
---
 .../zfsutils-linux/usr/lib/zfs-linux/trim | 74 ---
 1 file changed, 32 insertions(+), 42 deletions(-)

diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
index 91d00bb0c..341a2fbbd 100755
--- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
+++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
@@ -1,4 +1,4 @@
-#!/bin/sh -eu
+#!/bin/sh -u
 
 # directly exit successfully when zfs module is not loaded
 if ! [ -d /sys/module/zfs ]; then
@@ -14,66 +14,56 @@ get_property () {
 	# since they're not available on pools https://github.com/openzfs/zfs/pull/11680
 	# TODO: use zpool user-defined property when such feature is available.
 	pool="$1"
-	zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 2>/dev/null || return 1
+	zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 2>/dev/null
 }
 
 trim_if_not_already_trimming () {
 	pool="$1"
 	if ! zpool status "${pool}" | grep -q "trimming"; then
-		# Ignore errors (i.e. HDD pools),
-		# and continue with trimming other pools.
-		zpool trim "${pool}" || true
+		# This will error on HDD-only pools: doesn't matter
+		zpool trim "${pool}"
 	fi
 }
 
+# Walk up the kernel parent names:
+# this will catch devices from LVM 
 get_transp () {
-local dev="$1"
-local par_dev="$dev"
-local pd
-while true; do
-pd=$(lsblk -dnr -o PKNAME "$par_dev")
-if [ "$?" -ne 0 ]; then
-return $?
-fi
-if [ -z "$pd" ]; then
-break
-else
-par_dev="/dev/$pd"
-fi
-done
-lsblk -dnr -o TRAN "$par_dev"
+	dev="$1"
+	while pd="$(lsblk -dnr -o PKNAME "$dev")"; do
+		if [ -z "$pd" ]; then
+			break
+		else
+			dev="/dev/$pd"
+		fi
+	done
+	lsblk -dnr -o TRAN "$dev"
 }
 
-zpool_is_nvme_only () {
-	zpool=$1
-	# get a list of devices attached to the specified zpool
-for x in $(zpool list -vHPL "${zpool}" |\
-awk -F'\t' '{if($2 ~ /^\/dev\//) print $2}'); do
-if [ "$(get_transp $x)" != "nvme" ]; then
-return 1
-fi
-done
+pool_is_nvme_only () {
+	pool="$1"
+	# get a list of devices attached to the specified pool
+	zpool list -vHP "${pool}" | \
+		awk -F'\t' '$2 ~ "^/dev/" {print $2}' | \
+	while read -r dev
+	do
+		[ "$(get_transp "$dev")" = "nvme" ] || return
+	done
 }
 
 # TRIM all healthy pools that are not already trimming as per their 

Bug#1022704: ccache: broken in cross-architecture chroot

[Joel Rosdahl]

On Mon, Oct 24, 2022, at 13:40, Raphaël Halimi wrote:
> I also tested it, it's broken too.

Thanks.

Can you give me more some detailed hints on how I can reproduce the issue?

Regards,
Joel

Bug#1022240: fixed in ipmiutil 3.1.8-3

[patrice . duroux]

Hi,

Also there is a small bug in the line:
* * * * *  root  /usr/bin/ipmiutil wdt -r > /usr/bin/ipmiutil wdt.lastrun 2&>1

It should be:
* * * * *  root  /usr/bin/ipmiutil wdt -r > /usr/bin/ipmiutil wdt.lastrun 2>&1

This is currently creating a file (/root/1).

Thanks,
Patrice

Bug#1022711: subversion: "svn --non-interactive status -v svn-md5" started by emacs hangs

[Vincent Lefevre]

Package: subversion
Version: 1.14.1-3+deb11u1
Severity: important

I have a file called "svn-md5". When I want to open this file with
emacs (including "emacs -Q"), emacs runs

  svn --non-interactive status -v svn-md5

(I don't know why), but "svn --non-interactive status -v svn-md5"
hangs, so that I can't read the file.

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

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

Versions of packages subversion depends on:
ii  libapr1  1.7.0-6+deb11u1
ii  libaprutil1  1.6.1-5
ii  libc62.31-13+deb11u5
ii  libsvn1  1.14.1-3+deb11u1

subversion recommends no packages.

Versions of packages subversion suggests:
pn  db5.3-util  
pn  libapache2-mod-svn  
ii  patch   2.7.6-7
ii  subversion-tools1.14.1-3+deb11u1

-- debconf-show failed

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)