This patch initializes the Mozpower module and implements the PowerBase class. This class is used as a base for subclasses that implement power measurement tooling for various OS and CPU combinations.
Differential Revision: https://phabricator.services.mozilla.com/D39191
--HG--
extra : moz-landing-system : lando
This is the equivalent of .pth in virtualenv declarations. It sets up
a .egg file with a `sys.path` addition, as far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D37131
--HG--
extra : moz-landing-system : lando
This is the equivalent of .pth in virtualenv declarations. It sets up
a .egg file with a `sys.path` addition, as far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D37131
--HG--
extra : moz-landing-system : lando
This is the equivalent of .pth in virtualenv declarations. It sets up
a .egg file with a `sys.path` addition, as far as I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D37131
--HG--
extra : moz-landing-system : lando
If there is still value to this -- if you know of anyone using jimdb via mach, etc -- I am
happy to throw this away, but otherwise, would like to clean it up.
Differential Revision: https://phabricator.services.mozilla.com/D30943
--HG--
extra : moz-landing-system : lando
This patch moves testing/raptor/raptor/playback into its own testing package in testing/mozbase/mozproxy
so we can use the proxy in other places than Raptor.
Differential Revision: https://phabricator.services.mozilla.com/D21200
--HG--
rename : testing/raptor/raptor/playback/__init__.py => testing/mozbase/mozproxy/mozproxy/__init__.py
rename : testing/raptor/raptor/playback/base.py => testing/mozbase/mozproxy/mozproxy/backends/base.py
rename : testing/raptor/raptor/playback/mitmproxy.py => testing/mozbase/mozproxy/mozproxy/backends/mitm.py
rename : testing/raptor/raptor/playback/mitmproxy-rel-bin-linux64.manifest => testing/mozbase/mozproxy/mozproxy/backends/mitmproxy-rel-bin-linux64.manifest
rename : testing/raptor/raptor/playback/mitmproxy-rel-bin-osx.manifest => testing/mozbase/mozproxy/mozproxy/backends/mitmproxy-rel-bin-osx.manifest
rename : testing/raptor/raptor/playback/mitmproxy-rel-bin-win.manifest => testing/mozbase/mozproxy/mozproxy/backends/mitmproxy-rel-bin-win.manifest
rename : testing/raptor/raptor/playback/mitmproxy_requirements.txt => testing/mozbase/mozproxy/mozproxy/backends/mitmproxy_requirements.txt
extra : moz-landing-system : lando
AVDs are identical to previous version, except that the config.ini files are updated
with a larger size for the /data partition.
--HG--
extra : rebase_source : 4eb406a33e47593bb7e7ff9dc34142516012d7ea
The minidump_stackwalk used for tests ifs picked up from tooltool, and
it looks like the tooltool manifests haven't been updated in 2 years.
As it turns out, this old version is not capable of, at least, stack
walk over crashes originated in LTOed rust code on Windows, while
breakpad trunk, as well as the slightly oldest version we have in-tree
do.
While ideally, we'd go with building minidump_stackwalk as a taskcluster
toolchain artifact, or during the build, but that involves significantly
more work, while we should fix the stack traces of crashes that people
_do_ get as early as possible.
The tooltool artifacts linked in the updated manifests were generated
the following way:
- Revert the last two changes that happened to minidump_stackwalk.cc
between 2016 and now (they don't matter for functionality and get in
the way of the rest below).
- Apply the changes betwen the version of minidump_stackwalk.cc from
2016 and
https://hg.mozilla.org/users/tmielczarek_mozilla.com/stackwalk-http/raw-file/51e4725ffad4/stackwalk.cc
- Pick the http_symbol_supplier.cc and http_symbol_supplier.h files from
the same repo as stackwalk.cc above.
- Add the necessary build system bits to build it off the Gecko tree,
along with the in-tree breakpad code.
- Build it for linux, linux64, macosx64, win32-mingw.
The patch doing all the above is:
https://hg.mozilla.org/try/rev/64491336dc7fca7a1c00ae8c66619b01563bbe4e
The push to build it on the aforementioned platforms:
https://hg.mozilla.org/try/rev/4b621a67ca0bd6cf8954566e180d23e1ba8a9f83
A win64-mingw variant was also built, but is not being used, keeping
things in line with what we currently are using. We may want to follow
up with an update to use that win64 variant on 64-bits testers.
Differential Revision: https://phabricator.services.mozilla.com/D14005
--HG--
extra : moz-landing-system : lando
mach android-emulator currently supports 6 different avds; I am struggling to maintain
that many configurations. I don't see a lot of value in keeping both 6.0 and 7.0,
and Android 6.0 is not as popular as 7.0. Let's remove 6.0, encouraging 7.0 as an
alternative; same for x86-6.0 -> x86-7.0.
This fixes a regression to |mach talos-test| around a missing 'mozterm'
dependency.
MozReview-Commit-ID: GcfoA4U1fqg
--HG--
extra : rebase_source : 68c743165a03c4d9975676556252816793ba9d49
This makes sure the mozterm module is available to the testers. The
setup.py was needed to it could be installed from requirements.txt.
This module does not yet live on pypi.
MozReview-Commit-ID: 9AL0EZ1uVgL
--HG--
extra : rebase_source : 882d4ec5ec9b80f20ca63e5c7303752427b390d2
This makes sure the mozterm module is available to the testers. The
setup.py was needed to it could be installed from requirements.txt.
This module does not yet live on pypi.
MozReview-Commit-ID: 9AL0EZ1uVgL
--HG--
extra : rebase_source : 4052f60e5e793d912045a9bd420d70c59e8a69fb
