On 23/09/2016 05:01, ishikawa wrote:
On 2016年09月23日 11:42, ishikawa wrote:
By changing a few install.rdf as suggested, the particular error messages
are gone, but
I now see different failures.
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=de72a169065a2bbb7f69a0e5420992bf
On 22/09/16 17:07, Ehsan Akhgari wrote:
> What exact debug configuration is too slow for you? People who want to
> debug C++ generally turn optimizations off, but for front-end devs, I
> think building with --enable-debug and --enable-optimize should give you
> an optimized build with the debug f
On 2016年09月23日 03:01, Andrew McKay wrote:
> Just a note that https://bugzilla.mozilla.org/show_bug.cgi?id=1303418
> is about to land and this will prevent an add-on upgrade changing the
> ID of the add-on. That's not happening in this case (the code hasn't
> landed), but just a heads up on a simila
On 2016年09月23日 11:42, ishikawa wrote:
> On 2016年09月22日 17:33, Mark Banner wrote:
>> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>>> 3:07:56 INFO - 1474488476446addons.xpi-utilsWARN
>>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>>> addon ID: expected addon
On 2016年09月22日 17:33, Mark Banner wrote:
> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>> 3:07:56 INFO - 1474488476446addons.xpi-utilsWARN
>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>> addon ID: expected addon ID specialpow...@mozilla.org, found
>> spec
hg.mozilla.org's x509 server certificate (AKA an "SSL certificate") expires
next week.
A new certificate has already been issued and it is scheduled to be swapped
in around 2016-09-26T17:00Z (Monday September 26 10:00 PDT). The transition
may be delayed to avoid downtime in automation, which hasn'
Just a note that https://bugzilla.mozilla.org/show_bug.cgi?id=1303418
is about to land and this will prevent an add-on upgrade changing the
ID of the add-on. That's not happening in this case (the code hasn't
landed), but just a heads up on a similar front.
On 22 September 2016 at 01:33, Mark Bann
On 9/22/16 2:52 PM, gar...@mozilla.com wrote:
In May it was decided that artifacts for try jobs running in TaskCluster should
expire after 14 days.
Just to be clear, what counts as "artifacts" here? The actual build?
The log? All of the above?
There may be value for keeping logs longer th
On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote:
> On 22/09/2016 05:28, Nicholas Nethercote wrote:
>> Greetings,
>>
>> Assertions, such as MOZ_ASSERT, are great. But they only run in debug
>> builds.
>>
>> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
>>
>> I want to highlight a n
Definitely explore this!
I want us to be very careful/deliberate about the privacy consequences of
this, though. Any values which could be user data need to be tightly
controlled, in the same manner we control access to the minidumps
themselves. So I don't think we should be too generic about this
In May it was decided that artifacts for try jobs running in TaskCluster should
expire after 14 days. This has greatly reduced the amount of try artifacts
that we keep within s3 and we are looking to make the same changes to buildbot
try artifacts that were uploaded using TaskCluster.
Bug 1303
On 09/22/2016 04:28 AM, Nicholas Nethercote wrote:
I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
this in nsTArray::ElementAt(), to implement a form of always-on array
bounds checking. See
https://bugzilla
On 22/09/2016 05:28, Nicholas Nethercote wrote:
Greetings,
Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.
Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
I want to highlight a nice case where converting a normal assertion
into a release asserti
On 9/22/2016 12:28 AM, Nicholas Nethercote wrote:
Greetings,
Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.
Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
I want to highlight a nice case where converting a normal assertion
into a release asser
On Thursday, September 22, 2016 at 5:58:58 PM UTC+10, Paul Adenot wrote:
> On Thu, Sep 22, 2016, at 07:33 AM, Gerald Squelart wrote:
> > Sitting on the shoulders of giants, an idea, in the unlikely case it's
> > not been thought of yet:
> > How about an assertion that files a crash report (or somet
On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
3:07:56 INFO - 1474488476446addons.xpi-utilsWARN
addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
addon ID: expected addon ID specialpow...@mozilla.org, found
special-pow...@mozilla.org in manifest ...
I am not su
On Thu, Sep 22, 2016, at 07:33 AM, Gerald Squelart wrote:
> Sitting on the shoulders of giants, an idea, in the unlikely case it's
> not been thought of yet:
> How about an assertion that files a crash report (or something lighter
> like a telemetry blip) but does not actually crash?
I think you c
+1 on MOZ_DIAGNOSTIC_ASSERT - its been very useful to me as well.
On Thu, Sep 22, 2016 at 6:40 AM, Bobby Holley wrote:
> There's also MOZ_DIAGNOSTIC_ASSERT, which is fatal in pre-release builds
> but not release ones. It can be a good compromise to find bugs in the wild
> when the performance co
While perusing error log of try-comm-central run of
Windows 7 debug version run of |make mozmill| test on try-comm-central
treeherder, I noticed a strange error message.
3:07:56 INFO - 1474488476446 addons.xpi-utils WARN addMetadata:
Add-on specialpow...@mozilla.org is invalid: Error: Inv
19 matches
Mail list logo
