[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libgss1 -> libgss2 transition?
Re: libgss1 -> libgss2 transition?
Wed, 31 Mar 2010 01:40:30 +0200
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
Russ Allbery <address@hidden> writes:
> Simon Josefsson <address@hidden> writes:
>> Hi Russ, could you please upload now, to experimental first? Use the
>> latest daily snapshot  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
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.
>> 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
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':
exec git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git'
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 $@
> dh_auto_configure -- --with-po-suffix
> ifeq (,$(filter $(DEB_HOST_ARCH),mips mipsel))
> cd doc && $(MAKE) install-ps install-pdf install-html
> 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.