On Saturday 26 May 2007 09:49, Alexey Mikhailov wrote:
On Friday 25 May 2007 22:04:34 Benjamin Lutz wrote:
On Friday 25 May 2007 01:22:21 Alexey Mikhailov wrote:
[...]
2. As I said before initial subject of this project was
Distributed audit daemon. But after some discussions we had
On Sun, 27 May 2007, Benjamin Lutz wrote:
Hi,
[ log shippping daemon for audit and other other logs ]
[ syslog problems ]
sorry I have to cut this short;)
What Alexey said - this will be about log shipping not about writing
single log records etc.
Your syslog problems are outside the scope
On 27/05/07, Bjoern A. Zeeb [EMAIL PROTECTED] wrote:
Having a generic, more secure and reliable (local) logging mechnism
should be discussed in at least another thread. You may as well think
of taking this idea to IETF as RFC 3164 lives there as a Memo these
days and it might be a general
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed package.
Now make -V PKGNAME should be a speedy operation, but the make has to
load in and analyze
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed package. Now
make -V
Not quite what you asked for but...
Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is needed is a ports server and a thin CLI
frontend to it.
This server can store dependency data in an efficient manner,
Stephen Montgomery-Smith said:
I suggest rewriting make so that variables are only evaluated on a
need to know basis.
or I have tried to do this.
Of course a lot of people have thinked about it, and quickly realized
that it was not going to work. In the bsd.ports.mk, evaluation of one
On Mon, 28 May 2007, Michel Talon wrote:
Stephen Montgomery-Smith said:
I suggest rewriting make so that variables are only evaluated on a
need to know basis.
or I have tried to do this.
Of course a lot of people have thinked about it, and quickly realized
that it was not going to
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed
I'm looking for something that will work with the existing framework.
But yes, I get the feeling that maybe using make to process the ports
might be the source of the problem. Make is a program primarily
designed for figuring out which was made first, the target or the
source, but in the
On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
In summary, the ports infrastructure is really complicated because it's
trying to deal with all kinds of constraints and conditions. I challenge
Reading this, I was wondering what the ports infrastructure has
ever done for us?
See
On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote:
To gain some performance, a first idea would be to simplify
bsd.ports.mk. I am convinced that a substantial part of the 4000 lines
are historical crap which serve no useful purpose.
11272 of LOC in bsd.*.mk, but who's counting.
In [EMAIL PROTECTED], Edwin Groothuis [EMAIL PROTECTED] typed:
On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
In summary, the ports infrastructure is really complicated because it's
trying to deal with all kinds of constraints and conditions. I challenge
Reading this, I was
On Sun, May 27, 2007 at 10:51:56PM -0400, Mike Meyer wrote:
In [EMAIL PROTECTED], Edwin Groothuis [EMAIL PROTECTED] typed:
On Sun, May 27, 2007 at 08:44:56PM -0500, Mark Linimon wrote:
In summary, the ports infrastructure is really complicated because it's
trying to deal with all kinds of
14 matches
Mail list logo
