Bootstrap a GNU source distribution from git

2024-09-29 Thread Vivien Kraus
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

2024-03-18 Thread Vivien Kraus
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

2024-03-16 Thread Vivien Kraus
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!

2024-02-22 Thread Vivien Kraus
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

2024-02-10 Thread Vivien Kraus
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?

2024-02-10 Thread Vivien Kraus
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?

2024-02-10 Thread Vivien Kraus
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

2024-02-05 Thread Vivien Kraus
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

2024-02-01 Thread Vivien Kraus
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

2024-01-31 Thread Vivien Kraus
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?

2023-12-17 Thread Vivien Kraus
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.

2023-12-10 Thread Vivien Kraus
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.

2023-12-08 Thread Vivien Kraus
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.

2023-10-31 Thread Vivien Kraus
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

2023-10-24 Thread Vivien Kraus
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

2023-09-19 Thread Vivien Kraus
---
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

2023-09-18 Thread Vivien Kraus
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