I use transmission constantly and would be happy to sponsor. In
principle of course: assuming there are no technical show-stoppers.

I already have my own fork on salsa.debian.org/bap/transmission with
some very minor tweaks.

In the meantime, I note that Sandro Tosi has dropped his
maintainership of the package, but pushed a debian/4.0.5-2 tag without uploading. Do you know the status of that?

The two top bugs are a missing -latomic on ARM, which should be easy
enough to work around in debian/rules using
include /usr/share/dpkg/architecture.mk
if ...
and the prebuilt javascript business, which I note from MR/16 you've
been working on. One suggestion I have for that is to set things up so
that *if* the tools are available, the javascript can be rebuilt; but
if not, pre-built versions are used anyway. This would make things
robust, and would I think allow the bug to be downgraded.

I'm also not thrilled with how the build process adds a git hook if it
can. Should probably hot-wire that off, because it seems to present a
potential security issue. Just a quilt patch to disable the entire if(GIT_FOUND) thing at the end of CMakeLists.txt seems about right.
(The Source Control System is supposed to control the build, not vice
versa!)

Anyway, let me know if/when you want me to dput.

Cheers,

--Barak.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

In the meantime, I note that Sandro Tosi has dropped his
maintainership of the package, but pushed a debian/4.0.5-2 tag without uploading. Do you know the status of that?

I have had no answer from both listed maintainers since last January. I
have tried to contact them through salsa comment, bug reports and direct e-mail.

The two top bugs are a missing -latomic on ARM, which should be easy
enough to work around in debian/rules using
include /usr/share/dpkg/architecture.mk
if ...

Maybe this fix should be upstreamed with something looking like a
similar change: https://patch-diff.githubusercontent.com/raw/ccache/ccache/pull/723.patch

and the prebuilt javascript business, which I note from MR/16 you've
been working on. One suggestion I have for that is to set things up so
that *if* the tools are available, the javascript can be rebuilt; but
if not, pre-built versions are used anyway. This would make things
robust, and would I think allow the bug to be downgraded.

I fail to understand how using prebuild versions would fix the bug or
how handling the case where the tools are not available would help.
Would you elaborate on the use case?

I'm also not thrilled with how the build process adds a git hook if it
can. Should probably hot-wire that off, because it seems to present a potential security issue. Just a quilt patch to disable the entire if(GIT_FOUND) thing at the end of CMakeLists.txt seems about right.
(The Source Control System is supposed to control the build, not vice
versa!)

I completely agree but as we are in the context of a NMU, I wanted to
keep focused.

To sum things up, I understand that my upload needs an update for the
missing -latomic issue. I'll prepare an update.

Thanks for your interest,

Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <costela@debian.org>
Uploaders: Alexandre Rossi <niol@zincube.net>,
Barak A. Pearlmutter <bap@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Apr 06, 2024 at 06:43:08PM +0000, Barak A. Pearlmutter wrote:

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 <costela@debian.org>
Uploaders: Alexandre Rossi <niol@zincube.net>,
Barak A. Pearlmutter <bap@debian.org>

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

Note that the package is in the debian namespace on salsa. No need
to NMU, team-uploads can be done by everyone. [1]

[1] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

--
tobi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

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 <costela@debian.org>
Uploaders: Alexandre Rossi <niol@zincube.net>,
Barak A. Pearlmutter <bap@debian.org>

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

Perfect, the end goal being having transmission back in testing ASAP.

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

Should be fixed, d/control syntax issue.

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!

Done.

https://mentors.debian.net/debian/pool/main/t/transmission/transmission_4.0.5-2.dsc

Changes can be reviewed on salsa:
https://salsa.debian.org/niol/transmission

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.

Ok, this feels against DFSG in the sense of including prebuild files
in source, and upstream does it, so I do not see clearly a role for
Debian regarding this. Do you mean removing the Files-Excluded stanzas in d/copyright?

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.

Incuded your hack for the mean time, and will initiate work with upstream
today to have a proper fix in place.

Thanks,

Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Well, it's not a *violation* of the DFSG to include derived files in
the upstream sources, as long as the source needed to regenerate them
is also included. That's often done for bootstrapping compilers.
Source tarballs also often include documentation PDFs and such so
people installing the software can read the documentation without
having to have that part of the build working.

That said, since you've already done the work to get that stuff
generated and debian-build time, I certainly have no objections to
just doing that, and even removing them from the source tarball if you
so desire.

Can't believe I missed the debian/control broken lines. Thanks.

Barring issues, will upload.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)