I'm getting a QA failure when running a build from a recent git master:

Checking autotools environment for common misconfiguration
NOTE: Checking autotools environment for common misconfiguration
linux: Recipe file does not have license file information (LIC_FILES_CHKSUM)
ERROR: linux: Recipe file does not have license file information (LIC_FILES_CHKSUM)
Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
Function 'do_qa_configure' failed
ERROR: Function 'do_qa_configure' failed

This is when building kernel version 2.6.33.2-r2.

Chris Tapp

opensource@...
www.keylevel.com

On 01/24/2011 01:46 PM, Bruce Ashfield wrote:

Saul/Richard,

I'm batching two changes that I've been testing together.

The first is explained by the patch itself, but basically it
allows us to map multiple BSPs onto a single branch for building.
There's no impact to existing BSPs, but as we go forward it means
that if boards only differ by configuration we can avoid branch
explosion in the kernel repo and pickup their different
configurations. If at any point we need to break them out from
using a common branch, that is an easy switch to do. I've been
testing this with a test enablement of the atom-pc using the
yocto/standar/base branch .. and it works nicely.

The second is an update to pickup Tom's patches for the emenlow.
Tom will follow up with changes to have the emenlow use the
2.6.37 kernel as well as the 2.6.34 kernel.

These are based on top of the beagleboard commits I sent on
Friday, which I've heard are working their way through the
queue.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield<bruce.ashfield@...>
---


Bruce Ashfield (2):
linux-yocto: allow multiple BSPs per branch
linux-yocto: update SRCREVs for emenlow

meta/classes/kernel-yocto.bbclass | 4 ++--
.../conf/distro/include/poky-default-revisions.inc | 6 +++---
.../kern-tools/kern-tools-native_git.bb | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

Oops, both where pulled

Sau!

On 01/24/2011 01:46 PM, Bruce Ashfield wrote:

The emenlow has been ported/tested on 2.6.37. Updating the SRCREVs
to reflect the change.

Signed-off-by: Bruce Ashfield<bruce.ashfield@...>
---
.../conf/distro/include/poky-default-revisions.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index b9602ea..8d98eef 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -100,12 +100,12 @@ SRCREV_machine_pn-linux-yocto_qemumips ?= "2b43d84250a582b61397ad5f59a6445ce1258
SRCREV_machine_pn-linux-yocto_qemuppc ?= "20f182db27f3e6fc6bd55bfc9e24c8c023fbff7f"
SRCREV_machine_pn-linux-yocto_qemux86 ?= "a9d833fda90e2f1257888a97e092135610b5f259"
SRCREV_machine_pn-linux-yocto_qemux86-64 ?= "a9d833fda90e2f1257888a97e092135610b5f259"
-SRCREV_machine_pn-linux-yocto_emenlow ?= "a9d833fda90e2f1257888a97e092135610b5f259"
+SRCREV_machine_pn-linux-yocto_emenlow ?= "c19e556f79f03c8f1e5e84ccd9b5436c2001fcce"
SRCREV_machine_pn-linux-yocto_atom-pc ?= "a9d833fda90e2f1257888a97e092135610b5f259"
SRCREV_machine_pn-linux-yocto_routerstationpro ?= "219a5f9dc6e5beced36184e141f80b2df61ae32f"
SRCREV_machine_pn-linux-yocto_mpc8315e-rdb ?= "3f01b98238c2ff7913ce9f68f9db5ae9538717bc"
SRCREV_machine_pn-linux-yocto_beagleboard ?= "a9d833fda90e2f1257888a97e092135610b5f259"
-SRCREV_meta_pn-linux-yocto ?= "e3895db37bd65ea97e59b70ea936c84b398d3f3e"
+SRCREV_meta_pn-linux-yocto ?= "8a49ef6f1a43dabbce34a9ee9a1be08b26fc511c"
SRCREV_pn-linux-libc-headers-yocto ??= "a9d833fda90e2f1257888a97e092135610b5f259"
SRCREV_pn-matchbox-config-gtk ??= "2081"
SRCREV_pn-matchbox-desktop-sato ??= "76"

Pulled into Master

Thanks
Sau!

On 01/21/2011 12:23 PM, Bruce Ashfield wrote:

Richard/Saul,

Just another quick update to pickup a change that gets beagleboard xm
networking functional.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield<bruce.ashfield@...>
---


Bruce Ashfield (1):
linux-yocto/stable: update beagleboard SRCREV

.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

Pulled into Master

Thanks
Sau!

On 01/21/2011 10:23 AM, Bruce Ashfield wrote:

Richard/Saul,

Just a couple of SRCREV updates to bring in new kernel configs
for the crownbay and some functionality (cherry picked from
mainline) for the Beagle.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield<bruce.ashfield@...>
---


Bruce Ashfield (2):
linux-yocto/stable: update beagleboard SRCREV
linux-yocto/stable: update crownbay kernel configuration

.../conf/distro/include/poky-default-revisions.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky

Pulled into Master

Thanks
Sau!

Saul Wold wrote:

Folks,

Apologies for the extended absence of bugzilla.yoctoproject.org, it is
back up now and working.

As we head into the next phase of Poky / Yocto Metadata 1.0, we need
to have people evaluate the existing bugs and determine if they can be
fixed for 1.0 or need to be marked for the next release.

Currently there are 170 open bugs, we need to go through these and
ensure that their Importance and Target Milestones are correct.

I will be holding a Bug Triage meeting via the #yocto IRC Channel at
two times, in order to accommodate the global nature of the Yocto
Project. These will be about :30 to :45 minute meetings.

Tue February 1st @ 17:30 GMT / Tue 09:30 PST / Wed 01:00 China
Wed February 2st @ 07:00 GMT / Tue 23:00 PST / Wed 15:00 China

I don't think this time will work for the China folks since it'll be their
Feb. 3rd which is their Chinese New Year...

Please join the team to discuss any bugs that you have an interest
in.

Given the number of bugs and the time consideration, I'd suggest go through
bugs at medium and above level. So the pre-assignment for people before the
bug meeting is to promote those low priority bugs if there's specific reason
to do so...


I will be the "bug caller" at those times in order to facilitate

some semblance of order.

You can also send email or place a bugzilla comment directly for those
bugs that are important to you or your project.

Thanks for your support of the Yocto Project

Folks,

Apologies for the extended absence of bugzilla.yoctoproject.org, it is back up now and working.

As we head into the next phase of Poky / Yocto Metadata 1.0, we need to have people evaluate the existing bugs and determine if they can be fixed for 1.0 or need to be marked for the next release.

Currently there are 170 open bugs, we need to go through these and ensure that their Importance and Target Milestones are correct.

I will be holding a Bug Triage meeting via the #yocto IRC Channel at two times, in order to accommodate the global nature of the Yocto Project. These will be about :30 to :45 minute meetings.

Tue February 1st @ 17:30 GMT / Tue 09:30 PST / Wed 01:00 China
Wed February 2st @ 07:00 GMT / Tue 23:00 PST / Wed 15:00 China

Please join the team to discuss any bugs that you have an interest in. I will be the "bug caller" at those times in order to facilitate some semblance of order.

You can also send email or place a bugzilla comment directly for those bugs that are important to you or your project.

Thanks for your support of the Yocto Project

--
Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

From: Darren Hart [mailto:dvhart@...]
Sent: Friday, January 28, 2011 6:37 AM

On 01/26/2011 03:58 PM, Tian, Kevin wrote:

From: Chris Tapp
Sent: Wednesday, January 26, 2011 9:09 PM

I know this is probably a basic question, but I'm not having much luck !

I've built poky-image-minimal for atom-pc using the 0.9 Poky release.

This gives me an ext3 rootfs of over 80MB, which doesn't sound minimal
to me ;-)

This is a known issue in 0.9. the switch from ipk to rpm leaves some

temporary files

in the final ext3 rootfs, which results the large size.

Can I reduce the size of the image, or is it expected to be this size?

I've tried changing

IMAGE_ROOTFS_SIZE_ext3 = "500000"

This configuration option only works when it exceeds the size of generated

rootfs,

or else it will be changed implicitly to the actual size plus some extra buffer

in atom-pc.conf to another value, but this didn't make any
difference to the image that gets created (by re-running bitbake poky-
image-minimal after making the above change).

I've also tried using

ROOT_FLASH_SIZE = "64"

also without any luck.

Any help would be much appreciated !

I'd suggest you to use the master to see whether it works for you.

The alternative is to apply below commit to your 0.9 code:

commit 5e384038cbd5035377d61a1b77ad23ab69e0cac0
Author: Richard Purdie<richard.purdie@...>
Date: Wed Jan 5 18:56:47 2011 +0000

rootfs_rpm.bbclass: Remove temporary work files in install directory,

saving work files in install directory, saving the manifests as logfiles into ${T}

Signed-off-by: Richard Purdie<richard.purdie@...>

diff --git a/meta/classes/rootfs_rpm.bbclass

b/meta/classes/rootfs_rpm.bbclass

index 33abe96..2f7d691 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -202,8 +202,11 @@ EOF
# remove lock files
rm -f ${IMAGE_ROOTFS}${rpmlibdir}/__db.*

- # remove resolver files and manifests
- rm -f ${IMAGE_ROOTFS}/install/install.manifest
+ # Move manifests into the directory with the logs
+ mv ${IMAGE_ROOTFS}/install/*.manifest ${T}/
+
+ # Remove all remaining resolver files
+ rm -f ${IMAGE_ROOTFS}/install

This needs to be "rm -rf", there is another patch in master that takes
care of this: 21fafc889e81411735de7d04ffe504e5cff4830d

Thanks for the catch-up. I do remember that you dig it out but not realize related here. :-)

Thanks
Kevin

On 01/26/2011 03:58 PM, Tian, Kevin wrote:

From: Chris Tapp
Sent: Wednesday, January 26, 2011 9:09 PM

I know this is probably a basic question, but I'm not having much luck !

I've built poky-image-minimal for atom-pc using the 0.9 Poky release.

This gives me an ext3 rootfs of over 80MB, which doesn't sound minimal
to me ;-)

This is a known issue in 0.9. the switch from ipk to rpm leaves some temporary files
in the final ext3 rootfs, which results the large size.

Can I reduce the size of the image, or is it expected to be this size?

I've tried changing

IMAGE_ROOTFS_SIZE_ext3 = "500000"

This configuration option only works when it exceeds the size of generated rootfs,
or else it will be changed implicitly to the actual size plus some extra buffer

in atom-pc.conf to another value, but this didn't make any
difference to the image that gets created (by re-running bitbake poky-
image-minimal after making the above change).

I've also tried using

ROOT_FLASH_SIZE = "64"

also without any luck.

Any help would be much appreciated !

I'd suggest you to use the master to see whether it works for you.

The alternative is to apply below commit to your 0.9 code:

commit 5e384038cbd5035377d61a1b77ad23ab69e0cac0
Author: Richard Purdie<richard.purdie@...>
Date: Wed Jan 5 18:56:47 2011 +0000

rootfs_rpm.bbclass: Remove temporary work files in install directory, saving work files in install directory, saving the manifests as logfiles into ${T}

Signed-off-by: Richard Purdie<richard.purdie@...>

diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 33abe96..2f7d691 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -202,8 +202,11 @@ EOF
# remove lock files
rm -f ${IMAGE_ROOTFS}${rpmlibdir}/__db.*

- # remove resolver files and manifests
- rm -f ${IMAGE_ROOTFS}/install/install.manifest
+ # Move manifests into the directory with the logs
+ mv ${IMAGE_ROOTFS}/install/*.manifest ${T}/
+
+ # Remove all remaining resolver files
+ rm -f ${IMAGE_ROOTFS}/install

This needs to be "rm -rf", there is another patch in master that takes care of this: 21fafc889e81411735de7d04ffe504e5cff4830d

--
Darren

log_check rootfs

Thanks
Kevin
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 1/27/11 7:34 AM, Aleksandr Koltsoff wrote:

Chris Tapp wrote:

I've built poky-image-minimal for atom-pc using the 0.9 Poky release.

This gives me an ext3 rootfs of over 80MB, which doesn't sound minimal
to me ;-)

Can I reduce the size of the image, or is it expected to be this size?

Hi there,

The rpm packaging version does has some issues (half-statically built
binaries, full SAT-solver which might be an overkill for a minimal
image, etc).

Many of these items are resolved in the mhatle/rpm5 branch that is part of
poky-contrib. I'm trying to get the work finished for inclusion in the next day
or so.

But for a minimal image, RPM likely is too big of a hammer for the filesystem
design you want and IPK is likely more useful to you.

The place where I see RPM being needed is in medium size to larger (CGL) style
systems. Also places where a sat solver is necessary for field upgrades... even
though thats not quite working yet.

--Mark

I got much better results by switching to PACKAGE_CLASSES ?=
"package_ipk" in local.conf.

This will not be an RPM based system, but the image size will be
significantly smaller (especially if you're trying to reduce minimal).

Also, some fixes (post 0.9) should drop the rpm size requirement a bit,
if you want to try git/master.

regards,

ak.

On 11-01-27 09:22 AM, Chris Tapp wrote:

I've built poky-image-minimal for a machine that's based on
qemux86.conf. I've create a modified copy to target x86 hardware and
made sure usbhost and usbgadget are in the MACHINE_FEATURES.

If I boot on an Intel Atom board then everything is fine. However, if I
boot on a PC-Engines ALIX 3D3 the usb keyboard doesn't work and I can't
login.

I have had to disable USB 2 support in the ALIX BIOS to prevent "unable
to enumerate USB device on port ..." messages, but USB 1.1 is still
enabled. The OHCI device code is 1d6b:0001 and works ok with an EO build
that I have.

What's the kernel version on the working build ?
Do you have the dmesg output from the working/non working
boots handy ? Also the .config from your non-working
boot would also be handy.

Can anyone point me to where I should be looking to find out how to get
this working?

This smells like a configuration issue, or something different
between kernel versions. The information above will help us
narrow it down.

Cheers,

Bruce

Chris Tapp

opensource@...
www.keylevel.com



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

I've built poky-image-minimal for a machine that's based on qemux86.conf. I've create a modified copy to target x86 hardware and made sure usbhost and usbgadget are in the MACHINE_FEATURES.

If I boot on an Intel Atom board then everything is fine. However, if I boot on a PC-Engines ALIX 3D3 the usb keyboard doesn't work and I can't login.

I have had to disable USB 2 support in the ALIX BIOS to prevent "unable to enumerate USB device on port ..." messages, but USB 1.1 is still enabled. The OHCI device code is 1d6b:0001 and works ok with an EO build that I have.

Can anyone point me to where I should be looking to find out how to get this working?

Chris Tapp

opensource@...
www.keylevel.com

Chris Tapp wrote:

I've built poky-image-minimal for atom-pc using the 0.9 Poky release.

This gives me an ext3 rootfs of over 80MB, which doesn't sound minimal
to me ;-)

Can I reduce the size of the image, or is it expected to be this size?

Hi there,

The rpm packaging version does has some issues (half-statically built
binaries, full SAT-solver which might be an overkill for a minimal
image, etc).

I got much better results by switching to PACKAGE_CLASSES ?=
"package_ipk" in local.conf.

This will not be an RPM based system, but the image size will be
significantly smaller (especially if you're trying to reduce minimal).

Also, some fixes (post 0.9) should drop the rpm size requirement a bit,
if you want to try git/master.

regards,

ak.
--
Best regards,

Aleksandr Koltsoff
Head of Software Development, EKE Building Technology Systems
+358 44 566 2030, Piispanportti 7, 02240 Espoo, Finland
-= Easy Home Control for Everyone @ www.ebts.fi =-

Hi Darren,
I'm just trying to estimate the minimal footprint that can be achieved for an image with a basic set of features in order to have a comparison.
In march I'll participate in a local academia event in Argentina and I'll be talking about Yocto, so I have anticipated that this kind of questions would be in place.

Folks, especially regular contributors:

Are they are any volunteers willing to setup a Debian 6 machine and build Poky / Yocto to determine if we have any problems. Since we
will release 1.0 right around the time that developers maybe be working on Debian 6, we want to ensure we have tested against it.

Please let me know

Thanks
Sau!

Hi,
recently (from this week), I continuously meet build error (x86 and arm).

Seems it's a kind of lock problem, eg: complaining that No such file or directory: {POKYBASE}/build-arm/tmp/sysroots/package-output.lock. (not limiting to this, I run into at least four times). Detailed log is pasted below. After re-compile, the problem will be gone. But if you continues, you might meet it again in the future...

Raised it here in case it is a potential problem.

Thanks& Regards,
criping


{POKYBASE}/build-arm/tmp/work/armv5te-poky-linux-gnueabi/libfm-0.1.14-r1/temp/log.do_package.19852

the following files were installed but not shipped in any package:
NOTE: the following files were installed but not shipped in any package:
/usr/lib/gio/modules/libgiofm.a
NOTE: /usr/lib/gio/modules/libgiofm.a
/usr/lib/gio/modules/libgiofm.la
NOTE: /usr/lib/gio/modules/libgiofm.la
/usr/lib/gio/modules/libgiofm.so
NOTE: /usr/lib/gio/modules/libgiofm.so
/usr/lib/gio/modules/.debug/libgiofm.so
NOTE: /usr/lib/gio/modules/.debug/libgiofm.so
/usr/share/mime/packages/libfm.xml
NOTE: /usr/share/mime/packages/libfm.xml
Multiple libraries (libfm.so.0, libfm-gtk.so.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libfm.so.0, libfm-gtk.so.0) found and LEAD_SONAME not defined Error executing a python function in /media/poky/new.git/meta/recipes-support/libfm/libfm_0.1.14.bb:
OSError: [Errno 2] No such file or directory: '/media/poky/new.git/build-arm/tmp/sysroots/package-output.lock'

ERROR: Error executing a python function in /media/poky/new.git/meta/recipes-support/libfm/libfm_0.1.14.bb:
OSError: [Errno 2] No such file or directory: '/media/poky/new.git/build-arm/tmp/sysroots/package-output.lock'

The stack trace of python calls that resulted in this exception/failure was:
ERROR: The stack trace of python calls that resulted in this exception/failure was:
File "emit_pkgdata", line 79, in <module>
ERROR: File "emit_pkgdata", line 79, in <module>

ERROR:
File "emit_pkgdata", line 76, in emit_pkgdata
ERROR: File "emit_pkgdata", line 76, in emit_pkgdata

ERROR:
File "/media/poky/new.git/bitbake/lib/bb/utils.py", line 452, in unlockfile
ERROR: File "/media/poky/new.git/bitbake/lib/bb/utils.py", line 452, in unlockfile
os.unlink(lf.name)
ERROR: os.unlink(lf.name)

ERROR:
The code that was being executed was:
ERROR: The code that was being executed was:
0075:
ERROR: 0075:
0076: bb.utils.unlockfile(lf)
ERROR: 0076: bb.utils.unlockfile(lf)
0077:
ERROR: 0077:
0078:
ERROR: 0078:
*** 0079:emit_pkgdata(d)
ERROR: *** 0079:emit_pkgdata(d)
0080:
ERROR: 0080:
(file: 'emit_pkgdata', lineno: 79, function: <module>)
ERROR: (file: 'emit_pkgdata', lineno: 79, function: <module>)
0072: if g or allow_empty == "1":
ERROR: 0072: if g or allow_empty == "1":
0073: packagedfile = pkgdatadir + '/runtime/%s.packaged' % pkg
ERROR: 0073: packagedfile = pkgdatadir + '/runtime/%s.packaged' % pkg
0074: file(packagedfile, 'w').close()
ERROR: 0074: file(packagedfile, 'w').close()
0075:
ERROR: 0075:
*** 0076: bb.utils.unlockfile(lf)
ERROR: *** 0076: bb.utils.unlockfile(lf)
0077:
ERROR: 0077:
0078:
ERROR: 0078:
0079:emit_pkgdata(d)
ERROR: 0079:emit_pkgdata(d)
0080:
ERROR: 0080:
(file: 'emit_pkgdata', lineno: 76, function: emit_pkgdata)
ERROR: (file: 'emit_pkgdata', lineno: 76, function: emit_pkgdata) Function 'emit_pkgdata' failed
ERROR: Function 'emit_pkgdata' failed

From: Chris Tapp
Sent: Wednesday, January 26, 2011 9:09 PM

I know this is probably a basic question, but I'm not having much luck !

I've built poky-image-minimal for atom-pc using the 0.9 Poky release.

This gives me an ext3 rootfs of over 80MB, which doesn't sound minimal
to me ;-)

This is a known issue in 0.9. the switch from ipk to rpm leaves some temporary files
in the final ext3 rootfs, which results the large size.

Can I reduce the size of the image, or is it expected to be this size?

I've tried changing

IMAGE_ROOTFS_SIZE_ext3 = "500000"

This configuration option only works when it exceeds the size of generated rootfs,
or else it will be changed implicitly to the actual size plus some extra buffer

in atom-pc.conf to another value, but this didn't make any
difference to the image that gets created (by re-running bitbake poky-
image-minimal after making the above change).

I've also tried using

ROOT_FLASH_SIZE = "64"

also without any luck.

Any help would be much appreciated !

I'd suggest you to use the master to see whether it works for you.

The alternative is to apply below commit to your 0.9 code:

commit 5e384038cbd5035377d61a1b77ad23ab69e0cac0
Author: Richard Purdie <richard.purdie@...>
Date: Wed Jan 5 18:56:47 2011 +0000

rootfs_rpm.bbclass: Remove temporary work files in install directory, saving work files in install directory, saving the manifests as logfiles into ${T}

Signed-off-by: Richard Purdie <richard.purdie@...>

diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 33abe96..2f7d691 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -202,8 +202,11 @@ EOF
# remove lock files
rm -f ${IMAGE_ROOTFS}${rpmlibdir}/__db.*

- # remove resolver files and manifests
- rm -f ${IMAGE_ROOTFS}/install/install.manifest
+ # Move manifests into the directory with the logs
+ mv ${IMAGE_ROOTFS}/install/*.manifest ${T}/
+
+ # Remove all remaining resolver files
+ rm -f ${IMAGE_ROOTFS}/install

log_check rootfs

Thanks
Kevin

On 01/25/2011 10:36 AM, Lorenzati, Marcelo wrote:

Hi all,

I wanted to know if it’s feasible to build Yocto with ulibc instead of
glibc and if someone have tried.

In a really constrained system could be the difference between selecting
RT Linux or another real time OS.

What size of an image are you hoping to achieve?


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel