Russ Allbery <[email protected]> writes: > Simon Josefsson <[email protected]> writes: > >> Hi Russ, could you please upload now, to experimental first? Use the >> latest daily snapshot [1] as the source, and the debian packaging stuff >> from CVS. For me it builds under linux, mac, windows, and the debian >> package is lintian free on my system, so I think v1.0.0 is almost ready, >> but I'd like to avoid a 1.0.1 soon after just because it doesn't build >> on the buildd's. > > Uploaded (to unstable) as 1.0.0. Sorry, I didn't get to this yesterday.
No problem, thanks! I'm leaving for vacation tomorrow, and GSS was holding up my GNU SASL release and I wanted to get it out ASAP, so that's why I didn't wait with releasing GSS 1.0.0. > A few minor things: > > * I updated the watch file since it was still pointing to alpha.gnu.org, > which actually doesn't have 1.0.0. Right, ftp.gnu.org will be the future site for all non-alpha releases. > * Switched to debhelper compat level V7, since there's no reason not to. Ok. There is no lintian warning about that. ;) > * You'd been adding the multi-author changelog author notation even for > uploads where you were the only person who made changes and were also > the uploader. Conventionally, one omits the author notation in that > case since it's the common case that the uploader made all the changes. > And it keeps the changelog a bit shorter. I went back and removed those > annotations. Aha, I wasn't aware of that. Will avoid it in the future. > I tagged the debian directory, but it looks like there are no tags for the > last few uploads. Dunno if it's worth going back and retroactively adding > those tags. It is probably not worth the time... >> Btw, the version number in changelog maybe should be modified to include >> a date, so that the real gss-1.0.0 upload will be newer. I'm not sure >> how to best do that, 1.0.0~20100329-1? > > Yes. Or ~git20100329, but the "git" part isn't really needed. I'll try that sometime. >> On the other hand, maybe uploading 1.0.0-1 to experimental now and then >> 1.0.0-2 to unstable later works just as fine. > > Note that if we'd done that, both would have had to use the same upstream > tarball. You can't change upstream tarballs without changing the upstream > version, even moving between archive suites. So that only works if using > the final 1.0.0 tarball release. Ok. >> If you have any comments (even stylistic) on the packaging code, please >> let me know, as I'm still learning debian packaging. I'm co-maintaining >> the gsasl debian package in git and have learned to appreciate that, so >> possibly one improvement would be to move to git for gss & shishi too. > > I would love that. My documentation for how I structure my packages is > at: > > http://www.eyrie.org/~eagle/notes/debian/git.html I've read that before, and it is useful. I didn't get your git-pbuilder stuff to work, though, so I am using this short script 'git-pdebuild': #!/bin/sh exec git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' --auto-debsign" I don't recall why your script didn't work for me.. > If I were you, I'd use the upstream Git development repository to hold the > packaging as well and just use a separate set of branches. There's a > section in that document about how to set that up. I find that very > convenient when working with packaging alongside upstream development. > > Of course, that would mean giving anyone who's helping with the packaging > access to the upstream development repository, which you may not want to > do, or merging patch sets from people. I'll think about that -- I suspect I'll prefer to put the debian specific stuff in another git repository instead of the upstream one. I'm not sure I trust all the git/debian tools to not mess up my repository yet. There is also size/speed concerns. >> The packaging uses CDBS and I'm not sure that is considered the best >> packaging tool any more (or if it ever was), so switching to something >> else would be another option -- but I don't know to what. > > I really like debhelper 7 with rule minimization and overrides. The > corresponding debian/rules file for the current GSS package would look > something like: > > #!/usr/bin/make -f > > DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) > > %: > dh $@ > > override_dh_auto_configure: > dh_auto_configure -- --with-po-suffix > > override_dh_auto_test: > ifeq (,$(filter $(DEB_HOST_ARCH),mips mipsel)) > dh_auto_test > endif > > override_dh_auto_install: > dh_auto_install > cd doc && $(MAKE) install-ps install-pdf install-html > DESTDIR=debian/tmp > > override_dh_compress: > dh_compress -Xgss.pdf > > I don't remember if the version in shlibs is automatically updated based > on the information in the symbols file or if you still need an override > for dh_makeshlibs as well. > > The advantage of using this method over debhelper is that all the > individual programs being run have man pages that document what they do, > and you can set DH_VERBOSE to 1 in the environment to see exactly what > programs are run in what order. Ok, I think we should switch to this after squeeze. /Simon _______________________________________________ Help-gss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gss
