[OE-core] [PATCH 2/2] musl: Delete GLIBC_LDSO before creating symlink with lnr

2019-08-13 Thread Khem Raj
Fixes rebuild failures after say do_compile fails

| ./tools/install.sh -D -r 
/mnt/a/yoe/build/tmp/work/riscv64-yoe-linux-musl/musl/1.1.23+gitAUTOINC+d0b547dfb5-r0/image/usr/lib/libc.so
 
/mnt/a/yoe/build/tmp/work/riscv64-yoe-linux-musl/musl/1.1.23+gitAUTOINC+d0b547dfb5-r0/image/lib/ld-musl-riscv64.so.1
 || true
| Traceback (most recent call last):
|   File "/mnt/a/yoe/sources/openembedded-core/scripts/lnr", line 24, in 

| os.symlink(target, linkname)
| FileExistsError: [Errno 17] File exists: 'image/usr/lib/libc.so' -> 
'/mnt/a/yoe/build/tmp/work/riscv64-yoe-linux-musl/musl/1.1.23+gitAUTOINC+d0b547dfb5-r0/imageNone'

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index 2633229b8c..b2991d4ed5 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -64,7 +64,7 @@ do_install() {
oe_runmake install DESTDIR='${D}'
 
install -d ${D}${bindir}
-   rm -f ${D}${bindir}/ldd
+   rm -f ${D}${bindir}/ldd ${D}${GLIBC_LDSO}
lnr ${D}${libdir}/libc.so ${D}${bindir}/ldd
lnr ${D}${libdir}/libc.so ${D}${GLIBC_LDSO}
for l in crypt dl m pthread resolv rt util xnet
-- 
2.22.0

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


[OE-core] [PATCH 1/2] linuxloader: Add entries for riscv64

2019-08-13 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/classes/linuxloader.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/linuxloader.bbclass b/meta/classes/linuxloader.bbclass
index b4c413494a..c0fbf26836 100644
--- a/meta/classes/linuxloader.bbclass
+++ b/meta/classes/linuxloader.bbclass
@@ -19,6 +19,8 @@ def get_musl_loader(d):
 dynamic_loader = 
"${base_libdir}/ld-musl-arm${ARMPKGSFX_ENDIAN}${ARMPKGSFX_EABI}.so.1"
 elif targetarch.startswith("aarch64"):
 dynamic_loader = 
"${base_libdir}/ld-musl-aarch64${ARMPKGSFX_ENDIAN_64}.so.1"
+elif targetarch.startswith("riscv64"):
+dynamic_loader = "${base_libdir}/ld-musl-riscv64${@['', 
'-sf'][d.getVar('TARGET_FPU') == 'soft']}.so.1"
 return dynamic_loader
 
 def get_glibc_loader(d):
@@ -42,6 +44,8 @@ def get_glibc_loader(d):
 dynamic_loader = "${base_libdir}/ld-linux.so.3"
 elif targetarch.startswith("aarch64"):
 dynamic_loader = 
"${base_libdir}/ld-linux-aarch64${ARMPKGSFX_ENDIAN_64}.so.1"
+elif targetarch.startswith("riscv64"):
+dynamic_loader = "${base_libdir}/ld-linux-riscv64-lp64${@['d', 
''][d.getVar('TARGET_FPU') == 'soft']}.so.1"
 return dynamic_loader
 
 def get_linuxloader(d):
-- 
2.22.0

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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-13 Thread Khem Raj
On Tue, Aug 13, 2019 at 12:18 PM Richard Purdie
 wrote:
>
> On Tue, 2019-08-13 at 10:04 +0100, Richard Purdie wrote:
> > On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> > > Comparing that build to a corresponding do-nothing build with Thud,
> > > the time difference matches those three minutes where I have no
> > > idea
> > > what bitbake is doing now that it didn’t need to do before…
> > >
> > > Hopefully these time degradations can be solved, because the
> > > current
> > > state of bitbake is barely usable. We also need to look into
> > > possible
> > > ways to improve the cooker output when it is running the setscene
> > > tasks so it makes some kind of sense again.
> >
> > We talked on irc and you pointed at the commit things started to go
> > wrong. Just to summarise things for the benefit of the list, this is
> > some quick testing I did:
> >
> > "bitbake -p; time bitbake core-image-minimal -n"
> >
> > 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> > 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> > 40.3s 7df31ff36892c2f9c65326b06b4c70
> > 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> > 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c
> > 76.9s master-next
> >
> > So basically the original changes showed a 25% hit but the
> > performance
> > of -next is dire.
> >
> > This is with no hash equiv server configured.
> >
> > It will vary depending on the target used (numbers with -sato for the
> > above would be interesting for comparision) and how much was or is in
> > sstate, they type of sstate mirror configured and so on.
> >
> > I really need to focus on getting the new code functioning correctly
> > before we attempt to optimise but if nobody tests the new code due to
> > performance problems we have a different issue. We also have a
> > scaling
> > problem with the hash server itself I need to fix to stop the
> > autobuilder throwing weird errors. I'm therefore a bit challenged on
> > where to start with it all :/.
>
> I had a glance at the profile output from master-next and the problem
> wasn't where I thought it would be, it was in the scheduler code. That
> is good as those classes are effectively independent of the other
> changes and hence are a separate fix.
>
> I've put a patch in -next which takes the above test to 36s which is
> close to the older bitbake.
>
> Could be interesting to see how it looks for others and different
> workloads.
>

will try it tonight

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


Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Bruce Ashfield
On Tue, Aug 13, 2019 at 11:39 PM Bruce Ashfield
 wrote:
>
> On Tue, Aug 13, 2019 at 11:04 PM Bruce Ashfield
>  wrote:
> >
> >
> >
> > On Tue, Aug 13, 2019 at 11:01 PM Hongzhi, Song  
> > wrote:
> >>
> >>
> >> On 8/14/19 10:53 AM, Bruce Ashfield wrote:
> >> >
> >> >
> >> > On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song
> >> > mailto:hongzhi.s...@windriver.com>> wrote:
> >> >
> >> >
> >> > On 8/13/19 8:27 PM, Bruce Ashfield wrote:
> >> > >
> >> > >
> >> > > On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
> >> > > mailto:hongzhi.s...@windriver.com>
> >> >  >> > >> wrote:
> >> > >
> >> > > A new patch let kernel source Documentation/Kconfig in top
> >> > Kconfig
> >> > > So kernel-devsrc should include Documentation/ too.
> >> > > Otherwise "make scripts" will fails.
> >> > >
> >> > > patch:
> >> > > commit b1663d7e3a7961fc45262fd68a89253f2803036c
> >> > > Author: Mauro Carvalho Chehab  >> > 
> >> > >  >> > >>
> >> > > Date:   Tue Jun 4 09:26:27 2019 -0300
> >> > >
> >> > > docs: Kbuild/Makefile: allow check for missing docs at
> >> > build time
> >> > >
> >> > > While this doesn't make sense for production Kernels, in
> >> > order to
> >> > > avoid regressions when documents are touched, let's add a
> >> > > check target at the make file.
> >> > >
> >> > > Signed-off-by: Mauro Carvalho Chehab
> >> > >  >> > 
> >> >  >> > >>
> >> > > Signed-off-by: Jonathan Corbet  >> > 
> >> > > >>
> >> > >
> >> > > Signed-off-by: Hongzhi.Song  >> > 
> >> > >  >> > >>
> >> > > ---
> >> > >  meta/recipes-kernel/linux/kernel-devsrc.bb
> >> > 
> >> > >  | 2 +-
> >> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> >> > 
> >> > > 
> >> > > b/meta/recipes-kernel/linux/kernel-devsrc.bb
> >> >  
> >> > > index 5ec5929..a874e06 100644
> >> > > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> >> > 
> >> > > 
> >> > > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> >> > 
> >> > > 
> >> > > @@ -65,7 +65,7 @@ do_install() {
> >> > >  )
> >> > >
> >> > >  # then drop all but the needed Makefiles/Kconfig files
> >> > > -rm -rf $kerneldir/build/Documentation
> >> > > +#rm -rf $kerneldir/build/Documentation
> >> > >
> >> > >
> >> > > In the spirit of keeping kernel-devsrc as small as possible (I have
> >> > > another patch pending if you really want the full kernel
> >> > source), this
> >> > > should only keep the Documentation/ files that are required to pass
> >> > > the check, not keep all of Documentation.
> >> >
> >> >
> >> > If you have a better patch, I am pleasure to accept it.
> >> >
> >> >
> >> > ???
> >> >
> >> > This is where you'd typically do a v2 of the patch after getting a
> >> > review of a change.
> >> >
> >> > But if you are refusing the feedback, then yes, I'll do a version of
> >> > the patch myself rather than just blindly copying in all of the
> >> > documentation. I'll submit it myself.
> >> >
> >> > RP/Ross, whoever is taking in patches, drop this version, and I'll do
> >> > my own.
> >>
> >>
> >> I am not very familiar with the kernel-devsrc.bb. I have no objection
> >> for your decision.
> >
> >
> > At a minimum, we shouldn't leave the commented out #rm -rf 
> > $kerneldir/build/Documentation, so I can do that and tweak the commit 
> > message a bit as well.
> >
> > Leave it with me, and I'll send it to the list (hopefully tomorrow) to be 
> > sure it still solves your problem.
>
> Aha. Now I see what is actually happening. On reading the patch, I
> thought you were requiring the existence of the *entire* Documentation
> directory, not just the Kbuild infrastructure that would be triggered
> if the documentation warning is enabled.
>
> I still want to change things just a bit, but I'll leave your
> Signed-off-by on the patch, since it won't be a structural 

Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Bruce Ashfield
On Tue, Aug 13, 2019 at 11:04 PM Bruce Ashfield
 wrote:
>
>
>
> On Tue, Aug 13, 2019 at 11:01 PM Hongzhi, Song  
> wrote:
>>
>>
>> On 8/14/19 10:53 AM, Bruce Ashfield wrote:
>> >
>> >
>> > On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song
>> > mailto:hongzhi.s...@windriver.com>> wrote:
>> >
>> >
>> > On 8/13/19 8:27 PM, Bruce Ashfield wrote:
>> > >
>> > >
>> > > On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
>> > > mailto:hongzhi.s...@windriver.com>
>> > > > >> wrote:
>> > >
>> > > A new patch let kernel source Documentation/Kconfig in top
>> > Kconfig
>> > > So kernel-devsrc should include Documentation/ too.
>> > > Otherwise "make scripts" will fails.
>> > >
>> > > patch:
>> > > commit b1663d7e3a7961fc45262fd68a89253f2803036c
>> > > Author: Mauro Carvalho Chehab > > 
>> > > > > >>
>> > > Date:   Tue Jun 4 09:26:27 2019 -0300
>> > >
>> > > docs: Kbuild/Makefile: allow check for missing docs at
>> > build time
>> > >
>> > > While this doesn't make sense for production Kernels, in
>> > order to
>> > > avoid regressions when documents are touched, let's add a
>> > > check target at the make file.
>> > >
>> > > Signed-off-by: Mauro Carvalho Chehab
>> > > > > 
>> > > > >>
>> > > Signed-off-by: Jonathan Corbet > > 
>> > > >>
>> > >
>> > > Signed-off-by: Hongzhi.Song > > 
>> > > > > >>
>> > > ---
>> > >  meta/recipes-kernel/linux/kernel-devsrc.bb
>> > 
>> > >  | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
>> > 
>> > > 
>> > > b/meta/recipes-kernel/linux/kernel-devsrc.bb
>> >  
>> > > index 5ec5929..a874e06 100644
>> > > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
>> > 
>> > > 
>> > > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
>> > 
>> > > 
>> > > @@ -65,7 +65,7 @@ do_install() {
>> > >  )
>> > >
>> > >  # then drop all but the needed Makefiles/Kconfig files
>> > > -rm -rf $kerneldir/build/Documentation
>> > > +#rm -rf $kerneldir/build/Documentation
>> > >
>> > >
>> > > In the spirit of keeping kernel-devsrc as small as possible (I have
>> > > another patch pending if you really want the full kernel
>> > source), this
>> > > should only keep the Documentation/ files that are required to pass
>> > > the check, not keep all of Documentation.
>> >
>> >
>> > If you have a better patch, I am pleasure to accept it.
>> >
>> >
>> > ???
>> >
>> > This is where you'd typically do a v2 of the patch after getting a
>> > review of a change.
>> >
>> > But if you are refusing the feedback, then yes, I'll do a version of
>> > the patch myself rather than just blindly copying in all of the
>> > documentation. I'll submit it myself.
>> >
>> > RP/Ross, whoever is taking in patches, drop this version, and I'll do
>> > my own.
>>
>>
>> I am not very familiar with the kernel-devsrc.bb. I have no objection
>> for your decision.
>
>
> At a minimum, we shouldn't leave the commented out #rm -rf 
> $kerneldir/build/Documentation, so I can do that and tweak the commit message 
> a bit as well.
>
> Leave it with me, and I'll send it to the list (hopefully tomorrow) to be 
> sure it still solves your problem.

Aha. Now I see what is actually happening. On reading the patch, I
thought you were requiring the existence of the *entire* Documentation
directory, not just the Kbuild infrastructure that would be triggered
if the documentation warning is enabled.

I still want to change things just a bit, but I'll leave your
Signed-off-by on the patch, since it won't be a structural change as I
thought.

But can you provide me your test steps ? Do you have a tweaked kernel
config that is enabling WARN_MISSING_DOCUMENTS and COMPILE_TEST ?

Bruce

>
> Bruce
>
>>
>>
>> Thanks,
>>
>> --Hongzhi
>>
>>
>> >
>> > Cheers,
>> >
>> > Bruce
>> >
>> >
>> > Thanks,
>> >
>> > --Hongzhi
>> >

Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Bruce Ashfield
On Tue, Aug 13, 2019 at 11:01 PM Hongzhi, Song 
wrote:

>
> On 8/14/19 10:53 AM, Bruce Ashfield wrote:
> >
> >
> > On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song
> > mailto:hongzhi.s...@windriver.com>> wrote:
> >
> >
> > On 8/13/19 8:27 PM, Bruce Ashfield wrote:
> > >
> > >
> > > On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
> > > mailto:hongzhi.s...@windriver.com>
> >  > >> wrote:
> > >
> > > A new patch let kernel source Documentation/Kconfig in top
> > Kconfig
> > > So kernel-devsrc should include Documentation/ too.
> > > Otherwise "make scripts" will fails.
> > >
> > > patch:
> > > commit b1663d7e3a7961fc45262fd68a89253f2803036c
> > > Author: Mauro Carvalho Chehab  > 
> > >  > >>
> > > Date:   Tue Jun 4 09:26:27 2019 -0300
> > >
> > > docs: Kbuild/Makefile: allow check for missing docs at
> > build time
> > >
> > > While this doesn't make sense for production Kernels, in
> > order to
> > > avoid regressions when documents are touched, let's add a
> > > check target at the make file.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab
> > >  > 
> >  > >>
> > > Signed-off-by: Jonathan Corbet  > 
> > > >>
> > >
> > > Signed-off-by: Hongzhi.Song  > 
> > >  > >>
> > > ---
> > >  meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > >  | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > > 
> > > b/meta/recipes-kernel/linux/kernel-devsrc.bb
> >  
> > > index 5ec5929..a874e06 100644
> > > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > > 
> > > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > > 
> > > @@ -65,7 +65,7 @@ do_install() {
> > >  )
> > >
> > >  # then drop all but the needed Makefiles/Kconfig files
> > > -rm -rf $kerneldir/build/Documentation
> > > +#rm -rf $kerneldir/build/Documentation
> > >
> > >
> > > In the spirit of keeping kernel-devsrc as small as possible (I have
> > > another patch pending if you really want the full kernel
> > source), this
> > > should only keep the Documentation/ files that are required to pass
> > > the check, not keep all of Documentation.
> >
> >
> > If you have a better patch, I am pleasure to accept it.
> >
> >
> > ???
> >
> > This is where you'd typically do a v2 of the patch after getting a
> > review of a change.
> >
> > But if you are refusing the feedback, then yes, I'll do a version of
> > the patch myself rather than just blindly copying in all of the
> > documentation. I'll submit it myself.
> >
> > RP/Ross, whoever is taking in patches, drop this version, and I'll do
> > my own.
>
>
> I am not very familiar with the kernel-devsrc.bb. I have no objection
> for your decision.
>

At a minimum, we shouldn't leave the commented out #rm -rf
$kerneldir/build/Documentation, so I can do that and tweak the commit
message a bit as well.

Leave it with me, and I'll send it to the list (hopefully tomorrow) to be
sure it still solves your problem.

Bruce


>
> Thanks,
>
> --Hongzhi
>
>
> >
> > Cheers,
> >
> > Bruce
> >
> >
> > Thanks,
> >
> > --Hongzhi
> >
> >
> > > Bruce
> > >
> > >  rm -rf $kerneldir/build/scripts
> > >  rm -rf $kerneldir/build/include
> > >
> > > --
> > > 2.8.1
> > >
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > 
> > >  > >
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > >
> > >
> > >
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness
> > 

Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Hongzhi, Song


On 8/14/19 10:53 AM, Bruce Ashfield wrote:



On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song 
mailto:hongzhi.s...@windriver.com>> wrote:



On 8/13/19 8:27 PM, Bruce Ashfield wrote:
>
>
> On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
> mailto:hongzhi.s...@windriver.com>
>> wrote:
>
>     A new patch let kernel source Documentation/Kconfig in top
Kconfig
>     So kernel-devsrc should include Documentation/ too.
>     Otherwise "make scripts" will fails.
>
>     patch:
>     commit b1663d7e3a7961fc45262fd68a89253f2803036c
>     Author: Mauro Carvalho Chehab mailto:mchehab%2bsams...@kernel.org>
>     >>
>     Date:   Tue Jun 4 09:26:27 2019 -0300
>
>         docs: Kbuild/Makefile: allow check for missing docs at
build time
>
>         While this doesn't make sense for production Kernels, in
order to
>         avoid regressions when documents are touched, let's add a
>         check target at the make file.
>
>         Signed-off-by: Mauro Carvalho Chehab
>     mailto:mchehab%2bsams...@kernel.org>
>>
>         Signed-off-by: Jonathan Corbet mailto:cor...@lwn.net>
>     >>
>
>     Signed-off-by: Hongzhi.Song mailto:hongzhi.s...@windriver.com>
>     >>
>     ---
>      meta/recipes-kernel/linux/kernel-devsrc.bb

>      | 2 +-
>      1 file changed, 1 insertion(+), 1 deletion(-)
>
>     diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb

>     
>     b/meta/recipes-kernel/linux/kernel-devsrc.bb
 
>     index 5ec5929..a874e06 100644
>     --- a/meta/recipes-kernel/linux/kernel-devsrc.bb

>     
>     +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb

>     
>     @@ -65,7 +65,7 @@ do_install() {
>          )
>
>          # then drop all but the needed Makefiles/Kconfig files
>     -    rm -rf $kerneldir/build/Documentation
>     +    #rm -rf $kerneldir/build/Documentation
>
>
> In the spirit of keeping kernel-devsrc as small as possible (I have
> another patch pending if you really want the full kernel
source), this
> should only keep the Documentation/ files that are required to pass
> the check, not keep all of Documentation.


If you have a better patch, I am pleasure to accept it.


???

This is where you'd typically do a v2 of the patch after getting a 
review of a change.


But if you are refusing the feedback, then yes, I'll do a version of 
the patch myself rather than just blindly copying in all of the 
documentation. I'll submit it myself.


RP/Ross, whoever is taking in patches, drop this version, and I'll do 
my own.



I am not very familiar with the kernel-devsrc.bb. I have no objection 
for your decision.


Thanks,

--Hongzhi




Cheers,

Bruce


Thanks,

--Hongzhi


> Bruce
>
>          rm -rf $kerneldir/build/scripts
>          rm -rf $kerneldir/build/include
>
>     --
>     2.8.1
>
>     --
>     ___
>     Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org

>     >
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness
await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>



--
- Thou shalt not follow the NULL pointer, for chaos and madness await 
thee at its end

- "Use the force Harry" - Gandalf, Star Trek II


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


Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Bruce Ashfield
On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song 
wrote:

>
> On 8/13/19 8:27 PM, Bruce Ashfield wrote:
> >
> >
> > On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
> > mailto:hongzhi.s...@windriver.com>> wrote:
> >
> > A new patch let kernel source Documentation/Kconfig in top Kconfig
> > So kernel-devsrc should include Documentation/ too.
> > Otherwise "make scripts" will fails.
> >
> > patch:
> > commit b1663d7e3a7961fc45262fd68a89253f2803036c
> > Author: Mauro Carvalho Chehab  > >
> > Date:   Tue Jun 4 09:26:27 2019 -0300
> >
> > docs: Kbuild/Makefile: allow check for missing docs at build time
> >
> > While this doesn't make sense for production Kernels, in order to
> > avoid regressions when documents are touched, let's add a
> > check target at the make file.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > mailto:mchehab%2bsams...@kernel.org>>
> > Signed-off-by: Jonathan Corbet  > >
> >
> > Signed-off-by: Hongzhi.Song  > >
> > ---
> >  meta/recipes-kernel/linux/kernel-devsrc.bb
> >  | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > b/meta/recipes-kernel/linux/kernel-devsrc.bb <
> http://kernel-devsrc.bb>
> > index 5ec5929..a874e06 100644
> > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> > 
> > @@ -65,7 +65,7 @@ do_install() {
> >  )
> >
> >  # then drop all but the needed Makefiles/Kconfig files
> > -rm -rf $kerneldir/build/Documentation
> > +#rm -rf $kerneldir/build/Documentation
> >
> >
> > In the spirit of keeping kernel-devsrc as small as possible (I have
> > another patch pending if you really want the full kernel source), this
> > should only keep the Documentation/ files that are required to pass
> > the check, not keep all of Documentation.
>
>
> If you have a better patch, I am pleasure to accept it.
>

???

This is where you'd typically do a v2 of the patch after getting a review
of a change.

But if you are refusing the feedback, then yes, I'll do a version of the
patch myself rather than just blindly copying in all of the documentation.
I'll submit it myself.

RP/Ross, whoever is taking in patches, drop this version, and I'll do my
own.

Cheers,

Bruce



>
> Thanks,
>
> --Hongzhi
>
>
> > Bruce
> >
> >  rm -rf $kerneldir/build/scripts
> >  rm -rf $kerneldir/build/include
> >
> > --
> > 2.8.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > 
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
>


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


Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Hongzhi, Song


On 8/13/19 8:27 PM, Bruce Ashfield wrote:



On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song 
mailto:hongzhi.s...@windriver.com>> wrote:


A new patch let kernel source Documentation/Kconfig in top Kconfig
So kernel-devsrc should include Documentation/ too.
Otherwise "make scripts" will fails.

patch:
commit b1663d7e3a7961fc45262fd68a89253f2803036c
Author: Mauro Carvalho Chehab mailto:mchehab%2bsams...@kernel.org>>
Date:   Tue Jun 4 09:26:27 2019 -0300

    docs: Kbuild/Makefile: allow check for missing docs at build time

    While this doesn't make sense for production Kernels, in order to
    avoid regressions when documents are touched, let's add a
    check target at the make file.

    Signed-off-by: Mauro Carvalho Chehab
mailto:mchehab%2bsams...@kernel.org>>
    Signed-off-by: Jonathan Corbet mailto:cor...@lwn.net>>

Signed-off-by: Hongzhi.Song mailto:hongzhi.s...@windriver.com>>
---
 meta/recipes-kernel/linux/kernel-devsrc.bb
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb

b/meta/recipes-kernel/linux/kernel-devsrc.bb 
index 5ec5929..a874e06 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb

+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb

@@ -65,7 +65,7 @@ do_install() {
     )

     # then drop all but the needed Makefiles/Kconfig files
-    rm -rf $kerneldir/build/Documentation
+    #rm -rf $kerneldir/build/Documentation


In the spirit of keeping kernel-devsrc as small as possible (I have 
another patch pending if you really want the full kernel source), this 
should only keep the Documentation/ files that are required to pass 
the check, not keep all of Documentation.



If you have a better patch, I am pleasure to accept it.

Thanks,

--Hongzhi



Bruce

     rm -rf $kerneldir/build/scripts
     rm -rf $kerneldir/build/include

-- 
2.8.1


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
- Thou shalt not follow the NULL pointer, for chaos and madness await 
thee at its end

- "Use the force Harry" - Gandalf, Star Trek II


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


[OE-core] [PATCH] gdb: Do not set musl specific CFLAGS

2019-08-13 Thread Khem Raj
These settings are no longer needed because we define
gl_cv_func_gettimeofday_clobber=no already and stat issue is alrwady
fixed via [1]

[1] 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3c025cfe5efc44eb4dfb03b53dca28e75096dd1e

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gdb/gdb_8.3.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb_8.3.bb 
b/meta/recipes-devtools/gdb/gdb_8.3.bb
index c6eac84dd8..d70757a151 100644
--- a/meta/recipes-devtools/gdb/gdb_8.3.bb
+++ b/meta/recipes-devtools/gdb/gdb_8.3.bb
@@ -26,4 +26,3 @@ EOF
chmod +x ${WORKDIR}/python
fi
 }
-CPPFLAGS_append_libc-musl = " -Drpl_gettimeofday=gettimeofday -Drpl_stat=stat"
-- 
2.22.0

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


[OE-core] [thud][PATCH v2 4/4] libcomps: fix CVE-2019-3817

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../libcomps/libcomps/CVE-2019-3817.patch | 97 +++
 .../recipes-devtools/libcomps/libcomps_git.bb |  1 +
 2 files changed, 98 insertions(+)
 create mode 100644 meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch

diff --git a/meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch 
b/meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch
new file mode 100644
index 00..b8cfb3c4db
--- /dev/null
+++ b/meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch
@@ -0,0 +1,97 @@
+From cea10cd1f2ef6bb4edaac0c1d46d47bf237c42b8 Mon Sep 17 00:00:00 2001
+From: Riccardo Schirone 
+Date: Mon, 21 Jan 2019 18:11:42 +0100
+Subject: [PATCH] Fix UAF in comps_objmrtree_unite function
+
+The added field is not used at all in many places and it is probably the
+left-over of some copy-paste.
+
+Upstream-Status: Backport
+[https://github.com/rpm-software-management/libcomps/commit
+/e3a5d056633677959ad924a51758876d415e7046]
+
+CVE: CVE-2019-3817
+
+Signed-off-by: Kevin Weng 
+---
+ libcomps/src/comps_mradix.c| 2 --
+ libcomps/src/comps_objmradix.c | 2 --
+ libcomps/src/comps_objradix.c  | 2 --
+ libcomps/src/comps_radix.c | 1 -
+ 4 files changed, 7 deletions(-)
+
+diff --git a/libcomps/src/comps_mradix.c b/libcomps/src/comps_mradix.c
+index 338cb07..6ceb7c9 100644
+--- a/libcomps/src/comps_mradix.c
 b/libcomps/src/comps_mradix.c
+@@ -177,7 +177,6 @@ void comps_mrtree_unite(COMPS_MRTree *rt1, COMPS_MRTree 
*rt2) {
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+@@ -195,7 +194,6 @@ void comps_mrtree_unite(COMPS_MRTree *rt1, COMPS_MRTree 
*rt2) {
+ parent_pair = (struct Pair*) it->data;
+ free(it);
+ 
+-pair->added = 0;
+ for (it = tmp_subnodes->first; it != NULL; it=it->next) {
+ pair = malloc(sizeof(struct Pair));
+ pair->subnodes = ((COMPS_MRTreeData*)it->data)->subnodes;
+diff --git a/libcomps/src/comps_objmradix.c b/libcomps/src/comps_objmradix.c
+index 9be6648..8771c89 100644
+--- a/libcomps/src/comps_objmradix.c
 b/libcomps/src/comps_objmradix.c
+@@ -285,7 +285,6 @@ void comps_objmrtree_unite(COMPS_ObjMRTree *rt1, 
COMPS_ObjMRTree *rt2) {
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+@@ -303,7 +302,6 @@ void comps_objmrtree_unite(COMPS_ObjMRTree *rt1, 
COMPS_ObjMRTree *rt2) {
+ parent_pair = (struct Pair*) it->data;
+ free(it);
+ 
+-pair->added = 0;
+ for (it = tmp_subnodes->first; it != NULL; it=it->next) {
+ pair = malloc(sizeof(struct Pair));
+ pair->subnodes = ((COMPS_ObjMRTreeData*)it->data)->subnodes;
+diff --git a/libcomps/src/comps_objradix.c b/libcomps/src/comps_objradix.c
+index a790270..0ebaf22 100644
+--- a/libcomps/src/comps_objradix.c
 b/libcomps/src/comps_objradix.c
+@@ -692,7 +692,6 @@ void comps_objrtree_unite(COMPS_ObjRTree *rt1, 
COMPS_ObjRTree *rt2) {
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+@@ -711,7 +710,6 @@ void comps_objrtree_unite(COMPS_ObjRTree *rt1, 
COMPS_ObjRTree *rt2) {
+ //printf("key-part:%s\n", parent_pair->key);
+ free(it);
+ 
+-//pair->added = 0;
+ for (it = tmp_subnodes->first; it != NULL; it=it->next) {
+ pair = malloc(sizeof(struct Pair));
+ pair->subnodes = ((COMPS_ObjRTreeData*)it->data)->subnodes;
+diff --git a/libcomps/src/comps_radix.c b/libcomps/src/comps_radix.c
+index ada4fda..05dcaf2 100644
+--- a/libcomps/src/comps_radix.c
 b/libcomps/src/comps_radix.c
+@@ -529,7 +529,6 @@ void comps_rtree_unite(COMPS_RTree *rt1, COMPS_RTree *rt2) 
{
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+-- 
+2.22.0
+
diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
b/meta/recipes-devtools/libcomps/libcomps_git.bb
index e69bf67729..b657f3377c 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_git.bb
@@ -6,6 +6,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/libcomps.git \
file://0001-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \
file://0002-Set-library-installation-path-correctly.patch \
file://0001-Make-__comps_objmrtree_all-static-inline.patch \
+   file://CVE-2019-3817.patch \
"
 
 PV = "0.1.8+git${SRCPV}"
-- 
2.22.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

[OE-core] [thud][PATCH v2 1/4] curl: fix CVE-2018-16890 CVE-2019-3822 CVE-2019-3823

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../curl/curl/CVE-2018-16890.patch| 50 +
 .../curl/curl/CVE-2019-3822.patch | 47 
 .../curl/curl/CVE-2019-3823.patch | 55 +++
 meta/recipes-support/curl/curl_7.61.0.bb  |  3 +
 4 files changed, 155 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-16890.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2019-3822.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2019-3823.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-16890.patch 
b/meta/recipes-support/curl/curl/CVE-2018-16890.patch
new file mode 100644
index 00..3776f362bc
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-16890.patch
@@ -0,0 +1,50 @@
+From 53d3c2f92b4a7561b1006494badf8cf2ef9110c0 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Wed, 2 Jan 2019 20:33:08 +0100
+Subject: [PATCH 1/3] NTLM: fix size check condition for type2 received data
+
+Bug: https://curl.haxx.se/docs/CVE-2018-16890.html
+Reported-by: Wenxiang Qian
+CVE-2018-16890
+
+Upstream-Status: Backport
+[https://github.com/curl/curl/commit
+/b780b30d1377adb10bbe774835f49e9b237fb9bb]
+
+CVE: CVE-2018-16890
+
+Signed-off-by: Kevin Weng 
+---
+ lib/vauth/ntlm.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/lib/vauth/ntlm.c b/lib/vauth/ntlm.c
+index cdb8d8f0d..0212756ab 100644
+--- a/lib/vauth/ntlm.c
 b/lib/vauth/ntlm.c
+@@ -5,7 +5,7 @@
+  *| (__| |_| |  _ <| |___
+  * \___|\___/|_| \_\_|
+  *
+- * Copyright (C) 1998 - 2017, Daniel Stenberg, , et al.
++ * Copyright (C) 1998 - 2019, Daniel Stenberg, , et al.
+  *
+  * This software is licensed as described in the file COPYING, which
+  * you should have received as part of this distribution. The terms
+@@ -182,10 +182,11 @@ static CURLcode ntlm_decode_type2_target(struct 
Curl_easy *data,
+ target_info_len = Curl_read16_le([40]);
+ target_info_offset = Curl_read32_le([44]);
+ if(target_info_len > 0) {
+-  if(((target_info_offset + target_info_len) > size) ||
++  if((target_info_offset >= size) ||
++ ((target_info_offset + target_info_len) > size) ||
+  (target_info_offset < 48)) {
+ infof(data, "NTLM handshake failure (bad type-2 message). "
+-"Target Info Offset Len is set incorrect by the peer\n");
++  "Target Info Offset Len is set incorrect by the peer\n");
+ return CURLE_BAD_CONTENT_ENCODING;
+   }
+ 
+-- 
+2.22.0
+
diff --git a/meta/recipes-support/curl/curl/CVE-2019-3822.patch 
b/meta/recipes-support/curl/curl/CVE-2019-3822.patch
new file mode 100644
index 00..4f612ddd5e
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2019-3822.patch
@@ -0,0 +1,47 @@
+From 761b51f66c7b1cd2cd6c71b807bfdb6a27c49b30 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Thu, 3 Jan 2019 12:59:28 +0100
+Subject: [PATCH 2/3] ntlm: fix *_type3_message size check to avoid buffer
+ overflow
+
+Bug: https://curl.haxx.se/docs/CVE-2019-3822.html
+Reported-by: Wenxiang Qian
+CVE-2019-3822
+
+Upstream-Status: Backport
+[https://github.com/curl/curl/commit
+/50c9484278c63b958655a717844f0721263939cc]
+
+CVE: CVE-2019-3822
+
+Signed-off-by: Kevin Weng 
+---
+ lib/vauth/ntlm.c | 11 +++
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/lib/vauth/ntlm.c b/lib/vauth/ntlm.c
+index 0212756ab..3be0403d9 100644
+--- a/lib/vauth/ntlm.c
 b/lib/vauth/ntlm.c
+@@ -777,11 +777,14 @@ CURLcode Curl_auth_create_ntlm_type3_message(struct 
Curl_easy *data,
+   });
+ 
+ #ifdef USE_NTRESPONSES
+-  if(size < (NTLM_BUFSIZE - ntresplen)) {
+-DEBUGASSERT(size == (size_t)ntrespoff);
+-memcpy([size], ptr_ntresp, ntresplen);
+-size += ntresplen;
++  /* ntresplen + size should not be risking an integer overflow here */
++  if(ntresplen + size > sizeof(ntlmbuf)) {
++failf(data, "incoming NTLM message too big");
++return CURLE_OUT_OF_MEMORY;
+   }
++  DEBUGASSERT(size == (size_t)ntrespoff);
++  memcpy([size], ptr_ntresp, ntresplen);
++  size += ntresplen;
+ 
+   DEBUG_OUT({
+ fprintf(stderr, "\n   ntresp=");
+-- 
+2.22.0
+
diff --git a/meta/recipes-support/curl/curl/CVE-2019-3823.patch 
b/meta/recipes-support/curl/curl/CVE-2019-3823.patch
new file mode 100644
index 00..194e6e6430
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2019-3823.patch
@@ -0,0 +1,55 @@
+From 40f6c913f63cdbfa81daa7ac7f1c7415bb99edeb Mon Sep 17 00:00:00 2001
+From: Daniel Gustafsson 
+Date: Sat, 19 Jan 2019 00:42:47 +0100
+Subject: [PATCH 3/3] smtp: avoid risk of buffer overflow in strtol
+
+If the incoming len 5, but the buffer does not have a termination
+after 5 bytes, the strtol() call may keep reading through the line
+buffer until is exceeds its boundary. Fix by ensuring that we are
+using a bounded read with a temporary buffer on the stack.
+
+Bug: 

[OE-core] [thud][PATCH v2 3/4] glib-2.0: fix CVE-2019-13012

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../glib-2.0/glib-2.0/CVE-2019-13012.patch| 47 +++
 meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb |  1 +
 2 files changed, 48 insertions(+)
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
new file mode 100644
index 00..29c5d98402
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
@@ -0,0 +1,47 @@
+From c7f7fd53780f8caebccc903d61ffc21632b46a6c Mon Sep 17 00:00:00 2001
+From: Matthias Clasen 
+Date: Tue, 22 Jan 2019 13:26:31 -0500
+Subject: [PATCH] keyfile settings: Use tighter permissions
+
+When creating directories, create them with 700 permissions,
+instead of 777.
+
+Closes: #1658
+
+Upstream-Status: Backport
+[https://gitlab.gnome.org/GNOME/glib/commit
+/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429]
+
+CVE: CVE-2019-13012
+
+Signed-off-by: Kevin Weng 
+---
+ gio/gkeyfilesettingsbackend.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/gio/gkeyfilesettingsbackend.c b/gio/gkeyfilesettingsbackend.c
+index a37978e83..580a0b0a1 100644
+--- a/gio/gkeyfilesettingsbackend.c
 b/gio/gkeyfilesettingsbackend.c
+@@ -89,7 +89,8 @@ g_keyfile_settings_backend_keyfile_write 
(GKeyfileSettingsBackend *kfsb)
+ 
+   contents = g_key_file_to_data (kfsb->keyfile, , NULL);
+   g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE,
+-   G_FILE_CREATE_REPLACE_DESTINATION,
++   G_FILE_CREATE_REPLACE_DESTINATION |
++   G_FILE_CREATE_PRIVATE,
+NULL, NULL, NULL);
+ 
+   compute_checksum (kfsb->digest, contents, length);
+@@ -640,7 +641,7 @@ g_keyfile_settings_backend_new (const gchar *filename,
+ 
+   kfsb->file = g_file_new_for_path (filename);
+   kfsb->dir = g_file_get_parent (kfsb->file);
+-  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
++  g_mkdir_with_parents (g_file_peek_path (kfsb->dir), 0700);
+ 
+   kfsb->file_monitor = g_file_monitor (kfsb->file, 0, NULL, NULL);
+   kfsb->dir_monitor = g_file_monitor (kfsb->dir, 0, NULL, NULL);
+-- 
+2.22.0
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb
index f007596968..611abd8eb8 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb
@@ -17,6 +17,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz 
\
file://CVE-2019-12450.patch \
file://CVE-2019-9633_p1.patch \
file://CVE-2019-9633_p2.patch \
+   file://CVE-2019-13012.patch \
"
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
-- 
2.22.0

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


[OE-core] [thud][PATCH v2 2/4] dbus: fix CVE-2019-12749

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../dbus/dbus/CVE-2019-12749.patch| 127 ++
 meta/recipes-core/dbus/dbus_1.12.10.bb|   1 +
 2 files changed, 128 insertions(+)
 create mode 100644 meta/recipes-core/dbus/dbus/CVE-2019-12749.patch

diff --git a/meta/recipes-core/dbus/dbus/CVE-2019-12749.patch 
b/meta/recipes-core/dbus/dbus/CVE-2019-12749.patch
new file mode 100644
index 00..393c70ca21
--- /dev/null
+++ b/meta/recipes-core/dbus/dbus/CVE-2019-12749.patch
@@ -0,0 +1,127 @@
+From f0120c5d97a4cc1b659e86d38f2b1f646ca20ea3 Mon Sep 17 00:00:00 2001
+From: Simon McVittie 
+Date: Thu, 30 May 2019 12:53:03 +0100
+Subject: [PATCH] auth: Reject DBUS_COOKIE_SHA1 for users other than the server
+ owner
+
+The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
+of a shared home directory by having the server write a secret "cookie"
+into a .dbus-keyrings subdirectory of the desired identity's home
+directory with 0700 permissions, and having the client prove that it can
+read the cookie. This never actually worked for non-malicious clients in
+the case where server uid != client uid (unless the server and client
+both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
+Unix uid 0) because an unprivileged server would fail to write out the
+cookie, and an unprivileged client would be unable to read the resulting
+file owned by the server.
+
+Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
+is owned by the uid of the server (a side-effect of a check added to
+harden our use of XDG_RUNTIME_DIR), further ruling out successful use
+by a non-malicious client with a uid differing from the server's.
+
+Joe Vennix of Apple Information Security discovered that the
+implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
+attack: a malicious client with write access to its own home directory
+could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
+read and write in unintended locations. In the worst case this could
+result in the DBusServer reusing a cookie that is known to the
+malicious client, and treating that cookie as evidence that a subsequent
+client connection came from an attacker-chosen uid, allowing
+authentication bypass.
+
+This is mitigated by the fact that by default, the well-known system
+dbus-daemon (since 2003) and the well-known session dbus-daemon (in
+stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
+authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
+at an early stage, before manipulating cookies. As a result, this
+vulnerability only applies to:
+
+* system or session dbus-daemons with non-standard configuration
+* third-party dbus-daemon invocations such as at-spi2-core (although
+  in practice at-spi2-core also only accepts EXTERNAL by default)
+* third-party uses of DBusServer such as the one in Upstart
+
+Avoiding symlink attacks in a portable way is difficult, because APIs
+like openat() and Linux /proc/self/fd are not universally available.
+However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
+a non-matching uid, we can solve this vulnerability in an easier way
+without regressions, by rejecting it early (before looking at
+~/.dbus-keyrings) whenever the requested identity doesn't match the
+identity of the process hosting the DBusServer.
+
+Signed-off-by: Simon McVittie 
+Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/269
+Closes: CVE-2019-12749
+
+Upstream-Status: Backport
+[https://gitlab.freedesktop.org/dbus/dbus/commit
+/47b1a4c41004bf494b87370987b222c934b19016]
+
+CVE: CVE-2019-12749
+
+Signed-off-by: Kevin Weng 
+---
+ dbus/dbus-auth.c | 32 
+ 1 file changed, 32 insertions(+)
+
+diff --git a/dbus/dbus-auth.c b/dbus/dbus-auth.c
+index 37d8d4c9..7390a9d5 100644
+--- a/dbus/dbus-auth.c
 b/dbus/dbus-auth.c
+@@ -529,6 +529,7 @@ sha1_handle_first_client_response (DBusAuth *auth,
+   DBusString tmp2;
+   dbus_bool_t retval = FALSE;
+   DBusError error = DBUS_ERROR_INIT;
++  DBusCredentials *myself = NULL;
+ 
+   _dbus_string_set_length (>challenge, 0);
+   
+@@ -565,6 +566,34 @@ sha1_handle_first_client_response (DBusAuth *auth,
+   return FALSE;
+ }
+ 
++  myself = _dbus_credentials_new_from_current_process ();
++
++  if (myself == NULL)
++goto out;
++
++  if (!_dbus_credentials_same_user (myself, auth->desired_identity))
++{
++  /*
++   * DBUS_COOKIE_SHA1 is not suitable for authenticating that the
++   * client is anyone other than the user owning the process
++   * containing the DBusServer: we probably aren't allowed to write
++   * to other users' home directories. Even if we can (for example
++   * uid 0 on traditional Unix or CAP_DAC_OVERRIDE on Linux), we
++   * must not, because the other user controls their home directory,
++   * and could carry out symlink attacks to make us read from or
++   * write to 

[OE-core] ✗ patchtest: failure for "[thud] curl: fix CVE-2018-1689..." and 3 more

2019-08-13 Thread Patchwork
== Series Details ==

Series: "[thud] curl: fix CVE-2018-1689..." and 3 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/19261/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  thud (currently at d3d3f44303)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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


[OE-core] [thud][PATCH 2/4] dbus: fix CVE-2019-12749

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../dbus/dbus/CVE-2019-12749.patch| 127 ++
 meta/recipes-core/dbus/dbus_1.12.10.bb|   1 +
 2 files changed, 128 insertions(+)
 create mode 100644 meta/recipes-core/dbus/dbus/CVE-2019-12749.patch

diff --git a/meta/recipes-core/dbus/dbus/CVE-2019-12749.patch 
b/meta/recipes-core/dbus/dbus/CVE-2019-12749.patch
new file mode 100644
index 00..393c70ca21
--- /dev/null
+++ b/meta/recipes-core/dbus/dbus/CVE-2019-12749.patch
@@ -0,0 +1,127 @@
+From f0120c5d97a4cc1b659e86d38f2b1f646ca20ea3 Mon Sep 17 00:00:00 2001
+From: Simon McVittie 
+Date: Thu, 30 May 2019 12:53:03 +0100
+Subject: [PATCH] auth: Reject DBUS_COOKIE_SHA1 for users other than the server
+ owner
+
+The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
+of a shared home directory by having the server write a secret "cookie"
+into a .dbus-keyrings subdirectory of the desired identity's home
+directory with 0700 permissions, and having the client prove that it can
+read the cookie. This never actually worked for non-malicious clients in
+the case where server uid != client uid (unless the server and client
+both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
+Unix uid 0) because an unprivileged server would fail to write out the
+cookie, and an unprivileged client would be unable to read the resulting
+file owned by the server.
+
+Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
+is owned by the uid of the server (a side-effect of a check added to
+harden our use of XDG_RUNTIME_DIR), further ruling out successful use
+by a non-malicious client with a uid differing from the server's.
+
+Joe Vennix of Apple Information Security discovered that the
+implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
+attack: a malicious client with write access to its own home directory
+could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
+read and write in unintended locations. In the worst case this could
+result in the DBusServer reusing a cookie that is known to the
+malicious client, and treating that cookie as evidence that a subsequent
+client connection came from an attacker-chosen uid, allowing
+authentication bypass.
+
+This is mitigated by the fact that by default, the well-known system
+dbus-daemon (since 2003) and the well-known session dbus-daemon (in
+stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
+authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
+at an early stage, before manipulating cookies. As a result, this
+vulnerability only applies to:
+
+* system or session dbus-daemons with non-standard configuration
+* third-party dbus-daemon invocations such as at-spi2-core (although
+  in practice at-spi2-core also only accepts EXTERNAL by default)
+* third-party uses of DBusServer such as the one in Upstart
+
+Avoiding symlink attacks in a portable way is difficult, because APIs
+like openat() and Linux /proc/self/fd are not universally available.
+However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
+a non-matching uid, we can solve this vulnerability in an easier way
+without regressions, by rejecting it early (before looking at
+~/.dbus-keyrings) whenever the requested identity doesn't match the
+identity of the process hosting the DBusServer.
+
+Signed-off-by: Simon McVittie 
+Closes: 
https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsqfojzsKaTLrhYk7-2F4AqW4Z0aTTxYxcMGlkfrpmYKZqw1bpnzzdxCB9YO7xZwpTvnA-3D-3D_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FJYsjDq1g468dzj84vKE7KK-2FvT22avn5U9YcVt85sTA4tepftll-2Baq3M9eo4YCyUWYrN1r6ngO6VCFpjbtSsyTy3M2aZjBjZUByNmRr5P82a2-2B9TnX56cJhPYCtT6FXlXc2dCWfRTWasb0KOpLKpCVXhIhDvuQ7nNa0EsxdEJ7kWtcgzCwKwWx1dLY5TNGSQo
+Closes: CVE-2019-12749
+
+Upstream-Status: Backport
+[https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsqfojzsKaTLrhYk7-2F4AqW4Z0aTTxYxcMGlkfrpmYKZqwxlDxIUuV3NsS4-2FTIcFoyAA-3D-3D_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FJYsjDq1g468dzj84vKE7KK-2FvT22avn5U9YcVt85sTA4DsGTiyJF96mAymOloRHcUgz8RlpJRLz0mRCQGIpkyeNJOMSsOukswlyle2Vi3yd3dZE9iQVjiIMBlkfmayQWQGs1L1DZDjBeWLkroc1PR0vfccVbvieS1-2B3sMv13f1D0PVmjGiGx6RjIz2ii7j84B
+/47b1a4c41004bf494b87370987b222c934b19016]
+
+CVE: CVE-2019-12749
+
+Signed-off-by: Kevin Weng 
+---
+ dbus/dbus-auth.c | 32 
+ 1 file changed, 32 insertions(+)
+
+diff --git a/dbus/dbus-auth.c b/dbus/dbus-auth.c
+index 37d8d4c9..7390a9d5 100644
+--- a/dbus/dbus-auth.c
 b/dbus/dbus-auth.c
+@@ -529,6 +529,7 @@ sha1_handle_first_client_response (DBusAuth *auth,
+   DBusString tmp2;
+   dbus_bool_t retval = FALSE;
+   DBusError error = DBUS_ERROR_INIT;
++  DBusCredentials *myself = NULL;
+ 
+   _dbus_string_set_length (>challenge, 0);
+   
+@@ -565,6 +566,34 @@ sha1_handle_first_client_response (DBusAuth *auth,
+   return FALSE;

[OE-core] [thud][PATCH 3/4] glib-2.0: fix CVE-2019-13012

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../glib-2.0/glib-2.0/CVE-2019-13012.patch| 47 +++
 meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb |  1 +
 2 files changed, 48 insertions(+)
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
new file mode 100644
index 00..29c5d98402
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
@@ -0,0 +1,47 @@
+From c7f7fd53780f8caebccc903d61ffc21632b46a6c Mon Sep 17 00:00:00 2001
+From: Matthias Clasen 
+Date: Tue, 22 Jan 2019 13:26:31 -0500
+Subject: [PATCH] keyfile settings: Use tighter permissions
+
+When creating directories, create them with 700 permissions,
+instead of 777.
+
+Closes: #1658
+
+Upstream-Status: Backport
+[https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsnGdThIumwxbeCM-2BExoUQb3xoFKw5ia4SQ7gfdvTfxmZ8uW8wNMPXLlzqfBPx5Spkg-3D-3D_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FzBSP60qI2GfklY0UAhXTU7-2BagK7GE0pY2gSbtzQgRWAtFRzsX5zZc4SnBz-2BZn2IxtzjkOKKVfBGZVXe6NZ6yH17NLIcwrFuflIpbosCts2lUbNM0C5tds-2BcpFGJ8YNExatD8xQHoIdKQdWh2yVHTSL7gxkDxYkzDoXFn-2F-2FQGctFXEl8VKUiRClzAawIH0Ckv
+/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429]
+
+CVE: CVE-2019-13012
+
+Signed-off-by: Kevin Weng 
+---
+ gio/gkeyfilesettingsbackend.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/gio/gkeyfilesettingsbackend.c b/gio/gkeyfilesettingsbackend.c
+index a37978e83..580a0b0a1 100644
+--- a/gio/gkeyfilesettingsbackend.c
 b/gio/gkeyfilesettingsbackend.c
+@@ -89,7 +89,8 @@ g_keyfile_settings_backend_keyfile_write 
(GKeyfileSettingsBackend *kfsb)
+ 
+   contents = g_key_file_to_data (kfsb->keyfile, , NULL);
+   g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE,
+-   G_FILE_CREATE_REPLACE_DESTINATION,
++   G_FILE_CREATE_REPLACE_DESTINATION |
++   G_FILE_CREATE_PRIVATE,
+NULL, NULL, NULL);
+ 
+   compute_checksum (kfsb->digest, contents, length);
+@@ -640,7 +641,7 @@ g_keyfile_settings_backend_new (const gchar *filename,
+ 
+   kfsb->file = g_file_new_for_path (filename);
+   kfsb->dir = g_file_get_parent (kfsb->file);
+-  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
++  g_mkdir_with_parents (g_file_peek_path (kfsb->dir), 0700);
+ 
+   kfsb->file_monitor = g_file_monitor (kfsb->file, 0, NULL, NULL);
+   kfsb->dir_monitor = g_file_monitor (kfsb->dir, 0, NULL, NULL);
+-- 
+2.22.0
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb
index f007596968..611abd8eb8 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.58.0.bb
@@ -17,6 +17,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz 
\
file://CVE-2019-12450.patch \
file://CVE-2019-9633_p1.patch \
file://CVE-2019-9633_p2.patch \
+   file://CVE-2019-13012.patch \
"
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
-- 
2.22.0

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


[OE-core] [thud][PATCH 1/4] curl: fix CVE-2018-16890 CVE-2019-3822 CVE-2019-3823

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../curl/curl/CVE-2018-16890.patch| 50 +
 .../curl/curl/CVE-2019-3822.patch | 47 
 .../curl/curl/CVE-2019-3823.patch | 55 +++
 meta/recipes-support/curl/curl_7.61.0.bb  |  3 +
 4 files changed, 155 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-16890.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2019-3822.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2019-3823.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-16890.patch 
b/meta/recipes-support/curl/curl/CVE-2018-16890.patch
new file mode 100644
index 00..3776f362bc
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-16890.patch
@@ -0,0 +1,50 @@
+From 53d3c2f92b4a7561b1006494badf8cf2ef9110c0 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Wed, 2 Jan 2019 20:33:08 +0100
+Subject: [PATCH 1/3] NTLM: fix size check condition for type2 received data
+
+Bug: 
https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsuYawlW3mAc8KSIVCn7Sr15C6jasXKgfgJg3JjJc2B5tUGp03H07-2B9S6u-2FfoRsGaNA-3D-3D_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FT1vYL7RdHUXx5bTSyf-2BcHR-2FH99gGD0yxa2eDYEjnkkb2piM5nuT9Okl3ZrJA9sAE-2B5rmYECHdFNdUX0JlH7LDIVejeTQadVG6ba-2FpEkCdCA9gq7zRkLAgdI3PN-2BCxa3dccdSBFpI1pL4M0QWKi8etP4TfG1trESO3T7x1KWt9hdClBaPVmjcfOg0NnZqj3dM
+Reported-by: Wenxiang Qian
+CVE-2018-16890
+
+Upstream-Status: Backport
+[https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsm-2BOxbx-2BokIEd78jiad-2F22EvF-2F5AbNKhGzn8FPX-2FD9Za_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FT1vYL7RdHUXx5bTSyf-2BcHR-2FH99gGD0yxa2eDYEjnkkYh8rqSb35IOFzYXlwANJZDcoaGAvdMBQIW66yHB0q840xeh1nsvNy99-2BeC8OnXMhl6mIja7Rhuos5DP-2FrmBNWuySm6VU5JTOy1kFNvV-2BydqaqtGXpyIgtzWMDkU6Z-2BR0cXTCVLDdCzHe-2Fmc15i6Akd
+/b780b30d1377adb10bbe774835f49e9b237fb9bb]
+
+CVE: CVE-2018-16890
+
+Signed-off-by: Kevin Weng 
+---
+ lib/vauth/ntlm.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/lib/vauth/ntlm.c b/lib/vauth/ntlm.c
+index cdb8d8f0d..0212756ab 100644
+--- a/lib/vauth/ntlm.c
 b/lib/vauth/ntlm.c
+@@ -5,7 +5,7 @@
+  *| (__| |_| |  _ <| |___
+  * \___|\___/|_| \_\_|
+  *
+- * Copyright (C) 1998 - 2017, Daniel Stenberg, , et al.
++ * Copyright (C) 1998 - 2019, Daniel Stenberg, , et al.
+  *
+  * This software is licensed as described in the file COPYING, which
+  * you should have received as part of this distribution. The terms
+@@ -182,10 +182,11 @@ static CURLcode ntlm_decode_type2_target(struct 
Curl_easy *data,
+ target_info_len = Curl_read16_le([40]);
+ target_info_offset = Curl_read32_le([44]);
+ if(target_info_len > 0) {
+-  if(((target_info_offset + target_info_len) > size) ||
++  if((target_info_offset >= size) ||
++ ((target_info_offset + target_info_len) > size) ||
+  (target_info_offset < 48)) {
+ infof(data, "NTLM handshake failure (bad type-2 message). "
+-"Target Info Offset Len is set incorrect by the peer\n");
++  "Target Info Offset Len is set incorrect by the peer\n");
+ return CURLE_BAD_CONTENT_ENCODING;
+   }
+ 
+-- 
+2.22.0
+
diff --git a/meta/recipes-support/curl/curl/CVE-2019-3822.patch 
b/meta/recipes-support/curl/curl/CVE-2019-3822.patch
new file mode 100644
index 00..4f612ddd5e
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2019-3822.patch
@@ -0,0 +1,47 @@
+From 761b51f66c7b1cd2cd6c71b807bfdb6a27c49b30 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Thu, 3 Jan 2019 12:59:28 +0100
+Subject: [PATCH 2/3] ntlm: fix *_type3_message size check to avoid buffer
+ overflow
+
+Bug: 
https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsuYawlW3mAc8KSIVCn7Sr16swIdigko5fNDjNRt0Dh6FfGTpPs9ibM6aBry51kJrnw-3D-3D_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FT1vYL7RdHUXx5bTSyf-2BcHR-2FH99gGD0yxa2eDYEjnkkbJbCzXOiW1odOTtQFdFcpJzsRBVUETMOtLC0B-2BdylXcUavysDy2hajcvoqOZD-2ByPOIoUO2RTyiKiVNqvL52XWE0BudzTX7FaPC6VtNnfkW1p1Uwi1FAOsHmAIdfS0Hk46aZhgWeAHazbigfQ1Wrvpc
+Reported-by: Wenxiang Qian
+CVE-2019-3822
+
+Upstream-Status: Backport
+[https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsm-2BOxbx-2BokIEd78jiad-2F22EvF-2F5AbNKhGzn8FPX-2FD9Za_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2FT1vYL7RdHUXx5bTSyf-2BcHR-2FH99gGD0yxa2eDYEjnkkZyVjLXyu6AfrfslPgZqQqfmT-2FCjlb31qQx-2BPRmMVneLfPjeil2-2BTKjDA9s3w3kZFEyRIX6Yy-2B0lQECXSq5tv3xNIDIn46JHgTnKWqkfIQHuY7yT5WYG3E5lOFcZYcsoosqoxeJTKgg9-2BPkTA1v944K
+/50c9484278c63b958655a717844f0721263939cc]
+
+CVE: CVE-2019-3822
+
+Signed-off-by: Kevin Weng 
+---
+ lib/vauth/ntlm.c | 11 +++
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/lib/vauth/ntlm.c b/lib/vauth/ntlm.c
+index 

[OE-core] [thud][PATCH 4/4] libcomps: fix CVE-2019-3817

2019-08-13 Thread Kevin Weng via Openembedded-core
Signed-off-by: Kevin Weng 
---
 .../libcomps/libcomps/CVE-2019-3817.patch | 97 +++
 .../recipes-devtools/libcomps/libcomps_git.bb |  1 +
 2 files changed, 98 insertions(+)
 create mode 100644 meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch

diff --git a/meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch 
b/meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch
new file mode 100644
index 00..b8cfb3c4db
--- /dev/null
+++ b/meta/recipes-devtools/libcomps/libcomps/CVE-2019-3817.patch
@@ -0,0 +1,97 @@
+From cea10cd1f2ef6bb4edaac0c1d46d47bf237c42b8 Mon Sep 17 00:00:00 2001
+From: Riccardo Schirone 
+Date: Mon, 21 Jan 2019 18:11:42 +0100
+Subject: [PATCH] Fix UAF in comps_objmrtree_unite function
+
+The added field is not used at all in many places and it is probably the
+left-over of some copy-paste.
+
+Upstream-Status: Backport
+[https://u12060237.ct.sendgrid.net/wf/click?upn=ZUEdHBk4v9DOmlXxaQIXsoghc-2F9RlLvhcpOjxb9ovgnr4YRBxmwFECTTjPS9PgQV84-2BUSEk9vEIRrUewVY024DakCb8CoJOoQbEEuIx0JtI-3D_TE0Kxc-2FihH-2BEaJFZv0piOBm40-2F8jB5b-2FHzeWxsyZzZlOtbMQm4wqVCgNIpo7dsW-2F-2BMliwfLhRhehxDxQEVAVjz-2B7rA-2FJAENANhR-2F6MZPVT-2BCzcQr03CBCKL19RuiyJjo1Ir8MQwBmEVs-2FImhHvCT5WfFHukDc-2FVeE2UO6hYfFWHVV9DDcXOiilszZ-2FXfOq3SLzYA8Fb2Yqg1HlodT-2B1oAdwEwgfU50AJ-2Bx6URUTp4ji5qBHXFLICP4SbDpvokE9b
+/e3a5d056633677959ad924a51758876d415e7046]
+
+CVE: CVE-2019-3817
+
+Signed-off-by: Kevin Weng 
+---
+ libcomps/src/comps_mradix.c| 2 --
+ libcomps/src/comps_objmradix.c | 2 --
+ libcomps/src/comps_objradix.c  | 2 --
+ libcomps/src/comps_radix.c | 1 -
+ 4 files changed, 7 deletions(-)
+
+diff --git a/libcomps/src/comps_mradix.c b/libcomps/src/comps_mradix.c
+index 338cb07..6ceb7c9 100644
+--- a/libcomps/src/comps_mradix.c
 b/libcomps/src/comps_mradix.c
+@@ -177,7 +177,6 @@ void comps_mrtree_unite(COMPS_MRTree *rt1, COMPS_MRTree 
*rt2) {
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+@@ -195,7 +194,6 @@ void comps_mrtree_unite(COMPS_MRTree *rt1, COMPS_MRTree 
*rt2) {
+ parent_pair = (struct Pair*) it->data;
+ free(it);
+ 
+-pair->added = 0;
+ for (it = tmp_subnodes->first; it != NULL; it=it->next) {
+ pair = malloc(sizeof(struct Pair));
+ pair->subnodes = ((COMPS_MRTreeData*)it->data)->subnodes;
+diff --git a/libcomps/src/comps_objmradix.c b/libcomps/src/comps_objmradix.c
+index 9be6648..8771c89 100644
+--- a/libcomps/src/comps_objmradix.c
 b/libcomps/src/comps_objmradix.c
+@@ -285,7 +285,6 @@ void comps_objmrtree_unite(COMPS_ObjMRTree *rt1, 
COMPS_ObjMRTree *rt2) {
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+@@ -303,7 +302,6 @@ void comps_objmrtree_unite(COMPS_ObjMRTree *rt1, 
COMPS_ObjMRTree *rt2) {
+ parent_pair = (struct Pair*) it->data;
+ free(it);
+ 
+-pair->added = 0;
+ for (it = tmp_subnodes->first; it != NULL; it=it->next) {
+ pair = malloc(sizeof(struct Pair));
+ pair->subnodes = ((COMPS_ObjMRTreeData*)it->data)->subnodes;
+diff --git a/libcomps/src/comps_objradix.c b/libcomps/src/comps_objradix.c
+index a790270..0ebaf22 100644
+--- a/libcomps/src/comps_objradix.c
 b/libcomps/src/comps_objradix.c
+@@ -692,7 +692,6 @@ void comps_objrtree_unite(COMPS_ObjRTree *rt1, 
COMPS_ObjRTree *rt2) {
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+@@ -711,7 +710,6 @@ void comps_objrtree_unite(COMPS_ObjRTree *rt1, 
COMPS_ObjRTree *rt2) {
+ //printf("key-part:%s\n", parent_pair->key);
+ free(it);
+ 
+-//pair->added = 0;
+ for (it = tmp_subnodes->first; it != NULL; it=it->next) {
+ pair = malloc(sizeof(struct Pair));
+ pair->subnodes = ((COMPS_ObjRTreeData*)it->data)->subnodes;
+diff --git a/libcomps/src/comps_radix.c b/libcomps/src/comps_radix.c
+index ada4fda..05dcaf2 100644
+--- a/libcomps/src/comps_radix.c
 b/libcomps/src/comps_radix.c
+@@ -529,7 +529,6 @@ void comps_rtree_unite(COMPS_RTree *rt1, COMPS_RTree *rt2) 
{
+ struct Pair {
+ COMPS_HSList * subnodes;
+ char * key;
+-char added;
+ } *pair, *parent_pair;
+ 
+ pair = malloc(sizeof(struct Pair));
+-- 
+2.22.0
+
diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
b/meta/recipes-devtools/libcomps/libcomps_git.bb
index e69bf67729..b657f3377c 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_git.bb
@@ -6,6 +6,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/libcomps.git \
file://0001-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \

Re: [OE-core] [PATCH] xrandr: update to 1.5.1

2019-08-13 Thread Adrian Bunk
On Tue, Aug 13, 2019 at 10:01:25PM +0200, Alexander Kanavin wrote:
> On Tue, 13 Aug 2019 at 21:53, Oleksandr Kravchuk <
> open.sou...@oleksandr-kravchuk.com> wrote:
> 
> > SRC_URI was moved from xorg-app-common.inc, since it has hardcoded file
> > extension (tar.bz2), but upstream stopped publishing tar.bz2 archives
> > for newer versions of the packages.
> >
> 
> Should this be rather fixed in the common include though? I took a brief
> look here:
> https://www.x.org/releases/individual/app/
> and it seems like we can switch to xz for everything or almost everything
> without much pain.

If there end up several compression types here this could be made 
configurable, similar to GNOME_COMPRESS_TYPE.

> Alex

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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


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

2019-08-13 Thread Oleksandr Kravchuk
Signed-off-by: Oleksandr Kravchuk 
---
 meta/recipes-devtools/git/git_2.22.0.bb | 11 ---
 meta/recipes-devtools/git/git_2.22.1.bb | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.22.0.bb
 create mode 100644 meta/recipes-devtools/git/git_2.22.1.bb

diff --git a/meta/recipes-devtools/git/git_2.22.0.bb 
b/meta/recipes-devtools/git/git_2.22.0.bb
deleted file mode 100644
index 9e55fd6eae..00
--- a/meta/recipes-devtools/git/git_2.22.0.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "6deab33485c07cb3391ea0f255a936f2"
-SRC_URI[tarball.sha256sum] = 
"a4b7e4365bee43caa12a38d646d2c93743d755d1cea5eab448ffb40906c9da0b"
-SRC_URI[manpages.md5sum] = "d6cb42f12185a47ce3adaac24a1ded50"
-SRC_URI[manpages.sha256sum] = 
"f6a5750dfc4a0aa5ec0c0cc495d4995d1f36ed47591c3941be9756c1c3a1aa0a"
diff --git a/meta/recipes-devtools/git/git_2.22.1.bb 
b/meta/recipes-devtools/git/git_2.22.1.bb
new file mode 100644
index 00..e0ed146b27
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.22.1.bb
@@ -0,0 +1,11 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.md5sum] = "b379ee9b8c7733d01fc49998148621ef"
+SRC_URI[tarball.sha256sum] = 
"83bf264bfa4573faddb396cbc7f5518db082f9573aa3c8ea08b8a30d23a46adc"
+SRC_URI[manpages.md5sum] = "70aaf2da41c21b0864e9b1bb8231172c"
+SRC_URI[manpages.sha256sum] = 
"228da34377a6795619e1822a4fad00c87300135b811643bdb816afe4a92040f9"
-- 
2.17.1

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


Re: [OE-core] [PATCH] xrandr: update to 1.5.1

2019-08-13 Thread Alexander Kanavin
On Tue, 13 Aug 2019 at 22:01, Alexander Kanavin 
wrote:

> On Tue, 13 Aug 2019 at 21:53, Oleksandr Kravchuk <
> open.sou...@oleksandr-kravchuk.com> wrote:
>
>> SRC_URI was moved from xorg-app-common.inc, since it has hardcoded file
>> extension (tar.bz2), but upstream stopped publishing tar.bz2 archives
>> for newer versions of the packages.
>>
>
> Should this be rather fixed in the common include though? I took a brief
> look here:
> https://www.x.org/releases/individual/app/
> and it seems like we can switch to xz for everything or almost everything
> without much pain.
>

Nevermind; only xrandr provides .tar.xz. I have confused that with gz :)

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


Re: [OE-core] [PATCH] xrandr: update to 1.5.1

2019-08-13 Thread Alexander Kanavin
On Tue, 13 Aug 2019 at 21:53, Oleksandr Kravchuk <
open.sou...@oleksandr-kravchuk.com> wrote:

> SRC_URI was moved from xorg-app-common.inc, since it has hardcoded file
> extension (tar.bz2), but upstream stopped publishing tar.bz2 archives
> for newer versions of the packages.
>

Should this be rather fixed in the common include though? I took a brief
look here:
https://www.x.org/releases/individual/app/
and it seems like we can switch to xz for everything or almost everything
without much pain.

Alex

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


[OE-core] [PATCH] xrandr: update to 1.5.1

2019-08-13 Thread Oleksandr Kravchuk
SRC_URI was moved from xorg-app-common.inc, since it has hardcoded file
extension (tar.bz2), but upstream stopped publishing tar.bz2 archives
for newer versions of the packages.

Signed-off-by: Oleksandr Kravchuk 
---
 .../xorg-app/{xrandr_1.5.0.bb => xrandr_1.5.1.bb}   | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-app/{xrandr_1.5.0.bb => xrandr_1.5.1.bb} 
(64%)

diff --git a/meta/recipes-graphics/xorg-app/xrandr_1.5.0.bb 
b/meta/recipes-graphics/xorg-app/xrandr_1.5.1.bb
similarity index 64%
rename from meta/recipes-graphics/xorg-app/xrandr_1.5.0.bb
rename to meta/recipes-graphics/xorg-app/xrandr_1.5.1.bb
index ea6897948d..6583ea2371 100644
--- a/meta/recipes-graphics/xorg-app/xrandr_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-app/xrandr_1.5.1.bb
@@ -11,5 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=fe1608bdb33cf8c62a4438f7d34679b3"
 DEPENDS += "libxrandr libxrender"
 PE = "1"
 
-SRC_URI[md5sum] = "ebffac98021b8f1dc71da0c1918e9b57"
-SRC_URI[sha256sum] = 
"c1cfd4e1d4d708c031d60801e527abc9b6d34b85f2ffa2cadd21f75ff38151cd"
+SRC_URI = "${XORG_MIRROR}/individual/app/${BPN}-${PV}.tar.xz"
+
+SRC_URI[md5sum] = "fe40f7a4fd39dd3a02248d3e0b1972e4"
+SRC_URI[sha256sum] = 
"7bc76daf9d72f8aff885efad04ce06b90488a1a169d118dea8a2b661832e8762"
-- 
2.17.1

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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-13 Thread Richard Purdie
On Tue, 2019-08-13 at 10:04 +0100, Richard Purdie wrote:
> On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> > Comparing that build to a corresponding do-nothing build with Thud,
> > the time difference matches those three minutes where I have no
> > idea
> > what bitbake is doing now that it didn’t need to do before…
> >  
> > Hopefully these time degradations can be solved, because the
> > current
> > state of bitbake is barely usable. We also need to look into
> > possible
> > ways to improve the cooker output when it is running the setscene
> > tasks so it makes some kind of sense again.
> 
> We talked on irc and you pointed at the commit things started to go
> wrong. Just to summarise things for the benefit of the list, this is
> some quick testing I did:
> 
> "bitbake -p; time bitbake core-image-minimal -n"
> 
> 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> 40.3s 7df31ff36892c2f9c65326b06b4c70 
> 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e 
> 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c 
> 76.9s master-next
> 
> So basically the original changes showed a 25% hit but the
> performance
> of -next is dire.
> 
> This is with no hash equiv server configured.
> 
> It will vary depending on the target used (numbers with -sato for the
> above would be interesting for comparision) and how much was or is in
> sstate, they type of sstate mirror configured and so on.
> 
> I really need to focus on getting the new code functioning correctly
> before we attempt to optimise but if nobody tests the new code due to
> performance problems we have a different issue. We also have a
> scaling
> problem with the hash server itself I need to fix to stop the
> autobuilder throwing weird errors. I'm therefore a bit challenged on
> where to start with it all :/.

I had a glance at the profile output from master-next and the problem
wasn't where I thought it would be, it was in the scheduler code. That
is good as those classes are effectively independent of the other
changes and hence are a separate fix.

I've put a patch in -next which takes the above test to 36s which is
close to the older bitbake.

Could be interesting to see how it looks for others and different
workloads.

Cheers,

Richard

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


[OE-core] [PATCH] uboot: fixes to uboot-extlinux-config attribute values

2019-08-13 Thread Will Page
The way this class uses overrides to support generation of multiple
sections is subject to two different issues: 1) labels that conflict
with existing override names causing the value for the conflicting label
to be set for all labels, and 2) reusing the override list through each
iteration, prepending each new label to the list of overrides makes
earlier labels' value take precedence over later labels, making later
labels virtually impossible to customize.

The first issue is resolved by removing all label names from overrides
before iterating over labels.  The second issue is resolved by
generating a fresh list of overrides with only the current label added.

The current label is also appended to the list of overrides instead of
prepended, which makes it the highest priority override.  This is
matches the behavior of devtool-source.bbclass, which similarly
monkey-patches overrides.

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

Signed-off-by: Will Page 
---
 meta/classes/uboot-extlinux-config.bbclass | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/meta/classes/uboot-extlinux-config.bbclass 
b/meta/classes/uboot-extlinux-config.bbclass
index b5b1a81dfc..f4bf94be04 100644
--- a/meta/classes/uboot-extlinux-config.bbclass
+++ b/meta/classes/uboot-extlinux-config.bbclass
@@ -104,13 +104,16 @@ python do_create_extlinux_config() {
 if default:
 cfgfile.write('DEFAULT %s\n' % (default))
 
-for label in labels.split():
+# Need to deconflict the labels with existing overrides
+label_overrides = labels.split()
+default_overrides = localdata.getVar('OVERRIDES').split(':')
+# We're keeping all the existing overrides that aren't used as a 
label
+# an override for that label will be added back in while we're 
processing that label
+keep_overrides = list(filter(lambda x: x not in label_overrides, 
default_overrides))
 
-overrides = localdata.getVar('OVERRIDES')
-if not overrides:
-bb.fatal('OVERRIDES not defined')
+for label in labels.split():
 
-localdata.setVar('OVERRIDES', label + ':' + overrides)
+localdata.setVar('OVERRIDES', ':'.join(keep_overrides + 
[label]))
 
 extlinux_console = localdata.getVar('UBOOT_EXTLINUX_CONSOLE')
 
-- 
2.17.1

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


[OE-core] [PATCH] xf86-input-libinput: update to 0.29.0

2019-08-13 Thread Oleksandr Kravchuk
Signed-off-by: Oleksandr Kravchuk 
---
 ...input-libinput_0.28.2.bb => xf86-input-libinput_0.29.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-driver/{xf86-input-libinput_0.28.2.bb => 
xf86-input-libinput_0.29.0.bb} (63%)

diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb 
b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.29.0.bb
similarity index 63%
rename from meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb
rename to meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.29.0.bb
index 19123e06c9..f87083e575 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.29.0.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=5e6b20ea2ef94a998145f0ea3f788ee0"
 
 DEPENDS += "libinput"
 
-SRC_URI[md5sum] = "b7548bc1d7e82d189205794ff86307af"
-SRC_URI[sha256sum] = 
"b8b346962c6b62b8069928c29c0db83b6f544863bf2fc6830f324de841de2820"
+SRC_URI[md5sum] = "d600e8e2e30747b8ce49ec5294ff0ab6"
+SRC_URI[sha256sum] = 
"c28b56a21754b972db31798e6a4cf4dc9d69208d08f8fe41701a94def5e94bee"
 
 FILES_${PN} += "${datadir}/X11/xorg.conf.d"
-- 
2.17.1

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


[OE-core] [PATCH 4/5] sudo: correct SRC_URI

2019-08-13 Thread Alexander Kanavin
The old URI returns 404, and has an invalid TLS certificate.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-extended/sudo/sudo_1.8.27.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sudo/sudo_1.8.27.bb 
b/meta/recipes-extended/sudo/sudo_1.8.27.bb
index 1a3b2be6b4c..9d2d6bd4299 100644
--- a/meta/recipes-extended/sudo/sudo_1.8.27.bb
+++ b/meta/recipes-extended/sudo/sudo_1.8.27.bb
@@ -1,6 +1,6 @@
 require sudo.inc
 
-SRC_URI = "http://ftp.sudo.ws/sudo/dist/sudo-${PV}.tar.gz \
+SRC_URI = "http://www.sudo.ws/sudo/dist/sudo-${PV}.tar.gz \
${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', 
'', d)} \
file://0001-Include-sys-types.h-for-id_t-definition.patch \
"
-- 
2.17.1

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


[OE-core] [PATCH 2/5] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively

2019-08-13 Thread Alexander Kanavin
Recursive RDEPENDS resolution requires that all of the dependent
recipes' packaging has completed. There is no mechanism to ensure that
and therefore races were observed.

This change effectively requires recipes to list their runtime file
dependencies explicitly rather than have them pulled indirectly.
This may require a bit of fixing in layers, but should result
in a better definition of runtime file dependencies.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/insane.bbclass | 18 --
 1 file changed, 18 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 35c4fdb4913..9b886d13805 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -722,25 +722,7 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, 
taskdeps, packages, d):
 filerdepends[subkey] = key[13:]
 
 if filerdepends:
-next = rdepends
 done = rdepends[:]
-# Find all the rdepends on the dependency chain
-while next:
-new = []
-for rdep in next:
-rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
-sub_rdeps = rdep_data.get("RDEPENDS_" + rdep)
-if not sub_rdeps:
-continue
-for sub_rdep in bb.utils.explode_deps(sub_rdeps):
-if sub_rdep in done:
-continue
-if oe.packagedata.has_subpkgdata(sub_rdep, d):
-# It's a new rdep
-done.append(sub_rdep)
-new.append(sub_rdep)
-next = new
-
 # Add the rprovides of itself
 if pkg not in done:
 done.insert(0, pkg)
-- 
2.17.1

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


[OE-core] [PATCH 5/5] ovmf: fix upstream version check

2019-08-13 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 meta/recipes-core/ovmf/ovmf_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
b/meta/recipes-core/ovmf/ovmf_git.bb
index 7944ee97d49..b569b593fc2 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"gitsm://github.com/tianocore/edk2.git;branch=master;protocol=git \
 
 PV = "edk2-stable201905"
 SRCREV="20d2e5a125e34fc8501026613a71549b2a1a3e54"
+UPSTREAM_CHECK_GITTAGREGEX = "(?Pedk2-stable.*)"
 
 inherit deploy
 
-- 
2.17.1

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


[OE-core] [PATCH 3/5] python3-numpy: update to 1.17.0

2019-08-13 Thread Alexander Kanavin
Rebase files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch

License-Update: clarified license for numpy/core/src/multiarray/dragon4.c (it 
is MIT)
Signed-off-by: Alexander Kanavin 
---
 ...-and-so-on-for-libraries-by-default-.patch | 47 ---
 ...up.py-remove-the-detection-of-x86-ta.patch | 32 +
 .../python-numpy/python-numpy.inc |  9 ++--
 ...umpy_1.16.3.bb => python3-numpy_1.17.0.bb} |  0
 4 files changed, 57 insertions(+), 31 deletions(-)
 create mode 100644 
meta/recipes-devtools/python-numpy/files/0001-numpy-random-setup.py-remove-the-detection-of-x86-ta.patch
 rename meta/recipes-devtools/python-numpy/{python3-numpy_1.16.3.bb => 
python3-numpy_1.17.0.bb} (100%)

diff --git 
a/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
 
b/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
index 8fe0d1a27ee..98a97058312 100644
--- 
a/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
+++ 
b/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
@@ -1,4 +1,4 @@
-From c14554c7e2fff8dd559dfb41e7dd11392c6f85e3 Mon Sep 17 00:00:00 2001
+From 672a75c8417ce08db9e31fc415ec445479231d5a Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Thu, 10 Dec 2015 13:20:30 +0200
 Subject: [PATCH] Don't search /usr and so on for libraries by default to
@@ -10,14 +10,14 @@ Signed-off-by: Ross Burton 
 Signed-off-by: Alexander Kanavin 
 
 ---
- numpy/distutils/system_info.py | 50 --
- 1 file changed, 6 insertions(+), 44 deletions(-)
+ numpy/distutils/system_info.py | 42 --
+ 1 file changed, 5 insertions(+), 37 deletions(-)
 
 diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
-index 2424943..bf56a6d 100644
+index ba2b1f4..f94dce1 100644
 --- a/numpy/distutils/system_info.py
 +++ b/numpy/distutils/system_info.py
-@@ -274,51 +274,13 @@ if sys.platform == 'win32':
+@@ -278,45 +278,13 @@ if sys.platform == 'win32':
  add_system_root(os.path.join(conda_dir, 'Library'))
  
  else:
@@ -45,31 +45,24 @@ index 2424943..bf56a6d 100644
 -default_x11_include_dirs.extend(['/usr/lib/X11/include',
 - '/usr/include/X11'])
 -
--import subprocess as sp
--tmp = None
--try:
--# Explicitly open/close file to avoid ResourceWarning when
--# tests are run in debug mode Python 3.
--tmp = open(os.devnull, 'w')
--p = sp.Popen(["gcc", "-print-multiarch"], stdout=sp.PIPE,
-- stderr=tmp)
--except (OSError, DistutilsError):
--# OSError if gcc is not installed, or SandboxViolation (DistutilsError
--# subclass) if an old setuptools bug is triggered (see gh-3160).
--pass
--else:
--triplet = str(p.communicate()[0].decode().strip())
--if p.returncode == 0:
--# gcc supports the "-print-multiarch" option
--default_x11_lib_dirs += [os.path.join("/usr/lib/", triplet)]
--default_lib_dirs += [os.path.join("/usr/lib/", triplet)]
--finally:
--if tmp is not None:
--tmp.close()
+-with open(os.devnull, 'w') as tmp:
+-try:
+-p = subprocess.Popen(["gcc", "-print-multiarch"], 
stdout=subprocess.PIPE,
+- stderr=tmp)
+-except (OSError, DistutilsError):
+-# OSError if gcc is not installed, or SandboxViolation 
(DistutilsError
+-# subclass) if an old setuptools bug is triggered (see gh-3160).
+-pass
+-else:
+-triplet = str(p.communicate()[0].decode().strip())
+-if p.returncode == 0:
+-# gcc supports the "-print-multiarch" option
+-default_x11_lib_dirs += [os.path.join("/usr/lib/", triplet)]
+-default_lib_dirs += [os.path.join("/usr/lib/", triplet)]
 +default_lib_dirs = libpaths(['/deadir/lib'], platform_bits)
 +default_include_dirs = ['/deaddir/include']
 +default_src_dirs = ['.', '/deaddir/src']
-+
+ 
 +default_x11_lib_dirs = libpaths(['/deaddir/lib'], platform_bits)
 +default_x11_include_dirs = ['/deaddir/include']
  
diff --git 
a/meta/recipes-devtools/python-numpy/files/0001-numpy-random-setup.py-remove-the-detection-of-x86-ta.patch
 
b/meta/recipes-devtools/python-numpy/files/0001-numpy-random-setup.py-remove-the-detection-of-x86-ta.patch
new file mode 100644
index 000..ebb2a6f9df1
--- /dev/null
+++ 
b/meta/recipes-devtools/python-numpy/files/0001-numpy-random-setup.py-remove-the-detection-of-x86-ta.patch
@@ -0,0 +1,32 @@
+From b881e0b2ba9cf1a4aa351a1c1ea90b1e1776ce21 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Mon, 12 Aug 2019 15:37:36 +0200
+Subject: [PATCH] 

[OE-core] [PATCH 1/5] gcc-cross-canadian: add missing runtime dependencies

2019-08-13 Thread Alexander Kanavin
The recipe is special in that it does not auto-detect them
at packaging step (via EXCLUDE_FROM_SHLIBS). With the recursive
RDEPENDS qa check gone they need to be listed explicitly.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 807e47e0ee2..0e626172b5f 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -152,7 +152,8 @@ do_install () {
 
 ELFUTILS = "nativesdk-elfutils"
 DEPENDS += "nativesdk-gmp nativesdk-mpfr nativesdk-libmpc ${ELFUTILS} 
nativesdk-zlib"
-RDEPENDS_${PN} += "nativesdk-mpfr nativesdk-libmpc ${ELFUTILS}"
+RDEPENDS_${PN} += "nativesdk-mpfr nativesdk-libmpc ${ELFUTILS} nativesdk-glibc 
nativesdk-libgcc nativesdk-libstdc++ nativesdk-zlib nativesdk-gmp"
+RDEPENDS_${PN}_remove_sdkmingw32 = "nativesdk-glibc"
 
 SYSTEMHEADERS = "${target_includedir}/"
 SYSTEMLIBS = "${target_base_libdir}/"
-- 
2.17.1

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


[OE-core] [PATCH] libevent: update to 2.1.11

2019-08-13 Thread Oleksandr Kravchuk
Signed-off-by: Oleksandr Kravchuk 
---
 .../libevent/{libevent_2.1.10.bb => libevent_2.1.11.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libevent/{libevent_2.1.10.bb => 
libevent_2.1.11.bb} (88%)

diff --git a/meta/recipes-support/libevent/libevent_2.1.10.bb 
b/meta/recipes-support/libevent/libevent_2.1.11.bb
similarity index 88%
rename from meta/recipes-support/libevent/libevent_2.1.10.bb
rename to meta/recipes-support/libevent/libevent_2.1.11.bb
index 81ceb1cd91..1e18f0ab2c 100644
--- a/meta/recipes-support/libevent/libevent_2.1.10.bb
+++ b/meta/recipes-support/libevent/libevent_2.1.11.bb
@@ -12,8 +12,8 @@ SRC_URI = " \
 file://run-ptest \
 "
 
-SRC_URI[md5sum] = "999caf86f52943af2363bc8077f00167"
-SRC_URI[sha256sum] = 
"e864af41a336bb11dab1a23f32993afe963c1f69618bd9292b89ecf6904845b0"
+SRC_URI[md5sum] = "7f35cfe69b82d879111ec0d7b7b1c531"
+SRC_URI[sha256sum] = 
"a65bac6202ea8c5609fd5c7e480e6d25de467ea1917c08290c521752f147283d"
 
 UPSTREAM_CHECK_URI = "http://libevent.org/;
 
-- 
2.17.1

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


[OE-core] [PATCH] librepo: update to 1.10.5

2019-08-13 Thread Oleksandr Kravchuk
Also cleanedup the recipe.

Signed-off-by: Oleksandr Kravchuk 
---
 .../{librepo_1.10.4.bb => librepo_1.10.5.bb}   | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/librepo/{librepo_1.10.4.bb => librepo_1.10.5.bb} 
(58%)

diff --git a/meta/recipes-devtools/librepo/librepo_1.10.4.bb 
b/meta/recipes-devtools/librepo/librepo_1.10.5.bb
similarity index 58%
rename from meta/recipes-devtools/librepo/librepo_1.10.4.bb
rename to meta/recipes-devtools/librepo/librepo_1.10.5.bb
index 50c9a82e74..87d64bf3a0 100644
--- a/meta/recipes-devtools/librepo/librepo_1.10.4.bb
+++ b/meta/recipes-devtools/librepo/librepo_1.10.5.bb
@@ -1,4 +1,5 @@
-SUMMARY = " A library providing C and Python (libcURL like) API for 
downloading linux repository metadata and packages."
+SUMMARY = "A library providing C and Python (libcURL like) API \
+   for downloading linux repository metadata and packages."
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
@@ -7,7 +8,7 @@ SRC_URI = "git://github.com/rpm-software-management/librepo.git 
\

file://0004-Set-gpgme-variables-with-pkg-config-not-with-cmake-m.patch \
"
 
-SRCREV = "9b2df22dbcdf9352672334098fff56335aa10423"
+SRCREV = "385e2ced1083cac0bcb19e30500311f6923e6dfc"
 
 S = "${WORKDIR}/git"
 
@@ -15,7 +16,12 @@ DEPENDS = "curl glib-2.0 openssl attr gpgme libxml2"
 
 inherit cmake distutils3-base pkgconfig
 
-EXTRA_OECMAKE = " -DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} 
-DPYTHON_DESIRED=3 -DENABLE_TESTS=OFF -DENABLE_DOCS=OFF -DWITH_ZCHUNK=OFF"
+EXTRA_OECMAKE = " \
+-DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} \
+-DPYTHON_DESIRED=3 \
+-DENABLE_TESTS=OFF \
+-DENABLE_DOCS=OFF \
+-DWITH_ZCHUNK=OFF \
+"
 
 BBCLASSEXTEND = "native nativesdk"
-
-- 
2.17.1

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


[OE-core] [PATCH] python3-git: update to 3.0.0

2019-08-13 Thread Oleksandr Kravchuk
Signed-off-by: Oleksandr Kravchuk 
---
 .../python/{python3-git_2.1.13.bb => python3-git_3.0.0.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-git_2.1.13.bb => 
python3-git_3.0.0.bb} (88%)

diff --git a/meta/recipes-devtools/python/python3-git_2.1.13.bb 
b/meta/recipes-devtools/python/python3-git_3.0.0.bb
similarity index 88%
rename from meta/recipes-devtools/python/python3-git_2.1.13.bb
rename to meta/recipes-devtools/python/python3-git_3.0.0.bb
index fd6ba50df5..b6c837cdf3 100644
--- a/meta/recipes-devtools/python/python3-git_2.1.13.bb
+++ b/meta/recipes-devtools/python/python3-git_3.0.0.bb
@@ -12,8 +12,8 @@ PYPI_PACKAGE = "GitPython"
 
 inherit pypi setuptools3
 
-SRC_URI[md5sum] = "1ecc2d27123418e4c9e5602788c96855"
-SRC_URI[sha256sum] = 
"c15c55ff890cd3a6a8330059e80885410a328f645551b55a91d858bfb3eb2573"
+SRC_URI[md5sum] = "9412ae9665fd29328f2afc6df887ae81"
+SRC_URI[sha256sum] = 
"629867ebf609cef21bb9d849039e281e25963fb7d714a2f6bacc1ecce4800293"
 
 DEPENDS += " ${PYTHON_PN}-gitdb"
 
-- 
2.17.1

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


Re: [OE-core] [PATCH 2/4] python3-numpy: update to 1.17.0

2019-08-13 Thread richard . purdie
On Tue, 2019-08-13 at 08:35 -0700, Khem Raj wrote:
> On Tue, Aug 13, 2019 at 8:34 AM Michael Halstead
>  wrote:
> > 
> > On 8/13/19 2:54 AM, Alexander Kanavin wrote:
> > 
> > On Tue, 13 Aug 2019 at 10:34, Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> > > 
> > > This doesn't build on opensuse 42.3:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/907
> > > 
> > > Its numpy-native and looks like it might be the old compiler :(
> > 
> > That version of opensuse went end-of-life about a month ago. We can
> > hold this off until the autobuilder is upgraded.
> > 
> > Alex
> > 
> > I'm ready to drop this worker at any time. opensuse-42.3 is still a
> > SANITY_TESTED_DISTRO. Is it fine to go ahead and remove this?
> > 
> 
> sure, also a patch to drop it from SANITY_TESTED_DISTRO before
> disconnecting it

Patch queued.

Cheers,

Richard

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


Re: [OE-core] [PATCH 2/4] python3-numpy: update to 1.17.0

2019-08-13 Thread Khem Raj
On Tue, Aug 13, 2019 at 8:34 AM Michael Halstead
 wrote:
>
>
> On 8/13/19 2:54 AM, Alexander Kanavin wrote:
>
> On Tue, 13 Aug 2019 at 10:34, Richard Purdie 
>  wrote:
>>
>>
>> This doesn't build on opensuse 42.3:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/907
>>
>> Its numpy-native and looks like it might be the old compiler :(
>
>
> That version of opensuse went end-of-life about a month ago. We can hold this 
> off until the autobuilder is upgraded.
>
> Alex
>
> I'm ready to drop this worker at any time. opensuse-42.3 is still a 
> SANITY_TESTED_DISTRO. Is it fine to go ahead and remove this?
>

sure, also a patch to drop it from SANITY_TESTED_DISTRO before disconnecting it

> --
> Michael Halstead
> Linux Foundation / SysAdmin
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/4] python3-numpy: update to 1.17.0

2019-08-13 Thread Michael Halstead

On 8/13/19 2:54 AM, Alexander Kanavin wrote:
> On Tue, 13 Aug 2019 at 10:34, Richard Purdie
>  > wrote:
>
>
> This doesn't build on opensuse 42.3:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/907
>
> Its numpy-native and looks like it might be the old compiler :(
>
>
> That version of opensuse went end-of-life about a month ago. We can
> hold this off until the autobuilder is upgraded.
>
> Alex
I'm ready to drop this worker at any time. opensuse-42.3 is still a
SANITY_TESTED_DISTRO. Is it fine to go ahead and remove this?

-- 
Michael Halstead
Linux Foundation / SysAdmin

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


[OE-core] [PATCH V2] gcc-runtime: Move content from gcclibdir into libdir

2019-08-13 Thread Khem Raj
OE does not use the traditional /usr/lib/gcc prefix to store gcc-runtime
it basically is moved into libdir, however some newer files were
installed by newer versions of gcc especially libgomp ( omp.h openacc.h )
into gcclibdir, so we have content in both directories, this confuses
other tools which are trying to guess the gcc installation and its
runtime location, since now we have two directories, the tools either
choose one or other and we get inconsistent behavior, e.g. clang for
aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc

This change ensures that OE ends up with single valid location for gcc
runtime files

Move more common bits into common inc file

Signed-off-by: Khem Raj 
---
v2: Divert packaging to use new path in whole recipe

 meta/recipes-devtools/gcc/gcc-runtime.inc| 18 +++---
 meta/recipes-devtools/gcc/gcc-runtime_8.3.bb | 10 --
 meta/recipes-devtools/gcc/gcc-runtime_9.1.bb | 10 --
 3 files changed, 15 insertions(+), 23 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index a5c2600d7f..22c1d78dd1 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -17,6 +17,12 @@ EXTRA_OECONF_PATHS = "\
 EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
 EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
 
+# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
+EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
+
+# Building with thumb enabled on armv6t fails
+ARM_INSTRUCTION_SET_armv6 = "arm"
+
 RUNTIMELIBITM = "libitm"
 RUNTIMELIBITM_arc = ""
 RUNTIMELIBITM_mipsarch = ""
@@ -77,6 +83,11 @@ do_install () {
cd ${B}/${TARGET_SYS}/$d/
oe_runmake 'DESTDIR=${D}' MULTIBUILDTOP=${B}/${TARGET_SYS}/$d/ 
install
done
+   if [ -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include ]; then
+   install -d ${D}${libdir}/${TARGET_SYS}/${BINV}/include 
+   mv ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/* 
${D}${libdir}/${TARGET_SYS}/${BINV}/include
+   rmdir --ignore-fail-on-non-empty -p 
${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include
+   fi
rm -rf ${D}${infodir}/libgomp.info ${D}${infodir}/dir
rm -rf ${D}${infodir}/libitm.info ${D}${infodir}/dir
rm -rf ${D}${infodir}/libquadmath.info ${D}${infodir}/dir
@@ -205,7 +216,7 @@ FILES_libssp-dev = "\
 ${libdir}/libssp*.so \
 ${libdir}/libssp*_nonshared.a \
 ${libdir}/libssp*.la \
-${libdir}/gcc/${TARGET_SYS}/${BINV}/include/ssp \
+${libdir}/${TARGET_SYS}/${BINV}/include/ssp \
 "
 SUMMARY_libssp-dev = "GNU stack smashing protection library - development 
files"
 FILES_libssp-staticdev = "${libdir}/libssp*.a"
@@ -214,7 +225,7 @@ SUMMARY_libssp-staticdev = "GNU stack smashing protection 
library - static devel
 FILES_libquadmath = "${libdir}/libquadmath*.so.*"
 SUMMARY_libquadmath = "GNU quad-precision math library"
 FILES_libquadmath-dev = "\
-${libdir}/gcc/${TARGET_SYS}/${BINV}/include/quadmath* \
+${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
 ${libdir}/libquadmath*.so \
 ${libdir}/libquadmath.la \
 "
@@ -239,7 +250,8 @@ FILES_libgomp-dev = "\
 ${libdir}/libgomp*${SOLIBSDEV} \
 ${libdir}/libgomp*.la \
 ${libdir}/libgomp.spec \
-${libdir}/gcc/${TARGET_SYS}/${BINV}/include/omp.h \
+${libdir}/${TARGET_SYS}/${BINV}/include/omp.h \
+${libdir}/${TARGET_SYS}/${BINV}/include/openacc.h \
 "
 SUMMARY_libgomp-dev = "GNU OpenMP parallel programming library - development 
files"
 FILES_libgomp-staticdev = "${libdir}/libgomp*.a"
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb 
b/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
index a1c7a76d0b..dd430b57eb 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
+++ b/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
@@ -1,12 +1,2 @@
 require recipes-devtools/gcc/gcc-${PV}.inc
 require gcc-runtime.inc
-
-# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
-EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
-
-FILES_libgomp-dev += "\
-${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
-"
-
-# Building with thumb enabled on armv6t fails
-ARM_INSTRUCTION_SET_armv6 = "arm"
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb 
b/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
index a1c7a76d0b..dd430b57eb 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
+++ b/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
@@ -1,12 +1,2 @@
 require recipes-devtools/gcc/gcc-${PV}.inc
 require gcc-runtime.inc
-
-# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
-EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
-
-FILES_libgomp-dev += "\
-${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
-"
-
-# Building with thumb enabled on armv6t fails
-ARM_INSTRUCTION_SET_armv6 = "arm"
-- 
2.22.0

-- 
___

Re: [OE-core] [PATCH] gcc-runtime: Move content from gcclibdir into libdir

2019-08-13 Thread richard . purdie
On Tue, 2019-08-13 at 07:36 -0700, Khem Raj wrote:
> On Tue, Aug 13, 2019 at 7:23 AM Richard Purdie
>  wrote:
> > On Mon, 2019-08-12 at 16:22 -0700, Khem Raj wrote:
> > > OE does not use the traditional /usr/lib/gcc prefix to store gcc-
> > > runtime
> > > it basically is moved into libdir, however some newer files were
> > > installed by newer versions of gcc especially libgomp ( omp.h
> > > openacc.h )
> > > into gcclibdir, so we have content in both directories, this
> > > confuses
> > > other tools which are trying to guess the gcc installation and
> > > its
> > > runtime location, since now we have two directories, the tools
> > > either
> > > choose one or other and we get inconsistent behavior, e.g. clang
> > > for
> > > aarch64 uses /usr/lib but same clang for riscv64 chose
> > > /usr/lib/gcc
> > > 
> > > This change ensures that OE ends up with single valid location
> > > for
> > > gcc
> > > runtime files
> > > 
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-devtools/gcc/gcc-runtime.inc| 5 +
> > >  meta/recipes-devtools/gcc/gcc-runtime_8.3.bb | 3 ++-
> > >  meta/recipes-devtools/gcc/gcc-runtime_9.1.bb | 3 ++-
> > >  3 files changed, 9 insertions(+), 2 deletions(-)
> > 
> > This appears to break mingw:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/925
> > 
> 
> seems   virtual:nativesdk:/home/pokybuild/yocto-worker/meta-
> mingw/build/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb:do_package
> 
> but I cant see which files can you help

They're in the 1b and 2b logs, e.g.:

https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/731185/raw

Cheers,

Richard

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


[OE-core] Yocto Project Status WW33'19

2019-08-13 Thread sjolley.yp.pm
Current Dev Position: YP 2.8 M3

Next Deadline: YP 2.8 Milestone M3 Cutoff (Feature Freeze) Aug 25, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Amanda
*   SWAT team rotation: Amanda -> Chen on Aug. 16, 2019
*   SWAT team rotation: Chen -> Armin on Aug. 23, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

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

 

Key Status/Updates:

*   YP 2.6.3 is out of QA and being readied for release.
*   This release which was 2.8 will now become 3.0.
*   The sstate has equivalency work has run into some challenges:

*   performance of the hash server is not able to scale to the
autibuilder's load
*   performance of runqueue has regressed even when not using the hash
equivalency code
*   bugfixes in master-next regress performance even further
*   there are bugs being triggered by the has equivalency code that need
investigation and resolution (along with test cases creating).

These issues are being worked on but we need to ensure correctness of the
new code first before the performance can be fixed

*   There were updates so some key components for bug fixes this week,
in particular pseudo.
*   General patch merging is happening and the queue is mostly clear and
flowing but it isn't happening as frequently as usual due to the hash
equivalency work.

 

Planned Releases for YP 3.0 {2.8}:

*   M2 is released.
*   M3 Cutoff (Feature Freeze) 25th Aug
*   M3 Release 6th Sept
*   M4 Cutoff 30th Sept - this will be YP 3.0.
*   YP 3.0 {2.8 (M4)} Final Release 25th Oct

 

Planned upcoming dot releases:

*   YP 2.7.2 (Warrior) is planned for after YP 3.0 release.
*   YP 2.6.3 (Thud) is out of QA and being readied for release.
*   YP 2.6.4 (Thud) is planned for after YP 2.7.2  release.

 

Tracking Metrics:

*   WDD 2482 (last week 2481) (

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

*   Total patches found: 1489 (last week 1496)
*   Patches in the Pending State: 617 (41%) [last week 615 (41%)]

 

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

 

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


Re: [OE-core] [PATCH] gcc-runtime: Move content from gcclibdir into libdir

2019-08-13 Thread Khem Raj
On Tue, Aug 13, 2019 at 7:23 AM Richard Purdie
 wrote:
>
> On Mon, 2019-08-12 at 16:22 -0700, Khem Raj wrote:
> > OE does not use the traditional /usr/lib/gcc prefix to store gcc-
> > runtime
> > it basically is moved into libdir, however some newer files were
> > installed by newer versions of gcc especially libgomp ( omp.h
> > openacc.h )
> > into gcclibdir, so we have content in both directories, this confuses
> > other tools which are trying to guess the gcc installation and its
> > runtime location, since now we have two directories, the tools either
> > choose one or other and we get inconsistent behavior, e.g. clang for
> > aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc
> >
> > This change ensures that OE ends up with single valid location for
> > gcc
> > runtime files
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-devtools/gcc/gcc-runtime.inc| 5 +
> >  meta/recipes-devtools/gcc/gcc-runtime_8.3.bb | 3 ++-
> >  meta/recipes-devtools/gcc/gcc-runtime_9.1.bb | 3 ++-
> >  3 files changed, 9 insertions(+), 2 deletions(-)
>
> This appears to break mingw:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/925
>

seems   
virtual:nativesdk:/home/pokybuild/yocto-worker/meta-mingw/build/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb:do_package

but I cant see which files can you help

> Cheers,
>
> Richard
>
>
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > index a5c2600d7f..ebba774108 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > @@ -77,6 +77,11 @@ do_install () {
> >   cd ${B}/${TARGET_SYS}/$d/
> >   oe_runmake 'DESTDIR=${D}'
> > MULTIBUILDTOP=${B}/${TARGET_SYS}/$d/ install
> >   done
> > + if [ -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include ]; then
> > + install -d ${D}${libdir}/${TARGET_SYS}/${BINV}/include
> > + mv ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/*
> > ${D}${libdir}/${TARGET_SYS}/${BINV}/include
> > + rmdir --ignore-fail-on-non-empty -p
> > ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include
> > + fi
> >   rm -rf ${D}${infodir}/libgomp.info ${D}${infodir}/dir
> >   rm -rf ${D}${infodir}/libitm.info ${D}${infodir}/dir
> >   rm -rf ${D}${infodir}/libquadmath.info ${D}${infodir}/dir
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> > b/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> > index a1c7a76d0b..172af4e7e1 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> > @@ -5,7 +5,8 @@ require gcc-runtime.inc
> >  EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
> >
> >  FILES_libgomp-dev += "\
> > -${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
> > +${libdir}/${TARGET_SYS}/${BINV}/include/omp.h \
> > +${libdir}/${TARGET_SYS}/${BINV}/include/openacc.h \
> >  "
> >
> >  # Building with thumb enabled on armv6t fails
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> > b/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> > index a1c7a76d0b..172af4e7e1 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> > @@ -5,7 +5,8 @@ require gcc-runtime.inc
> >  EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
> >
> >  FILES_libgomp-dev += "\
> > -${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
> > +${libdir}/${TARGET_SYS}/${BINV}/include/omp.h \
> > +${libdir}/${TARGET_SYS}/${BINV}/include/openacc.h \
> >  "
> >
> >  # Building with thumb enabled on armv6t fails
> > --
> > 2.22.0
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] gcc-runtime: Move content from gcclibdir into libdir

2019-08-13 Thread Richard Purdie
On Mon, 2019-08-12 at 16:22 -0700, Khem Raj wrote:
> OE does not use the traditional /usr/lib/gcc prefix to store gcc-
> runtime
> it basically is moved into libdir, however some newer files were
> installed by newer versions of gcc especially libgomp ( omp.h
> openacc.h )
> into gcclibdir, so we have content in both directories, this confuses
> other tools which are trying to guess the gcc installation and its
> runtime location, since now we have two directories, the tools either
> choose one or other and we get inconsistent behavior, e.g. clang for
> aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc
> 
> This change ensures that OE ends up with single valid location for
> gcc
> runtime files
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/gcc/gcc-runtime.inc| 5 +
>  meta/recipes-devtools/gcc/gcc-runtime_8.3.bb | 3 ++-
>  meta/recipes-devtools/gcc/gcc-runtime_9.1.bb | 3 ++-
>  3 files changed, 9 insertions(+), 2 deletions(-)

This appears to break mingw:

https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/925

Cheers,

Richard


> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index a5c2600d7f..ebba774108 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -77,6 +77,11 @@ do_install () {
>   cd ${B}/${TARGET_SYS}/$d/
>   oe_runmake 'DESTDIR=${D}'
> MULTIBUILDTOP=${B}/${TARGET_SYS}/$d/ install
>   done
> + if [ -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include ]; then
> + install -d ${D}${libdir}/${TARGET_SYS}/${BINV}/include 
> + mv ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/*
> ${D}${libdir}/${TARGET_SYS}/${BINV}/include
> + rmdir --ignore-fail-on-non-empty -p
> ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include
> + fi
>   rm -rf ${D}${infodir}/libgomp.info ${D}${infodir}/dir
>   rm -rf ${D}${infodir}/libitm.info ${D}${infodir}/dir
>   rm -rf ${D}${infodir}/libquadmath.info ${D}${infodir}/dir
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> b/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> index a1c7a76d0b..172af4e7e1 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> +++ b/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb
> @@ -5,7 +5,8 @@ require gcc-runtime.inc
>  EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
>  
>  FILES_libgomp-dev += "\
> -${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
> +${libdir}/${TARGET_SYS}/${BINV}/include/omp.h \
> +${libdir}/${TARGET_SYS}/${BINV}/include/openacc.h \
>  "
>  
>  # Building with thumb enabled on armv6t fails
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> b/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> index a1c7a76d0b..172af4e7e1 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> +++ b/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb
> @@ -5,7 +5,8 @@ require gcc-runtime.inc
>  EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
>  
>  FILES_libgomp-dev += "\
> -${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
> +${libdir}/${TARGET_SYS}/${BINV}/include/omp.h \
> +${libdir}/${TARGET_SYS}/${BINV}/include/openacc.h \
>  "
>  
>  # Building with thumb enabled on armv6t fails
> -- 
> 2.22.0
> 

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


Re: [OE-core] [PATCH] pulseaudio: don't include consolekit when systemd is enabled

2019-08-13 Thread Tanu Kaskinen
On Tue, 2019-08-13 at 16:11 +0300, Tanu Kaskinen wrote:
> On Fri, 2019-07-26 at 23:03 +0800, Anuj Mittal wrote:
> > When using systemd, make sure that pulseaudio-server RDEPENDS on
> > module-systemd-login instead of module-console-kit both of which provide
> > the same functionality but for different init systems [1][2].
> > 
> > Even though both modules can co-exist, this helps avoid including
> > consolekit (which has been deprecated) in the images using systemd.
> > 
> > [1] 
> > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index51h3
> > [2] 
> > https://github.com/pulseaudio/pulseaudio/commit/860d1cf3a76701ade38784822abb24285176227c
> > 
> > Signed-off-by: Anuj Mittal 
> 
> Acked-by: Tanu Kaskinen 

Never mind, this is already in master (I didn't find it initially,
which is why I sent that mail as a ping).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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


Re: [OE-core] [PATCH] pulseaudio: don't include consolekit when systemd is enabled

2019-08-13 Thread Tanu Kaskinen
On Fri, 2019-07-26 at 23:03 +0800, Anuj Mittal wrote:
> When using systemd, make sure that pulseaudio-server RDEPENDS on
> module-systemd-login instead of module-console-kit both of which provide
> the same functionality but for different init systems [1][2].
> 
> Even though both modules can co-exist, this helps avoid including
> consolekit (which has been deprecated) in the images using systemd.
> 
> [1] 
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index51h3
> [2] 
> https://github.com/pulseaudio/pulseaudio/commit/860d1cf3a76701ade38784822abb24285176227c
> 
> Signed-off-by: Anuj Mittal 

Acked-by: Tanu Kaskinen 

> ---
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
> b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index e245be7..ec51d8b 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> @@ -259,9 +259,12 @@ FILES_${PN}-module-gsettings += 
> "${libexecdir}/pulse/gsettings-helper ${datadir}
>  # modules must be installed when X11 is enabled.
>  RDEPENDS_pulseaudio-server += "\
>  ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '\
> -pulseaudio-module-console-kit \
>  pulseaudio-module-device-manager \
>  pulseaudio-module-x11-cork-request \
>  pulseaudio-module-x11-publish \
>  pulseaudio-module-x11-xsmp \
>  ', '', d)}"
> +
> +RDEPENDS_pulseaudio-server += "${@bb.utils.contains('DISTRO_FEATURES', 
> 'x11', \
> +  bb.utils.contains('DISTRO_FEATURES', 
> 'systemd', 'pulseaudio-module-systemd-login', 
> 'pulseaudio-module-console-kit', d), \
> +  '', d)}"
> -- 
> 2.7.4
> 
-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-13 Thread Alexander Kanavin
On Tue, 13 Aug 2019 at 11:04, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> We talked on irc and you pointed at the commit things started to go
> wrong. Just to summarise things for the benefit of the list, this is
> some quick testing I did:
>
> "bitbake -p; time bitbake core-image-minimal -n"
>
> 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> 40.3s 7df31ff36892c2f9c65326b06b4c70
> 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c
> 76.9s master-next
>
> So basically the original changes showed a 25% hit but the performance
> of -next is dire.
>

Sadly with larger sets the performance hit is much worse. I enabled all of
the layers in meta-oe, and ran this with empty sstate and build directories:
bitbake -p; time bitbake -n -k world

The outcomes are:

6c7c0cefd34067311144a1d4c01986fe0a4aef26
12m51,848s
(this is the baseline; the bulk of the time goes towards going through the
task list without executing the tasks - the 'spinning task counter" part)

9983b07fffd19082abded7c3f15cc77d306dd69c
66m29,563s

So there could be something quadratically-growing going on with these new
commits :(

I didn't dare to try master-next after seeing above how it hits
core-image-minimal and master already regressing to over an hour :-(

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


Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

2019-08-13 Thread Bruce Ashfield
On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song 
wrote:

> A new patch let kernel source Documentation/Kconfig in top Kconfig
> So kernel-devsrc should include Documentation/ too.
> Otherwise "make scripts" will fails.
>
> patch:
> commit b1663d7e3a7961fc45262fd68a89253f2803036c
> Author: Mauro Carvalho Chehab 
> Date:   Tue Jun 4 09:26:27 2019 -0300
>
> docs: Kbuild/Makefile: allow check for missing docs at build time
>
> While this doesn't make sense for production Kernels, in order to
> avoid regressions when documents are touched, let's add a
> check target at the make file.
>
> Signed-off-by: Mauro Carvalho Chehab 
> Signed-off-by: Jonathan Corbet 
>
> Signed-off-by: Hongzhi.Song 
> ---
>  meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 5ec5929..a874e06 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -65,7 +65,7 @@ do_install() {
>  )
>
>  # then drop all but the needed Makefiles/Kconfig files
> -rm -rf $kerneldir/build/Documentation
> +#rm -rf $kerneldir/build/Documentation
>

In the spirit of keeping kernel-devsrc as small as possible (I have another
patch pending if you really want the full kernel source), this should only
keep the Documentation/ files that are required to pass the check, not keep
all of Documentation.

Bruce



>  rm -rf $kerneldir/build/scripts
>  rm -rf $kerneldir/build/include
>
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


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


Re: [OE-core] [PATCH 2/4] python3-numpy: update to 1.17.0

2019-08-13 Thread Alexander Kanavin
On Tue, 13 Aug 2019 at 10:34, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

>
> This doesn't build on opensuse 42.3:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/907
>
> Its numpy-native and looks like it might be the old compiler :(
>

That version of opensuse went end-of-life about a month ago. We can hold
this off until the autobuilder is upgraded.

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


Re: [OE-core] [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively

2019-08-13 Thread Alexander Kanavin
On Mon, 12 Aug 2019 at 22:50,  wrote:

>
> > world builds seem to have regressed (preparation time wise) even
> > without having hash equivalency. Just oe-core is bearable, but adding
> > meta-oe layers makes it spent many minutes after initializing tasks
> > but before any tasks actually begin.
>
> Is that with master or current master-next?
>
> I'm curious if master-next is better or worse...
>
> To be honest I'm worrying more about correctness right now.
>

Certainly. I didn't want to raise this now as you have plenty on your
plate, but as Khem did, I had to chime in.

This was with master@9983b07fffd19082abded7c3f15cc77d306dd69c.

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


[OE-core] [PATCHv2] meson: backport fix for builds with -Werror=return-type

2019-08-13 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 meta/recipes-devtools/meson/meson.inc |   1 +
 ...rn-statements-that-are-seen-with-Wer.patch | 100 ++
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index 662368e219..14e5f8a610 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -16,6 +16,7 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P

file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \

file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
file://vala-cross-compile.patch \
+   
file://0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch \
"
 SRC_URI[sha256sum] = 
"f27b7a60f339ba66fe4b8f81f0d1072e090a08eabbd6aa287683b2c2b9dd2d82"
 SRC_URI[md5sum] = "48787e391ec5c052799a3dd491f73909"
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
new file mode 100644
index 00..16c6d90761
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
@@ -0,0 +1,100 @@
+From 15f44be1c7f71cb0a8c6863917acbbc301c621fe Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 15 Jul 2019 10:06:17 +0200
+Subject: [PATCH] Fix missing return statements that are seen with
+ -Werror=return-type.
+
+Error example:
+
+Code:
+
+#include 
+int main () {
+/* If it's not defined as a macro, try to use as a symbol */
+#ifndef LC_MESSAGES
+LC_MESSAGES;
+#endif
+}
+Compiler stdout:
+
+Compiler stderr:
+ In file included from /usr/include/locale.h:25,
+ from /tmp/tmpep_i4iwg/testfile.c:2:
+/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE
+requires compiling with optimization (-O) [-Wcpp]
+  382 | #  warning _FORTIFY_SOURCE requires compiling with optimization
+(-O)
+  |^~~
+/tmp/tmpep_i4iwg/testfile.c: In function 'main':
+/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void
+function [-Werror=return-type]
+8 | }
+  | ^
+cc1: some warnings being treated as errors
+
+Upstream-Status: Backport
+Signed-off-by: Martin Jansa 
+---
+ mesonbuild/compilers/c.py | 1 +
+ mesonbuild/compilers/clike.py | 5 +
+ 2 files changed, 6 insertions(+)
+
+diff --git a/mesonbuild/compilers/c.py b/mesonbuild/compilers/c.py
+index 3b58a076..9ef92077 100644
+--- a/mesonbuild/compilers/c.py
 b/mesonbuild/compilers/c.py
+@@ -70,6 +70,7 @@ class CCompiler(CLikeCompiler, Compiler):
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+diff --git a/mesonbuild/compilers/clike.py b/mesonbuild/compilers/clike.py
+index 83f67591..f9cbeabd 100644
+--- a/mesonbuild/compilers/clike.py
 b/mesonbuild/compilers/clike.py
+@@ -375,6 +375,7 @@ class CLikeCompiler:
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+@@ -554,6 +555,7 @@ class CLikeCompiler:
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)[0]:
+@@ -589,6 +591,7 @@ class CLikeCompiler:
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)[0]:
+@@ -667,6 +670,7 @@ class CLikeCompiler:
+ #include 
+ int main(int argc, char *argv[]) {{
+ printf ("{fmt}", {cast} {f}());
++return 0;
+ }}'''.format(**fargs)
+ res = self.run(code, env, extra_args=extra_args, 
dependencies=dependencies)
+ if not res.compiled:
+@@ -819,6 +823,7 @@ class CLikeCompiler:
+ #error "No definition for __builtin_{func} found in the 
prefix"
+ #endif
+ #endif
++return 0;
+ }}'''
+ return self.links(t.format(**fargs), env, extra_args=extra_args,
+   dependencies=dependencies)
+-- 

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-13 Thread Richard Purdie
On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> Comparing that build to a corresponding do-nothing build with Thud,
> the time difference matches those three minutes where I have no idea
> what bitbake is doing now that it didn’t need to do before…
>  
> Hopefully these time degradations can be solved, because the current
> state of bitbake is barely usable. We also need to look into possible
> ways to improve the cooker output when it is running the setscene
> tasks so it makes some kind of sense again.

We talked on irc and you pointed at the commit things started to go
wrong. Just to summarise things for the benefit of the list, this is
some quick testing I did:

"bitbake -p; time bitbake core-image-minimal -n"

30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
30.6s a0d941c787cf3ef030d190903279d311bc05d752
40.3s 7df31ff36892c2f9c65326b06b4c70 
42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e 
45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c 
76.9s master-next

So basically the original changes showed a 25% hit but the performance
of -next is dire.

This is with no hash equiv server configured.

It will vary depending on the target used (numbers with -sato for the
above would be interesting for comparision) and how much was or is in
sstate, they type of sstate mirror configured and so on.

I really need to focus on getting the new code functioning correctly
before we attempt to optimise but if nobody tests the new code due to
performance problems we have a different issue. We also have a scaling
problem with the hash server itself I need to fix to stop the
autobuilder throwing weird errors. I'm therefore a bit challenged on
where to start with it all :/.

Cheers,

Richard



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


[OE-core] [PATCH] go-runtime: remove conflict files from -dev packages

2019-08-13 Thread changqing.li
From: Changqing Li 

fix below error:
file /usr/lib64/go/src/cmd/cgo/zdefaultcc.go conflicts between attempted 
installs of go-dev-1.12.6-r0.core2_64 and go-runtime-dev-1.12.6-r0.core2_64
file /usr/lib64/go/src/cmd/go/internal/cfg/zdefaultcc.go conflicts between 
attempted installs of go-dev-1.12.6-r0.core2_64 and 
go-runtime-dev-1.12.6-r0.core2_64

these 2 files existed in both go-dev and go-runtime-dev
remove it from go-runtime-dev to fix the problem

Signed-off-by: Changqing Li 
---
 meta/recipes-devtools/go/go-runtime.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/go/go-runtime.inc 
b/meta/recipes-devtools/go/go-runtime.inc
index e282195..9731e16 100644
--- a/meta/recipes-devtools/go/go-runtime.inc
+++ b/meta/recipes-devtools/go/go-runtime.inc
@@ -59,6 +59,9 @@ do_install() {
done
find ${D}${libdir}/go/src -depth -type d -name testdata -exec rm -rf {} 
\;
rm -f ${D}${libdir}/go/src/cmd/dist/dist
+rm -f ${D}${libdir}/go/src/cmd/cgo/zdefaultcc.go
+rm -f ${D}${libdir}/go/src/cmd/go/internal/cfg/zdefaultcc.go
+
 }
 
 ALLOW_EMPTY_${PN} = "1"
-- 
2.7.4

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


Re: [OE-core] [PATCH 2/4] python3-numpy: update to 1.17.0

2019-08-13 Thread Richard Purdie
On Mon, 2019-08-12 at 15:49 +0200, Alexander Kanavin wrote:
> Rebase files/0001-Don-t-search-usr-and-so-on-for-libraries-by-
> default-.patch
> 
> License-Update: clarified license for
> numpy/core/src/multiarray/dragon4.c (it is MIT)
> Signed-off-by: Alexander Kanavin 
> ---
>  ...-and-so-on-for-libraries-by-default-.patch | 47 -
> --
>  ...up.py-remove-the-detection-of-x86-ta.patch | 32 +
>  .../python-numpy/python-numpy.inc |  9 ++--
>  ...umpy_1.16.3.bb => python3-numpy_1.17.0.bb} |  0
>  4 files changed, 57 insertions(+), 31 deletions(-)
>  create mode 100644 meta/recipes-devtools/python-numpy/files/0001-
> numpy-random-setup.py-remove-the-detection-of-x86-ta.patch
>  rename meta/recipes-devtools/python-numpy/{python3-numpy_1.16.3.bb
> => python3-numpy_1.17.0.bb} (100%)

This doesn't build on opensuse 42.3:

https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/907

Its numpy-native and looks like it might be the old compiler :(

Cheers,

Richard

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


Re: [OE-core] [PATCH] go/go-runtime: use update-alternative for zdefaultcc.go

2019-08-13 Thread Changqing Li



On 8/8/19 7:56 PM, Matt Madison wrote:

On Wed, Aug 7, 2019 at 10:36 PM Changqing Li  wrote:


On 8/7/19 10:16 PM, Richard Purdie wrote:

On Wed, 2019-08-07 at 10:35 +0800, Changqing Li wrote:

On 8/6/19 6:47 PM, Richard Purdie wrote:

On Tue, 2019-08-06 at 14:54 +0800, changqing...@windriver.com
wrote:

From: Changqing Li 

fix below error:
file /usr/lib64/go/src/cmd/cgo/zdefaultcc.go conflicts between
attempted installs of go-dev-1.12.6-r0.core2_64 and go-runtime-
dev-
1.12.6-r0.core2_64
file /usr/lib64/go/src/cmd/go/internal/cfg/zdefaultcc.go
conflicts
between attempted installs of go-dev-1.12.6-r0.core2_64 and go-
runtime-dev-1.12.6-r0.core2_64

Signed-off-by: Changqing Li 
---
meta/recipes-devtools/go/go-runtime_1.12.bb | 6 ++
meta/recipes-devtools/go/go_1.12.bb | 7 +++
2 files changed, 13 insertions(+)

It seems odd that both of these packages should provide this,
perhaps
one version should just be deleted?

Cheers,

Richard

These 2 recipes don't have any DEPEND or RDEPEND relationship, so
they
are independent from the point of recipe.

Make one of dev packages empty seems not proper ?

Let me put this another way. What is the difference between these two
binaries? When should you use one, when should you use the other? Or
are they the same thing?

Cheers,

Richard

go is for building go compiler,  and go-runtime only contains go
standard  runtime library

There are 2 use caes:

1.  on target, user only install go-runtime to provide libstd.so for
other go apps.

2.  on target, user install both go and go-runtime

in my opinion,  only in case2,  install dev pkg is meaningful, so maybe
we can remove the conflict

part of files from go-runtime.


@Matt,  you have do lots of work related these recipes, could you also
give your opinion? Thanks.

Well, those 'z'-prefixed files are ones that are generated during the
build of go to embed default flags for the 'go' and 'cgo' commands to
use when they have to call on the C compiler.  They also happen to be
generated during the build of go-runtime because go normally doesn't
separate its toolchain and runtime builds, whereas we have to for the
cross build case. So filtering those files out of the go-runtime-dev
package and leaving them in the go-dev package would probably be OK.
It's something of an artificial distinction, though.

Regards,
-Matt


Thanks, I will remove these 2 files from go-runtime-dev packages,

and send a v2 patch.








--
BRs

Sandy(Li Changqing)


--
BRs

Sandy(Li Changqing)

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