Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)
On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon wrote: > Hi all, Autif, > > I've been working to support .NET development on Linux > over the past few days. > > There is a Visual Studio plugin, MonoTools for Visual Studio > which provides support for local and remote debugging of > .NET applications with Mono. > > This requires a remote stub to be running on the target > platform, monotools-server. > > I've created a recipe to build monotools-server, which in > turn required me to pull in Openembedded Legacy recipes > for mono-xsp and gtk-sharp. > > As it stands I'm now able to build an X enabled image for > the Raspberry Pi and remote-debug some simple Windows > Forms .NET applications within the Visual Studio IDE. > > Recipes are hosted here in 'recipes-mono' > > g...@git.assembla.com:ciseco-eve.meta-eve.git > > If there is interest in migrating these recipes into meta-mono > and somebody will review them then I'll be pleased to make > whatever changes are needed to comply with relevant > Yocto policies. Absolutely! I am about to embark on a vacation returning to work on Jan 7. More then - Unfortunately, I will not have time to look at this today or until Jan 7. Working hard - then playing hard :-) I will dig into then when I return. (Side note - we gave up on GTK# recipe and decided that Windows forms are 'good enough' for us. This makes me glad :-) > > Best Regards, (& Happy Holidays) > > Alex > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)
On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan wrote: > On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon > wrote: >> Hi all, Autif, >> >> I've been working to support .NET development on Linux >> over the past few days. >> >> There is a Visual Studio plugin, MonoTools for Visual Studio >> which provides support for local and remote debugging of >> .NET applications with Mono. >> >> This requires a remote stub to be running on the target >> platform, monotools-server. >> >> I've created a recipe to build monotools-server, which in >> turn required me to pull in Openembedded Legacy recipes >> for mono-xsp and gtk-sharp. >> >> As it stands I'm now able to build an X enabled image for >> the Raspberry Pi and remote-debug some simple Windows >> Forms .NET applications within the Visual Studio IDE. >> >> Recipes are hosted here in 'recipes-mono' >> >> g...@git.assembla.com:ciseco-eve.meta-eve.git I could not "git clone" the repo. Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses. If the license is different for monotools-server or mono-xsp or gtk-sharp, you will likely have to submit a patch for README file too. Even otherwise, section 4 in README needs to be updated. If you have any tasks left - please add them to section 10. The guidelines for the Yocto project are very similar to other FOSS projects including the Linux kernel. They are outlined here: https://wiki.yoctoproject.org/wiki/Contribution_Guidelines I used the following as a guide when I have submitted my patches in the past. This is for the Linux kernel, adapt as appropriate for meta-mono. http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/ Please submit separate patches for each of the recipes (presumably there are no changes to the mono/libGDI+ recipes) Please add me to the "To:" recipient (I filter a lot of PATCH related traffic) - this should allow the emails to be caught by the filter instead of archiving. In case I do not respond within 72 hours, please email me with a gentle reminder :-) I have not had the opportunity to integrate patches just yet, please bear with me in case I screw up. Thanks again for contributing! PS #1: If you do not want to go thru the hassle - please email me the tar.gz as an attachment and I will check it in directly - a bad side effect of this would be that you will not get any "git" credit for this PS #2: I am still on vacation, but had a few hours - the 72 hour clock will start only after Monday :-) And finally, PS #3: http://marc.info/?l=linux-usb&m=135229956521385&w=2 http://marc.info/?l=linux-usb&m=135119051922403&w=2 http://marc.info/?l=linux-usb&m=134858043613838&w=2 http://marc.info/?l=linux-usb&m=134791970203982&w=2 ... many others ... Please refrain from top posting :-) Autif >> If there is interest in migrating these recipes into meta-mono >> and somebody will review them then I'll be pleased to make >> whatever changes are needed to comply with relevant >> Yocto policies. > > Absolutely! > > I am about to embark on a vacation returning to work on Jan 7. > > More then - Unfortunately, I will not have time to look at this today > or until Jan 7. > > Working hard - then playing hard :-) > > I will dig into then when I return. > > (Side note - we gave up on GTK# recipe and decided that Windows forms > are 'good enough' for us. This makes me glad :-) > >> >> Best Regards, (& Happy Holidays) >> >> Alex >> >> ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)
On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon wrote: > On 02/01/2013 20:27, Autif Khan wrote: >> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan wrote: >>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon >>> wrote: >>>> Hi all, Autif, >>>> >>>> I've been working to support .NET development on Linux >>>> over the past few days. >>>> >>>> There is a Visual Studio plugin, MonoTools for Visual Studio >>>> which provides support for local and remote debugging of >>>> .NET applications with Mono. >>>> >>>> This requires a remote stub to be running on the target >>>> platform, monotools-server. >>>> >>>> I've created a recipe to build monotools-server, which in >>>> turn required me to pull in Openembedded Legacy recipes >>>> for mono-xsp and gtk-sharp. >>>> >>>> As it stands I'm now able to build an X enabled image for >>>> the Raspberry Pi and remote-debug some simple Windows >>>> Forms .NET applications within the Visual Studio IDE. >>>> >>>> Recipes are hosted here in 'recipes-mono' >>>> >>>> g...@git.assembla.com:ciseco-eve.meta-eve.git >> >> I could not "git clone" the repo. > > Apologies. I should have given you the public r/o link. > > Originally I was trying to avoid modifying meta-mono, adding .bbappends > into my own meta-eve layer instead, but since my last post to you I > found I couldn't build against the current HEAD of Yocto due to some odd > file location issues which I couldn't overlay. (i.e. it didn't seem to > be able to pick up the patches where you had them - although was fine > with an older commit of the Yocto core). > > As a result I've moved the original meta-mono patches that weren't being > picked up by bitbake and merged my additions into a fork of meta-mono > which is here: > > git://git.assembla.com/ciseco-eve.meta-mono.git Got it. I scanned thru the code and saw what you did to re-organize the directory structure. When I get back, I will see if I can build libGDI+ and mono with denzil (I am stuck with denzil for reasons beyond my control, or until I find a show stopping bug in denzil for our project - unlikely) Meanwhile, I have no questions about changes for gk-sharp, mono, mono-xsp and monotools-server. Presumably, you will take care of the "TODO: This needs fixing properly and needs to be revisited" in mono_.bb - I definitely do not want unstripped binaries on my distribution - presumably, this was needed for some debugging and is not meant to be checked into production. I could not understand the purpose of libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch - could you please help me understand what prompted these seemingly non trivial changes. Everything else looks good. > I'm coming up the curve on Git, as I migrate from mainly Subversion use. > Can I issue a "pull request" to you or some such? Yes, a pull request should work. >> Presumably, you want to release the recipes with the MIT and/or GPLv2 >> licenses. >> >> If the license is different for monotools-server or mono-xsp or >> gtk-sharp, you will likely have to submit a patch for README file too. >> Even otherwise, section 4 in README needs to be updated. If you have >> any tasks left - please add them to section 10. >> > > Will double check this. I am waiting for feedback from the > monotools-server people on their license as there's nothing explicit in > their source. Will wait for that. Might affect the README >> The guidelines for the Yocto project are very similar to other FOSS >> projects including the Linux kernel. They are outlined here: >> >> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines >> >> I used the following as a guide when I have submitted my patches in >> the past. This is for the Linux kernel, adapt as appropriate for >> meta-mono. >> >> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/ >> >> Please submit separate patches for each of the recipes (presumably >> there are no changes to the mono/libGDI+ recipes) >> >> Please add me to the "To:" recipient (I filter a lot of PATCH related >> traffic) - this should allow the emails to be caught by the filter >> instead of archiving. >> >> In case I do not respond within 72 hours, please email me with a >> gentle reminder :-) >> >> I have not had the opportunity to integrate patches just yet, please >> bear with me
Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)
On Thu, Jan 3, 2013 at 10:45 AM, Alex J Lennon wrote: > On 03/01/2013 15:24, Autif Khan wrote: >> On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon >> wrote: >>> On 02/01/2013 20:27, Autif Khan wrote: >>>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan wrote: >>>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon >>>>> wrote: >>>>>> Hi all, Autif, >>>>>> >>>>>> I've been working to support .NET development on Linux >>>>>> over the past few days. >>>>>> >>>>>> There is a Visual Studio plugin, MonoTools for Visual Studio >>>>>> which provides support for local and remote debugging of >>>>>> .NET applications with Mono. >>>>>> >>>>>> This requires a remote stub to be running on the target >>>>>> platform, monotools-server. >>>>>> >>>>>> I've created a recipe to build monotools-server, which in >>>>>> turn required me to pull in Openembedded Legacy recipes >>>>>> for mono-xsp and gtk-sharp. >>>>>> >>>>>> As it stands I'm now able to build an X enabled image for >>>>>> the Raspberry Pi and remote-debug some simple Windows >>>>>> Forms .NET applications within the Visual Studio IDE. >>>>>> >>>>>> Recipes are hosted here in 'recipes-mono' >>>>>> >>>>>> g...@git.assembla.com:ciseco-eve.meta-eve.git >>>> >>>> I could not "git clone" the repo. >>> >>> Apologies. I should have given you the public r/o link. >>> >>> Originally I was trying to avoid modifying meta-mono, adding .bbappends >>> into my own meta-eve layer instead, but since my last post to you I >>> found I couldn't build against the current HEAD of Yocto due to some odd >>> file location issues which I couldn't overlay. (i.e. it didn't seem to >>> be able to pick up the patches where you had them - although was fine >>> with an older commit of the Yocto core). >>> >>> As a result I've moved the original meta-mono patches that weren't being >>> picked up by bitbake and merged my additions into a fork of meta-mono >>> which is here: >>> >>> git://git.assembla.com/ciseco-eve.meta-mono.git >> >> Got it. >> >> I scanned thru the code and saw what you did to re-organize the >> directory structure. >> >> When I get back, I will see if I can build libGDI+ and mono with >> denzil (I am stuck with denzil for reasons beyond my control, or until >> I find a show stopping bug in denzil for our project - unlikely) >> >> Meanwhile, I have no questions about changes for gk-sharp, mono, >> mono-xsp and monotools-server. >> > > Good oh. > >> Presumably, you will take care of the "TODO: This needs fixing >> properly and needs to be revisited" in mono_.bb - I >> definitely do not want unstripped binaries on my distribution - >> presumably, this was needed for some debugging and is not meant to be >> checked into production. > > Ah yes. I'd forgotten about that. I shall habe to revisit why that was > erroring. > >> I could not understand the purpose of >> libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch - >> could you please help me understand what prompted these seemingly non >> trivial changes. >> > > Yes there seems to be a problem building libGDI against libpng15. It > seems a known issue: > > https://github.com/mono/libgdiplus/pull/4 > >> Everything else looks good. >> > > Good oh > >>> I'm coming up the curve on Git, as I migrate from mainly Subversion use. >>> Can I issue a "pull request" to you or some such? >> >> Yes, a pull request should work. >> >>>> Presumably, you want to release the recipes with the MIT and/or GPLv2 >>>> licenses. >>>> >>>> If the license is different for monotools-server or mono-xsp or >>>> gtk-sharp, you will likely have to submit a patch for README file too. >>>> Even otherwise, section 4 in README needs to be updated. If you have >>>> any tasks left - please add them to section 10. >>>> >>> >>> Will double check this. I am waiting for feedback from the >>> monotools-server people on their license as there's nothing explicit in >>> their sour
Re: [yocto] Busybox still old version: Still looking for a clear understanding of an old mystery.
On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker wrote: > Hi Rudolf, > > > On 1/15/2013 3:28 PM, Rudolf Streif wrote: >> >> >> Brian, >> >> What are you exactly referring to as "new version"? The package version >> that bitbake builds is defined by the recipe, through the version >> designation in the recipe's file name or through explicitly setting PV. >> >> I think what you are trying to do is to modify the busybox configuration >> and then recompile and package. Bitbake will not automatically recompile >> after menuconfig. Menuconfig does not invslidate the shared state cache. Try >> this: >> >> bitbake -c menuconfig busybox >> bitbake -c -f compile busybox >> bitbake busybox >> >> > So I have done the above. That is not the question. Busybox compiles fine > and the new unstripped busybox is in the > .../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/ What is the new version of busybox? What is the full filename of the new recipe that you created to compile a new version of busybox? For example the old one is busybox_1.20.2.bb (in meta/recipes-core/busybox) Also, can you please paste the .bb file in the email > My question is that after compiling busybox, I do > > bitbake -c cleansstate core-image-minimal > bitbake core-image-minimal > > expecting that the core image generated will contain the new busybox. It > does not, it contains a busybox copy that was compiled days ago, not the > custom one I just compiled. > > Why is this? How can I force the bitbake to include the newly-compiled > busybox into my minimal image? > > > Thanks, > > Brian > > ___ > 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] Busybox still old version: Still looking for a clear understanding of an old mystery.
On Wed, Jan 16, 2013 at 10:23 AM, Brian Smucker wrote:
> Hi,
>
> The version of busybox is the same. I've just temporarily done a bitbake -c
> menuconfig to change one of the options, recompiled using the custom config
> that's generated, and now I want to force its inclusion into
> core-image-minimal.
I see. I think that is a bit unorthodox. (Mostly because I have never
tried it. Is it even supposed to work like you describe? I suppose
not. But that aside ...)
If I were doing this, I would create a busybox bbappend in my meta
layer and override the danny stock do_prepare_config() (in
meta/recipes-core/busybox/busybox.inc)
96 do_prepare_config () {
97 sed -e 's#@DATADIR@#${datadir}#g' \
98 < ${WORKDIR}/defconfig > ${S}/.config
99 sed -i -e '/CONFIG_STATIC/d' .config
100 echo "# CONFIG_STATIC is not set" >> .config
101 for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
102 ${S}/.config
103 sed -i -e '${configmangle}' ${S}/.config
104 if test ${DO_IPv4} -eq 0 && test ${DO_IPv6} -eq 0; then
105 # disable networking applets
106 mv ${S}/.config ${S}/.config.oe-tmp
107 awk 'BEGIN{net=0}
108 /^# Networking Utilities/{net=1}
109 /^#$/{if(net){net=net+1}}
110 {if(net==2&&$0 !~ /^#/&&$1){print("# "$1" is not
set")}else{print}}' \
111 ${S}/.config.oe-tmp > ${S}/.config
112 fi
113 }
> Thanks,
>
> Brian
>
>
> On 1/16/2013 6:13 AM, Autif Khan wrote:
>>
>> On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker
>> wrote:
>>>
>>> Hi Rudolf,
>>>
>>>
>>> On 1/15/2013 3:28 PM, Rudolf Streif wrote:
>>>>
>>>>
>>>> Brian,
>>>>
>>>> What are you exactly referring to as "new version"? The package version
>>>> that bitbake builds is defined by the recipe, through the version
>>>> designation in the recipe's file name or through explicitly setting PV.
>>>>
>>>> I think what you are trying to do is to modify the busybox configuration
>>>> and then recompile and package. Bitbake will not automatically recompile
>>>> after menuconfig. Menuconfig does not invslidate the shared state cache.
>>>> Try
>>>> this:
>>>>
>>>> bitbake -c menuconfig busybox
>>>> bitbake -c -f compile busybox
>>>> bitbake busybox
>>>>
>>>>
>>> So I have done the above. That is not the question. Busybox compiles
>>> fine
>>> and the new unstripped busybox is in the
>>>
>>> .../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/
>>
>> What is the new version of busybox?
>>
>> What is the full filename of the new recipe that you created to
>> compile a new version of busybox? For example the old one is
>> busybox_1.20.2.bb (in meta/recipes-core/busybox)
>>
>> Also, can you please paste the .bb file in the email
>>
>>> My question is that after compiling busybox, I do
>>>
>>> bitbake -c cleansstate core-image-minimal
>>> bitbake core-image-minimal
>>>
>>> expecting that the core image generated will contain the new busybox. It
>>> does not, it contains a busybox copy that was compiled days ago, not the
>>> custom one I just compiled.
>>>
>>> Why is this? How can I force the bitbake to include the newly-compiled
>>> busybox into my minimal image?
>>>
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>> ___
>>> 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] Trying to compile mono on target for machine crownbay
On Wed, Feb 20, 2013 at 11:30 AM, Evgheni Antropov wrote: > In my case I have resolved it in another way: > > correct in Makefile for "eglib" folder SUBDIRS variables and excluded "test" > from them values: > > - > egrep "SUBDIRS =" ./mono-2.10.2/build/eglib/Makefile > DIST_SUBDIRS = src test > SUBDIRS = src test > #SUBDIRS = src > #SUBDIRS = src > #SUBDIRS = src > > + > egrep "SUBDIRS =" ./mono-2.10.2/build/eglib/Makefile > DIST_SUBDIRS = src > SUBDIRS = src > #SUBDIRS = src > #SUBDIRS = src > #SUBDIRS = src > > "build" is my own directory where I'm compiling mono. > > Just FYI - meta-mono is available as a layer that can build mono on a build machine (cross compilation) instead of natively compiling mono in target device. http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono][PATCH 1/2] layer.conf: Use .= for adding to BBPATH and += to BBFILES
On Mon, Jan 21, 2013 at 6:17 PM, Khem Raj wrote:
> Fixes parsing errors which is appearing after this commit to
> meta-openembedded
>
> http://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f
>
> This triggers
> exception NameError: name 'base_contains' is not defined
> without this change
>
> Signed-off-by: Khem Raj
> ---
> conf/layer.conf |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 6bcf70e..d8cc797 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -1,8 +1,8 @@
> # We have a conf and classes directory, add to BBPATH
> -BBPATH := "${BBPATH}:${LAYERDIR}"
> +BBPATH .= ":${LAYERDIR}"
>
> # We have a recipes directory, add to BBFILES
> -BBFILES := "${BBFILES} ${LAYERDIR}/recipes-mono/*/*.bb \
> +BBFILES += "${LAYERDIR}/recipes-mono/*/*.bb \
> ${LAYERDIR}/recipes-mono/*/*.bbappend"
>
> BBFILE_COLLECTIONS += "mono"
> --
> 1.7.9.5
>
Merged into master
Apologies for late merge - somehow this got lost because of bad email
filtering on my part.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono][PATCH 2/2] monotools-server: Remove multiline comment
On Mon, Jan 21, 2013 at 6:17 PM, Khem Raj wrote:
> bitbake/master does not like it anymore
>
> Signed-off-by: Khem Raj
> ---
> .../monotools-server/monotools-server_2.0.bb |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/recipes-mono/monotools-server/monotools-server_2.0.bb
> b/recipes-mono/monotools-server/monotools-server_2.0.bb
> index 551c586..ef738da 100644
> --- a/recipes-mono/monotools-server/monotools-server_2.0.bb
> +++ b/recipes-mono/monotools-server/monotools-server_2.0.bb
> @@ -22,8 +22,6 @@ SRC_URI += " \
> file://fix-pkglib_SCRIPTS.patch \
> "
>
> -# file://Makefile-pkglib.patch \
> -
> DEPENDS = "mono-xsp gtk-sharp"
>
> S = "${WORKDIR}/${PN}"
> --
> 1.7.9.5
>
Merged into master
Apologies for late merge - somehow this got lost because of bad email
filtering on my part.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Question about file systems
On Tue, Mar 5, 2013 at 9:20 PM, Paul D. DeRocco wrote: > This is really a Linux question, but since it is specifically about embedded > systems, I'm hoping this group is a good place to ask. > > My application is based on an Atom, with a small USB flash drive (SLC) for > its storage. I'm trying to decide what file system to use. The application > doesn't do a lot of file accesses, and of course I'll mount the partition(s) > with "noatime" since I don't care about recording access times. But I'm > concerned that if someone yanks the plug, rather than pushing the button for > an orderly shutdown, the next boot will do a long "fsck", and the user will > think the system is broken. > > So I guess the questions are these: Are ext2, ext3 and ext4 all equally > likely to need to do an "fsck" after a disorderly shutdown? Do they > typically take different amounts of time to do an "fsck"? Or is the > journaling of ext3 and ext4 something that should be avoided on a flash > drive at all costs, even though my app won't be doing much file access? > > Also, my app stores its own data in a directory tree of typically a few > hundred small files. Would it be a win or a lose to break this off into a > separate small partition? I was actually thinking of making this a FAT32 > partition, so that I could yank the drive and access those files in any > other machine. > > Any insights would be appreciated. > > -- > > Ciao, Paul D. DeRocco > Paulmailto:pdero...@ix.netcom.com > We have a somewhat similar situation here. We have a device which is not battery backed. And to top it off, the SOP to power off the machine is to yank its power cable. Here is what I have come up with and it seems to be working for us for our requirements. All partitions are ext4. We have one root partition that is always mounted read-only (except when we are upgrading). /var and /tmp (amongst a few others) are tmpfs We have a separate apps partition that is mounted read-only (again except when we are upgrading). In addition to apps, we also store configuration like calibration etc in this partition. We have another scratch partition which is mounted with "rw,sync,barrier=1" options where we store temporary files that need to survive a reboot - log files for example. However, if/when we detect filesystem corruption, we just format the partition during normal boot. In this case the files will of course not survive and that is acceptable. The acceptable risk is that while we are upgrading apps or the OS image, the device should not be powered down. If it is - then we have a way to re-image the device in the field. But that is a separate discussion. When we want to upgrade, we show a message that upgrade is underway on the UI. Remount the partition with "rw,barrier=1" (no need for sync), perform the upgrade, then remount with "ro" options. The difference between root and apps partition is that while upgrades to apps will be frequent - multiple times a week - the upgrades to root will be rare - once in 2 years or even less - it is a very high bar to call for an OS upgrade. And we have built in stuff in our meta layers to recover from bad app partitions and bad scratch partitions. We did not want to club apps and root together and risk bricking the device during normal app upgrades. We do not (using automation) try to recover data from partition, we (as a rule) format the partition and repopulate it. That works for us :-) By no means am I an expert - this is based on help from a lot of folks over at the ext4 mailing list and of course here on the Yocto-Project's mailing list and IRC channel. We have invested some time in testing and making sure that we have a solution that works for us and does not surprise us. I hope this helps. Please let me know if you want me to elaborate on something specific. Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trying to cross compile Mono - glib link error
I followed the instructions and installed the ADT from the 1.1 tarball as outlined in documentation. And tested a few simple GTK apps. Everything worked well. After that I am trying to cross compile mono and I am getting the following error: LD test-glib libtool: link: warning: library `/opt/poky/1.1/sysroots/i586-poky-linux/usr/lib/libgmodule-2.0.la' was moved. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' make[4]: *** [test-glib] Error 1 make[4]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib/test' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6' make: *** [all] Error 2 compiler flags seem to look fine autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep LD BUILDDIR=/home/autif/data/dev/projects/yocto/poky-edison-6.0/build LDFLAGS=' --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' OLDPWD=/home/autif/data/dev/projects/yocto autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CPP CPPFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CXX CXX=i586-poky-linux-g++ CXXFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep FLAGS CFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' CPPFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' CXXFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' LDFLAGS=' --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' Please advise. Thanks! Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to cross compile Mono - glib link error
I bitbaked core-image-sato-sdk It did not produce a tar.gz of the file system I improvised and (-o loop) mounted the core-image-sato-sdk-atom-pc.ext3 at /home/autif/data/dev/projects/yocto/sysroot autif@hp8440w:~/data/dev/projects/yocto/sysroot$ ls bin dev home lost+found mnt sbin tmp var boot etc lib media proc sys usr I changed the environment file as follows (notice how sysroot is updated for all variables): export PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH export PKG_CONFIG_SYSROOT_DIR=/home/autif/data/dev/projects/yocto/sysroot export PKG_CONFIG_PATH=/home/autif/data/dev/projects/yocto/sysroot/usr/lib/pkgconfig export CONFIG_SITE=/opt/poky/1.1/site-config-i586-poky-linux export CC=i586-poky-linux-gcc export CXX=i586-poky-linux-g++ export GDB=i586-poky-linux-gdb export TARGET_PREFIX=i586-poky-linux- export CONFIGURE_FLAGS="--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot" export CFLAGS=" -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot" export CXXFLAGS=" -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot" export LDFLAGS=" --sysroot=/home/autif/data/dev/projects/yocto/sysroot" export CPPFLAGS=" -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot" export OECORE_NATIVE_SYSROOT="/opt/poky/1.1/sysroots/x86_64-pokysdk-linux" export OECORE_TARGET_SYSROOT="/home/autif/data/dev/projects/yocto/sysroot" export OECORE_ACLOCAL_OPTS="-I /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" export OECORE_DISTRO_VERSION="1.1" export OECORE_SDK_VERSION="1.1" And I am still getting the same error. LD test-glib libtool: link: warning: library `/opt/poky/1.1/sysroots/i586-poky-linux/usr/lib/libgmodule-2.0.la' was moved. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' make[4]: *** [test-glib] Error 1 make[4]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib/test' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6' make: *** [all] Error 2 Command exited with non-zero status 2 7.05user 1.36system 0:12.62elapsed 66%CPU (0avgtext+0avgdata 60832maxresident)k 0inputs+37504outputs (0major+1185664minor)pagefaults 0swaps autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep FLAGS CFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot' CPPFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CXXFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' LDFLAGS=' --sysroot=/home/autif/data/dev/projects/yocto/sysroot' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CXX CXX=i586-poky-linux-g++ CXXFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CC CC=i586-poky-linux-gcc SLAVE NONE ACCEPT' -- "$cur" )); COMPREPLY=($( compgen -W 'ACCEPT DROP LOG ULOG REJECT \ COMPREPLY=($( compgen -W 'ACCEPT DROP LOG ULOG REJECT \ COMPREPLY=($( compgen -W 'ACCEPT DROP LOG ULOG REJECT \ autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ ls /home/autif/data/dev/projects/yocto/sysroot Please advise. Did I set the environment correctly? Thanks Autif On Thu, Nov 10, 2011 at 11:24 PM, Zhang, Jessica wrote: > Hi Autif, > > It seems the libgmodule-2.0.la is missing from the 1.1 tarball sysroot but > I've checked it does exist under the sysroot that extracted from the > core-image-sato-sdk image. So, you have to do the following steps: > 1. bitbake core-image-sato-sdk > 2. source the environment-setup script under /opt/poky/1.1 > 3. Run runqemu-extract-sdk against the built out image file, it should be > under your .../build/tmp/deploy/image/core-image-sato-sdk.tar.bz2 and the > directory you want the sysroot to be extracted to e.g. $HOME/qemux86 > 4. change your sysroot setting to point to the newly created sysroot > directory. > > Or, you can following the ADT manual and using the par
Re: [yocto] Trying to cross compile Mono - glib link error
Here are some more environment variables (they all look as expected, I am not sure if they are right): autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep i586 CC=i586-poky-linux-gcc CFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot' CONFIG_SITE=/opt/poky/1.1/site-config-i586-poky-linux CPPFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CXX=i586-poky-linux-g++ CXXFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' GDB=i586-poky-linux-gdb PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games TARGET_PREFIX=i586-poky-linux- autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ On Sun, Nov 13, 2011 at 8:07 PM, autif khan wrote: > I bitbaked core-image-sato-sdk > > It did not produce a tar.gz of the file system > > I improvised and (-o loop) mounted the > core-image-sato-sdk-atom-pc.ext3 at > /home/autif/data/dev/projects/yocto/sysroot > > autif@hp8440w:~/data/dev/projects/yocto/sysroot$ ls > bin dev home lost+found mnt sbin tmp var > boot etc lib media proc sys usr > > I changed the environment file as follows (notice how sysroot is > updated for all variables): > > export > PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH > export PKG_CONFIG_SYSROOT_DIR=/home/autif/data/dev/projects/yocto/sysroot > export > PKG_CONFIG_PATH=/home/autif/data/dev/projects/yocto/sysroot/usr/lib/pkgconfig > export CONFIG_SITE=/opt/poky/1.1/site-config-i586-poky-linux > export CC=i586-poky-linux-gcc > export CXX=i586-poky-linux-g++ > export GDB=i586-poky-linux-gdb > export TARGET_PREFIX=i586-poky-linux- > export CONFIGURE_FLAGS="--target=i586-poky-linux > --host=i586-poky-linux --build=x86_64-linux > --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot" > export CFLAGS=" -m32 -march=i586 > --sysroot=/home/autif/data/dev/projects/yocto/sysroot" > export CXXFLAGS=" -m32 -march=i586 > --sysroot=/home/autif/data/dev/projects/yocto/sysroot" > export LDFLAGS=" --sysroot=/home/autif/data/dev/projects/yocto/sysroot" > export CPPFLAGS=" -m32 -march=i586 > --sysroot=/home/autif/data/dev/projects/yocto/sysroot" > export OECORE_NATIVE_SYSROOT="/opt/poky/1.1/sysroots/x86_64-pokysdk-linux" > export OECORE_TARGET_SYSROOT="/home/autif/data/dev/projects/yocto/sysroot" > export OECORE_ACLOCAL_OPTS="-I > /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/share/aclocal" > export OECORE_DISTRO_VERSION="1.1" > export OECORE_SDK_VERSION="1.1" > > And I am still getting the same error. > > LD test-glib > libtool: link: warning: library > `/opt/poky/1.1/sysroots/i586-poky-linux/usr/lib/libgmodule-2.0.la' was > moved. > libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or > unhandled argument `=/usr/lib/libglib-2.0.la' > make[4]: *** [test-glib] Error 1 > make[4]: Leaving directory > `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib/test' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory > `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6' > make: *** [all] Error 2 > Command exited with non-zero status 2 > 7.05user 1.36system 0:12.62elapsed 66%CPU (0avgtext+0avgdata > 60832maxresident)k > 0inputs+37504outputs (0major+1185664minor)pagefaults 0swaps > autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep FLAGS > CFLAGS=' -m32 -march=i586 > --sysroot=/home/autif/data/dev/projects/yocto/sysroot' > CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux > --build=x86_64-linux > --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot' > CPPFLAGS=' -m32 -march=i586 > --sysroot=/home/autif/data/dev/projects/yocto/sysroot' > CXXFLAGS=' -m32 -march=i586 > --sysroot=/home/autif/data/dev/projects/yocto/sysroot' > LDFLAGS=' --sysroot=/home/autif/data/dev/projects/yoct
[yocto] Where is the emgd.ko module?
I built the "crownbay" (not crownbay-noemgd) image as outlined in the E660 development kit (link http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1) I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and followed the instructions (short version - extract, move, add meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to local.conf, bitbake core-image-sato) The result was the expected set of images in tmp/deploy/images I loop mounted the core-image-sato-crownbay.ext3 and tried to find emgd.ko in the file system - I could not find it. (find output attached - notice that there is no emgd.ko) Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory called "binary" which contains core-image-sato-crownbay.hddimg, which contains rootfs.img, which I also loop mounted and was able to find the emgd.ko (however this image does not work with my hardware, I am not sure why). Find output for this is also included below. I very much doubt that it is included as a part of the kernel, I looked at the kernel's .config (in tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build) and could not find emgd there either. So, my questions is if I am doing something wrong? Do I need to do something to get the emgd.ko to build? I am using the latest release (6.0 "Edison" (released on October 17th, 2011)). Please advise. Thanks Autif autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd ./usr/lib/libemgdsrv_um.so.1.5.15.3226 ./usr/lib/libemgdsrv_um.so ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 ./usr/lib/libemgdPVR2D_DRIWSEGL.so ./usr/lib/xorg/modules/drivers/emgd_drv.so ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 ./usr/lib/libemgdsrv_init.so ./usr/lib/libemgdsrv_init.so.1.5.15.3226 ./usr/lib/libemgdglslcompiler.so ./usr/lib/dri/emgd_dri.so autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ sudo find . | grep emgd ./usr/lib/libemgdsrv_um.so ./usr/lib/dri/emgd_dri.so ./usr/lib/libemgdsrv_init.so.1.5.15.3226 ./usr/lib/libemgdsrv_init.so ./usr/lib/xorg/modules/drivers/emgd_drv.so ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 ./usr/lib/libemgdsrv_um.so.1.5.15.3226 ./usr/lib/libemgdPVR2D_DRIWSEGL.so ./usr/lib/libemgdglslcompiler.so ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko ./etc/rpm-postinsts/kernel-module-emgd.sh.done autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where is the emgd.ko module?
I think that I did. Included is an excerpt that says that I need not do anything except bitbake core image sato when MACHINE="crownbay". As instructed, I followed the steps in section one (Building the meta-crownbay BSP layer) and ignored everything in section two (Special notes for building the meta-crownbay BSP layer) which includes instructions to patch a "crownbay-noemgd" with the Intel driver. Included below is the excerpt from the README. Is there a section that I am overlooking? Thanks Autif The meta-crownbay layer makes use of the proprietary Intel EMGD userspace drivers when building the "crownbay" machine (but not when building the "crownbay-noemgd" machine). If you got the BSP from the 'BSP Downloads' section of the Yocto website, the EMGD binaries needed to perform the build will already be present in the BSP, located in the meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 directory, and you can ignore the rest of this section. On Tue, Dec 13, 2011 at 11:28 AM, Jim Abernathy wrote: > On Tue, 2011-12-13 at 11:13 -0500, autif khan wrote: >> I built the "crownbay" (not crownbay-noemgd) image as outlined in the >> E660 development kit (link >> http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1) >> >> I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and >> followed the instructions (short version - extract, move, add >> meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to >> local.conf, bitbake core-image-sato) >> >> The result was the expected set of images in tmp/deploy/images >> >> I loop mounted the core-image-sato-crownbay.ext3 and tried to find >> emgd.ko in the file system - I could not find it. (find output >> attached - notice that there is no emgd.ko) >> >> Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory >> called "binary" which contains core-image-sato-crownbay.hddimg, which >> contains rootfs.img, which I also loop mounted and was able to find >> the emgd.ko (however this image does not work with my hardware, I am >> not sure why). Find output for this is also included below. >> >> I very much doubt that it is included as a part of the kernel, I >> looked at the kernel's .config (in >> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build) >> and could not find emgd there either. >> >> So, my questions is if I am doing something wrong? Do I need to do >> something to get the emgd.ko to build? I am using the latest release >> (6.0 "Edison" (released on October 17th, 2011)). Please advise. >> > Check out the README file in the meta-crownbay directory. There are > instructions on integrating the EMGD driver files into the build. > > Jim A > >> Thanks >> >> Autif >> >> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd >> ./usr/lib/libemgdsrv_um.so.1.5.15.3226 >> ./usr/lib/libemgdsrv_um.so >> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 >> ./usr/lib/libemgdPVR2D_DRIWSEGL.so >> ./usr/lib/xorg/modules/drivers/emgd_drv.so >> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 >> ./usr/lib/libemgdsrv_init.so >> ./usr/lib/libemgdsrv_init.so.1.5.15.3226 >> ./usr/lib/libemgdglslcompiler.so >> ./usr/lib/dri/emgd_dri.so >> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ >> >> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ >> sudo find . | grep emgd >> ./usr/lib/libemgdsrv_um.so >> ./usr/lib/dri/emgd_dri.so >> ./usr/lib/libemgdsrv_init.so.1.5.15.3226 >> ./usr/lib/libemgdsrv_init.so >> ./usr/lib/xorg/modules/drivers/emgd_drv.so >> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 >> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 >> ./usr/lib/libemgdsrv_um.so.1.5.15.3226 >> ./usr/lib/libemgdPVR2D_DRIWSEGL.so >> ./usr/lib/libemgdglslcompiler.so >> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd >> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko >> ./etc/rpm-postinsts/kernel-module-emgd.sh.done >> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ >> ___ >> 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] How to require image recipe from another layer?
Hi, I have the following problem and I am not sure how to resolve it. I have created my own layer (say) meta-autif In the layer - I have my recipes (say) helloworld, many more may be Now I want to add these packages to the core-image-sato recipe for the image. This recipe resides in meta layer (under recipes-sato/images) I have the following recipe (say) core-image-autif.bb require core-image-sato.bb IMAGE_FEATURES += "helloworld" When I execute "bitbake core-image-autif", I get the following error ERROR: Could not include required file core-image-sato.bb However, when I copy core-image-sato.bb from meta/recipes-sato/images to the same directory as core-image-autif.bb, I get the image (with my helloworld and other apps) My question is - if there is a way to include/require a recipe form a different directory? If yes, what is it? If not, is there a recommended solution - that scales (if the core-image-sato.bb changes, that should be reflected in core-image-autif). Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
Thats right. Accounting for the relative, path, the following recipe seems to works. require ../../../meta/recipes-sato/images/core-image-sato.bb IMAGE_FEATURES += "helloworld" Thanks for the help Autif On Wed, Dec 28, 2011 at 3:12 PM, Chris Larson wrote: > On Wed, Dec 28, 2011 at 1:06 PM, autif khan wrote: >> I have the following problem and I am not sure how to resolve it. >> >> I have created my own layer (say) meta-autif >> >> In the layer - I have my recipes (say) helloworld, many more may be >> >> Now I want to add these packages to the core-image-sato recipe for the >> image. This recipe resides in meta layer (under recipes-sato/images) >> >> I have the following recipe (say) core-image-autif.bb >> >> require core-image-sato.bb >> IMAGE_FEATURES += "helloworld" > > You want something like: > > require recipes-core/images/core-image-sato.bb > -- > Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
Must be the hangover from the holidays! I typed the path as you suggested (I did replace recipes-core with recipes-sato), but I must have had a type somewhere and it did not work and gave the same error. I then tried the relative path - which I copied and pasted - instead of typing and it worked. So I assumed thats what it must have been. Now, I have the following as my recipe and it works just fine. As I said - must be the hangover from the holidays. require recipes-sato/images/core-image-sato.bb IMAGE_FEATURES += "helloworld" Thanks again Autif On Wed, Dec 28, 2011 at 3:31 PM, Chris Larson wrote: > On Wed, Dec 28, 2011 at 1:22 PM, autif khan wrote: >> Thats right. Accounting for the relative, path, the following recipe >> seems to works. >> >> require ../../../meta/recipes-sato/images/core-image-sato.bb >> IMAGE_FEATURES += "helloworld" > > > That's not what I was referring to. You don't need the full relative > path. It will automatically search BBPATH if you require a relative > path. if you do require recipes-sato/images/core-image-sato.bb, it > will search your layers and find it. > -- > 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] How to require image recipe from another layer?
Another recipe question along the same path.
The following recipe does not actually put helloworld in the image -
it does not even build it.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += "helloworld"
The following one does.
require recipes-sato/images/core-image-sato.bb
IMAGE_INSTALL += "helloworld"
I am guessing that if I have several recipes in my layer (say) hw1,
hw2, hw3 etc, I would have to use the following recipe.
require recipes-sato/images/core-image-sato.bb
IMAGE_INSTALL += "hw1 hw2 hw3 etc"
However, I am sure there is a way to ties these up with
"IMAGE_FEATURE" variable.
Can you please help me with setting up my recipes so that all the
hello world apps are included when I use the following recipe.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += "helloworld"
I am guessing that I would have to tell the hw1 recipe that it is a
helloworld feature. How do I go about doing this?
Here it is for reference:
DESCRIPTION = "hello world app"
SECTION = "autif"
LICENSE = "SomeLic"
LIC_FILES_CHKSUM = "file://COPYING;md5=178c09540123ca26c1b9c1ccbfbcde87"
PR = "r0"
SRC_URI = "file://COPYING \
file://helloworld.c"
S = "${WORKDIR}"
do_compile () {
${CC} helloworld.c -o helloworld
}
do_install () {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
Thanks again!
Autif
On Wed, Dec 28, 2011 at 3:43 PM, autif khan wrote:
> Must be the hangover from the holidays!
>
> I typed the path as you suggested (I did replace recipes-core with
> recipes-sato), but I must have had a type somewhere and it did not
> work and gave the same error. I then tried the relative path - which I
> copied and pasted - instead of typing and it worked. So I assumed
> thats what it must have been.
>
> Now, I have the following as my recipe and it works just fine. As I
> said - must be the hangover from the holidays.
>
> require recipes-sato/images/core-image-sato.bb
> IMAGE_FEATURES += "helloworld"
>
> Thanks again
>
> Autif
>
> On Wed, Dec 28, 2011 at 3:31 PM, Chris Larson wrote:
>> On Wed, Dec 28, 2011 at 1:22 PM, autif khan wrote:
>>> Thats right. Accounting for the relative, path, the following recipe
>>> seems to works.
>>>
>>> require ../../../meta/recipes-sato/images/core-image-sato.bb
>>> IMAGE_FEATURES += "helloworld"
>>
>>
>> That's not what I was referring to. You don't need the full relative
>> path. It will automatically search BBPATH if you require a relative
>> path. if you do require recipes-sato/images/core-image-sato.bb, it
>> will search your layers and find it.
>> --
>> 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] Trying to compile mono on target for machine crownbay
I bitbaked core-image-sato-sdk, copied it to the target disk and tried to build mono natively on the target machine and I got the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid I am not sure why there is a leading '=' in the path. Needless to say - mono builds fine on ubuntu, so it is unlikely (not impossible) to be a mono build issue. Has anyone seen anything like this with mono or some other piece of software? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
I talked to a couple of mono developers (kangaroo and vargaz) - the consensus is that "'auto' is hosed" I am not an expert in auto tools, I just know how to configure, make, make install. I get by when I need to know my way around makefiles I am a capable C/C++ developer - please advise or point me to right resources. Thanks Autif On Thu, Jan 5, 2012 at 4:52 PM, autif khan wrote: > I bitbaked core-image-sato-sdk, copied it to the target disk and tried > to build mono natively on the target machine and I got the following > error: > > libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or > unhandled argument `=/usr/lib/libglib-2.0.la' > > the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid > > I am not sure why there is a leading '=' in the path. Needless to say > - mono builds fine on ubuntu, so it is unlikely (not impossible) to be > a mono build issue. > > Has anyone seen anything like this with mono or some other piece of software? > > Thanks > > Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
On Thu, Jan 5, 2012 at 5:17 PM, Mark Hatle wrote: > On 1/5/12 3:52 PM, autif khan wrote: >> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or >> unhandled argument `=/usr/lib/libglib-2.0.la' > > > The version of libtool you are currently using is damaged in some way. I > suspect the program is falling back and trying to use either a local version > or the host-system version. I am using 6.0 Edison release of yocto. Is libtool being broken a known issue for this version? > The libtool located within the OE/Poky environment understands that when a > "=" is predicating a path, it means locate the item within the sysroot at > the following path. Since the error indicates it doesn't understand that > concept, it appears that that version of libtool is broken. > > Normally the autotools class will deal with this situation for you. Simply > inheriting autotools class usually does it. For now, there is no recipe for mono in yocto. There is one for a very old version of mono on OE that I have looked at. It does not work, when it is integrated in some layer. It fails with a somewhat different error (included below). So I am trying to write the recipe for mono and trying to compile it on native hardware - that would be the first step - if I can compile it natively, then I will try to cross compile it, and then I can try to write the recipe. So, I do not have a sysroot to cross compile ... It is the native root file system - the compilation happens on the target hardware. How can I figure out what the issue is with auto tools? Thanks Autif Error form mono recipe from OE: checking for preceeding underscore in symbols... configure: error: in `/home/autif/data/dev/yocto/koko/tmp/work/core2-poky-linux/mono-2.6.3-r0.1/mono-2.6.3': configure: error: cannot run test program while cross compiling ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Does my build disk's filesystem make a difference?
You are better off with one of the dual boot OSes in a virtual machine that a dual boot situation where you are trying to write to NTFS from linux or trying to work with ext2fs tools from windows. I do not even know if you can create equivalent of symlinks (used extensively in yocto) on an NTFS In theory, it might work, but NTFS was not built for linux, likewise, ext4 was not meant to be used for windows. It is a bad idea. You know - unless this happens to be your master's research thesis :-) On Fri, Jan 6, 2012 at 6:53 PM, Jeff Osier-Mixon wrote: > I am creating a Yocto Project build system. For various reasons, it is a > dual-boot system, win7 & linux (probably mint 12, haven't decided). I have a > primary boot disk with both operating systems and a large secondary disk to > use for build trees etc. > > Does the filesystem on the big secondary disk matter? Ideally I would like > to be able to get to the large data disk from both operating systems. That > would necessitate NTFS, as win7 does not speak ext4 reliably, but I don't > want to slow my builds down. > > -- > 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 > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
Here is a recipe that I using to generate a custom SDK image which I can use to natively compile mono on the target. require recipes-sato/images/core-image-sato-sdk.bb IMAGE_INSTALL += "bison libtool" PR="r0" bison is required and I added libtool because it was being generated by mono's autoconf (./configure) script and gave the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' If I understand correctly, yocto has a special libtool which understands how to handle '=/path/to/lib' The problem is that it looks like 'libtool' is not included in the image. I do have the libtool recipe in meta/recipes-devtools/libtool The libtool version generated by mono was 2.2.6b The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68) Am I doing something wrong? If not, where is the 'libtool' in the image? Thanks Autif On Thu, Jan 5, 2012 at 4:59 PM, autif khan wrote: > I talked to a couple of mono developers (kangaroo and vargaz) - the > consensus is that "'auto' is hosed" > > I am not an expert in auto tools, I just know how to configure, make, > make install. > > I get by when I need to know my way around makefiles > > I am a capable C/C++ developer - please advise or point me to right resources. > > Thanks > > Autif > > On Thu, Jan 5, 2012 at 4:52 PM, autif khan wrote: >> I bitbaked core-image-sato-sdk, copied it to the target disk and tried >> to build mono natively on the target machine and I got the following >> error: >> >> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or >> unhandled argument `=/usr/lib/libglib-2.0.la' >> >> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid >> >> I am not sure why there is a leading '=' in the path. Needless to say >> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be >> a mono build issue. >> >> Has anyone seen anything like this with mono or some other piece of software? >> >> Thanks >> >> Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
When I try to compile mono using the ADT (bitbake meta-ide-support, source the environment file and configure, followed by make), I get the same behavior. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' But then, even in this case, mono's autoconf (./configure) generated a 'libtool' instead of using the one from yocto's development environment. Please advise. Thanks Autif On Mon, Jan 9, 2012 at 3:12 PM, autif khan wrote: > Here is a recipe that I using to generate a custom SDK image which I > can use to natively compile mono on the target. > > require recipes-sato/images/core-image-sato-sdk.bb > IMAGE_INSTALL += "bison libtool" > PR="r0" > > bison is required and I added libtool because it was being generated > by mono's autoconf (./configure) script and gave the following error: > > libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or > unhandled argument `=/usr/lib/libglib-2.0.la' > > If I understand correctly, yocto has a special libtool which > understands how to handle '=/path/to/lib' > > The problem is that it looks like 'libtool' is not included in the > image. I do have the libtool recipe in meta/recipes-devtools/libtool > > The libtool version generated by mono was 2.2.6b > > The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68) > > Am I doing something wrong? If not, where is the 'libtool' in the image? > > Thanks > > Autif > > On Thu, Jan 5, 2012 at 4:59 PM, autif khan wrote: >> I talked to a couple of mono developers (kangaroo and vargaz) - the >> consensus is that "'auto' is hosed" >> >> I am not an expert in auto tools, I just know how to configure, make, >> make install. >> >> I get by when I need to know my way around makefiles >> >> I am a capable C/C++ developer - please advise or point me to right >> resources. >> >> Thanks >> >> Autif >> >> On Thu, Jan 5, 2012 at 4:52 PM, autif khan wrote: >>> I bitbaked core-image-sato-sdk, copied it to the target disk and tried >>> to build mono natively on the target machine and I got the following >>> error: >>> >>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or >>> unhandled argument `=/usr/lib/libglib-2.0.la' >>> >>> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid >>> >>> I am not sure why there is a leading '=' in the path. Needless to say >>> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be >>> a mono build issue. >>> >>> Has anyone seen anything like this with mono or some other piece of >>> software? >>> >>> Thanks >>> >>> Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
While googling, I found this link (http://mashandmish.wordpress.com/2011/04/20/crossbuilding-webkit-with-a-yocto-toolchain-part-i-glib/) Here, the author is replacing the libtool generated by autoconf (./configure script) with the one form the sysroot. i.e. ./configure cp /opt/poky/1.0/sysroots/i686-pokysdk-linux/usr/bin/i686-pokysdk-libtool libtool I did the equivalent and amazingly got the same results. I am sure I am missing something. Just not sure what. On Mon, Jan 9, 2012 at 3:45 PM, autif khan wrote: > When I try to compile mono using the ADT (bitbake meta-ide-support, > source the environment file and configure, followed by make), I get > the same behavior. > > libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or > unhandled argument `=/usr/lib/libglib-2.0.la' > > But then, even in this case, mono's autoconf (./configure) generated a > 'libtool' instead of using the one from yocto's development > environment. > > Please advise. > > Thanks > > Autif > > On Mon, Jan 9, 2012 at 3:12 PM, autif khan wrote: >> Here is a recipe that I using to generate a custom SDK image which I >> can use to natively compile mono on the target. >> >> require recipes-sato/images/core-image-sato-sdk.bb >> IMAGE_INSTALL += "bison libtool" >> PR="r0" >> >> bison is required and I added libtool because it was being generated >> by mono's autoconf (./configure) script and gave the following error: >> >> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or >> unhandled argument `=/usr/lib/libglib-2.0.la' >> >> If I understand correctly, yocto has a special libtool which >> understands how to handle '=/path/to/lib' >> >> The problem is that it looks like 'libtool' is not included in the >> image. I do have the libtool recipe in meta/recipes-devtools/libtool >> >> The libtool version generated by mono was 2.2.6b >> >> The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68) >> >> Am I doing something wrong? If not, where is the 'libtool' in the image? >> >> Thanks >> >> Autif >> >> On Thu, Jan 5, 2012 at 4:59 PM, autif khan wrote: >>> I talked to a couple of mono developers (kangaroo and vargaz) - the >>> consensus is that "'auto' is hosed" >>> >>> I am not an expert in auto tools, I just know how to configure, make, >>> make install. >>> >>> I get by when I need to know my way around makefiles >>> >>> I am a capable C/C++ developer - please advise or point me to right >>> resources. >>> >>> Thanks >>> >>> Autif >>> >>> On Thu, Jan 5, 2012 at 4:52 PM, autif khan wrote: >>>> I bitbaked core-image-sato-sdk, copied it to the target disk and tried >>>> to build mono natively on the target machine and I got the following >>>> error: >>>> >>>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or >>>> unhandled argument `=/usr/lib/libglib-2.0.la' >>>> >>>> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid >>>> >>>> I am not sure why there is a leading '=' in the path. Needless to say >>>> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be >>>> a mono build issue. >>>> >>>> Has anyone seen anything like this with mono or some other piece of >>>> software? >>>> >>>> Thanks >>>> >>>> Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] auto tools tagged configuration
So, I have been trying to cross compile mono and having some luck with it. When the configure script runs, it creates a libtool script which does not work well with yocto's cross compilation setup. Step 1: So, I rename this libtool as libtool.orig and Step 2: copy the libtool from tmp/sysroots/crownbay/usr/bin/crossscripts/i586-poky-linux-libtool This errors out as follows: ... ... CC debug-debugger.lo debug-debugger.c: In function ‘debugger_get_boxed_object’: debug-debugger.c:211:21: warning: variable ‘last_boxed_object’ set but not used [-Wunused-but-set-variable] ../../doltlibtool --quiet --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse -c -o mdb-debug-info32.lo mdb-debug-info32.s libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[4]: *** [mdb-debug-info32.lo] Error 1 make[4]: Leaving directory `/home/autif/data2/nosync/dev/yocto/apps/mono/mono-2.6.3/mono/mini' ... ... At this point, if I delete the cross libtool and rename libtool.orig (from Step 1) back to libtool, make continues beyond this step and fails further. Again, copying yocto's libtool as done is Step 2, allows make to continue creates all the binaries and libraries. At this point the binaries can be manually copied to the target and seem to pass a lot of mono's runtime and library tests. This is great! (make install fails, but, resolution for it can wait) So, what is this "tagged information" can can not be "infered" and what can I do to mono's autoconf script to fix this? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-sato-directdisk
I have been using core-image-sato and core-image-sato-sdk on the hard
disk on Intel Atom (crownbay in my case).
I perform the following broad steps:
1) have a suitable partition on the disk - say partition #3
2) this partition will show up as sde3 on my host machine and sda3 on the atom
3) mkfs.ext3 /dev/sde3
4) mount /dev/sde3 /mnt/target
5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-text3
6) cp -a /mnt/target-ext3/* /mnt/target
7) grub-install --recheck --root-directory=/mnt/target /dev/sde
If grub install passed, I copy the following to /mnt/target/boot/grub/grub.cfg
set default="0"
set timeout="30"
menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}
Thats it - this boots for me.
Eventually, when I move to some other media, I will have to
investigate other bootloaders - like syslinux.
All the best, do tell if this works.
On Thu, Jan 19, 2012 at 7:51 PM, James Abernathy wrote:
> The README.hardware file in the poky directory talks about creating images
> on 2 types of disk for the Atom based PCs like the n450. The one I've
> successfully tested is the core-image-sato on a USB key. I have no luck
> with the directdisk method because the image recipe doesn't exist for
> core-image-minimal-directdisk or core-image-sato-directdisk.
>
> Is there a way to put Yocto on the hard drive on a Atom PC?
>
> Jim A
>
>
> ___
> 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] core-image-sato-directdisk
On Fri, Jan 20, 2012 at 11:13 AM, Jim Abernathy wrote:
> On 01/20/2012 09:16 AM, autif khan wrote:
>>
>> I have been using core-image-sato and core-image-sato-sdk on the hard
>> disk on Intel Atom (crownbay in my case).
>>
>> I perform the following broad steps:
>>
>> 1) have a suitable partition on the disk - say partition #3
>> 2) this partition will show up as sde3 on my host machine and sda3 on the
>> atom
>> 3) mkfs.ext3 /dev/sde3
>> 4) mount /dev/sde3 /mnt/target
>> 5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3
>> /mnt/target-text3
>> 6) cp -a /mnt/target-ext3/* /mnt/target
>> 7) grub-install --recheck --root-directory=/mnt/target /dev/sde
>>
>> If grub install passed, I copy the following to
>> /mnt/target/boot/grub/grub.cfg
>>
>> set default="0"
>> set timeout="30"
>>
>> menuentry 'Yocto SDK' {
>> insmod part_msdos
>> insmod ext2
>> set root='(hd0,msdos3)'
>> linux /boot/bzImage root=/dev/sda3
>> }
>>
>>
>> Thats it - this boots for me.
>>
>> Eventually, when I move to some other media, I will have to
>> investigate other bootloaders - like syslinux.
>>
>> All the best, do tell if this works.
>
> This worked fine for me. one typo in step (5) ext3 and not text3, but these
> are good instructions. How do we get them put into the README.hardware
> instead of the directdisk section that doesn't work anymore.
Yup, I wrote then off the cuff, I am glad that a typo is the only
error and no major missing steps :-)
I am also glad that these steps worked for you.
> Did you file a bug on this?
I have not. I am not sure I should. I am not even sure whoose call it
should be weather or not this goes in README.hardware. I hope someone
chimes in
> Thanks,
>
> Jim Abernathy
>
>
>>
>> On Thu, Jan 19, 2012 at 7:51 PM, James Abernathy
>> wrote:
>>>
>>> The README.hardware file in the poky directory talks about creating
>>> images
>>> on 2 types of disk for the Atom based PCs like the n450. The one I've
>>> successfully tested is the core-image-sato on a USB key. I have no luck
>>> with the directdisk method because the image recipe doesn't exist for
>>> core-image-minimal-directdisk or core-image-sato-directdisk.
>>>
>>> Is there a way to put Yocto on the hard drive on a Atom PC?
>>>
>>> Jim A
>>>
>>>
>>> ___
>>> 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] core-image-sato-directdisk
On Fri, Jan 20, 2012 at 12:15 PM, Paul Eggleton wrote: > On Friday 20 January 2012 11:54:44 autif khan wrote: >> > Did you file a bug on this? >> >> I have not. I am not sure I should. I am not even sure whoose call it >> should be weather or not this goes in README.hardware. I hope someone >> chimes in > > So I would say if any of our documentation is out-of-date or unclear, it > should be fixed, no deliberation needed :) > > However, in Poky master, README.hardware has now been updated to remove > references to the old directdisk images. It could be that we need to > explicitly add something like what you have written about writing the image to > a hard disk, but for the moment it is at least no longer out-of-date. > > At the very least a great start would be to put your instructions up as a page > on the Yocto Project wiki. I have created a new link titled "How Do I" on the main page and for now, this is the only entry. Please take a look. https://wiki.yoctoproject.org/wiki/Main_Page https://wiki.yoctoproject.org/wiki/How_do_I > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] libtool version mismatch
I have been working on writing a recipe for mono. I have successfully written one for lbgdiplus and am making headway with mono. Mono comes with libtool version 2.2.6, Yocto uses 2.4 After do_configure(), when do_complie() is being executed, I am getting the following error for the following command: Command: /bin/sh ./libtool --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/home/autif/data2/nosync/dev/yocto/kokosdk/tmp/sysroots/crownbay -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE_VERSION=\"6.6\" -DPACKAGE_STRING=\"libgc-mono\ 6.6\" -DPACKAGE_BUGREPORT=\"hans_bo...@hp.com\" -DPACKAGE_URL=\"\" -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DPARALLEL_MARK=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -O2 -pipe -g -feliminate-unused-debug-types -g -mno-tls-direct-seg-refs -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c Error: | libtool: Version mismatch error. This is libtool 2.4, but the | libtool: definition of this LT_INIT comes from libtool 2.2.6. | libtool: You should recreate aclocal.m4 with macros from libtool 2.4 | libtool: and run autoconf again. | make[3]: *** [allchblk.lo] Error 63 Here is how LT_INIT is defined in aclocal.m4: # LT_INIT([OPTIONS]) # -- AC_DEFUN([LT_INIT], [AC_PREREQ([2.58])dnl We use AC_INCLUDES_DEFAULT AC_BEFORE([$0], [LT_LANG])dnl AC_BEFORE([$0], [LT_OUTPUT])dnl AC_BEFORE([$0], [LTDL_INIT])dnl m4_require([_LT_CHECK_BUILDDIR])dnl dnl Autoconf doesn't catch unexpanded LT_ macros by default: m4_pattern_forbid([^_?LT_[A-Z_]+$])dnl m4_pattern_allow([^(_LT_EOF|LT_DLGLOBAL|LT_DLLAZY_OR_NOW|LT_MULTI_MODULE)$])dnl dnl aclocal doesn't pull ltoptions.m4, ltsugar.m4, or ltversion.m4 dnl unless we require an AC_DEFUNed macro: AC_REQUIRE([LTOPTIONS_VERSION])dnl AC_REQUIRE([LTSUGAR_VERSION])dnl AC_REQUIRE([LTVERSION_VERSION])dnl AC_REQUIRE([LTOBSOLETE_VERSION])dnl m4_require([_LT_PROG_LTMAIN])dnl dnl Parse OPTIONS _LT_SET_OPTIONS([$0], [$1]) # This can be used to rebuild libtool when needed LIBTOOL_DEPS="$ltmain" # Always use our own libtool. LIBTOOL='$(SHELL) $(top_builddir)/libtool' AC_SUBST(LIBTOOL)dnl _LT_SETUP # Only expand once: m4_define([LT_INIT]) ])# LT_INIT What changes should be made to the auto tools files to fix this? Thanks! Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libtool version mismatch
On Tue, Jan 24, 2012 at 10:44 AM, Khem Raj wrote:
> On Tue, Jan 24, 2012 at 7:18 AM, autif khan wrote:
>> Error:
>> | libtool: Version mismatch error. This is libtool 2.4, but the
>> | libtool: definition of this LT_INIT comes from libtool 2.2.6.
>> | libtool: You should recreate aclocal.m4 with macros from libtool 2.4
>> | libtool: and run autoconf again.
>> | make[3]: *** [allchblk.lo] Error 63
>
> this says it all and we do that regeneration automatically for recipes
> which inherit autotools
It seems that way, but I can not explain the following behavior.
1) I can grep autoreconf in log.do_configure
2) When I add do_configure_prepend() {autoreconf --force --install
-Wcorss} this issue seems to go away.
So, I am confused, but not lost - as it seems like this updated recipe
seems to work.
I have attached logs for before and after the changes specified in 2 (above)
> you need to post your recipes for someone to look at what you are doing
Still a work in progress:
SUMMARY = "An Open Source implementation of the Microsoft's .NET Framework"
DESCRIPTION = "This is part of the Mono project - http://mono-project.com";
HOMEPAGE = "http://mono-project.com";
BUGTRACKER = "http://bugzilla.xamarin.com/";
SECTION = "devel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=58d09de7e50ecdbafcf97e7eb5d0c34a"
SRC_URI = "http://download.mono-project.com/sources/mono/mono-${PV}.tar.bz2 \
file://mono-2.6.7/mono/mini/Makefile.in.1.diff \
file://mono-2.6.7/mono/profiler/Makefile.in.2.diff"
inherit autotools pkgconfig
DEPENDS =+ "libgdiplus"
PR = "r0"
SRC_URI[md5sum] = "cc8b7bf061bd11fbd0fcc1c95eb79d34"
SRC_URI[sha256sum] =
"ae21a997d72e2fb8ea88644c87ab52471e9c97117b937e205ea1835b5a028ce4"
EXTRA_OECONF += "--disable-mcs-build mono_cv_uscore=no
--with-tls=pthread --with-sigaltstack=no"
do_configure_prepend() {
autoreconf -Wcross --verbose --install --force || bbnote "mono
failed to autoreconf"
}
do_compile_prepend() {
ln -s i586-poky-linux-libtool libtool
}
mono.temp.tar.gz
Description: GNU Zip compressed data
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libtool version mismatch
On Tue, Jan 24, 2012 at 12:09 PM, Khem Raj wrote:
> On Tue, Jan 24, 2012 at 8:13 AM, autif khan wrote:
>>
>> do_configure_prepend() {
>> autoreconf -Wcross --verbose --install --force || bbnote "mono
>> failed to autoreconf"
>> }
>>
>> do_compile_prepend() {
>> ln -s i586-poky-linux-libtool libtool
>> }
>
> get rid of above these are not needed when recipes inherit autotools
> see if you need to copy over some of m4 macros that is what you
> need to do in do_configure_prepend if needed.
Can you point me to an existing recipe that already does something
similar? I am not sure what I am looking for.
Thanks for all the help!
Autif
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do I patch the kernel before it is built?
I could not find a way to patch the kernel source before its is built. I promise to update the Yocto wiki's How do I section when I have a working solution for the following :-) Here is what I am trying to do: 1) Patch the kernel (add VID/PID to hid_ignore_list in drivers/hid/hid-core.c and also to add the VID/PID to .h file) 2) Build the kernel - no change here - standard kernel build 3) Build a kernel module 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 recipe for a kernel module - please point me to it. Thank you Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gaku music player
Hi Jim, I would appreciate if you could add some information to the How do I section in the wiki. I am not there yet, but I also need audio and video on crownbay in about 4-8 weeks. Thanks for getting to the bottom of this Autif On Fri, Feb 3, 2012 at 3:21 PM, James Abernathy wrote: > > > On Fri, Feb 3, 2012 at 11:02 AM, James Abernathy > wrote: >> >> I tried all the different mixer options on the Crownbay. It's just not >> very loud. I'll try an amplifier, but with earphones, it almost not loud >> enough to hear. I don't remember other Linux's having this issue. Could >> there be something else software wise? The good news is the built-in GUI >> Music and Video players work with the H.264 files I've tested as well as the >> command line stuff. >> >> Also got the glxgears works as well. >> >> Jim A > > To close this one out. The Crownbay seems to have a line level out only and > not a port that supports headphones and line level. Once I put minimal Line > in level amplfication, the audio works as expected. > > Thanks for the help. It's good to see nice integration in Yocto of video and > music players that actually plays the the H.264 and MP3 files. > > Jim A > >> >> >> > > > ___ > 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] Build Error
I also attached the corresponding .done file however, since its size was 0, it was not attached - dont forget to add a .done file too. On Sun, Feb 5, 2012 at 6:24 PM, autif khan wrote: > It seems like > > wget http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz > > return a 500 - Internal server error. > > Does not look like you did anything wrong. > > However, I do not know a workaround. > > I have attached these files from my downloads directory. > > You can copy these files in yours and it should get you by for now. > > On Sun, Feb 5, 2012 at 5:27 PM, Sean Liming wrote: >> I am new developer to Yocto and embedded Linux in general >> >> >> >> Host machine: i3 with 4GB RAM >> >> OS: Ubuntu 11.10 64-bit >> >> >> >> I am following the online quick start guide, and looks like the end of >> bitbake runs into several errors: >> >> >> >> ERROR: Task 1136 >> (/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/contacts_git.bb, >> do_configure) failed with exit code '1' >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb' >> failed >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.1.bb' >> failed >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-support/libfm/libfm_0.1.14.bb' >> failed >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb' >> failed >> >> ERROR: '/home/sean/poky-edison-6.0/meta/recipes-support/vte/vte_0.24.3.bb' >> failed >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-sato/puzzles/oh-puzzles_git.bb' >> failed >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-connectivity/connman/connman-gnome_0.5.bb' >> failed >> >> ERROR: '/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/tasks_0.19.bb' >> failed >> >> ERROR: '/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/dates_git.bb' >> failed >> >> ERROR: >> '/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/contacts_git.bb' >> failed >> >> >> >> Looking back at the build process, one error calls out a package that cannot >> be downloaded: >> http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz >> >> >> >> I have attached errors some of the log files. The common error appears to be >> oe_runconf failed. >> >> >> >> Did I miss configure something? Wrong python version? >> >> There was a post about the dash vs. bash shell. I am not sure what shell is >> supposed to be using: >> >> >> >> The instructions say run sudo dpkg-reconfigure dash and say no. Nothing in >> the message popup says what is the shell. >> >> >> >> Thanks for any help. >> >> >> >> Regards, >> >> >> >> Sean >> >> >> >> >> ___ >> 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] Build Error
Here is what I have - I started with a minimal ubuntu server and the following command seens to get all the dependencies - the last few (bison, flex and unzip) are not required - but are required for other stuff I am working on. I hope this helps with the documentation. sudo apt-get install -y gcc g++ patch diffstat texi2html texinfo cvs subversion gawk chrpath make libgl1-mesa-dev libglu1-mesa-dev libsdl1.2-dev git libxml-parser-perl bison gettext flex unzip On Mon, Feb 6, 2012 at 11:44 AM, Sean Liming wrote: > > Found the problem - missing package - libxml-parser-perl. It is not part of > the setup. For any future reference, here is the fix: > > $sudo apt-get install libxml-parser-perl > > Ubuntu was a fresh install. I should have checked the docs in progress, > which calls it out at the end. > > Regards, > > Sean Liming > Owner > SJJ Embedded Micro Solutions, LLC. > Tel: 714-970-7523 / Cell: 858-774-3176 > > > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] > On Behalf Of Sean Liming > Sent: Sunday, February 05, 2012 11:21 PM > To: 'Khem Raj' > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Build Error > > > Searching further there seems to be different patches for perl-native for > Ubuntu 10.04. Not sure what needs to be applied here. > > Regards, > > Sean > > > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] > On Behalf Of Sean Liming > Sent: Sunday, February 05, 2012 11:05 PM > To: 'Khem Raj' > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Build Error > > > How would I check if perl-native is staged? The intltool.inc has the updated > Rudolf. > > Regards, > > Sean > > -Original Message- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Sunday, February 05, 2012 10:30 PM > To: Sean Liming > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Build Error > > On Sun, Feb 5, 2012 at 8:01 PM, Sean Liming > wrote: >> @ autif- thank you for the tar file. Placed it in the downloads folder >> and > the error doesn't appear. >> >> >> I added the two lines to the local.conf folder >> >> INHERIT += "own-mirrors" >> SOURCE_MIRROR_URL = "http://autobuilder.yoctoproject.org/pub/sources/"; >> >> I am not sure how to resolve the lib-xml-parser for intltool issue >> based > on the post. >> > > checking for perl... /usr/bin/perl > checking for perl >= 5.8.1... 5.12.4 > checking for XML::Parser... configure: error: XML::Parser perl module is > required for intltool > ERROR: oe_runconf failed > > it should not be getting perl from your build but from the native sysroot. > is perl-native staged ? >> >> Regards, >> >> Sean Liming >> Owner >> SJJ Embedded Micro Solutions, LLC. >> Tel: 714-970-7523 / Cell: 858-774-3176 >> >> >> -Original Message- >> From: Khem Raj [mailto:raj.k...@gmail.com] >> Sent: Sunday, February 05, 2012 4:00 PM >> To: Sean Liming >> Cc: yocto@yoctoproject.org >> Subject: Re: [yocto] Build Error >> >> On Sun, Feb 5, 2012 at 2:27 PM, Sean Liming > wrote: >>> Did I miss configure something? Wrong python version? >>> >>> There was a post about the dash vs. bash shell. I am not sure what >>> shell is supposed to be using: >> >> you could add something like below to your local.conf >> >> INHERIT += "own-mirrors" >> SOURCE_MIRROR_URL = "http://autobuilder.yoctoproject.org/pub/sources/"; >> >> that should help a bit >> >> ___ >> 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 mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > ___ > 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] How do I patch the kernel before it is built?
>>> I could not find a way to patch the kernel source before its is built.
>>>
>>> I promise to update the Yocto wiki's How do I section when I have a
>>> working solution for the following :-)
>>
>> This should be covered in the existing documentation and also the
>> more general bitbake/oe-core docs.
>>
>>>
>>> Here is what I am trying to do:
>>>
>>> 1) Patch the kernel (add VID/PID to hid_ignore_list in
>>> drivers/hid/hid-core.c and also to add the VID/PID to .h file)
>>> 2) Build the kernel - no change here - standard kernel build
>>> 3) Build a kernel module
>>>
>>> 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.
I tried this - attached at the end of this email are my bbappend file
and my patches, when the recipe is bitbaked, it does not actually
apply the patch.
On a similar note - there seems to be a file in
meta/recipes-kernel/linux/linux-yocto called
tools-perf-no-scripting.patch
However, it does not seem to be used anywhere - is this just crud or I
am missing something? I was hoping to cheat off of the recipe that
uses it.
>>> 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
Thank you for this recipe - it seems like this is exactly what I was
looking for. I will cheat off of this as soon as I can patch my
kernel.
R E C I P E
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://linux/drivers/hid/hid-core.c.diff \
file://linux/drivers/hid/hid-ids.h.diff "
PR = "r3"
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
P A T C H
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
cat hid-core.c.diff
--- linux.orig/drivers/hid/hid-core.c 2012-01-31 16:44:44.152001877 -0500
+++ linux/drivers/hid/hid-core.c2012-01-31 16:46:34.608001870 -0500
@@ -1839,6 +1839,8 @@
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_1_PHIDGETSERVO_20) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT) },
{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK,
USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PIXCIR, USB_DEVICE_ID_PIXCIR) },
{ }
};
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
cat hid-ids.h.diff--- linux.orig/drivers/hid/hid-ids.h 2012-01-31
16:44:55.432001877 -0500
+++ linux/drivers/hid/hid-ids.h 2012-01-31 16:47:36.624001858 -0500
@@ -671,4 +671,7 @@
#define USB_VENDOR_ID_ZYDACRON 0x13EC
#define USB_DEVICE_ID_ZYDACRON_REMOTE_CONTROL 0x0006
+#define USB_VENDOR_ID_PIXCIR 0x040b
+#define USB_DEVICE_ID_PIXCIR 0x2000
+
#endif
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch the kernel before it is built?
> I could not find a way to patch the kernel source before its is built.
>
> I promise to update the Yocto wiki's How do I section when I have a
> working solution for the following :-)
This should be covered in the existing documentation and also the
more general bitbake/oe-core docs.
>
> Here is what I am trying to do:
>
> 1) Patch the kernel (add VID/PID to hid_ignore_list in
> drivers/hid/hid-core.c and also to add the VID/PID to .h file)
> 2) Build the kernel - no change here - standard kernel build
> 3) Build a kernel module
>
> 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.
>>
>> I tried this - attached at the end of this email are my bbappend file
>> and my patches, when the recipe is bitbaked, it does not actually
>> apply the patch.
>>
>> On a similar note - there seems to be a file in
>> meta/recipes-kernel/linux/linux-yocto called
>> tools-perf-no-scripting.patch
>>
>> However, it does not seem to be used anywhere - is this just crud or I
>> am missing something? I was hoping to cheat off of the recipe that
>> uses it.
>>
> 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
>>
>> Thank you for this recipe - it seems like this is exactly what I was
>> looking for. I will cheat off of this as soon as I can patch my
>> kernel.
>>
>>
>> R E C I P E
>>
>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
>> linux-yocto_3.0.bbappend
>> FILESEXTRAPATHS_prepend := "${THISDIR}:"
>> SRC_URI += " file://linux/drivers/hid/hid-core.c.diff \
>> file://linux/drivers/hid/hid-ids.h.diff "
>> PR = "r3"
>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
>>
>> P A T C H
>>
>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
>
> Taking a look at this (while I was cutting and pasting), this should
> be in in the
> a 'linux-yocto' subdirectory if you want bitbake to pickup the patch and make
> it
> available to the linux-yocto recipe.
>
> i.e.
> ~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
>
> And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
> that part is
> automatic.
I tried this just now - here is what happens:
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://drivers/hid/file.diff
Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://linux-yocto/drivers/hid/file.diff
Result - my diff files are copied in a directory called linux-yocto in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
These patches are not applied in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
Here is what the work directory looks like
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
ls
git license-destdir linux linux-crownbay-standard-build linux-yocto temp
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
I have attached the original set of files as a tar gzip.
> (and yes, I see 'edison' was the branch now)
Yes, I am using Yocto 1.0 - very soon I will migrate to M2 - pending
tasks at hand :-)
> Cheers,
>
> Bruce
>
>> cat hid-core.c.diff
>> --- linux.orig/drivers/hid/hid-core.c 2012-01-31 16:44:44.152001877 -0500
>> +++ linux/drivers/hid/hid-core.c 2012-01-31 16:46:34.608001870 -0500
>> @@ -1839,6 +1839,8 @@
>> { HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
>> USB_DEVICE_ID_1_PHIDGETSERVO_20) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT)
>> },
>> { HID_USB_DEVICE(USB_VENDOR_ID_YEALINK,
>> USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
>> +
Re: [yocto] How do I patch the kernel before it is built?
>>> I could not find a way to patch the kernel source before its is
>>> built.
>>>
>>> I promise to update the Yocto wiki's How do I section when I have a
>>> working solution for the following :-)
>>
>>
>> This should be covered in the existing documentation and also the
>> more general bitbake/oe-core docs.
>>
>>>
>>> Here is what I am trying to do:
>>>
>>> 1) Patch the kernel (add VID/PID to hid_ignore_list in
>>> drivers/hid/hid-core.c and also to add the VID/PID to .h file)
>>> 2) Build the kernel - no change here - standard kernel build
>>> 3) Build a kernel module
>>>
>>> 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.
I tried this - attached at the end of this email are my bbappend file
and my patches, when the recipe is bitbaked, it does not actually
apply the patch.
On a similar note - there seems to be a file in
meta/recipes-kernel/linux/linux-yocto called
tools-perf-no-scripting.patch
However, it does not seem to be used anywhere - is this just crud or I
am missing something? I was hoping to cheat off of the recipe that
uses it.
>>> 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
Thank you for this recipe - it seems like this is exactly what I was
looking for. I will cheat off of this as soon as I can patch my
kernel.
R E C I P E
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://linux/drivers/hid/hid-core.c.diff \
file://linux/drivers/hid/hid-ids.h.diff "
PR = "r3"
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
P A T C H
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
>>>
>>>
>>> Taking a look at this (while I was cutting and pasting), this should
>>> be in in the
>>> a 'linux-yocto' subdirectory if you want bitbake to pickup the patch and
>>> make it
>>> available to the linux-yocto recipe.
>>>
>>> i.e.
>>> ~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
>>>
>>> And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
>>> that part is
>>> automatic.
>>
>>
>> I tried this just now - here is what happens:
>>
>> Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
>> file://drivers/hid/file.diff
>> Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
>
>
> If you get a fetcher failire, you have it in the wrong place.
>
> Note: this has nothing to do with the kernel and is a general
> bitbake/oe-core question.
>
>
>>
>> Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
>> file://linux-yocto/drivers/hid/file.diff
>
>
> Interesting. I've never had to specify linux-yocto in my SRC_URIs,
> so something strange it going on here.
>
> Does anyone else have ideas here ?
>
>
>
>> Result - my diff files are copied in a directory called linux-yocto in
>>
>> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
>>
>> These patches are not applied in
>>
>> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
>>
>> Here is what the work directory looks like
>>
>>
>> autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
>> ls
>> git license-destdir linux linux-crownbay-standard-build linux-yocto
>> temp
>>
>> autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
>>
>>
>> I have attached the original set of files as a tar gzip
Re: [yocto] How do I patch the kernel before it is built?
\> I could not find a way to patch the kernel source before its is
> built.
>
> I promise to update the Yocto wiki's How do I section when I have a
> working solution for the following :-)
This should be covered in the existing documentation and also the
more general bitbake/oe-core docs.
>
> Here is what I am trying to do:
>
> 1) Patch the kernel (add VID/PID to hid_ignore_list in
> drivers/hid/hid-core.c and also to add the VID/PID to .h file)
> 2) Build the kernel - no change here - standard kernel build
> 3) Build a kernel module
>
> 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.
>>
>>
>>
>> I tried this - attached at the end of this email are my bbappend file
>> and my patches, when the recipe is bitbaked, it does not actually
>> apply the patch.
>>
>> On a similar note - there seems to be a file in
>> meta/recipes-kernel/linux/linux-yocto called
>> tools-perf-no-scripting.patch
>>
>> However, it does not seem to be used anywhere - is this just crud or I
>> am missing something? I was hoping to cheat off of the recipe that
>> uses it.
>>
> 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
>>
>>
>>
>> Thank you for this recipe - it seems like this is exactly what I was
>> looking for. I will cheat off of this as soon as I can patch my
>> kernel.
>>
>>
>> R E C I P E
>>
>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
>> linux-yocto_3.0.bbappend
>> FILESEXTRAPATHS_prepend := "${THISDIR}:"
>> SRC_URI += " file://linux/drivers/hid/hid-core.c.diff \
>> file://linux/drivers/hid/hid-ids.h.diff "
>> PR = "r3"
>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
>>
>> P A T C H
>>
>>
>>
>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
>
>
>
> Taking a look at this (while I was cutting and pasting), this should
> be in in the
> a 'linux-yocto' subdirectory if you want bitbake to pickup the patch
> and
> make it
> available to the linux-yocto recipe.
>
> i.e.
>
> ~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
>
> And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
> that part is
> automatic.
I tried this just now - here is what happens:
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://drivers/hid/file.diff
Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
>>>
>>>
>>>
>>> If you get a fetcher failire, you have it in the wrong place.
>>>
>>> Note: this has nothing to do with the kernel and is a general
>>> bitbake/oe-core question.
>>>
>>>
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://linux-yocto/drivers/hid/file.diff
>>>
>>>
>>>
>>> Interesting. I've never had to specify linux-yocto in my SRC_URIs,
>>> so something strange it going on here.
>>>
>>> Does anyone else have ideas here ?
>>>
>>>
>>>
Result - my diff files are copied in a directory called linux-yocto in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
These patches are not applied in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
Here is what the work directory looks like
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef0
[yocto] Unable to fetch file://lib for package emgd in yoctyo 1.2 (aka M2)
I am bitbaking core image sato for machine corwnbay (with the emgd
driver) and the emgd-driver-bin recipe seems to fail.
Here is the error. I searched the archives, but could not find anything.
Please advise.
Here is the output for bitbake -b
/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
NOTE: Running task 1 of 12 (ID: 4,
/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb,
do_fetch)
NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Started
ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
fetch URL file://lib from any source.' failed
ERROR: Logfile of failure stored in:
/ssd/autif/M2/crb/tmp/work/core2-poky-linux/emgd-driver-bin-1.8-r8/temp/log.do_fetch.31621
Log data follows:
| DEBUG: Trying PREMIRRORS
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['bzr',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['cvs',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['git',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['hg',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['osc',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['p4',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svk',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svn',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: Trying Upstream
| ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
fetch URL file://lib from any source.' failed
NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Failed
ERROR: Task 4
(/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb,
do_fetch) failed with exit code '1'
ERROR:
'/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb'
failed
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to fetch file://lib for package emgd in yoctyo 1.2 (aka M2)
Chatted with TomZ on #yocto on freenode IRC, it looks like I did not
perform the steps in section II from README in
meta-intel/meta-crownbay. It is likely that that's what I am missing.
On Tue, Feb 7, 2012 at 10:12 AM, autif khan wrote:
> I am bitbaking core image sato for machine corwnbay (with the emgd
> driver) and the emgd-driver-bin recipe seems to fail.
>
> Here is the error. I searched the archives, but could not find anything.
>
> Please advise.
>
> Here is the output for bitbake -b
> /data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
>
> NOTE: Running task 1 of 12 (ID: 4,
> /data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb,
> do_fetch)
> NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Started
> ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
> fetch URL file://lib from any source.' failed
> ERROR: Logfile of failure stored in:
> /ssd/autif/M2/crb/tmp/work/core2-poky-linux/emgd-driver-bin-1.8-r8/temp/log.do_fetch.31621
> Log data follows:
> | DEBUG: Trying PREMIRRORS
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['bzr',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['cvs',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['git',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['hg',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['osc',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['p4',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svk',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svn',
> '.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
> '/sources/', '', '', {}]
> | DEBUG: Trying Upstream
> | ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
> fetch URL file://lib from any source.' failed
> NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Failed
> ERROR: Task 4
> (/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb,
> do_fetch) failed with exit code '1'
> ERROR:
> '/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb'
> failed
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to fetch file://lib for package emgd in yoctyo 1.2 (aka M2)
>> > I am bitbaking core image sato for machine corwnbay (with the emgd >> > driver) and the emgd-driver-bin recipe seems to fail. >> > >> > Here is the error. I searched the archives, but could not find anything. >> > >> > Please advise. >> >> It looks like the problem may be forgetting to carry out the steps in >> section 'II. Special notes for building the meta-crownbay BSP layer' in >> the README. >> >> Note that this is no longer necessary if you use master - the >> emgd-driver-bin recipe has been upgraded to do the steps there >> automatically, which is now possible because it uses the LICENSE_FLAGS, >> but which does mean you need to set the LICENSE_FLAGS_WHITELIST as >> mentioned in the new README for crownbay in master. > > I can confirm that using the master branch is the way to go to make this > easy. > I documented my test of it at : > https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_setup_Intel.C2.AE_Atom.E2.84.A2_Processor_E6xx_based_system_for_media_playback.3F > Confirmed - after following all the steps in section II of the README in meta-intel/meta-crownbay - the build worked. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building your own UI
> 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. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch the kernel before it is built?
> R E C I P E
>
> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
> cat
> linux-yocto_3.0.bbappend
> FILESEXTRAPATHS_prepend := "${THISDIR}:"
> SRC_URI += " file://linux/drivers/hid/hid-core.c.diff \
> file://linux/drivers/hid/hid-ids.h.diff "
> PR = "r3"
> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
Fond the bug - it was a problem in the recipe
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
I was missing the ${PN} at the end.
Bruce - Thank you for all the help :-)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building your own UI
>>> 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
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] How do I patch the kernel before it is built?
>>> 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] How to find Log
>>> How to locate Log file while a error occur.
>>
>> It's under the directory ${WORKDIR}/temp/. Actually when an error occurs,
>> you can find the specific log file in the output, something like.
>>
>> ERROR: Logfile of failure stored in:
>> /intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
>>
>> Best Regards,
>> Lianhao
>>
>>
> I have a similar questions. If the error occurs and the console log
> information scrolls too far to get back to, how do I find the error log file
> then? I know what directory all the logs will be, but is there an easy way to
> find the one with the error??
This is true - I set my terminal scrollback to lines to avoid this.
May be that error line should be displayed both before and after the log.
I will see if I can find where this happens and create a patch. But
that will have to wait until after ELC 2012.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS fails to find an existing package
> Hello Khem Raj,
>
> On Wed, 2012-02-15 at 07:28 -0800, Khem Raj wrote:
>> the .a files are going into -static package and I guess
>> there is .so and not .so.X which means .so goes into
>> -dev package and hence your libharu package is empty
>> so you have to redirect the files into correct package
>> with the help of FILES_${PN} = "libharu.so " etc.
>
> You were right. Thanks for the tip.
>
> Adding FILES_${PN} = "${libdir}/lib*.so" made bitbake to create an
> non-empty libharu package thereby fixing the problem.
Heads up - if you are using 1.2 M2 - you may have to add the following
line in your recipe:
INSANE_SKIP_{PN} = "dev-so"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS fails to find an existing package
> Hello,
>
> On Thu, 2012-02-16 at 10:26 +0530, Joshua Immanuel wrote:
>> Can you please explain little bit more on what INSANE_SKIP_${PN} =
>> "dev-so" does. I don't find any documentation on it.
>
> I guess, it suppresses the warnings stating that an non-dev package
> contains symlink. This is the warning I got, when I packaged protobuf
> for yocto
In the e-mail I mentioned that if you are using M2 1.2 (means the
milestone 2 of version 1.2). 1,2 final will be released sometime in
the next few weeks/months.
Sometime between 1.1 and 1.2 M2 - the behavior has been changed where
the warning you described below has been changed to an error - thereby
- the said .so files are not actually included.
This does not apply if you are using 1.0 or 1.1 (not sure about 1.1
myself - I jumped from 1.0 to 1.2 M2)
Eventually - if/when you will be using a newer release of yocto - your
recipe will fail to work as expected - unless you have that insane
skip.
>
>> WARNING: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
>> protobuf path
>> '/work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so'
>> WARNING: QA Issue: protobuf:
>> /work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so
>> contains probably-redundant RPATH /usr/lib
>
> Adding the line INSANE_SKIP_${PN} = "dev-so" suppressed the above
> warnings.
This is correct.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-mono is released
meta-mono has been released. I have tested it on x86 and ARM successfully and on PPC and MIPS unsuccessfully. I will work on those architectures and time becomes available. If someone prefers that they need mono for MIPS or PPC immediately, please email me and I will see what I can do. comments and patches are welcome. The README for meta-mono is attached below: 1) Intro 2) Dependencies 3) Maintainer(s) & Patch policy 4) Copyright 5) Current State - x86 6) Current State - ARM 7) Current State - MIPS 8) Current State - PPC 9) Current State - alpha, amd64, hppa, ia64, s390 & sparc 10) TODO 1) Intro meta-mono is an OpenEmbedded layer that builds mono runtime and mono libraries to allow users to run .NET applications under linux built using OE. For more info about mono, see mono project's website. For more info on OpenEmbedded, see OE's website. 2) Dependencies On the host: The host system must have the following packges: gcc g++ patch diffstat texi2html texinfo cvs subversion gawk chrpath make libgl1-mesa-dev libglu1-mesa-dev libsdl1.2-dev git libxml-parser-perl bison gettext flex unzip rpm2cpio On the target: So far, Windows Forms applications have been tested under Sato. Mono does not require Sato, it does require X if you want to run Windows Forms applications. While mono can run w/o X, that recipe is not supported currently. It is unlikely to be supported. 3) Maintainer(s) & Patch policy Autif Khan (autif.ml...@gmail.com) autif on #yocto on freenode Send a patch or tar.gz file as attachment to the maintainer. 4) Copyright MIT/GPLv2 - following the lead of libgdiplus and mono 5) Current State - x86: Works Maintainer uses Yocto/OE/Poky as his build environment. He has built core-image-mono and core-image-mono-sdk for qemux86 and crownbay. The maintainer has also tested mono using all the runtime tests and few library tests that come with mono. The maintainer has also tested one Windows Forms application. 6) Current State - ARM: Works Maintainer uses Yocto/OE/Poky as his build environment. He has built core-image-mono for qemuarm. The maintainer has tested one Windows Forms application. 7) Current State - MIPS: Minor issues need to be resolved Maintainer uses Yocto/OE/Poky as his build environment. He has built core-image-mono for qemumips. A Windows Forms application fails to execute. More investigation is needed, if there is an interest in getting mono to work perfectly on MIPS, please contact the maintainer. 8) Current State - PPC: Does not build Maintainer uses Yocto/OE/Poky as his build environment. The build for core-image-mono for qemuppc fails. If there is an interest in getting mono to work perfectly on PPC, please contact the maintainer. 9) Current State - alpha, amd64, hppa, ia64, s390 & sparc: Unknown When qemu provided by Yocto supports one of these machines, the maintainer will support these architectures. 10) TODO 10.1) see if mono works for amd64, seems like qemux86-64 is available 10.2) investigate why windows forms apps dont run on MIPS 10.2) investigate why compilation fails for PPC 10.3) run mono runtime tests for ARM 10.4) run mono runtime tests for MIPS 10.5) run mono runtime tests for PPC 10.6) run mono library tests for ARM 10.7) run mono library tests for MIPS 10.8) run mono library tests for PPC 10.9) write recipes to create packages for runtime tests 10.10) write recipes to create packages for mscorlib library tests 10.11) write recipes to create packages for System.dll library tests 10.12) try mono on beagleboard (email maintainer when you do this, he will thank you) 10.13) write a recipe for windows forms app ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono is released
On Wed, Feb 22, 2012 at 1:25 PM, Autif Khan wrote: > meta-mono has been released. I have tested it on x86 and ARM > successfully and on PPC and MIPS unsuccessfully. I will work on those > architectures and time becomes available. If someone prefers that they > need mono for MIPS or PPC immediately, please email me and I will see > what I can do. At this point of time, I am using github for hosting the source. Michael Halstead is setting me up with git.yoctoproject The code will be moved over to git.yoctoproject in the next few days. I neglected to include the link in the previous email. Here are the relevant links: http://www.openembedded.org/wiki/LayerIndex meta-mono is listed under software support layers http://github.com/KokoFitClub/meta-mono This URI will very soon be replaced with git.yoctoproject.org Of course, Layer Index will be updated when this is done. Once again, please use it and let me know if something does not work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono is released
>> meta-mono has been released. I have tested it on x86 and ARM >> successfully and on PPC and MIPS unsuccessfully. I will work on those >> architectures and time becomes available. If someone prefers that they >> need mono for MIPS or PPC immediately, please email me and I will see >> what I can do. > > At this point of time, I am using github for hosting the source. > > Michael Halstead is setting me up with git.yoctoproject > > The code will be moved over to git.yoctoproject in the next few days. Things move at light speed apparently. All the code is available at git.yoctoproject and github. Only git.yoctoproject is authoritative, the code at github will be removed soon. Layer Index has been updated to reflect this. http://www.openembedded.org/wiki/LayerIndex Source is in git: git://git.yoctoproject.org:meta-mono.git http://git.yoctoproject.org (under Yocto MetaData Layers) > I neglected to include the link in the previous email. Here are the > relevant links: > > http://www.openembedded.org/wiki/LayerIndex > > meta-mono is listed under software support layers > > http://github.com/KokoFitClub/meta-mono > > This URI will very soon be replaced with git.yoctoproject.org > > Of course, Layer Index will be updated when this is done. > > Once again, please use it and let me know if something does not work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] USB touchscreen integration
I have a touchscreen made by AUO. It came with a driver which I have written a recipe for and it seems to be compiling and when the touchscreen is detected, the driver seems to be loading and controlling the touchscreen. (Its not under the control of hid_core driver). It shows up in /proc/bus/input/devices I: Bus=0003 Vendor=03eb Product=201c Version=1503 N: Name="pixcir_hid_mt_v2.0" P: Phys= S: Sysfs=/devices/pci:00/:00:17.0/:01:00.0/:02:02.0/usb3/3-1/3-1:1.0/input/input4 U: Uniq= H: Handlers=mouse0 B: PROP=0 B: EV=b B: KEY=400 0 0 0 0 0 0 0 0 0 0 B: ABS=65 3 It shows up as /dev/input/mouse0 While this is great, I am not sure how to wire this up with X so that the mouse is actually functional on the screen. A quick search at yocto wiki resulted in nothing, and google's search in site:yoctoproject.org also resulted in somewhat irrelevant results. I am using poky master on machine crownbay. X is running very well on an LVDS monitor. Keyboard and mouse run fine when externally connected. This query is limited to wiring a USB touchscreen with yocto. I am not sure what the next steps are. Please help! Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] apt-native_0.7.14.bb failed
> Hi, > > I tried to build image with: bitbake -k core-image-sato, > with http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2 > > but it failed, here is error message: > > --- > NOTE: Running task 5229 of 5288 (ID: 82, > /home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/apt-native_0.7.14.bb, > do_install) > NOTE: package apt-native-0.7.14-r5: task do_install: Started > ERROR: Function 'do_install_base' failed (see > /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773 > for further information) > ERROR: Logfile of failure stored in: > /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773 > Log data follows: > | oe_libinstall: cd bin > | oe_libinstall: install -d > /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/image/home/jingzhe/yocto/edison-6.0-build/tmp/sysroots/i686-linux/usr/lib// > | ERROR: oe_libinstall: unable to locate shared library > | ERROR: Function 'do_install_base' failed (see > /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773 > for further information) > NOTE: package apt-native-0.7.14-r5: task do_install: Failed > ERROR: Task 82 > (/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/apt-native_0.7.14.bb, > do_install) failed with exit code '1' > ERROR: > '/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/apt-native_0.7.14.bb' > failed > -- > > does anybody know how to solve it? > To help understand the context, can you please include the the MACHINE variable. Its in conf/local.conf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] USB touchscreen integration
On Thu, Mar 1, 2012 at 12:30 AM, Khem Raj wrote: > On 02/24/2012 10:04 AM, Autif Khan wrote: >> I have a touchscreen made by AUO. It came with a driver which I have >> written a recipe for and it seems to be compiling and when the >> touchscreen is detected, the driver seems to be loading and >> controlling the touchscreen. (Its not under the control of hid_core >> driver). >> >> It shows up in /proc/bus/input/devices >> >> I: Bus=0003 Vendor=03eb Product=201c Version=1503 >> N: Name="pixcir_hid_mt_v2.0" >> P: Phys= >> S: >> Sysfs=/devices/pci:00/:00:17.0/:01:00.0/:02:02.0/usb3/3-1/3-1:1.0/input/input4 >> U: Uniq= >> H: Handlers=mouse0 >> B: PROP=0 >> B: EV=b >> B: KEY=400 0 0 0 0 0 0 0 0 0 0 >> B: ABS=65 3 >> >> It shows up as /dev/input/mouse0 > > tslib handles /dev/input/touchscreen0 can you modify the driver ? After struggling, I realized that enabling events and events debug, I can get more information - which lead me to an issue with the LCD driver provided by the vendor. Vendor is supporting me since. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] iptables not building on master
I was working with M2 until recently and had to switch to master. After I switched to master, I tried to bitbake core-image-sato for machine crownbay. The build fails with the following error: unknown type name '__aligned_u64' The file in question is extenstions/libxt_pkttypes.c After a bit of investigation (thanks Khem) it seems like instead of /usr/include/linux/types.h, the include/linux/types.h from iptables source is being included. These a bit incompatible - specifically - the definition for __aligned_u64 is not in the latter. I am building core-image-sato for qemux86 and will report when the build reaches that point. Is this a known issue? *** This issue should be hitting anyone doing a clean build on master. Or at the very least someone who builds iptables recipe*** I looked at the recent change (post M2) that iptables was updated to 1.2.12.2 (from 1.2.12.1). There was a patch included for extensions/GNUmakefile which does not build "check" target. I looked at what it does and realized that someone more experienced that I am should look into this. Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] iptables not building on master
I love working with master: work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says: configure: error: Could not find pam/pam-devel, please install the needed packages. It seems like pam/pam-dev is needed in the target environment and not in the host environment. Although, iptables seem to have built. I can't imagine how it will be affected by meta-intel and meta-crownbay - they do not do anything with iptables. Trying to build core-image-minimal for crownbay now. Will report when done. On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan wrote: > I was working with M2 until recently and had to switch to master. > After I switched to master, I tried to bitbake core-image-sato for > machine crownbay. The build fails with the following error: > > unknown type name '__aligned_u64' > > The file in question is extenstions/libxt_pkttypes.c > > After a bit of investigation (thanks Khem) it seems like instead of > /usr/include/linux/types.h, the include/linux/types.h from iptables > source is being included. These a bit incompatible - specifically - > the definition for __aligned_u64 is not in the latter. > > I am building core-image-sato for qemux86 and will report when the > build reaches that point. > > Is this a known issue? > > *** This issue should be hitting anyone doing a clean build on master. > Or at the very least someone who builds iptables recipe*** > > I looked at the recent change (post M2) that iptables was updated to > 1.2.12.2 (from 1.2.12.1). There was a patch included for > extensions/GNUmakefile which does not build "check" target. I looked > at what it does and realized that someone more experienced that I am > should look into this. > > Thanks > > Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] iptables not building on master
Interesting - core image minimal builds fine - it does not actually build iptables. So the point is moot. I did a clean build for core-image-sato and it failed at the same place for the same error. I am no sure how meta-intel + meta-crownbay can interact with iptables - there is no recipe for iptables in meta-intel anywhere. Tom - If you have the bandwidth - can you please see if you can replicate my woes. I do not know anyone else who is on master and crownbay. If there - please let me know if things work for you. This broke for me when I moved from M2 to master. Thanks Autif On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan wrote: > I love working with master: > > work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says: > > configure: error: Could not find pam/pam-devel, please install the > needed packages. > > It seems like pam/pam-dev is needed in the target environment and not > in the host environment. > > Although, iptables seem to have built. I can't imagine how it will be > affected by meta-intel and meta-crownbay - they do not do anything > with iptables. > > Trying to build core-image-minimal for crownbay now. Will report when done. > > On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan wrote: >> I was working with M2 until recently and had to switch to master. >> After I switched to master, I tried to bitbake core-image-sato for >> machine crownbay. The build fails with the following error: >> >> unknown type name '__aligned_u64' >> >> The file in question is extenstions/libxt_pkttypes.c >> >> After a bit of investigation (thanks Khem) it seems like instead of >> /usr/include/linux/types.h, the include/linux/types.h from iptables >> source is being included. These a bit incompatible - specifically - >> the definition for __aligned_u64 is not in the latter. >> >> I am building core-image-sato for qemux86 and will report when the >> build reaches that point. >> >> Is this a known issue? >> >> *** This issue should be hitting anyone doing a clean build on master. >> Or at the very least someone who builds iptables recipe*** >> >> I looked at the recent change (post M2) that iptables was updated to >> 1.2.12.2 (from 1.2.12.1). There was a patch included for >> extensions/GNUmakefile which does not build "check" target. I looked >> at what it does and realized that someone more experienced that I am >> should look into this. >> >> Thanks >> >> Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding test files to an image
> Suppose I want to build the meta-intel/meta-sugarbay image and also include
> some video and audio files into the /home/root directory to facilitate
> testing of the video and audio players.
>
> Can I include these files in a recipe somewhere?
I use the recipe at the end of this message to include whatever I
want. This recipe has to be added to the image - I have a custom
image, so it goes in there. I am sure a recipe can be added to
something in local.conf - I just do not know that variable. My guess
it is IMAGE_IMSTALL += "mypics".
Regardless ...
mypics-1.0.tar.gz contains a file called COPYING and its mds5um on the
2nd line. It can be replaced with a license from common licenses
directory - but at the time when I wrote this recipe, I did not know
how to do that. Anything that goes in there ends up in
/home/root/mypics.
It can probably be tweaked to look better - I am sure SRC_URI line is
not perfect. But it seems to work between Edison to master
For larger files - like video worth 200MB or so, I just store them on
a hard disk and mount manually on /media/hdd or where-ever. Not that
it wont work in this recipe, just that it would take longer to build
the image etc.
All the best. Hopefully, this will get you started in the right direction.
LICENSE = "MyLic"
LIC_FILES_CHKSUM = "file://COPYING;md5=697172b05e4bff0a2421579697ba5653"
MY_DESTINATION = "/home/root/mypics"
SRC_URI = "file://mypics-1.0/mypics-1.0.tar.gz"
do_install_append() {
install -d ${D}${MY_DESTINATION}
install -m 0644 ${S}/* ${D}${MY_DESTINATION}
}
PR = "r0"
FILES_${PN} += "${MY_DESTINATION}/*"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding test files to an image
On Thu, Mar 8, 2012 at 4:43 PM, jfabernathy wrote:
> On 03/08/2012 04:33 PM, Rudolf Streif wrote:
>>
>> Jeff,
>>
>> Use hyphen instead of underscore for the subdirectory SRC_URI:
>>
>> SRC_URI = "file://myvideos-1.0/myvideos-1.0.tar.gz"
>>
>> and of course for the subdirectory in the subdirectory where the recipe is
>> located. The file fetcher copies the entire path
>> myvideos-1.0/myvideos-1.0.tar.gz to ${WORKDIR}.
>>
>> Rudi
>
> that didn't solve the problem. I still get file not found errors. The
> videos are unpack to WORKDIR, but the do_install is looking for them in S.
>
>
> install -d
> /build/sugarbay-master/tmp/work/x86_64-poky-linux/myvideos-1.0-r0/image/home/root/myvideos
> install -m 0644
> /build/sugarbay-master/tmp/work/x86_64-poky-linux/myvideos-1.0-r0/myvideos-1.0/*
> /build/sugarbay-master/tmp/work/x86_64-poky-linux/myvideos-1.0-r0/image/home/root/myvideos
>
> I think I need to control where the do_unpack puts the files.
>
Just a dumb thought, but I have been bitten many times by it.
please try bitbake myvideos -c cleansstate
then bitbake myvideos to build the recipe.
Alternatively, you can of course rev up the PR everytime you change
the recipe. But that is cumbersome.
And yes, I forgot to mention in my previous mail that the
mypics-1.0.tar.gz is located in
meta-autif/recipes-autif/mypics/mypics-1.0/mypics-1.0.tar.gz
As Rudolf suggested - bitbake is a bit finickey about '-' and '_'
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Announcement] 1.2 Milestone 3 Released
In the announcement for M2 (https://lists.yoctoproject.org/pipermail/yocto/2012-January/006735.html), compatible M2 for meta-intel - in addition to qt and eclipse plugin - were also included. However, meta-intel does not seem to have an 1.2_M3.final tag. 1.2_M3.rc1 does exist. So, my question is - will 1.2_M3.final be released in the near future? Or will it be skipped in the M4 era? I am building 1.2_M3.final with meta-intel's HEAD as I write this email and things seem to be going well. But I wanted to make sure that I am not missing anything. Thanks Autif On Wed, Mar 14, 2012 at 6:05 PM, Flanagan, Elizabeth wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > We are pleased to announce the third milestone of the coming release > of Yocto 1.2. This milestone release is available at: > > > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.2-m3/poky-edison-6.1.0-m3.tar.bz2 > or > > http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.2-m3/poky-edison-6.1.0-m3.tar.bz2 > > Additional tarballs for meta-qt3 and the eclipse plugin are available at: > > > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.2-m3/meta-qt3-edison-6.1.0-m3.tar.bz2 > > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.2-m3/eclipse-poky-edison-6.1.0-m3.tar.bz2 > > with mirror locations at: > > > http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.2-m3/meta-qt3-edison-6.1.0-m3.tar.bz2 > > http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.2-m3/eclipse-poky-edison-6.1.0-m3.tar.bz2 > > For information on 1.2 M3 test results see: > > http://wiki.yoctoproject.org/wiki/Yocto_1.2_Milestone_Test_Report > > Thank you everyone for all the hard work. > > - -- > Elizabeth Flanagan > Yocto Project > Release Engineer > > - > edison-6.1.0-m3 Errata > - > Release Name: poky-edison-6.1.0-m3 > Branch: 1.2_M3 > Tag: 1.2_M3.final > Hash: 320558f494c618f53e0c773db3ea0109476e8359 > md5: 24a90ec80d90c7f6757d9be50c2efe47 poky-edison-6.1.0-m3.tar.bz2 > Download Locations: > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.2-m3/poky-edison-6.1.0-m3.tar.bz2 > http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.2-m3/poky-edison-6.1.0-m3.tar.bz2 > > Release Name: eclipse-poky-edison-6.1.0-m3 > Branch: 1.2_M3 > Tag: 1.2_M3.final > Hash: 06652a1b3f7a82481b4a7f1fee279ce1c616013b > md5: eaa2d0e9a5554463b1d44b8b5f9d29e0 eclipse-poky-edison-6.1.0-m3.tar.bz2 > Download Locations: > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.2-m3/eclipse-poky-edison-6.1.0-m3.tar.bz2 > http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.2-m3/eclipse-poky-edison-6.1.0-m3.tar.bz2 > > Release Name: meta-qt3-edison-6.1.0-m3 > Branch: 1.2_M3 > Tag: 1.2_M3.final > Hash: 7e283e296d589256bef1a5652b72f264aba72e1a > md5: 89d04eaf3aead8322c3b601190391f2d meta-qt3-edison-6.1.0-m3.tar.bz2 > Download Locations: > http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.2-m3/meta-qt3-edison-6.1.0-m3.tar.bz2 > http://mirrors.kernel.org/yocto/yocto/milestones/yocto-1.2-m3/meta-qt3-edison-6.1.0-m3.tar.bz2 > > - > Features > - > - - HOB2 with redesigned UI and workflow implementation > - - Build appliance features and stability. > - - Error handling improvement such as display a summary of warning > and error messages at the end of Bitbake command. > - - Oracle/Sun Hotspot JDK/JRE support. > - - POSIX support > - - Enhancement to the Eclipse plug-in for Bitbake commander > > - > Known Issues > - > - - Bug 2066 - Glxgears failed in qemuarm/qemuppc/qemumips. > - - Bug 1898-[beagleboard C4] X server cannot startup with 3.0 kernel. > - - Bug 1906 -[QEMU] loses focus in qemux86-64 terminal When I press > key [CTRL+L] > - - Bug 1912-[beagleboard C4] Segmentation fault when reboot the > system with 3.0 kernel > - - Bug 1917-[non-GPLv3] image fails to boot up with no root filesystem found > - - Bug 1918-[x32] insane.bbclass reports error for x32 kernel > - - Bug 1899-[multilib] do_rootfs failed for lib-connman-gnome with ipk > - - Bug 1903-[HOB] do_rootfs failed with dummy-image against a clean working > dir > - - Bug 1910-[HOB] git recipes not shown in package view due to > inconsistent package name > - - Bug 1911-[HOB] non-GPLv3 build not work > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.16 (GNU/Linux) > > iQEcBAEBAgAGBQJPYRW0AAoJEEyK+E/MEkQPd8MIALCvjFoOhM8yU7osB/YYqBWC > 6NfnzRmPLnySGoeN3oobKomLG9ZoGmrwwuSfYfAlf3w6TDTAOunSi6x/94L1P6pa > 5cOiSCkZGYP4OLBDfGynciCRLTjmqREq7I6uEHscvvG9n8f5uN99hVG8zc99JAzi > Cu2z4iyr/qV/WLzJj7Fg9QPAWLUp3xtrgiqaa+0W26qdea6go6hbdbhZ0tYhf/HE > duXPgjgwhGHUKNFli3UDchJRdGoIvm/TLkKfzqgFEDdE/5lbKPvWg6Q21Ec04ZM9 > N8OqoAJJMOUtVztl3CIJ7bA2/zTNazIzLBVFiodtzpKJr9FMJsJKp+GpJybuCKg= > =n5IG > -END PGP SIGNATURE- > __
[yocto] Graphics Acceleration on crownbay - 1.2M2 + meta-intel tip
I am trying to get hardware accelerated graphics (video in particular) to work on my crownbay based hardware. I have EMGD 1.10 driver integrated and working. The evidence for this is that when I use glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. This is good, however, when I go over to the web2 browser (enabled by defining WEB = "web-webkit" for recipe task-core-apps-x11-pimlico) - I do not get graphics acceleration for javascript graphics. I also do not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps instead of the standard 25 or 29 fps. This was not the case when Yocto used EMGD 1.8 driver - video worked fine - I am not sure about accelerated javascript based graphics in browser as I was not as far ahead in the project. Is this a known issue? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
Minor correction to the subject - I am using 1.2M3, not 1.2M2 On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan wrote: > I am trying to get hardware accelerated graphics (video in particular) > to work on my crownbay based hardware. I have EMGD 1.10 driver > integrated and working. The evidence for this is that when I use > glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. > > This is good, however, when I go over to the web2 browser (enabled by > defining WEB = "web-webkit" for recipe task-core-apps-x11-pimlico) - I > do not get graphics acceleration for javascript graphics. I also do > not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps > instead of the standard 25 or 29 fps. > > This was not the case when Yocto used EMGD 1.8 driver - video worked > fine - I am not sure about accelerated javascript based graphics in > browser as I was not as far ahead in the project. > > Is this a known issue? > > Thanks > > Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
On Wed, Mar 21, 2012 at 4:23 PM, Tom Zanussi wrote: > On Wed, 2012-03-21 at 16:15 -0400, Autif Khan wrote: >> Minor correction to the subject - I am using 1.2M3, not 1.2M2 >> >> On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan wrote: >> > I am trying to get hardware accelerated graphics (video in particular) >> > to work on my crownbay based hardware. I have EMGD 1.10 driver >> > integrated and working. The evidence for this is that when I use >> > glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. >> > >> > This is good, however, when I go over to the web2 browser (enabled by >> > defining WEB = "web-webkit" for recipe task-core-apps-x11-pimlico) - I >> > do not get graphics acceleration for javascript graphics. I also do >> > not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps >> > instead of the standard 25 or 29 fps. >> > >> > This was not the case when Yocto used EMGD 1.8 driver - video worked >> > fine - I am not sure about accelerated javascript based graphics in >> > browser as I was not as far ahead in the project. >> > >> > Is this a known issue? >> > > > When I tested video using gst-launch, I saw the same thing, which was > due to a missing libva-tpi. The latest commit in meta-intel added that > and fixed the problem for me. > > commit 162f3d1d3c538d7582a5e81205a9cdab74125b2b > Author: Tom Zanussi > Date: Mon Mar 12 19:57:29 2012 -0500 > > ia32-base: add libva display dependencies to emgd xserver > I did a build today with tip - I have confirmed that I have this in the source. What files should have been added to the root filesystem image as a reult of adding libva-tpi, libva-glx and libva-egl? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
>> >> Minor correction to the subject - I am using 1.2M3, not 1.2M2 >> >> >> >> On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan wrote: >> >> > I am trying to get hardware accelerated graphics (video in particular) >> >> > to work on my crownbay based hardware. I have EMGD 1.10 driver >> >> > integrated and working. The evidence for this is that when I use >> >> > glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. >> >> > >> >> > This is good, however, when I go over to the web2 browser (enabled by >> >> > defining WEB = "web-webkit" for recipe task-core-apps-x11-pimlico) - I >> >> > do not get graphics acceleration for javascript graphics. I also do >> >> > not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps >> >> > instead of the standard 25 or 29 fps. >> >> > >> >> > This was not the case when Yocto used EMGD 1.8 driver - video worked >> >> > fine - I am not sure about accelerated javascript based graphics in >> >> > browser as I was not as far ahead in the project. >> >> > >> >> > Is this a known issue? >> >> > >> > >> > When I tested video using gst-launch, I saw the same thing, which was >> > due to a missing libva-tpi. The latest commit in meta-intel added that >> > and fixed the problem for me. >> > >> > commit 162f3d1d3c538d7582a5e81205a9cdab74125b2b >> > Author: Tom Zanussi >> > Date: Mon Mar 12 19:57:29 2012 -0500 >> > >> > ia32-base: add libva display dependencies to emgd xserver >> > >> >> I did a build today with tip - I have confirmed that I have this in the >> source. >> >> What files should have been added to the root filesystem image as a >> reult of adding libva-tpi, libva-glx and libva-egl? >> > > You should see those shared libraries in /usr/lib I think that I do: root@crownbay:/usr/lib# ls -l *libva* lrwxrwxrwx1 root root19 Mar 21 17:38 libva-egl.so.1 -> libva-egl.so.1.0.12 -rwxr-xr-x1 root root 3040 Mar 21 17:07 libva-egl.so.1.0.12 lrwxrwxrwx1 root root19 Mar 21 17:38 libva-glx.so.1 -> libva-glx.so.1.0.12 -rwxr-xr-x1 root root 14868 Mar 21 17:07 libva-glx.so.1.0.12 lrwxrwxrwx1 root root19 Mar 21 17:38 libva-tpi.so.1 -> libva-tpi.so.1.0.12 -rwxr-xr-x1 root root 3856 Mar 21 17:07 libva-tpi.so.1.0.12 lrwxrwxrwx1 root root19 Mar 21 17:38 libva-x11.so.1 -> libva-x11.so.1.0.12 -rwxr-xr-x1 root root 28476 Mar 21 17:07 libva-x11.so.1.0.12 lrwxrwxrwx1 root root15 Mar 21 17:38 libva.so.1 -> libva.so.1.0.12 -rwxr-xr-x1 root root 68816 Mar 21 17:07 libva.so.1.0.12 The older image did not have egl, glx and tpi However, when I execute gst-launch -v playbin2 uri=file:///media/hdd/BBB.ogv I get a lot of "There may be a timestamping problem, or this computer is too slow." warnings. Attached are the logs created by the above command. Is there something else that needs to be done? log.gz Description: GNU Zip compressed data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
>> >> >> Minor correction to the subject - I am using 1.2M3, not 1.2M2 >> >> >> >> >> >> On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan >> >> >> wrote: >> >> >> > I am trying to get hardware accelerated graphics (video in >> >> >> > particular) >> >> >> > to work on my crownbay based hardware. I have EMGD 1.10 driver >> >> >> > integrated and working. The evidence for this is that when I use >> >> >> > glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. >> >> >> > >> >> >> > This is good, however, when I go over to the web2 browser (enabled by >> >> >> > defining WEB = "web-webkit" for recipe task-core-apps-x11-pimlico) - >> >> >> > I >> >> >> > do not get graphics acceleration for javascript graphics. I also do >> >> >> > not get graphics acceleration when I watch an MP4 movie. I get 2-3 >> >> >> > fps >> >> >> > instead of the standard 25 or 29 fps. >> >> >> > >> >> >> > This was not the case when Yocto used EMGD 1.8 driver - video worked >> >> >> > fine - I am not sure about accelerated javascript based graphics in >> >> >> > browser as I was not as far ahead in the project. >> >> >> > >> >> >> > Is this a known issue? >> >> >> > >> >> > >> >> > When I tested video using gst-launch, I saw the same thing, which was >> >> > due to a missing libva-tpi. The latest commit in meta-intel added that >> >> > and fixed the problem for me. >> >> > >> >> > commit 162f3d1d3c538d7582a5e81205a9cdab74125b2b >> >> > Author: Tom Zanussi >> >> > Date: Mon Mar 12 19:57:29 2012 -0500 >> >> > >> >> > ia32-base: add libva display dependencies to emgd xserver >> >> > >> >> >> >> I did a build today with tip - I have confirmed that I have this in the >> >> source. >> >> >> >> What files should have been added to the root filesystem image as a >> >> reult of adding libva-tpi, libva-glx and libva-egl? >> >> >> > >> > You should see those shared libraries in /usr/lib >> >> I think that I do: >> >> root@crownbay:/usr/lib# ls -l *libva* >> lrwxrwxrwx 1 root root 19 Mar 21 17:38 >> libva-egl.so.1 -> libva-egl.so.1.0.12 >> -rwxr-xr-x 1 root root 3040 Mar 21 17:07 libva-egl.so.1.0.12 >> lrwxrwxrwx 1 root root 19 Mar 21 17:38 >> libva-glx.so.1 -> libva-glx.so.1.0.12 >> -rwxr-xr-x 1 root root 14868 Mar 21 17:07 libva-glx.so.1.0.12 >> lrwxrwxrwx 1 root root 19 Mar 21 17:38 >> libva-tpi.so.1 -> libva-tpi.so.1.0.12 >> -rwxr-xr-x 1 root root 3856 Mar 21 17:07 libva-tpi.so.1.0.12 >> lrwxrwxrwx 1 root root 19 Mar 21 17:38 >> libva-x11.so.1 -> libva-x11.so.1.0.12 >> -rwxr-xr-x 1 root root 28476 Mar 21 17:07 libva-x11.so.1.0.12 >> lrwxrwxrwx 1 root root 15 Mar 21 17:38 libva.so.1 -> >> libva.so.1.0.12 >> -rwxr-xr-x 1 root root 68816 Mar 21 17:07 libva.so.1.0.12 >> >> The older image did not have egl, glx and tpi >> >> However, when I execute gst-launch -v playbin2 uri=file:///media/hdd/BBB.ogv >> >> I get a lot of "There may be a timestamping problem, or this computer >> is too slow." warnings. >> >> Attached are the logs created by the above command. >> >> Is there something else that needs to be done? > > Hmm, looks like the acceleration isn't kicking in. Is that a supported > format for emgd accelaration? - I've been testing with 1080p .h264 > videos, http://www.bigbuckbunny.org/index.php/download/, maybe if you > could try that so we know we're on the same page. > I was hoping that Ogg Video is supported. I tried the H.264 (BBB stands for bigbuck bunny, I got these movies from an earlier email from you). But I am getting another error - ERROR: pipeline doesn't want to preroll. Do I need some other codec or some library? Are there licensing implications of using H.264? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
> I got a question about how to change the startup application with Yocto for > images generated with Yocto. > And I googled it and landed on this page: > https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts. > Pretty good, someone > was thinking about the same thing. But this page turns out to be empty. It > seems that we need to get > better than this. > > I'm wondering if someone could update this wiki page or if the information is > somewhere else... I do not know of if the information is elsewhere - I had to find this information for my project Here is my stab at it (already updated the wiki): Q: How do I change and add startup scripts? A: Edit meta/recipes-sato/matchbox-sato/matchbox-session-sato/session. Of course, if you have your own meta-layer, append the matchbox-session-sato_0.1.bb recipe. Disable 'matchbox-desktop' and 'matchbox-panel', however, do not disable 'exec matchbox-window-manager ...' Don't forget to run your app as a background process For example, the following code will start the fifteen game: #matchbox-desktop & # Lines containing feature-[foo] are removed at build time if the machine # doesn't have the feature "foo". #START_APPLETS=showdesktop,windowselector #END_APPLETS=clock,battery,systray,startup-notify,notify #END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone #matchbox-panel --titlebar --start-applets $START_APPLETS --end-applets $END_APPLETS & /usr/games/fifteen & exec matchbox-window-manager -theme Sato -use_desktop_mode decorated -use_cursor $SHOWCURSOR $@ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to install kernel module(s)?
> Hi, > I have made a custom kernel bb file, and get some modules in > tmp/deploy/images/modules-3.3.0-r1-pangu-test.tgz, > > but how to install the modules into the image? There is a chance that I completely misunderstand your scenario. Presumably, you have a recipe for your kernel modules - something akin to meta/recipes-kernel/hello-mod/hello-mod_0.1.bb In that case, to include the module, you need to add hello-mod to the IMAGE_INSTALL variable (either in local.conf or in your one meta-layer's images recipes) Now, if you are modifying the kernel's recipe to get the modules - I am not sure. Does this help? Can you please clarify, how the modules are built? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
>> Hi Autif, thanks a lot for providing the answer here. Since no one is >> showing any objections here, I updated the wiki page with your answer >> (https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup). >> Please let me know if there is any suggestions or concerns. > > > This rather narrow answer is only useful if you are running a MatchBox > desktop. > There are many other deployment scenarios which would require a different > approach. That is true. However, All over the Yocto Project's website - the common bitbake commands for an image is either core-image-minimal or core-image-sato. (core-image-sato-sdk also uses matchbox). minimal does not start any app - not counting daemons and gettys If the user chooses another window manager - they are/should be on their own. I just assumed that we are not trying to document the init process (bootloader, kernel, initrd, inittab, init.d etc) We are trying to answer a less experienced developer to replace the default window manager with their own app There is a chance that I am not aware of the default application being other than matchbox. Can you please provide me some counter example? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
Hi Song, I thought that I already updated the wiki. It seems like you created an extra page. "_scripts" is missing from the link. It should be there. Source: https://wiki.yoctoproject.org/wiki/Category:FAQ What I added days ago: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts What you added (which I think should be deleted): https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup Agree? On Tue, Apr 3, 2012 at 4:34 PM, Liu, Song wrote: > Hi Autif, thanks a lot for providing the answer here. Since no one is showing > any objections here, I updated the wiki page with your answer > (https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup). > Please let me know if there is any suggestions or concerns. > > Song > > -Original Message- > From: Autif Khan [mailto:autif.ml...@gmail.com] > Sent: Thursday, March 29, 2012 4:56 PM > To: Liu, Song > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] How to change the startup application > >> I got a question about how to change the startup application with Yocto for >> images generated with Yocto. >> And I googled it and landed on this page: >> https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup >> _scripts. Pretty good, someone was thinking about the same thing. But >> this page turns out to be empty. It seems that we need to get better than >> this. >> >> I'm wondering if someone could update this wiki page or if the information >> is somewhere else... > > I do not know of if the information is elsewhere - I had to find this > information for my project > > Here is my stab at it (already updated the wiki): > > Q: How do I change and add startup scripts? > > A: Edit meta/recipes-sato/matchbox-sato/matchbox-session-sato/session. > Of course, if you have your own meta-layer, append the > matchbox-session-sato_0.1.bb recipe. > > Disable 'matchbox-desktop' and 'matchbox-panel', however, do not disable > 'exec matchbox-window-manager ...' > > Don't forget to run your app as a background process > > For example, the following code will start the fifteen game: > > #matchbox-desktop & > > # Lines containing feature-[foo] are removed at build time if the machine # > doesn't have the feature "foo". > > #START_APPLETS=showdesktop,windowselector > #END_APPLETS=clock,battery,systray,startup-notify,notify > #END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone > > #matchbox-panel --titlebar --start-applets $START_APPLETS --end-applets > $END_APPLETS & > > /usr/games/fifteen & > > exec matchbox-window-manager -theme Sato -use_desktop_mode decorated > -use_cursor $SHOWCURSOR $@ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.2 changelog
> Here is the list as it stands: > > https://wiki.yoctoproject.org/wiki/Release_1.2_Changes > > (Note that changes in 1.1.1 have been separated out and should probably just > be deleted, hopefully I didn't miss any). I was pleasantly surprised when unionfs showed up in the kernel - it is not in the list though. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using and auditing kernel config fragments
> For some reason which I cannot work out, the rt2800usb options are > removed (rather then disabled) from the yocto kernel config, i.e., if I > run 'bitbake -c menuconfig linux-yocto', there is very little under > Drivers->Net->WLAN. If I run menuconfig in the devshell, there are lots > more WLAN drivers available, including the rt2800. Under Device Drivers -> Network device support -> Wireless LAN, You have to enable Ralink driver support to see the options for CONFIG_RT2800USB It is not under Device Drivers -> Network device support -> Wireless LAN It is under Device Drivers -> Network device support -> Wireless LAN -> Ralink driver support ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using and auditing kernel config fragments
>> For some reason which I cannot work out, the rt2800usb options are >> removed (rather then disabled) from the yocto kernel config, i.e., if I >> run 'bitbake -c menuconfig linux-yocto', there is very little under >> Drivers->Net->WLAN. If I run menuconfig in the devshell, there are lots >> more WLAN drivers available, including the rt2800. > > Under Device Drivers -> Network device support -> Wireless LAN, You > have to enable Ralink driver support to see the options for > CONFIG_RT2800USB > > It is not under Device Drivers -> Network device support -> Wireless LAN > > It is under Device Drivers -> Network device support -> Wireless LAN > -> Ralink driver support I forgot to mention - Under Networking Support -> Wireless, you need to enable cfg80211 AND msc80211 (Generic IEEE 802.11 Netowrking Stack) Then the Ralink driver support shows up under Wireless LAN ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build time data
> Is there a page somewhere that gives a rough idea of how quickly a full build > runs on various systems? I dont think there is a page anywhere. This is as rough as it can get on the two machine that I have not including the time it takes to download the source files. HP 2.8GHz core i-7 dual core hyper threaded machine with a 5400 rpm disk: BB_NUM_THREADS = "8" PARALLEL_MAKE = "8" core image minimal 2.5 hours core image sato 5 hours core image sdk 8-10 hours A build machine - Core i7-3960X 3.3 GHz - 6 cores hyperthreaded, with an SSD for build output and a 7200 rpm 6.0 Gbps claiming HDD for downloads, poky, whatever BB_NUM_THREADS = "24" PARALLEL_MAKE = "24" core image minimal 27 minutes core image sato 58-62 minutes core image sdk 110-120 minutes OS was always Ubuntu 11.10 - xubuntu on HP laptop, server in build machine. > I need a faster build platform, but want to get a reasonable price / > performance balance ;-) > > I'm looking at something like an i7-2700K but am not yet tied... The build machine cost about $3500 or so from tiger direct/newegg It was well worth it - instead of doing nightly builds, I can now do a clean build in under one hour. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] Fixed the URL for git repo for meta-openembedded
Signed-off-by: Autif Khan --- README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/README b/README index 5fafd9d..9f441f5 100644 --- a/README +++ b/README @@ -10,7 +10,7 @@ URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD -URI: git://git.openembedded.net/meta-openembedded +URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] to build the opencv lib
On Tue, Apr 24, 2012 at 6:13 AM, "沈华明@qq" <446257...@qq.com> wrote:
> Hi,
> I want to build the opencv lib into yocto,but I have no idea to do it. I
> have copyed a opencv_1.0.0.bb file
> into my layer,and after I do :bitbake opencv.,it comes the error:Nothing
> PROVIDES 'swig'(but )
> The recipe is the following,
You can not just copy a recipe - if it has dependencies, then you need
to copy those recipes too.
OR - the simpler thing to do
Add the entire meta layer to bblayers.conf
>
> DESCRIPTION = "Opencv : The Open Computer Vision Library"
> HOMEPAGE = "http://sourceforge.net/projects/opencvlibrary";
> SECTION = "libs"
> PRIORITY = "optional"
> LICENSE = "GPLv2"
>
> PR = "r3"
>
> DEPENDS = "libtool swig swig-native python jpeg zlib libpng tiff glib-2.0"
> #RDEPENDS_${PN} = "python jpeg zlib libpng tiff glib-2.0"
This is where the recipe says that it depends on "swig" and you likely
do not have swig in any of your meta layers. Chances are - you can get
swig from the same place you got the recipe for opencv
>
> SRC_URI = "${SOURCEFORGE_MIRROR}/opencvlibrary/opencv-${PV}.tar.gz \
> file://debian/010_enable_static.diff \
> file://debian/010_ffmpeg_linking.diff \
> file://debian/010_fix_optimisations.diff \
> file://debian/010_m4_syntax.diff \
> file://debian/010_makefile_syntax.diff \
> file://debian/010_python_cspec.diff \
> file://debian/020_python_linking.diff \
> file://debian/030_install_hook.diff \
> file://debian/050_rebootstrap.diff \
> file://debian/100_amd64.diff \
> file://debian/100_static_inline.diff \
> file://debian/100_ffmpeg_updates.diff \
> file://debian/110_dc1394.diff \
> file://debian/120_header_warnings.diff \
> file://debian/200_documentation.diff \
> file://debian/200_examples_makefile.diff \
> file://debian/210_openmp_compilation.diff \
> file://debian/300_fix_segfault_in_window_gtk.diff \
> "
>
> inherit distutils-base autotools pkgconfig
>
> EXTRA_OECONF = "--disable-debug --without-gtk --without-python
> --disable-apps az_python_cspec=${STAGING_INCDIR}/${PYTHON_DIR}"
>
> export BUILD_SYS
> export HOST_SYS
>
> do_configure() {
> gnu-configize
> cp ${STAGING_DATADIR}/libtool/config.{sub,guess} autotools
> oe_runconf
> }
>
> PACKAGES += "python-opencv"
>
> python populate_packages_prepend () {
> cv_libdir = bb.data.expand('${libdir}', d)
> cv_libdir_dbg = bb.data.expand('${libdir}/.debug', d)
> do_split_packages(d, cv_libdir, '^lib(.*)\.so$', 'lib%s-dev', 'OpenCV %s
> development package', extra_depends='${PN}-dev', allow_links=True)
> do_split_packages(d, cv_libdir, '^lib(.*)\.la$', 'lib%s-dev', 'OpenCV %s
> development package', extra_depends='${PN}-dev')
> do_split_packages(d, cv_libdir, '^lib(.*)\.a$', 'lib%s-dev', 'OpenCV %s
> development package', extra_depends='${PN}-dev')
> do_split_packages(d, cv_libdir, '^lib(.*)\.so\.*', 'lib%s', 'OpenCV %s
> library', extra_depends='', allow_links=True)
> }
>
> FILES_${PN}-doc += "${datadir}/opencv/"
> FILES_${PN} = "${bindir}"
> FILES_${PN}-dbg += "${libdir}/.debug"
> FILES_${PN}-dev = "${includedir} ${libdir}/pkgconfig"
>
> DESCRIPTION_python-opencv = "Python bindings to opencv"
> FILES_python-opencv = "${PYTHON_SITEPACKAGES_DIR}/*"
> RDEPENDS_python-opencv = "python-core"
>
> SRC_URI[md5sum] = "146a05005f2d2c16c4ee10ebd7f1dd58"
> SRC_URI[sha256sum] =
> "3a6ee888e4dd4ab7f2bc80d046688c099c6a95d1267af554b7c8f1543b66f21e"
>
>
>
> Thanks~
>
>
>
>
> ___
> 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] [PATCH 2/2] yocto-bsp: clarify help with reference to meta-intel
>>> + NOTE: For x86- and x86_64-based BSPs, the generated BSP assumes the >>> + presence of the of the meta-intel layer. Ensure the meta-intel layer >>> + is present and added to bblayers.conf. >>> >> >> Unless I am really mis-reading this I think "presence of the of the" >> should just be "presence of the" > > Oh wow. :-) > There is an illusion like this (attached jpeg) <>___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using meta repositories from OpenEmbedded and Yocto projects
> Hi, > Can I re-use the meta-openembedded git repositories from > openembedded.org and steve sakoman's meta-sakoman repositories (contains > support for the Gumstix Overo board), and check it out inside a checkout of > the yocto poky git repository, to take advantage of the latest yocto and > openembedded recipes and build it for the Gumstix Overo board? > > for example: > > poky > meta-openembedded (from git://git.openembedded.org/meta-openembedded) > meta-openembedded-contrib (from git://git.openembedded.org/meta-openembedded-contrib) > meta-sakoman.git (from git://www.sakoman.com/git/meta-sakoman) Short answer - Yes :-) At least the first one is used in meta-chromium > I've used OpenEmbedded before, and this is my first time with Yocto, and I > see a bunch of meta-* repositories, and was wondering if including them > inside the main poky folder was the way to go, to add additional support > from various sources. Long answer - Don't forget to add these meta layers in conf/bblayers.conf > Best regards, > > Elvis Dowson > > ___ > 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] When "bitbake core-image-sato-sdk", Error: Function failed: do_kernel_configme. Who can explain Bruce Ashfield's solution? thank you!
On Fri, May 4, 2012 at 12:10 PM, jack wrote: > Hello, all! When "bitbake core-image-sato-sdk", I was puzzled by such > errors: > > > NOTE: package > linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4: > task do_kernel_configme: Started > ERROR: Function failed: do_kernel_configme (see > /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/log.do_kernel_configme.18778 > for further information) > ERROR: Logfile of failure stored in: > /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/log.do_kernel_configme.18778 > Log data follows: > | ERROR: Function failed: do_kernel_configme (see > /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/log.do_kernel_configme.18778 > for further information) > | [INFO] doing kernel configme > | > /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/run.do_kernel_configme.18778: > line 92: > :/home/jackie/esdc/poky/scripts:/home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/linux/scripts/util: > No such file or directory > NOTE: package > linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4: > task do_kernel_configme: Failed > ERROR: Task 760 > (/home/jackie/esdc/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb, > do_kernel_configme) failed with exit code '1' > Waiting for 2 active tasks to finish: > 0: gcc-cross-4.6.3+svnr184847-r23 do_compile (pid 14631) > 1: eggdbus-native-0.6-r3 do_compile (pid 18130) > > > I googled and found Bruce Ashfield's solution: > In the meantime, if you remove the kern-tools-native_git.bbappend from the > meta-kernel-dev > layer, the AUTOREV setting will be removed, and you won't pull in tools that > are too > new for the matching kernel. > > But where is the kern-tools-native_git.bbappend and meta-kernel-dev? I am > newer to yocto, who can help me? There is no kern-tools-native_git.bbappend in what I could find. Can you please include your conf/bblayers.conf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] modify a kernel patch
On Tue, May 8, 2012 at 3:20 PM, Bruce Ashfield wrote: > > For anyone following along (all one of them), Frans and I have this > working now. It was a missing export of GUILT_BASE. I just sent a patch > to the list for it. Thanks! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On Tue, May 22, 2012 at 7:43 AM, jfabernathy wrote: > when testing an image using runqemu qemux86, can you get networking to > work?? mine comes up disabled. I want to test an application that requires > Internet access. Yes, I am able to get networking to work out of the box (bitbake core-image-sato, etc.) Internetworking does not work out of the box. This is accomplished over tun/tap devices - I do not know much about these virtual networking devices - they have never failed for me :-) The IP address of the emulated machine is 192.168.7.2 - The IP address of host machine is 192.168.7.1 You can not (out of the box) communicate with machines other than the host machine - so that would included internet etc. So, if you have an ssh server or a web-server running on the host machine - you can ssh to the host machine or browse a webpage using the browser. Alternatively, you can run a proxy server on the build machine and use it to get to the internet. You can run ifconfig to see if the network is configured properly on the emulated machine in the terminal. It should show 192.168.7.2 - if you do not see this - you do not have networking working. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_FSTYPES - what formats are supported?
> Is the list of values for IMAGE_FSTYPES documented somewhere? Searching > though the documentation shows references to it, but not a list of values > that are supported. meta/classes/image_types.bbclass look for IMAGE_TYPES ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Create a .bb for my aplication
On Tue, Sep 4, 2012 at 1:14 PM, Raul Rosetto Munoz wrote:
> Hello,
> I have some files that compose my application, and I want to put this files
> in the "/home/prjs" folder, I know That I need to install the prjs folder
> and the other files in this folder.
>
> What I dont know first, How to create a .bb file!
I am not sure what you mean. Do you mean that if you create a .bb
file, how to include it in your image?
>
> And another question.
>
> I saw that if I do some things like this:
>
> install -m 0644 ${WORKDIR}/fstab ${D}${sysconfdir}/fstab
>
> I will copy the file fstab in /etc/ folder.
>
> How I can know that {sysconfdir} correspond to /etc/ folder?
these are in poky/meta/conf/bitbake.conf
> And If it is correct how to know for what /home/ folder correspond {???}.
If they do not exist in bitbake.conf, you should use a local variable
in your recipe or local.conf.
> plz Can some one try to tell me???
>
> Thanks For All Help!
>
> --
> Raul Rosetto Muñoz
>
> ___
> 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] how to add a new environment in poky
On Tue, Sep 4, 2012 at 11:15 PM, Wangdawei wrote:
> Hi
>
> I need to add a new environment that LD_LIBRARY_PATH when I use my
> own external toolchain .
>
> I add 1 line in external-toolchain.inc “LD_LIBRARY_PATH =.
> "${EXTERNAL_TOOLCHAIN}/i586-target-linux-gnu/lib:"”,but there is no
> effect.when I used this toolchain to compile , there also isn’t this value ,
> so I want to ask how to add a environment in poky ? the run.compile.xxx
> script can get the value ?
I do not use external toolchains, so I can not provide a quick answer.
However, this has come up before - several times.
Please search the mailing list archives for external toolchain integration.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Love what you have done with Danny
I have been stuck with Denzil and have not kept up with git's tip (just because my hardware was fully supported by Denzil). However, when Danny came out I had to try it. I love what has been done with tracking the tasks being performed - instead of the build logs scrolling by (which I can tail in tmp/log/cooker/ anyway) Great job and thanks! Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
