Bug#1007764: gcc-defaults: please support DPKG_ROOT
Hi, On Wed, 17 Aug 2022 18:20:36 +0200 Johannes Schauer Marin Rodrigues wrote: > On Wed, 16 Mar 2022 13:30:26 +0100 Johannes Schauer Marin Rodrigues > wrote: > > when creating chroots for new architectures that are in the process of being > > bootstrapped without yet having emulation support from qemu, it is not > > possible to run maintainer scripts inside the foreign architecture chroot > > because foreign architecture ELF binaries cannot be executed. The solution > > to > > that problem is to run maintainer scripts from outside the chroot and use > > the > > DPKG_ROOT environment variable to instruct the maintainer script on which > > chroot to operate. By default, for normal installations, that environment > > variable is set, but empty. > > > > Apart from init-system-helpers and pam, all packages in the > > Essential:yes set have support for DPKG_ROOT already. To start building > > packages we also need to install build-essential. > > > > Please consider applying the patch from this merge request: > > > > https://salsa.debian.org/toolchain-team/gcc-defaults/-/merge_requests/4 > > > > We tested it in our CI environment and it produces a bit-by-bit > > identical chroot with DPKG_ROOT compared to a normal installation. > > > > https://salsa.debian.org/helmutg/dpkg-root-demo/ > > > > Since the DPKG_ROOT variable is empty on normal installations, the patch > > should have no effect in the normal case. > > I wanted to send a friendly ping about this bug. I see that since I filed this > bug, you uploaded three new versions of gcc-defaults. Please consider applying > the changes of above merge request against gcc-defaults on salsa. Here is the > diff in plain text for your convenience: > > --- a/debian/g++.postinst.in > +++ b/debian/g++.postinst.in > @@ -2,9 +2,9 @@ > > # remove the doc dir, if it's still a directory and replace with a symlink > pkg=`basename $0 .postinst` > -if [ ! -L /usr/share/doc/$pkg ]; then > -rm -rf /usr/share/doc/$pkg > -ln -s cpp /usr/share/doc/$pkg > +if [ ! -L "$DPKG_ROOT/usr/share/doc/$pkg" ]; then > +rm -rf "$DPKG_ROOT/usr/share/doc/$pkg" > +ln -s cpp "$DPKG_ROOT/usr/share/doc/$pkg" > fi > > # fix for report #138038: remove old diversions I uploaded an NMU of gcc-defaults with the maximum delay of 15 days. Please cancel if you disagree. Full debdiff attached. Thanks! cheers, joschdiff -Nru gcc-defaults-1.200/debian/changelog gcc-defaults-1.200+nmu1/debian/changelog --- gcc-defaults-1.200/debian/changelog 2022-07-22 17:31:39.0 +0200 +++ gcc-defaults-1.200+nmu1/debian/changelog 2022-08-28 08:23:21.0 +0200 @@ -1,3 +1,10 @@ +gcc-defaults (1.200+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Support DPKG_ROOT in g++ postinst (closes: #1007764) + + -- Johannes Schauer Marin Rodrigues Sun, 28 Aug 2022 08:23:21 +0200 + gcc-defaults (1.200) unstable; urgency=medium * Stop building gccbrig, removed in GCC 12. diff -Nru gcc-defaults-1.200/debian/g++.postinst.in gcc-defaults-1.200+nmu1/debian/g++.postinst.in --- gcc-defaults-1.200/debian/g++.postinst.in 2020-11-17 19:53:07.0 +0100 +++ gcc-defaults-1.200+nmu1/debian/g++.postinst.in 2022-08-28 08:23:21.0 +0200 @@ -2,9 +2,9 @@ # remove the doc dir, if it's still a directory and replace with a symlink pkg=`basename $0 .postinst` -if [ ! -L /usr/share/doc/$pkg ]; then -rm -rf /usr/share/doc/$pkg -ln -s cpp /usr/share/doc/$pkg +if [ ! -L "$DPKG_ROOT/usr/share/doc/$pkg" ]; then +rm -rf "$DPKG_ROOT/usr/share/doc/$pkg" +ln -s cpp "$DPKG_ROOT/usr/share/doc/$pkg" fi # fix for report #138038: remove old diversions signature.asc Description: signature
Bug#1018259: nmu: libidn2_2.3.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: jo...@debian.org, ond...@debian.org, si...@josefsson.org, k...@debian.org Hi, due to a bug in debhelper (see #1015263) the libidn2-0 package gained a wrong dependency on sgml-base. Since there was no upload of libidn2 since the bug got fixed in debhelper, the current version on unstable still wrongly depends on sgml-base. This breaks di-builds because sgml-base doesn't exist in udeb context. This added dependency also hurts bootstrapping and breaks our DPKG_ROOT CI. Please rebuilds libidn2 with the current debhelper version. nmu libidn2_2.3.3-1 . ANY . unstable . -m "rebuild with debhelper after #1015263 was fixed" Thanks! cheers, josch
Bug#1018258: RFP: procs -- modern replacement for ps
Package: wnpp Severity: wishlist * Package name: procs Version : 0.13.0 Upstream Author : Dalance * URL : https://github.com/dalance/procs * License : MIT Programming Lang: Rust Description : modern replacement for ps procs is a replacement for ps written in Rust. Features: - Colored and human-readable output - Automatic theme detection based on terminal background - Multi-column keyword search - Some additional information which are not supported by ps - TCP/UDP port - Read/Write throughput - Docker container name - More memory information - Pager support - Watch mode (like top) - Tree view
Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.
Hi, I have realized that this issue happended in GDM3 environment. In LightDM environment, this issue does not happend. -- Yukiharu YABUKI
Bug#1012404: RM: llvm-toolchain-12 -- ROM; Limit the number of llvm versions
Control: tags -1 +moreinfo Control: block -1 by 102184 On Sun, Aug 28, 2022 at 12:22 AM Jeremy Bicha wrote: > Actually, nothing is using llvm-toolchain-12 so I assume it can be removed > now. Never mind, I checked the wrong thing. Thank you, Jeremy Bicha
Bug#1012404: RM: llvm-toolchain-12 -- ROM; Limit the number of llvm versions
Control: tags -1 -moreinfo Control: unblock -1 by 1012184 Actually, nothing is using llvm-toolchain-12 so I assume it can be removed now. Thank you, Jeremy Bicha
Bug#1018257: rhythmbox: Audio CD does not appear in sources
Package: rhythmbox Version: 3.4.6-2 Severity: normal X-Debbugs-Cc: glenn.gree...@gmail.com Dear Maintainer, Rhythmbox does not add an audio CD to the sources list. Thank You, --glenn green -- System Information: Debian Release: bookworm/testing APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rhythmbox depends on: ii dbus1.14.0-2 ii gstreamer1.0-plugins-base 1.20.3-2 ii gstreamer1.0-plugins-good 1.20.3-1 ii gstreamer1.0-x 1.20.3-2 ii libc6 2.34-4 ii libglib2.0-02.72.3-1+b1 ii libgstreamer-plugins-base1.0-0 1.20.3-2 ii libgstreamer1.0-0 1.20.3-1 ii libgtk-3-0 3.24.34-3 ii libpeas-1.0-0 1.32.0-1+b1 ii librhythmbox-core10 3.4.6-2 ii libx11-62:1.8.1-2 ii media-player-info 24-2 ii rhythmbox-data 3.4.6-2 Versions of packages rhythmbox recommends: ii avahi-daemon 0.8-6 ii gnome-flashback [notification-daemon] 3.44.0-3+b1 ii gnome-shell [notification-daemon] 42.4-1+b1 ii gstreamer1.0-plugins-ugly 1.20.3-1 ii gvfs-backends 1.50.2-1 ii notification-daemon3.20.0-4+b1 ii rhythmbox-plugins 3.4.6-2 ii yelp 42.1-2 Versions of packages rhythmbox suggests: pn gnome-codec-install ii gnome-control-center 1:43~beta-2 ii gstreamer1.0-plugins-bad 1.20.3-2 ii rhythmbox-plugin-cdrecorder 3.4.6-2 -- no debconf information
Bug#1018256: qt6-webengine: unneeded Node.js related build dependencies
Package: src:qt6-webengine Version: 6.3.1+dfsg2-13 Severity: normal Dear Maintainer, There are build dependencies for this package that seem unneeded, which were carried over from qtwebengine-opensource-src packaging. In src:qtwebengine-opensource-src 5.14.1+dfsg-1 [1] a node_modules sub-dir (in src/3rdparty/chromium/third_party/devtools-frontend/src) was fully excluded for the Debian repacked tarball. Removal of the node_modules sub-dir then led to some Node.js related build deps being added to qtwebengine-opensource-src packaging in a later revision (5.15.3+dfsg-1 [2]) due them being needed for that version. Build dependences on these specific packages were added: libjs-d3, node-pako, node-rollup-plugin-terser, node-yargs, rollup In qt6-webengine packaging the above mentioned node_modules sub-dir is currently included in the repacked tarball. This means all five of the listed build dependencies are essentially unneeded, due the build being able to use the already included Node.js modules. Perhaps it would be good to remove the mentioned BDs for the sake of simplifying the required dependencies for qt6-webengine builds? [1] https://tracker.debian.org/media/packages/q/qtwebengine-opensource-src/changelog-5.14.1dfsg-1 [2] https://tracker.debian.org/media/packages/q/qtwebengine-opensource-src/changelog-5.15.3dfsg-1
Bug#1004221: reportbug: automatically add usertags for ftp.debian.org bugs
Control: tags -1 + patch Control: forwarded -1 https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/79 On Fri, 19 Aug 2022 18:55:40 -0700 Sean Whitton wrote: > I don't believe any of our scripts for removals care about usertags, > just bug subjects, so it seems fine to trust the existing tags the BTS > knows about, as demonstrated by Paul's rsync commands. Thanks for confirming. I've filed the above merge request as a patch. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#907652: grep: please use libpcre2 instead of pcre3
Upstream patches were proposed in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47264 , and they've been merged upstream. The next upstream grep release, whenever that is, should allow this debian bug to be closed.
Bug#1017360: src:sentencepiece: fails to migrate to testing for too long: FTBFS on s390x
Package: sentencepiece Version: 0.1.97-1 Followup-For: Bug #1017360 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu kinetic ubuntu-patch Control: tags -1 patch Please find attached a patch for this build failure. It has been uploaded to Ubuntu where it fixes the build failure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru sentencepiece-0.1.97/debian/patches/header-dependencies.patch sentencepiece-0.1.97/debian/patches/header-dependencies.patch --- sentencepiece-0.1.97/debian/patches/header-dependencies.patch 1969-12-31 16:00:00.0 -0800 +++ sentencepiece-0.1.97/debian/patches/header-dependencies.patch 2022-08-27 19:34:02.0 -0700 @@ -0,0 +1,20 @@ +Description: include necessary headers to ensure IS_BIG_ENDIAN is defined + normalizer.h uses IS_BIG_ENDIAN, which is defined in util.h. Include + util.h here. +Author: Steve Langasek +Last-Update: 2022-08-27 +Forwarded: no +Bug-Debian: https://bugs.debian.org/1017360 + +Index: sentencepiece-0.1.97/src/normalizer.h +=== +--- sentencepiece-0.1.97.orig/src/normalizer.h sentencepiece-0.1.97/src/normalizer.h +@@ -22,6 +22,7 @@ + #include + + #include "common.h" ++#include "util.h" + #include "sentencepiece_model.pb.h" + #include "sentencepiece_processor.h" + #include "third_party/absl/strings/string_view.h" diff -Nru sentencepiece-0.1.97/debian/patches/series sentencepiece-0.1.97/debian/patches/series --- sentencepiece-0.1.97/debian/patches/series 2022-06-14 04:51:23.0 -0700 +++ sentencepiece-0.1.97/debian/patches/series 2022-08-27 19:32:13.0 -0700 @@ -1,2 +1,3 @@ support-python-module-in-place.patch disable-static-library.patch +header-dependencies.patch
Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "polymc": * Package name: polymc Version : 1.4.1+ds-1 * URL : https://polymc.org * License : LGPL-3, LGPL-2.1, GPL-3, GPL-2, BSD-3-clause, BSD-2-clause, Apache-2.0, zlib, BSL-1.0, ISC, Expat * Vcs : https://salsa.debian.org/BenTheTechGuy/polymc Section : contrib/games The source builds the following binary package: polymc - FOSS Minecraft launcher supporting multiple instances and accounts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/polymc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/p/polymc/polymc_1.4.1+ds-1.dsc Changes for the initial release: polymc (1.4.1+ds-1) unstable; urgency=medium . * Initial Package (Closes: #898972) Regards, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1018254: qemu: debian shell programs use which instead of the standard command -v
Source: qemu
Version: 1:7.0+dfsg-7
Severity: minor
Dear Maintainer,
Debian ships a few shell programs, and they (ab)use which(1)
instead of the standard command -v.
Please consider the diff, below, which fixes this in:
* debian/qemu-debootstrap
* debian/qemu-ifup.linux
* debian/qemu-make-debian-root
Additionally, it fixes a horrific under-defined (notionally
XSI-extenion, not recommended by the standard, shellcheck-warned)
conditional spelling in debian/qemu-ifup.linux
Best,
наб
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/qemu-7.0+dfsg.orig/debian/qemu-debootstrap
b/qemu-7.0+dfsg/debian/qemu-debootstrap
index 43875cb..399e736 100755
--- a/qemu-7.0+dfsg.orig/debian/qemu-debootstrap
+++ b/qemu-7.0+dfsg/debian/qemu-debootstrap
@@ -5,7 +5,7 @@
# so regular debootstrap can be used just fine without --foreign, since all
# commands inside the chroot will just run using qemu from binfmt-misc
subsystem.
-if ! which debootstrap >/dev/null 2>/dev/null; then
+if ! command -v debootstrap >/dev/null; then
echo "E: debootstrap isn't found in \$PATH, is debootstrap package
installed?" >&2
exit 1
fi
diff --git a/qemu-7.0+dfsg.orig/debian/qemu-ifup.linux
b/qemu-7.0+dfsg/debian/qemu-ifup.linux
index f2f4d5d..76b68ea 100755
--- a/qemu-7.0+dfsg.orig/debian/qemu-ifup.linux
+++ b/qemu-7.0+dfsg/debian/qemu-ifup.linux
@@ -5,13 +5,13 @@
# in order to be able to find brctl
PATH=$PATH:/sbin:/usr/sbin
-ip=$(which ip)
+ip=$(command -v ip)
if [ -n "$ip" ]; then
ip link set "$1" up
else
- brctl=$(which brctl)
- if [ ! "$ip" -o ! "$brctl" ]; then
+ brctl=$(command -v brctl)
+ if [ -z "$ip$brctl" ]; then
echo "W: $0: not doing any bridge processing: neither ip nor brctl
utility not found" >&2
exit 0
fi
@@ -31,11 +31,10 @@ switch=$(ip route ls | \
for br in $switch; do
if [ -d /sys/class/net/$br/bridge/. ]; then
if [ -n "$ip" ]; then
- ip link set "$1" master "$br"
+ exec ip link set "$1" master "$br"
else
- brctl addif $br "$1"
+ exec brctl addif $br "$1"
fi
-exit # exit with status of the previous command
fi
done
diff --git a/qemu-7.0+dfsg.orig/debian/qemu-make-debian-root
b/qemu-7.0+dfsg/debian/qemu-make-debian-root
index d4b6c01..e8681b2 100755
--- a/qemu-7.0+dfsg.orig/debian/qemu-make-debian-root
+++ b/qemu-7.0+dfsg/debian/qemu-make-debian-root
@@ -7,15 +7,15 @@
set -e
-which debootstrap >/dev/null || {
+command -v debootstrap >/dev/null || {
echo "error: missing debootstrap package" >&2
exit 1
}
-which sfdisk >/dev/null || {
+command -v sfdisk >/dev/null || {
echo "error: missing fdisk package" >&2
exit 1
}
-which mke2fs >/dev/null || {
+command -v mke2fs >/dev/null || {
echo "error: missing e2fsprogs package" >&2
exit 1
}
signature.asc
Description: PGP signature
Bug#1018242: osk-sdl: Kernel modules for touchscreen input not included in initramfs on amd64 if MODUES=dep is selected
Package: osk-sdl
Version: 0.67-2
Followup-For: Bug #1018242
X-Debbugs-Cc: drati...@gmail.com
Control: tags -1 patch
Dear Maintainer,
I have found the kernel modules necessary, it seems that hid_multitouch and
i2c_hid_acpi cover at least the Steam Deck and the Asus T100TA. Incidentally,
this also fixes the issue I was having with touch input not working on the
Steam Deck.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages osk-sdl depends on:
ii cryptsetup 2:2.5.0-2
ii cryptsetup-initramfs 2:2.5.0-2
ii debconf [debconf-2.0] 1.5.79
ii fonts-dejavu-core 2.37-2
ii libc6 2.34-3
ii libcryptsetup122:2.5.0-2
ii libegl11.4.0-1
ii libgcc-s1 12.1.0-8
ii libgl1 1.4.0-1
ii libgles2 1.4.0-1
ii libsdl2-2.0-0 2.0.22+dfsg-6
ii libsdl2-ttf-2.0-0 2.20.0+dfsg-1
ii libstdc++6 12.1.0-8
osk-sdl recommends no packages.
osk-sdl suggests no packages.
-- debconf information:
osk-sdl/prerm-config:
>From c2461b41d237d829fbba4d4dea10a9997833c3c5 Mon Sep 17 00:00:00 2001
From: Balint Kovacs
Date: Sun, 28 Aug 2022 00:18:48 +0100
Subject: [PATCH] Include kernel modules necessary on amd64 tablets
---
debian/initramfs/hooks/osk-sdl | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/initramfs/hooks/osk-sdl b/debian/initramfs/hooks/osk-sdl
index 2b65692..8c184be 100755
--- a/debian/initramfs/hooks/osk-sdl
+++ b/debian/initramfs/hooks/osk-sdl
@@ -65,6 +65,7 @@ case "$DPKG_ARCH" in
AMD64_KMSRO="vmwgfx_dri.so virtio_gpu_dri.so i965_dri.so iris_dri.so
kms_swrast_dri.so"
dri_inst ${AMD64_KMSRO}
copy_exec "$libdir/libGLESv2.so.2"
+manual_add_modules hid_multitouch i2c_hid_acpi
;;
*)
echo "osk-sdl unsupported arch: $DPKG_ARCH"
--
2.37.2
Bug#1018253: emacs-nox: Fatal error when installing
This is likely a duplicate of Bug #1017698. (Sorry, I had only searched for bugs in emacs-nox instead of src:emacs.)
Bug#1018253: emacs-nox: Fatal error when installing
Package: emacs-nox Version: 1:28.1+1-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: ke...@mit.edu Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? $ sudo apt install emacs-nox * What exactly did you do (or not do) that was effective (or ineffective)? This was on a fresh "Debian sid amd64 (20220827_05:24)" LXC container. * What was the outcome of this action? Here is one error message: == Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: emacs-bin-common emacs-common emacsen-common install-info libasound2 libasound2-data libgccjit0 libjansson4 liblcms2-2 Suggested packages: emacs-common-non-dfsg ncurses-term libasound2-plugins alsa-utils liblcms2-utils Recommended packages: mailutils emacs-el alsa-ucm-conf alsa-topology-conf The following NEW packages will be installed: emacs-bin-common emacs-common emacs-nox emacsen-common install-info libasound2 libasound2-data libgccjit0 libjansson4 liblcms2-2 0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded. Need to get 29.4 MB of archives. After this operation, 143 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://deb.debian.org/debian sid/main amd64 install-info amd64 6.8-6 [185 kB] Get:2 http://deb.debian.org/debian sid/main amd64 emacsen-common all 3.0.4 [19.3 kB] Get:3 http://deb.debian.org/debian sid/main amd64 emacs-common all 1:28.1+1-2 [14.0 MB] Get:4 http://deb.debian.org/debian sid/main amd64 emacs-bin-common amd64 1:28.1+1-2 [161 kB] Get:5 http://deb.debian.org/debian sid/main amd64 libasound2-data all 1.2.7.2-1 [39.1 kB] Get:6 http://deb.debian.org/debian sid/main amd64 libasound2 amd64 1.2.7.2-1 [380 kB] Get:7 http://deb.debian.org/debian sid/main amd64 libgccjit0 amd64 12.2.0-1 [8,786 kB] Get:8 http://deb.debian.org/debian sid/main amd64 libjansson4 amd64 2.14-2 [40.8 kB] Get:9 http://deb.debian.org/debian sid/main amd64 liblcms2-2 amd64 2.13.1-1 [152 kB] Get:10 http://deb.debian.org/debian sid/main amd64 emacs-nox amd64 1:28.1+1-2 [5,592 kB] Fetched 29.4 MB in 3s (10.6 MB/s) Selecting previously unselected package install-info. (Reading database ... 24354 files and directories currently installed.) Preparing to unpack .../install-info_6.8-6_amd64.deb ... Unpacking install-info (6.8-6) ... Setting up install-info (6.8-6) ... Selecting previously unselected package emacsen-common. (Reading database ... 24368 files and directories currently installed.) Preparing to unpack .../0-emacsen-common_3.0.4_all.deb ... Unpacking emacsen-common (3.0.4) ... Selecting previously unselected package emacs-common. Preparing to unpack .../1-emacs-common_1%3a28.1+1-2_all.deb ... Unpacking emacs-common (1:28.1+1-2) ... Selecting previously unselected package emacs-bin-common. Preparing to unpack .../2-emacs-bin-common_1%3a28.1+1-2_amd64.deb ... Unpacking emacs-bin-common (1:28.1+1-2) ... Selecting previously unselected package libasound2-data. Preparing to unpack .../3-libasound2-data_1.2.7.2-1_all.deb ... Unpacking libasound2-data (1.2.7.2-1) ... Selecting previously unselected package libasound2:amd64. Preparing to unpack .../4-libasound2_1.2.7.2-1_amd64.deb ... Unpacking libasound2:amd64 (1.2.7.2-1) ... Selecting previously unselected package libgccjit0:amd64. Preparing to unpack .../5-libgccjit0_12.2.0-1_amd64.deb ... Unpacking libgccjit0:amd64 (12.2.0-1) ... Selecting previously unselected package libjansson4:amd64. Preparing to unpack .../6-libjansson4_2.14-2_amd64.deb ... Unpacking libjansson4:amd64 (2.14-2) ... Selecting previously unselected package liblcms2-2:amd64. Preparing to unpack .../7-liblcms2-2_2.13.1-1_amd64.deb ... Unpacking liblcms2-2:amd64 (2.13.1-1) ... Selecting previously unselected package emacs-nox. Preparing to unpack .../8-emacs-nox_1%3a28.1+1-2_amd64.deb ... Unpacking emacs-nox (1:28.1+1-2) ... Setting up liblcms2-2:amd64 (2.13.1-1) ... Setting up libjansson4:amd64 (2.14-2) ... Setting up libasound2-data (1.2.7.2-1) ... Setting up emacsen-common (3.0.4) ... Setting up libasound2:amd64 (1.2.7.2-1) ... Setting up emacs-common (1:28.1+1-2) ... Created symlink /etc/systemd/user/default.target.wants/emacs.service ��� /usr/lib/systemd/user/emacs.service. Setting up libgccjit0:amd64 (12.2.0-1) ... Setting up emacs-bin-common (1:28.1+1-2) ... update-alternatives: using /usr/bin/ctags.emacs to provide /usr/bin/ctags (ctags) in auto mode update-alternatives: using /usr/bin/ebrowse.emacs to provide /usr/bin/ebrowse (ebrowse) in auto mode update-alternatives: using /usr/bin/emacsclient.emacs to provide /usr/bin/emacsclient (emacsclient) in auto mode update-alternatives: using /usr/bin/etags.emacs to provide /usr/bin/etags (etags) in auto mode Setting up emacs-nox (1:28.1+1-2) ... update-alternatives: using /usr/bin/emacs-nox to pr
Bug#1018209: Further testing
Hi, I have tested this patch on the Asus T100TA, and the Pinephone. On the Asus, it went from 111476 to 111477 kB, and on the Pinephone, from 82238 to 82239. I didn't have any issues on either.
Bug#1018252: Is ugene still non-free?
Package: ugene Version: 40.1+dfsg-1 Severity: normal A package in non-free with a +dfsg version is strange. #694044 and #693655 mainly talk about two plugins that seem to be resolved already: phylip (1:3.696+dfsg-1) unstable; urgency=medium * New upstream version now with free license * cme fix dpkg-control * removed redundant README.source * d/copyright: - DEP5 now with BSD-2-Clause license - exclude some binaries without source which are not needed ... -- Andreas Tille Wed, 17 Sep 2014 19:35:06 +0200 psipred ugene (33.0+dfsg-1) unstable; urgency=medium ... * Remove psipred from upstream source - it is excluded from build anyway ... -- Andreas Tille Thu, 09 Jan 2020 15:11:09 +0100 I might be missing something, but it's not obvious why ugene is still in non-free.
Bug#919903: ITP: wxwidgets3.2 -- wxWidgets Cross-platform C++ GUI toolkit
On 2022-08-27 03:20, Andrea Pappacoda wrote: Control: tags -1 - wontfix Hi, I've just built wxwidgets3.2 from the salsa [repo], but it seems that the wx-common package isn't being built. Is this intentional? Yes, because wx-common is currently being built by wxwidgets3.0 until we get wxwidgets3.2 through NEW and into the archive. I needed wxWidgets 3.2 because I'm packaging Cemu (#1018037), and it requires the latest wxWidgets version. Also, why was this packaged in a new repo? Because I wanted to get rid of some cruft from the old repo and also switch to a git-buildpackage layout. Scott
Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)
Sean Whitton writes:
> Hello,
>
> On Wed 24 Aug 2022 at 10:57PM +01, Ian Jackson wrote:
>
>>
>> Sean Whitton writes ("Bug#1017725: dgit-maint-native(7) examples should use
>> push-source (rather than push)"):
>>> On Fri 19 Aug 2022 at 05:12PM +02, Philip Hands wrote:
>>> > It strikes me that examples that currently show the `push` sub-command:
>>> >
>>> > dgit -wgf --overwrite push
>>> > and
>>> > dgit -wgf push
>>> >
>>> > should show the use of the `push-source` sub-command instead,
>>> > since doing binary uploads to Debian now prevents migration to
>>> > testing, so chances are that's not what most people want to do.
>>>
>>> Yes, that should be updated.
>>>
>>> > One could perhaps also add a `--with-binary` option for `push` and
>>> > gently transition to defaulting to doing source-only uploads unless
>>> > one specified that option via config or options.
>>>
>>> This is an intriguing suggestion, thank you.
>>
>> Given the differences between the behaviour of (what is now) push and
>> of push-source, I'm not really convinced that a mere option is
>> sufficient.
>>
>> But, how about this:
>>
>> * Provide `push-built` which does what `push` does now.
>> * Change `push` to look at a (not distro-dependent) config option.
>> - for bookworm, defaults to "do push-built, warn"
>> - for bookworm+1, defaults to "do push-source"
>>
>> People who have scripts that do "dgit push" and need to work on older
>> releases can safely pass the config option right away since unknown
>> config options are ignored.
>
> Yes, having a 'push-built' like this alongside 'push-source' sounds
> better than the current push and push-source combination. LGTM.
I think that would have given me the hint I required to know what I
needed to do (without having to do it wrong once to find out :-) )
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#1017976: Info received (Confirmation)
I was able to install 1:27.1+1-3.1 via snapshot.debian.org and that solved the problem. 1:28.1+1-1 did exhibit the bug behavior. I didn't try the +b2 or +b1 of 27.1. Cheers, --sebboh On Sat, Aug 27, 2022 at 3:21 AM Debian Bug Tracking System wrote: > > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Rob Browning > > If you wish to submit further information on this problem, please > send it to 1017...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1017976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017976 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#1018251: kristall: Setting QT_QPA_PLATFORM=wayland makes kristall fail to run
Package: kristall Version: 0.3+git20210303.763bd81+dfsg-1 Severity: normal X-Debbugs-Cc: charlesmel...@outlook.com Dear Maintainer (myself in this case), I'm running kristall on a gnome/wayland (default) session and I always get the following warning regarding kristall: Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. But when I try to run kristall with QT_QPA_PLATFORM=wayland, it fails to launch and displays the following message: qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. Aborted Well, fear not if you're reading this report because this happened to you. This happens because enabling QT_QPA_PLATFORM=wayland makes QT run on wayland natively instead of using a X compatibility layer. You shouldn't worry to much about this last sentence. A very easy solution to the problem is to install qtwayland5: apt install qtwayland5 # (use sudo if you're not root) After that, you'll be able to run kristall with QT_QPA_PLATFORM=wayland set. You may wonder why it doesn't work out of the box, the main problem is running on wayland natively used to be buggy so the upstream deactivated it. Nowadays (qt > 5.12) it pretty stable so it should be safe to run it. There is only one known bug remaining [1] and it's a corner case IMHO. Hopefully this can help anyone with the same problem. Cheers, Carlos Melara (a.k.a. Charles) [1] https://bugreports.qt.io/browse/QTBUG-68636 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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 kristall depends on: ii libc6 2.34-4 ii libgcc-s1 12.1.0-8 ii libqt5core5a 5.15.4+dfsg-5 ii libqt5gui55.15.4+dfsg-5 ii libqt5multimedia5 5.15.4-2 ii libqt5multimediawidgets5 5.15.4-2 ii libqt5network55.15.4+dfsg-5 ii libqt5widgets55.15.4+dfsg-5 ii libssl3 3.0.5-2 ii libstdc++612.1.0-8 kristall recommends no packages. Versions of packages kristall suggests: ii qtwayland5 5.15.4-2 -- no debconf information
Bug#1018250: buster-pu: package eboard/1.1.3-0.4~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Vincent Legout
* Add upstream fix for segfault on engine selection,
thanks to Eric Cooper and Bernhard Übelacker. (Closes: #962627)
The only difference between the package in buster and the package
in bullseye/bookworm was a missing crash fix.
diff -Nru eboard-1.1.3/debian/changelog eboard-1.1.3/debian/changelog
--- eboard-1.1.3/debian/changelog 2019-05-17 16:17:10.0 +0300
+++ eboard-1.1.3/debian/changelog 2022-08-27 23:55:52.0 +0300
@@ -1,3 +1,18 @@
+eboard (1.1.3-0.4~deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for buster.
+
+ -- Adrian Bunk Sat, 27 Aug 2022 23:55:52 +0300
+
+eboard (1.1.3-0.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream fix for segfault on engine selection,
+thanks to Eric Cooper and Bernhard Übelacker. (Closes: #962627)
+
+ -- Adrian Bunk Sat, 17 Jul 2021 21:48:28 +0300
+
eboard (1.1.3-0.3) unstable; urgency=medium
[ Gianfranco Costamagna ]
diff -Nru
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
---
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
1970-01-01 02:00:00.0 +0200
+++
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
2021-07-17 21:48:09.0 +0300
@@ -0,0 +1,21 @@
+From ed33049aff2cefd7508bcda8ab738b8ec871c948 Mon Sep 17 00:00:00 2001
+From: Christian Palazzo
+Date: Thu, 30 Apr 2020 00:43:21 +0200
+Subject: https://bugs.launchpad.net/ubuntu/+source/eboard/+bug/1306419
+
+diff --git a/proto_xboard.cc b/proto_xboard.cc
+index ba48aa1..edabe1b 100644
+--- a/proto_xboard.cc
b/proto_xboard.cc
+@@ -1083,7 +1083,7 @@ void CraftyProtocol::readDialog() {
+ snprintf(EngineCommandLine,512,"crafty bookpath=%s logpath=%s tbpath=%s",
+ BookPath,LogPath,LogPath);
+ if (!global.env.Home.empty())
+-snprintf(EngineRunDir,512,"%s/.eboard/craftylog",global.env.Home.c_str());
++snprintf(EngineRunDir,256,"%s/.eboard/craftylog",global.env.Home.c_str());
+ else
+ strcpy(EngineRunDir,"/tmp");
+
+--
+2.20.1
+
diff -Nru eboard-1.1.3/debian/patches/series eboard-1.1.3/debian/patches/series
--- eboard-1.1.3/debian/patches/series 2019-05-17 16:16:10.0 +0300
+++ eboard-1.1.3/debian/patches/series 2021-07-17 21:48:28.0 +0300
@@ -2,3 +2,4 @@
hungarian-translation.patch
90_respect_deb_build_options.patch
ld-as-needed.patch
+0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
Bug#981944: libmatthew-java: FTBFS with OpenJDK 17 due to javadoc errors
Control: tags -1 patch
I'm attaching a simple patch that addresses the problem. I believe we can just
remove the javadoc param line.
From: Markus Koschany
Date: Sat, 27 Aug 2022 22:47:41 +0200
Subject: java17
---
cx/ath/matthew/unix/UnixSocket.java | 1 -
1 file changed, 1 deletion(-)
diff --git a/cx/ath/matthew/unix/UnixSocket.java b/cx/ath/matthew/unix/UnixSocket.java
index f652614..3c6df06 100644
--- a/cx/ath/matthew/unix/UnixSocket.java
+++ b/cx/ath/matthew/unix/UnixSocket.java
@@ -171,7 +171,6 @@ public class UnixSocket
* @see getPeerUID
* @see getPeerPID
* @see getPeerGID
-* @param data The byte of data to send.
*/
public byte recvCredentialByte() throws IOException
{
signature.asc
Description: This is a digitally signed message part
Bug#1018249: tasksel: add a way to optionally install suggested packages
Package: tasksel Version: 3.70 Severity: wishlist X-Debbugs-Cc: dfo...@gmail.com Dear maintainer, some tasks install packages that suggest other packagesm but there isn't a way to install or remove the suggested packages with tasksel, unless the configuration of APT itself contains APT::Install-Suggests "true"; in which case tasksel installs and removes also the suggested packages. I would find this feature especially useful for hamradio-* and electronics-* but I wouldn't like to enable globally for every apt invocation. Please consider adding a command line option that enables intallation and removal of suggested packages (eg. --enable-suggest or --enable-suggested). thanks, Daniele
Bug#1018248: lv2: ftbfs on ppc64el with usrmerge build environment
Package: lv2 Version: 1.18.4-1 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu kinetic ubuntu-patch Dear maintainers, The lv2 package was failing to build on ppc64el in Ubuntu because the upstream build system has code to detect whether to use /usr/lib64 as a target, which incorrectly triggers in Ubuntu because our build environments are all usrmerge systems (whereas Debian's are not). As we can expect Debian to eventually move its build environment to use usrmerge, I think the attached patch is appropriate to include in Debian as well. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru lv2-1.18.4/debian/rules lv2-1.18.4/debian/rules --- lv2-1.18.4/debian/rules 2021-01-17 12:50:35.0 -0800 +++ lv2-1.18.4/debian/rules 2022-08-27 13:41:15.0 -0700 @@ -13,6 +13,7 @@ override_dh_auto_configure: $(WAF) configure --prefix=/usr \ --mandir=/usr/share/man \ + --libdir=/usr/lib \ --strict override_dh_auto_build:
Bug#1018247: RM: libnet-amazon-perl/0.62-2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: rm The API it uses was removed in 2020, see #990042 for background.
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Samstag, dem 27.08.2022 um 19:40 +0200 schrieb Jonas Smedegaard: > Yes, Ghostscript contains a script update-gsfonts which makes use of > it. I see, thank you . So, I'll keep the file. Do you guys think I will have to post a heads-up to debian-devel for the transition? - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKexQACgkQy+qOlwzN Wd+l3xAA2hXXT0zFjuNnsyqJT9dY6eDrH0CFG8JhI21dkBBl/DBEAov8Mxdv/a7x kZ683Vcx+5z4oa7ig4Ik7LGmTcRLdz0F023IG84a31UuWWEnt9IeWm5sFB1AugSC OMvqOp+4VFLMTxCb1RBGKJ9nLELCeRXKDULoc/4PWHLxicTQTaT958wmq5IbxgJf bsXHWy+u2w8X72R+h1CVPlh1KwNtL8V73PITBODSLnxWPdHZS3kHMMF0X4slBI/P ej96A2upjnyYJF5NUwkzHAkXMBUGL/3l/AMowIm28bBhBFiVuWme5KzuXJ5gvptt KKZ0qDNXRCDmoEjSRqMFJWC8L8OSs4Gw3ajq6Fn/tojpvGl4mz3N7qdMO8LETD6J q0EGa+UW32HCz/WUe1lRvSgrHyZe7igGmhdbnNZgT8XHpQG8DKaPoMWMt7MjxIIb p+8yU58tIfg27SQfEsEmiZ3gXMp/WYkVnCAbJAqxLejohA5XB2Hfn5XDNhZHibAM iP/KcPUyUlBr59/x8I1++Z4BJrVwHsuwpCAbWMdIXzVqE8Ufe00piG1z68/8xw3k tnztmEIFgHfkiP/K+D1EdeyA9QJlTFVc6AohJC4JzTiTsk53Ej6C27g4k6eusOXw +IFcgHLCcn+AsMUk38jzQP5K/BT44nTOFZwCzX7nMng7A7bOEx0= =/rte -END PGP SIGNATURE-
Bug#969482: ITP: glab -- An open-source GitLab command line tool
Package: wnpp Followup-For: Bug #969482 Owner: Julian Dreykorn X-Debbugs-Cc: debian-de...@lists.debian.org, dreykorn.jul...@gmail.com I appologize for the duplicated lines in my previos reply. It was really not my intention, just a copy-paste-mistake that happened accidentally from Vim in the console. I'm sorry for that and hope that it didn't cause any confusions here.
Bug#1018246: buster-pu: package freeradius/3.0.17+dfsg-1.1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Debian FreeRADIUS Packaging Team
* CVE-2019-13456: side-channel leak where 1 in 2048 handshakes fail
* CVE-2019-17185: DoS due to multithreaded BN_CTX access
* Add upstream fix for a crash bug. (Closes: #992036)
This fixes 2 CVEs (already fixed in bullseye),
and a crash that has been already fixed in a bullseye point release.
diff -Nru freeradius-3.0.17+dfsg/debian/changelog
freeradius-3.0.17+dfsg/debian/changelog
--- freeradius-3.0.17+dfsg/debian/changelog 2019-04-23 00:23:36.0
+0300
+++ freeradius-3.0.17+dfsg/debian/changelog 2022-08-27 22:29:38.0
+0300
@@ -1,3 +1,12 @@
+freeradius (3.0.17+dfsg-1.1+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * CVE-2019-13456: side-channel leak where 1 in 2048 handshakes fail
+ * CVE-2019-17185: DoS due to multithreaded BN_CTX access
+ * Add upstream fix for a crash bug. (Closes: #992036)
+
+ -- Adrian Bunk Sat, 27 Aug 2022 22:29:38 +0300
+
freeradius (3.0.17+dfsg-1.1) unstable; urgency=high
* Non-maintainer upload.
diff -Nru
freeradius-3.0.17+dfsg/debian/patches/0001-EAP-pwd-fix-DoS-due-to-multithreaded-BN_CTX-access.patch
freeradius-3.0.17+dfsg/debian/patches/0001-EAP-pwd-fix-DoS-due-to-multithreaded-BN_CTX-access.patch
---
freeradius-3.0.17+dfsg/debian/patches/0001-EAP-pwd-fix-DoS-due-to-multithreaded-BN_CTX-access.patch
1970-01-01 02:00:00.0 +0200
+++
freeradius-3.0.17+dfsg/debian/patches/0001-EAP-pwd-fix-DoS-due-to-multithreaded-BN_CTX-access.patch
2022-08-27 22:27:54.0 +0300
@@ -0,0 +1,137 @@
+From 6b522f8780813726799e6b8cf0f1f8e0ce2c8ebf Mon Sep 17 00:00:00 2001
+From: Mathy Vanhoef
+Date: Fri, 4 Oct 2019 17:53:52 +0400
+Subject: EAP-pwd: fix DoS due to multithreaded BN_CTX access
+
+The EAP-pwd module created one global OpenSSL BN_CTX instance, and
+used this instance in all incoming requests. This means that different
+threads used the same BN_CTX instance, which can result in a crash.
+An adversary can trigger these crashes by concurrently initiating
+multiple EAP-pwd handshakes from different clients.
+
+Fix this bug by creating a separate BN_CTX instance for each request.
+---
+ .../rlm_eap/types/rlm_eap_pwd/eap_pwd.h | 1 +
+ .../rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c | 24 +--
+ .../rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.h | 2 --
+ 3 files changed, 13 insertions(+), 14 deletions(-)
+
+diff --git a/src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.h
b/src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.h
+index 013a6e7992..ca12778f61 100644
+--- a/src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.h
b/src/modules/rlm_eap/types/rlm_eap_pwd/eap_pwd.h
+@@ -90,6 +90,7 @@ typedef struct _pwd_session_t {
+ uint8_t *out; /* message to fragment */
+ size_t out_pos;
+ size_t out_len;
++BN_CTX *bnctx;
+ EC_GROUP *group;
+ EC_POINT *pwe;
+ BIGNUM *order;
+diff --git a/src/modules/rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c
b/src/modules/rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c
+index 76cc57023e..eefca985d7 100644
+--- a/src/modules/rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c
b/src/modules/rlm_eap/types/rlm_eap_pwd/rlm_eap_pwd.c
+@@ -55,8 +55,6 @@ static int mod_detach (void *arg)
+
+ inst = (eap_pwd_t *) arg;
+
+- if (inst->bnctx) BN_CTX_free(inst->bnctx);
+-
+ return 0;
+ }
+
+@@ -76,11 +74,6 @@ static int mod_instantiate (CONF_SECTION *cs, void
**instance)
+ return -1;
+ }
+
+- if ((inst->bnctx = BN_CTX_new()) == NULL) {
+- cf_log_err_cs(cs, "Failed to get BN context");
+- return -1;
+- }
+-
+ return 0;
+ }
+
+@@ -96,6 +89,7 @@ static int _free_pwd_session (pwd_session_t *session)
+ EC_POINT_clear_free(session->pwe);
+ BN_clear_free(session->order);
+ BN_clear_free(session->prime);
++ BN_CTX_free(session->bnctx);
+
+ return 0;
+ }
+@@ -217,6 +211,12 @@ static int mod_session_init (void *instance,
eap_handler_t *handler)
+ session->order = NULL;
+ session->prime = NULL;
+
++ session->bnctx = BN_CTX_new();
++ if (session->bnctx == NULL) {
++ ERROR("rlm_eap_pwd: Failed to get BN context");
++ return 0;
++ }
++
+ /*
+* The admin can dynamically change the MTU.
+*/
+@@ -496,7 +496,7 @@ static int mod_process(void *arg, eap_handler_t *handler)
+ /*
+* compute our scalar and element
+*/
+- if (compute_scalar_element(session, inst->bnctx)) {
++ if (compute_scalar_element(session, session->bnctx)) {
+ DEBUG2("failed to compute server's scalar and element");
+ return 0;
+ }
+@@ -508,7 +508,7 @@ static int mod_process(void *arg, eap_handler_t *handler)
+* element is a point, get
Bug#1018245: RM: gnome-todo -- RoM; superseded by endeavour
Package: ftp.debian.org X-Debbugs-Cc: gnome-t...@packages.debian.org Affects: src:gnome-todo Please remove gnome-todo. The upstream project has been renamed to Endeavour and we have packaged the latest version as source package endeavour. https://gitlab.gnome.org/GNOME/gnome-todo We provided a transitional binary package 'gnome-todo' so that users will get the new binary package automatically upon upgrading. I believe `dak rm` is smart enough to remove the 41.0-3 versions without interfering with the arch:all transitional gnome-todo package (>= 42.0-3) On behalf of the Debian GNOME team, Jeremy Bicha
Bug#1017083: [pkg-crosswire-devel] Bug#1017083: Path forward
On Sat, 27 Aug 2022 at 20:55, Roberto C. Sánchez wrote: > I agree with your approach. Including the source now to address the bug > and ensure that package is not removed is something that should be done > soon. The introduction of the new package could also be pursued in > parallel and once it is accepted into the archive, then bibledit could > be updated to depend on the package and remove the duplicate components. > > Thank you for the support for this approach Roberto. Upstream now has created a new tarball that includes the missing source code. This addresses the bug. It took quite a while to be able to get things work out well, upstream, but anyway, it's done now. That tarball was used to create a new package for Debian. Then the upload was done. Likely things will be moving fast now, and hopefully this fixes the issue completely. Teus.
Bug#1017083: [pkg-crosswire-devel] Bug#1017083: Path forward
On Sat, Aug 27, 2022 at 07:48:11PM +0200, Teus Benschop wrote: > The bug report states this: > > > In order to solve this problem, you could: > > 1. add the source files to "debian/missing-sources" directory. > > 2. repack the origin tarball and add the missing source files to it. > > The intention just now is to go for something similar to the proposed > solution number 2. > That means in this case that upstream will provide a new tarball that > includes the missing source files. > Then once this is done, a new Bibledit package can be created based on this > tarball. > > The intention is to do the above before the package will be > automatically removed from the testing distro, > and then let the new changelog close this bug in time. > I agree with your approach. Including the source now to address the bug and ensure that package is not removed is something that should be done soon. The introduction of the new package could also be pursued in parallel and once it is accepted into the archive, then bibledit could be updated to depend on the package and remove the duplicate components. Regards, -Roberto -- Roberto C. Sánchez
Bug#1018244: buster-pu: package libnet-freedb-perl/0.10-2~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Debian Perl Group
* Add a patch to change the default host from the defunct
freedb.freedb.org to gnudb.gnudb.org. (Closes: #991089)
diff -Nru libnet-freedb-perl-0.10/debian/changelog
libnet-freedb-perl-0.10/debian/changelog
--- libnet-freedb-perl-0.10/debian/changelog2015-12-01 23:24:47.0
+0200
+++ libnet-freedb-perl-0.10/debian/changelog2022-08-27 21:28:48.0
+0300
@@ -1,3 +1,18 @@
+libnet-freedb-perl (0.10-2~deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for buster.
+
+ -- Adrian Bunk Sat, 27 Aug 2022 21:28:48 +0300
+
+libnet-freedb-perl (0.10-2) unstable; urgency=medium
+
+ * Add a patch to change the default host from the defunct
+freedb.freedb.org to gnudb.gnudb.org.
+Thanks to Adrian Bunk for the bug report. (Closes: #991089)
+
+ -- gregor herrmann Fri, 16 Jul 2021 20:53:11 +0200
+
libnet-freedb-perl (0.10-1) unstable; urgency=medium
* Team upload
diff -Nru
libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch
libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch
--- libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch
1970-01-01 02:00:00.0 +0200
+++ libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch
2021-07-16 21:53:11.0 +0300
@@ -0,0 +1,52 @@
+Description: replace default host freedb.freedb.org with gnudb.gnudb.org.
+ Also remove reference to inaccessible documentation, and fix the non-online
+ test which checks for the default host.
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/991089
+Author: gregor herrmann
+Last-Update: 2021-07-16
+Forwarded: https://rt.cpan.org/Ticket/Display.html?id=137752
+Bug: https://rt.cpan.org/Ticket/Display.html?id=137752
+
+--- a/FreeDB.pm
b/FreeDB.pm
+@@ -7,7 +7,7 @@
+ use File::Temp;
+
+ has hostname => (is => 'ro', default => $ENV{HOSTNAME} //
'unknown');
+-has remote_host=> (is => 'rw', default => 'freedb.freedb.org');
++has remote_host=> (is => 'rw', default => 'gnudb.gnudb.org');
+ has remote_port=> (is => 'rw', default => 8880);
+ has user => (is => 'rw', default => $ENV{USER} //
'unknown');
+ has timeout=> (is => 'rw', default => 120);
+@@ -449,7 +449,7 @@
+
+
+ new() creates and returns a new Net::FreeDB object that is connected
+-to either the given host or freedb.freedb.org as default.
++to either the given host or gnudb.gnudb.org as default.
+
+ =item lscat
+
+@@ -723,10 +723,6 @@
+ giving the correct drive number will return in an
+ accurate return.
+
+-=head1 Resources
+-The current version of the CDDB Server Protocol can be
+-found at: http://ftp.freedb.org/pub/freedb/latest/CDDBPROTO
+-
+ =head1 AUTHOR
+ David Shultz Edshu...@cpan.orge
+ Peter Pentchev Er...@ringlet.nete
+--- a/t/00-basic.t
b/t/00-basic.t
+@@ -10,7 +10,7 @@
+ ok($freedb->hostname eq 'unknown', 'Error setting hostname');
+ }
+
+-ok($freedb->remote_host eq 'freedb.freedb.org', 'Error setting default host');
++ok($freedb->remote_host eq 'gnudb.gnudb.org', 'Error setting default host');
+
+ ok($freedb->remote_port == 8880, 'Error setting default port');
+
diff -Nru libnet-freedb-perl-0.10/debian/patches/series
libnet-freedb-perl-0.10/debian/patches/series
--- libnet-freedb-perl-0.10/debian/patches/series 1970-01-01
02:00:00.0 +0200
+++ libnet-freedb-perl-0.10/debian/patches/series 2021-07-16
21:53:11.0 +0300
@@ -0,0 +1 @@
+replace_freedb_with_gnudb.patch
Bug#1018218: bugs.debian.org: Pseudo-header needed for “affects” relationship
> Yes, you can, because this: > > > 3) add support for a placeholder bug number like “-1” (similar to how > > the clone command works) > > is an intrinsic part of how the "Control" pseudo-header works. Somehow I missed that, even though I was looking. There are several docs on the bug tracker and the doc I found seemed to only indicate that -1 was used in the cloning context. Sorry for the trouble.
Bug#1016761: libhttp-daemon-perl: FTBFS with newer HTTP::Tiny versions
Control: forwarded -1 https://github.com/libwww-perl/HTTP-Daemon/issues/57 On Sat, Aug 06, 2022 at 11:17:13PM +, Thorsten Alteholz wrote: > > > On Sat, 6 Aug 2022, gregor herrmann wrote: > > > On Sat, 06 Aug 2022 21:24:08 +0300, Niko Tyni wrote: > > > > > It looks like the recent security fix in libhttp-daemon-perl_6.14-1.1 > > > (or at least the associated test case) has issues with newer versions > > > of the HTTP::Tiny module. > > […] > > > From my build log: > > >Subroutine HTTP::Tiny::Handle::write_content_body redefined at > > > t/content_length.t line 277. > > Oh, that is bad, shall these new tests better be disabled than? The upstream bug at https://github.com/libwww-perl/HTTP-Daemon/issues/57 is unfortunately quiet. FWIW https://github.com/NixOS/nixpkgs/pull/181632 looks like at least NixOS just dropped the test. Guess we should do the same for now but I didn't really look into the actual issue. -- Niko
Bug#1018243: libhash-sharedmem-perl: FTBFS on mipsel: undefined symbol: __sync_bool_compare_and_swap_8
Source: libhash-sharedmem-perl Version: 0.005-1 Severity: important Tags: ftbfs x-debbugs-cc: debian-m...@lists.debian.org This package failed to build on mipsel (and has never built there). >From the build log: # Failed test 'use Hash::SharedMem;' # at t/bad_dir.t line 8. # Tried to use 'Hash::SharedMem'. # Error: Can't load '/<>/blib/arch/auto/Hash/SharedMem/SharedMem.so' for module Hash::SharedMem: /<>/blib/arch/auto/Hash/SharedMem/SharedMem.so: undefined symbol: __sync_bool_compare_and_swap_8 at /usr/lib/mipsel-linux-gnu/perl-base/DynaLoader.pm line 187. # at t/bad_dir.t line 8. # Compilation failed in require at t/bad_dir.t line 8. # BEGIN failed--compilation aborted at t/bad_dir.t line 8. [...] Result: FAIL Failed 29/31 test programs. 607/619 subtests failed. dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 3 I see the source uses __sync_bool_compare_and_swap in lib/Hash/SharedMem.xs:470 . Apparently this is not available on 32-bit MIPS architectures (or 32-bit PPC either for that matter.) I'm copying the MIPS porters. Is there a known workaround for this? -- Niko Tyni nt...@debian.org
Bug#1018242: osk-sdl: Kernel modules for touchscreen input not included in initramfs on amd64 if MODUES=dep is selected
Package: osk-sdl Version: 0.67-2 Severity: normal X-Debbugs-Cc: drati...@gmail.com Dear Maintainer, On my Asus T100TA tablet, I had a very small /boot partition configured (244 MB) so to save space, I wanted to configure a targeted initramfs. (I set MODULES=dep in /etc/initramfs-tools/initramgs.conf) However, that broke touch input on osk-sdl, presumably due to a missing module, as it works when I use MODULES=most. Furhter investigation will be in order. I have not tested this with my Steam Deck, or for that matter my Pine Phone. I am also unsure what modules would be needed. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages osk-sdl depends on: ii cryptsetup 2:2.5.0-2 ii cryptsetup-initramfs 2:2.5.0-2 ii debconf [debconf-2.0] 1.5.79 ii fonts-dejavu-core 2.37-2 ii libc6 2.34-4 ii libcryptsetup122:2.5.0-2 ii libegl11.4.0-1 ii libgcc-s1 12.1.0-8 ii libgl1 1.4.0-1 ii libgles2 1.4.0-1 ii libsdl2-2.0-0 2.0.22+dfsg-6 ii libsdl2-ttf-2.0-0 2.20.0+dfsg-1 ii libstdc++6 12.1.0-8 osk-sdl recommends no packages. osk-sdl suggests no packages. -- debconf information: osk-sdl/prerm-config:
Bug#1018241: buster-pu: package esorex/3.13.1-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: Debian Astronomy Team * Fix testsuite failures on armhf and ppc64el caused by incorrect libffi usage. (Closes: #934081) * Re-enable Python tests on armhf and ppc64el. (Closes: #893206) It builds on armhf and ppc64el. armhf is part of LTS, so fixing Python recipes might still be worth it.
Bug#1017083: Path forward
The bug report states this: > In order to solve this problem, you could: > 1. add the source files to "debian/missing-sources" directory. > 2. repack the origin tarball and add the missing source files to it. The intention just now is to go for something similar to the proposed solution number 2. That means in this case that upstream will provide a new tarball that includes the missing source files. Then once this is done, a new Bibledit package can be created based on this tarball. The intention is to do the above before the package will be automatically removed from the testing distro, and then let the new changelog close this bug in time. Thanks for all the input on this matter.
Bug#1014008: coreutils: comm --output-delimiter= (empty) separates with a single NUL, not the empty string, vice versa for --total
On 01/07/2022 11:29, Pádraig Brady wrote: On 28/06/2022 21:06, наб wrote: retitle -1 1014008 coreutils: comm --output-delimiter= (empty) separates with a single NUL, not the empty string, vice versa for --total thanks The only thing suitable for posting is "lmao". As the title says: $ comm --total --output-delimiter= <(echo a; echo b) <(echo a) | cat -A ^@^@a$ b$ 101total$ Support for the NUL delimiter was explicitly added with: https://github.com/coreutils/coreutils/commit/0e46753d7 You're correct that the support / docs are inconsistent, especially with the subsequently added --total option. I'll fix the docs and --total option upstream. Addressed upstream at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=708ae170c
Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5
On Fri, 2022-02-18 at 19:11 -0800, Ryan Tandy wrote: > I removed "pwdMustChange: TRUE" from the policy and then the tests > passed. Not sure if this is the correct fix, but at least I don't > currently see anything in test_pamcmds.expect that would be expecting > a forced reset? Applying this change makes the autopkgtest pass again (this change has just been merged in Git). That means that the expected functionality of nss-pam-ldapd is tested properly. The tests currently don't test the forced password reset by the user functionality (presence of pwdReset on a user account) and it seems that exact behaviour differs between LDAP server implementations (the password policy controls differ and the return code of the BIND operation may also differ). It seems that currently nslcd (default configuration) rejects the login if a password change is needed on OpenLDAP 2.5. This can be worked around by setting "pam_authc_search NONE" in nslcd.conf which should not cause issues with most OpenLDAP LDAP servers. I plan to upload a new version of the package soon. If anyone has any concerns regarding e.g. insufficient testing of the above use case, please let me know. Kind regards, -- -- arthur - adej...@debian.org - https://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
Quoting Fabian Greffrath (2022-08-27 18:51:04) > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > @Jonas: Is the file /etc/ghostscript/fontmap.d/10fonts-urw-base35.conf > [1] even necessary now that the font files are directly symlinked in > the libgs9-common package? Yes, Ghostscript contains a script update-gsfonts which makes use of it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1016653: gm(1): improve targa (.tga) orientation bits support
Control: retitle -1 gm(1): improve targa (.tga) orientation bits support > Bob Friesenhahn writes: > However, I believe that this bug report is incorrect. After reading [1] (and trying both ImageMagick and GraphicsMagick on the samples*/ provided therein), I guess my suggestions would be as follows. 1. GraphicsMagick .tga reader should support all the combinations of the orientation bits, not just the default ‘bottom left’; (I gather that’s something already in Git?) 2. It should be possible to specify orientation explicitly both when reading .tga files (my understanding is that files produced by buggy .tga writers that get these wrong are not uncommon in the wild) and when writing them (for the benefit of legacy readers that only implement a specific orientation; a quick look into LDPCXTGA’s ldtga.cpp has confirmed that it ignores all the .tga metadata but width and height fields and assumes the non-default TopLeft orientation.) I haven’t checked the source, but it seems that at least -orient is ignored by the GraphicsMagick .tga writer. 3. I’d think the documentation should feature -auto-orient more prominently in the examples. (I’ve retitled the bug report accordingly.) TYC. [1] http://gitlab.com/illwieckz/produce-reference-tga > What has actually happened is that ImageMagick changed what it > returns and more recent ImageMagick also changed what it does > when it displays an image. It sounds like the behavior of ImageMagick’s display(1) was reversed exactly twice, which should’ve resulted in the original behavior being restored, at least so long as the user is concerned. What am I missing here? > GraphicsMagick always returns an image in the common normal form > (TopLeft). ImageMagick changed so that it returns an image in > the same form as the file, but it sets an orientation option so > that the user needs to use -auto-orient to see a correct image. Seems to be the case for .tga images, indeed. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#1018240: Xtightvnc(1): support arbitrary stdio in -inetd, not just socket-based
Package: tightvncserver
Version: 1:1.3.10-5+b1
Severity: wishlist
Control: found -1 1:1.3.10-3
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
Xtightvnc(1) concludes with:
Probably, the best way to secure Xvnc server is to allow only
loopback connections from the server machine (the -localhost option)
and to use SSH tunneling for remote access to the Xvnc server.
However, it’s arguably even more secure to either use a Unix
socket accessible by only the intended user(s) (note that
OpenSSH supports Unix to Unix, TCP to Unix, and Unix to TCP
socket forwarding; see the -L option in ssh(1)); or a pair
of pipes, such as rsync(1) uses (by essentially invoking
$ ssh -- REMOTE rsync --server to access the remote.)
Moreover, certain lightweight SSH2 servers, such as
tinysshd(8), omit support for forwarding altogether, which
doesn’t inconvenience tools such as rsync(1) in the least,
but which makes the advice above impossible to follow.
Unfortunately, the obvious candidate for such usage, the
-inetd option, doesn’t quite support it. The cause is
twofold. On the one hand, Xtightvnc -inetd still assumes
that the communication is done via a TCP socket, uses
setsockopt(2) on the file descriptor, and exits when that
fails. On the other, contrary to the documentation,
-inetd
Xvnc is launched by inetd. This option causes Xvnc to redirect
network input/output to stdin/stdout.
the current implementation uses not stdin and stdout, but rather
‘stdin’ only, for both input and output. Which isn’t a problem
when the server is started from inetd(8) proper, as in that case
both stdin and stdout point to the same socket; but /is/ a
problem in the proposed usage, where stdin and stdout are two
separate pipes (incoming and outgoing, respectively.)
Xvnc/programs/Xserver/hw/vnc/init.c
361- close stderr. OsInit() will redirect stderr logging to an
362- appropriate log file or /dev/null if that doesn't work. */
363-
364:dup2(0,3);
365-inetdSock = 3;
366-close(2);
367-
Xvnc/programs/Xserver/hw/vnc/sockets.c
101-
102:if (setsockopt(inetdSock, IPPROTO_TCP, TCP_NODELAY,
103- (char *)&one, sizeof(one)) < 0) {
104:rfbLogPerror("setsockopt");
105-exit(1);
106-}
107-
(So far as I can tell only a single use of setsockopt(2)
in the file is relevant to the problem being described.)
As such, my suggestions would be as follows.
1. The setsockopt(2) failure in rfbInitSockets () is
downgraded to a warning (from a fatal error.) This
alone should be sufficient for running Xtightvnc(1)
on a Unix socket via inetd(8), which is already more
secure than a localhost-bound TCP port.
2. In place of inetdSock, the code should use separate
inetdIn and inetdOut file descriptors, so that it’s
possible to use a pair of pipes in place of a socket.
It’s also possible to work around the problem at hand by
using socat(1) and strace(1) as follows.
#!/bin/sh
### tightvnc-ssh-pipe.sh
## Example Xtightvnc tunneling via SSH pipes.
## Connect with:
## $ xvncviewer localhost::12345
LOCAL_PORT=12345
REMOTE=remote.example.net
## .
exec socat TCP4-LISTEN:"$LOCAL_PORT",bind=localhost \
EXEC:"ssh -t -- ${REMOTE} \
set -C -e -u -- ; stty raw -echo ; exec 3<> /dev/tty ; \
strace -o /tmp/debug.\"$(date +%s.%N)\" -ft -s95 \
-e trace=dup2 -e trace=setsockopt \
-e inject=setsockopt\\:retval=0\\:when=4 \
-e inject=dup2\\:retval=3\\:when=1 \
-- Xtightvnc \\:99 -auth \"\$HOME\"/.Xauthority \
-geometry 1280x$((1024 - 2 * 24)) -depth 24 \
-dontdisconnect -nevershared -inetd",pty
### tightvnc-ssh-pipe.sh ends here
Here, ssh -t, together with the socat(1) ,pty option, forces
pseudo-tty allocation on the remote side; exec 3<> /dev/tty
redirects file descriptor 3 (which is the number inetdSock
is set to) to the pty thus allocated; -e inject=dup2:retval=3
:when=1 turns the dup2(2) call in init.c into a no-op; and
-e inject=setsockopt:retval=0:when=4 does the same to the
setsockopt(2) call in sockets.c.
Also, while we’re at it, note that Xtightvnc above ignores the
:99 option and binds to /tmp/.X11-unix/X1, as if :1 were given.
It should be noted that the use of pipes, or actually -inetd
/ inetd.conf(5) ‘nowait’, means that the failure of the
underlying connection invariably leads to the termination
of the associa
Bug#1018239: live-boot: please add support for subroot= option
Package: live-boot
Version: 1:20220505
Severity: wishlist
Tags: patch
Control: found -1 1:20190614
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
SquashFS support for file-level deduplication makes it more
space-efficient to have several distinct Debian installs on
a single SquashFS image, rather than have one image per
install (as per the following syslinux.cfg example snippet.)
LABEL bookworm-2022-08-20
...
APPEND ... boot=live toram=6300e90c.squashfs ...
LABEL bookworm-2022-08-24
...
APPEND ... boot=live toram=6305aa79.squashfs ...
This in turn can be used for tracking testing / unstable,
or for having an image with conflicting packages installed
(even though only one of any given set of such will be
usable for a given boot.)
Moreover, this allows for the SquashFS in question to be
updated incrementally, rather than written anew each time,
which is more friendly to flash-based storage devices; and
also allows for booting into an earlier install should there
be issues with the latest one.
I hereby suggest that a subroot= option is implemented, to
point to a subdirectory on the underlying read-only image to
be used in place of its root; like, Syslinux-wise:
LABEL bookworm-2022-08-24
...
APPEND ... boot=live toram=bookworm.squashfs subroot=x6305aa79 ...
The overlay will then use lowerdir=/run/live/rootfs/bookworm
.squashfs/x6305aa79 in place of /run/live/rootfs/bookworm
.squashfs .
FWIW, I’m using this feature for all my ‘live’ images for
a couple of years now, but my configurations are somewhat
similar, so I can’t claim that I’ve tested it extensively.
Also, while we’re at it, I’ve followed the surrounding
code’s style and used:
subroot=*) ROOTINFIX="${_PARAMETER#subroot=}" ...
union=*) UNIONTYPE="${_PARAMETER#union=}" ...
But it sure is less redundant (and thus less error-prone)
to use instead:
subroot=*) ROOTINFIX="${_PARAMETER#*=}" ...
union=*) UNIONTYPE="${_PARAMETER#*=}" ...
Note that in the latter case there’s only one place the
option name needs to be changed (or aliases added), if
ever need arises.
--
FSF associate member #7257 http://am-1.org/~ivan/
--- lib/live/boot/.9990-overlay.sh.~2022-08-23~ 2022-05-05 10:16:56 +
+++ lib/live/boot/9990-overlay.sh 2022-08-23 22:45:09 +
@@ -83,7 +83,7 @@ setup_unionfs ()
if [ -d "${image}" ]
then
# it is a plain directory: do nothing
-rootfslist="${image} ${rootfslist}"
+rootfslist="${image}${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
elif [ -f "${image}" ]
then
if losetup --help 2>&1 | grep -q -- "-r\b"
@@ -106,7 +106,7 @@ setup_unionfs ()
esac
mpoint=$(trim_path "${croot}/${imagename}")
-rootfslist="${mpoint} ${rootfslist}"
+rootfslist="${mpoint}${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
mount_options=""
# Setup dm-verity support if a device has it supported
@@ -188,9 +188,9 @@ setup_unionfs ()
log_begin_msg "Mounting \"${image_directory}\" on \"${croot}/filesystem\""
mount -t $(get_fstype "${image_directory}") -o ro,noatime "${image_directory}" "${croot}/filesystem" || \
panic "Can not mount ${image_directory} on ${croot}/filesystem" && \
- rootfslist="${croot}/filesystem ${rootfslist}"
+ rootfslist="${croot}/filesystem${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
# probably broken:
- mount -o bind ${croot}/filesystem $mountpoint
+ mount -o bind "${croot}/filesystem${ROOTINFIX:+/$ROOTINFIX}" "$mountpoint"
log_end_msg
fi
--- lib/live/boot/.9990-cmdline-old.~2022-08-23~ 2022-05-05 10:16:56 +
+++ lib/live/boot/9990-cmdline-old 2022-08-23 22:45:10 +
@@ -257,6 +257,11 @@ Cmdline_old ()
export ROOT
;;
+ subroot=*)
+ROOTINFIX="${_PARAMETER#subroot=}"
+export ROOTINFIX
+;;
+
union=*)
UNIONTYPE="${_PARAMETER#union=}"
export UNIONTYPE
Bug#1018064: Subject: RFS: cmd2/2.4.1+ds-1 [ITA] [RC] -- Improved Python cmd2 module from (cammon documentation)
Control: tags -1 - moreinfo Hello Tobias! finished! As I still don't have cmd2 permission on debian, I created a Fork and renamed the branch from master to debian/master which is the team's default. As also the current repository shows that the package is not from the python team. follow the new .dsc and mine https://mentors.debian.net/package/cmd2/ and personal repository where the fork is: https://salsa.debian.org/nilsonfsilva/python-cmd2 Nilson F. Silva 81-3036-0200 81-991616348 81-98546-9553 De: Tobias Frost Enviado: sábado, 27 de agosto de 2022 07:30 Para: 1018...@bugs.debian.org <1018...@bugs.debian.org> Assunto: Bug#1018064: Subject: RFS: cmd2/2.4.1+ds-1 [ITA] [RC] -- Improved Python cmd2 module from (cammon documentation) Control: tags -1 moreinfo Hi Nilson, it seems that upstream has released a new upstream version (2.4.2) recently. I'm wondering if it would make sense to update the packaging to this version or if there are special reasons to stick to the older one? (Marking this bug moreinfo until you've gave feedback; just to avoid unnecessary work... Please remove the tag with your reply.) Regarding one thing my eye spotted: You write: > * New maintainer. (Closes: #1012662, #1002341) however, #1002341 is fixing a FTBFS, so it does not "match" the entry. I guess this bug deserves its own changelog entry… Cheers, -- tobi
Bug#1009894: new upstream versions
Hi Matteo, sorry for the delay. I have created merge requests for the current upstream version 1.6.1 on Salsa (branches upstream, pristine-tar and master). It was pretty straight-forward, but there is one problem, though: upstream renamed the executable, shared object and some other file system objects from "qmmp" to "qmmp-1", probably to avoid a conflict with qmmp version 2. I have no idea how to handle this. Regards Harri
Bug#1018238: gm(1): please add Linux framebuffer (/dev/fb0) support
Package: graphicsmagick
Version: 1.4+really1.3.38-1
Severity: wishlist
Control: found -1 1.4+really1.3.36+hg16481-2
Control: found -1 1.4+really1.3.35-1~deb10u2
[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]
It is currently possible to use $ gm convert command to show
images by writing them directly into Linux framebuffer, provided
that the /dev/fb0 device file permissions are set appropriately.
For instance, on my system, the command could be:
$ gm convert -resize 1280x1024 -gravity center -extent 1280x1024 \
-depth 8 -recolor "0 0 1 0, 0 1 0 0, 1 0 0 0, 0 0 0 1" \
IMAGEFILE\[0] rgba:/dev/fb0
Similarly, it’s possible to take screenshots, though the
only way to do so that I was able to figure out requires
a simple byte order conversion helper, like:
$ (perl -e 'use common::sense; binmode (STDIN); binmode (STDOUT);
local $/ = \(4 * 1280); while () {
s/(.)(.)(.)./$3$2$1\377/g; print ($_); }' \
< /dev/fb0 \
| gm convert -size 1280x1024 -depth 8 rgba:- SCREENSHOT.png)
The obvious inconvenience here is that the framebuffer data
format (-size, -depth, but in general also the layout and
such things as the use of indexed color instead of RGB(A))
vary from system to system, depending on the hardware and
its boot- (e. g., I use video=VGA-1:1280x1024-24 on my system)
and run-time (as could be set with fbset(1), at least on
some arm64 machines) configuration.
I therefore suggest that a new ‘Linux framebuffer’ image
format is implemented in GraphicsMagick that would use the
FBIOGET_FSCREENINFO ioctl [1] to figure out the framebuffer
resolution and format before reading (writing) image data
from (to) it; like:
$ gm convert imagefile linuxfb:/dev/fb0
$ gm convert linuxfb:/dev/fb0 screenshot.png
$
[1] http://kernel.org/doc/html/latest/fb/api.html
Better still if it’d be possible to select a portion of
framebuffer for reading (without reading the whole framebuffer
first), or to put the image into a given position on screen
when writing. While this won’t turn gm(1) into a fully-featured
framebuffer image viewer, for what we have fbi(1) already,
arguably it would be rather a convenient feature to use from
scripts.
--
FSF associate member #7257 http://am-1.org/~ivan/
Bug#1018237: RM: proj-rdnap -- ROM; Obsolete
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Please remove proj-rdnap from the archive, it's obsolete now that PROJ uses GeoTIFF grids from the CDN. Kind Regards, Bas
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 @Jonas: Is the file /etc/ghostscript/fontmap.d/10fonts-urw-base35.conf [1] even necessary now that the font files are directly symlinked in the libgs9-common package? Cheers, - Fabian [1] https://salsa.debian.org/fonts-team/fonts-urw-base35/-/blob/master/debian/10fonts-urw-base35.conf Am Samstag, dem 27.08.2022 um 14:12 +0200 schrieb Fabian Greffrath: > Am Freitag, dem 26.08.2022 um 09:52 +0200 schrieb Roland Rosenfeld: > > Just go for it. > > I have just uploaded fonts-urw-base35_20200910-2 to experimental > which > takes over the gsfonts and gsfonts-x11 packages. So, if you guys > could > check if the transition works out for you as expected, that'd be > appreciated. > > Thanks! > > - Fabian > -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKS3gACgkQy+qOlwzN Wd/OEw/+LaO8ZtZFtXNTRCbr0pybxPhIMpqOL16b1vhnT31XwQvGAzuRhuNF2/9g pL2mNe01HKE5FldwuH9+XawdfYnH0P9dMRzm1CXZAwdrVjefwQkhISfFgta+zwG9 A744jNnC7zk/ChQRapmrRKilUjK7MqA3GhC+0jr7I6NF7qNEsi+EUpMDSn5KeqXc d8l2dbmvSFYaajVxTvnNkq3y7feLCyDKIsJKFbVD+FpBs/Om4MRJDBGuc9FKOjTS 4+tsQaWi6FFbdVu4NbEGhcYi3u6b3MWUAfo4MgAQuiE3fpv1rRSE4Hw6aRP7YSwZ 6YKVVURiXbNDdmYjP3lS4yaQ+KWvvIjezUcTuD8RAPgcqUic70+UFU7ytNLR/yXm lP4L0aQuALQD3QFtWh+wFS3Kk/o98afGoqd8gxkDsoUAkwAejHzLAPa2H3j2dpRf 4fgRCVCi4cFroILW/gB7S2ytqvhxGaVoBTYm0XcaTe1KsOt/P1n4CUzf2hVEwFOI UCOet2tzGe34HEvYxFyJoa9nLZu2IE/Qy2BYLNJMBWBZLgi5LHiYfVdh1XRaEx1p lpn2pf+l4ETHwH3/G7aekf1Ew2A6xvIKuja8lSNKsGoQ/jXViIqmPWiCVZGzDA7L oU476E1e3TNhyPIu2G7YH59m7pv8h4LHr5QIGeKRjOUdeCIFkMY= =U7BW -END PGP SIGNATURE-
Bug#1016231: glosstex: FTBFS: ! LaTeX Error: File `hypdoc.sty' not found.
Control: reassign -1 texlive-latex-base 2022.20220722-1
Control: affects -1 src:glosstex
Control: retitle -1 doc.sty requires hypdoc.sty that is in texlive-latex-extra
On Fri, Jul 29, 2022 at 06:39:30PM +0200, Lucas Nussbaum wrote:
> Source: glosstex
> Version: 0.4.dfsg.1-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220728 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > TEXINPUTS=.: latex glosstex.dtx
> > This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian)
> > (preloaded format=latex)
> > restricted \write18 enabled.
> > entering extended mode
> > (./glosstex.dtx
> > LaTeX2e <2022-06-01> patch level 5
> > L3 programming layer <2022-07-15>
> > (/usr/share/texlive/texmf-dist/tex/latex/base/ltxdoc.cls
> > Document Class: ltxdoc 2022/06/22 v2.1h Standard LaTeX documentation class
> > *
> > * Local config file ltxdoc.cfg used
> > *
> > (/usr/share/texlive/texmf-dist/tex/latex/base/ltxdoc.cfg)
> > (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
> > Document Class: article 2021/10/04 v1.4n Standard LaTeX document class
> > (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
> > (/usr/share/texlive/texmf-dist/tex/latex/base/doc.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/tools/multicol.sty)))
> > (/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty) (./glosstex.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)
> > Using the standard configuration file glosstex.std
> > (./glosstex.std)
> > Using the configuration file glosstex.cfg
> > (./glosstex.cfg))
> > Writing index file glosstex.idx
> >
> > ! LaTeX Error: File `hypdoc.sty' not found.
>...
New in 2022.20220722-1:
/usr/share/texlive/texmf-dist/tex/latex/base/doc.sty: \RequirePackage{hypdoc}
This is a problem due to:
texlive-latex-base: /usr/share/texlive/texmf-dist/tex/latex/base/doc.sty
texlive-latex-extra: /usr/share/texlive/texmf-dist/tex/latex/hypdoc/hypdoc.sty
cu
Adrian
Bug#993014: cifs-utils non-parallel FTBFS
El 27/8/22 a las 17:24, Michael Tokarev escribió: 27.08.2022 03:35, Santiago Vila пишет: Hi. Now that this is finally fixed in sid, here is a proposed diff for bullseye, including changelog. Heh. The changelog includes entry by me.. it is not fair for your contribution, I think.. :) I prefer not to appear in the changelog for such tiny contribution, but do as you prefer. I am happy enough to see this fixed in the next point release of Debian 11. BTW, should we drop the .1 from -3.1+deb11u2 release number? This is an upload for stable, so it has to be >= version in stable to be accepted. Version in stable is 2:6.11-3.1+deb11u1 because it was made by security team. Once we start using the "+deb11u1" thing in stable, the usual thing is to increment the u1 part, so we go from u1 to u2. Thanks.
Bug#990739: buster-pu: package iptables-netflow/2.3-5+deb10u1
Hi Adrian, Adrian Bunk wrote: > Since it was easy to verify with kernel 4.19.249-2 that the module did > not compile before but does after the fix, I've uploaded a package with > the debdiff from the bug to buster. Thanks a lot! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1018076: Add depends to armv6-support
Hi, adding support to armv6-support will help here Bastien
Bug#993014: cifs-utils non-parallel FTBFS
27.08.2022 03:35, Santiago Vila пишет: Hi. Now that this is finally fixed in sid, here is a proposed diff for bullseye, including changelog. Heh. The changelog includes entry by me.. it is not fair for your contribution, I think.. :) BTW, should we drop the .1 from -3.1+deb11u2 release number? Thanks, /mjt
Bug#1018235: sgt-puzzles: Updated German man page / halibut translation
Package: sgt-puzzles Version: 20220801.89391ba-1 Severity: wishlist Tags: patch l10n The last update reminded me to actually use sgt-puzzles (had not done so for quite some time) and since I had forgotten the rules, I read my own translation and spotted some typos. Once you upload your next version, could you include the updated de.po (attached)? Finally I noticed that you are in quite close contact with upstream. I noticed that some links in the documentation are broken, e.g. http://www.nikoli.com/en/puzzles/slitherlink.html Maybe upstream wants to review this? (I can open a separate bug if you want). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages sgt-puzzles depends on: ii libc62.34-4 ii libcairo21.16.0-6 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libglib2.0-0 2.72.3-1+b1 ii libgtk-3-0 3.24.34-3 ii libpango-1.0-0 1.50.9+ds-1 ii libpangocairo-1.0-0 1.50.9+ds-1 Versions of packages sgt-puzzles recommends: ii chromium [www-browser] 104.0.5112.101-1 ii firefox-esr [www-browser]102.1.0esr-2 ii konqueror [www-browser] 4:21.12.3-1 ii links [www-browser] 2.27-1+b1 ii lynx [www-browser] 2.9.0dev.10-1 ii sugar-browse-activity [www-browser] 207-1 ii w3m [www-browser]0.5.3+git20220429-1+b1 ii xdg-utils1.1.3-4.1 sgt-puzzles suggests no packages. -- no debconf information -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ 2022-08-05_sgt-puzzles_de.po.xz Description: application/xz signature.asc Description: PGP signature
Bug#1018205: rumur: possible missing linking to latomic
On 8/26/22 23:53, Tobias Frost wrote: On Fri, Aug 26, 2022 at 05:23:20PM -0700, Matthew Fernandez wrote: What I see is that the test program that fails to link is not linked against latomic: + rumur --output checker.c model.m + cc -std=c11 checker.c -lpthread (from https://ci.debian.net/data/autopkgtest/unstable/arm64/r/rumur/25034806/log.gz) This actually puzzles me further. What I’ve looked at in the past to evaluate a package’s success post submission is the QA buildd page.¹ This one indicates both arm64 and armel passed and installed successfully. So is the CI page you linked somehow building the package differently? ¹ https://buildd.debian.org/status/package.php?p=rumur
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
Ben Hutchings wrote... > As a temporary workaround, disabling the Spectre v2 mitigation with the > kernel parameter "nospectre_v2" should allow this kernel version to run > on older CPUs without SSE2. We'll fix this properly in a later update. Thank you, that did the right thing on my very old Celeron (Coppermine) CPU from around the year 2000, part of my hardware museum. Christoph signature.asc Description: PGP signature
Bug#991120: buster-pu: package postsrsd/1.5-2+deb10u2
On Sat, Aug 06, 2022 at 06:18:32PM +0100, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sun, 2021-07-18 at 18:29 +0100, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Wed, 2021-07-14 at 22:00 +0200, Oxan van Leeuwen wrote: > > > [ Checklist ] > > > [x] *all* changes are documented in the d/changelog > > > [x] I reviewed all changes and I approve them > > > [x] attach debdiff against the package in (old)stable > > > [ ] the issue is verified as fixed in unstable > > > > > > As of writing the fix isn't in unstable yet, since I don't have > > > upload rights. > > > I've asked my sponsor to upload the fix for both stable and > > > unstable > > > at the > > > same time -- it seemed unnecessary to add another roundtrip delay, > > > as > > > it's > > > exactly the same fix. > > > > Tagging as "moreinfo" for now on that basis. Please remove the tag > > once > > the upload has happened. > > > > Apparently the unstable upload happened at some point, but the tag was > never removed. > > If this is still something you're interested in fixing in buster, > please go ahead. Since it looks desirable to me to do this now instead of possibly later with an LTS advisore, I've uploaded it to buster. The changes are the debdiff from the bug, except for an UNRELEASED -> buster fix. > Regards, > > Adam cu Adrian
Bug#1018234: gdbm: ftbfs on !linux
Source: gdbm Version: 1.8.3-13.1 Severity: important Tags: patch Hello, gdbm currently ftbfs on !linux because the symbols file unconditionally requires _gdbm_snapshot, while this is a feature that is available on Linux only. The attached patch adds the appropriate condition, could you apply it? Thanks, Samuel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.19.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/libgdbm6.symbols.original2022-08-27 14:58:04.0 + +++ debian/libgdbm6.symbols 2022-08-27 14:58:57.0 + @@ -33,7 +33,7 @@ _gdbm_next_bucket_dir@Base 1.16 _gdbm_put_av_elem@Base 1.16 _gdbm_read_entry@Base 1.16 - _gdbm_snapshot@Base 1.21 + (arch=linux-any)_gdbm_snapshot@Base 1.21 _gdbm_split_bucket@Base 1.16 _gdbm_str2fmt@Base 1.21 _gdbm_unlock_file@Base 1.16
Bug#990739: buster-pu: package iptables-netflow/2.3-5+deb10u1
On Fri, Aug 05, 2022 at 08:35:07PM +0100, Adam D. Barratt wrote: > On Sat, 2021-12-04 at 17:55 +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Tue, 2021-07-06 at 02:45 +0200, Axel Beckert wrote: > > > an API change in the Linux kernel 4.19.194-1 uploaded with the > > > Buster > > > 10.10 stable minor update caused a regression in > > > iptables-netflow-dkms/2.3-5 built from the iptables-netflow source > > > package. The upstream API change happened in 4.19.191: > > > > > > - modules: mark ref_module static > > > > > > > Please go ahead, thanks. > > Ping? We're in the process of organising the final point release for > buster, as support for it transitions over to the LTS team, so if you > would still like to fix it via pu then the upload needs to happen soon. Since it was easy to verify with kernel 4.19.249-2 that the module did not compile before but does after the fix, I've uploaded a package with the debdiff from the bug to buster. > Regards, > > Adam cu Adrian
Bug#983841: buster-pu: package libvirt-php/0.5.4-3+deb10u1
On Sat, Aug 06, 2022 at 06:16:54PM +0100, Adam D. Barratt wrote: > Control: tags -1 -moreinfo + confirmed > > On Wed, 2021-03-17 at 18:32 +, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Tue, 2021-03-02 at 08:47 +0100, Ondřej Surý wrote: > > > [ Reason ] > > > The package update fixes segmentation fault caused by incomplete > > > PHP > > > 7.3 support > > > in the upstream package. > > > > > > [ Impact ] > > > The PHP crashes when calling libvirt_node_get_cpu_stats (See > > > #982804) > > > > The metadata for that bug implies that it affects the package in > > unstable, and is not yet fixed there. Is that correct? > > > > That appears to have been resolved in the meantime. > > If this is something that you're still interested in fixing in buster, > please go ahead. Since it looks correct and desirable to me and has already been approved, I've uploaded a package with the debdiff from the bug to buster. > Regards, > > Adam cu Adrian
Bug#993132: python3-fife: prints "is"/"is not" used-with-a-literal warnings at install time
Control: tags -1 fixed-upstream patch Control: forwarded -1 https://github.com/fifengine/fifengine/issues/1082 This seems to be fixed upstream: https://github.com/fifengine/fifengine/pull/1076 and https://github.com/fifengine/fifengine/commit/f37c31c6cea74d50f1d635d876253a7b1f64630b
Bug#974553: RFP: gomuks -- terminal based Matrix client
Hi Gürkan (2020.11.12_10:12:49_+0200) > Note I have completely done the wrong order, first did the packaging > wrong (downloads from internet during build) > then read: > https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html Yeah, that's the biggest blocker here. Most of the dependencies are packaged in Debian already, but not all of them. From a quick look at go.mod, we're missing: gopkg.in/toast.v1 v1.0.0-20180812000517-0a84660828b2 gopkg.in/vansante/go-ffprobe.v2 v2.0.2 maunium.net/go/mautrix v0.9.26 maunium.net/go/mauview v0.1.2 maunium.net/go/tcell v0.2.0 And there are version mismatches, but presumably most of those aren't an issue. So, first step would be to package those missing dependencies, above. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1017083: Path forward
If a package like libjs-quill was created, this package would have to go through the NEW queue before it would be accepted in the Debian archives. Earlier packages in this queue always took considerable time before they were reviewed and accepted. Based on earlier experience with new packages in Debian, I would expect that this Bibledit package will long have been removed automatically from testing. So although creating libjs-quill would be the right thing to do, I am inclined to take the quicker route this time around, and just satisfy the bug report, and that's it. Satisfying the bug report is, as the bug states, to include the source code that leads to the minified Javascript. That looks a reasonable approach just now, and something that can be done in time before Bibledit is removed from the testing distribution. At the same time it looks wise to me if someone files a bug that libjs-quill would need to be packaged. Then if libjs-quill is available, Bibledit could eventually switch to using this new package. But this is something for the longer term. It's not a short-term solution to this bug report.
Bug#1018233: fife: X Error of failed request: GLXBadDrawable
Source: fife Version: 0.4.2-3 Severity: important Control: tags -1 upstream Control: affects -1 unknown-horizons Control: forwarded -1 https://github.com/fifengine/fifengine/issues/1079 while trying to unbreak unknown-horizons, I found this error: When starting unknown-horizons, it immediatly errors out with $unknown-horizons X Error of failed request: GLXBadDrawable Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 287 Current serial number in output stream: 287 Some research indicates a problem in fife, upstream has this bug reported: https://github.com/fifengine/fifengine/issues/1079
Bug#945748: xboxdrv: Python2 removal in sid/bullseye
Here's upstream's unreleased fix for Python3, which works for me https://gitlab.com/xboxdrv/xboxdrv/-/commit/3ca002d783974539f5be4e683b67a58f4cc9fce0 -- Michael R. Crusoe OpenPGP_signature Description: OpenPGP digital signature
Bug#1009200: pytorch: (autopkgtest) needs update for python3.10: 'float' object cannot be interpreted as an integer
On Sat, 2022-08-27 at 08:55 +0200, Emanuele Rocca wrote: > On 08/04 09:36, Paul Gevers wrote: > > We are in the transition of making python3.10 the default Python > > versions > > [0]. With a recent upload of python3-defaults the autopkgtest of > > pytorch > > fails in testing when that autopkgtest is run with the binary > > packages of > > python3-defaults from unstable. It passes when run with only > > packages from > > testing. FYI, everything is already fixed in git a couple of months ago, and we are just waiting for the package to go through NEW queue.
Bug#1018232: libunistring: symbols need updating on hurd-i386
Source: libunistring Version: 0.9.3-5.2 Severity: important Tags: patch Hello, Apart from a couple of testsuite issues, which I have fixed in glibc, libunistring fails to build due to an outdated symbols file. The attached patch does this by simply removing the specific debian/libunistring2.symbols.hurd-i386 file, and use instead the (arch=hurd-any) qualifier that makes symbols properly conditioned. Could you apply it? Thanks, Samuel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.19.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/libunistring2.symbols.original 2022-08-27 12:42:24.0 + +++ debian/libunistring2.symbols2022-08-27 13:47:04.0 + @@ -152,7 +152,7 @@ libunistring_c_tolower@Base 0.9.7 libunistring_c_toupper@Base 0.9.7 libunistring_freea@Base 0.9.7 - (arch=gnu-any-any)libunistring_fseterr@Base 0.9.7 + (arch=hurd-any)libunistring_fseterr@Base 0.9.7 libunistring_gl_locale_name@Base 0.9.7 libunistring_gl_locale_name_default@Base 0.9.7 libunistring_gl_locale_name_environ@Base 0.9.7 @@ -166,7 +166,11 @@ libunistring_gl_uninorm_decompose_merge_sort_inplace@Base 0.9.7 libunistring_glthread_once_singlethreaded@Base 0.9.7 libunistring_glthread_recursive_lock_init_multithreaded@Base 0.9.7 - (arch=gnu-any-any)libunistring_glthread_rwlock_init_for_glibc@Base 0.9.8 + (arch=hurd-any)libunistring_glthread_rwlock_destroy_multithreaded@Base 0.9.8 + (arch=hurd-any)libunistring_glthread_rwlock_init_multithreaded@Base 0.9.8 + (arch=hurd-any)libunistring_glthread_rwlock_rdlock_multithreaded@Base 0.9.8 + (arch=hurd-any)libunistring_glthread_rwlock_unlock_multithreaded@Base 0.9.8 + (arch=hurd-any)libunistring_glthread_rwlock_wrlock_multithreaded@Base 0.9.8 libunistring_hard_locale@Base 0.9.7 libunistring_iconveh_close@Base 0.9.7 libunistring_iconveh_open@Base 0.9.7 diff --exclude .svn --exclude .git --exclude CVS --exclude .hg -urN debian.original/libunistring2.symbols.hurd-i386 debian/libunistring2.symbols.hurd-i386 --- debian.original/libunistring2.symbols.hurd-i386 2021-04-26 22:24:08.0 +0200 +++ debian/libunistring2.symbols.hurd-i386 1970-01-01 01:00:00.0 +0100 @@ -1,689 +0,0 @@ -libunistring.so.2 libunistring2 #MINVER# -* Build-Depends-Package: libunistring-dev - UC_CATEGORY_C@Base 0.9.7 - UC_CATEGORY_Cc@Base 0.9.7 - UC_CATEGORY_Cf@Base 0.9.7 - UC_CATEGORY_Cn@Base 0.9.7 - UC_CATEGORY_Co@Base 0.9.7 - UC_CATEGORY_Cs@Base 0.9.7 - UC_CATEGORY_L@Base 0.9.7 - UC_CATEGORY_LC@Base 0.9.7 - UC_CATEGORY_Ll@Base 0.9.7 - UC_CATEGORY_Lm@Base 0.9.7 - UC_CATEGORY_Lo@Base 0.9.7 - UC_CATEGORY_Lt@Base 0.9.7 - UC_CATEGORY_Lu@Base 0.9.7 - UC_CATEGORY_M@Base 0.9.7 - UC_CATEGORY_Mc@Base 0.9.7 - UC_CATEGORY_Me@Base 0.9.7 - UC_CATEGORY_Mn@Base 0.9.7 - UC_CATEGORY_N@Base 0.9.7 - UC_CATEGORY_Nd@Base 0.9.7 - UC_CATEGORY_Nl@Base 0.9.7 - UC_CATEGORY_No@Base 0.9.7 - UC_CATEGORY_P@Base 0.9.7 - UC_CATEGORY_Pc@Base 0.9.7 - UC_CATEGORY_Pd@Base 0.9.7 - UC_CATEGORY_Pe@Base 0.9.7 - UC_CATEGORY_Pf@Base 0.9.7 - UC_CATEGORY_Pi@Base 0.9.7 - UC_CATEGORY_Po@Base 0.9.7 - UC_CATEGORY_Ps@Base 0.9.7 - UC_CATEGORY_S@Base 0.9.7 - UC_CATEGORY_Sc@Base 0.9.7 - UC_CATEGORY_Sk@Base 0.9.7 - UC_CATEGORY_Sm@Base 0.9.7 - UC_CATEGORY_So@Base 0.9.7 - UC_CATEGORY_Z@Base 0.9.7 - UC_CATEGORY_Zl@Base 0.9.7 - UC_CATEGORY_Zp@Base 0.9.7 - UC_CATEGORY_Zs@Base 0.9.7 - UC_PROPERTY_ALPHABETIC@Base 0.9.7 - UC_PROPERTY_ASCII_HEX_DIGIT@Base 0.9.7 - UC_PROPERTY_BIDI_ARABIC_DIGIT@Base 0.9.7 - UC_PROPERTY_BIDI_ARABIC_RIGHT_TO_LEFT@Base 0.9.7 - UC_PROPERTY_BIDI_BLOCK_SEPARATOR@Base 0.9.7 - UC_PROPERTY_BIDI_BOUNDARY_NEUTRAL@Base 0.9.7 - UC_PROPERTY_BIDI_COMMON_SEPARATOR@Base 0.9.7 - UC_PROPERTY_BIDI_CONTROL@Base 0.9.7 - UC_PROPERTY_BIDI_EMBEDDING_OR_OVERRIDE@Base 0.9.7 - UC_PROPERTY_BIDI_EUROPEAN_DIGIT@Base 0.9.7 - UC_PROPERTY_BIDI_EUR_NUM_SEPARATOR@Base 0.9.7 - UC_PROPERTY_BIDI_EUR_NUM_TERMINATOR@Base 0.9.7 - UC_PROPERTY_BIDI_HEBREW_RIGHT_TO_LEFT@Base 0.9.7 - UC_PROPERTY_BIDI_LEFT_TO_RIGHT@Base 0.9.7 - UC_PROPERTY_BIDI_NON_SPACING_MARK@Base 0.9.7 - UC_PROPERTY_BIDI_OTHER_NEUTRAL@Base 0.
Bug#1018167: gettext: FTBFS on hurd-i386
Samuel Thibault, le ven. 26 août 2022 14:52:19 +0200, a ecrit: > Santiago Vila, le ven. 26 août 2022 14:25:19 +0200, a ecrit: > > > FAIL: msgcat-17 > > > === > > > > > > 16,18c16,18 > > > < "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine " > > > < "Platte% s% smit der jederzeitigen Möglichkeit eines Fehlers in jedem > > > Moment " > > > < "und an jeder Stelle" > > > --- > > > > "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine > > > > Platte% s" > > > > "% smit der jederzeitigen Möglichkeit eines Fehlers in jedem Moment und > > > > an " > > > > "jeder Stelle" > > > > I have the feeling that this may have something to do with terminal width on > > Hurd, but I don't really know. > > I don't pay particular attention to my terminal width when I restart > buildd, but I also had a quick try, and building gettext in various > terminal sizes doesn't change the result (and it should really not, > otherwise it's a gettext test suite bug, I'd say :) The test actually passes --width=80 > > > < "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine " > > > < "Platte% s% smit der jederzeitigen Möglichkeit eines Fehlers in jedem > > > Moment " > > > --- > > > > "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine > > > > Platte% s" > > > > "% smit der jederzeitigen Möglichkeit eines Fehlers in jedem Moment und > > > > an " > > In the second line of the reference, there are more characters than in > the first line of the obtained result. So it's probably not a question > of width, but I guess it may rather be related to e.g. word breaking > rules. Investigation would be needed to find out what exactly makes the > break happen at a different position. Apparently on hurd-i386 gettext is not using libunistring, probably because the latest version is not built due to a couple test failures. I have fixed them, the gettext giveback will be waiting ~6h for the resulting binaries to be installed. Samuel
Bug#1018166: RM: rust-spotify-tui -- ROM; FTBFS for the last year
Upstream has no commits on master since Nov 2021. The main developer lacked time: https://github.com/Rigellute/spotify-tui/issues/1000 Regards, Blair Noctis
Bug#1018146: correct multiarch for blends stuff?
Hi Petter, On Sat, Aug 27, 2022 at 10:52:07AM +0200, Petter Reinholdtsen wrote: > I do not know, as I have not looked into this in years, but I doubt it. > The dependency three across all architectures are just too complex for > me to believe it. The essence of my argument was that the dependency tree has become irrelevant. Since britney does not look into Recommends and the dependency tree has become a recommendation tree, there aren't actually that many dependencies left. It's a fairly simple tree now (when disregarding recommends). Helmut
Bug#1018230: mkmf.rb's pkg_config function does not work for cross compilation
Package: libruby3.0
Version: 3.0.4-7+b1
File: /usr/lib/ruby/3.0.0/mkmf.rb
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cr...@lists.debian.org
Control: affects -1 + src:ruby-augeas
Hi Antonio et al,
during DebConf22, Antonio made cross building ruby extensions work.
That's awesome. It also means that we can not start looking into issues
further down in that stack.
ruby-augeas fails to cross build. It use pkg-config via the pkg_config
function from mkmf.rb. This function happens to use the build
architecture pkg-config and thus fails finding the requested packages
(which happen to only be installed for the host architecture). This is
not an issue in ruby-augeas, but an issue in mkmf.rb aka libruby3.0 and
it will affect many source packages.
Relevant code at:
https://sources.debian.org/src/ruby3.0/3.0.4-7/lib/mkmf.rb/#L1822
For some reason, this function says that if we are cross compiling,
pkg-config doesn't work. While that used to be true, it is not on Debian
since quite a while. We should do something like:
- (pkgconfig = with_config("pkg-config", ("pkg-config" unless
CROSS_COMPILING))) &&
+ (pkgconfig = with_config("pkg-config", CROSS_COMPILING ?
"#{DEB_HOST_GNU_TYPE}-pkg-config" : "pkg-config")) &&
Unfortunately, DEB_HOST_GNU_TYPE doesn't exist as a ruby variable here.
It probably needs to come from the host architecture's rbconfig.rb. I
checked and unfortunately, rbconfig.rb doesn't have any variable that
would know the right value. It has CONFIG['arch'], which is more like
DEB_HOST_MULTIARCH (and that happens to be correct everywhere except
any-i386). It also has CC valued "#{DEB_HOST_GNU_TYPE}-gcc" and we may
be able to dissect that.
I think the best solution here would be adding CONFIG['PKG_CONFIG'] to
rbconfig.rb and using that. I happen to not know how to implement that.
Does the approach sound reasonable? Would it be upstreamable?
Helmut
Bug#1018231: O: ucpp -- embeddable, quick and light C preprocessor
Package: wnpp Severity: normal Control: affects -1 src:ucpp I intend to orphan the ucpp package. The package description is: A C preprocessor designed to be embeddable, quick, light and fully compliant to ISO Standard 9899:1999, aka ISO C99, or simply, C99. Nowadasys, the LibreOffice SDK works with cpp (and that is done in the libreoffice packages). And in LibreOffice 7.5 (bookworm) idlc will be gone completely (and thus also ucpp: https://cgit.freedesktop.org/libreoffice/core/commit/?id=a8485d558fab53291e2530fd9a1be581c1628deb https://qa.debian.org/popcon-graph.php?packages=ucpp&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1 has 131 installations but it's decreasing. Those is from(old)stable: See https://packages.debian.org/buster/libreoffice-dev (ucpp) and https://packages.debian.org/bullseye/libreoffice-dev (ucpp) and https://packages.debian.org/bookworm/libreoffice-dev (cpp) Regards, Rene
Bug#990047: timeshift: Not possible to browse content of snapshot via the gui
Le 04/08/2022 à 23:28, Steve M a écrit : Ludovic, Timeshift first uses xdg-open to call the default tool of your desktop environment as it in turn calls gvfs-open, kde-open, exo-open, gnome- open, etc. as appropriate. On my Debian desktop with KDE running xdg- open and kde-open launche Dolphin, but on my Pop_OS laptop xdg_open is not installed and there is no gvfs-open for some reason. In the event that xdg_open fails, Timeshift tries in order to launch nemo, nautilus, thunar, io.elementary.files, pantheon-files, marlin, and dolphin lastly. In your case it seems that maybe xdg-open is resulting in "code" being called due to your Gnome settings. The command `xdg-mime query default inode/directory` should report out what the default file browser is set to. You can also look in ~/.config/mimeapps.list to see what it is set to. I think you can just edit this file or run a command similar to `xdg-mime default org.gnome.Nautilus.desktop inode/directory` to make a change. Please let me know how this works out as it may be worth asking upstream for a more robust means of opening the default file manager. Thanks -Steve Steeve, Okay. I see the catch! The command `xdg-mime query default inode/directory` returns org.gnome.Nautilus.desktop (as expected) when I run it as my user. But, as Timeshift runs as root, if I run the same xdg-mime command as root I get `code.desktop` :( root doesn't have any `~/.config/mimeapps.list file`. And it sure won't use the settings I have in my account. After purging the VSCode package, the xdg-mime returns org.gnome.Nautilus.desktop as one would expect. As root, `xdg-mime default org.gnome.Nautilus.desktop inode/directory` creates the cat ~/.config/mimeapps.list enforcing nautilus as the default application. Fixing the behaviour when VSCode is installed. A diff of my /etc folder after VSCode install show this change brought by the package. Adding VSCode for inode/directory if I understand it properly : ``` diff --git a/mailcap b/mailcap index 7167022..2d64e78 100644 --- a/mailcap +++ b/mailcap @@ -84,6 +84,10 @@ application/xhtml_xml; /usr/bin/chromium %s; test=test -n "$DISPLAY" application/x-mimearchive; /usr/bin/chromium %s; test=test -n "$DISPLAY" x-scheme-handler/http; /usr/bin/chromium %s; test=test -n "$DISPLAY" x-scheme-handler/https; /usr/bin/chromium %s; test=test -n "$DISPLAY" +x-scheme-handler/vscode; /usr/share/code/code --open-url %s; test=test -n "$DISPLAY" +text/plain; /usr/share/code/code --new-window %s; test=test -n "$DISPLAY" +inode/directory; /usr/share/code/code --new-window %s; test=test -n "$DISPLAY" +application/x-code-workspace; /usr/share/code/code --new-window %s; test=test -n "$DISPLAY" application/vnd.iccprofile; /usr/bin/gcm-import %s; test=test -n "$DISPLAY" application/pkcs12; /usr/bin/gcr-viewer %s; test=test -n "$DISPLAY" application/pkcs12+pem; /usr/bin/gcr-viewer %s; test=test -n "$DISPLAY" ``` So, I guess that Timeshift does it right. And it's VSCode causing trouble to the party. -- Ludovic Poujol
Bug#1017885: dictionaries-common: debian-ispell.el triggers warnings in Emacs
El mié, 24 ago 2022 a las 21:45, Vincent Lefevre () escribió: Hi, Vincent, > It seems that Emacs caches results, so that once the cache is built, > Emacs doesn't attempt to rebuild anything... until the cache gets > obsolete or is removed: > > rm -r .emacs.d/eln-cache > > Now I've seen earlier today that this was not working at all in > firejail with some restrictive profiles because gcc could not be run. > If I understand correctly, Emacs now wants to compile the .el files: > > https://www.emacswiki.org/emacs/GccEmacs Thanks, I was not aware of this change. I track the emacs mailing list, but mostly for spellchecking related issues and did not notice this change. > > First two warnings should never happen, ‘really-hunspell’ is a local > > variable inside a let statement, Other expect the variable or function > > from outside the file. I could improve the use of > > ‘ispell-base-dicts-override-alist’, but seems not a problem here. > > So this would be a bug in Emacs itself? This seems caused by a typo in my definition, not a bug in Emacs. The underlying reason for these warnings is that we use to supress warnings in normal byte-compilation, but this does not happen in this async byte-compilalation. I expect an upload with this problem fixed soon. Thanks again for your info. Regards, -- Agustin
Bug#1007173: bogofilter: Bogofilter crashes with "realloc: invalid next size" on some emails
Control: reopen 733622 Control: forcemerge 733622 -1 On Mon, Jun 27, 2022 at 11:44:22PM +0200, Bernhard Übelacker wrote: > Dear Maintainer, > tried to reproduce this issue and it is not observable in > bookworm/testing or bullseye/stable. > > Following is from a asan enabled build in buster/oldstable > with the given example file. First of all apologies for the late reply. This is an old issue fixed in 1.2.5, but I've never managed to get a reasonably small set of patches to backport only the fix. If upgrading to bullseye is not an option, then installing the bullseye version of bogofilter from buster-backports is unfortunately the best option. > Kind regards, > Bernhard >... cu Adrian
Bug#1018229: O: libcuckoo -- high-performance, concurrent hash table (header-only) library
Package: wnpp Severity: normal Control: affects -1 src:libcuckoo Hi, I intend to orphan the libcuckoo package. # apt-cache show libcuckoo-dev Package: libcuckoo-dev Source: libcuckoo Version: 0.3.1-1 Installed-Size: 184 Maintainer: Debian LibreOffice Maintainers Architecture: all Description: high-performance, concurrent hash table (header-only) library Description-md5: 266f2c64cb38d9dc6d4ae9e5e2c2e5e3 Homepage: https://github.com/efficient/libcuckoo Section: devel Priority: optional Filename: pool/main/libc/libcuckoo/libcuckoo-dev_0.3.1-1_all.deb Size: 37064 MD5sum: bac7f0e662e8acc36e5763d8162650a5 SHA256: 7ade625a6887c4797d81a823c0112de7beec859148efb966696dcb55f895056e Was packaged for LibreOffice but since it isn't used anymore I lost interest :) Note the (autopkg)test is flaky and thus marked as such in the last upload, see https://github.com/efficient/libcuckoo/issues/144 for the upstream issue. Given it was packaged specifically for LibreOffice and noone is using it (and ~non-installed due to popcon, but that might be wrong as it's header-only, just a build-dependency - but that would then still be installed in the development environment) maybe it should just be removed instead? Especially as it never was part of a stable release... Regards, Rene
Bug#1012404: RM: llvm-toolchain-13 -- ROM; Limit the number of llvm versions
Control: tags -1 +moreinfo Setting the tag until these are ready for removal. Thank you, Jeremy Bicha
Bug#1018228: jupyterlab-pygments: autopkgtest regression in testing
Source: jupyterlab-pygments Version: 0.2.2-1 Severity: serious User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.10 Hi Maintainer The autopkgtests of jupyterlab-pygments recently regressed in testing [1]. I've copied what I hope is the relevant part of the log below. This is probably due to the hardcoded dependency on python3.9-minimal in debian/tests/control. Regards Graham [1] https://ci.debian.net/packages/j/jupyterlab-pygments/testing/amd64/ autopkgtest: WARNING: package python3-jupyterlab-pygments is not installed though it should be autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs Reading package lists... Building dependency tree... Reading state information... E: Unable to locate package python3.9-minimal E: Couldn't find any package by glob 'python3.9-minimal' E: Couldn't find any package by regex 'python3.9-minimal' command1 FAIL badpkg blame: jupyterlab-pygments badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U.
Bug#1018227: bullseye-pu: package gri/2.12.27-1.1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: Peter S Galbraith * Use ps2pdf instead of convert for converting from ps to pdf. (Closes: #991057) See #987504 for background of the imagemagick change that caused the FTBFS. diff -Nru gri-2.12.27/debian/changelog gri-2.12.27/debian/changelog --- gri-2.12.27/debian/changelog2020-06-26 03:41:17.0 +0300 +++ gri-2.12.27/debian/changelog2022-08-27 15:14:06.0 +0300 @@ -1,3 +1,18 @@ +gri (2.12.27-1.1~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Rebuild for bullseye. + + -- Adrian Bunk Sat, 27 Aug 2022 15:14:06 +0300 + +gri (2.12.27-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Use ps2pdf instead of convert for converting from ps to pdf. +(Closes: #991057) + + -- Adrian Bunk Thu, 25 Aug 2022 19:33:47 +0300 + gri (2.12.27-1) unstable; urgency=medium * New upstream release. diff -Nru gri-2.12.27/debian/patches/imagemagick.patch gri-2.12.27/debian/patches/imagemagick.patch --- gri-2.12.27/debian/patches/imagemagick.patch1970-01-01 02:00:00.0 +0200 +++ gri-2.12.27/debian/patches/imagemagick.patch2022-08-25 19:33:47.0 +0300 @@ -0,0 +1,30 @@ +Description: Use ps2pdf instead of convert for converting from ps to pdf +Author: Adrian Bunk +Bug-Debian: https://bugs.debian.org/991057 + +--- gri-2.12.27.orig/doc/examples/Makefile.am gri-2.12.27/doc/examples/Makefile.am +@@ -78,8 +78,8 @@ DISTCLEANFILES = $(png_files) $(eps_file + %-tiny.png : %.png + -convert -strip -background white -geometry 90x999 $< $@ + %.pdf : %.ps +- convert $< $@ +-# ps2pdf $< $@ ++# convert $< $@ ++ ps2pdf $< $@ + %.html : %.gri + perl $(srcdir)/../gri2html $< $@ + all: html png eps txt +--- gri-2.12.27.orig/doc/screenshots/Makefile.am gri-2.12.27/doc/screenshots/Makefile.am +@@ -26,8 +26,8 @@ pdf: $(the_pdf_files) + -convert $< $@ + + %.pdf : %.eps +- convert $< $@ +-# ps2pdf $< $@ ++# convert $< $@ ++ ps2pdf $< $@ + + # This was good for color; + # now let's put them in grayscale for the PostScript manual diff -Nru gri-2.12.27/debian/patches/series gri-2.12.27/debian/patches/series --- gri-2.12.27/debian/patches/series 1970-01-01 02:00:00.0 +0200 +++ gri-2.12.27/debian/patches/series 2022-08-25 19:33:47.0 +0300 @@ -0,0 +1 @@ +imagemagick.patch
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
User: tobi-rm-proposals@d.o Usertags: rm-proposal (FTR, I also don't think that snap/flatpak/appimage should be pulled by an Debian package) I agree with Olek, Ember (and friends) were always hard to keep floating in Debian, so I can understand Oleks' sentiment about maybe using snap… However this can be done by the users themselves, there is no need to have a debian package doing so. So, maybe, it is time to let ember go and remove it from Debian? It has no reverse dependencies, so it is save to do so. I'll reassign this bug to ftp.debian.org in 3 months, if there is no veto in this bug. -- tobi (Doing bug triaging on games team packages) signature.asc Description: PGP signature
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Freitag, dem 26.08.2022 um 09:52 +0200 schrieb Roland Rosenfeld: > Just go for it. I have just uploaded fonts-urw-base35_20200910-2 to experimental which takes over the gsfonts and gsfonts-x11 packages. So, if you guys could check if the transition works out for you as expected, that'd be appreciated. Thanks! - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKCiYACgkQy+qOlwzN Wd/wnhAAwwgzhqlgOuioHah1qrqaNeJZIasP1oQ7uPFq6wKDkKSGSMP4pvR2rNSp GHtdh+PzCij/5ADfEl8wEB0b3kkVmKhPPH8uMmUH4TZW+YxBypem6fsLAP7P0cSH kUeFMqjmQFQtuB1rcjT2UXQS5daG/UYE2f5RMxOsh5zxx5Wja4NAYUdOm2qdrLQG 73zczLWK3rX7+jJh7nEn48IjC8LmRAOr77tOnazVhWMjGIuEQqJ+klKaRFz8jY0R rb1LvWves+kpwMmNW8G+GoTrUqhArHqngAWszq6eW/A+VeBM9ZZdDTrmwVOhCoeO csh+y11e2QIlzJsZ8fp3KI/8UDfOBD5RmzlfvTVfYc+V/Zs0eh6DXhcrfYFJIeGZ TAiRm4eEKlqzZF2kdwn5mQsrmgVoSC8Ox/qLgVS9FCwVDCqjYQIb9mTDnS+td5gS +gvbZOruEdQd1pcRhcA+z3Dvi4c9DCsR3ixre8f2iWmhw07HFT7IGBGqy7+kz8nL JA/uSzrMTDg7Kyzsx0GAVOmhxABFur6Cy23iRW4btsJGij7GdMggRIBjIfs1CsMD 91nV96GsPbLXM/HUrr7XBmTrDFaMTdtgmyp0zbDVRFfDas8mFBt3BDBc3JofLVv3 RALcjqc3AdfpJZtlELV/SYR1Y9RXI+WzafRDN87Jrg8VxRiqy50= =aC/0 -END PGP SIGNATURE-
Bug#1018226: bullseye-pu: package dlt-daemon/2.18.6-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Aigars Mahinovs
* CVE-2022-31291: Double free in dlt_config_file_set_section().
(Closes: #1014534)
diff -Nru dlt-daemon-2.18.6/debian/changelog dlt-daemon-2.18.6/debian/changelog
--- dlt-daemon-2.18.6/debian/changelog 2021-01-09 15:18:44.0 +0200
+++ dlt-daemon-2.18.6/debian/changelog 2022-08-27 14:59:10.0 +0300
@@ -1,3 +1,11 @@
+dlt-daemon (2.18.6-1+deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * CVE-2022-31291: Double free in dlt_config_file_set_section().
+(Closes: #1014534)
+
+ -- Adrian Bunk Sat, 27 Aug 2022 14:59:10 +0300
+
dlt-daemon (2.18.6-1) unstable; urgency=medium
* Update to new release
diff -Nru dlt-daemon-2.18.6/debian/patches/0001-Fix-a-double-free-bug.patch
dlt-daemon-2.18.6/debian/patches/0001-Fix-a-double-free-bug.patch
--- dlt-daemon-2.18.6/debian/patches/0001-Fix-a-double-free-bug.patch
1970-01-01 02:00:00.0 +0200
+++ dlt-daemon-2.18.6/debian/patches/0001-Fix-a-double-free-bug.patch
2022-08-18 19:36:47.0 +0300
@@ -0,0 +1,29 @@
+From 6a3bd901d825c7206797e36ea98e10a218f5aad2 Mon Sep 17 00:00:00 2001
+From: Safe-BCY <512234...@qq.com>
+Date: Thu, 5 May 2022 06:47:17 +0800
+Subject: Fix a double-free bug.
+
+In the dlt_config_file_set_section function of dlt_config_file_parser.c:
+ s-name is not set to null after free.
+ It will be freed again in the dlt_config_file_release function.
+
+Signed-off-by: Zhongyang.Bao
+---
+ src/shared/dlt_config_file_parser.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/shared/dlt_config_file_parser.c
b/src/shared/dlt_config_file_parser.c
+index 009a093..fc2d516 100644
+--- a/src/shared/dlt_config_file_parser.c
b/src/shared/dlt_config_file_parser.c
+@@ -148,6 +148,7 @@ static int dlt_config_file_set_section(DltConfigFile
*file, char *name)
+
+ if (s->keys == NULL) {
+ free(s->name);
++s->name = NULL;
+ dlt_log(LOG_ERR, "Cannot allocate memory for internal data
structure\n");
+ return -1;
+ }
+--
+2.20.1
+
diff -Nru dlt-daemon-2.18.6/debian/patches/series
dlt-daemon-2.18.6/debian/patches/series
--- dlt-daemon-2.18.6/debian/patches/series 1970-01-01 02:00:00.0
+0200
+++ dlt-daemon-2.18.6/debian/patches/series 2022-08-27 14:59:10.0
+0300
@@ -0,0 +1 @@
+0001-Fix-a-double-free-bug.patch
Bug#1018225: src:rust-rustls: fails to migrate to testing for too long: blocked by build dependency
Source: rust-rustls Version: 0.20.6-3 Severity: serious Control: close -1 0.20.6-7 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:rust-rustls has been trying to migrate for 62 days [2]. Hence, I am filing this bug. Your package build depends on rust-criterion but that's not in testing and can't migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=rust-rustls OpenPGP_signature Description: OpenPGP digital signature
Bug#1018208: RM: gnome-shell-extension-xrdesktop -- RoQA; unmaintained, depends on removed package
Control: tags -1 +moreinfo On Sat, Aug 27, 2022 at 2:34 AM Andrej Shadura wrote: > On Sat, 27 Aug 2022, at 02:44, Jeremy Bicha wrote: > > Please remove gnome-shell-extension-xrdesktop from Debian. > > > > The extension only works with gnome-shell-xrdesktop which was removed > > from Debian with https://bugs.debian.org/1008471 > > (The package depends on gnome-shell instead of gnome-shell-xrdesktop > > like it should.) > > Please hold off your horses a bit :) > There appears to be a group of people interested in maintaining this, let's > give them a chance to get properly started.> Ok, but I didn't see any discussion in the usual places. Thank you, Jeremy Bicha
Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x
Source: exempi Version: 2.6.1-2 Severity: serious Control: close -1 2.6.2-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1014061 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:exempi has been trying to migrate for 62 days [2]. Hence, I am filing this bug. Your package failed to build from source on s390x while it built the successfully in the past. Reported in bug 1014061. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=exempi OpenPGP_signature Description: OpenPGP digital signature
Bug#969482: ITP: glab -- An open-source GitLab command line tool
Package: wnpp Followup-For: Bug #969482 X-Debbugs-Cc: dreykorn.jul...@gmail.com I would also be interested in this package. But the details need to be updated. It was officially adopted by GitLab, so it has a new URL: https://gitlab.com/gitlab-org/cli Does this mean that we need a new possible maintainer, or is the original creator still willing to maintain it? Hope to see it soon in Debian. Best wishes, Julianhttps://gitlab.com/gitlab-org/cli Does this mean that we need a new possible maintainer, or is the original creator still willing to maintain it? Hope to see it soon in Debian. Best wishes, Julianhttps://gitlab.com/gitlab-org/cli Does this mean that we need a new possible maintainer, or is the original creator still willing to maintain it? Hope to see it soon in Debian. Best wishes, Julianhttps://gitlab.com/gitlab-org/cli Does this mean that we need a new possible maintainer, or is the original creator still willing to maintain it? Hope to see it soon in Debian. Best wishes, Julianhttps://gitlab.com/gitlab-org/cli Does this mean that we need a new possible maintainer, or is the original creator still willing to maintain it? Hope to see it soon in Debian. Best wishes, Julian
Bug#1018110: RFS: hydrapaper/3.3.1-1 [RC] -- Utility that sets background independently for each monitor
The missing depdencies has been filed as #1018222.
Bug#1018222: hydapaper: Missing depdencies
Package: hydrapaper
Version: 3.3.1-1
Severity: serious
During the review for the RFS I've missed that there are missing dependencies…
See Jeroen's analyis for details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018110#10
Quoting:
Program fails to start (missing dep on something to ensure gi gtk4 is
present, installing gir1.2-gtk-4.0 seems to fix that):
Traceback (most recent call last):
File "/usr/bin/hydrapaper", line 60, in
gi.require_version('Gtk', '4.0')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
require_version
raise ValueError('Namespace %s not available for version %s' %
ValueError: Namespace Gtk not available for version 4.0
Same for adw:
Traceback (most recent call last):
File "/usr/bin/hydrapaper", line 62, in
gi.require_version('Adw', '1')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Adw not available
Probably missing a dependency on python3-dbus too (imported by
hydrapaperd)? And python3-pil as mentioned earlier.
Bug#1018221: virglrenderer: release 0.9.1 to unstable
Source: virglrenderer Severity: wishlist Dear Maintainer, please consider releasing the 0.9.1 package to unstable, to allow bookworm getting a newer version before its freeze. I know the freeze is only due in a few months but as the 0.9.1 packages lingers in experimental and salsa git repo since a while now I wanted to ask rather early enough. Semi related and possibly better asked at the upstream repo, but as you're there active too: there seems to be a lot done in git since 0.9.1, is there any plan for when to do the next upstream bump? thanks Thomas
Bug#1016864: RFS: librcc/0.2.13+ds-1 [QA] -- RusXMMS Charset Conversion library
On Wed, 24 Aug 2022 22:30:26 +1000 Hugh McMaster wrote: + Update Vcs-* fields and point to GitHub. > > > > VCS* is for the packaging, not for upstream. The link on Github seems not to > > have the (latesdt) packaging > > Good point. I've dropped the Vcs-* fields, since there is no Salsa > packaging repository at the moment. > > I checked the GitHub repository and it has the latest version 0.2.13. > Older versions are available from a different (non-GitHub) repository. Fixed: I've created a repo for you on salsa, populated it from debsnap and granted rights to you. Let me know if it does not work as expected… https://salsa.debian.org/debian/librcc -- tobi
Bug#1018064: Subject: RFS: cmd2/2.4.1+ds-1 [ITA] [RC] -- Improved Python cmd2 module from (cammon documentation)
Control: tags -1 moreinfo Hi Nilson, it seems that upstream has released a new upstream version (2.4.2) recently. I'm wondering if it would make sense to update the packaging to this version or if there are special reasons to stick to the older one? (Marking this bug moreinfo until you've gave feedback; just to avoid unnecessary work... Please remove the tag with your reply.) Regarding one thing my eye spotted: You write: >* New maintainer. (Closes: #1012662, #1002341) however, #1002341 is fixing a FTBFS, so it does not "match" the entry. I guess this bug deserves its own changelog entry… Cheers, -- tobi
Bug#1017247: golang-github-gatherstars-com-jwz: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/gatherstars-com/jwz github.com/gatherstars-com/jwz/examples/visualize retur
On 8/27/22 15:32, Nilesh Patra wrote: On 8/25/22 22:47, Robin Jarry wrote: Hey Nilesh, Nilesh Patra, Aug 25, 2022 at 14:20: This bug is causing an autoremoval warning for aerc. There does not seem to be a fix upstream about this. I am not sure what exactly is triggering this, but my hunch is it might be related to change in sort function with golang 1.19. (This works fine with go-1.18) Can I ask you to take a look at it? I pushed a fix on salsa: https://salsa.debian.org/go-team/packages/golang-github-gatherstars-com-jwz/-/commit/842c69125282bdfb2725325d91d8002ce8f86891 This patch was submitted upstream: https://github.com/gatherstars-com/jwz/pull/2 If you want I can upload but you'll need to give me permission for golang-github-gatherstars-com-jwz :-) Hi, I had granted you upload access couple of days back, could you upload? Looks like you uploaded already, there was an old page in my browser cache. Sorry for the noise! -- Best, Nilesh
Bug#1018218: bugs.debian.org: Pseudo-header needed for “affects” relationship
On Sat, 2022-08-27 at 10:40 +0200, debbug.deb...@sideload.33mail.com wrote: > When composing a bug report where another package is affected by the > bug, there is no way to express that because the control command > makes > bug number a required field: > > > http://5ekxbftvqg26oir5wle3p27ax3wksbxcecnm6oemju7bjra2pn26s3qd.onion/Bugs/server-control#affects > > So you cannot write the header: > > control: affects $bugNumber $otherPkg > Yes, you can, because this: > 3) add support for a placeholder bug number like “-1” (similar to how > the clone command works) is an intrinsic part of how the "Control" pseudo-header works. Quoting https://www.debian.org/Bugs/Reporting#pseudoheader Control Commands Control: control commands Allows for any of the commands which must be sent to cont...@bugs.debian.org to work when sent to sub...@bugs.debian.org or n...@bugs.debian.org. -1 initially refers to the current bug (that is, the bug created by a mail to submit@ or the bug messaged with nnn@). I'm closing this bug as the requested feature already exists. Regards, Adam
Bug#1018220: OSError: Cannot initialize new instance of inotify, Errno=Too many open files (EMFILE)
Package: lintian-brush
Version: 0.128
Severity: important
X-Debbugs-Cc: dfo...@gmail.com
Dear maintainer,
lintian-brush is unable to process quisk.
Steps to reproduce:
git clone g...@salsa.debian.org:debian-hamradio-team/quisk.git
cd quisk
lintian-brush
Actual result:
Traceback (most recent call last):
File "/usr/bin/lintian-brush", line 33, in
sys.exit(load_entry_point('lintian-brush==0.128', 'console_scripts',
'lintian-brush')())
File "/usr/lib/python3/dist-packages/lintian_brush/__main__.py", line 333, in
main
overall_result = run_lintian_fixers(
File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 1081,
in run_lintian_fixers
dirty_tracker = get_dirty_tracker(
File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 1006,
in get_dirty_tracker
return DirtyTracker(local_tree, subpath)
File "/usr/lib/python3/dist-packages/breezy/dirty_tracker.py", line 67, in
__init__
self._wm = WatchManager()
File "/usr/lib/python3/dist-packages/pyinotify.py", line 1764, in __init__
raise OSError(err % self._inotify_wrapper.str_errno())
OSError: Cannot initialize new instance of inotify, Errno=Too many open files
(EMFILE)
The repository is at:
commit 597fa17b15f63d9524b9d61a5c82c128c35d78f1
tag: debian/4.2.2-1
Thanks for looking into this,
Daniele
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE=it:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lintian-brush depends on:
ii devscripts 2.22.2
ii python3 3.10.6-1
ii python3-breezy 3.2.2-2+b1
ii python3-debian 0.1.46
ii python3-debmutate0.54
ii python3-distro-info 1.1
ii python3-dulwich 0.20.44-1+b1
ii python3-iniparse 0.5-1
ii python3-iso8601 1.0.2-1
ii python3-ruamel.yaml 0.17.16-1
ii python3-tqdm 4.64.0-2
ii python3-upstream-ontologist 0.1.25-2
Versions of packages lintian-brush recommends:
ii debhelper13.9
ii decopy 0.2.4.7-0.2
ii dos2unix 7.4.3-1
ii gpg 2.2.35-3
ii lintian 2.115.2
ii ognibuild0.0.13-1
ii python3-asyncpg 0.25.0-2+b1
ii python3-bs4 4.11.1-1
ii python3-docutils 0.17.1+dfsg-2
ii python3-levenshtein 0.12.2-2+b2
ii python3-lxml 4.9.1-1+b1
ii python3-markdown 3.4.1-1
ii python3-pyinotify0.9.6-2
ii python3-semver 2.10.2-3
ii python3-tomlkit 0.9.2-1
Versions of packages lintian-brush suggests:
ii brz-debian 2.8.69
pn git-buildpackage
pn gnome-pkg-tools
ii po-debconf 1.0.21+nmu1
pn postgresql-common
-- no debconf information
Bug#1017247: golang-github-gatherstars-com-jwz: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/gatherstars-com/jwz github.com/gatherstars-com/jwz/examples/visualize retur
On 8/25/22 22:47, Robin Jarry wrote: Hey Nilesh, Nilesh Patra, Aug 25, 2022 at 14:20: This bug is causing an autoremoval warning for aerc. There does not seem to be a fix upstream about this. I am not sure what exactly is triggering this, but my hunch is it might be related to change in sort function with golang 1.19. (This works fine with go-1.18) Can I ask you to take a look at it? I pushed a fix on salsa: https://salsa.debian.org/go-team/packages/golang-github-gatherstars-com-jwz/-/commit/842c69125282bdfb2725325d91d8002ce8f86891 This patch was submitted upstream: https://github.com/gatherstars-com/jwz/pull/2 If you want I can upload but you'll need to give me permission for golang-github-gatherstars-com-jwz :-) Hi, I had granted you upload access couple of days back, could you upload? -- Best, Nilesh
Bug#1018110: RFS: hydrapaper/3.3.1-1 [RC] -- Utility that sets background independently for each monitor
Control: tags -1 moreinfo
On Thu, 25 Aug 2022 15:49:14 -0300
Francisco M Neto wrote:
> I am looking for a sponsor for my package hydrapaper:
hi Francisco,
took a look but this package doesn't appear ready for uploading:
* changelog: is that bug really fixed just by switching to gtk4?
There's still no dependency on python3-pil while the program is
directly importing from that module!
* copyright: missing entry for the appdata xml file (cc0).
* patches: forwarded upstream but the related merge request was
closed by yourself; why? is the patch still needed?
* watch: multiple empty lines at EOF
* control:
+ short and long description could use an update (upstream describes
the program as a "Wallpaper manager with multi monitor support";
mention additional supported desktop environments, etc.)
+ unused build-dep on python3-willow?
+ the build-dep on libwnck-3-dev appears to server no other purpose
than pulling in the dbus-1 pkgconfig file from libdbus-1-dev; if
so, you should depend on the latter directly
+ libhandy-1-0 is a hard dependency of gir1.2-handy-1 but not
imported or linked directly in hydrapaper, so no need to duplicate
that here
+ gir1.2-handy-1 itself looks isn't used at all in the new upstream
release so that should go too
+ ${shlibs:Depends} is pointless for an arch:all Python package
Program fails to start (missing dep on something to ensure gi gtk4 is
present, installing gir1.2-gtk-4.0 seems to fix that):
Traceback (most recent call last):
File "/usr/bin/hydrapaper", line 60, in
gi.require_version('Gtk', '4.0')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
require_version
raise ValueError('Namespace %s not available for version %s' %
ValueError: Namespace Gtk not available for version 4.0
Same for adw:
Traceback (most recent call last):
File "/usr/bin/hydrapaper", line 62, in
gi.require_version('Adw', '1')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Adw not available
Probably missing a dependency on python3-dbus too (imported by
hydrapaperd)? And python3-pil as mentioned earlier.
Please at least take a cursory look at upstream code when packaging
major version bumps, and test your packages on a reasonably clean
testing/unstable install before asking for sponsorship.
Consider adding some basic automated testing, as even a trivial
autopkgtest that just calls `hydrapaper --help' would have failed
with errors similar to the ones listed above.
pgp3ShOEoWh0S.pgp
Description: OpenPGP digital signature
Bug#1018219: grcc: undefined symbol: _ZN6spdlog5sinks15basic_file_sinkINS_7details10null_mutexEEC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb)
Package: gnuradio Version: 3.10.3.0-2 Severity: important The grcc tool fail in unstable. I tried to use it to build a newer version of gr-gsm, but failed: This is what I see: % /usr/bin/grcc ImportError Cannot import gnuradio. Is the Python path environment variable set correctly? All OS: PYTHONPATH Is the library path environment variable set correctly? Linux: LD_LIBRARY_PATH Windows: PATH See https://wiki.gnuradio.org/index.php/ModuleNotFoundError (/usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.3: undefined symbol: _ZN6spdlog5sinks15basic_file_sinkINS_7details10null_mutexEEC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb) Setting severity to important, as it make it hard to build extra gnuradio packages. -- Happy hacking Petter Reinholdtsen
