On Fri, Jul 26, 2013 at 12:21 PM, Burton, Ross wrote:
> On 26 July 2013 12:10, Laszlo Papp wrote:
> > As far as I can tell, the reference documentation does not write that
> > anywhere what you are claiming here. So you are either incorrect, or I
> need
> > to fil
On Fri, Jul 26, 2013 at 12:14 PM, Paul Barker wrote:
> On 26 July 2013 11:57, Laszlo Papp wrote:
> > Actually, I also have problems with Debian stable? See the bugreports I
> > sent. It is mentioned as "supported distribution". Yet, it does not
> work. I
> >
On Fri, Jul 26, 2013 at 12:05 PM, Burton, Ross wrote:
> On 26 July 2013 11:57, Laszlo Papp wrote:
> > Actually, I also have problems with Debian stable? See the bugreports I
> > sent. It is mentioned as "supported distribution". Yet, it does not
> work. I
> >
ople. Arch is
a quite common distribution, especially for development because it gives
you the most power for working with bleeding edge technologies.
On Fri, Jul 26, 2013 at 11:52 AM, Burton, Ross wrote:
> On 26 July 2013 11:39, Laszlo Papp wrote:
> > If you do not trust Arch, you can
On Fri, Jul 26, 2013 at 11:44 AM, Burton, Ross wrote:
> Personally speaking, what Paul said.
>
I already replied why I think it is more blocking than helping certain part
of the community.
> We don't "support" any other
> unstable/rolling distribution such as Rawhide, Debian Sid/Unstable,
> etc
, anyhow.
On Fri, Jul 26, 2013 at 11:39 AM, Laszlo Papp wrote:
> If you do not trust Arch, you can use something else. That does not mean
> there would not be people who update (daily for instance) and fix the
> issues coming up.
>
> It is your decision not to trust Archlinux, s
to rule
them out for not being usable in your case.
On Fri, Jul 26, 2013 at 11:34 AM, Paul Barker wrote:
> On 26 July 2013 11:21, Laszlo Papp wrote:
> > Hi,
> >
> > may I ask if it is acceptable to target Archlinux host (64 bit) supported
> > any time soon for a rele
Hi,
may I ask if it is acceptable to target Archlinux host (64 bit) supported
any time soon for a release?
As I might need to work in this environment on a daily bases for a long
term product, I might just need to stand up to get more involved, albeit I
have already filed couple of bug reports ev
Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.25593
for further information)
ERROR: Task 31
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta-sourcery/recipes/meta/
external-sourcery-toolchain.bb, do_install) fail
be fixed.
On Thu, Jul 25, 2013 at 5:53 AM, Laszlo Papp wrote:
> So, is there any workaround in any way to get unblocked or I should just
> switch away from Yocto for now? Unfortunately, if no workaround comes, I do
> not have any other option because then it just does not work. :(
I also filed a bugreport with regards to this:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4901
On Thu, Jul 25, 2013 at 6:57 AM, Laszlo Papp wrote:
> You seem to have missed this email:
> https://lists.yoctoproject.org/pipermail/yocto/2013-July/017416.html
>
>
> On Thu, Ju
You seem to have missed this email:
https://lists.yoctoproject.org/pipermail/yocto/2013-July/017416.html
On Thu, Jul 25, 2013 at 6:47 AM, Khem Raj wrote:
>
> On Jul 24, 2013, at 12:47 AM, "Rifenbark, Scott M" <
> scott.m.rifenb...@intel.com> wrote:
>
> I am facing this issue, any clue?
> **
use the meta-sourcery layer, and it has no any
proper documentation about that, nor example, like the Linaro guys nicely
made one for their solution.
On Wed, Jul 24, 2013 at 10:32 PM, Laszlo Papp wrote:
> Also, it seems to be a bit less lightweight than what we have in oe-core.
> I wou
Also, it seems to be a bit less lightweight than what we have in oe-core. I
would not like to pull unnecessary recipes in. Is it possible to work the
oe-core stuff around?
On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp wrote:
> I believe the developer story would be simpler with oe-core
.
On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson wrote:
> On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson wrote:
>
>> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp wrote:
>>
>>> is this officially supported by the Yocto project? I would not like to
>>> us
1) Is that really from sourcery?
2) What documentation?
3) BTW, the question was whether sourcery is officially supported.
On Wed, Jul 24, 2013 at 9:55 PM, Brian Hutchinson wrote:
> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp wrote:
>
>> Hi,
>>
>> is this officiall
chain questions here for Laszlo?
>
> ** **
>
> Thanks,
>
> Scott
>
> ** **
>
> *From:* djsz...@archlinux.us [mailto:djsz...@archlinux.us] *On Behalf Of
> *Laszlo
> Papp
> *Sent:* Tuesday, July 23, 2013 11:52 PM
> *To:* Rifenbark, Scott M
Yeah, I already filed a bugreport:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899
On Wed, Jul 24, 2013 at 7:16 PM, Saul Wold wrote:
> On 07/24/2013 11:11 AM, Laszlo Papp wrote:
>
>> It seems I can reproduce the issue with even beagleboard + poky using
>>
It seems I can reproduce the issue with even beagleboard + poky using poky
dylan vanilla.
Anyone mind fixing this very nasty bug?
On Wed, Jul 24, 2013 at 5:46 PM, Laszlo Papp wrote:
> Here you can find the two outputs for "bitbake -e busybox". The broken
> sourcery, and n
Here you can find the two outputs for "bitbake -e busybox". The broken
sourcery, and not so broken csl:
http://ix.io/6QZ
http://ix.io/6R1
Yeah, I know it is a bad practice to paste files to a mailing list, so
forgive that for me now, please.
On Wed, Jul 24, 2013 at 4:20 PM, Laszlo P
On Wed, Jul 24, 2013 at 4:12 PM, Bill Traynor wrote:
> On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp wrote:
> > I was using that based on the non-official documentation (i.e.
> presentation
> > at the Linux event).
>
> external-sourcery is the new TCMODE and should work,
This one to be precise:
TCMODE = "external-csl"
EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"
TARGET_PREFIX = "arm-none-linux-gnueabi-"
On Wed, Jul 24, 2013 at 4:08 PM, Laszlo Papp wrote:
> I was using that based on the non-official documentation (i.e.
ed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
> wrote:
> > Hi,
> >
> >
> >
> > Can anyone address the toolchain questions here for Laszlo?
> >
> >
> >
> > Thanks,
> >
> > Scott
> >
> >
> >
> > From: djsz...@ar
Hi,
is this officially supported by the Yocto project? I would not like to use
Yocto for my own purposes if it is something unsupported, and I would need
to put a significant investment into to it to make the releases buildable,
et cetera.
Many thanks,
Laszlo
_
Sorry for the noise. Disregard the busybox issue as that has been now
solved. The problem is with the external sourcery toolchain inside the
platform as it seems. At least, the error message has no any reference to
my custom layer.
On Wed, Jul 24, 2013 at 3:14 PM, Laszlo Papp wrote:
> It i
>
> ** **
>
> Thanks,
>
> Scott
>
> ** **
>
> *From:* djsz...@archlinux.us [mailto:djsz...@archlinux.us] *On Behalf Of
> *Laszlo
> Papp
> *Sent:* Tuesday, July 23, 2013 11:52 PM
> *To:* Rifenbark, Scott M
> *Cc:* Wold, Saul
> *Subject:* Re: FW: [OE-core] Doc:
Signed-off-by: Laszlo Papp
---
meta-yocto/conf/layer.conf | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta-yocto/conf/layer.conf b/meta-yocto/conf/layer.conf
index e012f24..e326aad 100644
--- a/meta-yocto/conf/layer.conf
+++ b/meta-yocto/conf/layer.conf
@@ -9,3 +9,8
27 matches
Mail list logo