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: 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: 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: 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: 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: 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-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
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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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
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: 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
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
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: 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: 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: 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: 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: 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
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.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.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: 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
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
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.
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 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
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
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: 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
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
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
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: 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+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: 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.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: 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: 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: 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: 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: 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: 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: 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: 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
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.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
101 - 157 of 157 matches
Mail list logo