[gentoo-dev] Last rites: media-gfx/xloadimage
# Matt Turner (2025-04-04) # Package is dead and has a pile of patches to make it compile. # SRC_URI is long gone. Many alternative image viewers. # Removal on 2025-05-04. Bug #953119. media-gfx/xloadimage signature.asc Description: PGP signature
[gentoo-dev] [PATCH] cargo.eclass: fix live unpack to use selected cargo
Eveywhere, we use ${CARGO} as set by the rust toolchain setup, except
one place. This caused issues such as erroring out in at least one
reported case with "cargo: command not found" (when using --root,
apparently). It would also certainly not respect RUST_MIN_VER /
RUST_MAX_VER.
Ensure we consistently use the variable referencing the $CARGO that is
definitely guaranteed to exist.
Signed-off-by: Eli Schwartz
---
eclass/cargo.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 95d485ab20c3..d93ae1723470 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -603,12 +603,12 @@ cargo_live_src_unpack() {
export CARGO_HOME="${ECARGO_REGISTRY_DIR}"
# Absence of quotes around offline arg is intentional, as cargo bails
out if it encounters ''
- einfo "cargo fetch ${offline:+--offline}"
- cargo fetch ${offline:+--offline} || die #nowarn
+ einfo "${CARGO} fetch ${offline:+--offline}"
+ "${CARGO}" fetch ${offline:+--offline} || die #nowarn
# Let cargo copy all required crates to "${WORKDIR}" for offline use in
later phases.
- einfo "cargo vendor ${offline:+--offline} ${ECARGO_VENDOR}"
- cargo vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die #nowarn
+ einfo "${CARGO} vendor ${offline:+--offline} ${ECARGO_VENDOR}"
+ "${CARGO}" vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die
#nowarn
# Users may have git checkouts made by cargo.
# While cargo vendors the sources, it still needs git checkout to be
present.
--
2.49.0
[gentoo-dev] [PATCH] cargo.eclass: fix live unpack to use selected cargo
From: Eli Schwartz
Eveywhere, we use ${CARGO} as set by the rust toolchain setup, except
one place. This caused issues such as erroring out in at least one
reported case with "cargo: command not found" (when using --root,
apparently). It would also certainly not respect RUST_MIN_VER /
RUST_MAX_VER.
Ensure we consistently use the variable referencing the $CARGO that is
definitely guaranteed to exist.
Signed-off-by: Eli Schwartz
Signed-off-by: Sam James
---
I've pushed this.
eclass/cargo.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 95d485ab20c34..d93ae1723470a 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -603,12 +603,12 @@ cargo_live_src_unpack() {
export CARGO_HOME="${ECARGO_REGISTRY_DIR}"
# Absence of quotes around offline arg is intentional, as cargo bails
out if it encounters ''
- einfo "cargo fetch ${offline:+--offline}"
- cargo fetch ${offline:+--offline} || die #nowarn
+ einfo "${CARGO} fetch ${offline:+--offline}"
+ "${CARGO}" fetch ${offline:+--offline} || die #nowarn
# Let cargo copy all required crates to "${WORKDIR}" for offline use in
later phases.
- einfo "cargo vendor ${offline:+--offline} ${ECARGO_VENDOR}"
- cargo vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die #nowarn
+ einfo "${CARGO} vendor ${offline:+--offline} ${ECARGO_VENDOR}"
+ "${CARGO}" vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die
#nowarn
# Users may have git checkouts made by cargo.
# While cargo vendors the sources, it still needs git checkout to be
present.
--
2.49.0
[gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public
Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted: > I had really hoped to receive more comments on my earlier RFC. [...] > I really do want to know what others think so I can > make a better judgment on whether or not my idea is really this crazy > and if I should just shut up about it or not (so dear reader if you have > an opinion then please share). So because I carried over my own already "works for me" kernel maintenance scripts from Mandrake when I switched in 2004 and have continued maintaining and using them over the decades since, I normally try to stay out of Gentoo kernel packaging discussion. But given both the above explicit invitation and that as I've read the thread a thought occurred to me... First, DKMS /is/ a cross-distro standard solution. As such, I believe in general it should be reasonably supported in Gentoo unless it simply doesn't make sense (note that "doesn't make sense" can also include the case of simply no one stepping up to do it, not the case here). But, the thought that occurred to me reading the thread, was that there are obvious parallels between this and another very significant and controversial now "cross distro standard solution" (which I guess I don't need to name explicitly). As there, I believe "the Gentoo approach" should (again assuming developer willingness to do the work, seemingly the case here) make it available as an additional integrated *option*, while keeping the current Gentoo option as well. So I support DKMS integration /as/ /an/ /option/. That said, in keeping with my normal policy I'll avoid comment on whether this specific implementation is the best way to do it, vs. something else (which might actually be as simple as a good dkms gentoo-wiki page, or to complete the parallel, may be complex enough to justify installation handbook integration). (Meanwhile, in terms of my personal dkms experience, while my normal kernel maintenance scripts don't use it, I ran across it in an upstream kernel bug tracing discussion at one point and recall being rather confused, having to ddg it, etc. Once I figured out what it actually was I had the context necessary to decide I was better off slightly modifying my existing approach than trying to learn something new "that probably made binary-distro assumptions I'd have to work around anyway". If it was well integrated into Gentoo including documentation I'd have probably at least have heard about it, and would likely have had a much better idea whether and how it would mesh with my own kernel maintenance scripts. So that's why, as an accepted cross-distro standard solution, I'm in favor of integrating it, even if I may or may not be able to personally take advantage of that given my otherwise independent kernel scripts solution.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Last rites: x11-misc/xtoolwait
# Matt Turner (2025-04-04) # Package is dead (last release in 1999). # Not relevant today: purpose is to not overload a very slow system with # multiple X11 clients starting at the same time. SRC_URI is long dead. # Removal on 2025-05-04. Bug #953120. x11-misc/xtoolwait signature.asc Description: PGP signature
[gentoo-dev] Last-rites: media-video/jellyfin-media-player
# Andreas Sturmlechner (2025-04-04) # Depends on Qt5WebEngine, and upstream seem to be having a hard time # porting to Qt6 with an unknown ETA likely well beyond the time we want # to keep dev-qt/qtwebengine:5 in ::gentoo. # Removal on 2025-04-31. Bug #92 media-video/jellyfin-media-player signature.asc Description: This is a digitally signed message part.
