[Pkg-crosswire-devel] Ice-cream release

[Dmitrijs Ledkovs]

2009/5/24 Jonathan Marsden <jmarsden at fastmail.fm>:
> 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.
>

to be fair.... me too...

> (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.
>

I've only touched debian/* in the main branch

> (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!
>

there is something wrong with bzr bd UI. It doesn't look easy to
manage DFSG tarballs with it. So yeah simply removing files seems much
easier.


> (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.
>

Yeap. But we do need to create Debian.source listing what files we
have removed, I think. Have to check that.

> (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 :)
>

good. lol =D that would actually be cool to if crosswire published
DFSG-free tarballs =D

> (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.
>

yeap I did a bruteforce patch to avoid autoconf

http://bazaar.launchpad.net/~pkgcrosswire/libsword/dfsg/annotate/head:/debian/patches/30_fixup-after-dfsg.diff

> (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.
>

On top of that I've been looking into java/python bindings. Right now
they are not integrated into the top level build-system at all. They
are expecting libsword to be configure, build _and_ installed into
/usr/lib/ and then they go into configuring themselves and so on. So
they could have as well publish them as separate tarballs cause so far
there isn't an obvious way to build those from top-level configure.
Plus see the "small" email about what dependencies they are pulling
for the library in their configure.ac / Makefiles.am that i posted on
sword-devel.

> Jonathan
>

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич