bug#58285: secrets crashes when unlocking database

[Maxim Cournoyer]

Hi,

kias...@disroot.org writes:

> (.secrets-real:8886): Gtk-WARNING **: 01:35:46.681: GtkText - did not
> receive a focus-out event.
> If you handle this event, you must return
> GDK_EVENT_PROPAGATE so the default handler
> gets the event as well
> Traceback (most recent call last):
>   File
>   
> "/gnu/store/b07y8a2axslnz97pjdg7lp73xwk1gf8w-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/overrides/__init__.py",
>   line 351, in wrap
> return func(a, b, *user_data)
>   File
>   
> "/gnu/store/sadrq8giqh8f5r1x7ycxa2dciv1445f4-secrets-6.5/lib/python3.9/site-packages/gsecrets/sorting.py",
>   line 60, in sort_by_ctime_asc
> return ele1.ctime.compare(ele2.ctime)
> TypeError: GLib.DateTime.compare() takes exactly 2 arguments (1 given)

I could reproduce that; I first updated to version 7, but I had an
unrelated problem with otp something.  Unfortunately I'm not sure what's
wrong.  Would you have the time to open an issue with upstream?  You'll
need an account with their gitlab here:
https://gitlab.gnome.org/World/secrets.

-- 
Thanks,
Maxim

bug#56322: Debbug 56322, Ruby packaging issues, ping?

[Remco van 't Veer]

Hi Maxime,

Thanks for taking a look again.  I'll make a new patchset to correct the
things you mentioned.

2022/10/09 11:15, Maxime Devos:

> Otherwise, not that I know of, these patches appear
> straightforward. They might need to be done on core-updates though --
> unless this has changed, IIRC ruby-asciidoctor is deep in the package
> graph.

What's the protocol for "doing on core-updates"?  I guess I can rebase
on that but who will or should pick up these patches?  Is there somebody
I need to ping?

Remco

bug#57479: Inkscape can't find python-lxml

[Maxim Cournoyer]

Hi,

Leo Famulari  writes:

> I'm not able to create QR codes in Inkscape.
>
> I try to create a QR code in Inkscape by going through these menus:
> Extensions -> Render -> Barcode -> QR Code
>
> But, when I click "Apply" to create the QR code, Inkscape prints an
> error message like this:
>
> --
> Traceback (most recent call last):
>   File 
> "/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/render_barcode_qrcode.py",
>  line 30, in 
> import inkex
>   File 
> "/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/__init__.py",
>  line 11, in 
> from .extensions import *
>   File 
> "/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/extensions.py",
>  line 34, in 
> from .elements import (
>   File 
> "/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/elements/__init__.py",
>  line 9, in 
> from ._parser import SVG_PARSER, load_svg
>   File 
> "/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/elements/_parser.py",
>  line 30, in 
> from lxml import etree
> ModuleNotFoundError: No module named 'lxml'
> --
>
> Any ideas?

Wrap inkscape with GUIX_PYTHONPATH and 'python-lxml' as an input.  Or
simply install python-lxml (and python) in your user profile.

-- 
Thanks,
Maxim

bug#36869: gnome-todo won't create new todo list

[Maxim Cournoyer]

Hi,

Ricardo Wurmus  writes:

> Hi Jesse,
>
>> The name org.gnome.evolution.dataserver.Source5 was not provided
>> by any service files."
>
> Looks like it needs the evolution-dataserver package to be installed in
> a location where it is found for DBus activation.
>
> A work-around is to install that package globally (by adding it to the
> “packages” field in the operating system configuration) — or with a
> reasonably recent version of Guix to install it in the default profile
> (there’s a special case for DBus services installed to the default
> profile).
>
> A proper fix would involve propagating the evolution-dataserver package.

Done in 4451d08828.

Creating a new list in 'guix shell --pure endeavour -- endeavour' now
works for me.

Closing!

-- 
Thanks,
Maxim

bug#30265: Fish embeds store file names in UCS-4/UTF-32 literal strings

[Maxim Cournoyer]

Hi,

Mark H Weaver  writes:

> John Soo  writes:
>> I looked into it and I think a patch to fish might be required but I
>> got buried in other work.
>
> Note that commit 1bab9b9f17256a9e4f45f5b0cceb8b52e0a1b1ed (April 2021)
> added support in our grafting code to find and rewrite UTF-16 and UTF-32
> store references.  That might have mitigated or even eliminated the
> adverse effects of this bug.
>
> However, the Guix daemon's reference scanner still does not detect
> UTF-16/32 references.  This could be a problem if some store item is
> reachable *only* via UTF-16/32 store references, because "guix gc" might
> delete it even though it is still needed.
>
> However, if it is the case that every referenced store item is
> represented in ASCII or UTF-8 at least once, everything should work.
> Therefore, an easy workaround would be to add another phase that simply
> creates a file in the output(s) that contains ASCII or UTF-8 references
> to any needed store items.

Working with what I see (the fish build outputs results), the only UCS-4
references (either big or small endian) it registered to the store via
multi-byte encoded strings are:

--8<---cut here---start->8---
$ strings -e L /gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin/fish* 
| grep /gnu
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/share/doc/fish
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/share/fish
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/etc/fish
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin
strings -e B /gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin/fish* | 
grep /gnu
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/share/doc/fish
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/share/fish
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/etc/fish
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin
/gnu/store/qfy1rxm1vzd68y9jvcvq4zzz0cnbla8i-fish-3.5.1/bin
--8<---cut here---end--->8---

No UCS-2 references are detected via 'strings'.

Thanks for having shared the history and background.

Closing.

-- 
Maxim

bug#44903: Guix 1.2.0 installer 'auto-partition!' crash

[Maxim Cournoyer]

Hi,

Josselin Poiret  writes:

> Hi Maxim,
>
> Maxim Cournoyer  writes:
>
>> Mathieu, do you think this bug can still exist in 1.3.0 or our current
>> snapshot installer images?  If not, we should close it, as it's gone
>> stale and reported against 1.2.0.
>
> Just my 2 cents: I think this issue was fixed with
> 0a74509a696671580c8a7dc768d26f414748bab5.  Sometimes, devices are so
> small you can't even create a new partition table on them, and we used
> to not detect this failure and instead return #f for the disk.  That or
> ped_disk_new fails for some reason but I wouldn't know why without more
> info.

Thanks for the heads-up.  I'm tentatively closing the bug.

-- 
Thanks,
Maxim

bug#30290: guix-daemon slows to a crawl when a substitute server is offline

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi Maxim,
>
> On Wed, 23 Mar 2022 at 11:50, zimoun  wrote:
>> On Wed, 18 Aug 2021 at 22:25, Maxim Cournoyer  
>> wrote:
>
>>> Extra note: the problems reported earlier (hang or backtrace instead of
>>> graceful fallback to other substitute servers) also affect the scenario
>>> where substitutes are fetched from uDNS discovered substitute servers (I
>>> just tried).
>>
>> I guess this old bug [1] about the daemon hanging is still there, right?
>>
>> How such issue could be tackled?
>>
>> 1: 
>
> What could be actionable for tackling this old bug?

I can't seem to reproduce the original issue, which was that an offline
server would slow down fetching of substitutes by repeatedly trying to
reach it, at least when setting e.g.:

--8<---cut here---start->8---
127.0.0.2 ci.guix.gnu.org
--8<---cut here---end--->8---

In my /etc/hosts file to simulate it's unreachable, with at least
another substitute server available in my --substitute-urls list.  It
goes right to that second server without loosing any time.

Closing for now, we can always reopen the issue if it manifests itself
in the future.

-- 
Thanks,
Maxim

bug#57933: Gtk is unsupported on i686-linux

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> I had the following error while trying out `make release` for
> `i686-linux` specifically.
>
> + for example in gnu/system/examples/*.tmpl
> + case "$example" in
> + options=
> + guix system -n disk-image gnu/system/examples/desktop.tmpl
> accepted connection from pid 17139, user nixbld
> guix system: warning: 'disk-image' is deprecated: use 'image' instead
> guix system: error: package gvfs@1.50.2 does not support i686-linux
> + rm -f t-guix-system-16656 t-guix-system-error-16656 
> /tmp/guix-build-guix-1.3.0.24760-34049.drv-0/t-guix-system-16656/config.scm 
> /tmp/guix-build-guix-1.3.0.24760-34049.drv-0/t-guix-system-16656/my-torrc
> + rmdir /tmp/guix-build-guix-1.3.0.24760-34049.drv-0/t-guix-system-16656
> FAIL tests/guix-system.sh (exit status: 1)

I reported and fixed this one recently:

  https://issues.guix.gnu.org/58352

> Turns out, Gtk is unsupported on i686-linux which is problematic to
> build the desktop.tmpl image.
>
> mathieu@meije ~/guix [env]$ make -j8 && ./pre-inst-env guix build gtk -s 
> i686-linux
> gnu/packages/gtk.scm:1182:2: warning: package gtk@4.8.0 does not support 
> i686-linux

That is still the case due to Rust being pulled in via librsvg:

--8<---cut here---start->8---
$ ./pre-inst-env  guix graph --path gtk librsvg
gtk@4.8.1
gst-plugins-bad@1.18.5
librsvg@2.50.7
--8<---cut here---end--->8---

(Time passes…)

I pushed things to make ‘gst-plugins-bad’ supported on i686-linux:

--8<---cut here---start->8---
27a3a5d193 gnu: svt-hevc: Mark as supported on x86_64-linux only.
e3362e249a gnu: directfb: Remove input labels.
3714c8bdcd gnu: gst-plugins-bad: Use 'librsvg-for-system'.
c3b0be1fa2 gnu: directfb: Use 'librsvg-for-system'.
--8<---cut here---end--->8---

But now there’s an ‘openexr’ test failure on i686.

And GTK has another path to unsupported software on i686-linux.

(Note that we’re talking about GTK 4.x, not GTK+, so maybe we can live
with that for now.  At least it no longer affects ‘desktop.tmpl’ and GTK
has relatively few dependents at this point.)

Ludo’.

bug#58366: Guix build guix fails on i686

[Ludovic Courtès]

Hi,

Denis 'GNUtoo' Carikli  skribis:

> After a guix pull it now builds fine again. I've tested it with guix
> build -s i686-linux on x86_64 and guix build guix on i686.

Yes, this was addressed in .

> So the bug can now be closed.

Done, thanks!

Ludo’.

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Samuel Thibault]

Ludovic Courtès, le dim. 09 oct. 2022 18:09:07 +0200, a ecrit:
> So it would seem that ‘_dl_start’ is called and somehow then a tail-call
> to ‘_dl_fatal_printf’ is made.

Perhaps you can build glibc without tail-call optimization?
(-fno-optimize-sibling-calls)

Samuel

bug#58399: [BUG] guix-emacs error -

[florhizome]

Hello,
when trying to use guix' emacs UI recently, the minibuffer command
interface won't work. The issue and a possible fix (a one-line patch)
has already been described here:
https://gitlab.com/emacs-guix/emacs-guix/-/issues/30
It comes from the newer geiser not containing a file for company support
anymore. Since the afroementioned gitlab-repo doesn't have commits since
a year, I think it's sensible to go ahead and patch it by ourselves
instead of waiting for a fix. But personally I am not very experienced
in doing such a thing.
Best wishes,
florhizome

bug#58375: Installer does not show what is being downloaded

[Ludovic Courtès]

Hello!

Josselin Poiret  skribis:

> Julien Lepiller  writes:
>> I installed Guix on a new drive, so I tried the installer from the latest 
>> image. After reviewing the system config, the installer goes to a black 
>> screen where guix output is shown. Although I can see messages about 
>> substitutes being updated, and how much will be downloaded, all download 
>> lines are replaced with a seemingly random number of dots:
>>
>> substitute: mise à jour des substituts depuis «…»... 100.0 %
>> 4.5 Mo seront téléchargés.
>> .
>> ...
>> .
>> .
>> ..
>>
>> Maybe this is related to the translation?
>
> I agree that this does look pretty bad, but this is because we capture
> the guix command output to a log file so that we're able to include it
> in the installer dump if anything goes wrong.  Guix detects it's not
> talking directly to a terminal and so doesn't try to use terminal
> specific escape codes to display the download progress.  I don't know
> how we could improve on that front though, since in general capturing
> the guix command output helps with debugging issues.

This is a duplicate of , marked as
important.

I think capturing all the output as-is is overkill; one option I
suggested in the bug report above is to syslog specific events of
interest during ‘guix system init’.

Thoughts?

Ludo’.

bug#58384: copy-build-system assumes that strip-flags, strip-directories is a S-exp, but it isn't.

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> This fixes a bug introduced in ccc2658e2a111590ec25e308946e47a24d357785,
> reported at .
>
> Tested with "./pre-inst-env guix build openjpeg-data".
>
> Fixes: https://issues.guix.gnu.org/issue/58384
>
> * guix/build-system/copy.scm (copy-build): 'strip-flags' and
> '#:strip-directories' are G-exps, not S-exps, so don't use sexp->gexp.
> * guix/build-system/cmake.scm (copy-build): Likewise.
> * guix/build-system/glib-or-gtk.scm
> (glib-or-gtk-build,glib-or-gtk-cross-build): Likewise.
> * guix/build-system/maven.scm (maven-build): Likewise.
> * guix/build-system/meson.scm
> (meson-build,meson-cross-build): Likewise.

Oops.  Applied, thanks for the quick fix!

Ludo’.

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> $ addr2line -e  
> /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1
>  0x1000 0x11627 0x11bb
> ??:0
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333
> :?
>
>
> That’s ‘_dl_fatal_printf’ calling ‘_exit’; it’s trying to tell us
> something.
>
> I’ll try and rebuild the system with the debugging patches at
> , to
> get early ld.so output, for lack of a better solution…

I tried adapted the patches above and tried them, but it seems that
‘_dl_sysdep_start’ isn’t even reached.  For example, I set a breakpoint
on ‘mach_task_self’ (called from ‘__mach_init’, called from
‘_dl_sysdep_start’), but that’s never reached (I’m assuming ‘break/tu’
is reliable, is it?).

The user-space backtrace upon trap remains unhelpful:

--8<---cut here---start->8---
start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]Kernel Breakpoint 
trap,
 eip 0xc1030d5b 

Breakpoint at  task_resume: pushl   %ebp

db> debug traps /on 

db> b task_terminate

set breakpoint #2   

db> c   

Kernel Debug trap trap, eip 0xc1030d5b  

 execkernel: Page fault (14), code=6

Stopped at  0x1000: pushl   0x4(%ebx)   

> user space <  
> 
0x1000(bf24,0,0,1160b,0)

0x11627(bf9c,0,0,0,2)   

0x11bb()

--8<---cut here---end--->8---

… where:

--8<---cut here---start->8---
$ addr2line -e 
/gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1
 0x11627 0x11bb
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333
:?
$ objdump -S 
/gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1
 --start-address=0x11b0 |head -40

/gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1:
 file format elf32-i386


Disassembly of section .text:

11b0 <_start>:
11b0:   89 e0   mov%esp,%eax
11b2:   83 ec 0csub$0xc,%esp
11b5:   50  push   %eax
11b6:   e8 b5 0a 00 00  call   1c70 <_dl_start>
11bb:   83 c4 10add$0x10,%esp
--8<---cut here---end--->8---

So it would seem that ‘_dl_start’ is called and somehow then a tail-call
to ‘_dl_fatal_printf’ is made.

Through a dichotomy I tried to see how far it goes.  The info I have so
far is that ld.so errors out from elf/rtld.c:563 (line 565 is not
reached):

--8<---cut here---start->8---
558:  if (bootstrap_map.l_addr || ! 
bootstrap_map.l_info[VALIDX(DT_GNU_PRELINKED)])
559:{
560:  /* Relocate ourselves so we can do normal function calls and
561: data access using the global offset table.  */
562:
563:  ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0, 0);
564:}
565:  bootstrap_map.l_relocated = 1;
...
578:  __rtld_malloc_init_stubs ();
--8<---cut here---end--->8---

It’s hard to be more precise because ELF_DYNAMIC_RELOCATE is a macro
that expands to quite a lot of code.

I don’t see the code path that would lead to a ‘_dl_fatal_printf’ call
though.

Ideas?  :-)

Ludo’.

bug#58384: [core-updates] build-system: Fix uses of #:strip-flags and #:strip-directories.

[Maxime Devos]

This fixes a bug introduced in ccc2658e2a111590ec25e308946e47a24d357785,
reported at .

Tested with "./pre-inst-env guix build openjpeg-data".

Fixes: https://issues.guix.gnu.org/issue/58384

* guix/build-system/copy.scm (copy-build): 'strip-flags' and
'#:strip-directories' are G-exps, not S-exps, so don't use sexp->gexp.
* guix/build-system/cmake.scm (copy-build): Likewise.
* guix/build-system/glib-or-gtk.scm
(glib-or-gtk-build,glib-or-gtk-cross-build): Likewise.
* guix/build-system/maven.scm (maven-build): Likewise.
* guix/build-system/meson.scm
(meson-build,meson-cross-build): Likewise.
---
 guix/build-system/cmake.scm   | 4 ++--
 guix/build-system/copy.scm| 4 ++--
 guix/build-system/glib-or-gtk.scm | 8 
 guix/build-system/maven.scm   | 4 ++--
 guix/build-system/meson.scm   | 8 
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/guix/build-system/cmake.scm b/guix/build-system/cmake.scm
index ffd04867a2..effb54f044 100644
--- a/guix/build-system/cmake.scm
+++ b/guix/build-system/cmake.scm
@@ -149,8 +149,8 @@ (define build
  #:validate-runpath? #$validate-runpath?
  #:patch-shebangs? #$patch-shebangs?
  #:strip-binaries? #$strip-binaries?
- #:strip-flags #$(sexp->gexp strip-flags)
- #:strip-directories #$(sexp->gexp 
strip-directories))
+ #:strip-flags #$strip-flags
+ #:strip-directories #$strip-directories)
 
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
   system #:graft? #f)))
diff --git a/guix/build-system/copy.scm b/guix/build-system/copy.scm
index ea85719286..bf7fcaedba 100644
--- a/guix/build-system/copy.scm
+++ b/guix/build-system/copy.scm
@@ -122,8 +122,8 @@ (define builder
 #:validate-runpath? #$validate-runpath?
 #:patch-shebangs? #$patch-shebangs?
 #:strip-binaries? #$strip-binaries?
-#:strip-flags #$(sexp->gexp strip-flags)
-#:strip-directories #$(sexp->gexp 
strip-directories))
+#:strip-flags #$strip-flags
+#:strip-directories #$strip-directories)
 
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
   system #:graft? #f)))
diff --git a/guix/build-system/glib-or-gtk.scm 
b/guix/build-system/glib-or-gtk.scm
index a9041bb9f9..f4f431273b 100644
--- a/guix/build-system/glib-or-gtk.scm
+++ b/guix/build-system/glib-or-gtk.scm
@@ -178,9 +178,9 @@ (define build
#:validate-runpath? #$validate-runpath?
#:patch-shebangs? #$patch-shebangs?
#:strip-binaries? #$strip-binaries?
-   #:strip-flags #$(sexp->gexp strip-flags)
+   #:strip-flags #$strip-flags
#:strip-directories
-   #$(sexp->gexp strip-directories))
+   #$strip-directories)
 
 
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
@@ -271,9 +271,9 @@ (define %outputs
#:make-dynamic-linker-cache? 
#$make-dynamic-linker-cache?
#:patch-shebangs? #$patch-shebangs?
#:strip-binaries? #$strip-binaries?
-   #:strip-flags #$(sexp->gexp strip-flags)
+   #:strip-flags #$strip-flags
#:strip-directories
-   #$(sexp->gexp strip-directories
+   #$strip-directories)))
 
 
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
diff --git a/guix/build-system/maven.scm b/guix/build-system/maven.scm
index c5a26c8754..9a17dea977 100644
--- a/guix/build-system/maven.scm
+++ b/guix/build-system/maven.scm
@@ -183,8 +183,8 @@ (define builder
#:validate-runpath? #$validate-runpath?
#:patch-shebangs? #$patch-shebangs?
#:strip-binaries? #$strip-binaries?
-   #:strip-flags #$(sexp->gexp strip-flags)
-   #:strip-directories #$(sexp->gexp strip-directories)
+   #:strip-flags #$strip-flags
+   #:strip-directories #$strip-directories
 
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
   system #:graft? #f)))
diff --git a/guix/build-system/meson.scm b/guix/build-system/meson.

bug#56322: Debbug 56322, Ruby packaging issues, ping?

[Maxime Devos]

On 08-10-2022 12:01, Remco van 't Veer wrote:

Do the patches[1][2] need more work?


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56322#11
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56322#29


Trailing #t haven' been necessary since a long time, and  ...

> + (define baseruby ;; used to build ruby by parser generator

... I don't think this is quite grammatical, maybe ';; for bootstrapping 
ruby's parser generator' or ';; used to build ruby's parser generator'?


Otherwise, not that I know of, these patches appear straightforward. 
They might need to be done on core-updates though -- unless this has 
changed, IIRC ruby-asciidoctor is deep in the package graph.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature