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>
<mailto:address@hidden>>
>> >> >> > Logic Product Development, Inc.
>> >> >> > >> >> > -- >> >> > 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.
>