Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
> On Tue, 13 Jul 2021, Michał Górny wrote: >> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects > The title is too long (50 chars max AFAIR) Heh. :) But yes, I say this every time, but either people don't read others' news item reviews, or they forget them very quickly. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
> On Tue, 13 Jul 2021, Marek Szuba wrote: > Title: PipeWire versions of PulseEffects are now media-sound/easyeffects Too long. https://www.gentoo.org/glep/glep-0042.html#news-item-headers "Title: A short (maximum 50 characters) descriptive title." > Author: Marek Szuba > Posted: 2021-07-16 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: >=media-sound/pulseeffects-5.0.0 > In response to the upstream decision to rename PulseEffects to > EasyEffects we have decided to adopt the new name for versions only > supporting media-video/pipewire while retaining the old one for > versions allowing the use of media-sound/pulseaudio. I find this sentence hard to understand. Maybe it could be split up? Also, it might be helpful to explicitly say what are the old and new versions (>=6.0.0 or >=5.0.0?), especially when the dividing line is different from upstream's. > media-sound/easyeffects is already available in the tree, and all the > PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed > in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are > asked to emerge media-sound/easyeffects instead. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
On Tue, 2021-07-13 at 01:01 +0100, Marek Szuba wrote: > Officially the new name has only been in effect since version 6.0.0 but > having discussed this with prometheanfire on IRC, it makes sense to > extend the new name to >=5.0.0 - that way people not interested in > switching from plain PulseAudio to PipeWire can continue to use v4 > (which according to upstream is now in maintenance mode, i.e. hasn't > been EOLed yet) without having to mask v5 ebuilds. > > It 7 days feels like a reasonable time to wait before dropping > media-sound/pulseeffects-5.0.4 from the tree because this news item will > continue to display for affected users even after the ebuild is gone, > won't it. > > > * * * > > > Title: PipeWire versions of PulseEffects are now media-sound/easyeffects The title is too long (50 chars max AFAIR) > Author: Marek Szuba > Posted: 2021-07-16 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: >=media-sound/pulseeffects-5.0.0 Why not display it to users of all versions? > > In response to the upstream decision to rename PulseEffects to > EasyEffects we have decided to adopt the new name for versions only > supporting media-video/pipewire while retaining the old one for versions > allowing the use of media-sound/pulseaudio. > > media-sound/easyeffects is already available in the tree, and all the > PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed > in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are > asked to emerge media-sound/easyeffects instead. I like short but here it seems that you're skipping some essential details and having users guess. Maybe start by explaining the current state (I guess something like 'pulseeffects versions X use pulseaudio, while versions Y switched to pipewire'?). Then tell people that upstream has decided to rename the project to avoid ambiguity (?). Then make it clear that we are going to split the packages in Gentoo, and one will support PA and the other PW. Finally, tell explicitly what PA and PW users should do, and provide an example emerge snippet (do they need to deselect pulseeffects?). -- Best regards, Michał Górny
Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
> On 13 Jul 2021, at 01:11, Sam James wrote: > > > >> On 13 Jul 2021, at 01:08, Marek Szuba wrote: >> >> On 2021-07-13 01:01, Marek Szuba wrote: >> >>> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects >>> Author: Marek Szuba >>> Posted: 2021-07-16 >>> Revision: 1 >>> News-Item-Format: 2.0 >>> Display-If-Installed: >=media-sound/pulseeffects-5.0.0 >>> In response to the upstream decision to rename PulseEffects to EasyEffects >>> we have decided to adopt the new name for versions only supporting >>> media-video/pipewire while retaining the old one for versions allowing the >>> use of media-sound/pulseaudio. >>> media-sound/easyeffects is already available in the tree, and all the >>> PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed >>> in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are asked >>> to emerge media-sound/easyeffects instead. >> >> Looks like Thunderbird's somehow cocked up the line breaks in the first >> paragraph :-/ For the record, _this_ is what the news item looks like >> (modulo quote marks of course) in my text file. >> > > FWIW, using git send-mail on the gentoo-news repo avoids this ;) s/mail/email/ signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
> On 13 Jul 2021, at 01:08, Marek Szuba wrote: > > On 2021-07-13 01:01, Marek Szuba wrote: > >> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects >> Author: Marek Szuba >> Posted: 2021-07-16 >> Revision: 1 >> News-Item-Format: 2.0 >> Display-If-Installed: >=media-sound/pulseeffects-5.0.0 >> In response to the upstream decision to rename PulseEffects to EasyEffects >> we have decided to adopt the new name for versions only supporting >> media-video/pipewire while retaining the old one for versions allowing the >> use of media-sound/pulseaudio. >> media-sound/easyeffects is already available in the tree, and all the >> PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed >> in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are asked to >> emerge media-sound/easyeffects instead. > > Looks like Thunderbird's somehow cocked up the line breaks in the first > paragraph :-/ For the record, _this_ is what the news item looks like (modulo > quote marks of course) in my text file. > FWIW, using git send-mail on the gentoo-news repo avoids this ;) best, sam signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Re: News item: media-sound/pulseffects "renaming"
On 2021-07-13 01:01, Marek Szuba wrote: Title: PipeWire versions of PulseEffects are now media-sound/easyeffects Author: Marek Szuba Posted: 2021-07-16 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: >=media-sound/pulseeffects-5.0.0 In response to the upstream decision to rename PulseEffects to EasyEffects we have decided to adopt the new name for versions only supporting media-video/pipewire while retaining the old one for versions allowing the use of media-sound/pulseaudio. media-sound/easyeffects is already available in the tree, and all the PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are asked to emerge media-sound/easyeffects instead. Looks like Thunderbird's somehow cocked up the line breaks in the first paragraph :-/ For the record, _this_ is what the news item looks like (modulo quote marks of course) in my text file. -- MS OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] News item: media-sound/pulseffects "renaming"
Officially the new name has only been in effect since version 6.0.0 but having discussed this with prometheanfire on IRC, it makes sense to extend the new name to >=5.0.0 - that way people not interested in switching from plain PulseAudio to PipeWire can continue to use v4 (which according to upstream is now in maintenance mode, i.e. hasn't been EOLed yet) without having to mask v5 ebuilds. It 7 days feels like a reasonable time to wait before dropping media-sound/pulseeffects-5.0.4 from the tree because this news item will continue to display for affected users even after the ebuild is gone, won't it. * * * Title: PipeWire versions of PulseEffects are now media-sound/easyeffects Author: Marek Szuba Posted: 2021-07-16 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: >=media-sound/pulseeffects-5.0.0 In response to the upstream decision to rename PulseEffects to EasyEffects we have decided to adopt the new name for versions only supporting media-video/pipewire while retaining the old one for versions allowing the use of media-sound/pulseaudio. media-sound/easyeffects is already available in the tree, and all the PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are asked to emerge media-sound/easyeffects instead. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
Ben Kohler wrote: > Nobody is "disabling choice" here, Fair! Sorry about the hyperbole. > a change in defaults doesn't remove your ability to choose something else. True. My argument is more specificically that setting USE flags by default in a "low-level" profile goes in the wrong direction. > And I understand your sentiment that adding more default-on flags goes > against YOUR goals of a minimal gentoo, but I'd like to remind you and > others that this minimalism is not the goal of every gentoo user. It's important that this is a low-ish-level profile. Unfortunately Matt didn't respond to my question/point about profile inheritance. I don't expect a gentoo desktop system to be minimal. I would however like being able to build upon a minimal profile (not a desktop one) with nothing in it, as opposed to having to essentially create a new profile for each of my configurations. > I want to be clear that I'm not saying you are wrong, but remember that > your perspective is not the only correct one on this topic. Maybe the discussion should focus on different kinds of profiles? I'm not concerned about typical "user-facing" profiles here, it can make plenty sense to enable these USE flags by default in those. Michael Orlitzky wrote: > all I personally want is to be reasonably sure what my configurations > are going to do without having to list every individual package and > USE flag explicitly. Exactly this. Unfortunately I've had to give up on it, as USE flags are set by default here and there, but I'd love to be able to rely on a minimal starting point that will stay minimal. Thank you for your mail Michael, you expressed my concern very well. Kind regards //Peter
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/12/21 12:25 PM, Michael Orlitzky wrote: We've kept things the same level of difficulty for one group of people, but made them much harder for another. In no situation can anyone who wants everything enabled have a harder time than 'adds USE="bzip2 lzma zstd" to make.conf', but everyone else suffers to some degree. That's discouraging choice overall. Point taken. If IUSE="-flag" were actually common in reality, I'd use it as evidence that MY way is better, but alas.. =) -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On Mon, 2021-07-12 at 10:46 -0500, Ben Kohler wrote: > > Nobody is "disabling choice" here, a change in defaults doesn't remove > your ability to choose something else. I think what you're suggesting is that default-on is not any worse for choice than default-off, since both can be changed? Consider the one legitimate example given: sys-apps/kmod. How can we disable lzma for everything except packages that have +lzma defaulted? (Ignoring the open pull request, that is usually done for a good reason.) In other words, how do people undo this patch, without potentially breaking their systems? I hesitate to speak for anyone else, but all I personally want is to be reasonably sure what my configurations are going to do without having to list every individual package and USE flag explicitly. I don't think it's written in stone anywhere, but the repo relies on the fact that USE flags are disabled by default. As a result, it's much easier for users to add things to USE than it is to remove them. If we assume that most IUSE default-ons exist for a good reason (roughly true), then you can imagine two groups of people. Person 1: wants everything enabled by default. Person 2: wants only important things (determined by chosen profile and IUSE defaults) enabled by default. Before the patch, Person 1: adds USE="bzip2 lzma zstd" to make.conf. Requires no ongoing maintenance. Person 2: does nothing. After the patch, Person 1: does nothing. Person 2: lists a hundred different packages in all of his package.use files, after checking each of them to see which ones have important IUSE defaults. Requires ongoing maintenance as new packages are added. We've kept things the same level of difficulty for one group of people, but made them much harder for another. In no situation can anyone who wants everything enabled have a harder time than 'adds USE="bzip2 lzma zstd" to make.conf', but everyone else suffers to some degree. That's discouraging choice overall.
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On 11.7.2021 23.54, Michał Górny wrote:
> Hi, everyone.
>
>
>
> The point of contention was a proposed change to the EAPI depreciation
> workflow. The current workflow consists of roughly three steps:
>
> 1. The Council decides to deprecate an EAPI. It is added to eapis-
> deprecated in layout.conf and pkgcheck/repoman start emitting warnings
> when they're used in ebuilds. This is a 'weak' request for developers
> to stop using the old EAPI.
>
> 2. The Council decides to ban an EAPI. This is a pure policy decision
> with no technical implementation. It is a 'strong' request not to use
> the old EAPI, and developers have to have a very good reason (e.g.
> blocked secbump, revbump due to dep changes by a third party and so on)
> to touch an ebuild and leave it at old EAPI.
>
> 3. When all ebuilds are removed, the EAPI is added to eapis-banned
> and the tools now explicitly forbid adding ebuilds with that EAPI.
>
>
> The change proposed in [1] eliminates step 2. The EAPI remains
> in 'deprecated' policy-state until all ebuilds using it are removed.
> There is no distinction between 'weak' deprecation ("please don't use
> it") and 'strong' ban ("you mustn't use it unless you have a very good
> reason to").
>
So it's about removing a bureaucratic step that never resulted in
anything before? Sounds good. The 2nd step should be considered being
added back IF people kept deliberately adding deprecated EAPI ebuilds.
But as you said, guess it's not a problem with active maintainers and
current available QA tools.
-- juippis
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/12/21 10:30 AM, Peter Stuge wrote: Matt Turner wrote: If you can find a case where you wouldn't want to enable one of these USE flags, please let me know and I'll reconsider my position. My catalyst spec files all have use: -* foo bar x y z specifically because the defaults are never what I want for any given system. I build desktops, servers, containers, VM appliance images and embedded system, and I know what I want in each one. Especially the latter frequently have only very few USE flags set and I want zero extra dependencies. I think you're making a great argument that you'd be completely unaffected by any of the suggestions in this thread. I don't consider needing "use: -*" at all a desirable situation. This catalyst warning might support that: Warning!!! The use of -* in $stage/use will cause portage to ignore package.use in the profile and portage_confdir. You've been warned! I see it as a shortcoming of the standard profiles that I have to essentially create my own in order to get what I want, as opposed to being able to build upon something truly minimal. I'd claim most of these packages' bzip2/lzma/zstd USE flags should be removed in favor of statically enabling them That is the direct opposite of Gentoo's single most core value: choice Choice makes sense when there's a legitimate trade-off to be made. I explained that and why I frequently do not want those USE flags set, demonstrating that I want choice here. You can of course dismiss any concern which disagrees with your opinion as illegitimate. Please do not bother asking questions if that's your style. Choice isn't dogma. Is there a difference between dogma and value? I understand choice to be a core value in Gentoo. Maybe that's wrong (now)? Core values are more important than pretty much anything else. Choice isn't always possible. That's not this case. If choice is indeed a core value then where choice is pretty easy (this case) in my mind there needs to be an overwhelmingly strong argument to conciously and intentionally disable choice. Just don't do it. Kthx. This kind of thing is nothing but irritating. Please don't do this. I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant exactly what you wrote: This kind of thing (increase default USE-flags) is nothing but irritating. Please don't do this. Kind regards //Peter Hi Peter, Nobody is "disabling choice" here, a change in defaults doesn't remove your ability to choose something else. And I understand your sentiment that adding more default-on flags goes against YOUR goals of a minimal gentoo, but I'd like to remind you and others that this minimalism is not the goal of every gentoo user. More default features might irritate you and other minimalists, but it may significantly improve the gentoo experiences of everyone else. I want to be clear that I'm not saying you are wrong, but remember that your perspective is not the only correct one on this topic. -Ben
[gentoo-dev] [PATCH 2/2] distutils-r1.eclass: use _python_check_EPYTHON in (compile|test|install)
From: Florian Schmaus
Signed-off-by: Florian Schmaus
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 3286842f0933..0236c576efc5 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -742,6 +742,8 @@ _distutils-r1_copy_egg_info() {
distutils-r1_python_compile() {
debug-print-function ${FUNCNAME} "${@}"
+ _python_check_EPYTHON
+
_distutils-r1_copy_egg_info
# distutils is parallel-capable since py3.5
@@ -820,6 +822,8 @@ distutils-r1_python_test() {
die "${FUNCNAME} can be only used after calling
distutils_enable_tests"
fi
+ _python_check_EPYTHON
+
if [[ ${_DISTUTILS_TEST_INSTALL} ]]; then
distutils_install_for_testing
fi
@@ -859,6 +863,8 @@ distutils-r1_python_test() {
distutils-r1_python_install() {
debug-print-function ${FUNCNAME} "${@}"
+ _python_check_EPYTHON
+
local root=${D%/}/_${EPYTHON}
[[ ${DISTUTILS_SINGLE_IMPL} ]] && root=${D%/}
--
2.32.0
[gentoo-dev] [PATCH 1/2] python-utils-r1.eclass: Issue more explanatory errors wrt wrong env
The current errors about incorrect call context are cryptic at best.
Replace the inline checks with a single _python_check_EPYTHON function
and provide a verbose explanation how to fix the problem.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass| 2 +-
eclass/python-utils-r1.eclass | 35 +++
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 344aa46b2f94..3286842f0933 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -459,7 +459,7 @@ distutils_enable_tests() {
esetup.py() {
debug-print-function ${FUNCNAME} "${@}"
- [[ -n ${EPYTHON} ]] || die "EPYTHON unset, invalid call context"
+ _python_check_EPYTHON
[[ ${BUILD_DIR} ]] && _distutils-r1_create_setup_cfg
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 168c767a2eea..fac1fa7facb7 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -549,6 +549,26 @@ python_get_scriptdir() {
echo "${PYTHON_SCRIPTDIR}"
}
+# @FUNCTION: _python_check_EPYTHON
+# @INTERNAL
+# @DESCRIPTION:
+# Verify that EPYTHON is set. Die with an explanatory error if it
+# is not.
+_python_check_EPYTHON() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ -n ${EPYTHON} ]] && return
+
+ eerror "${FUNCNAME[1]} must be called in a valid Python execution
context."
+ eerror "This usually means one of the following:"
+ eerror
+ eerror " 1. inside python_* sub-phase, called via distutils-r1_src*
function."
+ eerror " 2. inside a function called via python_foreach_impl."
+ eerror " 3. after a call to python_setup."
+
+ die "${FUNCNAME[1]} must be called in a valid Python execution context"
+}
+
# @FUNCTION: python_optimize
# @USAGE: [...]
# @DESCRIPTION:
@@ -567,8 +587,7 @@ python_optimize() {
die "python_optimize is not to be used in pre/post* phases"
fi
- [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is
null).'
-
+ _python_check_EPYTHON
local PYTHON=${PYTHON}
[[ ${PYTHON} ]] || _python_export PYTHON
[[ -x ${PYTHON} ]] || die "PYTHON (${PYTHON}) is not executable"
@@ -666,7 +685,7 @@ python_doexe() {
python_newexe() {
debug-print-function ${FUNCNAME} "${@}"
- [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is
null).'
+ _python_check_EPYTHON
[[ ${#} -eq 2 ]] || die "Usage: ${FUNCNAME} "
local wrapd=${_PYTHON_SCRIPTROOT:-/usr/bin}
@@ -794,7 +813,7 @@ python_moduleinto() {
python_domodule() {
debug-print-function ${FUNCNAME} "${@}"
- [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is
null).'
+ _python_check_EPYTHON
local d
if [[ ${_PYTHON_MODULEROOT} == /* ]]; then
@@ -831,7 +850,7 @@ python_domodule() {
python_doheader() {
debug-print-function ${FUNCNAME} "${@}"
- [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is
null).'
+ _python_check_EPYTHON
local includedir=$(python_get_includedir)
local d=${includedir#${EPREFIX}}
@@ -1022,7 +1041,7 @@ python_is_installed() {
python_fix_shebang() {
debug-print-function ${FUNCNAME} "${@}"
- [[ ${EPYTHON} ]] || die "${FUNCNAME}: EPYTHON unset (pkg_setup not
called?)"
+ _python_check_EPYTHON
local force quiet
while [[ ${@} ]]; do
@@ -1254,7 +1273,7 @@ build_sphinx() {
epytest() {
debug-print-function ${FUNCNAME} "${@}"
- [[ -n ${EPYTHON} ]] || die "EPYTHON unset, invalid call context"
+ _python_check_EPYTHON
local args=(
# verbose progress reporting and tracebacks
@@ -1285,7 +1304,7 @@ epytest() {
eunittest() {
debug-print-function ${FUNCNAME} "${@}"
- [[ -n ${EPYTHON} ]] || die "EPYTHON unset, invalid call context"
+ _python_check_EPYTHON
set -- "${EPYTHON}" -m unittest_or_fail discover -v "${@}"
--
2.32.0
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
Matt Turner wrote: > > > If you can find a case where you wouldn't want to enable one of these > > > USE flags, please let me know and I'll reconsider my position. > > > > My catalyst spec files all have use: -* foo bar x y z > > specifically because the defaults are never what I want for any given > > system. I build desktops, servers, containers, VM appliance images and > > embedded system, and I know what I want in each one. Especially the > > latter frequently have only very few USE flags set and I want zero > > extra dependencies. > > I think you're making a great argument that you'd be completely > unaffected by any of the suggestions in this thread. I don't consider needing "use: -*" at all a desirable situation. This catalyst warning might support that: Warning!!! The use of -* in $stage/use will cause portage to ignore package.use in the profile and portage_confdir. You've been warned! I see it as a shortcoming of the standard profiles that I have to essentially create my own in order to get what I want, as opposed to being able to build upon something truly minimal. > > > I'd claim most of these packages' bzip2/lzma/zstd USE flags should > > > be removed in favor of statically enabling them > > > > That is the direct opposite of Gentoo's single most core value: choice > > Choice makes sense when there's a legitimate trade-off to be made. I explained that and why I frequently do not want those USE flags set, demonstrating that I want choice here. You can of course dismiss any concern which disagrees with your opinion as illegitimate. Please do not bother asking questions if that's your style. > Choice isn't dogma. Is there a difference between dogma and value? I understand choice to be a core value in Gentoo. Maybe that's wrong (now)? Core values are more important than pretty much anything else. Choice isn't always possible. That's not this case. If choice is indeed a core value then where choice is pretty easy (this case) in my mind there needs to be an overwhelmingly strong argument to conciously and intentionally disable choice. > > Just don't do it. Kthx. > > This kind of thing is nothing but irritating. Please don't do this. I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant exactly what you wrote: This kind of thing (increase default USE-flags) is nothing but irritating. Please don't do this. Kind regards //Peter
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, Jul 12, 2021 at 04:59:06PM +0200, Michał Górny wrote: > On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote: > > On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote: > > > On 2021-07-11 21:54, Michał Górny wrote: > > > > > > > My gut feeling is that having this distinction is useful. However, it > > > > has been pointed out that we've probably never really had to use it > > > > (i.e. use the "banned" argument to stop someone from using old EAPI) > > > > and that the switch from "deprecated" to "banned" state did not really > > > > affect porting away from old EAPI. > > > > > > For the benefit of those not interested in sifting through the logs of > > > Council meetings, here is a quick reiteration of my take on this: > > > > > > 1. Maybe it's my professional bend speaking but it feels to me like we > > > really should establish a clear, GLEP-documented EAPI life cycle with > > > well-defined meaning of individual stages. I will work on preparing a > > > suitable proposal; > > > > > > 2. Until the above has introduced a (hopefully) better system, I am all > > > for > > > removing step 2 because it makes the procedure less bureaucratic. > > > > > > > > > On 2021-07-12 02:11, Aaron Bauman wrote: > > > > > > > Just officially ban it, send out a message, and use the best judgement > > > > when enforcing it (should it even need to be enforced). > > > > > > And the point of establishing a policy doomed from start to be enforced > > > weakly or not at all is? Other than making the Council look like we care > > > more about theatrics than actual governance, that is. > > > > > > -- > > > Marecki > > > > > > > It is not theatrics. It is a policy that was effective in the past and > > is used in lieu of a technical measure. Albeit, it is unlikely to be > > enforced because most people abide by the deprecation warnings. > > > > That's the whole point. Do we need a two-step deprecation/ban if 'most' > people abide by deprecation warnings? > > I'm wondering if the two-step deprecation/ban isn't a symptom of a wider > problem. After all, we want people to stop using old EAPIs after > they're deprecated, not after they're explicitly forbidden to use them. > > Maybe the whole point is that we should stop trying to draw explicit > lines everywhere and instead assume -- per common sense -- that > deprecating is enough for people to eventually stop using them. > As said, in lieu of that we have a fail safe. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote: > On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote: > > On 2021-07-11 21:54, Michał Górny wrote: > > > > > My gut feeling is that having this distinction is useful. However, it > > > has been pointed out that we've probably never really had to use it > > > (i.e. use the "banned" argument to stop someone from using old EAPI) > > > and that the switch from "deprecated" to "banned" state did not really > > > affect porting away from old EAPI. > > > > For the benefit of those not interested in sifting through the logs of > > Council meetings, here is a quick reiteration of my take on this: > > > > 1. Maybe it's my professional bend speaking but it feels to me like we > > really should establish a clear, GLEP-documented EAPI life cycle with > > well-defined meaning of individual stages. I will work on preparing a > > suitable proposal; > > > > 2. Until the above has introduced a (hopefully) better system, I am all for > > removing step 2 because it makes the procedure less bureaucratic. > > > > > > On 2021-07-12 02:11, Aaron Bauman wrote: > > > > > Just officially ban it, send out a message, and use the best judgement > > > when enforcing it (should it even need to be enforced). > > > > And the point of establishing a policy doomed from start to be enforced > > weakly or not at all is? Other than making the Council look like we care > > more about theatrics than actual governance, that is. > > > > -- > > Marecki > > > > It is not theatrics. It is a policy that was effective in the past and > is used in lieu of a technical measure. Albeit, it is unlikely to be > enforced because most people abide by the deprecation warnings. > That's the whole point. Do we need a two-step deprecation/ban if 'most' people abide by deprecation warnings? I'm wondering if the two-step deprecation/ban isn't a symptom of a wider problem. After all, we want people to stop using old EAPIs after they're deprecated, not after they're explicitly forbidden to use them. Maybe the whole point is that we should stop trying to draw explicit lines everywhere and instead assume -- per common sense -- that deprecating is enough for people to eventually stop using them. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Sun, 2021-07-11 at 15:53 +0200, Thomas Deutschmann wrote: > > Furthermore, tmpfiles.d settings are only supposed for creation, > deletion and cleaning of volatile and temporary files. Any package which > will install tmpfiles.d settings which will create files in persistent > locations should be treated like a bug in the package itself (for Gentoo > packagers for example we have keepdir [3] function). Not crucial to your main point, but packages that use keepdir under /var/cache (which is persistent) get prodded to use tmpfiles instead: https://bugs.gentoo.org/692736
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, Jul 12, 2021 at 04:21:02PM +0200, Thomas Deutschmann wrote: > Hi, > > it's not clear to me what will be the consequences of this change. > > I am expecting good faith and that nobody will add an ebuild with deprecated > EAPI just for fun or because maintainer prefers retro stuff. > > So looking at the reasons to bump without touching EAPI: > > a) Because of a changing dep/add slot operator > > b) Because of a security vulnerability. > > c) Other critical fixes which should reach users ASAP. > > In addition, all of this could happen by non-primary maintainer of the > package. > Like a lot of policies and rules in Gentoo there are exceptions. This is why we have various projects and teams that enforce said policies and rules. Finally, we have escalation procedures with various independent bodies to handle it should common sense prove to be an uncommon virtue. We cannot legislate common sense. So many people spending so much time to arrive at an imperfect policy, as usual. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
Hi, it's not clear to me what will be the consequences of this change. I am expecting good faith and that nobody will add an ebuild with deprecated EAPI just for fun or because maintainer prefers retro stuff. So looking at the reasons to bump without touching EAPI: a) Because of a changing dep/add slot operator b) Because of a security vulnerability. c) Other critical fixes which should reach users ASAP. In addition, all of this could happen by non-primary maintainer of the package. In case such a change would force anyone who is touching the ebuild to also fix the ebuild itself and migrate to latest EAPI -- even non-primary maintainers -- this would be far away from any reality and would cause pain for users in the end because people wouldn't touch these packages anymore. Keep in mind: Even if you are the primary maintainer, if you have foo-1.2.3 (stable for a while but using deprecated EAPI) and upstream just released foo-2.0 (a complete rewrite after 10 years, not yet ready for stabilization but added with latest EAPI) and you would now need to fix something critical in v1.2.3, this would be impossible because adding a patch/change deps is one thing, making an EAPI change _will_ require more testing which will prevent fast stabilization (remember when trailing slash behavior changed when we had no QA/CI checks able to catch most (still not all!) problems caused by incomplete EAPI bumps which had real impact when those ebuilds were merged to disk). If the above will be still allowed (and I believe it *must* be still allowed), we cannot get rid of step 2 -- we will need exemptions. I would really like to understand why people in Gentoo believe we should eliminate step 2 and also start enforcing policy. I agree with the latter: If we create a rule which isn't enforceable, it's not a rule and we shouldn't create it as such. But in this case, like said, I believe we need the exemptions, which makes it impossible to enforce something, so we cannot create a (new) policy in first place. But is it really a problem? Is such a new policy really needed? Are people really pushing lots of ebuilds with EAPIs we already marked as deprecated? If it is a real problem, do we actually have information why maintainers are doing that? Trying to understand why someone keeps using deprecated EAPI could help more like a policy which is more likely to cause more stale packages/ignored bugs assuming these maintainer didn't do that for fun or wilful ignorance. At the moment, the whole idea of creating a policy for that problem sounds like shooting sparrows with cannons. But maybe I am missing something... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote: > On 2021-07-11 21:54, Michał Górny wrote: > > > My gut feeling is that having this distinction is useful. However, it > > has been pointed out that we've probably never really had to use it > > (i.e. use the "banned" argument to stop someone from using old EAPI) > > and that the switch from "deprecated" to "banned" state did not really > > affect porting away from old EAPI. > > For the benefit of those not interested in sifting through the logs of > Council meetings, here is a quick reiteration of my take on this: > > 1. Maybe it's my professional bend speaking but it feels to me like we > really should establish a clear, GLEP-documented EAPI life cycle with > well-defined meaning of individual stages. I will work on preparing a > suitable proposal; > > 2. Until the above has introduced a (hopefully) better system, I am all for > removing step 2 because it makes the procedure less bureaucratic. > > > On 2021-07-12 02:11, Aaron Bauman wrote: > > > Just officially ban it, send out a message, and use the best judgement > > when enforcing it (should it even need to be enforced). > > And the point of establishing a policy doomed from start to be enforced > weakly or not at all is? Other than making the Council look like we care > more about theatrics than actual governance, that is. > > -- > Marecki > It is not theatrics. It is a policy that was effective in the past and is used in lieu of a technical measure. Albeit, it is unlikely to be enforced because most people abide by the deprecation warnings. -Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-crypt/cardpeek
# Marek Szuba (2021-07-12) # No releases since March 2015, no upstream repo activity since November # 2019. Unmaintained in Gentoo. Depends on effectively EOLed Lua 5.2, # fails to build against any other version. Removal in 30 days # (Bug #801883) app-crypt/cardpeek -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping dev-lang/lua:5.2
On 2021-07-09 17:34, William Hubbs wrote: Actually upstream does say when they will stop supporting each version [1]. Um, where? Because I've looked at this page before, I've looked at it again just now and I all can see there is that there will be no further releases of Lua versions up to and including 5.2, and that there will *probably* be no more 5.3 releases. No official End of Life statements, no EOL timeline, and 5.3 is apparently both dead and alive at the same time - which is fine for cats but not so for software. I guess it is a matter of interpretation then, "there will be no further releases" means end of life, to me anyway. Okay, in that case everyone who interprets this as Lua 5.1 having officially been EOLed can substitute the relevant part of the first sentence of my RFC with "the Lua ecosystem is a bloody nightmare because new versions regularly introduce API incompatibilities and a lot of application developers have never bothered to update their Lua code for anything newer than 5.1 in spite of in part because dev-lang/luajit having never reached compatibility with even the 5.2 API". Not that it changes any of my conclusions, IMHO. Two, more importantly, making LuaJIT the only available implementation of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64, riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1 but are not supported by LuaJIT at all) as well as force arm64 and ppc64le users to use a 2.1-beta version. This I am afraid might be the deal breaker, as I honestly cannot imagine Gentoo suddenly implementing support for all those arches. Some of the arches you listed are not stable, so I don't think we have to worry about those arches (see arches.desc). If the arch isn't stable, we can't guarantee anything. I am pretty sure that the ~arch status does NOT give us the right to de-keyword packages en masse. There is activity in luajit upstream, so hopefully they will do a new release that supports the newer lua versions. I do agree that it is problematic that they only support lua 5.1. I really do hope Mike Pall (i.e. LuaJIT upstream) will eventually release stable 2.1 - but between how long it has been since the latest beta and that he responds with something between impatience and hostility to any requests for a new release, LuaJIT has to me been looking more and more like one of those artisanal projects (not necessarily software ones) whose creators chip at them in perpetuity without ever reaching the state worthy of being considered finished. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On 2021-07-11 21:54, Michał Górny wrote: My gut feeling is that having this distinction is useful. However, it has been pointed out that we've probably never really had to use it (i.e. use the "banned" argument to stop someone from using old EAPI) and that the switch from "deprecated" to "banned" state did not really affect porting away from old EAPI. For the benefit of those not interested in sifting through the logs of Council meetings, here is a quick reiteration of my take on this: 1. Maybe it's my professional bend speaking but it feels to me like we really should establish a clear, GLEP-documented EAPI life cycle with well-defined meaning of individual stages. I will work on preparing a suitable proposal; 2. Until the above has introduced a (hopefully) better system, I am all for removing step 2 because it makes the procedure less bureaucratic. On 2021-07-12 02:11, Aaron Bauman wrote: > Just officially ban it, send out a message, and use the best judgement > when enforcing it (should it even need to be enforced). And the point of establishing a policy doomed from start to be enforced weakly or not at all is? Other than making the Council look like we care more about theatrics than actual governance, that is. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On 2021-07-10 22:55, William Hubbs wrote: Change the _R0 suffix on these variable names to _ECLASS. Since my question in response to the previous round of this has yet to be answered, I repeat: are there any non-cosmetic reasons for doing this? -- Marecki OpenPGP_signature Description: OpenPGP digital signature
