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

[Sean Hudson]

On 11/2/18 10:57 AM, akuster808 wrote:
> Morning Trevor,
> 
> On 11/1/18 7:27 PM, Trevor Woerner wrote:
>> Hi Jon,
>>
>> On Thu, Nov 1, 2018 at 3:56 PM Jon Mason > > wrote:
>>
>> I am planning on being at SCaLE (assuming the OEDEM happens there).
>>
>> Many corporate travel budgets are tied to presenting at conferences.
>> So, if we could somehow get a track there (which might be too late in
>> the game to do now), then we might be able to get enough people
>> present to make it happen and pull in others whose budget is more
>> flexible.
>>
>>
>> As it turns out, I'll be organising the YP/OE Miniconf that will most
>> likely be run on the Sunday. I was going to send out a separate email
>> discussing the Miniconf, but I guess now is as good a time as any :-)
> 
> 
> I would like a some clarification. As fas as the OE Board knows, we had
> one room available on Sunday. Is this the same room or did you find some
> other space at the venue? I am a bit confused about the messaging. The
> subject and Jon's statement are all about OEDaM but your addition to
> this tread is about a Miniconf. Is the Miniconf a separate thing?
> 
>>
>> While it's true that the CFP has closed for SCaLE, I plan to open my
>> own CFP specifically for the Miniconf, and I don't plan to close it
>> until closer to the conference itself. I want to encourage people to
>> give talks about current things, as such, having a CFP close this
>> early wouldn't do.
>>
>> We haven't decided on a format for the Miniconf, exactly, if we have
>> traditional talks, we'll have 6 sessions (2 before lunch, 4 after).
>> But depending on interest and what sort of proposals we get, we might
>> do some longer, some shorter talks.
> 
> 
> May I ask who "We" are? AFAIK, Behan and Tom are doing a *-ale tracks at
> Scale.
> 
> 


Trevor,

  The OpenEmbedded board had a quick discussion and would like to share
a few things.
  First, the board fully supports any OpenEmbedded member organizing
community events.
  Second, thank you for stepping up to organize such an event.  We
greatly appreciate it and will support you as best we can.

  Third, the desire for user-centric events or a separate conference
entirely has been discussed at several of the recent developer meetings,
while at the same time, we've seen a growing number of users attending
these meetings "just to observe".  It sounds like the event that you are
starting to organize at SCaLE presents the perfect opportunity to start
creating such a user-centric meeting.

 Lastly, as was brought up at the meeting in Edinburgh, this is all
occurring *very* late for conference planning, which adds greatly to
everyone's stress and angst.

  With that said, the board does have a concern, a request, and a
suggestion. (triple threat!)

  The concern arises from the history associated with the OEDEM and
OEDAM names/meetings.  Specifically, we are concerned about possible
confusion that may arise from overusing those terms.  FWIW, members
expressed this at the last several developer meetings publicly and have
also expressed reservations to board members privately. For many,
employers will only pay for them to go to a single "meeting" a year.
This means we need to make it easy for users, developers, and their
employers to know what type of meeting is being held.

  So, we request that you call the event that you are organizing an
OpenEmbedded User Summit, or something similar.  We think this will help
clarify things and it also preserves the use of the "official",
OpenEmbedded Developer Meetings terms, e.g. OEDEM or OEDAM, for the OE
developers.

  Recognizing that we are scrambling to get things organized at the last
minute, we further suggest that we put together a quick verbal
discussion with all the necessary folks present.  ATM, that appears to
be you, Tom K, Behan, and the OE board.

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

Re: [yocto] How to avoid stripping libthread_db to enable gdb thread debugging?

[Mark Hatle]

On 11/2/18 1:03 PM, Hui Liu wrote:
> Hi,
> 
> I add gdb to my recipe, and found gdb can't enable thread debugging.
> 
> The warning from gdb is:
> 
> warning: Unable to find libthread_db matching inferior's thread library, 
> thread
> debugging will not be available
> 
> After some investigation, I found it is due to libthread_db is stripped:
> 
> nm lib/libthread_db.so.1
> nm: lib/libthread_db.so.1: no symbols
> 
> Could you let me know how to avoid this?

You need to install the dbg package.  This contains the symbols necessary for
debugging.  You can install it for either cross or local (on target) debugging.
In the cross-debuging case, you should not need it on the target.

--Mark

> -- 
> Thanks,
> Hui
> 
> 

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

[yocto] How to avoid stripping libthread_db to enable gdb thread debugging?

[Hui Liu]

Hi,

I add gdb to my recipe, and found gdb can't enable thread debugging.

The warning from gdb is:

warning: Unable to find libthread_db matching inferior's thread library,
thread debugging will not be available

After some investigation, I found it is due to libthread_db is stripped:

nm lib/libthread_db.so.1
nm: lib/libthread_db.so.1: no symbols

Could you let me know how to avoid this?

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

Re: [yocto] Kernel development using externalsrc

[Khem Raj]

On Fri, Nov 2, 2018 at 8:47 AM CHMIELARZ Radoslaw
 wrote:
>
> Hi all,
>
>
>
> The company I work for uses yocto to build an image with a custom linux 
> kernel. The documentation 
> (https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html) suggests 
> a setup where the kernel is under git and the kernel recipe specifies this 
> git repository hence the workflow is the following:
>
> Make changes in local kernel directory
> Submit changes to git (and presumably push to shared space)
> Run yocto build which fetches the changes
>
>
>
> However since I don’t want to push the changes to git server before I test 
> locally I have added the kernel sources using externalsrc. Unfortunately this 
> has the drawback that linux-libc-headers runs do_configure and do_install 
> phase which invalidates glibc-initial and requires a recompilation of a 
> couple of hundreds of packages. I would like to avoid it.
>
>
>
> Thus my question is: how can I retain this setup where I only make local 
> changes to the kernel without yocto rebuilding glibc and dependent packages?
>
>
>
> To add more background we are using morty release and the changes in kernel 
> will be in configuration and devices (probably as modules but some may be 
> included with the kernel binary). Glibc is also an externalsrc project at the 
> moment since I’m trying to upgrade to newer yocto release but this will be 
> taken from git in the long run.
>

may be you want to take a look at devtool workflow
https://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#using-devtool-in-your-workflow
>
>
> Cheers,
>
> Radek
>
> --
> ___
> 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] Install a pre-build ipkg package at build time

[Khem Raj]

On Fri, Nov 2, 2018 at 8:48 AM João Gonçalves
 wrote:
>
> Hi all,
>
> I have some pre-build opkg packages and I need to install them on my target 
> image, is this possible?
> I tried to use the bin_package class but I didn't found any example, I'm also 
> not sure if it can be used this way or just to install the data files 
> extracted from the ipkg file. Anyway I also tried to extract the binary files 
> form the package and use the bin_package class to install them, but with no 
> success.
>
> Does anyone have any example of this?
>

once you point SRC_URI to your ipk
inherit bin_package should be then able to help in repackaging it
you have to post specific errors so we can see what might be going on

> Thanks,
> João Gonçalves
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[akuster808]

Morning Trevor,

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


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

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


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


- armin

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

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

[darknighte]

OE folks,

  The OE board hasn't made a final decision yet, but plan to make one
soon.  We will send an update as soon as we have.
  In the meantime, if folks who are interested in attending something
at SCaLE, it will be factored into the board's decision making
process.
On Thu, Nov 1, 2018 at 2:57 PM Jon Mason  wrote:
>
> On Thu, Nov 1, 2018 at 10:04 AM Trevor Woerner  wrote:
> >
> > Hello Fellow YP/OE Enthusiasts!
> >
> > There were discussions at our recent OEDEM regarding:
> > - our next developers meeting
> > - SCaLE 2019
> > - expanding/adding to the YP/OE presence at conferences (i.e. our own
> >   miniconf?)
> >
> > Please see time indices: 12:13 and 16:45
> > https://docs.google.com/document/d/1YDAHjIOXCIgvSZVOKCYLxa8h26dkruX8zspoge7zCpk
> >
> > Unfortunately, although lots of opinions were expressed, nothing concrete 
> > was
> > decided. Many people pointed out that their travel budgets are already
> > strained or maxed out, so adding another conference would be difficult if 
> > not
> > impossible. It's unclear how many "core" YP/OE people might show up at next
> > year's SCaLE. Also, given that this year's ELC scheduling hiccup is a 
> > one-off,
> > maybe it doesn't make as much sense to put in all the work required to run 
> > an
> > OEDAM at SCaLE if it's only ever going to happen once. Therefore I think I 
> > can
> > safely say the organizing committee for YP/OE Things at SCaLE 2019 is 
> > leaning
> > towards not running an OEDAM.
> >
> > It's not too late to change our plans. If a large number of core people 
> > reply
> > to this email saying they want and OEDAM in March and will be available in
> > Pasadena, then we could accommodate it. It's just that we didn't leave
> > Edinburgh with the feeling that an OEDAM at SCaLE was feasible. Also, at 
> > this
> > point SCaLE isn't on the radars of many of the core YP/OE people, and
> > currently the conference tends to attract users rather than developers (or 
> > so
> > is my impression).
> >
> > Thoughts?
>
> I am planning on being at SCaLE (assuming the OEDEM happens there).
>
> Many corporate travel budgets are tied to presenting at conferences.
> So, if we could somehow get a track there (which might be too late in
> the game to do now), then we might be able to get enough people
> present to make it happen and pull in others whose budget is more
> flexible.
>
> Thanks,
> Jon
>
> >
> > Best regards,
> > Trevor
> > --
> > ___
> > Openembedded-core mailing list
> > openembedded-c...@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] 2.6 migration guide

[Scott Rifenbark]

Peter,

Thanks
Scott

https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-openssl-changes
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-security-changes

On Fri, Nov 2, 2018 at 8:10 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> In “4.14.2. OpenSSL Changes”, change “both versions their dependency
> chains” to “both versions in their dependency chains”.
>
> In “4.14.4. Security Changes”, change “files” to “flags” (twice).
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org <
> openembedded-core-boun...@lists.openembedded.org> *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 30 oktober 2018 23:07
> *To:* Paul Eggleton 
> *Cc:* Yocto discussion list ; openembedded-core <
> openembedded-c...@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 migration guide
>
>
>
> Paul,
>
>
>
> Thanks for sending.
>
>
>
> Contributors
>
>
>
> I have an initial section at
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
> which is based on Richard's input.  I am sure there are more items.
>
>
>
> Thanks,
>
> Scott
>
>
>
> On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
> Hi folks
>
> When Scott prepares the migration guide for a release, he usually looks to
> me
> to collate the notable changes for it (those requiring user intervention).
> I
> haven't prepared anything yet though and the 2.6 release is fast
> approaching.
> Can anyone who has been involved in or is aware of such changes in master
> for
> upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>
> Scott and I will take care of cleaning it up, so things added there don't
> need
> to be perfect.
>
> I will also be doing my usual trawl through the commits in the release for
> the
> more general changelog, so most things will get picked up that way, but
> it's
> really helpful if people with first-hand knowledge of the implications of
> some
> of these changes are involved in how they get documented.
>
> Thanks,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Install a pre-build ipkg package at build time

[João Gonçalves]

Hi all,

I have some pre-build opkg packages and I need to install them on my target
image, is this possible?
I tried to use the bin_package class but I didn't found any example, I'm
also not sure if it can be used this way or just to install the data files
extracted from the ipkg file. Anyway I also tried to extract the binary
files form the package and use the bin_package class to install them, but
with no success.

Does anyone have any example of this?

Thanks,
João Gonçalves
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Kernel development using externalsrc

[CHMIELARZ Radoslaw]

Hi all,

The company I work for uses yocto to build an image with a custom linux kernel. 
The documentation 
(https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html) suggests a 
setup where the kernel is under git and the kernel recipe specifies this git 
repository hence the workflow is the following:

  1.  Make changes in local kernel directory
  2.  Submit changes to git (and presumably push to shared space)
  3.  Run yocto build which fetches the changes

However since I don't want to push the changes to git server before I test 
locally I have added the kernel sources using externalsrc. Unfortunately this 
has the drawback that linux-libc-headers runs do_configure and do_install phase 
which invalidates glibc-initial and requires a recompilation of a couple of 
hundreds of packages. I would like to avoid it.

Thus my question is: how can I retain this setup where I only make local 
changes to the kernel without yocto rebuilding glibc and dependent packages?

To add more background we are using morty release and the changes in kernel 
will be in configuration and devices (probably as modules but some may be 
included with the kernel binary). Glibc is also an externalsrc project at the 
moment since I'm trying to upgrade to newer yocto release but this will be 
taken from git in the long run.

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

Re: [yocto] [OE-core] 2.6 migration guide

[Peter Kjellerstedt]

In “4.14.2. OpenSSL Changes”, change “both versions their dependency chains” to 
“both versions in their dependency chains”.
In “4.14.4. Security Changes”, change “files” to “flags” (twice).

//Peter

From: openembedded-core-boun...@lists.openembedded.org 
 On Behalf Of Scott Rifenbark
Sent: den 30 oktober 2018 23:07
To: Paul Eggleton 
Cc: Yocto discussion list ; openembedded-core 

Subject: Re: [OE-core] 2.6 migration guide

Paul,

Thanks for sending.

Contributors

I have an initial section at 
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
 which is based on Richard's input.  I am sure there are more items.

Thanks,
Scott

On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton 
mailto:paul.eggle...@linux.intel.com>> wrote:
Hi folks

When Scott prepares the migration guide for a release, he usually looks to me
to collate the notable changes for it (those requiring user intervention). I
haven't prepared anything yet though and the 2.6 release is fast approaching.
Can anyone who has been involved in or is aware of such changes in master for
upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:

  https://wiki.yoctoproject.org/wiki/FutureMigrationGuide

Scott and I will take care of cleaning it up, so things added there don't need
to be perfect.

I will also be doing my usual trawl through the commits in the release for the
more general changelog, so most things will get picked up that way, but it's
really helpful if people with first-hand knowledge of the implications of some
of these changes are involved in how they get documented.

Thanks,
Paul

--
Paul Eggleton
Intel Open Source Technology Centre

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

[yocto] Problem with including python-paho-mqtt in the Yocto build

[Pramode C.E]

Hi,

I am doing a "bitbake  -c populate_sdk_ext core-image-base" (yocto 2.5)
with the following line in my local.conf:

CORE_IMAGE_EXTRA_INSTALL += "python-paho-mqtt"

The build fails with the following errors (this is a build which does not
use any sstate-cache from previous builds - it is totally from scratch):

ERROR: Task python-py-native.do_fetch attempted to execute unexpectedly
ERROR: Task python-py-native.do_prepare_recipe_sysroot attempted to execute
unexpectedly
ERROR: Task python-py-native.do_unpack attempted to execute unexpectedly
ERROR: Task python-py-native.do_patch attempted to execute unexpectedly
ERROR: Task python-py-native.do_populate_lic attempted to execute
unexpectedly and should have been setscened
ERROR: Task python-py-native.do_configure attempted to execute unexpectedly
ERROR: Task python-py-native.do_compile attempted to execute unexpectedly
ERROR: Task python-py-native.do_install attempted to execute unexpectedly
ERROR: Task python-py-native.do_populate_sysroot attempted to execute
unexpectedly and should have been setscened
NOTE: Tasks Summary: Attempted 6657 tasks of which 6657 didn't need to be
rerun and all succeeded.

I have verified that inclusion of "python-paho-mqtt" is causing this
problem .. remove that line and the build succeeds.

I had seen such errors previously during eSDK installation, but the fact
that these errors are occuring during the SDK build itself, that too
without using any sstate from previous builds, make me wonder what has gone
wrong. Any pointers will be highly appreciated!

Thanks and regards,
Pramode C.E
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

[Khem Raj]

On Fri, Nov 2, 2018 at 2:02 AM Kevin Hao  wrote:
>
> On Fri, Nov 02, 2018 at 09:01:34AM +0100, Heiko Schocher wrote:
> > Hello Kevin,
> >
> > Am 01.11.2018 um 03:18 schrieb Kevin Hao:
> > > On Wed, Oct 31, 2018 at 02:23:00PM +0100, Heiko Schocher wrote:
> > > > Hello all,
> > > >
> > > > just builded core-image-minimal with current head of thud branch for
> > > > the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 
> > > > 4.14.78",
> > > > installed the resulting sd card image and boot it, and get:
> > > >
> > > > INIT: Id "O0" respawning too fast: disabled for
> > > > 5 minutes
> > > >
> > > > Reason seems to be:
> > > >
> > > > meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > >
> > > > SERIAL_CONSOLES = "115200;ttyO0"
> > > >
> > > > shouldn't this be
> > > >
> > > > SERIAL_CONSOLES = "115200;ttyS0"
> > > >
> > > > With this fix, sd card image boot fine ... may I oversee seomthing
> > > > obvious ?
> > >
> > > No, it should be 'ttyO0'. It is set by the omap serial driver. You can
> > > refer the following in platform_data/serial-omap.h:
> > >#define OMAP_SERIAL_NAME"ttyO"
> >
> > Yes, you are right, but I see with linux kernel 4.14.78 from
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y=e7405910ca5553eae8744af4e5c03e64ee048cb1
> >
> > and I see:
> >
> > [0.00] Linux version 4.14.78 (oe-user@oe-host) (gcc version 8.2.0
> > (GCC)) #1 Thu Nov 1 10:51:09 UTC 2018
> > [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> > cr=10c5387d
> > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> > instruction cache
> > [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
> > [...]
> > [0.362878] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
> > [0.365758] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, 
> > base_baud = 300) is a 8250
> > [1.030465] console [ttyS0] enabled
> >
> > So definitely a ttyS0 ...
>
> OK, so you don't use the linux-yocto kernel, you must not use the Yocto kernel
> meta either.

I dont think there is such a rule. meta-yocto-bsps are meant as
references and people might want to enhance them.

 The reason that you got a ttyS0 here is that you use the
> 8250_omap.c driver. But in Yocto we use the omap-serial.c driver. You can
> workaround this issue by enabling SERIAL_8250_OMAP_TTYO_FIXUP.
>

omap serial is obsolete why does linux-yocto keeps using it.
seondly, machine config should enable both consoles ttyO0 and ttyS0 if
you know that at least one kernel is using ttyO0

> Thanks,
> Kevin
>
> >
> > bye,
> > Heiko
> > >
> > > Thanks,
> > > Kevin
> > >
> > > >
> > > > bye,
> > > > Heiko
> > > > --
> > > > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > > > Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
> > > > --
> > > > ___
> > > > yocto mailing list
> > > > yocto@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

[Bruce Ashfield]

On 2018-11-02 4:59 AM, Kevin Hao wrote:

On Fri, Nov 02, 2018 at 09:01:34AM +0100, Heiko Schocher wrote:

Hello Kevin,

Am 01.11.2018 um 03:18 schrieb Kevin Hao:

On Wed, Oct 31, 2018 at 02:23:00PM +0100, Heiko Schocher wrote:

Hello all,

just builded core-image-minimal with current head of thud branch for
the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 4.14.78",
installed the resulting sd card image and boot it, and get:

INIT: Id "O0" respawning too fast: disabled for
5 minutes

Reason seems to be:

meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

SERIAL_CONSOLES = "115200;ttyO0"

shouldn't this be

SERIAL_CONSOLES = "115200;ttyS0"

With this fix, sd card image boot fine ... may I oversee seomthing
obvious ?


No, it should be 'ttyO0'. It is set by the omap serial driver. You can
refer the following in platform_data/serial-omap.h:
#define OMAP_SERIAL_NAME"ttyO"


Yes, you are right, but I see with linux kernel 4.14.78 from

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y=e7405910ca5553eae8744af4e5c03e64ee048cb1

and I see:

[0.00] Linux version 4.14.78 (oe-user@oe-host) (gcc version 8.2.0
(GCC)) #1 Thu Nov 1 10:51:09 UTC 2018
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
[...]
[0.362878] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
[0.365758] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud = 
300) is a 8250
[1.030465] console [ttyS0] enabled

So definitely a ttyS0 ...


OK, so you don't use the linux-yocto kernel, you must not use the Yocto kernel
meta either. The reason that you got a ttyS0 here is that you use the
8250_omap.c driver. But in Yocto we use the omap-serial.c driver. You can
workaround this issue by enabling SERIAL_8250_OMAP_TTYO_FIXUP.


Thanks Kevin!

I had missed that detail in my reply.

Bruce



Thanks,
Kevin



bye,
Heiko


Thanks,
Kevin



bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de




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

Re: [yocto] Can not build SDK in rocko 'nothing provides /usr/bin/python...'

[Peter Bergin]

On 2018-11-02 09:54, Erik Botö wrote:

and there they have added python to RDEPENDS. Adding that should pull
python in to the SDK as well.

Thank you Erik!

Yes, adding python to RDEPENDS_kernel-devsrc solved the problem.

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

Re: [yocto] force a factory-preset sdk to quemu

[Zolee K]

Thanks for the tip! I'll do it!

On 2018. Nov 2., Fri at 10:08, Kosta Zertsekel  wrote:

> On Fri, Nov 2, 2018, 10:28 Zolee K wrote:
>
>> I got my board with Yocto based SDK but there is no quemu in the
>> configfile by default. Is it possible to add quemu capability manually to
>> factory-preset sdk?
>>
> If Yocto SDK you have is actually Yocto eSDK (extended SDK), you can try
> the below:
> $ MACHINE=qemux86 bitbake build-image
>
> --- Kosta Z
>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] force a factory-preset sdk to quemu

[Kosta Zertsekel]

On Fri, Nov 2, 2018, 10:28 Zolee K wrote:

> I got my board with Yocto based SDK but there is no quemu in the
> configfile by default. Is it possible to add quemu capability manually to
> factory-preset sdk?
>
If Yocto SDK you have is actually Yocto eSDK (extended SDK), you can try
the below:
$ MACHINE=qemux86 bitbake build-image

--- Kosta Z

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

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

[Kevin Hao]

On Fri, Nov 02, 2018 at 09:01:34AM +0100, Heiko Schocher wrote:
> Hello Kevin,
> 
> Am 01.11.2018 um 03:18 schrieb Kevin Hao:
> > On Wed, Oct 31, 2018 at 02:23:00PM +0100, Heiko Schocher wrote:
> > > Hello all,
> > > 
> > > just builded core-image-minimal with current head of thud branch for
> > > the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 
> > > 4.14.78",
> > > installed the resulting sd card image and boot it, and get:
> > > 
> > > INIT: Id "O0" respawning too fast: disabled for
> > > 5 minutes
> > > 
> > > Reason seems to be:
> > > 
> > > meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > > 
> > > SERIAL_CONSOLES = "115200;ttyO0"
> > > 
> > > shouldn't this be
> > > 
> > > SERIAL_CONSOLES = "115200;ttyS0"
> > > 
> > > With this fix, sd card image boot fine ... may I oversee seomthing
> > > obvious ?
> > 
> > No, it should be 'ttyO0'. It is set by the omap serial driver. You can
> > refer the following in platform_data/serial-omap.h:
> >#define OMAP_SERIAL_NAME"ttyO"
> 
> Yes, you are right, but I see with linux kernel 4.14.78 from
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y=e7405910ca5553eae8744af4e5c03e64ee048cb1
> 
> and I see:
> 
> [0.00] Linux version 4.14.78 (oe-user@oe-host) (gcc version 8.2.0
> (GCC)) #1 Thu Nov 1 10:51:09 UTC 2018
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
> [...]
> [0.362878] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
> [0.365758] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud 
> = 300) is a 8250
> [1.030465] console [ttyS0] enabled
> 
> So definitely a ttyS0 ...

OK, so you don't use the linux-yocto kernel, you must not use the Yocto kernel
meta either. The reason that you got a ttyS0 here is that you use the
8250_omap.c driver. But in Yocto we use the omap-serial.c driver. You can
workaround this issue by enabling SERIAL_8250_OMAP_TTYO_FIXUP.

Thanks,
Kevin

> 
> bye,
> Heiko
> > 
> > Thanks,
> > Kevin
> > 
> > > 
> > > bye,
> > > Heiko
> > > -- 
> > > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > > Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
> > > -- 
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


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

Re: [yocto] Can not build SDK in rocko 'nothing provides /usr/bin/python...'

[Erik Botö]

On Fri, Nov 2, 2018 at 8:30 AM Peter Bergin  wrote:
>
> Hi,
>
> I'm working in rocko branch and trying to build a SDK with kernel-devsrc on a 
> standard qemux86 machine. During task populate_sdk I get the following error:
>
> ERROR: core-image-base-1.0-r0 do_populate_sdk: Could not invoke dnf. Command 
> '/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf
>  -y -c 
> /work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/2.4.3/sysroots/i586-poky-linux/etc/dnf/dnf.conf
>  
> --setopt=reposdir=/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/2.4.3/sysroots/i586-poky-linux/etc/yum.repos.d
>  
> --repofrompath=oe-repo,/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/oe-sdk-repo
>  
> --installroot=/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/2.4.3/sysroots/i586-poky-linux
>  
> --setopt=logdir=/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/temp
>  --nogpgcheck install packagegroup-core-standalone-sdk-target run-postinsts 
> psplash packagegroup-base-extended packagegroup-core-boot linu
 x-libc-headers-dev kernel-devsrc' returned 1:
> Added oe-repo repo from 
> /work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/oe-sdk-repo
> Last metadata expiration check: 0:00:00 ago on Fri 02 Nov 2018 07:14:37 AM 
> UTC.
> Error:
>  Problem: conflicting requests
>   - nothing provides /usr/bin/python needed by kernel-devsrc-1.0-r0.qemux86
>
> ERROR: core-image-base-1.0-r0 do_populate_sdk: Function failed: 
> do_populate_sdk
> ERROR: Logfile of failure stored in: 
> /work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/temp/log.do_populate_sdk.25760
> ERROR: Task 
> (/work/yocto/rocko/layers/poky/meta/recipes-core/images/core-image-base.bb:do_populate_sdk)
>  failed with exit code '1'
>
> Any ideas about what the problem is and how to fix?

I had a quick look at how the kernel-devsrc recipe looks in master,
and there they have added python to RDEPENDS. Adding that should pull
python in to the SDK as well.

See 
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/kernel-devsrc.bb?h=master#n234

Cheers,
Erik
>
> My addition to standard Yocto configuration is:
>
> TOOLCHAIN_TARGET_TASK_append = " \
> kernel-devsrc \
> linux-libc-headers-dev \
> "
>
> I first build image with 'bitbake core-image-base' then I got the error when 
> building SDK with 'bitbake core-image-base -c populate_sdk'
>
>
> Thanks,
> /Peter
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] of: Fix of_populate_phandle_cache compilation error

[He Zhe]

When merging tag 'v4.18.10' into v4.18/standard/base, 05a9931 "of: fix phandle
cache creation for DTs with no phandles" from v4.18.10 introduces an undefined
label "out" and causes the follow compilation error.

drivers/of/base.c: In function 'of_populate_phandle_cache':
drivers/of/base.c:124:3: error: label 'out' used but not defined
   goto out;
   ^~~~

This is because the base of 05a9931 has been modified by b75caf0 "of: allocate /
free phandle cache outside of the devtree_lock".

This patch picks a part of
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?h=
linux-4.18.y-rt=9866102318991051e5e99085d3c88d6483ee70d4
to fix this error, and can be dropped when rebasing above 9866102.

Signed-off-by: He Zhe 
---
This error affects all arches building preempt-rt kernel with "of" by default.

 drivers/of/base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ecb495df4aad..49da3726cda5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -119,14 +119,14 @@ void of_populate_phandle_cache(void)
phandles++;
 
raw_spin_unlock_irqrestore(_lock, flags);
+   kfree(shadow);
 
if (!phandles)
-   goto out;
+   return;
 
cache_entries = roundup_pow_of_two(phandles);
phandle_cache_mask = cache_entries - 1;
 
-   kfree(shadow);
shadow = kcalloc(cache_entries, sizeof(*phandle_cache), GFP_KERNEL);
 
if (!shadow)
-- 
2.11.0

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

[yocto] force a factory-preset sdk to quemu

[Zolee K]

Hi All,

I got my board with Yocto based SDK but there is no quemu in the configfile
by default. Is it possible to add quemu capability manually to
factory-preset sdk? Id like to run the linux in an emulated enviroment, its
quiet boring to burn the sd card for each and every minor changes that I
make.

Thank,

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

Re: [yocto] thud, beaglebone-yocto.conf: SERIAL_CONSOLES setting

[Heiko Schocher]

Hello Kevin,

Am 01.11.2018 um 03:18 schrieb Kevin Hao:

On Wed, Oct 31, 2018 at 02:23:00PM +0100, Heiko Schocher wrote:

Hello all,

just builded core-image-minimal with current head of thud branch for
the beaglebone-yocto machine, with linux 4.14.x LTS "Linux version 4.14.78",
installed the resulting sd card image and boot it, and get:

INIT: Id "O0" respawning too fast: disabled for
5 minutes

Reason seems to be:

meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

SERIAL_CONSOLES = "115200;ttyO0"

shouldn't this be

SERIAL_CONSOLES = "115200;ttyS0"

With this fix, sd card image boot fine ... may I oversee seomthing
obvious ?


No, it should be 'ttyO0'. It is set by the omap serial driver. You can
refer the following in platform_data/serial-omap.h:
   #define OMAP_SERIAL_NAME"ttyO"


Yes, you are right, but I see with linux kernel 4.14.78 from

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y=e7405910ca5553eae8744af4e5c03e64ee048cb1

and I see:

[0.00] Linux version 4.14.78 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 Thu Nov 1 
10:51:09 UTC 2018

[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
[...]
[0.362878] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
[0.365758] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud = 
300) is a 8250
[1.030465] console [ttyS0] enabled

So definitely a ttyS0 ...

bye,
Heiko


Thanks,
Kevin



bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Can not build SDK in rocko 'nothing provides /usr/bin/python...'

[Peter Bergin]

Hi,

I'm working in rocko branch and trying to build a SDK with kernel-devsrc 
on a standard qemux86 machine. During task populate_sdk I get the 
following error:


ERROR: core-image-base-1.0-r0 do_populate_sdk: Could not invoke dnf. Command 
'/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf
 -y -c 
/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/2.4.3/sysroots/i586-poky-linux/etc/dnf/dnf.conf
 
--setopt=reposdir=/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/2.4.3/sysroots/i586-poky-linux/etc/yum.repos.d
 
--repofrompath=oe-repo,/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/oe-sdk-repo
 
--installroot=/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/2.4.3/sysroots/i586-poky-linux
 
--setopt=logdir=/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/temp
 --nogpgcheck install packagegroup-core-standalone-sdk-target run-postinsts 
psplash packagegroup-base-extended packagegroup-core-boot 
linux-libc-headers-dev kernel-devsrc' returned 1:
Added oe-repo repo from 
/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/oe-sdk-repo
Last metadata expiration check: 0:00:00 ago on Fri 02 Nov 2018 07:14:37 AM UTC.
Error:
 Problem: conflicting requests
  - nothing provides /usr/bin/python needed by kernel-devsrc-1.0-r0.qemux86

ERROR: core-image-base-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
ERROR: Logfile of failure stored in: 
/work/yocto/rocko/qemux86/tmp/work/qemux86-poky-linux/core-image-base/1.0-r0/temp/log.do_populate_sdk.25760
ERROR: Task 
(/work/yocto/rocko/layers/poky/meta/recipes-core/images/core-image-base.bb:do_populate_sdk)
 failed with exit code '1'

Any ideas about what the problem is and how to fix?

My addition to standard Yocto configuration is:

TOOLCHAIN_TARGET_TASK_append = " \
    kernel-devsrc \
    linux-libc-headers-dev \
"

I first build image with 'bitbake core-image-base' then I got the error 
when building SDK with 'bitbake core-image-base -c populate_sdk'



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

[yocto] [patchtest-oe][PATCH] test_patch_cve.py: fix cve tag checking logic

[Chen Qi]

The current logic for checking cve tag is not correct. It errors
out if and only if the patch contains a line which begins with
CVE-- and contains nothing else.

It will not error out if the patch contains no CVE information, nor
will it error out if the patch contains line like below.

'Fix CVE--'

I can see that the cve tag checking logic tries to ensure the patch
contains something like 'CVE: CVE--'. So fix to implement such
logic.

Signed-off-by: Chen Qi 
---
 tests/test_patch_cve.py | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/tests/test_patch_cve.py b/tests/test_patch_cve.py
index 39e7267..df6fe46 100644
--- a/tests/test_patch_cve.py
+++ b/tests/test_patch_cve.py
@@ -22,7 +22,6 @@ import re
 class CVE(base.Base):
 
 re_cve_pattern = re.compile("CVE\-\d{4}\-\d+", re.IGNORECASE)
-re_cve_payload_pattern = re.compile("\+CVE\-\d{4}\-\d+", re.IGNORECASE)
 re_cve_payload_tag = re.compile("\+CVE:(\s+CVE\-\d{4}\-\d+)+")
 
 def setUp(self):
@@ -39,10 +38,12 @@ class CVE(base.Base):
 def test_cve_tag_format(self):
 for commit in CVE.commits:
 if self.re_cve_pattern.search(commit.shortlog) or 
self.re_cve_pattern.search(commit.commit_message):
+tag_found = False
 for line in commit.payload.splitlines():
-# first match is lax but second strict
-if self.re_cve_payload_pattern.match(line):
-if not self.re_cve_payload_tag.match(line):
-self.fail('Missing or incorrectly formatted CVE 
tag in included patch file',
-  'Correct or include the CVE tag on cve 
patch with format: "CVE: CVE--"',
-  commit)
+if self.re_cve_payload_tag.match(line):
+tag_found = True
+break
+if not tag_found:
+self.fail('Missing or incorrectly formatted CVE tag in 
included patch file',
+  'Correct or include the CVE tag on cve patch 
with format: "CVE: CVE--"',
+  commit)
-- 
2.7.4

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