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

[Grigory Shepelev <shegeley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

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 <shegeley@gmail.com>:

> 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 <ludo@gnu.org>:
>
>> Hi,
>>
>> Grigory Shepelev <shegeley@gmail.com> 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/nonguix        39e4b41
>> > 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 <maximedevos@telenet.be> skribis:
>>
>> > Seems like an instance of <https://issues.guix.gnu.org/52559#15>.
>> > 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
>> 040000 tree 8070c9587f76797cf16800522688ded39c956d00    gnu/packages
>> $ git ls-tree 8070c9587f76797cf16800522688ded39c956d00 |grep virtuali
>> 100644 blob 20ffb4a481239349078e2a2864d1bd873dfcd143    virtualization.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’.
>>
>

[-- Attachment #2: Type: text/html, Size: 5307 bytes --]