Bug#950198: restinio
I've pushed my version of restinio's packaging to https://salsa.debian.org/seb/restinio's master branch. I started from Felix's initial effort, but a lot of things were missing: - d/copyright severely lacking - missing build-deps (most notably on cmake) initially prevented building as-is in a clean chroot - reworked/removed patches to cmake: initial patch had a "CMakeLists hacks; no idea what they are trying to do" comment associated to various changes in upstream CMakeLists. I changed that hack, which was aimed at "just building the package", so that we now run the full suite of unit tests provided by upstream (needed to upgrade to upstream version to 0.6.6 to fully implement that) Let me know if you want me to upload what I've got now to NEW. So we don't forget, here are a couple of items we'll want to fix later on: - 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" Cheers, -- Seb
Bug#950198: restinio
On Mon, Apr 27, 2020 at 09:07:36AM +0200, Sébastien Delafond wrote:
> I've pushed my version of restinio's packaging to
> [..]
> Let me know if you want me to upload what I've got now to NEW.
amazing. thank you.
> So we don't forget, here are a couple of items we'll want to fix later
> on:
>
> - 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.
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.
cheers
felix
Bug#950198: restinio
Please apologise the flood, I missed something obvious.
On Mon, Apr 27, 2020 at 11:02:23AM +0200, Felix Salfelder wrote:
> 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 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.
As of version 0.6.4, none of the additional headers were required for
either for building opendht or jami. 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. 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.
thanks
felix
[1] https://salsa.debian.org/felixs-guest/restinio/master
Bug#950198: restinio
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
Bug#950198: restinio
Thanks Sébastien for your analysis. On Mon, Apr 27, 2020 at 12:10:35PM +0200, Sébastien Delafond wrote: > Before you go ahead on any of this, please let's wait for Alexandre's > input. I agree. > 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. My gut feeling.. let me try and explain. First of all, there is no technical requirement for release tarballs of different sizes. The friction is most obvious in the copyright file. But also distributing stuff that is packaged elsewhere is against the packaging guidelines [1] in a similar context (repacking). """ 6.7.8.2.2 [the package] should not contain any file that does not come from the upstream author(s). """ Then, I do not believe that source files "come from upstream" authors just because they inadvertendly bundle third party work into some kind of "convenience" tarball. Beyond belief, the package (as I did it) is in fact based on the upstream git repo, so this is where "upstream" comes from. And I am in good society doing it that way [2]. """ There is absolutely no technical reason to not use the upstream git repository as the basis for the git repository used in Debian packaging. I would never package software maintained in a git repository upstream and not do so. """ I hope it is more clear now, how I prefer to use the small tarball over running the tests, as a matter of principle. The tests can be added later, once it will be practical, e.g. with a patch, and maybe some other dependencies packaged. regards felix [1] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html [2] http://joeyh.name/blog/entry/upstream_git_repositories/
Bug#950198: restinio
On 27/04 13:13, Felix Salfelder wrote: > I hope it is more clear now, how I prefer to use the small tarball > over running the tests, as a matter of principle It was perfectly clear the first time, and this is where we can agree to disagree. Starting on this project I had a couple of goals, and what's in my salsa repository right now achieves the three of them: - copyright-clean - runs the upstream tests - should pass NEW As I don't intend to maintain restinio in the long run, I don't feel the need to argue this any further, and will happily defer to Alexandre's opinion. Cheers, -- Seb
Bug#950198: restinio
On Mon, Apr 27, 2020 at 01:22:29PM +0200, Sébastien Delafond wrote: > It was perfectly clear the first time, and this is where we can agree to > disagree. Dear Sébastien. Yes, lets agree. > Starting on this project I had a couple of goals. Towards the original goal (getting Jami into Debian), I have reworded the cmake patch description and improved the package based on your proposed changes. - cleanup rules, add the MULTIARCH bit - more on d/copyright - cmake dependency - d/watch > As I don't intend to maintain restinio in the long run, I don't feel the > need to argue this any further, and will happily defer to Alexandre's > opinion. I acknowledge that running the tests is of importance to you. I will certainly take that into consideration. To proceed, we need restinio in NEW. If you (or anybody else follwing this conversation) wishes to help, please review and/or sponsor [1]. Looking at Alexandre's Jami package, I infer that small(er) tarballs are in his interest. I do not actually know, and if it helps, I am not going to decide how the 0.6.6 package will look like. best regards felix [1] https://salsa.debian.org/felixs-guest/restinio/-/tree/master-0.6.4
Bug#950198: restinio
On 2020-04-28 7:19 a.m., Felix Salfelder wrote: > On Mon, Apr 27, 2020 at 01:22:29PM +0200, Sébastien Delafond wrote: > Towards the original goal (getting Jami into Debian), I have reworded > the cmake patch description and improved the package based on your > proposed changes. > > - cleanup rules, add the MULTIARCH bit > - more on d/copyright > - cmake dependency > - d/watch thank you Seb <3! > >> As I don't intend to maintain restinio in the long run, I don't feel the >> need to argue this any further, and will happily defer to Alexandre's >> opinion. > > I acknowledge that running the tests is of importance to you. I will > certainly take that into consideration. > > To proceed, we need restinio in NEW. If you (or anybody else follwing > this conversation) wishes to help, please review and/or sponsor [1]. Hello, I am following the conversation. > > Looking at Alexandre's Jami package, I infer that small(er) tarballs are > in his interest. I do not actually know, and if it helps, I am not going > to decide how the 0.6.6 package will look like. Alright so I am going to step in on the small or big tarball debate. We definitely want to run the tests if that is possible, and we also want to avoid shipping bundled dependencies if that is possible. Debian isn't only interested in getting Jami working, we are also interested in shipping the most complete restinio package possible. Before I upload anything, can we clear-up where the repository should live? I am already unsure of where I should look to review: at Seb's repository or at Felix's? Can we move this to https://salsa.debian.org/debian ? It would make it much easier for DDs, like me, to step in and help if they want to make patches. I have created a repository here: - https://salsa.debian.org/debian/restinio And: - Gave felix dev permissions on the repository - I have uploaded Seb's work. - Set the VCS-* fields to point to the new repo The build of the package fails on my end: - resolve: Host not found (authoritative) Are the tests trying to contact a server or something? If that is the case, we should eithier selectively disable them or fix them. Or is there something missing from the package that I pushed at https://salsa.debian.org/debian/restinio ? Should I have looked elsewhere? Also, I notice that the package's Changelog already has two entries, but was it even uploaded once? Should it say UNRELEASED instead, until it is uploaded, or should I understand that it was uploaded? Action item before we can upload: - Agree where the package will be maintained (hopefully thats over - debian/restinio) - If we run the tests, they should pass (or was it my machine?) Thank you all for your work :) Cheers -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#950198: restinio
On 03/05 19:40, Alexandre Viau wrote: > Also, I notice that the package's Changelog already has two entries, > but was it even uploaded once? Should it say UNRELEASED instead, until > it is uploaded, or should I understand that it was uploaded? This was my mistake, it should have said UNRELEASED as I definitely did not upload the package. I just changed that. > Action item before we can upload: > - Agree where the package will be maintained (hopefully thats over - > debian/restinio) Agreed. > - If we run the tests, they should pass (or was it my machine?) I re-ran the build this morning from the repository you created, and it passes here in sbuild; TTBOMK it's only binding its test router to 127.0.0.1, and not trying to reach anything outside, but I may be missing something. I add a basic d/salsa-ci.yml, that should tell us what's going on. Cheers, -- Seb
Bug#950198: restinio
On 04/05 09:18, Sébastien Delafond wrote: > I re-ran the build this morning from the repository you created, and it > passes here in sbuild; TTBOMK it's only binding its test router to > 127.0.0.1, and not trying to reach anything outside, but I may be > missing something. > > I add a basic d/salsa-ci.yml, that should tell us what's going on. All the unit tests are passing in salsa: https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500 Cheers, -- Seb
Bug#950198: restinio
On 04/05 10:31, Sébastien Delafond wrote: > > I add a basic d/salsa-ci.yml, that should tell us what's going on. > > All the unit tests are passing in salsa: > > https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500 Hi Alexandre, in the current state, do you think I should upload restinio to NEW? Cheers, -- Seb
Bug#950198: restinio
Yes, go ahead! Sorry I couldn't do it myself quicker, I tend to work on Debian only on the weekends. Thank you for your work!! :) The next step would now be to update OpenDHT, which should be quick once restinio passes new. Cheers, -- Alexandre Viau av...@debian.org On Thu, May 7, 2020 at 2:47 AM Sébastien Delafond wrote: > > On 04/05 10:31, Sébastien Delafond wrote: > > > I add a basic d/salsa-ci.yml, that should tell us what's going on. > > > > All the unit tests are passing in salsa: > > > > https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500 > > Hi Alexandre, > > in the current state, do you think I should upload restinio to NEW? > > Cheers, > > -- > Seb
Bug#950198: restinio
[Alexandre Viau] > The next step would now be to update OpenDHT, which should be quick > once restinio passes new. The restinio package was just accepted into unstable. https://tracker.debian.org/pkg/restinio > -- Happy hacking Petter Reinholdtse
Bug#950198: restinio
On Fri, May 15, 2020 at 11:30:03AM +0200, Petter Reinholdtsen wrote: > [Alexandre Viau] > > The next step would now be to update OpenDHT, which should be quick > > once restinio passes new. > > The restinio package was just accepted into unstable. I am half way through opendht [1]. My package lacks testing (just imported new upstream 2.1.1). I will continue as time permits, but feel free to help. cheers felix [1] https://salsa.debian.org/felixs-guest/opendht
Bug#950198: restinio
On 2020-05-15 5:48 a.m., Felix Salfelder wrote: > On Fri, May 15, 2020 at 11:30:03AM +0200, Petter Reinholdtsen wrote: >> [Alexandre Viau] >>> The next step would now be to update OpenDHT, which should be quick >>> once restinio passes new. >> >> The restinio package was just accepted into unstable. > > I am half way through opendht [1]. My package lacks testing (just > imported new upstream 2.1.1). I will continue as time permits, but feel > free to help. Hello! I have just uploaded a new version of opendht. For the next step I will attempt to build Jami to see if there is anything missing. -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#950198: restinio
[Alexandre Viau] > I have just uploaded a new version of opendht. > > For the next step I will attempt to build Jami to see if there is > anything missing. Hi. Is there any progress on this? I see there is a new version of restino available, perhaps time to update it? I doubt it will solve the atomic issue, but might be a good idea to get the latest fixes into Debian. -- Alexandre Viau av...@debian.org
