Hi,
thanks Wes!
taking over now and cleaning up the trees the sheriffed repos and will do
backouts as needed.
- Tomcat
On Tue, Jul 19, 2016 at 4:05 AM, Wes Kocher wrote:
> The Treeherder devs have deployed a hotfix that appears to have fixed up
> the responsiveness issues, so I've reopened th
The Treeherder devs have deployed a hotfix that appears to have fixed up
the responsiveness issues, so I've reopened the trees.
On Mon, Jul 18, 2016 at 5:05 PM, Wes Kocher wrote:
>
> The DB issues that popped back up again from bug 1286942 have been
> resolved, and all non-trunk trees have been
The DB issues that popped back up again from bug 1286942 have been
resolved, and all non-trunk trees have been reopened.
Treeherder responsiveness has been an issue all day (bug 1287501), which is
keeping the trunk trees closed, since I can't easily tell if jobs are
broken. The responsiveness issu
On Mon, Jul 18, 2016 at 03:50:38PM -0700, Justin Dolske wrote:
> On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote:
>
> >
> > The second point sort of solves them both. As part of making things
> > verifiable, Mozilla could publish a program that makes byte by byte
> > comparison only on files
The "Cookie prefix" adds restrictions to how cookies with two specific
prefixes may be used. This addresses some of the Weak Confidentiality and
Weak Integrity concerns noted by RFC 6265 (
https://tools.ietf.org/html/rfc6265#section-8.5).
Cookies whose names start with "__Secure-" or "__Host-" mus
On Sun, Jul 17, 2016 at 09:38:31AM -0700, David Bruant wrote:
> Out of curiosity, how has is the TOR team handled points 1 and 2?
I cannot answer for TOR, but I can answer for Debian, who also does
reproducible builds of Firefox.
1) is not addressed at all, and while the Firefox package is marked
On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote:
>
> The second point sort of solves them both. As part of making things
> verifiable, Mozilla could publish a program that makes byte by byte
> comparison only on files that matters after unzip. If they're not that
> important, .chk files could
On 2016-07-18 2:56 PM, Gregory Szorc wrote:
> A significant obstacle to even comparable builds is "private" data embedded
> within Firefox. e.g. Google API Keys. I /think/ we're also shipping some
> DRM blobs. Then of course there is build signing, which takes a private key
> and cryptographically
Le lundi 18 juillet 2016 20:57:12 UTC+2, Gregory Szorc a écrit :
> On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote:
>
> We already have deterministic packaging in some parts of Firefox (notably
> most XPIs and omni.ja files). We've done this by implementing our own
> jar/zip archiving layer (
Additional DB issues have popped up today, so trees are again closed. We
are re-using bug 1286942 as the tracking bug.
On Fri, Jul 15, 2016 at 2:59 AM, Carsten Book wrote:
> Hi,
>
> we currently have a complete tree closure due to Buildbot DB Issues.
>
> The Teams working on resolving this issue
Yes. Moreover, they are sandboxed at runtime. So modulo bugs in the
sandboxing layer, we can treat those blobs as adversarial and the integrity
of Firefox shouldn't depend on the integrity of those blobs.
On Mon, Jul 18, 2016 at 12:04 PM, Chris Peterson
wrote:
> On 7/18/16 11:56 AM, Gregory Szor
On 7/18/16 11:56 AM, Gregory Szorc wrote:
A significant obstacle to even comparable builds is "private" data embedded
within Firefox. e.g. Google API Keys. I /think/ we're also shipping some
DRM blobs.
Mozilla does not ship any DRM blobs with Firefox. The Adobe Primetime
and Google Widevine CD
On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote:
> Hi,
>
> Two recent comments on the Linux reproducible build bug thread [1] suggest
> that the bug has no clear end goal.
>
> In this email, I'll try to describe what I understand of the problem and
> discuss the outline of a possible end goa
It warms the cockles of my heart to see people adding to the GDB
pretty-printers. :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
https://bugzilla.mozilla.org/show_bug.cgi?id=1286467 has landed, so if
you have the following in your .gdbinit:
add-auto-load-safe-path ~/some/parent/dir/of/where/you/keep/gecko
You're now going to see stuff like the following for a hashtable with
entries:
mRegistrationInfos = nsClassHashtabl
Hello,
Treeherder sends a Pulse messages to add new jobs to your pushes. Those
messages are currently not arriving, thus, the system won't work.
If you want to know when it gets fixed you can follow this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1287404
Our apologies for any inconvenie
On Fri, Jul 15, 2016 at 3:34 AM, Kurt Roeckx wrote:
> I also wonder how this fallback thing works. Things are linked to the
> pulseaudio library, but if the pulseaudio binary isn't installed things fall
> back to something else like alsa as far as I know. Is this something the
> pulseaudio libr
You've got great timing, support for --enable-jack just landed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ab76338931e
-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
Team last week, *July 11 - July 15* (week 28).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org/p/Des
Thank you, Xidorn (and of course, arai-san). I'm really happy to test
IME with non-e10s mode!!
On 2016/07/17 22:48, Xidorn Quan wrote:
Hi,
In bug 1287069 (https://bugzil.la/1287069), I just landed a new command
line argument, --disable-e10s, to |mach run|. As its name indicates, it
would run t
On 2016-07-17 18:38, David Bruant wrote:
2) Timestamps of the files inside the .tar.bz2 package will differ, but
untarring them and using a recursive diff will reveal no differences (except
for the aforementioned .chk files)
The second point sort of solves them both. As part of making things
21 matches
Mail list logo
