> > 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
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
> 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 b
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
> 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 actu
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 o
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
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
unive
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...
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/ru
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 *pMo
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 s
12 matches
Mail list logo
