clone 413964 -1 reassign -1 pcmanx-gtk2 severity -1 important severity 414106 important clone 413964 -2 reassign 413964 xulrunner severity -2 important thanks
On Fri, Mar 09, 2007 at 07:38:12AM +0100, Mike Hommey <[EMAIL PROTECTED]> wrote: > On Thu, Mar 08, 2007 at 11:26:59PM +0100, Marc 'HE' Brockschmidt <[EMAIL > PROTECTED]> wrote: > > Mike Hommey <[EMAIL PROTECTED]> writes: > > > On Thu, Mar 08, 2007 at 01:07:53PM -0800, Steve Langasek <[EMAIL > > > PROTECTED]> wrote: > > >> On Thu, Mar 08, 2007 at 01:37:49PM +0100, Mike Hommey wrote: > > >>> If the gcj plugin is making use of xpcom, it should require > > >>> xulrunner-xpcom > > >>> too. > > >>> See https://bugzilla.mozilla.org/show_bug.cgi?id=366113#c8 > > >> Still, this is an 11th-hour regression introduced by the new xulrunner, > > >> AFAICS. Even if the "bug" belongs to gcj-4.1, this change in xulrunner's > > >> behavior is grounds for not letting the new xulrunner into etch. > > >> Security > > >> updates need to not break related packages. > > > So what ? Better "fixing" xulrunner than gcj-4.1 ? This gets ridiculous. > > > > At this time, we don't know which other third-party application rely on > > this specific xulrunner configuration, and I really don't want to risk > > to break anything else. It's easier to revert this change for xulrunner > > now instead of testing every possible r-dep. > > I checked all reverse dependencies that use the -plugin pkg-config file. > Only gcj-4.1 and classpath are affected. Okay, my checker script was not done with its work yet, pcmanx-gtk2 is also affected. Let's put all these detected issue as important and fix it in xulrunner. I'll do it as soon as I know if #414008 is due to some utter wreckage or not. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
