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