Bug#1072573: rpc.idmapd runs out of file descriptors
Package: nfs-common
Version: 2.6.2-4
Severity: important
Tags: patch upstream
On some of our bookworm systems I've seen what looked like a file descriptor
leak. Sample lsof output:
[...]
rpc.idmap 675 root 126r DIR 0,400 10813
/run/rpc_pipefs/nfs/clnt11e6 (deleted)
rpc.idmap 675 root 127u FIFO 0,40 0t0 10817
/run/rpc_pipefs/nfs/clnt11e6/idmap (deleted)
rpc.idmap 675 root 128r DIR 0,400 10834
/run/rpc_pipefs/nfs/clnt11ef (deleted)
rpc.idmap 675 root 129u FIFO 0,40 0t0 10838
/run/rpc_pipefs/nfs/clnt11ef/idmap (deleted)
rpc.idmap 675 root 130r DIR 0,400 10855
/run/rpc_pipefs/nfs/clnt11f8 (deleted)
rpc.idmap 675 root 131u FIFO 0,40 0t0 10859
/run/rpc_pipefs/nfs/clnt11f8/idmap (deleted)
Cranking up the verbosity level to 3 showed that dirscancb never reaps stale
entries in its queue (no "Stale client" lines). The reason turns out to be that
the scan terminates on the first directory entry that doesn't contain an
"idmap" file. Applying the attached patch seems to have solved the problem for
me.
As far as I can tell the bug is still present upstream, and has been for many
years (that "goto out" is from 2007 and replaced a "return" so the bug is even
older than that).
Marking "important" since this has actually caused observable problems in our
environment.From: Sergio Gelato
Date: Tue, 4 Jun 2024 16:02:59 +0200
Subject: rpc.idmapd: nfsopen() failures should not be fatal
dirscancb() loops over all clnt* subdirectories of /run/rpc_pipefs/nfs/.
Some of these directories contain /idmap files, others don't. nfsopen()
returns -1 for the latter; we then want to skip the directory, not abort
the entire scan.
---
utils/idmapd/idmapd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils/idmapd/idmapd.c b/utils/idmapd/idmapd.c
index e79c124..f3c540d 100644
--- a/utils/idmapd/idmapd.c
+++ b/utils/idmapd/idmapd.c
@@ -556,7 +556,7 @@ dirscancb(int fd, short UNUSED(which), void *data)
if (nfsopen(ic) == -1) {
close(ic->ic_dirfd);
free(ic);
-goto out;
+continue;
}
if (verbose > 2)
Bug#1007213: please upgrade to Xpra 5
control: retitle -1 please upgrade to Xpra 5 Xpra 3 and 4 are EOL (since August 2023); see https://github.com/Xpra-org/xpra/wiki/Versions
Bug#1006344: rasdaemon: inconsistent /var/lib/rasdaemon permissions between upgraded and new installs
In addition, since /var/lib/rasdaemon is no longer in the package's file list it may need to be explicitly removed by the postrm script.
Bug#1037410: libfuse3-3: always warns "Ignoring invalid max threads value 4294967295 > max (100000)." by default
control: tags -1 + fixed-upstream This was fixed in upstream commit 2da03e389866835e29b78a4546c6f1f87aab8fe1 , first released in version 3.14.1.
Bug#1041521: OpenSSH: problematic interaction between GSSAPI Key Exchange and publickey in 8.9p1 and newer
Source: openssh Version: 1:9.2p1-2 Symptom: ssh fails with "sign_and_send_pubkey: internal error: initial hostkey not recorded". This issue was reported upstream in https://bugzilla.mindrot.org/show_bug.cgi?id=3406 and rejected because it's a flaw in the GSSAPI key exchange patch. However, Damien Miller was kind enough to provide a hint in Comment 2. To trigger it, one needs to (a) perform a successful GSSAPI key exchange, (b) attempt public key authentication. (In addition, the client and the server must both have the hostbound authentication protocol extension enabled for the problem to manifest itself. This is on by default in bookworm.) This is probably not a very common combination, but it can happen if one has Kerberos credentials for the correct realm but the wrong user, and a private key for the right user. I suppose an ambitious developer might try to provide a functional equivalent to the host key binding that leverages the GSSAPI key exchange, instead of Damien Miller's one-statement suggestion. A likely workaround for affected clients until this gets fixed is to set pubkeyauthentication=unbound as needed.
Bug#1040767: facter: inconsistent detection of Xen dom0
systemd has a similar issue, tracked in #1038901. (Maybe one should ask the virt-what maintainers whether they agree with https://github.com/systemd/systemd/issues/28113#issuecomment-1621986461, in which case this bug can be reassigned to virt-what.)
Bug#1040767: facter: inconsistent detection of Xen dom0
Package: facter Version: 4.3.0-2 On recent amd64 hardware (I haven't tested on ARM), and if the "virt-what" package is installed, "facter virtual is_virtual" in a Xen dom0 returns "virtual => xenhvm" and "is_virtual => true". On some older hardware it returns "virtual => xen0" and "is_virtual => false". If I uninstall the "virt-what" package it returns "virtual => xen0" and "is_virtual => false" on both old and new hardware. Is this a bug in facter or in virt-what? Formally, a Xen dom0 is indeed a virtual machine, albeit a rather special one, and virt-what only reports (faithfully, as far as I could see) what it gets from the cpuid instruction; so the problem, in my view, is rather how facter makes use of the information from virt-what. In practice, I prefer for the dom0 to have is_virtual => false since I use is_virtual to decide on such things as whether to install intel-microcode (which doesn't really make sense in a guest domain). I could live with "virtual => xen0, is_virtual => true" since that also lets me single out the dom0. "virtual => xenhvm" for the dom0, on the other hand, doesn't give me enough information. There are also differences in behavior with and without virt-what in a PVH domU. With virt-what I get "virtual => xen" instead of "virtual => xenu". (The underlying hardware doesn't seem to play a role here.)
Bug#1033936: fwupd: FuEngine failed to get releases for UEFI dbx ... requires >= 1.8.14
This probably even affects sid, as it only has version 1.8.12. I would also like for fwupd updates to be distributed via -updates just like tzdata, clamav, etc.
Bug#1023240: firmware-iwlwifi: iwlwifi-so-a0-gf-a0-72.ucode possibly missing
It was added to linux-firmware.git after 2022-10-12, should be in 20221109: commit 06dbfbc74388a2e9a7228f4215b884a3139ece56 Author: Gregory Greenman Date: Wed Oct 26 12:15:12 2022 +0300 iwlwifi: add new FWs from core69-81 release Add the -69.ucode firmwares for the currently supported hardware. This is not the latest core, but we didn't send it before and it still can be useful. I'll check tomorrow whether it will cure the errors I'm getting with kernel 5.19.11-1~bpo11+1 on an AX211 with -71.ucode (regression from 5.18.16-1~bpo11+1 which works on the same hardware/firmware combo).
Bug#1008589: /usr/share/gtksourceview-4/language-specs/latex.lang: style 'def:text' not defined
Package: libgtksourceview-4-common Version: 4.8.0-1 Severity: minor Tags: fixed-upstream Seen in logs: gedit[3022041]: in file /usr/share/gtksourceview-4/language-specs/latex.lang: style 'def:text' not defined Upstream commit 1b6afe1c "language-specs: add 'text' to def.lang" addresses this but has not been cherry-picked into the 4.8 branch.
Bug#1003932: fwupd: GLib g_bytes_get_data: assertion 'bytes != NULL' failed
Package: fwupd Version: 1.5.7-4 On one machine (this may be hardware-dependent; the system in question is a Dell Precision 3450 with BIOS version 1.2.3) fwupd logs the message GLib g_bytes_get_data: assertion 'bytes != NULL' failed exactly 16 times, twice a day (coinciding with activations of fwupd-refresh.service, regardless of whether new metadata is available). I guess this means that some calls to g_bytes_get_data() are missing a guard against the possibility that the first argument is null. (The second argument is allowed to be null according to the documentation and isn't called "bytes".)
Bug#1003647: openafs-client.service uses deprecated KillMode=none
Package: openafs-client Version: 1.8.6-5 (Still unfixed on salsa.debian.org as far as I can tell.) On a bullseye system, systemd[1] now issues the following warning: systemd[1]: /lib/systemd/system/openafs-client.service:22: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. I don't know what the timescale is for removing KillMode=none, but one may want to start exploring alternatives. (Perhaps KillMode=mixed with SendSIGKILL=no ? There may be better solutions, though.)
Bug#1003457: noisy fwupd error messages with (disabled) TPM 1.2
Package: fwupd Version: 1.5.7-4 fwupd[150732]: ERROR:sys:src/tss2-sys/api/Tss2_Sys_Execute.c:110:Tss2_Sys_ExecuteFinish() Unsupported device. The device is a TPM 1.2 fwupd[150732]: ERROR:esys:src/tss2-esys/api/Esys_Startup.c:216:Esys_Startup_Finish() Received a non-TPM Error fwupd[150732]: ERROR:esys:src/tss2-esys/api/Esys_Startup.c:78:Esys_Startup() Esys Finish ErrorCode (0x00080001) fwupd[150732]: 05:40:45:0110 FuEngine failed to add device (null): failed to initialize TPM The hardware is what it is (old, vendor no longer provides BIOS updates, fwupd may still be useful for firmware updates on peripherals), but surely fwupd could be handling this more elegantly? Possibly relevant information from the kernel on this system: kernel: [ 10.755156] tpm_tis 00:07: 1.2 TPM (device-id 0xB, rev-id 16) kernel: [ 10.803696] tpm tpm0: TPM is disabled/deactivated (0x7)
Bug#974616: nomacs: "charset=Ascii" appears before the comment of the image
Control: tags -1 + upstream This *is* an upstream bug, as the upstream README.md has build instructions for Ubuntu that list libexiv2-dev (no version constraint given) as a required package. As far as I can tell, it's unaddressed as of the current tip of the master branch. I don't see that anyone has reported it as an issue on GitHub either. (I don't want a GitHub account, so I won't report it myself.) My only interest in this bug is that it has kept nomacs out of bullseye; I don't need its EXIF support. If this package isn't effectively orphaned, perhaps the maintainer can lower the bug's severity? (And/or forward the report upstream...)
Bug#1002013: Regression: IPMIEVD_OPTIONS was removed, served a purpose
Package: ipmitool Version: 1.8.18-10.1 Severity: important The changelog for 1.8.18-7 mentions * Remove not longer needed debian/ipmitool.ipmievd.default (Closes: #907832). - New debian/ipmitool.maintscript to remove /etc/default/ipmitool. - Add IPMIEVD_OPTIONS from /etc/default/ipmitool into debian/ipmitool.ipmievd.service. Unfortunately, that last change was done by hard-coding the default value "open daemon" into the ExecStart line of the systemd service unit, with no convenient way to customise it. Some hardware requires "sel daemon" instead; on such systems ipmievd breaks on upgrade from buster to bullseye.
Bug#859388: duplicate of #946882 (fixed in bullseye)
control: fixed -1 2.03.11-2.1 It looks like bug #946882 was a duplicate of this one. Marking as fixed and leaving it for the maintainer to mark as done when he sees fit.
Bug#991140: memory leak in krb5_gss_inquire_cred()
Package: libgssapi-krb5-2 Version: 1.17-3+deb10u1 Severity: normal Tags: patch upstream I have recently stumbled upon a resource leak in this library. Here is my one-line patch for it. As far as I can tell the problem was introduced ten years ago and is still present in the latest upstream version. I have tested this patch and it does seem to plug the leak I found. Author: Sergio Gelato Date: Wed Jul 14 20:21:29 UTC 2021 Subject: Plug leak in krb5_gss_inquire_cred Commit 1cd2821c19b2b95e39d5fc2f451a035585a40fa5 added an assignment to cred_handle but didn't update the cleanup code accordingly. This results in a leak on every call with GSS_C_NO_CREDENTIAL. We solve this by analogy with the changes to krb5_gss_init_sec_context_ext() and to the error cleanup block of krb5_gss_inquire_cred() by the same commit. Index: krb5-1.17/src/lib/gssapi/krb5/inq_cred.c === --- krb5-1.17.orig/src/lib/gssapi/krb5/inq_cred.c 2019-01-08 17:02:37.0 +0100 +++ krb5-1.17/src/lib/gssapi/krb5/inq_cred.c 2021-07-14 22:19:40.022773499 +0200 @@ -197,8 +197,7 @@ mechs = GSS_C_NO_OID_SET; } -if (cred_handle == GSS_C_NO_CREDENTIAL) -krb5_gss_release_cred(minor_status, (gss_cred_id_t *)&cred); +krb5_gss_release_cred(minor_status, &defcred); krb5_free_context(context); *minor_status = 0;
Bug#837907: stat() hangs on a particular file
* Salvatore Bonaccorso [2021-05-09 22:37:02 +0200]: > Control: tags -1 + moreinfo > > Do you still can reproduce the issue with a recent kernel? No, I haven't seen it in a while (and never with 4.9 or 4.19 either; nor with 5.10 but that's statistically less significant).
Bug#979151: live-build: installer_debian-installer script needs to support xz compression
* Roland Clobus [2021-01-03 19:07:32 +0100]: > Can you provide the command line to 'lb config' that you used to find > this issue? That would help in reproducing this issue. The key option is --debian-installer-distribution buster-backports (and/or --parent-debian-installer-distribution buster-backports ; I'm using both). This points lb installer_debian-installer to deb.debian.org/debian/dists/buster-backports/main/debian-installer/binary-amd64/Packages.gz which doesn't exist. (Patching the script to download Packages.xz and run unxz instead of gunzip was good enough for me as a quick workaround, though I guess it may be better to move the decompression logic into Download_file().) Of course this is not enough: one also needs a d-i image built with a kernel from buster-backports. I rolled my own (based on the 10.7 point release) and am also passing --mirror-debian-installer http://localhost . If you're willing to ignore the ABI mismatch between the kernel and the udebs you could just use a copy of the dists/buster/main/installer-amd64/ files, renaming the directory to dists/buster-backports ditto. Other options include --distribution buster --debian-installer live , and I'm pinning linux-image-* linux-headers-* firmware-* wireless-regdb from buster-backports to priority 600. In case you wonder, using the daily snapshots of d-i was an exercise in frustration the past couple of days due to the 5.10 kernel having just made it into sid. But even after patching installer_debian-installer to use snapshot.debian.org (this could form the basis for a feature enhancement to live-build, by the way) I ran into issues with debootstrap. That's why I chose to stay closer to the buster release. I see that dists/sid still offers both Packages.gz and Packages.xz. So at the moment it's only the buster-backports repository that has dropped support for gz.
Bug#979151: live-build: installer_debian-installer script needs to support xz compression
Package: live-build Version: 1:20191221 (Apparently not fixed as of commit 037e93fe which is the current head of the master branch.) https://wiki.debian.org/DebianRepository/Format#Compression_of_indices says: "Clients must support xz compression, and must support gzip and bzip2 if they want to use the files that are listed as usual use cases of these formats. Support for all three formats is highly recommended, as gzip and bzip2 are historically more widespread." scripts/build/installer_debian-installer currently only tries to download Packages.gz. This breaks when pointing to a udeb repository (e.g., buster-backports) that only provides Packages.xz.
Bug#975669: xpra.os_util.is_systemd_pid1() returns False on systemd
control: found -1 3.0.4+dfsg1-1~bpo10+1 On Wed, Nov 25, 2020 at 02:57:45PM +1100, Dmitry Smirnov wrote: > On Wednesday, 25 November 2020 7:47:33 AM AEDT Sergio Gelato wrote: > > Package: xpra > > Version: 2.4.3+dfsg1-1 > > Thanks for report. However this version is obsolete and the problem is most > certainly fixed in newer release. I recommend to upgrade to version from > "buster-backports" as I hope it may have the fix already... As I mentioned parenthetically in the original report, the same flawed detection code is on upstream svn trunk. I've also checked that it is still called from xpra/scripts/main.py in a relevant way. As far as I can tell it affects all versions so far. I have explicitly checked 3.0.4: $ python3 Python 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from xpra.os_util import is_systemd_pid1 >>> is_systemd_pid1() False >>> $ head -1 /proc/1/status Name: systemd $ xpra --version xpra v3.0.4-r24778 I now also have a suggested fix: read /proc/1/status and look for a line matching ^Name:[[:space:]]+systemd$ (or whatever the proper regexp syntax is) instead of /proc/1/cmdline which may read /sbin/init even on systemd.
Bug#975669: xpra.os_util.is_systemd_pid1() returns False on systemd
Package: xpra Version: 2.4.3+dfsg1-1 (The same code is in upstream svn trunk.) Consider this: $ python Python 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from xpra.os_util import is_systemd_pid1 >>> is_systemd_pid1() False >>> $ cat /proc/1/cmdline /sbin/init$ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Apr 27 2020 /sbin/init -> /lib/systemd/systemd* The test is confused by the symlink and returns a false negative. I had been wondering why systemd-run wasn't being used even if I explicitly asked for it. Fix with caution, as doing so may expose latent bugs.
Bug#974432: xfce4-notifyd fails to start in ssh session; long timeout
Package: xfce4-notifyd Version: 0.4.3-1 Severity: normal (Possibly related to #899377, but that report isn't about remote sessions.) When dbus-daemon tries to start xfce4-notifyd from within an ssh session (with X forwarding), this fails after a 2-minute timeout. Typical log entries: Nov 11 16:57:49 HOST systemd[18064]: Starting XFCE notifications service... Nov 11 16:57:49 HOST xfce4-notifyd[32729]: Unable to init server: Could not connect: Connection refused Nov 11 16:57:49 HOST xfce4-notifyd[32729]: cannot open display: Nov 11 16:57:49 HOST systemd[18064]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE Nov 11 16:57:49 HOST systemd[18064]: xfce4-notifyd.service: Failed with result 'exit-code'. Nov 11 16:57:49 HOST systemd[18064]: Failed to start XFCE notifications service. Nov 11 16:59:49 HOST dbus-daemon[32186]: [session uid=UID pid=32186] Failed to activate service 'org.freedesktop.Notifications': timed out (service_start_timeout=12ms) In this example, the startup attempt was triggered with notify-send test (which hangs until the timeout) but I've also seen this triggered by other activity. These are fairly ordinary buster systems, with (in particular) libgtk-3-0 version 3.24.5-1. systemd-cgls shows this dbus-daemon as running as part of dbus.service in the user slice, with the following arguments: /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only I believe this to be normal (I didn't tweak the configuration in this respect) but wonder how daemons in the user slice are supposed to choose between the displays of the user's various active sessions. Still, this bug report is specifically about xfce4-notifyd not handling this more gracefully (e.g., by just going into headless, do-not-disturb mode if no sensible screen can be found; or at the very least by bailing out quickly and quietly rather than after two minutes), not about the flaws of dbus-daemon or systemd (or possibly ssh, if one thinks D-Bus should be forwarded).
Bug#919460: Bug#919460: xen: disk I/O problems on stretch PV guest restores after security update
No, it did not happen again, at least not to me (and I've since upgraded to buster and Xen 4.11), and if no one else has run into it either it's probably not worth continued attention. In particular, it's unlikely to have been a regression triggered by the +deb9u11 security update.
Bug#971798: Regression: lockPref no longer recognised in .js files
* Carsten Schoenert [2020-10-07 14:29:31 +0200]: > Am 07.10.20 um 13:47 schrieb Sergio Gelato: > > Commit a21b649 (first included in 1:77.0~b1-1) silently changed the > > spelling of lockPref to lock_pref . > > Are you sure? Sorry, wrong commit. It was actually e7a23ec5 two months earlier. Anyway, this is a change to debian/patches/fixes/Allow-.js-preference-files-to-set-locked-prefs-with-lockP.patch which looks at least superficially as a Debian-specific change (I couldn't find the patch queue branch and dig into the history any further).
Bug#971798: Regression: lockPref no longer recognised in .js files
Package: thunderbird Version: 1:78.3.1-2~deb10u2 Commit a21b649 (first included in 1:77.0~b1-1) silently changed the spelling of lockPref to lock_pref . This breaking change doesn't seem to have been documented anywhere: not in debian/changelog, not in debian/thunderbird.NEWS. Moreover, it looks like parts of the test suite (e.g., extensions/pref/autoconfig/test/unit/autoconfig-all.cfg) are still referencing the old spelling. Are these files being used? The most annoying implication of this change is that custom .js files must be updated at the same time as Thunderbird itself. It would have been more convenient if both spellings had been allowed during a transition period.
Bug#966489: /usr/lib/tmpfiles.d/vsftpd.conf references /var/run
Package: vsftpd Version: 3.0.3-12 The log message says it all: [/usr/lib/tmpfiles.d/vsftpd.conf:1] Line references path below legacy directory /var/run/, updating /var/run/vsftpd/empty → /run/vsftpd/empty; please update the tmpfiles.d/ drop-in file accordingly.
Bug#963962: Update: /etc/grub.d/20_linux_xen
Some minor additions: 1. It turns out #924360 is no longer a concern. Not that I can see, anyway. 2. This is what I get when trying to boot from the .efi entry: -- Loading Xen 4.11-amd64.efi ...Loading Xen 4.11-amd64.efi ... error: invalid arch-dependent ELF magic. error: invalid arch-dependent ELF magic. Loading Linux 4.19.0-9-amd64 ...Loading Linux 4.19.0-9-amd64 ... error: you need to load the kernel first. error: you need to load the kernel first. Loading initial ramdisk ...Loading initial ramdisk ... error: you need to load the kernel first. error: you need to load the kernel first. Press any key to continue...Press any key to continue... -- So at this time I don't see a point in generating those .efi menu entries.
Bug#924360: Solved: ERR: Bootloader shutdown EFI x64 boot services!
The system I had encountered the problem on had been freshly upgraded from stretch. It turned out that while the GRUB *packages* had been upgraded, the boot loader in the EFI system partition was still from stretch. I had to explicitly grub-install --target=x86_64-efi After this, things are booting fine. So: GRUB issue, fixed in buster (but do pay attention to the version string on the GRUB menu screen at boot!)
Bug#924360: ERR: Bootloader shutdown EFI x64 boot services!
control: unmerge 924360 This is clearly not the same bug as #901599. (Not even in severity: #901599 does not prevent operation, while this bug requires a reset to recover from.) I can confirm #924360 on a Dell PowerEdge T330 with BIOS 2.9.0 (and 2.8.1). Seen as a Xen bug, it is a regression from stretch. I'm able to boot Xen 4.8 on the same hardware, using a buster (4.19.118-2+deb10u1) dom0 kernel. I'm inclined to think it's actually a GRUB issue, and wonder if it might not be hardware/firmware-dependent. I've read the discussion at https://lists.gt.net/xen/devel/497206 and it is clearly the bootloader (GRUB) that is shutting down EFI BS when it shouldn't. The reason Xen 4.8 is not affected is that it doesn't support Multiboot2 (the autogenerated menu entries in grub.cfg use multiboot/module instead of multiboot2/module2).
Bug#963962: /etc/grub.d/20_linux_xen generates non-functional menu entries
Package: grub-common Version: 2.02+dfsg1-20 Severity: normal xen-hypervisor-4.11-amd64 in buster installs the following files: /boot/xen-4.11-amd64.gz /boot/xen-4.11-amd64.efi /boot/xen-4.11-amd64.config The first one is bootable (usually; but see #924360). The second one may or may not be bootable by GRUB (I didn't succeed); it's probably meant for booting directly by UEFI. The third is just a summary of the hypervisor's build configuration and clearly not meant for booting. /etc/grub.d/20_linux_xen generates boot menu entries for all three. This seems excessive. The .config entry definitely shouldn't be there, and the .efi one does not work in its present form (although for all I know this may be fixable with better module settings). At the very least the .config file should be filtered out by file_is_not_sym(), grub_file_is_not_garbage() or similar. The .efi file clearly also requires attention but I'm not going to suggest a specific resolution yet. If GRUB can be made to boot it, maybe that would help solve #924360 on affected hardware; otherwise it would be better not to generate a menu entry for it (perhaps by not installing it in /boot, which would be a matter for the Debian Xen maintainers).
Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values
control: tags -1 + patch
* Philip Withnall [2020-06-15 23:25:18 +0200]:
> https://gitlab.gnome.org/GNOME/glib/-/issues/422
>
> Nobody has yet found time to work on it; merge requests are welcome!
Here is a patch that works for me.
Handle arbitrary binary data in extended attribute values.
It's safe to assume an escaped string doesn't contain embedded null bytes,
but raw memory buffers (as returned by getxattr()) require more care.
If the length of the data to be escaped is known, use that knowledge instead
of invoking strlen().
Also correct an off-by-one error in hex_unescape_string()'s computation of
the output string length.
--- a/gio/glocalfileinfo.c
+++ b/gio/glocalfileinfo.c
@@ -293,17 +293,15 @@
}
static char *
-hex_escape_string (const char *str,
+hex_escape_buffer (const char *str,
+ size_t len,
gboolean *free_return)
{
- int num_invalid, i;
+ size_t num_invalid, i;
char *escaped_str, *p;
unsigned char c;
static char *hex_digits = "0123456789abcdef";
- int len;
- len = strlen (str);
-
num_invalid = 0;
for (i = 0; i < len; i++)
{
@@ -340,6 +338,13 @@
}
static char *
+hex_escape_string (const char *str,
+ gboolean *free_return)
+{
+ return hex_escape_buffer (str, strlen(str), free_return);
+}
+
+static char *
hex_unescape_string (const char *str,
int*out_len,
gboolean *free_return)
@@ -377,10 +382,10 @@
else
*p++ = str[i];
}
- *p++ = 0;
-
if (out_len)
*out_len = p - unescaped_str;
+ *p++ = 0;
+
*free_return = TRUE;
return unescaped_str;
}
@@ -394,7 +399,7 @@
char *escaped_val;
gboolean free_escaped_val;
- escaped_val = hex_escape_string (value, &free_escaped_val);
+ escaped_val = hex_escape_buffer (value, len, &free_escaped_val);
g_file_info_set_attribute_string (info, gio_attr, escaped_val);
Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values
Package: libglib2.0-0
Version: 2.58.3-2+deb10u2
Severity: important
g_file_copy_attributes(), when invoked with G_FILE_COPY_ALL_METADATA on
files in NFS, is prone to truncating the value of extended attribute
system.nfs4_acl. Here is an excerpt from strace output, showing the
getxattr() and setxattr() calls:
getxattr("/home/xxx/a", "system.nfs4_acl", 0x7ffef8b54a20, 63) = -1 ERANGE
(Numerical result out of range)
getxattr("/home/xxx/a", "system.nfs4_acl", NULL, 0) = 80
getxattr("/home/xxx/a", "system.nfs4_acl",
"\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80) = 80
setxattr("/home/xxx/b", "system.nfs4_acl", "", 0, 0) = -1 EIO (Input/output
error)
Note how the attribute value was truncated from 80 bytes to 0. I believe this
is because the value starts with a 0 byte. gio/glocalfileinfo.c:escape_xattr()
does not make use of the len argument when computing escaped_val, but instead
invokes strlen() which is unsuitable for binary strings. A look at the latest
upstream version, 2.64.3, suggests the problem is still there.
This impacts such operations as "Save As" in evince.
Due to an unrelated bug I recommend running a recent kernel (e.g., 5.5 rather
than 4.19) when attempting to reproduce this problem.
Bug#961962: typo in /etc/cron.monthly/acct
Package: acct Version: 6.6.4-3 Severity: normal Tags: patch The latest commit, 83278eebd2d1caedfd4e664b2eff2972d5235341, introduced a regression by misspelling /var/log/wtmp.1.gz as /var/log/wtmp1.gz . The impact is probably minor since the default logrotate configuration does not compress wtmp after rotation. Patch attached. --- a/debian/acct.cron.monthly +++ b/debian/acct.cron.monthly @@ -27,7 +27,7 @@ # The script process the content of wtmp.1 or wtmp.1.gz (if one of them exists) # and also the data from current wtmp. -if test -f /var/log/wtmp.1 || test -f /var/log/wtmp1.gz; then +if test -f /var/log/wtmp.1 || test -f /var/log/wtmp.1.gz; then if [ -f /var/log/wtmp.1 ] then
Bug#961272: apt: inconsistent pinning behaviour
* Julian Andres Klode [2020-05-22 12:51:20 +0200]: > > You have pinned all versions of these packages to the same priority - 10, > > including the installed version. I'm wondering more why the other > > packages are kept back, I'd expect them to be upgraded too. Since they want to be upgraded to the version from backports, I assume they depend on newer versions of some libraries. > > What does policy say for them? Apart from the different package name, the same as for the ones that were going to be upgraded. > FWIW, as you want to emulate hold, the correct approach to do > that is to pin the installed version high: > > Package: ... > Pin: release a=now > Pin-Priority: 1001 Thank you for the suggestion. I don't see any mention of "a=now" in the apt_preferences(5) man page for buster.
Bug#961272: Acknowledgement (apt: inconsistent pinning behaviour)
control: severity -1 wishlist I've now seen the error of my ways. Downgrading the severity to "wishlist" since it appears to work as documented but not in the way I'd find most useful (and since there doesn't seem to be an "invalid" tag). My mistake was to specify the same positive priority for all versions of the pinned packages. This downgrades the priority of the installed version as well. The reason some packages were still not upgraded in the example shown is that the pinning allowed versions from backports to be considered, and some of these were then held back due to their own dependencies. What I'd like to have is a way to lower the priority of versions other than the one currently installed, without having to explicitly configure a version pattern. Yes, setting a hold on the package (or a negative pin priority) covers most of the associated use cases. Most but maybe not all?
Bug#961272: apt: inconsistent pinning behaviour
Package: apt Version: 1.8.2.1 I'm trying to pin some packages (nvidia stuff) the upgrade of which is best followed by an immediate reboot, so that I can upgrade the rest without waiting for a reboot window. I came up with the attached preferences configuration (based on the list of packages apt-get would otherwise try to upgrade on this system), and while it's definitely having some effect it seems that "apt-get upgrade" still wants to upgrade some of the pinned packages. I see no reason (neither good nor bad-but-documented) for this, so I call it a bug. (Aside about the use case: I've tried to use "apt-mark hold" instead, and that works, but puppet doesn't like package holds not implied by its own manifest and reacts by running "apt-get install", which fails noisily. I'm still looking for a reasonably painless solution.) Here is what "apt-get upgrade" prints out: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: libegl-nvidia0 libegl-nvidia0:i386 libegl1-nvidia libegl1-nvidia:i386 libgl1-nvidia-glx libgl1-nvidia-glx:i386 libgles-nvidia1 libgles-nvidia1:i386 libgles-nvidia2 libgles-nvidia2:i386 libnvidia-cfg1 libnvidia-eglcore libnvidia-eglcore:i386 libnvidia-glcore libnvidia-glcore:i386 libnvidia-glvkspirv libnvidia-glvkspirv:i386 libnvidia-ml1 nvidia-alternative nvidia-driver nvidia-driver-bin nvidia-driver-libs-nonglvnd nvidia-driver-libs-nonglvnd:i386 nvidia-driver-libs-nonglvnd-i386:i386 nvidia-kernel-dkms nvidia-kernel-support nvidia-nonglvnd-vulkan-icd nvidia-nonglvnd-vulkan-icd:i386 nvidia-vdpau-driver xserver-xorg-video-nvidia The following packages will be upgraded: nvidia-legacy-check nvidia-nonglvnd-vulkan-common 2 upgraded, 0 newly installed, 0 to remove and 30 not upgraded. Need to get 430 kB of archives. After this operation, 22.5 kB of additional disk space will be used. Do you want to continue? [Y/n] n Abort. Additional information: # apt-cache policy nvidia-legacy-check nvidia-legacy-check: Installed: 418.74-1 Candidate: 440.82-1~bpo10+1 Version table: 440.82-1~bpo10+1 10 100 http://deb.debian.org/debian buster-backports/non-free amd64 Packages 418.113-1 10 500 http://deb.debian.org/debian buster/non-free amd64 Packages *** 418.74-1 10 100 /var/lib/dpkg/status (and likewise for nvidia-nonglvnd-vulkan-common, nvidia-driver, etc.) Package: libegl-nvidia0 libegl-nvidia0:i386 libegl1-nvidia libegl1-nvidia:i386 libgl1-nvidia-glx libgl1-nvidia-glx:i386 libgles-nvidia1 libgles-nvidia1:i386 libgles-nvidia2 libgles-nvidia2:i386 libnvidia-cfg1 libnvidia-eglcore libnvidia-eglcore:i386 libnvidia-glcore libnvidia-glcore:i386 libnvidia-glvkspirv libnvidia-glvkspirv:i386 libnvidia-ml1 nvidia-alternative nvidia-driver nvidia-driver-bin nvidia-driver-libs-nonglvnd nvidia-driver-libs-nonglvnd:i386 nvidia-driver-libs-nonglvnd-i386:i386 nvidia-kernel-dkms nvidia-kernel-support nvidia-legacy-check nvidia-nonglvnd-vulkan-common nvidia-nonglvnd-vulkan-icd nvidia-nonglvnd-vulkan-icd:i386 nvidia-vdpau-driver xserver-xorg-video-nvidia Pin: version * Pin-Priority: 10
Bug#960437: libnfsidmap ignores [Mapping] section in idmapd.conf
Package: libnfsidmap Version: 0.25-5.1 Severity: normal Tags: fixed-upstream This version of libnfsidmap ignores the settings Nobody-User and Nobody-Group in the configuration file's [Mapping] section. This causes clients to show 4294967294 as the user or group under some circumstances (e.g., when none of the plugins listed in [Translation]Method provide name-to-id mappings for nobody@). This was fixed upstream in version 0.26 (dated 2014-08-13). The ChangeLog suggests that the implementation started diverging from the documentation in this respect on 2006-04-20.
Bug#952446: Please update to latest nfs-utils
When doing this (or sooner?), please also take over (and absorb) orphaned package libnfsidmap, the upstream for which was merged into nfs-utils three years ago.
Bug#959867: ifup kills dhclient on if-up.d script failure
Package: ifupdown Version: 0.8.35 Severity: important I've now run into this problem on several systems running buster. Whenever a script in /etc/network/if-up.d/ fails (see, e.g., #959864) the dhclient instance dies. This behaviour may actually predate buster, but is much more noticeable now that dhclient-script sets the interface's valid_lft to the actual, finite lifetime of the lease (cf. #834532). The result is that the system drops off the network when the initial DHCP lease expires. I'm not sure how well specified the behaviour of ifup is on script failure; I couldn't find it documented. Maybe this needs to be clarified? That's also why I've filed a bug against postfix, whose if-up.d script really shouldn't be failing so casually. Still, doing things halfway (killing dhclient but leaving the interface up) doesn't feel right. I'd rather deal with an immediate failure than with a delayed one. Here is information about the same incident as in #959864, but with a focus on ifup rather than postfix. From systemctl status: ● ifup@eno1.service - ifup for eno1 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since xx 11:56:04 UTC; x days ago Process: 713 ExecStart=/bin/sh -ec ifup --allow=hotplug eno1; ifquery --state eno1 (code=exited, status=1/FAILURE) Main PID: 713 (code=exited, status=1/FAILURE) 11:56:04 HOST dhclient[729]: DHCPACK of 192.168.1.68 from 192.168.1.67 11:56:04 HOST dhclient[729]: bound to 192.168.1.68 -- renewal in 11512 seconds. 11:56:04 HOST sh[713]: bound to 192.168.1.68 -- renewal in 11512 seconds. 11:56:04 HOST sh[713]: Sending network state change signal to nslcd...done. 11:56:04 HOST sh[713]: run-parts: /etc/network/if-up.d/postfix exited with return code 69 11:56:04 HOST sh[713]: ifup: failed to bring up eno1 11:56:04 HOST systemd[1]: ifup@eno1.service: Main process exited, code=exited, status=1/FAILURE 11:56:04 HOST systemd[1]: ifup@eno1.service: Failed with result 'exit-code'. From process accounting: dhclient-script |v3| 0.00| 0.00| 0.00| 0| 0| 2388.00| 0.00|1138|1131| F | 0|__ |xx 11:56:04 2020 dhclient-script |v3| 0.00| 0.00|23.00| 0| 0| 2388.00| 0.00|1131| 729| | 0|__ |xx 11:56:04 2020 dhclient|v3| 0.00| 0.00| 519.00| 0| 0| 8456.00| 0.00| 725| 723| | 0|__ |xx 11:55:59 2020 sh |v3| 0.00| 0.00| 519.00| 0| 0| 2388.00| 0.00| 723| 716| | 0|__ |xx 11:55:59 2020 postfix |v3| 0.00| 0.00| 0.00| 0| 0| 2388.00| 0.00|1219|1217| F | 0|__ |xx 11:56:04 2020 postqueue |v3| 1.00| 0.00| 3.00| 0| 0| 45576.00| 0.00|1222|1217| | 69|__ |xx 11:56:04 2020 postfix |v3| 0.00| 0.00| 4.00| 0| 0| 2388.00| 0.00|1217|1194| | 69|__ |xx 11:56:04 2020 run-parts |v3| 0.00| 0.00|13.00| 0| 0| 2284.00| 0.00|1194|1193| | 1|__ |xx 11:56:04 2020 sh |v3| 0.00| 0.00|13.00| 0| 0| 2388.00| 0.00|1193| 716| | 1|__ |xx 11:56:04 2020 ifup|v3| 0.00| 0.00| 533.00| 0| 0| 2344.00| 0.00| 716| 713| | 1|__ |xx 11:55:59 2020 sh |v3| 0.00| 0.00| 534.00| 0| 0| 2388.00| 0.00| 713| 1|S| 1|__ |xx 11:55:59 2020 dhclient|v3| 0.00| 0.00| 520.00| 0| 0| 11416.00| 0.00| 729| 1|SF X| 0|__ |xx 11:55:59 2020 Examination of the raw process accounting data (dump-acct doesn't print out this information) reveals that process 729 was killed by signal 15 (SIGTERM).
Bug#959864: /etc/network/if-up.d/postfix: postqueue fatal: mail system is down
Package: postfix Version: 3.4.8-0+10debu1 Severity: important (Severity due to the fact that the problem can lead to systemd killing dhclient on the interface, causing the system to lose network connectivity when the lease expires.) Seen intermittently at boot time on several systems running buster: 11:56:02 HOST postfix/postfix-script[1126]: starting the Postfix mail system 11:56:04 HOST postfix/postqueue[1222]: fatal: Cannot flush mail queue - mail system is down 11:56:04 HOST sh[713]: run-parts: /etc/network/if-up.d/postfix exited with return code 69 11:56:04 HOST sh[713]: ifup: failed to bring up eno1 11:56:04 HOST systemd[1]: ifup@eno1.service: Main process exited, code=exited, status=1/FAILURE 11:56:04 HOST systemd[1]: ifup@eno1.service: Failed with result 'exit-code'. 11:56:07 HOST postfix/master[1128]: daemon started -- version 3.4.8, configuration /etc/postfix This may seem odd since /etc/network/if-up.d/postfix explicitly checks the value of RUNNING before attempting a queue flush. However, that is based on when the master daemon has started and written its PID file, not on when the services needed by postqueue (qmgr, pickup) are actually up. With the help of process accounting records I can confirm that these two services weren't up until 11:56:05. So what is needed here is either a more precise test or increased tolerance of failures to flush the queue (or both). I think I'll just add an || true to that sendmail invocation line, although one may conceivably want to discriminate on the basis of the actual exit code.
Bug#956905: Cyrus SASL: please make NTLMv2 the default
Package: libsasl2-modules
Version: 2.1.27+dfsg-1+deb10u1
Severity: wishlist
Tags: patch
The NTLM plugin defaults to the less-secure v1 of the protocol, does not
support a way for clients to override this default (this is tracked upstream
as https://github.com/cyrusimap/cyrus-sasl/issues/574), and will not even
attempt v2 if v1 fails (e.g., due to it being disabled server-side).
As a workaround until a better fix is available, I've applied the attached
patch (which is a variation on the proof of concept at
https://access.redhat.com/solutions/4253821). Since in this day and age
it makes more sense to prefer NTLMv2 (if NTLM is to be used at all),
I'm submitting it for the maintainers' consideration.
Default to ntlm_v2=yes.
See https://github.com/cyrusimap/cyrus-sasl/issues/574 and
https://bugzilla.redhat.com/show_bug.cgi?id=1722159
We definitely should prefer NTLMv2 over v1.
--- a/plugins/ntlm.c
+++ b/plugins/ntlm.c
@@ -1993,7 +1993,7 @@
unsigned char hash[NTLM_HASH_LENGTH];
unsigned char resp[NTLM_RESP_LENGTH], *lm_resp = NULL, *nt_resp = NULL;
int result;
-const char *sendv2;
+const char *sendv2 = NULL;
if (!serverin || serverinlen < NTLM_TYPE2_MINSIZE ||
memcmp(serverin, NTLM_SIGNATURE, sizeof(NTLM_SIGNATURE)) ||
@@ -2065,7 +2065,7 @@
/* should we send a NTLMv2 response? */
params->utils->getopt(params->utils->getopt_context,
"NTLM", "ntlm_v2", &sendv2, NULL);
-if (sendv2 &&
+if (!sendv2 ||
(sendv2[0] == '1' || sendv2[0] == 'y' ||
(sendv2[0] == 'o' && sendv2[1] == 'n') || sendv2[0] == 't')) {
Bug#931772: [request-tracker-maintainers] Bug#931772: RT: On Create scrip ran but ticket not created
I agree that one should avoid forking RT unnecessarily. While I still think that the current behaviour is flawed, it hasn't been an urgent concern since I've addressed the performance issue that acted as a trigger in my environment. If it were, I (as a non-paying customer with correspondingly low support expectations) would probably either come up with a fix of my own or migrate to different software. I'd rather not be the one who brings this up in upstream's forum, though, as they require prior registration. But anyone else who feels this is worth pursuing is welcome to do so (and hopefully improve on my analysis: I didn't expend all that much thought on it).
Bug#953019: udev: unexpected network interface name changes on upgrade from stretch
* Michael Biebl [2020-03-03 14:34:37 +0100]: > > stretch# udevadm test-builtin net_id /sys/class/net/enp94s0f0 > > > ID_NET_NAME_PATH=enp94s0f0 > > ... > > > buster# udevadm test-builtin net_id /sys/class/net/ens1f0np0 > > > ID_NET_NAME_PATH=enp94s0f0np0 > > ID_NET_NAME_SLOT=ens1f0np0 > > > Are you using the same kernel? I've run "udevadm test-builtin net_id /sys/class/net/enp94s0f0" after "apt-get dist-upgrade" and before rebooting into the new kernel and seen the new values of ID_NET_NAME_PATH and ID_NET_NAME_SLOT. (I have several servers with this hardware configuration. I would not have known to check this the first time; this is an observation from the second upgrade.) > Do you get different names if you boot > your buster system with the stretch kernel? That I haven't tried yet. I have two more servers of this type to upgrade. For a quick test, I've now upgraded systemd from stretch-backports… # apt-get install --only-upgrade -t stretch-backports udev [...] The following additional packages will be installed: libpam-systemd libsystemd0 libsystemd0:i386 libudev1 systemd Suggested packages: systemd-container The following packages will be upgraded: libpam-systemd libsystemd0 libsystemd0:i386 libudev1 systemd udev 6 upgraded, 0 newly installed, 0 to remove and 193 not upgraded. [...] # udevadm test-builtin net_id /sys/class/net/enp94s0f0 Load module index Parsed configuration file /lib/systemd/network/99-default.link Created link configuration context. Using default interface naming scheme 'v240'. ID_NET_NAMING_SCHEME=v240 ID_NET_NAME_MAC=enxd09466xx ID_OUI_FROM_DATABASE=Dell Inc. ID_NET_NAME_PATH=enp94s0f0 ID_NET_NAME_SLOT=ens1f0 Unload module index Unloaded link configuration context. # reboot After the reboot into kernel 4.9.210-1, the new interface name is ens1f0. So the switch to the slot-based name follows the systemd upgrade, while the np0 suffix seems kernel-related.
Bug#953019: udev: unexpected network interface name changes on upgrade from stretch
Package: udev Version: 241-7~deb10u3 After upgrading a system from stretch to buster, the names of some network interfaces changed unexpectedly. Specifically: stretch# udevadm test-builtin net_id /sys/class/net/enp94s0f0 calling: test-builtin === trie on-disk === tool version: 232 file size: 8669279 bytes header size 80 bytes strings1850783 bytes nodes 6818416 bytes Load module index Found container virtualization none timestamp of '/etc/systemd/network' changed timestamp of '/lib/systemd/network' changed Parsed configuration file /lib/systemd/network/99-default.link Created link configuration context. ID_NET_NAME_MAC=enxd09466xx ID_NET_NAME_PATH=enp94s0f0 Unload module index Unloaded link configuration context. buster# udevadm test-builtin net_id /sys/class/net/ens1f0np0 Load module index Parsed configuration file /lib/systemd/network/99-default.link Created link configuration context. Using default interface naming scheme 'v240'. ID_NET_NAMING_SCHEME=v240 ID_NET_NAME_MAC=enxd09466xx ID_OUI_FROM_DATABASE=Dell Inc. ID_NET_NAME_PATH=enp94s0f0np0 ID_NET_NAME_SLOT=ens1f0np0 Unload module index Unloaded link configuration context. This is the same interface, as shown by the ID_NET_NAME_PATH values. Even if it weren't for the newly detected ID_NET_NAME_SLOT I think I would still have had to reconfigure things due to the extra np# suffix. I had serial console access so this was only a minor inconvenience, but how could I have avoided being surprised? Isn't predictability the main selling point for this interface naming scheme? Some hardware info: 5e:00.0 Ethernet controller [0200]: Broadcom Limited BCM57416 NetXtreme-E 10GBase-T RDMA Ethernet Controller [14e4:16d8] (rev 01) Handle 0x0901, DMI type 9, 17 bytes System Slot Information Designation: Mezzanine 1 Type: x8 PCI Express 3 Current Usage: In Use Length: Other ID: 1 Characteristics: 3.3 V is provided PME signal is supported Bus Address: :5e:00.0 Handle 0x, DMI type 0, 26 bytes BIOS Information Vendor: Dell Inc. Version: 2.4.8 Release Date: 11/27/2019 [...] Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: PowerEdge R440 [...]
Bug#864242: Review of propsed fix for /etc/cron.monthly/acct failure on recent installs
This bug is still present in buster. I'm not sure that the proposed fix will do the right thing if logrotate is not installed (which I think can happen, as logrotate is not a dependency of acct and only has priority important, not required). How about moving the "exit 0" to an else clause in the existing "if [-f /var/log/wtmp.1 ]" block?
Bug#922533: Review of proposed move of /var/log/account to /var/account
I'm looking at the proposed fix for this bug and have a few concerns. I hope they can be addressed before the next upload. 1. What about the possibility that /var/log and /var are different filesystems? The preinst may need some error checking to handle out-of-space conditions from mv, and the administrator needs to be warned in advance about the move (I think this calls at least for a mention in the release notes). Moreover, I'm not convinced that the currently proposed preinst script is idempotent (policy §6.2). How about adding a symbolic link from /var/account to /var/log/account on upgrade instead? 2. What happens if both /var/account and /var/log/account already exist? Is it really appropriate to try and clobber an existing /var/account without consulting the administrator? Again, consider the idempotency requirement. 3. I'm not sure offhand whether process accounting will be turned off while the preinst script is running. (The old prerm in buster only stops the acct service on remove, not on upgrade.) If not, there is a risk that accounting records will be written to the old location during the move. (At the same time, I'd like to keep any gap in process accounting coverage at a minimum; but this is a wish, not a requirement.)
Bug#867067: nfs-kernel-server: nfsdcltrack fails to init database
I have empirical reasons to believe that the fix for CVE-2019-3689 (cf. #940848) will take care of this bug as well.
Bug#924587: please add nfs-idmapd.service to nfs-client.target
Please don't. I'm running an NFSv4.1 environment with sec=krb5p and autofs-ldap just fine without this. The rpc.idmapd(8) man page says among other things: "Note that on more recent kernels only the NFSv4 server uses rpc.idmapd. The NFSv4 client instead uses nfsidmap(8), and only falls back to rpc.idmapd if there was a problem running the nfsidmap(8) program." (Aside: the libnfsidmap2 package mistakenly has the nfsidmap man page in section 5 rather than 8, in both stretch and buster (I haven't checked sid). Minor documentation bug.) This applies to Debian stretch and later. I'm not starting rpc.idmapd on client-only machines at all (the nfsidmap mechanism works for me) and home directories are reliably being automounted. This makes me believe that your proposed "fix" is incorrect (at least for general use; if you need to run an old/odd kernel you may need something like this, but then you should fix it locally in /etc/systemd/system/ and not impose it on everyone else). >From reading #842199 I get the impression that autofs is starting too soon, before the LDAP server can be reached. On my systems autofs.service has an effective After=nslcd.service which seems to be generated on the basis of an # X-Start-Before: autofs comment in /etc/init.d/nslcd (so you probably won't have this on systems without nslcd). There are many ways to influence the order in which systemd starts services; why pick on rpc.idmapd?
Bug#947000: Acknowledgement (xfce4-weather-plugin: moonset time not shown on no-moonrise days)
Here is the corresponding patch for sunrise and sunset, for the sake of
high-latitude users close to the middle of their time zone. Definitely
more of a corner case than the moonrise/moonset one.
The Sun may set today even though it last rose months ago.
For high-latitude locations, approximately once a year.
Index: xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c
===
--- xfce4-weather-plugin-0.8.11.orig/panel-plugin/weather-summary.c 2019-12-19 09:26:57.061048252 +0100
+++ xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c 2019-12-19 18:15:46.932435519 +0100
@@ -439,15 +439,16 @@
if (data->current_astro->sun_never_rises) {
value = g_strdup(_("\tSunrise:\t\tThe sun never rises today.\n"));
APPEND_TEXT_ITEM_REAL(value);
-} else if (data->current_astro->sun_never_sets) {
-value = g_strdup(_("\tSunset:\t\tThe sun never sets today.\n"));
-APPEND_TEXT_ITEM_REAL(value);
} else {
sunrise = format_date(data->current_astro->sunrise, NULL, FALSE);
value = g_strdup_printf(_("\tSunrise:\t\t%s\n"), sunrise);
g_free(sunrise);
APPEND_TEXT_ITEM_REAL(value);
-
+}
+if (data->current_astro->sun_never_sets) {
+value = g_strdup(_("\tSunset:\t\tThe sun never sets today.\n"));
+APPEND_TEXT_ITEM_REAL(value);
+} else {
sunset = format_date(data->current_astro->sunset, NULL, FALSE);
value = g_strdup_printf(_("\tSunset:\t\t%s\n\n"), sunset);
g_free(sunset);
Bug#925561: xfce4-weather-plugin uses deprecated API version
control: fixed -1 0.10.0-1 My eyes had glazed over last night, I hadn't noticed that 0.10.0 was already in sid. That supports the sunrise/2.0 API which this bug is about. Marking as fixed. > Alternatively, it may be enough to just replace /locationforecastlts/1.3 > with /locationforecast/1.9 in panel-plugin/weather.c and in README; will > test this next. Aside: I've tested this successfully. Not sure it's worth a bug report yet, as the old API is deprecated but still supported.
Bug#947000: xfce4-weather-plugin: moonset time not shown on no-moonrise days
Package: xfce4-weather-plugin
Version: 0.10.0-1
Tags: patch
A logic error causes the time the Moon sets not to be displayed if the Moon
doesn't also rise on the same day. Patch tested on 0.8.11, applies cleanly
to tip of upstream master branch.
Treat moon_never_rises and moon_never_sets independently of each other.
Unlike the Sun perhaps, the Moon may set but not rise on certain days.
Prior to this patch, the moonset time would be suppressed on no-moonrise days.
Index: xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c
===
--- xfce4-weather-plugin-0.8.11.orig/panel-plugin/weather-summary.c 2019-03-24 13:08:29.0 +0100
+++ xfce4-weather-plugin-0.8.11/panel-plugin/weather-summary.c 2019-12-19 09:26:57.061048252 +0100
@@ -466,16 +466,17 @@
value =
g_strdup(_("\tMoonrise:\tThe moon never rises today.\n"));
APPEND_TEXT_ITEM_REAL(value);
-} else if (data->current_astro->moon_never_sets) {
-value =
-g_strdup(_("\tMoonset:\tThe moon never sets today.\n"));
-APPEND_TEXT_ITEM_REAL(value);
} else {
moonrise = format_date(data->current_astro->moonrise, NULL, FALSE);
value = g_strdup_printf(_("\tMoonrise:\t%s\n"), moonrise);
g_free(moonrise);
APPEND_TEXT_ITEM_REAL(value);
-
+}
+if (data->current_astro->moon_never_sets) {
+value =
+g_strdup(_("\tMoonset:\tThe moon never sets today.\n"));
+APPEND_TEXT_ITEM_REAL(value);
+} else {
moonset = format_date(data->current_astro->moonset, NULL, FALSE);
value = g_strdup_printf(_("\tMoonset:\t%s\n"), moonset);
g_free(moonset);
Bug#925561: xfce4-weather-plugin uses deprecated API version
control: found -1 0.8.10-1 control: tags -1 + fixed-upstream I confirm that this is fixed in release 0.8.11 (the recommended upgrade from 0.8.10 for stable environments). Tested on buster amd64 (by copying the debian/ subdirectory from 0.8.10, adding a changelog entry, and rebuilding; no other changes were needed). HOWEVER, another API (LocationforecastLTS) is being end-of-lifed as of 2019-11-07. This (separate) bug (upstream #16268) is not yet fixed upstream, much less in 0.8.11. At the moment this only gives rise to warnings, with errors expected to start no earlier than 2020-02-07. I'd therefore suggest checking for the existence of a 0.8.12 before packaging 0.8.11 for buster-updates. (For sid one should consider the 0.10 branch or newer.) Alternatively, it may be enough to just replace /locationforecastlts/1.3 with /locationforecast/1.9 in panel-plugin/weather.c and in README; will test this next.
Bug#946981: debian/watch pattern matches ../ first
Package: xfce4-weather-plugin Version: 0.8.10-1 Tags: patch The debian/watch file for this package matches ../ ahead of the actual version subdirectories, leading to failure. Here is an excerpt of uscan's output: uscan info: Found the following matching directories (newest first): ../ (..) 0.10/ (0.10) 0.9/ (0.9) 0.8/ (0.8) 0.7/ (0.7) 0.6/ (0.6) 0.5/ (0.5) uscan info: newest_dir => '..' I'm attaching a new watch file with more restrictive patterns (require versions to begin with a digit). Also, the upstream distribution site now supports https. version=4 https://archive.xfce.org/src/panel-plugins/xfce4-weather-plugin/(\d[\d\.]*)/ \ xfce4-weather-plugin-(\d[\d\.]*)\.tar\.(?:gz|bz2)
Bug#946166: lightdm-gtk-greeter segfaults on hostname changes
Package: lightdm-gtk-greeter
Version: 2.0.6-1
This is a long-standing bug (see, e.g.,
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1422794
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1677058
https://bugzilla.redhat.com/show_bug.cgi?id=1399811
https://bugzilla.redhat.com/show_bug.cgi?id=1394472
) but still unfixed in buster (and upstream, I believe).
The symptom is a
lightdm-gtk-gre[920]: segfault at 10 ip 7f011974ecc0 sp 7ffe6f799768
error 4 in licairo.so.2.11600.0[7f01196eb000+cc000]
on the first login attempt after boot; the user ends up having to authenticate
twice. seat0-greeter.log mentions
Invalid MIT-MAGIC-COOKIE-1 key
[Background] Failed to create root pixmap
in that order. Setting a static hostname for the machine suppresses the problem.
As far as I can tell, the immediate cause for the segfault is a missing check
for src/greeterbackground.c:create_root_surface() returning NULL (which it does
here, as evidenced by the "Failed to create root pixmap" message). One could add
if (!surface) return;
in the obvious place in greeter_background_save_xroot() to avoid segfaulting at
this point. I wonder if one shouldn't also emit a more explicit hint ("has the
hostname changed?" or "see ") in the log when this happens.
This still won't address the Xauthority issue, though.
/var/run/lightdm/root/:0, created by lightdm and not by the greeter, apparently
contains a cookie for /unix:0 which is not being updated when the
hostname changes (e.g., due to DHCP activity after lightdm starts up). I'm
filing this report against the greeter due to the segfault, but feel free to
reassign/clone it to lightdm if need be.
I guess the reason this doesn't bite more people is that a static hostname is
usually set at installation time. The machine on which I had this issue was
installed from USB media, with the network connection non-functional during
installation (due to a Thunderbolt support bug in the 4.19 kernel, fixed in
5.3.9 and hopefully in 4.19.82; but I digress) and ended up using localhost as
the boot-time hostname.
Bug#826543: cupsd fails to remove job files at end of PreserveJobFiles interval
Earlier I pointed out that upstream commit [53cac1d08bba395942df638d74526470c9fc7975] Fix parentheses in cupsdCleanJobs isn't in buster. I've now given some more thought to the implications of this. In the typical case (default settings) job->history_time is INT_MAX. The misplaced parenthesis makes the code behave as if (1 < JobHistoryUpdate || !JobHistoryUpdate) JobHistoryUpdate = job->history_time; which means JobHistoryUpdate will nearly always be updated. It will therefore most likely (until 2038, anyway) end up with the file_time value of the last job in the array. I haven't checked how the jobs array is sorted; I think the code should avoid relying on a particular ordering. The correct result is of course the earliest file_time value of all jobs in the array, so the misplaced parenthesis could result in cleanup being unduly delayed. By the way, the way in which history_time and file_time are calculated in cupsdLoadJob() and cupsdUpdateJobs() could result in wraparound on platforms with signed 32-bit time_t. For plausible values of PreserveJobHistory and PreserveJobFiles this isn't going to bite until 2038 or maybe late 2037, but what if one now were to test with "1000w" on a 32-bit platform?
Bug#826543: cupsd fails to remove job files at end of PreserveJobFiles interval
Thank you for your reply. The issue I reported is distinct from upstream #5538 or Debian #921741 but the upstream patch does indeed seem to incorporate my suggested fix; I assume upstream independently spotted the same problem. Note that the original fix for #5538 had a misplaced right parenthesis, corrected in [53cac1d08bba395942df638d74526470c9fc7975] Fix parentheses in cupsdCleanJobs The latter patch is not in buster yet. (I should probably cherry-pick it for local use if you won't issue an update for buster.) As for testing again, the issue doesn't seem easy to trigger to begin with. I had deployed my suggested fix locally on jessie but not on stretch, and it hasn't come back to bite us. (I'm not saying it was never triggered, only that the spool never filled up again as a result. Unrelated changes to our printing infrastructure --- we no longer run a central CUPS server --- have probably helped.)
Bug#916470: rasdaemon: wrong homepage
This appears fixed in the Debian Package Tracker, which currently links to https://apps.fedoraproject.org/packages/rasdaemon . https://pagure.io/rasdaemon is a less useful choice, as it doesn't belong to upstream but to the Debian package maintainer. As of this writing the content looks stale (the newest commit is two years old, give or take a few weeks).
Bug#942405: rasdaemon: release 0.6.4 is out, fixes important bugs
Package: rasdaemon Version: 0.6.0-1.2 Severity: important Normally a "please catch up with upstream" bug would have severity wishlist, but in this instance the new release includes patches for several bugs that have seriously inconvenienced me (and possibly discouraged others from using this package). I'm thinking especially of [4bf0b71f] fix file descriptor leak in ras-report.c:setup_report_socket() [e4a8a6c5] parse_ras_data: flush trace buffer immediately, not on next call Of course the improved hardware support is also likely to be useful, along with all the other less important bug fixes. (E.g., I've been cherry-picking [0a16789f] rasdaemon: fix PCIe AER error type .)
Bug#941466: Sextractor - Rename package?
* Ole Streicher [2019-10-01 09:18:01 +0200]: > I personally completely agree that the name is offending and should be > changed. This should however happen in a coordinated way -- including > conda-forge and Fedora (and ideally upstream as well). I made a comment > on the conda-forge PR #8764. I don't find the name offensive. Some spam filters might (the "Scunthorpe problem"). Shall we also ban sexagesimal arithmetic? (OK, you wrote "offending". In this context that presumably means it goes against Debian policy. Which section of the Policy Manual?) > Note that we already renamed the executable name from "sex" to > "sextractor", which is something upstream would also agree. The issue is > to rename sextractor to source-extractor (or similar). If Debian policy requires it, go ahead. Otherwise I'd wait and see what upstream ends up doing. So far upstream seems disinclined to rename the package.
Bug#940028: launching d-i on multiple consoles doesn't play well with preseeding
Package: rootskel Version: 1.131 Severity: important I like to create Xen domU virtual machines using debian-installer, with preseeding for a no-questions-asked experience. This works well with stretch, but when I try to use buster images (from debian/dists/buster/main/installer-amd64/current/images/netboot/xen/ in the public repository) I find that I am being asked some questions (by localechooser) despite the preseeding. Moreover, the exact questions asked vary from run to run even if I make no changes to my setup. Occasionally I even get netcfg failures. >From the installer log I see that two instances of debian-installer are being run in parallel, one for each of the consoles hvc0 and tty0: Sep 10 10:02:13 reopen-console: Looking at console hvc0 from /proc/consoles Sep 10 10:02:13 reopen-console:Adding hvc0 to consoles list Sep 10 10:02:13 reopen-console:hvc0 is preferred Sep 10 10:02:13 reopen-console: Looking at console tty0 from /proc/consoles Sep 10 10:02:13 reopen-console:Adding tty0 to consoles list Sep 10 10:02:13 reopen-console: Adding inittab entry for hvc0 Sep 10 10:02:13 reopen-console: Adding inittab entry for tty0 Sep 10 10:02:13 reopen-console: Restarting init to start d-i on the consoles we found Sep 10 10:02:13 init: reloading /etc/inittab Sep 10 10:02:13 init: starting pid 208, tty '/dev/tty4': '/usr/bin/tail -f /var/log/syslog' Sep 10 10:02:13 init: starting pid 209, tty '/dev/hvc0': '/sbin/debian-installer' Sep 10 10:02:13 init: starting pid 210, tty '/dev/tty0': '/sbin/debian-installer' This seems to be new behaviour since stretch, introduced in version 1.128 of package rootskel. I suspect that the two debian-installer instances are racing each other. To confirm this, I unpacked initrd.gz, made a simple change to sbin/reopen-console (adding inittab entries only for cons in $preferred instead of for cons in $consoles), repacked, and run an installation again with much better results (no more questions from localechooser). I do appreciate that for interactive d-i use it's nice to have it show up on all consoles; but not at the expense of breaking fully automated installation.
Bug#939498: systemd warns about use of /var/run in rpc-statd.service
Package: nfs-common Version: 1:1.3.4-2.5 Severity: minor After upgrading to buster, systemd issues the following warning: systemd[1]: /lib/systemd/system/rpc-statd.service:13: PIDFile= references path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly.
Bug#935426: mailcap.order entries aren't always keyed by package name
Package: mime-support Version: 3.62 Severity: important According to the mailcap.order(5) man page, "The order of entries in the /etc/mailcap file can be altered by editing the /etc/mailcap.order file. Each line of that file specifies a package and an optional mime type." This only holds true if the package adds a file to /usr/lib/mime/packages. Many /etc/mailcap entries, however, are obtained by parsing files in /usr/share/applications; in that case the "package" name is taken to be the name of the .desktop file, minus the .desktop suffix. In some cases this is different from the actual package name. Moreover, the name can change in a package's history, resulting in surprising behaviour changes across release upgrades if /etc/mailcap.order isn't updated to match. The behaviour is old but became noticeable for me after upgrading from stretch to buster. evince.desktop was renamed to org.gnome.Evince.desktop, causing gimp to become the preferred PDF viewer. As I tried to correct this by adding evince:application/pdf to the mailcap.order file I got a warning "Warning: package evince listed in /etc/mailcap.order does not have mailcap entries." and no reordering of entries.
Bug#932749: Debian packaging of EclipseLink is missing essential classes
Package: libeclipselink-java Version: 2.6.6-1 Severity: grave When running a very simple test application, or indeed any production application I have at hand, using the Debian-packaged version of EclipseLink, I run into the following error when calling javax.persistence.Persistence.createEntityManagerFactory: [...] Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.internal.libraries.asm.ClassVisitor at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 9 more Indeed eclipselink-2.6.6/debian/excludesfiles/build contains the following line: org/eclipse/persistence/internal/libraries/** I conclude that the Debian packaging of EclipseLink is unusable at the moment, hence the severity setting. (The same applications work fine with upstream's eclipselink.jar. I'm not sure why this library is packaged in Debian, as nothing in buster seems to depend on it.)
Bug#932746: EclipseLink 2.6.6 doesn't work with OpenJDK 11
Package: libeclipselink-java Version: 2.6.6-1 Severity: important Tags: fixed-upstream When run with OpenJDK 11, which is the default JRE in buster, I get an exception trace that ends with: Caused by: java.lang.NullPointerException at org.eclipse.persistence.internal.helper.JavaSEPlatform.atLeast(JavaSEPlatform.java:150) at org.eclipse.persistence.indirection.IndirectCollectionsFactory.getProvider(IndirectCollectionsFactory.java:202) at org.eclipse.persistence.indirection.IndirectCollectionsFactory.(IndirectCollectionsFactory.java:45) ... 11 more This is upstream bug 536730, for which a fix is available on the 2.6 maintenance branch. (It would have made it into 2.6.7 if this had been released.) I have verified that cherry-picking the fix solves this particular issue. More comprehensive support for Java 11, including but not limited to the fix for this bug, is in EclipseLink 2.7.2 and later.
Bug#932182: Acknowledgement (vlc: Floating point exception crash playing certain DVDs)
control: found -1 3.0.7-1 control: tags -1 + fixed-upstream I confirm that the upstream commit I referred to earlier solves my problem and allows the DVD to be played. Inspection of the 3.0.7.1-2 source code suggests that the bug is still there (i.e. the commit didn't make it into that upstream release and isn't in debian/patches either) but I haven't verified it experimentally.
Bug#932182: vlc: Floating point exception crash playing certain DVDs
Source: vlc Version: 3.0.7-0+deb9u1 (Also reproducible on buster's 3.0.7-1.) vlc reproducibly crashes early on when trying to play a certain DVD in my collection. (Other DVDs play normally.) Judging from the backtrace (see below), this may be fixed by upstream commit 90989df9e3aab300c2d09a8eb9c0570e4cba4efa: vout: opengl: converter: prevent FPE with cropped empty spu This seems to cherry-pick cleanly, I'll be building and testing a modified package soon. Report #929491 may be about the same problem but doesn't contain enough detail for me to be certain. I've censored out the DVD title and serial number for privacy. Reading symbols from /usr/bin/vlc...Reading symbols from /usr/lib/debug/.build-id/e9/f58f04722b8df7835baf5420050c3f691bc510.debug...done. done. (gdb) run dvd://1 Starting program: /usr/bin/vlc dvd://1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". VLC media player 3.0.7 Vetinari (revision 3.0.7-0-g86cee31099) [New Thread 0x7fffe984e700 (LWP 6978)] [New Thread 0x7fffef216700 (LWP 6979)] [New Thread 0x7fffe4e3a700 (LWP 6980)] [5575a0e0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [New Thread 0x7fffe41f0700 (LWP 6981)] [New Thread 0x7fffc6967700 (LWP 6982)] [New Thread 0x7fffc5d51700 (LWP 6983)] [New Thread 0x7fffc51f9700 (LWP 6985)] [New Thread 0x7fffb7fff700 (LWP 6986)] [New Thread 0x7fffbc11a700 (LWP 6987)] libdvdnav: Using dvdnav version 5.0.3 [New Thread 0x7fffb53c4700 (LWP 6988)] [New Thread 0x7fffb52c3700 (LWP 6989)] [Thread 0x7fffb52c3700 (LWP 6989) exited] [Thread 0x7fffb53c4700 (LWP 6988) exited] libdvdnav: DVD Title: libdvdnav: DVD Serial Number: libdvdnav: DVD Title (Alternative): libdvdnav: DVD disk reports itself with Region mask 0x. Regions: 1 2 3 4 5 6 7 8 libdvdread: Attempting to retrieve all CSS keys libdvdread: This can take a _long_ time, please be patient libdvdread: Get key for /VIDEO_TS/VIDEO_TS.VOB at 0x0134 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_01_0.VOB at 0x017e libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_01_1.VOB at 0x01b7 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_02_0.VOB at 0x29e4 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_02_1.VOB at 0x29eb libdvdread: Elapsed time 0 libdvdread: Found 2 VTS's libdvdread: Elapsed time 0 [New Thread 0x7fffb53c4700 (LWP 6996)] [New Thread 0x7fffb52c3700 (LWP 6997)] [New Thread 0x7fff98122700 (LWP 6998)] [New Thread 0x7fffb4791700 (LWP 6999)] [New Thread 0x7fff95163700 (LWP 7000)] libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so libva info: va_openDriver() returns -1 [7fffa0005da0] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/gallium_drv_video.so libva info: va_openDriver() returns -1 [7fffa0005da0] glconv_vaapi_drm gl error: vaInitialize: unknown libva error libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/gallium_drv_video.so libva info: va_openDriver() returns -1 [7fffa0005da0] glconv_vaapi_drm gl error: vaInitialize: unknown libva error [7fffa81896d0] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding [7fffa81896d0] main decoder error: buffer deadlock prevented Thread 17 "vlc" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7fff95163700 (LWP 7000)] 0x7fff94e5cf13 in upload_plane (pixels=0x7fff8c002e40, visible_pitch=0, pitch=, height=, width=0, tex_idx=0, tc=0x7fffa004f190) at video_output/opengl/converter_sw.c:496 496 video_output/opengl/converter_sw.c: No such file or directory. (gdb) bt #0 0x7fff94e5cf13 in upload_plane (pixels=0x7fff8c002e40, visible_pitch=0, pitch=, height=, width=0, tex_idx=0, tc=0x7fffa004f190) at video_output/opengl/converter_sw.c:496 #1 0x7fff94e5cf13 in tc_common_update (tc=0x7fffa004f190, textures=0x7fffa00aacd0, tex_width=0x7fffa00aacd4, tex_height=0x7fffa00aacd8, pic=0x7fff8c002c50, plane_offset=0x7fff951626e0) at video_output/opengl/converter_sw.c:519 #2 0x7fff94e5851d in vout_display_opengl_Prepare (vgl=0x7fffa00c51f0, picture=picture@entry=0x7fffa05cffa0, subpicture=subpicture@entry=0x7fffa0551c10) at video_output/opengl/vout_helper.c:1231 #3 0x7fff94e5e1d6 in PictureRender (vd=, pic=0x7fffa05cffa0, subpicture=0x7fffa0551c10) at video_output/opengl/display.c:210 #4 0x771656bc in vout_display_Prepare (subpicture=, picture=0x7fffa05cffa0, vd=0x7fffa054e6c0) at ../include/vlc_vout_wrapper.h:47 #5 0x771656bc in ThreadDisplayRenderPicture (vo
Bug#931772: RT: On Create scrip ran but ticket not created
Package: request-tracker4 Version: 4.4.1-3+deb9u3 I've run into the following problem when submitting a ticket with a large binary attachment. An On Create scrip is triggered (as configured for the queue) and sends e-mail with a copy of the attachment, but in the process the web server times out (40 seconds is the mod_fcgid default) and the ticket creation fails, resulting in there being no entry in table TICKETS in the database for the ticket number mentioned in the e-mail. (Also, the attachment is truncated in the outgoing e-mail, but this is a lesser concern.) That it should take so long for the scrip to complete is not the object of this bug report (see #931769 for that). My complaint here is about the confusion created by sending out e-mail that refers to a nonexistent ticket. I think I would prefer for the ticket to be created and the scrip not to complete (e-mail delivery can fail for other reasons anyway) than the opposite. Also, if the ticket is created by the mail gateway the gateway should consume the incoming message once the ticket is created, even if scrips haven't been run. In the original incident the incoming mail remained in the queue, causing a new e-mail to be sent on each delivery attempt (they all failed for the same reason). Scrip failure should of course be reported to the system administrator, but it seems less useful to mailbomb either the requestor or (as in my incident) the AdminCcs for the queue.
Bug#931769: MIME::Decoder::Base64::encode_it() is too slow
Package: libmime-tools-perl Version: 5.508-1 (Issue believed to be still present in the latest version 5.509-1.) When base64-encoding a large file, MIME::Decoder processes it 45 bytes at a time. The resulting function call (and, depending on the application, system call) overhead can be very noticeable. I've seen RT (Debian package request-tracker4) hit a 40-second timeout while encoding a 8MB attachment because of this. Significant gains can be had by telling the encoder to process the file in larger chunks; I've set $EncodeChunkLength = 120*57 with good results. This takes advantage of the fact that MIME::Base64::encode_base64() will split the output into 76-byte lines by default; the feature has been documented since at least version 2.04 of MIME::Base64 (the minimum version required by MIME::Decoder::Base64). Maybe the encode chunk length should somehow be made configurable. If output is to a pipe one may want not to exceed the pipe buffer size (currently 64kB in Linux, but it can be smaller on other operating systems).
Bug#926483: FTBFS: utils/blkmapd/device-discovery.c:156: undefined reference to `major'
major(dev) is defined as a macro in which is provided by libc6-dev. I don't see that listed as an explicit build dependency, so it's conceivable that it might be present in some build environments but not in others. The configure script tests for it, potentially leading to #define MAJOR_IN_SYSMACROS 1 (and/or to #define MAJOR_IN_MKDEV 1, but seems associated with ZFS and the Solaris Porting Layer only). Would it be wrong to add an explicit build dependency on libc6-dev? Does it actually cure the FTBFS?
Bug#923511: [pkg-bacula-devel] Bug#923511: make_catalog_backup.pl doesn't sanitize $args{db_name}
* Carsten Leonhardt [2019-03-03 18:59:06 +0100]:
> I've written a patch to base the filename on the catalog name as you
> suggested (although I'm not good at perl), but the script
> "delete_catalog_backup" needs to be changed too.
That's probably correct. I'm still using a modified version of
delete_catalog_backup.pl, which doesn't seem to be part of Debian any more,
and indeed I had to modify that accordingly.
The patch looks good. I'd probably have used tr/A-Za-z0-9_-//cd but that's
a matter of taste.
Another thing I've found out in testing is that some versions of libpq have
trouble with URIs in the PGDATABASE environment variable; this can be worked
around by invoking pg_dump with an explicit -d argument:
> my %args = @_;
> setup_env_pgsql(%args);
> -exec("HOME='$wd' pg_dump -c > '$wd/$args{db_name}.sql'");
> +exec("HOME='$wd' pg_dump -c -d '$args{db_name}' >
> '$wd/$dump_filename.sql'");
> print "Error while executing postgres dump $!\n";
> return 1; # in case of error
The drawback, of course, is that the URI may include a password; so maybe
this is best left up to the local system administrator.
I'll see about reporting this to the PostgreSQL maintainers; the intent of
the source code seems to be that URIs should be valid in PGDATABASE,
so this looks like a bug. 9.6 is affected, not sure about other versions.
Bug#923511: make_catalog_backup.pl doesn't sanitize $args{db_name}
Package: bacula-director
Version: 7.4.4+dfsg-6
(Bug still present in latest upstream release.)
/etc/bacula/scripts/make_catalog_backup.pl uses a temporary file with a name
based on $args{db_name}. This fails if the database name contains / characters,
as it well might if it is a URI like
postgresql://host/db?sslmode=verify-full&sslrootcert=/etc/ssl/certs/host-ca.crt
(Aside: forcing TLS server certificate validation is my actual reason for
using a PostgreSQL connection string as the database name in the Bacula
configuration. It works, and may be worth documenting in the Bacula manual;
or Bacula could be enhanced to pass connection options in some other way.
Such wishlist items are not what the present bug report is about; I mention
them only for context.)
I'm planning to base the file name on the catalog name instead, though I
suppose even that might conceivably contain forbidden characters in some
installations.
Bug#923434: regression in kernel 4.9.144-3 on VIA C7
Package: linux-image-4.9.0-8-686-pae Version: 4.9.144-3 Severity: normal We have a VIA CN700-8237R board (with a Centaur C7 CPU). The kernel says DMI: /CN700-8237R, BIOS 6.00 PG 11/25/2009 This used to boot successfully with 4.9.130-2, but consistently fails with 4.9.144-3. It also boots successfully with 4.19.16-1~bpo9+1, so I have a workaround (at least for the time being). With 4.9.144-3, the boot usually hangs after printing the message console [tty0] enabled Sometimes I see one more line on the console: tsc: Fast TSC calibration using PIT There seems to be a difference in behaviour between cold and warm boots, with cold boots proceeding further (but still hanging eventually). Also, booting in single user mode sometimes succeeds. This makes me think that the hardware is not being (re)initialised correctly. I only have this one VIA C7 board, so I cannot rule out a hardware defect. I'm reporting this bug just in case someone has a use for the information, but since (a) 4.19.16-1~bpo9+1 works, and (b) it's time for us to replace this hardware anyway, I don't particularly need a fix.
Bug#922224: atop interferes with package acct's logging
Package: atop
Version: 2.2.6-4
Severity: important
On systems running stretch and systemd and with both the acct and the atop
packages installed, the process accounting logs in /var/log/account/ only
cover one out of every 24 hours. The pattern is:
accton |v3| 0.00| 0.00| 0.00| 0| 0| 4180.00|
0.00| 1857218569|Wed Feb 13 06:25:04 2019
[...]
atopacctd |v3| 0.00| 0.00|414389280.00| 0| 0| 0.00|
0.00| 7551|Thu Dec 27 08:20:13 2018
and then nothing. If I run "systemctl atopacct status" I see:
Feb 13 07:25:06 HOST atopacctd[755]: reactivate process accounting
This leads me to believe that the two packages are mutually incompatible
and should be declared as such (unless the incompatibility is removed,
of course). I'll now proceed to ban atop from my systems.
On a potentially related note, I see that /etc/init.d/atopacct checks
directories /var/account/pacct and /var/log/pacct but not /var/log/account,
and that the atop(1) man page refers to /var/account/pacct. There are also
(in /etc/logrotate.d/psacc{s,u}_atop) references to /etc/logrotate.d/psacct;
is any Debian package providing this file?
Bug#895381: Severity
* micah anderson [2019-01-20 21:03:53 +0100]: > I'm not disputing this bug exists, I'm just trying to determine why it > is you set the severity to "Serious". As you are probably aware, this > severity indicates that this is a sever violation of Debian policy > (violates a "must" or "required" directive), or in the package > maintainer's opinion, makes the package unsuitable for release. Oh. In the package maintainer's opinion. I had missed that part; my apologies. No, I don't claim a policy violation on this one and of course I'll defer to the package maintainer's assessment. I do find the bug scary, though, due to the possibility of silent corruption, and have been running a privately patched version of the package for that reason.
Bug#919460: [Pkg-xen-devel] Bug#919460: xen: disk I/O problems on stretch PV guest restores after security update
* Hans van Kranenburg [2019-01-17 00:41:39 +0100]: > > After "reboot -f"ing some of the affected domUs (which made them > > functional again), I rebooted the dom0. This time all domUs were > > restored normally. (Of course those that still had their filesystems > > mounted read-only stayed that way.) > > > > Is anyone else seeing this? > > The usual questions here would be like "can you reproduce the issue" > etc... Because if you consistently can cause the problem to happen, > you're in a positition to start trying things. Since this only happened on the reboot immediately following the Xen upgrade, in order to reproduce it I would need to either try it on another system or downgrade Xen on my test system and upgrade it again. The latter doesn't look like a good use of my limited time. I will eventually want to upgrade my production dom0's. Any domU's that I care about on these systems will be shut down prior to the reboot (that was the main lesson for me from this test), but I can leave a canary behind and see what happens to it. So eventually I should have an idea whether this is reproducible across systems. This will take a few weeks, though: plenty of time for others to run into the same problem if it's reproducible. I've been wondering whether the observed behaviour might be explained in terms of the specific changes made by the latest security patches. I don't see any such obvious explanation myself, but maybe to an expert it would leap out; that's partly why I reported this. If this is the case, then maybe there is no fix other than documenting the issue in release notes. It's also conceivable that the bug is in that domU kernel rather than in Xen. I might set up canary domU's with 4.9.144 (stretch-proposed-updates) and/or 4.19.x.
Bug#919460: xen: disk I/O problems on stretch PV guest restores after security update
Source: xen Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11 Yesterday I upgraded a test dom0 to this version (from 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10; stretch amd64, Xeon E5430), then rebooted. Running domU's were saved and restored in the usual way. However, all PV domU's running stretch (both i386 and amd64, all kernel 4.9.130-2) lost write access to xvda on restore due to I/O errors. Sample kernel log attached. (/var/log/kern.log stopped recording entries, so I grabbed dmesg output to show what happened afterwards.) I also had PV domUs running jessie (kernel 3.16.59-1, again both i386 and amd64). These were restored successfully. In all cases, xvda is backed by an LVM logical volume local to the dom0. After "reboot -f"ing some of the affected domUs (which made them functional again), I rebooted the dom0. This time all domUs were restored normally. (Of course those that still had their filesystems mounted read-only stayed that way.) Is anyone else seeing this? Jan 15 07:40:46 bst1 kernel: [1096816.319075] Freezing user space processes ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.320237] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.321499] PM: freeze of devices complete after 0.113 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321501] suspending xenstore... Jan 15 07:40:46 bst1 kernel: [1096816.321540] PM: late freeze of devices complete after 0.034 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321582] PM: noirq freeze of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] xen:grant_table: Grant tables using version 1 layout Jan 15 07:40:46 bst1 kernel: [1096816.321609] Suspended for 122.096 seconds Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: noirq restore of devices complete after 0.098 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: early restore of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328857] PM: restore of devices complete after 6.076 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328909] Restarting tasks ... done. ...skipping... Jan 15 07:40:46 bst1 kernel: [1096816.319075] Freezing user space processes ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.320237] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.321499] PM: freeze of devices complete after 0.113 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321501] suspending xenstore... Jan 15 07:40:46 bst1 kernel: [1096816.321540] PM: late freeze of devices complete after 0.034 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321582] PM: noirq freeze of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] xen:grant_table: Grant tables using version 1 layout Jan 15 07:40:46 bst1 kernel: [1096816.321609] Suspended for 122.096 seconds Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: noirq restore of devices complete after 0.098 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: early restore of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328857] PM: restore of devices complete after 6.076 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328909] Restarting tasks ... done. Jan 15 07:40:51 bst1 kernel: [1096821.985693] blk_update_request: I/O error, dev xvda, sector 0 [1096816.319075] Freezing user space processes ... (elapsed 0.001 seconds) done. [1096816.320237] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [1096816.321499] PM: freeze of devices complete after 0.113 msecs [1096816.321501] suspending xenstore... [1096816.321540] PM: late freeze of devices complete after 0.034 msecs [1096816.321582] PM: noirq freeze of devices complete after 0.038 msecs [1096816.321609] xen:grant_table: Grant tables using version 1 layout [1096816.321609] Suspended for 122.096 seconds [1096816.321609] PM: noirq restore of devices complete after 0.098 msecs [1096816.321609] PM: early restore of devices complete after 0.038 msecs [1096816.328857] PM: restore of devices complete after 6.076 msecs [1096816.328909] Restarting tasks ... done. [1096821.985693] blk_update_request: I/O error, dev xvda, sector 0 [1096821.988866] blk_update_request: I/O error, dev xvda, sector 0 [1096821.988892] blk_update_request: I/O error, dev xvda, sector 0 [1096821.988908] blk_update_request: I/O error, dev xvda, sector 12941838 [1096821.988950] Aborting journal on device dm-3-8. [1096821.991190] blk_update_request: I/O error, dev xvda, sector 12931074 [1096821.991213] Buffer I/O error on dev dm-3, logical block 139265, lost sync page write [1096821.991230] blk_update_request: I/O error, dev xvda, sector 3663168 [1096821.991247] blk_update_request: I/O error, dev xvda, sector 9413656 [1096821.991270] Aborting journal on device dm-1-8. [1096821.991334] Aborting journal on device dm-0-8. [1096821.991386] JBD2: Error -5 detected when updating journal sup
Bug#914621: adduser: please allow a leading underscore in user names again
My apologies for not having notice the closely related #521883 before submitting this. They can't immediately be merged because of the severity mismatch, and the discussion in #521883 seems to have drifted somewhat. I do like the idea of having a separate NAME_REGEX for system users, although that's definitely wishlist material while I still see this bug as a regression.
Bug#914621: adduser: please allow a leading underscore in user names again
Package: adduser
Version: 3.115
Severity: minor
The current default value for NAME_REGEX is ^[a-z][-a-z0-9_]*\$ (since version
3.111 reenabled underscores in all but the leading position). Historically,
adduser has allowed leading underscores from at least version 3.11.2 until
version 3.77, except for a brief hiatus in versions 3.61 and 3.62.
I understand why one may want to discourage leading digits in usernames, but
this restriction on leading underscores seems to have arosen by accident. I'm
therefore setting the severity to "minor" rather than "wishlist". ("minor"
because one can override this in /etc/adduser.conf, of course.)
Bug#912375: please consider specifying the full path name to wish in /usr/bin/ds9
Package: saods9 Version: 7.5+repack1-2 Severity: wishlist Some of our users have experienced breakage in Debian's /usr/bin/ds9 due to certain variable settings in their environment. Although this might be considered user error, it may be possible to alleviate this class of problem by hardening the ds9 script; please consider doing so. Both the problems I am aware of involved a private installation of Tcl/Tk taking precedence over the system one. In one case, the user had an installation of NASA's LHEASoft, with its own libtcl8.6 and libtk8.6 on the LD_LIBRARY_PATH search path; this issue is mentioned at https://heasarc.gsfc.nasa.gov/lheasoft/issues.html and could be worked around by unsetting LD_LIBRARY_PATH in the ds9 script. In the other case, LD_LIBRARY_PATH was unset but the user had a wish executable (from an AstroConda installation) ahead of /usr/bin/wish in the search path; this could be worked around by making the script exec /usr/bin/wish explicitly. (In both cases a contributing factor was that the LHEASoft/AstroConda installation lacked a working Tcl "xml" package, which ds9 depends on.) I've wondered whether there might be policy reasons against the above workarounds but couldn't find any. Section 10.4 of the Debian Policy Manual is silent about fully qualifying path names (outside of the #! bang path).
Bug#910993: hidapi-cffi: new upstream bugfix release is available
Source: hidapi-cffi Version: 0.2.1-1.1 Severity: wishlist Version 0.2.2 of this software was released (still to GitHub) on 2017-11-22. The changes are: 1. Fix length parameter in send_feature_report 2. Make serial number optional in Device.open. I've just started experimenting with this package and almost immediately ran into the second issue above, which is a deviation from the documentation. Besides packaging the new version, I'd also suggest adding a debian/watch file based on the usual template for projects hosted on GitHub.
Bug#910927: bacula-sd.service should specify SupplementaryGroups=bacula
Package: bacula-sd Version: 7.4.4+dfsg-6 There is a difference in behaviour between the SystemV init script, /etc/init.d/bacula-sd, and its systemd counterpart. The former starts /usr/sbin/bacula-sd as root with command-line arguments to specify the uid and gid to run as, while in the latter systemd starts the daemon with User=bacula and Group=tape. This difference has an impact on the running daemon's supplementary group list: in the SystemV case this includes group bacula, but not in the systemd case. This can lead to problems when switching from SystemV to systemd (e.g., on upgrade from jessie to stretch) if the administrator has chosen to rely on membership in group bacula for access control. One scenario where this will occur is if bacula-sd is configured to use TLS credentials and the secret key is owned by root:bacula and not readable by others. (One may want the daemon to only have read access to the key, and group tape may have other members who should not have access.) Adding /etc/systemd/system/bacula-sd.service.d/groups.conf with [Service] SupplementaryGroups=bacula has been verified to cure the symptoms. I suggest including this setting in /lib/systemd/system/bacula-sd.service .
Bug#641390: a2ps recommends nonexistent package cupsys-client
control: severity -1 serious Section 7.2 of the Debian Policy Manual reads in part: "The Recommends field should list packages that would be found together with this one in all but unusual installations." cupsys-client does not exist in Debian any more, not even as a virtual package (it was renamed to cups-client many years ago), so I submit that ap2s' continued mention of it in Recommends: is a policy violation.
Bug#840660: lightdm: Error using VT_WAITACTIVE 7 on /dev/tty0: Interrupted system call
It looks to me like upstream commit robert.anc...@canonical.com-20170213034648-wvwh9evai55o7sm5, first released in lightdm 1.21.4, should adequately address this (by retrying the system call on EINTR). Am cherry-picking this into 1.18.3, will test then tag this bug accordingly. (Note to other would-be cherry-pickers: the commit depends on an earlier one, michael.te...@canonical.com-20161020085337-efsjna95ma6yio89.)
Bug#903002: mc reset confuses ipmievd
* Jörg Frings-Fürst [2018-07-08 08:38:55 +0200]: > Can you please file a bug report to the upstream author[1] ? I'd much prefer that someone else do it. Among other reasons, https://www.debian.org/Bugs/Reporting says "If necessary, the maintainer of the package will forward the bug upstream." Instead, I'll provide additional information here, in the form of partial output of ipmievd -v -v -v sel nodaemon. Additional comments at the end. [...] Sensors cached OpenIPMI Request Message Header: netfn = 0xa cmd = 0x40 SEL count is 40 SEL freespace is 384 SEL Percent Used: 62% SEL Overflow: false Current SEL count is 40 [...] SEL Next ID: 0028 OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 28 00 00 ff SEL Entry: 2800022f55425b24083b0b01 SEL lastid is 0028 Current SEL lastid is 0028 Waiting for events... [...][ipmitool mc reset warm][...] OpenIPMI Request Message Header: netfn = 0xa cmd = 0x40 SEL count is 41 SEL freespace is 368 SEL Percent Used: 64% SEL Overflow: false New Events SEL Read ID: 0028 OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 28 00 00 ff SEL Entry: 0070018e58425b0bdbf25202 SEL Read ID: 2951 OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 51 29 00 ff SEL Entry: 2800022f55425b24083b0b01 Power Supply sensor Power Supplies Redundancy Lost Asserted SEL Read ID: 0029 OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 29 00 00 ff Get SEL Entry 29 command failed: Requested sensor, data, or record not found OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 29 00 00 ff SEL Entry: 2900028e58425b24083b0b01 Power Supply sensor Power Supplies Redundancy Lost Asserted OpenIPMI Request Message Header: netfn = 0xa cmd = 0x40 SEL count is 10751 SEL freespace is 512 SEL Percent Used: 98% SEL Overflow: false SEL buffer is 98% full, please consider clearing the SEL buffer New Events SEL Read ID: 0029 OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 29 00 00 ff SEL Entry: 0070018e58425b0bdbf25202 SEL Read ID: 2951 OpenIPMI Request Message Header: netfn = 0xa cmd = 0x43 OpenIPMI Request Message Data (6 bytes) 00 00 51 29 00 ff [...] This looks to me like a loss of synchronisation between requests and responses. 2951 looks like a plausible start for a "Get SEL Info" response.
Bug#903002: mc reset confuses ipmievd
control: -1 tags - moreinfo * Jörg Frings-Fürst [2018-07-05 16:59:16 +0200]: > > Please can you check it with the latest firmware V2.60? The problem still occurs on a DL385p Gen8 after upgrade to v2.60. It was seen both during the reset immediately following the firmware upgrade and in a subsequent manually triggered reset. The same problem was seen on a DL360p Gen8. I haven't tried upgrading that to v2.60 yet. I can't reproduce it on a MicroServer Gen8, however (neither with v2.54 nor with v2.60).
Bug#903002: mc reset confuses ipmievd
Package: ipmitool Version: 1.8.18-3 Seen on multiple ProLiant Gen8 servers with iLO firmware v2.54: if the BMC is reset (e.g. with "ipmitool mc reset warm", or through the embedded web server), the running instance of "ipmievd sel [no]daemon" starts logging spurious warnings about the SEL buffer being almost full; e.g.: /usr/sbin/ipmievd sel nodaemon Reading sensors... Waiting for events... No data available Get SEL Info command failed Power Supply sensor Power Supplies Redundancy Lost Asserted Get SEL Entry 5 command failed: Requested sensor, data, or record not found Power Supply sensor Power Supplies Redundancy Lost Asserted Power Supply sensor Power Supplies Redundancy Lost Asserted Power Supply sensor Power Supplies Redundancy Lost Asserted SEL buffer is 98% full, please consider clearing the SEL buffer Power Supply sensor Power Supplies Redundancy Lost Asserted Get SEL Info command failed: Requested sensor, data, or record not found Get SEL Entry 2 command failed: Requested sensor, data, or record not found (About the contents of the log entries, for purposes of this bug report it's enough to know that ipmievd is in substantial agreement with "ipmitool sel list" and with the view from the BMC's embedded web server. Only the "SEL buffer is 98% full" alert is clearly spurious; see below.) At the same time, "ipmitool sel info" reports: SEL Information Version : 1.5 (v1.5, v2 compliant) Entries : 6 Free Space : 928 bytes Percent Used : 9% Last Add Time: 07/04/2018 19:36:40 Last Del Time: 05/27/2017 08:45:32 Overflow : false Supported Cmds : 'Reserve' How one gets from 9% to 98% is unclear to me. Restarting ipmievd restores sanity, but only until the next BMC reset. Could ipmievd be caching information that is invalidated by the reset?
Bug#898137: nfsd: increase DRC cache limit
Source: linux Version: 4.9.88-1 Severity: wishlist Tags: patch I've run into this capacity limitation in stretch, which is addressed upstream in Linux 4.15 by the following commit: commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6 Author: J. Bruce Fields Date: Tue Sep 19 20:51:31 2017 -0400 nfsd: increase DRC cache limit which trivially applies to Linux 4.9 (I haven't checked 3.16) and provides significant relief in my use case. It would save me (and perhaps others) work if this change could be included in Debian's 4.9 kernel packages; otherwise I'll have to keep maintaining my own fork. (4.15 has other issues so I don't want to use it in production yet.) For the benefit of others who may be running into the same problem, here is a more detailed description. Symptom: an NFS server accepts only a limited number of concurrent v4.1+ mounts. Once that limit is reached, new clients get NFS4ERR_DELAY (10008) replies to CREATE_SESSION. (This can be seen in the server's dmesg after rpcdebug -m nfsd -s proc.) Increasing the number of nfsd threads has no impact on the number of mounts allowed. A server with 512MB of RAM only accepts 7 or 8 concurrent NFSv4.1+ mounts. From the perspective of an affected client, mount.nfs appears to hang (triggering a kernel backtrace after 120 seconds); in reality, though, it just keeps reissuing CREATE_SESSION calls until one of them succeeds. Pre-v4.1 clients are unaffected by this since sessions are new to NFS v4.1. The proposed patch just increases the limit by an order of magnitude, at the cost of using more kernel memory. As noted in comments in the source code, it would be nice to make this tuneable by the server administrator.
Bug#895983: lightdm: loops starting greeter X :1, "no screens found", fills /var/log
Package: lightdm Version: 1.18.3-1 Sometimes lightdm starts a tight, endless loop trying to start an X server for the greeter on :1 (VT8) while the user's session on :0 (VT7) is locked. The X server starts, complains about "no screens found", exits, and lightdm immediately tries again. On the attached monitor, which is powered on, one just sees a blinking white underscore in the top left corner. Attempts to change to a different VT using Ctrl+Alt+Fn work (one briefly sees the console login prompt on VT1) but are immediately overridden by a switch back to VT8, courtesy of lightdm. The looping lightdm instance is using about 30% of the CPU and Gigabytes of virtual address space. /var/log tends to fill up since /var/log/lightdm/lightdm.log doesn't get rotated when it grows large. I've seen this, sporadically, on several systems after they were upgraded from jessie to stretch. One possible common denominator is that they have nVidia graphics cards. (Regrettably, we need to use the proprietary drivers for these.) I'm responding by enabling AllowEmptyInitialConfiguration in /etc/X11/xorg.conf (a file that supposedly shouldn't be needed any more, but how else is one to override a poor choice of default settings?), which may be alleviating the problem (it's hard to tell for sure since I don't know how to trigger it at will). Would it be possible to: -- introduce rate limiting on lightdm's attempts to start X servers? -- rotate lightdm.log when it grows beyond a certain size? The root cause of Xorg's failure to detect any screens probably lies outside lightdm, but that doesn't mean one can't handle it more gracefully. Attaching lightly sanitised copies of /var/log/Xorg.1.log and of a representative excerpt from lightdm.log. The graphics card in this particular instance was a 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) and "cat /sys/module/nvidia/version" prints 340.106. [+169368.13s] DEBUG: Seat seat0: Display server stopped [+169368.13s] DEBUG: Seat seat0: Stopping session [+169368.13s] DEBUG: Seat seat0: Session stopped [+169368.13s] DEBUG: Seat seat0: Stopping display server, no sessions require it [+169368.13s] DEBUG: Seat seat0: Active display server stopped, starting greeter [+169368.13s] DEBUG: Seat seat0: Creating greeter session [+169368.13s] DEBUG: Seat seat0: Creating display server of type x [+169368.13s] DEBUG: Using VT 8 [+169368.13s] DEBUG: Seat seat0: Starting local X display on VT 8 [+169368.13s] DEBUG: DisplayServer x-1: Logging to /var/log/lightdm/x-1.log [+169368.13s] DEBUG: DisplayServer x-1: Writing X server authority to /var/run/lightdm/root/:1 [+169368.13s] DEBUG: DisplayServer x-1: Launching X Server [+169368.18s] DEBUG: Launching process 5480: /usr/bin/X :1 -seat seat0 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch [+169368.18s] DEBUG: DisplayServer x-1: Waiting for ready signal from X server :1 [+169368.28s] DEBUG: Process 5480 exited with return value 1 [+169368.28s] DEBUG: DisplayServer x-1: X server stopped [+169368.28s] DEBUG: Releasing VT 8 [+169368.28s] DEBUG: DisplayServer x-1: Removing X server authority /var/run/lightdm/root/:1 [+169368.28s] DEBUG: Seat seat0: Display server stopped [+169368.28s] DEBUG: Seat seat0: Stopping session [+169368.28s] DEBUG: Seat seat0: Session stopped [+169368.28s] DEBUG: Seat seat0: Stopping display server, no sessions require it [+169368.28s] DEBUG: Seat seat0: Active display server stopped, starting greeter [+169368.28s] DEBUG: Seat seat0: Creating greeter session [+169368.28s] DEBUG: Seat seat0: Creating display server of type x [+169368.28s] DEBUG: Using VT 8 [+169368.28s] DEBUG: Seat seat0: Starting local X display on VT 8 [+169368.28s] DEBUG: DisplayServer x-1: Logging to /var/log/lightdm/x-1.log [+169368.28s] DEBUG: DisplayServer x-1: Writing X server authority to /var/run/lightdm/root/:1 [+169368.28s] DEBUG: DisplayServer x-1: Launching X Server [+169368.33s] DEBUG: Launching process 5481: /usr/bin/X :1 -seat seat0 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch [+169368.33s] DEBUG: DisplayServer x-1: Waiting for ready signal from X server :1 [+169368.42s] DEBUG: Process 5481 exited with return value 1 [+169368.42s] DEBUG: DisplayServer x-1: X server stopped [+169368.42s] DEBUG: Releasing VT 8 [+169368.42s] DEBUG: DisplayServer x-1: Removing X server authority /var/run/lightdm/root/:1 [+169368.42s] DEBUG: Seat seat0: Display server stopped [+169368.42s] DEBUG: Seat seat0: Stopping session [+169368.42s] DEBUG: Seat seat0: Session stopped [+169368.42s] DEBUG: Seat seat0: Stopping display server, no sessions require it [+169368.43s] DEBUG: Seat seat0: Active display server stopped, starting greeter [+169368.43s] DEBUG: Seat seat0: Creating greeter session [+169368.43s] DEBUG: Seat seat0: Creating display server of type x [+169368.43s] DEBUG: Using VT 8 [+169368.43s] DEBUG: Seat seat0: Starting local X display on VT 8 [+169368.43s] DEBUG: DisplayServ
Bug#895404: NFS server stops accepting mount request / mounted NFS directories became inaccessible on client
control: severity -1 normal control: tags -1 + moreinfo Dear reporter, I'm sorry to hear that you have lost data. However, it doesn't seem very constructive to make a bug release-critical without providing enough detail to make a fix possible. NFS is a complex network protocol, and the root cause of unexpected behaviour isn't always obvious at first glance. First of all, has this bug been filed against the right package? The nfsd processes are actually kernel threads (that's one reason "kill -9" doesn't work on them), the corresponding package is the kernel image. How many clients are accessing that NFS server when the problem occurs? I see that you have RPCNFSDCOUNT=8 but the address range for allowed clients is a /27. If you have 30 clients all trying to write at the same time, some of them are going to have to wait until a server thread becomes available. "server not responding, still trying" is a common symptom of this. Have you tried tuning the server? You can adjust the thread count without a reboot. I don't see sec=krb5p in your /etc/exports, so NFS traffic on the wire is probably unencrypted. Have you looked at it with tcpdump or a similar tool, particularly when the problem occurs? For example it would be nice to know whether that "Connection timed out" you get from mount.nfs is for the portmapper (unlikely), for mountd, or for nfsd itself. (strace may also tell you some of this.) Are you familiar with rpcdebug? If client traffic is coming in but the server isn't replying, you could set debugging flags and look at kernel log output. Other available debugging tools include the kernel's event tracing subsystem, as well as nfsstat, nfsiostat and mountstats from package nfs-common. (The last two are client-side, so maybe not so useful if your problem really is at the server end.) I can't help you much more than this: my own environment is NFSv4-only (and I feel no urge to look back) while yours is anything but. But if you manage to pinpoint more precisely what's wrong, someone else may be able to provide better hints (or you may figure it out yourself).
Bug#884284: nfs4_reclaim_open_state: Lock reclaim failed
Control: retitle -1 nfs4_reclaim_open_state: Lock reclaim failed For what it's worth, I've seen the same symptoms in jessie (kernel 3.16.36 at the time) and Ubuntu trusty (3.13.0-93). In my experience, NFSv4 in stretch is no worse than in jessie. Rate-limiting those "Lock reclaim failed!" messages would be useful. I've had to add a filter for them in rsyslog to prevent a DoS on my central logging infrastructure. I don't see them often, but when a client gets stuck it can emit this message *many* times. There is definitely more than one trigger for these. I'm under the impression that network partitioning events generate short bursts of such messages, but this is usually benign and does not require a reboot for recovery. Not sure what causes the more severe incidents (I haven't had one in a while, and my NFS environment is intentionally v4-only). My troubleshooting checklist for the next incident includes echo 1 > /sys/kernel/debug/tracing/events/nfs4_lock_reclaim/enable but I haven't had a chance to put this into practice yet.
Bug#895384: nfs-utils: debian/watch pattern matches ../
Source: nfs-utils Version: 1:1.3.4-2.1 Tags: patch https://tracker.debian.org/pkg/nfs-utils mentions "Problems while searching for a new upstream version". The reason turns out to be that the version string pattern in debian/watch matches .. as well as 2.3.1 etc. and uscan treats .. as newest. A minimal fix (tested) is to change /([\.\d]+)/ to /(\d[\.\d]*)/ . There may be better solutions. Incidentally, the latest upstream release of nfs-utils is 2.3.1. Debian sid still has 1.3.4.
Bug#895381: rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5'
Package: nfs-common Version: 1:1.3.4-2.1 Severity: serious Tags: fixed-upstream patch One of my systems has logged rpc.gssd[1168]: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5' This turns out to be a known problem, covered extensively in https://bugzilla.redhat.com/show_bug.cgi?id=1419280 Please cherry-pick upstream commit 5ae8be8b6af1a0fdf2fa26051a05d4c04d028849 (and possibly 0a4f5e4daccdeba767b9ef36e30efbd7fd9a76d8 as well, although I'd rate that at a lower severity).
Bug#892374: autofs: can't specify nfsvers=4.1 in auto.master
Package: autofs Version: 5.1.2-1 Severity: wishlist Tags: fixed-upstream The versions of autofs currently in Debian do not support nfsvers=4.1 or nfsvers=4.2 as a map option in the auto.master map. This makes it inconvenient to force one of these protocols for every mount, as one needs to add the option to each map entry individually. This is fixed upstream in 5.1.4 (please consider packaging that). I have successfully cherry-picked the relevant changes into 5.1.2; one needs the following two commits: [16ca6b40] allow dot in OPTIONSTR value lexer pattern [aa1f4321] handle additional nfs versions in mount_nfs.c
Bug#886855: xfce4-session: verbose logging is always enabled
To fin4478: the upstream commit is trivial to cherry-pick onto 4.12.1, if your goal is just to gain control over the logging you could try that (as I've done with good success). The error you got in attempting to package 4.13 is unrelated to this bug. I'm not sure what the point was of filing #891284: it looks like a candidate for merging with this bug.
Bug#891325: Info received (Bug#891325: Acknowledgement (xfce4-weather-plugin: search function violates provider's usage policy))
Here is a minimal patch to add a User-Agent: header to outgoing requests.
I've tested it and found that it restored location search functionality.
I don't consider it a complete fix since it doesn't make the search URI
configurable.
Attempt a minimal fix for Debian #891325.
Index: git/panel-plugin/weather.c
===
--- git.orig/panel-plugin/weather.c 2018-02-24 17:08:19.734257691 +0100
+++ git/panel-plugin/weather.c 2018-02-24 18:04:11.807358994 +0100
@@ -1852,6 +1852,10 @@
g_object_set(data->session, SOUP_SESSION_TIMEOUT,
CONN_TIMEOUT, NULL);
+/* Set the user agent to something sensible */
+g_object_set(data->session, SOUP_SESSION_USER_AGENT,
+ PACKAGE_NAME "/" PACKAGE_VERSION " ", NULL);
+
/* Set the proxy URI from environment */
proxy_uri = g_getenv("HTTP_PROXY");
if (!proxy_uri)
Bug#891325: Acknowledgement (xfce4-weather-plugin: search function violates provider's usage policy)
The Nominatim Usage Policy at https://operations.osmfoundation.org/policies/nominatim/ reads in part: "Apps must make sure that they can switch the service at our request at any time (in particular, switching should be possible without requiring a software update). If at all possible, set up a proxy and also enable caching of requests." I think that argues for making the search URL configurable by the user at run time (especially when one also considers this other suggestion: "If your requirements are even larger you can install your own instance of Nominatim"). Maybe the User-Agent string could be made configurable as well (with a sensible default).
Bug#891325: xfce4-weather-plugin: search function violates provider's usage policy
Package: xfce4-weather-plugin Version: 0.8.9-1 Severity: serious The location search functionality is currently broken. On investigation, I find the following URL in the source code: http://nominatim.openstreetmap.org/search?q=%s&format=xml (where %s is replaced by the sanitized query string). Using this URL in Firefox returns plausible results. Searching in the plugin and capturing the wire traffic shows the following: GET /search?q=%s&format=xml HTTP/1.1 Host: nominatim.openstreetmap.org Connection: Keep-Alive (note the lack of a referrer or user agent in the request), to which the server responds with Access blocked Access blocked You have been blocked because you have violated the https://operations.osmfoundation.org/policies/nominatim/";>usage policy of OSM's Nominatim geocoding service. Please be aware that OSM's resources are limited and shared between many users. The usage policy is there to ensure that the service remains usable for everybody. Please review the terms and make sure that your software adheres to the terms. You should in particular verify that you have set a +valid referrer or a user agent that identifies your application, and that you are not overusing the service with massive bulk requests. If you feel that this block is unjustified or remains after you have adopted your usage, you may contact the Nominatim system administrator at nomina...@openstreetmap.org to have this block lifted. I understand that the plugin relies on libsoup for this. The documentation for soup_session_new_with_options mentions a SOUP_SESSION_USER_AGENT which one may want to consider using. Incidentally, libsoup supports TLS. An https:// URL would be an improvement, except for debugging (so one may want to add a toggle for this, with https being the default setting).
Bug#884871: rpc.svcgssd starts while disabled in /etc/default/nfs-kernel-server
rpc.svcgssd is also needed on clients in order to support NFSv4.0 callbacks. It was moved from nfs-kernel-server to nfs-common for this reason. See Debian bug #651558. Apparently the task of starting rpc.svcgssd under SysV init is still entrusted to the nfs-kernel-server package. Maybe something needs to be done about that. If you are using systemd, you may find the file systemd/README in the source package to be of interest. The relevant portion reads: "rpc.gssd and rpc.svcgssd are assumed to be needed if /etc/krb5.keytab is present. If a site needs this file present but does not want the gss daemons running, it should create /etc/systemd/system/rpc-gssd.service.d/01-disable.conf and /etc/systemd/system/rpc-svcgssd.service.d/01-disable.conf containing [Unit] ConditionNull=false " I think this (or equivalent information; I'd have suggested "systemctl disable" instead of the above approach) should be included somewhere under /usr/share/doc/nfs-common/. As for the side question on how to disable version 4.0 but not 4.1: try passing --no-nfs-version=4.0 to nfsd. (I haven't tested this myself yet, only read utils/nfsd/nfsd.c. The man page is too terse about this.)
Bug#890488: xen-utils-common is missing README.pti, README.comet
Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u4.1 A recent changelog entry claims: * Ship README.pti and README.comet from the upstream XSA-254 advisory in /usr/share/doc/xen-utils/common/. However, I cannot find these files anywhere on my system after upgrade. (The changelog entry contains a likely typo, xen-utils/common instead of xen-utils-common, but I looked for the files elsewhere as well.) In the source package, which does contain these files, I see that debian/rules.real builds the architecture-independent package xen-utils-common in an architecture-dependent manner; in particular, dh_installdocs is only invoked on a subset of all architectures. Maybe this needs to be reconsidered?
