Workaround for stage1 failures introduced with portage-2.3.19-r1

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Workaround for stage1 failures introduced with portage-2.3.19-r1

Ben Kohler
Due to bug 645002 (and possibly others), our stage1 builds are making
very odd choices on several || ( ) deps, and failing to resolve deps.

One example failure log:
https://archives.gentoo.org/gentoo-releng-autobuilds/message/19e4086ee421a504c445edafc2e83d88

This has been fixed in portage-2.3.20 but there is no indication yet
of if or when this version is going to be stabilized.  If the next
portage stabilization is more than a couple of days out, I propose
that we add a temporary mask to force portage to make the right
decisions.  Since catalyst now cleans our releng portage configs,
there would be no visible signs of this workaround in the resulting
stages.

Proposed masks:

releng/releases/weekly/portage/stages/package.mask/releng/portage-workarounds:

dev-util/pkgconf
sys-apps/paludis
sys-fs/static-dev


Thoughts?

-Ben

Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Jorge Manuel B. S. Vicetto-2
On Tue, Jan 30, 2018 at 3:02 PM, Ben Kohler <[hidden email]> wrote:

> Due to bug 645002 (and possibly others), our stage1 builds are making
> very odd choices on several || ( ) deps, and failing to resolve deps.
>
> One example failure log:
> https://archives.gentoo.org/gentoo-releng-autobuilds/message/19e4086ee421a504c445edafc2e83d88
>
> This has been fixed in portage-2.3.20 but there is no indication yet
> of if or when this version is going to be stabilized.  If the next
> portage stabilization is more than a couple of days out, I propose
> that we add a temporary mask to force portage to make the right
> decisions.  Since catalyst now cleans our releng portage configs,
> there would be no visible signs of this workaround in the resulting
> stages.

I've been meaning to poke Zac about this issue - whether this was a
new failure or the new portage version was missing stable keywords.

> Proposed masks:
>
> releng/releases/weekly/portage/stages/package.mask/releng/portage-workarounds:
>
> dev-util/pkgconf
> sys-apps/paludis
> sys-fs/static-dev
>
>
> Thoughts?

I'd rather keyword the "fixed" portage version instead.

> -Ben
>

Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

M. J. Everitt
On 30/01/18 16:19, Jorge Manuel B. S. Vicetto wrote:

> On Tue, Jan 30, 2018 at 3:02 PM, Ben Kohler <[hidden email]> wrote:
>> Due to bug 645002 (and possibly others), our stage1 builds are making
>> very odd choices on several || ( ) deps, and failing to resolve deps.
>>
>> One example failure log:
>> https://archives.gentoo.org/gentoo-releng-autobuilds/message/19e4086ee421a504c445edafc2e83d88
>>
>> This has been fixed in portage-2.3.20 but there is no indication yet
>> of if or when this version is going to be stabilized.  If the next
>> portage stabilization is more than a couple of days out, I propose
>> that we add a temporary mask to force portage to make the right
>> decisions.  Since catalyst now cleans our releng portage configs,
>> there would be no visible signs of this workaround in the resulting
>> stages.
> I've been meaning to poke Zac about this issue - whether this was a
> new failure or the new portage version was missing stable keywords.
Fixed in
https://gitweb.gentoo.org/proj/portage.git/commit/?id=e2134e9f72a86734552bb67e9414a017cfc4ea51


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Ben Kohler
In reply to this post by Jorge Manuel B. S. Vicetto-2
On Tue, Jan 30, 2018 at 10:19 AM, Jorge Manuel B. S. Vicetto
<[hidden email]> wrote:
>
> I'd rather keyword the "fixed" portage version instead.
>
If you can get this version marked stable, that will solve the
problem.  I don't know how many other unrelated changes are in .20 so
I don't know how feasible a quick-stable is.

-Ben

Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Zac Medico-2
On 01/30/2018 08:39 AM, Ben Kohler wrote:
> On Tue, Jan 30, 2018 at 10:19 AM, Jorge Manuel B. S. Vicetto
> <[hidden email]> wrote:
>>
>> I'd rather keyword the "fixed" portage version instead.
>>
> If you can get this version marked stable, that will solve the
> problem.  I don't know how many other unrelated changes are in .20 so
> I don't know how feasible a quick-stable is.

There are a couple of important problems with portage-2.3.20 that are
fixed in portage-2.3.21, so you should use portage-2.3.21 instead:

* Bug 645416 dep_zapdeps: fix virtual/rust handling (regression)

* Bug 645780 add --changed-deps-report option (in order to help users
cope with the new --dynamic-deps=n default introduced in portage-2.3.20).
--
Thanks,
Zac


signature.asc (231 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

M. J. Everitt
On 30/01/18 17:16, Zac Medico wrote:

> On 01/30/2018 08:39 AM, Ben Kohler wrote:
>> On Tue, Jan 30, 2018 at 10:19 AM, Jorge Manuel B. S. Vicetto
>> <[hidden email]> wrote:
>>> I'd rather keyword the "fixed" portage version instead.
>>>
>> If you can get this version marked stable, that will solve the
>> problem.  I don't know how many other unrelated changes are in .20 so
>> I don't know how feasible a quick-stable is.
> There are a couple of important problems with portage-2.3.20 that are
> fixed in portage-2.3.21, so you should use portage-2.3.21 instead:
>
> * Bug 645416 dep_zapdeps: fix virtual/rust handling (regression)
>
> * Bug 645780 add --changed-deps-report option (in order to help users
> cope with the new --dynamic-deps=n default introduced in portage-2.3.20).
How much of the new 'gemato' features are included in .21 Zac? Is there
any way we can backport the regression to .20 ?

What are the stabilisation targets currently for .20 and .21 respectively?

Cheers,

Michael.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Zac Medico-2
On 01/30/2018 09:18 AM, M. J. Everitt wrote:

> On 30/01/18 17:16, Zac Medico wrote:
>> On 01/30/2018 08:39 AM, Ben Kohler wrote:
>>> On Tue, Jan 30, 2018 at 10:19 AM, Jorge Manuel B. S. Vicetto
>>> <[hidden email]> wrote:
>>>> I'd rather keyword the "fixed" portage version instead.
>>>>
>>> If you can get this version marked stable, that will solve the
>>> problem.  I don't know how many other unrelated changes are in .20 so
>>> I don't know how feasible a quick-stable is.
>> There are a couple of important problems with portage-2.3.20 that are
>> fixed in portage-2.3.21, so you should use portage-2.3.21 instead:
>>
>> * Bug 645416 dep_zapdeps: fix virtual/rust handling (regression)
>>
>> * Bug 645780 add --changed-deps-report option (in order to help users
>> cope with the new --dynamic-deps=n default introduced in portage-2.3.20).
> How much of the new 'gemato' features are included in .21 Zac? Is there
> any way we can backport the regression to .20 ?
>
> What are the stabilisation targets currently for .20 and .21 respectively?
We really can't stabilize portage-2.3.20 due to the above bugs.

Do you have any specific issues with the gemato support in
portage-2.3.21? We can always mask the rsync-verify USE flag if we need
to disable that feature.
--
Thanks,
Zac


signature.asc (231 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

M. J. Everitt
On 30/01/18 17:43, Zac Medico wrote:

> On 01/30/2018 09:18 AM, M. J. Everitt wrote:
>>
>> How much of the new 'gemato' features are included in .21 Zac? Is there
>> any way we can backport the regression to .20 ?
>>
>> What are the stabilisation targets currently for .20 and .21 respectively?
> We really can't stabilize portage-2.3.20 due to the above bugs.
>
> Do you have any specific issues with the gemato support in
> portage-2.3.21? We can always mask the rsync-verify USE flag if we need
> to disable that feature.
Hmm, ok let's defer discussion to #g-releng on IRC for a way forward.
Likely we'll just have to patch the releng portage overlay to get us
through ..
Cheers,
Michael.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Jorge Manuel B. S. Vicetto-2
In reply to this post by Zac Medico-2
On Tue, Jan 30, 2018 at 4:16 PM, Zac Medico <[hidden email]> wrote:

> On 01/30/2018 08:39 AM, Ben Kohler wrote:
>> On Tue, Jan 30, 2018 at 10:19 AM, Jorge Manuel B. S. Vicetto
>> <[hidden email]> wrote:
>>>
>>> I'd rather keyword the "fixed" portage version instead.
>>>
>> If you can get this version marked stable, that will solve the
>> problem.  I don't know how many other unrelated changes are in .20 so
>> I don't know how feasible a quick-stable is.
>
> There are a couple of important problems with portage-2.3.20 that are
> fixed in portage-2.3.21, so you should use portage-2.3.21 instead:
>
> * Bug 645416 dep_zapdeps: fix virtual/rust handling (regression)
>
> * Bug 645780 add --changed-deps-report option (in order to help users
> cope with the new --dynamic-deps=n default introduced in portage-2.3.20).
> --
> Thanks,
> Zac

I believe there was some misunderstanding about my comment.
I meant I prefer to add to our /etc/portage/package.keywords an entry
for a portage version with this issue fixed.
Per Zac's comment above, I'll do that for portage2.3.21.

Thanks,
Jorge.

Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Ben Kohler
On Tue, Jan 30, 2018 at 12:54 PM, Jorge Manuel B. S. Vicetto
<[hidden email]> wrote:
> I believe there was some misunderstanding about my comment.
> I meant I prefer to add to our /etc/portage/package.keywords an entry
> for a portage version with this issue fixed.
> Per Zac's comment above, I'll do that for portage2.3.21.
>
> Thanks,
> Jorge.
>

You're going to ship unstable portage in stage3 just to avoid adding a
temporary portage config that users won't even see?

That seems questionable, but I guess if it gets autobuilds back on
track, it's something.

-Ben

Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Jorge Manuel B. S. Vicetto-2
On Tue, Jan 30, 2018 at 8:57 PM, Ben Kohler <[hidden email]> wrote:

> On Tue, Jan 30, 2018 at 12:54 PM, Jorge Manuel B. S. Vicetto
> <[hidden email]> wrote:
>> I believe there was some misunderstanding about my comment.
>> I meant I prefer to add to our /etc/portage/package.keywords an entry
>> for a portage version with this issue fixed.
>> Per Zac's comment above, I'll do that for portage2.3.21.
>>
>> Thanks,
>> Jorge.
>>
>
> You're going to ship unstable portage in stage3 just to avoid adding a
> temporary portage config that users won't even see?

AFAICS, the real solution here is not to try to play "whac-a-mole",
but to get a consistent resolution by portage - which requires using a
version that is currently unstable (pending stabilization at a later
date).

Zac,
do you foresee any issue with users getting a downgrade from 2.3.21 to
the latest stable? At that point, the virtual providers were already
picked, so they shouldn't be affected by this issue. Are there any
features on 2.3.21 that may cause "regressions" is users end up
downgrading to the current latest stable?

> That seems questionable, but I guess if it gets autobuilds back on
> track, it's something.
>
> -Ben
>

Reply | Threaded
Open this post in threaded view
|

Re: Workaround for stage1 failures introduced with portage-2.3.19-r1

Zac Medico-2
On 01/30/2018 02:44 PM, Jorge Manuel B. S. Vicetto wrote:

> On Tue, Jan 30, 2018 at 8:57 PM, Ben Kohler <[hidden email]> wrote:
>> On Tue, Jan 30, 2018 at 12:54 PM, Jorge Manuel B. S. Vicetto
>> <[hidden email]> wrote:
>>> I believe there was some misunderstanding about my comment.
>>> I meant I prefer to add to our /etc/portage/package.keywords an entry
>>> for a portage version with this issue fixed.
>>> Per Zac's comment above, I'll do that for portage2.3.21.
>>>
>>> Thanks,
>>> Jorge.
>>>
>>
>> You're going to ship unstable portage in stage3 just to avoid adding a
>> temporary portage config that users won't even see?
>
> AFAICS, the real solution here is not to try to play "whac-a-mole",
> but to get a consistent resolution by portage - which requires using a
> version that is currently unstable (pending stabilization at a later
> date).
>
> Zac,
> do you foresee any issue with users getting a downgrade from 2.3.21 to
> the latest stable? At that point, the virtual providers were already
> picked, so they shouldn't be affected by this issue. Are there any
> features on 2.3.21 that may cause "regressions" is users end up
> downgrading to the current latest stable?
There are not problems like that, the downgrade should be smooth.
--
Thanks,
Zac


signature.asc (231 bytes) Download Attachment