Re: [yocto] NooB: qemu-native compile error during bitbake core-image-sato

2019-10-15 Thread pwr 

On 15-10-2019 00:04, Ross Burton wrote:

On 14/10/2019 22:32, myken wrote:
For future reference, how could I have found this answer? I searched 
like crazy but never found any reference that qemu is "old" and my 
kernel is "new".


By recognising where the failure was, knowing that glibc changed, and 
that qemu needs to be fixed, then finding the relevant fixes already 
existed in qemu.


Running unsupported distros means discovering stuff like this.  :)

Ross


Yes I know, that's why I'm asking, thanks.
Robert.

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

[yocto] Yocto Project Status WW42’19

2019-10-15 Thread Stephen K Jolley 
Current Dev Position: YP 3.0 Final Release

Next Deadline: YP 3.0 Final Release 25th Oct

SWAT Team Rotation:

   -

   SWAT lead is currently: Paul
   -

   SWAT team rotation: Paul -> Ross on Oct. 18, 2019
   -

   SWAT team rotation: Ross -> Amanda on Oct. 25, 2019
   -

   https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Next Team Meetings:

   -

   Bug Triage meeting Thursday Oct. 17th at 7:30am PDT (
   https://zoom.us/j/454367603)
   -

   Monthly Project Meeting Tuesday Nov. 5th at 8am PDT (
   https://zoom.us/j/990892712) 
   -

   Weekly Engineering Sync Tuesday Oct. 15th at 8am PDT (
   https://zoom.us/j/990892712) 
   -

   Twitch - Next event is Tuesday Nov. 12th at 8am PDT (
   https://www.twitch.tv/yocto_project)


Key Status/Updates:

   -

   YP 3.0 was built and submitted to QA as 3.0 rc2 (rc1 had build failures).
   -

   There is a QA report from QA for 3.0 rc2. There were two issues raised
   from testing but these are both relatively minor issues that are unlikely
   to block release.
   -

   The release is therefore now pending a decision from the TSC on whether
   we should release.
   -

   Master has started taking patches for post 3.0 to try and avoid any
   further backlog buildup.
   -

   We plan to build 2.7.2, followed by 2.6.4 imminently, Armin has been
   preparing the branches.
   -

   We have begun collecting ideas for YP 3.1 in this document:
   
https://docs.google.com/document/d/1UKZIGe88-eq3-pOPtkAvFAegbQDzhy_f4ye64yjnABc/edit?usp=sharing
   -

   If anyone has any status items for the project they’d like to add to the
   weekly reports, please email Richard+Stephen.


Planned Releases for YP 3.0:

   -

   YP 3.0 Final Release 25th Oct


Planned upcoming dot releases:

   -

   YP 2.7.2 (Warrior) is planned this week.
   -

   YP 2.6.4 (Thud) is planned for after YP 2.7.2  release.


Tracking Metrics:

   -

   WDD 2528 (last week 2525) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   Poky Patch Metrics
   -

  Total patches found: 1445 (last week 1448)
  -

  Patches in the Pending State: 586 (41%) [last week 587 (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 Program Manager*

*7867 SW Bayberry Dr., Beaverton, OR 97007*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] using BBMULTICONFIG to create a 32-bit rootfs, kernel, u-boot that also includes a 64-bit kernel, u-boot for NXP i.mx6/i.mx8

2019-10-15 Thread Davis Roman 
Hi Joshua,

Thank you for replying.

Since my last email, I enabled BBMULTICONFIG and was able to build both
32bit and 64bit machine types successfully and so i have both packages
available in their corresponding build folders.

build/tmp-imx6sxsabresd/deploy/rpm/imx6sxsabresd/kernel-4.14.98-r0.imx6sxsabresd.rpm
build/tmp-imx8mmevk/deploy/rpm/imx8mmevk/kernel-4.14.98-r0.imx8mmevk.rpm

I checked out mcdepends however I don't believe this helps me to do the
last piece which is to pull the 64-bit kernel package into my 32-bit image.
According to the yocto docs, mcdepends ensures that imageA is built only
after imageB has finished building (or at least that's how I understand it).

In parallel, I'm studying a patch that was upstreamed in 2017 for adding
support for multiple kernel packages (
http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143674.html
)
This appears to be in line with what I'm looking to do however the wrinkle
is that I'm dealing with two kernels from two different machine types
whereas the patch dealt with two kernels of the same machine type.
I'm still trying to understand the implications of this. My feeling is that
I need a hybrid approach of bbmulticonfig and the above patch for adding
multiple kernel packages.

Please let me know if you have any thoughts.

Thanks,

Davis

On Fri, Oct 4, 2019 at 10:59 PM Joshua Watt  wrote:

>
>
> On Fri, Oct 4, 2019, 7:04 PM Davis Roman  wrote:
>
>> Hello,
>>
>> We're working on a Linux distro for two systems where one is based on
>> NXP i.mx6(32-bit,armv7) and the other i.mx8(64-bit,armv8).
>>
>> I have two machine types defined in Yocto so individually I can build
>> either one however our goal is to create a single distro that can run on
>> both processors.
>>
>> So the idea is to use BBMULTICONFIG(
>> https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBMULTICONFIG
>> )
>> to build two separate images,
>>
>> 1) a 32-bit distro for an i.mx6
>> 2) a 64-bit distro for an i.mx8
>>
>> and then finally, take the 32-bit distro and add the 64-bit
>> kernel+modules and u-boot.
>>
>> ---
>> |--|
>> ||   32-bit rootfs||
>> |--|
>> |-   - |
>> || 32-bit kernel |   |  64-bit kernel ||
>> |-   - |
>> |-   - |
>> || 32-bit u-boot |   |  64-bit u-boot ||
>> |-   - |
>> ---
>>i.mx6solo i.mx8m mini
>>
>> We've already tried our existing 32-bit rootfs + 64-bit kernel/u-boot on
>> the i.mx8 and the system runs.
>> So in theory, it should just be a matter of getting yocto to assemble
>> all the pieces together.
>>
>> I don't have much experience with BBMULTICONFIG so any ideas or comments
>> on how to proceed would be appreciated.
>>
>
> You are on the right track. Create two multiconfig files one for each
> machine, then user mcdepends (
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#dev-enabling-multiple-configuration-build-dependencies)
> to pull the 64 bit kernel, etc. into the 32 bit image.
>
> BBMULTICONFIG is used in local.conf to select which multiconfigs you want
> to enable. In your case it would have to list both of the ones that you
> define.
>
>
>> Thank you,
>>
>> Davis
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] using BBMULTICONFIG to create a 32-bit rootfs, kernel, u-boot that also includes a 64-bit kernel, u-boot for NXP i.mx6/i.mx8

2019-10-15 Thread Joshua Watt 


On 10/15/19 2:03 PM, Davis Roman wrote:

Hi Joshua,

Thank you for replying.

Since my last email, I enabled BBMULTICONFIG and was able to build 
both 32bit and 64bit machine types successfully and so i have both 
packages available in their corresponding build folders.


build/tmp-imx6sxsabresd/deploy/rpm/imx6sxsabresd/kernel-4.14.98-r0.imx6sxsabresd.rpm
build/tmp-imx8mmevk/deploy/rpm/imx8mmevk/kernel-4.14.98-r0.imx8mmevk.rpm

I checked out mcdepends however I don't believe this helps me to do 
the last piece which is to pull the 64-bit kernel package into my 
32-bit image.
According to the yocto docs, mcdepends ensures that imageA is built 
only after imageB has finished building (or at least that's how I 
understand it).


The documentation might be a little misleading; mcdepends allows a 
*task* from one multiconfig to depend on a *task* from another. Using 
the image creation task (do_rootfs) is just an example.


I think one way to do what you want is write a recipe that mcdepends on 
the do_deploy task from the 64-bit kernel recipe, pulls the deployed 
kernel image, repackage it, and then install that recipe's package into 
the 32-bit rootfs. There might be other ways that someone knows about 
that would be better/cleaner, but that's what I would do.




In parallel, I'm studying a patch that was upstreamed in 2017 for 
adding support for multiple kernel packages 
(http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143674.html)
This appears to be in line with what I'm looking to do however the 
wrinkle is that I'm dealing with two kernels from two different 
machine types whereas the patch dealt with two kernels of the same 
machine type.
I'm still trying to understand the implications of this. My feeling is 
that I need a hybrid approach of bbmulticonfig and the above patch for 
adding multiple kernel packages.


Ya, you might be able to do that if your new recipes looks like a kernel 
"flavor" described in that patch I'm not quite clear on what the 
advantage of doing that in this case would be; not that there isn't one 
to be had, I just can't see it with a cursory glance :).




Please let me know if you have any thoughts.

Thanks,

Davis

On Fri, Oct 4, 2019 at 10:59 PM Joshua Watt > wrote:




On Fri, Oct 4, 2019, 7:04 PM Davis Roman mailto:davis.roma...@gmail.com>> wrote:

Hello,

We're working on a Linux distro for two systems where one is
based on
NXP i.mx6(32-bit,armv7) and the other i.mx8(64-bit,armv8).

I have two machine types defined in Yocto so individually I
can build
either one however our goal is to create a single distro that
can run on both processors.

So the idea is to use

BBMULTICONFIG(https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBMULTICONFIG)

to build two separate images,

1) a 32-bit distro for an i.mx6
2) a 64-bit distro for an i.mx8

and then finally, take the 32-bit distro and add the 64-bit
kernel+modules and u-boot.

---
|--|
||           32-bit rootfs            ||
|--|
|-   - |
|| 32-bit kernel |   |  64-bit kernel ||
|-   - |
|-   - |
|| 32-bit u-boot |   |  64-bit u-boot ||
|-   - |
---
   i.mx6solo             i.mx8m mini

We've already tried our existing 32-bit rootfs + 64-bit
kernel/u-boot on the i.mx8 and the system runs.
So in theory, it should just be a matter of getting yocto to
assemble all the pieces together.

I don't have much experience with BBMULTICONFIG so any ideas
or comments on how to proceed would be appreciated.


You are on the right track. Create two multiconfig files one for
each machine, then user mcdepends

(https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#dev-enabling-multiple-configuration-build-dependencies)
to pull the 64 bit kernel, etc. into the 32 bit image.

BBMULTICONFIG is used in local.conf to select which multiconfigs
you want to enable. In your case it would have to list both of the
ones that you define.


Thank you,

Davis
-- 
___

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


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

Re: [yocto] [opkg-devel] [OE-core][opkg-utils ] Bug 13528 : adding SPDX license identifier

2019-10-15 Thread Alejandro Del Castillo 


On 10/14/19 7:36 AM, Ycn aKaJoseph wrote:
> Hi,
> 
> GPL-2.0-only was applied to script without previous Licences and 
> GPL-2.0-or-later to those mentioning it, however I'm wondering if I 
> should also add a SPDX id to the makefile ?
> 
> Here's first attempt without identifier to the Makefile.

I don't have a preference regarding adding a SPDX identifier for the 
Makefile. If I don't see any comments one way or the other, I will pull 
the patch in, by the end of the week.

thanks again for taking care of this,

Alejandro

> On Fri, Oct 11, 2019 at 6:45 PM  > wrote:
> 
> On Fri, 2019-10-11 at 15:54 +, Alejandro Del Castillo wrote:
>  > On 10/11/19 8:51 AM, Ycn aKaJoseph wrote:
>  > > Hi guys,
>  > >
>  > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528
> 
> 
> 
>  > > <
>  > >
> 
> https://urldefense.com/v3/__https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528__;!fqWJcnlTkjM!8RtsWJXbDz_l063ZSVKrRMwvQ5KGdD0lk9aSjlUW9VHM2wufITJnBuIvovQxoT0yJXu-6Q$
>  > > >
>  > >
>  > > I'm about to work on that bug however most of the script in opkg-
>  > > utils
>  > > dir are un-licenced and there's no hint for me to decide what SPDX
>  > > Identifier to add.
>  >
>  > thanks for doing this!
>  >
>  > > The doubt concerns those script :
>  > > makePackage
>  > > opkg-build
>  > > opkg-buildpackage
>  > > opkg-compare-indexes
>  > > opkg-diff
>  > > opkg-extract-file
>  > > opkg-graph-deps
>  > > opkg-list-fields
>  > > opkg-make-index
>  > > opkg-show-deps
>  > > opkg-unbuild
>  > > opkg-update-index
>  > >
>  > > What license do you want them to carry ?
>  >
>  > Looking at the commit history, opkg-graph-deps was authored by Haris
>  > Okanovic, and the rest by Richard Purdie (included them on the
>  > thread).
>  >
>  > My take on it:  since opkg is licensed as GPLv2+, and the files that
>  > have a license in opkg-utils are GPLv2+, make sense to me to license
>  > the rest as GPLv2+ too.
> 
> I didn't author these, they were imported from ipkg-utils which was
> part of handhelds.org
> 
> .
> I did modify things quite a bit during the
> import.
> 
> handhelds.org
> 
> 's
> CVS repos aren't there any more but I do have old
> sources lying around locally. I have a snapshot of the CVS repo from
> 20050930 and it has GPLv2 COPYING file (not 2+, just 2).
> 
> I'd suggest we follow the original licensing of that and go with GPLv2.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto