If Richard doesn't want to use gerrit for OE-core, that doesn't exclude
others from using it for the layers they manage, does it?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://www.arm.com/products/processors/cortex-a/cortex-a17-processor.php
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
meta/conf/machine/include/tune-cortexa17.inc | 36
1 file changed, 36 insertions(+)
create mode 100644 meta/conf/machine/include/tune
Could http://patchwork.openembedded.org/ be also updated?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 05/19/15 04:35, Paul Eggleton wrote:
On Tuesday 19 May 2015 15:09:31 Robert Yang wrote:
Has a uniform backend for configuration sounds like a good idea, here are
some rough thoughts that we can do in metadata, please feel free to give
your comments:
1) Add a conf file, bbclass or bb
On 15-04-17 08:17 AM, Mike Looijmans wrote:
I noticed there's a crda package in OE, but it RDEPENDS on udev for
no other reason than simply because it provides a rules file for that.
And I want to keep using mdev.
I think it would be better to split this package, and have a
crda-udev package
On 15-04-03 10:34 AM, akuster808 wrote:
I am trying to replicate how Poky is created using combo-layer. I
have referenced https://wiki.yoctoproject.org/wiki/Combo-layer
Interesting! I had never heard of this :-)
The issue seems to be related when I define branch. Not defining it
works fine
[If I reply, people will think that I'm really big on this MAINTAINERS
file thing, which I'm really not. But if I don't reply I'll feel as
though my point was missed :-(]
On 01/07/15 16:30, Richard Purdie wrote:
On Wed, 2015-01-07 at 16:21 -0500, Trevor Woerner wrote:
On 01/07/15 04:25, Richard
On 01/07/15 04:25, Richard Purdie wrote:
I also have a patch. Where should I share them? How do I ensure everyone
with an interest in this defect actually gets the patch? Sure I can
create email and send to the people who I think need to know.
When I went through that whole let's add a
I've written a quick tutorial about this work Paul and his co-workers
have been doing:
https://drive.google.com/file/d/0B3KGzY5fW7laQmgxVXVTSDJHeFU/view?usp=sharing
Tested-by: Trevor Woerner trevor.woer...@linaro.org
--
___
Openembedded-core mailing
On 12/11/14 12:14, Paul Eggleton wrote:
It's not supposed to behave this way, although I have reproduced it here - I
think I hadn't actually tested rebuilding an image with a recipe in the
workspace added to the image. The problem is that the do_compile task is
being marked as nostamp, but
Awesome!! I'm giving this update a whirl right now...
...just one small nit... in commit
7d2c6430131ccf94b8bdc185b8cd849fe479d552 the warning message says:
+lines_before.append('# NOTE: LICENSE is being set to CLOSED
to allow you to at least start building - if')
+
Oops! (this worked before the git pull)
$ devtool add xannounce ~/devel/yocto/build/workflow/xannounce/
NOTE: Creating workspace layer in
/home/trevor/devel/yocto/build/workflow/build/workspace
NOTE: Recipe
to a terminal
On 12/11/14 14:16, Trevor Woerner wrote:
Oops! (this worked before the git pull)
$ devtool add xannounce ~/devel/yocto/build/workflow/xannounce/
NOTE: Creating workspace layer in
/home/trevor/devel/yocto/build/workflow/build/workspace
NOTE: Recipe
/home
I think *this* thread (and question) got lost in the shuffle...
On 12/09/14 10:47, Trevor Woerner wrote:
On 12/02/14 09:01, Paul Eggleton wrote:
On Monday 01 December 2014 23:54:03 Trevor Woerner wrote:
On 11/25/14 12:28, Paul Eggleton wrote:
I've then added a new recipe auto-creation script
On 12/11/14 16:35, Paul Eggleton wrote:
Thanks for the quick bisect - I've fixed it so that wrapper is only used when
running bitbake through devtool build, and now devtool add works properly
again. This is why I should probably write some proper tests before trying to
do anything
(oops! sorry for going off-list)
On 12/09/14 05:50, Paul Eggleton wrote:
On Monday 08 December 2014 22:30:31 Trevor Woerner wrote:
This is really awesome stuff. I'm still playing around with it.
My current HEAD is:
commit 6ea5f5368a88317ace198f44a47cf043bc9fb6e6
Author: Paul
On 12/09/14 10:10, Paul Eggleton wrote:
On Tuesday 09 December 2014 10:00:51 Trevor Woerner wrote:
Would it be possible to make the output of devtool be nice and colourful
like the output of bitbake?
Good idea, this is now done on the branch as well. devtool build doesn't
support colour
On 12/02/14 09:01, Paul Eggleton wrote:
On Monday 01 December 2014 23:54:03 Trevor Woerner wrote:
On 11/25/14 12:28, Paul Eggleton wrote:
I've then added a new recipe auto-creation script, recipetool, which can
take a source tree or URL and create a skeleton recipe to build
On 12/09/14 11:08, Paul Eggleton wrote:
On Tuesday 09 December 2014 10:39:05 Trevor Woerner wrote:
Okay. Maybe it'd be best to just revert to bitbake? IOW, does the
devtool tool need its own build,deploy,...?
We did talk about this in a previous email, but just to clarify:
devtool build
Hi Paul,
Are you making these changes on the existing contrib/paule/devtool or
somewhere else?
A small nit I stumbled on recently... many layers contain a
recipes-devtools directory, and I'm thinking that using the same word
for this feature might get confusing (?). Maybe it would be best to
On 12/01/14 05:11, Paul Eggleton wrote:
On Friday 28 November 2014 12:28:00 Trevor Woerner wrote:
Perhaps any recipe you're working on could be automatically included via
an IMAGE_INSTALL_append in conf/local.conf (or maybe that's too intrusive?)?
This is something I'd wanted to do - it's
On 11/25/14 12:28, Paul Eggleton wrote:
I've then added a new recipe auto-creation script, recipetool, which can
take a source tree or URL and create a skeleton recipe to build it.
...
* recipetool create ideally needs to become smarter and fill in
more details of the recipe. At some
Hi Paul,
These tools are really nice! Some thoughts/comments:
Maybe the devtool.conf that gets created could be placed in the
conf/ subdirectory (along with the other configuration files such as
local.conf and bblayers.conf)?
Perhaps any recipe you're working on could be automatically included
Wow, this is exciting!
Just thinking out loud here... is there a way to way to have the
devshell come up without having applied any patches but with the patches
already queued in, say, a quilt series?
It seems to happen often enough to me that: a recipe has 10 local
patches which applied fine
Hi Paul,
I too wanted to express my thanks to you for this work!
On 10/28/14 19:33, Paul Barker wrote:
This would be a great time for someone to step up and
help move things forward to v0.4.0 and beyond.
Is there a roadmap for opkg somewhere?
Best regards,
Trevor
--
On 10/03/14 04:24, Koen Kooi wrote:
Op 1 okt. 2014, om 17:34 heeft Martin Jansa martin.ja...@gmail.com het
volgende geschreven:
On Wed, Oct 01, 2014 at 09:12:16AM +0100, Richard Purdie wrote:
On Wed, 2014-10-01 at 06:10 +0200, Martin Jansa wrote:
On Tue, Sep 30, 2014 at 08:55:53PM -0700,
On 09/04/14 15:12, Burton, Ross wrote:
If someone knows a good UI for blame-digging then please let me know!
http://vimcasts.org/episodes/fugitive-vim-exploring-the-history-of-a-git-repository/
http://vimcasts.org/episodes/fugitive-vim-browsing-the-git-object-database/
--
ping?
On 07/11/14 12:11, Trevor Woerner wrote:
A previously upstreamed patch has been applied. Bump the version to
incorporate this upstream update.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
.../grub/grub/asciih-fix-build-warning-error.patch | 34
A previously upstreamed patch has been applied. Bump the version to
incorporate this upstream update.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
.../grub/grub/asciih-fix-build-warning-error.patch | 34 --
meta/recipes-bsp/grub/grub_git.bb
This patch fixes a grub build error which is promoted to an error via -Werror.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
Upstream-status: submitted
---
...l-grub-gen-asciih-fix-build-warning-error.patch | 44 ++
meta/recipes-bsp/grub/grub_git.bb
On 05/28/14 15:57, Khem Raj wrote:
Upstream-status should appear in component source patch header not
overall OE patch header.
Thanks for the clarification. v2 is on its way.
--
___
Openembedded-core mailing list
This patch fixes a build warning which is promoted to an error via -Werror.
changes from v1:
* put Upstream-Status in patch itself, not in OE patch header
* fix commit wording
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
.../grub/grub/asciih-fix-build-warning-error.patch | 34
Hello,
This sounds like a great addition!
On 23 April 2014 05:26, Stoicescu, CorneliuX
corneliux.stoice...@intel.com wrote:
1) Testing recipes updates or new recipes
(any experience from common recipe build fails can be helpful here)
I recently stumbled on a situation where doing a clean on
On 30 April 2014 13:57, Paul Barker p...@paulbarker.me.uk wrote:
If you can't find
a good guide online on how to set this up, let me know and I'll write
up a blog post of how I did it.
I'd be interested in reading this, if you wrote it up. Which container
technology did you use?
--
Hi Martin,
Just to confirm... when we work on this, we should be working against
master-next?
Best regards,
Trevor
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
This is the license used for motif.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
meta/files/common-licenses/OGPL | 104
1 file changed, 104 insertions(+)
create mode 100644 meta/files/common-licenses/OGPL
diff --git a/meta/files/common
On 04/09/14 12:24, Burton, Ross wrote:
Please don't say the next patch is adding Motif to oe-core! :) Ross
haha! A little too late for April 1st, eh?
I'm still working through a world build of (mostly) meta-openembedded
and motif is there. Is there a better place to add common license files?
On 04/09/14 13:27, Burton, Ross wrote:
Surely a meta-oe specific license could go into meta-oe? Ross
Okay, sorry for the noise.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
Is anyone seeing any build failures with proj-4.8.0? Or does anyone have
any local fixes? This one has been failing for me for a while, and yet
doesn't show up on the SOBBW lists.
--
___
Openembedded-core mailing list
On 04/03/14 09:06, Martin Jansa wrote:
Other recipes are still free for fixing, please fix them and send reply to
this thread
when you start looking into it, so that nobody duplicates work.
I'm going to be looking at some of the qa.log warnings over the weekend.
--
Here are my notes from today's monthly OE/TSC meeting which takes place
the first Tuesday of every month on freenode's #oe channel.
attendees: bluelightning, Jefro, RP, denix, tlwoerner, fray, nerdboy,
kergoth
topic #1: upcoming release
- schedule:
...in roughly 12 hours from now?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 04/01/14 00:34, Denys Dmytriyenko wrote:
On Tue, Apr 01, 2014 at 12:04:16AM -0400, Trevor Woerner wrote:
...in roughly 12 hours from now?
?
I'm referring to the monthly OE meeting that's held on IRC. I'm trying
to confirm it takes place today and is scheduled for noon EST
Just out of curiosity,
http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20140329_001343.log/world_fixes.inc
includes the line:
inherit blacklist
But when I try, my build doesn't seem happy with this so I use the
following instead:
INHERIT += blacklist
I wonder
On 03/11/14 11:40, Stefan Stanacar wrote:
== is a bashism use = instead.
But the first line of this script is:
#/bin/bash
Shouldn't a bash script be allowed to have bash-isms??!
--
___
Openembedded-core mailing list
Hello Martin,
Excellent, excellent post!
On 03/29/14 21:31, Martin Jansa wrote:
2) There are a lot of changes and component upgrades in oe-core which
sometimes aren't very straight-forward to adapt to and issues stay in
meta-oe for months.
Critical bugfixes aside, I think the current
Excellent information! Thanks for all the workflow examples, this is great.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 03/25/14 01:50, Martin Jansa wrote:
Can you show some example of config you need to have wor wayland and
cannot have for core-image-minimal?
Okay, good point. I should have thought harder to come up with a better
example :-) It's funny, actually, that you're the one pressing me on
this, I
On 03/24/14 12:00, Richard Purdie wrote:
I think from my perspective, in 1.7 I'd like to see us looking at
Developer Workflow.
Maybe I'm using things incorrectly :-)
But I often find that I'm switching between building different images.
For example, one moment I might be building
Allow the user, in their local configuration, to override the size of the
final image. This is useful when creating an image for (for example) an SD
card and the user wants the image to fill up the card as much as possible.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
meta/recipes
Does this resolve issue 5407?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5407
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 02/05/14 12:21, Khem Raj wrote:
I would like to invite everyone to the bug fixing weekend which is
coming in 3 weeks from Feb 21 to Feb 24
Maybe this notice should be posted to the blog?
https://www.yoctoproject.org/new
___
Openembedded-core
Hi Otavio,
Thanks for taking a look at my patch.
On 02/02/14 19:23, Otavio Salvador wrote:
I like to idea and I second this pull request, the only thing I would
like to see added is the possibility of grabing the maintainers for
boards from the machine .conf file. This is the way we're using
automatically.
Trevor Woerner (1):
scripts: add get_maintainer script
scripts/get_maintainer.pl | 2140 +
1 file changed, 2140 insertions(+)
create mode 100755 scripts/get_maintainer.pl
--
1.8.5.2.227.g53f3478
Hopefully some of you have had the time to peruse the bugzilla database
and have chosen a bug or two you'd like to quash this weekend. The bug
hunt starts Friday Jan 16 and runs until Monday.
If you're looking for more ideas there are some janitorial tasks
outlined here:
Hello all OE/Yocto enthusiasts!
https://bugzilla.yoctoproject.org/
It has been noted that the number of unresolved issues in our bugzilla
has been rising which, if left unchecked, will lead to an
ever-increasing bug count. In an effort to raise awareness of the number
of unresolved bugs and work
Since OE is generally used to build Linux distributions, I'm rather
curious to know why OE would include tunes for CortexM3?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
On 01/13/14 13:25, Phil Blundell wrote:
On Mon, 2014-01-13 at 13:16 -0500, Trevor Woerner wrote:
Since OE is generally used to build Linux distributions, I'm rather
curious to know why OE would include tunes for CortexM3?
Well, Cortex-M can run uClinux.
Is there an OE layer that adds support
Hi Mike,
On 01/12/14 15:28, Mike Looijmans wrote:
Worse than unmaintained - this one was taken out of existence last
Friday. I've already notified Paul Eggleton, so it should removed from
the list soon.
Excellent, thanks for the update :-)
___
On 01/08/14 05:28, Richard Purdie wrote:
On Tue, 2014-01-07 at 20:23 +0100, Martin Jansa wrote:
With PACKAGECONFIGs which can list optional dependencies which aren't
included in the the layer itself it's now easier to have recipe with
optional qt5 support in oe-core, but qt5 itself in separate
On 01/09/14 05:56, Jack Mitchell wrote:
On 08/01/14 23:20, Trevor Woerner wrote:
questions:
1) Currently it has been suggested this should be a 2-day event, should
these two days be during the week or over a weekend? In either case,
which 2 days?
If it's two days long then why don't you do
On 01/09/14 10:34, Otavio Salvador wrote:
On Thu, Jan 9, 2014 at 1:07 PM, Trevor Woerner
trevor.woer...@linaro.org mailto:trevor.woer...@linaro.org wrote:
On 01/09/14 05:56, Jack Mitchell wrote:
On 08/01/14 23:20, Trevor Woerner wrote:
questions:
1) Currently it has
Hi everyone,
At the last TSC meeting the topic of unmaintained layers came up. Here
is the sorted list of master layers from the layer index [1], would it
be possible for those in the know to indicate which layers are, or are
suspected of being, unmaintained?
meta-aarch64
meta-acer
meta-ada
On 01/09/14 17:43, Mark Hatle wrote:
On 1/9/14, 3:45 PM, Bruce Ashfield wrote:
On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner
trevor.woer...@linaro.org wrote:
Hi everyone,
At the last TSC meeting the topic of unmaintained layers came up. Here
is the sorted list of master layers from
On 01/08/14 10:56, Paul Eggleton wrote:
However, one concern I have always had with Qt being moved out of
OE-Core though is that I very much doubt the same will happen with
GTK+ and GNOME UI components that we carry, which I think will lead to
the (perhaps erroneous, but logical) assumption in
Hi everyone,
This is a Request For Comments email regarding a bug scrub party the
OE TSC would like to hold.
background:
It has been noticed that the number of bugs in the bugzilla[1] has been
climbing; it would be nice to hold a bug scrub event to raise
awareness of the bugzilla and hopefully
Hello everyone,
question:
Should some version of Qt be included in openembedded-core, or should
all recipes to add Qt be part of their own version-specific Qt layer?
background:
openembedded-core[1] used to include recipes for Qt3, but as Qt3 became
old these recipes were replaced with Qt4 and
A security advisory, CVE-2013-6462, has been issued for libXfont so bump to
version 1.4.7 which fixes this issue.
http://lists.x.org/archives/xorg/2014-January/056265.html
Stack buffer overflow in parsing of BDF font files in libXfont
Trevor Woerner (1):
libxfont: upgrade to 1.4.7
This release includes the fix for CVE-2013-6462, as well as other security
hardening and code cleanups.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
.../xorg-lib/{libxfont_1.4.6.bb = libxfont_1.4.7.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Whoops! I thought the [OE-core] part was added automatically by the
mailing list software. Should I send a V2?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 12/28/13 17:28, Paul Eggleton wrote:
I got a bit tired of seeing poor SUMMARY and DESCRIPTION values in our
recipes, so I went on a bit of a quest to clean them up, and ended up
tidying up a few other things in the process.
This might be a good time to remind people of the
Hi Ross,
Your commit message and your commit don't seem to agree. I.e. you say
you've removed 2 dependencies, but it looks like you've actually removed
more than just 2.
On 12/10/13 07:13, Ross Burton wrote:
Use PACKAGECONFIG to offer some flexibility to the libmatchbox configuration,
and
Hi Saul,
On 1 November 2013 12:35, Saul Wold s...@linux.intel.com wrote:
This says what you are doing, but the question is why is the change needed?
It might be obvious to you, but not to others. The base-feeds.conf file is
provided via the a distro configuration, so it's not guarenteed to be
Place the on-target feed configuration into the base-feeds.conf file instead
of the opkg.conf file.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
meta/classes/rootfs_ipk.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b
On 26 September 2013 22:17, Tom Zanussi tom.zanu...@linux.intel.com wrote:
This patchset implements a new command named 'wic' (for OpenEmbedded
Image Creator). Please see [YOCTO #3847] for extensive background on
what's implemented here.
Wow Tom, this is really AWESOME work! And thanks for
On 30 July 2013 14:47, Andreas Oberritter o...@opendreambox.org wrote:
AFAIR, the reasoning against patchelf was the bad availability across
distributions and it being a prerequisite for native builds. Today,
there's still no patchelf package in current releases of Debian or Ubuntu.
pseudo
On 19 July 2013 05:41, Paul Eggleton paul.eggle...@linux.intel.com wrote:
On Tuesday 09 July 2013 16:14:55 Trevor Woerner wrote:
On 8 July 2013 17:55, Mark Hatle mark.ha...@windriver.com wrote:
For anyone with an old or broken system, they will need to download (or
build) the buildtools
On 10 July 2013 09:03, Hongxu Jia hongxu@windriver.com wrote:
Replace incorrect shebang line with `#!/usr/bin/perl'.
I thought using 'env' was the preferred method?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
On 10 July 2013 16:07, Emilia Ciobanu
emilia.maria.silvia.ciob...@intel.com wrote:
PR = ${INC_PR}.0
+PV = 31
I thought the general trend was to move away from real PVs to the
autoincrementer? I'm just curious to know what issue prompted the move
back to real PVs?
On 11 July 2013 10:55, Ciobanu, Emilia Maria Silvia
emilia.maria.silvia.ciob...@intel.com wrote:
I think this is a misunderstanding. We are currently using the
autoincrementation
mechanism for the PR of the packages and not for the PV. In this case the PV
variable
was missing from the
On 8 July 2013 17:55, Mark Hatle mark.ha...@windriver.com wrote:
For anyone with an old or
broken system, they will need to download (or build) the buildtools..
install it and have it in their path prior to running oe-core.
Does a download location already exist with downloads available for
On 27 June 2013 10:08, Mark Hatle mark.ha...@windriver.com wrote:
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version, so checking
for just the version string is not enough. We also need to check
if the patch for the issue has
On 30 June 2013 12:02, Philip Balister phi...@balister.org wrote:
On 06/30/2013 11:56 AM, Trevor Woerner wrote:
On 27 June 2013 10:08, Mark Hatle mark.ha...@windriver.com wrote:
See GNU Savannah bug 30612 -- make 3.82 is known to be broken.
A number of vendors are providing a modified version
On 24 June 2013 10:27, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
PACKAGES =+ ${PN}-ralink ${PN}-sd8686 ${PN}-wl12xx ${PN}-vt6656 \
${PN}-rtl-license ${PN}-rtl8192cu ${PN}-rtl8192ce
${PN}-rtl8192su \
${PN}-broadcom-license ${PN}-bcm4329 ${PN}-bcm4330
What really confuses me about the attempts I was making is that in
my local.conf file I have explicitly asked for kernel version 3.8.11:
PREFERRED_VERSION_linux-yocto := 3.8.11%
When I watch the build messages fly by I see that linux-yocto_3.8.11
is being built.
In my work directory there
On Wed, May 15, 2013 at 1:24 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
You set the SRCREV that Khem sent. That was my 3.8.4. commit. The version
number in the directories is coming coming from the PV of the package, which
you
didn't tweak.
Ahh... yes. Thank you. Makes perfect sense
On Mon, May 13, 2013 at 1:41 AM, Khem Raj raj.k...@gmail.com wrote:
This patchset adds a new qemu based machine target for mips64 Big-endian
linux-yocto recipe is modified to have it in tree to support qemumips64
machine
My machine seems to build fine, but I can't seem to fully boot the
On Mon, May 13, 2013 at 2:33 PM, Khem Raj raj.k...@gmail.com wrote:
On May 13, 2013, at 9:45 AM, Trevor Woerner twoer...@gmail.com wrote:
try runqemu qemumips64 bootparams=root=/dev/sda
does that boot ?
It gets a little further but doesn't succeed. I have now tried booting a
number of
times
On Mon, May 13, 2013 at 3:02 PM, Khem Raj raj.k...@gmail.com wrote:
you must be using systemd. I am seeing same failure with systemd but only
when my build host is archlinux
Are you referring to the build host or target? My build host is
openSuSE 12.3 which does use systemd. For the target I'm
There's something else that's going on that is strange. When I do a
qemumips build from the master repositories and run it, the
qemu-system-mips that is used is the one built as part of OE (i.e. the
one from the build sysroot). But when I build and run the qemumips64
image using this branch, the
On Mon, May 13, 2013 at 3:38 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
having unwisely wandered into this MIPS64 minefield a couple weeks
back, i might as well see if i can get a build. in short:
* switch to kraj/qemumips64 branch of openembedded-core-contrib
* add that as another
Bruce, you said you were building 3.8.11, but I'm not. When I run my image,
my banner includes:
Linux version 3.4.43-yocto-standard (trevor@zzz) (gcc version 4.7.2 (GCC) )
#1 PREEMPT Mon May 13 12:14:42 EDT 2013
___
Openembedded-core mailing list
I'm building core-image-minimal, I assume that's what everyone else is
doing.
When I run the bitbake -s as Robert is, I get the following:
$ bitbake -s | grep linux
linux-dummy :1.0-r1
linux-firmware
On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day rpj...@crashcourse.cawrote:
On Mon, 13 May 2013, Trevor Woerner wrote:
I'm building core-image-minimal, I assume that's what everyone else is
doing.
When I run the bitbake -s as Robert is, I get the following:
$ bitbake -s | grep linux
Okay, I'm going to start over :-)
I have a layer, meta-poky, which is:
$ git remote -v
contrib git://git.pokylinux.org/poky-contrib (fetch)
contrib git://git.pokylinux.org/poky-contrib (push)
origin git://git.yoctoproject.org/poky (fetch)
origin git://git.yoctoproject.org/poky (push)
Currently
On Mon, May 13, 2013 at 5:30 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
i'm confused ... why would you be building two versions of the
kernel?
Maybe I just need to provide a PREFERRED_PROVIDER_virtual/kernel?
___
Openembedded-core mailing
On Mon, May 13, 2013 at 6:19 PM, Khem Raj raj.k...@gmail.com wrote:
sysroots/x86_64-linux/usr/bin/mips64-angstrom-linux/mips64-angstrom-linux-gcc
-v
angstrom??!
angstrom - poky?
sysroots/x86_64-linux/usr/bin/mips64-poky-linux/mips64-poky-linux-gcc --version
mips64-poky-linux-gcc (GCC) 4.7.2
By adding:
PREFERRED_VERSION_linux-yocto := 3.8%
to my conf/local.conf I was able to get the image to build/use 3.8.11;
but I too am still seeing the kernel panic as described before (i.e.
in reset_counters()).
___
Openembedded-core mailing list
On Mon, May 13, 2013 at 10:03 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Mon, May 13, 2013 at 10:01 PM, Trevor Woerner twoer...@gmail.com wrote:
By adding:
PREFERRED_VERSION_linux-yocto := 3.8%
Yep. This is what I was about to recommend, but did you apply Khem's patches
On Thu, May 9, 2013 at 12:57 PM, Marcin Juszkiewicz
marcin.juszkiew...@linaro.org wrote:
Who will maintain those layers after my leave? This was not decided yet.
There are few guys at Linaro who know how to use OpenEmbedded but most
of them is outside of Builds and Baselines team.
To me this
301 - 400 of 447 matches
Mail list logo
