Re: Core updates status

[Josselin Poiret <dev@jpoiret.xyz>]

[-- Attachment #1.1: Type: text/plain, Size: 1126 bytes --]

Hi Ludo,

Ludovic Courtès <ludo@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.


[-- Attachment #1.2: scheme script to filter commit list --]
[-- Type: text/plain, Size: 1229 bytes --]

#!/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))

[-- Attachment #1.3: Type: text/plain, Size: 878 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]