On 27/04 11:02, Felix Salfelder wrote:
> > - salsa-ci
> >
> > - open an issue upstream to integrate my two cmake patches for the
> > scenario "build a release without shipping binaries, yet
> > insist on running the tests during our build"
>
> I will see what I can do about these.
Before you go ahead on any of this, please let's wait for Alexandre's
input.
> Something else that might need work.
>
> The freshly imported tarball (0.6.6) contains an embedded dev/asio
> directory, which does not exist in the upstream repository, nor was it
> in the 0.6.4 tarball. I understand that this copy is unnecessary. But
> some test is compiled with -I${top_srcdir}/dev/asio/include.
>
> The embedded asio does not coincide with libasio-dev in sid,
> 1:1.12.2-1. Imo (and I am certainly clueless here) this may lead to
> questionable test results. Technically, We may need to depend on a
> specific libasio-dev.
Definitely not; instead we'd patch the corresponding CMakeLists to
compile against the system-wide asio. As for the 2 above points, let's
wait on Alexandre to see if he thinks this should delay the upload to
NEW.
> The source of this is, upstream is offering multiple tarballs, one
> with third party packages included. This also explains some of
> Sébastiens additions to the copyright file.
Some of them, yes. But there wasn't really any effort put into coming up
with a proper d/copyright with 0.6.4, as my initial "git grep -i
copyright upstream/0.6.4" led me to conclude.
> As of version 0.6.4, none of the additional headers were required for
> either for building opendht or jami.
But the whole point is, they are required to run the unit tests.
> I have imported the smaller tarball and rebased Sébastiens
> commits. It's in my master branch now [1]. I'm afraid the package does
> no longer build, and I am unsure how to proceed.
I'm not sure what to tell you here, except that this operation was
indeed bound to fail.
> My gut feeling is that the small tarball is the correct one, (although
> I can see the other one listed in d/watch), and that the tests should
> be compiled against installed packages, if at all.
I am unsure where your gut feeling comes from: the smaller package is OK
to simply use as an include in a development project. OTOH when building
the Debian package, we're definitely interested in running the
upstream-provided unit tests during a regular build.
Cheers,
--
Seb