Hi,
On Thu, 09 Jun 2022 at 08:38:40 +0200, Marc Haber wrote:
> On Thu, Jun 09, 2022 at 02:28:48PM +0800, Paul Wise wrote:
>> On Thu, 2022-06-09 at 07:28 +0200, Marc Haber wrote:
>>> I am working on a package written in python that thankfully has a
>>> test suite. Unfortunately, one of the tests fails if the en_GB.UTF-8
>>> locale is not present.
>>
>> Any idea why the test requires that locale? Tried C.UTF-8?
>
> I havent looked at the test in detail, I have not yet decided whether
> the package would be helpful in Debian. It looks like the test has
> en_GB.UTF-8 hardcoded, sets the locale to that value and then fails
> it it's not there. Most likely it's the home locale of the dev.
>
>>> How do I solve this? Do I need to build-depend on the locales-all
>>> package or is there a less ugly way?
>>
>> I think that using locales-all is currently the only way to ensure that
>> a specific locale other than C/C.UTF-8 is installed.
>
> And build-depending on that is not bad in some way?
If a single locale is needed then an alternative is to ‘Build-Depends:
locales’ — which is much smaller than locales-all — and generate the
desired locale at build time (and/or via autopkgtests):
debian/control:
Build-Depends: […], locales <!nocheck>
debian/rules:
override_dh_auto_test:
[ -d tests/.locale ] || mkdir tests/.locale
localedef -c -i en_GB -f UTF-8 tests/.locale/en_GB.utf8
env LOCPATH=$(CURDIR)/tests/.locale test_command
debian/clean:
tests/.locale/
At least this is what I've done in a similar situation. I don't know
if that's better or worse than Build-Depends: locales-all :-)
Cheers
--
Guilhem.
Attachment:
signature.asc
Description: PGP signature