Bug 225708 - Merge Review: dovecot
Summary: Merge Review: dovecot
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dovecot
Version: 23
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-01-31 18:30 UTC by Nobody's working on this, feel free to take it
Modified: 2016-12-20 11:56 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 11:56:00 UTC
Type: ---
Embargoed:
kevin: fedora-cvs+


Attachments (Terms of Use)
Diff of spec file changes for merge review items (6.06 KB, patch)
2007-02-26 07:18 UTC, Jef Spaleta
no flags Details | Diff

Description Nobody's working on this, feel free to take it 2007-01-31 18:30:07 UTC
Fedora Merge Review: dovecot

http://cvs.fedora.redhat.com/viewcvs/devel/dovecot/
Initial Owner: tjanouse

Comment 1 Jef Spaleta 2007-02-26 07:15:10 UTC
Executive Summary:
Okay this package needs some work.  I've tried to incorporate as many of the
important changes as I could into an updated specfile. I will attach a diff of
my spec against the spec in fedora core cvs for your to look over. Additionally
you can find my spec and the srpm built from it at.
Please take a close look at the specfile diff. If there are any changes that you
have an issue with, we will need to discuss them. 

I'll probably have other minor specfile cleanup suggestions on a second pass
through the specfile after we work through the important changes.

The very detailed review follows below.

Legend:  
GOOD: +  BAD: -   
Not Applicable: N/A  
Still in Progress or questinable: ?

+ MUST: The package is named according to the Package Naming Guidelines.
+ MUST: The spec file name is good
+ MUST: The package is licensed with approved licenses
+ MUST: The License field in the package spec file matches the most relevant
actual license.
  Comment: parts of the upstream code are lcensed under the MIT license, but it
is probably best to list the LGPL here alone, since by the nature of the
interaction of the licenses the LGPL applies to everything in the upstream source.
+ MUST: The spec file is written in a close approximation of American English.
+ MUST: The spec file for the package is legible. 
+ MUST: The package must successfully compile and build into binary rpms on at
least one supported architecture.
  see
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/dovecot-1.0-3.rc22.fc7.src.rpm/result/
+ MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of Packaging Guidelines; inclusion of
those as BuildRequires is optional. Apply common sense.
+ MUST: A package must not contain any duplicate files in the %files listing.
+ MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
+ MUST: Each package must consistently use macros, as described in the macros
section of Packaging Guidelines.
+ MUST: The package must contain code, or permissable content. This is described
in detail in the code vs. content section of Packaging Guidelines.
+ MUST: Packages must not own files or directories already owned by other packages. 
  Comment: This appears to be true

- MUST: rpmlint output with comments inline below.
- MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.  
  Need to include COPYING COPYING.MIT and COPYING.LGPL in the docs.  Fixed in
updated spec diff
- MUST: The sources used to build the package must match the upstream source, as
provided in the spec URL. Reviewers should use md5sum for this task.
  The SOURCE0 url was inadequate, fixed in the supplied specfile diff.
  md5sum check passes:
  upstraam release: d5bd3ce8ba7ca2ee9f563fe63a1f700a  dovecot-1.0.rc22.tar.gz
  included source:  d5bd3ce8ba7ca2ee9f563fe63a1f700a  dovecot-1.0.rc22.tar.gz
- MUST: A package must own all directories that it creates. 
  comment: /etc/pki/dovecot not owned, fixed in provided specfile diff         
- MUST: If a package includes something as %doc, it must not affect the runtime
of the application. To summarize: If it is in %doc, the program must run
properly if it is  not present.
  comment: mkcert.sh is being used in %post.  This is not good and it breaks the
rule concerning running properly if docs are not present.  mkcert should be
moved to libexec and used from there. Fixed in the provided spec.
- MUST: Header files or static libraries must be in a -devel package.
  comment: Need to remove .a files or create a -devel package for them with a
justification as to why the static libs are needed.  The best thing to do is to
remove the .la and .a files all together.  This is done in the specfile diff
provided.
- MUST: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
  Comment: removed in the provided specfile diff.

? MUST: Every binary RPM package which stores shared library files (not just
symlinks) in any of the dynamic linker's default paths, must call ldconfig in
%post and %postun. If the package has multiple subpackages with libraries, each
subpackage should also have a %post/%postun section that calls /sbin/ldconfig.
  Comment:  shared libs exist in /usr/lib/dovecot but they appear to be simple
plugins for dovecot's own runtime use and not meant for linking.  if this is the
case, then no corrections need to be made. Please confirm that the items in
/usr/lib/dovecot are not meant to be dynamically linkable libraries.
? MUST: Permissions on files must be set properly. 
  comment: see rpmlint comments below
? MUST: The package must meet the Packaging Guidelines.

N/A MUST: The spec file MUST handle locales properly. This is done by using the
%find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
N/A MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in ExcludeArch. 
N/A package is not designed to be relocatable
N/A MUST: No Large documentation files or -doc subpackage. 
N/A no  pkgconfig(.pc) files in payload
N/A MUST: If a package contains library files with a suffix (e.g.
libfoo.so.1.1), then library files that end in .so (without suffix) must go in a
-devel package.
N/A MUST: no devel subpackage In the vast majority of cases, devel packages must
require the base package using a fully versioned dependency: Requires: %{name} =
%{version}-%{release} 
N/A Package does not contain GUI application no need for a %{name}.desktop file

RPMLINT COMMENTS INLINE

http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/dovecot-1.0-3.rc22.fc7.src.rpm/result/rpmlint.log
rpmlint on dovecot-1.0-3.rc22.fc7.src.rpm
W: dovecot strange-permission migrate-users 0755
W: dovecot strange-permission migrate-folders 0755
W: dovecot strange-permission dovecot.init 0755
W: dovecot strange-permission perfect_maildir.pl 0755
...These permissions appear to be okay to me. 
W: dovecot prereq-use openssl >= 0.9.7f-4, /sbin/chkconfig, /usr/sbin/useradd
... Requires fixed in provided specfile diff. prereq is no longer valid. See the
PackagingGuidelines for more details
E: dovecot configure-without-libdir-spec
?????  I am not sure what rpmlint is trying to tell us here.
E: dovecot use-of-RPM_SOURCE_DIR
.... The other option would be to use the appropriate SOURCE# macros for each
source file.  Changed in the specfile diff provided.
W: dovecot macro-in-%changelog _datadir
W: dovecot macro-in-%changelog post
.... Editted in spec diff
W: dovecot mixed-use-of-spaces-and-tabs (spaces: line 82, tab: line 84)
.... fixed in spec diff
W: dovecot patch-not-applied Patch104: dovecot-1.0.beta2-lib64.patch
.... commented out in spec diff

rpmlint on dovecot-1.0-3.rc22.fc7.i386.rpm
W: dovecot conffile-without-noreplace-flag /etc/pam.d/dovecot
W: dovecot conffile-without-noreplace-flag /etc/rc.d/init.d/dovecot
.... I think the pam.d config needs to be noreplace to perserve local admin
changes if they are made. Updated in the specfile diff.
E: dovecot non-standard-gid /var/run/dovecot dovecot
.... this is fine.
E: dovecot executable-marked-as-config-file /etc/rc.d/init.d/dovecot
.... this is standard for initscripts
E: dovecot non-readable /etc/pki/dovecot/certs/dovecot.pem 0600
E: dovecot non-standard-uid /var/lib/dovecot dovecot
E: dovecot non-standard-gid /var/lib/dovecot dovecot
E: dovecot non-standard-dir-perm /var/lib/dovecot 0750
E: dovecot non-standard-gid /var/run/dovecot/login dovecot
E: dovecot non-standard-dir-perm /var/run/dovecot/login 0750
E: dovecot non-readable /etc/pki/dovecot/private/dovecot.pem 0600
.... all of these rpmlint errors appear to be bogus to me. Please confirm that
the permissions and ownership are as intended for these.
E: dovecot non-standard-gid /usr/share/doc/dovecot-1.0/examples/mkcert.sh dovecot
E: dovecot non-readable /usr/share/doc/dovecot-1.0/examples/mkcert.sh 0750
E: dovecot non-standard-executable-perm
/usr/share/doc/dovecot-1.0/examples/mkcert.sh 0750
.... I think these are valid errors, if mkcert.sh is really meant to be a doc
item. But its being used in post so it needs to be moved out of the doc area.
     Fixed in provided spec diff.
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib20_convert_plugin.a
W: dovecot devel-file-in-non-devel-package
/usr/lib/dovecot/imap/lib11_imap_quota_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/imap/lib20_zlib_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib01_acl_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib11_trash_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib10_quota_plugin.a
W: dovecot devel-file-in-non-devel-package
/usr/lib/dovecot/lib02_lazy_expunge_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib20_mail_log_plugin.a
....  the .a files are removed in specfile diff
W: dovecot dangerous-command-in-%pre rm
W: dovecot dangerous-command-in-%post mv
W: dovecot dangerous-command-in-%preun userdel
....  I think these warnings are bogus. Though you may want to look back over 
      the use of the rm and mv commands to see if they are still needed.
      I think I understand why the restart_flag logic is present.  
      But I do not understand why the ssl cert manipulation logic block is in  
      %post.  All the file location testing and conditional use of mv. What
      cases trigger the mv commands? Is this logic meant for now EOL'd fedora 
      and rhl releases?
    

Comment 2 Jef Spaleta 2007-02-26 07:18:28 UTC
Created attachment 148781 [details]
Diff of spec file changes for merge review items

This is the diff between the dovecot.spec in fedora cvs and my merge review
edditted dovecot.spec.

Comment 3 Jef Spaleta 2007-02-26 07:24:16 UTC
You can find the srpm and spec file with my changes at:
http://jspaleta.thecodergeek.com/merge-review/dovecot/

-jef

Comment 4 Tom Diehl 2007-02-26 15:09:59 UTC
Comment:  shared libs exist in /usr/lib/dovecot but they appear to be simple
plugins for dovecot's own runtime use and not meant for linking.  if this is the
case, then no corrections need to be made. Please confirm that the items in
/usr/lib/dovecot are not meant to be dynamically linkable libraries.

With respect to the above comment,
If there is no -devel package, does that stop someone from being able to build
something like http://wiki.dovecot.org/LDA/Sieve?highlight=%28dovecot-sieve%29
against it? I know that Sieve will not build the way dovecot is currently
packaged, because the Sieve program needs to be able to find a file called
dovecot-config in the "compiled Dovecot sources". I do not know what the correct
way to handle this but I ask that you take my comments into consideration, in
case someone would like to use Dovecot-Sive with this package.

Comment 5 Tomas Janousek 2007-03-02 15:01:39 UTC
Hi Jef,
thanks for your review, I applied your diff and commited, just changed the
section removing .la/.a files to use find instead. My comments follow:


(In reply to comment #1)
> ? MUST: Every binary RPM package which stores shared library files (not just
> symlinks) in any of the dynamic linker's default paths, must call ldconfig in
> %post and %postun. If the package has multiple subpackages with libraries, each
> subpackage should also have a %post/%postun section that calls /sbin/ldconfig.
>   Comment:  shared libs exist in /usr/lib/dovecot but they appear to be simple
> plugins for dovecot's own runtime use and not meant for linking.  if this is the
> case, then no corrections need to be made. Please confirm that the items in
> /usr/lib/dovecot are not meant to be dynamically linkable libraries.

I confirm that.

> E: dovecot configure-without-libdir-spec
> ?????  I am not sure what rpmlint is trying to tell us here.

This is probably a rpmlint bug, the libdir is passed by %configure itself.

> E: dovecot non-readable /etc/pki/dovecot/certs/dovecot.pem 0600
> E: dovecot non-standard-uid /var/lib/dovecot dovecot
> E: dovecot non-standard-gid /var/lib/dovecot dovecot
> E: dovecot non-standard-dir-perm /var/lib/dovecot 0750
> E: dovecot non-standard-gid /var/run/dovecot/login dovecot
> E: dovecot non-standard-dir-perm /var/run/dovecot/login 0750
> E: dovecot non-readable /etc/pki/dovecot/private/dovecot.pem 0600
> .... all of these rpmlint errors appear to be bogus to me. Please confirm that
> the permissions and ownership are as intended for these.

Yes, they are.

> W: dovecot dangerous-command-in-%pre rm
> W: dovecot dangerous-command-in-%post mv
> W: dovecot dangerous-command-in-%preun userdel
> ....  I think these warnings are bogus. Though you may want to look back over 
>       the use of the rm and mv commands to see if they are still needed.
>       I think I understand why the restart_flag logic is present.  
>       But I do not understand why the ssl cert manipulation logic block is in  
>       %post.  All the file location testing and conditional use of mv. What
>       cases trigger the mv commands? Is this logic meant for now EOL'd fedora 
>       and rhl releases?

Yeah, the certificate paths used to be different, this block moves them to new
location.


(In reply to comment #4)
> If there is no -devel package, does that stop someone from being able to build
> something like http://wiki.dovecot.org/LDA/Sieve?highlight=%28dovecot-sieve%29
> against it? I know that Sieve will not build the way dovecot is currently
> packaged, because the Sieve program needs to be able to find a file called
> dovecot-config in the "compiled Dovecot sources". I do not know what the correct
> way to handle this but I ask that you take my comments into consideration, in
> case someone would like to use Dovecot-Sive with this package.

I didn't find any easy way to make dovecot-sieve compile against packaged
version. It just wants access to the dovecot build dir. I might create a -devel
package in the future as upstream added an option to install headers, but the
location of things is probably still not ok. Regarding dovecot-sieve, we'll
probably build that from the same source package.

Comment 6 Jef Spaleta 2007-03-04 09:09:37 UTC
(In reply to comment #5)
> Yeah, the certificate paths used to be different, this block moves them to new
> location.

Would it be possible to drop these? When did the paths change? How far back in
terms of fedora releases is this actually useful? Or if it can't be dropped can
this be converted to a trigger?

Comment 7 Tomas Janousek 2007-03-05 11:50:04 UTC
The newest fedora rls in which the old paths are used is FC-3. They are used in
RHEL-4 as well. Should I remove the block then?

Comment 8 Tomas Janousek 2007-10-15 15:03:30 UTC
Package Change Request
======================
Package Name: dovecot
New Branches: F-8

Comment 9 Kevin Fenzi 2007-10-15 15:26:57 UTC
cvs done.

Comment 10 Paul Howarth 2008-05-22 09:09:24 UTC
Some comments on the current scriptlets.

1. In %post, the code to migrate the certificates from the old locations is
enclosed in a block that is only used on installs, not upgrades. Isn't the
entire point of the certificate-moving code to facilitate tidy upgrades?

2. Again in %post, the certificate and DH parameter generation is only done for
installs, not upgrades. But the certificates and DH parameters are only
generated if they don't already exist anyway, so it seems to me that the test
for "install, not upgrade" can be dispensed with entirely.

3. Why is the "service dovecot condrestart" in %postun rather than %post? When
upgrading from a version of dovecot prior to this one, the condrestart won't
happen (though it will for subsequent upgrades).

4. Again in %postun, the removal of the dovecot group and user should be
stripped out - the current packaging guidelines say not to remove
package-created users and groups
(http://fedoraproject.org/wiki/Packaging/UsersAndGroups). Similarly, in %pre,
the creation of the dovecot user account doesn't follow the currently prescribed
recipe (that includes the use of getent).




Comment 11 Dan Horák 2008-05-22 09:30:03 UTC
1. + 2. I will recheck the logic

3.
http://fedoraproject.org/wiki/Packaging/SysVInitScript#head-91577460937bcc1e94127ca00afd8e69274823b0

4. looks like I missed this guideline, but found some other about
UsersAndGroups, I will fix it

Thanks for catching this issues.

Comment 12 Dan Horák 2008-05-29 07:16:26 UTC
updated version was commited

ad 1. + 2. - I have removed the whole upgrading part of the scriptlet because it
was useful only when upgrading from versions < 1.0 and any serious user has
already done an upgrade for at least security reasons

ad 4. - fixed

http://cvs.fedoraproject.org/viewcvs/rpms/dovecot/devel/dovecot.spec?rev=1.101&view=auto

Comment 13 Susi Lehtola 2009-03-27 07:30:19 UTC
Ping, any progress?

Comment 14 Michal Hlavinka 2009-04-20 08:58:25 UTC
(In reply to comment #13)
> Ping, any progress?  

dovecot.spec has been updated, waiting for objections :o)

Comment 15 Michal Hlavinka 2009-11-26 13:53:46 UTC
ping, any update?

Comment 16 Paul Howarth 2009-11-27 10:40:20 UTC
Jef, are you still interested in completing this review or would it be OK for someone else to take over?

Comment 17 Paul Howarth 2010-04-09 11:11:27 UTC
No response from Jef for 5 months; anyone object to me taking over the review?

Comment 18 Michal Hlavinka 2010-06-10 15:32:41 UTC
no objections from me, it's another two months, I think you can take it

Comment 19 Michal Hlavinka 2012-01-04 16:02:24 UTC
no response for a looong time, I've reset assignee of this bug, so anyone else can take it.

Comment 20 Paul Howarth 2012-02-23 12:49:01 UTC
Some comments from comparing the built packages with my local build (see http://www.city-fan.org/cfo-trac/browser/dovecot/trunk):

You could include /var/run/dovecot, /var/run/dovecot/login and /var/run/dovecot/empty as regular (not %ghost) directories in the package and add entries for the latter two directories in the tmpfiles.d config file. There would no longer be any need then to create/chown/restorecon those directories in %post, and an rpm query for ownership of the directories would give the proper answer.

The main package contains %_libexecdir/dovecot/managesieve and %_libexecdir/dovecot/managesieve-login, which are duplicates of the ones in the pigeonhole package.

The main package contains %_libdir/dovecot/lib90_sieve_plugin.so, which should be (but isn't) in the pigeonhole package.

Perhaps the main package should own the %_libdir/dovecot/settings directory in case any package other than the pigeonhole one wanted to drop files in there in the future?

I have a Requires(post) for openssl for the mkcert.sh script but I guess that's covered by the Requires: openssl anyway?

The Requires(post) and Requires(preun) of chkconfig are not needed for systemd-based releases.

The Requires(post) and Requires(preun) of shadow-utils are not needed at all.

The Requires(preun) of initscripts is not needed for systemd-based releases.

Perhaps install the pigeonhole documentation into directory %_docdir/dovecot-pigeonhole-2.1.0 as per the rpm package name/version rather than %_docdir/dovecot-2.1-pigeonhole-0.3.0 as per upstream naming?

Comment 21 Michal Hlavinka 2012-02-24 12:33:55 UTC
(In reply to comment #20)
> Some comments from comparing the built packages with my local build (see
> http://www.city-fan.org/cfo-trac/browser/dovecot/trunk):
> 
> You could include /var/run/dovecot, /var/run/dovecot/login and
> /var/run/dovecot/empty as regular (not %ghost) directories in the package and
> add entries for the latter two directories in the tmpfiles.d config file. There
> would no longer be any need then to create/chown/restorecon those directories
> in %post, and an rpm query for ownership of the directories would give the
> proper answer.

I prefer it the way it is now.

> The main package contains %_libexecdir/dovecot/managesieve and
> %_libexecdir/dovecot/managesieve-login, which are duplicates of the ones in the
> pigeonhole package.

fixed

> The main package contains %_libdir/dovecot/lib90_sieve_plugin.so, which should
> be (but isn't) in the pigeonhole package.

fixed

> Perhaps the main package should own the %_libdir/dovecot/settings directory in
> case any package other than the pigeonhole one wanted to drop files in there in
> the future?

fixed

> I have a Requires(post) for openssl for the mkcert.sh script but I guess that's
> covered by the Requires: openssl anyway?

yes

> The Requires(post) and Requires(preun) of chkconfig are not needed for
> systemd-based releases. 

fixed

> The Requires(post) and Requires(preun) of shadow-utils are not needed at all.

fixed

> The Requires(preun) of initscripts is not needed for systemd-based releases.

fixed

> Perhaps install the pigeonhole documentation into directory
> %_docdir/dovecot-pigeonhole-2.1.0 as per the rpm package name/version rather
> than %_docdir/dovecot-2.1-pigeonhole-0.3.0 as per upstream naming?

I did this intentionally because it's better (at least in my opinion :)

Comment 22 Michal Hlavinka 2014-03-04 14:23:13 UTC
Is there anything left or can we close this review?

Comment 23 Dan Horák 2014-03-26 10:36:53 UTC
(In reply to Michal Hlavinka from comment #22)
> Is there anything left or can we close this review?

There is one little thing - you should switch from the hardcoded gz extension in the man pages in %files to the common wildcard scheme. As the compression is done by rpmbuild itself it allows switching to another compression method without touching the spec file.

eg.
%{_mandir}/man1/deliver.1.gz => %{_mandir}/man1/deliver.1*

Comment 24 Michal Hlavinka 2014-03-26 14:05:57 UTC
I don't think such change is worth it, but changed anyway.

Comment 25 Paul Howarth 2014-03-26 16:37:54 UTC
A few more things I noticed:

* Adding BR: xz-devel would enable support for xz-compressed mailboxes

* %defattr has been redundant since rpm 4.4 (EL-5 doesn't need it...)

* /var/run/dovecot is marked as %ghost but its implicitly-included subdir
  /var/run/dovecot/empty is not, which doesn't really make sense

* The daemon creates /var/run/dovecot/token-login at start-up; perhaps the
  package should treat this directory the same as /var/run/dovecot/empty?

* lib10_doveadm_sieve_plugin.so is in the main package rather than the
  pigeonhole package

* rpmlint would like the obsoletes for the old sieve and managesieve packages
  to have matching provides

Comment 26 Michal Hlavinka 2014-03-27 15:42:07 UTC
> A few more things I noticed:
> * Adding BR: xz-devel would enable support for xz-compressed mailboxes

added
 
> * %defattr has been redundant since rpm 4.4 (EL-5 doesn't need it...)

removed

> * /var/run/dovecot is marked as %ghost but its implicitly-included subdir
>   /var/run/dovecot/empty is not, which doesn't really make sense

/var/run/dovecot is directory marked as %ghost which means that all files and subdirectories (that are present after %install) are ghost too (AFAIK). What makes you think that "empty" is not ghost? When I remove that dir and do

$ rpm -V dovecot

everything is fine, while after removing any man page file (for example) it complains. Also it is not in the rpm archive:

$ rpm2cpio ./x86_64/dovecot-2.2.12-1.fc21.x86_64.rpm | cpio --list | grep var
20162 blocks
./var/lib/dovecot



> * The daemon creates /var/run/dovecot/token-login at start-up; perhaps the
>   package should treat this directory the same as /var/run/dovecot/empty?

done

> * lib10_doveadm_sieve_plugin.so is in the main package rather than the
>   pigeonhole package

fixed

> * rpmlint would like the obsoletes for the old sieve and managesieve packages
>   to have matching provides

fixed (obsolete removed, Fedora N-2 does not have such packages)

Comment 27 Paul Howarth 2014-03-27 16:18:04 UTC
(In reply to Michal Hlavinka from comment #26)
> > * /var/run/dovecot is marked as %ghost but its implicitly-included subdir
> >   /var/run/dovecot/empty is not, which doesn't really make sense
> 
> /var/run/dovecot is directory marked as %ghost which means that all files
> and subdirectories (that are present after %install) are ghost too (AFAIK).
> What makes you think that "empty" is not ghost? When I remove that dir and do
> 
> $ rpm -V dovecot
> 
> everything is fine, while after removing any man page file (for example) it
> complains. Also it is not in the rpm archive:
> 
> $ rpm2cpio ./x86_64/dovecot-2.2.12-1.fc21.x86_64.rpm | cpio --list | grep var
> 20162 blocks
> ./var/lib/dovecot

My mistake, mis-reading of rpmdiff output. Sorry about that.

Comment 28 Michal Hlavinka 2014-03-31 08:38:13 UTC
Seem I forgot to push the changes. Fixed, it's in repository now.

Comment 29 Cole Robinson 2015-02-11 20:36:05 UTC
Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

  https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

  https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.

Comment 30 Paul Howarth 2015-03-04 16:45:19 UTC
More items:

 * The COPYING* files should be %license rather than %doc except on EL < 7

 * pigeonhole upstream tarball is now at
   http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-%{pigeonholever}.tar.gz

 * Are you still trying to maintain EL-5 compatibility? If so, then the buildreq
   of quota-devel should be guarded with "%if %{?fedora}0 > 90 || %{?rhel}0 >50"
   as there was no quota-devel package prior to then. If not, there are some
   EL5-isms that could go, such as buildroot definition, Group: tag, %clean
   section etc.

 * I couldn't find any MIT-licensed code in pigeonhole but the pigeonhole
   package's license is stated as "MIT and LGPLv2" - why?

 * There's a typo "executalbe" in the comment on the openssl dependency

 * SOURCE2 is mangled in %install for EL-5 builds; it would be better to copy
   it to the build dir in %prep and mangle it there

 * The use of "%{name}" and "dovecot" seems rather ad-hoc. I suspect it would
   need quite a bit of tweaking of the package to get it to build usefully if
   %{name} was defined as anything other than "dovecot". Might be worth
   rationalizing but it's certainly not a blocker.

I hope to be able to finish off this review soon!

Comment 31 Jan Kurik 2015-07-15 15:26:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 32 Fedora End Of Life 2016-11-24 10:18:11 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 33 Fedora End Of Life 2016-12-20 11:56:00 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.