packaging: make dockerrpm fedora target more generic Fedora moves fast in version numbers, and often with Mercurial packaging being backwards compatible. Thus, only aim for providing built-in support for latest Fedora version, and make it easy to update. With this refactoring, 'dockerrpm fedora31' also works. 'dockerrpm fedora' will use the 'fedora:latest' Docker image.

packaging: use "python3" for fedora29 ... and as buildrpm default Change the buidrpm default. The CentOS targets explicitly use "python", and changing the default will only influence Fedora 29. A Python 3 package needs python3 dependencies, so pythonexe (and pythonver) is used for specifying dependencies. Other OS versions will keep using "python" as before ... or potentially change to explicit "python2". Fedora 29 packages can thus also still be built for Python 2 - just not in the docker image that is updated for Python 3.

packaging: use "--python python" for centos7 to avoid explicit "python2" This is a partial backout of 92a51a45d44c. We will need to be able to control whether package dependencies are python2 or python3. Generally (at least in recent Fedora), the package prefix match the name of the python executable ... but CentOS 7 doesn't use the python2 prefix in package name or alias for python-docutils yet, so just keep centos7 in the unversioned "python" world. Change the new (unused) buildrpm "--python3" option (introduced in a6dcac6454c1) to "--python python3" to get a more generic method for explicit control over whether we use python, python2 or python3.

packaging: fix docker-centos5 - use pythonexe and set to "python" as before Fix 92a51a45d44c .

packaging: move dockerrpm output directory creation to dockerrpm Avoid having to compute the directory in two places in different environments.

packaging: drop "support" for unsupported Fedora versions Fedora 31 has just been released, and Fedora 29 will be EOL in a month. Don't spend any time thinking about dead stuff.

mail: black wants to add this blank line I can't figure out how this got overlooked on previous runs, but here we are. It looks like the culprit change is already public?

hghave: verify we have a black that is new enough for our format We require what is currently the absolute latest black, so let's be paranoid.

contrib: fix up example fix configuration for our move to released black

phabricator: use True primitive instead of b'true' for phabupdate actions Something I'd missed in the creatediff port. This didn't matter before with the old PHP form style wireformat, but breaks with the new arcanist format. Differential Revision: https://phab.mercurial-scm.org/D7152

setup: allow py3 install without env vars 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

formatting: drop `grey`, our custom black version Now that the official black has all we want, we can drop this.

formatting: using black to check for formatting

formatting: run black version 19.10b0 on the codebase 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.

packaging: fix buildrpm whitespace

packaging: drop outdated buildrpm "tested on" comment 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.

packaging: also include hgweb.wsgi in rpms

packaging: introduce Python3 support as buildrpm --python3 Just overrule the HGPYTHON3 warning.

packaging: be explicit about Python version in rpm spec 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.

packaging: make python snippets in rpm building python3 compatible 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.

py3: fix patchbomb to accept non-ASCII header value for email preview Since mail.headencode() is disabled by -n/--test, non-ASCII header value has to be allowed. Spotted by Denis Laxalde.

tests: check patchbomb with a non-ascii commit message This fails on Python 3 but gets fixed in the next changeset.

formatter: fix handling of None value in templater mapping 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.

config: add support for defaultvalue of list of printable elements

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.

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.

py3: leverage pycompat.long

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.

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')]

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.