Re: [OE-core] rpm generation question

[Mark Hatle]

On 4/19/16 7:15 PM, Tudor Florea wrote:
> 
> 
> On 19/04/2016 21:02, Mark Hatle wrote:
>> On 4/19/16 12:05 PM, Tudor Florea wrote:
>>> As part of our test infrastructure we're attempting to install ptest
>>> packages (and execute the tests accordingly).
>>> Attempting to install ptest for valgrind fails with this error:
>>>
>>> error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
>>> provides /this/is/a/bogus/interpreter/name
>>
>> You can turn off the file level requires and provides on a per package basis.
>>
>> SKIP_FILEDEPS_${PN}-ptest = '1'
> 
> Mark,
> Thank you for the information provided.
> Unfortunately this did not work as expected.
> First issue: the dependency on bogus interpreter still exists with the
> line above.
> I was able to force remove this dependency by setting
> MERGEPERFILEDEPS = "0"
> on meta/classes/package_rpm.bbclass. Of course this is not a fix but
> only a test. I'm not sure if there is something missing around.
> 
> The second issue: The rpm created this way can be installed using the
> command:
> rpm -ivH ./valgrind-ptest-3.11.0-r0.4.ppce500mc.rpm
> but still fails when attempt to install using smart.
> 
> Is this second issue a bug or smart is supposed to work this way?

What is the error with smart.  If it's the same dependency error then it almost
sounds like the feed database is out of sync.

--Mark

> 
> Thank you,
>  Tudor.
> 
>>
>> Otherwise (for rpm packages) the system will attempt to discover and use the
>> per-file interpreter and other dependencies.  Since ptest is only tests, and 
>> the
>> dependencies here are specific to tests -- it should be safe to disable them.
>>
>> (If that isn't the right approach for some reason, there are some other ways 
>> to
>> do a file level provide, but they're significantly more complicated and 
>> rarely
>> used.)
>>
>> --Mark
>>
>>>
>>> smart install valgrind-ptest-3.11.0-r0.1@ppce500mc
>>> Loading cache...
>>> Updating cache...
>>> ###
>>> [100%]
>>>
>>> Computing transaction...
>>>
>>>  error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
>>> provides /this/is/a/bogus/interpreter/name
>>>
>>>
>>> This is most probably caused by the file shell_badinterp contained in
>>> this package having the following contents:
>>>
>>> #! /this/is/a/bogus/interpreter/name
>>>
>>> true
>>>
>>> Does anyone have an idea how to get rid of this error?
>>> More specific: How can I exclude dependency on
>>> "/this/is/a/bogus/interpreter/name" for an rpm package?
>>>
>>> Thank you very much.
>>>   Tudor.
>>>
>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] create-pull-request: create branch on remote if not found

[Robert Yang]

Updated in the repo: (add option -a to auto push or set CONTRIB_AUTO_PUSH in 
env).

  git://git.openembedded.org/openembedded-core-contrib rbt/cpr
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/cpr

Robert Yang (3):
  create-pull-request: create branch on remote if not found
  create-pull-request: read remote from env var CONTRIB_REMOTE
  create-pull-request: set subject automatically for cover latter



commit 973264bfbe57f0d56ba58caf7924710f76bafca8
Author: Robert Yang 
Date:   Tue Apr 19 17:30:03 2016 -0700

create-pull-request: add option -a to auto push

Before this patch, we need two steps to create PULL:
* Step 1, create branch:
  $ git push  :
* Step 2, create PULL:
  $ create-pull-request -u  -l  -b  
-r ~


We can see that the args used in step 1 are in step 2, so we can use
"create-pull-request -a" or set CONTRIB_AUTO_PUSH in to create the
branch to simplify the steps.

[YOCTO #9408]

Signed-off-by: Robert Yang 

diff --git a/scripts/create-pull-request b/scripts/create-pull-request
index 479ad6e..595fda0 100755
--- a/scripts/create-pull-request
+++ b/scripts/create-pull-request
@@ -39,6 +39,8 @@ Usage: $CMD [-h] [-o output_dir] [-m msg_body_file] [-s 
subject] [-r relative_to

   -l local branch Local branch name (default: HEAD)
   -c  Create an RFC (Request for Comment) patch series
   -h  Display this help message
+  -a  Automatically push local branch (-l) to remote branch 
(-b),
+  or set CONTRIB_AUTO_PUSH in env
   -i commit_idEnding commit (default: HEAD)
   -m msg_body_fileThe file containing a blurb to be inserted into the 
summary email
   -o output_dir   Specify the output directory for the messages (default: 
pull-PID)

@@ -59,7 +61,7 @@ EOM
 }

 # Parse and validate arguments
-while getopts "b:cd:hi:m:o:p:r:s:u:l:" OPT; do
+while getopts "b:acd:hi:m:o:p:r:s:u:l:" OPT; do
case $OPT in
b)
BRANCH="$OPTARG"
@@ -127,6 +129,9 @@ while getopts "b:cd:hi:m:o:p:r:s:u:l:" OPT; do
;;
esac
;;
+   a)
+   CONTRIB_AUTO_PUSH="1"
+   ;;
esac
 done

@@ -171,6 +176,11 @@ esac
 # Perform a sanity test on the web URL. Issue a warning if it is not
 # accessible, but do not abort as users may want to run offline.
 if [ -n "$WEB_URL" ]; then
+   if [ "$CONTRIB_AUTO_PUSH" = "1" ]; then
+   echo "Pushing '$BRANCH' on '$REMOTE' as requested..."
+   git push $REMOTE $L_BRANCH:$BRANCH
+   echo ""
+   fi
wget --no-check-certificate -q $WEB_URL -O /dev/null
if [ $? -ne 0 ]; then
echo "WARNING: Branch '$BRANCH' was not found on the contrib 
git tree."


// Robert


On 04/19/2016 08:18 PM, Bruce Ashfield wrote:



On Mon, Apr 18, 2016 at 11:13 PM, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:



On 04/19/2016 11:00 AM, Bruce Ashfield wrote:



On Mon, Apr 18, 2016 at 10:45 PM, Robert Yang mailto:liezhi.y...@windriver.com>
>>
wrote:

 Before this patch, we need two steps to create PULL:
 * Step 1, create branch:
$ git push  :
 * Step 2, create PULL:
$ create-pull-request -u  -l  -b

 -r ~

 We can see that the args used in step 1 are in step 2, so we can 
use
 create-pull-request to create the branch if not found to simplify 
the
 steps.


I think this needs to be optional. When I'm running this script, I'm 
just
looking to have something
I've already pushed locally dumped. If I mess up, and don't have the
branch that
I've used
pushed to my remote already (or for  whatever reason want/need different
branches .. which
was broken in previous updates to the script .. grrr),  I don't want
something
pushing a branch
without be explicitly giving permission for that to happen.


Thanks, how about add an option:

"-a automatically push/update local branch (-l) to remote branch (-b)"

Then it will always create/update the remote branch when -a is used.


That would meet my requirement. So looks fine to me. Others of course have the
right to object :)

Cheers,

Bruce


// Robert


Bruce


 [YOCTO #9408]

 Signed-off-by: Robert Yang mailto:liezhi.y...@windriver.com>
 >>

 ---
   scripts/create-pull-request | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/scripts/create-pull-request 
b/scripts/create-pull-request
 index 479ad6e..7dc9836 100755
  

Re: [OE-core] rpm generation question

[Tudor Florea]

On 19/04/2016 21:02, Mark Hatle wrote:
> On 4/19/16 12:05 PM, Tudor Florea wrote:
>> As part of our test infrastructure we're attempting to install ptest
>> packages (and execute the tests accordingly).
>> Attempting to install ptest for valgrind fails with this error:
>>
>> error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
>> provides /this/is/a/bogus/interpreter/name
> 
> You can turn off the file level requires and provides on a per package basis.
> 
> SKIP_FILEDEPS_${PN}-ptest = '1'

Mark,
Thank you for the information provided.
Unfortunately this did not work as expected.
First issue: the dependency on bogus interpreter still exists with the
line above.
I was able to force remove this dependency by setting
MERGEPERFILEDEPS = "0"
on meta/classes/package_rpm.bbclass. Of course this is not a fix but
only a test. I'm not sure if there is something missing around.

The second issue: The rpm created this way can be installed using the
command:
rpm -ivH ./valgrind-ptest-3.11.0-r0.4.ppce500mc.rpm
but still fails when attempt to install using smart.

Is this second issue a bug or smart is supposed to work this way?


Thank you,
 Tudor.

> 
> Otherwise (for rpm packages) the system will attempt to discover and use the
> per-file interpreter and other dependencies.  Since ptest is only tests, and 
> the
> dependencies here are specific to tests -- it should be safe to disable them.
> 
> (If that isn't the right approach for some reason, there are some other ways 
> to
> do a file level provide, but they're significantly more complicated and rarely
> used.)
> 
> --Mark
> 
>>
>> smart install valgrind-ptest-3.11.0-r0.1@ppce500mc
>> Loading cache...
>> Updating cache...
>> ###
>> [100%]
>>
>> Computing transaction...
>>
>>  error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
>> provides /this/is/a/bogus/interpreter/name
>>
>>
>> This is most probably caused by the file shell_badinterp contained in
>> this package having the following contents:
>>
>> #! /this/is/a/bogus/interpreter/name
>>
>> true
>>
>> Does anyone have an idea how to get rid of this error?
>> More specific: How can I exclude dependency on
>> "/this/is/a/bogus/interpreter/name" for an rpm package?
>>
>> Thank you very much.
>>   Tudor.
>>
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][master][krogoth][jethro][fido 2/2] tzdata: update to 2016d

[Armin Kuster]

From: Armin Kuster 

Changes affecting future time stamps

America/Caracas switches from -0430 to -04 on 2016-05-01 at 02:30.
(Thanks to Alexander Krivenyshev for the heads-up.)

Asia/Magadan switches from +10 to +11 on 2016-04-24 at 02:00.
(Thanks to Alexander Krivenyshev and Matt Johnson.)

New zone Asia/Tomsk, split off from Asia/Novosibirsk. It covers
Tomsk Oblast, Russia, which switches from +06 to +07 on 2016-05-29
at 02:00.  (Thanks to Stepan Golosunov.)

Changes affecting past time stamps

New zone Europe/Kirov, split off from Europe/Volgograd.  It covers
Kirov Oblast, Russia, which switched from +04/+05 to +03/+04 on
1989-03-26 at 02:00, roughly a year after Europe/Volgograd made
the same change.  (Thanks to Stepan Golosunov.)

Russia and nearby locations had daylight-saving transitions on
1992-03-29 at 02:00 and 1992-09-27 at 03:00, instead of on
1992-03-28 at 23:00 and 1992-09-26 at 23:00.  (Thanks to Stepan
Golosunov.)

Many corrections to historical time in Kazakhstan from 1991
through 2005.  (Thanks to Stepan Golosunov.)  Replace Kazakhstan's
invented time zone abbreviations with numeric abbreviations.

Signed-off-by: Armin Kuster 
---
 meta/recipes-extended/tzdata/{tzdata_2016c.bb => tzdata_2016d.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/tzdata/{tzdata_2016c.bb => tzdata_2016d.bb} (98%)

diff --git a/meta/recipes-extended/tzdata/tzdata_2016c.bb 
b/meta/recipes-extended/tzdata/tzdata_2016d.bb
similarity index 98%
rename from meta/recipes-extended/tzdata/tzdata_2016c.bb
rename to meta/recipes-extended/tzdata/tzdata_2016d.bb
index 5eb85b7..627a31a 100644
--- a/meta/recipes-extended/tzdata/tzdata_2016c.bb
+++ b/meta/recipes-extended/tzdata/tzdata_2016d.bb
@@ -8,8 +8,8 @@ DEPENDS = "tzcode-native"
 
 SRC_URI = 
"http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata";
 
-SRC_URI[tzdata.md5sum] = "0330ccd16140d3b6438a18dae9b34b93"
-SRC_URI[tzdata.sha256sum] = 
"8700d981e6f2007ac037dabb5d2b12f390e8629bbc30e564bc21cf0c069a2d48"
+SRC_URI[tzdata.md5sum] = "14bf84b6c2cdab0a9428991e0150ebe6"
+SRC_URI[tzdata.sha256sum] = 
"d9554dfba0efd76053582bd89e8c7036ef12eee14fdd506675b08a5b59f0a1b4"
 
 inherit allarch
 
-- 
2.3.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][master][krogoth][jethro][fido 1/2] tzcode: update to 2016d

[Armin Kuster]

From: Armin Kuster 

they keep the versions in-sync. changes are all in data.

Changes affecting future time stamps

America/Caracas switches from -0430 to -04 on 2016-05-01 at 02:30.
(Thanks to Alexander Krivenyshev for the heads-up.)

Asia/Magadan switches from +10 to +11 on 2016-04-24 at 02:00.
(Thanks to Alexander Krivenyshev and Matt Johnson.)

New zone Asia/Tomsk, split off from Asia/Novosibirsk. It covers
Tomsk Oblast, Russia, which switches from +06 to +07 on 2016-05-29
at 02:00.  (Thanks to Stepan Golosunov.)

Changes affecting past time stamps

New zone Europe/Kirov, split off from Europe/Volgograd.  It covers
Kirov Oblast, Russia, which switched from +04/+05 to +03/+04 on
1989-03-26 at 02:00, roughly a year after Europe/Volgograd made
the same change.  (Thanks to Stepan Golosunov.)

Russia and nearby locations had daylight-saving transitions on
1992-03-29 at 02:00 and 1992-09-27 at 03:00, instead of on
1992-03-28 at 23:00 and 1992-09-26 at 23:00.  (Thanks to Stepan
Golosunov.)

Many corrections to historical time in Kazakhstan from 1991
through 2005.  (Thanks to Stepan Golosunov.)  Replace Kazakhstan's
invented time zone abbreviations with numeric abbreviations.

Signed-off-by: Armin Kuster 
---
 .../tzcode/{tzcode-native_2016c.bb => tzcode-native_2016d.bb} | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-extended/tzcode/{tzcode-native_2016c.bb => 
tzcode-native_2016d.bb} (68%)

diff --git a/meta/recipes-extended/tzcode/tzcode-native_2016c.bb 
b/meta/recipes-extended/tzcode/tzcode-native_2016d.bb
similarity index 68%
rename from meta/recipes-extended/tzcode/tzcode-native_2016c.bb
rename to meta/recipes-extended/tzcode/tzcode-native_2016d.bb
index 06b92ea..647ce2d 100644
--- a/meta/recipes-extended/tzcode/tzcode-native_2016c.bb
+++ b/meta/recipes-extended/tzcode/tzcode-native_2016d.bb
@@ -8,10 +8,10 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=76ae2becfcb9a685041c6f166b44c2c2"
 SRC_URI =" 
http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode
 \

http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata";
 
-SRC_URI[tzcode.md5sum] = "ffb82ab0b588138759902b4627a6a80d"
-SRC_URI[tzcode.sha256sum] = 
"344b1bd486935bca2b7baa47db3b99b32211c45f31ec0d1ead8bacd103c5a416"
-SRC_URI[tzdata.md5sum] = "0330ccd16140d3b6438a18dae9b34b93"
-SRC_URI[tzdata.sha256sum] = 
"8700d981e6f2007ac037dabb5d2b12f390e8629bbc30e564bc21cf0c069a2d48"
+SRC_URI[tzcode.md5sum] = "06fc6fc111cd8dd681abdc5326529afd"
+SRC_URI[tzcode.sha256sum] = 
"a8f33d6f87aef7e109e4769fc7f6e63637d52d07ddf6440a1a50df3d9a34e0ca"
+SRC_URI[tzdata.md5sum] = "14bf84b6c2cdab0a9428991e0150ebe6"
+SRC_URI[tzdata.sha256sum] = 
"d9554dfba0efd76053582bd89e8c7036ef12eee14fdd506675b08a5b59f0a1b4"
 
 S = "${WORKDIR}"
 
-- 
2.3.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Andreas Müller]

On Tue, Apr 19, 2016 at 4:54 PM, Richard Purdie
 wrote:
> On Tue, 2016-04-19 at 16:11 +0200, Andreas Müller wrote:
>> thanks a lot for your efforts. Do I understand this right: You
>> suggest
>> to use build sysroot (on my own risk - as I did before) and make gdb
>> happy by linking sources?
>>
>> Problem I see is that we have multiple package archs e.g
>> ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
>> expands to multiple paths. But a script symlinking all together + set
>> substitute-path might help here...
>>
>> I will play around with this in the later...
>
> I was thinking about this a bit more and there is another option
> available to you which would be to pass all the debug sources into the
> sysroot as hardlinks to the files in workdir, in much the same way as
> we do the other sysroot files (which you don't strip).
>
> Since those files are collected by do_package you'd probably have to
> force do_populate_sysroot after do_package but such an additional class
> to make these tweaks probably wouldn't be that large and would just
> affect performance a bit (with the benefit of the debugging you want).
>
> Just thinking out loud really. My big worry is all the different
> codepaths we have people using, equally, you can't get performance
> (disk footprint and speed) and functionality in some cases and people
> do want to choose different compromises.
>
> Cheers,
>
> Richard
Yes such an option would make both possible and is worth spending
efforts: Releasable and properly linked debug sysroot/-dbg packs and
'quick' debugging on top of current build-sysroot.

I can't promise when (daily coding for food eats up my time) but I'll
try to get something to work on this matter. If this will lead to
something (and even if not), the chapter for remote debugging in docs
needs love. The IMAGE_GEN_DEBUGFS / IMAGE_FSTYPES_DEBUGFS can be taken
from this thread :).

I would like to append some notes how to remote debug with qt-creator
- it is really easy to set up and does so much - not only when
debugging qt applications...

Andreas
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] backports for jethro

[Tim Kilbourn]

What is the policy for backporting changes to released branches like
jethro? I'm hitting an issue that was fixed in 2015 on master, but
didn't get included in jethro 2.0.1. Is there any chance of having
this cherrypicked so I can get the fix from the jethro branch in git?

-
commit 9abcd309c098558360cde2bff65be840ead25f83
Author: Robert Yang 
Date:   Tue Nov 24 05:20:38 2015 -0800

boot-directdisk.bbclass: remove HDDIMG before create

Fixed when rebuild:
mkdosfs: file /path/to/hdd.image already exists

Signed-off-by: Robert Yang 
Signed-off-by: Ross Burton 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] xinput-calibrator startup question

[Jussi Kukkonen]

On 19 April 2016 at 21:24, Koen Kooi  wrote:
>
>> Op 19 apr. 2016, om 17:12 heeft Jussi Kukkonen  
>> het volgende geschreven:
>>
>> Hi Koen,
>>
>> I was looking at xinput-calibrator in preparation for bug 9365 "Remove
>> xtscal in preference of xinput-calibrator", and I'm wondering if you
>> remember the logic behind this commit:
>>
>> commit 6464bcd67d10ab9967ac83c27c413c1014be707e
>> Author: Koen Kooi 
>> Date:   Wed Apr 30 11:33:23 2014 +0200
>>
>>xinput-calibrator: fix XDG launch
>>
>>In the move from meta-oe to OE-core XDG based launched was dropped
>>without noting it in the commit message, so fix that regression.
>>
>>Gnome-session will now launch the calibrator again.
>>
>> The commit installs the app desktop file in the XDG autostart
>> directory. But we already have a XSession script for a similar purpose
>> -- the result in Sato is that xinput-calibrator runs twice (and I
>> would expect that to happen in gnome as well)?
>>
>> I'd like to either not install the desktop file or install it in
>> applications directory, so please let me know if the reasons for the
>> above commit might still be valid.
>
> They are still valid, XDG is still the right place to launch it.

I was hoping for a little more detail... I wonder why is xdg autostart
better than xsession in this case (this does not seem obvious to me)
and if it is, shouldn't the xsession script have been removed when the
autostart desktop file was added? It seems clear that the current
setup is broken since both autostart methods are used.

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] syslinux.bbclass: Remove APPEND from variable dependency

[Otavio Salvador]

The value of APPEND is already being tracked and does impact on the
generated configuration file. This reverts the OE-Core:3c2d7ae5 commit
as it is not need anymore.

Signed-off-by: Otavio Salvador 
---

 meta/classes/syslinux.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index fd04ac6..4fcb0c5 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -190,4 +190,3 @@ python build_syslinux_cfg () {
 
 cfgfile.close()
 }
-build_syslinux_cfg[vardeps] += "APPEND"
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] syslinux.bbclass: The AUTO_SYSLINUXMENU value needs to be boolean

[Otavio Salvador]

The python code expects AUTO_SYSLINUXMENU to be a boolean value,
otherwise the logic fails. This fixes the code comparing the value to
"1" which is the value expected by the shell script code, counterpart.

Signed-off-by: Otavio Salvador 
---

 meta/classes/syslinux.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index defad73..fd04ac6 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -121,7 +121,7 @@ python build_syslinux_cfg () {
 if syslinux_serial:
 cfgfile.write('SERIAL %s\n' % syslinux_serial)
 
-menu = d.getVar('AUTO_SYSLINUXMENU', True)
+menu = (d.getVar('AUTO_SYSLINUXMENU', True) == "1")
 
 if menu and syslinux_serial:
 cfgfile.write('DEFAULT Graphics console %s\n' % (labels.split()[0]))
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] syslinux.bbclass: Add AUTO_SYSLINUXMENU as variable dependency

[Otavio Salvador]

The value of AUTO_SYSLINUXMENU has impact on the generated
configuration file so this needs to be added to the vardeps flag.

Signed-off-by: Otavio Salvador 
---

 meta/classes/syslinux.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index fd04ac6..4f238e8 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -190,4 +190,4 @@ python build_syslinux_cfg () {
 
 cfgfile.close()
 }
-build_syslinux_cfg[vardeps] += "APPEND"
+build_syslinux_cfg[vardeps] += "APPEND AUTO_SYSLINUXMENU"
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] xinput-calibrator startup question

[Koen Kooi]

> Op 19 apr. 2016, om 17:12 heeft Jussi Kukkonen  het 
> volgende geschreven:
> 
> Hi Koen,
> 
> I was looking at xinput-calibrator in preparation for bug 9365 "Remove
> xtscal in preference of xinput-calibrator", and I'm wondering if you
> remember the logic behind this commit:
> 
> commit 6464bcd67d10ab9967ac83c27c413c1014be707e
> Author: Koen Kooi 
> Date:   Wed Apr 30 11:33:23 2014 +0200
> 
>xinput-calibrator: fix XDG launch
> 
>In the move from meta-oe to OE-core XDG based launched was dropped
>without noting it in the commit message, so fix that regression.
> 
>Gnome-session will now launch the calibrator again.
> 
> The commit installs the app desktop file in the XDG autostart
> directory. But we already have a XSession script for a similar purpose
> -- the result in Sato is that xinput-calibrator runs twice (and I
> would expect that to happen in gnome as well)?
> 
> I'd like to either not install the desktop file or install it in
> applications directory, so please let me know if the reasons for the
> above commit might still be valid.

They are still valid, XDG is still the right place to launch it.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] rpm generation question

[Mark Hatle]

On 4/19/16 12:05 PM, Tudor Florea wrote:
> As part of our test infrastructure we're attempting to install ptest
> packages (and execute the tests accordingly).
> Attempting to install ptest for valgrind fails with this error:
> 
> error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
> provides /this/is/a/bogus/interpreter/name

You can turn off the file level requires and provides on a per package basis.

SKIP_FILEDEPS_${PN}-ptest = '1'

Otherwise (for rpm packages) the system will attempt to discover and use the
per-file interpreter and other dependencies.  Since ptest is only tests, and the
dependencies here are specific to tests -- it should be safe to disable them.

(If that isn't the right approach for some reason, there are some other ways to
do a file level provide, but they're significantly more complicated and rarely
used.)

--Mark

> 
> smart install valgrind-ptest-3.11.0-r0.1@ppce500mc
> Loading cache...
> Updating cache...
> ###
> [100%]
> 
> Computing transaction...
> 
>  error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
> provides /this/is/a/bogus/interpreter/name
> 
> 
> This is most probably caused by the file shell_badinterp contained in
> this package having the following contents:
> 
> #! /this/is/a/bogus/interpreter/name
> 
> true
> 
> Does anyone have an idea how to get rid of this error?
> More specific: How can I exclude dependency on
> "/this/is/a/bogus/interpreter/name" for an rpm package?
> 
> Thank you very much.
>   Tudor.
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] rpm generation question

[Tudor Florea]

As part of our test infrastructure we're attempting to install ptest
packages (and execute the tests accordingly).
Attempting to install ptest for valgrind fails with this error:

error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
provides /this/is/a/bogus/interpreter/name

smart install valgrind-ptest-3.11.0-r0.1@ppce500mc
Loading cache...
Updating cache...
###
[100%]

Computing transaction...

 error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
provides /this/is/a/bogus/interpreter/name


This is most probably caused by the file shell_badinterp contained in
this package having the following contents:

#! /this/is/a/bogus/interpreter/name

true

Does anyone have an idea how to get rid of this error?
More specific: How can I exclude dependency on
"/this/is/a/bogus/interpreter/name" for an rpm package?

Thank you very much.
  Tudor.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Khem Raj]

See how gcc project manages it. May be that is sufficient for us too
On Apr 19, 2016 9:41 AM, "Burton, Ross"  wrote:

>
> On 19 April 2016 at 03:17, Christopher Larson  wrote:
>
>> There may be something better out there, and if we can find it, great,
>> but I think separate issues is better than not addressing the issue at all,
>> but only if the tooling is good enough to help reduce overhead on the part
>> of the devs dealing with it. Issue tracker overhead gets pretty frustrating
>> at times.
>>
>
> There may be a way of dealing with this using flags.  If we had a flag for
> each release then we could add a flag for each release which is impacted by
> the bug, and track when they're resolved by changing flag state.
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image_types: Ensure rootfs dependencies cover DEBUGFS

[Richard Purdie]

If you configure a bz2 debugfs, pbzip2-native currently isn't built.
This patch makes sure the dependencies are added.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index e2467bd..122e080 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -17,7 +17,9 @@ def imagetypes_getdepends(d):
 
 deps = []
 ctypes = d.getVar('COMPRESSIONTYPES', True).split()
-for type in (d.getVar('IMAGE_FSTYPES', True) or "").split():
+fstypes = set((d.getVar('IMAGE_FSTYPES', True) or "").split())
+fstypes |= set((d.getVar('IMAGE_FSTYPES_DEBUGFS', True) or "").split())
+for type in fstypes:
 if type in ["vmdk", "vdi", "qcow2", "hdddirect", "live", "iso", 
"hddimg"]:
 type = "ext4"
 basetype = type


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] bugzilla.yoctoproject.org policy for bugs against multiple releases

[Burton, Ross]

On 19 April 2016 at 03:17, Christopher Larson  wrote:

> There may be something better out there, and if we can find it, great, but
> I think separate issues is better than not addressing the issue at all, but
> only if the tooling is good enough to help reduce overhead on the part of
> the devs dealing with it. Issue tracker overhead gets pretty frustrating at
> times.
>

There may be a way of dealing with this using flags.  If we had a flag for
each release then we could add a flag for each release which is impacted by
the bug, and track when they're resolved by changing flag state.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] boost: improve configure

[Ross Burton]

Instead of adding a custom task (do_boostconfig) simply use the existing
do_configure.

Ensure that there are no relative paths in do_configure.

Instead of editing the user-config.jam sample file in the source tree (which is
entirely comments) and extending it on every build, create a new user-config.jam
in ${WORKDIR}.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/boost/boost.inc | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 92c7bcb..5696b6a 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -142,7 +142,7 @@ def get_boost_parallel_make(d):
 BOOST_PARALLEL_MAKE = "${@get_boost_parallel_make(d)}"
 BJAM_OPTS= '${BOOST_PARALLEL_MAKE} -d+2 -q \
${BJAM_TOOLS} \
-   
-sBOOST_BUILD_USER_CONFIG=${S}/tools/build/example/user-config.jam \
+   -sBOOST_BUILD_USER_CONFIG=${WORKDIR}/user-config.jam \
--build-dir=${S}/${TARGET_SYS} \
--disable-icu \
${BJAM_EXTRA}'
@@ -150,23 +150,19 @@ BJAM_OPTS= '${BOOST_PARALLEL_MAKE} -d+2 -q \
 # Native compilation of bzip2 isn't working
 BJAM_OPTS_append_class-native = ' -sNO_BZIP2=1'
 
-do_boostconfig() {
-   cp -f boost/config/platform/linux.hpp 
boost/config/platform/linux-gnueabi.hpp
+do_configure() {
+   cp -f ${S}/boost/config/platform/linux.hpp 
${S}/boost/config/platform/linux-gnueabi.hpp
 
# D2194:Fixing the failure of "error: duplicate initialization of gcc 
with the following parameters" during compilation.
-   sed -i "/^using gcc : 4.3.1/d" ${S}/tools/build/example/user-config.jam
-   sed -i "/^using python : ${PYTHON_BASEVERSION}"/d 
${S}/tools/build/example/user-config.jam
-   echo 'using gcc : 4.3.1 : ${CXX} : "${CFLAGS}" 
"${CXXFLAGS}" "${LDFLAGS}" ;' >> 
${S}/tools/build/example/user-config.jam
-   echo "using python : ${PYTHON_BASEVERSION} : : 
${STAGING_INCDIR}/python${PYTHON_BASEVERSION} ;" >> 
${S}/tools/build/example/user-config.jam
-   echo "using python : 3.5 : : ${STAGING_INCDIR}/python3.5m ;" >> 
${S}/tools/build/example/user-config.jam
+   rm -f ${WORKDIR}/user-config.jam
+   echo 'using gcc : 4.3.1 : ${CXX} : "${CFLAGS}" 
"${CXXFLAGS}" "${LDFLAGS}" ;' >> ${WORKDIR}/user-config.jam
+   echo "using python : ${PYTHON_BASEVERSION} : : 
${STAGING_INCDIR}/python${PYTHON_BASEVERSION} ;" >> ${WORKDIR}/user-config.jam
+   echo "using python : 3.5 : : ${STAGING_INCDIR}/python3.5m ;" >> 
${WORKDIR}/user-config.jam
 
CC="${BUILD_CC}" CFLAGS="${BUILD_CFLAGS}" ./bootstrap.sh 
--with-bjam=bjam --with-toolset=gcc --with-python-root=${PYTHON_ROOT}
-   sed -i '/^using python/d' project-config.jam
+   sed -i '/^using python/d' ${S}/project-config.jam
 }
 
-do_boostconfig[dirs] = "${S}"
-addtask do_boostconfig after do_patch before do_configure
-
 do_compile() {
set -ex
rm -rf ${S}/${TARGET_SYS}
-- 
2.8.0.rc3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] boost: delete the build directory before rebuilding

[Ross Burton]

If there is an existing build directory when do enter do_compile() then delete
it, as it contains the previous build.  If the rebuild was caused because
dependencies have changed we want to ensure that a rebuild actually happens.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/boost/boost.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 982446c..92c7bcb 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -169,6 +169,7 @@ addtask do_boostconfig after do_patch before do_configure
 
 do_compile() {
set -ex
+   rm -rf ${S}/${TARGET_SYS}
bjam ${BJAM_OPTS} --prefix=${prefix} \
--exec-prefix=${exec_prefix} \
--libdir=${libdir} \
-- 
2.8.0.rc3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] packagegroup-core-tools-profile: Enable valgrind on ARMv7a and above

[Felipe F. Tonello]

Fixes: e5f41c221356 ("task-core-tools-profile: fix valgrind for arm and
systemtap for mips")

Valgrind works on ARMv7a and above.

Signed-off-by: Felipe F. Tonello 
---
 meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index ff2b5779a203..b6520d6779d7 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -59,7 +59,7 @@ LTTNGMODULES = "lttng-modules"
 
 BABELTRACE = "babeltrace"
 
-# valgrind does not work on mips
+# valgrind does not work on the following configurations/architectures
 
 VALGRIND = "valgrind"
 VALGRIND_libc-uclibc = ""
@@ -68,7 +68,9 @@ VALGRIND_mips = ""
 VALGRIND_mips64 = ""
 VALGRIND_mips64n32 = ""
 VALGRIND_nios2 = ""
-VALGRIND_arm = ""
+VALGRIND_armv4 = ""
+VALGRIND_armv5 = ""
+VALGRIND_armv6 = ""
 VALGRIND_aarch64 = ""
 
 RDEPENDS_${PN} = "\
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] xinput-calibrator startup question

[Jussi Kukkonen]

Hi Koen,

I was looking at xinput-calibrator in preparation for bug 9365 "Remove
xtscal in preference of xinput-calibrator", and I'm wondering if you
remember the logic behind this commit:

commit 6464bcd67d10ab9967ac83c27c413c1014be707e
Author: Koen Kooi 
Date:   Wed Apr 30 11:33:23 2014 +0200

xinput-calibrator: fix XDG launch

In the move from meta-oe to OE-core XDG based launched was dropped
without noting it in the commit message, so fix that regression.

Gnome-session will now launch the calibrator again.

The commit installs the app desktop file in the XDG autostart
directory. But we already have a XSession script for a similar purpose
-- the result in Sato is that xinput-calibrator runs twice (and I
would expect that to happen in gnome as well)?

I'd like to either not install the desktop file or install it in
applications directory, so please let me know if the reasons for the
above commit might still be valid.


Thanks,
 Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image.bbclass: The wrong name is being used for the debug filesystem

[Mark Hatle]

[YOCTO #9487]

The debug filesystem file name is ending in "debug_tar", it should be simply
"tar".  Strip the "debug_" piece as necessary.

To avoid deleting the tar ball, when we've asked for just the tarball we need
to check 't' and not 'realt'.

The two hunks were suggested by RP.  I've implemented and verify they work
with the settings:

PACKAGE_CLASSES = "package_rpm"
IMAGE_GEN_DEBUGFS = '1'

IMAGE_FSTYPES_DEBUGFS = "tar.bz2"

IMAGE_FSTYPES_DEBUGFS = "tar.gz"

and

IMAGE_FSTYPES_DEBUGFS = "tar"

Signed-off-by: Mark Hatle 
---
 meta/classes/image.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index f471f1a..8bfd241 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -393,6 +393,8 @@ python () {
 for ctype in ctypes:
 if bt.endswith("." + ctype):
 type = bt[0:-len(ctype) - 1]
+if type.startswith("debugfs_"):
+type = type[8:]
 # Create input image first.
 gen_conversion_cmds(type)
 localdata.setVar('type', type)
@@ -406,7 +408,7 @@ python () {
 gen_conversion_cmds(bt)
 
 localdata.setVar('type', realt)
-if realt not in alltypes:
+if t not in alltypes:
 
rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"))
 else:
 subimages.append(realt)
-- 
2.5.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Richard Purdie]

On Tue, 2016-04-19 at 16:11 +0200, Andreas Müller wrote:
> thanks a lot for your efforts. Do I understand this right: You
> suggest
> to use build sysroot (on my own risk - as I did before) and make gdb
> happy by linking sources?
> 
> Problem I see is that we have multiple package archs e.g
> ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
> expands to multiple paths. But a script symlinking all together + set
> substitute-path might help here...
> 
> I will play around with this in the later...

I was thinking about this a bit more and there is another option
available to you which would be to pass all the debug sources into the
sysroot as hardlinks to the files in workdir, in much the same way as
we do the other sysroot files (which you don't strip).

Since those files are collected by do_package you'd probably have to
force do_populate_sysroot after do_package but such an additional class
to make these tweaks probably wouldn't be that large and would just
affect performance a bit (with the benefit of the debugging you want).

Just thinking out loud really. My big worry is all the different
codepaths we have people using, equally, you can't get performance
(disk footprint and speed) and functionality in some cases and people
do want to choose different compromises.

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Mark Hatle]

Of course after hitting send, I noticed the example in 7 was missing on step.. 
:P

On 4/19/16 9:47 AM, Mark Hatle wrote:
> On 4/19/16 9:11 AM, Andreas Müller wrote:
>> thanks a lot for your efforts. Do I understand this right: You suggest
>> to use build sysroot (on my own risk - as I did before) and make gdb
>> happy by linking sources?
>>
>> Problem I see is that we have multiple package archs e.g
>> ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
>> expands to multiple paths. But a script symlinking all together + set
>> substitute-path might help here...
>>
>> I will play around with this in the later...
>>
>> Andreas
>>
> 
> See Yocto Project bug #9481: 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9481
> 
> Below are the steps that I have added that I hope will be documented in the YP
> 2.1 documentation. (This matches current master.)
> 
> I just went through and verified the steps on my local machine. As noted, 
> there
> is currently a bug in the debugfs creation. RP helped me fix the 'rpm' case, 
> but
> it appears ipkg support is broken in some way.
> 
> 
> 
> 1. Configure your build system to construct the companion debug filesystem
> 
> In the local.conf:
> 
> IMAGE_GEN_DEBUGFS = '1'
> IMAGE_FSTYPES_DEBUGFS = 'tar.bz2'
> 
> The options above will cause the system to generate a special companion
> filesystem fragment, that contains the matching source and debug symbols to 
> your
> deployable filesystem. It does this by looking at what is in the deployed
> filesystem, and pulling the corresponding -dbg packages.
> 
> The companion debug filesystem is NOT a complete filesystem, but only contains
> the debug fragements. It must be combined with the full filesystem for
> debugging. (Later steps will show this.)
> 
> 2. Configure the system to include gdbserver in the target filesystem
> 
> In the local.conf (or an image recipe):
> 
> IMAGE_INSTALL_append = “ gdbserver"
> 
> 3. Build the environment
> 
> Construct the image (and companion Debug Filesystem)
> bitbake 
> 
> Build the cross GDB component and make it available for debugging
> 
> Build the SDK that matches the image (this is best for a production build for
> later debugging, especially during long term maintenance)
> bitbake -c populate_sdk 
> 
> or
> 
> Build the minimal toolchain components that match the target (this is smaller
> then a typical SDK and only contains a minimal set of components to build 
> simple
> test applications, as well as run the debugger)
> bitbake meta-toolchain
> 
> or
> 
> Build gdb itself within the build system (this produces a temporary copy of
> cross-gdb that can be used for debugging during development. It is the 
> quickest
> approach, but the other methods are better for long term maintenance 
> strategies.)
> bitbake gdb-cross-
> 
> (Note: If you run bitbake gdb-cross, the system will give you a suggestion 
> like
> gdb-cross-i586, the suggestion is likely the actual name you want to use.)
> 
> 4. Setup your environment
> 
> 4.1 Setup the debugfs
> 
> $ mkdir debugfs
> $ cd debugfs
> $ tar xvfj  dir>/tmp-glibc/deploy/images//.rootfs.tar.bz2
> $ tar xvfj  dir>/tmp-glibc/deploy/images//-dbg.rootfs.tar.bz2
> 
> 4.2 Setup GDB
> 
> Install the SDK (if you built one) and source the correct environment file. 
> This
> will put it in your path.
> 
> if using the build system gdb will be in
> //sysroots//usr/bin//-gdb
> 
> 5. Boot the target
> 
> For QEMU, 
> 
> (verify that your host can access the target via TCP)
> 
> 6. Debug a program
> 
> 6.1 Run gdbserver on the target, such as:
> 
> (We’ll debug gzip in this example, see gdbserver docs for additional options)
> 
> root@qemux86:~# gdbserver localhost:1234 /bin/gzip —help
> 
> 6.2 On the host, run gdb, configure it and connect to the target:
> 
> $ cd 
> $ -gdb
> 
> (gdb) set sysroot debugfs
> (gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
> (gdb) target remote :1234
> 
> At this point everything should automatically load (matching binaries, symbols
> and headers.)
> 
> Note: the gdb ‘set’ commands above can be placed into the users ~/.gdbinit GDB
> will automatically run whatever commands are in that file when it is started.
> 
> 
> 7. Deploying WITHOUT a full image rebuild
> 
> In many cases, during development you want a quick method to deploy a new 
> binary
> to the target and debug it, without waiting for a full image build.
> 
> One approach to this is to build the component you want to debug. Then 
> directly
> copy the executable to BOTH the target and the host ‘debugfs’. If the binary 
> is
> processed through the debug splitting in OE, you should also copy the debug
> items (the .debug contents and corresponding /usr/src/debug) from the work 
> dir.
> 
> Such as:
> 
> $ bitbake bash
> $ bitbake -c devshell bash
> $ cd ..
> $ scp packages-split/bash/bin/bash :/bin/bash

(missing step)
$ cp packages-split/bash/bin/bash /debugfs/bin/bash

> $ cp -a packages-split/bash-dbg/* /debugfs
> 
> 

-- 

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Mark Hatle]

On 4/19/16 9:11 AM, Andreas Müller wrote:
> thanks a lot for your efforts. Do I understand this right: You suggest
> to use build sysroot (on my own risk - as I did before) and make gdb
> happy by linking sources?
> 
> Problem I see is that we have multiple package archs e.g
> ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
> expands to multiple paths. But a script symlinking all together + set
> substitute-path might help here...
> 
> I will play around with this in the later...
> 
> Andreas
> 

See Yocto Project bug #9481: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9481

Below are the steps that I have added that I hope will be documented in the YP
2.1 documentation. (This matches current master.)

I just went through and verified the steps on my local machine. As noted, there
is currently a bug in the debugfs creation. RP helped me fix the 'rpm' case, but
it appears ipkg support is broken in some way.



1. Configure your build system to construct the companion debug filesystem

In the local.conf:

IMAGE_GEN_DEBUGFS = '1'
IMAGE_FSTYPES_DEBUGFS = 'tar.bz2'

The options above will cause the system to generate a special companion
filesystem fragment, that contains the matching source and debug symbols to your
deployable filesystem. It does this by looking at what is in the deployed
filesystem, and pulling the corresponding -dbg packages.

The companion debug filesystem is NOT a complete filesystem, but only contains
the debug fragements. It must be combined with the full filesystem for
debugging. (Later steps will show this.)

2. Configure the system to include gdbserver in the target filesystem

In the local.conf (or an image recipe):

IMAGE_INSTALL_append = “ gdbserver"

3. Build the environment

Construct the image (and companion Debug Filesystem)
bitbake 

Build the cross GDB component and make it available for debugging

Build the SDK that matches the image (this is best for a production build for
later debugging, especially during long term maintenance)
bitbake -c populate_sdk 

or

Build the minimal toolchain components that match the target (this is smaller
then a typical SDK and only contains a minimal set of components to build simple
test applications, as well as run the debugger)
bitbake meta-toolchain

or

Build gdb itself within the build system (this produces a temporary copy of
cross-gdb that can be used for debugging during development. It is the quickest
approach, but the other methods are better for long term maintenance 
strategies.)
bitbake gdb-cross-

(Note: If you run bitbake gdb-cross, the system will give you a suggestion like
gdb-cross-i586, the suggestion is likely the actual name you want to use.)

4. Setup your environment

4.1 Setup the debugfs

$ mkdir debugfs
$ cd debugfs
$ tar xvfj /tmp-glibc/deploy/images//.rootfs.tar.bz2
$ tar xvfj /tmp-glibc/deploy/images//-dbg.rootfs.tar.bz2

4.2 Setup GDB

Install the SDK (if you built one) and source the correct environment file. This
will put it in your path.

if using the build system gdb will be in
//sysroots//usr/bin//-gdb

5. Boot the target

For QEMU, 

(verify that your host can access the target via TCP)

6. Debug a program

6.1 Run gdbserver on the target, such as:

(We’ll debug gzip in this example, see gdbserver docs for additional options)

root@qemux86:~# gdbserver localhost:1234 /bin/gzip —help

6.2 On the host, run gdb, configure it and connect to the target:

$ cd 
$ -gdb

(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) target remote :1234

At this point everything should automatically load (matching binaries, symbols
and headers.)

Note: the gdb ‘set’ commands above can be placed into the users ~/.gdbinit GDB
will automatically run whatever commands are in that file when it is started.


7. Deploying WITHOUT a full image rebuild

In many cases, during development you want a quick method to deploy a new binary
to the target and debug it, without waiting for a full image build.

One approach to this is to build the component you want to debug. Then directly
copy the executable to BOTH the target and the host ‘debugfs’. If the binary is
processed through the debug splitting in OE, you should also copy the debug
items (the .debug contents and corresponding /usr/src/debug) from the work dir.

Such as:

$ bitbake bash
$ bitbake -c devshell bash
$ cd ..
$ scp packages-split/bash/bin/bash :/bin/bash
$ cp -a packages-split/bash-dbg/* /debugfs


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/4] u-boot: basic support of device tree blob reassembly

[Andreas Oberritter]

Hello Yannick,

On 19.04.2016 14:46, Yannick Gicquel wrote:
> This introduces a new task 'assemble_dtb' to handle the concatenation of 
> U-Boot
> without DTB and the compiled U-Boot DTB while using CONFIG_OF_SEPARATE.
> Basically, this task merges the u-boot-nodtb.bin and the device tree blob 
> using
> the 'cat' command and overrides the u-boot.bin file which is generated
> at the compilation step.
> 
> This task is intended to be used in the verified-boot image generation process
> after the kernel-fitimage class had appended a public key to the device tree
> blob. It is placed after the do_deploy and before the do_install tasks and it
> replaces the u-boot binaries in both deploy directory and build directory
> in order to minimize the changes in later tasks.
> 
> Signed-off-by: Yannick Gicquel 
> ---
>  meta/recipes-bsp/u-boot/u-boot-sign.inc | 21 +
>  meta/recipes-bsp/u-boot/u-boot.inc  | 22 ++
>  2 files changed, 43 insertions(+)
>  create mode 100644 meta/recipes-bsp/u-boot/u-boot-sign.inc
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-sign.inc 
> b/meta/recipes-bsp/u-boot/u-boot-sign.inc
> new file mode 100644
> index 000..c88a2a1
> --- /dev/null
> +++ b/meta/recipes-bsp/u-boot/u-boot-sign.inc
> @@ -0,0 +1,21 @@
> +# This file is part of U-Boot verified boot support and is intended to be
> +# included from u-boot recipe and from kernel-fitimage.bbclass
> +#
> +# The signature procedure requires the user to generate an RSA key and
> +# certificate in a directory and to define the following variable:
> +#
> +# UBOOT_SIGN_KEYDIR = "/keys/directory"
> +# UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", "dev.key")
> +# UBOOT_SIGN_ENABLE = "1"
> +#
> +# The signature support is limited to the use of CONFIG_OF_SEPARATE in 
> U-Boot.
> +#
> +# For more details, please refer to U-boot documentation.
> +
> +UBOOT_SIGN_ENABLE ?= "0"
> +UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
> +UBOOT_DTB_BINARY ?= "u-boot.dtb"
> +UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
> +UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
> +UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
> +UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 3ba866d..29b0b95 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -65,6 +65,28 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
>  UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
>  UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
>  
> +# The use of verified boot requires to share environment variables with 
> kernel
> +# fitImage class as the mkimage call requires dtb filepath to append 
> signature
> +# public key.
> +require u-boot-sign.inc
> +
> +do_assemble_dtb() {
> + # Concatenate U-Boot w/o DTB & DTB with public key
> + # (cf. kernel-fitimage.bbclass for more details)
> + cd ${DEPLOYDIR}
> + if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ]; then
> + if [ -e "${UBOOT_NODTB_IMAGE}" -a -e "${UBOOT_DTB_IMAGE}" ]; 
> then
> + cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
> ${UBOOT_IMAGE}
> + cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
> ${S}/${UBOOT_BINARY}

in general, you should avoid writing to ${S} (source). It's better to
write to ${B} (build).

> + else
> + bbwarn "Failure while adding public key to u-boot 
> binary. Verified boot won't be available."
> + fi
> + fi
> +}
> +
> +addtask assemble_dtb after do_deploy before do_install

The task do_deploy executes after do_install. Does it really work this
way? I think bitbake should try to detect this and error out.

Maybe you could just use do_install_append and add the dependency below
to do_install.

Regards,
Andreas

> +do_assemble_dtb[depends] += "${@' 
> ${PREFERRED_PROVIDER_virtual/kernel}:do_assemble_fitimage' if 
> '${UBOOT_SIGN_ENABLE}' == '1' else ''}"
> +
>  do_compile () {
>   if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
> 'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
>   sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' 
> config.mk
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Andreas Müller]

On Tue, Apr 19, 2016 at 9:33 AM, Hongxu Jia  wrote:
> Hi all,
>
> With some investigation, there is an example to explain how to do remote
> debug.
>
> Also file [YOCTO #9481] for document.
>
> Hi Andreas,
>
> Would you please have a look the example, to see if it could fit your case.
>
> Example:
>
> 1. Build a image with gdbserver and gzip installed. The gzip
>is the debug binary. Append the following to local.conf
> ...
> IMAGE_INSTALL_append = " gdbserver gzip"
> ...
>
> $ bitbake core-image-sato
>
> 2. Build gdb-cross for remote debug on host
>
> $ bitbake gdb-cross-i586
>
> 3. start qemu
>
> $ runqemu qemux86 core-image-sato
>
> 4. On host side, create symlink /usr/src/debug to
>${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS} which the
>location of sources is /usr/src/debug.
>
> $ ln -snf /TOPDIR/tmp/work/i586-poky-linux /usr/src/debug
>
> 5. On target side, ipaddr is 128.224.163.187,
>run gdbserver to debug "gzip -h"
>
> root@qemux86-64:~# gdbserver localhost:1024 gzip -h
> Process gzip created; pid = 530
> Listening on port 1024
>
> 6. On host side, enter gzip's devshell
> $ bitbake -cdevshell gzip
>
> 7. On host side, run gdb-cross to remote debug gzip
>
> gzip-1.6# i586-poky-linux-gdb ../build/gzip
>
> 8. Use path ${STAGING_DIR_HOST} as the system root for
>the program being debugged. Any absolute shared
>library paths will be prefixed with path;
>
> (gdb) set sysroot /TOPDIR/tmp/sysroots/qemux86
>
>
> 9. Start remote target, set break point at help()
>
> (gdb) target remote 128.224.163.187:1024
> (gdb) break gzip.c:325
> (gdb) info break
> Num Type   Disp Enb AddressWhat
> 1   breakpoint keep y   0x00401ec1 in main at
> /usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:325
> (gdb) c
> Continuing.
>
> Breakpoint 1, main (argc=2, argv=0x7fffeca8) at
> /usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:465
> 465 help(); do_exit(OK); break;
> (gdb) list
> 460 case 'd':
> 461 decompress = 1; break;
> 462 case 'f':
> 463 force++; break;
> 464 case 'h': case 'H':
> 465 help(); do_exit(OK); break;
> 466 case 'k':
> 467 keep = 1; break;
> 468 case 'l':
> 469 list = decompress = to_stdout = 1; break;
> (gdb) c
> Continuing.
> [Inferior 1 (process 1246) exited normally]
>
>
> 10. On target side, get output of "gzip -h"
> [snip]
> Remote debugging from host 128.224.153.74
> Usage: gzip [OPTION]... [FILE]...
> Compress or uncompress FILEs (by default, compress FILES in-place).
>
> Mandatory arguments to long options are mandatory for short options too.
>
>   -c, --stdout  write on standard output, keep original files unchanged
>   -d, --decompress  decompress
>   -f, --force   force overwrite of output file and compress links
>   -h, --helpgive this help
>   -k, --keepkeep (don't delete) input files
>   -l, --listlist compressed file contents
>   -L, --license display software license
>   -n, --no-name do not save or restore the original name and time stamp
>   -N, --namesave or restore the original name and time stamp
>   -q, --quiet   suppress all warnings
>   -r, --recursive   operate recursively on directories
>   -S, --suffix=SUF  use suffix SUF on compressed files
>   -t, --testtest compressed file integrity
>   -v, --verbose verbose mode
>   -V, --version display version number
>   -1, --fastcompress faster
>   -9, --bestcompress better
>
> With no FILE, or when FILE is -, read standard input.
>
> Report bugs to .
>
> Child exited with status 0
> GDBserver exiting
> [snip]
>
> //Hongxu
>
thanks a lot for your efforts. Do I understand this right: You suggest
to use build sysroot (on my own risk - as I did before) and make gdb
happy by linking sources?

Problem I see is that we have multiple package archs e.g
ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
expands to multiple paths. But a script symlinking all together + set
substitute-path might help here...

I will play around with this in the later...

Andreas
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] perf: pass DESTDIR in EXTRA_OEMAKE

[Bruce Ashfield]

On Tue, Apr 19, 2016 at 8:57 AM, Ross Burton  wrote:

> Instead of passing DESTDIR just in the make install invocation, pass it in
> EXTRA_OEMAKE.  This appears to stop perf from rebuilding at instal time
> for me,
> which appears to be the trigger for the random build failure.
>

This also passed my local build tests, but then again, in two weeks of
trying (off and
on), I've never reproduced the race condition .. so I can't comment if it
actually fixes
it or not.

Having a the destdir be consistent for all phases makes sense though, so I
see no
problem with the change as-is.

I'll suspend my nasty perf Makefile hacks to serialize parts of the build
to see if this
holds as a permanent fix for the problem.

Tested-by: Bruce Ashfield 

Bruce


>
> [ YOCTO #9182 ]
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-kernel/perf/perf.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/
> perf.bb
> index c43f39c..3d6ffb3 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -88,6 +88,7 @@ EXTRA_OEMAKE = '\
>  '
>
>  EXTRA_OEMAKE += "\
> +'DESTDIR=${D}' \
>  'prefix=${prefix}' \
>  'bindir=${bindir}' \
>  'sharedir=${datadir}' \
> @@ -110,7 +111,7 @@ do_compile() {
>  do_install() {
> # Linux kernel build system is expected to do the right thing
> unset CFLAGS
> -   oe_runmake DESTDIR=${D} install
> +   oe_runmake install
> # we are checking for this make target to be compatible with older
> perf versions
> if [ "${@perf_feature_enabled('perf-scripting', 1, 0, d)}" = "1" ]
> && grep -q install-python_ext ${S}/tools/perf/Makefile*; then
> oe_runmake DESTDIR=${D} install-python_ext
> --
> 2.8.0.rc3
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 4/4] kernel: fitimage: basic support for fitimage signature

[Otavio Salvador]

On Tue, Apr 19, 2016 at 9:46 AM, Yannick Gicquel
 wrote:
> This is an initial support of fitImage signature to enable U-Boot verified
> boot. This feature is implemented by adding a signature tag to the
> configuration section of the generated fit-image.its file.
>
> When a UBOOT_SIGN_ENABLE variable is set to "1", the signature procedure is
> activated and performs a second call to mkimage to sign the fitImage file and
> to include the public key in the deployed U-Boot device tree blob. (This
> implementation depends on the use of CONFIG_OF_SEPARATE in U-Boot.)
>
> As the U-Boot device tree blob is appended in the deploy dir, a dependency
> on 'u-boot:do_deploy' is added when the feature is activated.
>
> Signed-off-by: Yannick Gicquel 
> ---
>  meta/classes/kernel-fitimage.bbclass | 45 
> +++-
>  1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/kernel-fitimage.bbclass 
> b/meta/classes/kernel-fitimage.bbclass
> index 62e0017..cbf07ba 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -1,5 +1,8 @@
>  inherit kernel-uboot
>
> +# To resolve the following UBOOT_DTB_BINARY identifier
> +require recipes-bsp/u-boot/u-boot-sign.inc
> +

Again, use a class for it. inc files are being abused this way.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/4] u-boot: basic support of device tree blob reassembly

[Otavio Salvador]

On Tue, Apr 19, 2016 at 9:46 AM, Yannick Gicquel
 wrote:
> This introduces a new task 'assemble_dtb' to handle the concatenation of 
> U-Boot
> without DTB and the compiled U-Boot DTB while using CONFIG_OF_SEPARATE.
> Basically, this task merges the u-boot-nodtb.bin and the device tree blob 
> using
> the 'cat' command and overrides the u-boot.bin file which is generated
> at the compilation step.
>
> This task is intended to be used in the verified-boot image generation process
> after the kernel-fitimage class had appended a public key to the device tree
> blob. It is placed after the do_deploy and before the do_install tasks and it
> replaces the u-boot binaries in both deploy directory and build directory
> in order to minimize the changes in later tasks.
>
> Signed-off-by: Yannick Gicquel 
> ---
>  meta/recipes-bsp/u-boot/u-boot-sign.inc | 21 +
>  meta/recipes-bsp/u-boot/u-boot.inc  | 22 ++
>  2 files changed, 43 insertions(+)
>  create mode 100644 meta/recipes-bsp/u-boot/u-boot-sign.inc
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot-sign.inc 
> b/meta/recipes-bsp/u-boot/u-boot-sign.inc
> new file mode 100644
> index 000..c88a2a1
> --- /dev/null
> +++ b/meta/recipes-bsp/u-boot/u-boot-sign.inc

I think it could be moved to a class, so the U-Boot can inherit it.

> @@ -0,0 +1,21 @@
> +# This file is part of U-Boot verified boot support and is intended to be
> +# included from u-boot recipe and from kernel-fitimage.bbclass
> +#
> +# The signature procedure requires the user to generate an RSA key and
> +# certificate in a directory and to define the following variable:
> +#
> +# UBOOT_SIGN_KEYDIR = "/keys/directory"
> +# UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", "dev.key")
> +# UBOOT_SIGN_ENABLE = "1"
> +#
> +# The signature support is limited to the use of CONFIG_OF_SEPARATE in 
> U-Boot.
> +#
> +# For more details, please refer to U-boot documentation.
> +
> +UBOOT_SIGN_ENABLE ?= "0"
> +UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
> +UBOOT_DTB_BINARY ?= "u-boot.dtb"
> +UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
> +UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
> +UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
> +UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 3ba866d..29b0b95 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -65,6 +65,28 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
>  UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
>  UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
>
> +# The use of verified boot requires to share environment variables with 
> kernel
> +# fitImage class as the mkimage call requires dtb filepath to append 
> signature
> +# public key.
> +require u-boot-sign.inc
> +
> +do_assemble_dtb() {
> +   # Concatenate U-Boot w/o DTB & DTB with public key
> +   # (cf. kernel-fitimage.bbclass for more details)
> +   cd ${DEPLOYDIR}
> +   if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ]; then
> +   if [ -e "${UBOOT_NODTB_IMAGE}" -a -e "${UBOOT_DTB_IMAGE}" ]; 
> then
> +   cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
> ${UBOOT_IMAGE}
> +   cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
> ${S}/${UBOOT_BINARY}
> +   else
> +   bbwarn "Failure while adding public key to u-boot 
> binary. Verified boot won't be available."
> +   fi
> +   fi
> +}
> +
> +addtask assemble_dtb after do_deploy before do_install
> +do_assemble_dtb[depends] += "${@' 
> ${PREFERRED_PROVIDER_virtual/kernel}:do_assemble_fitimage' if 
> '${UBOOT_SIGN_ENABLE}' == '1' else ''}"
> +

This should be part of the class, not another .inc file.

>  do_compile () {
> if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
> 'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
> sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' 
> config.mk
> --
> 1.9.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base.bbclass: Introduce PACKAGECONFIG_CONFARGS variable

[Otavio Salvador]

Hello Martin,
Hello Richard,

Martin, thanks for updating the patch to comply to Richard's suggestions.

On Tue, Apr 19, 2016 at 7:31 AM, Martin Jansa  wrote:
> * add separate variable for configuration options generated from
>   PACKAGECONFIG setting, this helps other bbclasses and recipes
>   to take advantage of PACKAGECONFIG mechanism, without including
>   other options from EXTRA_OECONF
> * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
>   from PACKAGECONFIG:
>   EXTRA_QMAKEVARS_PRE +=
>   but with
>   conf/distro/include/no-static-libs.inc
>   it means getting --disable-static as invalid option inside
>   EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
>   to use poky with meta-qt5.
> * once we migrate all bbclasses and recipes to PACKAGECONFIG_CONFARGS
>   we should also restrict EXTRA_OECONF append only to autotools.bbclass
>   like I did for cmake.bbclass
>
> Signed-off-by: Martin Jansa 

Acked-by: Otavio Salvador 

Richard, I understand we are late in the release cycle however this
change is indeed required to fix our build of Qt5 using Poky
distribution.

The patch seems fairly safe and should have no impact for current
metadata, while it allow for meta-qt5 to fix the Poky support. The
patch has been sent on Feb and ended being forgotten in the merge
queue however it is being used daily by the World Build test from
Martin, which includes it so static libraries can be disabled.

Please consider it for 2.1.

Best Regards,

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Hongxu Jia]

On 04/19/2016 08:31 PM, Mark Hatle wrote:

On 4/19/16 2:33 AM, Hongxu Jia wrote:

Hi all,

With some investigation, there is an example to explain how to do remote debug.

Also file [YOCTO #9481] for document.

Hi Andreas,

Would you please have a look the example, to see if it could fit your case.

Example:

1. Build a image with gdbserver and gzip installed. The gzip
is the debug binary. Append the following to local.conf
...
IMAGE_INSTALL_append = " gdbserver gzip"
...

$ bitbake core-image-sato

2. Build gdb-cross for remote debug on host

$ bitbake gdb-cross-i586

3. start qemu

$ runqemu qemux86 core-image-sato

4. On host side, create symlink /usr/src/debug to
${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS} which the
location of sources is /usr/src/debug.

$ ln -snf /TOPDIR/tmp/work/i586-poky-linux /usr/src/debug

This is incorrect.  On the host you use the combination of:

(gdb) set sysroot 
(gdb) set substitute-path /usr/src/debug /usr/src/debug



Yes! Yours is more reasonable. It is verified on my case:

4. On host side, Set a substitution rule for finding source files.
   Replace /usr/src/debug with ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}

(gdb) set substitute-path /usr/src/debug /TOPDIR/tmp/work/i586-poky-linux

//Hongxu


5. On target side, ipaddr is 128.224.163.187,
run gdbserver to debug "gzip -h"

root@qemux86-64:~# gdbserver localhost:1024 gzip -h
Process gzip created; pid = 530
Listening on port 1024

6. On host side, enter gzip's devshell
$ bitbake -cdevshell gzip

7. On host side, run gdb-cross to remote debug gzip

gzip-1.6# i586-poky-linux-gdb ../build/gzip

8. Use path ${STAGING_DIR_HOST} as the system root for
the program being debugged. Any absolute shared
library paths will be prefixed with path;

(gdb) set sysroot /TOPDIR/tmp/sysroots/qemux86


9. Start remote target, set break point at help()

(gdb) target remote 128.224.163.187:1024
(gdb) break gzip.c:325
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x00401ec1 in main at
/usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:325
(gdb) c
Continuing.

Breakpoint 1, main (argc=2, argv=0x7fffeca8) at
/usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:465
465 help(); do_exit(OK); break;
(gdb) list
460 case 'd':
461 decompress = 1; break;
462 case 'f':
463 force++; break;
464 case 'h': case 'H':
465 help(); do_exit(OK); break;
466 case 'k':
467 keep = 1; break;
468 case 'l':
469 list = decompress = to_stdout = 1; break;
(gdb) c
Continuing.
[Inferior 1 (process 1246) exited normally]


10. On target side, get output of "gzip -h"
[snip]
Remote debugging from host 128.224.153.74
Usage: gzip [OPTION]... [FILE]...
Compress or uncompress FILEs (by default, compress FILES in-place).

Mandatory arguments to long options are mandatory for short options too.

   -c, --stdout  write on standard output, keep original files unchanged
   -d, --decompress  decompress
   -f, --force   force overwrite of output file and compress links
   -h, --helpgive this help
   -k, --keepkeep (don't delete) input files
   -l, --listlist compressed file contents
   -L, --license display software license
   -n, --no-name do not save or restore the original name and time stamp
   -N, --namesave or restore the original name and time stamp
   -q, --quiet   suppress all warnings
   -r, --recursive   operate recursively on directories
   -S, --suffix=SUF  use suffix SUF on compressed files
   -t, --testtest compressed file integrity
   -v, --verbose verbose mode
   -V, --version display version number
   -1, --fastcompress faster
   -9, --bestcompress better

With no FILE, or when FILE is -, read standard input.

Report bugs to .

Child exited with status 0
GDBserver exiting
[snip]

//Hongxu



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] perf: pass DESTDIR in EXTRA_OEMAKE

[Ross Burton]

Instead of passing DESTDIR just in the make install invocation, pass it in
EXTRA_OEMAKE.  This appears to stop perf from rebuilding at instal time for me,
which appears to be the trigger for the random build failure.

[ YOCTO #9182 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/perf/perf.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index c43f39c..3d6ffb3 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -88,6 +88,7 @@ EXTRA_OEMAKE = '\
 '
 
 EXTRA_OEMAKE += "\
+'DESTDIR=${D}' \
 'prefix=${prefix}' \
 'bindir=${bindir}' \
 'sharedir=${datadir}' \
@@ -110,7 +111,7 @@ do_compile() {
 do_install() {
# Linux kernel build system is expected to do the right thing
unset CFLAGS
-   oe_runmake DESTDIR=${D} install
+   oe_runmake install
# we are checking for this make target to be compatible with older perf 
versions
if [ "${@perf_feature_enabled('perf-scripting', 1, 0, d)}" = "1" ] && 
grep -q install-python_ext ${S}/tools/perf/Makefile*; then
oe_runmake DESTDIR=${D} install-python_ext
-- 
2.8.0.rc3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH 1/4] u-boot: basic support of device tree blob reassembly

[Yannick Gicquel]

This introduces a new task 'assemble_dtb' to handle the concatenation of U-Boot
without DTB and the compiled U-Boot DTB while using CONFIG_OF_SEPARATE.
Basically, this task merges the u-boot-nodtb.bin and the device tree blob using
the 'cat' command and overrides the u-boot.bin file which is generated
at the compilation step.

This task is intended to be used in the verified-boot image generation process
after the kernel-fitimage class had appended a public key to the device tree
blob. It is placed after the do_deploy and before the do_install tasks and it
replaces the u-boot binaries in both deploy directory and build directory
in order to minimize the changes in later tasks.

Signed-off-by: Yannick Gicquel 
---
 meta/recipes-bsp/u-boot/u-boot-sign.inc | 21 +
 meta/recipes-bsp/u-boot/u-boot.inc  | 22 ++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-bsp/u-boot/u-boot-sign.inc

diff --git a/meta/recipes-bsp/u-boot/u-boot-sign.inc 
b/meta/recipes-bsp/u-boot/u-boot-sign.inc
new file mode 100644
index 000..c88a2a1
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot-sign.inc
@@ -0,0 +1,21 @@
+# This file is part of U-Boot verified boot support and is intended to be
+# included from u-boot recipe and from kernel-fitimage.bbclass
+#
+# The signature procedure requires the user to generate an RSA key and
+# certificate in a directory and to define the following variable:
+#
+# UBOOT_SIGN_KEYDIR = "/keys/directory"
+# UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", "dev.key")
+# UBOOT_SIGN_ENABLE = "1"
+#
+# The signature support is limited to the use of CONFIG_OF_SEPARATE in U-Boot.
+#
+# For more details, please refer to U-boot documentation.
+
+UBOOT_SIGN_ENABLE ?= "0"
+UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
+UBOOT_DTB_BINARY ?= "u-boot.dtb"
+UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
+UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
+UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
+UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 3ba866d..29b0b95 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -65,6 +65,28 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
 
+# The use of verified boot requires to share environment variables with kernel
+# fitImage class as the mkimage call requires dtb filepath to append signature
+# public key.
+require u-boot-sign.inc
+
+do_assemble_dtb() {
+   # Concatenate U-Boot w/o DTB & DTB with public key
+   # (cf. kernel-fitimage.bbclass for more details)
+   cd ${DEPLOYDIR}
+   if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ]; then
+   if [ -e "${UBOOT_NODTB_IMAGE}" -a -e "${UBOOT_DTB_IMAGE}" ]; 
then
+   cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
${UBOOT_IMAGE}
+   cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
${S}/${UBOOT_BINARY}
+   else
+   bbwarn "Failure while adding public key to u-boot 
binary. Verified boot won't be available."
+   fi
+   fi
+}
+
+addtask assemble_dtb after do_deploy before do_install
+do_assemble_dtb[depends] += "${@' 
${PREFERRED_PROVIDER_virtual/kernel}:do_assemble_fitimage' if 
'${UBOOT_SIGN_ENABLE}' == '1' else ''}"
+
 do_compile () {
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' 
config.mk
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH 2/4] u-boot: deploy u-boot nodtb and dtb files

[Yannick Gicquel]

This enable the deployment of u-boot-nodtb.bin and u-boot.dtb files.

Signed-off-by: Yannick Gicquel 
---
 meta/recipes-bsp/u-boot/u-boot.inc | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 29b0b95..749f8d8 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -239,6 +239,20 @@ do_deploy () {
 rm -f ${UBOOT_BINARY} ${UBOOT_SYMLINK}
 ln -sf ${UBOOT_IMAGE} ${UBOOT_SYMLINK}
 ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
+
+# OF_SEPARATE generated files deployment
+if [ -f ${S}/${UBOOT_DTB_BINARY} ]; then
+install ${S}/${UBOOT_DTB_BINARY} ${DEPLOYDIR}/${UBOOT_DTB_IMAGE}
+rm -f ${UBOOT_DTB_BINARY} ${UBOOT_DTB_SYMLINK}
+ln -sf ${UBOOT_DTB_IMAGE} ${UBOOT_DTB_SYMLINK}
+ln -sf ${UBOOT_DTB_IMAGE} ${UBOOT_DTB_BINARY}
+fi
+if [ -f ${S}/${UBOOT_NODTB_BINARY} ]; then
+install ${S}/${UBOOT_NODTB_BINARY} 
${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
+rm -f ${UBOOT_NODTB_BINARY} ${UBOOT_NODTB_SYMLINK}
+ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_SYMLINK}
+ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_BINARY}
+fi
fi
 
 if [ "x${UBOOT_ELF}" != "x" ]
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH 3/4] kernel: fitimage: support device tree compiler options

[Yannick Gicquel]

This introduces a new variable to set the device tree compiler options while
calling mkimage ('-D' option). By default, this variable is not set but it can
be defined in a configuration file, as following example:

UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"

Signed-off-by: Yannick Gicquel 
---
 meta/classes/kernel-fitimage.bbclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index e5b75ed..62e0017 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -17,6 +17,9 @@ python __anonymous () {
 d.appendVarFlag('do_assemble_fitimage', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
 }
 
+# Options for the device tree compiler passed to mkimage '-D' feature:
+UBOOT_MKIMAGE_DTCOPTS ??= ""
+
 #
 # Emit the fitImage ITS header
 #
@@ -209,7 +212,10 @@ do_assemble_fitimage() {
#
# Step 4: Assemble the image
#
-   uboot-mkimage -f fit-image.its arch/${ARCH}/boot/fitImage
+   uboot-mkimage \
+   ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if 
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+   -f fit-image.its \
+   arch/${ARCH}/boot/fitImage
fi
 }
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH 4/4] kernel: fitimage: basic support for fitimage signature

[Yannick Gicquel]

This is an initial support of fitImage signature to enable U-Boot verified
boot. This feature is implemented by adding a signature tag to the
configuration section of the generated fit-image.its file.

When a UBOOT_SIGN_ENABLE variable is set to "1", the signature procedure is
activated and performs a second call to mkimage to sign the fitImage file and
to include the public key in the deployed U-Boot device tree blob. (This
implementation depends on the use of CONFIG_OF_SEPARATE in U-Boot.)

As the U-Boot device tree blob is appended in the deploy dir, a dependency
on 'u-boot:do_deploy' is added when the feature is activated.

Signed-off-by: Yannick Gicquel 
---
 meta/classes/kernel-fitimage.bbclass | 45 +++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 62e0017..cbf07ba 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,5 +1,8 @@
 inherit kernel-uboot
 
+# To resolve the following UBOOT_DTB_BINARY identifier
+require recipes-bsp/u-boot/u-boot-sign.inc
+
 python __anonymous () {
 kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
 if kerneltype == 'fitImage':
@@ -15,6 +18,12 @@ python __anonymous () {
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
 d.appendVarFlag('do_assemble_fitimage', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
+
+# Verified boot will sign the fitImage and append the public key to
+# U-boot dtb. We ensure the U-Boot dtb is deployed before assembling
+# the fitImage:
+if d.getVar('UBOOT_SIGN_ENABLE', True):
+d.appendVarFlag('do_assemble_fitimage', 'depends', ' 
u-boot:do_deploy')
 }
 
 # Options for the device tree compiler passed to mkimage '-D' feature:
@@ -132,6 +141,9 @@ EOF
 fitimage_emit_section_config() {
 
conf_csum="sha1"
+   if [ -n "${UBOOT_SIGN_ENABLE}" ] ; then
+   conf_sign_keyname="${UBOOT_SIGN_KEYNAME}"
+   fi
 
# Test if we have any DTBs at all
if [ -z "${2}" ] ; then
@@ -152,6 +164,26 @@ fitimage_emit_section_config() {
 hash@1 {
 algo = "${conf_csum}";
 };
+EOF
+
+   if [ ! -z "${conf_sign_keyname}" ] ; then
+
+   if [ -z "${2}" ] ; then
+   sign_line="sign-images = \"kernel\";"
+   else
+   sign_line="sign-images = \"fdt\", \"kernel\";"
+   fi
+
+   cat << EOF >> fit-image.its
+signature@1 {
+algo = "${conf_csum},rsa2048";
+key-name-hint = "${conf_sign_keyname}";
+sign-images = "fdt", "kernel";
+};
+EOF
+   fi
+
+   cat << EOF >> fit-image.its
 };
 EOF
 }
@@ -160,7 +192,7 @@ do_assemble_fitimage() {
if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
kernelcount=1
dtbcount=""
-   rm -f fit-image.its
+   rm -f fit-image.its arch/${ARCH}/boot/fitImage
 
fitimage_emit_fit_header
 
@@ -216,6 +248,17 @@ do_assemble_fitimage() {
${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if 
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
-f fit-image.its \
arch/${ARCH}/boot/fitImage
+
+   #
+   # Step 5: Sign the image and add public key to U-Boot dtb
+   #
+   if test -n "${UBOOT_SIGN_ENABLE}"; then
+   uboot-mkimage \
+   ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if 
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+   -F -k "${UBOOT_SIGN_KEYDIR}" \
+   -K "${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_BINARY}" \
+   -r arch/${ARCH}/boot/fitImage
+   fi
fi
 }
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH 0/4] U-Boot verified boot basic support

[Yannick Gicquel]

Hello,

Please find a patchset proposal for U-Boot verified boot basic support.
Before submitting those, I would like to ask people on this list some feedbacks
on the way it's currently implemented.

The verified boot support principle is to sign a kernel fitImage, thanks to an
SSL keypair, and to append a public key in u-boot device tree blob to enable
software integrity check at runtime.

The proposal depends on the U-Boot CONFIG_OF_SEPARATE which in effect splits
U-Boot binaries allowing the DTB file to be outside the main u-boot binaries.

Thus, regarding the current fitImage generation, the following is proposed:

 - extend the generated fit-images.its file from kernel-fitimage.bbclass in
   order to add a 'signature' tag to the configuration section, then add a call
   to uboot-mkimage to sign the fitImage and append the public key to DTB file.

 - add a task in u-boot.inc 'do_assemble_dtb' which concatenates the device
   tree blob with public key to u-boot binary, and organize the u-boot and
   virtual/kernel recipes' tasks this way:

   u-boot:do_deploy -> virtual/kernel:do_assemble_fitimage -> 
u-boot:do_assemble_dtb

To enable the verified boot, the following variables can be added in a 
configuration file:

   KERNEL_CLASSES ?= " kernel-fitimage "
   KERNEL_IMAGETYPE ?= "fitImage"
   UBOOT_SIGN_KEYDIR = "/signature/keys/directory"
   UBOOT_SIGN_KEYNAME = "dev"
   UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
   UBOOT_SIGN_ENABLE = "1"

Well, I don't know if these changes are the way to go, but at least I think
this limits the codes changes and it propagates the feature to BSP layers which
uses u-boot.inc. Anyway, I would be pleased to get feedback on this.

Best regards,
Yannick

Yannick Gicquel (4):
  u-boot: basic support of device tree blob reassembly
  u-boot: deploy u-boot nodtb and dtb files
  kernel: fitimage: support device tree compiler options
  kernel: fitimage: basic support for fitimage signature

 meta/classes/kernel-fitimage.bbclass| 53 +++--
 meta/recipes-bsp/u-boot/u-boot-sign.inc | 21 +
 meta/recipes-bsp/u-boot/u-boot.inc  | 36 ++
 3 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-bsp/u-boot/u-boot-sign.inc

-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic: isoimage-isohybrid: implement grubefi menu logic

[Ed Bartosh]

Hi Ioan-Adrian,

It's my fault as I've rewritten ks parser and missed --menu implementation.
Let me know if you need my help with this.

It would be great if you also add test case for this feature to wic oe-selftest 
suite.

Regards,
Ed

On Tue, Apr 19, 2016 at 03:17:56PM +0300, Ioan-Adrian Ratiu wrote:
> Hello Ed,
> 
> I've tested it on Jethro. Sorry about this. I'll look at the changes in wic's 
> kickstart and redo/resubmit.
> 
> Thank you,
> Ioan
> 
> On Mon, 18 Apr 2016 16:24:11 +0300
> Ed Bartosh  wrote:
> 
> > Hi Ioan-Adrian,
> > 
> > Did you test if this patch works on master?
> > From the first look I'd say it will not work as --menu bootloader
> > option is not implemented there.
> > 
> > On Mon, Apr 18, 2016 at 03:46:22PM +0300, Ioan-Adrian Ratiu wrote:
> > > Right now isoimage-isohybrid creates a single boot menu entry "boot"
> > > and passes it the arguments supplied with "--append". There is logic
> > > for creating custom grub menus, but it is sadly not used. "boot" is
> > > hardcoded.
> > > 
> > > This change makes isoimage use the wic bootloader "--menu" argument to
> > > create its menus. The syntax used for menu specification was chosen so
> > > it does not conflict with the kernel parameter syntax (you can pass
> > > custom kernel arguments from the generated grub menu entries, like for
> > > example silent booting, thread affinity etc.).
> > > 
> > > The "--menu" argument syntax is as following. The argument supplies a
> > > collection of menu entry names and kernel parameters. Menu name entries
> > > can contain any ASCII character except | or : which are separators.
> > > Kernel parameters obey the syntax defined by the kernel documentation.
> > > | is the menu separator and : is the separator between the menu names
> > > and parameters.
> > > 
> > > Example for use in wks files:
> > >   --menu "Menu Name:firstarg,secondard|Menu Name 2:anotherarg,otherarg"
> > > 
> > > Signed-off-by: Ioan-Adrian Ratiu 
> > > ---
> > >  .../lib/wic/plugins/source/isoimage-isohybrid.py   | 35 
> > > --
> > >  1 file changed, 26 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
> > > b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > > index bc99283..4b0b035 100644
> > > --- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > > +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > > @@ -101,23 +101,40 @@ class IsoImagePlugin(SourcePlugin):
> > >  splashline = ""
> > >  
> > >  bootloader = creator.ks.bootloader
> > > +kernel = "/bzImage"
> > > +default_options = bootloader.append
> > > +default_menu_to_boot = "Default boot"
> > > +grub_menus = ""
> > > +
> > > +# menu separators are '|', custom boot args separated by ':', ex.
> > > +# --menu "Menu Name:firstarg,secondard|Menu Name 
> > > 2:anotherarg,otherarg"
> > > +for menu in bootloader.menus.split('|'):
> > > +menu_list = menu.split(":")
> > > +menu_name = menu_list[0]
> > > +grub_menu_options = ""
> > > +
> > > +if (len(menu_list) > 1):
> > > +menu_params = menu_list[1]
> > > +for param in menu_params.split(','):
> > > +if param.lower() == "default":
> > > +default_menu_to_boot = menu_name
> > > +else: grub_menu_options += " " + param
> > > +
> > > +grub_menus += "menuentry '%s' {\n" % menu_name
> > > +grub_menus += "linux %s rootwait %s %s\n" % \
> > > +(kernel, default_options, grub_menu_options)
> > > +grub_menus += "initrd /initrd \n"
> > > +grub_menus += "}\n"
> > >  
> > >  grubefi_conf = ""
> > >  grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> > >  grubefi_conf += "--parity=no --stop=1\n"
> > > -grubefi_conf += "default=boot\n"
> > > +grubefi_conf += "default=%s\n" % default_menu_to_boot
> > >  grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> > >  grubefi_conf += "\n"
> > >  grubefi_conf += "search --set=root --label %s " % part.label
> > >  grubefi_conf += "\n"
> > > -grubefi_conf += "menuentry 'boot'{\n"
> > > -
> > > -kernel = "/bzImage"
> > > -
> > > -grubefi_conf += "linux %s rootwait %s\n" \
> > > -% (kernel, bootloader.append)
> > > -grubefi_conf += "initrd /initrd \n"
> > > -grubefi_conf += "}\n"
> > > +grubefi_conf += grub_menus
> > >  
> > >  if splashline:
> > >  grubefi_conf += "%s\n" % splashline  
> > 
> > --
> > Regards,
> > Ed
> 

-- 
--
Regards,
Ed
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Mark Hatle]

On 4/19/16 2:33 AM, Hongxu Jia wrote:
> Hi all,
> 
> With some investigation, there is an example to explain how to do remote 
> debug.
> 
> Also file [YOCTO #9481] for document.
> 
> Hi Andreas,
> 
> Would you please have a look the example, to see if it could fit your case.
> 
> Example:
> 
> 1. Build a image with gdbserver and gzip installed. The gzip
>is the debug binary. Append the following to local.conf
> ...
> IMAGE_INSTALL_append = " gdbserver gzip"
> ...
> 
> $ bitbake core-image-sato
> 
> 2. Build gdb-cross for remote debug on host
> 
> $ bitbake gdb-cross-i586
> 
> 3. start qemu
> 
> $ runqemu qemux86 core-image-sato
> 
> 4. On host side, create symlink /usr/src/debug to
>${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS} which the
>location of sources is /usr/src/debug.
> 
> $ ln -snf /TOPDIR/tmp/work/i586-poky-linux /usr/src/debug

This is incorrect.  On the host you use the combination of:

(gdb) set sysroot 
(gdb) set substitute-path /usr/src/debug /usr/src/debug

> 5. On target side, ipaddr is 128.224.163.187,
>run gdbserver to debug "gzip -h"
> 
> root@qemux86-64:~# gdbserver localhost:1024 gzip -h
> Process gzip created; pid = 530
> Listening on port 1024
> 
> 6. On host side, enter gzip's devshell
> $ bitbake -cdevshell gzip
> 
> 7. On host side, run gdb-cross to remote debug gzip
> 
> gzip-1.6# i586-poky-linux-gdb ../build/gzip
> 
> 8. Use path ${STAGING_DIR_HOST} as the system root for
>the program being debugged. Any absolute shared
>library paths will be prefixed with path;
> 
> (gdb) set sysroot /TOPDIR/tmp/sysroots/qemux86
> 
> 
> 9. Start remote target, set break point at help()
> 
> (gdb) target remote 128.224.163.187:1024
> (gdb) break gzip.c:325
> (gdb) info break
> Num Type   Disp Enb AddressWhat
> 1   breakpoint keep y   0x00401ec1 in main at
> /usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:325
> (gdb) c
> Continuing.
> 
> Breakpoint 1, main (argc=2, argv=0x7fffeca8) at
> /usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:465
> 465 help(); do_exit(OK); break;
> (gdb) list
> 460 case 'd':
> 461 decompress = 1; break;
> 462 case 'f':
> 463 force++; break;
> 464 case 'h': case 'H':
> 465 help(); do_exit(OK); break;
> 466 case 'k':
> 467 keep = 1; break;
> 468 case 'l':
> 469 list = decompress = to_stdout = 1; break;
> (gdb) c
> Continuing.
> [Inferior 1 (process 1246) exited normally]
> 
> 
> 10. On target side, get output of "gzip -h"
> [snip]
> Remote debugging from host 128.224.153.74
> Usage: gzip [OPTION]... [FILE]...
> Compress or uncompress FILEs (by default, compress FILES in-place).
> 
> Mandatory arguments to long options are mandatory for short options too.
> 
>   -c, --stdout  write on standard output, keep original files unchanged
>   -d, --decompress  decompress
>   -f, --force   force overwrite of output file and compress links
>   -h, --helpgive this help
>   -k, --keepkeep (don't delete) input files
>   -l, --listlist compressed file contents
>   -L, --license display software license
>   -n, --no-name do not save or restore the original name and time stamp
>   -N, --namesave or restore the original name and time stamp
>   -q, --quiet   suppress all warnings
>   -r, --recursive   operate recursively on directories
>   -S, --suffix=SUF  use suffix SUF on compressed files
>   -t, --testtest compressed file integrity
>   -v, --verbose verbose mode
>   -V, --version display version number
>   -1, --fastcompress faster
>   -9, --bestcompress better
> 
> With no FILE, or when FILE is -, read standard input.
> 
> Report bugs to .
> 
> Child exited with status 0
> GDBserver exiting
> [snip]
> 
> //Hongxu
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Mark Hatle]

On 4/18/16 11:32 PM, Paul Eggleton wrote:
> On Mon, 18 Apr 2016 13:50:15 Mark Hatle wrote:
>> On 4/18/16 9:16 AM, Andreas Müller wrote:
>>> On Mon, Apr 18, 2016 at 3:55 PM, Burton, Ross  
> wrote:
 On 18 April 2016 at 14:08, Hongxu Jia  wrote:
> If sysroot is required, override DEBUG_FLAGS to remove
> -fdebug-prefix-map

 We should probably get this in the release notes, as many people do
 indeed
 want remote debug to work.

 Can you tell gdb the base path to use when looking for symbols?  I've not
 done remote GDB for some time but wouldn't "set substitute-path /
 //my/sysroot/" work?  Or maybe /usr /my/sysroot/usr?

 If gdb can't be told then instead of having to replace all of DEBUG_FLAGS
 it would be neat if the prefix mapping variables where in another
 variable that could just be unset.

 Ross
>>>
>>> OK I think I could live with removing -fdebug-prefix-map for now.
>>>
>>> A thought: We have the setting IMAGE_GEN_DEBUGFS - I have not yet
>>> tested. As far as I understand it creates an unstripped sysroot and
>>> does not affect target rootfs - is that correct? Does the sysroot
>>> created by IMAGE_GEN_DEBUGFS contain the sources? If yes we could set
>>> that as sysroot for gdb.
>>>
>>> I think one of the problems we have here is that there is no reference
>>> way documented (or it is outdated) how remote debugging is meant to be
>>> performed.
>>
>> Remote debugging is setup to always assume the remote side has access to a
>> debugable sysroot.  This isn't the project's sysroot, since that is
>> transient, but a REAL matching sysroot to the main image.
>>
>> The easiest way to do this is to add the following to your local.conf:
>>IMAGE_GEN_DEBUGFS = '1'
>>
>> After this, look in your deploy directory and you will see the image to
>> deploy to the target, and also a matching 'debug' chunk that you keep on
>> your local host.  This way you -know- they are always in sync.
>>
>> There is class material from the various Yocto Project Dev Day classes on
>> using this.
> 
> I thought I'd seen this go into the manual but I can't seem to find it; I 
> also 
> can't find said Dev Day class material online. Mark, would you be able to 
> work 
> with Scott R to get this documented both within the variable reference and in 
> a task-oriented manner?
> 
> In the mean time, Jefro - is the recent dev day material available somewhere? 
> I can only find 2014 (ELCE Dusseldorf) under "Training" on the YP website.

(I thought these steps were documented as well, and also were part of the
beginner material.  But I've also not been able to find it -- as I've only got
the advanced class materials for Ireland and San Diego.)


The steps are in the Dusseldorf slides:

http://www.yoctoproject.org/bulk/devday-eu-2014/ypdd14-reyna-iot-hands-on-lab.pdf

Slide 28 shows the old way of producing the debugfs.  The new way is to use the
IMAGE_GEN_DEBUGFS = "1".  You then extract it (and the original rootfs) into a
single directory.  In the slides that directory is called "debugfs".


Start on slide 44.

The setup for GDB (on the host side):

(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) file debugfs/usr/bin/morseapp

This assumes your CWD is the place with the exracted debugfs (produced by the
IMAGE_GEN_DEBUGFS = "1").

The substitute-path is what allows the (host) to find the matching symbols for
the items.  You simply set:

set substitute-path  

By using the debugfs, you don't have to set this to 100 different locations, you
can simply use a single location.

--Mark

> Thanks,
> Paul
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] create-pull-request: create branch on remote if not found

[Bruce Ashfield]

On Mon, Apr 18, 2016 at 11:13 PM, Robert Yang 
wrote:

>
>
> On 04/19/2016 11:00 AM, Bruce Ashfield wrote:
>
>>
>>
>> On Mon, Apr 18, 2016 at 10:45 PM, Robert Yang > > wrote:
>>
>> Before this patch, we need two steps to create PULL:
>> * Step 1, create branch:
>>$ git push  :
>> * Step 2, create PULL:
>>$ create-pull-request -u  -l  -b
>> 
>> -r ~
>>
>> We can see that the args used in step 1 are in step 2, so we can use
>> create-pull-request to create the branch if not found to simplify the
>> steps.
>>
>>
>> I think this needs to be optional. When I'm running this script, I'm just
>> looking to have something
>> I've already pushed locally dumped. If I mess up, and don't have the
>> branch that
>> I've used
>> pushed to my remote already (or for  whatever reason want/need different
>> branches .. which
>> was broken in previous updates to the script .. grrr),  I don't want
>> something
>> pushing a branch
>> without be explicitly giving permission for that to happen.
>>
>
> Thanks, how about add an option:
>
> "-a automatically push/update local branch (-l) to remote branch (-b)"
>
> Then it will always create/update the remote branch when -a is used.
>

That would meet my requirement. So looks fine to me. Others of course have
the
right to object :)

Cheers,

Bruce


>
> // Robert
>
>
>> Bruce
>>
>>
>> [YOCTO #9408]
>>
>> Signed-off-by: Robert Yang > >
>>
>> ---
>>   scripts/create-pull-request | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/create-pull-request b/scripts/create-pull-request
>> index 479ad6e..7dc9836 100755
>> --- a/scripts/create-pull-request
>> +++ b/scripts/create-pull-request
>> @@ -173,8 +173,8 @@ esac
>>   if [ -n "$WEB_URL" ]; then
>>  wget --no-check-certificate -q $WEB_URL -O /dev/null
>>  if [ $? -ne 0 ]; then
>> -   echo "WARNING: Branch '$BRANCH' was not found on the
>> contrib
>> git tree."
>> -   echo " Please check your remote and branch
>> parameter
>> before sending."
>> +   echo "Branch '$BRANCH' not found on '$REMOTE',
>> creating it..."
>> +   git push $REMOTE $L_BRANCH:$BRANCH
>>  echo ""
>>  fi
>>   fi
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> 
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
>> at its
>> end"
>>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic: isoimage-isohybrid: implement grubefi menu logic

[Ioan-Adrian Ratiu]

Hello Ed,

I've tested it on Jethro. Sorry about this. I'll look at the changes in wic's 
kickstart and redo/resubmit.

Thank you,
Ioan

On Mon, 18 Apr 2016 16:24:11 +0300
Ed Bartosh  wrote:

> Hi Ioan-Adrian,
> 
> Did you test if this patch works on master?
> From the first look I'd say it will not work as --menu bootloader
> option is not implemented there.
> 
> On Mon, Apr 18, 2016 at 03:46:22PM +0300, Ioan-Adrian Ratiu wrote:
> > Right now isoimage-isohybrid creates a single boot menu entry "boot"
> > and passes it the arguments supplied with "--append". There is logic
> > for creating custom grub menus, but it is sadly not used. "boot" is
> > hardcoded.
> > 
> > This change makes isoimage use the wic bootloader "--menu" argument to
> > create its menus. The syntax used for menu specification was chosen so
> > it does not conflict with the kernel parameter syntax (you can pass
> > custom kernel arguments from the generated grub menu entries, like for
> > example silent booting, thread affinity etc.).
> > 
> > The "--menu" argument syntax is as following. The argument supplies a
> > collection of menu entry names and kernel parameters. Menu name entries
> > can contain any ASCII character except | or : which are separators.
> > Kernel parameters obey the syntax defined by the kernel documentation.
> > | is the menu separator and : is the separator between the menu names
> > and parameters.
> > 
> > Example for use in wks files:
> >   --menu "Menu Name:firstarg,secondard|Menu Name 2:anotherarg,otherarg"
> > 
> > Signed-off-by: Ioan-Adrian Ratiu 
> > ---
> >  .../lib/wic/plugins/source/isoimage-isohybrid.py   | 35 
> > --
> >  1 file changed, 26 insertions(+), 9 deletions(-)
> > 
> > diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
> > b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > index bc99283..4b0b035 100644
> > --- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > @@ -101,23 +101,40 @@ class IsoImagePlugin(SourcePlugin):
> >  splashline = ""
> >  
> >  bootloader = creator.ks.bootloader
> > +kernel = "/bzImage"
> > +default_options = bootloader.append
> > +default_menu_to_boot = "Default boot"
> > +grub_menus = ""
> > +
> > +# menu separators are '|', custom boot args separated by ':', ex.
> > +# --menu "Menu Name:firstarg,secondard|Menu Name 
> > 2:anotherarg,otherarg"
> > +for menu in bootloader.menus.split('|'):
> > +menu_list = menu.split(":")
> > +menu_name = menu_list[0]
> > +grub_menu_options = ""
> > +
> > +if (len(menu_list) > 1):
> > +menu_params = menu_list[1]
> > +for param in menu_params.split(','):
> > +if param.lower() == "default":
> > +default_menu_to_boot = menu_name
> > +else: grub_menu_options += " " + param
> > +
> > +grub_menus += "menuentry '%s' {\n" % menu_name
> > +grub_menus += "linux %s rootwait %s %s\n" % \
> > +(kernel, default_options, grub_menu_options)
> > +grub_menus += "initrd /initrd \n"
> > +grub_menus += "}\n"
> >  
> >  grubefi_conf = ""
> >  grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> >  grubefi_conf += "--parity=no --stop=1\n"
> > -grubefi_conf += "default=boot\n"
> > +grubefi_conf += "default=%s\n" % default_menu_to_boot
> >  grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> >  grubefi_conf += "\n"
> >  grubefi_conf += "search --set=root --label %s " % part.label
> >  grubefi_conf += "\n"
> > -grubefi_conf += "menuentry 'boot'{\n"
> > -
> > -kernel = "/bzImage"
> > -
> > -grubefi_conf += "linux %s rootwait %s\n" \
> > -% (kernel, bootloader.append)
> > -grubefi_conf += "initrd /initrd \n"
> > -grubefi_conf += "}\n"
> > +grubefi_conf += grub_menus
> >  
> >  if splashline:
> >  grubefi_conf += "%s\n" % splashline  
> 
> --
> Regards,
> Ed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] git: update to 2.7.4

[Alexander Kanavin]

This should also fix recent CVEs:
https://ma.ttias.be/remote-code-execution-git-versions-client-server-2-7-1-cve-2016-2324-cve-2016-2315/

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/git/git_2.7.2.bb | 11 ---
 meta/recipes-devtools/git/git_2.7.4.bb | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.7.2.bb
 create mode 100644 meta/recipes-devtools/git/git_2.7.4.bb

diff --git a/meta/recipes-devtools/git/git_2.7.2.bb 
b/meta/recipes-devtools/git/git_2.7.2.bb
deleted file mode 100644
index 3fd7151..000
--- a/meta/recipes-devtools/git/git_2.7.2.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "162ddc6c9b243899ad67ebd6b1c166b1"
-SRC_URI[tarball.sha256sum] = 
"58959e3ef3046403216a157dfc683c4d7f0dd83365463b8dd87063ded940a0df"
-SRC_URI[manpages.md5sum] = "7bb067d6363f537b92c3b8b813ff9ed6"
-SRC_URI[manpages.sha256sum] = 
"e6b5481fd6e24a1d1b155ef17363b313d47025bf6da880737fa872ab78e24f15"
diff --git a/meta/recipes-devtools/git/git_2.7.4.bb 
b/meta/recipes-devtools/git/git_2.7.4.bb
new file mode 100644
index 000..bc72793
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.7.4.bb
@@ -0,0 +1,11 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.md5sum] = "c64012d491e24c7d65cd389f75383d91"
+SRC_URI[tarball.sha256sum] = 
"7104c4f5d948a75b499a954524cb281fe30c6649d8abe20982936f75ec1f275b"
+SRC_URI[manpages.md5sum] = "58020dc13a5801c49f7986fef7027535"
+SRC_URI[manpages.sha256sum] = 
"0dfe1931ad302873470e0280248e3aa50502b5edd00dcc3e9c9173667b6fea6a"
-- 
2.8.0.rc3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] license.bbclass: postpone image license manifest creation until image postprocessing phase

[Markus Lehtonen]

This is a proposed fix to yocto bug #9446. It should fix the reported issue
although is was not able to reproduce the problem.

Markus Lehtonen (1):
  license.bbclass: do write_deploy_manifest in image postprocessing

 meta/classes/license.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] license.bbclass: do write_deploy_manifest in image postprocessing

[Markus Lehtonen]

Call write_deploy_manifest() in image postprocessing phase, instead of
rootfs postprocessing. The reason being that not necessarily all
do_deploy tasks are dependencies of the do_rootfs and we might miss
something.

[YOCTO #9446]

Signed-off-by: Markus Lehtonen 
---
 meta/classes/license.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 94be559..43944e6 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -650,9 +650,12 @@ SSTATETASKS += "do_populate_lic"
 do_populate_lic[sstate-inputdirs] = "${LICSSTATEDIR}"
 do_populate_lic[sstate-outputdirs] = "${LICENSE_DIRECTORY}/"
 
-ROOTFS_POSTPROCESS_COMMAND_prepend = "write_package_manifest; 
write_deploy_manifest; license_create_manifest; "
+ROOTFS_POSTPROCESS_COMMAND_prepend = "write_package_manifest; 
license_create_manifest; "
 do_rootfs[recrdeptask] += "do_populate_lic"
 
+IMAGE_POSTPROCESS_COMMAND_prepend = "write_deploy_manifest; "
+do_image[recrdeptask] += "do_populate_lic"
+
 do_populate_lic_setscene[dirs] = "${LICSSTATEDIR}/${PN}"
 do_populate_lic_setscene[cleandirs] = "${LICSSTATEDIR}"
 python do_populate_lic_setscene () {
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] devtool: sdk-update: fix handling of UNINATIVE_CHECKSUM changes

[Paul Eggleton]

If UNINATIVE_CHECKSUM changes over an SDK update, bitbake within the
extensible SDK will be broken because it will see that the matching
uninative tarball doesn't exist and if there is a default value of
UNINATIVE_URL it will attempt to download the file and will then fail
because the checksums don't match up; alternatively if no UNINATIVE_URL
is set then it'll also fail with an error about misconfiguration. To fix
this, add some logic to devtool sdk-update to download the matching
uninative tarball(s) for the checksum(s) in the newly fetched SDK
configuration.

Fixes [YOCTO #9301].

Signed-off-by: Paul Eggleton 
---
 scripts/lib/devtool/sdk.py | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index a22841d..46fd12b 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -23,6 +23,7 @@ import shutil
 import errno
 import sys
 import tempfile
+import re
 from devtool import exec_build_env_command, setup_tinfoil, parse_recipe, 
DevtoolError
 
 logger = logging.getLogger('devtool')
@@ -209,6 +210,28 @@ def sdk_update(args, config, basepath, workspace):
 logger.error("Updating %s failed" % changedfile)
 return ret
 
+# Check if UNINATIVE_CHECKSUM changed
+uninative = False
+if 'conf/local.conf' in changedfiles:
+def read_uninative_checksums(fn):
+chksumitems = []
+with open(fn, 'r') as f:
+for line in f:
+if line.startswith('UNINATIVE_CHECKSUM'):
+splitline = re.split(r'[\[\]"\']', line)
+if len(splitline) > 3:
+chksumitems.append((splitline[1], 
splitline[3]))
+return chksumitems
+
+oldsums = read_uninative_checksums(os.path.join(basepath, 
'conf/local.conf'))
+newsums = read_uninative_checksums(os.path.join(tmpsdk_dir, 
'conf/local.conf'))
+if oldsums != newsums:
+uninative = True
+for buildarch, chksum in newsums:
+uninative_file = os.path.join('downloads', 
'uninative', chksum, '%s-nativesdk-libc.tar.bz2' % buildarch)
+mkdir(os.path.join(tmpsdk_dir, 
os.path.dirname(uninative_file)))
+ret = subprocess.call("wget -q -O %s %s/%s" % 
(uninative_file, updateserver, uninative_file), shell=True, cwd=tmpsdk_dir)
+
 # Ok, all is well at this point - move everything over
 tmplayers_dir = os.path.join(tmpsdk_dir, 'layers')
 if os.path.exists(tmplayers_dir):
@@ -220,6 +243,9 @@ def sdk_update(args, config, basepath, workspace):
 shutil.move(os.path.join(tmpsdk_dir, changedfile), destfile)
 os.remove(os.path.join(conf_dir, 'sdk-conf-manifest'))
 shutil.move(tmpmanifest, conf_dir)
+if uninative:
+shutil.rmtree(os.path.join(basepath, 'downloads', 'uninative'))
+shutil.move(os.path.join(tmpsdk_dir, 'downloads', 
'uninative'), os.path.join(basepath, 'downloads'))
 
 if not sstate_mirrors:
 with open(os.path.join(conf_dir, 'site.conf'), 'a') as f:
-- 
2.5.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] Fix for eSDK update interaction with uninative checksum changes

[Paul Eggleton]

The following changes since commit e003ef038819c10f351bb8268b377626c95bb077:

  toasterconf.json: Update for krogoth release (2016-04-18 16:48:58 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib 
paule/extsdk-uninative-update
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/extsdk-uninative-update

Paul Eggleton (1):
  devtool: sdk-update: fix handling of UNINATIVE_CHECKSUM changes

 scripts/lib/devtool/sdk.py | 26 ++
 1 file changed, 26 insertions(+)

-- 
2.5.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] base.bbclass: Introduce PACKAGECONFIG_CONFARGS variable

[Martin Jansa]

* add separate variable for configuration options generated from
  PACKAGECONFIG setting, this helps other bbclasses and recipes
  to take advantage of PACKAGECONFIG mechanism, without including
  other options from EXTRA_OECONF
* e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options
  from PACKAGECONFIG:
  EXTRA_QMAKEVARS_PRE +=
  but with
  conf/distro/include/no-static-libs.inc
  it means getting --disable-static as invalid option inside
  EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried
  to use poky with meta-qt5.
* once we migrate all bbclasses and recipes to PACKAGECONFIG_CONFARGS
  we should also restrict EXTRA_OECONF append only to autotools.bbclass
  like I did for cmake.bbclass

Signed-off-by: Martin Jansa 
---
 meta/classes/base.bbclass  | 9 ++---
 meta/classes/cmake.bbclass | 2 ++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index f9697a9..0259259 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -428,9 +428,12 @@ python () {
 extraconf.append(items[1])
 appendVar('DEPENDS', extradeps)
 appendVar('RDEPENDS_${PN}', extrardeps)
-if bb.data.inherits_class('cmake', d):
-appendVar('EXTRA_OECMAKE', extraconf)
-else:
+appendVar('PACKAGECONFIG_CONFARGS', extraconf)
+
+# TODO once are all recipes/bbclass abusign EXTRA_OECONF
+# to get PACKAGECONFIG options fixed to use PACKAGECONFIG_CONFARGS
+# move this append to autotools.bbclass
+if not bb.data.inherits_class('cmake', d):
 appendVar('EXTRA_OECONF', extraconf)
 
 pn = d.getVar('PN', True)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 22cd61e..02f313a 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -27,6 +27,8 @@ OECMAKE_EXTRA_ROOT_PATH ?= ""
 OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
 OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
 
+EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
+
 # CMake expects target architectures in the format of uname(2),
 # which do not always match TARGET_ARCH, so all the necessary
 # conversions should happen here.
-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] base.bbclass: Introduce EXTRA_CONF_PACKAGECONFIG variable

[Martin Jansa]

On Mon, Apr 18, 2016 at 07:49:51PM -0300, Otavio Salvador wrote:
> On Mon, Apr 18, 2016 at 7:45 PM, Richard Purdie
>  wrote:
> > On Mon, 2016-04-18 at 19:31 -0300, Otavio Salvador wrote:
> >> On Fri, Mar 25, 2016 at 8:55 AM, Martin Jansa  >> > wrote:
> >> > Was there some agreement about variable name?
> >>
> >> meta-qt5 5.6 is using this so we need a final decision if it will be
> >> merged or not. I am in favor it as I think it is clear enough.
> >
> > It was an RFC and I still don't get a good feeling about the names
> > used.
> >
> > I suggested:
> >
> > PACKAGECONFIG_CONFPARAMS
> > or
> > PACKAGECONFIG_CONFARGS
> 
> I like CONFARGS.

I'll send patch with PACKAGECONFIG_CONFARGS and wait until it's merged
somewhere, before updating usages of this in other layers (so that I
don't need to redo it again if the name is changed again).

> > as it then makes things slightly clearer these things are coming from
> > PACKAGECONFIG. We have a namespace which is a bit of a mess and I'd
> > prefer to try and improve with new things if we can...
> >
> > The fact meta-qt5 is already using this is bad, it really shouldn't be.
> > We're also very close to the final build of 2.1 right now so this would
> > be a very late change :/.

meta-qt5/master isn't using it, it's only in master-next, because
without this change the builds are broken when people use
openembedded-core/meta/conf/distro/include/no-static-libs.inc
e.g. with default Poky config.

> I think it is a safe change but I am fine in postponing it for 2.2. In
> this case we need to revert the usage of it in meta-qt5 (which I also
> support).

Nothing needs to be reverted, because it wasn't merged in any permanent
layer.

If it doesn't go to 2.1 then I'll leave meta-qt5/krogoth version broken
for Poky builds with no-static-libs.inc.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2 1/1] bash: fixed ptest run-builtins failed

[Dengke Du]

1. redirect the stderr output of the command exec with -l option to
   /dev/null.
   Because when we run command exec with -l option in builtins.tests,
   it is a login shell, so it would read the file /etc/profile, that
   file executes the /usr/bin/resize which added by commit:
 cc6360f4c4d97ef9d3545f381224ee99ce7d
   The /usr/bin/resize is produced by busybox that source code resize.c
   contains:
fprintf(stderr, ESC"7" ESC"[r" ESC"[999;999H" ESC"[6n");
   In the end, it outputs an escape sequence to the stderr, so when we
   compare the test output file /tmp/xx with builtins.right, it failed.
   we need to redirect the stderr output to the /dev/null to solve the
   problem.

2. ensure the target system contains the locales "en_US.UTF-8".
   Because when run the run-builtins, it executes the source5.sub file
   that contain:
LC_ALL=en_US.UTF-8
   such as add the following to the local.conf:
IMAGE_LINGUAS_append = " en-us"

Signed-off-by: Dengke Du 
---
 .../bash/bash/fix-run-builtins.patch   | 33 ++
 meta/recipes-extended/bash/bash_4.3.30.bb  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-extended/bash/bash/fix-run-builtins.patch

diff --git a/meta/recipes-extended/bash/bash/fix-run-builtins.patch 
b/meta/recipes-extended/bash/bash/fix-run-builtins.patch
new file mode 100644
index 000..2fa3883
--- /dev/null
+++ b/meta/recipes-extended/bash/bash/fix-run-builtins.patch
@@ -0,0 +1,33 @@
+From 0c4cab9594c96c2dc435a8d9724605824bcbf917 Mon Sep 17 00:00:00 2001
+From: Dengke Du 
+Date: Tue, 19 Apr 2016 02:57:45 -0400
+Subject: [PATCH] fix run-builtins failed
+
+FAIL: run-builtins
+1. redirect the stderr output of command exec with -l option in
+   builtins.tests to /dev/null
+2. ensure the system contain the locales "en_US.UTF-8"
+
+Upstream-Status: Pending
+
+Signed-off-by: Dengke Du 
+---
+ tests/builtins.tests | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/builtins.tests b/tests/builtins.tests
+index 9d77520..63f3af8 100644
+--- a/tests/builtins.tests
 b/tests/builtins.tests
+@@ -109,7 +109,7 @@ esac
+ 
+ # test options to exec
+ (exec -a specialname ${THIS_SH} -c 'echo $0' )
+-(exec -l -a specialname ${THIS_SH} -c 'echo $0' )
++(exec -l -a specialname ${THIS_SH} -c 'echo $0' ) 2> /dev/null
+ # test `clean' environment.  if /bin/sh is bash, and the script version of
+ # printenv is run, there will be variables in the environment that bash
+ # sets on startup.  Also test code that prefixes argv[0] with a dash.
+-- 
+2.8.1
+
diff --git a/meta/recipes-extended/bash/bash_4.3.30.bb 
b/meta/recipes-extended/bash/bash_4.3.30.bb
index 4426cf0..95ed392 100644
--- a/meta/recipes-extended/bash/bash_4.3.30.bb
+++ b/meta/recipes-extended/bash/bash_4.3.30.bb
@@ -20,6 +20,7 @@ SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
file://test-output.patch \
file://fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch \
file://run-ptest \
+  file://fix-run-builtins.patch \
"
 
 SRC_URI[tarball.md5sum] = "a27b3ee9be83bd3ba448c0ff52b28447"
-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2 0/1] bash: fixed ptest run-builtins failed

[Dengke Du]

The following changes since commit ee25d0e3987d7732a2e46e1640693b4cf419a9fc:

  toasterconf.json: Update for krogoth release (2016-04-18 16:49:28 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib 
dengke/fixed-bash-ptest-run-builtins-failed
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=dengke/fixed-bash-ptest-run-builtins-failed

Dengke Du (1):
  bash: fixed ptest run-builtins failed

 .../bash/bash/fix-run-builtins.patch   | 33 ++
 meta/recipes-extended/bash/bash_4.3.30.bb  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-extended/bash/bash/fix-run-builtins.patch

-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used

[Hongxu Jia]

Hi all,

With some investigation, there is an example to explain how to do remote 
debug.


Also file [YOCTO #9481] for document.

Hi Andreas,

Would you please have a look the example, to see if it could fit your case.

Example:

1. Build a image with gdbserver and gzip installed. The gzip
   is the debug binary. Append the following to local.conf
...
IMAGE_INSTALL_append = " gdbserver gzip"
...

$ bitbake core-image-sato

2. Build gdb-cross for remote debug on host

$ bitbake gdb-cross-i586

3. start qemu

$ runqemu qemux86 core-image-sato

4. On host side, create symlink /usr/src/debug to
   ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS} which the
   location of sources is /usr/src/debug.

$ ln -snf /TOPDIR/tmp/work/i586-poky-linux /usr/src/debug

5. On target side, ipaddr is 128.224.163.187,
   run gdbserver to debug "gzip -h"

root@qemux86-64:~# gdbserver localhost:1024 gzip -h
Process gzip created; pid = 530
Listening on port 1024

6. On host side, enter gzip's devshell
$ bitbake -cdevshell gzip

7. On host side, run gdb-cross to remote debug gzip

gzip-1.6# i586-poky-linux-gdb ../build/gzip

8. Use path ${STAGING_DIR_HOST} as the system root for
   the program being debugged. Any absolute shared
   library paths will be prefixed with path;

(gdb) set sysroot /TOPDIR/tmp/sysroots/qemux86


9. Start remote target, set break point at help()

(gdb) target remote 128.224.163.187:1024
(gdb) break gzip.c:325
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x00401ec1 in main at 
/usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:325

(gdb) c
Continuing.

Breakpoint 1, main (argc=2, argv=0x7fffeca8) at 
/usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:465

465 help(); do_exit(OK); break;
(gdb) list
460 case 'd':
461 decompress = 1; break;
462 case 'f':
463 force++; break;
464 case 'h': case 'H':
465 help(); do_exit(OK); break;
466 case 'k':
467 keep = 1; break;
468 case 'l':
469 list = decompress = to_stdout = 1; break;
(gdb) c
Continuing.
[Inferior 1 (process 1246) exited normally]


10. On target side, get output of "gzip -h"
[snip]
Remote debugging from host 128.224.153.74
Usage: gzip [OPTION]... [FILE]...
Compress or uncompress FILEs (by default, compress FILES in-place).

Mandatory arguments to long options are mandatory for short options too.

  -c, --stdout  write on standard output, keep original files unchanged
  -d, --decompress  decompress
  -f, --force   force overwrite of output file and compress links
  -h, --helpgive this help
  -k, --keepkeep (don't delete) input files
  -l, --listlist compressed file contents
  -L, --license display software license
  -n, --no-name do not save or restore the original name and time stamp
  -N, --namesave or restore the original name and time stamp
  -q, --quiet   suppress all warnings
  -r, --recursive   operate recursively on directories
  -S, --suffix=SUF  use suffix SUF on compressed files
  -t, --testtest compressed file integrity
  -v, --verbose verbose mode
  -V, --version display version number
  -1, --fastcompress faster
  -9, --bestcompress better

With no FILE, or when FILE is -, read standard input.

Report bugs to .

Child exited with status 0
GDBserver exiting
[snip]

//Hongxu

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] meta.bbclass: set INHIBIT_DEFAULT_DEPS

[Richard Purdie]

On Tue, 2016-04-19 at 15:33 +1200, Paul Eggleton wrote:
> On Mon, 18 Apr 2016 21:27:25 Burton, Ross wrote:
> > On 18 April 2016 at 03:57, Robert Yang 
> > wrote:
> > > The recipe which inherits meta.bbclass doesn't require any
> > > default deps.
> > 
> > meta is only inherited by one class (populate_sdk_base.bbclass) and
> > three
> > recipes (two of which indirectly inherit populate_sdk_base) so do
> > we really
> > need this class?  Maybe we should drop it in the 2.2 cycle.
> 
> I don't think we ought to be in too much of a hurry to remove this -
> it's 
> still a handy class. Besides I was planning on using it to solve this
> issue:
> 
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=9257 

I have the opposite view. Its pretty much impossible to tell what a
"meta" class would do from its name or have any idea of whether a given
change should be added to the class since its purpose is so vague.

I'l like to see it renamed to something more useful, or removed given
its just two lines...

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core