From: Vagrant Cascadian <vagrant@reproducible-builds.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 46038@debbugs.gnu.org
Subject: bug#46038: guix 1.3.0rc1 test failure: channels-news, one entry
Date: Tue, 04 May 2021 15:34:44 -0700 [thread overview]
Message-ID: <871ramt9ff.fsf@yucca> (raw)
In-Reply-To: <875yzymg1h.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]
On 2021-05-04, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@reproducible-builds.org> skribis:
>
>> On 2021-01-22, Vagrant Cascadian wrote:
>>> I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it
>>> builds fine on the official buildd.debian.org infrastructure, on amd64
>>> and arm64 the "channel-news, one entry" test from tests/channels.scm
>>> fails on tests.reproducible-builds.org.
>>>
>>> There are likely a few differences in the two build environments,
>>> possibly including network access.
>>>
>>> Does the "channel-news, one entry" test indirectly depend on network or
>>> bootstrap binaries?
>>>
>>> Could a difference in locale related variables affect the result of the
>>> test (e.g. LANGUAGE=en:en_US vs. LANGUAGE unset, LC_ALL unset
>>> vs. LC_ALL=C or LC_ALL=C.UTF-8)?
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/guix.html
>>
>> Still basically the same story with 1.3.0rc1, in some cases this test
>> fails, but I haven't consistently figured out what triggers it.
>>
>>
>>> test-name: channel-news, one entry
>>> location: /build/1st/guix-1.2.0/tests/channels.scm:324
>>> source:
>
> [...]
>
>>> + (lset= equal?
>>> + (map channel-news-entry-title
>>> + (channel-news-for-commit channel commit5))
>>> + '((("en" . "Another file!"))
>>> + (("en" . "Old news.") ("eo" . "Malnova?oj."))))
>
> The culprit is right here: it should read “Malnovaĵoj”, but there’s a
> question mark instead of ‘ĵ’.
>
> Could it be that you’re not running tests in a UTF-8 locale?
Thanks for taking a deeper look!
Yes, on tests.reproducible-builds.org, one build is run in the C locale,
the other in various UTF-8 locales (somewhat arbitrarily tied to
architecture exactly which UTF-8 locale is used). I'm guessing
buildd.debian.org use C.UTF-8, since it builds fine there.
So now the question is what to do; should tests be able to assume a
UTF-8 locale?
Should I try to adapt the test to work in C?
Should I workaround it in the Debian packaging by forcing to use a UTF-8
locale (on Debian, the only one definitely available is C.UTF-8, which
isn't in upstream glibc, and thus not in guix itself).
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2021-05-04 22:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87lfck6hbl.fsf@yucca>
2021-05-02 2:23 ` bug#46038: guix 1.3.0rc1 test failure: channels-news, one entry Vagrant Cascadian
2021-05-04 19:53 ` Ludovic Courtès
2021-05-04 22:34 ` Vagrant Cascadian [this message]
2021-05-06 10:46 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871ramt9ff.fsf@yucca \
--to=vagrant@reproducible-builds.org \
--cc=46038@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.