On 2 December 2010 19:15, Jonathan Marsden <[email protected]> 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 _______________________________________________ Pkg-crosswire-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-crosswire-devel
