gcc/DATESTAMP not updated any longer

Jakub Jelinek jakub@redhat.com
Fri Nov 13 09:57:43 GMT 2020


On Tue, Nov 10, 2020 at 09:23:09AM +0100, Martin Liška wrote:
> On 11/9/20 11:09 PM, Jakub Jelinek wrote:
> > So I think either new_update must be raising an exception, or returning
> > None for some reason.
> > Bet we want to add logging for that exception, as well as for it returning
> > None and inside of it perhaps even more detailed logging on where it
> > returned None.
> 
> The following should expand both a returned None or an exception.
> Jakub, please install it.

Just FYI, we have finally the culprit today:
'ascii' codec can't decode byte 0xe2 in position 4882: ordinal not in range(128)
Traceback (most recent call last):
  File "hooks/post_receive.py", line 87, in post_receive
  File "/sourceware1/projects/src-home/git-hooks/hooks/daemon.py", line 82, in run_in_daemon
    fun()
  File "/sourceware1/projects/src-home/git-hooks/hooks/updates/emails.py", line 107, in flush
    email.send()
  File "/sourceware1/projects/src-home/git-hooks/hooks/updates/emails.py", line 233, in send
    e_msg_body = self.__email_body_with_diff
  File "/sourceware1/projects/src-home/git-hooks/hooks/updates/emails.py", line 310, in __email_body_with_diff
    email_body += diff
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 4882: ordinal not in range(128)

and at least in a couple of past missed mails it is the git diff containing
non-ascii characters (usually valid utf-8, but I think we even shouldn't
throw away mails that contain something not valid utf-8).

	Jakub



More information about the Gcc mailing list