Bug#1065203: regression: TypeError: find_username() missing 1 required positional argument: 'ssh_conf'
Control: tag -1 patch I've opened an MR to fix this at: https://salsa.debian.org/debian/dput-ng/-/merge_requests/36 Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can it be put in stable?
Package: mariadb-server Version: 1:10.11.6-0+deb12u1 Severity: important Tags: upstream X-Debbugs-Cc: deb...@viperfang.net, t...@security.debian.org Dear Maintainer, * What led up to the situation? Running nextcloud plugin that imports a country database for reverse geocoding (Memories app) * What exactly did you do (or not do) that was effective (or ineffective)? Waited for it to complete, but php reports the server has gone away, journalctl shows its crashing. * What was the outcome of this action? MariaDB Crashed * What outcome did you expect instead? MariaDB to not crash. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.13-5-pve (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii galera-4 26.4.13-1 ii gawk 1:5.2.1-2 ii iproute2 6.1.0-3 ii libc6 2.36-9+deb12u6 ii libdbi-perl1.643-4 ii libpam0g 1.5.2-6+deb12u1 ii libssl33.0.11-1~deb12u2 ii libstdc++6 12.2.0-14 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.6-0+deb12u1 ii mariadb-common 1:10.11.6-0+deb12u1 ii mariadb-server-core1:10.11.6-0+deb12u1 ii passwd 1:4.13+dfsg1-1+b1 ii perl 5.36.0-7+deb12u1 ii procps 2:4.0.2-3 ii psmisc 23.6-1 ii rsync 3.2.7-1 ii socat 1.7.4.4-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii mariadb-plugin-provider-bzip2 1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-lz4 1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-lzma1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-lzo 1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-snappy 1:10.11.6-0+deb12u1 ii pv 1.6.20-1 Versions of packages mariadb-server suggests: pn mailx pn mariadb-test pn netcat-openbsd -- debconf information: mariadb-server/nis_warning: mariadb-server/old_data_directory_saved: mariadb-server/postrm_remove_databases: false
Bug#264500: fmtools: fmscan patch to allow choice of threshold signal strength (attached)
I incorporated this patch into fmtools 1.0 back in 2004. It is in the current Debian release (version 2.0.8). The bug can be closed. On Mon, Apr 22, 2024 at 4:53 PM Petter Reinholdtsen wrote: > > Control: tags -1 + patch > > [Gregory P. Smith] 2004-08-08] > > The fmscan utility is not nearly as useful as it could be without > > this patch. this adds the -t command line option to allow control of > > the threshold signal strength that fmscan uses to decide if a station > > can be received. please apply to future debian packages of this tool > > and submit to the upstream maintainer. > > Thank you for the patch. I am sad to see it has lingered here for so > long. CC to the upstream email address, in the hope that upstream can > have a look at the patch in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264500 >. Not > convinced that the old email address still work, but it is worth a try. > :) > -- > Happy hacking > Petter Reinholdtsen
Bug#1068850: GnuPG signature verify emits “SignatureVerifyError: 0”
Package: dput Version: 0.12 Severity: normal When verifying a GnuPG-signed file, ‘dput’ can sometimes emit a confusing error: = […] Checking signature on .changes gpg: ../build-area/foo_1.2_source.changes: Error checking signature from F9B46AAC84420C82: SignatureVerifyError: 0 Checking signature on .dsc gpg: ../build-area/foo_1.2.dsc: Error checking signature from F9B46AAC84420C82: SignatureVerifyError: 0 […] = The program continues, but this message is misleading when the signature is actually valid. If there is no problem with the signature, no message like this should be emitted; if there is a problem with the signature, the message should clearly state what it is. -- \ “The history of Western science confirms the aphorism that the | `\ great menace to progress is not ignorance but the illusion of | _o__)knowledge.” —Daniel J. Boorstin, historian, 1914–2004 | Ben Finney signature.asc Description: PGP signature
Bug#772204: Package upload repository policy
On 08-Apr-2024, Osamu Aoki wrote: > * Adjust message to address rejection condition and repository policy Where (what URL) can I find the current repository policy, with enough precision to implement a conformant upload program? -- \ “It is wrong to think that the task of physics is to find out | `\ how nature *is*. Physics concerns what we can *say* about | _o__) nature…” —Niels Bohr | Ben Finney signature.asc Description: PGP signature
Bug#1021392: dput: Ambiguity when dput thinks package is already uploaded
Control: severity -1 minor Control: merge 941784 -1 On 07-Oct-2022, Moritz Schlarb wrote: > This bit me recently You're not alone; bug#941784 describes this same behaviour. I'm merging this report with that one. -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney signature.asc Description: PGP signature
Bug#772204: dput: .orig.tar.gz for non -1 package for security-master
Control: severity -1 minor Control: tags -1 - moreinfo Control: merge 706607 -1 On 28-Aug-2016, Ben Finney wrote: > Is this behaviour the same problem reported in [bug#706607], or is that a > separate problem? On the assumption that bug#706607 reports the same problem, I am merging this bug report with that one. If there is a change needed, that is not covered by the report in bug#706607 (and that I did not parse correctly from this bug report), please feel free to describe it separately in a new bug report. -- \ “Progress might have been all right once, but it's gone on too | `\long.” —Ogden Nash | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#881720: SSH public key authentication failed: Unable to extract public key from private key file: Method unimplemented in libgcrypt backend on curl 7.74.0
This problem continues to occur with curl 7.74.0 on Debian GNU/Linux 11 (bullseye) on WSL: curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1w zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3 Release-Date: 2020-12-09, security patched: 7.74.0-1.3+deb11u11 Debian GNU/Linux 11 (bullseye) Kernel: Linux 5.15.146.1-microsoft-standard-WSL2 Since I have the public key file, a workaround is to explicitly pass the public key file. That is, this command fails: curl -v sftp://user@host/home/user/ with this error: Using SSH private key file '.../.ssh/id_rsa' * SSH public key authentication failed: Unable to extract public key from private key file: Method unimplemented in libgcrypt backend And this works: curl --pubkey ~/.ssh/id_rsa.pub sftp://user@host/home/user/ "curl 8.7.1 (x86_64-pc-cygwin)" extracts the private key from the public key.
Bug#1066942: Debugging xmrig FTBFS on armhf
I could not reproduce the issue on an armhf porterbox, which is concerning. I have just uploaded a new release that just tells cmake to force an ARMv7 build if DEB_HOST_ARCH is armhf. It also includes a handy patch that makes the build log give a couple clues so I can track down why my machine and the porterbox can't reproduce it but the buildd can. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: Debugging xmrig FTBFS on armhf
It seems that the maes flag is automatically added if the ARM_TARGET CMake var is not set, which happens in cmake/cpu.cmake. The first thing I saw when I opened that file looked promising: if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(XMRIG_64_BIT ON) add_definitions(-DXMRIG_64_BIT) else() set(XMRIG_64_BIT OFF) endif() I figured that maybe SIZEOF_VOID_P changed with the t64 transition and this caused it to get confused and think that we are building on x86_64. Then I looked closer at the buildd log and saw that XMRIG_64_BIT was (correctly) set to OFF, which means that this could not be the issue. The next lines of interest are here: if (CMAKE_SYSTEM_PROCESSOR MATCHES "^(aarch64|arm64|armv8-a)$") set(ARM_TARGET 8) elseif (CMAKE_SYSTEM_PROCESSOR MATCHES "^(armv7|armv7f|armv7s|armv7k|armv7-a|armv7l|armv7ve)$") set(ARM_TARGET 7) endif() There are no other functions modifying the ARM_TARGET other than the option to override this value by manually setting the ARM_V7 variable. This means that CMAKE_SYSTEM_PROCESSOR must not be matching one of the armv7* values on buildd and your machine, but does on all of mine. The build could be fixed by setting ARM_V7 in d/rules on armhf, but I would prefer properly resolving this issue instead of just working around it. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Hello, Since my last message, I have tried to reproduce this in several ways, e.g. an sbuild chroot in both qemu-user-static and on actual hardware (Raspberry Pi 2), and also a direct build on an armhf VM. It always builds successfully. Since then, there has been a new upstream release of xmrig, so I figured I would just upload and see if it still fails buildd. On the buildd log, it indeed fails with the same maes error. This means xmrig thinks it's building on x86 and adds those flags, but this doesn't happen on arm64; only on armhf, only after the t64 transition. It also doesn't happen on any of my systems but does on buildd and apparently your system. I guess I'll request guest access to an armhf porterbox and hope FTBFS happens there so I can debug this. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Sebastian, I can't seem to reproduce this on an armhf chroot, VM, or actual hardware (all unstable). When were you last able to reproduce this? It's possible (since unstable has changed rapidly in recent days) that the problem was something external that fixed itself between then and now. -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1066942: xmrig: FTBFS on armhf: cc: error: unrecognized command-line option ‘-maes’
Hello, The package builds fine on my armhf VM as well as a Raspberry Pi 2 running armhf Debian bare metal. Maybe some transitioning library caused this issue? If xmrig gets binNMU'd, it will probably build successfully. I would do it, but I'm not a Debian Developer. Could you do it? Thanks, -- Ben Westover OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
It turned out to just be a test expecting the 32 bit limit. This is patched in the newest version which I have just uploaded. Build fixed! -- Ben Westover OpenPGP_signature.asc Description: PGP signature
Bug#1067094: pacman-package-manager: FTBFS on armel/armh
Hello, Arch Linux ARM supports armhf/armel just fine, so I think this can work with little to no patches. I haven't been able to take a look since the t64 transition because I have been busy with other things. I will likely have time tomorrow to fix this. -- Ben Westover
Bug#1067078: gawk: Please upgrade to 5.3.0 which has CSV support
Package: gawk Version: 1:5.2.1-2 Severity: normal X-Debbugs-Cc: bugs.debian@wongs.net Dear Maintainer, Please upgrade this package to version 5.3. As of 2023, GNU's gawk has support for the Comma Separated Values format by use of the `-k` switch. This is a major improvement for people who must deal with such files. Upgrading to version 5.3 will also ensure that gawk is compatible with Brian Kernighan's awk, which added CSV support previously. Thank you. —Ben -- 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-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gawk depends on: ii libc6 2.37-13 ii libgmp10 2:6.3.0+dfsg-2 ii libmpfr6 4.2.1-1 ii libreadline8 8.2-3 ii libsigsegv2 2.14-1 gawk recommends no packages. Versions of packages gawk suggests: ii gawk-doc 5.2.1-1 -- no debconf information
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
Van: Salvatore Bonaccorso
> Hi Ben,
>
> On Thu, Dec 14, 2023 at 09:16:48AM +, Ben Mesman | Spark Narrowcasting
> wrote:
> > The attached patch works on my systems. Is there a way to get this in?
>
> ...
>
> We cannot pick changes which are not going to land in Linux upstream
> and then backported to the stable series. So the way to go here is to
> report the bug upstream, along with your proposed change. Candidates
> to reach out are:
>
> ...
>
> as it is affecting 6.1.y mention that the fix needs to be backported to
> various
> stable series at least back 6.1.y and describe which testing you have
> performed.
>
> Feel free to keep as well the Debian bug in the loop for the report.
>
> Hope this helps?
Small update on this bug: I reached out and Fred Ai made a patch which is now
in the mainline kernel:
commit 58aeb5623c2ebdadefe6352b14f8076a7073fea0
Author: Fred Ai
Date: Sat Feb 3 02:29:08 2024 -0800
mmc: sdhci-pci-o2micro: Fix a warm reboot issue that disk can't be detected
by BIOS
Driver shall switch clock source from DLL clock to
OPE clock when power off card to ensure that card
can be identified with OPE clock by BIOS.
Signed-off-by: Fred Ai
Fixes:4be33cf18703 ("mmc: sdhci-pci-o2micro: Improve card input timing at
SDR104/HS200 mode")
Cc: sta...@vger.kernel.org
Link:
https://lore.kernel.org/r/20240203102908.4683-1-fredaibayhubt...@126.com
Signed-off-by: Ulf Hansson
I'm still waiting for the patch to land in the stable kernel series (both 6.1
and 6.6)
Regards,
Ben Mesman.
Bug#1064035: Missing documentation due to error in kernel-doc script
Package: linux-doc-5.10 Version: 5.10.209-1 Severity: important The backport of commit 3080ea5553cc "stddef: Introduce DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and introduced a syntax error: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236. Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236. Execution of ./scripts/kernel-doc aborted due to compilation errors. This doesn't stop the documentation build process, but causes the documentation that should be extracted by kernel-doc to be missing from linux-doc-5.10. We should be able to fix this by eithering backport commit e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions into variables" or replacing /$args/ with /([^,)]+)/. Ben. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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#1063889: Parse package version string using ‘python3-debian’ class ‘debian.debian_support.Version’
On 14-Feb-2024, Ben Finney wrote: > The ‘dput.source_check’ function currently uses a custom regex pattern for > parsing a package version string. This pattern differs in some ways from > the official Debian Policy definition of a version string. Thanks to Christoph Berg (‘myon’) for the motivation to report this bug. -- \ “We jealously reserve the right to be mistaken in our view of | `\ what exists, given that theories often change under pressure | _o__) from further investigation.” —Thomas W. Clark, 2009 | Ben Finney signature.asc Description: PGP signature
Bug#1063889: Parse package version string using ‘python3-debian’ class ‘debian.debian_support.Version’
Package: dput Version: dput Severity: minor The ‘dput.source_check’ function currently uses a custom regex pattern for parsing a package version string. This pattern differs in some ways from the official Debian Policy definition of a version string. Instead of custom parsing, re-write the check to use the functionality provided by the ‘python3-debian’ package. In ‘debian.debian_support’ is a ‘Version’ class whose constructor parses a package version string into the defined structure of a Debian package version. This will introduce a “Depends: python3-debian” relationship to this package. -- \ “He that would make his own liberty secure must guard even his | `\ enemy from oppression.” —Thomas Paine | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1061095: linux-image-6.6.11-amd64: 2.5gbit USB device with r8152 chipset only does 100baset
Control: tag -1 moreinfo On Thu, 2024-01-18 at 13:42 +1100, Russell Coker wrote: > Package: src:linux > Version: 6.6.11-1 > Severity: normal > Tags: upstream > > [51076.208113] r8152-cfgselector 2-1: reset SuperSpeed USB device number 6 > using xhci_hcd > [51076.236596] r8152 2-1:1.0: firmware: direct-loading firmware > rtl_nic/rtl8156b-2.fw > [51076.258622] r8152 2-1:1.0: ram code speedup mode fail > [51076.258647] r8152 2-1:1.0: load rtl8156b-2 v2 04/27/23 successfully > [51076.301913] r8152 2-1:1.0 eth0: v1.12.13 > [51076.697896] r8152 2-1:1.0 usb2.5g: renamed from eth0 > [51079.489807] r8152 2-1:1.0 usb2.5g: carrier on > [51079.745192] r8152 2-1:1.0 usb2.5g: carrier off > [51082.561105] r8152 2-1:1.0 usb2.5g: carrier on > [51152.705733] r8152 2-1:1.0 usb2.5g: carrier off > [51156.353013] r8152-cfgselector 2-1: USB disconnect, device number 6 > [51156.353455] xhci_hcd :00:14.0: WARN Set TR Deq Ptr cmd failed due to > incorrect slot or ep state. > [51156.353492] r8152 2-1:1.0 usb2.5g: Stop submitting intr, status -108 > > Above is the relevant kernel message logs. > > # mii-tool usb2.5g > usb2.5g: 100 Mbit, half duplex, link ok You should not use mii-tool for this; it only works speeds up to 1 Gbit (and even then only with some PHYs). Please provide information from ethtool. > Above is the output of mii-tool, also the lights on the switch indicate > 100mbit speed. It gets 100mbit on a 1000baset switch too, so it's not a > switch issue. > > [66653.451043] cdc_ncm 2-1.2:2.0 enx00e04c680225: renamed from eth0 > [66656.811499] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > [66657.067647] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c680225: link becomes > ready > [66657.323360] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > [66657.835395] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > [66658.347355] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > [66658.859227] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > [66659.371242] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > [66659.883190] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 > mbit/s uplink > > Above is the dmesg output from a LicheePi4A running the > 5.10.113-g387b6863253c-dirty kernel it ships with, when it does this the > switch LEDs indicate that it's 2500 speed. This indicates that it's not > a problem with the hardware in the USB device but a problem with the kernel. > > # ethtool usb2.5g > Settings for usb2.5g: > Supported ports: [ ] > Supported link modes: Not reported !! > Supported pause frame use: No > Supports auto-negotiation: No > Supported FEC modes: Not reported > Advertised link modes: Not reported > Advertised pause frame use: No > Advertised auto-negotiation: No > Advertised FEC modes: Not reported > Speed: 1000Mb/s > Duplex: Half > Auto-negotiation: off !! > Port: Twisted Pair > PHYAD: 0 > Transceiver: internal > MDI-X: Unknown > Current message level: 0x0007 (7) >drv probe link > Link detected: yes > > Above is the output of running ethtool on a Debian/Stable system running > kernel 6.1.0-13-amd64. Is this using the cdc-ncm or r8152 driver? > Half duplex is a problem, but less of a problem than > 100baseT. This is a regression from Debian/Stable. The above also looks very broken, so I would hesitate to say that this has regressed as opposed to showing different symptoms. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#1063470: debsums: man page documents removed "--generate=keep" option
Package: debsums Version: 3.0.2.1 Severity: minor Dear Maintainer, The man debsums(1) man page says: -g, --generate=[missing|all][,keep[,nocheck]] ... keep Write the extracted/generated sums to /var/lib/dpkg/info/package.md5sums. However, if I try to use the "keep" option, debsums reports: wraith:/tmp$ debsums --generate=all,keep,nocheck debsums_3.0.2.1_all.deb debsums: the --generate=keep option has been removed and does nothing. at /usr/bin/debsums line 847. Since the option no longer does anything, it should either be removed from the man page or documented as doing nothing. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 debsums depends on: ii libdpkg-perl 1.22.4 ii libfile-fnmatch-perl 0.02-3+b2 ii perl 5.38.2-3 ii ucf 3.0043+nmu1 debsums recommends no packages. Versions of packages debsums suggests: ii bash-completion 1:2.11-8 -- Configuration Files: /etc/default/debsums changed: CRON_CHECK="monthly" -- debconf information: * debsums/apt-autogen: true * debsums/croncheck: monthly
Bug#1061783: apprise fails its autopkg tests with Python 3.12
Howdy Andreas, On 07-Feb-2024, Andreas Tille wrote: > Hi Ben, > > I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest > fails with Python3.12. I'd happily fix packages in Debian Python Team > but your package is not team maintained. Do you have any reason for > this? The package metadata for ‘apprise’ tells me its maintainer is: Maintainer: Debian Python Team http://deb.debian.org/debian/pool/main/a/apprise/apprise_1.7.2-1.dsc> so I think you might have the information mixed up? You are talking about “version 0.5.1-4”, so maybe you are referring to a different package? -- \ “Speech is human, silence is divine, yet also brutish and dead: | `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1063319: easyeffects: Please lower calf-plugins dependency to Recommends
Package: easyeffects Version: 7.1.4-1 Severity: wishlist Dear Maintainer, Easyeffects works quite well without calf-plugins. In my case, I just use the equaliser from lsp-plugins-lv2, with an empty replacement package for calf-plugins, and can report ill effects. So I do not think a hard dependency is justified. In addition, calf-plugins pulls in obsolete library gtk2 (this is of course an issue with that package, and not with easyeffects). Thanks in advance, Itaï. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages easyeffects depends on: ii calf-plugins 1:0 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii libadwaita-1-0 1.4.2-1+b1 ii libbs2b0 3.1.0+dfsg-7 ii libc62.37-15 ii libcairo21.18.0-1+b1 ii libebur128-1 1.2.6-1+b1 ii libfftw3-double3 3.3.10-1 ii libfftw3-single3 3.3.10-1 ii libgcc-s114-20240201-3 ii libglib2.0-0 2.78.3-2 ii libgsl27 2.7.1+dfsg-6 ii libgtk-4-1 4.12.5+ds-2 ii liblilv-0-0 0.24.22-1 ii libpango-1.0-0 1.51.0+ds-4 ii libpipewire-0.3-01.0.3-1 ii libsamplerate0 0.2.2-4 ii libsigc++-3.0-0 3.6.0-1 ii libsndfile1 1.2.2-1 ii libsoundtouch1 2.3.2+ds1-1 ii libspeexdsp1 1.2.1-1 ii libstdc++6 14-20240201-3 ii libtbb12 2021.11.0-2 ii libzita-convolver4 4.0.3-2 Versions of packages easyeffects recommends: ii lsp-plugins-lv2 1.2.14-1 pn mda-lv2 pn zam-plugins easyeffects suggests no packages. -- no debconf information
Bug#1062204: Acknowledgement (Newly-created clusters have restrictive postgresql.conf permissions)
Control: found -1 patroni/3.1.1-1 I've just tested a couple of other versions of the Debian patroni package from snapshot.debian.org: 3.0.4-1 does not have the problem: postgresql.conf is world-readable. 3.1.1-1 has the problem: postgresql.conf is not world-readable. -- Ben Harris, University of Cambridge Information Services.
Bug#1062204: Newly-created clusters have restrictive postgresql.conf permissions
Package: patroni Version: 3.2.2-1 When Patroni creates a new PostgreSQL cluster, the postgresql.conf file in /etc/patroni// ends up without world read permission. This means that tools that use pg_wrapper (such as /usr/bin/psql) can't find the cluster's port number and don't work by default. I think this problem was introduced by this upstream commit: https://github.com/zalando/patroni/commit/01d07f86cd525c0f324074ee026faf6d7f179839 But I'm not sure if it's an upstream bug, or a latent flaw in the Debian packaging. To reproduce: On a fresh Debian system, install patroni, postgresql, and etcd-server. Configure /etc/patroni/dcs.yml as shown below. # systemctl stop postgresql@16-main # pg_dropcluster 16 main # pg_createconfig_patroni 16 test # systemctl start patroni@16-test # pg_isready /var/run/postgresql/:5432 - accepting connections # adduser user (press Return lots) # su - user $ pg_isready Error: Invalid data directory for cluster 16 test If I change the permissions on /etc/postgresql/16/test/postgresql.conf from 600 to 644 then pg_isready works as the unprivileged user. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages patroni depends on: ii python33.11.6-1 ii python3-cdiff 1.0-1.1 ii python3-click 8.1.6-1 ii python3-dateutil 2.8.2-3 ii python3-etcd 0.4.5-4 ii python3-pkg-resources 68.1.2-2 ii python3-prettytable3.6.0-1 ii python3-psutil 5.9.8-1 ii python3-psycopg2 2.9.9-1+b1 ii python3-urllib31.26.18-2 ii python3-yaml 6.0.1-2 Versions of packages patroni recommends: ii iproute2 6.7.0-2 Versions of packages patroni suggests: ii etcd-server 3.4.23-4+b8 pn haproxy pn patroni-doc ii postgresql 16+256 pn vip-manager -- Configuration Files: /etc/patroni/dcs.yml changed: etcd3: host: 127.0.0.1:2379 -- no debconf information
Bug#1054726: python-daemon: FTBFS: ValueError: ("Missing 'Version:' header and/or PKG-INFO file at path: /<>/python_daemon.egg-info/PKG-INFO", python-daemon [unknown version] (/<
Control: notfound -1 python-daemon/3.0.1-1.1 Control: reassign -1 dh-python Control: found -1 dh-python/6.20231025 Control: retitle -1 dh-python: Packages FTBFS because of missing metadata Control: fixed -1 dh-python/6.20231204 Control: fixed -1 dh-python/6.20231223 On 16-Dec-2023, s3v wrote: > I've just checked your package does build fine in a sid chroot > environment and reproducible-builds confirms that Thank you. When I build in an up-to-date ‘unstable’ (where ‘dh-python’ is at version “6.20231223”), I also get a successful build from source today. > it was built against dh-python/6.20231025 but the current version in sid is > dh-python/6.20231204. I can reproduce the failure with this commit reverted Agreed, this bug was in ‘dh-python’ and is now fixed. -- \ “I was stopped by the police for speeding; they said ‘Don't you | `\ know the speed limit is 55 miles an hour?’ I said ‘Yeah I know, | _o__) but I wasn't going to be out that long.’” —Steven Wright | Ben Finney signature.asc Description: PGP signature
Bug#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations)
Control: user helm...@debian.org Control: usertag -1 dep17p1 According to the classification in DEP-17 <https://subdivi.de/~helmut/dep17.html> this is problem type P1. libnfsidmap1 includes mitigation M7 (Conflicts with the other packages) since version 1:2.5.4-1~exp2, but although this usually avoids P1 we now know that this is not always the case. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#1058937: Conflicts with libnfsidmap{2,-regex} involving aliased file locations
Package: libnfsidmap1
Version: 1:2.5.4-1~exp1
Severity: serious
As receently disvovered by Helmut Grohne, a conflict between binary
packages does not ensure that the files of one will be removed before
the files of the other are installed. This can result in file loss
when the conflict involves aliased filenames rather than exactly the
same filenames.
This specific scenario exists when installing libnfsidmap1 as a
replacement for libnfsidmap{2,-regex} packages. I was able to
reproduce it with the following sequence of commands in a minimal
bullseye amd64 chroot:
# apt -y install usrmerge
# apt -y install libnfsidmap{2,-regex}
# sed -i 's/bullseye/bookworm/' /etc/apt/sources.list
# apt update
# apt -d -y install libnfsidmap1
# (cd /var/cache/apt/archives && \
dpkg -i libc{6,-bin}_2.36-9+deb12u3_amd64.deb \
libsasl2-{2,modules-db}_2.1.28+dfsg-10_amd64.deb \
libgmp10_2%3a6.2.1+dfsg1-1.1_amd64.deb \
libgnutls30_3.7.9-2_amd64.deb libldap-2.5-0_2.5.13+dfsg-5_amd64.deb)
# dpkg -i /var/cache/apt/archives/libnfsidmap1_1%3a2.6.2-4_amd64.deb
Ben.
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
The attached patch works on my systems. Is there a way to get this in?
--- arch/x86/kernel/reboot.c.orig 2023-12-14 08:25:10.033382061 +0100
+++ arch/x86/kernel/reboot.c 2023-12-14 08:31:10.394325941 +0100
@@ -469,6 +469,14 @@
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"),
},
},
+ { /* Handle problems with rebooting HP t640 thin-clients */
+ .callback = set_pci_reboot,
+ .ident = "HP t640",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP t640 Thin Client"),
+ },
+ },
{ /* PCIe Wifi card isn't detected after reboot otherwise */
.callback = set_pci_reboot,
Bug#1003805: python3-numpy: depends on two different Python versions
Package: python3-numpy Version: 1:1.24.2-2 Followup-For: Bug #1003805 Dear Maintainer, I second this request. By a quick survey of other « python3- » packages installed on my system, they all depend on python3:any (and not on python3.##:any). This means that *SOME* version of python3 will be installed, which, in almost all cases, is enough. Usually, it will be the current default version: today, 3.11 on sid, and when that bumps up to 3.12, then on most systems, all python3-xxx packages will switch to 3.12 in a manner essentially transparent to the user. If the user absoultely wants to use 3.12 today, there is nothing that prevents him or her to install python3.12 manually, and all python3- packages will also byte-compile to that automatically. On the other hand, with the hard Depends: of python3-numpy, the user is simply unable to decide NOT to isntall python3.12 , and this is indeed annoying to some. So, I request that you reduce the dependence to python3:any alone, as for other python3- packages. Yours, Itaï. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-numpy depends on: ii libatlas3-base [liblapack.so.3] 3.10.3-13 ii libblas3 [libblas.so.3] 3.11.0-2 ii libc62.37-13 ii liblapack3 [liblapack.so.3] 3.11.0-2 ii python3 3.11.6-1 ii python3-pkg-resources68.1.2-2 ii python3.11 3.11.7-1 ii python3.12 3.12.1-1 python3-numpy recommends no packages. Versions of packages python3-numpy suggests: ii gcc 4:13.2.0-2 pn gfortran ii python3-dev 3.11.6-1 pn python3-pytest -- no debconf information
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Control: reassign -1 src:linux 6.5.3-1~bpo12+1 Control: tag -1 moreinfo On Sat, 2023-12-02 at 18:11 +0100, Paul Gevers wrote: > Package: linux-image-6.5.0-0.deb12.1-arm64 > Version: 6.5.3-1~bpo12+1 > Severity: serious > Justification: system stops responding > > Dear kernel maintainers, > > Thursday 30 November I upgraded the ci.debian.net workers. We're running > the backports kernel there due to issues we discussed earlier, but after > upgrading, we lost access to our arm64 hosts one after the other. We're > running the 6.4 kernel again now, and I extracted some of the logs. > Please let me know if you need more info. The first error logged in this file has: > CPU: 6 PID: 15039 Comm: lxc-start Tainted: G D WL > 6.5.0-0.deb12.1-arm64 #1 Debian 6.5.3-1~bpo12+1 The D and W flags mean there were prior BUG and WARN errors logged. Please send those as well. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman signature.asc Description: This is a digitally signed message part
Bug#1057147: Acknowledgement (Does not look for config in ~/.config/dput/dput.cf)
Control: tag -1 patch I opened a merge request to fix this: <https://salsa.debian.org/debian/dput-ng/-/merge_requests/30> Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#1057147: Does not look for config in ~/.config/dput/dput.cf
Package: dput-ng Version: 1.37 Severity: normal dput now looks for its config in ~/.config/dput/dput.cf as well as ~/.dput.cf. (The ~/.config prefix should also be overridable by setting $XDG_CONFIG_HOME, but I haven't checked whether dput implements that.) Please add support for this alternate location. Ben. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 dput-ng depends on: ii python3 3.11.4-5+b1 ii python3-dput 1.37 dput-ng recommends no packages. Versions of packages dput-ng suggests: pn dput-ng-doc pn python3-twitter -- debconf-show failed
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
Some searching and some trial and error later I find that adding a "reboot=p"
to the kernel command line will result in en rebootable system. It looks like
this system ("HP t640 Thin Client") should be added to the list of boot quirks
in 'arch/x86/kernel/reboot.c'?
For the record, "c,p", "g,p" and "p" work, all other combinations fail to do a
functional reboot.
Bug#1056331: qemu-user-static: fails to run any binary with message "error while loading shared libraries" on Apple Silicon
Package: qemu-user-static Version: 1:8.1.2+ds-1 Severity: important X-Debbugs-Cc: tho...@glanzmann.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, On my M1 Mac Mini running Thomas Glanzmann's Asahi port, qemu-user-static fails with only the message "error while loading shared libraries:" and nothing else; this is when trying to run any binary in a fresh debootstrap chroot which should have all the libraries it needs. QEMU did used to have a bug affecting Apple Silicon, but this was fixed in 8.1.1. Folks in the IRC chat suggest that it may be a Debian packaging issue. Thanks, - -- Ben Westover - -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.5.0-asahi-00780-g62806c2c6f29 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC 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 qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii systemd 254.5-1 qemu-user-static suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmVcCBwACgkQwxHF9U6J tphu4Q/+Iply2hp9Pzdq14ZCwZ9hlvygugrYgCuriJy3zmlctsT0Puhdn2By7dDZ OBz2SkQtot9ddGaew3z/3iGh8IiBcjKjlWtPWIH6YN27iApYUAu2sXH5TvC7Ca7v 7QapiPF91BVf//tddE5D505hBU0CNjvNrmII+7TXDRGdoJIJd0jCYCMEuiAliE8Y RF3/JE+NQeXWKKFjHy13v2+055Uxvyh/C63UiCuvAxrpitfQLZdrB9tMgk+ADTi+ JB2yad164blFRNAv2A4Qke8PoSOhlbyTGHyAYVK1eFwx7ckl/8+K/0BpQciTD7KE U/6v7GRx4efHSfguPLTWlf6Pfvpekx+/aLjleeAOurMHDgg7AcdO7d2A7AGjhMTO ksdL9gNHfIYYxu8MhnNIrwjZHk3ntmEshh65e1L3PCARTsZt/qzKdimeziCmqKgR Aqsak/mNvWnGlQzA/F1JrPXoaiejbzwNWm2RZW4M3uWGFMpKVH5acF2yFd0CuFQO gGfc96HomMw7uZxtpGcPQALqDWvpsKHUlYaNRuC3XQI6qXoWJiaaBslVx9LII6Kk rAz9pG1PwG65c8s+ansZ4DMjwL8Sp2eBw+mwl6Bm17y/l1FThf0XmvPEA4B3NQ/b hAUkpOj6gb0LwgtOfJ4sx0DAEC5OqKsolEj8X0FPqRYixLgNMMY= =EY8G -END PGP SIGNATURE-
Bug#1056056: Acknowledgement (linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640)
Control: merge 1056055 1056056 Van: Debian Bug Tracking System Verzonden: donderdag 16 november 2023 14:21 Aan: Ben Mesman | Spark Narrowcasting Onderwerp: Bug#1056056: Acknowledgement (linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640) [U ontvangt vaak geen e-mail van ow...@bugs.debian.org. Informatie over waarom dit belangrijk is op https://aka.ms/LearnAboutSenderIdentification] LET OP: Deze e-mail is afkomstig van buiten de organisatie. Klik niet op links en open geen bijlagen tenzij je de afzender kent en weet dat de inhoud veilig is. Bij twijfel neem, altijd contact op met de Servicedesk. CAUTION: This email was sent from an external source. Do not click on links or open attachments unless you know the sender and the content is safe. When in doubt, please contact the Servicedesk. Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1056056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056056. 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. As you requested using X-Debbugs-CC, your message was also forwarded to b...@sparknarrowcasting.nl (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 1056...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1056056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056056 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
Package: src:linux Version: 6.1.55-1 Severity: important X-Debbugs-Cc: b...@sparknarrowcasting.nl If the HP t640 (I tried 2 different systems) runs this kernel, a 'reboot' will result in the BIOS reporting that the disk is missing. After a cold reboot (turning the device off and on again) the disk wil be detected and the system will boot as expected. The next reboot will again trigger this bug. Other HP thin-clients from similar series (t620, t630, t655) do not have the same problem. Debian bullseye (kernel 5.10) does not have this problem, but upgrading to 6.1.0 (through bulleye-backports) will trigger this bug. Upgrading bookworm to a 6.5 kernel (through bookworm-backports) does not solve the bug. Because the installer uses the same kernel, after the installation is complete and does the reboot, the bug will be triggered. -- Package-specific info: ** Version: Linux version 6.1.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 root=UUID=3b7b05fe-9cdc-49e7-9416-319125d9858e ro quiet ** Not tainted ** Kernel log: [ 0.00] Linux version 6.1.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) [ 0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 root=UUID=3b7b05fe-9cdc-49e7-9416-319125d9858e ro quiet [ 0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x-0x0009] usable [ 0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [ 0.00] BIOS-e820: [mem 0x0010-0x09df] usable [ 0.00] BIOS-e820: [mem 0x09e0-0x09ffdfff] reserved [ 0.00] BIOS-e820: [mem 0x09ffe000-0x0a1f] usable [ 0.00] BIOS-e820: [mem 0x0a20-0x0a20afff] ACPI NVS [ 0.00] BIOS-e820: [mem 0x0a20b000-0x7a88dfff] usable [ 0.00] BIOS-e820: [mem 0x7a88e000-0x7a980fff] reserved [ 0.00] BIOS-e820: [mem 0x7a981000-0x7a9b5fff] ACPI data [ 0.00] BIOS-e820: [mem 0x7a9b6000-0x7af20fff] ACPI NVS [ 0.00] BIOS-e820: [mem 0x7af21000-0x7c96bfff] reserved [ 0.00] BIOS-e820: [mem 0x7c96c000-0x7ca04fff] type 20 [ 0.00] BIOS-e820: [mem 0x7ca05000-0x7dff] usable [ 0.00] BIOS-e820: [mem 0x7e00-0x7fff] reserved [ 0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [ 0.00] BIOS-e820: [mem 0xfd00-0xfdff] reserved [ 0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved [ 0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [ 0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [ 0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [ 0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [ 0.00] BIOS-e820: [mem 0xfedc2000-0xfedc] reserved [ 0.00] BIOS-e820: [mem 0xfedd4000-0xfedd5fff] reserved [ 0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved [ 0.00] BIOS-e820: [mem 0xff00-0x] reserved [ 0.00] BIOS-e820: [mem 0x0001-0x00015eff] usable [ 0.00] BIOS-e820: [mem 0x00015f00-0x00017eff] reserved [ 0.00] BIOS-e820: [mem 0x00017f00-0x00017f33] usable [ 0.00] BIOS-e820: [mem 0x00017f34-0x00017fff] reserved [ 0.00] NX (Execute Disable) protection: active [ 0.00] efi: EFI v2.70 by American Megatrends [ 0.00] efi: TPMFinalLog=0x7aed8000 ACPI 2.0=0x7a998000 ACPI=0x7a998000 SMBIOS=0x7c82 SMBIOS 3.0=0x7c81f000 MEMATTR=0x790b6298 ESRT=0x790c0698 [ 0.00] secureboot: Secure boot disabled [ 0.00] SMBIOS 3.2.1 present. [ 0.00] DMI: HP HP t640 Thin Client/8523, BIOS M43 v01.04 10/29/2019 [ 0.00] tsc: Fast TSC calibration using PIT [ 0.00] tsc: Detected 2395.458 MHz processor [ 0.000628] e820: update [mem 0x-0x0fff] usable ==> reserved [ 0.000631] e820: remove [mem 0x000a-0x000f] usable [ 0.000644] last_pfn = 0x17f340 max_arch_pfn = 0x4 [ 0.001139] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [ 0.001351] e820: update [mem 0x8000-0x] usable ==> reserved [ 0.001361] last_pfn = 0x7e000 max_arch_pfn = 0x4 [ 0.006355] esrt: Reserving ESRT space from 0x790c0698 to 0x790c06d0. [ 0.006369] e820: update [mem
Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2
Control: tags -1 + upstream patch
On 12-Nov-2023, Ben Finney wrote:
> Either:
>
> * The upstream version constraint needs to be relaxed by the upstream
> project, to allow ‘python3-rich’ version “3.0.0-2” to satisfy the
> dependency.
This is the resolution indicated by the upstream code base. In versions
starting at “13.4.2”, the upstream project declares dependencies that allow
‘markdown-it-py’ version “3.0.0” also.
https://github.com/Textualize/rich/commit/f232e9d95bbe4747f12459d5935cfa2a42c08069>
This can be applied with a simple patch:
=
diff --git old/pyproject.toml new/pyproject.toml
--- old/pyproject.toml
+++ new/pyproject.toml
@@ -30,7 +30,7 @@
typing-extensions = { version = ">=4.0.0, <5.0", python = "<3.9" }
pygments = "^2.14.0"
ipywidgets = { version = ">=7.5.1,<9", optional = true }
-markdown-it-py = "^2.1.0"
+markdown-it-py = ">=2.1.0"
[tool.poetry.extras]
jupyter = ["ipywidgets"]
=
or by upgrading Debian's ‘rich’ package source, to upstream's version
“13.4.2” or later.
--
\ “You can never entirely stop being what you once were. That's |
`\ why it's important to be the right person today, and not put it |
_o__) off until tomorrow.” —Larry Wall |
Ben Finney
signature.asc
Description: PGP signature
Bug#1055954: ITP: controku -- Control Roku devices from the comfort of your own desktop
Package: wnpp Severity: wishlist Owner: Ben Westover X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: controku Version : 1.1.0 Upstream Contact: Ben Westover * URL : https://github.com/benthetechguy/controku * License : GPL-3 Programming Lang: Python Description : Control Roku devices from the comfort of your own desktop Controku is a library and GTK3 application that allows you to control Roku devices from the comfort of your own desktop. I am the developer of this program. I find it very useful, and it would be nice to have in Debian. I plan to maintain it inside of the Python team. I will need a sponsor for the initial upload, as I am only a DM. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmVTr6kACgkQwxHF9U6J tphZVxAAps/BL8t83IiPaA5EoTlx5SlIs1me9g266vzAVaootjg5vJ5uUa86snA1 efdCdKfBvNgXyECQxM1yK0TFp4utM0yRAYg1f4JfZ2pZBI2/cyNenlUizvD3Qdp7 jSzHpdBHpEv0O+yzhU9F6PhO+jfUBRubKMjFheUU/8n1VWYNnGdbLvH4hIIO2pEi aNtlqX95BA2jxNwpJldkMYqIxKKrY1pnu8iXaOGZ6gen8Ru6e1hQ4RxmHva5odh3 5ws6rwLsAW+Butlsa4dRWfS5+tpzbjsf780bvu2oI1Anqrp04CaiKyvGlIV2V0TA QLk6vFLVT8Y0TZHuTJxYmUHBYt+gZ9TVIj/hIkQZLCRpWRXEj2SKAPe8t2ZimcXU Zbes0u8QdakmMT52swvL1Wv8AOd+Xfi4DSuYhM8ZJ+18PQ/Cwa2X3Pqre9JGPkQ8 GPiHDY3ff57kaun7inSMrKU0gYqisuLVq2MrFSyt2YckEfdHenzp5o5xMg6Y22xI 1OKMNTh99N/qkrPl0v4ueX0B6XE2NagDF/Jo55U0jxmOc1Hin3i0iE8Xz9Wu2qwk eKZxbbwnF5x3CLAHcuDTSsqvE8deqxHSXJNuBFh9iMNm1JrnTqmWSDrpEG2lmpZz uAKMzGqgfeKQIT7cjqXM5Dk8mOwObthvR5weg2hTUg+LMDVtpJ4= =BtbR -END PGP SIGNATURE-
Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2
On 12-Nov-2023, Sandro Tosi wrote: > > The inconsistent constraints need to be resolved; > > no they dont. debian uses apt not pip to install packages. The ‘pip’ command-line tool can also query which packages Python knows are installed, and that uses the database derived from Python package metadata. So, the Python metadata installed by the Debian package needs to be consistent with the dependencies. > from a packaging perspective, what matter is "does rich work?" and since > the answer is "yes" In the aspect of Python giving the correct answer from a query using ‘pip’, it isn't working. This is because the query is not of the Debian package database, but the Python metadata. This can be resolved by making the Debian dependencies and the Python metadata declared dependencies, consistent. Please address this so that the Python standard ‘pip’ tool can get the correct information from the Python metadata installed by these Debian packages. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney signature.asc Description: PGP signature
Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2
Package: python3-rich Version: 13.3.1-2 Severity: normal Howdy, The Debian binary package ‘python3-rich’ declares: Depends: python3-markdown-it with no version constraint. On this machine, the dependency is satisfied by the only available version ‘python3-markdown-it’ version “3.0.0-2”. The Python metadata installed by the Debian ‘python3-rich’ package declares a constrained version range for that corresponding dependency: Requires-Dist: markdown-it-py (>=2.1.0,<3.0.0) This results in the Python ‘pip’ package dependency graph reporting (correctly) that its version constraints are not satisfied by the installed packages: INFO: pip is looking at multiple versions of rich to determine which version is compatible with other requirements. This could take a while. ERROR: Could not find a version that satisfies the requirement markdown-it-py<3.0.0,>=2.1.0 (from rich) (from versions: none) The inconsistent constraints need to be resolved; the Python package metadata dependency declarations need to be satisfied when the Debian package is installed. Either: * The upstream version constraint needs to be relaxed by the upstream project, to allow ‘python3-rich’ version “3.0.0-2” to satisfy the dependency. or * The Debian package needs to constrain its dependency on ‘python3-rich’ to match upstream's declared constraints. -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-rich depends on: ii python3 [python3-supported-min] 3.11.4-5+b1 ii python3-markdown-it 3.0.0-2 ii python3-pygments 2.15.1+dfsg-1 ii python3-typing-extensions4.7.1-2 python3-rich recommends no packages. python3-rich suggests no packages. -- no debconf information
Bug#1055823: Acknowledgement (neomutt: Cannot open terminal using default installation location of binary)
Well I noticed at the end of the report about an apparmor profile being active for neomutt. So I added a rule to allow terminfo and that fixed things. Sorry for the noise.
Bug#1055823: neomutt: Cannot open terminal using default installation location of binary
Package: neomutt Version: 20220429+dfsg1-4.1 Severity: important Dear Maintainer, I am having strange problem getting neomutt to run using the default installation location of /usr/bin/neomutt. If I copy the binary to /tmp there is no problem. Using bash or dash has the same results. I can't find any other program that does this. Here's the test commands: $ unset LD_LIBRARY_PATH $ export PATH=/bin:/usr/bin $ md5sum /tmp/neomutt /usr/bin/neomutt cf48133c08534446745457c08fe0bf7b /tmp/neomutt cf48133c08534446745457c08fe0bf7b /usr/bin/neomutt $ /usr/bin/neomutt Error opening terminal: xterm-256color. $ /tmp/neomutt Which works fine. When I build from upstream git and copy the debianization files from the package obtained by 'apt source neomutt' (with a few modifications to get it to build), the result is the same after installing the .deb. The output of 'ldd /tmp/neomutt': linux-vdso.so.1 (0x7ffdd19a5000) libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f9d503a1000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7f9d50361000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f9d50329000) libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f9d501b9000) libnotmuch.so.5 => /lib/x86_64-linux-gnu/libnotmuch.so.5 (0x7f9d50169000) libgpgme.so.11 => /lib/x86_64-linux-gnu/libgpgme.so.11 (0x7f9d50111000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f9d500e9000) libgsasl.so.18 => /lib/x86_64-linux-gnu/libgsasl.so.18 (0x7f9d500c1000) liblua5.4.so.0 => /lib/x86_64-linux-gnu/liblua5.4.so.0 (0x7f9d50079000) libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x7f9d4fe0) libidn.so.12 => /lib/x86_64-linux-gnu/libidn.so.12 (0x7f9d50041000) libtokyocabinet.so.9 => /lib/x86_64-linux-gnu/libtokyocabinet.so.9 (0x7f9d4fcf1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9d4fb09000) libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f9d4fa29000) libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f9d4f9f9000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f9d50039000) libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f9d50029000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9d4f919000) libgmime-3.0.so.0 => /lib/x86_64-linux-gnu/libgmime-3.0.so.0 (0x7f9d4f899000) libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x7f9d4f831000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7f9d4f6e9000) libtalloc.so.2 => /lib/x86_64-linux-gnu/libtalloc.so.2 (0x7f9d4f6d9000) libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 (0x7f9d4f40) libsexp.so.2 => /lib/x86_64-linux-gnu/libsexp.so.2 (0x7f9d4f6c9000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f9d4f00) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f9d4f6a1000) /lib64/ld-linux-x86-64.so.2 (0x7f9d505e1000) libassuan.so.0 => /lib/x86_64-linux-gnu/libassuan.so.0 (0x7f9d4f689000) libntlm.so.0 => /lib/x86_64-linux-gnu/libntlm.so.0 (0x7f9d4f679000) libgssglue.so.1 => /lib/x86_64-linux-gnu/libgssglue.so.1 (0x7f9d4f669000) libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f9d4f261000) libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7f9d4efc9000) libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 (0x7f9d4ee19000) libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f9d4f651000) libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x7f9d4edc1000) libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x7f9d4ed71000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x7f9d4ece9000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f9d4f639000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f9d4ecc9000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9d50021000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f9d4ecc1000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f9d4eca9000) libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x7f9d4eab9000) libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x7f9d4eaa9000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x7f9d4ea09000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f9d4e9f9000) libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x7f9d4e9f1000) libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1
Bug#1055769: blag: add dependency “Suggests” for documentation
Source: blag Version: 2.2.0 Severity: minor Dear Maintainer, Working with the ‘blag’ package requires understanding how it works and what it does. Please set a “Suggests: blag-doc” dependency to the binary package ‘blag’. This will present the suggestion to administrators choosing which packages to install. -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney signature.asc Description: PGP signature
Bug#1055483: util-linux: Please include /usr/sbin/fdformat
Package: util-linux Version: 2.39.2-5 Severity: normal X-Debbugs-Cc: bugs.debian@wongs.net Dear Maintainer, Ever since Bookworm, fdformat, the floppy disk low-level format program has been missing. This is because upstream no longer configures it by default in order to save disk space. However, without that tool, there is no way to format a floppy in Debian. Alternatives tried: Kfloppy actually calls fdformat. Gnome-disks simply calls Udisks2 which appears to only know how to high-level format a floppy (mkfs). The fdutils package contains only formatting programs for unusual formats (superformat, xdfcopy). I was able to extract the executable and man page for fdformat from the .deb package in Bullseyes, but that is not a good solution. It would be appreciated if the Debian maintainers would configure Util Linux to build the fdformat program: ./configure --enable-fdformat I have tested this (after 'apt source util-linux') and that is all that is needed. If for some reason it is not possible to re-enable fdformat in the util-linux package, then I hope that fdformat can be adopted by the fdutils package. -- 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-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii libblkid1 2.39.2-5 ii libc6 2.37-12 ii libcap-ng0 0.8.3-1+b3 ii libcrypt1 1:4.4.36-2 ii libmount1 2.39.2-5 ii libpam0g 1.5.2-9.1 ii libselinux13.5-1 ii libsmartcols1 2.39.2-5 ii libsystemd0254.5-1 ii libtinfo6 6.4+20231016-1 ii libudev1 254.5-1 ii libuuid1 2.39.2-5 ii zlib1g 1:1.2.13.dfsg-3 Versions of packages util-linux recommends: ii sensible-utils 0.0.20 Versions of packages util-linux suggests: ii dosfstools 4.2-1 ii kbd 2.5.1-1+b1 ii util-linux-extra2.39.2-5 ii util-linux-locales 2.39.2-5 -- no debconf information
Bug#1053122: Fwd: Re: Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible
Control: tag -1 - moreinfo Forwarded Message From: Gabriel Francisco To: Ben Hutchings Subject: Re: Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible Date: 12/10/23 20:23:30 Message-Id: Hi, > The CPU registers contain several addresses starting 89, except for > rbx which starts 99 (and is the faulting address). That looks like > a single bit got flipped. Thanks for the explanation! (now I know how to detect bit flips) :D > The first BUG message should be more meaningful that what comes after. > This shows the kernel tried to access non-existent memory. Yes, I should have reported the first one indeed, I thought too much and ended reporting the second one. Sorry about that. > This could be due to a kernel bug, but is more likely a hardware > problem. Please test the RAM with memtest86+. Also if you've enabled > any overclocking options, turn those off. Even with XMP(3000@1.35v) enabled (F4-3000C16-16GISB), memtest86+ ran for 3 hours and printed PASS in the screen. I removed the XMP profile from my memories and ordered new rams to check if my current ones are faulty (or not). The message in dmesg was only one occasion. (but I reported it anyways) The hang does still happens with/without XMP when running 6.5.x kernel series. It happens when maximizing a video (or time-to-time when my cursor enters the video area) when using kernel 6.5.x. It does not happen with kernel 6.1.x series. I'm using amgpu module. Greetings, *Gabriel Francisco* Linux User #507840 email: frc.gabriel[at]gmail.com On Thu, Oct 5, 2023 at 1:15 AM Ben Hutchings wrote: > Control: retitle -1 linux-image-6.5.0-1-amd64: Kernel page fault in > process exit due to bit flip > Control: tag -1 moreinfo > > On Wed, 2023-09-27 at 20:45 +0200, Gabriel Francisco wrote: > > Package: src:linux > > Version: 6.5.3-1 > > Severity: important > > Tags: upstream > > X-Debbugs-Cc: frc.gabr...@gmail.com > > > > Dear Maintainer, > > > > First of all thanks for your hard work! > > > > I noticed my computer started freezing for few seconds when > entering/exiting > > full screen videos in youtube using firefox and while trying to check if > the > > issue also afected chromium I saw the following message in dmesg: > > > > [12569.564300] BUG: unable to handle page fault for address: > 991989e936b8 > > [12569.564304] #PF: supervisor write access in kernel mode > > [12569.564306] #PF: error_code(0x0002) - not-present page > > The first BUG message should be more meaningful that what comes after. > This shows the kernel tried to access non-existent memory. > > > [12569.564308] PGD 0 P4D 0 > > [12569.564311] Oops: 0002 [#1] PREEMPT SMP NOPTI > > [12569.564314] CPU: 10 PID: 328649 Comm: Chroot Helper Not tainted > 6.5.0-1-amd64 #1 Debian 6.5.3-1 > > [12569.564317] Hardware name: ASUS System Product Name/ROG STRIX B550-F > GAMING WIFI II, BIOS 3205 08/14/2023 > > [12569.564318] RIP: 0010:down_write+0x23/0x70 > > [12569.564324] Code: 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 > 48 89 fb e8 2e bc ff ff bf 01 00 00 00 e8 74 3a 53 ff 31 c0 ba 01 00 00 00 > 48 0f b1 13 75 33 65 48 8b 04 25 80 29 03 00 48 89 43 08 bf 01 > > [12569.564326] RSP: 0018:a189d736fc70 EFLAGS: 00010246 > > [12569.564328] RAX: RBX: 991989e936b8 RCX: > 891797aaef00 > > [12569.564330] RDX: 0001 RSI: 891989e645c0 RDI: > 8e7c95dc > > [12569.564331] RBP: R08: 0060 R09: > 80400014 > > [12569.564333] R10: 8918cbfeb7f8 R11: 0006 R12: > 7f7e5fd0 > > [12569.564334] R13: 0001 R14: 891989e645c0 R15: > 891989e64958 > > The CPU registers contain several addresses starting 89, except for > rbx which starts 99 (and is the faulting address). That looks like > a single bit got flipped. > > This could be due to a kernel bug, but is more likely a hardware > problem. Please test the RAM with memtest86+. Also if you've enabled > any overclocking options, turn those off. > > [...] > > After that the computer can't shutdown and systemd keeps waiting on > process PID 328649 (Chroot Helper). > > This (and the other BUG messages) are because that process crashed in > kernel mode and couldn't properly exit. > > Ben. > > -- > Ben Hutchings > Beware of bugs in the above code; > I have only proved it correct, not tried it. - Donald Knuth > > Hi,> The CPU registers contain several addresses starting 89, except for > rbx which starts 99 (and is the faulting address). That looks like> a single bit got flipped.Thanks for the explanati
Bug#1053983: dos2unix: Man page should mention that UTF-16 is converted to UTF-8 by default
Hello Tony, On Sun, Oct 15, 2023 at 8:26 AM tony mancill wrote: > Hi Ben, > > I believe the portion of the manpage you are referring to is: > > CONVERSION MODES > ascii > In mode "ascii" only line breaks are converted. This is the default > conversion mode. [**Missing information about UTF-16 behavior.**] > > Although the name of this mode is ASCII, which is a 7 bit standard, > the actual mode is 8 bit. Use always this mode when converting > Unicode UTF-8 files. > Yes, that is the section I was considering. The first sentence is quite definite that _only_ line breaks are converted, so the conversion of UTF-16 was a surprise (a pleasant one, yes, but still a surprise). Ideally, I'd like to see the option renamed and the man page say something like: CONVERSION MODES unix In the default mode, "unix", line breaks are converted to newlines, Unicode characters are encoded in UTF-8, and any BOM header is stripped. This mode was originally called "ascii" and that name still works as an alias for backwards compatibility. And, yes, I had missed the reference to how -ascii actually works in the --keep-utf16 section. It is good to see that unix2dos actually does what I wanted rather than what it claims it does. Thank you. Ben Wong
Bug#1053983: dos2unix: Man page should mention that UTF-16 is converted to UTF-8 by default
Package: dos2unix Version: 7.5.1-1 Severity: normal X-Debbugs-Cc: bugs.debian@wongs.net Dear Maintainer, The dos2unix man page claims that the default mode is "ASCII" and that in ASCII mode only line endings will be changed. This is no longer true. In the default mode, UTF-16 is converted to UTF-8 and the BOM is removed. I do not know if this is still considered an "ASCII" mode or if the default is some new UTF-8 mode. Please consider updating the documentation to match the current behavior. Thanks! *** End of the template - remove these template lines *** -- 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-1-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 dos2unix depends on: ii libc6 2.37-12 dos2unix recommends no packages. dos2unix suggests no packages. -- no debconf information
Bug#1052676: linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK)
Control: severity -1 important On Tue, 2023-09-26 at 22:45 +0200, Diederik de Haas wrote: [...] > I don't know *IF* it's possible to still add hardware support to the 6.1 > kernel which is used in Stable/Bookworm. Assuming the platforms were properly > supported in the upstream 6.1 kernel, then there still has been zero testing > with it on a Debian system, which does not sound ideal for Stable. > One of the Debian kernel maintainers would have to answer whether it is > possible at all for 6.1/Stable/Bookworm. [...] I'm not sure if it's documented anywhere, but release team policy has been that hardware enablement is allowed in stable updates. (If that involves changes to a driver we already enabled, the benefit has to be weighed against the risk of regressions for previously supported devices. But I don't that's being proposed here.) Even though there won't have been broad testing of the Debian kernel configuration on the Mediatek SoCs, this can't possibly be a regression for them. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible
Control: retitle -1 linux-image-6.5.0-1-amd64: Kernel page fault in process exit due to bit flip Control: tag -1 moreinfo On Wed, 2023-09-27 at 20:45 +0200, Gabriel Francisco wrote: > Package: src:linux > Version: 6.5.3-1 > Severity: important > Tags: upstream > X-Debbugs-Cc: frc.gabr...@gmail.com > > Dear Maintainer, > > First of all thanks for your hard work! > > I noticed my computer started freezing for few seconds when entering/exiting > full screen videos in youtube using firefox and while trying to check if the > issue also afected chromium I saw the following message in dmesg: > > [12569.564300] BUG: unable to handle page fault for address: 991989e936b8 > [12569.564304] #PF: supervisor write access in kernel mode > [12569.564306] #PF: error_code(0x0002) - not-present page The first BUG message should be more meaningful that what comes after. This shows the kernel tried to access non-existent memory. > [12569.564308] PGD 0 P4D 0 > [12569.564311] Oops: 0002 [#1] PREEMPT SMP NOPTI > [12569.564314] CPU: 10 PID: 328649 Comm: Chroot Helper Not tainted > 6.5.0-1-amd64 #1 Debian 6.5.3-1 > [12569.564317] Hardware name: ASUS System Product Name/ROG STRIX B550-F > GAMING WIFI II, BIOS 3205 08/14/2023 > [12569.564318] RIP: 0010:down_write+0x23/0x70 > [12569.564324] Code: 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 > fb e8 2e bc ff ff bf 01 00 00 00 e8 74 3a 53 ff 31 c0 ba 01 00 00 00 48 > 0f b1 13 75 33 65 48 8b 04 25 80 29 03 00 48 89 43 08 bf 01 > [12569.564326] RSP: 0018:a189d736fc70 EFLAGS: 00010246 > [12569.564328] RAX: RBX: 991989e936b8 RCX: > 891797aaef00 > [12569.564330] RDX: 0001 RSI: 891989e645c0 RDI: > 8e7c95dc > [12569.564331] RBP: R08: 0060 R09: > 80400014 > [12569.564333] R10: 8918cbfeb7f8 R11: 0006 R12: > 7f7e5fd0 > [12569.564334] R13: 0001 R14: 891989e645c0 R15: > 891989e64958 The CPU registers contain several addresses starting 89, except for rbx which starts 99 (and is the faulting address). That looks like a single bit got flipped. This could be due to a kernel bug, but is more likely a hardware problem. Please test the RAM with memtest86+. Also if you've enabled any overclocking options, turn those off. [...] > After that the computer can't shutdown and systemd keeps waiting on process > PID 328649 (Chroot Helper). This (and the other BUG messages) are because that process crashed in kernel mode and couldn't properly exit. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#1053384: RFP: elpa-gdscript-mode -- Emacs mode for editing GDScript program code
Package: wnpp Severity: wishlist * Package name: emacs-gdscript-mode Version : 1.4.0 Upstream Contact: xiliuya * URL : https://github.com/godotengine/emacs-gdscript-mode * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs mode for editing GDScript program code This package installs an Emacs major mode for editing code in the GDScript programming language. It gives syntax highlighting and indentations. The GDScript language is the native programming language for writing scripts in the Godot game engine. -- \ “The only tyrant I accept in this world is the still voice | `\ within.” —Mohandas K. Gandhi | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1053254: new version available
Source: ries Version: 2018.08.05-1 Severity: normal X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Just a notice. 2023-08-01 version available there is also: Debian Math Team -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup
I have been able to figure out what is going on. The crash is due to a typo in FreeType which was recently fixed [0]. This change is also needed. I can confirm in a local build that with this typo fix the reported Chromium crash (in libfreetype.so.6) is fixed. To be clear, this FreeType change [0] is needed in addition to the the COLRv1 disable [1]. [0] https://gitlab.freedesktop.org/freetype/freetype/-/commit/16f311d72582c117796a23e22074fe9624760ee1 [1] https://salsa.debian.org/debian/freetype/-/commit/f65637c7f84fa2ccfb14c11d0ed0f315fe83636d On Thu, Sep 28, 2023 at 10:36 AM Ben Wagner wrote: > > I will take a look into this, but I am confused. > FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported > function. This change will affect its behavior to always return 0 > (false) but that often happens anyway even without this change (most > fonts don't have COLRv1 tables). For now it's fine to to revert the > change as the original issue does not currently affect many users, but > it is an issue that will need to be addressed. > > On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster wrote: > > > > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote: > >> > >> Hi Andres, > >> > >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote: > >> > > >> > Control: affects -1 chromium > >> > > >> > > >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote: > >> > > Hi, > >> > > > >> > > In chromium source code, function SkScalerContext::GlyphMetrics > >> > > SkScalerContext_FreeType::generateMetrics() will call > >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow > >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied, > >> > > and > >> > > chromium will not be able to run. > >> > > >> > > >> > This smells like an ABI change that doesn't really seem appropriate for > >> > a point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's > >> > Chromium, but I wonder if any other packages are using it on bookworm? > >> > > >> > For the record, Skia has the following code: > >> > > >> > #ifdef TT_SUPPORT_COLRV1 > >> > > >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST > >> > is defined. > >> > #if (((FREETYPE_MAJOR) < 2) || \ > >> > ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) < 11) || \ > >> > ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && > >> > (FREETYPE_PATCH) < 1)) && \ > >> > !defined(FT_STATIC_CAST) > >> > #undef TT_SUPPORT_COLRV1 > >> > > >> > > >> > So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid > >> > (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going > >> > to remain disabled on bookworm via the proposed-update (with chromium > >> > being the only broken package), then I'll probably just bump that > >> > version check to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13. > >> > >> FreeType 2.12.1 was released with experimental COLRv1 support enabled. > >> This was unintentional, as the implementation shipped in this release > >> was incomplete and incompatible with the final COLRv1 API. > >> > >> Upstream's intention was to enable COLRv1 support in FreeType 2.13.0, > >> which has a stable and complete COLRv1 API. > >> > >> I'm surprised Chromium actually used an experimental API, although > >> this version check copied above seems like a bug. > >> > >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages. > >> firefox*, godot and paraview are fine. Most of the openjdk-* packages > >> aren't in bookworm. > > > > > > After discussing the timing of Debian 12.2 with a release manager, I’ll > > revert the change shortly. > > > > Hugh
Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup
I will take a look into this, but I am confused. FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported function. This change will affect its behavior to always return 0 (false) but that often happens anyway even without this change (most fonts don't have COLRv1 tables). For now it's fine to to revert the change as the original issue does not currently affect many users, but it is an issue that will need to be addressed. On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster wrote: > > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote: >> >> Hi Andres, >> >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote: >> > >> > Control: affects -1 chromium >> > >> > >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote: >> > > Hi, >> > > >> > > In chromium source code, function SkScalerContext::GlyphMetrics >> > > SkScalerContext_FreeType::generateMetrics() will call >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied, >> > > and >> > > chromium will not be able to run. >> > >> > >> > This smells like an ABI change that doesn't really seem appropriate for a >> > point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's >> > Chromium, but I wonder if any other packages are using it on bookworm? >> > >> > For the record, Skia has the following code: >> > >> > #ifdef TT_SUPPORT_COLRV1 >> > >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST >> > is defined. >> > #if (((FREETYPE_MAJOR) < 2) || \ >> > ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) < 11) || \ >> > ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && (FREETYPE_PATCH) >> > < 1)) && \ >> > !defined(FT_STATIC_CAST) >> > #undef TT_SUPPORT_COLRV1 >> > >> > >> > So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid >> > (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going to >> > remain disabled on bookworm via the proposed-update (with chromium being >> > the only broken package), then I'll probably just bump that version check >> > to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13. >> >> FreeType 2.12.1 was released with experimental COLRv1 support enabled. >> This was unintentional, as the implementation shipped in this release >> was incomplete and incompatible with the final COLRv1 API. >> >> Upstream's intention was to enable COLRv1 support in FreeType 2.13.0, >> which has a stable and complete COLRv1 API. >> >> I'm surprised Chromium actually used an experimental API, although >> this version check copied above seems like a bug. >> >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages. >> firefox*, godot and paraview are fine. Most of the openjdk-* packages >> aren't in bookworm. > > > After discussing the timing of Debian 12.2 with a release manager, I’ll > revert the change shortly. > > Hugh
Bug#1052394: php-graham-campbell-result-type: correction to short description
reference Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description
Bug#1052396: php-ramsey-collection: small correction to short description
reference Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description
Bug#1052395: php-laravel-serializable-closure: correction to short description
reference Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description
Bug#1052370: mrbuild: small correction to the short title
Reference Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description
Bug#1052266: kdiskmark: please change short description
reference Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short descriptiony
Bug#1053129: small correction to the short description
Package: r-cran-poorman X-Debbugs-CC: benatt...@gezapig.nl Severity: minor Dear Maintainer, The short description contains a typo. sependency should be: dependency this: Poor Man's sependency free recreation of 'dplyr' GNU R package to: Poor Man's dependency free recreation of 'dplyr' GNU R package
Bug#1053097: plee-the-bear: new version
Source: plee-the-bear Version: 0.6.0-8 Severity: normal X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Somewhat confused. Seems that Julien Jorge, one of the listed uploaders has made a new release: https://github.com/j-jorge/plee-the-bear -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1053095: picked up project with version 2.08
Source: geki2 Version: 2.0.3-10 Severity: normal X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Someone seems to work on this game and makes releases. Maybe it's worth to take a look. https://github.com/Quipyowert2/geki2 -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052401: plasma-mobile: correction to short description
No need to follow the original description. It's not uncommon that a package is open source in Debian main. Do not expect that it's the only open source in it's kind. Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description
Bug#1052681: no uploader
Timo Aaltonen schreef op di 26-09-2023 om 09:01 [+0300]: > Ben Tris kirjoitti 26.9.2023 klo 8.50: > > Source: xinit > > X-Debbugs-Cc: benatt...@gezapig.nl > > Severity: important > > > > Dear Maintainer, > > > > There is no uploader at this moment, it is required in this case I > > think. > > > > Debian Policy Manual, Release 4.6.2.0 > > 3.3 The maintainer of a package > > > > If the maintainer of the package is a team of people with a shared > > email > > address, the Uploaders control field must be > > present and must contain at least one human with their personal > > email > > address. > > > > Stop already, these bugreports are of no use. > Thank for the notion. I would like to know why this bug report is of no use.
Bug#1052681: no uploader
Source: xinit X-Debbugs-Cc: benatt...@gezapig.nl Severity: important Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address.
Bug#1052680: no uploader
Source: xfonts-utils X-Debbugs-Cc: benatt...@gezapig.nl Severity: important Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address.
Bug#1052679: no uploader
Source: xcursor-themes X-Debbugs-Cc: benatt...@gezapig.nl Version: 1.0.5-1 Severity: important Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address.
Bug#1052662: no uploader
Source: twm Version: 1:1.0.10-1 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052600: libxss: No uploader
Source: libxss Version: 1:1.2.3-1 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052599: No uploader
Source: libxshmfence Version: 1.3-1 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052559: No uploader
Bastian Germann schreef op zo 24-09-2023 om 20:45 [+0200]: > Am 24.09.23 um 20:39 schrieb Ben Tris: > > I think this counts also in this case? > > > > There is no uploader at this moment, it is required in this case I > > think. > > > > Debian Policy Manual, Release 4.6.2.0 > > 3.3 The maintainer of a package > > > > If the maintainer of the package is a team of people with a shared > > email > > address, the Uploaders control field must be > > present and must contain at least one human with their personal > > email address. > > There was no upload that removed me from Uploaders. > The next upload should be a QA upload that also sets the Maintainer > field to the usual QA value. OK, so I guess I did better not make this bugreport. Then I guess this bug report can be closed? Is it possible that I close the bug by just sending an empty message to 1052559-d...@bugs.debian.org
Bug#1052559: No uploader
Source: zlmdb Version: 22.6.1-3 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, I think this counts also in this case? There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052558: wxutils: No uploader
Source: wxutils Version: 0.2.7-1 Severity: important X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, There is no uploader at this moment, it is required in this case I think. Debian Policy Manual, Release 4.6.2.0 3.3 The maintainer of a package If the maintainer of the package is a team of people with a shared email address, the Uploaders control field must be present and must contain at least one human with their personal email address. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052472: linux-image-6.5.0-1-powerpc64: Can't run program if its executable file was made immutable via chattr(1)
Control: reassign -1 src:zfs-linux
On Fri, 2023-09-22 at 16:13 +, WHR wrote:
> Package: src:linux
> Version: 6.5.3-1
> Severity: normal
> X-Debbugs-Cc: msl023...@gmail.com, msl023...@gmail.com
>
>
> Taking executable file /usr/bin/ssh to demonstrate the issue:
>
> # which ssh
> /usr/bin/ssh
> # ssh
>
> usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
> [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
> [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
> [-i identity_file] [-J [user@]host[:port]] [-L address]
> [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p
> port]
> [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
> [-w local_tun[:remote_tun]] destination [command]
> # chattr +i /usr/bin/ssh
>
> # ssh
> Segmentation fault
>
>
> By trying to load the program via ld.so(1) with truss (actually strace), it
> shows that a mmap(2) call used to load the data segument failed due to EPERM:
>
> # truss -s 128 -f /lib/powerpc64-linux-gnu/ld64.so.1 /usr/bin/ssh
> execve("/lib/powerpc64-linux-gnu/ld64.so.1",
> ["/lib/powerpc64-linux-gnu/ld64.so.1", "/usr/bin/ssh"], 0x7fffc0380530 /* 29
> vars */) = 0
> brk(NULL) = 0x1000db6
> openat(AT_FDCWD, "/usr/bin/ssh", O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\22h\220\0\0\0\0\0\0\0@\0\0\0\0\0\22\4\330\0\0\0\1\0@\08\0\t\0@\0\35\0\34\0\0\0\6\0\0\0\4\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\1\370\0\0\0\0\0\0\1\370\0\0\0\0\0\0\0\10\0\0\0\3\0\0\0\4"...,
> 832) = 832
> mmap(NULL, 1259760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7fff9372
> mprotect(0x7fff9383, 65536, PROT_NONE) = 0
> mmap(0x7fff9384, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) = -1 EPERM (Operation not
> permitted)
> close(3)= 0
> writev(2, [{iov_base="/usr/bin/ssh", iov_len=12}, {iov_base=": ",
> iov_len=2}, {iov_base="error while loading shared libraries", iov_len=36},
> {iov_base=": ", iov_len=2}, {iov_base="/usr/bin/ssh", iov_len=12},
> {iov_base=": ", iov_len=2}, {iov_base="failed to map segment from shared
> object", iov_len=40}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0},
> {iov_base="\n", iov_len=1}], 10/usr/bin/ssh: error while loading shared
> libraries: /usr/bin/ssh: failed to map segment from shared object
> ) = 107
> exit_group(127) = ?
> +++ exited with 127 +++
>
>
> I can also reproduce this issue on Bullseye (with Linux 5.10.0-21-amd64);
> while Buster (Linux 4.19.0-23-amd64) is fine.
[...]
> ** Command line:
> root=ZFS=zr/ROOT/debiansid-be ro quiet
> cgroup_enable=cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,perf_event,net_prio
> systemd.unified_cgroup_hierarchy=0
> net.ifname-policy=keep,onboard,slot,path,kernel zfs.zfs_txg_timeout=60
> zfs.zfs_arc_max=2166172771 init=/init
[...]
I can't reproduce this on an ext4 filesystem, so I think ZFS is the
problem.
ZFS has its own check that blocks a writable mmap of an immutable file,
without taking MAP_PRIVATE into account:
https://sources.debian.org/src/zfs-linux/2.1.12-2/module/os/linux/zfs/zfs_vnops_os.c/#L3908
Ben.
--
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.
signature.asc
Description: This is a digitally signed message part
Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: [...] > ## Kernel modules will be signed with an ephemeral key > > The modules will not longer be signed using the Secure Boot CA like the > EFI kernel image itself. Instead a key will be created during the build > and thrown away after. > > Yes, this will make the build unreproducible, but no better solution > currently exists. There are some plans, but no-one is working on them. > If a suitable replacement shows up, we can always switch to that > solution. Builds for the architectures involved are already unreproducible due to inconsistent generation of BTF in both the kernel and modules. Additionally, my "plan" would also get rid of signing modules with the Secure Boot CA, so I'm not going to object to this. [...] > ## Image packages contains more version info > > By renaming the kernel packages we try to make several kernels > installable at the same time. In contrast to rpm, where you can have > the same package installed multiple times in different versions, dpkg > only supports a single one at the same time. So the co-installable > versions needs to have different package names. > > The packages will include the full upstream version. There exists the > exception of devel builds and uploads to experimental, wich will contain > even less of the version, to avoid new names in that cases. > > Example: linux-image-6.5.3-cloud-arm64 > > There are some drawbacks. > > The same upstream version in testing and backports will have the same > package name. This is not OK, because they will be incompatible on architectures supporting SB (and sometimes incompatible on others due to compiler differences or required config changes). If someone upgrades from stable + backports to testing, and has OOT modules: - With DKMS, will a rebuild be triggered if the linux-image package name doesn't change? - With module-assistant, the new linux-image package will satisfy dependencies of the old modules even though they are incompatible. > Multiple uploads of the same upstream version will have > the same package name, but those rarely happens. Those happen fairly often for urgent security updates. > Those packages will > not be compatible and a reboot is necessary to be able to load modules > again. > > It will not longer be possible to reliably derive the package name from > kernel release (see above), as both values are not really related > anymore. Given all the drawbacks, I don't see the benefit of decoupling package names from release strings. In the same way that shared library packages must be renamed for every backward-incompatible ABI changes, I believe we should keep doing this for linux-image packages. > ## Header and tool packages will not longer contain version > > The headers packages will not longer include the version. It won't be > reliably possible to derive the package name anyway from the running > kernel. > > This means that only headers of one single version can be available on > the system at one time. This might be a bit inconvinient for dkms, as > it can't longer build modules for multiple versions. > > But we too often have the problem that image and headers go out of sync > and then you can't find the correct ones anyway. > > Example: linux-headers-cloud-arm64 This is all downside with no justification given. Please explain what the benefit is. > ## Installer packages will not longer contain too much version > > The installer can only ever handle one version of kernel. Also it got > an internal mechanism to detect which packages belong together > (the Kernel-Version control entry). So we have no need to rename them > and force a matching change in d-i itself just because a new kernel > exists. So it will not longer contain the full version in the package > names if not needed. [...] In the installer, netboot images break every time the kernel ABI is bumped. I think there's a specific check and error message for this, but I'm not exactly sure. It should be verified that this detection will work the way you expect, so that the error message doesn't change and create a support burden for the installer team. Currently kernel-wedge generates the udeb package names and would need to add an option to leave out the version part of the names. I'm happy to work on that once we have an agreement for what to do. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#1052524: postgresql-16: Ow that hurts! On the short description.
Package: postgresql-16 Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Is it really not The World's Most Advanced Relational Database? Please, do not tell me it is true, it hurts me so badly. Please change the short description to a friendlier one. (while you're doing, please also remove free and open-source (sounds pretty dumb while you're in main) from the long description? Else I have to make a separate bug report for that) -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052400: php-zumba-json-serializer: correction to short description
Package: php-zumba-json-serializer Followup-For: Bug #1052400 X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Thank you for acting and asking me. I'm not really the person you should ask. I think it's good with "library". The short description contained basically a repeating of the package name. I should have put some references in that bug report: policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-zumba-json-serializer depends on: ii php-common 2:93 ii php-mbstring2:8.2+93 ii php8.2-mbstring [php-mbstring] 8.2.7-1~deb12u1 php-zumba-json-serializer recommends no packages. php-zumba-json-serializer suggests no packages.
Bug#1052520: librust-tiny-skia-dev: What is?! Please be more informative on short and long description
Package: librust-tiny-skia-dev Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, short synopsis and extended description It's something, effectively nothing. Reference Debian Policy Manual (Release 4.6.2.0) 3.4 The description of a package Debian Developer’s Reference (Release 13.3) 6.2.2 The package synopsis, or short description 6.2.3 The long description -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 librust-tiny-skia-dev depends on: pn librust-arrayref-0.3+default-dev pn librust-arrayvec-0.7-dev pn librust-bytemuck-1+aarch64-simd-dev pn librust-bytemuck-1+default-dev pn librust-cfg-if-1+default-dev pn librust-png-0.17+default-dev pn librust-tiny-skia-path-0.8+no-std-float-dev pn librust-tiny-skia-path-0.8+std-dev pn librust-tiny-skia-path-0.8-dev librust-tiny-skia-dev recommends no packages. librust-tiny-skia-dev suggests no packages.
Bug#1052504: librust-password-hash-dev: too long short description (one of many Rust packages)
Package: librust-password-hash-dev Followup-For: Bug #1052504 X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, also The single line synopsis should be kept brief—certainly under 80 characters. reference: Debian Policy Manual 4.6.2.0 - 3.4.1 -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 librust-password-hash-dev depends on: pn librust-base64ct-1+alloc-dev pn librust-base64ct-1+default-dev pn librust-base64ct-1+std-dev pn librust-rand-core-0.6+std-dev pn librust-rand-core-0.6-dev pn librust-subtle-2-dev librust-password-hash-dev recommends no packages. librust-password-hash-dev suggests no packages.
Bug#1052504: librust-password-hash-dev: too long short description (one of many Rust packages)
Package: librust-password-hash-dev Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, The short description should be kept short (50 characters or so) reference: developers reference 13.3 - 6.6.3.2 -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 librust-password-hash-dev depends on: pn librust-base64ct-1+alloc-dev pn librust-base64ct-1+default-dev pn librust-base64ct-1+std-dev pn librust-rand-core-0.6+std-dev pn librust-rand-core-0.6-dev pn librust-subtle-2-dev librust-password-hash-dev recommends no packages. librust-password-hash-dev suggests no packages.
Bug#1052413: pyequihash: should maintainer/uploader be turned?
Source: pyequihash Version: 0.2-2 Followup-For: Bug #1052413 X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, sorry for this mistake. This bug can be closed. (don't know how I could do that with nnn-d...@bugs.debian.org or nnn-close) (I'm using reportbug) -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052410: psycopg3: should maintainer/uploader be turned?
Source: psycopg3 Version: 3.1.7-4 Followup-For: Bug #1052410 X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, sorry for this mistake. This bug can be closed. (don't know how I could do that with nnn-d...@bugs.debian.org or nnn-close) (I'm using reportbug) -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052442: python3-airspeed: correction to the short description
Package: python3-airspeed Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, On the short description. Please, Do not include the package name. Do not include "a". Please change: Python Airspeed - a Python template engine To: Python template engine Reference Debian policy 3.4.1 The single line synopsis developers reference 6.2.2 The package synopsis, or short description -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-airspeed depends on: ii python3 3.11.2-1+b1 pn python3-cachetools ii python3-six 1.16.0-4 python3-airspeed recommends no packages. python3-airspeed suggests no packages.
Bug#1052386: opentracker: correction to the short description
Package: opentracker Followup-For: Bug #1052386 X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, In turn of my earlier message, in this case the term "open" I guess has another meaning. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 opentracker depends on: ii libc6 2.36-9+deb12u1 pn libowfat0 ii zlib1g 1:1.2.13.dfsg-1 opentracker recommends no packages. opentracker suggests no packages.
Bug#1052386: opentracker: correction to the short description
Package: opentracker Followup-For: Bug #1052386 X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, I hope you understand the reason of this package being in main? Please change the short title to?: BitTorrent tracker The rest of the short title is useless. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 opentracker depends on: ii libc6 2.36-9+deb12u1 pn libowfat0 ii zlib1g 1:1.2.13.dfsg-1 opentracker recommends no packages. opentracker suggests no packages.
Bug#1052413: pyequihash: should maintainer/uploader be turned?
Source: pyequihash Version: 0.2-2 Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Normally the Debian Python Team would be maintainer. Then Joost van Baal-Ilić would be under uploaders. Now it's opposite. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052412: pymdown-extensions: should maintainer/uploader be turned?
Source: pymdown-extensions Version: 9.5-2 Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Normally the Debian Python Team would be maintainer. Then Sandro Tosi would be under uploaders. Now it's opposite. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052410: psycopg3: should maintainer/uploader be turned?
Source: psycopg3 Version: 3.1.7-4 Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Normally the Debian Python Team would be maintainer. Then Tomasz Rybak would be under uploaders. Now it's opposite. -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052401: plasma-mobile: correction to short description
Package: plasma-mobile Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Open-source user interface for phones, based on Plasma technologies To: user interface for phones, based on Plasma technologies -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 plasma-mobile depends on: ii bluedevil 4:5.27.5-2 ii breeze-icon-theme 4:5.103.0-1 pn fonts-mplus pn fonts-oxygen ii kio 5.103.0-1 ii kpackagetool5 5.103.0-1 ii kpeople-vcard 0.1-3 ii libc6 2.36-9+deb12u1 ii libkf5configcore5 5.103.0-2 ii libkf5configgui55.103.0-2 ii libkf5configwidgets55.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiogui5 5.103.0-1 ii libkf5kiowidgets5 5.103.0-1 ii libkf5modemmanagerqt6 5.103.0-1 ii libkf5networkmanagerqt6 5.103.0-1 ii libkf5notifications55.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5plasma5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libkf5service-bin 5.103.0-1 ii libkf5service5 5.103.0-1 ii libkf5waylandclient54:5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkworkspace5-54:5.27.5-2 ii libqt5core5a5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick55.15.8+dfsg-3 ii libqt5widgets5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 pn maliit-keyboard ii milou 4:5.27.5-2 ii pipewire0.3.65-3 pn plasma-nano ii plasma-nm 4:5.27.5-2 ii plasma-pa 4:5.27.5-2 pn plasma-settings ii plasma-workspace4:5.27.5-2 ii plasma-workspace-wayland4:5.27.5-2 ii powerdevil 4:5.27.5-2 ii qml-module-org-kde-activities 5.103.0-1 ii qml-module-org-kde-bluezqt 5.103.0-1 ii qml-module-org-kde-kio 5.103.0-1 pn qml-module-org-kde-kirigami-addons-labs-mobileform ii qml-module-org-kde-kirigami25.103.0-1 ii qml-module-org-kde-kquickcontrols 5.103.0-1 ii qml-module-org-kde-people 5.103.0-1 ii qml-module-org-kde-pipewire 5.27.5-3 pn qml-module-org-kde-qqc2breezestyle pn qml-module-qtfeedback pn qml-module-qtquick-localstorage ii xdg-desktop-portal-kde 5.27.5-2 Versions of packages plasma-mobile recommends: pn kde-config-mobile-networking pn plasma-mobile-tweaks plasma-mobile suggests no packages.
Bug#1052400: php-zumba-json-serializer: correction to short description
Package: php-zumba-json-serializer Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Json Serializer is a PHP library to serialize PHP variables in JSON format To?: serialize PHP variables in JSON format -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-zumba-json-serializer depends on: ii php-common 2:93 ii php-mbstring2:8.2+93 ii php8.2-mbstring [php-mbstring] 8.2.7-1~deb12u1 php-zumba-json-serializer recommends no packages. php-zumba-json-serializer suggests no packages.
Bug#1052399: php-voku-portable-ascii: correction to short description
Package: php-voku-portable-ascii Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Portable ASCII library - performance optimized (ascii) string functions for To?: portable performance optimized ASCII string functions -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-voku-portable-ascii depends on: ii php-common 2:93 php-voku-portable-ascii recommends no packages. Versions of packages php-voku-portable-ascii suggests: pn php-intl
Bug#1052396: php-ramsey-collection: small correction to short description
Package: php-ramsey-collection Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: A PHP library for representing and manipulating collections To: PHP library for representing and manipulating collections -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-ramsey-collection depends on: ii php-common 2:93 php-ramsey-collection recommends no packages. php-ramsey-collection suggests no packages.
Bug#1052395: php-laravel-serializable-closure: correction to short description
Package: php-laravel-serializable-closure Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Laravel Serializable Closure provides an easy and secure way to serialize To: easy and secure way to serialize closures -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-laravel-serializable-closure depends on: ii php-common 2:93 php-laravel-serializable-closure recommends no packages. php-laravel-serializable-closure suggests no packages.
Bug#1052394: php-graham-campbell-result-type: correction to short description
Package: php-graham-campbell-result-type Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: An Implementation Of The Result Type To: implementation of the result type -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-graham-campbell-result-type depends on: ii php-common 2:93 pn php-phpoption php-graham-campbell-result-type recommends no packages. php-graham-campbell-result-type suggests no packages.
Bug#1052393: php-faker: correction to small description
Package: php-faker Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Faker is a PHP library that generates fake data for you To: PHP library that generates fake data for you Or better: PHP library that generates fake data -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 php-faker depends on: ii php-common 2:93 pn php-psr-container pn php-symfony-deprecation-contracts php-faker recommends no packages. Versions of packages php-faker suggests: pn php-curl pn php-doctrine-orm ii php-mbstring2:8.2+93 pn php-xml ii php8.2-mbstring [php-mbstring] 8.2.7-1~deb12u1
Bug#1052390: orsopy: small correction to the short description
Package: orsopy Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Support library of the Open Reflectometry Standards Organiza To: support library of the Open Reflectometry Standards Organization -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052386: opentracker: correction to the short description
Source: opentracker Version: 0.0~git20210823.110868e-3 Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: Open and free bittorrent tracker To: bittorrent tracker Or: BitTorrent tracker -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052373: node-mj-context-menu: small correction on short description
Package: node-mj-context-menu Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: eimplementation of MathJax context menu in TypeScript To: reimplementation of MathJax context menu in TypeScript -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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#1052370: mrbuild: small correction to the short title
Package: mrbuild Severity: minor X-Debbugs-Cc: benatt...@gezapig.nl Dear Maintainer, Please change: A simple build system To: simple build system -- 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-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 mrbuild depends on: ii perl 5.36.0-7 mrbuild recommends no packages. mrbuild suggests no packages.
