Yuya Nishihara <yuya@tcha.org> [Sun, 27 Oct 2019 12:30:59 +0900] rev 43335
config: fix -Tjson to not crash due to unsupported defaultvalue types
Maybe it isn't great to ignore unsupported types at all, but otherwise
"hg config -Tjson" would crash.
Denis Laxalde <denis@laxalde.org> [Sun, 27 Oct 2019 18:12:24 +0100] rev 43334
tests: handle Message-Id email header possible wrapping
The "Message-Id" header will get wrapped with a new line when exceeding
75 characters on Python 3 (see changeset
7d4f2e4899c5 introducing usage
of email.header.Header.encode and respective doc). This will occur in an
unpredictable manner depending on the hostname's length. To make the
test output consistent across Python versions and hostname
configuration, we add a filter to unwrap this header value.
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Oct 2019 12:51:53 +0900] rev 43333
py3: leverage pycompat.long
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 25 Oct 2019 14:02:40 +0200] rev 43332
packaging: remove version info from Breaks+Replaces in Debian package
The versioned Breaks: and Replaces: cause problem when trying to install
our package over the one in Debian.
$ sudo apt install ./packages/debian-buster/mercurial_5.2~rc0+15-buster-
a2ff3aff81d2_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'mercurial' instead of './packages/debian-buster/mercurial_5.2~rc0+15-buster-
a2ff3aff81d2_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
mercurial : Breaks: mercurial-common (< 5.2~rc0+15-buster-
a2ff3aff81d2) but 5.2~rc0-1 is to be installed
E: Unable to correct problems, you have held broken packages.
Removing version information resolves the situation.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 17:28:57 +0200] rev 43331
py3: fix generated non-ascii message in test-notify.t
The resulting "Subject:" header contains an encoded word in Python 3 so
we have to add distinct outputs for Python 3 but underlying values are
the same:
>>> from email.header import decode_header
>>> decode_header('=?utf-8?b?w6AuLi4=?=')
[(b'\xc3\xa0...', 'utf-8')]
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 14:28:20 +0200] rev 43330
py3: decode encoding literal before passing to .decode()
bytes.decode(<encoding>) wants an str as "encoding" parameter,
it raises a TypeError if given a bytestring. encoding.encoding and
encoding.fallbackencoding are bytes values.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 16:34:43 +0200] rev 43329
py3: decode payload of notify email
This fixes one UnicodeEncodeError in test-notify.t:422 when testing the
notify hook with non-ascii content (there are more later). We only
decode on Python 3, since it's not safe for sure on Python 2.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 15:50:15 +0200] rev 43328
py3: decode email headers with mail.headdecode() in notify extension
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 15:46:16 +0200] rev 43327
py3: use stdlib's parseaddr() to get sender header in notify extension
In Python 3, email headers are unicode string so using
stringutil.email() will not work as it compares with bytestring. So
let's use email.utils.parseaddr() from the stdlib which has a consistent
behavior across Python versions. The same is done in patchbomb
extension already.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 15:28:00 +0200] rev 43326
py3: use a BytesParser in notify extension
This is the first step to make the "long line" case in test-notify.t
pass by fixing a UnicodeDecodeError on Python 3.
We alias a parsebytes() in mail module, similarly as we already have a
parse() function for Python 2 and Python 3 compatibility.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 17:16:43 +0200] rev 43325
py3: fix headencode() with display=False
We previously called str() on a email.header.Header object. On Python 2,
this returns a bytestring and the __str__ method is actually an alias to
.encode() method. On Python 3, __str__ does not perform encoding (and
returns a unicode string). To keep a consistent behavior across Python
versions, we explicitly use .encode() and we wrap the result with
encoding.strtolocal() to get a bytestring in all cases. As a side effect
of forcing bytes conversion, we need to decode back in _addressencode().
This is to make test-notify.t pass on Python 3.
Also note that headers are now encoded in some patchbomb tests; this is
because the charset is not always "us-ascii" ("iso-8859-1" otherwise) on
Python 3.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 24 Oct 2019 14:31:24 +0200] rev 43324
mail: catch LookupError in headdecode()
We already catch this exception in _encode() (called by headencode()).
It gets raised when running test-notify.t with Python 3.