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
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
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
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
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
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.
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 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.
>
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
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"
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"
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 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
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 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
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
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
>
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"
@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
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
@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
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
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
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,
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
25 matches
Mail list logo
