Re: xulrunner 1.9.2 into sid?
On Wed, 30 Jun 2010 09:08:36 +0200 Mike Hommey wrote: Disadvantages of maintaining the status quo: - part way through the release, security support will end and many users won't even notice (unless they're subscribed to debian-security); leaving a lot of the Debian user base vulnerable. That surely can be arranged with a special security upload of the package displaying a message to the user in some way (which, IMHO, should be done with any package which security support is dropped) I think that's a great solution. Anyway, I hope I've done a better job of clearly defining the scope of the problem. I look forward to some constructive debate. Your debate is pointless. Why do you care ? What is your agenda ? Do you want me to list the same kind of problems webkit gives ? IMHO, webkit gives more headaches than mozilla. Simply because despite all you can say, you have several codebases for each debian suite. Each of which may or may not have some of the security issues. This is in no way any better than with mozilla. As for access to the security bugs information, relying on the public information is not enough anyway if you want to provide *timely* security updates. The current webkit support in debian is way after the facts. The current mozilla support in debian is only a few days off, merely because the CVE and MFSA information is not available to me until upstream releases its security update. Also, speaking of upstream security support, I have yet to see an upstream stable release of webkit that includes security fixes. I don't remember there was any for the GTK port, despite a promise for some, and I don't think there was any for the QT port either. At least, Mozilla continues to support older releases for some months after a new major release. So far, that doesn't appear to have been true for webkit. Actually, apart from Chromium, I don't think there are releases with security fixes in webkit at all. And even then, I don't think Chromium upstream releases security fixes for older major releases. The best you can do is actually to go through the CVEs and webkit security bugs, and find the relevant patches in svn, hoping they are not dependent on changes in the codebase between the moment it was fixed in svn, and the codebase you're trying to patch. And then, you have to account for the fact that you have several codebases in each debian suite. How exactly is that supposed to be better ? So, why exactly would we have to chose webkit over mozilla ? Because it's the new cool kid on the block ? Finally, the security team hasn't been involved in patching mozilla for years. AFAIK, patching is what makes most of the work in security support. Except this work is done by the mozilla maintainers and has been for a while. What exactly are you trying to get off the security team shoulders ? Handling a security build and issuing a DSA ? Following the advisories for mozilla ? I completely concur. Webkit has some growing pains and poses its own set of unique issues that need to be addressed; which I plan to work. All in all, will you just do something really constructive and stop this crusade of yours ? As stated previously, my intent was simply to debate the consequences of mozilla's new extremely short support timeframe; certainly no crusade, and certainly no reason to turn the heat up. Since you're content with the amount of work involved with security backports, and as long as users are loudly informed when suppport gets terminated, then all of my concerns are addressed. At this point I'm perfectly content with the outcome. Thanks for taking the time to resolve the issues. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100704162015.e6f72ea5.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
Hi! Am 29.06.2010 22:52, schrieb Michael Gilbert: I believe I do. Backports are for recompilations of unstable packages for the stable releases. Thanks for excellently stating that you do *not* know about what is backports about and for, you couldn't have done that better. The second paragraph on the front page of backports.org says pretty much the same exact thing in different words. Uh? Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates) [..] Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2ae94b.50...@schmehl.info
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 08:31:25PM -0400, Michael Gilbert wrote: On Tue, 29 Jun 2010 17:07:27 -0400 Michael Gilbert wrote: Hopefully restating clearly this time: my proposal is to no longer distribute mozilla packages in the main stable repository; instead they can be maintained in backports (or volatile) at the choosing of the maintainers of those packages (or converted to webkit to remain in stable main). I propose no changes to the mozilla packages in unstable or experimental. I'm going to make one more attempt at assembling a sound argument supporting this proposal. Note that my only vested interest in the outcome of any decision is reducing the burden on the security team. I understand that Mike Hommey is ultimately responsible for any decision that may be made, and the consequences of that decision primarily only affect the mozilla maintainers' future workload (with some fallout on the security team). In the following lists, I break down the advantages and disadvantages of each approach. If there are other thoughts, I would be happy to see them included. Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) - one (or almost the same) code base across backports and testing/unstable (and potentially oldstable-backports). Disadvantages of switching to backports: - no official security support. - potential confusing for users since the mozilla packages will not be available in a default install. - Problems for all rdeps of xulrunner-1.9.1 and libmozjs2d, and all build-rdeps of libmozjs-dev and xulrunner-dev that don't depend on either of both (e.g. plugins), and ensuing problem for users of those packages. Advantages of maintaining the status quo: - continue to provide a highly demanded packages where users expect to find it. Disadvantages of maintaining the status quo: - part way through the release, security support will end and many users won't even notice (unless they're subscribed to debian-security); leaving a lot of the Debian user base vulnerable. That surely can be arranged with a special security upload of the package displaying a message to the user in some way (which, IMHO, should be done with any package which security support is dropped) - this will be a lot more work for the maintainers due to manual backports of mozilla patches and? - three different code bases to support: stable, testing/unstable, and oldstable (when that is supported) and? Anyway, I hope I've done a better job of clearly defining the scope of the problem. I look forward to some constructive debate. Your debate is pointless. Why do you care ? What is your agenda ? Do you want me to list the same kind of problems webkit gives ? IMHO, webkit gives more headaches than mozilla. Simply because despite all you can say, you have several codebases for each debian suite. Each of which may or may not have some of the security issues. This is in no way any better than with mozilla. As for access to the security bugs information, relying on the public information is not enough anyway if you want to provide *timely* security updates. The current webkit support in debian is way after the facts. The current mozilla support in debian is only a few days off, merely because the CVE and MFSA information is not available to me until upstream releases its security update. Also, speaking of upstream security support, I have yet to see an upstream stable release of webkit that includes security fixes. I don't remember there was any for the GTK port, despite a promise for some, and I don't think there was any for the QT port either. At least, Mozilla continues to support older releases for some months after a new major release. So far, that doesn't appear to have been true for webkit. Actually, apart from Chromium, I don't think there are releases with security fixes in webkit at all. And even then, I don't think Chromium upstream releases security fixes for older major releases. The best you can do is actually to go through the CVEs and webkit security bugs, and find the relevant patches in svn, hoping they are not dependent on changes in the codebase between the moment it was fixed in svn, and the codebase you're trying to patch. And then, you have to account for the fact that you have several codebases in each debian suite. How exactly is that supposed to be better ? So, why exactly would we have to chose webkit over mozilla ? Because it's the new cool kid on the block ? Finally, the security team hasn't been involved in patching mozilla for years. AFAIK, patching is what makes most of the work in security support. Except this work is done by the mozilla maintainers and has been for a while. What exactly are you trying to get off the security team shoulders ? Handling a security build and issuing a DSA ?
Re: xulrunner 1.9.2 into sid?
Hi! Am 30.06.2010 02:31, schrieb Michael Gilbert: Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) As current maintainer of the iceweasel and xulrunner backports I invite you to try that out. Calling that very simple maintainance is far from what I experienced so far. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2af924.5060...@debian.org
Re: xulrunner 1.9.2 into sid?
On Wed, Jun 30, 2010 at 09:58:28AM +0200, Alexander Reichle-Schmehl wrote: Hi! Am 30.06.2010 02:31, schrieb Michael Gilbert: Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) As current maintainer of the iceweasel and xulrunner backports I invite you to try that out. Calling that very simple maintainance is far from what I experienced so far. As current maintainer of the iceweasel and xulrunner packages I'm curious to know what kind of problems you have that makes it not a very simple maintainance. AFAIK, you should only need a couple backports (off the top of my head, debhelper, nspr, possibly nss, sqlite and cairo). Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630093209.ga4...@glandium.org
backports and volatile (was: Re: xulrunner 1.9.2 into sid?)
Hi! I'd like to excuse for the style of my initial response, it was pretty terse and just pointed out the misinterpretations without offering corrections to them. I'd like to address them now. * Michael Gilbert michael.s.gilb...@gmail.com [2010-06-29 21:50:31 CEST]: On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: You don't know the current policies WRT packages in backports and about their reasoning, do you? I believe I do. Backports are for recompilations of unstable packages for the stable releases. Hence, that's why it seems like a good solution here. volatile seems like it has a much more restrictive set of criteria, but I suppose it would also be a good solution if its allowable. That's not completely true. For a start, it's for recompilations for packages from *testing* (not unstable) in a stable environment. But reducing it to that is missing the point: The purpose of backports is to offer newer features in packages that are intended for the next stable release available for the current stable release. Wanting to put a package into backports as sole place won't get accepted because it won't be part of the next stable release. If we don't want to release a package it shouldn't go there neither. Honestly, the ideal solution would be for either backports or volatile to become officially supported (which from what I can tell has been in discussion for a long time now). In fact, if one or the other did become official, there would be no need for both. It might have evaded you, but volatile _is_ officially supported, for quite a long while already. See http://www.debian.org/volatile/ about it, it uses .debian.org ressources directly. backports just started to get into there with being integrated into the official buildd network, things are progressing slowly. I only can see that you mean officially supported *by the security team*, neither of them is, which is true. I am very grateful that the security-tracker does include the status for backports, though - that's extremely helpful to track issues. Additionally though, they are also both neither integrated into the BTS, which is another quite unfortunate state. But there is *need* for both: While backports is for getting newer features into stable for otherwise already good working software, the purpose of volatile is a completely different: It is about getting software into shape that does _not_ work anymore properly in stable anymore but would require deeper changes than just a small patch that could get in easily through a point release. Yes, clamav is a very good example here: The required engine changes are too much for a security/point release update, thus volatile is the proper place for it. I hope this clears up some confusion that might spin around in some heads. Thanks, and sorry for the initial response style again, Rhonda -- Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte. -- http://www.karriere.at/artikel/884/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630100148.ga7...@anguilla.debian.or.at
Re: xulrunner 1.9.2 into sid?
Michael Gilbert wrote: No, my proposal is to move the package to a better home: backports. Have you discussed this proposal with other members of the security team? And/or the relase team? Ignoring the fact whether this is something possible or not currently, just think of the rdepends. Seriously. xulrunner is not clamav in this regard. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaqc7b41.gnus_not_unix!%ya...@gnu.org
Re: xulrunner 1.9.2 into sid?
On Mon, 28 Jun 2010 13:54:28 +0200 Mike Hommey wrote: On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote: Ah yes, Iceape. Their releases are so few and far between, this could possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3, but its release date is TBD. Upstream Firefox 4 is due the end of the year, based on 1.9.3, and will likely be ahead of Seamonkey. So where does that put us? Seems trying to keep the two projects aligned is some task. :) (note 1.9.3 is apparently going to be reversioned to 2.0) Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid? 3.6 will go into sid when squeeze is released. It will remain in experimental until then, except if the plans change. 4.0 betas will go into experimental then. In the meanwhile, they will probably be provided somewhere on mozilla.debian.net. 4.0 will go into sid when it is released. First, TB 3.1 has just been released, and as such hasn't been widely tested in Debian. It usually isn't very wise, that close to the expected freeze time, to upload a new major release of a not exactly small and trivial software. I can understand this, but I would imagine the release of Squeeze is at least 8-10 months out. We still have a good deal of RC bugs to get through. Of course, packages this size will add to the count. Supposedly, the freeze is somewhen in august. After that, getting a new major version in the archive is a no-go. Second, for the reasons given earlier, releasing with iceweasel 3.6 and icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not be a huge problem, as we already didn't release lenny with iceape, but see below. Iceape is a beautiful piece of software, and I have run it in the past. But market share shows that Seamonkey/Iceape users are the minority, with Firefox/Iceweasel and Thunderbird/Icedove the vast majority. Releasing Lenny without Iceape was the best move, IMO. If Debian accounted for market share, it would dump a whole lot of packages. There are a lot of packages with less users than iceape. All in all, I still think releasing squeeze with iceape 2.0, iceweasel 3.5 and icedove 3.0 is the best course of action. Is this really the best move? With Firefox 4 due the end of the year, and 3.6 will be a year old already, the security team will be supporting 3.5 after Mozilla stops it's support. Same might be the case with Icedove 3.0. Choosing between 3.5 and 3.6 on that alone is not enough. As I said, Mozilla will also stop supporting 3.6 way before squeeze security support ends. This discussion brings up an opportunity to debate the merrit of continuing to suffer the chilling effects of a self-interested upstream (i.e. mozilla no longer attempts to play well in the open source ecosystem since it has no impact on 90% of their marketshare). Based on their latest decision to go to a 6-month only support cycle, it will be impossible to support their package for the 3+ year lifetime of a stable release (especially since since they purposely leave out patch information in their advisories, which is needed to independently solve their problems). In fact, at the current rate, 3.5 will be end-of-lifed before squeeze gets out the door. Chilling affects have already been felt: etch had to drop support for iceweasel 6 months before its end-of-life as well. Also since 3.0 is already end-of-lifed, support for iceweasel in lenny will need to end soon (a year or more before the end of that release). There are a couple solutions to this problem. In light of the new upstream support timeframe, Ubuntu has decided to sacrifice stability (opting to push new major upstream releases into their stable versions) and engage in poor supportability/secuirity practices (using embedded code copies instead of system libraries) [0]. This path is unnacceptable for Debian. In my personal opinion, the only viable option left is to drop all mozilla and mozilla-depending packages from main, and provide them in backports (as suggested already in another message in this thread). Backports' rolling release model makes it the perfect avenue to adhere to mozilla's dictated treadmill. It may take quite a bit of work to excise the offending packages, but there is still quite a bit of time before the squeeze freeze; so it should be doable. With respect to upgrades from lenny, perhaps the iceweasel packages could upgrade to epiphany or chromium and provide a message about using backports informing the user about how to continue using iceweasel if that's really what they want. Losing mozilla wouldn't be that significant of an loss since there are plenty of other good options nowadays (webkit, konquerer, chromium, etc.), which wasn't the case a year or so ago. Although webkit does have a few supportability problems of its own, they are more tractable
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: Mozilla actively makes it hard to stay up to date (by providing as little information as possible in their advisories); webkit (for the most part except for Apple announcements) makes it easy. This means security fixes are going to happen a lot faster since there is a lot less downtime waiting for patches to by disclosed. Actually, that's not true. It's pretty easy to track the security related changes in mercurial now (that was indeed a problem when mozilla was still using CVS), and security bugs are as documented as Webkit's. The only difference, for now, is that we have access to the Webkit bugs while we (still) don't have access to the Mozilla ones. But that should happen some day. IOW, your point is void ;) Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629073746.gd3...@glandium.org
Re: xulrunner 1.9.2 into sid?
Le mardi 29 juin 2010 à 02:57 -0400, Michael Gilbert a écrit : Losing mozilla wouldn't be that significant of an loss since there are plenty of other good options nowadays (webkit, konquerer, chromium, etc.), which wasn't the case a year or so ago. I would love to get rid of it, but unfortunately there is still a way too large number of broken websites that won’t work without Firefox. -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `-and I am praying for you.” -- Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1277802199.22309.2.ca...@meh
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: and engage in poor supportability/secuirity practices (using embedded code copies instead of system libraries) [0]. This path is unnacceptable for Debian. In my personal opinion, the only viable option left is to drop all mozilla and mozilla-depending packages from main [...] Losing mozilla wouldn't be that significant of an loss since there are plenty of other good options nowadays (webkit, konquerer, chromium, etc.), which wasn't the case a year or so ago. Wait, wait... you promote webkit-based browsers, every single of which embeds the complete webkit codebase -- while you name exactly that issue as the reason why Ubuntu's approach to xulrunner is unacceptable. Hmm... Yeah, indeed that approach is bad, but that's a reason to remove chromium and konqueror which do use it, not iceweasel which doesn't. Also, Chromium doesn't support even the base essentials, like working AdBlock[1] or sane cookie handling[2]. And Konqueror is just a bad joke, barely better than Dillo or Amaya (no, not the DD). So your proposal would remove the only reasonably featured browser from Debian. [1]. A Chromium extension named AdBlock exists, but it merely hides the junk after downloading them -- so you merely don't see them while still being subjected to slowdown, having your bandwidth stolen, being tracked, having advertising scripts running, being exposed to more of potentially unpatched vulnerabilities, and all that kind of goodies... [2]. Chromium doesn't even understand the concept of session cookies. It does allow purging cookies at exit -- but that applies to all cookies, including the few you do want to keep. Iceweasel's default handling isn't perfect, but it can be set to something sane even without installing any extensions, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629095720.ga12...@angband.pl
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 11:57:20AM +0200, Adam Borowski wrote: [1]. A Chromium extension named AdBlock exists, but it merely hides the junk after downloading them -- so you merely don't see them while still being subjected to slowdown, having your bandwidth stolen, being tracked, having advertising scripts running, being exposed to more of potentially unpatched vulnerabilities, and all that kind of goodies... This is not true anymore... https://chrome.google.com/extensions/detail/gighmmpiobklfepjocnamgkkbiglidom -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629100030.go19...@dorei.kerker.die-welt.net
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 12:00:30PM +0200, Evgeni Golov wrote: On Tue, Jun 29, 2010 at 11:57:20AM +0200, Adam Borowski wrote: [1]. A Chromium extension named AdBlock exists, but it merely hides the junk after downloading them -- so you merely don't see them while still being subjected to slowdown, having your bandwidth stolen, being tracked, having advertising scripts running, being exposed to more of potentially unpatched vulnerabilities, and all that kind of goodies... This is not true anymore... https://chrome.google.com/extensions/detail/gighmmpiobklfepjocnamgkkbiglidom This is a new development, good to know. They say it's badly incomplete, mostly due to no support in the underlying API, but since it's being worked on, it looks like this particular show stopper is already mostly gone. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629105544.ga12...@angband.pl
Re: xulrunner 1.9.2 into sid?
On 06/29/2010 03:57 AM, Adam Borowski wrote: [1]. A Chromium extension named AdBlock exists, but it merely hides the junk after downloading them -- so you merely don't see them while still being subjected to slowdown, having your bandwidth stolen, being tracked, having advertising scripts running, being exposed to more of potentially unpatched vulnerabilities, and all that kind of goodies... No longer the case with Adblock 2.0, as already pointed out by Evgeni. [2]. Chromium doesn't even understand the concept of session cookies. It does allow purging cookies at exit -- but that applies to all cookies, including the few you do want to keep. Iceweasel's default handling isn't perfect, but it can be set to something sane even without installing any extensions, While true, this is rather trivial to setup: rm ~/.config/chromium/Default/Cookies ln -s /dev/null ~/.config/chromium/Default/Cookies -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 04:57:53AM -0600, Aaron Toponce wrote: On 06/29/2010 03:57 AM, Adam Borowski wrote: [2]. Chromium doesn't even understand the concept of session cookies. It does allow purging cookies at exit -- but that applies to all cookies, including the few you do want to keep. Iceweasel's default handling isn't ^ perfect, but it can be set to something sane even without installing any extensions, While true, this is rather trivial to setup: rm ~/.config/chromium/Default/Cookies ln -s /dev/null ~/.config/chromium/Default/Cookies Uhm, and that gets me what? It would nuke all cookies, including those which are supposed to last beyond the session. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629111657.ga13...@angband.pl
Re: xulrunner 1.9.2 into sid?
On 06/29/2010 05:16 AM, Adam Borowski wrote: Uhm, and that gets me what? It would nuke all cookies, including those which are supposed to last beyond the session. Touche. I misread your post, and Chromium's ability to do this by default. Apologies. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 11:57:20 +0200, Adam Borowski wrote: On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: and engage in poor supportability/secuirity practices (using embedded code copies instead of system libraries) [0]. This path is unnacceptable for Debian. In my personal opinion, the only viable option left is to drop all mozilla and mozilla-depending packages from main [...] Losing mozilla wouldn't be that significant of an loss since there are plenty of other good options nowadays (webkit, konquerer, chromium, etc.), which wasn't the case a year or so ago. Wait, wait... you promote webkit-based browsers, every single of which embeds the complete webkit codebase -- while you name exactly that issue as the reason why Ubuntu's approach to xulrunner is unacceptable. Hmm... Yeah, indeed that approach is bad, but that's a reason to remove chromium and konqueror which do use it, not iceweasel which doesn't. Like I said, that is hopefully just a temporary problem and will be fixed following the squeeze release. To clarify my point, it will be easier to support six forks of the same codebase rather than six forks of the same codebase plus a completely separate codebase as well (especially when those six forks are roughly feature-equivalent to the separate codebase). Also, Chromium doesn't support even the base essentials, like working AdBlock[1] or sane cookie handling[2]. And Konqueror is just a bad joke, barely better than Dillo or Amaya (no, not the DD). It's open source (and in rapid development); if these are features interest you then them or pay someone to do it for you. So your proposal would remove the only reasonably featured browser from Debian. No, my proposal is to move the package to a better home: backports. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629112400.b276dc06.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: No, my proposal is to move the package to a better home: backports. Same question as for Md with volatile: apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 What do you do with these packages ? backports too ? Do you realize some of these are part of the core of the GNOME desktop ? Also, using backports doesn't magically solve the issue that all these package need to be updated when there is a new ABI/API (which basically is the case with major xulrunner versions) Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629152920.ga12...@glandium.org
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: Mozilla actively makes it hard to stay up to date (by providing as little information as possible in their advisories); webkit (for the most part except for Apple announcements) makes it easy. This means security fixes are going to happen a lot faster since there is a lot less downtime waiting for patches to by disclosed. Actually, that's not true. It's pretty easy to track the security related changes in mercurial now (that was indeed a problem when mozilla was still using CVS), and security bugs are as documented as Webkit's. The only difference, for now, is that we have access to the Webkit bugs while we (still) don't have access to the Mozilla ones. But that should happen some day. IOW, your point is void ;) OK, point taken (I don't have any perspective on mozilla's inner workings, so I didn't know this). However, do you want to continue suffering with the workload required to support the mozilla packages? The core problem I see is that there are two very vulnerable codebases currently planned to be supported, and manpower could be roughly halved if the codebases were reduced to one. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629113528.d113c16d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 11:35:28AM -0400, Michael Gilbert wrote: On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: Mozilla actively makes it hard to stay up to date (by providing as little information as possible in their advisories); webkit (for the most part except for Apple announcements) makes it easy. This means security fixes are going to happen a lot faster since there is a lot less downtime waiting for patches to by disclosed. Actually, that's not true. It's pretty easy to track the security related changes in mercurial now (that was indeed a problem when mozilla was still using CVS), and security bugs are as documented as Webkit's. The only difference, for now, is that we have access to the Webkit bugs while we (still) don't have access to the Mozilla ones. But that should happen some day. IOW, your point is void ;) OK, point taken (I don't have any perspective on mozilla's inner workings, so I didn't know this). However, do you want to continue suffering with the workload required to support the mozilla packages? The core problem I see is that there are two very vulnerable codebases currently planned to be supported, and manpower could be roughly halved if the codebases were reduced to one. The point in releasing squeeze with 3.5/1.9.1 is precisely to only have to support one codebase for all mozilla based software in debian... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629153957.ga12...@glandium.org
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 17:39:57 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 11:35:28AM -0400, Michael Gilbert wrote: On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote: Mozilla actively makes it hard to stay up to date (by providing as little information as possible in their advisories); webkit (for the most part except for Apple announcements) makes it easy. This means security fixes are going to happen a lot faster since there is a lot less downtime waiting for patches to by disclosed. Actually, that's not true. It's pretty easy to track the security related changes in mercurial now (that was indeed a problem when mozilla was still using CVS), and security bugs are as documented as Webkit's. The only difference, for now, is that we have access to the Webkit bugs while we (still) don't have access to the Mozilla ones. But that should happen some day. IOW, your point is void ;) OK, point taken (I don't have any perspective on mozilla's inner workings, so I didn't know this). However, do you want to continue suffering with the workload required to support the mozilla packages? The core problem I see is that there are two very vulnerable codebases currently planned to be supported, and manpower could be roughly halved if the codebases were reduced to one. The point in releasing squeeze with 3.5/1.9.1 is precisely to only have to support one codebase for all mozilla based software in debian... The point I was trying to make in that paragraph is that there are two browser codebases (webkit and mozilla) that need to be supported, which could be halved by dropping one. On the current path, there will be three mozilla versions that need to be supported; lenny, squeeze, and unstable (which is of course quasi-supported). On the new path, this could be reduced to one version; backports. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629115147.3b6364df.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: No, my proposal is to move the package to a better home: backports. Same question as for Md with volatile: apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 What do you do with these packages ? backports too ? Do you realize some of these are part of the core of the GNOME desktop ? Yes, I would say drop them all. The maintainer should be free to choose whether they want to continue to support the package in backports, convert the backend to use webkit, or to drop the package altogether. Which of those are gnome core packages? Only liferea, galeon, evolution-rss, and yelp stick out to me, but I don't use gnome. Yelp has a webkit backend, so the mozilla backend could be disabled. Also, using backports doesn't magically solve the issue that all these package need to be updated when there is a new ABI/API (which basically is the case with major xulrunner versions) I agree, anyone planning to maintain those packages in backports will indeed have to suffer through that, but it's just the fact of life with mozilla. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629120604.6d8a7462.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On 2010-06-29, Mike Hommey m...@glandium.org wrote: On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: No, my proposal is to move the package to a better home: backports. Same question as for Md with volatile: apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 What do you do with these packages ? backports too ? Do you realize some of these are part of the core of the GNOME desktop ? Actually we have the same problem with clamav in volatile. We would need to put all rdeps there, otherwise stuff gets messy. At least that's a very restricted set, yours is... not feasible, I suppose. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni2k6lv.vri.tr...@kelgar.0x539.de
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 11:03:19 +0200, Josselin Mouette wrote: Le mardi 29 juin 2010 à 02:57 -0400, Michael Gilbert a écrit : Losing mozilla wouldn't be that significant of an loss since there are plenty of other good options nowadays (webkit, konquerer, chromium, etc.), which wasn't the case a year or so ago. I would love to get rid of it, but unfortunately there is still a way too large number of broken websites that won’t work without Firefox. I've only encounter three or four websites in the last year that didn't work quite right with webkit (I've been using midori for at least that long as my primary browser), and upstream has been surprisingly responsive to fixing those issues very quickly. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629121745.bfdac139.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote: The point I was trying to make in that paragraph is that there are two browser codebases (webkit and mozilla) that need to be supported, which could be halved by dropping one. As long as there are people to support both, why drop one? I mean, you're not involved in mozilla security support, why do you even care? And don't make me laugh with the number of codebases, please, because the mozilla codebase in a given debian suite is the same, which can't be said from each embedded version of webkit. Sure, some patches may be applied as they are, or with minimal modifications, accross these various versions. But this is also true for mozilla. For instance, the last 3.0 upload in stable-security was the first one without an upstream release, and out of 17 patches, only one needed to be seriously amended, but wasn't included in the end because of the low severity. All in all, my gut feeling is that webkit is much more a burden to support than mozilla, but I'm not advocating to drop it. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629162923.ga13...@glandium.org
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 12:06:04PM -0400, Michael Gilbert wrote: On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: No, my proposal is to move the package to a better home: backports. Same question as for Md with volatile: apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 What do you do with these packages ? backports too ? Do you realize some of these are part of the core of the GNOME desktop ? Yes, I would say drop them all. The maintainer should be free to choose whether they want to continue to support the package in backports, convert the backend to use webkit, or to drop the package altogether. Which of those are gnome core packages? Only liferea, galeon, evolution-rss, and yelp stick out to me, but I don't use gnome. Yelp has a webkit backend, so the mozilla backend could be disabled. Also, using backports doesn't magically solve the issue that all these package need to be updated when there is a new ABI/API (which basically is the case with major xulrunner versions) I agree, anyone planning to maintain those packages in backports will indeed have to suffer through that, but it's just the fact of life with mozilla. Seeing how many problems there still are with webkit backed GNOME applications, that sure is only a mozilla problem... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629163109.gb13...@glandium.org
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 18:31:09 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 12:06:04PM -0400, Michael Gilbert wrote: On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote: On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote: No, my proposal is to move the package to a better home: backports. Same question as for Md with volatile: apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2 What do you do with these packages ? backports too ? Do you realize some of these are part of the core of the GNOME desktop ? Yes, I would say drop them all. The maintainer should be free to choose whether they want to continue to support the package in backports, convert the backend to use webkit, or to drop the package altogether. Which of those are gnome core packages? Only liferea, galeon, evolution-rss, and yelp stick out to me, but I don't use gnome. Yelp has a webkit backend, so the mozilla backend could be disabled. Also, using backports doesn't magically solve the issue that all these package need to be updated when there is a new ABI/API (which basically is the case with major xulrunner versions) I agree, anyone planning to maintain those packages in backports will indeed have to suffer through that, but it's just the fact of life with mozilla. Seeing how many problems there still are with webkit backed GNOME applications, that sure is only a mozilla problem... Apologies, I should have said that was a fact of life for any abi/api transition, so there is nothing special about a mozilla transition (except that it touches a lot of packages) whether or not its in backports or elsewhere. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629123520.5a7dcd17.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
Mike Hommey wrote: On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote: The point I was trying to make in that paragraph is that there are two browser codebases (webkit and mozilla) that need to be supported, which could be halved by dropping one. As long as there are people to support both, why drop one? I mean, you're not involved in mozilla security support, why do you even care? FWIW, this does not seem to be limited to one person, or one codebase. This apparently well-meaning idea that we can improve Debian's security etc by talking people out of doing jobs that they have volunteered to do, and are doing, is a recent trend that I really don't understand. -- see shy jo signature.asc Description: Digital signature
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 12:35:19 -0400, Joey Hess wrote: Mike Hommey wrote: On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote: The point I was trying to make in that paragraph is that there are two browser codebases (webkit and mozilla) that need to be supported, which could be halved by dropping one. As long as there are people to support both, why drop one? I mean, you're not involved in mozilla security support, why do you even care? FWIW, this does not seem to be limited to one person, or one codebase. This apparently well-meaning idea that we can improve Debian's security etc by talking people out of doing jobs that they have volunteered to do, and are doing, is a recent trend that I really don't understand. I really hope I haven't come across this way. It was certainly not my intention. Like I said in my first post to this discussion, I think a debate on the merit of the status quo with respect to the mozilla packages is greatly needed right now. If the result of this debate is maintaining the status quo, then that's just fine with me, but at least all of the dirty laundry has been aired, and an informed decision made. I also stated that I did't want to diminish Mike's work in any way. He's done a great job, and I hope the package will continue to be maintained. I just think that a more appropriate home is in backports. This is the same solution that has been implemented for clamav due to its short upstream support time frame. As for my non-involvement in mozilla security, that actually isn't true. I actually spent a great deal of effort to triage all of the mozilla issues in the security tracker about a year ago, and submitted bugs for the open ones. However, as a user, I have no access to mozilla patches, so I could go no further. I did what I could to improve mozilla security, then I just simply lost interest because I found webkit to be actually tractable. Anyway, I think debate is healthy, and hopefully a broadly beneficial solution can be reached. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629133446.a1f3e0e4.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
Hi! Am 29.06.2010 17:24, schrieb Michael Gilbert: No, my proposal is to move the package to a better home: backports. You don't know the current policies WRT packages in backports and about their reasoning, do you? Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2a4243.1060...@schmehl.info
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: Hi! Am 29.06.2010 17:24, schrieb Michael Gilbert: No, my proposal is to move the package to a better home: backports. You don't know the current policies WRT packages in backports and about their reasoning, do you? I believe I do. Backports are for recompilations of unstable packages for the stable releases. Hence, that's why it seems like a good solution here. volatile seems like it has a much more restrictive set of criteria, but I suppose it would also be a good solution if its allowable. I just realized that clamav actually went into volatile, and it was flasplugin-nonfree that went to backports. Anyway those two show the two roads already traveled. It's a matter of debating the best one for this case. Honestly, the ideal solution would be for either backports or volatile to become officially supported (which from what I can tell has been in discussion for a long time now). In fact, if one or the other did become official, there would be no need for both. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629155031.80bc198d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
Michael Gilbert schrieb am Tuesday, den 29. June 2010: Hi, In my personal opinion, the only viable option left is to drop all mozilla and mozilla-depending packages from main, and provide them in backports (as suggested already in another message in this thread). Backports' rolling release model makes it the perfect avenue to adhere to mozilla's dictated treadmill. It may take quite a bit of work to excise the offending packages, but there is still quite a bit of time before the squeeze freeze; so it should be doable. With respect to upgrades from lenny, perhaps the iceweasel packages could upgrade to epiphany or chromium and provide a message about using backports informing the user about how to continue using iceweasel if that's really what they want. You should talk with the backports ftpmaster before (yes thats me). Alex - Not happy about the idea. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629202247.ga4...@lisa.snow-crash.org
Re: xulrunner 1.9.2 into sid?
Hi! * Michael Gilbert michael.s.gilb...@gmail.com [2010-06-29 21:50:31 CEST]: On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: Am 29.06.2010 17:24, schrieb Michael Gilbert: No, my proposal is to move the package to a better home: backports. You don't know the current policies WRT packages in backports and about their reasoning, do you? I believe I do. Backports are for recompilations of unstable packages for the stable releases. Thanks for excellently stating that you do *not* know about what is backports about and for, you couldn't have done that better. Also, weren't it you who responded to a mail about getting the security tracker informations straight that it is too much of trouble for you to check backports informations, too? I fail to see how that would get better if you want to push more stuff into backports? Honestly, the ideal solution would be for either backports or volatile to become officially supported (which from what I can tell has been in discussion for a long time now). In fact, if one or the other did become official, there would be no need for both. Also, you seem to know pretty little about volatile, it seems. Can you please check the things you talk about before you are spreading false statements just as they were facts? And no, the scope of volatile and backports is pretty much different, none of them would obsolete the other. Thanks, Rhon*please do your homework*da -- Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte. -- http://www.karriere.at/artikel/884/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629202505.ga8...@anguilla.debian.or.at
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 12:35:19PM -0400, Joey Hess wrote:
This apparently well-meaning idea that we can improve Debian's
security etc by talking people out of doing jobs that they have
volunteered to do, and are doing, is a recent trend that I really
don't understand.
Amen.
On Tue, Jun 29, 2010 at 01:34:46PM -0400, Michael Gilbert wrote:
I really hope I haven't come across this way. It was certainly not
my intention. Like I said in my first post to this discussion, I think
a debate on the merit of the status quo with respect to the mozilla
packages is greatly needed right now. If the result of this debate is
maintaining the status quo, then that's just fine with me, but at least
all of the dirty laundry has been aired, and an informed decision made.
Well, I confess that it did come across that way also to me, and
probably to many others. The impression was something like: “someone not
working on iceweasel security in Debian is trying to convince someone
else which is working on that, not only to stop, but also to throw out
of the Debian main archive iceweasel all together”.
Try looking at it that way for a minute and you surely understand how
surreal the debate looked like from the outside :-)
As for my non-involvement in mozilla security, that actually isn't
true. I actually spent a great deal of effort to triage all of the
mozilla issues in the security tracker about a year ago, and submitted
bugs for the open ones. However, as a user, I have no access to
mozilla patches, so I could go no further. I did what I could to
improve mozilla security, then I just simply lost interest because I
found webkit to be actually tractable.
To the risk of repeating myself, Debian is a do-ocracy: who does the
work and does it well (as in this case!) gets the right to decide. If
you stopped working on iceweasel security, you kind of gave up your
rights of directly affecting the course of the package.
I'm sure that for a package as big and complex as iceweasel Mike and
Eric could use every single pair of helping hands: get involved again
and your greatly needed debate will have a much higher impact.
(That was written without iceweasel maintainers' permission, though.)
Besides, we all thank you for your security triaging activity for
Mozilla-related package: that helps other users way more than removing
their favorite browser from the main archive.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: xulrunner 1.9.2 into sid?
* Philipp Kern tr...@philkern.de [2010-06-28 11:55:22 CEST]: On 2010-06-28, Marco d'Itri m...@linux.it wrote: If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. The catch-all for I can't maintain this stuff properly[1] is not volatile, but backports. Thanks. No it isn't, can you please stop disregarding backports in that way? If you don't like it that's your fault - but calling it a dump place for stuff that one can't maintain properly couldn't be further from reality. [1] No offence meant for the awesome mozilla maintainers. But offence meant for the backports maintainers? Thanks for the fish. Rhonda -- Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte. -- http://www.karriere.at/artikel/884/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629203919.ga14...@anguilla.debian.or.at
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 3:50 PM, Michael Gilbert michael.s.gilb...@gmail.com wrote: On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: Hi! Am 29.06.2010 17:24, schrieb Michael Gilbert: No, my proposal is to move the package to a better home: backports. You don't know the current policies WRT packages in backports and about their reasoning, do you? I believe I do. Backports are for recompilations of unstable packages for the stable releases. No, the backports service is for backporting packages from testing to the stable release. If a package (or the candidate version) does not exist in testing, then it is not a candidate for backports except under special circumstances. A package still has to go through some sanity checking (via the unstable - testing transition) before being available for backporting since packages targeted for use with the stable release are supposed to be exactly that -- stable. This means stable both in the sense of working properly as well as not being a moving target because of behavior changes introduced in newer versions. The proposal to maintain the packages entirely in backports is not congruent with this. It sounds closer to the intent of volatile, although I don't think that's a proper place for the packages being discussed either since volatile is for packages which, more by necessity, need to have multiple updates during the span of a stable release. This is not the case with the Mozilla-related packages, as new version updates (other than the security fixes already being handled) are a nicety, not a requirement. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiluxaygkyf0rln3hpivq13ax6m3n2qsmqaw2...@mail.gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 22:25:06 +0200, Gerfried Fuchs wrote: Hi! * Michael Gilbert michael.s.gilb...@gmail.com [2010-06-29 21:50:31 CEST]: On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: Am 29.06.2010 17:24, schrieb Michael Gilbert: No, my proposal is to move the package to a better home: backports. You don't know the current policies WRT packages in backports and about their reasoning, do you? I believe I do. Backports are for recompilations of unstable packages for the stable releases. Thanks for excellently stating that you do *not* know about what is backports about and for, you couldn't have done that better. The second paragraph on the front page of backports.org says pretty much the same exact thing in different words. Also, weren't it you who responded to a mail about getting the security tracker informations straight that it is too much of trouble for you to check backports informations, too? I fail to see how that would get better if you want to push more stuff into backports? Yes, and I also stated that if backports were to become an officially supported release, I would adapt my workflow to support it. But until then, it doesn't make sense. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629165216.a3e20b7d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 22:26:04 +0200, Stefano Zacchiroli wrote: On Tue, Jun 29, 2010 at 12:35:19PM -0400, Joey Hess wrote: This apparently well-meaning idea that we can improve Debian's security etc by talking people out of doing jobs that they have volunteered to do, and are doing, is a recent trend that I really don't understand. Amen. On Tue, Jun 29, 2010 at 01:34:46PM -0400, Michael Gilbert wrote: I really hope I haven't come across this way. It was certainly not my intention. Like I said in my first post to this discussion, I think a debate on the merit of the status quo with respect to the mozilla packages is greatly needed right now. If the result of this debate is maintaining the status quo, then that's just fine with me, but at least all of the dirty laundry has been aired, and an informed decision made. Well, I confess that it did come across that way also to me, and probably to many others. The impression was something like: “someone not working on iceweasel security in Debian is trying to convince someone else which is working on that, not only to stop, but also to throw out of the Debian main archive iceweasel all together”. Try looking at it that way for a minute and you surely understand how surreal the debate looked like from the outside :-) I can certainly see that perspective, and I can see now that I've chosen my words poorly, which has lead to a major communication breakdown. Hopefully restating clearly this time: my proposal is to no longer distribute mozilla packages in the main stable repository; instead they can be maintained in backports (or volatile) at the choosing of the maintainers of those packages (or converted to webkit to remain in stable main). I propose no changes to the mozilla packages in unstable or experimental. As for my non-involvement in mozilla security, that actually isn't true. I actually spent a great deal of effort to triage all of the mozilla issues in the security tracker about a year ago, and submitted bugs for the open ones. However, as a user, I have no access to mozilla patches, so I could go no further. I did what I could to improve mozilla security, then I just simply lost interest because I found webkit to be actually tractable. To the risk of repeating myself, Debian is a do-ocracy: who does the work and does it well (as in this case!) gets the right to decide. If you stopped working on iceweasel security, you kind of gave up your rights of directly affecting the course of the package. Understood; however, ill-conceived security disclosure policies impede this process. I would fix the issues myself, but I am restricted from doing so because of upstream mozilla disclosure policy. That policy is the primary reason that I am no longer interested in mozilla. I don't really see my interests changing without changes happening upstream first. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629170727.3d70722d.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 10:39:20PM +0200, Gerfried Fuchs wrote: * Philipp Kern tr...@philkern.de [2010-06-28 11:55:22 CEST]: On 2010-06-28, Marco d'Itri m...@linux.it wrote: If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. The catch-all for I can't maintain this stuff properly[1] is not volatile, but backports. Thanks. No it isn't, can you please stop disregarding backports in that way? If you don't like it that's your fault - but calling it a dump place for stuff that one can't maintain properly couldn't be further from reality. It seems the irony was well hidden, then. [1] No offence meant for the awesome mozilla maintainers. But offence meant for the backports maintainers? Thanks for the fish. I already took the offence for the volatile maintainers, thanks. Ciao Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629213812.ga2...@kelgar.0x539.de
Re: xulrunner 1.9.2 into sid?
On Tue, 29 Jun 2010 17:07:27 -0400 Michael Gilbert wrote: Hopefully restating clearly this time: my proposal is to no longer distribute mozilla packages in the main stable repository; instead they can be maintained in backports (or volatile) at the choosing of the maintainers of those packages (or converted to webkit to remain in stable main). I propose no changes to the mozilla packages in unstable or experimental. I'm going to make one more attempt at assembling a sound argument supporting this proposal. Note that my only vested interest in the outcome of any decision is reducing the burden on the security team. I understand that Mike Hommey is ultimately responsible for any decision that may be made, and the consequences of that decision primarily only affect the mozilla maintainers' future workload (with some fallout on the security team). In the following lists, I break down the advantages and disadvantages of each approach. If there are other thoughts, I would be happy to see them included. Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) - one (or almost the same) code base across backports and testing/unstable (and potentially oldstable-backports). Disadvantages of switching to backports: - no official security support. - potential confusing for users since the mozilla packages will not be available in a default install. Advantages of maintaining the status quo: - continue to provide a highly demanded packages where users expect to find it. Disadvantages of maintaining the status quo: - part way through the release, security support will end and many users won't even notice (unless they're subscribed to debian-security); leaving a lot of the Debian user base vulnerable. - this will be a lot more work for the maintainers due to manual backports of mozilla patches - three different code bases to support: stable, testing/unstable, and oldstable (when that is supported) Anyway, I hope I've done a better job of clearly defining the scope of the problem. I look forward to some constructive debate. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629203125.af7af9af.michael.s.gilb...@gmail.com
Re: xulrunner 1.9.2 into sid?
Michael Gilbert michael.s.gilb...@gmail.com writes: In the following lists, I break down the advantages and disadvantages of each approach. If there are other thoughts, I would be happy to see them included. Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) - one (or almost the same) code base across backports and testing/unstable (and potentially oldstable-backports). People have been dancing around this, but no one seems to have said it directly, so I will. Packages that are excluded from the release are not eligible for backports either. If Mozilla was not considered a candidate for the release, it also wouldn't be permitted in the backports.org repository (unless the policies of the various archives changed). backports.org only accepts backports of packages that have migrated to testing. Packages are only permitted to migrate to testing if they're release candidates and are intended to be part of the next release. If we were not going to include Mozilla in subsequent releases, that would mean blocking it from migration with an RC bug, and that in turn would mean that it could not be uploaded to backports.org. I suspect the repository that you're looking for when you say backports is actually volatile, although there are doubtless other issues with hosting all of Mozilla there. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eifpe3mc@windlord.stanford.edu
Re: xulrunner 1.9.2 into sid?
On Sun, Jun 27, 2010 at 08:25:59AM -0600, Aaron Toponce wrote: Seeing as though upstream Firefox 3.6 released December 1, 2008, and upstream Thunderbird 3.1 released just a couple days ago, it might be high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and Icedove 3.1 will depend on it. However, I hear there will be lots of breakage if xulrunner 1.9.2 comes into Sid. If so, what will break? Further, what can I do to help? Short answer: not much. Long answer: The target for squeeze was decided to be 3.5/1.9.1 a long time ago, when testing freeze was expected much earlier. Until Thunderbird 3.1, the incentive to keep it that way still made sense. Now, things may have changed, but it's more complicated than it seems. We currently only have one version of xulrunner in the archive for a given suite. Technically speaking, the xulrunner source package provides the xulrunner-1.9.x packages, and obviously a given source package only provides on xulrunner-1.9.x package. At the moment, stable (lenny) has xulrunner-1.9, squeeze and unstable have xulrunner-1.9.1 and experimental has xulrunner-1.9.2. With the upcoming release of the Firefox 4.0 first beta, there might be a xulrunner-2.0 coming in a third party repository. Therea are mainly two reasons for that state of affairs with xulrunner: - it avoids having a part of the suite using a version of xulrunner while another part uses a different one, which would most probably create a big mess. - there is not enough hand power to maintain several versions of xulrunner in the same suite (especially stable) The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is still considered as the release target: iceape 2.0, icedove 3.0, and iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support for stable will be easier if there is only one branch to support for the whole gecko ecosystem. Sure, upstream support for it will be dropped soon, but we can't expect 3.6 to be supported the whole squeeze lifetime either. That being said, there are reasons why 3.6 would be nice to have in squeeze, and the main one is the out of process plugin feature. BUT, there are technical reasons that make that goal difficult to attain. First, TB 3.1 has just been released, and as such hasn't been widely tested in Debian. It usually isn't very wise, that close to the expected freeze time, to upload a new major release of a not exactly small and trivial software. Second, for the reasons given earlier, releasing with iceweasel 3.6 and icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not be a huge problem, as we already didn't release lenny with iceape, but see below. Switching to xulrunner 1.9.2 means making sure all the packages currently built against xulrunner-dev and libmozjs-dev build fine, get the proper dependencies, and then run fine with xulrunner 1.9.2. Unfortunately, as xpcom is guaranteed forward compatible but not backwards compatible, some plugins and extensions, once built against xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This would leave iceape users with a bitter aftertaste. Alternatively, iceape-dev could be filled again with the relevant header and library files, such that those plugins and extensions can build against it which would solve the compatibility issue, but then iceape would need to either be released or be left in the same state as in lenny, i.e. only providing the -dev package. That means a lot of work in identifying those plugins and extensions, modifying them, etc. FWIW, as iceape-dev is not used anymore and is a transitional package, I was about to remove it. Switching to xulrunner 1.9.2 would also mean to make sure it works properly on all the target architectures, while currently there are various test suite failures on some architectures. xulrunner 1.9.1 is in a better shape, from that perspective. All in all, I still think releasing squeeze with iceape 2.0, iceweasel 3.5 and icedove 3.0 is the best course of action. Cheers, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628083406.gd5...@glandium.org
Re: xulrunner 1.9.2 into sid?
Hello, On 06/27/2010 04:25 PM, Aaron Toponce wrote: Seeing as though upstream Firefox 3.6 released December 1, 2008, and upstream Thunderbird 3.1 released just a couple days ago, it might be high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and Icedove 3.1 will depend on it. However, I hear there will be lots of breakage if xulrunner 1.9.2 comes into Sid. If so, what will break? Further, what can I do to help? It cannot be that bad, I am running it on my desktop with Maverick. ii xulrunner-1.9.2 1.9.2.4+build7+nobinonly-0u XUL + XPCOM application runner It is already in experimental http://packages.debian.org/search?searchon=sourcenameskeywords=xulrunner maybe you can just install it and report back to the maintainers? Thanks and regards Steffen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c285f84.7030...@gmx.de
Re: xulrunner 1.9.2 into sid?
On Jun 28, Mike Hommey m...@glandium.org wrote: Unfortunately, as xpcom is guaranteed forward compatible but not backwards compatible, some plugins and extensions, once built against xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This would leave iceape users with a bitter aftertaste. Alternatively, And how would this be worse than shipping a version of iceweasel which is already obsolete? Who actually cares about iceape? If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. FWIW, I have been using iceweasel 3.6 since it has been uploaded and it works *much* better than 3.5 did, which was slow and crashed a lot. -- ciao, Marco signature.asc Description: Digital signature
Re: xulrunner 1.9.2 into sid?
On 2010-06-28, Marco d'Itri m...@linux.it wrote: If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. The catch-all for I can't maintain this stuff properly[1] is not volatile, but backports. Thanks. Kind regards, Philipp Kern [1] No offence meant for the awesome mozilla maintainers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni2gsca.jp9.tr...@kelgar.0x539.de
Re: xulrunner 1.9.2 into sid?
On Mon, Jun 28, 2010 at 11:35:17AM +0200, Marco d'Itri wrote: On Jun 28, Mike Hommey m...@glandium.org wrote: Unfortunately, as xpcom is guaranteed forward compatible but not backwards compatible, some plugins and extensions, once built against xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This would leave iceape users with a bitter aftertaste. Alternatively, And how would this be worse than shipping a version of iceweasel which is already obsolete? Who actually cares about iceape? If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. apt-cache rdepends xulrunner-1.9.1 libmozjs2d What are you suggesting for these packages? volatile, too? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628101703.ga12...@glandium.org
Re: xulrunner 1.9.2 into sid?
On Mon, Jun 28, 2010 at 09:55:22AM +, Philipp Kern wrote: On 2010-06-28, Marco d'Itri m...@linux.it wrote: If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. The catch-all for I can't maintain this stuff properly[1] is not volatile, but backports. Thanks. Speaking of backports, a way to streamline packages from testing to backports would be very much helpful for packages like iceweasel, where basically the package from testing can be installed on a lenny system provided you already use backports for some other libraries. If that's not the case anymore, some of its dependencies should be switched to using symbols files. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628101928.gb12...@glandium.org
Re: xulrunner 1.9.2 into sid?
On Jun 28, Mike Hommey m...@glandium.org wrote: Speaking of backports, a way to streamline packages from testing to backports would be very much helpful for packages like iceweasel, where basically the package from testing can be installed on a lenny system provided you already use backports for some other libraries. If that's not the case anymore, some of its dependencies should be switched to using symbols files. Please open bugs on all your dependencies which are still not shipping symbol files! I did it (with patches) for some key dependencies of my packages and it helped a lot. -- ciao, Marco signature.asc Description: Digital signature
Re: xulrunner 1.9.2 into sid?
On 06/28/2010 02:34 AM, Mike Hommey wrote: The latter also applies for iceape and icedove, and is why 3.5/1.9.1 is still considered as the release target: iceape 2.0, icedove 3.0, and iceweasel 3.5 are all based on xulrunner/gecko 1.9.1. Security support for stable will be easier if there is only one branch to support for the whole gecko ecosystem. Sure, upstream support for it will be dropped soon, but we can't expect 3.6 to be supported the whole squeeze lifetime either. Ah yes, Iceape. Their releases are so few and far between, this could possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3, but its release date is TBD. Upstream Firefox 4 is due the end of the year, based on 1.9.3, and will likely be ahead of Seamonkey. So where does that put us? Seems trying to keep the two projects aligned is some task. :) Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid? First, TB 3.1 has just been released, and as such hasn't been widely tested in Debian. It usually isn't very wise, that close to the expected freeze time, to upload a new major release of a not exactly small and trivial software. I can understand this, but I would imagine the release of Squeeze is at least 8-10 months out. We still have a good deal of RC bugs to get through. Of course, packages this size will add to the count. Second, for the reasons given earlier, releasing with iceweasel 3.6 and icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not be a huge problem, as we already didn't release lenny with iceape, but see below. Iceape is a beautiful piece of software, and I have run it in the past. But market share shows that Seamonkey/Iceape users are the minority, with Firefox/Iceweasel and Thunderbird/Icedove the vast majority. Releasing Lenny without Iceape was the best move, IMO. All in all, I still think releasing squeeze with iceape 2.0, iceweasel 3.5 and icedove 3.0 is the best course of action. Is this really the best move? With Firefox 4 due the end of the year, and 3.6 will be a year old already, the security team will be supporting 3.5 after Mozilla stops it's support. Same might be the case with Icedove 3.0. I can see this is a delicate dance, and I can see the problem of two xulrunner releases in a single archive. I wasn't aware of the technical complexities, so it was good to learn. Thanks for taking the time. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
RE : xulrunner 1.9.2 into sid?
Do you have an entry explaining how to create from scratch a symbol file for a given library ? I could not find this information on the debian wiki. thanks Frederic Message d'origine De: Marco d'Itri [mailto:m...@linux.it] Date: lun. 28/06/2010 12:37 À: debian-devel@lists.debian.org Cc: pkg-mozilla-maintain...@lists.alioth.debian.org Objet : Re: xulrunner 1.9.2 into sid? On Jun 28, Mike Hommey m...@glandium.org wrote: Speaking of backports, a way to streamline packages from testing to backports would be very much helpful for packages like iceweasel, where basically the package from testing can be installed on a lenny system provided you already use backports for some other libraries. If that's not the case anymore, some of its dependencies should be switched to using symbols files. Please open bugs on all your dependencies which are still not shipping symbol files! I did it (with patches) for some key dependencies of my packages and it helped a lot. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/606cc410b038e34cb97646a32d0ec0bf03888...@venusbis.synchrotron-soleil.fr
Re: xulrunner 1.9.2 into sid?
On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote: Ah yes, Iceape. Their releases are so few and far between, this could possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3, but its release date is TBD. Upstream Firefox 4 is due the end of the year, based on 1.9.3, and will likely be ahead of Seamonkey. So where does that put us? Seems trying to keep the two projects aligned is some task. :) (note 1.9.3 is apparently going to be reversioned to 2.0) Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid? 3.6 will go into sid when squeeze is released. It will remain in experimental until then, except if the plans change. 4.0 betas will go into experimental then. In the meanwhile, they will probably be provided somewhere on mozilla.debian.net. 4.0 will go into sid when it is released. First, TB 3.1 has just been released, and as such hasn't been widely tested in Debian. It usually isn't very wise, that close to the expected freeze time, to upload a new major release of a not exactly small and trivial software. I can understand this, but I would imagine the release of Squeeze is at least 8-10 months out. We still have a good deal of RC bugs to get through. Of course, packages this size will add to the count. Supposedly, the freeze is somewhen in august. After that, getting a new major version in the archive is a no-go. Second, for the reasons given earlier, releasing with iceweasel 3.6 and icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not be a huge problem, as we already didn't release lenny with iceape, but see below. Iceape is a beautiful piece of software, and I have run it in the past. But market share shows that Seamonkey/Iceape users are the minority, with Firefox/Iceweasel and Thunderbird/Icedove the vast majority. Releasing Lenny without Iceape was the best move, IMO. If Debian accounted for market share, it would dump a whole lot of packages. There are a lot of packages with less users than iceape. All in all, I still think releasing squeeze with iceape 2.0, iceweasel 3.5 and icedove 3.0 is the best course of action. Is this really the best move? With Firefox 4 due the end of the year, and 3.6 will be a year old already, the security team will be supporting 3.5 after Mozilla stops it's support. Same might be the case with Icedove 3.0. Choosing between 3.5 and 3.6 on that alone is not enough. As I said, Mozilla will also stop supporting 3.6 way before squeeze security support ends. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628115428.ga18...@glandium.org
Re: xulrunner 1.9.2 into sid?
On 06/28/2010 06:54 AM, Mike Hommey wrote: On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote: [snip] Second, for the reasons given earlier, releasing with iceweasel 3.6 and icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not be a huge problem, as we already didn't release lenny with iceape, but see below. Iceape is a beautiful piece of software, and I have run it in the past. But market share shows that Seamonkey/Iceape users are the minority, with Firefox/Iceweasel and Thunderbird/Icedove the vast majority. Releasing Lenny without Iceape was the best move, IMO. If Debian accounted for market share, it would dump a whole lot of packages. There are a lot of packages with less users than iceape. When you've got limited resources, you must make hard decisions. One of those decisions is whether to help a lot of people at the expense of a few, or the few at the expense of the lot. Quoting Aristotle: Even supposing the chief good to be eventually the aim for the individual as for the state, that of the state is evidently of greater and more fundamental importance both to attain and to preserve. The securing of one individual's good is cause for rejoicing, but to secure the good of a nation or of a city-state is nobler and more divine. Quoting Spock: Were I to invoke logic, however, logic clearly dictates that the needs of the many outweigh the needs of the few. -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c289659.60...@cox.net
Re: xulrunner 1.9.2 into sid?
On Jun 28, PICCA Frédéric-Emmanuel frederic-emmanuel.pi...@synchrotron-soleil.fr wrote: Do you have an entry explaining how to create from scratch a symbol file for a given library ? You add dh_makeshlibs -- -c4 to debian/rules and then edit the diff in the error message. Do not forget to remove the old .shlibs file. -- ciao, Marco signature.asc Description: Digital signature
Re: xulrunner 1.9.2 into sid?
On 28/06/2010 14:29, Marco d'Itri wrote: On Jun 28, PICCA Frédéric-Emmanuel frederic-emmanuel.pi...@synchrotron-soleil.fr wrote: Do you have an entry explaining how to create from scratch a symbol file for a given library ? You add dh_makeshlibs -- -c4 to debian/rules and then edit the diff in the error message. You can also create an empty symbol file and look at/apply the diff in the build log. This is what I do. Do not forget to remove the old .shlibs file. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c28a8f1.8080...@free.fr
Re: RE : xulrunner 1.9.2 into sid?
PICCA Frédéric-Emmanuel wrote: Do you have an entry explaining how to create from scratch a symbol file for a given library ? I could not find this information on the debian wiki. thanks Frederic Hi, $ man dpkg-gensymbols aka $ dpkg-gensymbols -plibfoo -v0.1.2 -Odebian/libfoo.symbols.$arch Then, for a c++ library, some sed, c++filt, etc. can give you a multi-arch symbols file. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i0aa9n$ct...@dough.gmane.org
Re: xulrunner 1.9.2 into sid?
On 06/28/2010 03:38 AM, Steffen Möller wrote: Hello, On 06/27/2010 04:25 PM, Aaron Toponce wrote: Seeing as though upstream Firefox 3.6 released December 1, 2008, and upstream Thunderbird 3.1 released just a couple days ago, it might be high time to get xulrunner 1.9.2 into Sid, as both Iceweasel 3.6 and Icedove 3.1 will depend on it. However, I hear there will be lots of breakage if xulrunner 1.9.2 comes into Sid. If so, what will break? Further, what can I do to help? It cannot be that bad, I am running it on my desktop with Maverick. ii xulrunner-1.9.2 1.9.2.4+build7+nobinonly-0u XUL + XPCOM application runner It is already in experimental http://packages.debian.org/search?searchon=sourcenameskeywords=xulrunner maybe you can just install it and report back to the maintainers? Thanks and regards Steffen Well, Ubuntu started the transition in Lucid and it's not entirely completed yet. We still have a handful of sources that we cannot rebuild due to the transition. There are also a few broken applications that we still have to patch. In addition, we had to drop most of the extensions from the archive and a few less popular applications that were built on xulrunner. Also, Ubuntu does not have the resources to backport security fixes for EOL gecko versions. That was the main push to have xulrunner-1.9.2 in Lucid (3 yr desktop support). Since Debian is committed to providing backported security fixes for EOL versions and the greater number of packages involved, I think what Mike Hommey said before is the way to go for Squeeze and sid. Micah Gersten Ubuntu Mozilla Team Member -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c28ae1c.3050...@ubuntu.com
Re: xulrunner 1.9.2 into sid?
On Mon, Jun 28, 2010 at 02:29:54PM +0200, Marco d'Itri wrote: On Jun 28, PICCA Frédéric-Emmanuel frederic-emmanuel.pi...@synchrotron-soleil.fr wrote: Do you have an entry explaining how to create from scratch a symbol file for a given library ? You add dh_makeshlibs -- -c4 to debian/rules and then edit the diff in the error message. Do not forget to remove the old .shlibs file. While that's enough to be useful for next versions, it's certainly not to be useful to relax current dependencies in unstable. Using the various files from mole[1] should be used as a base template, though the versioning given by mole is wrong (the symbols file it gives contain the debian revisions while they shouldn't) Mike 1. http://qa.debian.org/cgi-bin/mole/seedsymbols -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628145812.gb29...@glandium.org
Re: xulrunner 1.9.2 into sid?
Le 28/06/2010 11:35, Marco d'Itri a écrit : On Jun 28, Mike Hommeym...@glandium.org wrote: Unfortunately, as xpcom is guaranteed forward compatible but not backwards compatible, some plugins and extensions, once built against xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This would leave iceape users with a bitter aftertaste. Alternatively, And how would this be worse than shipping a version of iceweasel which is already obsolete? Who actually cares about iceape? If there is no manpower to do better than this then I feel that it would be more honest to just use volatile. FWIW, I have been using iceweasel 3.6 since it has been uploaded and it works *much* better than 3.5 did, which was slow and crashed a lot. I agree : on 64bit systems Iceweasel 3.5 is way too slow, and Iceweasel 3.6 should be included in Squeeze. For Icedove 3.0, it's a beta no ? I would prefer Icedove 2.0 or Icedove 3.1 in Squeeze, but really not Icedove 3.0. Have this packages in unstable or testing is not a huge problem, but do not release that in stable please ! Of course I'm ok to give some help to avoid that... if I can be usefull. Olivier B. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c28c5fc@daevel.fr
Re: xulrunner 1.9.2 into sid?
On Mon, Jun 28, 2010 at 02:35, Marco d'Itri m...@linux.it wrote: On Jun 28, Mike Hommey m...@glandium.org wrote: Unfortunately, as xpcom is guaranteed forward compatible but not backwards compatible, some plugins and extensions, once built against xulrunner 1.9.2, are likely to not work in iceape 2.0 anymore. This would leave iceape users with a bitter aftertaste. Alternatively, And how would this be worse than shipping a version of iceweasel which is already obsolete? Who actually cares about iceape? I would say I care, but I use Mozilla nightlies straight from ftp.mozilla.org... But if current stable doesn't have iceape, anyone on stable that wants it must be doing something else anyway, so I'm not sure it's that big a deal. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktili6xjjh5ckitbdcdj3hipmnvo8r37bjynto...@mail.gmail.com
Re: xulrunner 1.9.2 into sid?
On lun., 2010-06-28 at 17:55 +0200, Olivier Bonvalet wrote: I agree : on 64bit systems Iceweasel 3.5 is way too slow, and Iceweasel 3.6 should be included in Squeeze. Thank you for volunteering, I'm sure Mike will take all the help you'll give. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
