Bug#1017906: Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
Hello, On Sun 01 Jan 2023 at 05:15PM +01, Paul Gevers wrote: > Hi Sean, > > On Mon, 22 Aug 2022 14:29:56 -0700 Sean Whitton > wrote: >> control: severity 1017906 wishlist > >> > Is there ftp team consensus that either or both of these issues are RC? >> #1017892 is wishlist or not a bug. [...] > >> #1017906 *might* be a problem. [...] > > It seems like you mixed up the bugs in your control message? I'm currently > staring at #1017892 (vendored copies) because it's RC, but I agree with you it > looks much less severe. Given that, do you think #1017906 (no source) should > be raised again until somebody has figured out if there's *no* RC problem? Yes. #1017892 should be wishlist, #1017906 possibly serious, depending on the details. My apologies! -- Sean Whitton signature.asc Description: PGP signature
Bug#1017906: Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
Hi Sean, On Mon, 22 Aug 2022 14:29:56 -0700 Sean Whitton wrote: control: severity 1017906 wishlist > Is there ftp team consensus that either or both of these issues are RC? #1017892 is wishlist or not a bug. [...] #1017906 *might* be a problem. [...] It seems like you mixed up the bugs in your control message? I'm currently staring at #1017892 (vendored copies) because it's RC, but I agree with you it looks much less severe. Given that, do you think #1017906 (no source) should be raised again until somebody has figured out if there's *no* RC problem? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
control: severity 1017906 wishlist Hello, On Mon 22 Aug 2022 at 10:05AM +01, Simon McVittie wrote: > > Control: clone -1 -2 > Control: retitle -1 librsvg: Has vendored copies of Rust libraries that are > in Debian > Control: retitle -2 librsvg: Contains generated files whose source is not > necessarily the same version that's in main > Control: tags -1 + help > Control: tags -2 + help > > On Mon, 22 Aug 2022 at 10:19:01 +0300, Sebastian Dröge wrote: >> The vendor subdirectory in the librsvg source package contains copies of >> various Rust libraries in specific versions. Some of them are packaged in >> Debian (i.e. the version from Debian should be used), others contain >> autogenerated files for which the original source is not in Debian. > > This seems like two separate issues, so I'm cloning it. > > Is there ftp team consensus that either or both of these issues are RC? #1017892 is wishlist or not a bug. Certainly not a DFSG issue. #1017906 *might* be a problem. If there is generated Rust code without the source code used to generate it, or the tool used to transform the sources into the generated Rust code, then there is source code missing. I have not looked into the package to see whether this is actually the case. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
Control: clone -1 -2 Control: retitle -1 librsvg: Has vendored copies of Rust libraries that are in Debian Control: retitle -2 librsvg: Contains generated files whose source is not necessarily the same version that's in main Control: tags -1 + help Control: tags -2 + help On Mon, 22 Aug 2022 at 10:19:01 +0300, Sebastian Dröge wrote: > The vendor subdirectory in the librsvg source package contains copies of > various Rust libraries in specific versions. Some of them are packaged in > Debian (i.e. the version from Debian should be used), others contain > autogenerated files for which the original source is not in Debian. This seems like two separate issues, so I'm cloning it. Is there ftp team consensus that either or both of these issues are RC? Regardless of whether they are RC, the GNOME team is unlikely to be able to solve these without help. In particular, I have been one of the more frequent uploaders of librsvg in recent years, not because I *want* to be involved with librsvg, but because *someone* has to do it (as a dependency of GTK 4 and GNOME, among others). I don't know Rust or the Rust toolchain, so I am not well-placed to make extensive structural changes. The Rust tooling in Debian seems to have a general assumption that every Rust library is built using Cargo as its top-level build system and packaged individually (no vendoring). Conversely, because it was gradually ported from C to Rust, librsvg is built using Autotools (invoking Cargo internally); and its dependencies are provided as vendored modules. I do not have sufficient Rust knowledge to fit Debian's Cargo wrappers into this Autotools build, I certainly do not have sufficient Rust knowledge to adapt it to be able to cope with having half the dependencies vendored and the other half coming from external packages, and I am definitely not the right person to be packaging all the vendored dependencies as individual Rust libraries. I already dread having to package a new upstream version of librsvg, because it means losing several hours of my life to checking a diff and updating d/copyright. I had been forcing myself to do this work anyway, because part of being involved in a volunteer project is having to do work that we don't want to do, but perhaps I should have been refusing to touch this particular package and letting its occasional CVEs and other RC bugs go unfixed until someone with the right skillset picked it up? I've done my best, but I know my best is not good enough. Other Debian contributors with more time and/or expertise are welcome to step in any time. If Debian as a project requires librsvg to be maintained in particular ways, then someone who is capable of doing that work will need to do it, and I'm sorry but that's not me. smcv
Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
Source: librsvg Version: 2.54.4+dfsg-1 Severity: serious Tags: upstream Hi, See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html For more details how to solve this in a way that makes ftp-masters happy, please refer to them. The vendor subdirectory in the librsvg source package contains copies of various Rust libraries in specific versions. Some of them are packaged in Debian (i.e. the version from Debian should be used), others contain autogenerated files for which the original source is not in Debian. Examples for this are - vendor/semver corresponds to the rust-semver package in Debian. Here version 1.0.10 is included while Debian currently only has version 1.0.4. Both versions should be API compatible so that's not necessarily a problem for switching to the Debian version. - vendor/memchr corresponds to the rust-memchr package in Debian. Currently these two have the same version. - vendor/png corresponds to the rust-png package in Debian. Here version 0.17.5 is included while Debian currently only has version 0.16.8. Both versions are not API compatible. - vendor/glib-sys corresponds to the rust-glib-sys package in Debian. Here version 0.15.10 is included while Debian currently only has version 0.14.0. Both versions are not API compatible at all. In addition the src/lib.rs in that subdirectory has exactly the same problem mentioned in the above discussion. It is autogenerated from GLib-2.0.gir by the gir tool, and GLib-2.0.gir is autogenerated from the GLib (glib2.0 source package) source code. Either the original source in the exact version used here and everything to generate the files has to be shipped with the source package, or the files have to be regenerated at build time with whatever is available in Debian. See the above discussion for more details. These are not all files affected. You'll have to check the whole content of the vendor subdirectory on every release and ideally make sure each of these are packaged in Debian in the correct version. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
