HG problem: abort: decoding near '9: error: ‘sse2::l': 'ascii' codec can't decode byte 0xe2 in position 213: ordinal not in range(128)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

HG problem: abort: decoding near '9: error: ‘sse2::l': 'ascii' codec can't decode byte 0xe2 in position 213: ordinal not in range(128)

ISHIKAWA,chiaki

Hi,

I am developing mozilla patches locally under my local PC running linux.

I often include the GCC's error/warning message in the mercurial
commit message (in the second and subsequent lines, the first line is
for usage by mozilla's bugzilla procedure.) when my local patch is
created to address build error or suppress compiler warning.

It worked just fine for months/years.

After an upgrade of local tools under Debian GNU/Linux last month or
so, I just noticed that such a patch with GCC warning line could not
be re-applied after it was qpopped. (I use mercurial mqueue
extension.)

This happened yesterday. This is the error message.

note: commit message saved in .hg/last-message.txt
transaction abort!
rollback completed
abort: decoding near '9: error: ‘sse2::l': 'ascii' codec can't decode byte 0xe2 in position 213: ordinal not in range(128)!

I was puzzled. After looking at the patch and the message above, I
finally figured out that that hg barfed on the proper quote character
just before "sse2::l" above. Can you spot the slightly tilted OPENING quote character?

So I removed the GCC warning line from the commit message and the
patch could be applied. This is problematic because I have about a few
dozen patches (actually more) and some patches could not be re-applied
due to the error above. I had to temporarily removed the offending
patch(es). Luckily the offending patches are relatively independent
and taken out for the moment.
But this could not be done if the patches are interdependent and
must be applied in a certain order.

Either
- GCC began producing such a non-ascii character lately (it is v7 on
my linux PC)
  [but I think I must have seen such characters long time before that],
- the "ascii" codec or whatever used by python has become very strict
  (But why ascii? Should we not use utf-8 after all?)
  [this could be an issue with setup of hg under my Debian GNU/Linux distribution?] , or
- something in my locale/character setting under Debian GNU/Linux
  broke lately due to the upgrade of local packages.

My point is that I have NOT changed in my personal setting at all (unless |./mach bootstrap| I occasionally run to make sure that I have the latest rust and other tools did something funny to my .hgrc).
Only the tools and system-wide setting could have changed mysteriously from my point of view.

I found a similar bug report in the following open source project:
https://github.com/schacon/hg-git/issues/27

I have not tried the HGENCODING=utf-8 fix mentioned in the above URL
for fear of breaking existing patches against my local copy of the
mozilla-central and comm-central source tree.

I wonder what would be the ultimate correct fix or
procedure to avoid/suppress this error.

I am posting this to warn developers who *MAY* see similar issues,
and to figure out where I should contact and report the issue:
- mercurial developers?
- python developers?
- who else?

I understand that mozilla is a big user of mercurial and so it should have
some clout to figure out the correct answer is quickly.  :-)

TIA

Happy Hacking in the good old sense of the phrase...

from a very perplexed linux user.


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds