Bug#1063951: fixed in barectf 3.1.2-2

[Michael Jeanson]

On 2024-03-24 18:28, Timo Röhling wrote:

Control: reopen -1
Control: notfixed -1 3.1.2-2

On Fri, 15 Mar 2024 21:44:05 + Debian FTP Masters 
 wrote:

   * [2375fb4] Disable pytest8 deprecation warnings (Closes:    #1063951)
 - Also (Closes: #1066742) built with pytest8
Unfortunately, this was not a permanent solution, because the features which 
PytestRemovedIn8Warning has been warning about, have been actually removed now 
(pytest 8.1).



Cheers
Timo




They seem to have renamed 'PytestRemovedIn8Warning' to
'PytestRemovedIn9Warning' and we can't ignore a non-existent exception
type without generating an error. When I remove it from the ignore list and 
just keep the 2 DeprecationWarning types, I can successfully run the test 
suite with pytest 8.1.1.


I'll go for this until upstream adds support for pytest8.

Michael

Bug#976920: liburcu: FTBFS on ppc64el: dh_auto_test: error: make -j160 check VERBOSE=1 regtest returned exit code 2

[Michael Jeanson]

On Wed, Dec 9, 2020 at 4:09 AM Lucas Nussbaum  wrote:
>
> Source: liburcu
> Version: 0.12.1-1
> Severity: serious
> Justification: FTBFS on ppc64el
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
>
> I'm marking this bug as severity:serious since your package currently has
> ppc64el binary packages in unstable (so this is a regression).
>

That is a lot of CPUs, I'll check with the upstream author why there
is a 128 threads limit in the test suite.

Bug#931147: gdb depends on newer libbabeltrace

[Michael Jeanson]

On 2019-08-24 6:12 a.m., Andreas Beckmann wrote:
> Followup-For: Bug #931147
> 
> Hi,
> 
> I've just opened a PU request for babeltrace and a binNMU request
> for gdb etc. to get this fixed in buster, too.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935583
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935588
> 
> Andreas
> 

Thanks for doing this, I appreciate the help.

Michael

Bug#910577: gdb-multiarch: libbabeltrace1 dependency not tight enough

[Michael Jeanson]

On 2018-12-11 2:54 p.m., Adrian Bunk wrote:
> Most important is to fix the root cause:
> 
> $ cat /var/lib/dpkg/info/libbabeltrace1\:amd64.shlibs 
> libbabeltrace-ctf-metadata 1 libbabeltrace1
> libbabeltrace-ctf-text 1 libbabeltrace1
> libbabeltrace-ctf 1 libbabeltrace1
> ...
> $ 
> 
> Reverse dependencies could then be fixed for buster by binNMU.

Ok, so if I understand correctly.

Either, "libbabeltrace-ctf1" should be added to the dependencies of the
3 ctf shared objects in the shlibs file. That way packages that link
with any of theses libs will have an explicit dependency on
"libbabeltrace-ctf1", which will work with both old and new babeltrace
packages.

Or the dependency on "libbabeltrace1" should be versioned to explicitly
pull a package that includes the ctf sub-library.

Do you have an opinion on which of these solutions is preferable.

Thanks,

Michael

Bug#910577: gdb-multiarch: libbabeltrace1 dependency not tight enough

[Michael Jeanson]

On 2018-11-26 3:51 p.m., Adrian Bunk wrote:
> Control: reassign -1 libbabeltrace1 1.5.3-2
> Control: severity -1 serious
> Control: affects -1 gdb-multiarch
> 
> On Mon, Oct 08, 2018 at 11:35:10AM +0200, Matthias Urlichs wrote:
>> Package: gdb-multiarch
>> Version: 8.1-4
>> Severity: important
>>
>> gdb-multiarch requires libbabeltrace-ctf1.
>>
>>   --\ Versions of libbabeltrace-ctf1 (3) 
>>
>> p1.5.1-1
>> i1.5.6-1
>> i A  libbabeltrace1 1.5.6-1
>>
>> Apparently the build process picks up the fact that libbabeltrace-1.5.6-1
>> contains the -ctf sub-library, but then doesn't depend on >=1.5.6.
>> Thus 1.5.1 ends up being installed, which doesn't contain the plugin.
>> ...
> 
> Reassigning to libbabeltrace1 where this bug should be fixed.
> 
> cu
> Adrian
> 

Hi,

I'm quite unsure how to fix this properly. I understand the problem but
every solution I come up with involves modifying already released
packages. I'm open to any suggestion.

Michael

Bug#897483: ust: FTBFS: LTTngUst.c:20:10: fatal error: org_lttng_ust_LTTngUst.h: No such file or directory

[Michael Jeanson]

On 2018-05-02 04:07 PM, Lucas Nussbaum wrote:
> Source: ust
> Version: 2.10.1-2
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. 
>> -I../include/lttng  -I../include -I../include 
>> -I/usr/lib/jvm/default-java/include 
>> -I/usr/lib/jvm/default-java/include/linux -Wdate-time -D_FORTIFY_SOURCE=2 
>> -Wall -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
>> -Wformat -Werror=format-security -c -o LTTngUst.lo LTTngUst.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/lttng 
>> -I../include -I../include -I/usr/lib/jvm/default-java/include 
>> -I/usr/lib/jvm/default-java/include/linux -Wdate-time -D_FORTIFY_SOURCE=2 
>> -Wall -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
>> -Wformat -Werror=format-security -c LTTngUst.c  -fPIC -DPIC -o 
>> .libs/LTTngUst.o
>> LTTngUst.c:20:10: fatal error: org_lttng_ust_LTTngUst.h: No such file or 
>> directory
>>  #include "org_lttng_ust_LTTngUst.h"
>>   ^~
>> compilation terminated.
>> make[4]: *** [Makefile:501: LTTngUst.lo] Error 1
> 
> The full build log is available from:
>http://aws-logs.debian.net/2018/05/02/ust_2.10.1-2_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 

Hi,

That's surprising, I did a source upload a week or so ago that built
fine on the buildds. Looking at both build logs the difference seems to
be that the default jdk changed from 9 to 10.

I'll try to reproduce the failure on my system and fix it.

Thanks for the heads up,

Michael

Bug#885556: multipath-udeb: depends on a non-udeb package: liburcu6

[Michael Jeanson]

On 2018-01-14 22:02, Cyril Brulebois wrote:
> clone 885556 -1 reassign -1 src:liburcu 0.10.0-2 retitle -1 please
> provide a udeb severity -1 important block 885556 by -1 thanks
> 
> 
> Hi,
> 
> Cyril Brulebois  (2017-12-28):
>> [Please keep debian-boot@ in copy of your replies.]
>> 
>> Hi,
>> 
>> Your udeb package depends on a non-udeb package (liburcu6),
>> making it uninstallable on all architectures.
> 
> So, looking at the source, it seems liburcu really isn't an option,
> as it's hardcoded in a few makefiles, etc. I've drafted a patch to
> add a udeb to src:liburcu, which you'll find attached.
> 
> Let's see if I got the BTS dance right. :)
> 
> 
> Cheers,

Hi,

I've uploaded 0.10.0-3 with the included patch and some other minor
packaging fixes, it's sitting in the NEW queue because of the added udeb.

Regards,

Michael

Bug#879088: babeltrace: package merge makes gdb, linux-perf etc. uninstallable

[Michael Jeanson]

On 2017-10-19 04:18, Adrian Bunk wrote:
> Control: retitle -1 Please make libbabeltrace-ctf{1,-dev} provides versioned
> 
> On Thu, Oct 19, 2017 at 08:28:46AM +0100, Simon McVittie wrote:
>> ...
>> Please do one of these as soon as possible:
>> ...
> 
> None of these is required.
> 
> Making the libbabeltrace-ctf{1,-dev} provides versioned is all that is 
> required to fix the versioned (build) dependencies.
> 
> cu
> Adrian
> 

Sorry for that mess, I will upload a fixed package with the versioned
provides. Thanks for pointing me in the right direction.

Cheers,

Michael

Bug#867465: ceph-base: purging ceph-base deletes /etc/ceph/rbdmap owned by ceph-common

[Michael Jeanson]

Hi,

Here is a simple fix for this bug, both ceph-common and ceph-base delete
'etc/ceph' on purge in their postrm script but only ceph-common owns
files in this directory. Just remove the cleanup code from the ceph-base
postrm script.

Cheers,

Michael
>From bb8312996cf030e0846f458009558b42145a6061 Mon Sep 17 00:00:00 2001
From: Michael Jeanson <mjean...@efficios.com>
Date: Thu, 14 Sep 2017 15:28:51 -0400
Subject: [PATCH] Don't clean dirs on postrm in ceph-base (Closes: #867465)

Cleanup of the /etc/ceph directory on purge is already handled by
ceph-common which owns files in the directory.
---
 debian/ceph-base.postrm | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/ceph-base.postrm b/debian/ceph-base.postrm
index 48e4853c0..31272029c 100644
--- a/debian/ceph-base.postrm
+++ b/debian/ceph-base.postrm
@@ -24,8 +24,6 @@ case "$1" in
 ;;
 
 purge)
-	rm -rf /var/log/ceph 
-	rm -rf /etc/ceph
 ;;
 
 upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-- 
2.14.1

Bug#821795: lttng-modules-dkms: module FTBFS in jessie against Linux 3.16: error: conflicting types for 'trace_mm_page_alloc_extfrag'

[Michael Jeanson]

- On Jul 12, 2016, at 5:17 PM, Jon Bernard jbern...@debian.org wrote:

> * Michael Jeanson <mjean...@ubuntu.com> wrote:
>> Hi Jon,
>> 
>> Here is an updated debdiff, it works on a fully updated jessie. Should
>> we track these updates in a branch of the collab-maint repo?
> 
> Excellent, thanks.  This patch works and I've put it into a dedicated
> stable branch 'jessie' so this will be easier to track.
> 
> In looking at the stable update procedure, I need to request permission
> to submit an update and I wonder: would it be more valuable to update
> our Jessie version (2.5.1) to the latest supported stable version
> upstream (2.5.6) and rebase these patches on that version?  Give that
> upstream supports a stable branch (which I think is unusual, but very
> awesome), this looks like a compelling approach.
> 
> Thoughts?

If minor version bumps are allowed in Debian, then it would make a lot
more sense to update to the latest 2.5.x bugfix release.

Michael

Bug#821795: lttng-modules-dkms: module FTBFS in jessie against Linux 3.16: error: conflicting types for 'trace_mm_page_alloc_extfrag'

[Michael Jeanson]

Hi Jon,

Here is an updated debdiff, it works on a fully updated jessie. Should
we track these updates in a branch of the collab-maint repo?

Michael
diff -Nru lttng-modules-2.5.1/debian/changelog 
lttng-modules-2.5.1/debian/changelog
--- lttng-modules-2.5.1/debian/changelog2014-10-24 11:11:35.0 
-0400
+++ lttng-modules-2.5.1/debian/changelog2016-07-04 04:49:26.0 
-0400
@@ -1,3 +1,9 @@
+lttng-modules (2.5.1-2~test2) unstable; urgency=medium
+
+  * Add patches
+
+ -- Michael Jeanson <mjean...@ubuntu.com>  Mon, 04 Jul 2016 17:24:58 -0400
+
 lttng-modules (2.5.1-1) unstable; urgency=medium
 
   * [106d0a8] New upstream version 2.5.1
diff -Nru lttng-modules-2.5.1/debian/lttng-modules-dkms.dkms.in 
lttng-modules-2.5.1/debian/lttng-modules-dkms.dkms.in
--- lttng-modules-2.5.1/debian/lttng-modules-dkms.dkms.in   2014-10-24 
11:11:35.0 -0400
+++ lttng-modules-2.5.1/debian/lttng-modules-dkms.dkms.in   2016-07-04 
04:47:00.0 -0400
@@ -10,7 +10,7 @@
 KCONFIG=true
 fi
 
-MAKE[$i]="make -C $kernel_source_dir 
M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build modules"
+MAKE[$i]="make -C $kernel_source_dir 
M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build modules V=1"
 
 BUILT_MODULE_NAME[$i]="lttng-lib-ring-buffer"
 BUILT_MODULE_LOCATION[$i]="lib/"
@@ -158,13 +158,6 @@
 DEST_MODULE_LOCATION[$i]="/extra/probes"
 i=$((i+1))
 
-if [ "$KCONFIG" = "true" ] && [ -n "$CONFIG_REGMAP" ]; then
-BUILT_MODULE_NAME[$i]="lttng-probe-regmap"
-BUILT_MODULE_LOCATION[$i]="probes/"
-DEST_MODULE_LOCATION[$i]="/extra/probes"
-i=$((i+1))
-fi
-
 if [ "$KCONFIG" = "true" ] && [ -n "$CONFIG_REGULATOR" ]; then
 BUILT_MODULE_NAME[$i]="lttng-probe-regulator"
 BUILT_MODULE_LOCATION[$i]="probes/"
diff -Nru lttng-modules-2.5.1/debian/patches/0001-Fix-discover-Debian-API.patch 
lttng-modules-2.5.1/debian/patches/0001-Fix-discover-Debian-API.patch
--- lttng-modules-2.5.1/debian/patches/0001-Fix-discover-Debian-API.patch   
1969-12-31 19:00:00.0 -0500
+++ lttng-modules-2.5.1/debian/patches/0001-Fix-discover-Debian-API.patch   
2016-07-04 04:41:24.0 -0400
@@ -0,0 +1,257 @@
+From 0aadd8424c7c21259f80da4c97a2b9fef92bd2e9 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
+Date: Mon, 27 Apr 2015 10:57:34 -0400
+Subject: [PATCH 1/2] Fix: discover Debian API
+
+Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
+---
+ Makefile   | 12 ++--
+ Makefile.ABI.workarounds   | 11 
+ abi-debian-version.sh  | 30 ++
+ instrumentation/events/lttng-module/kmem.h | 91 +-
+ lib/Makefile   |  4 ++
+ lttng-kernel-version.h | 14 +
+ probes/Makefile|  4 ++
+ 7 files changed, 161 insertions(+), 5 deletions(-)
+ create mode 100644 Makefile.ABI.workarounds
+ create mode 100755 abi-debian-version.sh
+
+--- a/Makefile
 b/Makefile
+@@ -5,6 +5,8 @@
+ ifneq ($(KERNELRELEASE),)
+ ifneq ($(CONFIG_TRACEPOINTS),)
+ 
++KERNELDIR=${LTTNG_KERNELDIR}
++
+ lttng_check_linux_version = $(shell pwd)/include/linux/version.h
+ lttng_check_generated_linux_version = $(shell 
pwd)/include/generated/uapi/linux/version.h
+ 
+@@ -19,6 +21,8 @@
+ endif
+ endif
+ 
++include $(KBUILD_EXTMOD)/Makefile.ABI.workarounds
++
+ obj-m += lttng-ring-buffer-client-discard.o
+ obj-m += lttng-ring-buffer-client-overwrite.o
+ obj-m += lttng-ring-buffer-metadata-client.o
+@@ -67,14 +71,14 @@
+   CFLAGS = $(EXTCFLAGS)
+ 
+ default:
+-  $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
++  LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
+ 
+ modules_install:
+-  $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
++  LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) 
modules_install
+ 
+ clean:
+-  $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
++  LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
+ 
+ %.i: %.c
+-  $(MAKE) -C $(KERNELDIR) M=$(PWD) $@
++  LTTNG_KERNELDIR=$(KERNELDIR) $(MAKE) -C $(KERNELDIR) M=$(PWD) $@
+ endif # KERNELRELEASE
+--- /dev/null
 b/Makefile.ABI.workarounds
+@@ -0,0 +1,11 @@
++# Work-around for distro-specific public modules ABI breakages.
++# Some distributions break the public module instrumentation ABI
++# compared to upstream stable kernels without providing other mean than
++# the kernel EXTRAVERSION to figure it out. Translate this information
++# into a define visible from the C preprocessor.
++
++DEB_API_VERSION=$(shell $(KBUILD_EXTMOD)/abi-debian-version.sh $(CURDIR))
++
++ifneq ($(DEB_API_VERSION), 0)
++ccflags-y += -DDEBIAN_API_VERSION=$(DEB_API_VERSION)
++endif
+--- /dev/null
 

Bug#821795: lttng-modules-dkms: module FTBFS in jessie against Linux 3.16: error: conflicting types for 'trace_mm_page_alloc_extfrag'

[Michael Jeanson]

- On Jul 1, 2016, at 10:29 PM, Jon Bernard jbern...@debian.org wrote:
> Hey Michael,
> 
> I just attempted a build with your diff and I'm seeing the attached
> errors.  It looks like the debian-specific ifdefs are not quite right,
> does any of this look familiar?  I'll look at it closer over the holiday
> if you don't get to it sooner.

Looks like the jessie kernel was updated since I made this debdiff, I'll
look into making a new patch, it should be pretty straightforward.

Michael

Bug#821795: lttng-modules-dkms: module FTBFS in jessie against Linux 3.16: error: conflicting types for 'trace_mm_page_alloc_extfrag'

[Michael Jeanson]

Hi,

Here is a debdiff against the current package fixing the build
failure, I'll ask Jon to make a new upload.

Michael


lttng-modules-2.5.1-fix-build.debdiff
Description: Binary data

Bug#805559: FTBFS: Depends: libbabeltrace-dev (< 1.3) but 1.3.1-1 is to be installed

[Michael Jeanson]

On Thu, 19 Nov 2015 16:46:19 +
Iain Lane <la...@debian.org> wrote:

> On Thu, Nov 19, 2015 at 11:25:58AM -0500, Michael Jeanson wrote:
> > […]
> > I've pushed the fix to collab-maint but I don't have upload rights
> > yet, would you mind uploading it?
> 
> I'd love to, but it still fails. :(

That's what happens when I try to go too fast, it's now fixed and
tested.

> 
>   sbuild-build-depends-lttngtop-dummy : Depends: libbabeltrace-dev (<
> 1.3) but 1.3.1-1 is to be installed
> 
> > […]
> > By the way, I'm looking for a second advocate for my DM application,
> > I've been co-maintaining the lttng related packages with Jon
> > Bernard for more than a year now but haven't worked with any other
> > DD yet.
> 
> I'd have to work with you a bit more (just drive-bying here really)
> before being happy to do that - but you only strictly need one
> advocate, even if they encourage more.

Yeah I'd like to have at least 2 sponsors, it just seems more
appropriate.

> 
> Cheers,
> 

Bug#805559: FTBFS: Depends: libbabeltrace-dev (< 1.3) but 1.3.1-1 is to be installed

[Michael Jeanson]

On Thu, 19 Nov 2015 13:56:37 +
Iain Lane  wrote:

> Package: lttngtop
> Version: 0.3-2
> Severity: serious
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu xenial ubuntu-patch
> 
> Hi,
> 
> lttngtop fails to build because it has an upper bound on a versioned
> dependency which is unsatisfiable in unstable now.
> 
>   Some packages could not be installed. This may mean that you have
>   requested an impossible situation or if you are using the unstable
>   distribution that some required packages have not yet been created
>   or been moved out of Incoming.
>   The following information may help to resolve the situation:
> 
>   The following packages have unmet dependencies:
>sbuild-build-depends-lttngtop-dummy : Depends: libbabeltrace-dev
> (< 1.3) but 1.3.1-1 is to be installed Depends: libbabeltrace-ctf-dev
> (< 1.3) but 1.3.1-1 is to be installed E: Unable to correct problems,
> you have held broken packages. apt-get failed.
>   Package installation failed
> 
> I tried dropping the bounds (attached patch) and it builds for me.
> 
> Are they necessary? If so, could you fix the package to work with the
> new babeltrace?
> 
> Cheers,
> 

Hi,

I've pushed the fix to collab-maint but I don't have upload rights yet,
would you mind uploading it?

For the record, the post 1.2 master branch of babeltrace is
incompatible with lttngtop and was supposed to be the next release.
However, as the release date kept sliding, it was decided to apply some
patches on the 1.2 branch and release it as 1.3 and I forgot to update
this package.

By the way, I'm looking for a second advocate for my DM application,
I've been co-maintaining the lttng related packages with Jon
Bernard for more than a year now but haven't worked with any other DD
yet.

Thanks,

Michael

Bug#798244: lttnganalyses ftbfs, missing build dependencies

[Michael Jeanson]

On 15-09-07 05:19 AM, Matthias Klose wrote:
> Package: src:lttnganalyses
> Version: 0.3.0-1
> Severity: serious
> Tags: sid stretch
> 
> [...]
>  fakeroot debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_testroot -O--buildsystem=pybuild
>dh_prep -O--buildsystem=pybuild
>dh_auto_install -O--buildsystem=pybuild
> I: pybuild base:170: /usr/bin/python3.5 setup.py install --root
> /«PKGBUILDDIR»/debian/python3-lttnganalyses
> lttnganalysescli needs the babeltrace package.
>  See https://www.efficios.com/babeltrace for more info.
> 
> E: pybuild pybuild:256: install: plugin distutils failed with: exit code=1:
> /usr/bin/python3.5 setup.py install --root
> /«PKGBUILDDIR»/debian/python3-lttnganalyses
> dh_auto_install: pybuild --install -i python{version} -p 3.5 3.4 --dir .
> --dest-dir /«PKGBUILDDIR»/debian/python3-lttnganalyses returned exit code 13
> make: *** [binary] Error 13
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> debian/rules:7: recipe for target 'binary' failed
> 

This seems to be related to the transition to python 3.5, lttnganalyses
depends on python3-babeltrace which contains a native extension that
wasn't built against python 3.5.

I'm not sure what's the proper way to fix this.

Michael