XULRunner Upgrade Issue - From 18.0 to 30.0
I have an Mac OS X app working fine on XULRunner ver 18.0. Now I am upgrading the XULRunner version from 18.0 to 30.0. Have followed the steps below: 1. Downloaded the XULRunner 30.0 Runtime 2. Remove the content from XULRunner.Framework directory 3. Copied the latest files downloaded in XULRunner 30.0 Runtime Now while launching the application, I am getting this error: Dyld Error Message: Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Users/USER/Desktop/*/MyApp.app/Contents/MacOS/xulrunner Reason: image not found Please help me to resolve this issue. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Issue in upgrading XULRunner from 18.0 to 30.0
I have an Mac OS X app working fine on XULRunner ver 18.0. Now I am upgrading the XULRunner version from 18.0 to 30.0. Have followed the steps below: 1. Downloaded the XULRunner 30.0 Runtime 2. Remove the content from XULRunner.Framework directory 3. Copied the latest files downloaded in XULRunner 30.0 Runtime Now while launching the application, I am getting this error: Dyld Error Message: Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Users/USER/Desktop/*/OxfordDictionary.app/Contents/MacOS/xulrunner Reason: image not found Please help me to resolve this issue. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Ehsan Akhgari wrote: On 2014-07-14, 9:50 AM, Byron Jones wrote: Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? how is that different from "not watching", which already exists? Doesn't "Not watching" also include "no relationship with the bug"? good point - file a bug please :) 3. Can we get a "All watched components" flag under Components? no, watching is your relationship with the bug, not a specific component. I'm talking about component watching here... ... i know :) component watching is the reason why you receive email, so it's covered by the 'relationship' filter. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
On 2014-07-14, 9:50 AM, Byron Jones wrote: Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? In the majority of cases I want the same thing to happen if I have any of these relationships to a bug. how is that different from "not watching", which already exists? Doesn't "Not watching" also include "no relationship with the bug"? 2. Can we get a field designating the creation of bugs, so that I can set things up so that I get bugmails for new bugs no matter what? one already exists, but i forgot to change the visible description to make it obvious. it's currently labeled as "bug id". bug 1036301. Ah thanks! 3. Can we get a "All watched components" flag under Components? That way I can set up my filters so that I get a bugmail for bugs created in all of my watched components in Core and also for when their status changes but for nothing else, except for a few components I care about more... no, watching is your relationship with the bug, not a specific component. I'm talking about component watching here... Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Great Documentation about Xray Wrappers
Hi All, I just wanted to call out the excellent documentation that Will Bamberg recently created about Xray vision, including the recently-landed "Xray To JS" wrappers that landed in Firefox 32: https://developer.mozilla.org/en-US/docs/Xray_vision If you've ever been confused about this stuff, this is a great resource for comprehending this complicated (and important) system. Cheers, bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
L. David Baron wrote: On Monday 2014-07-14 21:50 +0800, Byron Jones wrote: Ehsan Akhgari wrote: 2. Can we get a field designating the creation of bugs, so that I can set things up so that I get bugmails for new bugs no matter what? one already exists, but i forgot to change the visible description to make it obvious. it's currently labeled as "bug id". bug 1036301. Does this include when a bug was moved into a component? That's effectively a "new bug" case. (And if everybody who wants to see new bugs has to write a complex filter for it themselves, some are likely to get it wrong and miss moved bugs.) "bug id"/"bug created" won't match when a bug is moved into a component. you need to use "component" as the field that was changed to match those actions. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Philipp Kewisch wrote: On 7/14/14 8:13 AM, Byron Jones wrote: Now, I got a notification for bug 1038029 where Magnus added himself as CC and also added the "regression" keyword. No comment was added. Does it take some time until the filters are applied? Shouldn't the bugmail filter have filtered out this email? that's possibly bug 1036872 (an interaction between the normal email preferences and filters). if you still see that behaviour after that bug has been fixed and deployed don't hesitate to file a bug. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Philipp Kewisch wrote: Great work on this feature, I like it! I currently have an email filter to exclude some bugmail for which I am not sure its possible to use the new bugmail filtering feature. The rule is to only deliver Devtools bugmail if its a new bug, or I am explicitly on CC. If it were possible, I guess it would be a 3 part rule: 1. Exclude all devtools bugs 2. Include if relationship is CC'd 3. Include if ??? is "New" that looks along the right path. currently to include new bugs you have to select "bug id" from the field list. within 24 hours that will change to "bug created" (existing filters won't be impacted). -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
On Monday 2014-07-14 21:50 +0800, Byron Jones wrote: > Ehsan Akhgari wrote: > >2. Can we get a field designating the creation of bugs, so that I > >can set things up so that I get bugmails for new bugs no matter > >what? > one already exists, but i forgot to change the visible description > to make it obvious. it's currently labeled as "bug id". > bug 1036301. Does this include when a bug was moved into a component? That's effectively a "new bug" case. (And if everybody who wants to see new bugs has to write a complex filter for it themselves, some are likely to get it wrong and miss moved bugs.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MozHarness outside of loaners and releng network
Hello, There are some recent improvement to mozharness that helps running the jobs outside of tbpl and releng loaned machines: * Http authentication ** e.g. http authentication for pvtbuilds * Url substitutions ** Hit external reachable hosts instead of internal ones * Developer configs ** It allows overwriting production variables The wiki has been over-hauled with this info. [1] The improvements are also highlighted in here. [2][3] Best regards, Armen & Aki [1] https://wiki.mozilla.org/ReleaseEngineering/Mozharness/How_to_run_tests_as_a_developer [2] http://armenzg.blogspot.ca/2014/07/introducing-http-authentication-for.html [3] http://armenzg.blogspot.ca/2014/07/using-developer-configs-for-mozharness.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: webserial api
Ah, sorry for not being too straightforward Erik. The answer is no (as far as the API design goes, but the implementation should follow that ofc) There is actually a very nice image explaining this on our messageboard, but I'm on my phone so I'll do my best to explain this with a similar example. When you use a Mouse, the OS provides APIs for a mouse, independent of the connection type (ps2, Bluetooth, serial, USB or other). The OS & drivers make it show up as a mouse. Similarly, when you have a serial port (the OS recognizes this device as a serial port), the OS provides a set of APIs to talk to that (open, close, read & write), regardless of the underlying physical connection. The WebSerial API proposes the exposure of those APIs (but not the underlying ones, so no way to talk to the USB stack) to the web. I hope this makes things more clear? Vasilis > On 14 Jul 2014, at 16:46, Eric Rescorla wrote: > > > > >> On Mon, Jul 14, 2014 at 4:22 AM, wrote: >> On Monday, July 14, 2014 2:00:47 PM UTC+3, Gervase Markham wrote: >> > On 13/07/14 18:35, Vasilis wrote: >> > >> > > Jonas, I would be really interested in your thoughts. Try as we might >> > >> > > (in the WebSerial API docs, at least), noone could actually think of >> > >> > > a use case where providing access to a physical (RS232), or Virtual >> > >> > > (VirtualUSB or VirtualBluetooth) serial port could be a privacy >> > >> > > and/or security issue. >> > >> > > >> > >> > > It's a whole different beast when you provide access for cameras or >> > >> > > any USB device, of course, but what could someone do with access to a >> > >> > > serial port? >> > >> > >> > >> > The WebSerial interface doesn't cover the Universal Serial Bus, then? >> > >> > >> > >> > For USB, the OS has some underlying knowledge of what the device is, >> > >> > right? So we could do permissions for USB on a per-device rather than >> > >> > per-port basis, which is the right way to do it IMO. But AFAIK that's >> > >> > not possible for RS232. >> > >> > >> > >> > Gerv >> >> Which is the kind of exaggerated security for no real purpose that I >> mentioned. >> >> The three major OSes give you APIs to access any Serial-Port-like device >> (physical or virtual) in a straightforward manner, because, for all intents >> and purposes, those are Serial ports. Trying to go around this and map >> devices with ports ranges from hard (USB, Bluetooth) to impossible (RS232) > > I still don't think I understand your answer here. Will this API allow me to > directly address USB devices? To take a concrete case, say that I have > a USB printer, will I be able to use this API (subject to user consent) > to talk to it directly and print documentS? > > -Ekr > > >> I do agree with Kip, some Serial devices are important and/or dangerous, but >> do we really want to set the security of this based on the idea that someone >> from a government agency and/or industrial plan will use the power plant's >> controlling computer to: >> 1. Plug in a serial device, like an Arduino >> 2. Access the Internet >> 3. Go to a nefarious website >> 4. Give access to the PLC, and kaboom. >> >> Isn't that a little too much paranoia? Should we have restricted the Camera >> API because someone could have used it on a computer with a spycam, thus >> leaking goverment info and starting WW3? > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? In the majority of cases I want the same thing to happen if I have any of these relationships to a bug. how is that different from "not watching", which already exists? 2. Can we get a field designating the creation of bugs, so that I can set things up so that I get bugmails for new bugs no matter what? one already exists, but i forgot to change the visible description to make it obvious. it's currently labeled as "bug id". bug 1036301. 3. Can we get a "All watched components" flag under Components? That way I can set up my filters so that I get a bugmail for bugs created in all of my watched components in Core and also for when their status changes but for nothing else, except for a few components I care about more... no, watching is your relationship with the bug, not a specific component. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
On 14/07/2014 15:33, Ehsan Akhgari wrote: > 2. Can we get a field designating the creation of bugs, so that I can > set things up so that I get bugmails for new bugs no matter what? +1 for that. One thing I always do is check for new bugs in the components I'm watching and then CC me on those of interest. Only receiving successive messages for bugs I've explicitly CC'd me on would greatly reduce the amount of bugmail I have to go through every day while still allowing me to watch entire components for activity. Gabriele signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: webserial api
On Mon, Jul 14, 2014 at 4:22 AM, wrote: > On Monday, July 14, 2014 2:00:47 PM UTC+3, Gervase Markham wrote: > > On 13/07/14 18:35, Vasilis wrote: > > > > > Jonas, I would be really interested in your thoughts. Try as we might > > > > > (in the WebSerial API docs, at least), noone could actually think of > > > > > a use case where providing access to a physical (RS232), or Virtual > > > > > (VirtualUSB or VirtualBluetooth) serial port could be a privacy > > > > > and/or security issue. > > > > > > > > > > It's a whole different beast when you provide access for cameras or > > > > > any USB device, of course, but what could someone do with access to a > > > > > serial port? > > > > > > > > The WebSerial interface doesn't cover the Universal Serial Bus, then? > > > > > > > > For USB, the OS has some underlying knowledge of what the device is, > > > > right? So we could do permissions for USB on a per-device rather than > > > > per-port basis, which is the right way to do it IMO. But AFAIK that's > > > > not possible for RS232. > > > > > > > > Gerv > > Which is the kind of exaggerated security for no real purpose that I > mentioned. > > The three major OSes give you APIs to access any Serial-Port-like device > (physical or virtual) in a straightforward manner, because, for all intents > and purposes, those are Serial ports. Trying to go around this and map > devices with ports ranges from hard (USB, Bluetooth) to impossible (RS232) > I still don't think I understand your answer here. Will this API allow me to directly address USB devices? To take a concrete case, say that I have a USB printer, will I be able to use this API (subject to user consent) to talk to it directly and print documentS? -Ekr I do agree with Kip, some Serial devices are important and/or dangerous, > but do we really want to set the security of this based on the idea that > someone from a government agency and/or industrial plan will use the power > plant's controlling computer to: > 1. Plug in a serial device, like an Arduino > 2. Access the Internet > 3. Go to a nefarious website > 4. Give access to the PLC, and kaboom. > > Isn't that a little too much paranoia? Should we have restricted the > Camera API because someone could have used it on a computer with a spycam, > thus leaking goverment info and starting WW3? > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Great feature, Byron! I have three feature requests: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? In the majority of cases I want the same thing to happen if I have any of these relationships to a bug. 2. Can we get a field designating the creation of bugs, so that I can set things up so that I get bugmails for new bugs no matter what? 3. Can we get a "All watched components" flag under Components? That way I can set up my filters so that I get a bugmail for bugs created in all of my watched components in Core and also for when their status changes but for nothing else, except for a few components I care about more... Thanks! Ehsan On 2014-07-14, 2:13 AM, Byron Jones wrote: are you tired of receiving notifications from bugzilla that you simply don't care about? you can now tell bugzilla to stop clogging up your inbox with those pesky emails via "bugmail filtering". are you only interested in seeing new bugs and bug status changes in some components you are watching? set up a filter! or perhaps you only want to be informed about qa related changes on bug where you are the assignee? set up a filter! see http://globau.wordpress.com/2014/07/10/using-bugmail-filtering-to-exclude-notifications-you-dont-want/ for more details. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
On 7/14/14 8:13 AM, Byron Jones wrote: > are you tired of receiving notifications from bugzilla that you simply > don't care about? > > you can now tell bugzilla to stop clogging up your inbox with those > pesky emails via "bugmail filtering". I also entered a filter with the intent to ignore bugmail where just the CC was changed. I used these filters (for which I now realize they are not complete): * Exclude if Field CC changed * Include if Comment created Now, I got a notification for bug 1038029 where Magnus added himself as CC and also added the "regression" keyword. No comment was added. Does it take some time until the filters are applied? Shouldn't the bugmail filter have filtered out this email? If so, in addition to the above mentioned exclude rule, I would need to add an "include" filter for each possible field that might be changed, i.e. keyword, whiteboard, etc. Is there an easier way to do this? Thanks, Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: webserial api
On Monday, July 14, 2014 2:00:47 PM UTC+3, Gervase Markham wrote: > On 13/07/14 18:35, Vasilis wrote: > > > Jonas, I would be really interested in your thoughts. Try as we might > > > (in the WebSerial API docs, at least), noone could actually think of > > > a use case where providing access to a physical (RS232), or Virtual > > > (VirtualUSB or VirtualBluetooth) serial port could be a privacy > > > and/or security issue. > > > > > > It's a whole different beast when you provide access for cameras or > > > any USB device, of course, but what could someone do with access to a > > > serial port? > > > > The WebSerial interface doesn't cover the Universal Serial Bus, then? > > > > For USB, the OS has some underlying knowledge of what the device is, > > right? So we could do permissions for USB on a per-device rather than > > per-port basis, which is the right way to do it IMO. But AFAIK that's > > not possible for RS232. > > > > Gerv Which is the kind of exaggerated security for no real purpose that I mentioned. The three major OSes give you APIs to access any Serial-Port-like device (physical or virtual) in a straightforward manner, because, for all intents and purposes, those are Serial ports. Trying to go around this and map devices with ports ranges from hard (USB, Bluetooth) to impossible (RS232). I do agree with Kip, some Serial devices are important and/or dangerous, but do we really want to set the security of this based on the idea that someone from a government agency and/or industrial plan will use the power plant's controlling computer to: 1. Plug in a serial device, like an Arduino 2. Access the Internet 3. Go to a nefarious website 4. Give access to the PLC, and kaboom. Isn't that a little too much paranoia? Should we have restricted the Camera API because someone could have used it on a computer with a spycam, thus leaking goverment info and starting WW3? Vasilis ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: webserial api
On 13/07/14 18:35, tzi...@gmail.com wrote: > Jonas, I would be really interested in your thoughts. Try as we might > (in the WebSerial API docs, at least), noone could actually think of > a use case where providing access to a physical (RS232), or Virtual > (VirtualUSB or VirtualBluetooth) serial port could be a privacy > and/or security issue. > > It's a whole different beast when you provide access for cameras or > any USB device, of course, but what could someone do with access to a > serial port? The WebSerial interface doesn't cover the Universal Serial Bus, then? For USB, the OS has some underlying knowledge of what the device is, right? So we could do permissions for USB on a per-device rather than per-port basis, which is the right way to do it IMO. But AFAIK that's not possible for RS232. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
On 7/14/14 8:13 AM, Byron Jones wrote: > are you tired of receiving notifications from bugzilla that you simply > don't care about? > > you can now tell bugzilla to stop clogging up your inbox with those > pesky emails via "bugmail filtering". Great work on this feature, I like it! I currently have an email filter to exclude some bugmail for which I am not sure its possible to use the new bugmail filtering feature. The rule is to only deliver Devtools bugmail if its a new bug, or I am explicitly on CC. If it were possible, I guess it would be a 3 part rule: 1. Exclude all devtools bugs 2. Include if relationship is CC'd 3. Include if ??? is "New" Does it maybe work with including bugmail when the creation date changed? Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
