Bug#1050796: octave-interval tests need an update with mpfr4 4.2.1
Control: forwarded -1 https://savannah.gnu.org/bugs/?64607 Control: tags -1 + patch confirmed upstream Thank you for the bug report, Matthias. This issue has been reported in the upstream bug tracking system. The fix seems to be trivial, cf patch attached to this message. Let us see if a new upstream version of interval package for Octave is released soon. If not, I will released a patched version of octave-interval. Best, Rafael Laboissière * Matthias Klose [2023-08-29 12:20]: Package: octave-interval Version: 3.2.1-5 Severity: serious Tags: sid trixie Forwarded: https://savannah.gnu.org/bugs/index.php?64607 Affects: src:mpfr4 the octave-interval tests need an update with mpfr4 4.2.1: see https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-interval/37232402/log.gz Description: Adjust BISTs in src/intervaltotext.cc for MPFR v2.4.1 GNU MPFR had a bug in the formatting function, causing the "+" flag to be ignored for Inf and NaN. It is now honored in version 2.4.1. The BISTs in src/intervaltotext.cc are fixed for the coping with the correct behavior. Author: Rafael Laboissière Bug: https://savannah.gnu.org/bugs/?64607 Bug-Debian: https://bugs.debian.org/1050796 Forwarded: not-needed Last-Update: 2023-08-29 --- octave-interval-3.2.1.orig/src/intervaltotext.cc +++ octave-interval-3.2.1/src/intervaltotext.cc @@ -1281,7 +1281,7 @@ DEFUN_DLD (intervaltotext, args, nargout %!assert (intervaltotext (infsup (), "[cg]"), "[empty]"); %!assert (intervaltotext (infsup (-inf, inf), "[g]"), "[Entire]"); -%!assert (intervaltotext (infsup (-inf, inf), "[
Bug#1050848: pywinrm (0.3.0-4) Issue in Debain 12
Package: pywinrm Version: 0.3.0-4 Hi Team Greetings. We have recently tried upgrading to Debian 12 from Debian 11. We are now facing issues using pywinrm module. Basically we use this module with ansible to connect to our windows VM using WIN RM. This pywinrm has python3 as dependency and hence it brings python3 (3.11.2 ) version. When we further investigating we found transport.py script has an issue in below line and throws an error saying ""msg": "ntlm: module 'inspect' has no attribute 'getargspec'" argspec = set(inspect.getargspec(function).args) One solution to fix this is change getargspec with getfullargspec and it works. But this is a manual workaround for us. Is there any chance of fixing this issue in python3.11.2 and make these changes available as a part of Debian 12 ? . Kindly let us know if you need further details Thanks SAI
Bug#1043598: ovn: CVE-2023-3153
Hi, On Sun, Aug 13, 2023 at 02:12:34PM +0200, Salvatore Bonaccorso wrote: > Source: ovn > Version: 23.03.0-1 > Severity: important > Tags: security upstream > Forwarded: https://github.com/ovn-org/ovn/issues/198 > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for ovn. > > CVE-2023-3153[0]: > | service monitor MAC flow is not rate limited > > upstream is notified about [1] but is not giving more details at time > of writing. The advisory and the patch is now public: https://mail.openvswitch.org/pipermail/ovs-announce/2023-August/000327.html https://mail.openvswitch.org/pipermail/ovs-dev/2023-August/407553.html Regards, Salvatore
Bug#1050846: libvhdi: Please add support for new arch Loongarch
Package: libvhdi
Version: 20210425-1
Severity: wishlist
Tags: patch
User:debian-de...@lists.debian.org
Usertags: loongarch64
Dear maintainers,
When I compiled libvhdi for loongarch architecture, test case fail is
happened during memory check.
We have added loongarch architecture support for libvhdi, the patch
can be found in the attachment.
If you have any questions, you can contact me at any time.
--- libvhdi-20210425.orig/tests/vhdi_test_memory.h
+++ libvhdi-20210425/tests/vhdi_test_memory.h
@@ -28,7 +28,7 @@
extern "C" {
#endif
-#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( LIBVHDI_DLL_IMPORT ) && !defined( __aarch64__ ) && !defined( __alpha__ ) && !defined( __arm__ ) && !defined( __clang__ ) && !defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined( __mips__ ) && !defined( __powerpc__ ) && !defined( __ppc64__ ) && !defined( __ppc64le__ ) && !defined( __riscv ) && !defined( __s390x__ ) && !defined( __sparc__ ) && !defined( HAVE_ASAN )
+#if defined( HAVE_GNU_DL_DLSYM ) && defined( __GNUC__ ) && !defined( LIBVHDI_DLL_IMPORT ) && !defined( __aarch64__ ) && !defined( __alpha__ ) && !defined( __arm__ ) && !defined( __clang__ ) && !defined( __CYGWIN__ ) && !defined( __hppa__ ) && !defined(__loongarch__) && !defined( __mips__ ) && !defined( __powerpc__ ) && !defined( __ppc64__ ) && !defined( __ppc64le__ ) && !defined( __riscv ) && !defined( __s390x__ ) && !defined( __sparc__ ) && !defined( HAVE_ASAN )
#define HAVE_VHDI_TEST_MEMORY 1
#endif
Bug#1050833: release-notes: Bookworm renames network interfaces
Rainer Dorsch wrote: > I did a test installation with a bullseye installer on a cubox-i > (armhf architecture) and then upgraded to bookworm. After the upgrade > the network was gone. Even booting with the previous kernel > 5.10.0-23-armmp does not bring the network back. > > After some more investigation, I found that the network interfaces got > renamed from eth0 to end0, which required manual modifications in my > /etc/network/interfaces file. Fortunately, I did this test before > upgrading production systems. Are you saying that armhf machines still used one of the old interface naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on bullseye, and hadn't yet switched over to "predictable" names? For the architectures I know anything about, interface names like eth0 disappeared quite a while ago, with particular warnings in the stretch and buster release notes: https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#new-interface-names https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names If the sequence of events has been different on armhf, that might need a new entry in the "Complications and corner cases" section of the wiki page. The question is, how exactly did you come to be still using "eth0" in a bullseye /etc/network/interfaces file? > On one of my production systems the renaming also broke the packages > shorewall, dnsmasq, and some custom scripts. > > On the debian-arm mailing list the topic was discussed in this threat: > > https://lists.debian.org/debian-arm/2023/08/msg3.html > > Suggestions in the thread: > - Try adding "net.ifnames=0" to kernel's commandline. > - Adding a statement to the release notes like "did you know your > interface name will change after the reboot thus possibly breaking > your network configuration?" > - Add a warning to debconf which the user has to confirm during the > upgrade > - ifupdown can do interface name wildcards and mac matching. The > other solutions for this problem (systemd-networkd, NetworkManager, > ifupdown-ng, probably ifupdown2) -> but this solves only part of the > problem, e.g. neither dnsmasq and shorewall are not covered nor custom > scripts If you're worried about "predictable" names making things unpredictable, the canonical solution is to set up a .link file specifying how you want the crucial interface(s) to be named. See the section "CUSTOM SCHEMES USING .LINK FILES". > Adding a prominent warning to the release notes should a low hanging > fruit and would have helped me. Likely I would not have run in the > issue in the first place or at least the debugging would have been > easier :-) Sure, *if* the change was in bookworm. But if people didn't read the stretch and buster release notes, why would we expect a warning in the bookworm release notes to do any good? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1050845: mpi-defaults: Please add support for loongarch64
Package: mpi-defaults
Version: 1.14
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64
Dear maintainers,
Please add support for loongarch64 (64-bit LoongArch) in mpi-defaults,
default to openmpi. And loong64 is dpkg architecture for loongarch64.
I have compiled the packages on local Debian system as follows
mpi-default-bin_1.14_loong64.deb
mpi-default-dev_1.14_loong64.deb
Please consider the patch attached.
For ease of viewing, you can also review the following link [1].
If you have any questions, you can contact me at any time.
[1]:https://salsa.debian.org/science-team/mpi-defaults/-/merge_requests/1
thanks,
Dandan Zhang
diff -Nru mpi-defaults-1.14/debian/control mpi-defaults-1.14/debian/control
--- mpi-defaults-1.14/debian/control2021-08-04 13:43:05.0 +
+++ mpi-defaults-1.14/debian/control2021-08-04 13:46:55.0 +
@@ -10,8 +10,8 @@
Alastair McKinstry ,
Build-Depends:
debhelper-compat (= 13),
- libopenmpi-dev (>= 1.4.3-2.1) [alpha amd64 arm64 armel armhf hppa hurd-i386
i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc
powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32],
- openmpi-bin (>= 1.4.3-2.1) [alpha amd64 arm64 armel armhf hppa hurd-i386 i386
ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe
ppc64 ppc64el riscv64 s390x sh4 sparc64 x32],
+ libopenmpi-dev (>= 1.4.3-2.1) [alpha amd64 arm64 armel armhf hppa hurd-i386
i386 ia64 kfreebsd-amd64 kfreebsd-i386 loong64 m68k mips mips64el mipsel
powerpc powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32],
+ openmpi-bin (>= 1.4.3-2.1) [alpha amd64 arm64 armel armhf hppa hurd-i386 i386
ia64 kfreebsd-amd64 kfreebsd-i386 loong64 m68k mips mips64el mipsel powerpc
powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32],
# libmpich-dev [],
# mpich []
Rules-Requires-Root: no
@@ -20,7 +20,7 @@
Vcs-Git: https://salsa.debian.org/science-team/mpi-defaults.git
Package: mpi-default-dev
-Architecture: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64
kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64
ppc64el riscv64 s390x sh4 sparc64 x32
+Architecture: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64
kfreebsd-amd64 kfreebsd-i386 loong64 m68k mips mips64el mipsel powerpc
powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
Section: libdevel
Depends: ${mpi-dev}, ${misc:Depends}
Description: Standard MPI development files (metapackage)
@@ -31,7 +31,7 @@
compilers mpicc, mpic++/mpicxx/mpiCC, mpif77 and mpi90 and their manpages.
Package: mpi-default-bin
-Architecture: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64
kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64
ppc64el riscv64 s390x sh4 sparc64 x32
+Architecture: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64
kfreebsd-amd64 kfreebsd-i386 loong64 m68k mips mips64el mipsel powerpc
powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
Section: net
Depends: ${mpi}, ${misc:Depends}
Description: Standard MPI runtime programs (metapackage)
diff -Nru mpi-defaults-1.14/debian/rules mpi-defaults-1.14/debian/rules
--- mpi-defaults-1.14/debian/rules 2021-08-04 13:43:02.0 +
+++ mpi-defaults-1.14/debian/rules 2021-08-04 13:46:55.0 +
@@ -21,6 +21,7 @@
ia64 \
kfreebsd-amd64 \
kfreebsd-i386 \
+ loong64 \
mips \
mips64el \
mipsel \
@@ -47,6 +48,7 @@
ia64 \
kfreebsd-amd64 \
kfreebsd-i386 \
+ loong64 \
m68k \
mips \
mips64el \
@@ -76,6 +78,7 @@
ia64 \
kfreebsd-amd64 \
kfreebsd-i386 \
+ loong64 \
m68k \
mips \
mips64el \
Bug#1050844: xutils-dev: Please add support for new arch Loongarch
Package: xutils-dev Version: 7.7+6.1 Severity: wishlist Tags: patch User:debian-de...@lists.debian.org Usertags: loongarch64 Dear maintainers, When I compiled kdrill for loongarch architecture, the error message is happened for lacking of loongarch machine defined in xutils-dev. We have added loongarch architecture support for xutils-dev, the patch can be found in the attachment. If you have any questions, you can contact me at any time. diff --git a/xorg-cf-files/Imake.cf b/xorg-cf-files/Imake.cf index e2e4f1b..164e47f 100644 --- a/xorg-cf-files/Imake.cf +++ b/xorg-cf-files/Imake.cf @@ -1037,6 +1037,18 @@ XCOMM Keep cpp from replacing path elements containing i486/i586/i686 # define AArch64Architecture # undef __aarch64__ # endif +# if defined(__loongarch__) +# undef __loongarch__ +# if __loongarch_grlen == 64 +# undef __loongarch_grlen +# undef __loongarch_lp64 +# define LoongArch64Architecture +# endif +# if __loongarch_grlen == 32 +# undef __loongarch_grlen +# define LoongArch32Architecture +# endif +# endif # if defined(__riscv) && (__riscv_xlen == 64) # define RISCV64Architecture # /* undef __riscv */ diff --git a/xorg-cf-files/linux.cf b/xorg-cf-files/linux.cf index fb5924d..6209639 100644 --- a/xorg-cf-files/linux.cf +++ b/xorg-cf-files/linux.cf @@ -1117,6 +1117,25 @@ InstallNamedTargetNoClobber(install,file.ad,$(INSTAPPFLAGS),$(XAPPLOADDIR),class # define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines -D_XSERVER64 #endif /* AArch64Architecture */ +#ifdef LoongArch64Architecture +# ifndef OptimizedCDebugFlags +# define OptimizedCDebugFlags -O2 GccAliasingArgs +# endif +# define LinuxMachineDefines -D__loongarch__ -D__loongarch_grlen=64 -D__loongarch_lp64 +# define ServerOSDefines XFree86ServerOSDefines -DDDXTIME +# define ServerExtraDefines -DGCCUSESGAS XFree86ServerDefines -D_XSERVER64 +#endif /* LoongArch64Architecture */ + +#ifdef LoongArch32Architecture +# ifndef OptimizedCDebugFlags +# define OptimizedCDebugFlags -O2 GccAliasingArgs +# endif +# define LinuxMachineDefines -D__loongarch__ -D__loongarch_grlen=32 +# define ServerOSDefines XFree86ServerOSDefines -DDDXTIME +# define ServerExtraDefines -DGCCUSESGAS XFree86ServerDefines +#endif /* LoongArch32Architecture */ + + #ifdef RISCV64Architecture # ifndef OptimizedCDebugFlags # define OptimizedCDebugFlags DefaultGcc2RISCV64Opt DefaultGcc2OptimizeOpt GccAliasingArgs
Bug#1050843: Use-after-free crash when deallocating a frame object
Here’s a debdiff for 3.11.2-6 in bookworm adding the upstream patch. Anders From: Anders Kaseorg Sent: Tuesday, August 29, 2023 19:12 To: sub...@bugs.debian.org Subject: Use-after-free crash when deallocating a frame object Package: python3.11 Version: 3.11.2-6 Tags: bookworm fixed-upstream patch upstream Python 3.11.0 through 3.11.4 have a use-after-free condition when deallocating a stack frame object, manifesting as a SIGSEGV crash under certain conditions on the current position of the stack pointer and the number and depth of allocated objects. This potentially affects any Python application, and is known to affect the Zulip chat server. This is a regression from 3.10.x (hence also from 3.9.x in Debian 11), and is fixed in 3.11.5 which is now in Debian testing. Please apply this fix in Debian 12. Upstream issue: https://github.com/python/cpython/issues/106092 Test case: https://github.com/andersk/python-segfault Patch from 3.11.5: https://github.com/python/cpython/pull/107533 Thanks, Anders python3.11_3.11.2-6_frame_dealloc.debdiff Description: python3.11_3.11.2-6_frame_dealloc.debdiff
Bug#1050843: Use-after-free crash when deallocating a frame object
Package: python3.11 Version: 3.11.2-6 Tags: bookworm fixed-upstream patch upstream Python 3.11.0 through 3.11.4 have a use-after-free condition when deallocating a stack frame object, manifesting as a SIGSEGV crash under certain conditions on the current position of the stack pointer and the number and depth of allocated objects. This potentially affects any Python application, and is known to affect the Zulip chat server. This is a regression from 3.10.x (hence also from 3.9.x in Debian 11), and is fixed in 3.11.5 which is now in Debian testing. Please apply this fix in Debian 12. Upstream issue: https://github.com/python/cpython/issues/106092 Test case: https://github.com/andersk/python-segfault Patch from 3.11.5: https://github.com/python/cpython/pull/107533 Thanks, Anders
Bug#1050837: [Pkg-utopia-maintainers] Bug#1050837: udisks2.service does not start, timeout after ~3 minutes
See https://github.com/storaged-project/udisks/issues/1152 > Am 29.08.2023 um 23:06 schrieb Jens Arnold : > > Package: udisks2 > Version: 2.10.0-5 > Severity: important > > Dear Maintainer, > > since upgrading to udisks2 2.10 and libblockdev3, udisks2 fails to start on my > system: > > root@jupiter:~# systemctl status udisks2.service > × udisks2.service - Disk Manager > Loaded: loaded (/lib/systemd/system/udisks2.service; enabled; preset: > enabled) > Active: failed (Result: timeout) since Tue 2023-08-29 22:13:24 CEST; 43min > ago > Docs: man:udisks(8) >Process: 257578 ExecStart=/usr/libexec/udisks2/udisksd (code=killed, > signal=KILL) > Main PID: 257578 (code=killed, signal=KILL) >CPU: 3min 1.809s > > Aug 29 22:10:22 jupiter systemd[1]: Starting udisks2.service - Disk Manager... > Aug 29 22:10:22 jupiter udisksd[257578]: udisks daemon version 2.10.0 starting > Aug 29 22:11:52 jupiter systemd[1]: udisks2.service: start operation timed > out. > Terminating. > Aug 29 22:13:23 jupiter systemd[1]: udisks2.service: State 'stop-sigterm' > timed > out. Killing. > Aug 29 22:13:23 jupiter systemd[1]: udisks2.service: Killing process 257578 > (udisksd) with signal SIGKILL. > Aug 29 22:13:23 jupiter systemd[1]: udisks2.service: Killing process 257594 > (n/a) with signal SIGKILL. > Aug 29 22:13:24 jupiter systemd[1]: udisks2.service: Main process exited, > code=killed, status=9/KILL > Aug 29 22:13:24 jupiter systemd[1]: udisks2.service: Failed with result > 'timeout'. > Aug 29 22:13:24 jupiter systemd[1]: Failed to start udisks2.service - Disk > Manager. > Aug 29 22:13:24 jupiter systemd[1]: udisks2.service: Consumed 3min 1.809s CPU > time. > > This might be related to the newly added NVMe support, however, it doesn't > happen on a VMware test VM with an NVMe controller. I've tried to start > udisksd > manually with strace: > > # strace > udisks2.txt 2>&1 /usr/libexec/udisks2/udisksd > > The output will be attached. > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages udisks2 depends on: > ii dbus 1.14.8-2 > ii libacl12.3.1-3 > ii libatasmart4 0.19-5 > ii libblkid1 2.39.2-1 > ii libblockdev-crypto33.0.2-3 > ii libblockdev-fs33.0.2-3 > ii libblockdev-loop3 3.0.2-3 > ii libblockdev-mdraid33.0.2-3 > ii libblockdev-nvme3 3.0.2-3 > ii libblockdev-part3 3.0.2-3 > ii libblockdev-swap3 3.0.2-3 > ii libblockdev-utils3 3.0.2-3 > ii libblockdev3 3.0.2-3 > ii libc6 2.37-7 > ii libglib2.0-0 2.77.2-1 > ii libgudev-1.0-0 238-2 > ii libmount1 2.39.2-1 > ii libpolkit-agent-1-0123-1 > ii libpolkit-gobject-1-0 123-1 > ii libsystemd0254.1-3 > ii libudisks2-0 2.10.0-5 > ii libuuid1 2.39.2-1 > ii parted 3.6-3 > ii udev 254.1-3 > > Versions of packages udisks2 recommends: > ii dosfstools 4.2-1 > ii e2fsprogs 1.47.0-2 > ii eject 2.39.2-1 > ii exfatprogs 1.2.1-2 > ii libpam-systemd 254.1-3 > ii ntfs-3g 1:2022.10.3-1+b1 > ii polkitd 123-1 > > Versions of packages udisks2 suggests: > ii btrfs-progs6.3.2-1 > ii f2fs-tools 1.16.0-1 > ii mdadm 4.2+20230508-7 > pn nilfs-tools > ii reiserfsprogs 1:3.6.27-6 > ii udftools 2.3-1 > pn udisks2-btrfs > pn udisks2-lvm2 > ii xfsprogs 6.4.0-1 > > -- no debconf information > > ___ > Pkg-utopia-maintainers mailing list > pkg-utopia-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
On Tue, Aug 29, 2023 at 05:09:32PM +0200, Sebastien Bacher wrote: > And as a follow up it's not only an autopkgtest issue, surf fails to > render any webpage on my Ubuntu mantic system with the new webkitgtk > installed I cannot reproduce the problem in Debian with libwebkit2gtk-4.1-0 2.41.91-1, it seems to work fine. What happens if you use the MiniBrowser directly instead of surf? $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser https://www.debian.org/ Berto
Bug#1050841: [IMPORTANT] Debian images no longer works for GPU driver installation with apt update
Package: apt Version: 2.2.4 Severity: important File: /usr/bin/apt Dear Maintainer, Google's GPU driver installation no longer works for Debian images since 08/23/2023. Google is using https://cloud.google.com/compute/docs/gpus/install-drivers-gpu#installation_scripts to install GPU drivers on Debian images. It executes scripts as https://raw.githubusercontent.com/GoogleCloudPlatform/compute-gpu-installation/main/linux/install_gpu_driver.py. Now for the latest images, if running scripts as below: ``` $ apt-cache search linux-headers | grep -i $(uname -r) $ apt update $apt install -y linux-headers-5.10.0-24-cloud-amd64 software-properties-common pciutils gcc make dkms ``` After running `apt update`, we find the package linux-headers-5.10.0-24-cloud-amd64 no longer exists, which results in the `apt install linux-headers-5.10.0-24-cloud-amd64` failure. It seems after the `apt update`, the index somehow no longer points to linux-headers-5.10.0-23-cloud-amd64 and linux-headers-5.10.0-24-cloud-amd64. I know it would work if we (1) not do `apt update`, or (2) install newer kernel packages. But for (1), the apt update is required for our other package installations, (2) the kernel package update needs VM rebooting. It is now blocking our product functionality because we need the GPU driver installation without VM rebooting. Could you please prioritize the issue and provide some tips or support? I am using projects/debian-cloud/global/images/debian-11-bullseye-v20230814 with Linux instance-2 5.10.0-24-cloud-amd64 #1 SMP Debian 5.10.179-5 (2023-08-08) x86_64 GNU/Linux. Thanks!
Bug#940328: O: keepassx -- Cross Platform Password Manager
keepassxc is already present in debian and maintained (https://tracker.debian.org/pkg/keepassxc) FTR I used to used to use keepassx (I still have it installed - but haven't used it for years). I switched to keepassxc some time ago. My experience was that it was a drop in replacement. There was no transition, just point it at your existing db and everything "just works". Regards, Jeremy OpenPGP_signature Description: OpenPGP digital signature
Bug#1050840: nfs-common: Server no longer listens on UDP port 2049 by default
Package: nfs-common Version: 1:2.6.2-4 Severity: normal X-Debbugs-Cc: jasmine.n...@outlook.com I upgraded my NFS server from Debian bullseye to bookworm and found that NFSv3 clients were no longer mounting exports from the upgraded server. The cause appears to be an undocumented change introduced by the default /etc/nfs.conf which does not override udp=n in the [nfsd] section. This configures the NFS server in Debian bookworm to not listen on UDP port 2049. Setting this to udp=y restores the default seen in Debian bullseye where the NFS server listens on both TCP and UDP port 2049. Of course the clients could be set to connect using TCP instead. It feels like this should be documented in the changelog. Jasmine Ngan -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 60952 status 1000241 tcp 40843 status 151 udp 44273 mountd 151 tcp 35625 mountd 152 udp 52968 mountd 152 tcp 48431 mountd 153 udp 43718 mountd 153 tcp 45947 mountd 133 tcp 2049 nfs 134 tcp 2049 nfs 1002273 tcp 2049 nfs_acl 1000211 udp 58660 nlockmgr 1000213 udp 58660 nlockmgr 1000214 udp 58660 nlockmgr 1000211 tcp 40979 nlockmgr 1000213 tcp 40979 nlockmgr 1000214 tcp 40979 nlockmgr -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/nfs.conf -- [general] pipefs-directory=/run/rpc_pipefs [nfsrahead] [exports] [exportfs] [gssd] [lockd] [exportd] [mountd] manage-gids=y [nfsdcld] [nfsdcltrack] [nfsd] [statd] [sm-notify] [svcgssd] -- /etc/nfs.conf.d/*.conf -- -- /etc/idmapd.conf -- [General] Verbosity = 0 [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- -- /proc/mounts -- nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nfs-common depends on: ii adduser3.134 ii init-system-helpers1.65.2 ii keyutils 1.6.3-2 ii libc6 2.36-9+deb12u1 ii libcap21:2.66-4 ii libcom-err21.47.0-2 ii libdevmapper1.02.1 2:1.02.185-2 ii libevent-core-2.1-72.1.12-stable-8 ii libgssapi-krb5-2 1.20.1-2 ii libkeyutils1 1.6.3-2 ii libkrb5-3 1.20.1-2 ii libmount1 2.38.1-5+b1 ii libnfsidmap1 1:2.6.2-4 ii libtirpc3 1.3.3+ds-1 ii libwrap0 7.6.q-32 ii python33.11.2-1+b1 ii rpcbind1.2.6-6+b1 ii sysvinit-utils [lsb-base] 3.06-4 ii ucf3.0043+nmu1 nfs-common recommends no packages. Versions of packages nfs-common suggests: pn open-iscsi pn watchdog Versions of packages nfs-kernel-server depends on: ii keyutils 1.6.3-2 ii libblkid1 2.38.1-5+b1 ii libc6 2.36-9+deb12u1 ii libcap21:2.66-4 ii libevent-core-2.1-72.1.12-stable-8 ii libsqlite3-0 3.40.1-2 ii libtirpc3 1.3.3+ds-1 ii libuuid1 2.38.1-5+b1 ii libwrap0 7.6.q-32 ii netbase6.4 ii sysvinit-utils [lsb-base] 3.06-4 ii ucf3.0043+nmu1 Versions of packages nfs-kernel-server recommends: ii python3 3.11.2-1+b1 ii python3-yaml 6.0-3+b2 Versions of packages nfs-kernel-server suggests: ii procps 2:4.0.2-3 -- no debconf information
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
On 2023-08-29, Diederik de Haas wrote: > Upstream recently added support for the following Pine64 Quartz64 devices: > - Quartz64 Model A > - Quartz64 Model B > - SoQuartz on Model A board > - SoQuartz on Blade board > - SoQuartz on CM4 IO carrier board Would you or someone else be willing to be listed as a tester for these boards? https://wiki.debian.org/U-boot/ > Link: > https://source.denx.de/u-boot/u-boot/-/tree/master/board/pine64/quartz64_rk3566 > > Hereby the request to package them for Debian. Presuming they are similar to the other rockchip arm64 targets, could you provide a basic patch and test one or more of the above platforms to work? For example, the rock64-rk3328: https://salsa.debian.org/debian/u-boot/-/blob/debian/latest/debian/targets.mk#L109 Although, you will likely first need to enable in arm-trusted-firmware, as that is usually a build-dependency for u-boot on rockchip platforms. live well, vagrant signature.asc Description: PGP signature
Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String
On 2023-08-29 22:45:40 +0200, Francesco Poli wrote:
> On Sun, 2 Apr 2023 23:18:57 +0200 Vincent Lefevre wrote:
>
> > On 2023-04-02 17:32:29 +0200, Francesco Poli wrote:
> > > On Thu, 30 Mar 2023 01:02:00 +0200 Vincent Lefevre wrote:
> > >
> > > > On 2023-03-29 14:25:23 -0300, Antonio Terceiro wrote:
> > > [...]
> > > > > If anyone can still see this bug, it would be nice to configure
> > > > > apt-listbugs in debug mode, e.g. setting
> > > > >
> > > > > DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt";};
> > > > >
> > > > > in /etc/apt/apt.conf.d/10apt-listbugs (i.e. adding the `-d` option),
> > > > > so
> > > > > that when it happens we have a trace of the requests/reponses.
> > > >
> > > > Is it possible to redirect (only) the debug data to a file?
> > > > Otherwise that's too invasive.
> > >
> > > All (well, almost all) debug output goes to stderr, so, yes, it should
> > > be possible to redirect only the debug data to a file.
> > >
> > > I think that
> > >
> > > DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt 2>
> > > /tmp/apt-listbugs.err";};
> > >
> > > should achieve that goal.
> >
> > But then, how can one get the error messages (which are still
> > important) in the terminal?
>
> Maybe the following could achieve this goal:
>
> DPkg::Pre-Install-Pkgs {"/usr/bin/bash -c '/usr/bin/apt-listbugs -d apt 2>
> >(/usr/bin/tee /tmp/apt-listbugs.err)'";};
> DPkg::Tools::Options::/usr/bin/bash "";
> DPkg::Tools::Options::/usr/bin/bash::Version "3";
> DPkg::Tools::Options::/usr/bin/bash::InfoFD "20";
I don't see how this would separate the debug messages from the
error messages. I recall that I do *not* want the debug data on
the screen.
--
Vincent Lefèvre - Web:
Bug#1000016: mp3splt: depends on obsolete pcre3 library
I am uploading a NMU in order to fix this (by dropping pcre support).diff -Nru mp3splt-2.6.2+20170630/debian/changelog mp3splt-2.6.2+20170630/debian/changelog --- mp3splt-2.6.2+20170630/debian/changelog 2021-01-06 17:59:57.0 +0100 +++ mp3splt-2.6.2+20170630/debian/changelog 2023-08-29 23:53:33.0 +0200 @@ -1,3 +1,11 @@ +mp3splt (2.6.2+20170630-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Disable pcre support. +Closes: #116 + + -- Bastian Germann Tue, 29 Aug 2023 23:53:33 +0200 + mp3splt (2.6.2+20170630-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru mp3splt-2.6.2+20170630/debian/control mp3splt-2.6.2+20170630/debian/control --- mp3splt-2.6.2+20170630/debian/control 2021-01-06 17:59:02.0 +0100 +++ mp3splt-2.6.2+20170630/debian/control 2023-08-29 23:53:33.0 +0200 @@ -4,7 +4,7 @@ Maintainer: Ron Lee Build-Depends: debhelper (>= 7.0.15), libdbus-glib-1-dev, libogg-dev, libvorbis-dev, libflac-dev, libmad0-dev, - libid3tag0-dev, libltdl3-dev, libpcre3-dev, libgtk-3-dev, + libid3tag0-dev, libltdl3-dev, libgtk-3-dev, libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev, audacious-dev, libaudclient-dev, doxygen, graphviz diff -Nru mp3splt-2.6.2+20170630/debian/rules mp3splt-2.6.2+20170630/debian/rules --- mp3splt-2.6.2+20170630/debian/rules 2021-01-06 17:47:47.0 +0100 +++ mp3splt-2.6.2+20170630/debian/rules 2023-08-29 23:53:19.0 +0200 @@ -92,6 +92,7 @@ --build=$(DEB_BUILD_GNU_TYPE) \ --prefix=/usr \ --disable-maintainer-mode \ + --disable-pcre \ --enable-silent-rules \ CPPFLAGS="$(CPPFLAGS)" \ CFLAGS="$(CFLAGS)" \
Bug#1050839: providing systemd unit files and a config sample
Package: gammastep Version: 2.0.9-1 Severity: wishlist Hello, It seems upstream now contains systemd units[1], apparmor files and a config sample[2] in the source tree, which are absent from the debian package. [1]: https://gitlab.com/chinstrap/gammastep/-/tree/master/data/systemd [2]: https://gitlab.com/chinstrap/gammastep/-/blob/master/gammastep.conf.sample I have tried the systemd unit, and had to replace @bindir@ with the actual path of the bin. The unit is enabled but doesn't run after the graphical session is started (I'm running i3 with nodm, my guess is it doesn't provide the graphical-session[3] target which is needed for this unit to start, as demonstrated here with sway?[4]). [3]: https://www.freedesktop.org/software/systemd/man/systemd.special.html#graphical-session.target [4]: https://github.com/swaywm/sway/wiki/Systemd-integration For reference, see also this attempt to make systemd units work with redshift: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827098 Have a good day,
Bug#1050838: bookworm-pu: package debian-edu-install/2.12.9~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: debian-edu-inst...@packages.debian.org, debian-...@lists.debian.org Control: affects -1 + src:debian-edu-install In the course of working towards the initial release of Debian Edu 12, we have updated the debian-edu-install component. The overall idea for Debian Edu components is to bring the testing/unstable versions to bookworm as-is. The development of debian-edu-* packages currently is most and for all targetting Debian Edu 12 (aka bookworm). We are not bringing in new features, we merely work on getting Debian Edu 12 to work as it used to in Debian Edu 11. [ Reason ] The debian-edu-install packages esp. defines storage requirements for the Debian Edu Installer (being a variant of D-I). With this storage requiment various other fixes are provided. [ Impact ] If this does not get accepted, there will be no Debian Edu for bookworm. Esp. system installation from Debian's image files will fail due to wrong (too small) auto-partitioning. [ Tests ] Manual tests during installation using incomplete Debian Edu 12.0 ISO netinst images. [ Risks ] No risk for non-Debian-Edu users. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] + [ Guido Berhoerster ] + * Adjust D-I auto-partitioning sizes for bullseye and bookworm (closes: +#1038792): +- Only show profiles in make minimum-diskreq +- Add partition size data for bullseye +- Properly declare phony targets in Makefile +- Increase partition sizes for main-server (90edumain) +- Increase partition sizes for main-server + thinclient-server (91edumain+ + ltsp) +- Increase partition sizes for main-server + workstation (92edumain+ws) +- Update after running 'make update-partman-recipes' + * README: Fix measured sizes of /srv/ltsp. The above mentioned storage / partitioning size adjustments for bookworm. + [ Mike Gabriel ] + * debian-edu-profile: +- Use '=' instead of '==' in dash script. Thanks, lintian. + * lib/debian-edu-common: +- Add shebang (#!/bin/sh) to silence lintian with 'W: debian-edu-profile- + udeb udeb: executable-not-elf-or-script [lib/debian-edu-common]'. + * debian/debian-edu-profile-udeb.postinst: ++ Drop #DEBHELPER# macro. The have no effect in udeb:pkgs. Thanks, lintian. lintian clean-up, mostly. [ Other info ] None. If any more info is needed, please let us know. diff -Nru debian-edu-install-2.12.8/debian/changelog debian-edu-install-2.12.9~deb12u1/debian/changelog --- debian-edu-install-2.12.8/debian/changelog 2023-02-26 10:15:55.0 +0100 +++ debian-edu-install-2.12.9~deb12u1/debian/changelog 2023-08-29 23:10:45.0 +0200 @@ -1,3 +1,35 @@ +debian-edu-install (2.12.9~deb12u1) bookworm; urgency=medium + + * Release to bookworm. + + -- Mike Gabriel Tue, 29 Aug 2023 23:10:45 +0200 + +debian-edu-install (2.12.9) unstable; urgency=medium + + [ Guido Berhoerster ] + * Adjust D-I auto-partitioning sizes for bullseye and bookworm (closes: +#1038792): +- Only show profiles in make minimum-diskreq +- Add partition size data for bullseye +- Properly declare phony targets in Makefile +- Increase partition sizes for main-server (90edumain) +- Increase partition sizes for main-server + thinclient-server (91edumain+ + ltsp) +- Increase partition sizes for main-server + workstation (92edumain+ws) +- Update after running 'make update-partman-recipes' + * README: Fix measured sizes of /srv/ltsp. + + [ Mike Gabriel ] + * debian-edu-profile: +- Use '=' instead of '==' in dash script. Thanks, lintian. + * lib/debian-edu-common: +- Add shebang (#!/bin/sh) to silence lintian with 'W: debian-edu-profile- + udeb udeb: executable-not-elf-or-script [lib/debian-edu-common]'. + * debian/debian-edu-profile-udeb.postinst: ++ Drop #DEBHELPER# macro. The have no effect in udeb:pkgs. Thanks, lintian. + + -- Mike Gabriel Sat, 19 Aug 2023 16:32:09 +0200 + debian-edu-install (2.12.8) unstable; urgency=medium * turkish debconf translation update, thanks to Atila KOÇ. Closes: #1031667. diff -Nru debian-edu-install-2.12.8/debian/debian-edu-profile-udeb.postinst debian-edu-install-2.12.9~deb12u1/debian/debian-edu-profile-udeb.postinst --- debian-edu-install-2.12.8/debian/debian-edu-profile-udeb.postinst 2020-10-19 09:25:24.0 +0200 +++ debian-edu-install-2.12.9~deb12u1/debian/debian-edu-profile-udeb.postinst 2023-08-29 23:10:13.0 +0200 @@ -2,8 +2,6 @@ set -e -#DEBHELPER# - # Get rid of setting DEBIAN_TASKS_ONLY (introduced by pkgsel-udeb 0.45) # to allow the installation of education tasks in the target chroot, # where this setting is evaluated (since tasksel 3.39). diff -Nru debian-edu-in
Bug#1050012: pandoc: Please drop B-D libghc-regex-pcre-doc
Control: reopen -1 On Fri, 18 Aug 2023 12:39:15 +0200 Bastian Germann wrote: Please drop the unnecessary build dependency libghc-regex-pcre-doc from pandoc so that package can move out of the key packages and be autoremoved. Changing the control.in file did not have an effect on the control file. README.source suggests that the control.in file can be ignored, so most probably it is a manual step to generate "control" from it.
Bug#1050836: oggvideotools: CVE-2020-21722 CVE-2020-21723 CVE-2020-21724
Source: oggvideotools X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerabilities were published for oggvideotools. CVE-2020-21722[0]: | Buffer Overflow vulnerability in oggvideotools 0.9.1 allows remote | attackers to run arbitrary code via opening of crafted ogg file. https://sourceforge.net/p/oggvideotools/bugs/11/ CVE-2020-21723[1]: | A Segmentation Fault issue discovered | StreamSerializer::extractStreams function in streamSerializer.cpp in | oggvideotools 0.9.1 allows remote attackers to cause a denial of | service (crash) via opening of crafted ogg file. https://sourceforge.net/p/oggvideotools/bugs/10 CVE-2020-21724[2]: | Buffer Overflow vulnerability in ExtractorInformation function in | streamExtractor.cpp in oggvideotools 0.9.1 allows remaote attackers | to run arbitrary code via opening of crafted ogg file. https://sourceforge.net/p/oggvideotools/bugs/9 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-21722 https://www.cve.org/CVERecord?id=CVE-2020-21722 [1] https://security-tracker.debian.org/tracker/CVE-2020-21723 https://www.cve.org/CVERecord?id=CVE-2020-21723 [2] https://security-tracker.debian.org/tracker/CVE-2020-21724 https://www.cve.org/CVERecord?id=CVE-2020-21724 Please adjust the affected versions in the BTS as needed.
Bug#1050835: nuget: CVE-2023-29337
Source: nuget X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for nuget. CVE-2023-29337[0]: Does https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-29337 affect nuget as packaged in Debian? If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-29337 https://www.cve.org/CVERecord?id=CVE-2023-29337 Please adjust the affected versions in the BTS as needed.
Bug#1050834: libpf4j-java: CVE-2023-40826 CVE-2023-40827 CVE-2023-40828
Source: libpf4j-java X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerabilities were published for libpf4j-java. CVE-2023-40826[0]: | An issue in pf4j pf4j v.3.9.0 and before allows a remote attacker to | obtain sensitive information and execute arbitrary code via the | zippluginPath parameter. https://github.com/pf4j/pf4j/issues/536 Duplicate/similar to: https://github.com/pf4j/pf4j/issues/526 https://github.com/pf4j/pf4j/pull/538 Fixed by: https://github.com/pf4j/pf4j/commit/8e0aa198c4e652cfc1eb9e05ca9b64397f67cc72 CVE-2023-40827[1]: | An issue in pf4j pf4j v.3.9.0 and before allows a remote attacker to | obtain sensitive information and execute arbitrary code via the | loadpluginPath parameter. https://github.com/pf4j/pf4j/issues/536 https://github.com/pf4j/pf4j/pull/537 https://github.com/pf4j/pf4j/pull/538 Fixed by: https://github.com/pf4j/pf4j/commit/8e0aa198c4e652cfc1eb9e05ca9b64397f67cc72 CVE-2023-40828[2]: | An issue in pf4j pf4j v.3.9.0 and before allows a remote attacker to | obtain sensitive information and execute arbitrary code via the | expandIfZip method in the extract function. https://github.com/pf4j/pf4j/pull/537 https://github.com/pf4j/pf4j/pull/538 Fixed by: https://github.com/pf4j/pf4j/commit/8e0aa198c4e652cfc1eb9e05ca9b64397f67cc72 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-40826 https://www.cve.org/CVERecord?id=CVE-2023-40826 [1] https://security-tracker.debian.org/tracker/CVE-2023-40827 https://www.cve.org/CVERecord?id=CVE-2023-40827 [2] https://security-tracker.debian.org/tracker/CVE-2023-40828 https://www.cve.org/CVERecord?id=CVE-2023-40828 Please adjust the affected versions in the BTS as needed.
Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String
On Sun, 2 Apr 2023 23:18:57 +0200 Vincent Lefevre wrote:
> On 2023-04-02 17:32:29 +0200, Francesco Poli wrote:
> > On Thu, 30 Mar 2023 01:02:00 +0200 Vincent Lefevre wrote:
> >
> > > On 2023-03-29 14:25:23 -0300, Antonio Terceiro wrote:
> > [...]
> > > > If anyone can still see this bug, it would be nice to configure
> > > > apt-listbugs in debug mode, e.g. setting
> > > >
> > > > DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt";};
> > > >
> > > > in /etc/apt/apt.conf.d/10apt-listbugs (i.e. adding the `-d` option), so
> > > > that when it happens we have a trace of the requests/reponses.
> > >
> > > Is it possible to redirect (only) the debug data to a file?
> > > Otherwise that's too invasive.
> >
> > All (well, almost all) debug output goes to stderr, so, yes, it should
> > be possible to redirect only the debug data to a file.
> >
> > I think that
> >
> > DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt 2>
> > /tmp/apt-listbugs.err";};
> >
> > should achieve that goal.
>
> But then, how can one get the error messages (which are still
> important) in the terminal?
Maybe the following could achieve this goal:
DPkg::Pre-Install-Pkgs {"/usr/bin/bash -c '/usr/bin/apt-listbugs -d apt 2>
>(/usr/bin/tee /tmp/apt-listbugs.err)'";};
DPkg::Tools::Options::/usr/bin/bash "";
DPkg::Tools::Options::/usr/bin/bash::Version "3";
DPkg::Tools::Options::/usr/bin/bash::InfoFD "20";
I tried it in a chroot, and it seems to work as intended.
Inspiration from
By the way, has anyone experienced this bug again, recently?
Or should I close it as unreproducible?
Please let me know, thanks!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpXC0tOrylVg.pgp
Description: PGP signature
Bug#1050833: release-notes: Bookworm renames network interfaces
Package: release-notes Severity: normal Dear Maintainer, I did a test installation with a bullseye installer on a cubox-i (armhf architecture) and then upgraded to bookworm. After the upgrade the network was gone. Even booting with the previous kernel 5.10.0-23-armmp does not bring the network back. After some more investigation, I found that the network interfaces got renamed from eth0 to end0, which required manual modifications in my /etc/network/interfaces file. Fortunately, I did this test before upgrading production systems. On one of my production systems the renaming also broke the packages shorewall, dnsmasq, and some custom scripts. On the debian-arm mailing list the topic was discussed in this threat: https://lists.debian.org/debian-arm/2023/08/msg3.html Suggestions in the thread: - Try adding "net.ifnames=0" to kernel's commandline. - Adding a statement to the release notes like "did you know your interface name will change after the reboot thus possibly breaking your network configuration?" - Add a warning to debconf which the user has to confirm during the upgrade - ifupdown can do interface name wildcards and mac matching. The other solutions for this problem (systemd-networkd, NetworkManager, ifupdown-ng, probably ifupdown2) -> but this solves only part of the problem, e.g. neither dnsmasq and shorewall are not covered nor custom scripts Adding a prominent warning to the release notes should a low hanging fruit and would have helped me. Likely I would not have run in the issue in the first place or at least the debugging would have been easier :-)
Bug#1050832: sarsen: autopkgtest needs update for python-xarray 2023.08.0
Source: sarsen
Version: 0.9.3+ds-2
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
Since the upload of python-xarray 2023.08.0-1, the autopkgtests of
sarsen are failing [1]. I've copied what I hope is the relevant part
of the log below.
Regards
Graham
[1] https://ci.debian.net/packages/s/sarsen/testing/amd64/
54s === FAILURES
===
54s test_compute_dem_oriented_area
54s
54s dem_raster =
54s [129600 values with dtype=float32]
54s Coordinates:
54s * x(x) float6405
54s spatial_ref int64 ...
54s Attributes:
54s AREA_OR_POINT: Area
54s units: m
54s long_name: elevation
54s
54s def test_compute_dem_oriented_area(dem_raster: xr.DataArray) -> None:
54s dem_3d = scene.convert_to_dem_3d(dem_raster)
54s
54s > res = scene.compute_dem_oriented_area(dem_3d)
54s
54s ../build.cju/src/tests/test_10_scene.py:39:
54s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
54s /usr/lib/python3/dist-packages/sarsen/scene.py:110: in
compute_dem_oriented_area
54s cross_2 = xr.cross(dx2, dy2, dim="axis") / 2
54s /usr/lib/python3/dist-packages/xarray/core/computation.py:1609: in cross
54s c = apply_ufunc(
54s /usr/lib/python3/dist-packages/xarray/core/computation.py:1197:
in apply_ufunc
54s return apply_dataarray_vfunc(
54s /usr/lib/python3/dist-packages/xarray/core/computation.py:288: in
apply_dataarray_vfunc
54s args = deep_align(
54s /usr/lib/python3/dist-packages/xarray/core/alignment.py:847: in deep_align
54s aligned = align(
54s /usr/lib/python3/dist-packages/xarray/core/alignment.py:783: in align
54s aligner.align()
54s /usr/lib/python3/dist-packages/xarray/core/alignment.py:568: in align
54s self.align_indexes()
54s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
54s
54s self =
54s
54s def align_indexes(self) -> None:
54s """Compute all aligned indexes and their corresponding
coordinate variables."""
54s
54s aligned_indexes = {}
54s aligned_index_vars = {}
54s reindex = {}
54s new_indexes = {}
54s new_index_vars = {}
54s
54s for key, matching_indexes in self.all_indexes.items():
54s matching_index_vars = self.all_index_vars[key]
54s dims = {d for coord in
matching_index_vars[0].values() for d in coord.dims}
54s index_cls = key[1]
54s
54s if self.join == "override":
54s joined_index = matching_indexes[0]
54s joined_index_vars = matching_index_vars[0]
54s need_reindex = False
54s elif key in self.indexes:
54s joined_index = self.indexes[key]
54s joined_index_vars = self.index_vars[key]
54s cmp_indexes = list(
54s zip(
54s [joined_index] + matching_indexes,
54s [joined_index_vars] + matching_index_vars,
54s )
54s )
54s need_reindex = self._need_reindex(dims, cmp_indexes)
54s else:
54s if len(matching_indexes) > 1:
54s need_reindex = self._need_reindex(
54s dims,
54s list(zip(matching_indexes, matching_index_vars)),
54s )
54s else:
54s need_reindex = False
54s if need_reindex:
54s if self.join == "exact":
54s > raise ValueError(
54s "cannot align objects with join='exact' where "
54s "index/labels/sizes are not equal along "
54s "these coordinates (dimensions): "
54s + ", ".join(f"{name!r} {dims!r}" for
name, dims in key[0])
54s )
54s E ValueError: cannot align objects with
join='exact' where index/labels/sizes are not equal along these
coordinates (dimensions): 'x' ('x',)
54s
54s /usr/lib/python3/dist-packages/xarray/core/alignment.py:415: ValueError
Bug#1050731: libmutter-12-0: gnome-shell libmutter-12 segfault
Package: libmutter-12-0 Version: 44.3-7 Followup-For: Bug #1050731 Dear Maintainer, I found workaround, changing the refresh in nvidia-settings from 144Hz to 60Hz solves the problem with libmutter segfault. Nvidia drivers: 535.104.05 Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (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 libmutter-12-0 depends on: ii adwaita-icon-theme 43-1 ii gsettings-desktop-schemas 44.0-2 ii libatk1.0-02.49.90-5 ii libc6 2.37-7 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libcanberra0 0.30-10 ii libcolord2 1.4.6-2.2 ii libdrm22.4.115-1 ii libegl11.6.0-1 ii libfontconfig1 2.14.2-4 ii libfribidi01.0.13-3 ii libgbm123.1.6-1 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libgl1 1.6.0-1 ii libglib2.0-0 2.77.2-1 ii libgnome-desktop-4-2 44.0-2 ii libgraphene-1.0-0 1.10.8-1 ii libgudev-1.0-0 237-2 ii libharfbuzz0b 8.0.1-1 ii libice62:1.0.10-1 ii libinput10 1.23.0-2 ii libjson-glib-1.0-0 1.6.6-1 ii liblcms2-2 2.14-2 ii libpango-1.0-0 1.51.0+ds-2 ii libpangocairo-1.0-01.51.0+ds-2 ii libpangoft2-1.0-0 1.51.0+ds-2 ii libpipewire-0.3-0 0.3.78-1 ii libsm6 2:1.2.3-1 ii libstartup-notification0 0.12-6+b1 ii libsystemd0254.1-2 ii libudev1 254.1-2 ii libwacom9 2.7.0-1 ii libwayland-server0 1.22.0-2 ii libx11-6 2:1.8.6-1 ii libx11-xcb12:1.8.6-1 ii libxau61:1.0.9-1 ii libxcb-randr0 1.15-1 ii libxcb-res01.15-1 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxcursor11:1.2.1-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxkbcommon-x11-0 1.5.0-1 ii libxkbcommon0 1.5.0-1 ii libxkbfile11:1.1.0-1 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii mutter-common 44.3-7 ii mutter-common-bin 44.3-7 libmutter-12-0 recommends no packages. libmutter-12-0 suggests no packages. Versions of packages libmutter-12-0 is related to: ii libegl-mesa0 [libegl-vendor] 23.1.6-1 ii libgl1-mesa-dri 23.1.6-1 ii libglx-mesa0 [libglx-vendor] 23.1.6-1 -- no debconf information
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
hi Dylan, On Tue, 29 Aug 2023, Dylan Aïssi wrote: Le mar. 29 août 2023 à 00:27, Boud Roukema a écrit : PROPOSAL (1): Should the user be informed when doing the system upgrade? More specifically, would a one-line warning to the user be considered acceptable, as a post-install script? E.g. something like: This is a discouraged behavior. Pipewire is updated every ~ two weeks, if it displays messages for each update that will annoy people and I will receive a wave of complaints to disable it. Fair enough. Especially with Mobian/trixie (Mobian/bookworm before the release of bookworm as stable), an upgrade after a week can often update 300 to 400 packages. PROPOSAL (2): Add the following file (under the default licence for pipewire - Expat - no need to complicate the licensing further): cat > debian/pipewire-pulse.README.Debian << EOF This would be possible but as you said pipewire-pulse is not the only user service here that means we should do the same for all other packages providing a user service. Looks like a waste of resources as it is the expected behavior. But the other services do not have a name that sounds like they are "part" of pipewire. Pipewire-jack and so on do not have /lib/systemd/user/ entries. In any case, I've proposed (Debian level, but should obviously be pushed upstream if appropriate) to adjust the man page: https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/23 commit af0a1acb PROPOSAL (3) Add the following file for the overall pipewire documentation: This proposal seems more appropriate :-) merge requests to improve this file are more than welcome :-P here is the git repo: https://salsa.debian.org/utopia-team/pipewire MR proposed: https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/23 commit d4ca0381 (I didn't see an easy way of splitting these two commits into two separate merge requests through the web interface.) I also want to mention our pipewire wiki page: https://wiki.debian.org/PipeWire if you consider it lacks some information then edits are also welcome :-). Thanks - I'll see if I can do something useful there. As the interactions between all these components is complex, the safest way is to restart your device after an update of pipewire. True. But in the long term, we could imagine that pipewire - like any Debian software component - could be used by organisations or groups running services for large numbers of people where frequent reboots are considered unacceptable - maybe a big radio or tv station, for example? While sysadmins of those sorts of services are expected to thoroughly know the software they use, they'll still make errors, and may wish to avoid a reboot, and may consider that pipewire "should" allow upgrading without a reboot. Or eventually you can try to only close your session and then reopen a new one to restart user services. So on a pinephone, 'sudo systemctl restart phosh', I assume. The upstream wiki [1] provides the following command to restart pw/wp services, but before filling a new bug, I would at least try to restart my device anyway. systemctl --user restart wireplumber pipewire pipewire-pulse I was doing that for some time, and then (incorrectly) thought that I could drop off the pipewire-pulse part. [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting Anyway, my two-part MR is posted (the CI pipeline failed, for reasons presumably unrelated to my changes). Cheers Boud
Bug#1039987: systemd-gpt-auto-generator(8) - wrong instruction how to disable
Am Tue, Aug 22, 2023 at 04:30:50PM +0200 schrieb Christoph Brinkhaus: Dear Michael, > Am Tue, Aug 22, 2023 at 02:31:21PM +0200 schrieb Michael Biebl: > > Hello Michael, > thank you very much for the feedback. I have added replies inline. > > > On Fri, 30 Jun 2023 19:04:59 +0200 Christoph Brinkhaus > > wrote: > > > Package: systemd > > > Version: 252.6-1 > > > Severity: wishlist > > > > > > Dear Maintainer, > > > > > > I tried to disable systemd-gpt-auto-generator because I do not need it. > > > man 8 systemd-gpt-auto-generator documents the necessary kernel > > > parameter in the section "KERNEL COMMAND LINE" which is at the bottom of > > > the man page. > > > > > > Incorrect is the original: > > > Those options take an optional boolean argument, and default to yes. The > > > generator is enabled by default, and a negative value may > > > be used to disable it. > > > > > > That did not work. Correct is > > > Those options take an optional boolean argument, and default to yes. The > > > generator is enabled by default, "no" may > > > be used to disable it. > > > > systemd-gpt-auto-generator uses the parse_boolean() function, which > > interprets the following values as false [1]: > > > > > >"0", > >"no", > >"n", > >"false", > >"f", > >"off" > > > > > > With "negative value", any of those strings is meant. > > So changing the documentation as per your suggestion would be incomplete. > > > > I suppose, with "negative value", you understood a negative *integer* value, > > like say -1? > > You are right, this is what I have expected to be ok according to the > documentation. Due to your explanation I have found man systemd.syntax > which explaines that kind of things. > > > > I do not have a better suggestion how to phrase it and in any case, this > > should be addressed upstream. > > I kindly ask you to raise this at https://github.com/systemd/systemd/issues > > (maybe you have an idea how the documentation can be improved). > > I have raised an issue as > https://github.com/systemd/systemd/issues/28928 > My suggestion is to change "negative value" to "negative string". The documentation has been updated upstream as shown in https://github.com/systemd/systemd/commit/7abb0eef8fe4510e04c365778489af01ad562587 - The generator is enabled by default, and a negative value may be used to disable it. + The generator is enabled by default, and a false value may be used to disable it + (e.g. systemd.gpt_auto=0). Shall I close the bug (somehow) or will you do it? Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund. signature.asc Description: PGP signature
Bug#1050831: wrk: No manual page
Package: wrk Version: 4.1.0-3+b2 Severity: serious Tags: upstream Justification: Policy 12.1 X-Debbugs-Cc: alx.manpa...@gmail.com Hi! This program has no manual page. :( Cheers, Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wrk depends on: ii libc62.37-6 ii libluajit-5.1-2 2.1.0~beta3+git20220320+dfsg-4.1 ii libssl3 3.0.9-1 wrk recommends no packages. wrk suggests no packages. -- no debconf information
Bug#1042334: heudiconv: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: tags -1 unreproducible Control: tags -1 moreinfo Hi Lucas, On Wed, 26 Jul 2023 22:06:34 +0200 Lucas Nussbaum wrote: Source: heudiconv Version: 0.11.6-1 Severity: serious Justification: FTBFS ... heudiconv/tests/test_heuristics.py ... [ 68%] heudiconv/tests/test_main.py .F [ 82%] Can't repro this in a clean unstable chroot and a new version which has the exact same test passes buildd in experimental. Can you please try a re-run and check if this still persists at your end? Thanks, Nilesh
Bug#1050829: RFP: sftpgo -- SFTP/FTP/FTPS/WebDAV file server with virtual user support
Package: wnpp Severity: wishlist X-Debbugs-Cc: 73...@numbersstation.org * Package name: sftpgo Version : 2.5.4 Upstream Contact: supp...@sftpgo.com * URL : https://github.com/drakkan/sftpgo * License : AGPL-3 Programming Lang: Go Description : SFTP/FTP/FTPS/WebDAV file server with virtual user support Fully featured and highly configurable SFTP server with optional HTTP/S, FTP/S and WebDAV support. Several storage backends are supported: local filesystem, encrypted local filesystem, S3 (compatible) Object Storage, Google Cloud Storage, Azure Blob Storage, SFTP. I run this software to share files with family and a ham radio club, and find it very flexible with multiple protocols, multiple storage backends, and virtual users for greater isolation from the operating system users. (No messing around with chroots just to share files over SFTP, for example.) It might even have potential to be used to benefit Debian directly. For example, if I were going to staff a Debian booth at a trade show, I would set up an SFTPGo file server, put the handout .pdf files and schedule on there, etc., rather than monkeying around with an HTTP server/PHP/PostgreSQL/OwnCloud/LetsEncrypt stack. For ham radio, it is especially useful because it is not legal for amateur radio networks to carry encrypted traffic. So I can share the same files securely for those connected by internet (using SFTP) and unencrypted (using FTP) for those on an amateur radio wireless connection.
Bug#1050830: RFP: sftpgo -- SFTP/FTP/FTPS/WebDAV file server with virtual user support
Package: wnpp Severity: wishlist X-Debbugs-Cc: 73...@numbersstation.org * Package name: sftpgo Version : 2.5.4 Upstream Contact: supp...@sftpgo.com * URL : https://github.com/drakkan/sftpgo * License : AGPL-3 Programming Lang: Go Description : SFTP/FTP/FTPS/WebDAV file server with virtual user support Fully featured and highly configurable SFTP server with optional HTTP/S, FTP/S and WebDAV support. Several storage backends are supported: local filesystem, encrypted local filesystem, S3 (compatible) Object Storage, Google Cloud Storage, Azure Blob Storage, SFTP. I run this software to share files with family and a ham radio club, and find it very flexible with multiple protocols, multiple storage backends, and virtual users for greater isolation from the operating system users. (No messing around with chroots just to share files over SFTP, for example.) It might even have potential to be used to benefit Debian directly. For example, if I were going to staff a Debian booth at a trade show, I would set up an SFTPGo file server, put the handout .pdf files and schedule on there, etc., rather than monkeying around with an HTTP server/PHP/PostgreSQL/OwnCloud/LetsEncrypt stack. For ham radio, it is especially useful because it is not legal for amateur radio networks to carry encrypted traffic. So I can share the same files securely for those connected by internet (using SFTP) and unencrypted (using FTP) for those on an amateur radio wireless connection.
Bug#967734: rxvt-unicode: depends on deprecated GTK 2
Please replace the Build-Depends: libgtk2.0-dev with libgdk-pixbuf-2.0-dev.
Bug#1050828: src:pd-xsample: fails to migrate to testing for too long: FTBFS on ppc64el
Source: pd-xsample Version: 0.3.2+git20170905.1.4441ae5-5 Severity: serious Control: close -1 0.3.2+git20170905.1.4441ae5-6 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pd-xsample has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable failed to build on ppc64el, while it built there successfully in the past. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, 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/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pd-xsample OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050827: src:rust-ureq: fails to migrate to testing for too long: new build depends not ready for migration
Source: rust-ureq Version: 2.7.1-1 Severity: serious Control: close -1 2.7.1-5 Tags: sid trixie 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 30 days as having a Release Critical bug in testing [1]. Your package src:rust-ureq has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable Build Depends on a new package that's not ready for migration yet. 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 trixie, 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/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=rust-ureq OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050826: src:openjdk-22: fails to migrate to testing for too long: FTBFS on armhf and s390x
Source: openjdk-22 Version: 22~5ea-1 Severity: serious Control: close -1 22~12ea-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:openjdk-22 has been trying to migrate for 40 days [2]. Hence, I am filing this bug. The version in unstable failed to build from source on armhf and s390x. 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 trixie, 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/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=openjdk-22 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050825: src:slic3r-prusa: fails to migrate to testing for too long: autopkgtest regression
Source: slic3r-prusa Version: 2.5.2+dfsg-1 Severity: serious Control: close -1 2.6.0+dfsg-3 Tags: sid trixie 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 30 days as having a Release Critical bug in testing [1]. Your package src:slic3r-prusa has been trying to migrate for 40 days [2]. Hence, I am filing this bug. The version in unstable segfaults during its own autopkgtest. 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 trixie, 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/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=slic3r-prusa OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1040802: xkb-data: Breaks altgr in Norwegian layout
]] Gunnar Hjalmarsson > On 2023-08-28 13:42, Tollef Fog Heen wrote: > > ]] Gunnar Hjalmarsson > > > >> What's the output of this command: > >> > >> gsettings get org.gnome.desktop.input-sources xkb-options > > $ gsettings get org.gnome.desktop.input-sources xkb-options > > ['compose:caps', 'compose:caps', 'grp:alts_toggle', 'lv3:ralt_switch'] > > Then run this command: > > gsettings set org.gnome.desktop.input-sources xkb-options "['compose:caps']" That made the problem go away, but it doesn't really answer how it ended up there in the first place, though. I suspect this is something that's carried from older versions somewhere, but replicating that will be somewhere between hard and impossible. Thanks for helping debug this. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2
Control: tags -1 + moreinfo On Wed, 07 Dec 2022 at 20:11:11 +, Luca Boccassi wrote: > An improvement to reduce the number of dependencies pulled down by the > usr-merged debootstrapped image has been available in unstable, > bookworm and bullseye-backports for a while. I'd like to make this > improvement available in bullseye as well, as it saves ~50MB on a > minbase image. As discussed with jmw at the #debian-uk summer party, I'm repurposing this bug for a newer debootstrap backport incorporating some changes that are needed to complete the transition to merged /usr, so it is not ready for further action until updated. Marking as moreinfo to take it off the SRMs' radar for now. (Our intention is that I'll implement and test a release candidate, Luca will review, and then we'll re-propose this when we're both happy.) On Wed, 15 Mar 2023 at 21:07, Jonathan Wiltshire wrote: > This sounds like a behaviour change in stable, which would be very unusual > unless it fixes significant issues. Can it really be justified? The situation has changed since then: bookworm is now stable, bullseye is oldstable, bookworm has the "new" behaviour, and we're going to need to make a larger behaviour change in bullseye anyway (for the benefit of any official buildds that have not yet been upgraded to bookworm). Aligning bullseye debootstrap behaviour more closely with bookworm seems likely to be more palatable than entirely new behaviours. I discussed this with jmw and he agreed the SRMs could consider getting #1025657 fixed in oldstable. Of course, if the change previously proposed here seems too risky, we can revert it and keep only the higher-priority stuff. smcv
Bug#1050824: RM: golang-github-facebookgo-grace -- RoQA; dead upstream; orphaned; gitea leaf library
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-facebookgo-gr...@packages.debian.org Control: affects -1 + src:golang-github-facebookgo-grace Dear ftpmasters, please remove golang-github-facebookgo-grace. It was introduced for Gitea, which is long gone again. This package is dead upstream, orphaned in Debian, and is a leaf library package with no r-deps. Thanks, Chris
Bug#1050823: RM: golang-github-cupcake-rdb -- RoQA; dead upstream; orphaned; gitea leaf package
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-cupcake-...@packages.debian.org Control: affects -1 + src:golang-github-cupcake-rdb Dear ftpmasters, please remove golang-github-cupcake-rdb. It was introduced for Gitea, which is long gone. This package is dead upstream, orphaned in Debian, and a leaf library with no r-deps. Thanks, Chris
Bug#999227: xfonts-cyrillic: diff for NMU version 1:1.0.5+nmu1
Control: tags 999227 + pending
Dear maintainer,
I've prepared an NMU for xfonts-cyrillic (versioned as 1:1.0.5+nmu1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.
The diff is based on the changes in Git packaging repository. To view the
difference between git packaging repo and NMU version, please check the
gitdiff.patch
file in the attachment.
Regards.
diff -Nru xfonts-cyrillic-1.0.5/debian/changelog
xfonts-cyrillic-1.0.5+nmu1/debian/changelog
--- xfonts-cyrillic-1.0.5/debian/changelog 2021-01-01 11:23:03.0
-0500
+++ xfonts-cyrillic-1.0.5+nmu1/debian/changelog 2023-08-29 13:36:25.0
-0400
@@ -1,3 +1,25 @@
+xfonts-cyrillic (1:1.0.5+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Julien Cristau ]
+ * Switch Vcs-* control fields to https.
+ * Switch upstream URLs in packaging to https.
+
+ [ Simon McVittie ]
+ * d/control: Update Vcs-* for migration to salsa.debian.org
+ * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #999227)
+ * d/control: Declare that the build does not require (fake)root
+ * d/rules: Use dh_update_autotools_config to update config.guess,
+config.sub
+
+ [ Boyuan Yang ]
+ * debian/source/format: Explicitly use format "3.0 (native)".
++ Current version corresponds to upstream release v1.0.4.
+
+ -- Boyuan Yang Tue, 29 Aug 2023 13:36:25 -0400
+
xfonts-cyrillic (1:1.0.5) unstable; urgency=medium
* Non maintainer upload by the Reproducible Builds team.
diff -Nru xfonts-cyrillic-1.0.5/debian/control
xfonts-cyrillic-1.0.5+nmu1/debian/control
--- xfonts-cyrillic-1.0.5/debian/control2015-02-02 15:28:36.0
-0500
+++ xfonts-cyrillic-1.0.5+nmu1/debian/control 2023-08-29 13:33:34.0
-0400
@@ -3,12 +3,13 @@
Priority: optional
Maintainer: Debian X Strike Force
Build-Depends:
- debhelper (>= 7),
+ debhelper (>= 10.8),
xfonts-utils (>= 1:7.5),
pkg-config,
Standards-Version: 3.8.3
-Vcs-Git: git://git.debian.org/git/pkg-xorg/font/xfonts-cyrillic
-Vcs-Browser: http://git.debian.org/?p=pkg-xorg/font/xfonts-cyrillic.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic
+Rules-Requires-Root: no
Package: xfonts-cyrillic
Architecture: all
diff -Nru xfonts-cyrillic-1.0.5/debian/copyright
xfonts-cyrillic-1.0.5+nmu1/debian/copyright
--- xfonts-cyrillic-1.0.5/debian/copyright 2015-02-02 15:09:13.0
-0500
+++ xfonts-cyrillic-1.0.5+nmu1/debian/copyright 2023-08-29 13:33:34.0
-0400
@@ -1,7 +1,7 @@
This package contains the set of Russian fonts for X11 Release 6.
The font-cronyx-cyrillic, font-misc-cyrillic, font-screen-cyrillic and
font-winitzki-cyrillic tarballs were downloaded from:
-http://xorg.freedesktop.org/releases/individual/font/
+https://xorg.freedesktop.org/releases/individual/font/
font-cronyx-cyrillic:
Copyright (C) 1994-1995 Cronyx Ltd.
diff -Nru xfonts-cyrillic-1.0.5/debian/rules
xfonts-cyrillic-1.0.5+nmu1/debian/rules
--- xfonts-cyrillic-1.0.5/debian/rules 2015-02-02 17:13:12.0 -0500
+++ xfonts-cyrillic-1.0.5+nmu1/debian/rules 2023-08-29 13:33:34.0
-0400
@@ -35,8 +35,12 @@
confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
endif
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
mkdir -p $(STAMP_DIR)
+ dh_update_autotools_config
+ >$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
mkdir -p $*-build
cd $*-build && \
../$*/configure \
@@ -48,9 +52,13 @@
>$@
build: build-stamp
+build-indep: build-stamp
build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
>$@
+build-arch:
+# Nothing to do
+
clean:
dh_testdir
rm -f config.cache config.log config.status
@@ -101,9 +109,10 @@
get-tarball-%:
uscan --no-conf --download --no-symlink --destdir . --package $*
--upstream-version $(shell awk -F = '/^PACKAGE_VERSION=/ { print $$2 }' <
$*/configure || echo 0) --
watchfile debian/watch.$* || test $$? = 1
-debian/watch.%:
- echo version=3 > $@
- echo 'http://xorg.freedesktop.org/releases/individual/font/
$*-(.*)\.tar\.gz' >> $@
+debian/watch.font-%:
+ echo '#git=git://anongit.freedesktop.org/xorg/font/$*' > $@
+ echo version=3 >> $@
+ echo 'https://xorg.freedesktop.org/releases/individual/font/
font-$*-(.*)\.tar\.gz' >> $@
.PHONY: watchfiles
watchfiles: $(addprefix debian/watch.,$(SUBDIRS))
diff -Nru xfonts-cyrillic-1.0.5/debian/source/format
xfonts-cyrillic-1.0.5+nmu1/debian/source/format
--- xfonts-cyrillic-1.0.5/debian/source/format 1969-12-31 19:00:00.0
-0500
+++ xfonts-cyrillic-1.0.5+nmu1/debian/source/format 2023-08-29
13:36:19.0 -0400
@@ -0,0 +1 @@
+3.0 (native)
diff -Nru xfonts-cyrillic-1.0.5/debian/watch.font-cronyx-cyrillic
xfonts-cyrillic-1.0.5+nmu1/debian/watch.font-cronyx-cyrillic
--- xfonts-cyrill
Bug#1050820: virtualbox-ext-pack: downloaded extension pack not stored?
Control: severity -1 normal Ok, looking at postinst [0], it seems that the message "The file will be downloaded into /usr/share/virtualbox-ext-pack" misled me, as it seems, as line 31 rm it after installing it… May I suggeset to remove that line, and while on it fixing #908897 to use a more FSH compliant path (/usr might not be writeable…) [0] https://salsa.debian.org/pkg-virtualbox-team/virtualbox-ext-pack/-/blob/master/debian/postinst.in#L27 -- Cheers, tobi
Bug#1050822: rust-polling: please update to v2.8
Source: rust-polling Version: 2.2.0-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to (at least) newer upstream version v2.8.0. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTuKmkACgkQLHwxRsGg ASHpMA//czJQGiZ4LERfwbJRDCDGHCidTzElcUTKCdSKCeGeCJN+lthQgznku8dm cA0KvMXdYJ9dMjK4m5rVuB4jW+KmY/aDPW6x46uPjdjPu1cYquZ3CkPnjLU5uQdw /o+4lMw4MIiNcJdCQe2joHSiuNWHMeIbv+o7ntKrgFqq7nIKNbLkayMbBDHEYtDm S0STE2uJcBF0je457woEMLzB/Bdcs/OEmUycShAreWsYFKcHhmpPprKYoRe9TzON q3LSg0WWkeRg/pOeU0Sp31KFLXkfjKFrCfo7XhZHTx6PoL5dE8SpmIslxFp6HGic nkatqOewAsFQtBrCefDKBDCdjhwuf8G+i79zxc5XT+GEUfDFxwEdsD2l97uSKc5h YNQF9KEZhCs/1nmLe8uWmCxjz4dDRgVZV7g3rdcL4zj7NkgG1ZhfslvBR0i93FVU Rwc9tLb2/eU9+xABKz9NkyDyXrl5N35RMHGLgXXQ3L6egsl+dhjCDqweuRH7n/qm 4QQ0CDeWCb2nPcsGFa3CE7zrbyVxZhm8v5AVRrmSQdfCGwlbN4WHMnIJ9PZBZIou 90ue9sS7IPsvxYI+N0CSCJKgJACsFq48GNAne6YUM/Pva00W0YvKiYlXgvQ0lPdb ADOJw7/525W5tR6M4zSnxQ+Q3Kgjk1s3Ot/D/O2p5mmpbeMDycw= =Gzwk -END PGP SIGNATURE-
Bug#1050819: pcre2: Please enable JIT on riscv64
Hi, On 29/08/2023 18:01, Aurelien Jarno wrote: PCRE2 gained support for JIT on riscv64 in version 10.41 and it is recommended to enable it [1]. Could you please do that for the next upload? I have tested the following patch without issue: Sure; I'm building an updated package now. I didn't quite take your patch, as I noticed the JIT arch list wasn't sorted, so I tidied that up too :) Regards, Matthew
Bug#1050821: kmag does not work with wayland plasma shell. OK on X11
Package: kmag Version: 4:22.12.3-1 Severity: important Tags: upstream Dear Maintainer, * What led up to the situation? Attempted to use kmag to enlarge a portion of screen * What exactly did you do (or not do) that was effective (or ineffective)? When using the Plasma/Wayland shell, the program only presented a gray window and no enlarged mouse cursor. * What was the outcome of this action? kmag did not enlarge any part of the screen. Tried different focus and window options to no effect. (see screenshot) * What outcome did you expect instead? Under Plasma/X11 kmag functions as designed. (see screenshot) -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kmag depends on: ii kio 5.103.0-1 ii libc6 2.36-9+deb12u1 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii libqaccessibilityclient-qt5-0 0.4.1-1+b1 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5printsupport5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 kmag recommends no packages. kmag suggests no packages. -- no debconf information -- Peter Hyman (609)598-0262 (612)440-PETE (7383)
Bug#1050820: virtualbox-ext-pack: downloaded extension pack not stored?
Package: virtualbox-ext-pack Version: 7.0.10-1 Severity: grave Dear Maintainer, /usr/share/virtualbox-ext-pack/ is empty after package installation and download: root@isildor2:/usr# apt install virtualbox-ext-pack Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: virtualbox-ext-pack 0 upgraded, 1 newly installed, 0 to remove and 9 not upgraded. Need to get 0 B/11.5 kB of archives. After this operation, 152 kB of additional disk space will be used. Retrieving bug reports... Done Parsing Found/Fixed information... Done Preconfiguring packages ... Selecting previously unselected package virtualbox-ext-pack. (Reading database ... 233745 files and directories currently installed.) Preparing to unpack .../virtualbox-ext-pack_7.0.10-1_all.deb ... License has already been accepted. Unpacking virtualbox-ext-pack (7.0.10-1) ... Setting up virtualbox-ext-pack (7.0.10-1) ... virtualbox-ext-pack: downloading: https://download.virtualbox.org/virtualbox/7.0.10/Oracle_VM_VirtualBox_Extension_Pack-7.0.10.vbox-extpack The file will be downloaded into /usr/share/virtualbox-ext-pack License accepted. 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Successfully installed "Oracle VM VirtualBox Extension Pack". root@isildor2:/usr# ls -la /usr/share/virtualbox-ext-pack/ total 16 drwxr-xr-x 2 root root 4096 Aug 29 19:13 . drwxr-xr-x 313 root root 12288 Aug 29 19:13 .. root@isildor2:~# find / -name '*vbox-extpack' root@isildor2:~# -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, 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 virtualbox-ext-pack depends on: ii ca-certificates20230311 ii debconf [debconf-2.0] 1.5.82 ii virtualbox 7.0.10-dfsg-3 ii wget 1.21.3-1+b2 virtualbox-ext-pack recommends no packages. virtualbox-ext-pack suggests no packages. -- debconf information: * virtualbox-ext-pack/license: true
Bug#1037281: Please add support for MediaTek MT7986 in U-Boot
On 10 Jun 2023-06-10 Vagrant Cascadian wrote: > On 2023-06-10, Bernhard wrote: > > I'm interested in the Router BANANA Pi R3 from Sinovoip: > > https://wiki.banana-pi.org/Banana_Pi_BPI-R3 > > > > This Banana Pi has MediaTek MT7986 (Filogic 830). > > I cannot say what it will take to support it in debian for sure... > ... > The other main thing is to check what support is needed in the linux > kernel... The good news is that it appears to be supported in the upstream kernel. The bad new starts with this: $ grep -r MEDIATEK debian/config/ debian/config/config:CONFIG_WLAN_VENDOR_MEDIATEK=y debian/config/arm64/config.cloud-arm64:# CONFIG_ARCH_MEDIATEK is not set Which is not relevant for the Banana Pi BPI-R3 ... $ grep MEDIATEK /boot/config-6.1.0-11-arm64 # CONFIG_ARCH_MEDIATEK is not set # CONFIG_MEDIATEK_GE_PHY is not set CONFIG_WLAN_VENDOR_MEDIATEK=y ... "CONFIG_ARCH_MEDIATEK is not set" means that there (essentially) isn't *anything* wrt MEDIATEK enabled in the Debian kernel ... (same for 6.5 btw) I have a script which helps with identifying which kernel modules would be needed based on the "compatible" strings in the dts file and running it on the mt7986a-bananapi-bpi-r3.dts revealed 1 missing component ... but a rather important one, which AFAICT is related to ARCH_MEDIATEK not being enabled. The dts file also includes a .dtsi file and scanning that file revealed mostly missing "Debian config settings:" lines and thus also any enabled modules in the Debian kernel. My script is very crude and will only give a starting point which I then would enhance by filling in the missing parts. But I'm not motivated enough to do that for a board which I don't have (as it's quite a bit of work) ;-) Hope it still helps.compatible: "arm,armv8-timer" source file: drivers/clocksource/arm_arch_timer.c drivers/clocksource/Kconfig: ARM_ARCH_TIMER (bool) compatible: "arm,cortex-a53" compatible: "arm,gic-v3" compatible: "arm,psci-0.2" source file: drivers/firmware/psci/psci.c drivers/firmware/psci/Kconfig: ARM_PSCI_FW (bool) compatible: "fixed-clock" source file: drivers/clk/clk-fixed-rate.c drivers/clk/Kconfig: COMMON_CLK (bool) Debian config settings: debian/config/arm64/config:CONFIG_COMMON_CLK=y compatible: "inside-secure,safexcel-eip97" source file: drivers/crypto/inside-secure/safexcel.c drivers/crypto/Kconfig: CRYPTO_DEV_SAFEXCEL (tristate) Debian config settings: debian/config/arm64/config:CONFIG_CRYPTO_DEV_SAFEXCEL=m compatible: "mediatek,mt7986a" compatible: "mediatek,mt7986a-pinctrl" source file: drivers/pinctrl/mediatek/pinctrl-mt7986.c drivers/pinctrl/mediatek/Kconfig: PINCTRL_MT7986 (bool) compatible: "mediatek,mt7986-apmixedsys" source file: drivers/clk/mediatek/clk-mt7986-apmixed.c drivers/clk/mediatek/Kconfig: COMMON_CLK_MT7986 (tristate) compatible: "mediatek,mt7986-auxadc" compatible: "mediatek,mt7986-efuse" compatible: "mediatek,mt7986-eth" source file: drivers/net/ethernet/mediatek/mtk_eth_soc.c compatible: "mediatek,mt7986-ethsys" source file: drivers/clk/mediatek/clk-mt7986-eth.c drivers/clk/mediatek/Kconfig: COMMON_CLK_MT7986_ETHSYS (tristate) compatible: "mediatek,mt7986-i2c" source file: drivers/i2c/busses/i2c-mt65xx.c drivers/i2c/busses/Kconfig: I2C_MT65XX (tristate) compatible: "mediatek,mt7986-infracfg" source file: drivers/clk/mediatek/clk-mt7986-infracfg.c drivers/clk/mediatek/Kconfig: COMMON_CLK_MT7986 (tristate) compatible: "mediatek,mt7986-mmc" source file: drivers/mmc/host/mtk-sd.c drivers/mmc/host/Kconfig: MMC_MTK (tristate) Debian config settings: debian/config/config:# CONFIG_MMC_MTK is not set compatible: "mediatek,mt7986-pcie" compatible: "mediatek,mt7986-pwm" source file: drivers/pwm/pwm-mediatek.c drivers/pwm/Kconfig: PWM_MEDIATEK (tristate) compatible: "mediatek,mt7986-rng" source file: drivers/char/hw_random/mtk-rng.c drivers/char/hw_random/Kconfig: HW_RANDOM_MTK (tristate) compatible: "mediatek,mt7986-sgmiisys_0" source file: drivers/clk/mediatek/clk-mt7986-eth.c drivers/clk/mediatek/Kconfig: COMMON_CLK_MT7986_ETHSYS (tristate) compatible: "mediatek,mt7986-sgmiisys_1" source file: drivers/clk/mediatek/clk-mt7986-eth.c drivers/clk/mediatek/Kconfig: COMMON_CLK_MT7986_ETHSYS (tristate) compatible: "mediatek,mt7986-spi-ipm" compatible: "mediatek,mt7986-thermal" source file: drivers/thermal/mediatek/auxadc_thermal.c drivers/thermal/mediatek/Kconfig: MTK_SOC_THERMAL (tristate) compatible: "mediatek,mt7986-topckgen" source file: drivers/clk/mediatek/clk-mt7986-topckgen.c drivers/clk/mediatek/Kconfig: COMMON_CLK_MT7986 (tristate) compatible: "mediatek,mt7986-tphy" compatible: "mediatek,mt7986-uart" compatible: "mediatek,mt7986-wdt" source file: drivers/watchdog/mtk_wdt.c drivers/watchdog/Kconfig: MEDIATEK_WATCHDOG (tristate) compatible: "mediatek,mt7986-wed" compatible: "mediatek,mt7986-wed-pcie" compatible: "mediatek,mt7986-wmac" source file: drivers/net/wireless/mediatek/mt76/mt7915/soc.c drivers/net/wireless/mediatek/mt76/mt7915/Kconfig: M
Bug#1050819: pcre2: Please enable JIT on riscv64
Source: pcre2 Version: 10.42-3 Severity: wishlist Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear maintainer, PCRE2 gained support for JIT on riscv64 in version 10.41 and it is recommended to enable it [1]. Could you please do that for the next upload? I have tested the following patch without issue: diff -u pcre2-10.42/debian/rules pcre2-10.42/debian/rules --- pcre2-10.42/debian/rules +++ pcre2-10.42/debian/rules @@ -13,7 +13,7 @@ deb_maint_conf_args = --enable-pcre2-16 --enable-pcre2-32 --disable-pcre2grep-callout #enable JIT only on architectures that support it (see pcre2jit.3) -ifneq ($(filter i386 amd64 armel armhf mips mipsel mips64el powerpc arm64 ppc64 ppc64el s390x, $(DEB_HOST_ARCH)),) +ifneq ($(filter i386 amd64 armel armhf mips mipsel mips64el powerpc arm64 ppc64 ppc64el riscv64 s390x, $(DEB_HOST_ARCH)),) deb_maint_conf_args +=--enable-jit else deb_maint_conf_args +=--disable-jit Thanks Aurelien [1] https://github.com/PCRE2Project/pcre2/issues/14
Bug#1050818: gtksourceview4: FTBFS on riscv64 due to test timeout
Source: gtksourceview4 Version: 4.8.4-4 Severity: important Tags: patch ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear maintainer, gtksourceview4 fails to build from source on riscv64 with a timeout in one test: | 23/23 test-language-specs TIMEOUT30.08s killed by signal 15 SIGTERM The full build log is available there: https://buildd.debian.org/status/fetch.php?pkg=gtksourceview4&arch=riscv64&ver=4.8.4-4&stamp=1693294414&raw=0 After investigation, it appeared the test actually passes, but needs a tiny but more time than the default 30 seconds timeout of meson. The following patch uses the --timeout-multiplier feature of meson to increase the timeout. I didn't try to use a different multiplier depending on the architecture as it has no impact on working tests anyway. diff -Nru gtksourceview4-4.8.4/debian/rules gtksourceview4-4.8.4/debian/rules --- gtksourceview4-4.8.4/debian/rules +++ gtksourceview4-4.8.4/debian/rules @@ -23,4 +23,4 @@ $(DOC_FLAGS) override_dh_auto_test: - NO_AT_BRIDGE=1 xvfb-run -a dh_auto_test + NO_AT_BRIDGE=1 xvfb-run -a dh_auto_test -- --timeout-multiplier 2 Regards Aurelien
Bug#1042758: Please update to 4.3.0
Control: tags -1 + fixed-in-experimental On Mon, 31 Jul 2023 14:33:56 +0200 Thomas Braun wrote: > Source: omniorb-dfsg > X-Debbugs-Cc: thomas.br...@byte-physics.de > Version: > Severity: normal > > Dear Maintainer, > > please update to 4.3.0. See also https://omniorb.sourceforge.io. omniorb-dfsg 4.3.0 is now available in experimental signature.asc Description: PGP signature
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
Hi Boud, Le mar. 29 août 2023 à 00:27, Boud Roukema a écrit : > > PROPOSAL (1): > > Should the user be informed when doing the system upgrade? More specifically, > would a one-line warning to the user be considered acceptable, as a > post-install > script? E.g. something like: > > "Please recommend that users restart all scripts running pipewire (such as > pipewire, pipewire-pulse)" This is a discouraged behavior. Pipewire is updated every ~ two weeks, if it displays messages for each update that will annoy people and I will receive a wave of complaints to disable it. > PROPOSAL (2): > > Add the following file (under the default licence for pipewire - Expat - no > need to complicate the licensing further): > > cat > debian/pipewire-pulse.README.Debian << EOF > Relation to pipewire and upgrades > = > > The pipewire-pulse systemd service runs independently of the pipewire > service. Both run as user services and are not restarted when a > system-level upgrade is performed by the root user. If you wish to > check that you restart pipewire-pulse whenever the pipewire is > upgraded using dpkg or apt, then consider using either > "checkrestart" in the "debian-goodies" package [1] or "needrestart" [2]. > These need to be run as root user, but aim to check for both > system and user services that need restarting. > > [1] https://tracker.debian.org/pkg/debian-goodies > [2] https://tracker.debian.org/pkg/needrestart > EOF This would be possible but as you said pipewire-pulse is not the only user service here that means we should do the same for all other packages providing a user service. Looks like a waste of resources as it is the expected behavior. > PROPOSAL (3) > Add the following file for the overall pipewire documentation: > > cat >> debian/pipewire.README.Debian << EOF > > > After upgrading pipewire > > > A system-level upgrade of pipewire will not automatically restart all > pipewire-related services. After an upgrade of pipewire, you may check > the output of "pw-dump" to see if you forgot to restart some services, > e.g. > >$ pw-dump |grep -nE "core\.(version|name)|process\.binary" > > or you may use "checkrestart" [1] or "needrestart" [2] with > sudo or as root user. > > [1] https://tracker.debian.org/pkg/debian-goodies > [2] https://tracker.debian.org/pkg/needrestart > EOF This proposal seems more appropriate :-) merge requests to improve this file are more than welcome :-P here is the git repo: https://salsa.debian.org/utopia-team/pipewire I also want to mention our pipewire wiki page: https://wiki.debian.org/PipeWire if you consider it lacks some information then edits are also welcome :-). > Independent of proposals (1) + (2) + (3), the 'pw-dump' > output gives me the feeling that restarting pipewire > should force the restart of all the related services - but > I don't know how well they are expected to work together > when according to pw-dump they are using inconsistent > pipewire versions. As the interactions between all these components is complex, the safest way is to restart your device after an update of pipewire. Or eventually you can try to only close your session and then reopen a new one to restart user services. The upstream wiki [1] provides the following command to restart pw/wp services, but before filling a new bug, I would at least try to restart my device anyway. systemctl --user restart wireplumber pipewire pipewire-pulse [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting Best regards, Dylan
Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader
control: merge 1050404 -1 control: block -1 by 1050459 control: tags -1 patch Hi, I've prepared an MR[1] to handle this, which requires a newer emacs-buttercup which is being prepared at [2]. PTAL. [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3 [2] https://salsa.debian.org/emacsen-team/emacs-buttercup/-/merge_requests/1 -- Manphiz
Bug#1024851: Regression with 2022.10+dfsg-1 on Pinebook pro : broken keyboard
Control: found -1 2022.04+dfsg-1 On 30 Dec 2022 Hubert Tonneau wrote: > Vagrant Cascadian wrote: > > > > I'd also be curious to see if it works for you with the 2023.01~rc* > > versions currently in experimental. > > This one seems to work half on my Pinebook pro: Did the situation improve with version 2023.01 as released with Bookworm? Or in case you're on Testing/Unstable, any change in 2023.07? > Please notice that the same problem did exist on 2022.04 > I just had just not used it enough to notice the issues of required slow > typing. Updated metadata accordingly On 23 Dec 2022 Vagrant Cascadian wrote: > Control: tags 1024851 moreinfo > > There is still a patch applied to enable usb support: > > > https://salsa.debian.org/debian/u-boot/-/blob/debian/latest/debian/patches/rockchip/rockchip-inno-usb.patch > > I would be curious to check if it works with or without the patch > applied... That would indeed be an interesting test. I'm not (so) sure whether it's a good idea to keep this patch as it was proposed in 2021-04-06 and NOT accepted. Rework was requested (i.e. implement it in phy-uclass) and while the submitter initially said they'd try, they later backed out of it. That was > 18 months ago, so I guess it's safe to assume that won't happen. Which means it has become a 'Debian only' patch and I don't think that's wise as it could interfere with what upstream expects to happen based on their code. My 0.02 signature.asc Description: This is a digitally signed message part.
Bug#1013298: O: flycheck -- modern on-the-fly syntax checking for Emacs
control: tags -1 patch After discussing on IRC and with permission from anarcat, I intend to adopt flycheck. An MR is being prepared at [1]. [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3 -- Manphiz
Bug#1050817: systemd: can't switch back to virtual console 7
Package: systemd Version: 254.1-3 Severity: important After switching to virtual console 1, it is possible to switch, using alt+fn or ctrl+alt+fn, to virtual console 1, 3, 4, 8, and 9 (why only these?), but not to virtual console 7, containing the default x11 session. It is possible to switch using 'loginctl activate', but this is not very obvious, hence the elevated severity. -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii libacl12.3.1-3 ii libaudit1 1:3.1.1-1 ii libblkid1 2.39.2-1 ii libc6 2.37-7 ii libcap21:2.66-4 ii libcryptsetup122:2.6.1-4 ii libfdisk1 2.39.2-1 ii libgcrypt201.10.2-2 ii libkmod2 30+20230519-1 ii liblz4-1 1.9.4-1 ii liblzma5 5.4.1-0.2 ii libmount1 2.39.2-1 ii libp11-kit00.25.0-4 ii libseccomp22.5.4-1+b3 ii libselinux13.5-1 ii libssl33.0.10-1 ii libsystemd-shared 254.1-3 ii libsystemd0254.1-3 ii libzstd1 1.5.5+dfsg2-1 ii mount 2.39.2-1 ii systemd-dev254.1-3 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.8-2 ii systemd-timesyncd [time-daemon] 254.1-3 Versions of packages systemd suggests: ii libfido2-11.13.0-1 pn libqrencode4 pn libtss2-esys-3.0.2-0 pn libtss2-mu0 pn libtss2-rc0 pn polkitd ii python3 3.11.4-5+b1 pn python3-pefile pn systemd-boot pn systemd-container pn systemd-homed pn systemd-resolved pn systemd-userdbd Versions of packages systemd is related to: pn dbus-user-session pn dracut ii initramfs-tools0.142 pn libnss-systemd ii libpam-systemd 254.1-3 ii udev 254.1-3 -- no debconf information
Bug#1050816: RM: mmorph -- RoQA; orphaned; dead upstream; low popcon; RC-buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:mmorph Please remove mmorph. It is orphaned and dead upstream. The package has a very low popcon and is RC-buggy, which made it miss bookworm. Nobody bothered to port it to a newer glibc version.
Bug#1050815: snapshot.d.o has been in a bad state for several months
package: snapshot.debian.org severity: important x-debbugs-cc: debian-de...@lists.debian.org, reproducible-bui...@lists.alioth.debian.org Hi, filing this as a bug report, again, because the problem has become worse than when #1031628 was filed and since snapshot.d.o is part of the central services Debian provides and it should work better than it does right now. else, why do we operate it? ;) On Wed, Aug 02, 2023 at 01:33:11PM +0200, Johannes Schauer Marin Rodrigues wrote: > snapshot.debian.org is getting worse again. There is not a single snapshot for > August yet and the last days of July are spotty: > > http://snapshot.debian.org/archive/debian/?year=2023&month=7 > > None for the 29. and only a single timestamp for the 26., 27., 28. and 30. > There should be four per day. The situation is even worse for other archives. > For debian-ports, for the month of July, there are only 22 snapshots overall: > > http://snapshot.debian.org/archive/debian-ports/?year=2023&month=7 > > This problem has been known for half a year already: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031628 > > But that bug got closed in favor of #1029744 which was filed because > debian-ports had no snapshots at all for January and only three for February > this year but there is no reply to that bug. > > In #1031628 Julien said that there is "not much we can do about it at the > moment". > > What is the status of this problem? What is needed to fix it? Is this just a > problem of computational and/or storage resources which an be fixed by the > funds available to Debian? > > I'd argue that snapshot.d.o is part of the central services Debian provides > and > it should work better than it does right now. On https://snapshot.debian.org/archive/debian-ports/?year=2023&month=8 I count 31 snapshot for those 29 days of August so far, with no snapshots so far for 2023-08-01, 2023-08-08, 2023-08-17 and 2023-08-29. But it get's worse: On Wed, Aug 09, 2023 at 11:34:56AM -0400, Theodore Ts'o wrote: > BTW, it also looks like not only are some snapshots not being taken, > some of the snapshots are missing packages. For example: > >https://snapshot.debian.org/archive/debian/20230806T091912Z/ > > is missing the package libc-dev-bin, and: > >https://snapshot.debian.org/archive/debian/20230807T150823Z/ > > is missing the package dbus. Which is something that I'm finding when > I try building an kvm-xfstests VM using: > > https://github.com/tytso/xfstests-bld/blob/master/test-appliance/gen-image > > Ah, well, I guess I'll try the snapshot for 20230805T151946Z next Please don't just close this bug report as it was done with #1031628, it's useful to be able to track this, point out that this problem has been existed since some time and have a place to discussion workarounds. Also, how can one start helping with this issue (or others)? where does the snapshot team communicate? https://salsa.debian.org/snapshot-team/snapshot/-/commits/master has not seen any commit since 7 months. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Alles weird gut. signature.asc Description: PGP signature
Bug#1050814: RFS: qbootctl/0.1.2-1 [ITP] -- utility to control Quacomm A/B boot slots
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-on-mobile-maintain...@alioth-lists.debian.net Dear mentors, I am looking for a sponsor for my package "qbootctl": * Package name : qbootctl Version : 0.1.2-1 Upstream contact : Caleb Connolly * URL : https://gitlab.com/sdm845-mainline/qbootctl * License : GPL-2-Linux-syscall-note, BSD-3-clause, BSD-3-Clause, GPL-3+ * Vcs : https://salsa.debian.org/lumag/qbootctl Section : utils The source builds the following binary packages: qbootctl - utility to control Quacomm A/B boot slots To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qbootctl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qbootctl/qbootctl_0.1.2-1.dsc Changes for the initial release: qbootctl (0.1.2-1) unstable; urgency=medium . * Initial release. (Closes: #1050354) -- With best wishes Dmitry
Bug#1050813: Danubian-installer: no option to skip configuring network
Package: webinar-installer Severity: important Tags: d-i X-Debbugs-Cc: erjoa...@gmail.com Dear Maintainer, The debian 12 installer does not appear to support an option to skip connecting to a network. I'm installing on a laptop and using a large DVD and do not have access to any wireless network, but following the graphical installation process I am forced to select a wireless network. I have to manually select "Go Back" and skip the "Configure the Network". However, on the clock configuration step I am again forced to select a network. There should be a clearly accessible option to skip network configuration for users who cannot or do not want to set up a network during installation. Thanks, Ernesto debian-12.0.0-amd64-DVD-1.iso *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028541: lvm2: LVM filters render server unbootable
Hi,
I'm seeing this bug in a different usecase on Debian Bookworm with LVM
2.03.16-2: multipath is set up, the multipath device is an LVM
physical volume in a volume group with a thin pool. To prevent LVM from
picking up on the multipath components, /etc/lvm/lvm.conf has a
global_filter that rejects the multipath components by matching on their
/dev/disk/by-id symlink paths.
I have replicated this setup in a VM, with the following global_filter
in /etc/lvm/lvm.conf:
devices {
global_filter=["r|/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1|","r|/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi2|"]
}
The relevant portion of /dev/disk/by-id:
lrwxrwxrwx 1 root root 9 Aug 29 16:31
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 -> ../../sdb
lrwxrwxrwx 1 root root 9 Aug 29 16:31
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2 -> ../../sdc
After running update-initramfs and rebooting, pvs and other LVM
tooling reports the following warning:
# pvs
WARNING: Device mismatch detected for somegroup/somethinpool_tmeta
which is accessing /dev/sdb instead of /dev/mapper/mpatha.
WARNING: Device mismatch detected for somegroup/somethinpool_tdata
which is accessing /dev/sdb instead of /dev/mapper/mpatha.
PV VGFmt Attr PSize PFree
/dev/mapper/mpatha somegroup lvm2 a-- <4.00g <2.99g
>From reading this report and the now-resolved upstream report, this
seems to happen because the /dev/disk/by-id symlinks are not available
by the time the LVM udev hooks run, so the r|...| filters do not have
any effect. Indeed, if I use r|/dev/sdb| and r|/dev/sdc| instead, run
update-initramfs and reboot, the warning does not appear anymore.
However, being able to use the /dev/disk/by-id paths would be preferable.
With the following four patches applied, I can use /dev/disk/by-id in
the filters and the warning does not appear:
https://sourceware.org/git/?p=lvm2.git;a=commit;h=17a3585cbb55d9a15ced9775a18b50c53a50ee8e
https://sourceware.org/git/?p=lvm2.git;a=commit;h=c9fdc828ff0504bc2e57f65862bc382f7663a8a2
https://sourceware.org/git/?p=lvm2.git;a=commit;h=6d14144d311fb347e4225ad6a48d4900b39445c4
https://sourceware.org/git/?p=lvm2.git;a=commit;h=bd05318ba2fc588be6339f5dc61f09195996b0e9
The first three patches are mentioned in the upstream bug report [1] and
cause pvscan to read symlink names from udev's DEVLINKS environment
variable under certain conditions. One of the conditions is that at
least one of the filter regexes refer to a symlink. However, this check
only considers a|...| filters [2], so it doesn't trigger if only r|...|
filters are used as above. Hence, in my case the fourth patch is also
needed, as it removes the filter regex check altogether.
Is there a chance the patches could be backported? All four patches seem
to be included in upstream release 2.03.19 [3].
Happy to provide any more information if needed!
Thanks and best wishes,
Friedrich
[1] https://github.com/lvmteam/lvm2/issues/104
[2]
https://sourceware.org/git/?p=lvm2.git;a=blob;f=lib/filters/filter-regex.c;h=ecc32914b0e15ba9cbac5c101cffddf25eddd8ad;hb=6d14144d311fb347e4225ad6a48d4900b39445c4#l272
[3] https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/tags/v2_03_19
Bug#1050768: xastir: Drop unused libproj-dev build dependency
Xastir's configure script probes for proj before geotiff, yes. This dependency in configure is an odd, ancient relic of when libgeotiff was in NO package management systems and most users had to build it from source by themselves. That generally meant they got static libraries, not shared, and so it was necessary to probe for libproj (which was always needed by static-linked geotiff) before probing for geotiff. It is still the case that if a user is using static geotiff libraries then proj must be found first, and it does no harm to probe for it even if geotiff is a shared library that pulls in its own dependency anyway. Few, if any, modern users of Xastir use handrolled libgeotiff, but we keep the possibility open because some people are like that. However, if we're only talking about a package dependency, so long as your libgeotiff package depends on the libproj-dev properly, and Xastir's package depends on libgeotiff, then there is no problem with removing a build dependency of the package on proj. So long as Xastir is always able to find libproj libraries and headers if libgeotiff is requested, we're fine. If, however, your libgeotiff package only depends on libproj and not libproj-dev, yeah, Xastir still needs that build dependency. David, please don't carbon me directly on things like this. Only if the package managers can't resolve your query directly, please send them to the Xastir mailing list, where multiple developers could respond. On Tue, Aug 29, 2023 at 10:33:40AM -0400, we recorded a bogon-computron collision of the flavor, containing: > Christoph, > > de Dave KB3EFS > > Keeping the B-D is a must so that offline maps can be built from online > sources provided by the U.S. Government. > > Please consult with Tom Russo KM5VY (the last developer to touch the entire > Xastir source code) before any changes. I have CC'd him with this email. > > Thank you. > > 73 > Dave > KB3EFS > > PS - Yes I see the other emails that are going back and forwards while I was > typing this. > > > > On 8/29/23 10:07, Christoph Berg wrote: > > Control: tags -1 moreinfo > > > > Re: Bas Couwenberg > > > Your package build depends on libproj-dev but doesn't link to libproj nor > > > include proj.h. > > Xastir uses libgeotiff-dev, which depends on libproj-dev, so dropping > > the B-D wouldn't make it not use it. > > > > Since configure.ac contains an explicit check for libproj before it > > tries to check for libgeotiff, I think keeping the B-D does have some > > value. > > > > Christoph > > -- Tom RussoKM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
Package: u-boot-rockchip Version: 2023.01+dfsg-2 Severity: wishlist Upstream recently added support for the following Pine64 Quartz64 devices: - Quartz64 Model A - Quartz64 Model B - SoQuartz on Model A board - SoQuartz on Blade board - SoQuartz on CM4 IO carrier board Link: https://source.denx.de/u-boot/u-boot/-/tree/master/board/pine64/quartz64_rk3566 Hereby the request to package them for Debian. TIA, Diederik -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-11-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled u-boot-rockchip depends on no packages. Versions of packages u-boot-rockchip recommends: ii python3 3.11.2-1+b1 pn u-boot-tools Versions of packages u-boot-rockchip suggests: pn arm-trusted-firmware -- no debconf information
Bug#1050777: Acknowledgement (The surf autopkgtests are failing with webkitgtk 2.41)
And as a follow up it's not only an autopkgtest issue, surf fails to render any webpage on my Ubuntu mantic system with the new webkitgtk installed Le 29/08/2023 à 09:51, Debian Bug Tracking System a écrit : Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1050777:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050777. 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): Debian WebKit Maintainers If you wish to submit further information on this problem, please send it to1050...@bugs.debian.org. Please do not send mail toow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#1050751: qosmic: Move to a lua version != 5.2
Last upstream release was in 2017. Seems Unlikely that they can help with a lua port. Many compile errors with lua 5.3, however Qosmic builds OK with lua 5.1 with a one line change. src/lua/frame.cpp // 98 lua_tointegerx(L, 1, &isnum) - 1; --> lua_tointeger(L, isnum) - 1;
Bug#1050811: RM: clif -- RoQA; orphaned; dead upstream; low popcon; RC-buggy (non-free)
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:clif Please remove clif. It is orphaned and dead upstream. The package has a low popcon and is RC-buggy (non-free source contained), which made it miss bookworm.
Bug#1050768: xastir: Drop unused libproj-dev build dependency
On 8/29/23 16:26, Christoph Berg wrote: Feel free to close this issue if you don't intend to apply the patch. TBH I'd rather keep it in there, I don't know enough about libgeotiff so I can't know if I would notice if it dropped the libproj-dev dependency some day, and then Xastir would stop using it without the build failing. PROJ is a hard dependency of GeoTIFF, several of its headers include proj.h hence the dependency from libgeotiff-dev. It's most unlikely that GeoTIFF will ever stop requiring PROJ, so the proj dependency will stay until that changes. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1050768: xastir: Drop unused libproj-dev build dependency
Christoph, de Dave KB3EFS Keeping the B-D is a must so that offline maps can be built from online sources provided by the U.S. Government. Please consult with Tom Russo KM5VY (the last developer to touch the entire Xastir source code) before any changes. I have CC'd him with this email. Thank you. 73 Dave KB3EFS PS - Yes I see the other emails that are going back and forwards while I was typing this. On 8/29/23 10:07, Christoph Berg wrote: Control: tags -1 moreinfo Re: Bas Couwenberg Your package build depends on libproj-dev but doesn't link to libproj nor include proj.h. Xastir uses libgeotiff-dev, which depends on libproj-dev, so dropping the B-D wouldn't make it not use it. Since configure.ac contains an explicit check for libproj before it tries to check for libgeotiff, I think keeping the B-D does have some value. Christoph
Bug#1050768: xastir: Drop unused libproj-dev build dependency
Control: tags -1 - moreinfo On 8/29/23 16:07, Christoph Berg wrote: Your package build depends on libproj-dev but doesn't link to libproj nor include proj.h. Xastir uses libgeotiff-dev, which depends on libproj-dev, so dropping the B-D wouldn't make it not use it. The build dependencies then do better reflect libraries actually used. Since configure.ac contains an explicit check for libproj before it tries to check for libgeotiff, I think keeping the B-D does have some value. That's apparently to support static libraries which are not relevant for the Debian package: https://github.com/Xastir/Xastir/issues/47 Feel free to close this issue if you don't intend to apply the patch. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1035019: software-properties in Debian: Updated translations
Hey there, Sorry but I think I forgot to follow up on the email but I've updated the translations in the Vcs https://git.launchpad.net/software-properties/commit/?id=81efc82 It means the next time someone do an update in Debian the translations should be included Cheers, Sébastien Bacher Le 08/06/2023 à 01:20, AsciiWolf a écrit : Hello, Any update about this? Thanks! Regards, Daniel so 29. 4. 2023 v 14:20 odesílatel AsciiWolf napsal: Hello Matthias, I have noticed that the "Software & Updates" GTK application has most of its strings untranslated in Debian in our (Czech) language although it is fully translated in Ubuntu.[1] When looking at the bug tracker, it looks like that many other language translations have the same problem. When looking at the software-properties po files[2] at Debian Salsa GitLab, it looks like that they were never updated, only the pot template was. I am not sure how translations of this component are handled in Debian, but please consider syncing them from Ubuntu. Thanks! Regards, Daniel P.S. I have also reported this as a Debian issue here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035019 [1] https://translations.launchpad.net/ubuntu/lunar/+source/software-properties/+pots/software-properties [2] https://salsa.debian.org/pkgutopia-team/software-properties/-/tree/debian/master/po
Bug#1050768: xastir: Drop unused libproj-dev build dependency
Control: tags -1 moreinfo Re: Bas Couwenberg > Your package build depends on libproj-dev but doesn't link to libproj nor > include proj.h. Xastir uses libgeotiff-dev, which depends on libproj-dev, so dropping the B-D wouldn't make it not use it. Since configure.ac contains an explicit check for libproj before it tries to check for libgeotiff, I think keeping the B-D does have some value. Christoph
Bug#1033274: gnome-session: recommends xdg-desktop-portal-gnome and not depends
On Tue, Aug 29, 2023 at 9:51 AM Pablo Mazzini wrote: > I don't see other distributions (such as Fedora) having x-d-p-gnome as a > dependency of gnome-session. While it's interesting to see how other distros handle complex integration issues, I don't think this is a convincing point. > Shouldn't the user be able to choose to have a minimal setup without the > support for it? xdg-desktop-portal-gnome is implemented as a systemd user service which means it can be disabled. Or if you want to use a different portal backend, you can customize it with an appropriate user conf file starting in xdg-desktop-portal 1.17 which will be in Unstable soon. See https://lists.debian.org/debian-devel/2023/08/msg00311.html especially the Github link. I believe either of those methods could serve your need of having a more "minimal" setup without risking the user experience for other people. Thank you, Jeremy Bícha
Bug#1050810: ITP: asahi-scripts -- Asahi Linux maintenance scripts
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: asahi-scripts Version : 20230821 Upstream Authors: The Asahi Linux project URL : https://github.com/AsahiLinux/asahi-scripts * License : MIT Description : Asahi Linux maintenance scripts This package contains miscellaneous admin scripts from the Asahi Linux reference distro. Package will be maintained within the Debian Bananas Apple M1 team.
Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library
Le mar. 29 août 2023 à 15:43, Thomas Ward a écrit : > I apoligize I was thinking Lua deps not PCRE. > > However, I did more digging. OpenResty has been on NGINX cofe version > 1.21.4 for the longest time. They do not have PCRE2 support in their > system. As this is an OpenResty-originating module the 4th requirement as > stated in the linked GitHub issue is not met. > > I would not be so sure that "next update" will have a fix if OpenResty > core does not support PRCE2 (1.21.5 nginx introduced PCRE2 core > requirement/build fixes, OpenResty never inccuded that). The reason PCRE3 > is still used here in the Lua module is the custom workaround of mixing > PCRE2 nginx and PCRE3 Lua which use different build flags at compile time > with the linking options. > > Therefore, we need to not make assumptions and watch this closely. If > there is not movement in a reasonable time period, then we may have to drop > this module from Debian due to PCRE3 being obsolete. > Actually, openresty has started supporting nginx 1.25.1 recently: [feature: upgrade nginx core to 1.25.1 which supports HTTP3]( https://github.com/openresty/openresty/commit/6278b1aeae0593b17d3143aeb60a216f73b6bb1d)[feature: [upgrade nginx core to 1.25.1]( https://github.com/openresty/stream-lua-nginx-module/commit/d48f057f18eb1f33123bf62be49c735c5cb98f16 ) [upgrade nginx core to 1.25.1]( https://github.com/openresty/lua-nginx-module/commit/e69fd3de281f31804857aa6dc0b8e79055716138 ) > > Considering the work of the author of these patches, I'd be surprised if it wasn't finished soon (right now, only stream-lua-nginx has no support for pcre2).
Bug#1033274: gnome-session: recommends xdg-desktop-portal-gnome and not depends
I don't see other distributions (such as Fedora) having x-d-p-gnome as a dependency of gnome-session. Shouldn't the user be able to choose to have a minimal setup without the support for it? On Tue, Aug 29, 2023 at 10:59 AM Simon McVittie wrote: > On Tue, 29 Aug 2023 at 10:32:23 +0100, Pablo Mazzini wrote: > > > Therefore, the desktop session needs to depend on the portal that has > the > > > best integration. > > > > Why does this dependency needs to be specified in the gnome-session > package? > > Wouldn't gnome-core be a better place to specify this? > > gnome-core is a somewhat complete GNOME session with various utilities > included (an image viewer, a calculator, software updates, a terminal...), > while gnome-session is the minimal GNOME session containing only the > necessary infrastructure to log in to a working GNOME interface. > Their scope is rather different. > > x-d-p-gnome is more like behind-the-scenes desktop environment plumbing > than a user-facing application: various applications will not work > correctly without it. It also isn't very large. Having a working portal > backend is becoming similar to having a working D-Bus session bus, > or a working fd.o Notifications interface, or a working X11 or Wayland > display, or a working sound server: something that apps assume, such > that the app can't work correctly without it. > > Let me turn this around: what is your use-case for installing > gnome-session but not x-d-p-gnome, such that logging into a minimal > GNOME session is possible, but applications that require a working portal > backend will not work correctly while logged into that session? > > smcv >
Bug#1016438: chromium: Ozone wayland platfrom broken on aarch64 build after 97.0.4692.99-1
Thank you for fixing the arm64 issues. I can confirm Ozone wayland platform works well on arm64 since a few releases. On 3/19/23 21:03, Andres Salomon wrote: At the time this bug was filed, arm64 had various other issues. But they're all cleaned up now, and I'm wondering if this bug is still an issue for you with chromium 111. Also, --ozone-platform=wayland is what I use these days.
Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library
I apoligize I was thinking Lua deps not PCRE. However, I did more digging. OpenResty has been on NGINX cofe version 1.21.4 for the longest time. They do not have PCRE2 support in their system. As this is an OpenResty-originating module the 4th requirement as stated in the linked GitHub issue is not met. I would not be so sure that "next update" will have a fix if OpenResty core does not support PRCE2 (1.21.5 nginx introduced PCRE2 core requirement/build fixes, OpenResty never inccuded that). The reason PCRE3 is still used here in the Lua module is the custom workaround of mixing PCRE2 nginx and PCRE3 Lua which use different build flags at compile time with the linking options. Therefore, we need to not make assumptions and watch this closely. If there is not movement in a reasonable time period, then we may have to drop this module from Debian due to PCRE3 being obsolete. Note also GH issue https://github.com/openresty/lua-nginx-module/issues/1984 which has been asking for PCRE2 support for *years* now with no movement - this seems to be related and explains the 1.21.4 nginx lock on the OpenResty fork as one hurdle (a major one). Thomas Sent from my Galaxy Original message From: Jérémy Lal Date: 8/29/23 05:16 (GMT-05:00) To: Thomas Ward , 1050...@bugs.debian.org Cc: Bastian Germann Subject: Re: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library Le lun. 21 août 2023 à 19:09, Thomas Ward mailto:tew...@thomas-ward.net>> a écrit : Bastian: As I understand the module, for over a year now the latest Lua module from OpenResty requires LuaJIT to actually compile. See https://salsa.debian.org/nginx-team/libnginx-mod-http-lua/-/blob/main/debian/control#L8 where this is in the build deps. I have not tested removing the PCRE3 build dependency here, but because OpenResty has refused to change the Lua library to be any Lua support other than 5.1, it requires LuaJIT in order to provide 'continued support' for Lua 5.1 bytecode. These comments have no relation with this bug report. It is my understanding that the pcre2/pcre3 dependency may not be needed, but I have not deep dived into the Lua packaging recently. I'm running a test build from the tagged data in Salsa locally to see if it builds without the pcre2/pcre3 devel libraries in build-deps. pcre3 is *needed* by libnginx-mod-http-lua, which doesn't support pcre2 yet. However someone involved worked on it a few days ago: https://github.com/openresty/lua-nginx-module/pull/2221 so hopefully the situation will resolve itself in next update. Jérémy
Bug#1050809: Please package production stream 535.xx with DSC support
Package: nvidia-graphics-drivers Version: 525.125.06-2 Severity: wishlist Version 535.xx of the proprietary Nvidia drivers added support for Display Stream Compression (DSC) on linux (see https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/238). DSC is required to properly support certain combinations of high resolutions and refresh rates, such as 8K@60Hz, 4K@240Hz, 5120x1440@240Hz, 7680x2160@120Hz. Screens with these resolutions have been available on the market for more than two years, but were not supported at max specs by the linux proprietary drivers until now. Can you please package the latest 535.xx drivers? Thanks for your efforts!
Bug#1050771: linux-image-6.4.0-3-amd64: Error! Bad return status for module build on kernel: 6.4.0-3-amd64 (x86_64) r8168
Control: forcemerge -1 1050287 On Tuesday, 29 August 2023 07:35:29 CEST alirezaimi wrote: > Package: src:linux > Version: 6.4.11-1 I had already reassigned it to r8168-dkms and it appears the problem was already reported, so merging this bug with that one. signature.asc Description: This is a digitally signed message part.
Bug#999937: tup: depends on obsolete pcre3 library
On Tue, 31 Jan 2023 21:36:46 +0800 Bo YU wrote: The upstream has tried to switch pcre2[0], but the backporting is not easy, so maybe waiting a new release is good iead. [0]: https://github.com/gittup/tup/commit/f26bc1e8c0b87d9d351e062c7d27afbbdc53869d I have started a backport in git but there is at least one linker flag missing.
Bug#1050762: feedbackd-device-themes: Users are not informed about existing tools from the feedbackd package
hi Guido, On Tue, 29 Aug 2023, Guido Günther wrote: On Tue, Aug 29, 2023 at 02:12:36AM +0200, Boud Roukema wrote: I discovered from browsing sources and git histories that the debian 'feedbackd' package automatically installs several user-level programs that the user should be informed about: $ dpkg -L feedbackd | grep /usr/bin /usr/bin /usr/bin/fbcli /usr/bin/fbd-theme-validate Users are informed via the manpages. Currently in Debian/trixie: - 'man feedbackd' gives 'See also fbcli(1)', so yes, there's a footnote, but it could be made more prominent - 'man fbcli' says nothing about fbd-theme-validate I've added a feedback-themes manpage upstream so apropos and other tools make it easier to find. Thanks! I assume you mean your MR listed below: https://source.puri.sm/Librem5/feedbackd/-/merge_requests/112 At the Debian level, the only thing that seems to be missing in MR 112 is crosslinks to and from the 'feedbackd-device-themes' package, and a clarification if and how the user can (or cannot) use both a device-specific theme and a custom theme (in 'src/fbd-theme-expander.c' I see the line /* Device specific lookup only for default theme */). I assume that this could also better be handled at the upstream level. In fact, this particular bug #1050762 is for feedbackd-device-themes. PROPOSAL: Thanks for proposing changes but I'd rather not duplicate documentation as I don't want to maintain it in different places. There's nothing Sure, no problem. :) Debian specific here so it should be part of the upstream docs and trickle into Debian. If you find anything missing please propose an MR there but note https://source.puri.sm/Librem5/feedbackd/-/merge_requests/112 [..snip..] For 'feedbackd-device-themes', I'm happy to wait until things trickle down to Debian/Mobian and then see if something's missing. Regarding MRs at source.puri.sm, I followed the instructions at https://source.puri.sm/Purism/public-announcement/-/wikis/home for getting 'external access', but I didn't receive an email for confirmation. I posted a question at #community-librem-one:talk.puri.sm, but that channel seems to be inactive; #community-general:talk.puri.sm seems to be invitation-only. Should I email source puri.sm ? It's about the only official instruction I haven't tried yet. To see the effects of your custom.json file, you will need to restart the running "feedbackd" daemon, e.g. "killall feedbackd" and then close and reopen a gui such as chatty that automatically restarts "feedbackd". Then (or before you switch) you can check individual effects: Just as a remark: There's neither a need to kill feedbackd as it can reload it's config on SIGHUP nor do you need to restart apps. I'll try that - thanks. Cheers Boud
Bug#1050771: linux-image-6.4.0-3-amd64: Error! Bad return status for module build on kernel: 6.4.0-3-amd64 (x86_64) r8168
Control: reassign -1 r8168-dkms signature.asc Description: This is a digitally signed message part.
Bug#1050808: RFS: texlive-bin/2023.20230311.66589-4 -- TeX Live: Package split
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "texlive-bin": * Package name : texlive-bin Version : 2023.20230311.66589-4 Upstream contact : k...@freefriends.org * URL : https://www.tug.org/texlive/ * License : MIT, TeX-Live, GPL-2+ * Vcs : https://github.com/debian-tex/texlive-bin Section : tex The source builds the following binary packages: texlive-binaries - Binaries for TeX Live texlive-binaries-sse2 - Binaries for TeX Live (the JIT part) libkpathsea6 - TeX Live: path search library for TeX (runtime part) libkpathsea-dev - TeX Live: path search library for TeX (development part) libptexenc1 - TeX Live: pTeX encoding library libptexenc-dev - TeX Live: ptex encoding library (development part) libsynctex2 - TeX Live: SyncTeX parser library libsynctex-dev - TeX Live: SyncTeX parser library (development part) libtexlua53 - transitional package (lib) libtexlua53-5 - TeX Live: Lua 5.3, modified for use with LuaTeX libtexlua53-dev - transitional package (dev) libtexlua-dev - TeX Live: Lua 5.3, modified for use with LuaTeX (development part) libtexluajit2 - TeX Live: LuaJIT, modified for use with LuaJITTeX libtexluajit-dev - TeX Live: LuaJIT, modified for use with LuaJITTeX (development part) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/texlive-bin/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/texlive-bin/texlive-bin_2023.20230311.66589-4.dsc Changes since the last upload: texlive-bin (2023.20230311.66589-4) unstable; urgency=medium . * Split luajit based binaries into texlive-binaries-sse2 to make TL usable on non-sse2 capable CPU's at all (Closes: #1041148). Regards, -- Hilmar Preusse -- sigmentation fault signature.asc Description: PGP signature
Bug#1049981: RFS: cliphist/0.4.0-1 [ITP] -- wayland clipboard manager (program)
On 23/08/17 04:33PM, Ricardo Marliere wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "cliphist": > > * Package name : cliphist >Version : 0.4.0-1 >Upstream contact : Senan Kelly > * URL : https://github.com/sentriz/cliphist > * License : GPL-3.0 > * Vcs : https://salsa.debian.org/go-team/packages/cliphist >Section : golang > > The source builds the following binary packages: > > cliphist - wayland clipboard manager (program) > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/cliphist/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/c/cliphist/cliphist_0.4.0-1.dsc > > Changes for the initial release: > > cliphist (0.4.0-1) unstable; urgency=medium > . >* Initial release (Closes: 1049970) > > Any review is appreciated. Thank you! > > Regards, Ping! Can someone please take a look? CC golang team thanks, Ricardo signature.asc Description: PGP signature
Bug#1050807: r-bioc-biocstyle: autopkgtest fails since TL 2023
Source: r-bioc-biocstyle
Version: 2.28.0+dfsg-1
Severity: important
Dear Maintainer,
I just noticed, that the autopkgtest of your package fail, since I uploaded
TL 2023 to unstable [1].
178s You can now run (pdf)latex on ‘maketitle_test_1.tex’
179s Timing stopped at: 0.754 0.102 1.264
179s Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,
:
179s Running 'texi2dvi' on 'maketitle_test_1.tex' failed.
179s LaTeX errors:
179s ! LaTeX Error: Command \@raggedtwoe@everyselectfont undefined.
The reason seems to be a change in the ragged2e package, which does not provide
the
\@raggedtwoe@everyselectfont command any more [2]. Hence the following code in
Bioconductor.sty does not work any more:
\renewcommand{\@raggedtwoe@everyselectfont}{%
\if@raggedtwoe@spaceskip
\ifdim\fontdimen\thr@@\font=\z@\relax
\if@inside@soul
As first step I'd try to replace the \renewcommand by a \newcommand. On the
long run upstream should evaluate if the patch is still needed or if the issue
has been solved in the meantime.
Hilmar
[1] https://ci.debian.net/packages/r/r-bioc-biocstyle/testing/amd64/
[2]
https://gitlab.com/TeXhackse/ragged2e/-/commit/031fc83cf10b663d820881ded59c8f304631c37c
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-3-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
--
sigmentation fault
signature.asc
Description: PGP signature
Bug#994722: apt-show-versions: Syntax error on or around line 378.
Hi Richard, thanks for finding that issue and providing a fix. Am 08.08.23 um 20:34 schrieb Richard Lewis: I believe the following patch fixes this bug, and the main issue in 883766 (but not the bit about the version number) Regards Christoph OpenPGP_signature Description: OpenPGP digital signature
Bug#1050806: O: debianutils -- Essential utilities specific to Debian
Package: wnpp After I have made a dog's breakfast of debianutils' postinst and fixed it, I do not feel inclined to maintain that essential package any longer. I cannot afford the response time that it takes when people's chroots break. So I orphan debianutils. So please consider adopting if you want to take the chance and have a good knowledge of the tools contained in debianutils.
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
Package: dhcpcd-base Version: 9.4.1-22 Severity: critical Tags: security Justification: breaks unrelated software X-Debbugs-Cc: Debian Security Team When the dhcpcd DHCPv4 client receives a zero-length UDP packet on port 68, the "network proxy" dhcpcd process exits with status 0. dhcpcd then stops all network activity: It does not renew leases and eventually expires the current lease (unless it has infinite duration) and removes the IP address, leaving the system without networking. This bug can be triggered remotely over the internet from any UDP port and is critical on an internet-facing system that needs DHCP to get an IP address, such as a gateway, a dedicated server or a VM. This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2 (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as upstream fixed it in 10.0.2: Upstream Bug report: https://github.com/NetworkConfiguration/dhcpcd/issues/179 Upstream Fix: https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae This patch does not apply cleanly to 9.4.1 because the privsep structure changed in 10.0.2. It's likely that only the src/privsep.c hunks about len == 0 and eloop_exit() needs to be backported, the other changes are just here to avoid compiler warnings about unused parameters. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 dhcpcd-base depends on: ii adduser 3.134 ii libc6 2.36-9+deb12u1 ii libudev1 252.12-1~deb12u1 Versions of packages dhcpcd-base recommends: pn wpasupplicant Versions of packages dhcpcd-base suggests: ii openresolv [resolvconf] 3.12.0-3 -- Configuration Files: /etc/dhcpcd.conf changed [not included] -- no debconf information
Bug#1050602: linux: kernel 6.4.11-1 does not recognize TPM on lenovo 14IAU7 (Flex 7i)
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=217804 https://lore.kernel.org/stable/20230822231510.2263255-1-jar...@kernel.org/ Control: tag -1 upstream On Saturday, 26 August 2023 23:26:51 CEST Justin King-Lacroix wrote: > Looks like this is an upstream bug that affects all Alder Lake (and maybe > newer) systems. > > https://bugzilla.kernel.org/show_bug.cgi?id=217804 Thanks, I added that and also what appears to be the most current patch submission which will hopefully fix that issue. The issue is also on Thorsten Leemhuis' radar: https://lore.kernel.org/stable/fcf2f600-d1f0-de14-956b-4d4f3f0cb...@leemhuis.info/ signature.asc Description: This is a digitally signed message part.
Bug#1050784: a quick fix/revert would be appreciated
Control: fixed -1 5.11 Am 29.08.23 um 12:34 schrieb Bastian Germann: I will upload a new version as soon as Helmut has agreed to the change. I have done so. For reference, I will keep this bug open for some time because many peapole were affected.
Bug#1050352: backside USB-ports stop working after some time
On Tuesday, 29 August 2023 07:43:40 CEST Rolf Reintjes wrote: > I could isolate the problem causing code in the debian patches on file > > drivers/iommu/intel/iommu.c > > With this change > > rolf@i7-5820K-debian-testing:~/kernel/linux-source-6.4/drivers/iommu/intel$ > diff iommu.c.debian iommu.c > 286c286 > < int dmar_disabled = IS_ENABLED(CONFIG_INTEL_IOMMU_DEFAULT_OFF); > --- > > > int dmar_disabled = !IS_ENABLED(CONFIG_INTEL_IOMMU_DEFAULT_ON); > > the problem is not there. Excellent, thanks for the analyses. On Monday, 28 August 2023 16:46:02 CEST Rolf Reintjes wrote: > I would appreciate further advice and guidance. Have patience. When someone with the needed knowledge has time to look into this issue, they will. But we can't make claims on how people spend their free time. signature.asc Description: This is a digitally signed message part.
Bug#1050804: lxqt-session: please provide an lxqt-portals.conf for xdg-desktop-portal
Source: lxqt-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/lxqt-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.
As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for LXQt
(https://github.com/lxqt/xdg-desktop-portal-lxqt exists, but I couldn't
find an ITP for it). Please add an lxqt-portals.conf to tell x-d-p more
explicitly what backends LXQt is meant to be using by default.
For example, if the intention is to try to use the -lxqt backend, falling
back to -gtk if -lxqt isn't installed or doesn't know how to do something,
the way to write that would be:
[preferred]
default=lxqt;gtk;
The desktop environment (either lxqt-session or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
Bug#1050803: mate-session-manager: please provide a mate-portals.conf for xdg-desktop-portal
Package: mate-session-manager
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/mate-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.
As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for MATE
(although I see there's an ITP open for x-d-p-xapp, #1038946). Please
add an mate-portals.conf to tell x-d-p more explicitly what backends
MATE is meant to be using by default.
For example, if the intention is to try to use the -xapp backend, falling
back to -gtk if -xapp isn't installed or doesn't know how to do something,
the way to write that would be:
[preferred]
default=xapp;gtk;
The desktop environment (either mate-session-manager or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
Bug#1050802: xfce4-session: please provide an xfce-portals.conf for xdg-desktop-portal
Source: xfce4-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/xfce-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.
As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for XFCE
(although I see there's an ITP open for x-d-p-xapp, #1038946). Please
add an xfce-portals.conf to tell x-d-p more explicitly what backends
XFCE is meant to be using by default.
For example, if the intention is to try to use the -xapp backend, falling
back to -gtk if -xapp isn't installed or doesn't know how to do something,
the way to write that would be:
[preferred]
default=xapp;gtk;
The desktop environment (either xfce4-session or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
Bug#1050801: cinnamon-common: please provide an x-cinnamon-portals.conf for xdg-desktop-portal
Package: cinnamon-common
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/x-cinnamon-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.
As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for Cinnamon
(although I see there's an ITP open for x-d-p-xapp, #1038946). Please
add an x-cinnamon-portals.conf to tell x-d-p more explicitly what backends
Cinnamon is meant to be using by default.
For example, if the intention is to try to use the -xapp backend, falling
back to -gtk if -xapp isn't installed or doesn't know how to do something,
the way to write that would be:
[preferred]
default=xapp;gtk;
The desktop environment (either cinnamon-common or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
Bug#1050800: openbox-lxde-session: please provide an lxde-portals.conf for xdg-desktop-portal
Package: openbox-lxde-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/lxde-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.
As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for LXDE
(https://github.com/lxqt/xdg-desktop-portal-lxqt exists, but I couldn't
find an ITP for it). Please add an lxde-portals.conf to tell x-d-p more
explicitly what backends LXDE is meant to be using by default.
For example, if the intention is to try to use the -lxqt backend, falling
back to -gtk if -lxqt isn't installed or doesn't know how to do something,
the way to write that would be:
[preferred]
default=lxqt;gtk;
The desktop environment (either openbox-lxde-session or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
Bug#1050799: gnome-session-flashback: please provide a gnome-flashback-portals.conf for xdg-desktop-portal
Package: gnome-session-flashback
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
Forwarded: https://gitlab.gnome.org/GNOME/gnome-flashback/-/issues/91
xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/gnome-flashback-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
In the case of gnome-session-flashback, XDG_CURRENT_DESKTOP is set to
GNOME-Flashback:GNOME, so in the absence of other configuration it would
use the gnome-portals.conf from gnome-session (if installed). However,
because GNOME Flashback uses metacity rather than GNOME Shell, its mix
of desired portals is probably somewhat different from the full-fat GNOME
session, so probably it should have its own gnome-flashback-portals.conf
that doesn't try to make use of GNOME-Shell- or Mutter-specific interfaces?
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
was the equivalent change for gnome-session.
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
Bug#1050784: a quick fix/revert would be appreciated
Hi Holger, Am 29.08.23 um 12:30 schrieb Holger Levsen: a quick fix/revert in unstable would be appreciated, this has broken all of tests.reproducible-builds.org and I guess other test systems as well. I will upload a new version as soon as Helmut has agreed to the change.
Bug#1050798: plasma-workspace: please provide a kde-portals.conf for xdg-desktop-portal
Source: plasma-workspace
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
Control: affects -1 plasma-mobile
xdg-desktop-portal 1.17.x (currently in experimental) introduces a new
way to select which portals will be used for which desktop environments,
modelled on mimeapps.list:
- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/kde-portals.conf
- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal
Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details of the search mechanism.
As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that. Please add a kde-portals.conf
to tell x-d-p more explicitly what backends Plasma is meant to be using
by default, and test with x-d-p from experimental to check that it's
working as expected.
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
is an example of the equivalent change in GNOME.
In KDE's case, it looks as though plasma-workspace and plasma-mobile share
the DesktopNames=KDE name but plasma-mobile depends on plasma-workspace,
so kde-portals.conf can probably be in plasma-workspace without any
further changes required in plasma-mobile?
I believe the file contents can be as simple as this (untested):
[preferred]
default=kde;
plasma-workspace (and plasma-mobile?) should probably have at least a
Recommends on xdg-desktop-portal-kde for this (see also #1019918).
Thanks,
smcv
--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html
