[Top][All Lists]
[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>