Hi Ross,

On 13 Dec 2012, at 23:58, Burton, Ross wrote:

On 13 December 2012 23:23, Chris Tapp <opensource@...> wrote:

Unfortunately, adding xvimagesink hasn't helped. I also still don't really understand why webm and flv work ok.

They're probably using ximagesink, but depending on your pipeline
you're probably doing the decode for mp4 using VAAPI, which has
special requirements on sinks.

One question - is that also true for 'fakesink'? I thought that was supposed to accept any format, but it also throws the same error.

My pipeline is just uridecodebin ! fakesink

I'd throw in some debugging to inspect the pipelines constructed for flv vs mp4.

Ross

Chris Tapp

opensource@...
www.keylevel.com

Hi,

Added python source parsing abilities to create-recipe.

Signed-off-by: David Nyström <david.nystrom@...>
---
scripts/create-recipe | 51 ++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/scripts/create-recipe b/scripts/create-recipe
index 776c91d..a556e39 100755
--- a/scripts/create-recipe
+++ b/scripts/create-recipe
@@ -40,6 +40,8 @@ my $version = $predef_version;
my $description = "";
my $summary = "";
my $url = "";
+my $homepage;
+my @rdepends;
my $configure = "";
my $localename = "";
my @sources;
@@ -1679,6 +1681,7 @@ sub write_bbfile
open(BBFILE, ">${name}_$version.bb");
print BBFILE "SUMMARY = \"$summary\"\n";
print BBFILE "DESCRIPTION = \"$description\"\n";
+ print BBFILE "HOMEPAGE = \"$homepage\"\n";

print BBFILE "LICENSE = \"@license\"\n";
print BBFILE "LIC_FILES_CHKSUM = \"";
@@ -1698,6 +1701,10 @@ sub write_bbfile
print BBFILE "DEPENDS = \"@out\"\n\n";
};

+ if (@rdepends > 0) {
+ print BBFILE "RDEPENDS_\$\{PN\} += \"@rdepends\"\n";
+ }
+
print BBFILE 'PR = "r0"' . "\n\n";
print BBFILE "SRC_URI = \"";
foreach (@sources) {
@@ -1734,6 +1741,7 @@ sub calculate_sums
chomp($sha256sum);
}

+
############################################################################
#
# Main program
@@ -1820,6 +1828,40 @@ foreach (@dirs) {

$fulldir = $dir;

+if ( -e "$dir/setup.py" ) {
+ $python = 1;
+ push(@inherits, "distutils");
+
+ system("cd $dir ; python setup.py build sdist &> /dev/null");
+
+ $templic = `sed '/^License: */!d; s///;q' $dir/*.egg-info/PKG-INFO`;
+ chomp($templic);
+ push(@license, $templic);
+ $summary = `sed '/^Name: */!d; s///;q' $dir/*.egg-info/PKG-INFO`;
+ chomp($summary);
+ $description = `sed '/^Summary: */!d; s///;q' $dir/*.egg-info/PKG-INFO`;
+ chomp($description);
+ $homepage = `sed '/^Home-page: */!d; s///;q' $dir/*.egg-info/PKG-INFO`;
+ chomp($homepage);
+ $findoutput = `find $dir/*.egg-info/ -name "requires.txt" 2>/dev/null`;
+ @findlist = split(/\n/, $findoutput);
+ foreach (@findlist) {
+ # Adding dependency do buildreqs should be removed when
+ # distutils is unbroken, i.e. blocks setup.py install from
+ # downloading and installing dependencies.
+ push(@buildreqs, `sed 's/[^a-zA-Z]//g' $dir/*.egg-info/requires.txt`);
+ chomp(@buildreqs);
+ foreach $item (@buildreqs) {
+ $item = "python-" . $item
+ }
+ push(@rdepends, `sed 's/[^a-zA-Z]//g' $dir/*.egg-info/requires.txt`);
+ chomp(@rdepends);
+ foreach $item (@rdepends) {
+ $item = "python-" . $item
+ }
+ }
+}
+
if ( -e "$dir/autogen.sh" ) {
$configure = "autogen";
$uses_configure = 1;
@@ -1859,7 +1901,6 @@ if (-e "$dir/$name.pro") {
push(@inherits, "qmake2");
}

-
#
# This is a good place to generate configure.in
#
@@ -1868,6 +1909,8 @@ if (length($configure) > 2) {
system("cd $dir ; ./autogen.sh &> /dev/null");
}
}
+
+
@files = <$dir/configure>;
foreach (@files) {
process_configure("$_");
@@ -1893,8 +1936,10 @@ foreach (@files) {
guess_license_from_file("$_");
}

-
-guess_description($dir);
+
+if ($python != 1) {
+ guess_description($dir);
+}

#
# Output of bbfile file
--
1.7.9.5

Hi,

I am using EXTRA_OEMAKE to pass extra flags to make.

How can I pass different flags for different tasks?

In this case I am compiling an external kernel module and I need
different make flags for the do_make_scripts and do_compile tasks. If
I set EXTRA_OEMAKE in the recipe, all tasks use the same make flags.

Thanks,
Alex

My 2c (USD) is for clarity on ADT vs. SDK vs. Toolchain.

Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176

a general preference on my part, but i think it would be useful if
any yocto docs that are discussing toolchains or cross-compilation or
the like use *non*-x86 architectures to get the point across.

for example, consider the current application developer's guide.
part of it uses, as an example, the toolchain installer
poky-eglibc-x86_64-i586-toolchain-gmae-1.4.sh. while this works just
fine, of course, what it does is potentially co-mingle both the dev
host content and target host content, making it harder than necessary
for the reader to draw a clear distinction between the two.

if any example related to compilation or a toolchain involves, say,
an *arm* target, then it's *immediately* obvious (using the "file"
command) whether something belongs on the dev host or on the target.

also, if you're using x86 for both dev content and target content,
you run the risk of an example working by accident since you're
picking up natively-installed tools when you shouldn't be. if you use
a non-x86 arch, there's little chance of that happening.

just my $0.02 (Cdn).

rday


--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

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

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

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

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

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

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

Is there a chance this can get included?

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

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

Whatever holidays you celebrate, I hope they are happy and peaceful. See you next year!
--
Jeff Osier-Mixon http://jefro.net/blog