| 1 |
On 05.11.2016 00:15, Zac Medico wrote: |
| 2 |
> On 11/04/2016 03:55 PM, Zac Medico wrote: |
| 3 |
>> On 11/04/2016 03:47 PM, Brian Dolbec wrote: |
| 4 |
>>> On Fri, 4 Nov 2016 13:53:02 -0700 |
| 5 |
>>> Zac Medico <zmedico@g.o> wrote: |
| 6 |
>>> |
| 7 |
>>>> On 11/04/2016 01:43 PM, Michał Górny wrote: |
| 8 |
>>>>> On Fri, 4 Nov 2016 13:19:39 -0700 |
| 9 |
>>>>> Zac Medico <zmedico@g.o> wrote: |
| 10 |
>>>>> |
| 11 |
>>>>>> On 11/04/2016 01:14 PM, Brian Dolbec wrote: |
| 12 |
>>>>>>> On Thu, 3 Nov 2016 15:55:23 -0700 |
| 13 |
>>>>>>> Zac Medico <zmedico@g.o> wrote: |
| 14 |
>>>>>>> |
| 15 |
>>>>>>>> In about a week, portage-2.3.2 will be eligible for a stable |
| 16 |
>>>>>>>> request. |
| 17 |
>>>>>>>> |
| 18 |
>>>>>>>> The only potential problem that I've noticed is the complaint |
| 19 |
>>>>>>>> about changes from bug 552814 causing issues for people using |
| 20 |
>>>>>>>> git sync with overlay filesystems, but setting sync-depth = 0 |
| 21 |
>>>>>>>> gives those users a workaround. There's also bug 597838, about |
| 22 |
>>>>>>>> the sync-depth setting being ineffective, but I only know of a |
| 23 |
>>>>>>>> couple of people that have been able to reproduce that. |
| 24 |
>>>>>>>> |
| 25 |
>>>>>>>> So, do we want to do a stable request portage-2.3.2 when the time |
| 26 |
>>>>>>>> comes? |
| 27 |
>>>>>>> |
| 28 |
>>>>>>> I'm not sure. Do we -r1 it adding a patch or two and ask it be |
| 29 |
>>>>>>> stabled? |
| 30 |
>>>>>> |
| 31 |
>>>>>> There are just 4 commits since 2.3.2, and they all look good. |
| 32 |
>>>>>> Maybe we should just cut a 2.3.3 release and wait another 30 days |
| 33 |
>>>>>> (we also need to stabilize app-crypt/gkeys since it's needed by |
| 34 |
>>>>>> emerge-webrsync now). |
| 35 |
>>>>> |
| 36 |
>>>>> Wouldn't it be better to have a really working version of gkeys |
| 37 |
>>>>> before it's stabilized? Like one that could be used without having |
| 38 |
>>>>> to create custom configuration files and/or run it as root? |
| 39 |
>>>> |
| 40 |
>>>> Well, gkeys stabilization is not really mandatory, since |
| 41 |
>>>> emerge-webrsync has a --insecure option. |
| 42 |
>>> |
| 43 |
>>> Why don't I/we work on whatever changes are needed to merge the |
| 44 |
>>> meta-manifest code to both portage and gkeys. I'll push out another |
| 45 |
>>> release. I also had some initial code that added gkeys use to verify |
| 46 |
>>> the pkg Manifest file, but I don't know if that is needed still, the |
| 47 |
>>> meta-manifest system will need to run a verify at the end of the sync. |
| 48 |
>>> |
| 49 |
>>> We'll have to poke Robin some more to get some new infra keys setup. |
| 50 |
>>> |
| 51 |
>>> If I have to, maybe I'll create some ansible scripts to run the dev |
| 52 |
>>> seeds update on vulture, transfer it to my system to push --sign to |
| 53 |
>>> api.g.o or break down and get Kristian to help me get key forwarding |
| 54 |
>>> better setup so I can do it from vulture. |
| 55 |
>> |
| 56 |
>> Sounds good, but I think we should cut a portage 2.3.3 release before we |
| 57 |
>> make any more changes. Maybe do a release branch that includes |
| 58 |
>> everything except the emerge-webrsync change. |
| 59 |
> |
| 60 |
> Let's just revert the emerge-webrsync patch, so we can tag a 2.3.3 |
| 61 |
> release on the master branch. |
| 62 |
> |
| 63 |
|
| 64 |
Will repoman be released with the same tag as well or is the portage and |
| 65 |
repoman version not going to be syncronized? |
| 66 |
|
| 67 |
Cheers, |
| 68 |
|
| 69 |
Manuel |
Archives