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