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'.
This allows builddeb to handle distributions that are not Debian.
Distributor ID is reported by lsb_release --id, and in case of builddeb it's
usually Debian or Ubuntu.
Debian and Ubuntu releases have both codenames and traditional version numbers.
An entire "branch" of releases is referred to by its codename, and version
numbers (e.g. 8.2, 14.04.3) are used to address individual releases.
Since we use codenames for building .deb packages, let's call the option and
the variable appropriately.
`make debian-jessie` was a poor name choice on my part, because it
really builds a package for the current debian platform, whatever that
happens to be, rather than a specific platform. Rename it to just
`make deb` so that it's a little clearer. As a result, it now places
built debs in a "debian-unknown" directory.
Future work will allow us to use docker to build debs.
Right now this doesn't install any config files. I plan to do that as
a followup, but getting something basic and working checked in seems
like more of a priority than getting everything done in one big step.
This also does not create a source deb yet. I haven't looked into that
process.
Note that this declares incompatibility with the `mercurial-common`
package. It's typical for debian packages to be split between
architecture-independent bits and native bits, meaning the python bits
downstream live in mercurial-common and the c extension bits live in
mercurial. We don't do that because we want to (ideally) give users a
single deb file to install.
Before this patch, doc string of each web commands isn't extracted as
translatable one, even though web commands are listed up in "hg help
hgweb".
This patch adds "mercurial/hgweb/webcommands.py" on to arguments of
"i18n/hggettext". "i18nfunctions" added into "webcommands.py" is used
by "i18n/hggettext" to get the list of functions having translatable
doc string.
I keep wanting to run 'make tests', but I forget to set TESTFLAGS='-j
16' or whatever is reasonable for my machine. This lets me just set it
once in my shell settings and forget it.
This makes it easy to do 'make testpy-2.4.6 TESTFLAGS="-j 16"' and the
Makefile will build Python if needed and then run tests (with -j 16)
with the resulting Python.
You can set the environment variable HGPYTHONS to a nice location on
your machine to cache the Python builds globally. If that's not set,
it builds them inside build/pythons.
The packages has to be installed by root but they would be installed
insecurely, owned by the uid of the unprivileged user that made the package.
The local user with that uid could thus write to /usr/local/bin/hg .
bdist_mpkg calls out to pax to create the package, but pax do apparently not
have the power to control what it is writing.
Instead, patch the pax files and set their uid fields to 0 before they are
wrapped in a dmg.
It seems like a default installation of bdist_mpkg makes it available as
Python module, but the corresponding executable is placed in a location like
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/bin which is
not in $PATH and thus not directly available. 'make osx' would thus fail.
Instead, skip the bdist_mpkg executable and invoke it as a Python module. That
works out of the box here.
bdist_mpkg do for some reason default to use the parameter --show ("Open with
Installer.app after building") if no parameters are specified. We do not like
that.
All the important parameters to bdist_mpkg are already specified in setup.py
and we don't have any to specify in the Makefile.
Instead, specify the parameter '--' which do no harm but will disable the
default opening of the installer. This makes it possible to build packages
"silently".
When running 'make clean' in an extracted release tarball, file
mercurial/__version__.py is removed, causing a subsequent install to
indicate 'version unknown'.
This problem was reported in the past [1] and a patch proposed in that mail,
but was never properly sent nor applied.
[1] http://selenic.com/pipermail/mercurial/2010-December/036249.html
OS X would offer to expand the zip so the (multi file) installer inside it
could be run ... but that would leave the expanded zip folder around.
Instead, use a .dmg file that automatically will be mounted - that seems more
common on OS X.
Still, there is two levels of levels of clicking before actually launching the
installer. Having a single file installer would be better ... but seems to be
hard. A more feasible improvement would be some fancy layout inside the .dmg .
`which -s` is a BSDism that doesn't exist on other versions of
`which`. That means that even on Mac OS X, `make osx` breaks if you have
another utils package installed (e.g. debianutils installed thru
fink). Redirect output to /dev/null instead.
"make clean" already removed __index__.py[cdo], but not the __index__.py
(automatically generated by "python setup.py build_hgextindex").
"setup.py build_hgextindex" did not generate a new index if file
__index__.py[cdo] already existed, because if __index__.py was removed,
the compiled file containing the old information was imported and used.
Generate an empty file (with a new timestamp to generate a new .py[cdo])
instead and make mercurial.extensions ignore the unset docs attribute.
One of the problems was a failed test-help.t, to reproduce:
$ rm hgext/__index__.py*
$ echo 'docs = {"mq": "dummy"}' > hgext/__index__.py
$ make test-help.t
With this a "make clean" or "python setup.py build_hgextindex" helps.
The update is done on a temporary file since d6abb3586946. The name of this
file was first XX.po~ and has been changed to XX.po.tmp in all except of one
place. Do this now.
Allow overwrite LANGUAGE and LC_ALL make variables, for make i18n man and html.
After this patch, we can make i18n man and html by following command:
$ make clean all LANGUAGE=ja
When running 'python setup.py sdist' many files were omitted from the resulting
tarball that are required for a complete build, including the .h file for the
inotify extension due to a python2.7+ distutils bug. This would cause 'make dist'
to fail to build a correct dist on python2.7
By building a MANIFEST.in that is the same as the old MANIFEST with 'include'
at the start of each line will cause a correct MANIFEST to be built and used
by distutils.
Comments marked with "i18n:", like:
# i18n: do not translate the field names
msg = _("Valid entries for the format field are topic, bar, number.")
will become available for translators in the .po files:
#. i18n: do not translate the field names
msgid "Valid entries for the format field are topic, bar, number."
msgstr ""
Given a system Python version of 2.6, the following won't clean up build:
$ make local PYTHON=python2.7
$ make clean
Distutils only cleans up build subdirectories for the current Python
version.
This patch cleans up the build folder even if PYTHON=python2.7 isn't
specified to clean.
The DESTDIR variable used to tell 'make install' an alternate system root
to install the software to. Since setup.py supports the same via its --root
parameter, it's easy to make life easier for many packagers.
By default, xgettext will wrap strings at 79 characters. This width
includes the two double-quotes and the '\n' added. Our strings are now
wrapped at 78 characters and a line can therefore be up to 82
characters wide in the .po file.
Setting the width to 82 characters ensures that xgettext does no silly
wrapping on our already-wrapped strings while still wrapping long
one-liners at 82 characters.
