I just did a quick check and the tools work for me on the current stable
(11.6) and unstable.
The only time they don't start is when X11 is not available like in an ssh
session:
$ java -verbose:class -jar
/usr/share/java/airport-utils/AirportBaseStationConfig.jar
...
[0.170s][info][class,load]
I checked pcs 0.10.1-2 in buster and it turns out it is not vulnerable
to CVE-2022-2735. Separate ruby daemon with a world writable UNIX socket
was introduced later in 0.10.5:
https://salsa.debian.org/ha-team/pcs/-/commits/master/pcsd/pcsd-ruby.service.in
Before that version python code runs
close 1008379 1.5.1-1
thanks
Tested the build of the new package release in sbuild
sid chroot and did not see any problems.
--
Valentin
Hi Paul,
On Thu, Sep 16, 2021 at 08:34:06AM +0200, Paul Gevers wrote:
> It was pointed out to me on IRC that the mount of /tmp with `nodev` is
> probably the issue here. I'm discussion if we should just drop that.
The failing test does not use a device so this probably won't help. I
tried
On Wed, Sep 15, 2021 at 09:24:08PM +0200, Paul Gevers wrote:
> I looked at the results of the autopkgtest of you package on amd64
> because with a recent upload of glibc the autopkgtest of ocfs2-tools
> fails in testing. It seems to me that the failures are related to the
> worker that the test
On Sun, Aug 01, 2021 at 09:45:00PM +0200, Valentin Vidic wrote:
> Thanks, that does sound similar to what I was getting there. I will try
> to see if it still happens with the latest installer. And since it
> crashes on start I had no way to access the logs or dmesg of the
> mach
On Sun, Aug 01, 2021 at 05:10:07PM +0200, Cyril Brulebois wrote:
> Valentin Vidic (2021-08-01):
> > No problem, I was not able to reproduce this reliably or get a core
> > dump for this crash. It could just be an emulation problem with qemu
> > or some timing issue for the
On Mon, May 03, 2021 at 08:36:58AM +0200, Cyril Brulebois wrote:
> Also adding to the list of bugs to keep an eye on (again, possibly not
> blocking the release on its being resolved; we could have the issue
> listed in errata, and possibly fixed in a point release).
Thanks, here is another one
On Mon, May 03, 2021 at 08:58:02AM +0200, John Paul Adrian Glaubitz wrote:
> > The same issue exists on s390x but isn't apparently going to get fixed
> > so we need to have d-i be smarter (hence the merge request)?
>
> Seems so.
QEMU console might get fixed in the kernel, but it looks like LPAR
Hi,
Probably not critical, but maybe these installation bugs on s390x could
be fixed for the release?
rootskel: steal-ctty no longer works on at least sparc64
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
debian-installer: qemu-system-s390x installation fails due to segfault in
user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-04-AT-Salzburg
thank you
--
Valentin
On Mon, Nov 23, 2020 at 11:46:54AM +0100, Matthias Klose wrote:
> Package: src:fence-agents
> Version: 4.6.0-2
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.9
>
> fence-agents autopkg tests time out, might not be Python 3.9 specific.
Yup,
One of autopkgtests in fence-agents package seems to be broken
in the same way - just hangs in wait forever and using bash works:
https://salsa.debian.org/ha-team/fence-agents/-/blob/master/debian/tests/delay
--
Valentin
Package: bgpdump
Version: 1.6.0-1
Severity: grave
Dear Maintainer,
The program segfaults when started:
$ bgpdump
Segmentation fault
Based on gdb info it seems like the call to log_to_stderr fails:
(gdb) bt
#0 0x2246 in ?? ()
#1 0x77fef5cf in main ()
(gdb) disas main
Package: wnpp
Severity: wishlist
Owner: Valentin Vidic
* Package name: google-auth-httplib2
Version : 0.0.3
Upstream Author : Google Cloud Platform
* URL :
https://github.com/GoogleCloudPlatform/google-auth-library-python-httplib2
* License : Apache 2.0
patch for removing fence_amt_ws (Closes: #934519)
+
+ -- Valentin Vidic Sun, 29 Sep 2019 12:27:01 +0200
+
fence-agents (4.0.25-1+deb9u1) stretch; urgency=medium
* fence_rhevm: add patch for CVE-2019-10153 (Closes: #930887)
diff -Nru fence-agents-4.0.25/debian/patches/remove-fence_amt_ws
fence
fence_amt_ws (Closes: #934519)
+
+ -- Valentin Vidic Sun, 29 Sep 2019 11:54:16 +0200
+
fence-agents (4.3.3-2) unstable; urgency=high
* fence_rhevm: add patch for CVE-2019-10153 (Closes: #930887)
diff -Nru fence-agents-4.3.3/debian/patches/remove-fence_amt_ws
fence-agents-4.3.3/debian/patches
On Mon, Mar 25, 2019 at 03:45:58PM +0100, Andreas Beckmann wrote:
> In that case you should probably add Breaks+Replaces against all of the
> old -dev packages that were merged, just to be on the safe side.
Yes, that is the plan. I think wferi will take care of it if he
has time?
--
Valentin
On Sat, Mar 23, 2019 at 05:19:59PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'wheezy' to 'jessie' to 'stretch' to 'buster'.
> It installed fine in 'wheezy', and upgraded to 'jessie' and 'stretch'
> successfully,
> but then the
On Tue, Feb 19, 2019 at 10:26:09AM +0100, Christoph Martin wrote:
> What can we do to not loose these packages (burp in my case)?
>
> librsync 2.0.2-1~exp1 was uploaded to experimental three days ago.
csync2 seems to build fine with librsync2 from experimental so if
you can upload that to
On Tue, Feb 19, 2019 at 10:26:09AM +0100, Christoph Martin wrote:
> What can we do to not loose these packages (burp in my case)?
>
> librsync 2.0.2-1~exp1 was uploaded to experimental three days ago.
I guess librsync2 would need to go into unstable and testing. Than
we can try to update our
Hi,
Not sure why grave so late in the release process that we lose
some packages (csync2 in my case)? grave after the release would
give us more time to move to librsync2.
--
Valentin
On Thu, Jan 24, 2019 at 10:27:39PM +0100, Valentin Vidic wrote:
> Password file indeed seems to be empty on stretch:
>
> drwxr-x--- 2 root coroqnetd 4096 Jan 24 22:22 .
> drwxr-xr-x 3 root root 4096 Jan 24 22:22 ..
> -rw-r- 1 root coroqnetd 65536 Jan 24 22:22 cert8.db
On Sun, Jan 20, 2019 at 05:07:25PM +0100, Andreas Beckmann wrote:
> Setting up corosync-qnetd (3.0.0-1) ...
> password file contains no data
> Invalid password.
> certutil: Could not set password for the slot: SEC_ERROR_INVALID_ARGS:
> security library: invalid arguments.
> dpkg: error
On Fri, Jan 11, 2019 at 12:32:05AM +0530, Pirate Praveen wrote:
> Package: pcs
> Version: 0.9.166-5
> Severity: serious
>
> https://ci.debian.net/packages/p/pcs/unstable/amd64
>
> May be 0.10 version has a fix, it is delaying rails 5 testing
> migration, so please fix it.
Yep, I'm looking at
close 911801
thanks
Trying to run the setup command always returns 401:
# pcs cluster setup --name pacemaker1 stretch1 stretch2
Error: stretch1: unable to authenticate to node
Error: stretch2: unable to authenticate to node
Error: nodes availability check failed, use --force to
On Thu, Oct 25, 2018 at 05:11:17PM +, Duncan Hare wrote:
> root@greene:/home/duncan# pcs cluster setup --name pacemaker1 pinke greene
> greene: Authorized
> pinke: Authorizedroot@greene:/home/duncan#root@greene:/home/duncan# pcs
> cluster setup --name pacemaker1 pinke greene --force
>
On Wed, Oct 24, 2018 at 05:19:02PM -0700, Duncan Hare wrote:
> Package: pacemaker
> Version: 1.1.16-1
> Severity: grave
> Justification: causes non-serious data loss
I've reassigned this to pcs package, since it probably doesn't have to
do with pacemaker, but I'm not sure what is going on here.
Check exit codes from each of the subdirectories.
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index dd29bcea..ab069a1c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,2 +1,2 @@
all install clean: %:
- for d in libdlm dlm_controld dlm_tool
On Tue, Oct 16, 2018 at 09:22:22PM +0200, Helmut Grohne wrote:
> The upstream Makefile runs submakes in a for loop without any error
> trapping. Thus it continues building even in the presence of failures.
> Doing so violates the Debian policy section 4.6. The recommended
> solution is adding "set
On Fri, Jul 06, 2018 at 12:50:42PM +0200, Ferenc Wágner wrote:
> Thanks for the report. I've been pretty busy with other tasks, but I'll
> check this out as soon as possible, your report isn't forgotten. I ask
> for you patience till then.
Feri, you still want to check this or should we close
On Fri, Jul 06, 2018 at 04:43:00PM -0400, Jason Gauthier wrote:
> Now, it's entirely possible that I do have a configuration issue
> causing corosync-qdevice to not start. However, the real issue is
> that corosync-qdevice does not log anything to stdout when run with
> "-f -d" (foreground,
On Fri, Jun 22, 2018 at 09:46:36AM -0400, Jason Gauthier wrote:
> corosync-qdevice is a daemon that runs on each cluster node that help
> provide a voting subsystem that utilizes corosync-qnet outside the
> cluster.
>
> After installing the packages from debian stretch, and configuring the
>
On Sat, Jun 09, 2018 at 02:41:24PM +0200, Ferenc Wágner wrote:
> Are those .a (and .la) files really needed? We mostly avoid shipping
> them, see:
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev
>
On Tue, May 29, 2018 at 09:54:13AM +0200, Emilio Pozuelo Monfort wrote:
> Your package failed to build on a rebuild against libcurl4:
>
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../include
> -I../../../include -I../../../include -I../../../linux-ha -I../../../linux-ha
>
On Wed, May 02, 2018 at 11:02:55PM +0200, Valentin Vidic wrote:
> Thanks, I can reproduce the errors too and will try to figure it out.
> The build was definitely working less than month ago when the last
> version was released, so something else in the system has changed.
After updat
On Wed, May 02, 2018 at 10:44:33PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
Thanks, I can reproduce the errors too and will try to figure it out.
The build was definitely working less than month ago when the last
version was
On Tue, Feb 27, 2018 at 08:22:50PM +0100, Valentin Vidic wrote:
> Since I can't reproduce it easily anymore I suspect something was
> fixed in the meanwhile. My original report was for 4.9.30-2+deb9u2
> and since then there seems to be a number of fixes that could be
> related to
On Tue, Feb 27, 2018 at 05:05:06PM +0100, Hans van Kranenburg wrote:
> ad 1. Christian, Valentin, can you give more specific info that can help
> someone else to set up a test environment to trigger > 32 values.
I can't touch the original VM that had this issue and tried to
reproduce on another
On Mon, Jan 29, 2018 at 11:16:51AM +0200, Adrian Bunk wrote:
> Source: booth
> Version: 1.01.0-5
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=booth=all=1.0-5=1516927397=0
>
> ...
> FAILED (failures=1)
The unit tests enabled in the last release are failing for unknown
On Mon, Jan 15, 2018 at 11:12:03AM +0100, Christian Schwamborn wrote:
> Is there a easy way to get/monitor the used 'grants' frames? As I understand
> it, the xen-diag tool you mentioned doesn't compile in xen 4.8?
Here is a status from another host:
domid=0: nr_frames=4, max_nr_frames=256
On Mon, Jan 15, 2018 at 11:12:03AM +0100, Christian Schwamborn wrote:
> Is there a easy way to get/monitor the used 'grants' frames? As I understand
> it, the xen-diag tool you mentioned doesn't compile in xen 4.8?
I just gave it another try and after modifying xen-diag.c
a bit to work with 4.8
On Fri, Jan 12, 2018 at 01:34:10AM +0100, Hans van Kranenburg wrote:
> Is the 59 your lots-o-vcpu-monster?
Yes, that is the one with a larger vcpu count.
> I just finished with the initial preparation of a Xen 4.10 package for
> unstable and have it running in my test environment.
Unrelated to
On Sun, Jan 07, 2018 at 07:36:40PM +0100, Hans van Kranenburg wrote:
> Recently a tool was added to "dump guest grant table info". You could
> see if it compiles on the 4.8 source and see if it works? Would be
> interesting to get some idea about how high or low these numbers are in
> different
On Sat, Jan 06, 2018 at 11:17:00PM +0100, Hans van Kranenburg wrote:
> I agree that the upstream default, 32 is quite low. This is indeed a
> configuration issue. I myself ran into this years ago with a growing
> number of domUs and network interfaces in use. We have been using
>
On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote:
> According to that link, the fix seems to be configuration rather than code.
> Does this mean this bug against the kernel should be closed?
Yes, the problem seems to be in the Xen hypervisor and not the Linux
kernel itself. The
Hi,
The problem seems to be caused by the new multi-queue xen blk driver
and I was advised by the Xen devs to increase the gnttab_max_frames=256
parameter for the hypervisor. This has solved the blocking issue
for me and it has been running without problems for a few months now.
I/O to LUNs
close 753235
thanks
On Mon, Aug 07, 2017 at 02:31:57PM -0400, Ferenc Wágner wrote:
> There's no problem with the Pacemaker libs, the "missing" symbols are a
> manifestation of the binutils incompatibility in the libqb headers.
Ok, didn't realize the pacemaker FTBFS was caused by the libqb problem.
Even better, than
On Mon, Aug 07, 2017 at 09:31:22AM -0400, Ferenc Wágner wrote:
> Absolutely, thanks for this very good find, Valentin! These symbols
> caused problems on non-x86 architectures before, and now libqb is broken
> for good (so we should probably merge this into #871153). Let's see
> what upstream
On Fri, Jul 28, 2017 at 04:14:47PM +0300, Adrian Bunk wrote:
> Source: pacemaker
> Version: 1.1.17-1
> Severity: serious
>
> Some recent change in unstable makes pacemaker FTBFS:
>
> https://tests.reproducible-builds.org/debian/history/pacemaker.html
>
On Fri, Mar 10, 2017 at 04:31:33PM +0100, Ronny Schneider wrote:
> as i installed the heartbeat-package in Debian Stretch, heartbeat failed to
> set the ip adresses, since the command "ifconfig" cannot be run. This command
> is part of the "net-tools"-Package and thus needed until heartbeat is
On Wed, Dec 21, 2016 at 03:32:39PM +0100, Valentin Vidic wrote:
> node1 IPaddr2::192.168.122.101/24/ens3 drbddisk::drbd0 LVM::cluster
> Filesystem::/dev/cluster/srv::/srv::ext4 mysql
> apache::/etc/apache2/apache2.conf
Also found the following problem in resource-agents but
again no
On Wed, Dec 21, 2016 at 02:24:00PM +0100, Patrick Matthäi wrote:
> DRBD+lvm+ext4, apache and mariadb should be enough
IMHO this setup is too complex for v1, but even that
seem to work for me:
node1 IPaddr2::192.168.122.101/24/ens3 drbddisk::drbd0 LVM::cluster
On Wed, Dec 21, 2016 at 01:15:12PM +0100, Patrick Matthäi wrote:
> We tried out many test cases, workarounds, debugging on this issue and
> the result was, that the v1 mode of heartbeat can not deal with the
> dependency system of systemd and will never support it.
Not sure what could be the
On Wed, Jul 06, 2016 at 04:53:05PM +0200, Christian Hofstaedtler wrote:
> Yes, but that is still better than not working at all.
Ok, I'll try to create a service file for the o2cb cluster stack
that is not too complicated.
The pacemaker cluster stack does not need the service files as
it starts
On Fri, May 06, 2016 at 10:21:33AM +0100, Chris Lamb wrote:
> libgfs2 unit tests
>
>24: meta.c FAILED (libgfs2.at:4)
>25: rgrp.c ok
The build test fails for me on unstable too due to a 2 byte increase
On Sat, Jun 08, 2013 at 01:02:56PM +0100, Dominic Hargreaves wrote:
> Source: libhttp-daemon-ssl-perl
> Version: 1.04-3
> Severity: serious
> Justification: FTBFS
>
> This package FTBFS (in a clean sid sbuild session):
>
> Can't call method "get_request" on an undefined value at t/testmodule.t
Same thing here, started segfaulting after an upgrade this morning:
2013-01-14 10:32:13 upgrade asterisk 1:1.6.2.9-2+squeeze8 1:1.6.2.9-2+squeeze9
[783312.661049] asterisk[27654]: segfault at 1 ip b748db77 sp b5319684 error 4
in libc-2.11.3.so[b7418000+14]
[783442.211589] asterisk[13070]:
59 matches
Mail list logo
