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
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
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.
control: tags -1 + fixed-upstream
This was fixed in upstream commit 2da03e389866835e29b78a4546c6f1f87aab8fe1 ,
first released in version 3.14.1.
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, Dam
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.)
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 =
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.
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 suppo
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
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
fw
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 s
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]: ERR
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 any
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
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.
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
* 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).
* 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-bac
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 t
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 obsole
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_
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:5
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.
* 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
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 look
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.
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-de
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 ar
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
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 boota
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
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 setxat
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 a
* 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 t
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 a
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-ge
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
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.
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
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 bust
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
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 lo
* 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
>
>
>
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 s
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 th
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
I have empirical reasons to believe that the fix for CVE-2019-3689 (cf. #940848)
will take care of this bug as well.
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
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
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 p
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 independen
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 cha
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):
../ (..)
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://bu
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 m
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 parenthes
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 (
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 pa
* 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 d
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/ima
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
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
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.createEntit
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.JavaSEPlatfor
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 upstrea
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 90989df9e3aab300c2d09a8eb9c
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 (
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 noti
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_SY
* 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
dele
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
postgres
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 success
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.0
* 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" dire
* 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
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 (bot
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 th
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, exc
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
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 a
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 syste
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 rena
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
* 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."
Ins
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 subsequ
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 buffe
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
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 atta
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
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!" message
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 m
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
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
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 #891
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
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
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).
Us
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 n
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.
(T
1 - 100 of 338 matches
Mail list logo