Marc,
On Sat, Oct 16, 2004 at 10:23:34PM +0200, Marc Haber wrote:
On Fri, 15 Oct 2004 14:47:30 +0100, paddy [EMAIL PROTECTED] wrote:
While this solution may be preferable for some uses, I think what bothers
me is the lack of a simpler solution. Is there really compelling reason
why all such
On Fri, 15 Oct 2004 14:47:30 +0100, paddy [EMAIL PROTECTED] wrote:
While this solution may be preferable for some uses, I think what bothers
me is the lack of a simpler solution. Is there really compelling reason
why all such files _must_ go into package-management?
I consider that way as
On Thu, Oct 14, 2004 at 09:47:02PM +0200, Marc Haber wrote:
On Mon, 11 Oct 2004 12:09:01 +0100, paddy [EMAIL PROTECTED] wrote:
On Sun, Oct 10, 2004 at 02:50:35PM +0200, Marc Haber wrote:
The clean way would be to build .deb files from the downloaded
plugins, and to install them via the
On Mon, 11 Oct 2004 12:09:01 +0100, paddy [EMAIL PROTECTED] wrote:
On Sun, Oct 10, 2004 at 02:50:35PM +0200, Marc Haber wrote:
The clean way would be to build .deb files from the downloaded
plugins, and to install them via the package management.
I don't believe that everything can, will and
On Mon, Oct 11, 2004 at 04:30:36PM -0400, Stephen Gran wrote:
This one time, at band camp, paddy said:
On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote:
This one time, at band camp, Martin Schulze said:
A while ago there was a discussion in which it was said that such
On Sun, Oct 10, 2004 at 02:50:35PM +0200, Marc Haber wrote:
On Fri, 8 Oct 2004 10:59:39 +0100, paddy [EMAIL PROTECTED] wrote:
On Wed, Sep 15, 2004 at 09:37:57AM +0200, Marc Haber wrote:
It will also happily write to /usr which is IMO a no-no for user
binaries.
Where should it write to ?
On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote:
This one time, at band camp, Martin Schulze said:
A while ago there was a discussion in which it was said that such
tools are rather useless (or even dangerous) if they don't get their
database updated in accordance with new
This one time, at band camp, paddy said:
On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote:
This one time, at band camp, Martin Schulze said:
A while ago there was a discussion in which it was said that such
tools are rather useless (or even dangerous) if they don't get their
On Fri, 8 Oct 2004 10:59:39 +0100, paddy [EMAIL PROTECTED] wrote:
On Wed, Sep 15, 2004 at 09:37:57AM +0200, Marc Haber wrote:
It will also happily write to /usr which is IMO a no-no for user
binaries.
Where should it write to ?
Would /var/lib or /usr/local be right ?
/usr/local is the domain
On Sun, 3 Oct 2004 12:36:48 +0200, Francesco Paolo Lovergine
[EMAIL PROTECTED] wrote:
Not always. In the past many backports have been built including perfectly
avoidable new dependencies. The volatile archive should have policy and
deb tools frozen. So no new debconf, no new ucf and so on.
In
On Sun, Oct 10, 2004 at 02:53:58PM +0200, Marc Haber wrote:
On Sun, 3 Oct 2004 12:36:48 +0200, Francesco Paolo Lovergine
[EMAIL PROTECTED] wrote:
Not always. In the past many backports have been built including perfectly
avoidable new dependencies. The volatile archive should have policy and
On Fri, Oct 08, 2004 at 04:44:05PM -0700, Thomas Bushnell BSG wrote:
paddy [EMAIL PROTECTED] writes:
But, I can see the case, as I describe before, where achieving the function
of a package places great pressure on the time to package, so much so that
if an interim, first cut package can
Thomas Bushnell BSG [u] wrote on 08/10/2004 18:18:
Will Lowe [EMAIL PROTECTED] writes:
My argument is just that even if you backport the important features
of a new release into an old codebase, it's hard to make any valuable
claims about the resulting product if the backport changes more than
a
The draft looks good, Sven. Please also include target # 5 as follows.
Draft for a volatile.debian.org packaging and update policy.
Target:
volatile.debian.org (or short: v.d.o) is intended to be a repository for
packages which degrade over time with respect to their usefulness. These
Sven Mueller [EMAIL PROTECTED] writes:
Doing a backport of some upstream change is usually a pretty difficult
task (except for smaller security fixes). It's pretty easy to claim
no new command line feature added, but it is pretty difficult to
claim no new bugs added or all necessary security
On Thu, Oct 07, 2004 at 02:58:05PM -0700, Thomas Bushnell BSG wrote:
I assume you mean use unstable? see below.
No, you can simply use private repositories, or backports, or whatever
else. There need be no Debian-branding of it in any way. What Debian
gives people is some kind of
On Wed, Sep 15, 2004 at 09:37:57AM +0200, Marc Haber wrote:
On Mon, 13 Sep 2004 16:13:25 +0200, Javier Fernández-Sanguino Peña
[EMAIL PROTECTED] wrote:
On Mon, Sep 13, 2004 at 03:40:51PM +0200, Martin Schulze wrote:
Have you thought about keeping these packages out of sarge or did you
On Wed, Oct 06, 2004 at 11:32:05PM +0200, Andreas Barth wrote:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041006 23:25]:
Unfortunately, most of what I have seen has been an attempt to have a
new place that involves no actual backporting and publicity work,
rather than volunteering to take
Thomas, Jesus,
I feel I owe you both and the list an apology for my last post here.
It falls below the standard I would aspire to achieving in terms
of courtesy, and that I'm sure you both deserve.
Additionally, I have not only completely missed the point, but
done no more than interupt in
On Wed, Oct 06, 2004 at 11:32:05PM +0200, Andreas Barth wrote:
Actually, I'm considering very much to pick the task up (and have also
already volatile.d.n ;), but there are some issues that needs to be
considered before doing a public announcement.
Andi,
Another observation:
Three months is
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
What are the pros and cons for
volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a rolling-when-its-ready
model more like security.d.o ?
well, not exactly an all at once, but having not just a random
Andi,
On Fri, Oct 08, 2004 at 03:15:29PM +0200, Andreas Barth wrote:
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
What are the pros and cons for
volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a rolling-when-its-ready
model more like
Hi,
* paddy ([EMAIL PROTECTED]) [041008 16:05]:
On Fri, Oct 08, 2004 at 03:15:29PM +0200, Andreas Barth wrote:
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
What are the pros and cons for
volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a
PLAN FOR MAINTENANCE OF A VOLATILE ARCHIVE
==
There is a 'list of packages' for the archive. Packages going onto the list
must satisfy the criteria:
utility is very sensisitive to and derives from,
in a very great part, it's
Jesus Climent [EMAIL PROTECTED] writes:
Except that those private repositories and backports have no policy
and no maintenance. My proposal is to create a policy for a
repository with maintenance, security updates which introduces new
packages and provides new functionality on outdated or
Will Lowe [EMAIL PROTECTED] writes:
My argument is just that even if you backport the important features
of a new release into an old codebase, it's hard to make any valuable
claims about the resulting product if the backport changes more than
a few lines of code.
This is true if you don't
Thomas Bushnell BSG [EMAIL PROTECTED] - Fri, Oct 08, 2004:
My proposal is to create a policy for a
repository with maintenance, security updates which introduces new
packages and provides new functionality on outdated or useless
packages from stable, and is built
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041008 18:20]:
In other words, it sounds like the whole virus-scanner bit is a red
herring, and what you actually want is just a repository that doesn't
have the stability restrictions that Debian normally has. Maybe
that's a good idea, but it needs
Loc Minier [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] - Fri, Oct 08, 2004:
My proposal is to create a policy for a
repository with maintenance, security updates which introduces new
packages and provides new functionality on outdated or useless
On Fri, Oct 08, 2004 at 09:17:44AM -0700, Thomas Bushnell BSG wrote:
Suppose a nifty new emacs feature is developed; why should that new
functionality be excluded from this repository you are speaking of,
merely because it isn't a security update?
Because, even if they are not security
On Fri, Oct 08, 2004 at 09:25:33AM -0700, Thomas Bushnell BSG wrote:
Loïc Minier [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] - Fri, Oct 08, 2004:
My proposal is to create a policy for a
repository with maintenance, security updates which
Jesus Climent [EMAIL PROTECTED] writes:
On Fri, Oct 08, 2004 at 09:17:44AM -0700, Thomas Bushnell BSG wrote:
Suppose a nifty new emacs feature is developed; why should that new
functionality be excluded from this repository you are speaking of,
merely because it isn't a security update?
paddy [EMAIL PROTECTED] writes:
But, I can see the case, as I describe before, where achieving the function
of a package places great pressure on the time to package, so much so that
if an interim, first cut package can achieve this most effectively
(ie: quickest) by shipping upstream
On Fri, Oct 08, 2004 at 04:43:03PM -0700, Thomas Bushnell BSG wrote:
This is an argument for why we ought to do what makes the package
useful (keep the virus definitions up-to-date, and add what new things
are necessary for that purpose), but is no argument for making other
unrelated
Thomas == Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Thomas And this means that the maintainer/whoever must do the
Thomas potentially hard work of backporting particular changes
Thomas and not others from upstream releases; merely including a
Thomas new upstream release is not
This one time, at band camp, Thomas Bushnell BSG said:
Stephen Gran [EMAIL PROTECTED] writes:
Well, the problem is that the procedure that we have is called
backports.org, or private repositories. I agree that we also have a
lack of an agreed upon maintenance strategy, but I respectfully
Stephen Gran [EMAIL PROTECTED] writes:
This archive (as-yet-to-be-named.debian.{org,net}) is intended for
packages that must, because of the nature of the modern internet, change
more rapidly than the standard release policy allows. This archive is
definitely _not_ the security archive, as
On Wed, Oct 06, 2004 at 09:42:30AM -0700, Thomas Bushnell BSG wrote:
I'm not saying we must do it at all. I'm saying that security is the
responsibility of the security team, and not debian-devel. Having not
heard from the security team what they think, and this apparent
reluctance to
On Wednesday 06 October 2004 04:12 pm, Thomas Bushnell BSG wrote:
For example, a new set of virus definitions, we are told, may include
a new library and a new strategy for catching viruses. Makes sense
to me. But when you add that, are you just going to add in the
latest upstream version
On Wed, Oct 06, 2004 at 04:12:48PM -0700, Thomas Bushnell BSG wrote:
In other words, are your upgrades going to be install the latest
upstream, or are they going to be fetch the relevant new things from
upstream and put them in the old thing? I agree completely that the
latter is more work,
* Jesus Climent ([EMAIL PROTECTED]) [041007 13:10]:
On Wed, Oct 06, 2004 at 04:12:48PM -0700, Thomas Bushnell BSG wrote:
In other words, are your upgrades going to be install the latest
upstream, or are they going to be fetch the relevant new things from
upstream and put them in the old
On Thu, Oct 07, 2004 at 09:41:13AM +0200, Javier Fernández-Sanguino Peña wrote:
If you feel AV scanners, IDS and similar software is not as up-to-date as
it should be then, by all means, help making release cycles shorter [3]
Maybe shorter cycles of 10K+ packages are not possible. Or even
also sprach Jesus Climent [EMAIL PROTECTED] [2004.10.07.1319 +0200]:
Again, i have the strong feeling that to produce shorter release
cycles we need a core system to take intensive care of.
ubuntu?
/me ducks
--
Please do not CC me when replying to lists; I read them!
.''`. martin f.
On Oct 07, Andreas Barth [EMAIL PROTECTED] wrote:
This policy is even not ok for a normal major debian upgrade. We have
exim and exim4, we have inn and inn2 for exactly that reason, and we should
also provide spamassassin and spamassassin3. This doesn't mean that
inn supports just about every
On Oct 07, Jesus Climent [EMAIL PROTECTED] wrote:
Again, i have the strong feeling that to produce shorter release cycles we
need a core system to take intensive care of.
Looks like the Ubuntu people are going to do this, and do it well.
--
ciao, |
Marco | [8404 omm/6rqm1mkGQ]
signature.asc
On Thu, Oct 07, 2004 at 01:16:30PM +0200, Andreas Barth wrote:
It is my point of view that with volatile in place, the policy for allowing
updates on such repository could introduce things which break other apps.
This policy is even not ok for a normal major debian upgrade. We have
exim
Hi,
I admin a small system with mailscanner, spamassassin, clamav, etc.
I would dearly like to move the system as a whole to a debian sarge base,
and will likely do so, regardless of the outcome of this debate/process.
The outcome _will_ impact how I admin it in future.
On Thu, Oct 07, 2004 at
Brian Kimball [EMAIL PROTECTED] writes:
Who wants to install Spamassassin-more-than-2-but-not-quite-3?
Snort-more-than-2.2-but-not-yet-2.3? This will just confuse your users
and piss off upstream.
Can you explain why ssh shouldn't be upgraded the same way?
On Thu, Oct 07, 2004 at 09:30:16AM -0700, Thomas Bushnell BSG wrote:
Brian Kimball [EMAIL PROTECTED] writes:
Who wants to install Spamassassin-more-than-2-but-not-quite-3?
Snort-more-than-2.2-but-not-yet-2.3? This will just confuse your users
and piss off upstream.
Can you explain
Jesus Climent [EMAIL PROTECTED] writes:
Because ssh-from-woody-plus-security-updates is not as useless as
spamassassin-from-woody-which-has-changed-so-much-that-is-impossible-to-backport-anything?
It seems to me that impossible is being used in a strange sense
here.
Part of maintaining a
[ do NOT reply to my mail, i am subscribed to the list ]
On Thu, Oct 07, 2004 at 12:11:32PM -0700, Thomas Bushnell BSG wrote:
It seems to me that impossible is being used in a strange sense
here.
Well, backporting the bayes which was introduced in 2.5x does not sound like
something you want
On Thu, Oct 07, 2004 at 12:11:32PM -0700, Thomas Bushnell BSG wrote:
Jesus Climent [EMAIL PROTECTED] writes:
Because ssh-from-woody-plus-security-updates is not as useless as
spamassassin-from-woody-which-has-changed-so-much-that-is-impossible-to-backport-anything?
It seems to me that
On Thu, Oct 07, 2004 at 09:35:38PM +0200, Jesus Climent wrote:
[ do NOT reply to my mail, i am subscribed to the list ]
On Thu, Oct 07, 2004 at 12:11:32PM -0700, Thomas Bushnell BSG wrote:
It seems to me that impossible is being used in a strange sense
here.
Well, backporting the
Jesus Climent [EMAIL PROTECTED] writes:
Well, backporting the bayes which was introduced in 2.5x does not sound like
something you want to do. I rather put 2.5x which is supported by upstream,
not deprecated and has a bigger user-base and developer eyes on the code than
2.20. With all the
[ What part of do no reply to my email but to the list, since i am
subscribed you did not understand? ]
On Thu, Oct 07, 2004 at 01:00:39PM -0700, Thomas Bushnell BSG wrote:
Jesus Climent [EMAIL PROTECTED] writes:
But again, that might be just me.
What you are saying should apply to any
On Thu, Oct 07, 2004 at 08:59:22PM +0100, paddy wrote:
How would one decide which features to backport, and which not?
The ones that the maintainer of the package decides is the best for
keeping the package which will update in stable usable, as long as the
packages is created against stable,
On Thu, Oct 07, 2004 at 10:26:40PM +0200, Jesus Climent wrote:
On Thu, Oct 07, 2004 at 08:59:22PM +0100, paddy wrote:
How would one decide which features to backport, and which not?
The ones that the maintainer of the package decides is the best for
keeping the package which will update
Jesus Climent [EMAIL PROTECTED] writes:
2.20 became useless because spammers reacted to most of the rules developed,
since it did not have any learning engine. It needed new rules, new rules
needed new functions in the core code (not just rules updates) and new
functions needed new perl
Part of maintaining a virus scanner may well include backporting
things, and that may be a fair bit of work to do. There are
But that doesn't mean that stability has become less important, it
At one point do we decide that the backport may have had a significant
impact on stability?
Say
Will Lowe [EMAIL PROTECTED] writes:
Say someone implements a significant new feature in spamassassin to
handle a particularly virulent new kind of spam, and this new feature
doubles the code size of the source. It's probably possible to rip
that new code out of the upstream source and
On Thu, Oct 07, 2004 at 01:54:11PM -0700, Thomas Bushnell BSG wrote:
This is an excellent argument for upgrading that part. It is no
argument for including new command line features, hookins to other
parts of the system, or other arbitrary features that might be added.
It is an argument is
On Thu, Oct 07, 2004 at 01:54:19PM -0700, Will Lowe wrote:
Say someone implements a significant new feature in spamassassin to
handle a particularly virulent new kind of spam, and this new feature
doubles the code size of the source. It's probably possible to rip
that new code out of the
Jesus Climent [EMAIL PROTECTED] writes:
And no, is not impossible but IT WILL NEVER get to stable, since it
is against the current stable policy.
Do you want to change that policy? Start moving strings and contacting the
involved parties to get such a change. Until the, no security backports
On Thu, Oct 07, 2004 at 02:22:18PM -0700, Thomas Bushnell BSG wrote:
If you want something which is simply unrestricted, you have that
now, no need for any changes to anything.
I assume you mean use unstable? see below.
Right, but why not just use unstable?
I asked this question earlier,
paddy [EMAIL PROTECTED] writes:
On Thu, Oct 07, 2004 at 02:22:18PM -0700, Thomas Bushnell BSG wrote:
If you want something which is simply unrestricted, you have that
now, no need for any changes to anything.
I assume you mean use unstable? see below.
No, you can simply use private
Thomas,
On Thu, Oct 07, 2004 at 02:58:05PM -0700, Thomas Bushnell BSG wrote:
paddy [EMAIL PROTECTED] writes:
On Thu, Oct 07, 2004 at 02:22:18PM -0700, Thomas Bushnell BSG wrote:
If you want something which is simply unrestricted, you have that
now, no need for any changes to anything.
Programming is not a matter of ripping out code. Backporting
requires actually understanding all the changes, not some kind of
mechanical process.
Ok, point taken.
My argument is just that even if you backport the important features
of a new release into an old codebase, it's hard to make
Colin Watson [EMAIL PROTECTED] wrote:
FWIW, I think that every upload to the security archive should be
accompanied by a security advisory. I wouldn't be at all surprised if
the security team felt that uploads that don't merit security advisories
were an inappropriate use of their archive.
Colin Watson [EMAIL PROTECTED] writes:
On Tue, Oct 05, 2004 at 12:08:42PM -0700, Thomas Bushnell BSG wrote:
Stephen Gran [EMAIL PROTECTED] writes:
I am under the impression that 'normal procedures' does not involve
updating the application to catch new threats. If I'm wrong, then there
This one time, at band camp, Thomas Bushnell BSG said:
Colin Watson [EMAIL PROTECTED] writes:
FWIW, I think that every upload to the security archive should be
accompanied by a security advisory. I wouldn't be at all surprised if
the security team felt that uploads that don't merit security
Stephen Gran [EMAIL PROTECTED] writes:
I thought that 'issues related to the development of debian' was on topic
for this list. It is not at all clear to me that this is a security
issue, because outdated A/V software usually does not place the server
it runs on at risk for compromise.
We
also sprach Thomas Bushnell BSG [EMAIL PROTECTED] [2004.10.06.2133 +0200]:
I think (1) is true, and I think both (A) and (B) are true. I am
not sure about (2), but I do understand why people are arguing for
it. If they are correct, then it seems to me that the security
archive is already an
This one time, at band camp, Thomas Bushnell BSG said:
Stephen Gran [EMAIL PROTECTED] writes:
I thought that 'issues related to the development of debian' was on topic
for this list. It is not at all clear to me that this is a security
issue, because outdated A/V software usually does
On 06 Oct 2004 12:33:42 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] said:
Stephen Gran [EMAIL PROTECTED] writes:
I thought that 'issues related to the development of debian' was on
topic for this list. It is not at all clear to me that this is a
security issue, because outdated A/V
martin f krafft [EMAIL PROTECTED] writes:
I think the problem is not so much whether s.d.o is the right place,
but rather whether anti-virus stuff can go in there. Security fixes
are backported to ensure no new features trickle in and to minimise
changes. With AV software and the like, this
Stephen Gran [EMAIL PROTECTED] writes:
What I (and it seems, others) would like to see is:
3) some other method to upgrade software that has to change rapidly to
meet new classes of threats, even though these threats may not affect
the machine running the software itself. This category
Manoj Srivastava [EMAIL PROTECTED] writes:
Well, while this may well be analogous, it is far from being
the same thing, and I don't think the security team should be saddled
with yet another task.
I am happy to agree that the brunt of meeting the new work is upon the
proposers of the
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041006 23:25]:
Unfortunately, most of what I have seen has been an attempt to have a
new place that involves no actual backporting and publicity work,
rather than volunteering to take that load on.
Actually, I'm considering very much to pick the task
This one time, at band camp, Thomas Bushnell BSG said:
Manoj Srivastava [EMAIL PROTECTED] writes:
Well, while this may well be analogous, it is far from being
the same thing, and I don't think the security team should be saddled
with yet another task.
I am happy to agree that the
This one time, at band camp, Thomas Bushnell BSG said:
Stephen Gran [EMAIL PROTECTED] writes:
What I (and it seems, others) would like to see is:
3) some other method to upgrade software that has to change rapidly to
meet new classes of threats, even though these threats may not affect
Stephen Gran [EMAIL PROTECTED] writes:
Well, the problem is that the procedure that we have is called
backports.org, or private repositories. I agree that we also have a
lack of an agreed upon maintenance strategy, but I respectfully disagree
that we have either a team or an archive at
Stephen Gran [EMAIL PROTECTED] writes:
Hmm, I rather thought that several people, myself included, had offered
to take on the work of doing what we thought was valuable, and you have
been trying to push it off on the security team over strenuous
objections that it is not their job.
No, you
also sprach Matthew Garrett [EMAIL PROTECTED] [2004.10.05.0015 +0200]:
We can push neither of them into Debian via security.d.o. No,
sorry, this is not the way stable works.
/Should/ it be the way stable works? We have the ability to change
that.
No. It's stable. It's one of the major
also sprach Norbert Tretkowski [EMAIL PROTECTED] [2004.10.05.0018 +0200]:
Some quick dirty perl and shell scripts. I plan to completely
rewrite these scripts in python soon.
Superb. It would rock if you could make this available as a package
(which I am sure you will). I think many of use
clamav can be as stable as a rock but be completely useless... when
two months after Sarge's release, a new virus hits hard, and in
order to detect it, clamav needs libfoo, which is not in Debian.
What then? *Maybe* we could push a new clamav via security.d.o, but
what about libfoo?
also sprach John Lines [EMAIL PROTECTED] [2004.10.05.0828 +0200]:
You could take the rather horrible step of building a static copy
of libfoo into clamav. This would be rather messy, but would allow
a single binary to be updated.
The problem is not so much that a new dependency would be needed
On Tue, Oct 05, 2004 at 07:28:21AM +0100, John Lines wrote:
clamav can be as stable as a rock but be completely useless... when
two months after Sarge's release, a new virus hits hard, and in
order to detect it, clamav needs libfoo, which is not in Debian.
What then? *Maybe* we
On Mon, Oct 04, 2004 at 11:46:29PM +0200, Andreas Barth wrote:
* Francesco Paolo Lovergine ([EMAIL PROTECTED]) [041004 19:40]:
What we probably need is the infrastructure to support the volatile
archive (buildd support and pools) and a general policy for those kind
of updates. Program
On Tue, Oct 05, 2004 at 07:54:51AM +0200, martin f krafft wrote:
also sprach Matthew Garrett [EMAIL PROTECTED] [2004.10.05.0015 +0200]:
We can push neither of them into Debian via security.d.o. No,
sorry, this is not the way stable works.
/Should/ it be the way stable works? We have
* Thiemo Seufer:
How could clamav possibly have a stable engine and suddenly start to
need libfoo?
Most antivirus software today is a framework for mobile code
distribution. Too often, you have to replace MIME decoders, HTTP
decoders, and the like.
I find it rather strange that new
Stephen Gran [EMAIL PROTECTED] writes:
This is exactly the problem. I don't think that most people actually
think it would be better to release either no AV/spam/whatever software
or useless software. I am getting the impression that people don't want
to disrupt the stability of the rest of
This one time, at band camp, Thomas Bushnell BSG said:
Stephen Gran [EMAIL PROTECTED] writes:
This is exactly the problem. I don't think that most people actually
think it would be better to release either no AV/spam/whatever software
or useless software. I am getting the impression
Stephen Gran [EMAIL PROTECTED] writes:
I am under the impression that 'normal procedures' does not involve
updating the application to catch new threats. If I'm wrong, then there
is no need for this entire thread.
Talk to the security team. Talk to the security team. Talk to the
security
On Tue, Oct 05, 2004 at 12:08:42PM -0700, Thomas Bushnell BSG wrote:
Stephen Gran [EMAIL PROTECTED] writes:
I am under the impression that 'normal procedures' does not involve
updating the application to catch new threats. If I'm wrong, then there
is no need for this entire thread.
Talk
[i am sorry for the empty message; this was the content i meant to
send]
also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.04.2336 +0200]:
Frankly speaking, the question whether to include clamav or not in
sarge is IMHO not a question whether volatile exists or not.
Either clamav is stable
Andreas Barth [EMAIL PROTECTED] wrote:
We can push neither of them into Debian via security.d.o. No, sorry,
this is not the way stable works.
/Should/ it be the way stable works? We have the ability to change that.
Providing that we only do it for the set of software that would
otherwise be
* martin f krafft wrote:
Adam D. Barratt:
http://backports.org/debian/dists/woody/spamassassin/binary-i386/Packages.gz
contains debconf{,-{doc,utils}} 1.2.35 as well as the SpamAssassin
packages. All other dependencies can (iirc) be fulfilled from
stock woody.
That's nifty!
What
This one time, at band camp, Andreas Barth said:
* Stephen Gran ([EMAIL PROTECTED]) [041004 17:10]:
So, now that this thread has been going on for a little while, I wanted
to see what the consensus among RM's is: are we going to allow updates
for these programs in sarge or do we have to
This one time, at band camp, Matthew Garrett said:
Andreas Barth [EMAIL PROTECTED] wrote:
We can push neither of them into Debian via security.d.o. No, sorry,
this is not the way stable works.
/Should/ it be the way stable works? We have the ability to change that.
Providing that we
99 matches
Mail list logo
