[PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

  • Done
  • quality assurance status badge
Details
2 participants
  • Liliana Marie Prikler
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
Merged with
M
M
Maxim Cournoyer wrote on 9 Oct 2023 18:33
(address . guix-patches@gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
cover.1696868939.git.maxim.cournoyer@gmail.com
This series introduces default variable bindings for the default
gnu-build-system IMPORTED-MODULES and MODULES values. The lack of a
%default-gnu-modules caused enough confusion, as made apparent by this series.

Maxim Cournoyer (65):
build-systems: gnu: Export %default-gnu-imported-modules and
%default-gnu-modules.
gnu: acl: Remove labels and trailing #t.
gnu: acl: Import the correct set of modules.
gnu: dirvish: Import the correct set of modules.
gnu: fio: Import the correct set of modules.
gnu: ccwl: Import the correct set of modules.
gnu: boost: Import the correct set of modules.
gnu: gcc-final: Import the correct set of modules.
gnu: epson-inkjet-printer-escpr: Import the correct set of modules.
gnu: splix: Import the correct set of modules.
gnu: guile-curl: Import the correct set of modules.
gnu: dpkg: Import the correct set of modules.
gnu: dezyne: Import the correct set of modules.
gnu: fastcap: Import the correct set of modules.
gnu: fasthenry: Import the correct set of modules.
gnu: seabios-qemu: Import the correct set of modules.
gnu: font-amiri: Import the correct set of modules.
gnu: xdg-utils: Import the correct set of modules.
gnu: tsukundere: Import the correct set of modules.
gnu: gcc-4.9: Import the correct set of modules.
gnu: make-libstdc++: Import the correct set of modules.
gnu: custom-gcc: Import the correct set of modules.
gnu: gdb: Import the correct set of modules.
gnu: genimage: Import the correct set of modules.
gnu: gimp: Import the correct set of modules.
gnu: pinentry-rofi: Import the correct set of modules.
gnu: mozjs: Import the correct set of modules.
gnu: icecat-minimal: Import the correct set of modules.
gnu: icedove-minimal: Import the correct set of modules.
gnu: python-graph-tool: Import the correct set of modules.
gnu: artanis: Import the correct set of modules.
gnu: guilescript: Import the correct set of modules.
gnu: guile-dsv: Import the correct set of modules.
gnu: guile-di: Import the correct set of modules.
gnu: guile-hall: Import the correct set of modules.
gnu: haunt: Import the correct set of modules.
gnu: guile-studio: Import the correct set of modules.
gnu: guile-libyaml: Import the correct set of modules.
gnu: guile-gitlab: Import the correct set of modules.
gnu: guile-smc: Import the correct set of modules.
gnu: rime-data: Import the correct set of modules.
gnu: jbigkit: Import the correct set of modules.
gnu: uftrace: Import the correct set of modules.
gnu: mdadm-static: Import the correct set of modules.
gnu: ecryptfs-utils: Import the correct set of modules.
gnu: ghmm: Import the correct set of modules.
gnu: %gcc-static: Import the correct set of modules.
gnu: mumps: Import the correct set of modules.
gnu: hypre: Import the correct set of modules.
gnu: lingeling: Import the correct set of modules.
gnu: guix-build-coordinator: Import the correct set of modules.
gnu: nar-herder: Import the correct set of modules.
gnu: python-sip-4: Import the correct set of modules.
gnu: ratpoison: Import the correct set of modules.
gnu: stklos: Import the correct set of modules.
gnu: python-sepolgen: Import the correct set of modules.
gnu: boxes: Import the correct set of modules.
gnu: simh: Import the correct set of modules.
gnu: stb: Import the correct set of modules.
gnu: info-reader: Import the correct set of modules.
gnu: git: Import the correct set of modules.
gnu: ffmpeg-3.4: Import the correct set of modules.
gnu: qemu: Import the correct set of modules.
gnu: ganeti: Import the correct set of modules.
gnu: criu: Import the correct set of modules.

gnu/packages/acl.scm | 15 ++++--------
gnu/packages/axoloti.scm | 4 +--
gnu/packages/backup.scm | 5 ++--
gnu/packages/base.scm | 2 +-
gnu/packages/benchmark.scm | 2 +-
gnu/packages/bioinformatics.scm | 4 +--
gnu/packages/boost.scm | 4 +--
gnu/packages/bootloaders.scm | 6 ++---
gnu/packages/bqn.scm | 2 +-
gnu/packages/commencement.scm | 8 +++---
gnu/packages/cpp.scm | 2 +-
gnu/packages/cross-base.scm | 2 +-
gnu/packages/cups.scm | 6 ++---
gnu/packages/curl.scm | 4 +--
gnu/packages/debian.scm | 2 +-
gnu/packages/dezyne.scm | 2 +-
gnu/packages/dictionaries.scm | 2 +-
gnu/packages/djvu.scm | 4 +--
gnu/packages/docker.scm | 2 +-
gnu/packages/emacs-xyz.scm | 20 +++++++--------
gnu/packages/emulators.scm | 2 +-
gnu/packages/engineering.scm | 4 +--
gnu/packages/esolangs.scm | 2 +-
gnu/packages/firmware.scm | 2 +-
gnu/packages/fonts.scm | 4 +--
gnu/packages/freedesktop.scm | 2 +-
gnu/packages/game-development.scm | 4 +--
gnu/packages/gcc.scm | 6 ++---
gnu/packages/gdb.scm | 2 +-
gnu/packages/genimage.scm | 2 +-
gnu/packages/geo.scm | 2 +-
gnu/packages/gimp.scm | 2 +-
gnu/packages/gnome.scm | 2 +-
gnu/packages/gnucash.scm | 2 +-
gnu/packages/gnupg.scm | 2 +-
gnu/packages/gnuzilla.scm | 6 ++---
gnu/packages/graph.scm | 4 +--
gnu/packages/guile-xyz.scm | 38 ++++++++++++++---------------
gnu/packages/ibus.scm | 2 +-
gnu/packages/image.scm | 2 +-
gnu/packages/instrumentation.scm | 2 +-
gnu/packages/java.scm | 4 +--
gnu/packages/language.scm | 2 +-
gnu/packages/linux.scm | 6 ++---
gnu/packages/machine-learning.scm | 4 +--
gnu/packages/mail.scm | 6 ++---
gnu/packages/make-bootstrap.scm | 2 +-
gnu/packages/maths.scm | 8 +++---
gnu/packages/messaging.scm | 2 +-
gnu/packages/mpd.scm | 2 +-
gnu/packages/mpi.scm | 2 +-
gnu/packages/music.scm | 2 +-
gnu/packages/networking.scm | 2 +-
gnu/packages/ocaml.scm | 2 +-
gnu/packages/openldap.scm | 2 +-
gnu/packages/package-management.scm | 8 +++---
gnu/packages/password-utils.scm | 2 +-
gnu/packages/plotutils.scm | 4 +--
gnu/packages/qt.scm | 6 ++---
gnu/packages/racket.scm | 2 +-
gnu/packages/ratpoison.scm | 2 +-
gnu/packages/scheme.scm | 2 +-
gnu/packages/selinux.scm | 2 +-
gnu/packages/shellutils.scm | 2 +-
gnu/packages/simh.scm | 2 +-
gnu/packages/speech.scm | 2 +-
gnu/packages/stb.scm | 2 +-
gnu/packages/telegram.scm | 4 +--
gnu/packages/texinfo.scm | 2 +-
gnu/packages/text-editors.scm | 2 +-
gnu/packages/version-control.scm | 4 +--
gnu/packages/video.scm | 2 +-
gnu/packages/virtualization.scm | 8 +++---
gnu/packages/web-browsers.scm | 2 +-
gnu/packages/web.scm | 2 +-
gnu/packages/xdisorg.scm | 2 +-
gnu/packages/xorg.scm | 2 +-
guix/build-system/agda.scm | 2 +-
guix/build-system/android-ndk.scm | 2 +-
guix/build-system/ant.scm | 2 +-
guix/build-system/asdf.scm | 2 +-
guix/build-system/cargo.scm | 2 +-
guix/build-system/chicken.scm | 2 +-
guix/build-system/cmake.scm | 2 +-
guix/build-system/copy.scm | 2 +-
guix/build-system/dub.scm | 2 +-
guix/build-system/elm.scm | 2 +-
guix/build-system/emacs.scm | 2 +-
guix/build-system/font.scm | 2 +-
guix/build-system/glib-or-gtk.scm | 2 +-
guix/build-system/gnu.scm | 13 +++++-----
guix/build-system/go.scm | 2 +-
guix/build-system/guile.scm | 2 +-
guix/build-system/haskell.scm | 2 +-
guix/build-system/julia.scm | 2 +-
guix/build-system/linux-module.scm | 2 +-
guix/build-system/maven.scm | 2 +-
guix/build-system/minify.scm | 2 +-
guix/build-system/node.scm | 2 +-
guix/build-system/ocaml.scm | 2 +-
guix/build-system/perl.scm | 2 +-
guix/build-system/python.scm | 2 +-
guix/build-system/r.scm | 2 +-
guix/build-system/rakudo.scm | 2 +-
guix/build-system/rebar.scm | 2 +-
guix/build-system/renpy.scm | 2 +-
guix/build-system/ruby.scm | 2 +-
guix/build-system/scons.scm | 2 +-
guix/build-system/texlive.scm | 2 +-
guix/build-system/waf.scm | 2 +-
tests/modules.scm | 8 +++---
111 files changed, 192 insertions(+), 197 deletions(-)


base-commit: dc455b6dfb28cf4ca7b1ab5deabeb0adf0ea2d20
--
2.41.0
L
L
Liliana Marie Prikler wrote on 9 Oct 2023 20:18
(name . Bruno Victal)(address . mirai@makinata.eu)
d9f99f1dd868b8e22d6906dc8f5d1dd9c9108734.camel@gmail.com
Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
Toggle quote (4 lines)
> This series introduces default variable bindings for the default
> gnu-build-system IMPORTED-MODULES and MODULES values.  The lack of a
> %default-gnu-modules caused enough confusion, as made apparent by
> this series.
If we're going to do this anyway, let's go big: add modules and
imported-modules to the fields of build-system and allow users to use
that. Perhaps also add short-hands so that (default-modules gnu)
expands to (build-system-modules gnu-build-system) and likewise for
imported-modules.

Cheers
M
M
Maxim Cournoyer wrote on 9 Oct 2023 20:26
control message for bug #66426
(address . control@debbugs.gnu.org)
87jzrvabyw.fsf@gmail.com
merge 66426 66425
quit
M
M
Maxim Cournoyer wrote on 9 Oct 2023 21:36
Re: [bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87y1gb8u73.fsf@gmail.com
Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (9 lines)
> Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
>> This series introduces default variable bindings for the default
>> gnu-build-system IMPORTED-MODULES and MODULES values.  The lack of a
>> %default-gnu-modules caused enough confusion, as made apparent by
>> this series.
> If we're going to do this anyway, let's go big: add modules and
> imported-modules to the fields of build-system and allow users to use
> that.

I don't understand; what would that look like in practice? Isn't this
already how it works? Build systems have #:modules and
#:imported-modules arguments, which are provided via the 'arguments'
field of a package.

Toggle quote (4 lines)
> Perhaps also add short-hands so that (default-modules gnu)
> expands to (build-system-modules gnu-build-system) and likewise for
> imported-modules.

Ah! I understand the idea now. It feels a bit strange to me to attach
such metadata to the build-system record itself though. At any rate, we
could discuss this separately and do it in a future iteration, perhaps?
The series posted here already has value in itself, and if we ever go to
attach this information to build system objects instead of plain
variables, we could use sed to adjust the code base.

What do yo think?

--
Thanks,
Maxim
L
L
Liliana Marie Prikler wrote on 9 Oct 2023 21:45
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
2e6bfb0e40fddb7f0df045aa3b234c1cf45494cf.camel@gmail.com
Am Montag, dem 09.10.2023 um 15:36 -0400 schrieb Maxim Cournoyer:
Toggle quote (17 lines)
> Hello,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
> > > This series introduces default variable bindings for the default
> > > gnu-build-system IMPORTED-MODULES and MODULES values.  The lack
> > > of a %default-gnu-modules caused enough confusion, as made
> > > apparent by this series.
> > If we're going to do this anyway, let's go big: add modules and
> > imported-modules to the fields of build-system and allow users to
> > use that.
>
> I don't understand; what would that look like in practice?  Isn't
> this already how it works?  Build systems have #:modules and
> #:imported-modules arguments, which are provided via the 'arguments'
> field of a package.
Well, no. The build-system record currently contains a name,
description and lowering procedure, but no "immediately helpful" data
for package writers.

Toggle quote (13 lines)
> > Perhaps also add short-hands so that (default-modules gnu)
> > expands to (build-system-modules gnu-build-system) and likewise for
> > imported-modules.
>
> Ah!  I understand the idea now.  It feels a bit strange to me to
> attach such metadata to the build-system record itself though.  At
> any rate, we could discuss this separately and do it in a future
> iteration, perhaps?
> The series posted here already has value in itself, and if we ever go
> to attach this information to build system objects instead of plain
> variables, we could use sed to adjust the code base.
>
> What do yo think?
Hmm, at the very least I'd like to bikeshed the variable names, hence
my suggestion to encode it into the build system itself, which would
allow any name locally. %default-anything reads weird to me, plus it's
a mouthful for imported modules.
WDYT about %gnu-build-modules and %gnu-build-system-modules, where
%gnu-build-system-modules keeps its current intent for being imported?
Alternatively we could also rename it to %gnu-build-imported-modules
with a deprecated alias.

Cheers
M
M
Maxim Cournoyer wrote on 10 Oct 2023 03:31
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87fs2j8dqa.fsf@gmail.com
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (40 lines)
> Am Montag, dem 09.10.2023 um 15:36 -0400 schrieb Maxim Cournoyer:
>> Hello,
>>
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>>
>> > Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
>> > > This series introduces default variable bindings for the default
>> > > gnu-build-system IMPORTED-MODULES and MODULES values.  The lack
>> > > of a %default-gnu-modules caused enough confusion, as made
>> > > apparent by this series.
>> > If we're going to do this anyway, let's go big: add modules and
>> > imported-modules to the fields of build-system and allow users to
>> > use that.
>>
>> I don't understand; what would that look like in practice?  Isn't
>> this already how it works?  Build systems have #:modules and
>> #:imported-modules arguments, which are provided via the 'arguments'
>> field of a package.
> Well, no. The build-system record currently contains a name,
> description and lowering procedure, but no "immediately helpful" data
> for package writers.
>
>> > Perhaps also add short-hands so that (default-modules gnu)
>> > expands to (build-system-modules gnu-build-system) and likewise for
>> > imported-modules.
>>
>> Ah!  I understand the idea now.  It feels a bit strange to me to
>> attach such metadata to the build-system record itself though.  At
>> any rate, we could discuss this separately and do it in a future
>> iteration, perhaps?
>> The series posted here already has value in itself, and if we ever go
>> to attach this information to build system objects instead of plain
>> variables, we could use sed to adjust the code base.
>>
>> What do yo think?
> Hmm, at the very least I'd like to bikeshed the variable names, hence
> my suggestion to encode it into the build system itself, which would
> allow any name locally. %default-anything reads weird to me, plus it's
> a mouthful for imported modules.

It seems conventional to me: we have %default-subtitute-urls,
%default-channels, %default-include (thousands of matches for
'%default-' upon grepping).

Toggle quote (5 lines)
> WDYT about %gnu-build-modules and %gnu-build-system-modules, where
> %gnu-build-system-modules keeps its current intent for being imported?
> Alternatively we could also rename it to %gnu-build-imported-modules
> with a deprecated alias.

People have been adding %gnu-build-system-modules to #:modules
erroneously. Not renaming that would ensure this keeps happening.
Having 'imported-modules' in the name seems like it'd make things a bit
easier to remember; thus, I think the proposed naming is adequate?

--
Thanks,
Maxim
L
L
Liliana Marie Prikler wrote on 10 Oct 2023 06:14
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
833f6e7be42b6fd505d2cdd401e93f0d9b64bab7.camel@gmail.com
Am Montag, dem 09.10.2023 um 21:31 -0400 schrieb Maxim Cournoyer:
Toggle quote (11 lines)
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > Hmm, at the very least I'd like to bikeshed the variable names,
> > hence my suggestion to encode it into the build system itself,
> > which would allow any name locally.  %default-anything reads weird
> > to me, plus it's a mouthful for imported modules.
>
> It seems conventional to me: we have %default-subtitute-urls,
> %default-channels, %default-include (thousands of matches for
> '%default-' upon grepping).
Fair enough, but in the cases you've named it's still %default for more
than one build system. Or do you by extension want %default-glib-or-
gtk-imported-modules? That's quite a mouthful imho without any
additional semantics.

Toggle quote (12 lines)
> > WDYT about %gnu-build-modules and %gnu-build-system-modules, where
> > %gnu-build-system-modules keeps its current intent for being
> > imported?
> > Alternatively we could also rename it to %gnu-build-imported-
> > modules
> > with a deprecated alias.
>
> People have been adding %gnu-build-system-modules to #:modules
> erroneously.  Not renaming that would ensure this keeps happening.
> Having 'imported-modules' in the name seems like it'd make things a
> bit easier to remember; thus, I think the proposed naming is
> adequate?
Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
is better even with that reasoning.

Cheers
M
M
Maxim Cournoyer wrote on 10 Oct 2023 16:36
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
878r8a5ytu.fsf@gmail.com
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (17 lines)
> Am Montag, dem 09.10.2023 um 21:31 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>>
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> > Hmm, at the very least I'd like to bikeshed the variable names,
>> > hence my suggestion to encode it into the build system itself,
>> > which would allow any name locally.  %default-anything reads weird
>> > to me, plus it's a mouthful for imported modules.
>>
>> It seems conventional to me: we have %default-subtitute-urls,
>> %default-channels, %default-include (thousands of matches for
>> '%default-' upon grepping).
> Fair enough, but in the cases you've named it's still %default for more
> than one build system. Or do you by extension want %default-glib-or-
> gtk-imported-modules? That's quite a mouthful imho without any
> additional semantics.

That's what I was thinking to in the future yes; add
%default-glib-or-gtk-imported-modules as well as
%default-glib-or-gtk-modules, %default-cmake-imported-modules and
%default-cmake-modules, etc.

The variable names may be somewhat long, but they are not used often and
they should be easy to auto-complete.

Toggle quote (15 lines)
>> > WDYT about %gnu-build-modules and %gnu-build-system-modules, where
>> > %gnu-build-system-modules keeps its current intent for being
>> > imported?
>> > Alternatively we could also rename it to %gnu-build-imported-
>> > modules
>> > with a deprecated alias.
>>
>> People have been adding %gnu-build-system-modules to #:modules
>> erroneously.  Not renaming that would ensure this keeps happening.
>> Having 'imported-modules' in the name seems like it'd make things a
>> bit easier to remember; thus, I think the proposed naming is
>> adequate?
> Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
> is better even with that reasoning.

So we'd use for example %glib-or-gtk-build-imported-modules? The
difference is small to what I proposed (swap the leading default for an
in-middle 'build' -- 2 characters), so I don't think your 'mouthful'
argument holds, but I don't have much of an issue with it, except
perhaps that 'build' is not directly attached to the module namespace,
which is (guix build-systems gnu) for example.

I still prefer my naming, but yeah, we're choosing the color of the bike
shed :-). If others could tip in, that may help decide, otherwise I'd
prefer leaving it as-is. Does that sound reasonable?

--
Thanks,
Maxim
M
M
Maxim Cournoyer wrote on 16 Oct 2023 17:28
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87a5siy4bq.fsf@gmail.com
Hello,

[...]

Toggle quote (19 lines)
>>> People have been adding %gnu-build-system-modules to #:modules
>>> erroneously.  Not renaming that would ensure this keeps happening.
>>> Having 'imported-modules' in the name seems like it'd make things a
>>> bit easier to remember; thus, I think the proposed naming is
>>> adequate?
>> Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
>> is better even with that reasoning.
>
> So we'd use for example %glib-or-gtk-build-imported-modules? The
> difference is small to what I proposed (swap the leading default for an
> in-middle 'build' -- 2 characters), so I don't think your 'mouthful'
> argument holds, but I don't have much of an issue with it, except
> perhaps that 'build' is not directly attached to the module namespace,
> which is (guix build-systems gnu) for example.
>
> I still prefer my naming, but yeah, we're choosing the color of the bike
> shed :-). If others could tip in, that may help decide, otherwise I'd
> prefer leaving it as-is. Does that sound reasonable?

I just realized that the whole series had been sent mistakenly to
another series (seems I messed up using 'mumi send'):

I did spot a couple errors in that series that I've resolved locally.

If nobody has further concerns, I'll merge it later today to the
core-updates branch.

--
Thanks,
Maxim
M
M
Maxim Cournoyer wrote on 19 Oct 2023 06:04
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
877cnjp89n.fsf@gmail.com
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (32 lines)
> Hello,
>
> [...]
>
>>>> People have been adding %gnu-build-system-modules to #:modules
>>>> erroneously.  Not renaming that would ensure this keeps happening.
>>>> Having 'imported-modules' in the name seems like it'd make things a
>>>> bit easier to remember; thus, I think the proposed naming is
>>>> adequate?
>>> Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
>>> is better even with that reasoning.
>>
>> So we'd use for example %glib-or-gtk-build-imported-modules? The
>> difference is small to what I proposed (swap the leading default for an
>> in-middle 'build' -- 2 characters), so I don't think your 'mouthful'
>> argument holds, but I don't have much of an issue with it, except
>> perhaps that 'build' is not directly attached to the module namespace,
>> which is (guix build-systems gnu) for example.
>>
>> I still prefer my naming, but yeah, we're choosing the color of the bike
>> shed :-). If others could tip in, that may help decide, otherwise I'd
>> prefer leaving it as-is. Does that sound reasonable?
>
> I just realized that the whole series had been sent mistakenly to
> another series (seems I messed up using 'mumi send'):
> <https://issues.guix.gnu.org/65924#18>.
>
> I did spot a couple errors in that series that I've resolved locally.
>
> If nobody has further concerns, I'll merge it later today to the
> core-updates branch.

I've now done so. Thanks for the review/comments!

--
Thanks,
Maxim
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 66426@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66426
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch