Bug#1049413: librsvg: Update to 2.56 or later
On Sat, 7 Oct 2023 21:33:44 +0200 Matthias Geiger wrote: [...] > - yeslogic-fontconfig-sys > yeslogic-fontconfig-sys actually is in debian. I can package all those; this might be needed wrt to 1062016. Partial vendoring might also be a solution here. best, -- Matthias Geiger Debian Maintainer "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1049413: librsvg: Update to 2.56 or later
On 15.08.23 14:25, Jeremy Bícha wrote: Source: librsvg Version: 2.54.7+dfsg-2 Severity: wishlist X-Debbugs-CC: werdah...@riseup.net It would be nice if we updated librsvg to 2.56 (GNOME 44 series) or 2.58 (GNOME 45 series). But 2.56 drops the vendored Rust crate dependencies, forcing us to either revendor librsvg or use the Debian packaged crates. That would complicate the packaging since it would tie librsvg into the Rust GTK transitions and other Rust library transitions. It's possible; just not sure we want to do it. Matthias (CC'd) did some work earlier on this; I believe there are a few more Rust crates that would need to be packaged if we wanted to test this more. See also these related librsvg bugs: https://bugs.debian.org/1017892 https://bugs.debian.org/1017906 One extra detail: my understanding is that current Ubuntu best practice is to vendor all Rust crates used as dependencies for libraries and apps in Ubuntu main (which includes librsvg). This is mentioned at https://github.com/canonical/ubuntu-mir Alternatively, we could ask the librsvg developers to revendor librsvg. Thank you, Jeremy Bícha Revisiting: After the recent gtk-rs upload building only with debian tooling/ packages might not be that far off. Crates in debian that need updating: - rctree - data-url crates that need packaging from scratch: - rawpointer - matrixmultiply - nalgebra - nalgebra-macros - simba - lopdf - yeslogic-fontconfig-sys I tend towards packaging all those. Since gtk3-rs is only getting security updates upstream future gtk-rs transitions won't be as much work. There's already a few GUI programs tied into the stack so tying librsvg2 in doesn't seem too bad imo. re-vendoring the tarball with cargo vendor is also an option if you prefer that. The crate librsvg does not get built from source yet; I haven't looking into how to do that, but it'll be needed eventually to enable svg rendering support in Loupe. Let me know if you want me to start packaging those missing crates. best, -- Matthias Geiger Debian Maintainer "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1049413: librsvg: Update to 2.56 or later
On 15.08.23 19:19, Simon McVittie wrote: On Tue, 15 Aug 2023 at 18:41:49 +0200, Matthias Geiger wrote: the latest rsvg would need ~ 10 NEW rust packages if it were to be devendored. iirc you can actually run "cargo vendor" and it would revendor the tarball (even with out upstream vendoring it). Given the policy that Jeremy linked to, I imagine Ubuntu will want to produce a fully-vendored tarball, even if Debian does not. looks like it, yeah. Producing a fully-vendored tarball of 2.55 or higher would be the closest thing to the status quo, so I think that would be a valid way to update librsvg, even if the Debian Rust team would prefer us to do it differently. We vendor rustc and cargo (partially / before build ) so I wouldn't say the team objects in this case. Is it possible to vendor *some* dependencies, and take others from Debian? That seems a lot more feasible to me than de-vendoring literally everything, and in particular would avoid librsvg getting stuck behind a new Rust library getting through NEW. I think so, yeah. The debian cargo wrapper (script) ( |/usr/share/cargo/bin| )||allows linking from a) the system and b) any other directory (or both) The wrapper mentioned has the documentation inside, you can also checkout my WIP packaging here [0]. All I'd add here for a second vendor dir would be a |$(CARGO) prepare-debian debian/cargo_registry vendor-dir |( I think). cargo will sort it out then. werdahias [0] https://salsa.debian.org/werdahias/obfuscate-wip/-/blob/debian/master/debian/rules || OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1049413: librsvg: Update to 2.56 or later
On Tue, Aug 15, 2023 at 1:19 PM Simon McVittie wrote: > Given the policy that Jeremy linked to, I imagine Ubuntu will want to > produce a fully-vendored tarball, even if Debian does not. I briefly mentioned this issue to Ubuntu's Main Inclusion team today and their Rust vendoring policy might be relaxed in the future, but it will take time and work to figure out the many details. Thank you, Jeremy Bícha
Bug#1049413: librsvg: Update to 2.56 or later
On Tue, 15 Aug 2023 at 18:41:49 +0200, Matthias Geiger wrote: > the latest rsvg would need ~ 10 NEW rust packages if it were to be > devendored. iirc you can actually run "cargo vendor" and it would revendor > the tarball (even with out upstream vendoring it). Given the policy that Jeremy linked to, I imagine Ubuntu will want to produce a fully-vendored tarball, even if Debian does not. Producing a fully-vendored tarball of 2.55 or higher would be the closest thing to the status quo, so I think that would be a valid way to update librsvg, even if the Debian Rust team would prefer us to do it differently. Is it possible to vendor *some* dependencies, and take others from Debian? That seems a lot more feasible to me than de-vendoring literally everything, and in particular would avoid librsvg getting stuck behind a new Rust library getting through NEW. smcv
Bug#1049413: librsvg: Update to 2.56 or later
On 15.08.23 15:34, Jeremy Bícha wrote: On Tue, Aug 15, 2023 at 9:05 AM Simon McVittie wrote: Are you sure you mean 2.58? https://gitlab.gnome.org/GNOME/librsvg seems to be version 2.56.92 right now, which suggests that GNOME 45 will have librsvg 2.57.x. … so maybe we can at least go to 2.55.x, even if moving beyond there is not feasible right now? Thank you for noticing. The devendoring also happened for the stable 2.55.0 release. Yes, 2.57 will be the release for GNOME 45. I don't know Rust or cargo, so I am not going to be able to help with this. smcv: no worries :) I have been learning some of the debcargo workflow. Matthias is our local expert. But if Debian and Ubuntu's packaging diverge, I just have less available free time to work on big Debian-specific projects these days. Thanks :) the latest rsvg would need ~ 10 NEW rust packages if it were to be devendored. iirc you can actually run "cargo vendor" and it would revendor the tarball (even with out upstream vendoring it). If you'd choose to fully devendor it and build it only with debian crates this creates two issues imo. First, librsvg would become inherently dependent on the GTK-rs stack. (It's already a lot of work to update each release, fortunately we're on par (almost)). Secondly the other rust dependencies would be also pulled in which would require more maintenance work and coordination with the rust team. If you choose to devendor it I can package the missing dependencies. best, werdahias OpenPGP_0x18BD106B3B6C5475.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1049413: librsvg: Update to 2.56 or later
On Tue, Aug 15, 2023 at 9:05 AM Simon McVittie wrote: > Are you sure you mean 2.58? https://gitlab.gnome.org/GNOME/librsvg seems > to be version 2.56.92 right now, which suggests that GNOME 45 will have > librsvg 2.57.x. > … > so maybe we can at least go to 2.55.x, even if moving beyond there is > not feasible right now? Thank you for noticing. The devendoring also happened for the stable 2.55.0 release. Yes, 2.57 will be the release for GNOME 45. > I don't know Rust or cargo, so I am not going to be able to help with > this. I have been learning some of the debcargo workflow. Matthias is our local expert. But if Debian and Ubuntu's packaging diverge, I just have less available free time to work on big Debian-specific projects these days. Thank you, Jeremy Bícha
Bug#1049413: librsvg: Update to 2.56 or later
On Tue, 15 Aug 2023 at 08:25:55 -0400, Jeremy Bícha wrote: > It would be nice if we updated librsvg to 2.56 (GNOME 44 series) or > 2.58 (GNOME 45 series). Are you sure you mean 2.58? https://gitlab.gnome.org/GNOME/librsvg seems to be version 2.56.92 right now, which suggests that GNOME 45 will have librsvg 2.57.x. Upstream documentation says: Before version 2.55.x, librsvg's versioning scheme was such that a release with an even minor number was considered a stable release suitable for production use (e.g. 2.54.x), and an odd minor number was a development release only. Starting with 2.55.x, all minor numbers are considered stable. Development and beta versions have a micro version starting at 90 (e.g. 2.55.90) — https://gitlab.gnome.org/GNOME/librsvg/-/blob/main/devel-docs/security.rst so maybe we can at least go to 2.55.x, even if moving beyond there is not feasible right now? > But 2.56 drops the vendored Rust crate dependencies, forcing us to > either revendor librsvg or use the Debian packaged crates. I don't know Rust or cargo, so I am not going to be able to help with this. smcv
Bug#1049413: librsvg: Update to 2.56 or later
Source: librsvg Version: 2.54.7+dfsg-2 Severity: wishlist X-Debbugs-CC: werdah...@riseup.net It would be nice if we updated librsvg to 2.56 (GNOME 44 series) or 2.58 (GNOME 45 series). But 2.56 drops the vendored Rust crate dependencies, forcing us to either revendor librsvg or use the Debian packaged crates. That would complicate the packaging since it would tie librsvg into the Rust GTK transitions and other Rust library transitions. It's possible; just not sure we want to do it. Matthias (CC'd) did some work earlier on this; I believe there are a few more Rust crates that would need to be packaged if we wanted to test this more. See also these related librsvg bugs: https://bugs.debian.org/1017892 https://bugs.debian.org/1017906 One extra detail: my understanding is that current Ubuntu best practice is to vendor all Rust crates used as dependencies for libraries and apps in Ubuntu main (which includes librsvg). This is mentioned at https://github.com/canonical/ubuntu-mir Alternatively, we could ask the librsvg developers to revendor librsvg. Thank you, Jeremy Bícha
