Last upload for mozilla-based products
vorlon at debian.org
Fri Mar 16 10:44:37 CET 2007
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 18.104.22.168-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
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
> 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/
More information about the pkg-mozilla-maintainers