Bug#657076: Updating and maintaining barry in Debian / Ubuntu
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?
Reply to: