Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins
On Fri, 2023-01-27 at 21:15 +0100, Michal Prívozník wrote: > But are you saying that if there was a GTK-3 support, then gkrellm could > stay? Most importantly, it needs someone to take care of it. An active Gentoo maintainer for these packages (or the subset that's going to stay), that actually answers bug reports etc. is an absolute must. GTK+3 port would be nice — it would at least prove that people really care enough to do the hard work, and that we won't be removing it soon enough again because of GTK+2 being removed (not likely anytime soon but…) or because the code no longer compiles, or… -- Best regards, Michał Górny
[gentoo-dev] Last rites: app-admin/bastille
# Mike Gilbert (2023-01-28) # No upstream releases since 2008. # No Gentoo maintainer since 2009. # Installs files in the wrong places (bug #455542) # and with the wrong mode (bug #892325). # Removal on 2023-02-27. app-admin/bastille
[gentoo-dev] Last rites: games-rpg/adonthell games-rpg/wastesedge
# Ionen Wolkens (2023-01-28) # Recently broke at runtime, and its relationship with evolving # swig+python is likely to keep breaking this further without an # active upstream (no activty since 2018) to keep up with changes. # Removal: 2023-02-27. Bug #892323 games-rpg/adonthell games-rpg/wastesedge signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins
> On 27 Jan 2023, at 20:15, Michal Prívozník wrote: > > On 1/27/23 20:21, Michał Górny wrote: >> On Fri, 2023-01-27 at 10:51 -0800, A Schenck wrote: >>> On 1/27/23 09:36, Michał Górny wrote: # Michał Górny (2023-01-27) # GKrellM and a variety of plugins. It's unmaintained for some time. # Upstream homepage is gone, and the whole suite is collecting dust # and patches. # Removal on 2023-02-26. Bug #892251. [also eclass/gkrellm-plugin.eclass] app-admin/gkrellm x11-plugins/gkrelltop >>> >>> The old homepage listed in the ebuild is gone but has moved[0]. >>> >>> The live ebuild has the correct upstream repository so it seems like >>> >>> just an oversight to not update the homepage whenever that was >>> >>> changed. >> >> Thanks. Unfortunately, it only confirms what I've suspected: it's not >> maintained and nobody's working on a GTK+3 port [1]. >> >> [1] https://git.srcbox.net/gkrellm/gkrellm/issues/1 >> > > Yes, sadly, Bill passed away more than a year ago: > > https://mailproc.sbbsnet.net/list/gkre...@lists.netservicesgroup.com?cmd=user_listview_msg=40=gkrellm_idx=28 > > But are you saying that if there was a GTK-3 support, then gkrellm could > stay? > Yes. And ideally a maintainer in Gentoo. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins
On 1/27/23 20:21, Michał Górny wrote: > On Fri, 2023-01-27 at 10:51 -0800, A Schenck wrote: >> On 1/27/23 09:36, Michał Górny wrote: >>> # Michał Górny (2023-01-27) >>> # GKrellM and a variety of plugins. It's unmaintained for some >>> time. >>> # Upstream homepage is gone, and the whole suite is collecting dust >>> # and patches. >>> # Removal on 2023-02-26. Bug #892251. >>> >>> [also eclass/gkrellm-plugin.eclass] >>> >>> app-admin/gkrellm >>> x11-plugins/gkrelltop >> >> The old homepage listed in the ebuild is gone but has moved[0]. >> >> The live ebuild has the correct upstream repository so it seems like >> >> just an oversight to not update the homepage whenever that was >> >> changed. > > Thanks. Unfortunately, it only confirms what I've suspected: it's not > maintained and nobody's working on a GTK+3 port [1]. > > [1] https://git.srcbox.net/gkrellm/gkrellm/issues/1 > Yes, sadly, Bill passed away more than a year ago: https://mailproc.sbbsnet.net/list/gkre...@lists.netservicesgroup.com?cmd=user_listview_msg=40=gkrellm_idx=28 But are you saying that if there was a GTK-3 support, then gkrellm could stay? Michal
Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins
On Fri, 2023-01-27 at 10:51 -0800, A Schenck wrote: > On 1/27/23 09:36, Michał Górny wrote: > > # Michał Górny (2023-01-27) > > # GKrellM and a variety of plugins. It's unmaintained for some > > time. > > # Upstream homepage is gone, and the whole suite is collecting dust > > # and patches. > > # Removal on 2023-02-26. Bug #892251. > > > > [also eclass/gkrellm-plugin.eclass] > > > > app-admin/gkrellm > > x11-plugins/gkrelltop > > The old homepage listed in the ebuild is gone but has moved[0]. > > The live ebuild has the correct upstream repository so it seems like > > just an oversight to not update the homepage whenever that was > > changed. Thanks. Unfortunately, it only confirms what I've suspected: it's not maintained and nobody's working on a GTK+3 port [1]. [1] https://git.srcbox.net/gkrellm/gkrellm/issues/1 -- Best regards, Michał Górny
Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins
On 1/27/23 09:36, Michał Górny wrote: # Michał Górny (2023-01-27) # GKrellM and a variety of plugins. It's unmaintained for some time. # Upstream homepage is gone, and the whole suite is collecting dust # and patches. # Removal on 2023-02-26. Bug #892251. [also eclass/gkrellm-plugin.eclass] app-admin/gkrellm x11-plugins/gkrelltop The old homepage listed in the ebuild is gone but has moved[0]. The live ebuild has the correct upstream repository so it seems like just an oversight to not update the homepage whenever that was changed. Bugzilla is crashing when navigating around the bug list but except for the recent CLANG-STRICTER-SYSTEM[1] report the issues[2] are mostly ancient and / or specific to plugins. It was sad losing gkrellm-cpufreq ages ago but cleaning up broken rarely used plugins would be much preferable to "throwing the baby out with the bathwater" if that idiom translates. . . The patches[3] currently in tree are just a default config and some opinions about font and max width. Every non-handheld device we use has gkrellm, two on the personal laptop because one is connected to gkrellmd running on the home server. On the work Mac laptop (though the X implementation there is somewhat broken). On the previous Windows work laptop. The various alternatives all seem much heavier like Plasma System Monitor which wants to take up most of the screen and show things in big pie graphs, or too light like the Mac things that put tiny-to-the- point-of-being-useless icons in the menu bar at the top of the screen. Will try to take a look at the CLANG-STRICTER bug if bugzilla starts working again but it might take a while to figure out the build system since gcc is still the default cc here. Thanks, -A [0] http://gkrellm.srcbox.net/ [1] https://bugs.gentoo.org/show_bug.cgi?id=881957 [2] https://bugs.gentoo.org/buglist.cgi?quicksearch=gkrellm_id=6713191 [3] https://gitweb.gentoo.org/repo/gentoo.git/tree/app-admin/gkrellm/files -- Attached is my PGP public key. Primary key fingerprint: C334 A85F 5B84 0061 2DF9 7310 6E37 4F22 EB0C 3D3A If you have a PGP key (and a minute to spare) please send it in reply to this email. If you have no idea what PGP is, feel free to ignore all this gobbledegook. OpenPGP_0x6E374F22EB0C3D3A.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Python 3.9 removal and Python 3.11 stable
No objections. Lots of work though :)
Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins
230127 Michał Górny wrote: > # GKrellM and a variety of plugins. It's unmaintained for some time. > # Upstream homepage is gone, and the whole suite is collecting dust > # and patches. > # Removal on 2023-02-26. Bug #892251. > acct-group/gkrellmd > acct-user/gkrellmd > app-admin/gkrellm > app-laptop/ibam > media-plugins/gkrellmpc > x11-plugins/bfm ... > x11-themes/gkrellm-themes Is there a recommended alternative ? I've got used to having it in the corner of a desktop & checking it regularly for various info for many years. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-dev] [PATCH 1/1] linux-mod.eclass: Remove EAPI deprecated function call
As warned, remove EAPI deprecated use of econf being called in
linux-mod_src_compile
Bug: https://bugs.gentoo.org/340597
See: https://marc.info/?l=gentoo-dev=167069431328509
Signed-off-by: Mike Pagano
---
eclass/linux-mod.eclass | 4
1 file changed, 4 deletions(-)
diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index 6cf9969b1..482775edc 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -624,10 +624,6 @@ linux-mod_src_compile() {
cd "${srcdir}" || die
ln -s "${S}"/Module.symvers Module.symvers # no die for
bug #888679
einfo "Preparing ${modulename} module"
- if [[ -n ${ECONF_PARAMS} ]]; then
- eqawarn "This package relies on the deprecated
functionality of econf being called in linux-mod_src_compile (ECONF_PARAMS), which will
go away in 30 days (20230107) (https://bugs.gentoo.org/340597)"
- econf ${ECONF_PARAMS}
- fi
# This looks messy, but it is needed to handle multiple variables
# being passed in the BUILD_* stuff where the variables
also have
--
2.39.1
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
OpenPGP_0x92A6DBEC81F2B137.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-admin/gkrellm & plugins
# Michał Górny (2023-01-27) # GKrellM and a variety of plugins. It's unmaintained for some time. # Upstream homepage is gone, and the whole suite is collecting dust # and patches. # Removal on 2023-02-26. Bug #892251. [also eclass/gkrellm-plugin.eclass] acct-group/gkrellmd acct-user/gkrellmd app-admin/gkrellm app-laptop/ibam media-plugins/gkrellmpc x11-plugins/bfm x11-plugins/gkrellaclock x11-plugins/gkrellfire x11-plugins/gkrellkam x11-plugins/gkrellm-bgchanger x11-plugins/gkrellm-bluez x11-plugins/gkrellm-countdown x11-plugins/gkrellm-cpupower x11-plugins/gkrellm-imonc x11-plugins/gkrellmlaunch x11-plugins/gkrellm-leds x11-plugins/gkrellm-mailwatch x11-plugins/gkrellmoon x11-plugins/gkrellm-plugins x11-plugins/gkrellm-radio x11-plugins/gkrellmss x11-plugins/gkrellm-trayicons x11-plugins/gkrellm-vaiobright x11-plugins/gkrellm-volume x11-plugins/gkrellmwireless x11-plugins/gkrellm-xkb x11-plugins/gkrellshoot x11-plugins/gkrellstock x11-plugins/gkrellsun x11-plugins/gkrelltop x11-plugins/gkrellweather x11-plugins/gkwebmon x11-plugins/i8krellm x11-themes/gkrellm-themes -- Best regards, Michał Górny
[gentoo-dev] Python 3.9 removal and Python 3.11 stable
Hi, everyone. TL;DR: 1. We want to drop Python 3.9 from PYTHON_COMPAT around June 2023. 2. We want to switch to Python 3.11 as the stable compat at around the same time. 3. Python 3.12 is coming at May, which will be hellish. === Dropping Python 3.9 in June === I'm happy to announce that the repo has fully migrated to Python 3.10 compatibility, and the only remaining package with only 3.9 is dev-python/pathlib2, which is a backport. I want to thank all the people who helped with it (the list is long so I won't list them). Currently Python 3.9 is in "security" supported state upstream, i.e. they no longer receive bugfixes except for (some of) security backports. We at Python project are planning to drop 3.9 from PYTHON_COMPAT at around June 2023. Does this sound acceptable to all? == Stable Python 3.11 in June == Since dropping python 3.9 will result in use rebuild for our users, we prefer to set python 3.11 as the stable compat at the same time (do note that while a preference, this isn't a blocker). Which is why we also think to bump the stable python to 3.11 at around June. If you haven't ported your packages, please do so ASAP. If you notice a package which isn't used and isn't ported, consider last-riting it. Any help would be very appreciated. If you need help, ping us on #gentoo-python, we are very active there. === Python 3.12 Beta in May === Python 3.12.0b1 is planned for May, with which we would (most likely) add 3.12 to PYTHON_COMPAT. We are expecting it to be a hard release of many reasons, one of them is removal of deprecated builtin distutils. Knowing of this impending hard work, we want to ease our burden, by dropping py3.9 and stabilizing 3.11. -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] sys-kernel/linux-headers: Adjust following kernel-2.eclass changes
On 1/24/23 18:37, James Le Cuirot wrote:
Signed-off-by: James Le Cuirot
---
sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild | 2 +-
sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild | 2 +-
sys-kernel/linux-headers/linux-headers-5.19.ebuild| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
index 08907ac2fb24..06fcc6978ce1 100644
--- a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
@@ -40,7 +40,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
diff --git a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
index 9d2ebae3daee..dae40c5ab655 100644
--- a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
@@ -43,7 +43,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
diff --git a/sys-kernel/linux-headers/linux-headers-5.19.ebuild
b/sys-kernel/linux-headers/linux-headers-5.19.ebuild
index 527b4b401d6c..8ae17e59be76 100644
--- a/sys-kernel/linux-headers/linux-headers-5.19.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.19.ebuild
@@ -42,7 +42,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
ACK
--
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index
[gentoo-dev] Last rites: dev-java/core-specs-alpha dev-java/spec-alpha
# Florian Schmaus (2013-01-27) # Previous dependencies of dev-lang/clojure, now part of the clojure # ebuild and no longer needed. # Removal on 2023-02-27. dev-java/core-specs-alpha dev-java/spec-alpha - Flow
Re: [gentoo-dev] [PATCH] kernel-2.eclass: Make xmakeopts an array for spaces in toolchain vars
On 1/24/2023 18:40, James Le Cuirot wrote:
On Mon, 2023-01-23 at 11:20 -0500, Joshua Kinard wrote:
On 1/21/2023 06:03, James Le Cuirot wrote:
Variables like CC can have spaces for additional arguments. This is
particularly useful for reliably setting the sysroot.
Signed-off-by: James Le Cuirot
---
eclass/kernel-2.eclass | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 873d4a204669..f7fcf15743f0 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kernel-2.eclass
@@ -756,13 +756,22 @@ env_setup_xmakeopts() {
# When cross-compiling, we need to set the ARCH/CROSS_COMPILE
# variables properly or bad things happen !
- xmakeopts="ARCH=${KARCH}"
+ xmakeopts=( ARCH="${KARCH}" )
if [[ ${CTARGET} != ${CHOST} ]] && ! cross_pre_c_headers; then
- xmakeopts="${xmakeopts} CROSS_COMPILE=${CTARGET}-"
+ xmakeopts+=( CROSS_COMPILE="${CTARGET}-" )
elif type -p ${CHOST}-ar >/dev/null; then
- xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
+ xmakeopts+=( CROSS_COMPILE="${CHOST}-" )
fi
- xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) OBJCOPY=$(tc-getOBJCOPY)
READELF=$(tc-getREADELF) STRIP=$(tc-getSTRIP)"
+ xmakeopts+=(
+ HOSTCC="$(tc-getBUILD_CC)"
+ CC="$(tc-getCC)"
+ LD="$(tc-getLD)"
+ AR="$(tc-getAR)"
+ NM="$(tc-getNM)"
+ OBJCOPY="$(tc-getOBJCOPY)"
+ READELF="$(tc-getREADELF)"
+ STRIP="$(tc-getSTRIP)"
+ )
export xmakeopts
}
@@ -850,7 +859,7 @@ install_headers() {
local ddir=$(kernel_header_destdir)
env_setup_xmakeopts
- emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/.. ${xmakeopts}
+ emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
"${xmakeopts[@]}"
# let other packages install some of these headers
rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
Can we perhaps use this opportunity to make "xmakeopts" more clear via a better
name, as well as uppercase it
to indicate that it is an exported variable? E.g., something like
"CROSS_MAKEOPTS" is more clear to the
reader than "xmakeopts", IMHO.
I realize such a change may be a tad invasive to the eclass and possibly touch
some ebuilds, so that may need
to be a separate patch that this proposed change would then be based off of.
I hadn't noticed some older linux-headers ebuilds use this variable, so thanks
for bringing that to my attention. Arguably they shouldn't, as it appears to
be an internal variable, even if it is exported, but it's been dropped in
later versions anyway. I've now made further changes. Please see the two
additional patches.
The changes look good to me, thanks!
Signed-off-by: Joshua Kinard
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by
moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
