While that could be the easy way out, it would definitely be wrong.
Such limits can be OS or filesystem specific, if at all. They do not even
represent reality on GNU/Linux! Try this:
I try to stay out of these politics, but I found it beneficial to remove the
dependency on MAX_PATH. It
On Fri, 2011-12-16 at 12:18 +0100, Rainer Gerhards wrote:
While that could be the easy way out, it would definitely be wrong.
Such limits can be OS or filesystem specific, if at all. They do not even
represent reality on GNU/Linux! Try this:
I try to stay out of these politics, but I
Good that you took the time to change the code, I'm currently working on
completing the dynamic allocation solution.
It's important to note that I used the chance to refactor the code a bit, so
the logic is slightly different. When you read the code, note that I use a
stack-based fixed size
On Fri, 2011-12-16 at 14:32 +0100, Rainer Gerhards wrote:
Good that you took the time to change the code, I'm currently working on
completing the dynamic allocation solution.
It's important to note that I used the chance to refactor the code a bit, so
the logic is slightly different. When
We have a bugzilla at http://bugzilla.adiscon.com and the mailing list
is at http://lists.adiscon.net/mailman/listinfo/rsyslog
Which way you use doesn't really matter to me, I am fine with either way.
Just note that anything that is related to the packaging is not
touched by me. I
Hi!
On Tue, 2011-12-13 at 18:44:11 +0100, Michael Biebl wrote:
but WTH does GNU/hurd not simply #define PATH_MAX and be done with it.
While that could be the easy way out, it would definitely be wrong.
Such limits can be OS or filesystem specific, if at all. They do not
even represent reality
On Tue, 2011-12-13 at 06:41 +0100, Guillem Jover wrote:
Hi!
On Fri, 2011-12-09 at 16:40:41 +0100, Svante Signell wrote:
Source: rsyslog
Version: 5.8.6-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
...
diff -ur rsyslog-5.8.6/runtime/modules.c
Hi!
On Tue, 2011-12-13 at 09:50:21 +0100, Svante Signell wrote:
On Tue, 2011-12-13 at 06:41 +0100, Guillem Jover wrote:
On Fri, 2011-12-09 at 16:40:41 +0100, Svante Signell wrote:
Source: rsyslog
Version: 5.8.6-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Thanks for all the efforts, but WTH does GNU/hurd not simply #define
PATH_MAX and be done with it. This would solve 90% of the build failures
we have in Debian.
This all looks like a major waste of time to me.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
On Tue, 2011-12-13 at 18:44 +0100, Michael Biebl wrote:
Thanks for all the efforts, but WTH does GNU/Hurd not simply #define
PATH_MAX and be done with it. This would solve 90% of the build failures
we have in Debian.
This all looks like a major waste of time to me.
It might look like that but
Hi!
On Fri, 2011-12-09 at 16:40:41 +0100, Svante Signell wrote:
Source: rsyslog
Version: 5.8.6-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
rsyslog FTBFS on GNU/Hurd due to the usage of PATH_MAX in one function
static rsRetVal Load(uchar *pModName)
Source: rsyslog
Version: 5.8.6-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
rsyslog FTBFS on GNU/Hurd due to the usage of PATH_MAX in one function
static rsRetVal Load(uchar *pModName) in file realtime/modules.c. The
attached patch use dynamic allocation of
12 matches
Mail list logo
