cyrus-imapd missing in Leap 15.3 RC
Hi all, I just upgraded one of my server-boxes from leap 15.2 to 15.3 RC I noticed that cyrus-imapd was missing, as well as some other related packages: cyrus-imapd cyradm perl-Cyrus-IMAP perl-Cyrus-SIEVE-managesieve I found those in server:mail repo, so it's not a big deal. However, still unexpected, as I would have assumed these pretty much standard packages to be included. Is this intentional, or were they just not built yet for some reason? Just for the record: apart from that, zypper dup from Leap 15.2 to 15.3 RC was working flawlessly (as usual). Congratulations for the good work & thanks a lot for all you r efforts!!
On 13/05/2021 20.58, B. Randolf wrote:
Hi all,
I just upgraded one of my server-boxes from leap 15.2 to 15.3 RC I noticed that cyrus-imapd was missing, as well as some other related packages:
cyrus-imapd
https://build.opensuse.org/request/show/742758 says it was dropped 2019-11-04 because it failed to build. The current Tumbleweed build does not start because
nothing provides insserv
seems somewhat related to the switch to systemd: http://bugzilla.suse.com/show_bug.cgi?id=1115999
On 13.05.2021 22:46, Bernhard M. Wiedemann wrote:
The current Tumbleweed build does not start because
nothing provides insserv
seems somewhat related to the switch to systemd: http://bugzilla.suse.com/show_bug.cgi?id=1115999
Yes, insserv was deleted (https://build.opensuse.org/request/show/870278) because "All consumers of insserv-compat in Factory have been modified so they do not rely on this package anymore). Amusing is that systemd *itself* depends on insserv/chkconfig in its script /usr/lib/systemd/systemd-sysv-install https://forums.opensuse.org/showthread.php/553507-chkconfig-command-is-gone
Am Freitag, 14. Mai 2021, 06:56:34 CEST schrieb Andrei Borzenkov:
On 13.05.2021 22:46, Bernhard M. Wiedemann wrote:
The current Tumbleweed build does not start because
nothing provides insserv
seems somewhat related to the switch to systemd: http://bugzilla.suse.com/show_bug.cgi?id=1115999
Yes, insserv was deleted (https://build.opensuse.org/request/show/870278) because "All consumers of insserv-compat in Factory have been modified so they do not rely on this package anymore). Amusing is that systemd *itself* depends on insserv/chkconfig in its script /usr/lib/systemd/systemd-sysv-install
https://forums.opensuse.org/showthread.php/553507-chkconfig-command-is-gone
Thank you for explaining! just another thought on that: If I got this right, this means that cyrus is no longer available/supported at least starting with Leap 15.3. Wouldn't it be necessary to include an appropriate warning or at least a hint in the release notes? Furthermore, which is the recommended imaps/pop3s implementation on Leap then? Although I'm temporarily fine with using cyrus from the server:mail-repo, I'd still prefer to switch to whatever is the recommended default on Leap in the long run...
On Fri, May 14, B. Randolf wrote:
Furthermore, which is the recommended imaps/pop3s implementation on Leap then? Although I'm temporarily fine with using cyrus from the server:mail-repo, I'd still prefer to switch to whatever is the recommended default on Leap in the long run...
I switched to dovecot some time ago and all imap related issues I saw with cyrus were gone... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Am Donnerstag, 13. Mai 2021, 21:46:46 CEST schrieb Bernhard M. Wiedemann:
On 13/05/2021 20.58, B. Randolf wrote:
Hi all,
I just upgraded one of my server-boxes from leap 15.2 to 15.3 RC I noticed that cyrus-imapd was missing, as well as some other related packages:
cyrus-imapd
https://build.opensuse.org/request/show/742758 says it was dropped 2019-11-04 because it failed to build.
The current Tumbleweed build does not start because
nothing provides insserv
seems somewhat related to the switch to systemd: http://bugzilla.suse.com/show_bug.cgi?id=1115999
Cyrus has been running with me for about> 15 years. How do you switch from cyrus to dovecote? Almost always works? What effort is required? And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there? It's not just some small, let's say unimportant program, but rather a large, important package? For me, Cyrus definitely belongs in a distribution. Regardless of whether any guidelines have been violated. Can't be that due to systemd such an important heavyweight is no longer there. Regards Eric
On Fri, May 14, Eric Schirra wrote:
And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
Maybe they have maintainers who care about the package?
It's not just some small, let's say unimportant program, but rather a large, important package?
If nobody from the openSUSE community takes care, it doesn't matter if it is a large important or a small unimportant package. And that nobody takes care means, it cannot be an important package. Else there would be somebody who cares.
Can't be that due to systemd such an important heavyweight is no longer there.
It's not because of systemd, it's because nobody cares. Don't blame the wrong thing. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Am Freitag, 14. Mai 2021, 10:58:50 CEST schrieb Thorsten Kukuk:
On Fri, May 14, Eric Schirra wrote:
And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
Maybe they have maintainers who care about the package?
It's not just some small, let's say unimportant program, but rather a large, important package?
If nobody from the openSUSE community takes care, it doesn't matter if it is a large important or a small unimportant package. And that nobody takes care means, it cannot be an important package. Else there would be somebody who cares.
I understand what you mean. But there is something wrong with openSUSE / SUSE. At some point you won't find a maintainer for apache. Then this is also no longer an important package? Sorry I do not understand this approach and, in my opinion, it is the completely wrong way and, especially if it continues like this, it will mean the downfall of openSUSE / SUSE. Because if important packages like cyrus or, hypotetically speaking, Apache are missing, nobody needs or wants them. How does SUSE make this clear to its enterprise customers? "Sorry, the community no longer has a maintainer, so no cyrus and apache, you just have to take something else". Then at the latest I would switch as a paying customer. Regards Eric
Citeren Eric Schirra
Am Freitag, 14. Mai 2021, 10:58:50 CEST schrieb Thorsten Kukuk:
On Fri, May 14, Eric Schirra wrote:
And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
Maybe they have maintainers who care about the package?
It's not just some small, let's say unimportant program, but rather a large, important package?
If nobody from the openSUSE community takes care, it doesn't matter if it is a large important or a small unimportant package. And that nobody takes care means, it cannot be an important package. Else there would be somebody who cares.
I understand what you mean. But there is something wrong with openSUSE / SUSE. At some point you won't find a maintainer for apache. Then this is also no longer an important package?
By that same reasoning, indeed. And I see no problem with that. In the hypothetical case that nobody wants to maintain Apache anymore, this either means there is something better that replaces it, or nobody wants to run webservers anymore. Packages come and go.
Sorry I do not understand this approach and, in my opinion, it is the completely wrong way and, especially if it continues like this, it will mean the downfall of openSUSE / SUSE.
It would be the downfall to keep spending time on packages that lack sufficient interest from the community to maintain them.
Because if important packages like cyrus or, hypotetically speaking, Apache are missing, nobody needs or wants them.
Apparently, Cyrus is important to you, but not enough to maintain it. Why do you expect someone else to maintain it for you for free?
How does SUSE make this clear to its enterprise customers? "Sorry, the community no longer has a maintainer, so no cyrus and apache, you just have to take something else". Then at the latest I would switch as a paying customer.
I assume that as long as there are paying customers, packages would be maintained independent from the community. So probably this isn't a package backed/needed by paying customers.
On Friday 2021-05-14 11:26, Eric Schirra wrote:
And why is [cyrus-imapd] still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
If nobody from the openSUSE community takes care, it doesn't matter if it is a large important or a small unimportant package. And that nobody takes care means, it cannot be an important package. Else there would be somebody who cares.
I understand what you mean. But there is something wrong with openSUSE / SUSE. At some point you won't find a maintainer for apache. Then this is also no longer an important package?
Precisely. important | ^ | | v | maintained If apache, in some future, declines in importance because virtually all users have moved to nginx or whatever, then the maintainers will eventually drop off too sooner or later. Conversely, if maintainers have dropped off, that means the effort was disproportionate to its business importance.
How does SUSE make this clear to its enterprise customers? "Sorry, the community no longer has a maintainer, so no cyrus and apache, you just have to take something else".
Iff there is a business value in cyrus, SUSE will provide a maintainer. Conversely, if there is no force-assigned maintainer, there is no business value in it for SUSE.
On Fri, May 14, Eric Schirra wrote:
But there is something wrong with openSUSE / SUSE.
Important: openSUSE != SUSE
At some point you won't find a maintainer for apache. Then this is also no longer an important package?
Yes. cyrus-impad is no important package for SUSE, SUSE does not even ship it. There is no customer interested in, they are using dovecot, which we ship. If nobody is using apache anymore, but e.g. everybody is using nginx or another new webserver, SUSE will also stop maintaining apache. And if there is nobody in the openSUSE community, who is interested in apache, because 99% are using the new web server, too, it will be dropped.
Sorry I do not understand this approach and, in my opinion, it is the completely wrong way and, especially if it continues like this, it will mean the downfall of openSUSE / SUSE.
Why should SUSE pay people to maintain a package for openSUSE, which SUSE and their customers don't need and where the openSUSE community has no interest in, only for you?
Because if important packages like cyrus or, hypotetically speaking, Apache are missing, nobody needs or wants them. How does SUSE make this clear to its enterprise customers?
Since the enterprise customers are using dovecot and not cyrus, they didn't care.
"Sorry, the community no longer has a maintainer, so no cyrus and apache, you just have to take something else". Then at the latest I would switch as a paying customer.
If you would be a pying customer, SUSE would earn money with which they could pay somebody to maintain this packages. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Am Freitag, 14. Mai 2021, 10:58:50 CEST schrieb Thorsten Kukuk:
On Fri, May 14, Eric Schirra wrote:
And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
Maybe they have maintainers who care about the package?
For such an important package? The problem is incidentally because of the macro Requires (pre):% insserv_prereq in this section of the spec: % if% {with systemd} BuildRequires: systemd Requires (pre):% fillup_prereq % systemd_requires % else Recommends: cron Requires (pre):% insserv_prereq % endif Although "with systemd" is queried here, and from a logical point of view systemd "Requires (pre):% insserv_prereq" should not be evaluated, it will. The build requires insserv and breaks off on Tumbleweed. Either you throw the insserv completely out of the spec or you fix the error that Requires is correctly evaluated in an if loop. Regards Eric
On Fri, May 14, Eric Schirra wrote:
Am Freitag, 14. Mai 2021, 10:58:50 CEST schrieb Thorsten Kukuk:
On Fri, May 14, Eric Schirra wrote:
And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
Maybe they have maintainers who care about the package?
For such an important package?
Looks like it's only important for you, so why do you not step up and fix the package?
The problem is incidentally because of the macro Requires (pre):% insserv_prereq
in this section of the spec:
% if% {with systemd} BuildRequires: systemd Requires (pre):% fillup_prereq % systemd_requires % else Recommends: cron Requires (pre):% insserv_prereq % endif
Although "with systemd" is queried here, and from a logical point of view systemd "Requires (pre):% insserv_prereq" should not be evaluated, it will. The build requires insserv and breaks off on Tumbleweed.
Either you throw the insserv completely out of the spec or you fix the error that Requires is correctly evaluated in an if loop.
Who is "you"? It's clearly not me. I think you should have written "me", becuase either you spent the time and fix it yourself, or nobody will do it for you. That's how open source and communities work. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Am Freitag, 14. Mai 2021, 11:55:45 CEST schrieb Thorsten Kukuk:
On Fri, May 14, Eric Schirra wrote:
Am Freitag, 14. Mai 2021, 10:58:50 CEST schrieb Thorsten Kukuk:
On Fri, May 14, Eric Schirra wrote:
And why is it still offered by many other distributions like Arch, Debian, Ubuntu, Fedora, Centos, Mageia? Why can it still be built and installed there?
Maybe they have maintainers who care about the package?
For such an important package?
Looks like it's only important for you, so why do you not step up and fix the package?
The problem is incidentally because of the macro
Requires (pre):% insserv_prereq
in this section of the spec:
% if% {with systemd} BuildRequires: systemd Requires (pre):% fillup_prereq % systemd_requires % else Recommends: cron Requires (pre):% insserv_prereq % endif
Although "with systemd" is queried here, and from a logical point of view systemd "Requires (pre):% insserv_prereq" should not be evaluated, it will. The build requires insserv and breaks off on Tumbleweed.
Either you throw the insserv completely out of the spec or you fix the error that Requires is correctly evaluated in an if loop.
Who is "you"? It's clearly not me. I think you should have written "me", becuase either you spent the time and fix it yourself, or nobody will do it for you. That's how open source and communities work.
With "you" I mean suse or the one who is responsible for the macros / the build service / the parsing of the spec file. That was probably a translation mistake. In my opinion the spec file is correct, but the evaluation of the macros in an if loop has an error. And why only me? The main question was not from me. So minimum two persons want cyrus. And I think a lot of others just don't even know. But the answers show me again and more and more recently, the ignorance or this dismissal and discussion of problems. What's going on at suse? Sad sad. Regards Eric
On Fri, 2021-05-14 at 12:16 +0200, Eric Schirra wrote:
With "you" I mean suse or the one who is responsible for the macros / the build service / the parsing of the spec file. That was probably a translation mistake. In my opinion the spec file is correct, but the evaluation of the macros in an if loop has an error.
Please stop intermingling openSUSE / SUSE. openSUSE, the distribution you are using, is a community distribution. SUSE as a company is helping to maintain part of the packages / toolchains, based on their needs for their enterprise products. But we cannot ask from a company, that uses our distro as a base, to contribyte to packages they have no customer base for. So, 'you' as in 'SUSE' makes no sense. If they would have a customer willing to pay for the feature you ask, they would dedicate resources for it.
And why only me? The main question was not from me. So minimum two persons want cyrus. And I think a lot of others just don't even know.
Rally up people to fix the package - can be you, or other people interested in the package. But don't 'ask' any random person to fix something they do not use or care for.
But the answers show me again and more and more recently, the ignorance or this dismissal and discussion of problems. What's going on at suse? Sad sad.
To look at the problem in the spec file in server:mail %if %{defined systemd_requires} %global with_systemd 1 %endif %bcond_with systemd … %if %{with systemd} BuildRequires: systemd Requires(pre): %fillup_prereq %systemd_requires This is wrong and probably misunderstood by the packager in first place: %if %{defined systemd_requires} => this is unusable in the light of the scheduler: no package is yet installed, hence nothing defines systemd_requires (would come from the package systemd-rpm-macros), thus the %global definition won't happen in the scheduler. %bcond_with means: by default, build without, except if specified otherwise (e.g. osc build --with=systemd; obviously not done by OBS) It's never specified otherwise - hence: build without systemd (in 2021, where basically every supported distro uses systemd, I'd rather change this to bcond_withou, make the default WITH systemd, and make the others exceptions) To make things fun, though: %if %{defined systemd_requires} is true in the context of the actual build: the setup worker VM has systemd-macros installed (and systemd-mini, as other packages pull it in), and thus installs the correct files, and the dep generator in the end also has it defined. Hope this helps to get somebody started to actually do the fixing now. cheers, Dominique
On Friday 2021-05-14 12:41, Dominique Leuenberger / DimStar wrote:
%if %{defined systemd_requires} %global with_systemd 1 %endif %bcond_with systemd … %if %{with systemd} BuildRequires: systemd Requires(pre): %fillup_prereq %systemd_requires
Hope this helps to get somebody started to actually do the fixing now.
893071
Am Freitag, 14. Mai 2021, 12:41:58 CEST schrieb Dominique Leuenberger / DimStar:
On Fri, 2021-05-14 at 12:16 +0200, Eric Schirra wrote:
With "you" I mean suse or the one who is responsible for the macros / the build service / the parsing of the spec file. That was probably a translation mistake. In my opinion the spec file is correct, but the evaluation of the macros in an if loop has an error.
Please stop intermingling openSUSE / SUSE. openSUSE, the distribution you are using, is a community distribution. SUSE as a company is helping to maintain part of the packages / toolchains, based on their needs for their enterprise products.
I don't think it's that easy to look at. The interlinking, dependency and specifications of suse and openSUSE are considerable. If you notice, for example, that Leap sometimes contains ancient versions of packages, with the note that they are contained in sles. Or that you don't get a new version of a package in Leap, with the hint that it should be so in the first place.
But we cannot ask from a company, that uses our distro as a base, to contribyte to packages they have no customer base for. So, 'you' as in 'SUSE' makes no sense. If they would have a customer willing to pay for the feature you ask, they would dedicate resources for it.
I just think they don't know that it won't be in future versions.
And why only me? The main question was not from me. So minimum two persons want cyrus. And I think a lot of others just don't even know.
Rally up people to fix the package - can be you, or other people interested in the package. But don't 'ask' any random person to fix something they do not use or care for.
So i have now done a request in server:mail. Please accept it. Not all users have the knowledge to do this. And again. You don't even know that this package will no longer exist but Leap 15.3. By the way. A few hours after I temporarily fixed the package in my home repo, I received a thank you. Then there was a comment here in the thread and confirm my opinion. This means that within a very short time there are already 4 users using cyrus. How much will there be when you first realize that cyrus is no longer there?
To look at the problem in the spec file in server:mail
%if %{defined systemd_requires} %global with_systemd 1 %endif %bcond_with systemd … %if %{with systemd} BuildRequires: systemd Requires(pre): %fillup_prereq %systemd_requires
This is wrong and probably misunderstood by the packager in first place:
%if %{defined systemd_requires} => this is unusable in the light of the scheduler: no package is yet installed, hence nothing defines systemd_requires (would come from the package systemd-rpm-macros), thus the %global definition won't happen in the scheduler.
%bcond_with means: by default, build without, except if specified otherwise (e.g. osc build --with=systemd; obviously not done by OBS)
It's never specified otherwise - hence: build without systemd (in 2021, where basically every supported distro uses systemd, I'd rather change this to bcond_withou, make the default WITH systemd, and make the others exceptions)
To make things fun, though: %if %{defined systemd_requires} is true in the context of the actual build: the setup worker VM has systemd-macros installed (and systemd-mini, as other packages pull it in), and thus installs the correct files, and the dep generator in the end also has it defined.
Hope this helps to get somebody started to actually do the fixing now.
Thanks for the explanation. But I'm at war with the bcond. It's totally illogical to me. That's why I never use it and have now solved it differently. A request has been created and I ask for approval. Regards Eric
On 14/05/2021 12.16, Eric Schirra wrote:
Am Freitag, 14. Mai 2021, 11:55:45 CEST schrieb Thorsten Kukuk:
...
With "you" I mean suse or the one who is responsible for the macros / the build service / the parsing of the spec file. That was probably a translation mistake. In my opinion the spec file is correct, but the evaluation of the macros in an if loop has an error.
But it is not a problem to maintain the package on another repo.
And why only me? The main question was not from me. So minimum two persons want cyrus. And I think a lot of others just don't even know.
You are probably right, more people will be surprised when they upgrade. Some with production servers.
But the answers show me again and more and more recently, the ignorance or this dismissal and discussion of problems. What's going on at suse? Sad sad.
Regards Eric
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am Freitag, 14. Mai 2021, 12:43:31 CEST schrieb Carlos E. R.:
On 14/05/2021 12.16, Eric Schirra wrote:
Am Freitag, 14. Mai 2021, 11:55:45 CEST schrieb Thorsten Kukuk: ...
With "you" I mean suse or the one who is responsible for the macros / the build service / the parsing of the spec file. That was probably a translation mistake. In my opinion the spec file is correct, but the evaluation of the macros in an if loop has an error.
But it is not a problem to maintain the package on another repo.
Have done now an request in server:mail. When accepted i will see try to bring it in leap. But unfortunately I don't have much hope. My last experiences show that. So, we just have to use the repo server: mail.
And why only me? The main question was not from me. So minimum two persons want cyrus. And I think a lot of others just don't even know.
You are probably right, more people will be surprised when they upgrade. Some with production servers.
Locked me in If I hadn't read the post here, I would have fallen on my nose. And I think there will be many more users after an upgrade, because very few are reading along here. Regards Eric
Although "with systemd" is queried here, and from a logical point of view systemd "Requires (pre):% insserv_prereq" should not be evaluated, it will. The build requires insserv and breaks off on Tumbleweed.
Either you throw the insserv completely out of the spec or you fix the error that Requires is correctly evaluated in an if loop.
Looks more like the bcond and evaluation of %{with systemd} is wrong. Both the server side build service as well as rpmbuild need to understand if you want to build "with systemd" or not. This block from the specfile does not look right to me: %if %{defined systemd_requires} %global with_systemd 1 %endif %bcond_with systemd BTW, if branches are not loops. Do you really need to support builds without systemd nowadays? But, even if you decide to fix it: Running a mail server with a software package maintained by one or two random people, who only marginally care, is not a good idea. I made this experience the hard way: Ubuntu ships a lot of packages, which it inherits from Debian, but does not care for updates in supposedly still maintained distros. The roundcube packages in 18.04 LTS and 20.04 LTS are grossly outdated, exhibit security vulnerabilities and there are no maintainers who care. They even have open bugs about it in their tracker and still don't care (e.g. lp#1891866). Clearly the better option is to remove packages from distros if they are not maintained anymore. - Ben
On 5/14/21 4:03 AM, Ben Greiner wrote:
But, even if you decide to fix it: Running a mail server with a software package maintained by one or two random people, who only marginally care, is not a good idea.
How does this issue affect cyrus-sasl? If we're loosing sasl I'm going to have to start scrambling now for an alternative for subversion session encryption. We can't use apache for a number of reasons. Regards, Lew
On Fri, May 14, 2021 at 09:06:55AM -0700, Lew Wolfgang wrote:
On 5/14/21 4:03 AM, Ben Greiner wrote:
But, even if you decide to fix it: Running a mail server with a software package maintained by one or two random people, who only marginally care, is not a good idea.
How does this issue affect cyrus-sasl? If we're loosing sasl I'm going to have to start scrambling now for an alternative for subversion session encryption. We can't use apache for a number of reasons.
No, different program. cyrus-sasl is also definitely in use for SASL things, both in SLES and openSUSE. Ciao, Marcus
participants (12)
-
Andrei Borzenkov -
Arjen de Korte -
B. Randolf -
Ben Greiner -
Bernhard M. Wiedemann -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Eric Schirra -
Jan Engelhardt -
Lew Wolfgang -
Marcus Meissner -
Thorsten Kukuk