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
The baseline compiler should always call builtins assuming the hardfp
calling convention on ARM, but it would actually take the native
calling convention on the device into account and sometimes use the
softfp convention.
The reason the baseline compiler should always use hardfp is that the
builtin thunks already convert hardfp->softfp along the call path and
softfp->hardfp along the return path, if this is necessary, to allow
wasm to call builtins using the hardfp convention always.
It is possible that the situation was different when the baseline
compiler was written and that the bug is the result of subsequent
changes to the thunk layer, but this is not known precisely.
There's a driveby fix here to simplify the logic around determining
hardfp vs softfp for the system ABI; UseHardFpABI() is now always
available and does the right thing, we don't need the #ifdef nest we
had previously.
--HG--
extra : rebase_source : 5b82e0d25cad05f9064e859282dd9d886da1e672
extra : amend_source : 13b9627ddda0127c7e34fe6b01f3d252f5bfba42
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
I suspect that the root cause of bug 1502182 is that we try open a database
connection before the old one is fully closed. Instead of dealing with
complicatedasync bookkeeping to make sure this doesn't happen, this patch
simply never closes the database connection. I don't think any of the
benefits of closing IndexedDB databases apply to Normandy, and it isn't
a significant cost to simply keep them open.
Additionally, the patch distinguishes between readonly and readwrite
transactions with the database. This was originally done to try and fix
the bug. When it didn't help, I decided to leave the change in because
it is a beneficial change anyways.
Differential Revision: https://phabricator.services.mozilla.com/D10629
--HG--
extra : moz-landing-system : lando
This patch doesn't change behavior; it's just making some custom cleanup
code unnecessary by using a better fitting container class.
Differential Revision: https://phabricator.services.mozilla.com/D11237
--HG--
extra : moz-landing-system : lando
Geoff Brown
Benjamin Bouvier
Jason Laster
Nicolas Silva
Luke Schwalfenberg
Mike Hommey
Tom Prince
Lars T Hansen
Alexander Surkov
Bobby Holley
Gabriel Luong
arthur.iakab
Lee Salzman
Michael Cooper
Rob Wood
Cosmin Sabou
Collin Wing
Daniel Holbert
Johann Hofmann
Markus Stange
Emilio Cobos Álvarez
Sam Foster