[linux-yocto] [master][yocto-4.15][PATCH] features/intel-pmc: add Intel pmc core support

[Dengke Du]

From: Liwei Song 

Add PMC Driver support for Intel Core SoC.

Signed-off-by: Liwei Song 
Signed-off-by: Bruce Ashfield 
Signed-off-by: Dengke Du 
---
 features/intel-pmc/intel-pmc-core.cfg | 1 +
 features/intel-pmc/intel-pmc-core.scc | 4 
 2 files changed, 5 insertions(+)
 create mode 100644 features/intel-pmc/intel-pmc-core.cfg
 create mode 100644 features/intel-pmc/intel-pmc-core.scc

diff --git a/features/intel-pmc/intel-pmc-core.cfg 
b/features/intel-pmc/intel-pmc-core.cfg
new file mode 100644
index 000..55f7132
--- /dev/null
+++ b/features/intel-pmc/intel-pmc-core.cfg
@@ -0,0 +1 @@
+CONFIG_INTEL_PMC_CORE=m
diff --git a/features/intel-pmc/intel-pmc-core.scc 
b/features/intel-pmc/intel-pmc-core.scc
new file mode 100644
index 000..f822086
--- /dev/null
+++ b/features/intel-pmc/intel-pmc-core.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Intel Core SoC Power Management Controller 
feature"
+define KFEATURE_COMPATIBILITY board
+
+kconf hardware intel-pmc-core.cfg
-- 
2.7.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Excluding ptest packages from image build

[ChenQi]

I just checked the codes. I think the ref manual might be a little 
misleading.
"Prevents specific packages from being installed when you are installing 
complementary packages. "

might better be changed to:
"Prevents specific packages to install their complementary packages. 
Items specified by this variable are considered as regular expression."

Maybe an example should follow.

So specifying value 'acl' for PACKAGE_EXCLUDE_COMPLEMENTARY should be 
valid and its complementary packages should not be installed. Specifying 
'acl.*' should have the same effect, but 'acl.' should not.


Anyway, I think you should file a bug with steps to reproduce the problem.

Also, I found that we currently don't have a mechanism to exclude some 
specific complementary package (e.g. acl-ptest in your case). We might 
need to reconsider what PACKAGE_EXCLUDE should mean.
More specifically, if a user requires *-ptest packages in general, but 
wants to exclude acl-ptest package, there's no easy way to do so.


Best Regards,
Chen Qi

On 05/09/2018 11:30 PM, Erik Nellessen wrote:

I would like to exclude some ptest packages from an image build.

To include ptest packages in general, my image recipe contains the 
following line:

IMAGE_FEATURES_append = " ptest-pkgs"

As a first step, I tried to exclude the acl-ptest package. To do so, I 
added the following to my image recipe:

PACKAGE_EXCLUDE_COMPLEMENTARY = "acl-ptest"

I thought that this would exclude the acl-ptest package as described 
in the project reference: 
https://www.yoctoproject.org/docs/2.4.2/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE_COMPLEMENTARY
"Prevents specific packages from being installed when you are 
installing complementary packages.


You might find that you want to prevent installing certain packages 
when you are installing complementary packages. For example, if you 
are using IMAGE_FEATURES to install dev-pkgs, you might not want to 
install all packages from a particular multilib. If you find yourself 
in this situation, you can use the PACKAGE_EXCLUDE_COMPLEMENTARY 
variable to specify regular expressions to match the packages you want 
to exclude."


Anyhow this did not result in an image without the acl-ptest package, 
as I could validate by having a look at the image's manifest file.


When I changed the image recipe to contain the regular expression 
"acl", i.e

PACKAGE_EXCLUDE_COMPLEMENTARY = "acl"
all three acl packages (acl, acl-lic, acl-ptest) were excluded from 
the image.


And to really start the confusion, when changed the regular expression 
to "acl.", i.e.

PACKAGE_EXCLUDE_COMPLEMENTARY = "acl."
all three packages were also excluded.

Now I am really confused. My expectation was that "acl-ptest" and 
"acl" would match the acl-ptest package name and "acl." would not 
match the acl package name.


Does anybody see what I am missing here?

Thanks in advance,
Erik





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Looking at using Yocto, have General Adoption questions

[Khem Raj]

Hi Richard

On 5/9/18 1:03 PM, Richard Koch wrote:

Hello list.

I'm looking for some general use cases for how a firmware development 
team such as ourselves has adopted Yocto in to their non-Yocto based 
environment.


We have a group of firmware developers that currently develop for 
various iMX6 based
controller boards. For those boards we have not been using Yocto but 
utilize a patched kernel and u-boot from the SOM mfr.

We then modified those and developed our own rootfs (manually).

Our build is source controlled through SVN. We use Linaro based ARM 
cross compilers to
build u-boot/kernel and our applications. This is packaged up in to a 
.deb file and installed
as an upgrade on to an SDCard that already contains a baseline 
u-boot/kernel/rootfs.


We have requirements for a new design that we would like to base off of 
the NXP MCIMX7D-SABRE eval board.
For this eval board there is a suggested BSP that to use which is Yocto 
based.


I have followed NXP's Yocto guide to download, configure, and build an 
SDCard image which boots

successfully on this eval board.

The Yocto build consumed ~26GB of disk space and took most of the day to 
build on an i7 Quad 32GB Ubuntu 16.04 PC.


So I am wondering how to introduce this to our current build environment 
and development team.
I understand the concept is to take the imx7dsabresd recipe/meta-layer/? 
and port that to our own design.


After successfully porting the eval BSP to our own design;

How does a team of developers such as ourselves:



I would suggest that you generate a eSDK, then let your teams use eSDK 
for doing development, configure a CI system which is integrating the 
changes and creating updates for extensible SDK, the diskspace and build 
time is first one investment you would do thereafter it would be 
incremental on the builder, for your dev teams it would be all prebuilt 
and they would only build the things they change


https://wiki.yoctoproject.org/wiki/Extensible_SDK
https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK



Control the source code changes?


There are several ways you can do it, use a sandbox tool like android 
repo to manage the project, where you create local mirrors of upstream 
nxp layers repos and create your internal branches for yourself which 
follow the corresponding upstream branches. Then you can manually merge 
or cherry-pick changes from upstream repositories as you wish to do.

You can also use git submodules to manage the project

If you dont make any changes to upstream layers then you might not want 
to create local branches and still use something like android repo or 
git submodules to manage the project.


see following for git-submodule based example

https://github.com/cbrake/oe-build/

IIRC NXP already uses repo to manage projects but here is another example

https://github.com/Angstrom-distribution/angstrom-manifest


Do we check/convert the whole Yocto git repo in to our SVN or is there a 
suggested way to trim down to a manageable subset?


It would be better if you were to use git for SCM since merging/syncing 
would become so much streamlined but you can use SVN if you have to, you 
might not be able to use the workspace management tools like above but 
you can still use something like gclient probably


How do we update our new recipe/meta-layer/? when the NXP 
recipe/meta-layer/? we derived it from changes upstream due to 
security/bug fixes?



see above



Appreciate any advice,



hope that helps. Feel free to ask further questions.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Looking at using Yocto, have General Adoption questions

[Richard Koch]

Hello list.

I'm looking for some general use cases for how a firmware development team such 
as ourselves has adopted Yocto in to their non-Yocto based environment.

We have a group of firmware developers that currently develop for various iMX6 
based
controller boards. For those boards we have not been using Yocto but utilize a 
patched kernel and u-boot from the SOM mfr.
We then modified those and developed our own rootfs (manually).

Our build is source controlled through SVN. We use Linaro based ARM cross 
compilers to
build u-boot/kernel and our applications. This is packaged up in to a .deb file 
and installed
as an upgrade on to an SDCard that already contains a baseline 
u-boot/kernel/rootfs.

We have requirements for a new design that we would like to base off of the NXP 
MCIMX7D-SABRE eval board.
For this eval board there is a suggested BSP that to use which is Yocto based.

I have followed NXP's Yocto guide to download, configure, and build an SDCard 
image which boots
successfully on this eval board.

The Yocto build consumed ~26GB of disk space and took most of the day to build 
on an i7 Quad 32GB Ubuntu 16.04 PC.

So I am wondering how to introduce this to our current build environment and 
development team.
I understand the concept is to take the imx7dsabresd recipe/meta-layer/? and 
port that to our own design.

After successfully porting the eval BSP to our own design;

How does a team of developers such as ourselves:

Control the source code changes?
Do we check/convert the whole Yocto git repo in to our SVN or is there a 
suggested way to trim down to a manageable subset?
How do we update our new recipe/meta-layer/? when the NXP recipe/meta-layer/? 
we derived it from changes upstream due to security/bug fixes?

Appreciate any advice,

-Rick


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to create a build for ARM Cortex-A8, S5PV210

[Andre McCurdy]

On Tue, May 8, 2018 at 1:38 PM, Denis  wrote:
> Hi. I'm new to yocto. So I have followed a tutorial and now I have crewated
> my first yocto distro for i386.
>
> Now I need to create a build for my device. It is a Samsung S5PV210 device,
> Cortex A8.
>
> Here there is a description
>
> http://www.friendlyarm.net/products/mini210
>
> Can someone suggest me how to setup the yocto build for this target?

Start by creating a machine config. That could initially be very
minimal, for example, just:

  require conf/machine/include/tune-cortexa8.inc

might be enough to build a toolchain and a minimal rootfs image with
command line tools which will run on your board (if the board comes
with a pre-built kernel then you may be able to use the pre-built
kernel to run the OE rootfs - just for an initial test).

Next step would be to create a kernel recipe, so that you can create a
complete kernel + rootfs with OE.

After that, add recipes for any components which are machine specific
but are not part of the kernel (e.g. out of tree kernel driver
modules, etc).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

[Andre McCurdy]

On Wed, May 9, 2018 at 5:40 PM, Matt Hoosier  wrote:
> On Wed, May 9, 2018 at 6:27 PM, Andre McCurdy  wrote:
>>
>> On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier 
>> wrote:
>> > From: Matt Hoosier 
>> >
>> > Although the submodules' histories have been fetched during the
>> > do_fetch() phase, the mechanics used to clone the workdir copy
>> > of the repo haven't been transferring the actual .git/modules
>> > directory from the repo fetched into downloads/ during the
>> > fetch task.
>> >
>> > Fix that, and for good measure also explicitly tell Git to avoid
>> > hitting the network during do_unpack() of the submodules.
>> >
>> > Ref:
>> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12739
>>
>> Patches for bitbake should be sent to the bitbake-devel mailing list:
>>
>>   http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
> Right, okay. How's that meant to work for stuff developed in-tree with poky?
> Do you manually want the 'bitbake/' leading directory stripped off before
> emailing the patch?

Yes, patches for bitbake should apply directly to a clone of the bitbake repo.

Manually editing a patch created from poky is certainly do-able, but
applying the patch to a genuine bikebake repo (with "git am -p2 ...")
and re-generating the patch from there may be safer. Whichever you
prefer.

>> > ---
>> >  bitbake/lib/bb/fetch2/gitsm.py | 12 +++-
>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/bitbake/lib/bb/fetch2/gitsm.py
>> > b/bitbake/lib/bb/fetch2/gitsm.py
>> > index 0aff1008e5..1f3fc44352 100644
>> > --- a/bitbake/lib/bb/fetch2/gitsm.py
>> > +++ b/bitbake/lib/bb/fetch2/gitsm.py
>> > @@ -132,4 +132,14 @@ class GitSM(Git):
>> >
>> >  if self.uses_submodules(ud, d, ud.destdir):
>> >  runfetchcmd(ud.basecmd + " checkout " +
>> > ud.revisions[ud.names[0]], d, workdir=ud.destdir)
>> > -runfetchcmd(ud.basecmd + " submodule update --init
>> > --recursive", d, workdir=ud.destdir)
>> > +
>> > +# Copy over the submodules' fetched histories too.
>> > +if ud.bareclone:
>> > +repo_conf = ud.destdir
>> > +else:
>> > +repo_conf = os.path.join(ud.destdir, '.git')
>> > +runfetchcmd("cp -pr %s %s" % (os.path.join(ud.clonedir,
>> > 'modules'), repo_conf), d)
>> > +
>> > +# Careful not to hit the network during unpacking; all
>> > history should already
>> > +# be fetched.
>> > +runfetchcmd(ud.basecmd + " submodule update --init
>> > --recursive --no-fetch", d, workdir=ud.destdir)
>> > --
>> > 2.13.6
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

[Matt Hoosier]

On Wed, May 9, 2018 at 6:27 PM, Andre McCurdy  wrote:

> On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier 
> wrote:
> > From: Matt Hoosier 
> >
> > Although the submodules' histories have been fetched during the
> > do_fetch() phase, the mechanics used to clone the workdir copy
> > of the repo haven't been transferring the actual .git/modules
> > directory from the repo fetched into downloads/ during the
> > fetch task.
> >
> > Fix that, and for good measure also explicitly tell Git to avoid
> > hitting the network during do_unpack() of the submodules.
> >
> > Ref:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12739
>
> Patches for bitbake should be sent to the bitbake-devel mailing list:
>
>   http://lists.openembedded.org/mailman/listinfo/bitbake-devel



Right, okay. How's that meant to work for stuff developed in-tree with
poky? Do you manually want the 'bitbake/' leading directory stripped off
before emailing the patch?



>
>
> > ---
> >  bitbake/lib/bb/fetch2/gitsm.py | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/bitbake/lib/bb/fetch2/gitsm.py
> b/bitbake/lib/bb/fetch2/gitsm.py
> > index 0aff1008e5..1f3fc44352 100644
> > --- a/bitbake/lib/bb/fetch2/gitsm.py
> > +++ b/bitbake/lib/bb/fetch2/gitsm.py
> > @@ -132,4 +132,14 @@ class GitSM(Git):
> >
> >  if self.uses_submodules(ud, d, ud.destdir):
> >  runfetchcmd(ud.basecmd + " checkout " +
> ud.revisions[ud.names[0]], d, workdir=ud.destdir)
> > -runfetchcmd(ud.basecmd + " submodule update --init
> --recursive", d, workdir=ud.destdir)
> > +
> > +# Copy over the submodules' fetched histories too.
> > +if ud.bareclone:
> > +repo_conf = ud.destdir
> > +else:
> > +repo_conf = os.path.join(ud.destdir, '.git')
> > +runfetchcmd("cp -pr %s %s" % (os.path.join(ud.clonedir,
> 'modules'), repo_conf), d)
> > +
> > +# Careful not to hit the network during unpacking; all
> history should already
> > +# be fetched.
> > +runfetchcmd(ud.basecmd + " submodule update --init
> --recursive --no-fetch", d, workdir=ud.destdir)
> > --
> > 2.13.6
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

[Andre McCurdy]

On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier  wrote:
> From: Matt Hoosier 
>
> Although the submodules' histories have been fetched during the
> do_fetch() phase, the mechanics used to clone the workdir copy
> of the repo haven't been transferring the actual .git/modules
> directory from the repo fetched into downloads/ during the
> fetch task.
>
> Fix that, and for good measure also explicitly tell Git to avoid
> hitting the network during do_unpack() of the submodules.
>
> Ref:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12739

Patches for bitbake should be sent to the bitbake-devel mailing list:

  http://lists.openembedded.org/mailman/listinfo/bitbake-devel

> ---
>  bitbake/lib/bb/fetch2/gitsm.py | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
> index 0aff1008e5..1f3fc44352 100644
> --- a/bitbake/lib/bb/fetch2/gitsm.py
> +++ b/bitbake/lib/bb/fetch2/gitsm.py
> @@ -132,4 +132,14 @@ class GitSM(Git):
>
>  if self.uses_submodules(ud, d, ud.destdir):
>  runfetchcmd(ud.basecmd + " checkout " + 
> ud.revisions[ud.names[0]], d, workdir=ud.destdir)
> -runfetchcmd(ud.basecmd + " submodule update --init --recursive", 
> d, workdir=ud.destdir)
> +
> +# Copy over the submodules' fetched histories too.
> +if ud.bareclone:
> +repo_conf = ud.destdir
> +else:
> +repo_conf = os.path.join(ud.destdir, '.git')
> +runfetchcmd("cp -pr %s %s" % (os.path.join(ud.clonedir, 
> 'modules'), repo_conf), d)
> +
> +# Careful not to hit the network during unpacking; all history 
> should already
> +# be fetched.
> +runfetchcmd(ud.basecmd + " submodule update --init --recursive 
> --no-fetch", d, workdir=ud.destdir)
> --
> 2.13.6
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

[Matt Hoosier]

From: Matt Hoosier 

Although the submodules' histories have been fetched during the
do_fetch() phase, the mechanics used to clone the workdir copy
of the repo haven't been transferring the actual .git/modules
directory from the repo fetched into downloads/ during the
fetch task.

Fix that, and for good measure also explicitly tell Git to avoid
hitting the network during do_unpack() of the submodules.

Ref:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12739
---
 bitbake/lib/bb/fetch2/gitsm.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
index 0aff1008e5..1f3fc44352 100644
--- a/bitbake/lib/bb/fetch2/gitsm.py
+++ b/bitbake/lib/bb/fetch2/gitsm.py
@@ -132,4 +132,14 @@ class GitSM(Git):
 
 if self.uses_submodules(ud, d, ud.destdir):
 runfetchcmd(ud.basecmd + " checkout " + ud.revisions[ud.names[0]], 
d, workdir=ud.destdir)
-runfetchcmd(ud.basecmd + " submodule update --init --recursive", 
d, workdir=ud.destdir)
+
+# Copy over the submodules' fetched histories too.
+if ud.bareclone:
+repo_conf = ud.destdir
+else:
+repo_conf = os.path.join(ud.destdir, '.git')
+runfetchcmd("cp -pr %s %s" % (os.path.join(ud.clonedir, 
'modules'), repo_conf), d)
+
+# Careful not to hit the network during unpacking; all history 
should already
+# be fetched.
+runfetchcmd(ud.basecmd + " submodule update --init --recursive 
--no-fetch", d, workdir=ud.destdir)
-- 
2.13.6

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Revert "u-boot: Update RPi Zero W defconfig to support DTB."

[Andrei Gherzan]

On Wed, May 9, 2018 at 7:10 PM, Ryan Harkin  wrote:

> Apologies all,
>
> I forgot to add [meta-raspberrypi] to the subject line.
>
> Andrei,
>
> Please let me know if you'd like me to resend. Assuming you don't have a
> fix for this in flight already.
>
> Regards,
> Ryan.
>
>
I was just going to point that out. Anyway, the patch/fix is already in
master.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Revert "u-boot: Update RPi Zero W defconfig to support DTB."

[Ryan Harkin]

Apologies all,

I forgot to add [meta-raspberrypi] to the subject line.

Andrei,

Please let me know if you'd like me to resend. Assuming you don't have a
fix for this in flight already.

Regards,
Ryan.


On 9 May 2018 at 19:07, Ryan Harkin  wrote:

> This reverts commit 72bc798ff548ba610e8dea53c80e39a37de8e043
>
> The following error was encountered when building the Yocto master:
>
> ERROR: u-boot-1_2018.03-r0 do_patch: Command Error: 'quilt --quiltrc
> /linaro/mbl/workspace-linaro/build-mbl/tmp-mbl-glibc/work/
> raspberrypi3-oe-linux-gnueabi/u-boot/1_2018.03-r0/recipe-
> sysroot-native/etc/quiltrc
> push' exited with 0  Output:
> Applying patch 0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch
> patching file configs/rpi_0_w_defconfig
> Hunk #1 FAILED at 12.
> 1 out of 1 hunk FAILED -- rejects in file configs/rpi_0_w_defconfig
> Patch 0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch does not apply
> (enforce with -f)
> ERROR: u-boot-1_2018.03-r0 do_patch: Function failed: patch_do_patch
> ERROR: Logfile of failure stored in:
> /linaro/mbl/workspace-linaro/build-mbl/tmp-mbl-glibc/work/
> raspberrypi3-oe-linux-gnueabi/u-boot/1_2018.03-r0/temp/log.do_patch.13706
> ERROR: Task
> (/linaro/mbl/workspace-linaro/build-mbl/conf/../../layers/
> openembedded-core/meta/recipes-bsp/u-boot/u-boot_2018.03.bb:do_patch)
> failed with exit code '1'
>
> The u-boot patch the original commit was attempting to apply has gone
> upstream, so remove this commit as it is no longer necessary.
>
> Signed-off-by: Ryan Harkin 
> ---
>  ...-rpi_0_w-Add-configs-consistent-with-RpI3.patch | 41
> --
>  recipes-bsp/u-boot/u-boot_%.bbappend   |  8 +
>  2 files changed, 1 insertion(+), 48 deletions(-)
>  delete mode 100644 recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-
> consistent-with-RpI3.patch
>
> diff --git 
> a/recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch
> b/recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-
> consistent-with-RpI3.patch
> deleted file mode 100644
> index e98fd85..000
> --- a/recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-
> consistent-with-RpI3.patch
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -From 5d113dc0130ea2ea9faaa000fba9c737266b9747 Mon Sep 17 00:00:00 2001
> -From: Drew Moseley 
> -Date: Fri, 9 Feb 2018 18:10:09 -0500
> -Subject: [PATCH] rpi_0_w: Add configs consistent with RpI3
> -
> -Upstream-Status: Accepted [https://patchwork.ozlabs.org/patch/856572/]
> -
> -Signed-off-by: Drew Moseley 
> 
> - configs/rpi_0_w_defconfig | 7 +++
> - 1 file changed, 7 insertions(+)
> -
> -diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
> -index 9a6d24b..1248294 100644
>  a/configs/rpi_0_w_defconfig
> -+++ b/configs/rpi_0_w_defconfig
> -@@ -12,14 +12,21 @@ CONFIG_SYS_PROMPT="U-Boot> "
> - CONFIG_CMD_GPIO=y
> - CONFIG_CMD_MMC=y
> - CONFIG_CMD_USB=y
> -+CONFIG_OF_EMBED=y
> -+CONFIG_ENV_FAT_INTERFACE="mmc"
> -+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> -+CONFIG_DM_KEYBOARD=y
> - CONFIG_DM_MMC=y
> - CONFIG_MMC_SDHCI=y
> - CONFIG_MMC_SDHCI_BCM2835=y
> - CONFIG_DM_ETH=y
> - CONFIG_USB=y
> - CONFIG_DM_USB=y
> -+CONFIG_USB_DWC2=y
> - CONFIG_USB_STORAGE=y
> - CONFIG_USB_KEYBOARD=y
> -+CONFIG_USB_HOST_ETHER=y
> -+CONFIG_USB_ETHER_SMSC95XX=y
> - CONFIG_DM_VIDEO=y
> - CONFIG_SYS_WHITE_ON_BLACK=y
> - CONFIG_CONSOLE_SCROLL_LINES=10
> ---
> -2.7.4
> -
> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend
> b/recipes-bsp/u-boot/u-boot_%.bbappend
> index 7d4a49e..3781666 100644
> --- a/recipes-bsp/u-boot/u-boot_%.bbappend
> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend
> @@ -1,7 +1 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot:"
> -
> -SRC_URI_append_rpi = " \
> -file://0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch \
> -"
> -
> -DEPENDS_append_rpi = " rpi-u-boot-scr"
> +RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
> --
> 2.7.4
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Revert "u-boot: Update RPi Zero W defconfig to support DTB."

[Ryan Harkin]

This reverts commit 72bc798ff548ba610e8dea53c80e39a37de8e043

The following error was encountered when building the Yocto master:

ERROR: u-boot-1_2018.03-r0 do_patch: Command Error: 'quilt --quiltrc
/linaro/mbl/workspace-linaro/build-mbl/tmp-mbl-glibc/work/raspberrypi3-oe-linux-gnueabi/u-boot/1_2018.03-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0  Output:
Applying patch 0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch
patching file configs/rpi_0_w_defconfig
Hunk #1 FAILED at 12.
1 out of 1 hunk FAILED -- rejects in file configs/rpi_0_w_defconfig
Patch 0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch does not apply
(enforce with -f)
ERROR: u-boot-1_2018.03-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored in:
/linaro/mbl/workspace-linaro/build-mbl/tmp-mbl-glibc/work/raspberrypi3-oe-linux-gnueabi/u-boot/1_2018.03-r0/temp/log.do_patch.13706
ERROR: Task
(/linaro/mbl/workspace-linaro/build-mbl/conf/../../layers/openembedded-core/meta/recipes-bsp/u-boot/u-boot_2018.03.bb:do_patch)
failed with exit code '1'

The u-boot patch the original commit was attempting to apply has gone
upstream, so remove this commit as it is no longer necessary.

Signed-off-by: Ryan Harkin 
---
 ...-rpi_0_w-Add-configs-consistent-with-RpI3.patch | 41 --
 recipes-bsp/u-boot/u-boot_%.bbappend   |  8 +
 2 files changed, 1 insertion(+), 48 deletions(-)
 delete mode 100644 
recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch

diff --git 
a/recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch 
b/recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch
deleted file mode 100644
index e98fd85..000
--- 
a/recipes-bsp/u-boot/u-boot/0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-From 5d113dc0130ea2ea9faaa000fba9c737266b9747 Mon Sep 17 00:00:00 2001
-From: Drew Moseley 
-Date: Fri, 9 Feb 2018 18:10:09 -0500
-Subject: [PATCH] rpi_0_w: Add configs consistent with RpI3
-
-Upstream-Status: Accepted [https://patchwork.ozlabs.org/patch/856572/]
-
-Signed-off-by: Drew Moseley 

- configs/rpi_0_w_defconfig | 7 +++
- 1 file changed, 7 insertions(+)
-
-diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
-index 9a6d24b..1248294 100644
 a/configs/rpi_0_w_defconfig
-+++ b/configs/rpi_0_w_defconfig
-@@ -12,14 +12,21 @@ CONFIG_SYS_PROMPT="U-Boot> "
- CONFIG_CMD_GPIO=y
- CONFIG_CMD_MMC=y
- CONFIG_CMD_USB=y
-+CONFIG_OF_EMBED=y
-+CONFIG_ENV_FAT_INTERFACE="mmc"
-+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
-+CONFIG_DM_KEYBOARD=y
- CONFIG_DM_MMC=y
- CONFIG_MMC_SDHCI=y
- CONFIG_MMC_SDHCI_BCM2835=y
- CONFIG_DM_ETH=y
- CONFIG_USB=y
- CONFIG_DM_USB=y
-+CONFIG_USB_DWC2=y
- CONFIG_USB_STORAGE=y
- CONFIG_USB_KEYBOARD=y
-+CONFIG_USB_HOST_ETHER=y
-+CONFIG_USB_ETHER_SMSC95XX=y
- CONFIG_DM_VIDEO=y
- CONFIG_SYS_WHITE_ON_BLACK=y
- CONFIG_CONSOLE_SCROLL_LINES=10
--- 
-2.7.4
-
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend 
b/recipes-bsp/u-boot/u-boot_%.bbappend
index 7d4a49e..3781666 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -1,7 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot:"
-
-SRC_URI_append_rpi = " \
-file://0002-rpi_0_w-Add-configs-consistent-with-RpI3.patch \
-"
-
-DEPENDS_append_rpi = " rpi-u-boot-scr"
+RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Excluding ptest packages from image build

[Erik Nellessen]

I would like to exclude some ptest packages from an image build.

To include ptest packages in general, my image recipe contains the 
following line:

IMAGE_FEATURES_append = " ptest-pkgs"

As a first step, I tried to exclude the acl-ptest package. To do so, I 
added the following to my image recipe:

PACKAGE_EXCLUDE_COMPLEMENTARY = "acl-ptest"

I thought that this would exclude the acl-ptest package as described in 
the project reference: 
https://www.yoctoproject.org/docs/2.4.2/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE_COMPLEMENTARY
"Prevents specific packages from being installed when you are installing 
complementary packages.


You might find that you want to prevent installing certain packages when 
you are installing complementary packages. For example, if you are using 
IMAGE_FEATURES to install dev-pkgs, you might not want to install all 
packages from a particular multilib. If you find yourself in this 
situation, you can use the PACKAGE_EXCLUDE_COMPLEMENTARY variable to 
specify regular expressions to match the packages you want to exclude."


Anyhow this did not result in an image without the acl-ptest package, as 
I could validate by having a look at the image's manifest file.


When I changed the image recipe to contain the regular expression "acl", i.e
PACKAGE_EXCLUDE_COMPLEMENTARY = "acl"
all three acl packages (acl, acl-lic, acl-ptest) were excluded from the 
image.


And to really start the confusion, when changed the regular expression 
to "acl.", i.e.

PACKAGE_EXCLUDE_COMPLEMENTARY = "acl."
all three packages were also excluded.

Now I am really confused. My expectation was that "acl-ptest" and "acl" 
would match the acl-ptest package name and "acl." would not match the 
acl package name.


Does anybody see what I am missing here?

Thanks in advance,
Erik



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Native curl and SSL CA certificates

[Iván Castell]

Thank you very much for your explanation Mr. Alexander, it was really
helpfull to understand my issue.

I fixed it removing completely my dnf bbappend recipe from my custom layer
and adding this variable to my distro.conf file:

PACKAGE_FEED_URIS = "https://storage.googleapis.com/my_repo/;

After that, at the end of the build process the image contains a valid
/etc/yum.d/oe-remote-repo file and all the necesary stuff to manage it.
There is no need to copy "ca-certificates.crt" manually at all.

Now its working as expected! :-)


2018-05-09 8:56 GMT+02:00 Alexander Kanavin <
alexander.kana...@linux.intel.com>:

> On 05/09/2018 09:29 AM, Iván Castell wrote:
>
>> But I am not fetching nor installing packages over the network during
>> image creation. I just build an image using local recipes (standard
>> procedure). One of those local recipes sets up a remote repository for rpm
>> packages (adding /etc/yum.repos.d/yocto-adv-rpm.repo to the final
>> image). The purpose of that remote repository is using it to update rpm
>> packages on target devices when they are running in production.
>>
>> In fact, I don't understand why yocto needs to synchronize that cache for
>> 'yocto-adv-rpm' repo during build time. It doesn't have any sense for me.
>> But the fact is that when the ca-certificates.crt is properly installed,
>> the build process ends fine. If that file is not properly installed, the
>> build process fails with the error reported in my previous message.
>>
>
> During image creation dnf is run several times, and it picks up its own
> configuration from the target rootfs. It is definitely not recommended to
> change that configuration behind dnf's back via installed recipes.
>
> The supported way to configure remote repositories is via
> PACKAGE_FEED_URIS:
> https://www.yoctoproject.org/docs/latest/dev-manual/dev-manu
> al.html#using-runtime-package-management
>
> Alex
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] System recovery

[Martin Townsend]

On Wed, May 9, 2018 at 11:21 AM, Enrico Bonomi
 wrote:
> Hi Martin,
>
> I'm newbie in yocto, but i used IMAGE_FSTYPES ="sdcard" to boot the system
> from SD card. What i want to obtain is to replace the broken file system
> that is located on the NAND with another one that works. A kind of recovery
> partition. is it possible from SD or should i create a recovery partition
> over the NAND?
>
> thanks
>
> Enrico
>
> 2018-05-09 11:25 GMT+02:00 Martin Townsend :
>>
>> Hi Enrico,
>>
>> UBI is only designed to work on raw NAND using the MTD subsystem.  MMC
>> will be a standard block device as the SD card will have Flash
>> Translation layer. See the excellent MTD website for more info
>> http://www.linux-mtd.infradead.org/doc/ubi.html
>>
>> In Yocto I believe you can use "sdcard" in the IMAGE_FSTYPES for a
>> flashable image for SD cards that can be used with U-Boot.
>>
>> -Martin.
>>
>>
>> On Wed, May 9, 2018 at 9:31 AM, Enrico Bonomi 
>> wrote:
>> > Hi,
>> >
>> > I work with Yocto Poky 1.7.3 on an imx6 dual lite SOM. I recently came
>> > across a problem with a preexisting system. Infact in a couple of cases,
>> > after about one year of work with no problems, file system results
>> > corrupted
>> > and the machine can't work. So i decide to implement a recovery system
>> > that
>> > can intervene in theese cases. An sd card is mounted on my board, so i
>> > think
>> > that i can use it to act this process. Using gparted i create a
>> > partition on
>> > sd card that can store my recovery file system.
>> > This partition starts at block 1581056 (so 0x00182000), every block has
>> > a
>> > size of 512 bytes and the file system size is 370262016 bytes (so
>> > 0x1611c000) that are 723168 blocks (so 0x000b08e0).
>> > In the u-boot i do the following instructions:
>> >
>> > nand erase.part rootfs
>> > ubi part rootfs
>> > ubi create rootfs
>> > mmc dev 0
>> > mmc read 1200 0x00182000  0x000b08e0
>> > ubi write 1200 rootfs 0x1611c000
>> > ubifsmount ubi0:rootfs
>> >
>> > and this instruction results in the following errors:
>> >
>> > UBIFS error (pid 0): ubifs_read_node: bad node type (0 but expected 6)
>> > UBIFS error (pid 0): ubifs_read_node: bad node at LEB 0:0
>> > UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume
>> > 'ubi0:rootfs' errno=-22!
>> >
>> > ubifsmount - mount UBIFS volume
>> >
>> > Usage:
>> > ubifsmount 
>> >- mount 'volume-name' volume
>> >
>> > the strange thing is that when i first program all new devices i use the
>> > following instruction:
>> >
>> > tftpboot prall
>> >
>> > and prall is the compiled of a txt file which, when programming file
>> > system
>> > use the same instructions, obviously except for
>> >
>> > tftp 1200 rootfs.ubifs
>> >
>> > instead of my mmc instructions, and
>> >
>> > ubi write 1200 rootfs ${filesize}
>> >
>> > but from what i understand the "filesize" variable is set from the tftp
>> > instruction
>> >
>> > Where do i fail?
>> >
>> > Thanks
>> >
>> > Enrico
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>
>

You forgot to reply to all so added the Yocto mailing list back in again.

You can create multiple images by specifying ubi and sdcard in
IMAGE_FSTYPES and then flash ubi to the raw NAND and then the sdcard
image to the SD then write the logic to perform the switch.

-Martin.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

My initial tests show couple issues, but usually caused by other changes in
that branch, not the gcc-8 itself.

1) strace-4.22 from
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
fails to build with ptest enabled (it builds with 4.20 version if I revert
this change)
../../strace-4.22/tests/inject-nf.c: In function 'main':
../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm
here
 }
 ^
Makefile:6313: recipe for target 'inject-nf.o' failed
make: *** [inject-nf.o] Error 1
make: Leaving directory 'strace/4.22-r0/build/tests'

2) glibc with obsolete rpc disabled from:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=0cd820424d4bdb5cc68e7503e09a0359fd21150a
causes busybox's mount applet to fail building:
util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
 # include 
   ^~~
compilation terminated.
make[1]: *** [util-linux/mount.o] Error 1
make: *** [util-linux] Error 2

3) grub and grub-efi fails to build with gcc8:
In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
..
../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct
grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^

4) iotivity fails to build with gcc8:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:
In lambda function:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30:
error: 'value' is not captured
 ocRep[KEY] = value;
  ^

5) nativesdk-libxcrypt fails to build (not sure which change caused this,
it build OK with sumo since the -std=gnu99 addition.
../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
before the last format character [-Werror=format-truncation=]
 "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
 ^~~

6) couple internal components which usually fail to build with gcc8,
because of more strict warnings + Werror.

I didn't get very far in testing, because our old kernel fails to build
with gcc8 and there are some other issues caused by other master changes.
But it doesn't look too bad (in my small test, lets see what bitbake world
will show), thanks a lot for new gcc.

Cheers,





On Sat, May 5, 2018 at 2:26 AM, Khem Raj  wrote:

> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend
> :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] System recovery

[Martin Townsend]

Hi Enrico,

UBI is only designed to work on raw NAND using the MTD subsystem.  MMC
will be a standard block device as the SD card will have Flash
Translation layer. See the excellent MTD website for more info
http://www.linux-mtd.infradead.org/doc/ubi.html

In Yocto I believe you can use "sdcard" in the IMAGE_FSTYPES for a
flashable image for SD cards that can be used with U-Boot.

-Martin.


On Wed, May 9, 2018 at 9:31 AM, Enrico Bonomi  wrote:
> Hi,
>
> I work with Yocto Poky 1.7.3 on an imx6 dual lite SOM. I recently came
> across a problem with a preexisting system. Infact in a couple of cases,
> after about one year of work with no problems, file system results corrupted
> and the machine can't work. So i decide to implement a recovery system that
> can intervene in theese cases. An sd card is mounted on my board, so i think
> that i can use it to act this process. Using gparted i create a partition on
> sd card that can store my recovery file system.
> This partition starts at block 1581056 (so 0x00182000), every block has a
> size of 512 bytes and the file system size is 370262016 bytes (so
> 0x1611c000) that are 723168 blocks (so 0x000b08e0).
> In the u-boot i do the following instructions:
>
> nand erase.part rootfs
> ubi part rootfs
> ubi create rootfs
> mmc dev 0
> mmc read 1200 0x00182000  0x000b08e0
> ubi write 1200 rootfs 0x1611c000
> ubifsmount ubi0:rootfs
>
> and this instruction results in the following errors:
>
> UBIFS error (pid 0): ubifs_read_node: bad node type (0 but expected 6)
> UBIFS error (pid 0): ubifs_read_node: bad node at LEB 0:0
> UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume
> 'ubi0:rootfs' errno=-22!
>
> ubifsmount - mount UBIFS volume
>
> Usage:
> ubifsmount 
>- mount 'volume-name' volume
>
> the strange thing is that when i first program all new devices i use the
> following instruction:
>
> tftpboot prall
>
> and prall is the compiled of a txt file which, when programming file system
> use the same instructions, obviously except for
>
> tftp 1200 rootfs.ubifs
>
> instead of my mmc instructions, and
>
> ubi write 1200 rootfs ${filesize}
>
> but from what i understand the "filesize" variable is set from the tftp
> instruction
>
> Where do i fail?
>
> Thanks
>
> Enrico
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] System recovery

[Enrico Bonomi]

Hi,

I work with Yocto Poky 1.7.3 on an imx6 dual lite SOM. I recently came
across a problem with a preexisting system. Infact in a couple of cases,
after about one year of work with no problems, file system results
corrupted and the machine can't work. So i decide to implement a recovery
system that can intervene in theese cases. An sd card is mounted on my
board, so i think that i can use it to act this process. Using gparted i
create a partition on sd card that can store my recovery file system.
This partition starts at block 1581056 (so 0x00182000), every block has a
size of 512 bytes and the file system size is 370262016 bytes (so
0x1611c000) that are 723168 blocks (so 0x000b08e0).
In the u-boot i do the following instructions:

nand erase.part rootfs
ubi part rootfs
ubi create rootfs
mmc dev 0
mmc read 1200 0x00182000  0x000b08e0
ubi write 1200 rootfs 0x1611c000
ubifsmount ubi0:rootfs

and this instruction results in the following errors:

UBIFS error (pid 0): ubifs_read_node: bad node type (0 but expected 6)
UBIFS error (pid 0): ubifs_read_node: bad node at LEB 0:0
UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume
'ubi0:rootfs' errno=-22!

ubifsmount - mount UBIFS volume

Usage:
ubifsmount 
   - mount 'volume-name' volume

the strange thing is that when i first program all new devices i use the
following instruction:

tftpboot prall

and prall is the compiled of a txt file which, when programming file system
use the same instructions, obviously except for

tftp 1200 rootfs.ubifs

instead of my mmc instructions, and

ubi write 1200 rootfs ${filesize}

but from what i understand the "filesize" variable is set from the tftp
instruction

Where do i fail?

Thanks

Enrico
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Ptest log

[Somshekar C Kadam]

Hi All,
I am newbie to the ptest.
I have run ptest on ARM and Intel target board.
Now I want to have the output format as given in link below
https://wiki.yoctoproject.org/wiki/Ptest_f49ee61422c867516db252054e993df29f775136




I use the parser to generate wiki page output provided in qa tools, next I
need to copy the content  to wiki page which I have no access to get the
same output format.

Please suggest what is that I need to do if I need to get the same output
format, as I see it contains excel/xml  format.

or if there is an other alternative method  to get list of PASS and FAIL
numbers of each package ptest results.



Thanks in advance


Regards
Somshekar C Kadam
9036660538
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Native curl and SSL CA certificates

[Alexander Kanavin]

On 05/09/2018 09:29 AM, Iván Castell wrote:
But I am not fetching nor installing packages over the network during 
image creation. I just build an image using local recipes (standard 
procedure). One of those local recipes sets up a remote repository for 
rpm packages (adding /etc/yum.repos.d/yocto-adv-rpm.repo to the final 
image). The purpose of that remote repository is using it to update rpm 
packages on target devices when they are running in production.


In fact, I don't understand why yocto needs to synchronize that cache 
for 'yocto-adv-rpm' repo during build time. It doesn't have any sense 
for me. But the fact is that when the ca-certificates.crt is properly 
installed, the build process ends fine. If that file is not properly 
installed, the build process fails with the error reported in my 
previous message.


During image creation dnf is run several times, and it picks up its own 
configuration from the target rootfs. It is definitely not recommended 
to change that configuration behind dnf's back via installed recipes.


The supported way to configure remote repositories is via PACKAGE_FEED_URIS:
https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-runtime-package-management

Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Native curl and SSL CA certificates

[Iván Castell]

Just to provide all the details, this is the bbappend I add to my custom
layer:

$ cat recipes-devtools/dnf/dnf_%.bbappend

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += " \
file://yocto-adv-rpm.repo \
"

do_install_append () {
install -d ${D}/etc/yum.repos.d
install -m 0600 ${WORKDIR}/yocto-adv-rpm.repo
${D}/etc/yum.repos.d/yocto-adv-rpm.repo
}

FILES_${PN} += "/etc/yum.repos.d"

The contets of yocto-adv-rpm.repo are in the previous message.


2018-05-09 8:29 GMT+02:00 Iván Castell :

> But I am not fetching nor installing packages over the network during
> image creation. I just build an image using local recipes (standard
> procedure). One of those local recipes sets up a remote repository for rpm
> packages (adding /etc/yum.repos.d/yocto-adv-rpm.repo to the final image).
> The purpose of that remote repository is using it to update rpm packages on
> target devices when they are running in production.
>
> In fact, I don't understand why yocto needs to synchronize that cache for
> 'yocto-adv-rpm' repo during build time. It doesn't have any sense for me.
> But the fact is that when the ca-certificates.crt is properly installed,
> the build process ends fine. If that file is not properly installed, the
> build process fails with the error reported in my previous message.
>
>
> 2018-05-08 21:15 GMT+02:00 Alexander Kanavin  intel.com>:
>
>> On 05/08/2018 05:55 PM, Iván Castell wrote:
>>
>>> Is this a bug related with curl or ca-certificates recipe? What should
>>> be the right way to fix it?
>>>
>>
>> Fetching and installing packages over the network during image creation
>> is not supported or tested in YP. You need to build them locally, with
>> recipes.
>>
>>
>> Alex
>>
>
>
>
>


-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: i...@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
has adopted the necessary measures to ensure the confidential treatment of
personal information. We also inform you that you can exercise your access,
rectification, cancellation and opposition rights by send us a mail to:
i...@nayarsystems.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Native curl and SSL CA certificates

[Iván Castell]

But I am not fetching nor installing packages over the network during image
creation. I just build an image using local recipes (standard procedure).
One of those local recipes sets up a remote repository for rpm packages
(adding /etc/yum.repos.d/yocto-adv-rpm.repo to the final image). The
purpose of that remote repository is using it to update rpm packages on
target devices when they are running in production.

In fact, I don't understand why yocto needs to synchronize that cache for
'yocto-adv-rpm' repo during build time. It doesn't have any sense for me.
But the fact is that when the ca-certificates.crt is properly installed,
the build process ends fine. If that file is not properly installed, the
build process fails with the error reported in my previous message.


2018-05-08 21:15 GMT+02:00 Alexander Kanavin <
alexander.kana...@linux.intel.com>:

> On 05/08/2018 05:55 PM, Iván Castell wrote:
>
>> Is this a bug related with curl or ca-certificates recipe? What should be
>> the right way to fix it?
>>
>
> Fetching and installing packages over the network during image creation is
> not supported or tested in YP. You need to build them locally, with recipes.
>
>
> Alex
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto