Bug#1084776: Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.
Package: rsyslog Version: 8.2408.0-2 Upon upgrade I see: Setting up rsyslog (8.2408.0-2) ... Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.
Bug#1083295: Add a Unicode::GCString package to Debian
Package: perltidy man perltidy says: -gcs, --use-unicode-gcstring ...Perltidy installation does not require Unicode::GCString, so users wanting to use this feature need set this flag and also to install Unicode::GCString separately. So perhaps Debian could have, and Recommend or Suggest, such a package.
Bug#1083059: hfsplus: FTBFS with gcc-14
Package: hfsplus
Version: 1.0.4-17.1ubuntu1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: daniel.bung...@canonical.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular
Dear Maintainer,
This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/2083086
hfsplus is FTBFS with gcc-14 on presumably all BIG_ENDIAN arches.
https://launchpadlibrarian.net/749243763/buildlog_ubuntu-oracular-s390x.hfsplus_1.0.4-17.1build1_BUILDING.txt.gz
I have only observed this on s390x on Ubuntu and assume it would also apply to
Debian.
In file included from partitions.c:29:
partitions.c: In function ‘partition_fillstruct’:
swab.h:51:51: error: assignment to ‘char *’ from incompatible pointer type
‘UInt16 *’ {aka ‘short unsigned int *’} [-Wincompatible-pointer-types]
51 | #define bswabU16_inc(ptr) *((UInt16*) (ptr)); ptr = (UInt16*)ptr + 1
| ^
partitions.c:59:23: note: in expansion of macro ‘bswabU16_inc’
59 | p->pmSig = bswabU16_inc( buf);
| ^~~~
this continues for all the bswabUXX_inc in partition_fillstruct.
I addressed this for Ubuntu (mostly) as follows:
--- a/libhfsp/src/swab.h
+++ b/libhfsp/src/swab.h
@@ -48,25 +48,25 @@
#define bswabU16(val) val
-#define bswabU16_inc(ptr) *((UInt16*) (ptr)); ptr = (UInt16*)ptr + 1
+#define bswabU16_inc(ptr) *((UInt16*) (ptr)); ptr = (void *)((UInt16*)ptr + 1)
/* Only available as a GCC extension, but required on sparc due to
alignment issues in some of the on-disk structs */
#if defined(__GNUC__) && defined(__sparc__)
#define bswabU32_inc(ptr) ({ \
unsigned char *c = (char*)ptr; \
- ptr = ((UInt32 *)ptr) + 1; \
+ ptr = (void *)(((UInt32 *)ptr) + 1);\
((c[0] << 24)+(c[1] << 16)+(c[2] << 8)+c[3]);})
#define bswabU64_inc(ptr) ({ \
unsigned char *c = (char*)ptr; \
UInt64 val = 0; \
int i = 0; \
- ptr = ((UInt64 *)ptr) + 1; \
+ ptr = (void *)(((UInt64 *)ptr) + 1);\
while (i < 8) \
val += (c[i] << (8*(7-i++))); \
val;})
#else
-#define bswabU32_inc(ptr) *((UInt32*) (ptr)); ptr = (UInt32*)ptr + 1
-#define bswabU64_inc(ptr) *((UInt64*) (ptr)); ptr = (UInt64*)ptr + 1
+#define bswabU32_inc(ptr) *((UInt32*) (ptr)); ptr = (void *)((UInt32*)ptr + 1)
+#define bswabU64_inc(ptr) *((UInt64*) (ptr)); ptr = (void *)((UInt64*)ptr + 1)
#endif
#define bstoreU16_inc(ptr, val) *((UInt16*) (ptr)) = val; ptr =
(void*)((UInt16*)ptr + 1)
The Ubuntu version I uploaded is different because of a flaw on the
defined(__sparc__) path that Ubuntu won't use, I expect the above is corret.
-Dan
Bug#1003046: openssh-client-ssh1: use /etc/ssh/ssh1_config as default config file
Package: openssh-client-ssh1 Version: 1:7.5p1-17 Followup-For: Bug #1003046 Dear Maintainer, This has become more important with the removal of old protocols from upstream openssh. This package attempts to read a configuration file meant for openssh-client, and errors out. I'm maintaining a parallel version that looks in /etc/ssh1 and ~/.ssh1 to stop the two from conflicting since installing ssh1 is now mandatory to access older hardware. As the two continue to diverge the incompatibility will only grow. -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.9+ (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages openssh-client-ssh1 depends on: ii libc62.40-2 ii libselinux1 3.7-3 ii libssl3t64 3.3.2-1 ii zlib1g 1:1.3.dfsg+really1.3.1-1 openssh-client-ssh1 recommends no packages. openssh-client-ssh1 suggests no packages. -- no debconf information
Bug#1082504: Say what the very long lines count refers to
Package: file Version: 1:5.45-3 Severity: minor $ file sp* spam.2434.eml: SMTP mail, ASCII text spam.2444.eml: SMTP mail, ASCII text spam.2454.eml: SMTP mail, ASCII text, with very long lines (327) spam.24583.eml: SMTP mail, ASCII text spam.24595.eml: SMTP mail, ISO-8859 text, with very long lines (1861) The man page should mention if 1861 refers to A. That there are 1861 long lines in the file, or B. that the longest line is 1861 octets long. (Answer: B) I tried to report it upstream, but it turned out to be a big hassle. Also mention what the definition of a long line is, and if it can be modified from the command line.
Bug#1082501: SyntaxWarning: invalid escape sequence '\?'
Package: py3status
Version: 3.59-1
Setting up py3status (3.59-1) ...
/usr/lib/python3/dist-packages/py3status/modules/bluetooth.py:103:
SyntaxWarning: invalid escape sequence '\?'
format_device = "\?if=connected&color=connected {alias}"
/usr/lib/python3/dist-packages/py3status/modules/sway_idle.py:1: SyntaxWarning:
invalid escape sequence '\?'
"""
/usr/lib/python3/dist-packages/py3status/modules/weather_owm.py:898:
SyntaxWarning: invalid escape sequence '\?'
separator = "[\?color={c}&show / ]".format(c=color)
/usr/lib/python3/dist-packages/py3status/modules/weather_owm.py:899:
SyntaxWarning: invalid escape sequence '\?'
body = "[\?color={c}&show {n}] [\?color={n} {{{n}}}]"
/usr/lib/python3/dist-packages/py3status/modules/weather_owm.py:914:
SyntaxWarning: invalid escape sequence '\?'
"format_forecast_separator": "\?color=tomato separator ",
/usr/lib/python3/dist-packages/py3status/modules/zypper_updates.py:1:
SyntaxWarning: invalid escape sequence '\?'
"""
/usr/lib/python3/dist-packages/py3status/modules/zypper_updates.py:34:
SyntaxWarning: invalid escape sequence '\?'
format = "zypper: [\?color=update {update}]"
Bug#1080431: man page wrong formatting
Package: wlr-randr The man page is formatted wrong. $ man wlr-randr | head -n 1 | tr -s ' ' USAGE:(1) User Commands USAGE:(1) That should look like: $ man cat | head -n 1 | tr -s ' ' CAT(1) User Commands CAT(1)
Bug#1079163: Update to mirrors.iu13.net
- added armhf as well - added cd images in /debian-cd
Bug#1077238: Upgrade will break networking, thus unable to download missing packages
Yes. The news item needs to warn: ** Warning: if you take no action, upon the next boot you might 1. Not be able to network. 2. Not be able to see your screen. 3. Not be able to boot. and thus unable to install the new packages to fix it too. Therefore be sure to install the new packages ... now, unless you are sure you know what you are doing.
Bug#1077238: Upgrade will break networking, thus unable to download missing packages
Package: firmware-misc-nonfree Version: 20240709-1 > Several firmware files were moved from firmware-misc-nonfree into > their own package Are you sure that won't break networking for some people? Best to have a transitional package that pulls in the rest, and leave it up to the user to remove the ones they don't want. Else the upon next boot, they can no longer connect. And thus cannot download the missing packages. And must get help from a third party.
Bug#809630: Sent to upstream
OK. Made https://github.com/OSGeo/PROJ/pull/4209
Bug#1077090: unmet dependencies
Package: polkitd-pkla Seen on sid aarch64 The following packages have unmet dependencies: polkitd-pkla : Depends: libpolkit-gobject-1-0 (= 124-2) but 124-3 is to be installed
Bug#1077089: Duplicate line for path "/run/lock"
Package: systemd Version: 256.4-2 Setting up systemd (256.4-2) ... /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
Bug#1075721: octave-dicom: use-after-free with dicomdict
Source: octave-dicom
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
I wanted to forward along a fix I have done for Ubuntu for octave-dicom.
Ubuntu builds of octave-dicom were FTBFS on the built-in testsuite with
use-after-free / segfault type issues. I have not reproduced this build
failure on Sid, but memory corruption issues are treacherous and might show up
later.
If desired, more details can be found at
https://bugs.launchpad.net/ubuntu/+source/octave-dicom/+bug/2069660 ,
but the summary is that I have moved the std::maps used by dicomdict to static
storage to address this. I believe that the destructors are getting confused
with the multiple copies of dicomdict, due to the functionality being built
into several plugins and plugins being loaded by octave with RTLD_GLOBAL.
The patch passes the built-in testsuite, along with my attempts to confuse the
dict information loaded with specific plugin ordering.
Please see attached. Also, the upstream bug tracker at
https://octave.space/savannah/?Action=get&Format=HTMLCSS&Title=[octave%20forge]%20(dicom)
seems to be down, so if you have information about how best to reach upstream,
I'd appreciate it.
-Dan
P.S. - this is my second attempt at forwarding this, so if you see a duplicate
assume mailserver weirdness and just close it.
Description: fix use-after-free due to symbol collisions across plugins
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2069660
Forwarded: no
Last-Update: 2024-06-28
Move these symbols to static, which helps shield them from strange cleanup
ordering of the maps that can result in use-after-free due to the map
destructors performing an overwriting clear and that the symbols are referenced
from multiple plugins.
--- a/src/dicomdict.cpp
+++ b/src/dicomdict.cpp
@@ -51,9 +51,9 @@
const char * factory_dicom_dict_filename="octavedicom.dic";
static std::string dic_filename(factory_dicom_dict_filename);
-std::map tagmap ;
-std::map keymap ;
-std::map dict ;
+static std::map tagmap ;
+static std::map keymap ;
+static std::map dict ;
void insert(const char *k, const gdcm::Tag t, const gdcm::DictEntry e)
{
Bug#1074505: dpkg: warning: while removing linux-image-6.8.11-amd64, directory '/lib/modules/6.8.11-amd64' not empty so not removed
Package: linux-image-amd64 dpkg: warning: while removing linux-image-6.8.11-amd64, directory '/lib/modules/6.8.11-amd64' not empty so not removed # ls -l /lib/modules/6.8.11-amd64 total 4 -rw-r--r-- 1 root root 55 05-27 14:48 modules.weakdep
Bug#1074262: fix typo in error message
Package: logcheck Version: 1.4.3 The pathname in an error message is incorrect: /etc/logcheck/logcheck.logfiled.d/*.logfiles That should be: /etc/logcheck/logcheck.logfiles.d/*.logfiles i.e. logfiled should be logfiles A merge request has been created: https://salsa.debian.org/debian/logcheck/-/merge_requests/22 -- Dan Langille d...@langille.org
Bug#1074176: packages.debian.org: allow seeing files
Thanks. But: The older page needs to mention the newer page, else people who end up on the older page will think that that is all they are allowed to see. In fact the older page should use the links from the newer page, to make its flat list clickable. Also both pages don't have any file dates. That is mainly why the reader came there, to see how old the files are. Sure, there is a VERSION file, but no date on it either. Anyway: so the entire website needs to use ls -og to show the dates. Yes, "dates aren't reliable", but no dates are worse. On Mon, Jun 24, 2024 at 09:47:15AM -0700, Soren Stoutner wrote: > You are probably looking for this URL: > https://sources.debian.org/src/gdal/3.9.1~rc2%2Bdfsg-1~exp1/
Bug#1074176: packages.debian.org: allow seeing files
Package: general Here we are looking at a list of files, https://packages.debian.org/experimental/amd64/gdal-bin/filelist but cannot click them to see their contents.
Bug#1073122: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
Package: systemd Version: 256-1 Severity: minor File: /usr/lib/tmpfiles.d/legacy.conf We see /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.
Bug#1072155: Wrong NEWS.Debian item
Package: systemd Version: 256~rc3-5 File: /usr/share/doc/systemd/NEWS.Debian.gz > - On new installations, tmpfiles.d will now cleanup by default /tmp/ every >10 days, and /var/tmp/ every 30 days. That note needs to be changed to > - On new installations, tmpfiles.d will now cleanup by default files >that have not been changed on /tmp/ for 10 days, and /var/tmp/ for 30 days. Big difference.
Bug#1071669: Document that Dl-Limit=9M is actually the same as 9K
Package: apt Version: 2.9.3 Severity: minor apt-transport-http apt-transport-https both say The used bandwidth can be limited with Acquire::http::Dl-Limit which accepts integer values in kilobytes per second. Well many people use e.g., Dl-Limit=20K and no error is caused. That's very unfortunate. As it gives the false impression that Dl-Limit=20M will be 1000 times faster than Dl-Limit=20K, but the sad truth is they both simply just mean Dl-Limit=20 ! Therefore those man pages (and anywhere else Dl-Limit is mentioned) should say that such letters are ignored. Indeed if you started all over again, you should have 1. Respected the letters. Or, 2. Raised an error on encountering the letters. But in the interest of not breaking scripts, at least you can now 3. Document that the letters are actually ignored! Thanks.
Bug#1071668: Add Acquire::Total::Dl-Limit
Package: apt Version: 2.9.3 Severity: wishlist apt-transport-http apt-transport-https both say The used bandwidth can be limited with Acquire::http::Dl-Limit which accepts integer values in kilobytes per second. The default value is 0 which deactivates the limit and tries to use all available bandwidth. Note that this option implicitly disables downloading from multiple servers at the same time. That's great. Except when there is a mixture of http and https sources. (Probably not considered back when there was only http.) Then to achieve a Dl-Limit=8 we need to do e.g., -o Acquire::http::Dl-Limit=4 \ -o Acquire::https::Dl-Limit=4 That indeed never goes past 8 so we are happy. But lets say after a few minutes the http source is now already fetched, well the https source is still limited at 4 even though it would be fine if it became 8. Therefore there needs to be a -o Acquire::Total::Dl-Limit=8 Also the "implicitly disables downloading from multiple servers at the same time" shouldn't apply to the new Acquire::Total::Dl-Limit. Or at least allow overriding. Also it would be a good idea to allow overriding "implicitly disables..." for http and https too.
Bug#1071652: As a matter of fact
As a matter of fact, the solution I posted doesn't work either. Therefore, be sure on the man page, to mention the true sequence needed: # debootstrap (missing step goes here) # debootstrap --second-stage
Bug#1053905: Docs out of step
$ apt-show-versions -r emacs emacs:all/bookworm-backports 1:29.3+1-3~bpo12+1 uptodate emacs-bin-common:arm64/bookworm-backports 1:29.3+1-3~bpo12+1 uptodate emacs-common:all/bookworm-backports 1:29.3+1-3~bpo12+1 uptodate emacs-common-non-dfsg:all/stable 1:28.2+1-2 uptodate 28! emacs-el:all/bookworm-backports 1:29.3+1-3~bpo12+1 uptodate emacs-pgtk:arm64/bookworm-backports 1:29.3+1-3~bpo12+1 uptodate emacsen-common:all/stable 3.0.5 uptodate https://unix.stackexchange.com/questions/758800/getting-emacs-common-non-dfsg-from-debian-bookworm-backports
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
> If I find time I'll have a look at this (probably just by looking > through GRUB 2 for candidate backports and hoping that one of them > helps). However, I should warn you that GRUB Legacy is extremely very > unmaintained at this point; I've really just been doing last-resort > patching for years, and this normally hasn't included debugging its > filesystem code. It'd be in your interests to migrate to GRUB 2. Thanks for your response - I hadn't quite noticed that this was legacy grub (and had kinda made the assumption the Debian upgrades had forced the upgrade). I have migrated to GRUB 2 and can confirm this resolves the issue. cheers, Dan The Networking People (TNP) Limited. Registered office: Network House, Caton Rd, Lancaster, LA1 3PE. Registered in England & Wales with company number: 07667393 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
Package: src:linux Version: 5.10.216-1 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrading to linux-image-5.10.0-29 the system fails to boot with grub 'Error 16: Inconsistent filesystem structure'. Booting into linux-image-5.10.0-28-amd64 and the system is once again bootable The console displays: Booting 'Debian GNU/Linux, kernel 5.10.0-29-amd64' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-5.10.0-29-amd64 root=UUID=ca38e015-f8d1-4ef0-9dc9-b56d7c8 le0f1 ro [Linux-bzImage, setup=0x3c00, size=0x6b5f40] Initrd /boot/initrd. img-5.10.0-29-amd64 Error 16: Inconsistent filesystem structure Press any key to continue...- -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: QEMU product_name: Standard PC (i440FX + PIIX, 1996) product_version: pc-i440fx-8.1 chassis_vendor: QEMU chassis_version: pc-i440fx-8.1 bios_vendor: SeaBIOS bios_version: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:05.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio SCSI [1af4:1004] Subsystem: Red Hat, Inc. Virtio SCSI [1af4:0008] Physical Slot: 5 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:12.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] Subsystem: Red Hat, Inc. Virtio network device [1af4:0001] Physical Slot: 18 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:13.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] Subsystem: Red Hat, Inc. Virtio network device [1af4:0001] Physical Slot: 19 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:1e.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: 00:1f.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: ** USB devices: not available -- System Information: Debian Release: 11.9 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/6 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.10.0-29-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.140 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-29-amd64 recommends: ii apparmor 2.13.6-10 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-29-amd64 suggests: pn debian-kernel-handbook pn grub-pc | grub-efi-amd64 | extlinux pn linux-doc-5.10 Versions of packages linux-image-5.10.0-29-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn f
Bug#1070356: Ydotool out of date
Package: ydotool Version: 0.1.8-3 As per https://github.com/ReimuNotMoe/ydotool/issues/233#issuecomment-2094063802 Debian ydotool is five years old.
Bug#1070347: GitHub not mentioned in documentation directory
Package: bash-completion Version: 1:2.11-8 In https://github.com/scop/bash-completion/issues/1175 we see GitHub is missing from Debian's bash-completion docs.
Bug#1070074: workaround: exec bash
Temporary workaround: $ exec bash
Bug#1021169: libglx-mesa0: Still present in 24.1.0~rc1-1
Package: libglx-mesa0
Version: 24.1.0~rc1-1
Followup-For: Bug #1021169
Dear Maintainer,
I'm still seeing this invalid path in the binary:
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri
and when attempting to load libglx_mesa0 I get the following error:
MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: cannot open
shared object file: No such file or directory (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
strace confirms that it is searching in nonsense paths:
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/radeonsi_dri.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\\$/lib/x86_64-linux-gnu/dri/radeonsi_dri.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'),
(500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.10 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default
Versions of packages libglx-mesa0 depends on:
ii libc62.37-18
ii libdrm2 2.4.120-2
ii libexpat12.6.2-1
ii libgl1-mesa-dri 24.1.0~rc1-1
ii libglapi-mesa24.1.0~rc1-1
ii libx11-6 2:1.8.7-1+b1
ii libx11-xcb1 2:1.8.7-1+b1
ii libxcb-dri2-01.17.0-1
ii libxcb-dri3-01.17.0-1
ii libxcb-glx0 1.17.0-1
ii libxcb-present0 1.17.0-1
ii libxcb-randr01.17.0-1
ii libxcb-shm0 1.17.0-1
ii libxcb-sync1 1.17.0-1
ii libxcb-xfixes0 1.17.0-1
ii libxcb1 1.17.0-1
ii libxext6 2:1.3.4-1+b1
ii libxfixes3 1:6.0.0-2+b1
ii libxshmfence11.3-1+b1
ii libxxf86vm1 1:1.1.4-1+b2
libglx-mesa0 recommends no packages.
libglx-mesa0 suggests no packages.
Versions of packages xserver-xorg depends on:
ii x11-xkb-utils7.7+8+b1
ii xkb-data 2.41-2
ii xserver-xorg-core2:21.1.12-1
ii xserver-xorg-input-evdev [xorg-driver-input] 1:2.10.6-2+b3
ii xserver-xorg-input-kbd [xorg-driver-input] 1:1.9.0-1+b3
ii xserver-xorg-input-libinput [xorg-driver-input] 1.4.0-1
ii xserver-xorg-input-mouse [xorg-driver-input] 1:1.9.3-1+b1
ii xserver-xorg-video-amdgpu [xorg-driver-video]23.0.0-1
Versions of packages xserver-xorg recommends:
ii libgl1-mesa-dri 24.1.0~rc1-1
pn xserver-xorg-legacy
Versions of packages xserver-xorg-core depends on:
ii keyboard-configuration 1.226
ii libaudit1 1:3.1.2-2
ii libc6 2.37-18
ii libdbus-1-3 1.14.10-4+b1
ii libdrm2 2.4.120-2
ii libegl1 1.7.0-1+b1
ii libepoxy0 1.5.10-1+b2
ii libgbm1 24.1.0~rc1-1
ii libgcrypt20 1.10.3-2+b1
ii libgl1 1.7.0-1+b1
ii libpciaccess0 0.17-3+b1
ii libpixman-1-0 0.42.2-1+b1
ii libselinux1 3.5-2+b2
ii libsystemd0 255.5-1
ii libudev1255.5-1
ii libunwind8 1.6.2-3+b1
ii libxau6 1:1.0.9-1+b1
ii libxcvt00.1.2-1+b1
ii libxdmcp6 1:1.1.2-3+b1
ii libxfont2 1:2.0.6-1+b1
ii libxshmfence1 1.3-1+b1
ii udev255.5-1
ii xserver-common 2:21.1.12-1
Versions of packages xserver-xorg-core recommends:
ii libgl1-mesa-dri 24.1.0~rc1-1
ii libpam-systemd [logind] 255.5-1
ii xcvt 0.1.2-1+b1
Versions of packages xserver-xorg-core suggests:
ii xfonts-100dpi1:1.0.5
ii xfonts-75dpi 1:1.0.5
ii xfonts-scalable 1:1.0.3-1.3
-- no debconf information
Bug#1069812: Junk on bottom of emacsclient man page
Package: emacs-common Version: 1:29.3+1-2 Severity: minor File: /usr/share/man/man1/emacsclient.emacs.1.gz Please see image.
Bug#985031: 5.8
https://github.com/htacg/tidy-html5/releases/tag/5.8.0
Bug#1067690: (no subject)
Source: pygame-sdl2 Version: 8.1.3-1 Severity: normal Tags: ftbfs X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, pygame-sdl2 will FTBFS with the current incarnation of cython3. Switching to cython3-legacy produces a passing build. Confirmed building with this change on sid and Ubuntu noble. --- a/debian/control +++ b/debian/control @@ -6,7 +6,7 @@ Uploaders: Markus Koschany Build-Depends: - cython3, + cython3-legacy, debhelper-compat (= 13), dh-sequence-python3, libsdl2-dev, -Dan
Bug#1065725: adns: FTBFS on arm{el,hf}: FAILED ./case-1stservbroken - WRONG OUTPUT - lines of syscall remaining 0
Greetings!
I took a look at this bug today.
I found that the regress testsuite make use of some negative offsets, which
seem to perplex the reader on 32 bit systems.
Please see the attached patch, which has allowed this to build for Ubuntu.
-Dan
Author: Dan Bungert
Description: Fix reads of signed values into unsigned variables
Bug-Ubuntu: https://bugs.launchpad.net/bugs/2057735
Bug-Debian: https://bugs.debian.org/1065725
Forwarded: yes
Last-Update: 2024-03-14
The regress testsuite makes use of time offsets to mock the passage of time,
and some of the usec values are expressed as negative numbers. Update the
reader to be able to handle that.
--- a/regress/hplayback.c.m4
+++ b/regress/hplayback.c.m4
@@ -108,7 +108,8 @@
void Tensuresetup(void) {
int fd;
int chars;
- unsigned long sec, usec;
+ time_t sec;
+ suseconds_t usec;
Tensure_reportfile();
Tensure_fuzzrawfile();
@@ -124,7 +125,7 @@
if (!adns__vbuf_ensure(&vb2,1000)) Tnomem();
fgets(vb2.buf,vb2.avail,Tinputfile); Pcheckinput();
chars= -1;
- sscanf(vb2.buf," start %lu.%lu%n",&sec,&usec,&chars);
+ sscanf(vb2.buf," start %lld.%ld%n",&sec,&usec,&chars);
if (chars==-1) Psyntax("start time invalid");
currenttime.tv_sec= sec;
currenttime.tv_usec= usec;
@@ -170,12 +171,13 @@
static void P_updatetime(void) {
int chars;
- unsigned long sec, usec;
+ time_t sec;
+ suseconds_t usec;
if (!adns__vbuf_ensure(&vb2,1000)) Tnomem();
fgets(vb2.buf,vb2.avail,Tinputfile); Pcheckinput();
chars= -1;
- sscanf(vb2.buf," +%lu.%lu%n",&sec,&usec,&chars);
+ sscanf(vb2.buf," +%lld.%ld%n",&sec,&usec,&chars);
if (chars==-1) Psyntax("update time invalid");
currenttime.tv_sec+= sec;
currenttime.tv_usec+= usec;
Bug#1065593: units: Allow access to user's own input
X-Debbugs-Cc: adri...@gnu.org
Package: units
Version: 2.23-1
Severity: wishlist
It seems that a big lack of the units program, is access to the user's
own input after he inputs it.
Often one needs access to the original input value, and currently must
use workarounds.
$ for i in `seq 5`; do echo -n "$i mi = "; units --terse ${i}mi km; done|sed
's/$/ km/'
1 mi = 1.609344 km
2 mi = 3.218688 km
3 mi = 4.828032 km
4 mi = 6.437376 km
5 mi = 8.04672 km
Maybe allow something like
$ for i in `seq 5`; do units --printf "%d{input} mi = %f{output} km\n" ${i}mi
km; done
I don't know.
Bug#1064958: Even if there was finally a choice
Also even if at the 31st choice we finally get to keep all, the next day we will still be facing the same problem. Yes, usually it is just a temporary situation. Upstream was just in the middle of sending out some packages, etc. But even so, not for one minute should users be left digging for the 31st choice. So they should always have a "k" option.
Bug#1065006: Letter each choice question
Package: aptitude Version: 0.8.13-5+b1 Severity: wishlist In #1064958 we see the usual choice after choice. Well how about number each choice as it is shown to the user? With letters, so as not to confuse them with the numbers being shown. Not just for debugging purposes, but for everyday use. It always feels good to have letters, even only after one or two. So why not all? So instead of each The following actions will resolve these dependencies: Say M) The following actions will resolve these dependencies: N) The following actions will resolve these dependencies: etc. And after 26 double the letters or something.
Bug#1064958: Even if there was finally a choice
There it finally was, way down at like the 31st choice. Accept this solution? [Y/n/q/?] n XX. The following actions will resolve these dependencies: Keep the following packages at their current version: 1) apt [2.7.12 (now)] 2) apt-utils [2.7.12 (now)] 3) at-spi2-core [2.50.0-1+b1 (now)] 4) gir1.2-atk-1.0 [2.50.0-1+b1 (now)] 5) libglib2.0-bin [2.78.4-1 (now)] 6) libpam-modules [1.5.2-9.1+b1 (now)] 7) libpam-modules-bin [1.5.2-9.1+b1 (now)] Accept this solution? [Y/n/q/?] n First, there should be choice numbers shown, at point XX above. Then in fact I could even easily say what choice it was. 31 is a guess. OK, I'll file a separate bug about that. Second, I was going too fast, with n RET n RET and ended up skipping over it! Thus we see you still need a "k" choice! Sure, you are saying "hurry and send us the exact state of the package system so we can recreate the issue." But I'm saying it doesn't matter. Even if there was only one or two choices before the all-keep choice popped up, there should always be my proposed "k" option available. And yes, "Well just use aptitide install ~U... _... ..._" I am sure there are tons of workarounds. But that doesn't matter, there still should be my proposed "k" short circuit choice!
Bug#1064958: Add k for keep all shown: [Y/n/q/k?]
Package: aptitude Version: 0.8.13-5+b1 Severity: wishlist Imagine there are 1000 different combinations of Accept this solution? [Y/n/q/?] n The following actions will resolve these dependencies: Remove the following packages: 1) libapt-pkg6.0 [2.7.12 (now, unstable)] 2) libglib2.0-0 [2.78.4-1 (now, unstable)] Install the following packages: 3) libapt-pkg6.0t64 [2.7.12+nmu1 (unstable)] 4) libglib2.0-0t64 [2.78.4-2 (unstable)] Keep the following packages at their current version: 5) at-spi2-core [2.50.0-1+b1 (now)] 6) gir1.2-atk-1.0 [2.50.0-1+b1 (now)] 7) libpam-modules [1.5.2-9.1+b1 (now)] 8) libpam-modules-bin [1.5.2-9.1+b1 (now)] Accept this solution? [Y/n/q/?] each of which we don't like. Well the only way to get out of it is nn(500)n and finally q. But q means we can't do the rest of the upgrade. So there should be an additional "k" choice, to keep all shown, and just proceed with the rest of the upgrade which isn't affected by these shown.
Bug#1064926: python-requests-unixsocket: test flake on HEAD request that can lead to FTBFS
Source: python-requests-unixsocket
Version: 0.3.0-3
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
While doing an upload to Ubuntu for another python-requests-unixsocket
fix (Debian bug 1063892), we observed that the package may FTBFS on the
testsuite. The HEAD request portion of some of the tests may fail,
apparently due to particular write/read patterns that can leave excess
data around for the next test request - the unread body.
In local testing the failure rate was small (< 5%), but on official
buidlers it was apparently 100%, so system load is likely a factor.
To that end an upstream PR has been opened:
https://github.com/msabramo/requests-unixsocket/pull/71
--- a/requests_unixsocket/testutils.py
+++ b/requests_unixsocket/testutils.py
@@ -51,6 +51,8 @@
('X-Requested-Query-String', environ['QUERY_STRING']),
('X-Requested-Path', environ['PATH_INFO'])]
body_bytes = b'Hello world!'
+if environ["REQUEST_METHOD"] == "HEAD":
+body_bytes = b''
start_response(status_text, response_headers)
logger.debug(
'WSGIApp.__call__: Responding with '
Also filed in Ubuntu as https://pad.lv/2053154
-Dan
Bug#1056364: borgmatic: please package documentation
Upstream dev here. Please let me know if there's anything I can do to make this easier. (Ideally in the form of a borgmatic ticket.) Today, the online documentation is "packaged" and served as a container image, but I realize that's not the most convenient way to consume offline documentation in Debian. Dan
Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1
Original Message On Feb 15, 2024, 12:44 PM, Jonathan Wiltshire < j...@debian.org> wrote: On Thu, Feb 15, 2024 at 02:24:05PM +0100, Andreas Beckmann wrote: > On 14/02/2024 11.01, Jonathan Wiltshire wrote: > > On Sun, Feb 11, 2024 at 11:23:00PM +0100, Andreas Beckmann wrote: > > > We need to push 4 packages together to stable-updates: > > > nvidia-graphics-drivers > > > nvidia-settings > > > nvidia-graphics-drivers-tesla-470 > > > nvidia-graphics-drivers-tesla > > > > According to my list there's just nvidia-graphics-drivers-tesla missing > > now; does that match yours? > > Seems installable in sid now, so just uploaded to PU. These 4 should be > ready for stable-updates. Thanks; accepted all four, and the builds have just come in. I can release as early as tonight (19:52) but I don't know if that's a bit of a rush. Should I hang on until tomorrow evening in case of any late-breaking issues? As a user facing this issue, I'd rather have the release as soon as possible. It's already been a couple days. But that's just a user perspective! We also need to put some thought into an announcement text. Here's a draft starting point: === This update addresses problems in four non-free packages to support nVidia graphics cards. The Linux kernel update included in Debian 12.5 marked two functions as GPL-only, making them inaccessible to non-free kernel modules. As a result, the nVidia kernel modules cannot be built via DKMS at installation time for the updated kernel. This issue could not be resolved in time for the release of Debian 12.5. The following packages have been updated to correct the problem, as well as fixing detection of Tesla 470 compatibility: Package Fixed version === == nvidia-graphics-drivers nvidia-graphics-drivers-tesla nvidia-graphics-drivers-tesla-470 nvidia-settings If you use the affected packages, we recommend you upgrade to these versions. === Feedback? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1 -- To unsubscribe, send mail to 1063675-unsubscr...@bugs.debian.org.
Bug#1063817: debconf-copydb pipe writes to GLOB file instead of stdout
Package: debconf Version: 1.5.85 Severity: normal X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, While debugging a FTBFS in Ubiquity, I observed that the usage of debconf-copydb regressed when using version 1.5.85 of debconf. The previous-in-Ubuntu version 1.5.82 of debconf was OK. That invocation looks roughly like: debconf-copydb templatedb pipe --config=Name:pipe --config=Driver:Pipe --config=InFd:none ... Bisecting debconf from there found commit 5db857ade00953496bfdb7edb884296bebc41885: "Avoid two-argument open" Further tracing found the following change to Debconf/DbDriver/Pipe.pm around line 120: - open ($fh, '>-'); + open ($fh, '>', \*STDOUT); An additional symptom of this problem is GLOB files are created in CWD with names that look like: GLOB(0x0123456789ab) Pointing the above to above to configdb on a fairly stock Debian Sid installation produces an equivalent result - GLOB file creation instead of the output. Is the 3-argument form this? open ($fh, '>&', \*STDOUT); Originally filed as LP: #2052982. -Dan
Bug#1061468: gloo: attempts to build on unsupported 32 bit systems
[Paul Wise] > The right way to do this is to Build-Depend: architecture-is-64-bit Thanks Paul, I didn't know about that. Clearly architecture-is-64-bit is the better solution. [Petter Reinholdtsen] > [Dan Bungert] > > I suggest adjusting the control file to reflect this state so that > > builds are only attempted on 64 bit systems. > Why? Which problem are you trying to solve? Doing such change will > fail to automatically discover if gloo start working on other > architectures, and require extra work to keep the list of architectures > up to date as Debian evolves. As far as I can see, the disadvantage of > trying to build on non-supported architectures is a few wasted CPU > cycles, while the advantage is less human time spent on package > maintenance. Did I miss something? To me, saving humans time is more > valuable than saving CPU time. Saving humans time is a tradeoff I will agree with. Another angle though is the time of people looking at problems across an architecture or, like me, who are temporarily looking at this package and checking why some of the builds fail. These "some builds fail" bugs can sometimes indicate a flaky build and that the rest of the builds can't be considered stable. Of course that's not the case here - it's a straightforward case of builds being disabled for 32 bit arches, which is a reasonable decision for upstream to make. No problem there. A bit unfortunate that cmake has this critical string not at the end of the log file, so the "tail of log" reports at https://buildd.debian.org/status/package.php?p=gloo are missing this detail, but that's a cmake issue. So the tradeoff I'm proposing is making it simpler for others looking at the package, to remove failed builds that we know will fail. It indeed has the downside that if the 32 bit support status changes it will require a change to reverse. Do you consider that scenario likely? There is side benefit here that the CPU time being saved is a bit more rarefied than amd64. If the above is uncompelling, you are of course free to decline the change. -Dan
Bug#1062779: Some files lack executable permission
Package: python3-i3ipc Version: 2.2.1-3 File: /usr/share/doc/python3-i3ipc/examples/i3-cycle-focus.py Shouldn't /usr/share/doc/python3-i3ipc/examples/i3-cycle-focus.py be chmod +x? Same with some of the others there, but some are OK. Then we could execute them directly...
Bug#1062778: Upstream has much different version
Package: python3-i3ipc Version: 2.2.1-3 File: /usr/share/doc/python3-i3ipc/examples/i3-cycle-focus.py It seems upstream has a much newer version, but I can't tell, due to https://github.com/altdesktop/i3ipc-python/issues/210
Bug#1062527: libimage-info-perl: ADT failure if libxml-simple-perl chosen instead of libxml-libxml-perl
Package: libimage-info-perl Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, I believe the following dependency is not quite correct. Today it says: Depends: ... libxml-libxml-perl | libxml-simple-perl If autopkgtest is run and libxml-libxml-perl is not installed, you get: 414s # Can't locate XML/LibXML/Reader.pm in @INC (you may need to install the XML::LibXML::Reader module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/share/perl5/Image/Info/SVG/XMLLibXMLReader.pm line 21. To address this, the dependency list should change to say libxml AND simple. The justification for that is based on code inspection of l/I/I/S/XMLLibXMLReader.pm, which says: use XML::LibXML::Reader; ... require XML::Simple; I'm not an expert on this package, or perl in general, so if you think the handling of libxml-simpler-perl is not quite correct, please implement otherwise. But the depend on libxml-libxml-perl seems quite firm. For Ubuntu I have uploaded the `and` version of this dependency in place of the `or`. This bug report was also filed in Ubuntu and can be found at https://launchpad.net/bugs/2051970 -Dan
Bug#1061596: When to never ask despite Always-Prompt
Package: aptitude Version: 0.8.13-5+b1 Severity: wishlist Even with Aptitude::CmdLine::Always-Prompt true there are some cases when prompting still doesn't make sense: # aptitude full-upgrade No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Do you want to continue? [Y/n/?]
Bug#1060173: ruby-hiredis FTBFS with hiredis 1.2.0-6
I examined this bug a bit. In test/reader_test.rb, test_nil / test_null_multi_bulk are both failing. If these tests are commented out, the package build will complete. Doesn't sound like a great idea though as it's not clear to me why these tests regressed. -Dan
Bug#1061539: wlrctl: missing arm64 version
Package: wlrctl Please also provide arm64 versions of this package! Might as well make the other missing versions too.
Bug#1061538: Old package separator "'" deprecated
Package: linklint Version: 2.3.5-7 File: /usr/bin/linklint Old package separator "'" deprecated at /usr/bin/linklint line 987...
Bug#1061468: gloo: attempts to build on unsupported 32 bit systems
Source: gloo
Version: 0.0~git20230519.597accf-2
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com
Dear Maintainer,
gloo attempts to build on 32 bit systems.
https://buildd.debian.org/status/package.php?p=gloo
We know this will not work, as cmake reports the following:
> Gloo can only be built on 64-bit systems.
I suggest adjusting the control file to reflect this state so that
builds are only attempted on 64 bit systems. Something like this should
work.
@@ -17,7 +17,7 @@ Rules-Requires-Root: no
Package: libgloo-dev
Section: libdevel
-Architecture: any
+Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64
loong64 ppc64 sparc64
Depends: libgloo0 (= ${binary:Version}),
libhiredis-dev,
libibverbs-dev,
-Dan
Bug#610668: closed by Steven Robbins (Re: mention gv more)
OK, gv is from a different package.
Bug#1060424: udisks2: Permission denied (Chromebook)
Package: udisks2 Version: 2.10.1-5 Seen on Chromebook. Setting up udisks2 (2.10.1-5) ... vda: Failed to write 'change' to '/sys/devices/platform/1.pci/pci:00/:00:04.0/virtio3/block/vda/uevent': Permission denied vdb: Failed to write 'change' to '/sys/devices/platform/1.pci/pci:00/:00:05.0/virtio4/block/vdb/uevent': Permission denied vdc: Failed to write 'change' to '/sys/devices/platform/1.pci/pci:00/:00:06.0/virtio5/block/vdc/uevent': Permission denied loop0: Failed to write 'change' to '/sys/devices/virtual/block/loop0/uevent': Permission denied ... loop7: Failed to write 'change' to '/sys/devices/virtual/block/loop7/uevent': Permission denied -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.60-08594-g03a802b9a072 (SMP w/8 CPU threads; PREEMPT)
Bug#1059936: tons of them
update-initramfs: Generating /boot/initrd.img-6.6.9-amd64 cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead
Bug#974972: Latest Version: 4.3.6 (20 Oct 2023)
An https://github.com/MacPaw/XADMaster/releases has a has a 1.10.8 from Oct 2023.
Bug#974972: Latest Version: 4.3.6 (20 Oct 2023)
$ man unar | tail -n 1 | tr -s ' ' The Unarchiver 2011-09-26 unar(1) $ unar --version v1.10.1 $ w3m -dump https://macpaw.com/the-unarchiver | grep Version Latest Version: 4.3.6 (20 Oct 2023)
Bug#946382: This bug report seems useless in my opinion
>>>>> "GK" == Georges Khaznadar writes:
GK> Hello Dan,
GK> I would like to get more information about your intent, for this bug
GK> report.
Looking at the crontab(5) man page,
everything lines up very pretty:
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.monthly )
But that is because the author picked 6 hours for each.
Let's see what would happen otherwise:
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.monthly )
Oh darn, that looks ugly.
The question that crosses users minds is: "Can I rewrite it
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )
47 06 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.weekly )
52 06 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.monthly )
or will that be taken as octal (even if octal 6 is just 6), or illegal?
Please don't force me to test to find the answer."
I'm just saying the man page needs to state clearly what will happen.
Sure, one could just add spaces instead of zeros to make the columns
line up. But that would just be avoiding the issue.
GK> Should leading zeroes be supported for the sake of making columns line
GK> up, or should leading zeroes be used to introduce octal constants, in
GK> your opinion?
Nobody wants octal. I'm just trying to make columns line up.
GK> As far as I understand the code of the file entry.c, numbers are parsed
GK> by the function atoi:
GK> -8<- file entry.c's excerpt --
GK> if (all_digits) {
GK> *numptr = atoi(temp);
GK> return ch;
GK> }
GK> -8<---
GK> ... which means that numbers prefixed by zeroes are considered as
GK> decimal.
OK that's great. Please mention so on crontab(5). Thanks.
In fact perhaps add an example saying one can use spaces and zeros to make the
columns line up:
25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.daily )
47 06 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.weekly )
52 4 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
--report /etc/cron.monthly )
Bug#1059421: Say " (which is also called dhclient)"
Package: isc-dhcp-client Version: 4.4.3-P1-4 Severity: minor File: /usr/share/doc/isc-dhcp-client/NEWS.Debian.gz We read > isc-dhcp-client (4.4.3-1) unstable; urgency=medium > > ISC has decided to stop maintaining the client and relay parts of isc-dhcp, > and they will be removed after the 4.4.3 release, keeping only the server > component. Please, consider using an alternative for isc-dhcp-client > (dhclient). Say instead: > ... component. Please, consider using an alternative for isc-dhcp-client > (which is also called dhclient). Otherwise we think the alternative we want is called dhclient.
Bug#1057139: Update
Is anyone monitoring these bug reports? Any suggestions on next steps?
Bug#1058648: p11-kit: FTBFS if bash-completion is installed
Source: p11-kit Version: 0.25.3-2 Severity: normal X-Debbugs-Cc: daniel.bung...@canonical.com Dear Maintainer, If bash-completion happens to be installed at the time of build, the build will fail. This can be observed when building on Debian Sid or Ubuntu Noble. dh_missing dh_missing: warning: usr/share/bash-completion/completions/p11-kit exists in debian/tmp but is not installed to anywhere (related file: "debian/tmp/usr/bin/p11-kit") dh_missing: warning: usr/share/bash-completion/completions/trust exists in debian/tmp but is not installed to anywhere (related file: "debian/tmp/usr/bin/trust") dh_missing: error: missing files, aborting full sample log: https://launchpadlibrarian.net/702524075/buildlog_ubuntu-noble-amd64.p11-kit_0.25.3-2ubuntu1_BUILDING.txt.gz Presumably the files should be added to the p11-kit binary package, or adding "usr/share/bash-completion/*" to d/not-installed will address the FTBFS. Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/2046389 -Dan
Bug#1057978: Almost removed most of my system
Package: aptitude
Version: 0.8.13-5
Today I out of habit hit RET to the following.
It removed much of my system.
https://www.reddit.com/r/Crostini/comments/alytbc/comment/kcv98ks/
Next time I'll be more careful and not trust it.
I didn't realize how long the list was when I hit RET.
Maybe there should be a second question if the removal list is longer than 20
packages.
# aptitude full-upgrade
The following packages will be REMOVED:
alsa-topology-conf{ap} alsa-ucm-conf{ap} apel{ap} appstream{ap}
at-spi2-core{ap}
bash-completion{ap} bzip2{ap} cpp{ap} (D: cpp-13) cpp-13{ap}
cros-logging{ap}
cros-pipe-config{ap} (D: pipewire, D: pipewire-alsa, D: pipewire-pulse, D:
wireplumber)
cros-sommelier-config{ap} cros-sudo-config{ap} cros-systemd-overrides{ap}
cros-vmstat-metrics{ap}
cros-wayland{ap} docbook-xml{ap} (D: sgml-data) dosfstools{ap} eject{ap}
enchant-2{ap}
exfatprogs{ap}
exim4-base{ap} (D: exim4-config, D: exim4-config-2, D:
libfile-fcntllock-perl, R: bsd-mailx, R: mailx, R: psmisc, S: file)
exim4-config{ap} exim4-daemon-light{ap} (D: exim4-base)
expect{ap} (D: libtcl8.6, D: tcl-expect, D: tcl8.6) ffmpeg{ap} file{ap}
flim{ap} (D: apel)
fonts-droid-fallback{ap} (R: fonts-noto-mono) fonts-noto-color-emoji{ap}
fonts-noto-mono{ap}
fonts-vlgothic{ap} ghostscript{ap} (D: libgs10) gir1.2-glib-2.0{ap} (D:
libgirepository-1.0-1)
git{ap} (D: git-man, D: liberror-perl, R: patch) git-man{ap}
gpsbabel-doc{ap} gsasl-common{ap}
gsfonts{ap} gstreamer1.0-gl{pu} (R: libgstreamer-gl1.0-0)
gstreamer1.0-libav{ap}
gstreamer1.0-plugins-bad{pu} gstreamer1.0-x{pu} guile-3.0-libs{ap}
gvfs{ap} (D: gvfs-common, D: gvfs-daemons, D: gvfs-libs) gvfs-common{ap} (R:
gvfs)
gvfs-daemons{ap} (D: gvfs-common, D: gvfs-libs, D: libudisks2-0, D: lsof, D:
udisks2, R: gvfs)
gvfs-libs{ap} (D: gvfs-common, D: libgcr-base-3-1) imagemagick-6-common{ap}
iptables{ap} (D: libip4tc2, D: libip6tc2, D: libnetfilter-conntrack3, D:
libnfnetlink0, D: libnftnl11, R: nftables)
isc-dhcp-common{ap} javascript-common{ap} kitty-doc{ap} (D: libjs-sphinxdoc)
libaacs0{ap} (R: libbdplus0) libatasmart4{ap} libauthen-sasl-perl{ap}
libavtp0{pu} (D: gstreamer1.0-plugins-bad) libbdplus0{ap} (R: libaacs0)
libblockdev-crypto3{ap} (D: libblockdev-utils3, D: libvolume-key1)
libblockdev-fs3{ap} (D: libblockdev-utils3) libblockdev-loop3{ap} (D:
libblockdev-utils3)
libblockdev-mdraid3{ap} (D: libblockdev-utils3, D: libbytesize1)
libblockdev-nvme3{ap} (D: libblockdev-utils3, D: libnvme1)
libblockdev-part3{ap} (D: libblockdev-utils3) libblockdev-swap3{ap} (D:
libblockdev-utils3)
libblockdev-utils3{ap} libblockdev3{ap} (D: libblockdev-utils3)
libbytesize-common{ap}
libbytesize1{ap} (D: libbytesize-common) libc-devtools{ap} (R: manpages, R:
manpages-dev)
libcanberra0{ap} (D: libtdb1, D: sound-theme-freedesktop) libclone-perl{ap}
libconfig++9v5{ap}
libdata-dump-perl{ap} libdca0{pu} (D: gstreamer1.0-plugins-bad)
libdecor-0-plugin-1-gtk{ap}
libdirectfb-1.7-7{pu} (D: gstreamer1.0-plugins-bad) libdjvulibre-text{ap}
libdjvulibre21{ap} (D: libdjvulibre-text)
libdpkg-perl{ap} (R: bzip2, R: libfile-fcntllock-perl, R:
liblocale-gettext-perl, R: xz-utils, S: git, S: patch, S: sensible-utils)
libencode-locale-perl{ap} liberror-perl{ap} libfaad2{pu} (D:
gstreamer1.0-plugins-bad)
libffado2{ap} (D: libconfig++9v5, D: libglibmm-2.4-1v5, D: libxml++2.6-2v5)
libfile-basedir-perl{ap} (D: libipc-system-simple-perl)
libfile-desktopentry-perl{ap} (D: libfile-basedir-perl, D: liburi-perl)
libfile-fcntllock-perl{ap}
libfile-listing-perl{ap} (D: libhttp-date-perl)
libfile-mimeinfo-perl{ap} (D: libencode-locale-perl, D: libfile-basedir-perl,
D: libfile-desktopentry-perl, R: libio-stringy-perl)
libfluidsynth3{pu} (D: gstreamer1.0-plugins-bad) libfont-afm-perl{ap}
libfreeaptx0{pu} (D: gstreamer1.0-plugins-bad) libgail-common{ap} (D:
libgail18) libgail18{ap}
libgck-1-0{ap} libgcr-base-3-1{ap} (D: libgck-1-0) libgdk-pixbuf2.0-bin{ap}
libgirepository-1.0-1{ap}
libglibmm-2.4-1v5{ap} libgraphene-1.0-0{pu} (D: gstreamer1.0-gl)
libgs-common{ap}
libgs10{ap} (D: libgs10-common, D: libijs-0.35, D: libjbig2dec0, D:
libpaper1, D: poppler-data)
libgs10-common{ap} (D: libgs-common, R: fonts-droid-fallback)
libgtk-3-bin{ap} libgtk2.0-bin{ap}
libheif-plugin-aomenc{ap} libheif-plugin-x265{ap}
libhtml-form-perl{ap} (D: libhtml-parser-perl, D: libhttp-message-perl, D:
liburi-perl)
libhtml-format-perl{ap} (D: libfont-afm-perl, D: libhtml-tree-perl)
libhtml-parser-perl{ap} (D: libhtml-tagset-perl, D: liburi-perl, R:
libhttp-message-perl, S: libdata-dump-perl)
libhtml-tagset-perl{ap}
libhtml-tree-perl{ap} (D: libhtml-parser-perl, D: libhtml-tagset-perl, R:
libhtml-format-perl, R: libwww-perl)
libhttp-cookies-perl{ap} (D: libhttp-date-perl, D: libhttp-message-perl)
libhttp-daemon-perl{ap} (D: libhttp-date-perl, D: libhttp-message-perl, D:
Bug#1057888: wpagui connect and disconnect buttons
Package: wpagui Version: 2:2.10-18 Severity: wishlist When connected, the connect button should become grey (unclickable). When diconnected, the disconnect button should also become grey. Yes, even if the state is detectable from other words on the interface.
Bug#1031666: Missing Dependencies: Geo::Point
Sorry. I don't know if I am talking about Geo:: or Gis:: or libgeo or libgis. It is all too confusing. I'll leave it to others to straighten out. As far a packages that don't seem to work as their man pages say, I sure hope there is at least a README file in their doc directories about it.
Bug#1057875: I'm not sure if I'm talking about Geo:: or Gis::
Sorry. I don't know if I am talking about Geo:: or Gis:: or libgeo or libgis. It is all too confusing. I'll leave it to others to straighten out.
Bug#1031666: Missing Dependencies: Geo::Point
On https://metacpan.org/pod/Geo::Distance is says Deprecated. The maintainer of this distribution has indicated that it is deprecated and no longer suitable for use. So it is time to remove this package from Debian! Thanks. I made a separate bug report about it.
Bug#1057875: Remove this upstream deprecated package
Package: libgis-distance-perl Severity: grave On https://metacpan.org/pod/Geo::Distance is says Deprecated. The maintainer of this distribution has indicated that it is deprecated and no longer suitable for use. So it is time to remove this package from Debian! Thanks.
Bug#1057776: dh-make-perl: Incorrect .deb filename is used when --install and --revision are supplied
Package: dh-make-perl Version: 0.122 Severity: normal Tags: patch X-Debbugs-Cc: dan.le...@sitpub.com Dear Maintainer, When both the --install and --revision options are used with dh-make-perl, the package build is successful but the package installation fails due to the supplied revision not being included in the filename passed to dpkg. e.g., if the following is run: dh-make-perl --install --revision 100 --cpan JSON::Diffable dh-make-perl correctly builds the .deb file with the supplied revision and creates libjson-diffable-perl_0.02-100_all.deb However, it then supplies 'libjson-diffable-perl_0.02-1_all.deb' to dpkg when attempting to install the package. Note the use of a hardcoded '-1' revision. This causes the operation to fail with: dpkg-deb: building package 'libjson-diffable-perl' in '../libjson-diffable-perl_0.02-100_all.deb'. make: Leaving directory '/root/JSON-Diffable-0.02' I: Running 'apt install /root/JSON-Diffable-0.02/../libjson-diffable-perl_0.02-1_all.deb'... Reading package lists... Done E: Unsupported file /root/JSON-Diffable-0.02/../libjson-diffable-perl_0.02-1_all.deb given on commandline Cannot install package /root/JSON-Diffable-0.02/../libjson-diffable-perl_0.02-1_all.deb The filename is generated with: $debname = sprintf( "%s_%s-1_%s.deb", $self->pkgname, $self->version, $archspec ); Which I believe should instead be: $debname = sprintf( "%s_%s_%s.deb", $self->pkgname, $self->pkgversion, $archspec ); $self->pkgversion contains the revision supplied with --revision. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.2-arch1-1 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages dh-make-perl depends on: ii debhelper 13.11.4 ii dpkg-dev 1.21.22 ii fakeroot 1.31-1.2 ii libapt-pkg-perl0.1.40+b2 ii libarray-unique-perl 0.08-4 ii libclass-accessor-perl 0.51-2 ii libconfig-ini-perl 1:0.029-1 ii libconfig-model-dpkg-perl 2.165 ii libdebian-source-perl 0.122 ii libdpkg-perl 1.21.22 ii libemail-address-xs-perl 1.05-1+b1 ii libemail-date-format-perl 1.008-1 ii libfile-which-perl 1.27-2 ii liblist-moreutils-perl 0.430-2 ii libmodule-depends-perl 0.16-5 ii libpod-parser-perl 1.65-1 ii libsoftware-license-perl 0.104002-1 ii libtie-ixhash-perl 1.23-4 ii libwww-mechanize-perl 2.16-1 ii libwww-perl6.68-1 ii libyaml-libyaml-perl 0.86+ds-1 ii libyaml-perl 1.30-2 ii make 4.3-4.1 ii perl 5.36.0-7 Versions of packages dh-make-perl recommends: ii apt-file 3.3 ii git 1:2.39.2-1.1 ii libmodule-build-perl 0.423200-1 ii libsys-cpu-perl 0.61-3+b1 ii pristine-tar 1.50 dh-make-perl suggests no packages. -- no debconf information --- /lib/DhMakePerl/Command/make.pm 2023-02-21 20:14:06.0 + +++ /lib/DhMakePerl/Command/make.pm 2023-12-01 17:12:50.901091797 + @@ -465,7 +465,7 @@ $archspec = $arch; } -$debname = sprintf( "%s_%s-1_%s.deb", $self->pkgname, $self->version, +$debname = sprintf( "%s_%s_%s.deb", $self->pkgname, $self->pkgversion, $archspec ); my $deb = $self->main_dir . "/../$debname";
Bug#1057121: dpkg: warning: unable to delete old directory '/lib/firmware/...
Best would be a message on the screen too, during apt-get, saying "Don't worry about the unable to delete old directory messages, Pretend you didn't see them." or something.
Bug#1057123: Fastest Taiwan mirror missed
Package: netselect-apt Version: 0.3.ds1-30.1 Severity: minor Testing in Taiwan, fastest machine http://opensource.nchc.org.tw/ somehow missed getting into the competition. It is listed on https://www.debian.org/mirror/list .
Bug#1057121: dpkg: warning: unable to delete old directory '/lib/firmware/...
Package: firmware-misc-nonfree Version: 20230625-1 Saw tons of these. Unpacking firmware-misc-nonfree (20230625-1) over (20230515-3) ... dpkg: warning: unable to delete old directory '/lib/firmware/wfx': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/ueagle-atm': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/tigon': Directory not empty dpkg: warning: unable to delete old directory '/lib/firmware/tehuti': Directory not empty Due to /lib/firmware/tehuti/bdx.bin etc.
Bug#1056907: Add non-free-firmware
Package: netselect-apt netselect-apt --nonfree only makes deb http://ftp.tku.edu.tw/debian/ sid main contrib non-free it should make deb http://ftp.tku.edu.tw/debian/ sid main contrib non-free non-free-firmware
Bug#1056774: Blank space on copyright page
Package: viking In /usr/share/doc/viking/copyright it says It was downloaded from and there is a blank space.
Bug#1002993: Also seen on chromebook
I just did the simple Linux installation as seen on https://support.google.com/chromebook/answer/9145439 https://www.youtube.com/watch?v=EVWrdrvQ-rU Oh, and then I changed the /etc/apt/sources.list.d/ to get "sid", and also picked beta channel: Google Chrome: Version 120.0.6099.25 (Official Build) beta (32-bit) Platform: 15662.16.0 (Official Build) beta-channel jacuzzi Channel: beta-channel Firmware Version: Google_Fennel.12573.380.0 ARC Enabled: true ARC: 11087447 Enterprise Enrolled: false Developer Mode: false Anyway, yes I read https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md but that's way advanced stuff, over my head. So you will need to send me a script with what commands to run to glean information about my chromebook. Yes I read https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md but that's way advanced stuff, over my head. Anyway, df, mount, stat,.. just tell me what commands to run and I'll post the output here.
Bug#1002993: Also seen on chromebook
Seen on Chromebook 120 Linux systemd 255~rc2-3 Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal failed: Invalid argument Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal/f7d2e0290918427294865abb94e8fa09 failed: Invalid argument Setting access ACL "u::rw-,g::r-x,g:adm:r--,g:4294967295:r-x,m::r--,o::---" on /var/log/journal/f7d2e0290918427294865abb94e8fa09/system.journal failed: Invalid argument All I know is I use chromebook with Linux on chromeOS beta. Send me any tests you want me to run. Seen during apt upgrade.
Bug#1056558: Remove "-emulator" from the sensible-terminal man page
Package: sensible-utils Version: 0.0.20 Severity: important $ set sensible-terminal $ man $@ | grep $@ sensible-terminal-emulator - sensible terminal emulator sensible-terminal-emulator [-T title] [--wait] [-e cmd...] sensible-terminal-emulator makes sensible decisions on $ sensible-terminal-emulator bash: sensible-terminal-emulator: command not found $ which $@ /usr/bin/sensible-terminal The binary is just called sensible-terminal. So "-emulator" needs to be removed from many places on the man page. Also > Documentation of behavior of sensible-utils under a debian system Debian, not debian.
Bug#1055858: Warnings from emacs 29.1
Package: w3m-el-snapshot Version: 1.4.632+0.20221206.2328.4f27810-1 I see: ⛔ Warning (comp): w3m-session.el:112:2: Warning: defvar `w3m-session-group-open' docstring has wrong usage of unescaped single quotes (use \= or different quoting) ⛔ Warning (comp): w3m-bookmark.el:208:25: Warning: ‘point-at-eol’ is an obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead. ⛔ Warning (comp): w3m-bookmark.el:461:23: Warning: ‘point-at-bol’ is an obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead. ⛔ Warning (comp): w3m-bookmark.el:467:33: Warning: ‘point-at-bol’ is an obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead. ⛔ Warning (comp): w3m-form.el:2026:20: Warning: ‘point-at-bol’ is an obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead. ⛔ Warning (comp): w3m-form.el:2026:58: Warning: ‘point-at-eol’ is an obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead. ⛔ Warning (comp): w3m-form.el:2027:19: Warning: ‘point-at-eol’ is an obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead. ⛔ Warning (comp): w3m-form.el:2028:37: Warning: ‘point-at-bol’ is an obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead. ⛔ Warning (comp): w3m-form.el:2029:49: Warning: ‘point-at-bol’ is an obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead. etc. many warnings.
Bug#207095: closed by Thomas Lange (closing)
OK, that's great. But nobody visiting the packages page knows about the tracker page, so there ought to be a hyperlink added to it on the packages page.
Bug#1054326: Can't start golbal heartbeat when drbd device is on top LVM device
Package: ocfs2-tools Version: 1.8.7-1+b1 Severity: important X-Debbugs-Cc: mar...@mydatex.cz Dear maitainer, in virtual enviroment I try build 2 node ocfs cluster. When drbd device is on top of md device all works. But when drbd device is on top LVM device global heartbeat doesn't start. Using config file '/etc/ocfs2/cluster.conf' Initializing cluster stack Checking heartbeat mode Global heartbeat enabled Heartbeat region 3D69F9BD7AF24C59BB600A8D7B1D4770 Scanning devices About to start heartbeat o2cb: Heartbeat region could not be found 3D69F9BD7AF24C59BB600A8D7B1D4770 root@drbd-server01:/home/marvin/ocfs2-tools/o2cb_ctl# mounted.ocfs2 -d -v -v Probing device /dev/vda1 Probing device /dev/vdb Probing device /dev/vdb1 Probing device /dev/vdb5 Probing device /dev/vdc Probing device /dev/vdc1 Probing device /dev/sr0 Probing device /dev/md0 Probing device /dev/mapper/c-o Probing device /dev/drbd0 Device Stack Cluster F UUID Label /dev/mapper/c-o o2cb mdtxcluster G 3D69F9BD7AF24C59BB600A8D7B1D4770 mdtx /dev/drbd0 o2cb mdtxcluster G 3D69F9BD7AF24C59BB600A8D7B1D4770 mdtx -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 ocfs2-tools depends on: ii debconf [debconf-2.0] 1.5.82 ii init-system-helpers1.65.2 ii libaio10.3.113-4 ii libc6 2.36-9+deb12u3 ii libcmap4 3.1.7-1 ii libcom-err21.47.0-2 ii libdlm34.2.0-2 ii libglib2.0-0 2.74.6-2 ii libreadline8 8.2-1.3 ii libuuid1 2.38.1-5+b1 ii lsb-base 11.6 ii psmisc 23.6-1 ii sysvinit-utils [lsb-base] 3.06-4 ocfs2-tools recommends no packages. ocfs2-tools suggests no packages. -- debconf information: ocfs2-tools/idle_timeout: 3 ocfs2-tools/heartbeat_threshold: 31 ocfs2-tools/reconnect_delay: 2000 ocfs2-tools/keepalive_delay: 2000 ocfs2-tools/init: false ocfs2-tools/clustername: ocfs2
Bug#1053692: [graphicsmagick:discussion] Re: Any plans to add HEIC format?
Package: graphicsmagick Hello. The viewnior and gpicview packages support heic, so should gm. --- On 2023-10-08 08:08, Bob Friesenhahn wrote: On Sat, 7 Oct 2023, Dan Jacobson wrote: I was using https://packages.debian.org/sid/graphicsmagick on a chromebook $ gm convert -list formats |fgrep -i heif AVIF P r-- HEIF Image Format (heif v16.2.0) HEIC P r-- HEIF Image Format (heif v16.2.0) HEIF P r-- HEIF Image Format (heif v16.2.0) $ gm convert -debug coder,exception C001.heic info:- 18:35:16 0:0.002526 0.000u 3249 constitute.c/ReadImage/1676/Coder: Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0 18:35:16 0:0.010894 0.010u 3249 heif.c/ReadHEIFImage/571/Coder: Geometry: 1280x720 18:35:16 0:0.011036 0.010u 3249 heif.c/ReadHEIFImage/573/Coder: Matte: False 18:35:16 0:0.011135 0.010u 3249 heif.c/ReadHEIFImage/650/Coder: heif_decode_image() reports error "Unsupported feature: Unsupported codec" From the above, I deduce that libheif from Debian Sid does not support HEIC, or a sub-feature of HEIC. It is possible that Debian Sid binaries do not include support for HEIC at all. The nature of free software is that free software developers (and free distributions) may not be willing to pay license fees, or legal fees, or financial penalties, associated with patented algorithms. At least Ubuntu 22.04 LTS does include HEIC support. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt --- [Any plans to add HEIC format?](https://sourceforge.net/p/graphicsmagick/discussion/250738/thread/3082583888/?limit=25#72bc/4107/9a40/a1c7)
Bug#1052601: Fix Description so everybody can understand it
Package: remind-tools Version: 04.02.06-1 Severity: minor >Description: sophisticated calendar and alarm program - rem2ps, 2pdf, 2html >tools > Remind allows you to remind yourself of upcoming events and appointments. > Each reminder or alarm can consist of a message sent to standard output, or a > program to be executed. > It also features: sophisticated date calculation, moon phases, > sunrise/sunset, Hebrew calendar, alarms, PostScript output, tcl/tk front-end > and proper handling of holidays. > Tools to convert the remind output to ps, pdf or html as well as > example files. I would change the last sentence to say: < This remind-tools package provides tools to convert the remind output < to ps, pdf or html as well as example files.
Bug#1052329: Acknowledgement (systemd: systemctl really slow to tab complete with zsh)
Sorry, just extracted /usr/share/zsh/vendor-completions/_systemctl from the latest unstable release and the fix is in there. Sorry for the noise. Dan. > On 20 Sep 2023, at 16:27, Debian Bug Tracking System > wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1052329: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052329. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian systemd Maintainers > > If you wish to submit further information on this problem, please > send it to 1052...@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. > > -- > 1052329: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052329 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#884253: See also
See also https://github.com/tumic0/GPXSee/issues/98 .
Bug#1051703: pdns-backend-pgsql: No mention of schema updates in NEWS despite breaking service
Hi Thanks for your response, I think this is mostly on me, but some comments on why I missed this: > * README.Debian files in each individual pdns-backend-* package I must confess that I didn’t notice the info about updates in here (but re-reading I find the mention of the /usr/share/pdns-backend-pgsql/schema directory, which was the primary thing I was looking for. It was just that on skimming that file it looked only about setting up the server. It might’ve been easier for me to spot if there was a separate section about updates as I had just disregarded that file given the ‘title’ (and in fact I ended up getting the schema updates from the upstream repo). I’d understand that you’d want to close this bug. Thanks for your work 😊 Dan The Networking People (TNP) Limited. Registered office: Network House, Caton Rd, Lancaster, LA1 3PE. Registered in England & Wales with company number: 07667393 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Bug#1051703: pdns-backend-pgsql: No mention of schema updates in NEWS despite breaking service
Package: pdns-backend-pgsql
Version: 4.7.3-2
Severity: important
Dear Maintainer,
Upon upgrading, manual steps are required to update the schema of the SQL
tables as mentioned upstream here:
https://doc.powerdns.com/authoritative/upgrading.html#schema-changes
Unfortunately I did not find this mentioned in NEWS or changelog leading to
errors on upgrade:
---
Exiting because communicator thread died with error: virtual void
GSQLBackend::getUpdatedMasters(std::vector&,
std::unordered_set&, CatalogHashMap&) unable to retrieve list of
master domains: Fatal error during prePQpreparepare: select domains.id,
domains.name, domains.type, domains.notified_serial, domains.options,
domains.catalog, records.content from records join domains on
records.domain_id=domains.id and records.name=domains.name where
records.type='SOA' and records.disabled=false and domains.type in ('MASTER',
'PRODUCER'): ERROR: column domains.options does not exist
---
I suggest these changes are mentioned in the debian upgrades notes
thanks,
Dan
-- System Information:
Debian Release: 12.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pdns-backend-pgsql depends on:
ii libc62.36-9+deb12u1
ii libgcc-s112.2.0-14
ii libpq5 15.3-0+deb12u1
ii libstdc++6 12.2.0-14
ii pdns-server 4.7.3-2
pdns-backend-pgsql recommends no packages.
Versions of packages pdns-backend-pgsql suggests:
pn postgresql
-- no debconf information
Bug#915289: Files never arrived
They are listed, but not present: $ dlocate --filename-only cron_now | xargs ls -l ls: cannot access '/usr/sbin/cron_now': No such file or directory ls: cannot access '/usr/share/man/man8/cron_now.8.gz': No such file or directory Also make sure to mention them on the other man pages' SEE ALSO.
Bug#1030129: (no subject)
Are there any plans to backport this? Is the bug in a state that allows it to show up as an action item for the maintainers?
Bug#1024695: also debian-ispell
Hi 1034744 team: please see #1024695 as a bug that could get fixed at the same time...
Bug#1041767: .emacs instructions
OK, I put this in my (29.1) .emacs file (require 'comp) (native-compile-prune-cache)
Bug#1024695: also debian-ispell
⛔ Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘dired-mode-map’ ⛔ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) ⛔ Warning (comp): debian-ispell.el:420:16: Warning: reference to free variable ‘ispell-program-name’ ⛔ Warning (comp): debian-ispell.el:427:16: Warning: reference to free variable ‘ispell-dictionary’ ⛔ Warning (comp): debian-ispell.el:429:11: Warning: assignment to free variable ‘ispell-base-dicts-override-alist’ ⛔ Warning (comp): debian-ispell.el:437:24: Warning: reference to free variable ‘ispell-base-dicts-override-alist’ ⛔ Warning (comp): debian-ispell.el:475:9: Warning: reference to free variable ‘ispell-dictionary’ ⛔ Warning (comp): debian-ispell.el:489:18: Warning: reference to free variable ‘ispell-program-name’
Bug#1041767: Debian should have a .eln package
I notice the Debian's emacs comes with e.g.,
/usr/lib/emacs/28.2/native-lisp/28.2-66fa0d00/preloaded/elisp-mode-90dbfe40-c7c8
already installed, So no extra version needs to be made (involuntarily,
with no way to turn off apparently, by the user.)
So the answer is: Debian should come with all the .eln files, not just
some of them.
Or they could be split into a second optional debian package.
Then there wouldn't be the one useful version, and also left over
versions, for each file, left on the users' disks:
# find .emacs.d/eln-cache/*/url-his* |xargs ls -ogt
-rwxr-xr-x 1 39464 08-03 02:05
.emacs.d/eln-cache/28.2-66fa0d00/url-history-a9b2f6e8-bfe8d526.eln
-rwxr-xr-x 1 39472 05-27 08:02
.emacs.d/eln-cache/28.2-e4556eb6/url-history-a9b2f6e8-bfe8d526.eln
-rwxr-xr-x 1 39464 2022-11-29
.emacs.d/eln-cache/28.2-467432cd/url-history-a9b2f6e8-bfe8d526.eln
-rwxr-xr-x 1 39464 2022-11-23
.emacs.d/eln-cache/28.2-fd960886/url-history-a9b2f6e8-bfe8d526.eln
-rwxr-xr-x 1 39464 2022-10-17
.emacs.d/eln-cache/28.2-8ab3e389/url-history-a9b2f6e8-bfe8d526.eln
Also users needn't wonder why their computer's fan is running,
and look and find
$ top
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
2736 jidanni 20 0 445720 337488 61184 R 100.0 2.1 0:21.62 emacs
that's it's emacs to blame...
$ pstree -alu
| `-emacs,2418
| |-aspell,2624 -a -m -d en_US --encoding=utf-8
| |-emacs,2813 -no-comp-spawn --batch -l
/tmp/emacs-async-comp-nnmh.el-nuDBgd.el
| |-{emacs},2419
| |-{emacs},2420
| |-{emacs},2421
| `-{emacs},2422
M-x list-processes
Compiling: /usr/share/emacs/28.2/lisp/gnus/gnus-sum.el.gz 2685run
*Async-native-compile-log* /dev/pts/1 Main /usr/bin/emacs
-no-comp-spawn --batch -l /tmp/emacs-async-comp-gnus-sum.el-S4iRQb.el
ispell 2624run ---- Main
aspell -a -m -d en_US --encoding=utf-8
server -- listen ---- Main
(network server on /run/user/1000/emacs/server)
Bug#1030129: (no subject)
Can this bug be backported to stable?
Bug#1042831: gmt-gshhg-data Recommends files aready included by the Depends
Package: gmt Version: 6.4.0+dfsg-2+b1 Severity: minor We see: Depends: gmt-common (= 6.4.0+dfsg-2), libc6 (>= 2.35), libgmt6 (>= 6.4.0), libnetcdf19 (>= 3.6.1) Recommends: gmt-gshhg-data | gmt-gshhg-low, gmt-dcw But aren't all the gmt-gshhg-data Recommends files already included by the Depends? $ dlocate --filename-only /binned|xargs ls -og|rev|sort|rev -rw-r--r-- 1 136598 2017-06-14 /usr/share/gmt-gshhg/binned_GSHHS_c.nc -rw-r--r-- 1 136598 2017-06-14 /usr/share/gmt/coast/binned_GSHHS_c.nc -rw-r--r-- 160813 2017-06-14 /usr/share/gmt-gshhg/binned_border_c.nc -rw-r--r-- 160813 2017-06-14 /usr/share/gmt/coast/binned_border_c.nc -rw-r--r-- 1 229095 2017-06-14 /usr/share/gmt-gshhg/binned_river_c.nc -rw-r--r-- 1 229095 2017-06-14 /usr/share/gmt/coast/binned_river_c.nc -rw-r--r-- 1 31935651 2017-06-14 /usr/share/gmt/coast/binned_GSHHS_f.nc -rw-r--r-- 1 2131261 2017-06-14 /usr/share/gmt/coast/binned_border_f.nc -rw-r--r-- 1 7619434 2017-06-14 /usr/share/gmt/coast/binned_river_f.nc -rw-r--r-- 1 8437674 2017-06-14 /usr/share/gmt/coast/binned_GSHHS_h.nc -rw-r--r-- 1 509728 2017-06-14 /usr/share/gmt/coast/binned_border_h.nc -rw-r--r-- 1 2266940 2017-06-14 /usr/share/gmt/coast/binned_river_h.nc -rw-r--r-- 1 2206533 2017-06-14 /usr/share/gmt-gshhg/binned_GSHHS_i.nc -rw-r--r-- 1 2206533 2017-06-14 /usr/share/gmt/coast/binned_GSHHS_i.nc -rw-r--r-- 1 217433 2017-06-14 /usr/share/gmt-gshhg/binned_border_i.nc -rw-r--r-- 1 217433 2017-06-14 /usr/share/gmt/coast/binned_border_i.nc -rw-r--r-- 1 908481 2017-06-14 /usr/share/gmt-gshhg/binned_river_i.nc -rw-r--r-- 1 908481 2017-06-14 /usr/share/gmt/coast/binned_river_i.nc -rw-r--r-- 1 550248 2017-06-14 /usr/share/gmt-gshhg/binned_GSHHS_l.nc -rw-r--r-- 1 550248 2017-06-14 /usr/share/gmt/coast/binned_GSHHS_l.nc -rw-r--r-- 198738 2017-06-14 /usr/share/gmt-gshhg/binned_border_l.nc -rw-r--r-- 198738 2017-06-14 /usr/share/gmt/coast/binned_border_l.nc -rw-r--r-- 1 364773 2017-06-14 /usr/share/gmt-gshhg/binned_river_l.nc -rw-r--r-- 1 364773 2017-06-14 /usr/share/gmt/coast/binned_river_l.nc And installing higher resolutions wouldn't make any point, as they are already installed.
Bug#1042012: Thanks
Thank you for the clarification and quick response.
Bug#1042012: libqt6opengl6-dev unavailable in debian unstable
Package: qt6-base-dev Version: 6.4.2+dfsg-16 Severity: grave Justification: renders package unusable libqt6opengl6-dev has been unavailable in sid for a bit now. The last available version was 6.4.2+dfsg-11 (which cannot be installed now due to version conflicts). -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.4-3-siduction-amd64 (SMP w/12 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 qt6-base-dev depends on: ii libgl-dev 1.6.0-1 ii libglx-dev 1.6.0-1 ii libopengl-dev 1.6.0-1 ii libqt6concurrent6 6.4.2+dfsg-16 ii libqt6core6 6.4.2+dfsg-16 ii libqt6dbus6 6.4.2+dfsg-16 ii libqt6gui6 6.4.2+dfsg-16 ii libqt6network6 6.4.2+dfsg-16 ii libqt6openglwidgets6 6.4.2+dfsg-16 ii libqt6printsupport6 6.4.2+dfsg-16 ii libqt6sql6 6.4.2+dfsg-16 ii libqt6test6 6.4.2+dfsg-16 ii libqt6widgets6 6.4.2+dfsg-16 ii libqt6xml6 6.4.2+dfsg-16 ii libvulkan-dev 1.3.250.0-1 ii qmake6 6.4.2+dfsg-16 ii qt6-base-dev-tools 6.4.2+dfsg-16 ii qt6-qpa-plugins 6.4.2+dfsg-16 qt6-base-dev recommends no packages. qt6-base-dev suggests no packages. -- no debconf information
Bug#1041767: Leaving .emacs.d/eln-cache on users disks not environmentally sound
All I know is based on https://emacs.stackexchange.com/questions/71825/how-often-should-emacs-28-1-native-compile-basic-emacs-files and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041767 I am not even sure that these files piling up in individual Debian users' $HOME/.emacs.d/eln-cache/28.2-* and never getting deleted should be piling up there in the first place. As far as "native-compile-prune-cache", that is not something regular users know how to find or use. Anyway, this is like some big oil spill.
Bug#1041770: systemctl preset failed on greetd.service: No such file or directory
Package: greetd Version: 0.9.0-3 Unpacking greetd (0.9.0-3) ... Setting up greetd (0.9.0-3) ... Failed to preset unit, file "/etc/systemd/system/display-manager.service" already exists and is a symlink to "/lib/systemd/system/xdm.service". /usr/bin/deb-systemd-helper: error: systemctl preset failed on greetd.service: No such file or directory
Bug#1041768: start-stop-daemon: pid value must be a number greater than 0
Package: xdm Version: 1:1.1.11-3+b2 # dpkg-reconfigure xdm #and then chose xdm. Then we see: start-stop-daemon: pid value must be a number greater than 0 Try 'start-stop-daemon --help' for more information.
Bug#1041767: Subject: eln-cache piling up
Package: emacs-bin-common Version: 1:28.2+1-15 These are piling up on user's disks, $ du -sh .emacs.d/eln-cache/* 4.0K.emacs.d/eln-cache/28.2-43f520ab 19M .emacs.d/eln-cache/28.2-467432cd 4.0K.emacs.d/eln-cache/28.2-7a6329ed 23M .emacs.d/eln-cache/28.2-8ab3e389 31M .emacs.d/eln-cache/28.2-e4556eb6 26M .emacs.d/eln-cache/28.2-fd960886 with no cleaning happening. https://gitlab.alpinelinux.org/alpine/aports/-/issues/13684 mentions it might be some flag left on during compiling.
Bug#1040633: pilkit autopkg tests fail with pillow 10.0.0
Upstream proposal resolves this: https://github.com/matthewwithanm/pilkit/pull/66/commits/e2eb73e1798865a201e570fced0bac195b2a590c -Dan
