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?
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 +
> @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 220.127.116.11/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
ppc64: *ping* (blocks 3 bugs...)
Marked ppc64 stable, closing since we're the last arch.