Re: [yocto] Contribute meta-installer to yocto

[Mark Hatle]

On 11/28/17 9:45 AM, akuster808 wrote:
> 
> 
> On 11/27/2017 09:20 AM, Mark Hatle wrote:
>> On 11/21/17 3:24 PM, Burton, Ross wrote:
>>> On 21 November 2017 at 08:55, Hongxu Jia >> > wrote:
>>>
>>> If yocto is interested in this layer and will accept it,
>>> I could send pull request or some one directly fetch
>>> from above github master branch.
>>>
>>>
>>> Are you asking for a git repo on git.yoctoproject.org
>>> ?  If you want one I believe the process is to 
>>> ask
>>> Michael Halstead.  There's no reason why it can't be maintained in this
>>> repository forever though,  just submit it to the layer index.
>> The request is for more then just a repository.  (We can get a repository
>> anywhere..)  What he is asking for is, is this something that the Yocto 
>> Project
>> itself wants to own.  He is still offering to be the maintainer of the layer,
>> but the project being owned by the Yocto Project itself has more 
>> implications.
> That is an interesting question.  Are you suggesting a discussion with
> the YP membership  since they are the ones who are providing the
> resources for the Project?

At present, we (Hongxu) intend to maintain the code and continue to evolve and
do all of the activities you would expect.  But I do think the YP membership
needs to at least be involved in a discussion of 'should this be a YP layer or
not'.  With the understanding that branding and [some day] resources may be
needed to continue the work.

(I want to make sure this isn't just shoveled over a wall and ignored.. that
serves no one.)

>>
>> I.e. using the bugzilla, discussion on the @yoctoproject.org mailing lists,
>> etc... what happens if he is no longer able to willing to maintain the 
>> layer.. etc.
>>
>> In addition, my understanding is a target based installer has places to 
>> insert
>> logos.  Currently these are blank.  If the Yocto Project wants to be the home
>> for this, then I would also hope that specific logos would be approved for 
>> use
>> within the default installer instance.
>>
>> If this is outside of the scope of what the Yocto Project itself wants to 
>> own,
>> then OpenEmbedded is the next place that might see value in this if not,
>> then a github project will be fine.
> 
> 
> Having an open discussion, like this is more in line with open source
> philosophy and I thank you.

This is exactly why I wanted it done this way.  The discussion needs to be open.
 This isn't a vendor specific BSP or vendor specific chunk of code.. (At least
it's not intended to be.)  Thus the broader question being asked.

> Kind regards,
> Armin
>>> Ross
> 
> 

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

Re: [yocto] How to add support for "usb WIFI dongle"?

[Alan Martinovic]

I can't confirm, but it just might be that "ipw2x00" is actually a firmware.
(Haven't seen a firware specified explicetly in the menu config before).

Ref: https://wiki.debian.org/brcm80211

I recently had a question that might share some light on the firmware
- driver relation:
 (given that it really is firmware you check in the menuconfig)

https://electronics.stackexchange.com/questions/342118/design-decision-for-dynamic-firmware-loading


On Tue, Nov 28, 2017 at 4:00 PM, Jerry Lian  wrote:
> Thanks Alan, I follow your instruction and it works eventually!
>
> But I got another question:
>
> I am using official Raspberry-PI WIFI dongle (BCM43143)
> I configure kernel so that driver "brcm80211" is enabled, however, WIFI is
> not working.
> Then I add driver "ipw2x00", then WIFI works.
> So my question, why do we need both "ipw2x00" and "brcm80211" for official
> Raspberry-PI WIFI dongle?
> (Sometimes the WIFI dongle works if I add drivers: "brcm80211, iwlwifi,
> rt2x00", without "ipw2x00", so I am really confused!)
>
> Thanks!
>
>
>
>
>
>
>
> On Tue, Nov 21, 2017 at 12:04 PM, Alan Martinovic
>  wrote:
>>
>> Some hints on where to start at:
>>
>> > What should I do to add support for "usb WIFI dongle"
>>
>> Am guessing the dongle works with Raspbian or id gets detected
>> once you plug it into a desktop Linux machine.
>> Once you do that type:
>>
>> dmesg
>>
>> And it will list the kernel modules related to your dongle.
>> You can use those buzzwords to google for what does
>> enabling the dongle actually translates to in terms of kernel config.
>>
>> After that (depending what linux you're using) figure out how to
>> run menuconfig. It might be something like:
>>
>> bitbake your-kernel-package-name -c menuconfig
>>
>> and try checking out the boxes that you found out
>> might be relevant to your wifi dongle.
>> Save it, build the image, and see if it got you somewhere.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 21, 2017 at 5:32 PM, Jerry Lian  wrote:
>> > I am confused on adding support for "usb WIFI dongle":
>> > * My boards do NOT have WIFI capability, so I will add a "usb WIFI
>> > dongle".
>> >   (I have two boards: Raspberri-PI-2, SIMATIC IOT-2020)
>> > * Suppose we start from "core-image-sato"
>> > * What should I do to add support for "usb WIFI dongle"
>> > * After we build/boot the image, how can we verify and bring the WIFI
>> > up?
>> >
>> > Thanks!
>> > Jerry
>> >
>> > --
>> > ___
>> > 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: [linux-yocto] v4.12.x - stable updates comprising v4.12.15

[Paul Gortmaker]

[v4.12.x - stable updates comprising v4.12.15] On 26/11/2017 (Sun 02:49) Paul 
Gortmaker wrote:

> Bruce, Yocto kernel folks:
> 
> Here is the 1st 4.12.x stable update.  Continuing on top of the final
> Greg KH released v4.12.14 kernel, we now have the appropriate content
> from 4.13.4 --> 4.13.5 (inclusive) applied on top of the GregKH
> baseline. 
> 
> Since the last 4.12 release was done at the same time as 4.13.3, that is
> why auditing of 4.13.4+ content for appropriate 4.12.x commits was
> chosen as a starting point.  These combined 4.13.x releases result in
> just about 185 backported commits to the 4.12.x baseline we wish to
> extend maintenance on.

Since I was in the mindset of auditing and adding appropriate patches, I
continued to work through some more of the 4.13.x content.  So now we
have a 4.12.16, which is based on the appropriate content from the audit
of what was added into 4.13.6 to 4.13.9 inclusive, which also gives us
about 185 more stable commits for our 4.12.x baseline.

Everything below (testing, locations, signed tag) remains true for .16
just as it did for the earlier .15 release.  Feel free to merge both at
once if you have not merged .15 yet.

Paul.
--

> 
> As usual, I've put this 4.12.x queue through the various testing that I
> figured made sense, which includes but is not limited to:
> 
> -x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
> -build MIPS, PPC, ARM, ARM64 with defconfig
> -build x86-64 allmodconfig/allyesconfig
> -build i386 allmodconfig/allyesconfig
> 
> I bumped the 4.12 Makefile and did the signed tag just as per the previously
> released 4.8.x versions for the older release.
> 
> Please find a signed v4.12.15 tag using this key:
> 
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
> 
> in the repo in my kernel.org directory here:
> 
>https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
>git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git
> 
> for merge to standard/base in linux-yocto-4.12 and then out from there
> into the other base and BSP branches.
> 
> For those who are interested, the evolution of the commits is here:
> 
>https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/
> 
> This repo isn't needed for anything; it just exists for transparency and
> so people can see how the commits were adjusted to apply to the 4.12.x
> kernel baseline in case people are interested.
> 
> Paul.
> --
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] rpm/dnf issues when building an SDK

[Tobias Olausson]

Hey all,

Just for any future users that encounter the same issues, it's a bug in
utils.py for bitbake, for which there is a patch submitted here:
https://patchwork.openembedded.org/patch/144399/

Applying the patch as follows:
patch -d /path/to/poky -p1 <
/path/to/0001-bitbake-lib-bb-utils-fix-movefile-copy-to-dir-fallba.patch

Makes the SDK build succeed on all my machines.

//Tobias


On 11/13/2017 06:13 PM, Tobias Olausson wrote:
> Hey,
>
> I have a weird issue when generating an SDK for the image I'm building.
> Somehow, I end up with the following errors:
>
> $ bitbake -c populate_sdk core-image-pelux-minimal
> ERROR: core-image-pelux-minimal-1.0-r0 do_populate_sdk: unable to place
> /home/vagrant/pelux_yocto/build/tmp/work/intel_corei7_64-pelux-linux/core-image-pelux-minimal/1.0-r0/sdk/image/etc/rpmrc
> in final SDK location
> ERROR: core-image-pelux-minimal-1.0-r0 do_populate_sdk: unable to place
> /home/vagrant/pelux_yocto/build/tmp/work/intel_corei7_64-pelux-linux/core-image-pelux-minimal/1.0-r0/sdk/image/etc/dnf/dnf.conf
> in final SDK location
>
> I have no idea why, and re-running the populate_sdk step succeeds
> without any tasks being run, and even after those errors, an sdk is
> produced, but I end up with 2 errors and a non-zero exit code. A quick
> check easily reveals that the files it wanted to place in "final SDK
> location" are non-existent, so the error as such makes sense.
>
> In my CI system I build this using vagrant with docker as the provider,
> and it's only then I notice this issue. When building locally (with
> docker or otherwise) there are no such issues. The CI system (and when I
> build locally) are ubuntu and debian, respectively. The error is present
> in the CI setup regardless of having rpm on the host machine or not.
>
> I couldn't find any info on other people having the same problem, and I
> start feeling stuck on this because it only fails in some environments,
> it seems.
>
> Cheers,
>
> Tobias Olausson
> Software Engineer
>
> PELAGICORE | Experience Change
> http://www.pelagicore.com/
>
> Registered Office Gothenburg, Sweden
> Registration No. 556780-4199
>
> PELAGICORE a part of LUXOFT




This e-mail and any attachment(s) are intended only for the recipient(s) named 
above and others who have been specifically authorized to receive them. They 
may contain confidential information. If you are not the intended recipient, 
please do not read this email or its attachment(s). Furthermore, you are hereby 
notified that any dissemination, distribution or copying of this e-mail and any 
attachment(s) is strictly prohibited. If you have received this e-mail in 
error, please immediately notify the sender by replying to this e-mail and then 
delete this e-mail and any attachment(s) or copies thereof from your system. 
Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Contribute meta-installer to yocto

[akuster808]

On 11/27/2017 09:20 AM, Mark Hatle wrote:
> On 11/21/17 3:24 PM, Burton, Ross wrote:
>> On 21 November 2017 at 08:55, Hongxu Jia > > wrote:
>>
>> If yocto is interested in this layer and will accept it,
>> I could send pull request or some one directly fetch
>> from above github master branch.
>>
>>
>> Are you asking for a git repo on git.yoctoproject.org
>> ?  If you want one I believe the process is to 
>> ask
>> Michael Halstead.  There's no reason why it can't be maintained in this
>> repository forever though,  just submit it to the layer index.
> The request is for more then just a repository.  (We can get a repository
> anywhere..)  What he is asking for is, is this something that the Yocto 
> Project
> itself wants to own.  He is still offering to be the maintainer of the layer,
> but the project being owned by the Yocto Project itself has more implications.
That is an interesting question.  Are you suggesting a discussion with
the YP membership  since they are the ones who are providing the
resources for the Project?

>
> I.e. using the bugzilla, discussion on the @yoctoproject.org mailing lists,
> etc... what happens if he is no longer able to willing to maintain the 
> layer.. etc.
>
> In addition, my understanding is a target based installer has places to insert
> logos.  Currently these are blank.  If the Yocto Project wants to be the home
> for this, then I would also hope that specific logos would be approved for use
> within the default installer instance.
>
> If this is outside of the scope of what the Yocto Project itself wants to own,
> then OpenEmbedded is the next place that might see value in this if not,
> then a github project will be fine.


Having an open discussion, like this is more in line with open source
philosophy and I thank you.

Kind regards,
Armin
>> Ross


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

Re: [yocto] How to add support for "usb WIFI dongle"?

[Jerry Lian]

Thanks Alan, I follow your instruction and it works eventually!

But I got another question:

   - I am using official Raspberry-PI WIFI dongle (BCM43143)
   - I configure kernel so that driver "brcm80211" is enabled, however,
   WIFI is not working.
   - Then I add driver "ipw2x00", then WIFI works.
   - So my question, why do we need both "ipw2x00" and "brcm80211" for
   official Raspberry-PI WIFI dongle?
   - (Sometimes the WIFI dongle works if I add drivers: "brcm80211,
   iwlwifi, rt2x00", without "ipw2x00", so I am really confused!)

Thanks!







On Tue, Nov 21, 2017 at 12:04 PM, Alan Martinovic  wrote:

> Some hints on where to start at:
>
> > What should I do to add support for "usb WIFI dongle"
>
> Am guessing the dongle works with Raspbian or id gets detected
> once you plug it into a desktop Linux machine.
> Once you do that type:
>
> dmesg
>
> And it will list the kernel modules related to your dongle.
> You can use those buzzwords to google for what does
> enabling the dongle actually translates to in terms of kernel config.
>
> After that (depending what linux you're using) figure out how to
> run menuconfig. It might be something like:
>
> bitbake your-kernel-package-name -c menuconfig
>
> and try checking out the boxes that you found out
> might be relevant to your wifi dongle.
> Save it, build the image, and see if it got you somewhere.
>
>
>
>
>
>
>
> On Tue, Nov 21, 2017 at 5:32 PM, Jerry Lian  wrote:
> > I am confused on adding support for "usb WIFI dongle":
> > * My boards do NOT have WIFI capability, so I will add a "usb WIFI
> dongle".
> >   (I have two boards: Raspberri-PI-2, SIMATIC IOT-2020)
> > * Suppose we start from "core-image-sato"
> > * What should I do to add support for "usb WIFI dongle"
> > * After we build/boot the image, how can we verify and bring the WIFI up?
> >
> > Thanks!
> > Jerry
> >
> > --
> > ___
> > 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] How to generate SPDX Information

[Joshua Watt]

On Tue, 2017-11-28 at 14:57 +0100, Christian Ege wrote:
> Hello,
> 
> due to the fact there is a license troll who actively sue German
> companies. I did some research to comply ith the need to provide the
> copyright information within my YOCTO builds. My research ended up
> with the spdx.class which includes support for the fossology tool.
> But
> the current version of fossology does not support the spdx plugin
> used
> in the spdx.class anymore [1] This plugin is not updated since 4
> years. As an alternative there is the DoSOCSv2 tool [2] for which a
> Patch by Lei Maohui exists which was not accepted and Lei ended up in
> a separate layer called meta-spdxscanner [3].
> 
> So my specific question is, what are the recommended actions to
> comply
> to provide copyright information with the sourcecode/binary? What is
> the state of the art at the moment and how do the users of oe/yocto
> solve this requirement.

Not sure if it is the best method, but we include all the license
information in our (readonly) rootfs image by adding 

 COPY_LIC_MANIFEST = "1"
 COPY_LIC_DIRS = "1"

to local.conf. Our UI application then parses /usr/share/common-
licenses/license.manifest show a scrollable list of software with a
short blurb for each like:
"licensed under one or more of the following licence(s): ${SPDX list
from license manifest}"

If the SPDX list contains the text "GPL" (and maybe some others, can't
remember right now), we add "Source code may be downloaded from http://
www.company.com/foss". We upload a monolithic tarball containing all
the GPL code to this site every release. This tarball is generated by
adding:

 INHERIT += "archiver"
 ARCHIVER_MODE[dumpdata] = "1"
 ARCHIVER_MODE[recipe] = "1"

to local.conf, then filtering out the copyleft software with some post-
processing scripts.

Finally, for each package, we add the text from the actual licenses
files for each package (from the directories under /usr/share/common-
licenses// so that the user can see the full terms.

Not sure if it is the best method, but it works for us. I think it
covers all the license requirements (mainly, attribution and making the
copyleft source available).

> 
> Thanks in advance,
> Christian
> 
> -- 
> [1] https://github.com/FOSSology-SPDX/fossology-spdx
> [2] https://github.com/DoSOCSv2/DoSOCSv2
> [3] https://layers.openembedded.org/layerindex/branch/master/layer/me
> ta-spdxscanner/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to generate SPDX Information

[Christian Ege]

Hello,

due to the fact there is a license troll who actively sue German
companies. I did some research to comply ith the need to provide the
copyright information within my YOCTO builds. My research ended up
with the spdx.class which includes support for the fossology tool. But
the current version of fossology does not support the spdx plugin used
in the spdx.class anymore [1] This plugin is not updated since 4
years. As an alternative there is the DoSOCSv2 tool [2] for which a
Patch by Lei Maohui exists which was not accepted and Lei ended up in
a separate layer called meta-spdxscanner [3].

So my specific question is, what are the recommended actions to comply
to provide copyright information with the sourcecode/binary? What is
the state of the art at the moment and how do the users of oe/yocto
solve this requirement.

Thanks in advance,
Christian

-- 
[1] https://github.com/FOSSology-SPDX/fossology-spdx
[2] https://github.com/DoSOCSv2/DoSOCSv2
[3] 
https://layers.openembedded.org/layerindex/branch/master/layer/meta-spdxscanner/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto