ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stuart Hughes
Subject: Re: [Ltib] Problem with "./ltib -p kernel -m scdeploy"
Date: Fri, 2 May 2008 08:13:25 -0700

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:

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.

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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]