Package: icedove
Version: 38.7.0-1~deb8u1
Severity: normal
Tags: upstream
Dear Maintainer,
I'm running icedove for years as MUA via IMAP for my Cyrus2 mail
server. Access has been encrypted using TLS on port 143 for many
years. Recently, it suddenly ceased working. In the relevant time
frame I
Package: browser-plugin-gnash
Version: 0.8.11~git20140319+dfsg-1~bpo70+1
Severity: normal
Dear Maintainer,
trying to watch any youtube video I saw my firewall logging connections
to external systems on port 443. The port is blocked, since all traffic
is expected to pass through a proxy.
Package: nslcd
Version: 0.8.10-4
Severity: important
Dear Maintainer,
I just switched from libnss-ldap / OpenLDAP with TLS auth to
libnssd-ldap / Samba4 AD DC with Kerberos auth. So the issue might have
existed for some time.
During boot k5start fails:
Fri Oct 24 12:34:55 2014: [FAIL]
Package: gcr
Version: 3.4.1-3
Severity: normal
Dear Maintainer,
on an amd64 system installing gcr:i386 - apparently used by acroread - fails.
The reason is that libgcr-3-1:i386 requires libgcr-3-common:i386, which is not
available:
$ apt-cache policy libgcr-3-common:i386
libgcr-3-common:i386:
I see the same situation here. Just updated from Squeeze to Wheezy.
Any progress on this since May?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I worked a little more on the issue and it seems to be a user error,
respectively a cryptic error message.
The new Kontact does not automatically import the old calendars since it
apparently uses a new storage model. It however starts wit some default
calendar, which is marked read only by
Package: krb5-user
Version: 1.8.3+dfsg-4squeeze1
Severity: normal
Tags: patch
kpasswd without setting of the kpasswd_server property in the [realms] section
connects to the KDC on UDP port 454.
Specifying the port 464 explicitly for the kpasswd_server property fixes the
problem, but this
My bind9 simply stopped working all of a sudden. It worked perfectly and
then following a reboot of the VZ container it would segfault on start.
The first event coincided with the latetst security update. I installed
the update and it did start again. However, now using still the same
code, it
My bind9 simply stopped working all of a sudden. It worked perfectly and
then following a reboot of the VZ container it would segfault on start.
The first event coincided with the latetst security update. I installed
the update and it did start again. However, now using still the same
code,
I have a similar issue with a NAS RAID attached via eSATA, which I use
for backup. It has XFS on LUKS. While it worked well in the beginning,
the last 3 backups messed it all up and required xfs repairs. Two times
it kicked the server into kernel crashes. This was in /var/log/messages
for the
I encountered the same issue today, when my backup script attempted to
rsync -aHAXx --stats --numeric-ids --inplace --delete '/'
'/media/backup/repository/sda5'
which produced
rsync: writefd_unbuffered failed to write 4092 bytes [sender]: Broken
pipe (32)
rsync: connection unexpectedly
Sorry, as the patch comments say, the bug has already been filed as
#405495, I myself have sent the patch then, and it circles somewhere in
unstable.
As we say in German: Reading educates!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
12 matches
Mail list logo
