virtual/rust: Add 1.75.0 and add new maintainers

[bowlofeggs]

No description provided.

[gentoo-bot]

Pull Request assignment

Submitter: @bowlofeggs
Areas affected: ebuilds
Packages affected: dev-lang/rust, dev-lang/rust-bin, sys-devel/rust-std, virtual/rust

dev-lang/rust: @gyakovlev, @gentoo/rust
dev-lang/rust-bin: @gentoo/rust
sys-devel/rust-std: @gyakovlev, @gentoo/rust
virtual/rust: @gentoo/rust

Linked bugs

Bugs linked: 922880

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[bowlofeggs]

Note that I haven't completed all the steps mentioned at https://wiki.gentoo.org/wiki/User:GYakovlev/Rust_bump. In particular, I don't have hardware other than x86_64 to check with, so I've only run tests with that arch. I also don't have a musl system handy to test with, so I didn't perform that step either.

[orbea]

In particular, I don't have hardware other than x86_64 to check with, so I've only run tests with that arch. I also don't have a musl system handy to test with, so I didn't perform that step either.

I can sympathize since I also only have x86_64, but this is probably a good way to inadvertently introduce regressions.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-01-30 00:13 UTC
Newest commit scanned: 277d6d6
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/3b9ad40c5c/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-01-30 01:02 UTC
Newest commit scanned: 2851f54
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/cf4d929634/output.html

[thesamesam]

Could you split it up into one commit per package? Same PR is fine (and desirable here).

[Richard-Rogalski]

fwiw, testing on ppc64le atm

[bowlofeggs]

Could you split it up into one commit per package? Same PR is fine (and desirable here).

I've pushed up this change.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-01-31 02:33 UTC
Newest commit scanned: e4f6331
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/d38b84eb56/output.html

[Richard-Rogalski]

Not sure if I'm missing something or if CI auto generates manifests, but it looked like you used thin manifests, and my rsync repo expects thick. just an fyi, idk if its an issue

[bowlofeggs]

I also don't have a musl system handy to test with, so I didn't perform that step either.

I have since set up a musl system and tested Rust there. rpick and ripgrep both build and run, with the exception of the known ripgrep issue https://bugs.gentoo.org/922372 which isn't a regression here.

[bowlofeggs]

Not sure if I'm missing something or if CI auto generates manifests, but it looked like you used thin manifests, and my rsync repo expects thick

I used pkgdev manifest to generate the changes to these manifest files. Are you seeing warnings or errors pertaining to it?

[stefson]

Can you please add profiler support for rust-bin, and the virtual/rust, please? chromium-122 needs it, the implementation ist trivial. I can paste you the patch later the day when I'm back home, or you can copy & paste from the dev-lang/rust ebuild.

[thesamesam]

Not sure if I'm missing something or if CI auto generates manifests, but it looked like you used thin manifests, and my rsync repo expects thick. just an fyi, idk if its an issue

git assures the integrity of files within the repository, so thin manifests are used within the git repo. The rest is generated for rsync down the line, so the PR is fine.

[bowlofeggs]

I have rebased on master to resolve a few conflicts.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-02-01 02:37 UTC
Newest commit scanned: ee18e97
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/2d0d13f7e1/output.html

[bowlofeggs]

Can you please add profiler support for rust-bin, and the virtual/rust, please? chromium-122 needs it, the implementation ist trivial. I can paste you the patch later the day when I'm back home, or you can copy & paste from the dev-lang/rust ebuild.

I like the suggestion. I don't have time to tinker with or test it today, but if you have some time feel free to post up a patch here (or you can PR into my branch on GitHub if you like that workflow).

[stefson]

lets not overcomplicate this, it is really trivial:

diff --git a/rust-bin-1.75.0.ebuild b/rust-bin-1.75.0.ebuild
index b4028fe..ecda7f2 100644
--- a/rust-bin-1.75.0.ebuild
+++ b/rust-bin-1.75.0.ebuild
@@ -31,7 +31,7 @@ SRC_URI="$(rust_all_arch_uris ${MY_P})
 LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4"
 SLOT="stable"
 KEYWORDS="~amd64 ~arm ~arm64 ~loong ~ppc ~ppc64 ~riscv ~s390 ~x86"
-IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix rust-analyzer rust-src rustfmt"
+IUSE="big-endian clippy cpu_flags_x86_sse2 doc prefix profiler rust-analyzer rust-src rustfmt"
 
 DEPEND=""
 
@@ -111,6 +111,7 @@ multilib_src_install() {
 	local components="rustc,cargo,${std}"
 	use doc && components="${components},rust-docs"
 	use clippy && components="${components},clippy-preview"
+	use profiler && components="${components},rust-demangler-preview"
 	use rustfmt && components="${components},rustfmt-preview"
 	use rust-analyzer && components="${components},rust-analyzer-preview,${analysis}"
 	# Rust component 'rust-src' is extracted from separate archive
@@ -148,6 +149,7 @@ multilib_src_install() {
 	)
 
 	use clippy && symlinks+=( clippy-driver cargo-clippy )
+	use profiler && symlinks+=( rust-demangler )
 	use rustfmt && symlinks+=( rustfmt cargo-fmt )
 	use rust-analyzer && symlinks+=( rust-analyzer )
 
@@ -195,6 +197,9 @@ multilib_src_install() {
 		echo /usr/bin/clippy-driver >> "${T}/provider-${P}"
 		echo /usr/bin/cargo-clippy >> "${T}/provider-${P}"
 	fi
+	if use profiler; then
+	echo /usr/bin/rust-demangler >> "${T}/provider-${P}"
+	fi
 	if use rustfmt; then
 		echo /usr/bin/rustfmt >> "${T}/provider-${P}"
 		echo /usr/bin/cargo-fmt >> "${T}/provider-${P}"

and for virtual/rust:

diff --git a/rust-1.75.0.ebuild b/rust-1.75.0.ebuild
index cff4b22..504bc5c 100644
--- a/rust-1.75.0.ebuild
+++ b/rust-1.75.0.ebuild
@@ -14,10 +14,10 @@ LICENSE=""
 # neither system nor bundled, so we just hardcode it here.
 SLOT="0/llvm-17"
 KEYWORDS="amd64 ~arm arm64 ~loong ppc ppc64 ~riscv ~s390 sparc ~x86"
-IUSE="rustfmt"
+IUSE="rustfmt profiler"
 
 BDEPEND=""
 RDEPEND="|| (
-	~dev-lang/rust-bin-${PV}[rustfmt?,${MULTILIB_USEDEP}]
-	~dev-lang/rust-${PV}[rustfmt?,${MULTILIB_USEDEP}]
+	~dev-lang/rust-bin-${PV}[profiler?,rustfmt?,${MULTILIB_USEDEP}]
+	~dev-lang/rust-${PV}[profiler?,rustfmt?,${MULTILIB_USEDEP}]
 )"

[Schievel1]

(or you can PR into my branch on GitHub if you like that workflow).

Better don't. If you force push an that branch this is a recipe for disaster if he bases his branch on it.

[thesamesam]

"lets not overcomplicate this" - he did say you could post a patch here, which you did.

[stefson]

Please don't make wild assumptions about users intentions, I'm sure anyone will agree the part about not overcomplicating things was about to not PR into the private branch. Also unsubbed myself from thread.

[thesamesam]

No assumptions were made, just pointing out that the comment was unnecessary and could be read wrongly. The patch method was mentioned, one could've just posted a patch in response.

[eli-schwartz]

@stefson your patch isn't git formatted and definitely doesn't link to https://bugs.gentoo.org/923010, which feels pretty problematic.

(I'm also not actually sure why it's so important to make this change as part of this specific PR, just submitting a followup PR isn't hard...)

[bowlofeggs]

I'm also not actually sure why it's so important to make this change as part of this specific PR, just submitting a followup PR isn't hard...

@thesamesam would you prefer it if I did a later PR to add this new feature flag, or would you rather it be part of this change? Either way is OK by me. If we do it in this PR, I'd probably opt to make it self-contained commits (one per ebuild).

[thesamesam]

Let's do it separately (new PR later), because we actually need to do it for older Rust anyway - as stable Chromium will either soon, or does already, need this, and it wouldn't be appropriate to rush stabling 1.75.0.

[thesamesam]

wrt this PR: have y'all done testing of say, everything using Rust on your machines (@rust-rebuild), and also the likely culprits (Firefox being the main one, really)?

If so, we can probably go ahead, if ppc64 was fine.

[Schievel1]

I am still compiling right now...

[bowlofeggs]

Hi @thesamesam! I tested a whole bunch of combinations of USE flags and built a handful of rust packages with each of them successfully.

Frustratingly, however, I have found a problem. I have dev-lang/rust-bin and dev-lang/rust installed at the same time on my development system. It seems that if I install dev-lang/rust that things seem to work as expected. Then if I eselect over to rust-bin and build a few things, that seems to work too. However, if I then eselect my way back to dev-lang/rust again the compiler won't run:

$ rustc
rustc: error while loading shared libraries: librustc_driver-d7fa24d03ca45498.so: cannot open shared object file: No such file or directory

I haven't yet dug into the eselect Rust module to learn what might be happening here. I also haven't checked whether this is a regression in 1.75.0, or if this issue is also present in 1.74.1. Once again it is late so I will need to look at this more later. I welcome debugging from anyone who has time and interest!

As an aside, I have been pondering on the idea of automating this testing as it takes quite a lot of time and is probably rather error prone since it is human-driven.

Thanks for all the input on this pull request so far from everyone!

[thesamesam]

Can you try env-update && . /etc/profile after switchinng back to see if it helps?

As an aside, I have been pondering on the idea of automating this testing as it takes quite a lot of time and is probably rather error prone since it is human-driven.

Yes, quite right. Especially given we know there's parts of maintenance which are necessarily human-intensive, it'd be way better to free up time for that.

[bowlofeggs]

Can you try env-update && . /etc/profile after switchinng back to see if it helps?

Ah that does seem to get it working again.

I also noticed something curious which is that if I simply eselect rust-bin and then immediately eselect back to the source rust, it will work. It seems to break only if I build something while I have the rust-bin one selected. Curious.

Since the env-update dance seems to work, would we take that to indicate that perhaps the rust eselect module should itself be doing that for the user when switching providers?

I also should mention that I don't know if anyone has yet tested something other than x86_64. I have personally done my testing on x86_64. I did test musl (though not as heavily - I mostly just did one build and made sure the result could build and run rpick and ripgrep). I don't have any hardware suitable for testing another arch at the moment.

[Schievel1]

Ok I did a full @rust-rebuild on my machine and everything compiles with 1.75.
I also tested Firefox + spider monkey and ripgrep.

/ also everything on x86_64 only. Sorry, but I don't have access to any other architecture

// also

scanelf: rpath_security_checks(): Security problem NULL DT_RUNPATH in /var/tmp/portage/dev-lang/rust-bin-1.75.0/image/opt/rust-bin-1.75.0/lib/libLLVM-17-rust-1.75.0-stable.so

maybe we can fix that down the line in a later bump.

[thesamesam]

@Richard-Rogalski Did you test it?