Re: [gentoo-dev] Re: EGO_SUM
On Wed, May 31, 2023 at 08:30:58AM +0200, pascal.jaeger leimstift.de wrote:
>
> > Arthur Zamarin hat am 30.05.2023 18:35 CEST
> > geschrieben:
> >
> >
> > Currently the best solution *per package* is to speak with upstream, to
> > add a CI workflow which create a source tarball which includes `vendor`
> > dir. This is the best way, and I'm doing that for multiple upstream of
> > some random Go packages in ::gentoo. But I know the disadvantage -
> > requirement to speak with upstream, explain why, and add it to the
> > system. This is best long-run solution, but more hardships.
> >
>
> I would like to add to this, that even if upstream is not willing to do this,
> devs could automate the creation of vendor tarballs using GitHub actions. I
> only did this for an upstream repositories that are also on GitHub and for
> projects written in Rust. Initially I did this for complicated Rust projects
> with several git submodules and submodules of submodules. But with a little
> tweaking of the GitHub actions I think it would be possible to use it for Go
> as well.
> https://wiki.gentoo.org/wiki/User:Schievel/autocreate_rust_sources
>
> This is additional initial work, but once you set it up, you don't even have
> the extra work of creating a new EGO_SUM for every package release. Ideally
> you just have to change the version in the file name of the ebuild to bump a
> package.
>
> Security wise I do not see a difference between this and creating the vendor
> tarball manually and uploading it to GitHub, as many proxy maintainers
> without devspace do it.
Can we please avoid vendor tarballs? there are situations, say when a
dependency includes non-go code, when vendor tarballs do not work.
That is why I went with the dependency tarballs.
I haven't written github actions, but here is the script I use to create
them, partly thanks to Sam for this.
This is stored in my ~/bin directory and I run it from the top level of
a go project which does not have a "vendor" directory.
William
#!/bin/bash
if [[ -z $1 ]]; then
printf "no tarball name specified\n" >&2
return 1
fi
GOMODCACHE=${PWD}/go-mod go mod download -modcacherw
XZ_OPT='-T0 -9' \
tar --owner 0 --group 0 --posix -acf ${1}-deps.tar.xz go-mod
rm -fr go-mod
signature.asc
Description: PGP signature
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
[gentoo-dev] Last rites: dev-python/http-parser
# Michał Górny (2023-05-31) # Unmaintained. Last commit in 2020. Does not work with Python 3.12. # No revdeps. # Removal on 2023-06-30. Bug #907495. dev-python/http-parser -- Best regards, Michał Górny
[gentoo-dev] [PATCH 3/3] rust-toolchain.eclass: qualify applicable rust_arch_uris with ABI and endianness
For less downloading client-side, as it is likely that only one package
in each covered group would work on a given system.
Closes: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild | 2 +-
dev-lang/rust-bin/rust-bin-1.66.1-r1.ebuild | 2 +-
dev-lang/rust-bin/rust-bin-1.67.1-r2.ebuild | 2 +-
dev-lang/rust-bin/rust-bin-1.68.1.ebuild| 2 +-
dev-lang/rust-bin/rust-bin-1.68.2-r1.ebuild | 2 +-
dev-lang/rust-bin/rust-bin-1.69.0.ebuild| 2 +-
dev-lang/rust/rust-1.65.0.ebuild| 2 +-
dev-lang/rust/rust-1.66.1.ebuild| 2 +-
dev-lang/rust/rust-1.67.1.ebuild| 2 +-
dev-lang/rust/rust-1.68.1.ebuild| 2 +-
dev-lang/rust/rust-1.68.2.ebuild| 2 +-
dev-lang/rust/rust-1.69.0-r1.ebuild | 2 +-
eclass/rust-toolchain.eclass| 16 ++--
13 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild
b/dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild
index 217681fdca9e..6dde1cf31349 100644
--- a/dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild
+++ b/dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild
@@ -21,7 +21,7 @@ SRC_URI+=" sparc? (
${GENTOO_BIN_BASEURI}/${MY_P}-sparc64-unknown-linux-gnu.tar.
LICENSE="|| ( MIT Apache-2.0 ) BSD-1 BSD-2 BSD-4 UoI-NCSA"
SLOT="stable"
KEYWORDS="amd64 arm arm64 ~mips ppc ppc64 ~riscv ~s390 sparc x86"
-IUSE="clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src
rustfmt"
DEPEND=""
diff --git a/dev-lang/rust-bin/rust-bin-1.66.1-r1.ebuild
b/dev-lang/rust-bin/rust-bin-1.66.1-r1.ebuild
index 4c965e1f5dd4..f9765ffc184f 100644
--- a/dev-lang/rust-bin/rust-bin-1.66.1-r1.ebuild
+++ b/dev-lang/rust-bin/rust-bin-1.66.1-r1.ebuild
@@ -21,7 +21,7 @@ SRC_URI+=" sparc? (
${GENTOO_BIN_BASEURI}/${MY_P}-sparc64-unknown-linux-gnu.tar.
LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4 UoI-NCSA"
SLOT="stable"
KEYWORDS="amd64 arm arm64 ~mips ppc ppc64 ~riscv ~s390 ~sparc x86"
-IUSE="clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src
rustfmt"
DEPEND=""
diff --git a/dev-lang/rust-bin/rust-bin-1.67.1-r2.ebuild
b/dev-lang/rust-bin/rust-bin-1.67.1-r2.ebuild
index c8ce92fc1251..d6a0726bbef4 100644
--- a/dev-lang/rust-bin/rust-bin-1.67.1-r2.ebuild
+++ b/dev-lang/rust-bin/rust-bin-1.67.1-r2.ebuild
@@ -21,7 +21,7 @@ SRC_URI="$(rust_all_arch_uris ${MY_P})
LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4 UoI-NCSA"
SLOT="stable"
KEYWORDS="~amd64 ~arm ~arm64 ~mips ~ppc ~ppc64 ~riscv ~s390 ~x86"
-IUSE="clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src
rustfmt"
DEPEND=""
diff --git a/dev-lang/rust-bin/rust-bin-1.68.1.ebuild
b/dev-lang/rust-bin/rust-bin-1.68.1.ebuild
index dd3c4559ee18..73b3c80c1c16 100644
--- a/dev-lang/rust-bin/rust-bin-1.68.1.ebuild
+++ b/dev-lang/rust-bin/rust-bin-1.68.1.ebuild
@@ -21,7 +21,7 @@ SRC_URI="$(rust_all_arch_uris ${MY_P})
LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4 UoI-NCSA"
SLOT="stable"
KEYWORDS="~amd64 ~arm ~arm64 ~mips ~ppc ~ppc64 ~riscv ~s390 ~x86"
-IUSE="clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src
rustfmt"
DEPEND=""
diff --git a/dev-lang/rust-bin/rust-bin-1.68.2-r1.ebuild
b/dev-lang/rust-bin/rust-bin-1.68.2-r1.ebuild
index efd643da0fd7..84e6effba07c 100644
--- a/dev-lang/rust-bin/rust-bin-1.68.2-r1.ebuild
+++ b/dev-lang/rust-bin/rust-bin-1.68.2-r1.ebuild
@@ -21,7 +21,7 @@ SRC_URI="$(rust_all_arch_uris ${MY_P})
LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4 UoI-NCSA"
SLOT="stable"
KEYWORDS="~amd64 ~arm ~arm64 ~mips ~ppc ~ppc64 ~riscv ~s390 ~x86"
-IUSE="clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src
rustfmt"
DEPEND=""
diff --git a/dev-lang/rust-bin/rust-bin-1.69.0.ebuild
b/dev-lang/rust-bin/rust-bin-1.69.0.ebuild
index 10ed7b6cb1f4..71bcc04ada4c 100644
--- a/dev-lang/rust-bin/rust-bin-1.69.0.ebuild
+++ b/dev-lang/rust-bin/rust-bin-1.69.0.ebuild
@@ -21,7 +21,7 @@ SRC_URI="$(rust_all_arch_uris ${MY_P})
LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4 UoI-NCSA"
SLOT="stable"
KEYWORDS="~amd64 ~arm ~arm64 ~mips ~ppc ~ppc64 ~riscv ~s390 ~x86"
-IUSE="clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src
rustfmt"
DEPEND=""
diff --git a/dev-lang/rust/rust-1.65.0.ebuild b/dev-lang/rust/rust-1.65.0.ebuild
index bb793aa16865..c3fe7cbd2f01 100644
--- a/dev-lang/rust/rust-1.65.0.ebuild
+++ b/dev-lang/rust/rust-1.65.0.ebuild
@@ -41,7 +41,7 @@
[gentoo-dev] [PATCH 2/3] rust-toolchain.eclass: add support for mips64el platforms
Right now mips64el systems are treated as mips64 (big-endian) in the rust_abi helper, that prevents installation of rust. Fix by checking for mips64el before mips64. See: https://github.com/gentoo/gentoo/pull/31241 Signed-off-by: WANG Xuerui --- dev-lang/rust-bin/Manifest | 12 dev-lang/rust/Manifest | 10 ++ eclass/rust-toolchain.eclass | 2 ++ 3 files changed, 24 insertions(+) diff --git a/dev-lang/rust-bin/Manifest b/dev-lang/rust-bin/Manifest index 28a2f491f86a..4d076c8865a5 100644 --- a/dev-lang/rust-bin/Manifest +++ b/dev-lang/rust-bin/Manifest @@ -14,6 +14,8 @@ DIST rust-1.65.0-mips-unknown-linux-gnu.tar.xz 172934452 BLAKE2B da7d02247e35723 DIST rust-1.65.0-mips-unknown-linux-gnu.tar.xz.asc 801 BLAKE2B e5323fc58614bb2f61831d9a3bd4e3e17e61d7d876e8ccea0d7bcd90d515cdb09cf6112922260fa7d53ba9944b183918448b31c2de431cee8b2f13e6e82f66ea SHA512 b0544165a5b7b49ea7861ca7cea20d6667976667c2253816f942f9b1473306615df5e5e8c1d28028ae79d7cdfe8bfcecefa8df65648976240af40ac08a8ca458 DIST rust-1.65.0-mips64-unknown-linux-gnuabi64.tar.xz 170733288 BLAKE2B 59211c452f921cc337762bcd50cf6cbe8b59b843c1f8afcb82705092ffd4465b663f3428c718b473235be5308cf13663bebc87a2ce93abc81b11192479261527 SHA512 75012281166d17805ae718b4ef55084f6b59c2ff10ef44ab03efd03e0a72539438ab953384e62f2c90042ed5b044478e17ce64d6e9ad85bf3d40ab55bfaa37fd DIST rust-1.65.0-mips64-unknown-linux-gnuabi64.tar.xz.asc 801 BLAKE2B 491ed32a0804f9b69cfe7622eed951aea8a88e6bb9d0cb90e7fb836807fbb0c02ca1d0f4ce54ec366fb5d314bab7702b2395218c8c6746f35b6a0654f079e8a2 SHA512 afad470d8ab02729ac1fba678a0459279e4b8bf687e7ae90bf51ddd5fab5b9f1d6e421ade260d101405387e793fda7fd6ed35df3a97875342fd93feb2e1598e9 +DIST rust-1.65.0-mips64el-unknown-linux-gnuabi64.tar.xz 174670568 BLAKE2B 5cadd21fe86c15fc305ced94c3ef002c7c9494857aecf2c82a1d79bacbe72f9ea37c4f9cc552cc2af256b5602ad8a0cce28483a0a0f44ee887f22f240a231b46 SHA512 f16a3b29ce635eb8a384c9bd802778cdddfb030459cbc7beb2b5c861bbc7287bf20dbb552d48f8548086436b5dacd8aa3f4eebe82a2bad5785791f6db2c52d93 +DIST rust-1.65.0-mips64el-unknown-linux-gnuabi64.tar.xz.asc 801 BLAKE2B 57ea482eab56a7e17f37709efadd39fdd8ee536de16522996b2a9ab78f8450dd1b14f76360fcab79f3017d3ace389c10755e8865c93e4979a1c37ee5fb039f4c SHA512 ee045f7f129434ee1a1c7dc0612ecb93a4bddc17e5ed3f5b3c751ddf001e4a711f5419c9de7756335fcf59dc6119facb12c8f37fae8acbfb4c407c896761a4ad DIST rust-1.65.0-mipsel-unknown-linux-gnu.tar.xz 177698400 BLAKE2B eac9bbef703dd3d7a96dcb31ee0fd6f46d7046ec5d8e810605285a9b71248f0e97412f881d3ec77b4ce79057367523e36cde1a19733944d5a0fb56fc71e1d95f SHA512 2ae3976913b4d5f6a2bb7a778ffe7cad5bcfa643e37c217790605c5260cef44a2a98baaa5cc4fb70fbf63d5ae10c8d10ebd684d1f21a66c6915c5c58f488d7f0 DIST rust-1.65.0-mipsel-unknown-linux-gnu.tar.xz.asc 801 BLAKE2B 26b706e4c8a05a0e27050c8806d47dba83bf2e529ff10f622bd166aede62b2868a2be746c1b0c5d824df58658d5d125310004922bdd4a1224eb050368483b1df SHA512 49a35c5152d2cab469159b83b081f11897040e5b6ef641e4774a45bdf79b936860302812697469ea4429cfbfa90238958342d03bbca019a80fc7fcf666c571a1 DIST rust-1.65.0-powerpc-unknown-linux-gnu.tar.xz 209510928 BLAKE2B ae05250069277c54f3658aa2474de6ce122de81f54a529cbed63b6e4c2354638904a018453a31dc2ecb364aa0c14bce23d97c4065cf8f7f0feb65e9107be78eb SHA512 a622011ac3c63b1b4f55a3fcf98fd1771af67b64a366473136b28f58e100635b823243e9a12f7694ee303e7338c40431e25554d5d72c16a72d0252c24c2cb7d1 @@ -47,6 +49,8 @@ DIST rust-1.66.1-mips-unknown-linux-gnu.tar.xz 187966796 BLAKE2B 193f18a9c56465d DIST rust-1.66.1-mips-unknown-linux-gnu.tar.xz.asc 801 BLAKE2B a04c0f9320d663658b758e6b89709645433a0d16548c511945c439ce134617c8a05d7e9ff988e8f7a1ef62a726284548bf8b259648f614c3a2205ee9c02b3a91 SHA512 4b581b997a643c0ee6105c141c7859e86d9b2cb6dda85d867593829978911dc5a6c343a11712a334b94188078c0d3b1e7e734334b8b4a16b38afab228172bc6b DIST rust-1.66.1-mips64-unknown-linux-gnuabi64.tar.xz 184874416 BLAKE2B 64d96a026634cce03496be36ea7a42986e0fedc75d6c61e0f9a6ffe5cd3432bacd353276636c58989d02328be62f760bc0157c5999262bbac5c570dbc049635a SHA512 ce4b5ff464e358b085c18c21697cf7f339c19db163a873bf68b24e2febf42e69e582bbfc9f95cc38a6c96610a8ccfe6ec431cb2f98be10c48f9c1cbf027456a0 DIST rust-1.66.1-mips64-unknown-linux-gnuabi64.tar.xz.asc 801 BLAKE2B fdcc56efc4f7df5d13595661d59354e4fcc757e966360fccf8a86d42f31f952334b9cedd107d23e4132b90e3082013cc26076a0754455d2759e2bb878afe023e SHA512 c5918b76fdfa39ba89c980ec2d252b3755439c8baece26d27f3515e800061370c2715620a052d3f22bd57412d058f5e3f53084bee08b5026b0f50112e6c41b93 +DIST rust-1.66.1-mips64el-unknown-linux-gnuabi64.tar.xz 187791816 BLAKE2B b81e214da1dc385bb1af0b01dcdaa5f2f9751b5faa6c9e05f501baeb6f1a298bb0af8829dd04736b76a063a5c28e303f2e295a54bd9093e6520ffd3de37f254f SHA512 4a21385af4b8441ecb717979e2b7329ce9384aa0008c350032d704d57e719464b0efa527745caa55c8e8784a4ae46b19b59631c5649fa50c0c83395864756c95 +DIST rust-1.66.1-mips64el-unknown-linux-gnuabi64.tar.xz.asc 801 BLAKE2B
[gentoo-dev] [PATCH 1/3] rust-toolchain.eclass: cosmetic cleanups
Re-tab the file, and reorganize the rust_abi and rust_all_arch_uris
helpers so the keys are sorted alphabetically while preserving match
order. No functional change intended.
See: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
eclass/rust-toolchain.eclass | 70
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/eclass/rust-toolchain.eclass b/eclass/rust-toolchain.eclass
index df48d3fae264..ef4b2a91ef7d 100644
--- a/eclass/rust-toolchain.eclass
+++ b/eclass/rust-toolchain.eclass
@@ -36,21 +36,21 @@ rust_abi() {
case ${CTARGET%%*-} in
aarch64*gnu) echo aarch64-unknown-linux-gnu;;
aarch64*musl) echo aarch64-unknown-linux-musl;;
- mips64*) echo mips64-unknown-linux-gnuabi64;;
+ armv6j*h*)echo arm-unknown-linux-gnueabihf;;
+ armv6j*s*)echo arm-unknown-linux-gnueabi;;
+ armv7a*h*)echo armv7-unknown-linux-gnueabihf;;
+ i?86*)echo i686-unknown-linux-gnu;;
+ mips64*) echo mips64-unknown-linux-gnuabi64;;
+ mipsel*) echo mipsel-unknown-linux-gnu;;
+ mips*)echo mips-unknown-linux-gnu;;
powerpc64le*) echo powerpc64le-unknown-linux-gnu;;
powerpc64*) echo powerpc64-unknown-linux-gnu;;
- x86_64*gnu) echo x86_64-unknown-linux-gnu;;
+ powerpc*) echo powerpc-unknown-linux-gnu;;
+ riscv64*) echo riscv64gc-unknown-linux-gnu;;
+ s390x*) echo s390x-unknown-linux-gnu;;
+ x86_64*gnu) echo x86_64-unknown-linux-gnu;;
x86_64*musl) echo x86_64-unknown-linux-musl;;
- armv6j*s*)echo arm-unknown-linux-gnueabi;;
- armv6j*h*)echo arm-unknown-linux-gnueabihf;;
- armv7a*h*)echo armv7-unknown-linux-gnueabihf;;
- i?86*)echo i686-unknown-linux-gnu;;
- mipsel*) echo mipsel-unknown-linux-gnu;;
- mips*)echo mips-unknown-linux-gnu;;
- powerpc*) echo powerpc-unknown-linux-gnu;;
- s390x*) echo s390x-unknown-linux-gnu;;
- riscv64*) echo riscv64gc-unknown-linux-gnu;;
- *)echo ${CTARGET};;
+ *)echo ${CTARGET};;
esac
}
@@ -105,22 +105,32 @@ rust_arch_uri() {
#
rust_all_arch_uris()
{
- local uris=""
- uris+="abi_x86_64? ( elibc_glibc? ( $(rust_arch_uri x86_64-unknown-linux-gnu
"$@") )
- elibc_musl? ( $(rust_arch_uri
x86_64-unknown-linux-musl "$@") ) ) "
- uris+="arm?( $(rust_arch_uri arm-unknown-linux-gnueabi "$@")
- $(rust_arch_uri arm-unknown-linux-gnueabihf"$@")
- $(rust_arch_uri armv7-unknown-linux-gnueabihf "$@") ) "
- uris+="arm64? ( elibc_glibc? ( $(rust_arch_uri
aarch64-unknown-linux-gnu "$@") )
- elibc_musl? ( $(rust_arch_uri
aarch64-unknown-linux-musl "$@") ) ) "
- uris+="mips? ( $(rust_arch_uri mips-unknown-linux-gnu "$@")
- $(rust_arch_uri mipsel-unknown-linux-gnu "$@")
- $(rust_arch_uri mips64-unknown-linux-gnuabi64 "$@") ) "
- uris+="ppc?( $(rust_arch_uri powerpc-unknown-linux-gnu "$@") ) "
- uris+="ppc64? ( $(rust_arch_uri powerpc64-unknown-linux-gnu"$@")
- $(rust_arch_uri powerpc64le-unknown-linux-gnu "$@") ) "
- uris+="s390? ( $(rust_arch_uri s390x-unknown-linux-gnu"$@") ) "
- uris+="abi_x86_32? ( $(rust_arch_uri i686-unknown-linux-gnu "$@") ) "
- uris+="riscv? ( $(rust_arch_uri riscv64gc-unknown-linux-gnu"$@") ) "
- echo "${uris}"
+ echo "
+ abi_x86_32? ( $(rust_arch_uri i686-unknown-linux-gnu "$@") )
+ abi_x86_64? (
+ elibc_glibc? ( $(rust_arch_uri x86_64-unknown-linux-gnu "$@") )
+ elibc_musl? ( $(rust_arch_uri x86_64-unknown-linux-musl "$@") )
+ )
+ arm? (
+ $(rust_arch_uri arm-unknown-linux-gnueabi "$@")
+ $(rust_arch_uri arm-unknown-linux-gnueabihf "$@")
+ $(rust_arch_uri armv7-unknown-linux-gnueabihf "$@")
+ )
+ arm64? (
+ elibc_glibc? ( $(rust_arch_uri aarch64-unknown-linux-gnu "$@")
)
+ elibc_musl? ( $(rust_arch_uri aarch64-unknown-linux-musl "$@")
)
+ )
+ mips? (
+ $(rust_arch_uri mips-unknown-linux-gnu "$@")
+ $(rust_arch_uri mipsel-unknown-linux-gnu"$@")
+ $(rust_arch_uri mips64-unknown-linux-gnuabi64 "$@")
+ )
+ ppc? ( $(rust_arch_uri powerpc-unknown-linux-gnu "$@") )
+ ppc64? (
+ $(rust_arch_uri
[gentoo-dev] [PATCH 0/3] rust-toolchain.eclass: cleanups and mips64el support
Hi, This is https://github.com/gentoo/gentoo/pull/31241 and specific to packaging of Rust (the compiler itself), but I'm also sending here for wider review (e.g. in case I messed up some ports but didn't realize). WANG Xuerui (3): rust-toolchain.eclass: cosmetic cleanups rust-toolchain.eclass: add support for mips64el platforms rust-toolchain.eclass: qualify applicable rust_arch_uris with ABI and endianness dev-lang/rust-bin/Manifest | 12 dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild | 2 +- dev-lang/rust-bin/rust-bin-1.66.1-r1.ebuild | 2 +- dev-lang/rust-bin/rust-bin-1.67.1-r2.ebuild | 2 +- dev-lang/rust-bin/rust-bin-1.68.1.ebuild| 2 +- dev-lang/rust-bin/rust-bin-1.68.2-r1.ebuild | 2 +- dev-lang/rust-bin/rust-bin-1.69.0.ebuild| 2 +- dev-lang/rust/Manifest | 10 +++ dev-lang/rust/rust-1.65.0.ebuild| 2 +- dev-lang/rust/rust-1.66.1.ebuild| 2 +- dev-lang/rust/rust-1.67.1.ebuild| 2 +- dev-lang/rust/rust-1.68.1.ebuild| 2 +- dev-lang/rust/rust-1.68.2.ebuild| 2 +- dev-lang/rust/rust-1.69.0-r1.ebuild | 2 +- eclass/rust-toolchain.eclass| 76 + 15 files changed, 80 insertions(+), 42 deletions(-) -- 2.40.0
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
Ühel kenal päeval, K, 31.05.2023 kell 11:43, kirjutas Andrey Grozin: > 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. I'm not aware what :*= is supposed to do, or if it's even valid syntax, compared to := and :* While yes, wxGTK does have implicit subslots from the subslot not being specified (then the subslot is the same as the slot iirc), this isn't a case of perl or similar. This is a case of python, ruby and similar, as these are parallel-installable slots, where you would need to define which they are OK with and lock to that then to avoid issues with other deps using different wxGTK versions (for example imagine filezilla and libfilezilla in a scenario where libfilezilla might grow a dependency on wxCore at some point). But with new slot versions happening every half or full decade, it simply isn't worth adding such complexity. Instead everything should try to switch to the newer version and stop using 3.0 ASAP. Optimizing for users to be able to opt into using older buggier 3.0-gtk3 slot instead of 3.2-gtk3 in order to not have to have multiple slots installed isn't something that we should really worry about. That said, we should indeed work towards updating consumers to 3.2-gtk3 now where possible, which should allow many users to go back to only a single slot, or even from three slots to a single installed slot when they had 3.0 and 3.0-gtk3 before. I think you might have volunteered yourself for that, so you can proceed ;) Once the majority is in 3.0-gtk3, we can as a future step perhaps also add 3.0 ones to package.deprecated. Mart
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
On Wed, 31 May 2023, Piotr Karbowski wrote: There's at least a few project that will not work with new wxGTK, out of what I know that is in tree the SuperSlicer and the PrusaSlicer that in the version currently in tree requires wxGTK 3.0. The newer version of PrusaSlicer actually requires wxGTK 3.1 and does not work well with 3.2, unless the wxGTK 3.2 is built with '--disable-glcanvasegl', but this is not interfaced as USE flag and I doubt ever will be. Yes, surely there are projects which work with 3.0 but not 3.2. But most projects will, probably, just work with 3.2. I've just switched 2 projects to 3.2 without negative consequences. Andrey
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
Hi, On 31/05/2023 13.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 There's at least a few project that will not work with new wxGTK, out of what I know that is in tree the SuperSlicer and the PrusaSlicer that in the version currently in tree requires wxGTK 3.0. The newer version of PrusaSlicer actually requires wxGTK 3.1 and does not work well with 3.2, unless the wxGTK 3.2 is built with '--disable-glcanvasegl', but this is not interfaced as USE flag and I doubt ever will be. Filling bugs might be the way to go, but please keep in mind that some software might be borderline impossible to switch to new wxGTK therefore a 3.0 would need to stay in tree for extended period of time. -- Piotr.
[gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
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
Re: [gentoo-dev] Re: EGO_SUM
Andrew Ammerlaan writes: > On 30/05/2023 18:35, Arthur Zamarin wrote: >> My solution is as such: >> 1. Undeprecate EGO_SUM in eclass >> 2. Forbid it's usage in ::gentoo (done by pkgcheck, error level, will >> fail CI and as such we can see the misuse). Overlays are allowed. >> 3. Maintainer starts talks with upstreams to add release workflow to >> create vendored source tarball, in hopes of it succeeding. "Start early, >> to future profit". I see this flow similar to the "always try to >> upstream patches". >> 4. Until upstream adds it, in ::gentoo use vendor tarballs. >> I also think many devs agree with this solution, but I can't talk for >> them, so I'll be happy agreeing devs can at least reply shortly their >> agreement or disagreement. > > I fully agree with Arthur +1 > With regards to proxy-maintained packages: The proxy can generate and upload > the vendor tarball for the proxied, this is not that much extra work. This expands the required trust in proxy maintainers, in a way which is unusually easy to double check. We can automate generating vendor tarballs (or more). If implemented such that tarballs are reproducible, it should be easy to verify by running the same procedure from a different host and verifying. There would still be a slight cost to an initial 'whitelist package' step or such, but IMO, that's not a very large cost. (and, also, possibly some other mechanism could be implemented) > Best regards, > Andrew -- Arsen Arsenović signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EGO_SUM
Just FYI, here is a working GitHub action for generating vendor tarballs in the same repo but with different branches https://github.com/bekcpear/gopkg-vendors/blob/main/.github/workflows/make-vendor.yaml It has already worked for a long time. Sincerely. Ryan > 在 2023年5月31日，14:20，Andrew Ammerlaan 写道： > > On 30/05/2023 18:35, Arthur Zamarin wrote: >> My solution is as such: >> 1. Undeprecate EGO_SUM in eclass >> 2. Forbid it's usage in ::gentoo (done by pkgcheck, error level, will >> fail CI and as such we can see the misuse). Overlays are allowed. >> 3. Maintainer starts talks with upstreams to add release workflow to >> create vendored source tarball, in hopes of it succeeding. "Start early, >> to future profit". I see this flow similar to the "always try to >> upstream patches". >> 4. Until upstream adds it, in ::gentoo use vendor tarballs. >> I also think many devs agree with this solution, but I can't talk for >> them, so I'll be happy agreeing devs can at least reply shortly their >> agreement or disagreement. > > I fully agree with Arthur > > With regards to proxy-maintained packages: The proxy can generate and upload > the vendor tarball for the proxied, this is not that much extra work. > > Best regards, > Andrew > > >
Re: [gentoo-dev] Re: EGO_SUM
> Arthur Zamarin hat am 30.05.2023 18:35 CEST > geschrieben: > > > Currently the best solution *per package* is to speak with upstream, to > add a CI workflow which create a source tarball which includes `vendor` > dir. This is the best way, and I'm doing that for multiple upstream of > some random Go packages in ::gentoo. But I know the disadvantage - > requirement to speak with upstream, explain why, and add it to the > system. This is best long-run solution, but more hardships. > I would like to add to this, that even if upstream is not willing to do this, devs could automate the creation of vendor tarballs using GitHub actions. I only did this for an upstream repositories that are also on GitHub and for projects written in Rust. Initially I did this for complicated Rust projects with several git submodules and submodules of submodules. But with a little tweaking of the GitHub actions I think it would be possible to use it for Go as well. https://wiki.gentoo.org/wiki/User:Schievel/autocreate_rust_sources This is additional initial work, but once you set it up, you don't even have the extra work of creating a new EGO_SUM for every package release. Ideally you just have to change the version in the file name of the ebuild to bump a package. Security wise I do not see a difference between this and creating the vendor tarball manually and uploading it to GitHub, as many proxy maintainers without devspace do it. Regards Pascal
Re: [gentoo-dev] Re: EGO_SUM
On 30/05/2023 18:35, Arthur Zamarin wrote: My solution is as such: 1. Undeprecate EGO_SUM in eclass 2. Forbid it's usage in ::gentoo (done by pkgcheck, error level, will fail CI and as such we can see the misuse). Overlays are allowed. 3. Maintainer starts talks with upstreams to add release workflow to create vendored source tarball, in hopes of it succeeding. "Start early, to future profit". I see this flow similar to the "always try to upstream patches". 4. Until upstream adds it, in ::gentoo use vendor tarballs. I also think many devs agree with this solution, but I can't talk for them, so I'll be happy agreeing devs can at least reply shortly their agreement or disagreement. I fully agree with Arthur With regards to proxy-maintained packages: The proxy can generate and upload the vendor tarball for the proxied, this is not that much extra work. Best regards, Andrew
