Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
2014-04-16 8:49 GMT+02:00 Journeyer J. Joh : > Hello, > > First of all I thank Nicolas Dechesne and Brian Hutchinson, for the > previous kind replies. > > While I was reading documents from Yocto Project, I found my source code in > use in my company is of Open Embedded for MSM. > > I found this from the git remote url of my surce code. It is > git://codeaurora.org/quic/le/openembedded/openembedded-core > > And the one of Yocto project is > git://git.yoctoproject.org/poky > > From the git log prints poky is actively developped now but > openembedded-core is not. > > In a nutshell(I learned this expression today^^), > - What is the relationship between those two? Any differences? Commons? > - Can I refer to the documents about poky for my openembedded-core? > Hi, the relationship between OpenEmbedded and Yocto Project is summed at http://en.wikipedia.org/wiki/Yocto_Project You may want to use the up to date layer list (with links to the official git repositories) here: http://layers.openembedded.org/layerindex/branch/master/layers/ -- Regards Samuel -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] How can I get the toolchain?
Hi, How can I extract the toolchain in my oe build result? Regards, Changhyeok -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rrdtool: enable libwrap, perl and python bindings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chong Lu schreef op 16-04-14 08:51:
> 1. default enable libwrap, perl and python bindings
A number of big distros are moving away from tcpwrappers, Arch has removed
it years ago and fedora looked into it a while ago. Since tcpwrappers hasn't
seen a release (or development) in years I think we should default it to off.
regards,
Koen
> 2. rrdtool uses perl.real, perl.real doesn't know where the PERL5LIB
> should be when prebuilts are used. Use the wrapper perl instead, perl
> sets PERL5LIB and invokes perl.real 3. While using dash as /bin/sh,
> subsequent commands in functions will not use the environment variables
> passed to the function call line unless explicitly run "export ENV_VAR".
> 4. delete unrecognized options: "--enable-local-libpng" and
> "--enable-local-zlib"
>
> Signed-off-by: Chong Lu ---
> meta-oe/recipes-extended/rrdtool/rrdtool_1.4.7.bb | 127
> +++-- 1 file changed, 120 insertions(+), 7 deletions(-)
>
> diff --git a/meta-oe/recipes-extended/rrdtool/rrdtool_1.4.7.bb
> b/meta-oe/recipes-extended/rrdtool/rrdtool_1.4.7.bb index
> 533451f..422e22f 100644 ---
> a/meta-oe/recipes-extended/rrdtool/rrdtool_1.4.7.bb +++
> b/meta-oe/recipes-extended/rrdtool/rrdtool_1.4.7.bb @@ -5,6 +5,7 @@
> LICENSE = "GPLv2" LIC_FILES_CHKSUM =
> "file://COPYING;md5=44fee82a1d2ed0676cf35478283e0aa0"
>
> DEPENDS = "libpng zlib cairo pango glib-2.0 libxml2" +DEPENDS_${PN}-perl
> = "perl-module-lib perl-module-dynaloader"
>
> PR = "r2"
>
> @@ -15,25 +16,137 @@ SRC_URI =
> "http://oss.oetiker.ch/rrdtool/pub/rrdtool-${PV}.tar.gz \ SRC_URI[md5sum]
> = "ffe369d8921b4dfdeaaf43812100c38f" SRC_URI[sha256sum] =
> "956aaf431c955ba88dd7d98920ade3a8c4bad04adb1f9431377950a813a7af11"
>
> -inherit autotools gettext +inherit autotools gettext pythonnative
> perlnative python-dir
>
> EXTRA_AUTORECONF = "-I m4"
>
> -PACKAGECONFIG ??= "" +PACKAGECONFIG ??= "python libwrap perl" +
> +PACKAGECONFIG[python] = "--enable-python=yes \
> +am_cv_python_pythondir=${STAGING_LIBDIR}/python${PYTHON_BASEVERSION}/site-packages
> \
> +am_cv_python_pyexecdir=${STAGING_LIBDIR}/python${PYTHON_BASEVERSION}/site-packages,\
>
>
+--disable-python,python,"
> + +PACKAGECONFIG[perl] = \ +"--enable-perl=yes
> --with-perl-options='INSTALLDIRS="vendor"' \ +ac_cv_path_PERL_CC='${CC}',
> \ +--disable-perl,perl," + +PACKAGECONFIG[libwrap] =
> ",--disable-libwrap,tcp-wrappers,libwrap" PACKAGECONFIG[dbi] =
> "--enable-libdbi,--disable-libdbi,libdbi"
>
> EXTRA_OECONF = " \ --enable-shared \ ---enable-local-libpng \ -
> --enable-local-zlib \ ---disable-libwrap \ --program-prefix='' \
> rd_cv_ieee_works=yes \ ---disable-perl \ ---disable-python \
> --disable-ruby \ --disable-lua \ --disable-rpath \ "
>
> +# don't use perl.real, this results in break issues with prebuilts since
> perl.real doesn't +# know where the PERL5LIB is... +# use wrapper perl
> instead +EXTRA_OEMAKE = "PERL=${STAGING_BINDIR_NATIVE}/perl-native/perl
> FULLPERL=${STAGING_BINDIR_NATIVE}/perl-native/perl" + +export BUILD_SYS
> +export HOST_SYS +export STAGING_LIBDIR +export STAGING_INCDIR +
> +do_configure() { + #fix the pkglib problem with newer automake + #perl +
> sed -i -e "s|-Wl,--rpath -Wl,\$rp||g" \ +
> ${S}/bindings/perl-shared/Makefile.PL + + #python + sed -i -e
> '/PYTHON_INCLUDES="-I${/c \ +
> PYTHON_INCLUDES="-I=/usr/include/python${PYTHON_BASEVERSION}"' \ +
> ${S}/m4/acinclude.m4 +#remove the hardcoded $(libdir) rpath + sed -i
> -e
> 's|--rpath=$(libdir)||g' ${S}/bindings/Makefile.am + +
> autotools_do_configure + +perl_version=`perl -v 2>/dev/null | \ +
> sed -n 's/This is perl.*v[a-z ]*\([0-9]\.[0-9][0-9.]*\).*$/\1/p'` + +
> #modify python sitepkg + #remove the dependency of perl-shared:Makefile +
> #or perl-shared/Makefile will be regenerated +#if any code touch
> bindings/Makefile after below perl bindings code +sed -i -e
> "s:\$(PYTHON) setup.py install:\$(PYTHON) setup.py install \ +
> --install-lib=${D}${PYTHON_SITEPACKAGES_DIR}:" \ +-e
> "s:perl-shared/Makefile.PL Makefile:perl-shared/Makefile.PL:" \ +
> ${S}/bindings/Makefile + +#redo the perl bindings + ( + cd
> bindings/perl-shared; + perl -I${STAGING_LIBDIR}/perl/$perl_version
> Makefile.PL INSTALLDIRS="vendor" +INSTALLPRIVLIB="abc"; + sed -i
> -e
> "s| ${libdir}/perl/| ${STAGING_LIBDIR}/perl/|g" Makefile; + + cd
> ../../bindings/perl-piped; + perl -I${STAGING_LIBDIR}/perl/$perl_version
> Makefile.PL INSTALLDIRS="vendor"; + sed -i -e "s| ${libdir}/perl/|
> ${STAGING_LIBDIR}/perl/|g" Makefile; +) + + #change the interpreter
> in
> file +sed -i -e "s|^PERL = ${STAGING_BINDIR_NATIVE}/.*|PERL =
> /usr/bin/perl|g" \ + ${S}/examples/Makefile +sed -i -e
> "s|${STAGING_BINDIR_NATIVE}/perl-native/perl|/usr/bin/perl|g" \ +
> ${S}/examples/*.pl +} + +python populate_packages_prepend() { +def
> fill_more(name, dbg=True,
[oe] [PATCH 2/2] gnome-disk-utility: change PACKAGECONFIG default: remove nautilus
gnome-doc-utils had to be added when not depending on nautilus
Signed-off-by: Andreas Müller
---
.../recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb
b/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb
index 6bfbfaf..bf836cc 100644
--- a/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb
+++ b/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb
@@ -3,7 +3,7 @@ SUMMARY = "GNOME disk utility"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=e9115d11797a5e6b746b4e9b90194564"
-DEPENDS = "glib-2.0 gtk+ libnotify libunique udisks avahi-ui virtual/libx11
libatasmart"
+DEPENDS = "glib-2.0 gtk+ libnotify libunique udisks avahi-ui virtual/libx11
libatasmart gnome-doc-utils"
PR = "r4"
@@ -20,7 +20,7 @@ SRC_URI += "\
EXTRA_OECONF += "--disable-scrollkeeper"
-PACKAGECONFIG ??= "nautilus"
+PACKAGECONFIG ??= ""
PACKAGECONFIG[nautilus] =
"--enable-nautilus-extension,--disable-nautilus-extension,nautilus"
do_configure_prepend() {
--
1.8.3.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] evince: make nautilus extension a PACKAGECONFIG and disable by default
Signed-off-by: Andreas Müller
---
meta-gnome/recipes-gnome/evince/evince_2.32.0.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
b/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
index 263765f..5aa485e 100644
--- a/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
+++ b/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
@@ -2,7 +2,7 @@ SUMMARY = "Evince is a document viewer for document formats
like pdf, ps, djvu"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=96f2f8d5ee576a2163977938ea36fa7b"
SECTION = "x11/office"
-DEPENDS = "gnome-icon-theme gnome-doc-utils-native libgnome-keyring nautilus
tiff libxt ghostscript poppler libxml2 gtk+ gconf libglade"
+DEPENDS = "gnome-icon-theme gnome-doc-utils-native libgnome-keyring tiff libxt
ghostscript poppler libxml2 gtk+ gconf libglade"
PR = "r5"
@@ -17,7 +17,6 @@ SRC_URI[archive.md5sum] = "ebc3ce6df8dcbf29cb9492f8dd031319"
SRC_URI[archive.sha256sum] =
"2a4c91ae38f8b5028cebb91b9da9ddc50ea8ae3f3d429df89ba351da2d787ff7"
EXTRA_OECONF = " --enable-thumbnailer \
- --enable-nautilus \
--disable-scrollkeeper \
--enable-pixbuf \
--disable-help \
@@ -28,6 +27,9 @@ do_install_append() {
install -m 0755 ${S}/data/icons/48x48/apps/evince.png
${D}${datadir}/pixmaps/
}
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[nautilus] = "--enable-nautilus,--disable-nautilus,nautilus"
+
RDEPENDS_${PN} += "glib-2.0-utils"
PACKAGES =+ "${PN}-nautilus-extension"
--
1.8.3.1
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 0/2] avoid nautilus build by default
There is no reason why we need to build nautilus when using evince and/or gnome-disk-utility. Andreas Müller (2): evince: make nautilus extension a PACKAGECONFIG and disable by default gnome-disk-utility: change PACKAGECONFIG default: remove nautilus meta-gnome/recipes-gnome/evince/evince_2.32.0.bb| 6 -- .../recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) -- 1.8.3.1 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
On Tue, Apr 15, 2014 at 11:49 PM, Journeyer J. Joh wrote: > From the git log prints poky is actively developped now but > openembedded-core is not. OpenEmbedded-core is very much active and is at heart of everything around OE poky is a distribution based on OpenEmbedded and it also serves as default reference distribution of Yocto Project and there are many other distributions which use OE technology for build system, poky uses combo layer tools to merge the layers it uses into a single git repository thats why you see different commit SHAs, some other distros e.g. SHR or Angstrom uses different mechanisms than poky for creating the sandbox out of many layers, where the individual layers are clones and consumed as it is. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] How can I get the toolchain?
On Wed, Apr 16, 2014 at 12:07 AM, Changhyeok Bae wrote: > Hi, > > How can I extract the toolchain in my oe build result? > bitbake -cpopulate_sdk should generate a self-installer .sh script which then you can run and install it > Regards, > Changhyeok > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] rsyslog: add status command and minor fixes for initscript
From: Jackie Huang
- add status command
- remove the unsupported option:
rsyslogd: error: option -c is no longer supported - ignored
- add --oknodo for do_start
Signed-off-by: Jackie Huang
---
.../recipes-extended/rsyslog/rsyslog/initscript| 35 ++--
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
index 8dee684..4121434 100644
--- a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
+++ b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
@@ -9,7 +9,8 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin
NAME=rsyslog
RSYSLOGD=rsyslogd
RSYSLOGD_BIN=/usr/sbin/rsyslogd
-RSYSLOGD_OPTIONS="-c5"
+# with rsyslog 7, -c is no longer supported
+RSYSLOGD_OPTIONS=""
RSYSLOGD_PIDFILE=/var/run/rsyslogd.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
@@ -27,7 +28,10 @@ do_start()
# Return
# 0 if daemon has been started
# 1 if daemon could not be started
-start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON --
$DAEMON_ARGS || return 1
+# if daemon had already been started, start-stop-daemon will return 1
+# so add -o/--oknodo(if nothing is done, exit 0)
+start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON \
+ --oknodo -- $DAEMON_ARGS || return 1
}
#
# Function that stops the daemon/service
@@ -56,6 +60,20 @@ do_reload() {
start-stop-daemon -K --signal HUP --quiet --pidfile $PIDFILE --name
$NAME
return 0
}
+
+do_status() {
+NAME=$1
+PIDFILE=$2
+# -t: test only but not stop
+start-stop-daemon -K -t --quiet --pidfile $PIDFILE --name $NAME
+# exit with status 0 if process is found
+if [ "$?" = "0" ]; then
+return 0
+else
+return 1
+fi
+}
+
case "$1" in
start)
echo -n "starting $RSYSLOGD ... "
@@ -82,8 +100,19 @@ case "$1" in
$0 stop
$0 start
;;
+ status)
+echo -n "status $RSYSLOGD ... "
+do_status "$RSYSLOGD" "$RSYSLOGD_PIDFILE"
+if [ "$?" = "0" ]; then
+echo "running"
+exit 0
+else
+echo "stopped"
+exit 1
+fi
+;;
*)
-echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
+echo "Usage: $SCRIPTNAME
{start|stop|status|restart|reload|force-reload}" >&2
exit 3
;;
esac
--
1.7.9.5
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] rsyslog: add status command and minor fixes for initscript
On 16/04/14 10:31, jackie.hu...@windriver.com wrote:
> From: Jackie Huang
>
> - add status command
> - remove the unsupported option:
> rsyslogd: error: option -c is no longer supported - ignored
> - add --oknodo for do_start
>
> Signed-off-by: Jackie Huang
> ---
> .../recipes-extended/rsyslog/rsyslog/initscript| 35
> ++--
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> index 8dee684..4121434 100644
> --- a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> +++ b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> @@ -9,7 +9,8 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin
> NAME=rsyslog
> RSYSLOGD=rsyslogd
> RSYSLOGD_BIN=/usr/sbin/rsyslogd
> -RSYSLOGD_OPTIONS="-c5"
> +# with rsyslog 7, -c is no longer supported
> +RSYSLOGD_OPTIONS=""
> RSYSLOGD_PIDFILE=/var/run/rsyslogd.pid
> SCRIPTNAME=/etc/init.d/$NAME
> # Exit if the package is not installed
> @@ -27,7 +28,10 @@ do_start()
> # Return
> # 0 if daemon has been started
> # 1 if daemon could not be started
> -start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON --
> $DAEMON_ARGS || return 1
> +# if daemon had already been started, start-stop-daemon will
> return 1
> +# so add -o/--oknodo(if nothing is done, exit 0)
> +start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON \
> + --oknodo -- $DAEMON_ARGS || return 1
> }
> #
> # Function that stops the daemon/service
> @@ -56,6 +60,20 @@ do_reload() {
> start-stop-daemon -K --signal HUP --quiet --pidfile $PIDFILE --name
> $NAME
> return 0
> }
> +
> +do_status() {
> +NAME=$1
> +PIDFILE=$2
> +# -t: test only but not stop
> +start-stop-daemon -K -t --quiet --pidfile $PIDFILE --name $NAME
> +# exit with status 0 if process is found
> +if [ "$?" = "0" ]; then
> +return 0
> +else
> +return 1
> +fi
> +}
> +
> case "$1" in
>start)
> echo -n "starting $RSYSLOGD ... "
> @@ -82,8 +100,19 @@ case "$1" in
> $0 stop
> $0 start
> ;;
> + status)
> +echo -n "status $RSYSLOGD ... "
> +do_status "$RSYSLOGD" "$RSYSLOGD_PIDFILE"
> +if [ "$?" = "0" ]; then
> +echo "running"
> +exit 0
> +else
> +echo "stopped"
> +exit 1
> +fi
> +;;
>*)
> -echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}"
> >&2
> +echo "Usage: $SCRIPTNAME
> {start|stop|status|restart|reload|force-reload}" >&2
> exit 3
> ;;
> esac
>
Hi Jackie,
I have a patch pending that fixes the rsyslog unsupported option. I
don't know if you want to take that and re-spin a v2 otherwise the patch
will probably fail to apply.
Cheers,
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
Cambridgeshire, UK
http://www.embed.me.uk
--
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rrdtool: enable libwrap, perl and python bindings
On Wednesday 16 April 2014 09:15:47 Koen Kooi wrote: > Chong Lu schreef op 16-04-14 08:51: > > 1. default enable libwrap, perl and python bindings > > A number of big distros are moving away from tcpwrappers, Arch has removed > it years ago and fedora looked into it a while ago. Since tcpwrappers hasn't > seen a release (or development) in years I think we should default it to > off. Chris added a tcp-wrappers PACKAGECONFIG to a number of recipes about a year ago; I wonder if we ought to promote it to a DISTRO_FEATURES item and if appropriate just not enable that by default. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rrdtool: enable libwrap, perl and python bindings
Op 16 apr. 2014, om 12:02 heeft Paul Eggleton het volgende geschreven: > On Wednesday 16 April 2014 09:15:47 Koen Kooi wrote: >> Chong Lu schreef op 16-04-14 08:51: >>> 1. default enable libwrap, perl and python bindings >> >> A number of big distros are moving away from tcpwrappers, Arch has removed >> it years ago and fedora looked into it a while ago. Since tcpwrappers hasn't >> seen a release (or development) in years I think we should default it to >> off. > > Chris added a tcp-wrappers PACKAGECONFIG to a number of recipes about a year > ago; I wonder if we ought to promote it to a DISTRO_FEATURES item and if > appropriate just not enable that by default. I think that makes the most sense in this situation. regards, Koen -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
On 04/16/2014 02:49 AM, Journeyer J. Joh wrote: > Hello, > > First of all I thank Nicolas Dechesne and Brian Hutchinson, for the > previous kind replies. > > While I was reading documents from Yocto Project, I found my source code in > use in my company is of Open Embedded for MSM. > > I found this from the git remote url of my surce code. It is > git://codeaurora.org/quic/le/openembedded/openembedded-core > > And the one of Yocto project is > git://git.yoctoproject.org/poky > >>From the git log prints poky is actively developped now but > openembedded-core is not. > > In a nutshell(I learned this expression today^^), > - What is the relationship between those two? Any differences? Commons? > - Can I refer to the documents about poky for my openembedded-core? OpenEmbedded is the build system and has been actively developed since 2004 or so (give or take a few years) Poky is the reference distribution from the Yocto Project. The Yocto Project is working to make embedded development easier. You should check the OpenEmbedded git server for activity; http://cgit.openembedded.org/openembedded-core/ I'm guessing (without looking) the codeaurora git is based of a release bench. Philip > > Thank you very much in advance. > > Sincerely > Journeyer > > > Journeyer J. Joh > o o s a p r o g r a m m e r > a t > g m a i l d o t c o m > > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
Hi, Samuel Stirtzel, Khem Raj and Philip Balister, Thank you for the kind answers!! I understood what are those. > - What is the relationship between those two? Any differences? Commons? OE for MSM is one instance of Yocto Project - OE-core. And It's like Poky - An reference instance of Yocto Project. > - Can I refer to the documents about poky for my openembedded-core? I think I can refer to the poky's documentations but must make sure that poky and OE for MSM are siblings from the same framework - Yocto Prooject - OE-core Thank you very much for the kindness!! Sincerely Journeyer Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m 2014-04-16 21:02 GMT+09:00 Philip Balister : > On 04/16/2014 02:49 AM, Journeyer J. Joh wrote: > > Hello, > > > > First of all I thank Nicolas Dechesne and Brian Hutchinson, for the > > previous kind replies. > > > > While I was reading documents from Yocto Project, I found my source code > in > > use in my company is of Open Embedded for MSM. > > > > I found this from the git remote url of my surce code. It is > > git://codeaurora.org/quic/le/openembedded/openembedded-core > > > > And the one of Yocto project is > > git://git.yoctoproject.org/poky > > > >>From the git log prints poky is actively developped now but > > openembedded-core is not. > > > > In a nutshell(I learned this expression today^^), > > - What is the relationship between those two? Any differences? Commons? > > - Can I refer to the documents about poky for my openembedded-core? > > OpenEmbedded is the build system and has been actively developed since > 2004 or so (give or take a few years) > > Poky is the reference distribution from the Yocto Project. > > The Yocto Project is working to make embedded development easier. > > You should check the OpenEmbedded git server for activity; > > http://cgit.openembedded.org/openembedded-core/ > > I'm guessing (without looking) the codeaurora git is based of a release > bench. > > Philip > > > > > Thank you very much in advance. > > > > Sincerely > > Journeyer > > > > > > Journeyer J. Joh > > o o s a p r o g r a m m e r > > a t > > g m a i l d o t c o m > > > > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] How can I get the toolchain?
Hi Changhyeok Bae, I raised similar questions and received good pointers and explanations: http://thread.gmane.org/gmane.comp.handhelds.openembedded Find the QnA titled with: [oe] Where can I get a arm cross toolchain for oe-core? I only able to give you pointers to answers I received. Good luck! Sincerely Journeyer Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m 2014-04-16 17:02 GMT+09:00 Khem Raj : > On Wed, Apr 16, 2014 at 12:07 AM, Changhyeok Bae > wrote: > > Hi, > > > > How can I extract the toolchain in my oe build result? > > > > bitbake -cpopulate_sdk > should generate a self-installer .sh script which then you can run and > install it > > > Regards, > > Changhyeok > > > > -- > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
I don't know what "OE for MSM" is, that you keep referring, probably your company's product based on OE. OE stands for OpenEmbedded and is the underlying technology for the Yocto Project and other things around it... I would recommend you to talk to someone from your company who's more familiar with the code base that you are trying to look at and how it is derived and/or relates to OpenEmbedded and the Yocto Project. -- Denys On Wed, Apr 16, 2014 at 09:37:49PM +0900, Journeyer J. Joh wrote: > Hi, Samuel Stirtzel, Khem Raj and Philip Balister, > > Thank you for the kind answers!! > > I understood what are those. > > > - What is the relationship between those two? Any differences? Commons? > OE for MSM is one instance of Yocto Project - OE-core. And It's like Poky - > An reference instance of Yocto Project. > > > - Can I refer to the documents about poky for my openembedded-core? > I think I can refer to the poky's documentations but must make sure that > poky and OE for MSM are siblings from the same framework - Yocto Prooject - > OE-core > > Thank you very much for the kindness!! > > Sincerely > Journeyer > > > Journeyer J. Joh > o o s a p r o g r a m m e r > a t > g m a i l d o t c o m > > > > 2014-04-16 21:02 GMT+09:00 Philip Balister : > > > On 04/16/2014 02:49 AM, Journeyer J. Joh wrote: > > > Hello, > > > > > > First of all I thank Nicolas Dechesne and Brian Hutchinson, for the > > > previous kind replies. > > > > > > While I was reading documents from Yocto Project, I found my source code > > in > > > use in my company is of Open Embedded for MSM. > > > > > > I found this from the git remote url of my surce code. It is > > > git://codeaurora.org/quic/le/openembedded/openembedded-core > > > > > > And the one of Yocto project is > > > git://git.yoctoproject.org/poky > > > > > >>From the git log prints poky is actively developped now but > > > openembedded-core is not. > > > > > > In a nutshell(I learned this expression today^^), > > > - What is the relationship between those two? Any differences? Commons? > > > - Can I refer to the documents about poky for my openembedded-core? > > > > OpenEmbedded is the build system and has been actively developed since > > 2004 or so (give or take a few years) > > > > Poky is the reference distribution from the Yocto Project. > > > > The Yocto Project is working to make embedded development easier. > > > > You should check the OpenEmbedded git server for activity; > > > > http://cgit.openembedded.org/openembedded-core/ > > > > I'm guessing (without looking) the codeaurora git is based of a release > > bench. > > > > Philip > > > > > > > > Thank you very much in advance. > > > > > > Sincerely > > > Journeyer > > > > > > > > > Journeyer J. Joh > > > o o s a p r o g r a m m e r > > > a t > > > g m a i l d o t c o m > > > > > > > > -- > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
On Wed, Apr 16, 2014 at 2:02 PM, Philip Balister wrote: >> >> I found this from the git remote url of my surce code. It is >> git://codeaurora.org/quic/le/openembedded/openembedded-core >> this tree is just a fork of oe-core (upstream) which is stuck at a 2-year old commit. if this is what you are calling "OE for MSM" well then it's just a 2-year old OE. You might be calling that "for MSM" because it comes from QCOM Code Aurora git tree.. but there is no vendor change in [1] [1] https://www.codeaurora.org/cgit/quic/le/openembedded/openembedded-core/ -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rrdtool: enable libwrap, perl and python bindings
On Wed, Apr 16, 2014 at 3:40 AM, Koen Kooi wrote: > Op 16 apr. 2014, om 12:02 heeft Paul Eggleton < > paul.eggle...@linux.intel.com> het volgende geschreven: > > > On Wednesday 16 April 2014 09:15:47 Koen Kooi wrote: > >> Chong Lu schreef op 16-04-14 08:51: > >>> 1. default enable libwrap, perl and python bindings > >> > >> A number of big distros are moving away from tcpwrappers, Arch has > removed > >> it years ago and fedora looked into it a while ago. Since tcpwrappershasn't > >> seen a release (or development) in years I think we should default it to > >> off. > > > > Chris added a tcp-wrappers PACKAGECONFIG to a number of recipes about a > year > > ago; I wonder if we ought to promote it to a DISTRO_FEATURES item and if > > appropriate just not enable that by default. > > I think that makes the most sense in this situation. > Agreed, I'd be all for that. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] bitlbee: add bitlbee-3.2.1
From: Krzysztof Sywula
Signed-off-by: Krzysztof Sywula
---
.../recipes-connectivity/bitlbee/bitlbee_3.2.1.bb | 61 ++
.../recipes-connectivity/bitlbee/files/init-script | 31 +++
2 files changed, 92 insertions(+)
create mode 100644 meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
create mode 100644 meta-oe/recipes-connectivity/bitlbee/files/init-script
diff --git a/meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
b/meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
new file mode 100644
index 000..449e6a0
--- /dev/null
+++ b/meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
@@ -0,0 +1,61 @@
+SUMMARY = "Bitlbee is an IRC to IM gateway that support multiple IM protocols."
+HOMEPAGE = "http://www.bitlbee.org/";
+SECTION = "console/network"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+DEPENDS = "glib-2.0 openssl"
+
+SRC_URI = "http://get.bitlbee.org/src/${P}.tar.gz \
+ file://init-script"
+
+SRC_URI[md5sum] = "6ee7c7a99eb59dfcf0307fcf44c14105"
+SRC_URI[sha256sum] =
"00f411dd7d6d28f30f0e73e46c9cbe88b4006e7f03adfe07b90a97280a290f59"
+
+S = "${WORKDIR}/bitlbee-${PV}"
+
+EXTRA_OECONF = "--prefix=/usr \
+--datadir=/usr/share/bitlbee \
+--etcdir=/etc/bitlbee \
+--oscar=0 \
+--ssl=openssl"
+
+do_configure () {
+# NOTE: bitlbee's configure script is not an autotool creation,
+# so we do not use the default autotools_do_configure.
+./configure ${EXTRA_OECONF} || die "./configure failed"
+}
+
+do_compile () {
+make CC="${CC}" LD="${LD}" || die "make failed"
+
+# make bitlbeed forking server
+cd ${S}/utils
+${CC} bitlbeed.c -o bitlbeed || die "bitlbeed failed to compile"
+}
+
+do_install () {
+# install bitlbee
+install -d ${D}${localstatedir}/lib/bitlbee
+make install DESTDIR=${D} || die "install failed"
+make install-etc DESTDIR=${D} || die "install failed"
+
+# copy bitlbee forking server
+install ${S}/utils/bitlbeed ${D}${sbindir}/bitlbeed
+
+# copy init script
+install -d ${D}${sysconfdir}/init.d
+install ${WORKDIR}/init-script ${D}${sysconfdir}/init.d/bitlbee
+sed -i -e "s:BITLBEED_EXEC:${sbindir}/bitlbeed:"
${D}${sysconfdir}/init.d/bitlbee
+sed -i -e "s:BITLBEED_OPTS::" ${D}${sysconfdir}/init.d/bitlbee
+
+# copy bitlbee utils
+install -d ${D}${datadir}/bitlbee
+cp ${S}/utils/* ${D}${datadir}/bitlbee/
+rm ${D}${datadir}/bitlbee/bitlbeed*
+}
+
+pkg_postinst_${PN} () {
+chown nobody:nogroup ${localstatedir}/lib/bitlbee
+chmod 700 ${localstatedir}/lib/bitlbee
+}
diff --git a/meta-oe/recipes-connectivity/bitlbee/files/init-script
b/meta-oe/recipes-connectivity/bitlbee/files/init-script
new file mode 100644
index 000..3ec3fdf
--- /dev/null
+++ b/meta-oe/recipes-connectivity/bitlbee/files/init-script
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+case "$1" in
+start)
+ echo "Starting bitlbee daemon"
+ start-stop-daemon --start --startas BITLBEED_EXEC \
+ -c nobody:nogroup --exec BITLBEED_EXEC -- \
+ BITLBEED_OPTS /usr/sbin/bitlbee
+ [ $? -eq 0 ] || echo $? "Failed to start bitlbee daemon"
+;;
+
+stop)
+echo "Stopping bitlbee daemon"
+ start-stop-daemon --stop --signal 9 \
+--exec BITLBEED_EXEC
+ [ $? -eq 0 ] || echo $? "Failed to stop bitlbee daemon"
+;;
+
+restart)
+ $0 stop
+ sleep 1
+ $0 start
+;;
+
+*)
+echo "usage: $0 { start | stop }"
+ exit 1
+;;
+esac
+
+exit 0
--
1.8.2
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] bitlbee: add bitlbee-3.2.1
On Wed, Apr 16, 2014 at 07:11:12PM +0100, krzysztof.m.syw...@intel.com wrote:
> From: Krzysztof Sywula
>
> Signed-off-by: Krzysztof Sywula
> ---
> .../recipes-connectivity/bitlbee/bitlbee_3.2.1.bb | 61
> ++
> .../recipes-connectivity/bitlbee/files/init-script | 31 +++
> 2 files changed, 92 insertions(+)
> create mode 100644 meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
> create mode 100644 meta-oe/recipes-connectivity/bitlbee/files/init-script
>
> diff --git a/meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
> b/meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
> new file mode 100644
> index 000..449e6a0
> --- /dev/null
> +++ b/meta-oe/recipes-connectivity/bitlbee/bitlbee_3.2.1.bb
> @@ -0,0 +1,61 @@
> +SUMMARY = "Bitlbee is an IRC to IM gateway that support multiple IM
> protocols."
> +HOMEPAGE = "http://www.bitlbee.org/";
> +SECTION = "console/network"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
> +
> +DEPENDS = "glib-2.0 openssl"
> +
> +SRC_URI = "http://get.bitlbee.org/src/${P}.tar.gz \
> + file://init-script"
> +
> +SRC_URI[md5sum] = "6ee7c7a99eb59dfcf0307fcf44c14105"
> +SRC_URI[sha256sum] =
> "00f411dd7d6d28f30f0e73e46c9cbe88b4006e7f03adfe07b90a97280a290f59"
> +
> +S = "${WORKDIR}/bitlbee-${PV}"
This looks like default value, isn't it?
> +EXTRA_OECONF = "--prefix=/usr \
> +--datadir=/usr/share/bitlbee \
> +--etcdir=/etc/bitlbee \
> +--oscar=0 \
> +--ssl=openssl"
> +
> +do_configure () {
> +# NOTE: bitlbee's configure script is not an autotool creation,
> +# so we do not use the default autotools_do_configure.
This recipe doesn't inherit autotools, so there is no "default
autotools_do_configure" afaik.
> +./configure ${EXTRA_OECONF} || die "./configure failed"
> +}
> +
> +do_compile () {
> +make CC="${CC}" LD="${LD}" || die "make failed"
Can you use oe_runmake to respect EXTRA_OEMAKE, especially PARALLEL_MAKE?
> +# make bitlbeed forking server
> +cd ${S}/utils
> +${CC} bitlbeed.c -o bitlbeed || die "bitlbeed failed to compile"
> +}
> +
> +do_install () {
> +# install bitlbee
> +install -d ${D}${localstatedir}/lib/bitlbee
> +make install DESTDIR=${D} || die "install failed"
> +make install-etc DESTDIR=${D} || die "install failed"
Can you use oe_runmake to respect EXTRA_OEMAKE, especially PARALLEL_MAKE?
> +
> +# copy bitlbee forking server
> +install ${S}/utils/bitlbeed ${D}${sbindir}/bitlbeed
> +
> +# copy init script
> +install -d ${D}${sysconfdir}/init.d
> +install ${WORKDIR}/init-script ${D}${sysconfdir}/init.d/bitlbee
> +sed -i -e "s:BITLBEED_EXEC:${sbindir}/bitlbeed:"
> ${D}${sysconfdir}/init.d/bitlbee
> +sed -i -e "s:BITLBEED_OPTS::" ${D}${sysconfdir}/init.d/bitlbee
> +
> +# copy bitlbee utils
> +install -d ${D}${datadir}/bitlbee
> +cp ${S}/utils/* ${D}${datadir}/bitlbee/
> +rm ${D}${datadir}/bitlbee/bitlbeed*
> +}
> +
> +pkg_postinst_${PN} () {
> +chown nobody:nogroup ${localstatedir}/lib/bitlbee
> +chmod 700 ${localstatedir}/lib/bitlbee
> +}
> diff --git a/meta-oe/recipes-connectivity/bitlbee/files/init-script
> b/meta-oe/recipes-connectivity/bitlbee/files/init-script
> new file mode 100644
> index 000..3ec3fdf
> --- /dev/null
> +++ b/meta-oe/recipes-connectivity/bitlbee/files/init-script
> @@ -0,0 +1,31 @@
> +#!/bin/sh
please add LSB headers
> +
> +case "$1" in
> +start)
> + echo "Starting bitlbee daemon"
> + start-stop-daemon --start --startas BITLBEED_EXEC \
> + -c nobody:nogroup --exec BITLBEED_EXEC -- \
> + BITLBEED_OPTS /usr/sbin/bitlbee
> + [ $? -eq 0 ] || echo $? "Failed to start bitlbee daemon"
> +;;
> +
> +stop)
> +echo "Stopping bitlbee daemon"
> + start-stop-daemon --stop --signal 9 \
> + --exec BITLBEED_EXEC
> + [ $? -eq 0 ] || echo $? "Failed to stop bitlbee daemon"
> +;;
> +
> +restart)
> + $0 stop
> + sleep 1
> + $0 start
> +;;
> +
> +*)
> +echo "usage: $0 { start | stop }"
> + exit 1
> +;;
> +esac
> +
> +exit 0
> --
> 1.8.2
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] bitlbee: add bitlbee-3.2.1
On Wed, Apr 16, 2014 at 11:11 AM, wrote: > +EXTRA_OECONF = "--prefix=/usr \ > +--datadir=/usr/share/bitlbee \ > +--etcdir=/etc/bitlbee \ > +--oscar=0 \ > +--ssl=openssl" should these be hardcoded ? -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
Hi Denys Dmytriyenko, I would recommend you to talk to someone from your company who's more > familiar > with the code base that you are trying to look at and how it is derived > and/or > relates to OpenEmbedded and the Yocto Project. This is what exactly I am sorry for.. I, in my team, the only one who works with linux. There are people who works with linux but, until now, I cannot meet them easily. I feel mail-list more kindly than them.. And I am new to this company... Telling this story doesn't look fit to the purpose of this maillist but, this is just my story.. And this is the reason why I thank you for your kindness.. But I agree I should try to talk with people in my company. I don't know what "OE for MSM" is, that you keep referring, probably your company's > product based on OE. I think this might be the OE for MSM: https://www.codeaurora.org/xwiki/bin/QLBEP/WebHome Thank you ... Sincerely Journeyer Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m 2014-04-16 23:42 GMT+09:00 Nicolas Dechesne : > On Wed, Apr 16, 2014 at 2:02 PM, Philip Balister > wrote: > >> > >> I found this from the git remote url of my surce code. It is > >> git://codeaurora.org/quic/le/openembedded/openembedded-core > >> > > this tree is just a fork of oe-core (upstream) which is stuck at a > 2-year old commit. if this is what you are calling "OE for MSM" well > then it's just a 2-year old OE. You might be calling that "for MSM" > because it comes from QCOM Code Aurora git tree.. but there is no > vendor change in [1] > > [1] > https://www.codeaurora.org/cgit/quic/le/openembedded/openembedded-core/ > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] What is the relationship between Open Embedded for MSM and Yocto Project?
On Wed, Apr 16, 2014 at 7:51 PM, Journeyer J. Joh wrote: > Hi Denys Dmytriyenko, > > I would recommend you to talk to someone from your company who's more > > familiar > > with the code base that you are trying to look at and how it is derived > > and/or > > relates to OpenEmbedded and the Yocto Project. > > > This is what exactly I am sorry for.. > I, in my team, the only one who works with linux. > There are people who works with linux but, until now, I cannot meet them > easily. I feel mail-list more kindly than them.. > And I am new to this company... > Telling this story doesn't look fit to the purpose of this maillist but, > this is just my story.. > > And this is the reason why I thank you for your kindness.. > But I agree I should try to talk with people in my company. > > I don't know what "OE for MSM" is, that you keep referring, probably > your company's > > product based on OE. > > > I think this might be the OE for MSM: > > https://www.codeaurora.org/xwiki/bin/QLBEP/WebHome > > Thank you ... > Sincerely > Journeyer > > > > Hi Journeyer, After paying more attention to the platform you are using ... I'm doubtful that the sdk instructions we mentioned to you before will actually work for you especially seeing that the snapshot of OE at the links you provided are 2011/2012 vintage. You may want to investigate the older bitbake meta-toolchain recipes (meta-toolchain-sdk too). So if the sdk instructions don't work, but you need to work with the latest OE/Yocto releases ... you may have to do things like I've had to do in the past for some platforms that aren't directly supported by OE, Yocto etc. I've had to use the kernel/u-boot that came from the silicon vendor (never mainlined and probably never will and are frozen in time) and I build u-boot and kernel source from vendor outside of bitbake (standalone). You can use the toolchain that is probably provided with the MDM and setup OE or Yocto to use that toolchain as an external toolchain to build current released filesystem images and packages. This way you have new applications in the rootfs but may be stuck (if it isn't mainlined) with old kernel. Your mileage will vary if you decide to go down this road as there can be land mines ... It is always best to keep toolchain, kernel, and root filesystem moving forward (not necessarily using the latest but not lagging too far behind it) and not let one of them get pinned being static but some times you don't have much of a choice (I've been there). Sometimes when you try to build new filesystem images with old toolchains you run into problems. Building old kernels with new toolchains also causes problems. So if you are like me and have a product that needs new kernels and filesystem images to keep up with security threats etc., ... you're going to have a hard life for a while (ask me how I know). You can also study the platform specific differences between what codeaurora (the working example that supports your platform) provided and what the latest releases of OE/yocto provide and make new recipies and bsp's in the latest releases of OE or Yocto to support your platform which is the right thing to do ... but requires the most knowledge of the build system to do. I hope I'm not confusing you ... just trying to give you ideas of what options you have so you can best pick a solution that fits with what you are trying to do. You may have to pick a less than ideal solution to start with and as you learn more move toward adding platform/BSP support for your hardware to the latest version of OE, Yocto etc. Regards, Brian -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] How can I get the toolchain?
Thanks for your help. In summary, 1) bitbake meta-toolchain 2) bitbake [target] -c populate_sdk ... However, those were building ...nativesdk ... I only would like to get the cross(arm) toolchain without building SDK toolchain. Regards, Changhyeok -Original Message- From: openembedded-devel-boun...@lists.openembedded.org [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of Journeyer J. Joh Sent: Wednesday, April 16, 2014 9:57 PM To: openembedded-devel@lists.openembedded.org Subject: Re: [oe] How can I get the toolchain? Hi Changhyeok Bae, I raised similar questions and received good pointers and explanations: http://thread.gmane.org/gmane.comp.handhelds.openembedded Find the QnA titled with: [oe] Where can I get a arm cross toolchain for oe-core? I only able to give you pointers to answers I received. Good luck! Sincerely Journeyer Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m 2014-04-16 17:02 GMT+09:00 Khem Raj : > On Wed, Apr 16, 2014 at 12:07 AM, Changhyeok Bae > > wrote: > > Hi, > > > > How can I extract the toolchain in my oe build result? > > > > bitbake -cpopulate_sdk > should generate a self-installer .sh script which then you can run and > install it > > > Regards, > > Changhyeok > > > > -- > > ___ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] How can I get the toolchain?
On Wed, Apr 16, 2014 at 9:33 PM, Changhyeok Bae wrote: > Thanks for your help. > > In summary, > 1) bitbake meta-toolchain > 2) bitbake [target] -c populate_sdk ... > > However, those were building ...nativesdk ... > I only would like to get the cross(arm) toolchain without building SDK > toolchain. > > Regards, > Changhyeok > > ... those do build the cross sdk/toolchain. You take the huge script that is generated and install it on your PC, source the environment setup script and now you are setup to cross compile on your host for the target. Regards, Brian -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] How can I get the toolchain?
On Wed, Apr 16, 2014 at 9:42 PM, Brian Hutchinson wrote: > On Wed, Apr 16, 2014 at 9:33 PM, Changhyeok Bae wrote: > >> Thanks for your help. >> >> In summary, >> 1) bitbake meta-toolchain >> 2) bitbake [target] -c populate_sdk ... >> >> However, those were building ...nativesdk ... >> I only would like to get the cross(arm) toolchain without building SDK >> toolchain. >> >> Regards, >> Changhyeok >> >> > ... those do build the cross sdk/toolchain. You take the huge script that > is generated and install it on your PC, source the environment setup script > and now you are setup to cross compile on your host for the target. > > Regards, > > Brian > > ... in your local.conf, you do have to set SDKMACHINE to something. I have to build toolchains that work on both 32 bit & 64 bit hosts so usually do a build with: SDKMACHINE ?= "x86_64" ... then do another build of sdk with: SDKMACHINE ?= "i686" -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH] rsyslog: add status command and minor fixes for initscript
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-
> boun...@lists.openembedded.org] On Behalf Of Jack Mitchell
> Sent: Wednesday, April 16, 2014 5:46 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [meta-oe][PATCH] rsyslog: add status command and minor
> fixes for initscript
>
> On 16/04/14 10:31, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang
> >
> > - add status command
> > - remove the unsupported option:
> > rsyslogd: error: option -c is no longer supported - ignored
> > - add --oknodo for do_start
> >
> > Signed-off-by: Jackie Huang
> > ---
> > .../recipes-extended/rsyslog/rsyslog/initscript| 35
> > ++--
> > 1 file changed, 32 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> > b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> > index 8dee684..4121434 100644
> > --- a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> > +++ b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
> > @@ -9,7 +9,8 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin
> > NAME=rsyslog
> > RSYSLOGD=rsyslogd
> > RSYSLOGD_BIN=/usr/sbin/rsyslogd
> > -RSYSLOGD_OPTIONS="-c5"
> > +# with rsyslog 7, -c is no longer supported RSYSLOGD_OPTIONS=""
> > RSYSLOGD_PIDFILE=/var/run/rsyslogd.pid
> > SCRIPTNAME=/etc/init.d/$NAME
> > # Exit if the package is not installed @@ -27,7 +28,10 @@ do_start()
> > # Return
> > # 0 if daemon has been started
> > # 1 if daemon could not be started
> > -start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON --
> > $DAEMON_ARGS || return
> 1
> > +# if daemon had already been started, start-stop-daemon will
> > return 1
> > +# so add -o/--oknodo(if nothing is done, exit 0)
> > +start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON \
> > + --oknodo -- $DAEMON_ARGS || return 1
> > }
> > #
> > # Function that stops the daemon/service @@ -56,6 +60,20 @@
> > do_reload() {
> > start-stop-daemon -K --signal HUP --quiet --pidfile $PIDFILE
> > --name $NAME
> > return 0
> > }
> > +
> > +do_status() {
> > +NAME=$1
> > +PIDFILE=$2
> > +# -t: test only but not stop
> > +start-stop-daemon -K -t --quiet --pidfile $PIDFILE --name $NAME
> > +# exit with status 0 if process is found
> > +if [ "$?" = "0" ]; then
> > +return 0
> > +else
> > +return 1
> > +fi
> > +}
> > +
> > case "$1" in
> >start)
> > echo -n "starting $RSYSLOGD ... "
> > @@ -82,8 +100,19 @@ case "$1" in
> > $0 stop
> > $0 start
> > ;;
> > + status)
> > +echo -n "status $RSYSLOGD ... "
> > +do_status "$RSYSLOGD" "$RSYSLOGD_PIDFILE"
> > +if [ "$?" = "0" ]; then
> > +echo "running"
> > +exit 0
> > +else
> > +echo "stopped"
> > +exit 1
> > +fi
> > +;;
> >*)
> > -echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}"
> > >&2
> > +echo "Usage: $SCRIPTNAME
> > + {start|stop|status|restart|reload|force-reload}" >&2
> > exit 3
> > ;;
> > esac
> >
>
>
> Hi Jackie,
>
> I have a patch pending that fixes the rsyslog unsupported option. I don't
> know if you want to take that
> and re-spin a v2 otherwise the patch will probably fail to apply.
Sorry I didn't notice that, I will take that and re-spin a v2.
Thanks,
Jackie
>
> Cheers,
>
> --
> Jack Mitchell (j...@embed.me.uk)
> Embedded Systems Engineer
> Cambridgeshire, UK
> http://www.embed.me.uk
> --
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH v2] rsyslog: add status command and a minor fix for initscript
From: Jackie Huang
- add status command
- add --oknodo for do_start
Signed-off-by: Jackie Huang
---
.../recipes-extended/rsyslog/rsyslog/initscript| 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
index d011e8f..7a8f8f9 100644
--- a/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
+++ b/meta-oe/recipes-extended/rsyslog/rsyslog/initscript
@@ -27,7 +27,10 @@ do_start()
# Return
# 0 if daemon has been started
# 1 if daemon could not be started
-start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON --
$DAEMON_ARGS || return 1
+# if daemon had already been started, start-stop-daemon will return 1
+# so add -o/--oknodo(if nothing is done, exit 0)
+start-stop-daemon -S --quiet --pidfile $PIDFILE --exec $DAEMON \
+ --oknodo -- $DAEMON_ARGS || return 1
}
#
# Function that stops the daemon/service
@@ -56,6 +59,20 @@ do_reload() {
start-stop-daemon -K --signal HUP --quiet --pidfile $PIDFILE --name
$NAME
return 0
}
+
+do_status() {
+NAME=$1
+PIDFILE=$2
+# -t: test only but not stop
+start-stop-daemon -K -t --quiet --pidfile $PIDFILE --name $NAME
+# exit with status 0 if process is found
+if [ "$?" = "0" ]; then
+return 0
+else
+return 1
+fi
+}
+
case "$1" in
start)
echo -n "starting $RSYSLOGD ... "
@@ -82,8 +99,19 @@ case "$1" in
$0 stop
$0 start
;;
+ status)
+echo -n "status $RSYSLOGD ... "
+do_status "$RSYSLOGD" "$RSYSLOGD_PIDFILE"
+if [ "$?" = "0" ]; then
+echo "running"
+exit 0
+else
+echo "stopped"
+exit 1
+fi
+;;
*)
-echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
+echo "Usage: $SCRIPTNAME
{start|stop|status|restart|reload|force-reload}" >&2
exit 3
;;
esac
--
1.7.9.5
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-networking][PATCH ] sethdlc: don't search host directories for header files
From: Chunrong Guo
*The build process hard-codes searches of various directories
in /usr/src/linux/include when looking for header files,
delete this to avoid host contamination
Signed-off-by: Chunrong Guo
---
.../sethdlc/files/fix-includedir.patch| 15 +++
meta-networking/recipes-connectivity/sethdlc/sethdlc.bb | 11 +++
2 files changed, 18 insertions(+), 8 deletions(-)
create mode 100644
meta-networking/recipes-connectivity/sethdlc/files/fix-includedir.patch
diff --git
a/meta-networking/recipes-connectivity/sethdlc/files/fix-includedir.patch
b/meta-networking/recipes-connectivity/sethdlc/files/fix-includedir.patch
new file mode 100644
index 000..49d6d42
--- /dev/null
+++ b/meta-networking/recipes-connectivity/sethdlc/files/fix-includedir.patch
@@ -0,0 +1,15 @@
+--- a/Makefileold 2014-04-16 22:05:58.070199084 -0500
b/Makefile 2014-04-16 22:06:27.153074058 -0500
+@@ -1,11 +1,10 @@
+ CC = gcc
+ CFLAGS = -O2 -Wall -W -Wno-long-long -pipe
+-INCLUDES = -I/usr/src/linux/include -I/usr/src/linux-2.6/include
+
+ all: sethdlc
+
+ sethdlc: sethdlc.c
+- $(CC) $(CFLAGS) $(INCLUDES) -o $@ $<
++ $(CC) $(CFLAGS) -o $@ $<
+
+ install:
+ install -C -p -s sethdlc /usr/local/sbin/
diff --git a/meta-networking/recipes-connectivity/sethdlc/sethdlc.bb
b/meta-networking/recipes-connectivity/sethdlc/sethdlc.bb
index 3a9692f..3459a36 100644
--- a/meta-networking/recipes-connectivity/sethdlc/sethdlc.bb
+++ b/meta-networking/recipes-connectivity/sethdlc/sethdlc.bb
@@ -1,27 +1,22 @@
DESCRIPTION = "set Linux HDLC packet radio modem driver port information"
HOMEPAGE = "https://www.kernel.org/pub/linux/utils/net/hdlc";
LICENSE = "GPLv2 & GPLv2+ "
-LIC_FILES_CHKSUM = "file://Makefile;md5=19aada31930b2be84bf7138420d77263"
-
+LIC_FILES_CHKSUM =
"file://sethdlc.c;beginline=1;endline=10;md5=90f936879e9f8b755a138aeb348782eb"
SRC_URI = "https://www.kernel.org/pub/linux/utils/net/hdlc/${BPN}-1.18.tar.gz \
+ file://fix-includedir.patch \
"
SRC_URI[md5sum] = "9016878156a5eadb06c0bae71cc5c9ab"
SRC_URI[sha256sum] =
"21b1e2e1cb0e288b0ec8fcfd9fed449914e0f8e6fc273706bd5b3d4f6ab6b04e"
-
S = "${WORKDIR}/${BPN}-1.18"
-DEPENDS="virtual/kernel"
-
-EXTRA_OEMAKE="CROSS_COMPILE=${TARGET_PREFIX} CC='${CC} ${LDFLAGS}' \
- KERNEL_DIR=${STAGING_KERNEL_DIR} "
+EXTRA_OEMAKE="CROSS_COMPILE=${TARGET_PREFIX} CC='${CC} ${LDFLAGS}'"
do_compile_prepend () {
oe_runmake clean
}
-
do_install() {
install -d ${D}/${bindir}
install sethdlc ${D}/${bindir}/
--
1.8.3.2
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
