On Tue, Jul 03, 2018 at 09:03:45PM +0200, Jonas Stein wrote:
> Dear all,
>
> The following packages are up for grabs:
>
> app-emulation/virtualbox-bin
>
>
> after retirement of the proxied maintainer.
>
> https://packages.gentoo.org/packages/app-emulation/virtualbox-bin
>
> This famous
On Tue, Jul 3, 2018 at 12:33 PM Matthias Maier wrote:
>
>
> On Tue, Jul 3, 2018, at 11:22 CDT, Matt Turner wrote:
>
> > I'd be happy to switch if the space requirements were similar.
>
> $ git clone --depth=1 https://github.com/gentoo-mirror/gentoo
>
> occupies 662M on my machine (just
On Tue, Jul 3, 2018 at 12:36 PM Rich Freeman wrote:
>
> On Tue, Jul 3, 2018 at 12:22 PM Matt Turner wrote:
> >
> > On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote:
> > > 4. by default git tends to accumulate history, which can eat up disk
> > > space. I imagine this could be automatically
On Tue, 3 Jul 2018, Matt Turner wrote:
On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote:
4. by default git tends to accumulate history, which can eat up disk
space. I imagine this could be automatically trimmed if users wanted,
though during syncing it would at least need to store all the
On Tue, Jul 3, 2018 at 1:39 PM William Hubbs wrote:
>
> All,
>
> some of us have talked about this on IRC off and on, but I want to bring
> it up here as well.
>
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend? It would
On 03/07/18 21:01, William Hubbs wrote:
> On Tue, Jul 03, 2018 at 09:20:53PM +0200, Jonas Stein wrote:
>>> I don't care that we have a wiki, but can we please look into killing
>>> mediawiki and look at something with a git backend?
>> I think the wiki is very useful and should remain.
> Like I
On Tue, Jul 03, 2018 at 09:20:53PM +0200, Jonas Stein wrote:
> > I don't care that we have a wiki, but can we please look into killing
> > mediawiki and look at something with a git backend?
>
> I think the wiki is very useful and should remain.
Like I said, there are wiki packages out there
On Tue, Jul 03, 2018 at 09:09:16PM +0100, M. J. Everitt wrote:
> On 03/07/18 21:01, William Hubbs wrote:
> > On Tue, Jul 03, 2018 at 09:20:53PM +0200, Jonas Stein wrote:
> >>> I don't care that we have a wiki, but can we please look into killing
> >>> mediawiki and look at something with a git
W dniu wto, 03.07.2018 o godzinie 12∶42 -0400, użytkownik Aaron Bauman
napisał:
> On Tuesday, July 3, 2018 12:40:57 PM EDT Aaron Bauman wrote:
> > On Tuesday, July 3, 2018 9:29:53 AM EDT Michał Górny wrote:
> > > Hi, everyone.
> > >
> > > Here's a series of patches for GLEP 63 (key policies).
Hi, everyone.
Here's a series of patches for GLEP 63 (key policies). The first three
patches are merely editorial changes. The fourth is an actual
recommended policy change.
The editorial changes are:
1. Using 'OpenPGP' instead of 'GPG' where appropriate.
2. Replacing 'RSAv4' with more
Replace many of the incorrect uses of GPG/GnuPG [key] with OpenPGP.
G[nu]PG has been left where the text clearly refers to the specific
implementation of OpenPGP rather than the standard itself.
---
glep-0063.rst | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff
Replace the 'RSAv4' with 'OpenPGP v4 key format'. The RSA algorithm
does not really have versions, and the author most likely meant the v4
of OpenPGP key format as outlined in RFC 4880, section 12.1.
This was figured out and explained to me by Kristian Fiskerstrand.
---
glep-0063.rst | 4 ++--
Reword the minimal requirements to clearly indicate that a dedicated
signing subkey is required. The current wording may make it unclear
whether the 'root key' and 'signing subkey' can be the same key.
---
glep-0063.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Change the recommended key size recommendation for RSA from 4096 bits
to 2048 bits. Use of larger keys is unjustified due to negligible gain
in security, and recommending RSA-4096 unnecessarily resulted
in developers replacing their RSA-2048 keys for no good reason.
---
glep-0063.rst | 18
On Tue, Jul 3, 2018 at 12:22 PM Matt Turner wrote:
>
> On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote:
> > 4. by default git tends to accumulate history, which can eat up disk
> > space. I imagine this could be automatically trimmed if users wanted,
> > though during syncing it would at
I would expect as much. But my primary argument would be key management
related, it is simply impossible to present a raw copy of our repo to end-users
and have them verify each commit
Original message From: William Hubbs
Date: 7/3/18 17:39 (GMT+01:00) To:
On Tuesday, July 3, 2018 9:29:53 AM EDT Michał Górny wrote:
> Hi, everyone.
>
> Here's a series of patches for GLEP 63 (key policies). The first three
> patches are merely editorial changes. The fourth is an actual
> recommended policy change.
>
> The editorial changes are:
>
> 1. Using
On Tue, Jul 3, 2018 at 12:34 PM William Hubbs wrote:
>
> On Tue, Jul 03, 2018 at 11:40:53AM -0400, Rich Freeman wrote:
> > On Tue, Jul 3, 2018 at 11:32 AM Brian Dolbec wrote:
> > > 2) we have a large infrastructure of rsync mirrors, which we do not for
> > > git.
> > >
> >
> > Do we need them.
On Tuesday, July 3, 2018 12:40:57 PM EDT Aaron Bauman wrote:
> On Tuesday, July 3, 2018 9:29:53 AM EDT Michał Górny wrote:
> > Hi, everyone.
> >
> > Here's a series of patches for GLEP 63 (key policies). The first three
> > patches are merely editorial changes. The fourth is an actual
> >
All,
Mostly because of the recent "trustless infrastructure" thread, I am
wondering why we are still distributing the portage tree primarily
via rsync instead of git?
Can someone educate me on that, and is it worth considering moving away
from rsync distribution?
Thanks,
William
On Tue, Jul 3, 2018 at 11:22 AM William Hubbs wrote:
>
> Mostly because of the recent "trustless infrastructure" thread, I am
> wondering why we are still distributing the portage tree primarily
> via rsync instead of git?
>
> Can someone educate me on that, and is it worth considering moving
On Tue, Jul 03, 2018 at 11:40:53AM -0400, Rich Freeman wrote:
> On Tue, Jul 3, 2018 at 11:32 AM Brian Dolbec wrote:
> > 2) we have a large infrastructure of rsync mirrors, which we do not for
> > git.
> >
>
> Do we need them. I've yet to see somebody complain about poor syncing
> performance
On Tue, Jul 03, 2018 at 01:47:19PM -0400, Brian Evans wrote:
> On 7/3/2018 1:39 PM, William Hubbs wrote:
> > All,
> >
> > some of us have talked about this on IRC off and on, but I want to bring
> > it up here as well.
> >
> > I don't care that we have a wiki, but can we please look into killing
On 7/3/2018 1:39 PM, William Hubbs wrote:
> All,
>
> some of us have talked about this on IRC off and on, but I want to bring
> it up here as well.
>
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend? It would be very
>
All,
some of us have talked about this on IRC off and on, but I want to bring
it up here as well.
I don't care that we have a wiki, but can we please look into killing
mediawiki and look at something with a git backend? It would be very
nice to be able to edit wiki pages in markdown or another
On Tue, 3 Jul 2018 10:22:35 -0500
William Hubbs wrote:
> All,
>
> Mostly because of the recent "trustless infrastructure" thread, I am
> wondering why we are still distributing the portage tree primarily
> via rsync instead of git?
>
> Can someone educate me on that, and is it worth
On Tue, Jul 03, 2018 at 08:32:55AM -0700, Brian Dolbec wrote:
> On Tue, 3 Jul 2018 10:22:35 -0500
> William Hubbs wrote:
>
> > All,
> >
> > Mostly because of the recent "trustless infrastructure" thread, I am
> > wondering why we are still distributing the portage tree primarily
> > via rsync
On Tue, Jul 3, 2018 at 11:32 AM Brian Dolbec wrote:
>
> 1) it is still the most bandwidth economical means of distributing the
> tree
Is this true? If I do two syncs 10min apart, I have to imagine that
less data will get transferred for git. Certianly there will be less
disk IO. I think the
On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote:
> 4. by default git tends to accumulate history, which can eat up disk
> space. I imagine this could be automatically trimmed if users wanted,
> though during syncing it would at least need to store all the commits
> between the last fetched
On Tue, Jul 3, 2018, at 11:22 CDT, Matt Turner wrote:
> I'd be happy to switch if the space requirements were similar.
$ git clone --depth=1 https://github.com/gentoo-mirror/gentoo
occupies 662M on my machine (just tested). With full history
(i.e. without --depth=1) I am at 1.1GB.
Best,
On Tue, Jul 3, 2018 at 12:41 PM Kristian Fiskerstrand wrote:
>
> I would expect as much. But my primary argument would be key management
> related, it is simply impossible to present a raw copy of our repo to
> end-users and have them verify each commit
>
While related, I think that the
Dear all,
The following packages are up for grabs:
app-emulation/virtualbox-bin
after retirement of the proxied maintainer.
https://packages.gentoo.org/packages/app-emulation/virtualbox-bin
This famous package has open bugs and
RepoMan scours the neighborhood...
inherit.deprecated
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend?
I think the wiki is very useful and should remain.
> It would be very nice to be able to edit wiki pages in markdown or another
> similar format
> and use git to
33 matches
Mail list logo
