As we cannot and should not rely on how the containers were generated,
let's force the container LANG to be en_US.UTF-8 otherwise some
containers (Debian 9, Ubuntu 16, and Ubuntu 18) would simply bail when
dealing with environment variables inherited from Gitlab CI which
contains non-POSIX characteres, such as "Fidêncio".

Unfortunately, there's no standard way to do this accross different
distros, leaving us with this "happy little accident" of setting up LANG
in the way it's done right now.

Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
---
 guests/lcitool | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/guests/lcitool b/guests/lcitool
index 49bb50b..a630971 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -735,6 +735,10 @@ class Application:
                 RUN pip3 install {pip_pkgs}
             """).format(**varmap))
 
+        sys.stdout.write(textwrap.dedent("""
+            ENV LANG "en_US.UTF-8"
+        """).format(**varmap))
+
         if args.cross_arch:
             sys.stdout.write(textwrap.dedent("""
                 ENV ABI "{cross_abi}"
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, 2019-10-10 at 17:13 +0200, Fabiano Fidêncio wrote:
> As we cannot and should not rely on how the containers were generated,
> let's force the container LANG to be en_US.UTF-8 otherwise some
> containers (Debian 9, Ubuntu 16, and Ubuntu 18) would simply bail when
> dealing with environment variables inherited from Gitlab CI which
> contains non-POSIX characteres, such as "Fidêncio".
> 
> Unfortunately, there's no standard way to do this accross different
> distros, leaving us with this "happy little accident" of setting up LANG
> in the way it's done right now.
> 
> Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
> ---
>  guests/lcitool | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/guests/lcitool b/guests/lcitool
> index 49bb50b..a630971 100755
> --- a/guests/lcitool
> +++ b/guests/lcitool
> @@ -735,6 +735,10 @@ class Application:
>                  RUN pip3 install {pip_pkgs}
>              """).format(**varmap))
>  
> +        sys.stdout.write(textwrap.dedent("""
> +            ENV LANG "en_US.UTF-8"
> +        """).format(**varmap))

The approach we ultimately want to take is probably to store this
variable, along with others like $NINJA, in the global shell
profile / initialization scripts, both for containers and for
virtual machines.

But it's a lot of work to get there and this solution, although
somewhat gross, fixes the build failures you're seeing in GitLab CI,
so it gets a reluctant

  Reviewed-by: Andrea Bolognani <abologna@redhat.com>

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Oct 10, 2019 at 06:15:35PM +0200, Andrea Bolognani wrote:
>On Thu, 2019-10-10 at 17:13 +0200, Fabiano Fidêncio wrote:
>> As we cannot and should not rely on how the containers were generated,
>> let's force the container LANG to be en_US.UTF-8 otherwise some
>> containers (Debian 9, Ubuntu 16, and Ubuntu 18) would simply bail when
>> dealing with environment variables inherited from Gitlab CI which
>> contains non-POSIX characteres, such as "Fidêncio".
>>
>> Unfortunately, there's no standard way to do this accross different

s/accross/across/ if you haven't pushed it yet ;)
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Oct 11, 2019 at 09:50:18AM +0200, Martin Kletzander wrote:
>On Thu, Oct 10, 2019 at 06:15:35PM +0200, Andrea Bolognani wrote:
>>On Thu, 2019-10-10 at 17:13 +0200, Fabiano Fidêncio wrote:
>>> As we cannot and should not rely on how the containers were generated,
>>> let's force the container LANG to be en_US.UTF-8 otherwise some
>>> containers (Debian 9, Ubuntu 16, and Ubuntu 18) would simply bail when
>>> dealing with environment variables inherited from Gitlab CI which
>>> contains non-POSIX characteres, such as "Fidêncio".
>>>
>>> Unfortunately, there's no standard way to do this accross different
>
>s/accross/across/ if you haven't pushed it yet ;)

Of course I'm way too late.  Just disregard this and the previous message from me...
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list