Re: [OE-core] Fwd: Help: Can not install OpenEmbedded
Hi Giang, On 03.08.2015 10:42, Giang Nguyễn wrote: I am installing Openembedded but i got an error. When i tried to extract oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh http://oecore-x86_64-armv7a-vfp-neon-toolchain-oe-core.0.sh/ file, it is always produce the same warning like the picture below. Please show me what must i do or give me some advices. I'm expecting to hear back from you. Hope you have a nice day, sir. the error message is pretty clear: It looks like your downloaded file is corrupt. Try to download again... Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Future of Qt4 recipes
Hi, Am 22.06.2015 um 12:43 schrieb Burton, Ross: 1) There's still lots of people using Qt4 in production, please keep it in oe-core! (and revisit in six months time) I agree it is really widely used in production. I would leave it in as long as the situation stays like this and Qt4 is maintained. You know in my opinion we would be better with a little bit less fragmentation... Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi, On 20.05.2015 15:48, Florian Boor wrote: ok great... then I'll change it to dropping the dependency of the -dev package while I'm working on it anyway. hrm strange... somehow my new patch did not make it to the list. Anyone an idea if it ended up in some filter? Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] [RESEND] gtk-engines: Make gtk-engines-dev installable by dropping dependency to not generated gtk-engines package.
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 33b6afe..036aa27 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -29,6 +29,8 @@ FILES_${PN}-schemas = ${datadir}/gtk-engines/*.xml
CFLAGS_prepend = -DHAVE_ANIMATION
+RDEPENDS_${PN}-dev =
+
inherit gnomebase
python populate_packages_prepend() {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 33b6afe..9c52193 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1
SECTION = x11/base
DEPENDS = intltool-native gtk+
-PR = r3
+PR = r4
PACKAGES += ${PN}-schemas
PACKAGES_DYNAMIC += ^gtk-engine-.* ^gtk-theme-.*
@@ -29,6 +29,8 @@ FILES_${PN}-schemas = ${datadir}/gtk-engines/*.xml
CFLAGS_prepend = -DHAVE_ANIMATION
+ALLOW_EMPTY_${PN} = 1
+
inherit gnomebase
python populate_packages_prepend() {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi Ross, On 20.05.2015 15:08, Burton, Ross wrote: No need to bump PR. Personally I think that the fix here is to stop PN-dev depending on PN, instead of creating an empty PN package to confuse people. well, in this way it automatically fixes this issues with the -dev package which is not installable for every build where gtk-engines has been built already, so in my opinion this is a good reason to increment PR. Randomly laying around packages with broken dependencies have quite more potential to confuse people than incremented PR most users do not care about much. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi Otavio, On 20.05.2015 15:20, Otavio Salvador wrote: No. You should rely on PR Service for this. Drop the PR bump as it is pointless here. oh PR Service - if we can rely on it in this case I agree. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] gtk-engines: Make gtk-engines-dev installable by dropping dependency to not generated gtk-engines package.
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 33b6afe..036aa27 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -29,6 +29,8 @@ FILES_${PN}-schemas = ${datadir}/gtk-engines/*.xml
CFLAGS_prepend = -DHAVE_ANIMATION
+RDEPENDS_${PN}-dev =
+
inherit gnomebase
python populate_packages_prepend() {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk-engines: Allow gtk-engines package to be empty in order to make the -dev package installable.
Hi, On 20.05.2015 15:32, Burton, Ross wrote: If you care about upgrade paths then the PR service is far more reliable than explicit PR bumps. ok great... then I'll change it to dropping the dependency of the -dev package while I'm working on it anyway. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] directfb: Allow native builds of directfb 1.7.6
Hi Arndre, On 10.03.2015 23:32, Andre McCurdy wrote: Are you sure that excluding tslib-native from DEPENDS works? Since -lts is hardcoded in LDFLAGS (see directfb.inc) the linker won't run unless libts.so is found in sysroot (regardless of whether or not you configure with --with-inputdrivers=none). That being said, I don't know if -lts really needs to be hardcoded in LDFLAGS, it's been there since directfb was first imported into oe-core, with no explanation of comment. yes it works - tested it and made sure that there was no native libts around from a previous build. But you are right, this hardcoded -lts in LDFLAGS looks strange. I can take a look at this later since I need to build and test this anyway. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] directfb: Allow native builds of directfb 1.7.6
From: Florian Boor flor...@kernelconcepts.de Required by some DirectFB applications like dfbsee. Signed-off-by: Florian Boor flor...@kernelconcepts.de --- meta/recipes-graphics/directfb/directfb_1.7.6.bb | 14 ++ 1 file changed, 14 insertions(+) diff --git a/meta/recipes-graphics/directfb/directfb_1.7.6.bb b/meta/recipes-graphics/directfb/directfb_1.7.6.bb index d25d987..7acb7e6 100644 --- a/meta/recipes-graphics/directfb/directfb_1.7.6.bb +++ b/meta/recipes-graphics/directfb/directfb_1.7.6.bb @@ -19,3 +19,17 @@ LEAD_SONAME = libdirectfb-1.7.so.0 SRC_URI[md5sum] = 8a7bb06b3f58599b230b4cf314004512 SRC_URI[sha256sum] = 44f32bacfb842ea234599532f8481fe41b5bd2310d2bd101508eb3a5df26c9e1 + +BBCLASSEXTEND = native +DEPENDS_class-native = jpeg-native libpng-native +EXTRA_OECONF_class-native = \ + --enable-freetype=no \ + --disable-zlib \ + --with-gfxdrivers=none \ + --disable-sdl \ + --disable-vnc \ + --disable-x11 \ + --disable-imlib2 \ + --disable-mesa \ + --with-inputdrivers=none \ + -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] directfb: Allow native builds of directfb 1.7.6
Hi Ross, On 06.03.2015 12:46, Burton, Ross wrote: Presumably you have patches to enable those for native, or would it be best to disable them in the native case as presumably all you need are the tools? you are right, I have these as well but I used bbappend to get native support for these. I will take a look for the easiest solution and create a patch. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH] directfb: Allow native builds of directfb 1.7.6
From: Florian Boor flor...@kernelconcepts.de Required by some DirectFB applications like dfbsee. Signed-off-by: Florian Boor flor...@kernelconcepts.de --- meta/recipes-graphics/directfb/directfb_1.7.6.bb |2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-graphics/directfb/directfb_1.7.6.bb b/meta/recipes-graphics/directfb/directfb_1.7.6.bb index d25d987..2594b59 100644 --- a/meta/recipes-graphics/directfb/directfb_1.7.6.bb +++ b/meta/recipes-graphics/directfb/directfb_1.7.6.bb @@ -19,3 +19,5 @@ LEAD_SONAME = libdirectfb-1.7.so.0 SRC_URI[md5sum] = 8a7bb06b3f58599b230b4cf314004512 SRC_URI[sha256sum] = 44f32bacfb842ea234599532f8481fe41b5bd2310d2bd101508eb3a5df26c9e1 + +BBCLASSEXTEND = native -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-oe][PATCH] fltk: Replace use of freetype-config with pkg-config Drop blacklist entry
From: Florian Boor flor...@kernelconcepts.de
Tested building for MIPS 32bit QEMU
Signed-off-by: Florian Boor flor...@kernelconcepts.de
---
.../fltk/fltk-1.1.10/fltk-no-freetype-config.patch | 18 ++
meta-oe/recipes-support/fltk/fltk_1.1.10.bb |7 +++
2 files changed, 21 insertions(+), 4 deletions(-)
create mode 100644
meta-oe/recipes-support/fltk/fltk-1.1.10/fltk-no-freetype-config.patch
diff --git
a/meta-oe/recipes-support/fltk/fltk-1.1.10/fltk-no-freetype-config.patch
b/meta-oe/recipes-support/fltk/fltk-1.1.10/fltk-no-freetype-config.patch
new file mode 100644
index 000..5dbb054
--- /dev/null
+++ b/meta-oe/recipes-support/fltk/fltk-1.1.10/fltk-no-freetype-config.patch
@@ -0,0 +1,18 @@
+--- a/configure.in.orig2015-03-01 16:00:35.956432907 +0100
b/configure.in 2015-03-01 16:04:23.269580093 +0100
+@@ -865,11 +865,11 @@
+ AC_ARG_ENABLE(xft, [ --enable-xftturn on Xft support
[default=no]])
+
+ if test x$enable_xft = xyes; then
+-AC_PATH_PROG(FTCONFIG,freetype-config)
++AC_PATH_PROG(PKGCONFIG,pkg-config)
+
+- if test x$FTCONFIG != x; then
+- CPPFLAGS=`$FTCONFIG --cflags` $CPPFLAGS
+- CXXFLAGS=`$FTCONFIG --cflags` $CXXFLAGS
++ if test x$PKGCONFIG != x; then
++ CPPFLAGS=`$PKGCONFIG --cflags xft` $CPPFLAGS
++ CXXFLAGS=`$PKGCONFIG --cflags xft` $CXXFLAGS
+
+ AC_CHECK_HEADER(X11/Xft/Xft.h,
+ AC_CHECK_LIB(Xft, XftDrawCreate,
diff --git a/meta-oe/recipes-support/fltk/fltk_1.1.10.bb
b/meta-oe/recipes-support/fltk/fltk_1.1.10.bb
index 4fd3645..3229ed0 100644
--- a/meta-oe/recipes-support/fltk/fltk_1.1.10.bb
+++ b/meta-oe/recipes-support/fltk/fltk_1.1.10.bb
@@ -6,19 +6,18 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=1c0b73db66884b6a925e727400315130
DEPENDS = alsa-lib zlib jpeg libpng libxext libxft
-PR = r1
-
-PNBLACKLIST[fltk] ?= broken: still uses /usr/bin/freetype-config
+PR = r2
SRC_URI =
ftp://ftp.rz.tu-bs.de/pub/mirror/ftp.easysw.com/ftp/pub/fltk/${PV}/fltk-${PV}-source.tar.bz2
\
file://disable_test.patch \
file://dso-fix.patch \
file://libpng15.patch \
+ file://fltk-no-freetype-config.patch \
S = ${WORKDIR}/fltk-${PV}
-inherit lib_package autotools-brokensep binconfig
+inherit lib_package autotools-brokensep binconfig pkgconfig
TARGET_CC_ARCH += ${LDFLAGS} -DXFT_MAJOR=2
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] fltk: Replace use of freetype-config with pkg-config Drop blacklist entry
Hi, On 02.03.2015 11:27, Martin Jansa wrote: Wrong ML, please resend to oe-devel. oh indeed - sorry... Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Use bb.warn instead of bb.error for deprecation notification.
Hi all, On 03.02.2015 13:04, Otavio Salvador wrote: The PRINC support has been dropped so it indeed has to raise an error. The layer you are using needs to be fixed instead. well, in this case the patch is wrong but we *must* raise a fatal error. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Use bb.warn instead of bb.error for deprecation notification.
Hi Ross, On 03.02.2015 13:40, Burton, Ross wrote: bb.error is fatal, so it's all good right? last time I checked (some days ago) it was not necessarily fatal. I was able to build complete image collecting a pile of PR_INC errors. That's what confused me... I'll check if I still have the log on another machine later. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Use bb.warn instead of bb.error for deprecation notification.
Hi, On 03.02.2015 14:00, Burton, Ross wrote: Its an error in a specific recipe, so why should that abandon the build immediately? hum... looks like we have different ideas of what is 'fatal' :-) I would abandon it because the result might not meet the users expectations. Apart from the fact that we should behave consistent with other recipe errors (e.g. parse errors) which are always fatal for a build. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] base.bbclass: Use bb.warn instead of bb.error for deprecation notification.
An error in bitbake/OE context is something fatal and interrupts the build.
A deprecation warning is exactly what we have bb.warn for.
Signed-off-by: Florian Boor florian.b...@kernelconcepts.de
---
meta/classes/base.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index de50be1..b5186bf 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -374,7 +374,7 @@ python () {
# obsolete. Return a warning to the user.
princ = d.getVar('PRINC', True)
if princ and princ != 0:
-bb.error(Use of PRINC %s was detected in the recipe %s (or one of its
.bbappends)\nUse of PRINC is deprecated. The PR server should be used to
automatically increment the PR. See:
https://wiki.yoctoproject.org/wiki/PR_Service.; % (princ, d.getVar(FILE,
True)))
+bb.warn(Use of PRINC %s was detected in the recipe %s (or one of its
.bbappends)\nUse of PRINC is deprecated. The PR server should be used to
automatically increment the PR. See:
https://wiki.yoctoproject.org/wiki/PR_Service.; % (princ, d.getVar(FILE,
True)))
pr = d.getVar('PR', True)
pr_prefix = re.search(\D+,pr)
prval = re.search(\d+,pr)
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] LinuxTag 2013
Hi all, LinuxTag starts next week and we (well I) will be there. LinuxTag takes place from May 22th to May 25th at 'Messegelände unter dem Funkturm' in Berlin, Germany. We share the booth 141 'Linux Embedded' with other cool projects and look forward to meet you there. Greetings Florian PS: Someone with enough power please add some note to the news section of the website. -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] LinuxTag 2013 - last call
Hi all, On 03.04.2013 16:23, Florian Boor wrote: This does not necessarily mean that I intend to to there alone! Everyone is invited to come and help with the booth. Of course any additional support is appreciated as well. Who has some interesting project/hardware/software/usecase related to OpenEmbbedded we can show there? really no one else? I still can order exhibitor passes till the end of today (CEST I assume). Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] LinuxTag 2013
Hi all, even though there was no feedback about my note about LinuxTag I decided to apply for a stand there. The idea is to share a booth with other embedded projects... this time some more people I know applied for a shared Embedded-Linux booth. This does not necessarily mean that I intend to to there alone! Everyone is invited to come and help with the booth. Of course any additional support is appreciated as well. Who has some interesting project/hardware/software/usecase related to OpenEmbbedded we can show there? Anyone with ideas for improving the presentation of the project? A more up to date and more interesting slideshow would be great to have e.g. Who has the power to update the OE poster? I really would like to have our latest sponsors (Eukrea!) on the poster. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-15 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904]florian.b...@kernelconcepts.de http://www.kernelconcepts.de/en ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
