[aur-general] [REMINDER] systemd conversion

newer
[aur-general] Signoff report for...

Tom Gundersen

4 Oct 2012 4 Oct '12

9:16 p.m.

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

Show replies by date

Tom Gundersen

4 Oct 4 Oct

9:27 p.m.

On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen 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

Tom Gundersen

9:29 p.m.

On Thu, Oct 4, 2012 at 8:27 PM, Tom Gundersen wrote:

...

On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen 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

Matthew Monaco

9:31 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On 10/04/2012 12:27 PM, Tom Gundersen wrote:

...

On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen 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.

Dave Reisner

9:47 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] 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 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

David J. Haines

10:12 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, Oct 04, 2012 at 02:47:34PM -0400, Dave Reisner wrote:

...

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

Is there now any equivalent to .pacnew files for what would have been configuration files in /etc/conf.d? That is to say, if before a user edited /etc/conf.d/<some file> and that file received a newer version in its package, a .pacnew file would be left behind, indicating that the user should set about merging his/her custom configuration into the newer "stock" configuration. Very useful, that. Now, however, it would seem that the user will never see such a message (even though potentially critical changes have been made to the unit file) because the custom unit file in /etc/systemd/... won't be tracked by pacman. Is there a good solution for detecting such changes, so that users can once again merge their necessary changes into the systemd equivalents of /etc/conf.d files? -- David J. Haines djhaines@gmx.com

Tom Gundersen

10:19 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines wrote:

...

Is there now any equivalent to .pacnew files for what would have been configuration files in /etc/conf.d? That is to say, if before a user edited /etc/conf.d/<some file> and that file received a newer version in its package, a .pacnew file would be left behind, indicating that the user should set about merging his/her custom configuration into the newer "stock" configuration. Very useful, that. Now, however, it would seem that the user will never see such a message (even though potentially critical changes have been made to the unit file) because the custom unit file in /etc/systemd/... won't be tracked by pacman.

Is there a good solution for detecting such changes, so that users can once again merge their necessary changes into the systemd equivalents of /etc/conf.d files?

Using Includes rather than copying the full service file reduces this problem somewhat. Moreover, there is the systemd-delta tool which is quite useful (it shows you the "diff" between the shipped service file and the actual one that you are using). -t

David J. Haines

10:24 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, Oct 04, 2012 at 09:19:00PM +0200, Tom Gundersen wrote:

...

On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines wrote:

...
Is there now any equivalent to .pacnew files for what would have been configuration files in /etc/conf.d? That is to say, if before a user edited /etc/conf.d/<some file> and that file received a newer version in its package, a .pacnew file would be left behind, indicating that the user should set about merging his/her custom configuration into the newer "stock" configuration. Very useful, that. Now, however, it would seem that the user will never see such a message (even though potentially critical changes have been made to the unit file) because the custom unit file in /etc/systemd/... won't be tracked by pacman.

Is there a good solution for detecting such changes, so that users can once again merge their necessary changes into the systemd equivalents of /etc/conf.d files?

Using Includes rather than copying the full service file reduces this problem somewhat. Moreover, there is the systemd-delta tool which is quite useful (it shows you the "diff" between the shipped service file and the actual one that you are using).

-t

Nice. Thanks! -- David J. Haines djhaines@gmx.com

Tom Gundersen

9:47 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco 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

Matthew Monaco

9:58 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On 10/04/2012 12:47 PM, Tom Gundersen wrote:

...

On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco 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

Ok, that said: This will do what rc.d/webfsd does with conf.d/webfsd: webfsd.service --------------------------------------------------------- [Unit] Description=webfsd Documentation=man:webfsd(1) After=network.target [Service] ExecStart=/usr/bin/webfsd -p 8080 -u nobody -R /srv/http -f index.html -F [Install] WantedBy=multi-user.target But I think an EnvironmentFile is useful for this service as it only takes config on the command line. webfsd@.service -------------------------------------------------------- [Unit] Description=webfsd Documentation=man:webfsd(1) After=network.target [Service] EnvironmentFile=/etc/webfs/%i.conf ExecStart=/usr/bin/webfsd $WEBFSD_ARGS -F [Install] WantedBy=multi-user.target

Tom Gundersen

10:10 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, Oct 4, 2012 at 8:58 PM, Matthew Monaco wrote:

...

This will do what rc.d/webfsd does with conf.d/webfsd: webfsd.service --------------------------------------------------------- [Unit] Description=webfsd Documentation=man:webfsd(1) After=network.target

[Service] ExecStart=/usr/bin/webfsd -p 8080 -u nobody -R /srv/http -f index.html -F

[Install] WantedBy=multi-user.target

But I think an EnvironmentFile is useful for this service as it only takes config on the command line. webfsd@.service -------------------------------------------------------- [Unit] Description=webfsd Documentation=man:webfsd(1) After=network.target

[Service] EnvironmentFile=/etc/webfs/%i.conf ExecStart=/usr/bin/webfsd $WEBFSD_ARGS -F

[Install] WantedBy=multi-user.target

It depends on the service/daemon of course, so there might be a case for doing this. I would say to keep it simple in general (the first file you pasted), but if it turns out that there is no way to make it generic enough (e.g., in the case of domainname literally every admin would need to tweak the file), then using EnvFile might make sense. I would, however, really resist using instances of config files as you did here, unless that is really a common scenario (I don't know this software at all, so might be). Let's keep it simple :-) -t

Kyle

5 Oct 5 Oct

11:30 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

I have a working unit for espeakup, which I saw listed in this thread, but I seem to recall Chris mentioning that he already had one. Let me know if it's needed, and if so, where I should post it. ~Kyle -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009

Stefan Wilkens

6 Oct 6 Oct

3:15 a.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012/10/5 Kyle :

...

I have a working unit for espeakup, which I saw listed in this thread, but I seem to recall Chris mentioning that he already had one. Let me know if it's needed, and if so, where I should post it. ~Kyle -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009

In a similar fashion; I took this as a time to learn how to deal with systemd and produced something usable for xmms2. Topic here: https://bbs.archlinux.org/viewtopic.php?id=150154

Tom Gundersen

20 Oct 20 Oct

1:07 a.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

Hi Kyle, On Fri, Oct 5, 2012 at 10:30 PM, Kyle wrote:

...

I have a working unit for espeakup, which I saw listed in this thread, but I seem to recall Chris mentioning that he already had one. Let me know if it's needed, and if so, where I should post it.

Could you post your service file to the list (maybe inline if the list does not accept attachments)? As Chris is no longer active, I'll push a new espeakup with the service files. However, I don't use it myself, so would be great if I could have something that was already tested :-) Cheers, Tom

Kyle

4:02 a.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

According to Tom Gundersen: # Could you post your service file to the list (maybe inline if the list # does not accept attachments)? As Chris is no longer active, I'll push # a new espeakup with the service files. However, I don't use it myself, # so would be great if I could have something that was already tested No problem. It's tested here and works without any issues. Cut between the lines and edit as needed. --- begin espeakup.service --- [Unit] Description=Software speech output for Speakup using eSpeak [Service] Type=forking PIDFile=/var/run/espeakup.pid ExecStart=/usr/bin/espeakup ExecReload=/bin/kill -HUP $MAINPID Restart=always [Install] WantedBy=multi-user.target --- end espeakup.service --- ~Kyle -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009

Tom Gundersen

10:23 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Sat, Oct 20, 2012 at 3:02 AM, Kyle wrote:

...

According to Tom Gundersen: # Could you post your service file to the list (maybe inline if the list # does not accept attachments)? As Chris is no longer active, I'll push # a new espeakup with the service files. However, I don't use it myself, # so would be great if I could have something that was already tested

No problem. It's tested here and works without any issues. Cut between the lines and edit as needed.

Thanks! I put this (with minor modifications) in community-testing. Could anyone confirm that it works as intended? Cheers, Tom

Taylor Lookabaugh

21 Oct 21 Oct

5:16 a.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

I reported a bug regarding ejabberd with respect to systemd. https://bugs.archlinux.org/task/32129 -- Taylor Lookabaugh "I consider my ability to arouse enthusiasm among my people, the greatest asset I possess, and the way to develop the best that is in a person is by appreciation and encouragement. There is nothing else that so kills the ambitions of a person as criticisms from superiors. I never criticize any-one. I believe in giving a person incentive to work. So I am anxious to praise but loath to find fault. If I like anything, I am hearty in my approbation and lavish in my praise." --Charles Schwab

Daniel Isenmann

4 Oct 4 Oct

9:57 p.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, 2012-10-04 at 20:27 +0200, Tom Gundersen wrote:

...

On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen 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 Extra mono 2.10.8-1 daniel Incomplete x86_64 Extra xsp 2.10.2-3 daniel Incomplete

Hi, feel free to do the above packages. I'm totally busy with my real life right now and don't have time to do it at the moment. - Daniel

Tom Gundersen

7 Oct 7 Oct

2:55 a.m.

New subject: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

On Thu, Oct 4, 2012 at 8:57 PM, Daniel Isenmann wrote:

...

feel free to do the above packages. I'm totally busy with my real life right now and don't have time to do it at the moment.

Put them both (mono+xsp) in testing. Could you (or anyone else who use them) let me know if they are ok to go to extra? Cheers, Tom

Giorgio Lando

6 Oct 6 Oct

1:16 p.m.

If the developer is interested, I have a working unit for the atd daemon in the at package. Let me know Giorgio

Giorgio Lando

1:19 p.m.

2012/10/6 Giorgio Lando :

...

If the developer is interested, I have a working unit for the atd daemon in the at package. Let me know Giorgio

As not said, the unit has been added in the version of at I received some seconds ago :)

Tobias Powalowski

7 Oct 7 Oct

10:10 a.m.

Am 04.10.2012 20:16, schrieb Tom Gundersen:
> 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
Hi Tom,
- kexec  is probably impossible to add a service file.
We discussed this on IRC some time ago, it's not possible to detect
which kernel should be loaded on shutdown in a clean way.

If you have the time i would be happy if you would look at
- usermin should be the same as webmin
- hpoj I don't have the hardware anymore
- vde2

Thanks
greetings
tpowa

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

Tom Gundersen

1:24 p.m.

On Oct 7, 2012 9:10 AM, "Tobias Powalowski" < tobias.powalowski@googlemail.com> wrote:

...

- hpoj I don't have the hardware anymore

Maybe this should be dropped then? T

4226

Age (days ago)

4243

Last active (days ago)

List overview

Download

22 comments

10 participants

participants (10)

Daniel Isenmann
Dave Reisner
David J. Haines
Giorgio Lando
Kyle
Matthew Monaco
Stefan Wilkens
Taylor Lookabaugh
Tobias Powalowski
Tom Gundersen