[yocto] permissions for /tmp set wrong

[Greg Wilson-Lindberg]

I'm trying to setup mariadb and in the process of looking at what's happening I 
see an error that it couldn't create a file in /tmp. I look at /tmp and it has 
permissions of 01700 which seems wrong. I did some searching and I found a 
reference to fs-perms.txt which has the permissions as 01777.


I haven't been able to find where this is changed. Can anyone tell me what 
might be changing the permissions from 01777 to 01700? Or at least where to 
look, or what to do to get them back to 01777.


Regards,

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

Re: [yocto] removal of user & group from sysroot when recipe/package is cleaned

[Peter Kjellerstedt]

That patch predates the Recipe Specific Sysroots that were introduced in Pyro. 
Most of it has since been removed as it is no longer relevant.

//Peter

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Kumar, Shrawan
Sent: den 24 april 2018 14:41
To: Khem Raj ; yocto@yoctoproject.org
Cc: connect.shra...@gmail.com
Subject: [yocto] removal of user & group from sysroot when recipe/package is 
cleaned

Hello Team,


Referring to the patch below regarding removal of user & group from sysroot 
when recipe/package is cleaned using clean/cleansstate/cleanall :



https://patchwork.openembedded.org/patch/119549/





Has this patch been up streamed ?

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

[yocto] building recipe with buildtools, causes sanity error: Your system needs to support the en_US.UTF-8 locale.

[John Smith]

bitbake stops with this error message: "Your system needs to support the 
en_US.UTF-8 locale."

export LC_ALL=en_US.UTF-8 has no effect. Do you know how to fix that error?

What I ve done:
- installed buildtools from 
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/buildtools/
  under /opt/poky/2.4.2

> cd poky
> . oe-init-build-env
> . /opt/poky/2.4.2/environment-setup-x86_64-pokysdk-linux
> bitbake 



https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/sanity.bbclass
def sanity_check_locale(d):
"""
Currently bitbake switches locale to en_US.UTF-8 so check that this locale 
actually exists.
"""
import locale
try:
locale.setlocale(locale.LC_ALL, "en_US.UTF-8")
except locale.Error:
raise_sanity_error("Your system needs to support the en_US.UTF-8 
locale.", d)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] removal of user & group from sysroot when recipe/package is cleaned

[Kumar, Shrawan]

Hello Team,


Referring to the patch below regarding removal of user & group from sysroot 
when recipe/package is cleaned using clean/cleansstate/cleanall :



https://patchwork.openembedded.org/patch/119549/





Has this patch been up streamed ?

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

Re: [yocto] [EXTERNAL] Re: want to execute a script having sudo : sudo cryptsetup

[Kumar, Shrawan]

Hello Team,


Referring to the patch below regarding removal of user & group from sysroot 
when recipe/package is cleaned using clean/cleansstate/cleanall :



https://patchwork.openembedded.org/patch/119549/





Has this patch been up streamed ?

Regards
Shrawan
From: John Finley [mailto:john.fin...@gmail.com]
Sent: 27 September 2017 22:58
To: Khem Raj 
Cc: Kumar, Shrawan ; connect.shra...@gmail.com; 
yocto@yoctoproject.org
Subject: [EXTERNAL] Re: [yocto] want to execute a script having sudo : sudo 
cryptsetup

pseudo can't do some of the cryptsetup functions that really require root, or 
at least I could not convince it to. Using sudo is not so good, but I don't 
think there's an easy way around it for the cryptsetup stuff.

On Wed, Sep 27, 2017 at 10:22 AM, Khem Raj 
> wrote:

On Wed, Sep 27, 2017 at 9:21 AM John Finley 
> wrote:
Try making it so the user doing the build is not prompted for a password when 
they do "sudo". I have this in my vm:

I think you can leverage pseudo tool to emulate the root user during build

john@vbox-ubuntu-16$ cat /etc/sudoers.d/john
john ALL=(ALL) NOPASSWD: ALL
john@vbox-ubuntu-16$
I don't know if that's all that's needed; I have to google it every time.

On Mon, Sep 25, 2017 at 2:48 AM, Kumar, Shrawan 
> wrote:
Hello Team ,

I am trying to achieve below from yocto , do we have a way  ?


dd if=/dev/zero of=hello.enc bs=4k count=$400
mknod /dev/loop_dev_0
losetup /dev/loop_dev_0 hello.enc
sudo cryptsetup --type=plain open /dev/loop_dev_0  plainMap < $2




Thanks and Regards
Shrawan


--
___
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] Error during Importing pexpect

[Nishina A. Pervin]

Thank you so much Ross!
It resolved my issue.

-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, April 24, 2018 3:17 PM
To: Nishina A. Pervin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Error during Importing pexpect

On 24 April 2018 at 08:09, Nishina A. Pervin  
wrote:
> When I am trying to import pexpect to make my program interactive in
> Krogoth branch of Yocto build for imx6qsabreauto board, i am getting
> the following
> error: Please help me to resolve the issue.
> root@imx6qsabreauto:/usr/bin# ./SensorTag.py B0:B4:48:BF:17:05
>
> Traceback (most recent call last):
>
>   File "./SensorTag.py", line 3, in 
>
> import pexpect
>
>   File "/usr/bin/pexpect.py", line 41, in 
>
> Currently pexpect is intended for UNIX operating systems."""
>
> ImportError: No module named pty

The dependencies on python-pexpect are not complete:

$ oe-pkgdata-util find-path */pty.py
python-terminal: /usr/lib/python2.7/pty.py
python3-terminal: /usr/lib/python3.5/pty.py

That's using Sumo so the names may be different for you, but repeat that 
command and you'll find out what package you need to add to the python-pexpect 
RDEPENDS.

Ross


Confidentiality Statement / Disclaimer : This message and any attachments is 
intended for the sole use of the intended recipient. It may contain 
confidential information. Any unauthorized use, dissemination or modification 
is strictly prohibited. If you are not the intended recipient, please notify 
the sender immediately then delete it from all your systems, and do not copy, 
use or print. Internet communications are not secure and it is the 
responsibility of the recipient to make sure that it is virus/malicious code 
exempt.

The company/sender cannot be responsible for any unauthorized alterations or 
modifications made to the contents. If you require any form of confirmation of 
the contents, please contact the company/sender. The company/sender is not 
liable for any errors or omissions in the content of this message.


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

[yocto] Release candidate build for Yocto Project 2.5 RC1

[Burton, Ross]

Hi,

We have a build ready for QA for the Yocto Project release 2.5,
release candidate 1.  As with the M3 this was built on the new
autobuilder so the announcement is happening manually again.

The release is available at:

http://autobuilder.yoctoproject.org/pub/releases/yocto-2.5.rc1/

The build results can be seen at:

https://autobuilder.yoctoproject.org/new/#/builders/30/builds/45

The eclipse-plugin-neon build failed, but it was re-ran and built
successfully so this isn't a problem.

Please QA this as soon as possible.

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

Re: [yocto] Error during Importing pexpect

[Burton, Ross]

On 24 April 2018 at 08:09, Nishina A. Pervin
 wrote:
> When I am trying to import pexpect to make my program interactive in Krogoth
> branch of Yocto build for imx6qsabreauto board, i am getting the following
> error: Please help me to resolve the issue.
> root@imx6qsabreauto:/usr/bin# ./SensorTag.py B0:B4:48:BF:17:05
>
> Traceback (most recent call last):
>
>   File "./SensorTag.py", line 3, in 
>
> import pexpect
>
>   File "/usr/bin/pexpect.py", line 41, in 
>
> Currently pexpect is intended for UNIX operating systems."""
>
> ImportError: No module named pty

The dependencies on python-pexpect are not complete:

$ oe-pkgdata-util find-path */pty.py
python-terminal: /usr/lib/python2.7/pty.py
python3-terminal: /usr/lib/python3.5/pty.py

That's using Sumo so the names may be different for you, but repeat
that command and you'll find out what package you need to add to the
python-pexpect RDEPENDS.

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

Re: [yocto] Can't able to locate qemu_i586-poky-linux in eclipse ide

[Ang, Chin Huat]

Hi,

Please note that there's now a new mailing list for eclipse-yocto plugin 
related discussion: eclipse-yo...@yoctoproject.org

You need to either start eclipse within a oe-init-build-env shell, or source 
environment-setup-* script in External Tool Configuration. Probably the easiest 
way is to just duplicate the qemu-*-poky-linux External Tool Configuration and 
replace "runqemu ..." with your runqemu-addptable2image command-line.

--Chin Huat


From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf 
of akshaya dalu [akshaya.cool.c...@gmail.com]
Sent: Monday, April 23, 2018 3:57 PM
To: yocto@yoctoproject.org
Subject: [yocto] Can't able to locate qemu_i586-poky-linux in eclipse ide

Hello,
  I want to open emulator from  eclipse ide and run hello world program 
without using any hardware . I have gone through the documentation but can't 
able to locate qemu_i586-poky-linux in external tool configuration of eclipse 
ide. I referred the link  
https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage
  . In that I didn't add 'ssh-server-openssh' extra feature in local 
configuration file and while executing bitbake core-image-sato 99% satisfied 
got 1 error msg and 1 warning msg. But I can able to open emulator through 
terminal by runqemu command! Can you help me??

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

[yocto] Error during Importing pexpect

[Nishina A. Pervin]

Hi,

When I am trying to import pexpect to make my program interactive in Krogoth 
branch of Yocto build for imx6qsabreauto board, i am getting the following 
error: Please help me to resolve the issue.

root@imx6qsabreauto:/usr/bin# ./SensorTag.py B0:B4:48:BF:17:05
Traceback (most recent call last):
  File "./SensorTag.py", line 3, in 
import pexpect
  File "/usr/bin/pexpect.py", line 41, in 
Currently pexpect is intended for UNIX operating systems."""
ImportError: No module named pty
A critical module was not found. Probably this OS does not support it.
Currently pexpect is intended for UNIX operating systems.
root@imx6qsabreauto:/usr/bin#

Please help me to resolve the issue.

Regards,
Nishina


Confidentiality Statement / Disclaimer : This message and any attachments is 
intended for the sole use of the intended recipient. It may contain 
confidential information. Any unauthorized use, dissemination or modification 
is strictly prohibited. If you are not the intended recipient, please notify 
the sender immediately then delete it from all your systems, and do not copy, 
use or print. Internet communications are not secure and it is the 
responsibility of the recipient to make sure that it is virus/malicious code 
exempt.

The company/sender cannot be responsible for any unauthorized alterations or 
modifications made to the contents. If you require any form of confirmation of 
the contents, please contact the company/sender. The company/sender is not 
liable for any errors or omissions in the content of this message.


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

Re: [yocto] Usage of yocto on different (production vs debug) scenarios

[Iván Castell]

That sounds really convincing, I will give it a chance and come back to
describe the hole process after all. Thank you for that valuable
information Mr. Ross

2018-04-23 17:38 GMT+02:00 Burton, Ross :

> Very curious as to what book said that, because *any* example of that
> happening is a bug in the recipe itself.  I wouldn't listen to it: the YP
> autobuilder has a shared sstate for three distributions * four
> architectures * two libc implementations and doesn't have problems.
>
> Ross
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Usage of yocto on different (production vs debug) scenarios

[Uwe Geuder]

Thanks Ross for your answers.  I'm still working on fully understanding
shared state so I appreciate your help.  Let me follow up on both your
answers in a single message.

On Mon, Apr 23, 2018 at 6:38 PM, Burton, Ross  wrote:
> On 23 April 2018 at 16:23, Iván Castell  wrote:
>>
[...]
>>
>> Related with that shared state cache, I found some information on a e-book
>> (search the text on google to find the source):
>>
>> "Sharing a shared state cache is possible; however, it needs to be
>> approached with care. Not all changes are detected by the shared state cache
>> implementation, and when this happens, some or all of the cache needs to be
>> invalidated. This can cause problems when the state cache is being shared.
[...]
> Very curious as to what book said that, because *any* example of that
> happening is a bug in the recipe itself.  I wouldn't listen to it: the YP
> autobuilder has a shared sstate for three distributions * four architectures
> * two libc implementations and doesn't have problems.
>
> Ross
>

I think when talking about shared state there can be 2 aspects of sharing

1.) sharing over time: Several invocations of bitbake in the same environment
  (DISTRO, MACHINE etc)
2.) sharing over distros etc.

Number 1 is an incremental build (as opposed to clean or full
build).  Without any doubt that is useful (or really mandatory) for
development work.  You build, you make little changes, you build, you
test, you make more changes...  You share state from the previous build,
because making a full clean build every time would lead to completely
inacceptable cycle times.

But when you are "done" with your changes you make an integration build
and to my experience that should be a clean (aka full) build.  You
intentionally do not share any state from a previous build, you don't
make an incremental build, because there is always the risk of broken
recipes.  I mean if there were no broken software, we would all be
unemployed by now...

Let me give a simple example I experienced my self recently:

I added creation of a new file in some task.  In my incremental
developer build it all worked fine.  When I put into a clean integration
build the task failed.  It turned out that the directory I wrote my new
file to in task A was created by a different task B.  In my development
build task B had already been executed long before I even started to
make the recipe modificationto to create a new file, so task A always
succeeded.  In the clean build task A happened to run first and failed.
A simple missing dependency / incorrect task ordering.  With parallel
clean builds you might not always find it, but with incremental builds
it can go undetected forever.

It's not only "some book" that mentions the risk of "bad" state, but
also the Yocto documentaton:

https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#concepts-tips-and-tricks

(Especially 4.5.4.2. Invalidating Shared State.  Of course the
invalidating is easy, but finding what you need to invalidate is hard.)

Of course the less something is tested the bigger the risk is.  So the
bitbake system should be rather fine, commonly used Poky recipes
probably too.  But when it comes to random layers and our own local
recipes and bbappends I would expect the risk to grow a lot.

So do you really tell us in the message above that above that Yocto
project runs incremental integration builds?

Another way to think about it: Shared state is used to to avoid
rebuilds.  So how could I benefit from having state information in some
SSTATE_DIR already?  I have to build it anyway, because my build area is
empty to begin with.

The 2nd aspect, sharing over distros was covered in the other message.

On Mon, Apr 23, 2018 at 6:10 PM, Burton, Ross  wrote:
> On 20 April 2018 at 11:47, Uwe Geuder  wrote:
>> But can you share state between distros? Isn't the purpose of distros to
>> use different options (variable settings) so the state would always be
>> different?
>
> If the input to the recipe is different then the hashes would be
> different so the content won't conflict.  You can definitely share
> sstate between DISTROs.
>
> Ross

Under the assumption that all recepies were perfect (which they probably
aren't in every point of history, see above) I fully believe that the
build system would work perfectly when I share the SSTATE_DIR over
DISTRO borders (or diferent MACHINE settings).  But do I really have any
commmon data that would lead to any saving? As you say the hashes would
be different.  In my thinking all "expensive" state info should be
different, because a different DISTRO (or different MACHINE) would lead
to different hashes for bascially every item.  So in the best case I end
up with several distinct sets of state data stored under the same top
directory, but that doesn't seem to result in any saving.  In the worst
case an item goes into the same file, so 

[yocto] sdk compiler output usable during build?

[Janne Karhunen]

Hi,

Quick question - is the sdk compiler supposed to be able to create
executables that can be executed while the sdk package build is
ongoing?

Reason I'm asking is that my package nativesdk build errors out saying
'C compiler cannot create executables'. Reason for that seems to be
that the output (say a.out) generated by x86_64-pokysdk-linux-gcc
requests runtime linker from the SDKs default final resting place
(/opt/poky..) and not from the location where the sysroot lies during
the build. How is that supposed to work?


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