On 2026-05-16, Kaelyn wrote: > On Friday, May 15th, 2026 at 11:56 PM, Vagrant Cascadian <[email protected]> > wrote: > >> On 2026-05-12, Vagrant Cascadian wrote: >> > On 2026-05-13, Nguyễn Gia Phong via "Development of GNU Guix and the GNU >> > System distribution." wrote: >> >> On 2026-04-09 at 00:07+09:00, Nguyễn Gia Phong wrote: >> >>> This branch is for queuing world rebuild changes >> >>> not under the scope of any existing team (or under too many). >> ... >> >> If you have been holding off any package update because it has >> >> many dependents but has not been adopted by any team, doing that >> >> in the next week or two might be a good idea. >> > >> > I think ncurses-with-tinfo could be merged into regular ncurses with >> > very low risks... which would trigger over 9000 rebuilds... originally >> > introduced ncurses-with-tinfo around 2022 or so as some packages needed >> > the tinfo parts and did not want to trigger a world rebuild at the >> > time... and here we are, 4 years later. :) >> > >> > Should I submit a pull request for this against the misc-world-rebuild >> > branch? >> > >> > It sort of makes sense at the same time, but possibly higher risk, to >> > actually update ncurses... from 6.2.x (~2021) to 6.6.x (2025)? >> >> Submitted ncurses/tinfo (a.k.a. "ncurses-with-tinfo") merge into >> ncurses, and ncurses update to 6.6 as: >> >> https://codeberg.org/guix/guix/pulls/8662 >> >> There are numerous patches that need applying to get up to the currently >> published patchsets for ncurses up to 6.6.20260509: >> >> https://invisible-mirror.net/archives/ncurses/6.6/ >> >> Help figuring out a clean way to import all those patches would be >> appreciated, as they need to be applied in sequence. >> > > Hi, I have an initial thought about handling the patches, which I know > might still be a bit tedious, and likely obvious to others, but I > still feel is worth mentioning: Either as a list of patches in the > source field (assuming Guix applies the patches in list order) or as > an added phases like the current ncurses package (or even as the > source for separate "patch" packages a little like the > wine-staging-patchset-data package), have a simple generator loop that > takes a list of dates like '("20251230" "20251231" "20260103") and > expands that list of date strings into the > "ncurses-X.X-YYYYMMDD.patch.gz" paths. Then maintaining the list of > patches in the future would be just adding dates to that list. One > could even potentially add the date of the last element in the list to > the version field of the ncurses package.
Sure, or even manually adding each of the patches to gnu/packages/patches/ and just using search-patches... that would certainly be the simplest, most transparent option. Other options would be to make a patch definition and apply it in a phase, which would at least require the date-version and the hash for the relevent date-version patch, which might actually be more work than just including the patches in gnu/packages/patches/ ... None of it is pretty ... wonder if I can find a VCS for ncurses with all the patches applied; have not looked too hard yet. :) live well, vagrant
signature.asc
Description: PGP signature
