Davyd McColl wrote:
>
> 1) `sync-depth` has been deprecated (should now use `clone-depth`)
The reason is that sync-depth was meant to be effective for
every sync, i.e. that with sync-depth=1 the clone should stay shallow.
However, it turned out that this caused frequent/occassional errors
with gi
On Friday, 6 July 2018 08:29:26 BST Martin Vaeth wrote:
> Davyd McColl wrote:
> > 1) `sync-depth` has been deprecated (should now use `clone-depth`)
>
> The reason is that sync-depth was meant to be effective for
> every sync, i.e. that with sync-depth=1 the clone should stay shallow.
> However,
Part of the original intent of the mail was just to bring to light the
disparity between the documentation and experience (wrt the default
value) -- I had no configured value and portage was trying to clone the
entire history of the repo instead of a shallow start. Since I really
appreciate the
On Fri, Jul 6, 2018 at 4:34 AM Davyd McColl wrote:
>
> I understand that git history will build over time -- I'm less concerned
> with (eventual) disk usage than I am with the speed of `emerge --sync`,
> which (and perhaps I'm sorely mistaken) appeared to be faster using git
> than rsync -- hence
@Rich: if I understand the process correctly, the same commits are
pushed to infra and GitHub by the CI bot?
I ask because prior to the GitHub incident, I didn't have signature
verification enabled (I hadn't read about it and it didn't even occur to
me). So my plan was to (whilst GitHub was be
On Fri, Jul 6, 2018 at 7:57 AM Davyd McColl wrote:
>
> @Rich: if I understand the process correctly, the same commits are
> pushed to infra and GitHub by the CI bot?
>
I'm pretty sure the repos are identical (well, aside from whatever
order they're updated in).
> I ask because prior to the GitHu
@Rich thanks for taking the time to formulate that in-depth response.
Appreciated.
-d
-- Original Message --
From: "Rich Freeman"
To: gentoo-user@lists.gentoo.org
Sent: 2018-07-06 14:20:54
Subject: Re: Re[4]: [gentoo-user] Re: Portage, git and shallow cloning
On Fri, Jul 6, 2018 at 7
Now that the public key stuff is working again (knock on wood), I'm
curious if it's usual for an emerge --sync to take 10-15 minutes
longer than it used due to the "Verifying /usr/portage" step.
On some systems (with fewer packages installed) it only takes a minute
or less. But, on my "main" deskt
Grant Edwards wrote:
> Now that the public key stuff is working again (knock on wood), I'm
> curious if it's usual for an emerge --sync to take 10-15 minutes
> longer than it used due to the "Verifying /usr/portage" step.
>
> On some systems (with fewer packages installed) it only takes a minute
>
On 2018-07-06, Dale wrote:
> I haven't timed mine yet but that sounds about like mine here. I'm not
> sure what the bottleneck is but I have a four core AMD CPU running at
> 3.2GHz with 16GBs of ram and SATA spinning rust drives. While I'm glad
> to have the added security measures, it does add
On Fri, Jul 6, 2018 at 2:16 PM, Dale wrote:
> Grant Edwards wrote:
>> Now that the public key stuff is working again (knock on wood), I'm
>> curious if it's usual for an emerge --sync to take 10-15 minutes
>> longer than it used due to the "Verifying /usr/portage" step.
>>
>> On some systems (with
R0b0t1 wrote:
> On Fri, Jul 6, 2018 at 2:16 PM, Dale wrote:
>> Grant Edwards wrote:
>>> Now that the public key stuff is working again (knock on wood), I'm
>>> curious if it's usual for an emerge --sync to take 10-15 minutes
>>> longer than it used due to the "Verifying /usr/portage" step.
>>>
>>>
On Fri, Jul 6, 2018 at 3:02 PM Grant Edwards wrote:
>
> Now that the public key stuff is working again (knock on wood), I'm
> curious if it's usual for an emerge --sync to take 10-15 minutes
> longer than it used due to the "Verifying /usr/portage" step.
>
Again, the sync mechanisms are different
On 2018-07-06, Grant Edwards wrote:
> Now that the public key stuff is working again (knock on wood), I'm
> curious if it's usual for an emerge --sync to take 10-15 minutes
> longer than it used due to the "Verifying /usr/portage" step.
>
> On some systems (with fewer packages installed) it only
On Friday, 6 July 2018 21:43:35 BST Grant Edwards wrote:
> On 2018-07-06, Grant Edwards wrote:
> > Now that the public key stuff is working again (knock on wood), I'm
> > curious if it's usual for an emerge --sync to take 10-15 minutes
> > longer than it used due to the "Verifying /usr/portage" st
On Fri, Jul 6, 2018 at 4:43 PM Grant Edwards wrote:
>
> On 2018-07-06, Grant Edwards wrote:
>
> > Now that the public key stuff is working again (knock on wood), I'm
> > curious if it's usual for an emerge --sync to take 10-15 minutes
> > longer than it used due to the "Verifying /usr/portage" st
Rich Freeman wrote:
> On Fri, Jul 6, 2018 at 4:43 PM Grant Edwards
> wrote:
>> On 2018-07-06, Grant Edwards wrote:
>>
>>> Now that the public key stuff is working again (knock on wood), I'm
>>> curious if it's usual for an emerge --sync to take 10-15 minutes
>>> longer than it used due to the "V
On 06/07/18 00:06, Floyd Anderson wrote:
> On Wed, 04 Jul 2018 22:57:05 -0400
> John Covici wrote:
>>
>> I got the following when running your command:
>> gemato verify -K /tmp/gentoo-release.asc.20180703 /usr/portage/
>> INFO:root:Refreshing keys from keyserver...
>> INFO:root:Keys refreshed.
>
>
On Wed, Jul 4, 2018 at 5:39 PM gevisz wrote:
> 2018-07-03 16:22 GMT+03:00 Mart Raudsepp :
>> If you use su, you should be using "su -" (or "su -l" or "su --login"),
>> not "su".
>
> I have used only "su" for already 3 years, since switched to Gentoo
> from Ubuntu and never had any problems with
On Wed, Jul 4, 2018 at 5:43 PM gevisz wrote:
>
> but it "shot" only after sourcing /etc/profile.
Which is what "su -l" does.
Hi Bill,
On Sat, 07 Jul 2018 07:40:00 +0800
Bill Kenworthy wrote:
I still have this error and Ive tried a number of things including:
gemato create -p ebuild -K /usr/share/openpgp-keys/gentoo-release.asc
/usr/portage/
next emerge --sync error-ed on a lot of private manifest files but
missin
On 07/07/18 09:42, Floyd Anderson wrote:
> Hi Bill,
>
> On Sat, 07 Jul 2018 07:40:00 +0800
> Bill Kenworthy wrote:
>>
>> I still have this error and Ive tried a number of things including:
>>
>> gemato create -p ebuild -K /usr/share/openpgp-keys/gentoo-release.asc
>> /usr/portage/
>>
>> next emer
Rich Freeman wrote:
>
> Biggest issue with git signature verification is that right now it
> will still do a full pull/checkout before verifying
Biggest issue is that git signature happens by the developer who
last commited which means that in practice you need dozens/hundreds
of keys. No package
Rich Freeman wrote:
>
> git has the advantage that it can just read the current HEAD and from
> that know exactly what commits are missing, so there is way less
> effort spent figuring out what changed.
I don't know the exact protocol, but I would assume that git is
even more efficient: I would a
Davyd McColl wrote:
> @Rich: if I understand the process correctly, the same commits are
> pushed to infra and GitHub by the CI bot?
Yes, the repositories are always identical (up to a few seconds delay).
> I ask because prior to the GitHub incident, I didn't have signature
> verification enable
25 matches
Mail list logo
