[Pkg-crosswire-devel] Questions

Dmitrijs Ledkovs dmitrij.ledkov at ubuntu.com
Thu Dec 2 21:01:46 GMT 2010

On 2 December 2010 19:15, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> Dima,
> On 12/2/2010 2:40 AM, Dmitrijs Ledkovs wrote:
>> 1) Does current bibletime builds against Karmic? Build fails in
>> developer-testing ppa.
> I have not tested that.  If there is an issue, it is almost certainly
> with the webkit / libqt4 dependency stuff, library package names and
> what is in which package seems to have changed significantly recently.
> Karmic is more than a year old... just 4 1/2 months of support left for
> it.  Spending support resources on it for updated BT versions seems low
> priority to me.  BibleTime 2.8.0 builds fine on Lucid, Maverick and
> Natty.  People on Karmic really needing BT 2.8.0 should probably
> consider upgrading to at least Lucid.

I did fix the webkit / libqt4 dependency stuff, such that it works on
lucid, maverick and natty. Configury goes fine on karmic.

Ok. It is just a little odd error IMHO. It fails on amd64, i386 and lpia with:

[ 52%] Building CXX object
/usr/bin/c++   -DBT_VERSION=\"2.8.0\" -DBT_DEBUG -DQT_DLL
-DQT_DEBUG -g -O2  -Wall -Werror -O2 -ggdb -fexceptions
-I/build/buildd/bibletime-2.8.0/src -I/usr/lib -I/usr/include/sword
-I/usr/include/qt4 -I/usr/include/qt4/QtWebKit
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtDBus
-I/usr/include/qt4/QtXml -I/usr/include/qt4/QtCore   -o
-c /build/buildd/bibletime-2.8.0/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp
In member function 'void BtInstallPage::slotSourceAdd()':
error: 'QSharedPointer' was not declared in this scope
error: expected primary-expression before '>' token
error: 'dlg' was not declared in this scope
make[3]: *** [CMakeFiles/bibletime.dir/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp.o]
Error 1

> Please, can we first get SWORD 1.6.2 packaged and into Debian
> experimental -- this is surely a much higher priority than BibleTime
> 2.8.0 for Karmic :)

Well lp:sword/debian is packaged with 1.6.2 - it just needs more
testing, but it is more or less ready for experimental.

>> 2) What is sword-language-packs package?
> No idea.  It's old.  Very old.

Ok. I'll try to contact the maintainer.

>> 3) Are we downgrading sword-frontend from recommends to suggests in
>> libsword9?
> 9?  There's now a need for a SWORD ABI numbering bump to 9?  Why?  What
> part of the SWORD 1.6.2 ABI is incompatible with the SWORD 1.6.1 ABI?
> When was this discussed?  Did I miss it?  Let's not do a SONAME bump
> unless there is a real need for one.

Xiphos produces odd random little bugs when compiled against 1.6.2 but
run against 1.6.1 (reported on gnomesword-users mailing list) In my
limitted tests same happens when I do the reverse - build against
1.6.1 run against 1.6.2.

The implementations have change a bit of the functions, but to be
fair, I am not competent to pin-point what is causing this.

This change has not been discussed yet here. I have switched sword
packaging to CMake because it is easier to build SWIG/python bindings
that way. The build now takes longer, since SWIG compilation takes
quite a bit of space and time. But CMake is more friendly with respect
to setting so-names and more flexible configure.

Fedora/RedHat, openSUSE, Macports and FreeBSD at least all package
sword as just libsword or libsword0. They never change the binary
package name. The so-name is set to release version and I think they
rebuild all deps on every sword point release.

>> 4) Do we need to update sword texts?
> Do those packages install OK?  If they do, do they show up in recent
> BibleTime/Xiphos installations?  You should be aware that packaging
> SWORD modules is a politically sensitive topic, some people on
> sword-devel seemed to be *extremely* against the idea in the past.  I
> have created an (ugly) shell script to automatically package SWORD
> modules in the past... are you sure you really want to stir up that
> hornets nest again??

BTW "The Girl that kicked the Hornet's Nest" is my favourite book from
the "Girl with a Dragon Tattoo" trilogy. But I am from the Baltics and
I am familiar with a few Northern Europe affairs described in the

Right. I have sword-text-kjv installed and I use it during testing. It
works fine. It's just they have not been updated and my opinion that
the source packages for sword-text-* do not use source but repackage
already created modules. I wonder how Firefox extension packaging is

>> 5) The downsides of using recipes to build package
>> - it currently builds recipes from branches as Dpkg source format 1.0
>> native only and hense generates tarballs for each upload instead of
>> using released tarball or snapshot tarball.
> Then don't use recipes :)  These are slowly-changing projects with small
> teams of developers.  It's not as though SWORD, Xiphos or BibleTime have
> huge teams of coders making radical changes every day.  So daily builds
> are not really that helpful to us anyway.

It's a current deficiency in how launchpad is allowing to use recipes.
Locally, if you drop a tarball in the build directory it will build
3.0 (quilt) or regular non-native 1.0 just fine. Launchpad devs still
haven't figured out where and how to store upstream tarballs and when
to inject those or not. See

Ideally in the future taballs will be generated from the pristine-tar
delta stored in the bzr branch it self.

As for daily builds I have had multiple requests for Xiphos and Sword
daily builds - to test updated tools for module developers, for
tanslators to test the updated translations UI and for me to check
that I'm not breaking Xiphos when I commit stuff =)))))

> Jonathan

More information about the Pkg-crosswire-devel mailing list