[yocto] Yocto in Virtualbox

[cnxsoft]

Hi,

I have build x86 qemu image using "bitbake -k core-image-sato" following 
the instructions given at 
http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html

I'm running Ubuntu 11.10 in VirtualBox 4.1.6.

When I run qemu, qemu starts apparently fine, but the qemu window stays 
black. So I'm suspecting that either it does not work in Virtualbox or I 
may have tochange some settings in qemu (e.g. -vga vmware).


Here's the output:

runqemu qemux86

Continuing with the following parameters:
KERNEL: 
[/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin]
ROOTFS: 
[/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3]

FSTYPE: [ext3]
Setting up tap interface under sudo
Acquiring lockfile for tap0...
Starting distccd...
Running qemu...
/home/jaufranc/edev/edison-6.0-build/tmp/sysroots/i686-linux/usr/bin/qemu -kernel 
/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin 
-net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda 
/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3 
-show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl 
-no-reboot -m 128 --append "vga=0 root=/dev/hda rw mem=128M 
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "

Enabling opengl


Thanks.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Upstream-Status finally @ 100%

[Saul Wold]

We finally did it!

After getting some final patches yesterday, we made it to 100% with 
patch Upsteam-Status.


Total Patches Files: 1243
All Upstream-Status: 1243
Fix Upstream-Status: 0
Need Upstream-Status: 0
Pending Upstream-Status: 461

This means we have 461 patches to now work their way into the Upstream
communities.

Let's work to maintain this, I will be watching incoming patches and 
using a check script to verify that patches have Upstream-Status.


Thanks to all those people who worked to get Upstream-Status into their 
patches.


Sau!

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Raspberry Pi

[Jack Mitchell]

On 08/02/12 02:36, Brian Hutchinson wrote:

On Tue, Feb 7, 2012 at 7:52 PM, Joshua Lock  wrote:

Somehow they managed to convince Broadcom to release a datasheet for the
SoC: http://www.raspberrypi.org/archives/615

One of my friends sent me a funny quote he saw today:

"The most amazing thing about this device is the ability to download a
Broadcom spec sheet without a pile of signed NDA's, 4 months of
negotiations, and not having to talk to a single lawyer.  Way more
impressive than a $35 Linux board! :D"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Very impressive indeed. I run a Raspberry Pi website at the moment, and 
in due course I plan on (attempting) to write a BSP for Yocto and maybe 
do a blog post on setting up quemuarm so people can play with a cross 
compile toolchain and learn how to use yocto in the process.


However, have you seen the kernel sources? Very slapdash in places, 
someone is going to spend a lot of time if they wish to get them 
upstream, they didn't even release them as patches, just as a source 
tree... tut tut.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: Hob 1.2 design

[Barros Pena, Belen]

Just to clarify: videos show relevant functionality to a specific design
piece. The fact that a video does not show something it doesn't mean the
functionality has gone away. If I showed everything on each video they
would be very very long (and very very boring) videos.  I hope this
explains. 

Given the time constraints we have, the little design documentation I am
producing is incomplete. Therefore, it is very important that if you have
any questions, doubts, thoughts, feedback, general comments etc about the
Hob UI, you get in touch with me. Even if the question sounds very small
or trivial: that's what I am here for.

Cheers

Belen



On 07/02/2012 16:17, "Joshua Lock"  wrote:

>Hi Belen,
>
>Thanks for clarifying.
>
>Shane - I noticed at least one bug has been closed because the second
>video didn't show the features (#1804) - seems like this isn't what was
>intended by features 'disappearing' in the latest video.
>
>http://bugzilla.pokylinux.org/show_bug.cgi?id=1804
>
>Cheers,
>Joshua
>
>On 07/02/12 03:23, Barros Pena, Belen wrote:
>> Hi Joshua,
>>
>> Additional package details appear on clicking the package name using an
>> information bubble. The bubble is also dismissed on click using a
>>'close'
>> button. This functionality is shown on the first video (not on the
>>second
>> one: I skipped it to keep it short).
>>
>> Cheers
>>
>> Belen
>>
>> On 06/02/2012 21:32, "Joshua Lock"  wrote:
>>
>>> On 31/01/12 17:39, Wang, Shane wrote:
 Hi, all,

 Belen has a new video for Hob2 workflow and design.

 https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov
>>>
>>> It just came to my attention through another channel that the
>>> description column of the packages table is no longer present.
>>>
>>> There had been some discussion about how to show relevant description
>>> information in that column, so I'm surprised to see it go.
>>>
>>> Belen, I assume from a design perspective this field was removed as it
>>> didn't show anything particularly useful? If we have useful data to
>>> include in that field is there a more appropriate way to integrate it
>>> into the UI? Perhaps a tooltip? Or an information overlay as has been
>>> used in other areas of the design?
>>>
>>> I'm concerned that if we give the user a list of packages without any
>>> more information we aren't making it easy for them to build an OS image
>>> without already understanding exactly all of the components they need -
>>> thoughts?
>>>
>>> Cheers,
>>> Joshua
>>> --
>>> Joshua Lock
>>>  Yocto Project "Johannes factotum"
>>>  Intel Open Source Technology Centre
>>
>
>-- 
>Joshua Lock
> Yocto Project "Johannes factotum"
> Intel Open Source Technology Centre

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] sysroot and boost.m4 library search path problem

[Joshua Immanuel]

Hello all,
While trying to build my user space application in yocto, the boost.m4
was looking packages in the host (i.e host contamination, thereby
resulting in configure error). This appears to be a problem in boost.m4
which ignores the sysroot option while searching for libraries. In the
libtool recipe of yocto I find that --with-sysroot option has been
renamed to --with-libtool-sysroot. 

To address this problem, I've written a patch for boost.m4 specifically
for yocto. I believe this will be helpful to others who are using boost
libraries. I guess, I have to send a separate patch to boost.m4
maintainer using '$with-sysroot' variable.

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in
diff --git a/boost.m4 b/boost.m4
index b1cb1b1..4f1a0d1 100644
--- a/boost.m4
+++ b/boost.m4
@@ -374,13 +374,27 @@ for boost_rtopt_ in $boost_rtopt '' -d; do
 case $boost_failed_libs in #(
   *@$boost_lib@*) continue;;
 esac
-# If with_boost is empty, we'll search in /lib first, which is not quite
-# right so instead we'll try to a location based on where the headers are.
-boost_tmp_lib=$with_boost
-test x"$with_boost" = x && boost_tmp_lib=${boost_cv_inc_path%/include}
-for boost_ldpath in "$boost_tmp_lib/lib" '' \
- /opt/local/lib* /usr/local/lib* /opt/lib* /usr/lib* \
- "$with_boost" C:/Boost/lib /lib*
+# If with_boost is empty, we'll search in /lib first, which is not
+# quite right so instead we'll try to a location based on where
+# the headers are.  If with_sysroot is specified then we prepend
+# with_sysroot path to the boost_tmp_lib variable
+if [[ -z ${with_libtool_sysroot+xxx} ]]; then
+   # with_sysroot variable not set at all
+  boost_tmp_lib=${with_boost}/lib
+  test x"$with_boost" = x && boost_tmp_lib="${boost_cv_inc_path%/include} \
+   /opt/local/lib* /usr/local/lib* /opt/lib* /usr/lib* \
+   ${with_boost} C:/Boost/lib /lib*"
+else
+  boost_tmp_lib="${with_libtool_sysroot}/${boost_cv_inc_path%/include} \
+  ${with_libtool_sysroot}/opt/local/lib* \
+  ${with_libtool_sysroot}/usr/local/lib* \
+  ${with_libtool_sysroot}/lib* \
+  ${with_libtool_sysroot}/usr/lib* \
+  ${with_libtool_sysroot}/opt/lib* \
+  ${with_libtool_sysroot}/Boost/lib ${with_boost}"
+fi
+
+for boost_ldpath in $boost_tmp_lib
 do
   test -e "$boost_ldpath" || continue
   boost_save_LDFLAGS=$LDFLAGS
@@ -1107,11 +1121,11 @@ boost_use_source=:
 test -f conftest.$ac_objext && ac_ext=$ac_objext && boost_use_source=false &&
   _AS_ECHO_LOG([re-using the existing conftest.$ac_objext])
 AS_IF([_AC_DO_STDERR($ac_link) && {
-	 test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
-	 test ! -s conftest.err
+test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
+test ! -s conftest.err
} && test -s conftest$ac_exeext && {
-	 test "$cross_compiling" = yes ||
-	 $as_executable_p conftest$ac_exeext
+test "$cross_compiling" = yes ||
+$as_executable_p conftest$ac_exeext
 dnl FIXME: use AS_TEST_X instead when 2.61 is widespread enough.
}],
   [$2],


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot and boost.m4 library search path problem

[Joshua Immanuel]

Hello all,

On Wed, 2012-02-08 at 18:19 +0530, Joshua Immanuel wrote:
> To address this problem, I've written a patch for boost.m4
> specifically for yocto. I believe this will be helpful to others who
> are using boost libraries. I guess, I have to send a separate patch to
> boost.m4 maintainer using '$with-sysroot' variable.

Forgot to mention, the issue already has been reported for boost.m4 at
https://github.com/tsuna/boost.m4/issues/26 
I have added my patch (not yocto specific one) there too.

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building your own UI

[autif khan]

>>> This may be a dumb question, but I'll ask anyway.
>>
>>> Suppose you have a project where you need a very custom user
>>> interface. Not just a series of applications that appear on a desktop
>>> like you see in sato, or Gnome, or KDE.  Basically your application
> becomes the UI.
>>
>>> I can see 2 approaches to this:
>>
>>> Start with core-image-minimal and add the packages you need to support
>>> GFX, X11, and your application plus dependencies.
>>> Take core-image-sato and change the applications to be your subtasks ,
>>> and the look-and-feel of the desktop.
>>
>>> What are the considerations of both approaches?
>> >Is one better, or easier than the other?
>> >How would you do this in Yocto?
>>> Where do you look for information you need to accomplish this?
>
>>We are still in the very early stages of architecture design and
> development
>
>>For now we are leaning towards keeping everything that comes with
> core-image-sato and writing a full screen app on top of it. Likely to be
> written in .NET (mono). A prototype (proof of concept) has been successfully
> developed :-)
>
>>As I said - still in very early stages of arch/design and dev. So things
> may still change.
>
>
> If it is okay to jump in an comment, I was going to ask the same question at
> some point.
>
> The need to have the application as the main UI or shell to the system is
> important for branding. Launching sato or other desktop would not be
> desirable. As an example, Windows uses Explorer.exe as the shell, but can be
> replaced with any application. Windows was architected this way. It would be
> nice to have similar architecture here, but I know it is easier said than
> done. As you said this is early in design.

We do have a lot of open questions that we will answer in good time:

1) Should the application be executed as root or as some user or as nobody

2) Should we trim the image? (we are not short on space or ram)

3) Aforementioned - should the app run from inittab or rcS.d or something else

We will figure out these things when we are on that bridge.

I do have a question - you have provided the example of Windows -
where explorer is the shell and can be changed. However, there is no
argument here - what are the clear (no brainer) or subjective
arguments for one versus the other.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto in Virtualbox

[autif khan]

On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft  wrote:
> Hi,
>
> I have build x86 qemu image using "bitbake -k core-image-sato" following the
> instructions given at
> http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html
> I'm running Ubuntu 11.10 in VirtualBox 4.1.6.
>
> When I run qemu, qemu starts apparently fine, but the qemu window stays
> black. So I'm suspecting that either it does not work in Virtualbox or I may
> have tochange some settings in qemu (e.g. -vga vmware).
>
> Here's the output:
>
> runqemu qemux86
>
> Continuing with the following parameters:
> KERNEL:
> [/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin]
> ROOTFS:
> [/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3]
> FSTYPE: [ext3]
> Setting up tap interface under sudo
> Acquiring lockfile for tap0...
> Starting distccd...
> Running qemu...
> /home/jaufranc/edev/edison-6.0-build/tmp/sysroots/i686-linux/usr/bin/qemu
> -kernel
> /home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin
> -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda
> /home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3
> -show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot
> -m 128 --append "vga=0 root=/dev/hda rw mem=128M
> ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
> Enabling opengl
>

So, what is the problem?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto in Virtualbox

[cnxsoft]

On 08/02/2012 21:06, autif khan wrote:

On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft  wrote:

Hi,

I have build x86 qemu image using "bitbake -k core-image-sato" following the
instructions given at
http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html
I'm running Ubuntu 11.10 in VirtualBox 4.1.6.

When I run qemu, qemu starts apparently fine, but the qemu window stays
black. So I'm suspecting that either it does not work in Virtualbox or I may
have tochange some settings in qemu (e.g. -vga vmware).

Here's the output:

runqemu qemux86

Continuing with the following parameters:
KERNEL:
[/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin]
ROOTFS:
[/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3]
FSTYPE: [ext3]
Setting up tap interface under sudo
Acquiring lockfile for tap0...
Starting distccd...
Running qemu...
/home/jaufranc/edev/edison-6.0-build/tmp/sysroots/i686-linux/usr/bin/qemu
-kernel
/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin
-net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda
/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3
-show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot
-m 128 --append "vga=0 root=/dev/hda rw mem=128M
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
Enabling opengl


So, what is the problem?


Qemu starts apparently fine, but the qemu window stays black.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I patch the kernel before it is built?

[autif khan]

>>> I have a meta layer where I am keeping my changes. I am guessing that I 
>>> need to:
>>>
>>> a) write a bbappend file to accomplish #1
>>> b) write a recipe to accomplish #3
>>>
>>> I have written recipes before, but just for libraries and autotools
>>> based applications. Not for a kernel module. If there is a recipe out
>>> there for some other module, I would be happy to steal from it.
>>>
>>> Please advise how I can go about patching the kernel and if there is a
>>
>> It's just like any other package. If your changes are simple, then
>> generating patches and putting them on the SRC_URI via a bbappend in
>> your layer is all you need. If you have complex changes, there are options
>> to manage them via git or via feature descriptions.
>>
>>> recipe for a kernel module - please point me to it.
>>
>> Darren validated and updated the kernel module example, so he'd probably
>> got this closer at hand than I do.
>
> See the hello-mod example under meta/recipes-kernel/hello-mod

Now, I want to load my module at startup.

The preferred way to load my module at startup would be by to place a
file called hello-mod in /etc/modutils

Is this correct?

Is there a recipe already that does this?

I see this line in kernel.bbclass - module_autoload_ipv6 = "ipv6"

So will appending module_autoload_hello-mod = "hello-mod" to this
class achieve this? I know how to append a recipe, but how do I append
a class?

When I boot my device it seems like minix and ipv6 modules are loaded,
but I can not follow how they are loaded.

Seems like ipv6 is in /etc/modutils, but minix is not.

minix is in /etc/filesystems - but I am not sure what role that file plays

Last but, not the least - was this documented somewhere and I just
could not/did not find it? Should I add this to the "How do I ..."
section of the wiki?

Thanks

Autif
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot and boost.m4 library search path problem

[McClintock Matthew-B29882]

Joshua,

Did you consider taking this patch and adding it to the proper recipe?

-M

On Wed, Feb 8, 2012 at 7:13 AM, Joshua Immanuel  wrote:
> Hello all,
>
> On Wed, 2012-02-08 at 18:19 +0530, Joshua Immanuel wrote:
>> To address this problem, I've written a patch for boost.m4
>> specifically for yocto. I believe this will be helpful to others who
>> are using boost libraries. I guess, I have to send a separate patch to
>> boost.m4 maintainer using '$with-sysroot' variable.
>
> Forgot to mention, the issue already has been reported for boost.m4 at
> https://github.com/tsuna/boost.m4/issues/26
> I have added my patch (not yocto specific one) there too.
>
> Regards
> Joshua
> --
> Joshua Immanuel
> HiPro IT Solutions Private Limited
> http://hipro.co.in
>
> ___
> 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] Yocto in Virtualbox

[Scott Garman]

On 02/08/2012 12:14 AM, cnxsoft wrote:

Hi,

I have build x86 qemu image using "bitbake -k core-image-sato" following
the instructions given at
http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html
I'm running Ubuntu 11.10 in VirtualBox 4.1.6.

When I run qemu, qemu starts apparently fine, but the qemu window stays
black. So I'm suspecting that either it does not work in Virtualbox or I
may have tochange some settings in qemu (e.g. -vga vmware).


Have you installed the Virtualbox guest additions within your VM?

Fwiw I've not run into any issues doing this with a Fedora 14 and Fedora 
16 VM (other than the builds themselves being dog slow). I make sure to 
install the guest additions in all my VMs.


Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Stewart, David C]

> From: Saul Wold [mailto:saul.w...@intel.com]
> Sent: Wednesday, February 08, 2012 1:12 AM
> 
> We finally did it!
> 
> After getting some final patches yesterday, we made it to 100% with patch
> Upsteam-Status.
> 
> Total Patches Files: 1243
> All Upstream-Status: 1243
> Fix Upstream-Status: 0
> Need Upstream-Status: 0
> Pending Upstream-Status: 461
> 
> This means we have 461 patches to now work their way into the Upstream
> communities.
> 
> Let's work to maintain this, I will be watching incoming patches and using a
> check script to verify that patches have Upstream-Status.
> 
> Thanks to all those people who worked to get Upstream-Status into their
> patches.

Nicely done, all!  I'm hoping we have can a reputation as a strong supporter of 
upstream projects, giving back wherever we can.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Osier-mixon, Jeffrey]

This sounds fantastic, and I'd love to create a page on the website
reflecting this. Just so I am clear, what exactly is this 100% of? Do we
have no local patches to upstream projects at all?

On Wed, Feb 8, 2012 at 9:07 AM, Stewart, David C
wrote:

> > From: Saul Wold [mailto:saul.w...@intel.com]
> > Sent: Wednesday, February 08, 2012 1:12 AM
> >
> > We finally did it!
> >
> > After getting some final patches yesterday, we made it to 100% with patch
> > Upsteam-Status.
> >
> > Total Patches Files: 1243
> > All Upstream-Status: 1243
> > Fix Upstream-Status: 0
> > Need Upstream-Status: 0
> > Pending Upstream-Status: 461
> >
> > This means we have 461 patches to now work their way into the Upstream
> > communities.
> >
> > Let's work to maintain this, I will be watching incoming patches and
> using a
> > check script to verify that patches have Upstream-Status.
> >
> > Thanks to all those people who worked to get Upstream-Status into their
> > patches.
>
> Nicely done, all!  I'm hoping we have can a reputation as a strong
> supporter of upstream projects, giving back wherever we can.
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Paul Eggleton]

On Wednesday 08 February 2012 09:34:56 Osier-mixon, Jeffrey wrote:
> This sounds fantastic, and I'd love to create a page on the website
> reflecting this. Just so I am clear, what exactly is this 100% of? Do we
> have no local patches to upstream projects at all?

Not quite - we still have most of the patches, it's just we've now declared on 
each and every one whether it can be/has been upstreamed.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Khem Raj]

On Wed, Feb 8, 2012 at 9:34 AM, Osier-mixon, Jeffrey
 wrote:
> This sounds fantastic, and I'd love to create a page on the website
> reflecting this. Just so I am clear, what exactly is this 100% of? Do we
> have no local patches to upstream projects at all?

it means that all patches have a field 'Upstream-Status'
and for most of them it reflects the status of patch w.r.t. upstream
of given package
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Osier-mixon, Jeffrey]

Ah, documentation :)  excellent

On Wed, Feb 8, 2012 at 9:45 AM, Khem Raj  wrote:

> On Wed, Feb 8, 2012 at 9:34 AM, Osier-mixon, Jeffrey
>  wrote:
> > This sounds fantastic, and I'd love to create a page on the website
> > reflecting this. Just so I am clear, what exactly is this 100% of? Do we
> > have no local patches to upstream projects at all?
>
> it means that all patches have a field 'Upstream-Status'
> and for most of them it reflects the status of patch w.r.t. upstream
> of given package
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Saul Wold]

On 02/08/2012 10:04 AM, Osier-mixon, Jeffrey wrote:

Ah, documentation :)  excellent



Jefro:

You can get more info about this from Mark's OE page:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

The Key thing to note on my numbers is that we have 461 patches that 
could potentially be up-streamed to other communities, depending the 
status of those communities, from active communities accepting patches 
to upstream source that is just download-able with no activity or 
maintainers.


We have 1243 patches overall, which include OE Specific configuration 
patches and Embedded specific tweaks to various upstreams that may not 
be appropriate or acceptable to the upstream community.


Sau!





On Wed, Feb 8, 2012 at 9:45 AM, Khem Raj mailto:raj.k...@gmail.com>> wrote:

On Wed, Feb 8, 2012 at 9:34 AM, Osier-mixon, Jeffrey
mailto:jeffrey.osier-mi...@intel.com>> wrote:
 > This sounds fantastic, and I'd love to create a page on the website
 > reflecting this. Just so I am clear, what exactly is this 100%
of? Do we
 > have no local patches to upstream projects at all?

it means that all patches have a field 'Upstream-Status'
and for most of them it reflects the status of patch w.r.t. upstream
of given package




--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org




___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Björn Stenberg]

Saul Wold wrote:
> After getting some final patches yesterday, we made it to 100% with
> patch Upsteam-Status.

Who sets the Upstream-Status? Are there guidelines how to do it?

I spoke to the author of curl and mentioned the two patches in Yocto against 
it, both of which are marked as "Upstream-Status: Inappropriate". He said those 
patches were never submitted to him.

Are we dismissing patches without even giving upstream a chance to comment?

-- 
Björn
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] About Pandaboard

[Sertaç Olgunsoylu]

Hi,
I've recently found this amazing project and I'd really love to contribute
to it. So, I have a question. Is there any ongoing effort or interest on
adding Pandaboard to the supported hardware? If so, I'd like to give a hand
to you. I can test software stack on that platform, file bugs and try to
resolve them. I don't have so much experience on embedded linux but I have
great desire to learn. Also, I believe that the most appropriate place to
achieve that goal is participating in open source projects. I found Yocto
amazing, exciting and promising. I'd love to be part of it.

Please let me know what I can do for that project..

Looking forward to hear from you
Sertac
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Saul Wold]

On 02/08/2012 02:07 AM, Björn Stenberg wrote:

Saul Wold wrote:

After getting some final patches yesterday, we made it to 100% with
patch Upsteam-Status.


Who sets the Upstream-Status? Are there guidelines how to do it?

The developer of the patch submitted to any OE branch (oe-core, meta-oe, 
...) should add the appropriate Upstream-Status entry.


See: http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

We had a big push within the OE-Core team to try and determine if 
patches are appropriate for upstream or not.



I spoke to the author of curl and mentioned the two patches in Yocto against it, both of 
which are marked as "Upstream-Status: Inappropriate". He said those patches 
were never submitted to him.

Are we dismissing patches without even giving upstream a chance to comment?


In some cases yes we might be doing that, particularly patches that 
seemed to be specific to the OE cross compilation environment or to deal 
with packaging with in the embedded space where marked as Inappropriate. 
 Once we get though round one of the obvious potential upstream-able 
patches we can revisit other.


If the author of curl would like to review and/or implement modification 
for OE that would be awesome, feel free to share the patches with them.


Sau!

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Khem Raj]

On Wed, Feb 8, 2012 at 2:07 AM, Björn Stenberg  wrote:
> Who sets the Upstream-Status? Are there guidelines how to do it?
>

patch author importer whoever brings this patch in into oe. Sometimes
there might be judgement error on patches
thats why I said "for most of them it reflects the status of patch
w.r.t. upstream"

> I spoke to the author of curl and mentioned the two patches in Yocto against 
> it, both of which are marked as "Upstream-Status: Inappropriate". He said 
> those patches were never submitted to him.
>
> Are we dismissing patches without even giving upstream a chance to comment?

Thats not the intention at all. All patches should go upstream from
OE's POV it would be cool to have 0 patches locally
If someone had better insights into patches and submit more
appropriate analysis of patches thats welcome
all the time.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] About Pandaboard

[Khem Raj]

On Tue, Feb 7, 2012 at 11:16 PM, Sertaç Olgunsoylu
 wrote:
> Hi,
> I've recently found this amazing project and I'd really love to contribute
> to it. So, I have a question. Is there any ongoing effort or interest on
> adding Pandaboard to the supported hardware? If so, I'd like to give a hand
> to you. I can test software stack on that platform, file bugs and try to
> resolve them. I don't have so much experience on embedded linux but I have
> great desire to learn. Also, I believe that the most appropriate place to
> achieve that goal is participating in open source projects. I found Yocto
> amazing, exciting and promising. I'd love to be part of it.
>
> Please let me know what I can do for that project..

its maintained on meta-ti layer. So probably asking
meta...@yoctoproject.org would be good.
https://lists.yoctoproject.org/listinfo/meta-ti

>
> Looking forward to hear from you
> Sertac
>
> ___
> 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] Building your own UI

[Sean Liming]

>>> This may be a dumb question, but I'll ask anyway.
>>
>>> Suppose you have a project where you need a very custom user 
>>> interface. Not just a series of applications that appear on a 
>>> desktop like you see in sato, or Gnome, or KDE.  Basically your 
>>> application
> becomes the UI.
>>
>>> I can see 2 approaches to this:
>>
>>> Start with core-image-minimal and add the packages you need to 
>>> support GFX, X11, and your application plus dependencies.
>>> Take core-image-sato and change the applications to be your subtasks 
>>> , and the look-and-feel of the desktop.
>>
>>> What are the considerations of both approaches?
>> >Is one better, or easier than the other?
>> >How would you do this in Yocto?
>>> Where do you look for information you need to accomplish this?
>
>>We are still in the very early stages of architecture design and
>> development
>
>>For now we are leaning towards keeping everything that comes with
> >core-image-sato and writing a full screen app on top of it. Likely to 
> >be written in .NET (mono). A prototype (proof of concept) has been 
> >successfully developed :-)
>
>>As I said - still in very early stages of arch/design and dev. So 
>>things
> >may still change.
>
>
> >If it is okay to jump in an comment, I was going to ask the same 
> >question at some point.
>
> >The need to have the application as the main UI or shell to the system 
> >is important for branding. Launching sato or other desktop would not 
>> be desirable. As an example, Windows uses Explorer.exe as the shell, 
>> but can be replaced with any application. Windows was architected this 
>> way. It would be nice to have similar architecture here, but I know it 
> >is easier said than done. As you said this is early in design.

>We do have a lot of open questions that we will answer in good time:

>1) Should the application be executed as root or as some user or as nobody

>2) Should we trim the image? (we are not short on space or ram)

>3) Aforementioned - should the app run from inittab or rcS.d or something
else

>We will figure out these things when we are on that bridge.

>I do have a question - you have provided the example of Windows - where
explorer is the shell and can be changed. However, there is no argument here
- what are >the clear (no brainer) or subjective arguments for one versus
the other.

There are two reasons or user models: security and branding.

Using the Windows example. A system boots to Explorer desktop and then
launches an application. If someone can close the application and get to the
desktop, it is a security vulnerability someone could get into all sorts of
data and control panel settings.  By switching the application as the shell
(replacing explorer.exe) where the OEM has created a unique UI for the
device, it locks the system down. The custom shell can also provide controls
or back door access for administrative functions like display and network
settings. For Windows the devices boots to the Administrator account so the
application is not impeded from the system.

A custom UI helps with branding by creating a unique UI, the device has a
unique look and feel that tells the user this is a device and they have no
idea what is underneath. Launching Explorer and then the application doesn't
create the unique device look and feel.

Another method that OEMs do with Windows is to have a base shell launches
the main application. Again, the base shell replaces the  Explorer.exe with
something that is unique for the devices. If the main application needs to
be replaced, the main application can be shut down and the base shell still
provides some UI to perform the upgrade.

I am new to Linux embedded so I don't know how this would be architected.




___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building your own UI

[jfabernathy]

On 02/07/2012 07:47 PM, Joshua Lock wrote:



On 07/02/12 13:54, jfabernathy wrote:

On 02/07/2012 01:54 PM, Joshua Lock wrote:

On 07/02/12 07:57, James Abernathy wrote:

This may be a dumb question, but I'll ask anyway.
Suppose you have a project where you need a very custom user 
interface.
Not just a series of applications that appear on a desktop like you 
see

in sato, or Gnome, or KDE. Basically your application becomes the UI.
I can see 2 approaches to this:

1. Start with core-image-minimal and add the packages you need to
support GFX, X11, and your application plus dependencies.
2. Take core-image-sato and change the applications to be your 
subtasks

, and the look-and-feel of the desktop.

What are the considerations of both approaches?


A key selling point of the Yocto approach is to provide a highly
customised OS for your target application, rather than taking an
existing solution and stripping it back.

2. is the antithesis of the Yocto approach if you don't want/need the
Sato UI.

The intention is that the core metadata should provide sufficient
granularity through the defined images and tasks to get people started.

I'd recommend something like 1. only taking core-image-core (horrible
name I know) if you want an X based OS.


I built core-image-core and it works and is basic. So it's not a really
small Sato???


We no doubt need more documentation in this area, and Hob is designed
to help here.



Is one better, or easier than the other?


Creating your own image is better in that you only build and ship what
you need. Arguably building atop a custom image is easier, but you
lose control.


How would you do this in Yocto?


You might consider creating a custom image by starting with
core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries
to provide the core functionality you desire.

$ less foo.bb
# a noddy example image, base of a NAS OS

# start with core-image-minimal
require recipes-core/images/core-image-minimal.bb

IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
IMAGE_INSTALL += "my-custom-nas-app"


I have difficulty understanding the difference in IMAGE_FEATURES and
IMAGE_INSTALL. To me IMAGE_INSTALL is clear I've used that in a
core-image-sato.bbappend file in an image directory in my own recipes-xx
directory. I see how IMAGE_FEATURES is uses in the core-image-core:

IMAGE_FEATURES += "apps-console-core ${X11_IMAGE_FEATURES}"

But I have no idea what ${X11_IMAGE_FEATURES} is or how to find where
it's defined. The apps-console-core is define in the Poky Refernce 
manual:


http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image 




However, I'm not sure were to find it's definition in the many recipes.


The features are defined in core-image.bbclass:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass 



Most of them translate into one or more task recipes 
(meta/recipes-*/tasks/) except package-management which translates to 
ROOTFS_PKGMANAGE which in turn is defined in each of the package 
management rootfs construction classes (meta/classes/rootfs_*.bbclass).


Thanks, Joshua,

I have build a number of the images with minimal x11 features to see the 
difference. All of them appear to be the basic Sato without the apps or 
borders. And all start with the bit Yocto Project Splash screen.  I 
remember back a few years and it may go back to more than that, you 
could launch just X without a window manager or at least a basic one and 
all you had was one xterm session. You could right click and create 
another xterm, but anything else had to be launched from the command 
line in the xterm.  like glxgears, mplayer, etc.  It was a good way of 
testing without committing to a look and feel.  Does that level exist in 
Yocto.  I'm not seeing how I use what I'm seeing even with the x11-basic 
to create a custom platform look.


BTW, I built core-image-clutter and it looks just like core-image-sato.  
Not sure the difference.
Also build the qt4e-demo-image.  That is pretty cool demo.  Probably 
takes a lot to figure out how to following that look and feel.


JIm A


Aside: I usually rely in git grep to track down where a variable is 
defined.


Cheers,
Joshua


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Daniel Stenberg]

On Wed, 8 Feb 2012, Saul Wold wrote:

If the author of curl would like to review and/or implement modification for 
OE that would be awesome, feel free to share the patches with them.


I am the maintainer of curl.

The curl patches Björn mentioned are clearly not written in way intended to be 
"upstreamable" so they cannot be accepted by the curl project and nobody has 
tried to.


This said, at least one of the patches fixes a problem that still exists 
upstream but the yocto patch [*] is made in such a hard-coded way it'd have to 
be seriously edited to get accepted. The flaw has not even been discussed with 
or mentioned to the curl project AFAICR...


So, room for improvements!

[*] = 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/curl/curl/noldlibpath.patch

--

 / daniel.haxx.se___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Khem Raj]

On Wed, Feb 8, 2012 at 1:26 PM, Daniel Stenberg  wrote:
> On Wed, 8 Feb 2012, Saul Wold wrote:
>
>> If the author of curl would like to review and/or implement modification
>> for OE that would be awesome, feel free to share the patches with them.
>
>
> I am the maintainer of curl.
>
> The curl patches Björn mentioned are clearly not written in way intended to
> be "upstreamable" so they cannot be accepted by the curl project and nobody
> has tried to.
>
> This said, at least one of the patches fixes a problem that still exists
> upstream but the yocto patch [*] is made in such a hard-coded way it'd have
> to be seriously edited to get accepted. The flaw has not even been discussed
> with or mentioned to the curl project AFAICR...
>
> So, room for improvements!

We understand the lack of upstreaming hence the process of documenting
the patches with Upstream-Status
was put in place. So step by step we are getting there where we will
be able to interact with upstream projects
on the patches we carry. The first step it to account for them which
we did. Next step
would be to interact with respective upstream projects and propose the
patches or describe
the problems if they are to be fixed differently.

-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Upstream-Status finally @ 100%

[Paul Menzel]

Am Mittwoch, den 08.02.2012, 10:45 -0800 schrieb Saul Wold:
> On 02/08/2012 10:04 AM, Osier-mixon, Jeffrey wrote:
> > Ah, documentation :)  excellent

Saul, thank you for the update and enforcing that requirement from the
commit and patch message guidelines.

> Jefro:
> 
> You can get more info about this from Mark's OE page:
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> 
> The Key thing to note on my numbers is that we have 461 patches that 
> could potentially be up-streamed to other communities, depending the 
> status of those communities, from active communities accepting patches 
> to upstream source that is just download-able with no activity or 
> maintainers.

Emphasis should be laid on *could*. Sending these patches upstream still
has to be done most of the time and most developers do not spend time
with that. I hope that will improve in the future somehow.

> We have 1243 patches overall, which include OE Specific configuration 
> patches and Embedded specific tweaks to various upstreams that may not 
> be appropriate or acceptable to the upstream community.



Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Upstream-Status finally @ 100%

[Saul Wold]

On 02/08/2012 01:26 PM, Daniel Stenberg wrote:

On Wed, 8 Feb 2012, Saul Wold wrote:


If the author of curl would like to review and/or implement
modification for OE that would be awesome, feel free to share the
patches with them.


I am the maintainer of curl.

The curl patches Björn mentioned are clearly not written in way intended
to be "upstreamable" so they cannot be accepted by the curl project and
nobody has tried to.

I am sure there are many patches like that in OE, they are written, 
tested and then forgotten about, our goal here is to not let them get 
forgotten.



This said, at least one of the patches fixes a problem that still exists
upstream but the yocto patch [*] is made in such a hard-coded way it'd
have to be seriously edited to get accepted. The flaw has not even been
discussed with or mentioned to the curl project AFAICR...

So, room for improvements!

[*] =
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/curl/curl/noldlibpath.patch




Daniel,

I think Khem has already said that we are taking incremental steps here, 
as I mentioned in my prior email, we have over 1200 patches lurking 
around in OE currently, initially we have about 460 as marked as pending.


If you can fix those issues, since we can't address all of them 
initially or be experts in all upstreams, we would be very grateful to 
remove 1 or 2 more patches.


Thanks for your understanding.

Sau!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building your own UI

[Joshua Lock]

On 08/02/12 12:52, jfabernathy wrote:

On 02/07/2012 07:47 PM, Joshua Lock wrote:

On 07/02/12 13:54, jfabernathy wrote:

On 02/07/2012 01:54 PM, Joshua Lock wrote:

On 07/02/12 07:57, James Abernathy wrote:

This may be a dumb question, but I'll ask anyway.
Suppose you have a project where you need a very custom user
interface.
Not just a series of applications that appear on a desktop like you
see
in sato, or Gnome, or KDE. Basically your application becomes the UI.
I can see 2 approaches to this:

1. Start with core-image-minimal and add the packages you need to
support GFX, X11, and your application plus dependencies.
2. Take core-image-sato and change the applications to be your
subtasks
, and the look-and-feel of the desktop.

What are the considerations of both approaches?


A key selling point of the Yocto approach is to provide a highly
customised OS for your target application, rather than taking an
existing solution and stripping it back.

2. is the antithesis of the Yocto approach if you don't want/need the
Sato UI.

The intention is that the core metadata should provide sufficient
granularity through the defined images and tasks to get people started.

I'd recommend something like 1. only taking core-image-core (horrible
name I know) if you want an X based OS.


I built core-image-core and it works and is basic. So it's not a really
small Sato???


We no doubt need more documentation in this area, and Hob is designed
to help here.



Is one better, or easier than the other?


Creating your own image is better in that you only build and ship what
you need. Arguably building atop a custom image is easier, but you
lose control.


How would you do this in Yocto?


You might consider creating a custom image by starting with
core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries
to provide the core functionality you desire.

$ less foo.bb
# a noddy example image, base of a NAS OS

# start with core-image-minimal
require recipes-core/images/core-image-minimal.bb

IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
IMAGE_INSTALL += "my-custom-nas-app"


I have difficulty understanding the difference in IMAGE_FEATURES and
IMAGE_INSTALL. To me IMAGE_INSTALL is clear I've used that in a
core-image-sato.bbappend file in an image directory in my own recipes-xx
directory. I see how IMAGE_FEATURES is uses in the core-image-core:

IMAGE_FEATURES += "apps-console-core ${X11_IMAGE_FEATURES}"

But I have no idea what ${X11_IMAGE_FEATURES} is or how to find where
it's defined. The apps-console-core is define in the Poky Refernce
manual:

http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image



However, I'm not sure were to find it's definition in the many recipes.


The features are defined in core-image.bbclass:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass


Most of them translate into one or more task recipes
(meta/recipes-*/tasks/) except package-management which translates to
ROOTFS_PKGMANAGE which in turn is defined in each of the package
management rootfs construction classes (meta/classes/rootfs_*.bbclass).


Thanks, Joshua,

I have build a number of the images with minimal x11 features to see the
difference. All of them appear to be the basic Sato without the apps or
borders. And all start with the bit Yocto Project Splash screen. I
remember back a few years and it may go back to more than that, you
could launch just X without a window manager or at least a basic one and
all you had was one xterm session. You could right click and create
another xterm, but anything else had to be launched from the command
line in the xterm. like glxgears, mplayer, etc. It was a good way of
testing without committing to a look and feel. Does that level exist in
Yocto. I'm not seeing how I use what I'm seeing even with the x11-basic
to create a custom platform look.


It's perfectly possible, it just may be that you have to create your own 
bare bones image.


The problem with trying to provide generic tasks and images is that 
everyones opinion of what constitutes minimal/bare bones is different. :-)


This thread has made it clear that we need to expedite the formation of 
some documentation guiding folks through building custom images.


Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto in Virtualbox

[cnxsoft]

On 09/02/2012 00:00, Scott Garman wrote:

On 02/08/2012 12:14 AM, cnxsoft wrote:

Hi,

I have build x86 qemu image using "bitbake -k core-image-sato" following
the instructions given at
http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html 


I'm running Ubuntu 11.10 in VirtualBox 4.1.6.

When I run qemu, qemu starts apparently fine, but the qemu window stays
black. So I'm suspecting that either it does not work in Virtualbox or I
may have tochange some settings in qemu (e.g. -vga vmware).


Have you installed the Virtualbox guest additions within your VM?

Fwiw I've not run into any issues doing this with a Fedora 14 and 
Fedora 16 VM (other than the builds themselves being dog slow). I make 
sure to install the guest additions in all my VMs.


Scott

Thanks Scott.  Yes, I have Virtual Box guest additions installed. My 
host is running Windows XP btw. And yes it was slow...the build for 
core-image-minimal took around 36 hours...
I found a link with a Virtual Box issue 
(https://wiki.yoctoproject.org/wiki/Build_Appliance_Design), but it seem 
related to the build itself rather than an issue while running qemu.



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto in Virtualbox

[Scott Garman]

On 02/08/2012 06:01 PM, cnxsoft wrote:

On 09/02/2012 00:00, Scott Garman wrote:

On 02/08/2012 12:14 AM, cnxsoft wrote:

Hi,

I have build x86 qemu image using "bitbake -k core-image-sato" following
the instructions given at
http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html

I'm running Ubuntu 11.10 in VirtualBox 4.1.6.

When I run qemu, qemu starts apparently fine, but the qemu window stays
black. So I'm suspecting that either it does not work in Virtualbox or I
may have tochange some settings in qemu (e.g. -vga vmware).


Have you installed the Virtualbox guest additions within your VM?

Fwiw I've not run into any issues doing this with a Fedora 14 and
Fedora 16 VM (other than the builds themselves being dog slow). I make
sure to install the guest additions in all my VMs.

Scott


Thanks Scott. Yes, I have Virtual Box guest additions installed. My host
is running Windows XP btw. And yes it was slow...the build for
core-image-minimal took around 36 hours...
I found a link with a Virtual Box issue
(https://wiki.yoctoproject.org/wiki/Build_Appliance_Design), but it seem
related to the build itself rather than an issue while running qemu.


Hmmm...I'm not sure what to tell you. Really grasping for straws here - 
one thing you could try is to export the image and load it into VMWare 
Player and see if there is any difference. If not, that would implicate 
the guest distro (Ubuntu 11.10).


Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] applying a custom kernel configuration to the "built in" routerstation pro bsp?

[David Smoot]

I want to change some of the kernel configuration options for my routerstation 
pro.  I have a .config from a 2.6.37 kernel running on my routerstation pro 
that was not built in Yocto that has the options I want to build in Yocto.  I 
am attempting to follow the instructions at 
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#bsp-filelayout-kernel.
 But I am confused.  

Since I am using the routerstation pro, I do not have a separate BSP, it is 
"built in".  So I know I need to modify a .bbappend file to point to my config 
file, but I am not sure which bbappend where.

Thanks for your time.
David Smoot
davidsm...@gmail.com



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto in Virtualbox

[David Smoot]

On Feb 8, 2012, at 8:18 AM, cnxsoft wrote:

On 08/02/2012 21:06, autif khan wrote:
> On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft  wrote:
>> Hi,
>> 
>> .255.0 oprofile.timer=1 "
>> Enabling opengl
>> 
> So, what is the problem?

>Qemu starts apparently fine, but the qemu window stays black.

I would try one of the pre-built images to isolate the problem between running 
inside virtualbox and your build. 


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

David Smoot
davidsm...@gmail.com



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto in Virtualbox

[Scott Garman]

On 02/08/2012 07:11 PM, David Smoot wrote:


On Feb 8, 2012, at 8:18 AM, cnxsoft wrote:

On 08/02/2012 21:06, autif khan wrote:

On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft   wrote:

Hi,

.255.0 oprofile.timer=1 "
Enabling opengl


So, what is the problem?



Qemu starts apparently fine, but the qemu window stays black.


I would try one of the pre-built images to isolate the problem between running 
inside virtualbox and your build.


This would be much quicker to test than my "export to VMWare Player" 
suggestion. I'd definitely try this first.


Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] applying a custom kernel configuration to the "built in" routerstation pro bsp?

[Khem Raj]

On (08/02/12 21:08), David Smoot wrote:
> I want to change some of the kernel configuration options for my 
> routerstation pro.  I have a .config from a 2.6.37 kernel running on my 
> routerstation pro that was not built in Yocto that has the options I want to 
> build in Yocto.  I am attempting to follow the instructions at 
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#bsp-filelayout-kernel.
>  But I am confused.  
> 
> Since I am using the routerstation pro, I do not have a separate BSP, it is 
> "built in".  So I know I need to modify a .bbappend file to point to my 
> config file, but I am not sure which bbappend where.

inside meta-yocto/recipes-bsp/formfactor/formfactor create a dir called
routerstationpro and inside that dir create file called 'machconfig'
add the kconfig options that you are missing in standard config to
this file

HTH

-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] applying a custom kernel configuration to the "built in" routerstation pro bsp?

[Bruce Ashfield]

On Wed, Feb 8, 2012 at 10:08 PM, David Smoot  wrote:
> I want to change some of the kernel configuration options for my
> routerstation pro.  I have a .config from a 2.6.37 kernel running on my
> routerstation pro that was not built in Yocto that has the options I want to
> build in Yocto.  I am attempting to follow the instructions
> at http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#bsp-filelayout-kernel.
> But I am confused.
>
> Since I am using the routerstation pro, I do not have a separate BSP, it is
> "built in".  So I know I need to modify a .bbappend file to point to my
> config file, but I am not sure which bbappend where.

Built in or not .. it's all the same. Put the config items you want into a .cfg
file of the name of your choice.

In the layer of your choice, create a linux-yocto_2.6.37.bbappend file,
and list the .cfg file on the SRC_URI (just like you would any patch or other
source file). Those config items will be added to the board after the built in
options and will override anything that was previously set.

If you were working with a local git repository, you could commit the change
directly to the tree .. but it doesn't sound like you are working in that model.

Cheers,

Bruce

>
> Thanks for your time.
> David Smoot
> davidsm...@gmail.com
>
>
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot and boost.m4 library search path problem

[Joshua Immanuel]

Hello McClintock,

On Wed, 2012-02-08 at 15:44 +, McClintock Matthew-B29882 wrote:
> Did you consider taking this patch and adding it to the proper recipe?

The patch is basically for boost.m4. We have the boost package in 'meta'
layer. But, boost.m4 is not a part of boost library, it is maintained
separately. As the boost doesn't support pkgconfig, boost.m4 comes to
the rescue for finding installed boost libraries.

So, this doesn't fit into any existing recipe. Whichever (autotools
build system based) application uses boost library will obviously use
boost.m4 and this patch is for them.

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto