Date   

[Package Report System]Upgrade recipes name list

Yocto Project Package Report System <package-reporting@...>
 

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 Maintainer NoUpgradeReason
systemtap-uprobes 1.8+git1+48fa6b5e1d3e636 2.0 Tom Zanussi <tom.zanussi@...>
sysprof 1.1.8+git1+4692f85f625f4 1.2.0 Tom Zanussi <tom.zanussi@...>
shadow 4.1.4.3 4.1.5.1 Scott Garman <scott.a.garman@...>
sudo 1.8.5p2 1.8.6 Scott Garman <scott.a.garman@...>
blktool 4-6 4 Scott Garman <scott.a.garman@...>
apmd 3.2.2-14 3.2.2 Scott Garman <scott.a.garman@...>
openssh 6.0p1 6.1p1 Scott Garman <scott.a.garman@...>
libidn 1.25 1.26 Saul Wold <sgw@...>
libtasn1 2.14 3.2 Saul Wold <sgw@...>
libnl 3.2.14 3.2.16 Saul Wold <sgw@...> libnl-3.2.2 is incompatible w...
createrepo 0.4.11 0.9.9 Saul Wold <sgw@...> Versions after 0.9.* use YUM,...
apt 0.7.14 0.9.7.7 Saul Wold <sgw@...>
cmake 2.8.10.1 2.8.10.2 Saul Wold <sgw@...>
pkgconfig 0.25 0.27.1 Saul Wold <sgw@...> removes glib-conf, adds circu...
build-appliance-image 1.0 3.2.1 Saul Wold <sgw@...>
util-linux 2.22.1 2.22.2 Saul Wold <sgw@...>
dhcp 4.2.4-P2 4.2.4 Saul Wold <sgw@...>
mtdev 1.1.2 1.1.3 Ross Burton <ross.burton@...>
logrotate 3.8.1 3.8.3 Robert Yang <liezhi.yang@...>
iputils s20101006 20121126 Radu Moisan <radu.moisan@...>
ed 1.6 1.7 Radu Moisan <radu.moisan@...>
cronie 1.4.8 1.4.9 Radu Moisan <radu.moisan@...>
apr-util 1.4.1 1.5.1 Radu Moisan <radu.moisan@...>
liburcu 0.7.4 0.7.5 Radu Moisan <radu.moisan@...>
curl 7.26.0 7.28.1 Radu Moisan <radu.moisan@...>
js 1.7.0+1.8.0rc1 1.60 Radu Moisan <radu.moisan@...>
u-boot-fw-utils 2011.06 2012.10 Radu Moisan <radu.moisan@...>
u-boot-mkimage 2011.06 2012.10 Radu Moisan <radu.moisan@...>
babeltrace 1.0+git1+f6ed7fa4636ff22 1.0.0 Radu Moisan <radu.moisan@...>
systemtap 1.8+git1+48fa6b5e1d3e636 2.0 Radu Moisan <radu.moisan@...>
zlib 1.2.7 121 Radu Moisan <radu.moisan@...>
mobile-broadband-provider-info1.0.0+gitr1+d9995ef693cb 20090309 Radu Moisan <radu.moisan@...>
valgrind 3.7.0 3.8.1 Radu Moisan <radu.moisan@...>
zypper 1.5.3-git1+2c5bb6ceb99ec 11.0 Mark Hatle <mark.hatle@...>
libzypp 0.0-git1+15b6c52260bbc52 11.0 Mark Hatle <mark.hatle@...>
rpm 5.4.9 5.4.9.0.20120508 Mark Hatle <mark.hatle@...>
fontconfig 2.10.1 2.10.2 Laurentiu Palcu <laurentiu.palcu@...>
xserver-xorg 1.13.0 1.13.1 Laurentiu Palcu <laurentiu.palcu@...>
xf86-video-intel 2.20.12 2.20.16 Laurentiu Palcu <laurentiu.palcu@...>
ghostscript 9.05 9.06 Kai Kang <kai.kang@...>
directfb 1.6.1 1.6.2 Kai Kang <kai.kang@...>
qmmp 0.6.1 0.6.5 Kai Kang <kai.kang@...>
trace-cmd 1.2+git1+7055ffd37beeb44 2.0.2 Darren Hart <dvhart@...>
kernelshark 1.2+git1+7055ffd37beeb44 2.0.2 Darren Hart <dvhart@...> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git;protocol=git
net-tools 1.60-23 1.60 Cristian Iorga <cristian.iorga@...>
iptables 1.4.15 1.4.16.3 Cristian Iorga <cristian.iorga@...>
dbus 1.6.4 1.6.8 Cristian Iorga <cristian.iorga@...>
bluez-hcidump 2.4 2.5 Cristian Iorga <cristian.iorga@...>
connman 1.4 1.9 Cristian Iorga <cristian.iorga@...>
ofono 1.10 1.11 Cristian Iorga <cristian.iorga@...>
iproute2 3.5.1 3.7.0 Cristian Iorga <cristian.iorga@...>
wpa-supplicant 1.0 1.1 Cristian Iorga <cristian.iorga@...>
telepathy-mission-control 5.13.0 5.14.0 Cristian Iorga <cristian.iorga@...>
telepathy-idle 0.1.12 0.1.14 Cristian Iorga <cristian.iorga@...>
telepathy-glib 0.19.8 0.20.1 Cristian Iorga <cristian.iorga@...>
pulseaudio 2.1 2.99.3 Cristian Iorga <cristian.iorga@...>
libmusicbrainz 3.0.3 4.0.0 Cristian Iorga <cristian.iorga@...>
gst-plugins-base 0.10.36 0.11.90 Cristian Iorga <cristian.iorga@...> not compatible with gst-fluen...
gst-plugins-good 0.10.31 0.11.90 Cristian Iorga <cristian.iorga@...> not compatible with gst-fluen...
gst-ffmpeg 0.10.13 0.11.2 Cristian Iorga <cristian.iorga@...> not compatible with gst-fluen...
gst-plugins-bad 0.10.23 0.11.90 Cristian Iorga <cristian.iorga@...> not compatible with gst-fluen...
gst-plugins-ugly 0.10.19 0.11.90 Cristian Iorga <cristian.iorga@...> not compatible with gst-fluen...
gstreamer 0.10.36 0.11.90 Cristian Iorga <cristian.iorga@...> not compatible with gst-flue...
gst-fluendo-mp3 0.10.19 0.10.20 Cristian Iorga <cristian.iorga@...>
xdg-utils 1.0.2 1.1.0 Constantin Musca <constantinx.musca@...> only release candidates avail...
ethtool 3.6 3.7 Constantin Musca <constantinx.musca@...>
pixman 0.28.0 0.28.2 Constantin Musca <constantinx.musca@...>
liberation-fonts 1.04 2.00.1 Constantin Musca <constantinx.musca@...> 2.00.0 - fontforge package re...
matchbox-panel-2 0.0+git1+cdf7a22716b8746 2.0 Constantin Musca <constantinx.musca@...>
lttng-viewer 0.12.38 0.12.38.21032011 Constantin Musca <constantinx.musca@...>
byacc 20120526 20121003 Bogdan Marinescu <bogdan.a.marinescu@...>
bdwgc 20110107 7.2alpha5 Bogdan Marinescu <bogdan.a.marinescu@...>
patch 2.6.1 2.7.1 Bogdan Marinescu <bogdan.a.marinescu@...>
tcf-agent 0.4.0+git1+4ef94ecb927a8 8.0 Bogdan Marinescu <bogdan.a.marinescu@...>
guile 2.0.6 2.0.7 Bogdan Marinescu <bogdan.a.marinescu@...>
automake 1.12.5 1.12.6 Bogdan Marinescu <bogdan.a.marinescu@...>
bison 2.5.1 2.7 Bogdan Marinescu <bogdan.a.marinescu@...>
gdb 7.5 7.5.1 Bogdan Marinescu <bogdan.a.marinescu@...>
nasm 2.10.05 2.10.06 Bogdan Marinescu <bogdan.a.marinescu@...>
lttng2-ust 2.0.5 2.1.0 Bogdan Marinescu <bogdan.a.marinescu@...>
lttng-modules 2.0.5 2.1.0 Bogdan Marinescu <bogdan.a.marinescu@...>
linux-libc-headers-yocto 3.4+git-1+a1cdb60720c452 3.4.9 Bogdan Marinescu <bogdan.a.marinescu@...>
linux-libc-headers 3.4.3 3.7 Bogdan Marinescu <bogdan.a.marinescu@...>
lttng-control 0.89 0.89.05122011 Bogdan Marinescu <bogdan.a.marinescu@...>
Upgradable Count: 72
Upgrade Total Count: 84
The based commit merge time is:
Fri Dec 14 10:00:37 2012 -0800
The based commit is:
commit 1cdc9b22fc685998508c864a7fdb0fe40df72a75
Author: Richard Purdie <richard.purdie@...>
Date: Fri Dec 14 17:21:05 2012 +0000
Any problem, please contact Saul Wold <sgw@...>


[Package Report System]Manual check recipes name list

Yocto Project Package Report System <package-reporting@...>
 

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 <yi.zhao@...... No data
e2fsprogs 1.42.1 1.42.5 110 day Scott Garman <scott.a.garman@... No data
chrpath 0.14 0.14 111 day Scott Garman <scott.a.garman@... No data
opensp 1.5.2 1.5.2 107 day Scott Garman <scott.a.garman@... No data
expat 2.1.0 2.0.1 110 day Scott Garman <scott.a.garman@... No data
nfs-utils 1.2.3 1.2.6 107 day Scott Garman <scott.a.garman@... No data
libpng 1.2.50 1.5.11 164 day Scott Garman <scott.a.garman@... 1.4.3 and later changes the AP...
psmisc 22.20 22.20 44 days Saul Wold <sgw@...... No data
cracklib 2.8.19 2.8.19 44 days Saul Wold <sgw@...... No data
sysstat 10.1.2 10.1.2 44 days Saul Wold <sgw@...... No data
less 456 451 44 days Saul Wold <sgw@...... No data
glew 1.9.0 1.9.0 44 days Saul Wold <sgw@...... No data
libexif 0.6.21 0.6.21 44 days Saul Wold <sgw@...... No data
sqlite3 3.7.14.1 3.7.14.1 44 days Saul Wold <sgw@...... No data
boost 1.51.0 1.51.0 44 days Saul Wold <sgw@...... No data
libcheck 0.9.9 0.9.9 44 days Saul Wold <sgw@...... No data
kconfig-frontends 3.6.0 3.6.0 44 days Saul Wold <sgw@...... No data
sysfsutils 2.1.0 2.1.0 44 days Saul Wold <sgw@...... No data
libcgroup 0.37.1 0.38-1 44 days Saul Wold <sgw@...... No data
console-tools 0.3.2 0.3.2 44 days Saul Wold <sgw@...... No data
libmad 0.15.1b 0.15.1b 44 days Saul Wold <sgw@...... No data
tzdata 2012d 2012c 101 day Radu Moisan <radu.moisan@inte... No data
watchdog 5.12 5.12 37 days Radu Moisan <radu.moisan@inte... No data
hdparm 9.39 9.39 37 days Radu Moisan <radu.moisan@inte... No data
tslib 1.0 1.0 104 day Radu Moisan <radu.moisan@inte... No data
zip 3.0 3.0 103 day Radu Moisan <radu.moisan@inte... No data
unzip 6.0 6.0 104 day Radu Moisan <radu.moisan@inte... No data
beecrypt 4.2.1 4.2.1 37 days Radu Moisan <radu.moisan@inte... No data
acpid 1.0.10 1.0.10 37 days Radu Moisan <radu.moisan@inte... No data
setserial 2.17 2.17 37 days Radu Moisan <radu.moisan@inte... No data
squashfs-tools 4.2 4.2 37 days Radu Moisan <radu.moisan@inte... No data
ubootchart 0.0+r12 0.0+r12 96 days Radu Moisan <radu.moisan@inte... No data
opkg 0.1.8+svnr649... 0.1.8 107 day Radu Moisan <radu.moisan@inte... No data
kmod 9 9 142 day Radu Moisan <radu.moisan@inte... No data
tinylogin 1.4 1.4 104 day Radu Moisan <radu.moisan@inte... TinyLogin was merged into Busy...
lame 3.99.5 3.99.5 109 day Radu Moisan <radu.moisan@inte... No data
ltp 20120903 20120903 19 days Mihai Lindner <mihaix.lindner... No data
prelink 1.0+git1+a2d8... 1.0+git1+9552... 107 day Mark Hatle <mark.hatle@windri... No data
x11vnc 0.9.13 0.9.13 104 day Laurentiu Palcu <laurentiu.pa... No data
adt-installer 0.1.8+svnr596... 1.1 96 days Jessica Zhang <jessica.zhang@... No data
cwautomacros 20110201 20110201 38 days Cristian Iorga <cristian.iorg... No data
quota 4.00 4.00 38 days Cristian Iorga <cristian.iorg... No data
libtirpc 0.2.2 0.2.2 38 days Cristian Iorga <cristian.iorg... No data
minicom 2.6.1 2.6.1 107 day Cristian Iorga <cristian.iorg... No data
rpcbind 0.2.0 0.2.0 38 days Cristian Iorga <cristian.iorg... No data
wireless-tools 29 29 38 days Cristian Iorga <cristian.iorg... No data
irda-utils 0.9.18 0.9.18 38 days Cristian Iorga <cristian.iorg... No data
tremor 20120314 20120122 38 days Cristian Iorga <cristian.iorg... No data
flac 1.2.1 1.2.1 38 days Cristian Iorga <cristian.iorg... No data
libomxil 0.9.3 0.9.3 38 days Cristian Iorga <cristian.iorg... No data
libsamplerate0 0.1.8 0.1.8 38 days Cristian Iorga <cristian.iorg... No data
freetype 2.4.10 2.4.10 109 day Constantin Musca <constantinx... No data
menu-cache 0.3.3 0.3.3 107 day Constantin Musca <constantinx... No data
libfm 0.1.17 1.30 108 day Constantin Musca <constantinx... No data
pcmanfm 0.9.10 0.9.10 107 day Constantin Musca <constantinx... No data
gtkhtml2 2.11.0+svnr11... 2.11.1 109 day Constantin Musca <constantinx... No data
mpfr 3.1.0 3.1.1 38 days Bogdan Marinescu <bogdan.a.ma... No data
libpcre 8.32 8.31 38 days Bogdan Marinescu <bogdan.a.ma... No data
python-scons 2.1.0 2.2.0 38 days Bogdan Marinescu <bogdan.a.ma... No data
strace 4.7 4.7 38 days Bogdan Marinescu <bogdan.a.ma... No data
tcl 8.5.11 8.5.12 38 days Bogdan Marinescu <bogdan.a.ma... No data
oprofile 0.9.7 0.9.8 38 days Bogdan Marinescu <bogdan.a.ma... No data
Manual Check Count: 62
Manual Need Check Count: 61
Any problem, please contact Saul Wold <sgw@...>


Re: bitbake user manual vs mega manual, and more info on local file fetcher?

Bill Traynor <wmat@...>
 




On Sat, Dec 15, 2012 at 10:53 AM, Trevor Woerner <twoerner@...> wrote:
On Thu, Dec 13, 2012 at 10:18 AM, Rifenbark, Scott M
<scott.m.rifenbark@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto


Re: What is GMAE?

Jack Mitchell <ml@...>
 

On 12/14/12 21:57, Brian Hutchinson wrote:
On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zhang@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto


Using SRC_URI_append with SOC_FAMILY

Elvis Dowson
 

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


Re: bitbake user manual vs mega manual, and more info on local file fetcher?

Trevor Woerner
 

On Thu, Dec 13, 2012 at 10:18 AM, Rifenbark, Scott M
<scott.m.rifenbark@...> 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).


Re: AUTOREVing with legacy recipe fetching from cvs

Trevor Woerner
 

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 <gizero@...> 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


Git tag systematics ?

Wolfgang Denk <wd@...>
 

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: wd@...
A committee is a group that keeps the minutes and loses hours.
-- Milton Berle


Re: [PATCH runqemu] runqemu: add support for FSTYPE=vmdk

Trevor Woerner
 

Is there a chance this can get included?


sometimes, the documentation is a bit too verbose and redundant

Robert P. J. Day
 

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
========================================================================


Re: What is GMAE?

Robert P. J. Day
 

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 <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 <image recipe>
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: <code class="filename">bitbake -c populate_sdk imagename</code>).
documentation/ref-manual/ref-variables.xml: <filename>bitbake -c populate_sdk imagename</filename>).
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
========================================================================


Happy Holidays

Osier-mixon, Jeffrey <jeffrey.osier-mixon@...>
 

Whatever holidays you celebrate, I hope they are happy and peaceful. See you next year!

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


Re: What is GMAE?

Mark Hatle <mark.hatle@...>
 

On 12/14/12 3:57 PM, Brian Hutchinson wrote:
On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zhang@...> 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?
There are changes to both bitbake and oe-core required. You'll have to look back at the oe-core mailing list to find the right set to backport.

We have backported the items to our 1.2 (7.0 Denzil) based system, but I'm not aware of anyone who is using it in 1.1 (6.0 Edison).

--Mark

Regards,

Brian


Re: What is GMAE?

Mark Hatle <mark.hatle@...>
 

On 12/14/12 4:12 PM, 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 <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 <image recipe>
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...;-)
I don't know if it's the preferred "Yocto Project" way.. but it's the only way I do it.

The code was implemented in the middle of the 1.3 process and does work in 1.3. (However multilib support may not be there. There are a series of patches pending for master that do enable the multilib support as part of the rpm/smart work.)

--Mark

-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

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


Re: [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse

Zhang, Jessica
 

Hi Timo,

Sorry for the delay, but finally got a chance to look into these patches. I like how it automate the docgen and integrate them into eclipse. The concern that I'm having is, it seems converting all the Yocto Project Docs, originally I thought only for ADT manual. So to view these doc in eclipse are nice, but since we don't have some corresponding feature support in eclipse plug-in, it'll look awkward to combine these docs with ADT plugin. BTW, to support our bitbake commander plug-in running on windows usage, we recently split the plug-in into 2 features: ADT and bitbake commander and the doc plug-in is part of ADT feature. So I'd suggest, if we want to show all the docs, probably create a separate Yocto Doc Feature. If we want to combine with ADT plug-in, then probably only covert the ADT manual content generation and integration. Make sense?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Timo Müller
Sent: Wednesday, December 12, 2012 5:10 AM
To: yocto@...
Cc: Timo Mueller
Subject: Re: [yocto] [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse

Hi,

mail@... wrote, On 06.12.2012 16:48:
From: Timo Mueller <timo.mueller@...>

Hi,

since the last proposal some things have changed:
1. Eclipse help generation is now part of the yocto-docs project
(currently available in the origin/timo branch) 2. We agreed that the
plugin should be licensed under the EPL v1.0 instead of having a
separate documentation plugin licensed under the CCA-SA 2.0 UK.

The last patch set was adding generated eclipse help files (html) to
the repository. One major change in this patch series is that I
extended the plugin build system to integrate the generation into the
build process. Thus keeping the eclipse help and the official
documentation in sync is now automated.
Also the eclipse help is now part of the user.doc plugin and no longer
contained in a separate plugin/feature.

Rational from the original patch:
<snip>
the documentation of the yocto project can currently be viewed online
or as a separate pdf. When using the eclipse ide to develop software
on base of a yocto sysroot and toolchain it would be convenient to
access the relevant parts of the documentation from within the ide.
</snip>
<snip>
I have intergrated this
documentation in the ide and it can now be accessed through the
eclipse help center (Help -> Help Contents).
</snip>

Best regards
Timo

Timo Mueller (7):
plugins/sdk.ide.doc.user: Add empty eclipse help
plugins/sdk.ide.doc.user: Add about.html to prepare addition of yocto
documentation
scripts/generate_doc.sh: Add script to handle eclipse help generation
plugins/sdk.ide.doc.user: Add yocto documentation to the table of
contents
scripts/generat-doc.sh: Copy generated eclipse help into the user.doc
plugin
scripts/build.sh: Add documentation generation to the default build
(TEMPORARY): Use origin/timo branch of yocto docs project

.../META-INF/MANIFEST.MF | 3 +-
plugins/org.yocto.sdk.ide.doc.user/about.html.in | 166 ++++++++++++++++++++
.../org.yocto.sdk.ide.doc.user/build.properties | 9 +-
plugins/org.yocto.sdk.ide.doc.user/html/book.css | 1 +
plugins/org.yocto.sdk.ide.doc.user/plugin.xml | 31 ++++
plugins/org.yocto.sdk.ide.doc.user/toc.xml | 21 +++
scripts/build.sh | 7 +
scripts/generate_doc.sh | 91 +++++++++++
8 files changed, 326 insertions(+), 3 deletions(-)
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/about.html.in
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/html/book.css
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/toc.xml
create mode 100755 scripts/generate_doc.sh
The name of the poky-ref-manual will be changed to ref-manual. This change has an impact on this patch series, since the name is used in the generate-doc shell script.
But with the temporary fix in patch 7, the timo branch is used, which will for the time being remain unaffected by the name changes. This way you can test the documentation integration proposed in this patch set.
I would like to get your opinion on the general approach to integrate the documentation into eclipse. If it fits into the eclipse-poky project in general, I will rewrite this patch series to reflect the changes. The rewrite will also remove the "the" from the different help chapters (as Scott pointed out to me).
I also agreed with Scott that once this approach is agreed on I will provide the necessary patches to the timo branch of the yocto-docs project and he will merge the eclipse generation into the master of the project.

Best regards,
Timo

PS: I also apologize for not signing off the patch series. I will make up for that in the reworked patches.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: What is GMAE?

Zhang, Jessica
 

So instead of back port, have you looked into adt-installer to address your need. It's sysroot is based on target images. The only downside is it's based on opkg and ipk if that's not your default package format.

-----Original Message-----
From: Brian Hutchinson [mailto:b.hutchman@...]
Sent: Friday, December 14, 2012 1:58 PM
To: Zhang, Jessica
Cc: Mark Hatle; yocto@...
Subject: Re: [yocto] What is GMAE?

On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zhang@...> 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?

Regards,

Brian


Re: What is GMAE?

Tim Bird <tim.bird@...>
 

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 <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 <image recipe>
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...;-)

-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Re: What is GMAE?

Brian Hutchinson <b.hutchman@...>
 

On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica <jessica.zhang@...> 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?

Regards,

Brian


Re: What is GMAE?

Zhang, Jessica
 

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?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Mark Hatle
Sent: Friday, December 14, 2012 12:46 PM
To: yocto@...
Subject: Re: [yocto] What is GMAE?

On 12/14/12 1:46 PM, Burton, Ross wrote:
On 14 December 2012 19:43, Tim Bird <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 <image recipe>

--Mark

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


Re: What is GMAE?

Mark Hatle <mark.hatle@...>
 

On 12/14/12 1:46 PM, Burton, Ross wrote:
On 14 December 2012 19:43, Tim Bird <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 <image recipe>

--Mark

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