[yocto] [meta-gplv2][PATCH] make: Do not assume glibc glob internals
glibc 2.27 hides them Signed-off-by: Khem Raj --- ...2-glob-Do-not-assume-glibc-glob-internals.patch | 36 ++ recipes-devtools/make/make_3.81.bb | 1 + 2 files changed, 37 insertions(+) create mode 100644 recipes-devtools/make/make-3.81/0002-glob-Do-not-assume-glibc-glob-internals.patch diff --git a/recipes-devtools/make/make-3.81/0002-glob-Do-not-assume-glibc-glob-internals.patch b/recipes-devtools/make/make-3.81/0002-glob-Do-not-assume-glibc-glob-internals.patch new file mode 100644 index 000..755be0b --- /dev/null +++ b/recipes-devtools/make/make-3.81/0002-glob-Do-not-assume-glibc-glob-internals.patch @@ -0,0 +1,36 @@ +From 9858702dbd1e137262c06765919937660879f63c Mon Sep 17 00:00:00 2001 +From: Paul Eggert +Date: Sun, 24 Sep 2017 09:12:58 -0400 +Subject: [PATCH 2/2] glob: Do not assume glibc glob internals. + +It has been proposed that glibc glob start using gl_lstat, +which the API allows it to do. GNU 'make' should not get in +the way of this. See: +https://sourceware.org/ml/libc-alpha/2017-09/msg00409.html + +* dir.c (local_lstat): New function, like local_stat. +(dir_setup_glob): Use it to initialize gl_lstat too, as the API +requires. +--- +Upstream-Status: Backport +which is so small that it's effectively public domain. + + configure.ac | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +Index: make-3.81/configure.in +=== +--- make-3.81.orig/configure.in make-3.81/configure.in +@@ -348,10 +348,9 @@ AC_CACHE_VAL(make_cv_sys_gnu_glob, [ + #include + #include + +-#define GLOB_INTERFACE_VERSION 1 + #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1 + # include +-# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION ++if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2 +gnu glob + # endif + #endif diff --git a/recipes-devtools/make/make_3.81.bb b/recipes-devtools/make/make_3.81.bb index b8a79b0..9fe22a8 100644 --- a/recipes-devtools/make/make_3.81.bb +++ b/recipes-devtools/make/make_3.81.bb @@ -9,6 +9,7 @@ require make.inc SRC_URI += "file://make_fix_for_automake-1.12.patch" SRC_URI += "file://makeinfo.patch" +SRC_URI += "file://0002-glob-Do-not-assume-glibc-glob-internals.patch" SRC_URI[md5sum] = "354853e0b2da90c527e35aabb8d6f1e6" SRC_URI[sha256sum] = "f3e69023771e23908f5d5592954d8271d3d6af09693cecfd29cee6fde8550dc8" -- 2.16.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Postinstallation script warnings in Yocto 2.4 Rocko
> You can set self.log_check_expected_regexes in RpmRootfs class in > meta/lib/oe/rootfs.py, but > > a) depending on how broad your regex is, you might suppress real failures of > the scriptlets; > > b) it would be only your local hack until the issue is resolved properly. > > Alex Can you detail how this would be done? Is it possible to append to 'log_check_expected_regex' from the .bb recipe that generates the warning? Or the only option is to patch the poky layer? Is there any way to remove these warnings in rocko without modifying the poky layer? (I cannot modify community layers) Thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Postinstallation script warnings in Yocto 2.4 Rocko
On 02/12/2018 01:40 PM, Diaz de Grenu, Jose wrote: Can you detail how this would be done? Is it possible to append to 'log_check_expected_regex' from the .bb recipe that generates the warning? Or the only option is to patch the poky layer? Is there any way to remove these warnings in rocko without modifying the poky layer? (I cannot modify community layers) You need to patch the layer, yes. But you can also send the patch to oe-core list, and it would be much less invasive than backporting the postinst_intercept stuff. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Printing DISTRO_NAME during OS boot
Hi,
I have two images defined, one is secure stripped and intended
for production, and the other one extends the production one by adding
different development tools.
They are both built using the same distro so the name printed during boot
is always the same.
Welcome to senic 0.1.9-1-g1692cb1!
...
senic 0.1.9-1-g1692cb1 senic-hub ttyS0
I would like to be able to easily distinguish which image has been
flashed and booted.
I've identified that the variable responsible for those prints is
$DISTRO_NAME.
So I've extended both of my image recipes with:
IMAGE_NAME =
"${IMAGE_BASENAME}-${MACHINE}-${DISTRO_VERSION}-${DATETIME}"
DISTRO_NAME = "${IMAGE_NAME}"
However that failed to end up in my image.
The checking the -e for the image shows the variable has
been correctly renamed:
# $DISTRO_NAME [5 operations]
# set /home/alan/senic-os/oe/meta/conf/bitbake.conf:715
# [_defaultval] "OpenEmbedded"
# set /home/alan/senic-os/oe/../meta-senic/conf/distro/senic.conf:1
# "senic"
# set /home/alan/senic-os/oe/meta/conf/documentation.conf:143
# [doc] "The long name of the distribution."
# set /home/alan/senic-os/oe/../meta-senic/recipes-core/images/
senic-os.bb:11
# "${IMAGE_NAME}"
# set /home/alan/senic-os/oe/../meta-senic/recipes-core/images/
senic-os-dev.bb:6
# "${IMAGE_NAME}"
# pre-expansion value:
# "${IMAGE_NAME}"
DISTRO_NAME="senic-os-dev-senic-hub-0.1.9-1-g1692cb1-20180212151325"
But the "Welcome to ... " remains the same.
I've grepped for "Welcome to" in all the layers without success.
Any ideas on how to achieve this?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Here is my BSP for the adzs-sc589-ezlite eval board.
On Thu, Feb 8, 2018 at 8:43 AM, Peter Spierenburg < peter.spierenb...@nautel.com> wrote: > I've created a board support package for the adzs-sc589-ezlite evaluation > board from Analog Devices. > Would you consider adding it to the layer index? http://layers.openembedded.org/layerindex/submit/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][auh 1/2] upgrade-helper.conf: add a template for easy deployment
From: Chang Rebecca Swee Fun Settings mentioned in the README have been ported over and now users are able to copy and start modifying for personal use cases. This file will served as a reference to minimize errors when users trying to create a new conf file by following the README. Signed-off-by: Chang Rebecca Swee Fun --- upgrade-helper.conf | 70 + 1 file changed, 70 insertions(+) create mode 100644 upgrade-helper.conf diff --git a/upgrade-helper.conf b/upgrade-helper.conf new file mode 100644 index 000..c9cc150 --- /dev/null +++ b/upgrade-helper.conf @@ -0,0 +1,70 @@ +# +# This file is your upgrade-helper configuration files and is where all local user +# settings specifically for AUH are placed. The comments in this file provide some +# guidelines to the options a new user to AUH tool might want to change. +# +# This file should be placed inside your BUILDDIR/upgrade-helper after initializing +# the OE build environment. +# +# Lines starting with the '#' character are commented out and in some cases the +# default values are provided as comments to show people example syntax. Enabling +# the option is a question of removing the # character and making any change to the +# variable as required. + +[maintainer_override] +# mails for recipe upgrades will go to john.doe instead of jane.doe, etc +# see also the global_maintainer_override option +jane@doe.com=john@doe.com +johhny.br...@bravo.com=john@doe.com + +[settings] +# recipes in blacklist will be skipped +blacklist=python glibc gcc + +# only recipes belonging to maintainers in whitelist will be attempted +maintainers_whitelist=jane@doe.com john@doe.com johhny.br...@bravo.com + +# email for all recipe upgrades will go to john.doe, except those listed +# in specific maintainer_override entries above +global_maintainer_override=john@doe.com + +# SMTP server +# Optional if your are running AUH locally +smtp=smtp.my-server.com:25 + +# from whom should the mails arrive +from=upgrade.hel...@my-server.com + +# who should get the status mail with statistics, at the end +status_recipients=john@doe.com + +# specify the directory where work (patches) will be saved (optional) +#workdir= + +# publish url to use in statistics summary (optional) +#publish_work_url=http://auh.somehost.com/work + +# clean sstate directory before upgrading +clean_sstate=yes + +# clean tmp directory before upgrading +clean_tmp=yes + +# Machines to test build with. +# Append _libc-name to test with alternative C library implementations +# e.g. qemux86_musl. +# +# Buildhistory and testimages will be created only for the first +# machine in the list, as otherwise it adds enormously to AUH run time. +machines=qemux86 qemux86_musl qemux86-64 qemuarm qemumips qemuppc + +# optional features +buildhistory=no +testimage=no +testimage_name=image-custom # defaults to core-image-sato + +# to enable upgrade recipes in a layer example for meta-intel +layer_mode=False +layer_name=meta-intel +layer_dir=DIR/meta-intel +layer_machines=intel-core2-32 intel-corei7-64 intel-quark -- 2.15.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][auh 2/2] Improve README and sample config file.
Specifically, add more information about various config settings,
add a few important points to README, and remove config file specifics
from README, so that there's only one source for what the settings are
(the sample config file).
Also comment out everything from the config file, so that those in a
hurry can take it into use immediately. Most settings are specific to
a maintainer, and so can't be provided in a 'generic' way.
Signed-off-by: Alexander Kanavin
---
README | 83 +--
upgrade-helper.conf | 85 +
2 files changed, 67 insertions(+), 101 deletions(-)
diff --git a/README b/README
index 4a8181f..4752dc6 100644
--- a/README
+++ b/README
@@ -27,67 +27,8 @@ Setup
undesirable ways.
2. Prepare a configuration file, by default in $BUILDDIR/upgrade-helper/
- upgrade-helper.conf, as below:
-
snip ---
-[maintainer_override]
-# mails for recipe upgrades will go to john.doe instead of jane.doe, etc
-# see also the global_maintainer_override option
-jane@doe.com=john@doe.com
-johhny.br...@bravo.com=john@doe.com
-
-[settings]
-# recipes in blacklist will be skipped
-blacklist=python glibc gcc
-
-# only recipes belonging to maintainers in whitelist will be attempted
-maintainers_whitelist=jane@doe.com john@doe.com johhny.br...@bravo.com
-
-# email for all recipe upgrades will go to john.doe, except those listed
-# in specific maintainer_override entries above
-global_maintainer_override=john@doe.com
-
-# SMTP server
-smtp=smtp.my-server.com:25
-
-# from whom should the mails arrive
-from=upgrade.hel...@my-server.com
-
-# who should get the status mail with statistics, at the end
-status_recipients=john@doe.com
-
-# specify the directory where work (patches) will be saved (optional)
-#workdir=
-
-# publish url to use in statistics summary (optional)
-#publish_work_url=http://auh.somehost.com/work
-
-# clean sstate directory before upgrading
-clean_sstate=yes
-
-# clean tmp directory before upgrading
-clean_tmp=yes
-
-# Machines to test build with.
-# Append _libc-name to test with alternative C library implementations
-# e.g. qemux86_musl.
-#
-# Buildhistory and testimages will be created only for the first
-# machine in the list, as otherwise it adds enormously to AUH run time.
-machines=qemux86 qemux86_musl qemux86-64 qemuarm qemumips qemuppc
-
-# optional features
-buildhistory=no
-testimage=no
-testimage_name=image-custom # defaults to core-image-sato
-
-# to enable upgrade recipes in a layer example for meta-intel
-layer_mode=False
-layer_name=meta-intel
-layer_dir=DIR/meta-intel
-layer_machines=intel-core2-32 intel-corei7-64 intel-quark
-
snip ---
+ upgrade-helper.conf. A sample file is provided in AUH source tree;
+ it can be used as-is, or tweaked further.
3. Enable distrodata and supply appropriate additional metadata. For
example, you could add the following to your conf/local.conf:
@@ -99,13 +40,13 @@ INHERIT =+ "distrodata"
WARNING: if you are using the default maintainers.inc file supplied
with Poky (in meta-yocto) and you don't set a
maintainers_whitelist or (global_)maintainer_override in the
- upgrade-helper configuration as above, and you specify "all"
+ upgrade-helper configuration as above, and you specify "-e all"
on the command line, the script will automatically send out
emails to the default maintainers. Please be careful not to
do this :)
-4. If you want to enable buildhistory (optional) you need to enable in
-upgrade-helper.conf also add the following lines to your conf/local.conf
+4. If you want to enable buildhistory (optional) you need to enable it in
+upgrade-helper.conf, and also add the following lines to your conf/local.conf
file:
--- snip ---
@@ -135,10 +76,6 @@ a vncserver example:
$ vncserver :1
$ export DISPLAY=:1
-If upgrade is succesful testimage/ptest results are generated into
-$BUILDDIR/upgrade-helper/work/recipe/ptest_recipe.log if recipe support
-ptest.
-
(Do not remove any other inherited class in the process, e.g. distrodata).
Usage
@@ -152,10 +89,18 @@ Some manual usage examples:
* To upgrade the xmodmap recipe to a user specified version:
$ upgrade-helper.py xmodmap -t 1.2.3
+* To upgrade all recipes to latest available versions, without
+ sending any emails:
+$ upgrade-helper.py all
+
* To attempt to upgrade all recipes and automatically send email
messages to maintainers for each attempted recipe as well as a
status mail at the end, use:
-$ upgrade-helper.py all
+$ upgrade-helper.py -e all
+
+The results of the AUH run (patches, logs and any other relevant information)
+are then found in ${BUILDDIR}/upgrade-helper/. AUH will also
+create recipe update commits from successful upgrade attempts in the layer
tree.
[yocto] Yocto Project Status WW07’18
Current Dev Position: YP 2.5 M3 development Next Deadline: YP 2.5 M3 cut off is 2/19/18 SWAT team rotation: Paul -> Tracy on Feb. 9, 2018. SWAT team rotation: Tracy -> Stephano on Feb. 16, 2018. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.5 M2 is currently undergoing QA and nearly complete. See: https://wiki.yoctoproject.org/wiki/2.5_QA_Status · YP 2.2.3 is also mostly through QA. See https://wiki.yoctoproject.org/wiki/2.2_QA_Status. T · Holidays mean that QA is slowed, we will QA 2.4.2 as soon as they return. · autobuilder.yoctoproject.org continues to be unavailable as we continue to develop the new autobuilder codebase to replace the current heavily customized buildbot one. · Some positive performance news is that by removing the “fetchall” and “checkuriall” tasks, we were able to take “bitbake core-image-sato -g” from 20s to around 8s. The speedup comes from the runqueue calculation so most builds will benefit from this speedup. The tasks are replaced by a dedicated bitbake option, --runall=. · Kernel updates have been blocked as some image sizes have overflowed the maximum allowed image sizes. We’re working on figuring out how to resolve that, likely by stripping ltp and/or optimising the kernel-devsrc recipe if possible. · The glibc change is blocked on various build failures the code seems to trigger as well as issues with gplv2 vs gplv3 patches for meta-gplv2. Planned upcoming dot releases: YP 2.4.2 (Rocko) will be built shortly, once there is QA bandwidth available. YP 2.3.4 (Pyro) will be built when we figure out gcc backports. YP 2.2.3 (Morty) rc2 is in QA. YP 2.2.4 (Morty) will be built when we figure out gcc backports. Key YP 2.5 Dates are: YP 2.5 M2 cut off is past, it is in QA. YP 2.5 M2 release of 1/26/18 YP 2.5 M3 cut off of 2/19/18 YP 2.5 M3 release of 3/2/18 YP 2.5 M4 cut off of 4/2/18 YP 2.5 M4 release of 4/27/18 Tracking Metrics: WDD 2610 (last week 2638) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Release Engineer INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 • Work Telephone: (503) 712-0534 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Reg: interrupt enabling
Hi, I’ m working on imx6ull yocto project. I would like to configure a gpio pin as interrupt source to trigger ecspi. I have configured ecspi and it’s working fine. Now I have to trigger it using an interrupt. How to do that? Regards Mathew -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
