On Tue, Aug 27, 2013 at 05:10:42PM -0700, Paul D. DeRocco wrote:
> > From: Gary Thomas
> >
> > As far as I understand, the 'do_rootfs' step in building an
> > image is basically
> > equivalent to running "${PKG_MGR} install
> > ", where PKG_MGR
> > is your package management method of choice - i
Hi everyone !
I tried to share the "shared-state" folder on a build server for several
people working on the same project. But I meet some unexpected problems,
like errors callings the native dpkg tool.
So I'm back to the basic question :-) Is it possible to share this cache
between developers or
Hi,
Following is my image file to generate rootfs image with SDK having Qt
support..
I am able to build SDK successfully but on building any Qt application with
generated SDK getting following error message-
/opt/poky/1.3.2/sysroots/EBboard-poky-linux-gnueabi//usr/include/qtopia/QtCore/qglobal.h:
Hi all,
I'm trying to install package-core-buildessential in my target (using
smart in my target) but it complains about:
error: Can't install libc6-dev-2.17-r3@armv7a_vfp_neon: no package
provides eglibc-thread-db-dev
Digging around it, I found that package should provide (eglibc-package.inc):
Hi Amit,
On Wednesday 28 August 2013 09:05:28 Amit Kumar wrote:
> I wants to build the recipes name linphone(SIP-based IP phone) with
> poky-9.0.0 build environment. I found he linphone recipes under the
> "angstrom-openembedded". In my poky build environment I have created the
> new layer, n
Am 2013-08-27 17:19, schrieb Glenn Schmottlach:
I'm trying to figure out the syntax for specifying more than one URI
in a single PREMIRROR statement, e.g.
PREMIRRORS_append = "git://.*/.* file://toplevel/premirror
ftp://ftp.acme.com/pre_mirror/foo [1] n"
So for all "git" fetches I want it to *f
> From: Martin Jansa
>
> Are you sure that you're not building some unnecessary IMAGE_FSTYPES?
No, I'm not sure.
> Last time someone asked my why it takes so long I've added some debug
> output to do_rootfs and found out that only half of the time was opkg
> installing packages and the rest was
2013/8/28 Paul D. DeRocco :
>> From: Martin Jansa
>>
>> Are you sure that you're not building some unnecessary IMAGE_FSTYPES?
>
> No, I'm not sure.
>
>> Last time someone asked my why it takes so long I've added some debug
>> output to do_rootfs and found out that only half of the time was opkg
>>
On 2013-08-27 18:10, Paul D. DeRocco wrote:
From: Gary Thomas
As far as I understand, the 'do_rootfs' step in building an
image is basically
equivalent to running "${PKG_MGR} install
", where PKG_MGR
is your package management method of choice - ipk or rpm.
This seems to me to
be a very single-t
2013/8/28 Samuel Stirtzel :
> 2013/8/28 Paul D. DeRocco :
>>> From: Martin Jansa
>>>
>>> Are you sure that you're not building some unnecessary IMAGE_FSTYPES?
>>
>> No, I'm not sure.
>>
>>> Last time someone asked my why it takes so long I've added some debug
>>> output to do_rootfs and found out t
On 28 August 2013 11:55, Gary Thomas wrote:
>
> Not quite - you build the packages (recipes) on your build host, but manage
> them directly on your target hardware. Of course, this assumes that your
> build host and target hardware are network connected.
>
I threw together a minimal Raspberry Pi
On Wednesday 28 August 2013 13:23:04 Navani Srivastava wrote:
> Following is my image file to generate rootfs image with SDK having Qt
> support..
> I am able to build SDK successfully but on building any Qt application with
> generated SDK getting following error message-
>
> /opt/poky/1.3.2/sysr
Hi, I am a little bit confused about how to handle these two and what
they are supposed to solve. I have so far never used RDEPENDS but only
DEPENDS.
But I am also having severe problems when building a rootfs image when
one of my user space libraries are changed from eg. libfoo.so.1 to
libfoo.so.3
I just removed qt stuff and tried with the SDK built with 'bitbake -c
populate_sdk poky-image' . I just compiled a simple program which includes
stdio.h, while compiling got error that "stdio.h: No such file or
directory" ..
It seems problem is with SDK generated with it. But I am not able to
under
Hi Hans,
On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
> Hi, I am a little bit confused about how to handle these two and what
> they are supposed to solve. I have so far never used RDEPENDS but only
> DEPENDS.
DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means
I am looking to build for MPC8572 with Dylan and checked out the
meta-fsl-ppc BSP layer. Seems like support for that machine was removed in
May [1]. The reason given was " *u-boot code base can not support mpc85xx
for sdk 1.3.2". Howerver, that was contested in a follow-up e-mail.
Interestingly, th
Hi Scott,
I noticed that the yocto reference manual is missing entries
for MACHINE_DEVICETREE and KERNEL_DEVICETREE variables.
I was trying to find out what the difference between the two were, and
discovered that it's not described in the reference manual here:
http://www.yocto
Hello all, Im newbi with linux embedded. I bought a mini2440 boards and I
downloaded the yocto project. I found some recipes for the same board from
this guy.
https://github.com/sakhnik/meta-mini2440
I have a kernel built for mini2440, and the
core-image-sato-mini2440.rootfs.tar.bz2
I have some q
On 13-08-28 01:48 PM, Elvis Dowson wrote:
Hi,
I just don't understand how to work with the linux-yocto kernel.
For example, I created a local copy of the yocto kernel, and updated the
linux-yocto_3.8.bb recipe to point to the local copy
(git:///;protocol=file, etc)
Then I created a local
Hi,
I just don't understand how to work with the linux-yocto kernel.
For example, I created a local copy of the yocto kernel, and updated the
linux-yocto_3.8.bb recipe to point to the local copy
(git:///;protocol=file, etc)
Then I created a local branch meta, and another local branch stand
Hi Bruce,
On Aug 28, 2013, at 9:52 PM, Bruce Ashfield
wrote:
> There were some old bugs which caused the wrong board description to
> be picked up, the seems similar.
>
> But without seeing your exact changes, as they sit in the tree, I
> can't be sure.
>
> Did you also update the meta and ma
On 13-08-28 02:05 PM, Elvis Dowson wrote:
Hi Bruce,
On Aug 28, 2013, at 9:52 PM, Bruce Ashfield
wrote:
There were some old bugs which caused the wrong board description to
be picked up, the seems similar.
But without seeing your exact changes, as they sit in the tree, I
can't be sure.
Did
On Aug 28, 2013, at 10:07 PM, Bruce Ashfield
wrote:
> On 13-08-28 02:05 PM, Elvis Dowson wrote:
>> Hi Bruce,
>>
>> On Aug 28, 2013, at 9:52 PM, Bruce Ashfield
>> wrote:
>>
>>> There were some old bugs which caused the wrong board description to
>>> be picked up, the seems similar.
>>>
>>>
This is the meta cfg/scc for building from the standard/axxia/base
and preempt-rt branches.
David Mercado (1):
meta: Add LSI axm5500sim and elpaso
.../bsp/axm5500sim/axm5500sim-preempt-rt.cfg | 19 +
.../bsp/axm5500sim/axm5500sim-preempt-rt.scc | 9 +
.../bsp/axm5500sim/axm55
From: David Mercado
Adds cfg/scc support for the LSI axm5500sim and elpaso bsps.
Signed-off-by: David Mercado
Signed-off-by: Paul Butler
---
.../bsp/axm5500sim/axm5500sim-preempt-rt.cfg | 19 +
.../bsp/axm5500sim/axm5500sim-preempt-rt.scc | 9 +
.../bsp/axm5500sim/axm5500sim-st
On 2013-08-28 6:06, Paul Eggleton wrote:
Hi Hans,
On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
Hi, I am a little bit confused about how to handle these two and what
they are supposed to solve. I have so far never used RDEPENDS but only
DEPENDS.
DEPENDS means a build-time dependenc
This reverts commit 60cf7ea849e77c8782dee147cfb8c38d1984236e.
This is a temporary workaround for the dropbearkey hang issue in 3.10.
---
kernel/time/timer_list.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/kernel/time/timer_list.c b/kernel/time/timer
This reverts commit b3956a896ea57f25cacd74708b8fab611543a81d.
This is a temporary workaround for the dropbearkey hang issue in 3.10.
---
kernel/time/timer_list.c | 89 +++-
1 file changed, 12 insertions(+), 77 deletions(-)
diff --git a/kernel/time/time
The following reverts fix the problem outlined in [Yocto #5062], which
manifested as a dropbearkey hang:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5062
This is a temporary fix and this particular branch contains only a revert
for common-pc-64-base, but the same revert should be done repo
On Tue, Aug 27, 2013 at 6:56 PM, Brian Hutchinson wrote:
> Hi,
>
> I need mgetty and don't see it anywhere in any of the OE core based
> layers. Did something replace it? I'm trying to migrate some OE classic
> work to OE core based distros.
>
> Regards,
>
> Brian
>
Ping! I'll take that as a "
On 08/28/2013 03:19 PM, Brian Hutchinson wrote:
On Tue, Aug 27, 2013 at 6:56 PM, Brian Hutchinson
mailto:b.hutch...@gmail.com>> wrote:
Hi,
I need mgetty and don't see it anywhere in any of the OE core
based layers. Did something replace it? I'm trying to migrate
some OE class
I jumped the gun and pushed a tag a few moments ago (1.5_M4.rc1). I've
deleted this tag, so folks should git fetch --prune --tags if you've
pulled in the past few moments.
-b
--
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
On Wed, Aug 28, 2013 at 9:22 PM, Hans Beckerus wrote:
> Well, I have been struggling before with packages not properly supporting
> different build and source folders so I can definitely relate to what you
> are saying. But, does that mean I actually *have* to do it this way for
> build dependenci
On Aug 28, 2013 4:39 PM, "Peter A. Bigot" wrote:
>
> On 08/28/2013 03:19 PM, Brian Hutchinson wrote:
>>
>> On Tue, Aug 27, 2013 at 6:56 PM, Brian Hutchinson
wrote:
>>>
>>> Hi,
>>>
>>> I need mgetty and don't see it anywhere in any of the OE core based
layers. Did something replace it? I'm tryin
> From: Nicolas Dechesne
>
> if the source code changes, the version of the recipe needs
> to change too. if you change the source code without bumping
> the version, the package might not be rebuilt properly
> indeed. and that can explain the behavior you are seeing. if
> 'someapp' does not c
On Tue, Aug 20, 2013 at 2:38 PM, Belisko Marek wrote:
> Hello,
>
> I'm trying to build omxplayer for Rpi board but seems libav and other
> dependencies was removed (replaced by meta-oe). But libav was also
> removed from meta-oe [1]. I was trying to use patches [2] but it
> produce errors:
> ERROR
All,
Earlier today we attempted a spin of rc1. This attempt ended up having
multiple issues. Due to that, we decided to end the build, tag and
spin an rc2.
So far, things are looking ok. I did drop the number of buildslaves on
the autobuilder down from 3 to 2, so things might take a bit longer.
T
Hi,
I had build libxml and executed xmlcatalog
It shows follow messages
# xmlcatalog --help
libxml was not compiled with catalog and output support
meta/recipes-core/libxml/libxml2.inc: 32
EXTRA_OECONF = "--without-python --without-debug --without-legacy
--without-catalog --without-docbook --wit
Hi Rudi,
Mpc85xx series is not supported and removed since FSL QorIQ SDK
1.4(QorIQ-SDK-V1.4-20130625-yocto) which is based on Yocto 1.4(dylan), the
machine configure files are removed from dylan/master of meta-fsl-ppc layer to
avoid unexpected issues.
http://git.yoctoproject.org/cgit/cgit.cgi
On Wed, 2013-08-28 at 22:22 +0400, Elvis Dowson wrote:
> On Aug 28, 2013, at 10:07 PM, Bruce Ashfield
> wrote:
>
> > On 13-08-28 02:05 PM, Elvis Dowson wrote:
> >> Hi Bruce,
> >>
> >> On Aug 28, 2013, at 9:52 PM, Bruce Ashfield
> >> wrote:
> >>
> >>> There were some old bugs which caused the
Thank you, Zhenhua. I ended up using meta-fsl-ppc from [1] which has
support for mpc8572 and Dylan. It built the kernel, dtb and rootfs image.
It does not boot right now though stopping after "Uncompressing Kernel
Image ... OK". I guess I have to do more debugging.
Thanks,
Rudi
[1]
http://git.fre
In order to execute
"bitbake -c populate_sdk poky-image" are we supposed to declare
BUILD_ARCH or SDK_ARCH somewhere in local.conf file?
Yocto Documentation has not mentioned anything like that. Just a doubt as
"bitbake poky-image" is working fine though populate_sdk is giving problem..
On Wed, A
An update on where we are at:
rc1 is still churning. There was one autobuilder issue with regards to
genericx86 in nightly-x86-lsb. I've built this out by hand and
populated the release with it as well as corrected the ab issue. We're
seeing a lot of sanity issues, but so far no build failures (ot
I took a look at the libxml's git log, didn't see the explicit reason
that why use the --without-catalog, so it seems reasonable to use the
--with-catalog which will make the xmlcatalog work (if it can be built
well with the option.)
// Robert
On 08/29/2013 09:46 AM, Li Zhijian wrote:
Hi,
I h
44 matches
Mail list logo
