Bug#762821: gnokii randomly crashes while sending SMS
Can you still reproduce this issue with a current Debian system? On Thu, 25 Sep 2014 14:18:57 +0200 "Jost Menke" wrote: Package: gnokii Version: 0.6.30+dfsg-1 gnokii smsd randomly crashes while sending SMS with Nokia 5110 connected to ttyS0. Here is a backtrace: 8<--- *** glibc detected *** /usr/sbin/smsd: double free or corruption (fasttop): 0x01d04d70 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x76aa6)[0x7f0f8608eaa6] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f0f8609384c] /usr/sbin/smsd[0x403098] /usr/sbin/smsd[0x40351a] /usr/sbin/smsd[0x4038d0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7f0f86616b50] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f0f860f3e6d] === Memory map: 0040-00405000 r-xp 08:01 665697 /usr/sbin/smsd 00605000-00606000 rw-p 5000 08:01 665697 /usr/sbin/smsd 00606000-006c8000 rw-p 00:00 0 01d0-01e32000 rw-p 00:00 0 [heap] 7f0f7c00-7f0f7c021000 rw-p 00:00 0 7f0f7c021000-7f0f8000 ---p 00:00 0 7f0f834d8000-7f0f834ed000 r-xp 08:01 4980778 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f0f834ed000-7f0f836ed000 ---p 00015000 08:01 4980778 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f0f836ed000-7f0f836ee000 rw-p 00015000 08:01 4980778 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f0f836fb000-7f0f837fe000 rw-p 00:00 0 7f0f837fe000-7f0f837ff000 ---p 00:00 0 7f0f837ff000-7f0f83fff000 rw-p 00:00 0 7f0f83fff000-7f0f8400 ---p 00:00 0 7f0f8400-7f0f8480 rw-p 00:00 0 7f0f8480-7f0f84802000 r-xp 08:01 1319958 /usr/lib/smsd/libsmsd_file.so 7f0f84802000-7f0f84a02000 ---p 2000 08:01 1319958 /usr/lib/smsd/libsmsd_file.so 7f0f84a02000-7f0f84a03000 rw-p 2000 08:01 1319958 /usr/lib/smsd/libsmsd_file.so 7f0f84a08000-7f0f84a0d000 r-xp 08:01 658833 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0f84a0d000-7f0f84c0c000 ---p 5000 08:01 658833 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0f84c0c000-7f0f84c0d000 rw-p 4000 08:01 658833 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0f84c1-7f0f84c12000 r-xp 08:01 658831 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0f84c12000-7f0f84e12000 ---p 2000 08:01 658831 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0f84e12000-7f0f84e13000 rw-p 2000 08:01 658831 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0f84e18000-7f0f84e37000 r-xp 08:01 658835 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0f84e37000-7f0f85036000 ---p 0001f000 08:01 658835 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0f85036000-7f0f85037000 r--p 0001e000 08:01 658835 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0f85037000-7f0f85038000 rw-p 0001f000 08:01 658835 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0f85038000-7f0f85042000 r-xp 08:01 670485 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 7f0f85042000-7f0f85241000 ---p a000 08:01 670485 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 7f0f85241000-7f0f85242000 r--p 9000 08:01 670485 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 7f0f85242000-7f0f85243000 rw-p a000 08:01 670485 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 7f0f85248000-7f0f8524f000 r-xp 08:01 4981052 /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4 7f0f8524f000-7f0f8544e000 ---p 7000 08:01 4981052 /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4 7f0f8544e000-7f0f8544f000 r--p 6000 08:01 4981052 /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4 7f0f8544f000-7f0f8545 rw-p 7000 08:01 4981052 /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4 7f0f8545-7f0f85451000 rw-p 00:00 0 7f0f85458000-7f0f85472000 r-xp 08:01 670477 /usr/lib/x86_64-linux-gnu/libbluetooth.so.3.12.0 7f0f85472000-7f0f85671000 ---p 0001a000 08:01 670477 /usr/lib/x86_64-linux-gnu/libbluetooth.so.3.12.0 7f0f85671000-7f0f85672000 r--p 00019000 08:01 670477 /usr/lib/x86_64-linux-gnu/libbluetooth.so.3.12.0 7f0f85672000-7f0f85675000 rw-p 0001a000 08:01 670477 /usr/lib/x86_64-linux-gnu/libbluetooth.so.3.12.0 7f0f85678000-7f0f857ad000 r-xp 08:01 658840 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 7f0f857ad000-7f0f859ad000 ---p 00135000 08:01 658840 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 7f0f859ad000-7f0f859b3000 rw-p 00135000 08:01 658840
Bug#915289: Files never arrived
They are listed, but not present: $ dlocate --filename-only cron_now | xargs ls -l ls: cannot access '/usr/sbin/cron_now': No such file or directory ls: cannot access '/usr/share/man/man8/cron_now.8.gz': No such file or directory Also make sure to mention them on the other man pages' SEE ALSO.
Bug#810416: gnokii: please switch to libusb 1.0
Control: tags -1 wontfix Upstream is no longer active and gnokii does not have libusb 1.0 support.
Bug#1050668: python3: Fails to import/work with SSL module due to ImportError
python3.11 has now fully migrated. I didn't read the bug properly before, but the issue was that you had part of your python3.11 installation from unstable, and part from testing. libpython3.11-minimal was a newer version than your python3.11-minimal I think. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1050773: metview: Drop unused libproj-dev build dependency
On 8/29/23 07:40, Bas Couwenberg wrote: Your package build depends on libproj-dev but doesn't link to libproj nor include proj.h. The same goes for libgeotiff-dev & libnetcdf-c++4-dev. The attached patch also drops those unused build dependencies. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 diff -Nru metview-5.19.2/debian/changelog metview-5.19.2/debian/changelog --- metview-5.19.2/debian/changelog 2023-07-15 10:28:25.0 +0200 +++ metview-5.19.2/debian/changelog 2023-08-29 07:24:56.0 +0200 @@ -1,3 +1,10 @@ +metview (5.19.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused build dependencies. + + -- Bas Couwenberg Tue, 29 Aug 2023 07:24:56 +0200 + metview (5.19.2-1) unstable; urgency=medium * New upstream release diff -Nru metview-5.19.2/debian/control metview-5.19.2/debian/control --- metview-5.19.2/debian/control 2023-07-15 10:28:25.0 +0200 +++ metview-5.19.2/debian/control 2023-08-29 07:24:56.0 +0200 @@ -48,13 +48,12 @@ swig, libexpat1-dev, libterralib-dev (>= 4.3.0+dfsg.2-8), - libproj-dev, libqt5svg5-dev, + libqt5svg5-dev, libgd-dev, imagemagick, - libnetcdf-dev, libnetcdf-c++4-dev, + libnetcdf-dev, flextra, - flexpart, - libgeotiff-dev + flexpart Standards-Version: 4.6.2 Homepage: https://confluence.ecmwf.int/display/METV/Metview Vcs-Browser: https://salsa.debian.org:/science-team/metview.git
Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41
Package: webkit2gtk Version: 2.41.90-1 Severity: high The new webkitgtk is blocked in Ubuntu/mantic-proposed because the surf autopkgtest are failing with the new version. The issue seems to be there in Debian as well https://ci.debian.net/packages/s/surf/unstable/amd64/ Every try since webkit2gtk/2.41.5-1 has been failing it seems
Bug#1050778: libterralib: Drop unused libshp-dev build dependency
Source: libterralib Version: 4.3.0+dfsg.2-12.1 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libshp-dev but doesn't link to libshp. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru libterralib-4.3.0+dfsg.2/debian/changelog libterralib-4.3.0+dfsg.2/debian/changelog --- libterralib-4.3.0+dfsg.2/debian/changelog 2019-08-26 19:28:30.0 +0200 +++ libterralib-4.3.0+dfsg.2/debian/changelog 2023-08-29 09:41:17.0 +0200 @@ -1,3 +1,9 @@ +libterralib (4.3.0+dfsg.2-13) UNRELEASED; urgency=medium + + * Drop unused libshp-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 09:41:17 +0200 + libterralib (4.3.0+dfsg.2-12.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libterralib-4.3.0+dfsg.2/debian/control libterralib-4.3.0+dfsg.2/debian/control --- libterralib-4.3.0+dfsg.2/debian/control 2019-08-26 19:27:36.0 +0200 +++ libterralib-4.3.0+dfsg.2/debian/control 2023-08-29 09:40:37.0 +0200 @@ -9,7 +9,6 @@ qt5-qmake, qtbase5-dev, zlib1g-dev, - libshp-dev, libdxflib-dev (>= 3.12.2), default-libmysqlclient-dev, libpq-dev,
Bug#1050779: coda: Drop unused libnetcdf-dev build dependency
Source: coda Version: 2.24.2-1 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru coda-2.24.2/debian/changelog coda-2.24.2/debian/changelog --- coda-2.24.2/debian/changelog2023-02-09 14:45:43.0 +0100 +++ coda-2.24.2/debian/changelog2023-08-29 10:05:24.0 +0200 @@ -1,3 +1,10 @@ +coda (2.24.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 10:05:24 +0200 + coda (2.24.2-1) unstable; urgency=medium * New upstream release diff -Nru coda-2.24.2/debian/control coda-2.24.2/debian/control --- coda-2.24.2/debian/control 2023-02-09 14:45:43.0 +0100 +++ coda-2.24.2/debian/control 2023-08-29 10:05:10.0 +0200 @@ -8,7 +8,6 @@ dh-sequence-python3, python3-all, python3-numpy, - libnetcdf-dev, netcdf-bin, libhdf5-dev | libhdf5-serial-dev, libaec-dev, libpcre3-dev,
Bug#1050780: amd64-microcode: AMD Ryzen 9 5900HX Speculative Return Stack Overflow
Package: amd64-microcode Version: 3.20230808.1.1 Severity: important Dear Maintainer, I am a bit concerned about a security warning I find on my debian trixie. I had applied the software mitigation as per some links I found googling around GRUB_CMDLINE_LINUX_DEFAULT="quiet usbcore.autosuspend=-1 nvidia- drm.modeset=1 tsc=nowatchdog pcie_aspm=off spec_store_bypass_disable=on" I would like to find a microcode update that takes care of this issue, if possible. uname -a Linux ghost 6.5.0 #2 SMP PREEMPT_DYNAMIC Mon Aug 28 12:19:05 CEST 2023 x86_64 GNU/Linux [0.069591]: Speculative Return Stack Overflow IBPB-extending microcode not applied! [0.069592] Speculative Return Stack Overflow: Mitigation: safe RET, no microcode [3.673179] microcode: CPU0: patch_level=0x0a5c [3.673185] microcode: CPU8: patch_level=0x0a5c [3.673186] microcode: CPU9: patch_level=0x0a5c [3.673186] microcode: CPU11: patch_level=0x0a5c [3.673186] microcode: CPU10: patch_level=0x0a5c [3.673186] microcode: CPU1: patch_level=0x0a5c [3.673193] microcode: CPU3: patch_level=0x0a5c [3.673193] microcode: CPU2: patch_level=0x0a5c [3.673193] microcode: CPU4: patch_level=0x0a5c [3.673193] microcode: CPU5: patch_level=0x0a5c [3.673196] microcode: CPU7: patch_level=0x0a5c [3.673196] microcode: CPU6: patch_level=0x0a5c [3.673196] microcode: CPU13: patch_level=0x0a5c [3.673196] microcode: CPU12: patch_level=0x0a5c [3.673201] microcode: CPU14: patch_level=0x0a5c [3.673201] microcode: CPU15: patch_level=0x0a5c [3.673219] microcode: Microcode Update Driver: v2.2. grep 'model\|microcode' /proc/cpuinfo model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c model : 80 model name : AMD Ryzen 9 5900HX with Radeon Graphics microcode : 0xa5c thanks in advance -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 amd64-microcode depends on no packages. Versions of packages amd64-microcode recommends: ii initramfs-tools 0.142 amd64-microcode suggests no packages. -- no debconf information
Bug#964082: parsinsert fails it's tests when built with -O2 gcc-13
Hi Étienne, Am Mon, Aug 28, 2023 at 10:09:42PM +0200 schrieb Étienne Mollier: > > The change even fixed LTO builds. :) Nice. > On the other hand, well, the hardening is gone. :( > > The package looks to range on the performance critical side of > the spectrum, so this is probably an acceptable trade-off. This > is probably symptomatic of a deeper problem in the source code > though, but I don't really expect to pinpoint the exact cause > without help from upstream. Definitely. We do not have resources to dive that deeply in "random" packages. > This is documented in d/rules. I'll also add the necessary > lintian overrides and blhc markers to reduce the noise caused by > the change in automated checks. Thanks a lot for the tough work Andreas. -- http://fam-tille.de
Bug#1050782: linux-image-armmp: Please enable the tca8418_keypad module for PocketCHIP support
Package: linux-image-armmp X-Debbugs-Cc: mich...@hotplate.co.nz Version: 6.1.38-4 Severity: normal Dear Maintainer, Could we have the module "tca8418_keypad" enabled in the Debian armmp kernel? Currently the NTC CHIP board is listed as "Stable untested" on https://wiki.debian.org/InstallingDebianOn/Allwinner. I'm troubleshooting some small issues running Bookworm with the NTC PocketCHIP carrier board that was commonly distributed along with the CHIP. The PocketCHIP board adds battery, screen and keyboard peripherals to the CHIP similar to a Beaglebone cape or Pi hat. The PocketCHIP keyboard is supported by the tca8418_keypad module. Currently it is not enabled in the armmp kernel configuration: root@djubre:~# grep TCA8418 /boot/config-6.1.0-11-armmp # CONFIG_KEYBOARD_TCA8418 is not set If we had this module enabled we would have complete out-of-the-box support for all of the PocketCHIP's hardware from Bookworm onwards. The following output is from a PocketCHIP R8 system running the latest linux-image-armmp tainted by building the tca8418_keypad module manually to confirm it works: -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 6.1.0-11-armmp (SMP w/1 CPU thread) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.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 linux-image-armmp depends on: ii linux-image-6.1.0-11-armmp 6.1.38-4 linux-image-armmp recommends no packages. linux-image-armmp suggests no packages. -- no debconf information
Bug#1050783: Regression in 3.1.0 breaks Cumin
Source: pyparsing Version: 3.1.0-1 Severity: important pyparsing 3.1.0 introduced a regression which breaks src:cumin (#1042262), this has been reported at https://github.com/pyparsing/pyparsing/issues/502 and was fixed in 3.1.1. Cheers, Moritz
Bug#1050784: debianutils: fails to reinstall / will fail to install 5.11
Package: debianutils Version: 5.9 Severity: serious Justification: fails to reinstall Hi Bastian, I appreciate that you want to help, but what you are doing to debianutils causes work to other developers. You added code to support installation of debianutils on unmerged systems. That configuration is no longer supported in trixie and beyond. While you may support it, that support comes at a significant cost to others and I question whether that is a good trade-off. Please consider reverting it and cleaning up the things it leaves behind. Also please test your build more extensively before uploading. Thanks in advance. What is broken precisely? You already uploaded 5.10 and it fixes some things. Thanks. For instances, Johannes reported that it broke DPKG_ROOT via #1050752, but you ended up only fixing the postinst and the postrm still doesn't do it. This is a normal bug. Sven reported that on unmerged systems the symlinks would be wrong via #1050725 and you also fixed it. Now they point at the right location, but you still misspelled tempfile as tmpfile. (Thanks to Aurelien for spotting this.) That spelling mistake results in a fatal issue. Since /usr/bin/tmpfile does not exist (neither on merged nor unmerged ones), you create a symlink /bin/tmpfile -> /usr/bin/tmpfile. On an unmerged system, this is a dead link. When running postinst again, /usr/bin/tmpfile still does not exist, so it tries to link again and that makes postinst fail. On a merged system /usr/bin/tmpfile now resolves to /bin/tmpfile, which resolves to /usr/bin/tmpfile, because /bin is a symlink pointing to /usr/bin. This is a loop and the existence test likewise returns false-ish leading to the same postinst failure. If you were doing a no-change upload of debianutils now, it would break on the upgrade. You can already experience this by reinstalling the package: mmdebstrap unstable /dev/null --chrooted-customize-hook="apt-get install -y --reinstall debianutils" ... Unpacking debianutils (5.10) over (5.10) ... Setting up debianutils (5.10) ... ln: failed to create symbolic link '/usr/bin/tmpfile': File exists dpkg: error processing package debianutils (--configure): installed debianutils package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: debianutils E: Sub-process /usr/bin/dpkg returned an error code (1) This is really bad. On unmerged systems that happen to have debianutils 5.9 installed, /usr/bin/tmpfile and /usr/bin/run-parts now point to /bin/which, which does exist. The 5.10 postinst will not rectify this. Please also handle that case. As you fix all of these issues, please thoroughly test your update. In particular, test upgrades from 5.8-1, 5.9 and 5.10. If you want to keep supporting unmerged system (something I recommend not to do), repeat all of those tests with unmerged chroots. piuparts can assist somewhat here. I strongly recommend that you get your changes peer-reviewed before uploading. It is just so easy to get wrong. A peer review is not an admission of stupidity or otherwise negative. When I changed debootstrap or debhelper in non-trivial ways recently, I also ensured to have thorough peer reviews. I volunteer to review your changes. Let me know if you want me to do it. Helmut
Bug#1050785: kst: Drop unused libnetcdf-dev build dependency
Source: kst Version: 2.0.8-5 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru kst-2.0.8/debian/changelog kst-2.0.8/debian/changelog --- kst-2.0.8/debian/changelog 2021-11-14 21:21:57.0 +0100 +++ kst-2.0.8/debian/changelog 2023-08-29 10:27:11.0 +0200 @@ -1,3 +1,9 @@ +kst (2.0.8-6) UNRELEASED; urgency=medium + + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 10:27:11 +0200 + kst (2.0.8-5) unstable; urgency=medium * QA upload. diff -Nru kst-2.0.8/debian/control kst-2.0.8/debian/control --- kst-2.0.8/debian/control2021-11-14 21:14:17.0 +0100 +++ kst-2.0.8/debian/control2023-08-29 10:27:06.0 +0200 @@ -10,7 +10,6 @@ libgetdata-dev, libgsl-dev, libmatio-dev, - libnetcdf-dev, pkg-config, qtbase5-dev, qtbase5-dev-tools,
Bug#1050786: cgget: buffer overflow detected; Aborted (core dumped)
Package: cgroup-tools
Version: 2.0.2-2
Severity: important
I was casually using the tools to explore v2 configuration and found
that a simple:
$ cgget -a
*** buffer overflow detected ***: terminated
Aborted (core dumped)
crashes. Under strace I see:
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cpuset.mems.effective",
{st_mode=S_IFREG|0444, st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cgroup.subtree_control",
{st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/memory.reclaim", {st_mode=S_IFREG|0200,
st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cgroup.max.depth", {st_mode=S_IFREG|0644,
st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cgroup.pressure", {st_mode=S_IFREG|0644,
st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/io.stat", {st_mode=S_IFREG|0444,
st_size=0, ...}, 0) = 0
openat(AT_FDCWD, "/sys/fs/cgroup/io.stat", O_RDONLY|O_CLOEXEC) = 4
newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
read(4, "8:64 rbytes=2230784 wbytes=0 rio"..., 4096) = 4096
close(4)= 0
writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow detected",
iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}], 3*** buffer overflow
detected ***: terminated
) = 45
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fdf94e01000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()= 138582
getpid()= 138582
tgkill(138582, 138582, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=138582, si_uid=1000} ---
+++ killed by SIGABRT (core dumped) +++
Aborted (core dumped)
-- Package-specific info:
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0+debian+tj (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cgroup-tools depends on:
ii libc6 2.36-9+deb12u1
ii libcgroup2 2.0.2-2
cgroup-tools recommends no packages.
cgroup-tools suggests no packages.
-- no debconf information
Bug#1050787: abinit: Drop unused libnetcdf-dev build dependency
Source: abinit Version: 9.6.2-1 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru abinit-9.6.2/debian/changelog abinit-9.6.2/debian/changelog --- abinit-9.6.2/debian/changelog 2022-01-02 22:53:06.0 +0100 +++ abinit-9.6.2/debian/changelog 2023-08-29 10:34:01.0 +0200 @@ -1,3 +1,10 @@ +abinit (9.6.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 10:34:01 +0200 + abinit (9.6.2-1) unstable; urgency=medium * New upstream release. diff -Nru abinit-9.6.2/debian/control abinit-9.6.2/debian/control --- abinit-9.6.2/debian/control 2021-10-01 21:27:53.0 +0200 +++ abinit-9.6.2/debian/control 2023-08-29 10:33:59.0 +0200 @@ -14,7 +14,6 @@ help2man, libfftw3-dev, libhdf5-dev, - libnetcdf-dev, libnetcdff-dev, libssl-dev, libxc-dev,
Bug#1050718: logrotate without copytruncate is nicer to aide
On Tue, Aug 29, 2023 at 08:10:43AM +0200, Marc Haber wrote: > On Mon, Aug 28, 2023 at 05:27:12PM +, Holger Levsen wrote: > > On Mon, Aug 28, 2023 at 04:27:36PM +0200, Marc Haber wrote: > > > Please consider applying this in Debian's munin-node package. If you > > > choose to not do this (which I would fully understand, I know that I am > > > asking a lot), [...] > > why do you think you are asking *a lot*? Because of the restarting? or? > Because of restarting and deviating from upstream's way, yes. And to > adapt to a totally unrelated package's shortcomings. ic, thanks. I think restarting munin-node is fine (shrugs) and might also help with logrotate, so meh, I guess I'll take this patch and probably might suggest it upstream too. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 三人成虎- Three men make a tiger. In other words, if one guy says "there's a tiger over there" you might not believe them, if three guys in a row all say this- you think there's a tiger there. A lie, repeated often enough, will be accepted as truth. signature.asc Description: PGP signature
Bug#1050788: cdftools: Drop unused libnetcdf-dev build dependency
Source: cdftools Version: 4.0.0-2 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru cdftools-4.0.0/debian/changelog cdftools-4.0.0/debian/changelog --- cdftools-4.0.0/debian/changelog 2022-04-21 16:02:49.0 +0200 +++ cdftools-4.0.0/debian/changelog 2023-08-29 10:44:48.0 +0200 @@ -1,3 +1,10 @@ +cdftools (4.0.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 10:44:48 +0200 + cdftools (4.0.0-2) unstable; urgency=medium * Update d/watch file for new file format (v4.0.0.tar.gz) diff -Nru cdftools-4.0.0/debian/control cdftools-4.0.0/debian/control --- cdftools-4.0.0/debian/control 2022-04-21 16:02:49.0 +0200 +++ cdftools-4.0.0/debian/control 2023-08-29 10:44:47.0 +0200 @@ -6,7 +6,6 @@ gfortran | fortran-compiler, texlive-latex-base, texlive-latex-recommended, - libnetcdf-dev, libnetcdff-dev Standards-Version: 4.6.0 Homepage: https://github.com/meom-group/CDFTOOLS
Bug#1050789: handbrake: 1.6.1+ds1-2 not seeing Vorbis audio tracks.
Package: handbrake Version: 1.6.1+ds1-2 Severity: important Dear Maintainer, After upgrading to this version, handbrake appears to have lost the ability to detect and use Vorbis-encoded audio in source files. When opening such a file it pauses (breifly for small files, longer for large files) and eventually presents an audio-free processing environment. The Add button also fails to add the audio track. A source file with MP3 audio encoded works as expected. Re-coding media with another program to use high-bitrate MP3 then re-passing it through Handbrake for final compression also works. Thank you for looking into this matter. -- System Information: Debian Release: trixie APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages handbrake depends on: ii libass91:0.17.1-1 ii libavcodec-extra60 [libavcodec60] 7:6.0-6 ii libavfilter9 7:6.0-6 ii libavformat60 7:6.0-6 ii libavutil587:6.0-6 ii libbluray2 1:1.3.4-1 ii libc6 2.37-7 ii libcairo2 1.16.0-7 ii libdvdnav4 6.1.1-1 ii libdvdread86.1.3-1 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.2-1 ii libgstreamer-plugins-base1.0-0 1.22.5-1 ii libgstreamer1.0-0 1.22.5-1 ii libgtk-3-0 3.24.38-4 ii libgudev-1.0-0 237-2 ii libjansson42.14-2 ii libpango-1.0-0 1.51.0+ds-2 ii libswresample4 7:6.0-6 ii libswscale77:6.0-6 ii libtheora0 1.1.1+dfsg.1-16.1+b1 ii libturbojpeg0 1:2.1.5-2 ii libva-drm2 2.19.0-1 ii libva2 2.19.0-1 ii libvorbis0a1.3.7-1 ii libvorbisenc2 1.3.7-1 ii libvpl22023.3.0-1 ii libx264-1642:0.164.3095+gitbaee400-3+b1 ii libx265-1993.5-2+b1 ii libxml22.9.14+dfsg-1.3 Versions of packages handbrake recommends: ii gstreamer1.0-libav 1.22.5-1 pn gstreamer1.0-pulseaudio | gstreamer1.0-alsa ii gstreamer1.0-x 1.22.5-1 handbrake suggests no packages. -- no debconf information
Bug#1050791: etsf-io: Drop unused libnetcdf-dev build dependency
Source: etsf-io
Version: 1.0.4-5
Severity: normal
Tags: patch
Dear Maintainer,
Your package build depends on libnetcdf-dev but doesn't link to libnetcdf.
The attached patch drops the unused build dependency.
Kind Regards,
Bas
diff -Nru etsf-io-1.0.4/debian/changelog etsf-io-1.0.4/debian/changelog
--- etsf-io-1.0.4/debian/changelog 2020-12-28 08:19:58.0 +0100
+++ etsf-io-1.0.4/debian/changelog 2023-08-29 11:04:52.0 +0200
@@ -1,3 +1,10 @@
+etsf-io (1.0.4-5.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop unused libnetcdf-dev build dependency.
+
+ -- Bas Couwenberg Tue, 29 Aug 2023 11:04:52 +0200
+
etsf-io (1.0.4-5) unstable; urgency=medium
* Team upload.
diff -Nru etsf-io-1.0.4/debian/control etsf-io-1.0.4/debian/control
--- etsf-io-1.0.4/debian/control2020-12-28 08:08:02.0 +0100
+++ etsf-io-1.0.4/debian/control2023-08-29 11:04:52.0 +0200
@@ -6,7 +6,6 @@
Build-Depends: debhelper-compat (= 13),
dh-exec,
gfortran,
- libnetcdf-dev (>= 1:4.3.3.1),
libnetcdff-dev
Standards-Version: 4.3.0
Vcs-Browser: https://salsa.debian.org/science-team/etsf-io
@@ -60,7 +59,6 @@
Section: libdevel
Depends: ${shlibs:Depends},
${misc:Depends},
- libnetcdf-dev,
libnetcdff-dev
Suggests: libetsf-io-doc
Description: Static libraries and Fortran module files of ETSF_IO
Bug#1050731: libmutter-12-0: gnome-shell libmutter-12 segfault
Dear Maintainer, The same bug happens on my machine. I sent a bug report to the gnome-shell maintainers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050502 Best regards, Markus
Bug#1050790: emoslib: Drop unused libnetcdf-dev build dependency
Source: emoslib Version: 2:4.5.9-8 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru emoslib-4.5.9/debian/changelog emoslib-4.5.9/debian/changelog --- emoslib-4.5.9/debian/changelog 2023-03-26 10:55:22.0 +0200 +++ emoslib-4.5.9/debian/changelog 2023-08-29 10:57:00.0 +0200 @@ -1,3 +1,10 @@ +emoslib (2:4.5.9-8.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 10:57:00 +0200 + emoslib (2:4.5.9-8) unstable; urgency=medium * Fix for FTBFS because of deprecated code in eccodes. diff -Nru emoslib-4.5.9/debian/control emoslib-4.5.9/debian/control --- emoslib-4.5.9/debian/control2023-03-26 10:55:22.0 +0200 +++ emoslib-4.5.9/debian/control2023-08-29 10:56:59.0 +0200 @@ -12,8 +12,7 @@ libeccodes-tools, libopenjp2-7-dev, zlib1g-dev, - libfftw3-dev, - libnetcdf-dev + libfftw3-dev Standards-Version: 4.6.0 Homepage: https://software.ecmwf.int/wiki/display/EMOS/Emoslib Vcs-Browser: https://salsa.debian.org:/science-team/emos
Bug#1050792: metkit: Drop unused libnetcdf-dev build dependency
Source: metkit Version: 1.10.14-1 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru metkit-1.10.14/debian/changelog metkit-1.10.14/debian/changelog --- metkit-1.10.14/debian/changelog 2023-08-14 10:15:51.0 +0200 +++ metkit-1.10.14/debian/changelog 2023-08-29 11:07:41.0 +0200 @@ -1,3 +1,10 @@ +metkit (1.10.14-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 11:07:41 +0200 + metkit (1.10.14-1) unstable; urgency=medium * New upstream release diff -Nru metkit-1.10.14/debian/control metkit-1.10.14/debian/control --- metkit-1.10.14/debian/control 2023-08-14 10:15:51.0 +0200 +++ metkit-1.10.14/debian/control 2023-08-29 11:07:38.0 +0200 @@ -10,7 +10,6 @@ odc [!powerpc !armel !armhf !i386 !mipsel], libeccodes-dev, libeccodes-tools, - libnetcdf-dev, libopenjp2-7-dev Standards-Version: 4.6.2 Homepage: https://github.com/ecmwf/metkit
Bug#1050793: python3-deepdiff: python3-clevercsv should be a Recommends, not a Depends
Package: python3-deepdiff Version: 6.2.2-1 Severity: normal Dear Maintainer, Debian package python3-deepdiff currently considers python3-clevercsv as a dependency. However that package is only considered as optional by the developers (see https://github.com/seperman/deepdiff). The deepdiff source code correctly handles the case where clevercsv is not installed (standard library csv module as a fallback): https://github.com/seperman/deepdiff/blob/master/deepdiff/serialization.py#L29 The trouble is that python3-clevercsv itself depends on python3-pandas which is quite a massive package (20Mb). Please remove the dependency on clevercsv and deprecate it as a Recommends. Best regards Fabrice -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-deepdiff depends on: ii python3 3.11.4-5+b1 pn python3-clevercsv pn python3-jsonpickle ii python3-numpy 1:1.24.2-1 pn python3-ordered-set ii python3-setuptools 68.0.0-2 python3-deepdiff recommends no packages. python3-deepdiff suggests no packages.
Bug#1029842: ITP: randombytes -- Library generating fresh randomness
Sam Hartman writes: >> "Jan" == Jan Mojzis writes: > > * Package name: randombytes > Version : 20230126 > Upstream Author : Daniel J. Bernstein > * URL : https://randombytes.cr.yp.to/ > * License : Public domain > > Public domain is problematic as a license. > At least under US copyright law, there are very few circumstances when > something can actually be public domain. > One example is software written by US government employees. > But I don't think any of those circumstances apply to this library. > So I'm not sure the license is okay. We have plenty of code written under that same license from the same group of authors, already in Debian. Look in OpenSSH and OpenSSL for example. So I would disagree there is a license problem having this package in Debian. Jan, I'm happy to help review, sponsor and co-maintain randombytes if you are interested. I rely on it as a dependency in some projects I'm working on. /Simon signature.asc Description: PGP signature
Bug#1041574: gnome-shell-extension-hamster: diff for NMU version 0.10.0+git20210628-4.1
Control: tags 1041574 + pending
Dear maintainer,
I've prepared an NMU for gnome-shell-extension-hamster (versioned as
0.10.0+git20210628-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru gnome-shell-extension-hamster-0.10.0+git20210628/debian/changelog gnome-shell-extension-hamster-0.10.0+git20210628/debian/changelog
--- gnome-shell-extension-hamster-0.10.0+git20210628/debian/changelog 2022-09-12 11:49:25.0 +0200
+++ gnome-shell-extension-hamster-0.10.0+git20210628/debian/changelog 2023-08-29 10:58:19.0 +0200
@@ -1,3 +1,10 @@
+gnome-shell-extension-hamster (0.10.0+git20210628-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update compatilbity patch for GNOME shell 44. (Closes: #1041574)
+
+ -- Tobias Frost Tue, 29 Aug 2023 10:58:19 +0200
+
gnome-shell-extension-hamster (0.10.0+git20210628-4) unstable; urgency=medium
[ Jesús Soto ]
diff -Nru gnome-shell-extension-hamster-0.10.0+git20210628/debian/control gnome-shell-extension-hamster-0.10.0+git20210628/debian/control
--- gnome-shell-extension-hamster-0.10.0+git20210628/debian/control 2022-09-12 11:49:25.0 +0200
+++ gnome-shell-extension-hamster-0.10.0+git20210628/debian/control 2023-08-29 10:58:19.0 +0200
@@ -19,7 +19,7 @@
Depends:
hamster-time-tracker,
gnome-shell (>= 3.38),
- gnome-shell (<< 44~),
+ gnome-shell (<< 45~),
${misc:Depends}
Description: GNOME Shell extension for the Hamster Time Tracker
Project Hamster helps you to keep track of how much time you spend on various
diff -Nru gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43-44.patch gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43-44.patch
--- gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43-44.patch 1970-01-01 01:00:00.0 +0100
+++ gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43-44.patch 2023-08-29 10:57:48.0 +0200
@@ -0,0 +1,23 @@
+From: =?utf-8?q?Rapha=C3=ABl_Hertzog?=
+Date: Mon, 18 Oct 2021 15:10:10 +0200
+Subject: Document compatibility with GNOME Shell 41, 42 and 43
+
+---
+ data/metadata.json.in | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/data/metadata.json.in
b/data/metadata.json.in
+@@ -13,7 +13,11 @@
+ "3.34",
+ "3.36",
+ "3.38",
+-"40"
++"40",
++"41",
++"42",
++"43",
++"44"
+ ],
+ "url": "https://github.com/projecthamster/hamster-shell-extension.git";,
+ "uuid": @UUID@
diff -Nru gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43.patch gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43.patch
--- gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43.patch 2022-09-12 11:49:25.0 +0200
+++ gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/Document-compatibility-with-GNOME-Shell-41-42-43.patch 1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-From: =?utf-8?q?Rapha=C3=ABl_Hertzog?=
-Date: Mon, 18 Oct 2021 15:10:10 +0200
-Subject: Document compatibility with GNOME Shell 41, 42 and 43
-
- data/metadata.json.in | 5 -
- 1 file changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/data/metadata.json.in b/data/metadata.json.in
-index 9a9f41d..78eef73 100644
a/data/metadata.json.in
-+++ b/data/metadata.json.in
-@@ -13,7 +13,10 @@
- "3.34",
- "3.36",
- "3.38",
--"40"
-+"40",
-+"41",
-+"42",
-+"43"
- ],
- "url": "https://github.com/projecthamster/hamster-shell-extension.git";,
- "uuid": @UUID@
diff -Nru gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/series gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/series
--- gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/series 2022-09-12 11:49:25.0 +0200
+++ gnome-shell-extension-hamster-0.10.0+git20210628/debian/patches/series 2023-08-29 10:57:22.0 +0200
@@ -1 +1 @@
-Document-compatibility-with-GNOME-Shell-41-42-43.patch
+Document-compatibility-with-GNOME-Shell-41-42-43-44.patch
signature.asc
Description: PGP signature
Bug#1050186: [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 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#1033274: gnome-session: recommends xdg-desktop-portal-gnome and not depends
> 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? > I am really struggling to see how the benefit of having one less package installed outweighs the harm caused by sandboxed apps being broken. I am not advocating to breaking sandboxed apps. I only wonder if gnome-session is not the right place for this dependency. On Mon, Aug 28, 2023 at 10:33 PM Jeremy Bícha wrote: > On Mon, Mar 20, 2023 at 6:51 PM Pablo Mazzini wrote: > > gnome-session can work properly without xdg-desktop-portal-gnome. > > > > As per the policy: > > Depends: This declares an absolute dependency. > > Recommends: This declares a strong, but not absolute, dependency. > > > > Please recommend xdg-desktop-portal-gnome. > > > > The gnome-core meta package already provides this dependency and it may > > be appropriate there. > > I am not convinced by your justification. Flatpak and Snap packages > are expected to work on Debian and require an xdg-desktop-portal > implementation. It is impossible for Flatpak (or Snap) alone to depend > on the correct portal implementation for each desktop. Therefore, the > desktop session needs to depend on the portal that has the best > integration. > > The Debian GNOME team has gotten bugs for years from people who > complain that their system doesn't work after disabling installing > recommended packages. Ironically, the fact that you are asking for > this change proves to me that there are people who intend to remove > recommended packages. > > I am really struggling to see how the benefit of having one less > package installed outweighs the harm caused by sandboxed apps being > broken. > > Thank you, > Jeremy Bícha >
Bug#1050794: python-escript: Drop unused libnetcdf-dev build dependency
Source: python-escript Version: 5.6-5 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru python-escript-5.6/debian/changelog python-escript-5.6/debian/changelog --- python-escript-5.6/debian/changelog 2023-08-03 12:13:07.0 +0200 +++ python-escript-5.6/debian/changelog 2023-08-29 11:13:50.0 +0200 @@ -1,3 +1,10 @@ +python-escript (5.6-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 11:13:50 +0200 + python-escript (5.6-5) unstable; urgency=medium * Standards-Version: 4.6.2 diff -Nru python-escript-5.6/debian/control python-escript-5.6/debian/control --- python-escript-5.6/debian/control 2023-08-03 12:13:07.0 +0200 +++ python-escript-5.6/debian/control 2023-08-29 11:13:48.0 +0200 @@ -19,7 +19,6 @@ libboost-random-dev, libboost-numpy-dev, libboost-iostreams-dev, - libnetcdf-dev, libnetcdf-c++4-dev, libsilo-dev (>= 4.10.2.real-5), libscotchparmetis-dev,
Bug#1050795: lammps: Drop unused libnetcdf-dev build dependency
Source: lammps Version: 20220106.git7586adbb6a+ds1-2 Severity: normal Tags: patch Dear Maintainer, Your package build depends on libnetcdf-dev but doesn't link to libnetcdf. The attached patch drops the unused build dependency. Kind Regards, Bas diff -Nru lammps-20220106.git7586adbb6a+ds1/debian/changelog lammps-20220106.git7586adbb6a+ds1/debian/changelog --- lammps-20220106.git7586adbb6a+ds1/debian/changelog 2022-03-17 19:23:11.0 +0100 +++ lammps-20220106.git7586adbb6a+ds1/debian/changelog 2023-08-29 11:45:50.0 +0200 @@ -1,3 +1,10 @@ +lammps (20220106.git7586adbb6a+ds1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused libnetcdf-dev build dependency. + + -- Bas Couwenberg Tue, 29 Aug 2023 11:45:50 +0200 + lammps (20220106.git7586adbb6a+ds1-2) unstable; urgency=medium * [a623229] Switch off GPU diff -Nru lammps-20220106.git7586adbb6a+ds1/debian/control lammps-20220106.git7586adbb6a+ds1/debian/control --- lammps-20220106.git7586adbb6a+ds1/debian/control2022-03-11 16:59:36.0 +0100 +++ lammps-20220106.git7586adbb6a+ds1/debian/control2023-08-29 11:45:48.0 +0200 @@ -13,7 +13,6 @@ libhdf5-mpi-dev, libjpeg-dev, libkim-api-dev, - libnetcdf-dev, libsymspg-dev, libvtk9-dev, libvtk9-qt-dev,
Bug#1033274: gnome-session: recommends xdg-desktop-portal-gnome and not depends
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#1021656: please package new upstream release
On Wed, Oct 12, 2022 at 01:24:40PM +0200, Piotr Ożarowski wrote: > Package: tt-rss > Version: 21~git20210204.b4cbc79+dfsg-1 > Severity: wishlist > > Hi, > > Please prepare new upstream release. Hello, I think that tt-rss as it is now in bookworm is barely usable (using the web interface at least). It's hard to tell which articles are read and which ones are not, plus they don't get marked as read automatically (#1005331). Also the journal is full of PHP warnings (#1006956). My impression is that that the packaged version (february 2021) just doesn't work with PHP 8, which was released a couple of months before that. Berto
Bug#1050784: debianutils: fails to reinstall / will fail to install 5.11
Hi to all involved, I am very sorry to have caused all those issues and promise to test change requests more careful in the future. Helmut, thank you for the review offer and I take it. Here is my draft that I have tested: https://salsa.debian.org/debian/debianutils/-/merge_requests/27 I am not very sure if I have to add any cleanup for the missing DPKG_ROOT. In my testing there was no problem but obviously I do not know about every possible scenario that is involved here. Thanks, Bastian
Bug#1050796: octave-interval tests need an update with mpfr4 4.2.1
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
Bug#1050502: gnome-shell crashes when restarting it with ALT+F2 and "r"
I tried obtaining a stack and JS trace using GDB for an already running gnome-shell like discribed here: https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces/Details#Obtaining_a_stack_and_JS_trace_using_GDB_for_an_already_running_gnome-shell But inbetween gnome-shell crashed and I had to logout- and in again to get the journalctl logs. The gdb.txt: [Thread 0x7f81d54096c0 (LWP 18756) exited] [New Thread 0x7f81d54096c0 (LWP 18825)] [New Thread 0x7f81d4c086c0 (LWP 18826)] [Thread 0x7f81d4c086c0 (LWP 18826) exited] [New Thread 0x7f81d4c086c0 (LWP 18932)] [New Thread 0x7f81b3fff6c0 (LWP 18933)] [Thread 0x7f81d4c086c0 (LWP 18932) exited] [New Thread 0x7f81d4c086c0 (LWP 18934)] [New Thread 0x7f81b2ffd6c0 (LWP 18935)] [Thread 0x7f81b3fff6c0 (LWP 18933) exited] [Thread 0x7f81d4c086c0 (LWP 18934) exited] [Thread 0x7f81b2ffd6c0 (LWP 18935) exited] [Detaching after fork from child process 18936] [New Thread 0x7f81b2ffd6c0 (LWP 18938)] [New Thread 0x7f81d4c086c0 (LWP 18939)] [Thread 0x7f81b2ffd6c0 (LWP 18938) exited] [Thread 0x7f81d4c086c0 (LWP 18939) exited] Thread 1 "gnome-shell" received signal SIGSEGV, Segmentation fault. 0x7f82013fbf63 in _XSend () from /lib/x86_64-linux-gnu/libX11.so.6 #0 0x7f82013fbf63 in _XSend () at /lib/x86_64-linux-gnu/libX11.so.6 #1 0x7f82013f2331 in XQueryExtension () at /lib/x86_64-linux-gnu/libX11.so.6 #2 0x7f81fe957d66 in () at /lib/x86_64-linux-gnu/libXext.so.6 #3 0x7f81fe9584b4 in XSyncTriggerFence () at /lib/x86_64-linux-gnu/libXext.so.6 #4 0x7f820190a340 in meta_sync_free (self=0x55df71f4b2c0) at ../src/compositor/meta-sync-ring.c:392 i = 0 ring = 0x7f8201a50800 __func__ = "meta_sync_ring_destroy" #5 meta_sync_ring_destroy () at ../src/compositor/meta-sync-ring.c:470 i = 0 ring = 0x7f8201a50800 __func__ = "meta_sync_ring_destroy" #6 0x7f8201908da5 in meta_compositor_x11_dispose (object=0x55df71f1fa00) at ../src/compositor/meta-compositor-x11.c:520 compositor_x11 = 0x55df71f1fa00 compositor = 0x55df71f1fa00 stage = 0x55df71b88220 #7 0x7f8202514d0a in g_object_run_dispose () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x7f82018aca19 in meta_compositor_destroy (compositor=0x55df71f1fa00) at ../src/compositor/compositor.c:198 #9 0x7f82018cc08d in meta_display_close (display=0x55df71b8c430, timestamp=) at ../src/core/display.c:1178 _pp = 0x55df71b8c570 _ptr = compositor = laters = 0x55df71f0f110 #10 0x7f82022274ae in shell_global_reexec_self (global=0x55df71bb9810) at ../src/shell-global.c:1339 arr = 0x7f81e4262c40 len = 21 meta_context = buf = 0x55df73d6ef90 "/usr/bin/gnome-shell" buf_p = buf_end = error = 0x0 #11 0x7f8200fb2f7a in () at /lib/x86_64-linux-gnu/libffi.so.8 #12 0x7f8200fb240e in () at /lib/x86_64-linux-gnu/libffi.so.8 #13 0x7f8200fb2b0d in ffi_call () at /lib/x86_64-linux-gnu/libffi.so.8 #14 0x7f8201dcbfa7 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #15 0x7f8201dcc698 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #16 0x7f81fef96620 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #17 0x7f81fef89d67 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #18 0x7f81fef95de3 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #19 0x7f81fef96267 in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #20 0x7f81fef9682c in () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #21 0x7f81ff03fb1d in JS_CallFunctionValue(JSContext*, JS::Handle, JS::Handle, JS::HandleValueArray const&, JS::MutableHandle) () at /lib/x86_64-linux-gnu/libmozjs-102.so.0 #22 0x7f8201da8ed1 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #23 0x7f8201dfc884 in () at /lib/x86_64-linux-gnu/libgjs.so.0 #24 0x7f820250e3f8 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #25 0x7f820252101c in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #26 0x7f82025221b1 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #27 0x7f8202528552 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x7f82025285ff in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x7f82018cc2fe in meta_display_request_restart (display=display@entry=0x55df71b8c430) at ../src/core/display.c:2601 result = 0 #30 0x7f82018e15b3 in restart_check_ready (context=0x55df71511c80) at ../src/core/restart.c:64 display = 0x55df71b8c430 context = 0x55df71511c80 error = 0x0 length = 7 line = #31 restart_check_ready (context=0x55df71511c80) at ../src/core/restart.c:58 context = 0x55df71511c80 error = 0x0 length = 7 line = #32 restart_helper_read_line_callback (source_object=, res=, user_data=0x55df71511c80) at ../src/core/restart.c:92 context = 0x55df71511c80 error = 0x0 length
Bug#1050797: python-gmpy2 tests need an update due to the fix of the MPFR formatted functions
Package: python-gmpy2 Version: 2.1.5-1 Severity: serious Tags: sid trixie Affects: src:mpfr4 This is due to the fix of the MPFR formatted functions, tests need an update in python-gmpy2. see https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-gmpy2/37232406/log.gz
Bug#1050762: feedbackd-device-themes: Users are not informed about existing tools from the feedbackd package
Hi, 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. I've added a feedback-themes manpage upstream so apropos and other tools make it easier to find. > 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 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..] > 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. Cheers, -- Guido
Bug#1050784: a quick fix/revert would be appreciated
hi, 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. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Segregation was legal. Slavery was legal. Don't use legality as a guide to morality. Outlaw profits from fossil fuel. signature.asc Description: PGP signature
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
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 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#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
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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
