date:20190723

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread qwang2



On 7/23/19 10:32 PM, Bruce Ashfield wrote:

On Tue, Jul 23, 2019 at 9:20 AM Yunguo Wei  wrote:



在 2019/7/23 21:03, qwang2 写道:

On 7/23/19 8:41 PM, Bruce Ashfield wrote:

On Tue, Jul 23, 2019 at 1:29 AM qwang2 
wrote:

On 7/22/19 11:34 PM, Bruce Ashfield wrote:

On Mon, Jul 22, 2019 at 1:24 AM  wrote:

From: Quanyang Wang 

Hi Bruce,

Would you please help merge these 2 patches to linux-yocto-dev
standard/xlnx-soc branch?

I've merged the patches.

Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
created a set of v5.2 branches in the main linux-yocto repository, and
I have merged the xlnx-soc work there.

So if you can try switching to:

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc


The content is the same as the linux-yocto-dev branch.

I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
quite ready yet. Contact me if you have trouble building that branch
without the recipes and I  can send you the in progress ones.

Also, if you do a port to 5.3, let me know and we can re-establish the
branch in linux-yocto-dev.

Hi Bruce,

I will do a port to 5.3.  But before I finish porting, I hope we can
retain the branch standard/xlnx-soc

I have 5.3-rc1 building and booting with the base set of features now.

Is there a reason why the branch I created in linux-yocto/5.2 won't
work while you are doing the port ? I'd like to push the 5.3 kernel
changes in the next day or so, and they will clobber that branch.

Hi Bruce,

For me, I plan to begin porting to 5.3 after I fix bugs and enable the
remaining

features. So I hope to maintain this branch in linux-yocto-dev but not
only linux-yocto.

But if retaining this branch bring inconvience, you can delete it.

I will switch to linux-yocto/5.2 to do the fixing bug.

Bruce,

Another reason is we have some test always tracking on
linux-yocto-dev/standard/xlnx-soc, rather than
linux-yocto/v5.2/standard/xlnx-soc.
There might be a gap between 5.3 changes is pushed and port for v5.3 is
done. So the xlnx SDK full features can't be tested during that time.

But anyway, please go ahead with your change if that is a standard
procedure, we will tune our internal plan accordingly. And we will do

Outside of the repo being different, and the branch having a v5.2/
prefix, the content is identical between linux-yocto-dev and the
linux-yocto tree. So hopefully, outside of updating which recipe you
use to build the BSP, that's the only difference. As I mentioned, I
can provide you with the linux-yocto_5.2 recipes before I complete all
my system level testing on them, if not having the recipes is a
problem for using that branch.

I always move linux-yocto-dev forward as soon as I can, and those
jumps are rebases/non-fastforward.

That being said, I can keep the old branch in -dev around on 5.2
content, while the rest of the tree is v5.3. There just won't be the
branch prefixes to keep things straight. Since you are likely the only
developers using that -soc branch, it shouldn't be a problem.

Let me know what is easiest for you, since I do want to support your
development efforts.


Hi Bruce,

It would be best that the standard/xlnx-soc branch in linux-yocto-dev is 
kept


at 5.2 content. Then after I fix bugs and finishing porting to 5.3, I 
will send request


to re-create this branch.

Thanks,

Quanyang



Bruce


the v5.3 port ASAP.

Regards,
Yunguo


Thanks,

Quanyang


Bruce


and don't delete it.

Thanks,

Quanyang


Bruce


Limeng (1):
 driver: pcie: reset pcie device with MIO31 on xilinx-zcu102
platform

Quanyang Wang (1):
 drm: xlnx: zynqmp_dp: initialize delayed work before enable
interrupts

.../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
drivers/pci/controller/pcie-xilinx-nwl.c  | 35
+++
3 files changed, 38 insertions(+), 1 deletion(-)

--
2.17.1






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

[yocto] PREMIRROR

2019-07-23 Thread Russell Peterson

Hello,

I am looking to have bitbake pick up files for a particular recipe from a
local git repository using the PREMIRROR functionality.

Basically, the recipe (bb file) points to github but in my local build I
add PREMIRROR_prepend = "git://.*/.*
git:///local/path/BASENAME;protocol=file\n"

I will probably make the git regular expression more exact for my specific
github repo but this works for now.

This all works (as I deleted the github download from the local download
directory) because I can see in the do_fetch log and the correct (local)
repo was found and placed in the DL_DIR.

Problem is, do_unpack fails because it appears to be looking for the
original (github) SRC_URI.  Then it complains about "no up to date source
found: clone or directory not available or not up to date (shallow clone
not enabled)"

Any help on what I am missing would be appreciated.

Regards,

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

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

2019-07-23 Thread Alexander Kanavin

On Tue, 23 Jul 2019 at 20:49,  wrote:

>
>- There are patches available which enable runqueue optimisations
>based on output comparisons of tasks. This removes the need to run later
>tasks if the output is unchanged and is based upon the previous hash
>equivalence server work. This feature should be a significant win for the
>users and is now working to a level where we’ll likely make this a key
>feature of the next release.
>
> This is going to be awesome! Maybe this achievement should get wider
exposure via a LWN article? (provided they accept the submission)

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

[yocto] Yocto Project Status WW30'19

2019-07-23 Thread sjolley.yp.pm

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: Anuj 
*   SWAT team rotation: Anuj -> Paul on July 26, 2019
*   SWAT team rotation: Paul -> Ross on Aug. 2, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 25th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday August 6th at 8am PDT (
 https://zoom.us/j/990892712) 
*   Twitch - Next event is Tuesday August 6th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   2.7.1 was released
*   2.6.3 has patches pending review and then will be built
*   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
*   There are ongoing discussions on a few key topics which are
summarized here for convenience. Please contribute if you have an interest
in these areas:

*   Running the testsuites for glibc/binutils/gcc
*   Moving lsb to its own layer
*   Removing poky-lsb in favour of some configuration fragments
*   Reproducibility
*   Minimizing python2 dependencies
*   Configuration of init systems

*   Changing poky's init system default to systemd is running into a
large number of testing failures on the autobuilder which puts that change
at risk.
*   The autobuilder performance problem when stopping builds has been
tracked down and fixed. The controller was also upgraded for some
performance improvements (thanks Michael).
*   There are patches available which enable runqueue optimisations
based on output comparisons of tasks. This removes the need to run later
tasks if the output is unchanged and is based upon the previous hash
equivalence server work. This feature should be a significant win for the
users and is now working to a level where we'll likely make this a key
feature of the next release.

 

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 released.
*   YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
before 2.8 M2.

 

Tracking Metrics:

*   WDD 2483 (last week 2498) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1499 (last week 1502)
*   Patches in the Pending State: 623 (42%) [last week 630 (42%)]

 

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] Recommended practice to live together hardcoded Linux GIDs with dynamic GIDs

2019-07-23 Thread Javier Tiá


Hi,

On a random manner, these errors appear:

ERROR: do_install: groupadd command did not succeed
ERROR: do_install: Function failed: useradd_sysroot

It's hard to reproduce. Tried several times to reproduce the error with 
`bitbake -c install ` and `bitbake -C install `. It is 
the only information we have from the build logs. Sounds like a race 
condition.


The recipe is creating several hardcoded Linux groups (GID) with useradd 
class.


In this thread [1] from 2014, there is a practice to the limitation of 
users/groups creation dependency.


[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2014-June/211737.html


Is there to this date a better practice to make work together the Linux 
hardcoded GIDs with the dynamic GID?


Should be all the GIDs be created dynamically?

Poky 2.1 is being used.


Thanks,

--
Javier Tiá

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

[yocto] [meta][PATCH] qemu: add a patch fixing the native build on newer kernels

2019-07-23 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

The build fails on qemu-native if we're using kernels after commit
0768e17073dc527ccd18ed5f96ce85f9985e9115. This adds an upstream
patch that fixes the issue.

Signed-off-by: Bartosz Golaszewski 
---
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 ...o-handle-variably-sized-SIOCGSTAMP-w.patch | 339 ++
 2 files changed, 340 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 7f0b3a7a73..46c40b7d4f 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -24,6 +24,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \

file://0009-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \

file://0010-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
file://0013-target-arm-Fix-vector-operation-segfault.patch \
+   
file://0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch \
   file://CVE-2019-12155.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
 
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
new file mode 100644
index 00..2feb567f1c
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
@@ -0,0 +1,339 @@
+From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski 
+Date: Tue, 23 Jul 2019 17:50:00 +0200
+Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new
+ kernels
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The SIOCGSTAMP symbol was previously defined in the
+asm-generic/sockios.h header file. QEMU sees that header
+indirectly via sys/socket.h
+
+In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
+the asm-generic/sockios.h header no longer defines SIOCGSTAMP.
+Instead it provides only SIOCGSTAMP_OLD, which only uses a
+32-bit time_t on 32-bit architectures.
+
+The linux/sockios.h header then defines SIOCGSTAMP using
+either SIOCGSTAMP_OLD or SIOCGSTAMP_NEW as appropriate. If
+SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
+on 32-bit architectures
+
+To cope with this we must now convert the old and new type from
+the target to the host one.
+
+Signed-off-by: Daniel P. Berrangé 
+Signed-off-by: Laurent Vivier 
+Reviewed-by: Arnd Bergmann 
+Message-Id: <20190718130641.15294-1-laur...@vivier.eu>
+Signed-off-by: Laurent Vivier 
+Signed-off-by: Bartosz Golaszewski 
+---
+Uptream-status: Backport (upstream commit: 
6d5d5dde9adb5acb32e6b8e3dfbf47fff0f308d2)
+
+ linux-user/ioctls.h|  21 +-
+ linux-user/syscall.c   | 140 +
+ linux-user/syscall_defs.h  |  30 +++-
+ linux-user/syscall_types.h |   6 --
+ 4 files changed, 159 insertions(+), 38 deletions(-)
+
+diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
+index ae8951625f..e6a27ad9d6 100644
+--- a/linux-user/ioctls.h
 b/linux-user/ioctls.h
+@@ -219,8 +219,25 @@
+   IOCTL(SIOCGRARP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_arpreq)))
+   IOCTL(SIOCGIWNAME, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_char_ifreq)))
+   IOCTL(SIOCGPGRP, IOC_R, MK_PTR(TYPE_INT)) /* pid_t */
+-  IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
+-  IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
++
++  /*
++   * We can't use IOCTL_SPECIAL() because it will set
++   * host_cmd to XXX_OLD and XXX_NEW and these macros
++   * are not defined with kernel prior to 5.2.
++   * We must set host_cmd to the same value as in target_cmd
++   * otherwise the consistency check in syscall_init()
++   * will trigger an error.
++   * host_cmd is ignored by the do_ioctl_XXX() helpers.
++   * FIXME: create a macro to define this kind of entry
++   */
++  { TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
++"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
++  { TARGET_SIOCGSTAMPNS_OLD, TARGET_SIOCGSTAMPNS_OLD,
++"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS },
++  { TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMP_NEW,
++"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP },
++  { TARGET_SIOCGSTAMPNS_NEW, TARGET_SIOCGSTAMPNS_NEW,
++"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS },
+ 
+   IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+   IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(TYPE_INT))
+diff --git a/linux-user/syscall.c b/linux-user/syscall.c
+index 96cd4bf86d..6df480e13d 100644
+--- a/linux-user/syscall.c
 b/linux-user/syscall.c
+@@ -37,6 +37,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -1139,8 +1140,9 @@ static inline abi_long

[yocto] Minutes: Yocto Project Monthly Meeting 7/23/2019

2019-07-23 Thread Reyna, David

Yocto Project Monthly Meeting
MINUTES: 7/23/2019

Attendees: Richard, JoshuaW, Bruce, Tim, Vineela, David, Trevor, Jan-Simon (at 
end)

Note: consolidated bridge for Tuesday meetings: https://zoom.us/j/990892712

RP:
  * Weekly status update will go out later today
  * 2.7.1 out last week
  * 2.6.3. due out Wednesday
  * Autobuilder performance issues finally found and fixed
  * Some issues with default poky init system (sysv vs. system)

Richard: Runqueue optimizations appear to be working, though some performance 
issues (sometimes 3 minute break for calculations). Example of feature, if 
“m4-native” has change but do_populate_sstate same then sstate left the same 
and no cascade of rebuilds to rest of packages. Richard quite excited about 
this, especially having this early in the development cycle.

Joshua: What about non-local implementations? Richard: focusing on local hash 
state equivalency first. Good step towards reproducibility. Next would then be 
non-local support. Goal is less duplicated in sstate-caches, which will help 
with sstate-cache mirrors. Joshua: would appear that non-local users would 
still need the sstate and database together.

Richard: runqueue api clunky in that it supports multiple tasked formats. Would 
like to consolidate them but that would require a “flag day” for everyone to 
make the transition.

Richard: changes could run against earlier releases like Warrior/Thud with 
minor patches if we would want to do so.

Bruce: 5.3 kernel dropped, so he is busy with that.

- David


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

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread Bruce Ashfield

On Tue, Jul 23, 2019 at 9:20 AM Yunguo Wei  wrote:
>
>
>
> 在 2019/7/23 21:03, qwang2 写道:
> >
> > On 7/23/19 8:41 PM, Bruce Ashfield wrote:
> >> On Tue, Jul 23, 2019 at 1:29 AM qwang2 
> >> wrote:
> >>>
> >>> On 7/22/19 11:34 PM, Bruce Ashfield wrote:
>  On Mon, Jul 22, 2019 at 1:24 AM  wrote:
> > From: Quanyang Wang 
> >
> > Hi Bruce,
> >
> > Would you please help merge these 2 patches to linux-yocto-dev
> > standard/xlnx-soc branch?
>  I've merged the patches.
> 
>  Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
>  created a set of v5.2 branches in the main linux-yocto repository, and
>  I have merged the xlnx-soc work there.
> 
>  So if you can try switching to:
> 
>  https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc
> 
> 
>  The content is the same as the linux-yocto-dev branch.
> 
>  I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
>  quite ready yet. Contact me if you have trouble building that branch
>  without the recipes and I  can send you the in progress ones.
> 
>  Also, if you do a port to 5.3, let me know and we can re-establish the
>  branch in linux-yocto-dev.
> >>> Hi Bruce,
> >>>
> >>> I will do a port to 5.3.  But before I finish porting, I hope we can
> >>> retain the branch standard/xlnx-soc
> >> I have 5.3-rc1 building and booting with the base set of features now.
> >>
> >> Is there a reason why the branch I created in linux-yocto/5.2 won't
> >> work while you are doing the port ? I'd like to push the 5.3 kernel
> >> changes in the next day or so, and they will clobber that branch.
> >
> > Hi Bruce,
> >
> > For me, I plan to begin porting to 5.3 after I fix bugs and enable the
> > remaining
> >
> > features. So I hope to maintain this branch in linux-yocto-dev but not
> > only linux-yocto.
> >
> > But if retaining this branch bring inconvience, you can delete it.
> >
> > I will switch to linux-yocto/5.2 to do the fixing bug.
> Bruce,
>
> Another reason is we have some test always tracking on
> linux-yocto-dev/standard/xlnx-soc, rather than
> linux-yocto/v5.2/standard/xlnx-soc.
> There might be a gap between 5.3 changes is pushed and port for v5.3 is
> done. So the xlnx SDK full features can't be tested during that time.
>
> But anyway, please go ahead with your change if that is a standard
> procedure, we will tune our internal plan accordingly. And we will do

Outside of the repo being different, and the branch having a v5.2/
prefix, the content is identical between linux-yocto-dev and the
linux-yocto tree. So hopefully, outside of updating which recipe you
use to build the BSP, that's the only difference. As I mentioned, I
can provide you with the linux-yocto_5.2 recipes before I complete all
my system level testing on them, if not having the recipes is a
problem for using that branch.

I always move linux-yocto-dev forward as soon as I can, and those
jumps are rebases/non-fastforward.

That being said, I can keep the old branch in -dev around on 5.2
content, while the rest of the tree is v5.3. There just won't be the
branch prefixes to keep things straight. Since you are likely the only
developers using that -soc branch, it shouldn't be a problem.

Let me know what is easiest for you, since I do want to support your
development efforts.

Bruce

> the v5.3 port ASAP.
>
> Regards,
> Yunguo
>
> >
> > Thanks,
> >
> > Quanyang
> >
> >>
> >> Bruce
> >>
> >>> and don't delete it.
> >>>
> >>> Thanks,
> >>>
> >>> Quanyang
> >>>
>  Bruce
> 
> > Limeng (1):
> > driver: pcie: reset pcie device with MIO31 on xilinx-zcu102
> > platform
> >
> > Quanyang Wang (1):
> > drm: xlnx: zynqmp_dp: initialize delayed work before enable
> > interrupts
> >
> >.../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
> >drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
> >drivers/pci/controller/pcie-xilinx-nwl.c  | 35
> > +++
> >3 files changed, 38 insertions(+), 1 deletion(-)
> >
> > --
> > 2.17.1
> >
> >>
> >>
>


-- 
- 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: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread Yunguo Wei




在 2019/7/23 21:03, qwang2 写道:


On 7/23/19 8:41 PM, Bruce Ashfield wrote:
On Tue, Jul 23, 2019 at 1:29 AM qwang2  
wrote:


On 7/22/19 11:34 PM, Bruce Ashfield wrote:

On Mon, Jul 22, 2019 at 1:24 AM  wrote:

From: Quanyang Wang 

Hi Bruce,

Would you please help merge these 2 patches to linux-yocto-dev 
standard/xlnx-soc branch?

I've merged the patches.

Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
created a set of v5.2 branches in the main linux-yocto repository, and
I have merged the xlnx-soc work there.

So if you can try switching to:

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc 



The content is the same as the linux-yocto-dev branch.

I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
quite ready yet. Contact me if you have trouble building that branch
without the recipes and I  can send you the in progress ones.

Also, if you do a port to 5.3, let me know and we can re-establish the
branch in linux-yocto-dev.

Hi Bruce,

I will do a port to 5.3.  But before I finish porting, I hope we can
retain the branch standard/xlnx-soc

I have 5.3-rc1 building and booting with the base set of features now.

Is there a reason why the branch I created in linux-yocto/5.2 won't
work while you are doing the port ? I'd like to push the 5.3 kernel
changes in the next day or so, and they will clobber that branch.


Hi Bruce,

For me, I plan to begin porting to 5.3 after I fix bugs and enable the 
remaining


features. So I hope to maintain this branch in linux-yocto-dev but not 
only linux-yocto.


But if retaining this branch bring inconvience, you can delete it.

I will switch to linux-yocto/5.2 to do the fixing bug.

Bruce,

Another reason is we have some test always tracking on 
linux-yocto-dev/standard/xlnx-soc, rather than 
linux-yocto/v5.2/standard/xlnx-soc.
There might be a gap between 5.3 changes is pushed and port for v5.3 is 
done. So the xlnx SDK full features can't be tested during that time.


But anyway, please go ahead with your change if that is a standard 
procedure, we will tune our internal plan accordingly. And we will do 
the v5.3 port ASAP.


Regards,
Yunguo



Thanks,

Quanyang



Bruce


and don't delete it.

Thanks,

Quanyang


Bruce


Limeng (1):
driver: pcie: reset pcie device with MIO31 on xilinx-zcu102 
platform


Quanyang Wang (1):
drm: xlnx: zynqmp_dp: initialize delayed work before enable 
interrupts


   .../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
   drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
   drivers/pci/controller/pcie-xilinx-nwl.c  | 35 
+++

   3 files changed, 38 insertions(+), 1 deletion(-)

--
2.17.1






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

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread qwang2




On 7/23/19 8:41 PM, Bruce Ashfield wrote:

On Tue, Jul 23, 2019 at 1:29 AM qwang2  wrote:


On 7/22/19 11:34 PM, Bruce Ashfield wrote:

On Mon, Jul 22, 2019 at 1:24 AM  wrote:

From: Quanyang Wang 

Hi Bruce,

Would you please help merge these 2 patches to linux-yocto-dev 
standard/xlnx-soc branch?

I've merged the patches.

Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
created a set of v5.2 branches in the main linux-yocto repository, and
I have merged the xlnx-soc work there.

So if you can try switching to:

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc

The content is the same as the linux-yocto-dev branch.

I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
quite ready yet. Contact me if you have trouble building that branch
without the recipes and I  can send you the in progress ones.

Also, if you do a port to 5.3, let me know and we can re-establish the
branch in linux-yocto-dev.

Hi Bruce,

I will do a port to 5.3.  But before I finish porting, I hope we can
retain the branch standard/xlnx-soc

I have 5.3-rc1 building and booting with the base set of features now.

Is there a reason why the branch I created in linux-yocto/5.2 won't
work while you are doing the port ? I'd like to push the 5.3 kernel
changes in the next day or so, and they will clobber that branch.


Hi Bruce,

For me, I plan to begin porting to 5.3 after I fix bugs and enable the 
remaining


features. So I hope to maintain this branch in linux-yocto-dev but not 
only linux-yocto.


But if retaining this branch bring inconvience, you can delete it.

I will switch to linux-yocto/5.2 to do the fixing bug.

Thanks,

Quanyang



Bruce


and don't delete it.

Thanks,

Quanyang


Bruce


Limeng (1):
driver: pcie: reset pcie device with MIO31 on xilinx-zcu102 platform

Quanyang Wang (1):
drm: xlnx: zynqmp_dp: initialize delayed work before enable interrupts

   .../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
   drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
   drivers/pci/controller/pcie-xilinx-nwl.c  | 35 +++
   3 files changed, 38 insertions(+), 1 deletion(-)

--
2.17.1





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

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

2019-07-23 Thread Bruce Ashfield

On Tue, Jul 23, 2019 at 1:29 AM qwang2  wrote:
>
>
> On 7/22/19 11:34 PM, Bruce Ashfield wrote:
> > On Mon, Jul 22, 2019 at 1:24 AM  wrote:
> >> From: Quanyang Wang 
> >>
> >> Hi Bruce,
> >>
> >> Would you please help merge these 2 patches to linux-yocto-dev 
> >> standard/xlnx-soc branch?
> > I've merged the patches.
> >
> > Also note: I'm about to move linux-yocto-dev to v5.3-rc1, so I've
> > created a set of v5.2 branches in the main linux-yocto repository, and
> > I have merged the xlnx-soc work there.
> >
> > So if you can try switching to:
> >
> > https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/log/?h=v5.2/standard/xlnx-soc
> >
> > The content is the same as the linux-yocto-dev branch.
> >
> > I'm going to generate linux-yocto_5.2 recipes shortly, but they aren't
> > quite ready yet. Contact me if you have trouble building that branch
> > without the recipes and I  can send you the in progress ones.
> >
> > Also, if you do a port to 5.3, let me know and we can re-establish the
> > branch in linux-yocto-dev.
>
> Hi Bruce,
>
> I will do a port to 5.3.  But before I finish porting, I hope we can
> retain the branch standard/xlnx-soc

I have 5.3-rc1 building and booting with the base set of features now.

Is there a reason why the branch I created in linux-yocto/5.2 won't
work while you are doing the port ? I'd like to push the 5.3 kernel
changes in the next day or so, and they will clobber that branch.

Bruce

>
> and don't delete it.
>
> Thanks,
>
> Quanyang
>
> >
> > Bruce
> >
> >>
> >> Limeng (1):
> >>driver: pcie: reset pcie device with MIO31 on xilinx-zcu102 platform
> >>
> >> Quanyang Wang (1):
> >>drm: xlnx: zynqmp_dp: initialize delayed work before enable interrupts
> >>
> >>   .../boot/dts/xilinx/zynqmp-zcu102-revA.dts|  1 +
> >>   drivers/gpu/drm/xlnx/zynqmp_dp.c  |  3 +-
> >>   drivers/pci/controller/pcie-xilinx-nwl.c  | 35 +++
> >>   3 files changed, 38 insertions(+), 1 deletion(-)
> >>
> >> --
> >> 2.17.1
> >>
> >



-- 
- 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

[yocto] install -m 0644 ${S}/lib/systemd/system/${PN}.service ${D}/${systemd_system_unitdir} failed to add service file to ${systemd_system_unitdir}

2019-07-23 Thread JH

Hi,

I set up the configuration for service files at following:

SYSTEMD_SERVICE_${PN} = "${PN}.service bootstrap.service"

do_install() {
..
install -d ${D}/${systemd_system_unitdir}
install -m 0644 ${S}/lib/systemd/system/*.service
${D}/${systemd_system_unitdir}
}

Despite both service files are in build directory, the final image
installation does not include those service files, appreciate anyone
help.

Thank you.

Kind regards,

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

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

2019-07-23 Thread Yi Zhao




On 7/23/19 2:38 PM, Akuster808 wrote:



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.



That's OK. Thanks.


//Yi



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
--- a/meta-security-compliance/recipes-openscap/openscap/openscap_git.bb
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap_git.bb
@@ -3,9 +3,9 @@
SUMARRY = "NIST Certified SCAP 1.2 toolkit with OE

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

2019-07-23 Thread 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: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

[yocto] PREMIRROR

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

[yocto] Yocto Project Status WW30'19

[yocto] Recommended practice to live together hardcoded Linux GIDs with dynamic GIDs

[yocto] [meta][PATCH] qemu: add a patch fixing the native build on newer kernels

[yocto] Minutes: Yocto Project Monthly Meeting 7/23/2019

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc][PATCH 0/2] xilinx-zynqmp: fix 2 issues in zcu102 Rev1.0 board

[yocto] install -m 0644 ${S}/lib/systemd/system/${PN}.service ${D}/${systemd_system_unitdir} failed to add service file to ${systemd_system_unitdir}

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

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

14 matches

Site Navigation

Mail list logo

Footer information