Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 04/09/12 21:25, William Mills wrote:
> I suspect the current issue is just growing pains for a case that has
> not been tested.
The simplest fix would be for meta-ti to preppend itself to the path the
same way meta-yocto does, i.e., in the layer.conf
BBPATH := "${LAYERDIR}:${BBPATH}"
In fact, this is the *only* way that a layer can override any conf files
in oe-core, which is probably what you always want in a BSP layer?
Just quickly scanning yocto git, there are a number of BSP layers that
are configured the same way as meta-ti, so potentially have the same
problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
layers configured this way too, but I think it's only a big issue for
BSP layers and distro layers.)
As long as we are mixing layers that do both prepend and append, the
layering will continue to be broken in subtle and hard to identify ways.
I can't think of a practical use case where a layer other than oe-core
might need to append itself to the BBPATH? If there were no genuine need
for layers to append to the path, the BBPATH extension could be done
automatically when including the layer, instead doing manually in each
layer.conf, giving us some consistency.
> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
> poky distro defs? That does seem to mixing things a bit. (I am not
> claiming meta-ti is clean yet but I want to understand the Intel examples.)
I apologize for getting this wrong, meta-intel is not dependent on
meta-yocto (the meta-yocto bbappends are only apply to the machines
meta-yocto itself contains configs for). But you do need meta-yocto for
the atom-pc machine, because meta-yocto is the BSP layer for that (and
should Intel decide to add an atom-pc to meta-intel, it will be broken
exactly the same as the beagleboard machine is just now).
Tomas
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> The simplest fix would be for meta-ti to preppend itself to the path the
> same way meta-yocto does, i.e., in the layer.conf
>
> BBPATH := "${LAYERDIR}:${BBPATH}"
>
> In fact, this is the *only* way that a layer can override any conf files
> in oe-core, which is probably what you always want in a BSP layer?
>
> Just quickly scanning yocto git, there are a number of BSP layers that
> are configured the same way as meta-ti, so potentially have the same
> problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
> layers configured this way too, but I think it's only a big issue for
> BSP layers and distro layers.)
>
> As long as we are mixing layers that do both prepend and append, the
> layering will continue to be broken in subtle and hard to identify ways.
> I can't think of a practical use case where a layer other than oe-core
> might need to append itself to the BBPATH? If there were no genuine need
> for layers to append to the path, the BBPATH extension could be done
> automatically when including the layer, instead doing manually in each
> layer.conf, giving us some consistency.
It has been considered witin OE to be best practice to append to BBPATH and
not prepend, the thinking being that then the search path matches the order of
the layers listed in bblayers.conf rather than the reverse. I'm not sure I
agree with it (I tend to prefer to list OE-Core first), but that's the
convention adopted there.
Quite a few people have asked for the items which BBPATH controls (classes,
conf files) to instead be found in layer priority order. If bitbake took over
managing BBPATH, that would be a possibility, and as you say it would improve
consistency at the expense of a little flexibility.
> But you do need meta-yocto for the atom-pc machine, because meta-yocto is
> the BSP layer for that (and should Intel decide to add an atom-pc to
> meta-intel, it will be broken exactly the same as the beagleboard machine is
> just now).
Some time ago we discussed the possibility of moving the atom-pc BSP to meta-
intel and then copying it back into meta-yocto, once the layer tooling allowed
for that to be done dynamically. Since the layer tooling is now in place that
is at least a practical possibility, but I'm not sure if it's still on the
cards - it still makes sense to me at any rate.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 05/09/12 10:15, Paul Eggleton wrote: > On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote: > It has been considered witin OE to be best practice to append to BBPATH and > not prepend, the thinking being that then the search path matches the order > of > the layers listed in bblayers.conf rather than the reverse. Then meta-yocto should follow that convention ... and it needs to be well documented, with the consequence of breaking that convention explained, and the terrible punishments to come described in great and sordid detail. Because this needs to be more than a convention, it needs to be an article of faith. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
On 03/09/12 22:00, Tomas Frydrych wrote: Hi Jack, On 03/09/12 18:52, Jack Mitchell wrote: As some of you know I run a small Raspberry Pi community site[1] and I would like to write a follow up to an earlier blog post about preparing yourself for programming on the Raspberry Pi with the Yocto Project. I don't know if of any use to you, but we have a recipe for a Yocto-based image for a UPnP audio player, which can be built for the RPi, in Guacamayo[1]. Tomas [1] https://github.com/Guacamayo/meta-guacamayo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto This is now livefor anyone interested. http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7 -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [Yocto #3044]Set JavaSource=1.6 for headless build
- @Override annotations can be used starting with jre >= 1.6
- Headless build plugin limited the java compilation to 1.5 (no matter what the
system jdk is)
Signed-off-by: Ioana Grigoropol
---
.../org.yocto.sdk.headless.build/build.properties |4 ++--
.../sdk/remotetools/wizards/bsp/MainPage.java |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/features/org.yocto.sdk.headless.build/build.properties
b/features/org.yocto.sdk.headless.build/build.properties
index 24ccf99..9a3e4d9 100644
--- a/features/org.yocto.sdk.headless.build/build.properties
+++ b/features/org.yocto.sdk.headless.build/build.properties
@@ -247,10 +247,10 @@ javacVerbose=true
#compilerArg=
# Default value for the version of the source code. This value is used when
compiling plug-ins that do not set the Bundle-RequiredExecutionEnvironment or
set javacSource in build.properties
-javacSource=1.5
+javacSource=1.6
# Default value for the version of the byte code targeted. This value is used
when compiling plug-ins that do not set the Bundle-RequiredExecutionEnvironment
or set javacTarget in build.properties.
-javacTarget=1.5
+javacTarget=1.6
#individualSourceBundles=true
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index 861cb08..fea1c76 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
@@ -520,12 +520,12 @@ public class MainPage extends WizardPage {
BuildLocationListener(String value){
this.value = value;
}
- //@Override
+ @Override
public void focusGained(FocusEvent e) {
value = ((Text)e.getSource()).getText();
}
- //@Override
+ @Override
public void focusLost(FocusEvent e) {
if(!((Text)e.getSource()).getText().equals(value)) {
checkBuildDir();
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote: > On 05/09/12 10:15, Paul Eggleton wrote: > > On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote: > > It has been considered witin OE to be best practice to append to BBPATH and > > not prepend, the thinking being that then the search path matches the order > > of > > the layers listed in bblayers.conf rather than the reverse. > > Then meta-yocto should follow that convention ... and it needs to be > well documented, with the consequence of breaking that convention > explained, and the terrible punishments to come described in great and > sordid detail. Because this needs to be more than a convention, it needs > to be an article of faith. I just want to clarify something here. Its accepted that most layers will append to BBPATH. I do think its acceptable for a distro policy layer to prepend though and this is why meta-yocto does this. I don't remember the exact reason right now but the principle stands. The root of the problem is that meta-yocto mixes up policy and hardware support which is bad. It also means its not compliant with the new Yocto Project compliance criteria and hence is not Yocto Project Compatible. Now we've got the compliance criteria sorted out there are some adjustments that need to be made and I will shortly be cleaving meta-yocto into two pieces to resolve this. I hadn't looked at this until now mainly in case there were changes to the criteria. FWIW I think this shows the strength of those criteria as by following them, we'd avoid a real world problem here. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 09/04/2012 07:23 PM, Darren Hart wrote: On 09/04/2012 01:25 PM, William Mills wrote: Darren: Is it true you can't get @ the Intel BSP's w/o also getting the poky distro defs? That does seem to mixing things a bit. (I am not claiming meta-ti is clean yet but I want to understand the Intel examples.) It isn't something we test as part of the QA that we perform. I mostly expect people building meta-intel to be building with meta-yocto (although I wouldn't take a hard line on requiring it). That said, I removed meta-yocto from a meta-intel/meta-fri2 build and removed DISTRO=poky from my local.conf and successfully built and booted a core-image-minimal build on an FRI2 this afternoon without any changes. Thanks! My confidence is restored. As long as including meta-yocto does not interfere with other BSPs or distros etc then there should be no harm in your assumption. I would be interested to know what Mentor Graphics and Wind River do on their products. Do they include meta-yocto? (YP is not all about comercial OS support but I know these orginatations have done the due diligence on layer compatibility for a non-poky distro.) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 00/12] Documentation fixes
Documentation fixes for the recent package group changes as well as a few other things I noticed along the way. The following changes since commit 12f77236b602e9ec43e845c8cec060ad342af19c: documentation: Fixed links to BitBake User Manual (2012-09-04 12:05:21 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib paule/doc-fixes-pg http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/doc-fixes-pg Paul Eggleton (12): documentation/bsp-guide, dev-manual-bsp-appendix: remove references to task bbappend documentation/poky-ref-manual: fix for rename of task to packagegroup documentation/dev-manual: fix for package group changes documentation/poky-ref-manual: improve IMAGE_FEATURES reference documentation/poky-ref-manual: replace reference to old files documentation/poky-ref-manual: update the default value of PACKAGES documentation/poky-ref-manual: variable reference clarifications and fixes documentation/poky-ref-manual: add packagegroup.bbclass to classes documentation/poky-ref-manual: update undocumented classes list documentation/poky-ref-manual: update images reference section documentation/yocto-project-qs: adjust GUI component feature listing documentation/poky-ref-manual: remove references to Dates and Contacts documentation/bsp-guide/bsp.xml| 24 --- .../dev-manual/dev-manual-bsp-appendix.xml | 29 .../dev-manual/dev-manual-common-tasks.xml | 48 ++--- documentation/poky-ref-manual/ref-bitbake.xml |8 +-- documentation/poky-ref-manual/ref-classes.xml | 50 - documentation/poky-ref-manual/ref-features.xml | 28 +--- documentation/poky-ref-manual/ref-images.xml | 17 +++-- documentation/poky-ref-manual/ref-variables.xml| 75 +--- .../yocto-project-qs/yocto-project-qs.xml | 10 +-- 9 files changed, 154 insertions(+), 135 deletions(-) -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 01/12] documentation/bsp-guide, dev-manual-bsp-appendix: remove references to task bbappend
The meta-intel BSPs and yocto-bsp tool no longer use a bbappend of task-core-tools-profile to add systemtap, so these sections should be removed. Signed-off-by: Paul Eggleton --- documentation/bsp-guide/bsp.xml| 24 .../dev-manual/dev-manual-bsp-appendix.xml | 29 2 files changed, 53 deletions(-) diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index 0c7ead5..5bfa9fb 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml @@ -172,9 +172,6 @@ meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig - meta-crownbay/recipes-core/ - meta-crownbay/recipes-core/tasks/ - meta-crownbay/recipes-core/tasks/task-core-tools-profile.bbappend meta-crownbay/recipes-graphics/ meta-crownbay/recipes-graphics/xorg-xserver/ meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend @@ -447,27 +444,6 @@ - -Core Recipe Files - -You can find these files in the BSP Layer at: - - meta-/recipes-core/* - - - - -This directory contains recipe files that are almost always necessary to build a -useful, working Linux image. -Thus, the term "core" is used to group these recipes. -For example, in the Crown Bay BSP there is the -task-core-tools-profile.bbappend file, which is an append file used -to recommend that the -SystemTap -package be included as a package when the image is built. - - - Display Support Files diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml index 98ed837..50a0049 100644 --- a/documentation/dev-manual/dev-manual-bsp-appendix.xml +++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml @@ -358,35 +358,6 @@ - - Changing recipes-core - - -Now let's look at changes in recipes-core. -The file task-core-tools.bbappend in -recipes-core/tasks appends the similarly named recipe -located in the source directory at -meta/recipes-core/tasks. -The append file in our layer right now is Crown Bay-specific and supports -EMGD and non-EMGD. -Here are the contents of the file: - - RRECOMMENDS_task-core-tools-profile_append_crownbay = " systemtap" - RRECOMMENDS_task-core-tools-profile_append_crownbay-noemgd = " systemtap" - - - - -The RRECOMMENDS statements list packages that -extend usability. -The first RRECOMMENDS statement can be removed, while the -second one can be changed to reflect meta-mymachine: - - RRECOMMENDS_task-core-tools-profile_append_mymachine = " systemtap" - - - - Changing recipes-kernel -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 02/12] documentation/poky-ref-manual: fix for rename of task to packagegroup
Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-bitbake.xml |2 +- documentation/poky-ref-manual/ref-variables.xml |8 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml index 330d72e..ff8db59 100644 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ b/documentation/poky-ref-manual/ref-bitbake.xml @@ -124,7 +124,7 @@ Once a provider is selected, BitBake resolves all the dependencies for the target. In the case of core-image-sato, it would lead to -task-base.bb, +packagegroup-base.bb, which in turn leads to packages like Contacts, Dates and BusyBox. These packages in turn depend on eglibc and the toolchain. diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index 362ece4..b1e3cd3 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -1311,7 +1311,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" The build process depends on these packages being present. Furthermore, because this is a "machine essential" variable, the list of packages are essential for the machine to boot. -The impact of this variable affects images based on task-core-boot, +The impact of this variable affects images based on packagegroup-core-boot, including the core-image-minimal image. @@ -1341,7 +1341,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" The build process does not depend on these packages being present. Furthermore, because this is a "machine essential" variable, the list of packages are essential for the machine to boot. -The impact of this variable affects images based on task-core-boot, +The impact of this variable affects images based on packagegroup-core-boot, including the core-image-minimal image. @@ -1388,7 +1388,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" Even though these packages are not essential for the machine to boot, the build process depends on them being present. The impact of this variable affects all images based on -task-base, which does not include the +packagegroup-base, which does not include the core-image-minimal or core-image-basic images. @@ -1425,7 +1425,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" The package being built has no build dependency on the list of packages with this variable. The impact of this variable affects only images based on -task-base, which does not include the +packagegroup-base, which does not include the core-image-minimal or core-image-basic images. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 03/12] documentation/dev-manual: fix for package group changes
Task has been renamed to package group, and there are some minor changes in how package group recipes should be constructed - in particular the inherit of packagegroup.bbclass is now highly recommended as it will set appropriate defaults and automatically add complementary -dev and -dbg packages. Signed-off-by: Paul Eggleton --- .../dev-manual/dev-manual-common-tasks.xml | 48 ++-- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index bdf59de..5e9f5e7 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -465,7 +465,7 @@ One way to get additional software into an image is to create a custom image. The following example shows the form for the two lines you need: - IMAGE_INSTALL = "task-core-x11-base package1 package2" + IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2" inherit core-image @@ -494,58 +494,58 @@ -Customizing Images Using Custom Tasks +Customizing Images Using Custom Package Groups -For complex custom images, the best approach is to create a custom task package +For complex custom images, the best approach is to create a custom package group recipe that is used to build the image or images. -A good example of a tasks package is -meta/recipes-core/tasks/task-core-boot.bb +A good example of a package group recipe is + meta/recipes-core/packagegroups/packagegroup-core-boot.bb. The PACKAGES -variable lists the task packages to build along with the complementary --dbg and -dev packages. -For each package added, you can use +variable lists the package group packages you wish to produce. inherit packagegroup +sets appropriate default values and automatically adds -dev and -dbg complementary +packages for every package specified in PACKAGES. Note that the inherit line should be towards +the top of the recipe, certainly before you set PACKAGES. +For each package you specify in PACKAGES, you can use RDEPENDS and RRECOMMENDS entries to provide a list of packages the parent task package should contain. Following is an example: - DESCRIPTION = "My Custom Tasks" + DESCRIPTION = "My Custom Package Groups" + + inherit packagegroup PACKAGES = "\ - task-custom-apps \ - task-custom-apps-dbg \ - task-custom-apps-dev \ - task-custom-tools \ - task-custom-tools-dbg \ - task-custom-tools-dev \ + packagegroup-custom-apps \ + packagegroup-custom-tools \ " - RDEPENDS_task-custom-apps = "\ + RDEPENDS_packagegroup-custom-apps = "\ dropbear \ portmap \ psplash" - RDEPENDS_task-custom-tools = "\ + RDEPENDS_packagegroup-custom-tools = "\ oprofile \ oprofileui-server \ lttng-control \ lttng-viewer" - RRECOMMENDS_task-custom-tools = "\ + RRECOMMENDS_packagegroup-custom-tools = "\ kernel-module-oprofile" -In the previous example, two task packages are created with their dependencies and their -recommended package dependencies listed: task-custom-apps, and -task-custom-tools. -To build an image using these task packages, you need to add -task-custom-apps and/or -task-custom-tools to +In the previous example, two package group packages are created with their dependencies and their +recommended package dependencies listed: packagegroup-custom-apps, and +packagegroup-custom-tools. +To build an image using these packagegroup packages, you need to add +packagegroup-custom-apps and/or +packagegroup-custom-tools to IMAGE_INSTALL. For other forms of image dependencies see the other areas of this section. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 04/12] documentation/poky-ref-manual: improve IMAGE_FEATURES reference
* apps-console-core has been effectively replaced by splash * apps-x11-core, apps-x11-games have been removed * ssh-server-* were added quite a while ago, add these here * x11 has been added * x11-base has changed behaviour slightly * doc-pkgs was added * nfs-server never exported the entire /, so remove this comment Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-features.xml | 28 +++- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/documentation/poky-ref-manual/ref-features.xml b/documentation/poky-ref-manual/ref-features.xml index 51bd73a..50acb4a 100644 --- a/documentation/poky-ref-manual/ref-features.xml +++ b/documentation/poky-ref-manual/ref-features.xml @@ -128,14 +128,21 @@ Current list of IMAGE_FEATURES contains the following: -apps-console-core: Core console applications such as -ssh, daemon, avahi daemon, -portmap (for mounting NFS shares) -x11-base: X11 server + minimal desktop +splash: enable showing a splash screen during boot. By +default, this is provided by psplash, which does allow customisation. If you prefer to +use an alternative splash screen package you can do so by setting the SPLASH variable +to a different package name (or names) within the image recipe or at the distro +configuration level. + +ssh-server-dropbear: install the Dropbear minimal SSH server. + +ssh-server-openssh: install the OpenSSH SSH server, +which is more full-featured than Dropbear. Note that if both this and ssh-server-dropbear +are present in IMAGE_FEATURES, then OpenSSH will take +precedence and Dropbear will not be installed. +x11: X server +x11-base: X server with minimal environment x11-sato: OpenedHand Sato environment -apps-x11-core: Core X11 applications such as an -X Terminal, file manager, and file editor -apps-x11-games: A set of X11 games tools-sdk: A full SDK that runs on the device tools-debug: Debugging tools such as @@ -146,11 +153,12 @@ LTTng tools-testapps: Device testing tools (e.g. touchscreen debugging) -nfs-server: NFS server (exports / over NFS -to everybody) +nfs-server: NFS server dev-pkgs: Development packages (headers and extra library links) for all packages installed in a given image -dbg-pkgs: Debug packages for all packages +dbg-pkgs: Debug symbol packages for all packages +installed in a given image +doc-pkgs: Documentation packages for all packages installed in a given image -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 05/12] documentation/poky-ref-manual: replace reference to old files
These file paths are no longer valid, instead point to the section of the reference manual with more information on valid IMAGE_FEATURES. Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-variables.xml |9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index b1e3cd3..bf1cce1 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -561,12 +561,11 @@ For example, ssh root access has a blank password. You should remove this feature before you produce a production image. - - There are other application targets too, see - meta/classes/poky-image.bbclass - and meta/packages/tasks/task-poky.bb - for more details. + + There are other valid features too, see + Image feature reference + section for more details. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 06/12] documentation/poky-ref-manual: update the default value of PACKAGES
Also add a definition for PACKAGE_BEFORE_PN since the default value of
PACKAGES now includes this.
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index bf1cce1..531ee8a 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -1482,6 +1482,13 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR =
"r2"
+PACKAGE_BEFORE_PN
+
+Enables easily adding packages to PACKAGES
+before ${PN} so that they pick up files that would normally be
included in the default package.
+
+
+
PACKAGE_CLASSES
This variable, which is set in the
local.conf configuration
@@ -1512,7 +1519,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR =
"r2"
PACKAGES
The list of packages to be created from the recipe.
-The default value is "${PN}-dbg ${PN} ${PN}-doc
${PN}-dev".
+The default value is "${PN}-dbg ${PN}-staticdev ${PN}-dev
${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}".
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 10/12] documentation/poky-ref-manual: update images reference section
* core-image-core was renamed to core-image-x11 and the editor and file manager were removed. * core-image-basic's description has been updated to reflect its intended purpose * core-image-lsb is intended to be standalone - should not be associated with core-image-basic. * The Pimlico applications have been removed so they are no longer present in the Sato images. Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-images.xml | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/documentation/poky-ref-manual/ref-images.xml b/documentation/poky-ref-manual/ref-images.xml index d1ff6d0..186d688 100644 --- a/documentation/poky-ref-manual/ref-images.xml +++ b/documentation/poky-ref-manual/ref-images.xml @@ -40,9 +40,6 @@ core-image-base: A console-only image that fully supports the target device hardware. - core-image-core: -An X11 image with simple applications such as terminal, editor, and file manager. - core-image-minimal: A small image just capable of allowing a device to boot. core-image-minimal-dev: @@ -61,12 +58,14 @@ for the Minimal MTD Utilities, which let the user interact with the MTD subsystem in the kernel to perform operations on flash devices. + core-image-x11: +A very basic X11 image with a terminal. + core-image-basic: -A foundational basic image without support for X that can be reasonably used for -customization. +A console-only image with more full-featured Linux system +functionality installed. core-image-lsb: -A core-image-basic image suitable for implementations -that conform to Linux Standard Base (LSB). +An image that conforms to the Linux Standard Base (LSB) specification. core-image-lsb-dev: A core-image-lsb image that is suitable for development work using the host. @@ -83,8 +82,8 @@ core-image-sato: An image with Sato support, a mobile environment and visual style that works well with mobile devices. -The image supports X11 with a Sato theme and Pimlico applications and also -contains terminal, editor, and file manager. +The image supports X11 with a Sato theme and applications such as +a terminal, editor, file manager, media player etc. core-image-sato-dev: A core-image-sato image suitable for development using the host. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 11/12] documentation/yocto-project-qs: adjust GUI component feature listing
List frameworks we provide that are likely to be used by people these days - Pimlico has been removed and GuPNP and Matchbox don't really belong. Also slightly modify the sentence following so that it is clear that these are optional. Signed-off-by: Paul Eggleton --- .../yocto-project-qs/yocto-project-qs.xml | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml index 94c488f..0e85d74 100644 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ b/documentation/yocto-project-qs/yocto-project-qs.xml @@ -104,11 +104,11 @@ Provides a recent Linux kernel along with a set of system commands and libraries suitable for the embedded environment. -Makes available system components such as X11, Matchbox, GTK+, Pimlico, Clutter, -GuPNP and Qt (among others) so you can create a richer user interface experience on -devices that use displays or have a GUI. -For devices that don't have a GUI or display, you simply would not employ these -components. +Makes available system components such as X11, GTK+, Qt, Clutter, and SDL +(among others) so you can create a rich user experience on devices +that have display hardware. +For devices that don't have a display or wish to use alternative UI +frameworks, these components need not be installed. Creates a focused and stable core compatible with the OpenEmbedded -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 12/12] documentation/poky-ref-manual: remove references to Dates and Contacts
Update the BitBake "Preferences and Providers" section to remove references to these two Pimlico applications that have been removed, and tweak the example slightly so it is technically correct. Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-bitbake.xml |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml index ff8db59..5055048 100644 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ b/documentation/poky-ref-manual/ref-bitbake.xml @@ -124,10 +124,10 @@ Once a provider is selected, BitBake resolves all the dependencies for the target. In the case of core-image-sato, it would lead to -packagegroup-base.bb, -which in turn leads to packages like Contacts, -Dates and BusyBox. -These packages in turn depend on eglibc and the toolchain. +packagegroup-core-x11-sato, +which in turn leads to recipes like matchbox-terminal, +pcmanfm and gthumb. +These recipes in turn depend on eglibc and the toolchain. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 07/12] documentation/poky-ref-manual: variable reference clarifications and fixes
* For PE/PV/PR/PN these pertain to a recipe ("package" was used here
historically).
* References to variables should not be prefixed with $ in the text
* Add text about suffixing RCONFLICTS as per other package variables
* Make ALLOW_EMPTY example complete
* Clarify and add example for AUTOREV
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml | 49 +++
1 file changed, 32 insertions(+), 17 deletions(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index 531ee8a..5165bf1 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -61,7 +61,7 @@
conjunction with a package name override.
Here is an example:
- ALLOW_EMPTY_${PN}
+ ALLOW_EMPTY_${PN} = "1"
@@ -76,9 +76,13 @@
AUTOREV
-Specifies to use the current (newest) source revision.
-This variable is with the SRCREV
-variable.
+When SRCREV
+is set to the value of this variable, it specifies that
the latest
+source revision in the repository should be used. Here is
an example:
+
+ SRCREV = "${AUTOREV}"
+
+
@@ -1478,7 +1482,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR =
"r2"
PACKAGE_ARCH
-The architecture of the resulting package.
+The architecture of the resulting package(s).
@@ -1536,14 +1540,17 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR
= "r2"
PN
-The name of the package.
+The name of the recipe. The name is normally extracted
from the recipe file name.
+For example, if the recipe is named
+expat_2.0.1.bb, then the default
value of PN
+will be "expat".
PR
-The revision of the package.
+The revision of the recipe.
The default value for this variable is "r0".
@@ -1551,13 +1558,13 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR
= "r2"
PV
-The version of the package.
-The version is normally extracted from the recipe name.
+The version of the recipe.
+The version is normally extracted from the recipe file
name.
For example, if the recipe is named
-expat_2.0.1.bb, then
PV
-will be 2.0.1.
+expat_2.0.1.bb, then the default
value of PV
+will be "2.0.1".
PV is generally not overridden within
-a recipe unless it is building an unstable version from a
source code repository
+a recipe unless it is building an unstable/development
version from a source code repository
(e.g. Git or Subversion).
@@ -1566,7 +1573,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR =
"r2"
PE
-the epoch of the package.
+the epoch of the recipe.
The default value is "0".
The field is used to make upgrades possible when the
versioning scheme changes in
some backwards incompatible way.
@@ -1581,7 +1588,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR =
"r2"
determines which recipe should be given preference.
The variable must always be suffixed with the name of the
provided item, and should be set to the
-$PN of the recipe
+PN of the recipe
to which you want to give precedence.
Here is an example:
@@ -1596,9 +1603,9 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR =
"r2"
If there are multiple versions of recipes available, this
variable determines which recipe should be given
preference.
-The variable must always be suffixed with the
$PN
+The variable must always be suffixed with the
PN
for which to select, and should be set to the
-$PV to which you want to give
precedence.
+PV to which you want to give
precedence.
You can u
[yocto] [yocto-docs][PATCH 08/12] documentation/poky-ref-manual: add packagegroup.bbclass to classes
Add a short section about packagegroup.bbclass. Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-classes.xml | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/documentation/poky-ref-manual/ref-classes.xml b/documentation/poky-ref-manual/ref-classes.xml index c06e362..b836e2c 100644 --- a/documentation/poky-ref-manual/ref-classes.xml +++ b/documentation/poky-ref-manual/ref-classes.xml @@ -262,6 +262,27 @@ + +Package Groups - packagegroup.bbclass + + +This class sets default values appropriate for package group recipes (such as +PACKAGES, +PACKAGE_ARCH, +ALLOW_EMPTY, +etc.). It is highly recommended that all package group recipes inherit this class. + + +For information on how to use this class, see the +"Customizing Images Using Custom Package Groups" +section in the Yocto Project Development Manual. + + +Previously this class was named task.bbclass. + + + + Packaging - package*.bbclass @@ -659,7 +680,6 @@ sstate.bbclass staging.bbclass syslinux.bbclass -task.bbclass terminal.bbclass tinderclient.bbclass toolchain-scripts.bbclass -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 09/12] documentation/poky-ref-manual: update undocumented classes list
Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-classes.xml | 28 +++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/documentation/poky-ref-manual/ref-classes.xml b/documentation/poky-ref-manual/ref-classes.xml index b836e2c..9e07c62 100644 --- a/documentation/poky-ref-manual/ref-classes.xml +++ b/documentation/poky-ref-manual/ref-classes.xml @@ -623,33 +623,54 @@
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 09/05/2012 02:15 AM, Paul Eggleton wrote:
> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
>> The simplest fix would be for meta-ti to preppend itself to the path the
>> same way meta-yocto does, i.e., in the layer.conf
>>
>> BBPATH := "${LAYERDIR}:${BBPATH}"
>>
>> In fact, this is the *only* way that a layer can override any conf files
>> in oe-core, which is probably what you always want in a BSP layer?
>>
>> Just quickly scanning yocto git, there are a number of BSP layers that
>> are configured the same way as meta-ti, so potentially have the same
>> problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
>> layers configured this way too, but I think it's only a big issue for
>> BSP layers and distro layers.)
>>
>> As long as we are mixing layers that do both prepend and append, the
>> layering will continue to be broken in subtle and hard to identify ways.
>> I can't think of a practical use case where a layer other than oe-core
>> might need to append itself to the BBPATH? If there were no genuine need
>> for layers to append to the path, the BBPATH extension could be done
>> automatically when including the layer, instead doing manually in each
>> layer.conf, giving us some consistency.
>
> It has been considered witin OE to be best practice to append to BBPATH and
> not prepend, the thinking being that then the search path matches the order
> of
> the layers listed in bblayers.conf rather than the reverse. I'm not sure I
> agree with it (I tend to prefer to list OE-Core first), but that's the
> convention adopted there.
>
> Quite a few people have asked for the items which BBPATH controls (classes,
> conf files) to instead be found in layer priority order. If bitbake took over
> managing BBPATH, that would be a possibility, and as you say it would improve
> consistency at the expense of a little flexibility.
>
>> But you do need meta-yocto for the atom-pc machine, because meta-yocto is
>> the BSP layer for that (and should Intel decide to add an atom-pc to
>> meta-intel, it will be broken exactly the same as the beagleboard machine is
>> just now).
>
> Some time ago we discussed the possibility of moving the atom-pc BSP to meta-
> intel and then copying it back into meta-yocto, once the layer tooling
> allowed
> for that to be done dynamically. Since the layer tooling is now in place that
> is at least a practical possibility, but I'm not sure if it's still on the
> cards - it still makes sense to me at any rate.
A case can be made, but in my opinion, atom-pc is a generic BSP (not
machine specific) and doesn't really fit with the other BSPs within
meta-intel. I believe we should have an Intel BSP in meta-yocto, but I
don't like the idea of duplicating a BSP in meta-yocto and meta-intel.
atom-pc seems like a reasonable candidate to leave in meta-yocto to me.
I could probably be convinced otherwise, but that's my current thinking.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 09/05/2012 07:20 AM, William Mills wrote: > On 09/04/2012 07:23 PM, Darren Hart wrote: >> >> >> On 09/04/2012 01:25 PM, William Mills wrote: >> >>> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the >>> poky distro defs? That does seem to mixing things a bit. (I am not >>> claiming meta-ti is clean yet but I want to understand the Intel examples.) >>> >> >> It isn't something we test as part of the QA that we perform. I mostly >> expect people building meta-intel to be building with meta-yocto >> (although I wouldn't take a hard line on requiring it). That said, I >> removed meta-yocto from a meta-intel/meta-fri2 build and removed >> DISTRO=poky from my local.conf and successfully built and booted a >> core-image-minimal build on an FRI2 this afternoon without any changes. >> > > Thanks! My confidence is restored. > > As long as including meta-yocto does not interfere with other BSPs or > distros etc then there should be no harm in your assumption. > > I would be interested to know what Mentor Graphics and Wind River do on > their products. Do they include meta-yocto? (YP is not all about > comercial OS support but I know these orginatations have done the due > diligence on layer compatibility for a non-poky distro.) I haven't heard one way or the other, but perhaps Bruce, Sean, and Matthew could comment on that. -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 09/05/2012 08:48 AM, Richard Purdie wrote: On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote: On 05/09/12 10:15, Paul Eggleton wrote: On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote: It has been considered witin OE to be best practice to append to BBPATH and not prepend, the thinking being that then the search path matches the order of the layers listed in bblayers.conf rather than the reverse. Then meta-yocto should follow that convention ... and it needs to be well documented, with the consequence of breaking that convention explained, and the terrible punishments to come described in great and sordid detail. Because this needs to be more than a convention, it needs to be an article of faith. I just want to clarify something here. Its accepted that most layers will append to BBPATH. I do think its acceptable for a distro policy layer to prepend though and this is why meta-yocto does this. I don't remember the exact reason right now but the principle stands. So how should we resolve the issue in meta-ti for the denzil/1.2 branch? I think the expediency of prepending sounds right to me. We can shoot for a better fix in 1.3. The root of the problem is that meta-yocto mixes up policy and hardware support which is bad. It also means its not compliant with the new Yocto Project compliance criteria and hence is not Yocto Project Compatible. Now we've got the compliance criteria sorted out there are some adjustments that need to be made and I will shortly be cleaving meta-yocto into two pieces to resolve this. I hadn't looked at this until now mainly in case there were changes to the criteria. FWIW I think this shows the strength of those criteria as by following them, we'd avoid a real world problem here. I'm glad you are thinking of doing this. I think it sets a good example and is cleaner. However we will still need priority or namespace to override the beagleboard definition in the meta-yocto-bsp (or whatever) layer if it contains both the beagleboard reference and the atom-pc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 05/09/12 15:45, William Mills wrote: >> Its accepted that most layers will append to BBPATH. I do think its >> acceptable for a distro policy layer to prepend though and this is why >> meta-yocto does this. I don't remember the exact reason right now but >> the principle stands. > > So how should we resolve the issue in meta-ti for the denzil/1.2 branch? > > I think the expediency of prepending sounds right to me. We can shoot > for a better fix in 1.3. I think in the light of what Paul said, the meta-ti behaviour is what is expected and changing will potentially complicate things for other meta-ti consumers who follow the convention; the problem is in meta-yocto, not meta-ti. The current problem can be worked around; it requires a custom layer that also prepends itself to the path in front of meta-yocto, and then provides a beagleboard.conf of it's own (which can simply 'include' or 'require' the beagleboard.conf from meta-ti). I think if Richard is working on a solution in meta-yocto, it might be enough to document this somewhere until it is ready. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 12-09-05 10:20 AM, William Mills wrote: On 09/04/2012 07:23 PM, Darren Hart wrote: On 09/04/2012 01:25 PM, William Mills wrote: Darren: Is it true you can't get @ the Intel BSP's w/o also getting the poky distro defs? That does seem to mixing things a bit. (I am not claiming meta-ti is clean yet but I want to understand the Intel examples.) It isn't something we test as part of the QA that we perform. I mostly expect people building meta-intel to be building with meta-yocto (although I wouldn't take a hard line on requiring it). That said, I removed meta-yocto from a meta-intel/meta-fri2 build and removed DISTRO=poky from my local.conf and successfully built and booted a core-image-minimal build on an FRI2 this afternoon without any changes. Thanks! My confidence is restored. As long as including meta-yocto does not interfere with other BSPs or distros etc then there should be no harm in your assumption. I would be interested to know what Mentor Graphics and Wind River do on their products. Do they include meta-yocto? (YP is not all about comercial OS support but I know these orginatations have done the due diligence on layer compatibility for a non-poky distro.) Layering flexibility is important, so we work largely on oe-core vs meta-yocto. That being said, there are elements in meta-yocto that are of interest, so it can be included in used, but with layers that get the ordering and priority correct to override/preserve appropriately. But sorting out exactly what we are talking about in this thread, would make using meta-yocto (or whatever the elements of it become), that much easier to do. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
On Wed, Sep 5, 2012 at 5:58 AM, Jack Mitchell wrote: > This is now livefor anyone interested. > http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7 Shouldn't the instructions include a step adding the meta-raspberrypi layer to conf/bblayers.conf? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
On 05/09/12 16:20, Trevor Woerner wrote: On Wed, Sep 5, 2012 at 5:58 AM, Jack Mitchell wrote: This is now livefor anyone interested. http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7 Shouldn't the instructions include a step adding the meta-raspberrypi layer to conf/bblayers.conf? Well spotted Trevor! Fixed and amended. Thanks, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Wed, 2012-09-05 at 10:45 -0400, William Mills wrote: > > On 09/05/2012 08:48 AM, Richard Purdie wrote: > > On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote: > >> On 05/09/12 10:15, Paul Eggleton wrote: > >>> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote: > >>> It has been considered witin OE to be best practice to append to BBPATH > >>> and > >>> not prepend, the thinking being that then the search path matches the > >>> order of > >>> the layers listed in bblayers.conf rather than the reverse. > >> > >> Then meta-yocto should follow that convention ... and it needs to be > >> well documented, with the consequence of breaking that convention > >> explained, and the terrible punishments to come described in great and > >> sordid detail. Because this needs to be more than a convention, it needs > >> to be an article of faith. > > > > I just want to clarify something here. > > > > Its accepted that most layers will append to BBPATH. I do think its > > acceptable for a distro policy layer to prepend though and this is why > > meta-yocto does this. I don't remember the exact reason right now but > > the principle stands. > > So how should we resolve the issue in meta-ti for the denzil/1.2 branch? > > I think the expediency of prepending sounds right to me. We can shoot > for a better fix in 1.3. I think the problem is in meta-yocto and is hitting a particular subset of users where people combine meta-yocto and meta-ti. I'm not sure this can easily be fixed in meta-ti, or that we currently have a high volume of users mixing those two. > > The root of the problem is that meta-yocto mixes up policy and hardware > > support which is bad. It also means its not compliant with the new Yocto > > Project compliance criteria and hence is not Yocto Project Compatible. > > > > Now we've got the compliance criteria sorted out there are some > > adjustments that need to be made and I will shortly be cleaving > > meta-yocto into two pieces to resolve this. I hadn't looked at this > > until now mainly in case there were changes to the criteria. > > > > FWIW I think this shows the strength of those criteria as by following > > them, we'd avoid a real world problem here. > > I'm glad you are thinking of doing this. I think it sets a good example > and is cleaner. > > However we will still need priority or namespace to override the > beagleboard definition in the meta-yocto-bsp (or whatever) layer if it > contains both the beagleboard reference and the atom-pc. With the solution, you can just order the meta-ti and meta-yocto-bsp layers such that the TI layer "wins" and no extra configuration is necessary. The trouble is that the meta-yocto doesn't allow this at the moment as things stand. In many ways this is just part of the learning experience of how to use and how not to use layers... Despite the fact we just passed the feature freeze point, I'm going to ensure we get this fixed for 1.3. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/3] base-files: add /etc/motd with TLK info
Signed-off-by: Saul Wold
---
.../base-files/base-files_3.0.14.bbappend |3 +++
meta-tlk/recipes-core/base-files/files/motd|7 +++
2 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
create mode 100644 meta-tlk/recipes-core/base-files/files/motd
diff --git a/meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
b/meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
new file mode 100644
index 000..248b225
--- /dev/null
+++ b/meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+PR .= ".1"
diff --git a/meta-tlk/recipes-core/base-files/files/motd
b/meta-tlk/recipes-core/base-files/files/motd
new file mode 100644
index 000..13cd74c
--- /dev/null
+++ b/meta-tlk/recipes-core/base-files/files/motd
@@ -0,0 +1,7 @@
+This image contains a time limited kernel and will reboot the machine
+automatically in 10 days. Do not include this image in a product.
+
+Use the image for evaluation purposes only.
+
+Please see http://www.yoctoproject.org/tlk for instructions on how to
+eliminate the timeout.
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/3 v3] Meta-tlk update
The following changes since commit 16a7879b98352b70e8c17181912a26212d716c87: meta-emenlow: rename recipes-gnome bbappends (2012-09-04 10:04:37 -0500) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgw/meta-tlk http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/meta-tlk Saul Wold (3): linux-yocto: Update linux-yocto for 3.2 and 3.4 base-files: add /etc/motd with TLK info psplash: Add TLK info to psplash image .../base-files/base-files_3.0.14.bbappend |3 +++ meta-tlk/recipes-core/base-files/files/motd|7 +++ .../recipes-core/psplash/files/psplash-tlk.png | Bin 0 -> 42295 bytes meta-tlk/recipes-core/psplash/psplash_git.bbappend | 10 ++ .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++ .../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++ .../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++ 7 files changed, 34 insertions(+), 0 deletions(-) create mode 100644 meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend create mode 100644 meta-tlk/recipes-core/base-files/files/motd create mode 100644 meta-tlk/recipes-core/psplash/files/psplash-tlk.png create mode 100644 meta-tlk/recipes-core/psplash/psplash_git.bbappend create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
Signed-off-by: Saul Wold
---
.../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++
.../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++
.../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++
3 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 58a6541..138cc21 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -2,3 +2,5 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
# enable the time limited kernel configuration options
SRC_URI += "file://time-limited-kernel.cfg"
+
+PR .= ".1"
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
new file mode 100644
index 000..138cc21
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -0,0 +1,6 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# enable the time limited kernel configuration options
+SRC_URI += "file://time-limited-kernel.cfg"
+
+PR .= ".1"
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
new file mode 100644
index 000..138cc21
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -0,0 +1,6 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# enable the time limited kernel configuration options
+SRC_URI += "file://time-limited-kernel.cfg"
+
+PR .= ".1"
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 3/3] psplash: Add TLK info to psplash image
Signed-off-by: Saul Wold
---
.../recipes-core/psplash/files/psplash-tlk.png | Bin 0 -> 42295 bytes
meta-tlk/recipes-core/psplash/psplash_git.bbappend | 10 ++
2 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 meta-tlk/recipes-core/psplash/files/psplash-tlk.png
create mode 100644 meta-tlk/recipes-core/psplash/psplash_git.bbappend
diff --git a/meta-tlk/recipes-core/psplash/files/psplash-tlk.png
b/meta-tlk/recipes-core/psplash/files/psplash-tlk.png
new file mode 100644
index
..54b8fae7220e12d1a0cbf33cea6dfbe341f0b55a
GIT binary patch
literal 42295
zcmb5VXH=6-8#NjqMQnf#QL2i9f`B5uMd>0%nt=2o@X#VsLQPZzL{JF)?1epiCufsXl!3;^RY@5$CbXMyk;-&c_RhTseMP
z=gpO`BbH;c5Bu=5TE6i+7xcw@$r1G0Zx1T6gT!C+)k2(l1Wss`8(i2y1R=nw$~8_wvNGXOPp!N}aCw&;<`cb`VNR
zqF3u!v5-Rn{U?t>>hx0UZu3SmIhItDtq#3-eW=biUhd(s7v~}Of?`#FLhflEdXfHF
z$QbhF2*j@4(P0|$NDN{pjGXI-yhz_k4n732{CI`)(3g0~<#SKps6$*8AqCx!-)cb2
zZ$r*IKWvbP42wZ-KQMFFh7?yo>bg#!`~^973Ub@^t=cdspMZuRoCP-URoX#^JXK(V*_oMPod#7)`!=&shRa{uIy1V*
zE<$OaN}0e;U3)2M{Zi}5&cxr2E!`iy-5-v>b{LBUkLff;yhS^#LX?ISyQv%sju*?Zc09cOQ24aDZ`~9X0@*;r
z{tVnWcKC&B*km`HxeBFgeYp;K;r!r(Hw0p%eofq@trXgP3<6RA@=~PuKF`*li?`~I
z^8R5N|8sKRPUf}hwT8c{r&Uilz2JRrceCJ?>WzrbVm=W&iGh23Qgw!|5ed)O#s8XC
zvMWF1*t0*D@#jX(%i~Axw;VfXe`WN|A&0l-g0aWAlEZhd{LwygHu~D-);H%3uRe^I
z*1lu(*5tCOHs6Nw^MB+ctu(9S6v)1=d&$*;Q~6EY
z#g7XPqoXK}-6ilNXJ2a69hW%*SG{b{e_z{N*Ia*CJLfX*HK{YB$7PQner@6}d?tOSe&+5B&&-t#%MU&yx2|vr>%kIbTiANXI=M`qUU({MiS~$D~KgAZo8P@#9<;JDdi>w!2F2OGreb)VXsXzKsv&n7Q
zJIkNvlR1)Mrsg8$A|agdZ6^|S5`_|ZL?ldd^M2+L@=ls=nzoz7<=PmBqBKqK8c*jQ
zANZ7SnwS1)*_g-JC08*gGS4LkW&-_=u%JgBwW!yvH&FX-_@%^lx~A#!Nykg20k^KW
zv*kzly_9YcD(M^v@fSgVrt_hrmGg4H%B$VgxocKxwE58)$~yhodne6T|M>ik?4(V^
zTf+I(n^QM=eoE<9-Fa%|p7$x~lX<>&zG1%BGDZeP%1-}@(Lh_!Ub5eB))BT6)^dsK
zVo9Gj9x=vepUA$Tr>sChiRZch;Q5MHhu3;#lRsx*ZC+&P!mhG8>(5?-&6ZxpJ<;n`8vL;S1D^yGe(o+-M>v%
z)7Pdwn>?GcgpLYb5qhY%q(@FM(yRJ;^QWS&qHc3%N9VWBp=9Y)@^4y9`#k0dl$57>-<)QX24qPr3ji`EZ0wy7}Iy8o^%*qxy!k*9fgb(5K`}ui=
z#|ng$t~4?Bo*;g
zo+f+?W=6-C;%z+{)JI8AElvGP${8yn%aH#iM~-K9NM+v4u(<2fQ{SRCVL00hJ(-z!
z+nrc|Fiscfq}&zx47R+1%15-e;xWa}zgD%uU|
zVHvjJL^Y%!(}@|x?1f~%xPHjxaMa8DFD?I}?F5Bfsf~pyj6L1{HA1@o?n~8u&iiq%
z3SZ6sDZJv^vhu$03U&T-SA5sM?BS0P3qw7u_H*{p^@vl#;gR8H5zyFYZ_K%S?<7gX
zd&kv$i0XUlpVSGdE_V#%i^O!KMO5;{-IPXUtEH-;P2$cL9fRiS<_|m`^2&>gpk%x}
zu*7}RX5>`*)XC{!uFn!J*3SaJcKzK7&%Tf=e)g8ar+d0@^yNOT-9IgobK%|fjdSqp
zu_prm^8IzWD$y&``({|pN`zm3Lt8{I=)+2Ujdb9(#=Adm%~rh@&V65_%chG@RmixI
z;(yswQdt3WC+tJ~dvDdeD|!j#E=w+R&i?HMPs4vP8oi<`B={3qTir|F7qD1}ohVoR
zxnT0-22Odl$XeP#IK8GoA
zlmDgU9XNJknv+E|;_=Y}rOLPEBA$Z=`6RO>6apg@r04$9=1<$JKV^s9mrt6Wm<`?M-&_
z$+piwg*Z)q_FjE_zWimbp+)8EKDVvt=4`z?YD>A=damcPRG+l`cy;1%BkxD6=k`Z9
zIsKf~M_drdkXc{M-BUg;M=w$~5xX1G9pk~l+$t}Su!zQ_XJ{&&fXtpj}hzf0}~9RmOU-zEQ#8~pE*|J~q!m;8U-
z;Q!Ue|9Wt61C$$L$7_1Va&>ohp7{R!L|!A?0|;c{;yX=8N5|>#lVyH>eofATXOA4T
z@C9=_S(lBCt(I$lx0Y(g$(8twS2+H%>3_EyjcjUaqSH7KJB%e*?Jk1|`-=ImbNbo2
zxm8O6rgNiy?vIg=&CDW?96I>IRU#!dRU)l+&2JmN`n?7|*I{w(*uf*;3$~ZyUS8%w
z&}XTfH&;m`r2@zQIcTHDrsqi>9!;&GH@z(kAA5fpK=VTolKTq3ywR?W+g`Oqt)|<5
z!}wc~w$1k@W!qJ+Gw>P<#Pd~u0R*By5z-mBApTzytTNY)q=f$a`~TlV`+uj8Ao}j-
z&$*^1%_KIP&`?aPld24ur|(pqIw#3=C~~q{KnB&_c85Dg{Nmq;h=@37+c27%84+=G
z22B5Nfl8@j!JPbj#kKCQRH7vXAE6XGjY4~Ez5g0!CHB5{e}BvpR-pZm?n>Sl&dMg{
zujKjqBwSeqk8|3(2#2FYajG^MQ(G)NNM*B40H&Hz1O}*CVTNVKah*+&>M<+dE}PX
zC?zoIual&-taPeeLaURThsW85Xq}%XB8fUbZX`qc#!4K91`2SCwYz)h-ve=7Y4YvN
zMcOLjZ6>o}ZBorj_;;!-vpN_@TknS887#J9y6Si0nMj(V9Qth|AG&eUlIZ2+I^Eb7&o4?w>DVeOh
zvKjljChU4A=pT4VNy$h{U)qW&b)iJEC*sob|8?^kS{cWWZx!wBwbFCks3#Ui^3A#l
znBc&m!0M{1z)Cc_DhtE%p5R~aDwR@C#mPzW#~fBx4yh?Axnn#p}u}CnbMw(J=+<}_anG%8w9+C
zu@9jMho-@KI20(Tu6dR`DPN=oC(%F6a^wzJxKdF}Bh^uNzpb)u|;2@e8S
zy9>t(l!Ov>WJ8$OM?BNJIEb(y5wDk&x#=pdIimNx6BKGY|JK6C$H&t%-6oqkNz;=j
zB5LPX>G~Fj_=k&DXKq%!4v&n*`kN$)6Ov#LaRb8xJ;TF2Jw1BSiG;&J7zBJV
z<764vHUpD6Er*%3>a0r1FZ>jP^&f~>t@SXI;O60RcV89}iA7}6`iK5beIP0F!Hq={
zV=v|N%X)Qud}DbqW+c)e3U2{f#E5`((*Mb#!gtC$asI7dEHQRETwGKAcdFE
zDzpmc$qbsZ7|YD8n8?-W?)0>S}8BBc;`*i^-YJ1*M_
zYi;eGf87$xRDkd-owJ?DRp#YG8KruqhWNO!?9j$D=aiD|Xq$ACP-ItkS&?5(VPXHu
zIEAbzu)j{rOi$Ij>#QO*pWJ--pCJG0-Ldg;D`OvQWzMzbb{L{<>=pOG`s1QjC&`Ol
zq4dFstvE?nu~3&uVis+D*FY05usA;-tzrJ&=JKoR>S{}`YT82Yba}0$$h81E&Rwzb
zn7fBZT2S*=EtBAaZl&#|K8R~jAM34Nq(sE2>|7J02y(UNf%04kAHqFL?9$Hdbln7usK+
zqI4ziJi!=ze|Gn+U_}a{Me79fM)?@uDJ_LJ`q{|k7*2_6*e7OY^KSO}`T41vPO2c5
zZ7Lr{r@h+xCv|Ooaig#O_&1pn-a@5vmE|#Zb{7Iisz!2+i0K#egbI+3mg1m#=4&5B
zD=zaqM+EHrX)c@P!bOw^==XD?@(Ed?jsT
zLy(k>7O1HWT7UR3MO@iUU^o(w^Ws-22;G_#PJ1q8+FVR-FPc|M?$KxMdZB+rG;J(8
zC)lB!bG4WrXkgH7i=?3pi0-3`b^vR^HPlzf+?S)!XQO5cpB5?aJo*^ZjT;;kv)v}J
zt`_+}p*|AvgTs@wuX&NZetja{1AilQ4mUhJJihWr}Uu$L=4(N50$=jL5%2xvxDylN0Lzf3ymxTEHS!0%9kg##OtQR#e0>Iw*Ryz!oOKkk}0m{;A?Xn|w^6P!Op!Wvr
zYZd8vy&ne$2T5b_dzOfql}
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On Wed, Sep 5, 2012 at 9:56 AM, Saul Wold wrote:
> Signed-off-by: Saul Wold
> ---
> .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++
> .../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++
> .../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++
> 3 files changed, 14 insertions(+), 0 deletions(-)
> create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
>
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> index 58a6541..138cc21 100644
> --- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> @@ -2,3 +2,5 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> # enable the time limited kernel configuration options
> SRC_URI += "file://time-limited-kernel.cfg"
> +
> +PR .= ".1"
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> new file mode 100644
> index 000..138cc21
> --- /dev/null
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> @@ -0,0 +1,6 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +# enable the time limited kernel configuration options
> +SRC_URI += "file://time-limited-kernel.cfg"
> +
> +PR .= ".1"
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> new file mode 100644
> index 000..138cc21
> --- /dev/null
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> @@ -0,0 +1,6 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +# enable the time limited kernel configuration options
> +SRC_URI += "file://time-limited-kernel.cfg"
> +
> +PR .= ".1"
what will this option do ?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
I also found that I had to add: BB_DANGLINGAPPENDS_WARNONLY = "yes" at the end of my conf/local.conf since I received a: ERROR: No recipes available for: /home/trevor/devel/yocto/raspi/poky/meta-raspberrypi/recipes-multimedia/libav/libav_0.7.4.bbappend the first time I tried baking (even when using the exact commits for both poky and meta-raspberrypi as specified in the instructions). Maybe it's just me? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On 09/05/2012 10:08 AM, Khem Raj wrote:
On Wed, Sep 5, 2012 at 9:56 AM, Saul Wold wrote:
Signed-off-by: Saul Wold
---
.../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++
.../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++
.../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++
3 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 58a6541..138cc21 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -2,3 +2,5 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
# enable the time limited kernel configuration options
SRC_URI += "file://time-limited-kernel.cfg"
+
+PR .= ".1"
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
new file mode 100644
index 000..138cc21
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -0,0 +1,6 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# enable the time limited kernel configuration options
+SRC_URI += "file://time-limited-kernel.cfg"
+
+PR .= ".1"
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
new file mode 100644
index 000..138cc21
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -0,0 +1,6 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# enable the time limited kernel configuration options
+SRC_URI += "file://time-limited-kernel.cfg"
+
+PR .= ".1"
what will this option do ?
Khem,
It will add another .1 to the PR, if PR = 4.1, it will become 4.1.1
Sau!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] core-image-minimal linux kernel version
I successfully built core-image-minimal. I now what to understand how the build determine what linux kernel it will be using because the next step I will want to do is add my own recipe that references my own kernel. I have not been able to find where the linkage to specific kernel is. Can someone provide an answer. Thanks, Jim Macon Toshiba Global Commerce Solutions voice +1 919-543-7490 mailto: ma...@us.ibm.com___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-minimal linux kernel version
Hi, On 05/09/12 18:35, James Macon wrote: > I successfully built core-image-minimal. I now what to understand how the > build determine what linux kernel it will be using because the next step I > will want to do is add my own recipe that references my own kernel. I > have not been able to find where the linkage to specific kernel is. Can > someone provide an answer. The kernel is normally specified in the machine conf file; grep for PREFERRED_PROVIDER_virtual/kernel. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On Wed, Sep 5, 2012 at 10:15 AM, Saul Wold wrote: > > > It will add another .1 to the PR, if PR = 4.1, it will become 4.1.1 sorry, I was more interested in the time limited kernel option. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
On 5 September 2012 18:13, Trevor Woerner wrote: > I also found that I had to add: > > BB_DANGLINGAPPENDS_WARNONLY = "yes" > > at the end of my conf/local.conf since I received a: > > ERROR: No recipes available for: > > /home/trevor/devel/yocto/raspi/poky/meta-raspberrypi/recipes-multimedia/libav/libav_0.7.4.bbappend > > the first time I tried baking (even when using the exact commits for > both poky and meta-raspberrypi as specified in the instructions). > Maybe it's just me? Not at all. Guacamayo uses the meta-raspberrypi layer and does this: # meta-raspberrypi has libav.bbappend, for which we do not have the base recipe # meta-ti has a bunch of recipes with broken license BBMASK=".*/meta-raspberrypi/recipes-multimedia/libav/|.*/meta-ti/recipes-misc" Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] raspberrypi image questions
I just built Yocto/Poky for the raspberrypi, following the recent thread on this list. I noticed that the resulting SD image is ~4GB, but most of that space seems to be unused: $ ssh root@192.168.1.150 Warning: Permanently added '192.168.1.150' (RSA) to the list of known hosts. root@192.168.1.150's password: root@raspberrypi:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root57388 46754 7718 86% / none 93964 156 93808 0% /dev /dev/mmcblk0p2 57388 46754 7718 86% /media/mmcblk0p2 /dev/mmcblk0p1 19400 8928 10472 46% /media/mmcblk0p1 tmpfs9396456 93908 0% /var/volatile tmpfs93964 0 93964 0% /dev/shm tmpfs93964 0 93964 0% /media/ram root@raspberrypi:~# cat /proc/partitions major minor #blocks name 17903977216 mmcblk0 1791 19456 mmcblk0p1 17923885056 mmcblk0p2 Notice that the physical partition for /dev/mmcblk0p2 is huge but the file system is only 57MB. How can I adjust my build and/or resize the file system to actually use the rest of the SD card? Also, is it possible to just build the SD image much like I do for other devices like the BeagleBoard, albeit with different contents in /boot? Sloshing around 4GB images is rather painful, plus it takes forever to DD it to the SD card. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On 09/05/2012 10:43 AM, Khem Raj wrote: On Wed, Sep 5, 2012 at 10:15 AM, Saul Wold wrote: It will add another .1 to the PR, if PR = 4.1, it will become 4.1.1 sorry, I was more interested in the time limited kernel option. Sorry, you had put that right under the PR line and JaMa had also asked about it! This is to prevent the HW BSP generated by the autobuild from being used in production, it's added by the autobuilder to the HW bsps. It's a kernel configuration that a patch in the linux-yocto code base, Bruce would have to fill you in on those details. Sau! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, September 04, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Sorry for the late. Forgot to hit the sent button yesterday. Attendees: Alex, MichaelH, Cristian, Darren, Tom, LaurentiuP, Nitin, Bjorn, BogdanM, Bruce, Sean, Dave, Paul, Saul, Richard, LaurentiuS, Cristiana, Ross, ScottR Agenda: * Opens collection - 5 min (Song) * Yocto 1.3 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status - Congratulations to the team on 3 things: 1. 1.3 feature complete is reached. We completed all high features except those we have moved from high to medium+, a significant portion of all features (218.1/432.6 = 50%) have been completed so far. We will review all medium+ features left on the schedule. Now we should focus on bug fixing. 2. Consistent performance improvement: M1:115, M2:93, M3:83, about 28% reduction on build time. 3. Bug fixing trend is going to the right direction for the past 3 weeks. - Master status: Saul, doing MUT, Richard pulled pretty much everything into master. There was an issues with eglibc not building correctly. With Paul's change there is a tool chain issue. Might do a quick pull into master for the fix. Might deferring some patches, we will look into patches more carefully. * SWAT team rotation: Ross -> Laurentiu Palcu. Thanks, Laurentiu! * Opens - 10 min ScottR: bug talking about a better example for BSP development manual for the appendix. Darren: maybe we can use the giveaway board. RP: makes sense. Song: good idea * Team sharing - 20 min Paul: sent out package group changes, renaming, task recipes, fixing some nasty issues at the same time. Should be reasonably smooth changes. If you know any issues, please let me know and I'll get them fixed quickly. RP: right direction, these issues have been talked about for some time. Now we got them in. Really appreciate the work. RP: LinuxCon last week, announced a compliance program: 2 levels: one is participant, the other is YP compatible. Encourage anyone to look at the criteria on the first level. YP compatible has more strict criteria. Some other changes, nativesdk work went in. experimentation for ssate work. Tricky to get the code right. If anyone wants to be involved, please talk to me. Michael: Had some connectivity issues this week. LinuxCon was very good. This week, eclipse plugin to build on AB. Working on the bugzilla stats. Patch work, code review a set of python scripts to allow monitoring and track patches on a web page. RP: we are experimenting now, doing evaluation, no decisions to use it yet. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On Wed, Sep 5, 2012 at 11:16 AM, Saul Wold wrote: > This is to prevent the HW BSP generated by the autobuild from being used in > production, it's added by the autobuilder to the HW bsps. thats fine. However, I am using linux-yocto unmodified from meta-yocto so this will now force me to generate my own bsp if I dont want this feature right ? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-minimal linux kernel version
I found it but this is only partially the answer. I found PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" in qemu.inc but there is no recipe for linux-yocto. There are recipes for linux-yocto_3.* , linux-yocto-tiny, and linux-yocto-rt_3*. Somewhere during the build process something is appending to linux-yocto. I will keep looking but if someone knows the answer please respond. Thanks, Jim Macon Toshiba Global Commerce Solutions voice +1 919-543-7490 mailto: ma...@us.ibm.com___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On 12-09-05 03:03 PM, Khem Raj wrote: On Wed, Sep 5, 2012 at 11:16 AM, Saul Wold wrote: This is to prevent the HW BSP generated by the autobuild from being used in production, it's added by the autobuilder to the HW bsps. thats fine. However, I am using linux-yocto unmodified from meta-yocto so this will now force me to generate my own bsp if I dont want this feature right ? Only the binaries produced by the release builds that use meta-tlk would have this issue. Even then a single rebuild without that layer removes the time limit option. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-minimal linux kernel version
On 05/09/12 20:03, James Macon wrote: > I found it but this is only partially the answer. I found > PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" in qemu.inc but there > is no recipe for linux-yocto. There are recipes for linux-yocto_3.* , > linux-yocto-tiny, and linux-yocto-rt_3*. > > Somewhere during the build process something is appending to linux-yocto. > I will keep looking but if someone knows the answer please respond. The part before the '_' is the package name, the part after is is version. So, linux-yocto, linux-yocto-tiny and linux-yocto-rt are three different kernels, each of which can have multiple versions at the same time. You get automatically the highest available version a package unless the version is specifically pinned down somewhere (e.g., PREFERRED_VERSION_virtual/kernel in the configs or DEFAULT_PREFERENCE in the recipes themselves). Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On Wed, Sep 5, 2012 at 12:06 PM, Bruce Ashfield wrote: > On 12-09-05 03:03 PM, Khem Raj wrote: >> >> On Wed, Sep 5, 2012 at 11:16 AM, Saul Wold wrote: >>> >>> This is to prevent the HW BSP generated by the autobuild from being used >>> in >>> production, it's added by the autobuilder to the HW bsps. >> >> >> thats fine. However, I am using linux-yocto unmodified from meta-yocto >> so this will now >> force me to generate my own bsp if I dont want this feature right ? > > > Only the binaries produced by the release builds that use meta-tlk > would have this issue. Even then a single rebuild without that layer > removes the time limit option. > diffstats confused me .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++ .../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++ .../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++ and I thought it was being applied to meta-yocto but then individual diffs showed that it was being applied to meta-tlk prepending [meta-tlk] in subject instead of just [yocto] would have filtered this message from my eyes. > Cheers, > > Bruce > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Wed, Sep 05, 2012 at 01:48:23PM +0100, Richard Purdie wrote: > On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote: > > On 05/09/12 10:15, Paul Eggleton wrote: > > > On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote: > > > It has been considered witin OE to be best practice to append to BBPATH > > > and > > > not prepend, the thinking being that then the search path matches the > > > order of > > > the layers listed in bblayers.conf rather than the reverse. > > > > Then meta-yocto should follow that convention ... and it needs to be > > well documented, with the consequence of breaking that convention > > explained, and the terrible punishments to come described in great and > > sordid detail. Because this needs to be more than a convention, it needs > > to be an article of faith. > > I just want to clarify something here. > > Its accepted that most layers will append to BBPATH. I do think its > acceptable for a distro policy layer to prepend though and this is why > meta-yocto does this. I don't remember the exact reason right now but > the principle stands. Then the reason should be documented in layer's README file with warning that this layer wants to be first or last in BBPATH so whoever is setting BBLAYERS can decide where to put it. > The root of the problem is that meta-yocto mixes up policy and hardware > support which is bad. It also means its not compliant with the new Yocto > Project compliance criteria and hence is not Yocto Project Compatible. > > Now we've got the compliance criteria sorted out there are some > adjustments that need to be made and I will shortly be cleaving > meta-yocto into two pieces to resolve this. I hadn't looked at this > until now mainly in case there were changes to the criteria. > > FWIW I think this shows the strength of those criteria as by following > them, we'd avoid a real world problem here. > > Cheers, > > Richard > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On Tue, Sep 04, 2012 at 09:18:43PM -0700, Saul Wold wrote:
> On 09/04/2012 02:00 PM, Martin Jansa wrote:
> > On Tue, Sep 04, 2012 at 01:57:19PM -0700, Saul Wold wrote:
> >> Signed-off-by: Saul Wold
> >> ---
> >> .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++
> >> .../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++
> >> .../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++
> >> 3 files changed, 14 insertions(+), 0 deletions(-)
> >> create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> >> create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> >>
> >> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> >> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> >> index 58a6541..138cc21 100644
> >> --- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> >> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> >> @@ -2,3 +2,5 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >>
> >> # enable the time limited kernel configuration options
> >> SRC_URI += "file://time-limited-kernel.cfg"
> >> +
> >> +PR .= ".1"
> >
> > why not
> > PRINC := "${@int(PRINC) + 1}"
> > ?
>
> I understood that the .1 adds more finer granularity instead of
> incrementing the base PR itself. You end up with a potential r1.2.1
> which is still legal.
Yes but also makes order of .bbappends applied even more important.
In case one layer has
PR .= ".2"
and other
PR .= ".1"
Then it will provide r1.2.1 or r1.1.2 depending on order of bbappends
applied. Hopefully you want change order of layers to break every
upgrade path, but why not use PRINC which does not suffer from this?
> What happens with a r1.2 and the above @int(PRINC) + 1?
I guess it will produce r2.2
princ = d.getVar('PRINC', True)
if princ and princ != "0":
pr = d.getVar('PR', True)
pr_prefix = re.search("\D+",pr)
prval = re.search("\d+",pr)
if pr_prefix is None or prval is None:
bb.error("Unable to analyse format of PR variable: %s" % pr)
nval = int(prval.group(0)) + int(princ)
pr = pr_prefix.group(0) + str(nval) + pr[prval.end():]
d.setVar('PR', pr)
Cheers,
>
> I would need to test it, done for the day right now.
>
>
> Sau!
>
> >> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> >> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> >> new file mode 100644
> >> index 000..138cc21
> >> --- /dev/null
> >> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> >> @@ -0,0 +1,6 @@
> >> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >> +
> >> +# enable the time limited kernel configuration options
> >> +SRC_URI += "file://time-limited-kernel.cfg"
> >> +
> >> +PR .= ".1"
> >> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> >> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> >> new file mode 100644
> >> index 000..138cc21
> >> --- /dev/null
> >> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> >> @@ -0,0 +1,6 @@
> >> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >> +
> >> +# enable the time limited kernel configuration options
> >> +SRC_URI += "file://time-limited-kernel.cfg"
> >> +
> >> +PR .= ".1"
> >> --
> >> 1.7.7.6
> >>
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/3] base-files: add /etc/motd with TLK info
On Wed, 2012-09-05 at 09:56 -0700, Saul Wold wrote:
> Signed-off-by: Saul Wold
Acked-by: Tom Zanussi
> ---
> .../base-files/base-files_3.0.14.bbappend |3 +++
> meta-tlk/recipes-core/base-files/files/motd|7 +++
> 2 files changed, 10 insertions(+), 0 deletions(-)
> create mode 100644
> meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
> create mode 100644 meta-tlk/recipes-core/base-files/files/motd
>
> diff --git a/meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
> b/meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
> new file mode 100644
> index 000..248b225
> --- /dev/null
> +++ b/meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend
> @@ -0,0 +1,3 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> +
> +PR .= ".1"
> diff --git a/meta-tlk/recipes-core/base-files/files/motd
> b/meta-tlk/recipes-core/base-files/files/motd
> new file mode 100644
> index 000..13cd74c
> --- /dev/null
> +++ b/meta-tlk/recipes-core/base-files/files/motd
> @@ -0,0 +1,7 @@
> +This image contains a time limited kernel and will reboot the machine
> +automatically in 10 days. Do not include this image in a product.
> +
> +Use the image for evaluation purposes only.
> +
> +Please see http://www.yoctoproject.org/tlk for instructions on how to
> +eliminate the timeout.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] linux-yocto: Update linux-yocto for 3.2 and 3.4
On Wed, 2012-09-05 at 09:56 -0700, Saul Wold wrote:
> Signed-off-by: Saul Wold
Acked-by: Tom Zanussi
> ---
> .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++
> .../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++
> .../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++
> 3 files changed, 14 insertions(+), 0 deletions(-)
> create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
>
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> index 58a6541..138cc21 100644
> --- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
> @@ -2,3 +2,5 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> # enable the time limited kernel configuration options
> SRC_URI += "file://time-limited-kernel.cfg"
> +
> +PR .= ".1"
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> new file mode 100644
> index 000..138cc21
> --- /dev/null
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
> @@ -0,0 +1,6 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +# enable the time limited kernel configuration options
> +SRC_URI += "file://time-limited-kernel.cfg"
> +
> +PR .= ".1"
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> new file mode 100644
> index 000..138cc21
> --- /dev/null
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
> @@ -0,0 +1,6 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +# enable the time limited kernel configuration options
> +SRC_URI += "file://time-limited-kernel.cfg"
> +
> +PR .= ".1"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/3] psplash: Add TLK info to psplash image
On Wed, 2012-09-05 at 09:56 -0700, Saul Wold wrote:
> Signed-off-by: Saul Wold
Acked-by: Tom Zanussi
> ---
> .../recipes-core/psplash/files/psplash-tlk.png | Bin 0 -> 42295 bytes
> meta-tlk/recipes-core/psplash/psplash_git.bbappend | 10 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
> create mode 100644 meta-tlk/recipes-core/psplash/files/psplash-tlk.png
> create mode 100644 meta-tlk/recipes-core/psplash/psplash_git.bbappend
>
> diff --git a/meta-tlk/recipes-core/psplash/files/psplash-tlk.png
> b/meta-tlk/recipes-core/psplash/files/psplash-tlk.png
> new file mode 100644
> index
> ..54b8fae7220e12d1a0cbf33cea6dfbe341f0b55a
> GIT binary patch
> literal 42295
> zcmb5VXH=6-8#NjqMQnf#QL2i9f`B5uMd>0%nt=2o@X#VsLQPZzL zp!D7eEeX9R)DR#f`G)8Hew?+=IzLX zH-bR^K|mmfh{yf`|8t*PbrO6Wf2M8W1A&}8ckpuvl9F~20y$yuubSGUN3Jkmn2#&$
> z+2sdnYL}lqhdKZ2@e~3H7)>{JF)?1epiCufsXl!3;^RY@5$CbXMyk;-&c_RhTseMP
> z=gpO`BbH;c5Bu=5TE6i+7xcw@$r1G0Zx1 zr!rr#nO@q>T6gT!C+)k2(l1Wss`8(i2y1R=nw$~8_wvNGXOPp!N}aCw&;<`cb`VNR
> zqF3u!v5-Rn{U?t>>hx0UZu3SmIhItDtq#3-eW=biUhd(s7v~}Of?`#FLhflEdXfHF
> z$QbhF2*j@4(P0|$NDN{pjGXI-yhz_k4n732{CI`)(3g0~<#SKps6$*8AqCx!-)cb2
> zZ$r*IKWvbP42wZ-KQMFFh7?yo>bg#!`~^973Ub@ z(z+<>^t=cdspMZuRoCP-URoX#^JX zfqaSQ1W&t359ne?b#=+amb2T6E!7@nUUhJoX3TcyKf4EkO!^{v8Mh=#xnC$Aec{RY
> zcAb30)#l_EKWen|FOGXK(V*_oMPod#7)`!=&shRa{uIy1V*
> zE<$OaN}0e;U3)2M{Zi}5&cxr2E!`iy-5-v>b{L z?^yMecbk$wu12YTxY>BUkLff;yhS^#LX?ISyQv%sju*?Zc09cOQ24aDZ`~9X0@*;r
> z{tVnWcKC&B*km`HxeBFgeYp;K;r!r(Hw0p%eofq@trXgP3<6RA@=~PuKF`*li?`~I
> z^8R5N|8sKRPUf}hwT8c{r&Uilz2JRrceCJ?>WzrbVm=W&iGh23Qgw!|5ed)O#s8XC
> zvMWF1*t0*D@#jX(%i~Axw;VfXe`WN|A&0l-g0aWAlEZhd{LwygHu~D-);H%3uRe^I
> z*1lu(*5tCOHs6Nw^MB+ctu(9S6 zq{LnLlG^k9H@EUTnXmIb`K}zJaVl!fx9b)zvfgd*xGmmPuUaB^>v)1=d&$*;Q~6EY
> z#g7XPqoXK}-6ilNXJ2a69hW%*SG{b{e_z{N*Ia*CJLfX*HK{YB$7PQner@ z!{0*HXLcJdI!NA$G}pc*ICM7doW$wiH);*C*Um<%NeWlJ|K~x;cay%eeVTn za#N+WxdjtiN1fb%vC4nEby>6}d?tOSe&+5B&&-t#%M zYWC>U&yx2|vr>%kIbTiANXI= z@U1?BPvqB6>M`qUU({MiS~$D~KgAZo8P@#9<;JDdi>w!2F2OGreb)VXsXzKsv&n7Q
> zJIkNvlR1)Mrsg8$A|agdZ6^|S5`_|ZL?ldd^M2+L@=ls=nzoz7<=PmBqBKqK8c*jQ
> zANZ7SnwS1)*_g-JC08*gGS4LkW&-_=u%JgBwW!yvH&FX-_@%^lx~A#!Nykg20k^KW
> zv*kzly_9YcD(M^v@fSgVrt_hrmGg4H%B$VgxocKxwE58)$~yhodne6T|M>ik?4(V^
> zTf+I(n^QM=eoE<9-Fa%|p7$x~lX<>&zG1%BGDZeP%1-}@(Lh_!Ub5eB))BT6)^dsK
> zVo9Gj9x=vepUA$Tr>sChiRZch;Q5MHhu3;#lRsx*ZC+&P!m zqIJsrXz8hIN5@WeT~un6_J%3(Ni>hG8>(5?-&6ZxpJ<;n`8vL;S1D^yGe(o+-M>v%
> z)7Pdwn>?GcgpLYb5qhY%q(@FM(yRJ;^QWS&qHc3%N9VWBp=9Y) z?n%ItTje?Bl}{i1ntAfmf?QtX75+rt;)l8E6YEmV!t}!HL+C z;`Q>@^4y9`#k0dl$57>-<)QX24qPr3ji`EZ0wy7}Iy8o^%*qxy!k*9fgb(5K`}ui=
> z#|ng$t~4?Bo*;g
> zo+f+?W=6-C;%z+{)JI8AElvGP${8yn%aH#iM~-K9NM+v4u(<2fQ{SRCVL00hJ(-z!
> z+nrc|Fiscfq}&zx47R+1%15-e;xWa}zgD%uU|
> zVHvjJL^Y%!(}@|x?1f~%xPHjxaMa8DFD?I}?F5Bfsf~pyj6L1{HA1@o?n~8u&iiq%
> z3SZ6sDZJv^vhu$03U&T-SA5sM?BS0P3qw7u_H*{p^@vl#;gR8H5zyFYZ_K%S?<7gX
> zd&kv$i0XUlpVSGdE_V#%i^O!KMO5;{-IPXUtEH-;P2$cL9fRiS<_|m`^2&>gpk%x}
> zu*7}RX5>`*)XC{!uFn!J*3SaJcKzK7&%Tf=e)g8ar+d0@^yNOT-9IgobK%|fjdSqp
> zu_prm^8IzWD$y&``({|pN`zm3Lt8{I=)+2Ujdb9(#=Adm%~rh@&V65_%chG@RmixI
> z;(yswQdt3WC+tJ~dvDdeD|!j#E=w+R&i?HMPs4vP8oi<`B={3qTir|F7qD1}ohVoR
> zxnT0-22Odl$XeP#IK8GoA
> zlmDgU9XNJknv+E|;_=Y}rOLPEBA$Z=`6RO>6apg@r04$9=1<$JKV^s9mrt6Wm< z9>Se?=jJz5IdwbtIWNu;
> z#4;?|KjkIOC9!+4jg093qHJr7NhEdN7(<7Zt5s#yDpl4z&2H`LRD_y*H`y}T
> zGm#77ddO67(0TAF?E$Tn3PnZbE$)1xd0H3h
> zdwP?a5BD9WvkJ18 zm7h&v)c;*@!6a+HfIpuLpM;xg%0`N2s&NX<(!sLYphKm1Xo(QCuQevXktU^N5va3i
> z()#b{;;a4ymyPas>51u~2=U! zvDtHGm1ZeL3bvk0zDr7sgnol&bQ(GZRb}N~MGnH01v^t0c`{_X@LQO`^$X0Q!3=q2
> zJZ3WpMs1{0h!^mP=fd=^cJv5bm|R$6P-DAwk92=T4IeoOwPcJBuZ|<#>fm2Cd&jk?
> zN5jLq8S#`j4mFmz z{oMOCX(K72)-&V>eW`BwQqfq`-zI)+Yrx$*Hd~Krq(AU+INxd(k;7mn zV%(EWOSqJfz&vvJ^X9(eU9mBMH;=g7*Simal*ES63=_cbmmRf@^dOL+>k!C`FbHIq
> z2|gDg5Wm|H$dVldqVO34;evgzZPbK7Qj8v`-!};uT}cnLGBIT~uXYrl=y><`?M-&_
> z$+piwg*Z)q_FjE_zWimbp+)8EKDVvt=4`z?YD>A=damcPRG+l`cy;1%BkxD6=k`Z9
> zIsKf~M_drdkXc{M-BUg;M=w$~5xX1G9pk~ zzjGbDzqdJf?>l+$t}Su!zQ_XJ{&&fXtpj}hzf0}~9RmOU-zEQ#8~pE*|J~q!m;8U-
> z;Q!Ue|9Wt61C$$L$7_1Va&>ohp7{R!L|!A?0|;c{;yX=8N5|>#lVyH>eofATXOA4T
> z@C9=_S(lBCt(I$lx0Y(g$(8twS2+H%>3_EyjcjUaqSH7KJB%e*?Jk1|`-=ImbNbo2
> zxm8O6rgNiy?vIg=&CDW?96I>IRU#!dRU)l+&2JmN`n?7|*I{w(*uf*;3$~ZyUS8%w
> z&}XTfH&;m`r2@zQIcTHDrsqi>9!;&GH@z(kAA5fpK=VTolKTq3ywR?W+g`Oqt)|<5
> z!}wc~w$1k@W!qJ+Gw>P<#Pd~u0R*By5z-mBApTzytTNY)q=f$a`~TlV`+uj8Ao}j-
> z&$*^1%_KIP&`?aPld24ur|(pqIw#3=C~~q{KnB&_c85Dg{Nmq;h=@37+c27%84+=G
> z22B5Nfl8@j!JPbj#kKCQRH7vXAE6XGjY4~Ez5g0!CHB5{e}BvpR-pZm?n>Sl&dMg{
> zujKjqBwSeqk z5iO{VxNgjC=>8|3(2#2FYajG^MQ(G)NNM*B40H&Hz1O}*CVTNVKah*+&>M<+dE}PX
> zC?zoIual&-taPeeLaURThsW85Xq}%XB8fUbZX`qc#!4K91`2SCwYz)h-ve=7Y4YvN
> zMcOLjZ6>o}ZBorj_;;!-vpN_@T zlee_+{y1H!7TK0>knS887#J9y6Si0nMj(V9Qth|AG&eUlIZ2+I^Eb7&o4?w>DVeOh
> zvKjljChU4A=pT4VNy$h{U)qW&b)iJEC*sob|8?^kS{cWWZx!wBwbFCks3#Ui^3A#l
> znBc&m!0M{1z)Cc_DhtE%p5R~aDwR z8k; z$M#5leO6{3?Ah9F%7WoiuOKVOrG>@C#mPzW#~fBx4yh?Ax z@TH}@sM9r}G{zaqK9t6Bnn#p}u}CnbMw(J=+<}_anG%8w9+C
> zu@9jMho-@KI20(Tu6dR`DPN=oC(%F6a^wz
Re: [yocto] [PATCH 0/3 v3] Meta-tlk update
On Wed, 2012-09-05 at 09:56 -0700, Saul Wold wrote: > The following changes since commit 16a7879b98352b70e8c17181912a26212d716c87: > > meta-emenlow: rename recipes-gnome bbappends (2012-09-04 10:04:37 -0500) > > are available in the git repository at: > git://git.yoctoproject.org/poky-contrib sgw/meta-tlk > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/meta-tlk > > Saul Wold (3): > linux-yocto: Update linux-yocto for 3.2 and 3.4 > base-files: add /etc/motd with TLK info > psplash: Add TLK info to psplash image > Pulled into meta-intel/master, thanks. Tom > .../base-files/base-files_3.0.14.bbappend |3 +++ > meta-tlk/recipes-core/base-files/files/motd|7 +++ > .../recipes-core/psplash/files/psplash-tlk.png | Bin 0 -> 42295 bytes > meta-tlk/recipes-core/psplash/psplash_git.bbappend | 10 ++ > .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++ > .../recipes-kernel/linux/linux-yocto_3.2.bbappend |6 ++ > .../recipes-kernel/linux/linux-yocto_3.4.bbappend |6 ++ > 7 files changed, 34 insertions(+), 0 deletions(-) > create mode 100644 > meta-tlk/recipes-core/base-files/base-files_3.0.14.bbappend > create mode 100644 meta-tlk/recipes-core/base-files/files/motd > create mode 100644 meta-tlk/recipes-core/psplash/files/psplash-tlk.png > create mode 100644 meta-tlk/recipes-core/psplash/psplash_git.bbappend > create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend > create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Wed, 2012-09-05 at 13:48 +0100, Richard Purdie wrote: > The root of the problem is that meta-yocto mixes up policy and hardware > support which is bad. It also means its not compliant with the new Yocto > Project compliance criteria and hence is not Yocto Project Compatible. > > Now we've got the compliance criteria sorted out there are some > adjustments that need to be made and I will shortly be cleaving > meta-yocto into two pieces to resolve this. I hadn't looked at this > until now mainly in case there were changes to the criteria. This has now been fixed in: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=2000698b17011bbde1c3e5bb01a7d6763316db5a ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] raspberrypi image questions
On Wednesday 05 September 2012 12:16:44 Gary Thomas wrote: > I just built Yocto/Poky for the raspberrypi, following the > recent thread on this list. I noticed that the resulting SD > image is ~4GB, but most of that space seems to be unused: > >$ ssh root@192.168.1.150 >Warning: Permanently added '192.168.1.150' (RSA) to the list of known > hosts. root@192.168.1.150's password: >root@raspberrypi:~# df >Filesystem 1K-blocks Used Available Use% Mounted on >/dev/root57388 46754 7718 86% / >none 93964 156 93808 0% /dev >/dev/mmcblk0p2 57388 46754 7718 86% /media/mmcblk0p2 >/dev/mmcblk0p1 19400 8928 10472 46% /media/mmcblk0p1 >tmpfs9396456 93908 0% /var/volatile >tmpfs93964 0 93964 0% /dev/shm >tmpfs93964 0 93964 0% /media/ram >root@raspberrypi:~# cat /proc/partitions >major minor #blocks name > > 17903977216 mmcblk0 > 1791 19456 mmcblk0p1 > 17923885056 mmcblk0p2 > > Notice that the physical partition for /dev/mmcblk0p2 is huge but > the file system is only 57MB. > > How can I adjust my build and/or resize the file system to actually > use the rest of the SD card? I suspect a resize2fs call is needed in there. Since the SD card class in meta-raspberrypi was changed to use the actual ext2 rootfs image instead of creating a new one on the fly, this has become an issue. I would suggest filing the issue on the meta-raspberrypi github. > Also, is it possible to just build the SD image much like I do for > other devices like the BeagleBoard, albeit with different contents > in /boot? Sloshing around 4GB images is rather painful, plus it > takes forever to DD it to the SD card. I must be missing something - do you want the rootfs larger or don't you? If it's expanded it will take up 4GB minus the boot partition size so you're into a large dd again... Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Tue, 2012-09-04 at 09:58 +0100, Tomas Frydrych wrote: > Hi Bruce, > > On 03/09/12 22:08, Bruce Ashfield wrote: > > That being said, taking a step back, what are you trying to get out of > > meta-yocto in this scenario ? > > a) I am targeting multiple chips, including TI Omap and Intel Atom. > meta-yocto is a prerequisite for the various machines in meta-intel, so > I have to include meta-yocto if I want to build images for an Intel > chip. Nothing unusual here. Is that really true? What in meta-intel depends on meta-yocto? This certainly isn't intentional so I'd like to understand more. > b) meta-yocto is the Poky distro layer; if you want to use Poky, then > you need meta-yocto. > > > see above. I misspoke. I don't think there's an intent to make meta-yocto > > and meta-ti work together, but oe-core + meta-ti, that's the combo that > > makes sense. > > See (b) above; you are not saying that Poky is only meant for Intel HW, > are you? > > The basic problem with meta-yocto is that it combines BSP stuff > (meta-intel prerequisite, Atom & Beagle config) with distro stuff (Poky, > Yocto branding). That's convenient for doing QA on a limited set of HW, > but suboptimal for real use; BSP layers simply should not be dependent > on distro layers, it largely defeats the purpose of having layers. > > Splitting out the minimal beagle config into a layer of its own would > improve things quite a bit. Effectively this is what we've now done and was always the intention (see the Yocto Project compatible criteria). Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Wed, 2012-09-05 at 10:20 -0400, William Mills wrote: > On 09/04/2012 07:23 PM, Darren Hart wrote: > > > > > > On 09/04/2012 01:25 PM, William Mills wrote: > > > >> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the > >> poky distro defs? That does seem to mixing things a bit. (I am not > >> claiming meta-ti is clean yet but I want to understand the Intel examples.) > >> > > > > It isn't something we test as part of the QA that we perform. I mostly > > expect people building meta-intel to be building with meta-yocto > > (although I wouldn't take a hard line on requiring it). That said, I > > removed meta-yocto from a meta-intel/meta-fri2 build and removed > > DISTRO=poky from my local.conf and successfully built and booted a > > core-image-minimal build on an FRI2 this afternoon without any changes. > > > > Thanks! My confidence is restored. > > As long as including meta-yocto does not interfere with other BSPs or > distros etc then there should be no harm in your assumption. > > I would be interested to know what Mentor Graphics and Wind River do on > their products. Do they include meta-yocto? (YP is not all about > comercial OS support but I know these orginatations have done the due > diligence on layer compatibility for a non-poky distro.) Commercial OS support usually involves some of your own policy so meta-yocto is interesting as an example to them but they'd probably only use it as inspiration to write their own. That was always expected and meta-yocto is extremely thin deliberately. Having said that, what meta-yocto was doing was wrong, it wasn't intentional, the implications not fully realised and is hopefully now fixed with the split :). Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
On 05/09/2012 18:13, Trevor Woerner wrote: I also found that I had to add: BB_DANGLINGAPPENDS_WARNONLY = "yes" at the end of my conf/local.conf since I received a: ERROR: No recipes available for: /home/trevor/devel/yocto/raspi/poky/meta-raspberrypi/recipes-multimedia/libav/libav_0.7.4.bbappend the first time I tried baking (even when using the exact commits for both poky and meta-raspberrypi as specified in the instructions). Maybe it's just me? Correct again Trevor, I've added the appropriate BBMASK required! Thanks for taking the time to go over it all. Cheers, Jack ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] raspberrypi image questions
On 05/09/2012 22:46, Paul Eggleton wrote: On Wednesday 05 September 2012 12:16:44 Gary Thomas wrote: I just built Yocto/Poky for the raspberrypi, following the recent thread on this list. I noticed that the resulting SD image is ~4GB, but most of that space seems to be unused: $ ssh root@192.168.1.150 Warning: Permanently added '192.168.1.150' (RSA) to the list of known hosts. root@192.168.1.150's password: root@raspberrypi:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root57388 46754 7718 86% / none 93964 156 93808 0% /dev /dev/mmcblk0p2 57388 46754 7718 86% /media/mmcblk0p2 /dev/mmcblk0p1 19400 8928 10472 46% /media/mmcblk0p1 tmpfs9396456 93908 0% /var/volatile tmpfs93964 0 93964 0% /dev/shm tmpfs93964 0 93964 0% /media/ram root@raspberrypi:~# cat /proc/partitions major minor #blocks name 17903977216 mmcblk0 1791 19456 mmcblk0p1 17923885056 mmcblk0p2 Notice that the physical partition for /dev/mmcblk0p2 is huge but the file system is only 57MB. How can I adjust my build and/or resize the file system to actually use the rest of the SD card? I suspect a resize2fs call is needed in there. Since the SD card class in meta-raspberrypi was changed to use the actual ext2 rootfs image instead of creating a new one on the fly, this has become an issue. I would suggest filing the issue on the meta-raspberrypi github. Also, is it possible to just build the SD image much like I do for other devices like the BeagleBoard, albeit with different contents in /boot? Sloshing around 4GB images is rather painful, plus it takes forever to DD it to the SD card. I must be missing something - do you want the rootfs larger or don't you? If it's expanded it will take up 4GB minus the boot partition size so you're into a large dd again... Cheers, Paul I think what he means (or this is what I would like to see ) is a boot.tar.gz and a rootfs.tar.gz which can then be extracted straight onto the partitions? Hence only a ~40mb boot write and ~50mb rootfs write rather than a 4GB dd slog. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto
On 04/09/12 09:43, Jack Mitchell wrote: On 03/09/12 22:00, Tomas Frydrych wrote: Hi Jack, On 03/09/12 18:52, Jack Mitchell wrote: As some of you know I run a small Raspberry Pi community site[1] and I would like to write a follow up to an earlier blog post about preparing yourself for programming on the Raspberry Pi with the Yocto Project. I don't know if of any use to you, but we have a recipe for a Yocto-based image for a UPnP audio player, which can be built for the RPi, in Guacamayo[1]. Tomas [1] https://github.com/Guacamayo/meta-guacamayo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Hi Tomas, That looks like an interesting layer. I have seen it pop up here and there but have never investigated it properly. Once this post is out the door and I have started experimenting with . other new image builds and applications I may be in touch! Cheers, ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] how to add a new environment in poky
Hi
I need to add a new environment that LD_LIBRARY_PATH when I use my own
external toolchain .
I add 1 line in external-toolchain.inc "LD_LIBRARY_PATH =.
"${EXTERNAL_TOOLCHAIN}/i586-target-linux-gnu/lib:"",but there is no effect.when
I used this toolchain to compile , there also isn't this value , so I want to
ask how to add a environment in poky ? the run.compile.xxx script can get the
value ?
thanks & rgds
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] raspberrypi image questions
On 05/09/2012 22:46, Paul Eggleton wrote: On Wednesday 05 September 2012 12:16:44 Gary Thomas wrote: I just built Yocto/Poky for the raspberrypi, following the recent thread on this list. I noticed that the resulting SD image is ~4GB, but most of that space seems to be unused: $ ssh root@192.168.1.150 Warning: Permanently added '192.168.1.150' (RSA) to the list of known hosts. root@192.168.1.150's password: root@raspberrypi:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root57388 46754 7718 86% / none 93964 156 93808 0% /dev /dev/mmcblk0p2 57388 46754 7718 86% /media/mmcblk0p2 /dev/mmcblk0p1 19400 8928 10472 46% /media/mmcblk0p1 tmpfs9396456 93908 0% /var/volatile tmpfs93964 0 93964 0% /dev/shm tmpfs93964 0 93964 0% /media/ram root@raspberrypi:~# cat /proc/partitions major minor #blocks name 17903977216 mmcblk0 1791 19456 mmcblk0p1 17923885056 mmcblk0p2 Notice that the physical partition for /dev/mmcblk0p2 is huge but the file system is only 57MB. How can I adjust my build and/or resize the file system to actually use the rest of the SD card? I suspect a resize2fs call is needed in there. Since the SD card class in meta-raspberrypi was changed to use the actual ext2 rootfs image instead of creating a new one on the fly, this has become an issue. I would suggest filing the issue on the meta-raspberrypi github. Also, is it possible to just build the SD image much like I do for other devices like the BeagleBoard, albeit with different contents in /boot? Sloshing around 4GB images is rather painful, plus it takes forever to DD it to the SD card. I must be missing something - do you want the rootfs larger or don't you? If it's expanded it will take up 4GB minus the boot partition size so you're into a large dd again... Cheers, Paul I think what he means (or this is what I would like to see ;) ) is a boot.tar.gz and a rootfs.tar.gz which can then be extracted straight onto the partitions? Hence only a ~40mb boot write and ~50mb rootfs write rather than a 4GB dd slog. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On Tue, 2012-09-04 at 09:21 +0100, Jack Mitchell wrote: > On 03/09/12 22:08, Bruce Ashfield wrote: > > On Mon, Sep 3, 2012 at 4:55 PM, Tomas Frydrych > > wrote: > >> snip... > >> > >> > >> > >> That being said, taking a step back, what are you trying to get out of > >> meta-yocto in this scenario ? oe-core + meta-ti is probably what you > >> should be using. > >> > > Sorry to jump in here, but this is actually a very interesting point. > From coming to OpenEmbedded through Yocto and subsequently learning > about the ecosystem as a whole, I have always considered meta-yocto to > be providing a sane distro configuration. This implies that I believe > the oe-core default distro configuration, even though it will build, the > result won't be very satisfying - or maybe a bit disjointed. > > You seem to be saying above that the meta-yocto layer is only any good > for providing the kernel framework, and as he is not using the framework > (i.e. using meta-ti) then there is no point in using the meta-yocto > layer? So does the Poky distro config only really slap a name on the > oe-core default distro policy - or does it have some added value? In the old days, there was no default distro config. OE-Core changed that as an experiment which IMO has been relatively successful. The Poky distro config inherits as much as possible from the core defaults. The extras are (reading poky.conf): * Example of Distro Branding * Ensuring some particular kernel versions * Particular SDK layout * Minor tweaks to basic images/qemu images * Mirror Setup (although OE-Core has these now too iirc) * Sets connectivity check * Sets list of compatible/tested distros * Some signature stuff (now OE-Core default) * Sets more stringent package sanity checks that OE-Core So at least some of the above moved into the core as default although we still need to remove the remnants from the poky.conf file. Others will likely move in future too. There isn't anything major above but there are several smaller usability tweaks/optimisations and I'd argue there is some added value. There are also example LSB and "tiny" profiles showing how to take the system and customise it in different ways which I'd argue have value too. > I'm not trying to rile anyone up here, just trying to put the jigsaw > together as the picture looks different every time I revisit it!! Its an evolving picture, hopefully in a good way :) Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] raspberrypi image questions
On Wednesday 05 September 2012 22:57:22 Jack Mitchell wrote: > On 05/09/2012 22:46, Paul Eggleton wrote: > > On Wednesday 05 September 2012 12:16:44 Gary Thomas wrote: > >> Also, is it possible to just build the SD image much like I do for > >> other devices like the BeagleBoard, albeit with different contents > >> in /boot? Sloshing around 4GB images is rather painful, plus it > >> takes forever to DD it to the SD card. > > > > I must be missing something - do you want the rootfs larger or don't you? > > If it's expanded it will take up 4GB minus the boot partition size so > > you're into a large dd again... > > I think what he means (or this is what I would like to see ) is a > boot.tar.gz and a rootfs.tar.gz which can then be extracted straight > onto the partitions? Hence only a ~40mb boot write and ~50mb rootfs > write rather than a 4GB dd slog. Ah, I see, that makes more sense. Another thing to add to the meta-raspberrypi issue tracker. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] raspberrypi image questions
On 05/09/12 22:56, Jack Mitchell wrote: > On 05/09/2012 22:46, Paul Eggleton wrote: >> On Wednesday 05 September 2012 12:16:44 Gary Thomas wrote: >>> I just built Yocto/Poky for the raspberrypi, following the >>> recent thread on this list. I noticed that the resulting SD >>> image is ~4GB, but most of that space seems to be unused: >>> >>> $ ssh root@192.168.1.150 >>> Warning: Permanently added '192.168.1.150' (RSA) to the list of >>> known >>> hosts. root@192.168.1.150's password: >>> root@raspberrypi:~# df >>> Filesystem 1K-blocks Used Available Use% Mounted on >>> /dev/root57388 46754 7718 86% / >>> none 93964 156 93808 0% /dev >>> /dev/mmcblk0p2 57388 46754 7718 86% >>> /media/mmcblk0p2 >>> /dev/mmcblk0p1 19400 8928 10472 46% >>> /media/mmcblk0p1 >>> tmpfs9396456 93908 0% >>> /var/volatile >>> tmpfs93964 0 93964 0% /dev/shm >>> tmpfs93964 0 93964 0% /media/ram >>> root@raspberrypi:~# cat /proc/partitions >>> major minor #blocks name >>> >>> 17903977216 mmcblk0 >>> 1791 19456 mmcblk0p1 >>> 17923885056 mmcblk0p2 >>> >>> Notice that the physical partition for /dev/mmcblk0p2 is huge but >>> the file system is only 57MB. >>> >>> How can I adjust my build and/or resize the file system to actually >>> use the rest of the SD card? >> I suspect a resize2fs call is needed in there. Since the SD card class in >> meta-raspberrypi was changed to use the actual ext2 rootfs image >> instead of >> creating a new one on the fly, this has become an issue. I would >> suggest filing >> the issue on the meta-raspberrypi github. >> >>> Also, is it possible to just build the SD image much like I do for >>> other devices like the BeagleBoard, albeit with different contents >>> in /boot? Sloshing around 4GB images is rather painful, plus it >>> takes forever to DD it to the SD card. >> I must be missing something - do you want the rootfs larger or don't >> you? If >> it's expanded it will take up 4GB minus the boot partition size so >> you're into >> a large dd again... >> >> Cheers, >> Paul >> > > I think what he means (or this is what I would like to see ;) ) is a > boot.tar.gz and a rootfs.tar.gz which can then be extracted straight > onto the partitions? For the rootfs, you can just add IMAGE_FSTYPES += "tar.bz2" somewhere suitable; I tend to do that for all my images, as it makes it easy to examine the rootfs contents. Tomas Hence only a ~40mb boot write and ~50mb rootfs > write rather than a 4GB dd slog. > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto beagleboard.conf -- should it not go away?
On 05/09/12 22:46, Richard Purdie wrote: > On Tue, 2012-09-04 at 09:58 +0100, Tomas Frydrych wrote: >> Hi Bruce, >> >> On 03/09/12 22:08, Bruce Ashfield wrote: >>> That being said, taking a step back, what are you trying to get out of >>> meta-yocto in this scenario ? >> >> a) I am targeting multiple chips, including TI Omap and Intel Atom. >> meta-yocto is a prerequisite for the various machines in meta-intel, so >> I have to include meta-yocto if I want to build images for an Intel >> chip. Nothing unusual here. > > Is that really true? What in meta-intel depends on meta-yocto? No, it is not true; I corrected that erroneous statement earlier in this thread. > Effectively this is what we've now done and was always the intention > (see the Yocto Project compatible criteria). Yes, that looks like it solves the problem neatly. Now I should be able to include both meta-yocto and meta-yocto-bsb if I want to. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
