[yocto] Zeus Call for patches

[akuster808]

Hello,

We are planning on doing the first dot release for Zeus this coming
Monday. If you would like a get your changes into this Zeus update,
please have them on the list by this Friday for review.

regards,
Armin & Anuj
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project Status WW46'19

[akuster808]

Hello Stephen,

On 11/12/19 7:47 AM, sjolley.yp...@gmail.com wrote:
>
> Current Dev Position: YP 3.1 M1 
>
> Next Deadline: YP 3.1 M1 build Dec. 2, 2019
>
>  
>
> SWAT Team Rotation:
>
>   * SWAT lead is currently: Anuj 
>   * SWAT team rotation: Anuj -> Chen on Nov. 15, 2019
>   * SWAT team rotation: Chen > Paul on Nov. 22, 2019
>   * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>

I watch and triage stable branch builds I initiate week after week and I
no longer want to take on the responsibilities for the other builds. I
therefor am removing my name from the normal swat rotation and have
updated the wiki accordingly.  This should set the appropriate
expectations. This unfortunately puts the full burden back on Intel and
WindRiver.  If things should change in the future, I will let you know.

regards,
Armin

>  *
>
>  
>
> Next Team Meetings:
>
>   * Bug Triage meeting Thursday Nov. 14th at 7:30am PDT
> (https://zoom.us/j/454367603)
>   * Monthly Project Meeting Tuesday Dec. 3rd at 8am PDT
> (https://zoom.us/j/990892712) 
>   * Weekly Engineering Sync Tuesday Nov. 12th at 8am PDT
> (https://zoom.us/j/990892712) 
>   * Twitch - Next event is Tuesday Nov. 12th at 8am PDT
> (https://www.twitch.tv/yocto_project)
>
>  
>
> Key Status/Updates:
>
>   * YP 2.7.2 is still undergoing QA
>   * There were some key fixes for pseudo related issues which mean it
> continues to work with modern distros like Fedora 31.
>   * Patches have continued to merge and master is staying roughly
> current with the pending patch queue but there continue to be
> recurring build failures that are not being addressed.
>   * The YP TSC worked on and shared a proposal on how an LTS release
> could work which is available at:
> 
> https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sUkyc/
> . There has been much discussion about this, patience would be
> appreciated as the TSC and governing board work through this to
> come up with plans on how we proceed.
>   * We are continuing to collect ideas for YP 3.1 in this document:
> 
> https://docs.google.com/document/d/1UKZIGe88-eq3-pOPtkAvFAegbQDzhy_f4ye64yjnABc/edit?usp=sharing
>   * If anyone has any status items for the project they’d like to add
> to the weekly reports, please email Richard and Stephen.
>
>  
>
> Proposed YP 3.1 Milestone Dates:
>
>   * YP 3.1 M1 Proposed build date 12/2/2019
>   * YP 3.1 M1 Proposed release date 12/13/2019
>   * YP 3.1 M2 Proposed build date 1/20/2020
>   * YP 3.1 M2 Proposed release date 1/31/2020
>   * YP 3.1 M3 Proposed build date 2/24/2020
>   * YP 3.1 M3 Proposed release date 3/6/2020
>   * YP 3.1 M4 Proposed build date  3/30/2020
>   * YP 3.1 M4 Proposed release date  4/24/2020
>
>  
>
> Planned upcoming dot releases:
>
>   * YP 3.0.1 has patches being queued in poky-contrib
>   * YP 2.7.2 (Warrior) is in QA.
>
>  
>
> Tracking Metrics:
>
>   * WDD 2508 (last week
> 2518)(https://wiki.yoctoproject.org/charts/combo.html)
>   * Poky Patch Metrics  
>   o Total patches found: 1445 (last week 1446)
>   o Patches in the Pending State: 579 (40%) [last week 579 (40%)]
>
>  
>
> The Yocto Project’s technical governance is through its Technical
> Steering Committee, more information is available at:
>
> https://wiki.yoctoproject.org/wiki/TSC
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
> Thanks,
>
>  
>
> */Stephen K. Jolley/**//*
>
> *Yocto Project Project Manager*
>
> (    *Cell*:    (208) 244-4460
>
> * *Email*:  _sjolley.yp...@gmail.com
> _
>
>  
>
>

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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.2.rc1)

[akuster808]

On 11/13/19 6:09 PM, Jain, Sangeeta wrote:
> Hello All,
>
> Intel and WR YP QA is planning for QA execution for YP build yocto-2.7.2.rc1.
> We are planning to execute following tests for this cycle:
>
> OEQA-manual tests for following module:
> 1. OE-Core
> 2. BSP-hw
> 3. BSP-Qemu
>
> Runtime auto test for following platforms:
> 1. MinnowTurbot 32-bit
> 2. Coffee Lake
> 3. NUC 7
> 4. NUC 6
> 5. Edgerouter
> 6. MPC8315e-rdb
> 7. Beaglebone
>
> ETA for completion is Monday, November 18.
ok. sound good.

thanks,
Armin
>
> Thanks & Regards,
> Sangeeta Jain
>> -Original Message-
>> From: Pokybuild User 
>> Sent: Thursday, October 31, 2019 1:23 AM
>> To: yocto@yoctoproject.org
>> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
>> ; Yeoh, Ee Peng ; Chan,
>> Aaron Chun Yew ; Ang, Chin Huat
>> ; richard.pur...@linuxfoundation.org;
>> akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta
>> 
>> Subject: QA notification for completed autobuilder build (yocto-2.7.2.rc1)
>>
>>
>> A build flagged for QA (yocto-2.7.2.rc1) was completed on the autobuilder 
>> and is
>> available at:
>>
>>
>>https://autobuilder.yocto.io/pub/releases/yocto-2.7.2.rc1
>>
>>
>> Build hash information:
>>
>> bitbake: 75d6648f232a06b99c54a1e33324a7fc1cd15b38
>> meta-gplv2: d5d9fc9a4bbd365d6cd6fe4d6a8558f7115c17da
>> meta-intel: ca26bed652722167b2dbe0042cfc2406029e9c6c
>> meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4
>> oecore: 726c3b92298981f5aa2f2449ceeec7b4bf84ed29
>> poky: d0f73121551dc98f6924cd77952bf9ebf5ef3dd7
>>
>>
>>
>> This is an automated message from the Yocto Project Autobuilder
>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>> Email: richard.pur...@linuxfoundation.org
>>
>>
>>

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

Re: [yocto] [OE-core] Yocto Project Status WW44’19

[akuster808]

On 10/29/19 5:12 PM, Stephen K Jolley wrote:
>
> Current Dev Position: YP 3.1 M1 
>
> Next Deadline: YP 3.1 M1 build Dec. 2, 2019
>

I noticed there is no 3.0.1 schedule.  Can we try for early December?

>
> SWAT Team Rotation:
>
>  *
>
> SWAT lead is currently: Amanda
>
>  *
>
> SWAT team rotation: Amanda -> Armin on Nov. 1, 2019
>
I will be on vacation next week so there may be delays in checking the
builds. But thats no worse than what I normally do.
No need to reschedule.

>  *
>
> SWAT team rotation: Armin-> Anuj on Nov. 8, 2019
>
>  *
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>

We could use more volunteers to help monitory builds.

>
> Next Team Meetings:
>
>  *
>
> Bug Triage meeting Thursday Nov. 7th at 7:30am PDT
> (https://zoom.us/j/454367603)
>
>  *
>
> Monthly Project Meeting Tuesday Nov. 5th at 8am PDT
> (https://zoom.us/j/990892712) 
>
>  *
>
> Weekly Engineering Sync Tuesday Nov. 12th at 8am PDT
> (https://zoom.us/j/990892712) 
>
>  *
>
> Twitch - Next event is Tuesday Nov. 12th at 8am PDT
> (https://www.twitch.tv/yocto_project)
>
>
> Key Status/Updates:
>
>  *
>
> Yocto Project “Zeus” 3.0 has been released!  Thank you to everyone
> who contributed patches, bugs, feedback and testing.  Some very
> rough git metrics say that 182 different people have contributed
> patches to this cycle.
>
>  *
>
> This week is ELC-E in Lyon, so meetings are limited.  If anyone
> reading this is there please do visit the Yocto Project booth and
> say hello!
>
>  *
>
> Patches have been flowing fast into master.  Due to ELC-E this
> will slow down this week, but Ross will continue to collect
> patches for testing in ross/mut.
>
>  *
>
> There are ongoing intermittent autobuilder failures, particularly
> in selftest but in other areas too. There is a separate email
> about this and we could do with help in debugging and resolving
> those issues.
>
>  *
>
> YP 2.6.4 was built and has passed QA, will be released imminently.
>
>  *
>
> YP 2.7.2 was held due to an unexplained test failure but will now
> be built in the next few days.
>
>  *
>
> Armin and Anuj have volunteered to maintain Zeus and they plan to
> work out the maintainership between them, thanks!
>

I have updated the wiki to reflect that.

I also added in 3.1 and 3.2

Any notion of a code name?

>  *
>
> We have begun collecting ideas for YP 3.1 in this document:
> 
> https://docs.google.com/document/d/1UKZIGe88-eq3-pOPtkAvFAegbQDzhy_f4ye64yjnABc/edit?usp=sharing
>
>  *
>
> If anyone has any status items for the project they’d like to add
> to the weekly reports, please email Richard and Stephen.
>

When are we planning on adding Centos 8?

>
> Planned upcoming dot releases:
>
>  *
>
> YP 2.7.2 (Warrior) is planned this week.
>
>  *
>
> YP 2.6.4 (Thud) is is to be released shortly.
>

This may be the last Thud update and I have patches still being queued.
Not sure when it will shift to community support.


I have stated marking older builds as "EOL" on the release page.


>
> Tracking Metrics:
>
>  *
>
> WDD 2493 (last week
> 2498)(https://wiki.yoctoproject.org/charts/combo.html)
>
>  *
>
> Poky Patch Metrics  
>
>  o
>
> Total patches found: 1441 (last week 1432)
>
>  o
>
> Patches in the Pending State: 579 (40%) [last week 578 (41%)]
>
>
> The Yocto Project’s technical governance is through its Technical
> Steering Committee, more information is available at:
>
> https://wiki.yoctoproject.org/wiki/TSC
>
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>

Do we want a separate stable report or include in this ?

-armin
>
> -- 
>
> Thanks,
>
>  
>
> */Stephen K. Jolley/*
>
> *Yocto Project Program Manager*
>
> *7867 SW Bayberry Dr., Beaverton, OR 97007*
>
> (*Cell*:    (208) 244-4460
>
> * *Email*: _s
> jolley.yp...@gmail.com
> _
>
>

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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.4.rc2)

[akuster808]

Jain,

Thanks for the report.


On 10/23/19 1:00 AM, Jain, Sangeeta wrote:
> Hello all,
>
> This is the full report for 2.6.4 RC2:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
>
> === Summary 
> No high milestone defects.  
> No new defect found in this cycle.
> The stap test case failure on beaglebone still exists in this release (BUG 
> id:13273). 
>
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273

The fix for this is sitting in patchworks

https://patchwork.openembedded.org/patch/165649/

When I told Richard Thud was a go, I complete forgot about that change
not being merged.

- armin
>
> Thanks & Regards,
> Sangeeta Jain
>
>> -Original Message-
>> From: Poky Build User 
>> Sent: Friday, October 18, 2019 5:18 AM
>> To: yocto@yoctoproject.org
>> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
>> ; Yeoh, Ee Peng ; Chan,
>> Aaron Chun Yew ; Ang, Chin Huat
>> ; richard.pur...@linuxfoundation.org;
>> akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta
>> 
>> Subject: QA notification for completed autobuilder build (yocto-2.6.4.rc2)
>>
>>
>> A build flagged for QA (yocto-2.6.4.rc2) was completed on the autobuilder 
>> and is
>> available at:
>>
>>
>>https://autobuilder.yocto.io/pub/releases/yocto-2.6.4.rc2
>>
>>
>> Build hash information:
>>
>> bitbake: 6b045e074c6fea97d4e305a5a3c8bf82135d95eb
>> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
>> meta-intel: c200851435f39acd2fe4abbf7a05fbf617833964
>> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5
>> oecore: cd7cf933b3235560ec71576d8f3836dff736a39f
>> poky: 51f6145f8f99a02df1dad937684f014b0172e72a
>>
>>
>>
>> This is an automated message from the Yocto Project Autobuilder
>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>> Email: richard.pur...@linuxfoundation.org
>>
>>
>>


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

Re: [yocto] [yocto-autobuilder-helper] Replaced hardcoded BASE_HOMEDIR directory

[akuster808]

On 10/18/19 9:55 AM, Marco wrote:
> Replaced hardcoded BASE_HOMEDIR directory.
> Please apologize the missing send-email on my machine.
Thanks Marco,

Would the be any need to add something to the README regarding the use
of this variable?

- armin
> --
> Marco
>

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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.4.rc2)

[akuster808]

On 10/17/19 7:01 PM, Jain, Sangeeta wrote:
>
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org  On
>> Behalf Of akuster
>> Sent: Friday, 18 October, 2019 6:53 AM
>> To: yocto@yoctoproject.org
>> Cc: akuster...@gmail.com; Chan, Aaron Chun Yew
>> ; ota...@ossystems.com.br
>> Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-
>> 2.6.4.rc2)
>>
>> Can we get 2.6.4-rc2 in a QA queue for the next dot release?
> Do you mean that we should wait for 2.7.2 before starting QA for 2.6.4-rc2?
Not to wait for 2.7.2, there is an outstanding issue needing resolution.

2.6.4 is a ready to go.

regards,
Armin
>> - armin
>>
> Thanks & Regards,
> Sangeeta Jain
>
>> On 10/17/19 2:17 PM, Poky Build User wrote:
>>> A build flagged for QA (yocto-2.6.4.rc2) was completed on the autobuilder 
>>> and
>> is available at:
>>>
>>> https://autobuilder.yocto.io/pub/releases/yocto-2.6.4.rc2
>>>
>>>
>>> Build hash information:
>>>
>>> bitbake: 6b045e074c6fea97d4e305a5a3c8bf82135d95eb
>>> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
>>> meta-intel: c200851435f39acd2fe4abbf7a05fbf617833964
>>> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5
>>> oecore: cd7cf933b3235560ec71576d8f3836dff736a39f
>>> poky: 51f6145f8f99a02df1dad937684f014b0172e72a
>>>
>>>
>>>
>>> This is an automated message from the Yocto Project Autobuilder
>>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>>> Email: richard.pur...@linuxfoundation.org
>>>
>>>
>>>
>> --
>> ___
>> 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] [thud][PATCH] linux-yocto/4.14: meta-yocto-bsp update to 143

[akuster808]

This appears to have been missed for this round.

maybe next time

- armin

On 10/9/19 8:09 AM, Armin Kuster wrote:
> Signed-off-by: Armin Kuster 
> ---
>  .../recipes-kernel/linux/linux-yocto_4.14.bbappend   | 20 
> ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend 
> b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
> index 426757e..5277798 100644
> --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
> +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
> @@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
>  KMACHINE_genericx86-64 ?= "common-pc-64"
>  KMACHINE_beaglebone-yocto ?= "beaglebone"
>  
> -SRCREV_machine_genericx86?= "5252513a39b4b3773debab1f77071d7c430ecb10"
> -SRCREV_machine_genericx86-64 ?= "5252513a39b4b3773debab1f77071d7c430ecb10"
> -SRCREV_machine_edgerouter ?= "d8fb40cd0e99325715c70aed6f361a8318097829"
> -SRCREV_machine_beaglebone-yocto ?= "c67809688bd22cb4cb909bcf1a1045e6337c3229"
> -SRCREV_machine_mpc8315e-rdb ?= "258ee8228e0a512c6dbe2a0dadcd9f030ba45964"
> +SRCREV_machine_genericx86?= "bc9d4b045fa0254d14ef3a667a200f02cb9af755"
> +SRCREV_machine_genericx86-64 ?= "bc9d4b045fa0254d14ef3a667a200f02cb9af755"
> +SRCREV_machine_edgerouter ?= "326e296f237347e965a38acb34f09e594430b0c6"
> +SRCREV_machine_beaglebone-yocto ?= "1b8c86329c9dbb10b8fcaeb2dceb75680994cd84"
> +SRCREV_machine_mpc8315e-rdb ?= "f26672ec1f164b0f2a15d629128a91093f971bdd"
>  
>  COMPATIBLE_MACHINE_genericx86 = "genericx86"
>  COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
> @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
>  COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
>  COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>  
> -LINUX_VERSION_genericx86 = "4.14.98"
> -LINUX_VERSION_genericx86-64 = "4.14.98"
> -LINUX_VERSION_edgerouter = "4.14.98"
> -LINUX_VERSION_beaglebone-yocto = "4.14.98"
> -LINUX_VERSION_mpc8315e-rdb = "4.14.98"
> +LINUX_VERSION_genericx86 = "4.14.143"
> +LINUX_VERSION_genericx86-64 = "4.14.143"
> +LINUX_VERSION_edgerouter = "4.14.143"
> +LINUX_VERSION_beaglebone-yocto = "4.14.143"
> +LINUX_VERSION_mpc8315e-rdb = "4.14.143"

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

Re: [yocto] [meta-security][PATCH 1/2] apparmor: add PRIVATE_LIBS for ptest package

[akuster808]

merged
On 10/10/19 4:22 AM, Alexander Kanavin wrote:
> Otherwise, the following occurs:
> ERROR: apparmor-2.13.3-r0 do_package: apparmor: Multiple shlib providers for 
> libapparmor.so.1: apparmor, apparmor-ptest (used by files: 
> /home/alexander/development/poky/build-metaoe/tmp/work/core2-32-poky-linux/apparmor/2.13.3-r0/packages-split/apparmor/usr/lib/perl5/vendor_perl/5.30.0/i686-linux/auto/LibAppArmor/LibAppArmor.so)
> ERROR: apparmor-2.13.3-r0 do_package: apparmor: Multiple shlib providers for 
> libapparmor.so.1: apparmor, apparmor-ptest (used by files: 
> /home/alexander/development/poky/build-metaoe/tmp/work/core2-32-poky-linux/apparmor/2.13.3-r0/packages-split/apparmor/usr/lib/python3.7/site-packages/LibAppArmor/_LibAppArmor.cpython-37m-i686-linux-gnu.so)
>
> Signed-off-by: Alexander Kanavin 
> ---
>  recipes-mac/AppArmor/apparmor_2.13.3.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/recipes-mac/AppArmor/apparmor_2.13.3.bb 
> b/recipes-mac/AppArmor/apparmor_2.13.3.bb
> index 2e5d221..990d870 100644
> --- a/recipes-mac/AppArmor/apparmor_2.13.3.bb
> +++ b/recipes-mac/AppArmor/apparmor_2.13.3.bb
> @@ -165,3 +165,5 @@ RDEPENDS_${PN} += "bash"
>  RDEPENDS_${PN} += 
> "${@bb.utils.contains('PACKAGECONFIG','python','python3-core 
> python3-modules','', d)}"
>  RDEPENDS_${PN}_remove += 
> "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
>  RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib bash"
> +
> +PRIVATE_LIBS_${PN}-ptest = "libapparmor.so*"

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

Re: [yocto] [warrior 0/3] Pull request

[akuster808]

ping

On 10/6/19 8:40 AM, Armin Kuster wrote:
> Please merge these changes to meta-yocto warrior
>
> The following changes since commit c16082ffa61f485e120670fbdf075f3fa8597494:
>
>   poky.conf: Bump version for 2.7.1 warrior release (2019-06-30 22:41:39 
> +0100)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib meta-yocto/stable/warrior-next
>   
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=meta-yocto/stable/warrior-next
>
> Kevin Hao (1):
>   meta-yocto-bsp: Bump to the latest stable kernel for all the BSP
>
> Ross Burton (2):
>   conf/poky: add debian-10 to the supported distribution list
>   conf/poky: add Fedora 30 and Opensuse Leap 15.1 to supported
> distributions
>
>  meta-poky/conf/distro/poky.conf  |  3 +++
>  .../recipes-kernel/linux/linux-yocto_4.19.bbappend   | 20 
> ++--
>  .../recipes-kernel/linux/linux-yocto_5.0.bbappend| 20 
> ++--
>  3 files changed, 23 insertions(+), 20 deletions(-)
>

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

Re: [yocto] [meta-security][PATCH] layer.conf: Update for zeus series

[akuster808]

On 10/11/19 12:51 AM, Martin Jansa wrote:
> Acked-by: Martin Jansa  >
>
> Please merge this to unblock CI.

done

>
> On Wed, Oct 9, 2019 at 12:55 AM Armin Kuster  > wrote:
>
> Signed-off-by: Armin Kuster  >
> ---
>  conf/layer.conf                          | 2 +-
>  meta-integrity/conf/layer.conf           | 2 +-
>  meta-security-compliance/conf/layer.conf | 2 +-
>  meta-tpm/conf/layer.conf                 | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index b9a4f25..3e890e1 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -9,6 +9,6 @@ BBFILE_COLLECTIONS += "security"
>  BBFILE_PATTERN_security = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_security = "8"
>
> -LAYERSERIES_COMPAT_security = "warrior"
> +LAYERSERIES_COMPAT_security = "zeus"
>
>  LAYERDEPENDS_security = "core openembedded-layer perl-layer
> networking-layer meta-python"
> diff --git a/meta-integrity/conf/layer.conf
> b/meta-integrity/conf/layer.conf
> index 41989da..962424c 100644
> --- a/meta-integrity/conf/layer.conf
> +++ b/meta-integrity/conf/layer.conf
> @@ -21,6 +21,6 @@ INTEGRITY_BASE := '${LAYERDIR}'
>  # interactive shell is enough.
>  OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"
>
> -LAYERSERIES_COMPAT_integrity = "warrior"
> +LAYERSERIES_COMPAT_integrity = "zeus"
>  # ima-evm-utils depends on keyutils from meta-oe
>  LAYERDEPENDS_integrity = "core openembedded-layer"
> diff --git a/meta-security-compliance/conf/layer.conf
> b/meta-security-compliance/conf/layer.conf
> index 9ccadab..0e93bd0 100644
> --- a/meta-security-compliance/conf/layer.conf
> +++ b/meta-security-compliance/conf/layer.conf
> @@ -8,6 +8,6 @@ BBFILE_COLLECTIONS += "scanners-layer"
>  BBFILE_PATTERN_scanners-layer = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_scanners-layer = "10"
>
> -LAYERSERIES_COMPAT_scanners-layer = "warrior"
> +LAYERSERIES_COMPAT_scanners-layer = "zeus"
>
>  LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"
> diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
> index cdccc55..3af2d95 100644
> --- a/meta-tpm/conf/layer.conf
> +++ b/meta-tpm/conf/layer.conf
> @@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "tpm-layer"
>  BBFILE_PATTERN_tpm-layer = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_tpm-layer = "10"
>
> -LAYERSERIES_COMPAT_tpm-layer = "warrior"
> +LAYERSERIES_COMPAT_tpm-layer = "zeus"
>
>  LAYERDEPENDS_tpm-layer = " \
>      core \
> -- 
> 2.17.1
>
> -- 
> ___
> 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] Patchwork and stable branches

[akuster808]

My apologies for cross posting.

I have noticed some behavior I was not expecting with OE's Patchwork in
that it is hiding patches.  I don't know if this is by design or a bug
in our Patchwork.

When a series of patches are submitted to the mailing list and are same
fix but against different branches, all but the last  patch entered are
automatically marked as "suspended"  and then hidden from the default
view.  I never noticed this before and is now adding a new dimension to
the Stable branch maintenance process that I need to work around.  I am
catching these issues as I compare my in box to patchwork.


regards,
Armin

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

Re: [yocto] [OE-core] 3.0 release notes / migration guide

[akuster808]

Paul,

On 10/2/19 3:20 PM, Paul Eggleton wrote:
> Hi folks
>
> So it's that time again - we need to start building up the raw material for 
> the release notes and migration guide for the upcoming 3.0 release, and I'd 
> like to request some help with some parts of it - read on for details.
>
> For the migration guide we have a wiki page serving as a staging area:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide

Thanks for putting this together.

>
> Things that should go in the migration guide: *anything* in the release that 
> would require someone who is upgrading to take some form of action (i.e. 
> change their configuration / recipes / etc.) Help with this from people who 
> implemented the changes or have already thought about / dealt with their 
> impact would be much appreciated.
>
> There is a process where I look through all the commits since the last 
> release 
> and pull out the ones that need to be mentioned in some form - other than the 
> migration guide items, the following needs to be gathered for the release 
> notes:
>
> 1) Features - new functionality. We need to capture what the feature is and 
> hopefully express the impact to the user succinctly.
We remove LSB support.

> 2) Recipe upgrades - straightforward
>
> 3) CVE fixes - fairly straightforward, I just look for commits that 
> explicitly 
> mention "CVE". If I can easily do so I'll also note where a recipe upgrade 
> fixes a CVE, but that isn't often readily available information.
So how can the community help in this case? Better commit messages?

>
> 4) Known issues - generally this is difficult to get from the commits since 
> we 
> either find out about them after the commit that introduced the issue, or we 
> don't know that they aren't addressed until right at the end of the release. 
> We don't want to note *all* open bugs, but if there's something that the user 
> is likely to hit that wasn't an issue in the previous release then we should 
> note it.

Well, aren't open defects not fixed by the time we release time but we
intend on fixing after release a form of known issues ?

- armin


> For the release notes I need help with #4 and #1 in particular, so if you 
> know 
> about anything in this release that falls into these categories then let me 
> know - just a pointer to the commit and any extra comments that you would 
> want 
> to make would be helpful. In the mean time I will start the process of 
> looking 
> through the commits and will add things to the migration guide page, but bear 
> in mind I don't always have all of the context for every change.
>
> Thanks!
> Paul
>


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

Re: [yocto] QA cycle report for 2.8 M3 RC1

[akuster808]

On 9/25/19 11:33 PM, Jain, Sangeeta wrote:
>
>  
>
> Hello All,
>
>  
>
> This is the full QA report for 2.8 M3 RC1: 
>
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
>
>  
>
> === Summary 
>
> No high milestone defects. 
>
> Two new defects are found in this cycle, mpc8315e-rdb System randomly
> hang when running commands (BUG id:13555)
>
> Due to this issue, oeqa would be timeout and many tests are
> skipped/failed on mpc8315e-rdb.
>
> and ptest failed (BUG id:13556).
>
>  
>

Thank you for the summary.

> === Bugs 
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13555
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13556
>
We split the pongo issue into its own bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13557

- armin
>
>  
>
> Thanks & Regards,
>
> Sangeeta Jain
>
>  
>

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

Re: [yocto] [meta-security][PATCH] ncrack: update to tip

[akuster808]

On 9/15/19 7:18 AM, Scott Ellis wrote:
> Signed-off-by: Scott Ellis 
> ---
>  recipes-security/ncrack/ncrack_0.7.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-security/ncrack/ncrack_0.7.bb 
> b/recipes-security/ncrack/ncrack_0.7.bb
> index 06ba2b6..ba26965 100644
> --- a/recipes-security/ncrack/ncrack_0.7.bb
> +++ b/recipes-security/ncrack/ncrack_0.7.bb
> @@ -4,9 +4,9 @@ HOMEPAGE = "https://nmap.org/ncrack;
>  SECTION = "security"
>  
>  LICENSE = "GPL-2.0"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=198fa93d4e80225839e595336f3b5ff0"
> +LIC_FILES_CHKSUM = 
> "file://COPYING;beginline=7;endline=12;md5=66938a7e5b4c118eda78271de14874c2"

Why did the LIC_FILES_CHKSUM change?
>  
> -SRCREV = "3a793a21820708466081825beda9fce857f36cb6"
> +SRCREV = "dc570e7e3cec1fb176c0168eaedc723084bd0426"
>  SRC_URI = "git://github.com/nmap/ncrack.git"
>  
>  DEPENDS = "openssl zlib"

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

Re: [yocto] [meta-selinux] [PATCH] python-scapy: upgrade 2.4.2 -> 2.4.3

[akuster808]

On 8/29/19 7:25 AM, Joe MacDonald wrote:
> [Re: [yocto] [meta-selinux] [PATCH] python-scapy: upgrade 2.4.2 -> 2.4.3] On 
> 19.08.29 (Thu 07:14) akuster808 wrote:
>
No v2 required. does not affect patchwork.

- armin
>>
>> On 8/28/19 10:41 PM, Yuan Chao wrote:
>>> License file changed from bin/scapy to LICENSE
>> Is this the correct layer?
> There's no scapy in meta-selinux, AFAIK.  So proably this was destined
> for meta-security instead.
>
> -J.
>
>> -armin
>>> Signed-off-by: Yuan Chao 
>>> ---
>>>  recipes-security/scapy/python-scapy.inc   | 4 ++--
>>>  .../scapy/{python-scapy_2.4.2.bb => python-scapy_2.4.3.bb}| 0
>>>  .../scapy/{python3-scapy_2.4.2.bb => python3-scapy_2.4.3.bb}  | 0
>>>  3 files changed, 2 insertions(+), 2 deletions(-)
>>>  rename recipes-security/scapy/{python-scapy_2.4.2.bb => 
>>> python-scapy_2.4.3.bb} (100%)
>>>  rename recipes-security/scapy/{python3-scapy_2.4.2.bb => 
>>> python3-scapy_2.4.3.bb} (100%)
>>>
>>> diff --git a/recipes-security/scapy/python-scapy.inc 
>>> b/recipes-security/scapy/python-scapy.inc
>>> index baa69b2..28e13f2 100644
>>> --- a/recipes-security/scapy/python-scapy.inc
>>> +++ b/recipes-security/scapy/python-scapy.inc
>>> @@ -3,11 +3,11 @@ DESCRIPTION = "Scapy is a powerful interactive packet 
>>> manipulation program. It i
>>>  SECTION = "security"
>>>  LICENSE = "GPLv2"
>>>  
>>> -LIC_FILES_CHKSUM = 
>>> "file://bin/scapy;beginline=9;endline=13;md5=1d5249872cc54cd4ca3d3879262d0c69"
>>> +LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>>>  
>>>  S = "${WORKDIR}/git"
>>>  
>>> -SRCREV = "bad14cb1a5aee29f8107fbe8ad008d4645f14da7"
>>> +SRCREV = "3047580162a9407ef05fe981983cacfa698f1159"
>>>  SRC_URI = "git://github.com/secdev/scapy.git"
>>>  
>>>  inherit ptest
>>> diff --git a/recipes-security/scapy/python-scapy_2.4.2.bb 
>>> b/recipes-security/scapy/python-scapy_2.4.3.bb
>>> similarity index 100%
>>> rename from recipes-security/scapy/python-scapy_2.4.2.bb
>>> rename to recipes-security/scapy/python-scapy_2.4.3.bb
>>> diff --git a/recipes-security/scapy/python3-scapy_2.4.2.bb 
>>> b/recipes-security/scapy/python3-scapy_2.4.3.bb
>>> similarity index 100%
>>> rename from recipes-security/scapy/python3-scapy_2.4.2.bb
>>> rename to recipes-security/scapy/python3-scapy_2.4.3.bb
>> -- 
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] [PATCH] python-scapy: upgrade 2.4.2 -> 2.4.3

[akuster808]

On 8/28/19 10:41 PM, Yuan Chao wrote:
> License file changed from bin/scapy to LICENSE
Is this the correct layer?

-armin
>
> Signed-off-by: Yuan Chao 
> ---
>  recipes-security/scapy/python-scapy.inc   | 4 ++--
>  .../scapy/{python-scapy_2.4.2.bb => python-scapy_2.4.3.bb}| 0
>  .../scapy/{python3-scapy_2.4.2.bb => python3-scapy_2.4.3.bb}  | 0
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  rename recipes-security/scapy/{python-scapy_2.4.2.bb => 
> python-scapy_2.4.3.bb} (100%)
>  rename recipes-security/scapy/{python3-scapy_2.4.2.bb => 
> python3-scapy_2.4.3.bb} (100%)
>
> diff --git a/recipes-security/scapy/python-scapy.inc 
> b/recipes-security/scapy/python-scapy.inc
> index baa69b2..28e13f2 100644
> --- a/recipes-security/scapy/python-scapy.inc
> +++ b/recipes-security/scapy/python-scapy.inc
> @@ -3,11 +3,11 @@ DESCRIPTION = "Scapy is a powerful interactive packet 
> manipulation program. It i
>  SECTION = "security"
>  LICENSE = "GPLv2"
>  
> -LIC_FILES_CHKSUM = 
> "file://bin/scapy;beginline=9;endline=13;md5=1d5249872cc54cd4ca3d3879262d0c69"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>  
>  S = "${WORKDIR}/git"
>  
> -SRCREV = "bad14cb1a5aee29f8107fbe8ad008d4645f14da7"
> +SRCREV = "3047580162a9407ef05fe981983cacfa698f1159"
>  SRC_URI = "git://github.com/secdev/scapy.git"
>  
>  inherit ptest
> diff --git a/recipes-security/scapy/python-scapy_2.4.2.bb 
> b/recipes-security/scapy/python-scapy_2.4.3.bb
> similarity index 100%
> rename from recipes-security/scapy/python-scapy_2.4.2.bb
> rename to recipes-security/scapy/python-scapy_2.4.3.bb
> diff --git a/recipes-security/scapy/python3-scapy_2.4.2.bb 
> b/recipes-security/scapy/python3-scapy_2.4.3.bb
> similarity index 100%
> rename from recipes-security/scapy/python3-scapy_2.4.2.bb
> rename to recipes-security/scapy/python3-scapy_2.4.3.bb

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

Re: [yocto] Build break in the latest openbmc tree.

[akuster808]

the meta-security layer should be fix now.

please update and let me know if not.

-armin

On 8/22/19 6:09 PM, Brad Bishop wrote:
> at 6:38 PM, James Feist  wrote:
>
>> On 8/22/19 3:35 PM, Jae Hyun Yoo wrote:
>>> Hi brad,
>>
>> + The mailing list
>>
>>> We met a build break while making Intel platform builds.
>>> ERROR: No recipes available for:
>>> /home/yoojae/workspace/openbmc/meta-security/recipes-kernel/linux/linux-stable_5.2.bbappend
>>> It was added by the subtree update patch but there is no main recipe
>>> for it. Did we miss something?
>>> Thanks,
>>> Jae
>
> Hi Jae
>
> linux-stable is in meta-odroid:
> https://lists.yoctoproject.org/pipermail/yocto/2019-August/046424.html
>
> It isn’t clear to me if meta-security is supposed to have a hard
> dependency on meta-odroid or not.
>
> Hi Armin
>
> Could you suggest what the right thing to do here might be?
>
> thx!
> brad

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

Re: [yocto] Build break in the latest openbmc tree.

[akuster808]

On 8/22/19 6:09 PM, Brad Bishop wrote:
> at 6:38 PM, James Feist  wrote:
>
>> On 8/22/19 3:35 PM, Jae Hyun Yoo wrote:
>>> Hi brad,
>>
>> + The mailing list
>>
>>> We met a build break while making Intel platform builds.
>>> ERROR: No recipes available for:
>>> /home/yoojae/workspace/openbmc/meta-security/recipes-kernel/linux/linux-stable_5.2.bbappend
>>> It was added by the subtree update patch but there is no main recipe
>>> for it. Did we miss something?
>>> Thanks,
>>> Jae
>
> Hi Jae
>
> linux-stable is in meta-odroid:
> https://lists.yoctoproject.org/pipermail/yocto/2019-August/046424.html
>
> It isn’t clear to me if meta-security is supposed to have a hard
> dependency on meta-odroid or not.
It should not. The is bad behavior and I wanted to avoid such an issue.
meta-security is a s/w layer and should be BSP neutral.  I did not
achieve that.
>
> Hi Armin
>
> Could you suggest what the right thing to do here might be?
Yeah, i believe the recipe in meta-security should be linux-%.* . My
testing unfortunately kept the meta-odroid layer included so its a false
positive. Not my intent . I know the qemu machines should build clean
with any changes in that layer.

I am testing changes now to correct his issue.

- armin
>
> thx!
> brad


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

Re: [yocto] [meta-security][PATCH 3/3] linux-stable/5.2: add stable bbappend

[akuster808]

On 8/20/19 8:11 PM, Hongzhi, Song wrote:
> Hi Armin,
>
> Do you know where is linux-stable_5.2.bb?

yes. in meta-odroid.

I suspect we could just use linux-%_5.2.bb

- armin
>
> Thanks,
>
> --Hongzhi
>
>
> On 8/14/19 7:54 AM, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>   recipes-kernel/linux/linux-stable_5.2.bbappend | 4 
>>   1 file changed, 4 insertions(+)
>>   create mode 100644 recipes-kernel/linux/linux-stable_5.2.bbappend
>>
>> diff --git a/recipes-kernel/linux/linux-stable_5.2.bbappend
>> b/recipes-kernel/linux/linux-stable_5.2.bbappend
>> new file mode 100644
>> index 000..76b5df5
>> --- /dev/null
>> +++ b/recipes-kernel/linux/linux-stable_5.2.bbappend
>> @@ -0,0 +1,4 @@
>> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES",
>> "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
>> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES",
>> "smack", " features/smack/smack.scc", "" ,d)}"
>> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES",
>> "yama", " features/yama/yama.scc", "" ,d)}"
>> +

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

Re: [yocto] [PATCH][thud] meta-yocto-bsp: Bump to the latest stable kernel for the BSPs

[akuster808]

On 8/12/19 8:48 PM, Kevin Hao wrote:
> On Fri, Apr 19, 2019 at 01:23:35PM +0800, Kevin Hao wrote:
>> In order to fix a systemtap bug [1] on arm board, we backport a kernel
>> patch from v5.0 kernel to v4.14 & v4.18 kernel, then need to bump the
>> kernel version to include this patch. Even this is only an arm specific
>> bug, we would like to bump the kernel version for the BSPs at the same
>> time. Boot test for all the boards.
>>
>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273
> Hi Armin,
>
> Could you help merge this patch to thud branch?
yes. It is now on my list.

Thanks,
Armin
>
> Thanks,
> Kevin
>
>> Signed-off-by: Kevin Hao 
>> ---
>>  .../recipes-kernel/linux/linux-yocto_4.14.bbappend   | 20 
>> ++--
>>  .../recipes-kernel/linux/linux-yocto_4.18.bbappend   | 20 
>> ++--
>>  2 files changed, 20 insertions(+), 20 deletions(-)
>>
>> diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend 
>> b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
>> index 502485a94b15..426757e48c9e 100644
>> --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
>> +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
>> @@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
>>  KMACHINE_genericx86-64 ?= "common-pc-64"
>>  KMACHINE_beaglebone-yocto ?= "beaglebone"
>>  
>> -SRCREV_machine_genericx86?= "2c5caa7e84311f2a0097974a697ac1f59030530e"
>> -SRCREV_machine_genericx86-64 ?= "2c5caa7e84311f2a0097974a697ac1f59030530e"
>> -SRCREV_machine_edgerouter ?= "e06bfa18c727bd0e6e10cf26d9f161e4c791f52b"
>> -SRCREV_machine_beaglebone-yocto ?= 
>> "b8805de77dcf8f59d8368fee4921c146c1300a6a"
>> -SRCREV_machine_mpc8315e-rdb ?= "f88e87360b10f8fbd853a7d412982e6620f3f96d"
>> +SRCREV_machine_genericx86?= "5252513a39b4b3773debab1f77071d7c430ecb10"
>> +SRCREV_machine_genericx86-64 ?= "5252513a39b4b3773debab1f77071d7c430ecb10"
>> +SRCREV_machine_edgerouter ?= "d8fb40cd0e99325715c70aed6f361a8318097829"
>> +SRCREV_machine_beaglebone-yocto ?= 
>> "c67809688bd22cb4cb909bcf1a1045e6337c3229"
>> +SRCREV_machine_mpc8315e-rdb ?= "258ee8228e0a512c6dbe2a0dadcd9f030ba45964"
>>  
>>  COMPATIBLE_MACHINE_genericx86 = "genericx86"
>>  COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
>> @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
>>  COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
>>  COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>>  
>> -LINUX_VERSION_genericx86 = "4.14.76"
>> -LINUX_VERSION_genericx86-64 = "4.14.76"
>> -LINUX_VERSION_edgerouter = "4.14.71"
>> -LINUX_VERSION_beaglebone-yocto = "4.14.71"
>> -LINUX_VERSION_mpc8315e-rdb = "4.14.71"
>> +LINUX_VERSION_genericx86 = "4.14.98"
>> +LINUX_VERSION_genericx86-64 = "4.14.98"
>> +LINUX_VERSION_edgerouter = "4.14.98"
>> +LINUX_VERSION_beaglebone-yocto = "4.14.98"
>> +LINUX_VERSION_mpc8315e-rdb = "4.14.98"
>> diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend 
>> b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
>> index 7f15843f3a90..11b35cc1c2f8 100644
>> --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
>> +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
>> @@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
>>  KMACHINE_genericx86-64 ?= "common-pc-64"
>>  KMACHINE_beaglebone-yocto ?= "beaglebone"
>>  
>> -SRCREV_machine_genericx86?= "db2d813869a0501782469ecdb17e277a501c9f57"
>> -SRCREV_machine_genericx86-64 ?= "db2d813869a0501782469ecdb17e277a501c9f57"
>> -SRCREV_machine_edgerouter ?= "28e7781d57a59227bf1c08c7f3dbdfee16aa0dc2"
>> -SRCREV_machine_beaglebone-yocto ?= 
>> "28e7781d57a59227bf1c08c7f3dbdfee16aa0dc2"
>> -SRCREV_machine_mpc8315e-rdb ?= "99071a599d8650b069fb8135866fca203f375350"
>> +SRCREV_machine_genericx86?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
>> +SRCREV_machine_genericx86-64 ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
>> +SRCREV_machine_edgerouter ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
>> +SRCREV_machine_beaglebone-yocto ?= 
>> "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
>> +SRCREV_machine_mpc8315e-rdb ?= "0802dc980cbc8bdb156d6fe305e7b88e6b602634"
>>  
>>  COMPATIBLE_MACHINE_genericx86 = "genericx86"
>>  COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
>> @@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
>>  COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
>>  COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>>  
>> -LINUX_VERSION_genericx86 = "4.18.22"
>> -LINUX_VERSION_genericx86-64 = "4.18.22"
>> -LINUX_VERSION_edgerouter = "4.18.25"
>> -LINUX_VERSION_beaglebone-yocto = "4.18.25"
>> -LINUX_VERSION_mpc8315e-rdb = "4.18.25"
>> +LINUX_VERSION_genericx86 = "4.18.35"
>> +LINUX_VERSION_genericx86-64 = "4.18.35"
>> +LINUX_VERSION_edgerouter = "4.18.35"
>> +LINUX_VERSION_beaglebone-yocto = "4.18.35"
>> +LINUX_VERSION_mpc8315e-rdb = "4.18.35"
>> -- 
>> 2.14.4
>>
>>

-- 
___
yocto mailing 

Re: [linux-yocto] [PATCH 0/4] More security fragments

[akuster808]

On 8/12/19 8:11 AM, Bruce Ashfield wrote:
> I've merged these to the 4.19/5.0/5.2 and master branches.

thanks.

-armin
>
> SRCREV updates will follow this week, once I get some more test cycles
> completed.
>
> Bruce
>
> On Sun, Aug 11, 2019 at 12:29 PM Armin Kuster  > wrote:
>
> It is time to move the kernel fragments out of meta-security to cache.
> It should make maintenance easier.
>
> Armin Kuster (4):
>   kernel-cache: add apparmor fragments
>   kernel-cache: add smack
>   kernel-cache: add ima fragments
>   kernel-cache: add yama security fragments
>
>  features/apparmor/apparmor.cfg         |  7 +++
>  features/apparmor/apparmor.scc         |  5 +
>  features/apparmor/apparmor_on_boot.cfg |  1 +
>  features/ima/ima.cfg                   | 18 ++
>  features/ima/ima.scc                   |  4 
>  features/ima/ima_evm_root_ca.cfg       |  3 +++
>  features/ima/modsign.cfg               |  3 +++
>  features/ima/modsign.scc               |  6 ++
>  features/smack/smack.cfg               | 10 ++
>  features/smack/smack.scc               |  4 
>  features/yama/yama.cfg                 |  1 +
>  features/yama/yama.scc                 |  4 
>  12 files changed, 66 insertions(+)
>  create mode 100644 features/apparmor/apparmor.cfg
>  create mode 100644 features/apparmor/apparmor.scc
>  create mode 100644 features/apparmor/apparmor_on_boot.cfg
>  create mode 100644 features/ima/ima.cfg
>  create mode 100644 features/ima/ima.scc
>  create mode 100644 features/ima/ima_evm_root_ca.cfg
>  create mode 100644 features/ima/modsign.cfg
>  create mode 100644 features/ima/modsign.scc
>  create mode 100644 features/smack/smack.cfg
>  create mode 100644 features/smack/smack.scc
>  create mode 100644 features/yama/yama.cfg
>  create mode 100644 features/yama/yama.scc
>
> -- 
> 2.17.1
>
> -- 
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/linux-yocto
>
>
>
> -- 
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>

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

Re: [yocto] [meta-integrity] layer.conf: switch to keyutils from meta-oe

[akuster808]

On 8/6/19 6:54 AM, Dmitry Eremin-Solenikov wrote:
> пн, 29 июл. 2019 г. в 13:45, :
>> From: Dmitry Eremin-Solenikov 
>>
>> As pointer by Martin Jansa, keyutils package is now a part of meta-oe,
>> so switch to using keyutils from that layer.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov 
> This patch is still necessary.

ah, forgot that one. thanks.

- armin
>

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

Re: [yocto] [meta-security 2/3] kernel-modsign.bbclass: add support for kernel modules signing

[akuster808]

On 8/4/19 1:24 PM, Dmitry Eremin-Solenikov wrote:
> вс, 4 авг. 2019 г. в 18:30, akuster808 :
>> On 7/28/19 8:31 AM, Dmitry Eremin-Solenikov wrote:
>>> From: Dmitry Eremin-Solenikov 
>>>
>>> Add bbclass responsible for handling signing of kernel modules.
>>>
>>> Signed-off-by: Dmitry Eremin-Solenikov 
>>> ---
>>>  meta-integrity/classes/kernel-modsign.bbclass | 29 +++
>>>  .../data/debug-keys/privkey_modsign.pem   | 28 ++
>>>  .../data/debug-keys/x509_modsign.crt  | 22 ++
>>>  3 files changed, 79 insertions(+)
>>>  create mode 100644 meta-integrity/classes/kernel-modsign.bbclass
>>>  create mode 100644 meta-integrity/data/debug-keys/privkey_modsign.pem
>>>  create mode 100644 meta-integrity/data/debug-keys/x509_modsign.crt
>>>
>>> diff --git a/meta-integrity/classes/kernel-modsign.bbclass 
>>> b/meta-integrity/classes/kernel-modsign.bbclass
>>> new file mode 100644
>>> index ..1e4d94b79091
>>> --- /dev/null
>>> +++ b/meta-integrity/classes/kernel-modsign.bbclass
>>> @@ -0,0 +1,29 @@
>>> +# No default! Either this or MODSIGN_PRIVKEY/MODSIGN_X509 have to be
>>> +# set explicitly in a local.conf before activating kernel-modsign.
>>> +# To use the insecure (because public) example keys, use
>>> +# MODSIGN_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
>>> +MODSIGN_KEY_DIR ?= "MODSIGN_KEY_DIR_NOT_SET"
>>> +
>>> +# Private key for modules signing. The default is okay when
>>> +# using the example key directory.
>>> +MODSIGN_PRIVKEY ?= "${MODSIGN_KEY_DIR}/privkey_modsign.pem"
>>> +
>>> +# Public part of certificates used for modules signing.
>>> +# The default is okay when using the example key directory.
>>> +MODSIGN_X509 ?= "${MODSIGN_KEY_DIR}/x509_modsign.crt"
>>> +
>>> +# If this class is enabled, disable stripping signatures from modules
>>> +INHIBIT_PACKAGE_STRIP = "1"
>>> +
>>> +do_configure_prepend() {
>> This is being pulled in with every configure task and causing parsing
>> issues.
>>
>> I changed it to "kernel_do_configure_prepend" and that fixed the issue I
>> was seeing.
> Interesting. I haven't seen this issue. Could you please share any details?
>
> Changed bbclass appears to work for me, so either of them is fine from my
> point of view.
with 'INHERIT += "kernel-modsign"' added to my local.conf I see this.

bitbake integrity-image-minimal
WARNING:
/home/build/releases/master/poky/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb:
Exception during build_dependencies for do_configure
WARNING:
/home/build/releases/master/poky/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb:
Error during finalise of
/home/build/releases/master/poky/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb
ERROR: Unable to parse
/home/build/releases/master/poky/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb
Traceback (most recent call last):
  File "/home/build/releases/master/poky/bitbake/lib/bb/siggen.py", line
149, in
SignatureGeneratorOEBasicHash.finalise(fn='/home/build/releases/master/poky/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb',
d=, variant=None):
 try:
    >    taskdeps = self._build_data(fn, d)
 except bb.parse.SkipRecipe:
  File "/home/build/releases/master/poky/bitbake/lib/bb/siggen.py", line
120, in
SignatureGeneratorOEBasicHash._build_data(fn='/home/build/releases/master/poky/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb',
d=):
 ignore_mismatch = ((d.getVar("BB_HASH_IGNORE_MISMATCH") or
'') == '1')
    >    tasklist, gendeps, lookupcache =
bb.data.generate_dependencies(d)

  File "/home/build/releases/master/poky/bitbake/lib/bb/data.py", line
379, in generate_dependencies(d=):
 for task in tasklist:
    >    deps[task], values[task] = build_dependencies(task, keys,
shelldeps, varflagsexcl, d)
 newdeps = deps[task]
  File "/home/build/releases/master/poky/bitbake/lib/bb/data.py", line
312, in build_dependencies(key='do_configure',
keys={'OLDEST_KERNEL_riscv64', 'BBFILE_PATTERN_perl-layer',
'patch_do_patch', 'PREFERRED_PROVIDER_nativesdk-linux-libc-headers',
'RECIPE_MAINTAINER_pn-help2man-native', 'sstate_package', 'PKGDESTWORK',
'EXCLUDE_FROM_WORLD_pn-prelink_libc-musl', 'LAYERVERSION_core',
'IMAGE_FSTYPES', 'RECIPE_MAINTAINER_pn-opkg',
'RECIPE_MAINTAINER_pn-libsdl2', 'DEFAULT_TEST_SUITES',
'SYSVINIT_ENABLED_GETTYS', 'SDK_ARCH', 'PYTHON',
'RECIPE_MAINTAINER_pn-initramfs-framework', 'SANITY_SITECONF_SAMPLE',
'get_patches_c

Re: [yocto] [meta-security 2/3] kernel-modsign.bbclass: add support for kernel modules signing

[akuster808]

On 7/28/19 8:31 AM, Dmitry Eremin-Solenikov wrote:
> From: Dmitry Eremin-Solenikov 
>
> Add bbclass responsible for handling signing of kernel modules.
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  meta-integrity/classes/kernel-modsign.bbclass | 29 +++
>  .../data/debug-keys/privkey_modsign.pem   | 28 ++
>  .../data/debug-keys/x509_modsign.crt  | 22 ++
>  3 files changed, 79 insertions(+)
>  create mode 100644 meta-integrity/classes/kernel-modsign.bbclass
>  create mode 100644 meta-integrity/data/debug-keys/privkey_modsign.pem
>  create mode 100644 meta-integrity/data/debug-keys/x509_modsign.crt
>
> diff --git a/meta-integrity/classes/kernel-modsign.bbclass 
> b/meta-integrity/classes/kernel-modsign.bbclass
> new file mode 100644
> index ..1e4d94b79091
> --- /dev/null
> +++ b/meta-integrity/classes/kernel-modsign.bbclass
> @@ -0,0 +1,29 @@
> +# No default! Either this or MODSIGN_PRIVKEY/MODSIGN_X509 have to be
> +# set explicitly in a local.conf before activating kernel-modsign.
> +# To use the insecure (because public) example keys, use
> +# MODSIGN_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
> +MODSIGN_KEY_DIR ?= "MODSIGN_KEY_DIR_NOT_SET"
> +
> +# Private key for modules signing. The default is okay when
> +# using the example key directory.
> +MODSIGN_PRIVKEY ?= "${MODSIGN_KEY_DIR}/privkey_modsign.pem"
> +
> +# Public part of certificates used for modules signing.
> +# The default is okay when using the example key directory.
> +MODSIGN_X509 ?= "${MODSIGN_KEY_DIR}/x509_modsign.crt"
> +
> +# If this class is enabled, disable stripping signatures from modules
> +INHIBIT_PACKAGE_STRIP = "1"
> +
> +do_configure_prepend() {

This is being pulled in with every configure task and causing parsing
issues.

I changed it to "kernel_do_configure_prepend" and that fixed the issue I
was seeing.

things appear to be still working, Can you double check.

- armin


> +if [ -f "${MODSIGN_PRIVKEY}" -a -f "${MODSIGN_X509}" ]; then
> +cat "${MODSIGN_PRIVKEY}" "${MODSIGN_X509}" \
> +> "${B}/modsign_key.pem"
> +else
> +bberror "Either modsign key or certificate are invalid"
> +fi
> +}
> +
> +do_shared_workdir_append() {
> +cp modsign_key.pem $kerneldir/
> +}
> diff --git a/meta-integrity/data/debug-keys/privkey_modsign.pem 
> b/meta-integrity/data/debug-keys/privkey_modsign.pem
> new file mode 100644
> index ..4cac00ae303a
> --- /dev/null
> +++ b/meta-integrity/data/debug-keys/privkey_modsign.pem
> @@ -0,0 +1,28 @@
> +-BEGIN PRIVATE KEY-
> +MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDEWsJjB2pA5Ih6
> +EelXvVjwWY1ix1azMciNRNPPQN1AMXF0K/VUkfOYbaPajg1cQYEf9gk3q7OZ5Axk
> +UY/e5piZORaPcsmj0lV0L+NSlRYydR5M/QxtEz26585FgqRGdAe6umStPmVKdqa2
> +d68O4PgQgJJtVuz6ndm+0uNEUDCVLwhkGQSwNB3qBbZAUX9escZ/a8eUiBfMYKaO
> +k8JRyM+2br9dgpTFg4UfBYexgNSQo8g5TIBGc8KgQiKCuFj1fQEhV5z4RusHthjc
> +NYXa3RHmdclxyrGeYr5ZRc47HqE1gd5NDR0WeHn4C4YKcfK1rZZz/2+6hfsIRfGx
> +6cQKk23hAgMBAAECggEAJ0ULiWirPG04SkmYxF5vEiqm1zGMymvTc0VnoxSS60q4
> +KQa9mvtRn5OV6JjuXRwQqga30zV4xvdP7yRMxMSTkllThL7tSuE/C+yj5xlABjlc
> +JQOa35mwh9fibg5xslF0Vkj+55MKCPlv4CBRl4Uwt4QvRMTUwk6dhMeCgmATR1J1
> +2/7AipjtfFYreDx7sLbRVvSzUhmZS0iCbNOhtTWPLNW+9YKHTOffKa04HzNtnAXq
> +OjJ0IRZD/C6LfkBUsnHg2eEiA97QXh/Srsl9nc8DaUK1IXRywEdmYIoNMWMav2Hm
> +RO8kkU30BqKW+/EO2ZbH2GmkxvwWd0ocBnLC3FRWEQKBgQDu4T8CB3YsOcVjqem4
> +iBlaSht/b46YQc7A1SOqZCimehmmXNSxQOkapIG3wlIr5edtXQA+xv09+WrproUB
> +SjAnqaH6pYeCvbNlY5k344gtYs+Kco2rq5GYa+LumAeX2Sam8F7u4LxvEogCecX7
> +e4rnG3lt3AVuuRE7zpCQtaWcJQKBgQDSbUvea9pcYli9pssTl+ijQKkgG9DdaYbA
> +I5w5bY1TPYZ/Ocysljefv/ssaHFh4DPxE1MQ5JHwZgZRo1EICxxYzGsLjyR/fmjz
> +1c/NJlTtalCNtLvWaf7b02ag/abnP8neiSpLL5xqHvGo5ikWwgYQD+9HVKGvL3S1
> +kI7x/ziADQKBgQCqFbkuMa/jh3LTJp0iZc1fa1qu3vhx0pFq3Zeab9w9xLxUps5O
> +MwCGltFBzNuDJBwm00wkZrzTjq6gGkHbjD5DT1XkyE13OqjsLQFgOOKyJiPN2Qik
> +TfHJzC91YMwvQ09xF78QaPXiRBiRYrEkAXACY56PKVS45I6vvcFTN/Ll/QKBgA9m
> +KDMyuVwhZlUaq6nXaBLqXHYZEwPhARd2g6xANCNvUTRmSnAm3hM2vW7WhdWfzq1J
> +uL53u6ZYEQZQaVGpXn2xF/RUmVsrKQsPDpH4yCZHrXVxUH20bA4yPkRxy5EIvgEn
> +EI1IAq5RbWXq0f70W/U49U3HB74GPwg6d/uFreDRAoGAN+v9gMQA6A1vM7LvbYR8
> +5CwwyqS/CfI9zKPLn53QstguXC/ObafIYQzVRqGb9lCQgtlmmKw4jMY0B/lDzpcH
> +zS8rqoyvDj/m7i17NYkqXErJKLRQ0ptXKdLXHlG0u185e7Y5p4O3Z5dk8bACkpHi
> +hp764y+BtU4qIcVaPsPK4uU=
> +-END PRIVATE KEY-
> diff --git a/meta-integrity/data/debug-keys/x509_modsign.crt 
> b/meta-integrity/data/debug-keys/x509_modsign.crt
> new file mode 100644
> index ..5fa2a9062a89
> --- /dev/null
> +++ b/meta-integrity/data/debug-keys/x509_modsign.crt
> @@ -0,0 +1,22 @@
> +-BEGIN CERTIFICATE-
> +MIIDnjCCAoagAwIBAgIUUqmBj5Q8edHMMTXsoGVGEEKdwV4wDQYJKoZIhvcNAQEL
> +BQAwZzEqMCgGA1UEAxMhbWV0YS1zZWN1cml0eSBtb2R1bGVzIHNpZ25pbmcga2V5
> +MRQwEgYDVQQKEwtleGFtcGxlLmNvbTEjMCEGCSqGSIb3DQEJARYUam9obi5kb2VA
> +ZXhhbXBsZS5jb20wIBcNMTkwNzI3MjIzOTA3WhgPMjExOTA3MjcyMjM5MTVaMGcx
> +KjAoBgNVBAMTIW1ldGEtc2VjdXJpdHkgbW9kdWxlcyBzaWduaW5nIGtleTEUMBIG

Re: [yocto] [meta-integrity][PATCH] ima-evm-utils: bump to release 1.2.1

[akuster808]

Dmitry,


On 7/31/19 1:24 PM, dbarysh...@gmail.com wrote:
> From: Dmitry Eremin-Solenikov 
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  ...link-to-libcrypto-instead-of-OpenSSL.patch | 65 ---
>  ...ls-replace-INCLUDES-with-AM_CPPFLAGS.patch | 43 
>  ...clude-hash-info.gen-into-distributio.patch | 31 -
>  ...ma-evm-utils-update-.gitignore-files.patch | 34 --
>  .../ima-evm-utils/ima-evm-utils_git.bb| 12 +---
>  5 files changed, 3 insertions(+), 182 deletions(-)
>  delete mode 100644 
> meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-ima-evm-utils-link-to-libcrypto-instead-of-OpenSSL.patch
>  delete mode 100644 
> meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0002-ima-evm-utils-replace-INCLUDES-with-AM_CPPFLAGS.patch
>  delete mode 100644 
> meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0003-ima-evm-utils-include-hash-info.gen-into-distributio.patch
>  delete mode 100644 
> meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0004-ima-evm-utils-update-.gitignore-files.patch
I am evaluation all your updates to this layer. I am traveling (PTO) and
have limited access to test system. I will either merge them or send
feedback in the next few days.

kind regards and thanks for the patches,
Armin
>
> diff --git 
> a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-ima-evm-utils-link-to-libcrypto-instead-of-OpenSSL.patch
>  
> b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-ima-evm-utils-link-to-libcrypto-instead-of-OpenSSL.patch
> deleted file mode 100644
> index 5ccb73d9b6e6..
> --- 
> a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0001-ima-evm-utils-link-to-libcrypto-instead-of-OpenSSL.patch
> +++ /dev/null
> @@ -1,65 +0,0 @@
> -From 4feaf9b61f93e4043eca26b4ec9f9f68d0cf5e68 Mon Sep 17 00:00:00 2001
> -From: Dmitry Eremin-Solenikov 
> -Date: Wed, 6 Mar 2019 01:08:43 +0300
> -Subject: [PATCH 1/4] ima-evm-utils: link to libcrypto instead of OpenSSL
> -
> -There is no need to link to full libssl. evmctl uses functions from
> -libcrypto, so let's link only against that library.
> -
> -Signed-off-by: Dmitry Eremin-Solenikov 
> 
> - configure.ac| 4 +---
> - src/Makefile.am | 9 -
> - 2 files changed, 5 insertions(+), 8 deletions(-)
> -
> -diff --git a/configure.ac b/configure.ac
> -index 60f3684..32e8d85 100644
>  a/configure.ac
> -+++ b/configure.ac
> -@@ -24,9 +24,7 @@ LT_INIT
> - # Checks for header files.
> - AC_HEADER_STDC
> - 
> --PKG_CHECK_MODULES(OPENSSL, [ openssl >= 0.9.8 ])
> --AC_SUBST(OPENSSL_CFLAGS)
> --AC_SUBST(OPENSSL_LIBS)
> -+PKG_CHECK_MODULES(LIBCRYPTO, [libcrypto >= 0.9.8 ])
> - AC_SUBST(KERNEL_HEADERS)
> - AC_CHECK_HEADER(unistd.h)
> - AC_CHECK_HEADERS(openssl/conf.h)
> -diff --git a/src/Makefile.am b/src/Makefile.am
> -index d74fc6f..b81281a 100644
>  a/src/Makefile.am
> -+++ b/src/Makefile.am
> -@@ -1,11 +1,11 @@
> - lib_LTLIBRARIES = libimaevm.la
> - 
> - libimaevm_la_SOURCES = libimaevm.c
> --libimaevm_la_CPPFLAGS = $(OPENSSL_CFLAGS)
> -+libimaevm_la_CPPFLAGS = $(LIBCRYPTO_CFLAGS)
> - # current[:revision[:age]]
> - # result: [current-age].age.revision
> - libimaevm_la_LDFLAGS = -version-info 0:0:0
> --libimaevm_la_LIBADD =  $(OPENSSL_LIBS)
> -+libimaevm_la_LIBADD =  $(LIBCRYPTO_LIBS)
> - 
> - include_HEADERS = imaevm.h
> - 
> -@@ -17,12 +17,11 @@ hash_info.h: Makefile
> - bin_PROGRAMS = evmctl
> - 
> - evmctl_SOURCES = evmctl.c
> --evmctl_CPPFLAGS = $(OPENSSL_CFLAGS)
> -+evmctl_CPPFLAGS = $(LIBCRYPTO_CFLAGS)
> - evmctl_LDFLAGS = $(LDFLAGS_READLINE)
> --evmctl_LDADD =  $(OPENSSL_LIBS) -lkeyutils libimaevm.la
> -+evmctl_LDADD =  $(LIBCRYPTO_LIBS) -lkeyutils libimaevm.la
> - 
> - INCLUDES = -I$(top_srcdir) -include config.h
> - 
> - CLEANFILES = hash_info.h
> - DISTCLEANFILES = @DISTCLEANFILES@
> --
> --- 
> -2.17.1
> -
> diff --git 
> a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0002-ima-evm-utils-replace-INCLUDES-with-AM_CPPFLAGS.patch
>  
> b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0002-ima-evm-utils-replace-INCLUDES-with-AM_CPPFLAGS.patch
> deleted file mode 100644
> index 8237274ca8b6..
> --- 
> a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils/0002-ima-evm-utils-replace-INCLUDES-with-AM_CPPFLAGS.patch
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -From 5bb10f3da420f4c46e44423276a9da0d4bc1b691 Mon Sep 17 00:00:00 2001
> -From: Dmitry Eremin-Solenikov 
> -Date: Wed, 6 Mar 2019 01:17:12 +0300
> -Subject: [PATCH 2/4] ima-evm-utils: replace INCLUDES with AM_CPPFLAGS
> -
> -Replace INCLUDES variable with AM_CPPFLAGS to stop Automake from warning
> -about deprecated variable usage.
> -
> -Signed-off-by: Dmitry Eremin-Solenikov 
> 
> - src/Makefile.am | 6 +++---
> - 1 file changed, 3 insertions(+), 3 deletions(-)
> -
> -diff --git a/src/Makefile.am b/src/Makefile.am
> -index b81281a..164e7e4 100644
>  a/src/Makefile.am
> -+++ b/src/Makefile.am
> 

Re: [yocto] [meta-security] keyutils: migrate to meta-oe

[akuster808]

On 7/29/19 3:47 AM, dbarysh...@gmail.com wrote:
> From: Dmitry Eremin-Solenikov 
>
> keyutils are now part of meta-oe, so remove them from meta-security.

This should be sitting in master-next already

- armin
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  .../files/fix_library_install_path.patch  | 28 --
>  ...ror-report-by-adding-default-message.patch | 42 ---
>  .../keyutils-test-fix-output-format.patch | 41 --
>  recipes-security/keyutils/files/run-ptest |  3 --
>  recipes-security/keyutils/keyutils_1.6.bb | 53 ---
>  5 files changed, 167 deletions(-)
>  delete mode 100644 
> recipes-security/keyutils/files/fix_library_install_path.patch
>  delete mode 100644 
> recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
>  delete mode 100644 
> recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
>  delete mode 100755 recipes-security/keyutils/files/run-ptest
>  delete mode 100644 recipes-security/keyutils/keyutils_1.6.bb
>
> diff --git a/recipes-security/keyutils/files/fix_library_install_path.patch 
> b/recipes-security/keyutils/files/fix_library_install_path.patch
> deleted file mode 100644
> index 938fe2eb57a4..
> --- a/recipes-security/keyutils/files/fix_library_install_path.patch
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -From b0355cc205543ffd33752874295139d57c4fbc3e Mon Sep 17 00:00:00 2001
> -From: Wenzong Fan 
> -Date: Tue, 26 Sep 2017 07:59:51 +
> -Subject: [PATCH] Subject: [PATCH] keyutils: use relative path for link
> -
> -The absolute path of the symlink will be invalid
> -when populated in sysroot, so use relative path instead.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Jackie Huang 
> -Signed-off-by: Wenzong Fan 
> -{rebased for 1.6]
> -Signed-off-by: Armin Kuster 
> -
> -Index: keyutils-1.6/Makefile
> -===
>  keyutils-1.6.orig/Makefile
> -+++ keyutils-1.6/Makefile
> -@@ -184,7 +184,7 @@ ifeq ($(NO_SOLIB),0)
> - $(INSTALL) -D $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME)
> - $(LNS) $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(SONAME)
> - mkdir -p $(DESTDIR)$(USRLIBDIR)
> --$(LNS) $(LIBDIR)/$(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> -+$(LNS) $(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> - sed \
> - -e 's,@VERSION\@,$(VERSION),g' \
> - -e 's,@prefix\@,$(PREFIX),g' \
> diff --git 
> a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
>  
> b/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
> deleted file mode 100644
> index acd91c01c483..
> --- 
> a/recipes-security/keyutils/files/keyutils-fix-error-report-by-adding-default-message.patch
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -fix keyutils test error report
> -
> -Upstream-Status: Pending
> -
> -"Permission denied" may be the reason of EKEYEXPIRED and EKEYREVOKED.
> -"Required key not available" may be the reason of EKEYREVOKED.
> -EXPIRED and REVOKED are 2 status of kernel security keys features.
> -But the userspace keyutils lib will output the error message, which may
> -have several reasons.
> -
> -Signed-off-by: Han Chao 
> -
> -diff --git a/tests/toolbox.inc.sh b/tests/toolbox.inc.sh
> -index bbca00a..739e9d0 100644
>  a/tests/toolbox.inc.sh
> -+++ b/tests/toolbox.inc.sh
> -@@ -227,11 +227,12 @@ function expect_error ()
> - ;;
> - EKEYEXPIRED)
> - my_err="Key has expired"
> --alt_err="Unknown error 127"
> -+alt_err="Permission denied"
> - ;;
> - EKEYREVOKED)
> - my_err="Key has been revoked"
> --alt_err="Unknown error 128"
> -+alt_err="Permission denied"
> -+alt2_err="Required key not available"
> - ;;
> - EKEYREJECTED)
> - my_err="Key has been rejected"
> -@@ -249,6 +250,9 @@ function expect_error ()
> - elif [ "x$alt_err" != "x" ] && expr "$my_errmsg" : ".*: $alt_err" 
> >&/dev/null
> - then
> - :
> -+elif [ "x$alt2_err" != "x" ] && expr "$my_errmsg" : ".*: $alt2_err" 
> >&/dev/null
> -+then
> -+:
> - elif [ "x$old_err" != "x" ] && expr "$my_errmsg" : ".*: $old_err" 
> >&/dev/null
> - then
> - :
> -
> diff --git 
> a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch 
> b/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
> deleted file mode 100644
> index a4ffd50ce54c..
> --- a/recipes-security/keyutils/files/keyutils-test-fix-output-format.patch
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -From 49b6321368e4bd3cd233d045cd09004ddd7968b2 Mon Sep 17 00:00:00 2001
> -From: Jackie Huang 
> -Date: Mon, 15 May 2017 14:52:00 +0800
> -Subject: [PATCH] keyutils: fix output format
> -
> -keyutils ptest output format is incorrect, according to yocto
> -Development Manual
> 

Re: [yocto] [meta-security-compliance][PATCH 2/4] openscap: add 1.3.1 recipes for upstream source

[Akuster808]

> On Jul 23, 2019, at 02:51, Yi Zhao  wrote:
> 
> Hi Armin,
> 
> 
> I got the following error when build openscap:
> 
> ERROR: openscap-git-r0 do_compile_ptest_base: Function failed: 
> do_compile_ptest_base (log file is located at 
> /buildarea/build/tmp/work/core2-64-poky-linux/openscap/git-r0/temp/log.do_compile_ptest_base.329146)
> ERROR: Logfile of failure stored in: 
> /buildarea/build/tmp/work/core2-64-poky-linux/openscap/git-r0/temp/log.do_compile_ptest_base.329146
> Log data follows:
> | DEBUG: Executing shell function do_compile_ptest_base
> | 
> /buildarea/build/tmp/work/core2-64-poky-linux/openscap/git-r0/temp/run.do_compile_ptest_base.329146:
>  line 108: oe-runcmake: command not found
> | WARNING: 
> /buildarea/build/tmp/work/core2-64-poky-linux/openscap/git-r0/temp/run.do_compile_ptest_base.329146:1
>  exit 127 from 'oe-runcmake tests'
> | ERROR: Function failed: do_compile_ptest_base (log file is located at 
> /buildarea/build/tmp/work/core2-64-poky-linux/openscap/git-r0/temp/log.do_compile_ptest_base.329146)

Thats not good. Thought I had run though this code path.  

I am traveling the next  2 weeks so i am not sure how quickly I can address 
this issue.

Armin
> 
> 
> //Yi
> 
> 
>> On 7/7/19 7:32 AM, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>  .../recipes-openscap/openscap/openscap.inc| 11 +--
>>  .../recipes-openscap/openscap/openscap_1.3.1.bb   | 10 ++
>>  .../recipes-openscap/openscap/openscap_git.bb |  4 ++--
>>  3 files changed, 17 insertions(+), 8 deletions(-)
>>  create mode 100644 
>> meta-security-compliance/recipes-openscap/openscap/openscap_1.3.1.bb
>> 
>> diff --git a/meta-security-compliance/recipes-openscap/openscap/openscap.inc 
>> b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
>> index 4c1f206..e5daaf8 100644
>> --- a/meta-security-compliance/recipes-openscap/openscap/openscap.inc
>> +++ b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
>> @@ -10,10 +10,10 @@ DEPENDS = "autoconf-archive dbus acl bzip2 pkgconfig 
>> gconf procps curl libxml2 l
>>DEPENDS_class-native = "autoconf-archive-native pkgconfig-native 
>> swig-native curl-native libxml2-native libxslt-native dpkg-native 
>> libgcrypt-native nss-native"
>>  -inherit cmake pkgconfig python3native perlnative ptest
>> -
>>  S = "${WORKDIR}/git"
>>  +inherit cmake pkgconfig python3native perlnative ptest
>> +
>>  PACKAGECONFIG ?= "python3 rpm perl"
>>  PACKAGECONFIG[python3] = "-DENABLE_PYTHON3=True, , python3, python3"
>>  PACKAGECONFIG[perl] = "-DENABLE_PERL=True,, perl, perl"
>> @@ -25,7 +25,6 @@ EXTRA_OECONF += "-DENABLE_PROBES_INDEPENDENT=yes 
>> -DENABLE_PROBES_LINUX=yes -DWIT
>>  -DENABLE_OSCAP_UTIL_DOCKER=no \
>>  "
>>  -EXTRA_OECONF_class-native += "-DENABLE_PROBES=True"
>>STAGING_OSCAP_DIR = "${TMPDIR}/work-shared/${MACHINE}/oscap-source"
>>  STAGING_OSCAP_BUILDDIR = 
>> "${TMPDIR}/work-shared/openscap/oscap-build-artifacts"
>> @@ -33,9 +32,9 @@ STAGING_OSCAP_BUILDDIR = 
>> "${TMPDIR}/work-shared/openscap/oscap-build-artifacts"
>>  EXTRANATIVEPATH += "chrpath-native"
>>do_configure_append_class-native () {
>> -sed -i 's:OSCAP_DEFAULT_CPE_PATH.*$:OSCAP_DEFAULT_CPE_PATH 
>> "${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/cpe":' ${S}/config.h
>> -sed -i 's:OSCAP_DEFAULT_SCHEMA_PATH.*$:OSCAP_DEFAULT_SCHEMA_PATH 
>> "${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/schemas":' ${S}/config.h
>> -sed -i 's:OSCAP_DEFAULT_XSLT_PATH.*$:OSCAP_DEFAULT_XSLT_PATH 
>> "${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/xsl":' ${S}/config.h
>> +sed -i 's:OSCAP_DEFAULT_CPE_PATH.*$:OSCAP_DEFAULT_CPE_PATH 
>> "${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/cpe":' ${B}/config.h
>> +sed -i 's:OSCAP_DEFAULT_SCHEMA_PATH.*$:OSCAP_DEFAULT_SCHEMA_PATH 
>> "${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/schemas":' ${B}/config.h
>> +sed -i 's:OSCAP_DEFAULT_XSLT_PATH.*$:OSCAP_DEFAULT_XSLT_PATH 
>> "${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/xsl":' ${B}/config.h
>>  }
>>do_clean[cleandirs] += " ${STAGING_OSCAP_BUILDDIR}"
>> diff --git 
>> a/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.1.bb 
>> b/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.1.bb
>> new file mode 100644
>> index 000..c29fd42
>> --- /dev/null
>> +++ b/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.1.bb
>> @@ -0,0 +1,10 @@
>> +SUMARRY = "NIST Certified SCAP 1.2 toolkit"
>> +
>> +require openscap.inc
>> +
>> +SRCREV = "3a4c635691380fa990a226acc8558db35d7ebabc"
>> +SRC_URI = "git://github.com/OpenSCAP/openscap.git;branch=maint-1.3 \
>> +   file://run-ptest \
>> +"
>> +
>> +DEFAULT_PREFERENCE = "-1"
>> diff --git 
>> a/meta-security-compliance/recipes-openscap/openscap/openscap_git.bb 
>> b/meta-security-compliance/recipes-openscap/openscap/openscap_git.bb
>> index 3dfa99e..aded920 100644
>> --- 

Re: [yocto] [OE-core] RFC: dropping official support for Debian 8 / Opensuse 42.3

[akuster808]

On 7/17/19 1:37 PM, Burton, Ross wrote:
> Hi,
>
> Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer
> formally supported, we think it's time to drop them from the supported
> distribution list.  Initially this involves removing them from the
> SANITY_TESTED_DISTROS list in Poky, at some point during this cycle we
> may remove those distributions from the Yocto Project autobuilder to
> add more workers for other supported distributions.
>
> It is expected that the next release will probably work on those two
> distributions, there are no plans to do new and exciting things
> dropping these unsupported distributions enables -- like increasing
> the minimum Python version to 3.5 until after the 2.8 release in
> October.
>
> Please, if this impacts you, speak up now.

+1
>
> Ross

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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.1.rc1)

[akuster808]

On 7/5/19 12:04 AM, Jain, Sangeeta wrote:
>
> QA cycle report for 2.7.1 RC1:
>
>  
>
>  1. No high milestone defects. 
>  2. Test results are available at following location:
>
>   • For results of all automated tests,
> please refer to results at public AB [1]
>
>   • For other test results, refer to git
> repo " yocto-testresults-contrib" [2]
>
>   • For test report for test cases run by
> Intel and WR team, refer to git repo " yocto-testresults-contrib" [2]
>
>  3. No new defects are found in this cycle. Hardware specific issues
> are observed (Parselog and Xorg failures), but no bugs are filed
> as these are not real Yocto failures.
>  4. ptest failing in this release which were passing in previous
> release – gstreamer[3]. Timeout issues observed in ptest - mdadm [4].
>  5. Summary of ptest in this build:
>
>    qemux86-64-ptest
>
>           Total : 44600
>
>       Pass : 42294
>
>    Fail :  290
>
>      Skip : 2016
>
>       Timeout issues in mdadm
>
> === Links 
>
>  
>
> [1] -
> https://autobuilder.yocto.io/pub/releases/yocto-2.7.1.rc1/testresults/
>
>  
>
> [2] -
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults
>
>  
>
> [3] - [QA 2.7.1.rc1] gstreamer1.0.pipelines/seek ptest failure
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13429
>
Will have to investigate.
>
>  
>
> [4] - mdadm ptest times out
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13368
>
This is known issue and also affects master

Thanks for the report.

- armin
>
>  
>
>  
>
>  
>
> Thanks & Regards,
>
> Sangeeta Jain
>
>  
>
>  Forwarded Message 
>
> *Subject: *
>
>   
>
> QA notification for completed autobuilder build (yocto-2.7.1.rc1)
>
> *Date: *
>
>   
>
> Mon, 1 Jul 2019 03:08:44 +
>
> *From: *
>
>   
>
> Poky Build User 
> 
>
> *To: *
>
>   
>
> yocto@yoctoproject.org 
>
> *CC: *
>
>   
>
> ota...@ossystems.com.br ,
> yi.z...@windriver.com ,
> apoorv.san...@intel.com ,
> ee.peng.y...@intel.com ,
> aaron.chun.yew.c...@intel.com ,
> chin.huat@intel.com ,
> richard.pur...@linuxfoundation.org
> , akuster...@gmail.com
> , sjolley.yp...@gmail.com
> , sangeeta.j...@intel.com
> 
>
>
>
>
> A build flagged for QA (yocto-2.7.1.rc1) was completed on the
> autobuilder and is available at:
>
>
> https://autobuilder.yocto.io/pub/releases/yocto-2.7.1.rc1
>
>
> Build hash information:
> bitbake: 34ed28a412af642a993642c14bd8b95d5ef22cd8
> meta-gplv2: 460ba027fd79b99151f95c826446f3aead5d17ff
> meta-intel: e84c763090f91196a5d234f62ee39bcf296c7f2e
> meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4
> oecore: 886deb4d0919c7a81036ea14fb8fd0f1619dd3a3
> poky: 38d5c8ea98cfa49825c473eba8984c12edf062be
>
>
>
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
>
>

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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.1.rc1)

[akuster808]

On 7/1/19 10:26 PM, Jain, Sangeeta wrote:
>
> Hello All,
>
>  
>
> Intel and WR YP QA is planning for QA execution for YP build 2.7.rc1
>
> We are planning to execute following tests for this cycle:
>

I would like to thank Intel and Wind River for doing QA.

>  
>
> OEQA-manual tests for following module:
>
>  
>
> 1. OE-Core
>
> 2. BSP-hw
>
> 3. BSP-Qemu
>
>  
>
> Runtime auto test for following platforms:
>
>  
>
> 1. MinnowTurbot 32-bit
>
> 2. Coffee Lake
>
> 3. NUC 7
>
> 4. NUC 6
>
> 5. Edgerouter
>
> 6. MPC8315e-rdb
>
> 7. Beaglebone
>
>  
>
> ETA for completion is Friday, 5 July.
>

That sounds great.

Thank you
Armin
>
>  
>
>  
>
> Thanks & Regards,
>
> Sangeeta Jain
>
>  
>
>  
>
>  Forwarded Message 
>
> *Subject: *
>
>   
>
> QA notification for completed autobuilder build (yocto-2.7.1.rc1)
>
> *Date: *
>
>   
>
> Mon, 1 Jul 2019 03:08:44 +
>
> *From: *
>
>   
>
> Poky Build User 
> 
>
> *To: *
>
>   
>
> yocto@yoctoproject.org 
>
> *CC: *
>
>   
>
> ota...@ossystems.com.br ,
> yi.z...@windriver.com ,
> apoorv.san...@intel.com ,
> ee.peng.y...@intel.com ,
> aaron.chun.yew.c...@intel.com ,
> chin.huat@intel.com ,
> richard.pur...@linuxfoundation.org
> , akuster...@gmail.com
> , sjolley.yp...@gmail.com
> , sangeeta.j...@intel.com
> 
>
>
>
>
> A build flagged for QA (yocto-2.7.1.rc1) was completed on the
> autobuilder and is available at:
>
>
> https://autobuilder.yocto.io/pub/releases/yocto-2.7.1.rc1
>
>
> Build hash information:
> bitbake: 34ed28a412af642a993642c14bd8b95d5ef22cd8
> meta-gplv2: 460ba027fd79b99151f95c826446f3aead5d17ff
> meta-intel: e84c763090f91196a5d234f62ee39bcf296c7f2e
> meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4
> oecore: 886deb4d0919c7a81036ea14fb8fd0f1619dd3a3
> poky: 38d5c8ea98cfa49825c473eba8984c12edf062be
>
>
>
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
>
>

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

Re: [yocto] Yocto Project Status WW26'19

[akuster808]

On 6/25/19 10:22 AM, sjolley.yp...@gmail.com wrote:
>
> Current Dev Position: YP 2.8 M2
>
> Next Deadline: YP 2.8 Milestone 2 Cutoff July 14th, 2019
>
>  
>
> SWAT Team Rotation:
>
>   * SWAT lead is currently: Ross
>   * SWAT team rotation: Ross -> Amanda on June 28, 2019
>   * SWAT team rotation: Amanda -> Chen on July, 5, 2019
>
So how do we handle holiday coverage? July 4th is a US holiday.

- armin
>
>  *
>   * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Next Team Meetings:
>
>   * Bug Triage meeting Thursday June 27th at 7:30am PDT
> (https://zoom.us/j/454367603)
>   * Monthly Project Meeting Tuesday July 2nd at 8am PDT
> (https://zoom.us/j/990892712)  
>   * Twitch - Next event is Tuesday 9th July at 8am PDT
> (https://www.twitch.tv/yocto_project)
>
>  
>
> Key Status/Updates:
>
>   * 2.8 M1 has been released.
>   * Mailing lists issues are continuing to be worked on as a top priority.
>   * We have a new “newcomer” bug category which are bugs suited to
> someone new to the project. These can be seen here:
> https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
>   * Several key reproducibility fixes have merged, thanks Joshua!
>   * The autobuilder has suffered stability issues with its NFS setup,
> seemingly related to the increased load from the new servers.
> We’re monitoring changes, hoping they fix the issue.
>   * We had significant problems with the versioning of libcrypt in
> recent distros which resulted in the need for a new uninative
> release. This fixes autobuilder builds.
>
>  
>
> Planned Releases for YP 2.8:
>
>   * M2 Cutoff 14th July
>   * M2 Release 26th July
>   * M3 Cutoff (Feature Freeze) 25th Aug
>   * M3 Release 6th Sept
>   * M4 Cutoff 30th Sept
>   * 2.8 (M4) Final Release 25th Oct
>
>  
>
> Planned upcoming dot releases:
>
>   * YP 2.7.1 (Warrior) is planned for build imminently now that 2.8 M1
> is done but is pending the new uninative changes.
>   * YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
> before 2.8 M2
>
>  
>
> Tracking Metrics:
>
>   * WDD 2482 (last week
> 2479)(https://wiki.yoctoproject.org/charts/combo.html)
>   * Poky Patch Metrics  
>   o Total patches found: 1509 (last week 1511)
>   o Patches in the Pending State: 638 (42%) [last week 641 (43%)]
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
> Thanks,
>
>  
>
> */Stephen K. Jolley/**//*
>
> *Yocto Project Project Manager*
>
> (    *Cell*:    (208) 244-4460
>
> * *Email*:  _sjolley.yp...@gmail.com
> _
>
>  
>
>

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

[yocto] update-rc.d 0.9 request

[akuster808]

Is is possible to bump the version of update-rc.d
 to 0.9 ? New
functionality was added after 0.8 and a simple hash makes version
control harder.

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

Re: [yocto] [PATCH][yocto-docs] ref-manual: Corrected openSUSE essential packages

[akuster808]

On 6/6/19 4:46 PM, Michael Halstead wrote:
> Some packages were bumped onto the pip3 install line. Install them with 
> zypper as before.
>
> Signed-off-by: Michael Halstead 
> ---

is this too early to Ping?

is there an issue with this patch?

-armin
>  documentation/poky.ent | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/documentation/poky.ent b/documentation/poky.ent
> index b5f600969..a436d9027 100644
> --- a/documentation/poky.ent
> +++ b/documentation/poky.ent
> @@ -68,8 +68,8 @@
>   python3-jinja2 SDL-devel xterm">
>   make wget python-xml \
>   diffstat makeinfo python-curses patch socat python3 python3-curses tar 
> python3-pip \
> - python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> - $ sudo pip3 install GitPython libSDL-devel xterm">
> + python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm
> + $ sudo pip3 install GitPython">
> $ sudo yum makecache
>   $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl 
> patch \

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

Re: [yocto] [meta-security][PATCH 1/2] oe-selftest: add running cve checker

[akuster808]

Chen,

On 6/14/19 1:13 AM, ChenQi wrote:
> Hi Armin,
>
> I just noticed this selftest case.
> Have you considered putting it into oe-core?
Yes I have. That was the first place I wanted to put it but Richard and
Ross have reservations about doing that so it sits in meta-security
until we can get it into core.

Regards,
armin


>
> Best Regards,
> Chen Qi
>
> On 05/10/2019 11:09 AM, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>   lib/oeqa/selftest/cases/cvechecker.py | 27 +++
>>   1 file changed, 27 insertions(+)
>>   create mode 100644 lib/oeqa/selftest/cases/cvechecker.py
>>
>> diff --git a/lib/oeqa/selftest/cases/cvechecker.py
>> b/lib/oeqa/selftest/cases/cvechecker.py
>> new file mode 100644
>> index 000..23ca7d2
>> --- /dev/null
>> +++ b/lib/oeqa/selftest/cases/cvechecker.py
>> @@ -0,0 +1,27 @@
>> +import os
>> +import re
>> +
>> +from oeqa.selftest.case import OESelftestTestCase
>> +from oeqa.utils.commands import bitbake, get_bb_var
>> +
>> +class CveCheckerTests(OESelftestTestCase):
>> +    def test_cve_checker(self):
>> +    image = "core-image-sato"
>> +
>> +    deploy_dir = get_bb_var("DEPLOY_DIR_IMAGE")
>> +    image_link_name = get_bb_var('IMAGE_LINK_NAME', image)
>> +
>> +    manifest_link = os.path.join(deploy_dir, "%s.cve" %
>> image_link_name)
>> +
>> +    self.logger.info('CVE_CHECK_MANIFEST = "%s"' % manifest_link)
>> +    if (not 'cve-check' in get_bb_var('INHERIT')):
>> +    add_cve_check_config = 'INHERIT += "cve-check"'
>> +    self.append_config(add_cve_check_config)
>> +    self.append_config('CVE_CHECK_MANIFEST = "%s"' % manifest_link)
>> +    result = bitbake("-k -c cve_check %s" % image,
>> ignore_status=True)
>> +    if (not 'cve-check' in get_bb_var('INHERIT')):
>> +    self.remove_config(add_cve_check_config)
>> +
>> +    isfile = os.path.isfile(manifest_link)
>> +    self.assertEqual(True, isfile, 'Failed to create cve data
>> file : %s' % manifest_link)
>> +
>
>

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

Re: [yocto] [meta-security][master][warrior][PATCH 0/3] python-scapy:solved the conflict with python3-scapy

[akuster808]

On 6/10/19 12:24 AM, Zang Ruochen wrote:
> -Remove redundant sed operations.
>
> -Rename conflicting files to resolve conflicts.
merged to master.

working on warrior

thanks,
- armin
>
>
> Zang Ruochen (3):
>   [yocto][meta-security][master][warrior][PATCH 1/3] python-scapy: Remove
> redundant sed operations
>   [yocto][meta-security][master][warrior][PATCH 2/3] python-scapy: solved
> the conflict with python3-scapy
>   [yocto][meta-security][master][warrior][PATCH 3/3] python3-scapy: solved
> the conflict with python-scapy
>
>  recipes-security/scapy/python-scapy.inc   | 7 ---
>  recipes-security/scapy/python-scapy_2.4.2.bb  | 5 +
>  recipes-security/scapy/python3-scapy_2.4.2.bb | 4 
>  3 files changed, 9 insertions(+), 7 deletions(-)
>

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

Re: [yocto] [meta-security] AppArmor 2.11 no longer available on Ubuntu archive (sumo branch)

[akuster808]

On 6/7/19 3:09 AM, Burton, Ross wrote:
> That is deliberate and by design, recipes shouldn't fetch from
> Debian/Ubuntu archives for this reason.
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
> is a patch to master that needs to be backported to warrior/thud/sumo.

working on propagating this change to the other branches.

- armin
>
> Ross
>
> On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy)
>  wrote:
>> We are building with meta-security (from sumo branch) which currently uses 
>> v2.11 of AppArmor, it seems overnight that the source archive has been 
>> removed from the Ubuntu archives. Does anyone know if this is a deliberate 
>> action, or if not who to contact to get it put back.
>>
>>
>>
>> Peter Smith
>>
>>
>>
>> Senior Emerging Technologies Engineer
>>
>> Grid Solutions
>>
>> GE Renewable Energy
>>
>>
>>
>> -NON PUBLIC-
>>
>>
>>
>>
>>
>>
>>
>> --
>> ___
>> 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][yocto-docs] ref-manual: Corrected openSUSE essential packages

[akuster808]

On 6/7/19 4:19 PM, Michael Halstead wrote:
>
>
> On Thu, Jun 6, 2019 at 5:07 PM akuster808  <mailto:akuster...@gmail.com>> wrote:
>
>
>
> On 6/6/19 4:46 PM, Michael Halstead wrote:
> > Some packages were bumped onto the pip3 install line. Install
> them with zypper as before.
> with backport? ie is Warrior or Thud affected, I suspect so
>
>
> Yes for Warrior. Thud is fine.
>
> Is there anything I need to do for the Warrior backport?
nope. i will handle this.

thanks,
Armin
>  
>
>
> - armin
> >
> > Signed-off-by: Michael Halstead  <mailto:mhalst...@linuxfoundation.org>>
> > ---
> >  documentation/poky.ent | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/documentation/poky.ent b/documentation/poky.ent
> > index b5f600969..a436d9027 100644
> > --- a/documentation/poky.ent
> > +++ b/documentation/poky.ent
> > @@ -68,8 +68,8 @@
> >       python3-jinja2 SDL-devel xterm">
> >   git chrpath make wget python-xml \
> >       diffstat makeinfo python-curses patch socat python3
> python3-curses tar python3-pip \
> > -     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> > -     $ sudo pip3 install GitPython libSDL-devel xterm">
> > +     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> libSDL-devel xterm
> > +     $ sudo pip3 install GitPython">
> >   >       $ sudo yum makecache
> >       $ sudo yum install gawk make wget tar bzip2 gzip python
> unzip perl patch \
>
>

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

Re: [yocto] [meta-security] AppArmor 2.11 no longer available on Ubuntu archive (sumo branch)

[akuster808]

On 6/7/19 3:09 AM, Burton, Ross wrote:
> That is deliberate and by design, recipes shouldn't fetch from
> Debian/Ubuntu archives for this reason.
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
> is a patch to master that needs to be backported to warrior/thud/sumo.
should poke that maintainer ; )


>
> Ross
>
> On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy)
>  wrote:
>> We are building with meta-security (from sumo branch) which currently uses 
>> v2.11 of AppArmor, it seems overnight that the source archive has been 
>> removed from the Ubuntu archives. Does anyone know if this is a deliberate 
>> action, or if not who to contact to get it put back.
>>
>>
>>
>> Peter Smith
>>
>>
>>
>> Senior Emerging Technologies Engineer
>>
>> Grid Solutions
>>
>> GE Renewable Energy
>>
>>
>>
>> -NON PUBLIC-
>>
>>
>>
>>
>>
>>
>>
>> --
>> ___
>> 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][yocto-docs] ref-manual: Corrected openSUSE essential packages

[akuster808]

On 6/6/19 4:46 PM, Michael Halstead wrote:
> Some packages were bumped onto the pip3 install line. Install them with 
> zypper as before.
with backport? ie is Warrior or Thud affected, I suspect so

- armin
>
> Signed-off-by: Michael Halstead 
> ---
>  documentation/poky.ent | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/documentation/poky.ent b/documentation/poky.ent
> index b5f600969..a436d9027 100644
> --- a/documentation/poky.ent
> +++ b/documentation/poky.ent
> @@ -68,8 +68,8 @@
>   python3-jinja2 SDL-devel xterm">
>   make wget python-xml \
>   diffstat makeinfo python-curses patch socat python3 python3-curses tar 
> python3-pip \
> - python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> - $ sudo pip3 install GitPython libSDL-devel xterm">
> + python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm
> + $ sudo pip3 install GitPython">
> $ sudo yum makecache
>   $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl 
> patch \

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

Re: [yocto] [PATCH] samhain: add rconflict for client and server mode

[akuster808]

On 5/27/19 7:37 PM, changqing...@windriver.com wrote:
> From: Changqing Li 
>
> Signed-off-by: Changqing Li 

merged. 

thanks,
Armin
> ---
>  recipes-ids/samhain/samhain-client_4.3.2.bb | 1 +
>  recipes-ids/samhain/samhain-server_4.3.2.bb | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/recipes-ids/samhain/samhain-client_4.3.2.bb 
> b/recipes-ids/samhain/samhain-client_4.3.2.bb
> index 812408e..0f53a8c 100644
> --- a/recipes-ids/samhain/samhain-client_4.3.2.bb
> +++ b/recipes-ids/samhain/samhain-client_4.3.2.bb
> @@ -9,3 +9,4 @@ EXTRA_OECONF += " \
>  "
>  
>  RDEPENDS_${PN} = "acl zlib attr bash"
> +RCONFLICTS_${PN} = "samhain-standalone"
> diff --git a/recipes-ids/samhain/samhain-server_4.3.2.bb 
> b/recipes-ids/samhain/samhain-server_4.3.2.bb
> index 9341d44..d304912 100644
> --- a/recipes-ids/samhain/samhain-server_4.3.2.bb
> +++ b/recipes-ids/samhain/samhain-server_4.3.2.bb
> @@ -18,3 +18,4 @@ do_install_append() {
>  }
>  
>  RDEPENDS_${PN} += "gmp bash perl"
> +RCONFLICTS_${PN} = "samhain-standalone"

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

Re: [yocto] [meta-security][PATCH] python3-fail2ban: Fix build error of xrange.

[akuster808]

On 5/20/19 11:57 PM, Lei, Maohui wrote:
> ping

Merged

thanks.

>> -Original Message-
>> From: Lei, Maohui
>> Sent: Friday, April 19, 2019 11:59 AM
>> To: yocto@yoctoproject.org
>> Cc: Lei, Maohui
>> Subject: [yocto] [meta-security][PATCH] python3-fail2ban: Fix build error of
>> xrange.
>>
>> NameError: name 'xrange' is not defined
>>
>> Signed-off-by: Lei Maohui 
>> ---
>>  .../files/0001-To-fix-build-error-of-xrang.patch   | 28 
>> ++
>>  .../fail2ban/python3-fail2ban_0.10.4.0.bb  |  4 
>>  2 files changed, 32 insertions(+)
>>  create mode 100644 
>> recipes-security/fail2ban/files/0001-To-fix-build-error-of-
>> xrang.patch
>>
>> diff --git a/recipes-security/fail2ban/files/0001-To-fix-build-error-of-
>> xrang.patch b/recipes-security/fail2ban/files/0001-To-fix-build-error-of-
>> xrang.patch
>> new file mode 100644
>> index 000..7f0812c
>> --- /dev/null
>> +++ b/recipes-security/fail2ban/files/0001-To-fix-build-error-of-xrang.patch
>> @@ -0,0 +1,28 @@
>> +From fe3436d65518099d35c643848cba50253abc249c Mon Sep 17 00:00:00 2001
>> +From: Lei Maohui 
>> +Date: Thu, 9 May 2019 14:44:51 +0900
>> +Subject: [PATCH] To fix build error of xrange.
>> +
>> +NameError: name 'xrange' is not defined
>> +
>> +Signed-off-by: Lei Maohui 
>> +---
>> + fail2ban/__init__.py | 2 +-
>> + 1 file changed, 1 insertion(+), 1 deletion(-)
>> +
>> +diff --git a/fail2ban/__init__.py b/fail2ban/__init__.py
>> +index fa6dcf7..61789a4 100644
>> +--- a/fail2ban/__init__.py
>>  b/fail2ban/__init__.py
>> +@@ -82,7 +82,7 @@ strptime("2012", "%Y")
>> +
>> + # short names for pure numeric log-level ("Level 25" could be truncated by
>> short formats):
>> + def _init():
>> +-   for i in xrange(50):
>> ++   for i in range(50):
>> +if logging.getLevelName(i).startswith('Level'):
>> +logging.addLevelName(i, '#%02d-Lev.' % i)
>> + _init()
>> +--
>> +2.7.4
>> +
>> diff --git a/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb 
>> b/recipes-
>> security/fail2ban/python3-fail2ban_0.10.4.0.bb
>> index 5c887e8..23ef027 100644
>> --- a/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
>> +++ b/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
>> @@ -2,3 +2,7 @@ inherit setuptools3
>>  require python-fail2ban.inc
>>
>>  RDEPENDS_${PN}-ptest = "python3-core python3-io python3-modules python3-
>> fail2ban"
>> +
>> +SRC_URI += " \
>> +file://0001-To-fix-build-error-of-xrang.patch \
>> +"
>> --
>> 2.7.4
>
>

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

Re: [yocto] [OE-core] Yocto Project Status WW21'19

[akuster808]

On 5/21/19 7:38 AM, Richard Purdie wrote:
>
> Current Dev Position: YP 2.8 M1
>
> Next Deadline: YP 2.8 Milestone 1 Cutoff June 9th, 2019
>
>
> SWAT Team Rotation:
>
>  *
>
> SWAT lead is currently: Ross
>
>  *
>
> SWAT team rotation: Ross -> Chen on May. 24, 2019
>
>  *
>
> SWAT team rotation: Chen -> Armin on May. 31, 2019
>
>  *
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>
> Next Team Meetings:
>
>  *
>
> Bug Triage meeting Thursday May 23rd at 7:30am PDT
> (https://zoom.us/j/454367603)
>
>  *
>
> Monthly Project Meeting Tuesday June 4th at 8am PDT
> (https://zoom.us/j/990892712) 
>
>
> Key Status/Updates:
>
>  *
>
> Stephen is going to be unavailable for several weeks, please refer
> any queries to Richard
>
>  *
>
> Mailing lists are moving to groups.io instead of our current
> mailman setup on 27th May. This shouldn’t impact users directly,
> more details will be sent to the mailing lists in due course.
>
>  *
>
> We have a new “newcomer” bug category which are bugs suited to
> someone new to the project. These can be seen here:
> https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
>
>  *
>
> Work is continuing to improve the ptest reliability with a focus
> now on ensuring the dependencies are correct.
>
>
>
> Planned Releases for YP 2.8:
>
>  *
>
> M1 Cutoff June 9th
>
>  *
>
> M1 Release June 21st
>
>  *
>
> M2 Cutoff 14th July
>
>  *
>
> M2 Release 26th July
>
>  *
>
> M3 Cutoff (Feature Freeze) 25th Aug
>
>  *
>
> M3 Release 6th Sept
>
>  *
>
> M4 Cutoff 30th Sept
>
>  *
>
> 2.8 (M4) Final Release 25th Oct
>
>
> Planned upcoming dot releases:
>
>  *
>
> YP 2.6.3 (Thud) is in planning
>
>  *
>
> YP 2.7.1 (Warrior) is in planning
>

I would like to work on some target dates and whether we to them before
or after the new uninative for FC30.

- armin
>
>
> Tracking Metrics:
>
>  *
>
> WDD 2559 (last week
> 2596)(https://wiki.yoctoproject.org/charts/combo.html)
>
>  *
>
> Poky Patch Metrics  
>
>  o
>
> Total patches found: 1531 (last week 1560)
>
>  o
>
> Patches in the Pending State: 654 (43%) [last week 665 (43%)]
>
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status
> 
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule
> 
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
> 
>
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>

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

Re: [yocto] [meta-security][PATCH] keyutils: fix library install path

[akuster808]

On 5/17/19 1:20 PM, Martin Jansa wrote:
> When you're on it, can you please check if it works with multilib?
>
> I think $(USRLIBDIR) doesn't respect ${libdir} from OE, so it always
> installs the library to /usr/lib instead of e.g. /usr/lib64 with
> multlilib.

Thank,

Will do.

- armin
>
> e.g. recipes-security/ccs-tools/ccs-tools_1.8.4.bb
>  is setting USRLIBDIR=${libdir}, I guess
> keyutils needs the same.
>
> On Fri, May 17, 2019 at 6:46 PM Armin Kuster  > wrote:
>
> Signed-off-by: Armin Kuster  >
> ---
>  .../files/fix_library_install_path.patch      | 28
> +++
>  recipes-security/keyutils/keyutils_1.6.bb
>      |  1 +
>  2 files changed, 29 insertions(+)
>  create mode 100644
> recipes-security/keyutils/files/fix_library_install_path.patch
>
> diff --git
> a/recipes-security/keyutils/files/fix_library_install_path.patch
> b/recipes-security/keyutils/files/fix_library_install_path.patch
> new file mode 100644
> index 000..938fe2e
> --- /dev/null
> +++ b/recipes-security/keyutils/files/fix_library_install_path.patch
> @@ -0,0 +1,28 @@
> +From b0355cc205543ffd33752874295139d57c4fbc3e Mon Sep 17 00:00:00
> 2001
> +From: Wenzong Fan  >
> +Date: Tue, 26 Sep 2017 07:59:51 +
> +Subject: [PATCH] Subject: [PATCH] keyutils: use relative path for
> link
> +
> +The absolute path of the symlink will be invalid
> +when populated in sysroot, so use relative path instead.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Jackie Huang  >
> +Signed-off-by: Wenzong Fan  >
> +{rebased for 1.6]
> +Signed-off-by: Armin Kuster  >
> +
> +Index: keyutils-1.6/Makefile
> +===
> +--- keyutils-1.6.orig/Makefile
>  keyutils-1.6/Makefile
> +@@ -184,7 +184,7 @@ ifeq ($(NO_SOLIB),0)
> +       $(INSTALL) -D $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME)
> +       $(LNS) $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(SONAME)
> +       mkdir -p $(DESTDIR)$(USRLIBDIR)
> +-      $(LNS) $(LIBDIR)/$(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> ++      $(LNS) $(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> +       sed \
> +       -e 's,@VERSION\@,$(VERSION),g' \
> +       -e 's,@prefix\@,$(PREFIX),g' \
> diff --git a/recipes-security/keyutils/keyutils_1.6.bb
> 
> b/recipes-security/keyutils/keyutils_1.6.bb 
> index c961fa2..2968a24 100644
> --- a/recipes-security/keyutils/keyutils_1.6.bb
> 
> +++ b/recipes-security/keyutils/keyutils_1.6.bb
> 
> @@ -19,6 +19,7 @@ SRC_URI =
> "http://people.redhat.com/dhowells/keyutils/${BP}.tar.bz2
>  \
>             file://keyutils-test-fix-output-format.patch \
>            
> file://keyutils-fix-error-report-by-adding-default-message.patch \
>             file://run-ptest \
> +           file://fix_library_install_path.patch \
>             "
>
>  SRC_URI[md5sum] = "191987b0ab46bb5b50efd70a6e6ce808"
> -- 
> 2.17.1
>
> -- 
> ___
> 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] patchwork

[akuster808]

ok, so no Admins. This is unexceptionable.

OE TSC and Board, I believe its your time to get involved.

regards,
Armin

On 5/3/19 10:18 AM, akuster808 wrote:
> Hello OE folk,
>
> My apologies for cross posting.
>
> Who is the Admin for Patchwork?
>
> I would like additional privileges to manage the "Yocto Project Layers"
> queue.
>
> Also, I would like additional  privileges to add new branches for any
> oe, meta-oe queues & yp layers.
>
> kind regards,
> Armin
>

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

Re: [yocto] [yocto-infrastructure] Upcoming network outage: Fri, May 17 starting 10PM PDT (Sat, 5:00Z)

[akuster808]

On 5/10/19 4:21 PM, Michael Halstead wrote:
> What: 30-minute network outage to Portland-hosted services
> When: Fri, May 17, between 10PM-3AM PDT (Sat, 05:00-10:00 UTC)
> Why : Network equipment replacement by our service provider
>
> Services Impacted:  autobuilder.yoctoproject.org
> , downloads.yoctoproject.org
> , sstate.yoctoproject.org
> 
>
> Our Portland hosting provider needs to replace some of their main 
> network equipment, which will require rerunning some cables. They are 
> asking us to prepare for up to a 30-minute network outage between the 
> hours listed above in order to complete this work.

Thanks for the heads up.

Is there a time on Sat that if things are not back to normal that we
should contact you? I hope and don't expect you to be working @ 3am.

regards,
Armin
>
> -- 
> Michael Halstead
> Linux Foundation / SysAdmin
>
>

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

Re: [yocto] SDK build fails at latest thud

[akuster808]

Teemu,



On 5/1/19 11:50 PM, Teemu K wrote:
> On Thu, Mar 28, 2019 at 6:36 AM Teemu K  wrote:
>> On Mon, Mar 18, 2019 at 7:21 AM Teemu K  wrote:
>>> On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:


 On 3/13/19 9:50 PM, Teemu K wrote:

 Hi,

 I noticed that when trying to build sdk on thud it fails on latest
 version. Actually it broke somewhere between commits:

 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)

 I'm using it with meta-freescale - layer to build image to iMX8.

 I'm using command 'populate_sdk' and it works fine on older version,
 but newer version it fails with error:

 Can you provide the steps to reproduce?
>>> bitbake my-image-name -c populate_sdk
>>>
 ==
 The following packages have unmet dependencies:
  target-sdk-provides-dummy : Conflicts: coreutils
 E: Unable to correct problems, you have held broken packages.


 There is a change sitting in stable/thud-next:

 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next=af5cf78b275ab5226354337d25d8dc1c41a08904

 which might be related. Can you try that branch?

 git://git.yoctoproject.org/poky-contrib  stable/thud-next
>>> That did not solve the problem. I have coreutils in my image and it
>>> kept conflicting. When I removed coreutils from my image it solved
>>> that problem, but there were some problems with perl etc. From the
>>> working version all those are missing from
>>> target-sdk-provices-dummy.bb and my original image works just fine.
>> I see that thud-branch has gotten even more 'fixes' for this sdk thing
>> in last week, but the actual problem still stays. If image-recipe uses
>> coreutils - recipe sdk build fails there because
>> target-sdk-provides-dummy.bb has it listed. And if I remove that then
>> it fails on next package.In my case it's bash-dev.
>>
>> Does those changes need something different how sdk is build or how to
>> build sdk with those changes? I'm not sure why they are listed there
>> in the first place if it overrides the actual package and does not
>> provide 'dummy' if/when needed.
>>
>> To create sdk I use this command: bitbake  -c populate_sdk
>>
>> -Teemu
> I updated to latest thud and this is still an issue. Isn't anyone else
> building sdk or what I'm doing wrong?
>
> I use command: bitbake  -c populate_sdk to generate sdk.
>
> With unedited poky - meta layer it stops at error:
>
> --
> The following packages have unmet dependencies:
>  target-sdk-provides-dummy : Conflicts: coreutils
> --
>
> If I remove that from poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb
>
> The next error is:
> --
> The following packages have unmet dependencies:
>  apt-dev : Depends: apt (= 1.2.24-r0) but it is not going to be installed
>Recommends: bash-dev
> --
>
> If I remove that from file mentioned before the next error is about
> perl-dev. If I remove that it ends up on this error:
>
> --
>
> The following packages have unmet dependencies:
>  target-sdk-provides-dummy-dev : Depends: target-sdk-provides-dummy (=
> 1.0-r0) but it is not going to be installed
> --
>
> For testing purposes I removed everything from that file except bash
> and after that the sdk generated just fine.
>
> I don't know enough about yocto/poky so what is the use of this
> target-sdk-provides-dummy thingie and why things are added there that
> keep breaking the sdk generation or do I need to generate sdk now
> someway differently? Atm. I'm either stuck on that older thud -
> version or I have to manually edit this
> target-sdk-provides-dummy-dev.bb - file.

Can you log a bug. We are not seeing this in the AutoBuilders.

https://bugzilla.yoctoproject.org/
>
> -Teemu

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

[yocto] patchwork

[akuster808]

Hello OE folk,

My apologies for cross posting.

Who is the Admin for Patchwork?

I would like additional privileges to manage the "Yocto Project Layers"
queue.

Also, I would like additional  privileges to add new branches for any
oe, meta-oe queues & yp layers.

kind regards,
Armin

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

Re: [yocto] [OE-core] QA cycle report for 2.7 RC2

[akuster808]

Sangeeta,


On 4/25/19 11:27 PM, Jain, Sangeeta wrote:
>
>  
>
> QA cycle reportfor 2.7 RC2:
>
>  
>
>  1. No high milestone defects. 
>  2. Test results are available at following location:
>
> ·    For results of all automated tests, please refer to results
> at public AB [1].
>
> ·    For other test results, refer to attachment [2].
>
> ·    For test report for test cases run by Intel and WR team,
> refer attachment [3]
>
Since "compliance-test.compliance-test.LSB_subset_test_suite" was run,
can you share the changes made to /opt/lsb-test/session file?

||

Can I get clarification on how
"compliance-test.compliance-test.stress_test_-_ltp_-Beaglebone" was run?

Regards,
Armin
>
> ·    For full test report, refer attachment [4]
>
>  3. No new defects are found in this cycle.
>  4. No existing issues observed in this release
>  5. No ptests are failing in this release which were passing in
> previous release. No timeout issues.
>
>  
>
> QA Hint: One failure was observed on public AB:
>
>  
>
> testseries | result_id : qemuppc |
> oeselftest_centos-7_qemuppc_20190414221329
>
> runqemu.QemuTest.test_qemu_can_shutdown
>
>  
>
> No bug filed for this issue, as it appears to be an intermittent
> failure and worked on rc1 test run.
>
>  
>
> === Links
>
>  
>
> *Link to testresults:*
>
>  
>
> [1] - https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc2/testresults/
>
>  
>
> [2] - 2.7_RC2_results_merged.zip
>
>  
>
> [3] - 2.7_ rc2_intel_wr_merged_report
>
>  
>
> [4] – 2.7 _rc2_full_report
>
>  
>
> Thanks & Regards,
>
> Sangeeta Jain
>
>  
>
>

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

Re: [yocto] [OE-core] QA cycle report for 2.5.3 RC3

[akuster808]

On 4/23/19 7:35 AM, richard.pur...@linuxfoundation.org wrote:
> On Thu, 2019-04-18 at 04:58 +, Jain, Sangeeta wrote:
>>  
>> QA cycle report for 2.5.3 RC3:
>>  
>> No high milestone defects. 
>> Test results are available at following location:
>> ·For results of all automated tests, refer to results at
>> public AB [1].
>> ·For other test results, refer to attachment [2].
>> ·For test report for test cases run by Intel and WR team,
>> refer attachment [3]
>> ·For full test report, refer attachment [4]
>> ·For ptest results, please refer to results at public AB [5]
>> ·For ptest report, refer to attachment [6]
>> No new defects are found in this cycle.
>> Number of existing issues observed in this release is 2- toaster [7]
>> and Build-appliance [8]
>> For ptest, regression data is not available for this release. No
>> timeout issues.
>> Test result report on Public AB shows no failures.
> I've been discussing with Tracy and Vineela how to best handle the test
> results for the release for 2.5.3. In the end I:
>
> a) Copied in the ptest results to the right place. This will happen
> automagically in all future builds:
>
> https://autobuilder.yocto.io/pub/releases/yocto-2.5.3/testresults/qemux86-64-ptest/
>
> b) Copied in the intel test results to their own directory:
>
> https://autobuilder.yocto.io/pub/releases/yocto-2.5.3/testresults-intel/
>
> c) Manually generated an updated test report for the combined results
> with the commands:
>
> $ cd /srv/autobuilder/autobuilder.yoctoproject.org/pub/releases/yocto-
> 2.5.3
> $resulttool report . > testreport.txt
>
> d) Added a header to the report which consisted of the report from QA
> with details of the bugs etc.
>
> This means we have a top level testreport file which contains all the
> test information about the release.
>
> I'd like to make this the standard procedure for release. The release
> notes and announcement can refer to the test report included with the
> release and the test results as its there all together.
>
> Ultimately I'd like to improve the formatting of the report (separate
> out ptest regressions from the other regressions, maybe html, maybe
> graphs, better regression information) but that is something for the
> future.
>
> Does that work for everyone?
This works for me.

- armin
>
> Cheers,
>
> Richard
>
>

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

Re: [yocto] [OE-core] Eclipse support dropped with immediate effect

[akuster808]

On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote:
> On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote:
>> On 4/9/19 8:52 PM, Richard Purdie wrote:
>>> I'm sorry to have to say this but the project is terminating its
>>> official eclipse plugin support with immediate effect.
>> Does this affect the stable branches as well?
> Yes, I think we'll just be removing the target from the autobuilder
> entirely.

Have we every removed a feature from a release? Do we need to doc this ?

- armin
> Cheers,
>
> Richard
>

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

Re: [yocto] [sumo] [PATCH v1] systemd: fix musl compilation

[akuster808]

On 4/9/19 8:44 PM, Sinan Kaya wrote:
> On 4/9/2019 7:49 AM, akuster wrote:
>> After closer look, I don't the "Upstream-Status:" nor a signoff in the
>> patch being added in the bb file.
>>
>> Does this issue affect later branches ?
>
> I can fix this. The issue was introduced while backporting a CVE patch
> from debian.
>
> So, we are fixing a problem by patching "the patch".
Ah, sorry that didn't register.
>
> We'd squash this into the original CVE under normal circumstances but
> original patch has been already checked in.
>
> Can I assume that upstream status would be "inappropriate"?
Its not applicable in this case.

Maybe a note for the patch and your signoff seems more than enough
unless the broader community has an issue with that. .

thanks,
Armin
>
> I can add these tags once we reach to an agreement.


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

Re: [yocto] [OE-core] Eclipse support dropped with immediate effect

[akuster808]

On 4/9/19 8:52 PM, Richard Purdie wrote:
> I'm sorry to have to say this but the project is terminating its
> official eclipse plugin support with immediate effect.

Does this affect the stable branches as well?

- armin
>
> There is nobody willing to keep the builds going, fix bugs, port to new
> eclipse releases or release the current plugin. This has been raised in
> many forums, multiple times and nobody stepped up to help. With nobody
> to do the work, we can't keep it going, it is that simple.
>
> We'll be removing the automated testing of the eclipse plugin from the
> autobuilder with immediate effect for all project releases.
>
> Richard
>
>
>

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

Re: [yocto] [poky] [PATCH] poky-tiny: set 5.0 as the preferred kernel

[akuster808]

On 4/9/19 9:09 PM, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
>
> Updating poky-tiny to prefer 5.0 as the kernel version. Boot
> tested against qemux86 and qemuarm. This removes the last user
> of the 4.18 kernel, so we can queue it for removal from master.
Thanks Bruce.

- Armin
>
> Signed-off-by: Bruce Ashfield 
> ---
>  meta-poky/conf/distro/poky-tiny.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-poky/conf/distro/poky-tiny.conf 
> b/meta-poky/conf/distro/poky-tiny.conf
> index 690cb0d5c9..243d492918 100644
> --- a/meta-poky/conf/distro/poky-tiny.conf
> +++ b/meta-poky/conf/distro/poky-tiny.conf
> @@ -38,7 +38,7 @@ TCLIBC = "musl"
>  # Distro config is evaluated after the machine config, so we have to 
> explicitly
>  # set the kernel provider to override a machine config.
>  PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
> -PREFERRED_VERSION_linux-yocto-tiny ?= "4.18%"
> +PREFERRED_VERSION_linux-yocto-tiny ?= "5.0%"
>  
>  # We can use packagegroup-core-boot, but in the future we may need a new 
> packagegroup-core-tiny
>  #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"

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

Re: [yocto] [meta-security][PATCH] clamav: freshclam need bind to run

[akuster808]

On 4/7/19 12:46 PM, Adrian Bunk wrote:
> On Sun, Apr 07, 2019 at 11:45:18AM +0530, akuster808 wrote:
>>
>> On 4/7/19 10:42 AM, Adrian Bunk wrote:
>>> On Sun, Apr 07, 2019 at 01:38:38AM +0530, akuster808 wrote:
>>>> On 4/6/19 8:31 PM, Adrian Bunk wrote:
>>>>> On Sat, Apr 06, 2019 at 08:15:40PM +0530, Armin Kuster wrote:
>>>>>> Add it to the rdepends for that package
>>>>>>
>>>>>> Signed-off-by: Armin Kuster 
>>>>>> ---
>>>>>>  recipes-security/clamav/clamav_0.99.4.bb | 2 ++
>>>>>>  1 file changed, 2 insertions(+)
>>>>>>
>>>>>> diff --git a/recipes-security/clamav/clamav_0.99.4.bb 
>>>>>> b/recipes-security/clamav/clamav_0.99.4.bb
>>>>>> index 6219d9e..dbe903f 100644
>>>>>> --- a/recipes-security/clamav/clamav_0.99.4.bb
>>>>>> +++ b/recipes-security/clamav/clamav_0.99.4.bb
>>>>>> @@ -152,3 +152,5 @@ RCONFLICTS_${PN} += "${PN}-systemd"
>>>>>>  SYSTEMD_SERVICE_${PN} = "${BPN}.service"
>>>>>>  
>>>>>>  RDEPENDS_${PN} += "openssl ncurses-libncurses libbz2 ncurses-libtinfo 
>>>>>> clamav-freshclam clamav-libclamav"
>>>>>> +
>>>>>> +RDEPENDS_freshclam = "bind"
>>>>> freshclam depending on a DNS server looks very wrong.
>>>> got talk to clamav folks then.
>>>>
>>>>> What is the actual problem?
>>>> ClamAV update process started at Sat Apr  6 14:59:25 2019
>>>> WARNING: Can't query current.cvd.clamav.net
>>>> WARNING: Invalid DNS reply. Falling back to HTTP mode.
>>>> ERROR: Can't get information about database.clamav.net: Temporary failure 
>>>> in name resolution
>>>> ERROR: Can't download main.cvd from database.clamav.net
>>>> Giving up on database.clamav.net...
>>>>
>>>> because 
>>>>
>>>> Use DNS to verify virus database version. Freshclam uses DNS TXT records
>>>> to verify database and software versions 
>>>>
>>>> therefor I am including bind.
>>> freshclam needing DNS information makes sense, which means it must be 
>>> configured how to access a DNS server.
>>>
>>> On the local machine you need only DNS client funtionality,
>>> just like every user needs for a web browser.
>>> Forcing installation of a DNS server is not the correct solution
>>> when the actual problem is just a configuration issue on the
>>> machine where you were trying it.
>> So I can expect a patch to provide such configuration. I would like to
>> see how you would solve this.
> How are you configuring networking on your device?

I figured it out.
>
>> Maybe an FAQ we can add to the layer for this package?
> From the error message you gave it is not obvious that there is any
> problem that would be specific to this package.
>
> I would guess that DNS configuration is missing or incorrect on your 
> device, and that "ping www.google.com" would also fail with a name 
> resolution error.

The runtime test I added creates a /etc/resolve.conf , that allows me to
ping to the outside but I missed including the local ip ( 127.)   I am
running this two systems to verify this my flurry of changes. One system
in at home on real hardware and other in qemu my laptop while I am
traveling. With that being said, I can drop the bind requirement and I
need to update the runtime test.

I do appreciate the reviews , questions and push back. 

Kind regards,
Armin
>
>> - armin
> cu
> Adrian
>


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

Re: [yocto] [meta-security][PATCH] clamav: freshclam need bind to run

[akuster808]

On 4/7/19 10:42 AM, Adrian Bunk wrote:
> On Sun, Apr 07, 2019 at 01:38:38AM +0530, akuster808 wrote:
>>
>> On 4/6/19 8:31 PM, Adrian Bunk wrote:
>>> On Sat, Apr 06, 2019 at 08:15:40PM +0530, Armin Kuster wrote:
>>>> Add it to the rdepends for that package
>>>>
>>>> Signed-off-by: Armin Kuster 
>>>> ---
>>>>  recipes-security/clamav/clamav_0.99.4.bb | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/recipes-security/clamav/clamav_0.99.4.bb 
>>>> b/recipes-security/clamav/clamav_0.99.4.bb
>>>> index 6219d9e..dbe903f 100644
>>>> --- a/recipes-security/clamav/clamav_0.99.4.bb
>>>> +++ b/recipes-security/clamav/clamav_0.99.4.bb
>>>> @@ -152,3 +152,5 @@ RCONFLICTS_${PN} += "${PN}-systemd"
>>>>  SYSTEMD_SERVICE_${PN} = "${BPN}.service"
>>>>  
>>>>  RDEPENDS_${PN} += "openssl ncurses-libncurses libbz2 ncurses-libtinfo 
>>>> clamav-freshclam clamav-libclamav"
>>>> +
>>>> +RDEPENDS_freshclam = "bind"
>>> freshclam depending on a DNS server looks very wrong.
>> got talk to clamav folks then.
>>
>>> What is the actual problem?
>> ClamAV update process started at Sat Apr  6 14:59:25 2019
>> WARNING: Can't query current.cvd.clamav.net
>> WARNING: Invalid DNS reply. Falling back to HTTP mode.
>> ERROR: Can't get information about database.clamav.net: Temporary failure in 
>> name resolution
>> ERROR: Can't download main.cvd from database.clamav.net
>> Giving up on database.clamav.net...
>>
>> because 
>>
>> Use DNS to verify virus database version. Freshclam uses DNS TXT records
>> to verify database and software versions 
>>
>> therefor I am including bind.
> freshclam needing DNS information makes sense, which means it must be 
> configured how to access a DNS server.
>
> On the local machine you need only DNS client funtionality,
> just like every user needs for a web browser.

>
> Forcing installation of a DNS server is not the correct solution
> when the actual problem is just a configuration issue on the
> machine where you were trying it.

So I can expect a patch to provide such configuration. I would like to
see how you would solve this.
Maybe an FAQ we can add to the layer for this package?

- armin
>> - Armin
> cu
> Adrian
>


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

Re: [yocto] [meta-security][PATCH] clamav: freshclam need bind to run

[akuster808]

On 4/6/19 8:31 PM, Adrian Bunk wrote:
> On Sat, Apr 06, 2019 at 08:15:40PM +0530, Armin Kuster wrote:
>> Add it to the rdepends for that package
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  recipes-security/clamav/clamav_0.99.4.bb | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/recipes-security/clamav/clamav_0.99.4.bb 
>> b/recipes-security/clamav/clamav_0.99.4.bb
>> index 6219d9e..dbe903f 100644
>> --- a/recipes-security/clamav/clamav_0.99.4.bb
>> +++ b/recipes-security/clamav/clamav_0.99.4.bb
>> @@ -152,3 +152,5 @@ RCONFLICTS_${PN} += "${PN}-systemd"
>>  SYSTEMD_SERVICE_${PN} = "${BPN}.service"
>>  
>>  RDEPENDS_${PN} += "openssl ncurses-libncurses libbz2 ncurses-libtinfo 
>> clamav-freshclam clamav-libclamav"
>> +
>> +RDEPENDS_freshclam = "bind"
> freshclam depending on a DNS server looks very wrong.
got talk to clamav folks then.

>
> What is the actual problem?

ClamAV update process started at Sat Apr  6 14:59:25 2019
WARNING: Can't query current.cvd.clamav.net
WARNING: Invalid DNS reply. Falling back to HTTP mode.
ERROR: Can't get information about database.clamav.net: Temporary failure in 
name resolution
ERROR: Can't download main.cvd from database.clamav.net
Giving up on database.clamav.net...

because 

Use DNS to verify virus database version. Freshclam uses DNS TXT records
to verify database and software versions 

therefor I am including bind.

- Armin

> cu
> Adrian
>

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

Re: [yocto] [meta-security][PATCH] clamav: freshclam need bind to run

[akuster808]

sent the wrong version. v2 later

Ill deal with it tomorrow after some much need sleep
-armin

On 4/6/19 8:15 PM, Armin Kuster wrote:
> Add it to the rdepends for that package
>
> Signed-off-by: Armin Kuster 
> ---
>  recipes-security/clamav/clamav_0.99.4.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/recipes-security/clamav/clamav_0.99.4.bb 
> b/recipes-security/clamav/clamav_0.99.4.bb
> index 6219d9e..dbe903f 100644
> --- a/recipes-security/clamav/clamav_0.99.4.bb
> +++ b/recipes-security/clamav/clamav_0.99.4.bb
> @@ -152,3 +152,5 @@ RCONFLICTS_${PN} += "${PN}-systemd"
>  SYSTEMD_SERVICE_${PN} = "${BPN}.service"
>  
>  RDEPENDS_${PN} += "openssl ncurses-libncurses libbz2 ncurses-libtinfo 
> clamav-freshclam clamav-libclamav"
> +
> +RDEPENDS_freshclam = "bind"

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

Re: [yocto] [meta-security][PATCH 2/2] sssd: add DISTRO_FEATURE sssd

[akuster808]

On 4/6/19 12:06 PM, Adrian Bunk wrote:
> On Sat, Apr 06, 2019 at 05:54:35AM +0530, akuster808 wrote:
>>
>> On 4/5/19 1:49 PM, Adrian Bunk wrote:
>>> On Fri, Apr 05, 2019 at 11:05:17AM +0530, akuster808 wrote:
>>>> On 4/5/19 10:29 AM, Adrian Bunk wrote:
>>>>> On Fri, Apr 05, 2019 at 03:47:46AM +0530, Armin Kuster wrote:
>>>>>> Signed-off-by: Armin Kuster 
>>>>>> ---
>>>>>>  recipes-security/sssd/sssd_1.16.4.bb | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/recipes-security/sssd/sssd_1.16.4.bb 
>>>>>> b/recipes-security/sssd/sssd_1.16.4.bb
>>>>>> index 34bc8c8..d6a308c 100644
>>>>>> --- a/recipes-security/sssd/sssd_1.16.4.bb
>>>>>> +++ b/recipes-security/sssd/sssd_1.16.4.bb
>>>>>> @@ -16,7 +16,7 @@ SRC_URI[sha256sum] = 
>>>>>> "6bb212cd6b75b918e945c24e7c3f95a486fb54d7f7d489a9334cfa1a1f
>>>>>>  
>>>>>>  inherit autotools pkgconfig gettext python-dir distro_features_check
>>>>>>  
>>>>>> -REQUIRED_DISTRO_FEATURES = "pam"
>>>>>> +REQUIRED_DISTRO_FEATURES = "pam sssd"
>>>>>> ...
>>>>> Adding a distro feature for a leaf package is wrong.
>>>> Is it a naming issue or something else? I would like to understand so I
>>>> may avoid making the same mistake.
>>> This has nothing to do with naming.
>>> It is about getting rid of workarounds by fixing the root cause,
>>> instead of adding more and more layers of workarounds.
>>>
>>> A DISTRO_FEATURE is for cases where PACKAGECONFIG in many recipes should 
>>> be toggled with one setting, or the setting has to be the same in several
>>> recipes.
>> The definition is old and needs to be updated to modern time. There a
>> plenty of recipes that require libraries the we ended up using this
>> mechanism. Look at the X11 situations. The sssd requires PAM but there
>> is no PAM config option supported in the recipe so I should remove PAM
>> to then?
> X11 and PAM are low-level libraries.
>
> A user might choose to build a distribution without X11 support or 
> without PAM support, and there is no better solution for this.
>
> It is not intended for temporary quick hacks.
>
>>> DISTRO_FEATURES is not appropriate to guard a quick hack workaround for
>>> breakage caused by another workaround.
>> Its being used in the case of mali support.  So I do see value in able
>> to use this mechanism in those cases.
> What are you referring to here?
>
>> I do have another option and that is to supply the previous libldb. This
>> I know is standard practice for other layers.
> I actually wonder why sssd currently requires libldb,
> it does not DEPEND on it so is not built against it.
Its hard coded in the configure. it is in the DEPENDs list in the recipe.

>
>>> The problem at hand is that libldb in meta-openembedded was upgraded to 
>>> a version not compatible with the version of samba in meta-openembedded.
>> And that should not have been allowed IMHO.
> 0001-ldb-Refuse-to-build-Samba-against-a-newer-minor-vers.patch in samba
> seems to have been added to prevent exactly this in the future.
>
>> What is even worse, one can
>> not install libldb onto a system without seen the same issues so it
>> appears no one is using it.
> samba uses the internal version and for sssd it is a non-default
> PACKAGECONFIG.
Correct.

>
>>> As workaroud the libldb shipped in samba was used and installed by 
>>> the samba recipe.
>>>
>>> The proper fix would be to upgrade samba to 4.9 or 4.10,
>>> and use the external libldb again.
>>> This would make all problems caused by having two different versions
>>> of libldb disappear.
>>>
>>> If this is not possible, it is likely samba that should stop just 
>>> shipping the (older versions of) the conflicting binaries for now.
>>>
>>> In a semi-related note, the current samba is a pretty outdated even for
>>> the 4.8 branch and misses several CVE fixes.
>> Make you wonder if folks are using samba.
> using != maintaining
>
> Users tend to use whatever is provided by a stable series,
> and trust that this is properly security supported.
>
> They cannot even notice that samba has not been updated for warrior
> before warrior becomes a stable series and they start using it.
>
> Creating an automated regular report based on cve_check for master and 
> all supported stable series for several layers might be easy enough.
>
> Currently the output would be depressing for master and worse
> for stable branches.
>
> Actually providing security support by providing properly tested fixes
> for master and 2 supported stable series would be full-time work for
> several people.
yep.  Late we have had 3 stable for a short period while the oldest on
gets it last dot release.

Thanks for you input and feedback

kind regards,
- Armin
>
>> - armin
> cu
> Adrian
>


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

Re: [yocto] [meta-security][PATCH 2/2] sssd: add DISTRO_FEATURE sssd

[akuster808]

On 4/5/19 1:49 PM, Adrian Bunk wrote:
> On Fri, Apr 05, 2019 at 11:05:17AM +0530, akuster808 wrote:
>>
>> On 4/5/19 10:29 AM, Adrian Bunk wrote:
>>> On Fri, Apr 05, 2019 at 03:47:46AM +0530, Armin Kuster wrote:
>>>> Signed-off-by: Armin Kuster 
>>>> ---
>>>>  recipes-security/sssd/sssd_1.16.4.bb | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/recipes-security/sssd/sssd_1.16.4.bb 
>>>> b/recipes-security/sssd/sssd_1.16.4.bb
>>>> index 34bc8c8..d6a308c 100644
>>>> --- a/recipes-security/sssd/sssd_1.16.4.bb
>>>> +++ b/recipes-security/sssd/sssd_1.16.4.bb
>>>> @@ -16,7 +16,7 @@ SRC_URI[sha256sum] = 
>>>> "6bb212cd6b75b918e945c24e7c3f95a486fb54d7f7d489a9334cfa1a1f
>>>>  
>>>>  inherit autotools pkgconfig gettext python-dir distro_features_check
>>>>  
>>>> -REQUIRED_DISTRO_FEATURES = "pam"
>>>> +REQUIRED_DISTRO_FEATURES = "pam sssd"
>>>> ...
>>> Adding a distro feature for a leaf package is wrong.
>> Is it a naming issue or something else? I would like to understand so I
>> may avoid making the same mistake.
> This has nothing to do with naming.
> It is about getting rid of workarounds by fixing the root cause,
> instead of adding more and more layers of workarounds.
>
> A DISTRO_FEATURE is for cases where PACKAGECONFIG in many recipes should 
> be toggled with one setting, or the setting has to be the same in several
> recipes.
The definition is old and needs to be updated to modern time. There a
plenty of recipes that require libraries the we ended up using this
mechanism. Look at the X11 situations. The sssd requires PAM but there
is no PAM config option supported in the recipe so I should remove PAM
to then?
>
> DISTRO_FEATURES is not appropriate to guard a quick hack workaround for
> breakage caused by another workaround.
Its being used in the case of mali support.  So I do see value in able
to use this mechanism in those cases.

I do have another option and that is to supply the previous libldb. This
I know is standard practice for other layers.
>
> The problem at hand is that libldb in meta-openembedded was upgraded to 
> a version not compatible with the version of samba in meta-openembedded.

And that should not have been allowed IMHO.  What is even worse, one can
not install libldb onto a system without seen the same issues so it
appears no one is using it.

>
> As workaroud the libldb shipped in samba was used and installed by 
> the samba recipe.
>
> The proper fix would be to upgrade samba to 4.9 or 4.10,
> and use the external libldb again.
> This would make all problems caused by having two different versions
> of libldb disappear.
>
> If this is not possible, it is likely samba that should stop just 
> shipping the (older versions of) the conflicting binaries for now.
>
> In a semi-related note, the current samba is a pretty outdated even for
> the 4.8 branch and misses several CVE fixes.
Make you wonder if folks are using samba.
- armin
>
> cu
> Adrian
>


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

Re: [yocto] Worries kernels supported

[akuster808]

On 4/6/19 5:12 AM, Bruce Ashfield wrote:
> On Thu, Apr 4, 2019 at 5:28 PM akuster808  wrote:
>> Hello,
>>
>> I noticed there are 3 kernels in Warrior. 4.18, 4.19 an 5.0. Do we
>> really need 4.18?
>> I see its the default version for poky-tiny. 4.18 is EOL but maintained
>> by Windriver.
> 4.18 needed to be around through M3 to backstop some layers and references
> that were being updated.
>
> I may delete it as part of M4, but really, since I kept it through M3, I may 
> not
> churn it in M4.  I handle all the support load on the linux-yocto
> reference kernels,
> so it shouldn't cause any one harm one way or the other.
Thanks for the info.

Armin
>
> I keep a very close eye on the versions, so nothing is around by chance or
> by mistake .. and best to just copy me on the email, since I can
> easily miss them
> in the noise.
>
> Bruce
>
>> regards,
>> Armin
>>
>>
>>
>

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

Re: [yocto] [meta-security][PATCH 2/2] sssd: add DISTRO_FEATURE sssd

[akuster808]

On 4/5/19 10:29 AM, Adrian Bunk wrote:
> On Fri, Apr 05, 2019 at 03:47:46AM +0530, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>  recipes-security/sssd/sssd_1.16.4.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-security/sssd/sssd_1.16.4.bb 
>> b/recipes-security/sssd/sssd_1.16.4.bb
>> index 34bc8c8..d6a308c 100644
>> --- a/recipes-security/sssd/sssd_1.16.4.bb
>> +++ b/recipes-security/sssd/sssd_1.16.4.bb
>> @@ -16,7 +16,7 @@ SRC_URI[sha256sum] = 
>> "6bb212cd6b75b918e945c24e7c3f95a486fb54d7f7d489a9334cfa1a1f
>>  
>>  inherit autotools pkgconfig gettext python-dir distro_features_check
>>  
>> -REQUIRED_DISTRO_FEATURES = "pam"
>> +REQUIRED_DISTRO_FEATURES = "pam sssd"
>> ...
> Adding a distro feature for a leaf package is wrong.
Is it a naming issue or something else? I would like to understand so I
may avoid making the same mistake.

- armin
>
> cu
> Adrian
>


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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)

[akuster808]

On 4/5/19 3:25 AM, richard.pur...@linuxfoundation.org wrote:
> On Thu, 2019-04-04 at 02:19 +, Jain, Sangeeta wrote:
>> Also, I don't see any ptest results for 2.6.2.rc3 on public
>> autobuilder. Do you have any plans to run them and share the results
>> on autobuilder?
> These were run separately but will run as part of any new stable
> release builds. The results are here:
>
> https://autobuilder.yocto.io/pub/non-release/20190328-8/testresults/qemux86-64-ptest/
> https://autobuilder.yocto.io/pub/non-release/20190328-7/testresults/qemux86-64-ptest/
>
> (for 2.6.2 and 2.5.4)
>
> I'll merge these into the main release output in due course.
Did I miss something in order to create:
https://autobuilder.yocto.io/pub/non-release/20190326-8/testresults/testresult-report.txt

- Armin
>
> Cheers,
>
> Richard
>

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

[yocto] Worries kernels supported

[akuster808]

Hello,

I noticed there are 3 kernels in Warrior. 4.18, 4.19 an 5.0. Do we
really need 4.18?
I see its the default version for poky-tiny. 4.18 is EOL but maintained
by Windriver.

regards,
Armin



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

Re: [yocto] [OE-core] [oe] Git commit process question.

[akuster808]

On 4/3/19 3:38 AM, Alexander Kanavin wrote:
> Just to make clear, the AUH workflow does require the maintainer to
> sign off and edit a commit message via 'git commit -s --reset-author
> --amend' for every commit, 
Not sure if this a requirement anymore. Most of my packages got updated
by other folks this time around.  Hard to say if the AUH played a part
or are folks now using the devtool check.
> so AUH does not get in the way of useful
> commit messages.
There was talk of using the AUH to fast track updates that pass the
process so in that case the message would be whatever the AUH provides

- armin
>
> Alex
>
> On Wed, 3 Apr 2019 at 12:31, Burton, Ross  wrote:
>> On Tue, 2 Apr 2019 at 20:46, Tom Rini  wrote:
>> pr
 The kernel does not have "upgrade foo to the latest upstream version" 
 commits.

 With the Automatic Upgrade Helper this is a semi-automatic task, and
 most of the time there is no specific motivation other than upgrading
 to the latest upstream version.
>>> But since that's just filling in a template the body can also be a
>>> template perhaps with useful AUH data (run at ... by ... ?) ?
>> Apart from making the commit message longer what does this achieve?
>> The commit already has a timestamp and author.
>>
>> Ross
>> --
>> ___
>> 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] [meta-security][PATCH] samhain: hash fix for aarch64 and mips64

[akuster808]

On 4/3/19 1:55 AM, mingli...@windriver.com wrote:
> From: Mingli Yu 
>
> samhain fails on both aarch64 and mips64 targets with:
> | samhain[3013]: FATAL: x_dnmalloc.c: 2790: hashval < AMOUNTHASH
>
> Though there is already a patch samhain-mips64-aarch64-dnmalloc-hash-fix.patch
> to fix this issue, the logic is incomplete and
> pass -DCONFIG_ARCH_MIPS64=1 and -DCONFIG_ARCH_AARCH64=1
> during do_configure phase respectively to fix the
> issue.
This does not apply. Can you rebase with master.

thanks,
Armin
>
> Signed-off-by: Mingli Yu 
> ---
>  recipes-security/samhain/samhain.inc | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/recipes-security/samhain/samhain.inc 
> b/recipes-security/samhain/samhain.inc
> index dcd72b9..90da813 100644
> --- a/recipes-security/samhain/samhain.inc
> +++ b/recipes-security/samhain/samhain.inc
> @@ -97,6 +97,11 @@ EOF
>  
>  do_configure () {
>   autoconf -f
> + if [ "${TARGET_ARCH}" = "mips64" ]; then
> + export CFLAGS="${CFLAGS} -DCONFIG_ARCH_MIPS64=1"
> + elif [ "${TARGET_ARCH}" = "aarch64" ]; then
> + export CFLAGS="${CFLAGS} -DCONFIG_ARCH_AARCH64=1"
> + fi
>   ./configure \
>   --build=${BUILD_SYS} \
>   --host=${HOST_SYS} \

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

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)

[akuster808]

Hello,

On 4/3/19 1:06 AM, Jain, Sangeeta wrote:
> Intel and WR YP QA is now working on QA execution for YP build 2.6.2 RC3. We 
> are planning to execute following tests for this cycle:
>
> OEQA-Manual tests for following modules:
> 1.SDK
> 2.Eclipse-plugin
> 3.Kernel
> 4.Toaster
> 5.Bitbake (oe-core)
> 6.Build-appliance
> 7.Crops
> 8.Compliance-test
> 9.Bsp-hw
> 10.   Bsp-qemu
I did not backport the manual test from master or thud. Are these the
original set?


regards,
Armin
> Runtime auto test for following platforms:
>
> 1.MinnowTurbo 32bit
> 2.MinnowTurbot 64 bit
> 3.NUC 7
> 4.NUC 6
> 5.Edgerouter
> 6.MPC8315e-rdb
> 7.Beaglebone
> 8.Qemuarm
> 9.Qemuarm-64
> 10.   Qemuppc
> 11.   Qemumips
> 12.   Qemumips64
>
> Other auto tests: 
>
> 1.Qemu-selftest
> 2.Qemu-meta-ide
>
> ETA for completion is Wednesday, 10 April.
>
> Thanks & Regards,
> Sangeeta Jain
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org  On
>> Behalf Of Poky Build User
>> Sent: Thursday, 28 March, 2019 11:30 AM
>> To: yocto@yoctoproject.org
>> Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew
>> ; akuster...@gmail.com
>> Subject: [yocto] QA notification for completed autobuilder build 
>> (yocto-2.6.2.rc3)
>>
>>
>> A build flagged for QA (yocto-2.6.2.rc3) was completed on the autobuilder 
>> and is
>> available at:
>>
>>
>>https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc3
>>
>>
>> Build hash information:
>>
>> bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b
>> eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316
>> eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718
>> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
>> meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc
>> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5
>> meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1
>> meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517
>> oecore: 45032e30be70503faeee468159b216031b729309
>> poky: faeb366bc3eb322f5f203cfe08dc4cf529a822e9
>>
>>
>>
>> This is an automated message from the Yocto Project Autobuilder
>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>> Email: richard.pur...@linuxfoundation.org
>>
>>
>>
>> --
>> ___
>> 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] [oe] [OE-core] Git commit process question.

[akuster808]

On 4/2/19 12:47 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 04:45:16AM +, Jon Mason wrote:
>> On Tue, Apr 2, 2019 at 6:41 AM Mark Hatle  wrote:
>>> On 4/1/19 6:20 PM, akuster808 wrote:
>>>>
>>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have noticed a large number of git commits with no header
>>>>>> information being accepted.
>>>>> Can you be more specific about what "no header information" means? You
>>>>> mean a shortlog and no full log message?
>>>> Commits with just a "subject" and signoff. No additional information
>>> If you can convey the reason for the change in just the subject, that is
>>> acceptable.. but there is -always- supposed to be a signed-off-by line 
>>> according
>>> to our guidelines.
>>>
>>> So if you see this, I think we need to step back and figure out where and 
>>> why
>>> it's happening and get it resolved in the future.
>>>
>>> (Places I've seen in the past were one-off mistakes and clearly that -- so 
>>> it
>>> wasn't anything that we needed to work on a correction.)
>>>
>>> --Mark
>>>
>>>> We tend to reference back to how the kernel does things.
>>>>
>>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>>> These two sections in particular.
>>>>
>>>>
>>>> 2) Describe your changes
>>>>
>>>> Describe your problem. Whether your patch is a one-line bug fix or 5000 
>>>> lines of
>>>> a new feature, there must be an underlying problem that motivated you to 
>>>> do this
>>>> work. Convince the reviewer that there is a problem worth fixing and that 
>>>> it
>>>> makes sense for them to read past the first paragraph.
>>>>
>>>>
>>>> along with this section.
>>>>
>>>>
>>>> 14) The canonical patch format
>>>>
>>>> This section describes how the patch itself should be formatted. Note 
>>>> that, if
>>>> you have your patches stored in a |git| repository, proper patch 
>>>> formatting can
>>>> be had with |git format-patch|. The tools cannot create the necessary text,
>>>> though, so read the instructions below anyway.
>>>>
>>>> The canonical patch subject line is:
>>>>
>>>> Subject: [PATCH 001/123] subsystem: summary phrase
>>>>
>>>> The canonical patch message body contains the following:
>>>>
>>>>   * A |from| line specifying the patch author, followed by an empty 
>>>> line
>>>> (only needed if the person sending the patch is not the author).
>>>>   * The body of the explanation, line wrapped at 75 columns, which 
>>>> will be
>>>> copied to the permanent changelog to describe this patch.
>>>>   * An empty line.
>>>>   * The |Signed-off-by:| lines, described above, which will also go in 
>>>> the
>>>> changelog.
>>>>   * A marker line containing simply |---|.
>>>>   * Any additional comments not suitable for the changelog.
>>>>   * The actual patch (|diff| output).
>>>>
>>>>
>>>> - Armin
>> There are existing git hooks that can be used to detect and fail to
>> merge patches like this.  For Linux, I have the following in
>> .git/hooks/pre-commit
>> #!/bin/sh
>> exec git diff --cached | scripts/checkpatch.pl -
> FWIW, over in U-Boot land I do:
> ./scripts/checkpatch.pl -q --git origin/master..
> as part of checking things prior to pushing to master.
Having hooks is fine but after the fact. It puts the burden back on the
Layer maintainer to resolve. If we think more info is better, it needs
to happen at time of change submittal.

- armin
>
>



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Git commit process question.

[akuster808]

On 4/2/19 12:46 PM, Tom Rini wrote:
> On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote:
>> On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote:
>>>
>>> On 4/1/19 4:02 PM, Richard Purdie wrote:
>>>> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>>>>> Hello,
>>>>>
>>>>> I have noticed a large number of git commits with no header
>>>>> information being accepted.
>>>> Can you be more specific about what "no header information" means? You
>>>> mean a shortlog and no full log message?
>>> Commits with just a "subject" and signoff. No additional information
>>>
>>> We tend to reference back to how the kernel does things.
>>>
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>> These two sections in particular.
>>>
>>>
>>> 2) Describe your changes
>>>
>>> Describe your problem. Whether your patch is a one-line bug fix or 5000
>>> lines of a new feature, there must be an underlying problem that
>>> motivated you to do this work. Convince the reviewer that there is a
>>> problem worth fixing and that it makes sense for them to read past the
>>> first paragraph.
>>> ...
>> The kernel does not have "upgrade foo to the latest upstream version" 
>> commits.
>>
>> With the Automatic Upgrade Helper this is a semi-automatic task, and 
>> most of the time there is no specific motivation other than upgrading
>> to the latest upstream version.
> But since that's just filling in a template the body can also be a
> template perhaps with useful AUH data (run at ... by ... ?) ?..

Maybe, if someone want to enhance the AUH.

- armin
>

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

Re: [yocto] [OE-core] Git commit process question.

[akuster808]

On 4/1/19 4:02 PM, Richard Purdie wrote:
> On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote:
>> Hello,
>>
>> I have noticed a large number of git commits with no header
>> information being accepted.
> Can you be more specific about what "no header information" means? You
> mean a shortlog and no full log message?
Commits with just a "subject" and signoff. No additional information

We tend to reference back to how the kernel does things.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html
These two sections in particular.


2) Describe your changes

Describe your problem. Whether your patch is a one-line bug fix or 5000
lines of a new feature, there must be an underlying problem that
motivated you to do this work. Convince the reviewer that there is a
problem worth fixing and that it makes sense for them to read past the
first paragraph.


along with this section.


14) The canonical patch format

This section describes how the patch itself should be formatted. Note
that, if you have your patches stored in a |git| repository, proper
patch formatting can be had with |git format-patch|. The tools cannot
create the necessary text, though, so read the instructions below anyway.

The canonical patch subject line is:

Subject: [PATCH 001/123] subsystem: summary phrase

The canonical patch message body contains the following:

  * A |from| line specifying the patch author, followed by an empty
line (only needed if the person sending the patch is not the
author).
  * The body of the explanation, line wrapped at 75 columns, which
will be copied to the permanent changelog to describe this patch.
  * An empty line.
  * The |Signed-off-by:| lines, described above, which will also go
in the changelog.
  * A marker line containing simply |---|.
  * Any additional comments not suitable for the changelog.
  * The actual patch (|diff| output).


- Armin

>
> Cheers,
>
> Richard
>

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

[yocto] Git commit process question.

[akuster808]

Hello,

I have noticed a large number of git commits with no header information
being accepted.

Are we still following:

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines



regards,
Armin

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

Re: [yocto] [meta-security][PATCH 3/4] linux-yocto: make bbappend version neutral

[akuster808]

On 3/31/19 10:59 AM, Adrian Bunk wrote:
> On Sun, Mar 31, 2019 at 10:28:59AM -0700, Armin Kuster wrote:
>> update apparmor configs
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  recipes-kernel/linux/linux-yocto/apparmor.cfg| 12 +++-
>>  .../linux/linux-yocto/apparmor_on_boot.cfg   |  1 +
>>  ...nux-yocto_4.%.bbappend => linux-yocto_%.bbappend} |  1 +
>>  3 files changed, 9 insertions(+), 5 deletions(-)
>>  create mode 100644 recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg
>>  rename recipes-kernel/linux/{linux-yocto_4.%.bbappend => 
>> linux-yocto_%.bbappend} (78%)
>>
>> diff --git a/recipes-kernel/linux/linux-yocto/apparmor.cfg 
>> b/recipes-kernel/linux/linux-yocto/apparmor.cfg
>> index 1dc4168..b5f9bb2 100644
>> --- a/recipes-kernel/linux/linux-yocto/apparmor.cfg
>> +++ b/recipes-kernel/linux/linux-yocto/apparmor.cfg
>> @@ -1,13 +1,15 @@
>>  CONFIG_AUDIT=y
>> -CONFIG_AUDITSYSCALL=y
>> -CONFIG_AUDIT_WATCH=y
>> -CONFIG_AUDIT_TREE=y
>>  # CONFIG_NETFILTER_XT_TARGET_AUDIT is not set
>> +CONFIG_SECURITY_NETWORK=y
>> +# CONFIG_SECURITY_NETWORK_XFRM is not set
>>  CONFIG_SECURITY_PATH=y
>>  # CONFIG_SECURITY_SELINUX is not set
>>  CONFIG_SECURITY_APPARMOR=y
>> -CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
>>  CONFIG_SECURITY_APPARMOR_HASH=y
>>  CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
>> +# CONFIG_SECURITY_APPARMOR_DEBUG is not set
>>  CONFIG_INTEGRITY_AUDIT=y
>> -# CONFIG_DEFAULT_SECURITY_APPARMOR is not set
>> +CONFIG_DEFAULT_SECURITY_APPARMOR=y
>> +# CONFIG_DEFAULT_SECURITY_DAC is not set
>> +CONFIG_DEFAULT_SECURITY="apparmor"
>> +CONFIG_AUDIT_GENERIC=y
>> diff --git a/recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg 
>> b/recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg
>> new file mode 100644
>> index 000..fc35740
>> --- /dev/null
>> +++ b/recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg
>> @@ -0,0 +1 @@
>> +CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
>> ...
> This and some of the other touched options are removed in kernel 5.1, 
> replaced with a different CONFIG_LSM mechanism.
Ah, 5.1... good point.. .

At some point I really should get these in the kernel-cache.

thanks for the review.

- armin
>
> cu
> Adrian
>

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

Re: [yocto] [meta-security][PATCH 4/4] linux-stable: add support for stable kernel bbappends

[akuster808]

not goint to work.

dropping

On 3/31/19 10:29 AM, Armin Kuster wrote:
> Signed-off-by: Armin Kuster 
> ---
>  recipes-kernel/linux/linux-stable/apparmor.cfg| 15 +++
>  .../linux/linux-stable/apparmor_on_boot.cfg   |  1 +
>  .../linux/linux-stable/smack-default-lsm.cfg  |  2 ++
>  recipes-kernel/linux/linux-stable/smack.cfg   |  8 
>  recipes-kernel/linux/linux-stable_%.bbappend  | 11 +++
>  5 files changed, 37 insertions(+)
>  create mode 100644 recipes-kernel/linux/linux-stable/apparmor.cfg
>  create mode 100644 recipes-kernel/linux/linux-stable/apparmor_on_boot.cfg
>  create mode 100644 recipes-kernel/linux/linux-stable/smack-default-lsm.cfg
>  create mode 100644 recipes-kernel/linux/linux-stable/smack.cfg
>  create mode 100644 recipes-kernel/linux/linux-stable_%.bbappend
>
> diff --git a/recipes-kernel/linux/linux-stable/apparmor.cfg 
> b/recipes-kernel/linux/linux-stable/apparmor.cfg
> new file mode 100644
> index 000..b5f9bb2
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-stable/apparmor.cfg
> @@ -0,0 +1,15 @@
> +CONFIG_AUDIT=y
> +# CONFIG_NETFILTER_XT_TARGET_AUDIT is not set
> +CONFIG_SECURITY_NETWORK=y
> +# CONFIG_SECURITY_NETWORK_XFRM is not set
> +CONFIG_SECURITY_PATH=y
> +# CONFIG_SECURITY_SELINUX is not set
> +CONFIG_SECURITY_APPARMOR=y
> +CONFIG_SECURITY_APPARMOR_HASH=y
> +CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
> +# CONFIG_SECURITY_APPARMOR_DEBUG is not set
> +CONFIG_INTEGRITY_AUDIT=y
> +CONFIG_DEFAULT_SECURITY_APPARMOR=y
> +# CONFIG_DEFAULT_SECURITY_DAC is not set
> +CONFIG_DEFAULT_SECURITY="apparmor"
> +CONFIG_AUDIT_GENERIC=y
> diff --git a/recipes-kernel/linux/linux-stable/apparmor_on_boot.cfg 
> b/recipes-kernel/linux/linux-stable/apparmor_on_boot.cfg
> new file mode 100644
> index 000..fc35740
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-stable/apparmor_on_boot.cfg
> @@ -0,0 +1 @@
> +CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
> diff --git a/recipes-kernel/linux/linux-stable/smack-default-lsm.cfg 
> b/recipes-kernel/linux/linux-stable/smack-default-lsm.cfg
> new file mode 100644
> index 000..b5c4845
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-stable/smack-default-lsm.cfg
> @@ -0,0 +1,2 @@
> +CONFIG_DEFAULT_SECURITY="smack"
> +CONFIG_DEFAULT_SECURITY_SMACK=y
> diff --git a/recipes-kernel/linux/linux-stable/smack.cfg 
> b/recipes-kernel/linux/linux-stable/smack.cfg
> new file mode 100644
> index 000..62f465a
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-stable/smack.cfg
> @@ -0,0 +1,8 @@
> +CONFIG_IP_NF_SECURITY=m
> +CONFIG_IP6_NF_SECURITY=m
> +CONFIG_EXT2_FS_SECURITY=y
> +CONFIG_EXT3_FS_SECURITY=y
> +CONFIG_EXT4_FS_SECURITY=y
> +CONFIG_SECURITY=y
> +CONFIG_SECURITY_SMACK=y
> +CONFIG_TMPFS_XATTR=y
> diff --git a/recipes-kernel/linux/linux-stable_%.bbappend 
> b/recipes-kernel/linux/linux-stable_%.bbappend
> new file mode 100644
> index 000..321392c
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-stable_%.bbappend
> @@ -0,0 +1,11 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +SRC_URI += "\
> +${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' 
> file://apparmor.cfg', '', d)} \
> +${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' 
> file://apparmor_on_boot.cfg', '', d)} \
> +"
> +
> +SRC_URI += "\
> +${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' 
> file://smack.cfg', '', d)} \
> +${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' 
> file://smack-default-lsm.cfg', '', d)} \
> +"

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

Re: [yocto] [meta-security][PATCH 2/2] sssd: fix libcrypto version used

[akuster808]

On 3/27/19 12:16 AM, Adrian Bunk wrote:
> On Tue, Mar 26, 2019 at 03:52:39PM -0700, akuster808 wrote:
>>
>> On 3/26/19 3:24 AM, Adrian Bunk wrote:
>>> On Mon, Mar 25, 2019 at 09:58:55AM -0700, Armin Kuster wrote:
>>>> Signed-off-by: Armin Kuster 
>>>> ---
>>>>  recipes-security/sssd/sssd_1.16.3.bb | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/recipes-security/sssd/sssd_1.16.3.bb 
>>>> b/recipes-security/sssd/sssd_1.16.3.bb
>>>> index 8f7f805..d39fa23 100644
>>>> --- a/recipes-security/sssd/sssd_1.16.3.bb
>>>> +++ b/recipes-security/sssd/sssd_1.16.3.bb
>>>> @@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages, 
>>>> --with-manpages=no"
>>>>  PACKAGECONFIG[python2] = "--with-python2-bindings, 
>>>> --without-python2-bindings"
>>>>  PACKAGECONFIG[python3] = "--with-python3-bindings, 
>>>> --without-python3-bindings"
>>>>  PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
>>>> -PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto"
>>>> +PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10"
>>>> ...
>>> This looks wrong for multiple reasons, and it still gave the same error 
>>> when I tried it.
>> That is troubling. I don't see any errors here. Thanks for the feed
>> back. I will have to dig at this a bit more.
>>
>> Can you provide some build detail so that I can reproduce it?
> Try building the package without nss but with cyrpto (sic) in PACKAGECONFIG.
Ok. I see it now.
>
>>> How has this change been tested?
>> Not for this change.
>>
>> Which reminds me I should automate some testing for this package.
> This is not about automating testing.
>
> This is about first reproducing the problem you are trying to fix,
> and then verifying that your fix actually fixes this problem.
And that is what i thought I was doing.

>
> Which is the fundamental way to do any kind of bugfixing.[1]
Thanks for the reminder.
>
> This one line already contained two bugs,[2] and the commit added a 
> third problem (usage of OpenSSL 1.0) without fixing any of these bugs.
>
> The commit message not stating any reason why this change was done only 
> adds to the confusion.
> I thought originally this was a workaround for code not building with 
> OpenSSL 1.1, which would then also be required for thud.
I will keep that in mind.

thanks,
Armin
>
>> regards,
>> Armin
> cu
> Adrian
>
> [1] this is not one of the harder cases where reproducing the problem
> would be a problem
> [2] "cyrpto", and "libcrypto" instead of "openssl p11-kit"
>

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

Re: [yocto] [meta-security][PATCH 2/2] sssd: fix libcrypto version used

[akuster808]

On 3/26/19 3:24 AM, Adrian Bunk wrote:
> On Mon, Mar 25, 2019 at 09:58:55AM -0700, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>  recipes-security/sssd/sssd_1.16.3.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-security/sssd/sssd_1.16.3.bb 
>> b/recipes-security/sssd/sssd_1.16.3.bb
>> index 8f7f805..d39fa23 100644
>> --- a/recipes-security/sssd/sssd_1.16.3.bb
>> +++ b/recipes-security/sssd/sssd_1.16.3.bb
>> @@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages, 
>> --with-manpages=no"
>>  PACKAGECONFIG[python2] = "--with-python2-bindings, 
>> --without-python2-bindings"
>>  PACKAGECONFIG[python3] = "--with-python3-bindings, 
>> --without-python3-bindings"
>>  PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
>> -PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto"
>> +PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10"
>> ...
> This looks wrong for multiple reasons, and it still gave the same error 
> when I tried it.
That is troubling. I don't see any errors here. Thanks for the feed
back. I will have to dig at this a bit more.

Can you provide some build detail so that I can reproduce it?

>
> How has this change been tested?
Not for this change.

Which reminds me I should automate some testing for this package.

regards,
Armin
>
> cu
> Adrian
>


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

Re: [yocto] [OE-core] OE Summit report from SCaLE17x

[akuster808]

Trevor,

Thank you for leading this effort. Its much appreciated.


On 3/15/19 7:27 AM, Trevor Woerner wrote:
> Hi,
>
> Earlier this week I got back from SCaLE17x during which I taught an E-ALE
> class on Buildroot, was a TA for the other E-ALE classes, organized and ran
> the first ever (hopefully of more to come) OE Summit, and gave a general intro
> talk on OE. I wasn't planning on giving an OE talk at SCaLE, but the person
> who was supposed to talk wasn't able to make it. I had travelled to SCaLE with
> a backup talk prepared as a "plan B", and it was good that I did.
>
> I'm quite happy with how the inaugural OpenEmbedded Summit went. Everything
> went off without a hitch, and there was a lot of interaction and feedback
> between the speakers and the audience.
>
> We had 4 speakers:
>
>   myself (Togan Labs): Using OE
>   Drew Moseley (mender.io): Mechanisms for Enabling and Configuring WiFi 
> in OE
>   Alistair Francis (Western Digital): RISC-V and OE
>   Jon Mason (ARM): Kernel Development Workflows Using OE
Thank you all for participating in the first ever OE Summit.

Kind regards,
Armin
>
> Counting attendance is a bit tricky because people sometimes wander in and
> out. Do we count someone who wanders in partway through but leaves before the
> end? My talk was the least attended. I forgot to count the audience members
> (since I was giving the talk), but I did notice that a couple people wandered
> in during the talk. Behan counted 12; like I said, I didn't think to get a
> specific number myself. In any case, my talk wasn't in the programme, since I
> was filling in for someone who didn't make it to the conference. Drew's and
> Jon's talks had roughly 20 audience members each, and Alistair's talk was
> about 30.
>
> It's too bad the OE Summit was pitted against SCaLE's "Embedded Track". I
> think we ended up "competing" for audience members between the two of us. The
> OE Summit was put in a rather large room. Between teaching and helping out
> with E-ALE and running the OE Summit, I didn't attend a single talk at the
> conference nor spend time in any other part of the conference except for
> these two rooms (which were beside each other). I have been told anecdotally,
> however, that the attendance numbers we saw for the OE Summit were in-line
> with the numbers of attendees for several of the other talks, but I can't
> comment personally.
>
> As we were still setting up for my OE talk, the very first talk of the OE
> Summit, one of the audience members put up his hand and asked what the
> difference is between "Yocto" and "OE". We weren't specifically prepared to
> comment off-the-cuff about the relationship between the two projects; it's not
> as if we had a prepared statement to read on the topic. We tried to fumble
> through a satisfactory answer while remaining as neutral as possible on the
> topic. But it sure would be great if the two projects could get together and
> put out an official statement on the matter to which we could point all such
> curious people. Interestingly enough, this person was sure that The Yocto
> Project pre-dated OE, which we had to correct. Then he assumed these were
> two projects that had simply forked from each other at some point in the
> past. It was probably actually more confusing to him that OE and YP are
> two separate projects, but with almost all the same developers, working on
> almost all the same code. In any case, The Yocto Project's Community Manager
> was on-hand, thankfully, and I don't think he had any objections to any of
> the things we said in answering this question.
>
> My talk was a general introduction talk about OE, but all the other talks
> assumed the audience knew something about OE. This turned out to not be the
> case. Pretty much all the speakers had to field questions along the lines of
> "so what is OE anyway?". Sadly, in many cases, saying "it's like Buildroot" is
> often what would help the person asking the question the most. I think it's
> noteworthy that more people seem to know what Buildroot is, but not OE/YP.
> Although I realize this is just one conference, and a very small sample set,
> so it wouldn't be fair to generalize from these numbers. But it is true that
> these are the sorts of questions we were frequently asked, so it's noteworthy
> in that respect.
>
> Oddly enough, when I was finished the slides portion of the Buildroot class,
> the very first statement a student made was to complain about how terribly
> difficult Yocto is to learn and use. Why this came up in a class about
> Buildroot is confusing to me too, maybe he looked me up online and found my
> affiliation with OE? I don't know. I was careful to not mention the words "OE"
> or "Yocto" at all in my Buildroot talk. In any case, in his opinion, using
> Yocto requires a masters degree. Obviously he's exaggerating for effect.
>
> I'd like to personally thank the speakers who agreed to give a talk at a
> conference that didn't exist 

Re: [linux-yocto] [kernel-cache][PATCH] netfilter: Enable CONFIG_NETFILTER_XT_TARGET_LOG

[akuster808]

On 2/15/19 5:13 PM, Tom Rini wrote:
> On Fri, Feb 15, 2019 at 10:46:13AM -0500, Bruce Ashfield wrote:
>
>> merged.
>>
>> SRCREV updates will be sent out with my next queue.
> Thanks.  What's the backport policy here?  I first ran into this issue
> back on Jethro (but that's a fair bit too far to expect a backport to)
> and I finally root caused this on thud.  Can this go back to thud/sumo
I think that depends on kernel versions supported by the stable
branches. Maybe patches for each branch for this repo? They need to be
posted than accepted/merged. Then I kernel recipes can be updated with
the new hashes.

- armin
> at least on your next round of changes there?
>
>



signature.asc
Description: OpenPGP digital signature
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] YPTM minutes

[akuster808]

On 2/5/19 10:24 AM, Joshua Watt wrote:
> On Tue, 2019-02-05 at 10:11 -0800, Scott Rifenbark wrote:
>>
>>
>> On Tue, Feb 5, 2019 at 8:37 AM > > wrote:
>>>
>>> *Yocto Technical Team Minutes for Feb. 5, 2019.*
>>>
>>>  
>>>
>>> Attendees: Armin, David, Joshua, Randy, Tim, Richard G., Stephen,
>>> Jan-Simon, Manjukum, Tracey, Trevor, Nick, Richard P, Mark, Kate,
>>> Michael,
>>>
>>>  
>>>
>>> YP 2.6.1 was released on Feb. 4, 2019.
>>>
>>> YP 2.7 M2 was built and is in QA and is 79% done.  See:
>>> https://wiki.yoctoproject.org/wiki/2.7_QA_Status
>>>
>>>  
>>>
>>> Armin agreed to add Ubuntu 18.4 to YP 2.6 series and we will use in
>>> for YP 2.7
>>>
>>> We discussed that the YP 2.6 manual doesn’t have an upgrading to YP
>>> 2.6.  Tracey will look into this.
>>>
>>>
>>
>> Can I get some clarification on this.  Ubuntu 18.04 seems to be an
>> LTS.  I don't have "LTS" listed in the 2.6 ref-manual
>> (https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros)
>> but do have Ubuntu 18.04 listed as a supported distro.  What is meant
>> by "... the YP 2.6 manual doesn't have an upgrading to YP 2.6."?  -
>> Thanks Scott
>
> I think there is a little confusion here. There are actually 2 issues:
>
> 1) The Yocto 2.6 manual doesn't have the "Moving to the Yocto Project
> 2.6 Release" section to describe the changes that have been made from
> 2.5 -> 2.6
> (https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#moving-to-the-yocto-project-2.5-release).
> Oddly, this section *is* present in the "latest" mega manual.
>
> 2) The second (unrelated) issue has to do with reporting 18.04 as a
> supported host distro. I'm not as familiar with this one, so I'll let
> someone else chime in.

This is in thud-next:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/distro/poky.conf?h=thud-next=263cf203bd363a6b9d58524ff5862d23c76e6390

Once I get sumo stabilized, the same will be validated and back ported.

- armin
>
>>
>>>  
>>>
>>> We discussed the status of YP 2.7 upgrades and we are doing OK
>>> there.  We are struggling on new features YP 2.7.  Richard is
>>> primarily working to stabilize the autobuilder to produce an
>>> automated QA report to allow QA to transition from Intel.
>>>
>>>  
>>>
>>> Richard discussed maintainers of OE-Core.  AUH is sending requests
>>> but not getting feedback.
>>>
>>>  
>>>
>>> Richard discussed that we have issues with some products and need
>>> support from the community to fix.
>>>
>>>  
>>>
>>> Tim discussed ptest issues Richard has identified.
>>>
>>>  
>>>
>>> Richard asked if there were ideas about how to better communicate
>>> with the community. No specific suggestions.
>>>
>>>  
>>>
>>> Thanks,
>>>
>>>  
>>>
>>> */Stephen K. Jolley/**//*
>>>
>>> *Yocto Project Project Manager*
>>>
>>> (    *Cell*:    (208) 244-4460
>>>
>>> * *Email*:  _sjolley.yp...@gmail.com
>>> _
>>>
>>>  
>>>
>>> -- 
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org 
>>> https://lists.yoctoproject.org/listinfo/yocto
> -- 
> Joshua Watt mailto:jpewhac...@gmail.com>>
>

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

Re: [yocto] [meta-security][thud][PATCH] tpm2-abrmd: Fix QA error

[akuster808]

On 12/12/18 7:27 AM, Daniel Dragomir wrote:
> QA Issue: tpm2-abrmd: Files/directories were installed but not
>   shipped in any package:
> /usr/share/dbus-1
> /usr/share/dbus-1/system-services
> /usr/share/dbus-1/system-services/com.intel.tss2.Tabrmd.service

merged
>
> Signed-off-by: Daniel Dragomir 
> ---
>  meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_2.0.2.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_2.0.2.bb 
> b/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_2.0.2.bb
> index 951556d..6347379 100644
> --- a/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_2.0.2.bb
> +++ b/meta-tpm/recipes-tpm/tpm2-abrmd/tpm2-abrmd_2.0.2.bb
> @@ -46,7 +46,8 @@ do_install_append() {
>  install -m 0644 "${WORKDIR}/tpm2-abrmd.default" 
> "${D}${sysconfdir}/default/tpm2-abrmd"
>  }
>  
> -FILES_${PN} += "${libdir}/systemd/system-preset"
> +FILES_${PN} += "${libdir}/systemd/system-preset \
> + ${datadir}/dbus-1"
>  
>  RDEPENDS_${PN} += "tpm2.0-tss"
>  

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

Re: [yocto] Using ICECC to build Thud issue

[akuster808]

On 12/5/18 1:21 PM, Joshua Watt wrote:
>
>
> On Wed, Dec 5, 2018, 3:09 PM John Unland   wrote:
>
> Fixed on master:
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1da297d35411e923ca3b6accdd37074f5182f019
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5dd8df08c51bc4cc1ef0d5be7656c9bfcf938cca
>
> They should probably be backported to thud.
>
>
> Glad it wasn't anything on the config end par say, would this be a
> candidate to log a bug for?
>
>
> CC'ing Armi
its in stable/thud-nmut

thanks
-a rmin
>
> It wouldn't hurt to make a bug for the backport.

>
>
>
> Thanks!
>

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

Re: [yocto] Yocto layers missing thud branches

[akuster808]

On 11/20/18 4:05 PM, Richard Purdie wrote:
> On Mon, 2018-11-19 at 09:47 +1300, Paul Eggleton wrote:
>> On Monday, 19 November 2018 12:11:35 AM NZDT Max Krummenacher wrote:
>>> Am Samstag, den 17.11.2018, 15:50 -0800 schrieb akuster808:
>>>> Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and
>>>> meta-cgl
>>>> please add a "Thud" branch
>>>>
>>> While at it, the following patches declaring thud compatibility are
>>> not
>>> yet applied:
>>>
> https://lists.yoctoproject.org/pipermail/yocto/2018-October/042780.html
> https://lists.yoctoproject.org/pipermail/yocto/2018-October/042922.html
> https://lists.yoctoproject.org/pipermail/yocto/2018-October/042923.html
>> I have just taken care of meta-qt3 and meta-qt4, FWIW.
> Given we don't test those any more, should we be pushing these new
> branches?
Are the branching schemes in sync with what we test , build or both?  I
think we should be clear what is built or built and tested if there are
exception.


The 2.6 release notes called out so it may lead to the conclusion its
tested.

Release Name: meta-qt3-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 02f273cba6c25f5cf20cb66d8a417a83772c3179
md5: 7b73bf1132428ea898938b03815cad21

- armin
>
> Cheers,
>
> Richard
>


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

Re: [yocto] [[yocto-docs][thud][PATCH] ref-system-requirements: sync with thud poky.conf

[akuster808]

On 11/19/18 10:16 AM, Scott Rifenbark wrote:
> Armin,
>
> See
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros
> and let me know if the patch is good.
Looks good.
Thanks,
Have a good Thanksgiving.
Armin
>
> Thanks,
> Scott
>
> On Sun, Nov 18, 2018 at 6:15 PM Armin Kuster  > wrote:
>
> poky.conf
>     ubuntu-16.04
>     ubuntu-16.10
>     ubuntu-17.04
>     fedora-26
>     centos-7
>     debian-8
>     debian-9
>     opensuse-42.1
>     opensuse-42.2
>
> Signed-off-by: Armin Kuster  >
> ---
>  documentation/ref-manual/ref-system-requirements.xml | 20
> 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-system-requirements.xml
> b/documentation/ref-manual/ref-system-requirements.xml
> index 9298e84..0abc47e 100644
> --- a/documentation/ref-manual/ref-system-requirements.xml
> +++ b/documentation/ref-manual/ref-system-requirements.xml
> @@ -93,19 +93,22 @@
>                  Ubuntu 11.10
>                  Ubuntu 12.04 (LTS)
>                  Ubuntu 13.10
> -                Ubuntu 14.04
> (LTS) -->
> +                Ubuntu 14.04 (LTS)
>                  Ubuntu 14.10
>                  Ubuntu 15.04
> -                Ubuntu 15.10
> +                Ubuntu 15.10 -->
>                  Ubuntu 16.04 (LTS)
> +                Ubuntu 16.10 (LTS)
> +                Ubuntu 17.04 
>  
> +                Fedora release 20
> (Heisenbug)
>                  Fedora release 22
>                  Fedora release 23
> -
> +                Fedora release 26
> +
> -
> -                openSUSE 13.2
> +                openSUSE 13.1
> +                openSUSE 13.2 -->
>                  openSUSE 42.1
> +                openSUSE 42.2
>              
>          
>
> -- 
> 2.7.4
>

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

Re: [yocto] [[yocto-docs][thud][PATCH] ref-system-requirements: sync with thud poky.conf

[akuster808]

On 11/18/18 6:53 PM, Ang, Chin Huat wrote:
> There's a minor typo where Ubuntu 16.10 is not LTS.
thanks,
v2 out shortly.

>
> 
> From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on 
> behalf of Armin Kuster [akuster...@gmail.com]
> Sent: Monday, November 19, 2018 10:15 AM
> To: akuster...@gmail.com; yocto@yoctoproject.org; srifenb...@gmail.com
> Subject: [yocto] [[yocto-docs][thud][PATCH] ref-system-requirements: sync 
>   with thud poky.conf
>
> poky.conf
> ubuntu-16.04
> ubuntu-16.10
> ubuntu-17.04
> fedora-26
> centos-7
> debian-8
> debian-9
> opensuse-42.1
> opensuse-42.2
>
> Signed-off-by: Armin Kuster 
> ---
>  documentation/ref-manual/ref-system-requirements.xml | 20 
> 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-system-requirements.xml 
> b/documentation/ref-manual/ref-system-requirements.xml
> index 9298e84..0abc47e 100644
> --- a/documentation/ref-manual/ref-system-requirements.xml
> +++ b/documentation/ref-manual/ref-system-requirements.xml
> @@ -93,19 +93,22 @@
>  Ubuntu 11.10
>  Ubuntu 12.04 (LTS)
>  Ubuntu 13.10
> -Ubuntu 14.04 (LTS) -->
> +Ubuntu 14.04 (LTS)
>  Ubuntu 14.10
>  Ubuntu 15.04
> -Ubuntu 15.10
> +Ubuntu 15.10 -->
>  Ubuntu 16.04 (LTS)
> +Ubuntu 16.10 (LTS)
> +Ubuntu 17.04 
>  
> +Fedora release 20 
> (Heisenbug)
>  Fedora release 22
>  Fedora release 23
> -
> +Fedora release 26
> +
> -
> -openSUSE 13.2
> +openSUSE 13.1
> +openSUSE 13.2 -->
>  openSUSE 42.1
> +openSUSE 42.2
>  
>  
>
> --
> 2.7.4
>
> --
> ___
> 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] Yocto layers missing thud branches

[akuster808]

On 11/18/18 12:47 PM, Paul Eggleton wrote:
> On Monday, 19 November 2018 12:11:35 AM NZDT Max Krummenacher wrote:
>> Am Samstag, den 17.11.2018, 15:50 -0800 schrieb akuster808:
>>> Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and meta-cgl
>>> please add a "Thud" branch
>>>
>> While at it, the following patches declaring thud compatibility are not
>> yet applied:
>> https://lists.yoctoproject.org/pipermail/yocto/2018-October/042780.html
>> https://lists.yoctoproject.org/pipermail/yocto/2018-October/042922.html
>> https://lists.yoctoproject.org/pipermail/yocto/2018-October/042923.html
> I have just taken care of meta-qt3 and meta-qt4, FWIW.
Thanks Paul.

>
> Cheers,
> Paul
>

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

[yocto] Yocto layers missing thud branches

[akuster808]

Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and meta-cgl
please add a "Thud" branch

kind regards,
Armin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I enabled Fortran support in Sumo?

[akuster808]

On 11/15/18 1:31 PM, Mike Worster wrote:
> I'm trying to get Fortran support (gfortran and libgfortran) enabled
> in a Yocto Sumo build.
>
> Based on advice I got from this site:
> https://jumpnowtek.com/yocto/Add-Fortran-support-to-a-Yocto-build.html
>
> I have enabled fortran in my local.conf via adding:
>
>     FORTRAN_forcevariable = ",fortran"
>
> And I have created a gcc-runtime_7.3.bbappend file containing:
>
>     RUNTIMETARGET += "libgfortran"

I recently ran into something similar. I ended up using in my local.conf
FORTRAN_forcevariable = ",fortran"
RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath" <<<--- maybe key??

and in one recipe I had a depends on "libgfortran" and is seems to build
fine.

- armin

>
> And I have added gfortran to my image:
>
>     FORTRAN_TOOLS = " \
>         gfortran \
>     gfortran-symlinks \
>     libgfortran \
>     libgfortran-dev \
>  "
>
>     IMAGE_INSTALL += " \
>         ${FORTRAN_TOOLS} \
>      "
> After all these modifications when I go to build I see the following
> error:
>
> |
> ../../../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/runtime/backtrace.c:36:10:
> fatal error: backtrace-supported.h: No such file or directory
> |  #include "backtrace-supported.h"
> |   ^~~
> | compilation terminated.
> | Makefile:2310: recipe for target 'backtrace.lo' failed
> | make[1]: *** [backtrace.lo] Error 1
>
> I've found I can get past this by updating
> poky/meta/recipes-devtools/gcc/gcc-7.3.inc with the following line:
>
>     CFLAGS += " -I../../libbacktrace "
>
> The build then dies later here:
>
> | libtool: link: cannot find the library
> `../libbacktrace/libbacktrace.la ' or
> unhandled argument `../libbacktrace/libbacktrace.la
> '
> | Makefile:1364: recipe for target 'libgfortran.la
> ' failed
> | make[1]: *** [libgfortran.la ] Error 1
>
> I can resolve that by adjusting the Makefile found at:
> tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gcc-runtime/7.3.0-r0/gcc-7.3.0/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/arm-poky-linux-gnueabi/libgfortran/Makefile.
> The following adjustment:
>
>  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la
>  \
>
> gets past the failure to find the library (one directory up). Then
> running the build again, there is the real problem:
>
> | ../../libbacktrace/.libs/libbacktrace.a: member
> ../../libbacktrace/.libs/libbacktrace.a(atomic.o) in archive is not an
> object
> | collect2: error: ld returned 1 exit status
> | ERROR: oe_runmake failed
> | Makefile:1364: recipe for target 'libgfortran.la
> ' failed
> | make[1]: *** [libgfortran.la ] Error 1
>
> As far as I can tell, the archive's elements (atomic.o being first)
> are being built for x86 instead of ARM, and thus they are not being
> recognized as objects.
>
> Does anyone have input on this issue? Any ideas why this is broken, or
> how to resolve this?
>
> -Mike
>

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

Re: [yocto] FW: final pass on release notes....and general status of readiness

[akuster808]

Stephen,

Please add "multiconfig in no longer works with COMPATIBLE_MACHINE" bug
12985

thanks,

Armin

On 11/14/18 2:02 PM, Scott Rifenbark wrote:
> Especially true for the manuals... always go to the website for best
> set of manuals.
>
> Scott
>
> On Wed, Nov 14, 2018 at 1:41 PM akuster808  <mailto:akuster...@gmail.com>> wrote:
>
>
> On 11/14/18 12:47 PM, Jolley, Stephen K wrote:
>>
>> We will release YP 2.6 M4 rc1 shortly.  Please give feedback if
>> any is required.
>>
>
> Please add the note that Tip of Thud is not what is being released.
>
> This will just confuse folks trying to connect the dots.
>
>
> - armin
>
>>  
>>
>> Thanks,
>>
>>  
>>
>> Stephen
>>
>>  
>>
>> *From:* Graydon, Tracy
>> *Sent:* Wednesday, November 14, 2018 12:33 PM
>> *To:* Jolley, Stephen K 
>> <mailto:stephen.k.jol...@intel.com>; Michael Halstead
>> 
>> <mailto:mhalst...@linuxfoundation.org>
>> *Subject:* final pass on release notesand general status of
>> readiness
>>
>>  
>>
>> Ugh, I am not seeing the email I sent with the finalized release
>> notes. I dunno if I sent it or not because I am having a
>> nightmare with Outlook on Mac eating things and generally not
>> working right.
>>
>>
>> So, by way of sanity check, attached.  The only changes were
>> adding the binutils CVES to Known issues:
>>
>>  
>>
>> binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606,
>> CVE-2018-18607
>>
>>  
>>
>> And the gitsm known issue:
>>
>>  
>>
>> - gitsm fixes on master-next:
>>
>> * The submodule name and path were assumed to be the same, which
>> is not necessarily true.
>>
>> * Submodules refer to a specific commit, not branch, but we
>> erroneously check against the branch specified in SRC_URI. This
>> results in
>>
>> failure if a submodule commit is not on that branch.
>>
>>  
>>
>> So, nothing major there. Just really a sanity check on the gitsm
>> wording.
>>
>>  
>>
>> Everything is ready to go. Pages are set and just need to be
>> published. Release announcement is ready. So we just need to do
>> the final mirror and tagging magic, and announce.
>>
>>  
>>
>> If the wording on gitsm issue looks reasonable, we are good to go.
>>
>>  
>>
>> -t
>>
>>  
>>
>>  
>>
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: final pass on release notes....and general status of readiness

[akuster808]

On 11/14/18 12:47 PM, Jolley, Stephen K wrote:
>
> We will release YP 2.6 M4 rc1 shortly.  Please give feedback if any is
> required.
>

Please add the note that Tip of Thud is not what is being released.

This will just confuse folks trying to connect the dots.


- armin

>  
>
> Thanks,
>
>  
>
> Stephen
>
>  
>
> *From:* Graydon, Tracy
> *Sent:* Wednesday, November 14, 2018 12:33 PM
> *To:* Jolley, Stephen K ; Michael Halstead
> 
> *Subject:* final pass on release notesand general status of readiness
>
>  
>
> Ugh, I am not seeing the email I sent with the finalized release
> notes. I dunno if I sent it or not because I am having a nightmare
> with Outlook on Mac eating things and generally not working right.
>
>
> So, by way of sanity check, attached.  The only changes were adding
> the binutils CVES to Known issues:
>
>  
>
> binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606,
> CVE-2018-18607
>
>  
>
> And the gitsm known issue:
>
>  
>
> - gitsm fixes on master-next:
>
> * The submodule name and path were assumed to be the same, which is
> not necessarily true.
>
> * Submodules refer to a specific commit, not branch, but we
> erroneously check against the branch specified in SRC_URI. This results in
>
> failure if a submodule commit is not on that branch.
>
>  
>
> So, nothing major there. Just really a sanity check on the gitsm wording.
>
>  
>
> Everything is ready to go. Pages are set and just need to be
> published. Release announcement is ready. So we just need to do the
> final mirror and tagging magic, and announce.
>
>  
>
> If the wording on gitsm issue looks reasonable, we are good to go.
>
>  
>
> -t
>
>  
>
>  
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] m4-native, zedboard, "Please port gnulib fseeko.c to your platform"

[akuster808]

Robert,

On 11/13/18 12:28 PM, Robert P. J. Day wrote:
>   been away from YP for a few months, diving back in, want to build a
> core-image-minimal for my zedboard, and i will first admit that i'm
> using a non-approved distro (fully-updated fedora 29):
>
> "WARNING: Host distribution "fedora-29" has not been validated with
> this version of the build system; you may possibly experience
> unexpected failures. It is recommended that you use a tested
> distribution."
>
>   no matter, i will live dangerously. but then things take an ugly
> turn:
>
> "WARNING: Your host glibc verson (2.28) is newer than that in
> uninative (2.27). Disabling uninative so that sstate is not
> corrupted."

>   ok, let's see how far we get ... and that's here, trying to compile
> m4-native:
>
> | gcc   -I. -I../../m4-1.4.18/lib
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -O2 -pipe -c -o freadahead.o ../../m4-1.4.18/lib/freadahead.c
> | gcc   -I. -I../../m4-1.4.18/lib
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
> -O2 -pipe -c -o fseeko.o ../../m4-1.4.18/lib/fseeko.c
> | ../../m4-1.4.18/lib/freadahead.c: In function ‘freadahead’:
> | ../../m4-1.4.18/lib/fseeko.c: In function ‘rpl_fseeko’:
> | ../../m4-1.4.18/lib/freadahead.c:92:3: error: #error "Please port
> gnulib freadahead.c to your platform! Look at the definition of
> fflush, fread, ungetc on your system, then report this to bug-gnulib."
> |   #error "Please port gnulib freadahead.c to your platform! Look at
> the definition of fflush, fread, ungetc on your system, then report
> this to bug-gnulib."
> |^
> | ../../m4-1.4.18/lib/fseeko.c:110:4: error: #error "Please port
> gnulib fseeko.c to your platform! Look at the code in fseeko.c, then
> report this to bug-gnulib."
> |#error "Please port gnulib fseeko.c to your platform! Look at the
> code in fseeko.c, then report this to bug-gnulib."
>
>
> and so on. red hat's bugzilla has an entry for just this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1595702
>
> but i'm unsure (read, have no clue) how to deal with this, and i
> suspect it affects more targets than just zedboard which is why i'm
> asking on the general YP list.
>
>   thoughts? is there a cheap fix for this? i'm about to dive into
> debugging this, but if someone wants to make my life easy, that'd be
> great.

Thud has :
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/m4?h=thud=95ca077ab871ceff46c2052f324f879a1d624ff4

with backports pending verification for sumo but missed th Rocko cutoff.

- armin

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

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

[akuster808]

On 11/12/18 8:12 AM, Burton, Ross wrote:
> On Sat, 10 Nov 2018 at 16:26,  wrote:
>> My personal view is that whilst there are a number of issues present in
>> rc1, we should release it, collect up fixes on the thud branch (aleady
>> happening) and plan on a 2.6.1 as soon as it looks like we have enough
>> critical mass behind those as opposed to an rc2 and further delays to
>> the release.
> I'd suggest we schedule 2.6.1 for about month after release, there's
> quite a queue of security fixes already.

Maybe shoot for before the Dec Holidays instead of a fixed period after
2.6 releases, a nice way to end the year : )

- armin

>
> With that caveat, I'm fine with this plan.
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[akuster808]

On 11/11/18 1:24 PM, richard.pur...@linuxfoundation.org wrote:
> On Sun, 2018-11-11 at 13:18 -0800, akuster808 wrote:
>> On 11/11/18 2:21 AM, richard.pur...@linuxfoundation.org wrote:
>>> On Sat, 2018-11-10 at 10:02 -0800, akuster808 wrote:
>>>> On 11/10/18 8:25 AM, richard.pur...@linuxfoundation.org wrote:
>>>>> On Fri, 2018-11-09 at 09:24 +, Jain, Sangeeta wrote:
>>>>>> 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
>>>>> Thanks Sangeeta and team!
>>>>>
>>>>> Now we have the QA report for YP 2.6 M4 rc1 (Final 2.6) we need
>>>>> to make
>>>>> a release go or nogo decision. To do this we have the
>>>>> following:
>>>>>  
>>>>> QA Report: 
>>>>> https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1
>>>>> Release Criteria: 
>>>>> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status#Milestone_4.2FFinal_-_Target_Oct._26.2C_2018
>>>>>
>>>>> We'd be happy to take representations from members and the
>>>>> community to
>>>>> help reach that decision.
>>>> Regarding. 
>>>> Bug 12991 - [2.6 M4 RC1][Build-Appliance] Bitbake build-
>>>> appliance-
>>>> image getting failed during building image due to webkitgtk
>>>> package
>>>> Does it mean the Build-Appliance is non functioning ?  It was
>>>> broken
>>>> at the Sumo release time as well. Should it be dropped as the
>>>> release
>>>> criteria?
>>> Build-appliance is a tricky test as it tests multiple things,
>>> roughly:
>>>
>>> * vmdk images under vmware
>>> * the web browser
>>> * toaster
>>> * whether we can self host (build poky within poky)
>>>
>>> The fact the webkit recipe failed to build may be due to several
>>> reasons:
>>>
>>> * random race type condition
>>> * lack of memory in the VM
>>> * phase of the moon
>>> * other things
>>>
>>> I'm not convinced its a release blocker, or that it invalidates the
>>> b-a 
>>> test, or that it would even reproduce. If it does reproduce that
>>> would
>>> be more interesting and easier to debug.
>> ok, but is the b-a functional  in 2.6?
> It booted under VMWare, I believe the web browser was functional and it
> managed a build to a point somewhere in webkitgtk which was the only
> failure in the build.
>
> I suspect but have little evidence that the failure was a race or
> system resource issue rather than a functionality problem with b-a.
> Does that make b-a functional? In my view, yes, your view may vary.

Nope. I am good. If it is functional I am good with it.  We can address
the other issues later.

thanks,

Armin

>
> Cheers,
>
> Richard
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[akuster808]

On 11/11/18 2:21 AM, richard.pur...@linuxfoundation.org wrote:
> On Sat, 2018-11-10 at 10:02 -0800, akuster808 wrote:
>> On 11/10/18 8:25 AM, richard.pur...@linuxfoundation.org wrote:
>>> On Fri, 2018-11-09 at 09:24 +, Jain, Sangeeta wrote:
>>>> 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
>>> Thanks Sangeeta and team!
>>>
>>> Now we have the QA report for YP 2.6 M4 rc1 (Final 2.6) we need to make
>>> a release go or nogo decision. To do this we have the following:
>>>  
>>> QA Report: 
>>> https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1
>>> Release Criteria: 
>>> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status#Milestone_4.2FFinal_-_Target_Oct._26.2C_2018
>>>
>>> We'd be happy to take representations from members and the community to
>>> help reach that decision.
>> Regarding. 
>> Bug 12991 - [2.6 M4 RC1][Build-Appliance] Bitbake build-appliance-
>> image getting failed during building image due to webkitgtk package
>> Does it mean the Build-Appliance is non functioning ?  It was broken
>> at the Sumo release time as well. Should it be dropped as the release
>> criteria?
> Build-appliance is a tricky test as it tests multiple things, roughly:
>
> * vmdk images under vmware
> * the web browser
> * toaster
> * whether we can self host (build poky within poky)
>
> The fact the webkit recipe failed to build may be due to several
> reasons:
>
> * random race type condition
> * lack of memory in the VM
> * phase of the moon
> * other things
>
> I'm not convinced its a release blocker, or that it invalidates the b-a 
> test, or that it would even reproduce. If it does reproduce that would
> be more interesting and easier to debug.

ok, but is the b-a functional  in 2.6?

- armin

>
> I do think we're going to have to split up the b-a test in 2.7 so that
> even if its not manual QA'd, we can automatically test some pieces of
> what it covers.
>
> Cheers,
>
> Richard
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[akuster808]

On 11/10/18 8:25 AM, richard.pur...@linuxfoundation.org wrote:
> On Fri, 2018-11-09 at 09:24 +, Jain, Sangeeta wrote:
>> 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
> Thanks Sangeeta and team!
>
> Now we have the QA report for YP 2.6 M4 rc1 (Final 2.6) we need to make
> a release go or nogo decision. To do this we have the following:
>  
> QA Report: 
> https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1
> Release Criteria: 
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status#Milestone_4.2FFinal_-_Target_Oct._26.2C_2018
>
> We'd be happy to take representations from members and the community to
> help reach that decision.

Regarding.

*Bug 12991* 
-[2.6 M4 RC1][Build-Appliance] Bitbake build-appliance-image getting
failed during building image due to webkitgtk package

Does it mean the Build-Appliance is non functioning ?  It was broken at
the Sumo release time as well. Should it be dropped as the release criteria?

- Armin

> My personal view is that whilst there are a number of issues present in
> rc1, we should release it, collect up fixes on the thud branch (aleady
> happening) and plan on a 2.6.1 as soon as it looks like we have enough
> critical mass behind those as opposed to an rc2 and further delays to
> the release.
>
> Cheers,
>
> Richard
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] [yocto-kernel-cache][v4.4][PATCH] kver: bump to v4.4.147

[akuster808]

On 11/6/18 2:42 PM, Bruce Ashfield wrote:
> On 2018-11-06 5:10 PM, akuster808 wrote:
>>
>> On 11/6/18 2:05 PM, Khem Raj wrote:
>>> On Tue, Nov 6, 2018 at 1:57 PM Armin Kuster 
>>> wrote:
>>>> Signed-off-by: Armin Kuster
>>>> ---
>>>>   kver | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/kver b/kver
>>>> index 7b008cd..5ccc572 100644
>>>> --- a/kver
>>>> +++ b/kver
>>>> @@ -1 +1 @@
>>>> -v4.4.141
>>>> +v4.4.147
>>> why not 4.4.162
>>
>> because linux-yocto-4.4
>> <http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/> is not
>> at 4.4.162. I am just trying to use the latest in that kernel repo.
>
> Did you want .162 ? I have a whole set of -stable updates staged
> here, but haven't pushed anything since releases are imminent.

We are a day or two away from freezing for a Rocko QA run so if I can
get it sometime tomorrow, I should be able to  get some runtime on that
update otherwise no need to rush things.

- armin

>
> But in the case of 4.4, I could lift my freeze, given that the kernel
> recipe isn't active in master, hence the release schedule is
> different.
>

> Bruce
>
>>
>>
>> - armin
>>
>>>> -- 
>>>> 2.7.4
>>>>
>>>> -- 
>>>> ___
>>>> 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] [yocto-kernel-cache][v4.4][PATCH] kver: bump to v4.4.147

[akuster808]

On 11/6/18 2:05 PM, Khem Raj wrote:
> On Tue, Nov 6, 2018 at 1:57 PM Armin Kuster  wrote:
>> Signed-off-by: Armin Kuster 
>> ---
>>  kver | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kver b/kver
>> index 7b008cd..5ccc572 100644
>> --- a/kver
>> +++ b/kver
>> @@ -1 +1 @@
>> -v4.4.141
>> +v4.4.147
> why not 4.4.162

because linux-yocto-4.4
 is not at
4.4.162. I am just trying to use the latest in that kernel repo.


- armin

>
>> --
>> 2.7.4
>>
>> --
>> ___
>> 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] [OE-core] OEDAM @ SCaLE 2019

[akuster808]

Morning Trevor,

On 11/1/18 7:27 PM, Trevor Woerner wrote:
> Hi Jon,
>
> On Thu, Nov 1, 2018 at 3:56 PM Jon Mason  > wrote:
>
> I am planning on being at SCaLE (assuming the OEDEM happens there).
>
> Many corporate travel budgets are tied to presenting at conferences.
> So, if we could somehow get a track there (which might be too late in
> the game to do now), then we might be able to get enough people
> present to make it happen and pull in others whose budget is more
> flexible.
>
>
> As it turns out, I'll be organising the YP/OE Miniconf that will most
> likely be run on the Sunday. I was going to send out a separate email
> discussing the Miniconf, but I guess now is as good a time as any :-)


I would like a some clarification. As fas as the OE Board knows, we had
one room available on Sunday. Is this the same room or did you find some
other space at the venue? I am a bit confused about the messaging. The
subject and Jon's statement are all about OEDaM but your addition to
this tread is about a Miniconf. Is the Miniconf a separate thing?

>
> While it's true that the CFP has closed for SCaLE, I plan to open my
> own CFP specifically for the Miniconf, and I don't plan to close it
> until closer to the conference itself. I want to encourage people to
> give talks about current things, as such, having a CFP close this
> early wouldn't do.
>
> We haven't decided on a format for the Miniconf, exactly, if we have
> traditional talks, we'll have 6 sessions (2 before lunch, 4 after).
> But depending on interest and what sort of proposals we get, we might
> do some longer, some shorter talks.


May I ask who "We" are? AFAIK, Behan and Tom are doing a *-ale tracks at
Scale.


- armin

>
>  I hope this helps. Best regards,
>     Trevor
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] OEDAM @ SCaLE 2019

[akuster808]

Trevor,


On 11/1/18 7:04 AM, Trevor Woerner wrote:
> Hello Fellow YP/OE Enthusiasts!
>
> There were discussions at our recent OEDEM regarding:
> - our next developers meeting
> - SCaLE 2019
> - expanding/adding to the YP/OE presence at conferences (i.e. our own
>   miniconf?)
>
> Please see time indices: 12:13 and 16:45
> https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk

Could you please give us a day's notice the next time so we can properly
set the perms for our minutes.

- armin

>
> Unfortunately, although lots of opinions were expressed, nothing concrete was
> decided. Many people pointed out that their travel budgets are already
> strained or maxed out, so adding another conference would be difficult if not
> impossible. It's unclear how many "core" YP/OE people might show up at next
> year's SCaLE. Also, given that this year's ELC scheduling hiccup is a one-off,
> maybe it doesn't make as much sense to put in all the work required to run an
> OEDAM at SCaLE if it's only ever going to happen once. Therefore I think I can
> safely say the organizing committee for YP/OE Things at SCaLE 2019 is leaning
> towards not running an OEDAM.
>
> It's not too late to change our plans. If a large number of core people reply
> to this email saying they want and OEDAM in March and will be available in
> Pasadena, then we could accommodate it. It's just that we didn't leave
> Edinburgh with the feeling that an OEDAM at SCaLE was feasible. Also, at this
> point SCaLE isn't on the radars of many of the core YP/OE people, and
> currently the conference tends to attract users rather than developers (or so
> is my impression).
>
> Thoughts?
>
> Best regards,
>   Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] tzdata overwrites existing localtime/zoneinfo?

[akuster808]

On 10/28/18 6:31 PM, Anders Montonen wrote:
> Hi,
>
>> On 28 Oct 2018, at 17:27, akuster808  wrote:
>> On 10/25/18 5:43 PM, Anders Montonen wrote:
>>> It seems to me that the tzdata package will overwrite whatever the current 
>>> time zone is with its default. This is not great if you’re upgrading the 
>>> package on an existing system. Should the creation of the file and link be 
>>> removed from the do_install and only be done in the pkg_postinst?
>> Timely email.. 2018g just got release. I will take a look at this issue
>> shortly.
> A colleague pointed out that although ${sysconfdir}/localtime is added to 
> CONFFILES, the get_conffiles() function in package.bbclass explicitly removes 
> symlinks from the list of configuration files.

Have you tried setting INSTALL_TIMEZONE_FILE="0" in your local.conf?

- armin

>
> Regards,
> Anders Montonen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] tzdata overwrites existing localtime/zoneinfo?

[akuster808]

On 10/25/18 5:43 PM, Anders Montonen wrote:
> Hi,
>
> It seems to me that the tzdata package will overwrite whatever the current 
> time zone is with its default. This is not great if you’re upgrading the 
> package on an existing system. Should the creation of the file and link be 
> removed from the do_install and only be done in the pkg_postinst?

Timely email.. 2018g just got release. I will take a look at this issue
shortly.


- armin

>
> Regards,
> Anders Montonen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto