[PATCH 0/1] gnu: Add gccgo-10.

  • Done
  • quality assurance status badge
Details
2 participants
  • Efraim Flashner
  • Sarah Morgensen
Owner
unassigned
Submitted by
Sarah Morgensen
Severity
normal
S
S
Sarah Morgensen wrote on 14 Jun 2021 06:16
(address . guix-patches@gnu.org)(name . Sarah Morgensen)(address . iskarian@mgsn.dev)
20210614041653.3085-1-iskarian@mgsn.dev
The primary goal for adding gccgo is to bootstrap the go compiler for arches
that aren't supported by go 1.4. I believe the major one to support here is
powerpc64le, but I am unsure of current arch usage. A secondary goal is to
provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.

I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
gcc 10 using `make check-go`. There are two minor test failures:

1. index0-out.go, previously reported upstream [0]
2. pprof (TestConvertCPUProfile/TestConvertMemProfile)

(I have not yet been able to deterine whether the pprof failures are an upstream
bug or a Guix bug. Should I send details to bug-guix?)

Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
should be removed after the change is in master.


Sarah Morgensen (1):
gnu: Add gccgo-10.

gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)

--
2.31.1
S
S
Sarah Morgensen wrote on 14 Jun 2021 17:48
[PATCH 1/1] gnu: Add gccgo-10.
(address . 49019@debbugs.gnu.org)
20210614154824.3465-1-iskarian@mgsn.dev
Generate gccgo with MAKE-GCCGO to factorize phases, and to fix the
cyclic dependency between out and lib (caused by libgo embedding the
gotools path) that was worked around in

* gnu/packages/gcc.scm (custom-gcc-gccgo): New procedure.
(make-gccgo): New procedure.
(gccgo-10): New variable.
---
gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)

Toggle diff (111 lines)
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 1fd5710e57..df2ba729d8 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -11,6 +11,7 @@
;;; Copyright © 2020 Guy Fleury Iteriteka <gfleury@disroot.org>
;;; Copyright © 2020 Simon Tournier <zimon.toutoune@gmail.com>
;;; Copyright © 2021 Chris Marusich <cmmarusich@gmail.com>
+;;; Copyright © 2021 Sarah Morgensen <iskarian@mgsn.dev>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -744,6 +745,42 @@ as the 'native-search-paths' field."
".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)"))
#t))))))))
+(define* (custom-gcc-gccgo gcc name languages
+ #:optional
+ (search-paths (package-native-search-paths gcc))
+ #:key (separate-lib-output? #t))
+ ;; TODO: remove CUSTOM-GCC-GCCGO when regex changes for CUSTOM-GCC are
+ ;; merged into master <https://issues.guix.gnu.org/49010>
+ "Return a custom version of GCC that supports LANGUAGES. Use SEARCH-PATHS
+as the 'native-search-paths' field."
+ (package (inherit gcc)
+ (name name)
+ (outputs (if separate-lib-output?
+ (package-outputs gcc)
+ (delete "lib" (package-outputs gcc))))
+ (native-search-paths search-paths)
+ (properties (alist-delete 'hidden? (package-properties gcc)))
+ (arguments
+ (substitute-keyword-arguments (package-arguments gcc)
+ ((#:modules modules %gnu-build-system-modules)
+ `(,@modules
+ (srfi srfi-1)
+ (srfi srfi-26)
+ (ice-9 regex)))
+ ((#:configure-flags flags)
+ `(cons (string-append "--enable-languages="
+ ,(string-join languages ","))
+ (remove (cut string-match "--enable-languages.*" <>)
+ ,flags)))
+ ((#:phases phases)
+ `(modify-phases ,phases
+ (add-after 'install 'remove-broken-or-conflicting-files
+ (lambda* (#:key outputs #:allow-other-keys)
+ (for-each
+ delete-file
+ (find-files (string-append (assoc-ref outputs "out") "/bin")
+ ".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|lto)(-.*)?$"))))))))))
+
(define %generic-search-paths
;; This is the language-neutral search path for GCC. Entries in $CPATH are
;; not considered "system headers", which means GCC can raise warnings for
@@ -813,6 +850,43 @@ It can also be used for ahead-of-time code generation for building standalone
compilers. The just-in-time (jit) part of the name is now something of a
misnomer.")))
+(define (make-gccgo gcc)
+ "Return a gccgo package based on GCC."
+ (let ((gccgo (custom-gcc-gccgo gcc "gccgo" '("go") %generic-search-paths)))
+ (package
+ (inherit gccgo)
+ (synopsis "Go frontend to GCC")
+ (description
+ "This package is part of the GNU Compiler Collection and
+provides the GNU compiler for the Go programming language.")
+ (arguments
+ (substitute-keyword-arguments (package-arguments gccgo)
+ ((#:phases phases)
+ `(modify-phases ,phases
+ (add-after 'install 'wrap-go-with-tool-path
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+ (exedir (string-append out "/libexec/gcc"))
+ (tooldir (dirname (car (find-files exedir "^cgo$")))))
+ (wrap-program (string-append out "/bin/go")
+ `("GCCGOTOOLDIR" =
+ (,(string-append "${GCCGOTOOLDIR-" tooldir "}")))
+ `("GOROOT" =
+ (,(string-append "${GOROOT-" out "}")))))))
+ (add-before 'configure 'fix-gotools-runpath
+ (lambda _
+ (substitute* "gotools/Makefile.in"
+ (("AM_LDFLAGS =" all)
+ (string-append all " -Wl,-rpath=$(libdir) ")))))
+ (add-before 'configure 'remove-tool-reference-from-libgo
+ (lambda _
+ (substitute* "libgo/Makefile.in"
+ (("(GccgoToolDir = \\\")[^\\\"]+" _ start)
+ (string-append start "/nonexistent"))
+ (("(DefaultGoroot = \\\")[^\\\"]+" _ start)
+ (string-append start "/nonexistent"))
+ (("(defaultGOROOTValue.*?return `)[^`]+" _ start)
+ (string-append start "/nonexistent"))))))))))))
(define-public gccgo-4.9
(custom-gcc (package
@@ -828,6 +902,9 @@ provides the GNU compiler for the Go programming language."))
;; a cyclic dependency. <http://debbugs.gnu.org/18101>
#:separate-lib-output? #f))
+(define-public gccgo-10
+ (make-gccgo gcc-10))
+
(define %objc-search-paths
(list (search-path-specification
(variable "OBJC_INCLUDE_PATH")
--
2.31.1
E
E
Efraim Flashner wrote on 21 Jun 2021 15:25
Re: [bug#49019] [PATCH 0/1] gnu: Add gccgo-10.
(name . Sarah Morgensen)(address . iskarian@mgsn.dev)(address . 49019@debbugs.gnu.org)
YNCTLLTUAr4uTdzd@3900XT
On Sun, Jun 13, 2021 at 09:16:53PM -0700, Sarah Morgensen via Guix-patches via wrote:
Toggle quote (14 lines)
> The primary goal for adding gccgo is to bootstrap the go compiler for arches
> that aren't supported by go 1.4. I believe the major one to support here is
> powerpc64le, but I am unsure of current arch usage. A secondary goal is to
> provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.
>
> I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
> gcc 10 using `make check-go`. There are two minor test failures:
>
> 1. index0-out.go, previously reported upstream [0]
> 2. pprof (TestConvertCPUProfile/TestConvertMemProfile)
>
> (I have not yet been able to deterine whether the pprof failures are an upstream
> bug or a Guix bug. Should I send details to bug-guix?)

I wouldn't worry about the test failures.

Toggle quote (4 lines)
> Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
> CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
> should be removed after the change is in master.

Makes sense

Toggle quote (13 lines)
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
>
> Sarah Morgensen (1):
> gnu: Add gccgo-10.
>
> gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> --
> 2.31.1
>

I threw together a quick gccgo-toolchain package and tried using that to
build keybase and syncthing. One of the errors I came across was:
/home/efraim/go/pkg/mod/golang.org/x/sys@v0.0.0-20200922070232-aee5d888a860/unix/gccgo.go:50:
undefined reference to `gccgoRealSyscallNoError' and also
github.com/minio/sha256-simd@v0.1.1 didn't like the assembly in the
package.

It's definitely possible that I'm missing some flag to tell go that I'm
really using gccgo. Or that it should be built with binutils-gold.

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmDQkyoACgkQQarn3Mo9
g1Hbvw//RKc6+QkfYN+9D9SVfXRYkLIYZgTr+7UoI8LE5nn9F19DyE5FyaogsE7a
GMZetxckfWgb33yfOrdVzDNPWTPmUFF5cRrES9Fy0j3oSGOy2ZxtglA0gJZUGTYt
brkmvcN0MKdC5QvwKd5AGI0Jpidytp3Q/X0h2t39fjVaamJqhQLqlmMHZ7XXS5dL
bECrhU/LchtURbRBVW9OjC1iUjy5AZisYGWb6jY6Etsc5/QkjzGDaOCFeyc+wYlS
vnjAdXYofv/Mx4guPiT1x64cl3ysdx2kPiSp1gub0265kDc4kegznyQdKrGveIcs
youOvXyOhFIzG3JmwhAMQpjpZq5MGPJecQ0UKWjFQbq+ODlvB2Fujwg0Ti2iB/LG
j8MWZC/EGdrmhzIWClIYs5auO3ltoJWVKDBGNHRWn+jiTuq9MvR8ajdDwJWX1lnK
VvLF65P30lmJeAtxB41P9pYkrpq+On+eaNZCTMXyI+jIH4c6aek/0a/WydJ3skLT
m0ReccyOgwQbpf5pMK9qwrCRxVXQVfRcJCJtqZxz6qdk/yuER0g4zdfJNk+u5tSt
jT2AT8n2tAHoBuFXtf7zRI7L/SrZarp2VuM+q9MHuaqjXPkn2dNyyis8Nr6ee4vs
PQzSg9+GjnDAX5pywEac2Xu+mGX5j4gLz3nqsHO/bjvfftGBUvw=
=dpH0
-----END PGP SIGNATURE-----


I
I
iskarian wrote on 21 Jun 2021 23:32
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 49019@debbugs.gnu.org)
96de532e108afa2cf35ae45a87053e19@mgsn.dev
Thanks for taking a look at this, Efraim!

June 21, 2021 6:25 AM, "Efraim Flashner" <efraim@flashner.co.il> wrote:

Toggle quote (43 lines)
> On Sun, Jun 13, 2021 at 09:16:53PM -0700, Sarah Morgensen via Guix-patches via wrote:
>
>> The primary goal for adding gccgo is to bootstrap the go compiler for arches
>> that aren't supported by go 1.4. I believe the major one to support here is
>> powerpc64le, but I am unsure of current arch usage. A secondary goal is to
>> provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.
>>
>> I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
>> gcc 10 using `make check-go`. There are two minor test failures:
>>
>> 1. index0-out.go, previously reported upstream [0]
>> 2. pprof (TestConvertCPUProfile/TestConvertMemProfile)
>>
>> (I have not yet been able to deterine whether the pprof failures are an upstream
>> bug or a Guix bug. Should I send details to bug-guix?)
>
> I wouldn't worry about the test failures.
>
>> Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
>> CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
>> should be removed after the change is in master.
>
> Makes sense
>
>> [0] https://issues.guix.gnu.org/49010
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
>>
>> Sarah Morgensen (1):
>> gnu: Add gccgo-10.
>>
>> gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 77 insertions(+)
>>
>> --
>> 2.31.1
>
> I threw together a quick gccgo-toolchain package and tried using that to
> build keybase and syncthing. One of the errors I came across was:
> /home/efraim/go/pkg/mod/golang.org/x/sys@v0.0.0-20200922070232-aee5d888a860/unix/gccgo.go:50:
> undefined reference to `gccgoRealSyscallNoError' and also
> github.com/minio/sha256-simd@v0.1.1 didn't like the assembly in the
> package.

The assembly problem is (unfortunately) a known limitation of gccgo. The gc and
gccgo compilers use different asm syntax, so many extant go programs cannot
currently be compiled with gccgo alone. There are also other limitations with
the go tools provided by gccgo, as only a subset have been implemented.

However, I have successfully built go-1.16 with gccgo with a few tweaks. (Most
dependent packages build with no modification or with a version bump, and I
have minimal patches for the handful of others. Docker will have to be updated
to work with go-1.16, which will likely be out of my depth.) I plan to share
a patchset for this soon.

As for x/sys: most likely updating the module dependency will solve it. I see
x/sys has had some gccgo related commits since that version was released.

Toggle quote (3 lines)
> It's definitely possible that I'm missing some flag to tell go that I'm
> really using gccgo. Or that it should be built with binutils-gold.

I must admit that I had not even thought about whether gold might be
necessary. I really am out of my depth on this one. I see that you authored
the patch for go@1.14 to use gold on armhf and aarch64, so you likely know
more about this than me! Presumably that was in regards to [0] and [1]?

Other than that, the main motivation for using gold seems to be the support for
split-stack, which allows the use of many more goroutines before running out of
stack space [2]. Replacing GNU ld (`./configure --with-ld=...') as [2] suggests
may introduce bugs... It appears that in at least one case (ppc64) gccgo
prefers gold even if gcc was not built solely with it [3]. Unfortunately, adding
gold as an optional linker would add ~75MiB to closure size...

I'm not sure what the best way forward is, here. WDYT?

Toggle quote (5 lines)
> --
> Efraim Flashner <efraim@flashner.co.il> ????? ?????
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

E
E
Efraim Flashner wrote on 28 Jun 2021 21:22
Re: [bug#49019] [PATCH 1/1] gnu: Add gccgo-10.
(name . Sarah Morgensen)(address . iskarian@mgsn.dev)(address . 49019-done@debbugs.gnu.org)
YNohgeO9PJ/Is/Td@3900XT
Thank you for the patch! gccgo was one of the things that has taunted me
for a while now. Patch pushed!

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmDaIYEACgkQQarn3Mo9
g1Gkqg/9EFgiJE4+ogLNDWjdmymp/sh8wpseX5jTFnpmo7Dw+/8XOcjJu/ar4A+S
B5eIzRsRWXEGBWFqf8fy5x+G5tzGXdz0w2bz2X5QEN8pHLi08zif2WOzKobqXTpz
785OZH1Q+WqU1Q6SmsIDM9bL+DBCZHwxDjjIkYIcLa9V5tjGRpEGuybIHgvS0Dp5
LkKsrsLd1TUtRcp2seg1KGj52mWJ6oUdkhV1WIZXsY++INKZirOwLlfigl7juave
inDfJbfhQyfY6I71qX0u6wraRfEMBRoC2fF1/7lmc6Ha9KTC3r9dHg/vdQ1paPV2
VcN71UeVFS0eabEopwHQlKntNqxOhL4yLkDa8zbO3UkBTk5eoRuhKhSdOEOSOWGQ
HhxRZvrnD36caNxUBDLHo/45ie/uG7Lvwxgg0c7RHn30LQk6pMRPCFLq1F10q0uY
jukZWFO3MMYygP3eV5h2Krty45Vp9rXr5ewtyBr73mhjnrHWlumbAOdIJ9NUAnBD
F838NcrdvtpKptTnhEUyznRjwALB8i+eHGxfJL/fhYfwiEVQpR9XcXi7hADqOm2I
qKbfWOt2iceCo2hNNj8d760H6Y1q1ehcMexdY3h18dPVrMolfzDvQys+2hIXgGMc
7fzerp3EJLwANNSpPKlZ3MzGvloRfYy/x5DnCMpItSStqY5lK8I=
=98LD
-----END PGP SIGNATURE-----


Closed
E
E
Efraim Flashner wrote on 28 Jun 2021 21:22
Re: [bug#49019] [PATCH 0/1] gnu: Add gccgo-10.
(address . iskarian@mgsn.dev)(address . 49019@debbugs.gnu.org)
YNohecmFcHqNDH/D@3900XT
On Mon, Jun 21, 2021 at 09:32:22PM +0000, iskarian@mgsn.dev wrote:
Toggle quote (61 lines)
> Thanks for taking a look at this, Efraim!
>
> June 21, 2021 6:25 AM, "Efraim Flashner" <efraim@flashner.co.il> wrote:
>
> > On Sun, Jun 13, 2021 at 09:16:53PM -0700, Sarah Morgensen via Guix-patches via wrote:
> >
> >> The primary goal for adding gccgo is to bootstrap the go compiler for arches
> >> that aren't supported by go 1.4. I believe the major one to support here is
> >> powerpc64le, but I am unsure of current arch usage. A secondary goal is to
> >> provide a gccgo-toolchain, as gccgo may provide advantages over gc in time.
> >>
> >> I have successfully built gccgo 9, 10 and 11 for x86-64. I additionally tested
> >> gcc 10 using `make check-go`. There are two minor test failures:
> >>
> >> 1. index0-out.go, previously reported upstream [0]
> >> 2. pprof (TestConvertCPUProfile/TestConvertMemProfile)
> >>
> >> (I have not yet been able to deterine whether the pprof failures are an upstream
> >> bug or a Guix bug. Should I send details to bug-guix?)
> >
> > I wouldn't worry about the test failures.
> >
> >> Finally, the regex update in [1] is implemented in CUSTOM-GCC-GCCGO rather than
> >> CUSTOM-GCC to avoid rebuilding 2k+ gfortran packages, and CUSTOM-GCC-GCCGO
> >> should be removed after the change is in master.
> >
> > Makes sense
> >
> >> [0] https://issues.guix.gnu.org/49010
> >> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
> >>
> >> Sarah Morgensen (1):
> >> gnu: Add gccgo-10.
> >>
> >> gnu/packages/gcc.scm | 77 ++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 77 insertions(+)
> >>
> >> --
> >> 2.31.1
> >
> > I threw together a quick gccgo-toolchain package and tried using that to
> > build keybase and syncthing. One of the errors I came across was:
> > /home/efraim/go/pkg/mod/golang.org/x/sys@v0.0.0-20200922070232-aee5d888a860/unix/gccgo.go:50:
> > undefined reference to `gccgoRealSyscallNoError' and also
> > github.com/minio/sha256-simd@v0.1.1 didn't like the assembly in the
> > package.
>
> The assembly problem is (unfortunately) a known limitation of gccgo. The gc and
> gccgo compilers use different asm syntax, so many extant go programs cannot
> currently be compiled with gccgo alone. There are also other limitations with
> the go tools provided by gccgo, as only a subset have been implemented.
>
> However, I have successfully built go-1.16 with gccgo with a few tweaks. (Most
> dependent packages build with no modification or with a version bump, and I
> have minimal patches for the handful of others. Docker will have to be updated
> to work with go-1.16, which will likely be out of my depth.) I plan to share
> a patchset for this soon.
>
> As for x/sys: most likely updating the module dependency will solve it. I see
> x/sys has had some gccgo related commits since that version was released.

Sounds good.

Toggle quote (8 lines)
> > It's definitely possible that I'm missing some flag to tell go that I'm
> > really using gccgo. Or that it should be built with binutils-gold.
>
> I must admit that I had not even thought about whether gold might be
> necessary. I really am out of my depth on this one. I see that you authored
> the patch for go@1.14 to use gold on armhf and aarch64, so you likely know
> more about this than me! Presumably that was in regards to [0] and [1]?

That one's come forward with a couple of go versions. Perhaps it'd be
best to add it unconditionally, or at least to switch the logic and only
skip it on x86_64 and i686.

Toggle quote (9 lines)
> Other than that, the main motivation for using gold seems to be the support for
> split-stack, which allows the use of many more goroutines before running out of
> stack space [2]. Replacing GNU ld (`./configure --with-ld=...') as [2] suggests
> may introduce bugs... It appears that in at least one case (ppc64) gccgo
> prefers gold even if gcc was not built solely with it [3]. Unfortunately, adding
> gold as an optional linker would add ~75MiB to closure size...
>
> I'm not sure what the best way forward is, here. WDYT?

It's not a lot of extra closure size, given just how large the go
package itself is. I think we leave it as-is for now and add change it
up later if necessary.

Toggle quote (6 lines)
>
> [0]: https://github.com/golang/go/issues/15696
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=19962
> [2]: https://golang.org/doc/install/gccgo#Gold
> [3]: https://github.com/gcc-mirror/gcc/commit/402565b61f9783473472fcfd729efa8c1e355d2b

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmDaIXkACgkQQarn3Mo9
g1HTWQ/+MffO+XFp1KLd1L6zSHAsqdHdjFysOUs9ip5fQHf7cqJMctEOep9lAoN0
KOBso3b42rA28NLqzGarxZVOLrOiU7XKaGSTV7yS1oRf1OUnJM0fDsXhlw9+gDIR
C49UIyIPELuaR2FFsp4ZcIW8ZmR/5dZQUwlSYc18/iCj4YpGxaBLp4a2uVOrRflE
eFn2qn4UMWij+o0tuUaFZGmRz1I67ZiivT5/jc30Omjm9dNthxHm7u9d+8/gJiWE
G3AfRNfjFEUaX3S1NWMREglHdfSTXkYoYOEE5oKyJBn74sr+KWvKJjCWUQHM7fZI
VENC12/b90w8228Ip/QUGb+W5dAeSjPwx3ZSQkXSjvB0gC1FZa/Gf6fgaZBGyfBc
RYb7MY9US1Ks54Hrx1YXq6PRlKHVLr8JfJtd5z83Pf4bkuxy9QPVLpYvw3bLMDM6
QghHUECPgTvu3vNN7IhHqG2y15KXFQ87VysK1FwZsFmNbpisGWeUSQaWdxMvSHhM
JRnwnsVrUehYcjDYT4qXn8SgI6gGc/BnUXCbyEmPbax3EObNJtGw+rIUGLUOMHJa
tFyUQsNYQWu7aARbbwM6ZncbgM7z815ljf4GXSblbPqSQwfLY90p1jVgdnPhu/Eb
39xeOyw7UIPYISpRY/amT5PBkaNGF60Jb2q5keTSdirBV2a3GNs=
=F0JH
-----END PGP SIGNATURE-----


?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 49019
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