Message: previous - next
Month: December 2012

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

From: pauline martin <321eniluap@...>
Date: Wed, 5 Dec 2012 08:44:41 -0500
On Tue, Dec 4, 2012 at 4:57 PM, Darrell Anderson <darrella@...> wrote:
>>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:
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: trinity-devel-unsubscribe@...
> For additional commands, e-mail: trinity-devel-help@...
> Read list messages on the web archive:
> Please remember not to top-post:
I wil give it a go again later, perhaps I was just out of it.  But I
don't recall being that out of it.  Hmmm.  Guess it is time for me to
find out, once I get home.