Re: [gentoo-dev] [PATCH] glep-0068: Add new element
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] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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
> 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] [PATCH] glep-0068: Add new element
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
[gentoo-dev] Last rites: packages only relevant to the already removed metasploit
# 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
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
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
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] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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
-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
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] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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] How to stabilize packages with frequent release cycles?
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
[gentoo-dev] Last rites: sci-chemistry/ortep3
# 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
[gentoo-dev] Last rites: app-admin/recursos
# 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
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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
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
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] Last rites: sci-chemistry/ortep3
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
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
[gentoo-dev] Last rites: various old dev-ruby/* packages
# Hans de Graaff (2020-09-17) # Mask old unmaintained or obsolete ruby packages for removal in 30 # days. # No longer maintained upstream, ruby27 issues, no deps dev-ruby/bluecloth # No longer maintained upstream, no deps dev-ruby/calendar_date_select # Obsolete, no deps dev-ruby/capistrano-stats # No longer maintained, git snapshot from 2013, no deps dev-ruby/expression_parser # No longer needed, no deps dev-ruby/hoe-seattlerb # No longer maintained upstream, ruby27 issues, no deps dev-ruby/inifile # Obsolete (merged into rails 4) dev-ruby/journey # No longer maintained, ruby27 issues, no deps dev-ruby/rgen # No longer maintained, no deps dev-ruby/ruby_dep signature.asc Description: This is a digitally signed message part
