-----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

Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:

* Ralf Lang [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

Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:

* Krzysztof Żelechowski [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

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

* 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

-----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

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

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

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 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 :

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

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

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

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

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 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

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

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 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

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

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