[yocto] Intel Galleio Board SSH Minimal Poky Image
Greetings, What is the minimal image from the poky yocto recipes that has ssh enabled by default or is it just better to enable it in the core minimal image on system startup. Thanks, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Thud Kernel Configuration not Working
Greetings,
I was trying to build a kernel with these files in a new layer for no smp to be
enabled but have no
idea why it doesn't work. This is after looking at the kernel manual and it's
literally the same
files excluding the disabling of smp as the chosen option.
.cfg for kernel option is called smp.cfg and this the file's content:
#Disable SMP
CONFIG_SMP=n
This is my bbappend called linux-yocto-4.1.8.bbappend:
# Include kernel configuration fragment
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URL += "file://smp.cfg"
If anyone has ideas thanks in advance,
Nick
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto on OnBoard Intel Galileo Flash
Greetings All, What is the best way to put a image on the 8mb of Yocto onboard flash or is this not possible with the Yocto Project. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project Unassigned Bugs - Help Needed
On 2019-02-11 12:19 p.m., sjolley.yp...@gmail.com wrote: > All, > > > > The triage team meets weekly and does its best to handle the bugs reported > into the Bugzilla. The number of people attending that meeting has fallen, > as have the number of people available to help fix bugs. One of the things > we hear users report is they don't know how to help. We (the triage team) > are therefore going to start reporting out the currently 294 unassigned > bugs. > > > > We're hoping people may be able to spare some time now and again to help out > with these. > > > > Bugs are split into two types, "true bugs" where things don't work as they > should and "enhancements" which are features we'd want to add to the system. > > > > There are also roughly four different "priority" classes right now, "2.7", > "2.8", "2.99" and "Future", the more pressing/urgent issues being in "2.7" > and then "2.8". > > > > Please review this link and if a bug is something you would be able to help > with either take ownership of the bug, or send me > (stephen.k.jol...@intel.com <mailto:stephen.k.jol...@intel.com> ) an e-mail > with the bug number you would like and I will assign it to you (please make > sure you have a Bugzilla account). > > > > The list is at: > https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs > > > > Thanks, > > > > Stephen K. Jolley > > Yocto Project Program Manager > > INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 > > *Cell: (208) 244-4460 > > * Email: stephen.k.jol...@intel.com > > > > > Stephen, I would be glad to help fix them. As I've newer to Yocto internals is there a list of trivial bugs or not just to help me get my feet wet? Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Bitbake Recipe Failing
Greetings All,
I am wondering how to forget about package QA in the best way possible just to
get this basic hello world test package to build in a
new layer I created:
SUMMARY = "Simple Hello World Application"
DESCRIPTION = "A test application to demonstrate how to create a recipe \
by directly compiling C files with BitBake."
SECTION = "examples"
PRIORITY = "optional"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "\
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://hello-1.0.tgz"
S = "${WORKDIR}"
do_compile() {
${CC} -c helloprint.c
${CC} -c hello.c
${CC} -o hello hello.o helloprint.o
}
do_install() {
install -d ${D}${bindir}
install -m 0755 hello ${D}${bindir}
}
This the errors when I run it with bitbake -b recipe name in the layer's folder:
ERROR: hello-1.0-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary:
'/home/nick/poky/build/tmp/work/i586-poky-linux/hello/1.0-r0/packages-split/hello/usr/bin/hello'
[ldflags]
WARNING: hello-1.0-r0 do_package_qa: QA Issue: hello rdepends on glibc, but it
isn't a build dependency, missing glibc in DEPENDS or PACKAGECONFIG?
[build-deps]
ERROR: hello-1.0-r0 do_package_qa: QA run found fatal errors. Please consider
fixing them.
ERROR: hello-1.0-r0 do_package_qa: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/home/nick/poky/build/tmp/work/i586-poky-linux/hello/1.0-r0/temp/log.do_package_qa.29042
ERROR: Task (/home/nick/poky/build/layer/hello_1.0.bb:do_package_qa) failed
with exit code '1'
NOTE: Tasks Summary: Attempted 13 tasks of which 7 didn't need to be rerun and
1 failed.
Huge Thanks,
Nick
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Add Layer Issue
Greetings All, I am wondering why this error is occuring: yocto-layer: command not found as I already sourced into my build with oe-init script and therefore add wondering why it's not found. I checked the current developer manual and that should work cleanly. Thanks, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Help with Nano Recipe
Greetings All,
I am trying to get the below recipe to build:
SUMMARY = "Recipe to build the 'nano' editor"
PN = "nano"
PV = "2.2.6"
LICENSE="GPLv3"
SITE = "http://www.nano-editor.org/dist;
PV_MAJOR = "${@d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${@d.getVar('PV',d,1).split('.')[1]}"
LIC_FILES_CHKSUM =
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
SRC_URI = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/${PN}-${PV}.tar.gz"
SRC_URI[md5sum] = "03233ae480689a008eb98feb1b599807"
SRC_URI[sha256sum] = \
"be68e133b5e81df41873d32c517b3e5950770c00fc5f4dd23810cd635abce67a"
LIC_FILES_CHKSUM =
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949
python do_fetch() {
bb.plain("Downloading source tarball from ${SRC_URI} ...")
src_uri = (d.getVar('SRC_URI', True) or "").split()
if len(src_uri) == 0:
bb.fatal("Empty URI")
try:
fetcher = bb.fetch2.Fetch(src_uri, d)
fetcher.download()
except bb.fetch2.BBFetchException:
bb.fatal("Could not fetch source tarball.")
bb.plain("Download successful.")
}
addtask fetch before do_build
python do_unpack() {
bb.plain("Unpacking source tarball ...")
os.system("tar x -C ${WORKDIR} -f ${DL_DIR}/${P}.tar.gz")
bb.plain("Unpacked source tarball.")
}
addtask unpack before do_build after do_fetch
python do_configure() {
bb.plain("Configuring source package ...")
os.system("cd ${WORKDIR}/${P} && ./configure")
bb.plain("Configured source package.")
}
addtask configure before do_build after do_unpack
python do_compile() {
bb.plain("Compiling package...")
os.system("cd ${WORKDIR}/${P} && make")
bb.plain("Compiled package.")
}
addtask compile before do_build after do_configure
do_clean[nostamp] = "1"
do_clean() {
rm -rf ${WORKDIR}/${P}
rm -f ${TMPDIR}/stamps/*
}
addtask clean
And am working why this error is occuring:
ERROR: ParseError at /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb:15:
unparsed line: 'LIC_FILES_CHKSUM =
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949'
I looked through the logs already and it was reported but only changed the file
number seemed to change it. I am wondering if there is a better
solution or why that's a bad CHSUM variable according to bitbake.
Thanks,
Nick
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Size of Packages from bitbake build feature idea
Greetings All, I assume this is possibly already there or is in another tool used by most people here. However if not I was wondering if it's a good idea to add support for telling what packages use up the most space on the root filesystem before the build or even a good idea. Something like bitbake show package size can be very useful for trimming down your packages before the build is done or even before debugging storage requirements. It should also support telling what shared libraries are used by each package. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Send build information to Toaster
Hi all, A dumb question which I feel like I should be able to work out, but can't: how do I send build information to Toaster? I have setup Toaster in Analysis mode on one machine (with MySQL and Apache). I'd now like to forward build information from another machine which I am running bitbake builds on. How do I do that? I've read the documentation: http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html, but can't seem to find the answer there. Cheers, Nick Toaster User Manual - Yocto Project<http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html> www.yoctoproject.org Note For the latest version of this manual associated with this Yocto Project release, see the Toaster User Manual from the Yocto Project website. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Install mozroot-certdata package on a read only root file system
I have an established yocto build which I'm now trying to switch over to having a root file system (eg. EXTRA_IMAGE_FEATURES += "read-only-rootfs"). However I'm running into an issue with a recipe in the meta-mono layer: mozroot-certdata. I see the culprit is the pkg_postint script (http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mozroot-certdata/mozroot-certdata_1.0.0.bb) which needs to modify the root file system on first boot which the build system is correctly flagging as impossible with a read only root file system: ERROR: The following packages could not be configured offline and rootfs is read-only: ['mozroot-certdata'] My question is: is their a way to get these mozroot certs installed and configured with mono during the build process, such that the root file system does not need to be modified at boot/run time? Cheers, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Interested in Helping Out
On 2016-09-05 08:49 AM, Daniel. wrote: > https://bugzilla.yoctoproject.org/buglist.cgi?query_format=specific=relevance+desc_status=__open__== > :) > Thanks Daniel, I had some ideas for the naming issues currently being discussed as related to open embedded and the Yocto projects. If people are interested in my input I would be glad to share it. Nick > 2016-09-02 18:00 GMT-03:00 nick <xerofo...@gmail.com>: >> Greetings All, >> I am interested in helping out here. In addition I do have some experience >> with the project >> so just giving me a heads up on where to start or what is the current focus >> would be great. >> Nick >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Interested in Helping Out
Greetings All, I am interested in helping out here. In addition I do have some experience with the project so just giving me a heads up on where to start or what is the current focus would be great. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What version of Jethro do we get with - git clone -b jethro git://git.yoctoproject.org/poky.git ?
And list of tags can be found here: http://git.yoctoproject.org/cgit/cgit.cgi/poky/refs/tags Nick Pongratz Singlewire Software On Tue, May 3, 2016 at 10:32 AM, Christopher Larson <clar...@kergoth.com> wrote: > > On Tue, May 3, 2016 at 3:31 PM, Mark T <mtl1nux...@gmail.com> wrote: > >> Hi Christopher, >> >> Thanks. What is the command option to specify the tag and is there a list >> or tags available ? >> > > https://git-scm.com/book/en/v2 > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > > -- > ___ > 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] [Openembedded-architecture] Removing Hob for 2.1
On 2016-02-26 08:37 AM, Philip Balister wrote: > On 02/25/2016 09:49 PM, Paul Eggleton wrote: >> Hi folks, >> >> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) >> UI >> for some time now; Hob has basically been on life support for the past few >> releases. As of late last month in master, Toaster has the capability to > > Please remove Hob. > > I've heard that the Linux Foundation training still mentions Hob, I'll > double check that this content is removed and shifted to Toaster. > > Philip > >> select the packages in an image, removing the last thing that Hob could do >> that Toaster couldn't. This means it's about time we looked at removing Hob >> - >> particularly if we want to do so for the upcoming 2.1 release as we should >> really do so within the M3 development timeframe which is almost over. >> >> To recap, the reasons why Hob ought to be removed include: >> >> - The code is tightly woven into BitBake, making it fragile. This means it >> needs significant QA and maintenance on an ongoing basis. >> >> - Some of the implementation is not ideal; we'll be able to remove some >> cruft >> from BitBake and OE-Core at the same time. >> >> - It's GTK+ 2 based, not the current GTK+ 3. >> >> - Toaster is now a much more capable UI and is being actively maintained >> >> I'm maintaining a list of things we would drop together with Hob, so I could >> probably come up with a patchset - I just wanted to give people a heads up >> and >> double check that this is something we indeed want to do in 2.1. Any >> comments? >> I haven't been using the last few versions of Yocto, last I used was 1.8 I believe unless we just jumped to 2.0/2.1. I was wondering for people somewhat used to using HOB for easier distribution build tuning how big is the learning curve(I assume it isn't much). Further more can Toaster be configured to make iso/vmware images as I find this very useful plus from what I known Toaster needs to be run with a browser can it be made to run as a non browser based service similar to Hob if not already done so. Just my thoughts, Nick P.S. Sorry if anybody gets a second email as I was not subscribed to openembedded architecture. >> Cheers, >> Paul >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] Removing Hob for 2.1
On 2016-02-26 08:37 AM, Philip Balister wrote: > On 02/25/2016 09:49 PM, Paul Eggleton wrote: >> Hi folks, >> >> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) >> UI >> for some time now; Hob has basically been on life support for the past few >> releases. As of late last month in master, Toaster has the capability to > > Please remove Hob. > > I've heard that the Linux Foundation training still mentions Hob, I'll > double check that this content is removed and shifted to Toaster. > > Philip > >> select the packages in an image, removing the last thing that Hob could do >> that Toaster couldn't. This means it's about time we looked at removing Hob >> - >> particularly if we want to do so for the upcoming 2.1 release as we should >> really do so within the M3 development timeframe which is almost over. >> >> To recap, the reasons why Hob ought to be removed include: >> >> - The code is tightly woven into BitBake, making it fragile. This means it >> needs significant QA and maintenance on an ongoing basis. >> >> - Some of the implementation is not ideal; we'll be able to remove some >> cruft >> from BitBake and OE-Core at the same time. >> >> - It's GTK+ 2 based, not the current GTK+ 3. >> >> - Toaster is now a much more capable UI and is being actively maintained >> >> I'm maintaining a list of things we would drop together with Hob, so I could >> probably come up with a patchset - I just wanted to give people a heads up >> and >> double check that this is something we indeed want to do in 2.1. Any >> comments? >> I haven't been using the last few versions of Yocto, last I used was 1.8 I believe unless we just jumped to 2.0/2.1. I was wondering for people somewhat used to using HOB for easier distribution build tuning how big is the learning curve(I assume it isn't much). Further more can Toaster be configured to make iso/vmware images as I find this very useful plus from what I known Toaster needs to be run with a browser can it be made to run as a non browser based service similar to Hob if not already done so. Just my thoughts, Nick >> Cheers, >> Paul >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dropping Debian 7 as supported?
On Thursday 11 Feb 2016 14:32:50 Burton, Ross wrote:
> On 11 February 2016 at 14:21, Nick Leverton <n...@leverton.org> wrote:
> > Possibly a little early - Debian 7 will be going onto LTS security support
> > for
> > two years, starting some time this month. Quoting from
> > https://wiki.debian.org/LTS
>
> Ah yes, I'd forgotten about the LTS project and was looking at the security
> team.
>
> This does make it less clear, but it's still an old release and we can't
> support/test on everything.
I agree it appears old by the standards of fast moving bleeding edge distros.
But despite what I said last week it's not really that ancient. Debian 7 is
still an officially supported version, and as an LTS version you're perhaps now
more likely to find your own users still on it.
The LTS announcement was made just this weekend, by the way:
"There will be no further security support for Debian 6.0.
The LTS Team will prepare the transition to Debian 7 ("wheezy"), which
is the current oldstable release. The LTS team will take over support
from the Security Team on April 26, 2016.
Debian 7 will also receive Long Term Support for five years after its
initial release with support ending in May 2018"
I can't say what Yocto ought to do, but if it were possible to make the sparse
support into an option, would that be a compromise ? The patch linked from
#9099 suggests that only two places would need to use that option.
Nick
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dropping Debian 7 as supported?
On Thursday 11 Feb 2016 14:32:50 Burton, Ross wrote: > On 11 February 2016 at 14:21, Nick Leverton <n...@leverton.org> wrote: > > Possibly a little early - Debian 7 will be going onto LTS security support > > for > > two years, starting some time this month. Quoting from > > https://wiki.debian.org/LTS > > Ah yes, I'd forgotten about the LTS project and was looking at the security > team. > > This does make it less clear, but it's still an old release and we can't > support/test on everything. I appreciate that, and I suspect the LTS efforts are of most interest to those running production servers. I would think anyone developing on Debian is likely to be running stable at least. Although I've worked at many development companies running elderly LTS versions of Ubuntu, Fedora/Centos, etc, I admit I've yet to meet one that ran Debian at all. Nevertheless if I can be of any help in supporting and testing on versions of Debian, I'm happy to do so. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dropping Debian 7 as supported?
On Thursday 11 Feb 2016 14:11:36 Burton, Ross wrote: > Hi, > > I'm proposing that we drop Debian 7 from the supported distributions list > in master, so that the 2.1 release supports Debian 8. Debian 7 was > released in 2013, Debian 8 superceded it in April 2015 so will have been > out for a year when 2.1 is released, which also means that is when Debian 7 > stops receiving security fixes. Nobody should be running Debian 7 after > April 2016! > > Any objections? Possibly a little early - Debian 7 will be going onto LTS security support for two years, starting some time this month. Quoting from https://wiki.debian.org/LTS "Debian 6 “Squeeze” until February 2016 Debian 7 “Wheezy” from February 2016 to May 2018 Debian 8 “Jessie“ from May 2018 to April/May 2020" Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem Booting Yocto 1.7.3
On 2015-11-17 07:37 PM, Clay D. Montgomery wrote: > Hello, > >I'm trying to update from Yocto (Dizzy) 1.7.2 to 1.7.3 for a Wandboard > Quad, but it hangs at the point where u-boot is trying to start the kernel. > I'm guessing maybe this is because my image has u-boot 2014 and I need u-boot > 2015? I have read that u-boot 2015 is required for Yocto 1.8 (Fido), because > it has a newer kernel (3.14). But, my Yocto 1.7.3 build is still the 3.10.17 > kernel. Is it possible Bitbake built this image with u-boot and kernel > versions that are not compatible, or am I missing the real issue? > > I am pasting my boot log below, up to the point where it hangs. I would > really appreciate any help. > > Thanks, Clay Montgomery > > > U-Boot 2014.10+fslc+g5fd0b60 (Nov 14 2015 - 17:25:56) > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > Reset cause: POR > Board: Wandboard > I2C: ready > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > auto-detected panel HDMI > Display: HDMI (1024x768) > In:serial > Out: serial > Err: serial > Net: FEC [PRIME] > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > reading boot.scr > ** Unable to read file boot.scr ** This looks highly suspect to me. > reading zImage > 5442368 bytes read in 359 ms (14.5 MiB/s) > Booting from mmc ... > reading imx6q-wandboard.dtb > 43370 bytes read in 21 ms (2 MiB/s) > Kernel image @ 0x1200 [ 0x00 - 0x530b40 ] > ## Flattened Device Tree blob at 1800 >Booting using the fdt blob at 0x1800 >Using Device Tree in place at 1800, end 1800d969 > > Starting kernel ... Also try using early printk in kernel and see if you actually reach the kernel initialization routines I am not sure if ARM supported early printk but it should for printing before serial console is completely initialized. This would allow me/you to see if the kernel actually starts and whether u-boot or the kernel itself is the issue. Cheers, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 1.9 now available.
On 2015-08-05 10:45 AM, Flanagan, Elizabeth wrote: The first milestone release for Yocto Project 1.9 is available for download now. http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.9_M1/ Thank you everyone for your contributions. eclipse-poky/juno-master bbd410e2c5db9532ea373ec993c5e8d9 eclipse-poky/kepler-master 989ee9bda9c0d5c05e790a289d4ca032 eclipse-poky/luna-master fe928773cf7b952c368769fdc4be3688 meta-qt3 139394eca6575b9ab31d2f79f7830f2a poky 59713c69884b4d459b0712133ba56034 Test report at https://wiki.yoctoproject.org/wiki/WW28_-_2015-07-10_-_Full_Pass_1.9_M1.rc2 Just a question about your testing Elizabeth. BB_NUMBER_THREADS = 8 PARALLEL_MAKE = -j 8 MACHINE = qemux86 It should be 2 times the number of cores for parallel build systems like make or bitbake. Why only eight as I do eight on my i5 from the same generation. This seems like a error in my opinion. Cheers, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto linux-kernel
On 2015-04-29 09:20 AM, Bruce Ashfield wrote: On 04/29/2015 08:38 AM, Parthiban Kandasamy wrote: i am using beagleboard-xm like board for my custom use. for my development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded). while bitbaking kernel, i got error as follows: Log data follows: | DEBUG: Executing shell function do_kernel_checkout | Reinitialized existing Git repository in /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/ | On branch standard/base | nothing to commit, working directory clean | ERROR. The branch 'meta' is required and was not | found. Ensure that the SRC_URI points to a valid linux-yocto | kernel repository | WARNING: /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1 exit 1 from | exit 1 | ERROR: Function failed: do_kernel_checkout (log file is located at /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588) due to this error i thought error can be cleared if kernel fetched from yocto git repository, but i cat get from there, so how do i get kernel-2.6.32 for yocto project. There isn't a released 2.6.32 linux-yocto version, so if you really want that old version, you'd need to create a linux-yocto-custom recipe for the version (unless that is what you already did). Bruce -- thanks and regards, parthiban +919790329795 The only reason to use such a old kernel is for one of two reasons in my experience either it's on custom hardware and written by a vendor supporting that hardware or people want to run a long term supported kernel. I am wondering of the two which one are you under Parthiban. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Openembedded/yocto bitbake with gcc 4.8.2 crashes at do_compile elfutils
On Mon, Mar 9, 2015 at 4:35 AM, Everhard Ros everhard@outlook.com wrote: Hello guys, I'm trying to run bitbake to get a linux image on an altera Cyclone 5 devboard(SoCrates). The end goal is to get a linux image that has the OpenCV library installed. I'm using the altera version of the yocto project. Currently everything is running fairly well on ubuntu 12.04. When I try to run this bitbake process on CentOS 7, I get the following error: Error: argument to 'sizeof' in 'snprintf' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] cc1: all warnings being treated as errors After some googling here and there, I kind of found the 'bug'.(new gcc has this new flag that older versions didn't have which causes a warning and an error with -wall). So now I'm looking for the place where flags are passed to the gcc compiler: I tried doing this in the bitbake.conf file in the meta -layer; TOOLCHAIN_OPTIONS, BUILD_CFLAGS and TARGET_CFLAGS are now empty. In the manual they mention these flags are being sent to the compiler. I also checked out the elfutils and gcc folders in yocto/meta/devtools/, but couldn't find anything relevant there (I used find/grep and the GUI, searching for the flags mentioned) Changing the flags in the bitbake.conf file didn't help; do you guys happen to have any idea where the compiler flags are being set when bitbake executes the do_compile task for elfutils? Thank you in advance. cheers! P.S: This is a cross-post from this thread I made at linuxquestions.org -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Did you look for the bb recipe file for elfutils as I am pretty certain that you can put your gcc compiler flags to work around this issue inside that particular bitbake recipe file. Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, Feb. 10, 2015 8:00 AM US Pacific Time
On 2015-02-09 08:15 PM, Jolley, Stephen K wrote: Tuesday, February 10, 2015 8:00 AM US Pacific Time Agenda: * Opens collection - 5 min (Stephen) * Yocto Project status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.8_Status https://wiki.yoctoproject.org/wiki/Yocto_1.8_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.8_Features * SWAT team rotation: Ross - Cristian https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team * Opens - 10 min * Team Sharing - 10 min We encourage people attending the meeting to logon the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference Details: Company: WIND RIVER SYS Ready-Access Number: 8007302996/9139049836 Access Code: 2705751 For International numbers see: https://www.yoctoproject.org/tools-resources/community/weekly-technical-call Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com Greetings All, I can't IRC tomorrow for the meeting as I am at school :(. Would someone either email me the major points of the meeting or think of some way to allow me to known what happened during the meeting. Thanks, Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Booting .hddimg from USB failed - ramdisk not found /dev/ram0 - HELP!
Simon,
Your right is this probably an issue with your boot partition config.
Regards Nick
On 2015-01-09 04:20 AM, Simon Bolek wrote:
Hi Nick, attached is my kernel .bbappend and .cfg files of linux kernel
recipe of my own layer. In original meta layer nothing was changed.
However, I spent last night trying to resolve the problem and found out
that standard core-sato-image was missing
meta/recipes-core/initrdscripts
I added that to the local.conf file and also added grub to it.
I wonder how 'install' was possible without those scripts, well, never mind.
After building .hddimg again i was able to boot and install the image from
USB device to atom-pc. Installation seemed to work without problems BUT
after removing the usb device, boot FAILED: *not bootable device* - I was
crying out loud, belive me!, gave up and went directly to bed...
The same(built and generated at the same bitbake run) iso image is working
in virtual box like a charm.
There must be a difference/bug somewhere.
Vbox is creating partitions on hda, atom-pc has sda. Should not be a
problem, but still a difference.
Could you help me on that? There are 3 Partitions on /dev/sda:
/dev/sda1 - boot partition (no asterix in partition table visible, but no
asterix on Vbox partition table as well)
/dev/sda2 - rootfs
/dev/sda3 - swap
However, I will open another thread for this.
thank you and best regards
simon:-)
On Fri, Jan 9, 2015 at 3:17 AM, nick xerofo...@gmail.com wrote:
Simon,
Please send me your kernel bb recipes as there is probably an issue in
them.
Regards,
Nick
On 2015-01-08 03:58 PM, Simon Bolek wrote:
NIck, thank you. what do you mean by that? I followed the instructions
from
here:
http://www.yoctoproject.org/docs/1.7/kernel-dev/kernel-dev.html#changing-the-configuration
is there something there I might be missing? Where is the part, 'linking
your kernels to the core-image-sato build' that you are talking about?
thank you and best regards
simon:-)
On Thu, Jan 8, 2015 at 6:50 PM, nick xerofo...@gmail.com wrote:
Simon,
Why are you not linking your kernels to the core-image-sato build.
This seems to be the issue.
Regards Nick
On 2015-01-08 05:59 AM, Simon Bolek wrote:
Thank you Nick. I will try that, but this is not the point. I am trying
to
figure out why
*bitbake core-image-sato *
does not create /dev/ram nodes, although linux-yocto has them defiined
in
.config file.
I also created:
mylayer/recipes-kernel/linux/linux_yocto_3.4.bbapend
mylayer/recipes-kernel/linux/linux_yocto_3.10.bbapend
mylayer/recipes-kernel/linux/linux_yocto_3.14.bbapend
with the following content:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://ramdisk.cfg
and
mylayer/recipes-kernel/linux/files/ramdisk.cfg
with content:
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
and afterwards run the commands:
bitbake linux-yocto -c cleansstate
bitbake linux-yocto
bitbake core-image-sato
again. Same result, no /dev/ram nodes under rootfs.
What am i doing wrong?
thank you
simon:-)
On Thu, Jan 8, 2015 at 2:03 AM, nick xerofo...@gmail.com wrote:
Simon,
Can you boot this on standard computer with qemu.
Try that first and report back if that works.
Nick
On 2015-01-07 04:59 PM, Simon Bolek wrote:
Hello folks!
I have the following problem/question.
1) I built a standard .hddimg core-image-sato genericx86 on ubuntu
14.10
2) Afterwards, this .hddimg was deployed to USB device (USB-ZIP
method)
3) Tried to boot Atom PC from the USB Device - *ERROR: cound not
found
ramdisk*
so initrd is trying to find /dev/ram0 which does not exist in the
image.
I
checked rootfs and there is nothing under
../poky/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/rootfs/dev
I googled this up and there is a thread telling to check the .config
file
for *CONFIG_BLK_DEV_RAM *settings*.*
I have the following entries in:
../poky/build/tmp/work/genericx86-poky-linux/linux-yocto/3.10.35+gitAUTOINC+7df9ef8ee4_2ee37bfe73-r0/linux-genericx86-standard-build/.config
...
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
...
I also *bitbake core-image-sato -c cleansstate* twice already.
I also* bitbake core-image-sato -c menuconfig *once more and
afterwards *bitbake
linux-yocto* again.
I also tried IRC channels, but no answer so far...
Can anyone help me? How can i force bitbake to create /dev/ram0 under
rootfs?
Or maybe there is another trick to boot the image from USB?
best regards
simon:-)
Viele Grüsse
Simon Bolek
mit freundlichem Gruss / best regards / pozdrawiam / atentamente
Simon P. Bolek
--
Dipl. Inf. Simon P. Bolek
SAP Consultant
Business Mobile and IVI Solutions
mailto: simon.bo...@arcom-ivi.de
http://www.arcom-ivi.de/
XING: https://www.xing.com/profile/SimonP_Bolek
Re: [yocto] Booting .hddimg from USB failed - ramdisk not found /dev/ram0 - HELP!
Simon,
Please send me your kernel bb recipes as there is probably an issue in
them.
Regards,
Nick
On 2015-01-08 03:58 PM, Simon Bolek wrote:
NIck, thank you. what do you mean by that? I followed the instructions from
here:
http://www.yoctoproject.org/docs/1.7/kernel-dev/kernel-dev.html#changing-the-configuration
is there something there I might be missing? Where is the part, 'linking
your kernels to the core-image-sato build' that you are talking about?
thank you and best regards
simon:-)
On Thu, Jan 8, 2015 at 6:50 PM, nick xerofo...@gmail.com wrote:
Simon,
Why are you not linking your kernels to the core-image-sato build.
This seems to be the issue.
Regards Nick
On 2015-01-08 05:59 AM, Simon Bolek wrote:
Thank you Nick. I will try that, but this is not the point. I am trying
to
figure out why
*bitbake core-image-sato *
does not create /dev/ram nodes, although linux-yocto has them defiined in
.config file.
I also created:
mylayer/recipes-kernel/linux/linux_yocto_3.4.bbapend
mylayer/recipes-kernel/linux/linux_yocto_3.10.bbapend
mylayer/recipes-kernel/linux/linux_yocto_3.14.bbapend
with the following content:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://ramdisk.cfg
and
mylayer/recipes-kernel/linux/files/ramdisk.cfg
with content:
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
and afterwards run the commands:
bitbake linux-yocto -c cleansstate
bitbake linux-yocto
bitbake core-image-sato
again. Same result, no /dev/ram nodes under rootfs.
What am i doing wrong?
thank you
simon:-)
On Thu, Jan 8, 2015 at 2:03 AM, nick xerofo...@gmail.com wrote:
Simon,
Can you boot this on standard computer with qemu.
Try that first and report back if that works.
Nick
On 2015-01-07 04:59 PM, Simon Bolek wrote:
Hello folks!
I have the following problem/question.
1) I built a standard .hddimg core-image-sato genericx86 on ubuntu
14.10
2) Afterwards, this .hddimg was deployed to USB device (USB-ZIP method)
3) Tried to boot Atom PC from the USB Device - *ERROR: cound not found
ramdisk*
so initrd is trying to find /dev/ram0 which does not exist in the
image.
I
checked rootfs and there is nothing under
../poky/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/rootfs/dev
I googled this up and there is a thread telling to check the .config
file
for *CONFIG_BLK_DEV_RAM *settings*.*
I have the following entries in:
../poky/build/tmp/work/genericx86-poky-linux/linux-yocto/3.10.35+gitAUTOINC+7df9ef8ee4_2ee37bfe73-r0/linux-genericx86-standard-build/.config
...
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
...
I also *bitbake core-image-sato -c cleansstate* twice already.
I also* bitbake core-image-sato -c menuconfig *once more and
afterwards *bitbake
linux-yocto* again.
I also tried IRC channels, but no answer so far...
Can anyone help me? How can i force bitbake to create /dev/ram0 under
rootfs?
Or maybe there is another trick to boot the image from USB?
best regards
simon:-)
Viele Grüsse
Simon Bolek
mit freundlichem Gruss / best regards / pozdrawiam / atentamente
Simon P. Bolek
--
Dipl. Inf. Simon P. Bolek
SAP Consultant
Business Mobile and IVI Solutions
mailto: simon.bo...@arcom-ivi.de
http://www.arcom-ivi.de/
XING: https://www.xing.com/profile/SimonP_Bolek
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Booting .hddimg from USB failed - ramdisk not found /dev/ram0 - HELP!
Simon,
Why are you not linking your kernels to the core-image-sato build.
This seems to be the issue.
Regards Nick
On 2015-01-08 05:59 AM, Simon Bolek wrote:
Thank you Nick. I will try that, but this is not the point. I am trying to
figure out why
*bitbake core-image-sato *
does not create /dev/ram nodes, although linux-yocto has them defiined in
.config file.
I also created:
mylayer/recipes-kernel/linux/linux_yocto_3.4.bbapend
mylayer/recipes-kernel/linux/linux_yocto_3.10.bbapend
mylayer/recipes-kernel/linux/linux_yocto_3.14.bbapend
with the following content:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://ramdisk.cfg
and
mylayer/recipes-kernel/linux/files/ramdisk.cfg
with content:
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
and afterwards run the commands:
bitbake linux-yocto -c cleansstate
bitbake linux-yocto
bitbake core-image-sato
again. Same result, no /dev/ram nodes under rootfs.
What am i doing wrong?
thank you
simon:-)
On Thu, Jan 8, 2015 at 2:03 AM, nick xerofo...@gmail.com wrote:
Simon,
Can you boot this on standard computer with qemu.
Try that first and report back if that works.
Nick
On 2015-01-07 04:59 PM, Simon Bolek wrote:
Hello folks!
I have the following problem/question.
1) I built a standard .hddimg core-image-sato genericx86 on ubuntu 14.10
2) Afterwards, this .hddimg was deployed to USB device (USB-ZIP method)
3) Tried to boot Atom PC from the USB Device - *ERROR: cound not found
ramdisk*
so initrd is trying to find /dev/ram0 which does not exist in the image.
I
checked rootfs and there is nothing under
../poky/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/rootfs/dev
I googled this up and there is a thread telling to check the .config file
for *CONFIG_BLK_DEV_RAM *settings*.*
I have the following entries in:
../poky/build/tmp/work/genericx86-poky-linux/linux-yocto/3.10.35+gitAUTOINC+7df9ef8ee4_2ee37bfe73-r0/linux-genericx86-standard-build/.config
...
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
...
I also *bitbake core-image-sato -c cleansstate* twice already.
I also* bitbake core-image-sato -c menuconfig *once more and
afterwards *bitbake
linux-yocto* again.
I also tried IRC channels, but no answer so far...
Can anyone help me? How can i force bitbake to create /dev/ram0 under
rootfs?
Or maybe there is another trick to boot the image from USB?
best regards
simon:-)
Viele Grüsse
Simon Bolek
mit freundlichem Gruss / best regards / pozdrawiam / atentamente
Simon P. Bolek
--
Dipl. Inf. Simon P. Bolek
SAP Consultant
Business Mobile and IVI Solutions
mailto: simon.bo...@arcom-ivi.de
http://www.arcom-ivi.de/
XING: https://www.xing.com/profile/SimonP_Bolek
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Distro vs. Image
Schwab, You asked about an building an installable image, if you have Hob there is a way. https://www.yoctoproject.org/documentation/hob-manual-16#run-deploy This is a link to the page explaining it, scroll down to the section on deploying or running your image and it should explain how to do it. Cheers Nick On 2014-12-28 09:23 PM, ChenQi wrote: Hi Schwab, What do you mean by distro recipe? I can see your initial problem is that you want different config details for the same image recipe (maybe for different HW, I guess?). Now we would like to create an installer image, i.e. a bootable image whose job is to install a release(-candidate) image to the HW. Naturally, some config details in the resulting image will be different. Can this be done via bbappend file in different layers? Can this be done via different distro config files? Regards, Chen Qi On 12/23/2014 11:09 AM, Leo Schwab wrote: Up to this point, all our builds for our prototypes have been image builds, i.e. we built an image recipe starting with packagegroup-core-boot, and it's accreted from there. We write the resulting .sdcard image file to an SD card and boot from that. Now we would like to create an installer image, i.e. a bootable image whose job is to install a release(-candidate) image to the HW. Naturally, some config details in the resulting image will be different. The more I read, it feels like this wants to be a distro, rather than just another image recipe. Recipes searching for files will automagically generate subdirectory search paths based on current distro name, which would allow us to substitute different config files based on what's being built. (Extra Credit for this build would be to incorporate a copy of the release image into the installer image.) Trouble is, none of the docs I've read describe very clearly how to make the leap from cobbling image recipes together to creating a functionally equivalent distro recipe. Could someone point out some resources and examples on how this is meant to be conceptualized and used? Thanks in advance for all suggestions. Schwab -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build Server Questions?
Boris, I am thinking of at least 32 cores or 2 e5 xeons and 64 GB of ram. Is this enough or should I accept for even more CPU cores? Nick On 2014-12-22 03:07 PM, Burton, Ross wrote: On 22 December 2014 at 18:41, nick xerofo...@gmail.com wrote: I am wondering if a build server is a good idea for Yocto Builds. In addition what specs are good for a build server if I am to purchase one. Further more I am assuming as many cores as possible for making the build be parallel and faster. I was also thinking as much ram as possible too, 64 GB as a minimum. This has been discussed repeatedly on this list, but the rule of thumb is a well-rounded server: as much of everything as possible, and don't bother with SSDs. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build Server Questions?
Greetings Yocto Devolopers, I am wondering if a build server is a good idea for Yocto Builds. In addition what specs are good for a build server if I am to purchase one. Further more I am assuming as many cores as possible for making the build be parallel and faster. I was also thinking as much ram as possible too, 64 GB as a minimum. If there are any other ideas on specs for a build server that would be greatly appreciated. Regards Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer Priority with Wildcard .bbappend Files
Hi Paul, I verified this by building an image - the sysctl.conf that ends up in the final image is the one from meta-bsp, not the one from meta-custom. But if I switch the name of base-files_%.bbappend in meta-custom to base-files_3.0.14.bbappend, this is what I get: # $FILESEXTRAPATHS [5 operations] # set poky/meta/conf/documentation.conf:172 # [doc] Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append files. # _prepend meta-bsp/recipes-core/base-files/base-files_3.0.14.bbappend:3 # meta-bsp/recipes-core/base-files/base-files: # _prepend meta-custom/recipes-core/base-files/base-files_3.0.14.bbappend:6 # meta-custom/recipes-core/base-files/base-files: # set data_smart.py:432 [finalize] # meta-bsp/recipes-core/base-files/base-files: # set data_smart.py:432 [finalize] # meta-custom/recipes-core/base-files/base-files:meta-bsp/recipes- cor e/base-files/base-files: # computed: # meta-custom/recipes-core/base-files/base-files:meta-bsp/recipes- cor e/base-files/base-files: FILESEXTRAPATHS=meta-custom/recipes-core/base-files/base- files:meta -bsp/recipes-core/base-files/base-files: And now the sysctl.conf file is being pulled from meta-custom. That absolutely should not happen. If you change it back does it revert to the version from meta-bsp? The wildcarding should not change the order in which the files are applied. The only corner case I can think of would be if the layer priority values are the same number - this isn't the case is it? The behavior does reappear if I change the file name back to a wildcard. And no, the layers are different priorities - meta-custom is priority 8 and meta-bsp is priority 6. Definitely sounds like there's some unexpected behavior here. I am going to dig in some more and see if I can find a limited test case that reproduces the issue, and then I'll get a bug report opened. Thanks! Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Layer Priority with Wildcard .bbappend Files
I think I've encountered a bug with how multiple bbappend files are processed
when one of the bbappends contains a filename wildcard, but I want to make sure
there's not something I'm missing before filing a bug report.
I have a BSP layer and a customization layer that are based on the OE/poky
Daisy release. The output of `bitbake-layers show-layers` looks like:
layer path priority
=
meta poky/meta5
meta-yoctopoky/meta-yocto 5
meta-yocto-bsppoky/meta-yocto-bsp 5
...ellided...
meta-bsp meta-bsp 6
meta-custom meta-custom 8
In meta-bsp there is a bbappend for base-files named
base-files_3.0.14.bbappend. The meta-bsp bbappend adds a sysctl.conf to /etc -
pretty straightforward:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
SRC_URI += file://sysctl.conf
do_install_append() {
install -m 0644 ${WORKDIR}/sysctl.conf ${D}${sysconfdir}/
}
Now what I want to do is add a file called base-files_%.bbappend to
meta-custom. It has its own version of sysctl.conf, and the recipe looks like
this:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
Here's where things get weird. If I run `bitbake -e base-files` and pull out
the section for FILESEXTRAPATHS, this is what I get (note that I've stripped
out the huge absolute paths to make this easier to read):
# $FILESEXTRAPATHS [5 operations]
# set poky/meta/conf/documentation.conf:172
# [doc] Extends the search path the OpenEmbedded build system uses
when looking for files and patches as it processes recipes and append files.
# _prepend meta-custom/recipes-core/base-files/base-files_%.bbappend:6
# meta-custom/recipes-core/base-files/base-files:
# _prepend meta-bsp/recipes-core/base-files/base-files_3.0.14.bbappend:3
# meta-bsp/recipes-core/base-files/base-files:
# set data_smart.py:432 [finalize]
# meta-custom/recipes-core/base-files/base-files:
# set data_smart.py:432 [finalize]
#
meta-bsp/recipes-core/base-files/base-files:meta-custom/recipes-core/base-files/base-files:
# computed:
#
meta-bsp/recipes-core/base-files/base-files:meta-custom/recipes-core/base-files/base-files:
FILESEXTRAPATHS=meta-bsp/recipes-core/base-files/base-files:meta-custom/recipes-core/base-files/base-files:
For some reason meta-bsp is coming before meta-custom in FILESEXTRAPATHS, even
though meta-custom has a higher priority! I verified this by building an image
- the sysctl.conf that ends up in the final image is the one from meta-bsp, not
the one from meta-custom. But if I switch the name of base-files_%.bbappend in
meta-custom to base-files_3.0.14.bbappend, this is what I get:
# $FILESEXTRAPATHS [5 operations]
# set poky/meta/conf/documentation.conf:172
# [doc] Extends the search path the OpenEmbedded build system uses
when looking for files and patches as it processes recipes and append files.
# _prepend meta-bsp/recipes-core/base-files/base-files_3.0.14.bbappend:3
# meta-bsp/recipes-core/base-files/base-files:
# _prepend
meta-custom/recipes-core/base-files/base-files_3.0.14.bbappend:6
# meta-custom/recipes-core/base-files/base-files:
# set data_smart.py:432 [finalize]
# meta-bsp/recipes-core/base-files/base-files:
# set data_smart.py:432 [finalize]
#
meta-custom/recipes-core/base-files/base-files:meta-bsp/recipes-core/base-files/base-files:
# computed:
#
meta-custom/recipes-core/base-files/base-files:meta-bsp/recipes-core/base-files/base-files:
FILESEXTRAPATHS=meta-custom/recipes-core/base-files/base-files:meta-bsp/recipes-core/base-files/base-files:
And now the sysctl.conf file is being pulled from meta-custom.
Is there something I'm missing, like some sort of decreased priorty for
bbappend files with a wildcard? Or is this a bug?
Thanks for any help!
Nick Stevens
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't find the header files after install adt_installer.tar.gz
Have you read the yocto docs on ADT for building correctly your development kit, seems to me rather trivial error in either your build or bitbake recipe for hello world. Cheers Nick On Thu, Nov 13, 2014 at 4:43 AM, neil...@emerson.com wrote: Hi all : I have installed the adt_installer .tar.gz like fllowing: $ cd ~ $ tar -xjf adt_installer.tar.bz2 $ cd adt-installer $ ./adt_installer Because the YOCTOADT_TARGET_SYSROOT_LOC_arm=$HOME/test-yocto/$YOCTOADT_TARGET_MACHINE_arm in adt_installer.conf file , then I extract the myself Root Filesystem: $source /opt/poky/1.7/environment-setup-i586-poky-linux $ runqemu-extract-sdk ~/Downloads/core-image-arm-rootfs.tar.bz2 $HOME/ test-yocto/ qemuarm/ Try to compile the “Helloworld”, it apper this error: hello.c:1:19: fatal error: stdio.h: No such file or directory Do you know how to resolve the issue? Please help me ! Thank you very much! -- ___ 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] Making Hob better.
On Wed, Nov 12, 2014 at 4:00 PM, John Unland opensourcejohn2...@gmail.com wrote: I'm not sure a separate bootloaders layer would really make sense - we normally keep bootloaders either in OE-Core... Are there bootloader(s) that you are looking for that are currently missing? Well I know I like to use U-Boot since it can go across multiple archs. Well I guess it makes since to just have it in OE-Core. Other than that that's what I wanted was U-Boot for x86 mostlyBut if It's in OE-Core then there's no need to abstract that out to a different layer I guess. Thanks. John On Wed, Nov 12, 2014 at 11:33 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Hi John, On Tuesday 11 November 2014 11:51:23 John Unland wrote: What about bootloaders? Where would I file a enhancement for different boot loaders (U-Boot, Lilo, etc.). Would be good if we had a boot loaders layer. I'm not sure a separate bootloaders layer would really make sense - we normally keep bootloaders either in OE-Core (where we currently have u-boot, grub, grub-efi, syslinux, gummiboot, etc.) or in specific BSPs where a specific bootloader is needed (or a specific version of an existing bootloader, e.g. BSPs shipping their own version of u-boot is common). FWIW there is also a meta-initramfs layer in the meta-openembedded repository which contains kexecboot. Are there bootloader(s) that you are looking for that are currently missing? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Do we support the kernel supporting off EFI directly as this can make boot much faster as there is no need for another boot loader in order to instruct the kernel how to boot your respected device. Cheers Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New recipe for toolchain fails install, ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored.
Hey Jim,
I had a stressful day with other things so I would like some time to unwind but
I will try and help out
later if that's OK.
Nick
On 14-11-13 03:13 PM, Jim Rafert wrote:
Hi folks,
I'm trying to put together a recipe to include llvm and clang in the yocto
toolchain. My goal is to have the clang compiler available for application
development. I do not intend to compile the kernel or OS image with clang.
I have created a recipe and placed it in one of my added layers as follows:
LICENSE = NCSA
PR = r0
LIC_FILES_CHKSUM = file://LICENSE.TXT;md5=47e311aa9caedd1b3abf098bd7814d1d
SRC_URI = file://llvm-3.5.0.tar.gz \
SRC_URI[md5sum] = e2dd127722ffb305c981d2a02687b4ff
SRC_URI[sha256sum] =
1badb762129feb7ced9484a7969c88cebab9b01b80b83002fc9690933cd7d0e0
EXTRA_OECONF = --config=Linux-yocto
INHIBIT_PACKAGE_DEBUG_SPLIT = 1
INSANE_SKIP_${PN} = already-stripped
#FILES_${PN} = ${libdir}/* /usr/bin
inherit autotools
do_configure () {
./configure --enable-optimized --enable-targets=x86,x86_64
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
}
The recipe is copied from another recipe of mine that builds the POCO
libraries, so INSANE_SKIP_${PN} = already-stripped may not actually be
necessary, but was left in until I got the recipe running.
I add the recipe to the toolchain by including it in TOOLCHAIN_HOST_TASK from
my local.conf, thus:
TOOLCHAIN_HOST_TASK += llvm
This gets the source unpacked, configures, and compiles, but do_install fails
with several instances of this message: ERROR: ld.so: object 'libpseudo.so'
from LD_PRELOAD cannot be preloaded: ignored.
Even though it doesn't install, the build products are in the work directory,
so I examined them.
[jimr@krusty llvm-3.5.0]$ file
/home/jimr/tera/yocto/daisy/build/tmp/work/i586-poky-linux/llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang
/home/jimr/tera/yocto/daisy/build/tmp/work/i586-poky-linux/llvm/3.5.0-r0/llvm-3.5.0/Release+Asserts/bin/clang:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.16,
BuildID[sha1]=0x96bd97125551d23e94bcbbc4e68b69b8db36def9, not stripped
I was hoping that this would be built for the architecture specified in
local.conf for the toolchain, which is: SDKMACHINE ?= x86_64
I think that this architecture mismatch may be the root of the problem with
the LD_PRELOAD of pseudo. I also would expect that the work directory would
be under x86_64-nativesdk-pokysdk-linux or x86_64-pokysdk-linux rather than
i586-poky-linux.
Do any of you Yocto/OE/bitbake experts out there know what I might be doing
wrong, or not doing, that causes this problem?
I have attached the output of the bitbake command, my local.conf file, the
recipe, and config.log and config.status from the work directory for your
viewing pleasure.
Any help with this would be greatly appreciated.
-Jim-
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
OK, I'll come up with a simple test case + procedure to reproduce it.
Cheers,
Nick
On Wed, Nov 12, 2014 at 1:49 AM, nick xerofo...@gmail.com wrote:
I would state so as if you need it and it doesn't work then it probably is
a bug
with bitbake.
Cheers Nick
On 14-11-11 09:37 AM, Nick D'Ademo wrote:
Would this be classified as a BitBake bug then?
I actually have a recipe which requires 32-bit libs - I'll see if
there's a
way around it.
Thanks for your help thus far.
Nick
On Wed, Nov 12, 2014 at 1:18 AM, nick xerofo...@gmail.com wrote:
That was my issue with your build, but I wasn't sure if that was going
to
prevent the build from you companies requirements. I would recommend
only
making the build 64 bit as it seems that there is no reason for
backwards
compatibility with older 32 bit libraries for your build.
Regards Nick
On 14-11-11 06:23 AM, Nick D'Ademo wrote:
A bit of progress (found the cause of the error at least):
The script that is failing is: linux/scripts/kconfig/lxdialog/
*check-lxdialog.sh*
I added 'set -x' to the script so I could see the output as BitBake
executes it... The function within that script which is failing is
*check()
*- in particular the following is failing:
*$cc -x c - -o $tmp 2/dev/null 'EOF'#include CURSES_LOCmain() {}EOF*
*Script output:*
*gcc
-isystem/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -L/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1
'-DCURSES_LOC=ncurses.h' -DLOCALE
-L/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
-lncursesw -ltinfo -x c - -o .lxdialog.tmp*
This command is returning 1 when it should be returning 0 (i.e.
successful
compile).
The exact error is:
*/usr/bin/ld: cannot find /lib64/libc.so.6/usr/bin/ld: cannot find
/usr/lib64/libc_nonshared.acollect2: error: ld returned 1 exit status*
Where is it trying to find those libraries? In my host system (they
don't
exist!) or the system root of my build? The files *only* exist in my
system
root @
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
*and
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/lib64.*
I suspect that this may be due to the fact that my custom machine conf
is a
multilib configuration...
Any further ideas?
On Tue, Nov 11, 2014 at 2:10 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com
wrote:
If I do the following (from the same Terminal that oe-init-build-env
has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not
invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a
issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS
=
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO
=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a
issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works
fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com
wrote:
Try downloading a stock kernel for kernel.org and extract it in
your
home
directory and run make menuconfig
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Seems like the best way to report any bug including ones related to YP.
Nick
On 14-11-12 08:12 PM, Nick D'Ademo wrote:
OK, I'll come up with a simple test case + procedure to reproduce it.
Cheers,
Nick
On Wed, Nov 12, 2014 at 1:49 AM, nick xerofo...@gmail.com wrote:
I would state so as if you need it and it doesn't work then it probably is
a bug
with bitbake.
Cheers Nick
On 14-11-11 09:37 AM, Nick D'Ademo wrote:
Would this be classified as a BitBake bug then?
I actually have a recipe which requires 32-bit libs - I'll see if
there's a
way around it.
Thanks for your help thus far.
Nick
On Wed, Nov 12, 2014 at 1:18 AM, nick xerofo...@gmail.com wrote:
That was my issue with your build, but I wasn't sure if that was going
to
prevent the build from you companies requirements. I would recommend
only
making the build 64 bit as it seems that there is no reason for
backwards
compatibility with older 32 bit libraries for your build.
Regards Nick
On 14-11-11 06:23 AM, Nick D'Ademo wrote:
A bit of progress (found the cause of the error at least):
The script that is failing is: linux/scripts/kconfig/lxdialog/
*check-lxdialog.sh*
I added 'set -x' to the script so I could see the output as BitBake
executes it... The function within that script which is failing is
*check()
*- in particular the following is failing:
*$cc -x c - -o $tmp 2/dev/null 'EOF'#include CURSES_LOCmain() {}EOF*
*Script output:*
*gcc
-isystem/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -L/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1
'-DCURSES_LOC=ncurses.h' -DLOCALE
-L/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
-lncursesw -ltinfo -x c - -o .lxdialog.tmp*
This command is returning 1 when it should be returning 0 (i.e.
successful
compile).
The exact error is:
*/usr/bin/ld: cannot find /lib64/libc.so.6/usr/bin/ld: cannot find
/usr/lib64/libc_nonshared.acollect2: error: ld returned 1 exit status*
Where is it trying to find those libraries? In my host system (they
don't
exist!) or the system root of my build? The files *only* exist in my
system
root @
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
*and
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/lib64.*
I suspect that this may be due to the fact that my custom machine conf
is a
multilib configuration...
Any further ideas?
On Tue, Nov 11, 2014 at 2:10 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com
wrote:
If I do the following (from the same Terminal that oe-init-build-env
has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not
invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a
issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS
=
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO
=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a
issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works
fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com
wrote:
Try downloading a stock kernel for kernel.org and extract it in
your
home
directory and run make menuconfig in
the root of the kernel source
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
A bit of progress (found the cause of the error at least):
The script that is failing is: linux/scripts/kconfig/lxdialog/
*check-lxdialog.sh*
I added 'set -x' to the script so I could see the output as BitBake
executes it... The function within that script which is failing is *check()
*- in particular the following is failing:
*$cc -x c - -o $tmp 2/dev/null 'EOF'#include CURSES_LOCmain() {}EOF*
*Script output:*
*gcc -isystem/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -L/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1
'-DCURSES_LOC=ncurses.h' -DLOCALE
-L/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
-lncursesw -ltinfo -x c - -o .lxdialog.tmp*
This command is returning 1 when it should be returning 0 (i.e. successful
compile).
The exact error is:
*/usr/bin/ld: cannot find /lib64/libc.so.6/usr/bin/ld: cannot find
/usr/lib64/libc_nonshared.acollect2: error: ld returned 1 exit status*
Where is it trying to find those libraries? In my host system (they don't
exist!) or the system root of my build? The files *only* exist in my system
root @ */home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64 *and
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/lib64.*
I suspect that this may be due to the fact that my custom machine conf is a
multilib configuration...
Any further ideas?
On Tue, Nov 11, 2014 at 2:10 AM, Nick Krause xerofo...@gmail.com wrote:
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com
wrote:
If I do the following (from the same Terminal that oe-init-build-env has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a
issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO
=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works
fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in
your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am
assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still
experiencing
the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com
wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date
temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com
wrote:
I tried bitbake linux-yocto -c menuconfig
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
That was my issue with your build, but I wasn't sure if that was going to
prevent the build from you companies requirements. I would recommend only
making the build 64 bit as it seems that there is no reason for backwards
compatibility with older 32 bit libraries for your build.
Regards Nick
On 14-11-11 06:23 AM, Nick D'Ademo wrote:
A bit of progress (found the cause of the error at least):
The script that is failing is: linux/scripts/kconfig/lxdialog/
*check-lxdialog.sh*
I added 'set -x' to the script so I could see the output as BitBake
executes it... The function within that script which is failing is *check()
*- in particular the following is failing:
*$cc -x c - -o $tmp 2/dev/null 'EOF'#include CURSES_LOCmain() {}EOF*
*Script output:*
*gcc -isystem/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -L/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1
'-DCURSES_LOC=ncurses.h' -DLOCALE
-L/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
-lncursesw -ltinfo -x c - -o .lxdialog.tmp*
This command is returning 1 when it should be returning 0 (i.e. successful
compile).
The exact error is:
*/usr/bin/ld: cannot find /lib64/libc.so.6/usr/bin/ld: cannot find
/usr/lib64/libc_nonshared.acollect2: error: ld returned 1 exit status*
Where is it trying to find those libraries? In my host system (they don't
exist!) or the system root of my build? The files *only* exist in my system
root @ */home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64 *and
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/lib64.*
I suspect that this may be due to the fact that my custom machine conf is a
multilib configuration...
Any further ideas?
On Tue, Nov 11, 2014 at 2:10 AM, Nick Krause xerofo...@gmail.com wrote:
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com
wrote:
If I do the following (from the same Terminal that oe-init-build-env has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a
issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO
=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works
fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in
your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am
assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still
experiencing
the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com
wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date
temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Would this be classified as a BitBake bug then?
I actually have a recipe which requires 32-bit libs - I'll see if there's a
way around it.
Thanks for your help thus far.
Nick
On Wed, Nov 12, 2014 at 1:18 AM, nick xerofo...@gmail.com wrote:
That was my issue with your build, but I wasn't sure if that was going to
prevent the build from you companies requirements. I would recommend only
making the build 64 bit as it seems that there is no reason for backwards
compatibility with older 32 bit libraries for your build.
Regards Nick
On 14-11-11 06:23 AM, Nick D'Ademo wrote:
A bit of progress (found the cause of the error at least):
The script that is failing is: linux/scripts/kconfig/lxdialog/
*check-lxdialog.sh*
I added 'set -x' to the script so I could see the output as BitBake
executes it... The function within that script which is failing is
*check()
*- in particular the following is failing:
*$cc -x c - -o $tmp 2/dev/null 'EOF'#include CURSES_LOCmain() {}EOF*
*Script output:*
*gcc -isystem/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -L/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1
'-DCURSES_LOC=ncurses.h' -DLOCALE
-L/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
-lncursesw -ltinfo -x c - -o .lxdialog.tmp*
This command is returning 1 when it should be returning 0 (i.e.
successful
compile).
The exact error is:
*/usr/bin/ld: cannot find /lib64/libc.so.6/usr/bin/ld: cannot find
/usr/lib64/libc_nonshared.acollect2: error: ld returned 1 exit status*
Where is it trying to find those libraries? In my host system (they don't
exist!) or the system root of my build? The files *only* exist in my
system
root @ */home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
*and
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/lib64.*
I suspect that this may be due to the fact that my custom machine conf
is a
multilib configuration...
Any further ideas?
On Tue, Nov 11, 2014 at 2:10 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com
wrote:
If I do the following (from the same Terminal that oe-init-build-env
has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a
issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO
=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a
issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works
fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in
your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am
assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still
experiencing
the
same error message unfortunately.
On Mon, Nov
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
I would state so as if you need it and it doesn't work then it probably is a bug
with bitbake.
Cheers Nick
On 14-11-11 09:37 AM, Nick D'Ademo wrote:
Would this be classified as a BitBake bug then?
I actually have a recipe which requires 32-bit libs - I'll see if there's a
way around it.
Thanks for your help thus far.
Nick
On Wed, Nov 12, 2014 at 1:18 AM, nick xerofo...@gmail.com wrote:
That was my issue with your build, but I wasn't sure if that was going to
prevent the build from you companies requirements. I would recommend only
making the build 64 bit as it seems that there is no reason for backwards
compatibility with older 32 bit libraries for your build.
Regards Nick
On 14-11-11 06:23 AM, Nick D'Ademo wrote:
A bit of progress (found the cause of the error at least):
The script that is failing is: linux/scripts/kconfig/lxdialog/
*check-lxdialog.sh*
I added 'set -x' to the script so I could see the output as BitBake
executes it... The function within that script which is failing is
*check()
*- in particular the following is failing:
*$cc -x c - -o $tmp 2/dev/null 'EOF'#include CURSES_LOCmain() {}EOF*
*Script output:*
*gcc -isystem/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -L/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1
'-DCURSES_LOC=ncurses.h' -DLOCALE
-L/home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
-lncursesw -ltinfo -x c - -o .lxdialog.tmp*
This command is returning 1 when it should be returning 0 (i.e.
successful
compile).
The exact error is:
*/usr/bin/ld: cannot find /lib64/libc.so.6/usr/bin/ld: cannot find
/usr/lib64/libc_nonshared.acollect2: error: ld returned 1 exit status*
Where is it trying to find those libraries? In my host system (they don't
exist!) or the system root of my build? The files *only* exist in my
system
root @ */home/nick/poky/build/tmp/sysroots/custom_machine_name/usr/lib64
*and
*/home/nick/poky/build/tmp/sysroots/custom_machine_name/lib64.*
I suspect that this may be due to the fact that my custom machine conf
is a
multilib configuration...
Any further ideas?
On Tue, Nov 11, 2014 at 2:10 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com
wrote:
If I do the following (from the same Terminal that oe-init-build-env
has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a
issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO
=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a
issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works
fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in
your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am
assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still
experiencing
the
same error message unfortunately
Re: [yocto] Making Hob better.
I am too interesting in helping out Yocto but more with kernel work on Yocto rt and standard kernel recipes. If someone would like to point me in the right direction to aid in helping out in this area of the Yocto project that would be very helpful. Thanks Nick On 14-11-11 10:46 AM, John Unland wrote: It is great to see so much interest in Hob: for a while we thought nobody was using it! I do see the potential for toaster as wel (Forgot to mention it). Yes I do see in the near future Hob being phased out in later releases. But for what it is right now, there are people using it, I really think it's a great idea to have something like hob for embedded systems espically the Hobbyist crowd. A kernel configuration module for Toaster is something that we'd like to see at some point. And the branding one I agree it would be great to have. Feel free to open Bugzilla entries for both. Under what catagories would these two be filed under? Contributions are very welcome! :) You can get involved in both development and QA work. To get started, you can subscribe to the Toaster mailing list: Sure I'll start looking over there. I'm pretty busy with my college schedule right now so I'm afraid I can't make it to the regular meetings. But thanks for the offer! :) Hob is not meant to be like Suse Studios. Further more you are right about the interface sucking hard for certain things, I would recommend you start cleaning that up first and then afterwards move on to other areas of interest with YP. Cheers Nick I see, will do. Cheers. On Tue, Nov 11, 2014 at 7:53 AM, Barros Pena, Belen belen.barros.p...@intel.com wrote: Hi Richard, On 11/11/2014 12:58, Richard Schmitt richard.schm...@freescale.com wrote: We also are looking to update Hob. It is great to see so much interest in Hob: for a while we thought nobody was using it! But I should probably be clear about the project plans in relation to Hob. The final goal is to replace it with Toaster. Hob is still being maintained, but no new features are planned for it. You are of course free to take Hob and add to it if you feel that's the tool that better suits your needs. However: * I cannot guarantee that Hob will be included in future releases of the Yocto Project. * Having been very involved in both Hob and Toaster, I must say that Toaster will be much more powerful, easier to extend with new features like the ones you suggest below, and in general way nicer to use. I am not sure how much you know about the Toaster project, or if there is anything in it that makes it unfit for your needs. But I would be happy to have a chat about it all, answer any questions you may have, and demo it if you'd like to see it. In particular, adding kernel feature support. Branding would be nice too. A kernel configuration module for Toaster is something that we'd like to see at some point. And the branding one I agree it would be great to have. Feel free to open Bugzilla entries for both. Cheers Belén Rich -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Barros Pena, Belen Sent: Tuesday, November 11, 2014 4:37 AM To: John Unland; yocto@yoctoproject.org Subject: Re: [yocto] Making Hob better. Hi John, Thanks for your feedback on Hob: I agree with everything you said. We are currently moving towards web-based interfaces for the Yocto Project tools, and are working on something called Toaster that eventually will do what Hob does. You can get more information on Toaster at https://www.yoctoproject.org/documentation/toaster-manual-17 On 10/11/2014 23:58, John Unland opensourcejohn2...@gmail.com wrote: Lastly, I would really love to help with development as well. I haven't really gotten into programming that much but I have worked with the Fedora Server Special Interest Group doing QA for Alpha and Beta release. So if anyone can put me in the right direction I can certainly help YP out. Contributions are very welcome! :) You can get involved in both development and QA work. To get started, you can subscribe to the Toaster mailing list: https://lists.yoctoproject.org/listinfo/toaster You can have a look at the features we are currently working on in the Yocto Project Bugzilla instance http://goo.gl/KncliQ There is information on how to contribute at https://wiki.yoctoproject.org/wiki/Contribute_to_Toaster We also have a weekly call that happens on Wednesdays at 4pm GMT. If you would like to join the call, let me know. All the best, Belén Thank you. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Nick,
Yes this is a issue with your custom machine and I believe this is a issue with
your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing
the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running
the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from
my
understanding. Also check all the
paths in your require lines as there may be an issue with your
builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to
nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6
lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com
wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf
file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on
nuc.conf,
so
actually: MACHINE = custom_machine_name. I replaced it with
nuc
in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com
wrote:
Do you run source oe-init-build-env before building and why is
your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
If I do the following (from the same Terminal that *oe-init-build-env *has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing
the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com
wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running
the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from
my
understanding. Also check all the
paths in your require lines as there may be an issue with your
builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to
nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model
DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6
lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com
wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf
file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
On Mon, Nov 10, 2014 at 7:56 AM, Nick D'Ademo nickdad...@gmail.com wrote:
If I do the following (from the same Terminal that oe-init-build-env has
been run):
1) cd
/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build
2) make menuconfig
Menu config loads correctly.
So for some reason, 'bitbake linux-yocto -c menuconfig' is not invoking
menuconfig properly.
Any ideas where to look in regard to my custom machine config?
On Mon, Nov 10, 2014 at 10:11 PM, nick xerofo...@gmail.com wrote:
Nick,
Yes this is a issue with your custom machine and I believe this is a issue
with your your machine
conf is located in the build directories.
Cheers Nick
On 14-11-10 02:26 AM, Nick D'Ademo wrote:
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for
kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue
with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still
experiencing
the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com
wrote:
I tried bitbake linux-yocto -c menuconfig on my own system
running
the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine
from
my
understanding. Also check all the
paths in your require lines as there may be an issue with your
builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to
nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model
DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6
lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com
wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf
file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo
Re: [yocto] Making Hob better.
John, Hob is not meant to be like Suse Studios. Further more you are right about the interface sucking hard for certain things, I would recommend you start cleaning that up first and then afterwards move on to other areas of interest with YP. Cheers Nick On 14-11-10 06:58 PM, John Unland wrote: Hello everyone, I am new to the embedded space, been working with embedded for a couple of months now as well as Linux itself. After much time spent with Hob I have to say it's a awesome tool to use. However I would like it to be better than it already is, I see the potential of this interface to help newbies like myself, weather it be hobbyist or industrial use. So below is what I have found through my fiddling around with Hob. -Some interface inconsistencies when your selecting layers, image type, distro type etc. -Image deployments (Only .hddimg and .iso can be deployed to physical media at the end (To my knowledge) of the build process. There's is a lot of FS types, but I would really like to have a steps on how to install these other FS types which documentation nor simply goggling it helps) -Branding. There are ways to go and edit files to specify how to rebrand and stuff but that requires a command line. I would like to have the simple screen where I can add branding (Boot screens, Logos, and distro names etc.). I could definitely if Hob does have a Web User interface where I can't access a command line to change parameters of the finished product. -Documentation is awesome, however from a person that has only a year and a half experience using Linux it's kinda hard reading it sometimes. (Not really anything bad on Yocto's part. I would just like to input something that newbies can be represented in this project) I really could see Hob become a open source version of openSUSE Studio (Which it's closed source) but for embedded devices. So that's just my hopes for Hob / Yocto could become... Lastly, I would really love to help with development as well. I haven't really gotten into programming that much but I have worked with the Fedora Server Special Interest Group doing QA for Alpha and Beta release. So if anyone can put me in the right direction I can certainly help YP out. Thank you. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unable to find the ncurses libraries when running menuconfig
Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Check to see if you actuality have it installed on your host system for your package manager. The library for ncurses for compiling the kernel is different based on your distro, check your distro's installer and install the correct ncurses package first. If this is still an issue please reply with a newer error message. Cheers Nick On 14-11-09 08:05 PM, Nick D'Ademo wrote: Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Thanks for the quick reply Nick. Host system is Ubuntu 14.04. ncurses is already installed: sudo apt-get install libncurses5-dev Reading package lists... Done Building dependency tree Reading state information... Done libncurses5-dev is already the newest version. On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com wrote: Check to see if you actuality have it installed on your host system for your package manager. The library for ncurses for compiling the kernel is different based on your distro, check your distro's installer and install the correct ncurses package first. If this is still an issue please reply with a newer error message. Cheers Nick On 14-11-09 08:05 PM, Nick D'Ademo wrote: Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Do you run source oe-init-build-env before building and why is your machine set to nuc seems this may be an issue? Nick On 14-11-09 08:15 PM, Nick D'Ademo wrote: Thanks for the quick reply Nick. Host system is Ubuntu 14.04. ncurses is already installed: sudo apt-get install libncurses5-dev Reading package lists... Done Building dependency tree Reading state information... Done libncurses5-dev is already the newest version. On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com wrote: Check to see if you actuality have it installed on your host system for your package manager. The library for ncurses for compiling the kernel is different based on your distro, check your distro's installer and install the correct ncurses package first. If this is still an issue please reply with a newer error message. Cheers Nick On 14-11-09 08:05 PM, Nick D'Ademo wrote: Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
That would make sense and that's why I suggested running oe-init-env in order to make sure the path are correct before building. Cheers Nick On 14-11-09 08:31 PM, Bob Cochran wrote: On 11/09/2014 08:15 PM, Nick D'Ademo wrote: Thanks for the quick reply Nick. Host system is Ubuntu 14.04. ncurses is already installed: sudo apt-get install libncurses5-dev Reading package lists... Done Building dependency tree Reading state information... Done libncurses5-dev is already the newest version. Oh boy, I've seen this before. I seem to remember this being caused by a problem with the path setup or something in the environment and maybe not being able to find the scripts folder or reaching a wrong folder first. How are you setting up your environment before invoking bitbake? Were you using the ADT? If so check out cross compiling the kernel here: http://www.openembedded.org/wiki/SDK/Toolchain/Application_Developer_Toolkit On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com mailto:xerofo...@gmail.com wrote: Check to see if you actuality have it installed on your host system for your package manager. The library for ncurses for compiling the kernel is different based on your distro, check your distro's installer and install the correct ncurses package first. If this is still an issue please reply with a newer error message. Cheers Nick On 14-11-09 08:05 PM, Nick D'Ademo wrote: Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Hey Nick, This seems to then be an issue with incorrect paths or build information in your nuc.conf as the most likely culprit. If you can post your machine's conf file I will be glad to see if there are any issues I can spot. Nick On 14-11-09 08:33 PM, Nick D'Ademo wrote: 1) source oe-init-build-env is run before building. 2) We are actually using a custom machine .conf based on nuc.conf, so actually: MACHINE = custom_machine_name. I replaced it with nuc in this post to avoid confusion. On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com wrote: Do you run source oe-init-build-env before building and why is your machine set to nuc seems this may be an issue? Nick On 14-11-09 08:15 PM, Nick D'Ademo wrote: Thanks for the quick reply Nick. Host system is Ubuntu 14.04. ncurses is already installed: sudo apt-get install libncurses5-dev Reading package lists... Done Building dependency tree Reading state information... Done libncurses5-dev is already the newest version. On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com wrote: Check to see if you actuality have it installed on your host system for your package manager. The library for ncurses for compiling the kernel is different based on your distro, check your distro's installer and install the correct ncurses package first. If this is still an issue please reply with a newer error message. Cheers Nick On 14-11-09 08:05 PM, Nick D'Ademo wrote: Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to nuc.conf -
however, BT support, multilib, and preferred providers have been added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf, so
actually: MACHINE = custom_machine_name. I replaced it with nuc in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com wrote:
Do you run source oe-init-build-env before building and why is your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com wrote:
Check to see if you actuality have it installed on your host system
for
your package manager.
The library for ncurses for compiling the kernel is different based on
your distro, check
your distro's installer and install the correct ncurses package first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU=
*make[1]: Entering directory
`/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build'
GEN ./Makefile *** Unable to find the ncurses libraries or the
***
required header files. *** 'make menuconfig' requires the ncurses
libraries. *** *** Install ncurses (ncurses-devel) and try again.
***
make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: ***
[menuconfig] Error 2make[1]: *** [sub-make] Error 2make: ***
[__sub-make]
Error 2Command failed.Press any key to continue... *
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Thanks Bob - glad to hear I'm not the first to see this! Not using the ADT and 'source oe-init-build-env' is run before building. On Mon, Nov 10, 2014 at 12:31 PM, Bob Cochran yo...@mindchasers.com wrote: On 11/09/2014 08:15 PM, Nick D'Ademo wrote: Thanks for the quick reply Nick. Host system is Ubuntu 14.04. ncurses is already installed: sudo apt-get install libncurses5-dev Reading package lists... Done Building dependency tree Reading state information... Done libncurses5-dev is already the newest version. Oh boy, I've seen this before. I seem to remember this being caused by a problem with the path setup or something in the environment and maybe not being able to find the scripts folder or reaching a wrong folder first. How are you setting up your environment before invoking bitbake? Were you using the ADT? If so check out cross compiling the kernel here: http://www.openembedded.org/wiki/SDK/Toolchain/ Application_Developer_Toolkit On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com mailto:xerofo...@gmail.com wrote: Check to see if you actuality have it installed on your host system for your package manager. The library for ncurses for compiling the kernel is different based on your distro, check your distro's installer and install the correct ncurses package first. If this is still an issue please reply with a newer error message. Cheers Nick On 14-11-09 08:05 PM, Nick D'Ademo wrote: Getting a strange error when attempting to configure the Yocto Linux kernel via: bitbake linux-yocto -c menuconfig. Does anyone have any ideas? (error message below) Much appreciated. Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = m64 corei7 TARGET_FPU= *make[1]: Entering directory `/home/nick/poky/build/tmp/work/corei7-64-intel-common- poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_ 0caf16d385-r0/linux-corei7-64-intel-common-standard-build' GEN ./Makefile *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: *** [menuconfig] Error 2make[1]: *** [sub-make] Error 2make: *** [__sub-make] Error 2Command failed.Press any key to continue... * -- ___ 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] Unable to find the ncurses libraries when running menuconfig
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from my
understanding. Also check all the
paths in your require lines as there may be an issue with your builds and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to nuc.conf -
however, BT support, multilib, and preferred providers have been added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf, so
actually: MACHINE = custom_machine_name. I replaced it with nuc in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com wrote:
Do you run source oe-init-build-env before building and why is your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com wrote:
Check to see if you actuality have it installed on your host system
for
your package manager.
The library for ncurses for compiling the kernel is different based
on
your distro, check
your distro's installer and install the correct ncurses package
first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto
Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU=
*make[1]: Entering directory
`/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build'
GEN ./Makefile *** Unable to find the ncurses libraries or the
***
required header files. *** 'make menuconfig' requires the ncurses
libraries. *** *** Install ncurses (ncurses-devel) and try again.
***
make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: ***
[menuconfig] Error 2make[1]: *** [sub-make] Error 2make: ***
[__sub-make]
Error 2Command failed.Press any key to continue... *
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Seems to after reading and doing some research a build issue with multiple jobs
or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from my
understanding. Also check all the
paths in your require lines as there may be an issue with your builds and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to nuc.conf -
however, BT support, multilib, and preferred providers have been added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf, so
actually: MACHINE = custom_machine_name. I replaced it with nuc in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com wrote:
Do you run source oe-init-build-env before building and why is your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com wrote:
Check to see if you actuality have it installed on your host system
for
your package manager.
The library for ncurses for compiling the kernel is different based
on
your distro, check
your distro's installer and install the correct ncurses package
first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto
Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU=
*make[1]: Entering directory
`/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build'
GEN ./Makefile *** Unable to find the ncurses libraries or the
***
required header files. *** 'make menuconfig' requires the ncurses
libraries. *** *** Install ncurses (ncurses-devel) and try again.
***
make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]: ***
[menuconfig] Error 2make[1]: *** [sub-make] Error 2make: ***
[__sub-make]
Error 2Command failed.Press any key to continue... *
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from my
understanding. Also check all the
paths in your require lines as there may be an issue with your builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf, so
actually: MACHINE = custom_machine_name. I replaced it with nuc
in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com wrote:
Do you run source oe-init-build-env before building and why is your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com
wrote:
Check to see if you actuality have it installed on your host
system
for
your package manager.
The library for ncurses for compiling the kernel is different
based
on
your distro, check
your distro's installer and install the correct ncurses package
first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto
Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU=
*make[1]: Entering directory
`/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build'
GEN ./Makefile *** Unable to find the ncurses libraries or
the
***
required header files. *** 'make menuconfig' requires the ncurses
libraries. *** *** Install ncurses (ncurses-devel) and try
again.
***
make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2]:
***
[menuconfig] Error 2make[1]: *** [sub-make] Error 2make: ***
[__sub-make]
Error 2Command failed.Press any key to continue
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Try downloading a stock kernel for kernel.org and extract it in your home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming either
ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from my
understanding. Also check all the
paths in your require lines as there may be an issue with your builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf, so
actually: MACHINE = custom_machine_name. I replaced it with nuc
in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com wrote:
Do you run source oe-init-build-env before building and why is your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com
wrote:
Check to see if you actuality have it installed on your host
system
for
your package manager.
The library for ncurses for compiling the kernel is different
based
on
your distro, check
your distro's installer and install the correct ncurses package
first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto
Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU=
*make[1]: Entering directory
`/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1+gitAUTOINC+b86dd5c6f4_0caf16d385-r0/linux-corei7-64-intel-common-standard-build'
GEN ./Makefile *** Unable to find the ncurses libraries or
the
***
required header files. *** 'make menuconfig' requires the ncurses
libraries. *** *** Install ncurses (ncurses-devel) and try
again.
***
make[3]: *** [scripts/kconfig/dochecklxdialog] Error 1make[2
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works fine and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in your home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from my
understanding. Also check all the
paths in your require lines as there may be an issue with your builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to
nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf
file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf,
so
actually: MACHINE = custom_machine_name. I replaced it with nuc
in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com
wrote:
Do you run source oe-init-build-env before building and why is
your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com
wrote:
Check to see if you actuality have it installed on your host
system
for
your package manager.
The library for ncurses for compiling the kernel is different
based
on
your distro, check
your distro's installer and install the correct ncurses package
first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto
Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU=
*make[1]: Entering directory
`/home/nick/poky/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.17.1
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
Nick,
Then this is an issue with your machine conf or paths required for kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue with you
building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works fine and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in your home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from my
understanding. Also check all the
paths in your require lines as there may be an issue with your builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to
nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6 lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf
file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on nuc.conf,
so
actually: MACHINE = custom_machine_name. I replaced it with nuc
in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com
wrote:
Do you run source oe-init-build-env before building and why is
your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com
wrote:
Check to see if you actuality have it installed on your host
system
for
your package manager.
The library for ncurses for compiling the kernel is different
based
on
your distro, check
your distro's installer and install the correct ncurses package
first.
If
this is still an
issue please reply with a newer error message.
Cheers Nick
On 14-11-09 08:05 PM, Nick D'Ademo wrote:
Getting a strange error when attempting to configure the Yocto
Linux
kernel
via: bitbake linux-yocto -c menuconfig.
Does anyone have any ideas? (error message below)
Much appreciated.
Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING = Ubuntu-14.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = m64 corei7
TARGET_FPU
Re: [yocto] Unable to find the ncurses libraries when running menuconfig
menuconfig works with a core-image-minimal vanilla build:
*Build Configuration:BB_VERSION= 1.24.0BUILD_SYS =
x86_64-linuxNATIVELSBSTRING = Ubuntu-14.04TARGET_SYS=
arm-poky-linux-gnueabiMACHINE = qemuarmDISTRO=
pokyDISTRO_VERSION= 1.7TUNE_FEATURES = arm armv5 thumb
dspTARGET_FPU= softmeta meta-yocto
meta-yocto-bsp=
master:45bb9e3323073070453647a32289dc1792f3d660meta-oe
meta-multimedia meta-gnome=
master:dac2422f737c351c37a8405a76b5f0b5df9311a0*
So this must be an issue with my custom machine.
On Mon, Nov 10, 2014 at 2:43 PM, nick xerofo...@gmail.com wrote:
Nick,
Then this is an issue with your machine conf or paths required for kernel
building. Are you able
to build a poky distro with a working kernel and this is just a issue with
you building the yocto
kernel alone or can you also not build poky too?
Cheers Nick
On 14-11-09 10:36 PM, Nick D'Ademo wrote:
Just tried with the latest 3.17.2 kernel. 'make menuconfig' works fine
and
loads the interactive kernel config.
On Mon, Nov 10, 2014 at 2:01 PM, nick xerofo...@gmail.com wrote:
Try downloading a stock kernel for kernel.org and extract it in your
home
directory and run make menuconfig in
the root of the kernel source tree, if this works then I am assuming
either ncurses or your machine conf is wrong
somewhere.
Cheers Nick
On 14-11-09 09:51 PM, Nick D'Ademo wrote:
Hi Nick,
I removed build/tmp/ and performed a rebuild - I'm still experiencing
the
same error message unfortunately.
On Mon, Nov 10, 2014 at 12:58 PM, nick xerofo...@gmail.com wrote:
Seems to after reading and doing some research a build issue with
multiple
jobs or try running rm -r tmp in your
build and then rebuild as it may be an issue with out of date temp
files.
Cheers Nick
On 14-11-09 08:51 PM, Nick D'Ademo wrote:
Thanks for trying that out Nick.
Issue is present on both 3.14 and 3.17 for me.
All paths in the require lines are correct too.
Any other ideas?
On Mon, Nov 10, 2014 at 12:46 PM, nick xerofo...@gmail.com wrote:
I tried bitbake linux-yocto -c menuconfig on my own system running
the
same distro and it seems to my
default use kernel 3.14 not 3.17 otherwise this seems be fine from
my
understanding. Also check all the
paths in your require lines as there may be an issue with your
builds
and
the path set up by these files
that you are linking to for your kernel build.
Nick
On 14-11-09 08:40 PM, Nick D'Ademo wrote:
Thanks Nick.
Machine conf is as follows (it's actually nearly identical to
nuc.conf
-
however, BT support, multilib, and preferred providers have been
added):
#@TYPE: Machine
#@NAME: chiefriver
#@WEBTITLE: Intel Next Unit of Computing (NUC) Model: DC3217IYE
#@DESCRIPTION: Machine configuration for Intel NUC model DC3217IYE
# i.e. Ivy Bridge + Panther Point
PREFERRED_VERSION_linux-yocto ?= 3.17%
MACHINE_FEATURES += va-impl-intel wifi efi bluetooth
MACHINE_FEATURES += intel-ucode
require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require multilib.conf
MACHINE_HWCODECS ?= va-intel gst-va-intel
XSERVER ?= ${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_I965} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware-iwlwifi-6000g2b-6
lms8
# disable the serial port configuration
SERIAL_CONSOLE =
PREFERRED_PROVIDER_jpeg = jpeg
PREFERRED_PROVIDER_jpeg-native = jpeg-native
PREFERRED_PROVIDER_virtual/fftw = fftw
On Mon, Nov 10, 2014 at 12:36 PM, nick xerofo...@gmail.com
wrote:
Hey Nick,
This seems to then be an issue with incorrect paths or build
information
in your nuc.conf
as the most likely culprit. If you can post your machine's conf
file I
will be glad to see
if there are any issues I can spot.
Nick
On 14-11-09 08:33 PM, Nick D'Ademo wrote:
1) source oe-init-build-env is run before building.
2) We are actually using a custom machine .conf based on
nuc.conf,
so
actually: MACHINE = custom_machine_name. I replaced it with
nuc
in
this
post to avoid confusion.
On Mon, Nov 10, 2014 at 12:25 PM, nick xerofo...@gmail.com
wrote:
Do you run source oe-init-build-env before building and why is
your
machine
set to nuc seems this may be an issue?
Nick
On 14-11-09 08:15 PM, Nick D'Ademo wrote:
Thanks for the quick reply Nick.
Host system is Ubuntu 14.04. ncurses is already installed:
sudo apt-get install libncurses5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libncurses5-dev is already the newest version.
On Mon, Nov 10, 2014 at 12:09 PM, nick xerofo...@gmail.com
wrote:
Check to see if you actuality have
Re: [yocto] Build optimization question
Diego, I agree with Ross here in from my experience with embedded systems the three best ways to strip your root file system are by removing unneeded boot loader coe, removing unneeded kernel components and that of striping your middle ware to smaller versions like Busybox and other similiar packages like elibc. Also running strip after your debugging is done for the target can strip your code even further, there are cases of stripping large programs like the kernel down from 20 megabytes to 2. Lastly, linking Busybox statically is great if you don't need a reason to link it against a C library implementation as static versions of Busybox can easily be less then 10 megabytes from my reading and experience. Regards Nick On 14-11-08 01:03 PM, Diego Sueiro wrote: Take a look at poky-tiny distro: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky-tiny.conf As you are using BBB you can optimize u-boot code and remove some board detection steps. I noticed that MLO generated by u-boot 2014.07 mainline is too much faster than the old ones. Regards, -- *dS Diego Sueiro sent from mobile. Em 08/11/2014 12:54, Burton, Ross ross.bur...@intel.com escreveu: On 8 November 2014 14:23, Brian Hutchinson b.hutch...@gmail.com wrote: I'm planning to just start excluding some of the packages in it ... I don't need sound, wireless, Bluetooth etc. If you don't need sound, wifi, and bluetooth then remove the relevant flags from DISTRO_FEATURES and they'll never be built. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Angstrom Build Failing
That's fine Samuel, I haven't the time to see if it works not due to being busy with school and kernel programming. Cheers Nick On 14-11-05 07:52 AM, Samuel Stirtzel wrote: 2014-10-31 19:41 GMT+01:00 nick xerofo...@gmail.com: Thanks Sven, I will git pull later and see if it's up again just wasn't sure if this was a network error or a misconfiguration on my part. Cheers Nick Sorry my fault, I have renamed the layer in gitorious in order to prevent confusion since there is another layer for the new KDE 5 stuff. For KDE4 there is: git://gitorious.org/openembedded-core-layers/meta-kde4.git KDE 5 / KDE Frameworks 5: https://github.com/e8johan/meta-kf5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Angstrom Build Fails
I am getting a failing build with the log below. If anyone knows how to fix
this it would be very helpful.
Cheers Nick
nick@nick-System-Product-Name:/media/nick/Build_Drive/setup-scripts$ time
MACHINE=beagleboard ./oebb.sh bitbake systemd-gnome-image
Using environment-angstrom-v2013.12 to setup needed variables. It is
recommended to do '. environment-angstrom-v2013.12' and run 'bitbake something'
without using ./oebb.sh as wrapper
Executing: MACHINE=beagleboard bitbake systemd-gnome-image
NOTE: Started PRServer with DBfile:
/media/nick/Build_Drive/setup-scripts/cache/prserv.sqlite3, IP: 127.0.0.1,
PORT: 57935, PID: 18666
WARNING: OPIE_VERSION has not been set; if you are going to build Opie, you
need to 'require' an appropriate .inc file from meta-opie/conf/distro/include
| ETA:
00:06:28
WARNING: OPIE_VERSION has not been set; if you are going to build Opie, you
need to 'require' an appropriate .inc file from meta-opie/conf/distro/include
| ETA:
00:06:18
WARNING: libgles-omap3-5.01.00.01 ONLY supports hardfp mode for
now
|
ETA: 00:02:40
WARNING: libgles-omap3-5.00.00.01 ONLY supports hardfp mode for now
WARNING: omap3-sgx-modules-5.01.00.01 ONLY supports hardfp mode for
now##
| ETA:
00:02:34
WARNING: omap3-sgx-modules-5.00.00.01 ONLY supports hardfp mode for now
WARNING: Unable to get checksum for lcr SRC_URI entry lcr-no_amr.diff: file
could not be
found
| ETA: 00:00:14
WARNING: Unable to get checksum for mono SRC_URI entry Makefile.am.diff: file
could not be
found##
| ETA: 00:00:10
WARNING: Unable to get checksum for mono SRC_URI entry config.in.diff: file
could not be found
WARNING: Unable to get checksum for mono SRC_URI entry Makefile.diff: file
could not be found
WARNING: Variable key FILES_${PN}-dev (${includedir} ${FILES_SOLIBSDEV}
${libdir}/*.la ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig
${datadir}/aclocal ${base_libdir}/*.o ${libdir}/${BPN}/*.la
${base_libdir}/*.la) replaces original key FILES_mono-xsp-dev (
/usr/lib/pkgconfig/xsp.pc /usr/lib/pkgconfig/xsp-2.pc ).
WARNING: Unable to get checksum for mono-native SRC_URI entry Makefile.am.diff:
file could not be found
WARNING: Unable to get checksum for mono-native SRC_URI entry config.in.diff:
file could not be found
WARNING: Unable to get checksum for mono-native SRC_URI entry Makefile.diff:
file could not be found
ERROR: Error executing a python function in
code:###
| ETA: 00:00:02
The stack trace of python calls that resulted in this exception/failure was:
File: 'code', lineno: 1, function: module
***
0001:__anon_634__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_base_bbclass(d)
0002:__anon_954__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_insane_bbclass(d)
0003:__anon_230__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_package_bbclass(d)
0004:__anon_430__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_package_ipk_bbclass(d)
0005:__anon_20__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_debian_bbclass(d)
File:
'__anon_634__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_base_bbclass',
lineno: 218, function:
__anon_634__media_nick_Build_Drive_setup_scripts_sources_openembedded_core_meta_classes_base_bbclass
0214:#
0215:override = d.getVar('SRC_URI_OVERRIDES_PACKAGE_ARCH', True)
0216:if override != '0':
0217:paths = []
*** 0218:fpaths = (d.getVar('FILESPATH', True) or '').split(':')
0219:machine = d.getVar('MACHINE', True)
0220:for p in fpaths:
0221:if os.path.basename(p) == machine and os.path.isdir(p):
0222:paths.append(p)
File:
'/media/nick/Build_Drive/setup-scripts/sources/bitbake/lib/bb/data_smart.py',
lineno: 516, function: getVar
0512:self._seen_overrides[override] = set()
0513:self._seen_overrides[override].add( var )
0514:
0515:def getVar(self, var, expand=False
Re: [yocto] Angstrom Build Fails
This isn't a network issue as I can fetch Yocto sources from other servers
without
any problems.
Cheers Nick
On 14-11-01 04:54 PM, Paul Eggleton wrote:
On Saturday 01 November 2014 19:55:47 Sven Ebenfeld wrote:
Looks like problems with gitorious.org again.
You should either find a mirror again or wait if the problem solves
itself. Unfortunately I don't know, which git repository this recipe
(opie) needs so I don't know if a mirror exists.
Am 01.11.2014 18:53, schrieb nick:
Exception: ExpansionError: Failure expanding variable SRCPV, expression
was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
Fetcher failure: Fetch command failed with exit code 128, output: fatal:
unable to connect to gitorious.org:
gitorious.org: Name or service not known
Name or service not known - that suggests a DNS failure - are you sure you
don't have local network issues?
Cheers,
Paul
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Angstrom Build Failing
Greetings, I am getting a failing build after cloning the angstrom build scripts. My build log is pasted below. Cheers Nick nick@nick-System-Product-Name:/media/nick/Build_Drive/setup-scripts$ MACHINE=beaglebone ./oebb.sh update Processing bitbake: Current branch 1.20 is up to date. Processing meta-angstrom: Current branch angstrom-v2013.12-yocto1.5 is up to date. Processing meta-openembedded: Current branch angstrom-staging-yocto1.5 is up to date. Processing meta-beagleboard: Current branch dora is up to date. Processing meta-ti: Current branch angstrom-staging-yocto1.5 is up to date. Processing meta-ettus: Fixed to revision 5a6a642f6707dc42a5210dbbf01d2bdfd869d4b0, skipping update Processing meta-fsl-arm: Current branch angstrom-staging-yocto1.5 is up to date. Processing meta-fsl-arm-extra: Current branch dora is up to date. Processing meta-nslu2: Fixed to revision bdcb4297ddb22f4eecddd4d8436cf9b6c6111922, skipping update Processing meta-smartphone: Fixed to revision 537d0c2ab41284012e1ba79716b085a861a6812a, skipping update Processing meta-intel: Current branch dora is up to date. Processing meta-xilinx: Fixed to revision 21c3cd3f058d736742ebc23a7a954f23456fbea5, skipping update Processing meta-openpandora: Fixed to revision 53ad3e60e4ed4fc7b946a2130da4bb9a8671341c, skipping update Processing meta-raspberrypi: Current branch dora is up to date. Processing meta-atmel: Current branch angstromv2013.12-staging is up to date. Processing meta-handheld: Fixed to revision 5b5e68a93aae1016f5ac1d057a721b2dbf30b8d8, skipping update Processing meta-opie: Fixed to revision b241408b31c2ffd941b8b38bd385136ef675a703, skipping update Processing meta-java: Current branch dora is up to date. Processing meta-browser: Fixed to revision fc3969f63bda343c38c40a23f746c560c4735f3e, skipping update Processing meta-mono: Fixed to revision ac286b1682e6bcc486ceb30ef90a936949bbfeab, skipping update layer repository name: meta-kde layer uri: git://gitorious.org/openembedded-core-layers/meta-kde.git layer branch/revision: master/f45abfd4d87b0132a2565499392d2d49f465d847 Layer checkout missing at /media/nick/Build_Drive/setup-scripts/sources/meta-kde, creating one Cloning into '/media/nick/Build_Drive/setup-scripts/sources/meta-kde'... fatal: protocol error: expected sha/ref, got ' -- Cannot find repository /openembedded-core-layers/meta-kde.git --' /media/nick/Build_Drive/setup-scripts/scripts/layerman: line 19: cd: /media/nick/Build_Drive/setup-scripts/sources/meta-kde: No such file or directory fatal: Could not parse object 'f45abfd4d87b0132a2565499392d2d49f465d847'. Layers present in repository: find: `/media/nick/Build_Drive/setup-scripts/sources/meta-kde': No such file or directory Processing meta-kde: /media/nick/Build_Drive/setup-scripts/scripts/layerman: line 79: cd: /media/nick/Build_Drive/setup-scripts/sources/meta-kde: No such file or directory Processing meta-linaro: Current branch dora is up to date. Processing meta-minnow: Current branch dora is up to date. Processing meta-sunxi: Fixed to revision f1e777d5526ea7c7a4f3a828b21d26c2c0650b83, skipping update Processing meta-qt5: Current branch dora is up to date. Processing meta-ros: Fixed to revision 64c8b5edb221263e7fac7c03629c730ade422dff, skipping update Processing meta-uav: Fixed to revision 6f663cc32532ae66dd6c06d3d79c0f3578975a6c, skipping update Processing meta-dominion: Current branch master is up to date. Processing meta-exynos: Fixed to revision ac21b106ce5c4c928f62e8f72ebeac9b02d113e2, skipping update Processing meta-telephony: Fixed to revision f71f5ea031d96a5a84bde4531974542ae49f8bee, skipping update Processing meta-qt5: Current branch dora is up to date. Processing openembedded-core: Current branch angstrom-staging-yocto1.5 is up to date. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Angstrom Build Failing
Thanks Sven, I will git pull later and see if it's up again just wasn't sure if this was a network error or a misconfiguration on my part. Cheers Nick On 14-10-31 02:29 PM, Sven Ebenfeld wrote: It looks like meta-kde on gitorious is currently down. Manually cloning its mirror on github in sources directory worked for me. Am 31.10.2014 18:49 schrieb nick xerofo...@gmail.com: Greetings, I am getting a failing build after cloning the angstrom build scripts. My build log is pasted below. Cheers Nick nick@nick-System-Product-Name:/media/nick/Build_Drive/setup-scripts$ MACHINE=beaglebone ./oebb.sh update Processing bitbake: Current branch 1.20 is up to date. Processing meta-angstrom: Current branch angstrom-v2013.12-yocto1.5 is up to date. Processing meta-openembedded: Current branch angstrom-staging-yocto1.5 is up to date. Processing meta-beagleboard: Current branch dora is up to date. Processing meta-ti: Current branch angstrom-staging-yocto1.5 is up to date. Processing meta-ettus: Fixed to revision 5a6a642f6707dc42a5210dbbf01d2bdfd869d4b0, skipping update Processing meta-fsl-arm: Current branch angstrom-staging-yocto1.5 is up to date. Processing meta-fsl-arm-extra: Current branch dora is up to date. Processing meta-nslu2: Fixed to revision bdcb4297ddb22f4eecddd4d8436cf9b6c6111922, skipping update Processing meta-smartphone: Fixed to revision 537d0c2ab41284012e1ba79716b085a861a6812a, skipping update Processing meta-intel: Current branch dora is up to date. Processing meta-xilinx: Fixed to revision 21c3cd3f058d736742ebc23a7a954f23456fbea5, skipping update Processing meta-openpandora: Fixed to revision 53ad3e60e4ed4fc7b946a2130da4bb9a8671341c, skipping update Processing meta-raspberrypi: Current branch dora is up to date. Processing meta-atmel: Current branch angstromv2013.12-staging is up to date. Processing meta-handheld: Fixed to revision 5b5e68a93aae1016f5ac1d057a721b2dbf30b8d8, skipping update Processing meta-opie: Fixed to revision b241408b31c2ffd941b8b38bd385136ef675a703, skipping update Processing meta-java: Current branch dora is up to date. Processing meta-browser: Fixed to revision fc3969f63bda343c38c40a23f746c560c4735f3e, skipping update Processing meta-mono: Fixed to revision ac286b1682e6bcc486ceb30ef90a936949bbfeab, skipping update layer repository name: meta-kde layer uri: git://gitorious.org/openembedded-core-layers/meta-kde.git layer branch/revision: master/f45abfd4d87b0132a2565499392d2d49f465d847 Layer checkout missing at /media/nick/Build_Drive/setup-scripts/sources/meta-kde, creating one Cloning into '/media/nick/Build_Drive/setup-scripts/sources/meta-kde'... fatal: protocol error: expected sha/ref, got ' -- Cannot find repository /openembedded-core-layers/meta-kde.git --' /media/nick/Build_Drive/setup-scripts/scripts/layerman: line 19: cd: /media/nick/Build_Drive/setup-scripts/sources/meta-kde: No such file or directory fatal: Could not parse object 'f45abfd4d87b0132a2565499392d2d49f465d847'. Layers present in repository: find: `/media/nick/Build_Drive/setup-scripts/sources/meta-kde': No such file or directory Processing meta-kde: /media/nick/Build_Drive/setup-scripts/scripts/layerman: line 79: cd: /media/nick/Build_Drive/setup-scripts/sources/meta-kde: No such file or directory Processing meta-linaro: Current branch dora is up to date. Processing meta-minnow: Current branch dora is up to date. Processing meta-sunxi: Fixed to revision f1e777d5526ea7c7a4f3a828b21d26c2c0650b83, skipping update Processing meta-qt5: Current branch dora is up to date. Processing meta-ros: Fixed to revision 64c8b5edb221263e7fac7c03629c730ade422dff, skipping update Processing meta-uav: Fixed to revision 6f663cc32532ae66dd6c06d3d79c0f3578975a6c, skipping update Processing meta-dominion: Current branch master is up to date. Processing meta-exynos: Fixed to revision ac21b106ce5c4c928f62e8f72ebeac9b02d113e2, skipping update Processing meta-telephony: Fixed to revision f71f5ea031d96a5a84bde4531974542ae49f8bee, skipping update Processing meta-qt5: Current branch dora is up to date. Processing openembedded-core: Current branch angstrom-staging-yocto1.5 is up to date. -- ___ 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] Failing Build
I tried that and it didn't work. Cheers Nick On 14-10-24 04:34 AM, Richard Purdie wrote: On Thu, 2014-10-23 at 22:46 -0400, nick wrote: Greetings Fellow Yocto Developers and Users, I am getting a failing build with bitbake core-image-rt-sdk on qemux86 or qemux86_64 machine builds. I'm guessing you've built a non-rt image, then built an -rt image and the two have become confused since the kernel changed. Wiping out the tmpdir and rebuilding (but leaving DL_DIR and SSTATE_DIR) will probably avoid this error. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Failing Build
Thanks Ross, Sorry about not reading the manual first, I thought it was a misconfiguration but wasn't sure. Cheers Nick On 14-10-24 07:14 AM, Burton, Ross wrote: On 24 October 2014 12:12, Burton, Ross ross.bur...@intel.com wrote: On 24 October 2014 12:00, Mihail, StanciuX stanciux.mih...@intel.com wrote: Looks to me that the core-image-rt-sdk recipe includes both the rt-kernel and the normal kernel, and maybe it shouldn't? FWIW, I appear to be able to replicate this with just core-image-rt. This is a case of RTFM. In order to build the image with the linux-yocto-rt kernel, be sure to include the following line in your local.conf, bblayers.conf, or your $MACHINE.conf. PREFERRED_PROVIDER_virtual/kernel = linux-yocto-rt Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Failing Build
Greetings Fellow Yocto Developers and Users, I am getting a failing build with bitbake core-image-rt-sdk on qemux86 or qemux86_64 machine builds. Further more I am posting my failing build messages below, I am assuming it's a misconfiguration or a bug related to qemux86 or Intel platforms. Cheers and Thanks for the Help, Nick /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/cordic.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/cpu-notifier-error-inject.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/cpu_rmap.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/cpumask.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc-ccitt.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc-itu-t.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc-t10dif.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc16.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc32.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc32defs.h Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc7.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/crc8.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/ctype.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/debug_locks.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/dec_and_lock.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress_bunzip2.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress_inflate.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress_unlz4.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress_unlzma.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress_unlzo.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/decompress_unxz.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/devres.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/digsig.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/div64.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/dma-debug.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/dump_stack.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/dynamic_debug.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/dynamic_queue_limits.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/earlycpio.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr/src/kernel/lib/extable.c Matched in manifest-qemux86-linux-yocto.populate_sysroot /media/nick/Build_Drive/poky/build/tmp/sysroots/qemux86/usr
[yocto] Time To Build Yocto
I am wondering from your experience how long is the largest build you have ever seen and what was it building. I am considering a high powered build system for Yocto and want to known about build times in order to help me with purchasing decisions. Cheers Nick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Time To Build Yocto
Thanks Chris, I was wondering if a i7 was worth it seems it is and yes for the matter, I did have issues with the kernel community and trying to work then out. Nick On 14-10-22 03:59 PM, Chris Tapp wrote: On 20 Oct 2014, at 21:44, nick xerofo...@gmail.com wrote: I am wondering from your experience how long is the largest build you have ever seen and what was it building. I am considering a high powered build system for Yocto and want to known about build times in order to help me with purchasing decisions. There was a recent thread discussing this - have a look at https://lists.yoctoproject.org/pipermail/yocto/2014-October/021808.html You need to start by working out what you'll be spending most of your time doing - full image builds, incremental images, single recipes, etc. My build system has an i7-3820 overclocked to 4.6 GHz with 16 GB RAM and SSDs. It takes about an hour to build an X11 image from scratch (no shared state, source already downloaded). I could reduce the build time to about 25 minutes by upgrading to a new CPU (12 core, 24 threads) for $2700 - once you have your use-case you can do the math to work out what the payback time will be ;-) -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: [meta-security][PATCH] nmap: inherit autotools-brokensep to allow B=S build.
-- Forwarded message --
From: Nick D'Ademo nickdad...@gmail.com
Date: Wed, May 7, 2014 at 8:26 AM
Subject: Re: [meta-security][PATCH] nmap: inherit autotools-brokensep to
allow B=S build.
To: Yocto list discussion yocto@yoctoproject.org
This is a resubmission - added required blank line between subject and SOB.
On Wed, May 7, 2014 at 8:24 AM, Nick D'Ademo nickdad...@gmail.com wrote:
Signed-off-by: Nick D'Ademo nickdad...@gmail.com
---
recipes-security/nmap/nmap_6.25.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/nmap/nmap_6.25.bb b/recipes-security/nmap/
nmap_6.25.bb
index aff5c63..5efcc70 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.25.bb
@@ -11,7 +11,7 @@ SRC_URI = http://nmap.org/dist/${PN}-${PV}.tar.bz2 \
SRC_URI[md5sum] = fcc80f94ff3adcb11eedf91092ea6f5e
SRC_URI[sha256sum] =
3349cc6d36b86b95ca2b8075d16615a3a598cef494920d6652f9a8bf9f7660b5
-inherit autotools
+inherit autotools-brokensep
DEPENDS = libpcap
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] nmap: inherit autotools-brokensep to allow B=S build. Signed-off-by: Nick D'Ademo nickdad...@gmail.com
---
recipes-security/nmap/nmap_6.25.bb |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/recipes-security/nmap/nmap_6.25.bb
b/recipes-security/nmap/nmap_6.25.bb
index aff5c63..0c70fd3 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.25.bb
@@ -11,7 +11,7 @@ SRC_URI = http://nmap.org/dist/${PN}-${PV}.tar.bz2 \
SRC_URI[md5sum] = fcc80f94ff3adcb11eedf91092ea6f5e
SRC_URI[sha256sum] =
3349cc6d36b86b95ca2b8075d16615a3a598cef494920d6652f9a8bf9f7660b5
-inherit autotools
+inherit autotools-brokensep
DEPENDS = libpcap
@@ -20,5 +20,4 @@ EXTRA_OECONF = --without-liblua --without-zenmap
--without-subversion --with-pc
do_configure() {
autoconf
oe_runconf
-}
-
+}
\ No newline at end of file
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] nmap: inherit autotools-brokensep to allow B=S build. Signed-off-by: Nick D'Ademo nickdad...@gmail.com
---
recipes-security/nmap/nmap_6.25.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/nmap/nmap_6.25.bb
b/recipes-security/nmap/nmap_6.25.bb
index aff5c63..5efcc70 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.25.bb
@@ -11,7 +11,7 @@ SRC_URI = http://nmap.org/dist/${PN}-${PV}.tar.bz2 \
SRC_URI[md5sum] = fcc80f94ff3adcb11eedf91092ea6f5e
SRC_URI[sha256sum] =
3349cc6d36b86b95ca2b8075d16615a3a598cef494920d6652f9a8bf9f7660b5
-inherit autotools
+inherit autotools-brokensep
DEPENDS = libpcap
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] nmap: inherit autotools-brokensep to allow B=S build.
Signed-off-by: Nick D'Ademo nickdad...@gmail.com
---
recipes-security/nmap/nmap_6.25.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/nmap/nmap_6.25.bb
b/recipes-security/nmap/nmap_6.25.bb
index aff5c63..5efcc70 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.25.bb
@@ -11,7 +11,7 @@ SRC_URI = http://nmap.org/dist/${PN}-${PV}.tar.bz2 \
SRC_URI[md5sum] = fcc80f94ff3adcb11eedf91092ea6f5e
SRC_URI[sha256sum] =
3349cc6d36b86b95ca2b8075d16615a3a598cef494920d6652f9a8bf9f7660b5
-inherit autotools
+inherit autotools-brokensep
DEPENDS = libpcap
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] nmap: inherit autotools-brokensep to allow B=S build.
This is a resubmission - added required blank line between subject and SOB.
On Wed, May 7, 2014 at 8:24 AM, Nick D'Ademo nickdad...@gmail.com wrote:
Signed-off-by: Nick D'Ademo nickdad...@gmail.com
---
recipes-security/nmap/nmap_6.25.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/nmap/nmap_6.25.bb b/recipes-security/nmap/
nmap_6.25.bb
index aff5c63..5efcc70 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.25.bb
@@ -11,7 +11,7 @@ SRC_URI = http://nmap.org/dist/${PN}-${PV}.tar.bz2 \
SRC_URI[md5sum] = fcc80f94ff3adcb11eedf91092ea6f5e
SRC_URI[sha256sum] =
3349cc6d36b86b95ca2b8075d16615a3a598cef494920d6652f9a8bf9f7660b5
-inherit autotools
+inherit autotools-brokensep
DEPENDS = libpcap
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: autogen-native recipe compilation error (since upgrade to 5.18.2)
Forwarded to Yocto List
-- Forwarded message --
From: Nick D'Ademo nickdad...@gmail.com
Date: Sun, Jan 12, 2014 at 3:32 PM
Subject: autogen-native recipe compilation error (since upgrade to 5.18.2)
To: p...@yoctoproject.org
Cc: liezhi.y...@windriver.com, richard.pur...@linuxfoundation.org
Since the recent commit: autogen-native: upgrade to 5.18.2 (
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/autogen?id=0cfb1e7a9f8349def5da787d3a284ac6d18ca55d
)
Compilation of the autogen-native recipe is broken for me.
Anyone have any ideas on this?
Many thanks in advance.
(Target machine is the Intel NUC).
*Error message as follows:*
ERROR: Function failed: do_compile (log file is located at
/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/temp/log.do_compile.16605)
ERROR: Logfile of failure stored in:
/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/temp/log.do_compile.16605
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8
| /bin/sh config/mk-shdefs config/shdefs
| config.status: creating shdef-temp
| make all-recursive
| make[1]: Entering directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build'
| Making all in compat
| make[2]: Entering directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/compat'
| :
| make[2]: Leaving directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/compat'
| Making all in snprintfv
| make[2]: Entering directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/snprintfv'
| for f in filament.c format.c printf.c mem.c stream.c custom.c ; do echo
#include \$f\ ; done snv.c
| ../i686-linux-libtool --tag=CC --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I.
-I/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2/snprintfv
-I..
-I/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include -O2 -pipe
-c -o snv.lo snv.c
| i686-linux-libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2/snprintfv
-I..
-I/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include -O2 -pipe
-c snv.c -fPIC -DPIC -o .libs/snv.o
| i686-linux-libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2/snprintfv
-I..
-I/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include -O2 -pipe
-c snv.c -o snv.o /dev/null 21
| ../i686-linux-libtool --tag=CC --mode=link gcc -std=gnu99
-isystem/home/nick/poky/build/tmp/sysroots/i686-linux/usr/include -O2 -pipe
-no-undefined -L/home/nick/poky/build/tmp/sysroots/i686-linux/usr/lib
-L/home/nick/poky/build/tmp/sysroots/i686-linux/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/i686-linux/usr/lib
-Wl,-rpath-link,/home/nick/poky/build/tmp/sysroots/i686-linux/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/i686-linux/usr/lib
-Wl,-rpath,/home/nick/poky/build/tmp/sysroots/i686-linux/lib -Wl,-O1 -o
libsnprintfv.la snv.lo -lm -ldl
| i686-linux-libtool: link: ar cru .libs/libsnprintfv.a .libs/snv.o
| i686-linux-libtool: link: ranlib .libs/libsnprintfv.a
| i686-linux-libtool: link: ( cd .libs rm -f libsnprintfv.la ln
-s ../libsnprintfv.la libsnprintfv.la )
| make[2]: Leaving directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/snprintfv'
| Making all in autoopts
| make[2]: Entering directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/autoopts'
| rm -f stdnoreturn.h-t stdnoreturn.h \
| { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' \
| sed -e '/definition of _Noreturn/r
/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2/config/snippet/_Noreturn.h'
\
|
/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/autogen-5.18.2/autoopts/stdnoreturn.in.h;
\
| } stdnoreturn.h-t \
| mv stdnoreturn.h-t stdnoreturn.h
| make all-recursive
| make[3]: Entering directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/autoopts'
| Making all in test
| make[4]: Entering directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/autoopts/test'
| make[4]: Nothing to be done for `all'.
| make[4]: Leaving directory
`/home/nick/poky/build/tmp/work/i686-linux/autogen-native/5.18.2-r0/build/autoopts/test'
| make[4]: Entering directory
Re: [yocto] Creating a EXT4 rootfs instead of EXT3: How?
Thanks for the reply Nicolas. It seems the problem is that .hddimg uses EXT3 by default (after looking at image_types.bbclass). The ROOTFS type for my build is set in /meta/conf/machine/include/ia32-base.inc: IMAGE_FSTYPES += live Is there a way to make the HDDIMG use EXT4 instead? Thanks, Nick On Wed, Jan 8, 2014 at 12:24 AM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Tue, Jan 7, 2014 at 2:19 PM, Nick D'Ademo nickdad...@gmail.com wrote: Can't seem to get the build process to create a EXT4 filesystem - I've tried the following: in general, more details about the actual error you get would be more helpful. 1. Tried adding ROOTFSTYPE ?= *ext4* to the machine .conf file the variable name is IMAGE_FSTYPES, not ROOTFSTYPES. 2. Ensured EXT4 is enabled in the Linux kernel (using menuconfig) this would not impact the image generation, only at runtime when mounting the rootfs This is a build for the Intel NUC hardware. Anyone have any ideas on how to do this? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Creating a EXT4 rootfs instead of EXT3: How?
Can't seem to get the build process to create a EXT4 filesystem - I've tried the following: 1. Tried adding ROOTFSTYPE ?= *ext4* to the machine .conf file 2. Ensured EXT4 is enabled in the Linux kernel (using menuconfig) This is a build for the Intel NUC hardware. Anyone have any ideas on how to do this? Many thanks. Nick ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] MULTILIB builds with Yocto: Status?
*A follow up to this (after further testing with the Yocto image classes - i.e. not my own custom image):* *After adding the following to local.conf (keeping all other variables to their defaults):* require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = x86 *Using the following Build configuration:* BB_VERSION= 1.21.0 BUILD_SYS = i686-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= x86_64-poky-linux MACHINE = nuc DISTRO= poky DISTRO_VERSION= 1.5+snapshot-20131124 TUNE_FEATURES = m64 TARGET_FPU= meta meta-yocto meta-yocto-bsp= master:6a8307c35705bf6c9f49c368dd730deef3d2ae15 meta-intel meta-nuc = master:f5c2786e7ca190308523379706130e0c2be793c9 *The MULTILIB build is successful with the following images:* core-image-minimal core-image-base core-image-sato As stated in the meta-nuc README, I then also added the following to local.conf to enable hardware video acceleration: LICENSE_FLAGS_WHITELIST += commercial *Retrying the core-image-sato image build now results in errors:* *ERROR: QA Issue: x264: Files/directories were installed but not shipped /usr/lib /usr/lib/libx264.so.133 /usr/lib/libx264.so /usr/lib/libx264.a /usr/lib/pkgconfig /usr/lib/.debug /usr/lib/pkgconfig/x264.pc /usr/lib/.debug/libx264.so.133ERROR: QA run found fatal errors. Please consider fixing them. ERROR: Function failed: do_package_qaERROR: Logfile of failure stored in: /home/nick/poky/test/tmp/work/x86_64-poky-linux/x264/r2265+gitAUTOINC+585324fee3-r0/temp/log.do_package.11458ERROR: Task 4913 (/home/nick/poky/meta/recipes-multimedia/x264/x264_git.bb http://x264_git.bb, do_package) failed with exit code '1' ERROR: Function failed: do_configure (log file is located at /home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/log.do_configure.11457)ERROR: Logfile of failure stored in: /home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/log.do_configure.11457 Log data follows:| DEBUG: Executing python function sysroot_cleansstate| DEBUG: Python function sysroot_cleansstate finished| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common'] | DEBUG: Executing shell function autotools_preconfigure| DEBUG: Shell function autotools_preconfigure finished| DEBUG: Executing shell function do_configure| ERROR: libx264 not found| | If you think configure made a mistake, make sure you are using the latest | version from Git. If the latest version fails, report the problem to the| libav-u...@libav.org libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net http://irc.freenode.net. | Include the log file config.log produced by configure as this will help| solving the problem.| WARNING: /home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/run.do_configure.11457:1 exit 1 from | /home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/libav-0.8.8/configure --enable-shared --enable-pthreads --enable-gpl --enable-avfilter --cross-prefix=x86_64-poky-linux- --prefix=/usr --enable-avserver --enable-avplay --enable-libtheora --enable-libvorbis --arch=x86_64 --target-os=linux --enable-cross-compile --extra-cflags= -O2 -pipe -g -feliminate-unused-debug-types -m64 --sysroot=/home/nick/poky/test/tmp/sysroots/nuc --extra-ldflags=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed --sysroot=/home/nick/poky/test/tmp/sysroots/nuc --enable-hardcoded-tables --enable-postproc --enable-bzlib --disable-libfaac --disable-libgsm --disable-indev=jack --disable-libmp3lame --disable-libschroedinger --disable-libvpx --enable-x11grab --enable-libx264 | ERROR: Function failed: do_configure (log file is located at /home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/log.do_configure.11457)ERROR: Task 3456 (/home/nick/poky/meta/recipes-multimedia/libav/libav_0.8.8.bb http://libav_0.8.8.bb, do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 5748 tasks of which 5744 didn't need to be rerun and 2 failed.No currently running tasks (5748 of 5775)Summary: 2 tasks failed: /home/nick/poky/meta/recipes-multimedia/x264/x264_git.bb http://x264_git.bb, do_package /home/nick/poky/meta/recipes-multimedia/libav/libav_0.8.8.bb http://libav_0.8.8.bb, do_configureSummary: There were 4 ERROR messages shown, returning a non-zero exit code.* *This appears to be a bug with the libx264 recipe.* Any thoughts or comments on this? Has anyone else tried MULTILIB builds with the NUC hardware (with hardware acceleration enabled)? Thanks, Nick On Thu, Nov 21, 2013 at 1:17 AM, Nick D'Ademo nickdad...@gmail.com wrote: From what I've read so far, by adding the following to the local.conf file (e.g. for a x86_64 build; in my case for the Intel NUC machine), Yocto will build an image which also contains 32-bit compiled system libraries (+ any 32-bit packages/recipes you have specified): require conf
Re: [yocto] MULTILIB builds with Yocto: Status?
Found the fix for these issues:
*The two offending Poky recipes are:*
recipes-multimedia/x264
recipes-multimedia/libav
*Files which need to be modified:*
x264_git.bb - Add --libdir=${libdir} to EXTRA_OECONF variable
libav.inc - Add --libdir=${libdir} AND --shlibdir=${libdir} to
EXTRA_OECONF variable
As you can see from the above fixes, the issue was that the configure step
was passing usr/lib instead of usr/lib64 which ultimately caused the
installed but not shipped errors.
Are these actually bugs which should be patched in the recipes?
Nick
On Sun, Nov 24, 2013 at 8:53 PM, Nick D'Ademo nickdad...@gmail.com wrote:
*A follow up to this (after further testing with the Yocto image classes -
i.e. not my own custom image):*
*After adding the following to local.conf (keeping all other variables to
their defaults):*
require conf/multilib.conf
MULTILIBS = multilib:lib32
DEFAULTTUNE_virtclass-multilib-lib32 = x86
*Using the following Build configuration:*
BB_VERSION= 1.21.0
BUILD_SYS = i686-linux
NATIVELSBSTRING = Ubuntu-12.04
TARGET_SYS= x86_64-poky-linux
MACHINE = nuc
DISTRO= poky
DISTRO_VERSION= 1.5+snapshot-20131124
TUNE_FEATURES = m64
TARGET_FPU=
meta
meta-yocto
meta-yocto-bsp= master:6a8307c35705bf6c9f49c368dd730deef3d2ae15
meta-intel
meta-nuc = master:f5c2786e7ca190308523379706130e0c2be793c9
*The MULTILIB build is successful with the following images:*
core-image-minimal
core-image-base
core-image-sato
As stated in the meta-nuc README, I then also added the following to
local.conf to enable hardware video acceleration:
LICENSE_FLAGS_WHITELIST += commercial
*Retrying the core-image-sato image build now results in errors:*
*ERROR: QA Issue: x264: Files/directories were installed but not shipped
/usr/lib /usr/lib/libx264.so.133 /usr/lib/libx264.so /usr/lib/libx264.a
/usr/lib/pkgconfig /usr/lib/.debug /usr/lib/pkgconfig/x264.pc
/usr/lib/.debug/libx264.so.133ERROR: QA run found fatal errors. Please
consider fixing them. ERROR: Function failed: do_package_qaERROR: Logfile
of failure stored in:
/home/nick/poky/test/tmp/work/x86_64-poky-linux/x264/r2265+gitAUTOINC+585324fee3-r0/temp/log.do_package.11458ERROR:
Task 4913 (/home/nick/poky/meta/recipes-multimedia/x264/x264_git.bb
http://x264_git.bb, do_package) failed with exit code '1' ERROR: Function
failed: do_configure (log file is located at
/home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/log.do_configure.11457)ERROR:
Logfile of failure stored in:
/home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/log.do_configure.11457
Log data follows:| DEBUG: Executing python function sysroot_cleansstate|
DEBUG: Python function sysroot_cleansstate finished| DEBUG: SITE files
['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux',
'common'] | DEBUG: Executing shell function autotools_preconfigure| DEBUG:
Shell function autotools_preconfigure finished| DEBUG: Executing shell
function do_configure| ERROR: libx264 not found| | If you think configure
made a mistake, make sure you are using the latest | version from Git. If
the latest version fails, report the problem to the| libav-u...@libav.org
libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net
http://irc.freenode.net. | Include the log file config.log produced by
configure as this will help| solving the problem.| WARNING:
/home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/run.do_configure.11457:1
exit 1 from |
/home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/libav-0.8.8/configure
--enable-shared --enable-pthreads --enable-gpl --enable-avfilter
--cross-prefix=x86_64-poky-linux- --prefix=/usr --enable-avserver
--enable-avplay --enable-libtheora --enable-libvorbis --arch=x86_64
--target-os=linux --enable-cross-compile --extra-cflags= -O2 -pipe -g
-feliminate-unused-debug-types -m64
--sysroot=/home/nick/poky/test/tmp/sysroots/nuc --extra-ldflags=-Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed
--sysroot=/home/nick/poky/test/tmp/sysroots/nuc --enable-hardcoded-tables
--enable-postproc --enable-bzlib --disable-libfaac --disable-libgsm
--disable-indev=jack --disable-libmp3lame --disable-libschroedinger
--disable-libvpx --enable-x11grab --enable-libx264 | ERROR: Function
failed: do_configure (log file is located at
/home/nick/poky/test/tmp/work/x86_64-poky-linux/libav/0.8.8-r0/temp/log.do_configure.11457)ERROR:
Task 3456 (/home/nick/poky/meta/recipes-multimedia/libav/libav_0.8.8.bb
http://libav_0.8.8.bb, do_configure) failed with exit code '1' NOTE:
Tasks Summary: Attempted 5748 tasks of which 5744 didn't need to be rerun
and 2 failed.No currently running tasks (5748 of 5775)Summary: 2 tasks
failed: /home/nick/poky/meta/recipes-multimedia/x264/x264_git.bb
http://x264_git.bb, do_package
/home/nick/poky/meta/recipes-multimedia
[yocto] MULTILIB builds with Yocto: Status?
From what I've read so far, by adding the following to the local.conf file (e.g. for a x86_64 build; in my case for the Intel NUC machine), Yocto will build an image which also contains 32-bit compiled system libraries (+ any 32-bit packages/recipes you have specified): require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = x86 However, running BitBake with the above added to local.conf results in a large number of build errors. To name a few: grub_2.0.0.bb: ... | checking whether the C compiler works... no | configure: error: in `/home/nick/poky/build/tmp/work/x86_64-poky-linux/grub/2.00-r1/build': | configure: error: C compiler cannot create executables ... ntp_4.2.6p5.bb: ... | configure: exit 77 | ERROR: oe_runconf failed ... Is there something I'm missing here? What is the status of MULTILIB support with Yocto? Has anyone attempted it lately? [The following guide seems a little outdated: https://wiki.yoctoproject.org/wiki/Multilib] Thanks, Nick ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Supported Kernel Versions
What is the latest combination of Yocto/Pocky that supports 3.2? I noticed that 3.4 is the minimum supported in the latest. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
