• tests failing without specific locales

    From Marc Haber@21:1/5 to All on Thu Jun 9 07:30:01 2022
    Hi,

    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.

    How do I solve this? Do I need to build-depend on the locales-all
    package or is there a less ugly way?

    Greetings
    Marc

    -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Paul Wise on Thu Jun 9 08:40:01 2022
    Hi Paul,

    thanks for your quick answer.

    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?

    Greetings
    Marc

    -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Marc Haber on Thu Jun 9 08:30:01 2022
    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?

    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.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmKhkx0ACgkQMRa6Xp/6 aaPBbRAAqpCrdeVoCGyJ7E9ao6vj+c7TikgSlxaZBIVNv5xl67LB3FRpiq0358gn LpgxjclIJrdODNjUUcOShpMWVXJN1YH96FiVz48Gujm0yJvjfKsh6rN4Eik4BxTA gW1nwnPMYN65k8VD0ojkysMN9qDG+AhGiPAtLJ8NbGMp+ScKMm7GSGCS+X7rZTsf xNR972sY6oyBL53Cnpi8t1hcNEfOGRXvls+ZmdNxmfYz4AKItzLy2mmFggq+dBz5 v5JM41KAEy/FRTFMuRs9YW2Yt02yTxw7pX1vt7vyuHV9cyyG6mBw5MOrCY5oAoN9 cigUXdgH6Fhe1Kqf8rMYJm18R71fJcydsg+7mdlQO/Y8iNOQyuOdoWpenjajjrho hwWV/qufEixgYOyenZiFof3AupbhoktP/Y/1xKfsHNSHX8mMRzMgm1mJUe4lhFyN D/CHOb+k+Nqj46ipPmk3TLI/ufcdD1H7MH/OBQS/DZOlN59zGe5aDJXnP2OWXmTT dgoVNIK8wqeMD8d3kyjMJu7QtmEFISY+kNBbpOfnyZuaSc0CdPHbcdk3b+6Kxv93 RbNzceTuMFAT7UhaGklL1TX2PMdDtaSS7jolBDY8qRCN+SFchCr9rpatc0iA7jTX U9UneA+l2Aej9MPBEVS+53pa1WM4ks4sFi+NFQ6j0UhP1yQ4ijQ=
    =8s28
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Marc Haber on Thu Jun 9 10:40:02 2022
    On Thu, 2022-06-09 at 08:38 +0200, Marc Haber wrote:

    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.

    It sounds like you could simply patch it to use C.UTF-8 instead?

    Or send upstream a patch to take the locale from the environment
    variables. Of course then tests might fail if someone uses a weird
    locale and the test results depend on the locale, but then you could
    set the locale to C.UTF-8 in debian/rules. Or perhaps debhelper should
    be doing that in the next compat level.

    And build-depending on that is not bad in some way?

    I can't think of a reason it would be problematic.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmKhsVIACgkQMRa6Xp/6 aaNHrg//XVTrHu69roQA20UUqGcBmf+aqNulaiveGQEGmnhqqF6I9WtoxsTqtPQJ SUivJbqp0oQzHKlSNTE/Tz0QwylTt2u365cSgXULCyLT+BR0MZ4L/9Hu13tM0p/z 2TXzSSWURLPr1C7IqQBfzAdAZaeuxb6kt2irRoWD9R1bfCltyrtlweXeY+wzWhM0 5cPJPC/wVRpA8tUK/L6qDPzXq8eYSlLdSxjkW63ma/Pe56dvIPIMNgRgw+QWysta jQY6K1BOPeoJzW74h1GyX8Hk+XPdKt5jnC9TPILajxH3BHN8F+KmcmBcSQ674fl6 UOYcW840+jIrqghsuPznp8WkwnSmKYL2ZKhpXlMdknxhkSXXcLge9gvUu8/wF98M llrgEnl+9oXRgwXSOjH3RHAK66Gfs8ZM6OxWkjMlkVO5HAEPVHzXRMA/N3VafN60 ccwbzDafGw78lm8wEWbQhUXPH0p503DR7IuGTADANDrRE9N4flWsQJIYmrTsRs4l DRYZqZuXGkyWYDUZKvmNC1f6CS5Npalsv195eH5XwMPJvITQz+J7VGy7Znx4RsOw +4uudNCbVxTQXjhsLE2N448AyCNzcsoYpLoVdBULApB4sWS0CTug5CJLW9Zo5bM+ Dal+TbAL8qhVoF0l+m3CCVAs4fmXaUDvWJZZY6NT6CLF+1w9SCg=
    =kwbg
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mattia Rizzolo@21:1/5 to Paul Wise on Thu Jun 9 11:00:01 2022
    On Thu, Jun 09, 2022 at 04:37:45PM +0800, Paul Wise wrote:
    On Thu, 2022-06-09 at 08:38 +0200, Marc Haber wrote:
    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.

    It sounds like you could simply patch it to use C.UTF-8 instead?

    Or send upstream a patch to take the locale from the environment
    variables. Of course then tests might fail if someone uses a weird
    locale and the test results depend on the locale

    At which point you have most likely uncovered a bug! (unless you are
    running something that by definition is supposed to be
    locale-dependant).

    --
    regards,
    Mattia Rizzolo

    GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
    More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
    Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmKhtYMACgkQCBa54Yx2 K62uqBAAvQBU+PmkTxwTWA06YlJnbLr035msLpDDP95tfO7Dmd8CBE+CS1ZeRqQQ CUeroHj9+ClJFRzdPCfx0HLRfpYrdHbZwC/2+o881XeWJxKdgs+9tIxfad1bNCji 3N67ElXqEG6xPA2GtMaU1RDUcZgBymZAStHLkuuSX6ET2SedBSRfAKAOSB9KfJMs A+SgFnyYK59bhvt6ERgd5+sJ/2TdvhlZPFrLBrp8FlWhapEbSqgJAy4QSMj6UYLz ZA+4XHqviDiRQsplhIw+EBG8WJ/8Yf7qFsxKngFjN6Npjt2Wu2C1OFXEFccxETEb HeSYFHJMB4fFxWu+lZXacgErhw2OgT1KSu5OwRODp4cmRZbx+Xdvmv1xsx6q7O36 RtwKLoFpGOPzIIH8wD188PbOmxuraUUVC4yi+NAinfGke2wdfFogm+pC20Xh6fpg BC6XMpQllf+6VUCL5rZqksz2JEVfNygwiDExjLOm3gLvouwWp9l4hjM4oz54YSE4 xaGoTpIDSu0GQwMW96bicUJLjXN0/OVXWif6UaSjR/EHHdgz/Wl
  • From Marc Haber@21:1/5 to Mattia Rizzolo on Thu Jun 9 12:20:01 2022
    On Thu, Jun 09, 2022 at 10:55:34AM +0200, Mattia Rizzolo wrote:
    On Thu, Jun 09, 2022 at 04:37:45PM +0800, Paul Wise wrote:
    Or send upstream a patch to take the locale from the environment
    variables. Of course then tests might fail if someone uses a weird
    locale and the test results depend on the locale

    At which point you have most likely uncovered a bug! (unless you are
    running something that by definition is supposed to be
    locale-dependant).

    I think the test in question ("check locale-aware sorting") is
    deliberately locale-dependent. I have opened am upstream issue and hope
    that Upstream will comment. The package itself is not yet on salsa and
    not yet in Debian, not even an ITP filed.

    Greetings
    Marc

    -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guilhem Moulin@21:1/5 to Marc Haber on Thu Jun 9 13:00:01 2022
    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.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmKhzrsACgkQ05pJnDwh pVJyjxAAn/NbXY6w0w63xOcVo3LLITTn0Eblsjc8jAh5l1vF0n/wGxwJCDe8fiuH GJD0laTSX7OD1IhCD3SruRGnsv4gYNxOL4VIcjXVg+beC2W56BvYEUkppvD3djHi 9YUbpeRRJgOarmL2R69ALfmACUozS+Z1svfBm+0mg+rISiE+Ap4stvFdvn/doL+p Mt83Udc0cMMlsWCt6uff2Fep7y8U9MwfQeKOVLUkfpve+B+Ga1CL8IMFobyi/CJG IFn9E9eGyMvQA/cjeTxKNGovBfkzy2LDD0PugItRrxtDc8sfK8nhtzSB7JP/n899 hY14pkY46ymu1EsQy3dSHy1LoJ4+1sPkHBYVj+UvQezcP+0GFx2hqKWLHAwipo+v etlxr+ZLpek3PX4QYlj3FlTE5x3Fv9HFmc7aGXl0LPU3i/7esIzZTbz67N27aGsT 88p5Gk+yhvpltJNuSK3VvKZ999SjwdaF85PLvOMhvsyCVOdYfG2ZY/ezXbyZGCT0 nRKi751c8tazT9NJbe1NrOesYEUa5UcQNUQ3FhwIT3dfQlEyzYP0XxTj53KeiHy8 1LE/+lQdwYt0YcTd0ydlZN0BCbHs5IeIa0/DSC2UbYJEWz3CKn20Xi7qB6//S9jp d/q22z+yH4iMGXxBN20zRWmuWg2933QoOlPHmk5vK/dKQ/fsBAE=
    =coOb
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)