Bug#1068436: transmission RFS
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.
Bug#1068436: transmission RFS
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 > Uploaders: Alexandre Rossi , >Barak A. Pearlmutter > > 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
Bug#1068436: transmission RFS
On Sat, Apr 06, 2024 at 06:43:08PM +, 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 > Uploaders: Alexandre Rossi , >Barak A. Pearlmutter > > 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
Bug#1068436: transmission RFS
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 Uploaders: Alexandre Rossi , Barak A. Pearlmutter 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.
Bug#1068436: transmission RFS
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
Bug#1068436: transmission RFS
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.
