Re: Last upload for mozilla-based products
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.)
> I have 2 main concerns:
> - A patch (stolen from redhat) that we apply leads to bugs such as
> https://bugzilla.mozilla.org/show_bug.cgi?id=370386
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414008
> This is IMHO quite problematic, since it makes the external helper
> applications thing more or less useless. This patch, on the other hand,
> is also important because it makes helper applications with arguments
> work.
> We have 3 possibilities to fix the issue:
> - backout the patch
> - forcing the browser.download.hide_plugins_without_extensions
> preference to false
> - Apply the new version of the patch, that I sent to
> https://bugzilla.mozilla.org/attachment.cgi?id=258000, see the
> interdiff with the previous patch, attached.
> This applies to iceape, iceweasel and xulrunner. It might be a good
> idea to add the patch to icedove as well, if we leave it in the
> others.
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.)
> - Upstream is releasing a regression fix release that fixes the
> following issues:
> https://bugzilla.mozilla.org/show_bug.cgi?id=370559
> https://bugzilla.mozilla.org/show_bug.cgi?id=371576
> https://bugzilla.mozilla.org/show_bug.cgi?id=373181
> https://bugzilla.mozilla.org/show_bug.cgi?id=371925
> https://bugzilla.mozilla.org/show_bug.cgi?id=370136
> https://bugzilla.mozilla.org/show_bug.cgi?id=371525
At least some of these are security fixes; of course we should have those,
but it's also not necessarily the case that they need to get into testing
before the release. For others, well, no software is perfect, and at some
point it's better for stable to be able to know what bugs we have than to
try to fix all the bugs that appear.
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.)
> 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?
Anyway, if a fix is available for this soon enough I can agree that it
should be included.
Thanks,
--
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@debian.org http://www.debian.org/
Reply to: