Re: [Ltib] BSP releases and repository tags

[Stuart Hughes]

Hi Andrea,

On 24/01/11 16:02, Andrea Galbusera wrote:
> 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!

Yes it probably is the reason.  To be honest because the ltib-release
that goes into the target image is changed on every build, it's probably
not that useful for releases.  The primary purpose of this is to track
builds during development (to know where a particular image came from).
 In all likelihood if you release a BSP iso, it will get rebuilt and
this file will change.  It is a bug, but probably not a high priority to
fix.  The simplest fix would probably be to drop a copy of the "real"
release info into the rootfs after it has been built (overwrite the one
from the build in the case of releases).  I do not have time to do this
right now.


> 
> 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
> 

That is just an omission, it could be easily added.

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

Please feel free to send patches to fix these issues against the
mainline version.

Regards, Stuart


> 
>> 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,
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
>