- Oct 23, 2019
-
-
Ian Moody authored
5.2 is the first release of Mercurial where py3 support is expected to be widely used, therefore we should allow installing it without hoop-jumping. Differential Revision: https://phab.mercurial-scm.org/D7151
-
- Oct 29, 2019
-
-
Pierre-Yves David authored
Now that the official black has all we want, we can drop this.
-
Pierre-Yves David authored
-
Pierre-Yves David authored
The latest version of black is out and contains the change we needed. So we can start using it now. note: `test-check-format.t` will complains about this changes because it still use `grey` and need to be migrated to `black`. See next changesets for this.
-
- Oct 27, 2019
-
-
kiilerix authored
-
kiilerix authored
Packaging usually works on other versions too, and it is not efficient to maintain the list in repo. It is already out of sync with the Makefile targets.
-
kiilerix authored
-
kiilerix authored
Just overrule the HGPYTHON3 warning.
-
kiilerix authored
Fedora 31 has Python3 at /usr/bin/python ... but expect everybody to not just find python in $PATH but be explicit about whether they want python2 or python3. mercurial.spec just used 'python' and would fail when it unknowingly used Python 3 and ended up with Mercurial setup.py reporting "Python 3.7 detected." and talking about the HGPYTHON3 environment variable. For now, just be explicit about using system python2 as python executable when building rpms.
-
kiilerix authored
Fedora 31 has Python3 at /usr/bin/python, and buildrpm would fail on snippets that use python2 syntax. Instead of forcing python2, just accept for the future while staying backwards compatible.
-
- Oct 30, 2019
-
-
Yuya Nishihara authored
Since mail.headencode() is disabled by -n/--test, non-ASCII header value has to be allowed. Spotted by Denis Laxalde.
-
- Oct 25, 2019
-
-
Denis Laxalde authored
This fails on Python 3 but gets fixed in the next changeset.
-
- Oct 27, 2019
-
-
Yuya Nishihara authored
For historical reasons, None in mapping dict means there's no such keyword, and falls back to b"". That's fine in log templates where mapping item is generally a callable returning a value (which may be None,) but the formatter directly puts an "evaluated" value in the mapping. So the None value has to be lifted to wrappedvalue(None) to avoid confusion in the template engine.
-
Yuya Nishihara authored
-
Yuya Nishihara authored
Maybe it isn't great to ignore unsupported types at all, but otherwise "hg config -Tjson" would crash.
-
Denis Laxalde authored
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 authored
-
- Oct 25, 2019
-
-
Denis Laxalde authored
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.
-
- Oct 24, 2019
-
-
Denis Laxalde authored
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 authored
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 authored
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 authored
-
Denis Laxalde authored
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 authored
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 authored
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 authored
We already catch this exception in _encode() (called by headencode()). It gets raised when running test-notify.t with Python 3.
-
Denis Laxalde authored
Long headers appears to be wrapped with new lines. In test-notify.t, we have a "filter.py" that replaces "\n" by " ", so we get an extra space in a Message-Id with a long value.
-
- Oct 10, 2019
-
-
Denis Laxalde authored
In Python 3, as_bytes() corresponds to as_string() in Python 2.
-
- Oct 23, 2019
-
-
Ian Moody authored
The latter wasn't noticed before since no tests exercise --confirm at all, let alone on an existing DREV. The former is only hit during an intermittent network issue during amending at the end of a phabsend, so doesn't seem testable. Differential Revision: https://phab.mercurial-scm.org/D7153
-
Denis Laxalde authored
We merge the mercurial and mercurial-common binary packages into a single mercurial package. This is essentially to ease installation (and upgrade) using a simple "dpkg -i" command. This also simplifies debian/rules by removing arch (in)dependent cleanups during installation. We have the mercurial binary Breaks: and Replaces: mercurial-common so that the latter will be removed upon upgrade. Also note the change from "override_dh_install" to "override_dh_auto_install" in debian/rules: this is because we do not want "make install" to be run automatically as we need the --install-layout=deb of "setup.py install" (otherwise, files would end up in $DESTDIR/usr/local).
-
Denis Laxalde authored
We change the "override_dh_install" target to "override_dh_auto_install" in debian/rules (see dh_auto_install(1) for details). This is because we do not want "make install" to be run automatically as we need the --install-layout=deb of "setup.py install". Otherwise, files end up in $DESTDIR/usr/local. At the moment, this is not a problem since files installed in debian/tmp (the default location) are not packed into binary packages (because there are debian/mercurial and debian/mercurial-common directories). This is cleaner to avoid running make more than needed.
-
Denis Laxalde authored
-
Denis Laxalde authored
-
- Oct 22, 2019
-
-
Gregory Szorc authored
We like to use the latest versions of things. I added pywin32-ctypes to the explicit list of packages so running on !Windows will pull in the dependency.
-
Gregory Szorc authored
These were all recently released and we should use them in automation.
-
Gregory Szorc authored
These are the latest Python versions and we should use them.
-
- Oct 21, 2019
-
-
Denis Laxalde authored
"hg" script is already correct because it is handled by setup.py but "hg-ssh" will be rewritten by dh_python into "/usr/bin/python" which is not wanted as we target Python 3. By passing --shebang=/usr/bin/python3 to dh_python3, we force shebangs to be set with this value.
-
Denis Laxalde authored
In builddeb script, the path where .deb files are looked for should simply be $OUTPUTDIR since the previous instruction moves those files there. This fixes "make deb".
-
Denis Laxalde authored
This fixes the following Lintian error: E: mercurial-common: missing-depends-on-sensible-utils etc/mercurial/hgrc.d/default-tools.rc
-
Denis Laxalde authored
Also drop the explicit "Depends: python" as debhelper will add it.
-