Re: [gentoo-dev] Up for grabs: Raspberry Pi stack
On Sat, 2024-04-20 at 04:24 +0100, Sam James wrote: > I don't have the hardware set up at the moment (and haven't for a while) > to test this properly. > > The following packages are up for grabs: > * media-libs/raspberrypi-userland-bin > * sys-kernel/raspberrypi-image > > I dropped myself as a co-maintainer on the following: > * sys-firmware/raspberrypi-wifi-ucode > * media-libs/raspberrypi-userland-bin > * sys-boot/raspberrypi-firmware > * sys-kernel/raspberrypi-sources > * sys-kernel/raspberrypi-image > > I think anyone interested in these packages should probably consider > joining the lot. > > There's a few outstanding bugs, notably https://bugs.gentoo.org/930269 > for Raspberry Pi 5 support, but a bunch of others including bumps being > due. I've been working in this area because of my PiStorm efforts, but it's been hard to find the time lately. I can at least say that I was on the way to last riting media-libs/raspberrypi-userland(-bin). Ideally, we need libcamera first, otherwise users of things like media-video/motion will be impacted. I don't know whether we have any such users though. As for hardware, I only have a Pi 4b and have no need for a Pi 5. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: tc-env_build: override (E)SYSROOT
On Fri, 2024-04-19 at 12:14 -0400, Mike Gilbert wrote:
> When using the CBUILD toolchain, it makes no sense to look for headers
> and libraries in the CHOST-based SYSROOT.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/toolchain-funcs.eclass | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index cde84e6f34c8..58a718180079 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 2002-2023 Gentoo Authors
> +# Copyright 2002-2024 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: toolchain-funcs.eclass
> @@ -384,6 +384,12 @@ tc-export_build_env() {
> # the target build system does not check.
> tc-env_build() {
> tc-export_build_env
> + local -x SYSROOT=
> + if [[ ${EAPI} == 6 ]]; then
> + local -x ESYSROOT=${EPREFIX}
> + else
> + local -x ESYSROOT=${BROOT}
> + fi
> CFLAGS=${BUILD_CFLAGS} \
> CXXFLAGS=${BUILD_CXXFLAGS} \
> CPPFLAGS=${BUILD_CPPFLAGS} \
What do you need this for? Just wondering because I wouldn't have thought
anything you wrap with tc-env_build would care about ESYSROOT.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-board/xmille
# James Le Cuirot (2024-04-05) # Dead upstream and broken beyond repair. Removal on 2024-05-05. Bug #928591. games-board/xmille signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Mon, 2024-04-01 at 20:51 +0200, Kévin GASPARD DE RENEFORT wrote: > > Thanks for clarifying that, it wasn't clear to me when I read the > > earlier e-mail. > > > > Personally I think the long term solution is to identify critical code > > bases that have a low bus factor before the bad actors do and make a > > concentrated community effort to help audit and maintain these code > > bases. > > Hi, > > I hope this is not a stupid suggestion, that is also my first mail here > so if something does not suits habits feel free to tell me please, but > after reading the whole topic here I did not find this suggestion. > > It’s merely a proposition out of my mind, also something I know very > little about. > > --- > > I read Linus T. speaking about usage of AI nowadays, in the IT field and > stating that is an awful idea to write code with it (at least, for now)… > But not to ask an AI to read the code and try to found by this way > security holes, bad habits, bugs and such. > > Again, my skill and knowledge about AI, specially nowadays, is very > small. But would take it lot of works to sets an AI to simple «read» > codes to look for undesired stuff ? That won’t even modify anything, > merely says : «Ah, found something weird, **here**.». Maybe, properly > configured, it would have detected this social-hacking. Maybe not. > > Since programming is a very hard works, specially when it’s about > security and bug, I also have very poor programing skill, but since the > whole purpose of a computer and it’s set of software is to do what an > human could NOT do properly (like being attentives while reading dozens > of hundreds line of code…) and automate stuff, it *seems* to perfectly > suits this need. > > I guess the process on Gentoo side while it’s about "packaging" is > writing the good ebuild that download source code, compressed (and that > is the whole problem here if I understand) and then unpack it, compile > it, etc… > > Could an AI reading the code could be a step somewhere ? > > On other distribution I would say it needs to act **before** the package > is made, while building it I guess, for Gentoo I do not know. > > But that is not the job of Gentoo’s ebuild writer to check other > projects code, that would be a non-sense ! Right ? > > I’m curious of what an AI could bring in this subject. > > If it’s a stupid suggestion, well, will keep reading this topic, very > interesting. And sorry for the noise. > > PS: Thanks for the works behind libre software, open-source and here, > Gentoo. I trust you since I do not have knowledge to judge properly the > works, but Gentoo is indeed one of the best Linux available, if not the > best in some field. Don’t let burn-out takes you and keep your real > priority among everything, even Gentoo or libre software. We are humans, > not machines. > > Regards, > GASPARD DE RENEFORT Kévin That's not stupid at all, I'd been thinking exactly the same thing. I raised this whole issue during a discussion at FOSDEM 2019, where I admitted that I didn't check the code changes for packages I was bumping, knowing that few to none of the other people in the room did so either. Despite speaking up then, I still didn't do it because it's a heavy a burden and I'm not paid to do it. Now I'm thinking I really should, but I could really use some help. I'll raise this idea at work. You could say that we specialise in these things. :) Regards, Chewi signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-sports/gracer
# James Le Cuirot (2024-03-30) # Old, ugly, broken, and requires OSS sound. Removal on 2024-04-30. # Bug #928066. games-sports/gracer signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] python-utils-r1.eclass: Fix python_doheader install location with ROOT
python_get_includedir is prefixed with ESYSROOT, not EPREFIX, so we need
to strip off the former, not the latter.
This is currently only used for dev-python/pillow, which I have tested.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 3af3cbdb075e1..caa39813feec7 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -884,7 +884,7 @@ python_doheader() {
[[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is
null).'
local includedir=$(python_get_includedir)
- local d=${includedir#${EPREFIX}}
+ local d=${includedir#${ESYSROOT}}
(
insopts -m 0644
--
2.43.2
Re: [gentoo-dev] Important note on tinderbox behavior
On Fri, 2024-02-23 at 15:35 +0100, Agostino Sarubbo wrote:
> Dear all,
>
> TL;DR: tinderbox will skip packages with know failures
>
> it's a matter of fact that on bugzilla there are hundreds of bugs that
> tinderbox continues to reproduce.
>
> That results in a waste of resources and time.
>
> What was done to improve this situation:
> in the past few months I launched few tinderbox environments with the scope
> of
> collect the known failures.
> These failures, that have an open bug, have been noted on a list.
> When tinderbox starts, it queries bugzilla to understand the status of the
> bug
> and in case of open bugs it passes the package names to emerge as
> --exclude $PACKAGE
> That save a lot of time because emerge FOO --exclude FOO hangs immediately.
>
> Imagine a scenario where a broken package has no DEPEND. The waste of
> resource
> is very minimal.
>
> Imagine another scenario where:
> - the package FOO is broken
> - the package BAR has 100 depend
> - the package FOO is a depend of BAR
> - the package FOO is at position 100 of the depend order
>
> that results in build 99 packages for nothing.
>
> In short the problem is not in the package itself, but when a lot of DEPEND
> are involved.
>
> This behavior, *that was already experimented in the latest few months* does
> not change anything on your side.
>
> The only con that comes in my mind is that when a version bump silently fixes
> an issue and maintainer is not aware about that.
> The bug still remains as open and as a consequence, the package continues to
> be excluded.
>
> For this reason, please be pay more attention to open bugs.
>
> As a side note, bugs are obviously categorized. For example a build failure
> for a package FOO on musl, will produce '--exclude FOO' only on musl.
> Same thing for doc brokeness.
>
> For this reason please expect less 'tinderbox has reproduced this issue with
> version "${VERSION}" - Updating summary.' and not seeing anymore this message
> is not a symptom of 'this is fixed now' ( https://bugs.gentoo.org/770889#c6 )
>
> Failures regarding Modern C porting are excluded from this behavior. Instead
> '-fpermissive' will be used to build as much as possible.
> Tests failures have also no influence on that, but keep in mind that packages
> with known test failure(s) are not built by default.
>
> Thanks
> Agostino
>
You've made the right call here. Sorry for not fixing the many bugs you've
reported. It's not that I don't care, it's very hard to find the time,
especially for the musl and Clang ones. I certainly won't assume the issues
have magically gone away. Thanks for your continued hard work in this area.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
On Sun, 2024-02-11 at 09:00 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 10 Feb 2024, Daniel Simionato wrote: > > > I'd like to start a discussion regarding setting HOME_MODE by default in > > the /etc/login.defs file (owned by sys-apps/shadow package). > > > Upstream keeps HOME_MODE commented: > > https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 > > > HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, > > they will use the specified permission when creating a user home directory, > > otherwise the default UMASK will be used. > > Since the default umask is 022, keeping HOME_MODE unset will result in home > > readable home directories created by useradd, which goes against security > > best practices. > > > The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH > > based distros, OpenSuse, ArchLinux all set it to 0700, Ubuntu has it at > > 0750. Debian and Gentoo are two exceptions, keeping the upstream value of > > HOME_MODE (although login.defs is changed in other ways). > > > I previously made a PR on github where you can find more details ( > > https://github.com/gentoo/gentoo/pull/35231), but as pointed in the > > comments this probably warrants some discussion beforehand. > > > I can understand the argument against the change, which is keeping in sync > > with upstream and don't risk changing the historic default behaviour of > > tools some users might rely upon. > > > I do believe though there's merit in providing safer and secure defaults, > > so I would like HOME_MODE to have a safe default value for Gentoo and > > Gentoo based distros. > > I see no strong argument either way. However, changing the default is > somewhat intrusive, so I'd prefer staying with upstream. Also, are we > aware of any breakage caused by this? > > As you've pointed out yourself, distros are inconsistent about it, > i.e. not much guidance from there. Maybe upstream would be a better > place for this discussion? > > Ulrich You may need 0701 if you have a web server reading from ~/public_html, but that's uncommon. I've been using this for years without issue, but I think 0700 makes the most sense as the default. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC PATCH 00/10] Upgrading cups-filters to 2.0.0
On Tue, 2023-12-05 at 00:20 -0500, Eli Schwartz wrote: > I've been working with Sam for a bit on this update. It's a bit of a > fiddly one, as a lot of stuff has changed upstream. It's probably best > described via my proposed news post. Please review. It would also be > quite nice to get a bit of testing -- I'm especially concerned about > cups-browsed's testsuite, so if anyone has any ideas how to actually run > it, that would be fantastic. I do not use cups-browsed myself... I've mostly just glanced at the code, which looks fine, but I just want to express my huge thanks for doing this. I know printing stuff isn't sexy, but it is important, so I really appreciate the effort. signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 4/4] eclass/golang-vcs.eclass: set up compile env
From: Thilo Fromm
This change calls go-env_set_compile_environment in golang-vcs's
src_unpack to set up a sane compile environment early in the go build
process. This un-breaks cross compiling of all golang ebuilds that
inherit golang-vcs.
Signed-off-by: Thilo Fromm
Closes: https://github.com/gentoo/gentoo/pull/33539
Signed-off-by: James Le Cuirot
---
eclass/golang-vcs.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/golang-vcs.eclass b/eclass/golang-vcs.eclass
index 7558db4776cb..6f7a837bc15f 100644
--- a/eclass/golang-vcs.eclass
+++ b/eclass/golang-vcs.eclass
@@ -20,7 +20,7 @@ esac
if [[ -z ${_GOLANG_VCS_ECLASS} ]]; then
_GOLANG_VCS_ECLASS=1
-inherit estack golang-base
+inherit estack golang-base go-env
PROPERTIES+=" live"
@@ -63,6 +63,7 @@ PROPERTIES+=" live"
# @INTERNAL
# @DESCRIPTION:
# Create EGO_STORE_DIR if necessary.
+# Set compile env via go-env.
_golang-vcs_env_setup() {
debug-print-function ${FUNCNAME} "$@"
@@ -84,6 +85,8 @@ _golang-vcs_env_setup() {
mkdir -p "${WORKDIR}/${P}/src" ||
die "${ECLASS}: unable to create ${WORKDIR}/${P}"
return 0
+
+ go-env_set_compile_environment
}
# @FUNCTION: _golang-vcs_fetch
--
2.42.1
[gentoo-dev] [PATCH 3/4] eclass/golang-vcs-snapshot.eclass: set up compile env
From: Thilo Fromm
This change calls go-env_set_compile_environment in
golang-vcs-snapshot's src_unpack to set up a sane compile environment
early in the go build process. This un-breaks cross compiling of all
golang ebuilds that inherit golang-vcs-snapshot.
Signed-off-by: Thilo Fromm
Signed-off-by: James Le Cuirot
---
eclass/golang-vcs-snapshot.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/golang-vcs-snapshot.eclass
b/eclass/golang-vcs-snapshot.eclass
index 9c199bbbd8c5..d34b8a6e913d 100644
--- a/eclass/golang-vcs-snapshot.eclass
+++ b/eclass/golang-vcs-snapshot.eclass
@@ -52,7 +52,7 @@ esac
if [[ -z ${_GOLANG_VCS_SNAPSHOT_ECLASS} ]]; then
_GOLANG_VCS_SNAPSHOT_ECLASS=1
-inherit golang-base
+inherit golang-base go-env
# @ECLASS_VARIABLE: EGO_VENDOR
# @DESCRIPTION:
@@ -92,6 +92,7 @@ _golang-vcs-snapshot_dovendor() {
# @FUNCTION: golang-vcs-snapshot_src_unpack
# @DESCRIPTION:
# Extract the first archive from ${A} to the appropriate location for GOPATH.
+# Set compile env via go-env.
golang-vcs-snapshot_src_unpack() {
local lib vendor_path x
ego_pn_check
@@ -117,6 +118,8 @@ golang-vcs-snapshot_src_unpack() {
fi
done
fi
+
+ go-env_set_compile_environment
}
fi
--
2.42.1
[gentoo-dev] [PATCH 2/4] eclass/go-module.eclass: export compile env in src_unpack
From: Thilo Fromm
This change calls go-env_set_compile_environment in go-module's
src_unpack to set up a sane compile environment early in the go build
process. This un-breaks cross compiling of all golang ebuilds that
inherit go-module.
Signed-off-by: Thilo Fromm
Signed-off-by: James Le Cuirot
---
eclass/go-module.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 6c58d7f26f07..701d36e012e2 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -68,7 +68,7 @@ esac
if [[ -z ${_GO_MODULE_ECLASS} ]]; then
_GO_MODULE_ECLASS=1
-inherit multiprocessing toolchain-funcs
+inherit multiprocessing toolchain-funcs go-env
if [[ ! ${GO_OPTIONAL} ]]; then
BDEPEND=">=dev-lang/go-1.18"
@@ -363,6 +363,7 @@ go-module_setup_proxy() {
#local go proxy. This mode is deprecated.
# 2. Otherwise, if EGO_VENDOR is set, bail out, as this functionality was
removed.
# 3. Otherwise, call 'ego mod verify' and then do a normal unpack.
+# Set compile env via go-env.
go-module_src_unpack() {
if use amd64 || use arm || use arm64 ||
( use ppc64 && [[ $(tc-endian) == "little" ]] ) || use s390 ||
use x86; then
@@ -386,6 +387,8 @@ go-module_src_unpack() {
${nf} ego mod verify
fi
fi
+
+ go-env_set_compile_environment
}
# @FUNCTION: _go-module_src_unpack_gosum
--
2.42.1
[gentoo-dev] [PATCH 1/4] eclass/go-env.eclass: add helper to set compile env
From: Thilo Fromm
This change adds a helper function to explicitly set CC, CXX, and
GOARCH, and carrying over CFLAGS, LDFLAGS and friends to CGO
equivalents, to provide a minimal sane compile environment for Go.
It enables Go builds to play nice with crossdev's wrappers for
emerge/ebuild etc. Previously, Go ebuilds emitted binaries for the host
architecture.
For example, when running on an x86_64 host:
emerge-aarch64-cross-linux-gnu foo
will now correctly emerge Go package "foo" for aarch64 instead of
x86_64.
The eclass provides a single helper function
go-env_set_compile_environment()
intended to be called by other Go eclasses in an early build stage.
Ebuilds may also explicitly call this function.
Signed-off-by: Thilo Fromm
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 48
1 file changed, 48 insertions(+)
create mode 100644 eclass/go-env.eclass
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
new file mode 100644
index ..ba4f6c3fbb59
--- /dev/null
+++ b/eclass/go-env.eclass
@@ -0,0 +1,48 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-env.eclass
+# @MAINTAINER:
+# Flatcar Linux Maintainers
+# @AUTHOR:
+# Flatcar Linux Maintainers
+# @BLURB: Helper eclass for setting the Go compile environment. Required for
cross-compiling.
+# @DESCRIPTION:
+# This eclass includes a helper function for setting the compile environment
for Go ebuilds.
+# Intended to be called by other Go eclasses in an early build stage, e.g.
src_unpack.
+
+if [[ -z ${_GO_ENV_ECLASS} ]]; then
+_GO_ENV_ECLASS=1
+
+inherit toolchain-funcs
+
+# @FUNCTION: go-env_set_compile_environment
+# @DESCRIPTION:
+# Set up basic compile environment: CC, CXX, and GOARCH.
+# Also carry over CFLAGS, LDFLAGS and friends.
+# Required for cross-compiling with crossdev.
+# If not set, host defaults will be used and the resulting binaries are host
arch.
+# (e.g. "emerge-aarch64-cross-linux-gnu foo" run on x86_64 will emerge "foo"
for x86_64
+# instead of aarch64)
+go-env_set_compile_environment() {
+ local arch="$(tc-arch)"
+ case "${arch}" in
+ x86)GOARCH="386" ;;
+ x64-*) GOARCH="amd64" ;;
+ ppc64) if [[ "$(tc-endian)" == "big" ]] ; then
+ GOARCH="ppc64"
+ else
+ GOARCH="ppc64le"
+ fi ;;
+ *) GOARCH="${arch}" ;;
+ esac
+
+ tc-export CC CXX
+ export GOARCH
+ export CGO_CFLAGS="${CGO_CFLAGS:-$CFLAGS}"
+ export CGO_CPPFLAGS="${CGO_CPPFLAGS:-$CPPFLAGS}"
+ export CGO_CXXFLAGS="${CGO_CXXFLAGS:-$CXXFLAGS}"
+ export CGO_LDFLAGS="${CGO_LDFLAGS:-$LDFLAGS}"
+}
+
+fi
--
2.42.1
[gentoo-dev] [PATCH V2 0/4] eclass/go-env.eclass: add helper to enable cross compiling
See the GitHub link for earlier discussion. This still doesn't work for cross-prefix builds, unless you set CGO_ENABLED=1, but fixing that involves different code and can be done later. https://github.com/gentoo/gentoo/pull/33539
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Add functions to get pointer size in bytes
tc-get-ptr-size for CHOST and tc-get-build-ptr-size for CBUILD.
Closes: https://bugs.gentoo.org/328401
Signed-off-by: James Le Cuirot
---
eclass/toolchain-funcs.eclass | 14 ++
1 file changed, 14 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 8fef764ad597..5da93063866b 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1216,4 +1216,18 @@ tc-get-c-rtlib() {
return 0
}
+# @FUNCTION: tc-get-ptr-size
+# @RETURN: Size of a pointer in bytes for CHOST (e.g. 4 or 8).
+tc-get-ptr-size() {
+ $(tc-getCPP) -P - <<< __SIZEOF_POINTER__ ||
+ die "Could not determine CHOST pointer size"
+}
+
+# @FUNCTION: tc-get-build-ptr-size
+# @RETURN: Size of a pointer in bytes for CBUILD (e.g. 4 or 8).
+tc-get-build-ptr-size() {
+ $(tc-getBUILD_CPP) -P - <<< __SIZEOF_POINTER__ ||
+ die "Could not determine CBUILD pointer size"
+}
+
fi
--
2.41.0
[gentoo-dev] [PATCH] eclass/go-env.eclass: add helper to set compile env
From: Thilo Fromm
This change adds a helper function to explicitly set CC, CXX, and
GOARCH, and carrying over CFLAGS, LDFLAGS and friends to CGO
equivalents, to provide a minimal sane compile environment for Go.
It enables Go builds to play nice with crossdev's wrappers for
emerge/ebuild etc. Previously, Go ebuilds emitted binaries for the host
architecture.
For example, when running on an x86_64 host:
emerge-aarch64-cross-linux-gnu foo
will now correctly emerge Go package "foo" for aarch64 instead of
x86_64.
The eclass provides a single helper function
go-env_set_compile_environment()
intended to be called by other Go eclasses in an early build stage.
Ebuilds may also explicitly call this function.
Calls to this function from _src_prepare in go-module.eclass,
golang-vcs-snapshot.eclass, and golang-vcs.eclass have also been added
to un-break cross-compilation of existing Go packages.
Signed-off-by: Thilo Fromm
Closes: https://github.com/gentoo/gentoo/pull/33539
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 48 +++
eclass/go-module.eclass | 5 +++-
eclass/golang-vcs-snapshot.eclass | 5 +++-
eclass/golang-vcs.eclass | 5 +++-
4 files changed, 60 insertions(+), 3 deletions(-)
create mode 100644 eclass/go-env.eclass
See the GitHub link for earlier discussion. This still doesn't work for
cross-prefix
builds, unless you set CGO_ENABLED=1, but fixing that involves different code
and can
be done later.
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
new file mode 100644
index ..0b4d44658a07
--- /dev/null
+++ b/eclass/go-env.eclass
@@ -0,0 +1,48 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-env.eclass
+# @MAINTAINER:
+# Flatcar Maintainers
+# @AUTHOR:
+# Flatcar Maintainers
+# @BLURB: Helper eclass for setting the Go compile environment. Required for
cross-compiling.
+# @DESCRIPTION:
+# This eclass includes a helper function for setting the compile environment
for Go ebuilds.
+# Intended to be called by other Go eclasses in an early build stage, e.g.
src_unpack.
+
+if [[ -z ${_GO_ENV_ECLASS} ]]; then
+_GO_ENV_ECLASS=1
+
+inherit toolchain-funcs
+
+# @FUNCTION: go-env_set_compile_environment
+# @DESCRIPTION:
+# Set up basic compile environment: CC, CXX, and GOARCH.
+# Also carry over CFLAGS, LDFLAGS and friends.
+# Required for cross-compiling with crossdev.
+# If not set, host defaults will be used and the resulting binaries are host
arch.
+# (e.g. "emerge-aarch64-cross-linux-gnu foo" run on x86_64 will emerge "foo"
for x86_64
+# instead of aarch64)
+go-env_set_compile_environment() {
+ local arch=$(tc-arch "${CHOST}}")
+ case "${arch}" in
+ x86)GOARCH="386" ;;
+ x64-*) GOARCH="amd64" ;;
+ ppc64) if [[ "$(tc-endian "${${CHOST}}")" = "big" ]] ; then
+ GOARCH="ppc64"
+ else
+ GOARCH="ppc64le"
+ fi ;;
+ *) GOARCH="${arch}" ;;
+ esac
+
+ tc-export CC CXX
+ export GOARCH
+ export CGO_CFLAGS="${CGO_CFLAGS:-$CFLAGS}"
+ export CGO_CPPFLAGS="${CGO_CPPFLAGS:-$CPPFLAGS}"
+ export CGO_CXXFLAGS="${CGO_CXXFLAGS:-$CXXFLAGS}"
+ export CGO_LDFLAGS="${CGO_LDFLAGS:-$LDFLAGS}"
+}
+
+fi
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 6c58d7f26f07..701d36e012e2 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -68,7 +68,7 @@ esac
if [[ -z ${_GO_MODULE_ECLASS} ]]; then
_GO_MODULE_ECLASS=1
-inherit multiprocessing toolchain-funcs
+inherit multiprocessing toolchain-funcs go-env
if [[ ! ${GO_OPTIONAL} ]]; then
BDEPEND=">=dev-lang/go-1.18"
@@ -363,6 +363,7 @@ go-module_setup_proxy() {
#local go proxy. This mode is deprecated.
# 2. Otherwise, if EGO_VENDOR is set, bail out, as this functionality was
removed.
# 3. Otherwise, call 'ego mod verify' and then do a normal unpack.
+# Set compile env via go-env.
go-module_src_unpack() {
if use amd64 || use arm || use arm64 ||
( use ppc64 && [[ $(tc-endian) == "little" ]] ) || use s390 ||
use x86; then
@@ -386,6 +387,8 @@ go-module_src_unpack() {
${nf} ego mod verify
fi
fi
+
+ go-env_set_compile_environment
}
# @FUNCTION: _go-module_src_unpack_gosum
diff --git a/eclass/golang-vcs-snapshot.eclass
b/eclass/golang-vcs-snapshot.eclass
index 9c199bbbd8c5..d34b8a6e913d 100644
--- a/eclass/golang-vcs-snapshot.eclass
+++ b/eclass/golang-vcs-snapshot.eclass
@@ -52,7 +52,7 @@ esac
if [[ -z ${_GOLANG_VCS_SNA
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
On Thu, 2023-09-28 at 02:15 +0100, Sam James wrote: > James Le Cuirot writes: > > > This fixes cross-prefix installations. > > Do we need to crank the minimum version we depend on for gpep517 then? Woops, yes. Got over-excited when I saw it was stabilised. Thanks. :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
This fixes cross-prefix installations.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 56afcdc5bcb8..1cc91110dccf 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -210,7 +210,7 @@ _distutils_set_globals() {
fi
bdep='
- >=dev-python/gpep517-13[${PYTHON_USEDEP}]
+ >=dev-python/gpep517-15[${PYTHON_USEDEP}]
'
case ${DISTUTILS_USE_PEP517} in
flit)
@@ -1444,6 +1444,7 @@ distutils_pep517_install() {
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
local cmd=(
gpep517 build-wheel
+ --prefix="${EPREFIX}/usr"
--backend "${build_backend}"
--output-fd 3
--wheel-dir "${WHEEL_BUILD_DIR}"
--
2.41.0
[gentoo-dev] [PATCH] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
This fixes cross-prefix installations.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 56afcdc5bcb8..838162c6b0f8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1444,6 +1444,7 @@ distutils_pep517_install() {
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
local cmd=(
gpep517 build-wheel
+ --prefix="${EPREFIX}/usr"
--backend "${build_backend}"
--output-fd 3
--wheel-dir "${WHEEL_BUILD_DIR}"
--
2.41.0
[gentoo-dev] [PATCH] python-utils-r1.eclass: Redo cross-prefix support using sysconfig
We recently supported cross-prefix by rewriting PYTHON_SITEDIR and
PYTHON_INCLUDEDIR from BROOT to EPREFIX. We now know that you can get
sysconfig to use EPREFIX in the first place, which is cleaner.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index f9c6d161d3f3..bd30c1203180 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -346,24 +346,22 @@ _python_export() {
PYTHON_SITEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
PYTHON_SITEDIR=$(
- "${PYTHON}" - <<-EOF || die
- import sysconfig
-
print(sysconfig.get_path("purelib"))
+ "${PYTHON}" - "${EPREFIX}/usr" <<-EOF
|| die
+ import sys, sysconfig
+
print(sysconfig.get_path("purelib", vars={"base": sys.argv[1]}))
EOF
)
-
PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
PYTHON_INCLUDEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
PYTHON_INCLUDEDIR=$(
- "${PYTHON}" - <<-EOF || die
- import sysconfig
-
print(sysconfig.get_path("platinclude"))
+ "${PYTHON}" - "${ESYSROOT}/usr" <<-EOF
|| die
+ import sys, sysconfig
+
print(sysconfig.get_path("platinclude", vars={"installed_platbase":
sys.argv[1]}))
EOF
)
-
PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
[gentoo-dev] [PATCH] distutils-r1.eclass: Use gpep517's new prefix rewriting options
It is okay for these to be given as an empty string.
Signed-off-by: James Le Cuirot
---
This cannot be applied until gpep517-14 is stable, but I'm just getting
it reviewed in readiness.
eclass/distutils-r1.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 91de144e1110..34ef3b6e55f3 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -210,7 +210,7 @@ _distutils_set_globals() {
fi
bdep='
- >=dev-python/gpep517-13[${PYTHON_USEDEP}]
+ >=dev-python/gpep517-14[${PYTHON_USEDEP}]
'
case ${DISTUTILS_USE_PEP517} in
flit)
@@ -1452,7 +1452,11 @@ distutils_pep517_install() {
cmd+=( --config-json "${config_settings}" )
fi
if [[ -n ${SYSROOT} ]]; then
- cmd+=( --sysroot "${SYSROOT}" )
+ cmd+=(
+ --sysroot "${SYSROOT}"
+ --rewrite-prefix-from "${BROOT}"
+ --rewrite-prefix-to "${EPREFIX}"
+ )
fi
printf '%s\n' "${cmd[*]}"
local wheel=$(
--
2.41.0
[gentoo-dev] [PATCH v3] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
host's Python. This breaks down when the build host's prefix differs
from the target host's prefix, so chop off the former and prepend the
latter.
This assumes that each Python implementation is always installed using
the same scheme. Meson already makes this assumption, and gpep517 makes
a similar assumption to determine Python's stdlib location.
We could improve on this and determine these locations using SYSROOT's
sysconfigdata file, like gpep517 does, but this seems needlessly
complex. We would need to take this approach for PYTHON_LIBPATH and
PYTHON_CONFIG, but these are only used by handful of packages.
${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
Signed-off-by: James Le Cuirot
---
Note that gpep517 also needs the same treatment, but I'll handle that
later. This at least allows Portage itself to be installed.
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2fffd6d56bf5..f9c6d161d3f3 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -351,6 +351,7 @@ _python_export() {
print(sysconfig.get_path("purelib"))
EOF
)
+
PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
@@ -362,6 +363,7 @@ _python_export() {
print(sysconfig.get_path("platinclude"))
EOF
)
+
PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
On Wed, 2023-08-16 at 12:47 +0200, Michał Górny wrote:
> On Wed, 2023-08-16 at 07:39 +0100, James Le Cuirot wrote:
> > We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
> > host's Python. This breaks down when the build host's prefix differs
> > from the target host's prefix, so chop off the former and prepend the
> > latter.
> >
> > This assumes that each Python implementation is always installed using
> > the same scheme. Meson already makes this assumption, and gpep517 makes
> > a similar assumption to determine Python's stdlib location.
> >
> > We could improve on this and determine these locations using SYSROOT's
> > sysconfigdata file, like gpep517 does, but this seems needlessly
> > complex. We would need to take this approach for PYTHON_LIBPATH and
> > PYTHON_CONFIG, but these are only used by handful of packages.
> >
> > ${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
> > reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> >
> > Note that gpep517 also needs the same treatment, but I'll handle that
> > later. This at least allows Portage itself to be installed.
> >
> > eclass/python-utils-r1.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index 2fffd6d56bf5..abfb74832f30 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -351,6 +351,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("purelib"))
> > EOF
> > )
> > +
> > PYTHON_SITEDIR="${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}"
> > export PYTHON_SITEDIR
> > debug-print "${FUNCNAME}: PYTHON_SITEDIR =
> > ${PYTHON_SITEDIR}"
> > ;;
> > @@ -362,6 +363,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("platinclude"))
> > EOF
> > )
> > +
> > PYTHON_INCLUDEDIR="${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}"
> > export PYTHON_INCLUDEDIR
> > debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
> > ${PYTHON_INCLUDEDIR}"
> >
> >
>
> You don't seem to have changed that, actually.
Ah! Sorry, I shouldn't make changes in a rush before starting the day job.
ionen said globbing, when this is technically pattern matching, so I got
confused and thought quoting the whole thing would fix it. Actually globbing
doesn't even occur when assigning variables.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
host's Python. This breaks down when the build host's prefix differs
from the target host's prefix, so chop off the former and prepend the
latter.
This assumes that each Python implementation is always installed using
the same scheme. Meson already makes this assumption, and gpep517 makes
a similar assumption to determine Python's stdlib location.
We could improve on this and determine these locations using SYSROOT's
sysconfigdata file, like gpep517 does, but this seems needlessly
complex. We would need to take this approach for PYTHON_LIBPATH and
PYTHON_CONFIG, but these are only used by handful of packages.
${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
Signed-off-by: James Le Cuirot
---
Note that gpep517 also needs the same treatment, but I'll handle that
later. This at least allows Portage itself to be installed.
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2fffd6d56bf5..abfb74832f30 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -351,6 +351,7 @@ _python_export() {
print(sysconfig.get_path("purelib"))
EOF
)
+
PYTHON_SITEDIR="${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}"
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
@@ -362,6 +363,7 @@ _python_export() {
print(sysconfig.get_path("platinclude"))
EOF
)
+
PYTHON_INCLUDEDIR="${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}"
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
On Tue, 2023-08-15 at 18:25 -0400, Ionen Wolkens wrote:
> On Tue, Aug 15, 2023 at 11:02:54PM +0100, James Le Cuirot wrote:
> > We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
> > host's Python. This breaks down when the build host's prefix differs
> > from the target host's prefix, so chop off the former and prepend the
> > latter.
> >
> > This assumes that each Python implementation is always installed using
> > the same scheme. Meson already makes this assumption, and gpep517 makes
> > a similar assumption to determine Python's stdlib location.
> >
> > We could improve on this and determine these locations using SYSROOT's
> > sysconfigdata file, like gpep517 does, but this seems needlessly
> > complex. We would need to take this approach for PYTHON_LIBPATH and
> > PYTHON_CONFIG, but these are only used by handful of packages.
> >
> > ${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
> > reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> >
> > Note that gpep517 also needs the same treatment, but I'll handle that
> > later. This at least allows Portage itself to be installed.
> >
> > eclass/python-utils-r1.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index 2fffd6d56bf5..68b28c0ed806 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -351,6 +351,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("purelib"))
> > EOF
> > )
> > +
> > PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}
>
> For a minor nitpick, should use quotes for the substitution, aka:
>
> PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#"${BROOT-${EPREFIX}}"}
>
> Or else if BROOT/EPREFIX somehow had glob characters in them, they will
> actually be globbing.
>
> > export PYTHON_SITEDIR
> > debug-print "${FUNCNAME}: PYTHON_SITEDIR =
> > ${PYTHON_SITEDIR}"
> > ;;
> > @@ -362,6 +363,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("platinclude"))
> > EOF
> > )
> > +
> > PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}
>
> Same here.
>
> > export PYTHON_INCLUDEDIR
> > debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
> > ${PYTHON_INCLUDEDIR}"
> >
> > --
> > 2.41.0
> >
Oops, not like me to miss that. Thanks!
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
host's Python. This breaks down when the build host's prefix differs
from the target host's prefix, so chop off the former and prepend the
latter.
This assumes that each Python implementation is always installed using
the same scheme. Meson already makes this assumption, and gpep517 makes
a similar assumption to determine Python's stdlib location.
We could improve on this and determine these locations using SYSROOT's
sysconfigdata file, like gpep517 does, but this seems needlessly
complex. We would need to take this approach for PYTHON_LIBPATH and
PYTHON_CONFIG, but these are only used by handful of packages.
${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
Signed-off-by: James Le Cuirot
---
Note that gpep517 also needs the same treatment, but I'll handle that
later. This at least allows Portage itself to be installed.
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2fffd6d56bf5..68b28c0ed806 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -351,6 +351,7 @@ _python_export() {
print(sysconfig.get_path("purelib"))
EOF
)
+
PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
@@ -362,6 +363,7 @@ _python_export() {
print(sysconfig.get_path("platinclude"))
EOF
)
+
PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
[gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: Fix shebangs using ${EPYTHON}, not ${PYTHON}
${PYTHON} points to BROOT's Python because it's usually used for calling
Python during the build. This value will be wrong at runtime after
building cross-prefix.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 56b1b81edd2e..2555ce12d066 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1023,8 +1023,6 @@ python_fix_shebang() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${EPYTHON} ]] || die "${FUNCNAME}: EPYTHON unset (pkg_setup not
called?)"
- local PYTHON
- _python_export "${EPYTHON}" PYTHON
local force quiet
while [[ ${@} ]]; do
@@ -1097,7 +1095,7 @@ python_fix_shebang() {
if [[ ! ${error} ]]; then
debug-print "${FUNCNAME}: in file ${f#${D%/}}"
debug-print "${FUNCNAME}: rewriting shebang:
${shebang}"
- sed -i -e "1s@${from}@#!${PYTHON}@" "${f}" ||
die
+ sed -i -e
"1s@${from}@#!${EPREFIX}/usr/bin/${EPYTHON}@" "${f}" || die
any_fixed=1
else
eerror "The file has incompatible shebang:"
--
2.41.0
[gentoo-dev] [PATCH 1/2] python-utils-r1.eclass: Remove old EAPI hack for exporting PYTHON
This eclass is EAPI 7+ now, so we can assume that BROOT is available.
This was broken anyway because it seems that Portage doesn't set BROOT
when it's empty.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a883135eaa41..56b1b81edd2e 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -338,7 +338,7 @@ _python_export() {
debug-print "${FUNCNAME}: EPYTHON = ${EPYTHON}"
;;
PYTHON)
- export
PYTHON=${BROOT-${EPREFIX}}/usr/bin/${impl}
+ export PYTHON=${BROOT}/usr/bin/${impl}
debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
;;
PYTHON_SITEDIR)
--
2.41.0
[gentoo-dev] Last rites: games-action/descent3 and games-action/descent3-demo
# James Le Cuirot (2023-06-25) # Impossible to legally obtain the native full game now. It freezes on keyboard # input, is incompatible with PipeWire, and requires gamescope to display under # Wayland. In short, it's a lost cause. Removal in 30 days. Bug #436140. games-action/descent3 games-action/descent3-demo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] cmake.eclass: Set CMAKE_SYSROOT when building with SYSROOT=
From: Raul E Rangel
When performing a SYSROOT= build, the --sysroot parameter was not
getting passed to the compiler if the CBUILD and CHOST matched. This
results in the build attempting to use BROOT libraries and headers
instead of the ones from the SYSROOT.
This change will allow `llvm` to be built into a new SYSROOT.
ROOT=/build/amd64-host emerge sys-devel/llvm
Signed-off-by: Raul E Rangel
Closes: https://github.com/gentoo/gentoo/pull/30658
Signed-off-by: James Le Cuirot
---
eclass/cmake.eclass | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 24787f1c2a49..1cdbc123a243 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -484,17 +484,17 @@ cmake_src_configure() {
cat >> "${toolchain_file}" <<- _EOF_ || die
set(CMAKE_SYSTEM_NAME "${sysname}")
_EOF_
+ fi
- if [ "${SYSROOT:-/}" != "/" ] ; then
- # When cross-compiling with a sysroot (e.g. with
crossdev's emerge wrappers)
- # we need to tell cmake to use libs/headers from the
sysroot but programs from / only.
- cat >> "${toolchain_file}" <<- _EOF_ || die
- set(CMAKE_SYSROOT "${ESYSROOT}")
- set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
- set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
- set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
- _EOF_
- fi
+ if [[ ${SYSROOT:-/} != / ]] ; then
+ # When building with a sysroot (e.g. with crossdev's emerge
wrappers)
+ # we need to tell cmake to use libs/headers from the sysroot
but programs from / only.
+ cat >> "${toolchain_file}" <<- _EOF_ || die
+ set(CMAKE_SYSROOT "${ESYSROOT}")
+ set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+ set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+ set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+ _EOF_
fi
if use prefix-guest; then
--
2.40.1
[gentoo-dev] [PATCH] qmake-utils.eclass: Force QMAKE_*FLAGS_RELEASE_WITH_DEBUGINFO to blank
These variables are usually defined as:
$ fgrep RELEASE_WITH_DEBUGINFO /usr/lib64/qt5/mkspecs/common/gcc-base.conf
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += $$QMAKE_CFLAGS_OPTIMIZE -g
QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO +=
$$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO +=
They can take precedence over our provided flags, so they need to be
blanked out. They are normally only used when the user specifies
-force-debug-info, but sometimes upstreams enable this themselves.
Signed-off-by: James Le Cuirot
---
eclass/qmake-utils.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/qmake-utils.eclass b/eclass/qmake-utils.eclass
index a86ce1fbabb8..49e7d5d15883 100644
--- a/eclass/qmake-utils.eclass
+++ b/eclass/qmake-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: qmake-utils.eclass
@@ -78,12 +78,15 @@ qt5_get_qmake_args() {
QMAKE_CFLAGS="${CFLAGS}"
QMAKE_CFLAGS_RELEASE=
QMAKE_CFLAGS_DEBUG=
+ QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO=
QMAKE_CXXFLAGS="${CXXFLAGS}"
QMAKE_CXXFLAGS_RELEASE=
QMAKE_CXXFLAGS_DEBUG=
+ QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO=
QMAKE_LFLAGS="${LDFLAGS}"
QMAKE_LFLAGS_RELEASE=
QMAKE_LFLAGS_DEBUG=
+ QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO=
EOF
}
--
2.40.1
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
On Wed, 2023-05-31 at 11:43 +, Andrey Grozin wrote: > Hello *, > > wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on > wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the > tree. Probably, in a vast majority of cases 3.0 can be simply replaced by > 3.2 without any negative consequences. What could be a reasonable way to > organize the transition 3.0 -> 3.2 in the tree? File a zillion bugs? > > The fact that this dependence is written in a special syntax > WX_GTK_VER="3.0-gtk3" > makes such a transition more difficult. Unlike the normal dependency > syntax, it is not possible to write something like > x11-libs/wxGTK:*= > This is unfortunate. The 3.0 -> 3.2 transition absolutely requires to edit > ebuild texts, unlike :*= where the same ebuild can work with different > slots (just a recompilation is sufficient for transition). This fact > makes it impossible for an ebuild to work with both slots. In a majority > of cases, I suppose, it would be desirable to allow an ebuild to work with > any of these 2 slots, without a necessity to edit it. But, alas, this is > not possible. > > Andrey games-engines/odamex is another one that doesn't work with 3.2. It just crashes. Haven't looked into it. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: www-client/chromium-bin
> On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote: > > # Out of date by several versions. Many unresolved security > > # vulnerabilities. Lack of manpower/interest in keeping it up to date. > > # Removal on 2023-06-03. > > www-client/chromium-bin > > > On Thu, 2023-05-04 at 18:59 +, Maciej Barć wrote: > R.i.p. to a lot od desktop users on non-state-of-the-art HW. > But chromium source build was unusable for long time with big UI bugs. Those affected can try www-client/vivaldi instead. If you're unaware, it's based on Chromium. It's also a binary package, I keep it well-maintained, and if you ask me, it's just better all round. :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Add PYTHON_DEPS to DEPEND unconditionally
On 12 April 2023 16:58:58 BST, "Michał Górny" wrote:
>From: Raul E Rangel
>
>Python distutils packages that build C extensions are currently not
>declaring PYTHON_DEPS as part of their DEPEND declaration. This results
>in build errors when cross compiling using ROOT=.
>
>i.e.,
> In file included from src/setproctitle.c:14:
> In file included from src/spt.h:15:
> src/spt_python.h:15:10: fatal error: 'Python.h' file not found
> #include
>^~
> 1 error generated.
>
>Since the distutils-r1 eclass currently sets the RDEPEND and BDEPEND
>variables it makes sense to have the eclass also set the DEPEND
>variable. We unconditionally add it to keep the API simple. If in the
>future this is problematic, we can maybe add a DISTUTILS_PURE_PYTHON
>eclass variable that will omit the DEPEND.
>
>Signed-off-by: Raul E Rangel
>Closes: https://github.com/gentoo/gentoo/pull/30469
>Signed-off-by: Michał Górny
>---
> eclass/distutils-r1.eclass | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
>index 09684781de2a..7e9cd6ef9b5a 100644
>--- a/eclass/distutils-r1.eclass
>+++ b/eclass/distutils-r1.eclass
>@@ -34,8 +34,8 @@
> # functions, you should consider calling the defaults (and especially
> # distutils-r1_python_prepare_all).
> #
>-# Please note that distutils-r1 sets RDEPEND and BDEPEND (or DEPEND
>-# in earlier EAPIs) unconditionally for you.
>+# Please note that distutils-r1 sets BDEPEND, DEPEND, and RDEPEND
>+# unconditionally for you.
> #
> # Also, please note that distutils-r1 will always inherit python-r1
> # as well. Thus, all the variables defined and documented there are
>@@ -307,6 +307,12 @@ _distutils_set_globals() {
> fi
>
> if [[ ! ${DISTUTILS_OPTIONAL} ]]; then
>+ # This dependency is only required for packages that build
>+ # C extensions. It was deemed cleaner to unconditionally
>+ # add the dependency than add it to the individual
>+ # ebuilds that need it.
>+ DEPEND="${PYTHON_DEPS}"
>+
> RDEPEND="${PYTHON_DEPS} ${rdep}"
> BDEPEND="${PYTHON_DEPS} ${bdep}"
> REQUIRED_USE=${PYTHON_REQUIRED_USE}
I think that's reasonable.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] [PATCH] cmake.eclass: Set CMAKE_SYSROOT in toolchain file when necessary
We previously set CMAKE_FIND_ROOT_PATH, but CMAKE_SYSROOT also sets this
and more. The latter is needed when cross-compiling Fortran code such as
sci-libs/lapack. Without this, it uses the toolchain's default sysroot,
adds a -L/usr/${CHOST}/usr/lib flag based on that, reads the libc.so.6
ld script from this directory, does not apply any sysroot to the paths
within because the script is outside the sysroot, and finally fails when
attempting to link the host's libc.so.6.
Signed-off-by: James Le Cuirot
---
eclass/cmake.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 2c5620adede5..a2ff80a233b4 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -489,7 +489,7 @@ cmake_src_configure() {
# When cross-compiling with a sysroot (e.g. with
crossdev's emerge wrappers)
# we need to tell cmake to use libs/headers from the
sysroot but programs from / only.
cat >> "${toolchain_file}" <<- _EOF_ || die
- set(CMAKE_FIND_ROOT_PATH "${SYSROOT}")
+ set(CMAKE_SYSROOT "${ESYSROOT}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
--
2.39.1
Re: [gentoo-dev] Putting CC and CXX into make.conf
On Thu, 2023-02-09 at 14:03 +0100, Michał Górny wrote:
> Hi,
>
> I'd like to propose that we work towards having good defaults for CC
> and CXX variables in make.conf files. Something like:
>
> CC=${CHOST}-gcc
> CXX=${CHOST}-g++
>
> or:
>
> CC=${CHOST}-cc
> CXX=${CHOST}-c++
>
> Why?
>
> Right now we're pretty much relying on autoconf defaults: if CC/CXX is
> unset, autoconf looks for ${CHOST}-gcc and ${CHOST}-g++ appropriately.
> However, autoconf is only one of the many build systems (and no longer
> very popular, I'd say) and whenever apps use another build system or
> override the default lookup in autoconf, we need to 'tc-export CC CXX'
> in order to ensure that the right name is picked.
>
> Furthermore, some of us (myself included) actually set CC and CXX
> in their make.conf to a different value. As a result, they are exported
> already on our systems and it's hard for us to notice that our ebuilds
> are missing the tc-export call.
>
> I'm not aware of any downsides to having them set by default, except for
> the potentially problematic migration of existing systems.
>
> What are your thoughts?
I've long been surprised that CC/CXX are not exported when the FLAGS are. We
already set these when cross-compiling or when using Clang, and that's been
fine, so I really don't see any issue.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] kernel-2.eclass: Make xmakeopts an array for spaces in toolchain vars
On Mon, 2023-01-23 at 11:20 -0500, Joshua Kinard wrote:
> On 1/21/2023 06:03, James Le Cuirot wrote:
> > Variables like CC can have spaces for additional arguments. This is
> > particularly useful for reliably setting the sysroot.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/kernel-2.eclass | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index 873d4a204669..f7fcf15743f0 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2022 Gentoo Authors
> > +# Copyright 1999-2023 Gentoo Authors
> > # Distributed under the terms of the GNU General Public License v2
> >
> > # @ECLASS: kernel-2.eclass
> > @@ -756,13 +756,22 @@ env_setup_xmakeopts() {
> >
> > # When cross-compiling, we need to set the ARCH/CROSS_COMPILE
> > # variables properly or bad things happen !
> > - xmakeopts="ARCH=${KARCH}"
> > + xmakeopts=( ARCH="${KARCH}" )
> > if [[ ${CTARGET} != ${CHOST} ]] && ! cross_pre_c_headers; then
> > - xmakeopts="${xmakeopts} CROSS_COMPILE=${CTARGET}-"
> > + xmakeopts+=( CROSS_COMPILE="${CTARGET}-" )
> > elif type -p ${CHOST}-ar >/dev/null; then
> > - xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> > + xmakeopts+=( CROSS_COMPILE="${CHOST}-" )
> > fi
> > - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
> > LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) OBJCOPY=$(tc-getOBJCOPY)
> > READELF=$(tc-getREADELF) STRIP=$(tc-getSTRIP)"
> > + xmakeopts+=(
> > + HOSTCC="$(tc-getBUILD_CC)"
> > + CC="$(tc-getCC)"
> > + LD="$(tc-getLD)"
> > + AR="$(tc-getAR)"
> > + NM="$(tc-getNM)"
> > + OBJCOPY="$(tc-getOBJCOPY)"
> > + READELF="$(tc-getREADELF)"
> > + STRIP="$(tc-getSTRIP)"
> > + )
> > export xmakeopts
> > }
> >
> > @@ -850,7 +859,7 @@ install_headers() {
> > local ddir=$(kernel_header_destdir)
> >
> > env_setup_xmakeopts
> > - emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/.. ${xmakeopts}
> > + emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
> > "${xmakeopts[@]}"
> >
> > # let other packages install some of these headers
> > rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
>
> Can we perhaps use this opportunity to make "xmakeopts" more clear via a
> better name, as well as uppercase it
> to indicate that it is an exported variable? E.g., something like
> "CROSS_MAKEOPTS" is more clear to the
> reader than "xmakeopts", IMHO.
>
> I realize such a change may be a tad invasive to the eclass and possibly
> touch some ebuilds, so that may need
> to be a separate patch that this proposed change would then be based off of.
I hadn't noticed some older linux-headers ebuilds use this variable, so thanks
for bringing that to my attention. Arguably they shouldn't, as it appears to
be an internal variable, even if it is exported, but it's been dropped in
later versions anyway. I've now made further changes. Please see the two
additional patches.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 3/3] sys-kernel/linux-headers: Adjust following kernel-2.eclass changes
Signed-off-by: James Le Cuirot
---
sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild | 2 +-
sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild | 2 +-
sys-kernel/linux-headers/linux-headers-5.19.ebuild| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
index 08907ac2fb24..06fcc6978ce1 100644
--- a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
@@ -40,7 +40,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
diff --git a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
index 9d2ebae3daee..dae40c5ab655 100644
--- a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
@@ -43,7 +43,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
diff --git a/sys-kernel/linux-headers/linux-headers-5.19.ebuild
b/sys-kernel/linux-headers/linux-headers-5.19.ebuild
index 527b4b401d6c..8ae17e59be76 100644
--- a/sys-kernel/linux-headers/linux-headers-5.19.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.19.ebuild
@@ -42,7 +42,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
--
2.39.1
[gentoo-dev] [PATCH 2/3] kernel-2.eclass: Rename xmakeopts to more appropriate KERNEL_MAKEOPTS
An upper-case name suggests that the variable is exported. This variable
is also not just used for cross-compiling any more.
Signed-off-by: James Le Cuirot
---
eclass/kernel-2.eclass | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index f7fcf15743f0..3c78aa5a8445 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -745,24 +745,25 @@ cross_pre_c_headers() {
use headers-only && [[ ${CHOST} != ${CTARGET} ]]
}
-# @FUNCTION: env_setup_xmakeopts
+# @FUNCTION: env_setup_kernel_makeopts
# @USAGE:
# @DESCRIPTION:
-# set the ARCH/CROSS_COMPILE when cross compiling
+# Set the toolchain variables, as well as ARCH and CROSS_COMPILE when
+# cross-compiling.
-env_setup_xmakeopts() {
+env_setup_kernel_makeopts() {
# Kernel ARCH != portage ARCH
export KARCH=$(tc-arch-kernel)
# When cross-compiling, we need to set the ARCH/CROSS_COMPILE
# variables properly or bad things happen !
- xmakeopts=( ARCH="${KARCH}" )
+ KERNEL_MAKEOPTS=( ARCH="${KARCH}" )
if [[ ${CTARGET} != ${CHOST} ]] && ! cross_pre_c_headers; then
- xmakeopts+=( CROSS_COMPILE="${CTARGET}-" )
+ KERNEL_MAKEOPTS+=( CROSS_COMPILE="${CTARGET}-" )
elif type -p ${CHOST}-ar >/dev/null; then
- xmakeopts+=( CROSS_COMPILE="${CHOST}-" )
+ KERNEL_MAKEOPTS+=( CROSS_COMPILE="${CHOST}-" )
fi
- xmakeopts+=(
+ KERNEL_MAKEOPTS+=(
HOSTCC="$(tc-getBUILD_CC)"
CC="$(tc-getCC)"
LD="$(tc-getLD)"
@@ -772,7 +773,7 @@ env_setup_xmakeopts() {
READELF="$(tc-getREADELF)"
STRIP="$(tc-getSTRIP)"
)
- export xmakeopts
+ export KERNEL_MAKEOPTS
}
# @FUNCTION: universal_unpack
@@ -858,8 +859,8 @@ install_universal() {
install_headers() {
local ddir=$(kernel_header_destdir)
- env_setup_xmakeopts
- emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
"${xmakeopts[@]}"
+ env_setup_kernel_makeopts
+ emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
"${KERNEL_MAKEOPTS[@]}"
# let other packages install some of these headers
rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
@@ -1425,8 +1426,8 @@ kernel-2_src_unpack() {
[[ -z ${K_NOSETEXTRAVERSION} ]] && unpack_set_extraversion
unpack_fix_install_path
- # Setup xmakeopts and cd into sourcetree.
- env_setup_xmakeopts
+ # Setup KERNEL_MAKEOPTS and cd into sourcetree.
+ env_setup_kernel_makeopts
cd "${S}" || die
if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
--
2.39.1
Re: [gentoo-dev] NEWS: Breaking changes to the RAP Prefix toolchain
On Fri, 2023-01-20 at 23:11 +, James Le Cuirot wrote:
> The context for this is a pull request I've been working on for a few weeks.
>
> https://github.com/gentoo/gentoo/pull/28851
>
> RAP prefix nobbled gcc/clang's sysroot when invoking the linker because glibc
> installed its linker scripts with prefixed paths, such as /path/to/prefix/lib
> rather than just /lib. Adjusting the linker scripts rather than the compiler
> behaviour is more natural and makes cross-compiling far easier.
>
> For the migration procedure, I did try a different approach of manually fixing
> up the linker scripts, but if you do this first, the gcc build fails
> immediately, and if you do this afterwards, the gcc build fails later. A
> symlink is therefore needed to allow the sysroot to be applied, even when the
> linker script paths are still prefixed.
>
> Unfortunately, it's not possible to filter news items on USE flags or even
> profile parents, so I've had to resort to explicitly listing all the prefix
> profiles. Prefix is quite a niche feature, so I don't want to show this news
> to everyone.
Following some feedback elsewhere, I'm going to add an additional paragraph,
because many users are not sure what kind of prefix they have. See below.
>
>
> Title: Breaking changes to the RAP Prefix toolchain
> Author: James Le Cuirot
> Posted: 2023-01-20
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/amd64/17.0/no-multilib/prefix/*
> Display-If-Profile: default/linux/amd64/17.1/no-multilib/prefix/*
> Display-If-Profile: default/linux/amd64/23.0/no-multilib/prefix/*
> Display-If-Profile: default/linux/amd64/23.0/split-usr/no-multilib/prefix/*
> Display-If-Profile: default/linux/arm/17.0/armv7a/prefix/*
> Display-If-Profile: default/linux/arm/23.0/armv7a/prefix/*
> Display-If-Profile: default/linux/arm/23.0/split-usr/armv7a/prefix/*
> Display-If-Profile: default/linux/arm64/17.0/prefix/*
> Display-If-Profile: default/linux/arm64/23.0/prefix/*
> Display-If-Profile: default/linux/arm64/23.0/split-usr/prefix/*
> Display-If-Profile: default/linux/ppc64le/17.0/prefix/*
> Display-If-Profile: default/linux/riscv/20.0/rv64gc/lp64d/prefix/*
> Display-If-Profile: default/linux/riscv/23.0/rv64/lp64d/prefix/*
> Display-If-Profile: default/linux/riscv/23.0/rv64/split-usr/lp64d/prefix/*
> Display-If-Profile: default/linux/x86/17.0/prefix/*
> Display-If-Profile: default/linux/x86/23.0/prefix/*
> Display-If-Profile: default/linux/x86/23.0/split-usr/prefix/*
>
> We are changing the way the toolchain operates on RAP Prefix systems in order
> to
> reduce the number of hacks we need to apply and make cross-compiling easier.
>
> If you using a non-RAP "Prefix Guest" or "Prefix Stack" variant (e.g. macOS)
> then this does not apply.
If you're not sure what kind of prefix you have, then check whether the
prefix-guest USE flag is enabled.
portageq envvar USE | grep prefix-guest
> If you are using a libc other than glibc (e.g. musl) then this *does* apply,
> but
> your libc will *not* break, so you should not carry out the following
> procedure.
> The only other package known to be affected is dev-libs/libbsd, which you can
> simply update. If you find another package affected by this, then please file
> a
> bug report.
>
> WARNING! It is important that you carry out the following procedure, otherwise
> your toolchain will break when you next update your compiler or glibc.
>
> 1. Run the following to create a temporary symlink:
>
> EPREFIX=$(portageq envvar EPREFIX)
> mkdir -p "${EPREFIX}${EPREFIX%/*}"
> ln -sn "${EPREFIX}" "${EPREFIX}${EPREFIX}"
>
> 2. Update or rebuild all installed slots of sys-devel/gcc and
> sys-devel/clang
> (if any). Feel free to remove any you no longer need.
>
> 3. Update or rebuild sys-libs/glibc.
>
> 4. Run the following to remove the symlink:
>
> EPREFIX=$(portageq envvar EPREFIX)
> rm "${EPREFIX}${EPREFIX}"
>
> 5. If dev-libs/libbsd is installed, then update it to 0.11.7-r2 or later.
>
> If you are reading this having updated glibc first and you are no longer able
> to
> build anything, then don't panic. Simply execute the line below and then carry
> out the regular procedure above.
>
> qlist sys-libs/glibc | xargs grep -lIF "GNU ld script" | xargs sed -i -r
> "s: /(usr|lib): $(portageq envvar EPREFIX)/\1:g"
>
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] Remove obsolete FEATURES=force-prefix
On Sun, 2023-01-22 at 09:18 +0100, Ulrich Müller wrote: > Signed-off-by: Ulrich Müller > --- > bin/dohtml.py| 6 ++ > bin/eapi.sh | 4 ++-- > lib/portage/const.py | 3 +-- > lib/portage/package/ebuild/config.py | 11 +++ > man/make.conf.5 | 8 +--- > 5 files changed, 9 insertions(+), 23 deletions(-) +1 signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 7/7] dev-libs/libbsd: Strip prefix from paths in ld script
ld scripts on standalone prefix (RAP) systems should have the prefix stripped
from any paths, as the sysroot is automatically prepended.
I originally thought this script was just used to apply --as-needed and was
therefore unneeded. It's actually used to automatically link libmd when it is
needed.
Signed-off-by: James Le Cuirot
---
dev-libs/libbsd/libbsd-0.11.7-r2.ebuild | 43 +
1 file changed, 43 insertions(+)
create mode 100644 dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
diff --git a/dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
b/dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
new file mode 100644
index ..0fcfb6bd563b
--- /dev/null
+++ b/dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
@@ -0,0 +1,43 @@
+# Copyright 1999-2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+VERIFY_SIG_OPENPGP_KEY_PATH="${BROOT}"/usr/share/openpgp-keys/guillemjover.asc
+inherit multilib multilib-minimal verify-sig
+
+DESCRIPTION="Library to provide useful functions commonly found on BSD systems"
+HOMEPAGE="https://libbsd.freedesktop.org/wiki/
https://gitlab.freedesktop.org/libbsd/libbsd;
+SRC_URI="https://${PN}.freedesktop.org/releases/${P}.tar.xz;
+SRC_URI+=" verify-sig? (
https://${PN}.freedesktop.org/releases/${P}.tar.xz.asc )"
+
+LICENSE="BSD BSD-2 BSD-4 ISC"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64
~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux"
+IUSE="static-libs"
+
+RDEPEND="app-crypt/libmd[${MULTILIB_USEDEP}]"
+DEPEND="${RDEPEND}
+ >=sys-kernel/linux-headers-3.17
+"
+BDEPEND="verify-sig? ( sec-keys/openpgp-keys-guillemjover )"
+
+multilib_src_configure() {
+ # The build system will install libbsd-ctor.a despite USE="-static-libs"
+ # which is correct, see:
+ #
https://gitlab.freedesktop.org/libbsd/libbsd/commit/c5b959028734ca2281250c85773d9b5e1d259bc8
+ ECONF_SOURCE="${S}" econf $(use_enable static-libs static)
+}
+
+multilib_src_install() {
+ emake DESTDIR="${D}" install
+
+ find "${ED}" -type f -name "*.la" -delete || die
+
+ # ld scripts on standalone prefix (RAP) systems should have the prefix
+ # stripped from any paths, as the sysroot is automatically prepended.
+ local ldscript=${ED}/usr/$(get_libdir)/${PN}$(get_libname)
+ if use prefix && ! use prefix-guest && grep -qIF "ld script"
"${ldscript}" 2>/dev/null; then
+ sed -i "s|${EPREFIX}/|/|g" "${ldscript}" || die
+ fi
+}
--
2.39.1
[gentoo-dev] [PATCH 6/7] python-utils-r1.eclass: Use BROOT rather than EPREFIX for PYTHON var
The PYTHON variable is used for the wrapper shebangs. These should point
to the build system rather than the host system. The variable is also
used in other contexts, but the build system is still likely to be most
appropriate. If this does break anything, it'll only be for prefixed
systems.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 43472bd1fae0..bc397229a670 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -332,7 +332,7 @@ _python_export() {
debug-print "${FUNCNAME}: EPYTHON = ${EPYTHON}"
;;
PYTHON)
- export PYTHON=${EPREFIX}/usr/bin/${impl}
+ export
PYTHON=${BROOT-${EPREFIX}}/usr/bin/${impl}
debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
;;
PYTHON_SITEDIR)
--
2.39.1
[gentoo-dev] [PATCH 5/7] sys-devel/clang: Move clang prefix tweaks from profile
Signed-off-by: James Le Cuirot
---
profiles/features/prefix/standalone/profile.bashrc | 11 +--
sys-devel/clang/clang-13.0.1.ebuild| 5 +
sys-devel/clang/clang-14.0.6-r1.ebuild | 5 +
sys-devel/clang/clang-15.0.6-r1.ebuild | 5 +
sys-devel/clang/clang-15.0.7-r1.ebuild | 5 +
sys-devel/clang/clang-16.0.0..ebuild | 5 +
sys-devel/clang/clang-16.0.0_pre20230101.ebuild| 5 +
7 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index 57ec4b57abcb..d46933210dcc 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -9,16 +9,7 @@
# Disable RAP trick during bootstrap stage2
[[ -z ${BOOTSTRAP_RAP_STAGE2} ]] || return 0
-if [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure ]];
then
-ebegin "Use ${EPREFIX} as default sysroot"
-sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
-eend $?
-pushd "${S}/lib/Driver/ToolChains" >/dev/null
-ebegin "Use dynamic linker from ${EPREFIX}"
-sed -i -e "/LibDir.*Loader/s@return \"\/\"@return \"${EPREFIX%/}/\"@"
Linux.cpp
-eend $?
-popd >/dev/null
-elif [[ ${CATEGORY}/${PN} == sys-devel/binutils && ${EBUILD_PHASE} == prepare
]]; then
+if [[ ${CATEGORY}/${PN} == sys-devel/binutils && ${EBUILD_PHASE} == prepare
]]; then
ebegin "Prefixifying native library path"
sed -i -r "/NATIVE_LIB_DIRS/s,((/usr(/local|)|)/lib),${EPREFIX}\1,g" \
"${S}"/ld/configure.tgt
diff --git a/sys-devel/clang/clang-13.0.1.ebuild
b/sys-devel/clang/clang-13.0.1.ebuild
index 5e10d595d900..c3a97feedae7 100644
--- a/sys-devel/clang/clang-13.0.1.ebuild
+++ b/sys-devel/clang/clang-13.0.1.ebuild
@@ -82,6 +82,10 @@ src_prepare() {
eprefixify \
lib/Frontend/InitHeaderSearch.cpp \
lib/Driver/ToolChains/Darwin.cpp || die
+
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]]; then
+ sed -i "/LibDir.*Loader/s@return \"\/\"@return
\"${EPREFIX}/\"@" lib/Driver/ToolChains/Linux.cpp || die
+ fi
}
check_distribution_components() {
@@ -224,6 +228,7 @@ multilib_src_configure() {
local clang_version=$(ver_cut 1-3 "${llvm_version}")
local mycmakeargs=(
+ -DDEFAULT_SYSROOT=$(usex prefix-guest "" "${EPREFIX}")
-DLLVM_CMAKE_PATH="${EPREFIX}/usr/lib/llvm/${SLOT}/$(get_libdir)/cmake/llvm"
-DCMAKE_INSTALL_PREFIX="${EPREFIX}/usr/lib/llvm/${SLOT}"
-DCMAKE_INSTALL_MANDIR="${EPREFIX}/usr/lib/llvm/${SLOT}/share/man"
diff --git a/sys-devel/clang/clang-14.0.6-r1.ebuild
b/sys-devel/clang/clang-14.0.6-r1.ebuild
index de10ab36054f..5cdb584470ac 100644
--- a/sys-devel/clang/clang-14.0.6-r1.ebuild
+++ b/sys-devel/clang/clang-14.0.6-r1.ebuild
@@ -95,6 +95,10 @@ src_prepare() {
eprefixify \
lib/Lex/InitHeaderSearch.cpp \
lib/Driver/ToolChains/Darwin.cpp || die
+
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]]; then
+ sed -i "/LibDir.*Loader/s@return \"\/\"@return
\"${EPREFIX}/\"@" lib/Driver/ToolChains/Linux.cpp || die
+ fi
}
check_distribution_components() {
@@ -234,6 +238,7 @@ multilib_src_configure() {
local clang_version=$(ver_cut 1-3 "${llvm_version}")
local mycmakeargs=(
+ -DDEFAULT_SYSROOT=$(usex prefix-guest "" "${EPREFIX}")
-DLLVM_CMAKE_PATH="${EPREFIX}/usr/lib/llvm/${SLOT}/$(get_libdir)/cmake/llvm"
-DCMAKE_INSTALL_PREFIX="${EPREFIX}/usr/lib/llvm/${SLOT}"
-DCMAKE_INSTALL_MANDIR="${EPREFIX}/usr/lib/llvm/${SLOT}/share/man"
diff --git a/sys-devel/clang/clang-15.0.6-r1.ebuild
b/sys-devel/clang/clang-15.0.6-r1.ebuild
index 0e089832722b..0d534ff751d3 100644
--- a/sys-devel/clang/clang-15.0.6-r1.ebuild
+++ b/sys-devel/clang/clang-15.0.6-r1.ebuild
@@ -86,6 +86,10 @@ src_prepare() {
eprefixify \
lib/Lex/InitHeaderSearch.cpp \
lib/Driver/ToolChains/Darwin.cpp || die
+
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]]; then
+ sed -i "/LibDir.*Loader/s@return \"\/\"@return
\"${EPREFIX}/\"@" lib/Driver/ToolChains/Linux.cpp || die
+ fi
}
check_distribution_components() {
@@ -246,6 +250,7 @@ get_distribution_components() {
multilib_src_configure() {
local mycmakeargs=(
+
[gentoo-dev] [PATCH 4/7] toolchain.eclass: Move remaining gcc prefix tweaks from profile
Signed-off-by: James Le Cuirot
---
eclass/toolchain.eclass| 13 +
profiles/features/prefix/standalone/profile.bashrc | 14 +-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 479814f0df3e..6d8901d21812 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -719,6 +719,19 @@ toolchain_src_prepare() {
einfo "Remove texinfo (bug #198182, bug #464008)"
eapply "${FILESDIR}"/gcc-configure-texinfo.patch
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]] ; then
+ einfo "Prefixifying dynamic linkers..."
+ for f in gcc/config/*/*linux*.h ; do
+ ebegin " Updating ${f}"
+ if [[ ${f} == gcc/config/rs6000/linux*.h ]]; then
+ sed -i -r
"s,(DYNAMIC_LINKER_PREFIX\s+)\"\",\1\"${EPREFIX}\",g" "${f}" || die
+ else
+ sed -i -r
"/_DYNAMIC_LINKER/s,([\":])(/lib),\1${EPREFIX}\2,g" "${f}" || die
+ fi
+ eend $?
+ done
+ fi
+
# >=gcc-4
if [[ -x contrib/gcc_update ]] ; then
einfo "Touching generated files"
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index 043f766c37e9..57ec4b57abcb 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -9,19 +9,7 @@
# Disable RAP trick during bootstrap stage2
[[ -z ${BOOTSTRAP_RAP_STAGE2} ]] || return 0
-if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE} == configure ]];
then
-cd "${S}"
-einfo "Prefixifying dynamic linkers..."
-for h in gcc/config/*/*linux*.h; do
- ebegin " Updating $h"
- if [[ "${h}" == gcc/config/rs6000/linux*.h ]]; then
- sed -i -r "s,(DYNAMIC_LINKER_PREFIX\s+)\"\",\1\"${EPREFIX}\",g" $h
- else
- sed -i -r "/_DYNAMIC_LINKER/s,([\":])(/lib),\1${EPREFIX}\2,g" $h
- fi
- eend $?
-done
-elif [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure
]]; then
+if [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure ]];
then
ebegin "Use ${EPREFIX} as default sysroot"
sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
eend $?
--
2.39.1
[gentoo-dev] [PATCH 3/7] toolchain.eclass: Fix cross-compiling gcc for standalone prefix
Standalone prefix has always configured gcc with a sysroot, but the
location of this sysroot is different at build time when
cross-compiling. gcc has a separate configure option for that.
prefix-guest systems do not have a sysroot applied, as they use the
host's libc.
Move this code from the prefix profile into the eclass so that it's less
of a special case. We can avoid relying on the `BOOTSTRAP_RAP_STAGE2`
variable by checking for the `prefix-guest` USE flag instead, as a
prefix-guest profile is now used for RAP stage 2.
Signed-off-by: James Le Cuirot
---
eclass/toolchain.eclass | 15 +++
.../features/prefix/standalone/profile.bashrc | 3 ---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 0dd23d93e383..479814f0df3e 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1200,6 +1200,21 @@ toolchain_src_configure() {
confgcc+=( --enable-threads=posix )
;;
esac
+
+ if ! use prefix-guest ; then
+ # GNU ld scripts, such as those in glibc, reference
unprefixed paths
+ # as the sysroot given here is automatically prepended.
For
+ # prefix-guest, we use the host's libc instead.
+ if [[ -n ${EPREFIX} ]] ; then
+ confgcc+=( --with-sysroot="${EPREFIX}" )
+ fi
+
+ # We need to build against the right headers and
libraries. Again,
+ # for prefix-guest, this is the host's.
+ if [[ -n ${ESYSROOT} ]] ; then
+ confgcc+=( --with-build-sysroot="${ESYSROOT}" )
+ fi
+ fi
fi
# __cxa_atexit is "essential for fully standards-compliant handling of
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index 3cdda77b9a88..043f766c37e9 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -21,9 +21,6 @@ if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE}
== configure ]]; the
fi
eend $?
done
-
-# use sysroot of toolchain to get correct include and library at compile
time
-EXTRA_ECONF="${EXTRA_ECONF} --with-sysroot=${EPREFIX}"
elif [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure
]]; then
ebegin "Use ${EPREFIX} as default sysroot"
sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
--
2.39.1
[gentoo-dev] [PATCH 2/7] usr-ldscript.eclass: Don't add prefix to ld script paths when standalone
The toolchain's sysroot is automatically prepended to these paths.
Gentoo Prefix used to prevent this, but now we're changing that.
prefix-guest systems do not have a sysroot applied, as they use the
host's libc, so the prefix is still needed in this case.
This is actually all moot because the gen_usr_ldscript function is a
noop on prefix anyway, but I'm still adding this in case that changes.
Signed-off-by: James Le Cuirot
---
eclass/usr-ldscript.eclass | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/eclass/usr-ldscript.eclass b/eclass/usr-ldscript.eclass
index b73d538ae5bb..6dbce59c6400 100644
--- a/eclass/usr-ldscript.eclass
+++ b/eclass/usr-ldscript.eclass
@@ -39,6 +39,13 @@ gen_usr_ldscript() {
tc-is-static-only && return
use prefix && return
+ # The toolchain's sysroot is automatically prepended to paths in this
+ # script. We therefore need to omit EPREFIX on standalone prefix (RAP)
+ # systems. prefix-guest (non-RAP) systems don't apply a sysroot so
EPREFIX
+ # is still needed in that case. This is moot because the above line
makes
+ # the function a noop on prefix, but we keep this in case that changes.
+ local prefix=$(usex prefix-guest "${EPREFIX}" "")
+
# We only care about stuffing / for the native ABI. #479448
if [[ $(type -t multilib_is_native_abi) == "function" ]] ; then
multilib_is_native_abi || return 0
@@ -154,7 +161,7 @@ gen_usr_ldscript() {
See bug https://bugs.gentoo.org/4411 for more info.
*/
${output_format}
- GROUP ( ${EPREFIX}/${libdir}/${tlib} )
+ GROUP ( ${prefix}/${libdir}/${tlib} )
END_LDSCRIPT
;;
esac
--
2.39.1
[gentoo-dev] [PATCH 1/7] sys-libs/glibc: Strip prefix from ld scripts for better cross-compiling
The toolchain expects to find the libc's files under its own sysroot. This
sysroot is automatically prepended to paths found in ld scripts, such as those
installed with glibc. We configure standalone prefix systems with a sysroot, so
these paths should not be prefixed. However, Gentoo Prefix has traditionally
left them prefixed and stopped the compiler from passing the sysroot to the
linker instead. It is better to strip the prefix and let the sysroot do its job,
as this makes cross-compiling much less awkward.
prefix-guest systems do not have a sysroot applied, as they use the host's libc,
but they would not install glibc anyway.
This change is not needed for musl, as it does not install any ld scripts.
Signed-off-by: James Le Cuirot
---
profiles/features/prefix/standalone/profile.bashrc | 9 +
sys-libs/glibc/glibc-2.36-r6.ebuild| 11 +++
sys-libs/glibc/glibc-.ebuild | 11 +++
3 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index fd95e43f7f30..3cdda77b9a88 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -1,5 +1,5 @@
# -*- mode: shell-script; -*-
-# Copyright 2018-2021 Gentoo Authors
+# Copyright 2018-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# RAP specific patches pending upstream:
@@ -24,10 +24,6 @@ if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE}
== configure ]]; the
# use sysroot of toolchain to get correct include and library at compile
time
EXTRA_ECONF="${EXTRA_ECONF} --with-sysroot=${EPREFIX}"
-
-ebegin "remove --sysroot call on ld for native toolchain"
-sed -i 's/--sysroot=%R//' gcc/gcc.c*
-eend $?
elif [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure
]]; then
ebegin "Use ${EPREFIX} as default sysroot"
sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
@@ -36,9 +32,6 @@ elif [[ ${CATEGORY}/${PN} == sys-devel/clang &&
${EBUILD_PHASE} == configure ]];
ebegin "Use dynamic linker from ${EPREFIX}"
sed -i -e "/LibDir.*Loader/s@return \"\/\"@return \"${EPREFIX%/}/\"@"
Linux.cpp
eend $?
-ebegin "Remove --sysroot call on ld for native toolchain"
-sed -i -e "$(grep -n -B1 sysroot= Gnu.cpp | sed -ne '{1s/-.*//;1p}'),+1 d"
Gnu.cpp
-eend $?
popd >/dev/null
elif [[ ${CATEGORY}/${PN} == sys-devel/binutils && ${EBUILD_PHASE} == prepare
]]; then
ebegin "Prefixifying native library path"
diff --git a/sys-libs/glibc/glibc-2.36-r6.ebuild
b/sys-libs/glibc/glibc-2.36-r6.ebuild
index be82be429c8f..e86bbd923123 100644
--- a/sys-libs/glibc/glibc-2.36-r6.ebuild
+++ b/sys-libs/glibc/glibc-2.36-r6.ebuild
@@ -1314,6 +1314,17 @@ glibc_do_src_install() {
mv "${ED}"/$(alt_usrlibdir)/libm-${upstream_pv}.a
"${ED}"/$(alt_usrlibdir)/${P}/libm-${upstream_pv}.a || die
fi
+ # We configure toolchains for standalone prefix systems with a sysroot,
+ # which is prepended to paths in ld scripts, so strip the prefix from
these.
+ # Before: GROUP ( /foo/lib64/libc.so.6 /foo/usr/lib64/libc_nonshared.a
AS_NEEDED ( /foo/lib64/ld-linux-x86-64.so.2 ) )
+ # After: GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a
AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
+ if [[ -n $(host_eprefix) ]] ; then
+ local file
+ grep -lZIF "ld script" "${ED}/$(alt_usrlibdir)"/lib*.{a,so}
2>/dev/null | while read -rd '' file ; do
+ sed -i "s|$(host_eprefix)/|/|g" "${file}" || die
+ done
+ fi
+
# We'll take care of the cache ourselves
rm -f "${ED}"/etc/ld.so.cache
diff --git a/sys-libs/glibc/glibc-.ebuild b/sys-libs/glibc/glibc-.ebuild
index 33d217dc1787..bf134512eb59 100644
--- a/sys-libs/glibc/glibc-.ebuild
+++ b/sys-libs/glibc/glibc-.ebuild
@@ -1314,6 +1314,17 @@ glibc_do_src_install() {
mv "${ED}"/$(alt_usrlibdir)/libm-${upstream_pv}.a
"${ED}"/$(alt_usrlibdir)/${P}/libm-${upstream_pv}.a || die
fi
+ # We configure toolchains for standalone prefix systems with a sysroot,
+ # which is prepended to paths in ld scripts, so strip the prefix from
these.
+ # Before: GROUP ( /foo/lib64/libc.so.6 /foo/usr/lib64/libc_nonshared.a
AS_NEEDED ( /foo/lib64/ld-linux-x86-64.so.2 ) )
+ # After: GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a
AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
+ if [[ -n $(host_eprefix) ]] ; then
+
[gentoo-dev] Allow prefixed systems to be cross-compiled
These changes relate to the news item I recently posted here. They've already had some feedback on GitHub, but they include eclass changes, and protocol says I must post them here too. I've included the wider package changes, as the eclass changes alone don't make sense out of context. In particular, I have not yet had any feedback on the python-utils-r1.eclass change. It's only a single line.
[gentoo-dev] [PATCH] kernel-2.eclass: Make xmakeopts an array for spaces in toolchain vars
Variables like CC can have spaces for additional arguments. This is
particularly useful for reliably setting the sysroot.
Signed-off-by: James Le Cuirot
---
eclass/kernel-2.eclass | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 873d4a204669..f7fcf15743f0 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kernel-2.eclass
@@ -756,13 +756,22 @@ env_setup_xmakeopts() {
# When cross-compiling, we need to set the ARCH/CROSS_COMPILE
# variables properly or bad things happen !
- xmakeopts="ARCH=${KARCH}"
+ xmakeopts=( ARCH="${KARCH}" )
if [[ ${CTARGET} != ${CHOST} ]] && ! cross_pre_c_headers; then
- xmakeopts="${xmakeopts} CROSS_COMPILE=${CTARGET}-"
+ xmakeopts+=( CROSS_COMPILE="${CTARGET}-" )
elif type -p ${CHOST}-ar >/dev/null; then
- xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
+ xmakeopts+=( CROSS_COMPILE="${CHOST}-" )
fi
- xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) OBJCOPY=$(tc-getOBJCOPY)
READELF=$(tc-getREADELF) STRIP=$(tc-getSTRIP)"
+ xmakeopts+=(
+ HOSTCC="$(tc-getBUILD_CC)"
+ CC="$(tc-getCC)"
+ LD="$(tc-getLD)"
+ AR="$(tc-getAR)"
+ NM="$(tc-getNM)"
+ OBJCOPY="$(tc-getOBJCOPY)"
+ READELF="$(tc-getREADELF)"
+ STRIP="$(tc-getSTRIP)"
+ )
export xmakeopts
}
@@ -850,7 +859,7 @@ install_headers() {
local ddir=$(kernel_header_destdir)
env_setup_xmakeopts
- emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/.. ${xmakeopts}
+ emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
"${xmakeopts[@]}"
# let other packages install some of these headers
rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
--
2.39.1
[gentoo-dev] NEWS: Breaking changes to the RAP Prefix toolchain
The context for this is a pull request I've been working on for a few weeks.
https://github.com/gentoo/gentoo/pull/28851
RAP prefix nobbled gcc/clang's sysroot when invoking the linker because glibc
installed its linker scripts with prefixed paths, such as /path/to/prefix/lib
rather than just /lib. Adjusting the linker scripts rather than the compiler
behaviour is more natural and makes cross-compiling far easier.
For the migration procedure, I did try a different approach of manually fixing
up the linker scripts, but if you do this first, the gcc build fails
immediately, and if you do this afterwards, the gcc build fails later. A
symlink is therefore needed to allow the sysroot to be applied, even when the
linker script paths are still prefixed.
Unfortunately, it's not possible to filter news items on USE flags or even
profile parents, so I've had to resort to explicitly listing all the prefix
profiles. Prefix is quite a niche feature, so I don't want to show this news
to everyone.
Title: Breaking changes to the RAP Prefix toolchain
Author: James Le Cuirot
Posted: 2023-01-20
Revision: 1
News-Item-Format: 2.0
Display-If-Profile: default/linux/amd64/17.0/no-multilib/prefix/*
Display-If-Profile: default/linux/amd64/17.1/no-multilib/prefix/*
Display-If-Profile: default/linux/amd64/23.0/no-multilib/prefix/*
Display-If-Profile: default/linux/amd64/23.0/split-usr/no-multilib/prefix/*
Display-If-Profile: default/linux/arm/17.0/armv7a/prefix/*
Display-If-Profile: default/linux/arm/23.0/armv7a/prefix/*
Display-If-Profile: default/linux/arm/23.0/split-usr/armv7a/prefix/*
Display-If-Profile: default/linux/arm64/17.0/prefix/*
Display-If-Profile: default/linux/arm64/23.0/prefix/*
Display-If-Profile: default/linux/arm64/23.0/split-usr/prefix/*
Display-If-Profile: default/linux/ppc64le/17.0/prefix/*
Display-If-Profile: default/linux/riscv/20.0/rv64gc/lp64d/prefix/*
Display-If-Profile: default/linux/riscv/23.0/rv64/lp64d/prefix/*
Display-If-Profile: default/linux/riscv/23.0/rv64/split-usr/lp64d/prefix/*
Display-If-Profile: default/linux/x86/17.0/prefix/*
Display-If-Profile: default/linux/x86/23.0/prefix/*
Display-If-Profile: default/linux/x86/23.0/split-usr/prefix/*
We are changing the way the toolchain operates on RAP Prefix systems in order to
reduce the number of hacks we need to apply and make cross-compiling easier.
If you using a non-RAP "Prefix Guest" or "Prefix Stack" variant (e.g. macOS)
then this does not apply.
If you are using a libc other than glibc (e.g. musl) then this *does* apply, but
your libc will *not* break, so you should not carry out the following procedure.
The only other package known to be affected is dev-libs/libbsd, which you can
simply update. If you find another package affected by this, then please file a
bug report.
WARNING! It is important that you carry out the following procedure, otherwise
your toolchain will break when you next update your compiler or glibc.
1. Run the following to create a temporary symlink:
EPREFIX=$(portageq envvar EPREFIX)
mkdir -p "${EPREFIX}${EPREFIX%/*}"
ln -sn "${EPREFIX}" "${EPREFIX}${EPREFIX}"
2. Update or rebuild all installed slots of sys-devel/gcc and sys-devel/clang
(if any). Feel free to remove any you no longer need.
3. Update or rebuild sys-libs/glibc.
4. Run the following to remove the symlink:
EPREFIX=$(portageq envvar EPREFIX)
rm "${EPREFIX}${EPREFIX}"
5. If dev-libs/libbsd is installed, then update it to 0.11.7-r2 or later.
If you are reading this having updated glibc first and you are no longer able to
build anything, then don't panic. Simply execute the line below and then carry
out the regular procedure above.
qlist sys-libs/glibc | xargs grep -lIF "GNU ld script" | xargs sed -i -r "s:
/(usr|lib): $(portageq envvar EPREFIX)/\1:g"
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Promote tc-env_build to a non-internal function
It's generally useful and already directly used by three packages. I
need to use it to fix cross-compiling of LLVM.
Signed-off-by: James Le Cuirot
---
eclass/toolchain-funcs.eclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 61a29d1b6ea6..bfcd6819ed0b 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -377,7 +377,6 @@ tc-export_build_env() {
# @FUNCTION: tc-env_build
# @USAGE: [command args]
-# @INTERNAL
# @DESCRIPTION:
# Setup the compile environment to the build tools and then execute the
# specified command. We use tc-getBUILD_XX here so that we work with
--
2.38.1
[gentoo-dev] Last rites: games-engines/residualvm
# James Le Cuirot (2022-12-14) # Merged into games-engines/scummvm a while back. No longer maintained # upstream. Removal in 30 days. games-engines/residualvm signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 3/3] dev-libs/apr-util: Don't prefix db_includedir with SYSROOT
The function will do it for you now, although with ESYSROOT rather than
SYSROOT, which was incorrect.
Signed-off-by: James Le Cuirot
---
dev-libs/apr-util/apr-util-1.6.1-r10.ebuild | 2 +-
dev-libs/apr-util/apr-util-1.6.1-r8.ebuild | 2 +-
dev-libs/apr-util/apr-util-1.6.1-r9.ebuild | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dev-libs/apr-util/apr-util-1.6.1-r10.ebuild
b/dev-libs/apr-util/apr-util-1.6.1-r10.ebuild
index 0e42903cdab1..198a64cbc507 100644
--- a/dev-libs/apr-util/apr-util-1.6.1-r10.ebuild
+++ b/dev-libs/apr-util/apr-util-1.6.1-r10.ebuild
@@ -96,7 +96,7 @@ src_configure() {
# We use $T for the libdir because otherwise it'd
simply be the normal
# system libdir. That's pointless as the compiler will
search it for
# us already. This makes cross-compiling and such
easier.
- --with-berkeley-db="${SYSROOT}$(db_includedir
2>/dev/null):${T}"
+ --with-berkeley-db="$(db_includedir 2>/dev/null):${T}"
)
else
myconf+=( --without-berkeley-db )
diff --git a/dev-libs/apr-util/apr-util-1.6.1-r8.ebuild
b/dev-libs/apr-util/apr-util-1.6.1-r8.ebuild
index 6209149b702b..b768137d1819 100644
--- a/dev-libs/apr-util/apr-util-1.6.1-r8.ebuild
+++ b/dev-libs/apr-util/apr-util-1.6.1-r8.ebuild
@@ -95,7 +95,7 @@ src_configure() {
# We use $T for the libdir because otherwise it'd
simply be the normal
# system libdir. That's pointless as the compiler will
search it for
# us already. This makes cross-compiling and such
easier.
- --with-berkeley-db="${SYSROOT}$(db_includedir
2>/dev/null):${T}"
+ --with-berkeley-db="$(db_includedir 2>/dev/null):${T}"
)
else
myconf+=( --without-berkeley-db )
diff --git a/dev-libs/apr-util/apr-util-1.6.1-r9.ebuild
b/dev-libs/apr-util/apr-util-1.6.1-r9.ebuild
index facb1b2e7b80..42ff0c6607ef 100644
--- a/dev-libs/apr-util/apr-util-1.6.1-r9.ebuild
+++ b/dev-libs/apr-util/apr-util-1.6.1-r9.ebuild
@@ -96,7 +96,7 @@ src_configure() {
# We use $T for the libdir because otherwise it'd
simply be the normal
# system libdir. That's pointless as the compiler will
search it for
# us already. This makes cross-compiling and such
easier.
- --with-berkeley-db="${SYSROOT}$(db_includedir
2>/dev/null):${T}"
+ --with-berkeley-db="$(db_includedir 2>/dev/null):${T}"
)
else
myconf+=( --without-berkeley-db )
--
2.38.1
[gentoo-dev] [PATCH 2/3] db-use.eclass: Use ESYSROOT rather than EPREFIX where appropriate
EPREFIX would be appropriate for values used at runtime.
db_findver and db_libname check for the presence of files or directories
at build time.
db_includedir returns a header directory, which would almost certainly
only be used at build time.
Signed-off-by: James Le Cuirot
---
eclass/db-use.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
index 3e5d6f63fa2e..99f31a17a738 100644
--- a/eclass/db-use.eclass
+++ b/eclass/db-use.eclass
@@ -52,7 +52,7 @@ db_findver() {
PKG="$(best_version $1)"
VER="$(ver_cut 1-2 "${PKG/*db-/}")"
- if [ -d "${EPREFIX}"/usr/include/db$(db_ver_to_slot "$VER") ]; then
+ if [ -d "${ESYSROOT}"/usr/include/db$(db_ver_to_slot "$VER") ]; then
#einfo "Found db version ${VER}" >&2
echo -n "$VER"
return 0
@@ -71,8 +71,8 @@ db_includedir() {
VER="$(db_findver sys-libs/db)" || return 1
VER="$(db_ver_to_slot "$VER")"
echo "include version ${VER}" >&2
- if [ -d "${EPREFIX}/usr/include/db${VER}" ]; then
- echo -n "${EPREFIX}/usr/include/db${VER}"
+ if [ -d "${ESYSROOT}/usr/include/db${VER}" ]; then
+ echo -n "${ESYSROOT}/usr/include/db${VER}"
return 0
else
eerror "sys-libs/db package requested, but headers not
found" >&2
@@ -83,8 +83,8 @@ db_includedir() {
for x in $@
do
if VER=$(db_findver "=sys-libs/db-${x}*") &&
- [ -d "${EPREFIX}/usr/include/db$(db_ver_to_slot
$VER)" ]; then
- echo -n
"${EPREFIX}/usr/include/db$(db_ver_to_slot $VER)"
+ [ -d "${ESYSROOT}/usr/include/db$(db_ver_to_slot
$VER)" ]; then
+ echo -n
"${ESYSROOT}/usr/include/db$(db_ver_to_slot $VER)"
return 0
fi
done
@@ -102,7 +102,7 @@ db_includedir() {
db_libname() {
if [ $# -eq 0 ]; then
VER="$(db_findver sys-libs/db)" || return 1
- if [ -e
"${EPREFIX}/usr/$(get_libdir)/libdb-${VER}$(get_libname)" ]; then
+ if [ -e
"${ESYSROOT}/usr/$(get_libdir)/libdb-${VER}$(get_libname)" ]; then
echo -n "db-${VER}"
return 0
else
@@ -114,7 +114,7 @@ db_libname() {
for x in $@
do
if VER=$(db_findver "=sys-libs/db-${x}*"); then
- if [ -e
"${EPREFIX}/usr/$(get_libdir)/libdb-${VER}$(get_libname)" ]; then
+ if [ -e
"${ESYSROOT}/usr/$(get_libdir)/libdb-${VER}$(get_libname)" ]; then
echo -n "db-${VER}"
return 0
fi
--
2.38.1
[gentoo-dev] [PATCH 1/3] db-use.eclass: Drop support for EAPI 5 and 6
The last consumers have been dropped from the gentoo repo.
Signed-off-by: James Le Cuirot
---
eclass/db-use.eclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
index 55e72286fda4..3e5d6f63fa2e 100644
--- a/eclass/db-use.eclass
+++ b/eclass/db-use.eclass
@@ -8,7 +8,7 @@
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Paul de Vrieze
-# @SUPPORTED_EAPIS: 5 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: This is a common location for functions that aid the use of
sys-libs/db
# @DESCRIPTION:
# This eclass is designed to provide helpful functions for depending on
@@ -16,7 +16,6 @@
# multilib is used for get_libname in all EAPI
case ${EAPI} in
- 5|6) inherit eapi7-ver ;& # fallthrough
7|8) inherit multilib ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.38.1
Re: [gentoo-dev] [PATCH 1/2] acct-group.eclass: Don't modify groups when EPREFIX is non-empty
On Fri, 2022-12-09 at 05:23 +0100, Michał Górny wrote:
> On Thu, 2022-12-08 at 21:28 +0000, James Le Cuirot wrote:
> > This was happening when running a prefix as root, which we don't really
> > support, but also when building a prefixed system under ROOT.
> >
> > Closes: https://bugs.gentoo.org/779181
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/acct-group.eclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 590a2f20ed8e..f55c9f4c9587 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -157,7 +157,7 @@ acct-group_src_install() {
> > acct-group_pkg_preinst() {
> > debug-print-function ${FUNCNAME} "${@}"
> >
> > - if [[ ${EUID} -ne 0 ]]; then
> > + if [[ ${EUID} -ne 0 || -n ${EPREFIX} ]]; then
> > einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
> > return
> > fi
>
> I dare say the message is not necessarily correct here but I suppose it
> doesn't matter that much.
Yeah, I thought that too, but not enough for such a corner case.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/2] acct-user.eclass: Don't modify users when EPREFIX is non-empty
This was happening when running a prefix as root, which we don't really
support, but also when building a prefixed system under ROOT.
Signed-off-by: James Le Cuirot
---
eclass/acct-user.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index b15599c5dd6f..a37e12121f83 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -181,7 +181,7 @@ acct-user_add_deps() {
eislocked() {
[[ $# -eq 1 ]] || die "usage: ${FUNCNAME} "
- if [[ ${EUID} -ne 0 ]]; then
+ if [[ ${EUID} -ne 0 || -n ${EPREFIX} ]]; then
einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
return 0
fi
@@ -332,7 +332,7 @@ acct-user_pkg_preinst() {
unset _ACCT_USER_ADDED
- if [[ ${EUID} -ne 0 ]]; then
+ if [[ ${EUID} -ne 0 || -n ${EPREFIX} ]]; then
einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
return
fi
@@ -405,7 +405,7 @@ acct-user_pkg_postinst() {
return
fi
- if [[ ${EUID} -ne 0 ]]; then
+ if [[ ${EUID} -ne 0 || -n ${EPREFIX} ]]; then
einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
return
fi
@@ -454,7 +454,7 @@ acct-user_pkg_prerm() {
return
fi
- if [[ ${EUID} -ne 0 ]]; then
+ if [[ ${EUID} -ne 0 || -n ${EPREFIX} ]]; then
einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
return
fi
--
2.38.1
[gentoo-dev] [PATCH 1/2] acct-group.eclass: Don't modify groups when EPREFIX is non-empty
This was happening when running a prefix as root, which we don't really
support, but also when building a prefixed system under ROOT.
Closes: https://bugs.gentoo.org/779181
Signed-off-by: James Le Cuirot
---
eclass/acct-group.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 590a2f20ed8e..f55c9f4c9587 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -157,7 +157,7 @@ acct-group_src_install() {
acct-group_pkg_preinst() {
debug-print-function ${FUNCNAME} "${@}"
- if [[ ${EUID} -ne 0 ]]; then
+ if [[ ${EUID} -ne 0 || -n ${EPREFIX} ]]; then
einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
return
fi
--
2.38.1
[gentoo-dev] acct-*.eclass: Don't modify users/groups when EPREFIX is non-empty
This was happening when running a prefix as root, which we don't really support, but also when building a prefixed system under ROOT. Bug #779181 suggested a variable to optionally permit this, but no one cares enough to make it work at present. I just want to fix the failures when building under ROOT.
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On Tue, 2022-12-06 at 18:54 -0500, Mike Gilbert wrote:
> On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot wrote:
> >
> > Groups are largely irrelevant for prefix, but we still don't want the
> > build to break.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/acct-group.eclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 590a2f20ed8e..ada5fe386693 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -176,7 +176,7 @@ acct-group_pkg_preinst() {
> > fi
> >
> > if [[ -n ${ROOT} ]]; then
>
> You should probably change this to [[ -n ${EROOT} ]]. Same goes for
> acct-user.eclass.
>
> Also see bug 779181; I'm not sure updating ${EROOT}/etc/group and
> ${EROOT}/etc/passwd makes any sense at all.
Hmm. On closer inspection, and after seeing that bug, I realise I have made
some bad assumptions.
I glanced at my old prefix and saw a bunch of additional users and groups in
there, so I figured the tools must have automatically operated on
${EPREFIX}/etc. In fact, user.eclass skipped the operation if you were root,
and these files were merely copies from /etc. I tried groupadd from a prefix,
and it defaulted to /etc.
The new eclasses also skip the operation if you are root. As that bug report
says, running a prefixed system as root is probably unsupported. I was doing
this as root into a ROOTed prefix though, which is slightly different. Should
we also skip the operation if EPREFIX non-empty? I'll think about it.
Thanks for pointing this out.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 4/4] user.eclass: Fix for when building in a rooted prefix (EROOT)
Users are largely irrelevant for prefix, but we still don't want the
build to break.
I left the home and shell related bits alone, as it's less clear whether
these should be prefixed or not. Obviously /dev/null should not be. It's
slightly academic anyway, as nothing in the main repo uses this eclass
any more.
Signed-off-by: James Le Cuirot
---
eclass/user.eclass | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/eclass/user.eclass b/eclass/user.eclass
index 02e1074fe4d6..9daa1f807e07 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -119,7 +119,7 @@ enewuser() {
local opts=()
# handle for ROOT != /
- [[ -n ${ROOT} ]] && opts+=( --prefix "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts+=( --prefix "${EROOT}" )
# handle uid
local euid=${1}; shift
@@ -307,7 +307,7 @@ enewgroup() {
# handle different ROOT
local opts
- [[ -n ${ROOT} ]] && opts=( --prefix "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts=( --prefix "${EROOT}" )
# handle extra
if [[ $# -gt 0 ]] ; then
@@ -383,7 +383,7 @@ esethome() {
# Handle different ROOT
local opts
- [[ -n ${ROOT} ]] && opts=( --prefix "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts=( --prefix "${EROOT}" )
# handle homedir
local ehome=${1}; shift
@@ -469,7 +469,7 @@ esetshell() {
# Handle different ROOT
local opts
- [[ -n ${ROOT} ]] && opts=( --prefix "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts=( --prefix "${EROOT}" )
# handle shell
local eshell=${1}; shift
@@ -546,7 +546,7 @@ esetcomment() {
# Handle different ROOT
local opts
- [[ -n ${ROOT} ]] && opts=( --prefix "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts=( --prefix "${EROOT}" )
# handle comment
local ecomment=${1}; shift
@@ -647,7 +647,7 @@ esetgroups() {
elog " - Groups: ${egroups}"
# Handle different ROOT
- [[ -n ${ROOT} ]] && opts+=( --prefix "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts+=( --prefix "${EROOT}" )
# update the group
case ${CHOST} in
--
2.38.1
[gentoo-dev] [PATCH 3/4] user-info.eclass: Fix for when building in a rooted prefix (EROOT)
Users are largely irrelevant for prefix, but we still don't want the
build to break.
Signed-off-by: James Le Cuirot
---
eclass/user-info.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass
index 5550e4f08eeb..1339e36634a8 100644
--- a/eclass/user-info.eclass
+++ b/eclass/user-info.eclass
@@ -48,7 +48,7 @@ egetent() {
fi
# Handle different ROOT
- [[ -n ${ROOT} ]] && opts+=( -R "${ROOT}" )
+ [[ -n ${ROOT} ]] && opts+=( -R "${EROOT}" )
pw show ${db} ${opts} "${key}" -q
;;
@@ -64,9 +64,9 @@ egetent() {
getent "${db}" "${key}"
else
if [[ ${key} =~ ^[[:digit:]]+$ ]]; then
- grep -E "^([^:]*:){2}${key}" "${ROOT}/etc/${db}"
+ grep -E "^([^:]*:){2}${key}"
"${EROOT}/etc/${db}"
else
- grep "^${key}:" "${ROOT}/etc/${db}"
+ grep "^${key}:" "${EROOT}/etc/${db}"
fi
fi
;;
@@ -167,7 +167,7 @@ egetgroups() {
local egroups_arr
if [[ -n "${ROOT}" ]]; then
local pgroup=$(egetent passwd "$1" | cut -d: -f1)
- local sgroups=( $(grep -E ":([^:]*,)?$1(,[^:]*)?$"
"${ROOT}/etc/group" | cut -d: -f1) )
+ local sgroups=( $(grep -E ":([^:]*,)?$1(,[^:]*)?$"
"${EROOT}/etc/group" | cut -d: -f1) )
# Remove primary group from list
sgroups=${sgroups#${pgroup}}
--
2.38.1
[gentoo-dev] [PATCH 2/4] acct-user.eclass: Fix for when building in a rooted prefix (EROOT)
Users are largely irrelevant for prefix, but we still don't want the
build to break.
Signed-off-by: James Le Cuirot
---
eclass/acct-user.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index b15599c5dd6f..538cc6ae8ec3 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -200,7 +200,7 @@ eislocked() {
# but we also expire the account which is more clear
local shadow
if [[ -n "${ROOT}" ]]; then
- shadow=$(grep "^$1:" "${ROOT}/etc/shadow")
+ shadow=$(grep "^$1:" "${EROOT}/etc/shadow")
else
shadow=$(getent shadow "$1")
fi
@@ -362,7 +362,7 @@ acct-user_pkg_preinst() {
fi
if [[ -n ${ROOT} ]]; then
- opts+=( --prefix "${ROOT}" )
+ opts+=( --prefix "${EROOT}" )
fi
elog "Adding user ${ACCT_USER_NAME}"
@@ -431,7 +431,7 @@ acct-user_pkg_postinst() {
fi
if [[ -n ${ROOT} ]]; then
- opts+=( --prefix "${ROOT}" )
+ opts+=( --prefix "${EROOT}" )
fi
elog "Updating user ${ACCT_USER_NAME}"
@@ -483,7 +483,7 @@ acct-user_pkg_prerm() {
)
if [[ -n ${ROOT} ]]; then
- opts+=( --prefix "${ROOT}" )
+ opts+=( --prefix "${EROOT}" )
fi
elog "Locking user ${ACCT_USER_NAME}"
--
2.38.1
[gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
Groups are largely irrelevant for prefix, but we still don't want the
build to break.
Signed-off-by: James Le Cuirot
---
eclass/acct-group.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 590a2f20ed8e..ada5fe386693 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -176,7 +176,7 @@ acct-group_pkg_preinst() {
fi
if [[ -n ${ROOT} ]]; then
- opts+=( --prefix "${ROOT}" )
+ opts+=( --prefix "${EROOT}" )
fi
elog "Adding group ${ACCT_GROUP_NAME}"
--
2.38.1
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Set CHOST within econf_build to fix config.site
On Tue, 2022-12-06 at 10:12 +, Sam James wrote:
>
> > On 6 Dec 2022, at 09:03, James Le Cuirot wrote:
> >
> > We were setting CBUILD within econf_build but not CHOST. crossdev's
> > /usr/share/config.site relies on both of these to decide whether to load
> > configure overrides needed when cross-compiling. Using the wrong
> > overrides leads to packages such as Python failing.
> >
> > Doing this also avoids the need to duplicate the --build and --host
> > configure arguments.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/toolchain-funcs.eclass | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> > index a184887ad3b9..61a29d1b6ea6 100644
> > --- a/eclass/toolchain-funcs.eclass
> > +++ b/eclass/toolchain-funcs.eclass
> > @@ -442,7 +442,8 @@ tc-env_build() {
> > # @CODE
> > econf_build() {
> > local CBUILD=${CBUILD:-${CHOST}}
> > - tc-env_build econf --build=${CBUILD} --host=${CBUILD} "$@"
> > + econf_env() { CHOST=${CBUILD} econf "$@"; }
> > + tc-env_build econf_env "$@"
> > }
> >
> > # @FUNCTION: tc-ld-is-gold
> > --
>
> Lgtm provided you've tested it in the relevant envs (which I'm sure you have).
>
> Curious how this didn't come up as a problem before, but it
> seems fine!
econf_build is not widely used, and you only added it to Python in June. It's
been used in other packages for much longer, but Python explicitly checks that
the size of a long is what it expects. I didn't see it with m68k because we
don't have any overrides for that. You also might not see it going from amd64
to arm64 either with them both being 64-bit. The lack of m68k overrides makes
me wonder if some of these are even needed any more. ac_cv_sizeof_* can
seemingly be determined when cross-compiling now.
Since we've already had some reports of success, I'm merging this now.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Set CHOST within econf_build to fix config.site
We were setting CBUILD within econf_build but not CHOST. crossdev's
/usr/share/config.site relies on both of these to decide whether to load
configure overrides needed when cross-compiling. Using the wrong
overrides leads to packages such as Python failing.
Doing this also avoids the need to duplicate the --build and --host
configure arguments.
Signed-off-by: James Le Cuirot
---
eclass/toolchain-funcs.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index a184887ad3b9..61a29d1b6ea6 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -442,7 +442,8 @@ tc-env_build() {
# @CODE
econf_build() {
local CBUILD=${CBUILD:-${CHOST}}
- tc-env_build econf --build=${CBUILD} --host=${CBUILD} "$@"
+ econf_env() { CHOST=${CBUILD} econf "$@"; }
+ tc-env_build econf_env "$@"
}
# @FUNCTION: tc-ld-is-gold
--
2.38.1
Re: [gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make
On Tue, 2022-11-29 at 17:31 -0500, Mike Gilbert wrote:
> On Tue, Nov 29, 2022 at 5:14 PM James Le Cuirot wrote:
> >
> > On Tue, 2022-11-29 at 13:55 -0500, Mike Gilbert wrote:
> > > This avoids some unnecessary Makefile logic and gives a nice speed up.
> > >
> > > Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
> > > AMD Phenom II. After, it takes 3 to 4 seconds.
> > >
> > > Signed-off-by: Mike Gilbert
> > > ---
> > > eclass/linux-info.eclass | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> > > index fc125b0d751..3e64cb9457a 100644
> > > --- a/eclass/linux-info.eclass
> > > +++ b/eclass/linux-info.eclass
> > > @@ -238,7 +238,9 @@ getfilevar() {
> > > # Pass dot-config=0 to avoid the config check in kernels
> > > prior to 5.4.
> > > [[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
> > > echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
> > > - nonfatal emake -C "${basedname}"
> > > --no-print-directory M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s
> > > -f - 2>/dev/null
> > > + nonfatal emake -C "${basedname}"
> > > --no-print-directory M="${T}" \
> > > + dot-config=0 need-config= need-compiler= \
> > > + ${BUILD_FIXES} -s -f - 2>/dev/null
> > >
> > > ARCH=${myARCH}
> > > fi
> >
> > I'm confused. Breaking up the line makes it faster?
>
> The change is stated in the email subject.
>
Heh, sorry. I need more sleep.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make
On Tue, 2022-11-29 at 13:55 -0500, Mike Gilbert wrote:
> This avoids some unnecessary Makefile logic and gives a nice speed up.
>
> Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
> AMD Phenom II. After, it takes 3 to 4 seconds.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/linux-info.eclass | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> index fc125b0d751..3e64cb9457a 100644
> --- a/eclass/linux-info.eclass
> +++ b/eclass/linux-info.eclass
> @@ -238,7 +238,9 @@ getfilevar() {
> # Pass dot-config=0 to avoid the config check in kernels prior
> to 5.4.
> [[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
> echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
> - nonfatal emake -C "${basedname}" --no-print-directory
> M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
> + nonfatal emake -C "${basedname}" --no-print-directory
> M="${T}" \
> + dot-config=0 need-config= need-compiler= \
> + ${BUILD_FIXES} -s -f - 2>/dev/null
>
> ARCH=${myARCH}
> fi
I'm confused. Breaking up the line makes it faster?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] toolchain.eclass: the configure script shebang with BROOT.
On Wed, 2022-06-01 at 23:34 +0800, hero...@gentoo.org wrote:
> From: Benda Xu
>
> It executes on CBUILD environment.
> ---
> eclass/toolchain.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 488648a82ab5..33306d3d92b1 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1655,7 +1655,7 @@ toolchain_src_compile() {
> # use of bash. Newer ones will auto-detect, but this is not harmful.
> # This needs to be set for compile as well, as it's used in libtool
> # generation, which will break install otherwise (at least in 3.3.6):
> bug #664486
> - CONFIG_SHELL="${EPREFIX}/bin/bash" \
> + CONFIG_SHELL="${BROOT}/bin/bash" \
> gcc_do_make ${GCC_MAKE_TARGET}
> }
Ack.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev-announce] [gentoo-dev] Last Rites: app-pda/gtkpod
On 24 April 2022 23:48:34 BST, Matt Turner wrote: >On Sun, Apr 24, 2022 at 3:14 PM James Le Cuirot wrote: >> >> On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote: >> > # Matt Turner (2022-03-27) >> > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at >> > # least 6 years. >> > # Removal on 2022-05-02 >> > app-pda/gtkpod >> >> Last rites has been cancelled. I'm taking over as maintainer. > >Okay, but are you doing the thing I asked? > >> If you can break the dependence on anjuta (which I didn't >> investigate), I'd have no problem keeping it. Would be nice to have an >> actual maintainer as well. > >No, you didn't: > >https://qa-reports.gentoo.org/output/gentoo-ci/d347eab546/output.html#app-pda/gtkpod > >:( Sorry, it was last thing at night and I hadn't noticed the keyword situation. I think Anjuta is a key dependency and can't be dropped. I'll take it if necessary. Maybe I'll strip it down. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev-announce] [gentoo-dev] Last Rites: app-pda/gtkpod
On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote: > # Matt Turner (2022-03-27) > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at > # least 6 years. > # Removal on 2022-05-02 > app-pda/gtkpod Last rites has been cancelled. I'm taking over as maintainer. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last Rites: app-pda/gtkpod
On Sun, 2022-04-24 at 13:29 -0700, Matt Turner wrote: > On Sun, Apr 3, 2022 at 1:56 PM Matt Turner wrote: > > > > On Sun, Apr 3, 2022 at 1:53 AM James Le Cuirot wrote: > > > > > > On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote: > > > > # Matt Turner (2022-03-27) > > > > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at > > > > # least 6 years. > > > > # Removal on 2022-05-02 > > > > app-pda/gtkpod > > > > > > I do still use this on rare occasions. It's not my favourite program but > > > there > > > are no good alternatives, short of using Rhythmbox, which does more than I > > > want. I'm not aware that it's actually broken, aside from a couple of > > > minor > > > warts in the package. Does it have to go? > > > > No, if you want to keep it -- feel free. I just saw it because it's > > the only reverse dependency of dev-util/anjuta which looks pretty dead > > itself, and then I saw how much more dead gtkpod looks. > > > > If you can break the dependence on anjuta (which I didn't > > investigate), I'd have no problem keeping it. Would be nice to have an > > actual maintainer as well. > > > Removal date is approaching. Are you planning to take this? Sorry, I kept putting this off. Yeah, I'll take it... for now. :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] Add EAPI=8 support
On Sun, 2022-04-10 at 21:22 +0200, Conrad Kostecki wrote:
> Signed-off-by: Conrad Kostecki
> ---
> eclass/cdrom.eclass | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> index bae3888c6c5..81539e8560c 100644
> --- a/eclass/cdrom.eclass
> +++ b/eclass/cdrom.eclass
> @@ -1,10 +1,10 @@
> -# Copyright 1999-2021 Gentoo Authors
> +# Copyright 1999-2022 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: cdrom.eclass
> # @MAINTAINER:
> # ga...@gentoo.org
> -# @SUPPORTED_EAPIS: 6 7
> +# @SUPPORTED_EAPIS: 6 7 8
> # @BLURB: Functions for CD-ROM handling
> # @DESCRIPTION:
> # Acquire CD(s) for those lovely CD-based emerges. Yes, this violates
> @@ -16,7 +16,7 @@
> # The functions are generally called in src_unpack.
>
> case ${EAPI:-0} in
> - [67]) ;;
> + 6|7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
That's fine, the commit message aside. There's nothing particularly API-
specific about this eclass.
On a sidenote, if all the consumers get bumped to EAPI 8 then we can revert
1e09cba657ccb2b8, which fixed the eclass for Bash 4.2 and 4.3, but made it a
tiny bit more complex. EAPI 8 requires Bash 5.0.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Last Rites: app-pda/gtkpod
On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote: > # Matt Turner (2022-03-27) > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at > # least 6 years. > # Removal on 2022-05-02 > app-pda/gtkpod I do still use this on rare occasions. It's not my favourite program but there are no good alternatives, short of using Rhythmbox, which does more than I want. I'm not aware that it's actually broken, aside from a couple of minor warts in the package. Does it have to go? signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] The build system (and install layout) of Portage
On Thu, 2022-03-17 at 18:22 +0100, Michał Górny wrote: > An alternative is to go back to using (at least partially) Makefiles or > Meson. However, that would have the important drawback that we'd lose > the ability to install Portage as a regular Python package (e.g. inside > a virtualenv). What is the use case for doing that? I thought maybe testing, but then you can run Portage and its unit tests in-place without installing it at all right now. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Package up for grabs: games-engines/odamex
On Fri, 2022-02-18 at 15:21 +0900, William Breathitt Gray wrote: > I'm trying to reduce some of my workload to avoid neglecting my other > projects. games-engines/odamex needs a version bump (Bug 833588) and a > minor fix for compilation against musl (Bug 831788). Upstream has been > pretty responsive and helpful in the past so it should be a nice > experience whenever you push patches for inclusion in the following > Odamex releases. Thanks for your hard work on this one, William. As you will have seen, I did look into unbundling for the version bump, but it wasn't pretty. We'll absorb this into the games team, assuming no one else wants it. Regards, Chewi signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] sgml-catalog-r1.eclass: Remove obsolete environment files
These files are only regenerated when gensgmlenv is present, but this
tool was part of sgmltools-lite, which was last-rited over a year ago.
The presence of 93sgmltools-lite can break tools such as
asciidoc. When SGML_CATALOG_FILES is defined, it automatically passes
the --catalogs option to xmllint, which uses the obsolete variable
over the updated catalogs listed in /etc/sgml/catalog.
Signed-off-by: James Le Cuirot
---
eclass/sgml-catalog-r1.eclass | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/eclass/sgml-catalog-r1.eclass b/eclass/sgml-catalog-r1.eclass
index 1e1f17815ac4..9f8bb13d6095 100644
--- a/eclass/sgml-catalog-r1.eclass
+++ b/eclass/sgml-catalog-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 2019 Gentoo Authors
+# Copyright 2019-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: sgml-catalog-r1.eclass
@@ -9,9 +9,8 @@
# @SUPPORTED_EAPIS: 7
# @BLURB: Functions for installing SGML catalogs
# @DESCRIPTION:
-# This eclass regenerates /etc/sgml/catalog, /etc/sgml.{,c}env
-# and /etc/env.d/93sgmltools-lite as necessary for the DocBook tooling.
-# This is done via exported pkg_postinst and pkg_postrm phases.
+# This eclass regenerates /etc/sgml/catalog as necessary for the DocBook
+# tooling. This is done via exported pkg_postinst and pkg_postrm phases.
case ${EAPI:-0} in
7) ;;
@@ -50,16 +49,9 @@ sgml-catalog-r1_update_catalog() {
# @FUNCTION: sgml-catalog-r1_update_env
# @DESCRIPTION:
-# Regenerate environment variables and copy them to env.d.
+# Remove obsolete environment files. They can break tools such as asciidoc.
sgml-catalog-r1_update_env() {
- # gensgmlenv doesn't support overriding root
- if [[ -z ${ROOT} && -x "${EPREFIX}/usr/bin/gensgmlenv" ]]; then
- ebegin "Regenerating SGML environment variables"
- gensgmlenv &&
- grep -v export "${EPREFIX}/etc/sgml/sgml.env" >
"${T}"/93sgmltools-lite &&
- mv "${T}"/93sgmltools-lite
"${EPREFIX}/etc/env.d/93sgmltools-lite"
- eend "${?}"
- fi
+ rm -f "${EROOT}"/etc/env.d/93sgmltools-lite
"${EROOT}"/etc/sgml/sgml.{,c}env
}
sgml-catalog-r1_pkg_postinst() {
--
2.34.1
Re: [gentoo-dev] [PATCH] profiles/default/linux: set gl_cv_type_time_t_bits_macro=no
On Fri, 2021-12-17 at 09:41 -0500, Mike Gilbert wrote:
> This is intended to prevent packages from automatically switching to
> 64-bit time_t on 32-bit ABIs. Making this switch in an uncontrolled
> manner will lead to inconsistent library ABIs that fail at runtime.
>
> At a later time, we will introduce new profiles to enable 64-bit time_t
> distro-wide.
>
> https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
>
> Bug: https://bugs.gentoo.org/828001
> Signed-off-by: Mike Gilbert
> ---
> profiles/default/linux/make.defaults | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/profiles/default/linux/make.defaults
> b/profiles/default/linux/make.defaults
> index 6ae7cf297cf..53ace7e229c 100644
> --- a/profiles/default/linux/make.defaults
> +++ b/profiles/default/linux/make.defaults
> @@ -53,3 +53,7 @@ VIDEO_CARDS="dummy fbdev v4l"
> # Note that adding LDFLAGS="-Wl,-O1 ${LDFLAGS}" breaks dev-util/boost-build
> # because of whitespace.
> LDFLAGS="-Wl,-O1 -Wl,--as-needed"
> +
> +# Mike Gilbert (2021-12-17)
> +# Prevent automagic use of 64-bit time_t.
> +gl_cv_type_time_t_bits_macro="no"
What will we do about other build systems? I worry they won't have a
consistent approach for all projects.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
On Thu, 2021-11-25 at 18:01 +0100, Piotr Karbowski wrote: > > https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643 > > Would you see something like this on more ebuilds, postgres, mysql, > elasticsearch, or have proper FEATURE flag for it instead? I don't think there's any need for this with PostgreSQL. The major versions are slotted, similar to MariaDB, but the data itself is also installed into versioned locations. Migrating usually involves copying the data to the new location. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2021 retrospective
On Fri, 2021-11-19 at 23:32 +0100, Andreas K. Huettel wrote: > in the spirit of our "2020 in retrospect & happy new year 2021!" front page > article, > > https://www.gentoo.org/news/2021/01/15/new-year.html > > which was rather well received, I'd already like to start collecting news > from 2021! > > Suggestions, text snippets, illustrations welcome- either as a reply here > on-list, or directly to me. m68k obviously. But you knew that already. ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-puzzle/gnudoku
# Alexey Sokolov (2021-08-30) # Homepage dead, uses gtk2, fails to build, https://bugs.gentoo.org/711344 games-puzzle/gnudoku signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sun, 28 Mar 2021 19:46:32 -0400 Joshua Kinard wrote: > I've kinda come to this conclusion myself. I could probably host an > extracted, micro-initramfs on my NFS server that would be loaded by the > kernel to jump to $REAL_ROOT. Not *too* much of an issue on the Octane, > because I can store the kernel command line args in a PROM variable so that > all I have to do is type "$foo" at the PROM prompt to load something. But, > SGI did their best to be inconsistent, and IP27 systems cannot permanently > save variables to NVRAM. Once you power cycle, all user-defined PROM vars > are lost. And Linux's NFS Root command args are somewhat complicated from > what I remember. Upshot is I boot the IP27 over serial console, so I can > just save bootp() args in a text file on my desktop and paste it into the > console for those instances. Have you seen CONFIG_CMDLINE? It lets you bake command line args into the kernel image itself. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpjPj3Fv0z6w.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sat, 27 Mar 2021 18:40:52 -0400 Joshua Kinard wrote: > On 3/27/2021 18:16, James Le Cuirot wrote: > > On Sat, 27 Mar 2021 17:43:34 -0400 > > Joshua Kinard wrote: > > > >> I kinda wish the Linux kernel had an ability to partially boot, init the > >> networking subsystem, then fetch an initramfs image over TFTP like it can > >> do > >> with NFS Root. That would solve the problem on my MIPS system(s) (and make > >> install netboots better). I've dug around, but this does not seem to be a > >> capability currently in the kernel, unless I have over looked something. > >> > >> Otherwise in the future, I may just have to setup an initramfs into an NFS > >> Root and teach the SGI's to somehow deal with it. Which all still seems > >> unnecessarily complicated because some other distro thinks it knows what's > >> best for everyone else (but I digress...). > > > > NBD may be a slightly simpler alternative and a bit more like an > > initramfs. nbdkit can do all sorts of weird things. I thought it might > > have a plugin for cpio archives, allowing you to use a regular > > initramfs generated by Dracut or similar directly. It doesn't appear to > > but plugins are quite easy to write. Alternatively you could just > > extract the initramfs and use nbdkit-linuxdisk-plugin. > > Can NBD be used like I described? Never played with it before. The MIPS > machine has functioning local disk drives, and currently, it boots fine by > just pulling a kernel off my TFTP server and booting from the local drive, > no initramfs needed because I compiled everything into it. If we ever force > sep-usr to end, then I'll need a way to teach it to mount /usr before > dropping into /bin/init (and nothing else). Apologies, I went to experiment with this idea but I'd forgotten that booting over NBD is not a built-in kernel feature and requires... an initramfs. NFS looks like the only option with this general approach. Rich is right though, the initramfs can be tiny. Dracut images are heavy because they are very flexible and pack a lot of features but none of that is required. The kexec idea would be a nice bonus for you, if it works. Limiting what kernel features you can enable must be frustrating. It's also worth bearing in mind that you could just generate an image with Dracut and extract it to a disk partition. That may seem a little pointless if you're not using something like LVM or encryption but I don't see the point in separate /usr either. ;) I'm guessing you don't want to change your partition layout at this point though. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpAb6gauIo0N.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sat, 27 Mar 2021 17:43:34 -0400 Joshua Kinard wrote: > I kinda wish the Linux kernel had an ability to partially boot, init the > networking subsystem, then fetch an initramfs image over TFTP like it can do > with NFS Root. That would solve the problem on my MIPS system(s) (and make > install netboots better). I've dug around, but this does not seem to be a > capability currently in the kernel, unless I have over looked something. > > Otherwise in the future, I may just have to setup an initramfs into an NFS > Root and teach the SGI's to somehow deal with it. Which all still seems > unnecessarily complicated because some other distro thinks it knows what's > best for everyone else (but I digress...). NBD may be a slightly simpler alternative and a bit more like an initramfs. nbdkit can do all sorts of weird things. I thought it might have a plugin for cpio archives, allowing you to use a regular initramfs generated by Dracut or similar directly. It doesn't appear to but plugins are quite easy to write. Alternatively you could just extract the initramfs and use nbdkit-linuxdisk-plugin. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpGX8oMTiAmr.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sun, 21 Mar 2021 05:18:52 +0100 Ulrich Mueller wrote: > >>>>> On Sat, 20 Mar 2021, William Hubbs wrote: > > > /etc/localtime should definitely be a symlink to the proper file in > > /usr/share/zoneinfo. > > > This works fine if /usr is on a separate partition *and* you are using > > an initramfs. The only time it doesn't work is if /usr is separate > > without using an initramfs. > > > Council decided years ago that we don't support separate /usr without > > an initramfs, but we haven't completed that transition yet. > > Which doesn't imply that we deliberately break things. How about making emerge --config dynamic, copying if it's on a different partition and symlinking if it's not? You can't accurately determine the use of an initramfs but at least this is closer to what we want. -- James Le Cuirot (chewi) Gentoo Linux Developer pgppd9SmOxjcX.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig
On Sun, 21 Feb 2021 15:54:39 +0200 Joonas Niilola wrote: > Hey, > > here are some packages up-for-grabs due to retirement of their maintainers. > b = bugs open, v = version bump available. > > app-arch/innoextract I'll take this. > net-irc/emech (b) > net-misc/tigervnc (b) > x11-misc/urxvtconfig (b) -- James Le Cuirot (chewi) Gentoo Linux Developer pgpCz9mh0ZV9G.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, 08 Feb 2021 12:19:13 +0100 Michał Górny wrote: > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. I do know that there is ongoing work to get Rust going on m68k but it's very slow and I'm not entirely confident they'll get there. At least I don't have this package on my m68k system! -- James Le Cuirot (chewi) Gentoo Linux Developer pgpEXub3MDL7c.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] eclass/lua-utils.eclass: remove EPREFIX from exported module paths
On Mon, 11 Jan 2021 11:01:33 -0600
William Hubbs wrote:
> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs
> ---
> eclass/lua-utils.eclass | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..9fe4d22e93f 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,9 @@ _lua_get_library_file() {
> die "Invalid implementation: ${impl}"
> ;;
> esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> +
> debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
> echo "${libdir}/${libname}"
> }
> @@ -274,6 +275,7 @@ _lua_export() {
> local val
>
> val=$($(tc-getPKG_CONFIG) --variable
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>
> export LUA_CMOD_DIR=${val}
> debug-print "${FUNCNAME}: LUA_CMOD_DIR =
> ${LUA_CMOD_DIR}"
> @@ -282,6 +284,7 @@ _lua_export() {
> local val
>
> val=$($(tc-getPKG_CONFIG) --variable includedir
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>
> export LUA_INCLUDE_DIR=${val}
> debug-print "${FUNCNAME}: LUA_INCLUDE_DIR =
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +301,7 @@ _lua_export() {
> local val
>
> val=$($(tc-getPKG_CONFIG) --variable
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>
> export LUA_LMOD_DIR=${val}
> debug-print "${FUNCNAME}: LUA_LMOD_DIR =
> ${LUA_LMOD_DIR}"
> @@ -364,11 +368,14 @@ lua_get_CFLAGS() {
> # @USAGE: []
> # @DESCRIPTION:
> # Obtain and print the name of the directory into which compiled Lua
> -# modules are installed, for the given implementation. If no implementation
> +# modules are installed for the given implementation. If no implementation
> # is provided, ${ELUA} will be used.
> #
> -# Please note that this function requires Lua and pkg-config installed,
> -# and therefore proper build-time dependencies need be added to the ebuild.
> +# Please note that this function requires Lua and pkg-config to be installed,
> +# and therefore proper build-time dependencies need to be added to the
> ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
> lua_get_cmod_dir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> @@ -385,6 +392,9 @@ lua_get_cmod_dir() {
> #
> # Please note that this function requires Lua and pkg-config installed,
> # and therefore proper build-time dependencies need be added to the ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
> lua_get_include_dir() {
> debug-print-function ${FUNCNAME} "${@}"
>
> @@ -412,11 +422,14 @@ lua_get_LIBS() {
> # @USAGE: []
> # @DESCRIPTION:
> # Obtain and print the name of the directory into which native-Lua
> -# modules are installed, for the given implementation. If no implementation
> +# modules are installed for the given implementation. If no implementation
> # is provided, ${ELUA} will be used.
> #
> # Please note that this function requires Lua and pkg-config installed,
> # and therefore proper build-time dependencies need be added to the ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
> lua_get_lmod_dir() {
> debug-print-function ${FUNCNAME} "${@}"
>
That's better, thanks. I would go a step further though and add a note
to lua_get_shared_lib() to say that this *does* include the SYSROOT and
prefix. It is slightly odd that this differs from lua_get_include_dir()
but I cannot find any examples where lua_get_shared_lib() is used in an
install phase.
Can you confirm that following this, you will go around and correct all
the ebuilds that use lua_get_include_dir() ? I count around 21 of them.
As I said, ${ESYSROOT} should be prepended when it is used in a build
phase. luaexpat is a good example of it being used in both a build and
an install phase.
Note that all of this is still slightly broken by the difference
between dev-util/pkgconfig and dev-util/pkgconf but I'll resolve that
as soon as I can. Most users, including most prefix users, won't notice.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpMZXQy_kycK.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
On Fri, 8 Jan 2021 14:26:32 +0200 Joonas Niilola wrote: > dev-libs/libgcrypt-compat > dev-libs/libpcre-debian These are maintained by me and I'd like to keep them. They can be pulled in by running the esteam tool in steam-overlay for games that need them. They could potentially be used for other old or Debian-oriented binary packages too. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp25epsm8vEo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths
On Thu, 7 Jan 2021 17:13:09 -0600
William Hubbs wrote:
> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs
> ---
> eclass/lua-utils.eclass | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..1e552da0848 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,10 @@ _lua_get_library_file() {
> die "Invalid implementation: ${impl}"
> ;;
> esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
> +
> debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
> echo "${libdir}/${libname}"
> }
> @@ -274,6 +276,7 @@ _lua_export() {
> local val
>
> val=$($(tc-getPKG_CONFIG) --variable
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>
> export LUA_CMOD_DIR=${val}
> debug-print "${FUNCNAME}: LUA_CMOD_DIR =
> ${LUA_CMOD_DIR}"
> @@ -282,6 +285,7 @@ _lua_export() {
> local val
>
> val=$($(tc-getPKG_CONFIG) --variable includedir
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>
> export LUA_INCLUDE_DIR=${val}
> debug-print "${FUNCNAME}: LUA_INCLUDE_DIR =
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +302,7 @@ _lua_export() {
> local val
>
> val=$($(tc-getPKG_CONFIG) --variable
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>
> export LUA_LMOD_DIR=${val}
> debug-print "${FUNCNAME}: LUA_LMOD_DIR =
> ${LUA_LMOD_DIR}"
NACK.
The _lua_get_library_file() result is used for lua_get_shared_lib() and
this appears to be always used when building, not when installing. In
that case, you want it to return the prefixed (and sysrooted) path or
callers should always prepend ${ESYSROOT}.
Similarly, lua_get_include_dir() is often used for building but is
sometimes used for installing too. luaexpat uses it for both! If this
is returned unprefixed then luaexpat and similar should prepend
${ESYSROOT} when building and ${ED} when installing.
I did suggest that you explicitly whether the paths are prefixed or not
in the function descriptions so please do that.
As discussed, I'll get back to you on the other sysroot issue.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgp2lt1tHBLfK.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Mon, 4 Jan 2021 19:28:37 -0500 Mike Gilbert wrote: > On Mon, Jan 4, 2021 at 6:45 PM Mike Gilbert wrote: > > > > On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot wrote: > > > $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev > > > /lib/udev > > > > > > The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all. > > > And why would it be? The man page says that this variable is only > > > applied to -I and -L flags. I don't know for sure but I suspect that > > > pkg-config just sees this as some arbitrary variable with no special > > > path handling at all. I wonder what led you to think that this fix was > > > necessary? > > > > Interesting! > > > > pkg-config behaves differently on my system: > > > > % PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev > > /foo/lib/udev > > > > This appears to be a difference in behavior between dev-util/pkgconfig > > and dev-util/pkgconf. I am using pkgconf, and I would guess you are > > using pkgconfig. > > > > I guess I will ask pkgconf upstream for help on this; it seems like > > this is probably an unintended behavior. > > It seems that the pkgconf behavior is intentional. > > https://github.com/pkgconf/pkgconf/issues/69 > > I opened an issue to see if we can get some kind of opt-out. > > https://github.com/pkgconf/pkgconf/issues/205 Hmmm. At this point, I'm thinking maybe we should just address this in cross-pkg-config. It seems unfair to ask upstream to accommodate this when the tool is just doing what we asked it to. Perhaps it could respect PKG_CONFIG_SYSROOT_DIR if it is already set, even when empty. It wouldn't allow to you set this differently for the build host but you shouldn't ever have to. I think I'd prefer this over adding yet another confusing variable. The same could be applied to PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSTEM_LIBRARY_PATH for consistency. What do you think? On a side note, I think that what cross-pkg-config does should be part of Portage or something rather than part of crossdev because there's nothing really cross-compile-specific about it. You can set SYSROOT when building natively, although that tends to run into even more issues than you get with cross. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpNBAoelSf5e.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Sun, 3 Jan 2021 10:16:49 -0500
Mike Gilbert wrote:
> On Sun, Jan 3, 2021 at 7:52 AM James Le Cuirot wrote:
> >
> > On Sat, 2 Jan 2021 20:09:04 -0500
> > Mike Gilbert wrote:
> >
> > > When cross-compiling, users will typically have
> > > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> > >
> > > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > > output get prefixed with this value.
> > >
> > > Signed-off-by: Mike Gilbert
> > > ---
> > >
> > > This patch has already been pushed, but I figured I would send it for
> > > review in case someone else can think of a failure case, or has a better
> > > solution.
> > >
> > > eclass/systemd.eclass | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > > index 81065a0af79a..f6d1fa2d92d6 100644
> > > --- a/eclass/systemd.eclass
> > > +++ b/eclass/systemd.eclass
> > > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> > >
> > > if $(tc-getPKG_CONFIG) --exists systemd; then
> > > d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd)
> > > || die
> > > + d=${d#${SYSROOT}}
> > > d=${d#${EPREFIX}}
> > > else
> > > d=${fallback}
>
> > The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> > for udev.eclass. It took a while to get this agreed and corrected in
> > PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> > EPREFIX; they may not be the same.
>
> Ugh, that "corrected" logic in PMS head is nasty.
I wish it could be simpler but that's just the nature of the beast. I
could give an example of why it matters, even in this context, but I
think you already know. There's some good news though...
> > If you just strip ESYSROOT then
> > it will always do the right thing but you'll need this fall back for
> > older EAPIs. I'm not sure why you didn't do it in one line?
>
> I was trying to accommodate older EAPIs that do not define ESYSROOT.
> This seemed like the simplest approach. It also allows for the case
> where someone is not using cross-pkg-config, and
> PKG_CONFIG_SYSROOT_DIR is unset. Since SYSROOT and EPREFIX are removed
> separately, if one of them is already missing, it will just be
> skipped.
I saw your new patch. I noticed that it sets the "d" variable but
doesn't make use of it. That aside, I thought perhaps I could come up
with something cleaner. That's when I made an amusing discovery.
$ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
/lib/udev
The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
And why would it be? The man page says that this variable is only
applied to -I and -L flags. I don't know for sure but I suspect that
pkg-config just sees this as some arbitrary variable with no special
path handling at all. I wonder what led you to think that this fix was
necessary?
That said, you'll still need special handling for EAPI 7. Unfortunately
there's no separate variable for the prefix alone but at least it's
simpler now. Something like this?
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c3..f10ea0de01a2 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,12 +50,19 @@ fi
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
- if $($(tc-getPKG_CONFIG) --exists udev); then
- local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
- echo "${udevdir#${EPREFIX%/}}"
- else
- echo /lib/udev
+ local udevdir="/lib/udev"
+
+ if $(tc-getPKG_CONFIG) --exists udev; then
+ udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
+
+ if [[ ${EAPI:-0} == [0123456] ]]; then
+ udevdir=${udevdir#${EPREFIX}}
+ else
+ udevdir=${udevdir#${ESYSROOT#${SYSROOT}}}
+ fi
fi
+
+ echo "${udevdir}"
}
One last question. Why is this dynamic at all? Shouldn't it just be
hardcoded to /lib/udev? Sure, a user could patch udev to make it
something different if they really wanted but there are plenty of other
paths we just assume. What makes this one special?
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpSPRcvfw2Md.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Sun, 3 Jan 2021 12:52:08 +
James Le Cuirot wrote:
> On Sat, 2 Jan 2021 20:09:04 -0500
> Mike Gilbert wrote:
>
> > When cross-compiling, users will typically have
> > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> >
> > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > output get prefixed with this value.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> >
> > This patch has already been pushed, but I figured I would send it for
> > review in case someone else can think of a failure case, or has a better
> > solution.
> >
> > eclass/systemd.eclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > index 81065a0af79a..f6d1fa2d92d6 100644
> > --- a/eclass/systemd.eclass
> > +++ b/eclass/systemd.eclass
> > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> >
> > if $(tc-getPKG_CONFIG) --exists systemd; then
> > d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> > + d=${d#${SYSROOT}}
> > d=${d#${EPREFIX}}
> > else
> > d=${fallback}
>
> I was going to say this is not the best approach as it would be better
> to tell pkg-config to not add the SYSROOT in the first place. I now
> realise we have shot ourselves in the foot with cross-pkg-config as it
> uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
> and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
> had prefix-related fixes for cross-pkg-config lined up for over a year
> but unfortunately they do not address this. Trying to accommodate this
> use case would probably just make it more confusing though so maybe
> your approach is best after all.
>
> The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> for udev.eclass. It took a while to get this agreed and corrected in
> PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> EPREFIX; they may not be the same. If you just strip ESYSROOT then
> it will always do the right thing but you'll need this fall back for
> older EAPIs. I'm not sure why you didn't do it in one line? I forget if
> EPREFIX is normalised to be / rather thank blank.
>
> d=${d#${SYSROOT%/}/${EPREFIX#/}}
Had another minute to think. EPREFIX always strips the trailing slash
so it would be blank.
d=${d#${SYSROOT%/}${EPREFIX}}
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgp0JKYoJYsgE.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Sat, 2 Jan 2021 20:09:04 -0500
Mike Gilbert wrote:
> When cross-compiling, users will typically have
> PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
>
> When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> output get prefixed with this value.
>
> Signed-off-by: Mike Gilbert
> ---
>
> This patch has already been pushed, but I figured I would send it for
> review in case someone else can think of a failure case, or has a better
> solution.
>
> eclass/systemd.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> index 81065a0af79a..f6d1fa2d92d6 100644
> --- a/eclass/systemd.eclass
> +++ b/eclass/systemd.eclass
> @@ -50,6 +50,7 @@ _systemd_get_dir() {
>
> if $(tc-getPKG_CONFIG) --exists systemd; then
> d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> + d=${d#${SYSROOT}}
> d=${d#${EPREFIX}}
> else
> d=${fallback}
I was going to say this is not the best approach as it would be better
to tell pkg-config to not add the SYSROOT in the first place. I now
realise we have shot ourselves in the foot with cross-pkg-config as it
uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
had prefix-related fixes for cross-pkg-config lined up for over a year
but unfortunately they do not address this. Trying to accommodate this
use case would probably just make it more confusing though so maybe
your approach is best after all.
The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
for udev.eclass. It took a while to get this agreed and corrected in
PMS but if SYSROOT points to / then the effective prefix is BROOT, not
EPREFIX; they may not be the same. If you just strip ESYSROOT then
it will always do the right thing but you'll need this fall back for
older EAPIs. I'm not sure why you didn't do it in one line? I forget if
EPREFIX is normalised to be / rather thank blank.
d=${d#${SYSROOT%/}/${EPREFIX#/}}
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpTmn9Lvd_4Y.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: media-libs/jpeg
On Wed, 30 Dec 2020 12:54:59 +0100 Michał Górny wrote: > # Michał Górny (2020-12-30) > # Unmaintained. Entirely replaced by media-libs/libjpeg-turbo, > # to the point that reverse dependencies no longer build with > # media-libs/jpeg. The two libraries are binary-incompatible, > # and the current method of switching between them is incorrect. > # Removal in 30 days. Bug #762634. > media-libs/jpeg It's worth noting that libjpeg-turbo is now an official reference implementation. https://jpeg.org/items/20190204_press.html Also of interest is the fact that libjpeg-turbo can be built to be ABI-compatible with jpeg-7 and jpeg-8, though not the current jpeg-9. I added a turbo-based media-libs/jpeg-compat for version 8 to steam-overlay. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpAmU8tbJTZQ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Thu, 17 Dec 2020 14:38:43 -0600 William Hubbs wrote: > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > I don't really understand what you mean by this. I am converting one > > internal bash function into an external script so that its python > > dependencies can be better defined and managed. > > What I mean is, ebuilds should not be calling _meson_env_array at all > since it is defined and documented as an eclass internal function. > > I would like to know more about what the gallium-nine-standalone ebuild > is doing and why it needs to call a meson.eclass internal function. > > On the other hand, if _meson_env_array is meant to be called by ebuilds, > we need to rename it and improve the documentation for it in the eclass. I knew I spoke to someone about this on IRC and turns out it was you 2 years ago. :P The ebuild needs to render flags as a Meson array and this eclass function is the best way to do it. You did not know why it was private and said to go ahead anyway but file a bug so that this situation could be improved. I admittedly didn't get around to filing a bug but I was totally prepared to deal with the fall out if it broke. Now floppym is improving the situation anyway and fixing the ebuild too. I give my thanks to him. Job done? -- James Le Cuirot (chewi) Gentoo Linux Developer pgpPbvZE71UX_.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH 2/3] meson.eclass: use meson-array script
On Fri, 11 Dec 2020 18:17:43 -0500 Mike Gilbert wrote: > This allows python-exec to pick a suitable interpreter when > /usr/bin/python is missing. > > Closes: https://bugs.gentoo.org/759433 > Signed-off-by: Mike Gilbert > --- > eclass/meson.eclass | 100 +--- > 1 file changed, 39 insertions(+), 61 deletions(-) That's cool. You forgot to remove the __MESON_ARRAY_PARSER definition though. pgpY5ngFuvHKB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Pushing to distfiles?
On Sun, 15 Nov 2020 11:03:29 +1300 Kent Fredric wrote: > On Wed, 11 Nov 2020 19:38:35 -0500 > Rich Freeman wrote: > > > I just host stuff like that on my dev webspace, or better yet on > > github or something else that will auto-tarball stuff. > > Oh, yeah, and don't rely on github auto-tarball stuff. > > History has demonstrated github sometimes "forgets" their cached copies > of those tarballs, and then later when requested, it will regenerate > them fresh ... but with different SHAsums. > > If you're gonna use github for tarballs, roll that tarball yourself, > and attach it to a "release", manually and explicitly, and then use the > URL to the release asset. > > Only then can you be sure: > > a) Of what the tarball actually contains > b) Of what the tarballs SHAsum will be I'm not claiming this has never actually happened but I use these GitHub tarballs *a lot* and I don't recall ever seeing it. Does anyone know for sure that it's happened in, say, the last 3 years? It's a lot of extra work for a problem that may no longer exist or is so rare that it's just not worth the effort. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpUsAXfBuNwo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On Tue, 03 Nov 2020 22:32:11 +0100 Michał Górny wrote: > Additionally, the following packages are looking for a new maintainer: > > net-misc/chrony I may take this if no one else really wants it. I run a simple client and server setup on Gentoo at home but I have no interest in the fancy features. > www-client/vivaldi > www-client/vivaldi-snapshot I'll take these but it may take me some time to get some kind of automation going for the frequent bumps involved. I know that Opera is a similar package but I really don't want it. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpBo6kggM2u6.pgp Description: OpenPGP digital signature
