[arch-dev-public] [signoff] syslog-ng 3.2.4-2
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes: * add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service There should be zero impact for users still on sysvinit. Signoff both, Dave
On Tue, Jun 28, 2011 at 4:33 PM, Dave Reisner <d@falconindy.com> wrote:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Works as expected with both sysvinit and systemd. signoff x86_64 -t
Am Tue, 28 Jun 2011 10:33:19 -0400 schrieb Dave Reisner <d@falconindy.com>:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Signoff both, Dave
Maybe I missed some discussion but Arch way usually means to not add more additional features than what is required to support our repo packages. Since it's a core repo pkg this policy should be respected. Any reason why you are adding systemd support that we don't officially support so far? I see we have systemd in community now but wouldn't be the proper way to offer additional foo-systemd packages in community replacing the packages from core/extra where needed? -Andy
On Tue, Jun 28, 2011 at 6:08 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Tue, 28 Jun 2011 10:33:19 -0400 schrieb Dave Reisner <d@falconindy.com>:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Signoff both, Dave
Maybe I missed some discussion but Arch way usually means to not add more additional features than what is required to support our repo packages. Since it's a core repo pkg this policy should be respected.
Any reason why you are adding systemd support that we don't officially support so far?
I see we have systemd in community now but wouldn't be the proper way to offer additional foo-systemd packages in community replacing the packages from core/extra where needed?
Just some additional info: Enabling systemd support in packages, does not introduce a makedepend on systemd, nor does it change the behavior of the package in question if systemd is not installed. It is (in most cases) simply a matter of installing an additional ini-style file in /lib/systemd/system. (This package upgrade also includes a backport of a bugfix, so it is slightly more complicated.) Enabling systemd support makes it a lot easier for people to test and evaluate systemd, so if no one is adversely affected I would be in favor of allowing it (especially in the low-level packages like syslog, udev, dbus, networkmanager, consolekit). Otherwise, we'll have a bit a of a chicken and egg problem: How are we to decide whether or not to add systemd to our repos if it is not widely tested? (Dave's systmed-arch-units package from [community] is nice, but probably not something we would ever move to an official repo, so not good for evalutaing systemd). Looking ahead a bit: if things pan out they way it looks like they will (most distros adopting systemd, and gnome depending on it), then we will probably at some point want to support both sysvinit and systemd, giving people a choice (maybe one in [core] and one in [extra]). As this seems likely, I think we should make things simple for ourselves by encouraging testing of systemd (as long as it does not cause problems for sysvinit of course). Just my two cents, -t
On Tue, Jun 28, 2011 at 11:08 AM, Andreas Radke <a.radke@arcor.de> wrote:
Am Tue, 28 Jun 2011 10:33:19 -0400 schrieb Dave Reisner <d@falconindy.com>:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Signoff both, Dave
Maybe I missed some discussion but Arch way usually means to not add more additional features than what is required to support our repo packages. Since it's a core repo pkg this policy should be respected.
Any reason why you are adding systemd support that we don't officially support so far? This did come up in IRC and no one had any reasoning against there.
I see we have systemd in community now but wouldn't be the proper way to offer additional foo-systemd packages in community replacing the packages from core/extra where needed? This is an unnecessary duplication of effort in my opinion, and a
1. "zero impact", as Dave stated 2. He is willing to maintain this extra functionality 3. We shouldn't impede progress unnecessarily This isn't a push for a switch to systemd, the new guy is just trying to make life easier for everyone involved. This is like saying we shouldn't have added hooks in initscripts as we don't need them, only community projects do. source of pain as far as keeping versions in sync. It is the same as enabling features that can then be optdepends; it doesn't pull anything else onto your system but at least allows people to use a stock package rather than one of 20+ variants in the way too crowded AUR. -Dan
On Tue, Jun 28, 2011 at 06:08:46PM +0200, Andreas Radke wrote:
Am Tue, 28 Jun 2011 10:33:19 -0400 schrieb Dave Reisner <d@falconindy.com>:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Signoff both, Dave
Maybe I missed some discussion but Arch way usually means to not add more additional features than what is required to support our repo packages. Since it's a core repo pkg this policy should be respected.
Any reason why you are adding systemd support that we don't officially support so far?
Note that udev and dbus already have support for systemd. This isn't anything revolutionary, or else I would have brought it up for discussion beforehand.
I see we have systemd in community now but wouldn't be the proper way to offer additional foo-systemd packages in community replacing the packages from core/extra where needed?
It isn't time just yet, but systemd will eventually move to [extra]. Unless there's some adverse effect on sysvinit setups (at which point, systemd support is an immediate NACK), I see no reason to duplicate packages. regards, dave
On 29/06/11 00:33, Dave Reisner wrote:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Signoff both, Dave
Signoff i686, Allan
[2011-06-28 10:33:19 -0400] Dave Reisner:
syslog-ng 3.2.4-2 is in [testing]. It's a rebuild with the following changes:
* add --enable-systemd flag to ./configure * add upstream patch to fix socket acitvation for systemd * package upstream syslog-ng.service
There should be zero impact for users still on sysvinit.
Another signoff for i686. -- Gaetan
participants (6)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Dave Reisner
-
Gaetan Bisson
-
Tom Gundersen