ltib
[Top][All Lists]
Advanced

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

Re: [Ltib] making ISO release (aka -m release)


From: Andrea Galbusera
Subject: Re: [Ltib] making ISO release (aka -m release)
Date: Tue, 13 Mar 2007 16:20:32 +0100

Hi Stuart,
thank you for reply. Lot of interesting suggestions in your answer.

On Thu, 2007-03-08 at 14:01 +0000, Stuart Hughes wrote:
> Hi Andrea,
> 
> There are quite a few items to cover here, but to cut to the chase, you
> can do what you want.
> 
> The longer answer is this:
> 
> * If you want to make a derivative BSP, then you should really start
> from the external sources provided at bitshrine.org (via savannah).  The
> reason for this is that in the "official" iso releases provided by
> Freescale, there could be some components that require explicit end user
> license agreement, or in some other way not be 100% re-distributable by
> you.  For example, I don't think all of the documentation that is on the
> iso images is freely distributable.

Ok, I have to check for licenses, but what I want to do is not really
redistribute the BSP to the world. I'd like to collect all the changes I
made to sources/configs/filesystems against the Freescale BSP together
with some docs and freeze them for future fix and/or enhancements by,
maybe, one of my colleagues.

> 
> * I would recommend doing the whole thing using savannah CVS and the
> GPP.  Unless you have something closed, this will offer you the simplest
> ongoing maintenance effort.

Let me give you an example. I have a patch to the kernel (generated with
-m patchmerge) that I use to enable a few more uarts my target have with
respect to the mpc5200 target by Freescale. This is basically two or
three lines of code in the platform initialization code. Would you post
this to the GPP?

> 
> * If you don't want to do that and you intend to distribute your own
> BSPs and maintain them, even if you don't want to publish some of the
> content, you'd still be better of using the public CVS.  The ltib source
> tree normally only has references to content, and you don't have to
> upload those to the GPP.  The advantage this has is that you'll be able
> to keep your BSP in sync with the master LTIB project.  What I'm
> suggesting is that if you had CVS write permissions you can create and
> maintain your own branch.  You'd then be able to make releases and tag
> CVS.

Again, if I don't get it wrong, platform configs are included in ltib's
sources. Would you suggest to get write permission to the CVS and commit
platform configs for my custom hardware?

> 
> * If you don't want to use the public CVS to make your BSP available,
> I'd recommend that you create your own private LTIB CVS project and then
> use the public CVS as the initial (and subsequent) vendor import.  That
> way you have a means of keeping your private tree in sync with the
> public one.  Also this will allow you to use the normal '-m release'
> process that references CVS

This sounds like the most promising solution for me. Just wanted to try
it now, but I can't checkout from CVS... I get errors from the site
being unable to connect to the database. I'll try later and let you
know.
> 
> * If you don't want to use CVS at all, you can still make a release, but
> to do this you have to first generate a MANIFEST file that lists all the
> files that need to go into the release, and then when you run -m
> release, you need to use the special tag name: 'localdir'.  To generate
> an initial MANIFEST file you need to have a CVS copy (e.g. savannah) and
> run something like:
> 
> cvs status 2>/dev/null | perl -e ' 
>     $_ =`cat CVS/Root`;
>     ($cvsroot) = m,(/.*),;
>     while(<>) {
>         m#^\s+Repository revision:.*$cvsroot/(.*),v#o and print "$1\n";
>     }
> ' > MANIFEST
> 
> This file will need to be hand edited to add/remove unwanted files.

This also is something I discovered digging into the ./ltib source, but
I didn't know how to create the MANIFEST file. I'll try this too, but
the local CVS appears more promising.

> Regards, Stuart
> 
> 
> On Wed, 2007-03-07 at 15:43 +0100, Andrea Galbusera wrote:
> > Hi all,
> > I have been using ltib for a while now. I started from the Freescale iso
> > BSP for the Lite5200 board and moved on making a new target for a custom
> > hardware platform similar to mpc5200. I feel confortable with the whole
> > thing and succesfully used many of the available target: I use a
> > sligthly patched kernel (patches captured by ltib) and I merged some
> > files to the target rootfs and also added a few application specific
> > packages.
> > 
> > I still miss a few point about the whole thing. The code I developed for
> > my custom target is not very interesting for the whole ltib community
> > (this platform will go into a product and it's not a development
> > hardware); then I don't think I should upload anything to CVS or the
> > GPP.
> > 
> > I anyway would like to use something like the "-m release" target to
> > freeze the state of the art and make a new BSP for future development,
> > if required. I read doc/LtibReleaseProcess, but it always deal with
> > committing changes to CVS and GPP before releasing.
> > How can I make a BSP from local files?
> > 
> > By the way, I use ltib 6.2.1 (1.218) from
> > mpc5200_lite5200b_20060726_ltib iso image from Freescale.
> > 
> > Any advice is welcome.
> > 
> > Regards,
> > Andrea
> > 
> > 
> > 
> > _______________________________________________
> > LTIB home page: http://bitshrine.org
> > 
> > Ltib mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/ltib
> 
> 





reply via email to

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