This imports the changes from wheezy-lts (http://deb.freexian.com/extended-lts/)
and creates a package we install in the debian7-based images (with a
modified version number to work around bug #1419577.
This leaves out debian7-raw and debian7-packages as unpatched, because
of the chicken-and-egg problem.
Depends on D26100
Differential Revision: https://phabricator.services.mozilla.com/D26102
--HG--
extra : moz-landing-system : lando
The SQLite in Debian 7 (3.7.13) lacks support for common table
expressions (the WITH keyword), which was introduced in SQLite
3.8.3. The Mercurial SQLite storage backend currently relies on
CTEs. Even if a future Mercurial doesn't require CTE, it is likely
that it will still use CTE if available for performance reasons.
So, it is in our best interest to give Mercurial access to a
modern SQLite. Plus, using a modern SQLite and avoiding potential
bugs in old versions seems prudent.
This commit introduces a SQLite package backport for Debian 7
so we can use the new SQLite feature. We had to minimally patch
the build to work with an older version of TCL that isn't using
multiarch.
I observed libsqlite3 being installed as part of building various
other packages (such as Python). I initially added the package as
a dependency so packages would be built against a more modern
SQLite. But glandium doesn't believe it matters, since nothing
should be doing build-time feature detection. Python is the most
important downstream package (since Mercurial uses its SQLite).
I audited the CPython build system and did not see any build-time
SQLite feature detection or version sniffing. So I think we'll be
fine building against an older SQLite.
Differential Revision: https://phabricator.services.mozilla.com/D14194
--HG--
extra : moz-landing-system : lando
This pulls a newer version of the nasm package, and patches
out doc building in order to make it compile on debian 7.
Differential Revision: https://phabricator.services.mozilla.com/D13510
--HG--
extra : moz-landing-system : lando
There are several kinds that cache tasks based on the inputs that go into the task. Historically,
these inputs included the name of upstream tasks. This change these tasks to include the digest
of the upstream tasks.
This also bumps the version of the docker and toolchain as every digest is changed for them.
Differential Revision: https://phabricator.services.mozilla.com/D11949
--HG--
extra : moz-landing-system : lando
This was released a few minutes ago. It contains some fixes necessary to support
partial clones.
Differential Revision: https://phabricator.services.mozilla.com/D13768
--HG--
extra : moz-landing-system : lando
We need to run Mercurial 4.8 so we can start using SQLite storage
and wire protocol version 2 for partial clones.
--auto-deconfigure was added because desktop1604-test now inherits
from a base image with Mercurial installed.
Differential Revision: https://phabricator.services.mozilla.com/D11399
--HG--
extra : moz-landing-system : lando
We need to run Mercurial 4.8 so we can start using SQLite storage
and wire protocol version 2 for partial clones.
Differential Revision: https://phabricator.services.mozilla.com/D11399
--HG--
extra : rebase_source : 712fa08226f74ef9cfe306b7c68ff3dd3f54d9d3
extra : source : a438eff7d106f25a951c690c22f30b37d40d54a6
We need to run Mercurial 4.8 so we can start using SQLite storage
and wire protocol version 2 for partial clones.
Differential Revision: https://phabricator.services.mozilla.com/D11399
--HG--
extra : moz-landing-system : lando
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
Upgrading to 4.7.1 will apply a fix to a performance regression
that was introduced in 4.7.
Differential Revision: https://phabricator.services.mozilla.com/D4961
--HG--
extra : rebase_source : 0139856b2f2a22c5a0e8876d5e34cc8f7e8e0307
extra : source : 1b49fa4d48428ad7bac0cca69fb5f5f3767c43b9
python-zstandard's 0.9.1 source distribution contains a debian/
directory.
On Squeeze, producing a Debian package is straightforward.
On Wheezy, we need to hack up Build-Depends because Wheezy doesn't
have a package for the Hypothesis fuzzing library. This package is
only used for testing and our package building disables testing,
so we don't even need to further hack up the packaging to disable
tests.
MozReview-Commit-ID: 6raXjdzggCH
--HG--
extra : rebase_source : 672492a40d65df8430eb17ba033bcb1c0890b7df
dh-python isn't available in Wheezy. Let's backport it so we can
build Python packages that use it.
Fortunately for us, the package builds without any modifications.
The only customization we need is to ensure our custom Python
packages are present in order to satisfy Build-Depends.
MozReview-Commit-ID: CqZtwvosA6K
--HG--
extra : rebase_source : 36515905a6c5937ba16f5f4b566b61715b4f26ac
The python3-minimal package provides /usr/bin/python3 on Debian.
This commit installs this package so a `python3` executable is
provided.
This required backporting the package to wheezy. The final patch
is trivial. But I wasted a bit of time figuring out why `mk-build-deps`
wasn't working. It would no-op and exit 0 and then the build would
complain about missing dependencies!
glandium's theory is that the ":any" multiarch support on wheezy
isn't complete. Removing ":any" seems to make things "just work."
MozReview-Commit-ID: FBicpK4SmkQ
--HG--
extra : rebase_source : a28ce731024e8ed6a43fb30e2ed57da2abb50d0f
Debian 7 ships Python 3.2 by default. That's too old for our
upcoming build requirement of Python 3.5.
This commit adds a Python 3.5 package for wheezy that backports
the Python 3.5 from a much later Debian version.
The patch was inspired by the existing patch for Python 2.7.
However, it needed additional work. The changes and reasons
should all be documented in the changelog file as part of the
package diff we apply.
I'm a bit disappointed we had to disable PGO. But it was
reliably segfaulting during the build. I didn't feel like going
down that rabbit hole.
MozReview-Commit-ID: ABpHW1KYFQP
--HG--
extra : rebase_source : 02dbd13236fe741cb33f07c803218fda339c214e
We bump the version of Mercurial for Debian packages and for Ubuntu
Docker images.
MozReview-Commit-ID: KYmG4rOm3TQ
--HG--
extra : rebase_source : cbb817a9ee4c27f0bc59f4fa1e2a708fac1cb093
The GDB version in Debian wheezy doesn't handle the DWARF data that the
GCC version we use to build Firefox and toolchains produce. So we take
the GDB version from Debian stretch and backport it.
--HG--
extra : rebase_source : dae0e9dcd5dde5a7c74b6cefd560480fccd9c5fa
There were a few constraints in the choice of the version of dpkg to
backport:
- 1.17.20 is the first version that supports the debian source format
for that xz-utils package.
- versions >= 1.17.10 and <= 1.17.22 fail to build on wheezy.
- versions >= 1.17.21 depend on a version of patch not available on
wheezy.
All in all, the simpler choice was to go with version 1.17.20 with a
backport of the build failure fix.
That version of dpkg breaks the version of devscripts in wheezy, so the
version from wheezy-backports would be better to use, but we can't
unconditionally use it on all builds, because it happens that
mk-build-deps from that version is broken with the dpkg in wheezy.
In the end, it's simpler to build that backport and rely on package task
dependencies rather than selectively install the package from
wheezy-backports, so we do that. Except we can't use version
2.14.11~bpo70+1 because of bug 1419577.
--HG--
extra : rebase_source : 19ad1a44b770229fbc7e15bbcf01d3cb101315a8
Back in bug 1360609, we added `run-on-projects` to a list so that the
toolchain tasks wouldn't run on every push on release branches.
Fast forward to now, and they're depended upon by other tasks, meaning
they are triggered when appropriate, without resorting to that trick. In
fact, the commit message for bug 1360609 said we could switch to an
empty list once the jobs have dependencies.
The same is true from package tasks, which, in fact, I suspect would
happen on every push on release branches.
The only exception is for a few toolchains that are depended upon by
nothing, and that are produced for developer consumption with e.g. mach
artifact toolchain.
--HG--
extra : rebase_source : bb8624fed7490b85f4bd72b7ceb2db7a72b4c2ab
The one available in Debian wheezy is 3.81, but we're explicitly using
4.0 on CentOS, most notably because of its --output-sync option which
helps make logs better in some ways.
This takes the package from Debian jessie and builds it for Debian
wheezy.
--HG--
extra : rebase_source : 20bb550703fec41ed0175ef7f78c5b9a394160f3
The one available in Debian wheezy is 1.7.10.4, which is really old, and
on our centos images, we're using 2.8.0rc3, which, while old too, is
more modern. While we may want to go with a more recent version, I'd
rather avoid differing from what we currently use, so use the exact same
version.
--HG--
extra : rebase_source : dfdf75a635073c248faef8a67648b2a83e4a1d84
We build packages of the same versions that were installed by
taskcluster/docker/recipes/install-cmake.sh and
taskcluster/docker/centos6-build/system-setup.sh in the desktop-build
image.
--HG--
extra : rebase_source : 843b89065daabd450f54ebf7a2cf55d00977e23a
