Hi Peter,
I understand your reluctance to use UTC (GMT), but I still think in the
log run that will cause less confusion. If you just want a timestamp,
who about using the 'time' seconds since the epoch? Anyhow I can
foresee many issues if you use localtime, so although there's no
right/wrong wrt it would please me to go with something based on UTC.
I understand the implications of using localtime, especially if development is spread out across timezones. Seconds since epoch would certainly work, but is quite cumbersome for users I distribute images to that don't understand how to convert back-n-forth from localtime.
Regards, Stuart
Peter Barada wrote:
> On Fri, 2009-11-06 at 09:13 +0000, Stuart Hughes wrote:
>> Hi Peter,
>>
>> Thanks for the patches. I need to take a closer look (maybe over the
>> w/e) but here's some initial comments/questions for you:
>>
>> ---+ bin/Ltibutils.pm
>>
>> I don't like the idea of using localtime as timestamps when making ELF
>> images. The reason is this will confuse people as it's inconsistent
>> with all other timestamps used in LTIB and also without a timezone it
>> can't be given an absolute reference. I'd advise switching to gm_yyyymmdd.
>
> In my timezone (GMT+5), its quite aggravating to do a build a 6:59pm and
> get one date, but then a build at 7:01pm produces tomorrows date. The
> date is only used in the ELF image name to stamp it.
>
> The reason for the date is so ELF images I create are anchored by date
> which makes it much easier to track when bugs pop up (by bisecting tests
> using all images to date(thanks to really cheap disc space!)) as well as
> easily have developers/users "keep up" with feature additions.
>
> The only place gm_yyyymmdd() is used is in Ltibrelease.pm::release_main.
> The same functionality (i.e. calling gmtime) is replicated in multiple
> places (autobuild, listpkginfo, mk_pkg_results).
>
>> I think prefixing relative paths with $top in parse_config is probably
>> okay, but I'm surprised it is needed as ltib is always run from the top
>> directory? Even if it doesn't do any harm, I'm a bit worried that this
>> could break other configs if they run from a different directory and
>> assume that current working directory. (I can't remember if anything
>> else uses this function).
> In my %ldirs I have:
>
> /var/ltmp/pkgs
> /opt/freescale/pkgs
> my-package-pool
>
> and if I have the yaffs_utils-20060418-mkyaffs2image.patch patch in
> my-package-pool, and w/o the change to prefix the relative path, adding
> a print of $getcwd() and $path right before the "if (-f $path) {"
> statement in get_file(), then I see the following output:
>
> address@hidden:~/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102$ ./ltib -p yaffs-utils.spec -m prep
>
> Processing: yaffs-utils
> =========================
> Build path taken because: build key set, no prebuilt rpm,
> pwd: /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102 path: /opt/ltib/pkgs/yaffs_utils-20060418-mkyaffs2image.patch
> pwd: /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102 path: /var/tmp/pkgs/yaffs_utils-20060418-mkyaffs2image.patch
> pwd: /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102 path: /opt/freescale/pkgs/yaffs_utils-20060418-mkyaffs2image.patch
> pwd: /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102 path: my-package-pool/yaffs_utils-20060418-mkyaffs2image.patch
> Testing network connectivity
> OK GPP:
>
> Try yaffs_utils-20060418-mkyaffs2image.patch.md5 from the GPP
> http://bitshrine.org/gpp/yaffs_utils-20060418-mkyaffs2image.patch.md5:
> 10:23:48 ERROR 404: Not Found.
> WARN: skipping md5sum check for lpd-IP-package-pool/yaffs_utils-20060418-mkyaffs2image.patch, md5 file was not found
>
> rpmbuild --dbpath /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rootfs//var/lib/rpm --target arm --define '_unpackaged_files_terminate_build 0' --define '_target_cpu arm' --define '__strip strip' --define '_topdir /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rpm' --define '_prefix /usr' --define '_tmppath /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/tmp' --define '_rpmdir /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rpm/RPMS' --define '_mandir /usr/share/man' --define '_sysconfdir /etc' --define '_localstatedir /var' -bp /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/dist/lfs-5.1/yaffs-utils/yaffs-utils.spec
> Building target platforms: arm
> Building for target arm
> error: File /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rpm/SOURCES/yaffs_utils-20060418-mkyaffs2image.patch: No such file or directory
> Build time for yaffs-utils: 0 seconds
>
> Failed building yaffs-utils
>
>
> f_prep() returned an error, exiting
> traceback:
> main:561
>
> Exiting on error or interrupt
>
>
> so get_file works fine w/o the change. The failure is because
> rpm/SOURCES/yaffs_utils-20060418-mkyaffs2image.patch is a symbolic link
> to "my-package-pool/yaffs_utils-20060418-mkyaffs2image.patch" using a
> relative path, which causes rpm to fail as the symbolic link is valid
> IFF the cwd (when accessing that file) is the top-level LTIB directory.
> I think rpm changes its working directory to "rpm/BUILD" which would
> cause accessing that file to fail....
>
> I'll look at prefixing $top in the symbolic link creation, not in
> get_file itself and see what happens in my LTIB usage....
>
>
>> ---+ config/userspace/deployment.lkc
>>
>> I can see what you're doing with the logic for primary deployment style
>> + elf. If I understand correctly if your platform has an elf capability
>> then you want to build that as well as your primary choice. If so then
>> I think it would be better to re-factor this. Put it back as was, add
>> yaffs2 to the 'root filesystem image type' choice-list and add a new
>> independent section below it like this:
>>
>> if CAP_DEPLOYMENT_ELF && (DEPLOYMENT_JFFS2
>> || DEPLOYMENT_YAFFS2
>> || DEPLOYMENT_RAMDIS)
>> config DEPLOYMENT_ELF
>> bool "build an combined elf image"
>> endif
>>
>> If you agree I can make that change.
>
> Yes, on my platform I want to optionally build the ELF file as well as
> the rootfs, and in the case of a ramdisk, combine it into the ELF file
> (as the other rootfs images would reside on non-volatile storage).
>
> Your refactoring makes perfect sense to me.
>
>> Aside from that it looks okay so far.
>>
>> Regards, Stuart
>>
>>
>> Peter Barada wrote:
>> > Stuart,
>> >
>> > The attached patch adds YAFFS2 as a deployment method to the current
>> > LTIB (actually LTIB as checked out 20091102), as well as patches to
>> > yaffs-utils-20060418 to allow for mkfsyaffs2image to be built and take
>> > args that allow a device table.
>> >
>> > I've purposely left the original mkyaffsimage code alone (and did not
>> > add a YAFFS deployment method) as I don't have a target with small-block
>> > NAND to test that functionality with, but it should be failry simple to add.
>> >
>> > The patch to deployment.lkc and bin/Ltibutils.pm also adds in ELF
>> > support, as in have LTIB create an ELF file of the resultant
>> > u-boot/kernel or u-boot/kernel/ramdisk using a Makefile in
>> > config/platform/__platform__/elf-image, and the ELF creation capability
>> > is enabled if the platform's main.lkc contains:
>> >
>> > # Can deploy an ELF image.
>> > config CAP_DEPLOYMENT_ELF
>> > bool
>> > default y
>> >
>> >
>> > If this capability is not present then the code should act as it does
>> > now (with the addition of creation of a YAFFS2 rootfs image). My target
>> > has LoLo as its boot loader, so to boot linux I need to load
>> > u-boot/kernel and exec u-boot (which then uses bootm witht he address of
>> > where the kernel was loaded as part of the ELF file) so I need the ELF
>> > deployment method. I can provide the Makefile/utilities for my target
>> > to link together u-boot/kernel/rootfs into a single ELF file if anyone
>> > is interested.
>> >
>> > I've been thinking about the sector/spare/erase size configuration for
>> > YAFFS (and the erase size for JFFS2), and I'm starting to convince
>> > myself that these variables should be in a platform's main.lkc as
>> > constants. The patch to yaffs-utils doesn't have any sector/page/block
>> > size information in it, I'll generate that later and have mkyaffs2image
>> > take advantage of it.
>> >
>> > Hopefully people will find this useful.
>> >
>> > --
>> > Peter Barada <address@hidden <mailto:address@hidden> <mailto:address@hidden>>
>> > Logic Product Development, Inc.
>> >
> --
> Peter Barada <address@hidden <mailto:address@hidden>>
> Logic Product Development, Inc.
>