Bug#1063951: fixed in barectf 3.1.2-2
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
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
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
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
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
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
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
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
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'
- 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'
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'
- 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'
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
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
On Thu, 19 Nov 2015 13:56:37 + Iain Lanewrote: > 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
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