Re: [Ltib] BSP releases and repository tags

[Andrea Galbusera]

Hi Stuart,

On Mon, 2011-01-24 at 12:05 +0000, Stuart Hughes wrote:
> Hi Andrea,
> 
> That looks like a bug, for the release the initial
> rootfs/etc/ltib-released should be the same as the one on the ISO.  I
> don't think this area has been updated, so is probably the same in the
> current CVS.

If I get it right, release_main() subroutine from Ltibrelease.pm is
supposed to trigger a complete rebuild from inside a stage directory to
ensure every piece to be in the final image. This stage dir is not under
scm control since it gets created on the fly (follows some code from the
script):

> mkdir $rel
> mv stage $rel
> mv $rel/stage $rel/$rel
> cp $rel/$rel/bin/ltib_install $rel/install
> 
> # work in the release staging area
> cd $rel/$rel
> 
> [...]
> 
> # built to make sure all generated pieces make it onto the iso
> if [  "$tag" = "localdir_nobuild" ]
> then 
>     ./ltib --preconfig $cf->{plat_dir} -m config --batch
> else
>     ./ltib --preconfig $cf->{plat_dir} --configure --batch
> fi

May this be a reason for the release_info to be rewritten with undefined
values in the scm related fields during re-build? This is just a guess
since I have little perl experience and need more hints to further
investigate on this. I just wanted to share such a concern with you!

One last question that is related to this same release process. Why
rootfs.jffs2 does not get copied into "images" dir? It would be handy to
find everything needed to flash a complete system there. I actually find
a kernel, a bootloader but no rootfs! Is this intentional or should it
be copied by extending the following instructions:

> # copy the pre-built images if any to the iso so usable without ltib
> mkdir ../images
> set +e
> cp -a rootfs*gz* ../images/
> cp -a rootfs/boot ../images/
> set -e

Thanks in advance for any more help in solving this issue
Regards,
Andrea


> Regards, Stuart
> 
> On 24/01/11 10:53, Andrea Galbusera wrote:
> > Hi Stuart,
> > thanks for your reply. I'm getting slightly confused about the release
> > files. What I see are different contents between
> > release_logs/RELEASE_INFO found inside the ISO image and the
> > etc/ltib-release inside the rootfs.jffs2 image that comes from the same
> > ISO image.
> > 
> > address@hidden:/tmp/mountediso$ cat release_logs/RELEASE_INFO
> > Release date = Wed Nov 10 14:18:09 2010 UTC
> > Release user = gizero
> > Release host = gizero-desktop
> > Release dir  = /home/gizero/work/tpt/mpc5121/ltib-tpt-branch-0_9
> > SCM wtag     = branch-mpc5121tpt-0_9
> > SCM tag      = rel-mpc5121tpt-0_9 (1.4)
> > Release tag  = ltib-mpc5121tpt-20101110
> > App version  = 10.1.1
> > 
> > while,
> > 
> > / # cat /etc/ltib-release
> > Release date = Wed Nov 10 14:24:18 2010 UTC
> > Release user = gizero
> > Release host = gizero-desktop
> > Release dir
> > = /home/gizero/work/tpt/mpc5121/ltib-tpt-branch-0_9/ltib-mpc5121tpt
> > -20101110/ltib-mpc5121tpt-20101110
> > SCM wtag     = none
> > SCM tag      = none
> > Release tag  = none
> > App version  = 10.1.1
> > 
> > If I get it right these two files are generated in two different steps
> > of the './ltib -m release' execution (timestamps differ). It looks like
> > the file that get included into the rootfs jffs2 image is created from
> > the stage directory shown in 'Release dir'.
> > 
> > release_logs/RELEASE_INFO comes with the expected information while
> > etc/ltib-release lacks some interesting bits. Since I'm not using the
> > latest version of ltib, may I have missed any rework on this
> > functionality?
> > 
> > Regards,
> > Andrea
> > 
> > On Fri, 2011-01-21 at 10:34 +0000, Stuart Hughes wrote:
> >> Hi Andrea,
> >>
> >> The release tag does get written into the ISO image, this is under
> >> release_logs/RELEASE_INFO in recent releases.  In there you may see
> >> something like this (comment below each line describing each entry):
> >>
> >> Release date = Wed Aug 27 15:22:49 2008 UTC
> >>    When it was made
> >> Release user = seh
> >>    Use id of who made it
> >> Release host = m20
> >>    Hostname on which the release was made
> >> Release dir  = /home/seh/ltib_bsps/fc5
> >>    The directory from where it was made
> >> SCM wtag     = Tbranch-xxxx-sim_b1
> >>    The branch you made it from     
> >> SCM tag      = branch-xxxx-sim_b1
> >>    The actual tag for this release
> >> Release tag  = ltib-e500mc-20080827
> >>    The ISO tag name (descriptive)
> >> App version  = 8.1.2
> >>    ltib script release version
> >> CVS version  = $Revision: 1.393 $
> >>    ltib script CVS version
> >>
> >> Note that this also gets written into the root filesystem as
> >> /etc/ltib-release.  When you first install an ISO without any changes,
> >> this will be the same as on the ISO.  However, if you modify and rebuild
> >> in anyway, this will get changed as it is no longer the _actual_ release.
> >>
> >> Regards, Stuart
> >>
> >> On 21/01/11 09:51, Andrea Galbusera wrote:
> >>> Hello,
> >>> I'm currently maintaining a series of ltib BSPs for an internal project.
> >>> We track BSP configuration changes and fixes with our company CVS
> >>> repository. For any new BSP release we use './ltib -m release'. This
> >>> works fine for us and provide a self contained copy of everything needed
> >>> for generating target images of any released BSP version. Branching and
> >>> tagging strategies we adopted are the same as described in
> >>> doc/LtibReleaseProcess. 
> >>>
> >>> Here comes my question: is there any reference to the release tag we
> >>> specify while running './ltib -m release' inside the rootfs image that
> >>> comes with the generated ISO? I thought this could have been in the
> >>> included /etc/ltib-release, but it does not seem so.
> >>>
> >>> My final goal is to read the BSP version from a running target: the most
> >>> desirable 'version string' would be the CVS tag corresponding to that
> >>> specific BSP version.
> >>>
> >>> Could anybody please elaborate on the /etc/ltib-release and RELEASE_INFO
> >>> files logic and how they get managed when ISO releasing with './ltib -m
> >>> release'?
> >>>
> >>> Thanks in advance
> >>> Regards,
> >>>
> >>>
> >>
> > 
> > 
> > 
>