Bug#1077599: apt: use sopv for OpenPGP signature verification
Package: apt Severity: wishlist Hi Julian, all-- We had some discussion over on https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/84 about how apt might use sopv instead of gpgv to validate OpenPGP signatures. I thought i'd move the discussion to an apt-specific forum, here in the BTS, since it's not really relevant for the chameleon. Feel free to move it somewhere more appropriate if you prefer! I had written over there: > I think a reasonable way forward would be for apt to depend on the sopv > interface (of which there are already several implementations available, > more than just the sequoia one), and to not have apt try to second-guess > the sopv implementation. sopv is defined such that it is a bug to accept > a weak signature. You can see, for example, the interoperability test > suite's review of acceptable RSA signature sizes, which tests against > the guidance in the upcoming RFC. > > If by default apt wants to require a stricter sopv implementation it > uses, it can just constrain the choice of sopv it selects (e.g. accept > sqop or dkg-sop (no relation) or pgpainless-cli or gosop 3+ or rpgpie > or gpgv-sq, but reject rnp-sop or sopgpy or gpgv; or, just pick one that > has reasonable policy and acceptable licensing, and require it). And if > some local admin wants a weaker algorithm policy because they're > dependent on some legacy repository, they can point to a different sopv > in the apt configuration. > > The only interface apt needs to worry about under this proposal is just > using sopv, which is deliberately simple. And OpenPGP algorithm > upgrades, cleartext signature framework decoding, wireformat revisions, > expiration dates, subkey cross-signatures, etc, can all be handled by > the OpenPGP implementation. Apt just needs to run: > > sopv inline-verify /usr/share/keyrings/repoA.pgp > /usr/share/keyrings/repoB.pgp < InRelease > > and consume its output as the validated Release file. > > (if you want sopv to defend against repository rollback too, it's only > marginally more complex to confirm that the new signature is older than > the last signature) > > If you're interested in this approach, i'd be happy to make a concrete > proposal for apt that would let it use some form of sopv, and you can > just pick the sopv implementation you like. Let me know if that would be > helpful. Julian followed up with: > What's missing from sopv are mechanisms for specifying crypto > policies, such as allowed hashes, allowed crypto algorithms, and > allowed key sizes. I'm not sure if there's stuff I'm missing. > > What we found out here is that verifying the key algorithm and size > during signature verification is a bit annoying, they only work with > errors. > > Imagine you have two keys, one weak and one strong. You never get a > warning about the weak key until you see a signature from it. > > That's suboptimal because it means only errors really add security, as > otherwise an attacker may replace the data with one signed with a > compromised weak key and if an update runs in the background you might > not even notice. > > We also need status communicated: > > fingerprints of keys that are unknown > uids and fingerprints of expired keys such that we can display them > > etc pp. I'm happy to respond to these thoughts in a later message in this thread. Regards, --dkg signature.asc Description: PGP signature
Bug#1074609: dracut: fails to install cryptsetup (lvm-on-luks)
Hi Thomas-- thanks for the suggestions! some comments below: On Sat 2024-07-27 03:49:49 +0200, Thomas Lange wrote: > Using lsinitrd /boot/initramfs you can check which dracut modules > are available in the initrd. > Following modules are available for crypt stuff: > > crypt > systemd-cryptsetup > crypt-gpg > crypt-loop > > Maybe you have to add some of these modules into dracut config. That doesn't matter for this system any more, as i've moved from dracut back to initramfs-tools, and i actually need to get some work done with the system at the moment so i can't keep rebooting it. I also don't understand enough about dracut to know how to ensure those modules are loaded; i'd expect dracut to be able to autodetect that the system needs cryptsetup for the root volume to work, and to include them by default. it used to work by default, and i don't think the answer is that the sysadmin should need to update their configuration files in order to reboot safely. Regards, --dkg signature.asc Description: PGP signature
Bug#1077385: RM: pendulum -- RoM, obsoleted
Package: ftp.debian.org Hi, pendulum has been a dependency of pgcli and iredis, but they removed that for a less complicated way of displaying relative timestamps in more recent versions. Please remove pendulum from Debian. Regards, Daniel
Bug#1077345: chromium: video on wayland, each frame emits warning to stderr: "gbm_pixmap_wayland.cc(82)] Cannot create bo with format=YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE"
Package: chromium Version: 126.0.6478.126-1~deb13u1 Severity: normal Hi there! When i use chromium to watch a video, using sway and wayland (no X11 or XWayland on this system), i get very noisy messages to stderr, apparently about one message per frame of video. I typically use set --ozone-platform-hint=auto, or set it explicitly in chrome://flags/#ozone-platform-hint (See https://bugs.debian,org/1075982, where i explain why i think this should be the default). In this configuration, playing any video produces a very noisy stream of messages to stderr. In particular, i see a line like this appear roughly once per frame: ``` [635461:635515:0728/122929.891862:ERROR:gbm_pixmap_wayland.cc(82)] Cannot create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE ``` Note that the video plays perfectly! The only complaint here is about the noisy stderr, which makes it impossible to catch any real warnings that might also show up on stderr. This happens with any video, but i've confirmed it (so that it's easy to reproduce) with a video from debconf23: ``` chromium 'https://gemmei.ftp.acc.umu.se/pub/debian-meetings/2023/DebConf23/debconf23-306-face-to-face-debian-meetings-in-a-climate-crisis.av1.webm ``` According to ffprobe, that video is 25 fps. If i run the above command, capturing stderr, and a kill it after 100 seconds, the resulting file contains 2478 error messages like above, though the numbers in the prefix differ slightly. I assume that's 1 message per frame of video, with a little bit of wiggle room in the timing for startup and network fetch. Please let me know if there are more detailed tests i can do, or patches i could try, that would help to debug this situation more effectively. Regards, --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.9.9-amd64 (SMP w/20 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 chromium depends on: ii chromium-common126.0.6478.126-1~deb13u1 ii libasound2t64 1.2.12-1 ii libatk-bridge2.0-0t64 2.52.0-1 ii libatk1.0-0t64 2.52.0-1 ii libatomic1 14-20240330-1 ii libatspi2.0-0t64 2.52.0-1 ii libc6 2.39-4 ii libcairo2 1.18.0-3+b1 ii libcups2t642.4.10-1 ii libdav1d7 1.4.3-1 ii libdbus-1-31.14.10-4+b1 ii libdouble-conversion3 3.3.0-1+b1 ii libdrm22.4.121-2 ii libevent-2.1-7t64 2.1.12-stable-10 ii libexpat1 2.6.2-1 ii libflac12t64 1.4.3+ds-2.1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b4 ii libgbm124.1.3-2 ii libgcc-s1 14-20240330-1 ii libglib2.0-0t642.80.4-1 ii libgtk-3-0t64 3.24.43-1 ii libharfbuzz-subset08.3.0-2+b1 ii libharfbuzz0b 8.3.0-2+b1 ii libjpeg62-turbo1:2.1.5-3 ii libjsoncpp25 1.9.5-6+b2 ii liblcms2-2 2.14-2+b1 ii libminizip1t64 1:1.3.dfsg+really1.3.1-1 ii libnspr4 2:4.35-1.1+b1 ii libnss32:3.102-1 ii libopenh264-7 2.4.1+dfsg-1 ii libopenjp2-7 2.5.0-2+b3 ii libopus0 1.5.2-2 ii libpango-1.0-0 1.54.0+ds-1 ii libpng16-16t64 1.6.43-5 ii libpulse0 16.1+dfsg1-5.1 ii libsnappy1v5 1.2.1-1 ii libstdc++6 14-20240330-1 ii libwoff1 1.0.2-2+b1 ii libx11-6 2:1.8.7-1+b1 ii libxcb11.17.0-2 ii libxcomposite1 1:0.4.5-1+b1 ii libxdamage11:1.1.6-1+b1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2+b1 ii libxkbcommon0 1.6.0-1+b1 ii libxml22.9.14+dfsg-1.3+b3 ii libxnvctrl0535.171.04-1 ii libxrandr2 2:1.5.4-1 ii libxslt1.1 1.1.35-1.1 ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages chromium recommends: ii chromium-sandbox 126.0.6478.126-1~deb13u1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.39-4 ii libdrm2 2.4.121-2 ii libgcc-s1 14-20240330-1 ii libjsoncpp25 1.9.5-6+b2 ii libstdc++614-20240330-1 ii libx11-6 2:1.8.7-1+b1 ii libxnvctrl0 535.171.04-1 ii x11-utils 7.7+6+b1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages chromium-common recommends: ii chromium-sandbox 126.0.6478.126-1~deb13u1 ii dunst [notification-daemon] 1.11.0-1 ii fonts-liberation
Bug#1076259: fixed in progress-linux-metapackages 20221002-15
close 1076259 20221002-16 thanks Hi, thanks for spotting it, I've uploaded fixed versions for both. Regards, Daniel
Bug#1041092: bts
tag 1041092 + pending thanks fixed in git, thanks for spotting and reporting it. Regards, Daniel
Bug#1073640: src:ceph: move aliased files from / to /usr (DEP17)
tag 1073640 + pending thanks fixed, pushing and uploading asap.. Regards, Daniel
Bug#1074874: bts
tag 1074874 + pending thanks I've cherry-picked the necessary upstream commits on top of 18.2.4, will finish running tests before uploading later on.. Regards, Daniel
Bug#1069702: unable to set format for numbers with unit_scale
close 1069702 thanks Hi, thank you for your report, I've fordwarded it to upstream in April: https://github.com/tqdm/tqdm/issues/1575 Given that there's no progress on it here, I don't think that it's of value to keep the duplicate of this upstream bug in the Debian bug tracker, hence I'm closing this bug. Regards, Daniel
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Hi, Am Dienstag, dem 23.07.2024 um 10:56 +0100 schrieb Jonathan Wiltshire: > On Tue, Jul 23, 2024 at 01:12:21AM +0200, Daniel Leidert wrote: > > Hi Jonathan, > > > > Am Montag, dem 01.07.2024 um 18:49 +0100 schrieb Jonathan Wiltshire: > > > > > > [..] > > > Please don't change history, and send a debdiff (relative to u4) of a > > > proposed upload fixing the regressions as 1.0.0~rc93+ds1-5+deb11u5 and a > > > proper changelog. Do not upload without further approval. > > > > Please find attached the debdiff. The u4 upload was missing just one > > patch. > > Please go ahead. Then I will clone this bug with the new version number for > tracking (don't be alarmed). Ok. I'll upload later today. Thanks for your swift response. > > > The build failures are unreproducible on porter machines. There, the > > package builds just fine. > > The issues are test failures; Correct. But they run during the build. On the porter machines, they succeeded. It seems i386 has succeeded now as well. I will check mipsel later. It is still running. Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#1076755: foot: logs utempter "usage error" when it stops
Package: foot Version: 1.17.2-2 Severity: normal I launch foot from a keybinding from sway, or from another foot instance. When i close a foot window (e.g. by exiting from the running shell), the following warning shows up in the system journal: ``` utempter[10509]: [ppid=10472] usage error ``` In this case, the foot process was 10472. I can work around this by adding the following configuration directive to ~/.config/foot/foot.ini: ``` [main] utmp-helper=none ``` Any foot instance that was launched when that directive was in `foot.ini` can close without producing the error message in the system journal. Feel free to reassign this if you think this is a bug in some other system component! --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.9.9-amd64 (SMP w/20 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 foot depends on: ii init-system-helpers 1.66 ii libc62.39-4 ii libfcft4t64 3.1.8-1.1 ii libfontconfig1 2.15.0-1.1 ii libpixman-1-00.42.2-1+b1 ii libutf8proc3 2.9.0-1+b1 ii libwayland-client0 1.22.0-2.1+b1 ii libwayland-cursor0 1.22.0-2.1+b1 ii libxkbcommon01.6.0-1+b1 ii ncurses-term 6.5-2 foot recommends no packages. Versions of packages foot suggests: pn foot-themes -- no debconf information signature.asc Description: PGP signature
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Am Dienstag, dem 23.07.2024 um 01:12 +0200 schrieb Daniel Leidert: > Hi Jonathan, > > Am Montag, dem 01.07.2024 um 18:49 +0100 schrieb Jonathan Wiltshire: > > > [..] > > Please don't change history, and send a debdiff (relative to u4) of a > > proposed upload fixing the regressions as 1.0.0~rc93+ds1-5+deb11u5 and a > > proper changelog. Do not upload without further approval. > > Please find attached the debdiff. The u4 upload was missing just one > patch. > > I'm currently looking into the build issues you mentioned. The build failures are unreproducible on porter machines. There, the package builds just fine. Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Hi Jonathan, Am Montag, dem 01.07.2024 um 18:49 +0100 schrieb Jonathan Wiltshire: [..] > Please don't change history, and send a debdiff (relative to u4) of a > proposed upload fixing the regressions as 1.0.0~rc93+ds1-5+deb11u5 and a > proper changelog. Do not upload without further approval. Please find attached the debdiff. The u4 upload was missing just one patch. I'm currently looking into the build issues you mentioned. Regards, Daniel diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc-1.0.0~rc93+ds1/debian/changelog --- runc-1.0.0~rc93+ds1/debian/changelog 2024-06-28 00:16:20.0 +0200 +++ runc-1.0.0~rc93+ds1/debian/changelog 2024-06-28 00:56:20.0 +0200 @@ -1,3 +1,16 @@ +runc (1.0.0~rc93+ds1-5+deb11u5) bullseye; urgency=medium + + * Non-maintainer upload by the Debian LTS Team. + * d/changelog: Cleaned up the last entry for 1.0.0~rc93+ds1-5+deb11u4 +removing some superflous entries. + * d/patches/CVE-2023-27561-and-CVE-2023-28642: Added to fix CVE-2023-27561 +and CVE-2023-27561. +- It was found that the fix for CVE-2021-30465 introduced a regression in + regards to CVE-2019-19921 which results in an incorrect access control + leading to privilege escalation and bypassing apparmor. + + -- Daniel Leidert Fri, 28 Jun 2024 00:56:20 +0200 + runc (1.0.0~rc93+ds1-5+deb11u4) bullseye; urgency=medium * Non-maintainer upload by the Debian LTS Team. @@ -15,11 +28,6 @@ - It was found that rootless runc makes `/sys/fs/cgroup` writable under specific conditions. A container may then gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host. - * Update changelog for 1.0.0~rc93+ds1-5+deb11u4~1.gbpce2b39 release - * Update patch for download URLs of busybox tarball - * Add patch to fix CVE-2021-43784.patch - * Add patch to fix tests with newer kernels - * Add patch to fix CVE-2023-25809 -- Daniel Leidert Fri, 28 Jun 2024 00:16:20 +0200 diff -Nru runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml --- runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml 2024-06-28 00:16:20.0 +0200 +++ runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml 2024-06-28 00:56:20.0 +0200 @@ -1,37 +1,10 @@ --- -# https://docs.gitlab.com/ce/ci/yaml/#include include: - - remote: https://salsa.debian.org/onlyjob/ci/raw/master/onlyjob-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml -## "amd64-unstable" always runs by default followed by lintian. - -## Only for arch:all packages - remove if not required: -binary-indep: - extends: .build-indep - -## Job to check Build-Depends versioning: -amd64-testing_unstable: - extends: .build - variables: -arch: amd64 -dist: testing_unstable - -i386-unstable: - extends: .build - variables: -arch: i386 -dist: unstable - -amd64-experimental: - extends: .build - variables: -arch: amd64 -dist: experimental - -amd64-stable: - extends: .build - when: manual - allow_failure: true - variables: -arch: amd64 -dist: stable +variables: + RELEASE: 'bullseye' + SALSA_CI_COMPONENTS: 'main contrib non-free' + SALSA_CI_DISABLE_REPROTEST: 1 + SALSA_CI_DISABLE_LINTIAN: 1 diff -Nru runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch --- runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch 1970-01-01 01:00:00.0 +0100 +++ runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch 2024-06-28 00:56:20.0 +0200 @@ -0,0 +1,109 @@ +From: Kir Kolyshkin +Date: Thu, 16 Mar 2023 14:35:50 -0700 +Subject: [PATCH] Prohibit /proc and /sys to be symlinks + +Commit 3291d66b9844 introduced a check for /proc and /sys, making sure +the destination (dest) is a directory (and not e.g. a symlink). + +Later, a hunk from commit 0ca91f44f switched from using filepath.Join +to SecureJoin for dest. As SecureJoin follows and resolves symlinks, +the check whether dest is a symlink no longer works. + +To fix, do the check without/before using SecureJoin. + +Add integration tests to make sure we won't regress. + +Signed-off-by: Kir Kolyshkin +(cherry picked from commit 0d72adf96dda1b687815bf89bb245b937a2f603c) +Signed-off-by: Sebastiaan van Stijn + +This patch fixes both, CVE-2023-27561 and CVE-2023-28642 + +Acked-by: Daniel Leidert +Origin: https://github.com/opencontainers/runc/commit/0abab45c9b97c113ff2cdc16f3a7388444c3fbec.patch +Forwarded: not-needed +--- + libcontainer/rootfs_linux.go | 23 +-- + tests/integration/mask.bats | 19 +++ + 2 files changed, 36 insertions(+), 6 deletions(-) + +diff --git a/libcontainer/rootfs_linux.go b/libcontainer/rootfs_linux.go +index 4791ceb..07303b0 100644 +--- a/libcontainer/rootfs_linux.go
Bug#1031019: sqop verify underdocumented, seems to expect to be verified file on stdin
Hi Andreas-- On Fri 2023-02-10 15:31:27 +0100, Andreas Metzler wrote: > According to both manpage and "sqop help verify" sqop verify accepts > exactly to args (sig and cert) plus two options > (--not-after/--not-before). > > However this command simply hangs: > sqop verify gnutls28_3.7.8.orig.tar.xz.asc > gnutls-3.7.8/debian/upstream/signing-key.asc > > Reading #969590 I found that the to-be verified tarball needs to be > passed as third arg on stdin. Technically this isn't a third argument, it's just stdin. sqop implements the standard Stateless OpenPGP Command Line Interface, which is found at https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ Hopefully that documentation is clearer than the manpages shipped with sqop. This crate should really create more up-to-date manpages during build, and the manpages should describe the expectations for stdin/stdout more clearly. i think that's at least in part an upstream concern: https://gitlab.com/sequoia-pgp/sequoia-sop/-/issues/33 Regards, --dkg signature.asc Description: PGP signature
Bug#1031020: sqop: Fails to verify sig on gnutls28_3.7.8.orig.tar.xz
Hi Andreas-- On Fri 2023-02-10 15:38:21 +0100, Andreas Metzler wrote: > I thought this should work, but it does not: > sqop verify gnutls28_3.7.8.orig.tar.xz.asc > gnutls-3.7.8/debian/upstream/signing-key.asc < gnutls28_3.7.8.orig.tar.xz.asc >No acceptable signatures found > > One of the signing keys (462225C3B46F34879FC8496CD605848ED7E69871) is in > gnutls-3.7.8/debian/upstream/signing-key.asc: I tested this against GnuTLS 3.8.6 with sqop 0.35.0, and i got the same result that you did. Investigating it further, i found: - the certificate in gnutls-3.8.6/debian/upstream/signing-key.asc that signed the 3.8.6 orig tarball was expired. - many of the certificates in gnutls-3.8.6/debian/upstream/signing-key.asc used SHA-1 in their internal certifications. SHA-1 should have been phased out years ago, and we should discourage OpenPGP certificates that rely on that algorithm. It turns out that the relevant certificates have all been fixed upstream, but they were not included in the debian packaging. I refreshed the debian packaging to use up-to-date certificates, and pushed that change here: https://salsa.debian.org/gnutls-team/gnutls/-/merge_requests/4 I hope this is useful, --dkg
Bug#1076672: ITP: sopv-gpgv -- Stateless OpenPGP Signature Verification with gpgv
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: sopv-gpgv Version : 0.1 Upstream Contact: Daniel Kahn Gillmor * URL : https://gitlab.com/dkg/sopv-gpgv * License : MIT Programming Lang: Python Description : Stateless OpenPGP Signature Verification with gpgv The Stateless OpenPGP Command-Line Interface Verification-only Subset (or `sopv`) is a simple, standard interface for verifying OpenPGP cryptographic signatures. This package provides an implementation of `sopv` backed by the minimal, verification-only `gpgv` tool from g10code. `sopv` is defined in https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ `gpgv` https://www.gnupg.org/documentation/manuals/gnupg/gpgv.html
Bug#1073993: O: libmicrohttpd -- library embedding HTTP server functionality
Hi Florian, On 7/20/24 15:04, Florian Ernst wrote: > When you orphaned libmicrohttpd with the upload of 1.0.0-2[0] you > apparently also depublished its git repo[1] I deleted it after a while when it wasn't picked up, so unfortunately I can't have it anymore, sorry. :( Regards, Daniel
Bug#1076649: ITP: cidr -- CLI to perform various actions on CIDR ranges
Hi Angel, On Sat, Jul 20, 2024 at 08:17:37PM +0200, Angel Abad wrote: > Package: wnpp > Severity: wishlist > Owner: Angel Abad > > * Package name: cidr > Version : 2.1.1-1 > Upstream Author : Bruno Schaatsbergen > * URL : https://github.com/bschaatsbergen/cidr > * License : Expat > Programming Lang: Go > Description : CLI to perform various actions on CIDR ranges I've been looking for something like this. Thanks for working on it! > CLI to perform various actions on CIDR ranges The description could rely on jargon a bit less. Let me try: Description: CLI for working with IPv6/v4 CIDR network prefixes Operations supported: - check host address is within a prefix - count number of possible host addressess - check operlap of two prefixes - calculate netmask of prefix - subdivide a prefix into a given number of subnets With my IPv6 hat on I notice counting the number of /64s in a prefix is missing and divide doesn't allow (according to README) requesting a fixed prefix size of eg. /64. --Daniel signature.asc Description: PGP signature
Bug#1076650: rust-sequoia-sop 0.35.0-3 FTBFS on mips64el ("relocation truncated to fit: R_MIPS_TLS_GD ...")
Package: rustc Version: 1.79.0+dfsg1-2 X-Debbugs-Cc: mips6...@buildd.debian.org, rust-sequoia-...@packages.debian.org Control: affects -1 src:rust-sequoia-sop Hey mips64el builders-- https://buildd.debian.org/status/fetch.php?pkg=rust-sequoia-sop=mips64el=0.35.0-3=1721479018=0 shows that rust-sequoia-sop 0.35.0-3 fails to build from source on mips64el. It builds fine on all the other debian platforms. I've copied what appear to the the relevant error messages, with a little bit of context, at the end of this message. 0.35.0-1 build successfully on mips64el -- but there are two significant differences between the versions: - 0.35.0-3 is building one additional binary, "sqopv", which was not being built by 0.35.0-1 - 0.35.0-3 add "-C codegen-units=1" to RUSTFLAGS, in an attempt to reduce the size of the sqop and sqopv binaries. Given that this error is happening in dh_auto_test, before sqopv is getting built, i tend to think it's the RUSTFLAGS change. I'm going to try removing the RUSTFLAGS change on mips64el to see whether it can build successfully, but this suggests that there may be some platform-specific bugs in rustc that put mips64el at risk. I welcome any suggestions or pointers for other ways to resolve this! Thanks for maintaining rustc in debian! --dkg ``` Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=sequoia_sop CARGO_MANIFEST_DIR=/<> CARGO_PKG_AUTHORS='Justus Winter ' CARGO_PKG_DESCRIPTION='An implementation of the Stateless OpenPGP Interface using Sequoia' CARGO_PKG_HOMEPAGE='https://sequoia-pgp.org/' CARGO_PKG_LICENSE=GPL-2.0-or-later CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=sequoia-sop CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://gitlab.com/sequoia-pgp/sequoia-sop' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.35.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=35 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 CARGO_RUSTC_CURRENT_DIR=/<> LD_LIBRARY_PATH=/<>/target/debug/deps OUT_DIR=/<>/target/mips64el-unknown-linux-gnuabi64/debug/build/sequoia-sop-f5bc5e9e498cf4f4/out rustc --crate-name sequoia_sop --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' -C metadata=5eb83a1627594449 -C extra-filename=-5eb83a1627594449 --out-dir /<>/target/mips64el-unknown-linux-gnuabi64/debug/deps --target mips64el-unknown-linux-gnuabi64 -C incremental=/<>/target/mips64el-unknown-linux-gnuabi64/debug/incremental -L dependency=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps -L dependency=/<>/target/debug/deps --extern anyhow=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libanyhow-6b4ca0a2ff29fed5.rmeta --extern sequoia_openpgp=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libsequoia_openpgp-c8df2195a74c1140.rmeta --extern sop=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libsop-4d091cf357cb81c2.rmeta -C debuginfo=2 -C strip=none --cap-lints warn -C linker=mips64el-linux-gnuabi64-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix /<>=/usr/share/cargo/registry/sequoia-sop-0.35.0 --remap-path-prefix /<>/debian/cargo_registry=/usr/share/cargo/registry -C codegen-units=1 -L native=/usr/lib/mips64el-linux-gnuabi64 -L native=/usr/lib/mips64el-linux-gnuabi64 -L native=/usr/lib/mips64el-linux-gnuabi64` warning: `sequoia-openpgp` (lib) generated 5 warnings Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=sequoia_sop CARGO_MANIFEST_DIR=/<> CARGO_PKG_AUTHORS='Justus Winter ' CARGO_PKG_DESCRIPTION='An implementation of the Stateless OpenPGP Interface using Sequoia' CARGO_PKG_HOMEPAGE='https://sequoia-pgp.org/' CARGO_PKG_LICENSE=GPL-2.0-or-later CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=sequoia-sop CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://gitlab.com/sequoia-pgp/sequoia-sop' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.35.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=35 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 CARGO_RUSTC_CURRENT_DIR=/<> LD_LIBRARY_PATH=/<>/target/debug/deps OUT_DIR=/<>/target/mips64el-unknown-linux-gnuabi64/debug/build/sequoia-sop-f5bc5e9e498cf4f4/out rustc --crate-name sequoia_sop --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test --cfg 'feature="default"' -C metadata=07411ef21101d0bf -C extra-filename=-07411ef21101d0bf --out-dir /<>/target/mips64el-unknown-linux-gnuabi64/debug/deps --target mips64el-unknown-linux-gnuabi64 -C incremental=/<>/target/mips64el-unknown-linux-gnuabi64/debug/incremental -L dependency=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps -L dependency=/<>/target/debug/deps --extern anyhow=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libanyhow-6b4ca0a2ff29fed5.rlib --extern
Bug#1076597: ITP: stagit -- static git repo web viewer, cgit/gitweb alternative
Package: wnpp Severity: wishlist Owner: Daniel Gröber X-Debbugs-Cc: debian-de...@lists.debian.org, d...@darkboxed.org * Package name: stagit Version : 1.2 Upstream Contact: Hiltjo Posthuma * URL : https://codemadness.org/stagit.html * License : MIT Programming Lang: C Description : static git web repo viewer Users expect a git repository to have a corresponding web page, but contemporary solutions (tightly coupled "forges") are complex and inflexible. stagit makes hosting git repositories on any web server as easy as it can be by simply pre-generating static HTML pages for any git repository. stagit is exceedingly simple. I'll maintain it myself, but I'm always happy to have co-maintainers. (Some bits from the README follow) Features - Log of all commits from HEAD. - Log and diffstat per commit. - Show file tree with linkable line numbers. - Show references: local branches and tags. - Detect README and LICENSE file from HEAD and link it as a webpage. - Detect submodules (.gitmodules file) from HEAD and link it as a webpage. - Atom feed of the commit log (atom.xml). - Atom feed of the tags/refs (tags.xml). - Make index page for multiple repositories with stagit-index. - After generating the pages (relatively slow) serving the files is very fast, simple and requires little resources (because the content is static), only a HTTP file server is required. - Usable with text-browsers such as dillo, links, lynx and w3m. Cons - Not suitable for large repositories (2000+ commits), because diffstats are an expensive operation, the cache (-c flag) is a workaround for this in some cases. - Not suitable for large repositories with many files, because all files are written for each execution of stagit. This is because stagit shows the lines of textfiles and there is no "cache" for file metadata (this would add more complexity to the code). - Not suitable for repositories with many branches, a quite linear history is assumed (from HEAD). In these cases it is better to just use cgit or possibly change stagit to run as a CGI program. - Relatively slow to run the first time (about 3 seconds for sbase, 1500+ commits), incremental updates are faster. - Does not support some of the dynamic features cgit has, like: - Snapshot tarballs per commit. - File tree per commit. - History log of branches diverged from HEAD. - Stats (git shortlog -s). This is by design, just use git locally. --Daniel
Bug#1076449: mercurial: does not start anymore with python 3.12.4-3, hgdemandimport problem
Package: mercurial Version: 6.8-1 Severity: grave Justification: renders package unusable Dear maintainer, In current sid, with python 3.12.4-3, mercurial fails at load with: ~$ hg Traceback (most recent call last): File "/usr/bin/hg", line 57, in from mercurial import dispatch File "", line 1360, in _find_and_load File "", line 1331, in _find_and_load_unlocked File "", line 935, in _load_unlocked File "/usr/lib/python3/dist-packages/hgdemandimport/demandimportpy3.py", line 52, in exec_module super().exec_module(module) File "", line 257, in exec_module File "", line 1360, in _find_and_load File "", line 1331, in _find_and_load_unlocked File "", line 935, in _load_unlocked File "/usr/lib/python3/dist-packages/hgdemandimport/demandimportpy3.py", line 52, in exec_module super().exec_module(module) File "", line 267, in exec_module AttributeError: partially initialized module 'threading' has no attribute 'RLock' (most likely due to a circular import) ~$ Commenting out the hgdemandimport.enable() at line 55 of /usr/bin/hg, it works: ~$ hg Mercurial Distributed SCM basic commands: add add the specified files on the next commit annotate show changeset information by line for each file clone make a copy of an existing repository commitcommit the specified files or all outstanding changes diff diff repository (or selected files) exportdump the header and diffs for one or more changesets forgetforget the specified files on the next commit init create a new repository in the given directory log show revision history of entire repository or files merge merge another revision into working directory pull pull changes from the specified source push push changes to the specified destination removeremove the specified files on the next commit serve start stand-alone webserver statusshow changed files in the working directory summary summarize working directory state updateupdate working directory (or switch revisions) (use 'hg help' for the full list of commands or 'hg -v' for details) ~$ Tried this on my own machine and also in a newly installed VM. Thanks, Daniel. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mercurial depends on: ii libc6 2.39-4 ii mercurial-common 6.8-1 ii python3 3.12.3-1 ii ucf 3.0043+nmu1 Versions of packages mercurial recommends: ii openssh-client 1:9.7p1-7 Versions of packages mercurial suggests: pn kdiff3 | kdiff3-qt | kompare | meld | tkcvs | mgdiff pn qct -- no debconf information
Bug#499167: developers-reference: please explain deb/debian/ds suffixes in versions
The convention seems to be documented in https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F > “+dfsg.N” and “+ds.N“ are a conventional way of extending a version > string, when the Debian package's upstream source tarball is actually > different from the source released upstream. The former is used when > upstream's source release contains elements that do not satisfy the > Debian Free Software Guildelines (DFSG) and hence may not be distributed > as source in the Debian system, the latter (standing for “Debian Source”) > is used when the modification are for other non-DFSG reasons. The text in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774843 seems to incorporate it. --Daniel signature.asc Description: PGP signature
Bug#1076415: ITP: azirevpn-cli -- AzireVPN CLI client for generating WireGuard configs
Package: wnpp Severity: wishlist Owner: Daniel Gröber X-Debbugs-Cc: debian-de...@lists.debian.org, d...@darkboxed.org * Package name: azirevpn-cli Version : 2.0.0 Upstream Contact: Tobias Windh * URL : https://github.com/AzireVPN/azirevpn-cli/ * License : GPL-2.0 Programming Lang: Bash Description : AzireVPN CLI client for generating WireGuard configs It's a simple 120 line bash script. I'll maintain it myself.
Bug#1043037: mlmmj NMU into experimental (Was: Reasonable fork of MLMMJ available now)
s with the standard salsa-ci template from https://salsa.debian.org/salsa-ci-team/pipeline#basic-use and once we're in unstable work on a seperate backport branch for bookworm. > The debian/rules have been converted to automatic 'dh' rules, and there > needs to be detailed review of what the end-effect of changing those > rules are compared to the current package in Debian. Easy. A debdiff should show you what we need to know. Let me know if you want us to send one. Chris, can you handle upgrade testing? Me an (I assume) Michael don't have running deployments (yet). If not we should do a public call for testing of an (eventual) unstable/experimental upload on d-devel and the mlmmj list you mention below. > Changing the debian/rules is specifically something not to change without > consent from the package maintainer. Right, that's a no-go for an NMU. But since you're here now :) Chis, if I was reviewing you package on d-mentors today doing eveything by hand would also be a complete no-go. As you can see Michael's version is significantly shorter (understatement of the year) and it is my understanding and opionion that using dh is strong consensus in Debian, see https://anarc.at/blog/2019-02-05-debian-build-systems/ dh usage is only growing. > Please do not upload this package as it is right now, I think the needs > changes before it could be released. Naturally. Do keep in mind that an upload to experimental doesn't need to be ready for release :) Michael, let me know if you want to work on Chris' feedback or if I should take over. > This is not a situation where Michael's > Git repo could simply be imported into the Debian MLMMJ Git repository, As far as NMUers in Debian are concerned your git repo doesn't really exist. I've followed the recent tag2upload discussion carefully and it is my opinion that in the general case there is no hope for git based collaboration in Debian until it is widely used, but since there's consensus on t2u now this may change soon^TM. In any case since you seem to be using gbp importing a DSC is easy: dget -d $URL_from_tracker gbp import-dsc $dsc done. > because there's several past versions that were never released to Debian and > so don't belong in the Salsa Git repo. I don't think I know enough Git magic > (rebase?) to reconcile all that to make a clean Salsa Git history of Debian > releases. See above. There's no need for that, but I always love a good git challange so hit me up on OFTC if you want to try that just to learn git better. Assuming you haven't made changes since Michael's fork I'd just do a one-off pull of Michael's branches and remove any inappropriate tags. No need for rebase. If you've made changes since the fork things take a turn for the next to impossible since gbp makes merge commits. I've tried that recently and learned the hard way rebasing through merges is not a standard thing to do. I still think it's possible (with enough brute force): for each merge you have to do a ranged rebase and re-create the merge by hand (yey). IMO this is why gbp is terrible and should not be used. It breaks down as soon as someone doesn't know it's not a collaboration mechanism outside of a single central repository, which is a very common misconception especially for contributors new to Debian. NMUs are Debian's documented standard and universal collaboration mechanism. They have terrible fidelity and UX ofc. but at least all tools I'm aware of support them. > And if you're not aware, the install instructions for MLMMJ for Exim4 also > need updating after changes to Exim4 for disallowing using "tainted data" > and I don't yet know if the new upstream fork has updated those > instructions. Doesn't look like upstream updated those instructions in 1.4.6 yet. Could you report an issue for that on codeberg if you have the details in your head still? > That was discussed on the MLMMJ mailing list, which is still active. Let > me know if you are on the mailing list for MLMMJ to see the discussion of > these issues. Could you link me to the ML and discussion? The website got reorganized recently I can't seem to find it. > I appreciate the work Micheal has done to create a new Debian package of > MLMMJ, it's definitely going to be useful even if it can't be released > directly. At minimum there should be away of 'cherry picking' Git commits > to include in a new MLMMJ Debian release. Chris, I've sent a request to join mlmmj-team on Salsa, could you add Michael (@mjeanson) too? > Daniel when you have time please let me know your thoughts about all this. > Hopefully we can figure out a way to make this work, because I could > certainly use help. I'm sure we'll get it done and then some :D Thanks, --Daniel signature.asc Description: PGP signature
Bug#1068130: xdg-desktop-portal-gnome cause slow start up time in some application
Hello. I have the issue on a multi desktop environment. I can't remove xdg-desktop-portal-gnome since it's required by gnome but cause troubles under awesome. Any hints? -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages xdg-desktop-portal-gnome depends on: ii dbus-user-session1.14.10-4+b1 ii dbus-x11 1.14.10-4+b1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii gsettings-desktop-schemas47~alpha-1 ii libadwaita-1-0 1.5.2-1 ii libc62.38-14 ii libcairo21.18.0-3+b1 ii libfontconfig1 2.15.0-1.1 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-1 ii libglib2.0-0t64 2.80.4-1 ii libgnome-bg-4-2t64 44.0-5 ii libgnome-desktop-4-2t64 44.0-5 ii libgraphene-1.0-01.10.8-3+b1 ii libgtk-4-1 4.12.5+ds-6+b1 ii libwayland-client0 1.22.0-2.1+b1 ii libx11-6 2:1.8.7-1+b1 ii xdg-desktop-portal 1.18.4-1 ii xdg-desktop-portal-gtk 1.15.1-1+b1 Versions of packages xdg-desktop-portal-gnome recommends: ii gnome-settings-daemon 46.0-5 ii gnome-shell46.3.1-2 Versions of packages xdg-desktop-portal-gnome suggests: ii accountsservice 23.13.9-6.1 ii evince 46.3-1 -- no debconf information -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#1075976: Minor mitigation
First, the mitigation: adding this into /etc/default/fluidsynth mostly mitigates this issue, but does not resolve it: OTHER_OPTS='-z8192' Upstream this bug exists as https://github.com/FluidSynth/fluidsynth/issues/338 and the upstream author seems almost hostile to the idea that anyone would not want fluidsynth to suck up CPU in the background. It's a strong enough attitude that I'm tempted to conclude that fluidsynth is not yet ready to be a dependency of any widely used package (like timidity)
Bug#1076210: hplip: hp-check error in line 630 since last update
On 12.07.24 17:35, Daniel Schröter wrote: Can you upgrade hplip to version 3.12.12 (or higher)? Typo :-( Can you upgrade hplip to version 3.23.12 (or higher)?
Bug#1076210: hplip: hp-check error in line 630 since last update
Package: hplip
Version: 3.22.10+dfsg0-5+b1
Severity: important
Tags: upstream
X-Debbugs-Cc: d.schroe...@gmx.de
Dear Maintainer,
since the last update hp-check produce an error (and my HP1020 printer is not
working anymore):
$ hp-check
/usr/bin/hp-check:630: SyntaxWarning: invalid escape sequence '\s'
lsusb_pat =
re.compile("""^Bus\s([0-9a-fA-F]{3,3})\sDevice\s([0-9a-fA-F]{3,3}):\sID\s([0-9a-fA-F]{4,4}):([0-9a-fA-F]{4,4})(.*)""",
re.IGNORECASE)
Traceback (most recent call last):
File "/usr/bin/hp-check", line 38, in
from base.g import *
File "/usr/share/hplip/base/g.py", line 239, in
sys_conf = SysConfig()
^^^
File "/usr/share/hplip/base/g.py", line 184, in __init__
ConfigBase.__init__(self, '/etc/hp/hplip.conf')
File "/usr/share/hplip/base/g.py", line 89, in __init__
self.read()
File "/usr/share/hplip/base/g.py", line 130, in read
self.conf.readfp(fp)
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean:
'read'?
From
https://bbs.archlinux.org/viewtopic.php?id=295303
it should be fixed in hplip 1:3.23.12-5 (on arch linux).
Can you upgrade hplip to version 3.12.12 (or higher)?
Thanks!
Bye
-- Package-specific info:
/usr/bin/hp-check:630: SyntaxWarning: invalid escape sequence '\s'
lsusb_pat =
re.compile("""^Bus\s([0-9a-fA-F]{3,3})\sDevice\s([0-9a-fA-F]{3,3}):\sID\s([0-9a-fA-F]{4,4}):([0-9a-fA-F]{4,4})(.*)""",
re.IGNORECASE)
Traceback (most recent call last):
File "/usr/bin/hp-check", line 38, in
from base.g import *
File "/usr/share/hplip/base/g.py", line 239, in
sys_conf = SysConfig()
^^^
File "/usr/share/hplip/base/g.py", line 184, in __init__
ConfigBase.__init__(self, '/etc/hp/hplip.conf')
File "/usr/share/hplip/base/g.py", line 89, in __init__
self.read()
File "/usr/share/hplip/base/g.py", line 130, in read
self.conf.readfp(fp)
AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean:
'read'?
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.8-amd64 (SMP w/16 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages hplip depends on:
ii adduser3.137
ii cups 2.4.10-1
ii hplip-data 3.22.10+dfsg0-5
ii libc6 2.38-14
ii libcups2t642.4.10-1
ii libdbus-1-31.14.10-4+b1
ii libhpmud0 3.22.10+dfsg0-5+b1
ii libpython3.12t64 3.12.4-1
ii libsane-hpaio 3.22.10+dfsg0-5+b1
ii libsane1 1.3.0-1
ii lsb-base 11.6
ii printer-driver-hpcups 3.22.10+dfsg0-5+b1
ii python33.12.3-1
ii python3-dbus 1.3.2-5+b2
ii python3-gi 3.48.2-1
ii python3-pexpect4.9-2
ii python3-pil10.4.0-1
ii python3-reportlab 4.2.2-1
ii sysvinit-utils [lsb-base] 3.09-2
ii wget 1.24.5-1
ii xz-utils 5.6.2-2
Versions of packages hplip recommends:
ii avahi-daemon 0.8-13+b2
ii pkexec124-3
ii polkitd 124-3
ii printer-driver-postscript-hp 3.22.10+dfsg0-5+b1
ii sane-utils1.3.0-1
Versions of packages hplip suggests:
pn hplip-doc
pn hplip-gui
pn python3-notify2
pn system-config-printer
-- no debconf information
Bug#1072299: Compositor-related crashes
I did another round of debugging, and have some new findings to report. To start with, I put a breakpoint on OnNoMemoryInternal(). That works better than trying to catch the SIGILL. However, this failure mode has been relatively infrequent with my modified 126.0.6478.126 build. More common lately has been a straight segfault related to Mojo that invariably brings down the entire browser. Here is a typical example: Thread 1 "chromium" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f92e4ff8480 (LWP 876682)] 0x55c72dfed9c2 in mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*) () (gdb) bt #0 0x55c72dfed9c2 in mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*) () #1 0x55c72dff5314 in mojo::MessageDispatcher::Accept(mojo::Message*) () #2 0x55c72dfefbed in mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) () #3 0x55c72dff9496 in mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) () #4 0x55c72dff8c73 in mojo::internal::MultiplexRouter::Accept(mojo::Message*) () #5 0x55c72dff5314 in mojo::MessageDispatcher::Accept(mojo::Message*) () #6 0x55c72dfeb74e in mojo::Connector::DispatchMessage(mojo::ScopedHandleBase) () #7 0x55c72dfebeda in mojo::Connector::ReadAllAvailableMessages() () #8 0x55c72d7e03ff in base::TaskAnnotator::RunTaskImpl(base::PendingTask&) () #9 0x55c72d801667 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() () #10 0x55c72d873e6a in base::(anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) () #11 0x7f92e80b97a9 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x7f92e80b9a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7f92e80b9acc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x55c72d872c00 in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () #15 0x55c72d802190 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) () #16 0x55c72d7c18a9 in base::RunLoop::Run(base::Location const&) () #17 0x55c72adc4fda in content::BrowserMainLoop::RunMainMessageLoop() () #18 0x55c72adc114d in content::BrowserMain(content::MainFunctionParams) () #19 0x55c72ca25b49 in content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams, bool) () #20 0x55c72ca25637 in content::ContentMainRunnerImpl::Run() () #21 0x55c72ca221a4 in content::ContentMain(content::ContentMainParams) () #22 0x55c7284eafc5 in ChromeMain () #23 0x7f92e644624a in __libc_start_call_main ( main=main@entry=0x55c7284eac60 , argc=argc@entry=8, argv=0x7ffdc854dc48, argv@entry=0xec0002740e0) at ../sysdeps/nptl/libc_start_call_main.h:58 #24 0x7f92e6446305 in __libc_start_main_impl (main=0x55c7284eac60 , argc=8, argv=0xec0002740e0, init=, fini=, rtld_fini=, stack_end=0x7ffdc854dc38) at ../csu/libc-start.c:360 #25 0x55c728167021 in _start () Right before, I'll get a message on the terminal like [885352:885352:0709/095917.737560:ERROR:interface_endpoint_client.cc(722)] Message 0 rejected by interface viz.mojom.Gpu [890042:890062:0709/222611.345773:ERROR:interface_endpoint_client.cc(722)] Message 0 rejected by interface blink.mojom.Blob I suspect this is a bug that is being tickled by the memory pressure (because otherwise everyone would be complaining about a crashing browser). Could use some guidance on what to poke in GDB/chromium to get some useful information out. One other oddity I've noticed: I often keep the browser's Task Manager window running on the side. I've noticed numerous cases where the "Browser" process's "Memory footprint" column hovers around ~350 MB, then spikes to ~850 MB for several seconds, then drops back down to ~350. This is with no visible activity in the browser that could explain it, like the loading of a new page. Memory allocations break very easily while this stat is elevated, as you'd expect.
Bug#1076136: AttributeError: module 'ssl' has no attribute 'wrap_socket' with Python 3.12
Package: python3-mysql.connector
Version: 8.0.15-4
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
After the update to Python 3.12, I can no longer use the
mysql.connector.connect function due to this error:
File "/usr/lib/python3/dist-packages/mysql/connector/__init__.py", line 173,
in connect
return MySQLConnection(*args, **kwargs)
File "/usr/lib/python3/dist-packages/mysql/connector/connection.py", line
102, in __init__
self.connect(**kwargs)
File "/usr/lib/python3/dist-packages/mysql/connector/abstracts.py", line 735,
in connect
self._open_connection()
File "/usr/lib/python3/dist-packages/mysql/connector/connection.py", line
250, in _open_connection
self._do_auth(self._user, self._password,
File "/usr/lib/python3/dist-packages/mysql/connector/connection.py", line
155, in _do_auth
self._socket.switch_to_ssl(ssl_options.get('ca'),
File "/usr/lib/python3/dist-packages/mysql/connector/network.py", line 427,
in switch_to_ssl
self.sock = ssl.wrap_socket(
^^^
AttributeError: module 'ssl' has no attribute 'wrap_socket'
It seems that Python 3.12 removed the ssl.wrap_socket() function (see
https://docs.python.org/3.12/whatsnew/3.12.html#ssl).
Regards, Daniel
- -- System Information:
Debian Release: trixie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.9.8-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-mysql.connector depends on:
ii python3 3.12.3-1
ii python3-protobuf 3.21.12-8.2
python3-mysql.connector recommends no packages.
python3-mysql.connector suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmaPpIEACgkQS80FZ8KW
0F07uRAAuJHnoY3Ds5a+i45FC2Dra7WvpedIWULgM9TjNDbIfFGPjKyIZfzBUpAB
5xvUZkP47K/HzByVRUcotI8ila/S11irtCMnij1n4Nbo+VC999X2XPXdtTIpEe/k
bmSlcGbHs7Fx3wgwuWhDZesZgXPSKu9ghr3NX1Pe+ew+U5Q7S2XeFPMAItIuddKV
q+p4xVrNuW0RsKVbX9VwSMClgfIquskie1wjMRFS8nbM6oPJuVJYzLNST0hhplmC
VnQ4EBMt52bvhQn4/izZ+HumykN0FNnsN2KZ9VRt3D/Jc1Ed/XVXYx1uSaRIliVK
QPBSP5U8pcwCLhvqyiqBrVfzn8iF5uFJdSyjhIajO6LMHW4D3MhQo5FG7ATpDzMt
STdZunDlZ3MeaC47lZzsQkd2UI/36MxjlRCcMk8LBc7+f4MUspbrdzZpZaTu9Dxi
v/6/GY2yl1MbCg1izgOWcMTAtswa0TfYX4OKaDtXvtUI8t53c5ESpkJ2s23bxuHI
EpHX1/r+UNDLg98naxFi8te3BiR9acvh7ub9c31/bFO8mn07NoOPDffcqOjdDaA4
uZ+4xje94k/RG3kZa5VUeEGrXpj+SDbpkME9G6mpBP2nkDEdxK7NpVK1V0sdS7nz
zG46G6kNT0pHWK1Nu7jsOJ8lzvjJzA7RRYFFPhL5xT2GEAHav98=
=Ld/f
-END PGP SIGNATURE-
Bug#1075982: chromium: please set ozone default to "auto"
Package: chromium Version: 125.0.6422.60-1 Severity: wishlist https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ozone_overview.md says: > It is also possible to choose an Ozone backend via the > chrome://flags/#ozone-platform-hint. The following options are > available - Default, X11, Wayland, and Auto. The default one is > “X11”. “Auto” selects Wayland if possible, X11 otherwise. It looks like it's possible to change the default from X11 to Auto by setting the following build parameter: ozone_platform="auto" It seems reasonable to me for debian's chromium to do this, as it means that chromium will Just Work™ on systems without XWayland. --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.9.7-amd64 (SMP w/20 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 chromium depends on: ii chromium-common125.0.6422.60-1 ii libasound2t64 1.2.12-1 ii libatk-bridge2.0-0t64 2.52.0-1 ii libatk1.0-0t64 2.52.0-1 ii libatomic1 14-20240330-1 ii libatspi2.0-0t64 2.52.0-1 ii libc6 2.38-13 ii libcairo2 1.18.0-3+b1 ii libcups2t642.4.10-1 ii libdav1d7 1.4.3-1 ii libdbus-1-31.14.10-4+b1 ii libdouble-conversion3 3.3.0-1+b1 ii libdrm22.4.121-2 ii libevent-2.1-7t64 2.1.12-stable-10 ii libexpat1 2.6.2-1 ii libflac12t64 1.4.3+ds-2.1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b4 ii libgbm124.0.8-1 ii libgcc-s1 14-20240330-1 ii libglib2.0-0t642.80.3-1 ii libgtk-3-0t64 3.24.42-1 ii libharfbuzz-subset08.3.0-2+b1 ii libharfbuzz0b 8.3.0-2+b1 ii libjpeg62-turbo1:2.1.5-3 ii libjsoncpp25 1.9.5-6+b2 ii liblcms2-2 2.14-2+b1 ii libminizip1t64 1:1.3.dfsg+really1.3.1-1 ii libnspr4 2:4.35-1.1+b1 ii libnss32:3.101-1 ii libopenh264-7 2.4.1+dfsg-1 ii libopenjp2-7 2.5.0-2+b3 ii libopus0 1.5.2-2 ii libpango-1.0-0 1.54.0+ds-1 ii libpng16-16t64 1.6.43-5 ii libpulse0 16.1+dfsg1-5.1 ii libsnappy1v5 1.2.1-1 ii libstdc++6 14-20240330-1 ii libwoff1 1.0.2-2+b1 ii libx11-6 2:1.8.7-1+b1 ii libxcb11.17.0-2 ii libxcomposite1 1:0.4.5-1+b1 ii libxdamage11:1.1.6-1+b1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2+b1 ii libxkbcommon0 1.6.0-1+b1 ii libxml22.9.14+dfsg-1.3+b3 ii libxnvctrl0535.171.04-1 ii libxrandr2 2:1.5.4-1 ii libxslt1.1 1.1.35-1+b1 ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages chromium recommends: ii chromium-sandbox 125.0.6422.60-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.38-13 ii libdrm2 2.4.121-2 ii libjsoncpp25 1.9.5-6+b2 ii libstdc++614-20240330-1 ii libx11-6 2:1.8.7-1+b1 ii libxnvctrl0 535.171.04-1 ii x11-utils 7.7+6+b1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages chromium-common recommends: ii chromium-sandbox 125.0.6422.60-1 ii dunst [notification-daemon] 1.11.0-1 ii fonts-liberation 1:2.1.5-3 ii libgl1-mesa-dri 24.0.8-1 ii notification-daemon 3.20.0-4+b2 pn system-config-printer ii udev 256.2-1 ii upower 1.90.3-1 Versions of packages chromium-sandbox depends on: ii libc6 2.38-13 -- no debconf information signature.asc Description: PGP signature
Bug#1033305: chromium: try enabling use_thin_lto for faster build
A couple of updates:
* Tim fixed ThinLTO on ppc64el via fix-clang-selection.patch, added in
the 123.0.6312.86 release.
* Thanks to bug #1072299, I've built chromium 126.0.6478.126 for
bookworm for my own usage/testing, and in addition to the allocator
tweak suggested in that thread, I enabled ThinLTO. Here are the tweaks
currently needed on stable to avoid subsequent build breakage:
--- a/build/config/compiler/BUILD.gn
+++ b/build/config/compiler/BUILD.gn
@@ -772,10 +772,6 @@ config("compiler") {
if (is_apple) {
ldflags += [ "-Wcrl,object_path_lto" ]
}
-
- # We only use one version of LLVM within a build so there's no need to
- # upgrade debug info, which can be expensive since it runs the verifier.
- ldflags += [ "-Wl,-mllvm,-disable-auto-upgrade-debug-info" ]
}
# TODO(crbug.com/335365324): Enable on other platforms.
--- a/build/config/rust.gni
+++ b/build/config/rust.gni
@@ -75,7 +75,7 @@ declare_args() {
#
# TODO(crbug.com/40281834): Re-enable ThinLTO for Rust on LaCrOS
# TODO(b/300937673): Re-enable ThinLTO for Rust on ash-chrome
- toolchain_supports_rust_thin_lto = !is_chromeos
+ toolchain_supports_rust_thin_lto = false
# Any extra std rlibs in your Rust toolchain, relative to the standard
# Rust toolchain. Typically used with 'rust_sysroot_absolute'
(The stable version of Rust appears not capable of LTO.)
So far, I haven't noticed any ill effects in my "production" home
environment... a laptop with 3 GB RAM, and chrome://discards showing 691
tabs :] (But I can't say it feels noticeably snappier, either. Some
kind of browser-performance benchmarking is probably in order...)
Bug#1072299: Compositor-related crashes
On Tue, 2024 Jun 25 14:26-04:00, Andres Salomon wrote: > > That backtrace makes sense; it's running OnNoMemoryInternal(), which > calls PA_IMMEDIATE_CRASH(), which generates an invalid opcode customized > for various architectures (ironically to provide a better backtrace > compared to calling abort() or something). > > It's a maze of #ifdefs, but it appears that on x86, it calls 'int3' > (which should emit SIGTRAP), followed by 'ud2' (undefined instruction). > You can probably get gdb to catch the SIGTRAP, but that honestly doesn't > help diagnose _why_ you're running out of memory. Even though GDB didn't catch all the crashes, the circumstantial evidence of all of them going through OnNoMemoryInternal() is pretty strong. > I don't know how chromium handles GPU memory, but I wonder if the issue > is that GPU memory can't be swapped, and the partition allocator is just > grabbing way too much of it and wasting it? > > Try changing the following in > base/allocator/partition_allocator/src/partition_alloc/partition_alloc_constants.h > > , around line 144: > > constexpr size_t kMaxPartitionPagesPerRegularSlotSpan = 4; > > Change that value to be 3 or 2, and see if that helps. Keep in mind by > doing this you're trading memory for speed, so memory allocations might > be a bit slower. Yep, I put the build-reproducibility issue aside, and built with this set to 2. (I also set use_thin_lto=true, in hopes of getting a small speed boost.) The difference is pretty stark, feels like an order of magnitude fewer crashes compared to the stock build. I can do the kind of aggressive browsing that previously took it down, and it keeps going. I've counted only two crashes so far, in quick succession on the same complex Web page, across multiple hours of use. I tried putting together a quick-and-dirty patch that allows setting the value via an environment variable, but the value gets used in a lot of other constexpr's, as well as array sizes, etc. (it's practically a #define). Do you think a patch is ultimately the way to go, or would the upstream be receptive to improving [configurability of] low-memory behavior? > If that doesn't help, it could also be that the CreateSharedImage() code > for your specific graphics driver is leaking memory or something. If you > can try a different graphics driver/stack, that could also point to a > specific bug in the driver. It seemed like --use-gl=egl was somewhat more crash-y with the stock build, so I reverted that tweak a while back. I need to try it again, it might be fine now. > Memory Saver is exactly what I was going to recommend as a workaround, > before I saw the backtrace. ;) Overall, Chromium does very well with what I'm throwing at it. The crashes feel like a minor issue that can be fixed easily, not some hard architectural problem requiring a refactor. --Daniel
Bug#1043037: mlmmj NMU into experimental (Was: Reasonable fork of MLMMJ available now)
Hi all, I'm also interested in getting mlmmj back into shape. Chris, the package Michael has been maintaining looks pretty good at first glance is there something stopping you from picking it up? Heads up: I'm going to NMU it to experimental as long as I don't find any issues during review. --Daniel On Fri, Mar 22, 2024 at 04:07:57PM -0400, Michael Jeanson wrote: > On Sat, 23 Dec 2023 18:10:34 -0500 Chris Knadle > wrote: > > retitle 1043037 Switch upstream source to fork after release of MLMMJ 1.4 > > summary 1043037 MLMMJ upstream is dead since 2017, but users of MLMMJ > > have created a usable fork with new features; it's time to switch to it > > thanks > > > > New location for ongoing fork MLMMJ releases (current release is 1.4.3): > > https://codeberg.org/mlmmj/mlmmj/releases > > Hi, > > I've prepared an updated mlmmj 1.4.4 package in a personal repo [1], I've > also been working with upstream to fix some issues I've encountered while > updating the packaging code. > > Please have a look and feel free to take only the pieces you like, I don't > run an mlmmj server yet so other than running the test suite it's quite > untested. There are some test failures on Salsa-CI which I'm unable to > reproduce locally at the moment. > > I would like to eventually migrate an existing mailman2 system to mlmmj > after trixie is release, hence this effort. > > Cheers, > > Michael > > [1] https://salsa.debian.org/mjeanson/mlmmj signature.asc Description: PGP signature
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
./sql/ha_partition.cc:5657 is coping over a blob of memory. Could it just be slow? Does running main.partition on its own generate the same result? Alternately one of the loop constructs around it got some incorrect values. Examine local variables (info locals) around what was executing on timeout. Also look at the variable constructs from which they were calculated. Possibly in multiple threads. mtr --gdb='b handle_fatal_signal; r' The thread that receives the timeout signal from mtr isn't necessarily the one being slow. Is failure repeatable with a lower number of mtr --parallel? On Sat, 6 Jul 2024 at 11:42, Otto Kekäläinen wrote: > > I built the binary in debug mode and that yielded a stacktrace: > > *** > > main.partition w38 [ retry-fail ] > Test ended at 2024-07-06 01:14:43 > > CURRENT_TEST: main.partition > mysqltest: At line 3010: query 'select id from t1 where data = 'ab' > order by id' failed: (2013): Lost connection to server > during query > > The result from queries just before the failure was: > < snip > > insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, > 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; > select id from t1 where data = 'ab' order by id; > id > 4 > 5 > 6 > 14 > 15 > 16 > drop table t1; > create table t1(id int unsigned not null, > data text default null, > key data_idx (data(1),id) > ) default charset=utf8 > partition by range (id) ( > partition p10 values less than (10), > partition p20 values less than (20) > ); > insert t1 values (6, 'ab'), (4, 'ab'), (5, 'ab'), (16, 'ab'), (14, > 'ab'), (15, 'ab'), (5, 'ac'), (15, 'aa') ; > select id from t1 where data = 'ab' order by id; > > More results from queries before failure can be found in > /home/otto/mariadb-server/builddir/mysql-test/var/38/log/partition.log > > - found 'core' (1/1) > worker[38] > Restart - not started > Core generated by '/home/otto/mariadb-server/builddir/sql/mariadbd' > Output from gdb follows. The first stack trace is from the failing thread. > The following stack traces are from all threads (so the failing one is > duplicated). > -- > [New LWP 3175949] > [New LWP 3175830] > [New LWP 3175886] > [New LWP 3175896] > [New LWP 3175931] > [New LWP 3175902] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". > Core was generated by `/home/otto/mariadb-server/builddir/sql/mariadbd > --defaults-group-suffix=.1 --de'. > Program terminated with signal SIGUSR1, User defined signal 1. > #0 0xfff80001028928c0 in __pthread_kill_implementation > (threadid=1892278236620992, signo=10, no_tid=0) at > ./nptl/pthread_kill.c:43 > 43 ./nptl/pthread_kill.c: No such file or directory. > [Current thread is 1 (Thread 0xfff8000102baa8c0 (LWP 3175949))] > #0 0xfff80001028928c0 in __pthread_kill_implementation > (threadid=1892278236620992, signo=10, no_tid=0) at > ./nptl/pthread_kill.c:43 > #1 0x01000154ca3c in my_write_core (sig=10) at ./mysys/stacktrace.c:424 > #2 0x01c39778 in handle_fatal_signal (sig=10) at > ./sql/signal_handler.cc:357 > #3 > #4 0x01f35cac in ha_partition::init_record_priority_queue > (this=0xfff800011cca7c10) at ./sql/ha_partition.cc:5657 > #5 0x01f363b4 in ha_partition::index_init > (this=0xfff800011cca7c10, inx=0, sorted=true) at > ./sql/ha_partition.cc:5762 > #6 0x01939870 in handler::ha_index_init (sorted=true, idx=0, > this=0xfff800011cca7c10) at ./sql/handler.h:3495 > #7 join_read_always_key (tab=0xfff800011cd285c0) at ./sql/sql_select.cc:24407 > #8 0x0191df74 in sub_select (join=0xfff800011c017560, > join_tab=0xfff800011cd285c0, end_of_records=) at > ./sql/sql_select.cc:23632 > #9 0x0195c6ec in do_select (procedure=0x0, > join=0xfff800011c017560) at ./sql/sql_select.cc:23146 > #10 JOIN::exec_inner (this=0xfff800011c017560) at ./sql/sql_select.cc:5010 > #11 0x0195cd60 in JOIN::exec (this=0xfff800011c017560) at > ./sql/sql_select.cc:4796 > #12 0x0195a938 in mysql_select (thd=0xfff800011c000dc8, > tables=0xfff800011c015f48, fields=..., conds=0xfff800011c016818, > og_num=1, order=, group=, > having=, proc_param=, > select_options=, result=, > unit=, select_lex=) at > ./sql/sql_select.cc:5326 > #13 0x0195ac54 in handle_select (thd=0xfff800011c000dc8, > lex=0xfff800011c005170, result=0xfff800011c017538, > setup_tables_done_option=) at ./sql/sql_select.cc:628 > #14 0x018a0d64 in execute_sqlcom_select > (thd=0xfff800011c000dc8, all_tables=0xfff800011c015f48) at > ./sql/sql_parse.cc:6141 > #15 0x018aea04 in mysql_execute_command > (thd=0xfff800011c000dc8, is_called_from_prepared_stmt=false) at > ./sql/sql_parse.cc:3950 > #16 0x018b6168 in mysql_parse (thd=0xfff800011c000dc8, > rawbuf=, length=, > parser_state=) at ./sql/sql_parse.cc:7862 > #17 0x018b929c in dispatch_command (command=COM_QUERY, >
Bug#1070063: Remmina fails to connect with Windows systems: Protocol Security Negotiation Failure (older release works)
Hi, On Thu, 20 Jun 2024 19:58:55 +0900 Kentaro HAYASHI wrote: > On Mon, 29 Apr 2024 15:41:02 +0200 Daniel Leidert wrote: > > > > when I try to connect to a windows (11) system, I get errors saying > > something like "check security protocol negotiation". When I set it > > the security protocol negotiation to automatic detection, there is a > > connection attempt, but the credentials are not accepted. As I > > haven't changed anything in the RDP setup, I tried downgrading to > > version 1.4.34, and everything works now as expected again. I'm not > > quite sure if this issue is related > > to https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177 > > and/or https://gitlab.com/Remmina/Remmina/-/issues/3090, or if this is a > > complete > > different issue. > > > > If the problem was caused > by https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177, it was > fixed in 1.4.35+dfsg-2. [1] > > Is this issue reproducible with 1.4.35+dfsg-2? I just updated, and now I can no longer reproduce the issue. Thus, I consider it fixed, likely by the mentioned upload. Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#1075747: curl: X.509 client certificates not working with curl/8.8.0-2
On Thu, 4 Jul 2024, Jan Schlien wrote:
curl upstream has fixed a few x509asn.1 bugs since 8.8.0 that will be included
in the pending 8.9.0 release that ships in three weeks.
I believe this specific bug is fixed by this commit:
https://github.com/curl/curl/commit/9aa1d412b814a40868558da51a6ab28ce1384a58
/ Daniel
Package: curl
Version: 8.8.0-2
Severity: normal
/usr/bin/curl --cert --key no longer works with the version
mentioned above. It worked well with the previous version 8.8.0-1. The error
message is:
curl: (35) error reading X.509 key or certificate file
From the changelog, this bullet point comes to mind:
* Switch curl package/binary to use gnutls, now with HTTP3 support
Looking at strace output, curl does read a lot of certs from /etc/ssl/certs/
(not shown) but it not attempt to read the path given with --cert. It reads the
--key file and then does a bogus sendmsg():
openat(AT_FDCWD, "path_removed.key", O_RDONLY|O_CLOEXEC) = 6
newfstatat(6, "", {st_mode=S_IFREG|0600, st_size=1854, ...}, AT_EMPTY_PATH) = 0
lseek(6, 0, SEEK_CUR) = 0
read(6, "-BEGIN ENCRYPTED PRIVATE KEY"..., 1855) = 1854
read(6, "", 1) = 0
close(6) = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 6
newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = 0
read(6, "# Locale name alias data base.\n#"..., 4096) = 2996
read(6, "", 4096) = 0
close(6) = 0
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/gnutls30.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/gnutls30.mo", O_RDONLY) = -1
ENOENT (No such file or dir ectory)
sendmsg(-1, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\3\3\0\2\1\0", iov_len=7}], msg_iovlen=1,
msg_controllen=0, msg_flags=0}, 0) = -1 EBADF (Bad file descriptor)
close(5) = 0
After that, it prints the error message one character by one and exits. Let me
know if anything else is needed.
Thanks,
Jan
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages curl depends on:
ii libc6 2.38-13
ii libcurl3t64-gnutls 8.8.0-2
ii zlib1g 1:1.3.dfsg+really1.3.1-1
curl recommends no packages.
curl suggests no packages.
-- no debconf information
--
/ daniel.haxx.se
Bug#1074610: [chdist] Produces warnings due to deprecated Perl syntax
Package: devscripts Version: 2.23.7 The chdist(1) program needs an update. On unstable: $ chdist create local http://apt.example.com/debian trixie main given is deprecated at /usr/bin/chdist line 710. when is deprecated at /usr/bin/chdist line 711. when is deprecated at /usr/bin/chdist line 714. when is deprecated at /usr/bin/chdist line 717. when is deprecated at /usr/bin/chdist line 720. when is deprecated at /usr/bin/chdist line 723. when is deprecated at /usr/bin/chdist line 726. when is deprecated at /usr/bin/chdist line 729. when is deprecated at /usr/bin/chdist line 732. when is deprecated at /usr/bin/chdist line 735. when is deprecated at /usr/bin/chdist line 738. when is deprecated at /usr/bin/chdist line 741. when is deprecated at /usr/bin/chdist line 744. when is deprecated at /usr/bin/chdist line 747. when is deprecated at /usr/bin/chdist line 750. when is deprecated at /usr/bin/chdist line 753. when is deprecated at /usr/bin/chdist line 756. when is deprecated at /usr/bin/chdist line 759. when is deprecated at /usr/bin/chdist line 762. Run chdist apt local update And enjoy. --Daniel
Bug#1074609: dracut: fails to install cryptsetup (lvm-on-luks)
Package: dracut Version: 102-3 Severity: important This system has been booting with a dracut-generated initramfs for several years. i ran into some trouble with the systemd 256 transition, but that was resolved. today, i tried to reboot and found that the dracut-generated initramfs was unable to find cryptsetup in a way that would unlock the local encrypted disk. I do not have systemd-cryptsetup installed, but i do have cryptsetup installed, and the root filesystem is derived from an LVM logical volume extracted from an lvm physical volume based on a dmcrypt LUKS volume. I've now uninstalled dracut and moved to initramfs-tools. while the initramfs-tools-generated initramfs is twice the size of the dracut-generated initramfs, it does contain the utilities i need to get the system to boot again. I'm willing to debug further if it would help. This was a pretty nasty failure, as it made the machine completely unbootable. --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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) Versions of packages dracut depends on: ii dracut-core 102-3 dracut recommends no packages. Versions of packages dracut suggests: pn dracut-network signature.asc Description: PGP signature
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Hi Jonathan, thanks for your swift response. To avoid any further delay, maybe you could check out the proposed handling and my question because I'd like to make sure to get it right. Am Montag, dem 01.07.2024 um 18:49 +0100 schrieb Jonathan Wiltshire: > On Mon, Jul 01, 2024 at 02:38:14AM +0200, Daniel Leidert wrote: > > > > I had to make a second upload because I used the wrong source for the > > upload (I started with the Go-team repository, but then decided to > > introduce the code to the Debian LTS repository, where I finalized my > > work. Unfortunately, I uploaded a build from the first, which was > > incomplete. After I discovered my mistake, I built from the correct one > > and uploaded runc 1.0.0~rc93+ds1-5+deb11u5. The debdiff will show that > > that it is the one that I uploaded to #1072248. Sorry and thanks. > > Fair enough, but you didn't give any clues in your changelog that a > regression fix was needed, or mention it in this request. > You're committed with 1.0.0~rc93+ds1-5+deb11u4 now that it's in the > archive. > > I'm also rejecting your new 1.0.0~rc93+ds1-5+deb11u5 because it changes > history in the changelog and still has an unhelpful message about syncing > with a repository users know nothing about. > > Please don't change history, and send a debdiff (relative to u4) of a > proposed upload fixing the regressions as 1.0.0~rc93+ds1-5+deb11u5 and a > proper changelog. Do not upload without further approval. Ok. So you'll get a debdiff between the uploaded u4 and the proposed u5. The changelog will be adjusted to reflect the changes between these versions and explain the regression. Is it ok if I clean up the changelog from the u4 upload (there are some redundant lines at the end of that entry from gbp) and mention that in the changelog entry of u5? Or do you want the changelog entry for u4 being preserved as is? Regards, Daniel signature.asc Description: This is a digitally signed message part
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Hi Jonathan, I had to make a second upload because I used the wrong source for the upload (I started with the Go-team repository, but then decided to introduce the code to the Debian LTS repository, where I finalized my work. Unfortunately, I uploaded a build from the first, which was incomplete. After I discovered my mistake, I built from the correct one and uploaded runc 1.0.0~rc93+ds1-5+deb11u5. The debdiff will show that that it is the one that I uploaded to #1072248. Sorry and thanks. Regards, Daniel Am Samstag, dem 29.06.2024 um 20:57 + schrieb Jonathan Wiltshire: > package release.debian.org > tags 1072248 = bullseye pending > thanks > > Hi, > > The upload referenced by this bug report has been flagged for > acceptance into the proposed-updates queue for Debian bullseye. > > Thanks for your contribution! > > Upload details > == > > Package: runc > Version: 1.0.0~rc93+ds1-5+deb11u4 > > Explanation: Fix-busybox-tarball-url; prevent buffer overflow writing > netlink messages [CVE-2021-43784]; fix tests on newer kernels; > prevent write access to user-owned cgroup hierarchy > '/sys/fs/cgroup/user.slice/...' [CVE-2023-25809]
Bug#1074503: [Pkg-netatalk-devel] Bug#1071945: netatalk: FTBFS against libgcrypt 1.11
Package: netatalk On Sunday, May 26th, 2024 at 7:14 PM, Andreas Metzler wrote: > > Hello, > > netatalk uses libgcrypt-config to locate libgcrypt. This breaks > against libgcrypt 1.11 which does not ship libgcrypt-config anymore. > Please use pkg-config/pkgconf instead. > > A development snapshot of the yet-unreleased libgcrypt 1.11 is available > in experimental. > > cu Andreas > Hi Andreas, Thanks for reporting this against netatalk. I have drafted version 3.2.1~ds-1 that removes the dependency on libgcrypt-config from netatalk's build system. (Among many other fixes.) https://salsa.debian.org/netatalk-team/netatalk/-/blob/debian/latest/debian/changelog?ref_type=heads My sponsor is currently unavailable so I don't know when this can be uploaded. However, I'm confident we can sort it out before the Trixie freeze. :) Sincerely, Daniel
Bug#1002996: ITP: python-orjson -- fast, correct JSON library for Python
Hello Agathe! El sáb, 29 jun 2024 a la(s) 7:53 a.m., Agathe Porte (gag...@debian.org) escribió: > Hi, > > 2024-06-21 20:16 CEST, Daniel Echeverri: > > Since 4.x version glances package depends from python-orjson, do you plan > > to work on this soon? I could upload the package once it's already. > > I am also DD and usually do my own uploads for the Debian Python team. > Thanks for the proposal nonetheless. > > > I was checking the dependencies of python-orjson seems > > depends of itoap rust library that isn't include in debian yet. For now, > I > > will work in can include this rust library in debian, meanwhile I receive > > news about you. > > Nice catch. I am also part of the Debian Rust Team so I packaged > and uploaded the itoap dependency: > > > https://salsa.debian.org/rust-team/debcargo-conf/-/tree/pending-itoap?ref_type=heads > > Now we wait for it to pass the NEW queue before moving on. > I will upload my preliminary packaging in the DPT namespace on Salsa: > > https://salsa.debian.org/python-team/packages/python-orjson > Oh great news! Thanks for your work!! and please let me know if you ever need any extra help. Regards -- Daniel Echeverri Debian Developer Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#1074498: RFS: baby/1.0-2 [ITP] -- Abbreviate long commands in terminal
Hi Manuel, On Sat, Jun 29, 2024 at 08:23:14PM -0300, Manuel Guerra wrote: > I completely understand what you are saying about the program not being > very useful for Debian, it has few functions but I hope to expand it later. I'd recommend incubating your idea in the wider FLOSS community (which I admit can be hard to get a foot into). Distributions are only really interested in programs once they've reached a level of usefulnes you can usually only get to by either having lots of experience already or getting feedback from others. However Debian unstable is not the right place to gather this early stage feedback for something like this. You can try IRC or other Debian community spaces https://wiki.debian.org/Community, but I'm not sure we have anything that's quite right for you. Hmm. > Regarding the tarball and the binary included in the package, I will solve > it as soon as possible. This error is because I am new to the world of free > software and it took me a long time to get to this point since I have done > everything self-taught, breaking my brain reading forums on the web. Admirable :) You should try to find a community space where people at a comparable (but maybe slightly higher) skill level as you hang out. I'm afraid I'm not much help with specifics here. --Daniel signature.asc Description: PGP signature
Bug#1074498: RFS: baby/1.0-2 [ITP] -- Abbreviate long commands in terminal
Hi Manuel, On Sat, Jun 29, 2024 at 05:50:53PM -0400, Manuel Guerra wrote: > * Package name : baby >Version : 1.0-2 >Upstream contact : Manuel Guerra > * URL : https://github.com/manuwarfare/baby > * License : GPL-3+ > * Vcs : https://salsa.debian.org/manuwarfare/baby >Section : utils > > The source builds the following binary packages: > > baby - Abbreviate long commands in terminal The README pitch sounds interesting, but I fear there's not enough documentation (or useful functionality) at this point for this to be useful in Debian. I'm afraid your packaging also has severe problems. Somehow you've included a tarball in the (unpacked) source package as well as a binary of your program. The latter is a no-go in Debian (main) that we'd ordinarily fix during packaging, but since you're upstream you ought to just fix your source package build. Have a read of the DFSG and perhaps a friendly packaging tutorial[1]. [ I can't find a better reference for the pedantic (but necessary) definition of what we consider source code that obviously explains that compiled binaries are not allowed. ] [1]: https://www.debian.org/doc/devel-manuals#packaging-tutorial --Daniel signature.asc Description: PGP signature
Bug#1060774: bullseye-pu: netatalk/3.1.12~ds-8+deb11u2
On Sunday, June 30th, 2024 at 5:33 AM, Jonathan Wiltshire wrote: > > > Hi, > > This request was approved for 11.10 but not uploaded in time; is it still > relevant for 11.11, the planned final point release for bullseye? > > Thanks, > > -- > Jonathan Wiltshire j...@debian.org > Debian Developer http://people.debian.org/~jmw > Hi Jonathan, Yes, I think this is still relevant for 11.11. Unfortunately, my sponsor hasn't been responsive for some time. I will remind him again now... Sincerely, Daniel
Bug#1074475: CVE-2024-38441: Heap out-of-bounds write in directory.c
Package: netatalk Version: 3.1.18~ds-1+b2 Severity: critical Tags: patch security upstream Justification: root security hole X-Debbugs-Cc: Debian Security Team This vulnerability in Netatalk arises due to a lack of validation for the length field after parsing user-provided data, leading to an out-of-bounds heap write of one byte (\0). Under specific configurations, this can result in an out-of-bounds write to the metadata of the next heap block, potentially allowing an attacker to execute code in the root context. The upstream project has issued a patch and fixed version 3.2.1: https://netatalk.io/security/CVE-2024-38441 https://github.com/Netatalk/netatalk/commit/77b5d99007cfef4d73d76fd6f0c26584891608e5.diff https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-1
Bug#1074474: CVE-2024-38440: Heap out-of-bounds write in uams_dhx_pam.c
Package: netatalk Version: 3.1.18~ds-1+b2 Severity: critical Tags: patch security upstream Justification: root security hole X-Debbugs-Cc: Debian Security Team This vulnerability in Netatalk arises due to a lack of validation for the length field after parsing user-provided data, leading to an out-of-bounds heap write of one byte (\0). Under specific configurations, this can result in reading metadata of the next heap block, potentially causing a Denial of Service (DoS) under certain heap layouts or with ASAN enabled. The upstream project has issued a patch and fixed version 3.2.1: https://netatalk.io/security/CVE-2024-38440 https://github.com/Netatalk/netatalk/commit/77b5d99007cfef4d73d76fd6f0c26584891608e5.diff https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-1
Bug#1074473: CVE-2024-38439: Heap out-of-bounds write in uams_pam.c
Package: netatalk Version: 3.1.18~ds-1+b2 Severity: critical Tags: security upstream patch Justification: root security hole X-Debbugs-Cc: Debian Security Team This vulnerability in Netatalk arises due to a lack of validation for the length field after parsing user-provided data, leading to an out-of-bounds heap write of one byte (\0). Under specific configurations, this can result in an out-of-bounds write to the metadata of the next heap block, potentially allowing an attacker to execute code in the root context. The upstream project has issued a patch and fixed version 3.2.1: https://netatalk.io/security/CVE-2024-38439 https://github.com/Netatalk/netatalk/commit/77b5d99007cfef4d73d76fd6f0c26584891608e5.diff https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-1
Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing
Hi Daichi, On Sun, Jun 16, 2024 at 04:08:26PM +0900, Daichi Fukui wrote: > > Daichi, I'd be happy to sponsor this upload in principle (once it passes > > review) but only if you're interested in taking care of blktrace going > > forward. > > Yes, I'm interested in taking care of blktrace and have a plan to address > a different issue, that is #1069862. I appreciate it if you could > sponsor this upload. > > > Firstly, apologies Daichi, if you wish adopt this package and maintain > > it moving forward, like Daniel, I would be happy to assist and support > > you as needed if requested. > > Yes, I would like to adopt the blktrace package and hopefully get > assistance for that if you don't mind. Alright. If you want to adopt it we should fixup the maintainer/uploader metadata. Since bas agreed to the takeover you can just go ahead and implement it yourself in d/control. Whether to leave Dmitry in Uploaders (which would represent co-maintanance) is your call as maintainer now. Overall you can basically choose one of the following maintanance approaches: 1) Be responsible for dealing with everything yourself. You are in Maintainers and there's no Uploaders, 2) Have a select set of people (maint+uploaders) be collectively responsible or 3) Collaborative maintainance across all of Debian. i.e. anyone can upload (we call this NMU) at will. You'd add yourself to the [LowThresholdNmu] list in that case [LowThresholdNmu]: https://wiki.debian.org/LowThresholdNmu Currently blktrace is packaged in git using the "only debian/ dir in git" approach https://salsa.debian.org/debian/blktrace. Personally I don't like that workflow and would strongly prefer switching to something else as it also impacts my sponsorship/review work. Do you have any preference among the git workflows in Debian? .. yet ;-) > In addition, I've updated the draft package as follows, following your > review for improvement. Hold off on uploading a new package to mentors with the metadata changes, I don't have the focus right now but I'm sure to have more review comments once I get around to it ;) Feel free to poke and prod if I don't get my keyboard in gear. --Daniel signature.asc Description: PGP signature
Bug#1074000: RESTful API feature does not work, because of missing "orjson" library
te.handle(scope,
> receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 297, in handle
>
> Jun 21 14:23:41 mapout glances[1168]: await self.app(scope, receive,
> send)
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 77, in app
>
> Jun 21 14:23:41 mapout glances[1168]: await
> wrap_app_handling_exceptions(app, request)(scope, receive, send)
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 64,
> in wrapped_app
>
> Jun 21 14:23:41 mapout glances[1168]: raise exc
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/_exception_handler.py", line 53,
> in wrapped_app
>
> Jun 21 14:23:41 mapout glances[1168]: await app(scope, receive, sender)
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/routing.py", line 72, in app
>
> Jun 21 14:23:41 mapout glances[1168]: response = await func(request)
>
> Jun 21 14:23:41 mapout glances[1168]:^^^
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/fastapi/routing.py", line 278, in app
>
> Jun 21 14:23:41 mapout glances[1168]: raw_response = await
> run_endpoint_function(
>
> Jun 21 14:23:41 mapout glances[1168]:
>
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/fastapi/routing.py", line 193, in
> run_endpoint_function
>
> Jun 21 14:23:41 mapout glances[1168]: return await
> run_in_threadpool(dependant.call, **values)
>
> Jun 21 14:23:41 mapout glances[1168]:
> ^
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/concurrency.py", line 42, in
> run_in_threadpool
>
> Jun 21 14:23:41 mapout glances[1168]: return await
> anyio.to_thread.run_sync(func, *args)
>
> Jun 21 14:23:41 mapout glances[1168]:
> ^^^
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/anyio/to_thread.py", line 56, in run_sync
>
> Jun 21 14:23:41 mapout glances[1168]: return await
> get_async_backend().run_sync_in_worker_thread(
>
> Jun 21 14:23:41 mapout glances[1168]:
>
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/anyio/_backends/_asyncio.py", line 2144, in
> run_sync_in_worker_thread
>
> Jun 21 14:23:41 mapout glances[1168]: return await future
>
> Jun 21 14:23:41 mapout glances[1168]:
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/anyio/_backends/_asyncio.py", line 851, in
> run
>
> Jun 21 14:23:41 mapout glances[1168]: result = context.run(func, *args)
>
> Jun 21 14:23:41 mapout glances[1168]:
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/glances/outputs/glances_restful_api.py",
> line 361, in _api_status
>
> Jun 21 14:23:41 mapout glances[1168]: return
> ORJSONResponse({'version': __version__})
>
> Jun 21 14:23:41 mapout glances[1168]:
>
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/responses.py", line 184, in
> __init__
>
> Jun 21 14:23:41 mapout glances[1168]: super().__init__(content,
> status_code, headers, media_type, background)
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/starlette/responses.py", line 41, in
> __init__
>
> Jun 21 14:23:41 mapout glances[1168]: self.body = self.render(content)
>
> Jun 21 14:23:41 mapout glances[1168]:
>
> Jun 21 14:23:41 mapout glances[1168]: File
> "/usr/lib/python3/dist-packages/fastapi/responses.py", line 45, in render
>
> Jun 21 14:23:41 mapout glances[1168]: assert orjson is not None,
> "orjson must be installed to use ORJSONResponse"
>
> Jun 21 14:23:41 mapout glances[1168]:^^
>
> Jun 21 14:23:41 mapout glances[1168]: AssertionError: orjson must be
> installed to use ORJSONResponse
>
Thanks for your report!
Yes, you are right, unfortunately, python-orjson isn't included in debian
archive yet[1], so I will work to can include this to fix this problem.
Regards.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002996
--
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#1002996: ITP: python-orjson -- fast, correct JSON library for Python
Hello! Since 4.x version glances package depends from python-orjson, do you plan to work on this soon? I could upload the package once it's already. For the other hand, I was checking the dependencies of python-orjson seems depends of itoap rust library that isn't include in debian yet. For now, I will work in can include this rust library in debian, meanwhile I receive news about you. Thank you very much! -- Daniel Echeverri Debian Developer Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#1074006: ITP: jinjax -- Super components powers for your Jinja templates
Package: wnpp * Package name : jinjax * Upstream Author : Juan-Pablo Scaletti * License : MIT * Homepage : https://github.com/jpsca/jinjax https://jinjax.scaletti.dev Regards, Daniel
Bug#1069212: src:rust-sequoia-openpgp: FTBFS when any librust-*-dev packages that contain *.lalrpop files are installed
Control: clone 1069212 -1
Control: reassign -1 dh-cargo
Control: affects -1 + src:rust-lalrpop src:rust-sequoia-openpgp debcargo
Control: retitle -1 "cargo prepare-debian" should not be invoked by default
with --link-from-system
Over on #debian-rust, we did a bit of archaeology to determine why
1069212 is happening.
It looks like tools that use lalrpop by default will descend into the
current working directory and act on any *.lalrpop there.
The reason that they stumble upon unwritable files is that "cargo
prepare-debian" is being invoked with --link-from-system, instead of
just pointing to /usr/share/cargo/registry directly.
cargo prepare-debian is getting --link-from-system by default due to
choices in dh-cargo.
The revision history of *why* this is on by default is unclear, sadly.
We were able to identify two cases where --link-from-system might be
necessary:
0) a case where a crate has no dependencies at all. in that case, on
the buildd, it's possible that /usr/share/cargo/registry doesn't
exist at all (no librust-*-dev packages installed) and so
--link-from-system avoids pointing to a non-existant repo (instead it
points to an empty repo).
1) a case where some crate wants to "vendor" a third-party crate that
isn't packaged for debian directly.
case (1) seems likely to be pretty unusual. Case (0) also seems unusual
(how many dependency-free packages are there?) but also seems like kind
of a distinct bug. if there are no crate dependencies, then there's no
need to ask cargo to look at a repository of crates anyway.
So it seems simpler and more robust to avoid using --link-from-system by
default, and let the crates that really need to use it override it
directly.
If there's a marginally common case for using --link-from-system, maybe
debcargo should grow an configuration choice that those crates that do
need it can just set directly.
--dkg
On Wed 2024-04-17 22:33:54 -0400, Daniel Kahn Gillmor wrote:
> Source: librust-sequoia-openpgp-dev
> Severity: normal
> X-Debbugs-Cc: Daniel Kahn Gillmor
>
> Hi all--
>
> If i try building rust-sequoia-openpgp (e.g. using debuild -uc -us) as a
> non-privileged user on a system that has some unnecessary dependencies
> installed, i will sometimes get a failure during build.rs that looks
> something like the following (this example is from building on a system
> that has the previous version of librust-sequoia-openpgp-dev installed):
>
>
> -
> Running
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
> [sequoia-openpgp 1.20.0] Selected cryptographic backend: Nettle
> [sequoia-openpgp 1.20.0] processing file
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`
> [sequoia-openpgp 1.20.0] thread 'main' panicked at 'called `Result::unwrap()`
> on an `Err` value: Os { code: 13, kind: PermissionDenied, message:
> "Permission denied" }', build.rs:10:29
> [sequoia-openpgp 1.20.0] stack backtrace:
> [sequoia-openpgp 1.20.0]0: rust_begin_unwind
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
> [sequoia-openpgp 1.20.0]1: core::panicking::panic_fmt
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
> [sequoia-openpgp 1.20.0]2: core::result::unwrap_failed
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
> [sequoia-openpgp 1.20.0]3: core::result::Result::unwrap
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/result.rs:1089:23
> [sequoia-openpgp 1.20.0]4: build_script_build::main
> [sequoia-openpgp 1.20.0] at ./build.rs:10:5
> [sequoia-openpgp 1.20.0]5: core::ops::function::FnOnce::call_once
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
> [sequoia-openpgp 1.20.0] note: Some details are omitted, run with
> `RUST_BACKTRACE=full` for a verbose backtrace.
> error: failed to run custom build command for `sequoia-openpgp v1.20.0
> (/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0)`
>
> Caused by:
> process didn't exit successfully:
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
> (exit status: 101)
> --- stdout
> processing file
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`
>
> --- stderr
> Selected cryptographic backend: Nettle
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os
> {
Bug#1060774: bullseye-pu: netatalk/3.1.12~ds-8+deb11u2
On Thursday, June 13th, 2024 at 6:33 AM, Jonathan Wiltshire wrote: > > > On Sat, Feb 24, 2024 at 11:16:47AM +0000, Daniel Markstedt wrote: > > > If it looks good, I will arrange for this to get uploaded. > > > Yes, you can go ahead with that. > > Thanks, > Cheers. I personally don't have upload permissions, yet. My own application stalled, and now facing technical issues. I asked the other package maintainer to take care of the upload. Hopefully he will have the chance to look at it soon. Best, Daniel
Bug#1052015: Are NMUs packaging new upstream versions appropriate? (Was: Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing)
Hi Tobias and Phil,
On Wed, Nov 01, 2023 at 01:50:04PM +0100, Tobias Frost wrote:
> this seems to be a NMU, and for NMUs there is a set of rules [0], for
> example it needs to fix (important) bugs.
Policy section 5.11.1. explicitly says even whishlist bugs are fair game:
pol> ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new
pol> upstream version, but care should be taken to minimize the impact to the
pol> maintainer.)
> Maybe I am missing something but I think this upload is outside of the
> scope of an NMU. Please let me know if I missed something.
Note policy sections 5.11.2. and 5.11.4. also explicitly talk about this
NMU-with-new-upstream-version scenario:
pol> If a new upstream version is packaged in the NMU, the Debian revision is
pol> set to 0, for example 1.6-0.1.
and
pol> Note that if you ever need to revert a NMU that packages a new upstream
pol> version, it is recommended to use a fake upstream version like
pol> CURRENT+reallyFORMER until one can upload the latest version again.
So I hardly think we can claim this is out of scope for NMUs if policy
deals with the nitty gritty of how to do it :)
--Daniel
signature.asc
Description: PGP signature
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Fri, Jun 14, 2024 at 09:55:31PM +0200, Samo Pogačnik wrote: > Hi Daniel, > > Dne 14.06.2024 (pet) ob 20:50 +0200 je Daniel Gröber napisal(a): > > Below you're not ACK'ing some of my comments again. With email review you > > really kind of have to say something about each comment otherwise it's > > really hard to tell if you just missed one or not and it's easier to > > discuss any disagreements sooner (when I have forgotten less of the context > > :x) > > rather than later when you send the next version. > > I just realized that i sent the unfinished mail instead of saving the > draft. I am sorry. I'll add the missing replies here and thanks for the > valuable response. No worries, that happens :) > > I noticed another thing, w > > e disable the test suite for what appear to be > > trivial reasons. I really don't like maintaining packages without a test > > suite so this is a no-go. Please look into why it's not working and fix it > > with more upstreamable patches if necessary. > > > > From a quick look it seems removing the `git config core.autocrlf input` > > call in test/setup already gets us quite far but the way git subrepo finds > > its libs needs adjustment too. > > > > Commit review below: > > > > > From: Samo Pogačnik > > > > > > Default 'git-core' location of git-subrepo executables currently > > > > +The default 'git-core' ... ? > thanks > > > > > > does not automatically integrate git-subrepo into git's own bash- > > > completion. This change moves git-subrepo executables into > > > /usr/share/git-subrepo and adds a symlink of its main executable > > > script into /usr/bin to achieve recognition of the 'git subrepo' > > > sub-command under the git bash-completion (through git's: > > > --list-cmds=...,other,...). > > > > > > Gbp-Pq: Name 0001-Fixed-bash-completion-integration-with-git.patch > > > --- > > > Makefile | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/Makefile b/Makefile > > > index 79898f5..3d84454 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -17,7 +17,7 @@ SHARE = share > > > > > > # Install variables: > > > PREFIX ?= /usr/local > > > -INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) > > > +INSTALL_LIB ?= $(DESTDIR)$(PREFIX)/share/$(NAME) > > > > While we're fixing upstream's mess $(DESTDIR) should be interpolated in the > > install target only so overriding the directory structure is easier. > > > > The install target should look something like this, vars listed for > > clarity: > > > > ``` > > PREFIX ?= /usr/local > > INSTALL_LIB ?= $(PREFIX)/share/$(NAME) > > install: > > $(INSTALL) -d -m 0755 $(DESTDIR)$(INSTALL_LIB)/ > > $(INSTALL) -C -m 0755 $(LIB) $(DESTDIR)$(INSTALL_LIB)/ > > ``` > > > > Notice the canonical use of $(INSTALL) instead of the plain command, > > doesn't make a difference in this case but it's good Makefile hygiene. > > > ACK > > > With that setup we can just export the INSTALL_* vars in debian/rules to > > override them: > > > > export INSTALL_LIB=/usr/share/git-subrepo > > export INSTALL_EXT=$(INSTALL_LIB) > > > > Setting INSTALL_EXT equal to INSTALL_LIB gets rid of the git-subrepo.d as > > I've been requesting. > > > > I'm sending you the full patch "Drop unecessary subdir in usr/share" I used > > to test this seperately, lets see if you can figure out how to apply it to > > your repo ;) > > > ACK > > > You still have to add a seperate commit to make the $(DESTDIR) adjustment. > > > > > INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d > > > INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 > > > > > > @@ -67,6 +67,8 @@ install: > > > install -C -m 0755 $(EXTS) $(INSTALL_EXT)/ > > > install -d -m 0755 $(INSTALL_MAN1)/ > > > install -C -m 0644 $(MAN1)/$(NAME).1 $(INSTALL_MAN1)/ > > > + install -d -m 0755 $(DESTDIR)$(PREFIX)/bin/ > > > + ln -s ../share/$(NAME)/$(NAME) $(DESTDIR)$(PREFIX)/bin/$(NAME) > > > > Creating symlinks like this we'd usually do with dh_link(1). This would be > > OK if you're intending to send this patch upstream? > > > ACK > > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -64,7 +64,7 @@ install: > > > install -C -m 0755 $(LIB) $(INSTALL_LIB)/ > > > sed
Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing
Hi all, I disagree with Phil and Tobias' assessment that an NMU is inappropriate here. Given the salvaging process uses NMUs as an indicator for maintainer inactivity I feel it's exactly what we should be doing here. NMU and eventually salvage if Bas still shows no interest in maintaining this package. Daichi, I'd be happy to sponsor this upload in principle (once it passes review) but only if you're interested in taking care of blktrace going forward. According to [contributors] Bas has not made any uploads since 2019, has been CCed on the RFS and not responded for months and is likeley about to get an NMU, which makes it look like a candidate for salvaging in the near future to me. So Daichi, you could become it's official maintainer if that interests you. [contributors]: https://contributors.debian.org/contributor/bas/ --Daniel signature.asc Description: PGP signature
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Fri, Jun 14, 2024 at 07:15:40PM +0200, Samo Pogačnik wrote: > Thanks for the review. I'll do my best to include as much as i know how > to into another 'release candidate', however it may take me a while. Thanks for working on this :) Recent discussion on d-devel makes me think git-subtree/subrepo have a good chance of becoming more popular as we educate upstreams about how to properly avoid future xz snafu. So you're doing really important work here <3 > Dne 10.06.2024 (pon) ob 22:26 +0200 je Daniel Gröber napisal(a): > > In general you're missing the Debian patch metadata, see [DEP-3]. I hate > > this archaic stuff I just mention it for completness. If you use gbp-pq for > > generating the patches you can mostly ignore. I do like to use the > > Forwarded field to note the upstream PR for the patch tho. > > > > [DEP-3]: https://dep-team.pages.debian.net/deps/dep3/ > > > > Next time I see the patches I want to see a Forwarded field for each -- one > > PR for all of them pleas, not spam upstream :) > > > I am a bit confused. I'm not sure i want to present patches upstream while you > (at least) have not yet accepted them. Otherwise i'd have to revise my > upstream > proposal (and spam upstream) every time you find another thing i missed about > the debian policy (which i probably will for some time). How do you see this? That's not spamming upstream so much as just doing upstream development :) There's nothing wrong with pushing revisions in that case. If you insist you can send me the patches/branch for review first, but I don't see a need for that. I was just trying to be clear about the fact that these patches should be well motivated and single-purpose so upstream can understand them. If it happens that upstream and Debian policy disagree there's no problem with sending upstream the patches they'll take and just add the rest on top in the Debian package patch stack. I do think we should try to always push patches upstream first to keep them informed about what we're doing. The "spam" comment was really just me making sure you're aware you're not expected to split each patch into it's own PR. Don't worry about that too much. Looking at the upstream activity I fear us being ignored may the worst that'll happen. My hunch is that we may end up having to take over as git-subrepo upstream. Only one way to know (send a PR) and in any case we'd want clean commits :) One workflow note: whatever you do you should make sure not to have Gbp-* fields in the commits you send upstream. Getting the Debian tooling to cooperate here can be a bit tricky. Give it a go and let me know if you need help. Overall what I'd try to do is commit the upstream changes[1] on top of our debian/sid branch, build/test using the Debian tooling and once things are working rebase onto the plain upstream branch then push that as a PR. The problem you're going to run into is dpkg-source complaining about unrepresented upstream changes. IIRC you can bypass that problem by only doing binary builds (check dpkg-buildpackage.1 for how to do that) or if all else fails temporarily switching the package to be format=3.0 (native) instead of (quilt). [1]: Dealing with changes that need both upstream and Debian adjustments is probably where git-debrebase would come in handy as it (IIRC) can seperate those a mixed upstream+Debian commit into seperate ones and then you can easily get rid of the Debian specific stuff during the final rebase. You can also just side-step that problem by committing such things separately to begin with. Re-ordering is easy whenever commits are non-overlapping after all. > > > Dne 28.05.2024 (tor) ob 19:23 +0200 je Daniel Gröber napisal(a): > > > > I'm not super happy with the approach of putting git-subrepo.d inside > > > > /usr/share/git-subrepo tbh. I might be able to let it pass but it seems > > > > lintian found another issue that needs patching anyway so you may as > > > > well > > > > fix this too. > > > > I'm still not seeing a change to remove git-subrepo.d. My comments don't > > just go away by ignoring them :P > > > I am sorry that you felt ignored. I simply thought i have a choice here and > tbh > i still do not see what could be wrong by having sourced only scripts in a > separate subdirectory. I'd be happy to understand your git-subrepo.d concerns > better to be able to fully support this decision. No worries. You do have a choice but you should at least communicate why you don't want to do what I suggest i.e. all review comments should be responded to with something lik ACK or NACK+further-discussion. It's not so much about "something wrong" as it is just a matter of having tidy and predictable structure. > > I noticed another thing, we disable the te
Bug#1073209: systemd: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
Package: systemd
Version: 256-1
Severity: normal
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock",
ignoring.
/usr/lib/tmpfiles.d/debian.conf:d /run/lock1777 root root - -
/usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -
systemd: /usr/lib/tmpfiles.d/debian.conf
systemd: /usr/lib/tmpfiles.d/legacy.conf
After an upgrade, i saw this:
Setting up systemd (256-1) ...
Investigating further, it looks like we have duplicate, conflicting directives
both shipped in the systemd package:
0 dkg@alice:~$ grep run/lock\ /usr/lib/tmpfiles.d/*.conf
0 dkg@alice:~$ dpkg -S /usr/lib/tmpfiles.d/{debian,legacy}.conf
0 dkg@alice:~$
Thanks for maintaining systemd in debian!
--dkg
Bug#1015278: ITP Status
Hello! I am interested in include this python app in Debian archive, are you working on this? Is there a git repo where you are working on this? If you want, I could give you a hand and upload these packages. Please let me know how I can help you with this. Regards. -- Daniel Echeverri Debian Developer Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#1068951: new upstream (6.x)
On 6/12/24 13:33, Jakub Ružička wrote: I did what I could with the upstream packaging, so now it's your turn with debian/experimental, Daniel, if you have the time :) thanks for all the work - I will have a time for everything this Friday afternoon/evening and will report back. Regards, Daniel
Bug#1073066: python3-pyspnego: Missing krb5 dependency
Package: python3-pyspnego
Version: 0.10.2-2
Severity: important
X-Debbugs-Cc: neel...@gmail.com
`_gss.py` imports the `krb5` python module but that one is not available in
Debian yet.
Using requests with `gssapi` results in a crash like this:
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 637, in post
return self.request("POST", url, data=data, json=json, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 589, in
request
resp = self.send(prep, **send_kwargs)
^^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 710, in send
r = dispatch_hook("response", hooks, r, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests/hooks.py", line 30, in
dispatch_hook
_hook_data = hook(hook_data, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests_kerberos/kerberos_.py", line
393, in handle_response
_r = self.handle_401(response, **kwargs)
^^^
File "/usr/lib/python3/dist-packages/requests_kerberos/kerberos_.py", line
276, in handle_401
_r = self.authenticate_user(response, **kwargs)
^^
File "/usr/lib/python3/dist-packages/requests_kerberos/kerberos_.py", line
246, in authenticate_user
auth_header = self.generate_request_header(response, host)
File "/usr/lib/python3/dist-packages/requests_kerberos/kerberos_.py", line
213, in generate_request_header
self._context[host] = ctx = spnego.client(
^^
File "/usr/lib/python3/dist-packages/spnego/auth.py", line 169, in client
return _new_context(
^
File "/usr/lib/python3/dist-packages/spnego/auth.py", line 84, in
_new_context
return proxy(
^^
File "/usr/lib/python3/dist-packages/spnego/_gss.py", line 318, in __init__
raise ImportError("GSSAPIProxy requires the Python gssapi library: %s" %
GSSAPI_IMP_ERR)
ImportError: GSSAPIProxy requires the Python gssapi library: No module named
'krb5'
Most likely this need to be resolved by packaging `python3-krb5` and depending
on it.
Have a nice day,
--nX
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.8-rt-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FORCED_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-pyspnego depends on:
ii python3 3.11.8-1
ii python3-cryptography 42.0.5-2
ii python3-gssapi1.8.3-1
python3-pyspnego recommends no packages.
python3-pyspnego suggests no packages.
-- no debconf information
Bug#1064536: scribus: Please package 1.6.1
Hi, what's the status of getting 1.6 uploaded? Do you need any help? Regards, Daniel
Bug#979188: [PATCH git-subrepo] Drop unecessary subdir in usr/share
---
Makefile| 1 +
debian/rules| 7 ++-
lib/git-subrepo | 22 +-
test/setup | 3 ---
4 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/Makefile b/Makefile
index e7643a7..79898f5 100644
--- a/Makefile
+++ b/Makefile
@@ -62,6 +62,7 @@ $(DOCKER_TESTS):
install:
install -d -m 0755 $(INSTALL_LIB)/
install -C -m 0755 $(LIB) $(INSTALL_LIB)/
+ sed -i 's!^SUBREPO_EXT_DIR=.*!SUBREPO_EXT_DIR=$(INSTALL_EXT)!'
$(INSTALL_LIB)/$(NAME)
install -d -m 0755 $(INSTALL_EXT)/
install -C -m 0755 $(EXTS) $(INSTALL_EXT)/
install -d -m 0755 $(INSTALL_MAN1)/
diff --git a/debian/rules b/debian/rules
index a6231a2..558e5cb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,9 +1,14 @@
#!/usr/bin/make -f
#export DH_VERBOSE = 1
+DESTDIR=debian/tmp
export PREFIX=/usr
+export INSTALL_LIB=$(DESTDIR)/usr/share/git-subrepo
+export INSTALL_EXT=$(INSTALL_LIB)
%:
- dh $@ --with=bash-completion
+ dh $@ \
+ -Smakefile --with=bash-completion \
+ -P$(DESTDIR)
override_dh_auto_test:
# Tests are broken without a .git directory, see
diff --git a/lib/git-subrepo b/lib/git-subrepo
index a6d5d96..7072887 100755
--- a/lib/git-subrepo
+++ b/lib/git-subrepo
@@ -12,21 +12,9 @@ set -e
export FILTER_BRANCH_SQUELCH_WARNING=1
# Import Bash+ helper functions:
-SOURCE=${BASH_SOURCE[0]}
-while [[ -h $SOURCE ]]; do
- DIR=$( cd -P "$( dirname "$SOURCE" )" && pwd )
- SOURCE=$(readlink "$SOURCE")
- [[ $SOURCE != /* ]] && SOURCE=$DIR/$SOURCE
-done
-SOURCE_DIR=$(dirname "$SOURCE")
-
-if [[ -z $GIT_SUBREPO_ROOT ]]; then
- # If `make install` installation used:
- source "${SOURCE_DIR}/git-subrepo.d/bash+.bash"
-else
- # If `source .rc` method used:
- source "${SOURCE_DIR}/../ext/bashplus/lib/bash+.bash"
-fi
+
+SUBREPO_EXT_DIR="$(realpath "$(dirname "${BASH_SOURCE[0]}")")/git-subrepo.d" #
replaced by `make install`
+source "${SUBREPO_EXT_DIR}/bash+.bash"
bash+:import :std can version-check
@@ -394,7 +382,7 @@ command:config() {
# Launch the manpage viewer:
command:help() {
- source "${SOURCE_DIR}/git-subrepo.d/help-functions.bash"
+ source "${SUBREPO_EXT_DIR}/help-functions.bash"
local cmd=${command_arguments[0]}
if [[ $cmd ]]; then
if can "help:$cmd"; then
@@ -1952,7 +1940,7 @@ OK() {
usage-error() {
local msg="git-subrepo: $1" usage=
if [[ $GIT_SUBREPO_TEST_ERRORS != true ]]; then
-source "${SOURCE_DIR}/git-subrepo.d/help-functions.bash"
+source "${SUBREPO_EXT_DIR}/help-functions.bash"
if can "help:$command"; then
msg=$'\n'"$msg"$'\n'"$("help:$command")"$'\n'
fi
diff --git a/test/setup b/test/setup
index a05f7ff..ea4df6e 100644
--- a/test/setup
+++ b/test/setup
@@ -5,9 +5,6 @@ git config core.autocrlf input
set -e
-# Set the GIT_SUBREPO_ROOT for testing.
-source "$PWD"/.rc
-
# Get the location of this script
SCRIPT_DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
--
2.39.2
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Sat, Jun 01, 2024 at 10:01:53AM +0200, Samo Pogačnik wrote: > I prepared a new 0.4.6-1 release with patched upstream regarding: > - bash-completition integration with git > - executable permissions on sourced-only files > - hashbangs inside sourced-only files > > I've also removed old lintian-override from debian/, since it is not > required anymore. Thanks, commit review inline below. In general you're missing the Debian patch metadata, see [DEP-3]. I hate this archaic stuff I just mention it for completness. If you use gbp-pq for generating the patches you can mostly ignore. I do like to use the Forwarded field to note the upstream PR for the patch tho. [DEP-3]: https://dep-team.pages.debian.net/deps/dep3/ Next time I see the patches I want to see a Forwarded field for each -- one PR for all of them pleas, not spam upstream :) > Dne 28.05.2024 (tor) ob 19:23 +0200 je Daniel Gröber napisal(a): > > I'm not super happy with the approach of putting git-subrepo.d inside > > /usr/share/git-subrepo tbh. I might be able to let it pass but it seems > > lintian found another issue that needs patching anyway so you may as well > > fix this too. I'm still not seeing a change to remove git-subrepo.d. My comments don't just go away by ignoring them :P I noticed another thing, we disable the test suite for what appear to be trivial reasons. I really don't like maintaining packages without a test suite so this is a no-go. Please look into why it's not working and fix it with more upstreamable patches if necessary. From a quick look it seems removing the `git config core.autocrlf input` call in test/setup already gets us quite far but the way git subrepo finds its libs needs adjustment too. Commit review below: > From: Samo Pogačnik > > Default 'git-core' location of git-subrepo executables currently +The default 'git-core' ... ? > does not automatically integrate git-subrepo into git's own bash- > completion. This change moves git-subrepo executables into > /usr/share/git-subrepo and adds a symlink of its main executable > script into /usr/bin to achieve recognition of the 'git subrepo' > sub-command under the git bash-completion (through git's: > --list-cmds=...,other,...). > > Gbp-Pq: Name 0001-Fixed-bash-completion-integration-with-git.patch > --- > Makefile | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 79898f5..3d84454 100644 > --- a/Makefile > +++ b/Makefile > @@ -17,7 +17,7 @@ SHARE = share > > # Install variables: > PREFIX ?= /usr/local > -INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) > +INSTALL_LIB ?= $(DESTDIR)$(PREFIX)/share/$(NAME) While we're fixing upstream's mess $(DESTDIR) should be interpolated in the install target only so overriding the directory structure is easier. The install target should look something like this, vars listed for clarity: ``` PREFIX ?= /usr/local INSTALL_LIB ?= $(PREFIX)/share/$(NAME) install: $(INSTALL) -d -m 0755 $(DESTDIR)$(INSTALL_LIB)/ $(INSTALL) -C -m 0755 $(LIB) $(DESTDIR)$(INSTALL_LIB)/ ``` Notice the canonical use of $(INSTALL) instead of the plain command, doesn't make a difference in this case but it's good Makefile hygiene. With that setup we can just export the INSTALL_* vars in debian/rules to override them: export INSTALL_LIB=/usr/share/git-subrepo export INSTALL_EXT=$(INSTALL_LIB) Setting INSTALL_EXT equal to INSTALL_LIB gets rid of the git-subrepo.d as I've been requesting. I'm sending you the full patch "Drop unecessary subdir in usr/share" I used to test this seperately, lets see if you can figure out how to apply it to your repo ;) You still have to add a seperate commit to make the $(DESTDIR) adjustment. > INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d > INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 > > @@ -67,6 +67,8 @@ install: > install -C -m 0755 $(EXTS) $(INSTALL_EXT)/ > install -d -m 0755 $(INSTALL_MAN1)/ > install -C -m 0644 $(MAN1)/$(NAME).1 $(INSTALL_MAN1)/ > + install -d -m 0755 $(DESTDIR)$(PREFIX)/bin/ > + ln -s ../share/$(NAME)/$(NAME) $(DESTDIR)$(PREFIX)/bin/$(NAME) Creating symlinks like this we'd usually do with dh_link(1). This would be OK if you're intending to send this patch upstream? > > # Uninstall support: > uninstall: > -- > 2.39.2 > > From: Samo Pogačnik > > Bash scripts under git-suberpo.d are not to be executed standalone > therefore should not have executable permissions. > > Gbp-Pq: Name 0002-Removed-executable-permission-on-sourced-only-files.patch > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 3d84454..818cd7d 100644 > --- a/Makefile > +++ b/Makefile > @@ -64,7 +64,7
Bug#1071260: prometheus-postgres-exporter: pg_replication_slots metrics query fails on standbys with replication slots
No sooner than I had posted my previous reply, I discovered that there is in fact already an upstream PR for the aforementioned #547 [1]; unsurprisingly #548 [2] claims to fix it, but has been awaiting approval since 2021 :( Perhaps you could give that PR a nudge, and perhaps it also makes sense if we simply cherry-pick that as the Debian patch. [1]: https://github.com/prometheus-community/postgres_exporter/issues/547 [2]: https://github.com/prometheus-community/postgres_exporter/pull/548 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071260: prometheus-postgres-exporter: pg_replication_slots metrics query fails on standbys with replication slots
Hi Michael, As this would seem to also affect the latest upstream release (v0.15.0), can you please forward this patch upstream and make a DEP-3 reference to it in your patch? There is little point in only patching this in Debian when it in fact affects the wider community. Thanks OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057752: [Pkg-electronics-devel] Bug#1057752: fpga-icestorm: diff for NMU version 0~20230218gitd20a5e9-1.1
Hi Chirs, On Fri, Jun 07, 2024 at 09:13:19PM +0200, Chris Hofstaedtler wrote: > I've prepared an NMU for fpga-icestorm (versioned as > 0~20230218gitd20a5e9-1.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Thanks for the patch. LGTM, feel free to upload straight away if you like. --Daniel signature.asc Description: PGP signature
Bug#1072644: new upstream (3.8.4)
Package: rspamd Hi, rspamd 3.8.4 has been released back in February - it would be nice if you could update the package in Debian. Regards, Daniel
Bug#1072299: Compositor-related crashes
I'm going to need a spot of help with this. I have Chromium running under GDB, with surprisingly low overhead (I can browse like normal if I drop the --single-process flag). As far as I could find, the "trap invalid opcode" error reported in syslog is synonymous with a SIGILL, so I set "handle SIGILL stop pass". Unfortunately, the trap errors continue to occur without GDB stopping execution. Do you know how to set this up to get to a backtrace? Maybe a way of disabling the signal/crash handler?
Bug#1072514: libgnutls30: Disabled KTLS support
Source: libgnutls30 Version: 3.7.9-2+deb12u1 Severity: wishlist X-Debbugs-Cc: daniel.salz...@nic.cz Dear Maintainer, The GnuTLS library is built with KTLS support disabled. If the `--enable-ktls` configure option is added to CONFIGUREARGS in debian/rules, the library builds successfully. Also, TLS offloading seems to work well. Could you please enable this feature in the package? -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1072299: Compositor-related crashes
On Fri, 2024 May 31 21:49-04:00, Andres Salomon wrote: > Oh! Apparently my info is outdated. According to > <https://bugs.debian.org/894081>, this was fixed back in August. It does > indeed look like > <https://deb.debian.org/debian-security-debug/pool/updates/main/c/chromium/> > has the dbgsym packages for .141. Thanks for the pointer. I did not know about debian-security-debug, as the Debian wiki pages make no mention of it. I've installed .141 and the dbgsym package, and confirmed that at least the tab crash still occurs. Will try to get some useful telemetry out of this. --Daniel
Bug#1071552: [pkg-gnupg-maint] Bug#1071552: Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG
On Thu 2024-05-30 18:34:13 +0200, Andreas Metzler wrote:
> the issue report refers to two patches, one of these is already part of
> 2.2.43. The other one[1] seemed pretty straightforward to backport
> (functions moved to other files and cipher_filter_ocb instead of
> cipher_filter_aead). I would appreciate a second pair of eyes.
I wish the patch wasn't so large, even if it appears to backport
cleanly!
I confess i don't fully understand the logic around iobufs and
I'm also more than a little distressed that the bulk of this logic and
buffer fiddling seems to be about deciding whether to compress the input
stream or not, on the basis of whether it's using SEPIDv1 (or LibrePGP's
non-standard OCB mode) vs. the deprecated, obsolete SED.
Nothing should be generating SED packets today, in 2024. The idea that
the compression layer is going to defend against chosen ciphertext
attacks is… lacking in cryptographic rigor.
Furthermore, the idea that GnuPG will (or will not) add a compression
layer depending on the first 5 bytes of the input stream is pretty
strange. Consider this deeply weird comparison, where depending on the
input data, the same GnuPG pipeline will compress or not compress:
```
0 dkg@alice:~$ packetlist() { printf '%s\n' "$1" | gpg --compress-algo=ZIP
--encrypt -r "$PGPID" | gpg --unwrap --decrypt | gpg --list-packets; }
0 dkg@alice:~$ diff -u <(packetlist %PDFx) <(packetlist %PDF-)
gpg: encrypted with 255-bit ECDH key, ID 38024D718ABA3F3B, created 2023-12-06
"Daniel Kahn Gillmor"
gpg: encrypted with 255-bit ECDH key, ID 38024D718ABA3F3B, created 2023-12-06
"Daniel Kahn Gillmor"
--- /dev/fd/63 2024-05-31 17:08:37.339457042 -0400
+++ /dev/fd/62 2024-05-31 17:08:37.339457042 -0400
@@ -1,6 +1,4 @@
-# off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
-:compressed packet: algo=1
-# off=2 ctb=cb tag=11 hlen=2 plen=12 new-ctb
+# off=0 ctb=cb tag=11 hlen=2 plen=12 new-ctb
:literal data packet:
mode b (62), created 1717189717, name="",
raw data: 6 bytes
1 dkg@alice:~$
```
Seems to me like the approach that would reduce the overall amount of
complexity is to have an explicit default that does not vary choice of
compression algorithm, based on the choice of incoming cleartext, and
then to actually respect any user-specified --compress-algo, which
doesn't seem to be happening when the first five octets of the input
stream match this magic list.
Of course, i'd be happy to just rip compression out of the OpenPGP
specification entirely anyway -- people who want to compress before
encrypting have many different ways of doing it irrespective of the
OpenPGP spec.
I think we should include an autopkgtest for the gnupg2 source package
as well that explicitly ensures that future updates don't break epg.el.
I'm including it here, but i'll also put it in the autopkgtests to
ensure we don't hit this regression again.
I propose to push this test plus your patch into salsa later today and
if it passes cleanly, i'll go ahead with the upload.
--dkg
#!/bin/sh
set -e
# Author: Daniel Kahn Gillmor
# Emacs has epg mode, which expects a certain behavior from GnuPG.
#
# GnuPG upstream doesn't think that it is a bug to break those
# expectations (see https://dev.gnupg.org/T6481) but we want to avoid
# having those problems in debian. (see
# https://bugs.debian.org/1071552)
# This test ensures that a simple attempt to send signed, encrypted
# PGP/MIME mail with emacs doesn't break with the current version of
# GnuPG.
WORKDIR="$(mktemp -d)"
mkdir -m 0700 "$WORKDIR/a" "$WORKDIR/b" "$WORKDIR/out"
OUTDIR="${AUTOPKGTEST_ARTIFACTS:-$WORKDIR/out}"
cleanup() {
find "$WORKDIR/out" -type f -print0 | xargs --null --no-run-if-empty -- head -v -n100
printf "Cleaning up working directory '%s'\n" "$WORKDIR"
rm -rf "$WORKDIR"
}
trap cleanup EXIT
GPG() {
home=$1
shift
gpg --quiet --homedir "$WORKDIR/$home" --batch --pinentry-mode=loopback --passphrase='' --no-tty --status-file="$WORKDIR/status" "$@"
}
GPG a --quick-gen-key "Alice "
ALICE_FPR=$(grep KEY_CREATED "$WORKDIR/status" | cut -f4 -d\ )
GPG b --quick-gen-key "Bob "
BOB_FPR=$(grep KEY_CREATED "$WORKDIR/status" | cut -f4 -d\ )
GPG b --export "Bob " | GPG a --import
# Alice certifies Bob's certificate locally so that her GnuPG installation knows it is valid:
GPG a --quick-lsign-key "$BOB_FPR" "Bob "
cat > "$WORKDIR/mailscript.el" <" "this is a test")
(message-goto-body)
(insert "we need to see whether easypg can handle encryption (see https://dev.gnupg.org/T6481)")
(mml-secure-message-sign-encrypt)
(let ((mml-secure-openpgp-sign-with-sender t)
(message-send-mail-function (lambda () (write-region nil nil
Bug#1072299: Compositor-related crashes
On Fri, 2024 May 31 18:36-04:00, Andres Salomon wrote: > > I'm going from memory here, but I believe the dak installation on > security.debian.org doesn't keep dbgsym packages for historical reasons. > Thus, they're only available once chromium gets moved to > stable-proposed-updates. https://tracker.debian.org/pkg/chromium shows > .60 as being the last one in stable-p-u. At some point in the next week > or two, someone from the release team will likely accept the newer > chromium packages into stable-p-u, at which point the dbgsym packages > for .141 (or whatever the latest version is) will be available. Eeegh, not a great state of affairs for a package that revs this often. > It sucks, but it is what it is. You could either spend a bunch of time > building chromium for the dbgsym packages, or I could put my local build > of .141 online w/ dbgsym packages for you to try out (assuming amd64?), > or you could downgrade to .60 and use those dbgsym packages. If it's not too much trouble to put up that .141 package (and the problem still persists in that version), I'll gladly make use of it. > Yes, just running 'chromium -g' will launch it inside gdb; you may have > to manually type 'run' to start it inside gdb, I forget. But then > you'll get a backtrace (or you can ctrl-c and run 'bt', if it's a > deadlock or something). I haven't bothered w/ core dumps of chromium > before, so I can't speak to that. Understood. The system in question is a bit tight on memory, so hopefully it won't fall over with Chromium under GDB. --Daniel
Bug#1072317: Redundant build when making packed_resources
Package: chromium Version: 125.0.6422.141-1 Severity: minor This is something I've noticed in the course of the build that has been annoying me for some time, and I thought I'd write it up. Here is an excerpt from the build log which illustrates the problem: [...] [61738/61742] AR obj/content/web_test/libweb_test_renderer.a [61739/61742] AR obj/content/web_test/libweb_test_browser.a [61740/61742] AR obj/content/shell/libcontent_shell_app.a [61741/61742] LINK ./content_shell [61742/61742] LINK ./chrome cp out/Release/chrome out/Release/chromium cp out/Release/content_shell out/Release/chromium-shell [...] debian/rules override_dh_auto_build-indep make[1]: Entering directory '/tmp/chromium-125.0.6422.141' gn gen out/Release --args="clang_use_chrome_plugins=false ..." Done. Made 20173 targets from 3449 files in 10398ms ninja -j8 -C out/Release packed_resources ninja: Entering directory `out/Release' [1/30013] CXX obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/file_util_posix.o [2/30013] CXX obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/time_override.o [3/30013] CXX obj/base/allocator/partition_allocator/src/partition_alloc/allocator_base/stack_trace_linux.o [...] It's not clear why, but the "gn gen" operation in the override_dh_auto_build-indep target renders a significant chunk of the existing build tree stale, and the packed_resources build then has to recompile a bunch of things that are distant dependencies of the requested resource files. I can't say at what version this started happening, but I do seem to recall at one point the packed_resources build needing only a three- digit number of steps. Would it be reasonable to do something like override_dh_auto_build-indep: -gn gen out/Release --args="$(defines)" +test -f out/Release/build.ninja || gn gen out/Release --args="$(defines)" ninja -j$(njobs) -C out/Release packed_resources so that it doesn't run "gn gen" again, if not necessary? --Daniel
Bug#1072299: Compositor-related crashes
Sigh, spoke too soon. Chromium still crashes in both modes (tab and browser) even without Firefox running, but much less frequently. I had a good half-hour without crashes after closing Firefox, enough to lead me to think that was the cause. At this point, we're probably better off waiting to see if .141 still has the issue. But is there a reason why that -dbgsym package isn't there? --Daniel
Bug#1072299: Compositor-related crashes
I believe I've found a correlation: The crashes seem to have started with an instance of firefox-esr (115.11.0esr-1~deb12u1) that I was running on the side, since earlier today. Once I closed Firefox, the crashiness went away, completely. (This is on the same laptop that needs --use-gl=egl to avoid visual artifacts, so that might have something to do with this) On Fri, 2024 May 31 15:27-04:00, Andres Salomon wrote: > > Interesting. Any chance of a backtrace (with the chromium-dbgsym > package)? I'm wondering if some (bundled) third party lib has started > requiring newer cpu extensions or something. I'm happy to provide this, but two questions: 1. In http://debug.mirrors.debian.org/debian-debug/pool/main/c/chromium/ as well as https://deb.debian.org/debian-debug/pool/main/c/chromium/, I don't see any packages with a matching version string of "125.0.6422.112-1~deb12u1" (and .141 isn't there yet). Am I missing something? 2. To get the stack trace, is the right way just running the whole thing in GDB, using "chromium -g"? Or do you set it up to make a core dump? (Sure would be nice to have an Apport-like after-the-fact workflow for this) --Daniel
Bug#1072299: Compositor-related crashes
Package: chromium Version: 125.0.6422.112-1~deb12u1 Severity: important Recently, I have been observing crashes of individual tabs, and even of the entire browser, when navigating some Web pages. The crashed tabs correlate with the following syslog messages (multiple instances listed below): 2024-05-31T12:42:35.334876-04:00 runabout kernel: [1324259.940186] traps: Compositor[125485] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded490 error:0 in chromium[55a9c7e22000+b13d000] 2024-05-31T12:57:20.174268-04:00 runabout kernel: [1325144.782743] traps: Compositor[125761] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded1e0 error:0 in chromium[55a9c7e22000+b13d000] 2024-05-31T13:24:20.059327-04:00 runabout kernel: [1326764.664063] traps: Compositor[126515] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ed1e0 error:0 in chromium[55daa7faa000+b13d000] 2024-05-31T13:55:26.767783-04:00 runabout kernel: [1328631.258090] traps: Compositor[126307] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ecfb0 error:0 in chromium[55daa7faa000+b13d000] The whole-browser crash occurs with no unusual messages to syslog or ~/.xsession-errors, strangely enough. And even stranger, only today (May 31) have I started observing these crashes. This particular version has been installed and running fine since May 23, and now it's crashing left and right. /var/log/dpkg.log shows no new package installs since the 25th, and I haven't futzed with any configurations for at least that long. Since the error relates to an invalid opcode, I'll include some details about the CPU: vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping: 6 microcode : 0xc7 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow dtherm --Daniel
Bug#1072272: prosody-modules: please add mod_spam_reporting
Package: prosody-modules Version: 0.0~hg20240511.d3a72777f149+dfsg-1 Severity: wishlist Dear Maintainers, you have included mod_report_forward and mod_watch_spam_reports in prosody- modules which both depend on mod_spam_reporting but which isn't included in prosody-modules itself yet. So please include mod_spam_reporting as well :) Thank you and kind regards Daniel -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prosody-modules depends on: pn prosody Versions of packages prosody-modules recommends: pn lua-ldap prosody-modules suggests no packages.
Bug#1072248: bullseye-pu: package runc/1.0.0~rc93+ds1-5+deb11u4
. +- It was found that the fix for CVE-2021-30465 introduced a regression in + regards to CVE-2019-19921 which results in an incorrect access control + leading to privilege escalation and bypassing apparmor. + + -- Daniel Leidert Fri, 31 May 2024 00:39:22 +0200 + runc (1.0.0~rc93+ds1-5+deb11u3) bullseye-security; urgency=high * Team upload. diff -Nru runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml --- runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml 2024-02-02 16:14:13.0 +0100 +++ runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml 2024-05-31 00:39:22.0 +0200 @@ -1,37 +1,10 @@ --- -# https://docs.gitlab.com/ce/ci/yaml/#include include: - - remote: https://salsa.debian.org/onlyjob/ci/raw/master/onlyjob-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml -## "amd64-unstable" always runs by default followed by lintian. - -## Only for arch:all packages - remove if not required: -binary-indep: - extends: .build-indep - -## Job to check Build-Depends versioning: -amd64-testing_unstable: - extends: .build - variables: -arch: amd64 -dist: testing_unstable - -i386-unstable: - extends: .build - variables: -arch: i386 -dist: unstable - -amd64-experimental: - extends: .build - variables: -arch: amd64 -dist: experimental - -amd64-stable: - extends: .build - when: manual - allow_failure: true - variables: -arch: amd64 -dist: stable +variables: + RELEASE: 'bullseye' + SALSA_CI_COMPONENTS: 'main contrib non-free' + SALSA_CI_DISABLE_REPROTEST: 1 + SALSA_CI_DISABLE_LINTIAN: 1 diff -Nru runc-1.0.0~rc93+ds1/debian/patches/0025-Fix-busybox-tarball-url-in-integration-test.patch runc-1.0.0~rc93+ds1/debian/patches/0025-Fix-busybox-tarball-url-in-integration-test.patch --- runc-1.0.0~rc93+ds1/debian/patches/0025-Fix-busybox-tarball-url-in-integration-test.patch 2024-02-02 16:14:13.0 +0100 +++ runc-1.0.0~rc93+ds1/debian/patches/0025-Fix-busybox-tarball-url-in-integration-test.patch 2024-05-31 00:39:22.0 +0200 @@ -2,12 +2,15 @@ Date: Sat, 3 Feb 2024 00:02:52 +0800 Subject: Fix busybox tarball url in integration test +https://github.com/opencontainers/runc/blob/main/tests/integration/get-images.sh + +Reviewed-by: Daniel Leidert --- tests/integration/multi-arch.bash | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/integration/multi-arch.bash b/tests/integration/multi-arch.bash -index 1dd751b..91d2c1d 100644 +index 1dd751b..0e07a11 100644 --- a/tests/integration/multi-arch.bash +++ b/tests/integration/multi-arch.bash @@ -2,10 +2,10 @@ @@ -15,11 +18,11 @@ case $(go env GOARCH) in arm64) - echo 'https://github.com/docker-library/busybox/raw/dist-arm64v8/stable/glibc/busybox.tar.xz' -+ echo 'https://github.com/docker-library/busybox/raw/dist-arm64v8/latest/glibc/busybox.tar.xz' ++ echo 'https://github.com/docker-library/busybox/raw/94c664b5ca464546266bce54be0082874a44c7b2/stable/glibc/busybox.tar.xz' ;; *) - echo 'https://github.com/docker-library/busybox/raw/dist-amd64/stable/glibc/busybox.tar.xz' -+ echo 'https://github.com/docker-library/busybox/raw/dist-amd64/latest/glibc/busybox.tar.xz' ++ echo 'https://github.com/docker-library/busybox/raw/31d342ad033e27c18723a516a2274ab39547be27/stable/glibc/busybox.tar.xz' ;; esac } diff -Nru runc-1.0.0~rc93+ds1/debian/patches/0027-Fix-test-for-newer-kernels.patch runc-1.0.0~rc93+ds1/debian/patches/0027-Fix-test-for-newer-kernels.patch --- runc-1.0.0~rc93+ds1/debian/patches/0027-Fix-test-for-newer-kernels.patch 1970-01-01 01:00:00.0 +0100 +++ runc-1.0.0~rc93+ds1/debian/patches/0027-Fix-test-for-newer-kernels.patch 2024-05-31 00:39:22.0 +0200 @@ -0,0 +1,43 @@ +From: Kir Kolyshkin +Date: Tue, 29 Jun 2021 13:19:42 -0700 +Subject: [PATCH] tests/int/no_pivot: fix for new kernels + +The test is failing like this: + + not ok 70 runc run --no-pivot must not expose bare /proc + # (in test file tests/integration/no_pivot.bats, line 20) + # `[[ "$output" == *"mount: permission denied"* ]]' failed + # runc spec (status=0): + # + # runc run --no-pivot test_no_pivot (status=1): + # unshare: write error: Operation not permitted + +Apparently, a recent kernel commit db2e718a47984b9d prevents +root from doing unshare -r unless it has CAP_SETFPCAP. + +Add the capability for this specific test. + +Signed-off-by: Kir Kolyshkin + +Acked-by: Daniel Leidert +Origin: https://github.com/opencontainers/runc/commit/1bbeadae72603c44932d46ade275219dbf718950.patch +Forwarded: not-needed +--- + tests/integration/no_pivot.bats | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +
Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo, On Sat, May 25, 2024 at 07:30:46PM +0200, Samo Pogačnik wrote: > https://salsa.debian.org/spog/git-subrepo/-/commit/42628d43faa4a05eb3dd3c4b75d9d194ce6bda90 I'm not super happy with the approach of putting git-subrepo.d inside /usr/share/git-subrepo tbh. I might be able to let it pass but it seems lintian found another issue that needs patching anyway so you may as well fix this too. W: git-subrepo: bash-completion-with-hashbang bash [usr/share/bash-completion/completions/git-subrepo:1] W: git-subrepo: executable-not-elf-or-script [usr/share/git-subrepo/git-subrepo.d/bash+.bash] W: git-subrepo: mismatched-override executable-not-elf-or-script usr/lib/git-core/git-subrepo.d/bash+.bash [usr/share/lintian/overrides/git-subrepo:1] N: 0 hints overridden; 1 unused override indeed bash+.bash is +x but shouldn't be. I'm not sure whether bash-completion-with-hashbang should really be W severity but the '#!bash' it has is certainly completely wrong. Looks like you'll have to get over your fear of patching upstream ;) --Daniel signature.asc Description: PGP signature
Bug#1072104: shellinabox: Add ipv6 support
Package: shellinabox Version: 2.21+b2 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** please add support for ipv6 beside of ipv4. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages shellinabox depends on: ii adduser3.134 ii libc6 2.38-11 ii libpam0g 1.5.2-6+deb12u1 ii libssl3t64 [libssl3] 3.2.1-3 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 shellinabox recommends no packages. Versions of packages shellinabox suggests: ii openssl 3.2.1-3 -- Configuration Files: /etc/default/shellinabox changed: SHELLINABOX_DAEMON_START=1 SHELLINABOX_PORT=4200 SHELLINABOX_ARGS="--no-beep --disable-ssl" -- no debconf information
Bug#1071552: [pkg-gnupg-maint] Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG
Control: affects 1071552 + emacs-el Control: retitle 1071552 GnuPG 2.2.42+ breaks emacs' EasyPG On Tue 2024-05-21 13:05:02 +0900, Youhei SASAKI wrote: > Package: gnupg > Version: 2.2.43-6 > Severity: critical I see that Andreas has reduced the severity of 1071552 from 'critical' to 'important'. I think that the bugs we're seeing with easypg are pretty severe. I would personally mark this bug report "serious", because i think it is unfit to be merged into testing until the package can work correctly with EasyPG. > Current GnuPG package, version 2.2.43, brek Emacs's EasyPG. > We are no longer able to store encrypted files completely. > > Well-kown issue: > https://github.com/emacs-mirror/emacs/blob/master/etc/PROBLEMS > --- quote --- > *** Saving a file encrypted with GnuPG via EasyPG hangs. > > This is known to happen with GnuPG v2.4.1. The only known workaround > is to downgrade to a version of GnuPG older than 2.4.1, or upgrade to > version 2.4.4 and newer, which reportedly solves the problem. Note > that GnuPG v2.2.42 and later also has this problem, so you should also > avoid those later 2.2.4x versions; v2.2.41 is reported to work fine. > --- quote --- > > See also https://dev.gnupg.org/T6481 > > Please upgrade GnuPG >= 2.4.4 or newer. I don't think this is a reasonable solution as of how the 2.4.x branch is designed right now, and the fact that upstream doesn't appear to intend the 2.4.x series as a long-term support series either. My understanding is that the upstream 2.4.x packages of GnuPG (which are visible in experimental today) introduce potentially serious incompatibilities into the OpenPGP ecosystem, and i don't think it's reasonable for debian to ship those versions until they are producing things that are compatible with most other OpenPGP implementations. Sadly, GnuPG upstream appears to be abandoning the OpenPGP standard, and despite reasonable attempts to convince them to interoperate, i don't see that changing. Would anyone be willing to try to backport the patches from upstream's fixes for T6481 to the 2.2.x series? --dkg signature.asc Description: PGP signature
Bug#1071787: libgnupg-interface-perl: GnuPG::Interface fails with GnuPG version 2.2.42 and higher in the 2.2.x line
Package: libgnupg-interface-perl
Version: 1.04-1
Severity: important
X-Debbugs-Cc: Daniel Kahn Gillmor
Control: forwarded -1 https://github.com/bestpractical/gnupg-interface/pull/14
Control: tags -1 + patch
Control: affects -1 + src:gnupg2
The GnuPG::Interface test suite fails with GnuPG 2.2.43 (currently in
unstable). This appears to be because of GnuPG upstream backporting
support something called the RENC key usage flag, which i confess i
still don't really understand, though it is also associated with "ADSK".
See https://dev.gnupg.org/rGe4f61df8509e7aff0628971d9ea8fe967cd0f416 for
some kind of hints from upstream about what this is about.
The attached patch should fix the brittle test suite to accept yet
another variation in GnuPG's output, which the module attempts to parse
or at least compare.
--dkg
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)
Versions of packages libgnupg-interface-perl depends on:
ii gnupg 2.2.43-6
ii gnupg1 1.4.23-2
ii libmath-bigint-perl 2.003002-1
ii libmoo-perl 2.005005-1
ii libmoox-handlesvia-perl 0.001009-2
ii libmoox-late-perl 0.100-2
ii perl [libmath-bigint-perl] 5.38.2-4
libgnupg-interface-perl recommends no packages.
libgnupg-interface-perl suggests no packages.
-- no debconf information
From c64b499e627b74c76197b4682eb183c648622b4b Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Fri, 24 May 2024 17:07:49 -0400
Subject: [PATCH 1/1] Handle versions of GnuPG 2.2.x that report the RENC key
usage flag
GnuPG Upstream has apparently backported work on the putative "RENC"
flag to the 2.2.x branch, i think as of 2.2.42.
This means that the output of key listings that have this flag set
will change. That breaks the fairly britle parser we have here.
---
t/MyTestSpecific.pm | 12
t/get_public_keys.t | 2 +-
t/get_secret_keys.t | 2 +-
t/list_secret_keys.t | 6 +++---
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/t/MyTestSpecific.pm b/t/MyTestSpecific.pm
index 67af078..2b7c91c 100644
--- a/t/MyTestSpecific.pm
+++ b/t/MyTestSpecific.pm
@@ -167,4 +167,16 @@ sub get_expired_test_sig_params {
return %sig_params
}
+# determine whether this GnuPG version reports on the "RENC" key usage
+# flag, which was added in 2.3.8 and 2.2.42 (see upstream
+# e4f61df8509e7aff0628971d9ea8fe967cd0f416)
+sub get_supported_renc {
+ my $gnupg = shift;
+ my $version = $gnupg->version;
+
+ return (($gnupg->cmp_version($version, '2.3.8') >= 0) ||
+ (($gnupg->cmp_version($version, '2.3') < 0) &&
+ ($gnupg->cmp_version($version, '2.2.42') >= 0)));
+}
+
1;
diff --git a/t/get_public_keys.t b/t/get_public_keys.t
index 8d8eebf..9d56a67 100644
--- a/t/get_public_keys.t
+++ b/t/get_public_keys.t
@@ -181,7 +181,7 @@ TEST
hex_id => 'ADB99D9C2E854A6B',
creation_date=> 949813119,
creation_date_string => '2000-02-06',
-usage_flags => $gnupg->cmp_version($gnupg->version, '2.3.8') >= 0 ? 'er' : 'e',
+usage_flags => get_supported_renc($gnupg) ? 'er' : 'e',
pubkey_data => $subkey_pub_data,
);
diff --git a/t/get_secret_keys.t b/t/get_secret_keys.t
index 5fc2a57..1d8e583 100644
--- a/t/get_secret_keys.t
+++ b/t/get_secret_keys.t
@@ -87,7 +87,7 @@ TEST
hex_id => 'ADB99D9C2E854A6B',
creation_date=> 949813119,
creation_date_string => '2000-02-06',
-usage_flags => $gnupg->cmp_version($gnupg->version, '2.3.8') >= 0 ? 'er' : 'e',
+usage_flags => get_supported_renc($gnupg) ? 'er' : 'e',
pubkey_data => $subkey_pub_data,
};
diff --git a/t/list_secret_keys.t b/t/list_secret_keys.t
index 44af61f..dcd0b97 100644
--- a/t/list_secret_keys.t
+++ b/t/list_secret_keys.t
@@ -51,11 +51,11 @@ TEST
elsif ( $gnupg->cmp_version( $gnupg->version, '2.1.11' ) <= 0 ) {
$keylist = '1';
}
-elsif ( $gnupg->cmp_version( $gnupg->version, '2.3.8' ) < 0 ) {
-$keylist = '2.2';
+elsif ( get_supported_renc( $gnupg ) ) {
+$keylist = '2';
}
else {
-$keylist = '2';
+$keylist = '2.2';
}
--
2.43.0
signature.asc
Description: PGP signature
Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean
On Sun 2024-05-19 20:43:58 +0200, Guido Günther wrote: > But you'd break that when filtering out files? I think what keeps me > confused: the tarball uploaded to Debian is the filtered one and hence > has a different checksum, no? hm, i don't think so, because we use import-orig.filter-pristine-tar=False. This lets me preserve both the upstream signature and the git history, and to compare the upstream tarball with the git tag using git as well. In the gnupg2 package, we currently have this in debian/gbp.conf: - [DEFAULT] debian-branch = debian/unstable upstream-branch = upstream-2.2 pristine-tar = True upstream-vcs-tag = gnupg-%(version)s [import-orig] filter = [ 'aclocal.m4', 'build-aux/compile', 'build-aux/config.rpath', 'build-aux/depcomp', 'build-aux/install-sh', 'build-aux/missing', 'build-aux/mkinstalldirs', 'build-aux/texinfo.tex', 'ChangeLog', 'config.h.in', 'configure', 'doc/gnupg.info*', 'doc/*.pdf', 'doc/*.png', 'INSTALL', 'm4/iconv.m4', 'm4/intdiv0.m4', 'm4/intl.m4', 'm4/lock.m4', 'm4/printf-posix.m4', 'm4/size_max.m4', 'm4/uintmax_t.m4', 'm4/wint_t.m4', '*/*/Makefile.in', '*/Makefile.in', 'Makefile.in', 'po/*.gmo', 'po/Makefile.in.in', 'po/stamp-po', 'regexp/_unicode_mapping.c', 'regexp/UnicodeData.txt', 'common/audit-events.h', 'common/status-codes.h', 'ChangeLog-2011', '*/ChangeLog-2011', 'tests/*/ChangeLog-2011', ] filter-pristine-tar = False - So what i'm asking is to be able replace that big import-orig.filter array with something that knows how we do cleaning, so that when i improve our cleaning, it improves the filter for the next import as well. > It would also have the upside that packages invoking `dh_clean … path1 > path2` would still work. > > Another reason to not parse debian/clean verbatim is that we'd also need > to support dh's substitution variables and would forever need to follow > what dh does (and we might even need to pay attention to the dh compat > level of the package) as otherwise things would break on people. you've convinced me that running the clean target is better than trying to parse debian/clean :) >> whether the packaging used debhelper or not. Does that seem like a >> plausible way to operate gbp import-orig? > > That would be an approach. Implementation wise the "tricky" bit is > that you don't have debian/ on the upstream branch you want to filter so > dh_clean or `debian/rules clean` won't work as is . So we'd need to > overlay that (which is certainly doable, just wanted to point it out). ah, yes, i see the complication here. > So that's a lot of effort for s.th. that can already be done via either > gbp.conf or FilesExcluded. I'm not against it, just looking at the pros > and cons. right, i see tradeoff you're describing, and if you decide this is too much complication for gbp, i'm willing to just keep the two lists (debian/clean and debian/gbp.conf's import-orig.filter) in sync more or less manually. But i thought it wouldn't hurt to ask -- it'd certainly be nice for anyone working on the GnuPG packaging (or any other packaging which covers a similar upstream) to have a simpler packaging maintenance workflow. Thanks for thinking this all through with me here, Guido! --dkg signature.asc Description: PGP signature
Bug#1071202: [pkg-gnupg-maint] Bug#1071202: src:gnupg2: upstream tarball ships files not in upstream revision control
Hi gniibe-- Thanks for this additional info! On Fri 2024-05-17 09:02:40 +0900, NIIBE Yutaka wrote: > The regexp subdirectory was introduced to support POSIX regexp functions > on Windows. The intention is providing same behavior among GnuPG on > different Operating Systems. Historically, regexp in OpenPGP had been > not supported by Windows versions of GnuPG; In the past, when a user > switched his Operating System from common POSIX one to Windows, it > stopped working. > > If it is only for Debian, possibly, we can simply use POSIX regexp > functions in the C library, perhaps. If GnuPG doesn't use this regexp dir when building on Debian, that sounds fine to me :) Then we definitely don't need to use or ship that mapping file! > There are corner cases for regexp matching among different regexp > functions support and Unicode versions. yes, the regexp support in the standard is ill-specified in a lot of ways, and most implementations struggle to implement it properly, for all kinds of reasons. We don't have good interop tests for it yet because we haven't extended sop into certificate management. I should probably try to get that under way. :/ > Strictly speaking about a data specification, it would be more acculate > to specify exact Unicode version explicitly in the OpenPGP standard. Unicode is supposed to evolve in a stable and sane way. I think tying OpenPGP to a specific version of Unicode would be a mistake; it's hard enough to upgrade OpenPGP as it is, without having to coordinate across versions of unicode in the first place. --dkg signature.asc Description: PGP signature
Bug#1071556: Acknowledgement (Dvorak keymap not loaded after login)
I've reported this issue to the upstream project at https://github.com/neutrinolabs/xrdp/issues/3081 Ubuntu's version 0.9.24-4 in 24.04/noble is likewise affected.
Bug#1071556: Dvorak keymap not loaded after login
Package: xrdp Version: 0.9.24-5 Severity: important Recently, I have noticed that logging in via a recent version of xrdp, while using the Dvorak layout on the client, yields a QWERTY layout in the remote framebuffer after getting past the login dialog. This is incorrect behavior and has never happened before. After some digging, I tracked the problem down to this: https://bugs.debian.org/1063725 It is no longer possible to refer to the Dvorak layout as just "dvorak" (as when one would run "setxkbmap dvorak"); one must now use either "us dvorak" or "us(dvorak)". The below edit fixes the issue and allows me the proper keymap after logging in: --- /etc/xrdp/xrdp_keyboard.ini.orig +++ /etc/xrdp/xrdp_keyboard.ini @@ -86,7 +86,7 @@ ; = [default_layouts_map] rdp_layout_us=us -rdp_layout_us_dvorak=dvorak +rdp_layout_us_dvorak=us(dvorak) rdp_layout_us_dvp=us(dvp) rdp_layout_dk=dk rdp_layout_de=de @@ -125,7 +125,7 @@ [rdp_layouts_map_mac] rdp_layout_us=us -rdp_layout_us_dvorak=dvorak +rdp_layout_us_dvorak=us(dvorak) rdp_layout_us_dvp=us(dvp) rdp_layout_dk=dk rdp_layout_de=de --Daniel
Bug#1064040: [pkg-gnupg-maint] Bug#1064040: src:gnupg2: Please remove Recommends: gnupg from all binary packages
Hi Julian-- On Fri 2024-02-16 10:42:35 +0100, Julian Andres Klode wrote: > gnupg is a big meta package pulling in all sorts of weird stuff > people don't want by default on their machine, like a wks server. I agree with this generally, but upstream seems to generally want all packages available in a standard installation, and hasn't committed to clear boundaries about what things will fail when certain subpieces are missing. See for example discussion in #873499 The explicit Recommends is trying to encourage behavior that aligns with upstream's wishes. > That wks server in experimental now pulls in a mail transport > agent. Andreas resolved this by moving gpg-wks-server to a Suggests from a Recommends. > 1. gnupg should move to the metapackages section This is a good idea, i've moved it there in git, and it should be included in the next upload. > 2. All Recommends on gnupg should be removed, we don't want that >installed by default. > 3. gpg should Recommends keyboxd and dirmngr as they will frequently be >needed when using gpg > > And then we should clean up all reverse dependencies to say gpg. I'm reluctant to do these parts for the above reasons. > I think I plan to do this in Ubuntu. The alternative would be > to demote all non-interesting gnupg dependencies to suggests, > those would be: > > - gnupg-utils > - gpg-wks-server > - gpgv [stuff will depend on that anyway if it needs it, like apt does] > - maybe gpg-wks-client As mentioned above, gpg-wks-server is already in Suggests (thanks, Andreas!) I'm moving the remaining three packages from the above list to Recommends: (instead of Depends:) for the gnupg package. > This may make the gnupg package *actually useful* rather than > be a pointless metapackage that nobody actually wants to install. I don't know how to strike a happy balance between what most users want (something minimal, to not have to think about OpenPGP at all, and have it just work silently in the background) and what upstream seems to want (a complicated interconnected system with lots of subtle configurability). --dkg signature.asc Description: PGP signature
Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean
Hi Guido-- On Thu 2024-05-16 08:39:27 +0200, Guido Günther wrote: > Great! This matches my preferred way too. ☺ Thanks for walking through the options here with me! > Wouldn't d/copyright's `Files-Excluded:` work here too? I'm using that > for similar purposes as it even allows to use `gbp import-orig --uscan` > and have things filtered out. `debian/clean` could parse the pattern from > there. Hm, I don't know what the semantics are for Files-Excluded, or what other side effects they have. The documentation for the machine-readable copyright format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ doesn't even include the word "Excluded", let alone "Files-Excluded" (see #685506, sigh). According to https://wiki.debian.org/UscanEnhancements#Deleting_Files_using_Files-Excluded_field_in_debian.2Fcopyright the Files-Excluded field actually affects the tarball by causing uscan to re-pack it without those files. Doing the tarball re-packing would mean breaking the upstream tarball's cryptographic signature, so i'm not sure i want to do that. The goal here is to increase attributability and provenance, and breaking the upstream cryptographic signature seems to work against that goal. > What if you'd read the filter list in the `clean` target? Hm, while i depend on gbp for my regular packaging workflow, one of the things i like about it is how it wraps itself around other packaging workflows. If i remove debian/gbp.conf from my package's source, the source can still build just fine using dpkg-buildpackage or debuild. I'd like to keep that property. > I think what you propose is doing it the other way around: Have gbp > run `debian/rules clean` to have a programatical way of filtering? right, that would do the job, and is probably the more principled way to do it than merely parsing debian/clean. It would work regardless of whether the packaging used debhelper or not. Does that seem like a plausible way to operate gbp import-orig? --dkg signature.asc Description: PGP signature
Bug#1071202: src:gnupg2: upstream tarball ships files not in upstream revision control
Source: gnupg2
Severity: minor
X-Debbugs-Cc: Daniel Kahn Gillmor
The gnupg2 package is built from source based on the upstream released
tarball. Upstream also uses git for revision control, and we track
upstream git as well as the released tarballs. upstream uses OpenPGP to
sign both git tags and released tarballs.
We trim many prebuilt files from the tarball, so what's in our debian
packaging repositories are pretty close to upstream's git repos. But
not quite all of them.
Inspired by the recent xz mess, where malicious files were slipped into
a tarball, i'd like to minimize the amount of non-tracked source used in
GnuPG. I think we should use debian/clean (and gbp import-orig's
filtering, see #1071200) to trim out all of the generated files before
build, so that what we're building from source is as close to upstream
traceable git commits as possible.
I did a quick scan of what we're shipping in revision control (hence,
what's in the filtered tarball) that the upstream git tag isn't
accounting for. Here's what i found:
$ git diff --stat gnupg-2.2.43..upstream/2.2.43 | grep -e '\+' -e 'Bin 0 ->'
ChangeLog | 34710 ++-
VERSION| 1 +
common/audit-events.h | 116 +
common/status-codes.h | 248 +
doc/defsincdate| 1 +
doc/gnupg-card-architecture.pdf| Bin 0 -> 19221 bytes
doc/gnupg-card-architecture.png| Bin 0 -> 8843 bytes
doc/gnupg-module-overview.pdf | 408 +
doc/gnupg-module-overview.png | Bin 0 -> 124560 bytes
po/ca.po | 2295 +-
po/cs.po | 2303 +-
po/da.po | 2299 +-
po/de.po | 2310 +-
po/el.po | 2295 +-
po/e...@boldquot.po | 10967 ++
po/e...@quot.po | 10951 ++
po/eo.po | 2295 +-
po/es.po | 2307 +-
po/et.po | 2299 +-
po/fi.po | 2295 +-
po/fr.po | 2299 +-
po/gl.po | 2303 +-
po/gnupg2.pot | 10636 ++
po/hu.po | 2295 +-
po/id.po | 2295 +-
po/it.po | 2295 +-
po/ja.po | 2295 +-
po/nb.po | 2295 +-
po/pl.po | 2295 +-
po/pt.po | 2295 +-
po/ro.po | 2307 +-
po/ru.po | 2303 +-
po/sk.po | 2303 +-
po/sv.po | 2299 +-
po/tr.po | 2295 +-
po/uk.po | 2299 +-
po/zh_CN.po| 2295 +-
po/zh_TW.po| 2291 +-
regexp/_unicode_mapping.c | 284 +
242 files changed, 127919 insertions(+), 42329 deletions(-)
$
the doc/*.{pdf,png} stuff is fixed already, as of 2.2.43-3, and will be
filtered out whenever we move to the next upstream release.
Here's my attempt at analyzing what remains:
ChangeLog: this is generated automatically by upstream from upstream git
history, and we ship it (half a meg after compression!) in all the
produced packages. This seems like a lot, and we ought to be able to
drop it from nearly everywhere. what if we just shipped it with
gnupg2-doc, and left the other packages with a simple text file? or
What if we just stopped shipping it altogether? will anyone mind?
The details are at developer-level, and it'll still be in the source
tarballs if anyone wants to read the file.
VERSION: this contains only the upstream version number. Can we
generate it manually from debian/changelog?
doc/defsincdate: this file is generated upstream, and can potentially
introduce non-reproducibility (see
debian/patches/debian-packaging/avoid-regenerating-defsincdate-use-shipped-file.patch
for more discussion). If we strip that file, and drop the above patch
(or tune it so that it only works with $SOURCE_DATE_EPOCH) then we
should be able to avoid unreproducibility. Doing so would mean that
generated documentation files would have the timestamp of t
Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean
Package: git-buildpackage Version: 0.9.33 Severity: wishlist X-Debbugs-Cc: Daniel Kahn Gillmor , Andreas Metzler Control: affects -1 src:gnupg2 I'd like to have "git import-orig" filter out all the files that are listed in debian/clean, without having to keep the lists synchronized. That way, if i notice that the upstream tarball is injecting some sort of additional pre-built artifact into the tarball, i can keep it out of our revision control *and* ensure that it gets rebuilt during a build from source. (This is motivated by discussion with Andreas Metzler about building GnuPG documentation artwork artifacts, see https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2024-May/009340.html , and of course also by the recent xz incident, where malware was expressed the tarball that had not been committed to revision control) background: i prefer debian packaging linked to the upstream revision control, but also being able to tie our work to formally released tarballs, if the upstream project ships them. I'm relying on gbp import-orig with an appropriately configured debian/gbp.conf to import cryptographically signed upstream tarball releases while pointing back to upstream's revision control tags. One example workflow that i would like to be able to have easily at my disposal as a maintainer is to tell that things are in the tarball that are *not* in the upstream revision control system (the other direction: looking for things in upstream revision control that didn't get shipped in the tarball, is interesting, but a separate question). After having verified the cryptographic signatures of the upstream tarball, and the upstream release tag, and doing "gbp import-orig", it's nice to be able to do (for example): git diff --stat gnupg-2.2.43..upstream/2.2.43 This helps me identify artifacts that we should probably be re-building from source. By including these generated artifacts in debian/clean, i can ensure that during the standard debian build process, they will be necessarily re-generated (because we run "debian/rules clean" before building). But if i'm including them in debian/clean, then there's no point in keeping them in the git packaging directory either. and i would prefer to avoid synchronizing debian/clean and debian/gbp.conf's import-orig.filter list. --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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) Versions of packages git-buildpackage depends on: ii devscripts 2.23.7 ii git1:2.43.0-1+b1 ii man-db 2.12.1-1 ii python33.11.8-1 ii python3-dateutil 2.9.0-2 ii python3-pkg-resources 68.1.2-2 ii python3-yaml 6.0.1-2 ii sensible-utils 0.0.22 Versions of packages git-buildpackage recommends: pn cowbuilder | pbuilder | sbuild ii pristine-tar1.50+nmu2 ii python3-requests2.31.0+dfsg-1 Versions of packages git-buildpackage suggests: pn python3-notify2 pn sudo ii unzip6.0-28 -- no debconf information signature.asc Description: PGP signature
Bug#1070688: [pkg-gnupg-maint] Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Hi Farblos-- On Tue 2024-05-14 21:28:05 +0200, Farblos wrote: > Should I open another issue about PINENTRY_USER_DATA not being > forwarded to the pinentry when using the gpg from package gpg-sq/ > gpg-from-sq? If yes, on what repository exactly? I would report it at https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg -- the more you can explain your specific setup, and reference the gpg documentation (perhaps the "environment variables" subsection of the FILES section of gpg(1)?) to justify the behavior would probably help sequoia figure out what needs fixing for your scenario. > gpg-from-sq indeed was on my system, and I think it got there because > of some of aptitude's proposals to resolve broken references. Thanks for including the apt logs. I'm still not sure how to replicate this change. It looks like some part of gpg was explicitly "held" by apt? and the other packages involved during this upgrade run (libdv4t64, libnetpbm11t64, libopencore-amrnb0, libopencore-amrwb0, gstreamer1.0-plugins-good, netpbm) don't seem related to GnuPG at all. And, gpgv itself somehow wasn't held? Curious! but i still don't really understand what happened here, unfortunately ☹ If anyone else has any insights or can suggest other things that Farblos could report, i'd welcome other suggestions. --dkg signature.asc Description: PGP signature
Bug#1070867: lists.debian.org: debconf25-team
Why don't you just use debconf-team? You are welcome to discuss there.
Bug#1070871: thunderbird: please use system librnp
Package: thunderbird Version: 1:115.10.1-1 Severity: normal X-Debbugs-Cc: Daniel Kahn Gillmor Thunderbird was (understandably) using an internal copy of librnp because upstream hadn't releasd a version with `rnp_signature_get_features` Now that 0.17.1-1 is in debian/unstable, please rebuild thunderbird to use the system version of librnp. thanks! --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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) Versions of packages thunderbird depends on: ii debianutils 5.17 ii fontconfig 2.15.0-1.1 ii libasound2t641.2.11-1+b1 ii libatk1.0-0t64 2.52.0-1 ii libc62.38-7 ii libcairo-gobject21.18.0-3+b1 ii libcairo21.18.0-3+b1 ii libdbus-1-3 1.14.10-4+b1 ii libdbus-glib-1-2 0.112-3+b2 ii libevent-2.1-7t642.1.12-stable-8.1+b3 ii libffi8 3.4.6-1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b4 ii libgcc-s114-20240330-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3 ii libglib2.0-0t64 2.80.1-1 ii libgtk-3-0t643.24.41-4 ii libnspr4 2:4.35-1.1+b1 ii libnss3 2:3.99-1 ii libotr5t64 4.1.1-5.1 ii libpango-1.0-0 1.52.2+ds-1 ii libstdc++6 14-20240330-1 ii libvpx8 1.13.1-2+b1 ii libx11-6 2:1.8.7-1+b1 ii libx11-xcb1 2:1.8.7-1+b1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxext6 2:1.3.4-1+b1 ii libxrandr2 2:1.5.4-1 ii psmisc 23.7-1 ii x11-utils7.7+6+b1 ii zenity 4.0.1-1+b1 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages thunderbird recommends: pn myspell-en-us | hunspell-dictionary | myspell-dictionary Versions of packages thunderbird suggests: pn apparmor ii fonts-lyx 2.4.0~RC4-1 ii libgssapi-krb5-2 1.20.1-6+b1 -- no debconf information signature.asc Description: PGP signature
Bug#1070870: loook: typo in package description: "formsm" - correct to "forms"
Package: loook Version: 0.9.0-1 Severity: minor Dear Maintainer, as a member of the translation team for Brazil I found a typo in the project description - "formsm" instead of forms. Please correct. Typo is present in versions loook (0.8.6-1), loook (0.8.6-2), loook (0.9.0-1) -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-28-generic (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages loook depends on: ii python3 3.10.6-1~22.04 ii python3-tk 3.10.8-1~22.04 Versions of packages loook recommends: pn libreoffice | calligra loook suggests no packages.
Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries
Control: tags 1069908 - moreinfo Hi Xiyue Deng-- On Wed 2024-05-08 19:13:37 -0700, Xiyue Deng wrote: > For this issue, it looks like debian-bug.el is passing "--list-cc=none" > to reportbug which then becomes part of the message. This is fixed in > [1] and pending sponsoring. thanks for this analysis and work! > I cannot seem to reproduce this. debian-bug.el tries to get full name > and email from several sources, such as user-full-name, > user-mail-address, envvars like DEBFULLNAME, DEBNAME, NAME, DEBEMAIL, > EMAIL, REPORTBUGEMAIL, etc. So there may be something unconventional > that triggered this. Can you check if your configuration set those info > in multiple places? What happens if you clear some of them? Here are the plausibly relevant env vars i have set (generated by running `M-1 M-! printenv` from within emacs itself and then manually pruning for things that include either my name or e-mail address): ``` DEBFULLNAME=Daniel Kahn Gillmor DEBEMAIL=d...@fifthhorseman.net DEBSIGN_MAINT=Daniel Kahn Gillmor EMAIL=d...@fifthhorseman.net ``` None of this seems wrong to me; or even if it does, it still ought to be able to be correctly interpreted by debian-bug.el, and de-duplicated. I decided to look in ~/.reportbugrc and i find i have the following settings: ``` reportbug_version "5.0" mode standard ui text no-cc list-cc-me ``` I have no recollection of setting either no-cc or list-cc-me, and i confess i don't really understand why these options are distinct. Perhaps this was from ancient run (or runs?) of `reportbug --configure`? Without modifying any env vars, I tried commenting out both the `no-cc` and `list-cc-me` options in ~/.reportbugrc, and with both of those removed, the generated X-Debbugs-Cc line after a `M-x debian-bug` was just: ``` X-Debbugs-Cc: none, Daniel Kahn Gillmor ``` So perhaps with the fix you have pending, this will be resolved. Thanks! --dkg signature.asc Description: PGP signature
Bug#1070866: gpg-from-sq: gpg-from-sq makes the rnp test suite fail
Package: gpg-from-sq
Version: 0.8.0-5
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor
Control: affects -1 + src:rnp
With gpg-from-sq installed, trying to build rnp 0.17.1-1 results in
these test failures:
---
96% tests passed, 10 tests failed out of 263
Total Test time (real) = 273.53 sec
The following tests FAILED:
254 - cli_tests-SignDefault (Failed)
255 - cli_tests-Encryption (Failed)
256 - cli_tests-SignDSA (Failed)
257 - cli_tests-EncryptElgamal (Failed)
258 - cli_tests-Keystore (Failed)
259 - cli_tests-Misc (Failed)
260 - cli_tests-SignECDSA (Failed)
261 - cli_tests-EncryptEcdh (Failed)
262 - cli_tests-Compression (Failed)
263 - cli_tests-EncryptSignRSA (Failed)
Errors while running CTest
---
Below is example output from the failure of test 260:
-
test 260
Start 260: cli_tests-SignECDSA
260: Test command: /usr/bin/python3
"/home/dkg/src/rnp/rnp/src/tests/cli_tests.py" "-v" "-d" "SignECDSA"
260: Working Directory: /home/dkg/src/rnp/rnp/build/src/tests
260: Environment variables:
260: RNP_TESTS_RNP_PATH=/home/dkg/src/rnp/rnp/build/src/rnp/rnp
260: RNP_TESTS_RNPKEYS_PATH=/home/dkg/src/rnp/rnp/build/src/rnpkeys/rnpkeys
260: RNP_TESTS_GPG_PATH=/usr/bin/gpg
260: RNP_TESTS_GPGCONF_PATH=/usr/bin/gpgconf
260: Test timeout computed to be: 3000
260: Running in /tmp/rnpctmpt95qw7bx
260: /usr/bin/gpg --version
260:
260: gpg (GnuPG-compatible Sequoia Chameleon) 2.2.40
260: Sequoia gpg Chameleon 0.8.0
260: sequoia-openpgp 1.20.0
260: Copyright (C) 2024 Sequoia PGP
260: License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
260: This is free software: you are free to change and redistribute it.
260: There is NO WARRANTY, to the extent permitted by law.
260:
260: Home: /home/dkg/src/rnp/rnp/debian/.debhelper/generated/_source/home/.gnupg
260: Supported algorithms:
260: Pubkey: RSA, DSA, ECDH, ECDSA, EDDSA
260: Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
260: CAMELLIA128, CAMELLIA192, CAMELLIA256
260: Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
260: Compression: Uncompressed, ZIP, ZLIB, BZIP2
260: Failed to parse GnuPG version.
260: Traceback (most recent call last):
260: File "/home/dkg/src/rnp/rnp/src/tests/cli_tests.py", line 5076, in
260: setup(LVL)
260: File "/home/dkg/src/rnp/rnp/src/tests/cli_tests.py", line 927, in setup
260: gpg_check_features()
260: File "/home/dkg/src/rnp/rnp/src/tests/cli_tests.py", line 845, in
gpg_check_features
260: raise_err('Failed to parse GnuPG version.')
260: File "/home/dkg/src/rnp/rnp/src/tests/cli_common.py", line 39, in
raise_err
260: raise CLIError(msg, log)
260: ^^
260: File "/home/dkg/src/rnp/rnp/src/tests/cli_common.py", line 20, in
__init__
260: logging.debug(self.log.strip())
260: ^^
260: AttributeError: 'NoneType' object has no attribute 'strip'
---
--dkg
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)
Versions of packages gpg-from-sq depends on:
ii gpg-sq 0.8.0-5
gpg-from-sq recommends no packages.
gpg-from-sq suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#1070688: [pkg-gnupg-maint] Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Control: affects 1070688 + gpg-from-sq apt
Hi Farblos, all--
Thanks for this detailed bug report (https://bugs.debian.org/1070688).
I'm a bit confused about the following:
On Wed 2024-05-08 11:07:28 +0200, Farblos wrote:
> Never mind. During one of the last t64 upgrade orgies package gpg-sq got
> installed on my system and succeeded to install the diversion to /usr/bin/gpg.
> And the sequoia replacement is not very feature complete, as they continue
> to stress themselfes.
gpg-sq doesn't install any diversions to my knowledge. the only
diversions that might be installed are in gpg-from-sq or gpgv-from-sq.
If those packages were on your system, then they could indeed have
installed a diversion. But nothing explicitly depends on those packages
(try running "apt rdepends gpg{,v}-from-sq") so i'm not sure how they
got installed during an upgrade.
Perhaps it has something to do with the fact that the packages use the
Provides field? If you didn't deliberately install either of the
*-from-sq packages, and they ended up on your system, is there some way
that you can replicate the upgrade path? I'd like to understand that
better, as i don't think it should have happened by accident.
Perhaps there is some signal either package can give to apt to help it
avoid that problem in the future?
> For example, referencing a recipient by exact name with "="
> does not work in gpg-sq, either.
Thanks, i've reported this part upstream:
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/74
--dkg
signature.asc
Description: PGP signature
