guests/lcitool | 4 ++++ 1 file changed, 4 insertions(+)
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
© 2016 - 2024 Red Hat, Inc.