This rule is no longer useful because chg daemon may be killed and respawned
per config/environment hash. We can't reliably run a daemon in foreground.
Before this patch, HGVER would be evaluated at the beginning of the make
execution, and would be unset because build/mercurial/ doesn't exist yet
at that point. Now we compute the version after the `make install` run
has completed.
This is backported to stable from 8626b44516c1, but that revision had an
error in the shell invocation syntax.
The only version strings that are changed are the ones baked into the
.pkg - hg's self-reported version string doesn't change, so users will
still see our mostly-pip-compatible version strings.
For reference, the part of our versioning setup that's not PEP440
compatible is the RC releases - those should be .rc0 insted of
-rc. It's too late to change that for the 4.3 cycle, so I'll worry
about fixing that during the 4.4 cycle.
The way HGVER is evaluated now, it'll be evaluated at the beginning of the
make execution - with this change, it's evaluated when it gets to that command,
at which point the version file it's looking for is sure to exist and be
up-to-date.
Differential Revision: https://phab.mercurial-scm.org/D224
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
Having linux wheels is going to helps system without compiler or python-dev
plus speed up the installation for everyone.
I followed the manylinux example repository
https://github.com/pypa/python-manylinux-demo
to add a make target (build-linux-wheels) using
official docker image to build python 2 linux wheels
for mercurial. It generates Python 2.6 and Python 2.7 for both
32 and 64 bits architectures.
I had to blacklist several test cases for various reasons:
* test-convert-git.t and test-subrepo-git.t because of the git version
* test-patchbomb-tls.t because of warning using tls 1.0
It's likely because the docker image is based on centos 5.0 and
openssl is outdated.
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
The zsh location appears to be on the default $fpath for zsh. bash, on
the other hand, appears to have no default location for completion
scripts, so we follow the lead of Apple's Git distribution and select
a semi-arbitrary place in /usr/local for the file.
Ubuntu 15.10 (Wily Werewolf) came out on October 22, 2015 and reached end of
life on July 28, 2016 [1]. Users were encouraged to upgrade to 16.04 (Xenial).
PPA doesn't allow new uploads targeting 15.10 anymore.
[1]: https://wiki.ubuntu.com/Releases
Instead of using bdist_mpkg, we use the modern Apple-provided tools to
build an OS X Installer package directly. This has several advantages:
* Avoids bdist_mpkg which seems to be barely maintained and is hard to
use.
* Creates a single unified .pkg instead of a .mpkg.
* The package we produce is in the modern, single-file format instead of
a directory bundle that we have to zip up for download.
In addition, this way of building the package now correctly:
* Installs the manpages, bringing the `make osx`-generated package in
line with the official Mac packages we publish on the website.
* Installs files with the correct permissions instead of encoding the
UID of the user who happened to build the package.
Thanks to Augie for updating the test expectations.
This is a bit of a hack, but I don't really want to mount a dmg during
a test, and I don't see an option with hdiutil to take a dmg and spit
out a folder, so this is what we've got for now.
Support for '!=' was only added in GNU Make 4.0, and CentOS versions as new as
CentOS 7 only carry 3.82.
I will leave figuring out compatibility with BSD make as an exercise for
interested folks.
This is portable between BSD and GNU make.
As of this change, our Makefile appears to work in both BSD and GNU
make, with the caveat that the test-% and testpy-% wildcard rules
don't work on BSD make. That said, this still seems worthwhile because
it lets the buildbots work more consistently across platforms.
One problem reported by lintian is "bad-distribution-in-changes-file unstable"
in changelog, but the current changelog for the official package in Ubuntu also
uses that distribution name (unstable), because they import from Debian. This
certainly doesn't stop the build process.
Instead of rewriting __init__ to define the modulepolicy,
write out a __modulepolicy__.py file like __version__.py
This should work for both system-wide installation and in-place build. Therefore
we can avoid relying on two separate modulepolicy rules, '@MODULELOADPOLICY@'
and 'mercurial/modulepolicy'.
