New subject: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)

4 Dec 2012

...
 I am trying to build it within a chroot, but unless I
am doing that
wrong I do not know what I need to do.  :(  I am also not opposed  to
...
 uninstalling my current version of trinity and working
from a
different environment, whatever is the best way to do it.  I can  use
...
 qemu or virtualbox.  It does not matter to me. if there
is a  specific
...
 way that one would suggest building them please let me
know what it
is, even if it a little unorthodox. 
I build for Slackware. I have only one computer.

For comparison testing, I have the following virtual machines:

Slackware 12.2 with KDE 3.5.10
Slackware 13.1 with Trinity 3.5.13

I use both virtual systems to compare how things used to run and to 
determine whether a bug or behavior is legacy from either system or 
new or a regression in R14.

I still work primarily with Slackware 13.1 32-bit as my main 
production system, although I also have a newer Slackware 14.0 64-
bit system. Within my 13.1 32-bit system I use a chroot in konsole 
to build R14 packages for 13.1 32-bit.

As I have only one computer, I have separate partitions on my 
system for Slackware 13.1 64-bit, 13.37 32-bit and 64-bit, 14.0 32-
bit and 64-bit, and Current 32-bit and 64-bit. Typically I don't 
build often in any of those systems. When I find a nice quiet spot 
in the R14 development, where everything builds without incident 
and usage remains stable, then I reboot my system and will run a 
full package build in one of the other systems. Most often I pick 
the Slackware 14.0 64-bit environment.

My Slackware 14.0 64-bit production and build environments are on 
separate partitions. Almost always I run those non-13.1 builds at 
night while I sleep and I don't need the computer.

On my to-do list is to create virtual machines for each build 
system and to use the existing build environment partitions as raw 
devices in the virtual machines. That will provide me flexibility 
to support the other systems without rebooting.

A sane approach, when the budget allows, is to use a second machine 
that hosts all of these build environments.

Most people have no need or desire to support multiple systems. 
Just focus on building against the current system. For that a 
chroot is fine. Virtual machines work too, but I find virtual 
machines too slow for long build runs.

Although written for Slackware, here is a good tutorial about 
creating a chroot:

http://slackworld.berlios.de/2007/chroot_howto.html

In the past, in all of my build environments, I remove all KDE4 
related packages. I do that create as pure a build environment as 
possible. I have been removing Qt4 as well, but I'll need to change 
that in order to build and test some of the newer packages Trinity 
provides.

The cmake packages don't have a problem correctly finding (T)Qt3 
rather than Qt4. The automake packages tend to get confused, but 
the work-around is to explicitly declare where to find the (T)Qt3 
packages:

  --with-qt-dir=${QTDIR}
  --with-qt-includes=${QT_INCLUDE_DIR}
  --with-qt-libraries=${QT_LIB_DIR}

In all of my build environments I don't use any desktop environment 
or window manager. I run my sole chroot from a terminal window and 
all other build environments from the console.

A sane approach is to focus on just building one package at a time 
in the order suggested in the wiki. Get TQt3 to build. Then 
tqtinterface. Etc.

The Trinity wiki and Arch web site should provide the gritty 
details. I'm guessing the Arch web site for Trinity provides all 
build scripts.

I believe most of us use a parent/master script to build each 
package successively without user intervention.

The 3.5.13.x branch is for back porting patches. Therefore the 
primary build environment uses the R14 development branch.

Darrell

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)