[yocto] 答复: Yocto Linux kernel 4.8 boot can't login.

[Richard Zhang]

Thanks,now work fine.


Richard


发件人: Khem Raj 
发送时间: 2017年1月13日 0:23:24
收件人: Richard Zhang
抄送: yocto@yoctoproject.org
主题: Re: [yocto] Yocto Linux kernel 4.8 boot can't login.

On Wed, Jan 11, 2017 at 9:48 PM, Richard Zhang  wrote:
> Starting crond: setuid: Function not implemented

Linux gained a new config option, CONFIG_MULTIUSER, that makes
support for non-root users optional. This results in a number of syscalls
being disabled setuid is one of them. set this option to 'y'
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi_4.8.bb: Upgrade to 4.8.16

[Khem Raj]

On Thu, Jan 12, 2017 at 1:54 PM, Andrei Gherzan  wrote:
> On Thu, Jan 12, 2017 at 6:29 PM, Khem Raj  wrote:
>> Signed-off-by: Khem Raj 
>> ---
>>  recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
>> b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>> index 7511f93..be25e65 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>> +++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
>> @@ -1,8 +1,8 @@
>>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>
>> -LINUX_VERSION ?= "4.8.15"
>> +LINUX_VERSION ?= "4.8.16"
>>
>> -SRCREV = "c8af0c2f515556ef052913d552b6b11501c71996"
>> +SRCREV = "061dccce6cf6705bbb5da29a643f4b0ad1d11630"
>>  SRC_URI = 
>> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
>>  "
>>  require linux-raspberrypi.inc
>> --
>> 2.11.0
>>
>
> Merged both to master.

 What do folks think about deleting all other kernel besides 4.1 4.4 and 4.9

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

Re: [yocto] Building on MacOS X

[Mark Hatle]

On 1/12/17 11:41 AM, Roger Smith wrote:
>  I have Parallels (running on El Capitan the one before Sierra)  and ubuntu 14
>  running my current build environment on a MacBook Pro, but boy is the build
> slow… I also worked at Apple for 19 years on drivers inside MacOS X/iOS, so I 
> am
> more than motivated to have this working natively rather than inside any
> container or disk space hogging environment.  As I mentioned I am working with
> the Intel Aero compute board, so slogging though all this fat to build an 
> image
> is a productivity killer.

So take from this.. there is desire for oe/bitbake to work natively.  Most
people don't have the skill or free time to do the work.  A number of us started
it at one time or another and made enough progress to say "ya I think it's
possible" and then ran out of time.

As far as I know pseudo and the security introduced in 10.11 that affect
preloading is likely the biggest technical problem...  everything else is just
"it's not Linux".

--Mark

> I think most of the  incompatibilities between Linux and os x (which btw is
> coming from the ios side of the fence unfortunately), can be mitigated with 
> boot
> args or via the command line . Apple’s compiler team had to make llvm 
> compatible
> with gcc, so I am surprised if in 2017, there are compiler issues to building
> for an x86_64 platform with llvm on the Mac . That’s the kind of bug Apple 
> likes
> to fix promptly.. 
> 
> As I mentioned, I tried to simply source the oe-init-build-env, and got an 
> error
> that the readlink command that yocto is using is incompatible with the bsd
> version of readlink built into os x. 
> 
> i.e when I run .
> 
> source oe-init-build-env
> 
> I get the error
> 
> readlink: illegal option -- f
> 
> Which is because on OS X readlink doesn’t specify -f
> 
> YNOPSIS
>  stat [-FLnq] [-f format| -l | -r | -s | -x] [-t timefmt] [file...]
>  readlink [-n] [file...]
> 
> I didn’t want to go through this level of change in the Yocto sources if (1)
> people don’t care to take changes or (2) it had already been done before.. I 
> was
> curious how far down this rabbit hole people had gone before..
> 
> Roger
> 
> 
>> On Jan 12, 2017, at 8:50 AM, Andrea Galbusera > > wrote:
>>
>> On Thu, Jan 12, 2017 at 5:21 PM, Belisko Marek > > wrote:
>>
>> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>> > > wrote:
>> > You can also build using Docker containers:
>> > https://github.com/crops/docker-win-mac-docs/wiki
>> 
>> Well the re is other limitation about slow filesystem access from
>> docker on osx. There is workaround to use nfs but it's not possible to
>> use nfs for building yocto - so it's kind of chicken-egg problem ;)
>>
>>
>> I shortly tested the CROPS docker-based setup after watching some 
>> presentation
>> at ELCE 2016 in Berlin. It basically worked but I experienced the filesystem
>> slowness your are talking about. I ended up waiting hours to see a simple
>> core-image-minimal build complete (even after giving more cores to docker).
>> One more point is that slightly more complex build scenarios, i.e. building
>> resin.os, also required tweaking docker run parameters for the build 
>> container
>> in order to give bitbake access to features like loop devices it needed (not
>> always easily debuggable issues indeed). Turned out I decided to stick with
>> more canonical linux based environments for the moment.
>>
>> Anyway, the technology behind CROPS is *very* interesting to me, and I'd like
>> to hear from people closely involved (Tim?) what the state of the art is and
>> what we can expect to see in the near future. IIRC, the roadmap for Yocto 2.3
>> release was supposed to resurrect the Eclipse plugin and adopt CROPS as an
>> alternative for running eSDK in a seamless way on different development host
>> OSs. Beside from the images on docker hub and the github projects that didn't
>> have high activity in the latest months, I hardly find discussions and
>> documentation on the whole approach. Isn't this hot enough anymore or are
>> there big issues that will prevent this technology from taking off. I often
>> manage SDKs for Windows-minded developers and I strongly yearn to find a
>> better approach to help them feel at home while building stuff for OE/Yocto
>> based systems... 
>>
>>  
>>
>> >
>> > On Jan 12, 2017, at 7:34 AM, Burton, Ross > > wrote:
>> >
>> >
>> > On 12 January 2017 at 15:14, Roger Smith > > wrote:
>> >>
>> >> Is there any documentation for running the Yocto build system on Mac 
>> OS X
>> >> or macOS as Apple now calls it? I am working with the 

Re: [yocto] Building on MacOS X

[Tim Orling]

> On Jan 12, 2017, at 8:50 AM, Andrea Galbusera  wrote:
> 
> On Thu, Jan 12, 2017 at 5:21 PM, Belisko Marek  > wrote:
> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
> > 
> wrote:
> > You can also build using Docker containers:
> > https://github.com/crops/docker-win-mac-docs/wiki 
> > 
> Well the re is other limitation about slow filesystem access from
> docker on osx. There is workaround to use nfs but it's not possible to
> use nfs for building yocto - so it's kind of chicken-egg problem ;)
> 
> I shortly tested the CROPS docker-based setup after watching some 
> presentation at ELCE 2016 in Berlin. It basically worked but I experienced 
> the filesystem slowness your are talking about. I ended up waiting hours to 
> see a simple core-image-minimal build complete (even after giving more cores 
> to docker). One more point is that slightly more complex build scenarios, 
> i.e. building resin.os, also required tweaking docker run parameters for the 
> build container in order to give bitbake access to features like loop devices 
> it needed (not always easily debuggable issues indeed). Turned out I decided 
> to stick with more canonical linux based environments for the moment.
> 

Depending on your hardware, it will take hours to build a simple image for the 
first time. This is no different on native Linux, if the hardware is only 1-4 
cores, 4-8 GB RAM and especially if you are using a spinning harddrive. Server 
class systems with 72+ cores and 128+ GB of RAM will have a significantly 
faster build time. Almost all my YP/OE builds are now run in containers.

We will run some tests and get back to you about the real speed differences. 
Assuming you are running on the same hardware, we have seen builds on Windows 
be slightly *faster* than on native Linux. We need to collect data for our 
latest Mac OS X builds to address your concern.

> Anyway, the technology behind CROPS is *very* interesting to me, and I'd like 
> to hear from people closely involved (Tim?) what the state of the art is and 
> what we can expect to see in the near future. IIRC, the roadmap for Yocto 2.3 
> release was supposed to resurrect the Eclipse plugin and adopt CROPS as an 
> alternative for running eSDK in a seamless way on different development host 
> OSs. Beside from the images on docker hub and the github projects that didn't 
> have high activity in the latest months, I hardly find discussions and 
> documentation on the whole approach. Isn't this hot enough anymore or are 
> there big issues that will prevent this technology from taking off. I often 
> manage SDKs for Windows-minded developers and I strongly yearn to find a 
> better approach to help them feel at home while building stuff for OE/Yocto 
> based systems... 
> 

This work is being done by a very small team. It is no less hot than since it 
was first announced. However, the state of the Eclipse plugin at the initial 
announcement was experimental and the perception was that it was production 
ready. That is a risk of developing a project in the open. Both the Docker 
technology and the Eclipse technologies that we are using are rapidly changing.

Our current work is hosted on GitHub (https://github.com/crops/eclipse-crops 
). We had to rethink some of the 
approach that we demoed at ELC San Diego. We are still targeting 2.3 for the 
“standard SDK” approach (e.g. no “devtool” integration).

>  
> >
> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  > > wrote:
> >
> >
> > On 12 January 2017 at 15:14, Roger Smith  > > wrote:
> >>
> >> Is there any documentation for running the Yocto build system on Mac OS X
> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
> >> Before I go down the rabbit hole of fixing issues like this one (and I am
> >> using the bash shell), I’d like to know if anyone has build it on os x
> >> before.
> >
> >
> > If you install all of the GNU tools using brew or similar and put them first
> > on $PATH then you can get bitbake started.  Then you need to stub out the
> > linux-specific bits in bitbake.  I've previously started on this work
> > already
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin 
> > ).
> > The next step is figuring out how to configure OE to build and link natively
> > on OSX using LLVM instead of GCC.
> >
> > However all of this is mostly academic because in Sierra (iirc) onwards
> > there is tighter security on processes, which means that pseudo won't work
> > even if you port it to macOS.
> >
> > So unless you fancy some non-trivial engineering 

Re: [yocto] Building on MacOS X

[Tim Orling]

> On Jan 12, 2017, at 10:43 AM, Maciej Borzęcki  
> wrote:
> 
> On Thu, Jan 12, 2017 at 7:12 PM, Andrea Galbusera  > wrote:
>> On Thu, Jan 12, 2017 at 6:55 PM, Maciej Borzęcki
>>  wrote:
>>> 
>>> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>>>  wrote:
 You can also build using Docker containers:
 https://github.com/crops/docker-win-mac-docs/wiki
>>> 
>>> IIRC docker on mac relies on docker-machine, which in turn spins up a
>>> virtualbox VM.
>> 
>> 
>> Not anymore! There's a native implementation [1] but still a linux kernel
>> around anyway! ;-)
>> 
>> [1]
>> https://www.docker.com/docker-news-an.d-press/docker-released-native-mac-and-windows-apps-optimize-developer-experience
> 
> Good to know. There is still hope for mac users after all :)

My main development machine is Mac OS X 10.12.2 (Sierra). I stay up to date 
with the latest Docker for Mac beta. It is a very pleasant experience.

> 
>>> 
>>> 
>>> 
 
 On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
 
 
 On 12 January 2017 at 15:14, Roger Smith  wrote:
> 
> Is there any documentation for running the Yocto build system on Mac OS
> X
> or macOS as Apple now calls it? I am working with the Intel Aero board.
> Before I go down the rabbit hole of fixing issues like this one (and I
> am
> using the bash shell), I’d like to know if anyone has build it on os x
> before.
 
 
 If you install all of the GNU tools using brew or similar and put them
 first
 on $PATH then you can get bitbake started.  Then you need to stub out
 the
 linux-specific bits in bitbake.  I've previously started on this work
 already
 
 (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
 The next step is figuring out how to configure OE to build and link
 natively
 on OSX using LLVM instead of GCC.
 
 However all of this is mostly academic because in Sierra (iirc) onwards
 there is tighter security on processes, which means that pseudo won't
 work
 even if you port it to macOS.
 
 So unless you fancy some non-trivial engineering the short version is
 just
 use something like Docker to run a Linux system on your Mac.
 
 Ross
 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
 
 
 
 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
 
>>> 
>>> 
>>> 
>>> --
>>> Maciej Borzecki
>>> RnDity
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>> 
>> 
> 
> 
> 
> -- 
> Maciej Borzecki
> RnDity

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

Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi_4.8.bb: Upgrade to 4.8.16

[Andrei Gherzan]

On Thu, Jan 12, 2017 at 6:29 PM, Khem Raj  wrote:
> Signed-off-by: Khem Raj 
> ---
>  recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
> b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> index 7511f93..be25e65 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> @@ -1,8 +1,8 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> -LINUX_VERSION ?= "4.8.15"
> +LINUX_VERSION ?= "4.8.16"
>
> -SRCREV = "c8af0c2f515556ef052913d552b6b11501c71996"
> +SRCREV = "061dccce6cf6705bbb5da29a643f4b0ad1d11630"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
>  "
>  require linux-raspberrypi.inc
> --
> 2.11.0
>

Merged both to master.


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

Re: [yocto] Override machine conf settings

[Khem Raj]

On Thu, Jan 12, 2017 at 10:37 AM, Ayoub Zaki  wrote:
> Hello,
>
> I'm trying to figure out how can I override machine settings, for example in
> raspberrypi  I want to change default kernel version from 4.4.x to 4.1.x for
> that I created in my layer meta-somelayer/conf/machine/raspberrypi.conf :

there is a machine config with same name in meta-raspberrypi layer and
thats taking
precedence over your layer see conf/layer.conf where it sets the
PRIORITY and also ensure
the BBPATHs are prefixed for your layer to be in front of
meta-raspberrypi layer. So that
it uses your layer and falls back to meta-raspberrypi to do the filler work.


>
> require conf/machine/raspberrypi.conf
> PREFERRED_VERSION_linux-raspberrypi = "4.1.%"
>
>
> when I ran bitbake it gives:
>
> $ MACHINE=raspberrypi bitbake virtual/kernel
>
> NOTE: Tainting hash to force rebuild of task
> /home/zak/Projects/yocto/meta-somelayer/recipes-kernel/linux/linux-raspberrypi_4.4.bb,
> do_compile
>
> so it seems that bitbake ignored my override settings !
>
> I'm using morty branch and my layer meta-somelayer has higher priority than
> meta-rapberrypi :
>
> $ bitbake-layers show-layers
> layer path  priority
> ==
> meta  /home/zak/Projects/yocto/meta5
> meta-yocto-bsp/home/zak/Projects/yocto/meta-yocto-bsp  5
> meta-poky /home/zak/Projects/yocto/meta-poky   5
> meta-yocto-bsp/home/zak/Projects/yocto/meta-yocto-bsp  5
> meta-raspberrypi  /home/zak/Projects/yocto/meta-raspberrypi  9
> meta-somelayer/home/zak/Projects/yocto/meta-somelayer  5
>
>
> when I tried to override the setting in rpi.conf instead of raspberrypi.conf
> in meta-somelayer/conf/machine/rpi.conf:
>
> MACHINEOVERRIDES = "raspberrypi:${MACHINE}"
> require conf/machine/raspberrypi.conf
>
> PREFERRED_VERSION_linux-raspberrypi = "4.1.%"
>
> and running bitbake with :
>
>
> $ MACHINE=rpi bitbake virtual/kernel
> NOTE: Tainting hash to force rebuild of task
> /home/zak/Projects/yocto/meta-somelayer/recipes-kernel/linux/linux-raspberrypi_4.1.bb,
> do_compile
>
> it worked !
>
> My objective however is to override the machine settings and keep the same
> MACHINE name.
>
> Any Ideas?
>
>
> Regards,
>
>
>
>
>
> --
> ___
> 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] Building on MacOS X

[Maciej Borzęcki]

On Thu, Jan 12, 2017 at 7:12 PM, Andrea Galbusera  wrote:
> On Thu, Jan 12, 2017 at 6:55 PM, Maciej Borzęcki
>  wrote:
>>
>> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>>  wrote:
>> > You can also build using Docker containers:
>> > https://github.com/crops/docker-win-mac-docs/wiki
>>
>> IIRC docker on mac relies on docker-machine, which in turn spins up a
>> virtualbox VM.
>
>
> Not anymore! There's a native implementation [1] but still a linux kernel
> around anyway! ;-)
>
> [1]
> https://www.docker.com/docker-news-and-press/docker-released-native-mac-and-windows-apps-optimize-developer-experience

Good to know. There is still hope for mac users after all :)

>>
>>
>>
>> >
>> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
>> >
>> >
>> > On 12 January 2017 at 15:14, Roger Smith  wrote:
>> >>
>> >> Is there any documentation for running the Yocto build system on Mac OS
>> >> X
>> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
>> >> Before I go down the rabbit hole of fixing issues like this one (and I
>> >> am
>> >> using the bash shell), I’d like to know if anyone has build it on os x
>> >> before.
>> >
>> >
>> > If you install all of the GNU tools using brew or similar and put them
>> > first
>> > on $PATH then you can get bitbake started.  Then you need to stub out
>> > the
>> > linux-specific bits in bitbake.  I've previously started on this work
>> > already
>> >
>> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
>> > The next step is figuring out how to configure OE to build and link
>> > natively
>> > on OSX using LLVM instead of GCC.
>> >
>> > However all of this is mostly academic because in Sierra (iirc) onwards
>> > there is tighter security on processes, which means that pseudo won't
>> > work
>> > even if you port it to macOS.
>> >
>> > So unless you fancy some non-trivial engineering the short version is
>> > just
>> > use something like Docker to run a Linux system on your Mac.
>> >
>> > Ross
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>> >
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>>
>>
>>
>> --
>> Maciej Borzecki
>> RnDity
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>



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

[yocto] Override machine conf settings

[Ayoub Zaki]

Hello,

I'm trying to figure out how can I override machine settings, for example
in raspberrypi  I want to change default kernel version from 4.4.x to 4.1.x
for that I created in my layer meta-somelayer/conf/machine/raspberrypi.conf
:

require conf/machine/raspberrypi.conf
PREFERRED_VERSION_linux-raspberrypi = "4.1.%"


when I ran bitbake it gives:

$ MACHINE=raspberrypi bitbake virtual/kernel

NOTE: Tainting hash to force rebuild of task
/home/zak/Projects/yocto/meta-somelayer/recipes-kernel/linux/
linux-raspberrypi_4.4.bb, do_compile

so it seems that bitbake ignored my override settings !

I'm using morty branch and my layer meta-somelayer has higher priority than
meta-rapberrypi :

$ bitbake-layers show-layers
layer path  priority
==
meta  /home/zak/Projects/yocto/meta5
meta-yocto-bsp/home/zak/Projects/yocto/meta-yocto-bsp  5
meta-poky /home/zak/Projects/yocto/meta-poky   5
meta-yocto-bsp/home/zak/Projects/yocto/meta-yocto-bsp  5
meta-raspberrypi  /home/zak/Projects/yocto/meta-raspberrypi  9
meta-somelayer/home/zak/Projects/yocto/meta-somelayer  5


when I tried to override the setting in rpi.conf instead of
raspberrypi.conf in meta-somelayer/conf/machine/rpi.conf:

MACHINEOVERRIDES = "raspberrypi:${MACHINE}"
require conf/machine/raspberrypi.conf

PREFERRED_VERSION_linux-raspberrypi = "4.1.%"

and running bitbake with :


$ MACHINE=rpi bitbake virtual/kernel
NOTE: Tainting hash to force rebuild of task
/home/zak/Projects/yocto/meta-somelayer/recipes-kernel/linux/
linux-raspberrypi_4.1.bb, do_compile

it worked !

My objective however is to override the machine settings and keep the same
MACHINE name.

Any Ideas?


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

[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi_4.9.bb: Add recipe for 4.9 release

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-kernel/linux/linux-raspberrypi_4.9.bb | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.9.bb

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
new file mode 100644
index 000..20f43aa
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
@@ -0,0 +1,8 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
+
+LINUX_VERSION ?= "4.9.2"
+
+SRCREV = "4052b0da7dbab0df22ca8733cf50b3e573e221e0"
+SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.9.y \
+"
+require linux-raspberrypi.inc
-- 
2.11.0

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

[yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi_4.8.bb: Upgrade to 4.8.16

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
index 7511f93..be25e65 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
@@ -1,8 +1,8 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
 
-LINUX_VERSION ?= "4.8.15"
+LINUX_VERSION ?= "4.8.16"
 
-SRCREV = "c8af0c2f515556ef052913d552b6b11501c71996"
+SRCREV = "061dccce6cf6705bbb5da29a643f4b0ad1d11630"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
 "
 require linux-raspberrypi.inc
-- 
2.11.0

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

Re: [yocto] Building on MacOS X

[Andrea Galbusera]

On Thu, Jan 12, 2017 at 6:55 PM, Maciej Borzęcki  wrote:

> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>  wrote:
> > You can also build using Docker containers:
> > https://github.com/crops/docker-win-mac-docs/wiki
>
> IIRC docker on mac relies on docker-machine, which in turn spins up a
> virtualbox VM.
>

Not anymore! There's a native implementation [1] but still a linux kernel
around anyway! ;-)

[1]
https://www.docker.com/docker-news-and-press/docker-released-native-mac-and-windows-apps-optimize-developer-experience


>
>
> >
> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
> >
> >
> > On 12 January 2017 at 15:14, Roger Smith  wrote:
> >>
> >> Is there any documentation for running the Yocto build system on Mac OS
> X
> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
> >> Before I go down the rabbit hole of fixing issues like this one (and I
> am
> >> using the bash shell), I’d like to know if anyone has build it on os x
> >> before.
> >
> >
> > If you install all of the GNU tools using brew or similar and put them
> first
> > on $PATH then you can get bitbake started.  Then you need to stub out the
> > linux-specific bits in bitbake.  I've previously started on this work
> > already
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
> log/?h=ross/darwin).
> > The next step is figuring out how to configure OE to build and link
> natively
> > on OSX using LLVM instead of GCC.
> >
> > However all of this is mostly academic because in Sierra (iirc) onwards
> > there is tighter security on processes, which means that pseudo won't
> work
> > even if you port it to macOS.
> >
> > So unless you fancy some non-trivial engineering the short version is
> just
> > use something like Docker to run a Linux system on your Mac.
> >
> > Ross
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
>
>
> --
> Maciej Borzecki
> RnDity
> --
> ___
> 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] Building on MacOS X

[Burton, Ross]

On 12 January 2017 at 17:55, Maciej Borzęcki 
wrote:

> IIRC docker on mac relies on docker-machine, which in turn spins up a
> virtualbox VM.
>

That's the old Docker (Docker Toolbox), the new Docker (Docker for Mac)
uses the built-in hypervisor so basically works exactly like Docker on
Linux.

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

Re: [yocto] Building on MacOS X

[Maciej Borzęcki]

On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
 wrote:
> You can also build using Docker containers:
> https://github.com/crops/docker-win-mac-docs/wiki

IIRC docker on mac relies on docker-machine, which in turn spins up a
virtualbox VM.


>
> On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
>
>
> On 12 January 2017 at 15:14, Roger Smith  wrote:
>>
>> Is there any documentation for running the Yocto build system on Mac OS X
>> or macOS as Apple now calls it? I am working with the Intel Aero board.
>> Before I go down the rabbit hole of fixing issues like this one (and I am
>> using the bash shell), I’d like to know if anyone has build it on os x
>> before.
>
>
> If you install all of the GNU tools using brew or similar and put them first
> on $PATH then you can get bitbake started.  Then you need to stub out the
> linux-specific bits in bitbake.  I've previously started on this work
> already
> (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
> The next step is figuring out how to configure OE to build and link natively
> on OSX using LLVM instead of GCC.
>
> However all of this is mostly academic because in Sierra (iirc) onwards
> there is tighter security on processes, which means that pseudo won't work
> even if you port it to macOS.
>
> So unless you fancy some non-trivial engineering the short version is just
> use something like Docker to run a Linux system on your Mac.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



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

Re: [yocto] Building on MacOS X

[Burton, Ross]

On 12 January 2017 at 17:41, Roger Smith  wrote:

> As I mentioned, I tried to simply source the oe-init-build-env, and got an
> error that the readlink command that yocto is using is incompatible with
> the bsd version of readlink built into os x.
>

Yes, we assume GNU tools.  That was the first step I posted: use brew to
install gnu awk/coreutils/etc etc.  But thats also the easy bit...

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

Re: [yocto] Building on MacOS X

[Roger Smith]

 I have Parallels (running on El Capitan the one before Sierra)  and ubuntu 14  
running my current build environment on a MacBook Pro, but boy is the build 
slow… I also worked at Apple for 19 years on drivers inside MacOS X/iOS, so I 
am more than motivated to have this working natively rather than inside any 
container or disk space hogging environment.  As I mentioned I am working with 
the Intel Aero compute board, so slogging though all this fat to build an image 
is a productivity killer.

I think most of the  incompatibilities between Linux and os x (which btw is 
coming from the ios side of the fence unfortunately), can be mitigated with 
boot args or via the command line . Apple’s compiler team had to make llvm 
compatible with gcc, so I am surprised if in 2017, there are compiler issues to 
building for an x86_64 platform with llvm on the Mac . That’s the kind of bug 
Apple likes to fix promptly.. 

As I mentioned, I tried to simply source the oe-init-build-env, and got an 
error that the readlink command that yocto is using is incompatible with the 
bsd version of readlink built into os x. 

i.e when I run .

source oe-init-build-env

I get the error

readlink: illegal option -- f

Which is because on OS X readlink doesn’t specify -f

YNOPSIS
 stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]
 readlink [-n] [file ...]

I didn’t want to go through this level of change in the Yocto sources if (1) 
people don’t care to take changes or (2) it had already been done before.. I 
was curious how far down this rabbit hole people had gone before..

Roger


> On Jan 12, 2017, at 8:50 AM, Andrea Galbusera  wrote:
> 
> On Thu, Jan 12, 2017 at 5:21 PM, Belisko Marek  > wrote:
> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
> > 
> wrote:
> > You can also build using Docker containers:
> > https://github.com/crops/docker-win-mac-docs/wiki 
> > 
> Well the re is other limitation about slow filesystem access from
> docker on osx. There is workaround to use nfs but it's not possible to
> use nfs for building yocto - so it's kind of chicken-egg problem ;)
> 
> I shortly tested the CROPS docker-based setup after watching some 
> presentation at ELCE 2016 in Berlin. It basically worked but I experienced 
> the filesystem slowness your are talking about. I ended up waiting hours to 
> see a simple core-image-minimal build complete (even after giving more cores 
> to docker). One more point is that slightly more complex build scenarios, 
> i.e. building resin.os, also required tweaking docker run parameters for the 
> build container in order to give bitbake access to features like loop devices 
> it needed (not always easily debuggable issues indeed). Turned out I decided 
> to stick with more canonical linux based environments for the moment.
> 
> Anyway, the technology behind CROPS is *very* interesting to me, and I'd like 
> to hear from people closely involved (Tim?) what the state of the art is and 
> what we can expect to see in the near future. IIRC, the roadmap for Yocto 2.3 
> release was supposed to resurrect the Eclipse plugin and adopt CROPS as an 
> alternative for running eSDK in a seamless way on different development host 
> OSs. Beside from the images on docker hub and the github projects that didn't 
> have high activity in the latest months, I hardly find discussions and 
> documentation on the whole approach. Isn't this hot enough anymore or are 
> there big issues that will prevent this technology from taking off. I often 
> manage SDKs for Windows-minded developers and I strongly yearn to find a 
> better approach to help them feel at home while building stuff for OE/Yocto 
> based systems... 
> 
>  
> >
> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  > > wrote:
> >
> >
> > On 12 January 2017 at 15:14, Roger Smith  > > wrote:
> >>
> >> Is there any documentation for running the Yocto build system on Mac OS X
> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
> >> Before I go down the rabbit hole of fixing issues like this one (and I am
> >> using the bash shell), I’d like to know if anyone has build it on os x
> >> before.
> >
> >
> > If you install all of the GNU tools using brew or similar and put them first
> > on $PATH then you can get bitbake started.  Then you need to stub out the
> > linux-specific bits in bitbake.  I've previously started on this work
> > already
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin 
> > ).
> > The next step is figuring out how to configure OE to build and link natively
> > on OSX using LLVM 

Re: [yocto] [oe] [Openembedded-architecture] OpenEmbedded Developers Meeting in Portland before ELC

[Burton, Ross]

On 12 January 2017 at 14:18, Hudson, Sean  wrote:

>   It's a great point.  I have volunteered Mentor's teleconference, but the
> onsite pickup is always a challenge.  Once we've finalized the location,
> I'll focus on making sure that we have a high quality pickup(s) in the
> room.  If possible, I'll get a true video-conference setup.
>

Definitely plural!  A conference phone with a number of microphones dotted
around the room seems to be a sensible idea.

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

Re: [yocto] Building on MacOS X

[Andrea Galbusera]

On Thu, Jan 12, 2017 at 5:21 PM, Belisko Marek 
wrote:

> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>  wrote:
> > You can also build using Docker containers:
> > https://github.com/crops/docker-win-mac-docs/wiki
> Well the re is other limitation about slow filesystem access from
> docker on osx. There is workaround to use nfs but it's not possible to
> use nfs for building yocto - so it's kind of chicken-egg problem ;)
>

I shortly tested the CROPS docker-based setup after watching some
presentation at ELCE 2016 in Berlin. It basically worked but I experienced
the filesystem slowness your are talking about. I ended up waiting hours to
see a simple core-image-minimal build complete (even after giving more
cores to docker). One more point is that slightly more complex build
scenarios, i.e. building resin.os, also required tweaking docker run
parameters for the build container in order to give bitbake access to
features like loop devices it needed (not always easily debuggable issues
indeed). Turned out I decided to stick with more canonical linux based
environments for the moment.

Anyway, the technology behind CROPS is *very* interesting to me, and I'd
like to hear from people closely involved (Tim?) what the state of the art
is and what we can expect to see in the near future. IIRC, the roadmap for
Yocto 2.3 release was supposed to resurrect the Eclipse plugin and adopt
CROPS as an alternative for running eSDK in a seamless way on different
development host OSs. Beside from the images on docker hub and the github
projects that didn't have high activity in the latest months, I hardly find
discussions and documentation on the whole approach. Isn't this hot enough
anymore or are there big issues that will prevent this technology from
taking off. I often manage SDKs for Windows-minded developers and I
strongly yearn to find a better approach to help them feel at home while
building stuff for OE/Yocto based systems...



> >
> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
> >
> >
> > On 12 January 2017 at 15:14, Roger Smith  wrote:
> >>
> >> Is there any documentation for running the Yocto build system on Mac OS
> X
> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
> >> Before I go down the rabbit hole of fixing issues like this one (and I
> am
> >> using the bash shell), I’d like to know if anyone has build it on os x
> >> before.
> >
> >
> > If you install all of the GNU tools using brew or similar and put them
> first
> > on $PATH then you can get bitbake started.  Then you need to stub out the
> > linux-specific bits in bitbake.  I've previously started on this work
> > already
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
> log/?h=ross/darwin).
> > The next step is figuring out how to configure OE to build and link
> natively
> > on OSX using LLVM instead of GCC.
> >
> > However all of this is mostly academic because in Sierra (iirc) onwards
> > there is tighter security on processes, which means that pseudo won't
> work
> > even if you port it to macOS.
> >
> > So unless you fancy some non-trivial engineering the short version is
> just
> > use something like Docker to run a Linux system on your Mac.
> >
> > Ross
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
> 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
> --
> ___
> 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] Building on MacOS X

[Khem Raj]

On Thu, Jan 12, 2017 at 8:21 AM, Belisko Marek  wrote:
> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>  wrote:
>> You can also build using Docker containers:
>> https://github.com/crops/docker-win-mac-docs/wiki
> Well the re is other limitation about slow filesystem access from
> docker on osx. There is workaround to use nfs but it's not possible to
> use nfs for building yocto - so it's kind of chicken-egg problem ;)

virtualbox works well unless you passionately dont want to use linux
on build host
>>
>> On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
>>
>>
>> On 12 January 2017 at 15:14, Roger Smith  wrote:
>>>
>>> Is there any documentation for running the Yocto build system on Mac OS X
>>> or macOS as Apple now calls it? I am working with the Intel Aero board.
>>> Before I go down the rabbit hole of fixing issues like this one (and I am
>>> using the bash shell), I’d like to know if anyone has build it on os x
>>> before.
>>
>>
>> If you install all of the GNU tools using brew or similar and put them first
>> on $PATH then you can get bitbake started.  Then you need to stub out the
>> linux-specific bits in bitbake.  I've previously started on this work
>> already
>> (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
>> The next step is figuring out how to configure OE to build and link natively
>> on OSX using LLVM instead of GCC.
>>
>> However all of this is mostly academic because in Sierra (iirc) onwards
>> there is tighter security on processes, which means that pseudo won't work
>> even if you port it to macOS.
>>
>> So unless you fancy some non-trivial engineering the short version is just
>> use something like Docker to run a Linux system on your Mac.
>>
>> Ross
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> 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
> --
> ___
> 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] Yocto Linux kernel 4.8 boot can't login.

[Khem Raj]

On Wed, Jan 11, 2017 at 9:48 PM, Richard Zhang  wrote:
> Starting crond: setuid: Function not implemented

Linux gained a new config option, CONFIG_MULTIUSER, that makes
support for non-root users optional. This results in a number of syscalls
being disabled setuid is one of them. set this option to 'y'
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on MacOS X

[Belisko Marek]

On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
 wrote:
> You can also build using Docker containers:
> https://github.com/crops/docker-win-mac-docs/wiki
Well the re is other limitation about slow filesystem access from
docker on osx. There is workaround to use nfs but it's not possible to
use nfs for building yocto - so it's kind of chicken-egg problem ;)
>
> On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
>
>
> On 12 January 2017 at 15:14, Roger Smith  wrote:
>>
>> Is there any documentation for running the Yocto build system on Mac OS X
>> or macOS as Apple now calls it? I am working with the Intel Aero board.
>> Before I go down the rabbit hole of fixing issues like this one (and I am
>> using the bash shell), I’d like to know if anyone has build it on os x
>> before.
>
>
> If you install all of the GNU tools using brew or similar and put them first
> on $PATH then you can get bitbake started.  Then you need to stub out the
> linux-specific bits in bitbake.  I've previously started on this work
> already
> (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
> The next step is figuring out how to configure OE to build and link natively
> on OSX using LLVM instead of GCC.
>
> However all of this is mostly academic because in Sierra (iirc) onwards
> there is tighter security on processes, which means that pseudo won't work
> even if you port it to macOS.
>
> So unless you fancy some non-trivial engineering the short version is just
> use something like Docker to run a Linux system on your Mac.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on MacOS X

[Tim Orling]

You can also build using Docker containers:
https://github.com/crops/docker-win-mac-docs/wiki 


> On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
> 
> 
> On 12 January 2017 at 15:14, Roger Smith  > wrote:
> Is there any documentation for running the Yocto build system on Mac OS X or 
> macOS as Apple now calls it? I am working with the Intel Aero board. Before I 
> go down the rabbit hole of fixing issues like this one (and I am using the 
> bash shell), I’d like to know if anyone has build it on os x before.
> 
> If you install all of the GNU tools using brew or similar and put them first 
> on $PATH then you can get bitbake started.  Then you need to stub out the 
> linux-specific bits in bitbake.  I've previously started on this work already 
> (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin 
> ). 
>  The next step is figuring out how to configure OE to build and link natively 
> on OSX using LLVM instead of GCC.
> 
> However all of this is mostly academic because in Sierra (iirc) onwards there 
> is tighter security on processes, which means that pseudo won't work even if 
> you port it to macOS.
> 
> So unless you fancy some non-trivial engineering the short version is just 
> use something like Docker to run a Linux system on your Mac.
> 
> Ross
> -- 
> ___
> 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] Building on MacOS X

[Burton, Ross]

On 12 January 2017 at 15:39, Tim Orling 
wrote:

> You can also build using Docker containers:
> https://github.com/crops/docker-win-mac-docs/wiki
>

Yes, this is the link I was failing to find, thanks Tim.  This is basically
the official way of using OE on Windows or Mac.

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

Re: [yocto] Building on MacOS X

[Mark Hatle]

On 1/12/17 9:14 AM, Roger Smith wrote:
> Is there any documentation for running the Yocto build system on Mac OS X or
> macOS as Apple now calls it? I am working with the Intel Aero board. Before I 
> go
> down the rabbit hole of fixing issues like this one (and I am using the bash
> shell), I’d like to know if anyone has build it on os x before.

As far as I am aware, nobody has ever finished this work.

There are numerous places (scripts primarily) that will expect GNU
util-linux/coreutils (and similar) extensions.

In addition, the pseudo program, used to emulate filesystem permissions and
related items only partially works on MacOS.  (I know it was working at one
point, but Apple changed some of the system properties [preloaded library] for
security reasons, and ended up making pseudo no longer work.  You may want to
look into this before getting too far in.  Without pseudo, there is no way to
perform a build/package.)

Some -very- old work:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib-archive/refs/heads

search for macosx

(I'd love to see a native bitbake/oe-core work on MacOS X... but as far as I
know the work stalled a while back due to lack of interest by people.)

Most of the people I know using MacOS X for development are using virtual box
(or similar) and a Linux based VM.

--Mark

> thanks
> 
> 
> source oe-init-build-env
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> -bash: /scripts/oe-buildenv-internal: No such file or directory
> 
> 

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

Re: [yocto] Building on MacOS X

[Burton, Ross]

On 12 January 2017 at 15:14, Roger Smith  wrote:

> Is there any documentation for running the Yocto build system on Mac OS X
> or macOS as Apple now calls it? I am working with the Intel Aero board.
> Before I go down the rabbit hole of fixing issues like this one (and I am
> using the bash shell), I’d like to know if anyone has build it on os x
> before.
>

If you install all of the GNU tools using brew or similar and put them
first on $PATH then you can get bitbake started.  Then you need to stub out
the linux-specific bits in bitbake.  I've previously started on this work
already (
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
The next step is figuring out how to configure OE to build and link
natively on OSX using LLVM instead of GCC.

However all of this is mostly academic because in Sierra (iirc) onwards
there is tighter security on processes, which means that pseudo won't work
even if you port it to macOS.

So unless you fancy some non-trivial engineering the short version is just
use something like Docker to run a Linux system on your Mac.

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

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

[Joe MacDonald]

Hi guys,

[Re: [meta-selinux] What's the point of refpolicy-minimum?] On 17.01.12 (Thu 
12:57) wenzong fan wrote:

> On 01/10/2017 10:48 PM, Joe MacDonald wrote:
> >Wenzong / Shrikant,
> >
> >I thought I knew the answer to the above question, and maybe my
> >understanding is still correct, but I think I need to ask it now anyway.
> >
> >I don't use refpolicy-minimum for anything, so when I did the updates to
> >refpolicy*_git I didn't even glance at refpolicy-minimum_git.  Wenzong's
> >change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
> >of the recipe) piqued my curiosity, so I had a look.  Of course,
> >refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
> >now that I'm looking at the recipe I see what seems like conflicting
> >statements in the recipe:
> >
> >   recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:
> >
> > 1 include refpolicy-targeted_${PV}.bb
> > 2
> > 3 SUMMARY = "SELinux minimum policy"
> > 4 DESCRIPTION = "\
> > 5 This is a minimum reference policy with just core policy modules, and 
> > \
> > 6 could be used as a base for customizing targeted policy. \
> > 7 Pretty much everything runs as initrc_t or unconfined_t so all of the 
> > \
> > 8 domains are unconfined. \
> > 9 "
> >
> >and:
> >
> >   recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:
> >
> > 1 SUMMARY = "SELinux targeted policy"
> > 2 DESCRIPTION = "\
> > 3 This is the targeted variant of the SELinux reference policy.  Most 
> > service \
> > 4 domains are locked down. Users and admins will login in with 
> > unconfined_t \
> > 5 domain, so they have the same access to the system as if SELinux was 
> > not \
> > 6 enabled. \
> > 7 "
> >
> >So now I'm trying to understand what the point of refpolicy-minimum
> >really is here.  Those of you who are using it, what are you using it
> >for and what do you expect would be the correct behaviour of a system
> >running that policy?
> >
> 
> I don't have much experience on using the refpolicy-minimum as well.
> 
> But from the original logs it should be "minimum targeted policy".
> 
> commit 65675f02e33f5da31ec5dbac7a45849f4952569b
> Author: Wenzong Fan 
> Date:   Mon Mar 24 21:07:50 2014 -0400
> 
> refpolicy: add minimum targeted policy
> 
> This is a minimum targeted policy with just core policy modules, and
> could be used as a base for customizing targeted policy.
> Pretty much everything runs as initrc_t or unconfined_t so all of the
> domains are unconfined.
> 
> Signed-off-by: Wenzong Fan 
> Signed-off-by: Joe MacDonald 
> 
> 
> >At the very least, I'm going to remove the 'include [...].bb' from both
> >'minimum' recipes, as that's completely incorrect, but when I do that I
> >want to know what anyone using this recipe wants to see from it, so
> >whatever the 'include' gets replaced with is doing the right thing
> >(which isn't necessarily what it's doing today).
> 
> I won't object to make the changes, if you think there should be a different
> minimum policy with targeted.

I'm not proposing an alternative, I'm just saying that the statements in
the descriptions of the recipes seem to conflict.  (And do note that the
git log you quoted is precisely the text in DESCRIPTION for
refpolicy-minimum.

What I'm confused by is this in minimum:

> Pretty much everything runs as initrc_t or unconfined_t so all of the
> domains are unconfined.

and this in targeted:

> > Most service domains are locked down.

So I guess my question is what is the desired behaviour out of this
recipe?  If nobody knows and it's not being used, I'm leaning toward a
'git rm'-based solution.  :-)

It sounds, though, like Shrikant is using it, so it's of some use, I
guess.  Shrikant, on the systems you've used the minimum policy, what
does the policy look like on your running system?  In the current world
refpolicy-minimum inherits POLICY_TYPE and POLICY_MLS_SENS from
refpolicy-targeted, is that good / bad / irrelevant to what you're doing
with it?  If I just rework minimum to remove the include and bring in
the minimal number of changes to get the policy to load again, is that
good enough for your purposes?  Do you want to volunteer to test my
changes for me before I commit them?  :-)

-- 
-Joe MacDonald.
:wq


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

[yocto] Building on MacOS X

[Roger Smith]

Is there any documentation for running the Yocto build system on Mac OS X or 
macOS as Apple now calls it? I am working with the Intel Aero board. Before I 
go down the rabbit hole of fixing issues like this one (and I am using the bash 
shell), I’d like to know if anyone has build it on os x before.

thanks


source oe-init-build-env
readlink: illegal option -- f
usage: readlink [-n] [file ...]
-bash: /scripts/oe-buildenv-internal: No such file or directory-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] OpenEmbedded Developers Meeting in Portland before ELC

[Hudson, Sean]

Paul,

  It's a great point.  I have volunteered Mentor's teleconference, but the 
onsite pickup is always a challenge.  Once we've finalized the location, I'll 
focus on making sure that we have a high quality pickup(s) in the room.  If 
possible, I'll get a true video-conference setup.

--
Sean


> -Original Message-
> From: openembedded-architecture-boun...@lists.openembedded.org
> [mailto:openembedded-architecture-boun...@lists.openembedded.org] On
> Behalf Of Paul Eggleton
> Sent: Wednesday, January 11, 2017 07:47 PM
> To: Philip Balister 
> Cc: yocto@yoctoproject.org; openembedded-
> memb...@lists.openembedded.org; openembedded-architecture
> ; openembedded-
> de...@lists.openembedded.org; openembedded-core  c...@lists.openembedded.org>
> Subject: Re: [Openembedded-architecture] [yocto] OpenEmbedded Developers
> Meeting in Portland before ELC
> 
> On Mon, 09 Jan 2017 16:04:57 Philip Balister wrote:
> > As we do around each Embedded Linux Conference, OpenEmbedded will
> host a
> > developer meeting to discuss the state of OpenEmbedded and what efforts
> > we should focus on over the next six months or so.
> >
> > All developers and users are welcome to attend. We like to hear feedback
> > from a variety of people over what works, doesn't work, and is useful to
> > people using OpenEmbedded for all sort of applications.
> >
> > The meeting will be held Monday, Feb 20 at a location we can almost
> > announce. Based on prior years, the meeting will run from 9AM to 5PM.
> >
> > If you are going to attend add your name to:
> >
> > http://openembedded.org/wiki/OEDAM_2017
> >
> > Also, go ahead and add ideas for the agenda. We'll organize them better
> > just before the actual meeting.
> 
> So it's great that this is happening, but unfortunately I'm not going to be
> able to make it to this one, and I suspect there will be many others who would
> like to participate but can't be present in person. In previous meetings we
> have really struggled with practical means for remote participation. I don't
> expect effective real-time two-way communication, but last time the audio
> was
> so poor I wasn't even able to hear what was being said.
> 
> Is there a chance that given advance notice we will be able to set something
> up that could improve this?
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sstate pruning

[Burton, Ross]

On 12 January 2017 at 13:38, Gary Thomas  wrote:

> Any constructive ideas for cleaning out a ver long standing
> sstate cache?  I have one build tree that is now approaching
> a year old (I do builds there all the time, sometimes many
> times per day).  The sstate-cache is HUGE.  Any ideas on
> how I can purge/cleanup?  Note: 'atime' is probably not
> useful as I have copied the whole thing a few times...
>
> $ du -s /build/p0382_2016-01-13/sstate-cache/
> 186576060   /build/p0382_2016-01-13/sstate-cache/
>

The usual way would be atime, so if you can remember when it was last moved
then anything that hasn't been touched since is obviously deletable.

The alternative would be to just delete it and then do a set of builds for
all your combinations that you care about, after all it's just a cache.

Also, that's not huge:

$ du -s /data/poky-master/sstate/
1.2T /data/poky-master/sstate/

:)

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

Re: [yocto] sstate pruning

[André Draszik]

On Thu, 2017-01-12 at 14:38 +0100, Gary Thomas wrote:
> Any constructive ideas for cleaning out a ver long standing
> sstate cache?  I have one build tree that is now approaching
> a year old (I do builds there all the time, sometimes many
> times per day).  The sstate-cache is HUGE.  Any ideas on
> how I can purge/cleanup?  Note: 'atime' is probably not
> useful as I have copied the whole thing a few times...
> 
> $ du -s /build/p0382_2016-01-13/sstate-cache/
> 186576060   /build/p0382_2016-01-13/sstate-cache/
> 
> Thanks for any input

poky/scripts/sstate-cache-management.sh -h

:-)

A.

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

[yocto] sstate pruning

[Gary Thomas]

Any constructive ideas for cleaning out a ver long standing
sstate cache?  I have one build tree that is now approaching
a year old (I do builds there all the time, sometimes many
times per day).  The sstate-cache is HUGE.  Any ideas on
how I can purge/cleanup?  Note: 'atime' is probably not
useful as I have copied the whole thing a few times...

$ du -s /build/p0382_2016-01-13/sstate-cache/
186576060   /build/p0382_2016-01-13/sstate-cache/

Thanks for any input

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Confusing error

[Gary Thomas]

On 2017-01-12 11:19, Gary Thomas wrote:

Lately I've been seeing errors like these:

ERROR: When reparsing 
/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install,
 the
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to 
f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not
deterministic and this needs to be fixed.
ERROR: When reparsing 
/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install,
 the
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to 
f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not
deterministic and this needs to be fixed.
ERROR: When reparsing 
/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install,
 the
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to 
f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not
deterministic and this needs to be fixed.
WARNING: u-boot-fw-utils-2011.06-r1 do_package_qa: QA Issue: No GNU_HASH in the 
elf binary:
'/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_printenv'

No GNU_HASH in the elf binary:
'/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_setenv'
[ldflags]


Sorry, ignore this error (overly ambitious cut).  My question for this
thread it just about the metadata errors...


ERROR: When reparsing 
/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install,
 the
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to 
f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not
deterministic and this needs to be fixed.

I'm not sure what triggers these errors - I do have more than
one bitbake build running (separate directories).  I have a local
copy of the metadata and it was not touched during these builds.

I'm using Poky/Yocto rev 840e221ea7c35177fda37af618c4727fa7754789
but I've seen them for a couple of months now.

Ideas?

Thanks




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Confusing error

[Gary Thomas]

Lately I've been seeing errors like these:

ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the 
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not 
deterministic and this needs to be fixed.
ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the 
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not 
deterministic and this needs to be fixed.
ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the 
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not 
deterministic and this needs to be fixed.
WARNING: u-boot-fw-utils-2011.06-r1 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 
'/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_printenv'
No GNU_HASH in the elf binary: 
'/build/p7619_2016-02-23/tmp/work/teton_p7620-amltd-linux-gnueabi/u-boot-fw-utils/2011.06-r1/packages-split/u-boot-fw-utils/sbin/fw_setenv' 
[ldflags]
ERROR: When reparsing /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install, the 
basehash value changed from 9505eae6877992fa6b9e3148cf3752eb to f19b1f7c30c515ab9ef905f96b6eaa5e. The metadata is not 
deterministic and this needs to be fixed.


I'm not sure what triggers these errors - I do have more than
one bitbake build running (separate directories).  I have a local
copy of the metadata and it was not touched during these builds.

I'm using Poky/Yocto rev 840e221ea7c35177fda37af618c4727fa7754789
but I've seen them for a couple of months now.

Ideas?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Release Candidate Build for yocto-2.2.1.rc1 now available.

[Poky Build User]

A release candidate build for yocto-2.2.1.rc1 is now available at:


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


Please begin QA on this build as soon as possible.


Build hash information: 
meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 
meta-intel : 0c42b70b33d0c7524dd71f9c40c47316fb548bbc 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
poky : 4b8ddc432273cca1d8580de22c2078b96973a737 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: joshua.g.l...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto