Bug 646062 – www-client/firefox-58.0 - .../work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 548, in emit self.fh.write(msg) UnicodeEncodeError: 'ascii' codec can't encode characters in position 156-157: ordinal not in range(128)

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Erich Seifert 2018-01-29 18:06:29 UTC]

Created attachment 517076 [details]
www-client:firefox-58.0:20180129-130029.log

Emerging www-client/firefox-58.0 fails in src_compile() with a Python KeyError:

Error running mach:

    ['build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

KeyError: u'compile'

  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/mach_commands.py", line 170, in build
    mach_context=self._mach_context)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 1232, in build
    telemetry_data = monitor.get_resource_usage()
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 433, in get_resource_usage
    o['tiers'] = self.tiers.tiered_resource_usage()
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 150, in tiered_resource_usage
    self.add_resources_to_dict(t_entry, phase=tier)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 159, in add_resources_to_dict
    end=end, phase=phase, per_cpu=False)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 468, in aggregate_cpu_percent
    data = self.phase_usage(phase)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 427, in phase_usage
    time_start, time_end = self.phases[phase]

Additional information:

# emerge -pqv '=www-client/firefox-58.0::gentoo'
[ebuild     U ] www-client/firefox-58.0 [57.0.4] USE="dbus gmp-autoupdate pulseaudio screenshot startup-notification -bindist -custom-cflags -custom-optimization -debug -eme-free -hardened -hwaccel -jack (-neon) (-selinux) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi (-nsplugin%*) (-pgo%)" L10N="de -ach -af -an -ar -as -ast -az -bg -bn-BD -bn-IN -br -bs -ca -cak -cs -cy -da -dsb -el -en-GB -en-ZA -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mai -mk -ml -mr -ms -nb -nl -nn -or -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -uz -vi -xh -zh-CN -zh-TW" 

# emerge --info '=www-client/firefox-58.0::gentoo'
Portage 2.3.19 (python 2.7.14-final-0, default/linux/amd64/17.0/desktop/plasma/systemd, gcc-6.4.0, glibc-2.25-r9, 4.14.15-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.14.15-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_950_@_3.07GHz-with-gentoo-2.4.1
KiB Swap:    2047984 total,   2047984 free
Timestamp of repository gentoo: Mon, 29 Jan 2018 08:45:01 +0000
Head commit of repository gentoo: ca0e8fc2f5c57cbdf973e9641dc5a5eb8221769a
sh bash 4.4_p12
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
distcc 3.2rc1 x86_64-pc-linux-gnu [enabled]
ccache version 3.2.4 [disabled]
app-shells/bash:          4.4_p12::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.24.3::gentoo
dev-lang/python:          2.7.14-r1::gentoo, 3.4.5-r1::gentoo, 3.5.4-r1::gentoo, 3.6.4::gentoo
dev-util/ccache:          3.2.4::gentoo
dev-util/cmake:           3.10.2::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.4.1-r2::gentoo
sys-apps/sandbox:         2.12::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.11.6-r2::gentoo, 1.15.1-r1::gentoo
sys-devel/binutils:       2.29.1-r1::gentoo
sys-devel/gcc:            6.4.0-r1::gentoo
sys-devel/gcc-config:     1.8-r1::gentoo
sys-devel/libtool:        2.4.6-r4::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.14::gentoo (virtual/os-headers)
sys-libs/glibc:           2.25-r9::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts: 

x-portage
    location: /usr/local/portage
    masters: gentoo
    priority: 0

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nehalem -mtune=nehalem -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mpopcnt -msse4.1 -msse4.2 -mfxsr -fstack-protector-strong -O3 -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.3/conf"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=nehalem -mtune=nehalem -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mpopcnt -msse4.1 -msse4.2 -mfxsr -fstack-protector-strong -O3 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--quiet-build=y --jobs=8 --load-average=8"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs clean-logs config-protect-if-modified distcc distlocks ebuild-locks fail-clean fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="..."
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="de"
MAKEOPTS="-j89 -l8"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi activities aio alsa amd64 avahi berkdb branding bzip2 cairo cdda cdr cli crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam ffmpeg firefox flac fortran gallium gdbm gif glamor gphoto2 gpm gstreamer http2 iconv id3tag idn ipv6 jpeg kdbus kde kipi kwallet lastfm lcms ldap libnotify lm_sensors lzma mad matroska mng modules mp3 mp4 mpeg mtp multilib musicbrainz ncurses nls nptl nsplugin ogg opencl opengl openmp opus pam pango pcre pcsc-lite pdf phonon plasma png policykit ppds pulseaudio qml qt3support qt5 readline samba sdl seccomp semantic-desktop spell ssl startup-notification svg systemd tcpd theora threads tiff truetype udev udisks unicode upower usb v4l vaapi vdpau vorbis vpx vulkan widgets wxwidgets x264 x265 xattr xcb xcomposite xml xv xvid zeroconf zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="canon ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse wacom" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-0" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" RUBY_TARGETS="ruby22 ruby23" USERLAND="GNU" VIDEO_CARDS="radeon radeonsi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

[Comment 1 Jeroen Roovers (RETIRED) 2018-01-30 09:03:17 UTC]

Exception in thread ProcessReader:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/testing/mozbase/mozprocess/mozprocess/processhandler.py", line 986, in _read
    callback(line.rstrip())
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/testing/mozbase/mozprocess/mozprocess/processhandler.py", line 904, in __call__
    e(*args, **kwargs)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mach/mach/mixin/process.py", line 86, in handleLine
    line_handler(line)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 720, in on_line
    self.log(logging.INFO, 'build_output', {'line': line}, '{line}')
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mach/mach/mixin/logging.py", line 54, in log
    extra={'action': action, 'params': params})
  File "/usr/lib64/python2.7/logging/__init__.py", line 1231, in log
    self._log(level, msg, args, **kwargs)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1286, in _log
    self.handle(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1296, in handle
    self.callHandlers(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1336, in callHandlers
    hdlr.handle(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 759, in handle
    self.emit(record)
  File "/var/tmp/portage.notmpfs/portage/www-client/firefox-58.0/work/firefox-58.0/python/mozbuild/mozbuild/controller/building.py", line 548, in emit
    self.fh.write(msg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 156-157: ordinal not in range(128)

[Comment 2 Torsten Kurbad 2018-01-30 13:43:35 UTC]

Could this be connected to FEATURES="distcc"?

[Comment 3 Erich Seifert 2018-01-30 14:46:36 UTC]

(In reply to Torsten Kurbad from comment #2)
> Could this be connected to FEATURES="distcc"?

Yes, thanks for the hint. It seems to be the case. In the meantime an update to www-client/firefox-58.0.1 was released, but it showed the same problems. After emerging without distcc, fiefox was built and installed without issues.

[Comment 4 Torsten Kurbad 2018-01-31 07:11:45 UTC]

(In reply to Erich Seifert from comment #3)
> (In reply to Torsten Kurbad from comment #2)
> > Could this be connected to FEATURES="distcc"?
> 
> Yes, thanks for the hint. It seems to be the case. In the meantime an update
> to www-client/firefox-58.0.1 was released, but it showed the same problems.
> After emerging without distcc, fiefox was built and installed without issues.

FEATURES="-distcc" worked for me too when building www-client/firefox-58.0.1.

[Comment 5 Ian Stakenvicius (RETIRED) 2018-01-31 16:55:04 UTC]

If there was a PMS-legal way to disable or restrict distcc in mozilla packages I would do it.  I haven't had a reliable distcc-based build in many versions, and although they do often compile "fine" with local retries there are occasions that I've seen random runtime failures that don't occur with a local-only build.

I recommend not using FEATURES="distcc" for firefox, thunderbird, and seamonkey.  You can disable features on a per-package basis using /etc/portage/package.env (google for instructions on setting per-package environment variables)

[Comment 6 Sven B. 2018-02-06 19:26:11 UTC]

(In reply to Ian Stakenvicius from comment #5)
> If there was a PMS-legal way to disable or restrict distcc in mozilla
> packages I would do it.  I haven't had a reliable distcc-based build in many
> versions, and although they do often compile "fine" with local retries there
> are occasions that I've seen random runtime failures that don't occur with a
> local-only build.
> 
> I recommend not using FEATURES="distcc" for firefox, thunderbird, and
> seamonkey.  You can disable features on a per-package basis using
> /etc/portage/package.env (google for instructions on setting per-package
> environment variables)

perhaps:

if has "distcc" $FEATURES ; then
   # fatal
   die "..."
   # non-fatal
   ewarn "..."
fi 

 in pkg_pretend; but i am not sure whether the features variable actually contains that information within the scope of the ebuild.

[Comment 7 Ian Stakenvicius (RETIRED) 2018-02-09 17:10:53 UTC]

(In reply to Sven B. from comment #6)
> perhaps:
> 
> if has "distcc" $FEATURES ; then
>    # fatal
>    die "..."
>    # non-fatal
>    ewarn "..."
> fi 
> 
>  in pkg_pretend; but i am not sure whether the features variable actually
> contains that information within the scope of the ebuild.

Although last I checked it does when portage is the package manager, this is an undocumented feature that just happens to be true until now.  It's not PMS compliant and so it can't be used in the gentoo repo.

[Comment 8 Thomas Deutschmann (RETIRED) 2018-11-13 21:23:07 UTC]

*** Bug 670662 has been marked as a duplicate of this bug. ***

[Comment 9 Ben 2018-11-18 19:55:23 UTC]

A post on f.g.o made me wonder...

are the LANG_* variables exported to the helper hosts, such that when gcc returns error messages back to the machine requesting services, that their locale messages match...

Or should all helper machines always return the 'C' locale?

[Comment 10 Ben 2018-11-19 01:23:17 UTC]

Okay, I found on *systemd* distcc helper machines: Forcing LANG to be unset seems to make distcc work better for firefox, or at least let it match OpenRC distcc helpers as OpenRC helper boxes do not set LANG by default.

Workaround-hack-maybe should be permanent: In the supplied file:
/etc/systemd/system/distccd.service.d, add:

Environment="LANG=''"

to the [Service] section, then restart distccd:

# systemctl daemon-reload; systemctl restart distccd

Then see if distcc works better.  For me, this finally lets firefox build fine with the distcc feature enabled in firefox.

Chalk another issue to systemd issues^H^H^H^H^H^H^H differences (though perhaps this is distcc or firefox build oversight that distcc behaves differently depending on locale.)

[Comment 11 Ben 2018-11-19 01:50:10 UTC]

I take that back, I found one of my OpenRC boxes with LANG set, so this helper machine also sets LANG.  I forgot that I had tried distcc with this OpenRC box by itself and it likewise failed in the same manner.

The assumed workaround to fix this is to add 

LANG=""

at the end of /etc/conf.d/distccd , for at least this OpenRC box [untested as of yet, but verified the environment no longer sets it to en_US.utf8 where it had been before.]

[Comment 12 Thomas Deutschmann (RETIRED) 2018-11-19 02:08:33 UTC]

So we finally have confirmation that the famous 

> UnicodeEncodeError: 'ascii' codec can't encode characters in position 156-157: ordinal not in range(128)

bug (see bugs like 666948) is really caused by different LANG= settings across distcc build cluster? Thanks!

[Comment 13 Ben 2018-11-19 19:25:46 UTC]

Yeah I probably should have wrote this in the other bug report (I found this one first...) but likely they may be one and the same "bug".  Need others to verify this workaround is usable.

I just verified that clearing environment variable LANG for my other OpenRC distccd box allows firefox to build properly with FEATURES=distcc for a different machine.  Note that this problem will also manifest with distcc running in loopback mode (localhost) which really baffled me.

However perhaps the correct solution is for distcc to also pass LANG* env variables to the helpers?

Anyway, thanks to fedeliallalinea for suggesting the idea to find this workaround (as well as finding that Firefox forces LANG to C in its build scripts).

[Comment 14 Christophe PEREZ 2018-11-19 20:55:40 UTC]

(In reply to Ben from comment #11)
> The assumed workaround to fix this is to add 
> 
> LANG=""
> 
> at the end of /etc/conf.d/distccd

Sure that is sufficient ?
I use OpenRC.
I added 
LANG=""
at the end of all my /etc/conf.d/distccd
I restarted all my distccd
But I always have the error :
UnicodeEncodeError: 'ascii' codec can't encode characters in position 147-148: ordinal not in range(128)
I don't have error with FEATURES="-distcc"

[Comment 15 Ben 2018-11-20 07:03:49 UTC]

Not sure if I have anything else set, but I just had another successful run.  Perhaps it's www-client/firefox-60.3.0-r1, not sure if my observations apply to other versions.

Without distcc: (1.6GHz x86 single core laptop, no helpers)
firefox: Fri Nov  9 09:49:35 2018: 30686 seconds

With distcc: (1.6GHz x86 single core laptop with -j8 -l1.5 (due to past bad experiences) and two x86_64 quad core multilib helpers)
firefox: Mon Nov 19 21:09:07 2018: 9812 seconds

[Comment 16 Ian Stakenvicius (RETIRED) 2018-11-20 23:01:03 UTC]

(In reply to Ben from comment #15)
> Not sure if I have anything else set, but I just had another successful run.
> Perhaps it's www-client/firefox-60.3.0-r1, not sure if my observations apply
> to other versions.
> 
> Without distcc: (1.6GHz x86 single core laptop, no helpers)
> firefox: Fri Nov  9 09:49:35 2018: 30686 seconds
> 
> With distcc: (1.6GHz x86 single core laptop with -j8 -l1.5 (due to past bad
> experiences) and two x86_64 quad core multilib helpers)
> firefox: Mon Nov 19 21:09:07 2018: 9812 seconds

I've also had success with 60.2+ and 62+ on distcc, in my case I have a common /etc/locale.gen and the same 'eselect locale' across all systems.  I'm not sure how best to deal with this but it certainly does seem to be related to a mismatch in locales or perhaps a lack of support for the locale on the distcc host compared to the client.

[Comment 17 Ben 2018-11-21 17:49:13 UTC]

Which locale was used?

I have a feeling only the "C" locale will allow Firefox to compile, mainly because apparently the Firefox build routines hardcode to C.

I had another machine (LANG=en_US.utf8) successfully build Firefox with distcc with the helpers (LANG=C) workaround.

[Comment 18 Christophe PEREZ 2018-11-21 21:41:31 UTC]

On all I have :
# eselect locale list
Available targets for the LANG variable:
  [1]   C
  [2]   en_US
  [3]   en_US.iso88591
  [4]   en_US.utf8
  [5]   fr_FR
  [6]   fr_FR@euro
  [7]   fr_FR.iso88591
  [8]   fr_FR.iso885915@euro *
  [9]   fr_FR.utf8
  [10]  POSIX
  [ ]   (free form)

[Comment 19 Ben 2018-11-25 10:16:30 UTC]

Could check what locale distcc returns errors from some of your hosts?

Create a file foo.c that is "dirty" to test with, perhaps like this:

---cut---
int goobers(int bar) {
char *foo;
foo=&bar;
return (foo);
}
---cut---

Now, try to compile it:

$ DISTCC_HOSTS=helpermachine distcc gcc -Wall -c foo.c -o foo.o
foo.c: Dans la fonction ‘goobers’:
foo.c:3:4: attention : assignment from incompatible pointer type [-Wincompatible-pointer-types]
foo.c:4:8: attention : return makes integer from pointer without a cast [-Wint-conversion]

See what locale it prints the messages in.  I hacked my machine to force LANG=fr_FR.utf8 above.  As far as I know, this will fail firefox builds.

Incidentally, I found what is different in en_US.utf8 and C: (Look carefully)

< foo.c: In function ‘goobers’:
> foo.c: In function 'goobers':

This is sufficient to trip up Python if was scraping the output and expecting LANG=C as distcc does not pass LANG.

[Comment 20 Christophe PEREZ 2018-11-25 13:27:38 UTC]

(In reply to Ben from comment #19)
> Now, try to compile it:
> 
> $ DISTCC_HOSTS=helpermachine distcc gcc -Wall -c foo.c -o foo.o

In my case :
$ DISTCC_HOSTS=192.168.0.11 distcc gcc -Wall -c foo.c -o foo.o
foo.c: Dans la fonction « goobers »:
foo.c:3:4: warning: affectation depuis un type pointeur incompatible [-Wincompatible-pointer-types]
foo.c:4:8: warning: le retour transforme un pointeur en entier sans transtypage [-Wint-conversion]
$ DISTCC_HOSTS=serveur2 distcc gcc -Wall -c foo.c -o foo.o
foo.c: Dans la fonction « goobers »:
foo.c:3:4: warning: affectation depuis un type pointeur incompatible [-Wincompatible-pointer-types]
foo.c:4:8: warning: le retour transforme un pointeur en entier sans transtypage [-Wint-conversion]

But I don't understand what that means.

[Comment 21 Ben 2018-11-25 16:42:10 UTC]

This means that your machines are still returning something other than LANG=C which means the hack presented didn't work for you... (i.e., /etc/conf.d/distccd didn't get applied to the running instance of distccd.)

[Comment 22 Christophe PEREZ 2018-11-25 19:30:02 UTC]

ok, understood. Thanks

[Comment 23 Ben 2018-11-26 17:09:27 UTC]

Were you able to get distccd to return results in locale 'C' (you should see it returning English results and use the straight single quote marks that match the single quote mark generated by your keyboard) -- and then see if firefox will build with those distccd machines?

[Comment 24 Christophe PEREZ 2018-11-26 17:14:43 UTC]

(In reply to Ben from comment #23)
> Were you able to get distccd to return results in locale 'C' (you should see
> it returning English results and use the straight single quote marks that
> match the single quote mark generated by your keyboard) -- and then see if
> firefox will build with those distccd machines?

No, sorry.

/etc/conf.d/distccd is read. Allow, listen logfile, loglevel directives are well used.
But LANG=C or LANG="C" or LANG="", doesn't do anything.

I don't really know what to try.

[Comment 25 Ian Stakenvicius (RETIRED) 2018-11-26 17:43:29 UTC]

(In reply to Christophe PEREZ from comment #24)
> (In reply to Ben from comment #23)
> > Were you able to get distccd to return results in locale 'C' (you should see
> > it returning English results and use the straight single quote marks that
> > match the single quote mark generated by your keyboard) -- and then see if
> > firefox will build with those distccd machines?
> 
> No, sorry.
> 
> /etc/conf.d/distccd is read. Allow, listen logfile, loglevel directives are
> well used.
> But LANG=C or LANG="C" or LANG="", doesn't do anything.
> 
> I don't really know what to try.

This is a bit more invasive, but try to edit /etc/init.d/distccd and add 'unset LANG' in start() above the start-stop-daemon call, then restart distccd?

[Comment 26 Christophe PEREZ 2018-11-26 17:49:07 UTC]

(In reply to Ian Stakenvicius from comment #25)
> This is a bit more invasive, but try to edit /etc/init.d/distccd and add
> 'unset LANG' in start() above the start-stop-daemon call, then restart
> distccd?

root@serveur2 ~ # grep -B1 "start-stop-daemon --start" /etc/init.d/distccd 
unset LANG
        start-stop-daemon --start --quiet --exec "${DISTCCD_EXEC}" --user distcc -- \
root@serveur2 ~ # rc-service distccd restart
 * Stopping distccd ...                                                                      [ ok ]
 * Starting distccd ...                                                                      [ ok ]

chris@medion ~/tmp $ DISTCC_HOSTS=serveur2 distcc gcc -Wall -c foo.c -o foo.o
foo.c: Dans la fonction « goobers »:
foo.c:3:4: warning: affectation depuis un type pointeur incompatible [-Wincompatible-pointer-types]
foo.c:4:8: warning: le retour transforme un pointeur en entier sans transtypage [-Wint-conversion]

Nothing changed :(

[Comment 27 Ben 2018-11-27 19:56:37 UTC]

What if you explicitly set LANG=C instead of unsetting?  I'm not sure how these localizations work, haven't really looked into it mainly because usually the C locale is the same as en_US without the annoying high bit characters ...

Also try setting LC_ALL=C as well?

[Comment 28 Christophe PEREZ 2018-11-27 23:31:06 UTC]

(In reply to Ben from comment #27)
> What if you explicitly set LANG=C instead of unsetting?

Not better

> Also try setting LC_ALL=C as well?

I should try it before. I have english message, even with LC_ALL=C in /etc/conf.d/distccd :
$ DISTCC_HOSTS=serveur2 distcc gcc -Wall -c foo.c -o foo.o
foo.c: In function 'goobers':
foo.c:3:4: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
foo.c:4:8: warning: return makes integer from pointer without a cast [-Wint-conversion]

But, same error compiling firefox with distcc.

[Comment 29 Jory A. Pratt 2019-03-31 20:06:16 UTC]

Please feel free to reopen and update any bug report that can be duplicated with current esr builds, 60.x. If you feel your feature needs to be re looked at in any of these bugs reopen and update, please attach patches when appropriate. Thank you Mozilla Team

[Comment 30 Christophe PEREZ 2019-05-31 19:51:20 UTC]

I always have the same problem, with all my PC (3), with all firefox version (actually www-client/firefox-60.7.0).
I have to compile without distcc each time.