Package: gerbera
Version: 2.2.0+dfsg-1+b3
Followup-For: Bug #1061790
I have found a workround for this problem. The following hack makes gerbera
work again for me.
As root:
cd /usr/share/gerbera/web/vendor/jquery
ln -s jquery-3.6.0.min.js jquery-3.7.1.min.js
ln -s jquery-3.6.0.min.map jqu
Package: gerbera
Version: 2.2.0+dfsg-1+b2
Followup-For: Bug #1061790
Just to confirm that this still exists in 2.2.0+dfsg-1+b2
Package: gerbera
Version: 2.0.0+dfsg-1
Followup-For: Bug #1061790
Dear Maintainer,
I use Gerbera rarely and have been running an old version.
I upgraded to 2.0.0+dfsg-1 and now see the same problem.
Note: in my case, I do not run Gerbera from systemd - I just invoke
it from my user terminal sess
On 03/05/2023 21:56, Nicholas D Steeves wrote:
> Hi,
>
> Graham Cobb writes:
>
>> The new checks at mount time cause mount times for large filesystems to be
>> much
>> longer. My roughly 10TB filesystem now takes over 90 seconds to mount.
>>
More recent
Package: mitmproxy
Version: 6.0.2-1
Severity: normal
I had just started using mitmproxy: it was installed and working.
Independently, I upgraded my Debian Testing system to the latest version
and now, when I try to run mitmproxy, I get the following errors:
Traceback (most recent call last):
F
Package: btrbk
Version: 0.32.4-1
Severity: minor
I have been using btrbk for centralised backups of many remote
machines for a long time.
The latest release of btrbk changes the 'readlink' command sent
to remote machines. Previously it seems the command was:
readlink -v -e /mnt/a/b
Now it is:
Package: logwatch
Version: 7.5.6-1
Severity: normal
A recent-ish upgrade of testing has meant that a couple of unmatched
LVM entries have started appearing in logwatch:
PV /dev/dm-0 online, VG cryptssd500gb2-vg is complete.: 1 Time(s)
PV /dev/dm-10 online, VG cryptdata16tb2-vg is complete
Package: dropbear-initramfs
Version: 2022.82-3
Severity: minor
While experimenting with the kernel 'ip=' parameter (see Bug#1015287),
I have been seeing strange errors on screen during bootup. Note that
these are cases in which the kernel networking initialisation fails but,
as I don't actually ne
Package: dropbear-initramfs
Version: 2022.82-3
Severity: wishlist
I have recently started using dropbear-initramfs to try to help with situations
where boot problems need to be resolved remotely.
I have it working on one system but when I try to use it on a second system it
doesn't work.
This se
Package: nfs-kernel-server
Version: 1:1.3.4-6
Followup-For: Bug #971238
I have also hit the problem about how to specify nfs-server options,
which still exists in this version.
Fortunately the equivalent Ubuntu bug report
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1898778 comes up i
Package: s3ql
Version: 3.7.0+dfsg-2
Followup-For: Bug #983170
Now that bullseye has shipped, and I have moved on to bookworm, I am keen to do
anything I can to help resolve this. Is there anything I can do? For example
testing with packages? Or is there an upstream fix available for testing?
-- S
Package: imagemagick-6-common
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal
Dear Maintainer,
While adjusting /etc/ImageMagick-6/policy.xml after upgrading to
8:6.9.11.60+dfsg-1.3 I noticed that the line:
has been changed to...
" has been lost from the end of
the line. It was present in the v
Package: dma
Version: 0.13-1
Followup-For: Bug #983916
Workround, for anyone else hitting this problem... sed can be used to do a
simple line wrap. I use:
sed 's/\(.\{800\}\)/&\n---/g'
which wraps lines at 800 bytes and adds '---' to the start of the next line.
In particular, for logwatch (whic
Package: dma
Version: 0.13-1
Severity: normal
I am using dma on a few standalone systems for handling reports from
various system daemons.
One of those daemons is logwatch. On one system, logwatch is reporting on some
log lines which happen to be very long (1060 characters). When one of those
log
Package: s3ql
Version: 3.7.0+dfsg-2
Followup-For: Bug #983170
The mount.log consists of minor variations on the following...
2021-02-20 13:21:46.208 238604:MainThread s3ql.mount.determine_threads: Using
10 upload threads.
2021-02-20 13:21:46.210 238604:MainThread s3ql.mount.main: Autodetected 10
Package: s3ql
Version: 3.7.0+dfsg-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome
Package: nbd-server
Version: 1:3.20-1
Followup-For: Bug #850424
By the way, the auth file accepts the "mixed" format for v6-mapped v4 addresses.
So, for example, 192.168.1.23 can be entered as :::192.168.1.23 instead of
having to
work out the hex bytes.
But don't forget that if you specify a
Package: s3ql
Followup-For: Bug #959117
Thanks Nikolaus.
I am unable to reproduce this problem with s3ql 3.3.2+dfsg-2+b2 and
fuse3 3.10.1-1 (the versions currently in unstable).
I am using:
mount.s3ql s3://eu-west-1/my-bucket-location/s3ql/sub-bucket/ /mnt/a
umount.s3ql /mnt/a
I have tried bot
Package: s3ql
Followup-For: Bug #959117
I note that this bug is blocking s3ql moving into bullseye, and hence stopping
me updating python3
and updates to several other packages.
As I am dependent on s3ql, duplicity, libreoffice and samba I would be very
happy to help in
any way I can. Please le
Package: btrfs-progs
Version: 5.7-1
Followup-For: Bug #955413
Thanks for looking into it. I agree with your analysis but the issue is real.
I think the long mount times tend to occur when there are large numbers of
subvolumes and other large trees.
Although the problem is not fixable in btrfs-pro
Package: btrfs-progs
Version: 5.3.1-1
Severity: minor
The new checks at mount time cause mount times for large filesystems to be much
longer. My roughly 10TB filesystem now takes over 90 seconds to mount.
Unfortunately, this is longer than the default systemd mount timer and systemd
assumes the m
Package: xpra
Version: 3.0.7+dfsg1-1
Severity: normal
I have installed xpra with no customisation (no changes to files in /etc/xpra).
xpra start --start=xclock
produces the following error message:
2020-03-29 22:54:55,346 Error: failed to write script file
'/run/user/500/xpra/run-xpra':
2020
Package: plasma-workspace-wallpapers
Version: 4:5.14.5-1
Severity: important
I currently have version 4:5.14.5-1 of plasma-workspace-wallpapers and
4:15.04.2-1 of kde-wallpapers-default installed.
Attempting to upgrade plasma-workspace-wallpapers to 4:5.17.5-2 (using "apt
upgrade") fails with e
Package: dar
Version: 2.6.8-1
Severity: normal
Dear Maintainer,
I had dar 2.6.6-1 installed on my system. I decided to upgrade to dar 2.6.8 so
I did:
apt install dar
This installed dar 2.6.8-1, gcc-10-base 10-20200222-1 and libgcc-s1
10-20200222-1.
However, it did NOT upgrade libdar (which I
Package: exim4
Version: 4.93-5
Severity: normal
This system recived no mail. Exim is setup to allow mail to be sent to a
smarthost
(mostly from daemons but from humans occasionally, like sending a log or config
file
to themselves on another system, or reportbug!).
Since a recent upgrade, the lo
Package: squid-deb-proxy
Version: 0.8.14+nmu2
Followup-For: Bug #932501
I am just updating this report to indicate that this bug still exists in
this version.
The workround in the original report seems to work, but without it,
squid-deb-proxy is useless.
-- System Information:
Debian Release: b
On 27/11/2019 16:42, Ansgar wrote:
> On Wed, 2019-11-27 at 15:22 +0000, Graham Cobb wrote:
>>> I suspect there are some old binaries (from systemd-241) around for
>>> some reason.
>>
>> That does seem to be the case.
>
> Did you ever (a) install system
On 27/11/2019 14:05, Ansgar wrote:
> On Wed, 2019-11-27 at 11:49 +0000, Graham Cobb wrote:
>> I am upgrading my debian testing system but the upgrades fail as systemd
>> cannot be configured.
>>
>> Output from dpkg --configure systemd:
>>
>> Setting up sy
On 27/11/2019 12:31, Michael Biebl wrote:
> Is this a /usr-merged system, i.e. is /lib a symlink to /usr/lib and
> /bin a symlink to /usr/bin?
>
No, it is not.
In case it is relevant: it is a fairly old system that has been upgraded
many times.
I needed to progress with my upgrade, so I noted that setting
LD_LIBRARY_PATH works round the problem:
LD_LIBRARY_PATH=/usr/lib/systemd/:/usr/lib:/lib dpkg --configure systemd
Package: systemd
Version: 243-8
Severity: important
Dear Maintainer,
I am upgrading my debian testing system but the upgrades fail as systemd cannot
be configured.
Output from dpkg --configure systemd:
Setting up systemd (243-8) ...
systemd-machine-id-setup: error while loading shared librarie
Package: duplicity
Version: 0.8.05-1
Followup-For: Bug #942593
Please see upstream bugs https://bugs.launchpad.net/duplicity/+bug/1849661 (and
https://bugs.launchpad.net/duplicity/+bug/1847885).
Unfortunately b2backend is still broken upstream. I have sent a patch and I
think that should fix it
Package: duplicity
Version: 0.8.05-1
Followup-For: Bug #942593
The bug still exists in the new version, although in a slightly different form:
(during "duplicity full" command)
Backtrace of previous error: Traceback (innermost last):
File "/usr/lib/python3/dist-packages/duplicity/backend.py", li
Package: duplicity
Version: 0.8.04-2
Followup-For: Bug #942593
Thanks Alexander. I will test the new version when it is available.
Just in case anyone is interested, my proposed patch did not work properly. The
following temporary patch is working for me:
+++ b2backend.py2019-10-20 21:3
Package: duplicity
Version: 0.8.04-2
Followup-For: Bug #942593
As part of my investigation, the following patch at least allows backups to
work:
--- b2backend.py.sav2019-10-18 18:31:22.263319894 +0100
+++ b2backend.py2019-10-18 18:42:10.969622822 +0100
@@ -110,6 +110,7 @@
u"
Package: duplicity
Version: 0.8.04-2
Severity: normal
Dear Maintainer,
I am attempting to use the new python3 version of duplicity for Backblaze.
Note: I have installed the python3 b2 library (pip3 install b2).
Any use fails with:
Attempt 1 failed. TypeError: can only concatenate str (not "byte
Package: mariadb-server-10.3
Version: 1:10.3.13-2
Followup-For: Bug #926231
OK, this is weird!
I tried the two options suggested by Otto. mysql_upgrade failed...
# mysql_upgrade
Version check failed. Got the following error when calling the 'mysql' command
line client
ERROR 2002 (HY000): Can't
Package: mariadb-server-10.3
Version: 1:10.3.13-2
Followup-For: Bug #926231
I'm not sure what the "MariaDB error log" is but I have found the following
entries in syslog:
Apr 3 20:31:00 novatech mariadb-server-10.3.postinst[8418]:
Apr 3 20:31:00 novatech mariadb-server-10.3.postinst[8418]: In
Package: mariadb-server-10.3
Version: 1:10.3.13-2
Followup-For: Bug #926231
The bug still exists in 1:10.3.13-2
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-2-
Package: mariadb-server-10.3
Version: 1:10.3.13-1
Severity: important
Dear Maintainer,
mariadb-server-10.3 will not configure on my debian testing (buster) system.
The system previously used mysql (I do not remember exacty which version but I
can find out if necessary).
Since that was replaced
Package: dovecot-sieve
Version: 1:2.3.4.1-1
Severity: normal
When processing a particular type of notification email, I consistently get the
following sieve crash during execution of /usr/lib/dovecot/dovecot-lda.
(note, extracted from mail.log and reformatted a little for readability)
Feb 25 19:2
Package: logwatch
Version: 7.4.3+git20180713-1
Followup-For: Bug #907512
I have the same problem. I am seeing thousands of these lines in my "logwatch
--service secure" output.
The offending log lines are all of the form:
Dec 8 23:36:05 novatech systemd-logind[1332]: Session 10573 logged out.
Package: libnet-upnp-perl
Version: 1.4.4-1
Severity: normal
Tags: patch upstream
[Note: this is a resubmission of the report as I think it got lost in an
unrelated problem on
my system. I cannot find the earlier report but if this is a duplicate I
apologise].
Dear Maintainer,
I recently update
Package: minissdpd
Version: 1.5.20180223-3
Followup-For: Bug #901605
Dear Maintainer,
This bug is NOT resolved in version 1.5.20180223-3 and needs to be reopened.
I have upgraded and am still getting the log spam.
It is possible that I need to edit /etc/default/minissdpd by hand (although
I have
Package: logwatch
Version: 7.4.3+git20161207-2
Followup-For: Bug #906045
Almost all mail delivery on my system happens through sieve but I have
discovered that
the log line format change seems to also affect non-sieve delivery.
The following non-sieve log line is also unmatched:
Aug 15 11:38:15
Package: logwatch
Version: 7.4.3+git20161207-2
Followup-For: Bug #906045
This bug also affects other dovecot sieve loglines. For example, I have seen
the following line:
Aug 14 10:57:46 black dovecot:
lda(default-user)<20273>: sieve:
msgid=<1790644118.7505868.1534240625135.javamail@lsg1-ap
Package: logwatch
Version: 7.4.3+git20161207-2
Followup-For: Bug #906045
Oops, the patch was reversed. This is the correct patch that works for me:
--- /usr/share/logwatch/scripts/services/dovecot2017-01-21
16:44:03.0 +
+++ dovecot 2018-08-13 15:35:42.869962064 +0100
@@ -
Package: logwatch
Version: 7.4.3+git20161207-2
Severity: normal
I recently upgraded dovecot-sieve to version 1:2.3.2.1-1 (in buster) and
logwatch
is failing to match the sieve log lines. Example sieve log lines are:
Aug 13 15:08:02 black dovecot: lda(cobb)<26533><5ecUM8GQcVulZwAAy7SJiA>: sieve:
Package: logwatch
Version: 7.4.3+git20161207-2
Severity: normal
I am running postfix-policyd-spf-python 2.0.1-1 and postfix 3.1.6-0+deb9u1.
Logwatch is not matching the SPF log lines.
Example log lines:
Jul 30 17:39:16 zaphod policyd-spf[15493]: prepend Received-SPF: Softfail
(mailfrom) identit
Package: tickr
Followup-For: Bug #904590
Note: I have installed tickr 0.7.0~beta3-1 from the upstream website and
it appears to be working well, for my particular uses, of course.
In particular it appears to be working with https: feeds and I have noticed no
new problems yet.
-- System Informati
Package: tickr
Version: 0.6.4-1+b1
Severity: important
More and more feeds are switching to https (often as websites just switch
all traffic from http to https). This seems to have been particularly
this week, as sites react to Chrome making http unacceptable.
I notice that a beta has been out fo
Package: dovecot-sieve
Version: 1:2.3.2.1-1
Severity: normal
I recently upgraded dovecot and it now fails to start sieve processing. syslog
contains:
Error: sieve: Failed to initialize script execution: Invalid
postmaster_address: invalid address `postmaster@' specified for the
postmaster_addr
Package: dovecot-sieve
Version: 1:2.2.35-2
Severity: normal
sieve processing crashes reproducibly with certain emails. This causes
these emails to be bounced with delivery failures.
mail.log contains the following information (backtrace manually reformatted for
readability):
Apr 26 10:04:26 bla
Package: dovecot-sieve
Version: 1:2.2.34-2
Severity: important
dovecot-lda crashes in sieve processing reproducibly with certain emails. This
causes
these emails to be bounced with delivery failures.
mail.log contains the following information (backtrace manually reformatted for
readability):
Package: duplicity
Version: 0.7.16-1
Followup-For: Bug #890645
The command "pip install b2" does seem to work, although I haven't done
exhaustive testing.
I ran the following commands (as root):
apt install python-arrow python-requests python-six python-tqdm python-dateutil
python-funcsigs pyt
Apologies. I made a mistake and was confused about what I already had
installed. I believe the manpage is correct.
Please close the bug.
Package: python-pip
Version: 9.0.1-2
Severity: minor
File: /usr/bin/pip2
man pip includes the following text:
On Debian, pip is the command to use when installing packages for
Python 2, while pip3 is the command to use when
installing packages for Python 3.
That information does not se
Package: duplicity
Version: 0.7.16-1
Followup-For: Bug #890645
I see the same problem, having just upgraded testing.
This is a clear regression: there was no requirement for external libraries
to use duplicity with B2 in previous versions of duplicity. Note that this
will mean that anyone using d
Package: fetchmail
Version: 6.3.26-3
Followup-For: Bug #768843
I note that this bug appears to have caused fetchmail to be removed
from debian testing.
I have used fetchmail for many years, and continue to rely on it.
In fact it is working fine for me on my testing system, with the version
of fet
Package: logwatch
Version: 7.4.3+git20161207-2
Severity: minor
Tags: patch upstream
As we are all encouraged to lock down our SSH/SSL protocols further, I now
get hundreds of log lines telling me that things like key exchange methods
cannot be negotiated.
The patch below summarises the "Unable to
On 10/06/17 22:21, Dominic Hargreaves wrote:
> Unfortunately we won't be able to fix either of these issues before
> stretch releases because we're past the last upload date, even if
> fixes were available.
>
> Given the last few releases of Getopt::Long have contained various
> regressions and r
Apologies, Gregor, for my misunderstanding. I had thought that
libgetopt-long-descriptive-perl provided both. I have now removed
libgetopt-long-descriptive-perl from my system and the problem remains
so, of course, you are right.
By the way, I have confirmed that the problem does NOT occur on my
j
Package: libgetopt-long-descriptive-perl
Version: 0.100-1
Severity: important
Dear Maintainer,
I have just realised that a long-established cron job is not doing what it
should as
Getopt::Long processing of option values is broken. I do not know when this
happened.
It used to work but it no lon
Package: softflowd
Version: 0.9.9-2
Severity: minor
The softflowd package information includes:
Homepage: http://code.google.com/p/softflowd/
That page no longer exists.
There appears to be a relevant page on Github:
https://github.com/davidediger/softflowd
-- System Information:
Debian Relea
Package: upnp-inspector
Version: 0.2.2+dfsg-3
Severity: normal
If I run upnp-inspector I get the following error:
Traceback (most recent call last):
File "/usr/bin/upnp-inspector", line 23, in
from coherence import __version__ as coherence_version
File "/usr/lib/python2.7/dist-packages/c
Package: logwatch
Version: 7.4.1-2
Severity: normal
Tags: patch
Dear Maintainer,
I run a small mail server for which I need to have dovecot imap debug enabled.
Unfortunately, the debugging information fills up my logwatch reports.
As this is for debugging imap problems (which are quite frequent)
Package: logwatch
Version: 7.4.3-1
Severity: normal
Tags: patch
Dear Maintainer,
I am running dovecot imap on several systems. I do not think I have turned on
any special logging or debgging options. But my logwatch output is very full of
lines such as:
**Unmatched Entries**
dovecot: imap(
Package: duplicity
Followup-For: Bug #830896
It turns out that the bucket name I was using on the command line included
Unicode characters: the "-" were actually some Unicode character that looked
like "-" but was not. This was because I had copied the bucket name off the
backblaze web page after
Package: duplicity
Version: 0.7.07.1-1
Severity: normal
I created a Backblaze B2 Cloud Storage account and tried to use it with
duplicity. However all duplicity commands using B2 fail for me with the same
error messages:
/usr/lib/python2.7/dist-packages/duplicity/backends/b2backend.py:211:
Unic
Package: github-backup
Version: 1.20160207-1
Severity: normal
To reproduce:
github-backup GrahamCobb
Gives the errors:
github-backup: Failed to query github for repos:
JsonError "failed to parse field homepage: expected String, encountered Null on
the JSON: Array [Object (fromList [(\"homepage
Package: vagrant
Version: 1.8.1+dfsg-1
Severity: normal
Using the stretch version of vagrant, attempting to install the
"vagrant-libvirt"
plugin fails:
vagrant plugin install vagrant-libvirt
Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
/usr/lib/ruby/2.3.0/rubygems/spec
Package: src:linux
Version: 4.3.5-1
Severity: normal
kernel BUG in btrfs. After BUG system hung and had to be rebooted.
Feb 24 01:53:43 black vmunix: [524578.024484] [ cut here
]
Feb 24 01:53:43 black vmunix: [524578.026952] kernel BUG at
/build/linux-19r8NQ/linux-4.3.5
Package: boinc-app-seti
Version: 7.28~svn3106-1+b1
Severity: normal
Dear Maintainer,
I am getting the following message from BOINC Manager:
Message from server: Your app_info.xml file doesn't have a usable version of
SETI@home v8.
I assume this requires a new release of boinc-app-seti. I have
Package: dovecot-sieve
Version: 1:2.2.18-1
Followup-For: Bug #792669
Please consider increasing the severity of this bug and releasing the package
with the upgraded
pigeonhole asap (probably without additional changes).
I upgraded my main personal mail server last week (after a few weeks of no
Package: awscli
Followup-For: Bug #784798
Installed 1.7.0-1 from unstable and the error went away.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4
Package: github-backup
Version: 1.20141110
Followup-For: Bug #772043
I just upgraded from jessie to stretch and github-backup is now useless:
github-backup GrahamCobb
Usage: github-backup [USERNAME|ORGANIZATION] [--exclude USERNAME/REPOSITORY]
Backs up all forks, issues, etc of a GitHub reposit
Package: awscli
Version: 1.4.2-1
Severity: important
Dear Maintainer,
I just upgraded from jessie to stretch. awscli now does not work...
$ aws
Traceback (most recent call last):
File "/usr/bin/aws", line 15, in
import awscli.clidriver
File "/usr/share/awscli/awscli/clidriver.py", line
Package: emacs21
Version: 21.4a+1-5.7
Followup-For: Bug #528363
This is happening to me every few minutes now. It seems to be the same
problem. Here is the stacktrace...
(gdb) bt
#0 __lll_lock_wait_private () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x7fd97c0c6486 i
Package: bash
Followup-For: Bug #763164
I have upgraded to bash 4.3-11 and this problem is no longer reproducible.
I notice in the changlog that the initial Shellshock fixes have been
replaced with upstream patches, which presumably work a bit differently.
I believe this bug can be closed.
--
Additional info:
The error messages cause MANY other scripts and programs to fail. For
example, 'update-initramfs' now fails (which causes 'apt-get install' to
also fail).
The only fix is to delete all the functions with hyphens and other
punctuation in their name using 'unset -f '.
--
To UNS
Package: bash
Version: 4.3-9.2
Severity: important
I just upgraded to the bash with fixes for Shellshock. All my bash invocations
now produce multiple error messages of the form:
error importing function definition for `BASH_FUNC_a-b'
These errors are reported for all exported functions who's n
Package: kdepimlibs5-dev
Version: 4:4.11.5-4+b1
Followup-For: Bug #747063
I have the same problem.
This prevents upgrading ("apt-get dist-upgrade" fails). I believe the severity
should be set much higher.
Note that "dpkg -r --force-depends kdepim-runtime" allows the upgrade to work
(or, at l
Package: firebird2.5-server-common
Version: 2.5.2.26540.ds4-15
Severity: important
I have just been upgrading an earlier Jessie system to the current version and
get the following error messages during the upgrade:
Setting up firebird2.5-server-common (2.5.2.26540.ds4-15) ...
find: The current d
On 10/11/13 10:50, Patrick Ohly wrote:
> Ubuntu essentially just copies the packaging done by Tino Keitel, who
> recently said that he is willing to enable KDE support if he can get
> help testing that. See
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682520
I am happy to help test in a Debi
Package: src:linux
Version: 3.9.6-1
Severity: important
Dear Maintainer,
After "apt-get dist-upgrade" from Wheezy to Jessie, could not reboot with the
new linux 3.9 kernel. The boot appeared to stop, with the console hung,
shortly after loading the nouveau graphics driver.
The lspci info for
This fix has not fixed the problem I reported.
Today I currently happened to have two messages stuck in my exim sending queue
because of this problem. These messages were not my specially crafted test
messages, just normal mail messages.
Installing openssl 1.0.1e-2 on the receiving system made
On Saturday 09 March 2013 14:44:38 Kurt Roeckx wrote:
> So what upstream asks is to try and reproduce it with s_client.
> At least 1 person reported that this fails for him:
> openssl s_client -connect mail.uni-paderborn.de:465
> And then send "EHLO test"
No, that doesn't fail for me.
I have been
On Saturday 09 March 2013 12:27:29 Kurt Roeckx wrote:
> This is problem the same problem as various other people have
> reported already. My guess is that it goes away when
> you do:
> export OPENSSL_ia32cap=~0x200
Yes
> Can you show the content of /proc/cpuinfo?
It is 4 times this
Package: openssl
Version: 1.0.1e-1
Followup-For: Bug #702635
The postfix problem can be worked around by adding:
smtpd_tls_exclude_ciphers = AES
to the postfix configuration.
By the way, in case it is relevant, the client system showing the problem is
also Debian Wheezy, using exim and openssl
Package: openssl
Version: 1.0.1e-1
Severity: important
I have just upgraded my personal mail server to the latest Wheezy.
Mail submission to postfix from some local clients has stopped working.
The entry in the mail log is:
postfix/smtpd[6543]: warning: TLS library problem: 6543:error:1408F119:S
Package: wine
Version: 1.4.1-4
Followup-For: Bug #690659
I have just removed wine-unstable and moved to the multiarch version of wine.
However, printing didn't work -- the printer appears in the dialog but no
fields are filled in (paper size, etc) and the buttons do nothing.
I checked the Wine Us
On Wednesday 11 July 2012 10:20:37 Fabian Greffrath wrote:
> Packages in Debian should always have alternative dependdencied on
> both, i.e. "libavcodec53| libavcodec-extra-53". Do you have packages
> from other repositories installed?
The problem appears to have been that I had not succeeded in r
Package: libavcodec-extra-53
Version: 6:0.8.3-4
Severity: important
I attempted to follow the instructions on
http://wiki.debian.org/MultimediaCodecs
to install libavcodec-extra-53, however I get the following error from apt-get:
Some packages could not be installed. This may mean that you have
Package: dovecot-core
Version: 1:2.1.7-2
Severity: normal
I upgraded dovecot on my wheezy system from 1:2.0.18-1 to 1:2.1.7-2. This
broke my namespace configuration and dovecot stopped working.
I have the following configuration information in a file called
/etc/dovecot/conf.d/50-grc.conf:
na
Upstream has reported that the workround for the problem is a new option ("-
ai") which was introduced in 2.4.3 (although he also reports that 2.4.4 should
be used due to a bug in 2.4.3).
Could the version with the "-ai" option be brought into Testing? Without this
option, anyone who sees the s
I have added a comment/suggestion to the upstream bug report.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The following script is a simpler way to reproduce the problem.
#!/bin/sh
mkdir a
touch a/test
dar -c first -g a
touch -d yesterday a/test
dar -c second -g a -A first
dar_manager -C testdb
dar_manager -B testdb -A first
dar_manager -B testdb -A second
Note that files with mtime moving backwards i
Package: dar
Version: 2.4.2-1
Severity: important
This is a followup to 637997, which is now archived so opening a new bug.
My earlier assumption that this problem was caused by the bug fixed upstream
in dar 2.4 is incorrect. I have now installed dar 2.4.2.1 (Wheezy) and this
bug is still occu
Package: dar
Version: 2.4.0-1
Severity: important
Upgrading to dar 2.4 has broken my (longstanding) backup script in two ways.
Note: the script is Manuel Iglesias's DAR_automatic_backup.sh, which may be
in use by others. The two problems will be reported in separate bug reports
as the actions are
Package: dar
Version: 2.4.0-1
Severity: normal
This is the second of my bug reports about dar 2.4 breaking existing
backup scripts (in particular, Manuel Iglesias's DAR_automatic_backup.sh
script).
In order to prevent the above error being (incorrectly) reported, my dar
backup script had to be
1 - 100 of 157 matches
Mail list logo
