Regards, Stuart
Peter Barada wrote:
> On Fri, 2009-11-06 at 17:29 +0000, Stuart Hughes wrote:
>> Hi Peter,
>>
>> If you can send me a new patch that would help. A flag in .ltibrc to
>> indicate times are local would be fine, the default (no entry at all)
>> should be to GMT (UTC).
>
> Attached.
>
> 1) re-factored ELF generation.
>
> 2) Fixes the absolute prefixing to only apply when creating symbolic
> link in rpm/SOURCES/
>
> 3) Added flag in .ltibrc to modify gm_yyyymmdd() to return localtime IFF
> flag %use_localdir is set and non-zero. My perl foo is not super stong
> so I brute-forced it.
>
> Example flag usage in .ltibrc:
>
> # If %use_localtime is set, and non-zero, then timestamps are in localtime, not GMT
> %use_localtime
> 1
>
>
>> Regards, Stuart
>>
>> Peter Barada wrote:
>> > On Fri, 2009-11-06 at 16:07 +0000, Stuart Hughes wrote:
>> >> 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.
>> >
>> > In my case the granularity is only to a day, and isolated to the stamp
>> > on the file so I wouldn't expect much problem with it.
>> >
>> > As a compromise, would a patch that adds/uses a flag to .ltibrc to
>> > specify whether timestamps are in localtime or GMT be acceptable? Then
>> > the default can be GMT and users can choose which time refernce they
>> > want to use.....
>> >
>> >> For now I'll apply your proposed change to add $top to relative paths,
>> >> lets see if there is any fallout (regressions) and if so deal with it then.
>> > As I'm the only one (apparently) who needs this, lemme look at fixing
>> > the symbolic link creation in rpm/SOURCES instead. I'll get you
>> > something over the weekend.
>> >
>> >> I will re-factor deployment.lkc as discussed (as time permits).
>> >
>> > If you want, I can re-factor and resubmit the change....
>> >
>> >> 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> <mailto:address@hidden> <mailto:address@hidden>>
>> >> >> > Logic Product Development, Inc.
>> >> >> >
>> >> > --
>> >> > Peter Barada <address@hidden <mailto:address@hidden> <mailto:address@hidden> <mailto:address@hidden>>
>> >> > Logic Product Development, Inc.
>> >> >
>> > --
>> > 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.
>