[bcc to ben and david again... sorry, don't normally do this] On Fri, Mar 2, 2012 at 6:06 PM, Benjamin Smedberg <[email protected]> wrote: > On 3/2/2012 12:37 PM, lkcl luke wrote: >> >> ok, then i have a proposal for you. would the mozilla foundation >> agree to *stall* releases of xulrunner if there are outstanding >> pyxpcom and hulahop bugs? > > No. But since we release every 6 weeks, you can always wait a release and > pick up the next one with your bugs fixed (assuming there is someone who can > fix them).
that's the thing: no we can't settle for that, because *any* release which goes out the door - and turns out not to work - could potentially end up in a gnu/linux distro. what's the chances of us being able to ask every single gnu/linux distro in the world - even nicely - "please could you not use that version of xulrunner, because, um, it doesn't work with hulahop but just so happens to work with firefox"? i asked mike (debian's mozilla maintainer) just that - one gnu/linux distro - and he didn't exactly go "pffh" but he very politely said words to the effect of "er that's a no?" :) we have people who use pyjamas-desktop on debian, ubuntu, arch-linux, fedora (and even a few brave souls who are serious about getting pythonwebkit compiled on macosx for goodness sake) the other alternative is that if i find a bug, and it gets fixed, that you guys promise to do a major sub-point-release of that (potentially older) version, which would be enough to trigger the gnu/linux distros to do an update. eventually. so, for example: we know that there's a segfault in 10.0.2 - something related to window focus, which i've just now found is fixed in the revision located below, see celebration :) if the bug's tracked down, would you do a major release 10.0.3 which would trigger debian etc. to package it? >> because that bug was relevant in (at least) xulrunner 10.0.2 but >> haven't been able to check it's still relevant for 13.0a1, because of >> the bug which is causing segfaults even in calling XRE_InitEmbedding2! > > As noted, this appears to be a bug somewhere in the linkage setup, which is > pretty obscure in general. The "standard" setup is that the embedding binary > statically links against jemalloc (so that it interposes its symbols > correctly). It may work to link jemalloc/mozutils against your binary. If > that's not feasible, then we have a potential range of bugs where > mozilla-with-jemalloc works correctly but mozilla-embedded-without-jemalloc > doesn't, and somebody would have to trace down and fix this issues. I'm not > sure whether that's important enough that I would harass core contributors > to do it right now, but I am pretty sure that if you wrote a simple testcase > which just calls XRE_InitEmbedding2 (without the statically linked jemalloc) > which we could run as automated tests, I'd take it so that this doesn't > break again. HAAAA! i finally have a back-dated (recent) build which works. commit 4d3b4bb2a588442474a80c164237392ea7802220 Author: Brian Smith <[email protected]> Date: Mon Feb 13 16:18:28 2012 -0800 Bug 713934: Update SetCertVerificationResult to use SSL_AuthCertificateCompl what i can now do is do a binary search, from there, to track down the commit pairs that work/don't work. corr, *relief*. it'll take me about 48 hours to go through the builds - there's 500 commits since 13feb2012 so i'll need.... 2^9 ... maybe 9 checkouts to track it down. l.
