[linux-yocto] [yocto-kernel-cache][PATCH 5/6] intel-common-drivers: enable OSS sound support

[chun . weng . ong]

From: Ong Chun Weng 

---
 bsp/intel-common/intel-common-drivers.scc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index f03e794..5557558 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -15,6 +15,9 @@ kconf hardware bsp/common-pc/common-pc-wifi.cfg
 # Platform Controller Hun EG20T
 include features/eg20t/eg20t.scc
 
+# OSS sound support
+include cfg/sound.scc
+
 # PCI
 include features/pci/pci.scc
 
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache][PATCH 3/6] intel-common: add support for more driver features for 32-bit system

[chun . weng . ong]

From: Ong Chun Weng 

Enable features that supported by Skylake in 32-bit intel common BSP.

---
 bsp/intel-common/intel-common-drivers-32.scc | 28 
 1 file changed, 28 insertions(+)

diff --git a/bsp/intel-common/intel-common-drivers-32.scc 
b/bsp/intel-common/intel-common-drivers-32.scc
index 7fcddb7..db5fb41 100644
--- a/bsp/intel-common/intel-common-drivers-32.scc
+++ b/bsp/intel-common/intel-common-drivers-32.scc
@@ -3,3 +3,31 @@
 # Common drivers and technologies to enable intel-common 32bit derived BSPs.
 #
 include features/eg20t/eg20t.scc
+
+include features/power/intel.scc
+
+# OSS sound support
+include cfg/sound.scc
+
+# Enable options for xhci (USB 3.0)
+include features/usb/xhci-hcd.scc
+
+# Enable options for ehci (USB 2.0)
+include features/usb/ehci-hcd.scc
+
+# Coretemp support for Intel platforms
+include features/thermal/coretemp.scc
+
+# Intel High Definition Audio Support
+include features/sound/snd_hda_intel.scc
+
+include features/intel-e1/intel-e1.scc
+
+# Enable iwlwifi support
+include features/iwlwifi/iwlwifi.scc
+
+# Bluetooth
+include features/bluetooth/bluetooth.scc
+
+# Enable options for the Intel Management Engine Interface include
+features/amt/mei/mei.scc
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache][PATCH 4/6] intel-common-drivers: enable EG20T platform controller hub

[chun . weng . ong]

From: Ong Chun Weng 

---
 bsp/intel-common/intel-common-drivers.scc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index 9beef28..f03e794 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -12,6 +12,9 @@ kconf hardware bsp/common-pc/common-pc-eth.cfg
 kconf hardware bsp/common-pc/common-pc-gfx.cfg
 kconf hardware bsp/common-pc/common-pc-wifi.cfg
 
+# Platform Controller Hun EG20T
+include features/eg20t/eg20t.scc
+
 # PCI
 include features/pci/pci.scc
 
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache][PATCH 6/6] intel-common: enable support for skylake in intel common bsp

[chun . weng . ong]

From: Ong Chun Weng 

---
 bsp/intel-common/intel-core2-32.scc  | 1 +
 bsp/intel-common/intel-corei7-64.scc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/bsp/intel-common/intel-core2-32.scc 
b/bsp/intel-common/intel-core2-32.scc
index 805158d..4d98d7b 100644
--- a/bsp/intel-common/intel-core2-32.scc
+++ b/bsp/intel-common/intel-core2-32.scc
@@ -10,6 +10,7 @@ include cfg/x86.scc
 # Supported platforms and SoCs
 include features/soc/baytrail/baytrail.scc
 include features/soc/tunnelcreek/tunnelcreek.scc
+include features/soc/skylake/skylake.scc
 
 # Fixme: These should be moved into something similar to the above
 include bsp/mohonpeak/mohonpeak32.scc
diff --git a/bsp/intel-common/intel-corei7-64.scc 
b/bsp/intel-common/intel-corei7-64.scc
index 4cac733..15aad87 100644
--- a/bsp/intel-common/intel-corei7-64.scc
+++ b/bsp/intel-common/intel-corei7-64.scc
@@ -9,6 +9,7 @@ include cfg/x86_64.scc
 
 # Supported platforms and SoCs
 include features/soc/baytrail/baytrail.scc
+include features/soc/skylake/skylake.scc
 
 # Fixme: These should be moved into something similar to the above
 include bsp/haswell-wc/haswell-wc.scc
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache][PATCH 2/6] intel-pinctrl: enable pinctrl driver for skylake

[chun . weng . ong]

From: Ong Chun Weng 

---
 features/intel-pinctrl/intel-pinctrl.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/features/intel-pinctrl/intel-pinctrl.cfg 
b/features/intel-pinctrl/intel-pinctrl.cfg
index 822485e..7b672b3 100644
--- a/features/intel-pinctrl/intel-pinctrl.cfg
+++ b/features/intel-pinctrl/intel-pinctrl.cfg
@@ -2,3 +2,5 @@ CONFIG_PINCTRL_INTEL=y
 CONFIG_PINCTRL_BAYTRAIL=y
 CONFIG_PINCTRL_CHERRYVIEW=y
 CONFIG_PINCTRL_BROXTON=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_SUNRISEPOINT=m
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache][PATCH 1/6] features: soc: enable configurations for skylake

[chun . weng . ong]

From: Ong Chun Weng 

---
 features/soc/skylake/skylake.cfg | 22 ++
 features/soc/skylake/skylake.scc | 12 
 2 files changed, 34 insertions(+)
 create mode 100644 features/soc/skylake/skylake.cfg
 create mode 100644 features/soc/skylake/skylake.scc

diff --git a/features/soc/skylake/skylake.cfg b/features/soc/skylake/skylake.cfg
new file mode 100644
index 000..5e09436
--- /dev/null
+++ b/features/soc/skylake/skylake.cfg
@@ -0,0 +1,22 @@
+CONFIG_CPU_IDLE=y
+CONFIG_MFD_INTEL_LPSS=m
+CONFIG_MFD_INTEL_LPSS_ACPI=m
+CONFIG_MFD_INTEL_LPSS_PCI=m
+CONFIG_INTEL_IDMA64=m
+CONFIG_GPIO_LYNXPOINT=m
+CONFIG_USB_EHCI_PCI=y
+CONFIG_POWERCAP=y
+CONFIG_INTEL_RAPL=m
+CONFIG_INTEL_POWERCLAMP=m
+CONFIG_HWMON=y
+CONFIG_SENSORS_I5500=m
+CONFIG_DRM_LOAD_EDID_FIRMWARE=y
+CONFIG_SND_HDA_I915=y
+CONFIG_SND_SOC_INTEL_SKL_RT286_MACH=m
+CONFIG_SND_SOC_INTEL_SST=m
+CONFIG_SND_SOC_INTEL_SST_ACPI=m
+CONFIG_SND_DYNAMIC_MINORS=y
+CONFIG_NETCONSOLE=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_INTEL=y
+CONFIG_INTEL_MEI_TXE=m
diff --git a/features/soc/skylake/skylake.scc b/features/soc/skylake/skylake.scc
new file mode 100644
index 000..bc59f22
--- /dev/null
+++ b/features/soc/skylake/skylake.scc
@@ -0,0 +1,12 @@
+# skylake.scc
+#
+# Features and devices found on the Skylake SoCs
+#
+
+# Enable I2C Support
+include features/i2c/i2c.scc
+
+# Enable mac 80211 + WLAN support
+include features/mac80211/mac80211.scc
+
+kconf hardware skylake.cfg
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [yocto-kernel-cache][PATCH 0/6] Enable kernel configuration for Skylake

[chun . weng . ong]

From: Ong Chun Weng 

These patch is to enable the kernel configuration for Skylake. 
And these patch is tested on Saddlebrook platform.

Please review and merge into yocto-kernel-cache branch yocto-4.4.

Thanks,
Chun Weng

Ong Chun Weng (6):
  features: soc: enable configurations for skylake
  intel-pinctrl: enable pinctrl driver for skylake
  intel-common: add support for more driver features for 32-bit system
  intel-common-drivers: enable EG20T platform controller hub
  intel-common-drivers: enable OSS sound support
  intel-common: enable support for skylake in intel common bsp

 bsp/intel-common/intel-common-drivers-32.scc | 28 
 bsp/intel-common/intel-common-drivers.scc|  6 ++
 bsp/intel-common/intel-core2-32.scc  |  1 +
 bsp/intel-common/intel-corei7-64.scc |  1 +
 features/intel-pinctrl/intel-pinctrl.cfg |  2 ++
 features/soc/skylake/skylake.cfg | 22 ++
 features/soc/skylake/skylake.scc | 12 
 7 files changed, 72 insertions(+)
 create mode 100644 features/soc/skylake/skylake.cfg
 create mode 100644 features/soc/skylake/skylake.scc

-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] problems with cmake finding the c++ includes

[Paul Eggleton]

Hi Stefan,

On Wed, 27 Apr 2016 08:35:51 s.jar...@esa-grimma.de wrote:
> Thank you for taking time to check my problem. I fixed that. Maybe not how
> you will do it.
> My main problem still exists - the compiling problem when the std. c++
> includes needed to be compiled. Maybee you have an idea how to tell the
> cmake class where to search it's header files.

The problem is Build.cmake in the g3log sources is setting CMAKE_CXX_FLAGS 
outright instead of adding to it, with the result that the default arguments 
set by OE (most importantly --sysroot) aren't being supplied to the compiler, 
so it can't find the standard headers. Really that file needs to be patched - 
I've attached a patch to fix it which you can put in a "files" or "g3log" 
directory alongside the recipe and add a file:// pointer to in SRC_URI, see 
other recipes for examples).

Also attached is a patch to fix the fact that the libg3log.so library produced 
wasn't versioned, which our build system expects and if it's not the case you 
will get a QA error. It is possible to disable that check but this is a little 
neater.

(I wouldn't normally go this far, but I was in a curious mood this afternoon.)

Cheers,
Paul

PS if you could please retain the mailing list on replies (unless they need to 
be private) that would be great.

-- 

Paul Eggleton
Intel Open Source Technology Centre>From d8cd848f5b52c7b494da721e313462fe058e8561 Mon Sep 17 00:00:00 2001
From: Paul Eggleton 
Date: Thu, 28 Apr 2016 15:15:55 +1200
Subject: [PATCH 1/2] Ensure default CXX flags such as --sysroot don't get
 wiped out

Signed-off-by: Paul Eggleton 
---
 Build.cmake | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Build.cmake b/Build.cmake
index 6b583f9..41bfaf5 100644
--- a/Build.cmake
+++ b/Build.cmake
@@ -23,7 +23,7 @@ SET(ACTIVE_CPP0xx_DIR "Release")
 IF ("${CMAKE_CXX_COMPILER_ID}" MATCHES ".*Clang")
MESSAGE("")
MESSAGE("cmake for Clang ")
-   SET(CMAKE_CXX_FLAGS "-Wall -std=c++11 -Wunused -D_GLIBCXX_USE_NANOSLEEP")
+   SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -std=c++11 -Wunused -D_GLIBCXX_USE_NANOSLEEP")
IF (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libstdc++ -pthread")
ELSE()
@@ -47,12 +47,12 @@ IF ("${CMAKE_CXX_COMPILER_ID}" MATCHES ".*Clang")
 ELSEIF("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
MESSAGE("cmake for GCC ")
IF (APPLE)
-   set(CMAKE_CXX_FLAGS "-Wall -Wunused -std=c++11  -pthread -D_GLIBCXX_USE_NANOSLEEP")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wunused -std=c++11  -pthread -D_GLIBCXX_USE_NANOSLEEP")
ELSEIF (MINGW)
-   set(CMAKE_CXX_FLAGS "-Wall -Wunused -std=c++11  -pthread -D_GLIBCXX_USE_NANOSLEEP -D_GLIBCXX_USE_SCHED_YIELD")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wunused -std=c++11  -pthread -D_GLIBCXX_USE_NANOSLEEP -D_GLIBCXX_USE_SCHED_YIELD")
ELSE()
set(PLATFORM_LINK_LIBRIES rt)
-   set(CMAKE_CXX_FLAGS "-Wall -rdynamic -Wunused -std=c++11 -pthread -D_GLIBCXX_USE_NANOSLEEP -D_GLIBCXX_USE_SCHED_YIELD")
+   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -rdynamic -Wunused -std=c++11 -pthread -D_GLIBCXX_USE_NANOSLEEP -D_GLIBCXX_USE_SCHED_YIELD")
ENDIF()
 ENDIF()
 
-- 
2.5.5

>From b8090456a448f8623734b857be597b8eb242a869 Mon Sep 17 00:00:00 2001
From: Paul Eggleton 
Date: Thu, 28 Apr 2016 15:16:52 +1200
Subject: [PATCH 2/2] Use a versioned library

Signed-off-by: Paul Eggleton 
---
 Build.cmake | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Build.cmake b/Build.cmake
index 41bfaf5..7ec73f6 100644
--- a/Build.cmake
+++ b/Build.cmake
@@ -107,7 +107,9 @@ if(ADD_BUILD_WIN_SHARED OR NOT(MSVC OR MINGW))
set_target_properties(g3logger_shared PROPERTIES
   LINKER_LANGUAGE CXX
   OUTPUT_NAME g3logger
-  CLEAN_DIRECT_OUTPUT 1)
+  CLEAN_DIRECT_OUTPUT 1
+  VERSION "0.0.0"
+  SOVERSION 0)
IF(APPLE)
   set_target_properties(g3logger_shared PROPERTIES MACOSX_RPATH TRUE)
ENDIF(APPLE)
-- 
2.5.5

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

Re: [yocto] aarch64-oe-linux/bin/ld: cannot find -lgcc . Adding native build support for arm64/aarch64 in oe-rootfs.

[Khem Raj]

you could use multilib add something like this below to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon”

> On Apr 26, 2016, at 10:53 PM, Jaggi, Manish  
> wrote:
> 
> It worked, thanks!!
> 
> But I couldnt find support to include multilibs say for 32bit and 64bit gcc.
> There is a MULTILIB macro but I am not sure how to use it?
> I think multilib recipes (bbfiles) are required, how to get them?
> 
> 
> Regards,
> Manish Jaggi
> From: Burton, Ross >
> Sent: Tuesday, April 26, 2016 2:27:12 PM
> To: Jaggi, Manish
> Cc: yocto@yoctoproject.org 
> Subject: Re: [yocto] aarch64-oe-linux/bin/ld: cannot find -lgcc . Adding 
> native build support for arm64/aarch64 in oe-rootfs.
> 
> 
> On 26 April 2016 at 09:37, Jaggi, Manish  > wrote:
> IMAGE_INSTALL_append = "gcc"
> IMAGE_INSTALL_append += " glibc"
> IMAGE_INSTALL_append += " libgcc"
> IMAGE_INSTALL_append += " binutils"
> IMAGE_INSTALL_append += " gccmakedep"
> 
> You left out the development headers and libraries required to actually link.
> 
> IMAGE_FEATURES is a more efficient way of doing this.  EXTRA_IMAGE_FEATURES 
> += "tools-sdk" will add gcc/cpp/make/etc, and "dev-pkgs" will ensure that all 
> of the -dev packages are installed on your image, so you can link against 
> anything you've installed.
> 
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dumping (inferred) do_task[vardeps] for some do_task

[Ulf Magnusson]

On Wed, Apr 27, 2016 at 6:19 PM, Christopher Larson  wrote:
>
>
> On Wed, Apr 27, 2016 at 9:11 AM, Ulf Magnusson  wrote:
>>
>> I'm trying to get a feel for how BitBake infers task dependencies. The
>> easiest way (but I'm open to suggestions) seems to be to dump the
>> value of do_task[vardeps] for a particular recipe after the inferred
>> dependencies are added.
>>
>> What's a good way to dump do_task[vardeps]? I tried using getVarFlag()
>> in an anonymous Python function, but it only catches dependencies
>> explicitly added to do_task[vardeps]. Maybe [vardeps] is never
>> assigned the complete set of dependencies internally, or maybe the
>> anonymous Python function is called too early.
>
>
> That's correct, the full list is not stored in the vardeps.
>

That was what I was starting to suspect. Thanks for conforming.

>> generate_dependencies() in bitbake/lib/bb/data.py also looked
>> promising, but maybe there's a better places further up the callstack.
>
>
> That is a reasonable place in the code, yes. You can inspect a certain
> amount of information in the signature data files, but I'm not sure it
> drills down to the level you desire.
>
> My 'bb' tool's 'show' subcommand can show not just a variable but also its
> dependencies, perhaps that might be of use? I haven't touched it in ages,
> but in theory it should work.

>From some quick experimentation,

  $ bb show -d -r test_recipe do_compile

only gave me the source code and not the dependencies.

I found a hackish method that seems to work however. Adding

python () {
deps, _ = bb.data.build_dependencies("do_compile", set(), set(), set(), d)
bb.note("do_compile deps: ", str(deps))
}

to the recipe also prints all the inferred dependencies.

Thanks,
Ulf
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dumping (inferred) do_task[vardeps] for some do_task

[Christopher Larson]

On Wed, Apr 27, 2016 at 9:11 AM, Ulf Magnusson  wrote:

> I'm trying to get a feel for how BitBake infers task dependencies. The
> easiest way (but I'm open to suggestions) seems to be to dump the
> value of do_task[vardeps] for a particular recipe after the inferred
> dependencies are added.
>
> What's a good way to dump do_task[vardeps]? I tried using getVarFlag()
> in an anonymous Python function, but it only catches dependencies
> explicitly added to do_task[vardeps]. Maybe [vardeps] is never
> assigned the complete set of dependencies internally, or maybe the
> anonymous Python function is called too early.
>

That's correct, the full list is not stored in the vardeps.

generate_dependencies() in bitbake/lib/bb/data.py also looked
> promising, but maybe there's a better places further up the callstack.
>

That is a reasonable place in the code, yes. You can inspect a certain
amount of information in the signature data files, but I'm not sure it
drills down to the level you desire.

My 'bb' tool's 'show' subcommand can show not just a variable but also its
dependencies, perhaps that might be of use? I haven't touched it in ages,
but in theory it should work.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Dumping (inferred) do_task[vardeps] for some do_task

[Ulf Magnusson]

Hello,

I'm trying to get a feel for how BitBake infers task dependencies. The
easiest way (but I'm open to suggestions) seems to be to dump the
value of do_task[vardeps] for a particular recipe after the inferred
dependencies are added.

What's a good way to dump do_task[vardeps]? I tried using getVarFlag()
in an anonymous Python function, but it only catches dependencies
explicitly added to do_task[vardeps]. Maybe [vardeps] is never
assigned the complete set of dependencies internally, or maybe the
anonymous Python function is called too early.

generate_dependencies() in bitbake/lib/bb/data.py also looked
promising, but maybe there's a better places further up the callstack.

Thanks a lot,
Ulf
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono] Mono XSP Issue

[Davis, Michael]

I am trying to build mono with the mono-xsp (fastcgi) package.
Compiling works fine, however on the final image all the scripts are incorrect. 
 
For example /usr/bin/fastcgi-mono-server4 has the following contents.

#!/bin/sh
exec /build/product/tmp-glibc/sysroots/x86_64-linux/usr/bin/mono $MONO_OPTIONS 
"/usr/lib/mono/2.0/mod-mono-server2.exe" "$@"

It is pointing to the mono binary on my build system instead of on the target 
system.

I am currently running of meta-mono master with the latest version of jethro.  
A grep of all files containing that incorrect path is below.

grep -r /build/monte/tmp-glibc/sysroots/x86_64-linux
usr/lib/mono/gac/monodoc/1.0.0.0__0738eb9f132ed756/monodoc.dll.config:  
  

usr/bin/mod-mono-server:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/2.0/mod-mono-server2.exe" "$@"
usr/bin/asp-state2:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/xsp/2.0/asp-state2.exe" "$@"
usr/bin/fastcgi-mono-server:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/2.0/fastcgi-mono-server2.exe" 
"$@"
usr/bin/xsp:exec /build/monte/tmp-glibc/sysroots/x86_64-linux/usr/bin/mono 
$MONO_OPTIONS "/usr/lib/mono/2.0/xsp2.exe" "$@"
usr/bin/dbsessmgr2:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/xsp/2.0/dbsessmgr2.exe" "$@"
usr/bin/xsp4:exec /build/monte/tmp-glibc/sysroots/x86_64-linux/usr/bin/mono 
$MONO_OPTIONS "/usr/lib/mono/4.5/xsp4.exe" "$@"
usr/bin/fastcgi-mono-server4:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/4.5/fastcgi-mono-server4.exe" 
"$@"
usr/bin/mod-mono-server2:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/2.0/mod-mono-server2.exe" "$@"
usr/bin/mono-fpm:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/4.5/mono-fpm.exe" "$@"
usr/bin/mod-mono-server4:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/4.5/mod-mono-server4.exe" "$@"
usr/bin/dbsessmgr4:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/xsp/4.0/dbsessmgr4.exe" "$@"
usr/bin/xsp2:exec /build/monte/tmp-glibc/sysroots/x86_64-linux/usr/bin/mono 
$MONO_OPTIONS "/usr/lib/mono/2.0/xsp2.exe" "$@"
usr/bin/asp-state4:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/xsp/4.0/asp-state4.exe" "$@"
usr/bin/asp-state:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/xsp/2.0/asp-state2.exe" "$@"
usr/bin/fastcgi-mono-server2:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/mono/2.0/fastcgi-mono-server2.exe" 
"$@"
usr/bin/dbsessmgr:exec /build/monte/tmp-glibc/sysroots/x86_64-
linux/usr/bin/mono $MONO_OPTIONS "/usr/lib/xsp/2.0/dbsessmgr2.exe" "$@"


Thanks,
Mike Davis
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Manipulating code and Building in offline environment

[Burton, Ross]

On 27 April 2016 at 14:03, Lars Larsen  wrote:
>
> BRANCH ?="develop"
> SRC_URI =
 "git:///eserver/GIT/autodiscover/;branch=${BRANCH};;name=discover "
> SRCREV_discover= "${AUTOREV}"
> SRCREV_FORMAT= "discover"

This is likely the problem.

$(AUTOREV) means "go and get the latest revision every build", which is
incompatible with offline builds.  Set the SRCREV to a specific SHA and
then the mirror can contain the SHA that the recipe wants to build.

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

[yocto] populate_sdk cmake and eclipse

[Ruben Schwarz]

Hi,

we created our own image for our custom hardware with yocto jethro.
Everything works fine, thanks for this great tools!

Now more developers have to write software for our project. I did the
following steps to set up a application dev environment (as mentionend in
application developers guide):

1. Create sdk: bitbake myImage -c populate_sdk
2. copy generated sdk.sh to a fresh installed ubuntu 14.04 and execute.
Toolchain is installed in /opt/poky/2.0.1/
3. install eclipse and the eclipse yocto plugin as mentionend in the docs.
4. Create a new Yocto Autotools C++ Project -> Build -> copy to target ->
Execute -> everything is fine!
5. Create a new Yocto CMake C++ Project -> Build -> Error: unable to run
cmake
6. Compile cmake project by hand:
cd PROJECT_FOLDER/Debug
source /opt/poky/2.0.1/environment_setup...
cmake ..
make

compiles without errors

*Now my questions:*
Anybody here who uses a sdk with eclipse and cmake?
Did I miss any configuration?

Not directly regarded to this problem:
Anybody here who uses JetBrains CLion with a yocto toolchain/sdk?

Thanks in advance and best regards
Ruben

-- 


Besuchen Sie uns auf der Hannover Messe vom 25. - 29. April, Halle 7, Stand 
D 34 auf dem Gemeinschaftsstand Baden-Württemberg! weitere Informationen 


Besuchen Sie unseren Chrome Webshop unter shop.cloudwuerdig.com

www.sotec.eu | www.cloudwuerdig.com 
-- 
SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG 
Calwer Straße 11, D-75395 Ostelsheim 
Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, 
Geschäftsführer: Florian Holz 
Cloudwürdig® ist eine eingetragene Marke der SOTEC Software Entwicklungs 
GmbH + Co Mikrocomputertechnik KG

Der Inhalt dieser e-Mail ist ausschließlich für den bezeichneten Adressaten 
bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder dessen 
Vertreter sein sollten, so beachten Sie bitte, dass jede Form der 
Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des 
Inhalts dieser e-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall 
mit dem Absender der e-Mail in Verbindung zu setzen.

The content of this e-mail is meant exclusively for the person to whom it 
is addressed. If you are not the person to whom this e-mail is addressed or 
his/her representative, please be informed, that any form of knowledge, 
publication, duplication or distribution of the content of this e-mail is 
inadmissible. We ask you, therefore, in such a case to please contact the 
sender of this e-mail.

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

Re: [yocto] Manipulating code and Building in offline environment

[Lars Larsen]

On 2016-04-27 14:21, Gary Thomas wrote:

On 2016-04-27 13:38, Lars Larsen wrote:

Hello

I have 2 questions

I have finally managed to build an image like I want it.


I consists of a kernel.

The ROS framework.

And our proprietary software under git control


What I want to achieve is the following:

When online it should fetch the latest commit (or what ever 
branch/tag) from our git repo.


It should be possible to take a laptop with a fresh checkout of all 
the software, go to the field where the is NO
INTERNET access, and be able to patch our code on the spot ,and build 
fresh images, for the target.


When online in our office environment all our own software is 
correctly checked out from our git repo. and build.

Beautifully.

But when offline ( I disconnect the LAN ) I continually gets errors 
like “Failure expanding variable SRCPV” on our

software modules.

I have following in build/conf/local.conf


BB_GENERATE_MIRROR_TARBALLS = "1"

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = "file://${DL_DIR}"


and I experimented with BB_FETCH_PREMIRRORONLY = "1"

with no appearent effect


So question 1:

How do I achieve the offline building. ?

Is should be possible - right ?


Question 2:

Where in the tree is the checked out source code located, that 
bitbake compiles from.




I do this all the time successfully.

What is your target and what recipe(s) are having issues?

Note setting BB_NO_NETWORK = "1" in local.conf can help diagnose these 
issues





Thanks for the quick response, I will be happy if you can help me solve 
this, since it's the last stone in our shoes before we go all in on yocto.



My target (at this time) is just a plain vanilla X86 platform - i might 
change in the furture.

The recipes that cause troubles, are those who examine my git repos
one example, I have several made from this template ($BRANCH is set by 
envoking scripts):


/DESCRIPTION = "Reflector deamon-  from local GIT"//
//# The initscript reflectord.sh that starts the deamon is installed 
with basic-framwork-files//

//HOMEPAGE = "www.visionweeding.com"//
//LICENSE = "CLOSED"//
//FPE_PATH = "/opt/fpe"//
//BRANCH ?="develop"//
//SRC_URI = 
"git:///eserver/GIT/autodiscover/;branch=${BRANCH};;name=discover " //

//SRCREV_discover= "${AUTOREV}"//
//SRCREV_FORMAT= "discover"//
//PV = "1.0.0+gitr${SRCPV}"//
//S = "${WORKDIR}/git"//
//inherit cmake//
//FILESEXTRAPATHS_prepend := "${THISDIR}/files:"//
//FILES_${PN} += "${FPE_PATH}/bin/reflectord \//
//${FPE_PATH}/bin/SearchBeam \//
//  "//
//do_install_append() {//
//
//bbnote "Branch test BRANCH= ${BRANCH}"//

//  install -d ${D}${FPE_PATH}/bin//

//rm  -rf ${FPE_PATH}/bin/.debug/*//
//install -d ${D}${sysconfdir}/init.d //
//install -m 0755 ${WORKDIR}/SearchBeam ${D}${FPE_PATH}/bin //
//install -m 0755 ${WORKDIR}/reflectord ${D}${FPE_PATH}/bin//
}//
//

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

Re: [yocto] [Fwd: gobject introspection release notes]

[Chris Trobridge]

> Subject: Re: [yocto] [Fwd: gobject introspection release notes]
> To: zhenhua@nxp.com; christrobri...@hotmail.com
> CC: yocto@yoctoproject.org
> From: alexander.kana...@linux.intel.com
> Date: Wed, 27 Apr 2016 15:38:01 +0300
> 
> On 04/26/2016 11:05 AM, Zhenhua Luo wrote:
> > Any ideas as to why "qemu-ppc64 crashes out immediately"?
> >
> > I can confirm the build ends in a segfault when I tried building
> > gobject-introspection for the t1042d4rdb-64b machine.
> >
> > */[Luo Zhenhua-B19537] This is a gobject-introspection support issue of
> > QEMU PPC64, the fix is not available now, you can use the following
> > workaround to bypass the issue. /*
> >
> > */http://git.yoctoproject.org/cgit.cgi/meta-fsl-ppc/tree/README#n18/*
> 
> I'm afraid disabling introspection data is not an acceptable solution 
> for Chris, because he does want to have that data.
> 
> Also, I'll send a fix to disable building of introspection data on all 
> ppc64 machines for now.
> 
> Alex

Thanks Alex.
This is not urgent and with this processor there is the option of using 32-bit 
mode.  So if the new commit fixes the 32-bit machine then that would be an 
acceptable alternative for now.
I like to fix things so I am curious about the qemu-ppc64 crash but realise I 
can't afford to spend much time on it!
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Fwd: gobject introspection release notes]

[Alexander Kanavin]

On 04/26/2016 11:05 AM, Zhenhua Luo wrote:

Any ideas as to why "qemu-ppc64 crashes out immediately"?

I can confirm the build ends in a segfault when I tried building
gobject-introspection for the t1042d4rdb-64b machine.

*/[Luo Zhenhua-B19537] This is a gobject-introspection support issue of
QEMU PPC64, the fix is not available now, you can use the following
workaround to bypass the issue. /*

*/http://git.yoctoproject.org/cgit.cgi/meta-fsl-ppc/tree/README#n18/*


I'm afraid disabling introspection data is not an acceptable solution 
for Chris, because he does want to have that data.


Also, I'll send a fix to disable building of introspection data on all 
ppc64 machines for now.


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problems with cmake finding the c++ includes

[Flanagan, Elizabeth]

On 27 April 2016 at 03:12, Paul Eggleton  wrote:
> On Tue, 26 Apr 2016 09:39:26 Burton, Ross wrote:
>> > SUMMARY = "g3log"
>> > SECTION = "sek4"
>> > LICENSE = "MIT"
>> > LIC_FILES_CHKSUM = "file://$
>> > {COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> This appears to be the Unlicense [1]. It's worth noting that we seem to be
> missing this in our common licenses, though it's listed by SPDX [2]. As an
> aside, maybe it's time for us to bring in new license files from SPDX if there
> are any others like this?

Ross and I were discussing an update for this. There are a lot of new
SPDX licenses and I want a day or so with this patch I'm working on
because enough has changed I don't want any breakage.

-b

>
>> This should point to the LICENSE file in the clone, and that license file
>> doesn't say MIT.
>>
>> > DEPENDS ="boost"
>
> I don't think this is correct - at least I can't see any sign upstream that it
> needs boost. It even claims that it needs no external libraries.
>
> Cheers,
> Paul
>
> [1] http://unlicense.org/
> [2] https://spdx.org/licenses/Unlicense.html
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Manipulating code and Building in offline environment

[Gary Thomas]

On 2016-04-27 13:38, Lars Larsen wrote:

Hello

I have 2 questions

I have finally managed to build an image like I want it.


I consists of a kernel.

The ROS framework.

And our proprietary software under git control


What I want to achieve is the following:

When online it should fetch the latest commit (or what ever branch/tag) from 
our git repo.

It should be possible to take a laptop with a fresh checkout of all the 
software, go to the field where the is NO
INTERNET access, and be able to patch our code on the spot ,and build fresh 
images, for the target.

When online in our office environment all our own software is correctly checked 
out from our git repo. and build.
Beautifully.

But when offline ( I disconnect the LAN ) I continually gets errors like 
“Failure expanding variable SRCPV” on our
software modules.

I have following in build/conf/local.conf


BB_GENERATE_MIRROR_TARBALLS = "1"

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = "file://${DL_DIR}"


and I experimented with BB_FETCH_PREMIRRORONLY = "1"

with no appearent effect


So question 1:

How do I achieve the offline building. ?

Is should be possible - right ?


Question 2:

Where in the tree is the checked out source code located, that bitbake compiles 
from.



I do this all the time successfully.

What is your target and what recipe(s) are having issues?

Note setting BB_NO_NETWORK = "1" in local.conf can help diagnose these issues


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Manipulating code and Building in offline environment

[Lars Larsen]

Hello

I have 2 questions

I have finally managed to build an image like I want it.


I consists of a kernel.

The ROS framework.

And our proprietary software under git control


What I want to achieve is the following:

When online it should fetch the latest commit (or what ever branch/tag) 
from our git repo.


It should be possible to take a laptop with a fresh checkout of all the 
software, go to the field where the is NO INTERNET access, and be able 
to patch our code on the spot ,and build fresh images, for the target.


When online in our office environment all our own software is correctly 
checked out from our git repo. and build. Beautifully.


But when offline ( I disconnect the LAN ) I continually gets errors like 
“Failure expanding variable SRCPV” on our software modules.


I have following in build/conf/local.conf


BB_GENERATE_MIRROR_TARBALLS = "1"

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = "file://${DL_DIR}"


and I experimented with BB_FETCH_PREMIRRORONLY = "1"

with no appearent effect


So question 1:

How do I achieve the offline building. ?

Is should be possible - right ?


Question 2:

Where in the tree is the checked out source code located, that bitbake 
compiles from.




Kind regards

Lars Larsen


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

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Burton, Ross]

On 27 April 2016 at 10:07, Chris Trobridge 
wrote:

> pjproject hasn't been touched for 6 years and has some custom steps I
> don't understand (
> https://github.com/openembedded/openembedded/tree/master/recipes/pjproject
> ).
>
> asterisk (
> https://github.com/openembedded/openembedded/tree/master/recipes/asterisk)
> is simarly out of date on openembedded, although there is also asterisk in
> meta-telephony (
> https://github.com/sysmocom/meta-telephony/tree/master/recipes-asterisk/asterisk)
> that is referenced.
>

I'm about to go and have lunch but I'll quickly say that the OE tree you're
linking to is unmaintained and has been for many years.  The asterisk in
meta-telephony is the one you should be looking at and ideally contributing
too.

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

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

Regarding:
"Can you shine any light on the "-fdebug-prefix-map" related fatal QA errors?  
(leaking host paths) I've found some discussion in openembedded that suggests 
this should be fixed in the compiler but again I am curious why this (very 
simple) recipe has this issue but others don't."
So DEBUG_FLAGS was changed recently but setting back to  "-g 
-feliminate-unused-debug-types" avoids this issue.
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eudev hwdb?

[Martin Jansa]

On Wed, Apr 27, 2016 at 10:48:03AM +0200, Gary Thomas wrote:
> I see that the replacement for udev (eudev) in OE-core takes nearly
> 12MB on my i.MX6 (ARM CortexA7).  This is nearly 25% of my total
> storage space (64MB NAND)!

See
http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/77244
and following discussions

> 
> # ls -lR /etc/udev
> /etc/udev:
> total 6520
> -rw-r--r-- 1 root root1600 Jan  1  1970 cache.data
> -r--r--r-- 1 root root 6660476 Apr 26 13:08 hwdb.bin
> drwxr-xr-x 2 root root1296 Apr 26 11:34 hwdb.d
> -rw-r--r-- 1 root root  51 Apr 26 11:31 mount.blacklist
> drwxr-xr-x 2 root root 160 Apr 26 11:35 mount.blacklist.d
> drwxr-xr-x 2 root root 608 Apr 26 13:08 rules.d
> drwxr-xr-x 2 root root 304 Apr 26 11:35 scripts
> -rw-r--r-- 1 root root  49 Apr 26 11:34 udev.conf
> 
> /etc/udev/hwdb.d:
> total 5224
> -rw-r--r-- 1 root root 1292931 Apr 26 11:34 20-OUI.hwdb
> -rw-r--r-- 1 root root  126596 Apr 26 11:34 20-acpi-vendor.hwdb
> -rw-r--r-- 1 root root   41289 Apr 26 11:34 20-bluetooth-vendor-product.hwdb
> -rw-r--r-- 1 root root 111 Apr 26 11:34 20-net-ifname.hwdb
> -rw-r--r-- 1 root root   13710 Apr 26 11:34 20-pci-classes.hwdb
> -rw-r--r-- 1 root root 2648842 Apr 26 11:34 20-pci-vendor-model.hwdb
> -rw-r--r-- 1 root root 783 Apr 26 11:34 20-sdio-classes.hwdb
> -rw-r--r-- 1 root root4067 Apr 26 11:34 20-sdio-vendor-model.hwdb
> -rw-r--r-- 1 root root8070 Apr 26 11:34 20-usb-classes.hwdb
> -rw-r--r-- 1 root root 1113001 Apr 26 11:34 20-usb-vendor-model.hwdb
> -rw-r--r-- 1 root root3702 Apr 26 11:34 60-evdev.hwdb
> -rw-r--r-- 1 root root   52967 Apr 26 11:34 60-keyboard.hwdb
> -rw-r--r-- 1 root root   14217 Apr 26 11:34 70-mouse.hwdb
> -rw-r--r-- 1 root root4627 Apr 26 11:34 70-pointingstick.hwdb
> 
> /etc/udev/mount.blacklist.d:
> total 0
> 
> /etc/udev/rules.d:
> total 20
> -rw-r--r-- 1 root root 1449 Apr 26 11:31 10-imx.rules
> -rw-r--r-- 1 root root0 Apr 26 11:34 80-net-name-slot.rules
> -rw-r--r-- 1 root root  847 Apr 26 11:31 automount.rules
> -rw-r--r-- 1 root root  757 Apr 26 11:31 autonet.rules
> -rw-r--r-- 1 root root  885 Apr 26 11:34 local.rules
> -rw-r--r-- 1 root root  843 Apr 26 11:31 localextra.rules
> 
> /etc/udev/scripts:
> total 8
> -rwxr-xr-x 1 root root 2469 Apr 26 11:31 mount.sh
> -rwxr-xr-x 1 root root 1402 Apr 26 11:31 network.sh
> 
> Is there any way to not have both the hwdb.bin (which I assume
> is a binary version of the hardware databases) and /etc/udev/hwdb.d?
> Perhaps there is some way to only use one?
> 
> Or maybe there is a better choice, such as mdev?  I'm not sure about
> this (no experience) but my system needs to handle plug devices
> which the current eudev does well.  It's just a huge "price" to pay.
> 
> Any ideas or pointers would be great
> 
> -- 
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eudev hwdb?

[Gary Thomas]

On 2016-04-27 10:59, Burton, Ross wrote:


On 27 April 2016 at 09:48, Gary Thomas > wrote:

Is there any way to not have both the hwdb.bin (which I assume
is a binary version of the hardware databases) and /etc/udev/hwdb.d?
Perhaps there is some way to only use one?

Or maybe there is a better choice, such as mdev?  I'm not sure about
this (no experience) but my system needs to handle plug devices
which the current eudev does well.  It's just a huge "price" to pay.


You could not install hwdb at all, it's a recommends so you can BAD_RECOMMENDS 
it away.  It's certainly possible to wipe
away the source files for hwdb if you don't care about extending them at 
runtime but nobody has done that yet: a rootfs
postproccess hook could delete it and confirm that everything works fine.


Can you explain a bit more? - BAD_RECOMMENDS doesn't seem to be documented.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

Thanks Ross,
I have added "EXTRA_OECONF += "--enable-shared", as asterisk needs shared 
libraries: these don't get the suffix and asterisk builds fine.
I am still getting a whole slew of host contamination warnings, eg "pjproject: 
/pjproject-staticdev/usr/lib/libpjsua-x86_64-poky-linux-gnu.a is owned by uid 
1000, which is the same as the user running bitbake. This may be due to host 
contamination".  I can find some references to this happening in release tests 
but not how it was fixed.
Can you shine any light on the "-fdebug-prefix-map" related fatal QA errors?  
(leaking host paths) I've found some discussion in openembedded that suggests 
this should be fixed in the compiler but again I am curious why this (very 
simple) recipe has this issue but others don't.
The only 'odd' thing I've need to do is add "do_configure_prepend() { LD=$CXX }
If I get these recipes (asterisk/pjproject) to an acceptable level I could 
propose them (back) into openembedded?
pjproject hasn't been touched for 6 years and has some custom steps I don't 
understand 
(https://github.com/openembedded/openembedded/tree/master/recipes/pjproject).
asterisk 
(https://github.com/openembedded/openembedded/tree/master/recipes/asterisk) is 
simarly out of date on openembedded, although there is also asterisk in 
meta-telephony 
(https://github.com/sysmocom/meta-telephony/tree/master/recipes-asterisk/asterisk)
 that is referenced.
'My' asterisk recipe is based on the one from meta-telephony so I should get in 
touch with the authors.
Regards,Chris
From: ross.bur...@intel.com
Date: Wed, 27 Apr 2016 08:41:14 +0100
Subject: Re: [yocto] Build Errors with new recipe for pjproject 
(autotools/pkgconfig)
To: christrobri...@hotmail.com
CC: yocto@yoctoproject.org


On 27 April 2016 at 07:27, Chris Trobridge  wrote:
Aside from the issues I mentioned previously, pjproject is detecting 
cross-compilation and this causes it to append '-x86_64-poky-linux-gnu' to all 
its library names.
This is then breaking autotools configuration in other recipes that are testing 
for the base name.
Is it common for a build process to differentiate cross compiled libraries like 
this?  Is there a preferred way to deal with it?
No, that's rather unusual.  Typically you'd just have a different libdir per 
architecture.
Ross  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eudev hwdb?

[Yegor Yefremov]

Hi Gary,

On Wed, Apr 27, 2016 at 10:48 AM, Gary Thomas  wrote:
> I see that the replacement for udev (eudev) in OE-core takes nearly
> 12MB on my i.MX6 (ARM CortexA7).  This is nearly 25% of my total
> storage space (64MB NAND)!
>
> # ls -lR /etc/udev
> /etc/udev:
> total 6520
> -rw-r--r-- 1 root root1600 Jan  1  1970 cache.data
> -r--r--r-- 1 root root 6660476 Apr 26 13:08 hwdb.bin
> drwxr-xr-x 2 root root1296 Apr 26 11:34 hwdb.d
> -rw-r--r-- 1 root root  51 Apr 26 11:31 mount.blacklist
> drwxr-xr-x 2 root root 160 Apr 26 11:35 mount.blacklist.d
> drwxr-xr-x 2 root root 608 Apr 26 13:08 rules.d
> drwxr-xr-x 2 root root 304 Apr 26 11:35 scripts
> -rw-r--r-- 1 root root  49 Apr 26 11:34 udev.conf
>
> /etc/udev/hwdb.d:
> total 5224
> -rw-r--r-- 1 root root 1292931 Apr 26 11:34 20-OUI.hwdb
> -rw-r--r-- 1 root root  126596 Apr 26 11:34 20-acpi-vendor.hwdb
> -rw-r--r-- 1 root root   41289 Apr 26 11:34 20-bluetooth-vendor-product.hwdb
> -rw-r--r-- 1 root root 111 Apr 26 11:34 20-net-ifname.hwdb
> -rw-r--r-- 1 root root   13710 Apr 26 11:34 20-pci-classes.hwdb
> -rw-r--r-- 1 root root 2648842 Apr 26 11:34 20-pci-vendor-model.hwdb
> -rw-r--r-- 1 root root 783 Apr 26 11:34 20-sdio-classes.hwdb
> -rw-r--r-- 1 root root4067 Apr 26 11:34 20-sdio-vendor-model.hwdb
> -rw-r--r-- 1 root root8070 Apr 26 11:34 20-usb-classes.hwdb
> -rw-r--r-- 1 root root 1113001 Apr 26 11:34 20-usb-vendor-model.hwdb
> -rw-r--r-- 1 root root3702 Apr 26 11:34 60-evdev.hwdb
> -rw-r--r-- 1 root root   52967 Apr 26 11:34 60-keyboard.hwdb
> -rw-r--r-- 1 root root   14217 Apr 26 11:34 70-mouse.hwdb
> -rw-r--r-- 1 root root4627 Apr 26 11:34 70-pointingstick.hwdb
>
> /etc/udev/mount.blacklist.d:
> total 0
>
> /etc/udev/rules.d:
> total 20
> -rw-r--r-- 1 root root 1449 Apr 26 11:31 10-imx.rules
> -rw-r--r-- 1 root root0 Apr 26 11:34 80-net-name-slot.rules
> -rw-r--r-- 1 root root  847 Apr 26 11:31 automount.rules
> -rw-r--r-- 1 root root  757 Apr 26 11:31 autonet.rules
> -rw-r--r-- 1 root root  885 Apr 26 11:34 local.rules
> -rw-r--r-- 1 root root  843 Apr 26 11:31 localextra.rules
>
> /etc/udev/scripts:
> total 8
> -rwxr-xr-x 1 root root 2469 Apr 26 11:31 mount.sh
> -rwxr-xr-x 1 root root 1402 Apr 26 11:31 network.sh
>
> Is there any way to not have both the hwdb.bin (which I assume
> is a binary version of the hardware databases) and /etc/udev/hwdb.d?
> Perhaps there is some way to only use one?
>
> Or maybe there is a better choice, such as mdev?  I'm not sure about
> this (no experience) but my system needs to handle plug devices
> which the current eudev does well.  It's just a huge "price" to pay.
>
> Any ideas or pointers would be great

eudev provides following configure option:

 --enable-hwdb  install hwdb.d files

this way you can omit hwdb.d installation by providing:

--disable-hwdb

Yegor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eudev hwdb?

[Burton, Ross]

On 27 April 2016 at 09:48, Gary Thomas  wrote:

> Is there any way to not have both the hwdb.bin (which I assume
> is a binary version of the hardware databases) and /etc/udev/hwdb.d?
> Perhaps there is some way to only use one?
>
> Or maybe there is a better choice, such as mdev?  I'm not sure about
> this (no experience) but my system needs to handle plug devices
> which the current eudev does well.  It's just a huge "price" to pay.
>

You could not install hwdb at all, it's a recommends so you can
BAD_RECOMMENDS it away.  It's certainly possible to wipe away the source
files for hwdb if you don't care about extending them at runtime but nobody
has done that yet: a rootfs postproccess hook could delete it and confirm
that everything works fine.

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

Re: [yocto] [OE-core] [RFT] GCC 6 Recipes

[Burton, Ross]

Finally made errors.yp do the right thing:
http://errors.yoctoproject.org/Errors/Latest/?filter=91ef7bf5ad13304827e2ef06738f7fc28ed650f6=commit
is a list of all the failures.

Ross

On 27 April 2016 at 09:02, Burton, Ross  wrote:

>
> On 21 April 2016 at 04:06, Khem Raj  wrote:
>
>> I have updated
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-6
>>
>> With few more patches added now. Most of packages in OE-Core are
>> building fine except linux-yocto on mips and ppc
>>
>
> I threw this at the autobuilder.  Lots of c++ failures on various
> architectures.
>
> https://autobuilder.yoctoproject.org/main/tgrid, the row for SHA 91ef.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] eudev hwdb?

[Gary Thomas]

I see that the replacement for udev (eudev) in OE-core takes nearly
12MB on my i.MX6 (ARM CortexA7).  This is nearly 25% of my total
storage space (64MB NAND)!

# ls -lR /etc/udev
/etc/udev:
total 6520
-rw-r--r-- 1 root root1600 Jan  1  1970 cache.data
-r--r--r-- 1 root root 6660476 Apr 26 13:08 hwdb.bin
drwxr-xr-x 2 root root1296 Apr 26 11:34 hwdb.d
-rw-r--r-- 1 root root  51 Apr 26 11:31 mount.blacklist
drwxr-xr-x 2 root root 160 Apr 26 11:35 mount.blacklist.d
drwxr-xr-x 2 root root 608 Apr 26 13:08 rules.d
drwxr-xr-x 2 root root 304 Apr 26 11:35 scripts
-rw-r--r-- 1 root root  49 Apr 26 11:34 udev.conf

/etc/udev/hwdb.d:
total 5224
-rw-r--r-- 1 root root 1292931 Apr 26 11:34 20-OUI.hwdb
-rw-r--r-- 1 root root  126596 Apr 26 11:34 20-acpi-vendor.hwdb
-rw-r--r-- 1 root root   41289 Apr 26 11:34 20-bluetooth-vendor-product.hwdb
-rw-r--r-- 1 root root 111 Apr 26 11:34 20-net-ifname.hwdb
-rw-r--r-- 1 root root   13710 Apr 26 11:34 20-pci-classes.hwdb
-rw-r--r-- 1 root root 2648842 Apr 26 11:34 20-pci-vendor-model.hwdb
-rw-r--r-- 1 root root 783 Apr 26 11:34 20-sdio-classes.hwdb
-rw-r--r-- 1 root root4067 Apr 26 11:34 20-sdio-vendor-model.hwdb
-rw-r--r-- 1 root root8070 Apr 26 11:34 20-usb-classes.hwdb
-rw-r--r-- 1 root root 1113001 Apr 26 11:34 20-usb-vendor-model.hwdb
-rw-r--r-- 1 root root3702 Apr 26 11:34 60-evdev.hwdb
-rw-r--r-- 1 root root   52967 Apr 26 11:34 60-keyboard.hwdb
-rw-r--r-- 1 root root   14217 Apr 26 11:34 70-mouse.hwdb
-rw-r--r-- 1 root root4627 Apr 26 11:34 70-pointingstick.hwdb

/etc/udev/mount.blacklist.d:
total 0

/etc/udev/rules.d:
total 20
-rw-r--r-- 1 root root 1449 Apr 26 11:31 10-imx.rules
-rw-r--r-- 1 root root0 Apr 26 11:34 80-net-name-slot.rules
-rw-r--r-- 1 root root  847 Apr 26 11:31 automount.rules
-rw-r--r-- 1 root root  757 Apr 26 11:31 autonet.rules
-rw-r--r-- 1 root root  885 Apr 26 11:34 local.rules
-rw-r--r-- 1 root root  843 Apr 26 11:31 localextra.rules

/etc/udev/scripts:
total 8
-rwxr-xr-x 1 root root 2469 Apr 26 11:31 mount.sh
-rwxr-xr-x 1 root root 1402 Apr 26 11:31 network.sh

Is there any way to not have both the hwdb.bin (which I assume
is a binary version of the hardware databases) and /etc/udev/hwdb.d?
Perhaps there is some way to only use one?

Or maybe there is a better choice, such as mdev?  I'm not sure about
this (no experience) but my system needs to handle plug devices
which the current eudev does well.  It's just a huge "price" to pay.

Any ideas or pointers would be great

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [OE-core] [RFT] GCC 6 Recipes

[Burton, Ross]

On 21 April 2016 at 04:06, Khem Raj  wrote:

> I have updated
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-6
>
> With few more patches added now. Most of packages in OE-Core are
> building fine except linux-yocto on mips and ppc
>

I threw this at the autobuilder.  Lots of c++ failures on various
architectures.

https://autobuilder.yoctoproject.org/main/tgrid, the row for SHA 91ef.

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

Re: [yocto] Strange dependency

[Burton, Ross]

On 27 April 2016 at 03:30, Paul Eggleton 
wrote:

> Looking at meta/recipes-devtools/qemu/qemu.inc it is explicitly looking at
> DISTRO_FEATURES for the native class. That seems wrong to me as well, but I
> would be surprised if it were the only place we were referring to
> DISTRO_FEATURES in the native context (especially implicitly - consider the
> defaults for PACKAGECONFIG in various recipes where we initialise it based
> on
> DISTRO_FEATURES and don't provide a special default for native). I guess
> it's
> something that someone will need to go through and clean up at some point.
>

Ah, that was a bit of cleanup I failed to do.  qemu.inc has a
PACKAGECONFIG_class-native to hardcode the options and not respect distro
features, but there were some dependencies that are picked based on
DISTRO_FEATURES.  This was a workaround for the previous odd linking, so
can be removed now.

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

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Burton, Ross]

On 27 April 2016 at 07:27, Chris Trobridge 
wrote:

> Aside from the issues I mentioned previously, pjproject is detecting
> cross-compilation and this causes it to append '-x86_64-poky-linux-gnu' to
> all its library names.
>
> This is then breaking autotools configuration in other recipes that are
> testing for the base name.
>
> Is it common for a build process to differentiate cross compiled libraries
> like this?  Is there a preferred way to deal with it?
>

No, that's rather unusual.  Typically you'd just have a different libdir
per architecture.

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

Re: [linux-yocto] fa3c776f1c47bd8cdbaaf1080420a67d4bfdc867 causing kernel stack corruption

[Yong, Jonathan]

On 04/27/2016 11:39, Yong, Jonathan wrote:

On 04/26/2016 20:52, Bruce Ashfield wrote:

On 2016-04-26 12:55 AM, Yong, Jonathan wrote:

Hi,

I'm seeing kernel stack corruptions in thermal_zone_device_register with
fa3c776f1c47bd8cdbaaf1080420a67d4bfdc867. After reviewing the patch, I'm
not see how it could cause a crash:



That's part of the -stable updates .. so that would be rare indeed
if it was the cause of the problem.

What board are you booting ? I'm not seeing any crashes in my test
boots.

Bruce


This happens on the Skylake Saddle Brook platform. I'm not seeing how it
could crash either, but I've replicated it with 2 clean kernel rebuilds
just to make sure all the modules are rebuilt with the new structure.
I'll be trying again soon to check if it is a compiler bug.

The kernel was also built with CC_STACKPROTECTOR_STRONG.



Changing compilers isn't helping either, weird.

--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

Aside from the issues I mentioned previously, pjproject is detecting 
cross-compilation and this causes it to append '-x86_64-poky-linux-gnu' to all 
its library names.
This is then breaking autotools configuration in other recipes that are testing 
for the base name.
Is it common for a build process to differentiate cross compiled libraries like 
this?  Is there a preferred way to deal with it?
I'm not confident about changing the pjproject build but I can link the base 
name to the extended name in do_install_append() so both names are present. 
pkgconfig picks up the extended names so these are also used in other recipes 
too (both forms of name in the same command line...).
Regards,Chris

From: christrobri...@hotmail.com
To: yocto@yoctoproject.org
Date: Tue, 26 Apr 2016 10:15:34 +0100
Subject: [yocto] Build Errors with new recipe for pjproject 
(autotools/pkgconfig)




I have been trying to formulate a new recipe for pjproject (pjsip) - there was 
one but it seems too old and isn't part of any layer now.
The library seems to require a fairly straightforward autotools/pkgconfig 
recipe but I get two errors, both of which I can see have come up before but 
haven't been answered satisfactorily.
The first is that the link stage fails with "x86_64-poky-linux-ld: unrecognized 
option '-Wl,-O1'".
I've found this answered as "tools being too old" but '-Wl,' is a gcc prefix to 
pass an option to the linker but the linker is being invoked directly and so 
this is really a configuration mismatch.  I can fix this with "LD=$CXX" in 
do_configure_prepend() but I am puzzled as to why autotools would get confused 
this way in the first place?
The second problem is possibly more recent: ERROR: pjproject-2.4.5-r0 
do_populate_sysroot: QA Issue: libpjproject.pc failed sanity test (tmpdir) in 
path 
/home/chris/yocto/build/tmp/work/corei7-64-poky-linux/pjproject/2.4.5-r0/sysroot-destdir/usr/lib/pkgconfig
 [pkgconfig]
I think this is benign other than leaking my dev environment but there was an 
oe gcc patch earlier this year that addressed this 
(http://lists.openembedded.org/pipermail/openembedded-core/2016-January/116468.html).
Apparently there was QA change the broke a lot of recipes but it's not clear 
how to fix this recipe - from what I could tell the fix should have applied to 
all recipes.  Adding '-gno-record-debug-prefix-map' should fix this but the 
compiler option is not recognised.
Any ideas on how to solve the QA error?
I am using the poky commit for 2.1_M4.rc1.
Thanks,Chris
  

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