<div class="gmail_quote">On Wed, Nov 2, 2011 at 8:15 PM, Mark Hatle <span dir="ltr"><<a href="mailto:mark.hatle@windriver.com">mark.hatle@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/2/11 12:32 PM, Andrea Adami wrote:<br>
> On Mon, Oct 31, 2011 at 1:44 AM, Ni Qingliang <<a href="mailto:niqingliang@insigma.com.cn">niqingliang@insigma.com.cn</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:niqingliang@insigma.com.cn">niqingliang@insigma.com.cn</a>>> wrote:<br>
><br>
> I'd like the 'system level configuration' solution.<br>
><br>
> the /etc/localtime/ link can be done when packaging rootfs (using the<br>
> system level configuration).<br>
><br>
> On Fri, 2011-10-28 at 22:43 +0800, Mark Hatle wrote:<br>
> > Setting the default TZ for the image is something that should be done in a<br>
> post<br>
> > install script for the tzdata package or something similar.<br>
> ><br>
> > Since the /etc/localtime is usually a copy/hardlink or symlink to the timezone<br>
> > data we don't want to package it up. Instead we want to perform the actions<br>
> > that a program running on the target system itself would use to change the<br>
> timezone.<br>
> ><br>
> > So I think the easiest approach is to add a system level configuration<br>
> variable<br>
> > (set the default).<br>
> ><br>
> > Then use this variable to populate the configuration file that specifies the<br>
> > system timezone... and then use the post install process to check the contents<br>
> > of a text file.<br>
> ><br>
> > Alternatively do this via an initscript -- but for folks w/ read-only<br>
> > filesystems I'm not sure that will work.<br>
> ><br>
> > --Mark<br>
><br>
> <cut><br>
><br>
> Maybe I misunderstand "system level configuration" but in the meta-oe recipe we have<br>
><br>
> DEFAULT_TIMEZONE ?= "Europe/London"<br>
><br>
> Maybe UTC would be better?<br>
<br>
</div></div>To me no timezone (which is UTC) is preferable as the system designer can then<br>
set the timezone, externally to the package(s).<br>
<div class="im"><br>
> Note how the variable is weak thus can be overridden in local.conf.<br>
><br>
> Secondly, why do it as post-install or at image do_rootfs stage when we have set<br>
> the variable and are therefore able to provide sane defaults in do_install?<br>
<br>
</div>If it's done within a do_install, then the file (/etc/timezone) itself gets<br>
placed into the package. If it's in the package, then if/when someone upgrades<br>
the package from a feed the timezone gets reset to the previous value. That's a<br>
bug IMHO.<br></blockquote><div><br>Sure, I overlooked that!<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
If it's done as a post-install script, then the timezone configuration can be<br>
evaluated and if one isn't set -- or there is no timezone file -- then we can<br>
set it to UTC or a similar default timezone.. (the value in the DEFAULT_TIMEZONE<br>
variable is reasonable in this approach.)<br>
<div class="im"><br></div></blockquote><div>maybe "Factory" then?<br>See post-install script example: <br><a href="http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/timezone-data/timezone-data-2011k.ebuild">http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/timezone-data/timezone-data-2011k.ebuild</a><br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> Other points before starting to write a patch:<br>
> -why is the recipe in oe-core doing chown -R root:root ${D} ?<br>
<br>
</div>There was an issue with the way the timezone data was extracted/constructed that<br>
it was have all of the build system's uid/gid preserved in the copy to the final<br>
install directory -- so when packaging incorrect usernames and groups were fed<br>
into the process causing issues.<br>
<br>
A simple chown -R root:root ${D} ensured that all of the timezone data was owned<br>
by the root user (on the target).<br>
<div class="im"><br>
> -the logic around # libc is removing zoneinfo files from package<br>
> Is it only eglibc?<br></div></blockquote><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
</div>Timezone info is updated more often then the system libc. So the zoneinfo files<br>
are handled externally of the libc. This allows for easier updates over time..<br>
(This is my guess, as I'm not familiar with exactly what this comment refers to.)<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div>Comments in meta-oe recipe would suggest that apparently only eglibc is removing zoneinfo file.<br><br> # Only eglibc is removing zoneinfo files from package<br>
if [ "${LIBC}"x = "eglibc"x ] ; then<br> cp -pP "${S}/zone.tab" ${D}${datadir}/zoneinfo<br> cp -pP "${S}/iso3166.tab" ${D}${datadir}/zoneinfo<br> fi<code><br>
</code></div></div><br><br>Being that we need the files on first boot, I'm not against providing 'Factory' settings during image do_rootfs or even in base-files.<br>The settings of timezone and locale (and keyboard) are typically done by user on first boot, at least in graphical environments.<br>
<br>Thanks for your comments!<br><br>Regards<br><br><br>Andrea<br>