[opensuse-packaging] package looking for maintainer: the AT daemon
Hi: I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5) So it is now up for grabs. that's all ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
Hi:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
that's all ;)
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"? If these are sane values, I might take over ;-) - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCU3hoACgkQCs1dsHJ/X7A91wCeJNpuKZHjN0UiCFiQIKzsJztS vAIAoORTf6TOOctKYWs62sIsxdG/ngGq =eCQy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
Hi:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
that's all ;)
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:
* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
Hi:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
that's all ;)
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).
What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:
Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:
* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
Hi:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
that's all ;)
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).
What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.
In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:
* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:
Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:
at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).
What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.
In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the
Everything is either abandoned or de-facto controlled by somebody.
overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources.
This means expensive, not proprietary. IMHO, Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-05 19:30]:
Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:
* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:
Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:
at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).
What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.
In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the
Everything is either abandoned or de-facto controlled by somebody.
You are missing the point, the someone greatly matters and is in this case a single commercial entity whose decisions will reflect the needs for their products and their business interests. That is certainly their right by virtue of funding much of its development, it should however by noted that these decisions are not necessarily in the best interests or even detrimental to the interests of other projects and vendors. Init and udev are the most central and important pieces apart from the kernel and there is an ever increasing amount of previously loosely-coupled, separate userland components such as cron, atd, acpid, syslog, ConsoleKit, and now user sessions which are being sucked up into systemd. While it probably makes sense for RedHat to streamline and take control of or at least exert significant influence over this middle stack, it also represents a radical departure from the current Linux ecosystem where distros have a certain degree of flexibility in what and which components they include based on their specific needs and technical merit. Once they're in the systemd train they more or less have to take what gets handed down to them, that is what systemd depends on or replaces next, as getting off becomes increasingly costly, just as avoiding it altogether since RH seems to be eager on pushing dependencies up the stack. In the FOSS world competition or even the potential threat of a fork or alternative solution and users voting with their feet are important means of driving progress, pushing towards technically optimal solutions, and ensuring a degree of responsiveness to consumers. After systemd has gathered enough momentum, there is even less incentive to take the needs of from anyone but their own and their paying customers into account or to strive for technically optimal design. You can already see the symptoms of that reflected in design decisions, such as the offline updates feature designed around the deficiencies of RH's package management, the requirement to upgrade systemd and the kernel in lockstep, udev dropping support for installation in /lib, the inclusion of FSS in order to boost the academic career of developers family members and so on.
overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources.
This means expensive, not proprietary.
Lets please move any further discussion to opensuse-offtopic or private since this is getting off topic here. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Guido, On Saturday 03 November 2012 14:14:11 Guido Berhoerster wrote:
the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources.
I do see your point, but as long as systemd is Free Software, I wouldn't call it proprietary. The fact that me might not have the resources to exercise the freedom _fully_ does play a role, but does not make the software non-free. You might not be able to run a newspaper, but still enjoy freedom of press. Regards, Torsten -- Torsten Grote, Kolab Evangelist Kolab Systems AG, Zürich, Switzerland e: grote@kolabsys.com t: +41 43 501 66 91 w: http://kolabsys.com pgp: 274D 4F97 Torsten Grote
El 03/11/12 08:56, Guido Berhoerster escribió:
at(1) is part of the posix utilities so it won't go away any time
Sure,I am not saying it will go away.. I am saying that I wont invest my resources on it. hence I ask for someone with interest in paleontology to take over. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Samstag, 3. November 2012 schrieb Ralf Lang:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
If these are sane values, I might take over ;-)
At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details. Besides that, the changelog looks quite boring to me ;-) (and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-) Regards, Christian Boltz -- Ja, Suuuse... die machen bald auch ein "system32"-Verzeichnis auf. :-) [Ratti in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sun, Nov 04, 2012 at 04:40:27PM +0100, Christian Boltz wrote:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5) ... At the risk of scaring you away - one of the first things the future
Am 03.11.2012 03:29, schrieb Cristian Rodríguez: maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
Besides that, the changelog looks quite boring to me ;-)
(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)
Quite the opposite here... while I wouldn't mind maintaining atd, I certainly don't want to maintain a systemd service file. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.11.2012 16:40, schrieb Christian Boltz:
Hello,
Am Samstag, 3. November 2012 schrieb Ralf Lang:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
If these are sane values, I might take over ;-)
At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
Besides that, the changelog looks quite boring to me ;-)
(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)
I'll look at it and report back yes/no - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCXvvEACgkQCs1dsHJ/X7B2MACdEZ0W2mSAlPqnXOGyu/gllR2u KaYAnjnqKmgPX3Fu0MvTaz4g0y20RPHw =pXhr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Montag, 5. November 2012 schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez: At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and
Am Samstag, 3. November 2012 schrieb Ralf Lang: the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}' (should I have added a comment "# looks ugly, but works"? ;-) See - request #142950 to Base:System - request #142949 for the 12.2 update but...
(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)
... this is still valid ;-)
I'll look at it and report back yes/no
Any news? ;-) Regards, Christian Boltz --
It is a pity that [Tumbleweed] fails to continue quickly after an openSUSE upgrade [...] A "pity"? That's a good one, you now owe me a beer for complaining :) [Erwin Van de Velde and Greg KH in opensuse-factory]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz wrote:
Am Montag, 5. November 2012 schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez: At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and
Am Samstag, 3. November 2012 schrieb Ralf Lang: the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'
(should I have added a comment "# looks ugly, but works"? ;-)
I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly. Using shell for this kind of things is one of the reasons why init scrips became such beasts. cu Ludwig [1] maybe we should have a common C library for that task -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly.
I think this remark shows very cleanly why so many *feel* that there is something wrong with the systemd concept. May be it has some merits over sysinit, but: It contradicts KISS. "atd" (or any other daemon) should do what it is designed for. If any init system wants to start it, it has to deal with "at", *not* the other way round. To me what you call "ideally" sounds just like a wrong way. Just an observation, 2c as usual, by no means a try to start another discussion about this topic. Detlef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Detlef Steuer wrote:
I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly.
I think this remark shows very cleanly why so many *feel* that there is something wrong with the systemd concept. May be it has some merits over sysinit, but:
It contradicts KISS. "atd" (or any other daemon) should do what it is designed for. If any init system wants to start it, it has to deal with "at", *not* the other way round. To me what you call "ideally" sounds just like a wrong way.
Well, this has nothing to do with systemd actually. Looks like at some point in time someone decided that atd should be configurable via sysconfig. The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michal Kubeček wrote:
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.
So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 27 November 2012, Ludwig Nussel wrote:
Michal Kubeček wrote:
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.
So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.
Hm, on the other hand this at package is a very good example how you can mess up a package by adding tons of "nice" patches so that it becomes really hard to follow upstream. Suse's at packages got not updates from upstream since 2005. Maybe one reason for this is that nobody wants to rebase (and test) all these existing patches. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ruediger Meier wrote:
On Tuesday 27 November 2012, Ludwig Nussel wrote:
Michal Kubeček wrote:
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.
So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.
Hm, on the other hand this at package is a very good example how you can mess up a package by adding tons of "nice" patches so that it becomes really hard to follow upstream.
Suse's at packages got not updates from upstream since 2005. Maybe one reason for this is that nobody wants to rebase (and test) all these existing patches.
Maybe, maybe not. Maybe the maintainer never tried to get the patches upstream? Maybe upstream is an idiot? Maybe the patches are bad quality? Maybe the project was dead and had no upstream for a long time? Do you know? I don't. Someone who actually cares about maintainging the at package has to find out and clean up the mess. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
At Tue, 27 Nov 2012 13:38:38 +0100, Ludwig Nussel wrote:
Michal Kubeček wrote:
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.
So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.
True, but only if parsing (SUSE-specific) sysconfig variables is acceptable for the upstream, too. In other words, if such a patch won't be merged to the upstream, we'll need to carry over the patch forever. It'd be much more pain than maintaining an init shell script. (Of course, this is about packages where we do "follow upstream". For packages that carry already tons of our own patches, it doesn't matter :) Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Takashi Iwai wrote:
At Tue, 27 Nov 2012 13:38:38 +0100, Ludwig Nussel wrote:
Michal Kubeček wrote:
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.
So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.
True, but only if parsing (SUSE-specific) sysconfig variables is acceptable for the upstream, too. In other words, if such a patch won't be merged to the upstream, we'll need to carry over the patch forever. It'd be much more pain than maintaining an init shell script.
I don't agree. Whether or not such a patch would be openSUSE specific is also questionable. Looks like at least Fedora also wants to have atd parameters configurable. Maybe upstream would be open to accepting a patch for a global config file (in whatever format)? You will never find out if you don't even ask and keep writing shell wrappers. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
At Tue, 27 Nov 2012 16:33:57 +0100, Ludwig Nussel wrote:
Takashi Iwai wrote:
At Tue, 27 Nov 2012 13:38:38 +0100, Ludwig Nussel wrote:
Michal Kubeček wrote:
On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:
The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.
As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.
So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.
True, but only if parsing (SUSE-specific) sysconfig variables is acceptable for the upstream, too. In other words, if such a patch won't be merged to the upstream, we'll need to carry over the patch forever. It'd be much more pain than maintaining an init shell script.
I don't agree. Whether or not such a patch would be openSUSE specific is also questionable. Looks like at least Fedora also wants to have atd parameters configurable. Maybe upstream would be open to accepting a patch for a global config file (in whatever format)? You will never find out if you don't even ask and keep writing shell wrappers.
Sure, I don't mean to stick *only* with the init shell script. It's broken for systemd, thus it must be fixed. No doubt about it. And the fix should be done together with the upstream at best indeed. Go ahead. However, a random patching in SUSE package can be rather a pain by itself alone. As mentioned, it's often harder to maintain unless accepted in the upstream. So, the key is the collaborative fix with the upstream. It might be a few lines of C code, but it needs lots of social tasks in addition. The background I write this is that, honestly speaking, I can hardly imagine that a SUSE-specific sysconfig is acceptable as a common infrastructure over all distros. If I were to get a patch from a Canonical guy to add a patch to parse Ubuntu's config file to any ALSA util programs, I'd reject it :) A typical and likely solution will be to introduce a new config file in the end, with a hope that the downstream will follow to change their tools like YaST for managing the new config file. This is a cleaner solution, but takes a long long way... Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Takashi Iwai <tiwai@suse.de>:
At Tue, 27 Nov 2012 16:33:57 +0100, Sure, I don't mean to stick *only* with the init shell script. It's broken for systemd, thus it must be fixed. No doubt about it. And the fix should be done together with the upstream at best indeed. Go ahead.
However, a random patching in SUSE package can be rather a pain by itself alone. As mentioned, it's often harder to maintain unless accepted in the upstream.
So, the key is the collaborative fix with the upstream. It might be a few lines of C code, but it needs lots of social tasks in addition.
The background I write this is that, honestly speaking, I can hardly imagine that a SUSE-specific sysconfig is acceptable as a common infrastructure over all distros. If I were to get a patch from a Canonical guy to add a patch to parse Ubuntu's config file to any ALSA util programs, I'd reject it :)
A typical and likely solution will be to introduce a new config file in the end, with a hope that the downstream will follow to change their tools like YaST for managing the new config file. This is a cleaner solution, but takes a long long way...
finally we're talking what it takes to be a packager / package maintainer... it's not about writing the .spec file (the syntax is not that difficult after all), but more aspects around it and a good contact / relation with upstream is very essential to be able to maintain the packages in long term. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
At Tue, 27 Nov 2012 17:03:00 +0100, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Takashi Iwai <tiwai@suse.de>:
At Tue, 27 Nov 2012 16:33:57 +0100, Sure, I don't mean to stick *only* with the init shell script. It's broken for systemd, thus it must be fixed. No doubt about it. And the fix should be done together with the upstream at best indeed. Go ahead.
However, a random patching in SUSE package can be rather a pain by itself alone. As mentioned, it's often harder to maintain unless accepted in the upstream.
So, the key is the collaborative fix with the upstream. It might be a few lines of C code, but it needs lots of social tasks in addition.
The background I write this is that, honestly speaking, I can hardly imagine that a SUSE-specific sysconfig is acceptable as a common infrastructure over all distros. If I were to get a patch from a Canonical guy to add a patch to parse Ubuntu's config file to any ALSA util programs, I'd reject it :)
A typical and likely solution will be to introduce a new config file in the end, with a hope that the downstream will follow to change their tools like YaST for managing the new config file. This is a cleaner solution, but takes a long long way...
finally we're talking what it takes to be a packager / package maintainer... it's not about writing the .spec file (the syntax is not that difficult after all), but more aspects around it and a good contact / relation with upstream is very essential to be able to maintain the packages in long term.
Right. But don't forget that the whole story is not only about contacts with the upstream. For example, if a new config file scheme is introduced, it must be adapted by its management tools. This implies a contact with *internal* tool maintainers, too. And at best, involve these tool maintainers from the very beginning of the action. Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Dienstag, 27. November 2012 schrieb Ludwig Nussel:
Christian Boltz wrote:
Am Montag, 5. November 2012 schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz: I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'
(should I have added a comment "# looks ugly, but works"? ;-)
I don't think the above is in the spirit of systemd.
That's very visible when you look at the ExecStart line ;-) and is also the reason why I asked if I should have added the "looks ugly, but works" comment ;-) The motivation behind this change was simple - fix the bug "settings in /etc/sysconfig/atd are ignored" (which was a regression by switching to a service file). I never said I like this solution, but it works ;-) For future versions, feel free to fix atd so that it reads a config file at startup.
Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly.
Or /etc/atd.conf ;-) Anyway - yes, _every daemon_ should have a config file where you can configure everything that you can specify as commandline option. Having only commandline options for a daemon is pointless. Besides that: yes, I love to keep things simple, and therefore like the systemd approach. But as you can see, things aren't always that easy ;-)
Using shell for this kind of things is one of the reasons why init scrips became such beasts.
Allow me to disagree ;-) IMHO the main problem of initscripts is that they contain a big copy&paste skeleton. If you have two initscripts that are based on the same (version of the) skeleton, you'll have 80 identical lines and maybe 10 lines that actually differ. In other words: you have to maintain those 80 lines 50 times because they were copied to 50 initscripts. You can't call that "code duplication" - it's "code multiplication" ;-) I'm quite sure we could have "maintainable" init scripts by rewriting them to a common "base script" that includes daemon-specific config or code sniplets. Maybe those sniplets could even look similar to the systemd service files (in a bash-readable syntax of course) - and I'm sure those sniplets could be as short as a service file for most daemons. [1] OTOH, there are cases where service files are "too simple" (especially various boot.* initscripts come to mind), so we _will_ need to call a (wrapper) script to do the actual work in some cases. Regards, Christian Boltz [1] No, I'm not proposing to go back to sysvinit and rewrite all initscripts - but I'm quite sure it would be possible. -- Ich rede davon, daß eine defekte Schrift an freetype übergeben wird (Daß sie defekt ist, kann ich ja nicht prüfen), woraufhin freetype irgendeine (defekte) Anweisung im Fontcode ohne Prüfung ausführt und erstmal getreulich versucht, sagenwirmal 5 Okobyte RAM von der Adresse $IRSINN nach $WAHNSINN zu verschieben. [Ratti in suse-programming] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz wrote:
Am Dienstag, 27. November 2012 schrieb Ludwig Nussel:
Christian Boltz wrote:
Am Montag, 5. November 2012 schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz: I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'
(should I have added a comment "# looks ugly, but works"? ;-)
I don't think the above is in the spirit of systemd.
That's very visible when you look at the ExecStart line ;-) and is also the reason why I asked if I should have added the "looks ugly, but works" comment ;-)
The motivation behind this change was simple - fix the bug "settings in /etc/sysconfig/atd are ignored" (which was a regression by switching to a service file). I never said I like this solution, but it works ;-)
This is really a question of policy to me. Do we want to pollute .service files with such /bin/bash constructs? If the shell wrapper is inevitable it could be implemented in a regular file just as well (/usr/sbin/atd_systemd_wrapper or something like that). That would at least keep both the .service file and the script readable and avoids quoting issues. Or just keep the working init script and admit that the software isn't ready for the new world order yet. I wonder why the broken .service file was added to atd in the first place. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 28 November 2012, Ludwig Nussel wrote:
I wonder why the broken .service file was added to atd in the first place.
Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ... cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Nov 28, 2012 at 11:00:46AM +0100, Ruediger Meier wrote:
On Wednesday 28 November 2012, Ludwig Nussel wrote:
I wonder why the broken .service file was added to atd in the first place.
Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ...
Well that change probably came from here: Mon Dec 5 19:05:48 UTC 2011 - crrodriguez@opensuse.org - Support systemd. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 28 November 2012, Marcus Meissner wrote:
On Wed, Nov 28, 2012 at 11:00:46AM +0100, Ruediger Meier wrote:
On Wednesday 28 November 2012, Ludwig Nussel wrote:
I wonder why the broken .service file was added to atd in the first place.
Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ...
Well that change probably came from here:
Mon Dec 5 19:05:48 UTC 2011 - crrodriguez@opensuse.org - Support systemd.
Yep, he just took a random service file from http://0pointer.de/public/systemd-units/atd.service and then accepted his own submit request ... https://build.opensuse.org/request/show/95490 cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 28/11/12 07:30, Ruediger Meier escribió:
On Wednesday 28 November 2012, Marcus Meissner wrote:
On Wed, Nov 28, 2012 at 11:00:46AM +0100, Ruediger Meier wrote:
On Wednesday 28 November 2012, Ludwig Nussel wrote:
I wonder why the broken .service file was added to atd in the first place.
Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ...
Well that change probably came from here:
Mon Dec 5 19:05:48 UTC 2011 - crrodriguez@opensuse.org - Support systemd.
Yep, he just took a random service file from http://0pointer.de/public/systemd-units/atd.service and then accepted his own submit request ... https://build.opensuse.org/request/show/95490
The unit is correct, however our version of at is/was outdated and lacked of a needed command line flag. I missed that, my bad ;P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
В Wed, 28 Nov 2012 11:47:38 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
El 28/11/12 07:30, Ruediger Meier escribió:
On Wednesday 28 November 2012, Marcus Meissner wrote:
On Wed, Nov 28, 2012 at 11:00:46AM +0100, Ruediger Meier wrote:
On Wednesday 28 November 2012, Ludwig Nussel wrote:
I wonder why the broken .service file was added to atd in the first place.
Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ...
Well that change probably came from here:
Mon Dec 5 19:05:48 UTC 2011 - crrodriguez@opensuse.org - Support systemd.
Yep, he just took a random service file from http://0pointer.de/public/systemd-units/atd.service and then accepted his own submit request ... https://build.opensuse.org/request/show/95490
The unit is correct, however our version of at is/was outdated and lacked of a needed command line flag. I missed that, my bad ;P
Do you mean that newer version of atd supports reading options from /etc/sysconfig/atd? If not, how can this unit file be correct? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 28 Nov 2012 11:30:39 +0100 Ruediger Meier <sweet_f_a@gmx.de> wrote: ...
Yep, he just took a random service file from http://0pointer.de/public/systemd-units/atd.service
http://0pointer.de/public/systemd-units.out-of-date/ :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 27/11/12 06:48, Ludwig Nussel escribió:
I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly. Using shell for this kind of things is one of the reasons why init scrips became such beasts.
The main issue here is the usage of this wonderful invention called sysconfig, which is really a hack for software whose authors were too lazy to include a basic configuration file. ;) Now it has become entangled into the complete system and is very hard to get rid of :-|
[1] maybe we should have a common C library for that task
libHX already knows how to parse sysconfig files AFAIK. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 27.11.2012 20:22, schrieb Cristian Rodríguez:
El 27/11/12 06:48, Ludwig Nussel escribió:
I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly. Using shell for this kind of things is one of the reasons why init scrips became such beasts.
The main issue here is the usage of this wonderful invention called sysconfig, which is really a hack for software whose authors were too lazy to include a basic configuration file. ;)
Now it has become entangled into the complete system and is very hard to get rid of :-|
[1] maybe we should have a common C library for that task
libHX already knows how to parse sysconfig files AFAIK.
Does debian actually have some scm for at or are just magically tarballs popping up at their ftp site? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 27/11/12 16:49, Ralf Lang (B1 Systems GmbH) escribió:
Does debian actually have some scm for at or are just magically tarballs popping up at their ftp site?
YEs, there is a git repo. http://anonscm.debian.org/gitweb/?p=collab-maint/at.git -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 27.11.2012 21:03, schrieb Cristian Rodríguez:
El 27/11/12 16:49, Ralf Lang (B1 Systems GmbH) escribió:
Does debian actually have some scm for at or are just magically tarballs popping up at their ftp site?
YEs, there is a git repo.
We recently upgraded factory at to debian's 3.1.13 plus suse related patches. After coarse testing, it seems like it doesn't break common use cases. Factory users please test any known edge cases so we can fix anything in time for release -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
El 12/06/13 09:26, Ralf Lang escribió:
We recently upgraded factory at to debian's 3.1.13 plus suse related patches. After coarse testing, it seems like it doesn't break common use cases. Factory users please test any known edge cases so we can fix anything in time for release
Thanks, the last time I tried such update atd functionality was stopped by the audit subsystem atd[9468]: PAM audit_log_acct_message() failed: Operation not permitted I did not investigate further though, does it work correctly now ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Cristian Rodríguez (crrodriguez@opensuse.org) wrote:
El 27/11/12 06:48, Ludwig Nussel escribió:
I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly. Using shell for this kind of things is one of the reasons why init scrips became such beasts.
The main issue here is the usage of this wonderful invention called sysconfig, which is really a hack for software whose authors were too lazy to include a basic configuration file. ;)
I don't have any reasons for a biased opinion either way, but it seems to me that you could also argue that this kind of laziness is *good*, i.e. the authors were too lazy to reinvent a wheel, and that the consistent location and format of config files it results in is an advantage which can then be harnessed by things like yast. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El mar 27 nov 2012 20:47:35 CLST, Adam Spiers escribió: ,
i.e. the authors were too lazy to reinvent a wheel, and that the consistent location and format of config files it results in is an advantage which can then be harnessed by things like yast.
Maybe, but I think that there are other factors as well, at the time this concept was invented, systems had little processing power,storage and most importantly..there were no shared libraries so everything had to be a command line argument, a shell script, a pipe etc... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 26/11/12 15:34, Christian Boltz escribió:
Hello,
Am Montag, 5. November 2012 schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez: At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and
Am Samstag, 3. November 2012 schrieb Ralf Lang: the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'
(should I have added a comment "# looks ugly, but works"? ;-)
See - request #142950 to Base:System - request #142949 for the 12.2 update
OK, I just now submitted a proper fix ;) created request id 143492 I rest my case with this thing though ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 28 November 2012, Cristian Rodríguez wrote:
El 26/11/12 15:34, Christian Boltz escribió:
Hello,
Am Montag, 5. November 2012 schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz:
Am Samstag, 3. November 2012 schrieb Ralf Lang:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'
(should I have added a comment "# looks ugly, but works"? ;-)
See - request #142950 to Base:System - request #142949 for the 12.2 update
OK, I just now submitted a proper fix ;) created request id 143492
I rest my case with this thing though ;)
Apart from that I find it very ugly to introduce the libHX dependency just to parse 2 lines from a bash style sysconfig config file there are some issues with that patch. Command line arguments should override the config file and not the other way around. The arguments from the config options should be parsed like the commandline ones inclusive error handling and not using atoi and atof. Config file should be mentioned in the man page. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 29/11/12 07:38, Ruediger Meier wrote:
Apart from that I find it very ugly to introduce the libHX dependency just to parse 2 lines from a bash style sysconfig config file there are some issues with that patch.
We have shared libraries to use them and avoid reinventing parsers.
Command line arguments should override the config file and not the other way around.
The arguments from the config options should be parsed like the commandline ones inclusive error handling and not using atoi and atof. Config file should be mentioned in the man page.
Feel free to improve it, as the $SUBJECT says I will no longer spend time on this at thingy. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 29 November 2012, Cristian Rodríguez wrote:
On 29/11/12 07:38, Ruediger Meier wrote:
Apart from that I find it very ugly to introduce the libHX dependency just to parse 2 lines from a bash style sysconfig config file there are some issues with that patch.
We have shared libraries to use them and avoid reinventing parsers.
Command line arguments should override the config file and not the other way around.
The arguments from the config options should be parsed like the commandline ones inclusive error handling and not using atoi and atof. Config file should be mentioned in the man page.
Feel free to improve it, as the $SUBJECT says I will no longer spend time on this at thingy.
So your last action is breaking it again. My fix would be to just revert your patch. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/11/12 09:50, Ruediger Meier escribió:
So your last action is breaking it again.
No, atd is supposed to be started from a systemd unit that the vast majority of users will not modify and instead will add the options to the sysconfig file.
My fix would be to just revert your patch.
I get it now, the idea is to complain and sabotage changes and not actually do anything constructive yourself. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 29 November 2012, Cristian Rodríguez wrote:
El 29/11/12 09:50, Ruediger Meier escribió:
So your last action is breaking it again.
No, atd is supposed to be started from a systemd unit that the vast majority of users will not modify and instead will add the options to the sysconfig file.
That does not mean that you should break the things for the minority. atd should work according to it's documentation. Actually your patch not only introduced config file parsing but practically also disabled command line parsing.
My fix would be to just revert your patch.
I get it now, the idea is to complain and sabotage changes and not actually do anything constructive yourself.
The idea is to only accept patches which does not break documented and well known behaviour ... cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 05.11.2012 14:28, schrieb Ralf Lang:
Am 04.11.2012 16:40, schrieb Christian Boltz:
Hello,
Am Samstag, 3. November 2012 schrieb Ralf Lang:
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
If these are sane values, I might take over ;-)
At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.
Besides that, the changelog looks quite boring to me ;-)
(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)
I'll look at it and report back yes/no
Request filed. https://build.opensuse.org/request/show/143267 -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* V Sobota 3. listopad 2012, 10:04:26 [CET] Ralf Lang napsal:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 03.11.2012 03:29, schrieb Cristian Rodríguez:
Hi:
I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)
So it is now up for grabs.
that's all ;)
Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?
If these are sane values, I might take over ;-)
The at daemon had no upstream for a long time. Debian took over the project and Fedora is using their version. We maintain our set of (19) patches. The new maintainer (c|sh)ould think about updating and merging the patchset. -- Vita Cizek
participants (19)
-
Adam Spiers -
Andrey Borzenkov -
Christian Boltz -
Cristian Rodríguez -
Detlef Steuer -
Dominique Leuenberger a.k.a DimStar -
Guido Berhoerster -
Krzysztof Żelechowski -
Ludwig Nussel -
Marcus Meissner -
Michal Kubecek -
Michal Kubeček
-
Rajko -
Ralf Lang -
Ralf Lang (B1 Systems GmbH)
-
Ruediger Meier -
Takashi Iwai -
Torsten Grote -
Vitezslav Cizek