Re: RFS: qrupdate
On Wed, Feb 4, 2009 at 6:20 PM, Rafael Laboissiere 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
* Jordi Gutiérrez Hermoso [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 " 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 12:41 PM, Jordi Gutiérrez Hermoso 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/31 Paul Wise : > 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 Sat, Jan 31, 2009 at 1:55 PM, Jordi Gutiérrez Hermoso wrote: > 2009/1/29 Paul Wise : 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
2009/1/29 Paul Wise : > On Fri, Jan 30, 2009 at 12:24 AM, Jordi Gutiérrez Hermoso > 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 Fri, Jan 30, 2009 at 12:24 AM, Jordi Gutiérrez Hermoso 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 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