Re: Hash files, signature and key now missing from release directory

[Ralph Giles]

On Tue, Apr 12, 2016 at 3:51 AM, Neil Harris  wrote:

> for example, http://releases.mozilla.org/pub/firefox/releases/45.0.1/

Also note that the releases.mozilla.org host supports https, which
offers an additional verification path.

 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Binary components Firefox 45 ESR - TypeError: Components.classes[cid] is undefined

[Bobby Holley]

Binary components are no longer supported:
https://blog.mozilla.org/addons/2015/05/04/dropping-support-for-binary-components/

On Tue, Apr 12, 2016 at 11:38 AM,  wrote:

> Hi,
>
> I would like to know if binary components still work in Firefox 45 ESR. I
> have a Firefox extension that is an XPCOM extension that works in Firefox
> 38 ESR. I am trying to upgrade it to work with 45 ESR and have used the
> Firefox 45 ESR SDK (from
> ftp.mozilla.org/pub/firefox/releases/45.0esr/win32/en-us/sdk) to build
> the xpt and header file. Both files are successfully generated.
>
> After making changes to my code to fix the removed/modified APIs, I am
> able to compile it. However, after registering the component, even though
> it shows up in the Firefox add-ons, I get the error TypeError:
> Components.classes[cid] is undefined. I have tried isolating the problem
> and it occurs in my main.js file when var o is set to
> Components.classes[cid].
>
> Thanks!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

This is probably a field that could stand to be re-labled, as I was
blithely thinking (and I would guess others are) that it was for features,
only.

-- Emma

On Tue, Apr 12, 2016 at 1:01 PM, Mark Côté  wrote:

> On 2016-04-07 2:50 AM, L. David Baron wrote:
> > (I'd much rather a bug report be editable text, with history
> > available, for answers to these or similar questions -- rather than
> > a stream of permanent comments.  But we seem stuck with the horrid
> > stream-of-comments Bugzilla format, which means I try to ignore the
> > comments as much as I can.  Then again, a 200 character summary is
> > often good enough to answer the above 5 questions.  As with the rest
> > of the Internet, don't read the comments.)
>
> Meant to reply to this earlier... BMO has a User Story field that sounds
> like it does exactly what you want.  It's an editable field that keeps
> history (admittedly not in an easy-to-read way, but that could be
> improved).  Despite the name of the field, I've found it useful for
> summarizing the current state of the discussion in the bug (sometimes
> along with the "obsolete" comment tag).
>
> Mark
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style for C++ enums

[Jason Orendorff]

On Mon, Apr 11, 2016 at 7:58 PM, Jeff Gilbert  wrote:

> On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley 
> wrote:
> > On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert 
> wrote:
> >> I think the whole attempt is
> >> increasingly a distraction vs the alternative, and I say this as
> >> someone who writes and reviews under at least three differently-styled
> >> code areas. The JS engine will, as ever, remain distinct
> >
> > Jason agreed to converge SM style with Gecko.
>
> The SM engineers I talked to are dismissive of this. I will solicit
> responses.
>

For the record:

SM is converging to Gecko style, at the rate that people contribute patches
to re-style our existing code. I.e., very slowly.

The one exception is indentation level: enough SM devs prefer 4-space
indents that we aren't changing that without further (internal) discussion.

-j
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Chris Peterson]

I've long thought that Bugzilla should be more like Wikipedia: the 
"front page" of the bug is editable and always up-to-date (i.e. not 
incorrect or outdated STRs), but the history and meta discussion is 
still available on a "back page".



On 4/12/16 2:19 PM, David Lawrence wrote:

I used to think it should be called "Abstract". Sort of a summarization
of the bug itself.

dkl

On 04/12/2016 05:02 PM, Emma Humphries wrote:

This is probably a field that could stand to be re-labled, as I was
blithely thinking (and I would guess others are) that it was for features,
only.

-- Emma

On Tue, Apr 12, 2016 at 1:01 PM, Mark Côté  wrote:


On 2016-04-07 2:50 AM, L. David Baron wrote:

(I'd much rather a bug report be editable text, with history
available, for answers to these or similar questions -- rather than
a stream of permanent comments.  But we seem stuck with the horrid
stream-of-comments Bugzilla format, which means I try to ignore the
comments as much as I can.  Then again, a 200 character summary is
often good enough to answer the above 5 questions.  As with the rest
of the Internet, don't read the comments.)


Meant to reply to this earlier... BMO has a User Story field that sounds
like it does exactly what you want.  It's an editable field that keeps
history (admittedly not in an easy-to-read way, but that could be
improved).  Despite the name of the field, I've found it useful for
summarizing the current state of the discussion in the bug (sometimes
along with the "obsolete" comment tag).

Mark

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Hash files, signature and key now missing from release directory

[Neil Harris]

On 12/04/16 17:32, Ralph Giles wrote:

On Tue, Apr 12, 2016 at 3:51 AM, Neil Harris  wrote:


for example, http://releases.mozilla.org/pub/firefox/releases/45.0.1/

Also note that the releases.mozilla.org host supports https, which
offers an additional verification path.

  -r



Yes, indeed it does, and perhaps I should have put the https link for 
the avoidance of confusion: however, my point about hashes/signature/key 
information was independent of whether the download is http or https -- 
and this issue has been fixed by kmoir, for which many thanks.


-- N
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Binary components Firefox 45 ESR - TypeError: Components.classes[cid] is undefined

[ganjoshua11]

On Wednesday, April 13, 2016 at 2:41:58 AM UTC+8, Bobby Holley wrote:
> Binary components are no longer supported:
> https://blog.mozilla.org/addons/2015/05/04/dropping-support-for-binary-components/
> 
> > Hi,
> >
> > I would like to know if binary components still work in Firefox 45 ESR. I
> > have a Firefox extension that is an XPCOM extension that works in Firefox
> > 38 ESR. I am trying to upgrade it to work with 45 ESR and have used the
> > Firefox 45 ESR SDK (from
> > ftp.mozilla.org/pub/firefox/releases/45.0esr/win32/en-us/sdk) to build
> > the xpt and header file. Both files are successfully generated.
> >
> > After making changes to my code to fix the removed/modified APIs, I am
> > able to compile it. However, after registering the component, even though
> > it shows up in the Firefox add-ons, I get the error TypeError:
> > Components.classes[cid] is undefined. I have tried isolating the problem
> > and it occurs in my main.js file when var o is set to
> > Components.classes[cid].
> >
> > Thanks!
> > ___


Hi Bobby,

Thanks for the response. Does this mean that all existing binary XPCOM 
extensions will not run in Firefox 45? Is there a way to allow the running of 
such components perhaps via some config settings?

Thanks again.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why do we still need to include Qt widget in mozilla-central?

[Masayuki Nakano]

On 2016/04/12 20:27, Henri Sivonen wrote:

On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano  wrote:

So, my question is, why do we still have Qt widget in mozilla-central? What
the reason of keeping it in mozilla-central?


My understanding is that
https://git.merproject.org/mer-core/qtmozembed/ still uses it.


Yeah, but they can clone m-c to their repository and it must be nicer 
since Qt widget code is broken in a lot of days under current our 
management.


> As we

are figuring out how to be more embeddable (see
https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ), it's
probably a bad time to make life hard for an existing embedding
solution.


If we continue to support Qt widget, I'd like we keep Qt widget 
buildable. At least on mozilla-central and tryserver, building Qt widget 
everyday will prevent bustage.


# My post didn't suggest to drop Qt widget. The status, i.e., dropping 
or continuing, should be clearer.


--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Gijs Kruitbosch]

On 12/04/2016 01:16, Justin Dolske wrote:

Looks like Gijs replied in
https://bugzilla.mozilla.org/show_bug.cgi?id=1255526#c21, and the
contributor's last comment for the day was acknowledgment that he'd stop.


Yes. I got another email personally, from which it seems that they 
thought the comments would


 "help to sort out developer specific bugs which are not actually 
suitable for newbie QA contributors."


to which I replied (that it unfortunately wasn't particularly helpful) 
and suggested they talk to QA folks on this Friday's test day.


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Hash files, signature and key now missing from release directory

[Neil Harris]

I'm not sure if this is the right list for this, but I thought I'd 
better bring this to your attention.


Previous release directories have carried checksum files, with 
signatures and a key file that allows the various binary files to be 
validated. See, for example, 
http://releases.mozilla.org/pub/firefox/releases/45.0.1/


In the most recent release, at 
http://releases.mozilla.org/pub/firefox/releases/45.0.2/ , these files 
appear to be missing, making it impossible to validate the release files 
as authentic.


This seems to me to be a backwards step for Firefox distribution 
security. If this is an oversight, could it be remedied, please? If this 
is a deliberate change, could someone please provide a rationale for the 
changes?


Kind regards,

Neil Harris




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

BMO Version Upgrade Testing and Feedback Needed by May 2nd, 2016

[David Lawrence]

My apologies. We will need to move this out a week to accommodate the
new Firefox release on April 26th. We do not want our migration to
interrupt the release process so better to do it after.

More time for quality testing and feedback! :)

Thanks
dkl


 Forwarded Message 
Subject: BMO Version Upgrade Testing and Feedback Needed by April 25th, 2016
Date: Mon, 11 Apr 2016 19:58:53 -0700 (PDT)
From: dlawre...@mozilla.com
To: mozilla-tools-...@lists.mozilla.org
Newsgroups: mozilla.tools.bmo

Greetings,

The Mozilla Bugzilla Team (B-Team) is happy to announce the test release
of the next version of bugzilla.mozilla.org (BMO) based on the upstream
Bugzilla code base. Although we have backported a lot of cool stuff over
the years from upstream, it is still beneficial for Mozilla to run a
more modern version of Bugzilla. This will allow for easier porting of
new features to the BMO code base, as well as allowing upstream to use
some BMO customizations.

We are hoping to have the upgrade completed by April 25, 2016. Please
let us know if that date will have any negative impact on development
schedules.

Please test drive at https://bugzilla-merge.allizom.org.

The main areas of focus for our test releases are stability,
performance, and reliability. Functionality that currently works in our
code base installed at https://bugzilla.mozilla.org should continue to
work as expected in the new version. Please let us know of any
customizations that may be missing as well. There are also numerous new
features/fixes that are part of the upstream code base, such as Markdown
support in comments and better HTML5 support, to name a couple.

Also, please test your various scripts and third-party applications,
such as dashboards, that use the XMLRPC/JSON/REST APIs with the test
server to make sure they continue to function properly.

The database is a sanitized snapshot of the live database so should be
useful for testing to make sure the information is displayed properly
and changeable. Please ping someone in #bteam IRC channel to set your
password as passwords have been removed.

Also note, email has been disabled so that unnecessary spam is not sent
out. So feel free to make changes to bugs to verify proper working order.

We are asking for anyone who has a few spare minutes to get involved and
provide testing and feedback.

Please file bug reports in the production BMO system at
https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org=development

Thanks,
The Mozilla Bugzilla Team
https://wiki.mozilla.org/BMO
___
tools-bmo mailing list
tools-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/tools-bmo


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform