0.31 just came out. ;) I've uploaded the snapshot now anyway to gain some time on the NEW pilgrimage.
I know you're a DD and as I said before, I should not be telling you what to do, but it would be nice if you could fix the lintian warnings and errors: W: connman source: out-of-date-standards-version 3.7.3 (current is 3.8.2) W: connman source: quilt-build-dep-but-no-series-file W: connman: binary-without-manpage usr/sbin/connmand E: connman: pkg-has-shlibs-control-file-but-no-actual-shared-libs W: connman: postinst-has-useless-call-to-ldconfig W: connman: postrm-has-useless-call-to-ldconfig W: connman: init.d-script-missing-lsb-section /etc/init.d/connman If you could, I would suggest to fix those and prepare another package to upload to NEW, as that should increase our chances to get it past ftp-master quicker. Also, wrt your answers to my previous mail: also sprach Alexander Sack <a...@debian.org> [2009.07.22.1404 +0200]: > > - /usr/lib/connman/scripts/dhclient* should really go to > > /usr/share, don't you think? > > Yes, thats probably the accurate place to ship it, but i never saw > the point for going through maintenance overhead if the amount of > files isn't significant enough and they are not shipped in an arch > all -common package at all. Point taken, I guess I am a bit pedantic and very appreciative of the FHS… > > - any reason you didn't use debhelper to install/remove/invoke > > the initrd scripts? > > Out of habits I would think. Also I felt more comfortable to > implement what it does than to buy some magic. And yet you are using cdbs? ;) I don't know how to use cdbs to do the equivalent, but I think it would make sense to use it, if only in the interest of uniformity. > > - does the short description have to mention Intel? > > > > - I'd change the capitalisation. > > > > - Maybe the long description could be rephrased to be a little bit > > more Debian-centric? After all, this is for Debian/Ubuntu, not > > Moblin, right? > > I used the description published by Moblin at the time I did the > initial package. This has changed now so we could update short and > long description based on what is on connman.net. I don't consider > myself an outstanding package description author, so please go ahead > and submit text snippets suitable; but dont go for a too debian/ubuntu > centric approach as there are more unnamed downstreams that might want > to reuse our package description. ;). > > Filed: https://bugs.launchpad.net/bugs/403001 I am pressed for time right now, but I might take a shot at a later point. > > - How does your version numbering scheme work? > > 0.30+git.1.5b69740e1 Have you considered just using the > > git-describe output, like I did e.g. for mdadm: > > 3.0~devel3-43-g2800528-1 > > the used scheme is basically implemented in debian/rules ... it > allows you to do snapshots and tags. We use some variant of that > approach in other packages as well. I haven't checked > git-describe, but I am not sure how feasible that is as we > regularly package up git snapshots that have no tags. The benefit of git-describe is that it's standardised and automatic. Here's how it works: 3.0~devel3-43-g2800528-1 This is the 3.0-devel3 pre-release, so we'll prefix 3.0~ manually. The remainder of the version spec comes from git-describe: devel3 is the name of the last annotated tag 43 is the number of commits since that tag g means Git 2800528 is the abbreviated commit ID That's one way to do it. Another would be to actually annotate-tag the upstream source yourself and maintain the tag in your own repo, which could be useful later if you need to identify the commit at which you snapshotted in a slightly more usable way. I find the git-describe syntax pretty nice though. Cheers, -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems windows v.i.s.t.a.: viruses, infections, spyware, trojans and adware
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
