searching for reviewer(mshal)
8f1443ae9fe4cc6bf37b21e7f302816b9b481965: Bug 1481604 - Require nightly Cargo in addition to a particular rustc when building with tup. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Wed, 22 Aug 2018 20:39:33 +0000 - rev 830938
Push 118861 by bmo:rhelmer@mozilla.com at Thu, 23 Aug 2018 11:42:47 +0000
Bug 1481604 - Require nightly Cargo in addition to a particular rustc when building with tup. r=mshal Our version check is removed as well, as the current required rustc version for Firefox includes all features required to build with tup. Differential Revision: https://phabricator.services.mozilla.com/D3847
8eac225243d8e0846f39c0fc1e4d831765ff6991: Bug 1480558 - part 4 - add icudata support for aarch64 windows; r=mshal
Nathan Froyd <froydnj@mozilla.com> - Tue, 21 Aug 2018 11:00:34 -0400 - rev 830553
Push 118847 by bmo:hskupin@gmail.com at Wed, 22 Aug 2018 09:09:03 +0000
Bug 1480558 - part 4 - add icudata support for aarch64 windows; r=mshal yasm doesn't support aarch64, and trying to use GNU as with an MSVC build seems like sadness waiting to happen. Instead, we'll generate our own assembly file that armasm64 will accept.
90a93173d2474aab0374c02c3af23f5110e4e456: Bug 1480558 - part 3 - unset AS_DASH_C_FLAG for aarch64 windows; r=mshal
Nathan Froyd <froydnj@mozilla.com> - Tue, 21 Aug 2018 11:00:35 -0400 - rev 830552
Push 118847 by bmo:hskupin@gmail.com at Wed, 22 Aug 2018 09:09:03 +0000
Bug 1480558 - part 3 - unset AS_DASH_C_FLAG for aarch64 windows; r=mshal The assembler for this platform doesn't need the special handling AS_DASH_C_FLAG provides.
7378a8999aea1cc98e5255ebf655bfa088bf0ef5: Bug 1480558 - part 2 - don't add MOZ_DEBUG_FLAGS to ASFLAGS on aarch64 windows; r=mshal
Nathan Froyd <froydnj@mozilla.com> - Tue, 21 Aug 2018 11:00:35 -0400 - rev 830551
Push 118847 by bmo:hskupin@gmail.com at Wed, 22 Aug 2018 09:09:03 +0000
Bug 1480558 - part 2 - don't add MOZ_DEBUG_FLAGS to ASFLAGS on aarch64 windows; r=mshal armasm64 doesn't accept the same options as its x86-ish counterparts, and passing options it doesn't understand causes assembly to fail. So let's just not pass any flags to the assembler for the moment.
edc9c624481561f8b9d4fc3218e6cbe47c831aca: Bug 1480558 - part 1 - set AS appropriately on aarch64 windows; r=mshal
Nathan Froyd <froydnj@mozilla.com> - Tue, 21 Aug 2018 11:00:35 -0400 - rev 830550
Push 118847 by bmo:hskupin@gmail.com at Wed, 22 Aug 2018 09:09:03 +0000
Bug 1480558 - part 1 - set AS appropriately on aarch64 windows; r=mshal
0b502a7a768ff6b44e2c26e3e4787d80f3ea8099: Bug 1481504 - fix HOST_OUTOPTION setting for Windows cross-compiles; r=mshal
Nathan Froyd <froydnj@mozilla.com> - Mon, 20 Aug 2018 17:22:44 -0400 - rev 830362
Push 118832 by bmo:ntim.bugs@gmail.com at Tue, 21 Aug 2018 13:33:17 +0000
Bug 1481504 - fix HOST_OUTOPTION setting for Windows cross-compiles; r=mshal For "real" Windows-to-Windows cross compiles, the setting of HOST_OUTOPTION is incorrect: it assumes that if we are cross-compiling, we'll be using `-o ` (GNU-style) rather than `-Fo` (MSVC-style). Our normal x86 Windows automation builds are technically not cross-compiles (host and target are both x86 Windows), so this case has never bothered us before. But when compiling for AArch64 Windows, we are really doing a cross-compile, and so we need to be more careful about how we set this option; otherwise, host compilations will mysteriously fail because they won't produce any output.
92fd5c3a0996ba5e6e5692a7b115c8f6e9234cca: Bug 1481590 - generating report with |mach analyze all| and modifying |mach summarize| to become |mach analyze files| r=gps,mshal,chmanchester
Chris Manchester <cmanchester@mozilla.com> - Fri, 17 Aug 2018 14:20:07 -0700 - rev 830064
Push 118809 by bmo:ntim.bugs@gmail.com at Sat, 18 Aug 2018 10:35:28 +0000
Bug 1481590 - generating report with |mach analyze all| and modifying |mach summarize| to become |mach analyze files| r=gps,mshal,chmanchester
facafe35dd26f60064617d601e69bdf93822c097: Bug 1482583 - Suppress clang-cl warnings in some third-party directories. r=mshal
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Sat, 11 Aug 2018 06:05:19 +0900 - rev 829456
Push 118782 by bmo:mtigley@mozilla.com at Thu, 16 Aug 2018 04:40:36 +0000
Bug 1482583 - Suppress clang-cl warnings in some third-party directories. r=mshal
ac5d5dec618e067abf88eb4ba7dc557723ccb003: Bug 1481590 - generating report with |mach analyze all| and modifying |mach summarize| to become |mach analyze files| r=gps,mshal,chmanchester
Sofia Carrillo <scarrillo@mozilla.com> - Wed, 15 Aug 2018 01:12:03 +0000 - rev 829353
Push 118765 by bmo:dharvey@mozilla.com at Wed, 15 Aug 2018 13:08:04 +0000
Bug 1481590 - generating report with |mach analyze all| and modifying |mach summarize| to become |mach analyze files| r=gps,mshal,chmanchester Differential Revision: https://phabricator.services.mozilla.com/D2981
37cf2f43323bd7c49caa3e308a624a181a1836e9: Bug 1474028 - Use output categories to exclude the gtest libxul from the default tup build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Fri, 10 Aug 2018 12:07:36 -0700 - rev 829345
Push 118765 by bmo:dharvey@mozilla.com at Wed, 15 Aug 2018 13:08:04 +0000
Bug 1474028 - Use output categories to exclude the gtest libxul from the default tup build. r=mshal MozReview-Commit-ID: 2C9PmFziFqr
adadcbb4f742a70bedb5a79c96a67ecb1c93d9a4: Bug 1478798 - Handle the CLOBBER file optimistically in the Tup backend. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Mon, 13 Aug 2018 17:07:41 +0000 - rev 828930
Push 118727 by bmo:rbartlensky@mozilla.com at Tue, 14 Aug 2018 10:49:39 +0000
Bug 1478798 - Handle the CLOBBER file optimistically in the Tup backend. r=mshal MozReview-Commit-ID: DDIqlDwjKil Differential Revision: https://phabricator.services.mozilla.com/D2799
52bd814d3589b8b7d6194e456b7fd7068af397e1: Bug 1474028 - Use output categories to exclude the gtest libxul from the default tup build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Fri, 10 Aug 2018 12:07:36 -0700 - rev 828518
Push 118683 by bmo:gl@mozilla.com at Sat, 11 Aug 2018 20:18:50 +0000
Bug 1474028 - Use output categories to exclude the gtest libxul from the default tup build. r=mshal MozReview-Commit-ID: 2C9PmFziFqr
6f39c71a8f6ce42ca894c7d609c8016e78b3e6ed: Bug 1450077 - Download rust 1.28 in mach bootstrap. r=froydnj,mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 07 Aug 2018 13:21:29 -0700 - rev 827513
Push 118540 by bmo:bpostelnicu@mozilla.com at Wed, 08 Aug 2018 10:44:22 +0000
Bug 1450077 - Download rust 1.28 in mach bootstrap. r=froydnj,mshal MozReview-Commit-ID: IBdFRyWlQTW
31f260db9192b9965b19736b5d5007fa49283807: Bug 1474524: Don't call contains() before adding an entry to the registry. r=mshal
Kris Maglione <maglione.k@gmail.com> - Sun, 05 Aug 2018 13:33:12 -0700 - rev 827418
Push 118534 by bmo:gl@mozilla.com at Wed, 08 Aug 2018 04:44:16 +0000
Bug 1474524: Don't call contains() before adding an entry to the registry. r=mshal It turns out that this check is the major bottleneck in this task. Simply catching the error caused by the duplicate files has the same effect, but is several orders of magnitude faster. MozReview-Commit-ID: 8vFyQ7VVYRD
c391841487f4e299567c730a9a839a45ed91756e: Bug 1480313 - Set check_unchanged for cargo build script rules in the Tup build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Wed, 01 Aug 2018 21:24:51 -0700 - rev 827376
Push 118523 by bmo:alwu@mozilla.com at Tue, 07 Aug 2018 22:38:39 +0000
Bug 1480313 - Set check_unchanged for cargo build script rules in the Tup build. r=mshal MozReview-Commit-ID: Cx3sP5m16Yl
ad4d84607d948c7cf1b9297dd282029f77c3af27: Bug 1474524: Don't call contains() before adding an entry to the registry. r?mshal draft
Kris Maglione <maglione.k@gmail.com> - Sun, 05 Aug 2018 13:33:12 -0700 - rev 826855
Push 118394 by maglione.k@gmail.com at Sun, 05 Aug 2018 20:34:06 +0000
Bug 1474524: Don't call contains() before adding an entry to the registry. r?mshal It turns out that this check is the major bottleneck in this task. Simply catching the error caused by the duplicate files has the same effect, but is several orders of magnitude faster. MozReview-Commit-ID: 8vFyQ7VVYRD
6d4cbc6714481a816dd5af1200c4eea82036a117: Bug 1478499 - Consider GCC_USE_GNU_LD when passing a symbols file in the Tup build for consistency with the Make build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Wed, 01 Aug 2018 13:25:48 -0700 - rev 825769
Push 118170 by plingurar@mozilla.com at Thu, 02 Aug 2018 10:24:36 +0000
Bug 1478499 - Consider GCC_USE_GNU_LD when passing a symbols file in the Tup build for consistency with the Make build. r=mshal MozReview-Commit-ID: 8o4o9HiGdrR
e815b69d6941f1bd0ef5805c81935776e02ee5cf: Bug 1478499 - Specify the symbol version script for js with SYMBOLS_FILE. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Wed, 01 Aug 2018 13:25:47 -0700 - rev 825768
Push 118170 by plingurar@mozilla.com at Thu, 02 Aug 2018 10:24:36 +0000
Bug 1478499 - Specify the symbol version script for js with SYMBOLS_FILE. r=mshal To make this work correctly we need to start respecting SYMBOLS_FILE under js/src, so we start setting GCC_USE_GNU_LD in js/src/config.status to get this wired up. MozReview-Commit-ID: Fn2Q8nwQukv
02c27967110862beef28aac74e8f909d46d187b6: Bug 1478499 - Move symbol version script generation for js shared library to moz.build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Wed, 01 Aug 2018 13:25:38 -0700 - rev 825767
Push 118170 by plingurar@mozilla.com at Thu, 02 Aug 2018 10:24:36 +0000
Bug 1478499 - Move symbol version script generation for js shared library to moz.build. r=mshal MozReview-Commit-ID: 7H287jfbrVF
844b006cc3e9c9dde6494270f388cb306360a49f: Bug 1478499 - Use JS_LIBRARY_NAME rather than LIBRARY_NAME when versioning js symbols. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 16:19:59 -0700 - rev 825766
Push 118170 by plingurar@mozilla.com at Thu, 02 Aug 2018 10:24:36 +0000
Bug 1478499 - Use JS_LIBRARY_NAME rather than LIBRARY_NAME when versioning js symbols. r=mshal MozReview-Commit-ID: 1iqn2Dfwm8S
97e20fbd0365fb26801dc3fdcb2d40fada4cb44d: Bug 1478499 - Skip additional js shell installation via ObjdirFiles in the tup build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 16:19:59 -0700 - rev 825765
Push 118170 by plingurar@mozilla.com at Thu, 02 Aug 2018 10:24:36 +0000
Bug 1478499 - Skip additional js shell installation via ObjdirFiles in the tup build. r=mshal Having an output to !/js/src/js causes problems for tup, because many compilation invocations will attempt to find headers in !/js/src/js, meaning tup thinks these invocations should depend on generating !/js/src/js (the file). MozReview-Commit-ID: Ky6kq82vlO8
9dee6a08a2ddd5156d5b25cd7a8732deaaf76aed: Bug 1478499 - Consider GCC_USE_GNU_LD when passing a symbols file in the Tup build for consistency with the Make build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 16:11:33 -0700 - rev 825516
Push 118129 by jhofmann@mozilla.com at Wed, 01 Aug 2018 22:38:13 +0000
Bug 1478499 - Consider GCC_USE_GNU_LD when passing a symbols file in the Tup build for consistency with the Make build. r=mshal MozReview-Commit-ID: 7D4zYj6vhly
3982c14a834eb62f3c473d8e68c6abb45e354ef8: Bug 1478499 - Specify the symbol version script for js with SYMBOLS_FILE. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 16:10:39 -0700 - rev 825515
Push 118129 by jhofmann@mozilla.com at Wed, 01 Aug 2018 22:38:13 +0000
Bug 1478499 - Specify the symbol version script for js with SYMBOLS_FILE. r=mshal To make this work correctly we need to start respecting SYMBOLS_FILE under js/src, so we start setting GCC_USE_GNU_LD in js/src/config.status to get this wired up. MozReview-Commit-ID: HYahjev0VUo
6f6e562e2013c4d63a470bc43d5b24eb618445e9: Bug 1478499 - Move symbol version script generation for js shared library to moz.build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 15:29:42 -0700 - rev 825514
Push 118129 by jhofmann@mozilla.com at Wed, 01 Aug 2018 22:38:13 +0000
Bug 1478499 - Move symbol version script generation for js shared library to moz.build. r=mshal MozReview-Commit-ID: JF3dtk0ybw2
03f68a47b89ea690a1695d4a4ecb575874d1457e: Bug 1478499 - Use JS_LIBRARY_NAME rather than LIBRARY_NAME when versioning js symbols. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 15:17:48 -0700 - rev 825513
Push 118129 by jhofmann@mozilla.com at Wed, 01 Aug 2018 22:38:13 +0000
Bug 1478499 - Use JS_LIBRARY_NAME rather than LIBRARY_NAME when versioning js symbols. r=mshal MozReview-Commit-ID: HkpddK16VG
237dc169f48651b3963910fba53a2b01651bc7a2: Bug 1478499 - Skip additional js shell installation via ObjdirFiles in the tup build. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Tue, 31 Jul 2018 15:16:04 -0700 - rev 825512
Push 118129 by jhofmann@mozilla.com at Wed, 01 Aug 2018 22:38:13 +0000
Bug 1478499 - Skip additional js shell installation via ObjdirFiles in the tup build. r=mshal Having an output to !/js/src/js causes problems for tup, because many compilation invocations will attempt to find headers in !/js/src/js, meaning tup thinks these invocations should depend on generating !/js/src/js (the file). MozReview-Commit-ID: CHP20RqH1OM
d9eba0253fb44cf9f3e5b590378a07f74f67e520: Bug 1474442 - mach command to analyze files in build graph r=chmanchester,mshal
Sofia Carrillo <scarrillo@mozilla.com> - Wed, 25 Jul 2018 14:06:51 -0400 - rev 823431
Push 117683 by dgottwald@mozilla.com at Fri, 27 Jul 2018 11:18:41 +0000
Bug 1474442 - mach command to analyze files in build graph r=chmanchester,mshal This patch introduces |mach summarize| so developers can see how expensive changing a file will be. For a file in the build graph, developers can get the total wall clock time for the file and the number of downstream commands. This command requires that developers have a local tup db. MozReview-Commit-ID: AWxrMibXH4r
0f0af7e8440bca32ce9ed3ab5d6e0ea2c6f9e145: Bug 1478557 - Use the command string rather than output list as a key for cargo commands in the tup backend. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Wed, 25 Jul 2018 22:51:54 -0700 - rev 823414
Push 117683 by dgottwald@mozilla.com at Fri, 27 Jul 2018 11:18:41 +0000
Bug 1478557 - Use the command string rather than output list as a key for cargo commands in the tup backend. r=mshal MozReview-Commit-ID: B8FtvHScXon
789b4ff72fffb413aecba4dcc8290a1d2f916d74: bug 1447932 - Add support for localized files to fastermake backend. r=mshal
Ted Mielczarek <ted@mielczarek.org> - Wed, 21 Mar 2018 16:47:02 -0400 - rev 822451
Push 117382 by bmo:rob@robwu.nl at Wed, 25 Jul 2018 11:45:57 +0000
bug 1447932 - Add support for localized files to fastermake backend. r=mshal Co-authored by Nick Alexander <nalexander@mozilla.com> This patch adds support to the fastermake backend for taking localized files from a locale directory as specified by the combination of --with-l10n-base and --enable-ui-locale. This allows artifact builds to be built localized with a different locale. MozReview-Commit-ID: 1bD9Gy0ewJ2
d12cfe02357cc97f00ac5f6b3be27ee7d9434aa8: bug 1447932 - Add support for localized files to fastermake backend. r?mshal draft
Ted Mielczarek <ted@mielczarek.org> - Wed, 21 Mar 2018 16:47:02 -0400 - rev 822037
Push 117268 by bmo:ted@mielczarek.org at Tue, 24 Jul 2018 16:41:41 +0000
bug 1447932 - Add support for localized files to fastermake backend. r?mshal Co-authored by Nick Alexander <nalexander@mozilla.com> This patch adds support to the fastermake backend for taking localized files from a locale directory as specified by the combination of --with-l10n-base and --enable-ui-locale. This allows artifact builds to be built localized with a different locale. MozReview-Commit-ID: 1bD9Gy0ewJ2
f19f8d717c6bb7497b6242a860fd96d8d82c50b7: bug 1447932 - Add support for localized files to fastermake backend. r=mshal
Ted Mielczarek <ted@mielczarek.org> - Wed, 21 Mar 2018 16:47:02 -0400 - rev 821583
Push 117144 by bmo:aryx.bugmail@gmx-topmail.de at Mon, 23 Jul 2018 18:24:35 +0000
bug 1447932 - Add support for localized files to fastermake backend. r=mshal Co-authored by Nick Alexander <nalexander@mozilla.com> This patch adds support to the fastermake backend for taking localized files from a locale directory as specified by the combination of --with-l10n-base and --enable-ui-locale. This allows artifact builds to be built localized with a different locale. MozReview-Commit-ID: 1bD9Gy0ewJ2
d5f4d31797839628aff1ec9fefcc7fed59bedcc0: Bug 1475278 - Link a HostRustLibrary to a HostProgram where necessary in the Tup backend. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Thu, 12 Jul 2018 16:31:54 -0700 - rev 820312
Push 116787 by bmo:bpostelnicu@mozilla.com at Thu, 19 Jul 2018 12:19:59 +0000
Bug 1475278 - Link a HostRustLibrary to a HostProgram where necessary in the Tup backend. r=mshal MozReview-Commit-ID: qghHI02Bfs
a4284f99e509ffe95f3d1e31e3cb47ceaaa75456: bug 1447932 - Add support for localized files to fastermake backend. r?mshal draft
Ted Mielczarek <ted@mielczarek.org> - Wed, 21 Mar 2018 16:47:02 -0400 - rev 819384
Push 116544 by bmo:ted@mielczarek.org at Tue, 17 Jul 2018 19:58:04 +0000
bug 1447932 - Add support for localized files to fastermake backend. r?mshal Co-authored by Nick Alexander <nalexander@mozilla.com> This patch adds support to the fastermake backend for taking localized files from a locale directory as specified by the combination of --with-l10n-base and --enable-ui-locale. This allows artifact builds to be built localized with a different locale. MozReview-Commit-ID: 1bD9Gy0ewJ2
6a71b2d44ae208139ba147bc4e302abe76589fe7: bug 1447932 - Add support for localized files to fastermake backend. r?mshal draft
Ted Mielczarek <ted@mielczarek.org> - Wed, 21 Mar 2018 16:47:02 -0400 - rev 819375
Push 116539 by bmo:ted@mielczarek.org at Tue, 17 Jul 2018 18:55:35 +0000
bug 1447932 - Add support for localized files to fastermake backend. r?mshal Co-authored by Nick Alexander <nalexander@mozilla.com> This patch adds support to the fastermake backend for taking localized files from a locale directory as specified by the combination of --with-l10n-base and --enable-ui-locale. This allows artifact builds to be built localized with a different locale. MozReview-Commit-ID: 1bD9Gy0ewJ2
df5da2a468c495a442dee88658ba0e16e41875e8: Bug 1466689 - Perform macOS builds on gecko-{L}-b-linux worker type; r=dustin,mshal
Gregory Szorc <gps@mozilla.com> - Mon, 04 Jun 2018 14:00:20 -0700 - rev 818286
Push 116246 by bmo:tom@mozilla.com at Fri, 13 Jul 2018 20:48:08 +0000
Bug 1466689 - Perform macOS builds on gecko-{L}-b-linux worker type; r=dustin,mshal The gecko-{L}-b-macosx64 worker types are really Linux (macOS builds are cross-compiled). These worker types are essentially identical to their gecko-{L}-b-linux counterparts. I don't see a compelling reason to maintain separate worker types for these builds other than maybe cost accounting (worker types are tagged in AWS land and these tags can be more easily broken out for billing analysis). But I don't think any important systems are relying on this "feature." So let's move the macOS build tasks to the gecko-{L}-b-linux workers. MozReview-Commit-ID: 67bArn6IG9T
e0f80c8f3e7dac385c1dec798d3dd534bb638448: Bug 1460470 - Make run-task Python 3.5+ only; r=mshal
Gregory Szorc <gps@mozilla.com> - Fri, 11 May 2018 10:19:53 -0700 - rev 818178
Push 116246 by bmo:tom@mozilla.com at Fri, 13 Jul 2018 20:48:08 +0000
Bug 1460470 - Make run-task Python 3.5+ only; r=mshal A try push converting run-task to Python 3 seemed to complete without error. Since it is annoying writing code that needs to work on both Python 2 and 3, let's require Python 3 and remove code for supporting Python 2. We implement a version check enforcing Python 3.5+. This is because we're supposed to be standardizing on 3.5+ everywhere. I want to prevent accidental usage of older Python 3 versions. MozReview-Commit-ID: 4vATLZ6Si2e
f86a907fd2f403f6ccfe0f1b810828e838204f04: Bug 1460470 - Change run-task to use Python 3 by default; r=mshal
Gregory Szorc <gps@mozilla.com> - Wed, 09 May 2018 17:26:40 -0700 - rev 818177
Push 116246 by bmo:tom@mozilla.com at Fri, 13 Jul 2018 20:48:08 +0000
Bug 1460470 - Change run-task to use Python 3 by default; r=mshal Python 3 is the future. MozReview-Commit-ID: APuu4Q3mimj
c0e40f3db223b454ae1ae4516096b3163a4ba33d: Bug 1460470 - More run-task Python 3 porting; r=mshal
Gregory Szorc <gps@mozilla.com> - Wed, 09 May 2018 21:15:36 -0700 - rev 818176
Push 116246 by bmo:tom@mozilla.com at Fri, 13 Jul 2018 20:48:08 +0000
Bug 1460470 - More run-task Python 3 porting; r=mshal Mostly normalization of str and bytes. Python 3 is annoying for systems level code where most things are bytes. MozReview-Commit-ID: KpvZGegBkYn
c87d6d0973e2fe4e535d85d4e16cb9cc90261fdb: Bug 1460470 - Make run-task somewhat usable on Python 3; r=mshal
Gregory Szorc <gps@mozilla.com> - Wed, 16 May 2018 11:06:36 -0700 - rev 818175
Push 116246 by bmo:tom@mozilla.com at Fri, 13 Jul 2018 20:48:08 +0000
Bug 1460470 - Make run-task somewhat usable on Python 3; r=mshal This required a lot of attention to bytes versus strings. The hacks around handling process output are somewhat gross. Apparently readline() doesn't work on bytes streams in Python 3?! So we install a custom stream decoder so we can have nice things. There are still some failures in run-task on Python 3. But we're a big step closer. MozReview-Commit-ID: 4FJlTn3q9Ai
e9194e7edcadfcb521f663e1fe967d81d64f8346: Bug 1460470 - Make run-task compile on Python 3; r=mshal
Gregory Szorc <gps@mozilla.com> - Wed, 16 May 2018 13:57:08 -0700 - rev 818174
Push 116246 by bmo:tom@mozilla.com at Fri, 13 Jul 2018 20:48:08 +0000
Bug 1460470 - Make run-task compile on Python 3; r=mshal The file failed to compile due to octal syntax and missing imports. After this change, we get a run-time error, which is strictly better. MozReview-Commit-ID: nY9A13Pt3E
8658af4e92de8b45f53ecf1d284164c46e15ca33: Bug 1475058 - Send SIGINT when interrupting interactive in mach before sending SIGKILL. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Thu, 12 Jul 2018 11:50:48 -0700 - rev 817625
Push 116140 by dgottwald@mozilla.com at Fri, 13 Jul 2018 10:03:29 +0000
Bug 1475058 - Send SIGINT when interrupting interactive in mach before sending SIGKILL. r=mshal MozReview-Commit-ID: 2XxLyNi1ZuS
c2c5533f14f6aa5cf5bd5d3be95b1f361dab1fa8: bug 1475278 - don't use rust demangle in Breakpad when building with tup. r=mshal
Ted Mielczarek <ted@mielczarek.org> - Thu, 12 Jul 2018 12:47:17 -0400 - rev 817570
Push 116119 by bmo:cmanchester@mozilla.com at Fri, 13 Jul 2018 00:16:13 +0000
bug 1475278 - don't use rust demangle in Breakpad when building with tup. r=mshal MozReview-Commit-ID: I7YQbfzBo0p
4e345dbaf6c69bd8492c6a758ca5bfd647c6af02: bug 1475278 - don't use rust demangle in Breakpad when building with tup. r?mshal draft
Ted Mielczarek <ted@mielczarek.org> - Thu, 12 Jul 2018 12:47:17 -0400 - rev 817484
Push 116060 by bmo:ted@mielczarek.org at Thu, 12 Jul 2018 16:48:57 +0000
bug 1475278 - don't use rust demangle in Breakpad when building with tup. r?mshal MozReview-Commit-ID: I7YQbfzBo0p
b18846ed7d05bde5510bb1dddca805aee76e43fe: Bug 1468547 - Re-factor gtest mach command to not invoke make when not necessary. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Mon, 09 Jul 2018 14:28:59 -0700 - rev 815971
Push 115703 by bmo:balbeza@mozilla.com at Tue, 10 Jul 2018 12:19:42 +0000
Bug 1468547 - Re-factor gtest mach command to not invoke make when not necessary. r=mshal MozReview-Commit-ID: 6j7t0YIZc8n
f211edf86a429fd76153b0b3612755ecfb2e1283: Bug 1468547 - Build the gtest libxul in the tup backend. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Mon, 09 Jul 2018 14:28:58 -0700 - rev 815970
Push 115703 by bmo:balbeza@mozilla.com at Tue, 10 Jul 2018 12:19:42 +0000
Bug 1468547 - Build the gtest libxul in the tup backend. r=mshal MozReview-Commit-ID: 8EISyDauwgD
b9937e7b09956d8228283632aa6d4079c45a0368: Bug 1468547 - Add a default output group to the Tup backend. r=mshal
Chris Manchester <cmanchester@mozilla.com> - Mon, 09 Jul 2018 14:28:58 -0700 - rev 815969
Push 115703 by bmo:balbeza@mozilla.com at Tue, 10 Jul 2018 12:19:42 +0000
Bug 1468547 - Add a default output group to the Tup backend. r=mshal This adds everything to a default output group so we can run `tup upd $objdir/<default>` during `mach build` and `tup upd $objdir/<gtest>` for instance when running `mach gtest` as a way to conditionally build parts of the tree. MozReview-Commit-ID: 8jpkru1EgAC
d6120c2bb51e2057df51f4d52510bb5f4e8b4ca5: Bug 1459004: Generate built_in_addons.json from moz.build definitions. r=mshal
Kris Maglione <maglione.k@gmail.com> - Wed, 06 Jun 2018 16:43:00 -0700 - rev 812387
Push 114542 by jdescottes@mozilla.com at Fri, 29 Jun 2018 10:33:35 +0000
Bug 1459004: Generate built_in_addons.json from moz.build definitions. r=mshal MozReview-Commit-ID: 1HRLG5tSlFr
300908ac5dc7b8607afeaea25a5258d0f157ee45: Bug 1436662 - Fix Thunderbird support for building windows packages. r=mshal, a=jcristau
Tom Prince <mozilla@hocat.ca> - Wed, 18 Apr 2018 20:52:07 -0600 - rev 812310
Push 114530 by bmo:imadueme@mozilla.com at Fri, 29 Jun 2018 05:41:04 +0000
Bug 1436662 - Fix Thunderbird support for building windows packages. r=mshal, a=jcristau Differential Revision: https://phabricator.services.mozilla.com/D991
4f7281fb654297bef2b6db642b9422b1416bb096: Bug 1436662: Remove `installer` MOZ_AUTOMATION stage; r=mshal a=jcristau
Tom Prince <mozilla@hocat.ca> - Thu, 05 Apr 2018 19:12:10 -0600 - rev 812309
Push 114530 by bmo:imadueme@mozilla.com at Fri, 29 Jun 2018 05:41:04 +0000
Bug 1436662: Remove `installer` MOZ_AUTOMATION stage; r=mshal a=jcristau The previous commit moved creating installers to be side effect of creating packages. This makes the installer step not actually do anything. So remove the step from automation. Differential Revision: https://phabricator.services.mozilla.com/D864
80affed3488675d550859e52b4c70d123d7d66d5: Bug 1436662: Package translated uninstaller; r=pike,mshal a=jcristau
Tom Prince <mozilla@hocat.ca> - Mon, 16 Apr 2018 12:49:53 -0600 - rev 812308
Push 114530 by bmo:imadueme@mozilla.com at Fri, 29 Jun 2018 05:41:04 +0000
Bug 1436662: Package translated uninstaller; r=pike,mshal a=jcristau The uninstaller was being built as a side-effect of building `setup.exe`. In Bug 1385227, that was moved from "somewhere" to part of the windows installer packaging, which happens after the zip and mar are generated. Since the installer we ship is actually repackaged from the zip[1], we stopped shipping translated uninstallers. This changes things around so that the uninstaller gets translated: - Explicitly build the uninstaller as part of the L10n repack step. - Use the same logic to build the installer locally as we do to create the ones we ship. [1] Except on Thunderbird Differential Revision: https://phabricator.services.mozilla.com/D672