Debian Bug report logs - #449448
Please package xulrunner 1.9 in the upstream way

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: submit@bugs.debian.org

Subject: Please package xulrunner 1.9 in the upstream way

Date: Mon, 5 Nov 2007 21:27:32 +0100

Package: xulrunner
Severity: wishlist

It would be beneficial to unify how xulrunner is packaged across linux
distributions.

Since upstream is unlikely to adapt the debian way of shipping
xulrunner for various reasons, we should follow their idea on how to
ship xulrunner.

A package that could be used is available in ubuntu and can be found
at:

https://launchpad.net/ubuntu/+source/xulrunner-1.9

Thanks for considering this,

 - Alexander

Message #10 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Alexander Sack <asac@jwsdot.com>, 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Mon, 5 Nov 2007 21:50:53 +0100

On Mon, Nov 05, 2007 at 09:27:32PM +0100, Alexander Sack wrote:
> Package: xulrunner
> Severity: wishlist
> 
> It would be beneficial to unify how xulrunner is packaged across linux
> distributions.
> 
> Since upstream is unlikely to adapt the debian way of shipping
> xulrunner for various reasons, we should follow their idea on how to
> ship xulrunner.

What is their idea on how to ship xulrunner ?

Mike

Message #15 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: Mike Hommey <mh@glandium.org>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Mon, 5 Nov 2007 21:58:17 +0100

On Mon, Nov 05, 2007 at 09:50:53PM +0100, Mike Hommey wrote:
> On Mon, Nov 05, 2007 at 09:27:32PM +0100, Alexander Sack wrote:
> > Package: xulrunner
> > Severity: wishlist
> > 
> > It would be beneficial to unify how xulrunner is packaged across linux
> > distributions.
> > 
> > Since upstream is unlikely to adapt the debian way of shipping
> > xulrunner for various reasons, we should follow their idea on how to
> > ship xulrunner.
> 
> What is their idea on how to ship xulrunner ?

Like the ubuntu package does it ... just a plain runner in
/usr/lib/xulrunner-VERSION + an sdk which we currently ship in
/usr/lib/xulrunner-devel-1.9a8/ using static glue et al ... you
probably know the details.

We have build firefox-3.0 on top of that ... you can take a look at 

   https://launchpad.net/ubuntu/+source/firefox-3.0/


 - Alexander

Message #20 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Alexander Sack <asac@jwsdot.com>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Tue, 6 Nov 2007 07:18:54 +0100

On Mon, Nov 05, 2007 at 09:58:17PM +0100, Alexander Sack wrote:
> On Mon, Nov 05, 2007 at 09:50:53PM +0100, Mike Hommey wrote:
> > On Mon, Nov 05, 2007 at 09:27:32PM +0100, Alexander Sack wrote:
> > > Package: xulrunner
> > > Severity: wishlist
> > > 
> > > It would be beneficial to unify how xulrunner is packaged across linux
> > > distributions.
> > > 
> > > Since upstream is unlikely to adapt the debian way of shipping
> > > xulrunner for various reasons, we should follow their idea on how to
> > > ship xulrunner.
> > 
> > What is their idea on how to ship xulrunner ?
> 
> Like the ubuntu package does it ... just a plain runner in
> /usr/lib/xulrunner-VERSION + an sdk which we currently ship in
> /usr/lib/xulrunner-devel-1.9a8/ using static glue et al ... you
> probably know the details.

There is no way we're going to use a static glue for embedding
applications.
And I'm not really convinced by the -VERSION thing.

Mike

Message #25 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: Mike Hommey <mh@glandium.org>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Tue, 6 Nov 2007 15:47:17 +0100

On Tue, Nov 06, 2007 at 07:18:54AM +0100, Mike Hommey wrote:
> On Mon, Nov 05, 2007 at 09:58:17PM +0100, Alexander Sack wrote:
> > On Mon, Nov 05, 2007 at 09:50:53PM +0100, Mike Hommey wrote:
> > > On Mon, Nov 05, 2007 at 09:27:32PM +0100, Alexander Sack wrote:
> > > > Package: xulrunner
> > > > Severity: wishlist
> > > > 
> > > > It would be beneficial to unify how xulrunner is packaged across linux
> > > > distributions.
> > > > 
> > > > Since upstream is unlikely to adapt the debian way of shipping
> > > > xulrunner for various reasons, we should follow their idea on how to
> > > > ship xulrunner.
> > > 
> > > What is their idea on how to ship xulrunner ?
> > 
> > Like the ubuntu package does it ... just a plain runner in
> > /usr/lib/xulrunner-VERSION + an sdk which we currently ship in
> > /usr/lib/xulrunner-devel-1.9a8/ using static glue et al ... you
> > probably know the details.
> 
> There is no way we're going to use a static glue for embedding
> applications.
> And I'm not really convinced by the -VERSION thing.
> 

Why? works pretty well from what i have seen so far.

 - Alexander

Message #30 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Alexander Sack <asac@jwsdot.com>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Tue, 6 Nov 2007 19:30:06 +0100

On Tue, Nov 06, 2007 at 03:47:17PM +0100, Alexander Sack wrote:
> On Tue, Nov 06, 2007 at 07:18:54AM +0100, Mike Hommey wrote:
> > On Mon, Nov 05, 2007 at 09:58:17PM +0100, Alexander Sack wrote:
> > > On Mon, Nov 05, 2007 at 09:50:53PM +0100, Mike Hommey wrote:
> > > > On Mon, Nov 05, 2007 at 09:27:32PM +0100, Alexander Sack wrote:
> > > > > Package: xulrunner
> > > > > Severity: wishlist
> > > > > 
> > > > > It would be beneficial to unify how xulrunner is packaged across linux
> > > > > distributions.
> > > > > 
> > > > > Since upstream is unlikely to adapt the debian way of shipping
> > > > > xulrunner for various reasons, we should follow their idea on how to
> > > > > ship xulrunner.
> > > > 
> > > > What is their idea on how to ship xulrunner ?
> > > 
> > > Like the ubuntu package does it ... just a plain runner in
> > > /usr/lib/xulrunner-VERSION + an sdk which we currently ship in
> > > /usr/lib/xulrunner-devel-1.9a8/ using static glue et al ... you
> > > probably know the details.
> > 
> > There is no way we're going to use a static glue for embedding
> > applications.
> > And I'm not really convinced by the -VERSION thing.
> > 
> 
> Why? works pretty well from what i have seen so far.

What does work pretty well ? the -VERSION thing ? It's not about working
or not, it's about the fact we're only shipping one version at a time.
What is the usefulness of the -VERSION for us ? If people want to
install an upstream, they obviously won't put it in /usr/lib/xulrunner,
so it's not a problem to use it. Moreover, if they want to install an
upstream version, they are likely to want to put it in
/usr/lib/xulrunner-VERSION, and THEN there will be a problem because
some other package would depend on THAT being the debian version...

If you're talking about the static glue, it's not about it working or
not, it's about the fact that if it's statically compiled, we'd have to
have all reverse dependencies buildNMUed if there happens to be issues
with the glue. That's bad.

Mike

Message #35 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: Mike Hommey <mh@glandium.org>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Wed, 12 Dec 2007 13:31:56 +0100

On Tue, Nov 06, 2007 at 07:30:06PM +0100, Mike Hommey wrote:
> On Tue, Nov 06, 2007 at 03:47:17PM +0100, Alexander Sack wrote:
> > On Tue, Nov 06, 2007 at 07:18:54AM +0100, Mike Hommey wrote:
> > > On Mon, Nov 05, 2007 at 09:58:17PM +0100, Alexander Sack wrote:
> > > > On Mon, Nov 05, 2007 at 09:50:53PM +0100, Mike Hommey wrote:
> > > > > On Mon, Nov 05, 2007 at 09:27:32PM +0100, Alexander Sack wrote:
> > > > > > Package: xulrunner
> > > > > > Severity: wishlist
> > > > > > 
> > > > > > It would be beneficial to unify how xulrunner is packaged across linux
> > > > > > distributions.
> > > > > > 
> > > > > > Since upstream is unlikely to adapt the debian way of shipping
> > > > > > xulrunner for various reasons, we should follow their idea on how to
> > > > > > ship xulrunner.
> > > > > 
> > > > > What is their idea on how to ship xulrunner ?
> > > > 
> > > > Like the ubuntu package does it ... just a plain runner in
> > > > /usr/lib/xulrunner-VERSION + an sdk which we currently ship in
> > > > /usr/lib/xulrunner-devel-1.9a8/ using static glue et al ... you
> > > > probably know the details.
> > > 
> > > There is no way we're going to use a static glue for embedding
> > > applications.
> > > And I'm not really convinced by the -VERSION thing.
> > > 
> > 
> > Why? works pretty well from what i have seen so far.
> 
> What does work pretty well ? the -VERSION thing ? It's not about working
> or not, it's about the fact we're only shipping one version at a time.
> What is the usefulness of the -VERSION for us ? If people want to
> install an upstream, they obviously won't put it in /usr/lib/xulrunner,
> so it's not a problem to use it. Moreover, if they want to install an
> upstream version, they are likely to want to put it in
> /usr/lib/xulrunner-VERSION, and THEN there will be a problem because
> some other package would depend on THAT being the debian version...
> 
> If you're talking about the static glue, it's not about it working or
> not, it's about the fact that if it's statically compiled, we'd have to
> have all reverse dependencies buildNMUed if there happens to be issues
> with the glue. That's bad.
> 

How about shipping like ubuntu, and then switching to a shared glue,
once you have a suitable patch? We could even upload as xulrunner-1.9
so the transition could take some time. But having something in sid
now would be beneficial imo.

For the question about the versioned pkglibdir ... why do you want to
drop the versioning from the pkglibdir? I mean, usually one shouldn't
ask: why to not diverge from upstream, but instead review the
arguments that led to the current diff. Given that -rpath linking
isn't the way to go anymore, I don't see any benefit out of shipping
a non-versioned dir.

 - Alexander

Message #40 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Alexander Sack <asac@jwsdot.com>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Wed, 12 Dec 2007 22:08:06 +0100

On Wed, Dec 12, 2007 at 01:31:56PM +0100, Alexander Sack wrote:
> How about shipping like ubuntu, and then switching to a shared glue,
> once you have a suitable patch? We could even upload as xulrunner-1.9
> so the transition could take some time. But having something in sid
> now would be beneficial imo.

It wouldn't be beneficial because it wouldn't be useable by any reverse
dependency. And it wouldn't build on a lot of architectures, and lacks a
whole bunch of patches we apply for good reasons. If it's only about
having a running xulrunner 1.9 for people that want it, they can take
nightly builds on mozilla.org.

> For the question about the versioned pkglibdir ... why do you want to
> drop the versioning from the pkglibdir? I mean, usually one shouldn't
> ask: why to not diverge from upstream, but instead review the
> arguments that led to the current diff. Given that -rpath linking
> isn't the way to go anymore, I don't see any benefit out of shipping
> a non-versioned dir.

Off the top of my head, this has at least these benefits:
- Allow other packages to reliably put files at the correct place (think
  extensions, plugins, or even diversions)
- Smoother upgrades
- Allows users to actually install mozilla.org's versions without
  overwriting ours !

And we only ship one xulrunner at a time anyways.

Now, the thing that is pissing me off is that while they actually did
what they told, and dropped gtkmozembed in favour of having embedders
use the xpcom glue and have it dlload libxul.so, their applications
(firefox, etc.) are *not* embedders, and *do* link against libxul.so.
If we want to link these applications properly, and have the
dependencies properly handled by dpkg, I guess we won't have much
choice, though using the new symbols feature of dpkg-shlibdeps, it is
possible to have the build dependencies right even without a SOVERSION.
The problem with this is that backports won't be possible.

Mike

Message #45 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: Mike Hommey <mh@glandium.org>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Thu, 13 Dec 2007 12:16:48 +0100

On Wed, Dec 12, 2007 at 10:08:06PM +0100, Mike Hommey wrote:
> On Wed, Dec 12, 2007 at 01:31:56PM +0100, Alexander Sack wrote:
> > How about shipping like ubuntu, and then switching to a shared glue,
> > once you have a suitable patch? We could even upload as xulrunner-1.9
> > so the transition could take some time. But having something in sid
> > now would be beneficial imo.
> 
> It wouldn't be beneficial because it wouldn't be useable by any reverse
> dependency. And it wouldn't build on a lot of architectures, and lacks a
> whole bunch of patches we apply for good reasons. If it's only about
> having a running xulrunner 1.9 for people that want it, they can take
> nightly builds on mozilla.org.

The fixes for the archs need adaption anyway.

And from what I know, in debian you usually don't get all archs built
with the first upload anyway, and the maintainer probably cannot/does
not want to fix the rare archs on its own. So uploading now without
those patches is beneficial and it allows porters start to work on the
patches _now_ and not after the release. ATM, there is still time to
get things into upstream tree without much hazzles.

Anyway, what are the patches you want want to see ported to
xulrunner-1.9 (without the archs of course)?

> 
> > For the question about the versioned pkglibdir ... why do you want to
> > drop the versioning from the pkglibdir? I mean, usually one shouldn't
> > ask: why to not diverge from upstream, but instead review the
> > arguments that led to the current diff. Given that -rpath linking
> > isn't the way to go anymore, I don't see any benefit out of shipping
> > a non-versioned dir.
> 
> Off the top of my head, this has at least these benefits:
> - Allow other packages to reliably put files at the correct place (think
>   extensions, plugins, or even diversions)

we provide stable directories for those parts of xulrunner/firefox
that allow packagers to drop something in: for now its
/usr/lib/xulrunner-addons/[plugins,extensions] and the same for
firefox-addons.

> - Smoother upgrades

I don't get this ... replacing files underneath a running application
rarely did any good on upgrades either.

> - Allows users to actually install mozilla.org's versions without
>   overwriting ours !
> 

Well, users must not install it in /usr/, but rather /usr/local/ or
somewhere else. So this point isn't valid.

> And we only ship one xulrunner at a time anyways.

For now this might be true, but you could also allow smoother
transitions to new versions if you would allow xulrunner and
xulrunner-1.9 (and next time xulrunner-1.9.1) to reside on the same
machine for some time. (like what we do in ubunt atm: migrate rdepends
one by one from firefox/xulrunner to xulrunner-1.9 without breaking
the rest). This takes some pressure of the packager to come up with
patches for all at once and allows you to release-early and often.

Why do you think this is a bad thing?

> 
> Now, the thing that is pissing me off is that while they actually did
> what they told, and dropped gtkmozembed in favour of having embedders
> use the xpcom glue and have it dlload libxul.so, their applications
> (firefox, etc.) are *not* embedders, and *do* link against
> libxul.so.

Their applications use the dependent glue, because they get loaded in
a running xpcom environment (but i guess you know that).

But why does it matter? Embedders can either choose to ramp up their
own xpcom through the standalone glue ... or can decide to be run as a
xulapp using the dependent glue (e.g. linking against libxul).

For the rdepends, we have a set of patches already. Those are not yet
complete, but will eventually go upstream. So once this is sorted out
there won't be any issue. Instead things will have improved, because
all this MOZILLA_FIVE_HOME and rpath mess is gone once and forever.

(While it would have been nice to be able to just recompile, it had to
happen at some point anyways. So lets do the transition of the
rdepends to use the glue now and help upstream to properly use it
... and things will be better.)

> If we want to link these applications properly, and have the
> dependencies properly handled by dpkg, I guess we won't have much
> choice, though using the new symbols feature of dpkg-shlibdeps, it is
> possible to have the build dependencies right even without a SOVERSION.
> The problem with this is that backports won't be possible.

yes, while i don't see a big problem requiring embedders to explicitly
depend on xulrunner-1.9, I see that we could improve the dpkg
integration. Using dpkg-shlibdeps would be a choice, yes.

 - Alexander

Message #50 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Alexander Sack <asac@jwsdot.com>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Thu, 13 Dec 2007 12:54:57 +0100

On Thu, Dec 13, 2007 at 12:16:48PM +0100, Alexander Sack <asac@jwsdot.com> wrote:
> yes, while i don't see a big problem requiring embedders to explicitly
> depend on xulrunner-1.9, I see that we could improve the dpkg
> integration. Using dpkg-shlibdeps would be a choice, yes.

This is how it used to be with the mozilla package, and we all know how
big a fiasco this was. I'm not going to agree to have that again.

Mike

Message #55 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: Mike Hommey <mh@glandium.org>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Thu, 13 Dec 2007 14:18:18 +0100

On Thu, Dec 13, 2007 at 12:54:57PM +0100, Mike Hommey wrote:
> On Thu, Dec 13, 2007 at 12:16:48PM +0100, Alexander Sack <asac@jwsdot.com> wrote:
> > yes, while i don't see a big problem requiring embedders to explicitly
> > depend on xulrunner-1.9, I see that we could improve the dpkg
> > integration. Using dpkg-shlibdeps would be a choice, yes.
> 
> This is how it used to be with the mozilla package, and we all know how
> big a fiasco this was. I'm not going to agree to have that again.
> 

Which fiasco do you refer to? Did people forget to add a
Depends? I doubt that this was the main deficiency of the bad old
mozilla package ...

From what I know the problem was rather the need to specify
LD_LIBRARY_PATH and link with rpath, which you mastered by shipping
the libs in /usr/lib/ ... which, btw, was a great thing to do for
1.8. However since people now need to use the glue anyway maintaining
this isn't needed anymore and we should try to get back to upstream
layout (which is what this bug is all about).

So what are your plans? Maintain the lib split and fork away or going
the "shared glue (if possible) way" + upstream directory layout?

 - Alexander

Message #60 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: Mike Hommey <mh@glandium.org>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: Please package xulrunner 1.9 in the upstream way

Date: Thu, 13 Dec 2007 14:21:06 +0100

On Thu, Dec 13, 2007 at 12:54:57PM +0100, Mike Hommey wrote:
> On Thu, Dec 13, 2007 at 12:16:48PM +0100, Alexander Sack <asac@jwsdot.com> wrote:
> > yes, while i don't see a big problem requiring embedders to explicitly
> > depend on xulrunner-1.9, I see that we could improve the dpkg
> > integration. Using dpkg-shlibdeps would be a choice, yes.
> 
> This is how it used to be with the mozilla package, and we all know how
> big a fiasco this was. I'm not going to agree to have that again.
> 

Oh, I forgot ... if you package just the glue in a shared lib ... and
keep the rest as it is, you won't have any problems with
dpkg-shlibdeps. Is that good enough?

 - Alexander

Message #65 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <glandium@debian.org>

To: control@bugs.debian.org

Cc: 363159@bugs.debian.org, 391024@bugs.debian.org, 404759@bugs.debian.org, 425233@bugs.debian.org, 441059@bugs.debian.org, 449448@bugs.debian.org

Subject: setting package to python-xpcom xulrunner-dev-static xulrunner-1.9 libmozjs1d libmozillainterfaces-java libmozjs1d-dbg xulrunner xulrunner-dev xulrunner-1.9-dbg libmozjs-dev xulrunner-1.9-common libxpcomglue0d spidermonkey-bin xulrunner-1.9-gnome-support ...

Date: Sat, 05 Apr 2008 10:49:39 +0200

# Automatically generated email from bts, devscripts version 2.10.20
#
# xulrunner (1.9~b4-1) UNRELEASED; urgency=low
#
#  * New upstream beta release (taken from upstream CVS). Closes: #449448.
#    + Don't crash when font file is unreadable. Closes: #425233.
#    + Better rendering of some extreme conditions. Closes: #391024.
#    + MOZILLA_1_8_BRANCH is not defined anymore: Closes: #441059.
#    + Don't jump when clicking out of the search bar. Closes: #404759.
#    + Ligatures don't overlap the following glyph. Closes: #363159.
#

package python-xpcom xulrunner-dev-static xulrunner-1.9 libmozjs1d libmozillainterfaces-java libmozjs1d-dbg xulrunner xulrunner-dev xulrunner-1.9-dbg libmozjs-dev xulrunner-1.9-common libxpcomglue0d spidermonkey-bin xulrunner-1.9-gnome-support
tags 425233 + pending
tags 363159 + pending
tags 441059 + pending
tags 449448 + pending
tags 391024 + pending
tags 404759 + pending

Message #72 received at 449448-close@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <glandium@debian.org>

To: 449448-close@bugs.debian.org

Subject: Bug#449448: fixed in xulrunner 1.9~b4-1

Date: Sun, 06 Apr 2008 17:21:27 +0000

Source: xulrunner
Source-Version: 1.9~b4-1

We believe that the bug you reported is fixed in the latest version of
xulrunner, which is due to be installed in the Debian FTP archive:

libmozillainterfaces-java_1.9~b4-1_all.deb
  to pool/main/x/xulrunner/libmozillainterfaces-java_1.9~b4-1_all.deb
libmozjs-dev_1.9~b4-1_all.deb
  to pool/main/x/xulrunner/libmozjs-dev_1.9~b4-1_all.deb
libmozjs1d-dbg_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/libmozjs1d-dbg_1.9~b4-1_amd64.deb
libmozjs1d_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/libmozjs1d_1.9~b4-1_amd64.deb
libxpcomglue0d_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/libxpcomglue0d_1.9~b4-1_amd64.deb
python-xpcom_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/python-xpcom_1.9~b4-1_amd64.deb
spidermonkey-bin_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/spidermonkey-bin_1.9~b4-1_amd64.deb
xulrunner-1.9-common_1.9~b4-1_all.deb
  to pool/main/x/xulrunner/xulrunner-1.9-common_1.9~b4-1_all.deb
xulrunner-1.9-dbg_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/xulrunner-1.9-dbg_1.9~b4-1_amd64.deb
xulrunner-1.9-gnome-support_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/xulrunner-1.9-gnome-support_1.9~b4-1_amd64.deb
xulrunner-1.9_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/xulrunner-1.9_1.9~b4-1_amd64.deb
xulrunner-dev-static_1.9~b4-1_amd64.deb
  to pool/main/x/xulrunner/xulrunner-dev-static_1.9~b4-1_amd64.deb
xulrunner-dev_1.9~b4-1_all.deb
  to pool/main/x/xulrunner/xulrunner-dev_1.9~b4-1_all.deb
xulrunner_1.9~b4-1.diff.gz
  to pool/main/x/xulrunner/xulrunner_1.9~b4-1.diff.gz
xulrunner_1.9~b4-1.dsc
  to pool/main/x/xulrunner/xulrunner_1.9~b4-1.dsc
xulrunner_1.9~b4.orig.tar.gz
  to pool/main/x/xulrunner/xulrunner_1.9~b4.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 449448@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mike Hommey <glandium@debian.org> (supplier of updated xulrunner package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 06 Apr 2008 13:01:04 +0200
Source: xulrunner
Binary: xulrunner-1.9 xulrunner-1.9-gnome-support libmozjs1d libmozjs-dev libmozjs1d-dbg spidermonkey-bin libxpcomglue0d xulrunner-1.9-common xulrunner-dev xulrunner-dev-static xulrunner-1.9-dbg libmozillainterfaces-java python-xpcom
Architecture: source all amd64
Version: 1.9~b4-1
Distribution: experimental
Urgency: low
Maintainer: Mike Hommey <glandium@debian.org>
Changed-By: Mike Hommey <glandium@debian.org>
Description: 
 libmozillainterfaces-java - XPCOM bindings for Java
 libmozjs-dev - Development files for the Mozilla SpiderMonkey JavaScript library
 libmozjs1d - The Mozilla SpiderMonkey JavaScript library
 libmozjs1d-dbg - Development files for the Mozilla SpiderMonkey JavaScript library
 libxpcomglue0d - XPCOM standalone glue
 python-xpcom - XPCOM bindings for Python
 spidermonkey-bin - standalone JavaScript/ECMAScript (ECMA-262) interpreter
 xulrunner-1.9 - XUL + XPCOM application runner
 xulrunner-1.9-common - Gecko engine library - common files
 xulrunner-1.9-dbg - Development files for the Gecko engine library
 xulrunner-1.9-gnome-support - Support for GNOME in xulrunner applications
 xulrunner-dev - Development files for the Gecko engine library
 xulrunner-dev-static - Static libraries for the Gecko engine
Closes: 363159 391024 404759 425233 441059 449448
Changes: 
 xulrunner (1.9~b4-1) experimental; urgency=low
 .
   * New upstream beta release (taken from upstream CVS). Closes: #449448.
     + Don't crash when font file is unreadable. Closes: #425233.
     + Better rendering of some extreme conditions. Closes: #391024.
     + MOZILLA_1_8_BRANCH is not defined anymore: Closes: #441059.
     + Don't jump when clicking out of the search bar. Closes: #404759.
     + Ligatures don't overlap the following glyph. Closes: #363159.
   * debian/patches/*: Remove patches.
   * debian/rules: Remove patch rules.
   * debian/control: Don't depend on dpatch.
   * debian/mozconfig: Use the new default cairo-gtk toolkit.
   * (was: debian/patches/31_system_bz2.dpatch)
     config/Makefile.in, config/autoconf.mk.in, config/system-headers,
     configure.in, extensions/metrics/build/Makefile.in
     extensions/metrics/src/Makefile.in,
     extensions/metrics/test/Makefile.in,
     toolkit/mozapps/update/src/updater/Makefile.in,
     toolkit/mozapps/update/src/updater/updater.cpp,
     toolkit/toolkit-tiers.mk: Allow to use system libbz2. bz#305782.
   * (was: debian/patches/35_zip_cache.dpatch)
     modules/libjar/nsJAR.cpp, modules/libjar/nsJAR.h: Invalidate cache for
     modified jar files. bz#368428.
   * (was: debian/patches/38_gnu.dpatch and debian/patches/38_kbsd.dpatch)
     config/rules.mk, configure.in, xpcom/glue/standalone/Makefile.in,
     xpcom/reflect/xptcall/src/md/unix/Makefile.in,
     xpcom/reflect/xptcall/src/md/unix/xptc_platforms_unixish_x86.h: Support
     building on GNU/kFreeBSD and GNU/Hurd. bz#356011.
   * (was: debian/patches/38_hppa_xpcom.dpatch)
     Most of the patch was applied upstream, but need a small fix in
     xpcom/reflect/xptcall/src/md/unix/Makefile.in.
   * (was: debian/patches/38_mips_xpcom.dpatch)
     xpcom/reflect/xptcall/src/md/unix/Makefile.in,
     xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_mips.s,
     xpcom/reflect/xptcall/src/md/unix/xptcinvoke_mips.cpp,
     xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_mips.s: Fix crashes on
     mips. bz#258429.
   * (was: debian/patches/60_js_binary.dpatch)
     config/autoconf.mk.in, config/rules.mk, configure.in, js/src/Makefile.in:
     Allow to build a standalone js binary. bz#331776.
     js/src/xpconnect/shell/Makefile.in: Add readline support to xpcshell.
     bz#331776.
     js/src/js.c, js/src/xpconnect/shell/xpcshell.cpp: Avoid visibility hidden
     issues with readline symbols. bz#331776.
   * (was: debian/patches/60_pyxpcom.dpatch)
     extensions/python/xpcom/src/Makefile.in: Allow to override the PYTHON_SO
     variable.
   * (was: debian/patches/65_native_uconv.dpatch)
     intl/uconv/native/nsINativeUConvService.idl,
     intl/uconv/native/nsNativeUConvService.cpp,
     intl/uconv/src/nsCharsetConverterManager.cpp: Properly load invalid UTF-8
     files with native uconv. bz#331748.
     intl/uconv/src/charsetalias.properties: Fix aliases for gbk and euc-tw for
     use with native uconv. bz#369403.
   * (was: debian/patches/68_m68k_xpcom.dpatch)
     xpcom/reflect/xptcall/src/md/unix/xptcinvoke_linux_m68k.cpp,
     xpcom/reflect/xptcall/src/md/unix/xptcstubs_linux_m68k.cpp: Improve
     assembly for m68k. bz#422337.
   * (was: debian/patches/68_mips_performance.dpatch)
     config/rules.mk, configure.in: Increase stability and performance on mips.
     Reverted to Thiemo's original version for better followup with upstream
     when it will happen (but already has to wait for bz#258429).
   * (was: debian/patches/80_config.dpatch)
     debian/rules: Use config.guess and config.sub from autotools-dev.
   * (was: debian/patches/80_crmf.dpatch)
     configure.in: Put the crmf library before the NSS libraries.
   * (was: debian/patches/80_javaxpcom.dpatch)
     extensions/java/xpcom/Makefile.in, toolkit/toolkit-makefiles.sh: Force
     creation of Makefiles in extensions/java, even when javaxpcom is disabled.
     Don't build the jars if DEB_NO_JAR is defined.
   * (was: debian/patches/80_libxpcom_hack.dpatch)
     js/src/xpconnect/shell/Makefile.in, xulrunner/app/Makefile.in: Force
     libxpcom to be linked to xulrunner-bin and xpcshell so that it is loaded
     in most cases.
   * (was: debian/patches/80_no_examples.dpatch)
     xulrunner/Makefile.in: Don't build example component.
   * (was: debian/patches/80_no_sys_profile.dpatch)
     xulrunner/app/Makefile.in: Don't install system profile.
   * (was: debian/patches/80_system_libs.dpatch)
     configure.in: Make sure we won't be bitten by upstream changing libjpeg,
     libpng or zlib internal version, which makes system library not used even
     though --with-system-* argument is given to configure.
   * (was: debian/patches/80_xulrunner-config.dpatch)
     build/unix/mozilla-config.in: Give more appropriate cflags and libs.
   * (was: debian/patches/80_zip.dpatch)
     config/config.mk, config/make-jars.pl, configure.in: Avoid needing zip if
     not required. bz#331785.
   * (was: debian/patches/81_soname.dpatch)
     config/rules.mk, js/src/Makefile.in, toolkit/library/Makefile.in,
     xpcom/stub/Makefile.in: Add soname to appropriate libraries. This is
     a stripped down version, compared to the dpatch version, because we
     actually are never going to use minor and micro version numbers. Also, we
     now don't set a SO version on libxul and libxpcom because they will now
     be dlloaded() by the standalone xpcomglue.
   * (was: debian/patches/82_locale.dpatch)
     xulrunner/app/xulrunner.js: Enable intl.locale.matchOS, and report the
     locale correctly. bz#331779.
   * (was: debian/patches/82_prefs.dpatch)
     modules/libpref/src/init/all.js: Set javascript.options.showInConsole ;
     Set DPI to system settings.
   * (was: debian/patches/85_installer.dpatch)
     xulrunner/setup/nsXULAppInstall.js: Install applications in /usr/local/lib
     instead of /usr/lib.
   * (was: debian/patches/85_no_register.dpatch)
     xulrunner/app/nsXULRunnerApp.cpp: Remove (un|)registering system.
   * (was: debian/patches/85_xpcomglue.dpatch)
     configure.in, xpcom/base/nscore.h, xpcom/glue/standalone/Makefile.in,
     xpcom/glue/standalone/nsGlueLinking.h,
     xpcom/glue/standalone/nsXPCOMGlue.h: Build the xpcom glue as a shared
     library. Now, also build the dependent xpcom glue.
     xpcom/glue/standalone/nsGlueLinkingDlopen.cpp: Load DSOs from . when
     directory is not given.
   * Other patches have been removed either because incorporated or made
     obsolete by this new upstream release.
 .
   * config/autoconf.mk.in, configure.in,
     modules/libpr0n/decoders/png/nsPNGDecoder.cpp,
     modules/libpr0n/decoders/png/nsPNGDecoder.h,
     modules/libpr0n/encoders/png/nsPNGEncoder.cpp,
     modules/libpr0n/encoders/png/nsPNGEncoder.h: Disable APNG support when
     system libpng doesn't support it.
   * Makefile.in, netwerk/dns/src/Makefile.in, xulrunner/build.mk: Make
     distclean cleaner. While previous cleanups have been incorporated
     upstream, some new files need to be removed. bz#333308.
   * debian/control:
     + Add new required build-dependency on libdbus-glib-1-dev.
     + Build-Depend on libnspr4-dev >= 3.7.0.
     + Build-Depend on libnss3-dev >= 3.12.0~beta2.
     + Build-Depend on libcairo2-dev >= 1.5.
     + Build-Depend on libgtk2.0-dev >= 2.10.
   * debian/remove.nonfree: Updated for new binary blobs and removed
     directory/c-sdk removals, since the directory is not here anymore.
     Also, fixed removal of files with names containing spaces.
   * debian/copyright: A whole lot of files have been either removed or
     relicensed under MPL/GPL/LGPL tri-license. Some new external libraries
     have been incorporated into the source tree, too.
   * debian/mozconfig: Don't build crash reporter (Google Breakpad).
   * debian/mozconfig, debian/control: Use system sqlite and lcms.
   * configure.in: Don't check lcms version, for the same reason as libpng
     and others.
   * js/src/Makefile.in, debian/control, debian/libmozjs0d.install,
     debian/rules: Bumped libmozjs SO version to 1d.
   * debian/libmozjs0d.README.Debian: Removed, as it is not relevant anymore.
   * intl/uconv/native/nsNativeUConvService.cpp: Fix native uconv so that
     XmlHTTPRequest works properly. bz#342133.
   * xulrunner/installer/Makefile.in, debian/rules: Build as if we were version
     1.9 instead of 1.9b4. Also fix permissions for /etc/gre.d file.
   * debian/control, debian/*: Change package names and installed files to fit
     new upstream.
   * debian/rules:
     + Adapted to new upstream files and install method. There is unfortunately
       only one install target now, and it must be run after build-jars when
       building binary-indep. This is why we must set .NOTPARALLEL.
     + Removed source target, which isn't appropriate anymore.
     + Changed the way we set optimization flags so that we use upstream ones,
       and arrange LDFLAGS so that -Wl,--as-needed appears before -lpthread
       during builds.
   * debian/mozconfig:
     + Don't set mozilla default home, it's not useful anymore.
     + Disable stripping of binaries during build.
   * debian/xulrunner.conf: Removed. The equivalent is now provided by upstream
     build system.
   * xulrunner/app/Makefile.in: Link libjemalloc to the xulrunner binary.
   * libxpcomglue0d.preinst, libxpcomglue0d.postrm: Divert libxpcomglue.so.0d
     from libxul0d so that both packages can be installed at the same time.
 .
   * (was: debian/patches/99_configure.dpatch)
     configure: Updated.
Files: 
 c085f0c410d1377950023fe741e927de 1350 devel optional xulrunner_1.9~b4-1.dsc
 72da268e11a2d500b924df793e789167 38979645 devel optional xulrunner_1.9~b4.orig.tar.gz
 d8bc19e0e5aec41c281a8b2c268279a3 94791 devel optional xulrunner_1.9~b4-1.diff.gz
 a4c3ffd7d6c47adadf15097a8aa734b1 213036 libdevel optional libmozjs-dev_1.9~b4-1_all.deb
 fb07c06236e98c08eca3e22c1d419d51 1282292 libs optional xulrunner-1.9-common_1.9~b4-1_all.deb
 b4333aa284cb51e2790e6e53af44db97 4666726 libdevel optional xulrunner-dev_1.9~b4-1_all.deb
 0ad5cb551dd0f198d7e43a197a1e2118 1417156 libdevel extra libmozillainterfaces-java_1.9~b4-1_all.deb
 e64f603b449a385ca2ab6eebefe10725 5990586 devel optional xulrunner-1.9_1.9~b4-1_amd64.deb
 b75312f93c1a0d41a7a965bef092d846 119418 devel optional xulrunner-1.9-gnome-support_1.9~b4-1_amd64.deb
 b5c5743173009c07fe9fd62a651140fa 354572 libs optional libmozjs1d_1.9~b4-1_amd64.deb
 cbce4dd1d8f9429b4b564514dcb54523 865804 libdevel extra libmozjs1d-dbg_1.9~b4-1_amd64.deb
 07ae258d3b4e14b092cefdb147ac9be0 60876 interpreters optional spidermonkey-bin_1.9~b4-1_amd64.deb
 e23e5f52bdbaacc32b02d57cc453ae3a 81952 libs optional libxpcomglue0d_1.9~b4-1_amd64.deb
 f2c3c5725cbaf65900105e9e15af6c48 150422 libdevel optional xulrunner-dev-static_1.9~b4-1_amd64.deb
 7af17517c6e6a1b49b5bd50200746873 49133550 libdevel extra xulrunner-1.9-dbg_1.9~b4-1_amd64.deb
 a48fcf255e4c89a2418bb810fd64c28f 148024 python extra python-xpcom_1.9~b4-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH+M2M3kvaLFT9KlgRAgjhAKCNWwB+fZg6j9ejOJTvpKo7QVK+pgCfaVQF
ZVSIUK5DLkslK1NXEXn+TKU=
=whYU
-----END PGP SIGNATURE-----

Message #77 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@jwsdot.com>

To: 449448@bugs.debian.org

Cc: Mike Hommey <glandium@debian.org>

Subject: Re: Bug#449448: marked as done (Please package xulrunner 1.9 in the upstream way)

Date: Mon, 7 Apr 2008 11:06:06 +0200

Thanks for your work on this ... 

can applications that are build against the upstream static glue find
and use debian xulrunner?


On Sun, Apr 06, 2008 at 05:33:15PM +0000, Debian Bug Tracking System wrote:
> 
> Your message dated Sun, 06 Apr 2008 17:21:27 +0000
> with message-id <E1JiYYZ-0007hi-O6@ries.debian.org>
> and subject line Bug#449448: fixed in xulrunner 1.9~b4-1
> has caused the Debian Bug report #449448,
> regarding Please package xulrunner 1.9 in the upstream way
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact owner@bugs.debian.org
> immediately.)
> 
> 

> X-Spam-Status: No, score=-8.9 required=4.0 tests=BAYES_00,FORGED_RCVD_HELO,
> 	HAS_PACKAGE autolearn=no version=3.1.4-bugs.debian.org_2005_01_02
> From: Alexander Sack <asac@jwsdot.com>
> To: submit@bugs.debian.org
> Subject: Please package xulrunner 1.9 in the upstream way
> 
> Package: xulrunner
> Severity: wishlist
> 
> It would be beneficial to unify how xulrunner is packaged across linux
> distributions.
> 
> Since upstream is unlikely to adapt the debian way of shipping
> xulrunner for various reasons, we should follow their idea on how to
> ship xulrunner.
> 
> A package that could be used is available in ubuntu and can be found
> at:
> 
> https://launchpad.net/ubuntu/+source/xulrunner-1.9
> 
> Thanks for considering this,
> 
>  - Alexander
> 
> 
> 

> X-Spam-Status: No, score=-6.6 required=4.0 tests=BAYES_00,FOURLA,
> 	FROMDEVELOPER,FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,HEADER_X_KATIE,
> 	IMPRONONCABLE_1,IMPRONONCABLE_2,MURPHY_DRUGS_REL8,MURPHY_WRONG_WORD1,
> 	MURPHY_WRONG_WORD2,PUSSY autolearn=no 
> 	version=3.1.4-bugs.debian.org_2005_01_02
> From: Mike Hommey <glandium@debian.org>
> To: 449448-close@bugs.debian.org
> Subject: Bug#449448: fixed in xulrunner 1.9~b4-1
> 
> Source: xulrunner
> Source-Version: 1.9~b4-1
> 
> We believe that the bug you reported is fixed in the latest version of
> xulrunner, which is due to be installed in the Debian FTP archive:
> 
> libmozillainterfaces-java_1.9~b4-1_all.deb
>   to pool/main/x/xulrunner/libmozillainterfaces-java_1.9~b4-1_all.deb
> libmozjs-dev_1.9~b4-1_all.deb
>   to pool/main/x/xulrunner/libmozjs-dev_1.9~b4-1_all.deb
> libmozjs1d-dbg_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/libmozjs1d-dbg_1.9~b4-1_amd64.deb
> libmozjs1d_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/libmozjs1d_1.9~b4-1_amd64.deb
> libxpcomglue0d_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/libxpcomglue0d_1.9~b4-1_amd64.deb
> python-xpcom_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/python-xpcom_1.9~b4-1_amd64.deb
> spidermonkey-bin_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/spidermonkey-bin_1.9~b4-1_amd64.deb
> xulrunner-1.9-common_1.9~b4-1_all.deb
>   to pool/main/x/xulrunner/xulrunner-1.9-common_1.9~b4-1_all.deb
> xulrunner-1.9-dbg_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/xulrunner-1.9-dbg_1.9~b4-1_amd64.deb
> xulrunner-1.9-gnome-support_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/xulrunner-1.9-gnome-support_1.9~b4-1_amd64.deb
> xulrunner-1.9_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/xulrunner-1.9_1.9~b4-1_amd64.deb
> xulrunner-dev-static_1.9~b4-1_amd64.deb
>   to pool/main/x/xulrunner/xulrunner-dev-static_1.9~b4-1_amd64.deb
> xulrunner-dev_1.9~b4-1_all.deb
>   to pool/main/x/xulrunner/xulrunner-dev_1.9~b4-1_all.deb
> xulrunner_1.9~b4-1.diff.gz
>   to pool/main/x/xulrunner/xulrunner_1.9~b4-1.diff.gz
> xulrunner_1.9~b4-1.dsc
>   to pool/main/x/xulrunner/xulrunner_1.9~b4-1.dsc
> xulrunner_1.9~b4.orig.tar.gz
>   to pool/main/x/xulrunner/xulrunner_1.9~b4.orig.tar.gz
> 
> 
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 449448@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Mike Hommey <glandium@debian.org> (supplier of updated xulrunner package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmaster@debian.org)
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Format: 1.7
> Date: Sun, 06 Apr 2008 13:01:04 +0200
> Source: xulrunner
> Binary: xulrunner-1.9 xulrunner-1.9-gnome-support libmozjs1d libmozjs-dev libmozjs1d-dbg spidermonkey-bin libxpcomglue0d xulrunner-1.9-common xulrunner-dev xulrunner-dev-static xulrunner-1.9-dbg libmozillainterfaces-java python-xpcom
> Architecture: source all amd64
> Version: 1.9~b4-1
> Distribution: experimental
> Urgency: low
> Maintainer: Mike Hommey <glandium@debian.org>
> Changed-By: Mike Hommey <glandium@debian.org>
> Description: 
>  libmozillainterfaces-java - XPCOM bindings for Java
>  libmozjs-dev - Development files for the Mozilla SpiderMonkey JavaScript library
>  libmozjs1d - The Mozilla SpiderMonkey JavaScript library
>  libmozjs1d-dbg - Development files for the Mozilla SpiderMonkey JavaScript library
>  libxpcomglue0d - XPCOM standalone glue
>  python-xpcom - XPCOM bindings for Python
>  spidermonkey-bin - standalone JavaScript/ECMAScript (ECMA-262) interpreter
>  xulrunner-1.9 - XUL + XPCOM application runner
>  xulrunner-1.9-common - Gecko engine library - common files
>  xulrunner-1.9-dbg - Development files for the Gecko engine library
>  xulrunner-1.9-gnome-support - Support for GNOME in xulrunner applications
>  xulrunner-dev - Development files for the Gecko engine library
>  xulrunner-dev-static - Static libraries for the Gecko engine
> Closes: 363159 391024 404759 425233 441059 449448
> Changes: 
>  xulrunner (1.9~b4-1) experimental; urgency=low
>  .
>    * New upstream beta release (taken from upstream CVS). Closes: #449448.
>      + Don't crash when font file is unreadable. Closes: #425233.
>      + Better rendering of some extreme conditions. Closes: #391024.
>      + MOZILLA_1_8_BRANCH is not defined anymore: Closes: #441059.
>      + Don't jump when clicking out of the search bar. Closes: #404759.
>      + Ligatures don't overlap the following glyph. Closes: #363159.
>    * debian/patches/*: Remove patches.
>    * debian/rules: Remove patch rules.
>    * debian/control: Don't depend on dpatch.
>    * debian/mozconfig: Use the new default cairo-gtk toolkit.
>    * (was: debian/patches/31_system_bz2.dpatch)
>      config/Makefile.in, config/autoconf.mk.in, config/system-headers,
>      configure.in, extensions/metrics/build/Makefile.in
>      extensions/metrics/src/Makefile.in,
>      extensions/metrics/test/Makefile.in,
>      toolkit/mozapps/update/src/updater/Makefile.in,
>      toolkit/mozapps/update/src/updater/updater.cpp,
>      toolkit/toolkit-tiers.mk: Allow to use system libbz2. bz#305782.
>    * (was: debian/patches/35_zip_cache.dpatch)
>      modules/libjar/nsJAR.cpp, modules/libjar/nsJAR.h: Invalidate cache for
>      modified jar files. bz#368428.
>    * (was: debian/patches/38_gnu.dpatch and debian/patches/38_kbsd.dpatch)
>      config/rules.mk, configure.in, xpcom/glue/standalone/Makefile.in,
>      xpcom/reflect/xptcall/src/md/unix/Makefile.in,
>      xpcom/reflect/xptcall/src/md/unix/xptc_platforms_unixish_x86.h: Support
>      building on GNU/kFreeBSD and GNU/Hurd. bz#356011.
>    * (was: debian/patches/38_hppa_xpcom.dpatch)
>      Most of the patch was applied upstream, but need a small fix in
>      xpcom/reflect/xptcall/src/md/unix/Makefile.in.
>    * (was: debian/patches/38_mips_xpcom.dpatch)
>      xpcom/reflect/xptcall/src/md/unix/Makefile.in,
>      xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_mips.s,
>      xpcom/reflect/xptcall/src/md/unix/xptcinvoke_mips.cpp,
>      xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_mips.s: Fix crashes on
>      mips. bz#258429.
>    * (was: debian/patches/60_js_binary.dpatch)
>      config/autoconf.mk.in, config/rules.mk, configure.in, js/src/Makefile.in:
>      Allow to build a standalone js binary. bz#331776.
>      js/src/xpconnect/shell/Makefile.in: Add readline support to xpcshell.
>      bz#331776.
>      js/src/js.c, js/src/xpconnect/shell/xpcshell.cpp: Avoid visibility hidden
>      issues with readline symbols. bz#331776.
>    * (was: debian/patches/60_pyxpcom.dpatch)
>      extensions/python/xpcom/src/Makefile.in: Allow to override the PYTHON_SO
>      variable.
>    * (was: debian/patches/65_native_uconv.dpatch)
>      intl/uconv/native/nsINativeUConvService.idl,
>      intl/uconv/native/nsNativeUConvService.cpp,
>      intl/uconv/src/nsCharsetConverterManager.cpp: Properly load invalid UTF-8
>      files with native uconv. bz#331748.
>      intl/uconv/src/charsetalias.properties: Fix aliases for gbk and euc-tw for
>      use with native uconv. bz#369403.
>    * (was: debian/patches/68_m68k_xpcom.dpatch)
>      xpcom/reflect/xptcall/src/md/unix/xptcinvoke_linux_m68k.cpp,
>      xpcom/reflect/xptcall/src/md/unix/xptcstubs_linux_m68k.cpp: Improve
>      assembly for m68k. bz#422337.
>    * (was: debian/patches/68_mips_performance.dpatch)
>      config/rules.mk, configure.in: Increase stability and performance on mips.
>      Reverted to Thiemo's original version for better followup with upstream
>      when it will happen (but already has to wait for bz#258429).
>    * (was: debian/patches/80_config.dpatch)
>      debian/rules: Use config.guess and config.sub from autotools-dev.
>    * (was: debian/patches/80_crmf.dpatch)
>      configure.in: Put the crmf library before the NSS libraries.
>    * (was: debian/patches/80_javaxpcom.dpatch)
>      extensions/java/xpcom/Makefile.in, toolkit/toolkit-makefiles.sh: Force
>      creation of Makefiles in extensions/java, even when javaxpcom is disabled.
>      Don't build the jars if DEB_NO_JAR is defined.
>    * (was: debian/patches/80_libxpcom_hack.dpatch)
>      js/src/xpconnect/shell/Makefile.in, xulrunner/app/Makefile.in: Force
>      libxpcom to be linked to xulrunner-bin and xpcshell so that it is loaded
>      in most cases.
>    * (was: debian/patches/80_no_examples.dpatch)
>      xulrunner/Makefile.in: Don't build example component.
>    * (was: debian/patches/80_no_sys_profile.dpatch)
>      xulrunner/app/Makefile.in: Don't install system profile.
>    * (was: debian/patches/80_system_libs.dpatch)
>      configure.in: Make sure we won't be bitten by upstream changing libjpeg,
>      libpng or zlib internal version, which makes system library not used even
>      though --with-system-* argument is given to configure.
>    * (was: debian/patches/80_xulrunner-config.dpatch)
>      build/unix/mozilla-config.in: Give more appropriate cflags and libs.
>    * (was: debian/patches/80_zip.dpatch)
>      config/config.mk, config/make-jars.pl, configure.in: Avoid needing zip if
>      not required. bz#331785.
>    * (was: debian/patches/81_soname.dpatch)
>      config/rules.mk, js/src/Makefile.in, toolkit/library/Makefile.in,
>      xpcom/stub/Makefile.in: Add soname to appropriate libraries. This is
>      a stripped down version, compared to the dpatch version, because we
>      actually are never going to use minor and micro version numbers. Also, we
>      now don't set a SO version on libxul and libxpcom because they will now
>      be dlloaded() by the standalone xpcomglue.
>    * (was: debian/patches/82_locale.dpatch)
>      xulrunner/app/xulrunner.js: Enable intl.locale.matchOS, and report the
>      locale correctly. bz#331779.
>    * (was: debian/patches/82_prefs.dpatch)
>      modules/libpref/src/init/all.js: Set javascript.options.showInConsole ;
>      Set DPI to system settings.
>    * (was: debian/patches/85_installer.dpatch)
>      xulrunner/setup/nsXULAppInstall.js: Install applications in /usr/local/lib
>      instead of /usr/lib.
>    * (was: debian/patches/85_no_register.dpatch)
>      xulrunner/app/nsXULRunnerApp.cpp: Remove (un|)registering system.
>    * (was: debian/patches/85_xpcomglue.dpatch)
>      configure.in, xpcom/base/nscore.h, xpcom/glue/standalone/Makefile.in,
>      xpcom/glue/standalone/nsGlueLinking.h,
>      xpcom/glue/standalone/nsXPCOMGlue.h: Build the xpcom glue as a shared
>      library. Now, also build the dependent xpcom glue.
>      xpcom/glue/standalone/nsGlueLinkingDlopen.cpp: Load DSOs from . when
>      directory is not given.
>    * Other patches have been removed either because incorporated or made
>      obsolete by this new upstream release.
>  .
>    * config/autoconf.mk.in, configure.in,
>      modules/libpr0n/decoders/png/nsPNGDecoder.cpp,
>      modules/libpr0n/decoders/png/nsPNGDecoder.h,
>      modules/libpr0n/encoders/png/nsPNGEncoder.cpp,
>      modules/libpr0n/encoders/png/nsPNGEncoder.h: Disable APNG support when
>      system libpng doesn't support it.
>    * Makefile.in, netwerk/dns/src/Makefile.in, xulrunner/build.mk: Make
>      distclean cleaner. While previous cleanups have been incorporated
>      upstream, some new files need to be removed. bz#333308.
>    * debian/control:
>      + Add new required build-dependency on libdbus-glib-1-dev.
>      + Build-Depend on libnspr4-dev >= 3.7.0.
>      + Build-Depend on libnss3-dev >= 3.12.0~beta2.
>      + Build-Depend on libcairo2-dev >= 1.5.
>      + Build-Depend on libgtk2.0-dev >= 2.10.
>    * debian/remove.nonfree: Updated for new binary blobs and removed
>      directory/c-sdk removals, since the directory is not here anymore.
>      Also, fixed removal of files with names containing spaces.
>    * debian/copyright: A whole lot of files have been either removed or
>      relicensed under MPL/GPL/LGPL tri-license. Some new external libraries
>      have been incorporated into the source tree, too.
>    * debian/mozconfig: Don't build crash reporter (Google Breakpad).
>    * debian/mozconfig, debian/control: Use system sqlite and lcms.
>    * configure.in: Don't check lcms version, for the same reason as libpng
>      and others.
>    * js/src/Makefile.in, debian/control, debian/libmozjs0d.install,
>      debian/rules: Bumped libmozjs SO version to 1d.
>    * debian/libmozjs0d.README.Debian: Removed, as it is not relevant anymore.
>    * intl/uconv/native/nsNativeUConvService.cpp: Fix native uconv so that
>      XmlHTTPRequest works properly. bz#342133.
>    * xulrunner/installer/Makefile.in, debian/rules: Build as if we were version
>      1.9 instead of 1.9b4. Also fix permissions for /etc/gre.d file.
>    * debian/control, debian/*: Change package names and installed files to fit
>      new upstream.
>    * debian/rules:
>      + Adapted to new upstream files and install method. There is unfortunately
>        only one install target now, and it must be run after build-jars when
>        building binary-indep. This is why we must set .NOTPARALLEL.
>      + Removed source target, which isn't appropriate anymore.
>      + Changed the way we set optimization flags so that we use upstream ones,
>        and arrange LDFLAGS so that -Wl,--as-needed appears before -lpthread
>        during builds.
>    * debian/mozconfig:
>      + Don't set mozilla default home, it's not useful anymore.
>      + Disable stripping of binaries during build.
>    * debian/xulrunner.conf: Removed. The equivalent is now provided by upstream
>      build system.
>    * xulrunner/app/Makefile.in: Link libjemalloc to the xulrunner binary.
>    * libxpcomglue0d.preinst, libxpcomglue0d.postrm: Divert libxpcomglue.so.0d
>      from libxul0d so that both packages can be installed at the same time.
>  .
>    * (was: debian/patches/99_configure.dpatch)
>      configure: Updated.
> Files: 
>  c085f0c410d1377950023fe741e927de 1350 devel optional xulrunner_1.9~b4-1.dsc
>  72da268e11a2d500b924df793e789167 38979645 devel optional xulrunner_1.9~b4.orig.tar.gz
>  d8bc19e0e5aec41c281a8b2c268279a3 94791 devel optional xulrunner_1.9~b4-1.diff.gz
>  a4c3ffd7d6c47adadf15097a8aa734b1 213036 libdevel optional libmozjs-dev_1.9~b4-1_all.deb
>  fb07c06236e98c08eca3e22c1d419d51 1282292 libs optional xulrunner-1.9-common_1.9~b4-1_all.deb
>  b4333aa284cb51e2790e6e53af44db97 4666726 libdevel optional xulrunner-dev_1.9~b4-1_all.deb
>  0ad5cb551dd0f198d7e43a197a1e2118 1417156 libdevel extra libmozillainterfaces-java_1.9~b4-1_all.deb
>  e64f603b449a385ca2ab6eebefe10725 5990586 devel optional xulrunner-1.9_1.9~b4-1_amd64.deb
>  b75312f93c1a0d41a7a965bef092d846 119418 devel optional xulrunner-1.9-gnome-support_1.9~b4-1_amd64.deb
>  b5c5743173009c07fe9fd62a651140fa 354572 libs optional libmozjs1d_1.9~b4-1_amd64.deb
>  cbce4dd1d8f9429b4b564514dcb54523 865804 libdevel extra libmozjs1d-dbg_1.9~b4-1_amd64.deb
>  07ae258d3b4e14b092cefdb147ac9be0 60876 interpreters optional spidermonkey-bin_1.9~b4-1_amd64.deb
>  e23e5f52bdbaacc32b02d57cc453ae3a 81952 libs optional libxpcomglue0d_1.9~b4-1_amd64.deb
>  f2c3c5725cbaf65900105e9e15af6c48 150422 libdevel optional xulrunner-dev-static_1.9~b4-1_amd64.deb
>  7af17517c6e6a1b49b5bd50200746873 49133550 libdevel extra xulrunner-1.9-dbg_1.9~b4-1_amd64.deb
>  a48fcf255e4c89a2418bb810fd64c28f 148024 python extra python-xpcom_1.9~b4-1_amd64.deb
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFH+M2M3kvaLFT9KlgRAgjhAKCNWwB+fZg6j9ejOJTvpKo7QVK+pgCfaVQF
> ZVSIUK5DLkslK1NXEXn+TKU=
> =whYU
> -----END PGP SIGNATURE-----
> 
> 


 - Alexander

Message #82 received at 449448@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Alexander Sack <asac@jwsdot.com>

Cc: 449448@bugs.debian.org

Subject: Re: Bug#449448: marked as done (Please package xulrunner 1.9 in the upstream way)

Date: Mon, 7 Apr 2008 11:17:00 +0200

On Mon, Apr 07, 2008 at 11:06:06AM +0200, Alexander Sack <asac@jwsdot.com> wrote:
> 
> 
> Thanks for your work on this ... 
> 
> can applications that are build against the upstream static glue find
> and use debian xulrunner?

They have to either use the standalone glue which will find it, or use
the dependent glue, link against libxpcom and libxul, and set the appropriate
rpath or LD_LIBRARY_PATH. I don't recommend the latter.

Mike

Send a report that this bug log contains spam.