bug#52808: Guix home should not assume that all targets are dot files

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin  skribis:

> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>
>> The following configuration results in a `~/.run` symlink being
>> created. My expectation is that a `~/run` symlink is created
>> instead. (ie. not a dotfile)
>
> Some how I missed it and not documented home-files-service-type in the
> manual, I'll add it soon.  Thank you for mentioning it.  It should break
> this expectation :)
>
>>> (home-environment
>>>   (services
>>> (list (service
>>> home-bash-service-type
>>> (home-bash-configuration
>>>   (guix-defaults? #t)))
>>>   (simple-service 'my-files
>>>   home-files-service-type
>>>   `(("run" ,(local-file "run")))
>>
>> This applies to all other targets. My expectation is that the
>> configuration should expect the exact target and not make an
>> assumption that all targets are hidden files, since that allows for
>> more utility:

I share Nick’s surprise.  :-)

[...]

> It's intentional and is a part of a design decision:
>
> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
> chans.scm goes not to ~/.config/guix/channels.scm, but to
> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
> from ~/.config, absent dot should partially break this expectation.
>
> It's a bad practice to use something without "config/..."  prefix and
> generally it should be avoided, it still possible to use something
> different in rare use-cases, for example for zsh: ("zshenv"
> ,zshenv-file-like-here), because it's hard to implement the lookup for
> initial configuration file other way for shells.

Oh, I see.

> You can elaborate more on what you try to achieve and I can try to give
> you a recommendation how to implement it.

I’d expect ‘home-files-service-type’ to do just that: add files to the
home directory, without trying to be smart.

Would it make sense to distinguish between ‘home-files’ and (say)
‘home-xdg-configuration-files’?

The latter would copy files to $XDG_CONFIG_DIR at activation time,
whereas the former would just copy them to $HOME.


I’d also suggest removing special handling of HOME/files in
symlink-manager.scm.  Relations between the various components of Guix
Home should preferably be made explicit via service extensions, and not
implicit through conventions like this ‘files’ sub-directory.

Thoughts?

Ludo’.

bug#52801: Guile misbehaves in case of escapes and carriage returns, sometimes breaking "guix pull"

[Ludovic Courtès]

Hi,

Grigory Shepelev  skribis:

> shegeley@zone51 ~$ guix pull
> Updating channel 'nonguix' from Git repository at 
> 'https://gitlab.com/nonguix/nonguix'...
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from these channels:
>   guix  https://git.savannah.gnu.org/git/guix.git 2495582
>   nonguix   https://gitlab.com/nonguix/nonguix39e4b41
> Computing Guix derivation for 'x86_64-linux'... -ice-9/read.scm:126:4: In 
> procedure read-string:
> gnu/packages/virtualization.scm:640:1: invalid character in escape sequence: 
> #\return
> guix pull: error: You found a bug: the program 
> '/gnu/store/w1hd6ab7f92y0f2r1ah4yyvi205a71bc-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "2495582e08cf411163f0799d290fda5101141949"; system: "x86_64-linux";
> host version: "1dfe8c372163d481ebebb97dd3b4cafa49906b28"; pull-version: 1).

Maxime Devos  skribis:

> Seems like an instance of .
> I took the liberty of renaming the bug report appropriately.
>
> Anyway, here's the minimal reproducer:
>
> Run the following in a REPL:
> (call-with-input-string "\"Hello\\\rcarriage return!\"" read)
> ;; --> invalid character in escape sequence: #\return

That’s expected.  Conversely, this one works:

  (call-with-input-string "\"Hello \\\nnewline!\"" read)

What was in gnu/packages/virtualization.scm:640:1 at that point?

--8<---cut here---start->8---
$ git ls-tree 2495582e08cf411163f0799d290fda5101141949 -- gnu/packages
04 tree 8070c9587f76797cf16800522688ded39c956d00gnu/packages
$ git ls-tree 8070c9587f76797cf16800522688ded39c956d00 |grep virtuali
100644 blob 20ffb4a481239349078e2a2864d1bd873dfcd143virtualization.scm
$ git show 20ffb4a481239349078e2a2864d1bd873dfcd143 |head -649 |tail -10
"/run/setuid-programs:/run/current-system/profile/sbin:\
/run/current-system/profile/bin"
 (add-after 'bootstrap 'patch-sphinx-version-detection
   (lambda _
 ;; The build system runs 'sphinx-build --version' to verify that
 ;; the Sphinx is recent enough, but does not expect the
 ;; .sphinx-build-real executable name created by the Sphinx 
wrapper.
 (substitute* "configure"
   (("\\$SPHINX --version 2>&1")
"$SPHINX --version 2>&1 \
--8<---cut here---end--->8---

AFAICS, this was a regular \n (not \r) following backslash.

Did the issue magically disappear?

Grigory, could it be that libgit2 somehow converted \n to \r\n on your
machine, or that you manually accesses files under
~/.cache/guix/checkouts?

Thanks,
Ludo’.

bug#52788: static networking: Support pointopoint/peer

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> It was not supported in guile-netlink, so I added support for #:peer and 
> other new arguments in addr-add and addr-del. There's no release yet, but I'd 
> be glad if you could check it works as expected (--with-latest=guile-netlink 
> should work).

Perhaps we also need to update  and related code in
(gnu services base) to expose that?

Ludo’.

bug#53561: Failing: guix package -i gtkmm@3

[Leo Famulari]

On Sun, Jan 30, 2022 at 10:01:41AM +, Dale Mellor wrote:
> I am trying to install a package, defined right there in the GUIX repo, 
> which propagates two different versions of
> libsigc++.

I see. That should be fixed.

It's true that my earlier reply was kind of dense, but you didn't put
any effort into your initial report, and thus you did not communicate
the problem effectively. You have to understand that we triage bug
reports from people with all levels of skill and experience.

bug#53616: Acknowledgement (build error k14i8vsbnihnghg9xhavs9p3yrxsa431-compute-guix-derivation)

[liberty4us--- via Bug reports for GNU Guix]

Ah, I see.  Thanks, Leo Famulari!

Well, it appears that aarch64 gets no love.  :\

Unfortunately, my calendar doesn't permit me to be more involved, so I will 
check back in a few months and see if the situation has changed.  In the 
meantime, rm -rf /gnu.

bug#53616: Acknowledgement (build error k14i8vsbnihnghg9xhavs9p3yrxsa431-compute-guix-derivation)

[Leo Famulari]

On Sun, Jan 30, 2022 at 05:15:29PM +0100, liberty4us--- via Bug reports for GNU 
Guix wrote:
> Ah, I see.  Thanks, Leo Famulari!
> 
> Well, it appears that aarch64 gets no love.  :\

It does get some love, but clearly it needs more.

> Unfortunately, my calendar doesn't permit me to be more involved, so I will 
> check back in a few months and see if the situation has changed.  In the 
> meantime, rm -rf /gnu.

Okay. I do think the situation will stabilize in a few months. I hope we
see you then!

bug#52801: Guile misbehaves in case of escapes and carriage returns, sometimes breaking "guix pull"

[Grigory Shepelev]

That explains why the problem was raised on my desktop PC as well. It uses
the same .gitconfig file.

вс, 30 янв. 2022 г. в 22:45, Grigory Shepelev :

> Seems like the problem was in my .gitconfig file where "autocrlf = true".
> I set it to "false", and cleared the cache. Then the "guix pull" started to
> work as expected.
> I don't even remember why I had to get into "git's guts". Something like:
> had some problem with some exact project where my colleague used macOS or
> windows and some files that came from git had some problems with that.
>
> вс, 30 янв. 2022 г. в 20:52, Ludovic Courtès :
>
>> Hi,
>>
>> Grigory Shepelev  skribis:
>>
>> > shegeley@zone51 ~$ guix pull
>> > Updating channel 'nonguix' from Git repository at '
>> https://gitlab.com/nonguix/nonguix'...
>> > Updating channel 'guix' from Git repository at '
>> https://git.savannah.gnu.org/git/guix.git'...
>> > Building from these channels:
>> >   guix  https://git.savannah.gnu.org/git/guix.git 2495582
>> >   nonguix   https://gitlab.com/nonguix/nonguix39e4b41
>> > Computing Guix derivation for 'x86_64-linux'... -ice-9/read.scm:126:4:
>> In procedure read-string:
>> > gnu/packages/virtualization.scm:640:1: invalid character in escape
>> sequence: #\return
>> > guix pull: error: You found a bug: the program
>> '/gnu/store/w1hd6ab7f92y0f2r1ah4yyvi205a71bc-compute-guix-derivation'
>> > failed to compute the derivation for Guix (version:
>> "2495582e08cf411163f0799d290fda5101141949"; system: "x86_64-linux";
>> > host version: "1dfe8c372163d481ebebb97dd3b4cafa49906b28"; pull-version:
>> 1).
>>
>> Maxime Devos  skribis:
>>
>> > Seems like an instance of .
>> > I took the liberty of renaming the bug report appropriately.
>> >
>> > Anyway, here's the minimal reproducer:
>> >
>> > Run the following in a REPL:
>> > (call-with-input-string "\"Hello\\\rcarriage return!\"" read)
>> > ;; --> invalid character in escape sequence: #\return
>>
>> That’s expected.  Conversely, this one works:
>>
>>   (call-with-input-string "\"Hello \\\nnewline!\"" read)
>>
>> What was in gnu/packages/virtualization.scm:640:1 at that point?
>>
>> --8<---cut here---start->8---
>> $ git ls-tree 2495582e08cf411163f0799d290fda5101141949 -- gnu/packages
>> 04 tree 8070c9587f76797cf16800522688ded39c956d00gnu/packages
>> $ git ls-tree 8070c9587f76797cf16800522688ded39c956d00 |grep virtuali
>> 100644 blob 20ffb4a481239349078e2a2864d1bd873dfcd143virtualization.scm
>> $ git show 20ffb4a481239349078e2a2864d1bd873dfcd143 |head -649 |tail -10
>> "/run/setuid-programs:/run/current-system/profile/sbin:\
>> /run/current-system/profile/bin"
>>  (add-after 'bootstrap 'patch-sphinx-version-detection
>>(lambda _
>>  ;; The build system runs 'sphinx-build --version' to verify
>> that
>>  ;; the Sphinx is recent enough, but does not expect the
>>  ;; .sphinx-build-real executable name created by the Sphinx
>> wrapper.
>>  (substitute* "configure"
>>(("\\$SPHINX --version 2>&1")
>> "$SPHINX --version 2>&1 \
>> --8<---cut here---end--->8---
>>
>> AFAICS, this was a regular \n (not \r) following backslash.
>>
>> Did the issue magically disappear?
>>
>> Grigory, could it be that libgit2 somehow converted \n to \r\n on your
>> machine, or that you manually accesses files under
>> ~/.cache/guix/checkouts?
>>
>> Thanks,
>> Ludo’.
>>
>

bug#52801: Guile misbehaves in case of escapes and carriage returns, sometimes breaking "guix pull"

[Grigory Shepelev]

Seems like the problem was in my .gitconfig file where "autocrlf = true". I
set it to "false", and cleared the cache. Then the "guix pull" started to
work as expected.
I don't even remember why I had to get into "git's guts". Something like:
had some problem with some exact project where my colleague used macOS or
windows and some files that came from git had some problems with that.

вс, 30 янв. 2022 г. в 20:52, Ludovic Courtès :

> Hi,
>
> Grigory Shepelev  skribis:
>
> > shegeley@zone51 ~$ guix pull
> > Updating channel 'nonguix' from Git repository at '
> https://gitlab.com/nonguix/nonguix'...
> > Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...
> > Building from these channels:
> >   guix  https://git.savannah.gnu.org/git/guix.git 2495582
> >   nonguix   https://gitlab.com/nonguix/nonguix39e4b41
> > Computing Guix derivation for 'x86_64-linux'... -ice-9/read.scm:126:4:
> In procedure read-string:
> > gnu/packages/virtualization.scm:640:1: invalid character in escape
> sequence: #\return
> > guix pull: error: You found a bug: the program
> '/gnu/store/w1hd6ab7f92y0f2r1ah4yyvi205a71bc-compute-guix-derivation'
> > failed to compute the derivation for Guix (version:
> "2495582e08cf411163f0799d290fda5101141949"; system: "x86_64-linux";
> > host version: "1dfe8c372163d481ebebb97dd3b4cafa49906b28"; pull-version:
> 1).
>
> Maxime Devos  skribis:
>
> > Seems like an instance of .
> > I took the liberty of renaming the bug report appropriately.
> >
> > Anyway, here's the minimal reproducer:
> >
> > Run the following in a REPL:
> > (call-with-input-string "\"Hello\\\rcarriage return!\"" read)
> > ;; --> invalid character in escape sequence: #\return
>
> That’s expected.  Conversely, this one works:
>
>   (call-with-input-string "\"Hello \\\nnewline!\"" read)
>
> What was in gnu/packages/virtualization.scm:640:1 at that point?
>
> --8<---cut here---start->8---
> $ git ls-tree 2495582e08cf411163f0799d290fda5101141949 -- gnu/packages
> 04 tree 8070c9587f76797cf16800522688ded39c956d00gnu/packages
> $ git ls-tree 8070c9587f76797cf16800522688ded39c956d00 |grep virtuali
> 100644 blob 20ffb4a481239349078e2a2864d1bd873dfcd143virtualization.scm
> $ git show 20ffb4a481239349078e2a2864d1bd873dfcd143 |head -649 |tail -10
> "/run/setuid-programs:/run/current-system/profile/sbin:\
> /run/current-system/profile/bin"
>  (add-after 'bootstrap 'patch-sphinx-version-detection
>(lambda _
>  ;; The build system runs 'sphinx-build --version' to verify
> that
>  ;; the Sphinx is recent enough, but does not expect the
>  ;; .sphinx-build-real executable name created by the Sphinx
> wrapper.
>  (substitute* "configure"
>(("\\$SPHINX --version 2>&1")
> "$SPHINX --version 2>&1 \
> --8<---cut here---end--->8---
>
> AFAICS, this was a regular \n (not \r) following backslash.
>
> Did the issue magically disappear?
>
> Grigory, could it be that libgit2 somehow converted \n to \r\n on your
> machine, or that you manually accesses files under
> ~/.cache/guix/checkouts?
>
> Thanks,
> Ludo’.
>

bug#52788: static networking: Support pointopoint/peer

[Julien Lepiller]

Le Sun, 30 Jan 2022 18:53:29 +0100,
Ludovic Courtès  a écrit :

> Hi Julien,
> 
> Julien Lepiller  skribis:
> 
> > It was not supported in guile-netlink, so I added support for
> > #:peer and other new arguments in addr-add and addr-del. There's no
> > release yet, but I'd be glad if you could check it works as
> > expected (--with-latest=guile-netlink should work).  
> 
> Perhaps we also need to update  and related code in
> (gnu services base) to expose that?
> 
> Ludo’.

Yes, otherwise we won't be able to use that in static-networking.

bug#52993: Acknowledgement (There is a problem with text rendering in the anki)

[Igor Gajsin]

Sorry, I somehow missed this bug, I can confirm that trick with
QTWEBENGINE_CHROMIUM_FLAGS= works for me.

-- 
With best regards,
Igor Gajsin

bug#52801: Guile misbehaves in case of escapes and carriage returns, sometimes breaking "guix pull"

[Maxime Devos]

Grigory Shepelev schreef op zo 30-01-2022 om 22:45 [+0300]:
> Seems like the problem was in my .gitconfig file where "autocrlf =
> true". I set it to "false", and cleared the cache. Then the "guix
> pull" started to work as expected. 

According to

and ,
we can tell libgit to not do CRLF conversion, which would make (guix git)
more robust.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#53645: Unable to guix pull on pinebook pro

[D. Birch]

As title.

I'm using a pinebook pro (arm64) and guix pull is giving up on me.

I've attached the output of stdout and stderr.

Did I do something wrong?


guix-pull-bug
Description: Binary data

bug#53204: [patch] font-cns11643: ... unzip error

[Brendan Tildesley]

I tried updating it but came across an unzip error, maybe unicode related. I've 
also noticed in my Icecat there are all these icons that are showing as random 
korean characters, so I wonder if my configuration is wrong somehow??:
 

starting phase `unpack'
Archive:  /gnu/store/lcnarbk2vd6l1qj77i2s4ny92chzpbzg-Open_Data.zip
   creating: Open_Data/
   creating: Open_Data/Fonts/
  inflating: Open_Data/Fonts/png_24x24.zip  
  inflating: Open_Data/Fonts/TW-Kai-98_1.ttf  
  inflating: Open_Data/Fonts/TW-Kai-Ext-B-98_1.ttf  
  inflating: Open_Data/Fonts/TW-Kai-Plus-98_1.ttf  
  inflating: Open_Data/Fonts/TW-Sung-98_1.ttf  
  inflating: Open_Data/Fonts/TW-Sung-Ext-B-98_1.ttf  
  inflating: Open_Data/Fonts/TW-Sung-Plus-98_1.ttf  
Open_Data/Fonts/#U5168#U5b57#U5eab#U5b57#U578b#U8aaa#U660e#U6587#U4ef6.txt:  
mismatching "local" filename (Open_Data/Fonts/???.txt),
 continuing with "central" filename version
  inflating: 
Open_Data/Fonts/#U5168#U5b57#U5eab#U5b57#U578b#U8aaa#U660e#U6587#U4ef6.txt  
   creating: Open_Data/MapingTables/
   creating: Open_Data/MapingTables/Big5/
  inflating: Open_Data/MapingTables/Big5/CNS2BIG5.txt  
  inflating: Open_Data/MapingTables/Big5/CNS2BIG5_Big5E.txt  
Open_Data/MapingTables/Big5/CNS2BIG5_#U4e03#U500b#U501a#U5929#U5916#U5b57.txt:  
mismatching "local" filename 
(Open_Data/MapingTables/Big5/CNS2BIG5_??.txt),
 continuing with "central" filename version
  inflating: 
Open_Data/MapingTables/Big5/CNS2BIG5_#U4e03#U500b#U501a#U5929#U5916#U5b57.txt  
Open_Data/MapingTables/Big5/CNS2BIG5_#U7b26#U865f.txt:  mismatching "local" 
filename (Open_Data/MapingTables/Big5/CNS2BIG5_??.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/Big5/CNS2BIG5_#U7b26#U865f.txt  
  inflating: Open_Data/MapingTables/CNS2DCI.txt  
  inflating: Open_Data/MapingTables/CNS2FIN.txt  
  inflating: Open_Data/MapingTables/CNS2INC.txt  
  inflating: Open_Data/MapingTables/CNS2TAX.txt  
   creating: Open_Data/MapingTables/Unicode/
  inflating: Open_Data/MapingTables/Unicode/CNS2UNICODE_Unicode 15.txt  
  inflating: Open_Data/MapingTables/Unicode/CNS2UNICODE_Unicode 2.txt  
  inflating: Open_Data/MapingTables/Unicode/CNS2UNICODE_Unicode BMP.txt  
Open_Data/MapingTables/#U5168#U5b57#U5eab#U4e2d#U6587#U5c0d#U7167#U8868#U8aaa#U660e#U6587#U4ef6.txt:
  mismatching "local" filename 
(Open_Data/MapingTables/.txt),
 continuing with "central" filename version
  inflating: 
Open_Data/MapingTables/#U5168#U5b57#U5eab#U4e2d#U6587#U5c0d#U7167#U8868#U8aaa#U660e#U6587#U4ef6.txt
  
Open_Data/MapingTables/#U5730#U653f/:  mismatching "local" filename 
(Open_Data/MapingTables/??/),
 continuing with "central" filename version
   creating: Open_Data/MapingTables/#U5730#U653f/
Open_Data/MapingTables/#U5730#U653f/#U5357#U6295#U7e23.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U5357#U6295#U7e23.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U4e2d#U5e02.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U4e2d#U5e02.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U4e2d#U7e23.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U4e2d#U7e23.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U5317#U5e02.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U5317#U5e02.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U5317#U7e23.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U5317#U7e23.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U5357#U5e02.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U5357#U5e02.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U5357#U7e23.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U5357#U7e23.txt  
Open_Data/MapingTables/#U5730#U653f/#U53f0#U6771#U7e23.txt:  mismatching 
"local" filename (Open_Data/MapingTables/??/?.txt),
 continuing with "central" filename version
  inflating: Open_Data/MapingTables/#U5730#U653f/#U53f0#U6771#U7e23.txt  
Open_Data/MapingTables/#U5730#U653f/#U56

bug#53647: __TIMESTAMP__ CPP macro not honoring SOURCE_EPOCH_DATE

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> * gnu/packages/electronics.scm (openboardview): New variable.

I've found a source of nondeterminism in the build of openboardview: the
use of the CPP __TIMESTAMP__ macro (info '(cpp) Common Predefined
Macros').  It seems that GCC 10.3.0 still doesn't doesn't honor
SOURCE_EPOCH_DATE for that macro.  A patch was made to correct this, but
it seems it was never applied [0].  I've ping'd in the #gcc channel to
verify.

I haven't seen the patch carried by Debian for their GCC package.

Thanks,

Maxim

[0]  https://gcc.gnu.org/pipermail/gcc-patches/2016-November/461108.html

bug#53559: Mutter test-suite is flaky

[Maxim Cournoyer]

Hello Liliana,

Liliana Marie Prikler  writes:

> * gnu/packages/gnome.scm (mutter)[disable-problematic-tests]: Also disable
> timeline tests.
> ---
>  gnu/packages/gnome.scm | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index e3fac534c4..b341fb4c97 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -7477,7 +7477,11 @@ (define-public mutter
>   ;; expression paragraph.  For an explanation, see: info '(sed)
>   ;; Multiline techniques'.
>   (invoke "sed" "/./{H;$!d} ; x ; s/^.*native-headless.*$//"
> - "-i" "src/tests/meson.build")))
> + "-i" "src/tests/meson.build")
> + ;; Timeline tests may unexpectedly fail on missed frames, so
> + ;; let's disable them as well.
> + (substitute* "src/tests/clutter/conform/meson.build"
> +   (("'timeline.*',") ""
>   (replace 'check
> (lambda* (#:key tests? test-options parallel-tests?
>   #:allow-other-keys)

You'd want to let upstream know about these flaky tests, and add the
reference to the upstream issue in a comment so we can track progress.

Otherwise, LGTM.

Thanks,

Maxim