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:
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 revoked.
FreeBSD
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 least
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
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 don't
On 12 September 2011 22:07, Julian H. Stacey j...@berklix.com 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
Hi,
Reference:
From: Chris Rees cr...@freebsd.org
Date: Tue, 13 Sep 2011 18:44:37 +0100
Message-id:
cadlo83-zcvaeyznw5dtehv1tosburzllr2hjxfjrx_qewph...@mail.gmail.com
Chris Rees wrote:
On 12 September 2011 22:18, Julian H. Stacey j...@berklix.com wrote:
Matthias
Chris Rees wrote:
On 12 September 2011 22:18, Julian H. Stacey j...@berklix.com 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
.html
Chris Rees utisoft at gmail.com
Sun Sep 4 16:56:37 UTC 2011
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
are False. You posted this:
http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/069860.html
Chris Rees utisoft at gmail.com
Sun Sep 4 16:56:37 UTC 2011
Guys,
I've had to deprecate sysutils/cfs -- there's a confirmed issue with
failing locks [1] which has been open for two
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
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
On 10 September 2011 06:45, Conrad J. Sabatier conr...@cox.net wrote:
On Fri, 09 Sep 2011 19:05:49 +0200
Matthias Andree matthias.and...@gmx.de wrote:
Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree mand...@freebsd.org wrote:
No,
Matthias Andree matthias.and...@gmx.de 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
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 to
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
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 packages,
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
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 and
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, 10 Sep 2011 12:24:33 +0200
Matthias Andree matthias.and...@gmx.de 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
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 library)
Matthias Andree matthias.and...@gmx.de 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
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 person
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree mand...@freebsd.org 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,
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
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree mand...@freebsd.org 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
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 adequately
Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree mand...@freebsd.org 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
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
On Fri, 09 Sep 2011 19:05:49 +0200
Matthias Andree matthias.and...@gmx.de wrote:
Am 09.09.2011 11:09, schrieb Conrad J. Sabatier:
On Thu, 08 Sep 2011 18:54:36 +0200
Matthias Andree mand...@freebsd.org wrote:
No, you'd use a managed installation. Nobody stands there
pointing a gun at
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 there
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 would be
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 tree in the
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 the
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 debatable.
On 8 Sep 2011 02:29, Julian H. Stacey j...@berklix.com wrote:
Hi,
Reference:
From: Doug Barton do...@freebsd.org
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
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 are
Hi,
Reference:
From: Chris Rees utis...@gmail.com
Date: Thu, 8 Sep 2011 07:20:27 +0100
Message-id:
CADLo83-4Hbq+Ce5ADJvEQP7167wJt48C8aOfCW8RV=w96st...@mail.gmail.com
Chris Rees wrote:
--00151774047892f1af04ac680e7e
Content-Type: text/plain; charset=ISO-8859-1
On 8
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 said.
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
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* is
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).
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 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 if
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 [
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 /new/ policy
On Mon, 05 Sep 2011 12:05:35 +0200
Julian H. Stacey j...@berklix.com 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
On Sep 7, 2011, at 8:30 AM, Stanislav Sedov wrote:
On Mon, 05 Sep 2011 12:05:35 +0200
Julian H. Stacey j...@berklix.com 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
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 made?
Doug Barton do...@freebsd.org wrote:
On 09/07/2011 00:07, per...@pluto.rain.com wrote:
Doug Barton do...@freebsd.org 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
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:
On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov s...@freebsd.org 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
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote:
On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov s...@freebsd.org 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
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 s...@freebsd.org wrote:
What about requiring that the ports deprecated should be either broken
or have known published vulnerabilties for a long period of
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 example,
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote:
On 2011-Sep-07 01:35:54 -0600, Chad Perrin c...@apotheon.net 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
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 c...@apotheon.net wrote:
One thing I've seen come up that I definitely think would be a good
idea, though, is more
On 7 Sep 2011 16:53, Mikhail T. mi+t...@aldan.algebra.com 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
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
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,
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 correct.
Peter Jeremy peterjer...@acm.org 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
On 9/7/2011 10:02 AM, per...@pluto.rain.com wrote:
Doug Barton do...@freebsd.org wrote:
On 09/07/2011 00:07, per...@pluto.rain.com wrote:
Doug Barton do...@freebsd.org wrote:
Better to deprecate such non urgent ports, wait a while
after next release is rolled, to give release users a warning
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
Hi,
Reference:
From: Doug Barton do...@freebsd.org
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 do...@freebsd.org wrote:
On 09/07/2011 00:07,
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 before each
On Mon, 5 Sep 2011 21:02:14 +0300
Kostik Belousov kostik...@gmail.com 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.
On 5 September 2011 22:46, Julian H. Stacey j...@berklix.com wrote:
Matthias Andree mand...@freebsd.org 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.
Yar Tikhiy yar.tik...@gmail.com 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.
Doug Barton do...@freebsd.org 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 happen if
On Wed, Sep 7, 2011 at 5:09 PM, per...@pluto.rain.com wrote:
Yar Tikhiy yar.tik...@gmail.com 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
On 09/07/2011 00:07, per...@pluto.rain.com wrote:
Doug Barton do...@freebsd.org 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
the 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
Chris Rees wrote:
On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com 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
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 prefer to
per...@pluto.rain.com wrote:
Chris Rees utis...@gmail.com 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
On 09/05/2011 02:33, Julian H. Stacey wrote:
Chris Rees wrote:
On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com 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
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 j...@berklix.com wrote:
Whoops, also missed a CVE -- buffer overflows can cause a DoS.
Expiration date altered to 1 month accordingly.
It is not
On 5 Sep 2011 18:15, Mikhail T. mi+t...@aldan.algebra.com 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.
Whoops, also missed a CVE -- buffer overflows can
On Mon, Sep 05, 2011 at 06:32:00PM +0100, Chris Rees wrote:
On 5 Sep 2011 18:15, Mikhail T. mi+t...@aldan.algebra.com 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
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
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
particular
Matthias Andree mand...@freebsd.org 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
Doug Barton do...@freebsd.org 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.
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 only of
On 09/05/2011 22:48, per...@pluto.rain.com wrote:
Doug Barton do...@freebsd.org 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
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.mi+t...@aldan.algebra.com wrote:
On -10.01.-28163 14:59, Chris Rees wrote:
I've had to deprecate sysutils/cfs -- there's a confirmed issue with
failing
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-pr.cgi?pr
On 4 September 2011 17:56, Chris Rees utis...@gmail.com 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? It
has two months
to deprecate sysutils/cfs -- there's a confirmed issue with
failing locks [1] which has been open for two years with no fix.
No reason to suddenly panic then.
Please would someone consider stepping up to fix and maintain it? It
has two months to live.
Thanks!
Chris
[1] http
On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com 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.
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
Chris Rees utis...@gmail.com 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
94 matches
Mail list logo
