Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
> On Tue, 05 Oct 2021, Alec Warner wrote: > I'd argue we can add NOTES.md to packages (e.g. allow those files.) > Then we modify packages.gentoo.org to render the markdown; or users > can render locally or read unrendered. How would you deal with translations? One NOTES file for every language? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
> On Tue, 05 Oct 2021, Sam James wrote:
> +Notes element
> +~
> +
> +The element describes important information on how to maintain
> +a package.
> +
> +The element has an obligatory ``type=""`` attribute whose value
> is
> +can be either ``text`` or ``url``. If its value is ``text``, then the
Too many verbs ("is can be") in this sentence.
> + value is formed of multi-line text. If its value is ``url``, the
> + value should be a link to a page containing information on how
> +to correct maintain the package.
Since this is plain text, it presumably should have an optional "lang"
attribute for consistency with other elements.
Ulrich
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
> On Tue, 05 Oct 2021, Michał Górny wrote: > On Tue, 2021-10-05 at 19:27 +0100, Sam James wrote: >> This is a preliminary version/draft of a proposed change to >> GLEP 68. >> >> I'd like to introduce a method for developers to signal anything >> special about a package and how to correctly maintain it. >> >> Sam James (1): >> glep-0068: Add notes element for package maintenance instructions >> >> glep-0068.rst | 26 +++--- >> 1 file changed, 23 insertions(+), 3 deletions(-) > To be honest, I don't think adding it to metadata.xml is a good idea. > This is not something that's going to be machine-parseable, > and expecting people to look into metadata.xml to see if it's even > present is a bit much. The same argument would apply to longdescription. > Maybe we could just add README files to the package directories > in question. This would have the clear advantage that the files will be > immediately visible. Scattering a package's metadata across multiple files doesn't look like a good idea to me. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, Oct 5, 2021 at 1:31 AM Michał Górny wrote: > > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > > Roughly, the idea is that: > > - master becomes 3.1.x, and primary development happens there > > - 3.0.x becomes the LTS branch and only major bugfixes are backported > there > > As things settle down in the future, master would become 3.2.x, 3.1.x > would become LTS, 3.0.x will be discontinued and so on. I'd appreciate a brief overview of how we would expect users to install each branch. E.g. one way might be: sys-apps/portage- # dev branch sys-apps/portage-3.1.x # LTS branch sys-apps/portage-3.0.x # old branch; unmaintained -A > > WDYT? > > -- > Best regards, > Michał Górny > > >
Re: [gentoo-dev] Package up for grabs: app-text/mupdf
I can proxy-maint this if no real devs want it El mar., 5 de octubre de 2021 10:23 p. m., Sam James escribió: > Hi, > > Putting app-text/mupdf up for grabs because I've not used it for a while. > > It needs a version bump (1.19.0) and some minor patches rebasing. > > Please note that anyone taking this over should keep an eye on upstream's > git occasionally to look for security relevant patches. > > Best, > sam >
[gentoo-dev] Package up for grabs: app-text/mupdf
Hi, Putting app-text/mupdf up for grabs because I've not used it for a while. It needs a version bump (1.19.0) and some minor patches rebasing. Please note that anyone taking this over should keep an eye on upstream's git occasionally to look for security relevant patches. Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
On 10/5/2021 16:29, Alec Warner wrote: > I thought we were going to go with the github-pages type route > (markdown, rendered online or locally.) > > -A > > On Tue, Oct 5, 2021 at 11:28 AM Sam James wrote: >> >> This is a preliminary version/draft of a proposed change to >> GLEP 68. >> >> I'd like to introduce a method for developers to signal anything >> special about a package and how to correctly maintain it. >> >> Sam James (1): >> glep-0068: Add notes element for package maintenance instructions >> >> glep-0068.rst | 26 +++--- Or perhaps we could use RST formatting like the GLEP source there to keep the plain text form readable, but also support visual rendering into HTML if needed? >> 1 file changed, 23 insertions(+), 3 deletions(-) >> >> -- >> 2.33.0 >> -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
> > I generally agree that comments are more visible/noticeable than > metadata, however, I also think that this could be a good step forward > for overall maintainability. The issue with documenting these things > in comments is that the comment lives only within the specific version > of the ebuild in which it is authored: it is up to the maintainer to > carry those comments over when version bumping. While this is > generally not a problem due to copy/paste, I think it is messy - there > could be an update to the comment from one version to the next, > meaning I now have two version of the comment floating around. > > With , there is one localized "source of truth" for this > documentation, which should remove any ambiguity. > > I would hope that after launching the feature, there would be > a gradual (or sudden?!) shift away from the current comments towards > the tag, maybe even including this in the dev manual. > That makes no sense, since the notes could be version-dependent. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item
> On 5 Oct 2021, at 18:43, Mike Gilbert wrote: > > Signed-off-by: Mike Gilbert > --- > .../2021-10-08-openssh-rsa-sha1.en.txt| 26 +++ > 1 file changed, 26 insertions(+) > create mode 100644 > 2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt > > diff --git a/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt > b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt > new file mode 100644 > index 000..cfdcc4a > --- /dev/null > +++ b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt > @@ -0,0 +1,26 @@ > +Title: OpenSSH RSA SHA-1 signatures > +Author: Mike Gilbert > +Posted: 2021-10-08 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: net-misc/openssh > + > +As of version 8.8, OpenSSH disables RSA signatures using the SHA-1 > +hash algorithm by default. This change affects both the client and > +server components. lgtm signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
On Tue, Oct 5, 2021 at 1:36 PM Sam James wrote: > > > > > On 5 Oct 2021, at 21:29, Alec Warner wrote: > > > > I thought we were going to go with the github-pages type route > > (markdown, rendered online or locally.) > > > > So, the thinking was, we could allow somewhat shorthand > notes or for the people who want to invest more time, allow > the GitHub-pages type route. > > But I'm open to the idea of just recommending people > use that if there's no appetite for mixed types. I'd argue we can add NOTES.md to packages (e.g. allow those files.) Then we modify packages.gentoo.org to render the markdown; or users can render locally or read unrendered. WDYT? -A > > > -A > > > > On Tue, Oct 5, 2021 at 11:28 AM Sam James wrote: > >> > >> This is a preliminary version/draft of a proposed change to > >> GLEP 68. > >> > >> I'd like to introduce a method for developers to signal anything > >> special about a package and how to correctly maintain it. > >> > >> Sam James (1): > >> glep-0068: Add notes element for package maintenance instructions > >> > >> glep-0068.rst | 26 +++--- > >> 1 file changed, 23 insertions(+), 3 deletions(-) > >> > >> -- > >> 2.33.0 > >> > >> > > >
Re: [gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item
On Tue, Oct 5, 2021 at 4:22 PM Aaron W. Swenson wrote: > > > I think it may be helpful to include the specific file(s) those > options > need to be added and to clarify whether they need to be added to > the > server host or the clients. > > Perhaps like so: > > hashes may be re-enabled on the server by adding the following > config > options to the end of /etc/ssh/sshd_confg: I considered something similar, but decided that I don't really want to do that level of hand-holding. Re-enabling ssh-rsa should be a seldom-used workaround. I feel like people can read the manual if they really need to enable them. The point of the news item is really to alert folks so they don't spend hours scratching their heads over it.
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Mon, Oct 4, 2021 at 2:48 AM Michał Górny wrote: > > On Tue, 2021-09-28 at 17:36 +0200, Michał Górny wrote: > > I know I'm going to regret asking this... but I've prepared a change to > > the Portage output format and I think it asks for a wider discussion > > than internally in Portage team. > > As I suspected, I truly regret sending this mail. I'm dangerously close > to burning out, so I'm going to retract these patches. When you decide > what you want and make patches for it, feel free to send them to > Portage. Keep in mind that while distributing patches and soliciting comments is a good practice, I don't believe any of our policies REQUIRE that you: 1. Reply to anybody who comments. 2. Address any comments. 3. Wait until anybody (let alone everybody) agrees before proceeding. I think that we sometimes let the requirement to communicate somehow stifle the desire to get things done. While I don't recommend it, you can technically satisfy any communications requirements by posting your patch and literally never checking your email before committing it. Obviously if you mess something up in doing so you'll look dumb, but it isn't intended to be a bureaucratic requirement. I suggest just skimming the comments to see if there is anything that seems like a good idea, then implementing those ideas (which you'll probably want to do anyway), and ignore the rest without comment. If somebody has a problem with what you're doing, the onus is on them to go find somebody to complain to in order to stop you. If you're the maintainer then you don't need permission to commit. In my experience the Council is fairly resistant to requests to meddle for things that aren't super-critical, so I'd be shocked if they didn't just ack and dismiss any request to bikeshed exactly what prefix your elog output uses. Open to contrary opinions, but IMO I think maintainers perceive that the distro is more consensus-driven than it actually is. You don't have to "win" the email battle. -- Rich
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
> On 5 Oct 2021, at 21:29, Alec Warner wrote: > > I thought we were going to go with the github-pages type route > (markdown, rendered online or locally.) > So, the thinking was, we could allow somewhat shorthand notes or for the people who want to invest more time, allow the GitHub-pages type route. But I'm open to the idea of just recommending people use that if there's no appetite for mixed types. > -A > > On Tue, Oct 5, 2021 at 11:28 AM Sam James wrote: >> >> This is a preliminary version/draft of a proposed change to >> GLEP 68. >> >> I'd like to introduce a method for developers to signal anything >> special about a package and how to correctly maintain it. >> >> Sam James (1): >> glep-0068: Add notes element for package maintenance instructions >> >> glep-0068.rst | 26 +++--- >> 1 file changed, 23 insertions(+), 3 deletions(-) >> >> -- >> 2.33.0 >> >> > signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
I thought we were going to go with the github-pages type route (markdown, rendered online or locally.) -A On Tue, Oct 5, 2021 at 11:28 AM Sam James wrote: > > This is a preliminary version/draft of a proposed change to > GLEP 68. > > I'd like to introduce a method for developers to signal anything > special about a package and how to correctly maintain it. > > Sam James (1): > glep-0068: Add notes element for package maintenance instructions > > glep-0068.rst | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) > > -- > 2.33.0 > >
Re: [gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item
I think it may be helpful to include the specific file(s) those options need to be added and to clarify whether they need to be added to the server host or the clients. Perhaps like so: hashes may be re-enabled on the server by adding the following config options to the end of /etc/ssh/sshd_confg: WKR, Aaron Mike Gilbert writes: Signed-off-by: Mike Gilbert --- .../2021-10-08-openssh-rsa-sha1.en.txt| 26 +++ 1 file changed, 26 insertions(+) create mode 100644 2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt diff --git a/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt new file mode 100644 index 000..cfdcc4a --- /dev/null +++ b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt @@ -0,0 +1,26 @@ +Title: OpenSSH RSA SHA-1 signatures +Author: Mike Gilbert +Posted: 2021-10-08 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/openssh + +As of version 8.8, OpenSSH disables RSA signatures using the SHA-1 +hash algorithm by default. This change affects both the client and +server components. + +After upgrading to this version, you may have trouble connecting to +older SSH servers that do not support the newer RSA/SHA-256/SHA-512 +signatures. Support for these signatures was added in OpenSSH 7.2. + +As well, you may have trouble using older SSH clients to connect to a +server running OpenSSH 8.8 or higher. Some older clients do not +automatically utilize the newer hashes. For example, PuTTY before +version 0.75 is affected. + +To resolve these problems, please upgrade your SSH client/server +whereever possible. If this is not feasible, support for the SHA-1 +hashes may be re-enabled using the following config options: + +HostkeyAlgorithms +ssh-rsa +PubkeyAcceptedAlgorithms +ssh-rsa -- Reservations and Reporting Technologist Great Smoky Mountains Railroad PO Box 1490 Bryson City, NC 28713 D: 828-488-7013 M: 800-872-4681 x 214 F: 828-488-0427 P: 9B32 F2A4 8C1F F4E0 1E23 CEEA 2153 C852 F779 174F signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
> Maybe we could just add README files to the package directories > in question. This would have the clear advantage that the files will be > immediately visible. > I'll personally prefer a readme. Also almost all metadata.xml features are underused >
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 10/2/21 10:51 AM, Mike Gilbert wrote: > On Sat, Oct 2, 2021 at 1:25 PM A Schenck wrote: >> Further discussion belongs on a different list, but the link provided by >> mgorny and repeated by you does not allow collaborating in compliance >> with the Gentoo Social Contract. > The patches were also posted for review on the gentoo-portage-dev mailing > list. Thanks. The patch is a bit messier than hoped but it's a starting point. OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
On Tue, Oct 5, 2021 at 3:10 PM Mike Gilbert wrote: > > On Tue, Oct 5, 2021 at 2:27 PM Sam James wrote: > > > > This adds a new '' element to allow maintainers to describe > > package-specific quirks or other instructions on how to correctly > > maintain a package. This is intended to encourage developers to document > > knowledge and increase the bus-factor of packages which are delicate > > but must live beyond a maintainer. > > Personally, I am much more likely to notice a comment at the top of > the ebuild than a new element in metadata.xml. I generally agree that comments are more visible/noticeable than metadata, however, I also think that this could be a good step forward for overall maintainability. The issue with documenting these things in comments is that the comment lives only within the specific version of the ebuild in which it is authored: it is up to the maintainer to carry those comments over when version bumping. While this is generally not a problem due to copy/paste, I think it is messy - there could be an update to the comment from one version to the next, meaning I now have two version of the comment floating around. With , there is one localized "source of truth" for this documentation, which should remove any ambiguity. I would hope that after launching the feature, there would be a gradual (or sudden?!) shift away from the current comments towards the tag, maybe even including this in the dev manual.
Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
On Tue, Oct 5, 2021 at 2:27 PM Sam James wrote: > > This adds a new '' element to allow maintainers to describe > package-specific quirks or other instructions on how to correctly > maintain a package. This is intended to encourage developers to document > knowledge and increase the bus-factor of packages which are delicate > but must live beyond a maintainer. Personally, I am much more likely to notice a comment at the top of the ebuild than a new element in metadata.xml.
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
On Tue, 2021-10-05 at 19:27 +0100, Sam James wrote: > This is a preliminary version/draft of a proposed change to > GLEP 68. > > I'd like to introduce a method for developers to signal anything > special about a package and how to correctly maintain it. > > Sam James (1): > glep-0068: Add notes element for package maintenance instructions > > glep-0068.rst | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) > To be honest, I don't think adding it to metadata.xml is a good idea. This is not something that's going to be machine-parseable, and expecting people to look into metadata.xml to see if it's even present is a bit much. Maybe we could just add README files to the package directories in question. This would have the clear advantage that the files will be immediately visible. -- Best regards, Michał Górny
[gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
This adds a new '' element to allow maintainers to describe package-specific quirks or other instructions on how to correctly maintain a package. This is intended to encourage developers to document knowledge and increase the bus-factor of packages which are delicate but must live beyond a maintainer. Signed-off-by: Sam James --- glep-0068.rst | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/glep-0068.rst b/glep-0068.rst index 83e54d9..21bdf2a 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: 2021-09-11 -Post-History: 2016-03-16, 2018-02-20 +Last-Modified: 2021-10-05 +Post-History: 2016-03-16, 2018-02-20, 2021-10-05 Content-Type: text/x-rst Requires: 67 Replaces: 34, 46, 56 @@ -160,6 +160,8 @@ element can contain, in any order: in different languages (at most one for each language), as detailed in `USE flag descriptions`_. +- at most one element containing notes on maintenance. + - at most one element providing information on upstream of the package, as detailed in `Upstream descriptions`_. @@ -213,6 +215,18 @@ The element can contain the following elements: which the description applies, and contains text, optionally interspersed with and elements. +Notes element +~ + +The element describes important information on how to maintain +a package. + +The element has an obligatory ``type=""`` attribute whose value is +can be either ``text`` or ``url``. If its value is ``text``, then the + value is formed of multi-line text. If its value is ``url``, the + value should be a link to a page containing information on how +to correct maintain the package. + Upstream descriptions ~ The element provides information on the upstream of a package. @@ -484,6 +498,12 @@ Example metadata.xml file Konfiguriert das Paket mit Unterstützung für bar (benötigt dev-libs/bar) Konfiguriert das Paket mit Unterstützung für bar + + Almost every release involves checking a diff of the build system. + Be careful of bundled libfoo which sometimes has custom modifications. + Versioning scheme is unusual. + Track record of ABI breaks within minor releases: check! + upstr...@example.com -- 2.33.0
[gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
This is a preliminary version/draft of a proposed change to GLEP 68. I'd like to introduce a method for developers to signal anything special about a package and how to correctly maintain it. Sam James (1): glep-0068: Add notes element for package maintenance instructions glep-0068.rst | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) -- 2.33.0
[gentoo-dev] [PATCH] 2021-10-08-openssh-rsa-sha1: add news item
Signed-off-by: Mike Gilbert --- .../2021-10-08-openssh-rsa-sha1.en.txt| 26 +++ 1 file changed, 26 insertions(+) create mode 100644 2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt diff --git a/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt new file mode 100644 index 000..cfdcc4a --- /dev/null +++ b/2021-10-08-openssh-rsa-sha1/2021-10-08-openssh-rsa-sha1.en.txt @@ -0,0 +1,26 @@ +Title: OpenSSH RSA SHA-1 signatures +Author: Mike Gilbert +Posted: 2021-10-08 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: net-misc/openssh + +As of version 8.8, OpenSSH disables RSA signatures using the SHA-1 +hash algorithm by default. This change affects both the client and +server components. + +After upgrading to this version, you may have trouble connecting to +older SSH servers that do not support the newer RSA/SHA-256/SHA-512 +signatures. Support for these signatures was added in OpenSSH 7.2. + +As well, you may have trouble using older SSH clients to connect to a +server running OpenSSH 8.8 or higher. Some older clients do not +automatically utilize the newer hashes. For example, PuTTY before +version 0.75 is affected. + +To resolve these problems, please upgrade your SSH client/server +whereever possible. If this is not feasible, support for the SHA-1 +hashes may be re-enabled using the following config options: + +HostkeyAlgorithms +ssh-rsa +PubkeyAcceptedAlgorithms +ssh-rsa -- 2.33.0
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 13:16 -0400, Michael Orlitzky wrote: > On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote: > > > > > 2. What happens to the LTS branch when the next EAPI is released? > > > > > > > I haven't really thought about it. Are you suggesting that we could > > bump 'master' Portage to newer EAPI earlier or...? > > > > I just mean that, a priori, the LTS branch won't be able to install > ebuilds that use the next EAPI. Backporting an entire EAPI doesn't seem > appropriate for a stable series; but maintaining an increasingly- > obsolete branch at that point doesn't make much sense either. Ah, that makes sense. Indeed, I suppose a new EAPI will be a good point of switching master to LTS. -- Best regards, Michał Górny
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote: > > > 2. What happens to the LTS branch when the next EAPI is released? > > > > I haven't really thought about it. Are you suggesting that we could > bump 'master' Portage to newer EAPI earlier or...? > I just mean that, a priori, the LTS branch won't be able to install ebuilds that use the next EAPI. Backporting an entire EAPI doesn't seem appropriate for a stable series; but maintaining an increasingly- obsolete branch at that point doesn't make much sense either.
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 10:15 -0400, Michael Orlitzky wrote: > On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote: > > Hi, everyone. > > > > I've been thinking about this for some time already, and the recent > > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > > branch of Portage. > > > > I think this is healthy for most software projects, but two things > stand out to me for portage specifically: > > 1. Most portage users can fake this already by telling portage to > accept only stable keywords for sys-apps/portage. I know it's not > exactly the same, but it provides many of the same benefits. That's not going to be possible long-term when I start making more changes ;-). > 2. What happens to the LTS branch when the next EAPI is released? > I haven't really thought about it. Are you suggesting that we could bump 'master' Portage to newer EAPI earlier or...? -- Best regards, Michał Górny
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > I think this is healthy for most software projects, but two things stand out to me for portage specifically: 1. Most portage users can fake this already by telling portage to accept only stable keywords for sys-apps/portage. I know it's not exactly the same, but it provides many of the same benefits. 2. What happens to the LTS branch when the next EAPI is released?
Re: [gentoo-dev] Packages up for grabs: misc packages from chainsaw@
On 2021-10-05 05:04, Sam James wrote: Hi all, Chainsaw asked retirement@ to drop him to maintainer-needed on his packages, so here's the resultant packages with no maintainers left: app-admin/ansible-lint > dev-python/requests-credssp I'll take these. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: misc packages from chainsaw@
Hi, On 2021/10/05 05:04, Sam James wrote: > Hi all, > > Chainsaw asked retirement@ to drop him to maintainer-needed on his packages, > so here's the resultant > packages with no maintainers left: That's a shame. Big loss. > app-arch/rpm createrepo_c depends on this, willing to grab it purely for that. rpmdevtools is the other big consumer - kensington - you willing to handle this one? > net-libs/iax I believe this can be last rited. This is a voice package but I can't find consumers, nor does it look useful as is (no .so being installed, and otherwise it's just a pkg-config style iax-config, but references not-installed libiax). I thus believe the package looks to be broken. Adding last-rite. > net-misc/astmanproxy Potentially useful. Will look into this. For now I'll mark myself as proxymaintainer. If someone else wants to grab instead, please feel free to do so. I may end up last-riting this, so if there are users of this, please let me know, or just grab the package. > net-misc/bgpq3 > net-misc/stuntman Will take these. May want to consider replacing bgpq3 with bgpq4 regardless. https://github.com/gentoo/gentoo/pull/22494 Kind Regards, Jaco
Re: [gentoo-portage-dev] [RFC] LTS branch of Portage
In all fairness, there haven't been that much incidents with Portage in the past under Zac's supervision, isn't it a bit overkill to bureaucratise the release model just after one incident? It appears to me that changes to Portage need to be considered very carefully, always, since it affects everyone. Thanks, Fabian On 05-10-2021 10:31:40 +0200, Michał Górny wrote: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > > Roughly, the idea is that: > > - master becomes 3.1.x, and primary development happens there > > - 3.0.x becomes the LTS branch and only major bugfixes are backported > there > > As things settle down in the future, master would become 3.2.x, 3.1.x > would become LTS, 3.0.x will be discontinued and so on. > > WDYT? > > -- > Best regards, > Michał Górny > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-portage-dev] [RFC] LTS branch of Portage
Hi, everyone. I've been thinking about this for some time already, and the recent FILESDIR mess seems to confirm it: I'd like to start a more stable LTS branch of Portage. Roughly, the idea is that: - master becomes 3.1.x, and primary development happens there - 3.0.x becomes the LTS branch and only major bugfixes are backported there As things settle down in the future, master would become 3.2.x, 3.1.x would become LTS, 3.0.x will be discontinued and so on. WDYT? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 05-10-2021 09:35:32 +0200, Michał Górny wrote: > On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote: > > > > Final question, am I understanding correctly that normal lines are not > > > > prefixed with something? Would it be, for consistency, alignment, and > > > > certainty of selecting rows something to use a prefix for those lines > > > > too (assuming they aren't at this point)? > > > > > > I don't know, we've never done that. I suppose it would be possible but > > > it is even more controversial and unlike the proposed changes, it would > > > actually require mangling the process output. > > > > If I remember correctly, Portage already does. In which case, doing > > this (even if it were adding leading spaces) would not be that much > > work? > > > > I'm afraid this is not that simple. You need to account for all escape > sequences that can affect editing already output data including clean > handling of line wrapping. In the end, we'd have to have a complete > detachtty-class terminal emulator inside Portage. Fair enough, thanks for looking into it. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote: > > > Final question, am I understanding correctly that normal lines are not > > > prefixed with something? Would it be, for consistency, alignment, and > > > certainty of selecting rows something to use a prefix for those lines > > > too (assuming they aren't at this point)? > > > > I don't know, we've never done that. I suppose it would be possible but > > it is even more controversial and unlike the proposed changes, it would > > actually require mangling the process output. > > If I remember correctly, Portage already does. In which case, doing > this (even if it were adding leading spaces) would not be that much > work? > I'm afraid this is not that simple. You need to account for all escape sequences that can affect editing already output data including clean handling of line wrapping. In the end, we'd have to have a complete detachtty-class terminal emulator inside Portage. -- Best regards, Michał Górny
