Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Kent Fredric
On Wed, 16 Sep 2020 16:05:49 -0600
Tim Harder  wrote:

> Speaking for myself, I avoid hosting most of my Gentoo-related work
> (outside of gentoo repo ebuild mangling) on gentoo.org since I prefer
> the services offered elsewhere in terms of usability, visibility, and
> project maintenance. Take this as constructive criticism of how Gentoo
> currently operates as an upstream host and see it as a call for putting
> more emphasis towards deploying GitLab, Gitea, or other similar service
> for Gentoo.

100%. Rich's suggestions with regards to documenting a "here's how you
build a container that can be air-dropped onto gentoo infra and booted,
and incrementally updated on request" process would possibly go a long
way with all of this.

Random devs can band together, build some GitFoo container, get it
working Gud(TM), and petition Infra to deploy it (probably in some
semi-official "this is just an 'speriment" namespace till it ossifies)

Making the Infra side DeadEasy(TM), and the contributor side
DeadEasy(TM) reduces all the real friction points beyond politics.


pgpw5PItQheYQ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: sci-chemistry/ortep3

2020-09-16 Thread Ashley Dixon
On Wed, Sep 16, 2020 at 10:21:17PM +0200, David Seifert wrote:
> # David Seifert  (2020-09-16)
> # EAPI 4, last release in 2001, the Fortran source code
> # is terrible and has buffer overflows.
> # Removal in 30 days.  Bug #664120, #742008.
> sci-chemistry/ortep3

I can't see how this ebuild was working at all, regardless of the aforementioned
bugs. SRC_URI has been dead for many years, along with HOMEPAGE [1]. It seems to
have been mirrored at [2] and [3] (which the ebuild does not reflect),  although
all the other glaring issues remain.

[1] https://web.archive.org/web/2020080100*/http://www.ornl.gov/sci/ortep
[2] https://ornl-ndav.github.io/ortep/ortep.html
[3] https://github.com/ornl-ndav/ortep

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Kent Fredric
On Wed, 16 Sep 2020 19:47:35 -0400
Rich Freeman  wrote:

> Seems like a way to improve this would be better documentation and a
> DIY infra testing platform.
> 
> First, document how to prepare a service for infra hosting.  Maybe
> provide an example service.
> 
> Second, publish a tarball of a container/chroot that basically
> simulates an infra host for testing purposes.  Provide instructions on
> how to configure/run it.  Make it easy - edit this config file to
> point to your repo, put the name of your service/host here, etc.
> 
> Anybody developing a service could then just follow the instructions
> and then test out their service in a similar environment to what infra
> uses.  Nobody needs to be trusted with any credentials.  Nobody needs
> access to any special repos.  They can run the container on their own
> host, and point it at their favorite git repo hosting service.
> 
> Once it is working all they need to do is give the link to their
> repo/etc to infra.  Infra can then fork it and host it.  The
> maintainer can submit pull requests as needed to infra.

I'm in favour of all of this.


pgpR_IjvewA8t.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Kent Fredric
On Wed, 16 Sep 2020 07:11:12 -0400
Rich Freeman  wrote:

> I realize this is a bit more tangential.  I just think that infra is
> already a huge failure point, so having more stuff on infra actually
> makes that failure point more critical.  A Gentoo where little is
> hosted on stuff we own is much more resilient in the face of
> legal/money/etc issues.  If Gentoo just becomes some blessed config
> files, a website, and SAML then anybody could host the core from their
> basement.

I agree on the "infra is a big SPOF", just to me, and my experience,
"single developers" are a much larger/more volatile SPOF.

Like, I can't even keep my own stuff running, so I'm using myself as an
example.

But I know too many people who fall into this camp.

Individuals are much less likely to have the finances and ability to,
not only delegate others to work on their platforms, but are unlikely
to have the delegation itself delegated.

So as fragile as gentoo infra is, ... its still less fragile in the
long term view of things than random 3rd parties.

( This is where we cry about the loss of the original gentoo wiki, and
how long it took us to replace it, where I'd imagine if it had started
out with the full backing of gentoo infra, we'd have lost much less,
and we'd have not lost so much of our google juice and 'fountain of
arcane knowledge' to Arch )


pgpqoOko22Ei0.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Rich Freeman
On Wed, Sep 16, 2020 at 11:44 AM Alec Warner  wrote:
>
>  - repomirror-ci and all the CI stuff is on infra because mgorny is also on 
> infra! It's not like we set his stuff up for him; instead we gave him access 
> to all the infra repos and he had to write his own puppet configs and 
> whatnot. The benefit of course is that anyone on infra can bump the stuff and 
> login to the machines and debug...but its not exactly a low bar.
> ..
> I think traditionally it's been a slog for non-infra people to get infra to 
> host much of anything and due to difficulties with the all-or-nothing 
> approach we take with infra credenteials; can really set a high bar to host 
> much of anything these days.

Seems like a way to improve this would be better documentation and a
DIY infra testing platform.

First, document how to prepare a service for infra hosting.  Maybe
provide an example service.

Second, publish a tarball of a container/chroot that basically
simulates an infra host for testing purposes.  Provide instructions on
how to configure/run it.  Make it easy - edit this config file to
point to your repo, put the name of your service/host here, etc.

Anybody developing a service could then just follow the instructions
and then test out their service in a similar environment to what infra
uses.  Nobody needs to be trusted with any credentials.  Nobody needs
access to any special repos.  They can run the container on their own
host, and point it at their favorite git repo hosting service.

Once it is working all they need to do is give the link to their
repo/etc to infra.  Infra can then fork it and host it.  The
maintainer can submit pull requests as needed to infra.

-- 
Rich



Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Tim Harder
On 2020-09-16 Wed 09:36, Jonas Stein wrote:
> The heart of a distribution is basically its infrastructure and the
> tools to test, maintain and distribute packages.
> 
> If a distribution relies on external sources, which are not maintained
> by the distribution, but a single person, it has been forked.
> 
> A healthy distribution needs to maintain its own tools.

Gentoo is quite free to mirror or fork various tools it deems critical
to itself. All this should require is poking your favorite infra contact
until they set it up. Beyond that, forcing recalcitrant upstreams to
move is futile since Gentoo has no leverage besides asking nicely.

Speaking for myself, I avoid hosting most of my Gentoo-related work
(outside of gentoo repo ebuild mangling) on gentoo.org since I prefer
the services offered elsewhere in terms of usability, visibility, and
project maintenance. Take this as constructive criticism of how Gentoo
currently operates as an upstream host and see it as a call for putting
more emphasis towards deploying GitLab, Gitea, or other similar service
for Gentoo.

Tim



[gentoo-dev] Last rites: app-admin/recursos

2020-09-16 Thread Sam James
# Sam James  (2020-09-16)
# Stuck on EAPI 4, only source is mirror://gentoo,
# unmaintained, HOMEPAGE gone.
app-admin/recursos


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: sci-chemistry/ortep3

2020-09-16 Thread David Seifert
# David Seifert  (2020-09-16)
# EAPI 4, last release in 2001, the Fortran source code
# is terrible and has buffer overflows.
# Removal in 30 days.  Bug #664120, #742008.
sci-chemistry/ortep3




Re: [gentoo-dev] How to stabilize packages with frequent release cycles?

2020-09-16 Thread Jonas Stein
Hi,

> When the latest release remains 'latest ~arch' for less than 3 days,
> stabilizing it after 30 days makes little sense.  After all, people with
> frequent upgrade cycle will test it for no more than that, and people
> with infrequent upgrade cycle may miss the version entirely.

> Do you have any suggestions how we could improve this?

At first we need a strict definition of "stable" and "testing", then we
can discuss how to stabilize.

The list of requirements should be testable like

if (old_enough AND no_bugs_with_security_tag AND all_deps_stable AND ...
) then stable

We should have a vote which properties are required and stick to these
more strictly in future.

And a stabilization tool, which is part of gentoo and hosted at gentoo
will check these properties.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Alec Warner
On Wed, Sep 16, 2020 at 1:17 AM Kent Fredric  wrote:

> On Mon, 14 Sep 2020 10:15:31 -0400
> Rich Freeman  wrote:
>
> > It might be easier to take smaller steps, such as having a policy that
> > "any call for devs to use/test a new tool/service, or any service that
> > automatically performs transactions on bugzilla, must be FOSS, and the
> > link to the source must be included in the initial communication, and
> > it must be clear what version of the code is operating at any time."
> > That is a pretty low barrier to those creating tools, though it
> > doesn't address the infra concern.  However, it does mean that infra
> > is now free to fork the service at any time, and reduces the bus
> > factor greatly.
>
> For the situation of things that take life before being part of infra,
> I think the least we can do is recognize their utility and importance,
> and at least, have infra *offer* some sort of shared location to run a
> deployment.
>
> That I think helps everyone, gives people a place to remove their own
> bus factor, but without mandatory strongarming.
>

The main challenge is always getting stuff onto infra. The past few things
we have launched have been because the developers in question joined infra
to launch their work.

 - repomirror-ci and all the CI stuff is on infra because mgorny is also on
infra! It's not like we set his stuff up for him; instead we gave him
access to all the infra repos and he had to write his own puppet configs
and whatnot. The benefit of course is that anyone on infra can bump the
stuff and login to the machines and debug...but its not exactly a low bar.
 - packages.gentoo.org was also originally arzano pushing patches to me
(which I would merge and then release by hand.) Just like with ebuilds this
eventually became too tedious and he was onboarded as a dev and infra
member to eliminate the middleman.

I think traditionally it's been a slog for non-infra people to get infra to
host much of anything and due to difficulties with the all-or-nothing
approach we take with infra credenteials; can really set a high bar to host
much of anything these days.

-A


Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Jonas Stein
Hi,

> However, we are still facing the same problem: Only one person is
> involved in development and knows how to run it. In case something will
> break again and Michał will be unavailable, we can’t just push a fix and
> watch a CI pipeline picking up and deploying new nattka. Instead someone
> will have to fork repository from Michał’s private repository at GitHub,
> make the changes and hope that anyone within infrastructure team can
> help to deploy fixed nattka.

The heart of a distribution is basically its infrastructure and the
tools to test, maintain and distribute packages.

If a distribution relies on external sources, which are not maintained
by the distribution, but a single person, it has been forked.

A healthy distribution needs to maintain its own tools.

-- 
Best,
Jonas



Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Jaco Kroon


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2020/09/16 11:39, Michał Górny wrote:

> On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
>>
>>> +- at most one  element containing
version
>>> +  constraints used to determine stabilization candidates, as detailed
>>> +  in `Stabilization candidates`_.
>>> +
>> At most one ...
>
> Do you mean capatilization?  It's following suit with other items here.
Sorry, was unclear, this correlates with the second comment below.
>>>  - zero or more  elements, possibly restricted
>>>    to specific package versions (at most one for each version) whose
presence
>>>    indicates that the appropriate ebuilds are suitable for
simultaneously
>>> @@ -199,6 +203,25 @@ The  element can contain the
following elements:
>>>  - at most one  element describing the role of
subslots (all
>>>    of them) as text.
>>>  
>>> +Stabilization candidates
>>> +
>>> +Each  element describes version
>>
>> vs each (implies any number).  I'd simply say, "If present, the
``
> Again, this follows suit with other descriptions.

If this is the standard, this is the standard, was just trying to point
out that this could be considered a conflict.

>>> +constraints used to determine package versions eligible
>>> +for stabilization.  Should this element be missing, the tooling assumes
>>> +a default of any version with any keywords present (i.e. the equivalent
>>> +of ``>=0``).
>>> +
>>> +The  element can contain the following
>>> +elements:
>>> +
>>> +- one or more  elements, each containing a version
>>> +  constraint in the format matching EAPI 0 dependency specification
>>> +  with the package category and name parts omitted, e.g. ``<1.7``.
>>> +  The tooling considers any ebuild version that satisfies the
constraint
>>> +  and has any keywords.  If multiple constraints are provided,
every one
>>> +  of them is matched separately, and multiple stabilization candidates
>>> +  can be reported.
>>
>> I think it's clear from context that there should be one or more, but
>> the language ("can contain" in the leading paragraph) implies all sub
>> elements are optional.  Perhaps:
>>
>> The ... element:
>>
>> - must contain one or more ...
>>
>> Which also allows for future "may contain" sub elements.
>>
>
> To be honest, I'm not sure if we should permit or prohibit empty element
> in the spec.

pick one.  But I'd use the word may (clearly optional) or must (clearly
compulsory) rather than can.

Kind Regards,
Jaco


-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl9h9YMACgkQCC3Esa/3
7p5XtQf9H6kcStCzBz75rOVhoswzhIafZWXJnurAYHvEvM3vrWrMzh46Bc3aZZLo
fo2+lg7Z9lw0iBxJjub/nexBR9D8XwCa3aW/G75Hgd5XcC54LfKRFGqGKHS9Zu9z
GT96Ijqo4aS2PlepD0Qk8jVTnngzB5opasH3nNgR2u6WSEQHtkCE8lg2A1Z0hr3i
PmO/kzvHnZxsais9wp7kkZn+ftGbI1Wuq6Gus3Yy3qWp2k6KTwD49VdN3y7Skk3s
T3ULl/+ui/FqwGGDjlQw0MW8o2mJ76VrQoMTiMG7IErFz9BzJ3djf/bgXg8YjHc5
kjo/h1tLcj7WvLphz9gdhGt4Sk85Sw==
=WdPf
-END PGP SIGNATURE-




Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Rich Freeman
On Wed, Sep 16, 2020 at 4:17 AM Kent Fredric  wrote:
>
> On Mon, 14 Sep 2020 10:15:31 -0400
> Rich Freeman  wrote:
>
> > It might be easier to take smaller steps, such as having a policy that
> > "any call for devs to use/test a new tool/service, or any service that
> > automatically performs transactions on bugzilla, must be FOSS, and the
> > link to the source must be included in the initial communication, and
> > it must be clear what version of the code is operating at any time."
> > That is a pretty low barrier to those creating tools, though it
> > doesn't address the infra concern.  However, it does mean that infra
> > is now free to fork the service at any time, and reduces the bus
> > factor greatly.
>
> For the situation of things that take life before being part of infra,
> I think the least we can do is recognize their utility and importance,
> and at least, have infra *offer* some sort of shared location to run a
> deployment.
>
> That I think helps everyone, gives people a place to remove their own
> bus factor, but without mandatory strongarming.

This might be one option.  Another might be to try to have a more
"open infra" approach where core services like authentication are
provided by Gentoo, but available to 3rd parties.  This could allow
more services to be externally hosted, ideally with redundancy (not
just at the host level, but at the maintainer/software level as well).
The obvious downside to this would be chaos - we might have 3 list
servers, 5 bug trackers, 10 git repos, and so on.  However, if
anything did go down we'd have half a dozen potential replacements so
all anybody needs to do is migrate their own stuff to their chosen
copy.

The value add of Gentoo would be in central services like
identity/reputation and curation.  There might be 14 git repos out
there but Gentoo would control which ones end up on the master rsync
server and which rsync mirrors get advertised as being genuine, and
which list servers are official.

I realize this is a bit more tangential.  I just think that infra is
already a huge failure point, so having more stuff on infra actually
makes that failure point more critical.  A Gentoo where little is
hosted on stuff we own is much more resilient in the face of
legal/money/etc issues.  If Gentoo just becomes some blessed config
files, a website, and SAML then anybody could host the core from their
basement.

Maybe it is a good thing that core services aren't always hosted by infra?

-- 
Rich



Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Michał Górny
On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
> Hi Michał,
> 
> Thanks for your efforts.  This looks interesting at the very least, and
> whilst in many cases on posts on this ML I'm on the "don't care" stance,
> this one looks like it could solve some problems for me. 
> net-misc/asterisk + friends will definitely make use of this.
> 
> Two nitpicks below that doesn't really carry significant meaning.
> 
> On 2020/09/16 07:48, Michał Górny wrote:
> 
> > Signed-off-by: Michał Górny 
> > ---
> >  glep-0068.rst | 62 ---
> >  1 file changed, 59 insertions(+), 3 deletions(-)
> > 
> > diff --git a/glep-0068.rst b/glep-0068.rst
> > index d8fc379..5b7e2b9 100644
> > --- a/glep-0068.rst
> > +++ b/glep-0068.rst
> > @@ -4,10 +4,10 @@ Title: Package and category metadata
> >  Author: Michał Górny 
> >  Type: Standards Track
> >  Status: Final
> > -Version: 1.1
> > +Version: 1.2
> >  Created: 2016-03-14
> > -Last-Modified: 2020-05-06
> > -Post-History: 2016-03-16, 2018-02-20
> > +Last-Modified: 2020-09-16
> > +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
> >  Content-Type: text/x-rst
> >  Requires: 67
> >  Replaces: 34, 46, 56
> > @@ -149,6 +149,10 @@ element can contain, in any order:
> >languages (at most one for each language), as detailed
> >in `Slot descriptions`_.
> >  
> > +- at most one  element containing version
> > +  constraints used to determine stabilization candidates, as detailed
> > +  in `Stabilization candidates`_.
> > +
> At most one ...

Do you mean capatilization?  It's following suit with other items here.

> >  - zero or more  elements, possibly restricted
> >to specific package versions (at most one for each version) whose 
> > presence
> >indicates that the appropriate ebuilds are suitable for simultaneously
> > @@ -199,6 +203,25 @@ The  element can contain the following 
> > elements:
> >  - at most one  element describing the role of subslots (all
> >of them) as text.
> >  
> > +Stabilization candidates
> > +
> > +Each  element describes version
> 
> vs each (implies any number).  I'd simply say, "If present, the `` 
> > +constraints used to determine package versions eligible
> > +for stabilization.  Should this element be missing, the tooling assumes
> > +a default of any version with any keywords present (i.e. the equivalent
> > +of ``>=0``).
> > +
> > +The  element can contain the following
> > +elements:
> > +
> > +- one or more  elements, each containing a version
> > +  constraint in the format matching EAPI 0 dependency specification
> > +  with the package category and name parts omitted, e.g. ``<1.7``.
> > +  The tooling considers any ebuild version that satisfies the constraint
> > +  and has any keywords.  If multiple constraints are provided, every one
> > +  of them is matched separately, and multiple stabilization candidates
> > +  can be reported.
> 
> I think it's clear from context that there should be one or more, but
> the language ("can contain" in the leading paragraph) implies all sub
> elements are optional.  Perhaps:
> 
> The ... element:
> 
> - must contain one or more ...
> 
> Which also allows for future "may contain" sub elements.
> 

To be honest, I'm not sure if we should permit or prohibit empty element
in the spec.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Jaco Kroon
Hi Michał,

Thanks for your efforts.  This looks interesting at the very least, and
whilst in many cases on posts on this ML I'm on the "don't care" stance,
this one looks like it could solve some problems for me. 
net-misc/asterisk + friends will definitely make use of this.

Two nitpicks below that doesn't really carry significant meaning.

On 2020/09/16 07:48, Michał Górny wrote:

> Signed-off-by: Michał Górny 
> ---
>  glep-0068.rst | 62 ---
>  1 file changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/glep-0068.rst b/glep-0068.rst
> index d8fc379..5b7e2b9 100644
> --- a/glep-0068.rst
> +++ b/glep-0068.rst
> @@ -4,10 +4,10 @@ Title: Package and category metadata
>  Author: Michał Górny 
>  Type: Standards Track
>  Status: Final
> -Version: 1.1
> +Version: 1.2
>  Created: 2016-03-14
> -Last-Modified: 2020-05-06
> -Post-History: 2016-03-16, 2018-02-20
> +Last-Modified: 2020-09-16
> +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
>  Content-Type: text/x-rst
>  Requires: 67
>  Replaces: 34, 46, 56
> @@ -149,6 +149,10 @@ element can contain, in any order:
>languages (at most one for each language), as detailed
>in `Slot descriptions`_.
>  
> +- at most one  element containing version
> +  constraints used to determine stabilization candidates, as detailed
> +  in `Stabilization candidates`_.
> +
At most one ...
>  - zero or more  elements, possibly restricted
>to specific package versions (at most one for each version) whose presence
>indicates that the appropriate ebuilds are suitable for simultaneously
> @@ -199,6 +203,25 @@ The  element can contain the following 
> elements:
>  - at most one  element describing the role of subslots (all
>of them) as text.
>  
> +Stabilization candidates
> +
> +Each  element describes version

vs each (implies any number).  I'd simply say, "If present, the `` +constraints used to determine package versions eligible
> +for stabilization.  Should this element be missing, the tooling assumes
> +a default of any version with any keywords present (i.e. the equivalent
> +of ``>=0``).
> +
> +The  element can contain the following
> +elements:
> +
> +- one or more  elements, each containing a version
> +  constraint in the format matching EAPI 0 dependency specification
> +  with the package category and name parts omitted, e.g. ``<1.7``.
> +  The tooling considers any ebuild version that satisfies the constraint
> +  and has any keywords.  If multiple constraints are provided, every one
> +  of them is matched separately, and multiple stabilization candidates
> +  can be reported.

I think it's clear from context that there should be one or more, but
the language ("can contain" in the leading paragraph) implies all sub
elements are optional.  Perhaps:

The ... element:

- must contain one or more ...

Which also allows for future "may contain" sub elements.

Kind Regards,
Jaco




[gentoo-dev] Last rites: packages only relevant to the already removed metasploit

2020-09-16 Thread Hans de Graaff
# Hans de Graaff  (2020-09-16)
# Dependencies of the already removed metasploit that are relevant
# only with metasploit. Masked for removal in 30 days.
dev-ruby/meterpreter_bins
dev-ruby/patch_finder
dev-ruby/rb-readline-r7


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Michał Górny
On Wed, 2020-09-16 at 10:26 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote:
> > It has two advantages:
> > 1. It reduces the risk of accidentally leaving it in the stable ebuild.
> 
> Huh, you mean you would remove the PROPERTIES token again, after the
> version has been stabilised? Why?

No, I mean removing it when bumping from version unsuitable to
be a stable candidate to one that is suitable.  What's really
problematic is that this mistake will be easy to miss, especially if
someone relies on pkgcheck entirely to determine when to stabilize
stuff.

> 
> Ebuilds could do conditionals like this (again, an example that would
> work for app-editors/emacs):
> 
> [[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"

Yes, provided that developers will actually do that.

> > 2. It handles specifying multiple stabilization candidates on different
> > branches.  I don't see how ebuilds would do that.
> 
> I don't understand. Why couldn't PROPERTIES be specified in different
> slots?
> 

How would you distinguish the ebuild group that represent the same
upstream branch (i.e. expecting only one report from the group) from
other upstream branches?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Ulrich Mueller
> On Wed, 16 Sep 2020, Michał Górny wrote:

> It has two advantages:

> 1. It reduces the risk of accidentally leaving it in the stable ebuild.

Huh, you mean you would remove the PROPERTIES token again, after the
version has been stabilised? Why?

Ebuilds could do conditionals like this (again, an example that would
work for app-editors/emacs):

[[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"

> 2. It handles specifying multiple stabilization candidates on different
> branches.  I don't see how ebuilds would do that.

I don't understand. Why couldn't PROPERTIES be specified in different
slots?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Kent Fredric
On Mon, 14 Sep 2020 10:15:31 -0400
Rich Freeman  wrote:

> It might be easier to take smaller steps, such as having a policy that
> "any call for devs to use/test a new tool/service, or any service that
> automatically performs transactions on bugzilla, must be FOSS, and the
> link to the source must be included in the initial communication, and
> it must be clear what version of the code is operating at any time."
> That is a pretty low barrier to those creating tools, though it
> doesn't address the infra concern.  However, it does mean that infra
> is now free to fork the service at any time, and reduces the bus
> factor greatly.

For the situation of things that take life before being part of infra,
I think the least we can do is recognize their utility and importance,
and at least, have infra *offer* some sort of shared location to run a
deployment.

That I think helps everyone, gives people a place to remove their own
bus factor, but without mandatory strongarming.


pgpJ3wCEsqaTS.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Michał Górny
On Wed, 2020-09-16 at 08:18 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote:
>  
> > +- one or more  elements, each containing a version
> > +  constraint in the format matching EAPI 0 dependency specification
> > +  with the package category and name parts omitted, e.g. ``<1.7``.
> 
> That's not a very powerful syntax, so unless I miss something,
> metadata.xml would have to be updated for almost every stable candidate.
> 
> To give an example, released versions of app-editors/emacs have exactly
> two numerical components, while prereleases and release candidates have
> three components or are marked _rc. Both would be impossible to match
> with the proposed syntax.

It's not 'one size fits all'.  It will work for a number of packages,
e.g. XFCE without too frequent updates.  In the end, it's primarily
designed around 'silencing' StableRequest results once they are
reported, i.e. for packages that have long-ish RC periods.

> So IMHO this has no advantage over keeping the information in the ebuild
> (e.g. as a PROPERTIES token).
> 

It has two advantages:

1. It reduces the risk of accidentally leaving it in the stable ebuild.

2. It handles specifying multiple stabilization candidates on different
branches.  I don't see how ebuilds would do that.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Ulrich Mueller
> On Wed, 16 Sep 2020, Michał Górny wrote:
 
> +- one or more  elements, each containing a version
> +  constraint in the format matching EAPI 0 dependency specification
> +  with the package category and name parts omitted, e.g. ``<1.7``.

That's not a very powerful syntax, so unless I miss something,
metadata.xml would have to be updated for almost every stable candidate.

To give an example, released versions of app-editors/emacs have exactly
two numerical components, while prereleases and release candidates have
three components or are marked _rc. Both would be impossible to match
with the proposed syntax.

So IMHO this has no advantage over keeping the information in the ebuild
(e.g. as a PROPERTIES token).

Ulrich


signature.asc
Description: PGP signature