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 only
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 package
On Mon, 2 Feb 2009 18:55:32 + Stephen Gran sg...@debian.org 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
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 more or
[...]
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. I
[...]
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 features all
[...] (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, programs
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 all.
On
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 all.
On Sat, 31 Jan 2009 12:56:43 +0100 Michael Tautschnig m...@debian.org 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
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
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
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 orphan
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 time to
On 2009-01-25, Michael Tautschnig m...@debian.org wrote:
--===6401238421216507687==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol=application/pgp-signature; boundary=UfEAyuTBtIjiZzX6
Content-Disposition: inline
--UfEAyuTBtIjiZzX6
Content-Type: text/plain;
Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009:
On 2009-01-25, Michael Tautschnig m...@debian.org wrote:
--===6401238421216507687==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol=application/pgp-signature; boundary=UfEAyuTBtIjiZzX6
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
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 few
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've got severly
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
situation is as
20 matches
Mail list logo