[yocto] the current dev manual seems to overly emphasize the importance of meta-intel

[Robert P. J. Day]

  perusing the current dev manual and it reads:

"Supported Board Support Packages (BSPs): The Yocto Project provides a
layer called meta-intel and it is maintained in its own separate Git
repository..."

  this wording *seems* to suggest there is something magical about the
meta-intel layer as compared to the numerous other layers. in
particular, this statement further down just adds to that impression:

"To get started with the BSPs, you need to use Git to create a local
clone of the upstream repository."

  i see no problem with using the meta-intel layer as an *example* but
that section should be reworded to not make the reader think that
meta-intel is unique in some weird sense. just my $0.02.

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] does anything still use "meta-yocto-kernel-extras"?

[Robert P. J. Day]

  still in dev manual (where i'll be all day, i suspect), section 2.2
refers to the layer meta-yocto-kernel-extras, but i don't recall
seeing *anything* that uses that layer (anymore?).

  i just grepped through all of the layers i have checked out and
found not a single instance of the string "meta-yocto-kernel-extras",
other than in the documentation that mentions it.

  is it still valid? still used somewhere?

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] Documentation: A few tweaks to chapter 2 of the dev manual.

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

  scott (or anyone else) is welcome to use any or all of this, or
tweak to taste. i have a few other concerns with ch 2 but i'll read it
more carefully to make sure i'm reading it correctly.

diff --git a/documentation/dev-manual/dev-manual-start.xml 
b/documentation/dev-manual/dev-manual-start.xml
index 1a16b9f..478b8ee 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -34,7 +34,7 @@
 You can use the OpenEmbedded build system, which uses
 BitBake, to develop complete Linux
 images and associated user-space applications for architectures based
-on ARM, MIPS, PowerPC, x86 and x86-64.
+on ARM, MIPS, MIPS64, PowerPC, x86 and x86-64.
 
 By default, using the Yocto Project creates a Poky distribution.
 However, you can create your own distribution by providing key
@@ -55,12 +55,12 @@
 Getting Set Up

 
-Here is what you need to get set up to use the Yocto Project:
+Here is what you need to use the Yocto Project:
 
 Host System:  You should have 
a reasonably current
 Linux-based host system.
 You will have the best results with a recent release of Fedora,
-OpenSUSE, Debian, Ubuntu, or CentOS as these releases are 
frequently tested against the Yocto Project
+openSUSE, Debian, Ubuntu, or CentOS as these releases are 
frequently tested against the Yocto Project
 and officially supported.
 For a list of the distributions under validation and their 
status, see the
 "Supported Linux 
Distributions" section
@@ -70,7 +70,7 @@
 You should also have about 100 gigabytes of free disk space 
for building images.
 
 Packages:  The OpenEmbedded 
build system
-requires certain packages exist on your development system 
(e.g. Python 2.6 or 2.7).
+requires that certain packages exist on your development 
system (e.g. Python 2.6 or 2.7).
 See "The 
Packages"
 section in the Yocto Project Quick Start and the
 "Required
 Packages for the Host Development System"
@@ -85,7 +85,8 @@
 Source Directory
 and is created when you use
 Git to clone a local copy
-of the upstream poky repository.
+of the upstream poky repository,
+or when you download an official release of the corresponding 
tarball.
 Working from a copy of the upstream repository allows you
 to contribute back into the Yocto Project or simply work with
 the latest software on a development branch.
@@ -122,7 +123,7 @@
 Yocto Project 
Kernel:
 If you are going to be making modifications to a supported 
Yocto Project kernel, you
 need to establish local copies of the source.
-You can find Git repositories of supported Yocto Project 
Kernels organized under
+You can find Git repositories of supported Yocto Project 
kernels organized under
 "Yocto Linux Kernel" in the Yocto Project Source Repositories 
at
 .
 This setup can involve creating a bare clone of the 
Yocto Project kernel and then

-- 


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] i think the explanation of "Build Directory" in dev manual is wrong

[Robert P. J. Day]

  here:

http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms

explanation of "Build Directory", one reads (start quote):

Provide a directory path and specifically name the build directory.
This next example creates a Build Directory named YP-11.0.0 in your
home directory within the directory mybuilds. If mybuilds does not
exist, the directory is created for you:

 $ source poky-tbd-11.0.0/oe-init-build-env $HOME/mybuilds/YP-11.0.0

Provide an existing directory to use as the Build Directory and use
the default build name.

 $ source poky-tbd-11.0.0/oe-init-build-env $HOME/mybuilds/

 === end quote ===

  i don't think either of those is correct, are they? pretty sure that
oe-init-build-env *doesn't* create intermediate directories and, in
that second example, wouldn't that just use ~/mybuilds as the build
directory? i don't foresee a default build name subdirectory being
created there. 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] Documentation: Small number of tweaks to ch 3, development manual.

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/dev-manual/dev-manual-newbie.xml 
b/documentation/dev-manual/dev-manual-newbie.xml
index 600c789..58343dc 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -430,7 +430,7 @@
 
 The recommended method for setting up the Yocto Project
 Source Directory and the
-files for supported BSPs (meta-intel) is to
+files for supported BSPs (eg., meta-intel) is 
to
 use Git to create a local copy of the
 upstream repositories.
 
@@ -810,7 +810,8 @@
 Git

 
-The Yocto Project uses Git, which is a free, open source distributed 
version control system.
+The Yocto Project makes extensive use of Git,
+which is a free, open source distributed version control system.
 Git supports distributed development, non-linear development, and can 
handle large projects.
 It is best that you have some fundamental understanding of how Git 
tracks projects and
 how to work with Git if you are going to use the Yocto Project for 
development.
@@ -914,7 +915,7 @@
 local working branch based on a branch name,
 your local environment matches the "tip" of that development branch
 at the time you created your local branch, which could be
-different than the files at the time of a similarly named release.
+different from the files at the time of a similarly named release.
 In other words, creating and checking out a local branch based on 
the
 &DISTRO_NAME; branch name is not the same as
 cloning and checking out the master branch.
@@ -1007,7 +1008,7 @@
 will allow the change, and for ultimately pushing the 
change from your local Git repository
 into the project’s upstream (or master) 
repository.
 git 
status: Reports any modified files that
-possibly need staged and committed.
+possibly need to be staged and committed.
 git checkout 
: Changes
 your working branch.
 This command is analogous to "cd".
@@ -1284,10 +1285,9 @@
 Board Support Package (BSP) README 
Files:
 For BSP maintainers of supported BSPs, you can examine
 individual BSP README files.
-Alternatively, you can examine the
-MAINTAINERS file, which is found in the
-meta-intel, for a list of all supported
-BSP maintainers.
+In addition, some layers (such as the 
meta-intel layer),
+include a MAINTAINERS file which contains
+a list of all supported BSP maintainers for that layer.
 
 Search by File:
 Using Git, you can enter the

-- 


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] ldd

[Seth Bollinger]

Hello All,

I don't see that ldd is part of the cross toolchain build anywhere.  Am I
missing something?

Thanks,

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

Re: [yocto] ldd

[Gary Thomas]

On 2013-11-09 06:42, Seth Bollinger wrote:

Hello All,

I don't see that ldd is part of the cross toolchain build anywhere.  Am I 
missing something?


It's built with the eglibc recipe and is packaged separately.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Yocto zedboard v4l-utils & 3.6.0 kernel with C920 webcam sucess

[Edward Vidal]

Hello all,
I finally was able to get the modules needed to support the C920 webcam.
The modules needed were a total of eight.
 tree 3.6.0-digilent-13.01-2-g06b3889
3.6.0-digilent-13.01-2-g06b3889
├── kernel
│   └── drivers
│   └── media
│   └── video
│   ├── gspca
│   │   └── gspca_main.ko
│   ├── uvc
│   │   └── uvcvideo.ko
│   ├── v4l2-common.ko
│   ├── v4l2-int-device.ko
│   ├── videobuf2-core.ko
│   ├── videobuf2-memops.ko
│   ├── videobuf2-vmalloc.ko
│   └── videodev.ko
├── myled.ko
└── pmodoled-gpio.ko

6 directories, 10 files
I built the core-image-sato for the zedboard which installed 1463 RPMs.  I
built a core-image-sato-sdk for the beagleboard with boost qt-mobility-x11
gsl gnuplot gnuradio boost, v4l-utils and python-netserver
which I installed with the rpm command increased the package count to 1559.

I used the boneCV for capture routine Modifications, added the -F mode for
H264 capture and associated help detail
 *  www.derekmolloy.ie on the zedboard and raw2mpg4 on Fedora18x86_64.
ffmpeg is my next task.

git remote show origin
* remote origin
  Fetch URL: https://github.com/derekmolloy/boneCV.git
  Push  URL: https://github.com/derekmolloy/boneCV.git
  HEAD branch: master
  Remote branch:
master tracked
  Local branch configured for 'git pull':
master merges with remote master
  Local ref configured for 'git push':
master pushes to master (up to date)

Thanks all for all the support.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] i think the explanation of "Build Directory" in dev manual is wrong

[Michael Gloff]

The build dir will definitely be created by the script(s) (assuming
permissions). The default build dir will be created under the level of the
script as 'build', but you can specify any path.

As you point this out I see the sentence:

The 
TOPDIRvariable
points to the Build Directory.

can be ambiguous. TOPDIR is not well defined. Maybe it should be called
BUILD_DIR and defined somewhere in local.conf as a default commented out
like DL_DIR and TMPDIR in addition to the ability to specify BUILD_DIR on
the command line.

Michael Gloff



On Sat, Nov 9, 2013 at 4:09 AM, Robert P. J. Day wrote:

>
>   here:
>
>
> http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms
>
> explanation of "Build Directory", one reads (start quote):
>
> Provide a directory path and specifically name the build directory.
> This next example creates a Build Directory named YP-11.0.0 in your
> home directory within the directory mybuilds. If mybuilds does not
> exist, the directory is created for you:
>
>  $ source poky-tbd-11.0.0/oe-init-build-env $HOME/mybuilds/YP-11.0.0
>
> Provide an existing directory to use as the Build Directory and use
> the default build name.
>
>  $ source poky-tbd-11.0.0/oe-init-build-env $HOME/mybuilds/
>
>  === end quote ===
>
>   i don't think either of those is correct, are they? pretty sure that
> oe-init-build-env *doesn't* create intermediate directories and, in
> that second example, wouldn't that just use ~/mybuilds as the build
> directory? i don't foresee a default build name subdirectory being
> created there. 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
>



-- 
Michael Gloff

mgl...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 310
 618-457-0110 Fax
 2390 EMAC Way
Carbondale, Il 62901
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto