Bug#1062209: 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#1062110: 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#1062209: 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#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#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#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#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#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#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#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#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#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#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#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#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.alsa:
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#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#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/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
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#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
Bug#779893: some packaging progress
Aloïs and Dmitry have done some work towards packaging this: https://salsa.debian.org/go-team/packages/go-ipfs
Bug#1013344: dbus-user-session
here's an upstream issue with more info: https://github.com/containers/podman/issues/5443#issuecomment-599415883
Bug#1013344: dbus-user-session
I got the same thing. I installed dbus-user-session and rebooted, then this error message went away and things worked.
Bug#1013344: dbus-user-session
and another: https://github.com/containers/podman/issues/5906
Bug#1004344: how to generate list of JS deps to package
Thanks for the ongoing maintenance of buildbot! F-Droid is in the process of moving to buildbot. We generally try to maintain all of our systems using Debian packages, so we might be able to contribute to getting those JS deps in Debian. Is there a quick way to find out the list of what's missing? I'm not a JS dev at all, but I've been able to package Go and Ruby packages without knowing those languages, so it might also work here.
Bug#869169: packaged and uploaded
> Nilson is already working on this package at https://salsa.debian.org/nilsonfsilva/minisign. > Is there a reason for creating that repo when you do not own the ITP? Do you want to sponsor Nilson? Sorry, I didn't mean to step on anyone's toes. I'd be very happy if Nilson wants to be the maintainer of the minisign package. We can move the package to whichever salsa repo he wants. Also, I don't need to be a maintainer of this package, I maintain enough already. I'm flexible and open on all this, I just wanted to get minisign into Debian and didn't find signs of progress on the ITP bug. > A side note: signify-openbsd is already in the archive. This is almost the same (https://github.com/aperezdc/signify/issues/20). Why should we package minisign in addition? signify-openbsd is a different codebase with a different feature set. They are similar, but far from the same thing.
Bug#869169: packaged and uploaded
https://salsa.debian.org/debian/minisign
Bug#968043: merge request ready
https://salsa.debian.org/python-team/packages/black/-/merge_requests/5
Bug#1012451: [Android-tools-devel] Bug#1012451: apksigner: Using PKCS11 keystore fails with NoSuchMethodException
Thanks for the detailed bug report. Have you tried using the Google binaries? Does this also happen there? IIRC upstream fixed some bugs related to smartcards in recent releases.
Bug#1009853: RM: transifex-client [all] -- RoM
Package: ftp.debian.org Severity: normal Please remove transifex-client source and binary packages from unstable and testing. Upstream has sunsetted it and no longer supports it. * https://community.transifex.com/t/postponing-api-2-0-2-5-and-transifex-client-sunset-date/2759 * https://github.com/transifex/transifex-client Upstream says this is the replacement: https://github.com/transifex/cli
Bug#992692: moar
There is also discussion about making the official Debian Docker images use HTTPS: https://github.com/debuerreotype/docker-debian-artifacts/issues/15
Bug#992692: more steps towards this goal
Another step towards this goal: the official Debian Vagrant images will default to HTTPS: https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/15 There are already many Debian mirrors that support HTTPS, not just CDNs. Here's a script to find HTTPS mirrors https://gist.github.com/HacKanCuBa/e3a998d68a82f81dbf11f2cce4f26d04 I think all mirrors should support HTTPS (this is a requirement for f-droid.org mirrors), so I filed a bug to track that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008652
Bug#1008652: mirrors must support HTTPS in order to be considered official
Package: general Severity: wishlist Since the beginning of F-Droid, we have required that official package repos and mirrors use HTTPS. We have encouraged all of them to have HTTPS. I think Debian should do the same. There are already very many Debian mirrors that do support HTTPS, here's a script to find them: https://gist.github.com/HacKanCuBa/e3a998d68a82f81dbf11f2cce4f26d04 If all Debian official mirrors supported HTTPS, then it would be much easier for Debian systems to default to using HTTPS for apt repos. This is related to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692
Bug#1007977: [Android-tools-devel] Bug#1007977: android-platform-system-core: builds adb which is also built (at a higher version) by android-platform-tools
Right, this is an ongoing, incomplete migration. Anything that is built in android-platform-tools should be removed from android-platform-system-core or any other android-platform-* packages. We welcome contributions there!
Bug#989462: Info received (About bumping Vagrant box disk image to 1TB)
> - you add to your pull request a change of the virtualized disk
> controller from virtio-blk to virtio-scsi and to the default libvirt
> vagrantfile the "unmap" option so that deletion of blocks in the guest
> are propagated om host storage
I looked into this a bit more. These feature weren't added to vagrant-libvirt
until 0.4.0, so no stable Debian package of vagrant-libvirt could support this
yet. Debian/testing has 0.7.0, and a backport to stable would be possible. I
guess a lot of people just use `vagrant plugin install ...`. It might be
possible to make it work with older vagrant-libvirt versions by using a hack
like this:
https://github.com/vagrant-libvirt/vagrant-libvirt/pull/692#issuecomment-922329049
There is a little more info here:
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/999#issuecomment-487728207
```
ENV['VAGRANT_EXPERIMENTAL'] = 'typed_triggers'
require 'open3'
Vagrant.configure('2') do |config|
...
config.vm.provider :libvirt do |lv, config|
lv.storage :file, :size => '3G', :device => 'sda', :bus => 'scsi', :discard
=> 'unmap', :cache => 'unsafe'
config.trigger.before
:'VagrantPlugins::ProviderLibvirt::Action::StartDomain', type: :action do |trigger|
trigger.ruby do |env, machine|
stdout, stderr, status = Open3.capture3(
'virt-xml', machine.id,
'--edit', 'type=scsi',
'--controller', 'model=virtio-scsi')
if status.exitstatus != 0
raise "failed to run virt-xml to modify the controller model.
status=#{status.exitstatus} stdout=#{stdout} stderr=#{stderr}"
end
end
end
...
end
end
```
Bug#989462: About bumping Vagrant box disk image to 1TB
Emmanuel Kasper: I did some testing around https://salsa.debian.org/cloud-team/debian-vagrant-images/-/tree/1TBv2 (not merged in master yet) and I am still reluctant to merge the branch. I am OK to bump the default disk size to something like 40GB but not to 1TB. The problem with the disk size of 1TB is as such: when you do a lot of write / erase cycles, the deletion of blocks is not propagated to the qcow2 backing disk image, so even though the OS in the VM reports only 2GB of block usage, the disk image could grow to 1TB, without the user knowing it. Yeah, I also thought about that. Would it be possible to ship the images with a disk/partition size of 1TB but keep a filesystem size of 20GB? It is easy to expand the filesystem as needed. The hard part is expanding the disk/partition size. I could reproduce this behavior running `fio` in the guest in a loop. I find this behavior dangerous. At that point I see three possibilities: - you add to your pull request a change of the virtualized disk controller from virtio-blk to virtio-scsi and to the default libvirt vagrantfile the "unmap" option so that deletion of blocks in the guest are propagated om host storage This sounds like the ideal solution. I have no idea how much work it would be. Do you? - you're fine with a disk image size of 40, or let's say 80GB Chromium builds can take more than 100GB, so either of those would mean we still need to make our own basebox. - you use a shared folder for the builds. I just noticed vagrant-libvirt has also support for virtio-fs which according to its author has native host performance. If they are security concerns, let's discuss that in details and involve upstream if needed. virtio-fs is mature enough that it's use in production for Kata Containers in Kubernetes and OpenShift Sandboxed containers in the Red Hat Kubernetes offering. We like the security isolation of throwing away all things that the build process has written to, so this option is less appealing, though perhaps workable. It there was a host-controlled method of resetting the virtio-fs to a previous snapshot, then it could work. .hc
Bug#1001755: Acknowledgement (https://ftp-master.debian.org is blocked when coming via Tor)
As discussed in #debian-ftp It seems that based on the box's iptables, the blocking is coming from the hoster (Brown University), not the machine itself. One potential solution is moving the web pages off that box to a public webserver. That would also improve the security profile of that box.
Bug#1001755: https://ftp-master.debian.org is blocked when coming via Tor
Package: ftp.debian.org I've recently noticed that https://ftp-master.debian.org/ is not accessible over tor. I get "The connection has timed out. The server at ftp-master.debian.org is taking too long to respond." in the same browser where everything else is responsive. Curl says: $ https_proxy=http://localhost:8081 curl https://ftp-master.debian.org/new.html curl: (56) Received HTTP code 500 from proxy after CONNECT This works fine: https_proxy=http://localhost:8081 curl https://www.debian.org
Bug#1001420: ITP: sdkmanager - Package manager for Android SDK packages
Package: wnpp Severity: wishlist * Package name: sdkmanager Version : 0.4.1 Upstream Author : Hans-Christoph Steiner * URL : https://gitlab.com/fdroid/sdkmanager * License : AGPLv3 Programming Lang: Python Package source : https://salsa.debian.org/python-team/packages/sdkmanager Description: Package manager for Android SDK packages A drop-in replacement for sdkmanager from the Android SDK written in Python. It implements the exact API of the sdkmanager (https://developer.android.com/studio/command-line/sdkmanager) command line. It only deviates from that API if it can be done while being 100% compatible. . The project also attempts to maintain the same terminal output so it can be compatible with things that scrape sdkmanager output.
Bug#1001335:
Great to hear that pipelining is already in use! I guess HTTPS plus pipelining could mean that file size is no longer reliably readable for the network observer. I've never profiles TLS and pipelining to know if there are still visible signatures that would let the network observer find the borders of file downloads, so I can't personally say for sure that padding would not still be useful. I agree that padding to something like 1MB would be required to strip out all size metadata. A small amount of padding would obscure a lot of metadata since there are many packages that are close to the same size. I've also been thinking about general fingerprintability, not just detecting whether a specific security update is being applied. The general pattern of packages, could be enough to identify a lot of boxes. I was thinking this was a low hanging fruit. If it is not, and you don't want to track this, I'm fine with it being closed. OpenSSL does Record Padding also: https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
Bug#992692: next steps
I fully support the idea that HTTPS should become the default for apt repos. From what I gather, the open question is how best to handle auto-apt-proxy configuration. There seems to be a number of reasonable proposals: * Make auto-apt-proxy set "Acquire::https::Verify-Peer false;" * automate setting http at install time using preseed with auto-apt-proxy asking this as a debconf question. * Users can always later edit the sources.list. In the context of a BSP or DebConf, that is a very reasonable thing to ask. auto-apt-proxy sounds like a nice feature, but it also adds security risks. We also need to consider that. Users should get best practice security without thinking about it at all. That's HTTPS these days, despite its imperfections. Not defaulting to HTTPS means people have to be aware that HTTP is the default, then consider using HTTPS. We should of course make it as easy as possible to use caching proxies, that also comes with a responsibility in making the sure aware that it adds small but present security risks. So a debconf question in auto-apt-proxy seems like a good place for that. For those who think that apt's GPG verification is enough, consider these CVEs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1358 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1829 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3587 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1252 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0501 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462 For more on this whole topic, I wrote up a blog post based on my previous research and these ongoing discussions: https://guardianproject.info/2021/12/08/debian-over-https/
Bug#1001335: apt should use TLSv1.3 Record Padding to obscure file size metadata
Package: apt Version: 2.3.13 Severity: wishlist apt should pad its TLS connections to obscure the size of the downloaded files from network observers. Right now, an attacker could build an index of all package sizes, then track the size of HTTPS streams to Debian mirrors, and from that, be able to identify most of the packages being downloaded over HTTPS. TLSv1.3 added the possibility to add padding TLS connections: https://tools.ietf.org/id/draft-ietf-tls-tls13-21.html#rfc.section.5.4 GnuTLS already supports it: https://www.gnutls.org/manual/gnutls.html#On-Record-Padding
Bug#989462: synced dirs
synced dirs are difficult to manage when the use case is security-sensitive. In F-Droid production, they are only used during box creation. Then production builds do not use them. Also, some Android app builds are literally bigger than 20GB, and running the build in the synced folder would be painfully slow.
Bug#988789: also affects Android AAR files
Android AAR files are closely related to APKs in how they are structured. They are both ZIPs, JARs, and have some standard Android files. I have a repro case for this bug with AARs. All the files should be available here: https://share.mayfirst.org/s/nsEjNBE3EgfNYJe The diffoscope HTML report is attached. aar-so-diffoscope-bug.html.xz Description: application/xz
Bug#989462: set Vagrant box filesystem size to something much larger than 20GB
I think at least one of the F-Droid contributors could find some time to contribute to the Debian images if we have direction on what kind of solution you'd accept here. Sounds like you've provided some ideas already. Looks like VMDK is still not resizable, but it is possible to convert to VDI then back. We're aiming to move entirely to libvirt anyway, so a fix only in libvirt will still be very helpful.
Bug#989462: set Vagrant box filesystem size to something much larger than 20GB
Package: cloud.debian.org The Vagrant guidelines say: "you should create a dynamically resizing drive with a large maximum size. This causes the actual footprint of the drive to be small initially, but to dynamically grow towards the max size as disk space is needed, providing the most flexibility for the end user." https://www.vagrantup.com/docs/boxes/base Both VirtualBox and libvirt qcow2 formats support exactly that. The official Debian box seems to be set at a fixed 20GB. This makes it very difficult for F-Droid to use these images as the base box for our Vagrant boxes. https://gitlab.com/fdroid/fdroid-bootstrap-buildserver/-/issues/10 F-Droid's base box has been using 1TB for a long time with good results. gitlab.com/fdroid/basebox/ Once this is fixed in Debian's images, then F-Droid no longer needs the forked base box and can use only Debian's.
Bug#988789: diffoscope | .so files are compared using a binary diff within in Android APKs (#259)
I don't have one of the APKs still, but these should be close:
https://f-droid.org/repo/org.torproject.torservices_2001.apk
https://f-droid.org/repo/org.torproject.torservices_2002.apk
https://f-droid.org/repo/org.torproject.torservices_2003.apk
https://f-droid.org/repo/org.torproject.torservices_2004.apk
Then compare those with the ones here:
https://gitlab.com/guardianproject/torservices-nightly/-/tree/master/fdroid/repo
.hc
Emanuel Bronshtein (@e3amn2l):
Emanuel Bronshtein commented:
@eighthave can you link to the compared APK files that fail to diff the .so
files in order to debug this, thanks.
The issue might be related to the "No such file" error in diff output:
```
Command `'strings --all --bytes=8 {}'` failed with exit code 1. Standard
output:
│┄ /usr/bin/strings:
'/tmp/diffoscope_4_ifbg_p_release/tmpqowyi8ycapk/org.torproject.torservices_2004.apk/lib/arm64-v8a/libtor.so':
No such file
```
Bug#988789: diffoscope: .so files are compared using a binary diff in Android APKs
Package: diffoscope
Version: 172~bpo10+1
Severity: important
APKs (Android app files) often contain Linux ELF shared library files, e.g.
lib/arm64-v8a/libtor.so. These are only compared using a binary diff, but they
should use the shared library comparison. The output looks like:
├── lib/arm64-v8a/libtor.so
│┄ Command `'strings --all --bytes=8 {}'` failed with exit code 1. Standard
output:
│┄ /usr/bin/strings:
'/tmp/diffoscope_4_ifbg_p_release/tmpqowyi8ycapk/org.torproject.torservices_2004.apk/lib/arm64-v8a/libtor.so':
No such file
│ @@ -386405,15 +386405,15 @@
│ 005e5640: 0800
│ 005e5650: 5d00 0400 0200 ]...
│ 005e5660: 08cc 0a00 08cc 0a00
│ 005e5670: d06f 0500 0500 .o..
│ 005e5680: 0800 1800
│ 005e5690: 6700 0400 4200 g...B...
│ 005e56a0: d83b 1000 d83b 1000 .;...;..
│ -005e56b0: b016 0500 0b00
│ +005e56b0: b016 0500 1500
│ 005e56c0: 0800 1800
│ 005e56d0: 6c00 0100 0600 l...
│ 005e56e0: 9052 1000 9052 1000 .R...R..
│ 005e56f0: 400f @...
│ 005e5700: 1000 1000
│ 005e5710: 7100 0100 0600 q...
│ 005e5720: 0070 1000 0070 1000 .p...p..
When running diffoscope directly on the extracted libtor.so files, then I get
useful output:
--- ./ciarang/lib/arm64-v8a/libtor.so
+++
./app/build/intermediates/stripped_native_libs/release/out/lib/arm64-v8a/libtor.so
├── readelf --wide --sections {}
│ @@ -8,15 +8,15 @@
│[ 3] .hash HASH02e8 0002e8 012eb8 04
A 5 0 8
│[ 4] .gnu.hash GNU_HASH000131a0 0131a0 014ae4 00
A 5 0 8
│[ 5] .dynsym DYNSYM 00027c88 027c88 041688 18
A 6 3 8
│[ 6] .dynstr STRTAB 00069310 069310 03e17b 00
A 0 0 1
│[ 7] .gnu.version VERSYM 000a748c 0a748c 005736 02
A 5 0 2
│[ 8] .gnu.version_rVERNEED 000acbc8 0acbc8 40 00
A 6 2 8
│[ 9] .rela.dyn RELA000acc08 0acc08 056fd0 18
A 5 0 8
│ - [10] .rela.plt RELA00103bd8 103bd8 0016b0 18
AI 5 11 8
│ + [10] .rela.plt RELA00103bd8 103bd8 0016b0 18
AI 5 21 8
│[11] .plt PROGBITS00105290 105290 000f40 10
AX 0 0 16
│[12] .text PROGBITS00107000 107000 392da4 00
AX 0 0 4096
│[13] .rodata PROGBITS00499db0 499db0 0c5418 00
A 0 0 16
│[14] .eh_frame_hdr PROGBITS0055f1c8 55f1c8 00af84 00
A 0 0 4
│[15] .eh_frame PROGBITS0056a150 56a150 031280 00
A 0 0 8
│[16] .preinit_arrayPREINIT_ARRAY 0059cae0 59bae0 10 08
WA 0 0 8
│[17] .init_array INIT_ARRAY 0059caf0 59baf0 18 08
WA 0 0 8
├── readelf --wide --decompress --hex-dump=.plt {}
│ @@ -1,10 +1,9 @@
│
│ Hex dump of section '.plt':
│ - NOTE: This section has relocations against it, but these have NOT been
applied to this dump.
│0x00105290 f07bbfa9 90260090 11b644f9 10a22591 .{...&D...%.
│0x001052a0 20021fd6 1f2003d5 1f2003d5 1f2003d5 ... ... ..
│0x001052b0 90260090 11ba44f9 10c22591 20021fd6 .&D...%. ...
│0x001052c0 90260090 11be44f9 10e22591 20021fd6 .&D...%. ...
│0x001052d0 90260090 11c244f9 10022691 20021fd6 .&D...&. ...
│0x001052e0 90260090 11c644f9 10222691 20021fd6 .&D.."&. ...
│0x001052f0 90260090 11ca44f9 10422691 20021fd6 .&D..B&. ...
├── readelf --wide --decompress --hex-dump=.got {}
│ @@ -1,9 +1,10 @@
│
│ Hex dump of section '.got':
│ + NOTE: This section has relocations against it, but these have NOT been
applied to this dump.
│0x005d5958
│0x005d5968 90521000 .R..
│0x005d5978 90521000 90521000 .R...R..
│0x005d5988 90521000 90521000 .R...R..
│0x005d5998 90521000 90521000 .R...R..
│0x005d59a8 90521000 90521000 .R...R..
│0x005d59b8 90521000 90521000 .R...R..
-- System Information:
Debian Release: 10.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
'proposed-updates')
Architecture: amd64 (x86_64)
Kernel:
Bug#855422: xkb-data: Toshiba Chromebook 2 CB35 now has broken media keys
Package: xkb-data Version: 2.29-2 Followup-For: Bug #855422 X-Debbugs-Cc: h...@eds.org Dear Maintainer, I just installed bullseye on Toshiba Chromebook 2 CB35. Basically everything just worked, except that the media keys output F-key codes. All Chromebooks only have media keys, there are no keys labeled as F keys. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#988202: ftp.debian.org: metadata.ftp-master.debian.org has many files that are 403 Forbidden
Package: ftp.debian.org Severity: normal When doing some work surverying licenses in Debian, I found these errors: 404 Client Error: Not Found: https://metadata.ftp-master.debian.org/changelogs/main/p/php-psr-log/php-psr- log_1.0.0-2_copyright 403 Client Error: Forbidden: https://metadata.ftp-master.debian.org/changelogs/main/a/apt/apt_1.3_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.3.1_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.3~pre3+cmake2_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.3~rc1_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.3~rc2_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.3~rc3_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.3~rc4_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.4~beta1_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.4~beta2_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.4~beta3_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.4~beta4_copyright https://metadata.ftp- master.debian.org/changelogs/main/a/apt/apt_1.4~rc1_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.100_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.101_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.102_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.103_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.104_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.106_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.107_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.108_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.109_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.110_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.111_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.112_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.113_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.114_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.115_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.116_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.117_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.118_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.119_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.120_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.121_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.122_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.123_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.124_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.125_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.126_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.127_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.128_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.130_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.131_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.132_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.133_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.134_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.135_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.136_copyright https://metadata.ftp-master.debian.org/changelogs/main/c/console-setup/console- setup_1.137_copyright
Bug#987994: diffoscope: crash when comparing two ZIP files
Package: diffoscope
Version: 168~bpo10+1
Severity: important
Dear Maintainer,
I downloaded the job artifact files from two related GitLab CI jobs and
compared them:
https://gitlab.com/guardianproject/tor-android/-/jobs/1231242475/artifacts/download
https://gitlab.com/eighthave/tor-android/-/jobs/1227385382/artifacts/download
diffoscope --html jobzip.html \
tor-android_release_0.4.5.7_044c580d3aeed61b315cd1c22520bbba3137acfb.zip \
tor-android_release_0.4.5.7_044c580d3aeed61b315cd1c22520bbba3137acfb\(1\).zip
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 771, in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 725, in
run_diffoscope
difference = compare_root_paths(path1, path2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
69, in compare_root_paths
difference = compare_files(file1, file2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
125, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 499, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 436, in _compare_using_details
other.as_container, no_recurse=no_recurse
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py",
line 192, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
125, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 499, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py",
line 406, in _compare_using_details
details.extend(self.compare_details(other, source))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/debian.py", line
195, in compare_details
self._deb822.get_as_string("Checksums-Sha256"),
File "/usr/lib/python3/dist-packages/debian/deb822.py", line 1657, in
get_as_string
if hasattr(self[key], 'keys'): # single-line
File "/usr/lib/python3/dist-packages/debian/deb822.py", line 500, in
__getitem__
value = self.__dict[keyi]
KeyError: 'Checksums-Sha256'
-- System Information:
Debian Release: 10.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages diffoscope depends on:
ii diffoscope-minimal 168~bpo10+1
Versions of packages diffoscope recommends:
ii abootimg 0.6-1+b2
ii acl 2.2.53-4
ii apksigner30.0.3-4
ii apktool 2.4.1-1
ii binutils-multiarch 2.31.1-16
ii bzip21.0.6-9.2~deb10u1
ii caca-utils 0.99.beta19-2.1
ii colord 1.4.3-4
ii db-util 5.3.1+nmu1
ii default-jdk [java-sdk] 2:1.11-71
ii default-jdk-headless 2:1.11-71
ii device-tree-compiler 1.4.7-4
ii docx2txt 1.4-1
ii e2fsprogs1.44.5-1+deb10u3
ii enjarify 1:1.0.3-4
ii ffmpeg 7:4.1.6-1~deb10u1
ii fontforge-extras 0.3-4
ii fp-utils 3.0.4+dfsg-22
ii fp-utils-3.0.4 [fp-utils]3.0.4+dfsg-22
ii genisoimage 9:1.1.11-3+b2
ii gettext 0.19.8.1-9
ii ghc 8.4.4+dfsg1-3
ii ghostscript 9.27~dfsg-2+deb10u4
ii giflib-tools 5.1.4-3
ii gnumeric 1.12.44-1
ii gnupg2.2.12-1+deb10u1
ii gnupg-utils 2.2.12-1+deb10u1
ii hdf5-tools 1.10.4+repack-10
ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1
ii jsbeautifier 1.6.4-7
ii libarchive-tools 3.3.3-4+deb10u1
ii llvm 1:7.0-47
ii lz4 [liblz4-tool]1.8.3-1
ii mono-utils 5.18.0.240+dfsg-3
ii ocaml-nox4.05.0-11
ii odt2txt
Bug#987718: unblock: fdroidserver/2.0.1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package fdroidserver
F-Droid is built on Debian and is a community with the same goals as
Debian, modeled after Debian. The F-Droid community maintains stable
release branches for fdroidserver that are devoted to each Debian
release. buster has 1.1.x and bullseye has 2.0.x. I am both package
maintainer and upstream on this package, and a Debian Developer. The
2.0.1 release includes only narrow bug and compatibility fixes. This
package has an extensive autopkgtest suite.
These are specific issues that are fixed:
* corrupt app icons are published, instead of valid PNGs #987717
* stop setting up source repo when running lint/rewritemeta
https://gitlab.com/fdroid/fdroidserver/commit/92438bbf78532b89fb7619601cf75c95e7d7f0a0
* use latest SPDX license info
https://gitlab.com/fdroid/fdroidserver/commit/eca7b23fc9f742d9420ec068cf0d60e5bdcf497e
* crash on bad fastlane/triple-t files
https://gitlab.com/fdroid/fdroidserver/commit/cfbee12ad2a1385aaf0aa7d9076924373639d189
* crash on bad repo file:
https://gitlab.com/fdroid/fdroidserver/commit/240139baf9778536251b9deee4c0e071a2333ebb
Previous stable updates to fdroidserver are here:
* #960885
* #935809
* #856358
* #773166
Here's the debdiff, note that the majority of the changes are to test
files, which are also part of the autopkgtest run:
diff -Nru fdroidserver-2.0/CHANGELOG.md fdroidserver-2.0.1/CHANGELOG.md
--- fdroidserver-2.0/CHANGELOG.md 2021-02-01 22:53:44.0 +0100
+++ fdroidserver-2.0.1/CHANGELOG.md 2021-03-09 18:21:30.0 +0100
@@ -4,6 +4,20 @@
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
+## [2.0.1] - 2020-03-09
+
+### Fixed
+
+* metadata: stop setting up source repo when running lint/rewritemeta
+* scanner: show error if scan_binary fails to run apkanalyzer
+* common: properly parse version from NDK's source.properties
+* update: stop extracting and storing XML icons, they're useless
+* index: raise error rather than crash on bad repo file
+* update: handle large, corrupt, or inaccessible fastlane/triple-t files
+* Update SPDX License List
+* checkupdates: set User-Agent to make gitlab.com happy
+* Run push_binary_transparency only once
+
## [2.0] - 2020-01-31
For a more complete overview, see the [2.0
diff -Nru fdroidserver-2.0/debian/changelog fdroidserver-2.0.1/debian/changelog
--- fdroidserver-2.0/debian/changelog 2021-02-02 13:28:22.0 +0100
+++ fdroidserver-2.0.1/debian/changelog 2021-03-09 18:26:20.0 +0100
@@ -1,3 +1,9 @@
+fdroidserver (2.0.1-1) unstable; urgency=medium
+
+ * New upstream version 2.0.1
+
+ -- Hans-Christoph Steiner Tue, 09 Mar 2021 18:26:20 +0100
+
fdroidserver (2.0-1) unstable; urgency=medium
* New upstream version 2.0
diff -Nru fdroidserver-2.0/examples/fdroid_fetchsrclibs.py
fdroidserver-2.0.1/examples/fdroid_fetchsrclibs.py
--- fdroidserver-2.0/examples/fdroid_fetchsrclibs.py2021-02-01
22:53:44.0 +0100
+++ fdroidserver-2.0.1/examples/fdroid_fetchsrclibs.py 2021-03-09
18:21:30.0 +0100
@@ -21,7 +21,7 @@
options = parser.parse_args()
common.options = options
pkgs = common.read_pkg_args(options.appid, True)
-allapps = metadata.read_metadata(pkgs)
+allapps = metadata.read_metadata(pkgs, check_vcs=True)
apps = common.read_app_args(options.appid, allapps, True)
srclib_dir = os.path.join('build', 'srclib')
os.makedirs(srclib_dir, exist_ok=True)
diff -Nru fdroidserver-2.0/fdroidserver/build.py
fdroidserver-2.0.1/fdroidserver/build.py
--- fdroidserver-2.0/fdroidserver/build.py 2021-02-01 22:53:44.0
+0100
+++ fdroidserver-2.0.1/fdroidserver/build.py2021-03-09 18:21:30.0
+0100
@@ -1013,7 +1013,7 @@
# Read all app and srclib metadata
pkgs = common.read_pkg_args(options.appid, True)
-allapps = metadata.read_metadata(pkgs, options.refresh, sort_by_time=True)
+allapps = metadata.read_metadata(pkgs, options.refresh, sort_by_time=True,
check_vcs=True)
apps = common.read_app_args(options.appid, allapps, True)
for appid, app in list(apps.items()):
diff -Nru fdroidserver-2.0/fdroidserver/checkupdates.py
fdroidserver-2.0.1/fdroidserver/checkupdates.py
--- fdroidserver-2.0/fdroidserver/checkupdates.py 2021-02-01
22:53:44.0 +0100
+++ fdroidserver-2.0.1/fdroidserver/checkupdates.py 2021-03-09
18:21:30.0 +0100
@@ -35,6 +35,7 @@
from . import _
from . import common
from . import metadata
+from . import net
from .exception import VCSException, NoSubmodulesException, FDroidException,
MetaDataException
@@ -63,7 +64,7 @@
vercode = None
if len(urlcode) > 0:
logging.debug("...requesting {0}".format(urlcode))
-req = urllib.request.Request(
Bug#987717: fdroidserver: corrupt app icons are published, instead of valid PNGs
Package: fdroidserver Version: 2.0-1 Severity: important Control: forwarded -1 https://gitlab.com/fdroid/fdroidserver/-/issues/344 `fdroid update` is extracting and publishing the drawable XML file as the app's icon. This file on its own cannot be displayed. Sometimes, `fdroid update` chooses that file over an available PNG file, which would be displayable.
Bug#985800: apksigner: crashes on help for lineage and rotate subcommands
Package: apksigner Version: 30.0.3-3~bpo10+1 Severity: important Dear Maintainer, When running `apksigner lineage -h` or `apksigner rotate -h`, it just immediately crashes with no output. Other help strings work. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apksigner depends on: ii default-jre [java9-runtime] 2:1.11-71 ii libapksig-java 30.0.3-3~bpo10+1 ii openjdk-11-jre [java9-runtime] 11.0.9.1+1-1~deb10u2 apksigner recommends no packages. apksigner suggests no packages. -- no debconf information
Bug#985452: cowbuilder: add cron job to remove stray cow.[0-9]* dirs from /var/cache/pbuilder/build
Package: cowbuilder Version: 0.88 Severity: normal Tags: patch Tags: patch Dear Maintainer, I've been using cowbuilder a long time. I recently noticed that I had ~20gigs of stuff in /var/cache/pbuilder/build: .../pbuilder/build $ ls -ld cow.[02-9]* drwxr-xr-x 23 root root 4096 Dez 29 17:06 cow.21198 drwxr-xr-x 22 root root 4096 Nov 23 22:48 cow.21823 drwxr-xr-x 18 root root 4096 Jän 9 2020 cow.22112 drwxr-xr-x 22 root root 4096 Dez 13 00:31 cow.22971 drwxr-xr-x 22 root root 4096 Dez 12 22:51 cow.23828 drwxr-xr-x 22 root root 4096 Okt 8 18:01 cow.27699 drwxr-xr-x 22 root root 4096 Jän 3 15:05 cow.28802 drwxr-xr-x 22 root root 4096 Mai 14 2020 cow.30699 drwxr-xr-x 18 root root 4096 Aug 19 2020 cow.30973 drwxr-xr-x 22 root root 4096 Nov 24 14:38 cow.4974 drwxr-xr-x 22 root root 4096 Mai 26 2020 cow.6459 drwxr-xr-x 22 root root 4096 Jän 3 16:28 cow.7114 drwxr-xr-x 23 root root 4096 Dez 13 00:08 cow.7734 drwxr-xr-x 22 root root 4096 Feb 15 13:21 cow.8510 There were no active sessions, so it seems these are just forgotten detritus. I propose adding a cron job to clean those up. I attached one that works for me. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cowbuilder depends on: ii cowdancer0.88 ii libc62.28-10 ii libncurses6 6.1+20181013-2+deb10u2 ii libtinfo66.1+20181013-2+deb10u2 ii pbuilder 0.230.4 cowbuilder recommends no packages. cowbuilder suggests no packages. -- no debconf information #!/bin/sh -e for f in /var/cache/pbuilder/build/cow.[0-9]*; do test -d "$f" || continue kill -0 `echo $(basename $f) | sed s',cow\.,,'` 2> /dev/null && continue rm -rf --one-file-system "$f" done
Bug#984970: buildbot 2.10.2 in Debian/bullseye
Oh yeah, I guess so, if you think it'll be stable enough. I'm new to buildbot actually, but I'm currently moving F-Droid over to it, and we try to use everything out of Debian.
Bug#984970: buildbot 2.10.2 in Debian/bullseye
Package: buildbot Hey Robin, Thanks for your work maintaining builbot in Debian! Since the window is closing fast on getting updates into bullseye, I wanted to ask you whether you can upload the v2.10.2 release soon? .hc
Bug#973082: confirmed
Great! Then it sounds like it should be included. It is a Python Team package and the source code is on salsa, so feel free to go ahead and upload.
Bug#973082: confirmed
Do the tests pass with this patch?
Bug#980087: another case
This time in android-sdk-meta. The tests Depends: adb and android-tools-adb, both of which are not in ppc64el: https://salsa.debian.org/android-tools-team/android-sdk-meta/-/blob/master/debian/tests/control https://ci.debian.net/data/autopkgtest/testing/ppc64el/a/android-sdk-meta/10012608/log.gz command1 FAIL badpkg blame: android-sdk-meta badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. command2 FAIL badpkg blame: android-sdk-meta badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U.
Bug#980644: [Android-tools-devel] Bug#980644: android-sdk-platform-tools-common: no Multi-Arch annotation prevents adb upgrade
Thorsten Glaser: Hans-Christoph Steiner dixit: Right now, we can only commit to supporting the arches that upstream supports (amd64 and arm64), so I'm downgrading the severity. It’d be the same if you’d install either of these, it’s *not* an architecture-specific problem. I could never wrap my head around the Multi-Arch: stuff. Please consider doing so in the near future. Helmut Grohne can help if you have concrete questions as well. This is becoming more and more important. I have tried in the past. I have way too much going to spend more time on it. That's why we have team packages, so each person does not need to know all the details. Thanks for your contribution! I would accept a merge request on salsa for this, if it passes in gitlab-ci. It’s a one-liner that changes package metadata only, so it’s got no chance not to pass. I tested it locally yesterday already, so I’ll try to wrap my head around this Salsa thing and give you one. Thanks for taking the time to learn more about salsa! I think the salsa/gitlab workflow will really improve Debian because it is a very common workflow in software development, and it is built around making it easy for anyone to contribute. Having the build and CI integrated into the workflow is a really a bit win over having to upload to ftp-master to see the results. .hc
Bug#980644: [Android-tools-devel] Bug#980644: android-sdk-platform-tools-common: no Multi-Arch annotation prevents adb upgrade
Control: severity -1 normal Right now, we can only commit to supporting the arches that upstream supports (amd64 and arm64), so I'm downgrading the severity. I could never wrap my head around the Multi-Arch: stuff. I would accept a merge request on salsa for this, if it passes in gitlab-ci.
Bug#972377: can't reproduce
can't reproduce
Bug#980087: release.debian.org: autopkgtest fails trying to install packages not in arch
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: britney android-platform-art as this in debian/tests/control: https://salsa.debian.org/android-tools-team/android-platform-art/-/blob/master/debian/tests/control Tests: dexdump-dexlist Depends: dexdump, dexlist autopkgtest fails on ppc64el with: https://ci.debian.net/data/autopkgtest/testing/ppc64el/a/android-platform-art/9669069/log.gz E: Unable to locate package dexdump E: Unable to locate package dexlist dexdump and dexlist are part of src:android-platform-art but are not built for ppc64el. britney should automatically know that Depends: dexdump, dexlist cannot be fulfilled on ppc64el and skip the test. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#975747: reopen the close to work around BTS bug
Control: reopen -1
Bug#977912: This is due to aapt's linking error.
Control: reassign -1 aapt Control: merge 977023 977912 This is due to aapt's linking error. The fdroidserver tests rely on aapt.
Bug#975747: this is actually fixed
Control: fixed -1 1:10.0.0+r36-1 Control: fixed -1 1:10.0.0+r36-2 Control: fixed -1 1:10.0.0+r36-3 Control: fixed -1 1:10.0.0+r36-4
