Re: Bug#413964: xulrunner: Broken xulrunner-plugin.pc causes gcj-4.1 to FTBFS

[Mike Hommey <mh@glandium.org>]

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 <mh@glandium.org> wrote:
> On Thu, Mar 08, 2007 at 11:26:59PM +0100, Marc 'HE' Brockschmidt <he@ftwca.de> wrote:
> > Mike Hommey <mh@glandium.org> writes:
> > > On Thu, Mar 08, 2007 at 01:07:53PM -0800, Steve Langasek <vorlon@debian.org> 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