* [bug#66964] mesa-updates: call for patches [not found] <87v8a3tw0s.fsf@protonmail.com> @ 2023-11-18 11:07 ` Christopher Baines 2023-11-20 5:41 ` John Kehayias via Guix-patches via 0 siblings, 1 reply; 3+ messages in thread From: Christopher Baines @ 2023-11-18 11:07 UTC (permalink / raw) To: John Kehayias; +Cc: 66964, guix-devel [-- Attachment #1: Type: text/plain, Size: 2448 bytes --] John Kehayias <john.kehayias@protonmail.com> writes: > Hi everyone, > > Update below: > > On Sun, Nov 05, 2023 at 11:47 PM, John Kehayias wrote: > [snippy snip snip] >>> >>> Happy to! Substitutes will eventually become available, but there's >>> quite a few builds to be done. This takes care of some ungrafts and >>> updates with I hope minimal disruption. I'll be keeping an eye out and >>> using locally as well. Please test and report, thanks everyone! >>> >>> John >> >> An issue was created to track merging the mesa-updates branch here: >> <https://issues.guix.gnu.org/66964>. Please use that bug number as >> needed (and cc me or use wide-reply in emacs debbugs). > > At this point I feel we are just about ready to go, unless there are > objections? > > Substitute coverage, according to > <https://qa.guix.gnu.org/branch/mesa-updates> is good on x86_64 and > i686 (about 95% and 83%, respectively) while, as usual, other > architectures are behind. The next best is aarch64 at 54% on bordeaux, > and then falling to 24% for armhf, with others we build in the teens. > I think this is to be expected? In any event builds continue very > slowly and in the past I think this is about where we merge. I think some changes have been pushed since this email, since the aarch64 substitute availability has dropped from 54% to 25%. > So, shall I merge this to master in the next couple of days? I've been > merging master into mesa-updates smoothly so far. Please do check and > feel free to object if this needs more time. I guess this has been held up by the changes on the 15th, but still, I think we need to wait for substitute availability to improve more prior to merging, unless there's a specific and significant reason why we don't want to wait. Targets are arbitrary, but guix weather defines ☀ as 80%+, so I think that's what we should aim for at least for x86_64-linux, i686-linux, aarch64-linux and armhf-linux. This isn't just about substitute availability though as this is key for discovering what things fail to build. Obviously delays in merging aren't ideal, but we should tackle the problems around this, maybe by deciding that testing and providing substitutes for ARM isn't a priority and thus isn't something we should wait for, or look at getting more ARM hardware to speed up the process (we also have a lack of x86_64 hardware on the bordeaux build farm). [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* [bug#66964] mesa-updates: call for patches 2023-11-18 11:07 ` [bug#66964] mesa-updates: call for patches Christopher Baines @ 2023-11-20 5:41 ` John Kehayias via Guix-patches via 0 siblings, 0 replies; 3+ messages in thread From: John Kehayias via Guix-patches via @ 2023-11-20 5:41 UTC (permalink / raw) To: Christopher Baines; +Cc: 66964, guix-devel Hi, On Sat, Nov 18, 2023 at 11:07 AM, Christopher Baines wrote: > > John Kehayias <john.kehayias@protonmail.com> writes: > >> Hi everyone, >> >> Update below: >> >> On Sun, Nov 05, 2023 at 11:47 PM, John Kehayias wrote: >> [snippy snip snip] >> >> At this point I feel we are just about ready to go, unless there are >> objections? >> >> Substitute coverage, according to >> <https://qa.guix.gnu.org/branch/mesa-updates> is good on x86_64 and >> i686 (about 95% and 83%, respectively) while, as usual, other >> architectures are behind. The next best is aarch64 at 54% on bordeaux, >> and then falling to 24% for armhf, with others we build in the teens. >> I think this is to be expected? In any event builds continue very >> slowly and in the past I think this is about where we merge. > > I think some changes have been pushed since this email, since the > aarch64 substitute availability has dropped from 54% to 25%. > Yes, Efraim chimed in to help on some other architectures and some big rebuilds were/are happening for those. I see them slowly ticking up but it will still need some time. >> So, shall I merge this to master in the next couple of days? I've been >> merging master into mesa-updates smoothly so far. Please do check and >> feel free to object if this needs more time. > > I guess this has been held up by the changes on the 15th, but still, I > think we need to wait for substitute availability to improve more prior > to merging, unless there's a specific and significant reason why we > don't want to wait. > Yes, agreed. I'm not as clear on how well we do typically on non-x86 but getting a sense of it now, which is why I wanted to ask. > Targets are arbitrary, but guix weather defines ☀ as 80%+, so I think > that's what we should aim for at least for x86_64-linux, i686-linux, > aarch64-linux and armhf-linux. This isn't just about substitute > availability though as this is key for discovering what things fail to > build. > I think this is something we could better clarify and quantify as many of us probably only pay attention to x86_64, where for others we can be strapped for both hardware and people. So I didn't want to wait for some substitutes that would never come but also don't want to inconvenience people on other architectures, especially if builds there take much much longer in the first place. Perhaps we can look at some historical data on what we've hit in substitute coverage and try to at least keep up with that if not set some goals for better coverage? While we might also expect further difficulties as some get left behind by upstream (as we've had to work around rust on i686 so far, I believe). All that is to say, yes, let's make sure we have good substitute coverage and are clear on what architectures we want to make sure users get substitutes for. > Obviously delays in merging aren't ideal, but we should tackle the > problems around this, maybe by deciding that testing and providing > substitutes for ARM isn't a priority and thus isn't something we should > wait for, or look at getting more ARM hardware to speed up the process > (we also have a lack of x86_64 hardware on the bordeaux build farm). > Agreed. We should have some clear Guix-wide standards and goals. I'm sure we can get some hardware from Guix-ers and/or funding too, especially if people know exactly what it will go towards improving. Thanks for chiming in here and all your work on this front! In the meantime, I'll go back to refreshing the CI and QA pages every so often to make sure we keep getting closer... ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <878r7b32qm.fsf@protonmail.com>]
* [bug#66964] mesa-updates: call for patches [not found] <878r7b32qm.fsf@protonmail.com> @ 2023-11-12 20:01 ` Kaelyn via Guix-patches via 0 siblings, 0 replies; 3+ messages in thread From: Kaelyn via Guix-patches via @ 2023-11-12 20:01 UTC (permalink / raw) To: John Kehayias; +Cc: guix-devel, 66964@debbugs.gnu.org Hi, I've just submitted a pair of patches for the mesa-updates branch: <https://issues.guix.gnu.org/67136> updating xorgproto and xorg-server-xwayland. The xorgproto is a high-impact update (guix refresh reports rebuilding 8710 packages would ensure 22871 dependent packages are rebuilt), but required to update to the latest xwayland as xwayland requires a newer version of presentproto than in the current guix xorgproto package. The updating and ungrafting of mesa and a number of X.org related libraries seemed like a good time (and place) to update xorgproto as well. Cheers, Kaelyn ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-11-20 5:42 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87v8a3tw0s.fsf@protonmail.com> 2023-11-18 11:07 ` [bug#66964] mesa-updates: call for patches Christopher Baines 2023-11-20 5:41 ` John Kehayias via Guix-patches via [not found] <878r7b32qm.fsf@protonmail.com> 2023-11-12 20:01 ` Kaelyn via Guix-patches via
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).