If a packaging task ended up being retried for any reason, the downstream
docker tasks that depended on them would fail, since they were hard-coding the
artifacts from the initial run.
Differential Revision: https://phabricator.services.mozilla.com/D7364
Interestingly, the resulting binaries are still compatible with Gtk+
3.4. The only difference in symbol use are:
g_log -> g_logv
g_assertion_message -> g_assertion_message_expr
Both of those symbols are actually available in older versions of glib.
Some #defines just switched from using the latter rather than the
former.
Differential Revision: https://phabricator.services.mozilla.com/D11141
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
We're going to bump our shipped builds to build against Gtk+ 3.10, but
still want to ensure we can still build against Gtk+ 3.4. As we're using
Gtk+ packages installed in the build docker image, we need to have a
separate image where the Gtk+ packages are kept at version 3.4.
Differential Revision: https://phabricator.services.mozilla.com/D11137
If a packaging task ended up being retried for any reason, the downstream
docker tasks that depended on them would fail, since they were hard-coding the
artifacts from the initial run.
Differential Revision: https://phabricator.services.mozilla.com/D7364
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
We're going to bump our shipped builds to build against Gtk+ 3.10, but
still want to ensure we can still build against Gtk+ 3.4. As we're using
Gtk+ packages installed in the build docker image, we need to have a
separate image where the Gtk+ packages are kept at version 3.4.
Differential Revision: https://phabricator.services.mozilla.com/D11137
Allow for retrigger adjustments when backfilling perf jobs and remove the now outdated geckoProfile support in this custom job action.
Differential Revision: https://phabricator.services.mozilla.com/D10742
--HG--
extra : moz-landing-system : lando
This uses the latest image_builder image (on docker hub) to build even the
image_builder image.
The change to `docker.py` handles a new API response (`aux`) from the Docker
daemon. It's unclear what this key means, but displaying it is simple.
Differential Revision: https://phabricator.services.mozilla.com/D8441
--HG--
extra : moz-landing-system : lando
This sets `TASKCLUSTER_BASE_URL` instead of `TASKCLUSTER_ROOT_URL`, since the proxy doesn't support the redeployable URL schema yet.
Differential Revision: https://phabricator.services.mozilla.com/D10149
--HG--
extra : moz-landing-system : lando
For tasks that only need python, the base images are sufficient. The in-tree
code verifies that the caches are setup as volumes in the image being used,
so set the caches in the base images as well.
Differential Revision: https://phabricator.services.mozilla.com/D10148
--HG--
extra : moz-landing-system : lando
We duplicate the hg.mo fingerprints in run-task so we can fall
back to known good values in case secrets retrieval fails.
Differential Revision: https://phabricator.services.mozilla.com/D10090
--HG--
extra : source : fe2744d3413d28aafe9334c1bac1081ca5702cbd
extra : amend_source : 5a3820ce0ebf3848c7eaa46fa6cb6a662be48c50
Also turn on saving of rust analysis for the windows searchfox job.
Depends on D10355
Differential Revision: https://phabricator.services.mozilla.com/D10356
--HG--
extra : moz-landing-system : lando
