Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is present in the version, it is quite stable, and fixes many problems that there are in 0.99.14. As a matter of fact, there is no upstream support for 0.99.x. Any reports are met with 'please upgrade and your problem will likely be over'.
Take bugs 163550 and 173928 - you can probably just close them after this move :-)
I built my own rpm for alpha4, and have it working quite well on FC5test1.
Thanks, Willem Riede.
Willem Riede wrote:
Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is present in the version, it is quite stable, and fixes many problems that there are in 0.99.14. As a matter of fact, there is no upstream support for 0.99.x. Any reports are met with 'please upgrade and your problem will likely be over'.
Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot from courier-imap without anyone noticing the difference.
The feature I'm missing in 0.99 is namespaces. Without this, I'd have to reconfigure all the MUAs to change their IMAP prefix from "INBOX" to "" (empty string).
On 5/12/2005 1:18 p.m., Bernardo Innocenti wrote:
Willem Riede wrote:
Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is present in the version, it is quite stable, and fixes many problems that there are in 0.99.14. As a matter of fact, there is no upstream support for 0.99.x. Any reports are met with 'please upgrade and your problem will likely be over'.
Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot from courier-imap without anyone noticing the difference.
The feature I'm missing in 0.99 is namespaces. Without this, I'd have to reconfigure all the MUAs to change their IMAP prefix from "INBOX" to "" (empty string).
I would like to add my +1 to this as well. Dovecot-0.99.x is arguably just as bad if not more 'alpha' than the upcoming 1.0 releases both in terms of bugs and of features and it seems most odd to be shipping a package that isn't supported by the upstream developer and community. I would also put the case that 0.99.x was more 'alpha' in it's quality than the current releases that are actually labelled as 'alpha'.
Anyway, there is a bugzilla entry open as an RFE for it:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960
Perhaps that might be a good place to start adding comments, maybe if enough people ask nicely in there and show support, it might happen from within RH ;-)
From memory last time I needed to there was very little work required to repackage the 1.0 tarballs using the existing 0.99.x spec file. The RFE above additionally talks about dovecot-lda being made available as a separate package, but I think at this stage it is secondary to actually getting the primary package updated in the distribution. Perhaps the lda component could start off in extras :)
I'm sure that if all that is missing for it to happen is someone to do some specfile hacking, someone in the community will step up to the mark (and I'll go digging throught the stuff I did to see how I last did it if I need to).
reuben
On 12/06/2005 07:21:28 AM, Reuben Farrelly wrote:
On 5/12/2005 1:18 p.m., Bernardo Innocenti wrote:
Willem Riede wrote:
Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is present in the version, it is quite stable, and fixes many problems that there are in 0.99.14. As a matter of fact, there is no upstream support for 0.99.x. Any reports are met with 'please upgrade and your problem will likely be over'.
Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot from courier-imap without anyone noticing the difference.
The feature I'm missing in 0.99 is namespaces. Without this, I'd have to reconfigure all the MUAs to change their IMAP prefix from "INBOX" to "" (empty string).
I would like to add my +1 to this as well. Dovecot-0.99.x is arguably just as bad if not more 'alpha' than the upcoming 1.0 releases both in terms of bugs and of features and it seems most odd to be shipping a package that isn't supported by the upstream developer and community. I would also put the case that 0.99.x was more 'alpha' in it's quality than the current releases that are actually labelled as 'alpha'.
Anyway, there is a bugzilla entry open as an RFE for it:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960
Perhaps that might be a good place to start adding comments, maybe if enough people ask nicely in there and show support, it might happen from within RH ;-)
I have added the 1.0-alpha4 spec file and the patches I successfully used myself to run dovecot-1.0-alpha4 on fc5t1 to that bugzilla, so I hope somebody makes use of those and upgrades dovecot in devel - please? pretty please? :-)
Thanks, Willem Riede.
Hi,
[Following up on an older thread]
On 7/12/2005 3:59 p.m., Willem Riede wrote:
On 12/06/2005 07:21:28 AM, Reuben Farrelly wrote:
On 5/12/2005 1:18 p.m., Bernardo Innocenti wrote:
Willem Riede wrote:
Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is present in the version, it is quite stable, and fixes many problems that there are in 0.99.14. As a matter of fact, there is no upstream support for 0.99.x. Any reports are met with 'please upgrade and your problem will likely be over'.
Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot from courier-imap without anyone noticing the difference.
The feature I'm missing in 0.99 is namespaces. Without this, I'd have to reconfigure all the MUAs to change their IMAP prefix from "INBOX" to "" (empty string).
I would like to add my +1 to this as well. Dovecot-0.99.x is arguably just as bad if not more 'alpha' than the upcoming 1.0 releases both in terms of bugs and of features and it seems most odd to be shipping a package that isn't supported by the upstream developer and community. I would also put the case that 0.99.x was more 'alpha' in it's quality than the current releases that are actually labelled as 'alpha'.
Anyway, there is a bugzilla entry open as an RFE for it:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960
Perhaps that might be a good place to start adding comments, maybe if enough people ask nicely in there and show support, it might happen from within RH ;-)
I have added the 1.0-alpha4 spec file and the patches I successfully used myself to run dovecot-1.0-alpha4 on fc5t1 to that bugzilla, so I hope somebody makes use of those and upgrades dovecot in devel - please? pretty please? :-)
Re: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960
dovecot-1.0-beta1 is now out and there is soon going to be a bounty paid by the author to the first person who finds a remotely exploitable bug (if one such one exists). See http://dovecot.org/security.html. That surely suggests that the author feels that his "beta" code is of reputable quality and surely good enough to replace the current and very outdated "alpha" 0.99 package we have in core that is no longer supported upstream.
Can someone from Redhat perhaps comment a bit more - if there is a reason for why it hasn't been upgraded please tell us, and who is actually now maintaining it? Thanks to Willem Riede who has done the hard work and come up with an updated specfile + patches and posted them in bugzilla, so you'd expect the upgrade to be relatively little work for whoever takes it on.
I'm thinking of a comment in bugzilla from John Dennis where he states "I'm being transitioned to other responsibilities and package ownership of dovecot is transferring at the same time. The new (yet to be determined) package maintainer for dovecot will need to pick up the ball on this issue.". So far no-one has picked up any ball, so who actually is the new maintainer?
I'm asking because there have been no real responses from Redhat to date as to what's going on, and there are constantly reports of users installing the old FC/RHEL RPM's on the dovecot list and being told to install the newer version because the version shipped in FC/RHEL is too old and not supported........
Thanks, Reuben
Reuben Farrelly wrote:
I'm thinking of a comment in bugzilla from John Dennis where he states "I'm being transitioned to other responsibilities and package ownership of dovecot is transferring at the same time. The new (yet to be determined) package maintainer for dovecot will need to pick up the ball on this issue.". So far no-one has picked up any ball, so who actually is the new maintainer?
On a somehow related topic squirrelmail needs some maintainer love too
Regards,
Nicolas Mailhot wrote:
Reuben Farrelly wrote:
I'm thinking of a comment in bugzilla from John Dennis where he states "I'm being transitioned to other responsibilities and package ownership of dovecot is transferring at the same time. The new (yet to be determined) package maintainer for dovecot will need to pick up the ball on this issue.". So far no-one has picked up any ball, so who actually is the new maintainer?
On a somehow related topic squirrelmail needs some maintainer love too
Post a separate thread on squirrelmail with the relevant bug reports if any.
Rahul Sundaram wrote:
Nicolas Mailhot wrote:
Reuben Farrelly wrote:
I'm thinking of a comment in bugzilla from John Dennis where he states "I'm being transitioned to other responsibilities and package ownership of dovecot is transferring at the same time. The new (yet to be determined) package maintainer for dovecot will need to pick up the ball on this issue.". So far no-one has picked up any ball, so who actually is the new maintainer?
On a somehow related topic squirrelmail needs some maintainer love too
Post a separate thread on squirrelmail with the relevant bug reports if any.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162852
has been waiting for some maintainer action for two months and a half
The report points some easy fixes :
-Requires: httpd, php >= 4.0.4, perl, tmpwatch >= 2.8, aspell +Requires: httpd, php >= 4.0.4, php-mbstring, perl, tmpwatch >= 2.8, aspell
-find -name '*.mo' |xargs rm +#find -name '*.mo' |xargs rm
Nicolas Mailhot wrote:
has been waiting for some maintainer action for two months and a half
The report points some easy fixes :
-Requires: httpd, php >= 4.0.4, perl, tmpwatch >= 2.8, aspell +Requires: httpd, php >= 4.0.4, php-mbstring, perl, tmpwatch >= 2.8, aspell
-find -name '*.mo' |xargs rm +#find -name '*.mo' |xargs rm
Too bad it's not in extras, since I'm the upstream packager for squirrelmail. :)
On Mon, Jan 16, 2006 at 05:28:59PM -0500, Konstantin Ryabitsev wrote:
Nicolas Mailhot wrote:
has been waiting for some maintainer action for two months and a half
The report points some easy fixes :
-Requires: httpd, php >= 4.0.4, perl, tmpwatch >= 2.8, aspell +Requires: httpd, php >= 4.0.4, php-mbstring, perl, tmpwatch >= 2.8, aspell
-find -name '*.mo' |xargs rm +#find -name '*.mo' |xargs rm
Too bad it's not in extras, since I'm the upstream packager for squirrelmail. :)
Does anything in Core require squirrelmail? If not, sounds like the perfect opportunity to move it to Extras.
If a package is unmaintained in Core, and there is a willing maintainer, then it should be moved to Extras.
devel@lists.stg.fedoraproject.org
-
Bernardo Innocenti -
Chuck Anderson -
Konstantin Ryabitsev -
Nicolas Mailhot -
Rahul Sundaram -
Reuben Farrelly -
Willem Riede