Am Montag, 5. August 2024, 00:39:13 CEST schrieb Robin H. Johnson:
> > Step 2: Formally introduce the new keywords in ebuilds by duplication.
> > Any "ppc64" in keywords becomes "ppc64 ppc64le".
> > Any "riscv" becomes "riscv riscv32 riscv64".
> > No exceptions. Can be done automatically. Until th
> On Sun, 04 Aug 2024, Andreas K Huettel wrote:
> Step 4: Prepare and publish a migration guide for users.
> Right now I assume this will mostly mean "select new profile". However,
> I have no clue how portage reacts when $ARCH changes.
Presumably this will also require eselect to be updated
On Sun, Aug 04, 2024 at 08:30:57PM +0200, Andreas K. Huettel wrote:
> Hi Arthur,
>
> > a. Splitting ppc64 keyword into ppc64 and ppc64le
>
> > b. Splitting riscv keyword into riscv(64?) and riscv32
...
> Step 2: Formally introduce the new keywords in ebuilds by duplication.
> Any "ppc64" in keyw
Hi Arthur,
> a. Splitting ppc64 keyword into ppc64 and ppc64le
> b. Splitting riscv keyword into riscv(64?) and riscv32
So in principle these steps both make sense.
The problem is mostly that such an operation on the living Gentoo
has not been attempted in recorded history. There is no precede
On 2024-08-02 15:05, Arthur Zamarin wrote:
Hi all
As continuation from previous arch changes and arch status [1], I want
to propose the next arch change for the near council meeting:
a. Splitting ppc64 keyword into ppc64 and ppc64le
Currently the ppc64 arch keyword matches both big endian (ppc
Hi all
As continuation from previous arch changes and arch status [1], I want
to propose the next arch change for the near council meeting:
a. Splitting ppc64 keyword into ppc64 and ppc64le
Currently the ppc64 arch keyword matches both big endian (ppc64ul) and
little endian (ppc64le). While ther
On Sun, 2023-09-24 at 23:14 +0530, Siddhanth Rathod wrote:
> How does modifying the DTD with a git hook sound ?
That could work if we put the DTD, XML schema, and RELAX NG schema all
in the repo metadata. The remaining projects are programs and (given
access to ::gentoo) can probably parse the lis
How does modifying the DTD with a git hook sound ?
On 9/23/23 20:17, Michael Orlitzky wrote:
On Sat, 2023-09-23 at 15:39 +0100, Sam James wrote:
At the moment, we bundle the DTD in pkgcore. If we just shoved it in
metadata/ instead in the main repo, we don't have that kind of problem.
I might
On Sat, Sep 23, 2023 at 03:39:32PM +0100, Sam James wrote:
>
> Michael Orlitzky writes:
>
> > On Sat, 2023-09-23 at 00:10 +0530, Siddhanth Rathod wrote:
> >>
> >> By establishing a universal remote-ID file, we can streamline this
> >> process. Your thoughts and feedback on this proposal would
On Sat, 2023-09-23 at 15:39 +0100, Sam James wrote:
>
> At the moment, we bundle the DTD in pkgcore. If we just shoved it in
> metadata/ instead in the main repo, we don't have that kind of problem.
>
I might be missing something obvious, but what I mean is, suppose we
have this plain-text mappi
Michael Orlitzky writes:
> On Sat, 2023-09-23 at 00:10 +0530, Siddhanth Rathod wrote:
>>
>> By establishing a universal remote-ID file, we can streamline this
>> process. Your thoughts and feedback on this proposal would be greatly
>> appreciated.Also, Any preferences on format?
>
> Building
On Sat, 2023-09-23 at 00:10 +0530, Siddhanth Rathod wrote:
>
> By establishing a universal remote-ID file, we can streamline this
> process. Your thoughts and feedback on this proposal would be greatly
> appreciated.Also, Any preferences on format?
Building the wiki page isn't too hard, but wha
Ulrich Mueller writes:
> [[PGP Signed Part:Undecided]]
>> On Fri, 22 Sep 2023, Siddhanth Rathod wrote:
>
>> I'm writing to propose the creation of a universal remote-ID file
>> within the api.git or gentoo.git in the metadata/ directory.
>> Currently, we have eight different locations that r
> On Fri, 22 Sep 2023, Siddhanth Rathod wrote:
> I'm writing to propose the creation of a universal remote-ID file
> within the api.git or gentoo.git in the metadata/ directory.
> Currently, we have eight different locations that require manual
> updates for any future changes, including my re
I'm writing to propose the creation of a universal remote-ID file within
the api.git or gentoo.git in the metadata/ directory. Currently, we have
eight different locations that require manual updates for any future
changes, including my recent commit
(https://gitweb.gentoo.org/proj/gentoolkit.g
On 17/06/2022 18.27, William Hubbs wrote:
On Mon, Jun 13, 2022 at 12:26:43PM +0200, Ulrich Mueller wrote:
On Mon, 13 Jun 2022, Florian Schmaus wrote:
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
where some voices where in agreement that EGO_SUM has its raison d'être
On Sat, Oct 01, 2022 at 07:21:13PM +0200, Florian Schmaus wrote:
> On 01/10/2022 18.36, Ulrich Mueller wrote:
> >> On Sat, 01 Oct 2022, Florian Schmaus wrote:
> >
> >> Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It
> >> appears that the ebuild had more than 6000 entries i
On 01/10/2022 18.36, Ulrich Mueller wrote:
On Sat, 01 Oct 2022, Florian Schmaus wrote:
Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It
appears that the ebuild had more than 6000 entries in SRC_URI [1],
That includes double counting and must be divided by the number of
de
> On Sat, 01 Oct 2022, Florian Schmaus wrote:
> Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It
> appears that the ebuild had more than 6000 entries in SRC_URI [1],
That includes double counting and must be divided by the number of
developers in TEXLIVE_DEVS. AFAICS that
On 30/09/2022 21.49, Alec Warner wrote:
On Fri, Sep 30, 2022 at 7:53 AM Florian Schmaus wrote:
And quite frankly, I don't see a problem with "large" Manifests and/or
ebuilds. Yes, it means our FTPs are hosting many files, in some cases
even many small files. And yes, it means that in some cases
On Fri, Sep 30, 2022 at 12:49:02PM -0700, Alec Warner wrote:
> On Fri, Sep 30, 2022 at 7:53 AM Florian Schmaus wrote:
> >
> > On 30/09/2022 02.36, William Hubbs wrote:
> > > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote:
> > >>> On Wed, 28 Sep 2022, Florian Schmaus wrote:
> >
On Fri, Sep 30, 2022 at 10:07:44PM +0200, Arsen Arsenović wrote:
> Hey,
>
> On Friday, 30 September 2022 02:36:05 CEST William Hubbs wrote:
> > I don't know for certain about a vendor tarball, but I do know there
> > are instances where a vendor tarball wouldn't work.
> > app-containers/containerd
Hey,
On Friday, 30 September 2022 02:36:05 CEST William Hubbs wrote:
> I don't know for certain about a vendor tarball, but I do know there
> are instances where a vendor tarball wouldn't work.
> app-containers/containerd is a good example of this, That is why the
> vendor tarball idea was dropped
On Fri, Sep 30, 2022 at 7:53 AM Florian Schmaus wrote:
>
> On 30/09/2022 02.36, William Hubbs wrote:
> > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote:
> >>> On Wed, 28 Sep 2022, Florian Schmaus wrote:
> >>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer
> On 30 Sep 2022, at 15:53, Florian Schmaus wrote:
>
> On 30/09/2022 02.36, William Hubbs wrote:
>> On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote:
On Wed, 28 Sep 2022, Florian Schmaus wrote:
2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer
>>>
On Wed, 2022-09-28 at 17:28 +0200, Florian Schmaus wrote:
> > I would like to continue discussing whether we should entirely >
> > deprecate
> > EGO_SUM without the desire to offend anyone.
> >
> > We now have a pending GitHub PR that bumps restic to 0.14 [1].
> > Restic > is
> > a very popular
On Fri, Sep 30, 2022 at 04:53:39PM +0200, Florian Schmaus wrote:
> On 30/09/2022 02.36, William Hubbs wrote:
> > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote:
> >>> On Wed, 28 Sep 2022, Florian Schmaus wrote:
> >>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo de
Hi,
When the size of the repo is considered too big maybe we can revisit the option
of having the portage tree distributed as a compressed sqashfs image.
$ du -hs /var/db/repos/gentoo
536M.
$ gensquashfs -k -q -b 1M -D /var/db/repos/gentoo -c zstd -X level=22
/tmp/gentoo-current.
Hi,
On 2022/09/30 16:53, Florian Schmaus wrote:
> jkroon@plastiekpoot ~ $ du -sh /var/db/repos/gentoo/
>> 644M /var/db/repos/gentoo/
>>
>> I'm not against exploding this by another 200 or even 300 MB personally,
>> but I do agree that pointless bloat is bad, and ideally we want to
>> shrink the
On 30/09/2022 16.36, Jaco Kroon wrote:
Hi All,
This doesn't directly affect me. Nor am I familiar with the mechanisms.
Perhaps it's worthwhile to suggest that EGO_SUM itself may be
externalized. I don't know what goes in here, and this will likely
require help from portage itself, so may not b
On 30/09/2022 02.36, William Hubbs wrote:
On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote:
On Wed, 28 Sep 2022, Florian Schmaus wrote:
2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer
maintains the package
3.) the number of EGO_SUM entries exceeds 1500 and a
Hi All,
This doesn't directly affect me. Nor am I familiar with the mechanisms.
Perhaps it's worthwhile to suggest that EGO_SUM itself may be
externalized. I don't know what goes in here, and this will likely
require help from portage itself, so may not be directly viable.
What if portage had a
On 28/09/2022 23.23, John Helmert III wrote:
On Wed, Sep 28, 2022 at 05:28:00PM +0200, Florian Schmaus wrote:
I would like to continue discussing whether we should entirely deprecate
EGO_SUM without the desire to offend anyone.
We now have a pending GitHub PR that bumps restic to 0.14 [1]. Rest
On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote:
> > On Wed, 28 Sep 2022, Florian Schmaus wrote:
>
> > I would like to continue discussing whether we should entirely
> > deprecate EGO_SUM without the desire to offend anyone.
Don't worry, I am not offended. I just haven't found
On Wed, Sep 28, 2022 at 05:28:00PM +0200, Florian Schmaus wrote:
> I would like to continue discussing whether we should entirely deprecate
> EGO_SUM without the desire to offend anyone.
>
> We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic is
> a very popular backup software
> On Wed, 28 Sep 2022, Florian Schmaus wrote:
> I would like to continue discussing whether we should entirely
> deprecate EGO_SUM without the desire to offend anyone.
> We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic
> is a very popular backup software written in Go. Th
I would like to continue discussing whether we should entirely deprecate
EGO_SUM without the desire to offend anyone.
We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic is
a very popular backup software written in Go. The PR drops EGO_SUM in
favor of a vendor tarball created
On Sat, Jul 16, 2022 at 10:20:01PM +0200, Ulrich Mueller wrote:
> > On Sat, 16 Jul 2022, William Hubbs wrote:
> > The only question is, is there a way to reliably tell whether or not
> > we are in the main tree?
>
> An eclass has no legitimate way to find out in which repository it is
> On Sat, 16 Jul 2022, William Hubbs wrote:
> I could force this in the eclass with the following flow if I know how
> to tell if the ebuild inheriting it is in the main tree or not:
> # in_main_tree is a place holder for a test to see if the ebuld running
> # this is in the tree
> if [
On Sat, Jul 16, 2022 at 06:46:40PM +, Robin H. Johnson wrote:
> On Sat, Jul 16, 2022 at 09:31:35PM +0300, Arthur Zamarin wrote:
> > I want to give another option. Both ways are allowed by eclass, but by
> > QA policy (or some other decision), it is prohibited to use EGO_SUM in
> > main ::gentoo
On Sat, Jul 16, 2022 at 09:31:35PM +0300, Arthur Zamarin wrote:
> I want to give another option. Both ways are allowed by eclass, but by
> QA policy (or some other decision), it is prohibited to use EGO_SUM in
> main ::gentoo tree.
>
> As a result, overlays and ::guru can use the EGO_SUM or dist d
On 16/07/2022 20.51, William Hubbs wrote:
> On Sat, Jul 16, 2022 at 02:58:04PM +0300, Joonas Niilola wrote:
>> On 16.7.2022 14.24, Florian Schmaus wrote:
>>>
>>
>> ++ this sounds most sensible. This is also how I've understood your
>> proposal.
>
> Remember that with EGO_SUM all of the bloated man
On Sat, Jul 16, 2022 at 02:58:04PM +0300, Joonas Niilola wrote:
> On 16.7.2022 14.24, Florian Schmaus wrote:
> >
> > That reads as if you wrote it under the assumption that we can only
> > either use dependency tarballs or use EGO_SUM. At the same time, I have
> > not seen an argument why we can n
On 16.7.2022 14.24, Florian Schmaus wrote:
>
> That reads as if you wrote it under the assumption that we can only
> either use dependency tarballs or use EGO_SUM. At the same time, I have
> not seen an argument why we can not simply do *both*.
>
> EGO_SUM has numerous advantages over dependency
On 15/07/2022 23.34, William Hubbs wrote:
On Mon, Jun 27, 2022 at 01:43:19AM +0200, Zoltan Puskas wrote:
In summary, IMHO the EGO_SUM way of handling of go packages has more
benefits than drawbacks compared to the vendor tarballs.
EGO_SUM can cause portage to break; that is the primary reason
On Wed, Jul 06, 2022 at 02:42:34PM +0200, Florian Schmaus wrote:
> On 04/07/2022 17.27, David Seifert wrote:
> > Ultimately, all these things really matter when only the defaults
> > change. Turn-right-on-red in the US is such a thing, because unless
> > otherwise stated, it's the norm. Knowing our
On Mon, Jun 27, 2022 at 01:43:19AM +0200, Zoltan Puskas wrote:
*snip*
> First of all one of the advantages of Gentoo is that it gets it's source
> code from upstream (yes, I'm aware of mirrors acting as a cache layer),
> which means that poisoning source code needs to be done at upstream
> lev
On 07.07.22 09:45, Michal Prívozník wrote:
I think that rejecting a contribution (regardless of the flag) should be
based on technical merit, rather than individual maintainers personal
preferences. I do understand some packages are like your babies, you
watch them grow, fine tune everything. But
On 7/6/22 18:04, Fabian Groffen wrote:
> - please do not needlessly change style: if you do not "maintain" the
> ebuild, respect the style of the maintainer, so only add the changes
> you need, keep it minimal, respect the original even though you don't
> like it (and don't use QA as an excus
On 7/4/22 16:19, Florian Schmaus wrote:
> I'd like to propose a new metadata XML element for packages:
>
>
>
> Maintainers can signal to other developers (and of course contributors
> in general) that they are happy with others to make changes to the
> ebuilds without prior consultation of t
Hi All,
On 2022/07/06 15:50, Michał Górny wrote:
> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
>> I'd like to propose a new metadata XML element for packages:
>>
>>
>>
>> Maintainers can signal to other developers (and of course contributors
>> in general) that they are happy
On 06-07-2022 15:50:30 +0200, Michał Górny wrote:
> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
> > I'd like to propose a new metadata XML element for packages:
> >
> >
> >
> > Maintainers can signal to other developers (and of course contributors
> > in general) that they ar
On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
> I'd like to propose a new metadata XML element for packages:
>
>
>
> Maintainers can signal to other developers (and of course contributors
> in general) that they are happy with others to make changes to the
> ebuilds without pr
On Wed, Jul 6, 2022 at 8:42 AM Florian Schmaus wrote:
>
>
> It appears that we have at least two options here:
>
> A) Establish that the default is non-maintainer-commits-welcome, and
> introduce a metadata element.
>
> B) Declare the default to be unspecified and introduce two metadata
> element
On 04/07/2022 17.27, David Seifert wrote:
Ultimately, all these things really matter when only the defaults
change. Turn-right-on-red in the US is such a thing, because unless
otherwise stated, it's the norm. Knowing our devbase, with roughly 75%
mostly AWOL and barely reading the MLs, I don't th
On Mon, 4 Jul 2022 22:49:25 -0400
Ionen Wolkens wrote:
On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
> I'd like to propose a new metadata XML element for packages:
>
>
>
> Maintainers can signal to other developers (and of course contributors
> in general) that they are
> On 5 Jul 2022, at 00:21, Robin H. Johnson wrote:
>
> On Mon, Jul 04, 2022 at 05:27:03PM +0200, David Seifert wrote:
>> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
>>> I'd like to propose a new metadata XML element for packages:
>>>
>>>
> ...
>> Ultimately, all these thing
> On 5 Jul 2022, at 03:49, Ionen Wolkens wrote:
>
> On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
>> I'd like to propose a new metadata XML element for packages:
>>
>>
>>
>> Maintainers can signal to other developers (and of course contributors
>> in general) that they are
> On 5 Jul 2022, at 04:24, Ionen Wolkens wrote:
>
> On Mon, Jul 04, 2022 at 10:53:41PM -0400, Ionen Wolkens wrote:
>> On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote:
>>> On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
I'd like to propose a new metadata XML e
On Mon, Jul 04, 2022 at 10:53:41PM -0400, Ionen Wolkens wrote:
> On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote:
> > On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
> > > I'd like to propose a new metadata XML element for packages:
> > >
> > >
> > >
> > > Mai
On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote:
> On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
> > I'd like to propose a new metadata XML element for packages:
> >
> >
> >
> > Maintainers can signal to other developers (and of course contributors
> > in g
On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
> I'd like to propose a new metadata XML element for packages:
>
>
>
> Maintainers can signal to other developers (and of course contributors
> in general) that they are happy with others to make changes to the
> ebuilds wit
> On 5 Jul 2022, at 00:49, Rich Freeman wrote:
>
> On Mon, Jul 4, 2022 at 7:21 PM Robin H. Johnson wrote:
>>
>> It had 3 states however:
>> a) go ahead and touch it, no additional approvals needed
>> b) please get a maintainer to approve it
>> c) do not touch it
>>
>
> ++
>
> Though to be
On Mon, Jul 4, 2022 at 7:21 PM Robin H. Johnson wrote:
>
> It had 3 states however:
> a) go ahead and touch it, no additional approvals needed
> b) please get a maintainer to approve it
> c) do not touch it
>
++
Though to be fair b is really no different from what just about
anybody can do via a
On Mon, Jul 04, 2022 at 05:27:03PM +0200, David Seifert wrote:
> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
> > I'd like to propose a new metadata XML element for packages:
> >
> >
...
> Ultimately, all these things really matter when only the defaults
> change. Turn-right-on-
On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
> I'd like to propose a new metadata XML element for packages:
>
>
>
> Maintainers can signal to other developers (and of course contributors
> in general) that they are happy with others to make changes to the
> ebuilds without pri
I'd like to propose a new metadata XML element for packages:
Maintainers can signal to other developers (and of course contributors
in general) that they are happy with others to make changes to the
ebuilds without prior consultation of the maintainer.
Of course, this is not a free tick
Hey,
>
> Rephrasing this just to ensure I'm understanding it correctly: you're
> suggesting to move _everything_ that uses Go into its own overlay. Let's
> call it gentoo-go for the sake of the example.
>
> If the above is accurate, then I hard disagree.
Yes, that was the suggestion, you understo
On Mon, Jun 27, 2022 at 01:43:19 +0200, Zoltan Puskas wrote:
> Hi,
>
> I've been working on adding a go based ebuild to Gentoo yesterday and I
> got this warning form portage saying that EGO_SUM is deprecated and
> should be avoided. Since I remember there was an intense discussion
> about this
On Mon, Jun 13, 2022 at 12:26:43PM +0200, Ulrich Mueller wrote:
> > On Mon, 13 Jun 2022, Florian Schmaus wrote:
>
> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
> where some voices where in agreement that EGO_SUM has its raison d'être,
> while there wh
On 14/06/2022 11.37, Michał Górny wrote:
On Mon, 2022-06-13 at 10:29 +0200, Michał Górny wrote:
On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
where some voices where in agreement that EGO_SUM has its raison d'êt
On Mon, 2022-06-13 at 10:29 +0200, Michał Górny wrote:
> On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
> > Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
> > where some voices where in agreement that EGO_SUM has its raison d'être,
> > while there where no argume
On Mon, 2022-06-13 at 11:30 +0200, Florian Schmaus wrote:
> On 13/06/2022 10.29, Michał Górny wrote:
> > On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
> > > Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
> > > where some voices where in agreement that EGO_SUM ha
> On Mon, 13 Jun 2022, Florian Schmaus wrote:
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
where some voices where in agreement that EGO_SUM has its raison d'être,
while there where no arguments in favor of eventually removing EGO_SUM,
I hereby pr
On 13/06/2022 10.49, Ulrich Mueller wrote:
On Mon, 13 Jun 2022, Michał Górny wrote:
On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
where some voices where in agreement that EGO_SUM has its raison d'être,
while
On 13/06/2022 10.29, Michał Górny wrote:
On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
where some voices where in agreement that EGO_SUM has its raison d'être,
while there where no arguments in favor of eventuall
> On Mon, 13 Jun 2022, Michał Górny wrote:
> On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
>> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
>> where some voices where in agreement that EGO_SUM has its raison d'être,
>> while there where no arguments in fav
On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
> where some voices where in agreement that EGO_SUM has its raison d'être,
> while there where no arguments in favor of eventually removing EGO_SUM,
> I hereby propose
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
where some voices where in agreement that EGO_SUM has its raison d'être,
while there where no arguments in favor of eventually removing EGO_SUM,
I hereby propose to undeprecate EGO_SUM.
1:
https://archives.gentoo.org/gentoo-d
Hi Robin,
On Wed, Apr 06, 2022 at 05:31:09PM +, Robin H. Johnson wrote:
> On Wed, Apr 06, 2022 at 07:06:30PM +0200, Jason A. Donenfeld wrote:
> > No, you're still missing the point.
> >
> > If SHA-512 breaks, the security of the system fails, regardless of
> > what change we make. This is bec
Hey Robin,
Sorry for the delay in getting back to you. As mentioned on IRC, both of
your messages bounced earlier, and I was at a conference all last week.
Catching up with this thread now...
On Wed, Apr 06, 2022 at 05:23:25PM +, Robin H. Johnson wrote:
> On Wed, Apr 06, 2022 at 02:15:02AM +0
On Wed, Apr 06, 2022 at 05:23:25PM +, Robin H. Johnson wrote:
> On Wed, Apr 06, 2022 at 02:15:02AM +0200, Jason A. Donenfeld wrote:
> > 2) Comparability: other distros use SHA2-512, as well as various
> > upstreams, which means we can compare our hashes to theirs easily.
> Can we expand on this
On Mon, Apr 11, 2022 at 7:14 PM Joshua Kinard wrote:
>
> On 4/5/2022 17:49, Jason A. Donenfeld wrote:
> > Hi Matt,
> >
> > On Tue, Apr 5, 2022 at 10:38 PM Matt Turner wrote:
> >>
> >> On Tue, Apr 5, 2022 at 12:30 PM Jason A. Donenfeld
> >> wrote:
> >>> By the way, we're not currently _checking_
On 4/5/2022 17:49, Jason A. Donenfeld wrote:
> Hi Matt,
>
> On Tue, Apr 5, 2022 at 10:38 PM Matt Turner wrote:
>>
>> On Tue, Apr 5, 2022 at 12:30 PM Jason A. Donenfeld wrote:
>>> By the way, we're not currently _checking_ two hash functions during
>>> src_prepare(), are we?
>>
>> I don't know, b
On 2022-04-06 19:34, Rich Freeman wrote:
This is one of those low cost, low risk, high reward situations IMO.
*puts on Council hat*
The above pretty much covers my own opinion on the subject.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On Wed, Apr 6, 2022 at 1:29 PM Jason A. Donenfeld wrote:
>
> Sort of. The security between infra and users relies on SHA2-512. The
> security between devs and infra relies on SHA-1. I guess the "full
> system" depends on both, but I've been focused on the more likely
> issue of a community-run mir
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:
> So I'll spell out the different possibilities:
> 1) GPG uses SHA-512. Manifest uses SHA-512 and BLAKE2b.
> 1a) Possibility: SHA-512 is broken. Result: system broken.
> 1b) Possibility: BLAKE2b is broken. Result: nothing.
> 2) GPG uses SHA-512
On Wed, Apr 06, 2022 at 07:06:30PM +0200, Jason A. Donenfeld wrote:
> No, you're still missing the point.
>
> If SHA-512 breaks, the security of the system fails, regardless of
> what change we make. This is because GnuPG uses SHA-512 for its
> signatures.
Question directly for you Jason, because
Hi Rich,
On 4/6/22, Rich Freeman wrote:
> On Tue, Apr 5, 2022 at 8:05 PM Sam James wrote:
> Our security fails currently if EITHER SHA2-512 or a hardened version
> of SHA-1 are defeated. Our top gpg signature is bound to a git commit
> record by SHA2-512, and the git commit record is bound to e
On Wed, Apr 06, 2022 at 02:15:02AM +0200, Jason A. Donenfeld wrote:
> 2) Comparability: other distros use SHA2-512, as well as various
> upstreams, which means we can compare our hashes to theirs easily.
Can we expand on this specific thread for a moment?
I was the author of GLEP59 about changing
Hi Ulrich,
On Wed, Apr 6, 2022 at 6:38 PM Ulrich Mueller wrote:
> > Why? Then we're dependent on two things, either of which could break,
> > rather than one.
>
> See? If either of these should happen, then we'll be happy that we still
> have both hashes in our Manifest files.
>
> OTOH, if that a
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:
> Why? Then we're dependent on two things, either of which could break,
> rather than one.
See? If either of these should happen, then we'll be happy that we still
have both hashes in our Manifest files.
OTOH, if that argument is not relavant b
Hi Ulrich,
On 4/6/22, Ulrich Mueller wrote:
>> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:
>
>> I think actually the argument I'm making this time might be subtly
>> different from the motions that folks went through last year.
>> Specifically, the idea last year was to switch to using BLAK
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:
> I think actually the argument I'm making this time might be subtly
> different from the motions that folks went through last year.
> Specifically, the idea last year was to switch to using BLAKE2b only.
> I think what the arguments I'm making n
On Tue, Apr 5, 2022 at 8:05 PM Sam James wrote:
> > On 5 Apr 2022, at 22:13, Jonas Stein wrote:
> >
> >> In other words, what are we actually getting by having _both_ SHA2-512
> >> and BLAKE2b for every file in every Manifest?
> >
> > Implementations are often broken and we have to expect zero da
> On 6 Apr 2022, at 01:15, Jason A. Donenfeld wrote:
>
> Hi Sam,
>
> On Wed, Apr 6, 2022 at 2:02 AM Sam James wrote:
>> This matches my views and recollection. We could revisit it
>> if there was a passionate advocate (which it looks like there may well be).
>>
>> While I wasn't against it b
Hi Sam,
On Wed, Apr 6, 2022 at 2:02 AM Sam James wrote:
> This matches my views and recollection. We could revisit it
> if there was a passionate advocate (which it looks like there may well be).
>
> While I wasn't against it before, I was sort of ambivalent given
> we had no strong reason to, bu
> On 5 Apr 2022, at 22:13, Jonas Stein wrote:
>
> Hi
>
>> I'd like to propose the following for portage:
>> - Only support one "secure" hash function (such as sha2, sha3, blake2, etc)
>> - Only generate and parse one hash function in Manifest files
>> - Remove support for multiple hash functio
Hi Matt,
On Tue, Apr 5, 2022 at 10:38 PM Matt Turner wrote:
>
> On Tue, Apr 5, 2022 at 12:30 PM Jason A. Donenfeld wrote:
> > By the way, we're not currently _checking_ two hash functions during
> > src_prepare(), are we?
>
> I don't know, but the hash-checking is definitely checked before
> sr
Hi Jonas,
On Tue, Apr 5, 2022 at 11:20 PM Jonas Stein wrote:
> > In other words, what are we actually getting by having _both_ SHA2-512
> > and BLAKE2b for every file in every Manifest?
>
> Implementations are often broken and we have to expect zero day attacks
> on hashes and on signatures. Henc
1 - 100 of 432 matches
Mail list logo
