Bug#852069: DomU guests with pygrub as bootloader do not start after, upgrade from Xen 4.1 (wheezy) to Xen 4.4 (jessie)

Package: xen-utils-4.4 Version: 4.4.1-9+deb8u8 Severity: normal Under Xen 4.1 in Debian 7 (wheezy), the following works when included in a DomU configuration in "/etc/xen/cfg/" -- bootloader = '/usr/lib/xen-default/bin/pygrub' After upgrading to Xen 4.4 as part of an upgrade to Debian

Bug#727027: clamav: new version 0.98 in upstream

I would like to bump this as well. We depend upon clamav widely and are very eager to see 0.98 in volatile/wheezy-updates. -- Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#621422: Package dependency error - "smtptest" test client authentication fails without "libsasl2-modules" installed

Package: cyrus-clients-2.2 Version: 2.2.13-14+lenny3 Severity: normal If the "smtptest" tool is used to test SMTP AUTH but the "libsasl2-modules" package is not installed on the _client_ side, it fails to understand the valid server prompt for SMTP AUTH: # smtptest -u [username] -a [authnam

Bug#619226: Follow-up: repeatable association with "libsasl2-modules"

As a follow-up, I experimented further and have determined that the issue is reliably replicated with the presence or absence of the "libsasl2-modules" package. That is, with this package installed everything works, but with this package uninstalled I get the error "Could not log on to timsieve

Bug#619226: Exact problem identified with sivtest tool

With the "libsasl2-modules" package installed, timsieved properly responds with the line '"SASL" "LOGIN PLAIN"' that is not present otherwise, as shown in my original bug report. Here is the output from the sivtest tool once the "libsasl2-modules" package has been installed: # sivtest WARNING:

Bug#619226: Packages apparently required but not declared as dependencies

Package: avelsieve Version: 1.9.7-6+lenny1 Severity: normal After applying the workaround recommended in bug 547648 (that is, setting "$this->broken_tls = true;" to disable TLS), the Squirrelmail "Filters" link produced the error message "Could not log on to timsieved daemon on your IMAP serve

Bug#563602: mdadm: autocheck running checkarray fails and degrades array when weekly cron jobs tick off

martin f krafft wrote: Please fire off checkarray at an earlier time so that it can complete before the 0626 run. Does the problem reoccur? I changed "/etc/cron.d/mdadm" to "57 7 * * 1" so that "checkarray" started at 0757 Monday, and it completed normally: Jan 4 07:57:31 virtual1 mdadm[3471]

Bug#559634: [pkg-ntp-maintainers] Bug#559634: no kernel sync and "ntpdc -c kerninfo" reports incorrect estimates of time on Xen dom0

I've left the daemon running for about 24 hours now since the last reset, and I'm still seeing wild swings: virtual1:~$ ntpdc -c kerninfo pll offset: 0 s pll frequency:104.224 ppm maximum error:16 s estimated error: 16 s status: 0041 pll unsync pll t

Bug#559634: [pkg-ntp-maintainers] Bug#559634: no kernel sync and "ntpdc -c kerninfo" reports incorrect estimates of time on Xen dom0

Kurt Roeckx wrote: On Sat, Dec 05, 2009 at 05:12:13PM -0500, Michael Bilow wrote: This is taking place on Xen dom0, not domU. (The name of the server -- the Xen host -- is "virtual1".) As far as I understand, ntp should work normally on dom0. I don't know much about x

Bug#559634: no kernel sync and "ntpdc -c kerninfo" reports incorrect estimates of time on Xen dom0

Package: ntp Version: 1:4.2.4p4+dfsg-8lenny2 Severity: normal This is taking place on Xen dom0, not domU. (The name of the server -- the Xen host -- is "virtual1".) As far as I understand, ntp should work normally on dom0. I have no actual evidence that ntp is synchronizing the clock at all.