[Pkg-crosswire-devel] Ice-cream release

[Jonathan Marsden]

Dmitrijs Ledkovs wrote:

> See lp:~pkgcrosswire/libsword/dfsg
> 
> it cannot be merged with main :-(
> 
> but it compiles :-)

OK... you added +dfsg to the Debian package version string, but you
aren't mangling the version in the watch file, and that gets you a
lintian warning (and uscan doesn't work any more).

I'm becoming a bit confused by all of this.  Too many separate
branches... get-orig-source, copyright, copyrights, newmain, and now
dfsg!  It shouldn't be that hard.

(1) I just look at lp:~pkgcrosswire/libsword/main, which had my
get-orig-source stuff added to debian/rules, and a further fix for
removing the win32 dirent files -- but which for some reason still had
all those files still in it, all the zlib sources, etc.

(2) So I "manually" did bzr rm for each of the files which the tarball
repack removes.  I think this is simpler and easier than whatever
gyrations you are doing that have made a separate non-mergeable tree,
and then doing more work on that to get it to merge back in again!

(3) I updated debian/copyright to get rid of info about the files we
remove during our repack -- they aren't there in our repacked tarball,
so we don't need to mention them in debian/copyright now.

(4) I also added the watch file version mangling so that uscan doesn't
look for a +dfsg tarball upstream, which is what your dfsg branch
currently seems to be doing :)

(5) BTW, for me at least, there are issues building SWORD (FTBFS) when
we remove include/regex.h , apparently because it was not conditionally
included in includes/Makefile.am based on MINGW, it was just always
included.  I'm not sure how your dfsg tree handles that, I'll take a
look and see what you did.

Patching include/Makefile.am for that issue is easy, I've already done
that; but then we'd have to run autoconf (or autogen.sh) at build time,
with all the 'fun' that implies for "putting back" old (upstream) copies
of Makefile.in and so forth.  Ugh.

I'm looking at creating a patch to the relevant Makefile.in for now,
unless your dfsg tree has a neater way to deal with this.

(6) The more I look at the SWORD build system, the more I think it
hasn't been kept all that up to date... on Jaunty, running autoreconf
-Wall gives a *lot* of warnings and suggests doing an autoupdate... but
that's more of an upstream build system issue than a packaging one.  The
crosswire.org server has the same autoconf version that Ubuntu Jaunty
has (2.63), so that's not why the build system seems sort of behind the
times.

I'll probably provide some related patches for SWORD upstream to improve
things.  But I'll have to test those changes on Hardy and Intrepid too,
so we don't accidentally break our ability to build SWORD with older
autoconf setups.

Jonathan