Bug#449682: sysv-rc-conf: debian/watch fails to report upstream's version
Control: tag -1 +patch Add a patch to use sourceforge as upstream (to detect new version) -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 >From 811c0d2756693c6aed0888030d8669badb41822a Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Sun, 23 Apr 2017 23:52:24 +0900 Subject: [PATCH] debian/watch: Update to use sourceforge as upstream --- debian/watch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/watch b/debian/watch index f56a7e1..e719aac 100644 --- a/debian/watch +++ b/debian/watch @@ -1,3 +1,3 @@ # Site Directory Pattern Version Script -version=2 -ftp://ftp.pidone.org/sysv-rc-conf/sysv-rc-conf-(.*)\.tar\.gz debian uupdate +version=3 +http://sf.net/sysv-rc-conf/sysv-rc-conf-(.*)\.tar\.gz pgpS0rhIfPqoj.pgp Description: PGP signature
Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Dear systemd maintainers, I'm in the process of ITA adjtimex package, which contains a bug you reported that need to support rcS service. I'm trying to fix this before send out my 1st release to close ITA. > Package: adjtimex > Severity: important > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: init-rcs-service > Your package adjtimex has an initscript that is enabled in runlevel > S, but it does not provide a corresponding systemd service unit. As you may already know, adjtimex is a tool to set up kernel time variables in boot time. Correct time and time ticking is important to many services, including time-sync service, so in SysV world adjtimex is run in rcS level, which is very early. Enclosed the "adjtimex.service" file I wrote and confirmed working well on my box. Since this is the first time I write service file, it would be helpful if you can help to review it. I also have one doubt whether to have "RemainAfterExit=yes", which is commented out now. After setting the kernel time variables, adjtimex simply exits and don't need to remain as daemon. I guess it should be okay to be "no". Looking forward to your reply. Thank you! Cheers, Roger adjtimex.service Description: Binary data
Bug#750639: installing adjtimex gives syntax error message
Control: fixed -1 1.29-3 Control: merge -1 630812 thanks This bug is the same as #630812, and should be fixed in 1.29-3. Try to merge the 2 bugs here.
Bug#750639: installing adjtimex gives syntax error message
Control: merge -1 630812 thanks
Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Dear Felipe and Andreas, Your detailed feedback is really helpful. I really appreciate your kindness help! Enclosed my updated adjtimex.service file. Here's the explanation why I changed a bit. >> [Unit] >> Description=adjtimex service in early boot > I think the description of the init script is better: "set the kernel > time variables". I changed to "Description=the kernel time variables setting" Because it's more proper in the log with context: Nov 29 22:36:01 sid systemd[1]: Starting the kernel time variables setting... Nov 29 22:36:01 sid systemd[1]: Started the kernel time variables setting. >> #RemainAfterExit=yes > I have seen that Type=oneshot services that do not have > RemainAfterExit=yes can be executed multiple times during boot. This > may or may not be a problem here. > The RemainAfterExit directive controls wether systemd considers the > unit "active" after all the running processes in the unit exited. This > can trigger multiple runs during boot, if at some point this unit is > wanted, but it already ran and exited. My sense is that > RemainAfterExit should be =yes for most Type=oneshot service. > Unfortunately, that means that to manually re-run the unit, one needs > to do a "restart" instead of a "start" to make systemd run the program > again. Considering adjtimex is simply set time ticking related kernel variables on boot, it won't look after those kernel variables, which may be changed by other processes, such as NTP client, I think it's better to indicate the user that adjtimex service is NOT "active" after exiting. So I removed the line completely. If you're comfortable with this version of adjtimex.service, together with another minor fix, I'll build a package to upload to mentors, and ask for sponsor in mentors list. Thanks again! Cheers, Roger adjtimex.service Description: Binary data
Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file
Dear Felipe,
Thanks for your feedback!
> Note that this is not the only place that this description appears. It
> also shows in the output of "systemctl status adjtimex.service", or
> "systemctl list-units". This should really be a full descriptive
> sentence. Maybe, "Adjust kernel time variables".
I think you might misunderstand me.
The description you proposed would generate the following log:
[DATE TIME] [HOSTNAME] systemd[1]: Starting set the kernel time variables...
[DATE TIME] [HOSTNAME] systemd[1]: Started set the kernel time variables.
or
[DATE TIME] [HOSTNAME] systemd[1]: Starting Adjust kernel time variables...
[DATE TIME] [HOSTNAME] systemd[1]: Started Adjust kernel time variables.
What I proposed was:
[DATE TIME] [HOSTNAME] systemd[1]: Starting the kernel time
variables setting...
[DATE TIME] [HOSTNAME] systemd[1]: Started the kernel time
variables setting.
IMHO, it looks more natural.
Yes, I found other existing systemd service also use the way you
propose, like "systemd-tmpfiles-setup.service":
Nov 30 23:43:32 sid systemd[1]: Starting Create Volatile Files and
Directories...
Nov 30 23:43:32 sid systemd[1]: Started Create Volatile Files and
Directories.
I consider it's minor bug to say "starting verb" or "started verb",
which is better to fix in the future.
>> Environment="TICK=1 FREQ=0"
> I don't think this works. There should be no quotes there, or systemd
> might treat TICK variable as containing "1 FREQ=0".
Thanks for pointing this out.
Yes, it's totally not working.
I confirmed by commenting out "EnvironmentFile" line, and found
"ExecStart" command failed because of no FREQ is set.
changing from
Environment="TICK=1 FREQ=0"
to
Environment="TICK=10005" "FREQ=0"
will fix it.
>> EnvironmentFile=-/etc/default/adjtimex
>> ExecStart=/sbin/adjtimex -tick "$TICK" -frequency "$FREQ"
>
> I think the quotes are superfluous. If you want to preserve quoting,
> systemd does it by using ${TICK} and ${FREQ} syntax.
It seems fine as it was. However, following spec is always a good
thing, so I changed to what you proposed:
ExecStart=/sbin/adjtimex -tick ${TICK} -frequency ${FREQ}
Thanks again for your review!
Cheers,
Roger
adjtimex.service
Description: Binary data
Bug#796588: adjtimex: Has init script in runlevel S but no matching service file
Dear Felipe, Considering now we have consensus on the service file except the description part, which is quite minor, I made a release build of adjtimex package and uploaded to mentors. I also created a RFS: https://bugs.debian.org/806797 Since you helped me greatly on the service file, which is the most significant improvement of this version (adjtimex/1.29-6), I hope you can kindly be my sponsor to upload. Thank you! Cheers, Roger
