| 1 |
On 07/08/2018 02:18 PM, Michał Górny wrote: |
| 2 |
> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico |
| 3 |
> napisał: |
| 4 |
>> On 07/08/2018 01:18 PM, Zac Medico wrote: |
| 5 |
>>> On 07/08/2018 01:08 PM, Michał Górny wrote: |
| 6 |
>>>> W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac Medico |
| 7 |
>>>> napisał: |
| 8 |
>>>>> On 07/08/2018 11:42 AM, Michał Górny wrote: |
| 9 |
>>>>>> W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac Medico |
| 10 |
>>>>>> napisał: |
| 11 |
>>>>>>> On 07/08/2018 06:56 AM, Michał Górny wrote: |
| 12 |
>>>>>>>> W dniu nie, 08.07.2018 o godzinie 15∶02 +0200, użytkownik Kristian |
| 13 |
>>>>>>>> Fiskerstrand napisał: |
| 14 |
>>>>>>>>> On 07/08/2018 08:53 AM, Michał Górny wrote: |
| 15 |
>>>>>>>>>> Is safe git syncing implemented already? If not, maybe finish it first and cover both with a single news item. Git is going to be more efficient here, so people may want to learn they have an alternative. |
| 16 |
>>>>>>>>> |
| 17 |
>>>>>>>>> Why complicate things, and increase wait for something that benefits |
| 18 |
>>>>>>>>> most users, just to give alternatives to a few using non-default sync |
| 19 |
>>>>>>>>> mechanism. Securing git distribution is a whole different ballpark. |
| 20 |
>>>>>>>>> |
| 21 |
>>>>>>>> |
| 22 |
>>>>>>>> Let me rephrase. Let's say I'm using rsync. This new feature is |
| 23 |
>>>>>>>> something positive but it breaks my use case (for one of the listed |
| 24 |
>>>>>>>> reasons -- overlayfs, inode use, small fs cache). After reading this |
| 25 |
>>>>>>>> news item, I learn that my only option is to disable the new feature. |
| 26 |
>>>>>>>> |
| 27 |
>>>>>>>> Now, I would appreciate being told that there's an alternate sync method |
| 28 |
>>>>>>>> that handles secure updates without having all those drawbacks. |
| 29 |
>>>>>>> |
| 30 |
>>>>>>> The thing is, the normal git tree doesn't even provide pre-generated |
| 31 |
>>>>>>> metadata, and I see then gentoo-mirror repo that provides metadata does |
| 32 |
>>>>>>> not have commits signed with an release key: |
| 33 |
>>>>>>> |
| 34 |
>>>>>>> https://github.com/gentoo-mirror/gentoo/commits/stable |
| 35 |
>>>>>>> |
| 36 |
>>>>>>> So I'm really not comfortable recommending git to anyone at this point. |
| 37 |
>>>>>> |
| 38 |
>>>>>> Wrong twice. |
| 39 |
>>>>>> |
| 40 |
>>>>>> Firstly, the canonical URL is: |
| 41 |
>>>>>> |
| 42 |
>>>>>> https://anongit.gentoo.org/git/repo/sync/gentoo.git |
| 43 |
>>>>>> (https://gitweb.gentoo.org/repo/sync/gentoo.git) |
| 44 |
>>>>>> |
| 45 |
>>>>>> Secondly, the merge commits (i.e. top commits that are verified |
| 46 |
>>>>>> by Portage) are signed by dedicated key that is part of the infra key |
| 47 |
>>>>>> set. In other words, it works out of the box. |
| 48 |
>>>>> |
| 49 |
>>>>> Is there any documentation that shows users how to migrate to git, and |
| 50 |
>>>>> what the pros and cons might be? Maybe its worthy of its own news item. |
| 51 |
>>>> |
| 52 |
>>>> Maybe. I don't really know, and don't think it's a good idea to show 30 |
| 53 |
>>>> news item of things users might like on every new Gentoo install. |
| 54 |
>>> |
| 55 |
>>> Well if instructions for setting up git sync and associated pros/cons |
| 56 |
>>> are not documented anywhere then I won't advise anyone to use it. |
| 57 |
>> |
| 58 |
>> I've attempted to configure it for myself, and this is what it does: |
| 59 |
>> |
| 60 |
>> * Using keys from /usr/share/openpgp-keys/gentoo-release.asc |
| 61 |
>> * Refreshing keys from keyserver ... |
| 62 |
>> [ ok ] |
| 63 |
>> * No valid signature found: unable to verify signature (missing key?) |
| 64 |
>> |
| 65 |
> |
| 66 |
> Please report a bug and attach your configuration along with keyring |
| 67 |
> version. |
| 68 |
|
| 69 |
It works after upgrading to openpgp-keys-gentoo-release-20180706 from |
| 70 |
openpgp-keys-gentoo-release-20180323. |
| 71 |
-- |
| 72 |
Thanks, |
| 73 |
Zac |
Archives