http://dhd.selfip.com/427e/stxxl-1.spec is not a valid URL and under http://dhd.selfip.com/427e/ I see nothing relevant.


Usually .a are statically build libs and they require special packaging. See http://fedoraproject.org/wiki/Packaging/Guidelines#Exclusion_of_Static_Libraries

According to http://koji.fedoraproject.org/koji/getfile?taskID=980986&name=build.log, your package does not respect the mandatory Fedora compiler flags, as described by http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags.

And not only the ppc build fails, all of them do.

Disabling the latex generation causes all arches to build successfully. 

Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=981048

SPEC URL:	http://dhd.selfip.com/427e/stxxl-2.spec
SRPM URL:	http://dhd.selfip.com/427e/stxxl-1.2.1-2.fc9.src.rpm

Changelog

* Sat Dec 06 2008 <mycae(a!t)yahoo.com> 1.2.1-2
- Removed latex build & buildrequires
- Patched makefiles to provide shared instead of static libs
- made doxygen log to file, due to excessively verbose output

Rpmlint:
SRPM:empty
SPEC:empty
RPM:
$ rpmlint -iv RPMS/i386/stxxl-1.2.1-2.fc9.i386.rpm 
stxxl.i386: I: checking
stxxl.i386: W: devel-file-in-non-devel-package /usr/lib/libstxxl-0.so
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.

Now this is causing problems, If i put the link in the devel package it says it must be part of the package proper and emits an error. If I put it in the main, as I have done now, it emits this warning. The libstxxl-0.so is simply a symlink to libstxxl.so.0. Running ldconfig -n during %install instead of hand-cranking the symlink makes no difference, as the net result is the same. It simply makes the symlink using the soname of the so. This soname is the same value that I have set in the build patch (patch0).

Koji scratch: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=981419
All succeeded.

Issues:
I don't build the user manual. This however can be grabbed from their sf page by users, so unless someone knows the solution off the top of their head to the latex problem, I will probably leave it.

3 week ping?

* "Summary" of -devel package is not "short and concise" as recommended by the guidelines, but two sentences squeezed into an overlong line.

* Run rpmlint also on your src.rpm

* src.rpm download URL gives 404 Not Found

* %description of the -devel package is the same as the description of the main package. That can't be right. Typically, you can cut down on that and simply say something like: "This package contains development files for compiling software that uses %{name}."

* -devel pkg typically must "Requires: %{name} = %{version}-%{release}" to stay in sync with the main package.

Note : That could also be the answer to your problem with the .so symlink. The symlink must be in the -devel package, and the -devel package requires the main package which contains the library file.

* %files devel section is missing %defattr parameter

* %files devel section contains unowned directories! Either add the missing

  %dir %{_docdir}/stxxl-1.2.1
  %dir %{_includedir}/stxxl

or use equivalent entries to include these directories and their contents recursively. You would do this by removing the "*" wildcard that you use currently.

SPEC URL: http://dhd.selfip.com/427e/stxxl-3.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-3.fc10.src.rpm

Rpmlint:
SRPM:	empty
SPEC:	empty
RPM:	empty

>"Summary" of -devel package is not "short and concise" as recommended by the
>guidelines, but two sentences squeezed into an overlong line.
I shortened it in the main package, though I thought it was pretty short to begin with. In the devel section it has been corrected, as it was clearly overlong. The main summary is slightly shortened but cannot be shortened further without losing information.

>Run rpmlint also on your src.rpm

My apologies if I had not -- I thought I had, as stated in comment 3. Clearly not, as running it produces a myriad of errors.

>src.rpm download URL gives 404 Not Found
Again, that's just sloppy on my part -- I didn't transfer it to the server. Both the old and the new have been uploaded.

> %description of the -devel package is the same as the description of the main
package.
Fixed. 

> -devel pkg typically must "Requires: %{name} = %{version}-%{release}" to stay
in sync with the main package.
Fixed

> %files devel section contains unowned directories! 
Fixed --  would have been evident had i run rpmlint correctly.

>%files devel section is missing %defattr parameter
Done.

>Note : That could also be the answer to your problem with the .so symlink. The
>symlink must be in the -devel package, and the -devel package requires the main
>package which contains the library file.

It wasn't that -- I worked it out in the end with the help of 
http://en.opensuse.org/Shared_Library_Packaging_Policy . Which was very clear, both in procedure and rationale. Seems to keep rpmlint happy and matches what is happening in other packages in my /usr/lib/.


I hope this package is less sloppy than the last attempt!

I'll review it.

Notes:

* The %build section still doesn't honour %optflags. You should fix your spec in the following way:

- echo OPT=-O2 -fPIC >> make.settings.local
+ echo "OPT=%{optflags}" >> make.settings.local

* Regarding %install section - you may shorten it a bit by replacing

mkdir %{buildroot}
mkdir -p %{buildroot}/%{_libdir}/
cp ./lib/libstxxl.so %{buildroot}/%{_libdir}/libstxxl.so.%{version}

with

install -p -D -m 0755 ./lib/libstxxl.so %{buildroot}/%{_libdir}/libstxxl.so.%{version}

* You also don't need to explicitly install doc-files. Just enumerate them in %files section properly. Let's assume, that you wish to install TROUBLESHOOTING file as %doc - all you need is to add 

%files
%doc TROUBLESHOOTING

and rpmbuild will cd into rpmbuild/BUILD/stxxl-1.2.1 directory and will search TROUBLESHOOTING here.

So you should remove the following lines:

mkdir -p %{buildroot}/%{_docdir}/
#Install Documentation
mkdir -p %{buildroot}/%{_docdir}/stxxl-1.2.1/
mkdir -p %{buildroot}/%{_docdir}/stxxl-1.2.1/doxy
cp -pr doc/doxy/* %{buildroot}/%{_docdir}/stxxl-1.2.1/doxy
#cp -pr doc/tutorial/tutorial.pdf %{buildroot}/%{_docdir}/stxxl-1.2.1/
#cp -p doc/tutorial/tutorial.dvi %{buildroot}/%{_docdir}/stxxl-1.2.1/
mkdir -p %{buildroot}/%{_docdir}/stxxl-1.2.1/examples/
cp -p doc/tutorial/examples/* %{buildroot}/%{_docdir}/stxxl-1.2.1/examples/
cp -p config_example %{buildroot}/%{_docdir}/stxxl-1.2.1/

and just add

%doc doc/doxy/* doc/tutorial/examples/* config_example

to "%files devel" section. Of course, docs will be installed into %{_docdir}/stxxl-devel-1.2.1/ directory.

* Consider adding README and TROUBLESHOOTING to %doc.

SPEC URL: http://dhd.selfip.com/427e/stxxl-4.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-4.fc10.src.rpm


>* Regarding %install section - you may shorten it a bit by replacing
Done.

> The %build section still doesn't honour %optflags. You should fix your spec in the following way:

I added optflags, but the macro doesn't (on my system) contain -fPIC, therefore removing PIC causes errors when running rpmlint hence I now have

echo "OPT=%{optflags} -fPIC" >> make.settings.local

In any case, duplicate -fPICs are not going to cause any harm when seen by GCC.

>You also don't need to explicitly install doc-files. Just enumerate them in %files section properly.
Doc section updated.


> Consider adding README and TROUBLESHOOTING to %doc.  
Done.

* Sun May 24 2009 <mycae(a!t)yahoo.com> 1.2.1-4
- Used doc macro to install docs previously manually installed
- Added README and TROUBLESHOOTING to docs
- Added otpflags macro to build settings
- Use "install" program rather than cp for the install of lib


RPM Lint:
$ rpmlint -vi  stxxl.spec ../SRPMS/stxxl-1.2.1-4.fc10.src.rpm ../RPMS/i386/stxxl-1.2.1-4.fc10.i386.rpm 
stxxl.src: I: checking
stxxl.i386: I: checking
2 packages and 1 specfiles checked; 0 errors, 0 warnings.

(In reply to comment #2)
> Disabling the latex generation causes all arches to build successfully. 
> 
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=981048  

Within Fedora versions prior to 10 (as well as for all the RedHat/CentOS versions, including EL-5), the Latex package was TeTex, whereas it is now TexLive. An example of how to handle the different packages corresponding to different versions is given in http://rmol.svn.sourceforge.net/viewvc/rmol/trunk/rmol/rmol.spec.in?revision=214&view=markup

Basically, you may use the following:
%if 0%{?fedora} >= 10
BuildArch:      noarch
BuildRequires:  texlive-latex, texlive-dvips
%endif
%if 0%{?fedora} < 10
BuildRequires:  tetex-latex, tetex-dvips
%endif
BuildRequires:  doxygen, ghostscript

Thanks for the pointers. I have re-enabled the latex documentation.

SPEC URL: http://dhd.selfip.com/427e/stxxl-5.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-5.fc10.src.rpm

$ rpmlint -vi  stxxl.spec ../SRPMS/stxxl-1.2.1-5.fc10.src.rpm ../RPMS/i386/stxxl-1.2.1-5.fc10.i386.rpm 
stxxl.src: I: checking
stxxl.i386: I: checking
2 packages and 1 specfiles checked; 0 errors, 0 warnings.

Koji:
F9: http://koji.fedoraproject.org/koji/taskinfo?taskID=1383288
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1383287

[My machine crashed just before I pressed the commit button of the review :( ]

Note that, as I have not the sponsor status, that is not an official review. However, there are a number of issues (some important, some others less) that I can point to you (in no particular order).

1. Doxygen, as it is configured, generates .map files (in the doc/html sub-directory), due to the use of the DOT tool (belonging to the graphviz package). On some configurations (e.g., my Fedora rawhide/11, with rpmbuild), some of those files are generated with a zero-length, which rpmlint then complains of.

There are, at least, two solutions/work-arounds:
  1.a. Just drop the use of DOT in the Doxygen configuration file:
  HAVE_DOT = NO
  as in http://rmol.svn.sourceforge.net/viewvc/rmol/trunk/rmol/doc/doxygen_html.cfg.in?revision=183&view=markup
  As Doxygen replaces with other, simpler, diagrams, that should not be a so big issue.
  1.b. Keep the use of DOT, but:
    - Add a 'BuildRequires: graphivz' directive.
    - Remove any zero-length-map files after the Doxygen generation (http://cvs.fedoraproject.org/viewvc/rpms/asterisk/F-11/asterisk.spec?revision=1.51&view=markup):
      find doc/html -name '*.map' -size 0 -delete

Note that with mock, there is, as is, no zero-length-map-file issue, but the .map files are not generated, due to the missing 'BuildRequires: graphviz' directive. Note also that you can not see that in the build.log (http://koji.fedoraproject.org/koji/getfile?taskID=1383290&name=build.log) of Koji, as you have re-directed the output log of Doxygen into a file removed by mock.

2. Avoid re-directing the output log of Doxygen, so that that log be present in the build.log generated by mock (and Koji):
make doxy > doxymake.log 2> doxymake.stderr
==>
make doxy

3. You may consider creating a separate -doc sub-package for both the HTML Doxygen-generated documentation and the Latex-generated tutorial (https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation).

4. I would rather keep the PDF version of the tutorial, rather than the DVI one. Moreover, we could alter the Makefile so that it generates only the PDF version (which is now the default with latex).

5. In the %files section, you should take ownership of the %{_includedir}/bits directory (https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership):
%dir %{_includedir}/bits/

6. Still in the %files sections, it may be better to use a wildcard for the libraries, as it will still hold for future versions of the library:
%{_libdir}/libstxxl.so.*

7. You may replace instances of stxxl with the %{name} macro, and of 1.2.1 with the %{version} macro (https://fedoraproject.org/wiki/Packaging/Guidelines#Macros). For instance:
---------------------------------------------------
URL:     http://%{name}.sourceforge.net
Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
Patch0:  %{name}-build-shared.patch
Patch1:  %{name}-build-shared-makefile.patch
---------------------------------------------------

x. The build system (makefiles) appears to be very specific to that package, and it may not be portable. For instance, you have to install the files manually yourself in the specification file. If you consider to bring a GNU Autotools environment (and submit the corresponding patch upstream), and if I can help you, do not hesitate.

If it may help, the above comments (plus a few small others) have been integrated into a new version of the specification file:
Spec URL: http://denisarnaud.fedorapeople.org/stxxl/121/6/stxxl.spec
(as well as the corresponding Source RPM: http://denisarnaud.fedorapeople.org/stxxl/121/6/stxxl-1.2.1-6.fc10.src.rpm)

All members of the "packager" group may do official package-reviews and package-approvals.

I agree with all of the changes made in your SRPM, and support its promotion pending review. I suppose this makes you co-maintainer? Do we need another reviewer?

Here are koji builds for the above SRPM, F9 failed, but F10 and F11 are OK. F9 is relatively close to EOL, so I suppose its not a big problem.

F9 : http://koji.fedoraproject.org/koji/taskinfo?taskID=1386757
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1386748
F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1386762

>If you consider to bring a GNU Autotools environment (and submit the >corresponding patch upstream), and if I can help you, do not hesitate.  

I think it is not necessarily a good idea to bring a different build system to STXXL, but instead to help upstream to improve their chosen method. I would hesitate to recommend a change of build sys to upstream, unless they expressed an interest in doing so. For this reason I do not have any plans to do such a thing, unless upstream indicate they would be interested.

In any case, I don't see this as important to this package for this version. Maybe in a newer upstream version after some petitioning...

Hmm I spoke a bit too soon. The use of noarch is causing problems with rpmlint, as noarch is being applied to the main package. If we remove noarch from the -doc section, all is well.

(In reply to comment #12)

> Note that, as I have not the sponsor status, that is not an official review.
> However, there are a number of issues (some important, some others less) that I

Denis, feel free to reassign this ticket to yourself (and, therefore, proceed with reviewing further). As you're a packager, then you may do the formal review (actually, you're almost finished reviewing this package :))

That's fine, if you like, I shall be honoured to go on with the review (thanks Peter and Michael!).

As for the failing build on Fedora 9, I just forgot to enclose the 'BuildArch: noarch' directive within the '%if 0%{?fedora} >= 10 [...] %endif' condition...

It now works well, as Koji shows: http://koji.fedoraproject.org/koji/taskinfo?taskID=1388361

Spec URL: http://denisarnaud.fedorapeople.org/stxxl/121/7/stxxl.spec
(as well as the corresponding Source RPM:
http://denisarnaud.fedorapeople.org/stxxl/121/7/stxxl-1.2.1-7.fc10.src.rpm)

As I have changed only the BuildArch directive, it does not imply any change on Fedora 10, 11 and 12. So, if you agree with that new version, I shall approve the package.

----------------

As for the build system, I proposed to ADD a new one, not to replace the existing one. Hence, (part of) the upstream team may still work with their current building system, if they are happy with it (though I do not understand how they install that library, since there is apparently no such possibility in the current build system!). And an additional GNU Autotools build system would allow (plenty of) other developers to build, install and package in a standard way, without too much maintenance. That is simply what I suggested, and see no reason why the upstream team should be against.

Without such a standard build system, it means that, as the main maintainer of the package, you will have more work every time a new upstream will be released. But, that is my $0.02, and as far as I understand, it should not interfere with Fedora packaging :)
---------------

SPEC URL: http://dhd.selfip.com/427e/stxxl-8.spec
SRPM URL: http://dhd.selfip.com/427e/stxxl-1.2.1-8.fc10.src.rpm

rpmlint:
$ rpmlint stxxl.spec ../SRPMS/stxxl-1.2.1-8.fc10.src.rpm ../RPMS/i386/stxxl-1.2.1-8.fc10.i386.rpm ..//RPMS/i386/stxxl-devel-1.2.1-8.fc10.i386.rpm ../RPMS/i386/stxxl-doc-1.2.1-8.fc10.i386.rpm ../RPMS/i386/stxxl-debuginfo-1.2.1-8.fc10.i386.rpm
5 packages and 1 specfiles checked; 0 errors, 0 warnings.

koji:
F9:http://koji.fedoraproject.org/koji/taskinfo?taskID=1389134
F10:http://koji.fedoraproject.org/koji/taskinfo?taskID=1389156
F11:http://koji.fedoraproject.org/koji/taskinfo?taskID=1389127

I removed the noarch entirely, as my rpm does not support this directive per sub-package, but rather attempts to provide it across all packages. This causes rpmlint to be annoyed about libs in a noarch package.

The wiki says that this feature is coming *soon* but is not here yet, but maybe both it and I are out of date?: https://fedoraproject.org/wiki/Features/NoarchSubpackages

So here is my revision. The only difference from -7 is the removal of the noarch directive.

With regards to the build system, at this time it is more work to make it autoconf friendly than to just keep the current "system" chugging along. Maybe next release :-).

> I removed the noarch entirely, as my rpm does not support this
> directive per sub-package,

It works in Fedora 10 (RPM 4.6.0) and above.

> This causes rpmlint to be annoyed about libs in a noarch package.

rpmlint must be new enough:
https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2946

(In reply to comment #20)
> It works in Fedora 10 (RPM 4.6.0) and above.

Yes, of course, my version (1.2.1-7) works on Fedora 10 and above. I just shows the result of Koji for Fedora 9, as it was the only remaining non-working version.

So, I suggest to keep the version 1.2.1-7 (or to have 1.2.1-9 version identical to the 1.2.1-7). Is that fine for you?

Absolutely fine. Sorry for the fuss.

I updated my rpm tools, and now everything is fine. I was a bit confused by the wiki: "Right now the Fedora infrastructure does not support this feature" but it seems out of date.

I forgot to add a <tab> between the 'BuildArch:' and 'noarch' parts of the 'BuildArch:<tab>noarch' directive, and rpmlint was complaining. So, I have made an 8-th release (where only the <tab> was added):
Spec URL: http://denisarnaud.fedorapeople.org/stxxl/121/8/stxxl.spec
(as well as the corresponding Source RPM:
http://denisarnaud.fedorapeople.org/stxxl/121/7/stxxl-1.2.1-8.fc10.src.rpm)

$ sha1sum stxxl-1.2.1-8.fc10.src.rpm stxxl-1.2.1.tar.gz stxxl-build-*
d04266f98f6e83e4a2307b3c5bc06ed259cf5e49  stxxl-1.2.1-8.fc10.src.rpm
bafa3c065395908e257ae76d19fa6883b374323f  stxxl-1.2.1.tar.gz
6f99ae374c44fe6de98713f26d5b308e2c054d29  stxxl-build-shared-makefile.patch
e0a01a5d7b5633a58f7f0c439df157b2407535ba  stxxl-build-shared.patch

APPROVED

The wiki (https://fedoraproject.org/wiki/Features/NoarchSubpackages) may have to be updated, as it is stated that that feature targets F12 (only). However, since the fix of rpmlint (https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2946 , as mentioned by Michael above), having noarch sub-package does work with Fedora from version above 10. Since the wiki is the description of a feature, the owners (Florian Festi <ffesti> and Jindrich Novy <jnovy>) could maybe be contacted to have them aware of that good news.

New Package CVS Request
=======================
Package Name: stxxl
Short Description: C++ STL drop-in replacement for extremely large datasets
Owners: mycae
Branches: F-9 F-10 F-11
InitialCC:

Also requesting EL-5

New Package CVS Request
=======================
Package Name: stxxl
Short Description: C++ STL drop-in replacement for extremely large datasets
Owners: mycae
Branches: F-9 F-10 F-11 EL-5
InitialCC:

CVS done.

stxxl-1.2.1-9.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/stxxl-1.2.1-9.fc9

stxxl-1.2.1-8.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/stxxl-1.2.1-8.fc10

stxxl-1.2.1-8.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/stxxl-1.2.1-8.fc11

stxxl-1.2.1-8.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update stxxl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6038

stxxl-1.2.1-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update stxxl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-6055

stxxl-1.2.1-9.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update stxxl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-6266

stxxl-1.2.1-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

stxxl-1.2.1-9.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

stxxl-1.2.1-8.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.