Bug 254091

rpmlint gave me
W: libsvm mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 11)
The specfile mixes use of spaces and tabs for indentation, which is a
cosmetic annoyance.  Use either spaces or tabs for indentation, not both.

W: libsvm wrong-file-end-of-line-encoding /usr/share/doc/libsvm-2.84/FAQ.html
This file has wrong end-of-line encoding, usually caused by creation or
modification on a non-Unix system. It could prevent it from being displayed
correctly in some circumstances.

*** Bug 254099 has been marked as a duplicate of this bug. ***

Issue addressed in Comment #1 fixed.
New SPEC: http://dchen.fedorapeople.org/files/rpms/libsvm.spec
New SRPM: http://dchen.fedorapeople.org/files/rpms/libsvm-2.84-1.fc7.src.rpm

Changed: 
- Fix rpmlint error
- Move python related files to libsvm-python

New Package CVS Request
=======================
Package Name: scim-array
Short Description: 3D Game of Foo
Owners: dchen
Branches: F-7 EL-5
InitialCC: dchen
Cvsextras Commits: yes

New SPEC: http://dchen.fedorapeople.org/files/rpms/libsvm.spec
New SRPM: http://dchen.fedorapeople.org/files/rpms/libsvm-2.84-2.fc7.src.rpm

Changed: 
- Fix mock error
- Support Python 2.4 and Python 2.5

Sorry for the Comment #4, one shouldn't make important decision when he has a 
running nose.

missing following guidelines
- MUST: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency: Requires: %{name} =
%{version}-%{release} 

New SPEC: http://dchen.fedorapeople.org/files/rpms/libsvm.spec
New SRPM: http://dchen.fedorapeople.org/files/rpms/libsvm-2.84-2.fc7.src.rpm

Changed: 
- Issue raised in Comment #6 fixed.

New SPEC: http://dchen.fedorapeople.org/files/rpms/libsvm.spec
New SRPM: http://dchen.fedorapeople.org/files/rpms/libsvm-2.84-3.fc7.src.rpm

Changed: 
- Issue raised in Comment #6 fixed.

Review:
+ package builds in mock (development i386).
+ rpmlint is silent for SRPM and RPM.
+ source files match upstream.
a7bd21b21510e9634950715c2b4a4ce9  libsvm-2.84.tar.gz
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible.
+ License text is included in package.
+ %doc files present.
+ BuildRequires are proper.
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code.
+ no static libraries.
+ no .pc file present.
+ -devel subpackage exists.
+ no .la files.
+ no translations are available.
+ Does owns the directories it creates.
+ no duplicates in %files.
+ file permissions are appropriate.
+ no scriptlets are used.
+ libsvm package
   Requires: glibc libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libm.so.6 libm.so.6(GLIBC_2.0)
libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4) rtld(GNU_HASH)
+ libsvm-devel package
  Provides: perl(libsvm)
  Requires: glibc libsvm = 2.84-3.fc8
+ libsvm-python package
  Provides: svmc.so
  Requires: /usr/bin/env libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3) libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libm.so.6
libm.so.6(GLIBC_2.0) libstdc++.so.6 libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4) libsvm = 2.84-3.fc8 python >= 2.4 python(abi) = 2.5
rtld(GNU_HASH)
+ Not a GUI app.

APPROVED.

New Package CVS Request
=======================
Package Name: libsvm, libsvm-devel libsvm-python
Short Description: A Library for Support Vector Machines
Owners: dchen
Branches: F-7
InitialCC: dchen
Cvsextras Commits: yes

cvs done. 

This one is mispackaged.

1) Note that %{_datadir}/libsvm/ is not included.

2) Note that %{_libdir}/java/libsvm/ is not included.

3) Note how %_libdir/libsvm/ is included in the -devel
package, while the two DSO files within it are also
included in the main package.

%files
[...]
%{_libdir}/libsvm/libsvm.so
%{_libdir}/libsvm/libsvm.so.2.84

%files devel
[...]
%{_libdir}/libsvm

4) Drop "Requires: glibc".

5) Drop "Requires: python ...", because rpmbuild adds the
python(abi) requirement automatically.

6) What is /usr/share/libsvm/src in the -devel package?

7) Creation of the DSO with non-versioned SONAME libsvm.so but
also a versioned library outside run-time linker's search path
is questionable. Where is this customisation explained?

8) What in the "libsvm-devel" package "Requires: libsvm"?

Do we need to have further mispackaging reported in same bugzilla? I guess I
approved libsvm-2.84-3.fc7.src.rpm this SRPM. And the issues 2,3,7,8 reported to
by you was not in approved SPEC in this package review.

dchen,
  Can you please package issues reported by Michael correctly?

2.84-4.fc7 and 2.84-3.fc7 contain a subset of the problems, and
additional bugs not found in this review, e.g. missing %defattr
in sub-packages. It got worse in later releases.

libsvm-2.84-7.fc7 has been pushed to the Fedora 7 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 libsvm'

libsvm-2.84-7.fc8 has been pushed to the Fedora 8 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 libsvm'

I checked new version libsvm-2.84-8.fc9
1) found that Compiler flags are not honored 
2) still there is /usr/share/libsvm/src included in -devel package.
  => For /usr/share/libsvm/src issue maintainer commented in %files section that
its needed for developers in -devel package.
3) use ldconfig scriptlet as simple as
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

Michael,
  Your review for this updated package please?

> %define temp_file /tmp/python.ver
> %define python_version %(python -V 2> %{temp_file} ; 
> cat %{temp_file} | awk 'BEGIN {FS= "[ .]"}
> {printf("%s.%s",$2,$3)}'; rm -f %{temp_file})

This would be just a one-liner:
%{!?pyver: %define pyver %(python -c 'import sys; print(sys.version[0:3])')}

But that version is not needed anywhere, because:

> %define libsvm_python_dir 
> %{_libdir}/python%{python_version}/site-packages/libsvm

The Python arch-specific modules path is:
%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

Use that value to build the  %{python_sitearch}/libsvm  path.


> BuildRequires:  glibc-devel 

Redundant. Implicit. Part of our minimal build chroot.


> %build
> make all DESTDIR=%{_builddir} LIBDIR=%{_libdir}

"rpm --eval %{_builddir}" returns a path no %build procedure
ought to see, because the value might find its way into
build files. Setting it in %build is wrong. If DESTDIR can't
be undefine in %build, revise your Makefile patch.


> %post 
> /sbin/ldconfig   -n %{_libdir}

Please read "man ldconfig" about what option -n does.
Running it like that in %post is wrong.


Re: comment 18

> 3) use ldconfig scriptlet as simple as
> %post -p /sbin/ldconfig
> %postun -p /sbin/ldconfig

Correct.


> For /usr/share/libsvm/src issue maintainer commented
> in %files section that its needed for developers in -devel
> package.

The .java files maybe. But not the binaries' C source files,
headers and Makefiles.

dchen,
 can you please update the package with fixes asked in above comment?

Just one curious question.

If we do need to put source C codes in some convient place, which package should
I include these sources?

Another question about %post and %postun

When doing:
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
rpm -e libsvm reports:
/sbin/ldconfig: relative path `0' used to build cache
error: %postun(libsvm-2.84-9.fc8.x86_64) scriptlet failed, exit status 1

But, it passed when I wrote like:
%post

/sbin/ldconfig



#%postun -p /sbin/ldconfig

%postun

/sbin/ldconfig

What format should I use?

C source files would belong into the -devel package as either
%doc files or in %_datadir. Where exactly to put them depends
on how they are integrated with the rest of the package (e.g. m4
scripts). In your case, however, you included the source of the
executables built into /usr/bin. That's strange.

> /sbin/ldconfig: relative path `0' used to build cache

Then you had junk (e.g. '#' comment lines) directly after a
scriptlet section in your spec file and it was added as the
scriptlet body.

> What format should I use?

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

It is because source codes provide better details of actual meanings of
parameters. Indeed, the API info is provided in README, but it is not as clear
as source code. So for me, it is very convenient to install sources as references.

However, if there is rules about RPM packages, well, I can always get these
sources from tar.gz.


>> What format should I use?
>
>%post -p /sbin/ldconfig
>%postun -p /sbin/ldconfig

Thanks

libsvm-2.84-9.fc7 has been pushed to the Fedora 7 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 libsvm'

libsvm-2.84-9.fc8 has been pushed to the Fedora 8 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 libsvm'

Michael,
   If you are happy with changes done in this package, Can you CLOSE this ticket?

%pyver is defined two times.

Package Change Request
======================
Package Name: libsvm
New Branches: EL-5
Owners: dchen

CVS done.