Hei hei,
On Thu, Sep 30, 2021 at 01:13:54PM +0200, Hans van Kranenburg wrote:
> Hi!
>
> On 9/30/21 12:45 AM, Andy Smith wrote:
> > Hi Alex,
> >
> > On Thu, Sep 30, 2021 at 12:10:32AM +0200, Alexander Dahl wrote:
> >> Am 22.09.21 um 20:54 schrieb Hans van Kra
Hello,
Am 22.09.21 um 20:54 schrieb Hans van Kranenburg:
Hi Ruediger,
On 9/22/21 11:37 AM, H.-R. Oberhage wrote:
Package: xen-system-amd64
Version: 4.14.3-1~deb11u1
After applying the buster security update to xen, my VM won't start
any longer, complaining about a memory allocation error.
Hello,
On Wed, Dec 18, 2019 at 10:37:47PM +0100, Hans van Kranenburg wrote:
> I expect the problem to be related to Linux and the hardware, and not
> specifically Xen. Knowing if the same happens when just booting Linux
> without Xen is valuable debugging info. However, I realize that it's
>
Hello there,
meanwhile I'm running bullseye with kernel v5.3, but the problem
persists and my Xen system is annoyingly unstable due to this bug. I
attach some more logs from the last days and add the debian xen devel
list in Cc. Maybe someone over there has an idea how to fix this. After
all the
Here the promised console logs. Hope that helps.
Greets
Alex
P.S.: sorry I messed up my initial From: address, please use this one.
[251782.115527] [ cut here ]
[251782.115569] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[251782.115622] WARNING: CPU: 0 PID:
Sorry, I messed up. This is a duplicate of #944612. Please close this one.
Greets
Alex
signature.asc
Description: OpenPGP digital signature
Package: src:linux
Version: 5.2.17-1
Severity: important
Dear Maintainer,
my computer crashes after random times of running (few hours to
several days) with kernels from Debian 8, 9, or 10 (but not 7) when
running as xen dom0, always with netdev watchdog timeout on transmit
queue.
It is a home
Hello Axel,
On Thu, Aug 08, 2019 at 10:17:44PM +0200, Axel Beckert wrote:
> I though never ran into this myself (and wasn't aware of that comment
> in mkswap). I also never came across a Raspbian using F2FS so far
> although the idea sounds quite obvious.
FTR, this is no configuration Raspbian
Hello,
I can confirm this problem for Raspbian 10 (buster, after upgrading from
9, stretch) on a F2FS rootfs. Deleting /var/swap, creating it with dd
from /dev/zero and manually mkswap it, solves the problem, the service
starts again then.
swapon failed before with the aforementioned error in
I'm a little emberassed, but after reboot the extension works now in
Firefox. No idea, was has happened, but I guess this can be closed.
o.O
--
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
X AGAINST
Package: webext-browserpass
Version: 2.0.22-2
Severity: important
Dear Maintainer,
while the browser plugin from this package works fine with Chromium,
it does not with Firefox. It is listed in the installed addons, but
there's no toolbar icon nor menu entry to use it. It is also not
possible to
Hei hei,
On Wed, 31 Oct 2018 19:16:11 +0100 Hans van Kranenburg
wrote:
> An alternative that might help you now might be to switch to pvgrub2?
This is an alternative for Debian virtual machines. At least I use
pygrub to boot other distributions, which don't have pvgrub.
So thanks for
Hei hei,
On Fri, Feb 22, 2019 at 07:24:11PM +0100, Hans van Kranenburg wrote:
> The current state of this bug does not really allow anyone other than
> yourself to cause it to progress.
FWIW, I also have problems with Xen and stretch on amd64. Since
upgrading from jessie I get random crashes,
Hei hei,
I just stumbled over an old entry in the Debian Bug tracker.
Am Dienstag, 20. November 2018, 21:56:13 CET schrieb Ron Yorston:
> Christoph Schulz wrote:
> >I could not reproduce the problem with dash, neither with git dash nor
> >with older versions (0.5.8, 0.5.9.1, 0.5.10.2, to name a
Hello,
I can confirm both the boot loop with 4.9.110-1 and that the boot loop
is gone with 4.9.110-3 from stretch-proposed-updates.
HTH & Greets
Alex
--
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
Hei hei,
meanwhile I found Debian bug report #883026 which addresses the same
underlying problem. I'm not familiar with managing those reports,
maybe someone can set this as duplicate?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883026
Greets
Alex
signature.asc
Description: PGP
Hei hei,
I can confirm that behaviour for Raspbian GNU/Linux 9 (stretch), quote
from syslog:
Jul 20 17:17:04 darcy systemd-fsck[96]: fsck.f2fs: invalid option -- 'y'
Jul 20 17:17:04 darcy systemd-fsck[96]: #011Error: Unknown option ?
Jul 20 17:17:04 darcy systemd-fsck[96]: Usage: fsck.f2fs
Package: arpwatch
Version: 2.1a15-2+b1
Followup-For: Bug #221616
Dear Maintainer,
sorry, I missed this info in my last mail, should have used reportbug
in the first place. O:-)
Greets
Alex
-- System Information:
Debian Release: 9.3
APT prefers stable-updates
APT policy: (500,
Hei hei,
I can confirm for arpwatch on Debian 9 (stretch).
There's a Windows 7 laptop on my network, which is frequently used in
other networks. After "returning home" it still has the old IP address
before getting a new one from my DHCP server. arpwatch reports this as
"new station", although
Package: mutt
Version: 1.7.2-1
Followup-For: Bug #534912
Dear Maintainer,
this bug is still not solved in stretch. Trying to open a folder named
'Archiv/Lists/ptxdist.2017' and get this error:
Can't open mailbox Archiv/Lists/ptxdist/2017: no such mailbox
Haven't tried the workaround,
Hei hei,
On Thu, Jul 27, 2017 at 10:27:28AM -0400, Simon Deziel wrote:
> The UseDNS directive was switched to "no" in OpenSSH 6.8 [1]:
>
> * sshd(8): UseDNS now defaults to 'no'. Configurations that match
>against the client host name (via sshd_config or authorized_keys)
>may need to
Package: openssh-server
Version: 1:7.4p1-10+deb9u1
Severity: normal
Dear Maintainer,
I used the 'from' field in authorized_keys with an hostname (fqdn) on
Debian 8 (jessie), which worked fine (openssh-server
1:6.7p1-5+deb8u3). After upgrading the server to stretch, this does
not work anymore.
Package: prosody
Version: 0.9.10-1
Severity: wishlist
Tags: upstream
Dear Maintainer,
upstream released 0.9.11 containing several bugfixes. Especially #648
is annoying in our setup here. See the release announcement:
https://prosody.im/doc/release/0.9.11
Thanks and greets
Alex
-- System
Hei hei,
FWIW, when using prosody with MySQL I have the very same problem.
Workaround is logging in after a reboot and restarting prosody. *sigh*
Greets
Alex
--
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains
Package: owncloud-client
Version: 1.7.0~beta1+really1.6.4+dfsg-1
Severity: important
Tags: upstream
Dear Maintainer,
after upgrade from Wheezy to Jessie on my Samsung NC10 Netbook (Intel
Atom CPU, i386) owncloud-client uses the whole CPU all the time making
the whole system disturbingly slow. My
Hei hei,
On a de locale machine with active systemd I get this output:
lcd4linux (0.11.0~svn1200-2.1+b1) wird eingerichtet ...
Job for lcd4linux.service failed. See 'systemctl status
lcd4linux.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript lcd4linux, action start failed.
Hei hei,
I ran into this again on jessie and investigated a little. This is what
I found out: the file /etc/logcheck/ignore.d.server/ssmtp belongs to the
package ssmtp, not to logcheck-database.
The code actually sending the message matched against is in function
'int ssmtp(char *argv[])'
Package: owncloud
Version: 7.0.2+dfsg-1
Severity: minor
Dear Maintainer,
the file /usr/share/doc/owncloud/examples/lighttpd/owncloud.conf
contains the following line:
alias.url += ( /owncloud/ = /var/lib/owncloud/ )
This will not work, because the application itself is in
Package: logcheck-database
Version: 1.3.16
Severity: normal
Dear Maintainer,
I installed logcheck-database together with ssmtp. The regex for sSMTP
does not match the ssmtp output in syslog, so this
% sudo cat /etc/logcheck/ignore.d.server/ssmtp
^\w{3} [ :0-9]{11} [._[:alnum:]-]+
I can confirm this for jessie and package version 10.0+ds1-1. This is
rather annoying, because at the moment the FreeBSD 9 kernel is removed
on upgrade and you have no running network afterwards making reinstall
older packages over network impossible. I run the 32 bit version in
VMware player on
Hei hei,
upstream applied my change manually to 2.x branch, but the change
itself should be okay. See https://github.com/zfsnap/zfsnap/pull/43
for details.
Greets
Alex
--
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom
Hei hei,
I made a pull request upstream for the change I made:
https://github.com/graudeejs/zfSnap/pull/43
However: upstream seems to rewrite the code for a new major release and
reorganized the code structure so the patch applies to v1.11.1 but not
to master which is in some pre 2.0.0 state at
Package: zfsnap
Version: 1.11.1-2
Severity: important
Tags: upstream
Dear Maintainer,
zfSnap returns the following on kfreebsd-amd64 architecture on every
single call (using --help just to show the effect):
# zfSnap --help
FATAL: Your OS isn't supported
This is due to a check on the output
Hei hie,
Am 2014-03-21 15:52, schrieb John Goerzen:
Just to be clear, what precisely is the output of uname on your system?
GNU/kFreeBSD
If you modify the script to accept that, then does it appear to work?
I didn't test this yet. I'm unfamiliar with zfSnap and wanted to try if
it could
Package: git-daemon-sysvinit
Version: 1:1.7.10.4-2
Severity: minor
Dear Maintainer,
when installing I get these:
Vormals nicht ausgewähltes Paket git-daemon-sysvinit wird gewählt.
(Lese Datenbank ... 30169 Dateien und Verzeichnisse sind derzeit
installiert.)
Entpacken
Package: git-daemon-sysvinit
Version: 1:1.7.10.4-2
Severity: minor
Dear Maintainer,
when changing GIT_DAEMON_DIRECTORY in the /etc/default/git-daemon
coming with the package to e.g. /srv/repos/git the git-daemon is still
called with --base-path=/var/cache because GIT_DAEMON_BASE_PATH has
the
according to the error message it would be possible to add a line like
this to /etc/logrotate.d/lastfmsubmitd and fix this as well:
su root lastfm
not tested however.
Greets
Alex
--
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first
Package: apper
Version: 0.7.2-5
Followup-For: Bug #699681
Hei hei,
I can confirm this for multiarch (this system) and a non multiarch
32bit x86 (virtual) machine at work, both at wheezy. I have apticron
installed in parallel on this machine here, which already downloads
packages in the
I found another entry in the KDE bug database covering the same topic:
https://bugs.kde.org/show_bug.cgi?id=256255
HTH Greets
signature.asc
Description: OpenPGP digital signature
Package: mpd
Version: 0.15.8-1+b1
Severity: normal
I can confirm this behaviour on a Pentium 133 MHz (no MMX) with 192 MB
RAM. Kernel and packages are up to date from Debian Squeeze 2010-03-03.
Skips still appear with nice value of -3 on all mpd processes. CPU load
is between 27% and 69% viewed
confirmed. however, the program doesn't seem to stop.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi,
when cleaning my mail inbox I noticed this open bug report. I don't have
100% CPU load with anymore since several weeks now. I think the update
of libqca2-plugin-gnupg to version 2.0.0~beta3-1 solved this issue. I
think the bug can be closed.
Greets
Alex
--
»With the first link, the chain
Hi,
If you can give it a quick try, that would be great.
Sorry for the late answer. Meanwhile I have signing-party 1.1.1-1
installed and the bug is closed, but I wanted to let you know: the
problem doesn't occur here anymore. :-)
Thanks and greets
Alex
signature.asc
Description: OpenPGP
Package: psi
Version: 0.12.1-1
Severity: normal
Since last week Psi is unusable when I set a GnuPG key in my user
account. When starting the CPU load goes to 100% and doesn't fall
anymore until I close Psi. There's no connection established at all and
chatting is impossible, although option
Package: signing-party
Version: 1.1-2
Severity: normal
I added the following line to my ~/.caffrc
$CONFIG{'mail'} = 'yes';
According to manpage this should have the same effect as calling caff
with '--mail yes'. Commandline option works as intended, but if I set
this option in .caffrc it
Package: lcd4linux
Version: 0.10.1~rc2-2
Severity: normal
lcd4linux tries to connect to MPd at startup and fails. This is because
MPd is started later in the boot process so lcd4linux is not able to
connect yet. If I manually restart lcd4linux later when MPd is already
running everything works
In the case mpd fails to start (this is not always the case) the
database is always corrupted in a similar way. There is a single keyword
in which one character is shifted 16 characters forward. I can open the
database (tag_cache) in a text editor, correct this single wrong
character and
47 matches
Mail list logo
