On 2026-05-17, Noé Lopez wrote: > 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
Well, the moment the next YYYYMMDD patch comes out, the hash for the zip file would change, as it contains all the patches, and would break future builds... > 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") …)) Yeah, an approach more-or-less like this is what someone helped me work out, by downloading the individual patches and applying them in a phase... and it also requires decompressing the patches ... although it is not as elegant as I would have hoped... Basically created a for-each loop of origins with all the patches and their hashes... unfortunately duplicated the list of patches, once for the origins, and once for the patches to apply ... that would be ideal to simplify. > Definitely, it would be wrong to add those patches to > gnu/packages/patches, since these are not specific to or modified by > guix. Hrm. :( > At worse, add one origin per patch, then loop the same. Ideally I could add all the patches as a single input and decompress them, although that takes some more fiddling. live well, vagrant
signature.asc
Description: PGP signature
