Well, given that the main maintainer dropped themselves from the
debian/control file, I think the package can be freely adopted,
keeping Leo Antunes on of course in case he reappears. I'll drop the
two of them a note asking for objections, and assuming there are none,
I'd suggest we go ahead with that. What do you think? This would be:

Maintainer: Leo Antunes <cost...@debian.org>
Uploaders: Alexandre Rossi <n...@zincube.net>,
                   Barak A. Pearlmutter <b...@debian.org>

and would allow "proper" uploads, not just NMUs.

I merged your "fix build on bookworm" patch, but the package still
builds fine on a chroot on my own machine, and fails to build on
salsa,
https://salsa.debian.org/bap/transmission/-/pipelines

If you feel like preparing a serious 4.0.5-2 candidate with
*everything* you think belongs included, rather than just a minimal
NMU, that would be great!

What I meant with the pre-built javascript business was that it's more
robust to set things up so *if* the tools to do so are available, that
stuff is rebuilt. But if not, e.g., if someone is building for a small
platform or porting or just wants to build a local copy and doesn't
want to install that stuff, it would use pre-built files instead. This
also makes it easier for porters. This seems like pretty much what
upstream advocates in web/README.md, except the idea is to automate
it. With that stuff in place, it's a lot easier to argue that using
the prebuilt files under some particular circumstance (like some
package is missing from Debian for the moment) is not serious enough
of an issue to delay progression to testing etc.

And yes, your "proper" cmake-test-based -latomic fix is the "right"
way to do it, unlike the sleazy hack I put in debian/rules.

--Barak.

Reply via email to