Last upload for mozilla-based products

[Mike Hommey]

On Wed, Mar 14, 2007 at 04:26:18AM -0700, Steve Langasek wrote:
> On Wed, Mar 14, 2007 at 08:26:55AM +0100, Mike Hommey wrote:
> > I would like to know, since the release is now very close, if there
> > could be a final upload of the mozilla-based products.
> 
> 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.

> 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).

(...)
> With that proviso, if there are fixes you think we should have, please go
> ahead with uploading them; but the longer we have to wait on an upstream
> release in order to get them, the more likely it is that the release team
> will judge the risks too high to be included so soon before release. 
> (Sorry, can't be more exact than that without seeing exactly what's going to
> be uploaded.)

Release candidates are already available, and cvs has already been tagged,
so even if they don't release officially soon, I think we can just safely
get a new upstream from cvs (or just the changes between the tags), name it
 version 2.0.0.3 for iceweasel, and upload it like that. If it happens that
they make more changes (which is very unlikely), we could still upload a -2
version fixing it up.

I'll check out exactly which of these would apply to the other applications
and will plan an upload of these too.

> > 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.

> Anyway, if a fix is available for this soon enough I can agree that it
> should be included.
> 
> Thanks,

Thank *you*

Mike