A new default SUMMARY and DESCRIPTION was defined for any package that
previously did not contain one. This value is based on the original
SUMMARY_${PN} value.
The new default SUMMARY and DESCRIPTION is used as a basis for all of
the automatic summary and descriptions for the various package splits,
include ${PN}, ${PN}-dbg, ${PN}-dev, ${PN}-doc, and locales.
A recipe may also override any of the automatic summaries by simply
specifying the value.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Since local mirror fetches are always symlinked from the download directory
directly, there is no need for this premirrors hack which doesn't cover
mirrors and also abuses the localpath variable with inconsistent results.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When files are fetched from a mirror source that happens to be local,
ensure links are created for the file since subsequent fetch calls
can then follow the links to find files.
Any other approach such as the existing manipulations of localpath
internally to the fetcher are prone to errors, races and other issues.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When processing a cvs SRC_URI to a file:// mirror, the user and host information
will break the mirror processing. This patch addresses it by only constructing
valid urls.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add more detailed SUMMARY and DESCRIPTIONS to various graphics and
graphics related components. I've recently gotten question from users
what something is, or why it was needed.. this should go a long way toward
answering those questions.
Many of the descriptions were taken directly from the upstream location,
where one was not available the Debian packages were consulted for
information.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
The definition of NM was missing, causing certain configure calls to revert
to using the host system's version of NM. This can cause problems on some
MIPS based targets, but is theoretically wrong everywhere.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Updating for the sugarbay and beagleboard BSPs. To make the sugbay
inhert common-pc-64 generic config/changes/fixes it has been
branched in the kernel as yocto/standard/common-pc-64/sugarbar, as
a result, we'll bump the common-pc-64 to be yocto/standard/common-pc-64/base.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
And fix following issue caused by the upgrade
| Can't load '/build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib/perl/5.12.2/auto/File/Glob/Glob.so' for module File::Glob: /build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib/perl/5.12.2/auto/File/Glob/Glob.so: wrong ELF class: ELFCLASS32 at /build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib/perl/5.12.2/XSLoader.pm line 79.
| at /build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib/perl/5.12.2/File/Glob.pm line 96
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
* SRC_URI format:
the SRC_URI are extended to allow multiple src rev:
name=<name1>,<name2>,...<name-n>
branch=<branch1>,<branch2>,...,<branch-n>
also SRCREV can be defined with
SRCREV_<name1> = xxxxx
SRCREV_<name2> = xxxxx
* FetchData extention
to support multiple src rev, several FetchData data are added:
- FetchData.names: list of name in SRC_URI, one name per srcrev. name is the index of revision and branch
- FetchData.revisions: dictionary of name->revision.
- FetchData.branches: dictionary of name->branch.
For example, linux-yocto recipes becomes:
SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;branch=${KBRANCH},meta;name=machine,meta"
FetchData.names = ['machine', 'meta']
FetchData.revisions = { 'machine':xxxxx, 'meta':xxxxxx }
FetchData.branches = { 'machine':${KBRANCH}, 'meta':'meta'}
* generic revision handling extension
the related revision handling code in fetch2.__init__.py are changed accordingly. the major change is add name parameter to indicate which src rev to handling. originally there is one src rev per FetchData, so FetchData parameter is enough. now since one FetchData has multiple src rev, it is necessary to use FetchData + name to specifiy src rev.
* git extension
git fetcher are also revised to take advantage of the multiple src rev in FetchData. especially the download() method are enhanced to fetch multiple src rev.
* other fetcher (svn, hg, ...) does not support multiple src rev. they just sync the API to add name, and then simply ignore the name. no actually functional change
Signed-off-by: Yu Ke <ke.yu@intel.com>
Since we're now always providing the git source control files it becomes
pointless to handle the tarballs of specific git revisions so drop this
part of the fetcher.
Signed-off-by: Yu Ke <ke.yu@intel.com>
The git download method clones the git repository to the local machine. The unpack process
can be optimised to be a local to local machine clone or a direct readtree operation to the
destination using git.will clone git repo to local, so git unpack can be simplified
to only checkouting the code to the work dir. For fullclone case, we also
need to manually copy all the ref info, which is needed by the later do_kernel_checkout().
Rather than use hardlinks, we reference the repository using alternatives since the
download directory may be on a different filesystem.
[Change to use -s by Richard Purdie]
Signed-off-by: Yu Ke <ke.yu@intel.com>
Discovered that the manual was not making correctly due to a stray
</literallayout> statement. I removed this statement and the manual
now builds.
Signed-off-by: Scott Rifenbark <scott@scott-desktop.(none)>
Fixes [BUGID #692]
Previously the information dumped by the kernel configuration audit
scripts was only placed in log files. This isn't as useful as it
could be, since they are rarely checked. This change takes the
output from kconf_check and explicitly displays it to the user.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Fixes [BUGID #685]
Although not used if the in kernel uImage is booted, it is
a good idea to set the UBOOT_ENTRYPOINT just as the other
uImage based boards do.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Add manual check date for recipes whose upstream vesion could not be
found automatically.
Also update glib-2.0 tracking data.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
The longlinks patch is upstream and and be removed now
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
This package has been added from meta-openembedded committed by Koen Kooi.
Changes from the meta-openembedded version:
* Add SUMMARY
* Change dependence name: libusb
* Add PR
Signed-off-by: Jingdong Lu <jingdong.lu@windriver.com>
This package has been added from Open Embedded in order to replace sendmail.
Changes from the Open Embedded version:
* Update version to 1.4.23
* Add SUMMARY, LIC_FILES_CHKSUM
Signed-off-by: Jingdong Lu <jingdong.lu@windriver.com>
This package has been added from Open Embedded.
Changes from the Open Embedded version:
* Update version to 12.4(mailx has been replaced by heirloom-mailx)
* Add SUMMARY, LIC_FILES_CHKSUM
* Remove patch(install.patch)
Signed-off-by: Jingdong Lu <jingdong.lu@windriver.com>
fix [BUGID #675]
Similar to previous cronie changes, so far 'at' environment is also not
complete and only root user could trigger delayed tasks. Similar permission
changes are required for:
/etc/at.deny
/usr/bin/at
/var/spool/at/
/usr/bin/at is setgid to 'daemon', to differentiate with cronie. So move
'at' out of 'cron' (/var/spool/cron/at -> /var/spool/at)
another fix is to rename /etc/init.d/at to atd which is more widely used
in other distros (also required by LTP test cases)
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
fix [BUGID #673]
several cron related test cases in LTP reveals that our current cron recipe
is not complete:
a) a complete cron hierarchy better have:
/etc/crontab
/etc/cron.d
/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
b) for a normal user to use crontab command:
add a new group - crontab
/usr/bin/crontab is setgid to root:crontab
/var/spool/cron is owned by root:crontab
below are optional, and thus not included in the default setup:
/etc/cron.deny
/etc/cron.allow
cronie by default only allows root user to use crontab, if neither cron.deny
nor cron.allow exists. They are controlled by final policy deployed on the
product.
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Mark Hatle
Richard Purdie
Bruce Ashfield
Joshua Lock
Saul Wold
Scott Garman
Koen Kooi
Nitin A Kamble
Yu Ke
Scott Rifenbark
Dongxiao Xu
Jingdong Lu
Kevin Tian
Dexuan Cui