hi Nick;
Yes, there was/is a bug about osx10.9 compiler issues, see bug#936977
for details. However, that bug specifically happens with builds-only,
and is unrelated to this tests-only proposal. I'm not aware of anything
preventing us from running 10.9 *testing*.
Hope that helps.
John.
=
On 1
On Thu, Nov 21, 2013 at 04:56:50PM -0500, John O'Duinn wrote:
> 6) If a developer lands a patch that works on 10.9, but it fails somehow
> on 10.7 or 10.8, it is unlikely that we would back out the fix, and we
> would instead tell users to upgrade to 10.9 anyways, for the security fixes.
It's not
Last I heard, the official recommendation from IT was for Mozilla
folks (esp. devs) to not upgrade to 10.9 yet, because some things
might not work. Is that no longer the case?
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lis
And to bring this full circle...
>> - Finish fixing the social API leaks:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=933551.
>
> Fixed on mozilla-central. Not yet backported to other repos. I asked
> ttaubert to nominate them for backporting.
ttaubert pointed out that these just help with
On Thu, Nov 21, 2013 at 05:56:12PM -0800, Jed Davis wrote:
> On Thu, Nov 21, 2013 at 05:41:27PM -0500, Boris Zbarsky wrote:
> > On 11/21/13 3:15 PM, Gavin Sharp wrote:
> >> It would be good to explore alternatives to Bonsai.
> >> https://github.com/mozilla/mozilla-central is supposed to have full
>
The next MemShrink meeting will be brought to you by the shutdown leak detector:
https://bugzilla.mozilla.org/show_bug.cgi?id=932898
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure
Hi all,
Please join me in welcoming David Keeler as a PSM peer! Amongst many
other things, David implemented the HSTS preload list, integrated OCSP
stapling into Firefox, and is current implementing the OCSP
Must-Staple feature, which is a key part of our goal of making
certificate status checking
On Thu, Nov 21, 2013 at 7:38 AM, Gregory Szorc wrote:
>
> You people are sick. I go to bed, wake up and my builds have gotten faster
And I've gone from 7.5 minutes to 6.75 minutes in the past day or two.
Nick
___
dev-platform mailing list
dev-platform@
On Thu, Nov 21, 2013 at 05:41:27PM -0500, Boris Zbarsky wrote:
> On 11/21/13 3:15 PM, Gavin Sharp wrote:
>> It would be good to explore alternatives to Bonsai.
>> https://github.com/mozilla/mozilla-central is supposed to have full
>> CVS history, right?
>
> Hmm. Where in there is the equivalent o
On 11/21/2013 3:12 PM, Laura Thomson wrote:
I can explain a little more about the motivation.
bonsai is old code, and written in very old-fashioned perl. As such, security
bugs are frequently filed against it, and it's very hard to find people who are
willing and able to fix them. If you are w
On 11/21/13 8:43 PM, Laura Thomson
wrote:
I'll keep it short and to the point. Are there any objections to shutting down http://bonsai.mozilla.org/cvsqueryform.cgi ?
If you don't know what that is--and few people do, which is even more reason to shut it off--it's a
I filed bug 941949 for what I think is a better solution
https://bugzilla.mozilla.org/show_bug.cgi?id=941949 - Support partial
updates for more than the last update for nightly and aurora
Robert
On 11/20/2013 11:37 PM, Robert Strong wrote:
While that might makes sense to implement for nightly,
On 11/21/13 3:15 PM, Gavin Sharp wrote:
It would be good to explore alternatives to Bonsai.
https://github.com/mozilla/mozilla-central is supposed to have full
CVS history, right?
Hmm. Where in there is the equivalent of
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla%2Flayout%2Fhtml%2Ffo
On 2013-11-21 10:06 AM, Michael Shal wrote:
From: "Gregory Szorc"
Unified sources have probably saved sufficient CPU cycles across all of
automation to more than offset having a non-unified build-only job. I'll
defer to the Platform Team (Ehsan?) to request that from Release
Engineering.
How m
I'm in the same boat - I use it relatively frequently to look up history.
Part of this is a form of habit - there are alternatives ways to get
at (most of?) that history now.
But I would be interested to know more about what killing it gains us,
in order to better evaluate the tradeoff.
Gavin
O
On 2013-11-21 12:00 PM, ISHIKAWA,chiaki wrote:
(2013/11/22 1:47), Ehsan Akhgari wrote:
On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote:
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way th
tl;dr: In order to improve our osx10.6 test capacity and to quickly
start osx10.9 testing, we're planning to make the following changes to
our OSX-build-and-test-infrastructure.
1) convert all 10.7 test machines as 10.6 test machines in order to
increase our 10.6 capacity.
2) convert all 10.8 test
On 11/21/13, 1:12 PM, Laura Thomson wrote:
I can explain a little more about the motivation.
bonsai is old code, and written in very old-fashioned perl. As such, security
bugs are frequently filed against it, and it's very hard to find people who are
willing and able to fix them. If you are wi
On 11/21/13 2:43 PM, Laura Thomson wrote:
it's a search engine for some of our CVS repositories
It's not just a search engine. It's also the only way to get CVS blame
sanely without doing a local pull of the CVS repository or trying to
make git do something useful for you. And a lot of our
On 11/21/2013 08:43 PM, Laura Thomson wrote:
I'll keep it short and to the point. Are there any objections to shutting down
http://bonsai.mozilla.org/cvsqueryform.cgi ?
If you don't know what that is--and few people do, which is even more reason to
shut it off--it's a search engine for some of
I can explain a little more about the motivation.
bonsai is old code, and written in very old-fashioned perl. As such, security
bugs are frequently filed against it, and it's very hard to find people who are
willing and able to fix them. If you are willing and able, let me know: I can
hook you
I'll keep it short and to the point. Are there any objections to shutting down
http://bonsai.mozilla.org/cvsqueryform.cgi ?
If you don't know what that is--and few people do, which is even more reason to
shut it off--it's a search engine for some of our CVS repositories, of which I
think none a
On 11/21/13, 7:06 AM, Michael Shal wrote:
From: "Gregory Szorc"
Unified sources have probably saved sufficient CPU cycles across all of
automation to more than offset having a non-unified build-only job. I'll
defer to the Platform Team (Ehsan?) to request that from Release
Engineering.
How man
Le 21. 11. 13 21:19, smaug a écrit :
> Don't even think about closing down bonsai. I could perhaps live without
> http://bonsai.mozilla.org/cvsqueryform.cgi, but
> http://bonsai.mozilla.org/cvsblame.cgi and
> http://bonsai.mozilla.org/cvslog.cgi
> are super useful.
I totally agree with smaug. You
On 11/21/2013 10:15 PM, Gavin Sharp wrote:
It would be good to explore alternatives to Bonsai.
https://github.com/mozilla/mozilla-central is supposed to have full
CVS history, right?
Some concerns with that alternative:
- I think that repo misses some history from some branches of CVS
- I'm not
Have we checked with the NSS or NSPR teams?
Kevin
On Nov 21, 2013 11:45 AM, "Laura Thomson" wrote:
> I'll keep it short and to the point. Are there any objections to shutting
> down http://bonsai.mozilla.org/cvsqueryform.cgi ?
>
> If you don't know what that is--and few people do, which is even
On Thu, 21 Nov 2013 12:15:48 -0800
Gavin Sharp wrote:
> It would be good to explore alternatives to Bonsai.
> https://github.com/mozilla/mozilla-central is supposed to have full
> CVS history, right?
For mozilla-central, maybe? ... but there are a ton of other projects
that used Bonsai as well,
If we had blame enabled on http://git.mozilla.org/ would you be able to
get what you need easily?
Currently, if I replace 'history' with 'blame' in a gitweb url, I get
"403 - Blame view not allowed" :(
http://git.mozilla.org/?p=integration/gecko-dev.git;a=history;f=README.txt;h=da882f56b14bd8
It would be good to explore alternatives to Bonsai.
https://github.com/mozilla/mozilla-central is supposed to have full
CVS history, right?
Some concerns with that alternative:
- I think that repo misses some history from some branches of CVS
- I'm not confident that we've audited that whatever hi
Gregory Szorc writes:
> Do we need periodic clobber? It's just wallpapering over legit
> clobber-needed issues, which doesn't exactly help us fix them.
The problem is that unfixed bugs in dependences mean that code
bugs can sometimes not show up until the next clobber. There is
then a huge regre
> From: "Gregory Szorc"
> Unified sources have probably saved sufficient CPU cycles across all of
> automation to more than offset having a non-unified build-only job. I'll
> defer to the Platform Team (Ehsan?) to request that from Release
> Engineering.
How many CPU cycles would we have saved ac
On 11/21/2013 09:43 PM, Laura Thomson wrote:
I'll keep it short and to the point. Are there any objections to shutting down
http://bonsai.mozilla.org/cvsqueryform.cgi ?
If you don't know what that is--and few people do, which is even more reason to
shut it off--it's a search engine for some of
On 11/21/13 2:00 PM, Paolo Amadini wrote:
I hope to see a comparable or even better level of debuggability in the
native Promise implementation soon!
Are there bugs filed on what's missing here? It should be pretty simple
to implement all sorts of things here as needed, but we need a clear
On 11/21/13, 8:40 AM, Ehsan Akhgari wrote:
On 2013-11-21 10:44 AM, Ed Morley wrote:
On 21 November 2013 15:38:28, Ehsan Akhgari wrote:
We don't, we clobber periodically. I'm not sure why that is better
than never clobbering...
We've been force-clobbering 1-2 times a day in automation for sev
On 11/20/13, 9:57 PM, Gregory Szorc wrote:
On 11/19/2013 10:08 PM, Gregory Szorc wrote:
On 11/18/13, 11:15 PM, Gregory Szorc wrote:
Do builds feel like they've gotten faster in the last few weeks^hours?
It's because they have.
When I did my MacBook Pro comparison [1] with a changeset from Oct
On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote:
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds
work is
by using the UNIFIED_SOURCES instead of the SOURCES variable in
On 21 November 2013 15:38:28, Ehsan Akhgari wrote:
We don't, we clobber periodically. I'm not sure why that is better
than never clobbering...
We've been force-clobbering 1-2 times a day in automation for several
months now sadly, due to bug 928195 and similar prior. (Patches almost
ready to
On 19/11/2013 1.38, Nikhil Marathe wrote:
> DOM Promise has been in the tree for a while
> We currently have two JS promise implementations in our codebase:
> toolkit/modules/Promise.jsm
Though it may seem counter-intuitive, the non-native Promise.jsm has
grown better error reporting and debuggabi
On 2013-11-21 10:44 AM, Ed Morley wrote:
On 21 November 2013 15:38:28, Ehsan Akhgari wrote:
We don't, we clobber periodically. I'm not sure why that is better
than never clobbering...
We've been force-clobbering 1-2 times a day in automation for several
months now sadly, due to bug 928195 and
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds work is
by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build
files. With that, the build system c
On 11/21/2013 1:11 PM, Robert Kaiser wrote:
Philip Chee schrieb:
I thought that there was a plan to pre-allocate on startup some memory
for the minidump/crash reporter?
For one thing, I'm not sure how far that went, for the other, we are
calling a Windows function to generate the minidump and
On 11/20/2013 2:11 PM, fma spew wrote:
The prompt part is not needed to be provided by WebCrypto. In the latest
releases, the prompt part has been taken care of our plugin. However, in
our new prototype, the scripting UI part (Dojo) will take care of it.
I expect that the browser will need to med
> On 11/21/13, 8:40 AM, Ehsan Akhgari wrote:
>> Yes, but our periodic clobber has been in effect long before that bug
>> (and in fact for as long as I can remember.)
Yes, but it's only once a week rather than a couple of times a day :-)
On 21/11/2013 16:45, Gregory Szorc wrote:
Do we need perio
> From: "Neil"
> There used to be a limitation that source files had to be in the VPATH.
> This limitation obviously does not apply to unified sources (the
> compiler will use the -I path to find the source.) so you shouldn't have
> a problem setting UNIFIED_SOURCES in a parent moz.build file. In
On Wed, Nov 20, 2013 at 2:40 PM, Benjamin Smedberg wrote:
> On 11/20/2013 3:10 AM, fma spew wrote:
>
>> Our customers' end-users have their end-user certificates stored in the
>> "Personal logical certificate store" on Windows. The rest of needed
>> certificates, ("Intermediary" and/or "Trusted Ro
(2013/11/22 1:47), Ehsan Akhgari wrote:
On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote:
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds
work is
by using the UNIFIED_S
Philip Chee schrieb:
I thought that there was a plan to pre-allocate on startup some memory
for the minidump/crash reporter?
For one thing, I'm not sure how far that went, for the other, we are
calling a Windows function to generate the minidump and I'm not sure if
we can reserve the memory i
(2013/11/22 2:17), Ehsan Akhgari wrote:
FWIW if this proves to be common, it's a huge problem since it would
affect our crash stats etc... :(
Well, if the problem is related to the symptom
that I observed with the use of -gsplit-dwarf option
with ccache, then we may be in for a big surprise.
On 21/11/2013 01:12, Daniel Glastonbury wrote:
I followed your advice. Quit Xcode, created .lldbinit, ./mach clobber && ./mach
build and my missing breakpoints are back. Thank you.
You're welcome.
___
dev-platform mailing list
dev-platform@lists.moz
On 21/11/2013 03:16, Ehsan Akhgari wrote:
On 2013-11-20 6:37 PM, Jonathan Watt wrote:
I'll update the OS X Debugging wiki page. Since it seems setting
target.inline-breakpoint-strategy can basically be made to work I don't
plan on contacting the LLDB guys right now.
Can we add our own lldbinit
Zack Weinberg wrote:
On 2013-11-20 12:37 PM, Benoit Jacob wrote:
Talking about ideas for further extending the impact of
UNIFIED_SOURCES, it seems that the biggest limitation at the moment
is that sources can't be unified between different moz.build's.
Because of that, source directories tha
51 matches
Mail list logo
