On Mon, 2 Feb 2009 18:55:32 + Stephen Gran wrote:
>This one time, at band camp, Michael Tautschnig said:
>> There is just a slightly archive-specific problem: A package in main
>> must not depend on something outside main (at least so I guess, I
>> couldn't find the docs stating this rightaway
Stephen Gran wrote:
> This one time, at band camp, Michael Tautschnig said:
>> There is just a slightly archive-specific problem: A package in main
>> must not depend on something outside main (at least so I guess, I
>> couldn't find the docs stating this rightaway). We'd thus need some
>> clamav p
This one time, at band camp, Michael Tautschnig said:
> There is just a slightly archive-specific problem: A package in main
> must not depend on something outside main (at least so I guess, I
> couldn't find the docs stating this rightaway). We'd thus need some
> clamav package in main, and not on
Michael Tautschnig wrote:
> There is just a slightly archive-specific problem: A package in main must not
> depend on something outside main (at least so I guess, I couldn't find the
> docs
> stating this rightaway). We'd thus need some clamav package in main, and not
> only in volatile. Which mor
This one time, at band camp, Scott Kitterman said:
> One question I have (I have not dealt with volatile before) is about
> support for multiple releases. Does it have separate pockets for stable
> and oldstable?
Yes, it's a (semi-)standard dak install, so it understands all the
release stuff j
On Sat, 31 Jan 2009 12:56:43 +0100 Michael Tautschnig wrote:
>[...]
>> >
>> > We had discussed this during the Security Team meeting in Essen: We
believe
>> > clamav shouldn't be included in stable; malware scan engines are a
constantly
>> > moving target and it's pointless to backport changes
> Michael Tautschnig wrote:
> > [...] (nice technical insight)
> >> In my opinion all the programs with the ability to talk to clamd (or to
> >> invoke clamscan/clamdscan) can be safely left under stable. The user has
> >> still got the ability to use an updated clamav from volatile with no
> >> pr
Michael Tautschnig wrote:
> [...] (nice technical insight)
>> In my opinion all the programs with the ability to talk to clamd (or to
>> invoke clamscan/clamdscan) can be safely left under stable. The user has
>> still got the ability to use an updated clamav from volatile with no
>> problems at al
[...] (nice technical insight)
>
> In my opinion all the programs with the ability to talk to clamd (or to
> invoke clamscan/clamdscan) can be safely left under stable. The user has
> still got the ability to use an updated clamav from volatile with no
> problems at all.
> On the other hand, progr
[...]
> >
> > We had discussed this during the Security Team meeting in Essen: We believe
> > clamav shouldn't be included in stable; malware scan engines are a
> > constantly
> > moving target and it's pointless to backport changes since new signatures
> > constantly require new scan engine feat
[...]
>
> I maintain klamav. As I understand it, DM's don't have upload rights to
> volatile. I don't really have time to deal with sponsorship hassles
> currently, so I'd probably orphan the package.
>
I don't think that these issues should be considered showstoppers for a move to
volatile.
On Thu, Jan 29, 2009 at 07:01:38PM +, Stephen Gran wrote:
> This one time, at band camp, Philipp Kern said:
> > On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote:
> > > I maintain klamav. As I understand it, DM's don't have upload rights to
> > > volatile. I don't really have t
This one time, at band camp, Philipp Kern said:
> On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote:
> > I maintain klamav. As I understand it, DM's don't have upload rights to
> > volatile. I don't really have time to deal with sponsorship hassles
> > currently, so I'd probably o
On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote:
> I maintain klamav. As I understand it, DM's don't have upload rights to
> volatile. I don't really have time to deal with sponsorship hassles
> currently, so I'd probably orphan the package.
So clamav is not sufficently modular
On Wed, 28 Jan 2009 23:00:04 +0100 Alexander Wirt
wrote:
>Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009:
>
>> On 2009-01-25, Michael Tautschnig wrote:
>> >
>> > --===6401238421216507687==
>> > Content-Type: multipart/signed; micalg=pgp-sha1;
>> >protocol="applicat
Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009:
> On 2009-01-25, Michael Tautschnig wrote:
> >
> > --===6401238421216507687==
> > Content-Type: multipart/signed; micalg=pgp-sha1;
> > protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6"
> > Content-Dispo
On 2009-01-25, Michael Tautschnig wrote:
>
> --===6401238421216507687==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6"
> Content-Disposition: inline
>
>
> --UfEAyuTBtIjiZzX6
> Content-Type: text/plain; charse
Stephen Gran wrote:
> This one time, at band camp, Martin Schulze said:
> > Michael Tautschnig wrote:
> > > In the clamav packaging team we had recurring discussion about how to
> > > deal with
> > > clamav in the near (== lenny) and more distant (>= squeeze) future. The
> > > current
> > > situa
This one time, at band camp, Martin Schulze said:
> Michael Tautschnig wrote:
> > In the clamav packaging team we had recurring discussion about how to deal
> > with
> > clamav in the near (== lenny) and more distant (>= squeeze) future. The
> > current
> > situation is as follows:
> >
> > - We'
Michael Tautschnig wrote:
> In the clamav packaging team we had recurring discussion about how to deal
> with
> clamav in the near (== lenny) and more distant (>= squeeze) future. The
> current
> situation is as follows:
>
> - We've got severly outdated clamav packages in etch(-security).
> - A
Dear Release Team,
In the clamav packaging team we had recurring discussion about how to deal with
clamav in the near (== lenny) and more distant (>= squeeze) future. The current
situation is as follows:
- We've got severly outdated clamav packages in etch(-security).
- A few packages depend on c
21 matches
Mail list logo
