[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: qrupdate

2009/1/31 Paul Wise <pabs@debian.org>:

> hexedit says byte 0x7 of debian/control is a tab (0x09) rather than a
> space (0x20). Anyway, not a big deal.

Ah, that one. I see it now. Okay, it's a space now.

> Just tested it on an etch system (perl 5.8.8), worked fine. I really
> doubt that it requires any recent version of perl.

Okay, lowered the Perl version.

> I think you missed my debhelper 7 comment?

I'm actually using version 7, since dh_prep needs it.

> The package FTBFS in a clean chroot. Please always test in a clean
> chroot with sbuild/pbuilder/cowbuilder/qemubuilder/etc.

Oops, I was missing a couple of build-deps. Fixed.

> I see lots of warnings from dpkg-shlibdeps, you might want to
> investigate and contact upstream about them

Okay, I've sent them an email about this.

> lintian gives one --pedantic warning, please encourage upstream to add
> a NEWS or ChangeLog file:
> P: libqrupdate1: no-upstream-changelog

Contacted upstream too.

> There are no header files in the -dev package, does fortran not need
> external headers to be able to link to the library ?

No, Fortran doesn't use headers.

> You don't handle DEB_BUILD_OPTIONS noopt or parallel=n, please check
> the debian-policy for info on that.

I'm going to ignore both of those since this package is so tiny and
Fortran builds so quickly.

> I assume you've read libpkg-guide?

Yes, is there a part of it I obviously need to read again more carefully?

> Is the static library needed? Debian tends towards not installing them
> where possible.

It's going into the -dev package per section 4.2 of libpkg-guide and
also following the example of lapack and blas which do the same.

> build-stamp should depend on $(QUILT_STAMPFN) instead of patch.


> configure/configure-stamp don't do anything, you can probably drop them.


> I would assume libqrupdate1 would mainly be installed automatically
> and the -dev package would be installed manually by people wanting to
> use the library. If that is the case, the function-reference and
> README should be in the -dev package. In addition the package
> descriptions should reflect this; the lib one should be minimalist and
> the -dev package should be aimed at folks developing software using
> the lib.

Yeah, again, Fortran is a little weird about this. I'll leave the
shared lib in the libqrupdate1 package and the static library in the
-dev package per the recommendations of libpkg-guide and the examples
of lapack and blas.

> You're missing ${misc:Depends} from the Depends, you should always
> include it in case some debhelper script adds stuff to it in the
> future.

Okay, this gives me a warning, but I understand this is harmless.

> libqrupdate1 should be in section libs rather than libdevel


> You don't specify which version of the GPL your packaging is released
> under, was that intentional?

Yeah, I don't really care. Use any version of the GPL. Anyways,
doesn't it have to be version 3 since I'm adding to the build system
of a GPLv3 package?

> The copyright file is wrong, Jaroslav Hajek seems to be the author but
> not the copyright holder.

I've contacted him about this too.

Here is the updated package on mentors.d.n:

- URL: http://mentors.debian.net/debian/pool/main/q/qrupdate
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc

I've also set up an svn repo for this package with the pkg-scicomp team:


- Jordi G. H.

Reply to: