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.
The xgettext program knows about Python string formatting and will
mark messages with a special "#, python-format" comment in the hg.pot
file. When msgfmt compiles the file, it can check these messages to
ensure that the translated string uses the same conversion specifiers
as the original string.
The pygettext program is still used to extract the docstrings.
The target update-pot extracts strings using pygettext and updates the
i18n/hg.pot file. The translators can then use msgmerge to merge the
new strings in hg.pot with their xx.po file when they want to.
The setup.py file now includes files under both templates/ and i18n/
as data files.
local: build extensions inplace (the former "all" target")
all: "local" (for people who expect this) and build everything else
install: install pre-built things (so root doesn't have to write to $HOME)
install-home: use setup.py's --home option instead of --prefix
