Re: [yocto] QA cycle report for 2.6 M4 RC1

[akuster808]

On 11/9/18 1:24 AM, Jain, Sangeeta wrote:
>
>  
>
> Hello All,
>
>  
>
Thank you to the Intel and Wind QA teams for performing these tasks.


Will the Build appliance failure keep it from functioning ?


- armin


> This is the full report for 2.6 M4 RC1: 
>
> https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1
>
>  
>
>  
>
> *Summary*
>
>  
>
> All planned tests were executed.
>
>  
>
> Total Test Executed – 3339
>
> Passed Test – 3322
>
> Failed Test – 7
>
> Blocked Test - 4
>
>  
>
> There were zero high priority defect.  Team had found 4 new defects.
> ptest for 1modulefailed in current release but passed in previous 2.6
> M3 rc1.  For Openssl no test was executed in current release as well
> as previous release. Present status of bugs for respective modules is
> as  follows:
>  
> ModuleName  –  BugId  –  Present Status
>  
> gstreamer   – 12990     - New
>  
> Note: For busybox, pass rate is lower than previous release, but no
> test cases which passes in previous release failed in current release.
> Lower pass rate is due to new test cases added in this release. No bug
> filed.
>
>  
>
> *Performance test*
>
>  
>
>  rootfs performance on ubuntu1604 upgraded by  13.04% in 2.6 M3 RC1
> w.r.t. 2.6 M2 RC1
>
>  
>
> *QA-Hints *
>
> * *
>
> For performance test, in this release, QA team has performed analysis
> on results from “yocto-perf” mailing list, rather than on results from
> Linux foundation machines.
>
> Weobserved two major difference between machines used to run
> Performance test by “yocto-perf” mailing list and Linux Foundation
> machines:
>
>  
>
> 1) Mailing List data points was not constant, sometime more, sometime less
>
> 2) Mailing List used machine with different spec
>
> * *
>
> *New Bugs*
>
> * *
>
> [1] Bug 12974 -  [2.6 M4 RC1] [OE-Core] Crosstap doesn't work on 2.6
> M4 RC1
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12974
>
>  
>
>  [2] Bug 129
> 79 - [2.6 M4
> rc1] test_recipetool_create_cmake failed on Fedora 27
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12979
>
> * *
>
> [3] Bug 129
> 91 - [2.6 M4
> RC1][Build-Appliance] Bitbake build-appliance-image getting failed
> during building image due to webkitgtk package
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991
>
>  
>
> [4] Bug 129
> 92 - [2.6 M4
> rc1] test_devtool_add_fetch_git failed on Fedora 27
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12992
>
>  
>
> Thanks & Regards,
>
> Sangeeta Jain
>
>  
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issue using UEFI with rootfs(squashfs) generated as a wic

[Mathieu Alexandre-Tétreault]

Hello,


The platform is running on a i7 CPU and is using UEFI to load the kernel. The 
image that we are currently building is loading

out of a USB stick wish was working until I switched the rootfs type to 
squashfs.


Systemd-boot is as the boot loader.


So far what I noticed is the boot.conf use the options LABEL=boot but the 
kernel is unable to read a LABEL from the squashfs.


On the other hand I tried to adding "root=/dev/sdb2 rootfstype=squashfs" to the 
boot.conf using a systemd-bootconf_%.bbappend

Using the define ROOT, APPEND_append gave me no result, I always end up with 
options LABEL=boot  rootwait console=tty0


I also tried  overridding build_efi_cfg() from 
meta/classes/systemd-boot-cfg.bbclass from my systemd-bootconf_%.bbappend and 
copy my files, but it always

get over-written some how.


Any advise would be greatly appreciated on how to modify the boot.conf file to 
allow loading a squashfs.


Cheers,


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

Re: [yocto] [RFC] Yocto Autobuilder and LAVA Integration

[Anibal Limon]

On Thu, 8 Nov 2018 at 20:49, Chan, Aaron Chun Yew <
aaron.chun.yew.c...@intel.com> wrote:

> Hi Anibal/RP,
>
> > In order to do a distributed Boards testing the Yocto Autobuilder
> > needs to publish in some place accessible the artifacts (image,
> > kernel, etc) to flash/boot the board and the test suite expected to
> > execute.
>
> [Reply] That is correct, since Linaro have this in place to use
> https://archive.validation.linaro.org/directories/ and I have look into
> this as well, we can leverage on this
>   but I am up for any suggestion you might have. So the idea
> here is that we have a placeholder to store the publish artifacts remotely
> and deploy using
>   native curl command with token access. Then based on your
> LAVA job definitions we can instruct LAVA to source the images via https.
>   Having said that, the deploy stage in LAVA must have some
> capabilities to read a token file in the LAVA job defintion and pick up the
> binaries from public repo (git LFS).
>
>   In order for Board Distributed Tests to happen, there are 2
> items in my wish lists
>
>   1. Public hosting of binary repository - with access control
>

For publish the artifacts (Rootfs, Kernel image, Test suite), if there is a
public build a token isn't needed like targeting some boards already
commercialized and can be published anywhere like in
http://downloads.yoctoproject.org.


>   2. Ease Handshaking between two(2) different systems CI
> (e.g. Jenkins/Autobuilder) with LAVA
>a. Exchange build property (metadata) - includes
> hardware info, system info
>

You can add meta-data to a LAVA test definition.

   b. Test reporting results
>

For notify job results LAVA test definition support the notify block in
test jobs or you can poll the API using for both needs a LAVA token.



>
> > I created a simple LAVA test definition that allows run testimage
> > (oe-test runtime) in my own LAVA LAB, is very simplistic only has a
> > regex to parse results and uses lava-target-ip and lava-echo-ipv4 to
> > get target and server IP addresses.
>
> [Reply] Although the lava test shell have these capabilities to use
> lava-target-ip or/and lava-echo-ipv4 this only works within LAVA scope, the
> way we retrieve the Ipv4
>   address is reading the logs from LAVA thru XML-RPC and grep
> the pattern matching string which contains IP even before the HW get
> initialize entirely then parse
>   IP back to the Yocto Autobuilder.
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/lava/trigger-lava-jobs


Yes, that's my idea the Yocto Autobuilder dosen't need to know about
particular network configuration in tha LAVA server for execute the job, in
this way the Yocto Autobuilder can communicate with LAVA server to retrieve
the testing job results, and in a case that needs to debug the board LAVA
support hacking sessions to allow connect to the board outside the LAB.

https://validation.linaro.org/static/docs/v2/hacking-session.html


>
>
> > Some of the tasks, I identified,  (if is accepted)
> >
> > - Yocto-aubuilder-helper: Implement/adapt to cover this new behavior ,
> > move the EXTRA_PLAIN_CMDS to a class.
> > - Poky/OE: Review/fix test-export or provide other mechanism to export
> > the test suite. > - Poky/OE: Review/fix test-export or provide other
> mechanism to export
> > the test suite.
>
> [Reply] I would like to understand further what is the implementation here
> and how it addresses the problems that we have today. I believe in the
> past, Tim has tried
>   to enable testexport and transfer the testexport into the
> DUT but it was not very successful and we found breakage.
>

Agree, The testexport functionality is on not usage so there are some bugs
on it.


>
> > -  Yocto-aubuilder-helper: Create a better approach to re-use LAVA job
> > templates across boards.
>
> [Reply] I couldn’t be more supportive on this having a common LAVA job
> template across boards but I would like to stress this, we don’t exactly
> know how
>   community will define their own LAVA job definition,
> therefore what I had in mind as per today is to create a placeholde where
> LAVA job templates
>   can be define and other boards/community can reuse the same
> template if it fits their use cases. In general the templates we have today
> are
>   created to fit into Yocto Project use cases.
>

Agree, I not mean a single template but a manner to add easily new LAVA
templates for boards in Yocto Autobuilder, this involves some base LAVA job
templates and a set of scripts to
generate the final template, like you are doing. For example there are
different ways to deploy a board but the login process is the same for
core-image's (login as root wo passwd).

Cheers,
Anibal


>
> Lastly  there are some works I've done on provisiong QEMU on LAVA
> sourceing from 

Re: [yocto] non-existent task do_package_write_ipk

[Donal Morrissey]

Hi Ross,
I had to use IMAGE_PREPROCESS_COMMAND in my own image recipe, the execution
order of the ROOTFS_POSTPROCESS_COMMAND commands didn't work for me.
Thanks for your help.
Donal

On Fri, 9 Nov 2018 at 14:53, Burton, Ross  wrote:

> On Fri, 9 Nov 2018 at 14:48, Donal Morrissey 
> wrote:
> > Thank you for your help. My build is using a layer which is generating a
> file in a ROOTFS_POSTPROCESS_COMMAND command. I would like to modify this
> file as part of the yocto build, but I'd prefer not to modify/fork this
> layer as it is from a vender.
> >
> > I'm creating my own layer, which will modify the file created in the
> vender layer's ROOTFS_POSTPROCESS_COMMAND command. If I use pkg_postinst,
> then the file will not have been created when pkg_postinst is called,
> because (as far as i understand) the ROOTFS_POSTPROCESS_COMMAND commands
> will only be executed after all packages have been installed on the root
> filesystem image.
>
> You'll have to set your own ROOTFS_POSTPROCESS_COMMAND in your image
> recipe.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] so how does PACKAGECONFIG_remove really work?

[Aditya Tayade]

Thanks Ross.


Regards,

Aditya Tayade


From: Burton, Ross 
Sent: Friday, November 9, 2018 8:10:22 PM
To: Aditya Tayade
Cc: Yocto-mailing-list
Subject: Re: [yocto] so how does PACKAGECONFIG_remove really work?

On Fri, 9 Nov 2018 at 14:36, Aditya Tayade  wrote:
> Can any one please help me to understand PACKAGECONFIG_remove feature
>
>
> Let's take an example of systemd recipe as follows:
>
> PACKAGECONFIG ??= "vconsole"
>
> PACKAGECONFIG[vconsole] = 
> "-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"
>
>
> Now how should we disable features set in PACKAGECONFIG[vconsole] using 
> PACKAGECONFIG_remove from it's bbappend file?

The _remove override removes a value from a variable. So this will
remove 'vconsole' from the value of PACKAGECONFIG:

PACKAGECONFIG_remove = "vconsole"

Ross
This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] so how does PACKAGECONFIG_remove really work?

[Uwe Geuder]

On Fri, Nov 9, 2018 at 4:41 PM Burton, Ross ross.burton-at-intel.com  wrote:
>
> On Fri, 9 Nov 2018 at 14:36, Aditya Tayade  wrote:
> > Can any one please help me to understand PACKAGECONFIG_remove feature
> >
> >
> > Let's take an example of systemd recipe as follows:
> >
> > PACKAGECONFIG ??= "vconsole"
> >
> > PACKAGECONFIG[vconsole] = 
> > "-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"
> >
> >
> > Now how should we disable features set in PACKAGECONFIG[vconsole] using 
> > PACKAGECONFIG_remove from it's bbappend file?
>
> The _remove override removes a value from a variable. So this will
> remove 'vconsole' from the value of PACKAGECONFIG:
>
> PACKAGECONFIG_remove = "vconsole"
>

I also wondered quite a while in the past why such questions are not covered
by the Mega Manual.

https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html

Once I had been told that the mega manual contains "everything". As matter of
fact that is not true. Basic syntax for bitbake (recipes and conf files) is
documented only in a separate Bitbake User Manual.

https://www.yoctoproject.org/docs/2.5.1/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax

Regards,

Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] non-existent task do_package_write_ipk

[Burton, Ross]

On Fri, 9 Nov 2018 at 14:48, Donal Morrissey  wrote:
> Thank you for your help. My build is using a layer which is generating a file 
> in a ROOTFS_POSTPROCESS_COMMAND command. I would like to modify this file as 
> part of the yocto build, but I'd prefer not to modify/fork this layer as it 
> is from a vender.
>
> I'm creating my own layer, which will modify the file created in the vender 
> layer's ROOTFS_POSTPROCESS_COMMAND command. If I use pkg_postinst, then the 
> file will not have been created when pkg_postinst is called, because (as far 
> as i understand) the ROOTFS_POSTPROCESS_COMMAND commands will only be 
> executed after all packages have been installed on the root filesystem image.

You'll have to set your own ROOTFS_POSTPROCESS_COMMAND in your image recipe.

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

Re: [yocto] non-existent task do_package_write_ipk

[Donal Morrissey]

Hi Ross,
Thank you for your help. My build is using a layer which is generating a
file in a ROOTFS_POSTPROCESS_COMMAND command. I would like to modify this
file as part of the yocto build, but I'd prefer not to modify/fork this
layer as it is from a vender.

I'm creating my own layer, which will modify the file created in the vender
layer's ROOTFS_POSTPROCESS_COMMAND command. If I use pkg_postinst, then the
file will not have been created when pkg_postinst is called, because (as
far as i understand) the ROOTFS_POSTPROCESS_COMMAND commands will only be
executed after all packages have been installed on the root filesystem
image.

Any suggestions on how to proceed?

Regards,
Donal

On Fri, 9 Nov 2018 at 12:13, Burton, Ross  wrote:
>
> A recipe that ship files and generates packages can't also inherit
> core-image because it can't both be a package and an image.  If you
> want this package to run something when it is installed, write a
> post-install function (pkg_postinst).
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] core-image-weston w/ initramfs

[Outback Dingo]

so core-image-weston works fine with the touch screen, then we added
core-image-minimal initramfs so we could boot with encrypted
filesystem, however now it seems the touch screen has lost its touch
and pointed capabilities, ive determined that much by looking at the
logs for when weston fails, same occurs with x11 image

ideas where to look to re-enable this
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] so how does PACKAGECONFIG_remove really work?

[Burton, Ross]

On Fri, 9 Nov 2018 at 14:36, Aditya Tayade  wrote:
> Can any one please help me to understand PACKAGECONFIG_remove feature
>
>
> Let's take an example of systemd recipe as follows:
>
> PACKAGECONFIG ??= "vconsole"
>
> PACKAGECONFIG[vconsole] = 
> "-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"
>
>
> Now how should we disable features set in PACKAGECONFIG[vconsole] using 
> PACKAGECONFIG_remove from it's bbappend file?

The _remove override removes a value from a variable. So this will
remove 'vconsole' from the value of PACKAGECONFIG:

PACKAGECONFIG_remove = "vconsole"

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

Re: [yocto] so how does PACKAGECONFIG_remove really work?

[Aditya Tayade]

Hi,


Can any one please help me to understand PACKAGECONFIG_remove feature


Let's take an example of systemd recipe as follows:

PACKAGECONFIG ??= "vconsole"

PACKAGECONFIG[vconsole] = 
"-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"


Now how should we disable features set in PACKAGECONFIG[vconsole] using 
PACKAGECONFIG_remove from it's bbappend file?


Regards,

Aditya Tayade



From: Aditya Tayade
Sent: Friday, November 9, 2018 7:48:36 PM
To: Yocto discussion list
Subject: [yocto] so how does PACKAGECONFIG_remove really work?


Hi,


Can any one please help me to understand PACKAGECONFIG_remove feature


Let's take an example of systemd recipe as follows:

PACKAGECONFIG ??= "vconsole"

PACKAGECONFIG[vconsole] = 
"-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"


Now how should we disable features set in PACKAGECONFIG using 
PACKAGECONFIG_remove from it's bbappend file?


Regards,

Aditya Tayade

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Set linux capabilities on binary on a recipe in meta-oe layer

[Uwe Geuder]

Hi!


On Fri, Nov 9, 2018 at 12:16 PM Markus W markus4dev-at-gmail.com wrote:

> On Thu, 8 Nov 2018 at 22:53, Piotr Tworek  wrote:
...
>> pkg_postinst_ontarget_${PN} () {
>>setcap cap_net_raw+eip $D${bindir}/node
>> }
...
> How can this be achieved when the rootfs is created and not on first
> boot? I would like not to ship libcap binaries with the target in
> production.

Ideally I would do it "locally" in do_install of the node recipe (you can
append extra statements to the task in your own .bbappend in your own
layer, don't edit existing recipes)

That of course requires that the package manager preserves the
capabilites. I have no experience which package manager would do
or not do that.

"Globally" you can do it by appending a new function to 
ROOTFS_POSTPROCESS_COMMAND

https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html#var-
ROOTFS_POSTPROCESS_COMMAND

This is done in your image recipe.

Regards,

Uwe Geuder
Neuro Event Labs Oy
Tampere, Finland
uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] so how does PACKAGECONFIG_remove really work?

[Aditya Tayade]

Hi,


Can any one please help me to understand PACKAGECONFIG_remove feature


Let's take an example of systemd recipe as follows:

PACKAGECONFIG ??= "vconsole"

PACKAGECONFIG[vconsole] = 
"-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"


Now how should we disable features set in PACKAGECONFIG using 
PACKAGECONFIG_remove from it's bbappend file?


Regards,

Aditya Tayade

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 2/2] intel-x86-64: Move 'CONFIG_NR_CPUS=256' to intel-x86-64.cfg

[Bruce Ashfield]

On 2018-11-08 8:45 p.m., Hongzhi, Song wrote:



On 11/09/2018 03:56 AM, Bruce Ashfield wrote:

On 2018-11-07 9:05 p.m., Hongzhi.Song wrote:

The maximum cpus are 64 on intel-x86-32.
But intel-x86-64 support ranges from 1 to 8192.
So we should move the config to intel-x86-64.cfg.


ok. This makes more sense, but two questions:

 - why limit to 256 on x86-64 ?


Hi Bruce,

The config file which contains '256' was transplanted from the 
historical branch.


I have consulted the committer, Yongxin Liu , 
who said:

for most x86-64 products, 256 was an usual value.
[add Yongxin in loop]



 - why not put 64 as the limit in intel-x86.cfg, since
   it now has no setting at all.


The default value is 64 on intel-x86-32.
So I doesn't explicitly set the config to 64 in intel-x86.cfg, but
set 256 explicitly in intel-x86-64.


I'd still rather have it explicitly set. We do sometimes rely
on defaults, but it is often better to have the fragments
be self-documenting and be independent of changing defaults
in the kernels.



By the way, intel-x86.cfg is shared by 32bit and 64bit.


Indeed. That would be a problem in setting the value to 64
explicitly in that fragment.

I'll merge this as-is, but I would rather have something that
explicitly sets the value for 32 bit .. something for a future
re-org of the fragments to take care of.

Bruce



--Hongzhi



Bruce



Signed-off-by: Hongzhi.Song 
---
  bsp/intel-x86/intel-x86-64.cfg | 3 +++
  bsp/intel-x86/intel-x86.cfg    | 1 -
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsp/intel-x86/intel-x86-64.cfg 
b/bsp/intel-x86/intel-x86-64.cfg

index 4e8a4d7..215c0f0 100644
--- a/bsp/intel-x86/intel-x86-64.cfg
+++ b/bsp/intel-x86/intel-x86-64.cfg
@@ -49,3 +49,6 @@ CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=m
    # Intel Resource Director Technology support
  CONFIG_INTEL_RDT=y
+
+# Processor type and features
+CONFIG_NR_CPUS=256
diff --git a/bsp/intel-x86/intel-x86.cfg b/bsp/intel-x86/intel-x86.cfg
index 6919179..080bca1 100644
--- a/bsp/intel-x86/intel-x86.cfg
+++ b/bsp/intel-x86/intel-x86.cfg
@@ -17,7 +17,6 @@
  CONFIG_MCORE2=y
  CONFIG_SMP=y
  CONFIG_SCHED_SMT=y
-CONFIG_NR_CPUS=256
    CONFIG_NUMA=y
  CONFIG_ACPI_NUMA=y








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

Re: [yocto] [patchtest-oe][PATCH] test_patch_cve.py: fix cve tag checking logic

[Michael Halstead]

When updating patchtest-oe to include the CVE fixes I also cleaned up
repositories in the share directory removing the patchwork credentials
in the process. I've restored the patchwork credentials and posted the
test results from local backups.

I've opened a bug to collect ideas for testing patchtest upgrades at
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13002.

On 11/8/18 11:38 PM, Mittal, Anuj wrote:
> On Wed, 2018-11-07 at 09:01 +, Richard Purdie wrote:
>> On Fri, 2018-11-02 at 14:03 +0800, Chen Qi wrote:
>>> The current logic for checking cve tag is not correct. It errors
>>> out if and only if the patch contains a line which begins with
>>> CVE-- and contains nothing else.
>>>
>>> It will not error out if the patch contains no CVE information, nor
>>> will it error out if the patch contains line like below.
>>>
>>> 'Fix CVE--'
>>>
>>> I can see that the cve tag checking logic tries to ensure the patch
>>> contains something like 'CVE: CVE--'. So fix to implement
>>> such
>>> logic.
>>>
>>> Signed-off-by: Chen Qi 
>>> ---
>>>  tests/test_patch_cve.py | 15 ---
>>>  1 file changed, 8 insertions(+), 7 deletions(-)
>> Thanks, good find.
>>
>> I've merged this and I believe the instance should have it applied
>> now
>> too.
>>
> Not sure if this is related but it looks like the tests aren't running
> at all now ...
>
>
> https://patchwork.openembedded.org/project/oe-core/series/?ordering=-last_updated
>
> Thanks,
>
> Anuj

-- 
Michael Halstead
Linux Foundation / SysAdmin

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

Re: [yocto] non-existent task do_package_write_ipk

[Burton, Ross]

A recipe that ship files and generates packages can't also inherit
core-image because it can't both be a package and an image.  If you
want this package to run something when it is installed, write a
post-install function (pkg_postinst).

Ross
On Fri, 9 Nov 2018 at 11:35, Donal Morrissey  wrote:
>
> Hi There,
> I'm not able to inherit core-image into my recipe, when I do, I get the 
> following error:
> ERROR: Task do_populate_sdk in 
> .../poky/meta/recipes-core/images/core-image-base.bb rdepends upon 
> non-existent task do_package_write_ipk in 
> /home/donal/Projects/farkas/source/meta-my-platform/recipes-tools/system-scripts/system-scripts.bb
> ERROR: Command execution failed: 1
>
> The reason I'm inheriting core-image, is so that I can append a command to 
> the ROOTFS_POSTPROCESS_COMMAND variable.
>
> The following are the contents of my bb file:
>
> SUMMARY = "Set of common platform tools."
> DESCRIPTION = "..."
> AUTHOR = "..."
> LICENSE = "CLOSED"
>
> inherit core-image
>
> my_post_process_cmd() {
> touch ${IMAGE_ROOTFS}/test
> }
> ROOTFS_POSTPROCESS_COMMAND += " my_post_process_cmd;"
>
> Any suggestions on how to fix this?
>
> Thank you,
> Donal
> --
> ___
> 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] Autoincing version every rebuild

[Burton, Ross]

Use the PR service, that's exactly what this is for.

Ross
On Fri, 9 Nov 2018 at 10:51, Mauro Ziliani  wrote:
>
> Hi all.
>
> I'd like increment version number (PV) o release number (PR) every time
> I built a recipe.
>
> I use this strategy in debug mode to give a reference to every debug
> session.
>
>
> In production it PV and PR value for the recipe will be fixed.
>
>
> Any idea?
>
>
> I'm working with fsl 4.1.15-2.0.1
>
>
> Best regards,
>
>   Mauro
>
> --
> ___
> 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] non-existent task do_package_write_ipk

[Donal Morrissey]

Hi There,
I'm not able to inherit core-image into my recipe, when I do, I get the
following error:
ERROR: Task do_populate_sdk in .../poky/meta/recipes-core/images/
core-image-base.bb rdepends upon non-existent task do_package_write_ipk in
/home/donal/Projects/farkas/source/meta-my-platform/recipes-tools/system-scripts/
system-scripts.bb
ERROR: Command execution failed: 1

The reason I'm inheriting core-image, is so that I can append a command to
the ROOTFS_POSTPROCESS_COMMAND variable.

The following are the contents of my bb file:

SUMMARY = "Set of common platform tools."
DESCRIPTION = "..."
AUTHOR = "..."
LICENSE = "CLOSED"

inherit core-image

my_post_process_cmd() {
touch ${IMAGE_ROOTFS}/test
}
ROOTFS_POSTPROCESS_COMMAND += " my_post_process_cmd;"

Any suggestions on how to fix this?

Thank you,
Donal
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder-helper][PATCH] config.json: Disable BUILDINFO for oe-selftest

[Michael Halstead]

Currently the containerimage.ContainerImageTests.test_expected_files test
doesn't expect a file at /etc/build so BUILDINFO must be false for the test to
pass.

Signed-off-by: Michael Halstead 
---
 config.json | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config.json b/config.json
index 6288e4b..8a694d7 100644
--- a/config.json
+++ b/config.json
@@ -158,6 +158,7 @@
 "BBTARGETS" : "core-image-minimal:do_populate_sdk_ext 
core-image-sato:do_populate_sdk"
 },
 "step6" : {
+"BUILDINFO" : false,
 "MACHINE" : "qemux86-64",
 "SDKMACHINE" : "x86_64",
 "PACKAGE_CLASSES" : "package_rpm",
-- 
2.17.2

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

[yocto] Autoincing version every rebuild

[Mauro Ziliani]

Hi all.

I'd like increment version number (PV) o release number (PR) every time
I built a recipe.

I use this strategy in debug mode to give a reference to every debug
session.


In production it PV and PR value for the recipe will be fixed.


Any idea?


I'm working with fsl 4.1.15-2.0.1


Best regards,

  Mauro

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

Re: [yocto] Set linux capabilities on binary on a recipe in meta-oe layer

[Markus W]

Thanks Piotr, that worked!

How can this be achieved when the rootfs is created and not on first boot?
I would like not to ship libcap binaries with the target in production.

/Markus

On Thu, 8 Nov 2018 at 22:53, Piotr Tworek  wrote:

> Hi Markus,
>
> Have you tried doing it in the postinst step executed on your target? Try:
>
> pkg_postinst_ontarget_${PN} () {
> setcap cap_net_raw+eip $D${bindir}/node
> }
>
> RDEPENDS_${PN} += "libcap-bin"
>
> /ptw
>
> > I have tested to set capabilities on the node binary within a custom
> recipe
> > (custom layer) but that failed.
> >
> > pkg_postinst_${PN} () {
> > setcap cap_net_raw+eip $D${bindir}/node
> > }
> > PACKAGE_WRITE_DEPS = "libcap-native"
> > RDEPENDS_${PN} = "libcap"
> >
> > The error message:
> >
> > ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check]
> > core-image-full-cmdline: found 1 error message in the logfile:
> > [log_check] Failed to set capabilities on file
> >
> `/home/ubuntu/yocto-sumo/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core
> > -image-full-cmdline/1.0-r0/rootfs/usr/bin/node' (No such file or
> directory)
> >
> > When I check the node binary is there in the rootfs directory. It seems
> > that when the the pkg_postinst function is executed the node binary is
> not
> > there.
> >
> > What am I missing? Any answer is much appreciated!
> >
> > Regards,
> > Markus
> >
> > On Wed, 7 Nov 2018 at 11:32, Markus W  wrote:
> > > Hi!
> > >
> > > Background:
> > > In my raspberry project I am developing a nodejs app that needs access
> to
> > > bluetooth/ble device. I want to run the node application as non root
> user
> > > for security reasons. In order to get access from within the app, the
> node
> > > binary need to have the following capability cap_net_raw+eip set. I am
> > > using the nodejs recipe from meta-oe and added it in my local.conf:
> > >
> > > IMAGE_INSTALL_append = " nodejs i2c-tools bluez5 kernel-image
> > > kernel-devicetree"
> > >
> > > Question:
> > > Where should I apply the following command? setcap cap_net_raw+eip
> > > /usr/bin/node
> > >
> > > What are my options? Can I create a recipe in a different package that
> > > will apply the above command on the meta-oe package for the nodejs
> recipe?
> > >
> > > I have been following this thread (
> > > https://lists.yoctoproject.org/pipermail/yocto/2016-June/030811.html),
> > > but the node binaries and my node-app are in different layers and
> > > packages.
> > >
> > > Any advice how to do this is much appreciated?
> > >
> > > Regards,
> > > Markus
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] ref-variables.xml: update manual page for update-rc.d

[changqing.li]

From: Changqing Li 

Currently, yocto doc refer link http://www.tin.org/bin/man.cgi?
section=8=update-rc.d. as man page of update-rc.d, but lastest
debian udpate-rc.d have big difference with ours, they need insserv
and all the initscripts support LSB comment header.

change to new link which is more similar to ours.

Signed-off-by: Changqing Li 
---
 documentation/ref-manual/ref-variables.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index 595f2db..fc7e087 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7116,7 +7116,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = 
"${INC_PR}.3"
 to the update-rc.d command.
 For more information on valid parameters, please see the
 update-rc.d manual page at
-.
+.
 
 
 
-- 
2.7.4

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

[yocto] [PATCH] update-rc.d: support enable/disable function

[changqing.li]

From: Changqing Li 

Add support of enable/disable function, so that user can keep
previous config after upgrade package

Signed-off-by: Changqing Li 
---
 update-rc.d | 70 +
 1 file changed, 70 insertions(+)

diff --git a/update-rc.d b/update-rc.d
index e07cf85..1ba97d3 100644
--- a/update-rc.d
+++ b/update-rc.d
@@ -27,6 +27,7 @@ usage()
 usage: update-rc.d [-n] [-f] [-r ]  remove
update-rc.d [-n] [-r ] [-s]  defaults [NN | sNN kNN]
update-rc.d [-n] [-r ] [-s]  start|stop NN runlvl 
[runlvl] [...] .
+   update-rc.d [-n] [-r ] [-s]  enable|disable [S|2|3|4|5]
-n: not really
-f: force
-v: verbose
@@ -101,6 +102,43 @@ makelinks()
done
 }
 
+renamelink()
+{
+   local oldstartstop newstartstop lev oldnn newnn
+   if [ "x$1" = "xS" ]; then
+   oldstartstop="K"
+   newstartstop="S"
+   else
+   oldstartstop="S"
+   newstartstop="K"
+   fi
+
+   lev=$2
+   if ls ${etcd}${lev}.d/${oldstartstop}*${bn} >/dev/null 2>&1; then
+   oldnn=`basename ${etcd}${lev}.d/${oldstartstop}*${bn}|cut -c2-3`
+   newnn=$[100-$oldnn]
+   [ $verbose -eq 1 ] && echo "rename 
${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} -> 
${etcd}${lev}.d/${newstartstop}${newnn}${bn}"
+   if [ $notreally -eq 0 ];then
+   mv ${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} 
${etcd}${lev}.d/${newstartstop}${newnn}${bn}
+   fi
+   if [ $dostart -eq 1 ] && [ $newstartstop = "S" ] && [ $lev = 
$RUNLEVEL ]; then
+   $fn start || true
+   fi
+   fi
+
+}
+
+renamelinks()
+{
+   if [ $# -eq 2 ]; then
+   renamelink $1 $2
+   else
+   for i in 2 3 4 5 S; do
+   renamelink $1 $i
+   done
+   fi
+}
+
 while [ $# -gt 0 ]; do
case $1 in
-n) notreally=1
@@ -221,6 +259,13 @@ case $1 in
;;
 
start | stop)
+   if [ $# -lt 4 ]
+   then
+   echo "Not enough arguments"
+   usage
+   exit 1
+   fi
+
while [ $# -gt 0 ]; do
if [ $1 = "start" ]; then
letter=S
@@ -251,6 +296,31 @@ case $1 in
makelinks
;;
 
+   enable | disable)
+   if [ $1 = "enable" ]; then
+   letter=S
+   elif [ $1 = "disable" ]; then
+   letter=K
+   else
+   usage
+   exit 1
+   fi
+   shift
+   if [ $# -gt 0 ]
+   then
+   case $1 in
+   S|2|3|4|5)
+   renamelinks $letter $1
+   ;;
+   *)
+   usage
+   exit 1
+   ;;
+   esac
+   else
+   renamelinks $letter
+   fi
+   ;;
*)
usage
exit 1
-- 
2.7.4

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

[yocto] QA cycle report for 2.6 M4 RC1

[Jain, Sangeeta]

Hello All,



This is the full report for 2.6 M4 RC1:

https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1





Summary



All planned tests were executed.



Total Test Executed - 3339

Passed Test - 3322

Failed Test - 7

Blocked Test - 4



There were zero high priority defect.  Team had found 4 new defects.

ptest for 1 module failed in current release but passed in previous 2.6 M3 rc1. 
 For Openssl no test was executed in current release as well as previous 
release. Present status of bugs for respective modules is as  follows:



ModuleName  -  BugId  -  Present Status



gstreamer- 12990 - New



Note: For busybox, pass rate is lower than previous release, but no test cases 
which passes in previous release failed in current release. Lower pass rate is 
due to new test cases added in this release. No bug filed.



Performance test



 rootfs performance on ubuntu1604 upgraded by  13.04% in 2.6 M3 RC1 w.r.t. 2.6 
M2 RC1



QA-Hints



For performance test, in this release, QA team has performed analysis on 
results from "yocto-perf" mailing list, rather than on results from Linux 
foundation machines.
We observed two major difference between machines used to run Performance test 
by "yocto-perf" mailing list and Linux Foundation machines:

1) Mailing List data points was not constant, sometime more, sometime less
2) Mailing List used machine with different spec



New Bugs



[1] Bug 12974 -  [2.6 M4 RC1] [OE-Core] Crosstap doesn't work on 2.6 M4 RC1

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12974



 [2] Bug 12979 - [2.6 
M4 rc1] test_recipetool_create_cmake failed on Fedora 27

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12979


[3] Bug 12991 - [2.6 
M4 RC1][Build-Appliance] Bitbake build-appliance-image getting failed during 
building image due to webkitgtk package
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991

[4] Bug 12992 - [2.6 
M4 rc1] test_devtool_add_fetch_git failed on Fedora 27
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12992

Thanks & Regards,
Sangeeta Jain

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