sbcl-2.2.6 build fail

  • Done
  • quality assurance status badge
Details
5 participants
  • bokr
  • Guillaume Le Vaillant
  • Christopher Baines
  • Tobias Geerinckx-Rice
  • Wensheng Xie
Owner
unassigned
Submitted by
Wensheng Xie
Severity
normal
W
W
Wensheng Xie wrote on 2 Jul 2022 11:29
(address . bug-guix@gnu.org)
AS1P250MB0605FCAA4FD38897A42D78E4B0BC9@AS1P250MB0605.EURP250.PROD.OUTLOOK.COM
Hi, guix:

the command:
guix package -u

log:
/gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv wird erstellt …
- „build-doc“-Phasebuilder for `/gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv' failed with exit code 1
Erstellung von /gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv fehlgeschlagen
Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
guix package: Fehler: build of
`/gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv' failed

This is what I had right. If you need more, please let me know.

best regards
wxie
T
T
Tobias Geerinckx-Rice wrote on 2 Jul 2022 13:40
6B9D52CF-992E-402B-9ABA-4E017804B4A6@tobias.gr
On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
Toggle quote (3 lines)
>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.


This log file is always a good idea to include.

If it's more than a few hundred kilobytes compressed, send only the last ~300K or so.
Hi,

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.
C
C
Christopher Baines wrote on 2 Jul 2022 18:49
87ilof78y0.fsf@cbaines.net
Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (6 lines)
> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
>
>
> This log file is always a good idea to include.

I think this is the equivalent non-grafted derivation:


There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
get it to build successfully once though on my laptop.

Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
successfully, or if there's particular conditions for it to build?

Thanks,

Chris
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmLAd/dfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfyuQ/7BnA3K58n7tAi7FW6RYsYrudbyi9GKgBn
Bh8Z9jhvjyb5bA4TcF1WER/SnoMa7ARHxj9k6ZxIowmkyUuSpqyFbk7GzCDbDQA5
YzleMJxiYLKkPwWDaTEXL/VIlbiDEiSvZcW2ielxQEMgwe9Yl1Z3Nd5gU0Y+n+oa
koJkYLeKe8Q/n5zqTh6bCsVlsZ9CocS2N//ZOUa2Yri2+hOf2n3XmaaU8DNII/RT
PNoToA2L8ABVwsUrj9LCyZOuQ1SRyKunuNI+CQMwgJpsXhhdmchAEv9AiiZ+MYIz
ArKlMh7q49VrpjyM2rCaQ7CqQmehwXPtHRqGlT1QiA7ogfOnzbG7Ui3+TQoPGuj1
LkEfpyyeIZNEr2CpMP+zX70+WxUMlP0DEGus6o5EPTA0+fjhLKqxhQGTv4Z9eX36
QiOHjB6S5mKuXbWyL9YaYTS1/q8n5aeA6gmauFKs2ROs4XXuHzgS7CSqeCrDKrj9
7Wv4Sf5+OF4CHEyuADVSTxG9iDhW7IX+RKGWjvcscmsjwLuPYFBxXKYXMd1blLPz
E4uvEWGCwjbI51rou21um+RVnZb57fpteWe9yqQODv9Yx4K+3OsthjTx4KDwNS8I
XOnJHBHRl4PueRp7EMu2es2yyE3y+IOcKf80hoXpgHeTDwQ4ZIFm8hHBcjxPQxUM
w9kvB3n3Gtw=
=nuLz
-----END PGP SIGNATURE-----

G
G
Guillaume Le Vaillant wrote on 2 Jul 2022 19:08
(name . Christopher Baines)(address . mail@cbaines.net)
87o7y74eid.fsf@kitej
Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (22 lines)
> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>
>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
>>
>>
>> This log file is always a good idea to include.
>
> I think this is the equivalent non-grafted derivation:
>
> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
>
> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> get it to build successfully once though on my laptop.
>
> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> successfully, or if there's particular conditions for it to build?
>
> Thanks,
>
> Chris

According to the logs, the 'build-doc' phase fails to compile the
documentation for SIMD related functions. There's a patch disabling this
part of the doc unless we compile on x86_64, but maybe not all x86_64
CPUs have the required instructions...

Would it be possible to get the result of "lscpu" on some machines where
it fails?

The build always works on my machine:
Toggle snippet (46 lines)
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 9 5950X 16-Core Processor
CPU family: 25
Model: 33
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 1
Stepping: 0
Frequency boost: enabled
CPU max MHz: 5083.3979
CPU min MHz: 2200.0000
BogoMIPS: 6786.83
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_go
od nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy sv
m extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate
ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc c
qm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists paus
efilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 512 KiB (16 instances)
L1i: 512 KiB (16 instances)
L2: 8 MiB (16 instances)
L3: 64 MiB (2 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-31
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling
Srbds: Not affected
Tsx async abort: Not affected
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYsB+ig8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j8kigD/QpcGCWwhlrPx2TCt7VKSI35VVaeGXDg8HgZm
4rPWHk0A/04GjJaRXcrw0g7NDg746WK+UtmPdlw1sKr2fyS3oI6M
=hx3k
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 2 Jul 2022 21:26
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
87edz36zm5.fsf@cbaines.net
Guillaume Le Vaillant <glv@posteo.net> writes:

Toggle quote (33 lines)
> [[PGP Signed Part:Undecided]]
> Christopher Baines <mail@cbaines.net> skribis:
>
>> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
>>
>>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
>>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
>>>
>>>
>>> This log file is always a good idea to include.
>>
>> I think this is the equivalent non-grafted derivation:
>>
>> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
>>
>> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
>> get it to build successfully once though on my laptop.
>>
>> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
>> successfully, or if there's particular conditions for it to build?
>>
>> Thanks,
>>
>> Chris
>
> According to the logs, the 'build-doc' phase fails to compile the
> documentation for SIMD related functions. There's a patch disabling this
> part of the doc unless we compile on x86_64, but maybe not all x86_64
> CPUs have the required instructions...
>
> Would it be possible to get the result of "lscpu" on some machines where
> it fails?

Sure, here is the lscpu output from the bayfront and harbourfront
machines.
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Vendor ID: AuthenticAMD
Model name: AMD Opteron(tm) Processor 6278
CPU family: 21
Model: 1
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 2
Stepping: 2
Frequency boost: enabled
CPU max MHz: 2400.0000
CPU min MHz: 1400.0000
BogoMIPS: 4799.96
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_go
od nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legac
y abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall arat npt lbrv svm_lock nrip_save ts
c_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 512 KiB (32 instances)
L1i: 1 MiB (16 instances)
L2: 32 MiB (16 instances)
L3: 24 MiB (4 instances)
NUMA:
NUMA node(s): 4
NUMA node0 CPU(s): 0-7
NUMA node1 CPU(s): 8-15
NUMA node2 CPU(s): 16-23
NUMA node3 CPU(s): 24-31
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Full AMD retpoline, STIBP disabled, RSB filling
Srbds: Not affected
Tsx async abort: Not affected
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 38 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
CPU family: 6
Model: 23
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 2
Stepping: 10
BogoMIPS: 4987.55
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts
rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm pti dtherm
Caches (sum of all):
L1d: 256 KiB (8 instances)
L1i: 256 KiB (8 instances)
L2: 24 MiB (4 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
Itlb multihit: KVM: Mitigation: VMX unsupported
L1tf: Mitigation; PTE Inversion
Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Meltdown: Mitigation; PTI
Spec store bypass: Vulnerable
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Full generic retpoline, STIBP disabled, RSB filling
Srbds: Not affected
Tsx async abort: Not affected
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmLApzJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfMwg/9HLPaRfeISaH8839BcocICzp93ka8Sy+P
sb9jYNFVaPh+xNsjRwQDSoaDEFR2gj0hmZHqRxjVCQHGufAP7d4jhSFeSjsJ+BsI
emwT4MzB8Fv8YKNtoIeiaSkV39PlLqZYT1vG1sHF+nezkspyCAf3Akppx6JNat+R
0eYZh9RREoDxTV40cOLKdV6KS9CpqMXr+O32pXqgWKTElEcbfGJp7tT4+qZg8knE
nRlWEcPfLMqHOS32E1B7Hw2zY8EKzzGxPhm1pddJgAvYIJyr60siSn/KC8nrBxHy
la3vpZD2Ne5JFrPHEPmSQhTZBfgf5e0WKbpeNKD5ORQKRkSVe7L5H7WwbscLaOw3
+Wm/euZzpFMnbZwiVMxjtOzSS54VaKSLddkFMJbh6ImnAXnlib0QJ+a3vHaOX2PM
kLKxc6bXapk4SUAntIHRut9ZtWpvh3x2MsqEru5npb8TMKTLe2cEgM2CJ+Y8tQRm
33THDGX+omfuUAvlIM0RjFw4ptsYtBq61gye+2QzqOOZw//rPtpzC+tSROmzjJRz
7ICWfWkwPJFGx5YF+jW65ZP2+5dnZjJ3Lmvp3U90mE2iemICNggIJXWGsuFN7RfV
jPsZ3bkXKyo18+btRNqXmagV533HBwLBuZi49K7tVq1LEGJAiEFL8NViQB+uSvNg
mDQOLlrg6eo=
=u0eA
-----END PGP SIGNATURE-----

B
B
bokr wrote on 3 Jul 2022 10:33
(name . Christopher Baines)(address . mail@cbaines.net)
20220703083325.GA40670@LionPure
Hi,

On +2022-07-02 20:26:40 +0100, Christopher Baines wrote:
Toggle quote (39 lines)
>
> Guillaume Le Vaillant <glv@posteo.net> writes:
>
> > [[PGP Signed Part:Undecided]]
> > Christopher Baines <mail@cbaines.net> skribis:
> >
> >> Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
> >>
> >>> On 2 July 2022 09:29:22 UTC, Wensheng Xie <xiewensheng@hotmail.com> wrote:
> >>>>Das Erstellungsprotokoll kann unter „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ eingesehen werden.
> >>>
> >>>
> >>> This log file is always a good idea to include.
> >>
> >> I think this is the equivalent non-grafted derivation:
> >>
> >> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
> >>
> >> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> >> get it to build successfully once though on my laptop.
> >>
> >> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> >> successfully, or if there's particular conditions for it to build?
> >>
> >> Thanks,
> >>
> >> Chris
> >
> > According to the logs, the 'build-doc' phase fails to compile the
> > documentation for SIMD related functions. There's a patch disabling this
> > part of the doc unless we compile on x86_64, but maybe not all x86_64
> > CPUs have the required instructions...
> >
> > Would it be possible to get the result of "lscpu" on some machines where
> > it fails?
>
> Sure, here is the lscpu output from the bayfront and harbourfront
> machines.
>
[...]

I wonder what running this at the time builds failed would have shown:

Toggle snippet (7 lines)
#/usr/bin/bash
# ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
top -n 1 | \
sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
-e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
-e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
(no guarantees on my hack to get rid of the highlighting escapes
and utf8->ascii quote subst :)
(top seems to assume even -n 1 output is always going to interactive dest)

Anyway, wondering: Could memory and CPU loading at the time
have triggered the build failure?
--
Regards,
Bengt Richter
G
G
Guillaume Le Vaillant wrote on 3 Jul 2022 10:51
(address . bokr@bokr.com)
8735fir2pi.fsf@kitej
bokr@bokr.com skribis:

Toggle quote (16 lines)
> I wonder what running this at the time builds failed would have shown:
>
> #/usr/bin/bash
> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
> top -n 1 | \
> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
> -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
> -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
>
> (no guarantees on my hack to get rid of the highlighting escapes
> and utf8->ascii quote subst :)
> (top seems to assume even -n 1 output is always going to interactive dest)
>
> Anyway, wondering: Could memory and CPU loading at the time
> have triggered the build failure?

I don't think so. It looks like the SB-SIMD optional module only gets
built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and
Harbourfront machines don't, and this is why the 'build-doc' phase fails
when trying to load SB-SIMD to compile its documentation.

I'm testing a patch disabling SB-SIMD, and I'll push it if all goes
well.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYsFaiQ8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j+lNgEAlSSNR6baqhAu+gDqjgi8l3E9WO1HsjZkMt10
snhdVogA/iyHouKmQVeqhRKh2Kg+9sQYPLzyLhcIbjMHDsgZX4GZ
=vKCC
-----END PGP SIGNATURE-----

G
G
Guillaume Le Vaillant wrote on 3 Jul 2022 12:09
(address . 56353-done@debbugs.gnu.org)
87y1xapks4.fsf@kitej
Guillaume Le Vaillant <glv@posteo.net> skribis:

Toggle quote (26 lines)
> bokr@bokr.com skribis:
>
>> I wonder what running this at the time builds failed would have shown:
>>
>> #/usr/bin/bash
>> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??)
>> top -n 1 | \
>> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
>> -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
>> -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
>>
>> (no guarantees on my hack to get rid of the highlighting escapes
>> and utf8->ascii quote subst :)
>> (top seems to assume even -n 1 output is always going to interactive dest)
>>
>> Anyway, wondering: Could memory and CPU loading at the time
>> have triggered the build failure?
>
> I don't think so. It looks like the SB-SIMD optional module only gets
> built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and
> Harbourfront machines don't, and this is why the 'build-doc' phase fails
> when trying to load SB-SIMD to compile its documentation.
>
> I'm testing a patch disabling SB-SIMD, and I'll push it if all goes
> well.

Patch pushed as e0d2f8164e6a1c15fdcae6f7dadb05c0c9e25352.
Closing.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYsFriw8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j/5dQD9EDVMQjAI8uX+UJIPLNKxsnOSJ21GyprR0ziJ
edM1vkUA/R6/X7fV26ZArk3+IKjflUWRZCccAZDqz05uotTlXE30
=iIAd
-----END PGP SIGNATURE-----

Closed
?
Your comment

This issue is archived.

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

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