On 9/13/11 4:52 PM, Chris Rees wrote:
> I'm rather tired of being called to defend myself,
I see no reason why you should find it necessary. Bravo for the work
you've done.
> I've plenty of better things to be doing.
>
Agreed. Julian, amongst others this past few weeks, have successfully
made
Matthias Andree wrote:
> claim, please fix, until end 2011, in mail/procmail, in collaboration
> with sunpoet@:
Procmail works for me, for a friend, & others on list.
It was & remains irresponsible to try to force satisfied users to fix other
people's reported problems on threat of ports being ot
-hominem, and please don't
> > >> think you're upsetting anyone in the slightest with them.
> > >>
> > >> Use rational and technical arguments, or take a break.
> > >>
> > >> Chris
> > >
> > > Your proposal to remo
Your proposal to remove procmail among others was ridiculous.
> > Please consider resigning Chris.
> >
>
> Not mine.
>
> Please consider reading mailing lists properly rather than jumping to
> conclusions.
>
> Chris
Chris Rees You are False. You posted this:
h
Chris Rees wrote:
> On 12 September 2011 22:18, Julian H. Stacey wrote:
> > Matthias Andree wrote:
> >> >> An obscure piece of software is undesirable (and shouldn't be ported in
> >> >> the first place).
> >> >
> >> > Bullshit!
> >>
> >> I think that suffices. If the discussion is getting emotio
On 13 September 2011 18:54, Julian H. Stacey wrote:
> Hi,
> Reference:
>> From: Chris Rees
>> Date: Tue, 13 Sep 2011 18:44:37 +0100
>> Message-id:
>>
>
> Chris Rees wrote:
>> On 12 September 2011 22:18, Julian H. Stacey wrote:
>> > Matthias Andree wrote:
>> >> >> An obscure p
Hi,
Reference:
> From: Chris Rees
> Date: Tue, 13 Sep 2011 18:44:37 +0100
> Message-id:
>
Chris Rees wrote:
> On 12 September 2011 22:18, Julian H. Stacey wrote:
> > Matthias Andree wrote:
> >> >> An obscure piece of software is undesirable (and shouldn't be ported in
> >>
On 12 September 2011 22:18, Julian H. Stacey wrote:
> Matthias Andree wrote:
>> >> An obscure piece of software is undesirable (and shouldn't be ported in
>> >> the first place).
>> >
>> > Bullshit!
>>
>> I think that suffices. If the discussion is getting emotional, we
>> should stop it.
>
> No.
On 12 September 2011 22:07, Julian H. Stacey wrote:
>> No, I won't tell you which window manager, because if I want to use it
>> again I don't want to discover that calling it to the minds of some of
>> the ports people caused it to be deleted.
>
> That summarises it. I too avoided mentioning a po
Am 12.09.2011 23:32, schrieb Julian H. Stacey:
> Hi,
>> If not, see to backups and/or migration in due time. We can't possibly
>> support software that is unsupported by the vendor, but that's what
>
> We already do. Been working just fine for many years. No I wont
> tell you where, because I do
On Mon, Sep 12, 2011 at 11:32:01PM +0200, Julian H. Stacey wrote:
> Please consider resigning.
plonk.
mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-
"Julian H. Stacey" writes:
Hi,
> We already do. Been working just fine for many years. No I wont
> tell you where, because I don't trust you & a few other irresponsible
> ports crusaders who should have their commit bits revoked to protect
> the FreeBSD we've held dear since before version numb
> No, I won't tell you which window manager, because if I want to use it
> again I don't want to discover that calling it to the minds of some of
> the ports people caused it to be deleted.
That summarises it. I too avoided mentioning a port for fear of the
immature kids who destroy ports. At lea
Matthias Andree wrote:
> >> An obscure piece of software is undesirable (and shouldn't be ported in
> >> the first place).
> >
> > Bullshit!
>
> I think that suffices. If the discussion is getting emotional, we
> should stop it.
No. You should stop advocating killing ports, or leave, or be revo
Hi,
> If not, see to backups and/or migration in due time. We can't possibly
> support software that is unsupported by the vendor, but that's what
We already do. Been working just fine for many years. No I wont
tell you where, because I don't trust you & a few other irresponsible
ports crusaders
Matthias Andree wrote:
> Am 10.09.2011 16:08, schrieb per...@pluto.rain.com:
> > Last I knew, if port X uses services provided by port Y and port
> > Y changes, port X often needs to be rebuilt and reinstalled even
> > though nothing in port X has changed. AFAIK this has nothing to
> > do with ba
On Sat, Sep 10, 2011 at 10:38:55PM +0200, Matthias Andree wrote:
> Am 10.09.2011 18:17, schrieb Chad Perrin:
> > On Sat, Sep 10, 2011 at 12:09:16PM +0200, Matthias Andree wrote:
> >>
> >> On the other hand, you're pointing out a problem of dead ports in the
> >> first place: if the API of (usually
On Sat, 10 Sep 2011 12:24:33 +0200
Matthias Andree wrote:
> Am 10.09.2011 07:45, schrieb Conrad J. Sabatier:
>
> >>> Frankly, I'm growing increasingly concerned that this push to
> >>> eliminate ports is getting out of control. I don't much care for
> >>> the notion that, having invested the ti
Am 10.09.2011 18:17, schrieb Chad Perrin:
> On Sat, Sep 10, 2011 at 12:09:16PM +0200, Matthias Andree wrote:
>>
>> On the other hand, you're pointing out a problem of dead ports in the
>> first place: if the API of (usually library) port Y changes, and port X
>> is unmaintained, that's typically a
On Sat, Sep 10, 2011 at 12:09:16PM +0200, Matthias Andree wrote:
>
> On the other hand, you're pointing out a problem of dead ports in the
> first place: if the API of (usually library) port Y changes, and port X
> is unmaintained, that's typically a situation where port X needs to be
> deprecated
On Sat, Sep 10, 2011 at 12:24:33PM +0200, Matthias Andree wrote:
>
> The open question is, is there a point in marking a point DEPRECATED
> without giving an expiration date. My personal answer is "no" because
> no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and
> people will be
Am 10.09.2011 07:45, schrieb Conrad J. Sabatier:
>>> Frankly, I'm growing increasingly concerned that this push to
>>> eliminate ports is getting out of control. I don't much care for
>>> the notion that, having invested the time in installing,
>>> configuring and tuning a certain set of software
>> An obscure piece of software is undesirable (and shouldn't be ported in
>> the first place).
>
> Bullshit!
I think that suffices. If the discussion is getting emotional, we
should stop it.
___
freebsd-ports@freebsd.org mailing list
http://lists.free
Am 10.09.2011 16:08, schrieb per...@pluto.rain.com:
> Last I knew, if port X uses services provided by port Y and port
> Y changes, port X often needs to be rebuilt and reinstalled even
> though nothing in port X has changed. AFAIK this has nothing to
> do with backups.
>
> If you've found a way
Matthias Andree wrote:
> Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
> > You fail to take into account the case where a port may need to
> > be reinstalled. An extraordinary effort is required if the port
> > no longer exists in the ports tree.
>
> If a "port may need to be reinstalled" then
On 10 September 2011 06:45, Conrad J. Sabatier wrote:
> On Fri, 09 Sep 2011 19:05:49 +0200
> Matthias Andree wrote:
>
>> Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
>> > On Thu, 08 Sep 2011 18:54:36 +0200
>> > Matthias Andree wrote:
>> >>
>> >> No, you'd use a managed installation. Nobody
On Fri, 09 Sep 2011 19:05:49 +0200
Matthias Andree wrote:
> Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
> > On Thu, 08 Sep 2011 18:54:36 +0200
> > Matthias Andree wrote:
> >>
> >> No, you'd use a managed installation. Nobody stands there
> >> pointing a gun at your head and forces you to u
Am 09.09.2011 14:38, schrieb Matt Burke:
> If someone deletes a package I use from ports, they are FORCING me to jump
> through an awful load of hoops to get what I want/need.
No. If people would please take note that the package does *not*
magically disappear from your computers because someone
Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
> On Thu, 08 Sep 2011 18:54:36 +0200
> Matthias Andree wrote:
>
>> Am 08.09.2011 13:52, schrieb Matt Burke:
>>
>>> I want machines, tools, to do as *I* say not the other way round,
>>> whether it's good for me or not. If I wanted nannying and
>>> i
On 09/08/11 17:54, Matthias Andree wrote:
> The port isn't perfectly usable (because that would mean it's usable in
> all circumstances for all advertised purposes, which is explicitly not
> the case in the light of known vulnerabilities).
In British Engligh at least, "perfectly" can mean "adequat
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree wrote:
> Am 08.09.2011 13:52, schrieb Matt Burke:
>
> > What the current FreeBSD policy of actively deleting perfectly
> > usable ports instead of putting a mild hurdle in the way is saying,
> > is that FreeBSD will stop me doing what I may want
Greg Byshenk wrote:
On Fri, Sep 09, 2011 at 07:27:51AM +0200, Erik Trulsson wrote:
On Thu, Sep 08, 2011 at 06:54:36PM +0200, Matthias Andree wrote:
Am 08.09.2011 13:52, schrieb Matt Burke:
Changing to a hypothetical example, why would an Apache vulnerability in
mod_rewrite in the least bit b
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree wrote:
> Am 08.09.2011 13:52, schrieb Matt Burke:
>
> > I want machines, tools, to do as *I* say not the other way round,
> > whether it's good for me or not. If I wanted nannying and
> > interference, I'd install Ubuntu.
>
> No, you'd use a ma
On Fri, Sep 09, 2011 at 07:27:51AM +0200, Erik Trulsson wrote:
> On Thu, Sep 08, 2011 at 06:54:36PM +0200, Matthias Andree wrote:
> > Am 08.09.2011 13:52, schrieb Matt Burke:
> > > Changing to a hypothetical example, why would an Apache vulnerability in
> > > mod_rewrite in the least bit bother a
On Thu, Sep 08, 2011 at 06:36:46PM +0200, Matthias Andree wrote:
> Am 08.09.2011 16:15, schrieb Mikhail T.:
>
> > Having a poor port of an obscure
> > piece of software is better, than no port at all.
>
> A poor port is undesirable (and shouldn't be in the tree in the first
> place).
Highly deb
On Thu, Sep 08, 2011 at 06:54:36PM +0200, Matthias Andree wrote:
> Am 08.09.2011 13:52, schrieb Matt Burke:
>
> > Changing to a hypothetical example, why would an Apache vulnerability in
> > mod_rewrite in the least bit bother a person who doesn't have the module
> > enabled, which I believe is th
On Fri, Sep 09, 2011 at 03:01:09AM +0200, Julian H. Stacey wrote:
> Matthias Andree wrote:
> > Am 08.09.2011 16:15, schrieb Mikhail T.:
> >
> > > Having a poor port of an obscure
> > > piece of software is better, than no port at all.
> >
> > A poor port is undesirable (and shouldn't be in the t
Matthias Andree wrote:
> Am 08.09.2011 16:15, schrieb Mikhail T.:
>
> > Having a poor port of an obscure
> > piece of software is better, than no port at all.
>
> A poor port is undesirable (and shouldn't be in the tree in the first
> place).
Wrong.
A `poor' port is is still a port else it woul
Matthias Andree wrote:
> Am 08.09.2011 13:52, schrieb Matt Burke:
> > I want machines, tools, to do as *I* say not the other way round, whether
> > it's good for me or not. If I wanted nannying and interference, I'd install
> > Ubuntu.
>
> No, you'd use a managed installation. Nobody stands the
Matthias Andree wrote:
> Am 07.09.2011 17:53, schrieb Mikhail T.:
>
> > The policy -- up until fairly recently -- was to remove ports, that
> > *fail to build* for a while. This made sense -- if the port remains
> > unbuildable long enough, then, certainly, it is no longer in use.
> >
> > The /ne
On Thu, Sep 08, 2011 at 06:36:46PM +0200, Matthias Andree wrote:
> Am 08.09.2011 16:15, schrieb Mikhail T.:
>
> An obscure piece of software is undesirable (and shouldn't be ported in
> the first place).
Wait -- what? Why should something not be ported if it's not popular?
--
Chad Perrin [ ori
Am 08.09.2011 13:52, schrieb Matt Burke:
> Changing to a hypothetical example, why would an Apache vulnerability in
> mod_rewrite in the least bit bother a person who doesn't have the module
> enabled, which I believe is the standard configuration? Would you prefer
> Apache be deleted from ports i
Am 07.09.2011 17:53, schrieb Mikhail T.:
> The policy -- up until fairly recently -- was to remove ports, that
> *fail to build* for a while. This made sense -- if the port remains
> unbuildable long enough, then, certainly, it is no longer in use.
>
> The /new/ policy of removing ports for much
Am 08.09.2011 16:15, schrieb Mikhail T.:
> Having a poor port of an obscure
> piece of software is better, than no port at all.
A poor port is undesirable (and shouldn't be in the tree in the first
place).
An obscure piece of software is undesirable (and shouldn't be ported in
the first place).
"Mikhail T." wrote:
>Having to deal with RedHat's yum at work, I got to say, I'd rather be
>building from source, than installing from "consistent packages", that
>somebody else built *to their* tastes.
Fedora crap is a very bad example. The canonical example of a binary
distribution which *works
On 08.09.2011 04:42, Greg Byshenk wrote:
For many people, what "THERE IS A PORT OF IT" actually -means- is
that the user can go to ports and install a -working- version of
the software, not merley that there is something called 'IT'
somewhere in the ports tree that may or may not work.
Some por
On 09/07/11 17:04, Chris Rees wrote:
>> The /new/ policy of removing ports for much lighter offenses, such as
> having vulnerabilities, has already caused so many objections, that it is
> time to abolish it.
>
> I consider the argument here dead; portmgr is reviewing the policy as Erwin
> has sai
Hi,
Reference:
> From: Chris Rees
> Date: Thu, 8 Sep 2011 07:20:27 +0100
> Message-id:
>
Chris Rees wrote:
> --00151774047892f1af04ac680e7e
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 8 Sep 2011 02:29, "Julian H. Stacey" wrote:
> >
> > Hi,
> > Reference:
> > > F
On Wed, Sep 07, 2011 at 08:15:04PM -0400, Mikhail T. wrote:
> On -10.01.-28163 14:59, Doug Barton wrote:
> >Non sequitur. The large number of ports that we support IS a feature.
> >However, it's also a pretty big maintenance burden. Especially when you
> >consider the number of those ports that
On 8 Sep 2011 02:29, "Julian H. Stacey" wrote:
>
> Hi,
> Reference:
> > From: Doug Barton
> > Date: Wed, 07 Sep 2011 15:45:51 -0700
> > Message-id: <4e67f41f.70...@freebsd.org>
>
> Doug Barton wrote:
> > On 9/7/2011 10:02 AM, per...@pluto.rain.com wrote:
> > > Doug Barton wrote
On 9/7/11 9:28 PM, Julian H. Stacey wrote:
>> And what we have been trying to explain to you is that this has never
>> been a supported mode of operation. We don't tie the ports tree to
>> specific releases,
>
> FreeBSD doese "tie the ports tree to specific releases". We have ports
> freezes befo
Hi,
Reference:
> From: Doug Barton
> Date: Wed, 07 Sep 2011 15:45:51 -0700
> Message-id: <4e67f41f.70...@freebsd.org>
Doug Barton wrote:
> On 9/7/2011 10:02 AM, per...@pluto.rain.com wrote:
> > Doug Barton wrote:
> >> On 09/07/2011 00:07, per...@pluto.rain.com wrote:
> >>> D
On -10.01.-28163 14:59, Doug Barton wrote:
Non sequitur. The large number of ports that we support IS a feature. However,
it's also a pretty big maintenance burden. Especially when you consider the
number of those ports that are either actually or effectively unmaintained.
Support? What suppor
On 9/7/2011 10:02 AM, per...@pluto.rain.com wrote:
> Doug Barton wrote:
>> On 09/07/2011 00:07, per...@pluto.rain.com wrote:
>>> Doug Barton wrote:
> Better to deprecate such non urgent ports, & wait a while
> after next release is rolled, to give release users a warning
>
Peter Jeremy wrote:
> On 2011-Sep-07 10:02:42 -0700, per...@pluto.rain.com wrote:
> >Reread the first paragraph. Provided the port is still in the
> >tree, when they try to build it the ports mechanism reports the
> >FORBIDDEN/BROKEN/whatever which describes the problem, and the
> >expiration da
On Wed, Sep 07, 2011 at 05:57:17PM +0200, Erik Trulsson wrote:
> On Wed, Sep 07, 2011 at 09:25:15AM -0600, Chad Perrin wrote:
> >
> > My understanding is that you are saying "attic" is just the standard
> > term for CVS history. Is that the case, or do I misunderstand your
> > point?
>
> Almost
On -10.01.-28163 14:59, Chris Rees wrote:
I don't actually think they've been divisive -- it's been policy for years.
The policy -- up until fairly recently -- was to remove ports, that *fail to
build* for a while. This made sense -- if the port remains unbuildable long
enough, then, certainl
On 07.09.2011 12:04, Chris Rees wrote:
However... I find it deeply troubling that you consider buildability more
important than security fixes. Are you actually serious?
Yes, I'm, of course, serious. As you formulated above, the question is a no
brainer: software, that does not build is ul
On 7 Sep 2011 16:53, "Mikhail T." wrote:
>
> On -10.01.-28163 14:59, Chris Rees wrote:
>>
>> I don't actually think they've been divisive -- it's been policy for
years.
>
>
> The policy -- up until fairly recently -- was to remove ports, that *fail
to build* for a while. This made sense -- if the
On Wed, Sep 07, 2011 at 09:25:15AM -0600, Chad Perrin wrote:
> On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote:
> > On 2011-Sep-07 01:35:54 -0600, Chad Perrin wrote:
> > >
> > > One thing I've seen come up that I definitely think would be a good
> > > idea, though, is more accessible
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote:
> On 2011-Sep-07 01:35:54 -0600, Chad Perrin wrote:
> >
> > One thing I've seen come up that I definitely think would be a good
> > idea, though, is more accessible documentation of the CVS "attic",
> > though. I had no idea such a thi
On Wed, Sep 07, 2011 at 12:53:31PM +0200, Kurt Jaeger wrote:
> >
> > One thing I've seen come up that I definitely think would be a good idea,
> > though, is more accessible documentation of the CVS "attic", though.
>
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/?hideattic=0#dirlist
>
> For exam
Erik Trulsson wrote:
> On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote:
> > On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov wrote:
> > > What about requiring that the ports deprecated should be either broken
> > > or have known published vulnerabilties for a long period of
> > > t
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote:
> On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov wrote:
> >What about requiring that the ports deprecated should be either broken
> >or have known published vulnerabilties for a long period of
> >time (say 6 months) for the start?
>
>
On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov wrote:
>What about requiring that the ports deprecated should be either broken
>or have known published vulnerabilties for a long period of
>time (say 6 months) for the start?
This might be reasonable for broken ports but ports with known
vulnerabili
Hi!
> One thing I've seen come up that I definitely think would be a good idea,
> though, is more accessible documentation of the CVS "attic", though.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/?hideattic=0#dirlist
For example, net/ztelnet is no longer in the ports, but:
http://www.freebsd.org
Doug Barton wrote:
> On 09/07/2011 00:07, per...@pluto.rain.com wrote:
> > Doug Barton wrote:
> >>> Better to deprecate such non urgent ports, & wait a while
> >>> after next release is rolled, to give release users a warning
> >>> & some time to volunteer ...
>
> That's an
On Tue, Sep 06, 2011 at 09:15:01PM -0700, Doug Barton wrote:
> On 09/07/2011 00:07, per...@pluto.rain.com wrote:
> >
> > How is it impractical to, as a rule, set an expiration date based on
> > an anticipated future release date rather than only a month or two
> > out from when the decision is mad
On Sep 7, 2011, at 8:30 AM, Stanislav Sedov wrote:
> On Mon, 05 Sep 2011 12:05:35 +0200
> "Julian H. Stacey" mentioned:
>
>> Mark Linimon wrote:
>>> On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote:
It is not responsible to threaten to remove ports without warning
betw
On Mon, 05 Sep 2011 12:05:35 +0200
"Julian H. Stacey" mentioned:
> Mark Linimon wrote:
> > On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote:
> > > It is not responsible to threaten to remove ports without warning
> > > between releases for non urgent reasons.
> >
> > portmgr has
conflicting opinions on when to remove
ports from the tree. The fate of sysutils/cfs or any other individual
port is, really, secondary to that discussion...
Yar, myself, as well as other folks, who object to the on-going
deprecations/removals of ports for the slightest of offenses, can fix
/any/ port
On 09/07/2011 00:07, per...@pluto.rain.com wrote:
> Doug Barton wrote:
>
>>> Better to deprecate such non urgent ports, & wait a while
>>> after next release is rolled, to give release users a warning
>>> & some time to volunteer ...
That's an interesting idea, but incredibl
On Wed, Sep 7, 2011 at 5:09 PM, wrote:
> Yar Tikhiy wrote:
>
>> By the way, the Debian folks invested certain effort in
>> keeping cfs up to date. Their git repo is still available
>> at http://smarden.org/git/cfs.git/ . In particular, the
>> DoS fix can be easily obtained from the repo and pl
Doug Barton wrote:
> > Better to deprecate such non urgent ports, & wait a while
> > after next release is rolled, to give release users a warning
> > & some time to volunteer ...
> >>
> >> That's an interesting idea, but incredibly unlikely to happen.
> >
> > It _certainly_ won't ha
Yar Tikhiy wrote:
> By the way, the Debian folks invested certain effort in
> keeping cfs up to date. Their git repo is still available
> at http://smarden.org/git/cfs.git/ . In particular, the
> DoS fix can be easily obtained from the repo and placed
> under files/ in the port.
So at this poi
On 5 September 2011 22:46, Julian H. Stacey wrote:
> Matthias Andree wrote:
>
>> So either Kostik, or you, or someone else steps up to maintain the port
>> at least to the extent that the known security bugs and reported bugs
>> get fixed, or to hell the port goes.
>
> Recent un-professional thre
On Mon, 5 Sep 2011 21:02:14 +0300
Kostik Belousov wrote:
> Second, I personally consider the crusade to remove old but compiling
> and working (*) ports as a damage both to the project functionality
> and to the project reputation.
I find this whole "discussion" rather strange. You use the high
Hi,
On 9/6/11 4:02 AM, Kostik Belousov wrote:
On Mon, Sep 05, 2011 at 06:32:00PM +0100, Chris Rees wrote:
On 5 Sep 2011 18:15, "Mikhail T." wrote:
On -10.01.-28163 14:59, Chris Rees wrote:
I've had to deprecate sysutils/cfs -- there's a confirmed issue with
failing
On 09/05/2011 22:48, per...@pluto.rain.com wrote:
> Doug Barton wrote:
>> On 09/05/2011 02:33, Julian H. Stacey wrote:
> It is not responsible to threaten to remove ports without
> warning between releases for non urgent reasons.
>>
>> We understand that this is your perspective, however t
> AFAIK there are maybe half a dozen or so developers who have
> recently put themselves on record as supporting the current,
> agressive deprecation campaign. The number who have posted in
> opposition may well be smaller, so you are probably right if "the
> community" is defined as consisting on
Doug Barton wrote:
> On 09/05/2011 02:33, Julian H. Stacey wrote:
> >>> It is not responsible to threaten to remove ports without
> >>> warning between releases for non urgent reasons.
>
> We understand that this is your perspective, however the community
> in general has a different idea.
I supp
Matthias Andree wrote:
> So either Kostik, or you, or someone else steps up to maintain the port
> at least to the extent that the known security bugs and reported bugs
> get fixed, or to hell the port goes.
Recent un-professional threats to throw out ports at un-necessarily
short notice, with h
Am 05.09.2011 20:29, schrieb Mikhail T.:
> On 05.09.2011 13:32, Chris Rees wrote:
>> If it's not that hard to fix then do it.
> Before doing it, I wanted to confirm, that there are no other, more
> serious vulnerabilities.
>
> Things, for which no fixes have been posted -- unlike for this
> partic
On 05.09.2011 13:32, Chris Rees wrote:
If it's not that hard to fix then do it.
Before doing it, I wanted to confirm, that there are no other, more
serious vulnerabilities.
Things, for which no fixes have been posted -- unlike for this
particular one, which Debian fixed several years ago (bef
On Mon, Sep 05, 2011 at 06:32:00PM +0100, Chris Rees wrote:
> On 5 Sep 2011 18:15, "Mikhail T." wrote:
> >
> > On -10.01.-28163 14:59, Chris Rees wrote:
> >>>
> >>> I've had to deprecate sysutils/cfs -- there's a confirmed issue with
>
On 5 Sep 2011 18:15, "Mikhail T." wrote:
>
> On -10.01.-28163 14:59, Chris Rees wrote:
>>>
>>> I've had to deprecate sysutils/cfs -- there's a confirmed issue with
>>> failing locks [1] which has been open for two years with no fix.
>&g
On -10.01.-28163 14:59, Chris Rees wrote:
I've had to deprecate sysutils/cfs -- there's a confirmed issue with
failing locks [1] which has been open for two years with no fix.
Whoops, also missed a CVE -- buffer overflows can cause a DoS.
Expiration date altered to 1 month accordi
Hi,
Doug Barton wrote:
> On 09/05/2011 02:33, Julian H. Stacey wrote:
> > Chris Rees wrote:
> >> On 4 September 2011 21:32, Julian H. Stacey wrote:
>
> Whoops, also missed a CVE -- buffer overflows can cause a DoS.
> Expiration date altered to 1 month accordingly.
> >>>
> >>> It is
On 09/05/2011 02:33, Julian H. Stacey wrote:
> Chris Rees wrote:
>> On 4 September 2011 21:32, Julian H. Stacey wrote:
Whoops, also missed a CVE -- buffer overflows can cause a DoS.
Expiration date altered to 1 month accordingly.
>>>
>>> It is not responsible to threaten to remove p
per...@pluto.rain.com wrote:
> Chris Rees wrote:
> > Whoops, also missed a CVE -- buffer overflows can cause a DoS.
>
> Er, am I the only one who does not recognize what "CVE" stands for?
"CVE" == Common Vulnerabilities and Exposures
To put it simply, it's a database of security threats
mai
On 5 Sep 2011 11:06, "Julian H. Stacey" wrote:
>
> Mark Linimon wrote:
> > On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote:
> > > It is not responsible to threaten to remove ports without warning
> > > between releases for non urgent reasons.
> >
> > portmgr has no such policy.
>
Mark Linimon wrote:
> On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote:
> > It is not responsible to threaten to remove ports without warning
> > between releases for non urgent reasons.
>
> portmgr has no such policy.
>
> Ports get deleted all the time due to various issues. I p
Chris Rees wrote:
> On 4 September 2011 21:32, Julian H. Stacey wrote:
> >>
> >> Whoops, also missed a CVE -- buffer overflows can cause a DoS.
> >> Expiration date altered to 1 month accordingly.
> >
> > It is not responsible to threaten to remove ports without warning
> > between releases for no
Chris Rees wrote:
> > I've had to deprecate sysutils/cfs ...
s/sysutils/security
(at least in my instance of the ports tree).
> Whoops, also missed a CVE -- buffer overflows can cause a DoS.
Er, am I the only one who does not recognize what "CVE" stands for?
BTW thanks
On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote:
> It is not responsible to threaten to remove ports without warning
> between releases for non urgent reasons.
portmgr has no such policy.
Ports get deleted all the time due to various issues. I prefer to see
a 1- or 2-month warni
On 4 September 2011 21:32, Julian H. Stacey wrote:
>>
>> Whoops, also missed a CVE -- buffer overflows can cause a DoS.
>> Expiration date altered to 1 month accordingly.
>
> It is not responsible to threaten to remove ports without warning
> between releases for non urgent reasons.
>
> Better to
Hi,
Reference:
> From: Chris Rees
> Date: Sun, 4 Sep 2011 20:21:10 +0100
> Message-id:
>
Chris Rees wrote:
> On 4 September 2011 17:56, Chris Rees wrote:
> > Guys,
> >
> > I've had to deprecate sysutils/cfs -- there's a confirmed
On 4 September 2011 17:56, Chris Rees wrote:
> Guys,
>
> I've had to deprecate sysutils/cfs -- there's a confirmed issue with
> failing locks [1] which has been open for two years with no fix.
>
> Please would someone consider stepping up to fix and maintain it?
Guys,
I've had to deprecate sysutils/cfs -- there's a confirmed issue with
failing locks [1] which has been open for two years with no fix.
Please would someone consider stepping up to fix and maintain it? It
has two months to live.
Thanks!
Chris
[1] http://www.freebsd.org/cgi/query
99 matches
Mail list logo
