Package: mitmproxy
Version: 4.0.4-4
Severity: important
Dear Maintainer,
I just installed mitmproxy on a pretty minimal headless system and realized it
doesn't
run withoutout pkg_resources. Installing python3-pkg-resources resolved the
problem.
Adding the dependency should be a easy fix.
(upstream 4.19.12)
Attached you can find the sylog from the crash.
Best regards,
Valentin Kleibel
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel
Hello,
Thanks for your help.
The bug has been reported upstream:
linux-kernel: https://lkml.org/lkml/2021/4/13/672
linux-block:
https://lore.kernel.org/linux-block/b6aea08d-7190-e341-8780-13ba8e015...@vrvis.at/T/#u
kernel.org bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212665
Package: cfengine3
Version: 3.12.1-2
Source: cfengine3
Dear Maintainers,
I noticed a bug in the mpf framework that prevents overriding the master
policy location via augments.
It ist well documented here: https://tracker.mender.io/browse/CFE-2953
I have also attached the patch.
Best regards,
Package: lvm2
Version: 2.03.11-2.1
Source: lvm2
Dear Maintainers,
I recently noticed that lvm2-polld started via sysvinit dies after 60s.
This is due to the daemon arg "-t 60" which makes sense for a systemd
socket but unfortunately not for sysvinit.
Removing the arg fixes the issue, see also
2.0, sector 0
[ 527.124299] aoe: device 42.0 is not up
[ 527.124300] aoe: device 42.0 is not up
[ 527.124316] aoe: device 42.0 is not up
Hope someone can resolve this issue,
thanks for your help,
Valentin Kleibel
[1] https://lkml.org/lkml/2019/8/27/400
Hi
$ ./scripts/get_maintainer.pl ./drivers/block/aoe/
Justin Sanders (supporter:ATA OVER ETHERNET (AOE) DRIVER)
Jens Axboe (maintainer:BLOCK LAYER)
linux-bl...@vger.kernel.org (open list:BLOCK LAYER)
linux-ker...@vger.kernel.org (open list)
Thanks for your help.
The bug has been reported
Hi Salvatore,
Thanks for the report. I assume you can reproduce the issue as well
with 5.10.28-1 in unstable?
I did not test this before as the aoe driver code was not changed at all
in the last 7 months. I can now report that the behavior is exactly the
same running the kernel
Package: cfengine3
Version: 3.15.2-3
Dear Maintainer,
I just noted that cfengine3 still recommends `python` for bullseye and
upwards but this virtual package is no longer available.
Please change this to `Recommends: python3`.
This is especially important as without python the apt-get module
Package: linux-image-amd64
Version: 5.10.92
Source: linux
Dear Maintainers,
while trying to fix #986837 we found another issue in the aoe driver:
Removal of an active aoe device leads to a page fault and inhibits the
removal of the aoe module.
The issue affects all kernels from v4.20-rc1 up to
found 1017944 grub2/2.06-3~deb11u1
severity 1017944 serious
tags 1017944 patch
Dear Maintainers,
We can confirm that this bug affects all pv and pvh domUs that use pvgrub.
The commit responsible is 20239c28 "Bump debhelper from old 10 to 13." [1]
The relevant change in debhelper came with
Package: lvm2
Version: 2.03.16-2
Source: lvm2
X-Debbugs-Cc: debian-init-divers...@chiark.greenend.org.uk
Dear Maintainers,
I kindly ask you to restore the init scripts removed in the commit
"Remove remaining unused init scripts". [1]
I can report that they both are still in use and work fine
#xen-devel is the IRC Xen channel. I just pinged them, I'll wait.
Depending on their answers, I'll post on the xen-devel mailing list.
thanks for the clarification, looking forward to an answer.
Our current workaround is to edit the interface names in the domUs
config to match the wrong
Package: xen-utils-4.17
Version: 4.17.1+2-gb773c48e36-1
Severity: important
Dear Maintainers,
On one of our domUs we discovered that the network interface names were
wrongly assigned since recreating the domU after an upgrade to bookworm.
If over 10 network interfaces are configured the
Package: orphan-sysvinit-scripts
Version: 0.14
Severity: normal
Dear maintainers,
Unfortunately cfengine3 removed it's sysv-init-script in 3.18.2-1.
Version 3.15.7-1 still shipped an init script that is working fine with
the current version 3.21.0-2.
I kindly ask you to add the cfengine3
I posted on xen-devel, you can follow from :
https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg00244.html
(Unfortunately, the formatting is weird via html, split the IRC part on
"- ").
Thank you for posting upstream.
Note that, at first sight, I was told this seems "not-a-Xen"
On [0], you can read "In both cases the device naming is subject to the
usual guest or backend domain facilities for renaming network devices".
It says "naming/renaming", but you can assume "detecting".
I also checked which net_ids udev knows about and the only things that
pop up are:
Hi,
the bug has been mentionned on #xen-devel, will keep you posted.
Thanks. I wasn't able to find such a report, could you link the archive
or post the threads subject so i can find it?
Meanwhile, you may try to force the domU vif names with a letter
The sorting with letters doesn't
Package: cfengine3
Version: 3.21.0-2
Dear Maintainer,
In the shipped masterfiles in cfe_internal/update/update_policy.cf
cfengine does its own search for a python executeable in $PATH to create
a symlink with its preferred interpreter.
But $(sys.bindir) is excluded from the search and
Package: cfengine3
Version: 3.21.0-2
Severity: important
Dear Maintainer.
The default update mechanism in the provided masterfiles will delete a
/usr/bin/python symlink.
The issue is discussed in
https://github.com/cfengine/masterfiles/pull/2591 and a fix suggested:
Hi Jordan, hi all
Just a quick look comparing dlm_tcp_listen_bind between the latest 6.1
and 6.6 stable branches,
it looks like there is a mismatch here with the dlm_local_addr[0] parameter.
6.1
static int dlm_tcp_listen_bind(struct socket *sock)
{
int addr_len;
/* Bind to our port */
Package: linux-image-amd64
Version: 6.1.76+1
Source: linux
Source-Version: 6.1.76+1
Severity: important
Control: notfound -1 6.6.15-2
Dear Maintainers,
We discovered a bug affecting dlm that prevents any tcp communications
by dlm when booted with debian kernel 6.1.76-1.
Dlm startup works
Hi
Would you be able to confirm that the attached patch fixes your issue as well?
Yes it does.
@debian maintainers: is it possible to include this patch in the next
point release?
Thank you for your work,
Valentin
Package: xen-tools
Version: 4.9.2-1
Tags: patch
Dear Maintainers,
The default network interface naming scheme for bookworm don-U's is
enX[num] but the network setup script used to fill
/etc/network/interfaces still assumes eth0 for the first network interface.
I think either the script
Hello,
I'm currently in the process of cleaning up and i noticed this bug i
reported is still open.
Based on what we know now i think the bug can be closed.
To summarize:
* the ordering of network interfaces (and therefore the ethn names) was
never meant to be stable and changed with Xen
25 matches
Mail list logo
