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 vul
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. Serio
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 [2010-06-29 21:50:31 CEST]:
> On Tue, 29 Jun 2010 20:58:11 +0200, Alexander
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 recompil
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
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 ba
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 s
Michael Gilbert 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 t
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 packa
On Tue, Jun 29, 2010 at 10:39:20PM +0200, Gerfried Fuchs wrote:
> * Philipp Kern [2010-06-28 11:55:22 CEST]:
> > On 2010-06-28, Marco d'Itri 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 ca
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
On Tue, 29 Jun 2010 22:25:06 +0200, Gerfried Fuchs wrote:
> Hi!
>
> * Michael Gilbert [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 packag
On Tue, Jun 29, 2010 at 3:50 PM, Michael Gilbert
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 pol
* Philipp Kern [2010-06-28 11:55:22 CEST]:
> On 2010-06-28, Marco d'Itri 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.
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
Hi!
* Michael Gilbert [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 pol
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 relea
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
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...
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
>
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 ar
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
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 w
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 d
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
On 2010-06-29, 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
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-
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
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 possibl
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 an
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
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.
> >
> >
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 .
.
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,
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
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 subjecte
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 a
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
>
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 unfortun
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 go
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 Sea
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: Th
On Mon, Jun 28, 2010 at 02:35, Marco d'Itri wrote:
> On Jun 28, Mike Hommey 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
Le 28/06/2010 11:35, Marco d'Itri a écrit :
On Jun 28, Mike Hommey 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
On Mon, Jun 28, 2010 at 02:29:54PM +0200, Marco d'Itri wrote:
> On Jun 28, PICCA Frédéric-Emmanuel
> 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
> th
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
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/libf
On 28/06/2010 14:29, Marco d'Itri wrote:
> On Jun 28, PICCA Frédéric-Emmanuel
> 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 c
On Jun 28, PICCA Frédéric-Emmanuel
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,
Marc
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'
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
bian-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 wrote:
> Speaking of backports, a way to streamline packages from testing to
> backports would be very much helpful for packages like iceweasel, where
> ba
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 i
On Jun 28, Mike Hommey 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
On Mon, Jun 28, 2010 at 09:55:22AM +, Philipp Kern wrote:
> On 2010-06-28, Marco d'Itri 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,
On Mon, Jun 28, 2010 at 11:35:17AM +0200, Marco d'Itri wrote:
> On Jun 28, Mike Hommey 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
On 2010-06-28, Marco d'Itri 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 mea
On Jun 28, Mike Hommey 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. Alter
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.
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 dep
60 matches
Mail list logo