Linux Archive - systemd conversion

Linux Archive (http://www.linux-archive.org/)

- ArchLinux User Repository (http://www.linux-archive.org/archlinux-user-repository/)

- - systemd conversion (http://www.linux-archive.org/archlinux-user-repository/709681-systemd-conversion.html)

systemd conversion

Hi guys,

Thanks to everyone who converted their packages to use native systemd
service files since my last email.

There are stil 66 packages remaining in our TODO however (10 from
extra and the rest from community):
https://www.archlinux.org/todo/178/.

It would be great if we can get the last few packages sorted so
nothing is left out when systemd moves to base. It might be that some
packages are pseudo-orphans (i.e., officially maintained, but not in
practice), so those packages we should probably drop if no one adopts
them.

If you (for whatever reason) don't think you will be converting your
packages in the near future, please let us know so we know which
packages to focus on when we help out with the conversion. In
particular those of you who have not converted any (or only a small
percentage) of your packages [0], it would be helpful to know your
intentions.

Cheers,

Tom

[0]:

cbrannon
daenyth
daniel
jlichtblau
romashka
spupykin
tpowa
tredaelli

systemd conversion

On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
> Hi guys,
>
> Thanks to everyone who converted their packages to use native systemd
> service files since my last email.
>
> There are stil 66 packages remaining in our TODO however (10 from
> extra and the rest from community):
> https://www.archlinux.org/todo/178/.

I got a request from a user eager to help to post the full list (our
TODO lists are password protected, mostly by accident I think):

x86_64 Community esekeyd 1.2.7-2 cbrannon Incomplete
x86_64 Community espeakup 0.71-4 cbrannon Incomplete
x86_64 Community mldonkey 3.1.3-1 cbrannon Incomplete
x86_64 Community webfs 1.21-7 cbrannon Incomplete
x86_64 Community gkrellm 2.3.5-2 daenyth Incomplete
any Community lastfmsubmitd 1.0.6-5 daenyth Incomplete
x86_64 Community noip 2.1.9-3 daenyth Incomplete
x86_64 Extra mono 2.10.8-1 daniel Incomplete
x86_64 Extra xsp 2.10.2-3 daniel Incomplete
x86_64 Extra pdns 2.9.22.6-1 jgc Incomplete
x86_64 Extra pdns-recursor 3.3-2 jgc Incomplete
x86_64 Extra xorg-xfs 1.1.2-1 jgc, andyrtr Incomplete
x86_64 Community boinc 7.0.25-1 jlichtblau Incomplete
x86_64 Community boinc-nox 7.0.25-1 jlichtblau Incomplete
x86_64 Community monit 5.5-1 jlichtblau Incomplete
x86_64 Community quassel 0.8.0-1 jlichtblau, vesa Incomplete
x86_64 Community partimage 0.6.9-2 lfleischer Incomplete
x86_64 Community snort 2.9.3.1-1 lfleischer Incomplete
x86_64 Extra at 3.1.13-1 romashka Incomplete
x86_64 Extra net-snmp 5.7.1-3 romashka Incomplete
any Community ajaxterm 0.11-5 spupykin Incomplete
x86_64 Community bind-geodns 9.4.1-6 spupykin Incomplete
x86_64 Community couchdb 1.2.0-4 spupykin Incomplete
x86_64 Community dante 1.3.2-1 spupykin Incomplete
x86_64 Community darkstat 3.0.715-2 spupykin Incomplete
x86_64 Community dbmail 3.0.2-4 spupykin Incomplete
x86_64 Community dictd 1.12.0-4 spupykin Incomplete
any Community dkfilter 0.11-8 spupykin Incomplete
x86_64 Community dspam 3.10.2-1 spupykin Incomplete
x86_64 Community ejabberd 2.1.11-3 spupykin Incomplete
x86_64 Community freeradius 2.2.0-2 spupykin Incomplete
any Community gnump3d 3.0-6 spupykin Incomplete
x86_64 Community gnunet 0.9.3-1 spupykin Incomplete
x86_64 Community inputattach 1.24-5 spupykin Incomplete
x86_64 Community ipsec-tools 0.8.0-3 spupykin Incomplete
x86_64 Community ircservices 5.1.24-2 spupykin Incomplete
any Community jmc 0.2.3-5 spupykin Incomplete
x86_64 Community mcelog 1.0pre3-3 spupykin Incomplete
x86_64 Community mediaproxy 2.5.2-2 spupykin Incomplete
x86_64 Community opendkim 2.6.7-1 spupykin Incomplete
x86_64 Community opensips 1.8.1-1 spupykin Incomplete
x86_64 Community osiris 4.2.3-4 spupykin Incomplete
x86_64 Community p3scan 2.3.2-6 spupykin Incomplete
any Community postgrey 1.34-5 spupykin Incomplete
x86_64 Community pound 2.6-2 spupykin Incomplete
x86_64 Community pptpd 1.3.4-10 spupykin Incomplete
any Community pyaimt 0.8.0.1-4 spupykin Incomplete
any Community pyicqt 0.8.1.5-4 spupykin Incomplete
any Community pymsnt 0.11.3-6 spupykin Incomplete
any Community pyrss 0.9.9.1-9 spupykin Incomplete
x86_64 Community ser2net 2.7-2 spupykin Incomplete
x86_64 Community sysstat 10.1.1-1 spupykin Incomplete
any Community trac 1.0-1 spupykin Incomplete
x86_64 Community ultimate-ircd 3.0.2-5 spupykin Incomplete
x86_64 Community unrealircd 3.2.9-2 spupykin Incomplete
x86_64 Community xl2tpd 1.3.0-2 spupykin Incomplete
x86_64 Community xmms2 0.8DrO_o-7 spupykin Incomplete
any Community yahoo-t 0.4-4 spupykin Incomplete
x86_64 Extra hpoj 0.91-17 tpowa Incomplete
x86_64 Extra kexec-tools 2.0.3-1 tpowa Incomplete
x86_64 Extra usermin 1.520-1 tpowa Incomplete
x86_64 Extra vde2 2.3.2-1 tpowa Incomplete
x86_64 Community tinc 1.0.19-2 tredaelli Incomplete
x86_64 Community courier-authlib 0.64.0-2 Incomplete
x86_64 Community courier-imap 4.10.0-1 Incomplete
x86_64 Community courier-mta 0.68.1-1 Incomplete

Cheers,

Tom

systemd conversion

On Thu, Oct 4, 2012 at 8:27 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
>> Hi guys,
>>
>> Thanks to everyone who converted their packages to use native systemd
>> service files since my last email.
>>
>> There are stil 66 packages remaining in our TODO however (10 from
>> extra and the rest from community):
>> https://www.archlinux.org/todo/178/.
>
> I got a request from a user eager to help to post the full list (our
> TODO lists are password protected, mostly by accident I think):

And then Dave points out that there is indeed a public version:
<https://www.archlinux.org/todolists/#178>.

I'll shut up now,

Tom

systemd conversion

On 10/04/2012 12:27 PM, Tom Gundersen wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
>> Hi guys,
>>
>> Thanks to everyone who converted their packages to use native systemd
>> service files since my last email.
>>
>> There are stil 66 packages remaining in our TODO however (10 from
>> extra and the rest from community):
>> https://www.archlinux.org/todo/178/.
>
> I got a request from a user eager to help to post the full list (our
> TODO lists are password protected, mostly by accident I think):
>

It's not password protected if you navigate to it from archlinux.org.

Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
use those as environment files to work as drop-in replacements for the rc.d
scripts, but there's probably more systemd-ish ways of configuring most units.

systemd conversion

Am Thu, 4 Oct 2012 20:27:37 +0200
schrieb Tom Gundersen <teg@jklm.no>:

> x86_64 Extra xorg-xfs 1.1.2-1 jgc,
> andyrtr Incomplete

We will drop xorg-xfs completely from the repos. It's useless now.

-Andy

systemd conversion

On Thu, Oct 04, 2012 at 12:31:39PM -0600, Matthew Monaco wrote:
> On 10/04/2012 12:27 PM, Tom Gundersen wrote:
> > On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
> >> Hi guys,
> >>
> >> Thanks to everyone who converted their packages to use native systemd
> >> service files since my last email.
> >>
> >> There are stil 66 packages remaining in our TODO however (10 from
> >> extra and the rest from community):
> >> https://www.archlinux.org/todo/178/.
> >
> > I got a request from a user eager to help to post the full list (our
> > TODO lists are password protected, mostly by accident I think):
> >
>
>
> It's not password protected if you navigate to it from archlinux.org.
>
> Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
> use those as environment files to work as drop-in replacements for the rc.d
> scripts, but there's probably more systemd-ish ways of configuring most units.

Environment files from /etc/conf.d are not to be used. We provide sane
defaults in the unit file we ship (a conflation of the /etc/rc.d script
and the options in the /etc/conf.d file) and let users override in /etc
if needed.

d

systemd conversion

On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco <dgbaley27@0x01b.net> wrote:
> Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
> use those as environment files to work as drop-in replacements for the rc.d
> scripts, but there's probably more systemd-ish ways of configuring most units.

The general strategy is "don't do that". The reason being that such a
service file would never be acceptable upstream, as /etc/conf.d/ is
arch-specific. This means that we will likely have to change it again
in the future and it seems more natural to have the break now rather
than at random times later.

The ideal way to set things up is: don't use EnvironmentFile unless
you must. If you can, set up the service file so that it can give a
reasonable default out-of-the-box without further configuration.
Moreover, prefer configurations to happen in the native config files
of the service if they exist, rather than on the commandline. Lastly,
the expectation should be that in case the user/admin needs to tweak
the service file, this can be done by copying it to /etc/systemd/ and
editing it there, rather than editing a config file.

To be a bit less abstract:

* An example of where I could see no way but use EnvironmentFile is
for domainname.service in yp-tools.
* An example of where one might argue that an EnvironmentFile would
be useful, but where I think I found a reasonable way to avoid it is
transmission-cli.

Cheers,

Tom