Summary: | gnome-base/librsvg: EAPI 7 request | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Michael <fedora.dm0> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | brankob, gyakovlev, herrtimson, jstein, rust |
Priority: | Normal | Keywords: | EBUILD, PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/gentoo/gentoo/pull/18574 https://github.com/gentoo/gentoo/pull/20727 https://bugs.gentoo.org/show_bug.cgi?id=873802 |
||
Whiteboard: | Remember to add gdk-pixbuf to BDEPEND | ||
Package list: | Runtime testing required: | --- | |
Attachments: | EAPI 7 update |
Description
David Michael
2020-11-09 19:06:35 UTC
rust without MULTILIB_USEDEP isn't really going to fly here, as it breaks amd64 multilib build consistency It won't be possible to cross-compile librsvg if it uses MULTILIB_USEDEP. If that is a real requirement, can the 2.40 ebuild be updated to EAPI 7 so the versions with broken dependencies can be masked? Rust really shouldn't be using multilib anyway. CHOST triplets do not map to Rust targets sensibly. Rust has different builtin targets for what is otherwise handled by CPU_FLAGS settings, so the Rust targets built for multilib ABIs are inappropriate or don't work half the time as is. You can discuss this with the rust maintainers, I guess. Building multilib is the main use case, and it'll just fail build with rust-bin if it's not enabled. I'm not sure why this is affecting anything cross for you, as those flags shouldn't really be in effect there. The multilib flags on virtual/rust in BDEPEND in the EAPI 7 affect me as is explained in bug #723112 comment #0. I'll CC the Rust list, because this is going to prevent any multilib Rust package from using EAPI 7. The multilib flags on everything else in DEPEND in the current EAPI 6 version affect me because I had to drop --root-deps=rdeps due to it causing other bugs, so those USE flags are enforced in BROOT until the packages upgrade to EAPI 7. This breaks everything for the same reason as bug #723112. My previous comment now looks like I was mashing multiple complaints together, so I'll try to clarify. This is related more to Rust maintenance than librsvg... Rust target triplets do not map to CHOST triplets, because different Rust targets can include what is covered by CPU_FLAGS for the same CHOST. - For example, Gentoo builds Rust's i686-unknown-linux-gnu target for the x86 ABI, which requires SSE2. That would be fine for most i686 chips, but I have a Geode CPU (embedded i686 with no SSE), so I need to build the i586-unknown-linux-gnu target with my i686 CHOST. - Another example, Gentoo builds the armv7-unknown-linux-gnueabihf target for armv7a CHOSTs. Rust has a different target thumbv7neon-unknown-linux-gnueabihf to include NEON and Thumb, which is automatically required by the Firefox build system when CPU_FLAGS has neon, so Firefox won't build without the additional target. So I think dev-lang/rust should be handled more like GCC, where it can be installed with whatever arbitrary set of targets without having its own multilib ABI USE flags. Packages could use an environment variable RUST_TARGET in make.conf (with a default from each arch profile) to pick which target to use, allowing the equivalent of setting CPU_FLAGS and CHOST. Multilib packages could use a variant for each ABI e.g. RUST_TARGET_x86 like CHOST_x86. you mean https://bugs.gentoo.org/747760 ? problem is that for arbitrary number of arbitrary targets you need cross-toolchains available, and it's illegal to depend on cross-* in normal ebuilds. also, current librsvg state is kinda a hack, until they make it a proper crate (work in progress). cargo cross support is coming, multilib in pure-cargo ebuilds is a bit of a hack as well, I'll look at doing it properly with multibuild functions. after rust_targets happen, we can also map targets to abi flags if needed. or write dep generator function. this is a LOT of work, I could use some help there, but it has to be ::gentoo legal way of doing things. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0b1cbe7008e00ce004e67ab455ff52902c614934 commit 0b1cbe7008e00ce004e67ab455ff52902c614934 Author: David Michael <fedora.dm0@gmail.com> AuthorDate: 2020-12-08 23:06:13 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-12-18 22:00:05 +0000 gnome-base/librsvg: bump the C version to EAPI 7 Only the old pure C version of librsvg can currently be updated beyond EAPI 6 due to this blocker: https://bugs.gentoo.org/723112 Bug: https://bugs.gentoo.org/753764 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: David Michael <fedora.dm0@gmail.com> Signed-off-by: Matt Turner <mattst88@gentoo.org> gnome-base/librsvg/librsvg-2.40.21.ebuild | 49 +++++++++++++++---------------- 1 file changed, 23 insertions(+), 26 deletions(-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f12a2409995a84ec4503772588d6643fdeae6055 commit f12a2409995a84ec4503772588d6643fdeae6055 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2021-04-18 15:22:57 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2021-04-18 15:27:19 +0000 gnome-base/librsvg: Port to EAPI=7 * Remove *.la files (bug #776343) * BDEPEND on x11-libs/gdk-pixbuf (bug #759172) Closes: https://bugs.gentoo.org/753764 Closes: https://bugs.gentoo.org/759172 Closes: https://bugs.gentoo.org/776343 Signed-off-by: Matt Turner <mattst88@gentoo.org> gnome-base/librsvg/librsvg-2.50.4.ebuild | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1e55a30fdc287e4a3539fbdbbe9811894a0d5a7 commit a1e55a30fdc287e4a3539fbdbbe9811894a0d5a7 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2021-04-18 16:44:40 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2021-04-18 17:29:51 +0000 gnome-base/librsvg: Revert to EAPI=6 dm0 tells me that in EAPI=7 that cross compiling with rust is broken. Bug: https://bugs.gentoo.org/753764 Bug: https://bugs.gentoo.org/759172 Signed-off-by: Matt Turner <mattst88@gentoo.org> gnome-base/librsvg/librsvg-2.50.4.ebuild | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) hey everyone, upstream librsvg decided to not to vendor their crates anymore with the source tarballs, starting with librsvg-2.55.0 version it seems. I can't think of another solution than to make use of the cargo eclass, which demands eapi=7 for your information only (In reply to tt_1 from comment #9) > hey everyone, > > upstream librsvg decided to not to vendor their crates anymore with the > source tarballs, starting with librsvg-2.55.0 version it seems. I can't > think of another solution than to make use of the cargo eclass, which > demands eapi=7 > > for your information only In addition to this (see bug 873802): 1. EAPI 6 lacks ENV_UNSET 2. cargo.eclass isn't used so CARGO_* doesn't get unset either. *** Bug 876754 has been marked as a duplicate of this bug. *** The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=beb396ee39c697e62ecc4173438b61746e97200e commit beb396ee39c697e62ecc4173438b61746e97200e Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2022-10-11 14:59:29 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2022-10-11 18:08:08 +0000 gnome-base/librsvg: Version bump to 2.55.1 The bundled crates were dropped in v2.55. As a result we need to use cargo.eclass, and it doesn't support EAPI=6, so we've switched to EAPI=8. Closes: https://bugs.gentoo.org/753764 Signed-off-by: Matt Turner <mattst88@gentoo.org> gnome-base/librsvg/Manifest | 264 ++++++++++++++++++++++ gnome-base/librsvg/librsvg-2.55.1.ebuild | 377 +++++++++++++++++++++++++++++++ 2 files changed, 641 insertions(+) |