Re: [yocto] icecast
Hi Have a look here: http://www.toradex.com/community/answers/33369/view.html Max Am Donnerstag, den 14.02.2019, 12:35 -0800 schrieb Chuck Wolber: > You have to refactor xslt-config out of the autotools macros and use > pkg-config instead. > > This recipe is an example: > > meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config > -for-pcre-detection.patch > > ..Ch:W.. > > On Thu, Feb 14, 2019 at 05:57 Leonardo Jose Duarte MendesJunior < > leodmende...@gmail.com> wrote: > > > I'm trying to compile the package icecast. The package icecast is old. The > > package depends on xslt. > > When I compile this package, I had the issue with xslt. > > How to use pkgconfig if the own source code use him ? > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-rocko] : fsl-community-bsp X11 build touch screen calibration issue on iMX6UL
Hi > Machine: imx6ulevek > > Image: core-image-x11 > > The issue I have observed on the device is, Xorg is unable to calibrate the > touchscreen, I don't know what has changed but it is unable to calibrate, > below is the log I get on prompt > ... > ERROR: XorgPrint Calibrator does not support the supplied --output-type > > Error: unable to apply or save configuration valuesUsing calibration data > stored in /etc/pointercal.xinput > Does not installing xf86-input-libinput help? xinput-calibrator cannot cope with that input backend. I used the following bbappend to achieve this: http://git.toradex.com/cgit/meta-toradex-demos.git/commit/?h=rocko-next&id=664a1926af81e49396bfe2681 18969ec2b8718cb Regards Max -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto layers missing thud branches
Hi Am Samstag, den 17.11.2018, 15:50 -0800 schrieb akuster808: > Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and meta-cgl > please add a "Thud" branch > While at it, the following patches declaring thud compatibility are not yet applied: https://lists.yoctoproject.org/pipermail/yocto/2018-October/042780.html https://lists.yoctoproject.org/pipermail/yocto/2018-October/042922.html https://lists.yoctoproject.org/pipermail/yocto/2018-October/042923.html Thanks. Max -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] core-image-minimal for raspberrypi3-64 manifest/sdimg contains no kernel modules
Hi Am Mittwoch, den 15.08.2018, 02:47 -0400 schrieb Steve Pavao: > There seems to be a problem with the core-image-minimal bitbake for > raspberrypi3-64 target at head > of sumo in all repos. I wonder if it’s also a problem for the raspberrypi3 > target. > > No kernel modules appear in the .manifest, and no kernel modules are put into > the sdimg. It’s > hard to believe it’s true, but that’s what I'm seeing. > > The problem does NOT occur for the rpi-hwup-image bitbake, which is actually > deprecated in poky > 2.5/sumo. > > Before you retire the rpi-hwup-image bitbake target, will you please make > sure that the kernel > modules from the core-image-minimal build make it into the .manifest and > therefore into the sdimg? > > Please let me know where to log this issue, so I can send you the .manifest > diffs, some ls command > output showing the large size difference between the core-image-minimal and > rpi-hwup-image sdimg > files for identical builds, and perhaps some file listings to show that one > of the builds contains > kernel modules (rpi-hwup-image) and the other does not (core-image-minimal). > > Steve Pavao > Korg R&D > Note that the 'kernel-modules' package is one of the packages built by a kernel recipe. It is a meta package which RDEPENDS on all kernel module packages built by your kernel configuration. So adding that package to your image should do the trick. Max -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to force build of a blacklisted recipe?
Hi > I'm trying to build dvb-apps recipe which is blacklisted and was removed > from the newer openembedded releases, but it exist in the release I work > with > > Now when I try to build the recipe I get this error: > > >ERROR: > /home/oealliancebuilder/openpli-oe-core/meta-openembedded/meta-multimedia/recipes-dvb/dvb- > apps/dvb-apps_1.1.1.bb > was skipped: Recipe is blacklisted: Fails to build with RSS > http://errors.yoctoproject.org/Errors/Details/130603/ - the recipe will > be removed on 2017-09-01 unless the issue is fixed > > But I want to tell openembedded to override the blacklisting and build > the recipe anyway so I can investigate and hopefully fix the recipe. How > can I do that ? You could overwrite the assignment to PNBLACKLIST in conf/local.conf: PNBLACKLIST[dvb-apps] = "" However, if you anyway want to work on the recipe you could simply delete the PNBLACKLIST line in the dvb-apps recipe. Max -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error do_compile libepoxy
Hi
2018-01-18 10:05 GMT+01:00 Alexander Kanavin <
alexander.kana...@linux.intel.com>:
> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>
>>
>> Looks like my first guess was not that bad. Reverting below commit,
>> which switched to meson build system brought my build back to green.
>> Also CC-ing the patch author who might suggest further investigations.
>>
>> libepoxy: convert to meson build
>>
>>
> There's probably a missing header include - carefully compare do_compile
> logs in both cases and see how they differ for the failing file. Also
> inspect the file for any conditional define macros and see if they're
> enabled or not in both cases.
>
>
I've seen this also with a build for Nviidia Tegras which have non
'standard' (i.e. not from the mesa build) EGL/OpenGLES header files. (And
there is no OpenGL/GLX.)
Above error and a linking attempt against the not existing GLX are both in
the test binaries produced from the libepoxy-1.4.3/test directory. All
artefacts from in there are not packaged by our recipe. Before the switch
to meson those binaries were not built, so I guess that the issues have
been there all along but they did not trigger.
My interim fix is to remove the test directory from the top-level
meson.build file but I'm unsure if that is a way forward.
I did not yet build nativesdk-libepoxy with this.
--- libepoxy-1.4.3/meson.build~ 2017-06-06 11:55:31.0 +0200
+++ libepoxy-1.4.3/meson.build 2018-01-18 14:10:49.517098475 +0100
@@ -258,7 +258,6 @@
subdir('include/epoxy')
subdir('src')
-subdir('test')
if get_option('enable-docs')
doxygen = find_program('doxygen', required: false)
[
Max
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4][PATCH 2/2] qt4: Add patch to allow builds of webkit with gcc v7++
Change configure logic, so that only gcc 3.3 and older does
not build webkit and gcc 3.2 and older additionally not
build QtXmlPatterns.
Signed-off-by: Max Krummenacher
---
recipes-qt4/qt4/qt4-4.8.7.inc | 2 +-
.../qt4-4.8.7/{gcc-6.patch => gcc-version.patch}| 21 ++---
recipes-qt4/qt4/qt4-native.inc | 2 +-
3 files changed, 20 insertions(+), 5 deletions(-)
rename recipes-qt4/qt4/qt4-4.8.7/{gcc-6.patch => gcc-version.patch} (62%)
diff --git a/recipes-qt4/qt4/qt4-4.8.7.inc b/recipes-qt4/qt4/qt4-4.8.7.inc
index 7720463..40558aa 100644
--- a/recipes-qt4/qt4/qt4-4.8.7.inc
+++ b/recipes-qt4/qt4/qt4-4.8.7.inc
@@ -27,7 +27,7 @@ SRC_URI =
"http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever
file://0034-Fix-kmap2qmap-build-with-clang.patch \
file://0035-Add-nios2-support.patch \
file://0036-qt-everywhere-opensource-src-4.8.7-gcc6.patch \
- file://gcc-6.patch \
+ file://gcc-version.patch \
file://Fix-QWSLock-invalid-argument-logs.patch \
file://add_check_for_aarch64_32.patch \
file://0001-QWS-fix-24-bit-RGB-BGR-handling.patch \
diff --git a/recipes-qt4/qt4/qt4-4.8.7/gcc-6.patch
b/recipes-qt4/qt4/qt4-4.8.7/gcc-version.patch
similarity index 62%
rename from recipes-qt4/qt4/qt4-4.8.7/gcc-6.patch
rename to recipes-qt4/qt4/qt4-4.8.7/gcc-version.patch
index b0ce9cd..9c5dd48 100644
--- a/recipes-qt4/qt4/qt4-4.8.7/gcc-6.patch
+++ b/recipes-qt4/qt4/qt4-4.8.7/gcc-version.patch
@@ -6,14 +6,29 @@ RP 2016/5/26
Index: qt-everywhere-opensource-src-4.8.7/configure
===
+
+Amend this and change the logic to assume all compilers are suitable
+exept 3.3x resp. 3.2x and older ones.
+Signed-off-by: Max Krummenacher
+
--- qt-everywhere-opensource-src-4.8.7.orig/configure
+++ qt-everywhere-opensource-src-4.8.7/configure
-@@ -7756,7 +7756,7 @@ case "$XPLATFORM" in
+@@ -7757,15 +7757,15 @@
*-g++*)
# Check gcc's version
case "$(${QMAKE_CONF_COMPILER} -dumpversion)" in
- 5*|4*|3.4*)
-+ 6*|5*|4*|3.4*)
- ;;
+- ;;
3.3*)
canBuildWebKit="no"
+ ;;
+- *)
++ 3.2*|3.1*|3.0*|2*)
+ canBuildWebKit="no"
+ canBuildQtXmlPatterns="no"
+ ;;
++ *)
++ ;;
+ esac
+ ;;
+ solaris-cc*)
diff --git a/recipes-qt4/qt4/qt4-native.inc b/recipes-qt4/qt4/qt4-native.inc
index c0d6b3c..08aa61d 100644
--- a/recipes-qt4/qt4/qt4-native.inc
+++ b/recipes-qt4/qt4/qt4-native.inc
@@ -18,7 +18,7 @@ SRC_URI =
"http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever
file://0015-configure-add-nostrip-for-debug-packages.patch \
file://0021-configure-make-qt4-native-work-with-long-building-pa.patch \
file://0036-qt-everywhere-opensource-src-4.8.7-gcc6.patch \
- file://gcc-6.patch \
+ file://gcc-version.patch \
file://g++.conf \
file://linux.conf \
file://qt-everywhere-opensource-src-4.8.6-QTBUG-22829.patch \
--
2.9.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4][PATCH 1/2] qt4-4.8.7.inc: use a supported builtin type for Uchar
cope with icu 59's changed use of uchar.
http://site.icu-project.org/download/59#TOC-ICU4C-char16_t
4.8.7-r0/recipe-sysroot/usr/include/unicode/umachine.h:347:13: error:
'char16_t' does not name a type; did you mean 'wchar_t'?
typedef char16_t UChar;
^~~~
wchar_t
...
4.8.7-r0/recipe-sysroot/usr/include/unicode/uversion.h:167:55: error: 'UChar'
does not name a type; did you mean 'UChar32'?
u_versionFromUString(UVersionInfo versionArray, const UChar *versionString);
Signed-off-by: Max Krummenacher
---
recipes-qt4/qt4/qt4-4.8.7.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-qt4/qt4/qt4-4.8.7.inc b/recipes-qt4/qt4/qt4-4.8.7.inc
index 4bade85..7720463 100644
--- a/recipes-qt4/qt4/qt4-4.8.7.inc
+++ b/recipes-qt4/qt4/qt4-4.8.7.inc
@@ -46,7 +46,7 @@ UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)/"
S = "${WORKDIR}/qt-everywhere-opensource-src-${PV}"
# workaround for class std::auto_ptr' is deprecated with gcc-6
-CXXFLAGS += "-std=gnu++98 -Wno-deprecated"
+CXXFLAGS += "-std=gnu++98 -Wno-deprecated -DUCHAR_TYPE=wchar_t"
# disable webkit for mips64 n32 temporarily that fails to compile,
# qt upstream defect:
--
2.9.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The basehash value changed from...
Hi Zoran Am Donnerstag, den 07.09.2017, 09:37 +0200 schrieb Zoran Stojsavljevic: > While re-compiling the whole YOCTO load for freescale i.MX6, where I have > added Qt5 layers (and it failed many times, so I needed to do some tricks > there), I encounter the following warning (in *ORANGE*) and error (in *RED*) > while finishing the build: > > *WARNING: Duplicate inclusion for > /home/user/toradex/Qt5-plus-x11/oe-core/build/../layers/meta-toradex-bsp- > common/conf/tdx_version.conf > in > /home/user/toradex/Qt5-plus-x11/oe-core/build/../layers/meta-toradex-demos/recipes- > images/images/tdx-image-fstype.inc* > *ERROR: When reparsing > /home/user/toradex/Qt5-plus-x11/oe-core/build/../layers/meta-toradex-demos/recipes- > images/images/angstrom-lxde-image.bb.do_image_teziimg, > the basehash value changed from b7b4f312b8b657bfdd068ebd8e2dd104 to > 1e71714a9c01964cdc724c52290abee4. The metadata is not deterministic and > this needs to be fixed.* > NOTE: Tasks Summary: Attempted 7415 tasks of which 7394 didn't need to be > rerun and all succeeded. Please note the '... and all succeeded'. So the basehash error did not break the build. I think the basehash error is due to the use of the DATE variable and that the following commit fixes it in master: http://cgit.openembedded.org/openembedded-core/commit/?id=4af13a4855c74cea9cf6c168fd73165d7094bf93 However Stefan is still in the process of backporting said commit, so you still see the error in morty. http://lists.openembedded.org/pipermail/openembedded-core/2017-August/141582.html Max -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Shared library question
Hi
Am Montag, den 27.02.2017, 15:03 +0100 schrieb Gary Thomas:
> I trying to create a package am335x-pru-support which creates a
> shared library used by another package pru-examples. The library
> files installed with am335x-pru-support are (from /image)
> -rwxr-xr-x 4 gthomas gthomas 17074 Feb 27 13:40 usr/lib/libprussdrv.a
> lrwxrwxrwx 1 gthomas gthomas16 Feb 27 13:40 usr/lib/libprussdrv.so ->
> libprussdrv.so.1
> lrwxrwxrwx 1 gthomas gthomas18 Feb 27 13:40 usr/lib/libprussdrv.so.1 ->
> libprussdrv.so.1.0
> -rwxr-xr-x 1 gthomas gthomas 22092 Feb 27 13:40 usr/lib/libprussdrv.so.1.0
> -rw-r--r-- 4 gthomas gthomas 8074 Feb 27 13:40 usr/include/pruss/prussdrv.h
> -rw-r--r-- 4 gthomas gthomas 4286 Feb 27 13:40
> usr/include/pruss/pruss_intc_mapping.h
>
> These files are split by the packager as:
> gthomas@europa:packages-split$ find am335x-pru-support | sort
> am335x-pru-support
> am335x-pru-support/usr
> am335x-pru-support/usr/lib
> am335x-pru-support/usr/lib/libprussdrv.so.1
> am335x-pru-support/usr/lib/libprussdrv.so.1.0
> gthomas@europa:packages-split$ find am335x-pru-support-dev | sort
> am335x-pru-support-dev
> am335x-pru-support-dev/usr
> am335x-pru-support-dev/usr/include
> am335x-pru-support-dev/usr/include/pruss
> am335x-pru-support-dev/usr/include/pruss/prussdrv.h
> am335x-pru-support-dev/usr/include/pruss/pruss_intc_mapping.h
> am335x-pru-support-dev/usr/lib
> am335x-pru-support-dev/usr/lib/libprussdrv.so
>
> These files get staged correctly to pru-examples recipe-specific-sysroot
> and I can build and link against them, using DEPENDS="am335x-pru-support".
> The problem is that when my build (target recipe) uses
>$(CC) my_target_program.c $(LDFLAGS) -lprussdrv
> it gets satisfied by /usr/lib/libprussdrv.so and not /usr/lib/libprussdrv.so.1
> This in turn appears to keep the pru-examples package from having
> a runtime dependency against the am335x-pru-support package and the
> necessary library file does not end up on my target.
>
> I've tried to work through this, following many recipes as examples,
> e.g. meta/recipes-multimedia/libogg (pattern for am335x-pru-support)
> and meta/recipes-multimedia/flac (pattern for pru-examples). The
> libogg/flac combo works correctly, mine does not :-(
>
> Any pointers on what I might be doing wrong? I'm so close to getting
> this stuff going, it's just the packaging that's going to claim the
> last hairs from my head...
When linking a shared object file you have to pass the linker a soname which
adds compatible version
information into the share object file.
Have a look here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/recipes-bsp?id=7ff327a4e3e8e19d1e3f848
865b6b27ba9f6250b
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Alternatively you can drop the libprussdrv.so.1 and libprussdrv.so.1.0, and
force with FILES... the
libprussdrv.so into the not -dev package.
Probably you would also want to INSANE_SKIP_${PN} = "dev-so".
Max
>
> Thanks
>
> n.b. I'm happy to share any of the recipes, I just left them out for brevity.
>
> --
>
> Gary Thomas | Consulting for the
> MLB Associates |Embedded world
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4][PATCH] packagegroup-core-qt4e.bb: mv tslib from rdepends to rrecommends
Commit c4671873af5ab6c7d15ca397538f154c11c3486e made the build of tslib a
PACKAGECONFIG. By default tslib components are not built.
Thus a build for a machine with "MACHINE_FEATURES" "touchscreen"
fails for missing tslib components.
Signed-off-by: Max Krummenacher
---
Alternatively or additionally one could change the default PACKAGECONFIG
in qt4-embedded.inc conditionally on MACHINE_FEATURES. If that is prefered
I could create a patch.
Max
recipes-qt4/packagegroups/packagegroup-core-qt4e.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-qt4/packagegroups/packagegroup-core-qt4e.bb
b/recipes-qt4/packagegroups/packagegroup-core-qt4e.bb
index 588e99b..86646e9 100644
--- a/recipes-qt4/packagegroups/packagegroup-core-qt4e.bb
+++ b/recipes-qt4/packagegroups/packagegroup-core-qt4e.bb
@@ -37,7 +37,6 @@ RDEPENDS_${PN} = " \
qt4-embedded-plugin-imageformat-tiff \
qt4-embedded-plugin-script-dbus \
qt4-embedded-plugin-sqldriver-sqlite \
- ${TOUCH} \
qt4-embedded-demos \
qt4-embedded-examples \
qt-demo-init \
@@ -47,5 +46,6 @@ RDEPENDS_${PN} = " \
RRECOMMENDS_${PN} = " \
libqt-embeddedxmlpatterns4 \
qt4-embedded-plugin-phonon-backend-gstreamer \
+ ${TOUCH} \
"
--
2.5.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
