Please stabilize so we can get firefox/xulrunner security bugs handled please. Already discussed with nirbheek for the go ahead.
Only dep that has to be stabilized is >=sqlite-3.5 if you arch is already stable please stabilize. Report any issues directly to this bug for tracking purposes please.
Why is this bug *depending* on two security bugs? Shouldn't it be depending on bug 280839?
x86 stable
Why stabilizing separately from firefox-3.5.x, if the intention is to stabilize that? If firefox will follow much later, nevermind. But if soon, then doing nspr earlier means users having to run revdep-rebuild now and get many rebuild, including a big xulrunner rebuild, only to soon be rebuilding xulrunner anyway for a version upgrade
(In reply to comment #4) Not to mention that we might get untested build failures with nspr-4.8 + mozilla-firefox-3.0* @Anarchy: I can't find the firefox stabilization bug? It should be stabilized at the same time as nspr-4.8 (right afterwards ie)
(In reply to comment #5) > (In reply to comment #4) > > Not to mention that we might get untested build failures with nspr-4.8 + > mozilla-firefox-3.0* > > @Anarchy: I can't find the firefox stabilization bug? It should be stabilized > at the same time as nspr-4.8 (right afterwards ie) > Nirbheek feel free to open I was gonna let craig a security padawan take and add all archs for xulrunner/firefox 1.9.1.1/3.5.x to the security bug. These were really meant as a mean to track breakage on archs.
Stable for ppc (bug 280393 is now about 3.5.* stabilization)
Stable for HPPA.
Compile tested on alpha. I don't know how to test it otherwise.
why is m68k here? and mips doesn't do stable keywords
amd64 stable
alpha/arm/ia64/sparc stable
ppc64: *ping* (blocks 3 bugs...)
Marked ppc64 stable, closing since we're the last arch.