Hi, Chris Frey wrote (03 Mar 2012 08:27:32 GMT) : > In the latest Barry git tree, I've updated the debian packaging to > Standards-Version 3.9.1 (the latest for Squeeze)
We don't wait until all previous Debian releases are EOL'd before we start following the latest Debian Policy. Please follow the latest available Standards-Version: Debian Policy 3.9.3 was released. See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz :) > and the compat level to 7 (the latest for Ubuntu 10.04 LTS). > I can keep pressing forward with the Standards-Version, but not the > compat, since that halts builds on older systems. But compat 7 isn't > too bad. Even squeeze-backports has debhelper 9+. I agree compat level 7 is not too bad, and this is obviously not a blocker at all, but I must state I strongly dislike the idea of refraining from using compat level 9 in Debian before 2015, merely because nobody has uploaded a recent debhelper into lucid-backports. We manage to be slow enough, by ourselves, to adopt recent changes at Debian, without needing any such external help to get things stalled. > I've also fixed some lintian errors. The following warnings remain: >> W: opensync0-plugin-barry: new-package-should-close-itp-bug > This can be ignored, I think. Putting two source packages into the same Git repository will be a pain. Let's talk about this other, new source package (opensync0-plugin-barry) later, and keep focused on the barry one to start with. By the way, I think the source package would be better called opensync-plugin-barry; and if it really needs to be a separate source package, Lintian is right, you need to fill an ITP for opensync-plugin-barry, and close it in its debian/changelog. However, the barry package Debian changelog should mention the adoption and close #657076. >> W: barrydesktop: binary-without-manpage usr/bin/bsyncjail >> W: barry-util: binary-without-manpage usr/bin/hal-blackberry > bsyncjail is used by the Desktop GUI to isolate the sync process, > in case opensync crashes. It is not meant to be run by the user. > Is there any harm in putting this in /usr/lib/barry or > /usr/lib/barrydesktop? IIRC /usr/lib/$BINARY_PACKAGE/$PROGRAM is appropriate, but please check the Debian Policy and FHS. > Similarly for hal-blackberry... that is just a script run by HAL > to fill in device identification info. This could go in /usr/lib as > well. Seems so. > Is it bad form to share a /usr/lib/barry directory between multiple > packages? It's fine. >> W: barrydesktop: package-name-doesnt-match-sonames libosyncwrap18 > This is a library only used by the Desktop GUI, and therefore packaged > right along with it. Someday it may be useful as a standalone library, > and could be packaged that way, but it is not ready for that yet. > I'm thinking this warning can be ignored for now too. Agreed. Please add a lintian override, with these reasons as comments, then. Random other notes follow. Please migrate to 3.0 (quilt) source format (done in my branch). Please add Vcs-Git and Vcs-Browser control fields. There are still duplicate short package descriptions in debian/control (barrydesktop and barrydesktop-dbg). Please enable hardening build flags to build hardened compiled binaries and libraries: https://wiki.debian.org/HardeningWalkthrough (Yes, the proper way to do so needs recent debhelper and dpkg-dev. Maybe supporting older systems will require dedicated branches to carry tiny patches.) The compiling notes on top of debian/control should really be moved to debian/README.source. debian/control is no good place for documentation. I find it misleading to write "barry (0.18.0-1) unstable" in debian/changelog right now; I think it should only be done at the last minute, once the package is really ready to be uploaded to Debian unstable, which is not presently the case. Until this point is reached, I find it saner to: * either keep UNRELEASED instead of unstable * or manually manage lower-than-release but increasing version numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) * or use git-dch to get automated lower-than-release but increasing version numbers About debian/changelog: * it removes history about all recent uploads to Debian; it should absolutely not do this. * I don't think we care about that granular history: + * bumped compat to level 6 (2011/06/28) + * reviewed debhelper(7) manpage changes and updated compat to 7 (2012/03/03) We've Git for this. * On the other hand, your debian/changelog seems to lack much information my own version of this file has. Possibly because you're only mentioning changes since your last own package. But we're preparing an upload to Debian, so debian/changelog must mention the changes from the last version uploaded to Debian to the current one. The debian/0.15-1.2 tag may be useful when gathering such informations, although I've already done most of the work in my branch, and I suggest starting from it. Building in a sid chroot fails for me: checking for OPENSYNC22... no checking for OPENSYNC40... no configure: error: Unable to find development libraries for either opensync 0.22 or 0.4x. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables: OPENSYNC22_CFLAGS and OPENSYNC22_LIBS or OPENSYNC40_CFLAGS and OPENSYNC40_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure: error: ./configure failed for desktop make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 => missing build-deps? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage? -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85r4x97pt1....@boum.org