[gentoo-dev] [PATCH] profiles/package.mask: last-rite asm submodules
Signed-off-by: Volkmar W. Pogatzki --- profiles/package.mask | 9 + 1 file changed, 9 insertions(+) diff --git a/profiles/package.mask b/profiles/package.mask index 9dd06203385..55ab9066238 100644 --- a/profiles/package.mask +++ b/profiles/package.mask @@ -33,6 +33,15 @@ #--- END OF EXAMPLES --- +# Volkmar W. Pogatzki (2022-07-12) +# Unused java libraries, all asm-* included in dev-java/asm, +# log4j-api-java9 never to be used as a package. Removal on 2022-08-12. +dev-java/asm-analysis +dev-java/asm-commons +dev-java/asm-tree +dev-java/asm-util +dev-java/log4j-api-java9 + # Sam James (2022-07-12) # Huge number of open bugs, deprecated upstream (they recommend # using other video editors like Shotcut, Kdenlive, ...). Removal on 2022-08-12. -- 2.35.1
[gentoo-dev] Last rites: media-video/kino
# Sam James (2022-07-12) # Huge number of open bugs, deprecated upstream (they recommend # using other video editors like Shotcut, Kdenlive, ...). Removal on 2022-08-12. # Bugs #372053, #438248, #740528, #778338, #832380, #834406. media-video/kino signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: net-mail/mpack
# Sam James (2022-07-10) # Broken with autoconf 2.70+, stuck on EAPI 6, plenty # of concerning warnings. Even Debian's fork isn't # enough to fix all the issues (w/ autoconf). # Removal on 2022-07-10. net-mail/mpack signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name
On Tue, Jul 12, 2022 at 05:28:36AM +0500, Anna Vyalkova wrote: > This patch uses more friendly language towards potential transgender > and plural contributors. > > No other projects require to use a legal name, e.g. Linux says to use > your real name[0]. I'm not sure there are *none*, but nevertheless I think this is a useful change. Thanks for doing this! > Government issued documents are really a bad example since in some > countries it's really hard to get your name changed there. > > [0]: > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin > > Closes: https://bugs.gentoo.org/805575 > Signed-off-by: Anna Vyalkova > --- > glep-0076.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/glep-0076.rst b/glep-0076.rst > index 2216483..27db00a 100644 > --- a/glep-0076.rst > +++ b/glep-0076.rst > @@ -137,8 +137,8 @@ the Certificate of Origin by adding :: > Signed-off-by: Name > > to the commit message as a separate line. The sign-off must contain > -the committer's legal name as a natural person, i.e., the name that > -would appear in a government issued document. > +the committer's real name as a natural person, i.e., the name that > +you would use to present yourself to your colleagues. > > The following is the current Gentoo Certificate of Origin, revision 1: > > -- > 2.35.1 > > signature.asc Description: PGP signature
[gentoo-dev] GLEP 83: EAPI deprecation
Please find below the first draft of GLEP 83 "EAPI deprecation".
This tries to define criteria for deprecation and for banning of EAPIs
by the Council.
I have tried to model it in a way that the actual dates for at least
EAPIs 4 and 5 are reproduced within a few months. To this end, the
criteria depend on three parameters:
- time between EAPI n+1 support by stable Portage and deprecation
of EAPI n (24 months)
- time between deprecation and ban (24 months)
- fraction of ebuilds in the tree when banning (< 5 %, at present
corresponding to about 1500 ebuilds)
The first two parameters can be varied within a relatively wide range,
without much influence on the timing for EAPIs 4 and 5. Combinations
like 30/24 months, 30/18 months, 24/18 months, or even 36/12 months
would work as well. I guess the question there is if we prefer a longer
upgrade path and transition times, or a smaller number of EAPIs in the
tree.
A rendered version (which especially makes the backwards compatibility
table readable) can be found here:
https://github.com/ulm/glep/blob/glep-eapi-deprecation/glep-0083.rst
Comments please.
Ulrich
---
GLEP: 83
Title: EAPI deprecation
Author: Ulrich Müller
Type: Informational
Status: Draft
Version: 1
Created: 2022-06-30
Last-Modified: 2022-07-11
Post-History: 2022-07-11
Content-Type: text/x-rst
---
Abstract
Introduce standardized criteria for deprecation and banning of EAPIs.
Motivation
==
So far, old EAPIs were deprecated by the Gentoo Council in an ad-hoc
manner. No fixed criteria were used, resulting in very different
deprecation times after approval of newer EAPIs. Standardized criteria
for deprecation and banning will make the life cycle of EAPIs more
predictable.
Specification
=
A *deprecated EAPI* is no longer required for the upgrade path of
users' systems. Its use is discouraged, and tools like pkgcheck will
warn about this [#COUNCIL-20130409]_.
A *banned EAPI* must no longer be used, neither for new ebuilds, nor
for updating of existing ebuilds [#COUNCIL-20140311]_.
The Gentoo Council will deprecate an EAPI when two newer EAPIs are
supported by the stable version of Portage, and one of them has been
supported for 24 months.
The Gentoo Council will ban a deprecated EAPI when it is used by less
than 5 % of ebuilds in the Gentoo repository, but no sooner than 24
months after its deprecation.
EAPIs used in profiles are outside the scope of this GLEP.
Rationale
=
Timing of EAPI deprecation is a trade-off between different factors.
On the one hand, the total number of EAPIs in active use should be
limited; this will prevent the learning curve for new developers and
contributors from becoming too steep and will help to reduce code
complexity, e.g. in eclasses.
On the other hand, an upgrade path to a stable system is guaranteed
for one year, plus limited support for systems that are outdated more
than a year [#COUNCIL-20091109]_. Therefore, previous EAPIs are still
required during that time. A period of 24 months before deprecation
has been chosen, which is more than the required minimum and will
allow projects to support a longer upgrade path.
Requiring two newer EAPIs before deprecation will allow ebuilds that
are otherwise seldom updated to be bumped to the next but one EAPI
immediately.
A delay of 24 months between deprecation and ban will give ebuild
authors enough time to update. This is especially relevant for
overlays and downstream distributions. Since a banned EAPI is
sufficient reason for updating an ebuild, an additional threshold of
5 % is required, in order to keep the number of such updates (and bug
reports requesting them) manageable.
Backwards Compatibility
===
The following table compares the actual dates of deprecations and bans
[#PMS-PROJECT]_ with the dates that would have resulted from the
criteria proposed in this GLEP ("new date").
.. csv-table::
:header-rows: 2
:stub-columns: 1
:widths: auto
:align: right
EAPI,Portage,Gentoo repo,deprecated,deprecated,diff.,banned,banned,diff.
,stable,usage < 5 %,actual date,new date,months,actual date,new date,months
0,2005-12-26,2017-02-28,2014-02-25,2009-12-11,-50,2016-01-10,2017-02-28,+14
1,2007-12-11,2009-10-25,2013-04-09,2011-01-08,-27,2014-03-11,2013-01-08,-14
2,2009-01-08,2015-03-27,2013-04-09,2012-03-08,-13,2014-03-11,2015-03-27,+12
3,2010-03-08,2015-01-16,2014-02-25,2013-03-17,-11,2016-01-10,2015-03-17,-10
4,2011-03-17,2018-01-11,2015-10-11,2016-01-17,+3,2018-04-08,2018-01-17,-3
5,2012-12-11,2021-06-15,2018-05-13,2018-06-27,+1,2021-08-08,2021-06-15,-2
6,2016-01-17,2022-11-22 [*]_,2021-07-11,2021-07-05,0,,2023-07-05,
7,2018-06-27,,,
8,2021-07-05,,,
.. [*] Extrapolated date, obtained by fitting data between 2021-01-01
and 2022-07-11 with an exponential function.
References
==
.. [#COUNCIL-20130409] "EAPI deprecation",
Gentoo Council meeting summary 2013-04-09
(https://pr
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 2:20 PM Mike Gilbert wrote: > > On Mon, Jul 11, 2022 at 2:01 PM Anna wrote: > > > > On 2022-07-11 19:57, Ulrich Mueller wrote: > > > > On Mon, 11 Jul 2022, Mike Gilbert wrote: > > > > > > >> Maybe leave ebegin/eend in place then, which was invented precisely for > > > >> this use case? What's so bad about nesting it? > > > > > > > It leads to odd looking output. > > > > > > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7 > > > > > > IIUC it would look like this, with the patch applied: > > > > > > * task 1 > > > * Doing task 2 ... [ ok ] > > > * task 1 succeeded > > > > > > That's not the most beautiful of outputs either. > > > > I think ebegin/eend output should be buffered so it can be nested > > properly. > > > > My take: the main purpose of ebegin is to inform the user that we are > starting a silent long-running task. eend tells you the result of that > task. > > Buffering ebegin calls would sort of defeat that purpose of informing > the user that something is happening. > > In other words, I don't think it makes sense to call ebegin before > starting a task that is expected to produce output. This includes > tasks that call ebegin themselves, since ebegin always produces > output. I've decided this is a hill I don't want to die on, so I've submitted a PR to update the QA check. https://github.com/gentoo/portage/pull/854
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 2:49 PM Frederik Pfautsch wrote: > > Am 11.07.22 um 20:14 schrieb Mike Gilbert: > > On Mon, Jul 11, 2022 at 1:57 PM Ulrich Mueller wrote: > >> > >>> On Mon, 11 Jul 2022, Mike Gilbert wrote: > >> > Maybe leave ebegin/eend in place then, which was invented precisely for > this use case? What's so bad about nesting it? > >> > >>> It leads to odd looking output. > >> > >>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7 > >> > >> IIUC it would look like this, with the patch applied: > >> > >> * task 1 > >> * Doing task 2 ... [ ok ] > >> * task 1 succeeded > >> > >> That's not the most beautiful of outputs either. > > > > Right. I would prefer to apply the first patch I submitted instead. > > How about output like: > > * Doing task 1 ... > > | * Doing task 2 ... > > | \> [ ok ] > > | > > | additional log from task 1 > > | line 2 of task 1 log > > \> [ !! ] > > This would require keeping track of the current "indentation" > level/prepend "| " to each output for every level. But not sure if is > possible/how difficult it is to implement. Just sort of a quick idea. That seems like it would be somewhat involved to implement, and it seems like a lot of complexity to solve relatively minor problem.
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
Am 11.07.22 um 20:14 schrieb Mike Gilbert: On Mon, Jul 11, 2022 at 1:57 PM Ulrich Mueller wrote: On Mon, 11 Jul 2022, Mike Gilbert wrote: Maybe leave ebegin/eend in place then, which was invented precisely for this use case? What's so bad about nesting it? It leads to odd looking output. https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7 IIUC it would look like this, with the patch applied: * task 1 * Doing task 2 ... [ ok ] * task 1 succeeded That's not the most beautiful of outputs either. Right. I would prefer to apply the first patch I submitted instead. How about output like: * Doing task 1 ... | * Doing task 2 ... | \> [ ok ] | | additional log from task 1 | line 2 of task 1 log \> [ !! ] This would require keeping track of the current "indentation" level/prepend "| " to each output for every level. But not sure if is possible/how difficult it is to implement. Just sort of a quick idea. OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 2:01 PM Anna wrote: > > On 2022-07-11 19:57, Ulrich Mueller wrote: > > > On Mon, 11 Jul 2022, Mike Gilbert wrote: > > > > >> Maybe leave ebegin/eend in place then, which was invented precisely for > > >> this use case? What's so bad about nesting it? > > > > > It leads to odd looking output. > > > > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7 > > > > IIUC it would look like this, with the patch applied: > > > > * task 1 > > * Doing task 2 ... [ ok ] > > * task 1 succeeded > > > > That's not the most beautiful of outputs either. > > I think ebegin/eend output should be buffered so it can be nested > properly. > My take: the main purpose of ebegin is to inform the user that we are starting a silent long-running task. eend tells you the result of that task. Buffering ebegin calls would sort of defeat that purpose of informing the user that something is happening. In other words, I don't think it makes sense to call ebegin before starting a task that is expected to produce output. This includes tasks that call ebegin themselves, since ebegin always produces output.
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 1:57 PM Ulrich Mueller wrote: > > > On Mon, 11 Jul 2022, Mike Gilbert wrote: > > >> Maybe leave ebegin/eend in place then, which was invented precisely for > >> this use case? What's so bad about nesting it? > > > It leads to odd looking output. > > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7 > > IIUC it would look like this, with the patch applied: > > * task 1 > * Doing task 2 ... [ ok ] > * task 1 succeeded > > That's not the most beautiful of outputs either. Right. I would prefer to apply the first patch I submitted instead.
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
> On Mon, 11 Jul 2022, Mike Gilbert wrote: >> Maybe leave ebegin/eend in place then, which was invented precisely for >> this use case? What's so bad about nesting it? > It leads to odd looking output. > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7 IIUC it would look like this, with the patch applied: * task 1 * Doing task 2 ... [ ok ] * task 1 succeeded That's not the most beautiful of outputs either. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 1:17 PM Ionen Wolkens wrote:
>
> On Mon, Jul 11, 2022 at 01:08:52PM -0400, Mike Gilbert wrote:
> > On Mon, Jul 11, 2022 at 12:56 PM Ulrich Mueller wrote:
> > >
> > > > On Mon, 11 Jul 2022, Ionen Wolkens wrote:
> > > >> -ebegin " python_check_deps"
> > > >> -python_check_deps
> > > >> -eend ${?}
> > > >> +einfo " python_check_deps"
> > > >> +if python_check_deps; then
> > > >> +einfo " python_check_deps succeeded"
> > > >> +else
> > > >> +einfo " python_check_deps failed"
> > > >> +fi
> > > >> }
> > >
> > > > I was about to go about merging this as suggested, but this masks the
> > > > return value, and then things like this always succeed:
> > >
> > > > if _python_run_check_deps "${impl}"; then
> > >
> > > Maybe leave ebegin/eend in place then, which was invented precisely for
> > > this use case? What's so bad about nesting it?
> >
> > It leads to odd looking output.
> >
> > https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
> >
>
> Isn't that a portage problem? I don't think stopping legitimate use
> because portage displays messages weird is the right thing to do but
> should rather improve how portage displays them in this situation.
What is a "good" way to display it? I don't really think you can make
ebegin/eend look good when there are lines of output between them.
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 01:08:52PM -0400, Mike Gilbert wrote:
> On Mon, Jul 11, 2022 at 12:56 PM Ulrich Mueller wrote:
> >
> > > On Mon, 11 Jul 2022, Ionen Wolkens wrote:
> > >> -ebegin " python_check_deps"
> > >> -python_check_deps
> > >> -eend ${?}
> > >> +einfo " python_check_deps"
> > >> +if python_check_deps; then
> > >> +einfo " python_check_deps succeeded"
> > >> +else
> > >> +einfo " python_check_deps failed"
> > >> +fi
> > >> }
> >
> > > I was about to go about merging this as suggested, but this masks the
> > > return value, and then things like this always succeed:
> >
> > > if _python_run_check_deps "${impl}"; then
> >
> > Maybe leave ebegin/eend in place then, which was invented precisely for
> > this use case? What's so bad about nesting it?
>
> It leads to odd looking output.
>
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
>
Isn't that a portage problem? I don't think stopping legitimate use
because portage displays messages weird is the right thing to do but
should rather improve how portage displays them in this situation.
--
ionen
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 12:11 PM Ionen Wolkens wrote:
>
> On Mon, Jul 11, 2022 at 09:16:10AM -0400, Mike Gilbert wrote:
> > It's common for python_check_deps to call python_has_version, which
> > calls ebegin itself.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> > eclass/python-utils-r1.eclass | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index a18ca58475f..5c678c524ae 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -1399,9 +1399,12 @@ _python_run_check_deps() {
> >
> > local PYTHON_USEDEP="python_targets_${impl}(-)"
> > local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > - ebegin " python_check_deps"
> > - python_check_deps
> > - eend ${?}
> > + einfo " python_check_deps"
> > + if python_check_deps; then
> > + einfo " python_check_deps succeeded"
> > + else
> > + einfo " python_check_deps failed"
> > + fi
> > }
>
> I was about to go about merging this as suggested, but this masks the
> return value, and then things like this always succeed:
>
> if _python_run_check_deps "${impl}"; then
Thanks for catching that.
[gentoo-dev] [PATCH v3] python-utils-r1.eclass: avoid nested ebegin calls
It's common for python_check_deps to call python_has_version, which
calls ebegin itself.
Closes: https://bugs.gentoo.org/851822
Signed-off-by: Mike Gilbert
---
eclass/python-utils-r1.eclass | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a18ca58475f..ab59db9954e 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1399,9 +1399,15 @@ _python_run_check_deps() {
local PYTHON_USEDEP="python_targets_${impl}(-)"
local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
- ebegin " python_check_deps"
+ einfo " python_check_deps"
python_check_deps
- eend ${?}
+ local status=$?
+ if [[ ${status} -eq 0 ]]; then
+ einfo " python_check_deps succeeded"
+ else
+ einfo " python_check_deps failed"
+ fi
+ return ${status}
}
# @FUNCTION: python_has_version
--
2.37.0
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 12:56 PM Ulrich Mueller wrote:
>
> > On Mon, 11 Jul 2022, Ionen Wolkens wrote:
> >> -ebegin " python_check_deps"
> >> -python_check_deps
> >> -eend ${?}
> >> +einfo " python_check_deps"
> >> +if python_check_deps; then
> >> +einfo " python_check_deps succeeded"
> >> +else
> >> +einfo " python_check_deps failed"
> >> +fi
> >> }
>
> > I was about to go about merging this as suggested, but this masks the
> > return value, and then things like this always succeed:
>
> > if _python_run_check_deps "${impl}"; then
>
> Maybe leave ebegin/eend in place then, which was invented precisely for
> this use case? What's so bad about nesting it?
It leads to odd looking output.
https://gitweb.gentoo.org/proj/portage.git/commit/?id=eba088af8f335c0adb386461e6df1267e24800e7
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
> On Mon, 11 Jul 2022, Ionen Wolkens wrote:
>> -ebegin " python_check_deps"
>> -python_check_deps
>> -eend ${?}
>> +einfo " python_check_deps"
>> +if python_check_deps; then
>> +einfo " python_check_deps succeeded"
>> +else
>> +einfo " python_check_deps failed"
>> +fi
>> }
> I was about to go about merging this as suggested, but this masks the
> return value, and then things like this always succeed:
> if _python_run_check_deps "${impl}"; then
Maybe leave ebegin/eend in place then, which was invented precisely for
this use case? What's so bad about nesting it?
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 09:16:10AM -0400, Mike Gilbert wrote:
> It's common for python_check_deps to call python_has_version, which
> calls ebegin itself.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/python-utils-r1.eclass | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index a18ca58475f..5c678c524ae 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1399,9 +1399,12 @@ _python_run_check_deps() {
>
> local PYTHON_USEDEP="python_targets_${impl}(-)"
> local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> - ebegin " python_check_deps"
> - python_check_deps
> - eend ${?}
> + einfo " python_check_deps"
> + if python_check_deps; then
> + einfo " python_check_deps succeeded"
> + else
> + einfo " python_check_deps failed"
> + fi
> }
I was about to go about merging this as suggested, but this masks the
return value, and then things like this always succeed:
if _python_run_check_deps "${impl}"; then
>
> # @FUNCTION: python_has_version
> --
> 2.37.0
>
>
--
ionen
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-libs/ucommon
# David Seifert (2022-07-11) # Unmaintained, companion lib of dev-cpp/commoncpp2 which has already # been removed, fails with USE=-ssl, no revdeps, upstream mostly dead. # Bug #830581, removal on 2022-08-10. dev-libs/ucommon signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, 2022-07-11 at 09:16 -0400, Mike Gilbert wrote:
> It's common for python_check_deps to call python_has_version, which
> calls ebegin itself.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/python-utils-r1.eclass | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index a18ca58475f..5c678c524ae 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1399,9 +1399,12 @@ _python_run_check_deps() {
>
> local PYTHON_USEDEP="python_targets_${impl}(-)"
> local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> - ebegin " python_check_deps"
> - python_check_deps
> - eend ${?}
> + einfo " python_check_deps"
> + if python_check_deps; then
> + einfo " python_check_deps succeeded"
> + else
> + einfo " python_check_deps failed"
> + fi
> }
>
> # @FUNCTION: python_has_version
WFM. Please don't push it yet, I'll ask ionen to add it on top of his
patchset for a single merge.
--
Best regards,
Michał Górny
[gentoo-dev] Last rites: dev-php/pecl-geoip
# Brian Evans (2022-07-11) # The database behind this extension is no longer available # Please migrate to dev-php/maxmind-db-reader optionally with its # bundled extension. Bug 857636 # Removal on 2022-08-10. dev-php/pecl-geoip OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls
It's common for python_check_deps to call python_has_version, which
calls ebegin itself.
Signed-off-by: Mike Gilbert
---
eclass/python-utils-r1.eclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a18ca58475f..5c678c524ae 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1399,9 +1399,12 @@ _python_run_check_deps() {
local PYTHON_USEDEP="python_targets_${impl}(-)"
local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
- ebegin " python_check_deps"
- python_check_deps
- eend ${?}
+ einfo " python_check_deps"
+ if python_check_deps; then
+ einfo " python_check_deps succeeded"
+ else
+ einfo " python_check_deps failed"
+ fi
}
# @FUNCTION: python_has_version
--
2.37.0
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, 2022-07-11 at 07:36 -0400, Mike Gilbert wrote:
> On Mon, Jul 11, 2022 at 3:04 AM Michał Górny wrote:
> >
> > On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> > > It's common for python_check_deps to call python_has_version, which
> > > calls ebegin itself.
> > >
> > > Signed-off-by: Mike Gilbert
> > > ---
> > > eclass/python-utils-r1.eclass | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > > index a18ca58475f..acfa83d5e18 100644
> > > --- a/eclass/python-utils-r1.eclass
> > > +++ b/eclass/python-utils-r1.eclass
> > > @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
> > >
> > > local PYTHON_USEDEP="python_targets_${impl}(-)"
> > > local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > > - ebegin " python_check_deps"
> > > + einfo " python_check_deps"
> > > python_check_deps
> > > - eend ${?}
> > > }
> > >
> > > # @FUNCTION: python_has_version
> >
> > What's the harm in nesting them?
>
> It results in strange looking output, and triggers a QA warning in the
> latest version of Portage.
This change means that if python_check_deps() isn't verbose and returns
false, we have no output that it failed. At least make it print
the result verbosely then.
--
Best regards,
Michał Górny
[gentoo-dev] Last rites: sci-biology/transfac
# David Seifert (2022-07-11) # Crashes with latest emboss, no other distro packages this, # ancient release, bug #361411, removal on 2022-08-10. sci-biology/transfac signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls
On Mon, Jul 11, 2022 at 3:04 AM Michał Górny wrote:
>
> On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> > It's common for python_check_deps to call python_has_version, which
> > calls ebegin itself.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> > eclass/python-utils-r1.eclass | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index a18ca58475f..acfa83d5e18 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
> >
> > local PYTHON_USEDEP="python_targets_${impl}(-)"
> > local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> > - ebegin " python_check_deps"
> > + einfo " python_check_deps"
> > python_check_deps
> > - eend ${?}
> > }
> >
> > # @FUNCTION: python_has_version
>
> What's the harm in nesting them?
It results in strange looking output, and triggers a QA warning in the
latest version of Portage.
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls
On Sun, 2022-07-10 at 23:53 -0400, Mike Gilbert wrote:
> It's common for python_check_deps to call python_has_version, which
> calls ebegin itself.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/python-utils-r1.eclass | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index a18ca58475f..acfa83d5e18 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1399,9 +1399,8 @@ _python_run_check_deps() {
>
> local PYTHON_USEDEP="python_targets_${impl}(-)"
> local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
> - ebegin " python_check_deps"
> + einfo " python_check_deps"
> python_check_deps
> - eend ${?}
> }
>
> # @FUNCTION: python_has_version
What's the harm in nesting them?
--
Best regards,
Michał Górny
