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

[Stuart Hughes]

Hi Peter,

Note the patch I sent you is always fatal if you run ./ltib -p xxx -m
scdeploy, it's purely for debugging.

Please try out Steve's suggestion and let us know if you run into
problems.

Regards, Stuart


On Fri, 2008-05-02 at 12:00 -0400, Peter Barada wrote:
> 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