Re: [yocto] Squeezing a gstreamer video pipeline into the smallest footprint possible
On 9 April 2014 00:03, Patrick Doyle wrote: > I have a ridiculously pinhole sized memory footprint into which I > would like to squeeze a gstreamer based video pipeline. I am looking > for tips on what I can do to minimize the footprint as much as > possible for my Yocto based system. The GStreamer plugins and libraries are all packaged independently in Yocto, so you can do some heavy size reduction by just installing the packages you need, and double-checking that nothing unexpected gets pulled in via dependencies. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can Yocto support "git clone" for url with http prefix
Thank you, Erik. Best Regards, Zhenhua > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Erik Bot? > Sent: Wednesday, April 09, 2014 2:47 PM > To: Luo Zhenhua-B19537 > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Can Yocto support "git clone" for url with http > prefix > > Hi, > > On Wed, Apr 9, 2014 at 8:21 AM, zhenhua@freescale.com > wrote: > > I want to create recipe for a package which is managed by Gerrit, > Gerrit only provides an anonymous HTTP url(http://:8181/bb) which can > be cloned by "git clone http://:8181/bb"; correctly. > > > > I set SRC_URI to "http://:8181/bb"; in the bb file, following is the > detailed definition. > >SRC_URI = "http://:8181/bb;protocol=git;branch=master"; > > > > When I try to build the package, following error appears. > > ERROR: Function failed: URL: > > 'http://:8181/bb;protocol=git;branch=master' has invalid > > parameters. Invalid protocol - if you wish to fetch from a git > > repository using http, you need to instead use the git:// prefix with > > protocol=http > > > > May I know if Yocto can support "git clone" for url with http prefix? > > Yes. All git SRC_URI start with git:// and then you can specify > protocol=http. E.g. > > SRC_URI = "git://:8181/bb;protocol=http;branch=master" > > Cheers, > Erik > > > > > > > Best Regards, > > > > Zhenhua > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > > -- > = > Erik Botö > Senior Software Engineer > Pelagicore AB > Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden > Mobile: +46 (0)76 881 72 03 > E-Mail: erik.b...@pelagicore.com > = > -- > ___ > 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] Dogfooding and usability testing Toaster
Hi all, I am looking into collecting feedback on the first version of Toaster https://www.yoctoproject.org/blogs/belenbarrospena/2014/eye-candy which will be out with Yocto Project 1.6. There are 2 things I'd like to do: 1) Dogfooding Once the release is out, it would be great to have people trying Toaster for real work stuff, and telling us how it went. I am of course particularly keen on hearing about what's wrong, so feel free to vent your frustrations with the thing. 2) (More formal) usability testing I am also looking into validating the Toaster interface in more conventional ways, which means usability testing. This is done in 30-minute sessions run remotely using screen sharing software, although we can also do it in person if you are going to ELC or the OEDAM. During those 30 minutes you will be asked to do some stuff with Toaster and to speak your mind a lot. I will also ask for your permission to record the session, which you can of course refuse. If you would like to volunteer for this (which is useful and important stuff), get in touch with me (I am belen in IRC, or email me). I would normally give out something in return for your time, but things are tight right now, so I'm afraid all you'll get on this occasion is a heartwarming thank you. Cheers Belén -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
Hi Vali, On Tuesday 08 April 2014 18:34:08 Vali Cobelea wrote: > Here at ENEA we decided to take the initiative regarding the CGL > compliance when it comes to the Yocto Project. > For this we started the work on a dedicated layer called 'meta-cgl' > which can be accessed / cloned from here: > > http://git.enea.com/git/?p=linux/meta-cgl.git > git clone g...@git.enea.com:linux/meta-cgl > > Have a look of the things we got there so far, please remember that > there is still plenty of work to be done (layer architecture, CGL > requirements coverage mode and so on). > It is a little bit more than a stub layer, consider it a starting point > for the direction we would like to have with this layer. > > Any input is much appreciated, lets keep the discussion by this email > thread and see where it goes. I don't have anything to offer on the layer contents, but I would say in order to make it easy for people to find this layer I would strongly encourage you to submit it to the OpenEmbedded layer index: http://layers.openembedded.org/layerindex/submit/ Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
Hi, Thank you for the input. We will keep the layer for a short period of time at the current location while getting other ideas regarding the content / architecture. The layer initiative will also be raised up in the board advisory meeting, in order to get even more input. After which we will make it easier to find, access and use for anyone, exactly as you suggested. Best regards, Vali On 04/09/2014 01:51 PM, Paul Eggleton wrote: Hi Vali, On Tuesday 08 April 2014 18:34:08 Vali Cobelea wrote: Here at ENEA we decided to take the initiative regarding the CGL compliance when it comes to the Yocto Project. For this we started the work on a dedicated layer called 'meta-cgl' which can be accessed / cloned from here: http://git.enea.com/git/?p=linux/meta-cgl.git git clone g...@git.enea.com:linux/meta-cgl Have a look of the things we got there so far, please remember that there is still plenty of work to be done (layer architecture, CGL requirements coverage mode and so on). It is a little bit more than a stub layer, consider it a starting point for the direction we would like to have with this layer. Any input is much appreciated, lets keep the discussion by this email thread and see where it goes. I don't have anything to offer on the layer contents, but I would say in order to make it easy for people to find this layer I would strongly encourage you to submit it to the OpenEmbedded layer index: http://layers.openembedded.org/layerindex/submit/ Thanks, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
On Wednesday 09 April 2014 13:55:47 Vali Cobelea wrote: > On 04/09/2014 01:51 PM, Paul Eggleton wrote: > > On Tuesday 08 April 2014 18:34:08 Vali Cobelea wrote: > >> Here at ENEA we decided to take the initiative regarding the CGL > >> compliance when it comes to the Yocto Project. > >> For this we started the work on a dedicated layer called 'meta-cgl' > >> > >> which can be accessed / cloned from here: > >>http://git.enea.com/git/?p=linux/meta-cgl.git > >>git clone g...@git.enea.com:linux/meta-cgl > >> > >> Have a look of the things we got there so far, please remember that > >> there is still plenty of work to be done (layer architecture, CGL > >> requirements coverage mode and so on). > >> It is a little bit more than a stub layer, consider it a starting point > >> for the direction we would like to have with this layer. > >> > >> Any input is much appreciated, lets keep the discussion by this email > >> thread and see where it goes. > > > > I don't have anything to offer on the layer contents, but I would say in > > order to make it easy for people to find this layer I would strongly > > encourage you to> > > submit it to the OpenEmbedded layer index: > >http://layers.openembedded.org/layerindex/submit/ > > Thank you for the input. > We will keep the layer for a short period of time at the current > location while getting other ideas regarding the content / architecture. > The layer initiative will also be raised up in the board advisory > meeting, in order to get even more input. > After which we will make it easier to find, access and use for anyone, > exactly as you suggested. OK, as the maintainer it's totally up to you. I would say though generally that I'd like to see more people adding their work-in-progress layers to the layer index, even if at some time later they will be moved elsewhere or absorbed into another layer - it just makes it easier to point people to the layer index so they can find recipes that have already been written, rather than having to re-write them from scratch. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Squeezing a gstreamer video pipeline into the smallest footprint possible
Thank you for the tips folks... please keep them coming. At the moment (for this pinhole sized project) I only need support for video. Is there any way to strip out all of the audio components from the gstreamer I generate? I tried adding --disable-vorbis to my recipe, only to find that config.status shows that both --disable-vorbis and --enable-vorbis options we set in ac_cs_config. In the mean time, I'm going to go build my own pipeline & link it statically as suggested by Sebastian. Thank you again. --wpd On Wed, Apr 9, 2014 at 4:53 AM, Burton, Ross wrote: > On 9 April 2014 00:03, Patrick Doyle wrote: >> I have a ridiculously pinhole sized memory footprint into which I >> would like to squeeze a gstreamer based video pipeline. I am looking >> for tips on what I can do to minimize the footprint as much as >> possible for my Yocto based system. > > The GStreamer plugins and libraries are all packaged independently in > Yocto, so you can do some heavy size reduction by just installing the > packages you need, and double-checking that nothing unexpected gets > pulled in via dependencies. > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
OK Paul, that indeed makes sense, I really did not knew that preliminary versions of layers are accepted. I will discuss around here and if everything goes OK we will start the move in the "public" layer index. I also do agree with an all-together strategy, no matter for the layer state. Much appreciated, Vali On 04/09/2014 02:01 PM, Paul Eggleton wrote: On Wednesday 09 April 2014 13:55:47 Vali Cobelea wrote: On 04/09/2014 01:51 PM, Paul Eggleton wrote: On Tuesday 08 April 2014 18:34:08 Vali Cobelea wrote: Here at ENEA we decided to take the initiative regarding the CGL compliance when it comes to the Yocto Project. For this we started the work on a dedicated layer called 'meta-cgl' which can be accessed / cloned from here: http://git.enea.com/git/?p=linux/meta-cgl.git git clone g...@git.enea.com:linux/meta-cgl Have a look of the things we got there so far, please remember that there is still plenty of work to be done (layer architecture, CGL requirements coverage mode and so on). It is a little bit more than a stub layer, consider it a starting point for the direction we would like to have with this layer. Any input is much appreciated, lets keep the discussion by this email thread and see where it goes. I don't have anything to offer on the layer contents, but I would say in order to make it easy for people to find this layer I would strongly encourage you to> submit it to the OpenEmbedded layer index: http://layers.openembedded.org/layerindex/submit/ Thank you for the input. We will keep the layer for a short period of time at the current location while getting other ideas regarding the content / architecture. The layer initiative will also be raised up in the board advisory meeting, in order to get even more input. After which we will make it easier to find, access and use for anyone, exactly as you suggested. OK, as the maintainer it's totally up to you. I would say though generally that I'd like to see more people adding their work-in-progress layers to the layer index, even if at some time later they will be moved elsewhere or absorbed into another layer - it just makes it easier to point people to the layer index so they can find recipes that have already been written, rather than having to re-write them from scratch. Cheers, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] The point of Release Candidates
It seems people don't understand what the point of a Release Candidate is, or the timelines we work to. The fact this is coming as a surprise to people is seriously upsetting to me as we've done this for long enough now that people should know the drill. A release candidate is what is says, a possible candidate to be released. We merge things, it goes to QA, it gets tested and then we decide go/no go. I appreciate this time around, RC1 was a trial run due to the kernel issues. We did the best would could there having decided to go for 3.14. RC3 was meant to happen last night. In theory, patches should have been submitted by Sunday for it giving me Monday/Tuesday to review, merge, test and sort things out. I delayed RC3 by 24 hours since: a) yocto-bsp tooling was broken. It fell off the radar and was a release blocker b) the RC2 QA report wasn't out I'm now finding that: a) The QA teams either don't have or can't boot beaglebone. b) The beaglebone README still isn't available. I took patches on the understanding this would be available. The QA team who do have hardware are trying to test something which isn't documented so this is hindering a). Are they testing the right thing? Who knows. c) We have a number of edgerouter bugs. Why are these appearing now? d) There are cyptodev patches in various states of flux. The turnaround on patches there isn't what I'd expect at rc3 if people want them in. Basically, they're not going in now due to that. e) The patch quality is to be blunt, dire. Patches coming in at this point need to be well thought out and tested. Instead, some people are panicking and appear to be throwing any old thing in and then worry about bug fixing it later. At this point, its looking like we may have to go to rc4 as bugs with two of the reference BSPs is a serious issue. I don't think people realise how much of a mess we're heading into here as even to make rc4, I need the fixes near enough yesterday. I'm actually taking this pretty personally. I do what I can for the project to pull things together. I do try and cut people slack where possible to make things happen. In return, it appears people are just taking advantage of this. I may well start getting a lot stricter with deadlines, cutoffs and so on which I can guarantee that people are not going to enjoy. Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Adding RPMs and kernel images
We are working on a project where we will be receiving different types of artifacts from various development groups within the organization. Specifically, we will receive kernel images (qemux86, qemuarm, and ATOM) as well as RPMs. We'd like to incorporate those artifacts directly into our project and have bitbake treat them as if they are current, part of the project, and are incorporated in our image builds. Can you suggest best practices/approaches to integrate these external artifacts in to our build. Thanks! Jim McClure -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs] [PATCH] Extended description of the ${D} variable
Hello everyone,
In comparision to ${S}, the variable ${D} isn't documented very well in the
ref-manual. I wanted to improve on that a little bit.
Please review the attached patch (on correctness of the statements especially).
It would be cool to see this mainline soon.
With best regards,
Dennis Meier
Siemens Building Technologies Division HQ (dARE of 5280)
Infrastructure & Cities Sector
Building Technologies
Control Products & Systems
IC BT CPS R&D ZG FW CCP
Gubelstrasse 22
6300 Zug, Switzerland
Tel: +41 41 724-2028
mailto:meier.den...@siemens.com
0001-Extended-description-of-the-D-variable-to.patch
Description: 0001-Extended-description-of-the-D-variable-to.patch
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-docs] [PATCH] Extended description of the ${D} variable
Dennis,
Thanks for the patch. I have applied it for the upcoming 1.6 release. You can
examine it at
http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#var-D. When
applying your patch, I performed some minor style editing to conform to some
standards within the YP documentation.
Best,
Scott
>-Original Message-
>From: Meier, Dennis [mailto:meier.den...@siemens.com]
>Sent: Wednesday, April 09, 2014 5:32 AM
>To: yocto@yoctoproject.org
>Cc: Rifenbark, Scott M
>Subject: [yocto-docs] [PATCH] Extended description of the ${D} variable
>
>Hello everyone,
>
>In comparision to ${S}, the variable ${D} isn't documented very well in the
>ref-
>manual. I wanted to improve on that a little bit.
>Please review the attached patch (on correctness of the statements
>especially).
>
>It would be cool to see this mainline soon.
>
>With best regards,
>Dennis Meier
>
>Siemens Building Technologies Division HQ (dARE of 5280) Infrastructure &
>Cities Sector Building Technologies Control Products & Systems IC BT CPS R&D
>ZG FW CCP Gubelstrasse 22
>6300 Zug, Switzerland
>Tel: +41 41 724-2028
>mailto:meier.den...@siemens.com
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Squeezing a gstreamer video pipeline into the smallest footprint possible
Hi, Disabling the GStreamer debugging system can also help trim off a decent amount from the packages. Edward On Wed, 2014-04-09 at 07:13 -0400, Patrick Doyle wrote: > Thank you for the tips folks... please keep them coming. At the moment > (for this pinhole sized project) I only need support for video. Is > there any way to strip out all of the audio components from the > gstreamer I generate? I tried adding --disable-vorbis to my recipe, > only to find that config.status shows that both --disable-vorbis and > --enable-vorbis options we set in ac_cs_config. > > In the mean time, I'm going to go build my own pipeline & link it > statically as suggested by Sebastian. > > Thank you again. > > --wpd > > > On Wed, Apr 9, 2014 at 4:53 AM, Burton, Ross wrote: > > On 9 April 2014 00:03, Patrick Doyle wrote: > >> I have a ridiculously pinhole sized memory footprint into which I > >> would like to squeeze a gstreamer based video pipeline. I am looking > >> for tips on what I can do to minimize the footprint as much as > >> possible for my Yocto based system. > > > > The GStreamer plugins and libraries are all packaged independently in > > Yocto, so you can do some heavy size reduction by just installing the > > packages you need, and double-checking that nothing unexpected gets > > pulled in via dependencies. > > > > Ross > ___ > gstreamer-embedded mailing list > gstreamer-embed...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/gstreamer-embedded -- Edward Hervey -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] do_populate_sysroot_setscene needs pseudo-native
I am getting the following warning: WARNING: Setscene task 45 (/home/jate/workspace/poky/meta/recipes-connectivity/avahi/avahi-ui_0.6.31.bb, do_populate_sysroot_setscene) failed with exit code '1' - real task will be run instead The task log.do_populate_sysroot_setscene has the following WARNING: NOTE: Performing useradd with [--root /home/jate/workspace/poky/qemux86/tmp/sysroots/qemux86 --system --home /var/run/avahi-daemon --no-create-home --shell /bin/false --user-group avahi] and 10 times of retry /home/jate/workspace/poky/qemux86/tmp/work/i586-poky-linux/avahi-ui/0.6.31-r7.0/temp/run.useradd_sysroot_sstate.17299: line 284: /home/jate/workspace/poky/qemux86/tmp/sysroots/i686-linux/usr/bin/pseudo: No such file or directory WARNING: useradd command did not succeed. Retrying... If I bitbake pseudo-native manually first, I can eliminate the warning. I tried adding pseudo-native to the useradd.bbclass, but that doesn't cause a rebuild. Any thoughts on how to do this? - Jate -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dogfooding and usability testing Toaster
On 04/09/2014 03:43 AM, Barros Pena, Belen wrote: > Hi all, > > I am looking into collecting feedback on the first version of Toaster > > https://www.yoctoproject.org/blogs/belenbarrospena/2014/eye-candy > > which will be out with Yocto Project 1.6. There are 2 things I'd like to > do: > > 1) Dogfooding > > Once the release is out, it would be great to have people trying Toaster > for real work stuff, and telling us how it went. I am of course > particularly keen on hearing about what's wrong, so feel free to vent your > frustrations with the thing. > > 2) (More formal) usability testing > > I am also looking into validating the Toaster interface in more > conventional ways, which means usability testing. This is done in > 30-minute sessions run remotely using screen sharing software, although we > can also do it in person if you are going to ELC or the OEDAM. During > those 30 minutes you will be asked to do some stuff with Toaster and to > speak your mind a lot. I will also ask for your permission to record the > session, which you can of course refuse. Belen, can you add this to the OEDAM wiki page? We should have a good variety of people there to give feedback. Philip > > If you would like to volunteer for this (which is useful and important > stuff), get in touch with me (I am belen in IRC, or email me). I would > normally give out something in return for your time, but things are tight > right now, so I'm afraid all you'll get on this occasion is a heartwarming > thank you. > > Cheers > > Belén > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_populate_sysroot_setscene needs pseudo-native
On Wed, Apr 9, 2014 at 1:52 PM, Jate S wrote: > WARNING: Setscene task 45 > (/home/jate/workspace/poky/meta/recipes-connectivity/avahi/ > avahi-ui_0.6.31.bb, > do_populate_sysroot_setscene) failed with exit code '1' - real task > will be run instead > > The task log.do_populate_sysroot_setscene has the following WARNING: > > NOTE: Performing useradd with [--root > /home/jate/workspace/poky/qemux86/tmp/sysroots/qemux86 --system --home > /var/run/avahi-daemon --no-create-home > --shell /bin/false --user-group avahi] > and 10 times of retry > > /home/jate/workspace/poky/qemux86/tmp/work/i586-poky-linux/avahi-ui/0.6.31-r7.0/temp/run.useradd_sysroot_sstate.17299: > line 284: > /home/jate/workspace/poky/qemux86/tmp/sysroots/i686-linux/usr/bin/pseudo: > No such file or directory > WARNING: useradd command did not succeed. Retrying... > > If I bitbake pseudo-native manually first, I can eliminate the > warning. I tried adding pseudo-native to the useradd.bbclass, but that > doesn't cause a rebuild. > > Any thoughts on how to do this? > You likely need something like: do_populate_sysroot_setscene[depends] += "pseudo-native:do_populate_sysroot_setscene" If you grep around oe-core/poky, there are a couple examples of this. I actually just ran into a case like this, where gdk-pixbuf-native needed jpeg-native to run its setscene postinst, but the dep was missing, causing setscene failure. -- 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
Re: [yocto] Dogfooding and usability testing Toaster
Hi Belen, That is exciting. I just ran with it and started a build with toaster in the background. A couple of observations from the get-go: - South 0.8.4 is also needed in addition to Django. The Toaster Wiki [1] does not say that but the Contribute to Toaster page [2] does. - You need to run 'sudo pip install ...' for Django and South otherwise the installation fails with 'permission denied' for /usr/lib/python2.7 - Clicking on "Show me the manual" in the Toaster UI directs to [3] which requires a log in - Is it possible to relocate/rename the toaster.sqlite database via configuration setting? If so, could I use the same database for different build environments? Thanks, Rudi [1] https://wiki.yoctoproject.org/wiki/Toaster#Installation_and_Running [2] https://wiki.yoctoproject.org/wiki/Contribute_to_Toaster [3] https://www.yoctoproject.org/documentation/toaster-manual -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dogfooding and usability testing Toaster
On Wed, Apr 9, 2014 at 4:33 PM, Rudolf Streif wrote: > That is exciting. I just ran with it and started a build with toaster in > the background. A couple of observations from the get-go: > >- South 0.8.4 is also needed in addition to Django. The Toaster Wiki >[1] does not say that but the Contribute to Toaster page [2] does. >- You need to run 'sudo pip install ...' for Django and South >otherwise the installation fails with 'permission denied' for >/usr/lib/python2.7 >- Clicking on "Show me the manual" in the Toaster UI directs to [3] >which requires a log in >- Is it possible to relocate/rename the toaster.sqlite database via >configuration setting? If so, could I use the same database for different >build environments? > > Side note: you can use pip install --user ... rather than sudo pip, to install it to your user site-packages directory under ~/.local, which won't impact the rest of the system. -- 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] yocto-1.6_M5.rc3 available
All, We have an rc3 build for our upcoming 1.6 release. We had to rebuild the eclipse-poky-kepler plugin due to some incompatibility with the debian 7 builder. We also have issues in nightly-oecore: http://autobuilder.yoctoproject.org/main/builders/nightly-oecore/builds/39 and http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/40 The build is available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc3 bitbake 40027a6e093c3b7480bfaccbd57e0e613d9a7b71 eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37 eclipse-poky-kepler 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e meta-fsl-arm d4316faef78ceb01ff023579e15110939ec69408 meta-fsl-ppc c4fa1b431f4efc4982a168119db95236cfa8cad3 meta-intel db84acfc8d9ed8dccd4a79de39fee337bc729662 meta-minnow 743fa66aa0cc2265a9c1f293c305828d90b4fbbd meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 oecore 77e3d60fa00a41424fe65977b2bf307727a5a26c poky 046a9ea30356daf4f3f8f4ddfc5b57fcfd85a27f -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
