Bug 226117

rpmlint on SRPM:
mailman.src:41: E: hardcoded-library-path in /usr/lib/%{name}
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.

FIX

mailman.src:135: E: configure-without-libdir-spec
A configure script is run without specifying the libdir. configure
options must be augmented with something like --libdir=%{_libdir}.

FIX

mailman.src: W: mixed-use-of-spaces-and-tabs (spaces: line 59, tab: line 121)
The specfile mixes use of spaces and tabs for indentation, which is a
cosmetic annoyance.  Use either spaces or tabs for indentation, not both.

Minor, but FIX

mailman.src: W: strange-permission mailman-crontab-edit 0755
A file that you listed to include in your package has strange
permissions. Usually, a file should have 0644 permissions.

I don't see where this gets used. ???

mailman.src: W: strange-permission mailman-migrate-fhs 0755
A file that you listed to include in your package has strange
permissions. Usually, a file should have 0644 permissions.

This is installed at 0644.  FIX.

On RPMS:

mailman.i386: E: non-standard-dir-perm /usr/lib/mailman/messages/et/LC_MESSAGES
02775
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

This is for several languages.

mailman.i386: E: non-standard-dir-perm /usr/lib/mailman/templates/no 02775
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

mailman.i386: E: non-executable-script /usr/lib/mailman/Mailman/Post.py 0644
This text file contains a shebang or is located in a path dedicated for
executables, but lacks the executable bits and cannot thus be executed.  If
the file is meant to be an executable script, add the executable bits,
otherwise remove the shebang or move the file elsewhere.

mailman.i386: E: wrong-script-interpreter
/usr/share/doc/mailman-2.1.10/contrib/mm-handler "/usr/local/bin/perl"
This script uses an incorrect interpreter.

mailman.i386: E: non-standard-dir-perm /var/lib/mailman/data 02775
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

mailman.i386: E: wrong-script-interpreter
/usr/share/doc/mailman-2.1.10/contrib/qmail-to-mailman.py "@PYTHON@"
This script uses an incorrect interpreter.

mailman.i386: E: non-standard-dir-perm
/usr/lib/mailman/pythonlib/japanese/mappings 02775
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

mailman.i386: W: file-not-utf8
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-admin.txt
The character encoding of this file is not UTF-8.  Consider converting it
in the specfile for example using iconv(1).

mailman.i386: E: zero-length
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-admin/index.dat

mailman.i386: W: non-conffile-in-etc /etc/logrotate.d/mailman
A non-executable file in your package is being installed in /etc, but is not
a configuration file. All non-executable files in /etc should be configuration
files. Mark the file as %config in the spec file.

mailman.i386: E: zero-length
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-member-es/index.dat

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/rmlist mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: E: non-executable-script
/usr/lib/mailman/Mailman/Archiver/pipermail.py 0644
This text file contains a shebang or is located in a path dedicated for
executables, but lacks the executable bits and cannot thus be executed.  If
the file is meant to be an executable script, add the executable bits,
otherwise remove the shebang or move the file elsewhere.

mailman.i386: W: file-not-utf8
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-member-es.txt
The character encoding of this file is not UTF-8.  Consider converting it
in the specfile for example using iconv(1).

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/roster mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: W: file-not-utf8 /usr/share/doc/mailman-2.1.10/ACKNOWLEDGMENTS
The character encoding of this file is not UTF-8.  Consider converting it
in the specfile for example using iconv(1).

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/listinfo mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: W: file-not-utf8 /usr/share/doc/mailman-2.1.10/README-I18N.en
The character encoding of this file is not UTF-8.  Consider converting it
in the specfile for example using iconv(1).

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/admindb mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: E: setgid-binary /usr/lib/mailman/mail/mailman mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: W: symlink-should-be-relative /etc/mailman/mm_cfg.py
/usr/lib/mailman/Mailman/mm_cfg.py
Absolute symlinks are problematic eg. when working with chroot environments.

mailman.i386: E: zero-length
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-member/index.dat

mailman.i386: E: zero-length
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-install/index.dat

mailman.i386: E: wrong-script-interpreter
/usr/share/doc/mailman-2.1.10/contrib/check_perms_grsecurity.py "@PYTHON@"
This script uses an incorrect interpreter.

mailman.i386: E: wrong-script-interpreter
/usr/share/doc/mailman-2.1.10/contrib/rotatelogs.py "@PYTHON@"
This script uses an incorrect interpreter.

mailman.i386: W: file-not-utf8
/usr/share/doc/mailman-2.1.10/admin/doc/mailman-member.txt
The character encoding of this file is not UTF-8.  Consider converting it
in the specfile for example using iconv(1).

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/private mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/create mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/admin mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.

mailman.i386: E: setgid-binary /usr/lib/mailman/cgi-bin/confirm mailman 02755
The file is setgid. Usually this is a packaging bug. If this is a game,
then, you should use the proper rpm group, or location.


I goes on like this for each file.  There are scores of non-standard perm and
gid errors, but that's just because it's all owned by mailman, which is fine.

The above need to be addressed, for the most part. Full review forthcoming. . .

Source URL should match:
Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz

Other that that and the above, it looks generally OK.

Adding current owner.

On new version:
warning: File listed twice: /etc/mailman/sitelist.cfg
warning: File listed twice: /usr/lib/mailman/Mailman/mm_cfg.py
warning: File listed twice: /usr/lib/mailman/cron/crontab.in

rpmlint:

The above, plus:

Lots of:
mailman.i386: E: file-in-usr-marked-as-conffile /usr/lib/mailman/templates/zh_TW/userpass.txt
A file in /usr is marked as being a configuration file. Store your conf files
in /etc/ instead.

mailman.i386: W: dangerous-command-in-%pre rm
mailman.i386: W: dangerous-command-in-%post rm

mailman.i386: W: incoherent-subsys /etc/rc.d/init.d/mailman $prog
The filename of your lock file in /var/lock/subsys/ is incoherent with your
actual init script name. For example, if your script name is httpd, you have
to use 'httpd' as the filename in your subsys directory. It is also possible
that rpmlint gets this wrong, especially if the init script contains
nontrivial shell variables and/or assignments.  These cases usually manifest
themselves when rpmlint reports that the subsys name starts a with '$'; in
these cases a warning instead of an error is reported and you should check the
script manually.

mailman.i386: W: incoherent-subsys /etc/rc.d/init.d/mailman $prog
The filename of your lock file in /var/lock/subsys/ is incoherent with your
actual init script name. For example, if your script name is httpd, you have
to use 'httpd' as the filename in your subsys directory. It is also possible
that rpmlint gets this wrong, especially if the init script contains
nontrivial shell variables and/or assignments.  These cases usually manifest
themselves when rpmlint reports that the subsys name starts a with '$'; in
these cases a warning instead of an error is reported and you should check the
script manually.

mailman.i386: W: service-default-enabled /etc/rc.d/init.d/mailman
The service is enabled by default after "chkconfig --add"; for security
reasons, most services should not be. Use "-" as the default runlevel in the
init script's "chkconfig:" line and/or remove the "Default-Start:" LSB keyword
to fix this if appropriate for this service.

All need fixing.

Ping?

Ping again?

(In reply to comment #5)
> Ping again?  
hello,
I am currently focusing a lot on fixing mailman bugs, so I will look into this right now. The last major thing in mailman was to uprade to 2.1.12. the config file mm_cfg.py is in /usr/lib/mailman/Mailman/ , since it's a part of Python package Mailman. The other warnings seem interesting, too...

hello,
I worked on the .spec file to adress these issues.

see
http://people.fedoraproject.org/~dnovotny/review/mailman.spec

these are my changes:

* hardcoded library path changed to %{_libdir}
* mixed use of spaces and tabs fixed
* added  --libdir=%{_libdir} to configure
* fixed URL to tarball
* permission of source files changed to 0644 (no strange-permission warnings on .src.rpm)
* got rid of "file listed twice" warnings: listing the files explicitly

the source files permission changes can't be seen in the .spec, I had to do it in the cvs checkout

as for the permission and setgid warnings, I guess mailman needs them that way. 

Also the incoherent-subsys warnings can be ignored because

"It is also possible that rpmlint gets this wrong, especially if the init script contains nontrivial shell variables and/or assignments.  These cases usually manifest themselves when rpmlint reports that the subsys name starts a with '$'"

which is exactly the case.

Do you think that's all, or do I have to fix something more?

Better.  I still get 

mailman.src:46: E: hardcoded-library-path in /usr/lib/%{name}
A library path is hardcoded to one of the following paths: /lib, /usr/lib. It
should be replaced by something like /%{_lib} or %{_libdir}.

mailman.src:131: W: configure-without-libdir-spec
A configure script is run without specifying the libdir. configure options
must be augmented with something like --libdir=%{_libdir} whenever the script
supports it.

mailman.src: W: mixed-use-of-spaces-and-tabs (spaces: line 63, tab: line 132)
The specfile mixes use of spaces and tabs for indentation, which is a cosmetic
annoyance.  Use either spaces or tabs for indentation, not both.

On the SRPM.


There's a *TON* of rpmlint errors on the RPM, mostly perm and gid issues.  Some are not.  The only ones that concern me are these:

Lots of:
mailman.i386: E: file-in-usr-marked-as-conffile
/usr/lib/mailman/templates/zh_TW/userpass.txt
A file in /usr is marked as being a configuration file. Store your conf files
in /etc/ instead.

mailman.i386: W: dangerous-command-in-%pre rm
mailman.i386: W: dangerous-command-in-%post rm

mailman.i386: W: incoherent-subsys /etc/rc.d/init.d/mailman $prog
The filename of your lock file in /var/lock/subsys/ is incoherent with your
actual init script name. For example, if your script name is httpd, you have
to use 'httpd' as the filename in your subsys directory. It is also possible
that rpmlint gets this wrong, especially if the init script contains
nontrivial shell variables and/or assignments.  These cases usually manifest
themselves when rpmlint reports that the subsys name starts a with '$'; in
these cases a warning instead of an error is reported and you should check the
script manually.

mailman.i386: W: incoherent-subsys /etc/rc.d/init.d/mailman $prog
The filename of your lock file in /var/lock/subsys/ is incoherent with your
actual init script name. For example, if your script name is httpd, you have
to use 'httpd' as the filename in your subsys directory. It is also possible
that rpmlint gets this wrong, especially if the init script contains
nontrivial shell variables and/or assignments.  These cases usually manifest
themselves when rpmlint reports that the subsys name starts a with '$'; in
these cases a warning instead of an error is reported and you should check the
script manually.

mailman.i386: W: service-default-enabled /etc/rc.d/init.d/mailman
The service is enabled by default after "chkconfig --add"; for security
reasons, most services should not be. Use "-" as the default runlevel in the
init script's "chkconfig:" line and/or remove the "Default-Start:" LSB keyword
to fix this if appropriate for this service.

All need fixing.  


Still present from #3.

(In reply to comment #8)
> Better.  I still get 
> 
> mailman.src:46: E: hardcoded-library-path in /usr/lib/%{name}
> A library path is hardcoded to one of the following paths: /lib, /usr/lib. It
> should be replaced by something like /%{_lib} or %{_libdir}.
> 
> mailman.src:131: W: configure-without-libdir-spec
> A configure script is run without specifying the libdir. configure options
> must be augmented with something like --libdir=%{_libdir} whenever the script
> supports it.
> 
> mailman.src: W: mixed-use-of-spaces-and-tabs (spaces: line 63, tab: line 132)
> The specfile mixes use of spaces and tabs for indentation, which is a cosmetic
> annoyance.  Use either spaces or tabs for indentation, not both.
> 
> On the SRPM.

this is strange, because I fixed this: rpmlint says "0 errors 0 warnings" on SRPM here... if you look at the new spec, you can see that the --libdir=%{_libdir} is there for example

<facepalm>

Somehow built with the wrong spec.  Rebuilding. . .

Now I get this on the SRPM:

mailman.src: W: strange-permission mailman-crontab-edit 0755
A file that you listed to include in your package has strange permissions.
Usually, a file should have 0644 permissions.

mailman.src: W: strange-permission mailman-migrate-fhs 0755
A file that you listed to include in your package has strange permissions.
Usually, a file should have 0644 permissions.

mailman.src: W: strange-permission mailman-update-cfg 0755
A file that you listed to include in your package has strange permissions.
Usually, a file should have 0644 permissions.

mailman.src: W: mixed-use-of-spaces-and-tabs (spaces: line 63, tab: line 172)
The specfile mixes use of spaces and tabs for indentation, which is a cosmetic
annoyance.  Use either spaces or tabs for indentation, not both.

and the same as #9 on the RPM.

(In reply to comment #11)
> Now I get this on the SRPM:
> 
> mailman.src: W: strange-permission mailman-crontab-edit 0755
> A file that you listed to include in your package has strange permissions.
> Usually, a file should have 0644 permissions.
> 
> mailman.src: W: strange-permission mailman-migrate-fhs 0755
> A file that you listed to include in your package has strange permissions.
> Usually, a file should have 0644 permissions.
> 
> mailman.src: W: strange-permission mailman-update-cfg 0755
> A file that you listed to include in your package has strange permissions.
> Usually, a file should have 0644 permissions.
> 
these changes of permissions have to be done on the CVS server side, wrote e-mail to Fedora CVS admins


btw, I built mailman-2.1.12-5.fc12 with the changes mentioned in 
comment #7

(In reply to comment #1)
> rpmlint on SRPM:
> mailman.src:41: E: hardcoded-library-path in /usr/lib/%{name}
> A library path is hardcoded to one of the following paths: /lib,
> /usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.

Well, thank you for this. By moving stuff to /usr/lib64 on x86_64, my mailman scripts relying on a fixed path to a binary, like /usr/lib/mailman/bin/newlist, stopped working. I've just checked Debian and openSUSE x86_64 mailman packages, and they have these files files under /usr/lib. Are you guys sure it was the right thing to do? Does Fedora really need to be so special?

/usr/lib/mailman/mail/mailman is a binary, as are the bits in cgi-bin. You've also got /usr/lib/mailman/pythonlib/japanese/c/_japanese_codecs.so.  These would, as far as I know, necessitate %{_libdir}.

Actually, the former would rather fit into /usr/libexec IMHO; no objection to having japanese codecs in %{_libdir}. I'm really only interested in the path to mailman control utilities, because that's what I execute. How can one write an arch-independent script that controls mailing lists now? I mean, sure there are hacks like "`rpm -ql mailman | grep /mailman/bin$`" or "`awk -F= '/MAILMANHOME=/ {print $2 }' /etc/rc.d/init.d/mailman`/bin" to determine the path, but...

hello Jon,
I'll explain the remaining warnings:

(In reply to comment #8)

>The only ones that concern me are these:
> 
> Lots of:
> mailman.i386: E: file-in-usr-marked-as-conffile
> /usr/lib/mailman/templates/zh_TW/userpass.txt
> A file in /usr is marked as being a configuration file. Store your conf files
> in /etc/ instead.
> 
these are the HTML files Mailman displays in its UI - they are both data (mailman treats them as data files) and config files, because the user can change them to customize the look and feel used by his mailing list (to conform with his web's design and/or content for example)

> mailman.i386: W: dangerous-command-in-%pre rm
> mailman.i386: W: dangerous-command-in-%post rm
we are not rm-ing any of the mailman's files, the %pre and %post script 
creates its own temporary flag file in /var/run, indicating if the service
is running during an upgrade (see the "restart_flag" variable in the spec)
and we are rm-ing only this script's temporary flag file

> 
> mailman.i386: W: incoherent-subsys /etc/rc.d/init.d/mailman $prog
> The filename of your lock file in /var/lock/subsys/ is incoherent with your
> actual init script name. For example, if your script name is httpd, you have
> to use 'httpd' as the filename in your subsys directory. It is also possible
> that rpmlint gets this wrong, especially if the init script contains
> nontrivial shell variables and/or assignments.  These cases usually manifest
> themselves when rpmlint reports that the subsys name starts a with '$'; in
> these cases a warning instead of an error is reported and you should check the
> script manually.
the subsys is coherent, rpmlint is confused by the usage of shell
variables ("It is also possible that rpmlint gets this wrong" applies here)

> mailman.i386: W: service-default-enabled /etc/rc.d/init.d/mailman
> The service is enabled by default after "chkconfig --add"; for security
> reasons, most services should not be. Use "-" as the default runlevel in the
> init script's "chkconfig:" line and/or remove the "Default-Start:" LSB keyword
> to fix this if appropriate for this service.
> 
yes, the service seems to be on by default: I can fix this after fedora server outage is over

Thanks, Daniel, these make sense.  When you fix the service being on by default, can you add brief versions in logical places in the spec, at least for the HTML/conf file issue?

OK, I will add some brief comments

btw one remark: the "service is default on" behavior was not apparent, because without creating the site list, mailman cannot function (and start up) - and that is why right after the installation mailman is not running: it cannot start properly before the site list is created by the administrator.

unfortunately, site list creation needs user intervention (for example setting administrator's password) so it cannot be done automatically when mailman is installed, thus additional setup by the administrator is required after installation.

I've noticed that actually, I installed it for testing and I got a "Boot Errors" message.

ok, built mailman-2.1.12-13.fc13 with "not default on" patch. you can search for "rpmlint" in the spec for the comments you requested

http://people.fedoraproject.org/~dnovotny/f/mailman.spec
http://koji.fedoraproject.org/koji/taskinfo?taskID=1885973

Ok, thanks, looks great.  Any thoughts on #13 and #15?

(In reply to comment #22)
> Ok, thanks, looks great.  Any thoughts on #13 and #15?
IMHO Radek has a good point. The executable files in mailman's bin directory are all python scripts, so it doesn't matter if they are in lib or lib64, they are not binaries. The best solution I can think of is to revert this change and document in the spec why this is an exception to rpmlint "error" message.

(In reply to comment #23)
> (In reply to comment #22)
> > Ok, thanks, looks great.  Any thoughts on #13 and #15?
> IMHO Radek has a good point. The executable files in mailman's bin directory
> are all python scripts, so it doesn't matter if they are in lib or lib64, they
> are not binaries. The best solution I can think of is to revert this change and
> document in the spec why this is an exception to rpmlint "error" message.    

+1.

OK, new release:
http://people.fedoraproject.org/~dnovotny/f/mailman.spec
http://koji.fedoraproject.org/koji/taskinfo?taskID=1918980

Apparently the _libdir thing hasn't been reverted completely. Please apply the following where applicable (I found it being a problem on F-13, but it should be an issue from F-12 on when built on 64bit):

----- 8< -----
--- mailman.spec	25 Mar 2010 14:31:26 -0000	1.92
+++ mailman.spec	19 Apr 2010 13:53:11 -0000
@@ -263,7 +263,7 @@ cp -r %{mmbuilddir}/doc $RPM_BUILD_ROOT%
 mkdir -p $RPM_BUILD_ROOT%{_bindir}
 install -m755 %{SOURCE8} $RPM_BUILD_ROOT%{_bindir}
 # set library path in mailman-update-cfg script.
-sed -i 's,@libdir@,%{_libdir},g' $RPM_BUILD_ROOT%{_bindir}/mailman-update-cfg
+sed -i 's,@mmdir@,%{mmdir},g' $RPM_BUILD_ROOT%{_bindir}/mailman-update-cfg
 
 # remove dir/files from $RPM_BUILD_ROOT that we aren't shipping
 rm -rf $RPM_BUILD_ROOT%{varmmdir}/icons
--- mailman-update-cfg	22 Jul 2009 11:30:13 -0000	1.2
+++ mailman-update-cfg	19 Apr 2010 13:53:11 -0000
@@ -10,4 +10,4 @@
 
 import py_compile
 
-py_compile.compile("@libdir@/mailman/Mailman/mm_cfg.py")
+py_compile.compile("@mmdir@/Mailman/mm_cfg.py")
----- >8 -----

Nils, thanks for your comment and solution. I have made a bug for this:

https://bugzilla.redhat.com/show_bug.cgi?id=583966

(In reply to comment #28)
> Apparently the _libdir thing hasn't been reverted completely. Please apply the
> following where applicable (I found it being a problem on F-13, but it should
> be an issue from F-12 on when built on 64bit):
> 
> ----- 8< -----
> --- mailman.spec 25 Mar 2010 14:31:26 -0000 1.92
> +++ mailman.spec 19 Apr 2010 13:53:11 -0000
> @@ -263,7 +263,7 @@ cp -r %{mmbuilddir}/doc $RPM_BUILD_ROOT%
>  mkdir -p $RPM_BUILD_ROOT%{_bindir}
>  install -m755 %{SOURCE8} $RPM_BUILD_ROOT%{_bindir}
>  # set library path in mailman-update-cfg script.
> -sed -i 's,@libdir@,%{_libdir},g' $RPM_BUILD_ROOT%{_bindir}/mailman-update-cfg
> +sed -i 's,@mmdir@,%{mmdir},g' $RPM_BUILD_ROOT%{_bindir}/mailman-update-cfg
> 
>  # remove dir/files from $RPM_BUILD_ROOT that we aren't shipping
>  rm -rf $RPM_BUILD_ROOT%{varmmdir}/icons
> --- mailman-update-cfg 22 Jul 2009 11:30:13 -0000 1.2
> +++ mailman-update-cfg 19 Apr 2010 13:53:11 -0000
> @@ -10,4 +10,4 @@
> 
>  import py_compile
> 
> -py_compile.compile("@libdir@/mailman/Mailman/mm_cfg.py")
> +py_compile.compile("@mmdir@/Mailman/mm_cfg.py")
> ----- >8 -----

. .. which is resolevd.  So where are we now?

Ping?

Adding the current maintainer to Cc.

Note that it seems like upstream might finish their 3.0 rewrite "Really Soon Now". It has a different architecture and will require completely different packaging.

Considering the pace here it might be more efficient and realistic to work with upstream to ensure that 3.0 will be more suitable for packaging according to our guidelines.

Thank you for adding me into CC, I didn't know about this merge review (Maybe I should start searching for my packages names from time to time).

If I understand this review well, it is about changing the directory structure and whole packaging process to fit better Fedora guidelines, right?

As I've checked it so far, there's for example problem with "/usr/lib/mailman/Mailman/mm_cfg.py". Config files really should not be in /usr/lib. This is not easily fixable unless you start doing some magic like importing python files from /etc/mailman/. (Bug 683763)

There is also problem with /etc/mailman/mm_cfg.py symlink, because if you run "rpmbuild" locally, it will generate "/etc/mailman/mm_cfg.pyo" and "/etc/mailman/mm_cfg.pyc". Current Mailman package workarounds it using "%{configdir}/mm_cfg.*" in %files section, but those files should not be there. Interesting thing is that those files are not generated when building using Koji.

The solution for it is to byte-compile everything manually instead of /etc/mailman/ directory or to finish this RFE http://rpm.org/ticket/837 .

> Considering the pace here it might be more efficient and realistic to work with
> upstream to ensure that 3.0 will be more suitable for packaging according to
> our guidelines.

I think this is better idea probably. Mailman 3 fixes lot of things and I think they won't release alpha versions forever and if I consider this review request is here for 4.5 years...

However, I will check the changes in .spec mentioned in this bug more closely to see what exactly changed.

Agreed, please post here when you get 3.x in rawhide, and I'll review it.

I still see 2.x.  Any ETA?

Ping?

Ping?

I still see 2.x.  Any ETA?

I don't see any ETA for 3.0, but in rawhide I'm trying to improve current 2.0 situation. I have prepared commit to move /usr/share/templates to /etc (which produces the most rpmlint warnings currently). I will check the original problems mentioned here and try to fix them too.

Cool, thanks, keep me posted!

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.

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

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.

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.