Bug#1062105: should not block migration to testing
control: severity -1 normal Thanks for reporting! In the Android Tools case, the shared libs and packages that use them are packaged together, often from the same source package, so I can't see why we'd need special versions of it. And when we need to, we can use strictly versioned depends, so it should be fine. I'm going to set the bug to normal for now.
Bug#1070346: how to activate the module "pcspkr" (PC speaker)
Hi, JFTR, I am not a Debian developer or Debian package maintainer. I am the upstream maintainer of the beep software. On 2024-05-04 00:53 +, Bjarni Ingi Gislason wrote: > Package: beep > Version: 1.4.9-1.1 > Severity: normal > > Dear Maintainer, > >* What led up to the situation? > >No sound with "beep -e $(tty)" Probably unrelated to your question: Is there any particular reason why you give beep a specific device and avoid the autodetection? > -.- > > I (as root) do not get any sound from > > 1) tput bel > > 2) beep -e $(tty) What kind of hardware is this? AMD64 and Realtek ALC C887-VD... no-name desktop PC from parts, or maybe some PC laptop, or even some Apple Intel CPU Macbook, iMac, Mac Pro? Do you get any PC speaker sound ever? Modern (as in post-2005 to post-2015) desktop PCs often come with the PC speaker header not connected, which saves a few cents in bill of material and assembly. > [root503]:~# beep --debug -e $(tty) > > beep: Verbose: evdev driver_detect 0x563df6280700 /dev/tty2 > beep: Verbose: b-lib: opened /dev/tty2 as 3 > beep: Verbose: evdev: 3 does not implement EV_SND API > beep: Verbose: console driver_detect 0x563df62806a0 /dev/tty2 > beep: Verbose: b-lib: opened /dev/tty2 as 4 > beep: Verbose: beep: using driver 0x563df62806a0 (name=console, fd=4, > dev=/dev/tty2) beep: Verbose: 1 times 200 ms beeps (100 ms delay > between, 0 ms delay after) @ 440 Hz beep: Verbose: console > driver_begin_tone 0x563df62806a0 440 beep: Verbose: console > driver_end_tone 0x563df62806a0 beep: Verbose: console driver_end_tone > 0x563df62806a0 beep: Verbose: console driver_fini 0x563df62806a0 Everything looking good so far. So the userspace until the kernel works as intended, and the problem appears be inside the kernel or the hardware, probably in the hardware configuration, be it the software configurable or the hardware configurable part. > -.- > > lsmod: > > pcspkr 12288 0 > > -.- > > /etc/modprobe.d/pcspkr-beep.conf contains > > alias platform:pcspkr pcspkr > > -.- > > [root565]:/etc/modprobe.d# modprobe --first-time pcspkr > modprobe: ERROR: could not insert 'pcspkr': Module already in > kernel > > -.- > > grep -F pcspkr /lib/modules/* : > > 6.6.15-amd64/modules.dep:kernel/drivers/input/misc/pcspkr.ko.xz: > 6.6.15-amd64/modules.order:kernel/drivers/input/misc/pcspkr.ko > 6.6.15-amd64/modules.alias:alias platform:pcspkr pcspkr > 6.7.12-amd64/modules.dep:kernel/drivers/input/misc/pcspkr.ko.xz: > 6.7.12-amd64/modules.order:kernel/drivers/input/misc/pcspkr.ko > 6.7.12-amd64/modules.alias:alias platform:pcspkr pcspkr The kernel looks good as well. > -.-. > > From /boot: > > config-6.6.15-amd64 > config-6.7.12-amd64 > grub > initrd.img-6.6.15-amd64 > initrd.img-6.7.12-amd64 > System.map-6.6.15-amd64 > System.map-6.7.12-amd64 > vmlinuz-6.6.15-amd64 > vmlinuz-6.7.12-amd64 That... gives an idea about the kernel versions installed, but beep should work with any of them. > -.- > > alsamixer -c 1 shows for "beep" > > Card: HDA ATI SB > Chip: Realtek ALC C887-VD > > Beep [dB gain: 4.50, 4.50] Positve dB values look a bit weird, but least it is not -65dB. Have you tried moving that value around a bit? Sometimes, changing a value has some side effect. > -.- > > There is no '/proc/sys/dev/input' directory. How did you come up with the /proc/sys/dev/input path? That path does not exist either on my Fedora development system nor on the Debian VM which I use for testing software on. > -- System Information: > Debian Release: trixie/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT) Weird. The installed kernels are 6.6.15 and 6.7.12, but you are running 6.1.0. beep should work with any kernel from the last 20 years (at least), though, so this should not matter to this issue. > Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 > (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to > /usr/bin/dash Init: sysvinit (via /sbin/init) > > Versions of packages beep depends on: > ii libc6 2.37-19 > > beep recommends no packages. > > beep suggests no packages. > > -- no debconf information Thanks for not sending the report in Icelandic. I would not have understood anything :-) Nothing stands out here as the obvious problem you need to solve to get PC beeper sound. I have found a thread regarding the Realtek ALC887 front panel audio at https://bbs.archlinux.org/viewtopic.php?id=275507 which suggests some hda-verb command line to get the front panel audio to produce sound. Perhaps the PC speaker sound needs some additional sound chip massaging on that chipset as well? While I hope my remarks are helpful, I fear they are not very much. Regards, Uli
Bug#1070386: ITP: pass-import - MediaWiki API client in Python
Package: wnpp Severity: wishlist Owner: Hans-Christoph Steiner * Package name: remarkable Version : 1.87+git20240504.e8cc99d Upstream Author : Jamie McGowan * URL : https://github.com/roddhjav/pass-import * License : BSD-2 GPL-2+ LGPL-2.1+ MIT Programming Lang: Python Package source : https://salsa.debian.org/python-team/packages/remarkable Description: A free fully featured Markdown editor. Remarkable is a free fully featured Markdown editor. It has a syntax like Github flavoured Markdown. With it you can write Markdown and view the changes as you make them in the live preview window. You can export your files to a variety of formats. There are multiple styles available along with extensive configuration options so you can set it up exactly how you like. Also on: AUR: https://aur.archlinux.org/packages/remarkable Gentoo: https://github.com/gentoo/gentoo/tree/824b749/app-editors/remarkable
Bug#1068722: aapt: symbol lookup error: libandroidfw.so.0: undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi
Package: aapt Version: 1:10.0.0+r36-10 Severity: important Dear Maintainer, When adb/fastboot is installed from bookworm-backports, those pull in android-libziparchive 1:33.0.3-2~bpo12+1, which does not have the symbols that bookworm's aapt needs to run: $ aapt aapt: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libandroidfw.so.0: undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi/ I guess the solution would be to also backport android-platform-frameworks-base? -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aapt depends on: ii android-libaapt1:10.0.0+r36-10 ii android-libandroidfw 1:10.0.0+r36-10 ii android-libbase1:33.0.3-2~bpo12+1 ii android-liblog 1:33.0.3-2~bpo12+1 ii android-libutils 1:33.0.3-2~bpo12+1 ii android-libziparchive 1:33.0.3-2~bpo12+1 ii libc6 2.36-9+deb12u4 ii libexpat1 2.5.0-1 ii libgcc-s1 13.1.0-9 ii libpng16-161.6.39-2 ii libprotobuf-lite32 3.21.12-3 ii libstdc++6 13.1.0-9 aapt recommends no packages. aapt suggests no packages. -- no debconf information
Bug#1067708: RFS: xz-utils/5.6.1-0.1 [NMU] -- XZ-format compression utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xz-utils": * Package name : xz-utils Version : 5.6.1-0.1 Upstream contact : x...@tukaani.org * URL : https://xz.tukaani.org/xz-utils/ * License : FSFUL, none, noderivs, permissive-nowarranty, LGPL-2.1+, CC-BY-SA-4.0, PD, GPL-3.0-or-later-WITH-Autoconf-exception-macro, 0BSD, GPL-2+, FSFULLR * Vcs : https://salsa.debian.org/debian/xz-utils Section : utils The source builds the following binary packages: liblzma5 - XZ-format compression library liblzma5-udeb - XZ-format compression library xz-utils - XZ-format compression utilities xzdec - XZ-format compression utilities - tiny decompressors liblzma-dev - XZ-format compression library - development files liblzma-doc - XZ-format compression library - API documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xz-utils/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xz-utils/xz-utils_5.6.1-0.1.dsc Changes since the last upload: xz-utils (5.6.1-0.1) unstable; urgency=medium . * Non-maintainer upload. * Import 5.6.1 * Remove both patches, fixed in upstream. This new version fixes a valgrind bug with liblzma that outputs a false warning that could affect existing testing frameworks for packages that test with valgrind requiring a specific output. This release only fixes bugs. Regards, -- Hans Jansen
Bug#1067151: xen-utils-common: vif-openvswitch ignores MTU
Hi Aleksi, Thanks for the report. I actually ran into the same situation recently, wanting to set up a PPPoE connection from within a Xen domU, also using openvswitch as bridge. On 19/03/2024 12:21, Aleksi Suhonen wrote: > Package: src:xen > Version: 4.17.3+10-g091466ba55-1~deb12u1 > Severity: wishlist > > I wasn't sure if this script comes from Debian or Xen or somewhere else, > so I thought it safest to report it here. These scripts/vif-* files are located in tools/hotplug/Linux in the Xen source tree, we ship them as such in the Debian package. So, yes, changes to them should first go upstream. However, it's perfectly fine to have a discussion here, so we can figure out what the right changes should be. > /etc/xen/scripts/vif-bridge handles MTU settings in the vif, but the > otherwise similar /etc/xen/scripts/vif-openvswitch does not. I added it > in, here's the diff-c and the full fixed file is also attached. > > *** vif-openvswitch.orig2024-03-19 11:53:13.0 +0200 > --- vif-openvswitch 2024-03-19 11:56:17.0 +0200 > *** > *** 89,94 > --- 89,95 >add|online) >check_tools >setup_virtual_bridge_port $dev > + set_mtu "$bridge" "$dev" "$type_if" >add_to_openvswitch $dev >;; Ah, interesting. I had some difficulties getting it to work back then. But, when putting the set_mtu line back like this, it also gives me the desired outcome now! My use case is about setting up a PPPoE connection from a Xen domU over vlan 6. I want an mtu of 1500 for the traffic inside the PPPoE connection, so I need mtu 1508 for the connection between the PPPoE client in the domU -> openvswitch in the dom0 -> physical interface -> switchports -> ISP NTU device. For some reason I had troubles to get the vifX.Y interface, as seen inside dom0 set to mtu 1508. It seemed not to have any effect (using ip link set mtu dev ), or, openvswitch kept resetting it back to 1500 all the time. When I would use ovs-vsctl set interface mtu_request= instead, it actually sticked. That's what I remember. I just did some more testing, and I cannot really reproduce that situation... :| I can also just use ip link in the dom0 now. Interesting, but good, since it would mean that we can indeed just (re)use that set_mtu function! :) I'm still curious what the problem was when I tried earlier... Maybe anyone else reading this knows more? Are you familiar with the process of sending patches upstream? Otherwise we (Debian Xen team) can assist with that. Regards, Hans
Bug#1036559: (no subject)
control: fixed 1036559 3.4.0~a1-7
Bug#1065612: O: google-android-m2repository-installer -- Google Android support m2 repository
Package: wnpp Severity: normal X-Debbugs-Cc: google-android-m2repository-instal...@packages.debian.org Control: affects -1 + src:google-android-m2repository-installer I intend to orphan the google-android-m2repository-installer package. None of the current maintainers have an interest in it, and it is non-free. The package description is: This package will download the Google Android Support Library repository and create a Debian package. This is structured as a maven m2 repository of all the versions of the library. . The Android Support Library offers a number of features that are not built into the framework. These libraries offer backward-compatible versions of new features, provide useful UI elements that are not included in the framework, and provide a range of utilities that apps can draw on. . WARNING: Installing this Debian package causes android_m2repository_r35.zip to be downloaded from dl.google.com and/or from other suggested mirrors. The End User License Agreement of this binary package is available at developer.android.com.
Bug#1063270: The "64bits time_t transition" in Debian/Xen
ary package libxenmisc4.17). Coincidentally, we are currently preparing the upload to switch from Xen 4.17 to Xen 4.18 in Debian unstable. So, if we just go ahead with doing that, and make sure it's built in the new way already... then... tada.wav! We just immediately have the correct libxenmisc4.18, and no other (stable lib) packages have to be renamed. Hans
Bug#1061521: + XPS 13 9343
Hi Antoine, On 2/3/24 17:16, Antoine wrote: > On 1/20/24 21:26, Hans de Goede wrote: >> Can you try adding "i8042.dumbkbd=1" to your kernel commandline? >> >> The next question is if the keyboard will still actually >> work after suspend/resume with "i8042.dumbkbd=1". If it >> stays in the list, but no longer works > > Hi, thanks a lot for taking into account our hardware, > just a supplementary feedback: > > In my case (Dell XPS 13 9343/i5-5200U): > - Dell Inc. XPS 13 9343/0TM99H, BIOS A19 12/24/2018 > - Linux version 6.6.13-1 (2024-01-20) > > commandline with `i8042.dumbkbd=1` fixes the issue, > with capslock functional but without led > + as a side note, hibernate doesn't trigger any issue > > (before getting informed of and testing `i8042.dumbkbd=1`) > I had attached logs before/after suspend against 6.6.11 and 6.6.13 : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061521#30 > > I remain at your disposal for any further infos/testing The issue of the kbd on some Dell XPS models no longer working after a suspend/resume cycle should be fixed by these 2 patches which are on their way to Linus' tree: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus=683cd8259a9b883a51973511f860976db2550a6e https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus=9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 Regards, Hans
Bug#1061933: apktool: path towards upgrading to newest upstream version
Package: apktool Version: 2.7.0+dfsg-7 Control: tags -1 help newcomer Upstream changed the Gradle setup to use Kotlin files (e.g. build.gradle.kts) rather than the Groovy files (e.g. build.gradle). I spoke with upstream about the changes to the buildsystem, they said that it was about switching to Kotlin and otherwise the buildsystem is basically the same. I think the easiest path to upgrading apktool to 2.9.3 will be to patch in the old build.gradle files and patch out the build.gradle.kts files. If someone manages to get a new enough Kotlin and Gradle into Debian, then the build.gradle.kts files should just work.
Bug#1060985: prewikka: FTBFS: ModuleNotFoundError: No module named 'six'
tags 1060985 patch thanks Looks like the package has a missing build dependency on python3-six. Builds successfully with the attached patch. -- mvh / best regards Hans Joachim Desserud http://desserud.orgdiff --git a/debian/control b/debian/control index 403eaea..59746b8 100644 --- a/debian/control +++ b/debian/control @@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13), python3-setuptools, python3-babel, python3-lesscpy, +python3-six, gettext, Standards-Version: 4.6.0 Homepage: https://www.prelude-siem.org/
Bug#1036968: included in 6.6.9-1
For the record, the module was included starting in 6.6.9-1: $ grep -i CS35L41 /boot/config-6.6.9-amd64 CONFIG_SND_HDA_SCODEC_CS35L41=m CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_LIB=m CONFIG_SND_SOC_CS35L41=m CONFIG_SND_SOC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_I2C=m
Bug#1036968: fixed
Control: fixed 1036968 6.6.9-1 Control: fixed 1036968 6.6.11-1 With 6.6.11-1, the headphone jack insert detection is now working when running on bookworm.
Bug#1060433: bookworm-pu: package apktool/2.7.0+dfsg-6+deb12u1
Package: release.debian.org
Control: affects -1 + src:apktool
X-Debbugs-Cc: apkt...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal
[ Reason ]
This fixes CVE-2024-21633.
[ Impact ]
If this is not included, bookworm users will be vulnerable to attacks
when analyzing malicious APKs with apktool. These attacks will be
able to write/overwrite any file that the user has permission to.
[ Tests ]
The existing autopkgtest covers code/functionality that is patched.
[ Risks ]
It is a very simple fix and problems should be rapidly visible via the
tests. Worst case, apktool will decompile a file to the wrong
location, but will tell the user the path.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Include upstream patch to 2.7.0 to fix CVE-2024-21633.
[ Other info ]
Upstream reached out to help get this updated in Debian, so they
deemed it quite important to fix. This is the first time upstream has
communicated with the Debian maintainers about this package, IIRC.
diff -Nru apktool-2.7.0+dfsg/debian/changelog
apktool-2.7.0+dfsg/debian/changelog
--- apktool-2.7.0+dfsg/debian/changelog 2023-03-21 09:41:45.0 +0100
+++ apktool-2.7.0+dfsg/debian/changelog 2024-01-10 20:08:30.0 +0100
@@ -1,3 +1,11 @@
+apktool (2.7.0+dfsg-6+deb12u1) bookworm; urgency=medium
+
+ * Team upload.
+ * CVE-2024-21633: Prevent arbitrary file writes with malicious resource
+names. (Closes: #1060013)
+
+ -- Hans-Christoph Steiner Wed, 10 Jan 2024 20:08:30 +0100
+
apktool (2.7.0+dfsg-6) unstable; urgency=medium
* only test APK build on arches with aapt that can do it
diff -Nru
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
---
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
1970-01-01 01:00:00.0 +0100
+++
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
2024-01-10 20:07:42.0 +0100
@@ -0,0 +1,92 @@
+From 087f89ebc0dd87e74c8945f074f25b51b195cb83 Mon Sep 17 00:00:00 2001
+From: Connor Tumbleson
+Date: Tue, 2 Jan 2024 06:11:03 -0500
+Forwarded:
https://github.com/iBotPeaches/Apktool/commit/087f89ebc0dd87e74c8945f074f25b51b195cb83
+Subject: [PATCH 1/1] Prevent arbitrary file writes with malicious resource
+ names. (#3484)
+
+CVE-2024-21633
+
+* refactor: rename sanitize function
+
+* fix: expose getDir
+
+* fix: safe handling of untrusted resource names
+
+ - fixes: GHSA-2hqv-2xv4-5h5w
+
+* test: sample file for GHSA-2hqv-2xv4-5h5w
+
+* refactor: avoid detection of absolute files for resource check
+
+* chore: enable info mode on gradle
+
+* test: skip test on windows
+
+* chore: debug windows handling
+
+* fix: normalize entry with file separators
+
+* fix: normalize filepath after cleansing
+
+* chore: Android paths are not OS specific
+
+* refactor: use java.nio for path traversal checking
+
+* chore: align path separator on Windows for Zip files
+
+* chore: rework towards basic directory traversal
+
+* chore: remove '--info' on build.yml
+---
+ .../java/brut/androlib/res/decoder/ResFileDecoder.java| 8
+ brut.j.util/src/main/java/brut/util/BrutIO.java | 7 +++
+ 2 files changed, 15 insertions(+)
+
+diff --git
a/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
b/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
+index a3174411..16ad35f9 100644
+---
a/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
b/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
+@@ -25,6 +25,7 @@ import brut.androlib.res.data.value.ResFileValue;
+ import brut.directory.DirUtil;
+ import brut.directory.Directory;
+ import brut.directory.DirectoryException;
++import brut.util.BrutIO;
+
+ import java.io.*;
+ import java.util.Map;
+@@ -47,6 +48,13 @@ public class ResFileDecoder {
+ String outResName = res.getFilePath();
+ String typeName = res.getResSpec().getType().getName();
+
++if (BrutIO.detectPossibleDirectoryTraversal(outResName)) {
++outResName = inFileName;
++LOGGER.warning(String.format(
++"Potentially malicious file path: %s, using instead %s",
res.getFilePath(), outResName
++));
++}
++
+ String ext = null;
+ String outFileName;
+ int extPos = inFileName.lastIndexOf(".");
+diff --git a/brut.j.util/src/main/java/brut/util/BrutIO.java
b/brut.j.util/src/main/java/brut/uti
Bug#1060013: fixed in 2.7.0+dfsg-7
Control: fixed -1 2.7.0+dfsg-7 Control: tags -1 fixed fixed-upstream security pending This has been updated with key help from upstream: https://github.com/iBotPeaches/Apktool/commit/087f89ebc0dd87e74c8945f074f25b51b195cb83
Bug#1060062: bootcd: can not exclude folders with files bigger than 4GB inside
Package: bootcd Version: 6.6.5 Severity: important Dear Maintainer, when trying to ignore a folder with files bigger than 4GB, I get the following error message: -- snip - bootcdwrite -m -y -c */root/bootcdwrite.conf* --- Checking for possible Problems --- --- Cleanup --- --- WARNING --- S_NEED_COMPRESS > S_VAR (113717304 > 72959976) To enable compression there must be much space (S_VAR) available in /var/spool/bootcd to hold extra space for compression. We need double as much space (S_NEED_COMPRESS) as will be copied to CD. but the space available is not enough i (-y) --- Sizes in KByte (du -klsc ) --- NOT_TO_CD = . . . . . . . . . . . . . . . . . . . . . . . . . . . 24176524 CD_ALL (SRCDISK v NOT_TO_CD) = . . . . . . . . . . . . . . . . . . 81035176 Needed = CD_ALL - NOT_TO_CD . . . . . . . . . . . . . . . . . . . 56858652 DVD+ (4.7 billion bytes) = . . . . . . . . . . . . . . . . . . . . 470 because of compression perhaps double size = . . . . . . . . . . . 940 --- WARNING --- SRCDISK does not fit on DVD (Needed > DVD) You can exclude files/dirs in NOT_TO_CD in bootcdwrite.conf. You can try to ignore this problem, if you only want an iso image. i (-y) VAR = . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72959976 OK - enough space in /var/spool/bootcd (Needed <= VAR) --- Building Modifications --- --- do function extra_changes --- --- Creating CD-Image --- ERROR: ia premature exit of unchecked output: <10+0 records in 10+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 0.0209077 s, 502 MB/s mkfs.fat 4.2 (2021-01-31) /usr/bin/bootcdwrite: 477: eval: MKISOFS: parameter not set> - snap -- I could not find any related information of this, either in th elogfiles, nor in the internet. For me, it looks like a bug. Another thing (maybe the same reason): Folders with a space in the name, like "VirtualBox VMs", can not be recognized. Even when masking the name, like "VirtualBox\ VM" it recognizes two folders: "VirtualBox\" and "VM". The trailing slash is beeing ignored. I am happy for any help. Best regards Hans -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bootcd depends on: ii busybox1:1.35.0-4+b3 ii cpio 2.13+dfsg-7.1 ii dosfstools 4.2-1 ii e2fsprogs 1.47.0-2 ii fdisk 2.38.1-5+b1 ii file 1:5.44-3 ii genisoimage9:1.1.11-3.4 ii grub-efi-amd64-bin 2.06-13+deb12u1 ii initramfs-tools0.142 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii lsb-base 11.6 ii rsync 3.2.7-1 ii shellia5.7.6 ii syslinux 3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 ii syslinux-common3:6.04~git20190206.bf6db5b4+dfsg1-3 ii sysvinit-utils [lsb-base] 3.06-4 ii util-linux 2.38.1-5+b1 ii uuid-runtime 2.38.1-5+b1 ii xorriso1.5.4-4 Versions of packages bootcd recommends: ii wodim 9:1.1.11-3.4 Versions of packages bootcd suggests: pn aufs-tools ii discover2.1.2-10 pn elilo ii ssh 1:9.2p1-2+deb12u2 -- debconf-show failed
Bug#1060052: cifs-utils: Copy file from same cifs mount to cifs mount --> kernel NULL pointer derefernce
I can confirm that reported issue does not occur with previous kernel: 6.1.0-16-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) x86_64 GNU/Linux On Fri, 5 Jan 2024 13:15:14 +0300 Michael Tokarev wrote: > Control: severity -1 normal > Control: merge 1060005 -1 > > FWIW, this is kernel bug, not cifs-utils bug, - guess it's 6.1.0-17 regression. > > /mjt > >
Bug#1053246: Security support ended for Xen 4.14 in Bullseye
Package: debian-security-support Version: 1:11+2023.05.04 Severity: normal Hi, Upstream security support for Xen 4.14 has ended recently. This also means that security support for Debian Bullseye has ended. The complexity of the software involved does not really allow for anyone else than the upstream developers, with a deep understanding of the inner workings of the hypervisor code, to apply/backport new patches. For security-support-ended.deb11, this could be a line like: xen 4.14.6-1 2023-09-21 https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support Note: This 4.14.6-1 package version is not visible for bullseye yet, right now, in the archive. It was submitted for the bullseye point release, and has just been accepted into it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053177 Thanks, Hans
Bug#1053221: a new CVE popped up
Control: retitle -1 bookworm-pu: package python-git/3.1.30-1+deb12u2
A new CVE and fix popped up right after I filled this. The patch is also from
upstream, and also has been shipped by the Debian LTS team.
diff --git a/debian/changelog b/debian/changelog
index dfaadbc..7d8905e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,24 @@
+python-git (3.1.30-1+deb12u2) stable; urgency=high
+
+ * Team upload.
+ * Fix CVE-2023-41040: Blind local file inclusion.
+
+ -- Hans-Christoph Steiner Fri, 29 Sep 2023 20:43:31 +0200
+
+python-git (3.1.30-1+deb12u1) stable; urgency=medium
+
+ [ Hans-Christoph Steiner ]
+ * Team upload.
+ * CVE-2023-40267: Include patch from Ubuntu (Closes: #1043503)
+
+ [ Fabian Toepfer ]
+ * SECURITY UPDATE: RCE due to improper user input validation
+- debian/patches/CVE-2023-40267.patch: Block insecure non-multi
+ options in clone/clone_from.
+- CVE-2023-40267
+
+ -- Hans-Christoph Steiner Fri, 29 Sep 2023 16:18:03 +0200
+
python-git (3.1.30-1) unstable; urgency=medium
[ Debian Janitor ]
diff --git a/debian/patches/CVE-2023-40267.patch b/debian/patches/CVE-2023-40267.patch
new file mode 100644
index 000..b733fb2
--- /dev/null
+++ b/debian/patches/CVE-2023-40267.patch
@@ -0,0 +1,60 @@
+From 5c59e0d63da6180db8a0b349f0ad36fef42aceed Mon Sep 17 00:00:00 2001
+From: Sylvain Beucler
+Date: Mon, 10 Jul 2023 16:10:10 +0200
+Subject: [PATCH] Block insecure non-multi options in clone/clone_from
+ Follow-up to #1521
+
+---
+ git/repo/base.py | 2 ++
+ test/test_repo.py | 24 +++-
+ 2 files changed, 25 insertions(+), 1 deletion(-)
+
+--- python-git-3.1.30.orig/git/repo/base.py
python-git-3.1.30/git/repo/base.py
+@@ -1188,6 +1188,8 @@ class Repo(object):
+
+ if not allow_unsafe_protocols:
+ Git.check_unsafe_protocols(str(url))
++if not allow_unsafe_options:
++Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options)
+ if not allow_unsafe_options and multi_options:
+ Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options)
+
+--- python-git-3.1.30.orig/test/test_repo.py
python-git-3.1.30/test/test_repo.py
+@@ -281,6 +281,17 @@ class TestRepo(TestBase):
+ rw_repo.clone(tmp_dir, multi_options=[unsafe_option])
+ assert not tmp_file.exists()
+
++unsafe_options = [
++{"upload-pack": f"touch {tmp_file}"},
++{"u": f"touch {tmp_file}"},
++{"config": "protocol.ext.allow=always"},
++{"c": "protocol.ext.allow=always"},
++]
++for unsafe_option in unsafe_options:
++with self.assertRaises(UnsafeOptionError):
++rw_repo.clone(tmp_dir, **unsafe_option)
++assert not tmp_file.exists()
++
+ @with_rw_repo("HEAD")
+ def test_clone_unsafe_options_allowed(self, rw_repo):
+ tmp_dir = pathlib.Path(tempfile.mkdtemp())
+@@ -337,6 +348,17 @@ class TestRepo(TestBase):
+ Repo.clone_from(rw_repo.working_dir, tmp_dir, multi_options=[unsafe_option])
+ assert not tmp_file.exists()
+
++unsafe_options = [
++{"upload-pack": f"touch {tmp_file}"},
++{"u": f"touch {tmp_file}"},
++{"config": "protocol.ext.allow=always"},
++{"c": "protocol.ext.allow=always"},
++]
++for unsafe_option in unsafe_options:
++with self.assertRaises(UnsafeOptionError):
++Repo.clone_from(rw_repo.working_dir, tmp_dir, **unsafe_option)
++assert not tmp_file.exists()
++
+ @with_rw_repo("HEAD")
+ def test_clone_from_unsafe_options_allowed(self, rw_repo):
+ tmp_dir = pathlib.Path(tempfile.mkdtemp())
diff --git a/debian/patches/CVE-2023-41040.patch b/debian/patches/CVE-2023-41040.patch
new file mode 100644
index 000..2e194af
--- /dev/null
+++ b/debian/patches/CVE-2023-41040.patch
@@ -0,0 +1,69 @@
+From: Facundo Tuesca
+Date: Tue, 5 Sep 2023 09:51:50 +0200
+Subject: Fix CVE-2023-41040
+
+This change adds a check during reference resolving to see if it
+contains an up-level reference ('..'). If it does, it raises an
+exception.
+
+This fixes CVE-2023-41040, which allows an attacker to access files
+outside the repository's directory.
+
+Origin: https://github.com/gitpython-developers/GitPython/commit/64ebb9fcdfbe48d5d61141a557691fd91f1e88d6
+Origin: https://github.com/gitpython-developers/GitPython/commit/65b8c6a2ccacdf26e751cd3bc3c5a7c9e5796b56
+Bug: https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-cwvm-v4w8-q58c
+Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-41040
+---
+ git/refs/symbolic.py | 2 ++
+ git/test/test
Bug#1053221: bookworm-pu: package python-git/3.1.30-1+deb12u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal
[ Reason ]
Fixes CVE-2023-40267 which can lead to RCE in specific configurations
when a malicious URL is fed to GitPython. For example, this affects
the F-Droid buildserver, which accepts git URLs from users via merge
requests.
[ Impact ]
Everything should work as before, except for unsafe URLs will now
throw an exception. That can be overridden using function arguments.
[ Tests ]
Sylvain Beucler fixed this first in Debian LTS buster. Canonical then created
and shipped a patch, and includes additions to the existing test suite to cover
the issues in CVE-2023-40267. It is covered by the package's autopkgtest. I
also ran the test suite locally on a bookworm machine.
[ Risks ]
Risks are minimal since this patch has been shipped by Debian LTS and Ubuntu,
and the original code has been released by upstream for a while now. The
patch touches most of the core functionality, so bugs could break things.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
The patch is a refactoring of what upstream developed and shipped for
CVE-2023-40267.diff --git a/debian/changelog b/debian/changelog
index dfaadbc..9b9ce45 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+python-git (3.1.30-1+deb12u1) stable; urgency=medium
+
+ [ Hans-Christoph Steiner ]
+ * Team upload.
+ * CVE-2023-40267: Include patch from Ubuntu (Closes: #1043503)
+
+ [ Fabian Toepfer ]
+ * SECURITY UPDATE: RCE due to improper user input validation
+- debian/patches/CVE-2023-40267.patch: Block insecure non-multi
+ options in clone/clone_from.
+- CVE-2023-40267
+
+ -- Hans-Christoph Steiner Fri, 29 Sep 2023 16:18:03 +0200
+
python-git (3.1.30-1) unstable; urgency=medium
[ Debian Janitor ]
diff --git a/debian/patches/CVE-2023-40267.patch b/debian/patches/CVE-2023-40267.patch
new file mode 100644
index 000..b733fb2
--- /dev/null
+++ b/debian/patches/CVE-2023-40267.patch
@@ -0,0 +1,60 @@
+From 5c59e0d63da6180db8a0b349f0ad36fef42aceed Mon Sep 17 00:00:00 2001
+From: Sylvain Beucler
+Date: Mon, 10 Jul 2023 16:10:10 +0200
+Subject: [PATCH] Block insecure non-multi options in clone/clone_from
+ Follow-up to #1521
+
+---
+ git/repo/base.py | 2 ++
+ test/test_repo.py | 24 +++-
+ 2 files changed, 25 insertions(+), 1 deletion(-)
+
+--- python-git-3.1.30.orig/git/repo/base.py
python-git-3.1.30/git/repo/base.py
+@@ -1188,6 +1188,8 @@ class Repo(object):
+
+ if not allow_unsafe_protocols:
+ Git.check_unsafe_protocols(str(url))
++if not allow_unsafe_options:
++Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options)
+ if not allow_unsafe_options and multi_options:
+ Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options)
+
+--- python-git-3.1.30.orig/test/test_repo.py
python-git-3.1.30/test/test_repo.py
+@@ -281,6 +281,17 @@ class TestRepo(TestBase):
+ rw_repo.clone(tmp_dir, multi_options=[unsafe_option])
+ assert not tmp_file.exists()
+
++unsafe_options = [
++{"upload-pack": f"touch {tmp_file}"},
++{"u": f"touch {tmp_file}"},
++{"config": "protocol.ext.allow=always"},
++{"c": "protocol.ext.allow=always"},
++]
++for unsafe_option in unsafe_options:
++with self.assertRaises(UnsafeOptionError):
++rw_repo.clone(tmp_dir, **unsafe_option)
++assert not tmp_file.exists()
++
+ @with_rw_repo("HEAD")
+ def test_clone_unsafe_options_allowed(self, rw_repo):
+ tmp_dir = pathlib.Path(tempfile.mkdtemp())
+@@ -337,6 +348,17 @@ class TestRepo(TestBase):
+ Repo.clone_from(rw_repo.working_dir, tmp_dir, multi_options=[unsafe_option])
+ assert not tmp_file.exists()
+
++unsafe_options = [
++{"upload-pack": f"touch {tmp_file}"},
++{"u": f"touch {tmp_file}"},
++{"config": "protocol.ext.allow=always"},
++{"c": "protocol.ext.allow=always"},
++]
++for unsafe_option in unsafe_options:
++with self.assertRaises(UnsafeOptionError):
++Repo.clone_from(rw_repo.working_dir, tmp_dir, **unsafe_option)
++assert not tmp_file.exists()
++
+ @with_rw_repo("HEAD")
+ def test_clone_from_unsafe_options_allowed(self, rw_repo):
+ tmp_dir = pathlib.Path(tempfile.mkdtemp())
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..325d25b
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2023-40267.patch
Bug#1043503: bullseye
I'm putting together 3.1.14-1+deb11u1 now for bullseye.
Bug#1053177: bullseye-pu: package xen/4.14.6-1
Hi Adam,
On 9/28/23 19:09, Adam D. Barratt wrote:
> On Thu, 2023-09-28 at 18:27 +0200, Hans van Kranenburg wrote:
>> Xen 4.14 support (and security support) has ended upstream. The
>> upstream
>> stable branch for version 4.14 is frozen now, and a final maintenance
>> release version 4.14.6 has been released. We'd like to put this final
>> update into Bullseye, to properly finish the Xen work for Bullseye.
>> Also, a few security fixes (regarding CVE-2023-20593 CVE-2023-20569
>> CVE-2022-40982) are included.
>>
>> https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
>>
>
> --- xen-4.14.5+94-ge49571868d/automation/scripts/qemu-smoke-x86-64.sh
> 2023-03-21 13:07:44.0 +0100
> +++ xen-4.14.6/automation/scripts/qemu-smoke-x86-64.sh2023-08-07
> 14:11:14.0 +0200
> @@ -5,11 +5,6 @@
> # variant should be either pv or pvh
> variant=$1
>
> -# Install QEMU
> -export DEBIAN_FRONTENT=noninteractive
> -apt-get -qy update
> -apt-get -qy install qemu-system-x86
>
> I realise this is an upstream change, but is it really intended to stop
> installing QEMU in a QEMU smoke test?
This particular change can be seen as the contents of the following
commit, in this case for 4.14:
8<
commit 98ec8ad2eeb96eb9d4b7f9bfd1ef3a994c63af17
Refs: RELEASE-4.14.5-103-g98ec8ad2eeb9
Author: Michal Orzel
AuthorDate: Wed Apr 26 09:29:45 2023 +0200
Commit: Jan Beulich
CommitDate: Wed Apr 26 09:29:45 2023 +0200
automation: Remove installation of packages from test scripts
Now, when these packages are already installed in the respective
containers, we can remove them from the test scripts.
Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
master commit: 72cfe1c3ad1fae95f4f0ac51dbdd6838264fdd7f
master date: 2022-12-09 14:55:33 -0800
>8
This is part of a change to the upstream test machinery. The commit that
it's picked from (the 72cfe1c3ad1 thing) lockstep follows a previous
change to the development / master branch:
8<
commit 1ed7da301020ee1e16177cb3d9caa817f195a59a
Author: Michal Orzel
Date: Thu Nov 17 17:16:42 2022 +0100
automation: Install packages required by tests in containers
Installation of additional packages from the test scripts when running
the tests has some drawbacks. It is slower than cloning containers
and can
fail due to some network issues (apparently it often happens on x86
rackspace). This patch is adding the packages required by the tests
to be
installed when building the containers.
>From qemu-alpine-x86_64.sh into debian:stretch:
- cpio,
- busybox-static.
>From qemu-smoke-*-{arm,arm64}.sh into debian:unstable-arm64v8:
- u-boot-qemu,
- u-boot-tools,
- device-tree-compiler,
- curl,
- cpio,
- busybox-static.
The follow-up patch will remove installation of these packages from the
test scripts. This is done in order not to break the CI in-between.
Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
>8
The Xen Project OSSTest machinery is used to run testing for the current
development version of Xen, as well as for the stable branch lines that
are still under active support.
After building/compiling the source code, all kinds of test scenarios
are executed, comprising tests for different virtualization modes, or
different kinds of functionality, but also different kinds of actual
hardware. AIUI, wanting to be able to do all of this quickly boils down
to a 'feet in the mud' situation, which involves automating interaction
with PDUs to be able to physically cut off power from a misbehaving
piece of server hardware, or, capturing actual serial console cable
output. I can understand that, at least for practical reasons, there is
no desire to duplicate/replicate all of this for each supported Xen version.
AIUI, The Xen source tree contains code/scripts to help setting up the
test cases, as well as to be able to run them. For the first part, the
current development code is used (the master branch), and for the second
part, well, whatever is in a branch line needs to be able to behave
correctly in that environment.
This is the reason why we can find the change with title "automation:
Install packages required by tests in containers" only once, committed
to the master branch at the time the change took place, and why similar
but possibly different variations on "automation: Remove installation of
packages from test scripts" do exist in various other branches, such as
stable-4.17 and stable-4.14 etc.
Also, note that for Debian, we don't do anything with this part of the
upstream source tree, or, at least, I mean, changes in there must not
cause changes in the actual debs that we ship.
Thanks for the question, it was a fun small exe
Bug#1043503: fixed in 3.1.36-1 (sid/trixie) and 2.1.11-1+deb10u1 (buster)
Looks like it is fixed in Ubuntu: https://changelogs.ubuntu.com/changelogs/pool/universe/p/python-git/python-git_3.1.30-1ubuntu0.23.04.1/changelog
Bug#1043503: fixed in 3.1.36-1 (sid/trixie) and 2.1.11-1+deb10u1 (buster)
I uploaded the latest upstream version to unstable to fix it there and in trixie. beuc uploaded 2.1.11-1+deb10u1 to buster LTS to fix it in buster. That leaves bullseye and bookworm. Anyone have any time or plans to handle those? I tried a quick cherry-pick test on the bullseye and bookworm versions and I wasn't able to get it going quickly. I wonder if it would be easiest to port beuc's patches to 3.1.14-1 (bullseye) and 3.1.30-1 (bookworm).
Bug#1051862: (Debian) Bug#1051862: server flooded with xen_mc_flush warnings with xen 4.17 + linux 6.1
Hi Radoslav, Thanks for your report... Hi Juergen, Boris and xen-devel, At Debian, we got the report below. (Also at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051862) This hardware, with only Xen and Dom0 running is hitting the failed multicall warning and logging in arch/x86/xen/multicalls.c. Can you help advise what we can do to further debug this issue? Since this looks like pretty low level Xen/hardware stuff, I'd rather ask upstream for directions first. If needed the Debian Xen Team can assist the end user with the debugging process. Thanks, More reply inline... On 9/13/23 20:12, Radoslav Bodó wrote: > Package: xen-system-amd64 > Version: 4.17.1+2-gb773c48e36-1 > Severity: important > > Hello, > > after upgrade from Bullseye to Bookworm one of our dom0's > became unusable due to logs/system being continuously flooded > with warnings from arch/x86/xen/multicalls.c:102 xen_mc_flush, and the > system become unusable. > > The issue starts at some point where system services starts to come up, > but nothing very special is on that box (dom0, nftables, fail2ban, > prometheus-node-exporter, 3x domU). We have tried to disable all domU's > and fail2ban as the name of the process would suggest, but issue is > still present. We have tried also some other elaboration but none of > them have helped so far: > > * the issue arise when xen 4.17 + linux >= 6.1 is booted > * xen + bookworm-backports linux-image-6.4.0-0.deb12.2-amd64 have same isuue > * without xen hypervisor, linux 6.1 runs just fine > * systemrescue cd boot and xfs_repair rootfs did not helped > * memtest seem to be fine running for hours Thanks for already trying out all these combinations. > As a workaround we have booted xen 4.17 + linux 5.10.0-25 (5.10.191-1) > and the system is running fine as for last few months. > > Hardware: > * Dell PowerEdge R750xs > * 2x Intel Xeon Silver 4310 2.1G > * 256GB RAM > * PERC H755 Adapter, 12x 18TB HDDs I have a few quick additional questions already: 1. For clarification.. From your text, I understand that only this one single server is showing the problem after the Debian version upgrade. Does this mean that this is the only server you have running with exactly this combination of hardware (and BIOS version, CPU microcode etc etc)? Or, is there another one with same hardware which does not show the problem? 2. Can you reply with the output of 'xl dmesg' when the problem happens? Or, if the system gets unusable too quick, do you have a serial console connection to capture the output? 3. To confirm... I understand that there are many of these messages. Since you pasted only one, does that mean that all of them look exactly the same, with "1 of 1 multicall(s) failed: cpu 10" "call 1: op=1 arg=[a1a9eb10] result=-22"? Or are there variations? If so, can you reply with a few different ones? Since this very much looks like an issue of Xen related code where the Xen hypervisor, dom0 kernel and hardware has to work together correctly, (and not a Debian packaging problem) I'm already asking upstream for advice about what we should/could do next, instead of trying to make a guess myself. Thanks, Hans > Any help, advice or bug confirmation would be appreciated > > Best regards > bodik > > > (log also in attachment) > > ``` > kernel: [ 99.762402] WARNING: CPU: 10 PID: 1301 at > arch/x86/xen/multicalls.c:102 xen_mc_flush+0x196/0x220 > kernel: [ 99.762598] Modules linked in: nvme_fabrics nvme_core bridge > xen_acpi_processor xen_gntdev stp llc xen_evtchn xenfs xen_privcmd > binfmt_misc intel_rapl_msr ext4 intel_rapl_common crc16 > intel_uncore_frequency_common mbcache ipmi_ssif jbd2 nfit libnvdimm > ghash_clmulni_intel sha512_ssse3 sha512_generic aesni_intel acpi_ipmi > nft_ct crypto_simd cryptd mei_me mgag200 ipmi_si iTCO_wdt intel_pmc_bxt > ipmi_devintf drm_shmem_helper dell_smbios nft_masq iTCO_vendor_support > isst_if_mbox_pci drm_kms_helper isst_if_mmio dcdbas mei intel_vsec > isst_if_common dell_wmi_descriptor wmi_bmof watchdog pcspkr > intel_pch_thermal ipmi_msghandler i2c_algo_bit acpi_power_meter button > nft_nat joydev evdev sg nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 > nf_defrag_ipv4 nf_tables nfnetlink drm fuse loop efi_pstore configfs > ip_tables x_tables autofs4 xfs libcrc32c crc32c_generic hid_generic > usbhid hid dm_mod sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif > crct10dif_generic ahci libahci xhci_pci libata xhci_hcd > kernel: [ 99.762633] megaraid_sas tg3 crct10dif_pclmul > crct10dif_common crc32_pclmul crc32c_intel bnxt_en usbcore scsi_mod > i2c_i801 libphy i2c_smbus usb_common scsi_common wmi > kernel: [ 99.764765] CPU: 10 PID: 1301 Comm: python3 Tainted: G > W 6.1.0-12-amd64 #1 Debian 6.1.52-1 >
Bug#1035623: fix included in V_9_4_P1
The b7afd8a4ecaca commit is now included in the upstream tag V_9_4_P1 from three weeks ago. Is there a timeline for that being uploaded to sid? This is a blocker for OpenSSL work (TLS Encrypted ClientHello integration with OpenSSL and Debian).
Bug#1043984: chocolate-doom: Homepage url fails, needs www
Source: chocolate-doom Version: 3.0.1+really3.0.0+git1548-1 Severity: minor Dear Maintainer, I noticed the hompage url in control fails to load Homepage: https://chocolate-doom.org/ Looks like it needs explicit www to load https://www.chocolate-doom.org/ Not sure if this is a recent change or not. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#894892: libkscreenlocker5: unable to unlock locked screen ("unlocking failed")
Package: libkscreenlocker5 Version: 5.27.5-2 Followup-For: Bug #894892 Dear Maintainer, tried with a fresh user, but no success. Verified and confirm, that "loginctl unlock-session XX" as normal user is unlockung the session. So it looks like this command might not be sent correctly from KDE. Tested on two computers, both running debian bookworm, actual packages, same package status. Both computers got this issue. NOT tested on my 32-bit system yet. I will tell more, if I got news. Thanks for any help. Best regards Hans -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkscreenlocker5 depends on: ii kio5.103.0-1 ii kpackagetool5 5.103.0-1 ii libc6 2.36-9+deb12u1 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configqml5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5declarative5 5.103.0-1 ii libkf5globalaccel-bin 5.103.0-1 ii libkf5globalaccel5 5.103.0-1 ii libkf5i18n55.103.0-1 ii libkf5idletime55.103.0-2 ii libkf5kiocore5 5.103.0-1 ii libkf5notifications5 5.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libkf5screendpms8 4:5.27.5-2 ii libkf5waylandclient5 4:5.103.0-1 ii libkf5windowsystem55.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii liblayershellqtinterface5 5.27.5-2 ii libpam0g 1.5.2-6 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus55.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5x11extras5 5.15.8-2 ii libstdc++6 12.2.0-14 ii libwayland-client0 1.21.0-1 ii libwayland-server0 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb11.15-1 ii libxi6 2:1.8-1+b1 ii psmisc 23.6-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.27.5-2 libkscreenlocker5 suggests no packages. -- debconf-show failed
Bug#894892: libkscreenlocker5: The file "/usr/lib/x86_64-linux-gnu/libexec/kcheckpass" is NOT existent in the stable package.
Package: libkscreenlocker5 Followup-For: Bug #894892 Dear Maintainer, I discovered, that in the bookworm repo in the package libscreenlocker5, the mentioned file "kcheckpass" is not existent. Thus the above workaround does not work. I also tried to manually copy the file from bullseye with no success and suppose, kcheckpass from bullseye is incompatible with bookworm. Please repack the lib with the missing file. Thank you very much. Best regards Hans -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkscreenlocker5 depends on: ii kio5.103.0-1 ii kpackagetool5 5.103.0-1 ii libc6 2.36-9+deb12u1 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configqml5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5declarative5 5.103.0-1 ii libkf5globalaccel-bin 5.103.0-1 ii libkf5globalaccel5 5.103.0-1 ii libkf5i18n55.103.0-1 ii libkf5idletime55.103.0-2 ii libkf5kiocore5 5.103.0-1 ii libkf5notifications5 5.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libkf5screendpms8 4:5.27.5-2 ii libkf5waylandclient5 4:5.103.0-1 ii libkf5windowsystem55.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii liblayershellqtinterface5 5.27.5-2 ii libpam0g 1.5.2-6 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus55.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5x11extras5 5.15.8-2 ii libstdc++6 12.2.0-14 ii libwayland-client0 1.21.0-1 ii libwayland-server0 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb11.15-1 ii libxi6 2:1.8-1+b1 ii psmisc 23.6-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.27.5-2 libkscreenlocker5 suggests no packages. -- debconf-show failed
Bug#1043409: 'nco' misses UDUnits2 conversions
Package: nco Version: 5.1.4-1 In bookworm the package ‘nco’ misses the UDUnits2 conversions, below the output of ncap2 —revision, at the bottom. NCO netCDF Operators version 5.1.4 "Bakhmut" built by buildd on x86-csail-01 at Jan 11 2023 07:01:46 ncap2 version 5.1.4 Linked to netCDF library version 4.9.0 compiled Aug 7 2022 23:41:41 Copyright (C) 1995--2023 Charlie Zender This program is part of NCO, the netCDF Operators. NCO is free software and comes with a BIG FAT KISS and ABSOLUTELY NO WARRANTY You may redistribute and/or modify NCO under the terms of the 3-Clause BSD License with exceptions described in the LICENSE file BSD: https://opensource.org/licenses/BSD-3-Clause LICENSE: https://github.com/nco/nco/tree/master/LICENSE Homepage: http://nco.sf.net Code: http://github.com/nco/nco Build-engine: Autoconf User Guide: http://nco.sf.net/nco.html Configuration Option: Active? Meaning or Reference: Check _FillValueYes http://nco.sf.net/nco.html#mss_val Community Codec RepoNo http://github.com/ccr/ccr DAP support Yes http://nco.sf.net/nco.html#dap Debugging: Custom No Pedantic, bounds checking (slowest execution) Debugging: Symbols No Produce symbols for debuggers (e.g., dbx, gdb) GNU Scientific Library Yes http://nco.sf.net/nco.html#gsl HDF4 supportNo http://nco.sf.net/nco.html#hdf4 InternationalizationNo http://nco.sf.net/nco.html#i18n (pre-alpha) Logging No http://nco.sf.net/nco.html#dbg netCDF3 64-bit offset Yes http://nco.sf.net/nco.html#lfs netCDF3 64-bit data Yes http://nco.sf.net/nco.html#cdf5 netCDF4/HDF5 supportYes http://nco.sf.net/nco.html#nco4 OpenMP SMP threadingYes http://nco.sf.net/nco.html#omp Regular Expressions Yes http://nco.sf.net/nco.html#rx UDUnits2 conversionsNo http://nco.sf.net/nco.html#udunits In bullseye this was active. Is it possible to switch it on in bookworm as well? I am using the python:3.12.0rc1-bookworm image from DockerHub (hub.docker.com). Thanks, Hans
Bug#1042842: network interface names wrong in domU (>10 interfaces)
Hi,
On 8/8/23 15:22, Valentin Kleibel wrote:
>> On [0], you can read "In both cases the device naming is subject to the
>> usual guest or backend domain facilities for renaming network devices".
>> It says "naming/renaming", but you can assume "detecting".
>>
>>> I also checked which net_ids udev knows about and the only things that
>>> pop up are:
>>> ID_NET_NAMING_SCHEME=v247
>>> ID_NET_NAME_MAC=enx00163efd832b
>>> ID_OUI_FROM_DATABASE=Xensource, Inc.
What I do is stuff like this:
-$ cat /etc/udev/rules.d/70-persistent-vifname.rules
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/0",
NAME="vlan2"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/1",
NAME="vlan3"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/2",
NAME="vlan4"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/3",
NAME="vlan6"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/4",
NAME="vlan9"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/5",
NAME="vlan10"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/6",
NAME="vlan11"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/7",
NAME="vlan12"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/8",
NAME="vlan13"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/9",
NAME="vlan14"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/10",
NAME="vlan15"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{nodename}=="device/vif/11",
NAME="vlan16"
The vif/X always matches the order in which you define the interfaces
inside the guest config file.
After starting to build router VMs (well before the whole interface
naming madness was a thing), it took only the first time when we wanted
to throw away a vlan, to realize that all the ethX numbers would shift 1
up, and from then on, I've always been using this so set my own style
predictable names (whenever there's more than one, otherwise it's just
eth0).
>> Is it from dom0 or domU ?
>> Are you using "net.ifnames=0" on the domU kernel command line ?
>> "v247" looks like systemd "predictive naming scheme" (eth -> enX).
>> From bookworm on, domUs vifs get named enXN (enX0, enX1, ...).
>> Read on :
>> https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#xen-network
>
> This is from the domU, running bullseye with a bookworm dom0.
>
>> See how ethN interfaces get messed up, like in your setup, but
>> predictable names would work, as you can see in "altname enXN" :
>> eth1 (:01) -> enX1
>> eth2 (:10) -> enX10
>> eth3 (:02) -> enX2
But yeah, so, even while not depending on whatever order it gets
initialized, and still having it function correctly, this is still just
pretty annoying... If I'm doing stuff around here, and just quickly want
to look up things (e.g. messing around with vlan15 settings), and
quickly type ip a instead of having to spend more time typing ip a show
dev vlan15 jadijadi, I still every time get this short "WTF huh, argh",
raises arms, does table flip, grmbl grbml feeling for a split second.
2: vlan2: I could not get our bullseye domU to show the "predictable names" even
> though i tried installing the bullseye-backports kernel 6.1.
> After you wrote this i installed udev 252.5 from backports and it now
> uses the correct enXn interface names, even with kernel 5.10.
>
>> So, my answer does not tell you if something changed in Xen itself, only
>> in Debian.
>> But I guess it relates to what Xen devs told us : vifs detection order
>> cannot be relied upon, that's why "predictable names" were invented.
>> The vif detection part is related to the domains kernels, not Xen itself
>> (at least that's what I understood).
>>
>> Using eth0 nowadays is a bit like using /dev/sda for hard drives, it's
>> considered legacy as it may create problems in some setups, like yours
>> (ie. for disks, it's recommended to use UUIDs or /dev/disk/by-*).
>>
>> I hope this answers your question.
>
> Thank you, yes it does.
>
> In our case the dom0 was updated to bookworm while the domU is still
> running bullseye.
> -> updated Xen so the vif detection order changed (which we relied on)
I didn't read the other mailthread on the xen list fully yet. But, I
think it's shouldn't be very hard to find the code changes and see if
it's deterministic and can just be fixed. Simply just to decrease the
totally unnecessary amount of silliness.
> -> the predictable network names for Xen don't work with bullseye
>
> So my new resolution for bullseye domUs on a bookworm dom0 is to install
> udev from backports and change the domUs network config to use the new
> enXn naming scheme instead of ethn.
Or the "device/vif/X" way...
So, anyway, did someone already did some test "just because we can" to
see how much network interfaces you can get added for fun, and if the
pattern keeps looking the same, also with enX4 enX40 .. enX49 enX5 etc?
:D enX1 enX10 enX100 .. enX109 enX11 enX110 argh o_O
Have fun,
Hans
Bug#1036968: Ubuntu 22.04 includes it
The sound works with Ubuntu 22.04. This laptop family (Dell XPS) is listed as supported by Ubuntu on their site. It is the same hardware as the Dell XPS 13 Plus: https://ubuntu.com/certified/202112-29802 The Ubuntu/jammy 22.04 kernel includes this same list of modules as listed in kernel.org issue: https://packages.ubuntu.com/jammy/amd64/linux-buildinfo-5.15.0-78-generic/download $ grep -i CS35L41 linux-buildinfo-5.15.0-78-generic_5.15.0-78.85_amd64/usr/lib/linux/5.15.0-78-generic/config CONFIG_SND_HDA_SCODEC_CS35L41=m CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_LIB=m CONFIG_SND_SOC_CS35L41=m CONFIG_SND_SOC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_I2C=m This machine is setup with Secure Boot, and not setup to sign its own kernels. So testing it in Debian would not be easy for me until its shipped in a signed kernel.
Bug#1042820: pim-data-exporter: Can not unpack ZIP file
Package: pim-data-exporter Version: 4:22.12.3-1 Severity: important Dear Maintainer, I tried to import and export all mails and settings of kmail from one computer to another. Using pimdataexporter I creyated a file called "kmail1.zip". This went well, but when I tried to unpack it, I got the error "Can not unpack kmail1.zip". In console it told "unexpected end" or so. Thus, to refer the file itself is ok, I checked with "unzip kmail1.zip" and it could all be extracted. Then repacked the whole files with ARK to a new zip file called "kmail2.zip" and tried again: It does not want to unpack the file. It would be nice, if you could take a look of it or tell me another solution. Thanks for reading and have a nice day. Best regards Hans -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pim-data-exporter depends on: ii kinit5.103.0-1 ii kio 5.103.0-1 ii libc62.36-9+deb12u1 ii libgcc-s112.2.0-14 ii libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1 ii libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1 ii libkf5akonadinotes5 [libkf5akonadinotes5-22.12] 4:22.12.3-1 ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.12] 4:22.12.3-1 ii libkf5archive5 5.103.0-1 ii libkf5calendarcore5abi2 5:5.103.0-1 ii libkf5configcore55.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5contacts5 5:5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5identitymanagement5 [libkf5identitymanagement5-22.12] 22.12.3-1 ii libkf5itemviews5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5mailcommon5abi2 [libkf5mailcommon5-22.12] 4:22.12.3-1 ii libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1 ii libkf5mime5abi1 [libkf5mime5-22.12] 22.12.3-1 ii libkf5notifications5 5.103.0-1 ii libkf5pimcommon5abi2 [libkf5pimcommon5-22.12]4:22.12.3-1 ii libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-22.12] 4:22.12.3-1 ii libkf5pimtextedit5abi2 [libkf5pimtextedit5-22.12]22.12.3-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5xmlgui55.103.0-1 ii libkuserfeedbackcore11.2.0-2 ii libkuserfeedbackwidgets1 1.2.0-2 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 pim-data-exporter recommends no packages. pim-data-exporter suggests no packages. -- debconf-show failed
Bug#1003403: maven: Warning running mvn about which beeing deprecated
I must admit I wasn't able to reproduce this even when testing with older maven versions. However, it looks like the most obvious usage of which was replaced upstream in 3.8.4, see for https://salsa.debian.org/java-team/maven/-/commit/e0a4b1763cfa9e730faa9526082ee793410fe1d1 So unless someone can still trigger this warning it might be fixed. -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1036968: linux: Enable CONFIG_SND_SOC_CS35L41_I2C for Intel Alder Lake sound
Package: src:linux Version: 6.3.2-1~exp1 Severity: important Dear Maintainer, I installed Debian on a Dell XPS 17 9720: https://wiki.debian.org/InstallingDebianOn/Dell/XPS%2017%209720 The audio output works, but there are a number of problems: * Headphone plug detection does not work at all. * No audio input is detected. * The audio crashes after a couple of days. This bug goes through some of the development efforts to fix this: https://bugzilla.kernel.org/show_bug.cgi?id=216194 One thing they said there is that all CS35L41 modules need to be enabled. This is the recommended set: CONFIG_SND_HDA_SCODEC_CS35L41=m CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_LIB=m CONFIG_SND_SOC_CS35L41=m CONFIG_SND_SOC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_I2C=m There is one module still not enabled in the Debian kernels (6.1.0-8, 6.3.2-1~exp1, and 6.3.4-1~exp1): $ grep CS35L41 /boot/config-6.3.0-0-amd64 CONFIG_SND_HDA_SCODEC_CS35L41=m CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m CONFIG_SND_SOC_CS35L41_LIB=m CONFIG_SND_SOC_CS35L41=m CONFIG_SND_SOC_CS35L41_SPI=m # CONFIG_SND_SOC_CS35L41_I2C is not set Could this module be enabled? -- Package-specific info: ** Version: Linux version 6.3.0-0-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.3.2-1~exp1 (2023-05-15) ** Command line: BOOT_IMAGE=/vmlinuz-6.3.0-0-amd64 root=/dev/mapper/monolith--vg-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Dell Inc. product_name: XPS 17 9720 product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: 1.14.0 board_vendor: Dell Inc. board_name: 0TW02W board_version: A00 ** Loaded modules: tls tun mmc_block r8153_ecm r8152 ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg wireguard libchacha20poly1305 chacha_x86_64 poly1305_x86_64 curve25519_x86_64 libcurve25519_generic libchacha ip6_udp_tunnel udp_tunnel snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr overlay bnep binfmt_misc nls_ascii nls_cp437 vfat fat snd_ctl_led snd_soc_sof_sdw snd_soc_intel_hda_dsp_common snd_sof_probes snd_soc_intel_sof_maxim_common snd_soc_rt711_sdca snd_soc_rt715_sdca regmap_sdw_mbq snd_soc_rt1316_sdw snd_hda_codec_hdmi regmap_sdw snd_soc_dmic snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils x86_pkg_temp_thermal snd_soc_hdac_hda intel_powerclamp snd_hda_ext_core coretemp snd_soc_acpi_intel_match iwlmvm snd_soc_acpi btusb kvm_intel btrtl snd_soc_core btbcm btintel btmtk mac80211 snd_compress kvm soundwire_bus bluetooth snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec uvcvideo libarc4 snd_hda_core videobuf2_vmalloc irqbypass uvc dell_laptop dell_wmi iwlwifi snd_hwdep jitterentropy_rng videobuf2_memops rapl dell_smbios ledtrig_audio mei_hdcp snd_pcm mei_pxp drbg hid_sensor_als ucsi_acpi intel_rapl_msr videobuf2_v4l2 processor_thermal_device_pci dcdbas intel_cstate ansi_cprng dell_wmi_sysman hid_sensor_trigger processor_thermal_device cfg80211 iTCO_wdt ecdh_generic intel_uncore videodev dell_wmi_ddv dell_wmi_descriptor firmware_attributes_class wmi_bmof pcspkr typec_ucsi snd_timer hid_sensor_iio_common processor_thermal_rfim mei_me intel_pmc_bxt industrialio_triggered_buffer processor_thermal_mbox videobuf2_common roles snd iTCO_vendor_support kfifo_buf processor_thermal_rapl mc industrialio mei watchdog ecc soundcore rfkill igen6_edac typec intel_rapl_common int3403_thermal int340x_thermal_zone int3400_thermal intel_hid acpi_thermal_rel sparse_keymap acpi_tad intel_pmc_core acpi_pad cdc_mbim joydev cdc_wdm ac hid_multitouch evdev serio_raw nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse msr loop configfs efi_pstore ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor cdc_ncm cdc_ether usbnet mii raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod usbhid hid_sensor_custom hid_sensor_hub intel_ishtp_hid i915 drm_buddy i2c_algo_bit crc32_pclmul drm_display_helper crc32c_intel nvme cec nvme_core ghash_clmulni_intel rc_core sha512_ssse3 ttm t10_pi hid_generic xhci_pci sha512_generic crc64_rocksoft_generic drm_kms_helper crc64_rocksoft xhci_hcd rtsx_pci_sdmmc crc_t10dif mmc_core crct10dif_generic i2c_hid_acpi usbcore intel_lpss_pci crct10dif_pclmul aesni_intel video i2c_i801 intel_ish_ipc i2c_hid intel_lpss crc64 drm psmouse thunderbolt crypto_simd rtsx_pci i2c_smbus intel_ishtp idma64 usb_common crct10dif_common cryptd hid battery wmi button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4621] (rev 02)
Bug#1036559: (no subject)
control: found 1036559 3.4.0~a1-6
Bug#1036559: androguard: fails to parse some valid APKs: ResParserError: res0 must be always zero!
Package: androguard
Version: 3.4.0~a1-1
Severity: important
Dear Maintainer,
androguard fails to parse some valid APKs, failing with:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/androguard/core/bytecodes/apk.py", line
1556, in get_android_resources
return self.arsc["resources.arsc"]
~^^
KeyError: 'resources.arsc'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/hans/code/fdroid/server/tests/../fdroid", line 22, in
fdroidserver.__main__.main()
File "/home/hans/code/fdroid/server/fdroidserver/__main__.py", line 230, in
main
raise e
File "/home/hans/code/fdroid/server/fdroidserver/__main__.py", line 211, in
main
mod.main()
File "/home/hans/code/fdroid/server/fdroidserver/update.py", line 2267, in
main
apks, cachechanged = process_apks(apkcache, repodirs[0], knownapks,
^^
File "/home/hans/code/fdroid/server/fdroidserver/update.py", line 1650, in
process_apks
(skip, apk, cachethis) = process_apk(apkcache, apkfilename, repodir,
knownapks,
^^^^^^
File "/home/hans/code/fdroid/server/fdroidserver/update.py", line 1510, in
process_apk
apk = scan_apk(apkfile)
^
File "/home/hans/code/fdroid/server/fdroidserver/update.py", line 1249, in
scan_apk
scan_apk_androguard(apk, apk_file)
File "/home/hans/code/fdroid/server/fdroidserver/update.py", line 1337, in
scan_apk_androguard
arsc = apkobject.get_android_resources()
^
File "/usr/lib/python3/dist-packages/androguard/core/bytecodes/apk.py", line
1562, in get_android_resources
self.arsc["resources.arsc"] = ARSCParser(self.zip.read("resources.arsc"))
^^^
File
"/usr/lib/python3/dist-packages/androguard/core/bytecodes/axml/__init__.py",
line 1344, in __init__
ate = ARSCResTableEntry(self.buff, res_id, pc)
File
"/usr/lib/python3/dist-packages/androguard/core/bytecodes/axml/__init__.py",
line 2589, in __init__
self.item = ARSCComplex(buff, parent)
^
File
"/usr/lib/python3/dist-packages/androguard/core/bytecodes/axml/__init__.py",
line 2647, in __init__
self.items.append((unpack('ARSCResStringPoolRef(buff, self.parent)))
^^^
File
"/usr/lib/python3/dist-packages/androguard/core/bytecodes/axml/__init__.py",
line 2667, in __init__
raise ResParserError("res0 must be always zero!")
androguard.core.bytecodes.axml.ResParserError: res0 must be always zero!
I'm seeing this with:
com.whatsapp
Version Code 230905004
Version 2.23.9.5
SHA-256 5f2a974da3d07803daf3cc29a63846d02e40d41c33c42f63f3e55ef14a07f55c
It was also reported for:
com.google.android.talk
SHA-256 6245178b03a5375f49f74f3eb40caab746655d39ee35fbfbf62299fedba037dd
Upstream suggests stop failing on that check:
https://github.com/androguard/androguard/issues/771#issuecomment-572169714
-- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental'),
(1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-0-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages androguard depends on:
ii python3 3.11.2-1+b1
ii python3-asn1crypto 1.5.1-2
ii python3-click 8.1.3-2
ii python3-colorama0.4.6-2
ii python3-ipython 8.5.0-4
ii python3-lxml4.9.2-1+b1
ii python3-magic 2:0.4.26-3
ii python3-matplotlib 3.6.3-1+b1
ii python3-networkx2.8.8-1
ii python3-oscrypto1.3.0-1
ii python3-pydot 1.4.2-1
ii python3-pygments2.14.0+dfsg-1
ii python3-yaml6.0-3+b2
Versions of packages androguard recommends:
ii python3-pyperclip 1.8.2-2
ii python3-pyqt5 5.15.9+dfsg-1
androguard suggests no packages.
-- no debconf information
Bug#1036386: tools-deps-clojure: FTBFS without network access
Source: tools-deps-clojure
Version: 0.16.1264-2
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
Dear Maintainer,
tools-deps-clojure currently fails to build on Sid. It looks like the
tests attempt to clone the upstream repository and then it fails:
Testing clojure.tools.deps.extensions.test-git
Cloning: https://github.com/clojure/tools.deps.git
FAIL in (canonicalize-errors) (test_git.clj:72)
expected: (thrown-with-msg? ExceptionInfo #"Library
io.github.clojure/tools.deps has coord with missing sha"
(ext/canonicalize (quote io.github.clojure/tools.deps) #:git{:tag
"tools.deps.alpha-0.5.317"} {}))
actual: #error {
:cause "Unable to clone
/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps\nfatal:
unable to access 'https://github.com/clojure/tools.deps.git/': Could not
resolve host: github.com\n"
:data {:args ("git" "clone" "--quiet" "--mirror"
"https://github.com/clojure/tools.deps.git;
"/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps"),
:exit 128, :out "", :err "fatal: unable to access
'https://github.com/clojure/tools.deps.git/': Could not resolve host:
github.com\n"}
:via
[{:type clojure.lang.ExceptionInfo
:message "Unable to clone
/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps\nfatal:
unable to access 'https://github.com/clojure/tools.deps.git/': Could not
resolve host: github.com\n"
:data {:args ("git" "clone" "--quiet" "--mirror"
"https://github.com/clojure/tools.deps.git;
"/build/tools-deps-clojure-0.16.1264/.gitlibs/_repos/https/github.com/clojure/tools.deps"),
:exit 128, :out "", :err "fatal: unable to access
'https://github.com/clojure/tools.deps.git/': Could not resolve host:
github.com\n"}
:at [clojure.tools.gitlibs.impl$git_clone_bare invokeStatic
"impl.clj" 103]}]
:trace
I saw this when building locally on Sid,
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/tools-deps-clojure.html
also has additional information.
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#1036385: python-aioredlock: FTBFS due to missing build dependency python3-setuptools
Source: python-aioredlock
Version: 0.7.3-1
Severity: serious
Justification: FTBFS
Tags: ftbfs sid
Dear Maintainer,
python-aioredlock currently fails to build with the following error
message:
dh clean --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:240: python3.11 setup.py clean
Traceback (most recent call last):
File "/build/python-aioredlock-0.7.3/setup.py", line 4, in
from setuptools import find_packages, setup
ModuleNotFoundError: No module named 'setuptools'
E: pybuild pybuild:388: clean: plugin distutils failed with: exit
code=1: python3.11 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.11
returned exit code 13
make: *** [debian/rules:4: clean] Error 25
dpkg-buildpackage: error: debian/rules clean subprocess returned exit
status 2
After adding python3-setuptools to build dependencies the package builds
successfully without any other issues
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#1002666: still fails
I just tried this today, and it fails to download. It tries to get version 12.0.4.
Bug#1034367: v2ray geoip data has problematic license
Package: v2ray From https://lists.debian.org/debian-legal/2023/02/msg4.html V2Fly project provides a geoip data file in https://github.com/v2fly/geoip. The license is declared as CC-BY-SA-4.0 but it uses the data from GeoLite2, which is licensed under an EULA https://www.maxmind.com/en/geolite2/eula. The EULA looks like not a free license. Debian packages the data file in the v2ray package. And Debian marks the data as MIT which is also wrong. Could you please check the license? Also, there is now libloc packages for this that should be free. For example, libloc-database should provide a free, compatible version of the geoip database.
Bug#1034346: more info
Turns out the provider has a custom initrd that does the /lib/modules mount. I don't know how common this is for VPS providers. Could the "Probably this system is using User Mode Linux." prompt check if /lib/modules is in /etc/fstab, and if not, offer a different suggestion, e.g. something like the steps I took.
Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount
Marco d'Itri: On Apr 13, Hans-Christoph Steiner wrote: Well, I'm a Debian user since 1998 and I know Debian, but I don't know Xen or how that /lib/modules mount even got there. I suppose it could be solved via documentation, but I don't know how to fix this, so I have a production server stuck with an incomplete bookworm upgrade. > Me neither, I think that this kind of Xen setup falls squarely in the retrocomputing area at this point. I suggest that you unmount /lib/modules/, continue the upgrade and see what happens after a reboot. I expect that it will work just fine. I emailed the support for more info. In the meantime I did: # service systemd-udevd stop # umount /lib/modules # apt dist-upgrade # mount | grep /lib modules on /usr/lib/modules type tmpfs (rw,relatime,size=102400k,mode=700) # reboot Failed to connect to bus: No such file or directory # So I rebooted from the VPS provider's console, and it seems to have worked.
Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount
Marco d'Itri: Control: severity -1 normal On Apr 13, Hans-Christoph Steiner wrote: I have some VPSes which are based on Xen, so the kernel comes from the host, and the VPS has no kernel installed. /lib/modules is mounted but not via /etc/fstab. When trying to upgrade from bullseye to bookworm, I get: Then fix it as suggested, but not via fstab? Looks like this is a documentation issue. What do you think should be changed here, exactly? Well, I'm a Debian user since 1998 and I know Debian, but I don't know Xen or how that /lib/modules mount even got there. I suppose it could be solved via documentation, but I don't know how to fix this, so I have a production server stuck with an incomplete bookworm upgrade.
Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount
Package: usrmerge Version: 25 Severity: serious I have some VPSes which are based on Xen, so the kernel comes from the host, and the VPS has no kernel installed. /lib/modules is mounted but not via /etc/fstab. When trying to upgrade from bullseye to bookworm, I get: Preparing to unpack .../archives/usrmerge_35_all.deb ... Unpacking usrmerge (35) ... Setting up usrmerge (35) ... FATAL ERROR: /lib/modules/ is a mount point. Probably this system is using User Mode Linux. To continue the conversion please: - replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab - reboot - try again E: usrmerge failed. dpkg: error processing package usrmerge (--configure): installed usrmerge package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: usrmerge E: Sub-process /usr/bin/dpkg returned an error code (1) Here is some more info which should hopefully be helpful: # umount /lib/modules/ umount: /lib/modules/: target is busy. # lsof /lib/modules COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd-u 1145 root memREG 0,20 1503845 /lib/modules/5.10.104/modules.symbols.bin systemd-u 1145 root memREG 0,20 3224788 /lib/modules/5.10.104/modules.alias.bin systemd-u 1145 root memREG 0,20 119456 10 /lib/modules/5.10.104/modules.dep.bin systemd-u 1145 root memREG 0,20 76634 /lib/modules/5.10.104/modules.builtin.bin # ps -ef|grep 1145 root 1145 1 0 09:29 ?00:00:00 /lib/systemd/systemd-udevd root 16599 25980 0 10:11 pts/100:00:00 grep 1145 # dpkg -l linux* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---=== un linux-kernel-log-daemon (no description available) ii linux-libc-dev:amd646.1.20-1 amd64Linux support headers for userspace development # mount |grep /lib modules on /lib/modules type tmpfs (rw,relatime,size=102400k,mode=700) # cat /etc/fstab /dev/xvda1 / xfs defaults0 0 proc/proc procdefaults0 0 #
Bug#1033833: unknown-horizons: Fails to start Couldn't open content/fonts/Unifont.ttf
Package: unknown-horizons Version: 2019.1-5 Severity: grave Dear Maintainer, When attempting to run uknown-horizons it fails with the following error message: $ unknown-horizons Discovered old settings file, auto-upgrading: 1 -> 38 Traceback (most recent call last): File "/usr/games/unknown-horizons", line 381, in main() File "/usr/games/unknown-horizons", line 122, in main ret = horizons.main.start(options) File "/usr/lib/python3/dist-packages/horizons/main.py", line 171, in start horizons.globals.fife.init() File "/usr/lib/python3/dist-packages/horizons/engine/engine.py", line 181, in init self._setting.apply() File "/usr/lib/python3/dist-packages/horizons/engine/settings.py", line 91, in apply change_language(language) File "/usr/lib/python3/dist-packages/horizons/i18n/__init__.py", line 163, in change_language horizons.globals.fife.pychan.loadFonts(fontdef) File "/usr/lib/python3/dist-packages/fife/extensions/pychan/fonts.py", line 98, in loadFonts for font in Font.loadFromFile(filename): ^^^ File "/usr/lib/python3/dist-packages/fife/extensions/pychan/fonts.py", line 82, in loadFromFile fonts.append(Font(font, lambda key, default=None: fontXMLFile.get(font, key, default))) ^ File "/usr/lib/python3/dist-packages/fife/extensions/pychan/fonts.py", line 52, in __init__ self.font = get_manager().createFont(self.source, self.size) File "/usr/lib/python3/dist-packages/fife/extensions/pychan/internal.py", line 176, in createFont return self.hook.create_font(path,size,glyphs) ^^^ fife.fife.CannotOpenFile: _[CannotOpenFile]_ , File couldn't be opened :: content/fonts/Unifont.ttf (Couldn't open content/fonts/Unifont.ttf) The root problem is a missing font or font format. I tried a simple rebuild of the package, but it had no effect. Looks like the font path is part of the source code, so might be more font references with similar issues. Also reported in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/unknown-horizons/+bug/2011358 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unknown-horizons depends on: ii fonts-unifont 1:15.0.01-2 ii python3 3.11.2-1 ii python3-enet0.0~vcs.2022.12.26.git-0.2+b1 ii python3-fife0.4.2-5+b1 ii python3-future 0.18.2-6 ii python3-yaml6.0-3+b2 unknown-horizons recommends no packages. unknown-horizons suggests no packages. -- no debconf information -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1032986: unblock fdroidserver/2.2.1-1
Paul Gevers: Hi, On 20-03-2023 17:16, Hans-Christoph Steiner wrote: I haven't really ever been able to troubleshoot it. I don't have access to a s390x box. And: ~ $ ssh zelenka.debian.org ssh: connect to host zelenka.debian.org port 22: Connection timed out ~ $ That's the only porterbox I could find. It works for me (now). Can you try again? I got in. Also, you don't strictly need to troubleshoot it. Obviously it depends on how sure you are it's in your dependency, but you said it quite convinced. I'm 100% sure its the dependency, and I just confirmed it on the porterbox and filed a bug upstream: https://github.com/androguard/androguard/issues/928 Normally we expect a debdiff attached to an unblock. This is mostly to trigger the submitter to look at it and make sure that all changes are explained. Can you please elaborate on the changes in ./debian/? ^ * zipalign is no longer used by fdroidserver * these patches were upstreamed: debian/patches/0005-handle-str-and-pathlib.Path-in-getvcs.patch was upstreamed debian/patches/0006-Fix-openjdk-detection-on-different-architectures.patch debian/patches/fix-java-paths-for-non-amd64.patch The debdiff is large because we were working upstream on 2.2.x as the release that is tied to Debian/bookworm (attached). Sure, I already used some tooling on our side to inspect it. It would help if you took a look and see if you spot things worth mentioning (e.g. some patches being dropped, I don't want to assume things). To reduce the diff you could ignore the tests and translations. There were changes related to have I mentioned above, like purging dead code related to zipalign, buildozer, and bug fixes related to a recent port to use pathlib. Also, there were methods added to support verifying JARs and APKs signed by SHA1, which are still considered valid by the Android apksigner tool, though Java has dropped support for verifying SHA1 signatures. The download_repo_index_v2() function was to finalize the whole "index-v2" work that was completed in fdroidserver 2.2.x. That was the one last key missing bit.
Bug#1033236: unblock: apktool/2.7.0+dfsg-6
Control: retitle -1 unblock: apktool/2.7.0+dfsg-6 aapt building is not supported on all arches, upstream only supports amd64, arm64 and i386. So I had to restrict the test of building to those arches. diff --git a/debian/changelog b/debian/changelog index d439603..8c68cfa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,15 @@ +apktool (2.7.0+dfsg-6) unstable; urgency=medium + + * only test APK build on arches with aapt that can do it + + -- Hans-Christoph Steiner Tue, 21 Mar 2023 09:41:45 +0100 + +apktool (2.7.0+dfsg-5) unstable; urgency=medium + + * fix broken symlink to commons-text.jar (Closes: #1033226) + + -- Hans-Christoph Steiner Mon, 20 Mar 2023 14:00:20 +0100 + apktool (2.7.0+dfsg-4) unstable; urgency=medium * fix arch detection for Depends: diff --git a/debian/links b/debian/links index 2c167db..779d62e 100644 --- a/debian/links +++ b/debian/links @@ -2,7 +2,7 @@ usr/share/java/antlr3-runtime.jar usr/share/apktool/antlr3-runtime.jar usr/share/java/commons-cli.jar usr/share/apktool/commons-cli.jar usr/share/java/commons-io.jar usr/share/apktool/commons-io.jar usr/share/java/commons-lang3.jar usr/share/apktool/commons-lang3.jar -usr/share/java/commons-text-1.9.jar usr/share/apktool/commons-text-1.9.jar +usr/share/java/commons-text.jar usr/share/apktool/commons-text.jar usr/share/java/guava.jar usr/share/apktool/guava.jar usr/share/java/snakeyaml.jar usr/share/apktool/snakeyaml.jar usr/share/java/stringtemplate.jar usr/share/apktool/stringtemplate.jar diff --git a/debian/tests/control b/debian/tests/control index 298f6e5..6855f40 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,4 +1,11 @@ # urzip.apk comes from https://github.com/eighthave/urzip via https://gitlab.com/fdroid/fdroidserver + Test-Command: apktool d debian/tests/urzip.apk && test -e urzip/smali/info/guardianproject/urzip/UnZipper.smali Depends: apktool Restrictions: allow-stderr + +# Test building an APK on arches that have aapt that can do it +Test-Command: apktool d debian/tests/urzip.apk && test -e urzip/smali/info/guardianproject/urzip/UnZipper.smali && apktool b urzip/ && test -e urzip/dist/urzip.apk +Architecture: amd64 arm64 i386 +Depends: apktool +Restrictions: allow-stderr
Bug#1033236: unblock: apktool/2.7.0+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: apkt...@packages.debian.org Control: affects -1 + src:apktool Please unblock package apktool [ Reason ] To fix the RC bug #1033226. [ Impact ] The core feature of `apktool build` will not work at all because it can't find a JAR. [ Tests ] I added a new test to cover a full cycle: apktool decode check if extracted file exists apktool build check if new APK file exists [ Risks ] Its a trivial fix, just fixing a symlink, I see no risks. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock apktool/2.7.0+dfsg-5diff --git a/debian/changelog b/debian/changelog index d439603..1884587 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +apktool (2.7.0+dfsg-5) unstable; urgency=medium + + * fix broken symlink to commons-text.jar (Closes: #1033226) + + -- Hans-Christoph Steiner Mon, 20 Mar 2023 14:00:20 +0100 + apktool (2.7.0+dfsg-4) unstable; urgency=medium * fix arch detection for Depends: diff --git a/debian/links b/debian/links index 2c167db..779d62e 100644 --- a/debian/links +++ b/debian/links @@ -2,7 +2,7 @@ usr/share/java/antlr3-runtime.jar usr/share/apktool/antlr3-runtime.jar usr/share/java/commons-cli.jar usr/share/apktool/commons-cli.jar usr/share/java/commons-io.jar usr/share/apktool/commons-io.jar usr/share/java/commons-lang3.jar usr/share/apktool/commons-lang3.jar -usr/share/java/commons-text-1.9.jar usr/share/apktool/commons-text-1.9.jar +usr/share/java/commons-text.jar usr/share/apktool/commons-text.jar usr/share/java/guava.jar usr/share/apktool/guava.jar usr/share/java/snakeyaml.jar usr/share/apktool/snakeyaml.jar usr/share/java/stringtemplate.jar usr/share/apktool/stringtemplate.jar diff --git a/debian/tests/control b/debian/tests/control index 298f6e5..af602dd 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,4 +1,4 @@ # urzip.apk comes from https://github.com/eighthave/urzip via https://gitlab.com/fdroid/fdroidserver -Test-Command: apktool d debian/tests/urzip.apk && test -e urzip/smali/info/guardianproject/urzip/UnZipper.smali +Test-Command: apktool d debian/tests/urzip.apk && test -e urzip/smali/info/guardianproject/urzip/UnZipper.smali && apktool b urzip/ && test -e urzip/dist/urzip.apk Depends: apktool Restrictions: allow-stderr
Bug#1033226: java.lang.NoClassDefFoundError: org/apache/commons/text/StringEscapeUtils
Package: apktool Version: 2.7.0+dfsg-4 Severity: important $ apktool build org.sajeg.fallingblocks_3 I: Using Apktool 2.7.0-dirty Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/text/StringEscapeUtils at brut.androlib.meta.YamlStringEscapeUtils.unescapeString(YamlStringEscapeUtils.java:141) at brut.androlib.meta.ClassSafeConstructor$ConstructStringEx.construct(ClassSafeConstructor.java:58) at org.yaml.snakeyaml.constructor.Constructor$ConstructScalar.constructStandardJavaInstance(Constructor.java:452) at org.yaml.snakeyaml.constructor.Constructor$ConstructScalar.construct(Constructor.java:403) at org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:270) at org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:253) at org.yaml.snakeyaml.constructor.SafeConstructor.processDuplicateKeys(SafeConstructor.java:108) at org.yaml.snakeyaml.constructor.SafeConstructor.flattenMapping(SafeConstructor.java:81) at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:252) at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:207) at org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:358) at org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:270) at org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:253) at org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:207) at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:191) at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:477) at org.yaml.snakeyaml.Yaml.loadAs(Yaml.java:470) at brut.androlib.meta.MetaInfo.load(MetaInfo.java:70) at brut.androlib.Androlib.readMetaFile(Androlib.java:280) at brut.androlib.Androlib.build(Androlib.java:294) at brut.androlib.Androlib.build(Androlib.java:287) at brut.apktool.Main.cmdBuild(Main.java:263) at brut.apktool.Main.main(Main.java:82) Caused by: java.lang.ClassNotFoundException: org.apache.commons.text.StringEscapeUtils at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) ... 23 more The problem is a weird broken symlink "commons-text-1.9.jar": ~ $ ls -l /usr/share/apktool/ total 248 lrwxrwxrwx 1 root root 26 14. Feb 15:32 antlr3-runtime.jar -> ../java/antlr3-runtime.jar -rw-r--r-- 1 root root259 14. Feb 15:32 apktool-2.7.0.jar -rw-r--r-- 1 root root 12849 14. Feb 15:32 apktool-cli.jar -rw-r--r-- 1 root root 184646 14. Feb 15:32 apktool-lib.jar lrwxrwxrwx 1 root root 20 14. Feb 15:32 baksmali.jar -> ../java/baksmali.jar -rw-r--r-- 1 root root259 14. Feb 15:32 brut.apktool.jar -rw-r--r-- 1 root root 2207 14. Feb 15:32 brut.j.common.jar -rw-r--r-- 1 root root 16834 14. Feb 15:32 brut.j.dir.jar -rw-r--r-- 1 root root 15930 14. Feb 15:32 brut.j.util.jar lrwxrwxrwx 1 root root 23 14. Feb 15:32 commons-cli.jar -> ../java/commons-cli.jar lrwxrwxrwx 1 root root 22 14. Feb 15:32 commons-io.jar -> ../java/commons-io.jar lrwxrwxrwx 1 root root 25 14. Feb 15:32 commons-lang3.jar -> ../java/commons-lang3.jar lrwxrwxrwx 1 root root 28 14. Feb 15:32 commons-text-1.9.jar -> ../java/commons-text-1.9.jar lrwxrwxrwx 1 root root 19 14. Feb 15:32 dexlib2.jar -> ../java/dexlib2.jar lrwxrwxrwx 1 root root 17 14. Feb 15:32 guava.jar -> ../java/guava.jar lrwxrwxrwx 1 root root 17 14. Feb 15:32 smali.jar -> ../java/smali.jar lrwxrwxrwx 1 root root 22 14. Feb 15:32 smali-util.jar -> ../java/smali-util.jar lrwxrwxrwx 1 root root 21 14. Feb 15:32 snakeyaml.jar -> ../java/snakeyaml.jar lrwxrwxrwx 1 root root 26 14. Feb 15:32 stringtemplate.jar -> ../java/stringtemplate.jar lrwxrwxrwx 1 root root 19 14. Feb 15:32 xmlunit.jar -> ../java/xmlunit.jar lrwxrwxrwx 1 root root 16 14. Feb 15:32 xpp3.jar -> ../java/xpp3.jar ~ $ ls -l /usr/share/apktool/../java/commons-text-1.9.jar ls: cannot access '/usr/share/apktool/../java/commons-text-1.9.jar': No such file or directory ~ $ -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apktool depends on: ii aapt 1:10.0.0+r36-10 ii
Bug#1032986: unblock fdroidserver/2.2.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package: fdroidserver It is blocked due to a autopkgtest failure only on s390x, this failure is not a regression. Since bullseye, we have fixed the issues in fdroidserver that caused autopkgtest to fail on ppc64el and s390x. ppc64el passes now. The current failure on s390x is caused by endian issues in androguard, a dependency. fdroidserver still mostly works on s390x despite these test failures.
Bug#1025069: debugging upstream
I've filed a bug upstream and am working through some debugging there: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3086
Bug#1032880: pipewire: mic input broken by recent changes
Package: pipewire
Version: 0.3.67-1
Severity: important
Dear Maintainer,
On a Dell XPS 17 9720
(https://wiki.debian.org/InstallingDebianOn/Dell/XPS%2017%209720) I'm
running bookworm. I try to keep the install as plain and default as
possible. The audio output and input was working at the beginning.
About a month ago, an update broke the audio input, but audio output
remains working. Subsequent updates have not changed the situation.
Here is some hopefully useful debug info:
~ $ uname -a
Linux monolith 6.1.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05)
x86_64 GNU/Linux
~ $ arecord -l
List of CAPTURE Hardware Devices
card 0: sofsoundwire [sof-soundwire], device 1: Jack In (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 4: Microphone (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
~ $ aplay -l
List of PLAYBACK Hardware Devices
card 0: sofsoundwire [sof-soundwire], device 0: Jack Out (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 2: Speaker (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 5: HDMI 1 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 6: HDMI 2 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 7: HDMI 3 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 31: Jack Out DeepBuffer (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
~ $ dpkg -l '*pulseaudio*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
+++-=-===-
ii gstreamer1.0-pulseaudio:amd64 1.22.0-5amd64
un libsdl1.2debian-pulseaudio
un mkchromecast-pulseaudio
un pipewire-media-session-pulseaudio
rc pulseaudio16.1+dfsg1-2+b1 amd64
un pulseaudio-module-bluetooth
ii pulseaudio-utils 16.1+dfsg1-2+b1 amd64
~ $ lsof /dev/snd/*
COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pipewire 2324 hans 41u CHR 116,11 0t0 803 /dev/snd/controlC0
pipewire 2324 hans 45u CHR 116,1 0t0 419 /dev/snd/seq
pipewire 2324 hans 46u CHR 116,1 0t0 419 /dev/snd/seq
wireplumb 2329 hans 26u CHR 116,11 0t0 803 /dev/snd/controlC0
wireplumb 2329 hans 27u CHR 116,11 0t0 803 /dev/snd/controlC0
wireplumb 2329 hans 28u CHR 116,11 0t0 803 /dev/snd/controlC0
~ $ emacs .config/systemd/user/pipewire.service.d/override.conf
~ $ systemctl --user daemon-reload
~ $ systemctl --user restart pipewire{,-pulse}.socket
~ $ journalctl --user -b --unit pipewire.service > pipewire-debug.log
# see attached
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pipewire depends on:
ii adduser 3.131
ii firmware-sof-signed 2.2.4-1
ii init-system-helpers 1.65.2
ii gstreamer1.0-pipewire:amd64 0.3.67-1
ii libpipewire-0.3-0:amd64 0.3.67-1
ii libpipewire-0.3-common0.3.67-1
ii libpipewire-0.3-modules:amd64 0.3.67-1
ii libwireplumber-0.4-0:amd640.4.13-1
ii pipewire:amd640.3.67-1
ii pipewire-alsa:amd64 0.3.67-1
ii pipewire-audio0.3.67-1
ii pipewire-bin 0.3.67-1
ii pipewire-pulse0.3.67-1
ii wireplumber 0.4.13-1
Mär 13 10:10:53 monolith systemd[2281]: Started pipewire.service - PipeWire Multimedia Service.
Mär 13 10:10:53 monolith pipewire[2324]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Mär 13 10:10:53 monolith pipewire[2324]: mod.rt: found session bus but no portal
Mär 13 10:34:37 monolith systemd[2281]: Stopping pipewire.service - PipeWire Multimedia Service...
Mär 13 10:34:37 monolith systemd[2281]: Stopped pipewire.service - PipeWire Multimedia Service.
Mär 13 10:34:37 monolith systemd[2281]: pipewire.service: Consumed 8.065s CPU time.
Mär 13 10:34:37 monolith systemd[2281]: Started pipewire.service - PipeWire Multimedia Service.
Mär 13 10:34:37 monolith pipewire[9326]: spa.alsa: close 0
Mär 13 10:34:37 monolith pipewire[9326]: spa.a
Bug#1032522: emacs-gtk: Pausing at an open quote causes emacs to freeze when editing Python
Package: emacs-gtk Version: 1:28.2+1-10 Severity: important Dear Maintainer, * What led up to the situation? I've been editing Python in emacs for over a decade. I'm working on fdroidserver right now, an old Python code base. * What exactly did you do (or not do) that was effective (or ineffective)? While editing Python code, if I pause after typing an open quote, like ' or """, then emacs will totally freeze and has to be killed. The window won't draw updates if I resize it. Specifically, this has to be typed in a class function, for example, typing at this point: https://gitlab.com/fdroid/fdroidserver/-/blob/ae2b33dab38f7e76fc6ca5245c8e3fa44224802f/tests/index.TestCase#L68 And adding: foo = ' will cause it to crash every time. * What was the outcome of this action? emacs is frozen, and it is pegging the one CPU. * What outcome did you expect instead? It should just let me type code! It seems to be related to: https://www.reddit.com/r/emacs/comments/z0oye9/emacs_freezes_when_opening_a_python_file/ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-10 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#1029668: confirmed
I'm having the same problem on bookworm, for me, I'm using the default eog viewer. There is a new upstream version of libheif available (v1.15.1), there is still time to upload that to bookworm. I'm a DD and I could do an NMU if that is helpful
Bug#1031684: python-magic: new upstream version available 0.4.27
Package: python3-magic Version: 2:0.4.26-3 Severity: normal Dear Maintainer, There is a new bugfix version available from upstream. It would be nice to have that in bookworm, and there is still time before the hard freeze if it is uploaded now. I can contribute there if that is needed to make this happen. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-magic depends on: ii libmagic1 1:5.44-3 ii python33.11.1-3
Bug#954072: `fdroid build` only works out of git
Control: severity -1 wishlist Upstream only uses and maintains the `fdroid build` command out of git. If someone wants change that, they should contribute upstream.
Bug#1031242: RM: django-hvad -- ROM; abandoned upstream ; unmaintained; EOL upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Please remove the source package django-hvad and all its binary packages from bookworm and sid. There have been no new commits upstream in 6 years, and this no longer works with the version of Django that is in bookworm.
Bug#1011567: needs com.sun.javadoc migration
Looks like doclava would need to be ported to use the API that replaces com.sun.javadoc: https://docs.oracle.com/en/java/javase/11/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration If someone does the migration, I can take care of the packaging updates.
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Roger, it is great to see your progress on android-platform-tools. Are you thinking of trying to get it into bookworm? If so, let me know how I can help. It would be really valuable to have there, but I don't know how much work it'll be.
Bug#1012103: upstream still uses java8
Doclava, which does not work with Java newer than 11. Upstream still builds it with java8. As in Android 13 still uses java8 in the build. Is there any hope?
Bug#1030728: Subject: FTBFS: tests fail, requiring network access
Source: biojava6-live
Version: 6.1.0+dfsg-3
Severity: serious
Tag: ftbfs patch
Dear Maintainer,
biojava6-live currently fails to build from source with test failures:
[ERROR] Failures:
[ERROR] FileDownloadUtilsTest$URLMethods.pingGoogleOK:161 expected:
but was:
The attached patch disables this and another test which require network
access. With these disabled, the package built successfully.
For more details, see either the build log from reproducible builds or
when the package was synced to Ubuntu
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/biojava6-live.html
https://launchpad.net/ubuntu/+source/biojava6-live/6.1.0+dfsg-3/+build/25558013
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Disable tests which require network access
Disable two tests which require network access when running.
To be honest, I don't see exactly how TestJmolSymmetryScriptGenerator ends up
calling network resources. I did see that when running the test suite with it
enabled it will send a request to https://models.rcsb.org/ presumably fetching
the models.
---
--- biojava6-live-6.1.0+dfsg.orig/biojava-core/src/test/java/org/biojava/nbio/core/util/FileDownloadUtilsTest.java
+++ biojava6-live-6.1.0+dfsg/biojava-core/src/test/java/org/biojava/nbio/core/util/FileDownloadUtilsTest.java
@@ -12,6 +12,7 @@ import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.file.Files;
+import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
@@ -156,6 +157,7 @@ class FileDownloadUtilsTest {
class URLMethods {
final String availableUrl = "https://www.google.com;;
+ @Disabled("Requires network access")
@Test
void pingGoogleOK(){
assertTrue(FileDownloadUtils.ping(availableUrl, 1000));
--- biojava6-live-6.1.0+dfsg.orig/biojava-structure-gui/src/test/java/org/biojava/nbio/structure/symmetry/TestJmolSymmetryScriptGenerator.java
+++ biojava6-live-6.1.0+dfsg/biojava-structure-gui/src/test/java/org/biojava/nbio/structure/symmetry/TestJmolSymmetryScriptGenerator.java
@@ -39,6 +39,7 @@ import org.biojava.nbio.structure.symmet
import org.biojava.nbio.structure.symmetry.core.SymmetryPerceptionMethod;
import org.biojava.nbio.structure.symmetry.jmolScript.JmolSymmetryScriptGeneratorDn;
import org.junit.Before;
+import org.junit.Ignore;
import org.junit.Test;
/**
@@ -50,6 +51,7 @@ public class TestJmolSymmetryScriptGener
public void setUp() {
}
+@Ignore
@Test
public void testPolygon() throws IOException, StructureException {
Structure struc = StructureIO.getStructure("4hhb");
@@ -64,4 +66,4 @@ public class TestJmolSymmetryScriptGener
String expected = "draw polyhedronD30 line{30.02,-39.95,0.59}{29.24,-0.53,40.00}{30.02,38.89,0.59}{30.80,-0.53,-38.82}{30.02,-39.95,0.59}{-30.00,-39.95,-0.60}{-30.79,-0.53,38.81}{-30.00,38.89,-0.60}{-29.22,-0.53,-40.01}{-30.00,-39.95,-0.60}width 0.45 color [x42ffd9] off;draw polyhedronD31 line{29.24,-0.53,40.00}{-30.79,-0.53,38.81}width 0.45 color [x42ffd9] off;draw polyhedronD32 line{30.02,38.89,0.59}{-30.00,38.89,-0.60}width 0.45 color [x42ffd9] off;draw polyhedronD33 line{30.80,-0.53,-38.82}{-29.22,-0.53,-40.01}width 0.45 color [x42ffd9] off;";
assertEquals(expected, poly);
}
-}
\ No newline at end of file
+}
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
Source: ruby-puppetserver-ca-cli Version: 2.4.0-1 Severity: serious Tag: ftbfs Dear Maintainer, ruby-puppetserver-ca-cli currently fails to build from source with test failures. Example: 1) Puppetserver::Ca::Action::Enable infracrl does not print the help output if called correctly Failure/Error: FileUtils.chown(@user, @group, path) ArgumentError: can't find user for puppet # ./lib/puppetserver/ca/utils/file_system.rb:96:in `write_file' # ./lib/puppetserver/ca/utils/file_system.rb:23:in `write_file' # ./lib/puppetserver/ca/action/enable.rb:109:in `create_infra_crl_chain' # ./lib/puppetserver/ca/action/enable.rb:75:in `enable_infra_crl' # ./lib/puppetserver/ca/action/enable.rb:53:in `run' # ./spec/puppetserver/ca/action/enable_spec.rb:34:in `block (5 levels) in ' # ./spec/utils/ssl.rb:248:in `with_ca_in' # ./spec/puppetserver/ca/action/enable_spec.rb:28:in `block (4 levels) in ' # ./spec/puppetserver/ca/action/enable_spec.rb:27:in `block (3 levels) in ' For more details see the log from reproducible builds https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-puppetserver-ca-cli.html (I have also verified the issue with pbuilder on my local Sid system) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1027456: gcc-10: gcc segfaults> 'tree-optimization/99824' patch is a fix
Control: tags -1 + fixed-upstream confirmed patch
Hi all,
I also ran into this issue while trying to build src:linux 6.1.7-1
targeting bullseye-backports.
I can confirm that I was able to build the kernel packages successfully
using gcc-10/10.2.1-6, with only the following patch on top:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=ee15832c53d52656e562c29110f2be1cfb66c450
ee15832c53 "tree-optimization/99824 - avoid excessive integer type
precision in VN"
So, in order to be able to do the next 'official' bullseye-backports for
src:linux I guess we first need this fix for gcc-10 to go into bullseye
via a stable point release?
Thanks,
Hans (Knorrie)From ee15832c53d52656e562c29110f2be1cfb66c450 Mon Sep 17 00:00:00 2001
From: Richard Biener
Date: Tue, 30 Mar 2021 11:22:52 +0200
Subject: [PATCH] tree-optimization/99824 - avoid excessive integer type
precision in VN
VN sometimes builds new integer types to handle accesss where precision
of the access type does not match the access size. The way
ao_ref_init_from_vn_reference is computing the access size ignores
the access type in case the ref operands have an outermost
COMPONENT_REF which, in case it is an array for example, can be
way larger than the access size. This can cause us to try
building an integer type with precision larger than WIDE_INT_MAX_PRECISION
eventually leading to memory corruption.
The following adjusts ao_ref_init_from_vn_reference to only lower
access sizes via the outermost COMPONENT_REF but otherwise honor
the access size as specified by the access type.
It also places an assert in integer type building that we remain
in the limits of WIDE_INT_MAX_PRECISION. I chose the shared code
where we set TYPE_MIN/MAX_VALUE because that will immediately
cross the wide_ints capacity otherwise.
2021-03-30 Richard Biener
PR tree-optimization/99824
* stor-layout.c (set_min_and_max_values_for_integral_type):
Assert the precision is within the bounds of
WIDE_INT_MAX_PRECISION.
* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use
the outermost component ref only to lower the access size
and initialize that from the access type.
* gcc.dg/torture/pr99824.c: New testcase.
---
gcc/stor-layout.c | 2 ++
gcc/testsuite/gcc.dg/torture/pr99824.c | 33 ++
gcc/tree-ssa-sccvn.c | 24 +++
3 files changed, 49 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/torture/pr99824.c
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index bde6fa22b58a..57c8a2516d95 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2816,6 +2816,8 @@ set_min_and_max_values_for_integral_type (tree type,
if (precision < 1)
return;
+ gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
+
TYPE_MIN_VALUE (type)
= wide_int_to_tree (type, wi::min_value (precision, sgn));
TYPE_MAX_VALUE (type)
diff --git a/gcc/testsuite/gcc.dg/torture/pr99824.c b/gcc/testsuite/gcc.dg/torture/pr99824.c
new file mode 100644
index ..9022d4a4b8e7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr99824.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+
+unsigned int
+strlenx(char *s)
+{
+ char *orig_s = s;
+ for (; *s; ++s)
+;
+ return s - orig_s;
+}
+
+struct i2c_adapter {
+char name[48];
+};
+
+struct {
+int instance;
+struct i2c_adapter i2c_adap[];
+} * init_cx18_i2c_cx;
+
+const struct i2c_adapter cx18_i2c_adap_template = {""};
+int init_cx18_i2c___trans_tmp_1;
+
+void
+init_cx18_i2c()
+{
+ int i = 0;
+ for (;; i++) {
+ init_cx18_i2c_cx->i2c_adap[i] = cx18_i2c_adap_template;
+ init_cx18_i2c___trans_tmp_1
+ = strlenx(init_cx18_i2c_cx->i2c_adap[i].name);
+ }
+}
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 4b280f21006e..926b4a976aec 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -996,22 +996,26 @@ ao_ref_init_from_vn_reference (ao_ref *ref,
poly_offset_int size = -1;
tree size_tree = NULL_TREE;
- /* First get the final access size from just the outermost expression. */
+ machine_mode mode = TYPE_MODE (type);
+ if (mode == BLKmode)
+size_tree = TYPE_SIZE (type);
+ else
+size = GET_MODE_BITSIZE (mode);
+ if (size_tree != NULL_TREE
+ && poly_int_tree_p (size_tree))
+size = wi::to_poly_offset (size_tree);
+
+ /* Lower the final access size from the outermost expression. */
op = [0];
+ size_tree = NULL_TREE;
if (op->opcode == COMPONENT_REF)
size_tree = DECL_SIZE (op->op0);
else if (op->opcode == BIT_FIELD_REF)
size_tree = op->op0;
- else
-{
- machine_mode mode = TYPE_MODE (type);
- if (mode == BLKmode)
- size_tree = TYPE_SIZE (type);
- else
- size = GET_MODE_BITSIZE (mode);
-}
if (size_tree != NULL_TREE
- && poly_int_tree_p (size_tree))
+ && poly_int_tree_p (size_tree)
+ && (!known_size_p (size)
+ || known_lt (wi::t
Bug#1028251: New Patch (Was: Re: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64)
Hi, On 1/13/23 22:45, Chuck Zmudzinski wrote: > On 1/13/23 7:39 AM, Marek Marczykowski-Górecki wrote: >> On Fri, Jan 13, 2023 at 12:58:29AM -0500, Chuck Zmudzinski wrote: >>> On 1/11/2023 10:58 PM, Chuck Zmudzinski wrote: >>>> On 1/9/23 12:55 PM, Hans van Kranenburg wrote: >>>>> Hi! [...] Yolo style cutting out lines here... [...] >>> >>> Regarding the systemd files causing ftbfs, this explains it: >>> >>> https://salsa.debian.org/xen-team/debian-xen/-/blob/master/m4/systemd.m4#L119 >>> >>> and this: >>> >>> https://salsa.debian.org/xen-team/debian-xen/-/blob/master/tools/configure.ac#L480 >>> >>> The comments indicate that using AX_AVAILABLE_SYSTEMD() will >>> by default enable systemd if systemd development files are on the >>> build system, and AX_ALLOW_SYSTEMD() means --enable-systemd >>> must explicitly be passed to tools/configure to enable it. Upstream >>> uses the former, so build systems with systemd development files >>> by default will ftbfs because that produces missing files that dh_missing >>> in debian/rules does not like. >>> >>> So the reason there is ftbfs on my system is that my system has >>> the systemd development package installed. >> >> By the way, maybe a better fix would be to pass --enable-systemd, add >> libsystemd-dev >> build-dep and list them in the package? They might require patching to >> support Debian-specific upgrade machinery, though... >> >> Not installing xendriverdomain.service is one of things missing for >> driver domains support >> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033). >> > > Hi Marek, > > I wouldn't be against fixing it that way. In fact, I would prefer > that Debian packaged Xen with full support for native systemd units. > I am willing to wait until if/when the package maintainers have > full systemd support in the Xen packages. > > Perhaps this is an opportunity for you to try to fix 922033 again. > I see it has been sitting there for a few years now. Let's see > what Hans thinks. Yeah, well, so, the thing here is... When Debian started to package Xen (thanks! Bastian, in 200X), the upstream init scripts were copy pasted, and adjusted to have the ability to have different Hypervisor-ABI-incompatible versions installed at the same time. Also, this is related to the collection of Makefile patches we carry around to have ABI-incompatible stuff end up in a directory like /usr/lib/xen-4.14/ and /usr/lib/xen-4.17/ ! What does this mean? Well, in the most basic sense it means that you could apt-get (dist-)upgrade and then still be able to xl shutdown a domU afterwards before doing reboot, because it will choose the right tools which match with the ABI of the *now* running hypervisor instead of being left with a dumpster fire, which in the end causes you to shout curse words and cause you to have to go to the machine and hold the power button for 5 seconds to force power it off. This is the thing about where you upgrade from Xen 4.14 to Xen 4.17 during the upgrade from Debian 11/Bullseye to Debian 12/Bookworm, it will allow you, if booting the whole new thing is a huge failure, to reset the computer, and in grub, choose to use the previous Xen (and possibly do that in combination with previous Debian linux kernel) and then have a system where you again at least can start your domUs again *) and first have a good rest, night of sleep before starting to dig into what's going wrong. So, this is exactly the same way of doing stuff like how you can also reboot back into the previous Linux kernel (ABI-compatible) one during a system upgrade, even if you're not using Xen at all! I like this very much. This is the kind of thing that helps admins of systems that have just local disks and a few domUs. Like, the case where you support some non-profit organization with their server stuff running on donated hardware. (Yes, I also do some of those, I do!) And, in case something does fail (there could always be something like a misbehaving mpt3sas card in the hardware or anything that no one else spotted yet), the admin does not have to end up in total panic mode after doing the upgrade on a Friday afternoon lying upside down inside a broom closet, but they can just at least recover from the situation and have something that's running again, and then a day later, or 2 or 3 days or a week later return on another planned moment to fix it, after asking around. Upstream Xen stuff doesn't have anything like that. But, they actually look at us, and they think, ooh, this is actually nice, we should have that also by default. The fact that we have this changed/altered/divergent init scripts in Debian is the main reason that we cannot just enable
Bug#1028251: [Pkg-xen-devel] Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64
Hi! On 09/01/2023 18:44, Chuck Zmudzinski wrote: > Control: tag -1 + moreinfo > > thanks > > On 1/9/23 8:09 AM, Hans van Kranenburg wrote: >> Hi Chuck, >> >> On 1/8/23 23:18, Chuck Zmudzinski wrote: >>> [...] >>> >>> The build failed: >>> >>>debian/rules override_dh_missing >>> make[1]: Entering directory '/home/chuckz/sources-sid/xen/xen-4.17.0' >>> dh_missing --list-missing >>> dh_missing: warning: usr/lib/modules-load.d/xen.conf exists in debian/tmp >>> but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/proc-xen.mount exists in >>> debian/tmp but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/xen-init-dom0.service exists in >>> debian/tmp but is not installed to anywhere >>> dh_missing: warning: >>> usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service exists in >>> debian/tmp but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/xen-watchdog.service exists in >>> debian/tmp but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/xenconsoled.service exists in >>> debian/tmp but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/xendomains.service exists in >>> debian/tmp but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/xendriverdomain.service exists >>> in debian/tmp but is not installed to anywhere >>> dh_missing: warning: usr/lib/systemd/system/xenstored.service exists in >>> debian/tmp but is not installed to anywhere >> >> I cannot reproduce this error here locally and the CI build also succeeds: >> >> https://salsa.debian.org/xen-team/debian-xen/-/pipelines/481577 > > I thought I had a fairly clean sid install, but I think the problem > on my system could be caused by some obscure grandfathered in > setting because the sid I am using was updated from all the way back to > an original install of jessie many years ago... > > It might be time for me to refresh my sid with a clean installation. > > Out of curiosity and if you have time, can you answer a couple of > question if you know the answer? > > 1. Do the builds on a clean environment produce the missing files > listed in my build? No, after my local package build, there's no such things in there: ~/build/xen/debian-xen/debian/tmp/usr/lib m (master) 1-$ ll total 0 drwxr-xr-x 1 knorrie knorrie 110 Jan 8 23:51 debug drwxr-xr-x 1 knorrie knorrie 2048 Jan 8 23:50 x86_64-linux-gnu drwxr-xr-x 1 knorrie knorrie 20 Jan 8 23:51 xen-4.17 > > 2. Are those systemd service files installed anywhere in the xen > binary packages, either in arch=x86_64 packages or for the arch=all > packages such as xen-utils-common? No, they are not: https://packages.debian.org/search?searchon=contents=xenconsoled.service=path=unstable=any > If you don't know the answer to these questions I will investigate > myself to find the answers, so you can work on more important things. > >> >> How are you building the packages? In a clean build environment, using >> for example sbuild or pbuilder, or in an environment where unrelated >> other build dependencies could be present, that are not included in the >> xen list, but maybe 'wake up and do something' if they're present? > > As I said, I am building on a sid install that might have some > stuff grandfathered in from old releases going back to jessie. > I also might have some stale stuff around from my private builds > of the traditional device model available from xen that is not > part of the Debian packages. I will investigate these possible causes. > > I use debuild as a frontend to dpkg-buildpackage to build the packages. Yes. So (I'm not entirely sure how it works, but as example, just making something up here): After doing something else first, you might end up with a system that has for example dh-systemd-yolo-all-the-things-helper installed. And, it might be that only it being present means that the package build process changes. It might even be a 'feature' of that helper... "just add it to your build depends, and it will automatically do all the things for you!!!~``1" This is why it is very much recommended to build the packages using something like sbuild, so that you can be sure that every time it will start with a super minimal chroot which only has some essential things, and that the only build dependencies used will be the ones that are explicitly defined in the debian/control of the package. >> You can also compare your own build output with the full one from the CI >> job: >> >> https://salsa.debian.org/xen-team/debian-xen/-/jobs/3767564/raw > > I will take a look at that when I get a chance. > > This is not a real high priority for me, so I am content to let this > be until I get a chance to investigate the quirks of my current > installation of sid, and I also added the moreinfo tag, so you can > ignore this bug if you wish until I do some further research. Sure, no problem. Have fun, Hans
Bug#1028251: [Pkg-xen-devel] Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64
Hi Chuck, On 1/8/23 23:18, Chuck Zmudzinski wrote: > [...] > > The build failed: > >debian/rules override_dh_missing > make[1]: Entering directory '/home/chuckz/sources-sid/xen/xen-4.17.0' > dh_missing --list-missing > dh_missing: warning: usr/lib/modules-load.d/xen.conf exists in debian/tmp but > is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/proc-xen.mount exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/xen-init-dom0.service exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: > usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/xen-watchdog.service exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/xenconsoled.service exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/xendomains.service exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/xendriverdomain.service exists in > debian/tmp but is not installed to anywhere > dh_missing: warning: usr/lib/systemd/system/xenstored.service exists in > debian/tmp but is not installed to anywhere I cannot reproduce this error here locally and the CI build also succeeds: https://salsa.debian.org/xen-team/debian-xen/-/pipelines/481577 How are you building the packages? In a clean build environment, using for example sbuild or pbuilder, or in an environment where unrelated other build dependencies could be present, that are not included in the xen list, but maybe 'wake up and do something' if they're present? You can also compare your own build output with the full one from the CI job: https://salsa.debian.org/xen-team/debian-xen/-/jobs/3767564/raw Hans
Bug#1026571: jnlp-servlet: FTBFS: src/classes/jnlp/sample/servlet/JnlpResource.java:47: error: cannot find symbol
Fwiw, java.util.jar.Pack200 was removed in JDK 14 and is thus missing when building with JDK 17. https://openjdk.org/jeps/367 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1026608: jcommander: FTBFS: JCommander.java:45: error: malformed HTML
tags 1026608 patch
thanks
See the attached patch which resolves the HTML errors to generate the
JavaDoc and make the package build successfully.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Fix HTML errors in Javadoc causing build failures
Remove tags, not part of HTML5
Replace <> wrapping author emails
Drop <> around generic T which is mistaken for HTML tag
Resolved based on how it was solved upstream:
https://github.com/cbeust/jcommander/commit/c31f983ae8f56a5b06f502009dfb32baa2be96f1
https://github.com/cbeust/jcommander/commit/7b46f253f625c91b47ef7e0780c01ffd357f4cd2
---
Origin: upstream,
Forwarded: not-needed
Last-Update: 2022-12-21
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/Parameter.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/Parameter.java
@@ -69,15 +69,15 @@ public @interface Parameter {
boolean password() default false;
/**
- * The string converter to use for this field. If the field is of type List
- * and not listConverter attribute was specified, JCommander will split
+ * The string converter to use for this field. If the field is of type List
+ * and not listConverter attribute was specified, JCommander will split
* the input in individual values and convert each of them separately.
*/
Class> converter() default NoConverter.class;
/**
* The list string converter to use for this field. If it's specified, the
- * field has to be of type List and the converter needs to return
+ * field has to be of type List and the converter needs to return
* a List that's compatible with that type.
*/
Class> listConverter() default NoConverter.class;
@@ -103,7 +103,7 @@ public @interface Parameter {
boolean variableArity() default false;
/**
- * What splitter to use (applicable only on fields of type List). By default,
+ * What splitter to use (applicable only on fields of type List). By default,
* a comma separated splitter will be used.
*/
Class splitter() default CommaParameterSplitter.class;
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/IParameterValidator.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/IParameterValidator.java
@@ -21,7 +21,7 @@ package com.beust.jcommander;
/**
* The class used to validate parameters.
*
- * @author Cedric Beust
+ * @author Cedric Beust ced...@beust.com
*/
public interface IParameterValidator {
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/IStringConverter.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/IStringConverter.java
@@ -33,7 +33,7 @@ package com.beust.jcommander;
*/
public interface IStringConverter {
/**
- * @return an object of type created from the parameter value.
+ * @return an object of type T created from the parameter value.
*/
T convert(String value);
}
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/JCommander.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/JCommander.java
@@ -42,7 +42,7 @@ import java.util.concurrent.CopyOnWriteA
* or an instance of Iterable. In the case of an array or Iterable, JCommander will collect
* the \@Parameter annotations from all the objects passed in parameter.
*
- * @author Cedric Beust
+ * @author Cedric Beust ced...@beust.com
*/
public class JCommander {
public static final String DEBUG_PROPERTY = "jcommander.debug";
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/MissingCommandException.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/MissingCommandException.java
@@ -21,7 +21,7 @@ package com.beust.jcommander;
/**
* Thrown when a command was expected.
*
- * @author Cedric Beust
+ * @author Cedric Beust ced...@beust.com
*/
@SuppressWarnings("serial")
public class MissingCommandException extends ParameterException {
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/ParameterException.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/ParameterException.java
@@ -22,7 +22,7 @@ package com.beust.jcommander;
* The main exception that JCommand will throw when something goes wrong while
* parsing parameters.
*
- * @author Cedric Beust
+ * @author Cedric Beust ced...@beust.com
*/
@SuppressWarnings("serial")
public class ParameterException extends RuntimeException {
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/ResourceBundle.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/ResourceBundle.java
@@ -26,7 +26,7 @@ import java.lang.annotation.Target;
/**
* @deprecated use @Parameters
*
- * @author Cedric Beust
+ * @author Cedric Beust ced...@beust.com
*/
@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({ TYPE })
--- jcommander-1.71.orig/src/main/java/com/beust/jcommander/SubParameter.java
+++ jcommander-1.71/src/main/java/com/beust/jcommander/SubParameter.java
@@ -7,7 +7,7 @@ import
Bug#1026163: Uses Java 11
The main reason puppetdb fails to build with JDK 17 is a check in project.clj which only allows Java 8 or 11. However, this has recently been expanded to allow Java 17 in upstream [1] and should be part of the 7.12.0 release. So upgrading the package should hopefully resolve this. Somewhat unrelated but I did notice that several other puppet-related packages, at least https://tracker.debian.org/pkg/puppetlabs-http-client-clojure https://tracker.debian.org/pkg/trapperkeeper-metrics-clojure https://tracker.debian.org/pkg/trapperkeeper-webserver-jetty9-clojure have similar checks which will fail with Java 17. They don't seem to have newer upstream versions though, and I don't know if additional changes in the code would be required for these to support Java 17. [1] https://github.com/puppetlabs/puppetdb/blob/main/project.clj#L281 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1026617: libjt400-java: FTBFS: [javac] /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:149: error: reference to Record is ambiguous
tags 1026617 patch thanks [javac] both class com.ibm.as400.access.Record in com.ibm.as400.access and class java.lang.Record in java.lang match [javac] /<>/java8/com/ibm/as400/data/RecordFormatDocument.java:1375: error: reference to Record is ambiguous Looks like the ambiguity stems from the new Record class introduced in new JDKS which hit when rebuilt with JDK 17. See the attached patch which adds an explicit import to the "local" Record class, which has been the one imported up until now. With this patch in place, the package builds successfully again on Debian Sid. -- mvh / best regards Hans Joachim Desserud http://desserud.orgDescription: Explicit import for Record Since this code predates java.lang.Record in the JDK, I'm going to assume it refers to its own class --- Forwarded: no Last-Update: 2022-12-21 --- libjt400-java-9.4.orig/src/com/ibm/as400/data/RecordFormatDocument.java +++ libjt400-java-9.4/src/com/ibm/as400/data/RecordFormatDocument.java @@ -14,6 +14,7 @@ package com.ibm.as400.data; import com.ibm.as400.access.*; +import com.ibm.as400.access.Record; import java.io.File; import java.io.FileOutputStream; --- libjt400-java-9.4.orig/src/com/ibm/as400/data/RfmlRecordFormat.java +++ libjt400-java-9.4/src/com/ibm/as400/data/RfmlRecordFormat.java @@ -26,6 +26,7 @@ import java.util.TimeZone; import java.util.Vector; import com.ibm.as400.access.*; +import com.ibm.as400.access.Record; /**
Bug#1026262: ojalgo: FTBFS tests require network access during build
Source: ojalgo
Version: 51.4.1+ds-1
Severity: normal
Tag: ftbfs patch
Dear Maintainer,
ojalgo currently fails to build with failing tests:
Fetch problem for AlphaVantageFetcher!
Symbol & Resolution: MSFT & DAY
java.net.UnknownHostException: www.alphavantage.co
(see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ojalgo.html
for more details)
Looks like one of the test suites tries to look up this domain to verify
it can parse historical data. Since network access is disabled, this
fails.
See the attached patch which disables this test suite, after which the
package builds successfully.
Also thanks for the quick response and applying the patch to
biojava4-live here the other day :)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Disables network tests
---
Forwarded: not-needed
Last-Update: 2022-12-17
--- ojalgo-51.4.1+ds.orig/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageTest.java
+++ ojalgo-51.4.1+ds/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageTest.java
@@ -22,6 +22,7 @@
*/
package org.ojalgo.data.domain.finance.series;
+import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
import org.ojalgo.TestUtils;
import org.ojalgo.type.CalendarDateUnit;
@@ -31,6 +32,7 @@ import org.ojalgo.type.CalendarDateUnit;
*
* @author stefanvanegmond
*/
+@Disabled("Requires network access")
public class AlphaVantageTest extends FinanceDataTests {
public AlphaVantageTest() {
Bug#1026258: FTBFS: missing build dependency and failing tests
Source: ormar
Version: 0.12.0-1
Severity: serious
Tag: ftbfs
Dear Maintainer,
ormar currently fails to build from source for two reasons. The first is
several error message like these when running the test suite:
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_fastapi/test_skip_reverse_models.py:8: in
from starlette.testclient import TestClient
/usr/lib/python3/dist-packages/starlette/testclient.py:16: in
import httpx
E ModuleNotFoundError: No module named 'httpx'
_ ERROR collecting tests/test_fastapi/test_wekref_exclusion.py
_
(Taken from the build log when the package got synced to Ubuntu, but
I've also reproduced this on Sid
https://launchpadlibrarian.net/638906557/buildlog_ubuntu-lunar-amd64.ormar_0.12.0-1_BUILDING.txt.gz)
These errors are the easy part, it simply needs
python3-httpx
added as a build dependency. With this in place, the build result
changes from 19 errors to 2 failing tests. I don't know why they are
failing though, whether it is due to api changes in the test client
used, or the functionality of the package.
=== FAILURES
===
__ test_all_endpoints
__
def test_all_endpoints():
client = TestClient(app)
with client as client:
item = {
"name": "test",
"categories": [{"name": "test cat"}, {"name": "test
cat2"}],
}
response = client.post("/items/", json=item)
item_check = Item(**response.json())
assert item_check.id is not None
assert item_check.categories[0].id is not None
no_pk_item = client.get(f"/items/{item_check.id}",
json=item).json()
E TypeError: TestClient.get() got an unexpected keyword
argument 'json'
tests/test_fastapi/test_excluding_fields.py:118: TypeError
__ test_all_endpoints
__
def test_all_endpoints():
client = TestClient(app)
with client as client:
response = client.post("/categories/", json={"name": "test
cat"})
category = response.json()
response = client.post(
"/items/", json={"name": "test", "id": 1, "category":
category}
)
item = Item(**response.json())
assert item.pk is not None
response = client.get("/items/")
items = [Item(**item) for item in response.json()]
assert items[0] == item
item.name = "New name"
response = client.put(f"/items/{item.pk}", json=item.dict())
assert response.json() == item.dict()
response = client.get("/items/")
items = [Item(**item) for item in response.json()]
assert items[0].name == "New name"
response = client.get("/items/raw/")
items = [Item(**item) for item in response.json()]
assert items[0].name == "New name"
assert items[0].category.name is None
response = client.get(f"/items/{item.pk}")
new_item = Item(**response.json())
assert new_item == item
response = client.delete(f"/items/{item.pk}")
assert response.json().get("deleted_rows", "__UNDEFINED__")
!= "__UNDEFINED__"
response = client.get("/items/")
items = response.json()
assert len(items) == 0
client.post("/items/", json={"name": "test_2", "id": 2,
"category": category})
response = client.get("/items/")
items = response.json()
assert len(items) == 1
item = Item(**items[0])
response = client.delete(f"/items/{item.pk}",
json=item.dict())
E TypeError: TestClient.delete() got an unexpected keyword
argument 'json'
tests/test_fastapi/test_more_reallife_fastapi.py:150: TypeError
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Bug#1026257: FTBFS: more network tests in node-zx
Source: node-zx
Version: 7.1.1+~cs6.7.23-1
Severity: serious
Tag: ftbfs patch
Dear Maintainer,
node-zx currently fails to build with the following error messages:
FAIL deps "installDeps() loader works via JS API"
Cannot find package 'cpy' imported from
/build/node-zx-7.1.1+~cs6.7.23/test/deps.test.js
FAIL deps "installDeps() loader works via CLI"
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'lodash' imported from
/build/node-zx-7.1.1+~cs6.7.23/zx-kdsc9wx1fn.mjs
Did you mean to import lodash/lodash.js?
at new NodeError (node:internal/errors:393:5)
at packageResolve (node:internal/modules/esm/resolve:860:9)
at moduleResolve (node:internal/modules/esm/resolve:909:20)
at defaultResolve (node:internal/modules/esm/resolve:1124:11)
at nextResolve (node:internal/modules/esm/loader:163:28)
at ESMLoader.resolve (node:internal/modules/esm/loader:841:30)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
at ModuleWrap.
(node:internal/modules/esm/module_job:76:40)
at link (node:internal/modules/esm/module_job:75:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
at Object.handler
(file:///build/node-zx-7.1.1+~cs6.7.23/test/deps.test.js:35:12)
exit code: 1
(See
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-zx.html
for more details)
I was able to reproduce the same error message when building in pbuilder
on my local Sid system. Turns out there's a couple of tests which call
`npm install` and verify the results which breaks when the network is
not available.
After expanding and applying the patch to disable network tests, the
package builds successfully.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/patches/drop-network-test.patch b/debian/patches/drop-network-test.patch
index cf5cd17..905f6a8 100644
--- a/debian/patches/drop-network-test.patch
+++ b/debian/patches/drop-network-test.patch
@@ -1,7 +1,7 @@
Description: drop network test
Author: Yadd
Forwarded: not-needed
-Last-Update: 2022-11-07
+Last-Update: 2022-12-17
--- a/test/cli.test.js
+++ b/test/cli.test.js
@@ -37,3 +37,24 @@ Last-Update: 2022-11-07
test('echo() works', async () => {
let stdout = ''
let log = console.log
+--- a/test/deps.test.js
b/test/deps.test.js
+@@ -21,7 +21,7 @@ const test = suite('deps')
+
+ $.verbose = false
+
+-test('installDeps() loader works via JS API', async () => {
++test.skip('installDeps() loader works via JS API', async () => {
+ await installDeps({
+ cpy: '9.0.1',
+ 'lodash-es': '4.17.21',
+@@ -30,7 +30,7 @@ test('installDeps() loader works via JS
+ assert.instance((await import('lodash-es')).pick, Function)
+ })
+
+-test('installDeps() loader works via CLI', async () => {
++test.skip('installDeps() loader works via CLI', async () => {
+ let out =
+ await $`node build/cli.js --install <<< 'import _ from "lodash" /* @4.17.15 */; console.log(_.VERSION)'`
+ assert.match(out.stdout, '4.17.15')
+
Bug#1026255: FTBFS: error: invalid flag: -html4
Source: junit5-system-exit
Version: 1.1.2-3
Severity: serious
Tags: ftbfs patch
Dear Maintainer,
junit5-system-exit currently fails to build from source with the
following error message:
Starting process 'command
'/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc''. Working directory:
/build/1st/junit5-system-exit-1.1.2 Command:
/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc
@/build/1st/junit5-system-exit-1.1.2/build/tmp/javadoc/javadoc.options
Successfully started process 'command
'/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc''
error: invalid flag: -html4
1 error
(for details see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/junit5-system-exit.html)
I was able to reproduce this on my Sid system, and the package built
successfully when replacing the flag, see the attached patch.
Based on the output from javadoc, this option now seems to be the
default
-html5Generate HTML 5 output. This option is no longer
required.
so alternatively the javadoc section can be trimmed down. Another thing
is that I haven't checked when the html5 option was introduced or when
it replaced html4. It builds successfully with the current JDK, but it
might introduced problems when backporting the package in the future. I
don't know if this is a concern.
Regardless, the attached patch should fix the build issue or serve as
the base for a better fix :)
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Replace html4 option with html5
The html4 option has been removed/replaced in newer JDKs, causing a build
failure.
---
Forwarded: no
--- junit5-system-exit-1.1.2.orig/build.gradle
+++ junit5-system-exit-1.1.2/build.gradle
@@ -74,6 +74,6 @@ publishing {
javadoc {
if(JavaVersion.current().isJava9Compatible()) {
-options.addBooleanOption('html4', true)
+options.addBooleanOption('html5', true)
}
}
Bug#909567: ITP: opensnitch -- Port of the Little Snitch application firewall
Hey aliasarmor, It would be great to have you as the package maintainer! I'm a Debian Developer and can mentor you through the process. The first step is to get it building on Debian unstable. Then get it building with only packages from Debian. Looks like lamby started that process here: https://salsa.debian.org/lamby/pkg-opensnitch More info here https://github.com/evilsocket/opensnitch/issues/304
Bug#1026083: Security: XSS bug in Loofah
Package: ruby-loofah Version: 2.19.0-1 Severity: serious control: affects -1 ruby-loofah/2.1.0 control: affects -1 ruby-loofah/2.7.0+dfsg-1 control: tags -1 fixed-upstream security help An XSS issue has been discovered in Loofah: https://github.com/flavorjones/loofah/security/advisories/GHSA-228g-948r-83gx It is fixed in the upstream release v2.19.1.
Bug#1025887: FTBFS: ambiguous method call
Source: biojava4-live
Version: 4.2.12+dfsg-7
Severity: serious
Tags: ftbfs patch
Dear Maintainer,
biojava4-live currently fails to build with the following error message:
compile:
[mkdir] Created dir:
/build/1st/biojava4-live-4.2.12+dfsg/build/biojava4-structure/classes
[javac]
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/build.xml:86:
warning: 'includeantruntime' was not set, defaulting to
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 483 source files to
/build/1st/biojava4-live-4.2.12+dfsg/build/biojava4-structure/classes
[javac]
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java:239:
error: reference to newFileSystem is ambiguous
[javac] try (FileSystem fs =
FileSystems.newFileSystem(m_zipFile, null)) {
[javac] ^
[javac] both method newFileSystem(Path,ClassLoader) in FileSystems
and method newFileSystem(Path,Map) in FileSystems match
[javac]
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java:296:
error: reference to newFileSystem is ambiguous
[javac] try (FileSystem zipfs =
FileSystems.newFileSystem(zipFile, null)) {
[javac]^
[javac] both method newFileSystem(Path,ClassLoader) in FileSystems
and method newFileSystem(Path,Map) in FileSystems match
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use or override a deprecated API that
is marked for removal.
[javac] Note: Recompile with -Xlint:removal for details.
[javac] Note:
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/MetalBondConsumer.java
uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
(see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/biojava4-live.html
for details)
When casting the null value to match one of the signatures this resolves
the build error. See the attached patch. I wasn't able to find the exact
upstream commit to reference since the file has been moved around, but
the patch is based on latest upstream and how they have chosen to
resolve the issue.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Add explicit cast to fix ambiguos method call error
Taken from upstream to match expected method call
https://github.com/biojava/biojava/blob/master/biojava-structure/src/main/java/org/biojava/nbio/structure/chem/ZipChemCompProvider.java
---
Origin: upstream
Forwarded: not-needed
Last-Update: 2022-12-11
--- biojava4-live-4.2.12+dfsg.orig/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java
+++ biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java
@@ -236,7 +236,7 @@ public class ZipChemCompProvider impleme
final String filename = "chemcomp/" + recordName+".cif.gz";
// try with resources block to read from the filesystem.
- try (FileSystem fs = FileSystems.newFileSystem(m_zipFile, null)) {
+ try (FileSystem fs = FileSystems.newFileSystem(m_zipFile, (ClassLoader)null)) {
Path cif = fs.getPath(filename);
if (Files.exists(cif)) {
@@ -293,7 +293,7 @@ public class ZipChemCompProvider impleme
*/
// Copy in each file.
- try (FileSystem zipfs = FileSystems.newFileSystem(zipFile, null)) {
+ try (FileSystem zipfs = FileSystems.newFileSystem(zipFile, (ClassLoader)null)) {
Files.createDirectories(pathWithinArchive);
for (File f : files) {
if (!f.isDirectory() && f.exists()) {
Bug#1025753: FTBFS: Java compilation error (cannot find symbols)
Source: jruby-openssl Version: 0.9.21-4 Severity: serious Tags: ftbfs Dear Maintainer, jruby-openssl currently fails to build with the following error message: [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[74,25] cannot find symbol symbol: class ChannelDescriptor location: package org.jruby.util.io [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[75,25] cannot find symbol symbol: class ChannelStream location: package org.jruby.util.io [ERROR] /build/jruby-openssl-0.9.21/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java:[76,25] cannot find symbol symbol: class FileExistsException location: package org.jruby.util.io [INFO] 3 errors Tested in pbuilder on my Sid system. Same error seemed to happen when the package got synced to Ubuntu [1] Btw, looks like the problematic imports are gone in latest upstream [2] so this might be resolved by upgrading to newer release :) [1] https://launchpad.net/ubuntu/+source/jruby-openssl/0.9.21-4/+build/24611214 [2] https://github.com/jruby/jruby-openssl/blob/master/src/main/java/org/jruby/ext/openssl/x509store/Lookup.java -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1025440: FTBFS: fails to compile with Java errors
Source: starjava-ttools Version: 3.4.7-2 Severity: serious Tags: ftbfs Dear Maintainer, starjava-ttools fails to build from source, see https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/starjava-ttools.html for detailed log output. The main errors seem to be com.sun.* imports. I've also seen the same build failure when the package got synced to Ubuntu (https://launchpad.net/ubuntu/+source/starjava-ttools/3.4.7-2/+build/24622556) as well as locally on my Sid system. Not sure what might have changed since the package got uploaded in the first place. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1025439: maelstrom: Crashes on startup: couldn't create staging surface
Package: maelstrom Version: 3.0.7-4 Severity: important Dear Maintainer, Maelstrom crashes on startup with the following error message: $ maelstrom Fatal: Couldn't create staging surface: Parameter 'pitch' is invalid Originally reported in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/maelstrom/+bug/1995534 but I am able to reproduce this on Debian Sid and it doesn't seem related to graphics card -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maelstrom depends on: ii libc6 2.36-5 ii libgcc-s1 12.2.0-9 ii libsdl2-2.0-0 2.24.2+dfsg-1 ii libsdl2-net-2.0-0 2.2.0+dfsg-2 ii libstdc++6 12.2.0-9 maelstrom recommends no packages. maelstrom suggests no packages. -- no debconf information -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#1025069: looks like its not conflicting with pulseaudio
It looks like it is not conflicting with pulseaudio. I tried these steps and I'm still have only "Dummy Output". I have not restarted though hans@delbin:~$ systemctl --user daemon-reload hans@delbin:~$ systemctl --user --now disable pulseaudio.service pulseaudio.socket hans@delbin:~$ systemctl --user --now enable pipewire pipewire-pulse Created symlink /home/hans/.config/systemd/user/default.target.wants/pipewire.service → /usr/lib/systemd/user/pipewire.service. Created symlink /home/hans/.config/systemd/user/sockets.target.wants/pipewire.socket → /usr/lib/systemd/user/pipewire.socket. Created symlink /home/hans/.config/systemd/user/default.target.wants/pipewire-pulse.service → /usr/lib/systemd/user/pipewire-pulse.service. Created symlink /home/hans/.config/systemd/user/sockets.target.wants/pipewire-pulse.socket → /usr/lib/systemd/user/pipewire-pulse.socket. hans@delbin:~$ LANG=C pactl info | grep '^Server Name' Server Name: PulseAudio (on PipeWire 0.3.61) hans@delbin:~$ $ systemctl --user --now enable wireplumber.service bash: $: command not found hans@delbin:~$ systemctl --user --now enable wireplumber.service hans@delbin:~$ systemctl --user --now enable pipewire pipewire-pulse hans@delbin:~$ systemctl --user --now start pipewire pipewire-pulse hans@delbin:~$ systemctl --user --now restart pipewire pipewire-pulse hans@delbin:~$ systemctl --user --now restart wireplumber.service hans@delbin:~$
Bug#1025069: more info
You can ping me on IRC (_hc) or matrix (@eighthave:matrix.org) if you want to try it interactively. pulseaudio was not running as far as I could tell. root@delbin:~# service pulseaudio-enable-autospawn status ○ pulseaudio-enable-autospawn.service Loaded: masked (Reason: Unit pulseaudio-enable-autospawn.service is masked.) Active: inactive (dead) hans@delbin:~$ ps auxww|grep pulse hans 68885 0.0 0.1 35168 10600 ?S/usr/bin/pipewire-pulse hans 80426 0.0 0.0 9568 2204 pts/1S+ 21:04 0:00 grep pulse hans@delbin:~$ systemctl --user --now enable wireplumber.service hans@delbin:~$ journalctl --user -u pipewire --user -u wireplumber --user -u pipewire-pulse -f Nov 26 22:54:26 delbin pipewire-pulse[2233]: 536870912 Nov 26 22:54:26 delbin wireplumber[2182]: Failed to set scheduler settings: Operation not permitted Nov 26 22:54:26 delbin wireplumber[2182]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed? Nov 26 22:54:26 delbin wireplumber[2182]: PipeWire's libcamera SPA missing or broken. libcamera not supported. Nov 26 22:54:27 delbin wireplumber[2182]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5. Dec 01 20:50:55 delbin systemd[2147]: Stopping PipeWire PulseAudio... Dec 01 20:50:55 delbin systemd[2147]: Stopped PipeWire PulseAudio. Dec 01 20:50:55 delbin systemd[2147]: pipewire-pulse.service: Consumed 17.350s CPU time. Dec 01 20:50:55 delbin systemd[2147]: Started PipeWire PulseAudio. Dec 01 20:50:55 delbin pipewire-pulse[68890]: 536870912 hans@delbin:~$ systemctl status|grep -e pipe -e wire -e pulse │ │ └─80108 grep -e pipe -e wire -e pulse ├─pipewire-pulse.service │ └─68885 /usr/bin/pipewire-pulse ├─pipewire.service │ └─2180 /usr/bin/pipewire ├─wireplumber.service │ └─2182 /usr/bin/wireplumber
Bug#1025069: pipewire: audio broken, only says Dummy Output (on plain bookworm install)
Package: pipewire Version: 0.3.61-1 Severity: important Dear Maintainer, I'm running a plain, default install of bookworm that was upgraded from bullseye. Audio output worked under bullseye, and at first under bookworm. Then an upgrade broke the audio. Now, the only audio device available in the GNOME Sound Settings is "Dummy Output" and it is not possible get sound output from any of the default apps (browsers, VLC, etc). I can get sound output using the Pd-extended flatpak package, which seems to directly access ALSA. That is why I filed this bug against pipewire. The computer is an ASUS Chromebook delbin so Linux does support it. Here is some hopefully useful debug info: hans@delbin:~$ pw-cli info 0 id: 0 permissions: rwxm type: PipeWire:Interface:Core/3 cookie: 3757616015 user-name: "hans" host-name: "delbin" version: "0.3.61" name: "pipewire-0" * properties: * config.name = "pipewire.conf" * link.max-buffers = "16" * core.daemon = "true" * core.name = "pipewire-0" * default.clock.min-quantum = "16" * cpu.max-align = "64" * default.clock.rate = "48000" * default.clock.quantum = "1024" * default.clock.max-quantum = "2048" * default.clock.quantum-limit = "8192" * default.video.width = "640" * default.video.height = "480" * default.video.rate.num = "25" * default.video.rate.denom = "1" * log.level = "2" * clock.power-of-two-quantum = "true" * mem.warn-mlock = "false" * mem.allow-mlock = "true" * settings.check-quantum = "false" * settings.check-rate = "false" * object.id = "0" * object.serial = "0" hans@delbin ~$ sudo journalctl | grep wire Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexec/bluetooth/bluetoothd") Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexec/bluetooth/bluetoothd") Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexec/bluetooth/bluetoothd") Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexec/bluetooth/bluetoothd") Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexec/bluetooth/bluetoothd") Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexec/bluetooth/bluetoothd") Nov 26 22:53:37 delbin dbus-daemon[846]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.71" (uid=1000 pid=2238 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.2" (uid=0 pid=844 comm="/usr/libexe
Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
Hi :)
On 04/11/2022 22:51, Salvatore Bonaccorso wrote:
> Hi Hans
>
> On Fri, Nov 04, 2022 at 02:59:29PM +0100, Hans van Kranenburg wrote:
>> Aha!
>>
>> On 02/11/2022 21:53, Salvatore Bonaccorso wrote:
>>> Hi,
>>>
>>> On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg wrote:
>>>> Hi,
>>>>
>>>> On 10/19/22 21:55, Moritz Muehlenhoff wrote:
>>>>>>> For the latest set of Xen issues my estimate is that we can postpone
>>>>>>> them until the next batch, they seem all of moderate/limited impact.
>>>>>>> But let me know if you think otherwise.
>>>>>>
>>>>>> I agree. Let's do them together with the new stuff that's planned for
>>>>>> Nov 1st, https://xenbits.xen.org/xsa/
>>>>>
>>>>> Ack, I've updated the Security Tracker.
>>>>
>>>> I'm having a look at this now, and while writing the changelog entry, I
>>>> run into the following thing:
>>>>
>>>> XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes done
>>>> to Linux, and the other two are about changes to Xen. Shouldn't the
>>>> Debian security tracker reflect that?
>>>>
>>>> CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
>>>> CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
>>>
>>> Speaking for src:linux I do not think we need to change the tracking:
>>>
>>> CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data in shared
>>> pages")
>>> CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data in shared
>>> pages")
>>> CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data bouncing when
>>> backend is untrusted")
>>> CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data bouncing when
>>> backend is untrusted")
>>
>> Riiight. Thanks, now I get why I cannot find any CVE number related to
>> XSA-403 listed in the Xen upstream changes (at least for 4.14 which I'm
>> working on now). They're all over there at the Linux side.
>
> It looks that there are still changes needed on the xen side, at least
> that is my understanding reading through
> https://xenbits.xen.org/xsa/advisory-403.html
> Quoting the advisory:
>
> | For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces
> support to
> | libxl for libxl_{disk,nic}_backend_untrusted environment variable to be
> used in
> | order to set whether disk and network backends should be trusted. Patch 2
> | reverts patch 1 and instead provides the more fine grained per-device
> options
> | that break the libxl ABI.
> |
> | Note that applying patch 2 to any of the stable releases will require a
> rebuild
> | of any consumers of the libxl library, as it introduces an ABI breakage and
> | hence won't be applied to the official repository stable branches. Users of
> | stable releases wanting to use the functionality provided by patch 2 will
> need
> | to apply it manually.
>
> This is the reason that in fact for those four CVEs, weh ave marked
> for bullseye:
>
> [bullseye] - xen (Too intrusive too backport)
>
> The "signaling of whether a frontend should consider a backend as
> potentially malicious can be done **from either the Linux kernel
> command line or the toolstack.**" (highlighting is added by me).
>
> So IMHO it is similarly correct to track src:xen under those CVEs, and
> they are marked as fixed with 4.16.2-1. *But* for bullseye, they can
> be ignored due to above reasons.
Yes, so the Xen part is about the "reporting whether the backend is to
be trusted".
That 'patch 1', the all-or-nothing option to signal the guest kernel is
now included with this update. But neither that change, nor the more
fine-grained patch 2 is directly linked to a CVE number. That change on
itself will not fix anything for any of the 4 CVE numbers.
Also, for 4.16 the story is the same, by the way. It's only in 4.17
which is to be released in the upcoming week that the otherwise lilbxl
ABI breaking changes are fully included, but even that doesn't change
anything for the CVE administration.
After all, it is a bit of a moot point for us. The only scenario in
which all of this is relevant is when using a 'driver domain' to
delegate the blk/net backend part to another untrusted guest domain.
Using this functionality is not properly enabled/supported out of the
box in our package builds for Debian.
Sometimes these XSA are like a little scavenger hunt.
Hans
Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
Aha!
On 02/11/2022 21:53, Salvatore Bonaccorso wrote:
> Hi,
>
> On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 10/19/22 21:55, Moritz Muehlenhoff wrote:
>>>>> For the latest set of Xen issues my estimate is that we can postpone
>>>>> them until the next batch, they seem all of moderate/limited impact.
>>>>> But let me know if you think otherwise.
>>>>
>>>> I agree. Let's do them together with the new stuff that's planned for
>>>> Nov 1st, https://xenbits.xen.org/xsa/
>>>
>>> Ack, I've updated the Security Tracker.
>>
>> I'm having a look at this now, and while writing the changelog entry, I
>> run into the following thing:
>>
>> XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes done
>> to Linux, and the other two are about changes to Xen. Shouldn't the
>> Debian security tracker reflect that?
>>
>> CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
>> CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
>
> Speaking for src:linux I do not think we need to change the tracking:
>
> CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data in shared
> pages")
> CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data in shared
> pages")
> CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data bouncing when backend
> is untrusted")
> CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data bouncing when backend
> is untrusted")
Riiight. Thanks, now I get why I cannot find any CVE number related to
XSA-403 listed in the Xen upstream changes (at least for 4.14 which I'm
working on now). They're all over there at the Linux side.
Hans
Bug#1021668: [Pkg-xen-devel] Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
Hi, On 10/19/22 21:55, Moritz Muehlenhoff wrote: >>> For the latest set of Xen issues my estimate is that we can postpone >>> them until the next batch, they seem all of moderate/limited impact. >>> But let me know if you think otherwise. >> >> I agree. Let's do them together with the new stuff that's planned for >> Nov 1st, https://xenbits.xen.org/xsa/ > > Ack, I've updated the Security Tracker. I'm having a look at this now, and while writing the changelog entry, I run into the following thing: XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes done to Linux, and the other two are about changes to Xen. Shouldn't the Debian security tracker reflect that? CVE-2022-26365 CVE-2022-33740 -> src:linux only ? CVE-2022-33741 CVE-2022-33742 -> src:xen only ? And for XSA-403, at first upstream was unsure about what to do for older Xen versions where the patches would be an ABI breaker. In the end, they did apply the more coarse-grained patch to at least offer some kind of mitigation in case a user wants to use it. So, the changelog line I'm including now will just be: - Linux disk/nic frontends data leaks XSA-403 CVE-2022-33741 CVE-2022-33742 HTH, Hans
Bug#1021668: [Pkg-xen-devel] Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
Hi, On 18/10/2022 22:31, Moritz Muehlenhoff wrote: > On Tue, Oct 18, 2022 at 02:17:32PM +0200, Hans van Kranenburg wrote: >> Does explicitly opening a BTS bug mean that, like we use to call it, >> "these CVEs warrant a DSA", > > No, in general we aim to file bugs for any open CVEs regardless of > the DSA state. This allows people to see that an issue is known > (and some maintainers might also not have noticed in time). Ok! >> and that it is a request for an ASAP package >> update and preparing a security update for stable, or, is this a new >> thing where BTS bugs are opened for packages, just in case the >> maintainer did not already track security issues themselves actively? > > For the latest set of Xen issues my estimate is that we can postpone > them until the next batch, they seem all of moderate/limited impact. > But let me know if you think otherwise. I agree. Let's do them together with the new stuff that's planned for Nov 1st, https://xenbits.xen.org/xsa/ Hans
Bug#1021668: [Pkg-xen-devel] Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
Hi! On 10/12/22 19:38, Moritz Mühlenhoff wrote: > Source: xen > X-Debbugs-CC: t...@security.debian.org > Severity: important > Tags: security > > Hi, > > The following vulnerabilities were published for xen. > > CVE-[...] Thanks for the overview. The XAPI one indeed does not apply to src:xen. I have a question, since the 'bug' report does not contain a question, or explicit call for action, and I have not seen it in this way before. Does explicitly opening a BTS bug mean that, like we use to call it, "these CVEs warrant a DSA", and that it is a request for an ASAP package update and preparing a security update for stable, or, is this a new thing where BTS bugs are opened for packages, just in case the maintainer did not already track security issues themselves actively? I'm just wondering... Thanks, Hans
Bug#1021449: cargo: Cargo is not able to build minidump-stackwalk
Package: cargo Version: 0.47.0-3+b1 Severity: normal X-Debbugs-Cc: hans.wolters@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I have a hubzilla instance hosted and one of the channels I own shows a crash and sends it to firefox. I was trying to build minidump-stackwalk * What exactly did you do (or not do) that was effective (or ineffective)? I installed cargo in order to build the crates for minidump-stackwalk * What was the outcome of this action? Cargo stated minidump-stalkwalk is only available for the 2021 version, debian stable supports only versions up to 2018 * What outcome did you expect instead? :-) *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-18-amd64 (SMP w/20 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cargo depends on: ii binutils 2.35.2-2 ii clang-11 [c-compiler] 1:11.0.1-2 ii gcc [c-compiler] 4:10.2.1-1 ii gcc-10 [c-compiler]10.2.1-6 ii libc6 2.31-13+deb11u4 ii libcurl3-gnutls7.74.0-1.3+deb11u3 ii libgcc-s1 10.2.1-6 ii libgit2-1.11.1.0+dfsg.1-4 ii libssh2-1 1.9.0-2 ii libssl1.1 1.1.1n-0+deb11u3 ii rustc 1.48.0+dfsg1-2 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 cargo recommends no packages. Versions of packages cargo suggests: pn cargo-doc ii python33.9.2-3 -- no debconf information
Bug#1021382: lxqt: Always wants root password for SMART Control
Package: lxqt Version: 30 Severity: normal Dear Maintainer, I am running LXQT on an EEEPC with debian/stable. There is an issue, I cannot exactly specify, which part is responsible, so let me just describe it. When started LXQT the first time, a window pops up and wants to enter the root password, so that it can actualize the smart-data for the harddrive. When done so, the window disappears. However, when I leave LXQT and change to a console by using "CTL + ALT + 2", and revert back to X with "CTL + 7" (terminal 7 is where the window manager is running), this behaviour appears again and I have to enter the root password again. This happens every time ands can be reliable repeated. As this might also be a security issue (can be misused by shoulder surfing or somehow else, it is a little bit annoying, too). It would be nice, if you could fix this. I tested this with other window managers, too, like LXDE, KDE and XFCE, there this behaviour did not appear. Thank you very much for any help! Best regards Hans -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-18-686 (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxqt depends on: ii ark 4:20.12.2-1 ii clipit1.4.4+git20190202-2 ii featherpad0.17.1-1 ii kwin-x11 [x-window-manager] 4:5.20.5-1 ii lightdm [x-display-manager] 1.26.0-7 ii lximage-qt0.16.0-1 ii lxqt-about0.16.0-1 ii lxqt-admin0.16.0-1 ii lxqt-branding-debian [lxqt-branding] 0.14.0.3 ii lxqt-core 30 ii lxqt-openssh-askpass 0.16.0-1 ii lxqt-powermanagement 0.16.0-1 ii lxqt-sudo 0.16.0-1 ii openbox [x-window-manager]3.6.1-9+deb11u1 ii pavucontrol 4.0-2 ii qlipper 1:5.1.2-1+b1 ii qps 2.2.0-1 ii qterminal 0.16.1-1 ii qttranslations5-l10n 5.15.2-2 ii sddm [x-display-manager] 0.19.0-3 ii sddm-theme-elarun [sddm-theme]0.19.0-3 ii sddm-theme-maldives [sddm-theme] 0.19.0-3 ii sddm-theme-maui [sddm-theme] 0.19.0-3 ii xarchiver 1:0.5.4.17-2 Versions of packages lxqt recommends: ii audacious4.0.5-1 ii bsd-mailx [mail-reader] 8.1.2-0.20180807cvs-2 ii chromium [www-browser] 106.0.5249.91-1~deb11u1 ii claws-mail [mail-reader] 3.17.8-1+b1 ii dillo [www-browser] 3.0.5-7 ii emacs-nox [mail-reader] 1:27.1+1-3.1 ii evolution [mail-reader] 3.38.3-1 ii feathernotes 0.8.0-1 ii firefox-esr [www-browser]102.3.0esr-1~deb11u1 ii gucharmap1:13.0.5-1 ii hexchat 2.14.3-6+deb11u1 ii im [mail-reader] 1:153-4 ii irssi1.2.3-1 ii kmail [mail-reader] 4:20.08.3-1 ii konqueror [www-browser] 4:20.12.0-4 ii lynx [www-browser] 2.9.0dev.6-3~deb11u1 ii mailutils [mail-reader] 1:3.10-3+b1 ii meteo-qt 2.1-1 ii mutt [mail-reader] 2.0.5-4.1+deb11u1 ii network-manager-gnome1.20.0-3 ii plasma-nm4:5.20.5-3 ii preload 0.6.4-5 ii qpdfview 0.4.18-5 ii s-nail [mail-reader] 14.9.22-1 ii screengrab 2.1.0-1 ii smplayer 20.6.0~ds0-1 ii smtube 18.3.0-1+b1 ii thunderbird [mail-reader]1:102.3.0-1~deb11u1 ii vm [mail-reader] 8.2.0b-7 ii w3m [www-browser]0.5.3+git20210102-6 ii weechat 3.0-1+deb11u1 ii xemacs21-mule [www-browser] 21.4.24-9 Versions of packages lxqt suggests: ii calibre 5.12.0+dfsg-1+deb11u1 ii compton-conf0.16.0-1 pn juffed pn nomacs ii obconf-qt 0.16.0-1 ii qt5-style-kvantum 0.18.0+repack-1 ii qtpass 1.3.2-3 pn shutter ii vokoscreen-ng [vokoscreen] 3.0.7-1 -- no debconf information
Bug#1021215: Kind request for backports of libtraceevent and libtracefs
Package: src:libtraceevent
Version: 1:1.1.2-1
Hi maintainer, :)
Linux commit fe4d0d5dde ("rtla/Makefile: Properly handle dependencies")
helps making the dependency on libtraceevent and libtracefs more
explicit, so that the users run into less weird problems on the go.
Linux 5.19 is in Debian unstable now, and for the stable-backports
packages that our kernel team is providing, this means that it will
FTBFS, unless we either:
- exclude rtla for bullseye-backports
- have backports for libtraceevent and libtracefs present
So, the question for you is: Do you want to also provide
bullseye-backports packages for libtraceevent and libtracefs?
About making dependencies explicit in the kernel package:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/539
Currently shipping without rtla, so far:
https://salsa.debian.org/benh/linux/-/commit/15b6859742d404abdcd68bcb589f8a8e2dfb6ce4
Thanks,
Hans
Bug#1020787: Xen: After updating to 5.19 kernel the VMs are started without XSAVE CPU flags
Hi! On 9/28/22 00:55, Diederik de Haas wrote: > On Wednesday, 28 September 2022 00:24:27 CEST Patrick wrote: >> I just applied the patch >> (xen.git-c3bd0b83ea5b7c0da6542687436042eeea1e7909.patch) to the xen >> packages and can confirm that this fixes the problems. The xsave flags are >> available again and thus the binaries work too. > > That is awesome, thank you :-) > > IIUC: > - Xen upstream will backport the patch to the stable branches; I do not know > when that will happen > - Debian's package will probably be updated before that and 4.16.2-2 will be > uploaded to Sid Soon (tm) with that patch applied Thanks for doing the investigation! I'm currently preparing 4.16.2-2 which includes the fix. Hans
Bug#1020786: kmail - option "delete double mails" in folder options not working
Package: kmail Version: 4:20.08.3-1 Severity: normal Dear Maintainer, there is an issue in kmail, which is present already since several years. I discovered, that the folder option "delete double mails" which is called by "CTL + *" is not working. During the last years, in my folders are many mails double, triple or even multi,caused by akonadi crashes, and I would like, to geht rid of it. So it would be nice, if you could take a look at this very usefull feature. Thank you very much for your help. Best regards Hans -- 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.10.0-18-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kmail depends on: ii akonadi-server4:20.08.3-3 ii kdepim-runtime4:20.08.3-1 ii kio 5.78.0-5 ii libc6 2.32-4 ii libgcc-s1 10.2.1-6 ii libgpgmepp6 1.16.0-1.1 ii libkf5akonadiagentbase5 [libkf5akonadiagentbase5-20.08] 4:20.08.3-3 ii libkf5akonadicontact5 [libkf5akonadicontact5-20.08] 4:20.08.3-1 ii libkf5akonadicore5abi2 [libkf5akonadicore5-20.08] 4:20.08.3-3 ii libkf5akonadimime5 [libkf5akonadimime5-20.08] 4:20.08.3-1 ii libkf5akonadisearch-bin 4:20.08.3-1 ii libkf5akonadisearch-plugins 4:20.08.3-1 ii libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-20.08] 4:20.08.3-1 ii libkf5akonadisearchpim5 [libkf5akonadisearchpim5-20.08] 4:20.08.3-1 ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08] 4:20.08.3-3 ii libkf5bookmarks5 5.86.0-1 ii libkf5calendarcore5abi2 5:5.86.0-1 ii libkf5calendarutils5 [libkf5calendarutils5-20.08] 4:20.08.3-1 ii libkf5codecs5 5.86.0-1 ii libkf5completion5 5.86.0-1 ii libkf5configcore5 5.86.0-1 ii libkf5configgui5 5.86.0-1 ii libkf5configwidgets5 5.86.0-1 ii libkf5contacts5 5:5.86.0-1 ii libkf5coreaddons5 5.86.0-1 ii libkf5crash5 5.86.0-1 ii libkf5dbusaddons5 5.86.0-1 ii libkf5grantleetheme-plugins 20.08.3-1 ii libkf5gravatar5abi2 [libkf5gravatar5-20.08] 4:20.08.3-1 ii libkf5guiaddons5 5.86.0-1 ii libkf5i18n5 5.86.0-1 ii libkf5iconthemes5 5.86.0-1 ii libkf5identitymanagement5 [libkf5identitymanagement5-20.08] 20.08.3-1 ii libkf5itemmodels5 5.86.0-1 ii libkf5itemviews5 5.86.0-1 ii libkf5jobwidgets5 5.86.0-1 ii libkf5kcmutils5 5.86.0-1 ii libkf5kiocore55.86.0-1 ii libkf5kiofilewidgets5 5.86.0-1 ii libkf5kiogui5 5.86.0-1 ii libkf5kiowidgets5 5.86.0-1 ii libkf5kontactinterface5 [libkf5kontactinterface5-20.08] 20.08.3-1 ii libkf5ksieveui5 [libkf5ksieveui5-20.08] 4:20.08.3-1 ii libkf5ldap5abi1 [libkf5ldap5-20.08] 20.08.3-1 ii libkf5libkdepim5 [libkf5libkdepim5-20.08] 4:20.08.3-1 ii libkf5libkleo5 [libkf5libkleo5-20.08] 4:20.08.3-1 ii libkf5mailcommon5abi2 [libkf5mailcommon5-20.08] 4:20.08.3-1 ii libkf5mailtransport5 [libkf5mailtransport5-20.08] 20.08.3-1 ii libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-20. 20.08.3-1 ii libkf5messagecomposer5abi1 [libkf5messagecomposer5-20.08] 4:20.08.3-5 ii libkf5messagecore5abi1 [libkf5messagecore5-20.08] 4:20.08.3-5 ii li
Bug#1019148: pulseaudio: Chromebook delbin-xhvi: not detecting earphone/headset, no mic input, no headphone output
Package: pulseaudio Version: 15.0+dfsg1-4+b1 Severity: important Dear Maintainer, I installed bullseye on a Asus Chromebook Flip C536E (delbin-xhvi), then upgraded it to Debian/testing to get more things working. Almost everything is working well in bookworm, there are just some audio issues. Sound output via the speakers works well, as does volume control. What does not work is: * No sound output to headphones or headsets * No mic input at all, both on the device mic and headset mics. * No detection when plugging in headphones or a headset (no GNOME prompt). The sound keeps playing out of the speakers. This is a TigerLake Chromebook, so it should be maintained in upstream Linux and ALSA, and source repos are available. I tried the experimental 5.19 kernel, but that didn't change anything. This computer seems closely related to the 'delbin' model, though not exactly the same: Asus Chromebook Flip CX5 (delbin) vs. Asus Chromebook Flip C536E (delbin-xhvi). Both are "volteer" boards. There are a whole range of "delbin" laptops that are well speced and good candidates for solid Debian machines. -- Package-specific info: File '/etc/default/pulseaudio' does not exist -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/4 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 pulseaudio depends on: ii adduser 3.128 ii init-system-helpers 1.64 ii libasound2 1.2.7.2-1 ii libasound2-plugins 1.2.7.1-1 ii libc6 2.34-4 ii libcap2 1:2.44-1 ii libdbus-1-3 1.14.0-2 ii libfftw3-single33.3.8-2 ii libgcc-s1 12.2.0-1 ii libglib2.0-02.72.3-1+b1 ii libgstreamer-plugins-base1.0-0 1.20.3-2 ii libgstreamer1.0-0 1.20.3-1 ii libice6 2:1.0.10-1 ii libltdl72.4.7-4 ii liborc-0.4-01:0.4.32-2 ii libpulse0 15.0+dfsg1-4+b1 ii libsm6 2:1.2.3-1 ii libsndfile1 1.0.31-2 ii libsoxr00.1.3-4 ii libspeexdsp11.2.0-1 ii libstdc++6 12.2.0-1 ii libsystemd0 251.3-1 ii libtdb1 1.4.6-3 ii libudev1251.3-1 ii libwebrtc-audio-processing1 0.3-1+b1 ii libx11-62:1.8.1-2 ii libx11-xcb1 2:1.8.1-2 ii libxcb1 1.15-1 ii libxtst62:1.2.3-1.1 ii lsb-base11.2 ii pulseaudio-utils15.0+dfsg1-4+b1 Versions of packages pulseaudio recommends: ii dbus-user-session1.14.0-2 ii libpam-systemd [logind] 251.3-1 ii rtkit0.13-4 Versions of packages pulseaudio suggests: pn paprefs pn pavucontrol pn pavumeter ii udev 251.3-1 Additional packages that might be relevant: ii alsa-topology-conf 1.2.5.1-2 ii alsa-ucm-conf 1.2.7.2-1 ii alsa-utils 1.2.7-1 ii firmware-amd-graphics 20210818-1 ii firmware-intel-sound20210818-1 ii firmware-iwlwifi20210818-1 ii firmware-linux-free 20200122-1 ii firmware-misc-nonfree 20210818-1 ii firmware-sof-signed 2.1.1-1 -- no debconf information $ pactl list short sinks 0 alsa_output.pci-_00_1f.3-platform-tgl_mx98373_rt5682.stereo-fallback module-alsa-card.c s16le 2ch 48000Hz SUSPENDED $ pactl list short sources 0 alsa_output.pci-_00_1f.3-platform-tgl_mx98373_rt5682.stereo-fallback.monitor module-alsa-card.c s16le 2ch 48000Hz SUSPENDED 1 alsa_input.pci-_00_1f.3-platform-tgl_mx98373_rt5682.stereo-fallback module-alsa-card.c s16le 2ch 48000Hz SUSPENDED # aplay -L null Discard all samples (playback) or generate zero samples (capture) lavrate Rate Converter Plugin Using Libav/FFmpeg Library samplerate Rate Converter Plugin Using Samplerate Library speexrate Rate Converter Plugin Using Speex Resampler jack JACK Audio Connection Kit oss Open Sound System pulse PulseAudio Sound Server speex Plugin using Speex DSP (resample, agc, denoise, echo, dereverb) upmix Plugin for channel upmix (4,6,8) vdownmix Plugin for channel downmix (stereo) with a simple spacialization hw:CARD=sofrt5682,DEV=0 sof-rt5682, Direct hardware device without any conversions hw:CARD=sofrt5682,DEV=1 sof-rt5682, Direct hardware device without any conversions hw:CARD=sofrt5682,DEV=2
Bug#1016547: [Pkg-xen-devel] Bug#1016547: /etc/default/grub.d/xen.cfg: Extraneous output line causes error message at boot
Hi John, On 8/2/22 19:50, John E. Krokes wrote: > Package: xen-hypervisor-common > Version: 4.14.5+24-g87d90d511c-1 > Severity: minor > File: /etc/default/grub.d/xen.cfg > > Dear Maintainer, > > When invoked via grub-mkconfig, xen.cfg outputs this as its first line: > Including Xen overrides from /etc/default/grub.d/xen.cfg > > The output of grub-mkconfig is expected to be redirected into a grub.cfg file. > Grub will read the grub.cfg at boot. Unfortunately, "Including" is not a > valid grub command. So when booting, grub emits this error message before > displaying its menu: > error: can't find command `Including'. Aha! Nice catch. That's indeed something that should be improved. > [...] > > The error message is obscured very quickly. It does not affect functionality > in any way. It requires booting on a VERY slow machine in order to read > the error message at all. > > > If I add a '#' to the start of the "Including", the resulting grub config file > boots with no error. > echo "#Including Xen overrides from /etc/default/grub.d/xen.cfg" > > I'm not sure if this line was intended to go into the generated config > file as a comment, or if it was intended to be shown to the user while > grub-mkconfig is running. I'm sure it's the latter, yes. Just some 'hey! I'm doing this now' message. > I have observed this and tested my fix against version > 4.14.5+24-g87d90d511c-1 of xen-hypervisor-common. I have also checked > with the debian git at > https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/tree/xen-hypervisor-common/etc/default/grub.d/xen.cfg. > This line > has not changed in a very long time. > > > I can also duplicate the behavior using grub-emu, with the output redirected > to a file. > > > I am running devuan, and originally reported this to their BTS but was > redirected to debian. So my version number does not match. Apologies for > that. It's ok. The changes/improvements for this will end up in the Xen 4.16 package that's in Debian unstable now, anyway. So, in our grub.d/xen.cfg file, there's two places that cause text output: the 'Including Xen overrides ...' informational one, and the notification/warning about overriding GRUB_DEFAULT. The grub.d/* files are executed (sourced) in the context of the grub-mkconfig itself using '.'. In there, I can see that similar status messages are just redirected to stderr. We can do the same here. For the warning, there's a grub_warn helper function, which we can use. So, that results in the follow changes I have here now: diff --git a/default/grub.d/xen.cfg b/default/grub.d/xen.cfg index d35744e..42670eb 100644 --- a/default/grub.d/xen.cfg +++ b/default/grub.d/xen.cfg @@ -5,7 +5,7 @@ # The configuration in here makes it possible to have different options set # for the linux kernel when booting with or without Xen. -echo "Including Xen overrides from /etc/default/grub.d/xen.cfg" +echo "Including Xen overrides from /etc/default/grub.d/xen.cfg" >&2 ### # Xen Hypervisor Command Line Options @@ -83,8 +83,8 @@ GRUB_CMDLINE_LINUX_XEN_REPLACE="earlyprintk=xen console=hvc0 noresume" #XEN_OVERRIDE_GRUB_DEFAULT= # if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "" ]; then - echo "WARNING: GRUB_DEFAULT changed to boot into Xen by default!" - echo " Edit /etc/default/grub.d/xen.cfg to avoid this warning." + grub_warn "GRUB_DEFAULT changed to boot into Xen by default!" \ + "Edit /etc/default/grub.d/xen.cfg to avoid this warning." XEN_OVERRIDE_GRUB_DEFAULT=1 fi if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then None of this output will now be mixed with the generated config any more. This will be in the next package upload. https://salsa.debian.org/xen-team/debian-xen/-/commits/wip/sid Thanks, Hans
Bug#1012451: Control: fixed 1012451 31.0.2
Control: fixed 1012451 31.0.2
Bug#1012451: [Android-tools-devel] Bug#1012451: apksigner: Using PKCS11 keystore fails with NoSuchMethodException
That was exactly what I was asking, thanks for the testing. My guess is that upstream has fixed this in newer releases. There is work underway to update this package. Plus there is a newer version available in bullseye-backports: 31.0.2-1~bpo11+1: all
Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)
Thanks for mapping it out. Do you have any contact to upstream? If so, could you request the new release? I can update the package. Emmanuel Kasper: Hi I took some time to revisit this bug in regards to vagrant libvirt developments. I see vagrant-libvirt upstream has merged in virtio-scsi support, which we needed for discard (https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692/commits) So the next steps should be: - upstream to release a new version of libvirt with virtio-scsi support - Debian to package it - change the libvirt vagrant box to use virtio-scsi. It should be enough to set the disk bus to scsi then vagrant-libvirt will set the controller type to virtio-iscsi by default - add the `discard` option so that deleted disk blocks in the VM are also deleted in the file disk image - finally bump the disk image size in the build process
