Re: ITR: libitpp (updated package)
On 02/07/07, Neil Williams wrote:
Minor problems:
1. libittp6 describes itself as:
C++ signal processing and communication library: Debug symbols
which is the same as libittp6-dbg:
C++ signal processing and communication library: Debug symbols
Remove the ": Debug symbols" from the description of libitpp6.
:-)
Minor problems, but major goof offs! Sorry! I'll prepare new packages tomorrow.
2. debian/changelog: experimental. I'm just checking - is this version
to be uploaded to experimental or is this a hangover from the previous
version? Change to unstable?
Well, the situation is like this: the current stable is now "phased
out" and only bug fixes are made. 3.99 is the "development" version
which is going to become the next "in thing". Do you suggest taking it
to unstable? In that case, I can ignore the older stable one and track
only the current one.
3. You need a debian/libittp-doc.doc-base file, including things like:
Document: ...
Title: ...
Author: ...
Abstract: <short abstract>
<long version>
[snip]
libittp-doc should be Section: doc and Architecture: all because it
[snip]
I'll do this as well.
Hmm. The pbuilder log still shows gcc-3.4 being installed. You appear
to build depend on two different fortran packages:
refblas3-dev Fortran 77 reference implementation
lapack3-dev library of linear algebra routines 3
lapack3 Depends on libg2c0 (>= 1:3.4.4-5) which brings in gcc-3.4
again. lapack3 is also an old package (2005).
I'll look into this. What is the alternative to lapack?
> Right now, I've just removed the atlas3 dependency. Please check it
> out, and I'll also talk to upstream about it. However, I don't think
> features are lost by this change. If anything, performance will be
> affected, to the best of my understanding.
I'm not sure it will - atlas is still shown as an alternative to
rfblas3 in the dependency list of the libittp6 package.
I saw that. So, should we leave things as they are, since atlas isn't
actually pulled in by default?
> I accept this advice. But note that it is highly unlikely that a
> mathematical simulation type toolkit type library like IT++ will have
> any applications based on it, though the possibility cannot be
> discounted.
Nonetheless, libraries are still more difficult to get right than an
application.
I accept. It's been a learning experience, and I've faced many
problems with this.
This does, however, raise a different issue - is there some way I can
test the package?
I think I added a make check or make check-local to the 3.10 series.
That runs many test. See this:
http://buildd.debian.org/fetch.cgi?pkg=libitpp;ver=3.10.11-1;arch=ia64;stamp=1181111650
As sponsor, it is important for me to know that the package I built
(which is the one actually uploaded) does work. The package appears to
support a 'make check' command. I did a test build on this amd64 box
and adding a '$(MAKE) check' line in the build-stamp: target after
$(MAKE) took less time than building the docs. I would recommend making
this a default command in the build-stamp rule, wrapped in a build
option:
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
$(MAKE) check
endif
I actually _did_ this for the 3.10 series, but forgot to do it. *Sigh*
I guess I'm just learning how imperfect I am...
Thanks for the patient response. Since I am not on my sid machine
anymore today, I can't do anything till tomorrow morning. So, will
prepare things with the changes you mentioned.
Kumar
--
Kumar Appaiah,
462, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036
Reply to: