Am 2016-03-04 um 20:51 schrieb Robert Schetterer:

Am 04.03.2016 um 19:15 schrieb Peter Chiochetti:

...

Since dovecot put up packages on their own repo, bigmichi stopped providing his'. I guess this is not Stephan; Would the kind person update ppa.launchpad.net/bigmichi1 ?

Thank You

what wrong with

http://wiki.dovecot.org/PrebuiltBinaries#Automatically_Built_Packages

builds fine on ubuntu 14.04

Dear Robert, I tried a deb-package of those once (Jan 2014), but it badly messed with upstart files in /etc, which is not the same in ubuntu and debian

-- peter

Am 2016-03-04 um 21:03 schrieb Stephan Bosch:

Op 3/4/2016 om 7:15 PM schreef Peter Chiochetti:

...

Since dovecot put up packages on their own repo, bigmichi stopped providing his'. I guess this is not Stephan; Would the kind person update ppa.launchpad.net/bigmichi1 ?

The Xi packages are built for Ubuntu here:

https://build.opensuse.org/project/repositories/home:sbosch:dovecot-2.2

Dear Stephan, in Ubuntu (12.04 here) /etc/init.d/dovecot is symlinked to /lib/init/upstart-job - but its in your package too, so installing your package might damage the upstart job. I remember having seen this (in 2014).

-- peter

On March 4, 2016 at 10:38 PM Stephan Bosch stephan@rename-it.nl wrote:

Op 3/4/2016 om 9:18 PM schreef Peter Chiochetti:

...

Am 2016-03-04 um 21:03 schrieb Stephan Bosch:

...

Op 3/4/2016 om 7:15 PM schreef Peter Chiochetti:

...

Since dovecot put up packages on their own repo, bigmichi stopped providing his'. I guess this is not Stephan; Would the kind person update ppa.launchpad.net/bigmichi1 ?

The Xi packages are built for Ubuntu here:

https://build.opensuse.org/project/repositories/home:sbosch:dovecot-2.2

Dear Stephan, in Ubuntu (12.04 here) /etc/init.d/dovecot is symlinked to /lib/init/upstart-job - but its in your package too, so installing your package might damage the upstart job. I remember having seen this (in 2014).

Then why doesn't anyone ever tell me? :)

I'll give that a look at the next Xi revision, which will happen quite soon.

Regards,

Stephan.

Stephan, for Jessie you should compile with systemd support enabled and leave the init.d link out completely. You can enable the ProtectFull=yes in the systemd file.

Aki Tuomi Dovecot Oy

On 6/03/2016 8:16 PM, aki.tuomi@dovecot.fi wrote:

Stephan, for Jessie you should compile with systemd support enabled and leave the init.d link out completely. You can enable the ProtectFull=yes in the systemd file.

Many of us Debian users hate the fact that systemd even exists..... for now we can run servers without systemd, but who knows in a few years or a couple of releases.

systemd is a cancer, that's been said before and it will be long time, if ever, before it is not said regularly.

Cheers A.

aki.tuomi@dovecot.fi wrote:

Yet, it would be good idea to enable systemd support for those who use systemd, despite being considered as cancerous by some people, with the same justification that some want to use systemd. Retaining the init.d script does pose some problems, mainly because it seems to interfere with systemctl enable command which gets confused.

It does? How?

If your unit and the init-script are named the same, everything should work as expected.

Grüße, Sven.

-- Sigmentation fault. Core dumped.

On Mon, 7 Mar 2016 04:22:44 +1100 Andrew McGlashan andrew.mcglashan@affinityvision.com.au wrote:

On 6/03/2016 8:16 PM, aki.tuomi@dovecot.fi wrote:

...

Stephan, for Jessie you should compile with systemd support enabled and leave the init.d link out completely. You can enable the ProtectFull=yes in the systemd file.

Many of us Debian users hate the fact that systemd even exists..... for now we can run servers without systemd, but who knows in a few years or a couple of releases.

systemd is a cancer, that's been said before and it will be long time, if ever, before it is not said regularly.

Cheers A.

Hi Andrew,

See this thread:

http://www.dovecot.org/list/dovecot/2016-February/103277.html

The systemd dependencies are pretty much just cosmetic: Inclusion of a unit file, and (maybe) that special way of reporting back to systemd when the daemon is listening and fully functional, which AFAIK doesn't affect Dovecot's functionality when used in a sans-systemd environment. Much as I like Dovecot, I'll blow it off my machine in a microsecond if it ever stops functioning in the absence of systemd, and from the thread I mentioned, I doubt that will ever happen.

One other thing: Later in this thread it's suggested that a distro (Debian) remove Dovecot's sysvinit init script. Although this sounds like a showstopper, it's really an opportunity. You can simply respawn Runit (or daemontools-encore or S6 or any other daemontools-inspired process supervisor) from /etc/inittab, and start Dovecot from there. The following is my huge, immense Runit run script for Dovecot:

=================================================== #!/bin/sh install -d -m 0755 -o root -g root /var/run/dovecot exec dovecot -F

So even though Debian might eliminate the init script, there's a very nice way forward, and once you get Runit running, you can begin slowly switching all your massive sysvinit init scripts with 5 line Runit run scripts.

And of course, you could switch to Devuan. Or do what I do: Run Void Linux, which ships with Runit actually performing PID1 init duties as well as process supervision.

SteveT

Steve Litt March 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz

On 03/07/2016 01:28 AM, Jaldhar H. Vyas wrote:

On Mon, 7 Mar 2016, Andrew McGlashan wrote:

...

Many of us Debian users hate the fact that systemd even exists..... for now we can run servers without systemd, but who knows in a few years or a couple of releases.

I can't speak for the project as a whole but you'll take my sysvinit when you pry it from my cold dead hands :-)

Please keep it that way!! I use sysvinit on all machines - desktop, laptop, server, except where broken non-official packages (e.g. graylog) support only systemd. I find systemd a horrendous little toy that sometimes behaves in outright silly ways. A Rube Goldberg machine is, by definition, something that never will go into production.

On 06/03/2016 04:18, Robert Schetterer wrote:

for paranoid people, create you own repo and for info dovecot had nice compiled from scratch to me in the past too

The only way to use dovecot IMHO is by source, you build in what you want and omit the junk (that some repo packagers want to include - because they need cater for many scenarios) that you have no need for, sadly though, dovecot has lapsed a bit in security in this respect since we used to be able to disable all non-wanted password types, but now we have many of them non configurable and get them built in whether we like it or not, its one of two gripes I've had with dovecot 2.x, otherwise, reasonable happy with it now days.

-- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/