Hi guys
while looking at those 2 bugs, i just bumped to new syslog-ng 3.x series.
http://bugs.archlinux.org/task/6980
http://bugs.archlinux.org/task/10776

Changes:
- adopted new syntax to config file
- disable stats logging by default,
it just floods everything with useless stats.
- added install message, which mentions syntax change

signoff both arches

greetings
tpowa
--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

On Sat, Mar 7, 2009 at 9:54 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
> Hi guys
> while looking at those 2 bugs, i just bumped to new syslog-ng 3.x series.
> http://bugs.archlinux.org/task/6980
> http://bugs.archlinux.org/task/10776
>
> Changes:
> - adopted new syntax to config file
> - disable stats logging by default,
> *it just floods everything with useless stats.
> - added install message, which mentions syntax change
>
> signoff both arches
>
> greetings
> tpowa
> --
> Tobias Powalowski
> Archlinux Developer & Package Maintainer (tpowa)
> http://www.archlinux.org
> tpowa@archlinux.org
>
>

It can't create the pid file:

$ sudo /etc/rc.d/syslog-ng start
:: Starting Syslog-NG

[BUSY] syslog-ng: Error creating pid file;
file='/usr/var/run/syslog-ng.pid', error='No such file or directory'

There's probably an incorrect configure option

Am Samstag 07 März 2009 schrieb Eric Bélanger:
> On Sat, Mar 7, 2009 at 9:54 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
> > Hi guys
> > while looking at those 2 bugs, i just bumped to new syslog-ng 3.x series.
> > http://bugs.archlinux.org/task/6980
> > http://bugs.archlinux.org/task/10776
> >
> > Changes:
> > - adopted new syntax to config file
> > - disable stats logging by default,
> > it just floods everything with useless stats.
> > - added install message, which mentions syntax change
> >
> > signoff both arches
> >
> > greetings
> > tpowa
> > --
> > Tobias Powalowski
> > Archlinux Developer & Package Maintainer (tpowa)
> > http://www.archlinux.org
> > tpowa@archlinux.org
>
> It can't create the pid file:
>
> $ sudo /etc/rc.d/syslog-ng start
>
> :: Starting Syslog-NG
>
> [BUSY] syslog-ng: Error creating pid file;
> file='/usr/var/run/syslog-ng.pid', error='No such file or directory'
>
> There's probably an incorrect configure option
hrm i don't use sudo, without sudo it works fine here.

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

On Sat, Mar 7, 2009 at 1:11 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
> Am Samstag 07 März 2009 schrieb Eric Bélanger:
>> On Sat, Mar 7, 2009 at 9:54 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
>> > Hi guys
>> > while looking at those 2 bugs, i just bumped to new syslog-ng 3.x series.
>> > http://bugs.archlinux.org/task/6980
>> > http://bugs.archlinux.org/task/10776
>> >
>> > Changes:
>> > - adopted new syntax to config file
>> > - disable stats logging by default,
>> > *it just floods everything with useless stats.
>> > - added install message, which mentions syntax change
>> >
>> > signoff both arches
>> >
>> > greetings
>> > tpowa
>> > --
>> > Tobias Powalowski
>> > Archlinux Developer & Package Maintainer (tpowa)
>> > http://www.archlinux.org
>> > tpowa@archlinux.org
>>
>> It can't create the pid file:
>>
>> $ sudo /etc/rc.d/syslog-ng start
>>
>> :: Starting Syslog-NG
>>
>> [BUSY] syslog-ng: Error creating pid file;
>> file='/usr/var/run/syslog-ng.pid', error='No such file or directory'
>>
>> There's probably an incorrect configure option
> hrm i don't use sudo, without sudo it works fine here.
>

I get same thing when running as root. Do you have a var symlink in
/usr? If so, that's why it works for you.
I don't know what could be the problem as we already use
--localstatedir=/var/lib/syslog-ng. Maybe there's a configure option
for the location of the pid file.

Am Samstag 07 März 2009 schrieb Eric Bélanger:
> On Sat, Mar 7, 2009 at 1:11 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
> > Am Samstag 07 März 2009 schrieb Eric Bélanger:
> >> On Sat, Mar 7, 2009 at 9:54 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
> >> > Hi guys
> >> > while looking at those 2 bugs, i just bumped to new syslog-ng 3.x
> >> > series. http://bugs.archlinux.org/task/6980
> >> > http://bugs.archlinux.org/task/10776
> >> >
> >> > Changes:
> >> > - adopted new syntax to config file
> >> > - disable stats logging by default,
> >> > it just floods everything with useless stats.
> >> > - added install message, which mentions syntax change
> >> >
> >> > signoff both arches
> >> >
> >> > greetings
> >> > tpowa
> >> > --
> >> > Tobias Powalowski
> >> > Archlinux Developer & Package Maintainer (tpowa)
> >> > http://www.archlinux.org
> >> > tpowa@archlinux.org
> >>
> >> It can't create the pid file:
> >>
> >> $ sudo /etc/rc.d/syslog-ng start
> >>
> >> :: Starting Syslog-NG
> >>
> >> [BUSY] syslog-ng: Error creating pid file;
> >> file='/usr/var/run/syslog-ng.pid', error='No such file or directory'
> >>
> >> There's probably an incorrect configure option
> >
> > hrm i don't use sudo, without sudo it works fine here.
>
> I get same thing when running as root. Do you have a var symlink in
> /usr? If so, that's why it works for you.
> I don't know what could be the problem as we already use
> --localstatedir=/var/lib/syslog-ng. Maybe there's a configure option
> for the location of the pid file.
it seems i have such an old system that it still has this old symlink
ok i'll fix it tomorrow

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

On Sun, Mar 8, 2009 at 12:17 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
>> I get same thing when running as root. Do you have a var symlink in
>> /usr? If so, that's why it works for you.
>> I don't know what could be the problem as we already use
>> --localstatedir=/var/lib/syslog-ng. *Maybe there's a configure *option
>> for the location of the pid file.
> it seems i have such an old system that it still has this old symlink
> ok i'll fix it tomorrow
>

>From filesystem 2009.01 pkgbuild :
# fhs compliance
...
(cd $startdir/pkg/usr; ln -s ../var var)

So most systems should have this symlink, but I also think it would be
better to avoid using it.
It seems weird to have usr/var/... files in a package while these
files are going to end up in /var/ when installed.

On Sun, Mar 8, 2009 at 7:31 AM, Xavier <shiningxc@gmail.com> wrote:
> On Sun, Mar 8, 2009 at 12:17 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
>>> I get same thing when running as root. Do you have a var symlink in
>>> /usr? If so, that's why it works for you.
>>> I don't know what could be the problem as we already use
>>> --localstatedir=/var/lib/syslog-ng. *Maybe there's a configure *option
>>> for the location of the pid file.
>> it seems i have such an old system that it still has this old symlink
>> ok i'll fix it tomorrow
>>
>
> >From filesystem 2009.01 pkgbuild :
> *# fhs compliance
> ...
> *(cd $startdir/pkg/usr; ln -s ../var var)
>
> So most systems should have this symlink, but I also think it would be
> better to avoid using it.
> It seems weird to have usr/var/... files in a package while these
> files are going to end up in /var/ when installed.
>

Both my i686 and x86_64 systems didn't had that symlink. I reinstalled
filesystem and now they have it. I don't know why the symlink wasn't
there. Either I removed it without thinking that it was belonging to a
package or an error happenned when I upgraded.

Anyway, the only reference to /usr/var in the FHS (
http://www.pathname.com/fhs/pub/fhs-2.3.html ) is:

"If /var cannot be made a separate partition, it is often preferable
to move /var out of the root partition and into the /usr partition.
(This is sometimes done to reduce the size of the root partition or
when space runs low in the root partition.) However, /var must not be
linked to /usr because this makes separation of /usr and /var more
difficult and is likely to create a naming conflict. Instead, link
/var to /usr/var."

I think the symlink can go. It's up to the user to decide if he wants
a seperate patition for /var or not. The sysmlink doesn't do anything
in that regard unless I misunderstood somethoiong. Currently, it only
prevents broken packages that use /usr/var instead of /var to stop
working.

Am Sonntag 08 März 2009 schrieb Eric Bélanger:
> On Sun, Mar 8, 2009 at 7:31 AM, Xavier <shiningxc@gmail.com> wrote:
> > On Sun, Mar 8, 2009 at 12:17 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
> >>> I get same thing when running as root. Do you have a var symlink in
> >>> /usr? If so, that's why it works for you.
> >>> I don't know what could be the problem as we already use
> >>> --localstatedir=/var/lib/syslog-ng. Maybe there's a configure option
> >>> for the location of the pid file.
> >>
> >> it seems i have such an old system that it still has this old symlink
> >> ok i'll fix it tomorrow
> >>
> > >From filesystem 2009.01 pkgbuild :
> >
> > # fhs compliance
> > ...
> > (cd $startdir/pkg/usr; ln -s ../var var)
> >
> > So most systems should have this symlink, but I also think it would be
> > better to avoid using it.
> > It seems weird to have usr/var/... files in a package while these
> > files are going to end up in /var/ when installed.
>
> Both my i686 and x86_64 systems didn't had that symlink. I reinstalled
> filesystem and now they have it. I don't know why the symlink wasn't
> there. Either I removed it without thinking that it was belonging to a
> package or an error happenned when I upgraded.
>
> Anyway, the only reference to /usr/var in the FHS (
> http://www.pathname.com/fhs/pub/fhs-2.3.html ) is:
>
> "If /var cannot be made a separate partition, it is often preferable
> to move /var out of the root partition and into the /usr partition.
> (This is sometimes done to reduce the size of the root partition or
> when space runs low in the root partition.) However, /var must not be
> linked to /usr because this makes separation of /usr and /var more
> difficult and is likely to create a naming conflict. Instead, link
> /var to /usr/var."
>
> I think the symlink can go. It's up to the user to decide if he wants
> a seperate patition for /var or not. The sysmlink doesn't do anything
> in that regard unless I misunderstood somethoiong. Currently, it only
> prevents broken packages that use /usr/var instead of /var to stop
> working.
hrm back to topic, signoff?

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

Tobias Powalowski schrieb:

"If /var cannot be made a separate partition, it is often preferable
to move /var out of the root partition and into the /usr partition.
(This is sometimes done to reduce the size of the root partition or
when space runs low in the root partition.) However, /var must not be
linked to /usr because this makes separation of /usr and /var more
difficult and is likely to create a naming conflict. Instead, link
/var to /usr/var."

I think the symlink can go. It's up to the user to decide if he wants
a seperate patition for /var or not. The sysmlink doesn't do anything
in that regard unless I misunderstood somethoiong. Currently, it only
prevents broken packages that use /usr/var instead of /var to stop
working.


Eric, you can commit the changes to filesystems/trunk, I think you are
right.



hrm back to topic, signoff?


Signoff x86_64 (two machines). The post_install message also seems to
show up properly.

On Sun, Mar 8, 2009 at 6:02 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Tobias Powalowski schrieb:
>>>
>>> "If /var cannot be made a separate partition, it is often preferable
>>> to move /var out of the root partition and into the /usr partition.
>>> (This is sometimes done to reduce the size of the root partition or
>>> when space runs low in the root partition.) However, /var must not be
>>> linked to /usr because this makes separation of /usr and /var more
>>> difficult and is likely to create a naming conflict. Instead, link
>>> /var to /usr/var."
>>>
>>> I think the symlink can go. It's up to the user to decide if he wants
>>> a seperate patition for /var or not. The sysmlink doesn't do anything
>>> in that regard unless I misunderstood somethoiong. Currently, it only
>>> prevents broken packages that use /usr/var instead of /var to stop
>>> working.
>
> Eric, you can commit the changes to filesystems/trunk, I think you are
> right.

OK, I'll do it.

>
>> hrm back to topic, signoff?
>
> Signoff x86_64 (two machines). The post_install message also seems to show
> up properly.
>

signoff i686.