Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Wed, Feb 06, 2019 at 11:11:38AM +0100, Andreas Tille wrote: > Hi Adrian, Hi Andreas, > On Wed, Feb 06, 2019 at 09:57:01AM +0200, Adrian Bunk wrote: > > > > > > Indeed, with this pbbam now passes its autopkgtests on all three > > > architectures in Ubuntu. Attached is a complete patch against pbbam > > > 0.19.0+dfsg-3 for this. > > > > Thanks, I've done NMUs for both this problem and removal of the libpbbam > > provides that caused FTBFS of blasr and pbdagcon. > > > > debdiffs are attached. > > Thanks a lot for your NMUs and the service to attach debdiffs. I > updated the according Git repositories on Salsa. Since there was a race > condition of mails I've uploaded pbbam with (basically) the same changes > as you did. I injected your changelog entry anyway in Git. > Unfortunately when I look at pbbam build logs[1] it seems bug #909071 > can not be considered as solved. :-( > BTW, I previously tried to spent some time into the i386 port but with > no result. :-( #909071 is resolved since pbbam built on amd64/arm64/ppc64el/mips64el. i386 FTBFS is part of #829741, and 32bit and big endian failures are not relevant for testing migration since there are no older binaries for these architectures in the archive. > Regarding your NMUs: You've sent also debdiffs for blasr_5.3.2+dfsg-1.1 > and pbdagcon_0.3+git20161121.000+ds-1.1 but I have not seen any > upload of these. I've commited the debdiffs in Git. I'm just waiting > whether I see some uploads but feel free to ping me whether I should > "sponsor" your changes. They are now uploaded, I had to wait with uploading until the pbbam provides fix was built on mips64el so that they won't FTBFS again due to that. > Thanks again for all your contribution > >Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
Hi Adrian, On Wed, Feb 06, 2019 at 09:57:01AM +0200, Adrian Bunk wrote: > > > > Indeed, with this pbbam now passes its autopkgtests on all three > > architectures in Ubuntu. Attached is a complete patch against pbbam > > 0.19.0+dfsg-3 for this. > > Thanks, I've done NMUs for both this problem and removal of the libpbbam > provides that caused FTBFS of blasr and pbdagcon. > > debdiffs are attached. Thanks a lot for your NMUs and the service to attach debdiffs. I updated the according Git repositories on Salsa. Since there was a race condition of mails I've uploaded pbbam with (basically) the same changes as you did. I injected your changelog entry anyway in Git. Unfortunately when I look at pbbam build logs[1] it seems bug #909071 can not be considered as solved. :-( BTW, I previously tried to spent some time into the i386 port but with no result. :-( Regarding your NMUs: You've sent also debdiffs for blasr_5.3.2+dfsg-1.1 and pbdagcon_0.3+git20161121.000+ds-1.1 but I have not seen any upload of these. I've commited the debdiffs in Git. I'm just waiting whether I see some uploads but feel free to ping me whether I should "sponsor" your changes. Thanks again for all your contribution Andreas. [1] https://buildd.debian.org/status/package.php?p=pbbam -- http://fam-tille.de
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 03:59:55PM -0800, Steve Langasek wrote:
> On Tue, Feb 05, 2019 at 11:10:15PM +0200, Adrian Bunk wrote:
> > On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote:
> > > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote:
> > > > And then there is the unrelated #908269 that currently prevents testing
> > > > migration of pbbam.
>
> > > > Steve seems to be addressing this with
> > > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz
>
> > > Yes, but the net result of this change is that now the autopkgtest fails
> > > by
> > > running out of memory during the package build at test time, which is why
> > > I
> > > haven't submitted a better patch to the BTS.
>
> > > I think the ideal here would be to either have a way to generate just the
> > > single data file we need for the tests, or to capture that file from the
> > > package build and ship it in a binary package, so that we don't have to
> > > do a
> > > full rebuild during the autopkgtests.
>
> > The file is generated during configure, not build.
>
> > As proof of concept, it works to do
>
> > override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard
> > tests/src/cram/pb*.t.in))
> > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
> > dh_auto_configure -O--buildsystem=meson
> > ...
>
> Indeed, with this pbbam now passes its autopkgtests on all three
> architectures in Ubuntu. Attached is a complete patch against pbbam
> 0.19.0+dfsg-3 for this.
Thanks, I've done NMUs for both this problem and removal of the libpbbam
provides that caused FTBFS of blasr and pbdagcon.
debdiffs are attached.
> Thanks,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
diff -Nru pbbam-0.19.0+dfsg/debian/changelog pbbam-0.19.0+dfsg/debian/changelog
--- pbbam-0.19.0+dfsg/debian/changelog 2019-02-04 12:50:20.0 +0200
+++ pbbam-0.19.0+dfsg/debian/changelog 2019-02-06 08:53:24.0 +0200
@@ -1,3 +1,12 @@
+pbbam (0.19.0+dfsg-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply autopkgtest regression fix from Steve Langasek.
+(Closes: #908269)
+ * libpbbam0.19.0: Remove the incorrect Provides: libpbbam.
+
+ -- Adrian Bunk Wed, 06 Feb 2019 08:53:24 +0200
+
pbbam (0.19.0+dfsg-3) unstable; urgency=medium
* Team upload.
diff -Nru pbbam-0.19.0+dfsg/debian/control pbbam-0.19.0+dfsg/debian/control
--- pbbam-0.19.0+dfsg/debian/control2019-02-03 09:00:28.0 +0200
+++ pbbam-0.19.0+dfsg/debian/control2019-02-06 08:52:32.0 +0200
@@ -50,7 +50,6 @@
${misc:Depends}
Pre-Depends: ${misc:Pre-Depends}
Breaks: libpbbam (<< ${source:Version})
-Provides: libpbbam
Replaces: libpbbam
Description: Pacific Biosciences binary alignment/map (BAM) library
The BAM format is a binary, compressed, record-oriented container format
diff -Nru pbbam-0.19.0+dfsg/debian/rules pbbam-0.19.0+dfsg/debian/rules
--- pbbam-0.19.0+dfsg/debian/rules 2019-02-04 12:47:51.0 +0200
+++ pbbam-0.19.0+dfsg/debian/rules 2019-02-06 08:52:46.0 +0200
@@ -26,6 +26,7 @@
override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard
tests/src/cram/pb*.t.in))
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+ dh_auto_configure -O--buildsystem=meson
mkdir -p $(generated_data_dir)
python tests/scripts/generate_data.py $(CURDIR)/tests/data
$(generated_data_dir)
# Fix broken PATH
diff -Nru pbbam-0.19.0+dfsg/debian/tests/control
pbbam-0.19.0+dfsg/debian/tests/control
--- pbbam-0.19.0+dfsg/debian/tests/control 2019-02-03 08:57:09.0
+0200
+++ pbbam-0.19.0+dfsg/debian/tests/control 2019-02-06 08:52:46.0
+0200
@@ -1,11 +1,5 @@
Test-Command: debian/rules override_dh_auto_test
Depends:
- make,
- python,
+ @builddeps@,
pbbamtools,
- python-cram,
- samtools
-Restrictions:
- rw-build-tree,
- allow-stderr,
- build-needed
+Restrictions: rw-build-tree, allow-stderr
diff -Nru pbseqlib-5.3.1+dfsg/debian/changelog
pbseqlib-5.3.1+dfsg/debian/changelog
--- pbseqlib-5.3.1+dfsg/debian/changelog2019-01-28 12:27:41.0
+0200
+++ pbseqlib-5.3.1+dfsg/debian/changelog2019-02-06 09:02:44.0
+0200
@@ -1,3 +1,12 @@
+pbseqlib (5.3.1+dfsg-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove manual dependencies on libpbbam, version build
+dependency on libpbbam-dev to ensure a proper dependency
+is generated.
+
+ -- Adrian Bunk Wed, 06 Feb 2019 09:02:44 +0200
+
pbseqlib (5.3.1+dfsg-2) unstable; urgency=medium
* Team upload.
diff -Nru pbseqlib-5.3.1+dfsg/debian/control pbseqlib-5.3.1+dfsg/debian/control
--- pbseqlib-5.3.1+dfsg/debian/control 2019-01-28 12:27:41.0 +0200
+++
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 11:10:15PM +0200, Adrian Bunk wrote: > On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote: > > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote: > > > And then there is the unrelated #908269 that currently prevents testing > > > migration of pbbam. > > > Steve seems to be addressing this with > > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz > > Yes, but the net result of this change is that now the autopkgtest fails by > > running out of memory during the package build at test time, which is why I > > haven't submitted a better patch to the BTS. > > I think the ideal here would be to either have a way to generate just the > > single data file we need for the tests, or to capture that file from the > > package build and ship it in a binary package, so that we don't have to do a > > full rebuild during the autopkgtests. > The file is generated during configure, not build. > As proof of concept, it works to do > override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard > tests/src/cram/pb*.t.in)) > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > dh_auto_configure -O--buildsystem=meson > ... Indeed, with this pbbam now passes its autopkgtests on all three architectures in Ubuntu. Attached is a complete patch against pbbam 0.19.0+dfsg-3 for this. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru pbbam-0.19.0+dfsg/debian/rules pbbam-0.19.0+dfsg/debian/rules --- pbbam-0.19.0+dfsg/debian/rules 2019-02-04 02:47:51.0 -0800 +++ pbbam-0.19.0+dfsg/debian/rules 2019-02-05 13:58:07.0 -0800 @@ -26,6 +26,7 @@ override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard tests/src/cram/pb*.t.in)) ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) + dh_auto_configure -O--buildsystem=meson mkdir -p $(generated_data_dir) python tests/scripts/generate_data.py $(CURDIR)/tests/data $(generated_data_dir) # Fix broken PATH diff -Nru pbbam-0.19.0+dfsg/debian/tests/control pbbam-0.19.0+dfsg/debian/tests/control --- pbbam-0.19.0+dfsg/debian/tests/control 2019-02-02 22:57:09.0 -0800 +++ pbbam-0.19.0+dfsg/debian/tests/control 2019-02-05 13:58:07.0 -0800 @@ -1,11 +1,5 @@ Test-Command: debian/rules override_dh_auto_test Depends: - make, - python, + @builddeps@, pbbamtools, - python-cram, - samtools -Restrictions: - rw-build-tree, - allow-stderr, - build-needed +Restrictions: rw-build-tree, allow-stderr signature.asc Description: PGP signature
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote: > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote: > > And then there is the unrelated #908269 that currently prevents testing > > migration of pbbam. > > > Steve seems to be addressing this with > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz > > Yes, but the net result of this change is that now the autopkgtest fails by > running out of memory during the package build at test time, which is why I > haven't submitted a better patch to the BTS. > > I think the ideal here would be to either have a way to generate just the > single data file we need for the tests, or to capture that file from the > package build and ship it in a binary package, so that we don't have to do a > full rebuild during the autopkgtests. The file is generated during configure, not build. As proof of concept, it works to do override_dh_auto_test: $(subst .t.in,.deb.t,$(wildcard tests/src/cram/pb*.t.in)) ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) dh_auto_configure -O--buildsystem=meson ... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 12:56:53PM -0800, Steve Langasek wrote: > > Regardless, the autopkgtest problem is not amd64-specific, because at least > for Ubuntu, we do not size our autopkgtest runners any differently on amd64 > than on other architectures. Fixing the autopkgtest to not require a full > source build for one data file would allow the autopkgtest to run (and > likely succeed) on all available archs. OK, I'll check tomorrow (by all means feel free to NMU since we are quite close before freeze and if you find a solution that works on Ubuntu for these packages I'm pretty sure it will work for Debian). I'm too tired now and I'm not sure when I will manage tomorrow. Thanks a lot for your patience Andreas. -- http://fam-tille.de
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 09:45:33PM +0100, Andreas Tille wrote: > Hi Steve, > On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote: > > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote: > > > And then there is the unrelated #908269 that currently prevents testing > > > migration of pbbam. > > > Steve seems to be addressing this with > > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz > > Yes, but the net result of this change is that now the autopkgtest fails by > > running out of memory during the package build at test time, which is why I > > haven't submitted a better patch to the BTS. > > I think the ideal here would be to either have a way to generate just the > > single data file we need for the tests, or to capture that file from the > > package build and ship it in a binary package, so that we don't have to do a > > full rebuild during the autopkgtests. > Thanks a lot for the time you have spent into this leaf package. I > think it is absolutely realistic that this package these days and also > for the next couple of years will be practically used only on amd64 > architecture. It might be sensible to draw a line here and simply > declare this package and its rdepends "Architecture: amd64" and move on > with problems that might affect more users and realistic applications > for other architectures. > What do you think? I have no opinion. I recognize that pretty much everyone working in this domain is using x86, but I also know that Debian and Ubuntu run quite well on both arm64 and ppc64el servers (the other two architectures pbbam supports); and Amazon has recently announced ARM64 cloud instances which are a fraction of the price of x86; so if I were the maintainer I would probably leave these enabled. Regardless, the autopkgtest problem is not amd64-specific, because at least for Ubuntu, we do not size our autopkgtest runners any differently on amd64 than on other architectures. Fixing the autopkgtest to not require a full source build for one data file would allow the autopkgtest to run (and likely succeed) on all available archs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 09:45:33PM +0100, Andreas Tille wrote: > Hi Steve, > > On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote: > > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote: > > > And then there is the unrelated #908269 that currently prevents testing > > > migration of pbbam. > > > > > Steve seems to be addressing this with > > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz > > > > Yes, but the net result of this change is that now the autopkgtest fails by > > running out of memory during the package build at test time, which is why I > > haven't submitted a better patch to the BTS. > > > > I think the ideal here would be to either have a way to generate just the > > single data file we need for the tests, or to capture that file from the > > package build and ship it in a binary package, so that we don't have to do a > > full rebuild during the autopkgtests. > > Thanks a lot for the time you have spent into this leaf package. I > think it is absolutely realistic that this package these days and also > for the next couple of years will be practically used only on amd64 > architecture. It might be sensible to draw a line here and simply > declare this package and its rdepends "Architecture: amd64" and move on > with problems that might affect more users and realistic applications > for other architectures. > > What do you think? All problems discussed are on amd64. > Kind regards > > Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
Hi Steve, On Tue, Feb 05, 2019 at 12:06:22PM -0800, Steve Langasek wrote: > On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote: > > And then there is the unrelated #908269 that currently prevents testing > > migration of pbbam. > > > Steve seems to be addressing this with > > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz > > Yes, but the net result of this change is that now the autopkgtest fails by > running out of memory during the package build at test time, which is why I > haven't submitted a better patch to the BTS. > > I think the ideal here would be to either have a way to generate just the > single data file we need for the tests, or to capture that file from the > package build and ship it in a binary package, so that we don't have to do a > full rebuild during the autopkgtests. Thanks a lot for the time you have spent into this leaf package. I think it is absolutely realistic that this package these days and also for the next couple of years will be practically used only on amd64 architecture. It might be sensible to draw a line here and simply declare this package and its rdepends "Architecture: amd64" and move on with problems that might affect more users and realistic applications for other architectures. What do you think? Kind regards Andreas. -- http://fam-tille.de
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Tue, Feb 05, 2019 at 09:35:23AM +0200, Adrian Bunk wrote: > And then there is the unrelated #908269 that currently prevents testing > migration of pbbam. > Steve seems to be addressing this with > http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz Yes, but the net result of this change is that now the autopkgtest fails by running out of memory during the package build at test time, which is why I haven't submitted a better patch to the BTS. I think the ideal here would be to either have a way to generate just the single data file we need for the tests, or to capture that file from the package build and ship it in a binary package, so that we don't have to do a full rebuild during the autopkgtests. > On Tue, Feb 05, 2019 at 12:04:16AM +0200, Adrian Bunk wrote: > > On Mon, Feb 04, 2019 at 04:36:22PM +0100, Andreas Tille wrote: > > > Hi Adrian, > > > > > > On Mon, Feb 04, 2019 at 01:06:35PM +0200, Adrian Bunk wrote: > > > > >Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or > > > > > directory > > > > > > > > > > I need to make some noise in the team since I'm definitely overworked > > > > > with these pb* packages. It might be that we will loose these for > > > > > Buster. :-( > > > > > > > > the patches for pbbam and pbdagcon should sort out most of the issues. > > > > > > I've now uploaded the old upstream version of pbdagcon. Unfortunately > > > I can not see that pbbam has fixed the build issues[1] - thus I think > > > #909071 needs to be re-opened. > > >... > > > > pbbam does now build on arm64/mips64el/ppc64el, > > this is what #909071 fixed. > > > > pbbam fails its tests on 32bit (#829741) and big endian, > > these are expected failures that won't block migration. > > > > But the pbdagcon build failure points at a bug in pbbam: > > libpbbam0.19.0 is not ABI compatible with the stretch libpbbam, > > so mustn't provide it. > > > > The following changes should fix the latter problem: > > - remove the Provides: libpbbam from libpbbam0.19.0 > > - remove manual dependencies on libpbbam from the following > > source packages (correct dependencies on libpbbam0.19.0 > > are now generated): > > - blasr > > - pbdagcon > > - pbseqlib > > - unanimity > > > > > Kind regards > > > > > > Andreas. > > > > > > > > > [1] https://buildd.debian.org/status/package.php?p=pbbam -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
And then there is the unrelated #908269 that currently prevents testing migration of pbbam. Steve seems to be addressing this with http://launchpadlibrarian.net/409374477/pbbam_0.19.0+dfsg-1ubuntu3_0.19.0+dfsg-1ubuntu4.diff.gz Adrian On Tue, Feb 05, 2019 at 12:04:16AM +0200, Adrian Bunk wrote: > On Mon, Feb 04, 2019 at 04:36:22PM +0100, Andreas Tille wrote: > > Hi Adrian, > > > > On Mon, Feb 04, 2019 at 01:06:35PM +0200, Adrian Bunk wrote: > > > >Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or directory > > > > > > > > I need to make some noise in the team since I'm definitely overworked > > > > with these pb* packages. It might be that we will loose these for > > > > Buster. :-( > > > > > > the patches for pbbam and pbdagcon should sort out most of the issues. > > > > I've now uploaded the old upstream version of pbdagcon. Unfortunately > > I can not see that pbbam has fixed the build issues[1] - thus I think > > #909071 needs to be re-opened. > >... > > pbbam does now build on arm64/mips64el/ppc64el, > this is what #909071 fixed. > > pbbam fails its tests on 32bit (#829741) and big endian, > these are expected failures that won't block migration. > > But the pbdagcon build failure points at a bug in pbbam: > libpbbam0.19.0 is not ABI compatible with the stretch libpbbam, > so mustn't provide it. > > The following changes should fix the latter problem: > - remove the Provides: libpbbam from libpbbam0.19.0 > - remove manual dependencies on libpbbam from the following > source packages (correct dependencies on libpbbam0.19.0 > are now generated): > - blasr > - pbdagcon > - pbseqlib > - unanimity > > > Kind regards > > > > Andreas. > > > > > > [1] https://buildd.debian.org/status/package.php?p=pbbam
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
On Mon, Feb 04, 2019 at 04:36:22PM +0100, Andreas Tille wrote: > Hi Adrian, > > On Mon, Feb 04, 2019 at 01:06:35PM +0200, Adrian Bunk wrote: > > >Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or directory > > > > > > I need to make some noise in the team since I'm definitely overworked > > > with these pb* packages. It might be that we will loose these for > > > Buster. :-( > > > > the patches for pbbam and pbdagcon should sort out most of the issues. > > I've now uploaded the old upstream version of pbdagcon. Unfortunately > I can not see that pbbam has fixed the build issues[1] - thus I think > #909071 needs to be re-opened. >... pbbam does now build on arm64/mips64el/ppc64el, this is what #909071 fixed. pbbam fails its tests on 32bit (#829741) and big endian, these are expected failures that won't block migration. But the pbdagcon build failure points at a bug in pbbam: libpbbam0.19.0 is not ABI compatible with the stretch libpbbam, so mustn't provide it. The following changes should fix the latter problem: - remove the Provides: libpbbam from libpbbam0.19.0 - remove manual dependencies on libpbbam from the following source packages (correct dependencies on libpbbam0.19.0 are now generated): - blasr - pbdagcon - pbseqlib - unanimity > Kind regards > > Andreas. > > > [1] https://buildd.debian.org/status/package.php?p=pbbam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909071: pbbam: FTBFS on every release architecture where it previously built (fwd)
Hi Adrian, On Mon, Feb 04, 2019 at 01:06:35PM +0200, Adrian Bunk wrote: > >Bug#916576: pbdagcon: FTBFS pbdata/Types.h: No such file or directory > > > > I need to make some noise in the team since I'm definitely overworked > > with these pb* packages. It might be that we will loose these for > > Buster. :-( > > the patches for pbbam and pbdagcon should sort out most of the issues. I've now uploaded the old upstream version of pbdagcon. Unfortunately I can not see that pbbam has fixed the build issues[1] - thus I think #909071 needs to be re-opened. Steve, since you suggested the patch - am I missing something? Kind regards Andreas. [1] https://buildd.debian.org/status/package.php?p=pbbam -- http://fam-tille.de
