Last upload for mozilla-based products

[Steve Langasek]

On Wed, Mar 14, 2007 at 01:46:34PM +0100, Mike Hommey wrote:
> > Note that iceape and xulrunner are currently out of sync between testing and
> > unstable, and I don't see any unblock hints in place for these from the
> > release team.  Have unblocks been requested for these?  (Sorry, I don't tend
> > to track the status of unblock requests once someone else on the team
> > responds to them.)

> No unblock has been requested, but I assumed Marc was following at least
> xulrunner, since he reviewed 1.8.0.10-1 before I uploaded it (and then had
> to fix more issues), and iceweasel got in without anyone asking, so...
> I would have asked after a while without action from the RMs, though.

iceweasel was unblocked without asking because there was a declared RC bug
on the package.  I think in the absence of such RC bugs on the radar, the
unpleasantness of unblocking a 150kloc diff sight-unseen is the dominating
factor. ;)

I guess iceape and xulrunner both have security bugs in testing that should
be considered RC?  I'll go ahead and unblock iceape on that basis; I'll
leave xulrunner for Marc to comment on further, since he knows the status
better than I do.

> > The provided interdiff looks reasonable to me, so I don't object to its
> > inclusion if you believe that's the correct course of action.  Is there a
> > description available for the original issue that the redhat patch was
> > intended to solve?  (That would help, among other things, with forming an
> > educated opinion on whether it should be added to icedove.)

> There are 2 things that are done by the patch. The first is to properly
> handle external helper applications with arguments, as provided by gnomevfs,
> which in turn uses the information from shared-mime-info.
> I don't have an example of such an helper in mind, but the example given in
> upstream bug is if someone sets "gedit --new-window" to be the handler for
> text/plain files.
> The second is that /etc/mailcap was taking precedence on "gnome" mime
> information.

> The bug the interdiff corrects is that now the gnomevfs code takes
> precedence on /etc/mailcap, there is no extensions information available,
> because the gnomevfs code doesn't return them anymore
> (gnome_vfs_mime_get_extensions_list always returns NULL). The side effect
> of this is that it breaks the way the external helper applications are being
> set in mozilla applications.
> So the interdiff works around this by taking the extensions info from
> mime.types files (but still uses the extensions given by gnomevfs if there
> are, which may happen with very old versions of gnomevfs).

Ok, if you think this is an important thing to have fixed for icedove, I can
accept that.  (Hmm, icedove also out of sync between testing and unstable,
and I have no idea about that one at all...)

> > > There is a third concern that I forgot: icons. It would be nice if we'd
> > > fix #414012 (and did the same on icedove and iceape)

> > I'm having trouble understanding why this would be "instead of" including
> > icons in /usr/share/pixmaps, as stated in 414012.  Wouldn't the intent be to
> > include higher-quality icons in the fd.o directory, with the .xpms currently
> > in /usr/share/pixmaps retained for compatibility with the Debian menu
> > system?

> There is an iceweasel.png file in /usr/share/pixmaps, that is, I think, what
> the bug reporter was referring to, or at least, this is what I intend to fix.

Ah, I was looking at a system that only had iceape installed, with no .pngs
in the directory.  Ok, understood.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/