Re: [yocto] What is GMAE?
On Fri, 14 Dec 2012, Tim Bird wrote: > On 12/14/2012 12:45 PM, Mark Hatle wrote: > > On 12/14/12 1:46 PM, Burton, Ross wrote: > >> On 14 December 2012 19:43, Tim Bird wrote: > >>> "If you need GMAE, you should use the bitbake meta-toolchain-gmae > >>> command. The resulting installation script when run will support such > >>> development. However, if you are not concerned with GMAE, you > >>> can generate the toolchain installer using bitbake meta-toolchain." > >>> > >>> After googling a bit, I figured out that GMAE stands for Gnome Mobile and > >>> Embedded. > >>> > >>> It might be good to put this acronym somewhere in the manual. > >>> (I'm still not sure if I need GMAE or not...) > >> > >> Basically, GMAE means GTK+ 2 and bits of the GNOME stack. > >> > >> A stealth plan of mine is to remove every trace of GMAE from Yocto. > >> It was an initiative Poky was involved with back in the OpenedHand > >> days that didn't really take off, and we're still carrying pieces of > >> it. > > > > I get this question a lot. With the ability (new in 1.3) to build an SDK > > based > > on the contents of any arbitrary image.. the meta-toolchain-gmae is simply > > not > > necessary. > > > > bitbake -c populate_sdk > > Aha. Thanks very much. > > Is this the preferred way to get a toolchain out of yocto? > That's exactly what I'm working on at the moment (well, after > fixing up some toolchain build issues I've encountered after > messing around a bit with the toolchain recipes...;-) some observations about the documentation (or lack thereof) of this task since tim seemed susprised about it, and i remember vaguely running across it once upon a time but forgetting about it. the entirety of mention of populate_sdk in all of the checked out yocto-docs repo is: $ grep -rw populate_sdk * documentation/ref-manual/eclipse/html/poky-ref-manual/ref-variables-glos.html: bitbake -c populate_sdk imagename). documentation/ref-manual/ref-variables.xml:bitbake -c populate_sdk imagename). documentation/ref-manual/ref-classes.xml:populate_sdk*.bbclass $ and part of that is a large comment at the end of ref-classes.xml listing all of the undocumented classes, so it would seem this task merits a bit more coverage. also, the yocto wiki currently contains this page for the "SDK Generator" but it hasn't been updated since 2010: https://wiki.yoctoproject.org/wiki/SDK_Generator just making some observations, i'm currently working through the ADT manual and building an SDK for my beagle as we speak. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] sometimes, the documentation is a bit too verbose and redundant
a general observation about something i've noticed about the yocto docs in places. here's an example from the ADT manual, section 2.1.1.1: "The following example commands download the Poky tarball, set up the Source Directory, set up the environment while also creating the default Build Directory, and run the bitbake command that results in the tarball ~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2: $ cd ~ $ mkdir yocto-project $ cd yocto-project $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.4/poky-tbd-8.0.tar.bz2 $ tar xjf poky-tbd-8.0.tar.bz2 $ source poky-tbd-8.0/oe-init-build-env $ bitbake adt-installer" it would seem that if someone is at this point, it's simply superfluous to be explaining how to create a new build directory and download a tarball, and untar it, and source the environment script -- that's just a lot of clutter. the only relevant line there is: $ bitbake adt-installer everything above that can be deleted, and the ADT manual can open with a simple list of prerequisites a reader is expected to understand, with a link if they don't. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH runqemu] runqemu: add support for FSTYPE=vmdk
Is there a chance this can get included? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Git tag systematics ?
Hi,
can anybody explain to me the systematics of the git tags ysed to mark
the Yocto / Poky releases?
For example, for Yocto 1.2 and before, we have release tags like
denzil-7.0, edison-6.0, bernard-5.0, laverne-4.0, etc.
Some parts of the current 1.3 Yocto release refer to it as "Poky 8.0"
or Version "8.0 Danny", see for example here:
https://www.yoctoproject.org/download/yocto-project-13-poky-80
However, there is no such release tag as "danny-8.0".
Instead, there is a tag "1.3" - but there are no similar tags as "1.1"
or "1.2" for the earlier releases?
What is the system in this numbering / tagging?
Releated: is there any document which explains the branch names being
used for development. for example, how can I find out ("officially")
what the branch name for Yocto 1.4 will be / is ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A committee is a group that keeps the minutes and loses hours.
-- Milton Berle
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] AUTOREVing with legacy recipe fetching from cvs
I apologize if I'm pointing out the obvious and/or something you've
already tried.
On Thu, Dec 13, 2012 at 11:22 AM, Andrea Galbusera wrote:
> After reading the manual I understand that the ${AUTOREV} method is
> not working with cvs. Is there an alternative approach to instruct the
> fetcher to always perform an update/checkout from the repository?
According to the bitbake documentation, if you specify a revision of
"now" will cause a fresh checkout on every build. Is that the same as
the "AUTOREV method"?
poky/bitbake/lib/bb/fetch2/cvs.py:
def need_update(self, url, ud, d):
if (ud.date == "now"):
return True
if not os.path.exists(ud.localpath):
return True
return False
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake user manual vs mega manual, and more info on local file fetcher?
On Thu, Dec 13, 2012 at 10:18 AM, Rifenbark, Scott M wrote: > we are revising the BitBake manual as part of the YP 1.4 release Personally I think it would be great if the bitbake documentation could be updated to include some of the information from Eren's document as well. Eren provides a "hands-on" demonstration of how bitbake works (and how to work with bitbake). The current documentation reads more like a dictionary (which is great if someone is looking for a dictionary-like treatment of bitbake). ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using SRC_URI_append with SOC_FAMILY
Hi,
I have defined the following variables defined
SOC_FAMILY = virtex-5 in my virtex-5.inc file, which is included by my
virtex-5-ml507-powerpc-440.conf machine configuration file.
I have defined MACHINE=virtex-4-ml507-powerpc-440 in my local.conf file
In my u-boot-xilinx.git recipe, I have defined
FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/${PN}/${SOC_FAMILY}' ],
d)}"
COMPATIBLE_MACHINE = "(virtex-5|microblaze)"
I will have multiple machine configurations, each of which will use either the
virtex-5 or microblaze SOC_FAMILY.
How can I specify SRC_URI_append, so that it appends based on the SOC_FAMILY,
rather than the machine configuration.
Setting SRC_URI_append_virtex-5 doesn't work (SOC_FAMILY), since the MACHINE
configuration is set to virtex-5-ml507-powerpc-440.
I don't want to end up specifying SRC_URI_append_virtex-5-ml507-powerpc-440,
and so forth for each and every MACHINE configuration that is based on a single
SOC_FAMILY.
What should I do to achieve the desired results, and optimize the recipe so
that it appends patches, based on the SOC_FAMILY, rather than the MACHINE
configuraiton.
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is GMAE?
On 12/14/12 21:57, Brian Hutchinson wrote: On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica wrote: Actually I talked with Richard regarding retiring the toolchain targets (meta-toolchain and meta-toolchain-gmae) as Mark mentioned that now we can build a toolchain matching the >image. Also, we're continue improving adt-installer which also allows you to setup sysroot using the target image as well. Richard's concern is there maybe some legacy user that >preferred the toolchain target. With the latest changes in toolchain generation which really maps to target images, probably we should unplug to legacy ones to make the toolchain generation more streamline. Thoughts or concerns? I'm one of the users that is stuck using Edison 6.0. I'm desperate for the ability to generate a toolchain and sysroot that matches our target. Right now I have to build meta-toolchain and then manually look in the tmp for sysroot-destdir related stuff from our build and copy it to the sysroot in /opt/poky and hand that out to developers. When our sister group overseas makes a change that effects the sysroot it breaks our build and I have to figure out what happened and manually adjust our sysroot to fix the problem. I sure would like to be able to just do an update and then bitbake the toolchain to pick up the changes. I figure we are stuck with Edison for a while ... can I back port these toolchain features you all are talking about to Edison? Hi Brian, I may be missing a trick here, but for our internal toolchain I pretty much made a copy of meta-toolchain, made a copy of the toolchain-packagegroup, edited the package group to contain the same libs, apps etc as my image, pointed meta-toolchain copy to that package-group instead of the default and now when ever I make an update to the image it is just a case of running bitbake core-image-product meta-toolchain-product and that spits out both the image and customized toolchain. If I have missed something obvious then please excuse my ramblings :) Cheers, Jack. Regards, 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] bitbake user manual vs mega manual, and more info on local file fetcher?
On Sat, Dec 15, 2012 at 10:53 AM, Trevor Woerner wrote: > On Thu, Dec 13, 2012 at 10:18 AM, Rifenbark, Scott M > wrote: > > we are revising the BitBake manual as part of the YP 1.4 release > > > Personally I think it would be great if the bitbake documentation > could be updated to include some of the information from Eren's > document as well. Eren provides a "hands-on" demonstration of how > bitbake works (and how to work with bitbake). The current > documentation reads more like a dictionary (which is great if someone > is looking for a dictionary-like treatment of bitbake). > I assume you're referring to Eren's blog post: http://hambedded.org/blog/categories/bitbake/ I'll be doing the bitbake manual update and will integrate similar information into the manual, or perhaps as new document in addition to the Bitbake manual. > ___ > 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] [Package Report System]Upgrade recipes name list
This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version is unstable" You can check the detail information at http://packages.yoctoproject.org/upgradepkgname PackageName Version UpVersion MaintainerNoUpgradeReason systemtap-uprobes 1.8+git1+48fa6b5e1d3e636 2.0 Tom Zanussi sysprof 1.1.8+git1+4692f85f625f4 1.2.0 Tom Zanussi shadow4.1.4.3 4.1.5.1 Scott Garman sudo 1.8.5p2 1.8.6 Scott Garman blktool 4-6 4 Scott Garman apmd 3.2.2-14 3.2.2 Scott Garman openssh 6.0p1 6.1p1 Scott Garman libidn1.25 1.26 Saul Wold libtasn1 2.14 3.2 Saul Wold libnl 3.2.143.2.16 Saul Woldlibnl-3.2.2 is incompatible w... createrepo0.4.110.9.9 Saul WoldVersions after 0.9.* use YUM,... apt 0.7.140.9.7.7 Saul Wold cmake 2.8.10.1 2.8.10.2 Saul Wold pkgconfig 0.25 0.27.1 Saul Woldremoves glib-conf, adds circu... build-appliance-image 1.0 3.2.1 Saul Wold util-linux2.22.12.22.2 Saul Wold dhcp 4.2.4-P2 4.2.4 Saul Wold mtdev 1.1.2 1.1.3 Ross Burton logrotate 3.8.1 3.8.3 Robert Yang iputils s20101006 20121126 Radu Moisan ed1.6 1.7 Radu Moisan cronie1.4.8 1.4.9 Radu Moisan apr-util 1.4.1 1.5.1 Radu Moisan liburcu 0.7.4 0.7.5 Radu Moisan curl 7.26.07.28.1 Radu Moisan js1.7.0+1.8.0rc11.60 Radu Moisan u-boot-fw-utils 2011.06 2012.10 Radu Moisan u-boot-mkimage2011.06 2012.10 Radu Moisan babeltrace1.0+git1+f6ed7fa4636ff22 1.0.0 Radu Moisan systemtap 1.8+git1+48fa6b5e1d3e636 2.0 Radu Moisan zlib 1.2.7 121 Radu Moisan mobile-broadband-provider-info1.0.0+gitr1+d9995ef693cb 20090309 Radu Moisan valgrind 3.7.0 3.8.1 Radu Moisan zypper1.5.3-git1+2c5bb6ceb99ec 11.0 Mark Hatle libzypp 0.0-git1+15b6c52260bbc52 11.0 Mark Hatle rpm 5.4.9
[yocto] [Package Report System]Manual check recipes name list
This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason lsb 4.1 4.1 102 day Yi Zhao ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
