Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 753764

Summary: gnome-base/librsvg: EAPI 7 request
Product: Gentoo Linux Reporter: David Michael <fedora.dm0>
Component: Current packagesAssignee: 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
Created attachment 670643 [details]
EAPI 7 update

Attached is an EAPI 7 ebuild.  This fixes cross-compiling EAPI 6 multilib dependencies and puts native tools in BDEPEND.  The resulting binpkg contains the same files as the EAPI 6 version for all USE flag combinations.

When switching to gnome2-utils.eclass, I only used the gdk-pixbuf loader postscripts since that's the only eclass-handled stuff that gets installed by the package.

Note that Rust is in BDEPEND now, so it had to drop its multilib USE dependencies due to bug #723112.  It just has to expect that the user built Rust with appropriate targets enabled.
Comment 1 Mart Raudsepp gentoo-dev 2020-11-09 21:05:02 UTC
rust without MULTILIB_USEDEP isn't really going to fly here, as it breaks amd64 multilib build consistency
Comment 2 David Michael 2020-11-09 21:18:18 UTC
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.
Comment 3 Mart Raudsepp gentoo-dev 2020-11-10 20:45:09 UTC
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.
Comment 4 David Michael 2020-11-10 22:20:43 UTC
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.
Comment 5 Georgy Yakovlev archtester gentoo-dev 2020-11-11 00:01:15 UTC
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.
Comment 6 Larry the Git Cow gentoo-dev 2020-12-18 22:05:31 UTC
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(-)
Comment 7 Larry the Git Cow gentoo-dev 2021-04-18 15:27:26 UTC
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(-)
Comment 8 Larry the Git Cow gentoo-dev 2021-04-18 17:30:02 UTC
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(-)
Comment 9 tt_1 2022-09-19 15:17:17 UTC
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
Comment 10 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-10-01 07:14:34 UTC
(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.
Comment 11 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-10-11 11:28:19 UTC
*** Bug 876754 has been marked as a duplicate of this bug. ***
Comment 12 Larry the Git Cow gentoo-dev 2022-10-11 18:19:29 UTC
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(+)