Bootstrap a GNU source distribution from git
Dear Guix,
GNU sources are usually shipped as tarballs with some pre-compiled
sources included. This can be a bit scary at times, so the question now
is, can we skip the tarballs and build everything from human-authored
sources?
I first want to emphasize that distributing generated sources is an
important feature of a build system. It is necessary for it to boast
cross-compilation support, and for packages doing simple forms of
introspection (such as using help2man or gobject introspection) it may
even be sufficient. There are other nice things as well, so with that
in mind, let us open the black box and see what the maintainers are
hiding from us.
I chose Hello. After a bit of guixing around, it works:
guix build -f hello.scm
shows the build, and
guix build --source -f hello.scm
shows the full source distribution (although it is not in a tar because
it would have additional reproducibility problems).
So, what are the hello maintainers hiding from us?
— they use gnulib;
— the translations are not in the git repository, so their release
process involves fetching stuff from the web and packing it in;
— the manpage generation depends on the presence of a ".git" folder;
— they have perl installed;
— they have a bunch of autotools, included code generators (gperf);
— they work in the git repository to have a meaningful version number
and commit log (for the ChangeLog);
— the manual displays its revision date, but we don’t know how it is
computed (I suspect the revision date is the last time the maintainer
who did the release edited or git-pulled the texinfo source, which,
let’s agree on that, is not very precise).
I could not fully recover the release source (I am not attempting bit-
reproducibility) because:
— the translations were lost;
— the ChangeLog was lost;
— the manual revision date was lost;
— guix’ patched shebangs leaked in the sources.
This is a mixed responsibility problem. The big point here is
translations. I understand that using translationproject.org means that
committing the translations would storm the repository with automated
commits, which would be undesirable. Maybe Software Heritage could
help?
Happy hacking!
Vivien
(use-modules
((guix licenses) #:prefix license:)
(guix build-system gnu)
(guix gexp)
(guix packages)
(guix git-download)
(gnu packages autotools)
(gnu packages base)
(gnu packages gettext)
(gnu packages gperf)
(gnu packages man)
(gnu packages perl)
(gnu packages texlive)
(gnu packages texinfo))
(define hello-dist
(package
(name "hello-dist")
(version "2.12.1")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://git.savannah.gnu.org/git/hello.git";)
(commit (string-append "v" version))
;; hello uses gnulib as a submodule
(recursive? #t)))
(file-name (string-append "hello-" version "-checkout"))
(sha256
(base32
"0k8ibhlj7v6i0ynzldkfg5r8p78m1mkczci0drr6h9z7n85vfacy"
(build-system gnu-build-system)
(arguments
(list
#:phases
#~(modify-phases %standard-phases
(replace 'bootstrap
(lambda* (#:key native-inputs inputs #:allow-other-keys)
(substitute* "Makefile.am"
(("\\$\\(top_srcdir\\)/build-aux/gitlog-to-changelog")
;; This script requires a full git checkout, which we
;; do not provide. FIXME: The source ChangeLog will
;; not be relevant.
"true"))
(for-each
patch-shebang
;; These scripts should be patched early because they
;; are invoked by the bootstrap script (many more will
;; be patched after the bootstrap phase).
(list "bootstrap" "gnulib/gnulib-tool" "gnulib/build-aux/prefix-gnulib-mk"
"build-aux/git-version-gen"))
;; hello will only build the manual pages if it is run
;; from its git repository (read: if .git is an existing
;; directory, see configure.ac) because the maintainer
;; thinks no cross-compiling can happen in this case
;; presumably. It would be cool if the hello maintainer
;; could precisely identify the dependencies of the
;; manpage so that a manpage template could be
;; distributed.
(mkdir-p ".git")
(call-with-output-file ".tarball-version"
;; hello would compute the version number from state
;; of the git repository if .tarball-version did not
;; exist.
(lambda (port)
(format port "~a\n" #$version)))
(invoke "sh" "bootstrap"
"--no-git"
"--gnulib-srcdir=gnulib"
;; FIXME: package the po fi
Guix role in a free society
Hello, Free software enables cooperation in a free society. More precisely, it makes it easy for a user of a package to use a new version where the personal information has been corrected. The thread in [1] questions our handling of potential cases where a transgender contributor of Guix or one of its packages requests to change their name. While it would be nothing but cruel to deny such a request, I want to consider the broader case of updating personal information in general. If someone asks you to update your installation of a package to a new tarball with updated personal information (or a new tag in a rewritten history), then in a non-free society, you can only say, “Sorry, I’m not allowed to”. In a free society, you’re allowed to, and you have tools at your fingertips to make sure it’s harmless to you (diff with your old version, if you are alone, or collectively check that it follows semver, remember that it still has all the CVEs, and forget about the old thing). If accepting such a safe update makes a security system fire false positives (such as, guix pull saying there’s a downgrade attack if guix’ history has been safely rewritten), then it’s a limitation of the security system. If it’s too much work to silence this warning for a legitimate reason, then make an announcement about this particular false positive and let the user proceed. The guix users, I claim, would rather have a distribution of guix (and the packages it provides) with accurate personal information, even if it means to be annoyed for a moment with a security system. Best regards, Vivien [1] https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00138.html P.S. I am desensitized to eye-rolling when I talk about free software ;)
Re: Concerns/questions around Software Heritage Archive
Hello! Le samedi 16 mars 2024 à 17:50 +, Christopher Baines a écrit : > This is probably worth thinking about as Guix is in a similar > situation > regarding publishing source code, and people potentially wanting to > change historical source code both in things Guix packages and Guix > itself. I see two problems: 1. providing packages; 2. developing Guix itself. I am sure that 1. is not a real problem, we could just ask the developer to release a new version incrementing the patch number, upgrade it on our side, and forget the old version. Garbage collection would ultimately get rid of the old tarballs. 2. is more difficult, because Guix contributors sometimes change their names too, and a commit reading “update my name” is not the best solution. If I understand correctly, rewriting the history would be understood as a “downgrade attack”, contrary to the ftfy case where the developer could rewrite the history without such consequences. Is my understanding correct?
Re: You're invited to the first patch review session!
Hello! Le jeudi 22 février 2024 à 15:53 -0800, Vagrant Cascadian a écrit : > On 2024-02-22, Steve George wrote: > > We're going to run some online patch review sessions. The first one > > is on *Thursday, 7th March* and you can sign-up here: > > > > https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 > > Hoping to make it for some of these, thanks for doing it! > > One small point is if people could include the scheduled times in UTC > in > addition to "arbitrary" timezones. It is much easier to compare > against > UTC (especially because it does not do daylight savings time) if you > don't happen to be in one of the specified timezones. :) I believe this ical file represents the event accurately (for March 7), but I’m not the organizer. Best regards, Vivien BEGIN:VCALENDAR PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VTIMEZONE TZID:Europe/Paris X-LIC-LOCATION:Europe/Paris BEGIN:DAYLIGHT TZNAME:CEST TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19810329T02 RRULE:FREQ=YEARLY;UNTIL=20370329T01Z;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZNAME:CET TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19961027T03 RRULE:FREQ=YEARLY;UNTIL=20361026T01Z;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:17ffaaac680917ea4c9e1221f0788ff5d8f07d99 DTSTAMP:20240222T054943Z DTSTART;TZID=Europe/Paris:20240307T18 DTEND;TZID=Europe/Paris:20240307T192500 SEQUENCE:2 SUMMARY:Guix Patch Review Sessions 2024 TRANSP:OPAQUE URL:https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 DESCRIPTION:Each session is run at 18:00 CET (Paris)\, 17:00 BST (London)\, 13:00 EST (New York) and we'll generally try to:\n\n— Introduction to someone's patch review process (30 mins)\n— Patch review together (1 hour)\n\nThis will be an informal\, friendly and interactive environment where anyone can ask questions\, show how they do something or make suggestions. It's on-line which restricts things a little\, but the goal is to be interactive and learn together.\n\nIf there are particular topics or questions you'd like to explore please add them below. CLASS:PUBLIC CREATED:20240223T060822Z LAST-MODIFIED:20240223T060822Z X-EVOLUTION-CALDAV-ETAG: 5d7e787386622c655ff0945084556a2a576d778a4044080867938dd45fabee5f END:VEVENT END:VCALENDAR
Re: On the road to the next release: testing the installer
Le vendredi 09 février 2024 à 12:24 +0100, Tanguy LE CARROUR a écrit : > Grub asked me right away my passphrase and… it did not work! 😱 > After several attempts, I figured out that the keyboard layout > was apparently set to `qwerty` even though I had selected `bépo > AFNOR` > during the configuration. When I eventually typed my passphrase > in `querty` Grub started and boot my system and… I had to type the > passphrase a second time, but, fortunately this time in `bépo`! > I checked the `config.scm` and the layout was properly set in the > bootloader declaration. This is unfortunate, but a known workaround is to boot and log in, then run cryptsetup luksAddKey , then enter your passphrase (to unlock the drive), then switch your keyboard layout to qwerty, then hit the exact same keys, and confirm by hitting the exact same keys. So now, you can unlock the drive with either your passphrase in a bépo layout or your passphrase in a qwerty layout.
Re: QA is back, who wants to review patches?
Hello Chris, Le vendredi 09 février 2024 à 10:44 +, Christopher Baines a écrit : > Let me know if you have any comments or questions! Thank you for all your work on QA. I can’t help but notice QA is missing a few patches. For instance, issues.guix.gnu.org lists 7 open issues with patches for gnome-team (#67623, #67493, #67273, #6648, #68937, #68716, #68911) but if I search for gnome-team on qa.guix.gnu.org, it only shows 2: #68937 and #68716. Do you know why the others were lost? Best regards, Vivien
Re: QA is back, who wants to review patches?
Dear QA wizards, Le vendredi 09 février 2024 à 10:44 +, Christopher Baines a écrit : > You just need to not be involved (so you can't review your > own patches) I interpret this as it’s OK to review patches if you asked for a change in the thread, am I correct? Or is this too much involvement? Best regards, Vivien
Re: Guix Days: Patch flow discussion
Le lundi 05 février 2024 à 17:21 +, Suhail a écrit : > > Even if it would be just an auto-close (for the "contributor can't > > work effectively..." case). > > Are there current instances of "contributor can't work effectively"? > If > not, I propose that decisions concerning those situations be deferred > till we have actual instances to guide us. Maybe this encompasses the cases where the contributor sends a v1 and never addresses the review? I don’t fully understand what this means.
Re: Core-updates coordination and plans
Hello, Le mercredi 31 janvier 2024 à 17:44 +0100, Josselin Poiret a écrit : > Also, I see that most of the patches that were requested to be merged > into c-u (like the big pages for jemalloc) actually got pushed, are > there any other (well-tested) ones we can go for at the same time as > the > glibc rebuild? I will stress that this is about *core* packages now, > I feel that it's too late to introduce more complications and delay > the > update any longer. Is it too late to ask if you could cherry-pick the commits that show up in the d6462be6a8..b701a7018d range (from gnu: eudev: Update to 3.2.14. to gnu: upower: Update to 1.90.2. inclusive)? We have them on gnome- team, but maybe it would rather belong in core-updates. What do you think? Best regards, Vivien
Re: Core-updates coordination and plans
Dear guix, Le mercredi 31 janvier 2024 à 10:19 -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. a écrit : > Either way, I'd appreciate if Eudev could please be fixed in this > core-updates cycle. The fix has been available for more than half a > year. The eudev package has been touched on gnome-team (unmerged yet, sorry this is taking time) a few months ago with the following commits: d6462be6a8..498db4de1f I submitted these changes against gnome-team because we needed to update libgudev, but in retrospect, it might belong to core-updates. I don’t know if these changes will work with a non-updated libgudev. If we start changing eudev in divergent branches, then it might be a headache to merge. Could you try and rebase your work on gnome-team, to see whether it works? Best regards, Vivien
Re: Anyone working on more recent glib/gtk4 packages?
Le samedi 16 décembre 2023 à 09:35 -0800, Ian Eure a écrit : > I wanted to package Fractal, which is a native GNOME client for > Matrix chat. It requires newer versions of glib and gtk than are > currently in Guix. I believe I’ve seen in IRC that some folks are > working on getting GNOME 43/44 packages done, which probably needs > the glib/gtk updates to happen. Hello Ian, We are working on the "gnome-team" branch to provide GNOME 44.7. Not every 44.7 update is merged in the gnome-team branch yet, but you should at least find a more up-to-date glib, gtk and libadwaita. Best regards, Vivien
Re: RFI: Guix XMPP service.
Le dimanche 10 décembre 2023 à 17:45 +0200, MSavoritias a écrit : > > There is also a trust issue. For acceptance, we need bridging. For > > bridging, we need policing. And for policing, we need people with > > time. > > That's a good question yeah. Whether we want bridging that is. > Personally I am leaning that we don't. > > Because bridging can ruin the experience of people that use XMPP. But > I > can see it either way. Maybe we could do something a little smarter, like having sneek deliver messages in both IRC and XMPP. Vivien
Re: RFI: Guix XMPP service.
Hello Guix! Le vendredi 08 décembre 2023 à 19:22 +0200, MSavoritias a écrit : > I propose to host an xmpp instance with a room/or some rooms under > the > guix domain. Something like xmpp.guix.gnu.org Are there options for guests? I don’t know how XMPP or Prosody or cheogram.com may handle this, but the way I imagine it, we could have an array of guest accounts and reserve one for anyone that would ask for it, for something like a week. The guest accounts need not communicate with another server, so we wouldn’t relay spam. Maybe there’s something more convenient or more standard though. What do you think? Best regards, Vivien
[PATCH qa-frontpage] Sort the patches before applying them to the git branch.
By default, the patches are not ordered. Because of the unreliability of e-mail delivery, they can be received completely out of order. Patchwork may also re-order them, and they may get ordered by commit author date (or, equivalently, e-mail Date header). Both possibilities lead to failure to apply patches if the order is incorrect for two patches that do not commute. The patch name contains a header: [bug#xxx,v12,i/n] where "i" is the variable part and indicates the patch number. Git pads "i" with zeros if needed. The string order of the names is thus the true commit order. * guix-qa-frontpage/manage-patch-branches.scm (create-branch-for-issue): Sort patches according to their "name". --- guix-qa-frontpage/manage-patch-branches.scm | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/guix-qa-frontpage/manage-patch-branches.scm b/guix-qa-frontpage/manage-patch-branches.scm index a42f3a0..74d7b8b 100644 --- a/guix-qa-frontpage/manage-patch-branches.scm +++ b/guix-qa-frontpage/manage-patch-branches.scm @@ -243,8 +243,13 @@ (invoke-read-line "git" "show-ref" "--hash" base-tag))) (let loop ((patch-data - (vector->list - (assoc-ref patchwork-series "patches"))) + (stable-sort + (vector->list +(assoc-ref patchwork-series "patches")) + (lambda (patch-a patch-b) + (let ((name-a (assoc-ref patch-a "name")) + (name-b (assoc-ref patch-b "name"))) + (string
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Bonsoir Simon, Le mardi 24 octobre 2023 à 22:10 +0200, Simon Tournier a écrit : > Hi, > > Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19 > november for Capitole du Libre: > > https://capitoledulibre.org/ > > We will stand in Village Associatif. Let us know if you can help us > at the event. Well, I do not know exactly what means "a stand" since > it will be the first for me. :-) I guess it mainly consists to be > around the Guix booth, chat with people about why Guix is awesome! > and > maybe demo some Guix features. > > Feel free to share your ideas. :-) > > Concretely, if you are planning to come, let synchronize and share > the > fun. Andreas and I will be there. Who is in? Do not be shy and > drop > an email; off-list possibly. > > If you are there, please stop at the wonderful Guix kakemono and say > hi. > > Hope to see you soon. Je compte bien y aller ! Vivien
[PATCH qa-frontpage WIP] Add a library to parse patchwork json data
---
Hi!
Here is a small library that exports 3 types:
â is the collection of metadata that is present
in the square brackets in the patch names;
â is an individual item of the patch series;
â is a whole series of patches;
And a set of functions to parse and serialize these.
A fun experiment is to run the following script:
(use-modules (guix-qa-frontpage patchwork patch-series))
(use-modules (rnrs bytevectors))
(use-modules (web client))
(use-modules (ice-9 receive))
(use-modules (json))
(define patchwork-data
(receive (r body)
(http-get
"https://patches.guix-patches.cbaines.net/api/patches/?order=-id";)
(json-string->scm (utf8->string body
(define patchwork-series
(map scm->patch-series (vector->list patchwork-data)))
(for-each
(lambda (correct-series)
(display correct-series)
(newline))
(map patch-series->scm patchwork-series))
You will see that patchwork has quite a lot of creativity when it
comes to breaking my expectations. I made sure to add as much
information in exceptions so that we can understand what is happening.
Best regards,
Vivien
Makefile.am | 3 +
guix-qa-frontpage/patchwork/patch-name.scm | 117 +
guix-qa-frontpage/patchwork/patch-series.scm | 165 +++
guix-qa-frontpage/patchwork/patch.scm| 93 +++
4 files changed, 378 insertions(+)
create mode 100644 guix-qa-frontpage/patchwork/patch-name.scm
create mode 100644 guix-qa-frontpage/patchwork/patch-series.scm
create mode 100644 guix-qa-frontpage/patchwork/patch.scm
diff --git a/Makefile.am b/Makefile.am
index 79b7032..7b00ea9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -32,6 +32,9 @@ SOURCES =
\
guix-qa-frontpage/server.scm
\
guix-qa-frontpage/database.scm
\
guix-qa-frontpage/patchwork.scm
\
+ guix-qa-frontpage/patchwork/patch-name.scm
\
+ guix-qa-frontpage/patchwork/patch.scm
\
+ guix-qa-frontpage/patchwork/patch-series.scm
\
guix-qa-frontpage/guix-data-service.scm
\
guix-qa-frontpage/branch.scm
\
guix-qa-frontpage/issue.scm
\
diff --git a/guix-qa-frontpage/patchwork/patch-name.scm
b/guix-qa-frontpage/patchwork/patch-name.scm
new file mode 100644
index 000..1b4cd97
--- /dev/null
+++ b/guix-qa-frontpage/patchwork/patch-name.scm
@@ -0,0 +1,117 @@
+(define-module (guix-qa-frontpage patchwork patch-name)
+ #:use-module (srfi srfi-9)
+ #:use-module (srfi srfi-9 gnu)
+ #:use-module (ice-9 match)
+ #:use-module (ice-9 exceptions)
+ #:export (
+make-patch-name-metadata
+patch-name-metadata?
+patch-name-metadata-bug-number
+patch-name-metadata-feature-branch
+patch-name-metadata-revision
+patch-name-metadata-index
+patch-name-metadata-total
+patch-name-metadata-set-index
+
+&patch-name-parser-error
+patch-name-parser-error?
+make-patch-name-parser-error
+
+parse-patch-name
+synthesize-patch-name
+))
+
+(define-record-type
+ (make-patch-name-metadata bug-number feature-branch revision index total)
+ patch-name-metadata?
+ (bug-number patch-name-metadata-bug-number)
+ (feature-branch patch-name-metadata-feature-branch)
+ (revision patch-name-metadata-revision)
+ (index patch-name-metadata-index)
+ (total patch-name-metadata-total))
+
+(define (patch-name-metadata-set-index meta index)
+ (match meta
+(($ bug branch rev _ total)
+ (make-patch-name-metadata bug branch rev index total
+
+(set-record-type-printer!
+
+ (lambda (record port)
+ (match record
+ (($ bug feature revision index total)
+ (format port
+ "#< \
+bug-number=~s feature-branch=~s revision=~s \
+index=~s total=~s>"
+ bug feature revision index total)
+
+(define-exception-type &patch-name-parser-error
+ &error
+ make-patch-name-parser-error
+ patch-name-parser-error?)
+
+(define (parse-patch-name name)
+ "Given a patch @var{name} obtained from Patchwork, infer the metadata
+from its name."
+ (define (raise-error message)
+(raise-exception
+ (make-exception
+ (make-error)
+ (make-patch-name-parser-error)
+ (make-exception-with-message message)
+ (make-exception-with-irritants (list name))
+ (make-exception-with-origin 'parse-patch-name
+ (define (as-bug-number arg)
+(and (string-prefix? "bug#" arg)
+ (string->number (substring arg (string-length "bug#")
+ (define (as-revision arg)
+
[PATCH qa-frontpage] Apply incoming patches onto the correct feature branch
It seems that the only available information of the feature branch is
in the patch name.
---
Hello guix!
Thank you for making the QA tool. It seems to me that feature branches
are ignored for patches. The patches seem to always be applied on top
of master. I get that idea because the base-for-issue-* tag is always
put on HEAD, and all my patches targetting gnome-team recently get
applied to master. I understand that the latter could be a problem
with me.
If patches are indeed applied on top of master, then the question
arises, what to do. The available information from patchwork is
scarce: the base-commit is not available, and the optional feature
branch only appears in the name of the patches of the series.
I think it is possible to parse the patch names. This way, we get some
useful information: the feature branch, the series revision, and the
patch index. The patch index can be used to make sure the patches are
in correct order (this can be the case if a server in the path
re-orders the emails).
What do you think?
Best regards,
Vivien
guix-qa-frontpage/manage-patch-branches.scm | 80 +++--
1 file changed, 76 insertions(+), 4 deletions(-)
diff --git a/guix-qa-frontpage/manage-patch-branches.scm
b/guix-qa-frontpage/manage-patch-branches.scm
index 7f3adb1..0512680 100644
--- a/guix-qa-frontpage/manage-patch-branches.scm
+++ b/guix-qa-frontpage/manage-patch-branches.scm
@@ -102,6 +102,55 @@
(close-pipe pipe)
result))
+(define (parse-patch-name name)
+ (let ((args
+ (and
+ (string-prefix? "[" name)
+ (let ((stop (string-index name #\])))
+(substring name 1 stop
+(as-bug-number
+ (lambda (arg)
+ (and (string-prefix? "bug#" arg)
+(string->number (substring arg (string-length "bug#"))
+(as-v2
+ (lambda (arg)
+ (and (string-prefix? "v" arg)
+(string->number (substring arg 1)
+(as-patch-number
+ (lambda (arg)
+ (match (string-split arg #\/)
+ (((= string->number index) (= string->number total))
+ (and index total (<= index total)
+ (cons index total)))
+ (else #f)
+(let analyze ((bug-number #f)
+ (branch "master")
+ (version 1)
+ (index 1)
+ (total 1)
+ (arguments
+ (if args
+ (string-split args #\,)
+ '(
+ (match arguments
+((or ("") ())
+ `((bug-number . ,bug-number)
+ (branch . ,branch)
+ (version . ,version)
+ (index . ,index)
+ (total . ,total)))
+(((= as-bug-number (? number? new-bug-number))
+ arguments ...)
+ (analyze new-bug-number branch version index total arguments))
+(((= as-v2 (? number? new-version))
+ arguments ...)
+ (analyze bug-number branch new-version index total arguments))
+(((= as-patch-number ((? number? new-index) . (? number? new-total)))
+ arguments ...)
+ (analyze bug-number branch version new-index new-total arguments))
+((feature-branch arguments ...)
+ (analyze bug-number feature-branch version index total arguments))
+
(define (create-branch-for-issue issue-number patchwork-series)
(define (apply-patches)
(let ((series-data
@@ -116,9 +165,32 @@
(json->scm body)
(if (assoc-ref series-data "received_all")
- (let* ((patch-data
- (vector->list
- (assoc-ref series-data "patches")))
+ (let* ((annotated-patch-data
+ (map
+ (lambda (patch)
+ (let ((name (assoc-ref patch "name")))
+ `((patch . ,patch)
+ (metadata . ,(parse-patch-name name)
+ (vector->list
+(assoc-ref series-data "patches"
+ (patch-data
+ (map
+ (lambda (annotated)
+ (assq-ref annotated 'patch))
+ (stable-sort
+annotated-patch-data
+(lambda (a b)
+ (let ((a-meta (assq-ref a 'metadata))
+(b-meta (assq-ref b 'metadata)))
+(< (assq-ref a-meta 'index)
+ (assq-ref b-meta 'index)))
+ (feature-branch
+ (match annotated-patch-data
+((p rest ...)
+ (let ((meta (assq-ref p 'metadata)))
+ (if meta
+ (assq-ref meta 'branch)
+ "master")
(branch-name
(simple-format #f "issue-~A" issue-number))
(base-tag
@@ -127,7 +1
