Re: [yocto] inheriting native.bbclass explicitly

[Andre McCurdy]

On Thu, Sep 13, 2018 at 6:05 AM, Dudziak Krzysztof
 wrote:
> Current release's reference manual issues in native.bbclass chapter a warning:
> "When creating a recipe, you must follow this naming convention:  
> native-myrecipe.bb
> Not doing so can lead to subtle problems because code exists that depends on 
> the naming convention."

Looks like a mistake in the documentation. Native only recipes (ie
recipes which use "inherit native" rather than BBCLASSEXTEND) should
have "-native" as a suffix, not "native-" as a prefix.

> Jethro release manual does not point it out.
> Is this warning really out of relevance for certain past releases e.g. Jethro?
>
> Abstracting from question raised above how following two fit all together:
> "When creating a recipe, you must follow this naming convention:  
> native-myrecipe.bb"
> and
> " The advantage of the second method is that you do not need to have two 
> separate recipes " (2.5.1 Release Reference Manual)

If you use BBCLASSEXTEND (ie "the second method") then that recipe
naming rule doesn't apply. ie a recipe using BBCLASSEXTEND should not
have a "-native" suffix.

> krzysiek
>
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Thursday, 13. September 2018 14:00
> To: Dudziak Krzysztof 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] inheriting native.bbclass explicitly
>
> On 13 September 2018 at 12:39, Dudziak Krzysztof
>  wrote:
>> Thanks for hints.
>> I don't want to have this package on target system.
>> You sound like inheriting explicitly had some major drawback of wide scope.
>
> It won't be included in the image unless you add it to the image.
>
> Ross
> 
>  This message and any attachments are intended solely for the addressees and 
> may contain confidential information. Any unauthorized use or disclosure, 
> either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for 
> the message if altered, changed or falsified. If you are not the intended 
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free 
> from viruses, the sender will not be liable for damages caused by a 
> transmitted virus.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Whitelist gdbserver

[Andre McCurdy]

On Thu, Sep 13, 2018 at 8:42 AM, Jeremy Overesch
 wrote:
> HI all,
>
> I’m attempting to whitelist gdbserver just for SDK purposes, while keeping
> all other GPLv3 code as incompatible (therefore unbuilt).  However,
> everything I’ve tried still results in gdbserver being removed from my SDK
> and therefore failing to build.
>
> In my local.conf, I have the following line:
>
> INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 AGPLv3"
>
> Through the yocto documentation
> (https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#license-flag-matching),
> it appears that adding the following *should* work, yet it doesn’t:

I think you are mixing up "LICENSE" and "LICENSE_FLAGS". The two don't
really work together. It's partly explained in:

  
https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-LICENSE_FLAGS

See the LICENSE_FLAGS comment which says "This value is independent of
LICENSE and is typically used to mark recipes that might require
additional licenses in order to be used in a commercial product. For
more information, see the "Enabling Commercially Licensed Recipes"
section."

To whitelist a recipe which is being excluded due to
INCOMPATIBLE_LICENSE, use WHITELIST_GPL-3.0. For example for
gdbserver, try the following:

  WHITELIST_GPL-3.0 += "gdbserver"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Dudziak Krzysztof]

Current release's reference manual issues in native.bbclass chapter a warning:
"When creating a recipe, you must follow this naming convention:  
native-myrecipe.bb
Not doing so can lead to subtle problems because code exists that depends on 
the naming convention."

Jethro release manual does not point it out.
Is this warning really out of relevance for certain past releases e.g. Jethro?

Abstracting from question raised above how following two fit all together:
"When creating a recipe, you must follow this naming convention:  
native-myrecipe.bb"
and
" The advantage of the second method is that you do not need to have two 
separate recipes " (2.5.1 Release Reference Manual)

krzysiek

-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, 13. September 2018 14:00
To: Dudziak Krzysztof 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] inheriting native.bbclass explicitly

On 13 September 2018 at 12:39, Dudziak Krzysztof
 wrote:
> Thanks for hints.
> I don't want to have this package on target system.
> You sound like inheriting explicitly had some major drawback of wide scope.

It won't be included in the image unless you add it to the image.

Ross

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Dudziak Krzysztof]

Thanks for hints.
I don't want to have this package on target system.
You sound like inheriting explicitly had some major drawback of wide scope.

I am familiarized with bitbake -e 
I know it as a way to print package/image tasks variables.
But how its output shows the list of classes inherited and the order they are 
inherited by Bitbake target?
Is any variable indicating this included in its output?

krzysiek

-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, 13. September 2018 13:23
To: Dudziak Krzysztof ; Yocto-mailing-list 

Subject: Re: [yocto] inheriting native.bbclass explicitly

CCing the list again.  Please remember to reply to the list.

On 13 September 2018 at 11:42, Dudziak Krzysztof 
 wrote:
> Is it possible for one Bitbake target to check list and order of classes 
> inherited?

bitbake -e [recipe] will show you what was parsed.

In this situation I wouldn't worry too much.  It's best to use BBCLASSEXTEND 
instead of inherit native directly anyway.

Ross

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake error

[Dimitris Tassopoulos]

Sometimes, I also got some weird errors like that when copying and pasting
projects (or meta layers) from one machine to other. That's because the
flags and some file stats are not copied.

On Thu, 13 Sep 2018, 18:57 Alexander Kanavin, 
wrote:

> It seems as though the build system is unable to create this directory:
>
>
> /home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8
>
> You probably have a permission problem there, working from /home/b but
> attempting to create /home/yocto.
>
> Alex
>
> 2018-09-13 15:15 GMT+02:00 idealsim :
> > Hi, i'm trying to build an image with Yocto on a new machine (ubuntu
> 16.04
> > LTS)but i have this error that i can't resolve. Can you help ?
> >
> > ERROR: Execution of event handler 'uninative_event_fetchloader' failed
> > Traceback (most recent call last):
> >   File
> "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> > line 55, in uninative_event_fetchloader(e= at
> > 0x7f2015027790>):
> >  if not os.path.exists(tarballpath):
> > >bb.utils.mkdirhier(tarballdir)
> >  if d.getVar("UNINATIVE_URL", True) == "unset":
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> > 716, in
> >
> mkdirhier(directory='/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8'):
> >  if e.errno != errno.EEXIST:
> > >raise e
> >
> > OSError: [Errno 13] Permission denied:
> '/home/b/yocto-krogoth/../../yocto'
> >
> > ERROR: Command execution failed: Traceback (most recent call last):
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py",
> line
> > 104, in runAsyncCommand
> > commandmethod(self.cmds_async, self, options)
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py",
> line
> > 325, in buildTargets
> > command.cooker.buildTargets(pkgs_to_build, task)
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/cooker.py",
> line
> > 1423, in buildTargets
> > bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data)
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> > 178, in fire
> > fire_class_handlers(event, d)
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> > 110, in fire_class_handlers
> > execute_handler(name, handler, event, d)
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> > 82, in execute_handler
> > ret = handler(event)
> >   File
> "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> > line 55, in uninative_event_fetchloader
> > bb.utils.mkdirhier(tarballdir)
> >   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> > 716, in mkdirhier
> > raise e
> > OSError: [Errno 13] Permission denied:
> '/home/b/yocto-krogoth/../../yocto'
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Dudziak Krzysztof]

Got it and will follow your recommendation. Thanks.

-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, 13. September 2018 14:00
To: Dudziak Krzysztof 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] inheriting native.bbclass explicitly

On 13 September 2018 at 12:39, Dudziak Krzysztof
 wrote:
> Thanks for hints.
> I don't want to have this package on target system.
> You sound like inheriting explicitly had some major drawback of wide scope.

It won't be included in the image unless you add it to the image.

Ross

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake error

[Alexander Kanavin]

It seems as though the build system is unable to create this directory:

/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8

You probably have a permission problem there, working from /home/b but
attempting to create /home/yocto.

Alex

2018-09-13 15:15 GMT+02:00 idealsim :
> Hi, i'm trying to build an image with Yocto on a new machine (ubuntu 16.04
> LTS)but i have this error that i can't resolve. Can you help ?
>
> ERROR: Execution of event handler 'uninative_event_fetchloader' failed
> Traceback (most recent call last):
>   File "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> line 55, in uninative_event_fetchloader(e= 0x7f2015027790>):
>  if not os.path.exists(tarballpath):
> >bb.utils.mkdirhier(tarballdir)
>  if d.getVar("UNINATIVE_URL", True) == "unset":
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> 716, in
> mkdirhier(directory='/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8'):
>  if e.errno != errno.EEXIST:
> >raise e
>
> OSError: [Errno 13] Permission denied: '/home/b/yocto-krogoth/../../yocto'
>
> ERROR: Command execution failed: Traceback (most recent call last):
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py", line
> 104, in runAsyncCommand
> commandmethod(self.cmds_async, self, options)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py", line
> 325, in buildTargets
> command.cooker.buildTargets(pkgs_to_build, task)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/cooker.py", line
> 1423, in buildTargets
> bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> 178, in fire
> fire_class_handlers(event, d)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> 110, in fire_class_handlers
> execute_handler(name, handler, event, d)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> 82, in execute_handler
> ret = handler(event)
>   File "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> line 55, in uninative_event_fetchloader
> bb.utils.mkdirhier(tarballdir)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> 716, in mkdirhier
> raise e
> OSError: [Errno 13] Permission denied: '/home/b/yocto-krogoth/../../yocto'
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Notes: Yocto Project Weekly Triage Meeting

[Randy MacLeod]

On 09/13/2018 11:17 AM, Jolley, Stephen K wrote:

Attendees: Stephen, Armin, Joshua, Amanda, Richard, Ross, Randy, Anuj,
Wiki: _https://wiki.yoctoproject.org/wiki/Bug_Triage_
AR: Ross - Update _12921_ 
 to NEEDINFO 
and add comment.
AR: Armin – Create selftest bug for _12921_ 
.

Discussed that we should expect M3 sometime next week.
AR: Amanda – Check _12332_ 
 to see if it 
can be closed.
AR: Randy – Check _12774_ 
 to see if it 
can be closed.
AR: Stephen – Check with David if _12785_ 
 and _12891_ 
 will be 
closed in M3.

Thanks,
*/Stephen K. Jolley/*
*Yocto Project Program Manager*
*INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 *
(*Cell*: (208) 244-4460
* *Email*: _stephen.k.jolley@intel.com_



This missed my email filters since I wasn't on the TO/CC list.
I added people with an AR to the To: list since they may be
in the same flooding even with filters email boat.



Stephen,
Can you please explicitly address anyone who has an AR next time?


Thanks,
--
# Randy MacLeod
# Wind River Linux

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

[yocto] Whitelist gdbserver

[Jeremy Overesch]

HI all,

I'm attempting to whitelist gdbserver just for SDK purposes, while keeping all 
other GPLv3 code as incompatible (therefore unbuilt).  However, everything I've 
tried still results in gdbserver being removed from my SDK and therefore 
failing to build.

In my local.conf, I have the following line:

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 AGPLv3"

Through the yocto documentation 
(https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#license-flag-matching),
 it appears that adding the following *should* work, yet it doesn't:

LICENSE_FLAGS_WHITELIST = "GPLv3_gdbserver"

I've also tried the following lines individually:
LICENSE_FLAGS_WHITELIST = "GPLv3_gdbserver LGPLv3_gdbserver"
INCOMPATIBLE_LICENSE_gdbserver = ""

But none of these seem to work.

When I build, I get the following:
 snip 
vagrant@buildPC:~/newroot/build$ bitbake -c populate_sdk thing4-fullImage
WARNING: Host distribution "Ubuntu-16.04" has not been validated with this 
version of the build system; you may possibly experience unexpected failures. 
It is recommended that you use a tested distribution.
NOTE: 
/home/vagrant/newroot/sources/poky/meta/recipes-extended/libidn/libidn_0.6.14.bb:
 INCLUDING libidn as buildable despite INCOMPATIBLE_LICENSE because it has been 
whitelisted
NOTE: 
/home/vagrant/newroot/sources/poky/meta/recipes-extended/libidn/libidn_1.32.bb: 
INCLUDING libidn as buildable despite INCOMPATIBLE_LICENSE because it has been 
whitelisted
Parsing recipes: 100% 
||
 Time: 00:00:12
Parsing of 2143 .bb files complete (0 cached, 2143 parsed). 2714 targets, 582 
skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'gdbserver' (but 
/home/vagrant/newroot/sources/poky/../meta-qt5/recipes-qt/packagegroups/packagegroup-qt5-qtcreator-debug.bb
 RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'gdbserver' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['gdbserver']
NOTE: Runtime target 'packagegroup-qt5-qtcreator-debug' is unbuildable, 
removing...
Missing or unbuildable dependency chain was: 
['packagegroup-qt5-qtcreator-debug', 'gdbserver']
ERROR: Required build target 'thing4-fullImage' has no buildable providers.
Missing or unbuildable dependency chain was: ['thing4-fullImage', 
'packagegroup-qt5-qtcreator-debug', 'gdbserver']

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
 snip 

Is there a way to figure out what magic line I need?

Thanks in advance for any help you can give.

-Jeremy



This message (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. If you are not the intended recipient of this message, you 
are hereby notified that you must delete the message without disseminating, 
copying or taking any action in reliance upon it. If you have received this 
message in error, please notify the sender via return e-mail. Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Building, Using SDK

[Dudziak Krzysztof]

Hi,

Alex González elaborates in his book Embedded Linux Development Using Yocto 
Projets (2nd Edition)
SDK-related questions - basics, building, usage (chapter 4).

1.
Downloading then installing precompiled SDK was one of all available options 
according to Alex.
He elaborates how to find it on server in Internet, how to select needed one 
and install it.
I wonder how to integrate downloaded and installed precompiled SDK
to Poky release used on build system?

2.
Preparing / building SDK by oneself was further option with image target's 
'populate_sdk' Bitbake task
as the recommended way (according to Alex in chapter's certain section).
One would need only to start populate_sdk task for image which matches root 
file system of system in development.
As soon as task completed SDK can be installed using generated script.
But how does it work for first build where rootfs was not built in the past.
Is in that case following procedure the proper one?
step 1: bitbake  -c populate_sdk
step 2: bitbake 

krzysiek





This message and any attachments are intended solely for the addressees and may 
contain confidential information. Any unauthorized use or disclosure, either 
whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-rockchip] conf: machine: Add support for vyasa-rk3288

[Shyam Saini]

> Hello Shyam,

Hi Trevor

> Thank you for your contribution!
>
> I just have 3 small nits with your patch, which I am happy to fix myself
> without you needing to send a v2 (if that's okay with you):

I'm perfectly fine with it. You can merge them it with your fixes.

> 1. I see that there's a mistake in meta-rockchip's README file which I will
>fix, the email subject should be prefixed with "[meta-rockchip][PATCH]".
>Sorry! I will fix this in the README.
>
> On Wed 2018-09-12 @ 07:40:04 PM, Shyam Saini wrote:
>> This patch adds initial support for the Amarula Vyasa Board.
>
> 2. I'm going to remove the following second sentence from the commit message.
>In 2 years, reading the commit logs regarding future promises/TODOs will
>seem funny. The sentence above fully explains this patch.
>
>> With this patch, we would have working images for vyasa,
>> single gpt and wic image support would be added later on.
>
>
>>
>> Signed-off-by: Shyam Saini 
>> ---
>>  conf/machine/vyasa-rk3288.conf | 14 ++
>>  1 file changed, 14 insertions(+)
>>  create mode 100644 conf/machine/vyasa-rk3288.conf
>>
>> diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
>> new file mode 100644
>> index ..9c634325451e
>> --- /dev/null
>> +++ b/conf/machine/vyasa-rk3288.conf
>> @@ -0,0 +1,14 @@
>> +# Copyright (C) 2018 Amarula Solutions
>> +# Released under the MIT license (see COPYING.MIT for the terms)
>> +
>> +#@TYPE: Machine
>> +#@NAME: Amarula Vyasa RK3288
>> +#@DESCRIPTION: Amarula Vyasa is Rockchip RK3288 SOC based Single board 
>> computer with fully supported opensource software.
>> +
>> +require conf/machine/include/rk3288.inc
>> +
>> +KERNEL_IMAGETYPE = "uImage"
>> +KERNEL_DEVICETREE = "rk3288-vyasa.dtb"
>
> 3. I'm going to add a space after += for consistency.
>
>> +KERNEL_EXTRA_ARGS +="LOADADDR=0x0200"
>> +
>> +UBOOT_MACHINE = "vyasa-rk3288_defconfig"
>> --
>> 2.11.0
>>
>
> Once again, thank you for your contribution!

Will take care of above mentioned points in future.
Thanks a lot for explaining.

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

[yocto] bitbake error

[idealsim]

Hi, i'm trying to build an image with Yocto on a new machine (ubuntu 16.04  
LTS)but i have this error that i can't resolve. Can you help ?


ERROR: Execution of event handler 'uninative_event_fetchloader' failed
Traceback (most recent call last):
  File  
"/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass", line  
55, in uninative_event_fetchloader(e=0x7f2015027790>):

 if not os.path.exists(tarballpath):
>bb.utils.mkdirhier(tarballdir)
 if d.getVar("UNINATIVE_URL", True) == "unset":
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line  
716, in  
mkdirhier(directory='/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8'):

 if e.errno != errno.EEXIST:
>raise e

OSError: [Errno 13] Permission denied: '/home/b/yocto-krogoth/../../yocto'

ERROR: Command execution failed: Traceback (most recent call last):
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py",  
line 104, in runAsyncCommand

commandmethod(self.cmds_async, self, options)
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py",  
line 325, in buildTargets

command.cooker.buildTargets(pkgs_to_build, task)
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/cooker.py", line  
1423, in buildTargets

bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data)
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line  
178, in fire

fire_class_handlers(event, d)
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line  
110, in fire_class_handlers

execute_handler(name, handler, event, d)
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line  
82, in execute_handler

ret = handler(event)
  File  
"/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass", line  
55, in uninative_event_fetchloader

bb.utils.mkdirhier(tarballdir)
  File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line  
716, in mkdirhier

raise e
OSError: [Errno 13] Permission denied: '/home/b/yocto-krogoth/../../yocto'
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Burton, Ross]

On 13 September 2018 at 12:39, Dudziak Krzysztof
 wrote:
> Thanks for hints.
> I don't want to have this package on target system.
> You sound like inheriting explicitly had some major drawback of wide scope.

It won't be included in the image unless you add it to the image.

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

Re: [yocto] inheriting native.bbclass explicitly

[Burton, Ross]

CCing the list again.  Please remember to reply to the list.

On 13 September 2018 at 11:42, Dudziak Krzysztof
 wrote:
> Is it possible for one Bitbake target to check list and order of classes 
> inherited?

bitbake -e [recipe] will show you what was parsed.

In this situation I wouldn't worry too much.  It's best to use
BBCLASSEXTEND instead of inherit native directly anyway.

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

[yocto] inheriting native.bbclass explicitly -- more details

[Dudziak Krzysztof]

autconf-archive's recipe as for OE-core layer builts also native package
in BBCLASSEXTEND-based fashion.
I like for system built here to change the approach to 
explicit-class-inheritance fashion in .bbappend in own layer.
Will it suffice to ensure native.bbclass is explicitly inherited as last class 
in .bbappend?


This message and any attachments are intended solely for the addressees and may 
contain confidential information. Any unauthorized use or disclosure, either 
whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Burton, Ross]

Adding yocto@ back to CC.  Please remember to mail the list and not the sender.

On 13 September 2018 at 10:34, Dudziak Krzysztof
 wrote:
> Will BBCLASSEXTEND=native fashion also build target system package?
> This is what is not needed (autoconf-archive on target system).
> Therefore thoughts turn to another approach.

BBCLASSEXTEND works by taking a target recipe and dynamically creating
another version of it.

So autoconf-archive.bb is written as a target recipe but because it
contains BBCLASSEXTEND="native nativesdk", there also exists
autoconf-archive-native and nativesdk-autoconf-archive.

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

[yocto] ext4 rootfs in wrong folder when trying to build sdcard image

[Richard Collins]

This is for a custom carrier board using the Phytec rk3288 SOM.

This worked for 2.2 morty.

I have migrated to 2.5 sumo. I am using their rk3288_sd_image-phy.bbclass
file. This file is only in the morty branch so I had to copy it into my bsp
layer.

I am still a bit of a Yocto noob so any help would be awesome.

When I build with
*IMAGE_FSTYPES += " tar.gz ext4"*
in the local conf the ext4 rootfs file is in the deploy folder.

When I build with
*IMAGE_FSTYPES += " tar.gz ext4"*
*IMAGE_FSTYPES_append_rk3288 = " sdcard"*
in the local conf the ext4 rootfs file ends up in the temp folder and so
the sdcard creation fails as it is looking for the ext4 file in the deploy
folder.

It's a really odd issue. :/

Any ideas on where to look?

Many thanks,
Richard e Collins.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Burton, Ross]

On 13 September 2018 at 10:17, Dudziak Krzysztof
 wrote:
> Is this rule’s scope literally each single recipe separately
>
> or rather the compound .bb file + set of matching .bbappends?

Compound.

> I am going to use that method for building autoconf-archive package
>
> as for device built here this package is needed only on build system and in
> no case on target system.

No need, the recipe already has BBCLASSEXTEND=native so you can just
depend on autoconf-archive-native.

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

Re: [yocto] allarch class used in autoconf-archive recipe

[Burton, Ross]

Re-adding yocto@ to CC.

On 13 September 2018 at 09:42, Dudziak Krzysztof
 wrote:
> Myself does not address level of warnings. TBH I did not check how the 
> warnings status is.
> Myself operates currently at recipe's level, no more.
> In lights of my understanding, which of course might still be wrong, there is 
> conflict between
> recommendation made in reference manual and how this package implements its 
> recipe.
> How to handle this situation?
>
> How to actually read Ross' answer? For me it's hard to find there answer to 
> my question. Apologize please,
> I am not so deep in Yocto Project.

The documentation states:

"OpenEmbedded recipes that produce packages that depend on tunings
through use of the RDEPENDS and TUNE_PKGARCH variables, should never
be configured for all architectures using allarch."

autoconf-archive doesn't produce packages that depend on tunings
though RDEPENDS, so it can use allarch.

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

[yocto] inheriting native.bbclass explicitly

[Dudziak Krzysztof]

Hi,

YP reference manual chapter 6.83 "native.bbclass"
https://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#ref-classes-native
 reads:
"*Create a myrecipe-native.bb that inherits the native class.
If you use this method, you must order the inherit statement in the recipe
after all other inherit statements so that the native class is inherited last."

Is this rule's scope literally each single recipe separately
or rather the compound .bb file + set of matching .bbappends?

I am going to use that method for building autoconf-archive package
as for device built here this package is needed only on build system and in no 
case on target system.

Regards
krzysiek

This message and any attachments are intended solely for the addressees and may 
contain confidential information. Any unauthorized use or disclosure, either 
whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH yocto-docs] ref-manual: Introduce the --use-label partition parameter for wic

[Kevin Hao]

Signed-off-by: Kevin Hao 
---
 documentation/ref-manual/ref-kickstart.xml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/documentation/ref-manual/ref-kickstart.xml 
b/documentation/ref-manual/ref-kickstart.xml
index a58f9d7c9602..dd97dd7206c7 100644
--- a/documentation/ref-manual/ref-kickstart.xml
+++ b/documentation/ref-manual/ref-kickstart.xml
@@ -198,6 +198,16 @@
 If the given label is already in use by another filesystem,
 a new label is created for the partition.
 
+
+--use-label:
+Makes wic to use the label in /etc/fstab to specify a
+partition. If the --use-label and --use-uuid are used at
+the same time, we prefer the uuid because it is less likely
+to cause name confliction. We don't support using this
+parameter on the root partition since it requires an
+initramfs to parse this value and we do not currently
+support that.
+
 
 --active:
 Marks the partition as active.
-- 
2.14.4

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