Request for merging "mesa-updates" branch

Open

Details

4 participants

Efraim Flashner
John Kehayias
Sharlatan Hellseher
Steve George

Owner: unassigned

Submitted by: John Kehayias

Severity: normal

John Kehayias wrote on 16 Sep 04:38 +0200

Recipients:(name . Guix-patches)(address . guix-patches@gnu.org)(name . Efraim Flashner)(address . efraim.flashner@gmail.com)

Message-ID:87bk0opbl7.fsf_-_@protonmail.com

Hello Guix,

The mesa-updates branch I think is just almost ready for merging. Besides some other fixes and updates, the main series is tracked at https://issues.guix.gnu.org/73071. There is an update to add NVK support to mesa for x86_64-linux which I need to review and push (and rebase to get more fixes from master).

Coverage looks good for x86_64 and i686 on QA, with powerpc64le as well on Berlin. I worry that aarch64 and others may have stalled out on Bordeaux. Perhaps Efraim can chime in there.

With an update for NVK for x86_64, that will take maybe a day to catch up again in builds but tends to be pretty quick. I'm not aware of other blockers.

Thanks!

John

Efraim Flashner wrote on 23 Sep 07:34 +0200

Recipients:(name . John Kehayias)(address . john.kehayias@protonmail.com)(address . 73288@debbugs.gnu.org)

Message-ID:ZvD981JawvibgfcO@3900XT

On Mon, Sep 16, 2024 at 02:38:16AM +0000, John Kehayias via Guix-patches via wrote:

Toggle quote (9 lines)

> Hello Guix,

> The mesa-updates branch I think is just almost ready for merging. Besides some other fixes and updates, the main series is tracked at <https://issues.guix.gnu.org/73071>. There is an update to add NVK support to mesa for x86_64-linux which I need to review and push (and rebase to get more fixes from master).

> Coverage looks good for x86_64 and i686 on QA, with powerpc64le as well on Berlin. I worry that aarch64 and others may have stalled out on Bordeaux. Perhaps Efraim can chime in there.

> With an update for NVK for x86_64, that will take maybe a day to catch up again in builds but tends to be pretty quick. I'm not aware of other blockers.

I built out to gtk+@3 and gtk on aarch64 without any problems, and I

also built mesa on riscv64 and armhf without any problems.

I haven't tested running any programs on those architectures.

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

John Kehayias wrote 4 days ago

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:87msjq57b3.fsf@protonmail.com

Hello,

Thanks for the report and testing, Efraim!

I'm cc'ing guix-devel to see if anyone else wants to weigh in here:

On Mon, Sep 23, 2024 at 08:34 AM, Efraim Flashner wrote:

Toggle quote (23 lines)> On Mon, Sep 16, 2024 at 02:38:16AM +0000, John Kehayias via Guix-patches via wrote:
>> Hello Guix,
>>
>> The mesa-updates branch I think is just almost ready for merging.
>> Besides some other fixes and updates, the main series is tracked at
>> <https://issues.guix.gnu.org/73071>. There is an update to add NVK
>> support to mesa for x86_64-linux which I need to review and push
>> (and rebase to get more fixes from master).
>>
>> Coverage looks good for x86_64 and i686 on QA, with powerpc64le as
>> well on Berlin. I worry that aarch64 and others may have stalled out
>> on Bordeaux. Perhaps Efraim can chime in there.
>>
>> With an update for NVK for x86_64, that will take maybe a day to
>> catch up again in builds but tends to be pretty quick. I'm not aware
>> of other blockers.
>>
>
> I built out to gtk+@3 and gtk on aarch64 without any problems, and I
> also built mesa on riscv64 and armhf without any problems.
>
> I haven't tested running any programs on those architectures.

Progress on QA/Bordeaux is, from what I hear, waiting in line behind
other branch merge requests (one is from many months ago and I don't
think will be ready soon). I think this branch is ready to merge, the
only potential issue is lower substitute coverage on
non-i686/x86_64-linux architectures. (Note that although QA shows only
in the 80% range, it was about the same as master before the more
recent rebases. No idea why as I can't find new failures that would
cause this.)

So, what shall we do? Personally, I would merge it now with the
understanding that substitutes will take time (weeks? months?) to
catch up. I don't think we have the capacity to be quicker even if
there was only one active non-master branch for these architectures.
Is this correct?

While at times issues crop up, in my experience the mesa update part
of mesa-updates (which is almost entirely what is in this current
branch) rarely causes many issues, just lots of rebuilds. We can also
always revert if something was missed. I would be happy to add a news
entry as a warning to anyone relying on substitutes for other
architectures, if that is helpful.

Thoughts? Concerns? Guidance we can solidify going forward?

Thanks!
John

Sharlatan Hellseher wrote 24 hours ago

Request for merging "mesa-updates" branch

Recipients:(address . 73288@debbugs.gnu.org)

Message-ID:87cyki6xbi.fsf@gmail.com

Hi,

The current queue of branches awaiting for review and merge:

- https://qa.guix.gnu.org/branch/python-team

#71408 It was closed due to a large amount of merge conflicts which

can't be resolved quick enough not blocking other changes (CC Steve who

started cherry pick process)

- https://qa.guix.gnu.org/branch/fonts-split-outputs

#72959 Needs to be rebased and place new evaluation (Cc Ludovic)

- https://qa.guix.gnu.org/branch/r-team

#73104 I've pinged R team members if that branch may be merged, the

changes touch just R packages from CRAN and Bioconductor. QA passed.

- https://qa.guix.gnu.org/branch/mesa-updates

#73288 I'd love to have that branch merged, it would help to pack more

projects for Astro* soft =).

- https://qa.guix.gnu.org/branch/go-team

#73502 I've rebased it recently and pushed again it looks like most of

the major builds passed successfully, some architectures (aarch64) are

lagged behind. The branch is ready and would let me complete packaging

Prometheus and start large unbundle task.

- https://qa.guix.gnu.org/branch/qt-team

#73515 QA is unhappy: "Unable to check changes between branch and

master. Merge base has not be processed by the data service yet."

- https://qa.guix.gnu.org/branch/wip-gsl-upgrade

#73558 not picked up yet: "Unable to check changes between branch and master.

Merge base has not be processed by the data service yet."

- https://qa.guix.gnu.org/branch/lisp-team

#73567 not picked up yet: "Information unavailable"

Oleg

Steve George wrote 12 hours ago

Recipients:

Message-ID:69a3b3fb-4317-4d8d-b5a2-104dd62c8222@futurile.net

Hi,

On 02/10/2024 21:53, Sharlatan Hellseher wrote:

(...)

Toggle quote (11 lines)> The current queue of branches awaiting for review and merge:
> 
> | 71408 | python-team         | Fri Jun 07 10:55:25+0200 2024 | Done |
> | 72959 | fonts-split-outputs | Mon Sep 02 12:55:25+0200 2024 | Open |
> | 73104 | r-team              | Sat Sep 07 17:55:24+0200 2024 | Open |
> | 73288 | mesa-updates        | Mon Sep 16 04:38:25+0200 2024 | Open |
> | 73502 | go-team             | Thu Sep 26 23:40:25+0200 2024 | Open |
> | 73515 | qt-team             | Fri Sep 27 14:46:24+0200 2024 | Open |
> | 73558 | wip-gsl-upgrade     | Sun Sep 29 22:33:24+0200 2024 | Open |
> | 73567 | lisp-team           | Mon Sep 30 15:43:28+0200 2024 | Open |
> 

(...)

Toggle quote (3 lines)

> - https://qa.guix.gnu.org/branch/r-team

> #73104 I've pinged R team members if that branch may be merged, the

> changes touch just R packages from CRAN and Bioconductor. QA passed.

(...)

What's the definition of when a branch looks good for merging? Does some

% of substitutes have to be achieved, and for which architectures?

https://qa.guix.gnu.org/branch/r-teamshows 96% for x86_64 which is .4 %

higher than current master [0]. So it's a win by merging it! ;-)

Seriously, it's also at 96% for aarch64-linux (bordeaux). So "it looks

good to me".

If that's the case, what prevents this "just" being merged?

Presumably r-team demonstrated their desire for it to be merged by

opening the merge request ticket. Is it a break in process if someone

else does it? (rather than waiting for them to respond).

Toggle quote (4 lines)

> - https://qa.guix.gnu.org/branch/mesa-updates

> #73288 I'd love to have that branch merged, it would help to pack more

> projects for Astro* soft =).

https://qa.guix.gnu.org/branch/mesa-updatesdoesn't look as good to me.

Fine on x86_64, but aarch64-linux is lower than master. Unsure if this

is due to the build farms still trying to catch-up?

Toggle quote (6 lines)

> - https://qa.guix.gnu.org/branch/go-team

> #73502 I've rebased it recently and pushed again it looks like most of

> the major builds passed successfully, some architectures (aarch64) are

> lagged behind. The branch is ready and would let me complete packaging

> Prometheus and start large unbundle task.

This looks about the same as Mesa-upates to me.

Is there a way to compare master<-->go-team to see if different packages

are failing?

We shouldn't make master break in new ways by merging right!

Steve / Futurile

[0] https://qa.guix.gnu.org/branch/master

Steve George wrote 12 hours ago

Recipients:

Message-ID:a477ded9-43ed-4be0-ba52-b16163fc8739@futurile.net

On 02/10/2024 21:53, Sharlatan Hellseher wrote:

Toggle quote (20 lines)> 
> Hi,
> 
> The current queue of branches awaiting for review and merge:
> 
> | 71408 | python-team         | Fri Jun 07 10:55:25+0200 2024 | Done |
> | 72959 | fonts-split-outputs | Mon Sep 02 12:55:25+0200 2024 | Open |
> | 73104 | r-team              | Sat Sep 07 17:55:24+0200 2024 | Open |
> | 73288 | mesa-updates        | Mon Sep 16 04:38:25+0200 2024 | Open |
> | 73502 | go-team             | Thu Sep 26 23:40:25+0200 2024 | Open |
> | 73515 | qt-team             | Fri Sep 27 14:46:24+0200 2024 | Open |
> | 73558 | wip-gsl-upgrade     | Sun Sep 29 22:33:24+0200 2024 | Open |
> | 73567 | lisp-team           | Mon Sep 30 15:43:28+0200 2024 | Open |
> 
> - https://qa.guix.gnu.org/branch/python-team
> #71408 It was closed due to a large amount of merge conflicts which
> can't be resolved quick enough not blocking other changes (CC Steve who
> started cherry pick process)
> 

There are 231 commits ahead of master.

I propose to break this into groups of 30-50 commits at a time.

Excluding the build-system changes that Lars [0] said they would do.

Rebase on current master and test that they don't make master 'worse' [1]

Each 30-50 can be put into a new branch for a smaller 'merge-train', to

see if it makes merging faster overall.

I did the first 31 and tested them. A new branch and merge-request could

be created for them [2].

I need someone to collaborate with as I can't do that myself.

However, looks like everyone in python-team is busy atm.

I'll cherry-pick the next tranche if someone has the time to work with

me on merging them - otherwise I'm wasting my time :-)

Steve / Futurile

[0] https://issues.guix.gnu.org/71408#8

[1] no additional breakage, though there are quite a few broken packages

[2] https://issues.guix.gnu.org/71408#13

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 73288@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 73288

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date