Spec URL: http://raphgro.fedorapeople.org/review/cppcms/cppcms.spec SRPM URL: http://raphgro.fedorapeople.org/review/cppcms/cppcms-1.0.4-1.fc20.src.rpm Description: CppCMS is a Free High Performance Web Development Framework (not a CMS) aimed at Rapid Web Application Development. It differs from most other web development frameworks like: Python Django, Java Servlets. Fedora Account System Username: raphgro
Created attachment 901321 [details] $ rpmlint rpmbuild/SPECS/cppcms.spec rpmbuild/RPMS/x86_64/cppcms-*
Not sure about: 1) %prep: Should I patch Doxyfile or provide my complete own one? Upstream seems to use an outdated format of the file. 2) %check: Two tests fail on my local system. So I decided to comment that. 3) %files doc: Do we need latex files, e.g. for pdf generation? I included manpages instead into the main package.
Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=6916686
This package has lot of issues. I do not want to sound too negative, but I fear it'll be a long and tiresome process to get this package into Fedora. Let start with pointing out a few selected issues. 1. Packaging: Please properly split the package into <main> and *-devel subpackages: - *.so.* belong into *-devel unless they are dlopened by name. - man3/ are devel doc and therefore belong into *-devel. - *.a are not supposed to be shipped in Fedora at all. - Please be more selective in %files sections. The way you have written them is very sensitive to accidentially picking up files a package is not supposed to contain (cf. *devel vs. <main>). 2. Contents: - Most of the man3/* manpages are junk and are likely to conflict with other packages. - The *-doc package contains a lot of files which are not supposed to be shipped. 3. Bundled libraries: This package bundles quite a number of sources from other origins (boost, json2*.js, sha1, etc.). Please modify the package to use external versions whenever possible.
1. Please setup your real name in bugzilla, not just an email address. 2. Why disable %check? 3. %build %ifarch x86_64 CMAKE_OPT=-DLIBDIR=lib64 %endif %cmake $CMAKE_OPT ------------------ Well, you can try RPM macro %{_lib} and change it to this: %cmake -DLIBDIR=%{_lib} 4. Besides, you are new people, please follow: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers
(In reply to Christopher Meng from comment #5) > 1. Please setup your real name in bugzilla, not just an email address. Sorry, I had to adjust the address to confirm with FAS. > 2. Why disable %check? Because some tests fail. See my initial comment. > 3. > %build > %ifarch x86_64 > CMAKE_OPT=-DLIBDIR=lib64 > %endif > %cmake $CMAKE_OPT > > ------------------ > > Well, you can try RPM macro %{_lib} and change it to this: > > %cmake -DLIBDIR=%{_lib} I'll fix that. Thanks for the hint. > 4. Besides, you are new people, please follow: > > http://fedoraproject.org/wiki/Join_the_package_collection_maintainers Ey.
My name is Raphael Groner <projects.rg>. Why Bugzilla doesn't accept that??
(In reply to Ralf Corsepius from comment #4) > This package has lot of issues. I do not want to sound too negative, but I > fear it'll be a long and tiresome process to get this package into Fedora. Well, having to do homework isn't a good point to argue against required bot worth effort. Upstream is not forced to apply each Fedora policy... ;) > 1. Packaging: > Please properly split the package into <main> and *-devel subpackages: > - *.so.* belong into *-devel unless they are dlopened by name. > - man3/ are devel doc and therefore belong into *-devel. > - *.a are not supposed to be shipped in Fedora at all. > - Please be more selective in %files sections. The way you have written them > is very sensitive to accidentially picking up files a package is not > supposed to contain (cf. *devel vs. <main>). I'll clean up the build, so only the important files should be packaged in. Not sure what to do about manpages, I should skip them completely. > 2. Contents: > - Most of the man3/* manpages are junk and are likely to conflict with other > packages. So just ignore and leave them out of the package? > - The *-doc package contains a lot of files which are not supposed to be > shipped. Please tell me the concrete file names. The sense is to ship html documentation cause doxygen produces that, but we could just ship Doxyfile in -devel and let the user decide if it wants to generate by itself. > 3. Bundled libraries: > This package bundles quite a number of sources from other origins (boost, > json2*.js, sha1, etc.). Please modify the package to use external versions > whenever possible. Hmmm. That's Fedora's policy and a good one. Maybe I have to work with upstream to fix that.
> Why Bugzilla doesn't accept that?? At https://bugzilla.redhat.com/userprefs.cgi?tab=account there are two (separate) fields for real name and email address. Enter the data and your password to confirm. That has worked before for other people, who had been asked to enter the real name.
According to booster / boost: Please read the commented discussion at upstream. I don't know what to do about that in Fedora. Having to remove all that forking code has less sense and would be just ridiculous. http://thread.gmane.org/gmane.comp.lib.boost.devel/204117 http://cppcms.com/wikipp/en/page/cppcms_1x_coding_standards#Libraries
Created attachment 911467 [details] cppcms-20140623.spec At least, some little progess. Here it is a new spec file but it won't work. I think I run into an issue with c++11: "error: provided for 'template<class T1, class T2> struct cppcms::traits", similiar like with this guy: http://www.copyquery.com/boostvariant-boostshared_ptrt-wont-compile/
http://koji.fedoraproject.org/koji/taskinfo?taskID=7068248
(In reply to Raphael Groner from comment #12) Now with --scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=7068257
Created attachment 911476 [details] build-20140623.log
Created attachment 911477 [details] cppcms src rpm (20140623)
CMake Error at CMakeLists.txt:495 (message): Can't build without Python interpreter -- Configuring incomplete, errors occurred!
^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:571:33: error: provided for 'template<class T1, class T2> struct cppcms::traits' struct traits<std::pair<T1,T2> > { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:686:27: error: wrong number of template arguments (1, should be 2) struct traits<long double> { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:571:33: error: provided for 'template<class T1, class T2> struct cppcms::traits' struct traits<std::pair<T1,T2> > { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:703:26: error: wrong number of template arguments (1, should be 2) struct traits<json::null> { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:571:33: error: provided for 'template<class T1, class T2> struct cppcms::traits' struct traits<std::pair<T1,T2> > { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:711:23: error: wrong number of template arguments (1, should be 2) struct traits<char[n]> { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:571:33: error: provided for 'template<class T1, class T2> struct cppcms::traits' struct traits<std::pair<T1,T2> > { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:719:30: error: wrong number of template arguments (1, should be 2) struct traits<char const [n]> { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:571:33: error: provided for 'template<class T1, class T2> struct cppcms::traits' struct traits<std::pair<T1,T2> > { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:729:28: error: wrong number of template arguments (1, should be 2) struct traits<char const *> { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:571:33: error: provided for 'template<class T1, class T2> struct cppcms::traits' struct traits<std::pair<T1,T2> > { ^ /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:740:1: error: expected declaration before '}' token } // cppcms ^ CMakeFiles/cppcms_config_find_param.dir/build.make:80: recipe for target 'CMakeFiles/cppcms_config_find_param.dir/src/json.cpp.o' failed make[2]: Leaving directory '/builddir/build/BUILD/cppcms-1.0.4' CMakeFiles/Makefile2:308: recipe for target 'CMakeFiles/cppcms_config_find_param.dir/all' failed make[1]: Leaving directory '/builddir/build/BUILD/cppcms-1.0.4' Makefile:150: recipe for target 'all' failed RPM build errors: /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h: In instantiation of 'T cppcms::value::get_value() const [with T = std::basic_string<char>]': /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:365:37: required from here /builddir/build/BUILD/cppcms-1.0.4/cppcms/json.h:239:3: warning: no return statement in function returning non-void [-Wreturn-type] } ^ make[2]: *** [CMakeFiles/cppcms_config_find_param.dir/src/json.cpp.o] Error 1 make[1]: *** [CMakeFiles/cppcms_config_find_param.dir/all] Error 2 make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.R8XHoK (%build) Bad exit status from /var/tmp/rpm-tmp.R8XHoK (%build) Child return code was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/cppcms.spec'] Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.7/site-packages/mockbuild/util.py", line 376, in do raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/cppcms.spec'] LEAVE do --> EXCEPTION RAISED
Created attachment 911480 [details] cppcms.spec (20140623.2)
Created attachment 911481 [details] src.rpm (20140623.2)
Thanks for taking care about my request. (In reply to Ralf Corsepius from comment #4) > 3. Bundled libraries: > This package bundles quite a number of sources from other origins (boost, > json2*.js, sha1, etc.). Please modify the package to use external versions > whenever possible. What do you think how we could handle those issues? (In reply to Raphael Groner from comment #10) > According to booster / boost: > Please read the commented discussion at upstream. I don't know what to do > about that in Fedora. Having to remove all that forking code has less sense > and would be just ridiculous. > > http://thread.gmane.org/gmane.comp.lib.boost.devel/204117 > http://cppcms.com/wikipp/en/page/cppcms_1x_coding_standards#Libraries Fork the fork?
(In reply to Raphael Groner from comment #20) > Thanks for taking care about my request. > > (In reply to Ralf Corsepius from comment #4) > > 3. Bundled libraries: > > This package bundles quite a number of sources from other origins (boost, > > json2*.js, sha1, etc.). Please modify the package to use external versions > > whenever possible. > > What do you think how we could handle those issues? Quite simple. There are 3 ways 1. Patch the sources. 2. Report it to upstream and wait until they implement it. 3. Abstain from packaging a package. 1. is the way of least resistance and should not be difficult to implement.
https://raphgro.fedorapeople.org/review/cppcms/cppcms.spec https://raphgro.fedorapeople.org/review/cppcms/cppcms-1.0.4-5.fc20.src.rpm Don't do rpmlint for now. I'll invest later.
(In reply to Ralf Corsepius from comment #21) > There are 3 ways > 1. Patch the sources. > 2. Report it to upstream and wait until they implement it. > 3. Abstain from packaging a package. > > 1. is the way of least resistance and should not be difficult to implement. So that would mean a fork of the fork for booster. I hoped that my two links make it more clear to understand why Fedora policy doesn't comply with upstream guidelines. So instead 3. seems to be the best way to handle it with lowest resistance. :-(
(In reply to Raphael Groner from comment #23) > (In reply to Ralf Corsepius from comment #21) > > There are 3 ways > > 1. Patch the sources. > > 2. Report it to upstream and wait until they implement it. > > 3. Abstain from packaging a package. > > > > 1. is the way of least resistance and should not be difficult to implement. > > So that would mean a fork of the fork for booster. I hoped that my two links > make it more clear to understand why Fedora policy doesn't comply with > upstream guidelines. So instead 3. seems to be the best way to handle it > with lowest resistance. :-( So be it - Sometimes upstreams need to learn the hard way they are doing a poor job.
Taken, a detailed review will follow on friday.
The changelog is not in sync with the actual release no. Thanks to rpmdev-bumpspec.
https://copr.fedoraproject.org/coprs/raphgro/CppCMS/build/51936/ I don't know why COPR can not build for F21.
https://copr.fedoraproject.org/coprs/raphgro/CppCMS/build/51938/
IIRC, we should also ask for an exception to keep booster as it is and embedded: > * Exception for using bundled bullet library for supertuxkart - > https://fedorahosted.org/fpc/ticket/459 (spot, 16:12:03) > * ACTION: Permit supertuxkart to include and use its forks of irrlicht > and bullet. (+1:5, 0:0, -1:0) (spot, 16:19:28)
If you think the exception is neccessary: Please ask for it! Will review after things are clarified. Greetings, Christian
Thanks a lot for your interest. I'll give some thought and come back later to the open issues. Sorry for the delay.
Due to unclear reasoning for the bundled stuff (booster/boost, json2, etc.), I don't see any possible solution for the short run. Unfortunately, I have to decline my review request till there's a working and easy fix found. Thanks for your help.