Control: severity 1017892 wishlist Control: severity 1017906 serious On Sun, 01 Jan 2023 at 17:15:19 +0100, Paul Gevers wrote: > On Mon, 22 Aug 2022 14:29:56 -0700 Sean Whitton <spwhit...@spwhitton.name> > wrote: > > #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 not Sean, but I agree the one that is *maybe* RC is #1017906 (depending on how the ftp team choose to interpret the source code requirement, corresponding source, and similar things), while #1017892 (use of vendored Rust at versions chosen by upstream) is not. If the ftp team consider #1017906 to be RC, then the solution to it is to bundle another copy of GLib source code with librsvg, corresponding to the version of GLib's GObject-Introspection data in vendor/glib-sys, similar to what I did for src:gobject-introspection (I used 3.0 (quilt) multiple original tarballs, which seemed slightly nicer than dropping it into debian/ and having it duplicated in every Debian revision). Using the GIR XML generated by Debian's GLib is not a solution, because that would result in glib-sys changing its API whenever it was rebuilt with a newer (or older!) GLib, and rebuilt libraries changing their APIs is generally bad news. I personally think GIR XML is a reasonable form for modification and a plausible way to exercise freedom-to-modify, despite not being the "least-derived" source, but it is true that it was mechanically generated from GLib's C code and is not the form you would modify to make an upstream contribution (the upstream of vendor/glib-sys is unlikely to accept any contribution to the GIR XML not of the form "update to GLib x.y.z", but the DFSG does not require that changes made downstream could be accepted upstream, and if it did then we would immediately lose sqlite and some GNU projects). As a result, I personally think this is not a particularly productive use of Debian maintainers' time; but if it's a requirement then I'll try to make time for it at some point, at the cost of an equivalent amount of other Debian work not getting done. smcv