Kyle Lippincott <spectral@google.com> [Thu, 18 Jun 2020 10:48:27 -0700] rev 45006
debian: support building a single deb for multiple py3 versions
Around transitions from one python minor version to another (such as 3.7 to
3.8), the current packaging can be slightly problematic - it produces a
`control` file that requires that the version of `python3` that's installed be
exactly the one that was used on the build machine for the `mercurial` package,
by containing a line like:
Depends: sensible-utils, libc6 (>= 2.14), python3 (<< 3.8), python3 (>= 3.7~), python3:any (>= 3.5~)
This is because it "knows" we only built for v3.7, which is the current default
on my system. By building the native components for multiple versions, we can
make it produce a line like this, which is compatible with 3.7 AND 3.8:
Depends: sensible-utils, libc6 (>= 2.14), python3 (<< 3.9), python3 (>= 3.7~), python3:any (>= 3.5~)
This isn't *normally* required, so I'm not making it the default. For those that
receive their python3 and mercurial packages from their distro, and/or don't
have to worry about a situation where the team that manages the python3
installation isn't the same as the team that manages the mercurial installation,
this is probably not necessary.
I chose the names `DEB_HG_*` because `DEB_*` is passed through `debuild`
automatically (otherwise we'd have to explicitly allow the options through,
which is a nuisance), and the `HG` part is to make it clear that this isn't a
"standard" debian option that other packages might respect.
Test Plan:
1. "nothing changed":
- built a deb without these changes
- built a deb with these changes but everything at the default
- used diffoscope to compare, all differences were due to timestamps
2. "explicit is the same as implicit" (single version)
- built a deb with everything at the default
- built a deb with DEB_HG_PYTHON_VERSIONS=3.7
- used diffoscope to compare, all differences were due to timestamps
3. "explicit is the same as implicit" (multi version)
- built a deb with DEB_HG_MULTI_VERSION=1
- built a deb with DEB_HG_PYTHON_VERSIONS=3.7
- used diffoscope to compare, all differences were due to timestamps
4. (single version, 3.7) doesn't work with python3.8
- `/usr/bin/python3.7 /usr/bin/hg debuginstall` works
- `/usr/bin/python3.8 /usr/bin/hg debuginstall` crashes
5. (multi version, 3.7 + 3.8)
- `/usr/bin/python3.7 /usr/bin/hg debuginstall` works
- `/usr/bin/python3.8 /usr/bin/hg debuginstall` works
Differential Revision: https://phab.mercurial-scm.org/D8642
Augie Fackler <augie@google.com> [Fri, 26 Jun 2020 11:20:58 -0400] rev 45005
merge with stable
Manuel Jacob <me@manueljacob.de> [Thu, 25 Jun 2020 03:46:07 +0200] rev 45004
hgweb: encode WSGI environment like OS environment
Previously, the WSGI environment keys and values were encoded using latin-1.
This resulted in a crash if a WSGI environment key or value could not be encoded
using latin-1.
On Unix, the OS environment is byte-based. Therefore we should do the reverse of
what Python does for os.environ.
On Windows, there’s no native byte-based OS environment. Therefore we should do
the same as what mercurial.encoding does with the OS environment.
Manuel Jacob <me@manueljacob.de> [Thu, 25 Jun 2020 03:10:13 +0200] rev 45003
hgweb: deduplicate code
A following patch will change the way keys and values are encoded. To reduce the
diff, I’ve split off the uninteresting part.
Manuel Jacob <me@manueljacob.de> [Fri, 26 Jun 2020 09:37:34 +0200] rev 45002
curses: do not initialize LC_ALL to user settings (
issue6358)
701341f57ceb moved the setlocale() call to right before curses was used. This
didn’t fully solve the problem it was supposed to solve (locale-dependent
functions, like date formatting/parsing), but only postponed it.
Initializing LC_CTYPE seems to be sufficient for curses to work correctly.
Luckily this is already done at interpreter startup on modern Python versions
and, since recently, by Mercurial in the pycompat module in all other cases.
Manuel Jacob <me@manueljacob.de> [Fri, 26 Jun 2020 04:07:50 +0200] rev 45001
compat: initialize LC_CTYPE locale on all Python versions and platforms
Previously, the LC_CTYPE locale was not initialized according to user settings
on all Python versions (e.g. never on Python 2) and platforms (e.g. not on
some Python < 3.8 on Windows).
This broke e.g. non-ASCII filenames passed to the Subversion bindings on Python
2, resulting in error messages like "file:///tmp/a%C3%A4 does not look like a
Subversion repository to libsvn version 1.14.0".
The following command could be used to test this functionality. Adding it to the
test suite would be pointless, as the locale is always set to "C" during test
runs.
@command(b'check_initial_codeset', norepo=True)
def check_initial_codeset(ui):
codeset1 = locale.nl_langinfo(locale.CODESET)
locale.setlocale(locale.LC_ALL, '')
codeset2 = locale.nl_langinfo(locale.CODESET)
assert codeset1 == codeset2
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 Jun 2020 10:32:51 -0700] rev 45000
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 24 Jun 2020 23:17:56 -0700] rev 44999
merge: don't grab wlock when merging in memory
I noticed this because we have an internal extension that does an
in-memory rebase while holding only a repo lock, which resulted in a
developer warning about the working copy lock being taken after the
repo lock.
Differential Revision: https://phab.mercurial-scm.org/D8665