Re: RFS: qrupdate
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-02-03 21:41]: I've also set up an svn repo for this package with the pkg-scicomp team: http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/ Thanks for that. Could you please create the trunk/ and tags/ directories and move debian/ into trunk/? Otherwise it will be hard to tag the Debian releases of the packages. This is the usual layout for pkg-scicomp packages, e.g.: $ svn ls svn+ssh://svn.debian.org/svn/pkg-scicomp/glpk $ svn ls svn+ssh://svn.debian.org/svn/pkg-scicomp/glpk/trunk $ svn ls svn+ssh://svn.debian.org/svn/pkg-scicomp/glpk/tags In this case, the Vcs-* tags in debian/control would be: Vcs-Svn: svn://svn.debian.org/svn/pkg-scicomp/qrupdate/trunk/ Vcs-Browser: http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/ I already committed three changes (added my name to Uploaders, fixed the debian/watch URL, and add a svn:ignore list). If you have not yet done it, you might be interested in subscribing to the pkg-scicomp-commits mailing list. You might also set the Maintainer to Debian Scientific Computation Team pkg-scicomp-de...@lists.alioth.debian.org and add your name to Uploaders. This common practice in pkg-scicomp but it is up to you. Otherwise, the package builds and installs fine here. I would just follow the suggestion from Paul Wise and put README and function-reference only in the -dev package. Please, tell us when the package is ready for upload. Cheers, -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
On Wed, Feb 4, 2009 at 6:20 PM, Rafael Laboissiere raf...@debian.org wrote: Otherwise, the package builds and installs fine here. I would just follow the suggestion from Paul Wise and put README and function-reference only in the -dev package. Well, this is a fortran library, you don't nessecarily need the -dev package to build apps that link against it. I'd put them in both packages myself. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
2009/1/31 Paul Wise p...@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.
Fixed.
configure/configure-stamp don't do anything, you can probably drop them.
Removed.
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
Fixed.
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:
http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/
Thanks,
- Jordi G. H.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
On Wed, Feb 4, 2009 at 12:41 PM, Jordi Gutiérrez Hermoso
jord...@gmail.com wrote:
I think you missed my debhelper 7 comment?
I'm actually using version 7, since dh_prep needs it.
Ok.
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.
ok
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.
noopt is useful for when people need to do debugging of the library or
apps using it.
I assume you've read libpkg-guide?
Yes, is there a part of it I obviously need to read again more carefully?
Nope, just making sure you're familiar with it.
This is a fortran library though, so some things are a bit different.
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.
Ok
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.
Fair enough, fortran is weird.
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.
The warning will go away with debhelper 7.1 (#498666).
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?
Yeah, version GPLv3 is incompatible with GPLv2 IIRC, so the binaries
are GPLv3 or later no matter what. You might want to clarify that the
packaging is under any version of the GPL (or just change it to GPLv3
or later).
- dget
http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc
I think you should depend on libblas-dev in case the ABI of libblas3gf
changes. Although, this is fortran, so I'm not entirely sure about
that. In any case I think it should be consistent between libblas
liblapack.
You can drop the perl build-dep version restriction since etch will
soon be oldstable and Debian doesn't support things older than
oldstable.
I've also set up an svn repo for this package with the pkg-scicomp team:
http://svn.debian.org/viewsvn/pkg-scicomp/qrupdate/
You should add Vcs-* fields to debian/control.
Only the copyright file is a blocker though.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
2009/1/29 Paul Wise p...@debian.org: On Fri, Jan 30, 2009 at 12:24 AM, Jordi Gutiérrez Hermoso jord...@gmail.com wrote: patches/add-soname seems to change the whitespace in the definition of SRC, why? Why not? It fits into 80 columns that way. :-) Just a gratuitous change, also unrelated to the purpose of the patch. Okay... undone. patches/add-soname needs some more metadata: upstream status, author, location it was taken from (if it was taken from somewhere). Done. Where is this requirement documented? Nowhere, it is just common sense really. I guess my sense is uncommon, then. *shrug* tab character before the Source: package name in debian/control Hm, I don't see this... Look at the diff.gz with less. I don't see it there either. Heisenbug. extra lines in debian/watch debian/*dirs debian/*install debian/docs Removed, but why does this matter? Doesn't matter, just slightly sloppy. ... I liked at least one of those whitespaces, the one in debian/watch, because it separates the version line from the actual content, but ok, I removed it. Okay, uploaded again, addressing all the things above. Oh, I forgot one thing. The Perl version. Does it matter if it's 5.10? Should I try to track down the earliest Perl version that works for this script? 5.10 is lenny, wouldn't backporters have to backport to lenny anyways? - 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 - Jordi G. H. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
On Sat, Jan 31, 2009 at 1:55 PM, Jordi Gutiérrez Hermoso
jord...@gmail.com wrote:
2009/1/29 Paul Wise p...@debian.org:
tab character before the Source: package name in debian/control
Hm, I don't see this...
Look at the diff.gz with less.
I don't see it there either. Heisenbug.
hexedit says byte 0x7 of debian/control is a tab (0x09) rather than a
space (0x20). Anyway, not a big deal.
Oh, I forgot one thing. The Perl version. Does it matter if it's 5.10?
Should I try to track down the earliest Perl version that works for
this script? 5.10 is lenny, wouldn't backporters have to backport to
lenny anyways?
Just tested it on an etch system (perl 5.8.8), worked fine. I really
doubt that it requires any recent version of perl.
I think you missed my debhelper 7 comment?
- dget
http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc
More comments:
The package FTBFS in a clean chroot. Please always test in a clean
chroot with sbuild/pbuilder/cowbuilder/qemubuilder/etc.
I see lots of warnings from dpkg-shlibdeps, you might want to
investigate and contact upstream about them
lintian gives one --pedantic warning, please encourage upstream to add
a NEWS or ChangeLog file:
P: libqrupdate1: no-upstream-changelog
There are no header files in the -dev package, does fortran not need
external headers to be able to link to the library ?
You don't handle DEB_BUILD_OPTIONS noopt or parallel=n, please check
the debian-policy for info on that.
I assume you've read libpkg-guide?
Is the static library needed? Debian tends towards not installing them
where possible.
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.
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.
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?
The copyright file is wrong, Jaroslav Hajek seems to be the author but
not the copyright holder.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
On Fri, Jan 30, 2009 at 12:24 AM, Jordi Gutiérrez Hermoso jord...@gmail.com wrote: patches/add-soname seems to change the whitespace in the definition of SRC, why? Why not? It fits into 80 columns that way. :-) Just a gratuitous change, also unrelated to the purpose of the patch. patches/add-soname needs some more metadata: upstream status, author, location it was taken from (if it was taken from somewhere). Done. Where is this requirement documented? Nowhere, it is just common sense really. tab character before the Source: package name in debian/control Hm, I don't see this... Look at the diff.gz with less. extra lines in debian/watch debian/*dirs debian/*install debian/docs Removed, but why does this matter? Doesn't matter, just slightly sloppy. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
On Thu, Jan 29, 2009 at 10:06 AM, Jordi Gutiérrez Hermoso jord...@gmail.com wrote: - dget http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc Some comments on just the diff.gz: You should use a Debian-specific SONAME if upstream doesn't have one. Please teach upstream about SONAMEs, ABI etc and get them to do that stuff instead of doing it yourself. debian/postinst debian/postrm look like they can be removed and generated by debhelper. debian/substvars should not be in the diff.gz patches/add-soname seems to change the whitespace in the definition of SRC, why? patches/add-soname has a typo in one of the variables added: VERSIOON patches/add-soname needs some more metadata: upstream status, author, location it was taken from (if it was taken from somewhere). you specify debhelper compat 7 but don't seem to use the features of it (annoying for backports). Also, is perl 5.10 really needed? you should definitely ask upstream to implement make install. you might want to send the function-reference script upstream along with a patch to integrate it with their build process. There is some extra whitespace: tab character before the Source: package name in debian/control extra lines in debian/watch debian/*dirs debian/*install debian/docs -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
