Vagrant Cascadian <[email protected]> writes: > 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
Just my stupid opinion:
If all the patches are in the zip archive, why not at that archive as an
an origin in the inputs field and then apply all the patches using a
simple for-each phase like this:
(for-each
(lambda (patch)
(invoke "patch"" patch) ;;i have no idea how to actually invoke patch
)
(scandir (assoc-ref inputs "ncurses-patches") …))
Definitely, it would be wrong to add those patches to
gnu/packages/patches, since these are not specific to or modified by
guix. At worse, add one origin per patch, then loop the same.
Have a nice day,
Noé
signature.asc
Description: PGP signature
