Re: [Ltib] Problem with "./ltib -p kernel -m scdeploy"

[Peter Barada]

On Fri, 2008-05-02 at 08:13 -0700, Stuart Hughes wrote:
> Hi Peter,
> 
> You should not have blown it away as it won't be possible to track down the 
> problem now.  However here's the reply to your earlier email I had in 
> my outbox to you, my daytime environment prevented me from getting it out 
> before:

My aplogies for blowing away the relevant bits, but the daze of punding
my head against the screen for a number of hours trying to figure this
out drove me to trying desperate measures. :)

My latest problem (of differing toolchains between IMX27 and IMX31) is
causing versioning problems (dependencies on GLIBC_2.4).  Can IMX31
(ARM11) and IMX27 (ARM9) both use the same toolchain (and if so, which
of the following):

tc-fsl-x86lnx-armeabi-ntpl-4.1.2-3.i386.rpm
tc-fsl-x86lnx-armeabi-ntpl-4.1.1-6.i386.rpm

I'm guessing the 4.1.2-3 version (looks to be newer).

> I'm not sure what's gone wrong here exactly but, but if I explain how it
> works and what could cause it I think we'll be able to figure it out.
> 
> The way -m scdeploy works is that 2 passes are done.
> 
> The first pass is to to an rpmbuild  -bi --short-circuit  using the
> normal spec file (the generated one: tmp/kernel-2.6.22-mx27lite.spec).
> This builds the normal package install tree under tmp.  
> 
> rpmbuild itself doesn't support the idea of installing this tree, so as
> a second pass, ltib parses the real spec file
> (tmp/kernel-2.6.22-mx27lite.spec) and generates a skeleton spec file and
> should place it in rpm/SPECS/kernel-2.6.22-mx27lite.spec.  This spec
> file has empty %prep, %build, %install, %clean sections and so all it
> does it find the install tree and creates an rpm file.  The empty %prep
> section will prevent unpacking and therefore tree removal·
> 
> Once this spec file is created, ltib clears out the cache value for the
> old spec file (get_spec($sn, 'del') ~ line 815) and finds the new one by
> virtue of the fact rpm/SPECS is first in the search path.
> 
> For some reason the rpm/SPEC/kernel-2.6.22-mx27lite.spec is not being
> found (your output shows it using tmp/kernel-2.6.22-mx27lite.spec on
> both passes), either it's not being created for some reason (although
> that's checked) or the name is wrong, or there is a bug in
> get_spec($sn, 'del');
> 
> To debug this, can you apply this patch to your ltib:
> 
> $ cvs diff -u ltib
> Index: ltib
> ===================================================================
> RCS file: /cm/vault/ltib/ltib/ltib,v
> retrieving revision 1.228.2.7
> diff -u -u -r1.228.2.7 ltib
> --- ltib        27 Jan 2007 00:44:39 -0000      1.228.2.7
> +++ ltib        2 May 2008 14:30:32 -0000
> @@ -812,7 +812,8 @@
>      close SPEC;
> 
>      # invalidate the cache entry as we want to find the new one next
> -    get_spec($sn, 'del');
> +    $spec = get_spec($sn, 'del');
> +    die "spec file for $sn is: $spec";
> 
>      my $ret = f_buildrpms("-bb");
>      unlink($tspec);
> 
> This will cause ltib to die after doing the first stage rpm install and
> print out the path of the spec it finds for the second path.  This
> should be _ltib_/rpm/SPECS/kernel-2.6.22-mx27lite.spec if not it means
> the file is missing, or the name of the file created is not correct
> (incorrectly parsed from the original spec files name: field).  Because
> it dies at this point, you'll be able to 'ls rpm/SPECS' and figure out
> what has happened.
> 
> Please let me know what you find, or if this is not clear.

I've applied the patch and will get back to you if I see this again.
Yes, your explanation is clear, and matches my understanding (after I
dove deep inside ./ltib to figure out *how* it does f_scdeploy()).

Thanks!

> Regards, Stuart
> --- address@hidden wrote:
> 
> From: Peter Barada <address@hidden>
> To: Stuart Hughes <address@hidden>
> Cc: address@hidden
> Subject: Re: [Ltib] Problem with "./ltib -p kernel -m scdeploy"
> Date: Fri, 02 May 2008 10:23:10 -0400
> 
> On Fri, 2008-05-02 at 09:48 +0100, Stuart Hughes wrote:
> > Hi Peter,
> > 
> > This is bad,  I'll check into this straight away.  Any chance you can
> > send me your config/platform/imx27lite directory (tarred up as is off
> > list) so I can see what state things are in.
> 
> In complete frustration I blew away the contents of tmp/ rpm/SPECS/
> rpm/RPMS/ and rebuilt using "./ltib -f" which got past that problem.
> (config directory attached).
> 
> Now I'm suffering from a versioning problem with the base_libs needing
> GLIB_2.4 (log attached).
> 
> > Which version of LTIB was this based on, Savannah CVS (rough date) or
> > from an ISO image.
> 
> It started out as an ISO from Freescale for the IMX31ADS (rel3?) and has
> evolved from there...
> 
> > Regards, Stuart
> > 
> > On Thu, 2008-05-01 at 16:24 -0400, Peter Barada wrote:
> > > Ok, now I'm completely confused.
> > > 
> > > In my environment I'm porting over IMX27 for Logic's board in an LTIB
> > > tree that already has support for Logic's IMX31 board.  I cloned
> > > config/platforms/imx31lite to config/platforms/imx27lite, updated its
> > > main.lkc, preconfig file for the kernel, new .spec file for the kernel,
> > > and all that looks to build correctly.  I'/ve done this before for other
> > > boards and my recipe works each time.
> > > 
> > > The problem I'm having is when I do "./ltib -p kernel -m scdeploy", LTIB
> > > blows away the kernel source (even though PKG_KERNEL_LEAVESRC is set to
> > > "y"!).  I've never seen this happen before and I can't quite figure out
> > > why LTIB decides to rerun the prep phase when I told LTIB to just do a
> > > short-circuited install and copy the content over to the rootfs...
> > > 
> > > Attached is the log.
> > > 
> > > Does anyone have an idea of what could cause this, and how I can fix it?
> > > So far today I've done nothing but prep/build kenrels and can't get much
> > > development done...
> > > 
> > > Thanks in advance!
> > > 
> > > 
> > > _______________________________________________
> > > LTIB home page: http://bitshrine.org
> > > 
> > > Ltib mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/ltib
> > 
> > 
> > 
> > _______________________________________________
> > LTIB home page: http://bitshrine.org
> > 
> > Ltib mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/ltib
-- 
Peter Barada <address@hidden>