[Pkg-crosswire-devel] Questions

[Dmitrijs Ledkovs]

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
CMakeFiles/bibletime.dir/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp.o
/usr/bin/c++   -DBT_VERSION=\"2.8.0\" -DBT_DEBUG -DQT_DLL
-DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_XML_LIB -DQT_CORE_LIB
-DQT_DEBUG -g -O2  -Wall -Werror -O2 -ggdb -fexceptions
-I/build/buildd/bibletime-2.8.0/obj-i486-linux-gnu
-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
CMakeFiles/bibletime.dir/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp.o
-c /build/buildd/bibletime-2.8.0/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp
/build/buildd/bibletime-2.8.0/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp:
In member function 'void BtInstallPage::slotSourceAdd()':
/build/buildd/bibletime-2.8.0/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp:358:
error: 'QSharedPointer' was not declared in this scope
/build/buildd/bibletime-2.8.0/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp:358:
error: expected primary-expression before '>' token
/build/buildd/bibletime-2.8.0/src/frontend/bookshelfmanager/installpage/btinstallpage.cpp:358:
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
book.

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

>> 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
https://dev.launchpad.net/BuildBranchToArchive/NonNativePackages

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