[yocto] is there a rationale for YP using sysvinit as default init manager?

[Robert P. J. Day]

  don't get me wrong, i have no problem with that, but a colleague
asked me what the reason was for using sysvinit as the *default*. i
hemmed and hawed and suggested it was for simplicity and reliability,
and that a lot of embedded systems didn't need the flashy features of
systemd, and so on.

  is there any short answer to give to that question?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] how to generate an SPDX "notice file" from a build?

[Robert P. J. Day]

  colleague just asked how to generate an SPDX license "notice file"
(whatever that is) from a build for a zynq ultrascale+ board, which
shouldn't be hard other than that:

 1) it's not pure YP, it's petalinux
 2) petalinux is being driven by a docker build container

so it may be that one or the other of the above is causing side
effects.

  in any event, i already pointed out how YP automatically generates
all the license info on a per-recipe basis, but there is apparently
some fancier format of SPDX output, so after a few seconds inspection,
i stumbled over the spdx.bbclass file. i added the line:

  INHERIT += "spdx"

to the petalinux version of local.conf, started the build, and noticed
numerous error messages of the form:

  SPDX: Could not set up required directories ... /home/yocto

which i'm *guessing* is due to the docker container having some
default idea of where output files are supposed to go.

  in any event, if the above had worked, what would i have seen and
where would i have seen it?

  more to the point, as i did more research, i noticed a number of
things related to collecting licensing info, such as a
meta-spdxscanner layer, and something called DoSOCSv2, of which i know
nothing.

  anyway, what is the simplest way to generate said "notice file", if
there is a formal definition of such a thing? i'll try that this
evening on a pure YP build just to verify proper operation before
trying to cram it into petalinux.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Defining group of machines

[Robert P. J. Day]

On Fri, 3 May 2019, Robert P. J. Day wrote:

> On Fri, 3 May 2019, Westermann, Oliver wrote:
>
> > We’ve a product group with different devices, each having their
> > machine-conf, eg
> >
> > Device_a
> >
> > Device_a_mini
> >
> > Device_b
> >
> > Device_b_mini <- Upcoming
> >
> > Device_c <- Upcoming
> >
> > Since device_a and device_a_mini share a lot of code, for them we
> > use one of the machine overrides, describing the processor family,
> > so I use RDEPENDS_${PN}_append_device_a if I just need it for
> > device_a and RDEPENDS_${PN}_append_am57x for device_a and
> > device_a_mini.
> >
> > Now I’m in the situation that device_c will use the same CPU as
> > device b, so I need something like a “group” of devices for family
> > b.
> >
> > How can I define a MACHINE_GROUP_device_b_group = “device_b
> > device_b_mini” so I can do
> >
> > RDEPENDS_${PN}_append_device_b_group or
> > do_install_append_device_b_group()?
>
>   i know i did this once upon a time using the MACHINEOVERRIDES
> variable to "insert" a machine family into the sequence of machine
> definitions. as long as there is (i believe) a strictly hierarchical
> grouping of machines you want to define, i'm pretty sure
> MACHINEOVERRIDES is what you want.
>
>   let me see if i can find where i did that once.

  yeah, i'm pretty sure you want MACHINEOVERRIDES:

https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-MACHINEOVERRIDES

which has a nice example of how to invent a new "machine" category
(qemuall) that subsumes a number of actual qemu machines. is that what
you were after?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Defining group of machines

[Robert P. J. Day]

On Fri, 3 May 2019, Westermann, Oliver wrote:

> We’ve a product group with different devices, each having their
> machine-conf, eg
>
> Device_a
>
> Device_a_mini
>
> Device_b
>
> Device_b_mini <- Upcoming
>
> Device_c <- Upcoming
>
> Since device_a and device_a_mini share a lot of code, for them we
> use one of the machine overrides, describing the processor family,
> so I use RDEPENDS_${PN}_append_device_a if I just need it for
> device_a and RDEPENDS_${PN}_append_am57x for device_a and
> device_a_mini.
>
> Now I’m in the situation that device_c will use the same CPU as
> device b, so I need something like a “group” of devices for family
> b.
>
> How can I define a MACHINE_GROUP_device_b_group = “device_b
> device_b_mini” so I can do
>
> RDEPENDS_${PN}_append_device_b_group or
> do_install_append_device_b_group()?

  i know i did this once upon a time using the MACHINEOVERRIDES
variable to "insert" a machine family into the sequence of machine
definitions. as long as there is (i believe) a strictly hierarchical
grouping of machines you want to define, i'm pretty sure
MACHINEOVERRIDES is what you want.

  let me see if i can find where i did that once.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Robert P. J. Day]

On Thu, 25 Apr 2019, Richard Purdie wrote:

> On Thu, 2019-04-25 at 08:05 -0400, Robert P. J. Day wrote:

> > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> > native/3.12.2-r0/build/Bootstrap.cmk/cmake:
> > /home/rpjday/oe/builds/zedboard/tmp/sysroots-uninative/x86_64-
> > linux/usr/lib/libstdc++.so.6:
> > version `GLIBCXX_3.4.26' not found (required by
> > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> > native/3.12.2-r0/build/Bootstrap.cmk/cmake)
> > > -
> > > Error when bootstrapping CMake:
> > > Problem while running initial CMake
> > > -
>
> This probably means that your system c library is newer than the one
> in uninative and things aren't working because of that. Either try:
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5f6156b32c9d17bdb06d67199373433b0e470cc7

  that patch is already in thud branch of poky i'm using ...

> or turning off uninative.

  yes, that seems to have solved things for now:

INHERIT_remove = "uninative"

moving on to the next head-scratcher ...

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[Robert P. J. Day]

On Thu, 2 May 2019, Scott Rifenbark wrote:

> Great, thanks!
>
> On Thu, May 2, 2019 at 11:21 AM akuster  wrote:
>
>
>   On 5/2/19 10:45 AM, Scott Rifenbark wrote:
>   The term "Container Layer" was put in the ref-manual by me to describe a
>   "meta-*" layer that had other "meta-*" layers (see
>   
> https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
>   and the term "Container Layer").  Maybe this was never a good term?  I 
> don't
>   know.  Nobody has said anything about that term for many releases. 
>
> The problem Robert points out needs to be fixed in the BSP manual as 
> "meta-intel" is
> not longer qualifying by my definition.  I can fix that. 
>
> Is "Container Layer" ok as I have defined it?
>
> in those terms above, yes its fine.

  the more i think about it, the more i'm nervous about the phrase
"container layer", as it suggests a "layer" of some kind in the
context of OE. the one distinction i think worth making is that a "BSP
layer" is a layer expressly designed to support identified target
systems (eg., meta-xilinx-bsp), while a non-BSP layer simply packages
functionality (recipes, classes) -- a good example is
meta-virtualization.

  in either case, the trivial property of an OE layer is something
that can be specified in a bblayers.conf file. so i'm not sure *how*
you would describe, for example, meta-openembedded.

  i'm sure i'm overthinking this.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[Robert P. J. Day]

On Thu, 2 May 2019, Scott Rifenbark wrote:

> Great, thanks!
>
> On Thu, May 2, 2019 at 11:21 AM akuster  wrote:
>
>   On 5/2/19 6:19 AM, Robert P. J. Day wrote:
>   > As meta-intel is no longer a container layer, use meta-xilinx as
>   > an example instead.
>
>   I thought "meta-virtualization" was a container layer?

  as a followup, i would think that "meta-openembedded" is the
canonical example of a container layer, no?

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[Robert P. J. Day]

  much snipping ...

On Thu, 2 May 2019, Scott Rifenbark wrote:

> On Thu, May 2, 2019 at 10:21 AM akuster  wrote:
>
>
>   On 5/2/19 6:19 AM, Robert P. J. Day wrote:
>   > As meta-intel is no longer a container layer, use meta-xilinx as
>   > an example instead.
>
>   I thought "meta-virtualization" was a container layer?

  uh, i'm looking at meta-virtualization right now:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/

and that looks like a regular BSP layer, not a container layer. am i
misunderstanding some fundamental point here?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Robert P. J. Day]

On Thu, 25 Apr 2019, Richard Purdie wrote:

> On Thu, 2019-04-25 at 08:05 -0400, Robert P. J. Day wrote:

... snip ...

> >   ASSUME_PROVIDED += "cmake-native"
>
> This is a bad idea as we patch cmake iirc.

... snip ...
>
> You would also have to do:
>
> HOSTTOOLS += "cmake"
>
> to allow cmake to be visible from the host system. Its a host
> contamination protection mechanisn that has been there since pyro.

  just to summarize, if one wanted to (perhaps injudiciously) take
advantage of host tools, that requires:

1) ASSUME_PROVIDED to specify the native package that no longer needs
   to be built, and

2) HOSTTOOLS to identify the binary (or binaries) that can be picked
   up from the host

  i can see an obvious example here:

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

but if this is the case, then it seems that the YP reference manual
should be clarified to explain the association between these
variables. for example, the current ref manual reads:

  ASSUME_PROVIDED

  Lists recipe names (PN values) BitBake does not attempt to build.
  Instead, BitBake assumes these recipes have already been built.

  In OpenEmbedded-Core, ASSUME_PROVIDED mostly specifies native
  tools that should not be built. An example is git-native, which when
  specified, allows for the Git binary from the host to be used rather
  than building git-native.

reading that, a reader would not realize the necessity(?) of setting
HOSTTOOLS, yes?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] "meta-intel" layer bad example of a "container layer"

[Robert P. J. Day]

  catching up with all the YP stuff i've missed over the last while
and, in the BSP guide in the layers section:

https://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers

one reads:

"Some layers function as a layer to hold other BSP layers. These
layers are knows as "container layers". An example of this type of
layer is the meta-intel layer. This layer contains BSP layers for the
Intel-core2-32 Intel® Common Core (Intel-core2-32) and the
Intel-corei7-64 Intel® Common Core (Intel-corei7-64). the meta-intel
layer also contains the common/ directory, which contains common
content across those layers. "

  pretty sure meta-intel has been a regular BSP layer for a while now,
so another example should be used. off the top of my head, i'd suggest
meta-xilinx:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/

unless anyone has strong objections, i can send in a patch.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Robert P. J. Day]

On Thu, 25 Apr 2019, Richard Purdie wrote:

   ... big snip of warning me about what i'm trying to do ...

> This is a bad idea and you're on a path to madness ;-)

  i already knew that ... i did admit i've been out of YP for a while
and have a lot of catching up to do. i suspect my next few days will
be full of reading.

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Robert P. J. Day]

On Thu, 25 Apr 2019, Bach, Pascal wrote:

> rday wrote:

> >   finally, regarding ASSUME_PROVIDED, given that i'm already
> > living life dangerously with an unsupported distro, is there any
> > harm in just loading up on ASSUME_PROVIDED packages, as long as
> > they work? in many cases, i can see that the version that would be
> > built by YP is close to, if not identical to, my host version. so
> > other than risking breakage down the line as versions change, as
> > long as the host packages work, is there any harm in just taking
> > advantage of them?
>
> Generally it's fine to use ASSUME_PROVIDED if you don't mind the
> dependency between the build host and Yocto.

  as i mentioned, i'm already living life on the edge doing all this
on fedora 30 branched (the unofficial next release), so i'm quite
prepared to trip over versioning issues, and testing all this against
F30 at least warns me about upcoming issues that i might be able to do
bug reports or patches against ahead of time.

  and it's easy to see there's a *ton* of packages i can assume
natively that should be fairly safe; in many cases, the version that
would be built by YP is exactly the same version i already have
natively. in other cases, the difference might be a micro-version off.

  anyway, i probably wouldn't have bothered with this if it weren't
for that cmake issue. but let's see where this goes.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Robert P. J. Day]

On Thu, 25 Apr 2019, Bach, Pascal wrote:

> >   currently trying to build a "core-image-minimal" for a zedboard on my
> > wholly unsupported fedora 30 (branched) system, so i'm well aware there
> > will almost certainly be breakage as i try to resolve version numbers and so
> > on, but working off the "thud" branch, the first issue i had was trying to
> > configure cmake-native -- the error message is exactly what you can read
> > someone asking about here:
> >
> > https://stackoverflow.com/questions/52663287/glibcxx-3-4-26-not-found
> >
> > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> > native/3.12.2-r0/build/Bootstrap.cmk/cmake:
> > /home/rpjday/oe/builds/zedboard/tmp/sysroots-uninative/x86_64-
> > linux/usr/lib/libstdc++.so.6:
> > version `GLIBCXX_3.4.26' not found (required by
> > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> > native/3.12.2-r0/build/Bootstrap.cmk/cmake)
> > | -
> > | Error when bootstrapping CMake:
> > | Problem while running initial CMake
> > | -
> >
> >   i'm unsure how to resolve that easily, but my first reaction
> > was, "if i already have cmake installed on the host, why not just
> > take advantage of ASSUME_PROVIDED"? i recall from some time back
> > asking why more host utils were not, by default, included in
> > ASSUME_PROVIDED, and the answer (quite reasonably) was that one
> > wants to have as few variables as possible for reliably replicated
> > builds.
> >
> >   fair enough, but in my case, until i figure out how to fix that,
> > i thought, why not just:
> >
> >   ASSUME_PROVIDED += "cmake-native"
> >
> > so i did, and that got me past the cmake-native build issue, until
> > i hit this trying to build libsolv-native:
> >
> > DEBUG: Executing shell function do_configure
> > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/libsolv-
> > native/0.6.35-r0/temp/run.do_configure.16705:
> > line 130: cmake: command not found
> >
> >   hang on ... why would a subsequent recipe not be able to locate
> > /usr/bin/cmake on my host after i explicitly identified
> > cmake-native as assumed to be provided? is there something about
> > the libsolv-native recipe that does not take that possibility into
> > account? i'm just about to check, but if someone has an
> > explanation for that, i'm all ears.
>
> There is an issue that CMake is not able to find binaries in
> hosttools. It might be the case that this is the issue you are
> seeing.
>
> I submitted a patch for that but I'm not sure it Ever made it into
> master or a release. I need to follow up on this, the patch is here:
> https://patchwork.openembedded.org/series/14429/#

  that *sort of* sounds like what is happening, but to be pedantic,
it's not that cmake can't find binaries in hosttools, it's that
*other* packages can't locate cmake on the host even after setting

  ASSUME_PROVIDED += "cmake-native"

i am assuming that whatever search path is used for "native" tools is
extended by the use of ASSUME_PROVIDED -- is that what your patch is
addressing? in any event, i've now run into a couple other packages
with the same issue -- "cmake: command not found" -- libcomps-native
and librepo-native, so i'll just ASSUME_PROVIDED them too for the
moment, as they're both installed on my host.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Robert P. J. Day]

  (warning: i've been away from YP for well over a year and am now
studiously trying to catch up, so i have some work to do.)

  currently trying to build a "core-image-minimal" for a zedboard on
my wholly unsupported fedora 30 (branched) system, so i'm well aware
there will almost certainly be breakage as i try to resolve version
numbers and so on, but working off the "thud" branch, the first issue
i had was trying to configure cmake-native -- the error message is
exactly what you can read someone asking about here:

https://stackoverflow.com/questions/52663287/glibcxx-3-4-26-not-found

/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-native/3.12.2-r0/build/Bootstrap.cmk/cmake:
/home/rpjday/oe/builds/zedboard/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6:
version `GLIBCXX_3.4.26' not found (required by
/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-native/3.12.2-r0/build/Bootstrap.cmk/cmake)
| -
| Error when bootstrapping CMake:
| Problem while running initial CMake
| -

  i'm unsure how to resolve that easily, but my first reaction was,
"if i already have cmake installed on the host, why not just take
advantage of ASSUME_PROVIDED"? i recall from some time back asking why
more host utils were not, by default, included in ASSUME_PROVIDED, and
the answer (quite reasonably) was that one wants to have as few
variables as possible for reliably replicated builds.

  fair enough, but in my case, until i figure out how to fix that, i
thought, why not just:

  ASSUME_PROVIDED += "cmake-native"

so i did, and that got me past the cmake-native build issue, until i
hit this trying to build libsolv-native:

DEBUG: Executing shell function do_configure
/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/libsolv-native/0.6.35-r0/temp/run.do_configure.16705:
line 130: cmake: command not found

  hang on ... why would a subsequent recipe not be able to locate
/usr/bin/cmake on my host after i explicitly identified cmake-native
as assumed to be provided? is there something about the libsolv-native
recipe that does not take that possibility into account? i'm just
about to check, but if someone has an explanation for that, i'm
all ears.

  finally, regarding ASSUME_PROVIDED, given that i'm already living
life dangerously with an unsupported distro, is there any harm in just
loading up on ASSUME_PROVIDED packages, as long as they work? in many
cases, i can see that the version that would be built by YP is close
to, if not identical to, my host version. so other than risking
breakage down the line as versions change, as long as the host
packages work, is there any harm in just taking advantage of them?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] m4-mative: "Please port gnulib fseeko.c to your platform!"

[Robert P. J. Day]

On Tue, 9 Apr 2019, Burton, Ross wrote:

> On Tue, 9 Apr 2019 at 11:14, Robert P. J. Day  wrote:
> >   so, to confirm what i thought, this is a bug in gnulib which
> > suggests i should dig through the build configuration to see where i
> > can, say, set a PREFERRED_VERSION of a newer version of gnulib that
> > no longer has tat bug? or, barring that, just add the appropriate
> > local patch on my end.
>
> No, gnulib is a copy/paste library.  The bug was fixed in gnulib, and
> new releases of m4 are fixed, but you'll need to cherry-pick the fix
> from oe-core master (we apply the patch to our m4 recipe) back to
> whatever stable branch you're using.

  ah, got it, thanks.

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

Re: [yocto] m4-mative: "Please port gnulib fseeko.c to your platform!"

[Robert P. J. Day]

On Mon, 8 Apr 2019, Burton, Ross wrote:

> Looks like that bug in gnulib that broke m4 (and others) when glibc
> changed.
>
> Fixed upstream
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a718
> and oe-core master/thud/possibly sumo also carry the relevant patch
> for m4.
>
> If you're using older releases against a newer release then 1) this
> is why we have supported host distros and 2) the patch is easy to
> backport.

  so, to confirm what i thought, this is a bug in gnulib which
suggests i should dig through the build configuration to see where i
can, say, set a PREFERRED_VERSION of a newer version of gnulib that
no longer has tat bug? or, barring that, just add the appropriate
local patch on my end.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] m4-mative: "Please port gnulib fseeko.c to your platform!"

[Robert P. J. Day]

  a few months ago, i ran into (and asked about) a failure building
m4-native that you can read here:

https://yocto.yoctoproject.narkive.com/6KyM5UvS/m4-native-zedboard-please-port-gnulib-fseeko-c-to-your-platform

first, i will admit i'm not sure where the fault lies -- is it m4, or
gnulib, or glibc, and whose responsibility is it to fix what. i'll be
honest -- i don't understand what the bug is or who should be
resolving it.

  i ask all this as i just had *exactly* the same error trying to
build agl-image-minimal with the AGL code base. what is the proper
solution to this? BTW, i'm trying this on fedora 30 branched, so this
is definitely not a supported build distro, but i'm still curious as
to what would be the proper fix.

  finally, it occurs to me that, if building a native package like
"m4" fails, would it be a reasonable workaround to simply say

  ASSUME_PROVIDED += "m4"

for the time being, to avoid having to build it until i know what the
proper fix is?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] m4-mative: "Please port gnulib fseeko.c to your platform!"

[Robert P. J. Day]

On Mon, 8 Apr 2019, Robert P. J. Day wrote:

>
>   a few months ago, i ran into (and asked about) a failure building
> m4-native that you can read here:
>
> https://yocto.yoctoproject.narkive.com/6KyM5UvS/m4-native-zedboard-please-port-gnulib-fseeko-c-to-your-platform
>
> first, i will admit i'm not sure where the fault lies -- is it m4, or
> gnulib, or glibc, and whose responsibility is it to fix what. i'll be
> honest -- i don't understand what the bug is or who should be
> resolving it.
>
>   i ask all this as i just had *exactly* the same error trying to
> build agl-image-minimal with the AGL code base. what is the proper
> solution to this? BTW, i'm trying this on fedora 30 branched, so this
> is definitely not a supported build distro, but i'm still curious as
> to what would be the proper fix.
>
>   finally, it occurs to me that, if building a native package like
> "m4" fails, would it be a reasonable workaround to simply say
>
>   ASSUME_PROVIDED += "m4"
>
> for the time being, to avoid having to build it until i know what the
> proper fix is?

  trying ASSUME_PROVIDED didn't work all that well, either ...

...
| autom4te: need GNU m4 1.4 or later: m4
| make[2]: *** [Makefile:641: autoconf.in] Error 1
...

  that's just weird as my installed version of m4 is 1.4.18, precisely
the version AGL is trying to build. i'm confused.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] m4-native, zedboard, "Please port gnulib fseeko.c to your platform"

[Robert P. J. Day]

  been away from YP for a few months, diving back in, want to build a
core-image-minimal for my zedboard, and i will first admit that i'm
using a non-approved distro (fully-updated fedora 29):

"WARNING: Host distribution "fedora-29" 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."

  no matter, i will live dangerously. but then things take an ugly
turn:

"WARNING: Your host glibc verson (2.28) is newer than that in
uninative (2.27). Disabling uninative so that sstate is not
corrupted."

  ok, let's see how far we get ... and that's here, trying to compile
m4-native:

| gcc   -I. -I../../m4-1.4.18/lib
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-O2 -pipe -c -o freadahead.o ../../m4-1.4.18/lib/freadahead.c
| gcc   -I. -I../../m4-1.4.18/lib
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-isystem/home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/include
-O2 -pipe -c -o fseeko.o ../../m4-1.4.18/lib/fseeko.c
| ../../m4-1.4.18/lib/freadahead.c: In function ‘freadahead’:
| ../../m4-1.4.18/lib/fseeko.c: In function ‘rpl_fseeko’:
| ../../m4-1.4.18/lib/freadahead.c:92:3: error: #error "Please port
gnulib freadahead.c to your platform! Look at the definition of
fflush, fread, ungetc on your system, then report this to bug-gnulib."
|   #error "Please port gnulib freadahead.c to your platform! Look at
the definition of fflush, fread, ungetc on your system, then report
this to bug-gnulib."
|^
| ../../m4-1.4.18/lib/fseeko.c:110:4: error: #error "Please port
gnulib fseeko.c to your platform! Look at the code in fseeko.c, then
report this to bug-gnulib."
|#error "Please port gnulib fseeko.c to your platform! Look at the
code in fseeko.c, then report this to bug-gnulib."


and so on. red hat's bugzilla has an entry for just this:

https://bugzilla.redhat.com/show_bug.cgi?id=1595702

but i'm unsure (read, have no clue) how to deal with this, and i
suspect it affects more targets than just zedboard which is why i'm
asking on the general YP list.

  thoughts? is there a cheap fix for this? i'm about to dive into
debugging this, but if someone wants to make my life easy, that'd be
great.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bbappend extra SRC_URI ignored

[Robert P. J. Day]

On Thu, 14 Jun 2018, Damien LEFEVRE wrote:

> HI,
> I'm working on meta-tegra layer and I'd like to append a recipe. The original 
> recipe looks like
> this:
> https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-t
> ools_28.2.0.bb 
>
> I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG 
> DEFAULT from 2 to 3 to
> get max performance in nvpmodel.conf configuration file.
>
> ```
> FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
> SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "

  why are you using both a prepend and the "+=" operator on the same
line?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Robert P. J. Day]

On Fri, 16 Mar 2018, Giordon Stark wrote:

> Right, so the problem for me is that there seems to be two ways to
> do this: MACHINEOVERRIDES .= ":machine3" (for 3a, 3b)
>
> or
>
> FILESEXTRAPATHS_append_machine3a = "${THISDIR}/files/machine3/"
> FILESEXTRAPATHS_append_machine3b = "${THISDIR}/files/machine3/"
>
> But it's not clear to me which is better or fits with the
> philosophy of yocto/bitbake.

  i used something like this once upon a time, can't remember where i
wrote it up, but i asked about it in some detail back here:

https://lists.yoctoproject.org/pipermail/yocto/2016-March/028923.html

perhaps someone can verify if i made any sense back then.

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

Re: [yocto] Can SRC_URI look in the same place for two different machines?

[Robert P. J. Day]

On Fri, 16 Mar 2018, Burton, Ross wrote:

> On 15 March 2018 at 14:07, Giordon Stark  wrote:
>   So for my device trees, I'm finding some files are duplicated. In 
> particular some of my
>   dtsi files are going to be the same amongst a few boards we're using, 
> so I would like
>   to have each machine name distinct so that 
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> files/${MACHINE}/${MACHINE}.dts
>
> is picked up, while still having
>
> files/common/*.dtsi picked up as well. As an example of my SRC_URI appends:
>
> SRC_URI_append_gfex-prototype1b = " \
>     file://skeleton.dtsi  \
>     file://pl.dtsi        \
>     file://zynq-7000.dtsi \
>     file://system.dts     \
> "
>
> SRC_URI_append_gfex-prototype2  = " \
>     file://skeleton.dtsi   \
>     file://pl.dtsi         \
>     file://zynq-7000.dtsi  \
>     file://system.dts      \
> "
>
> I suspect I do something with OVERRIDES in the
> conf/machine/${MACHINE}.conf file but not sure...
>
>
> Can't you just put common files in files/file.dtsi and then the
> machine-specific ones in files/[machine]/?

  isn't this precisely what MACHINEOVERRIDES is for?

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

Re: [yocto] OpenCV with python3

[Robert P. J. Day]

On Thu, 15 Mar 2018, Peter Balazovic wrote:

> Hello all,
> I have python module of OpenCV for python 2.7 on my Yocto image adding via 
> local.conf
>
> IMAGE_INSTALL_append += “ python-opencv”

  i know i've harped on this before, but can people please stop
combining the constructs "_append" and "+=" in the same expression?

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

Re: [yocto] bitbake: git and patch problem

[Robert P. J. Day]

On Mon, 5 Mar 2018, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote:

> I'm experiencing strange (at least to my eyes) behaviour from
> bitbake. My recipe specifies a git repository as the main SRC_URI,
> then, in a variant created using an append file adds a patch like
> this:
>
> SRC_URI_append_mystuff += "file://mystuff.patch"

  pretty sure you don't need both "_append" and "+=" in the same
assignment.

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

Re: [yocto] which is the official(?) OE/YP openbmc layer?

[Robert P. J. Day]

On Thu, 21 Sep 2017, Burton, Ross wrote:

> On 21 September 2017 at 11:01, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>     colleague just yesterday asked me a couple questions about openbmc,
>   so i investigated the OE/YP layer, and i'm a bit confused ... the
>   official OE layers page here:
>
>   https://layers.openembedded.org/layerindex/branch/master/layers/
>
>   refers to a meta-openbmc layer at https://github.com/facebook/openbmc,
>   implying it's a facebook project, but github also hosts:
>
>   https://github.com/openbmc
>
>     can anyone clarify the relationship between those two? if there is
>   any?
>
>
> Oh I really hope that isn't a Google/IBM vs Facebook fork war.
>
> I think the best way to get an answer is to email both
> maintainers...

  for curiosity's sake, i spent a few minutes ignoring the apparent
facebook fork and concentrated strictly on the top-level
github/openbmc content, and it seems amazingly convoluted.  starting
here:

  https://github.com/openbmc

i further checked out the next-level openbmc/openbmc git repo and,
holy mackinaw, it contains a ton of layers.

  ignoring all of the symlinked layers for regular OE/YP content
contained therein, one sees, from the top of that clone, all of the
following "layer.conf" files:

$ find . -name layer.conf
./meta-phosphor/conf/layer.conf
./meta-openbmc-machines/meta-x86/meta-mellanox/conf/layer.conf
./meta-openbmc-machines/meta-x86/meta-mellanox/meta-msn/conf/layer.conf
./meta-openbmc-machines/meta-x86/conf/layer.conf
./meta-openbmc-machines/meta-x86/meta-quanta/meta-q71l/conf/layer.conf
./meta-openbmc-machines/meta-x86/meta-quanta/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-rackspace/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-rackspace/meta-barreleye/conf/layer.conf
./meta-openbmc-machines/meta-openpower/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ingrasys/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ingrasys/meta-zaius/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ibm/meta-garrison/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ibm/meta-firestone/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ibm/meta-romulus/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ibm/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ibm/meta-palmetto/conf/layer.conf
./meta-openbmc-machines/meta-openpower/meta-ibm/meta-witherspoon/conf/layer.conf
./meta-openbmc-machines/meta-evb/conf/layer.conf
./meta-openbmc-machines/meta-evb/meta-evb-aspeed/conf/layer.conf
./meta-openbmc-machines/meta-evb/meta-evb-aspeed/meta-evb-ast2500/conf/layer.conf
./meta-openbmc-bsp/meta-aspeed/conf/layer.conf
./meta-openbmc-bsp/meta-aspeed/meta-ast2500/conf/layer.conf
./meta-openbmc-bsp/meta-aspeed/meta-ast2400/conf/layer.conf
$

  not only does that single "git clone" apparently contain 23
individual layers, some of the content represents independent projects
in github. for example:

  openbmc/meta-aspeed <==> openbmc/openbmc/meta-openbmc-bsp/meta-aspeed

same with meta-openpower, possibly others.

  sorry to pollute this ML with questions about a specific layer, i
just figured it would be a piece of cake to take a look at this stuff
for a colleague and it got ugly in a hurry.

  i'll check in with the actual maintainers, but if anyone out there
is doing current work with openbmc, any pointers as to the current
state of that content would be appreciated.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] which is the official(?) OE/YP openbmc layer?

[Robert P. J. Day]

On Thu, 21 Sep 2017, Burton, Ross wrote:

> On 21 September 2017 at 11:01, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>     colleague just yesterday asked me a couple questions about openbmc,
>   so i investigated the OE/YP layer, and i'm a bit confused ... the
>   official OE layers page here:
>
>   https://layers.openembedded.org/layerindex/branch/master/layers/
>
>   refers to a meta-openbmc layer at https://github.com/facebook/openbmc,
>   implying it's a facebook project, but github also hosts:
>
>   https://github.com/openbmc
>
>     can anyone clarify the relationship between those two? if there is
>   any?
>
>
> Oh I really hope that isn't a Google/IBM vs Facebook fork war.
>
> I think the best way to get an answer is to email both
> maintainers...

  after just cursory examination of both repos, i have to say, neither
of them looks particularly well-organized. or am i just being overly
critical?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] which is the official(?) OE/YP openbmc layer?

[Robert P. J. Day]

  colleague just yesterday asked me a couple questions about openbmc,
so i investigated the OE/YP layer, and i'm a bit confused ... the
official OE layers page here:

https://layers.openembedded.org/layerindex/branch/master/layers/

refers to a meta-openbmc layer at https://github.com/facebook/openbmc,
implying it's a facebook project, but github also hosts:

https://github.com/openbmc

  can anyone clarify the relationship between those two? if there is
any?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] is there a summary somewhere of container-based YP solutions?

[Robert P. J. Day]

  topic came up today about docker/container-based solutions for
embedded linux systems, and i already know some of that:

 * meta-virtualization layer has recipes-containers/ recipes
 * resinOS is tailored for containers

i'm curious if anyone has summarized the container-related aspects of
YP.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] a couple bad(?) tags in poky checkout

[Robert P. J. Day]

  just listed git tags for poky, and a couple that show up that screw
up the ordering:

...
yocot-1.4.2  <-
yocto-1.4.1
yocto-1.4.2
...
yocto-2.1.2
yocto-2.2
yocto-2.2.1
yocto_1.5_M5.rc8  <-
...

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH][yocto-docs] BSP Guide: Numerous aesthetic tweaks/clarifications

[Robert P. J. Day]

* Outside of a title, use "BSP layer", not "BSP Layer"
* Add details about YP reference boards.
* Minor grammatical clarification in places.
* Add  to even single paragraph notes for consistency.

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 4d0ace0..63848ad 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -19,7 +19,7 @@
 

 
-This guide presents information about BSP Layers, defines a 
structure for components
+This guide presents information about BSP layers, defines a 
structure for components
 so that BSPs follow a commonly understood layout, discusses how to 
customize
 a recipe for a BSP, addresses BSP licensing, and provides 
information that
 shows you how to create and manage a
@@ -33,7 +33,7 @@
 
 A BSP consists of a file structure inside a base directory.
 Collectively, you can think of the base directory, its file 
structure,
-and the contents as a BSP Layer.
+and the contents as a BSP layer.
 Although not a strict requirement, layers in the Yocto Project 
use the
 following well-established naming convention:
 
@@ -77,8 +77,9 @@
 meta-yocto-bsp layer is part of the
 shipped poky repository.
 The meta-yocto-bsp layer maintains several
-BSPs such as the Beaglebone, EdgeRouter, and generic versions 
of
-both 32 and 64-bit IA machines.
+Yocto Project "reference" BSPs such as the ARM-based 
Beaglebone,
+MIPS-based Ubiquiti EdgeRouter, PowerPC-based MPC8315E-RDB,
+and generic versions of both 32 and 64-bit IA machines.
 

 
@@ -94,7 +95,7 @@
 
 The layer's base directory
 (meta-bsp_name)
-is the root of the BSP Layer.
+is the root of the BSP layer.
 This root is what you add to the
 BBLAYERS
 variable in the conf/bblayers.conf file 
found in the
@@ -179,7 +180,7 @@
 

 
-Before looking at the common form for the file structure 
inside a BSP Layer,
+Before looking at the common form for the file structure 
inside a BSP layer,
 you should be aware that some requirements do exist in order 
for a BSP to
 be considered compliant with the Yocto Project.
 For that list of requirements, see the
@@ -188,7 +189,7 @@
 

 
-Below is the common form for the file structure inside a BSP 
Layer.
+Below is the common form for the file structure inside a BSP 
layer.
 While you can use this basic form for the standard, realize 
that the actual structures
 for specific BSPs could differ.

@@ -572,7 +573,8 @@
 

 
-To use an include file, you simply include them in the
+To use an include file, you simply 
include or
+require it in the
 machine configuration file.
 For example, the Raspberry Pi BSP
 raspberrypi3.conf contains the
@@ -956,28 +958,28 @@
 Instructions on how to boot 
the BSP build from
 the BSP layer.
 Instructions on how to boot 
the binary images
-contained in the 
binary directory,
+contained in the 
binary/ directory,
 if present.
 Information on any known bugs 
or issues that users
 should know about when either building or 
booting the BSP
 binaries.
 
 README.sources 
File:
-You must include a 
README.sources in the
-
meta-bsp_name directory.
-This file specifies exactly where you can find the 
sources used to
-generate the binary images contained in the
-binary directory, if present.
+If your BSP layer includes a 
binary/ directory
+with at least one binary image, then it must also 
include a top-level
+README.sources file that 
explains exactly
+where you can find the sources used to generate 
those binary images.

Re: [yocto] Remove a recipe's do_install_append() function in an append file

[Robert P. J. Day]

On Fri, 24 Mar 2017, Cody Piersall wrote:

> Hello,
>
> I am building zsh from meta-oe layer, and it has a do_install_append()
> function defined like this:
>
> do_install_append () {
> rm -fr ${D}/usr/share
> }
>
> which gets rid of lots lots of useful functionality, like
> context-aware autocompletion.  Can a bbappend file get rid of that
> function, or do I need to edit the actual recipe? I've attempted
> defining an empty do_install_append() { : } but it didn't work.

  it might be worth asking why zsh is doing that in the first place.
if one doesn't want all that stuff, *that* is where an append could be
used to remove it. i think zsh removing it by default is
inappropriate.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] are there any outstanding patches to be applied to BSP Guide?

[Robert P. J. Day]

  i know i was working on some tweaks but can't find if i submitted
any yet. can anyone verify that what's up under "in progress/latest"
is the current version, as git pull'ed from yocto docs? thanks.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] should a BSP layer *really* ever need additional layers to be functional?

[Robert P. J. Day]

On Thu, 23 Mar 2017, Josef Holzmayr wrote:

> Hi,
>
> On 23.03.2017 11:35, Robert P. J. Day wrote:
> >   i always thought that using nothing more than a BSP layer (plus, of
> > course, the underlying OE layers) should allow you to get to the
> > command line. is that not true?
>
> I don't think that this generally holds true, as it would lead to
> significant duplication. Imagine a board based off something already
> in meta-ti or meta-intel. And maybe just needing a slightly modified
> bootloader.

  true, but the wording in the BSP Guide is:

"Some BSPs require additional layers on top of the BSP's root layer in
 ^
order to be functional. "

  that particular phrasing suggests that perhaps what's needed is more
user space content of some kind. perhaps rewording that to say that a
BSP layer might be based on top of other layers as a starting point
would be clearer.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] BSP guide: better example for recursive layer structure than meta-intel?

[Robert P. J. Day]

  pretty sure i asked this before, but again in BSP Guide:

"Some layers function as a layer to hold other BSP layers. An example
of this type of layer is the meta-intel layer, which contains a number
of individual BSP sub-layers, as well as a directory named common/
full of common content across those layers. Another example is the
meta-yocto-bsp layer mentioned earlier."

  um ... both of those claims are false. meta-intel *used* to have a
multi-layer structure, but not so much anymore. is there a better
example for that?

  and meta-yocto-bsp is, of course, just a simple layer, nothing
recursive about it.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] should a BSP layer *really* ever need additional layers to be functional?

[Robert P. J. Day]

  perusing current BSP Guide:

"Some BSPs require additional layers on top of the BSP's root layer in
order to be functional. For these cases, you also need to add those
layers to the BBLAYERS variable in order to build the BSP."

  really? should a properly-designed BSP layer need additional layers
to simply boot a simple image (say, core-image-minimal) to the command
line?

  i always thought that using nothing more than a BSP layer (plus, of
course, the underlying OE layers) should allow you to get to the
command line. is that not true?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH] meta-yocto-bsp: Remove superfluous OVERRIDES in machine conf files

[Robert P. J. Day]

In machine configuration files, there is no need to use OVERRIDES that
match the precise machine being defined, so remove them for clarity
and consistency from these lines in those respective files:

  PREFERRED_VERSION_linux-yocto_genericx86-64 ?= "4.10%"
  PREFERRED_VERSION_linux-yocto_genericx86 ?= "4.10%"
  UBOOT_MACHINE_mpc8315e-rdb = "MPC8315ERDB_config"

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

  i'm hoping i'm not misunderstanding anything here.

diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf 
b/meta-yocto-bsp/conf/machine/genericx86-64.conf
index 514265e..bfedd84 100644
--- a/meta-yocto-bsp/conf/machine/genericx86-64.conf
+++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf
@@ -7,6 +7,6 @@ DEFAULTTUNE ?= "core2-64"
 require conf/machine/include/tune-core2.inc
 require conf/machine/include/genericx86-common.inc

-PREFERRED_VERSION_linux-yocto_genericx86-64 ?= "4.10%"
+PREFERRED_VERSION_linux-yocto ?= "4.10%"

 SERIAL_CONSOLES_CHECK = "ttyS0"
diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf 
b/meta-yocto-bsp/conf/machine/genericx86.conf
index 34a52c3..af03b86 100644
--- a/meta-yocto-bsp/conf/machine/genericx86.conf
+++ b/meta-yocto-bsp/conf/machine/genericx86.conf
@@ -9,4 +9,4 @@ require conf/machine/include/genericx86-common.inc

 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "gma500-gfx-check"

-PREFERRED_VERSION_linux-yocto_genericx86 ?= "4.10%"
+PREFERRED_VERSION_linux-yocto ?= "4.10%"
diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf 
b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index fa02edc..4ce3494 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -8,7 +8,7 @@ require conf/machine/include/tune-ppce300c3.inc
 KERNEL_IMAGETYPE = "uImage"

 EXTRA_IMAGEDEPENDS += "u-boot"
-UBOOT_MACHINE_mpc8315e-rdb = "MPC8315ERDB_config"
+UBOOT_MACHINE = "MPC8315ERDB_config"

 SERIAL_CONSOLE = "115200 ttyS0"


-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] any YP machines or functionality that still require uImage creation?

[Robert P. J. Day]

  i just noticed that the machine config file for mpc8315e-rdb still
lists "uImage" as the default image type:

KERNEL_IMAGETYPE = "uImage"
IMAGE_BOOT_FILES ?= "u-boot.bin uImage uImage-mpc8315erdb.dtb;dtb"

is there anything about that target that still *requires* uImage
creation, as opposed to zImage?

  given that uImage is considered u-boot's "legacy" format, is there
any drawback to making zImage the default image type, and letting
folks drop back to uImage if they choose?

  put another way, is there anything that currently *ever* requires
the creation/use of a uImage format?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

[Robert P. J. Day]

On Wed, 15 Mar 2017, Belisko Marek wrote:

> On Tue, Mar 14, 2017 at 9:53 PM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
> > On Tue, 14 Mar 2017, Belisko Marek wrote:
> >
> >> Hi Robert,
> >>
> >> On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day <rpj...@crashcourse.ca> 
> >> wrote:
> >> > On Mon, 13 Mar 2017, Robert P. J. Day wrote:
> >> >
> >> >>
> >> >>   i'll start a new thread to focus on just this issue. again, building
> >> >> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
> >> >>
> >> >>   INHERIT += "kernel-fitimage" <-- do i need this line?
> >> >>   KERNEL_IMAGETYPES_append = " fitImage"
> >> >>
> >> >> anyway, run:
> >> >>
> >> >>   $ bitbake virtual/kernel
> >> >>
> >> >> and eventually get:
> >> >>
> >> >>   make[2]: *** No rule to make target 'fitImage'.  Stop.
> >> >
> >> > ... snip ...
> >> >
> >> >   i would still love to figure out how to generate a simple FIT image
> >> > when building core-image-minimal for mpc8315e-rdb.
> >> >
> >> >   first, based on what i read, my first attempt was to add the
> >> > following line to local.conf:
> >> >
> >> >   KERNEL_IMAGETYPES_append = " fitImage"
> >> You need probably also add:
> >>
> >> KERNEL_CLASSES += "kernel-fitimage"
> >>
> >> to local.conf
> >
> >   that *appears* to have solved the problem ... so why is it i didn't
> > realize that? where is that written up that i somehow missed it?

> It is not documented in yocto manual (I cannot find anything about
> fitimage at all), so maybe it could be extended.

  i'll check later to see where it would seem to belong, unless
someone has a suggestion.

> >   and would it not make sense that selecting FIT image in one
> > variable should automatically set the other required variables?

> I think something like that can be doable and it will save a lot of
> time for people who want's to have it enabled.

  actually, i take back that suggestion, as i think it would overly
complicate kernel.bbclass (at least the way i read it).

  i can see that, for backward compatibility, kernel.bbclass contains
the following:

  # Here we pull in all various kernel image types which we support.
  #
  # In case you're wondering why kernel.bbclass inherits the other image
  # types instead of the other way around, the reason for that is to
  # maintain compatibility with various currently existing meta-layers.
  # By pulling in the various kernel image types here, we retain the
  # original behavior of kernel.bbclass, so no meta-layers should get
  # broken.
  #
  # KERNEL_CLASSES by default pulls in kernel-uimage.bbclass, since this
  # used to be the default behavior when only uImage was supported. This
  # variable can be appended by users who implement support for new kernel
  # image types.

  KERNEL_CLASSES ?= " kernel-uimage "
  inherit ${KERNEL_CLASSES}

so it's quite simple to extend the set of .bbclass files that provide
new kernel image types with, say:

  KERNEL_CLASSES += "kernel-fitimage"

beyond that, however, since a new kernel class file might define a
*pile* of new kernel image types, poor kernel.bbclass would need to
recognize all of them and know which kernel class file to inherit for
each new kernel type, which seems unwieldy.

  so as long as how to define new kernel image types is explained
clerly (is it?), then a discussion of FIT images should simply need to
refer the reader to that section.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

[Robert P. J. Day]

On Tue, 14 Mar 2017, Belisko Marek wrote:

> Hi Robert,
>
> On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
> > On Mon, 13 Mar 2017, Robert P. J. Day wrote:
> >
> >>
> >>   i'll start a new thread to focus on just this issue. again, building
> >> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
> >>
> >>   INHERIT += "kernel-fitimage" <-- do i need this line?
> >>   KERNEL_IMAGETYPES_append = " fitImage"
> >>
> >> anyway, run:
> >>
> >>   $ bitbake virtual/kernel
> >>
> >> and eventually get:
> >>
> >>   make[2]: *** No rule to make target 'fitImage'.  Stop.
> >
> > ... snip ...
> >
> >   i would still love to figure out how to generate a simple FIT image
> > when building core-image-minimal for mpc8315e-rdb.
> >
> >   first, based on what i read, my first attempt was to add the
> > following line to local.conf:
> >
> >   KERNEL_IMAGETYPES_append = " fitImage"
> You need probably also add:
>
> KERNEL_CLASSES += "kernel-fitimage"
>
> to local.conf

  that *appears* to have solved the problem ... so why is it i didn't
realize that? where is that written up that i somehow missed it?

  and would it not make sense that selecting FIT image in one variable
should automatically set the other required variables?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

[Robert P. J. Day]

On Mon, 13 Mar 2017, Robert P. J. Day wrote:

>
>   i'll start a new thread to focus on just this issue. again, building
> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
>
>   INHERIT += "kernel-fitimage" <-- do i need this line?
>   KERNEL_IMAGETYPES_append = " fitImage"
>
> anyway, run:
>
>   $ bitbake virtual/kernel
>
> and eventually get:
>
>   make[2]: *** No rule to make target 'fitImage'.  Stop.

... snip ...

  i would still love to figure out how to generate a simple FIT image
when building core-image-minimal for mpc8315e-rdb.

  first, based on what i read, my first attempt was to add the
following line to local.conf:

  KERNEL_IMAGETYPES_append = " fitImage"

however:

  $ bitbake virtual/kernel

  ... snip ...

  | NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E uImage
  CC=powerpc-poky-linux-gcc  -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd
  | NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E fitImage
  CC=powerpc-poky-linux-gcc  -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd

  ... snip ...

  | make[2]: *** No rule to make target 'fitImage'.  Stop.
  | Makefile:150: recipe for target 'sub-make' failed
  | make[1]: *** [sub-make] Error 2
  | Makefile:24: recipe for target '__sub-make' failed
  | make: *** [__sub-make] Error 2

which makes sense since there is no such target, "fitImage", in the
kernel build structure.

  what am i screwing up here? how do i generate a simple FIT image?

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] suddenly, bunch of circular dependency errors

[Robert P. J. Day]

  just updated my poky layer, tried to build core-image-minimal for
mpc8315e-rdb, and:

ERROR: 171 unbuildable tasks were found.
| ETA:  0:00:04
These are usually caused by circular dependencies and any circular
dependency chains found will be printed below. Increase the debug
level to see a list of unbuildable tasks.

Identifying dependency loops (this may take a short while)...

ERROR: An uncaught exception occurred in runqueue

  is anyone else seeing this?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] missing "whoami" command trying to build FIT image for mpc8315e-rdb ref board

[Robert P. J. Day]

  trying for the first time to build a FIT image, so started with
current poky checkout, configured and built for mpc8315e-rdb and
core-image-minimal, everything worked fine (as it always does).

  now, as i read it, to generate a FIT image output file, i need add
only:

  KERNEL_IMAGETYPES_append = " fitImage"

to my local.conf, is that right? but this is what happens:

$ bitbake core-image-minimal

... snip ...

Initialising tasks...done.
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 1301 of 2494 
(/home/rpjday/oe/dist/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.9.bb:do_compile)
NOTE: recipe linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0: task 
do_compile: Started
ERROR: linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0 do_compile: 
oe_runmake failed
ERROR: linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0 do_compile: 
Function failed: do_compile (log file is located at 
/home/rpjday/oe/builds/mpc8315e/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0/temp/log.do_compile.23408)
ERROR: Logfile of failure stored in: 
/home/rpjday/oe/builds/mpc8315e/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0/temp/log.do_compile.23408
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E uImage CC=powerpc-poky-linux-gcc  
-fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd
| NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E fitImage 
CC=powerpc-poky-linux-gcc  -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd
| ERROR: oe_runmake failed
| make[2]: Circular arch/powerpc/lib/crtsavres.o <- prepare dependency dropped.
|   CHK include/config/kernel.release
|   Using 
/home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source as 
source for kernel
|   GEN ./Makefile
|   CHK include/generated/uapi/linux/version.h
|   CHK include/generated/utsrelease.h
|   CHK include/generated/timeconst.h
|   CHK include/generated/bounds.h
|   CHK include/generated/asm-offsets.h
|   CALL
/home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/scripts/checksyscalls.sh
|   CHK include/generated/compile.h
| 
/home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/scripts/mkcompile_h:
 line 46: whoami: command not found
|   CALL
/home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/arch/powerpc/kernel/systbl_chk.sh
|   CALL
/home/rpjday/oe/builds/mpc8315e/tmp/work-shared/mpc8315e-rdb/kernel-source/arch/powerpc/kernel/prom_init_check.sh
|   CHK kernel/config_data.h
| make[2]: *** No rule to make target 'fitImage'.  Stop.
| Makefile:150: recipe for target 'sub-make' failed
| make[1]: *** [sub-make] Error 2
| Makefile:24: recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2
| ERROR: Function failed: do_compile (log file is located at 
/home/rpjday/oe/builds/mpc8315e/tmp/work/mpc8315e_rdb-poky-linux/linux-yocto/4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0/temp/log.do_compile.23408)
NOTE: recipe linux-yocto-4.9.8+gitAUTOINC+7e8ec462b6_6b67f448d6-r0: task 
do_compile: Failed
ERROR: Task 
(/home/rpjday/oe/dist/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.9.bb:do_compile)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 2470 tasks of which 2469 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
  
/home/rpjday/oe/dist/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.9.bb:do_compile
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
$

  obviously(?), selecting a FIT image triggers a call to "whoami" in
that kernel mkcompile_h script, and there is no such command in the
native sysroot. or am i doing something wrong?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] help

[Robert P. J. Day]

On Fri, 10 Mar 2017, Suneetha Lakshmi G wrote:

> Hi All,
>
> Im new to yocto and trying to build for my customer device im facing
> this issue.

  first advice is to use meaningful subject lines ... simply yelling
"help" is a good way to get people to not take you seriously right
from the beginning.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] why is VOLATILE_LOG_DIR mentioned in ref manual when it doesn't exist?

[Robert P. J. Day]

  not sure if i'm misreading this, but i note that an addition was
made to the ref manual back in dec 2016:

commit 5d2bdf49e569e44d02602501d72418f04dbe6e4a
Author: Scott Rifenbark <srifenb...@gmail.com>
Date:   Fri Dec 30 10:20:28 2016 -0800

ref-manual: New VOLATILE_LOG_DIR variable description

Fixes [YOCTO #6132]

No mention of how to make the target directory /var/log
persistent.  I added a note to the "post-install-logging"
image feature that points to the new VOLATILE_LOG_DIR
variable description, which I added to the glossary.

Signed-off-by: Scott Rifenbark <srifenb...@gmail.com>

diff --git a/documentation/ref-manual/ref-features.xml
b/documentation/ref-manual/ref-features.xml
index 282a517..a4516a2 100644
--- a/documentation/ref-manual/ref-features.xml
+++ b/documentation/ref-manual/ref-features.xml
@@ -297,6 +297,12 @@
 Enables logging postinstall script runs to
 the /var/log/postinstall.log file
 on first boot of the image on the target system.
+
+To make the /var/log directory
+on the target persistent, use the
+VOLATILE_LOG_DIR
+variable by setting it to "no".
+
 
 ptest-pkgs:
 Installs ptest packages for all ptest-enabled recipes.


but that is a broken link, and i see no definition or usage of that
variable. can someone clarify what is happening here?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH] yocto-docs: Various formatting/clarification adjustments to BSP Guide

[Robert P. J. Day]

Collection of aesthetic/formatting/clarification fixes to BSP Guide,
including:

* Adjust some directory names to have trailing slash
* Reword some paragraphs for clarity
* Add s inside s for consistency

and other minor tweaks.

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 4d0ace0..d189ee0 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -956,28 +956,28 @@
 Instructions on how to boot 
the BSP build from
 the BSP layer.
 Instructions on how to boot 
the binary images
-contained in the 
binary directory,
+contained in the 
binary/ directory,
 if present.
 Information on any known bugs 
or issues that users
 should know about when either building or 
booting the BSP
 binaries.
 
 README.sources 
File:
-You must include a 
README.sources in the
-
meta-bsp_name directory.
-This file specifies exactly where you can find the 
sources used to
-generate the binary images contained in the
-binary directory, if present.
+If your BSP layer includes a 
binary/ directory
+with at least one binary image, then it must also 
include a top-level
+README.sources file that 
explains exactly
+where you can find the sources used to generate 
those binary images.
 
 Layer Configuration 
File:
-You must include a 
conf/layer.conf in the
+You must include a 
conf/layer.conf file in the
 
meta-bsp_name directory.
 This file identifies the 
meta-bsp_name
 BSP layer as a layer to the build 
system.
 Machine Configuration 
File:
 You must include one or more
-
conf/machine/bsp_name.conf
-files in the 
meta-bsp_name directory.
+
conf/machine/machine.conf
+machine definition files in the
+
meta-bsp_name directory.
 These configuration files define machine targets 
that can be built
 using the BSP layer.
 Multiple machine configuration files define 
variations of machine
@@ -989,12 +989,22 @@
 hardware.
 If you do have very different targets, you should 
create separate
 BSP layers for each target.
-It is completely possible for a developer to 
structure the
-working repository as a conglomeration of 
unrelated BSP
-files, and to possibly generate BSPs targeted for 
release
-from that directory using scripts or some other 
mechanism
-(e.g. meta-yocto-bsp layer).
-Such considerations are outside the scope of this 
document.
+
+  
+It is completely possible for a developer to 
structure the
+working repository as a conglomeration of 
unrelated BSP
+files, and to possibly generate BSPs targeted 
for release
+from that directory using scripts or some 
other mechanism
+(e.g. meta-yocto-bsp 
layer).
+Such considerations are outside the scope of 
this document.
+  
+  
+In any event, the 
meta-yocto-bsp layer should be
+considered a special case as it defines the 
family of Yocto Project
+reference boards, which necessarily cover the 
set of supported
+architectures.
+  
+
 
 
 
@@ -1025,16 +1035,20 @@
 purposes, you should put the images and artifacts 
within a
 binary/ subdirectory l

[yocto] standards for YP documentation markup?

[Robert P. J. Day]

  more nitpicky pedantry ... i mentioned this once upon a long time
ago, but i thought i'd revisit it. there is a fair bit of
inconsistency in the docbook markup in the YP docs such that, even
though the end-product looks reasonable, the markup kind of bounces
around all over the place and, in future, would cause all sorts of
hilarity if one wanted to redefine the rendering.

  for instance, there are a number of terms that are apparently
supposed to be rendered in italics at the moment, such as filenames,
variable names, command names and so on. but even though docbook
supports explicit markup using:

  
  
  

and so on, if you check the BSP guide,  is being used all
over the place for all of the above; examples:

You use the yocto-bsp create sub-command to create
LICENSE_FLAGS_WHITELIST, the build stops and

and so on. sure, it all looks good right now, but if someone wanted to
make a trivial change to the rendering of, say, just commands, well,
oh dear ...

  other nitpickery i noticed in that same doc is inconsistency of
defining notes depending on whether they have more than one paragraph.
if there's just one para, it's very common to see:

  
blah blah
woof woof
  

OTOH, if it's a multi-para note, you see:

  

  ... para 1 ...


  ... para 2 ...

  

but look closely at the final rendering and you'll see that the use of
 clearly changes the final rendering in terms of line spacing.
and, occasionally, even a single-para note in the guide uses
 so it's not even consistently inconsistent. :-)

  anyway, yes, it's all picky, but it would be useful to have a short
guide on standard for YP docs markup so that, if someone starts a new
one, it can at least follow some guidelines.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

[yocto] occasional confusion in bsp guide, mixing BSP layer name and machine name

[Robert P. J. Day]

  as i claw my through the bsp guide, i notice the occasional
confusion between referring to the BSP layer itself and a machine
supported by that layer.

  a couple times, i've found references to the alleged machine
configuration file "conf/bsp_name.conf" (which i'm changing to
"conf/machine.conf"). and in section 1.4, i read the snippet:

/ start

Following is a specific example to help you better understand the
process. Consider an example that customizes a recipe by adding a
BSP-specific configuration file named interfaces to the
init-ifupdown_1.0.bb recipe for machine "xyz" where the BSP layer also
supports several other machines. Do the following:

Edit the init-ifupdown_1.0.bbappend file so that it contains the
following:

  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
directory.

Create and place the new interfaces configuration file in the BSP's
layer here:

  meta-xyz/recipes-core/init-ifupdown/files/xyz-machine-one/interfaces

/ end

so we have a section that ostensibly describes the BSP layer
"meta-xyz", but first refers specifically to the machine "xyz" (even
though the layer is described as supporting multiple machines), and
further extends the directory structure with the machine name
"xyz-machine-one". is it just me, or is that confusing and
contradictory?

  sure, it's excruciatingly pedantic, but is there a doc-wide standard
for names to be used for stuff like this? otherwise, i'll just make
something up to clean this up (assuming, of course, that it needs
cleaning and i'm not just hopelessly misreading all of this).

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Robert P. J. Day]

On Fri, 3 Mar 2017, Andy Pont wrote:

> Robert wrote...
>
> > > I would look at one of the P10xx series QorIQ boards.  Digi-Key list
> > > the P1021RDB-PC-ND and P1024RDB-PA-ND as being active parts which
> > > are either single or dual e500 cores.
> >
> >   i would start with the machine definition files in the meta-fsl-ppc
> > layer:
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/conf/machine
> >
> > and see what looks promising. however, IIRC, one of the properties of
> > a YP reference board is that it shouldn't be stupid, crazy expensive,
> > no? so anything climbing above $500 (USD) might not be an option.
> > people used to spending $60 for a beaglebone black might have a
> > seizure to suddenly realize they need $500 for a powerpc reference
> > board.
>
> Using Digi-Key UK as my reference, they list the MPC8308-RDB-ND and
> MPC8313E-RDBC-ND as being available for less than £250 which makes
> them sub $300 which is probably the best price I have seen for Power
> Architecture reference boards.
>
> Granted, they are still more expensive than a BBB, RPi or something
> like that but cheap compared to >$2,000 reference boards we used to
> have to buy in the old days!

  in canada, distributors are charging over $400 (CAD) for either of
those, which you'd normally think would be outside the bounds for a YP
reference board, but it may be that that's what you have to accept for
even an inexpensive PPC dev kit.

  a better question is, what PPC platform are people working with
these days? it seems pointless to select an older technology just
because it's cheaper, only to have no one buy it because it's useless.
so who out there is working with powerpc, and what PPC platform would
have enough general interest that it would be worth making the YP
reference board?

  or, perhaps (god forbid) there's no actual point in even *having* a
powerpc reference board?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Robert P. J. Day]

On Fri, 3 Mar 2017, Andy Pont wrote:

> Ross Burton wrote...
>
> >> it seems of limited value for YP to have a powerpc reference board,
> >> mpc8315e-rdb, that is essentially impossible to procure. is there any
> >> effort being made to look around for a newer powerpc reference board
> >> that people could actually buy?
> >
> >Do you have any suggestions?
>
> If we are being strictly pedantic then is isn't PowerPC (at least in
> the world that is Freescale / NXP / Whoever they are this week).
>
> I would look at one of the P10xx series QorIQ boards.  Digi-Key list
> the P1021RDB-PC-ND and P1024RDB-PA-ND as being active parts which
> are either single or dual e500 cores.

  i would start with the machine definition files in the meta-fsl-ppc
layer:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/conf/machine

and see what looks promising. however, IIRC, one of the properties of
a YP reference board is that it shouldn't be stupid, crazy expensive,
no? so anything climbing above $500 (USD) might not be an option.
people used to spending $60 for a beaglebone black might have a
seizure to suddenly realize they need $500 for a powerpc reference
board.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Robert P. J. Day]

On Fri, 3 Mar 2017, Burton, Ross wrote:

> On 3 March 2017 at 13:24, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>     it seems of limited value for YP to have a powerpc reference
>   board, mpc8315e-rdb, that is essentially impossible to
>   procure. is there any effort being made to look around for a
>   newer powerpc reference board that people could actually buy?
>
> Do you have any suggestions?

  not at the moment ... perhaps the powerpc or freescale folks can
weigh in. i'm not a powerpc expert, but it does seem pointless to have
a reference board that no one can get.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BSP "sub-layer" examples -- better example than meta-intel?

[Robert P. J. Day]

On Fri, 3 Mar 2017, Burton, Ross wrote:

> On 3 March 2017 at 10:59, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>     also, not sure how meta-yocto-bsp fits that description. it neither
>   contains sub-layers, nor is itself a sub-layer of a higher-level
>   layer. sure, it comes along as part of the checkout of "poky", but the
>   poky checkout itself is not a layer.
>
>
> meta-yocto-bsp being a sub-layer in the meta-yocto repository, I guess.

  oh, i understand how the poky layers are structured, but i was
quoting from the para in the bsp guide that starts, "Some layers
function as a layer to hold other BSP layers." and, technically
speaking, that is not what is happening there.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Robert P. J. Day]

  it seems of limited value for YP to have a powerpc reference board,
mpc8315e-rdb, that is essentially impossible to procure. is there any
effort being made to look around for a newer powerpc reference board
that people could actually buy?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH] yocto-docs: Various cleanup/tweaking to BSP Guide

[Robert P. J. Day]

Collection of minor cleanups to BSP Guide:

* Standardize on spelling of "BSP layer" rather than "BSP Layer"
* Describe YP reference boards in more detail (architecture, ...)
* Bump up several references to kernel "4.4" to "4.9"
* Replace meaningless "bsp_name.conf" with "machine.conf"
* Add a few more sample components to the BSP layer structure

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 4d0ace0..d81cb46 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -19,7 +19,7 @@
 

 
-This guide presents information about BSP Layers, defines a 
structure for components
+This guide presents information about BSP layers, defines a 
structure for components
 so that BSPs follow a commonly understood layout, discusses how to 
customize
 a recipe for a BSP, addresses BSP licensing, and provides 
information that
 shows you how to create and manage a
@@ -33,7 +33,7 @@
 
 A BSP consists of a file structure inside a base directory.
 Collectively, you can think of the base directory, its file 
structure,
-and the contents as a BSP Layer.
+and the contents as a BSP layer.
 Although not a strict requirement, layers in the Yocto Project 
use the
 following well-established naming convention:
 
@@ -77,8 +77,10 @@
 meta-yocto-bsp layer is part of the
 shipped poky repository.
 The meta-yocto-bsp layer maintains several
-BSPs such as the Beaglebone, EdgeRouter, and generic versions 
of
-both 32 and 64-bit IA machines.
+BSPs such as the ARM-based Beaglebone,
+MIPS64-based Ubiquiti Networks EdgeRouter,
+PowerPC-based Freescale MPC8315E-RDB,
+and generic versions of both 32 and 64-bit IA machines.
 

 
@@ -94,7 +96,7 @@
 
 The layer's base directory
 (meta-bsp_name)
-is the root of the BSP Layer.
+is the root of the BSP layer.
 This root is what you add to the
 BBLAYERS
 variable in the conf/bblayers.conf file 
found in the
@@ -189,7 +191,7 @@

 
 Below is the common form for the file structure inside a BSP 
Layer.
-While you can use this basic form for the standard, realize 
that the actual structures
+While you can use this basic form as your standard, realize 
that the actual structures
 for specific BSPs could differ.

 
@@ -200,6 +202,9 @@
  
meta-bsp_name/binary/bootable_images
  meta-bsp_name/conf/layer.conf
  meta-bsp_name/conf/machine/*.conf
+ meta-bsp_name/conf/machine/include/*
+ meta-bsp_name/files/*
+ meta-bsp_name/classes/*
  meta-bsp_name/recipes-bsp/*
  meta-bsp_name/recipes-core/*
  meta-bsp_name/recipes-graphics/*
@@ -663,21 +668,21 @@
 the 
meta-bsp_name/recipes-kernel/linux
 directory).
 
 
-Suppose you are using the 
linux-yocto_4.4.bb recipe to build
+Suppose you are using the 
linux-yocto_4.9.bb recipe to build
 the kernel.
 In other words, you have selected the kernel in your
-bsp_name.conf 
file by adding these types
+machine.conf 
file by adding these types
 of statements:
 
  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
- PREFERRED_VERSION_linux-yocto ?= "4.4%"
+ PREFERRED_VERSION_linux-yocto ?= "4.9%"
 
 
 When the preferred provider is assumed by default, the
 PREFERRED_PROVIDER statement does not 
appear in the
-
bsp_name.conf file.
+
machine.conf file.
 
-You would use the linux-yocto_4.4.bbappend
+You would then create a 
linux-yocto_4.9.bbappend
 file to append specific BSP settings to the kernel, thus
 configuring the kernel for your particular BSP.
 
@@ -686,7 +691,7 @@
 As an example, consider the following append file
 used by the BSPs in meta-yocto-bsp:
 
- meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
+ meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.9.bbappend
 
 The following listing shows the file.
 Be aware that the actual commit ID strings in this

[yocto] BSP Guide: what means "bsp_name.conf"?

[Robert P. J. Day]

  in section 1.2.9:

"Suppose you are using the linux-yocto_4.4.bb recipe to build the
kernel. In other words, you have selected the kernel in your
bsp_name.conf file by adding these types of statements: ..."
^

  um ... what? and just below that:

"Note
 When the preferred provider is assumed by default, the
 PREFERRED_PROVIDER statement does not appear in the bsp_name.conf
 file.   ^

  can i assume those should read "machine.conf"? because i have no
idea what "bsp_name.conf" refers to as it is.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] purpose of "README.sources" file, and why does meta-intel have one?

[Robert P. J. Day]

  still in BSP Guide:

"Note
  If the BSP's binary directory is missing or the directory has no
  images, an existing README.sources file is meaningless."

yet the meta-intel layer has that file but no binary/ directory, so is
the above the proper explanation of README.sources?

  i have about 20 layers checked out, and *very* few of them have a
README.sources file although, to be fair, they also don't have
"binary" directories. it seems like not a lot of layers take advantage
of that feature.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] BSP "sub-layer" examples -- better example than meta-intel?

[Robert P. J. Day]

  in current BSP Guide:

"Some layers function as a layer to hold other BSP layers. An example
of this type of layer is the meta-intel layer, which contains a number
of individual BSP sub-layers, as well as a directory named common/
full of common content across those layers. Another example is the
meta-yocto-bsp layer mentioned earlier."

  first, it seems meta-intel is not a great example anymore given its
restructuring -- it's just two layers:

  * meta-intel
  * meta-intel/meta-tlk

unlike what it used to be, so anyone want to suggest a better example
for that? (it *used* to be a great example of that, of course.)

  also, not sure how meta-yocto-bsp fits that description. it neither
contains sub-layers, nor is itself a sub-layer of a higher-level
layer. sure, it comes along as part of the checkout of "poky", but the
poky checkout itself is not a layer.

  so ... thoughts?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] more pedantry: "BSP Layer" versus "BSP layer"?

[Robert P. J. Day]

  jsut one of those things that starts to grate on me after a while
... while reading BSP guide, the text bounces back and forth between
"BSP Layer" and "BSP layer."

  personally, i'm not a huge fan of upper case (quelle surprise!), so
unless it's being used as a proper name, i think "BSP layer" is by far
the preferred style, and i'm happy to tweak the guide as i'm going
through it, unless there are massive objections.

  pretty sure i'm going to find at least a few things to adjust so i
can just fold that in with the rest. thoughts?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"

[Robert P. J. Day]

On Mon, 27 Feb 2017, Bruce Ashfield wrote:

>
>
> On Mon, Feb 27, 2017 at 5:07 AM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
>
>   Update the remaining references to kernel version 3.19 to version 4.4,
>   restricted to the section "kernel-dev-common.xml".
>
> I just sent a patch to drop 4.4 from master. I'd suggest 4.9 as a
> version to use that will persist in master for a bit longer.

  if my earlier patches for kernel-dev manual have not already been
applied, feel free to toss them, and i'll resubmit a newer patch right
from the beginning with updated version numbers and everything else.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"

[Robert P. J. Day]

On Mon, 27 Feb 2017, Bruce Ashfield wrote:

> On Mon, Feb 27, 2017 at 5:07 AM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
>
>   Update the remaining references to kernel version 3.19 to
>   version 4.4, restricted to the section
>   "kernel-dev-common.xml".
>
> I just sent a patch to drop 4.4 from master. I'd suggest 4.9 as a
> version to use that will persist in master for a bit longer.

  in that case, one can drop those earlier patches i sent in, and i
will submit newer ones.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] kernel-dev manual, section 2.6.2, do tags like "systemtap" exist?

[Robert P. J. Day]

On Mon, 27 Feb 2017, Bruce Ashfield wrote:

> On Mon, Feb 27, 2017 at 5:27 AM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
>
>     section 2.6.2 refers to how to display changes based on a
>   tag, and uses the alleged tag name "systemtap" ... do tags
>   like that even exist anymore? i see no such tag in my current
>   build directories.
>
> Correct. The tagged features were dropped a few years ago. So any
> section that references them could be dropped.

  okey dokey.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] couple questions about kernel-dev manual, section 2.6, "emenlow" branch

[Robert P. J. Day]

On Mon, 27 Feb 2017, Bruce Ashfield wrote:

> On Mon, Feb 27, 2017 at 4:54 AM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
>
>     still working my way through the kernel-dev manual, and a
>   couple oddities in section 2.6.
>
>     first, the example given uses the (alleged) standard/emenlow
>   branch, which i'm pretty sure doesn't exist anymore, yes? if
>   one is going to use an example, i suggest one base that
>   example on one of the YP reference BSPs that's guaranteed to
>   always exist, such as beagleboard or arm-versatile-926ejs.
>
> I can't say that one will always exist .. but the arm-versatile
> branch has been around for years, and until the qemuarm target
> changes to use something else, it will continue to be around.

  i might have skipped those possibilities since they produced no
output, which made the examples rather vacuous. :-) i'll check again,
want to make sure one picks a branch that actually generates output.

>     next, i'm assuming that one would be running those "git
>   whatchanged" commands in the project directory, under
>   tmp/work-shared//kernel-source, yes? it's just not
>   made clear in that section where a reader would be doing those
>   things.
>
> Correct.

  ok, i will add that note to the imminent patch.

>     finally, section 2.6.1 reads:
>
>   "Here is an example that looks at what has changed in the
>   emenlow branch of the linux-yocto-3.19 kernel."

>   what does the kernel version of 3.19 have to do with those git
>   commands? how do those commands depend on the particular
>   version of the linux-yocto recipe you're using?
>
> At one point I was changing the branching structure, and the kernel
> meta data was in the same repo as the kernel source, so that could
> change some of the commands.
>
> But nothing has changed on that front in quite some time, so the
> answer is "they don't depend on the version you are using" .. so the
> version reference could be dropped.

  roger that.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] kernel-dev manual, section 2.6.2, do tags like "systemtap" exist?

[Robert P. J. Day]

  section 2.6.2 refers to how to display changes based on a tag, and
uses the alleged tag name "systemtap" ... do tags like that even exist
anymore? i see no such tag in my current build directories.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"

[Robert P. J. Day]

Update the remaining references to kernel version 3.19 to version 4.4,
restricted to the section "kernel-dev-common.xml".

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

  if my earlier patch hasn't already been applied, this one can be
folded in since it simply adds more "3.19" -> "4.4" updates to the
same kernel-dev-common.xml file, which is already part of the commit
message for that earlier patch.

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index a9aafd3..97e2a0b 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -645,8 +645,8 @@
 recipe to your layer and give it a meaningful name.
 The name should include the version of the Linux kernel you
 are using (e.g.
-linux-yocto-myproject_3.19.bb,
-where "3.19" is the base version of the Linux kernel
+linux-yocto-myproject_4.4.bb,
+where "4.4" is the base version of the Linux kernel
 with which you would be working).
 In the same directory inside your layer,
 create a matching directory
@@ -698,7 +698,7 @@
 
 LINUX_VERSION:
 The Linux kernel version you are using (e.g.
-"3.19").
+"4.4").
 LINUX_VERSION_EXTENSION:
 The Linux kernel 
CONFIG_LOCALVERSION
 that is compiled into the resulting kernel and 
visible
@@ -724,7 +724,7 @@
 The combined results are a string with
 the following form:
 
- 
3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+ 
4.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
 
 While lengthy, the extra verbosity in 
PV
 helps ensure you are using the exact

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] couple questions about kernel-dev manual, section 2.6, "emenlow" branch

[Robert P. J. Day]

  still working my way through the kernel-dev manual, and a couple
oddities in section 2.6.

  first, the example given uses the (alleged) standard/emenlow branch,
which i'm pretty sure doesn't exist anymore, yes? if one is going to
use an example, i suggest one base that example on one of the YP
reference BSPs that's guaranteed to always exist, such as beagleboard
or arm-versatile-926ejs.

  next, i'm assuming that one would be running those "git whatchanged"
commands in the project directory, under
tmp/work-shared//kernel-source, yes? it's just not made clear
in that section where a reader would be doing those things.

  finally, section 2.6.1 reads:

"Here is an example that looks at what has changed in the emenlow
branch of the linux-yocto-3.19 kernel."

  what does the kernel version of 3.19 have to do with those git
commands? how do those commands depend on the particular version of
the linux-yocto recipe you're using?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] puzzling instructions in kernel dev manual, section 2.3.1

[Robert P. J. Day]

  just noticed this in kernel dev manual, section 2.3.1:

 "To force a pickup and commit of all such pending changes, enter
   the following:

 $ git add .
 $ git commit -s -a -m "getting rid of -dirty"

the "-a" option with "commit" means, "Tell the command to
automatically stage files that have been modified and deleted, but new
files you have not told Git about are not affected."

  but the previous command, "git add .", by using an argument of ".",
has already staged any new files, has it not?  perhaps the preceding
command should have been "git add -u" for update mode?

  or am i just confused?

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH v2] yocto-docs: kernel-dev, Aesthetic/formatting/clarification fixes

[Robert P. J. Day]

A variety of tweaks to kernel-dev manual, section
kernel-dev-common.xml, which include:

* adding extra text in places to clarify possibly ambiguous content
* some formatting changes related to font and overly long lines
* update some old version numbers that don't even exist anymore

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/documentation/kernel-dev/kernel-dev-common.xml 
b/documentation/kernel-dev/kernel-dev-common.xml
index a9aafd3..cb186c9 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -25,10 +25,10 @@
 If you are going to be modifying kernel recipes, it is recommended
 that you create and prepare your own layer in which to do your
 work.
-Your layer contains its own
+Your layer would typically contain its own
 BitBake
 append files
-(.bbappend) and provides a convenient
+(.bbappend) and would provide a convenient
 mechanism to create your own recipe files
 (.bb).
 For details on how to create and work with layers, see the 
following
@@ -59,9 +59,9 @@
 
 Modifying an existing recipe can consist of the following:
 
-Creating the append file
-Applying patches
-Changing the configuration
+Creating an append file
+Applying some local patches
+Changing the kernel 
configuration
 
 

@@ -81,14 +81,14 @@

 
 You create this file in your custom layer.
-You also name it accordingly based on the linux-yocto recipe
-you are using.
+You also name it accordingly based on the version of the
+linux-yocto recipe you are modifying.
 For example, if you are modifying the
-
meta/recipes-kernel/linux/linux-yocto_3.19.bb
-recipe, the append file will typically be located as follows
-within your custom layer:
+
meta/recipes-kernel/linux/linux-yocto_4.4.bb
+recipe, the corresponding append file will typically be located
+as follows within your custom layer:
 
- 
your-layer/recipes-kernel/linux/linux-yocto_3.19.bbappend
+ 
your-layer/recipes-kernel/linux/linux-yocto_4.4.bbappend
 
 The append file should initially extend the
 FILESPATH
@@ -133,12 +133,14 @@

 
 For example, you can apply a three-patch series by adding the
-following lines to your linux-yocto
-.bbappend file in your layer:
+following lines to the linux-yocto
+.bbappend file in your custom layer:
 
- SRC_URI += "file://0001-first-change.patch"
- SRC_URI += "file://0002-second-change.patch"
- SRC_URI += "file://0003-third-change.patch"
+ SRC_URI += " \
+file://0001-first-change.patch \
+file://0002-second-change.patch \
+file://0003-third-change.patch \
+"
 
 The next time you run BitBake to build the Linux kernel,
 BitBake detects the change in the recipe and fetches and
@@ -158,11 +160,12 @@
 
 You can make wholesale or incremental changes to the final
 .config file used for the eventual
-Linux kernel configuration by including a
-defconfig file and by specifying
+Linux kernel configuration by including a local
+defconfig file, as well as by specifying
 configuration fragments in the
 SRC_URI
-to be applied to that file.
+to be applied to the configuration defined by that
+defconfig file.
 

 
@@ -204,10 +207,10 @@

 
 Generally speaking, the preferred approach is to determine the
-incremental change you want to make and add that as a
-configuration fragment.
-For example, if you want to add support for a basic serial
-console, create a file named 8250.cfg in
+incremental changes you want to make and add each of those 
changes
+using a separate configuration fragment.
+For example, if you want to add support for a basic (8250 
UART-based) serial
+console, create a file named, for example, 
8250.cfg in
 the ${PN} directory with the following
 content (without indentation):
 
@@ -219,7 +222,7 @@
  CONFIG_SE

Re: [yocto] [PATCH] yocto-docs: Some aesthetic changes to kernel-dev-common.xml

[Robert P. J. Day]

On Thu, 23 Feb 2017, Hart, Darren wrote:

> > -Original Message-
> > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> > Sent: Thursday, February 23, 2017 3:08 AM
> > To: Yocto discussion list <yocto@yoctoproject.org>
> > Cc: Hart, Darren <darren.h...@intel.com>
> > Subject: [PATCH] yocto-docs: Some aesthetic changes to kernel-dev-
> > common.xml
> >
> >
> > Small number of aesthetic/visual changes to kernel-dev-common.xml.
> >
>
> Erm... that's not really what these are :-) These are a mix of
> grammatical fixes, format preferences, and clarifying commentary,
> which do amount to some functional changes in terms of what a reader
> may do or not do as a result of reading them. Please be explicit in
> your commit log.
>
> That said, I have no objections to these changes, the majority of
> which I consider to be good improvements. Thanks for taking the time
> to improve the documentation.

  so i should resubmit PATCH v2 with a more detailed commit msg? ok, i
can do that. stay tuned ...

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH] yocto-docs: Aesthetic changes to kernel-dev-intro.xml

[Robert P. J. Day]

* "sys" filesystem is technically "sysfs" filesystem
* "aggregate" already implies together :-)

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

diff --git a/documentation/kernel-dev/kernel-dev-intro.xml 
b/documentation/kernel-dev/kernel-dev-intro.xml
index 263e500..8de1f97 100644
--- a/documentation/kernel-dev/kernel-dev-intro.xml
+++ b/documentation/kernel-dev/kernel-dev-intro.xml
@@ -74,17 +74,17 @@
 visible CONFIG options as presented by the 
Linux
 kernel menuconfig system.
 Contrast this against a complete Linux kernel
-.config, which includes all the automatically
+.config file, which includes all the 
automatically
 selected CONFIG options.
 This efficiency reduces your maintenance effort and allows you
 to further separate your configuration in ways that make sense for
 your project.
 A common split separates policy and hardware.
 For example, all your kernels might support
-the proc and sys 
filesystems,
+the proc and sysfs 
filesystems,
 but only specific boards require sound, USB, or specific drivers.
 Specifying these configurations individually allows you to 
aggregate
-them together as needed, but maintains them in only one place.
+them as needed, but maintains them in only one place.
 Similar logic applies to separating source changes.
 


-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] Section 5.10.6, current YP reference manual, "default working directory"

[Robert P. J. Day]

On Wed, 22 Feb 2017, Burton, Ross wrote:

>
> On 22 February 2017 at 11:58, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>   so, *technically*, that claim in the ref manual is not wholly true;
>   there are still a small number of tasks that use that default
>   directory. is that a distinction worth making in the reference manual?
>
>
> The point was that tasks used to have ${B} as the working directory
> without any [dirs] set.  Now a task needs to set [dirs] if its wants
> to change the working directory.

  ah, now i get it.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] is there a list somewhere of OE/YP-supported system perf/monitoring tools?

[Robert P. J. Day]

On Wed, 8 Feb 2017, Joshua Lock wrote:

> On Wed, 2017-02-08 at 07:06 -0500, Robert P. J. Day wrote:
> > On Wed, 8 Feb 2017, Leon Woestenberg wrote:
> >
> > ... snip ...
> >
> > > blktrace
> >
> >   without putting any research into knowing precisely what these
> > utilities do, i put them into a list on a wiki page:
> >
> >  http://www.crashcourse.ca/wiki/index.php/OE_YP_performance_monitorin
> > g
>
> I think this list would be more useful on the Yocto Project wiki.

  i'm not trying to claim this is an official YP list, i just wanted
somewhere to write the list for now and my habit is to put everything
on a wiki page. if someone wants to start another page, i have no
problem with that. the reason i typically use my own wiki is that i
frequently customize those pages for my courses, so they could end up
with content that's not relevant for YP.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is there a list somewhere of OE/YP-supported system perf/monitoring tools?

[Robert P. J. Day]

On Wed, 8 Feb 2017, Leon Woestenberg wrote:

... snip ...

> blktrace

  without putting any research into knowing precisely what these
utilities do, i put them into a list on a wiki page:

 http://www.crashcourse.ca/wiki/index.php/OE_YP_performance_monitoring

given time, i'll add some commentary and break them into
sub-categories like user space, kernel space and so on. for now, i'll
just take more suggestions as to what should be on that list.

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] is there a list somewhere of OE/YP-supported system perf/monitoring tools?

[Robert P. J. Day]

On Wed, 8 Feb 2017, Maciej Borzęcki wrote:

> On Tue, Feb 7, 2017 at 3:31 PM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
> >
> >   colleague asked me for a list of OE/YP recipes for monitoring system
> > performance/resource utilization/profiling, i'm unaware of any single
> > list that tracks that sort of thing so i'll just ask what people are
> > aware of. just off the top of my head:
> >
> >  * sysstat
> >  * atop
> >  * collectd
> >  * netdata
> >  * rrdtool
> >  * dstat
>
> * pcp http://pcp.io/

  is there an OE recipe for that? i don't see one.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is there a list somewhere of OE/YP-supported system perf/monitoring tools?

[Robert P. J. Day]

On Wed, 8 Feb 2017, Leon Woestenberg wrote:

>
> On Wed, Feb 8, 2017 at 12:38 PM, Gary Thomas <g...@mlbassoc.com> wrote:
>   On 2017-02-08 07:48, Maciej Borzęcki wrote:
> On Tue, Feb 7, 2017 at 3:31 PM, Robert P. J. Day 
> <rpj...@crashcourse.ca> wrote:
>
>     colleague asked me for a list of OE/YP recipes for 
> monitoring
>   system
>   performance/resource utilization/profiling, i'm unaware of 
> any single
>   list that tracks that sort of thing so i'll just ask what 
> people are
>   aware of. just off the top of my head:
>
>    * sysstat
>    * atop
>    * collectd
>    * netdata
>    * rrdtool
>    * dstat
>
>
> * pcp http://pcp.io/
>
>
>   There is also bootchart (and friends) to gather information about
>   system startup and initialization.
>
>
> blktrace

  a colleague is looking for an OE utility similar to red hat's
"sosreport", but AFAICT, that utility is purely red hat and i see no
reference to it at the OE layers page. does anyone know something
remotely similar to that? or is it just a red hat wrapper around a
bunch of other tools (which is what it looks like).

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] is there a list somewhere of OE/YP-supported system perf/monitoring tools?

[Robert P. J. Day]

  colleague asked me for a list of OE/YP recipes for monitoring system
performance/resource utilization/profiling, i'm unaware of any single
list that tracks that sort of thing so i'll just ask what people are
aware of. just off the top of my head:

 * sysstat
 * atop
 * collectd
 * netdata
 * rrdtool
 * dstat

i'm going to stop there since that's just a sample list. what other
recipes should be added to that list that people find spectacularly
useful? thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] where does one find a OE/YP recipe for mod_auth_tkt?

[Robert P. J. Day]

  i was looking for this a while ago with no luck ... still
interested ... am i just being clueless in not seeing where to get it?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] how does one stay on top of YP security alerts?

[Robert P. J. Day]

  colleague wants to know how one stays up to date with security
alerts related to YP releases, i checked out the yocto-security
mailing list:

https://lists.yoctoproject.org/pipermail/yocto-security/

but that looks like a very dead mailing list. are there other options?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] has support for MPC8315E-RDB been dropped?

[Robert P. J. Day]

  i notice that if you search for the powerpc BSP in the latest
release here:

https://www.yoctoproject.org/downloads/bsps?release=98%5B%5D=22=

you get no match. i haven't been paying attention -- has yocto dropped
that board as its powerpc reference board? is it being replaced by a
newer powerpc system?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] questions about KBUILD_DEFCONFIG explanation in kernel-dev manual

[Robert P. J. Day]

  (yes, i really am digging through the user guides these days ...)

from kernel-dev manual, section 2.2.4:

  "To specify an "in-tree" defconfig file, edit the recipe that builds
   your kernel so that it has the following command form:

 KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file

   You need to append the variable with KMACHINE and then supply the
   path to your "in-tree" defconfig file."

first, i'm going to tag the "KMACHINE" part above with
, since it pretty clearly needs it.

  next, you need to "supply the path" to the defconfig file? uh, don't
you just need to give the simple name of the in-tree defconfig file
you want to use as it is somewhere under arch//configs in the
kernel source tree? here's a snippet from the meta-altera layer:

   KBUILD_DEFCONFIG ?= "socfpga_defconfig"
   KBUILD_DEFCONFIG_stratix10swvp ?= "defconfig"
   KBUILD_DEFCONFIG_10m50 ?= "10m50_defconfig"

seems like one needs just the name of the defconfig file to be used,
there's no concept of needing a "path" to the file, is there?

  next, it appears that one does *not* "need to append the variable
with KMACHINE", given one of the lines from meta-altera above, is that
correct? this just sets a default, no?

   KBUILD_DEFCONFIG ?= "socfpga_defconfig"

  and finally, must all defconfig files identified via
KBUILD_DEFCONFIG be an "in-tree" file? i ask since this line above:

   KBUILD_DEFCONFIG_stratix10swvp ?= "defconfig"

is potentially confusing, and might make someone perusing the source
to think that's an alternative way to point at their "out-of-tree"
defconfig file. but it's not, is it?

  i checked that machine type, and it's armv8, so i'm *assuming* that
line would refer to the in-tree file arch/arm64/configs/defconfig, is
that right?

  i think that will do it for now.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] potentially confusing wordage in kernel dev manual

[Robert P. J. Day]

  section 2.2.4:

  "By default, the OpenEmbedded build system looks for defconfig files
  in the layer used for Metadata, which is "out-of-tree", and then
  configures them using the following:

 SRC_URI += "file://defconfig"


um ... that wording makes it sounds like it's the OE build system
that automatically adds a local defconfig file to SRC_URI. does anyone
else see the potential confusion in the way that's explained?

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] in yocto-docs, many tags should properly be tags

[Robert P. J. Day]

  pretty sure i mentioned this once upon a time but, for pedantic
precision, quite a few strings currently tagged with  should
rather be tagged with . i'm currently proofing the kernel dev
manual and things like FILESPATH and FILESEXTRAPATHS are rendered with
the use of , which isn't really appropriate.

  *currently*, there is no difference in the final rendering of these
two tags, but one never knows when that might be desirable.

  obviously, not a high priority if any.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] "make html" for yocto-docs fails, "Unknown option -customization.xsl"

[Robert P. J. Day]

On Mon, 19 Dec 2016, Robert P. J. Day wrote:

>
>   been a while since i've built the docs from scratch, and now:
>
> $ make html
>
>  Building
>
> cd ; xsltproc  -o .html -customization.xsl .xml; cd ..
> Unknown option -customization.xsl
> Usage: xsltproc [options] stylesheet file [file ...]
>Options:
>... snip ...

   gh ... never mind, i forgot that i *need* to identify a manual,
it won't just build them all by default. apologies.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] "make html" for yocto-docs fails, "Unknown option -customization.xsl"

[Robert P. J. Day]

  been a while since i've built the docs from scratch, and now:

$ make html

 Building

cd ; xsltproc  -o .html -customization.xsl .xml; cd ..
Unknown option -customization.xsl
Usage: xsltproc [options] stylesheet file [file ...]
   Options:
   ... snip ...

  i'll take a quick look at how xsltproc has changed lately unless
someone else already knows what the fix is.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] [PATCH][yocto-docs] Couple aesthetic fixes for Chapter 1, kernel dev manual

[Robert P. J. Day]

* "sys" filesystem is technically "sysfs"

Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>

---

  nothing earth-shattering, just more pedantry.

diff --git a/documentation/kernel-dev/kernel-dev-intro.xml 
b/documentation/kernel-dev/kernel-dev-intro.xml
index 263e500..abc51aa 100644
--- a/documentation/kernel-dev/kernel-dev-intro.xml
+++ b/documentation/kernel-dev/kernel-dev-intro.xml
@@ -74,14 +74,14 @@
 visible CONFIG options as presented by the 
Linux
 kernel menuconfig system.
 Contrast this against a complete Linux kernel
-.config, which includes all the automatically
+.config file, which includes all the 
automatically
 selected CONFIG options.
 This efficiency reduces your maintenance effort and allows you
 to further separate your configuration in ways that make sense for
 your project.
 A common split separates policy and hardware.
 For example, all your kernels might support
-the proc and sys 
filesystems,
+the proc and sysfs 
filesystems,
 but only specific boards require sound, USB, or specific drivers.
 Specifying these configurations individually allows you to 
aggregate
 them together as needed, but maintains them in only one place.

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] suggestions for version controlling multi-layer reproducible builds?

[Robert P. J. Day]

  (if there's already a doc section for this somewhere, a pointer to
it would be just ducky.)

  if one is building an image for a releasable, commercial product,
and that image involves pulling in numerous layers, then dumping all
sorts of proprietary apps on top of it, what are the possibilities for
how to version number the released images such that, if a client has
an issue, they can identify precisely the state of components that
went into the system they're working with?

  in addition to all of the layers involved in the build, one has to
take into account that, when critical bugs are identified, an updated
RPM might be sent out and applied, whereupon that system's version
number is no longer perfectly accurate. in the end, the state of
someone's running system will be determined by a possibly huge
combination of selected packages, preferred package versions, build
config options, additional user space apps, hot fixes that have been
applied and so on.

  what sort of meaningful "version number" can be applied to something
like that? i'm sure at least a few other people have to be doing
something like that, so i'm open to suggestions.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

[yocto] should the MPC8315E-RDB be listed at YP BSPs page?

[Robert P. J. Day]

  just noticed that while that PPC reference board is described here:

  https://www.yoctoproject.org/downloads/bsps/krogoth21/mpc8315e-rdb

it's not mentioned at the more general YP BSPs page here:

  https://www.yoctoproject.org/downloads/bsps

under "Latest".  is it not still the current PowerPC reference board?
or how does one interpret that? thanks.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] any recommendations for ARM-powered, yocto-based drones?

[Robert P. J. Day]

  i want to get a drone, and i'd prefer that it was linux-powered --
specifically, i'd like an ARM-based drone with an OS created by yocto
project.

  i can see that there's an atom-powered drone here:

http://www.theregister.co.uk/2016/08/17/intel_aero_developer_board/

which runs "Yocto GNU/Linux", but i'd prefer something based on ARM.
any pointers?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] is there an OE/YP equivalent for sos[report]?

[Robert P. J. Day]

  from my fedora system:

$ dnf info sos
...
Summary : A set of tools to gather troubleshooting information from a system
...

  since it's written in python, it should be easy to package, but
since there's no obvious recipe for it right now, i'm wondering if
it's been obsoleted by something better.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] any yocto-supported ARM boards out there with BLE/BT?

[Robert P. J. Day]

  hoping someone can give me pointers ... i'm teaching an OE/yocto
class in january, client would prefer buying a bunch of
yocto-supported ARM boards that have BLE (bluetooth low energy) for
the students in the class.

  any suggestions? the boards need to be available, well, pretty much
now, and buyable from a major distributor. BLE is not a deal-breaker,
just would be nice.

  suggestions?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] why do some openstack layer.conf files add classes to BBFILES?

[Robert P. J. Day]

On Tue, 1 Nov 2016, Christopher Larson wrote:

>
> On Tue, Nov 1, 2016 at 1:57 AM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
>     just noticed the following property for a bunch of the openstack
>   layers at:
>
>   http://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/
>
>   some of the layer.conf files contain the line:
>
>   BBFILES += "${LAYERDIR}/recipes*/*/*.bb 
> ${LAYERDIR}/recipes*/*/*.bbappend
>   ${LAYERDIR}/classes/*.bbclass"
>
>   why is the classes/ directory being appended to BBFILES? i thought the
>   purpose of BBPATH was to contain locations of .conf and .bbclass
>   files. i'm puzzled by the above.
>
>
> You’re right to be puzzled, as that addition is pointless and will do nothing 
> useful.

  i already sent a patch to the meta-virt list to get rid of the
cruft.

rday

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] why do some openstack layer.conf files add classes to BBFILES?

[Robert P. J. Day]

  just noticed the following property for a bunch of the openstack
layers at:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/

some of the layer.conf files contain the line:

BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend 
${LAYERDIR}/classes/*.bbclass"

why is the classes/ directory being appended to BBFILES? i thought the
purpose of BBPATH was to contain locations of .conf and .bbclass
files. i'm puzzled by the above.

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] potentially confusing intro to what is in an SDK (SDK manual)

[Robert P. J. Day]

  more of the pedantic nitpickery you've all come to expect from me,
but in section 1.1 of SDK Manual (v. 2.2):

"All SDKs consist of the following:

Cross-Development Toolchain: This toolchain contains a compiler,
debugger, and various miscellaneous tools.

Libraries, Headers, and Symbols: The libraries, headers, and
symbols are specific to the image (i.e. they match the image).

Environment Setup Script: This *.sh file, once run, sets up the
cross-development environment by defining variables and preparing
for SDK use. "

hang on ... that last reference to an ".sh" file is potentially
misleading. the generated SDK itself is bundled into the installation
script (say,
poky-glibc-x86_64-core-image-minimal-ppce300c3-toolchain-2.2.sh), and
when that's run, what is installed contains, at the top level, the
setup script "environment-setup-ppce300c3-poky-linux" -- there is no
.sh script installed in the SDK installation directory.

  it might be common to create the symlink for convenience:

environment-setup-ppce300c3-poky-linux -> env.sh

or something like that, but AFAICT, there is no ".sh" setup script in
the SDK installation directory.

  is it possible the author was conflating the installation .sh file,
and the environment setup file?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] SDK manual is not listed on docs page

[Robert P. J. Day]

  i don't see link to SDK manual here:

https://www.yoctoproject.org/documentation/inprogress

is that deliberate, or an oversight?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] what is the proper way to select a persistent /var/log directory?

[Robert P. J. Day]

  just used the google to dig into that, found a number of references
to an alleged VOLATILE_LOG_DIR variable, but it seems to have not been
implemented, so should i assume this is done via the fs-perms.txt
file? or how *is* it done?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] OE/YP on digi connectcore 6, and upcoming linuxcon in toronto

[Robert P. J. Day]

  first, just last week, i taught an entire week on OE/YP on the digi
connectcore 6:

http://www.digi.com/products/embedded-systems/single-board-computers/connectcore-6-sbc

and, as i always do, i wrote a bunch of wiki pages on it to use during
the class, so you're welcome to them:

  http://www.crashcourse.ca/wiki/index.php/Digi_CC6

not claiming those pages are totally self-contained/stand alone, but
they're what i used and if they're helpful, terrific.

  second, i'm in toronto next week for linux con/container con, so if
any OE/YP are going to be there, hey, let's do dinner. or something.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] How to maintain a global DL_DIR?

[Robert P. J. Day]

On Wed, 17 Aug 2016, Gary Thomas wrote:

> On 2016-08-16 18:38, Robert P. J. Day wrote:
> > On Tue, 16 Aug 2016, Khem Raj wrote:
> >
> > > > On Aug 16, 2016, at 8:37 AM, Robert P. J. Day <rpj...@crashcourse.ca>
> > > > wrote:
> > > >
> > > > On Tue, 16 Aug 2016, Patrick Doyle wrote:
> > > >
> > > > > As I am playing with several different Yocto/OE projects, I thought
> > > > > it would be nice to set up a global downloads directory.
> > > > >
> > > > > Also, being a somewhat forgetful sort, I thought it would be nice if
> > > > > I could set DL_DIR in my .bashrc and not have to remember to edit
> > > > > conf/local.conf each time I follow the directions from a third party
> > > > > site to set up their Yocto based distribution.
> > > > >
> > > > > Can I do this?  If so, how?
> > > >
> > > > if you're talking about creating a local source mirror for tarballs
> > > > to be shared across multiple projects, i taught an OE/YP course last
> > > > week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
> > > > pages for it, including this one:
> > > >
> > > > http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror
> > >
> > > a small nit, perhaps its better to use rsync instead of cp.
> >
> >   good point, i will adjust that later. anything else i overlooked?
>
> I use the attached script to manage my download mirror.  There are
> two differences with the one Robert proposed:
>
> * It copies all files, regardless of name.  This is important if you
>   want your download mirror to be useful in a no-network environment
>   (which seems to be very important to some of my larger customers)
>   I normally run my builds with BB_NO_NETWORK="1" which lets me know
>   immediately if my download mirror needs updating.  I disable BB_NO_NETWORK
>   to download the new images, then update the mirror and turn it back
>   on again.

  i can appreciate that ... i'm always a little irked that the bash
patches are downloaded from the 'Net.

> * Once uploaded to the mirror, files are replaced by symbolic links
>   just as if the file had been present in the first place.  This has
>   two benefits - the downloads directory stays as small as possible
>   and the next time the 'save_downloads' script runs, it won't have
>   to bother with files already uploaded.  I use this process on a
>   number of build machines, some with Poky/Yocto build trees that have
>   been around for a long time (sometimes years) and keeping all those
>   old files in 'downloads' can really add up.

  true, but given that i keep my local mirror reasonably up to date,
i'm not overly concerned about leaving the occasional downloaded
tarball in a project directory. but here's something i *am* still
curious about.

  after a while, if you just keep adding to your local mirror, it gets
bigger and bigger and ... after a while, will contain versions of
tarballs that are utterly obsolete in that no current recipes refer to
them anymore, and it's useful to just clear out the rubbish once in a
while.

  is there a clever way to do that? is there some way to list all
versions of all sopurce that are, in any way, referenced by the
current set of recipes in the layers you have? after all, just because
you have a newer version of a tarball in no way means that the older
version(s) are unnecessary.

  way back when, i came up with a hacky solution: i start a new
project, point it at my local mirror, then run:

  $ bitbake -c fetchall world

what i end up with is, of course, piles of symlinks in the downloads/
directory, plus any new content as actual tarballs. at that point, if
i think what i've downloaded represents a decent cleaned
representation, everything in the downloads/ directory is used as the
basis for a new local source mirror, and the rest is thrown away.

  sure, i'm likely to toss a few things that will be referenced in the
future but so what, they'll be downloaded again and life will go on.
or is there a more clever way to do this?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: [yocto] How to maintain a global DL_DIR?

[Robert P. J. Day]

On Wed, 17 Aug 2016, Gary Thomas wrote:

> On 2016-08-16 18:38, Robert P. J. Day wrote:
> > On Tue, 16 Aug 2016, Khem Raj wrote:
> >
> > > > On Aug 16, 2016, at 8:37 AM, Robert P. J. Day <rpj...@crashcourse.ca>
> > > > wrote:
> > > >
> > > > On Tue, 16 Aug 2016, Patrick Doyle wrote:
> > > >
> > > > > As I am playing with several different Yocto/OE projects, I thought
> > > > > it would be nice to set up a global downloads directory.
> > > > >
> > > > > Also, being a somewhat forgetful sort, I thought it would be nice if
> > > > > I could set DL_DIR in my .bashrc and not have to remember to edit
> > > > > conf/local.conf each time I follow the directions from a third party
> > > > > site to set up their Yocto based distribution.
> > > > >
> > > > > Can I do this?  If so, how?
> > > >
> > > > if you're talking about creating a local source mirror for tarballs
> > > > to be shared across multiple projects, i taught an OE/YP course last
> > > > week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
> > > > pages for it, including this one:
> > > >
> > > > http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror
> > >
> > > a small nit, perhaps its better to use rsync instead of cp.
> >
> >   good point, i will adjust that later. anything else i overlooked?
>
> I use the attached script to manage my download mirror...

  well, *that* escalated quickly. :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] How to maintain a global DL_DIR?

[Robert P. J. Day]

On Tue, 16 Aug 2016, Khem Raj wrote:

> > On Aug 16, 2016, at 8:37 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> > On Tue, 16 Aug 2016, Patrick Doyle wrote:
> >
> >> As I am playing with several different Yocto/OE projects, I thought
> >> it would be nice to set up a global downloads directory.
> >>
> >> Also, being a somewhat forgetful sort, I thought it would be nice if
> >> I could set DL_DIR in my .bashrc and not have to remember to edit
> >> conf/local.conf each time I follow the directions from a third party
> >> site to set up their Yocto based distribution.
> >>
> >> Can I do this?  If so, how?
> >
> >  if you're talking about creating a local source mirror for tarballs
> > to be shared across multiple projects, i taught an OE/YP course last
> > week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
> > pages for it, including this one:
> >
> > http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror
>
> a small nit, perhaps its better to use rsync instead of cp.

  good point, i will adjust that later. anything else i overlooked?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] How to maintain a global DL_DIR?

[Robert P. J. Day]

On Tue, 16 Aug 2016, Patrick Doyle wrote:

> As I am playing with several different Yocto/OE projects, I thought
> it would be nice to set up a global downloads directory.
>
> Also, being a somewhat forgetful sort, I thought it would be nice if
> I could set DL_DIR in my .bashrc and not have to remember to edit
> conf/local.conf each time I follow the directions from a third party
> site to set up their Yocto based distribution.
>
> Can I do this?  If so, how?

  if you're talking about creating a local source mirror for tarballs
to be shared across multiple projects, i taught an OE/YP course last
week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
pages for it, including this one:

http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror

that explains how to create a globally accessible directory full of
tarballs, how to configure each new project to look there first, and
there's even a script so that, if a new project *does* have to
download a bit of stuff that's not in your local source mirror, you
can run that script from the downloads/ directory, and it will copy
all the newly-downloaded stuff into your local source mirror.

  let me know if anything on that page is unclear.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] can one use "ASSUME_PROVIDED += mono-native" to avoid compiling?

[Robert P. J. Day]

  built mono for the first time, and a significant amount of time was
spent compiling mono-native. if i already have mono on my build host,
is it worth checking if i can take advantage of it?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] what IMAGE_TYPES are valid to pass as "initrd" param to "bootm"?

[Robert P. J. Day]

  not at my dev machine right now, otherwise i'm sure i could figure
this out, but what possible values for IMAGE_FSTYPES are acceptable to
download to u-boot and pass to "bootm" directly as the second argument
for the initrd?

rday

-- 

========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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