LICENSE file checksum changed do to a verbage change.
Changes to code
zic no longer generates binary files containing POSIX TZ-like
strings that disagree with the local time type after the last
explicit transition in the data. This fixes a bug with
Africa/Casablanca and Africa/El_Aaiun in some year-2037 time
stamps on the reference platform. (Thanks to Alexander Belopolsky
for reporting the bug and suggesting a way forward.)
If the installed localtime and/or posixrules files are symbolic
links, zic now keeps them symbolic links when updating them, for
compatibility with platforms like OpenSUSE where other programs
configure these files as symlinks.
zic now avoids hard linking to symbolic links, avoids some
unnecessary mkdir and stat system calls, and uses shorter file
names internally.
zdump has a new -i option to generate transitions in a
more-compact but still human-readable format. This option is
experimental, and the output format may change in future versions.
(Thanks to Jon Skeet for suggesting that an option was needed,
and thanks to Tim Parenti and Chris Rovick for further comments.)
Changes to build procedure
An experimental distribution format is available, in addition
to the traditional format which will continue to be distributed.
The new format is a tarball tzdb-VERSION.tar.lz with signature
file tzdb-VERSION.tar.lz.asc. It unpacks to a top-level directory
tzdb-VERSION containing the code and data of the traditional
two-tarball format, along with extra data that may be useful.
(Thanks to Antonio Diaz Diaz, Oscar van Vlijmen, and many others
for comments about the experimental format.)
The release version number is now more accurate in the usual case
where releases are built from a Git repository. For example, if
23 commits and some working-file changes have been made since
release 2016g, the version number is now something like
'2016g-23-g50556e3-dirty' instead of the misleading '2016g'.
Official releases uses the same version number format as before,
e.g., '2016g'. To support the more-accurate version number, its
specification has moved from a line in the Makefile to a new
source file 'version'.
The experimental distribution contains a file to2050.tzs that
contains what should be the output of 'zdump -i -c 2050' on
primary zones. If this file is available, 'make check' now checks
that zdump generates this output.
'make check_web' now works on Fedora-like distributions.
Changes to documentation and commentary
tzfile.5 now documents the new restriction on POSIX TZ-like
strings that is now implemented by zic.
Comments now cite URLs for some 1917-1921 Russian DST decrees.
(Thanks to Alexander Belopolsky.)
tz-link.htm mentions JuliaTime (thanks to Curtis Vogt) and Time4J
(thanks to Meno Hochschild) and ThreeTen-Extra, and its
description of Java 8 has been brought up to date (thanks to
Stephen Colebourne). Its description of local time on Mars has
been updated to match current practice, and URLs have been updated
and some obsolete ones removed.
(From OE-Core rev: 19c365b23c3b835dcb5595aba598f35bf16a6d81)
(From OE-Core rev: f5213870101ab57eb6303290c57935aed40cd9c4)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
Poky is an integration of various components to form a complete prepackaged build system and development environment. It features support for building customised embedded device style images. There are reference demo images featuring a X11/Matchbox/GTK themed UI called Sato. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK with IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of layers which extend the systems capabilities in a modular way.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at: http://yoctoproject.org/documentation
OpenEmbedded-Core is a layer containing the core metadata for current versions of OpenEmbedded. It is distro-less (can build a functional image with DISTRO = "nodistro") and contains only emulated machine support.
For information about OpenEmbedded, see the OpenEmbedded website: http://www.openembedded.org/
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
bitbake: Git repository: http://git.openembedded.org/bitbake/ Mailing list: bitbake-devel@lists.openembedded.org
documentation: Git repository: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/ Mailing list: yocto@yoctoproject.org
meta-yocto(-bsp): Git repository: http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto(-bsp) Mailing list: poky@yoctoproject.org
Everything else should be sent to the OpenEmbedded Core mailing list. If in doubt, check the oe-core git repository for the content you intend to modify. Before sending, be sure the patches apply cleanly to the current oe-core git repository.
Git repository: http://git.openembedded.org/openembedded-core/
Mailing list: openembedded-core@lists.openembedded.org
Note: The scripts directory should be treated with extra care as it is a mix of oe-core and poky-specific files.