date:20200219

Re: [yocto] [OE-core] Yocto Project Status WW07'20

2020-02-19 Thread Sangeeta Jain

Planned upcoming dot releases:

  *   YP 2.7.3 built and in QA

I didn't see any notification for this build. Am I missing something?

Thanks,
Sangeeta

From: openembedded-core-boun...@lists.openembedded.org 
 On Behalf Of 
sjolley.yp...@gmail.com
Sent: Wednesday, 19 February, 2020 12:10 AM
To: yo...@yoctoproject.org; openembedded-c...@lists.openembedded.org
Subject: [OE-core] Yocto Project Status WW07'20


Current Dev Position: YP 3.1 M3

Next Deadline: YP 3.1 M3 build date 2/24/2020


Next Team Meetings:

  *   Bug Triage meeting Thursday Feb. 20th  at 7:30am PDT 
(https://zoom.us/j/454367603)
  *   Monthly Project Meeting Tuesday Mar. 3rd  at 8am PDT 
(https://zoom.us/j/990892712)
  *   Weekly Engineering Sync Tuesday Feb. 18th at 8am PDT 
(https://zoom.us/j/990892712)
  *   Twitch - Next event is Tuesday Mar. 10th at 8am PDT 
(https://www.twitch.tv/yocto_project)


Key Status/Updates:

  *   The project recently updated its git hosting infrastructure and there 
were some issues encountered with the cgit http/https repository sharing. Those 
issues should now be resolved, apologies if they caused issues for anyone. The 
git:// protocol sharing was unaffected.
  *   YP 3.0.2 rc2 is in QA with the report due soon.
  *   We continue to see a small number of reproducibility issues with master 
which need resolving for green builds (in particular gstreamer and perl).
  *   A significant memory usage issue was identified during bitbake parsing 
where memory usage would grow in each parser thread linearly per number of 
recipes parsed. This would therefore particularly affect large numbers of 
layers, multilibs and multiconfig. The fix has merged into bitbake along with 
the corresponding zeus and warrior branches. For one test case it reduced peak 
memory usage during parsing for 5 multiconfigs from 20GB to 2GB.
  *   Warrior patches for 2.7.3 are out for review.
  *   With the git infrastructure issue updated, we now have centos8 workers 
added to the autobuilder.
  *   We are making various queued changes to the autobuilder configuration to 
fix bugs, improve efficiency and test coverage but this may result in some test 
result instability as we test and resolve issues.
  *   We're collecting a list of companies, products and projects which use the 
Yocto Project on the wiki: https://wiki.yoctoproject.org/wiki/Project_Users 
Please add any you know are missing (or email Richard/Stephen who can add).
  *   The triage team is worried about attendance at triage meetings and the 
project is finding it hard to find people to help fix bugs. If anyone is 
willing to work on bugs, assistance would be greatly appreciated.


YP 3.1 Milestone Dates:

  *   YP 3.1 M3 build date 2/24/2020
  *   YP 3.1 M3 release date 3/6/2020
  *   YP 3.1 M4 build date  3/30/2020
  *   YP 3.1 M4 release date  4/24/2020


Planned upcoming dot releases:

  *   YP 2.7.3 built and in QA
  *   YP 2.7.3 release date 2/21/2020
  *   YP 3.0.2 build date  2/3/2020
  *   YP 3.0.2 release date 2/14/2020


Tracking Metrics:

  *   WDD 2710 (last week 2728) 
(https://wiki.yoctoproject.org/charts/combo.html)
  *   Poky Patch Metrics

 *   Total patches found: 1360 (last week 1361)
 *   Patches in the Pending State: 546 (40%) [last week 547 (40%)]


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
*Cell:(208) 244-4460
* Email:  sjolley.yp...@gmail.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48521): https://lists.yoctoproject.org/g/yocto/message/48521
Mute This Topic: https://lists.yoctoproject.org/mt/71424332/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

2020-02-19 Thread Sangeeta Jain



> -Original Message-
> From: Mittal, Anuj 
> Sent: Thursday, 20 February, 2020 11:35 AM
> To: Richard Purdie ; akuster808
> ; Jain, Sangeeta ;
> yocto@lists.yoctoproject.org
> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> ; Yeoh, Ee Peng ; Chan,
> Aaron Chun Yew ; sjolley.yp...@gmail.com;
> Tummalapalli, Vineela 
> Subject: RE: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)
> 
> > On Wed, 2020-02-19 at 14:41 -0800, akuster808 wrote:
> > >
> > > On 2/18/20 11:33 PM, Jain, Sangeeta wrote:
> > > > Hi All,
> > > >
> > > > This is the full report for yocto-3.0.2.rc2:
> > > > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contr
> > > > ib
> > > > /tree/?h=intel-yocto-testresults
> > > >
> > > > === Summary 
> > > > No high milestone defects.
> > > > one new defects are found in this cycle - oeqa/runtime test
> > > > 'test_dnf_exclude' failed (Bugid:13797) openssh ptest failed (BUG
> > > > id:13796) bash ptest failed (BUG id:13795)
> > > >
> > > > === Bugs 
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13797
> 
> From the error log, it looks like we are trying to install 7.67 while zeus 
> has 7.66
> so it errors out. I am guessing that curl wasn't built in a clean build 
> directory so
> the correct version of curl is deployed. Can this test be re-run please?
Re-run the test in new build directory and after having 'bitbake curl'.
It is passing now. Updating bug in Bugzila.

> 
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13796
> 
> This needs:
> 
> https://github.com/openssh/openssh-
> portable/commit/ff31f15773ee173502eec4d7861ec56f26bba381
> 
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13795
> 
> Was because of the bash CVE patch.
> 
> > >
> > > Thank you for logging the defects.
> > >
> > > I suspect this in now in the hands of the YP TSC.
> >
> > What is the stable maintainer's thoughts on this?
> >
> > In particular I'm worried about the bash patch and whether the ptest
> > regression above is related to that or not? Any recommendation?
> 
> Looks like it's related but I don't think the impact is much. The test is 
> failing
> because the line number that is expected to fail changed (because of the lines
> being added in the test). So we should be okay in my opinion.
> 
> Thanks,
> 
> Anuj

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48520): https://lists.yoctoproject.org/g/yocto/message/48520
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Modified GENIVI Cannelloni recipe with strange side effects

2020-02-19 Thread Zoran

Hello Laurent,

U R correct (and why I am not surprised?!). :-)

The correct recipe is here (it becomes very simplistic, seems):
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb

I have (out of my ignorance) one question, which confuses me: Why this
functionality does not reside in do_install_append () (I would expect
this to be correct one, but it seems that inheritance in bitbake has
changed)?

Many thanks (what we, ignorant YOCTO guys, will do without the experts),
Zoran
___

On Wed, Feb 19, 2020 at 7:05 PM Laurent Gauthier
 wrote:
>
> Hi Zoran,
>
> I just saw your reply now.
>
> I think that you might want to remove the INHIBIT_SYSROOT_STRIP and
> other INHIBIT_* options from your recipe.
>
> For reference a message from Khem warning that this option should be
> used sparingly:
>
> * https://www.yoctoproject.org/pipermail/yocto/2019-March/044415.html
>
> My best guess is that the use of this option is directly linked to
> chrpath being needed.
>
> As this recipe is being built with a rather clean looking
> CMakeLists.txt none of these weird options are needed.
>
> Kind regards, Laurent.
>
> On Mon, Feb 17, 2020 at 8:01 AM Zoran Stojsavljevic
>  wrote:
> >
> > > The issue I see is that the following files have been build but NOT 
> > > installed:
> > >
> > > * libcannelloni-common.so.0
> > > * libcannelloni-common.so.0.0.1
> >
> > Not quite... The solution is outlined here (in function do_install):
> > +   ## ERROR: QA Issue: package cannelloni contains bad RPATH
> > +   ## quick fix is in a do_install or do_install_append do
> > +   chrpath -d ${D}${bindir}/cannelloni
> >
> > https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb
> > https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb_GENIVI
> >
> > I admit, your first email has shaken my head, so I can see things much
> > more clear. :-)
> >
> > My best guess, this solution is just a workaround (not the final one),
> > since I have in ${D} the following:
> >
> > cannelloni-1.0: package cannelloni contains bad RPATH
> > /home/user/projects2/beaglebone-black/bbb-yocto/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build:
> > in file 
> > /home/user/projects2/beaglebone-black/bbb-yocto/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni/usr/bin/cannelloni
> > [rpaths]
> >
> > So, since my limited knowledge about bitbake build systems ends here,
> > somebody from YOCTO primes (potentially Khem Raj, Ross Burton, maybe
> > even Richard Purdie) should look more closely into this issue
> > (apologies for my unsolicited suggestions).
> >
> > Laurent,
> >
> > Once again, thank you for unselfish help,
> > Zoran
> > ___
> >
> >
> > On Fri, Feb 14, 2020 at 2:20 PM Laurent Gauthier
> >  wrote:
> > >
> > > Hi Zoran,
> > >
> > > You are almost there! I can feel it... :-)
> > >
> > > The issue I see is that the following files have been build but 
> > > NOTinstalled:
> > >
> > > * libcannelloni-common.so.0
> > > * libcannelloni-common.so.0.0.1
> > >
> > > If you make sure that they are installed that should fix your issue.
> > >
> > > Based on the info you provided no RDEPENDS seems to be required as it
> > > all appears that everything is in one package named "cannelloni",
> > > rather than a package for the main executable and then packages for
> > > libraries.
> > >
> > > Kind regards, Laurent.
> > >
> > > On Fri, Feb 14, 2020 at 12:43 PM Zoran Stojsavljevic
> > >  wrote:
> > > >
> > > > Hello Laurent,
> > > >
> > > > Many thanks to you for the help. :-)
> > > >
> > > > I did some modifications, and now I have all the elements in there/in 
> > > > place:
> > > >
> > > > [user@fedora31-ssd cannelloni]$ cd ../../../build/tmp
> > > > [user@fedora31-ssd tmp]$ find . -name libcannelloni*
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/image/usr/lib/libcannelloni-common.so
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/sysroot-destdir/usr/lib/libcannelloni-common.so
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/package/usr/lib/.debug/libcannelloni-common.so
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/package/usr/lib/libcannelloni-common.so
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni/usr/lib/libcannelloni-common.so
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni-dbg/usr/lib/.debug/libcannelloni-common.so
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build/libcannelloni-common.so.0
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build/libcannelloni-common.so.0.0.1
> > > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build/libcannelloni-common.so
> > > > ./sysroots-components/cortexa8hf-neon/cannelloni/usr/lib

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

2020-02-19 Thread Anuj Mittal

> On Wed, 2020-02-19 at 14:41 -0800, akuster808 wrote:
> >
> > On 2/18/20 11:33 PM, Jain, Sangeeta wrote:
> > > Hi All,
> > >
> > > This is the full report for yocto-3.0.2.rc2:
> > > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib
> > > /tree/?h=intel-yocto-testresults
> > >
> > > === Summary 
> > > No high milestone defects.
> > > one new defects are found in this cycle - oeqa/runtime test
> > > 'test_dnf_exclude' failed (Bugid:13797) openssh ptest failed (BUG
> > > id:13796) bash ptest failed (BUG id:13795)
> > >
> > > === Bugs 
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13797

From the error log, it looks like we are trying to install 7.67 while zeus has 
7.66 so it errors out. I am guessing that curl wasn't built in a clean build 
directory so the correct version of curl is deployed. Can this test be re-run 
please?

> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13796

This needs:

https://github.com/openssh/openssh-portable/commit/ff31f15773ee173502eec4d7861ec56f26bba381

> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13795

Was because of the bash CVE patch.

> >
> > Thank you for logging the defects.
> >
> > I suspect this in now in the hands of the YP TSC.
> 
> What is the stable maintainer's thoughts on this?
> 
> In particular I'm worried about the bash patch and whether the ptest 
> regression above
> is related to that or not? Any recommendation?

Looks like it's related but I don't think the impact is much. The test is 
failing because the line number that is expected to fail changed (because of 
the lines being added in the test). So we should be okay in my opinion.

Thanks,

Anuj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48518): https://lists.yoctoproject.org/g/yocto/message/48518
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] You advice to append environment set up to local root shell profile

2020-02-19 Thread JH

May be I should append to shells script.

On 2/20/20, JH  wrote:
> Hi,
>
> I want to setup export LD_LIBRARY_PATH and export PATH to the
> /home/root shell profile, the oe-core base-files has a profile file,
> is it a right way to copy that file to my application layer, to extend
> it and to add new path to export LD_LIBRARY_PATH and export PATH? I'll
> handle it by a base-files_%.bbappend in my application layer.
>
> Thank you.
>
> Kind regards,
>
> - jh
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48517): https://lists.yoctoproject.org/g/yocto/message/48517
Mute This Topic: https://lists.yoctoproject.org/mt/71410439/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] You advice to append environment set up to local root shell profile

2020-02-19 Thread JH

Hi,

I want to setup export LD_LIBRARY_PATH and export PATH to the
/home/root shell profile, the oe-core base-files has a profile file,
is it a right way to copy that file to my application layer, to extend
it and to add new path to export LD_LIBRARY_PATH and export PATH? I'll
handle it by a base-files_%.bbappend in my application layer.

Thank you.

Kind regards,

- jh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48516): https://lists.yoctoproject.org/g/yocto/message/48516
Mute This Topic: https://lists.yoctoproject.org/mt/71410439/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

2020-02-19 Thread Khem Raj




On 2/19/20 2:42 PM, Richard Purdie wrote:

On Wed, 2020-02-19 at 14:41 -0800, akuster808 wrote:


On 2/18/20 11:33 PM, Jain, Sangeeta wrote:

Hi All,

This is the full report for yocto-3.0.2.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
No high milestone defects.
one new defects are found in this cycle - oeqa/runtime test
'test_dnf_exclude' failed (Bugid:13797)
openssh ptest failed (BUG id:13796)
bash ptest failed (BUG id:13795)

=== Bugs 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13797
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13796
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13795


Thank you for logging the defects.

I suspect this in now in the hands of the YP TSC.


What is the stable maintainer's thoughts on this?

In particular I'm worried about the bash patch and whether the ptest
regression above is related to that or not? Any recommendation?



I agree, two failures are openssh related and I think they should be 
root caused.



Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48515): https://lists.yoctoproject.org/g/yocto/message/48515
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

2020-02-19 Thread Richard Purdie

On Wed, 2020-02-19 at 14:41 -0800, akuster808 wrote:
> 
> On 2/18/20 11:33 PM, Jain, Sangeeta wrote:
> > Hi All,
> > 
> > This is the full report for yocto-3.0.2.rc2:  
> > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
> > 
> > === Summary 
> > No high milestone defects.  
> > one new defects are found in this cycle - oeqa/runtime test
> > 'test_dnf_exclude' failed (Bugid:13797)
> > openssh ptest failed (BUG id:13796)
> > bash ptest failed (BUG id:13795)
> > 
> > === Bugs 
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13797
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13796
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13795
> 
> Thank you for logging the defects.
> 
> I suspect this in now in the hands of the YP TSC.

What is the stable maintainer's thoughts on this?

In particular I'm worried about the bash patch and whether the ptest
regression above is related to that or not? Any recommendation?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48514): https://lists.yoctoproject.org/g/yocto/message/48514
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA Cycle report for build (yocto-3.0.2.rc2)

2020-02-19 Thread akuster



On 2/18/20 11:33 PM, Jain, Sangeeta wrote:
> Hi All,
>
> This is the full report for yocto-3.0.2.rc2:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
>
> === Summary 
> No high milestone defects.  
> one new defects are found in this cycle - oeqa/runtime test 
> 'test_dnf_exclude' failed (Bugid:13797)
> openssh ptest failed (BUG id:13796)
> bash ptest failed (BUG id:13795)
>
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13797
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13796
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13795

Thank you for logging the defects.

I suspect this in now in the hands of the YP TSC.

regards,
Armin
>
> Thanks,
> Sangeeta
>
>> -Original Message-
>> From: yocto@lists.yoctoproject.org  On Behalf
>> Of pokybu...@centos7-ty-3.yocto.io
>> Sent: Wednesday, 12 February, 2020 3:56 PM
>> To: yocto@lists.yoctoproject.org
>> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
>> ; Yeoh, Ee Peng ; Chan,
>> Aaron Chun Yew ;
>> richard.pur...@linuxfoundation.org; akuster...@gmail.com;
>> sjolley.yp...@gmail.com; Jain, Sangeeta 
>> Subject: [yocto] QA notification for completed autobuilder build (yocto-
>> 3.0.2.rc2)
>>
>>
>> A build flagged for QA (yocto-3.0.2.rc2) was completed on the autobuilder 
>> and is
>> available at:
>>
>>
>> https://autobuilder.yocto.io/pub/releases/yocto-3.0.2.rc2
>>
>>
>> Build hash information:
>>
>> bitbake: 95687be83e716220eb3893b67428f97fd59fc2c5
>> meta-gplv2: 0f4eecc000f66d114ad258fa31aed66afa292166
>> meta-intel: b04e1edb9300a57e200a187a3255f67b50519202
>> meta-mingw: 756963cc28ebc163df7d7f4b4ee004c18d3d3260
>> oecore: 799b3cd1016bd765f4452a5e81ea5613c9089bce
>> poky: fe857e4179355bcfb79303c16baf3ad87fca59a4
>>
>>
>>
>> This is an automated message from the Yocto Project Autobuilder
>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>> Email: richard.pur...@linuxfoundation.org
>>
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48513): https://lists.yoctoproject.org/g/yocto/message/48513
Mute This Topic: https://lists.yoctoproject.org/mt/7139/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto [thud], [zeus] do_fetch and do_unpack failures with offline/online svn build! #yocto #python

2020-02-19 Thread Mikko Rapeli

On Tue, Feb 18, 2020 at 07:25:15AM +, Georgi Georgiev via 
Lists.Yoctoproject.Org wrote:
> OK,
> I read some code and I added the next line:
> 
> --- a/bitbake/lib/bb/fetch2/svn.py
> +++ b/bitbake/lib/bb/fetch2/svn.py
> @@ -145,6 +145,7 @@ class Svn(FetchMethod):
> 
>  if not ("externals" in ud.parm and ud.parm["externals"] == 
> "nowarn"):
>  # Warn the user if this had externals (won't catch them all)
> +svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
>  output = runfetchcmd("svn propget svn:externals || true", d, 
> workdir=ud.moddir)
>  if output:
>  if "--ignore-externals" in svnfetchcmd.split():
> 
> This works for me perfectly. I may look little redundant but...
> Any comments? 
> @Mikko, 

Looks good to me.

> We have only one svn repo in the whole project :-)

Lucky you :)

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48512): https://lists.yoctoproject.org/g/yocto/message/48512
Mute This Topic: https://lists.yoctoproject.org/mt/70695643/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583
Mute #python: https://lists.yoctoproject.org/mk?hashtag=python&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Issue while adding the support for TLS1.3 in existing krogoth yocto #yocto #yocto #yocto #yocto #apt #raspberrypi #yocto

2020-02-19 Thread Mikko Rapeli

Hi,

On Tue, Feb 18, 2020 at 01:20:25PM +0530, amaya jindal wrote:
>Thanks for your prompt reply. But is not there any way similar to add
>support for TLS1.3 instead of moving to new yocto releases

openssl is tricky to update and requires backporting fixes for many, many 
recipes
to get builds passing etc. Depending on project size, it may be possible
to update only those components which you use, e.g. backport commits from
poky master or release branches like warrior. The number of backported changes
will be large. I've ported openssl 1.1.1d patches to yocto 2.5 sumo but it 
wasn't
pretty. A strategy with regular yocto updates is much better and forces you
to think of your dependencies and patches much harder.

Hope this helps,

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48511): https://lists.yoctoproject.org/g/yocto/message/48511
Mute This Topic: https://lists.yoctoproject.org/mt/71367169/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583
Mute #raspberrypi: 
https://lists.yoctoproject.org/mk?hashtag=raspberrypi&subid=6691583
Mute #apt: https://lists.yoctoproject.org/mk?hashtag=apt&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Debugging gdb built by Yocto

2020-02-19 Thread Richard Purdie

On Tue, 2020-02-18 at 11:26 -0500, Patrick Doyle wrote:
> Does anybody have any tips or tricks for how I might debug the
> (cross-canadian) gdb built by Yocto's SDK?
> 
> I need to add some printf's to the gdb code to help track down why
> something isn't working, but none of my traditional
> get-ready-to-debug-this-code techniques are working.
> 
> How can I run the gdb that I just built?  Note that I am presuming
> that I can
> 
> $ bitbake gdb-cross-canadian-mipsel -ccompile -f

Do you perhaps want gdb-cross-mipsel ?

cross-canadian is designed to be run as part of the SDK.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48510): https://lists.yoctoproject.org/g/yocto/message/48510
Mute This Topic: https://lists.yoctoproject.org/mt/71406927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Creating a build system which can scale. #yocto

2020-02-19 Thread Mikko Rapeli

Hi,

Good pointers in this thread already. Here are mine:

 * Share sstate mirror and download cache from release builds to
   developer topic builds. NFS, web server or rsync before calling bitbake
   will work.

 * I've added buildhistory and prserv database as extra files to sstate mirror
   and use that to initiate new developer topic and release builds. This way
   we don't add prserv or buildhistory git trees to critical path in builds
   but get the benefits of QA checks, binary package versions, full history etc.

 * Don't use virtual machines or clouds to build. Bare metal throw away machines
   are much faster and more reliable. We've broken all clouds.

 * Use rm_work to reduce disk space usage during builds.

 * Tune build machines to bind things into memory and to not flush things to 
disk
   all the time since bitbake tmp, images etc are anyways going to be tar'ed
   as build output. If they fit to page cache in RAM, you can avoid a lot of IO 
and
   save disks/ssd. Linux kernel vm tuning does this:

$ cat /etc/sysctl.d/99-build_server_fs_ops_to_memory.conf 
# fs cache can use 90% of memory before system starts io to disk,
# keep as much as possible in RAM
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 90
# keep stuff for 12h in memory before writing to disk,
# allows reusing data as much as possible between builds
vm.dirty_expire_centisecs = 432
vm.dirtytime_expire_seconds = 432000
# allow single process to use 60% of system RAM for file caches, e.g. image 
build
vm.dirty_bytes = 0
vm.dirty_ratio = 60
# disable periodic background writes, only write when running out of RAM
vm.dirty_writeback_centisecs = 0

 * Finding optimal cost and power combination for build slaves is tricky.
   Track CPU, memory, IO and network usage for your project and find out which
   one is the bottle neck. For us it was RAM. CPUs are not effectly used by 
bitbake
   builds except when all hell breaks loose with C++ projects and their 
templates.
   Lots of CPU time is wasted when running single threaded bitbake tasks and
   creating images. Avoiding IO to disk and caching to RAM helps. I've not seen 
benefits
   of having more than 64 gigs of RAM or more than 32 CPUs (with hyper 
threading).
   Also project evolve over time and suddenly may start eating more RAM and 
triggering
   the kernel OOM killer, shivers..

Hope this helps,

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48509): https://lists.yoctoproject.org/g/yocto/message/48509
Mute This Topic: https://lists.yoctoproject.org/mt/71347835/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Debugging gdb built by Yocto

2020-02-19 Thread Khem Raj




On 2/18/20 8:26 AM, Patrick Doyle wrote:

Does anybody have any tips or tricks for how I might debug the
(cross-canadian) gdb built by Yocto's SDK?

I need to add some printf's to the gdb code to help track down why
something isn't working, but none of my traditional
get-ready-to-debug-this-code techniques are working.

How can I run the gdb that I just built?  Note that I am presuming that I can

$ bitbake gdb-cross-canadian-mipsel -ccompile -f

to rebuild gdb after I add a printf or two to it... but I can't figure
out how to run gdb without going through the sdk installation step.

$ bitbake gdb-cross-canadian-mipsel -cdevshell
# ../build-mipsel-poky-linux/gdb/gdb
bash: ../build-mipsel-poky-linux/gdb/gdb: No such file or directory
# file ../build-mipsel-poky-linux/gdb/gdb
../build-mipsel-poky-linux/gdb/gdb: ELF 64-bit LSB shared object,
x86-64, version 1 (GNU/Linux), dynamically linked, interpreter
/opt/iro, BuildID[sha1]=7f985bbe4cb6c97558b159860b2498f6389b254e, for
GNU/Linux 3.2.0, not stripped
# ldd ../build-mipsel-poky-linux/gdb/gdb
../build-mipsel-poky-linux/gdb/gdb: /lib/x86_64-linux-gnu/libm.so.6:
version `GLIBC_2.29' not found (required by
../build-mipsel-poky-linux/gdb/gdb)
 linux-vdso.so.1 =>  (0x7fff8a0c2000)
  ...

# 
LD_LIBRARY_PATH=../recipe-sysroot-native/usr/libexec:../recipe-sysroot-native/usr/lib
../build-mipsel-poky-linux/gdb/gdb
bash: ../build-mipsel-poky-linux/gdb/gdb: No such file or directory

None of the techniques from my bag-of-tricks works.

I guess I could go grab the source myself, manually apply the patches
myself, build it, and see if that works.

Or I could sit down real hard and think about why I am trying to debug
the canadian-cross built tool on my development host... perhaps I
should try debugging the native (cross)-gdb on my native host.  I'll
go try that now, but, in the mean time, I thought it was about time
for me to ask others for some clues.

Any clues or pointers?


its perhaps due to the fact that host where this will run is sdkhost and 
not your normal buildhost, so perhaps you can use uninative tarball 
provided glibc to run it if your sdkhost is similar to buildhost and 
that might work.




--wpd




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48508): https://lists.yoctoproject.org/g/yocto/message/48508
Mute This Topic: https://lists.yoctoproject.org/mt/71406927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] do_rootfs task took long time to finish

2020-02-19 Thread Khem Raj




On 2/17/20 11:55 PM, Marek Belisko wrote:

Hi,

I'm debugging strange issue that do_rootfs task took ~50 minutes. I
enabled buildstats and from that I learned it's quite long. Any ideas
how to debug this issue? My idea was to add timestamp to do_rootfs
tasks but I'm not sure if it's even possible. Thanks.



how big is the image its creating, might affect the time. Secondly
use some system perf monitor to see which tool is taking so long.


BR,

marek




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48507): https://lists.yoctoproject.org/g/yocto/message/48507
Mute This Topic: https://lists.yoctoproject.org/mt/71406925/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

2020-02-19 Thread Mikko Rapeli

Hi,

(lets keep this on the list too)

On Wed, Feb 19, 2020 at 04:51:18PM +0100, Armando Hernandez wrote:
> Hi Mikko,
> 
> Thanks for your reply. I checked your suggestion but does not work for me.
> I did included a .bbappend file in which I:
> 
>- re-set EXTRA_OECMAKE to an empty string (i.e. ""). - my intention was
>to pass no arguments when building the nativesdk. Now I know that this
>accion overwrites the value of EXTRA_OECMAKE in the original .bb file
>- added the line BBCLASSEXTEND = "nativesdk" to this new .bbappend file
>- added the line DEPENDS_class-target += "systemd" to the original .bb
>file
> 
> I found out that this configures both the target and the nativesdk
> libraries without systemd - which later on causes a failure when bitbake
> attempts to pull up everything to create the final image.
> 
> Basically, I'd like to find a way to unset or overwrite the following
> variables when building the nativesdk package:
> 
>- SYSTEMD_PACKAGES
>- SYSTEMD_SERVICE_${PN}
>- SYSTEMD_AUTO_ENABLE_${PN}
>- SYSTEMD_SERVICE_${PN}-systemd
>- SYSTEMD_AUTO_ENABLE_${PN}-systemd
>- EXTRA_OECMAKE

You can add _class-[target|native|nativesdk] to all variables
to override defaults.

Verify with "bitbake -e".

Hope this helps,

-Mikko

> Is it possible to do so? Or do I come up with another recipe of the sama
> package exclusively for the nativesdk?
> 
> Thanks again.
> 
> Armando Hernandez
> 
> On Wed, Feb 19, 2020 at 10:44 AM  wrote:
> 
> > Hi,
> >
> > On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> > > Hello,
> > >
> > > I have a recipe that builds a library. The recipe specifies an
> > additional package "${PN}-systemd" along with other systemd related
> > variables and finally it instructs that the package should be built with
> > "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended
> > this recipe to nativesdk because I need this library on it. When trying to
> > build the corresponding nativesdk package, the build fails at the
> > configuration step (i.e. "do_configure") claiming it cannot find the
> > package systemd.
> > >
> > > Is there a way I can install the -already-generated libraries into my
> > SDK (potentially via the corresponding nativesdk recipe) without having to
> > rebuild the package? Or do I need to somehow include such systemd package
> > in my sdk (which I don't think I need at all)?
> > >
> > > Any hints and pointers as to were to look at are very well appreciated.
> > > Thanks.
> >
> > Make the systemd dependency for target only, e.g. DEPENDS_class-target +=
> > "systemd"
> > etc.
> >
> > There may be relevant use cases to build some of systemd components or
> > tools
> > to native or nativesdk targets too. In that case add BBCLASSEXTEND +=
> > "nativesdk" etc
> > in a bbappend to systemd.
> >
> > Hope this helps,
> >
> > -Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48506): https://lists.yoctoproject.org/g/yocto/message/48506
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk&subid=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-updater] [meta-updater-raspberrypi] ERROR: No recipes available for: ..../meta-updater-raspberrypi/recipes-bsp/u-boot/libubootenv_%.bbappend

2020-02-19 Thread Greg Wilson-Lindberg

 I'm trying to add support for ostree to out boot2qt yocto warrior build for 
raspberry pi4. I've added meta-updater & meta-updater-raspberrypi to the build 
and when I start bitbake I get the following error:

ERROR: No recipes available for:
  .../sources/meta-updater-raspberrypi/recipes-bsp/u-boot/libubootenv_%.bbappend

I've tried downloading the HereOtaConnect sample project but it doesn't have 
the libubootenv recipe.
I researched where libubootenv is from and it is part of the sbabic swupddate 
system. Does this mean that I need to install meta-swupdate to get the 
libuboot? Does libubootenv automatically disable the fw* utilities from uboot?
Is there something else that I'
Regards,
Greg Wilson-Lindberg

 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48505): https://lists.yoctoproject.org/g/yocto/message/48505
Mute This Topic: https://lists.yoctoproject.org/mt/71407331/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

2020-02-19 Thread Martin Jansa

> DEPENDS_class-target += "systemd"

You surely meant
DEPENDS_append_class-target = " systemd"
here

On Wed, Feb 19, 2020 at 10:48 PM Mikko Rapeli  wrote:

> Hi,
>
> On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> > Hello,
> >
> > I have a recipe that builds a library. The recipe specifies an
> additional package "${PN}-systemd" along with other systemd related
> variables and finally it instructs that the package should be built with
> "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended
> this recipe to nativesdk because I need this library on it. When trying to
> build the corresponding nativesdk package, the build fails at the
> configuration step (i.e. "do_configure") claiming it cannot find the
> package systemd.
> >
> > Is there a way I can install the -already-generated libraries into my
> SDK (potentially via the corresponding nativesdk recipe) without having to
> rebuild the package? Or do I need to somehow include such systemd package
> in my sdk (which I don't think I need at all)?
> >
> > Any hints and pointers as to were to look at are very well appreciated.
> > Thanks.
>
> Make the systemd dependency for target only, e.g. DEPENDS_class-target +=
> "systemd"
> etc.
>
> There may be relevant use cases to build some of systemd components or
> tools
> to native or nativesdk targets too. In that case add BBCLASSEXTEND +=
> "nativesdk" etc
> in a bbappend to systemd.
>
> Hope this helps,
>
> -Mikko
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48504): https://lists.yoctoproject.org/g/yocto/message/48504
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk&subid=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

2020-02-19 Thread Mikko Rapeli

Hi,

On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> Hello,
> 
> I have a recipe that builds a library. The recipe specifies an additional 
> package "${PN}-systemd" along with other systemd related variables and 
> finally it instructs that the package should be built with 
> "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended 
> this recipe to nativesdk because I need this library on it. When trying to 
> build the corresponding nativesdk package, the build fails at the 
> configuration step (i.e. "do_configure") claiming it cannot find the package 
> systemd.
> 
> Is there a way I can install the -already-generated libraries into my SDK 
> (potentially via the corresponding nativesdk recipe) without having to 
> rebuild the package? Or do I need to somehow include such systemd package in 
> my sdk (which I don't think I need at all)?
> 
> Any hints and pointers as to were to look at are very well appreciated.
> Thanks.

Make the systemd dependency for target only, e.g. DEPENDS_class-target += 
"systemd"
etc.

There may be relevant use cases to build some of systemd components or tools
to native or nativesdk targets too. In that case add BBCLASSEXTEND += 
"nativesdk" etc
in a bbappend to systemd.

Hope this helps,

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48503): https://lists.yoctoproject.org/g/yocto/message/48503
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk&subid=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Opentk Support

2020-02-19 Thread Ross Burton

On Wed, 19 Feb 2020 at 21:45, Sheraz Ali  wrote:
> Does anyone know how to enable opentk in yocto ( i.e is it available )

https://layers.openembedded.org/layerindex/branch/master/recipes/?q=opentk
says that there are not any known recipes, so you'll have to write one
yourself.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48502): https://lists.yoctoproject.org/g/yocto/message/48502
Mute This Topic: https://lists.yoctoproject.org/mt/71406922/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread JH

It also seems mwifiex_sdio tried to write to RO rootfs and failed and
triggled RF Killm, does mwifiex_sdio needs some system directories for
RW?

[   26.636845] mwifiex_sdio mmc0:0001:1: mwifiex_process_cmdresp: cmd 0x242 fain
 Starting Load/Save RF Kill Switch Status...
[   26.852990] mwifiex_sdio mmc0:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14
[   26.861518] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0 (14.68.36
[FAILED] Failed to start Load/Save RF Kill Switch Status.
See 'systemctl status systemd-rfkill.service' for details.
 Starting Load/Save RF Kill Switch Status...
[FAILED] Failed to start Load/Save RF Kill Switch Status.
See 'systemctl status systemd-rfkill.service' for details.
 Starting Load/Save RF Kill Switch Status...
[FAILED] Failed to start Load/Save RF Kill Switch Status.
See 'systemctl status systemd-rfkill.service' for details.
 Starting Load/Save RF Kill Switch Status...

On 2/18/20, JH  wrote:
> Hi,
>
> Apologize for the cross posting.
>
> I am running kernel 4.19.75 on iMX6 customized device with WiFi and 4G
> LTE, it was running well in an RW rootfs. After I have just changed
> rootfs to RO UBIFS partition, it failed RF Kill and postinsts I
> suspect both try write to the RO and failed, any advice how to fix it?
> Despite it failed RF Kill and postinsts, it was still working.
>
> [6.097762] UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2,
> name "rootfs-volume", R/O mode
> ..
> [6.151932] VFS: Mounted root (ubifs filesystem) readonly on device
> 0:13.
> .
> [  OK  ] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
>  Starting Load/Save RF Kill Switch Status...
> [FAILED] Failed to start Load/Save RF Kill Switch Status.
> See 'systemctl status systemd-rfkill.service' for details.
>
> [FAILED] Failed to start Run pending postinsts.
> See 'systemctl status run-postinsts.service' for details.
> ...
> root#
>
> Thank you.
>
> Kind regards,
>
> - jh
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48497): https://lists.yoctoproject.org/g/yocto/message/48497
Mute This Topic: https://lists.yoctoproject.org/mt/71363457/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Status WW07'20

2020-02-19 Thread Stephen Jolley

Current Dev Position: YP 3.1 M3

Next Deadline: YP 3.1 M3 build date 2/24/2020

 

Next Team Meetings:

*   Bug Triage meeting Thursday Feb. 20th  at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Mar. 3rd  at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Feb. 18th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch - Next event is Tuesday Mar. 10th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   The project recently updated its git hosting infrastructure and
there were some issues encountered with the cgit http/https repository
sharing. Those issues should now be resolved, apologies if they caused
issues for anyone. The git:// protocol sharing was unaffected.
*   YP 3.0.2 rc2 is in QA with the report due soon.
*   We continue to see a small number of reproducibility issues with
master which need resolving for green builds (in particular gstreamer and
perl).
*   A significant memory usage issue was identified during bitbake
parsing where memory usage would grow in each parser thread linearly per
number of recipes parsed. This would therefore particularly affect large
numbers of layers, multilibs and multiconfig. The fix has merged into
bitbake along with the corresponding zeus and warrior branches. For one test
case it reduced peak memory usage during parsing for 5 multiconfigs from
20GB to 2GB.
*   Warrior patches for 2.7.3 are out for review.
*   With the git infrastructure issue updated, we now have centos8
workers added to the autobuilder.
*   We are making various queued changes to the autobuilder
configuration to fix bugs, improve efficiency and test coverage but this may
result in some test result instability as we test and resolve issues.
*   We're collecting a list of companies, products and projects which
use the Yocto Project on the wiki:

https://wiki.yoctoproject.org/wiki/Project_Users Please add any you know are
missing (or email Richard/Stephen who can add).
*   The triage team is worried about attendance at triage meetings and
the project is finding it hard to find people to help fix bugs. If anyone is
willing to work on bugs, assistance would be greatly appreciated.

 

YP 3.1 Milestone Dates:

*   YP 3.1 M3 build date 2/24/2020
*   YP 3.1 M3 release date 3/6/2020
*   YP 3.1 M4 build date  3/30/2020
*   YP 3.1 M4 release date  4/24/2020

 

Planned upcoming dot releases:

*   YP 2.7.3 built and in QA
*   YP 2.7.3 release date 2/21/2020
*   YP 3.0.2 build date  2/3/2020
*   YP 3.0.2 release date 2/14/2020

 

Tracking Metrics:

*   WDD 2710 (last week 2728) (

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

*   Total patches found: 1360 (last week 1361)
*   Patches in the Pending State: 546 (40%) [last week 547 (40%)]

 

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

*Cell:(208) 244-4460

* Email:   
sjolley.yp...@gmail.com

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48490): https://lists.yoctoproject.org/g/yocto/message/48490
Mute This Topic: https://lists.yoctoproject.org/mt/71406924/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] do_rootfs task took long time to finish

2020-02-19 Thread Marek Belisko

Hi,

I'm debugging strange issue that do_rootfs task took ~50 minutes. I
enabled buildstats and from that I learned it's quite long. Any ideas
how to debug this issue? My idea was to add timestamp to do_rootfs
tasks but I'm not sure if it's even possible. Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48491): https://lists.yoctoproject.org/g/yocto/message/48491
Mute This Topic: https://lists.yoctoproject.org/mt/71406925/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] oe-core recipe for defining directories in /

2020-02-19 Thread Quentin Schulz

Hi JH,

On Wed, Feb 19, 2020 at 09:12:08PM +1100, JH wrote:
> Hi,
> 
> Which recipe defines all directories in "/"? I need to make a bbapand
> to add directories to /.
> 

None. Or all of them, depends on how one sees it.

You just create a directory in do_install of a recipe.

You then make sure this directory is part of a package by checking it's
in one of the recipe's generated packages's FILES_.

Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48501): https://lists.yoctoproject.org/g/yocto/message/48501
Mute This Topic: https://lists.yoctoproject.org/mt/71406932/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread Mikko Rapeli

On Tue, Feb 18, 2020 at 08:43:01PM +1100, JH wrote:
> Hi Mikko,
> 
> On 2/18/20, mikko.rap...@bmw.de  wrote:
> > I think you may be missing volatile-binds package and service from your
> > image.
> > See poky/meta/recipes-core/volatile-binds/volatile-binds.bb
> 
> I got the source in my build system, it is zeus:
> 
> oe-core/meta/recipes-core/volatile-binds/volatile-binds.bb
> 
> ./all-oe-linux/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/packages-split/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/sysroot-destdir/sysroot-providers/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/pkgdata-pdata-input/runtime/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/pkgdata-pdata-input/runtime-reverse/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/pkgdata-pdata-input/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/pkgdata/runtime/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/pkgdata/runtime-reverse/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/pkgdata/volatile-binds
> ./all-oe-linux/volatile-binds/1.0-r0/license-destdir/volatile-binds
> 
> Are there correct?
> 
> > It may be missing /var/log but with systemd there should not be needs to
> > write
> > to that location after image builds...
> 
> The volatile did not have the log, so /var/log -> volatile/log was an
> invalid link, should I manually create it?
> 
> Thanks Mikko,

Well I have zeus and am using read-only rootfs with volatile binds and
I did not need anything extra. I would dig into this /var/log thing
and patch it away. I use systemd journal so no need for syslogs.

Cheers,

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48499): https://lists.yoctoproject.org/g/yocto/message/48499
Mute This Topic: https://lists.yoctoproject.org/mt/71406918/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [opkg-devel] [opkg-utils PATCH] Makefile: add opkg-feed to UTILS

2020-02-19 Thread Alejandro del Castillo


LGTM, merged!

On 2/17/20 5:57 PM, Alex Stewart wrote:

* Add the opkg-feed script to UTILS so that it is installed with a `make
   install`.

* Clean up the UTILS variable declaration to be a little more diffable.

Signed-off-by: Alex Stewart 
---
  Makefile | 17 ++---
  1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 817a8c1..4049654 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,17 @@
-UTILS = opkg-build opkg-unbuild opkg-make-index opkg.py opkg-list-fields \
-   arfile.py opkg-buildpackage opkg-diff opkg-extract-file opkg-show-deps \
-   opkg-compare-indexes update-alternatives
+UTILS = \
+   arfile.py \
+   opkg-build \
+   opkg-buildpackage \
+   opkg-compare-indexes \
+   opkg-diff \
+   opkg-extract-file \
+   opkg-feed \
+   opkg-list-fields \
+   opkg-make-index \
+   opkg-show-deps \
+   opkg-unbuild \
+   opkg.py \
+   update-alternatives
  
  MANPAGES = opkg-build.1
  



--
Cheers,

Alejandro
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48498): https://lists.yoctoproject.org/g/yocto/message/48498
Mute This Topic: https://lists.yoctoproject.org/mt/71406929/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Debugging gdb built by Yocto

2020-02-19 Thread Patrick Doyle

Does anybody have any tips or tricks for how I might debug the
(cross-canadian) gdb built by Yocto's SDK?

I need to add some printf's to the gdb code to help track down why
something isn't working, but none of my traditional
get-ready-to-debug-this-code techniques are working.

How can I run the gdb that I just built?  Note that I am presuming that I can

$ bitbake gdb-cross-canadian-mipsel -ccompile -f

to rebuild gdb after I add a printf or two to it... but I can't figure
out how to run gdb without going through the sdk installation step.

$ bitbake gdb-cross-canadian-mipsel -cdevshell
# ../build-mipsel-poky-linux/gdb/gdb
bash: ../build-mipsel-poky-linux/gdb/gdb: No such file or directory
# file ../build-mipsel-poky-linux/gdb/gdb
../build-mipsel-poky-linux/gdb/gdb: ELF 64-bit LSB shared object,
x86-64, version 1 (GNU/Linux), dynamically linked, interpreter
/opt/iro, BuildID[sha1]=7f985bbe4cb6c97558b159860b2498f6389b254e, for
GNU/Linux 3.2.0, not stripped
# ldd ../build-mipsel-poky-linux/gdb/gdb
../build-mipsel-poky-linux/gdb/gdb: /lib/x86_64-linux-gnu/libm.so.6:
version `GLIBC_2.29' not found (required by
../build-mipsel-poky-linux/gdb/gdb)
linux-vdso.so.1 =>  (0x7fff8a0c2000)
 ...

# 
LD_LIBRARY_PATH=../recipe-sysroot-native/usr/libexec:../recipe-sysroot-native/usr/lib
../build-mipsel-poky-linux/gdb/gdb
bash: ../build-mipsel-poky-linux/gdb/gdb: No such file or directory

None of the techniques from my bag-of-tricks works.

I guess I could go grab the source myself, manually apply the patches
myself, build it, and see if that works.

Or I could sit down real hard and think about why I am trying to debug
the canadian-cross built tool on my development host... perhaps I
should try debugging the native (cross)-gdb on my native host.  I'll
go try that now, but, in the mean time, I thought it was about time
for me to ask others for some clues.

Any clues or pointers?

--wpd
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48493): https://lists.yoctoproject.org/g/yocto/message/48493
Mute This Topic: https://lists.yoctoproject.org/mt/71406927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] oe-core recipe for defining directories in /

2020-02-19 Thread JH

Hi,

Which recipe defines all directories in "/"? I need to make a bbapand
to add directories to /.

Thank you.

Kind regards,

- jh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48486): https://lists.yoctoproject.org/g/yocto/message/48486
Mute This Topic: https://lists.yoctoproject.org/mt/71406920/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Opentk Support

2020-02-19 Thread Sheraz Ali

Hi,Does anyone know how to enable opentk in yocto ( i.e is it available )Thanks and RegardsSheraz Ali Shah-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48489): https://lists.yoctoproject.org/g/yocto/message/48489
Mute This Topic: https://lists.yoctoproject.org/mt/71406922/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] oe-core recipe for defining directories in /

2020-02-19 Thread Mark Hatle

On 2/19/20 4:29 AM, Quentin Schulz wrote:
> Hi JH,
> 
> On Wed, Feb 19, 2020 at 09:12:08PM +1100, JH wrote:
>> Hi,
>>
>> Which recipe defines all directories in "/"? I need to make a bbapand
>> to add directories to /.
>>
> 
> None. Or all of them, depends on how one sees it.

He is correct, this is shared between all package users.  But with that said,
there is a base filesystem package and an associated 'syncing' file for all
other users.

The is a recipe called 'base-files', it builds up the core filesystem
infrastructure, as well as puts down a few basic files that all filesystems 
need.

The 'syncing' file is a corresponding file to used to coordinate permissions
between all recipes: meta/files/fs-perms.txt.  fs-perms.txt is always consulted
when building any recipe to ensure that all common directory, permissions,
owners and groups get a common configuration.

If you are going to bbappend to base-files then you should also to add to
fs-perms.txt (you can do this, like a bbappend, by adding your own file to your
own layer and updating the variable 'FILESYSTEM_PERMS_TABLES' in one of your
global configuration files (usually your distro configuration file.)

but, this isn't the recommended way...

If the directories you are adding are custom to your product, I would recommend
creating a new package to manage this, as well as a custom
fs-perms.txt/FILESYSTEM_PERMS_TABLE entry to coordinate it between recipes that
use this new custom directory structure.

(If only one recipe uses that directory, then all of the overhead is simply not
needed!  You only need this if multiple recipes are sharing a common directory
structure.)

--Mark

> You just create a directory in do_install of a recipe.
> 
> You then make sure this directory is part of a package by checking it's
> in one of the recipe's generated packages's FILES_.
> 
> Quentin
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48492): https://lists.yoctoproject.org/g/yocto/message/48492
Mute This Topic: https://lists.yoctoproject.org/mt/71406926/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread Mikko Rapeli

(trimming lists to yocto only)

Hi,

I think you may be missing volatile-binds package and service from your image.
See poky/meta/recipes-core/volatile-binds/volatile-binds.bb

It may be missing /var/log but with systemd there should not be needs to write
to that location after image builds...

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48494): https://lists.yoctoproject.org/g/yocto/message/48494
Mute This Topic: https://lists.yoctoproject.org/mt/71406928/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread JH

Hi Mikko,

On 2/18/20, mikko.rap...@bmw.de  wrote:
> I think you may be missing volatile-binds package and service from your
> image.
> See poky/meta/recipes-core/volatile-binds/volatile-binds.bb

I got the source in my build system, it is zeus:

oe-core/meta/recipes-core/volatile-binds/volatile-binds.bb

./all-oe-linux/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/packages-split/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/sysroot-destdir/sysroot-providers/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/pkgdata-pdata-input/runtime/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/pkgdata-pdata-input/runtime-reverse/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/pkgdata-pdata-input/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/pkgdata/runtime/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/pkgdata/runtime-reverse/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/pkgdata/volatile-binds
./all-oe-linux/volatile-binds/1.0-r0/license-destdir/volatile-binds

Are there correct?

> It may be missing /var/log but with systemd there should not be needs to
> write
> to that location after image builds...

The volatile did not have the log, so /var/log -> volatile/log was an
invalid link, should I manually create it?

Thanks Mikko,

- jh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48484): https://lists.yoctoproject.org/g/yocto/message/48484
Mute This Topic: https://lists.yoctoproject.org/mt/71406918/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Zeus failed DHCP

2020-02-19 Thread JH

Hi,

My build connman on Thud works on WiFi, but Zeus does not work, the
connman could not get WiFi DHCP response, it puts a local IP address
169.254.24.188 to my WiFi interface. Has anyone found that the problem
in Zeus or it just me may be miss some packages or configuration?

What are packages could cause DHCP not working?

Here is Thud working log:

# systemctl status connman -l
��● connman.service - Connection service
   Loaded: loaded
(8;;file://solar/lib/systemd/system/connman.service/lib/systemd/system/connman.service8;;;
enabl)
   Active: active (running) since Thu 2020-02-13 03:18:51 UTC; 6 days ago
 Main PID: 131 (connmand)
   CGroup: /system.slice/connman.service
   ��└��─131 /usr/sbin/connmand -n

Feb 18 22:37:16 solar connmand[131]: rp_filter set to 2 (loose mode
routing), old value was 1
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} address
192.168.0.100/24 label mlan0 family 2
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} route 192.168.0.0 gw
0.0.0.0 scope 253 
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} route 192.168.0.1 gw
0.0.0.0 scope 253 
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} route 212.227.81.55
gw 192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {del} route 212.227.81.55
gw 192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: wwan0 {del} route 0.0.0.0 gw
10.114.57.126 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {add} route 0.0.0.0 gw
192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {add} route 212.227.81.55
gw 192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {del} route 212.227.81.55
gw 192.168.0.1 scope 0 

# systemctl status wpa_supplicant -l
��● wpa_supplicant.service - WPA supplicant
   Loaded: loaded
(8;;file://solar/lib/systemd/system/wpa_supplicant.service/lib/systemd/system/wpa_supplicant.service8;;;
disabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-02-13 03:18:53 UTC; 6 days ago
 Main PID: 503 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
   ��└��─503 /usr/sbin/wpa_supplicant -u

Feb 19 07:37:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 07:47:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 07:57:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:07:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:17:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:19:01 solar wpa_supplicant[503]: mlan0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-85 noise=-97 txrate=1000
Feb 19 08:27:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:37:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:47:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:57:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]

Here is Zenu build did not work:

# systemctl status connman -l
* connman.service - Connection service
   Loaded: loaded
(8;;file://solar/lib/systemd/system/connman.service/lib/systemd/system/connman.service8;;;
enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-02-18 00:47:43 UTC; 1 day 9h ago
 Main PID: 184 (connmand)
   CGroup: /system.slice/connman.service
   `-184 /usr/sbin/connmand -n

Feb 19 10:27:33 solar connmand[184]: mlan0 {newlink} index 3 operstate
5 
Feb 19 10:27:33 solar connmand[184]: mlan0 {add} route ff00:: gw ::
scope 0 
Feb 19 10:27:33 solar connmand[184]: mlan0 {add} route fe80:: gw ::
scope 0 
Feb 19 10:27:33 solar connmand[184]: mlan0 {RX} 10 packets 1650 bytes
Feb 19 10:27:33 solar connmand[184]: mlan0 {TX} 256 packets 96668 bytes
Feb 19 10:27:33 solar connmand[184]: mlan0 {update} flags 102467

Feb 19 10:27:33 solar connmand[184]: mlan0 {newlink} index 3 address
D4:CA:6E:9A:7E:29 mtu 1500
Feb 19 10:27:33 solar connmand[184]: mlan0 {newlink} index 3 operstate 6 
Feb 19 10:28:13 solar connmand[184]: mlan0 {add} address
169.254.241.106/16 label mlan0 family 2
Feb 19 10:28:14 solar connmand[184]: mlan0 {add} route 169.254.0.0 gw
0.0.0.0 scope 253 


# systemctl status wpa_supplicant -l
* wpa_supplicant.service - WPA supplicant
   Loaded: loaded
(8;;file://solar/lib/systemd/system/wpa_supplicant.service/lib/systemd/system/wpa_supplicant.service8;;;
disabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-02-18 00:47:48 UTC; 1 day 9h ago
 Main PID: 263 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
   `-263 /usr/sbin/wpa_supplicant -u

Feb 19 09:57:33 solar wpa_supplicant[263]: mlan0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-47 noise=-92 txrat

Re: [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread JH

Hi Belisko,

Thanks for your resonse.

On 2/18/20, Belisko Marek  wrote:
> Can you pls provide output of systemctl status systemd-rfkill
> There should be some more info what issue is.

Failed at step STATE_DIRECTORY spawning /lib/systemd/systemd-rfkill:
Read-only file system, did it try to write something in /lib/systemd?
How should I fix it?

# systemctl status systemd-rfkill -l
* systemd-rfkill.service - Load/Save RF Kill Switch Status
   Loaded: loaded
(8;;file://solar/lib/systemd/system/systemd-rfkill.service/lib/systemd/system/systemd-rfkill.service8;;;
static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2020-02-18 00:47:30
UTC; 1min 59s ago
 Docs: 8;;man:systemd-rfkill.service(8)man:systemd-rfkill.service(8)8;;
  Process: 149 ExecStart=/lib/systemd/systemd-rfkill (code=exited,
status=238/STATE_DIRECTORY)
 Main PID: 149 (code=exited, status=238/STATE_DIRECTORY)

Feb 18 00:47:30 solar systemd[1]: Starting Load/Save RF Kill Switch Status...
Feb 18 00:47:30 solar systemd[149]: systemd-rfkill.service: Failed to
set up special execution directory in /var/lib: Read-only file system
Feb 18 00:47:30 solar systemd[149]: systemd-rfkill.service: Failed at
step STATE_DIRECTORY spawning /lib/systemd/systemd-rfkill: Read-only
file system
Feb 18 00:47:30 solar systemd[1]: systemd-rfkill.service: Main process
exited, code=exited, status=238/STATE_DIRECTORY
Feb 18 00:47:30 solar systemd[1]: systemd-rfkill.service: Failed with
result 'exit-code'.
Feb 18 00:47:30 solar systemd[1]: Failed to start Load/Save RF Kill
Switch Status.
Feb 18 00:47:30 solar systemd[1]: systemd-rfkill.service: Start
request repeated too quickly.
Feb 18 00:47:30 solar systemd[1]: systemd-rfkill.service: Failed with
result 'exit-code'.
Feb 18 00:47:30 solar systemd[1]: Failed to start Load/Save RF Kill
Switch Status.

>> [FAILED] Failed to start Run pending postinsts.
>> See 'systemctl status run-postinsts.service' for details.
> Pls this one also: systemctl status run-postinsts

# systemctl status run-postinsts -l
* run-postinsts.service - Run pending postinsts
   Loaded: loaded
(8;;file://solar/lib/systemd/system/run-postinsts.service/lib/systemd/system/run-postinsts.service8;;;
enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-02-18 00:47:37
UTC; 6min ago
  Process: 153 ExecStart=/usr/sbin/run-postinsts (code=exited, status=0/SUCCESS)
  Process: 159 ExecStartPost=/bin/systemctl --no-reload disable
run-postinsts.service (code=exited, status=1/FAILURE)
 Main PID: 153 (code=exited, status=0/SUCCESS)

Feb 18 00:47:36 solar systemd[1]: Starting Run pending postinsts...
Feb 18 00:47:36 solar run-postinsts[153]: Configuring packages on first boot
Feb 18 00:47:36 solar run-postinsts[153]:  (This may take several
minutes. Please do not power off the machine.)
Feb 18 00:47:36 solar run-postinsts[153]: /usr/sbin/run-postinsts:
eval: line 1: can't create /var/log/postinstall.log: nonexistent
directory
Feb 18 00:47:36 solar run-postinsts[153]:  Removing any system startup
links for run-postinsts ...
Feb 18 00:47:37 solar systemctl[159]: Failed to disable unit: File
/etc/systemd/system/sysinit.target.wants/run-postinsts.service:
Read-only file system
Feb 18 00:47:37 solar systemd[1]: run-postinsts.service: Control
process exited, code=exited, status=1/FAILURE
Feb 18 00:47:37 solar systemd[1]: run-postinsts.service: Failed with
result 'exit-code'.
Feb 18 00:47:37 solar systemd[1]: Failed to start Run pending postinsts.

Was the problem to write to /var/log, the /var/volatile does not have a log?

# ls -l /var
drwxr-xr-x2 1000 1000   160 Feb 18  2020 backups
drwxr-xr-x5 1000 1000   100 Feb 18 00:47 cache
drwxr-xr-x9 1000 1000   180 Feb 18 00:47 lib
drwxr-xr-x3 1000 1000   224 Feb 18  2020 local
lrwxrwxrwx1 1000 100011 Feb 18  2020 lock -> ../run/lock
lrwxrwxrwx1 1000 100012 Feb 18 00:52 log -> volatile/log
lrwxrwxrwx1 1000 1000 6 Feb 18  2020 run -> ../run
drwxr-xr-x3 1000 100060 Feb 18  2020 spool
lrwxrwxrwx1 1000 100012 Feb 18  2020 tmp -> volatile/tmp
drwxrwxrwt8 root root   160 Feb 18 00:47 volatile

# ls -l /var/volatile/
drwxr-xr-x5 1000 1000   100 Feb 18 00:47 cache
drwxr-xr-x9 1000 1000   180 Feb 18 00:47 lib
drwxr-xr-x3 1000 100060 Feb 18  2020 spool

All system mount is the same as the original RW rootfs, did both write
to none standard RW system mount?

Here is defined system mount in fstab:

proc /procproc   defaults  0  0
devpts   /dev/pts devpts mode=0620,gid=5   0  0
tmpfs/run tmpfs
mode=0755,nodev,nosuid,strictatime 0  0
tmpfs/var/volatiletmpfs  defaults  0  0

Here is the mount:

# mount
ubi

Re: [yocto] [OE-core] Yocto Project Status WW07'20

2020-02-19 Thread Alexander Kanavin

On Tue, 18 Feb 2020 at 17:10,  wrote:

>
>- With the git infrastructure issue updated, we now have centos8
>workers added to the autobuilder.
>
> What are the current plans for centos 7?

Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48488): https://lists.yoctoproject.org/g/yocto/message/48488
Mute This Topic: https://lists.yoctoproject.org/mt/71406919/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Yocto Project Status WW07'20

2020-02-19 Thread Richard Purdie

On Tue, 2020-02-18 at 17:44 +0100, Alexander Kanavin wrote:
> On Tue, 18 Feb 2020 at 17:10,  wrote:
> > With the git infrastructure issue updated, we now have centos8
> > workers added to the autobuilder.
> > 
> 
> What are the current plans for centos 7? 

Project members are keen to see support for centos7 retained.

I think we need to sort our buildtools plan, then we have more options
as we can use that on Centos7.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48485): https://lists.yoctoproject.org/g/yocto/message/48485
Mute This Topic: https://lists.yoctoproject.org/mt/71406919/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread JH

Hi Mikko,

On 2/18/20, mikko.rap...@bmw.de  wrote:
> Well I have zeus and am using read-only rootfs with volatile binds and
> I did not need anything extra. I would dig into this /var/log thing
> and patch it away. I use systemd journal so no need for syslogs.

I actually not too worry about the rfkill error but more worried about
why the rfkill failed? Was it caused by some system problem? At the
moment, I could not get WiFi or LTE connected, which used to be
working in RW partition.

Thank you.

Kind regards,

- jh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48487): https://lists.yoctoproject.org/g/yocto/message/48487
Mute This Topic: https://lists.yoctoproject.org/mt/71406918/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto-dev standard/base][PATCH] tipc: fix successful connect() but timed out

2020-02-19 Thread He Zhe

From: Tuong Lien 

In commit 9546a0b7ce00 ("tipc: fix wrong connect() return code"), we
fixed the issue with the 'connect()' that returns zero even though the
connecting has failed by waiting for the connection to be 'ESTABLISHED'
really. However, the approach has one drawback in conjunction with our
'lightweight' connection setup mechanism that the following scenario
can happen:

  (server)(client)

   +- accept()|  | wait_for_conn()
   |  |  |connect() ---+
   |  |<---[SYN]-| > sleeping
   |  |  *CONNECTING   |
   |->*ESTABLISHED   | |
  |[ACK]>*ESTABLISHED  > wakeup()
send()|[DATA]--->|\> wakeup()
send()|[DATA]--->| |   > wakeup()
  .   .  .   . |-> recvq   .
  .   .  .   . |   .
send()|[DATA]--->|/> wakeup()
   close()|[FIN]>*DISCONNECTING|
  *DISCONNECTING | |
  |  ~~> schedule()
   | wait again
   .
   .
   | ETIMEDOUT

Upon the receipt of the server 'ACK', the client becomes 'ESTABLISHED'
and the 'wait_for_conn()' process is woken up but not run. Meanwhile,
the server starts to send a number of data following by a 'close()'
shortly without waiting any response from the client, which then forces
the client socket to be 'DISCONNECTING' immediately. When the wait
process is switched to be running, it continues to wait until the timer
expires because of the unexpected socket state. The client 'connect()'
will finally get ‘-ETIMEDOUT’ and force to release the socket whereas
there remains the messages in its receive queue.

Obviously the issue would not happen if the server had some delay prior
to its 'close()' (or the number of 'DATA' messages is large enough),
but any kind of delay would make the connection setup/shutdown "heavy".
We solve this by simply allowing the 'connect()' returns zero in this
particular case. The socket is already 'DISCONNECTING', so any further
write will get '-EPIPE' but the socket is still able to read the
messages existing in its receive queue.

Note: This solution doesn't break the previous one as it deals with a
different situation that the socket state is 'DISCONNECTING' but has no
error (i.e. sk->sk_err = 0).

Fixes: 9546a0b7ce00 ("tipc: fix wrong connect() return code")
Acked-by: Ying Xue 
Acked-by: Jon Maloy 
Signed-off-by: Tuong Lien 
Signed-off-by: David S. Miller 
Signed-off-by: He Zhe 
---
This patch is from v5.6-rc2.
The wrong one is from v5.5.

 net/tipc/socket.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index f9b4fb9..693e890 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2441,6 +2441,8 @@ static int tipc_wait_for_connect(struct socket *sock, 
long *timeo_p)
return -ETIMEDOUT;
if (signal_pending(current))
return sock_intr_errno(*timeo_p);
+   if (sk->sk_state == TIPC_DISCONNECTING)
+   break;
 
add_wait_queue(sk_sleep(sk), &wait);
done = sk_wait_event(sk, timeo_p, tipc_sk_connected(sk),
-- 
2.7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8388): 
https://lists.yoctoproject.org/g/linux-yocto/message/8388
Mute This Topic: https://lists.yoctoproject.org/mt/71406921/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Change RO rootfs failed RF Kill Switch Status and Failed to start Run pending postinsts

2020-02-19 Thread Marek Belisko

Hi,

On Tue, Feb 18, 2020 at 2:00 AM JH  wrote:
>
> Hi,
>
> Apologize for the cross posting.
>
> I am running kernel 4.19.75 on iMX6 customized device with WiFi and 4G
> LTE, it was running well in an RW rootfs. After I have just changed
> rootfs to RO UBIFS partition, it failed RF Kill and postinsts I
> suspect both try write to the RO and failed, any advice how to fix it?
> Despite it failed RF Kill and postinsts, it was still working.
>
> [6.097762] UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2,
> name "rootfs-volume", R/O mode
> ..
> [6.151932] VFS: Mounted root (ubifs filesystem) readonly on device 0:13.
> .
> [  OK  ] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
>  Starting Load/Save RF Kill Switch Status...
> [FAILED] Failed to start Load/Save RF Kill Switch Status.
> See 'systemctl status systemd-rfkill.service' for details.
Can you pls provide output of systemctl status systemd-rfkill
There should be some more info what issue is.
>
> [FAILED] Failed to start Run pending postinsts.
> See 'systemctl status run-postinsts.service' for details.
Pls this one also: systemctl status run-postinsts
> ...
> root#
>
> Thank you.
>
> Kind regards,
>
> - jh
> 

BR,

marek
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48496): https://lists.yoctoproject.org/g/yocto/message/48496
Mute This Topic: https://lists.yoctoproject.org/mt/71363457/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Modified GENIVI Cannelloni recipe with strange side effects

2020-02-19 Thread Laurent Gauthier

Hi Zoran,

I just saw your reply now.

I think that you might want to remove the INHIBIT_SYSROOT_STRIP and
other INHIBIT_* options from your recipe.

For reference a message from Khem warning that this option should be
used sparingly:

* https://www.yoctoproject.org/pipermail/yocto/2019-March/044415.html

My best guess is that the use of this option is directly linked to
chrpath being needed.

As this recipe is being built with a rather clean looking
CMakeLists.txt none of these weird options are needed.

Kind regards, Laurent.

On Mon, Feb 17, 2020 at 8:01 AM Zoran Stojsavljevic
 wrote:
>
> > The issue I see is that the following files have been build but NOT 
> > installed:
> >
> > * libcannelloni-common.so.0
> > * libcannelloni-common.so.0.0.1
>
> Not quite... The solution is outlined here (in function do_install):
> +   ## ERROR: QA Issue: package cannelloni contains bad RPATH
> +   ## quick fix is in a do_install or do_install_append do
> +   chrpath -d ${D}${bindir}/cannelloni
>
> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb
> https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb_GENIVI
>
> I admit, your first email has shaken my head, so I can see things much
> more clear. :-)
>
> My best guess, this solution is just a workaround (not the final one),
> since I have in ${D} the following:
>
> cannelloni-1.0: package cannelloni contains bad RPATH
> /home/user/projects2/beaglebone-black/bbb-yocto/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build:
> in file 
> /home/user/projects2/beaglebone-black/bbb-yocto/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni/usr/bin/cannelloni
> [rpaths]
>
> So, since my limited knowledge about bitbake build systems ends here,
> somebody from YOCTO primes (potentially Khem Raj, Ross Burton, maybe
> even Richard Purdie) should look more closely into this issue
> (apologies for my unsolicited suggestions).
>
> Laurent,
>
> Once again, thank you for unselfish help,
> Zoran
> ___
>
>
> On Fri, Feb 14, 2020 at 2:20 PM Laurent Gauthier
>  wrote:
> >
> > Hi Zoran,
> >
> > You are almost there! I can feel it... :-)
> >
> > The issue I see is that the following files have been build but 
> > NOTinstalled:
> >
> > * libcannelloni-common.so.0
> > * libcannelloni-common.so.0.0.1
> >
> > If you make sure that they are installed that should fix your issue.
> >
> > Based on the info you provided no RDEPENDS seems to be required as it
> > all appears that everything is in one package named "cannelloni",
> > rather than a package for the main executable and then packages for
> > libraries.
> >
> > Kind regards, Laurent.
> >
> > On Fri, Feb 14, 2020 at 12:43 PM Zoran Stojsavljevic
> >  wrote:
> > >
> > > Hello Laurent,
> > >
> > > Many thanks to you for the help. :-)
> > >
> > > I did some modifications, and now I have all the elements in there/in 
> > > place:
> > >
> > > [user@fedora31-ssd cannelloni]$ cd ../../../build/tmp
> > > [user@fedora31-ssd tmp]$ find . -name libcannelloni*
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/image/usr/lib/libcannelloni-common.so
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/sysroot-destdir/usr/lib/libcannelloni-common.so
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/package/usr/lib/.debug/libcannelloni-common.so
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/package/usr/lib/libcannelloni-common.so
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni/usr/lib/libcannelloni-common.so
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni-dbg/usr/lib/.debug/libcannelloni-common.so
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build/libcannelloni-common.so.0
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build/libcannelloni-common.so.0.0.1
> > > ./work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/build/libcannelloni-common.so
> > > ./sysroots-components/cortexa8hf-neon/cannelloni/usr/lib/libcannelloni-common.so
> > >
> > > I miss the very end of your thoughts. Namely:
> > >
> > > > The name of the package containing the shared library is name of the
> > > > xxx first-level directory "packages-split/xxx".
> > >
> > > So, how should I write the RDEPENDS command?
> > >
> > > Something as: RDEPENDS_${PN} = "???"
> > >
> > > What should I put on the right side of the equation (according to the 
> > > above traces)?
> > >
> > > Thank you,
> > > Zoran
> > > ___
> > >
> > > On Fri, Feb 14, 2020 at 11:49 AM Laurent Gauthier 
> > >  wrote:
> > >>
> > >> Hi Zoran,
> > >>
> > >> The issue seems to be that the executable /usr/bin/cannelloni has a
> > >> reference to a shared library (libcannelloni-common.so.0) for which
> > >> the Yocto build system is not able to determine automati

Re: [RAUC] Private: Re: [yocto] #yocto update the kernel with a rauc bundle

2020-02-19 Thread Enrico J?rns

Hi Hans,

Am 18.02.20 um 15:06 schrieb Hans-Ulrich Schlieben:
> Hi Enrico,
> 
> I just answered your first mail on the website and thought that will 
> automatically reply to all. Added all lists now, hope these are correct.

ah, I wasn't even aware that there is a website for this ;)

> Thanks to you I found the custom automount in the providers recipes. This 
> mounts /dev/mmc0.0 to /mnt/mmc.

Ok, good that we clarified this. The script should not be required in a
modern barebox as it has a lot of built-in automounting magic on board.

> After the mount it seems that only when I install a new image the barebox 
> mount /dev/mmc0.0 to /mnt/mmc0.0 works. 

This is the point that sounds a little strange, yes.

> Rauc / barebox seems something to change after a bundle update whereas mount 
> /dev/mmc0.0 to /mnt/mmc0.0 fails and the files are only visible in /mnt/mmc.
> 
> /mnt/mmc works in both cases so I have now 
> /mnt/mmc/boot... for system0 and
> /mnt/mmc0.1/boot... for system1

Would be great to see a log of such a failed mount to get a more
concrete idea what 'failed' actually means.

Best regards, Enrico

> -Original Message-
> From: Enrico Jörns  
> Sent: Tuesday, 18 February 2020 01:12
> To: Hans-Ulrich Schlieben 
> Subject: Re: Private: Re: [yocto] #yocto update the kernel with a rauc bundle
> 
> Hi hu,
> 
> please keep at least any list in CC so that others can benefit from this 
> discussion, too (Both RAUC and barebox ML would fit here). It also increases 
> the range and thus potential people that may help here.
> 
> Am 17.02.20 um 13:58 schrieb Hans-Ulrich Schlieben:
>> Hi Enrico,
>>
>> thank you very much for your help with IMAGE_INSTALL_append = " 
>> kernel-image kernel-devicetree"
>> that did the trick.
>>
>> What i do not understand is how barebox handles the mount names for my 
>> two alternate boot partitions.
>> The boot on the first partition works only under /mnt/mmc/:
>>
>> global.bootm.image="/mnt/mmc/boot/zImage"
>> global.bootm.oftree="/mnt/mmc/boot/imx6q-phytec-ksp0663.dtb"
>> global.linux.bootargs.dyn.root="root=/dev/mmcblk0p1
>> rootflags='data=journal' wd=60 ipv6.disable=1"
>>
>> whereas the second works with /mnt/mmc1/:
>> global.bootm.image="/mnt/mmc0.1/boot/zImage"
>> global.bootm.oftree="/mnt/mmc0.1/boot/imx6q-phytec-ksp0663.dtb"
>> global.linux.bootargs.dyn.root="root=/dev/mmcblk0p2
>> rootflags='data=journal' wd=60 ipv6.disable=1"
>>
>> In barebox i see both root filesystems under /mnt/mmc0.0 and 
>> /mnt/mmc0.1/.
>>
>> When i try to have a symmetrical configuration and rename /mmc/ into 
>> /mmc0.0/ boot on mmc0.0 does not work because it still mounts the 
>> first partition ar /mnt/mmc/.
> 
> Which version of barebox?
> 
> It should be sufficient to either say
> 
>   boot mmc0.0
> 
> or
> 
>   boot mmc0.1
> 
> and barebox will automatically mount the partition, look for a bootspec file 
> under /loader/entries and assemble the required boot options and kernel 
> command line automatically.
> 
>> What tells barebox to mount during boot mmc and mmc0.1 instead of 
>> mmc0.0 and mmc0.1?
> 
> Is there any custom automount unit located in you built-in env probably?
> 
> 
> Best regards, Enrico
> 


-- 
Pengutronix e.K.   | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48482): https://lists.yoctoproject.org/g/yocto/message/48482
Mute This Topic: https://lists.yoctoproject.org/mt/71399776/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw][PATCH] gcc/binutils: Allow plugins to be enabled on cross-canadian toolchain

2020-02-19 Thread Mark Hatle

As of GCC 8, plugin support is available with mingw.  If the plugins are
enabled in the regular binutils/gcc configurations, carry over that
configuration with the mingw versions as well.

When plugins are enabled, they produce a file called [plugin].dll.a.  This
causes the debugsrc processor to find the file and attempt to pull out dwarf
information.  However, we need to prevent this as the files are not ELF, but
in Microsoft PE format, and trigger an error if processed.

Signed-off-by: Mark Hatle 
---
 .../binutils/binutils-cross-canadian_2.%.bbappend  | 2 +-
 recipes-devtools/gcc/gcc-cross-canadian_%.bbappend | 7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend 
b/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
index 026c932..5845fe0 100644
--- a/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
+++ b/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
@@ -1,4 +1,4 @@
-EXTRA_OECONF_append_sdkmingw32 = " --disable-plugins --disable-nls"
+EXTRA_OECONF_append_sdkmingw32 = " --disable-nls"
 LDFLAGS_append_sdkmingw32 = " -Wl,-static"
 
 DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
diff --git a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend 
b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
index 888d610..9c0d828 100644
--- a/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
+++ b/recipes-devtools/gcc/gcc-cross-canadian_%.bbappend
@@ -1,6 +1,11 @@
 INSANE_SKIP_${PN}_append_sdkmingw32 = " staticdev"
-EXTRA_OECONF_append_sdkmingw32 = " --disable-nls --disable-lto"
+EXTRA_OECONF_append_sdkmingw32 = " --disable-nls"
 LDFLAGS_append_sdkmingw32 = " -Wl,-static"
 EXEEXT_sdkmingw32 = ".exe"
 ELFUTILS_sdkmingw32 = ""
 DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
+
+# With plugins enabled, it will output 'dll.a' files that are mistaken
+# for ELF which can trigger a failure.  Simply avoid processing these
+# to avoid the error condition.
+INHIBIT_PACKAGE_DEBUG_SPLIT = '1'
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48481): https://lists.yoctoproject.org/g/yocto/message/48481
Mute This Topic: https://lists.yoctoproject.org/mt/71397751/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] package QA & missing runtime dependency alerting (thud)

2020-02-19 Thread Peter Morrow via Lists.Yoctoproject.Org

On Wed, 2020-02-19 at 14:59 +0100, Maciej Pijanowski via
Lists.Yoctoproject.Org wrote:
> 
> 
> On 19.02.2020 13:50, Peter Morrow via Lists.Yoctoproject.Org wrote:
> 
> > Hello,
> > 
> > We occasionally see our build fail due to package QA issues,
> > specifically:
> > 
> > ERROR: gawk-4.2.1-r0 do_package_qa: QA Issue:
> > /usr/lib/gawk/ptest/test/fcall_exit.awk contained in package gawk-
> > ptest 
> > requires /bin/awk, but no providers found in RDEPENDS_gawk-ptest?
> > [file-rdeps], 
> > 
> > I'm wondering how yocto has made the decision that "/bin/awk" is a
> > runtime dependency for gawk-ptest (it is, so this is good).  Does
> > yocto read /usr/lib/gawk/ptest/test/fcall_exit.awk looking for
> > anything
> > that matches on a shbang then alert us to this as a missing
> > RDEPENDS?
>  Yes, it does look at the sheabangs of the scripts. Please refer to
> the manual
> and the insane.bbclass imeplementation
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-insane

Thanks Maciej,

I'm wondering also about the specific failure I'm seeing here, i.e.
gawk-ptest RDEPENDS on /bin/awk.  Looking at the recipe for gawk in
thud I see:

inherit autotools gettext texinfo update-alternatives

FILES_${PN} += "${datadir}/awk"
FILES_${PN}-dev += "${libdir}/${BPN}/*.la"

ALTERNATIVE_${PN} = "awk"
ALTERNATIVE_TARGET[awk] = "${bindir}/gawk"
ALTERNATIVE_PRIORITY = "100"

do_install_append() {
# remove the link since we don't package it
rm ${D}${bindir}/awk
}

So awk is an alternative for gawk.  In the version of yocto I'm using
(thud) the ptest.bbclass does not add a dependency on the package that
is being tested (this appears fixed in more recent versions of yocto).
Thus I added the dependency on gawk from gawk-ptest in a bbappend file
for gawk (to fix other package QA issues):

RDEPENDS_${PN}-ptest += " gawk"

So the question then becomes are alternatives also honoured in the
file-rdeps check of the insane bbclass?  I.e. if a file-rdeps check
finds /bin/awk in a file, since "awk" is not explicitly in the RDEPENDS
list (but gawk is) is this flagged as a false positive?

I'd prefer not to add INSANE_SKIP_${PN} = "file-rdeps" for gawk if
possible.

Thanks,
Peter.

> > I think this is what is happening but cannot see this in the
> > documentation error.  Something to back this hunch up:
> > 
> > http://lists.openembedded.org/pipermail/openembedded-core/2016-November/128419.html
> > 
> > 
> > I'm about to send patches upstream to gawk to remove some more
> > shbangs
> > from awk scripts and thus would like to check the yocto behaviour
> > before I do so.
> > 
> > Thanks,
> > Peter.
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> Maciej Pijanowski
> Embedded Systems Engineer
> GPG: 9963C36AAC3B2B46
> https://3mdeb.com
>  | @3mdeb_com
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48480): https://lists.yoctoproject.org/g/yocto/message/48480
Mute This Topic: https://lists.yoctoproject.org/mt/71395004/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] package QA & missing runtime dependency alerting (thud)

2020-02-19 Thread Maciej Pijanowski



On 19.02.2020 13:50, Peter Morrow via Lists.Yoctoproject.Org wrote:

Hello,

We occasionally see our build fail due to package QA issues,
specifically:

ERROR: gawk-4.2.1-r0 do_package_qa: QA Issue:
/usr/lib/gawk/ptest/test/fcall_exit.awk contained in package gawk-ptest
requires /bin/awk, but no providers found in RDEPENDS_gawk-ptest?
[file-rdeps],

I'm wondering how yocto has made the decision that "/bin/awk" is a
runtime dependency for gawk-ptest (it is, so this is good).  Does
yocto read /usr/lib/gawk/ptest/test/fcall_exit.awk looking for anything
that matches on a shbang then alert us to this as a missing RDEPENDS?
Yes, it does look at the sheabangs of the scripts. Please refer to the 
manual

and the insane.bbclass imeplementation
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-insane


I think this is what is happening but cannot see this in the
documentation error.  Something to back this hunch up:

http://lists.openembedded.org/pipermail/openembedded-core/2016-November/128419.html

I'm about to send patches upstream to gawk to remove some more shbangs
from awk scripts and thus would like to check the yocto behaviour
before I do so.

Thanks,
Peter.







--
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48479): https://lists.yoctoproject.org/g/yocto/message/48479
Mute This Topic: https://lists.yoctoproject.org/mt/71395004/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] package QA & missing runtime dependency alerting (thud)

2020-02-19 Thread Peter Morrow via Lists.Yoctoproject.Org

Hello,

We occasionally see our build fail due to package QA issues,
specifically:

ERROR: gawk-4.2.1-r0 do_package_qa: QA Issue:
/usr/lib/gawk/ptest/test/fcall_exit.awk contained in package gawk-ptest 
requires /bin/awk, but no providers found in RDEPENDS_gawk-ptest?
[file-rdeps], 

I'm wondering how yocto has made the decision that "/bin/awk" is a
runtime dependency for gawk-ptest (it is, so this is good).  Does
yocto read /usr/lib/gawk/ptest/test/fcall_exit.awk looking for anything
that matches on a shbang then alert us to this as a missing RDEPENDS?

I think this is what is happening but cannot see this in the
documentation error.  Something to back this hunch up:

http://lists.openembedded.org/pipermail/openembedded-core/2016-November/128419.html

I'm about to send patches upstream to gawk to remove some more shbangs
from awk scripts and thus would like to check the yocto behaviour
before I do so.

Thanks,
Peter.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48478): https://lists.yoctoproject.org/g/yocto/message/48478
Mute This Topic: https://lists.yoctoproject.org/mt/71395004/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd

2020-02-19 Thread Armando Hernandez

Hello,

I have a recipe that builds a library. The recipe specifies an additional 
package "${PN}-systemd" along with other systemd related variables and finally 
it instructs that the package should be built with "-DWITH_SYSTEMD=ON" being 
passed to cmake. So far so good. But, I extended this recipe to nativesdk 
because I need this library on it. When trying to build the corresponding 
nativesdk package, the build fails at the configuration step (i.e. 
"do_configure") claiming it cannot find the package systemd.

Is there a way I can install the -already-generated libraries into my SDK 
(potentially via the corresponding nativesdk recipe) without having to rebuild 
the package? Or do I need to somehow include such systemd package in my sdk 
(which I don't think I need at all)?

Any hints and pointers as to were to look at are very well appreciated.
Thanks.

Armando Hernandez
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48477): https://lists.yoctoproject.org/g/yocto/message/48477
Mute This Topic: https://lists.yoctoproject.org/mt/71392510/21656
Mute #sdk: https://lists.yoctoproject.org/mk?hashtag=sdk&subid=6691583
Mute #systemd: https://lists.yoctoproject.org/mk?hashtag=systemd&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Incrementally building constantly changing application source in a workflow-friendly way with #yocto

2020-02-19 Thread Pieter Smith

Hi Alexander,

Based on your and Oliver Westermann's help, I came up with something that works 
for our project requirements:

My application bitbake file looks like this:

EXTERNALSRC = 
"${@os.path.abspath(os.path.join(os.path.dirname(d.getVar('FILE')), '..', '..', 
'src'))}"
inherit externalsrc

S = "${EXTERNALSRC}"
inherit cmake

externalsrc.bb expects EXTERNALSRC to contain an absolute path. We have a 
relocatable workspace based on a git tree with submodules, so I calculate the 
absolute path of the source based on the bb file location. Our src directory is 
a cmake project, so I only have to convince cmake to use the EXTERNALSRC 
location for an out-of-tree build in WORKDIR by setting S.

The workflow for our project developers then becomes:

bitbake -c cleansstate  && bitbake ...

I can hide this in a wrapper Makefile.

Am I missing anything?

Regards,
Pieter Smith
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48476): https://lists.yoctoproject.org/g/yocto/message/48476
Mute This Topic: https://lists.yoctoproject.org/mt/71245615/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-selinux][PATCH] audit: add clock_settime64 syscall

2020-02-19 Thread Yu, Mingli

From: Mingli Yu 

On 32bit system,
After upgrade glibc to 2.31
 # strace -o /tmp/test.log date -s 09:16:45
 # tail -f /tmp/test.log
 close(3)= 0
 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=114, ...}) = 0
 clock_settime64(CLOCK_REALTIME, {tv_sec=1582103805, tv_nsec=0}) = 0
 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x4, 0x40), ...}) = 0
 ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
 write(1, "Wed Feb 19 09:16:45 UTC 2020\n", 29) = 29
 close(1)= 0
 close(2)= 0
 exit_group(0)   = ?
 +++ exited with 0 +++

It means the clock_settime64 syscall is used, so
add the syscall.

Signed-off-by: Mingli Yu 
---
 .../0001-lib-i386_table.h-add-new-syscall.patch| 42 ++
 recipes-security/audit/audit_2.8.5.bb  |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
recipes-security/audit/audit/0001-lib-i386_table.h-add-new-syscall.patch

diff --git 
a/recipes-security/audit/audit/0001-lib-i386_table.h-add-new-syscall.patch 
b/recipes-security/audit/audit/0001-lib-i386_table.h-add-new-syscall.patch
new file mode 100644
index 000..6e1827c
--- /dev/null
+++ b/recipes-security/audit/audit/0001-lib-i386_table.h-add-new-syscall.patch
@@ -0,0 +1,42 @@
+From df878b92e01f4d1c3de7f7d8229cea6a431509eb Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Wed, 19 Feb 2020 15:23:40 +0800
+Subject: [PATCH] lib/i386_table.h: add new syscall
+
+On 32bit system,
+After upgrade glibc to 2.31
+ # strace -o /tmp/test.log date -s 09:16:45
+ # tail -f /tmp/test.log
+ close(3)= 0
+ stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=114, ...}) = 0
+ clock_settime64(CLOCK_REALTIME, {tv_sec=1582103805, tv_nsec=0}) = 0
+ fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x4, 0x40), ...}) = 0
+ ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
+ write(1, "Wed Feb 19 09:16:45 UTC 2020\n", 29) = 29
+ close(1)= 0
+ close(2)= 0
+ exit_group(0)   = ?
+ +++ exited with 0 +++
+
+It means the clock_settime64 syscall is used, so
+add the syscall.
+
+Upstream-Status: Submitted 
[https://github.com/linux-audit/audit-userspace/pull/116]
+
+Signed-off-by: Mingli Yu 
+---
+ lib/i386_table.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/i386_table.h b/lib/i386_table.h
+index 1a64c88..65fd4d9 100644
+--- a/lib/i386_table.h
 b/lib/i386_table.h
+@@ -405,3 +405,4 @@ _S(383, "statx")
+ _S(384, "arch_prctl")
+ _S(385, "io_pgetevents")
+ _S(386, "rseq")
++_S(404, "clock_settime64")
+-- 
+2.7.4
+
diff --git a/recipes-security/audit/audit_2.8.5.bb 
b/recipes-security/audit/audit_2.8.5.bb
index ee3b3b5..af36ed5 100644
--- a/recipes-security/audit/audit_2.8.5.bb
+++ b/recipes-security/audit/audit_2.8.5.bb
@@ -10,6 +10,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 SRC_URI = 
"git://github.com/linux-audit/${BPN}-userspace.git;branch=2.8_maintenance \
file://Add-substitue-functions-for-strndupa-rawmemchr.patch \
file://Fixed-swig-host-contamination-issue.patch \
+   file://0001-lib-i386_table.h-add-new-syscall.patch \
file://auditd \
file://auditd.service \
file://audit-volatile.conf \
-- 
2.7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48475): https://lists.yoctoproject.org/g/yocto/message/48475
Mute This Topic: https://lists.yoctoproject.org/mt/71391497/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

48 matches

Mail list logo