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,

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

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

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

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

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

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]:

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

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

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()

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

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

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

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 obs

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 >>>

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

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 e7a23e

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

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

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

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

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

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

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

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

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

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

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

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.,

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

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

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

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

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 > > >

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

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

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

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

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

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

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

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

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): ../ (..)

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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|

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"

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

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

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

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,

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

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

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

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

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

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."

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

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

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

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

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

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!"

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

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

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

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

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:

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

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=xml (where %s is replaced by the sanitized query string). Using

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

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.

Bug#889905: [Pkg-xfce-devel] Bug#889905: xfce4-notifyd: privacy-invasive logging of notification content

* Yves-Alexis Perez [2018-02-08 20:38:01 +0100]: > Hi, thanks for the bug report. Can you provide the upstream bug report on > this? I can't reproduce with: > > notify-send ' ' on xfce4-notifyd 0.4.1-1 so maybe it's been > fixed meanwhile. The upstream bug numbers are #10027 and #14073. Yes,

  1   2   3   4   >