Created attachment 889085 [details] ebuild log IIRC this should be fixed dev-lang/rust-1.74.1 if not dev-lang/rust-1.75.0-r1
I assume you have unmasked USE=nightly on rust and enabled it? proc-macro2 is one of the reason USE=nightly got masked.
(In reply to Ionen Wolkens from comment #1) > I assume you have unmasked USE=nightly on rust and enabled it? > > proc-macro2 is one of the reason USE=nightly got masked. (still just tried to build greetd with 1.76.0-r1 and it builds fine, so I do assume it's self-inflicted through force-enabling USE=nightly)
(In reply to Ionen Wolkens from comment #1) > I assume you have unmasked USE=nightly on rust and enabled it? > > proc-macro2 is one of the reason USE=nightly got masked. Please also share `emerge --info` for good measure.
Created attachment 890744 [details] patched greetd portage directory USE=nightly indeed unmasked here, for rather obvious reasons. 'self-inflicted' ? Upstream maybe... Back to serious mode: This issue has been fixed in rust more than 6 months ago. Tested building. diff greetd-0.9.0.ebuild greetd-0.9.0-r1.ebuild 24c24 < proc-macro2@1.0.49 --- > proc-macro2@1.0.71 83a84 > "${FILESDIR}/${PN}-0.9.0-proc-macro2.patch" So it is set to the older dev-lang.rust version in the portage tree.
Should read currently oldest
That dependency seems updated in upstream git, I'll ask for a release. But maybe we could use a snapshot at this point anyawy.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e0fdc0e9272d6672a0b59160be5c7c2cb1765d5f commit e0fdc0e9272d6672a0b59160be5c7c2cb1765d5f Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2024-04-21 00:08:29 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2024-04-21 00:08:29 +0000 gui-libs/greetd: add 0.10.0 Closes: https://bugs.gentoo.org/928286 Signed-off-by: John Helmert III <ajak@gentoo.org> gui-libs/greetd/Manifest | 52 +++++++++++++ gui-libs/greetd/greetd-0.10.0.ebuild | 139 +++++++++++++++++++++++++++++++++++ 2 files changed, 191 insertions(+)
(In reply to John Helmert III from comment #6) > That dependency seems updated in upstream git, I'll ask for a release. But > maybe we could use a snapshot at this point anyawy. Thks 4 the version bump.
No problem!