Hi Ludo, Ludovic Courtès <l...@gnu.org> writes:
> I’m in favor of whatever allows us to move forward more quickly, so > temporarily stashing away the pkgconf changes sounds good to me. > > In that case, when time permits, could you push a ‘core-updates-new’ (?) > branch, (partially) rebased and without the pkgconf changes, and a > separate ‘wip-pkgconf’ branch? Does that seem doable to you? I did that partially yesterday, moved the old borked core-updates to old-core-updates and pushed the cleaned-up version at core-updates. I haven't pushed the pkgconf patches anywhere yet, but we should probably focus on c-u for now and worry about that later. > It would be great if you could also explain at which commit you started > rebasing ‘core-updates’¹ and which method/script you used. I started rebasing at the very first commit of core-updates that wasn't reachable from master (it is a rebase after all). I wrote a little script (attached) that basically filters `git rev-list` output, removing commits for which a commit with the same name appears on master after 1.4.
#!/usr/bin/env -S guile -s
!#
(use-modules (ice-9 popen)
(ice-9 textual-ports))
(define (check name)
(let* ((input+output (pipe))
(pid (spawn "git"
(list "git"
"log"
"-n1"
"v1.4.0..origin/master"
"-F"
(string-append "--grep=" name))
#:output (cdr input+output))))
(close-port (cdr input+output))
(define res
(let loop ((n 0))
(if (eof-object? (get-line (car input+output)))
n
(loop (+ 1 n)))))
(close-port (car input+output))
(waitpid pid)
(> res 0)))
(check "gnu: Add glirc.")
(let ((port (open-input-pipe "git rev-list --no-merges
origin/master..origin/core-updates --pretty=oneline")))
(define res
(let loop ((acc '()))
(let ((line (get-line port)))
(if (eof-object? line)
acc
(loop (cons line acc))))))
(close-pipe port)
(for-each
(lambda (line)
(unless (check (string-drop line 41))
(format #t "~a~%" line)))
res))
;; (unless (check (string-drop line 41))
;; (format #t "~a~%" line))
The one thing that we need to do right now is update glibc 2.39 with all the fixes from the upstream release/2.39/master branch. I don't think we've done this before significantly, but since we have an occasion this time we might as well. We can't really use git-fetch for glibc, so imo the only feasible option is like what Debian does [1], which is keeping a diff of the 2.39 tag and the release branch and applying it as a patch. We'll then probably need to add autotools to glibc builds, but this is doable even in commencement because we have them already available at that point. The own downside of this is that the patch name will not include the fixed CVEs, so guix lint won't be aware that the CVEs have been patched. [1] https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/git-updates.diff WDYT? Best, -- Josselin Poiret
signature.asc
Description: PGP signature
