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.