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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
