[gentoo-dev] Last-rites: sci-electronics/eagle
# Andreas Sturmlechner (2025-02-18) # Depends on deprecated Qt5WebEngine, no response from maintainers. # Download source appears gone; bugs #926675, #880649, #870256. # Removal on 2025-03-18. sci-electronics/eagle signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] sandbox and /proc//clear_refs [was: problems with media-gfx/asymptote]
On Tue, Feb 18, 2025 at 11:40 PM Andrey Grozin wrote: > > Some additional information: > > # strace -e trace=file ./cordtest > ... > openat(AT_FDCWD, "/proc/3702/clear_refs", O_WRONLY) = 3 > ... > SUCCEEDED > +++ exited with 0 +++ > > It is absolutely legal for the owner of a process to write to > /proc//clear_refs > I think it is a bug in Gentoo sandbox that this is not allowed. Please use Bugzilla.
[gentoo-dev] [PATCH 1/2] rust-toolchain.eclass: simplify `rust_all_arch_uris`
From: Matt Jolly
The `mips` logic has been moved into the one ebuild that it impacts,
and that ebuild is only required for one package - we'll try to
remove it from the tree soon.
Merge `loong` into `rust_all_arch_uris()` output unconditionally;
the check is now superfluous - all pre-1.71.0 rust versions
are out of the tree.
Signed-off-by: Matt Jolly
---
eclass/rust-toolchain.eclass | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/eclass/rust-toolchain.eclass b/eclass/rust-toolchain.eclass
index 89bca88b9e6b..2d9c56b4d6b6 100644
--- a/eclass/rust-toolchain.eclass
+++ b/eclass/rust-toolchain.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2024 Gentoo Authors
+# Copyright 1999-2025 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: rust-toolchain.eclass
@@ -113,29 +113,6 @@ rust_all_arch_uris()
)
riscv? ( elibc_glibc? ( $(rust_arch_uri riscv64gc-unknown-linux-gnu
"$@") ) )
s390? ( elibc_glibc? ( $(rust_arch_uri s390x-unknown-linux-gnu
"$@") ) )
+ loong? ( elibc_glibc? ( $(rust_arch_uri loongarch64-unknown-linux-gnu
"$@") ) )
"
-
- # Upstream did not gain support for loong until v1.71.0.
- # NOTE: Merge this into the block above after every <1.71.0 version is
- # gone from tree.
- local arg_version="${1##*-}"
- arg_version="${arg_version:-$PV}"
- if ver_test "${arg_version}" -ge 1.71.0; then
- echo "loong? ( elibc_glibc? ( $(rust_arch_uri
loongarch64-unknown-linux-gnu "$@") ) )"
- fi
-
- # until https://github.com/rust-lang/rust/pull/113274 is resolved, there
- # will not be upstream-built mips artifacts
- if ver_test "${arg_version}" -lt 1.72.0; then
- echo "mips? (
- abi_mips_o32? (
- big-endian? ( $(rust_arch_uri
mips-unknown-linux-gnu "$@") )
- !big-endian? ( $(rust_arch_uri
mipsel-unknown-linux-gnu "$@") )
- )
- abi_mips_n64? (
- big-endian? ( $(rust_arch_uri
mips64-unknown-linux-gnuabi64 "$@") )
- !big-endian? ( $(rust_arch_uri
mips64el-unknown-linux-gnuabi64 "$@") )
- )
- )"
- fi
}
--
2.48.0
[gentoo-dev] [PATCH 2/2] rust-toolchain.eclass: add rename param to `rust_all_arch_uris()`
From: Matt Jolly
Also update `rust_arch_uri` to also fetch the asc if we're renaming
so that we can use verify-sig.
Signed-off-by: Matt Jolly
---
eclass/rust-toolchain.eclass | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/eclass/rust-toolchain.eclass b/eclass/rust-toolchain.eclass
index 2d9c56b4d6b6..41fccb7c4a07 100644
--- a/eclass/rust-toolchain.eclass
+++ b/eclass/rust-toolchain.eclass
@@ -73,6 +73,7 @@ rust_abi() {
rust_arch_uri() {
if [ -n "$3" ]; then
echo "${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.xz ->
${3}-${1}.tar.xz"
+ echo "verify-sig? (
${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.xz.asc -> ${3}-${1}.tar.xz.asc )"
else
echo "${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.xz"
echo "verify-sig? (
${RUST_TOOLCHAIN_BASEURL}${2}-${1}.tar.xz.asc )"
@@ -80,7 +81,7 @@ rust_arch_uri() {
}
# @FUNCTION: rust_all_arch_uris
-# @USAGE: [alt-distfile-basename]
+# @USAGE: [alt-distfile-basename] [rust_arch_uri-rename-param]
# @DESCRIPTION:
# Outputs the URIs for SRC_URI to help fetch dependencies, using a base URI
# provided as an argument. Optionally allows for distfile renaming via a
specified
@@ -91,28 +92,31 @@ rust_arch_uri() {
#
rust_all_arch_uris()
{
+ local alt_basename="$1"
+ local rename_param="$2"
+
echo "
- abi_x86_32? ( elibc_glibc? ( $(rust_arch_uri i686-unknown-linux-gnu
"$@") ) )
+ abi_x86_32? ( elibc_glibc? ( $(rust_arch_uri i686-unknown-linux-gnu
"${alt_basename}" "${rename_param}") ) )
abi_x86_64? (
- elibc_glibc? ( $(rust_arch_uri x86_64-unknown-linux-gnu "$@") )
- elibc_musl? ( $(rust_arch_uri x86_64-unknown-linux-musl "$@") )
+ elibc_glibc? ( $(rust_arch_uri x86_64-unknown-linux-gnu
"${alt_basename}" "${rename_param}") )
+ elibc_musl? ( $(rust_arch_uri x86_64-unknown-linux-musl
"${alt_basename}" "${rename_param}") )
)
arm? ( elibc_glibc? (
- $(rust_arch_uri arm-unknown-linux-gnueabi "$@")
- $(rust_arch_uri arm-unknown-linux-gnueabihf "$@")
- $(rust_arch_uri armv7-unknown-linux-gnueabihf "$@")
+ $(rust_arch_uri arm-unknown-linux-gnueabi "${alt_basename}"
"${rename_param}")
+ $(rust_arch_uri arm-unknown-linux-gnueabihf "${alt_basename}"
"${rename_param}")
+ $(rust_arch_uri armv7-unknown-linux-gnueabihf "${alt_basename}"
"${rename_param}")
) )
arm64? (
- elibc_glibc? ( $(rust_arch_uri aarch64-unknown-linux-gnu "$@")
)
- elibc_musl? ( $(rust_arch_uri aarch64-unknown-linux-musl "$@")
)
+ elibc_glibc? ( $(rust_arch_uri aarch64-unknown-linux-gnu
"${alt_basename}" "${rename_param}") )
+ elibc_musl? ( $(rust_arch_uri aarch64-unknown-linux-musl
"${alt_basename}" "${rename_param}") )
)
- ppc? ( elibc_glibc? ( $(rust_arch_uri powerpc-unknown-linux-gnu "$@") )
)
+ ppc? ( elibc_glibc? ( $(rust_arch_uri powerpc-unknown-linux-gnu
"${alt_basename}" "${rename_param}") ) )
ppc64? (
- big-endian? ( elibc_glibc? ( $(rust_arch_uri
powerpc64-unknown-linux-gnu "$@") ) )
- !big-endian? ( elibc_glibc? ( $(rust_arch_uri
powerpc64le-unknown-linux-gnu "$@") ) )
+ big-endian? ( elibc_glibc? ( $(rust_arch_uri
powerpc64-unknown-linux-gnu "${alt_basename}" "${rename_param}") ) )
+ !big-endian? ( elibc_glibc? ( $(rust_arch_uri
powerpc64le-unknown-linux-gnu "${alt_basename}" "${rename_param}") ) )
)
- riscv? ( elibc_glibc? ( $(rust_arch_uri riscv64gc-unknown-linux-gnu
"$@") ) )
- s390? ( elibc_glibc? ( $(rust_arch_uri s390x-unknown-linux-gnu
"$@") ) )
- loong? ( elibc_glibc? ( $(rust_arch_uri loongarch64-unknown-linux-gnu
"$@") ) )
+ riscv? ( elibc_glibc? ( $(rust_arch_uri riscv64gc-unknown-linux-gnu
"${alt_basename}" "${rename_param}") ) )
+ s390? ( elibc_glibc? ( $(rust_arch_uri s390x-unknown-linux-gnu
"${alt_basename}" "${rename_param}") ) )
+ loong? ( elibc_glibc? ( $(rust_arch_uri loongarch64-unknown-linux-gnu
"${alt_basename}" "${rename_param}") ) )
"
}
--
2.48.0
[gentoo-dev] sandbox and /proc//clear_refs [was: problems with media-gfx/asymptote]
Some additional information: # strace -e trace=file ./cordtest ... openat(AT_FDCWD, "/proc/3702/clear_refs", O_WRONLY) = 3 ... SUCCEEDED +++ exited with 0 +++ It is absolutely legal for the owner of a process to write to /proc//clear_refs I think it is a bug in Gentoo sandbox that this is not allowed. Andrey
[gentoo-dev] [PATCH 0/2] rust-toolchain.eclass updates
From: Matt Jolly
These commits are part of a larger body of work which will
enable us to add the `beta` and `nightly` channels to
dev-lang/rust{,-bin}.
Please feel free to provide feedback on the commits directly
via the following PR: https://github.com/gentoo/gentoo/pull/40524
which will be merged after Rust 1.85.0 is pushed to the `stable`
channel upstream.
1. tidy up `rust_all_arch_uris`
- There is an obsolete `loong` conditional which is now applied
unconditionally.
- Logic for `mips` (which is only used by one ebuild) has been removed
from the eclass. It is added to that ebuild in a separate commit.
2. add a rename param to `rust_all_arch_uris`
- `rust_arch_uri` already supports renaming distfiles; this commit adds
required plumbing that enables us to use that functionality via
`rust_all_arch_uris` for the `beta` channel.
- `rust_all_arch_uris` now uses local variables instead of "$1" and "$2" for
readability.
- Also updates `rust_arch_uri` to produce an appropriate `verify-sig?`
conditional (including rename) when called in this way.
Matt Jolly (2):
rust-toolchain.eclass: simplify `rust_all_arch_uris`
rust-toolchain.eclass: add rename param to `rust_all_arch_uris()`
eclass/rust-toolchain.eclass | 59
1 file changed, 20 insertions(+), 39 deletions(-)
--
2.48.0
Re: [gentoo-dev] problems with media-gfx/asymptote
On Tue, 18 Feb 2025, Jérôme Carretero wrote: As an asymptote user, I went to check the issue tracker: https://github.com/vectorgraphics/asymptote/issues and the forum: https://sourceforge.net/p/asymptote/discussion/409349/thread/f8851c5214/ but I'm not seeing anything related to this. But from the upstream point of view, there is no issue. When I run these test programs outside the Gentoo sandbox, they succeed and report that the test has passed. This is an issue for Gentoo only. Andrey
[gentoo-dev] problems with media-gfx/asymptote
Hello *, asymptote-3.00 has just appeared, and I'm trying to update the ebuild. asymptote now bundles boehm-gc; the option to use system boehm-gc is now absent. asymptote-3.00/gc/README.md says that it's 8.2.8; however, the sourse tree asymptote-3.00/gc differs from the plain gc-8.2.8. I suppose some hacking autoconf files is needed to unbundle it, and it's a nontrivial work. A pity. What's more, compiling this bundled gc leads to sandbox violations like F: open_wr S: deny P: /proc/4643/clear_refs A: /proc/4643/clear_refs R: /proc/4643/clear_refs C: ./cordtest and several more. All of them are in some test programs: cordtest gctest staticrootstest disclaim_test disclaim_weakmap_test All of them try to write to some /proc/*/clear_refs; I don't know what are these /proc/*/clear_refs files. Surprisingly, all gc test are marked as passed. Maybe, the resulting libgc (and the resulting asymptote) even work. But, of course, the ebuild fails, and does not install these results. Interestingly, emerging boehm-gc succeeds, no sandbox violations. I suppose the best way out is to somehow force asymptote to use the system boehm-gc. As a stopgap measure, is it possible to allow these test programs to write to /proc/*/clear_refs? Hoping for some help, Andrey
Re: [gentoo-dev] problems with media-gfx/asymptote
Hi Andrey, On Tue, 2025-02-18 at 12:18 +, Andrey Grozin wrote: > [asymptote-3.00 has just appeared > [...] > What's more, compiling this bundled gc leads to sandbox violations As an asymptote user, I went to check the issue tracker: https://github.com/vectorgraphics/asymptote/issues and the forum: https://sourceforge.net/p/asymptote/discussion/409349/thread/f8851c5214/ but I'm not seeing anything related to this. May I suggest to bring these issues to upstream's attention so maybe they can understand them and fix them? Best regards, -- Jérôme signature.asc Description: This is a digitally signed message part
