Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Review Request: Armadillo - fast C++ matrix library with interface to LAPACK and ATLAS
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Summary: Review Request: Armadillo - fast C++ matrix library with interface to LAPACK and ATLAS Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: conradsand@ieee.org QAContact: extras-qa@fedoraproject.org CC: notting@redhat.com, fedora-package-review@redhat.com Estimated Hours: 0.0 Classification: Fedora
Hello,
This is my first package, and hance I am kindly seeking a sponsor. I'd like to get a review so the package can be included in Fedora.
Spec URL: http://arma.sourceforge.net/fedora/armadillo.spec SRPM URL: http://arma.sourceforge.net/fedora/armadillo-0.5.2-1.src.rpm
Description: Armadillo is a streamlined C++ linear algebra library (matrix maths) aiming towards a good balance between speed and ease of use. Integer, floating point and complex numbers are supported, as well as a subset of trigonometric and statistics functions. Optional integration with LAPACK and ATLAS libraries is also provided. A delayed evaluation approach is employed (during compile time) to combine several operations into one and reduce (or eliminate) the need for temporaries. This is accomplished through recursive templates and template meta-programming. This library is useful if C++ has been decided as the language of choice (due to speed and/or integration capabilities), rather than another language like Octave. It is distributed under a license that is useful in both open-source and commercial contexts.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
blurb conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |conradsand@ieee.org Blocks| |177841(FE-NEEDSPONSOR)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
blurb conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: Armadillo - |Review Request: Armadillo - |fast C++ matrix library |fast C++ matrix library |with interface to LAPACK |with interfaces to LAPACK |and ATLAS |and ATLAS
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Ralf Corsepius rc040203@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rc040203@freenet.de
--- Comment #1 from Ralf Corsepius rc040203@freenet.de 2009-03-11 12:18:21 EDT --- This submission has several issues:
a) Package doesn't honor %{_libdir} (it installs its lib's to /usr/lib on x86_64)
b) Please read (closely related to a)) https://fedoraproject.org/wiki/Packaging:Cmake
c) Split the package into a run-time package and a *-devel package
d) Many of the BuildRequires are redundant (BR: *-devel normally automatically pulls in the corresponding run-time packages)
e) This construct: [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT is being frowned upon in Fedora.
Please use rm -rf $RPM_BUILD_ROOT instead
f) Whether a separate *-doc package is necessary/useful is arguable. Technically, there is no need to have one.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #2 from Conrad Sanderson conradsand@ieee.org 2009-03-11 13:11:40 EDT --- (In reply to comment #1)
Thanks for the feedback -- I will address these issues. I have a further question & clarification with respect to point (c):
c) Split the package into a run-time package and a *-devel package
The library code is entirely in C++ header files, however routines from LAPACK, BLAS and ATLAS are called.
As such there is a convenience component in the form of a dummy run-time library (libarmadillo.so), which simply pulls in the LAPACK, BLAS and ATLAS libraries. The idea is that a user can simply link against libarmadillo.so, rather than individually linking against LAPACK etc.
In other words, the user can do this: g++ -o my_prog my_prog.cpp -larmadillo
instead of a longer: g++ -o my_prog my_prog.cpp -L/usr/lib/atlas -lblas -llapack -llapack_atlas
Hence I am not sure whether splitting the package into run-time and -devel packages is the best way to go. Suggestions ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #3 from Ralf Corsepius rc040203@freenet.de 2009-03-11 13:43:52 EDT --- (In reply to comment #2)
(In reply to comment #1)
In other words, the user can do this: g++ -o my_prog my_prog.cpp -larmadillo
Hence I am not sure whether splitting the package into run-time and -devel packages is the best way to go.
This is a classic devel-package use-case
Suggestions ?
Move the headers and lib*.so into *-devel and let the main-package only contain lib*.x.y.z
BTW: Unless I am mistaken, this package builds its libs stripped. In Fedora, libs are supposed to be built unstripped (rpm strips them later).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #4 from Conrad Sanderson conradsand@ieee.org 2009-03-12 09:36:59 EDT --- (In reply to comment #3)
Move the headers and lib*.so into *-devel and let the main-package only contain lib*.x.y.z
Hello,
I've followed your recommendations and redone the spec file, as well as CMakeLists.txt. %{_libdir} should (hopefully) be honoured.
The updated files are:
Spec URL: http://arma.sourceforge.net/fedora/armadillo.spec SRPM URL: http://arma.sourceforge.net/fedora/armadillo-0.5.3-1.src.rpm
BTW: Unless I am mistaken, this package builds its libs stripped. In Fedora, libs are supposed to be built unstripped (rpm strips them later).
I don't have any explicit stripping, but the output from rpmbuild has these two lines:
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
However, the above messages are amongst other stuff regarding java and python bytecompile, which has nothing to do with this package. If a stripped library build is occuring, is "/brp-strip-static-archive" responsible? If so, how is it turned off ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #5 from Michael Schwendt bugs.michael@gmx.net 2009-03-16 11:33:15 EDT ---
%dir %{_docdir}/%{name}-%{version} %dir %{_docdir}/%{name}-%{version}/docs_user %dir %{_docdir}/%{name}-%{version}/docs_tech %dir %{_docdir}/%{name}-%{version}/examples %{_docdir}/%{name}-%{version}/*.txt %{_docdir}/%{name}-%{version}/index.html %{_docdir}/%{name}-%{version}/docs_user/* %{_docdir}/%{name}-%{version}/docs_tech/* %{_docdir}/%{name}-%{version}/examples/*
Since you create and fill this directory yourself, you can simply replace above lines with this single line:
%{_docdir}/%{name}-%{version}/
The trailing slash is not important, but makes it more explicit that you include a directory recursively.
%dir %{_includedir}/armadillo_bits %{_includedir}/armadillo_bits/*
Same here: %{_includedir}/armadillo_bits/
Requires: atlas, lapack, blas, boost
Examine your built package's list of dependencies (rpm --query --requires ...). If there are automatic dependencies on the atlas/lapack/blas/boost library SONAMEs, drop above explicit Requires from the spec file. We rely on rpmbuild's automatic SONAME dependencies: https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #6 from Conrad Sanderson conradsand@ieee.org 2009-03-24 01:03:55 EDT --- Hello,
There are indeed automatic dependencies on the abovementioned libraries. As such, the spec file has been modified as requested.
The updated files are:
Spec URL: http://arma.sourceforge.net/fedora/armadillo.spec SRPM URL: http://arma.sourceforge.net/fedora/armadillo-0.6.0-1.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #7 from Conrad Sanderson conradsand@ieee.org 2009-03-25 06:07:36 EDT --- (In reply to comment #6)
Updated spec and source RPM for 0.6.1 release:
Spec URL: http://arma.sourceforge.net/fedora/armadillo.spec SRPM URL: http://arma.sourceforge.net/fedora/armadillo-0.6.1-1.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Conrad Sanderson conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-review?
--- Comment #8 from Conrad Sanderson conradsand@ieee.org 2009-05-07 05:42:19 EDT --- (In reply to comment #5)
spec and src rpm updated:
http://arma.sourceforge.net/fedora/armadillo.spec http://arma.sourceforge.net/fedora/armadillo-0.6.10-1.src.rpm
Anyone out there ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Conrad Sanderson conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://arma.sourceforge.net
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Chitlesh GOORAH chitlesh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody@fedoraproject.org |chitlesh@gmail.com
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Chitlesh GOORAH chitlesh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-review? |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Chitlesh GOORAH chitlesh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-review?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Jussi Lehtola jussi.lehtola@iki.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |jussi.lehtola@iki.fi
--- Comment #9 from Jussi Lehtola jussi.lehtola@iki.fi 2009-05-07 08:15:10 EDT --- Chitlesh: are you reviewing the package and sponsoring Conrad?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #10 from Jussi Lehtola jussi.lehtola@iki.fi 2009-05-07 08:19:28 EDT --- A few notes:
- gcc-c++, libstdc++-devel are not needed. First, BR libstdc++-devel is redundant since it's required by gcc-c++, second gcc-c++ is already in the standard kit installed in the buildroot: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2
- Also blas-devel is unnecessary since it's pulled in by lapack-devel.
- The section mkdir -p $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version} cp -r -p README.txt LICENSE.txt index.html examples docs_user docs_tech licenses $RPM_BUILD_ROOT/%{_docdir}/%{name}-%{version} is unnecessary. Just insert %doc README.txt LICENSE.txt index.html examples docs_user docs_tech licenses in the %files section of the main package. Also, note that if the documentation is large, it should be branched in its own package, which may be the case here.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Jussi Lehtola jussi.lehtola@iki.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: Armadillo - |Review Request: armadillo - |fast C++ matrix library |fast C++ matrix library |with interfaces to LAPACK |with interfaces to LAPACK |and ATLAS |and ATLAS
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #11 from Jussi Lehtola jussi.lehtola@iki.fi 2009-05-07 08:30:02 EDT --- Also, you should add %{?dist} to the Release: tag.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Rex Dieter rdieter@math.unl.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rdieter@math.unl.edu
--- Comment #12 from Rex Dieter rdieter@math.unl.edu 2009-05-07 08:55:28 EDT --- Re: comment #9 I can help too (with review/sponsoring) if chitlesh isn't able.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #13 from Chitlesh GOORAH chitlesh@gmail.com 2009-05-07 17:34:49 EDT --- (In reply to comment #9)
Chitlesh: are you reviewing the package and sponsoring Conrad?
Yes, today I've assigned this bug under my name
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #14 from Chitlesh GOORAH chitlesh@gmail.com 2009-05-07 17:53:30 EDT --- #1 (In reply to comment #10)
- Also blas-devel is unnecessary since it's pulled in by lapack-devel.
Conrad, here blas-devel is already required by lapack-devel, you can verify this with
chitlesh $ rpm -qR lapack-devel blas-devel = 3.1.1-4.fc10 <----------- here it is lapack = 3.1.1-4.fc10 liblapack.so.3 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Hence, if it is not important to add it in the spec file. For your next package, use this "rpm -qR XXXX" command to verify where you have unnecessary added redundant dependencies.
#2 verify your rpms there is a package caled "rpmlint". It helps you verify the quality of your rpms. Try rpmlint -i XXXX.rpm for each generated rpms before uploading for review. Any warning or errors should be corrected. The solutions of some common rpmlint warnings are listed on the fedora wiki.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #15 from Conrad Sanderson conradsand@ieee.org 2009-05-07 22:10:07 EDT --- (In reply to comment #10)
A few notes:
- gcc-c++, libstdc++-devel are not needed.
Thanks -- I've removed the explicit build dependencies.
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2
Based on rpm -qR, boost-devel doesn't pull in libstdc++-devel. Armadillo header files certainly need the header files provided by libstdc++-devel, and I'd assume boost-devel would also.
As such, should there be a dependency on libstdc++-devel in the -devel package?
The packaging guidelines only state that gcc-c++ (and hence libstdc++-devel) can be assumed to exist for "BuildRequires". Is this also the case for the "Requires" section ?
Just insert %doc README.txt LICENSE.txt ... in the %files section of the main package.
I've adapted this as follows:
%files ... %doc LICENSE.txt licenses
%files devel ... %doc README.txt index.html examples docs_user docs_tech
The reasoning is that the licensing applies whether or not the header files are present. "README.txt" and "index.html" refer to files which are only present when both the base and -devel package are installed (due to the layout in the original .tar.gz archive).
Also, note that if the documentation is large, it should be branched in its own package, which may be the case here.
I'd prefer to keep it in the -devel package to keep thing simpler, and hence less error prone. (I'd also prefer not to go overboard in splitting packages like Debian does). The documentation goes hand in hand when one does development using this library, so I'm not sure if the added complexity and effort of an extra doc package is worth it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #16 from Conrad Sanderson conradsand@ieee.org 2009-05-20 23:42:16 EDT --- (In reply to comment #14)
The spec file has been improved and the rpms checked through rpmlint. There are two minor warnings:
# rpmlint armadillo-0.6.11-2.fc10.x86_64.rpm armadillo.x86_64: W: unstripped-binary-or-object /usr/lib64/libarmadillo.so.0.6.11 armadillo.x86_64: W: no-documentation 1 packages and 0 specfiles checked; 0 errors, 2 warnings.
# rpmlint armadillo-devel-0.6.11-2.fc10.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
I'm not sure why there is the unstripped-binary-or-object warning. According to Comment #3 (Ralf Corsepius), "In Fedora, libs are supposed to be built unstripped (rpm strips them later)". Is this a problem worth worrying about ?
New spec file and source rpm are located at:
http://arma.sourceforge.net/fedora/armadillo.spec http://arma.sourceforge.net/fedora/armadillo-0.6.11-2.fc10.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #17 from Ralf Corsepius rc040203@freenet.de 2009-05-21 00:09:03 EDT --- (In reply to comment #16)
Comment #3 (Ralf Corsepius), "In Fedora, libs are supposed to be built unstripped (rpm strips them later)". Is this a problem worth worrying about ?
Generally speaking, without having checked details of the current package: Yes, it is a blocker and must be fixed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #18 from Ralf Corsepius rc040203@freenet.de 2009-05-21 01:13:18 EDT --- OK, your debuginfo issue is caused by not passing CXXFLAGS/CFLAGS to cmake, which causes libarmadillo.so.* to be built with inappropriate CFLAGS:
From build.log:
... /usr/bin/c++ -Darmadillo_EXPORTS -fPIC -I/users/corsepiu/src/rpms/BUILD/armadillo-0.6.11/include -o CMakeFiles/armadillo.dir/src/pull_libs.o -c /users/corsepiu/src/rpms/BUILD/armadillo-0.6.11/src/pull_libs.cpp
Note: All mandatory RPM_OPT_FLAGS are missing.
Using %cmake instead of "cmake ..." will likely resolve your issue.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #19 from Chitlesh GOORAH chitlesh@gmail.com 2009-05-21 10:26:54 EDT --- #1: Ralf is right here, use the macro %cmake instead of cmake.
#2: Also before creating the SRPM, change the permissions of both the spec file and the sources to 0644, currently : chitlesh(rpmbuild)[1]$rpmlint /home/chitlesh/rpmbuild/SRPMS/armadillo-0.6.11-2.fc10.src.rpm armadillo.src: W: strange-permission armadillo-0.6.11.tar.gz 0640 armadillo.src: W: strange-permission armadillo.spec 0640
#3: Swap the docs_user and LICENSE.txt from %name-devel to %name as they are user specific.
#4: remove /usr/share/doc/armadillo-devel-0.6.11/examples/Makefile.cmake after make install
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #20 from Conrad Sanderson conradsand@ieee.org 2009-05-22 06:24:58 EDT --- (In reply to comment #18)
Using %cmake instead of "cmake ..." will likely resolve your issue.
I tried this, and rpmlint still generates a warning.
It appears that "/usr/lib/rpm/brp-strip" is supposed to strip the library, however it's not doing its job.
Putting a line like "strip $RPM_BUILD_ROOT/%{_libdir}/*.so*" in the "%install" part seems to fix the warning, however I'm not sure whether this is the most appropriate fix.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #21 from Chitlesh GOORAH chitlesh@gmail.com 2009-05-23 12:31:53 EDT --- My scratch build with %cmake does not seem to have such rpmlint warning http://koji.fedoraproject.org/scratch/chitlesh/task_1368413/
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #22 from Conrad Sanderson conradsand@ieee.org 2009-05-25 04:11:04 EDT --- (In reply to comment #21)
My scratch build with %cmake does not seem to have such rpmlint warning http://koji.fedoraproject.org/scratch/chitlesh/task_1368413/
This is pretty weird.
I have a pretty much stock-standard Fedora 10 installation. The rpm building process (via "rpmbuild -ba armadillo.spec"), causes cmake to install files into "/root/rpmbuild/BUILDROOT/armadillo-0.6.11-4.fc10.x86_64/usr/". Afterwards the following scripts are run:
+ /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-static-archive + /usr/lib/rpm/brp-strip-comment-note
Looking at "/usr/lib/rpm/brp-strip" (as installed on my system), we have this line:
grep -v ' shared object,' | \
... which means it explicitly does not strip shared objects. A more appropriate "/usr/lib/rpm/brp-strip-shared" exists, but this isn't being run (why?)
Comparing your build log for x86_64 against mine, both use CXXFLAGS that contain "-O2 -g". The main differences appear after cmake installs files into $BUILDROOT. Specifically, the following scripts are run:
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/armadillo-0.6.11 extracting debug info from /builddir/build/BUILDROOT/armadillo-0.6.11-2.fc11.x86_64/usr/lib64/libarmadillo.so.0.6.11 symlinked /usr/lib/debug/usr/lib64/libarmadillo.so.0.6.11.debug to /usr/lib/debug/usr/lib64/libarmadillo.so.0.debug symlinked /usr/lib/debug/usr/lib64/libarmadillo.so.0.6.11.debug to /usr/lib/debug/usr/lib64/libarmadillo.so.debug 52 blocks + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars
So what's going on here ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #23 from Chitlesh GOORAH chitlesh@gmail.com 2009-05-26 07:40:08 EDT --- (In reply to comment #20)
(In reply to comment #18)
Using %cmake instead of "cmake ..." will likely resolve your issue.
I tried this, and rpmlint still generates a warning.
Does it ? can you post your SRPM please.
My scratch build for F-10 gives me only these warnings: http://koji.fedoraproject.org/scratch/chitlesh/task_1376830/
chitlesh(~)[0]$ls *.rpm armadillo-0.6.11-2.fc10.i386.rpm armadillo-debuginfo-0.6.11-2.fc10.i386.rpm armadillo-devel-0.6.11-2.fc10.ppc64.rpm armadillo-0.6.11-2.fc10.ppc64.rpm armadillo-debuginfo-0.6.11-2.fc10.ppc64.rpm armadillo-devel-0.6.11-2.fc10.ppc.rpm armadillo-0.6.11-2.fc10.ppc.rpm armadillo-debuginfo-0.6.11-2.fc10.ppc.rpm armadillo-devel-0.6.11-2.fc10.x86_64.rpm armadillo-0.6.11-2.fc10.x86_64.rpm armadillo-debuginfo-0.6.11-2.fc10.x86_64.rpm armadillo-0.6.11-2.fc11.src.rpm armadillo-devel-0.6.11-2.fc10.i386.rpm
chitlesh(~)[0]$rpmlint *.rpm armadillo.i386: W: no-documentation armadillo.ppc64: W: no-documentation armadillo.ppc: W: no-documentation armadillo.x86_64: W: no-documentation armadillo.src: W: strange-permission armadillo-0.6.11.tar.gz 0640 armadillo.src: W: strange-permission armadillo.spec 0640 13 packages and 0 specfiles checked; 0 errors, 6 warnings.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Denis Arnaud denis.arnaud_fedora@m4x.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |denis.arnaud_fedora@m4x.org
--- Comment #24 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-05-28 19:34:06 EDT --- rpmlint complains on the absence of documentation for the non -devel package. I would alter the %file section as per following: %files %defattr(-,root,root,-) %{_libdir}/*.so.* %doc README.txt LICENSE.txt
It effectively duplicates the README.txt and LICENSE.txt files, but I think it is normal to repeat both of those on the two generated packages. The guideline (https://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files) may not be clear enough on that part.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #25 from Jussi Lehtola jussi.lehtola@iki.fi 2009-05-29 04:03:00 EDT --- (In reply to comment #24)
rpmlint complains on the absence of documentation for the non -devel package. I would alter the %file section as per following: %files %defattr(-,root,root,-) %{_libdir}/*.so.* %doc README.txt LICENSE.txt
It effectively duplicates the README.txt and LICENSE.txt files, but I think it is normal to repeat both of those on the two generated packages. The guideline (https://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files) may not be clear enough on that part.
I'd place at least the LICENSE.txt in the main package, since it applies to the main package too. The development documentation, however, should go with -devel (unless it is so big that it should be branched into a separate -doc package).
As the -devel package requires the main package, the documentation of the main package is also available whenever -devel is installed, and thus there is no need to duplicate the file(s).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #26 from Chitlesh GOORAH chitlesh@gmail.com 2009-06-06 15:48:29 EDT --- %doc README.txt LICENSE.txt should only be placed once and preferably on the %{name}/main package. It is not important that all -devel should entail documentation.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #27 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-06-06 15:59:56 EDT --- Conrad, if you are still confronting with unstripped-binary-or-object rpmlint warning, would you check if you have "redhat-rpm-config" surely installed?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #28 from Conrad Sanderson conradsand@ieee.org 2009-06-08 08:45:01 EDT --- (In reply to comment #27)
Conrad, if you are still confronting with unstripped-binary-or-object rpmlint warning, would you check if you have "redhat-rpm-config" surely installed?
Installing "redhat-rpm-config" appears to have fixed the problem -- many thanks!
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #29 from Conrad Sanderson conradsand@ieee.org 2009-06-08 09:33:03 EDT --- (In reply to comment #26)
%doc README.txt LICENSE.txt should only be placed once and preferably on the %{name}/main package. It is not important that all -devel should entail documentation.
I've redone the spec file -- rpmlint now gives no warnings and no errors.
http://arma.sf.net/fedora/armadillo.spec http://arma.sf.net/fedora/armadillo-0.6.11-4.fc10.src.rpm
The -devel package needs to contain all the original text files and documentation, as they are referred to in the upstream README.txt file. The documentation is included here rather than the main package, as it is only required when developing programs that use the library.
The main package contains the library and LICENSE.txt (+ associated license subdir). It didn't make sense to include README.txt in the main package, as it refers to files that are only present in the -devel package.
I believe the package is now ready for inclusion into Fedora -- many thanks to everyone for their help.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #30 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-08 10:14:10 EDT --- You still shouldn't duplicate LICENSE.txt and licenses in the -devel package, as they are already in the main package.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #31 from Conrad Sanderson conradsand@ieee.org 2009-06-08 10:21:38 EDT --- (In reply to comment #30)
You still shouldn't duplicate LICENSE.txt and licenses in the -devel package, as they are already in the main package.
Not including LICENSE.txt in -devel will break the references/links from README.txt and "index.html" (present in the upstream .tar.gz). Including README.txt only makes sense in the -devel package.
Not including LICENSE.txt in the main package will cause rpmlint to give warnings.
Suggestions ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #32 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-08 10:30:12 EDT --- (In reply to comment #31)
(In reply to comment #30)
You still shouldn't duplicate LICENSE.txt and licenses in the -devel package, as they are already in the main package.
Not including LICENSE.txt in -devel will break the references/links from README.txt and "index.html" (present in the upstream .tar.gz). Including README.txt only makes sense in the -devel package.
In this case duplication may be alright, another option is to sed the link to point to %{_datadir}/doc/%{name}-%{version}/LICENSE.txt.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #33 from Conrad Sanderson conradsand@ieee.org 2009-06-08 12:48:08 EDT --- (In reply to comment #32)
In this case duplication may be alright, another option is to sed the link to point to %{_datadir}/doc/%{name}-%{version}/LICENSE.txt.
We have two possible solutions: (1) keep the spec file as is (2) remove "LICENSE.txt" and "licenses" from -devel and add the following lines to the spec file:
%post devel /sbin/ldconfig ln -s %{_docdir}/%{name}-%{version}/LICENSE.txt %{_docdir}/%{name}-devel-%{version}/LICENSE.txt ln -s %{_docdir}/%{name}-%{version}/licenses %{_docdir}/%{name}-devel-%{version}/licenses
%preun devel rm %{_docdir}/%{name}-devel-%{version}/LICENSE.txt rm -r %{_docdir}/%{name}-devel-%{version}/licenses
Solution (2) saves about 43 Kb in disk space, but it's messier (post-install and pre-uninstall scriptlets).
I'd vote for solution (1) as it's cleaner, but I'm also happy to go with (2) if that's what people prefer.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #34 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-08 12:56:24 EDT --- You can also just create the symlinks in the install phase, which is a lot neater than creating them in %post:
%install ... mkdir symlink ln -s %{_datadir}/doc/%{name}-%{version}/LICENSE.txt symlink/ ln -s %{_datadir}/doc/%{name}-%{version}/licenses symlink/
%files devel %doc symlink/*
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #35 from Michael Schwendt mschwendt@gmail.com 2009-06-08 13:03:14 EDT --- rm -rf symlink ; mkdir symlink
as not removing an existing symlink directory would break --short-circuit builds (and especially rpmbuild -bi --short-circuit foo.spec is very helpful).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #36 from Conrad Sanderson conradsand@ieee.org 2009-06-08 13:24:49 EDT --- (In reply to comment #34)
You can also just create the symlinks in the install phase, which is a lot neater than creating them in %post: ...
(In reply to comment #35)
rm -rf symlink ; mkdir symlink
ok, spec file updated with the cleaner solution.
http://arma.sf.net/fedora/armadillo.spec http://arma.sf.net/fedora/armadillo-0.6.11-5.fc10.src.rpm
rpmlint now gives two warnings, but they're just a harmless byproduct:
armadillo-devel.x86_64: W: dangling-symlink /usr/share/doc/armadillo-devel-0.6.11/licenses /usr/share/doc/armadillo-0.6.11/licenses armadillo-devel.x86_64: W: dangling-symlink /usr/share/doc/armadillo-devel-0.6.11/LICENSE.txt /usr/share/doc/armadillo-0.6.11/LICENSE.txt
(just to make it clear to anyone puzzled: as the -devel package is dependant on the main package, the symlinks will always work).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #37 from Chitlesh GOORAH chitlesh@gmail.com 2009-06-09 05:06:29 EDT --- Actually there is no need to include the licenses again in the sub -devel package. as I said in comment #26
Remove these rm -rf symlink; mkdir symlink ln -s %{_docdir}/%{name}-%{version}/LICENSE.txt symlink/ ln -s %{_docdir}/%{name}-%{version}/licenses symlink/
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #38 from Conrad Sanderson conradsand@ieee.org 2009-06-09 05:18:06 EDT --- (In reply to comment #37)
Actually there is no need to include the licenses again in the sub -devel package.
They need to be there, otherwise README.txt and index.html (from upstream archive) refer to stuff that isn't there (i.e. we'd have broken references/links).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #39 from Michael Schwendt mschwendt@gmail.com 2009-06-09 05:34:00 EDT --- Well, sometimes it's worth the little bit of extra effort and install all documentation files into a common %{_docdir}/%{name}-%{version}/ via %install instead of using %doc for subpackages.
[The more subpackages include %doc files, the more docdirs get created. That doesn't help with keeping /usr/share/doc browsable. Some packages with multiple subpackages spread their %doc files over more than four different docdirs.]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #40 from Conrad Sanderson conradsand@ieee.org 2009-06-09 06:09:17 EDT --- (In reply to comment #39)
Well, sometimes it's worth the little bit of extra effort and install all documentation files into a common %{_docdir}/%{name}-%{version}/ via %install instead of using %doc for subpackages.
I concur. Updated:
http://arma.sf.net/fedora/armadillo.spec http://arma.sf.net/fedora/armadillo-0.6.11-6.fc10.src.rpm
rpmlint gives no warnings on the source and binary packages.
(I hope this is the last iteration...)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #41 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-09 06:23:26 EDT --- Now you need to:
- mark the documentation files as %doc
and
- add %dir %{_docdir}/%{name}-%{version}/ to the files of the main package. (I don't think it owns the directory yet.)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #42 from Conrad Sanderson conradsand@ieee.org 2009-06-09 07:13:47 EDT --- (In reply to comment #41)
Now you need to:
- mark the documentation files as %doc
and
- add
%dir %{_docdir}/%{name}-%{version}/ to the files of the main package. (I don't think it owns the directory yet.)
Agreed on "%dir %{_docdir}/%{name}-%{version}/"
However, is %doc guaranteed to always place files into %{_docdir}/%{name}-%{version}/ ?
If not, this is going to conflict with the -devel package which lists the documentation as "%{_docdir}/%{name}-%{version}/README.txt ... "
I can't use %doc for the -devel package, as it's going to create a separate directory. Michael Schwendt (Comment #39) suggested to avoid the use of %doc for the devel package in order to keep everything in one place. If we're using direct file specification instead of %doc in the devel package, why not also do this in the main package ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #43 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-09 07:42:40 EDT --- (In reply to comment #42)
Agreed on "%dir %{_docdir}/%{name}-%{version}/"
However, is %doc guaranteed to always place files into %{_docdir}/%{name}-%{version}/ ?
If not, this is going to conflict with the -devel package which lists the documentation as "%{_docdir}/%{name}-%{version}/README.txt ... "
Nope, it just tags the files as documentation in the RPM database, see: http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
Normally one doesn't use this, but in this case you should.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #44 from Michael Schwendt mschwendt@gmail.com 2009-06-09 07:45:56 EDT --- %doc for absolute paths is just an attribute, whereas for local files it copies them into a subpkg's default docdir (after emptying that docdir). Your %files entries with %{_docdir}/%{name}-%{version} at the front are absolute paths. You can add the %doc attribute to them without problems.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #45 from Conrad Sanderson conradsand@ieee.org 2009-06-09 08:04:39 EDT --- (In reply to comment #43)
Nope, it just tags the files as documentation in the RPM database, see: http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
Normally one doesn't use this, but in this case you should.
ok, done:
http://arma.sf.net/fedora/armadillo.spec http://arma.sf.net/fedora/armadillo-0.6.11-7.fc10.src.rpm
7th time lucky ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Jussi Lehtola jussi.lehtola@iki.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |505154
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #46 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-13 12:16:47 EDT --- 1. The following line: Requires: libstdc++-devel, atlas-devel, lapack-devel, boost-devel should be removed, as the corresponding dependencies are already taken into account by the 'BuildRequires:' line, and as the 'Requires:' dependencies are automatically calculated: https://fedoraproject.org/wiki/Packaging/Guidelines#Requires .
2. I would add a "-f" (force) flag in the following line: rm examples/Makefile.cmake But it may be due to my paranoia :)
3. Since you are the main upstream developer, I would suggest (but that is not at all a Fedora requirement) to burry the header files in a specific directory, resulting, after the installation, into: %{_includedir}/armadillo/armadillo %{_includedir}/armadillo/bits %{_includedir}/armadillo/armadillo_itpp That way, you would have to add the armadillo directory prefix when you include Armadillo headers. For instance: #include <armadillo/bits/Mat_meat.hpp> instead of #include <armadillo_bits/Mat_meat.hpp> But that is only a suggestion!
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #47 from Michael Schwendt mschwendt@gmail.com 2009-06-13 14:14:47 EDT --- Re: Comment 46
Unusual. Typically, explicit Requires for a -devel package are added because building with the -devel package requires files contained within additional -devel packages (e.g. headers which are included by default). At least the Boost headers are included by the files in armadillo-devel -- and there is no pkg-config file and therefore no automatic dependency-chain based on the Requires found in the pkg-config file.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #48 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-13 16:11:03 EDT --- (In reply to comment #47)
Unusual. Typically, explicit Requires for a -devel package are added because building with the -devel package requires files contained within additional -devel packages (e.g. headers which are included by default). At least the Boost headers are included by the files in armadillo-devel -- and there is no pkg-config file and therefore no automatic dependency-chain based on the Requires found in the pkg-config file.
With the version without the 'Requires:' line, after installation of the RPMs, I get: # rpm -qpR armadillo-0.6.11-8.fc10.x86_64.rpm [...] libblas.so.3()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libcblas.so.3()(64bit) libgcc_s.so.1()(64bit) liblapack.so.3()(64bit) liblapack_atlas.so.3()(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit)
# ldd -r /usr/lib64/libarmadillo.so.0.6.11 [...] liblapack_atlas.so.3 => /usr/lib64/atlas/liblapack_atlas.so.3 (0x00007fd825c3a000) libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x00007fd825a1c000) libblas.so.3 => /usr/lib64/atlas/libblas.so.3 (0x00007fd825067000) liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x00007fd8248ab000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fd8245a0000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd824104000) libc.so.6 => /lib64/libc.so.6 (0x00007fd823d91000) libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007fd823b74000) libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007fd8231f4000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007fd822f19000)
Indeed, the Boost libraries are not needed, apparently because the ARMA_USE_BOOST environment variable is not set to true when calling cmake. That way, Armadillo does not use Boost, even when it is present on the building platform. In the header files delivered with the -devel sub-package, Boost is not used as, but through a specific wrapper, namely arma_boost, which does not need Boost when the ARMA_USE_BOOST variable is set to false.
We may try to alter the specification file, so as to define the ARMA_USE_BOOST variable to true. In that case, the RPM building process should detect the dependency on Boost, I guess.
Or did I miss something?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #49 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-13 16:17:40 EDT --- I forgot, following is the version I used: ----------------------------------- Spec URL: http://denisarnaud.fedorapeople.org/armadillo/0611/8/armadillo.spec SRPM URL: http://denisarnaud.fedorapeople.org/armadillo/0611/8/armadillo-0.6.11-8.fc10... -----------------------------------
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #50 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-13 17:01:38 EDT --- The following is an attempt to build with Boost: ----------------------------------- Spec URL: http://denisarnaud.fedorapeople.org/armadillo/0611/9/armadillo.spec SRPM URL: http://denisarnaud.fedorapeople.org/armadillo/0611/9/armadillo-0.6.11-9.fc10... -----------------------------------
Boost is detected by CMake, but it seems that the Boost libraries are still not needed (most of Boost is made of just headers). However, as when ARMA_USE_BOOST is set to true, some Boost headers (e.g., Boost Date-Time) are included, it is indeed required to add the dependency on boost-devel for the -devel sub-package. That is fine.
But, as lapack-devel and blas-devel include only libraries (and not header files), I would exclude the correspondent dependency from the 'Requires:' part. The same way, I would exclude dependency on 'libstdc++-devel'.
So, following is a suggestion for the corresponding part in the RPM specification file: ------------------- # The header files of %{name} include some Boost header files, delivered within # the boost-devel sub-package. However, since there is no dependency on any # Boost library (most of Boost is delivered as header files only), the RPM # building process does not detect that dependency. That dependency must # therefore be added manually. Requires: boost-devel -------------------
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #51 from Conrad Sanderson conradsand@ieee.org 2009-06-14 00:54:50 EDT --- (In reply to comment #46)
- I would add a "-f" (force) flag in the following line:
rm examples/Makefile.cmake
ok
- (...) I would suggest (but that is not at all a Fedora
requirement) to burry the header files in a specific directory, resulting, after the installation, into: %{_includedir}/armadillo/armadillo %{_includedir}/armadillo/bits %{_includedir}/armadillo/armadillo_itpp That way, you would have to add the armadillo directory prefix when you include Armadillo headers. For instance: #include <armadillo/bits/Mat_meat.hpp>
The files from the "armadillo_bits" directory are never directly included by the user (it wouldn't work). Instead, the user includes only one file, i.e. #include <armadillo> which then includes everything from "armadillo_bits".
(In reply to comment #50)
... But, as lapack-devel and blas-devel include only libraries (and not header files), I would exclude the correspondent dependency from the 'Requires:' part.
I see what you're getting at, but I'm not totally clear on this. Users will be linking their armadillo programs with -larmadillo, which in turn should automatically pull in the lapack and blas libraries. However, aren't "/usr/lib/liblapack.so" and "/usr/lib/libblas.so" required for this to work? (they're present in lapack-devel and blas-devel).
The same way, I would exclude dependency on 'libstdc++-devel'.
Armadillo explicitly needs the header files from "libstdc++-devel", unless we can assume that a c++ compiler will always be installed ? (I didn't want to make a dependency on gcc-c++, as people may possibly want to use another compiler).
So, following is a suggestion for the corresponding part in the RPM specification file:
# The header files of %{name} include some Boost header files, delivered within # the boost-devel sub-package. However, since there is no dependency on any # Boost library (most of Boost is delivered as header files only), the RPM # building process does not detect that dependency. That dependency must # therefore be added manually. Requires: boost-devel
ok.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #52 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-14 02:24:34 EDT --- (In reply to comment #51)
(In reply to comment #50)
... But, as lapack-devel and blas-devel include only libraries (and not header files), I would exclude the correspondent dependency from the 'Requires:' part.
I see what you're getting at, but I'm not totally clear on this. Users will be linking their armadillo programs with -larmadillo, which in turn should automatically pull in the lapack and blas libraries. However, aren't "/usr/lib/liblapack.so" and "/usr/lib/libblas.so" required for this to work? (they're present in lapack-devel and blas-devel).
The armadillo library is linked against blas and lapack, this is picked up by rpm which adds dependencies on the soname'd libraries as Denis said in #48. One doesn't need blas-devel and lapack-devel to use armadillo, just blas and lapack which are automatically pulled in.
The same way, I would exclude dependency on 'libstdc++-devel'.
Armadillo explicitly needs the header files from "libstdc++-devel", unless we can assume that a c++ compiler will always be installed ? (I didn't want to make a dependency on gcc-c++, as people may possibly want to use another compiler).
This, on the other hand I'd keep, since nothing picks this up automatically.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #53 from Michael Schwendt mschwendt@gmail.com 2009-06-14 04:07:02 EDT --- Re: comment #48
With the version without the 'Requires:' line, after installation of the RPMs, I get: # rpm -qpR armadillo-0.6.11-8.fc10.x86_64.rpm
Since you suggested to delete "Requires" lines from the armadillo-devel (!) subpackage, you need to query the armadillo-devel package, not the main one.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #54 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-14 06:24:08 EDT --- (In reply to comment #51)
Armadillo explicitly needs the header files from "libstdc++-devel", unless we can assume that a c++ compiler will always be installed ? (I didn't want to make a dependency on gcc-c++, as people may possibly want to use another compiler).
As stated on https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 , there is no need to explicitly set a dependency on gcc-c++ . And, if we have a look at the specification file of gcc (generating the gcc-c++ sub-package: http://cvs.fedoraproject.org/viewvc/rpms/gcc/F-11/gcc.spec?revision=1.49&...), we see that the gcc-c++ gets an explicit dependency on libstdc++-devel package: %package c++ Summary: C++ support for GCC Group: Development/Languages Requires: gcc = %{version}-%{release} Requires: libstdc++ = %{version}-%{release} Requires: libstdc++-devel = %{version}-%{release}
And that seems normal to me, as anyone developing in C++ would like to be able to use the STL (and, hence, the STL header files).
So, to recap, I would just list boost-devel within the 'Requires:' dependency, and add the result of that discussion within the Wiki (for example by adding an "Exception" sub-section to https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires, but I have not the right to alter that page).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #55 from Conrad Sanderson conradsand@ieee.org 2009-06-14 07:15:24 EDT --- (In reply to comment #54)
there is no need to explicitly set a dependency on gcc-c++ ... So, to recap, I would just list boost-devel within the 'Requires:' dependency, and add the result of that discussion within the Wiki
The intent was never to put a dependency on gcc-c++, but specifically only on libstdc++-devel. Jussi Lehtola (comment #52) seems to agree with this.
According to http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 "There is no need to include the following packages or their dependencies as BuildRequires", followed by a list which includes gcc-c++.
However, these exceptions are for "BuildRequires" and not "Requires". So we can't assume that gcc-c++ is installed on the user's machine, and hence we can't assume that libstc++-devel is installed.
It can be stated that Armadillo is not usable without a C++ compiler, however we leave the choice of the compiler upto the user. The question is whether libstdc++-devel is specific to g++, or whether it can be used by other compilers (including g++ derivatives). If it can be used by other compilers, I'd prefer to have the "Requires" as follows for armadillo-devel:
Requires: boost-devel, libstdc++-devel
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #56 from Chitlesh GOORAH chitlesh@gmail.com 2009-06-14 07:26:32 EDT --- (In reply to comment #46)
- The following line:
Requires: libstdc++-devel, atlas-devel, lapack-devel, boost-devel should be removed, as the corresponding dependencies are already taken into account by the 'BuildRequires:' line, and as the 'Requires:' dependencies are automatically calculated: https://fedoraproject.org/wiki/Packaging/Guidelines#Requires .
Aren't you confused here ? The Requires is for the -devel package and not for the main package.
Denis, I would appreciate in the future, if you could just post the lines what need attention rather a separate SRPM. I nearly mistook your spec for the review.
The package from my point of view is fine. Any objection before I approve it ? http://arma.sf.net/fedora/armadillo-0.6.11-7.fc10.src.rpm
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #57 from Chitlesh GOORAH chitlesh@gmail.com 2009-06-14 07:41:39 EDT --- Conrad what is your FAS username ? I'll use it to sponsor you.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #58 from Conrad Sanderson conradsand@ieee.org 2009-06-14 08:13:11 EDT --- (In reply to comment #57)
Conrad what is your FAS username ? I'll use it to sponsor you.
Thanks. FAS username sent to your email
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #59 from Michael Schwendt mschwendt@gmail.com 2009-06-14 08:17:48 EDT --- Re: comment #55
No, that's a misinterpretation of the guidelines. The spec file's BuildRequires become the src.rpm's Requires. The gcc-c++ package is mandatory in the "development-tools" as well as "buildsys-build" comps groups. And in turn libstdc++-devel is assumed to be available, too, and need not be specified as a Requires/BuildRequires in any package.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #60 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-14 08:48:29 EDT --- (In reply to comment #56)
The package from my point of view is fine. Any objection before I approve it ? http://arma.sf.net/fedora/armadillo-0.6.11-7.fc10.src.rpm
IMO the Requires: atlas-devel, lapack-devel of armadillo-devel are probably unnecessary. If one builds with g++ -larmadillo not with g++ -llapack -latlas -larmadillo then one doesn't need atlas-devel or lapack-devel and these can be safely dropped, since armadillo acts as a wrapper for the atlas and lapack libraries.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #61 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-14 17:29:06 EDT --- (In reply to comment #60, comment #59 and comment #56)
1. Thanks Michael for having shed light on this: that was what I was trying to say, but less successfully :)
2. OK, Chitlesh, I will not interfere with my own versions (which I use when reviewing packages), but will only suggest simple alterations. You are right, that's cleaner.
3.
IMO the Requires: atlas-devel, lapack-devel of armadillo-devel are probably unnecessary. If one builds with g++ -larmadillo not with g++ -llapack -latlas -larmadillo then one doesn't need atlas-devel or lapack-devel and these can be safely dropped, since armadillo acts as a wrapper for the atlas and lapack libraries.
https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRequires properly states "It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its configure script detects that libpng is not installed." And, in the Armadillo CMake configure script (CMakeLists.txt), the following excerpt: ----------------------------- IF(LAPACK_FOUND) SET(ARMA_USE_LAPACK true) ENDIF(LAPACK_FOUND)
IF(BLAS_FOUND) SET(ARMA_USE_BLAS true) ENDIF(BLAS_FOUND)
IF(Boost_FOUND) IF(Boost_MAJOR_VERSION GREATER 0) IF(Boost_MINOR_VERSION GREATER 33) SET(ARMA_USE_BOOST true) ENDIF(Boost_MINOR_VERSION GREATER 33) ENDIF(Boost_MAJOR_VERSION GREATER 0) ENDIF(Boost_FOUND) ----------------------------- suggests that, if Lapack, Blas and/or Boost are not found, then they are not used (and probably replaced by internal/workaround code). Hence, they should be listed as dependencies... of the building process, i.e., as 'BuildRequires:'.
And, as mentioned by Michael, boost-devel should be present in the 'Requires:' line as well, as most of Boost is delivered as header files only, which cannot be detected properly by the building process scripts.
In summary, we would have: -------------- BuildRequires: cmake, atlas-devel, lapack-devel, boost-devel %package devel # Comment justifying the use of a 'Requires:' line Requires: boost-devel --------------
Is that fine? Or did I miss something?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #62 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-15 02:10:06 EDT --- (In reply to comment #61)
In summary, we would have:
BuildRequires: cmake, atlas-devel, lapack-devel, boost-devel %package devel # Comment justifying the use of a 'Requires:' line Requires: boost-devel
Is that fine? Or did I miss something?
No, you missed boost-devel which is needed if armadillo headers use boost classes / something else only available in the boost header files.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #63 from Conrad Sanderson conradsand@ieee.org 2009-06-15 04:17:18 EDT --- (In reply to comment #60)
IMO the Requires: atlas-devel, lapack-devel of armadillo-devel are probably unnecessary. If one builds with g++ -larmadillo not with g++ -llapack -latlas -larmadillo then one doesn't need atlas-devel or lapack-devel and these can be safely dropped, since armadillo acts as a wrapper for the atlas and lapack libraries.
Agreed to omitting lapack-devel.
However, we need atlas-devel. Atlas headers are included by Armadillo headers. (line 85 of upstream include/armadillo, where a workaround for Ubuntu and other systems is present).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #64 from Conrad Sanderson conradsand@ieee.org 2009-06-15 04:35:00 EDT --- Updated spec and SRPM:
http://arma.sf.net/fedora/armadillo.spec http://arma.sf.net/fedora/armadillo-0.6.11-8.fc10.src.rpm
Spec file summary:
main package: BuildRequires: cmake, boost-devel, lapack-devel, atlas-devel
devel package: Requires: boost-devel, atlas-devel (and a note explaining why they're needed)
install section: rm -f examples/Makefile.cmake
I think these satisfy everyone's concerns.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #65 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-15 15:50:44 EDT --- The following shows that both lapack-devel and blas-devel contain only symbolic links on libraries and static libraries, but no header files: ---------------------------------------- $ rpm -ql lapack-devel /usr/lib64/liblapack.a /usr/lib64/liblapack.so /usr/lib64/liblapack_pic.a $ rpm -ql blas-devel /usr/lib64/libblas.a /usr/lib64/libblas.so ----------------------------------------
So, if I am not mistaken, armadillo-devel does not need to list those development packages in the 'Requires:' statement. Of course, they are needed when building the Armadillo packages, but not any longer after that (they are not needed by someone wanting to develop with armadillo-devel).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #66 from Jussi Lehtola jussi.lehtola@iki.fi 2009-06-15 16:09:12 EDT --- Whoa, this review is unusually long. A lot of static, though.
(In reply to comment #65)
The following shows that both lapack-devel and blas-devel contain only symbolic links on libraries and static libraries, but no header files:
clip
So, if I am not mistaken, armadillo-devel does not need to list those development packages in the 'Requires:' statement. Of course, they are needed when building the Armadillo packages, but not any longer after that (they are not needed by someone wanting to develop with armadillo-devel).
And they are not, as you could have seen in #64. The only packages required by -devel are boost-devel and atlas-devel, which both contain headers that are used by the armadillo headers. libstdc++-devel should probably be required too.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #67 from Denis Arnaud denis.arnaud_fedora@m4x.org 2009-06-16 05:40:25 EDT --- (In reply to comment #66)
And they are not, as you could have seen in #64. The only packages required by -devel are boost-devel and atlas-devel, which both contain headers that are used by the armadillo headers.
Sorry, it was my mistake: I read blas-devel instead of atlas-devel!
So, that is fine for me with boost-devel and atlas-devel. Moreover, as stated in comment #59 by Michael, "libstdc++-devel is assumed to be available, too, and need not be specified as a Requires/BuildRequires in any package".
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #68 from Conrad Sanderson conradsand@ieee.org 2009-06-21 01:19:21 EDT --- (In reply to comment #67)
So, that is fine for me with boost-devel and atlas-devel. Moreover, as stated in comment #59 by Michael, "libstdc++-devel is assumed to be available, too, and need not be specified as a Requires/BuildRequires in any package".
ok, I take it to mean the package is now all okay by everyone.
Chitlesh, what are your thoughts on approval ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #69 from Chitlesh GOORAH chitlesh@gmail.com 2009-07-05 08:42:17 EDT --- Give me your latest spec & srpm, I'll do a full review.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #70 from Conrad Sanderson conradsand@ieee.org 2009-07-05 23:07:43 EDT --- (In reply to comment #69)
Give me your latest spec & srpm, I'll do a full review.
http://arma.sourceforge.net/fedora/armadillo.spec http://arma.sourceforge.net/fedora/armadillo-0.6.12-1.fc10.src.rpm
rpmlint reports no errors and no warnings on the .src.rpm
Upon generation of the binary packages, there is only one very minor warning on "armadillo-devel-0.6.12-1.fc10.x86_64.rpm":
armadillo-devel.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/armadillo-0.6.12/README.txt
This is due to DOS end-of-line encoding used for that file (alone) in the upstream package. The DOS encoding was specifically used so the README file is readable using the brain-damaged Notepad under Windows (which is the default program for opening text files).
Under Linux, the DOS end-of-line encoding has no ill effects for all practical purposes. The file is viewed without any problems using viewers/editors such as "more", "less", "gedit", "kwrite", "nano", etc.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #71 from Jussi Lehtola jussi.lehtola@iki.fi 2009-07-06 03:46:32 EDT --- (In reply to comment #70)
Upon generation of the binary packages, there is only one very minor warning on "armadillo-devel-0.6.12-1.fc10.x86_64.rpm":
armadillo-devel.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/armadillo-0.6.12/README.txt
This is due to DOS end-of-line encoding used for that file (alone) in the upstream package. The DOS encoding was specifically used so the README file is readable using the brain-damaged Notepad under Windows (which is the default program for opening text files).
Under Linux, the DOS end-of-line encoding has no ill effects for all practical purposes. The file is viewed without any problems using viewers/editors such as "more", "less", "gedit", "kwrite", "nano", etc.
Still, you need to fix it. This is quite trivial: run
for file in README; do sed 's/\r//' $file >$file.new && \ touch -r $file $file.new && \ mv $file.new $file done
in the %setup phase to convert it.
(If you try catting the file it doesn't work properly.)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #72 from Conrad Sanderson conradsand@ieee.org 2009-07-06 04:06:30 EDT --- (In reply to comment #71)
Still, you need to fix it. This is quite trivial: run (...) in the %setup phase to convert it.
Can do this, or how about just "dos2unix" ? Seems less hassle than embedding a shell script.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #73 from Jussi Lehtola jussi.lehtola@iki.fi 2009-07-06 04:14:11 EDT --- Well, you can do just a sed oneliner sed -i 's/\r//' README but this loses the time stamp. Same with dos2unix. That's why it's best to use the former version.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #74 from Chitlesh GOORAH chitlesh@gmail.com 2009-07-06 04:16:12 EDT ---
https://fedoraproject.org/wiki/Common_Rpmlint_issues#wrong-file-end-of-line-...
Use the fix Jussi gave, as it preserves timestamps.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #75 from Michael Schwendt mschwendt@gmail.com 2009-07-06 04:40:48 EDT --- You can tell dos2unix/unix2dos to preserve the timestamp, too.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #76 from Chitlesh GOORAH chitlesh@gmail.com 2009-07-06 04:44:59 EDT --- Let's stick to the Fedora packaging guidelines's equivalent, for consistency.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #77 from Conrad Sanderson conradsand@ieee.org 2009-07-06 05:18:00 EDT --- (In reply to comment #74)
Use the fix Jussi gave, as it preserves timestamps.
Done.
http://arma.sourceforge.net/fedora/armadillo.spec http://arma.sourceforge.net/fedora/armadillo-0.6.12-2.fc10.src.rpm
rpmlint reports no errors on any of the rpms (source and binary)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Chitlesh GOORAH chitlesh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-review? |fedora-review+
--- Comment #78 from Chitlesh GOORAH chitlesh@gmail.com 2009-07-06 11:35:52 EDT --- - MUST: The package is named according to the Package Naming Guidelines. - MUST: The spec file name matches the base package %{name} - MUST: The package meets the Packaging Guidelines. - MUST: The package is licensed (LGPLv3+) with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines. - MUST: The License field in the package spec file matches the actual license. - MUST: 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 is included in %doc. - MUST: The spec file must be written in American English. - MUST: The spec file for the package is be legible. - MUST: The sources used to build the package must matches the upstream source, as provided in the spec URL. - MUST: The package successfully compiles and builds into binary rpms on at least i386. - MUST: All build dependencies is listed in BuildRequires. - MUST: The spec file handles locales properly. - MUST: If the package does not contain shared library files located in the dynamic linker's default paths - MUST: the package is not designed to be relocatable - MUST: the package owns all directories that it creates. - MUST: the package does not contain any duplicate files in the %files listing. - MUST: Permissions on files are set properly. - MUST: The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). - MUST: The package consistently uses macros, as described in the macros section of Packaging Guidelines. - MUST: The package contains code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines. - MUST: There are no Large documentation files - MUST: %doc does not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. - MUST: There are no Header files or static libraries - MUST: The package does not contain library files with a suffix - MUST: Package does NOT contain any .la libtool archives - MUST: Package containing GUI applications includes a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. - MUST: Package does not own files or directories already owned by other packages
SHOULD Items:
- SHOULD: The source package does include license text(s) as LICENSE.txt - SHOULD: mock builds succcessfully in i386. - SHOULD: The reviewer tested that the package functions as described. A package should not segfault instead of running, for example. - SHOULD: No scriptlets were used, those scriptlets must be sane. - SHOULD: No subpackages present.
APPROVED
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #79 from Chitlesh GOORAH chitlesh@gmail.com 2009-07-06 11:37:55 EDT --- Complete the packaging process as from "Add_Package_to_CVS_and_Set_Owner" section
https://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_CVS_an...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Chitlesh GOORAH chitlesh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|177841(FE-NEEDSPONSOR), | |505154 |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Conrad Sanderson conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs?
--- Comment #80 from Conrad Sanderson conradsand@ieee.org 2009-07-07 22:14:02 EDT --- New Package CVS Request ======================= Package Name: armadillo Short Description: fast C++ matrix library with interfaces to LAPACK and ATLAS Owners: conrads Branches: F-10 F-11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Conrad Sanderson conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|low |medium
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
--- Comment #81 from Jason Tibbitts tibbs@math.uh.edu 2009-07-08 12:31:38 EDT --- CVS done.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #82 from Fedora Update System updates@fedoraproject.org 2009-07-10 00:27:33 EDT --- armadillo-0.6.12-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/armadillo-0.6.12-2.fc10
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #83 from Fedora Update System updates@fedoraproject.org 2009-07-10 00:43:16 EDT --- armadillo-0.6.12-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/armadillo-0.6.12-2.fc11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |ON_QA
--- Comment #84 from Fedora Update System updates@fedoraproject.org 2009-07-16 03:20:26 EDT --- armadillo-0.6.12-2.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 armadillo'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7645
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #85 from Fedora Update System updates@fedoraproject.org 2009-07-16 03:36:10 EDT --- armadillo-0.6.12-2.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 armadillo'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7695
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #86 from Fedora Update System updates@fedoraproject.org 2009-08-01 19:57:16 EDT --- armadillo-0.6.12-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version| |0.6.12-2.fc10 Resolution| |ERRATA
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #87 from Fedora Update System updates@fedoraproject.org 2009-08-01 20:01:18 EDT --- armadillo-0.6.12-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|0.6.12-2.fc10 |0.6.12-2.fc11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
Conrad Sanderson conradsand@ieee.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs+ |fedora-cvs?
--- Comment #88 from Conrad Sanderson conradsand@ieee.org 2010-07-15 04:24:34 EDT --- Package Change Request ====================== Package Name: armadillo New Branches: EL-6 Owners: conrads
version 0.9.52 is mature enough to be part of EPEL
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #89 from Kevin Fenzi kevin@tummy.com 2010-07-16 13:26:53 EDT --- CVS done (by process-cvs-requests.py).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #90 from Jussi Lehtola jussi.lehtola@iki.fi 2011-01-23 10:18:40 EST --- Might you be bothered to build for EL5 as well? The rawhide spec builds as is...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=489686
--- Comment #91 from C Sand conradsand.fb@gmail.com 2011-01-25 03:13:18 EST --- (In reply to comment #90)
Might you be bothered to build for EL5 as well? The rawhide spec builds as is...
I don't have access to a RHEL 5 machine, so can't test the library properly.
The run-time component might build as is, but that doesn't really test the internals (as Armadillo is a template library). The run-time component is just an alias for LAPACK + BLAS + ATLAS + etc.
Also, I don't know what version of GCC is in RHEL 5. The library was only tested with 4.2, 4.3 and 4.4. It should work with 4.0 and 4.1, but I don't have the time to incorporate possible workarounds for earlier compilers (the library hits templates pretty hard).
I also don't know what version of ATLAS is in RHEL 5. Anything earlier than 3.8 is full of bugs.
package-review@lists.fedoraproject.org