Re: [yocto] PSA for anyone using openSUSE 42.2 (or similar)
On Fri, Dec 16, 2016 at 12:31 PM, Alexander Kanavin wrote: > Actually, scratch that; if bitbake can detect that the limit is not optimal > at runtime, then it probably should. Direct the bug accordingly. Bitbake can't possibly know how many builds you're going to spin up at any one time, and it can't take into consideration whether of not you set "parallel build" or "number of threads" settings on any of those builds. So when each bitbake starts it might look at the variable and say "that looks reasonable" but after starting the 3rd bitbake you end up with resource issues that fail a build that might otherwise muddle through. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.3_M1.rc1_M1.rc1 now available.
A release candidate build for yocto-2.3_M1.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 meta-intel : 466196fa2f619aa3d37ad6bfe13c11c72f910d16 meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f poky : 573c646d4cc62dcd0c230381df4940bdf314d495 \nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: git://git.yoctoproject.org/yocto-autobuilder\nEmail: joshua.g.l...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA Test Report for Yocto Project 2.0.3 rc6
Hi Here is the report for QA Cycle on 2.0.3 rc6 Full Report : https://wiki.yoctoproject.org/wiki/WW50_-_2016-12-09_-_QA_Cycle_2.0.3.rc6 Summary The QA cycle for 2.0.3 rc6 was completed, there were 4 new bugs found, One important issue related to ADT repo missing that was already triaged and the fix is under implementation, another issue that is not blocker related to parselogs that was already triaged and the solution is ongoing, two of the issues found were closed as won't fix due current NUC6 used to test is unsupported on versions before krogoth. There were also 4 bugs already found on newer releases that fix may be backported to jethro branch. In regards to performance measurements, is the first time that jethro branch is tested at GDC machines hence there is no previous data to compare with but in general all the values are in the same levels of the first measurements available for GDC machines that belongs to 2.1 M4 release. Bugs * New - 10786 - Missing adt repo for 2.0.3 build [1] - 10791 - failed to add i915 component master [2] - 10808 - [Test Case 191] LSB Image does not boot on NUC6i5 [3] - WONTFIX - 10809 - usb 1-1.2: device descriptor read/all, error -110 [4] - WONTFIX * Found on newer releases that may need to be backported - 7897 - Dmesg error BAR 14 and BAR 15 failed to assign in Minnow Max [5] - 9120 - The patch file is not applied to linux-yocto by yocto-kernel add patch command [6] - 9656 - NFS boot failed due No working init found kernel panic on qemu [7] - 10281 - Configuration variables: I can set a value for standard shell environment variable http_proxy [8] Performance -The is the first time that jethro branch was executed on GDC machines hence there is no previous data to compare, but compared to the first measurements present for current setup (2.1 M4) all the values are on the same levels -Charts can be found at https://wiki.yoctoproject.org/charts/perf_milestone_GDC/performance_test.html Links 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10786 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10791 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10808 4. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10809 5. https://bugzilla.yoctoproject.org/show_bug.cgi?id=7897 6. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9120 7. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9656 8. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10281 Regards, José -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/1] linux-rpi: clean .config in before do_configure step
On 16-12-16 17:58, Khem Raj wrote:
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
On Dec 15, 2016, at 2:05 AM, Piotr Lewicki wrote:
Signed-off-by: Piotr Lewicki
---
recipes-kernel/linux/linux-rpi.inc | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-rpi.inc
b/recipes-kernel/linux/linux-rpi.inc
index 95a9530..c665b9f 100644
--- a/recipes-kernel/linux/linux-rpi.inc
+++ b/recipes-kernel/linux/linux-rpi.inc
@@ -34,11 +34,13 @@ kernel_configure_variable() {
fi
}
-do_configure_prepend() {
+do_rpi_kconfig_clean() {
# Clean .config
-echo "" > ${B}/.config
+echo -n "" > ${B}/.config
CONF_SED_SCRIPT=""
+}
+do_configure_prepend() {
# oabi / eabi support
kernel_configure_variable AEABI y
if [ "${ARM_KEEP_OABI}" = "1" ] ; then
@@ -124,8 +126,11 @@ do_configure_prepend() {
# Keep this the last line
# Remove all modified configs and add the rest to .config
sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
+# Clean variable- useful when calling configure step multiple times
+CONF_SED_SCRIPT=""
yes '' | oe_runmake oldconfig
+
}
# Automatically depend on lzop-native if CONFIG_KERNEL_LZO is enabled
@@ -146,3 +151,5 @@ python () {
configfile.close()
}
+
+addtask rpi_kconfig_clean before do_configure after do_populate_lic
we should investigate the kernel tooling from OE-Core and use that IMO
See this thread on the OE list for a similar problem:
http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129205.html
--
Mike Looijmans
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PSA for anyone using openSUSE 42.2 (or similar)
On Fri, Dec 16, 2016 at 11:06 AM, Alexander Kanavin wrote: > On 12/16/2016 05:06 PM, Trevor Woerner wrote: >> >> I just made this adjustment but given it only happened once or twice a >> week on >> a reasonably busy build machine it might be hard to confirm. I'm also not >> sure >> if setting it to "infinity" is sensible ;-) >> >> I'm guessing other host distros probably also fall into this category. > > > I've seen this on Debian Testing as well. Care to submit a documentation > bug? > > https://bugzilla.yoctoproject.org/enter_bug.cgi?product=General%20Docs https://bugzilla.yoctoproject.org/show_bug.cgi?id=10818 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Reference doc displayed twice at yoctoproject.org/documentation/active
On 12/16/2016 05:21 AM, Daniel. wrote: Am I crazy or I'm seeing reference manual twice at https://www.yoctoproject.org/documentation/active ??? nope. the 2.1.1 release has the same issue. - armin Imagem inline 3 Regards, -- "Do or do not. There is no try" Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PSA for anyone using openSUSE 42.2 (or similar)
On 12/16/2016 06:06 PM, Alexander Kanavin wrote: On 12/16/2016 05:06 PM, Trevor Woerner wrote: I just made this adjustment but given it only happened once or twice a week on a reasonably busy build machine it might be hard to confirm. I'm also not sure if setting it to "infinity" is sensible ;-) I'm guessing other host distros probably also fall into this category. I've seen this on Debian Testing as well. Care to submit a documentation bug? https://bugzilla.yoctoproject.org/enter_bug.cgi?product=General%20Docs Actually, scratch that; if bitbake can detect that the limit is not optimal at runtime, then it probably should. Direct the bug accordingly. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] distutils break my shebang, what to do?
Well this is what I'm already doing, for target, nativesdk and native...
do_install_append() {
sed '1c\
#!/usr/bin/env python' -i ${D}${bindir}/myscript
}
Should I use do_install_class-nativesdk_append instead?
Regards,
2016-12-16 15:04 GMT-02:00 Khem Raj :
>
>> On Dec 15, 2016, at 5:49 PM, Daniel. wrote:
>>
>> Hi,
>>
>> I've been trying to install cxxtest to nativesdk. After done I went to
>> run`cxxtestgen` and got a "bad interpreter" error from bash. I look at
>> the script and there was "#! python" at first line.
>>
>> I know that this is something that distutils does. I also know that
>> SDK ships its own python interpreter. So what is the right way to
>> approach this problem?
>
> sed it out to right location when doing nativesdk build.
>
>>
>> Regards,
>>
>> --
>> "Do or do not. There is no try"
>> Yoda Master
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
--
"Do or do not. There is no try"
Yoda Master
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] distutils break my shebang, what to do?
> On Dec 15, 2016, at 5:49 PM, Daniel. wrote: > > Hi, > > I've been trying to install cxxtest to nativesdk. After done I went to > run`cxxtestgen` and got a "bad interpreter" error from bash. I look at > the script and there was "#! python" at first line. > > I know that this is something that distutils does. I also know that > SDK ships its own python interpreter. So what is the right way to > approach this problem? sed it out to right location when doing nativesdk build. > > Regards, > > -- > "Do or do not. There is no try" > Yoda Master > -- > ___ > 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] [prelink-cross][patch] Fix layout1 test on x86_64 x32.
Thank you. I've added this to the TODO set, and will hopefully have it (and the previous one) staged very soon. --Mark On 12/16/16 8:52 AM, Andrew Stubbs wrote: > Hi Mark, > > The layout1 test case currently fails for x32 because there is > insufficient address space for all the libraries. > > There's two ways to fix this: > > 1. Increase mmap_end such that there's more space. > > 2. Reduce max_page_size so that less space is wasted. > > I'm not sure what the implications of option 2 would be, so the attached > patch implements option 1. > > This still limits the number of possible libraries somewhat severely, > but it's more than enough to pass the layout1 test. > > Andrew > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/1] linux-rpi: clean .config in before do_configure step
> On Dec 15, 2016, at 2:05 AM, Piotr Lewicki wrote:
>
> Signed-off-by: Piotr Lewicki
> ---
> recipes-kernel/linux/linux-rpi.inc | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-rpi.inc
> b/recipes-kernel/linux/linux-rpi.inc
> index 95a9530..c665b9f 100644
> --- a/recipes-kernel/linux/linux-rpi.inc
> +++ b/recipes-kernel/linux/linux-rpi.inc
> @@ -34,11 +34,13 @@ kernel_configure_variable() {
> fi
> }
>
> -do_configure_prepend() {
> +do_rpi_kconfig_clean() {
> # Clean .config
> -echo "" > ${B}/.config
> +echo -n "" > ${B}/.config
> CONF_SED_SCRIPT=""
> +}
>
> +do_configure_prepend() {
> # oabi / eabi support
> kernel_configure_variable AEABI y
> if [ "${ARM_KEEP_OABI}" = "1" ] ; then
> @@ -124,8 +126,11 @@ do_configure_prepend() {
> # Keep this the last line
> # Remove all modified configs and add the rest to .config
> sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
> +# Clean variable- useful when calling configure step multiple times
> +CONF_SED_SCRIPT=""
>
> yes '' | oe_runmake oldconfig
> +
> }
>
> # Automatically depend on lzop-native if CONFIG_KERNEL_LZO is enabled
> @@ -146,3 +151,5 @@ python () {
>
> configfile.close()
> }
> +
> +addtask rpi_kconfig_clean before do_configure after do_populate_lic
we should investigate the kernel tooling from OE-Core and use that IMO
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PSA for anyone using openSUSE 42.2 (or similar)
On 12/16/2016 05:06 PM, Trevor Woerner wrote: I just made this adjustment but given it only happened once or twice a week on a reasonably busy build machine it might be hard to confirm. I'm also not sure if setting it to "infinity" is sensible ;-) I'm guessing other host distros probably also fall into this category. I've seen this on Debian Testing as well. Care to submit a documentation bug? https://bugzilla.yoctoproject.org/enter_bug.cgi?product=General%20Docs Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] PSA for anyone using openSUSE 42.2 (or similar)
Lately I've been seeing very intermittent, sporadic cases where a build will fail with something similar to: fork: Resource temporarily unavailable and nothing else wrong. Simply restarting the build causes it to succeed without incident. I had been seeing this, maybe, twice a week (on a build machine that builds most of the day as well as overnight with Jenkins jobs). I decided to investigate and found: http://unix.stackexchange.com/questions/253903/creating-threads-fails-with-resource-temporarily-unavailable-with-4-3-kernel which suggests the issue is a combination of - linux >= 4.3 - systemd >= 228 both of which are true when upgrading openSUSE from 42.1 (linux-4.1.36-41/210) to 42.2 (linux-4.4.36-8/228). The fix appears to be to modify the "DefaultTasksMax" systemd parameter (uncommenting it and setting it to "infinity"). On openSUSE 42.2 this is found in /etc/systemd/system.conf, then # systemctl daemon-reexec or reboot. I just made this adjustment but given it only happened once or twice a week on a reasonably busy build machine it might be hard to confirm. I'm also not sure if setting it to "infinity" is sensible ;-) I'm guessing other host distros probably also fall into this category. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [prelink-cross][patch] Fix layout1 test on x86_64 x32.
Hi Mark,
The layout1 test case currently fails for x32 because there is
insufficient address space for all the libraries.
There's two ways to fix this:
1. Increase mmap_end such that there's more space.
2. Reduce max_page_size so that less space is wasted.
I'm not sure what the implications of option 2 would be, so the attached
patch implements option 1.
This still limits the number of possible libraries somewhat severely,
but it's more than enough to pass the layout1 test.
Andrew
>From 6c8aec5590ba9ba93e6cbb458c34ead0481b0b7c Mon Sep 17 00:00:00 2001
From: Andrew Stubbs
Date: Fri, 16 Dec 2016 14:08:28 +
Subject: [PATCH] Fix x32 layout1 test.
2016-12-16 Andrew Stubbs
* src/arch-x86_64.c (PL_ARCH(x32)): Set mmap_end to 0x6000.
---
src/arch-x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/arch-x86_64.c b/src/arch-x86_64.c
index 6a97370..5c95f47 100644
--- a/src/arch-x86_64.c
+++ b/src/arch-x86_64.c
@@ -595,7 +595,7 @@ PL_ARCH(x32) = {
Also, if this guard area isn't too small, typically
even dlopened libraries will get the slots they desire. */
.mmap_base = 0x4100,
- .mmap_end = 0x5000,
+ .mmap_end = 0x6000,
.max_page_size = 0x20,
.page_size = 0x1000
};
--
2.8.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Reference doc displayed twice at yoctoproject.org/documentation/active
Am I crazy or I'm seeing reference manual twice at https://www.yoctoproject.org/documentation/active ??? [image: Imagem inline 3] Regards, -- "Do or do not. There is no try" Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get headers installed at target side of SDK?
Hey Burton! The headers are not in my image. Thank you a lot man! Regards, 2016-12-16 10:21 GMT-02:00 Burton, Ross : > > On 16 December 2016 at 02:54, Daniel. wrote: >> >> Then I tried to append packagegroup-sdk-target adding foo-dev to it >> but still I can't get the headers at the SDK. I'm building the SDK by >> building meta-toolchain and installing by executing the script >> generated at tmp/deploy/sdk. > > > Build a SDK by using bitbake my-image-name -c populate_sdk. > > This will build a SDK which contains the -dev packages for everything that > goes into your image. If you want headers that are not in your image > usually then you can add them to TOOLCHAIN_TARGET_TASK in the image recipe: > > TOOLCHAIN_TARGET_TASK_append = " libsomething.dev" > > Ross -- "Do or do not. There is no try" Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get headers installed at target side of SDK?
On 16 December 2016 at 02:54, Daniel. wrote: > Then I tried to append packagegroup-sdk-target adding foo-dev to it > but still I can't get the headers at the SDK. I'm building the SDK by > building meta-toolchain and installing by executing the script > generated at tmp/deploy/sdk. > Build a SDK by using bitbake my-image-name -c populate_sdk. This will build a SDK which contains the -dev packages for everything that goes into your image. If you want headers that are not in your image usually then you can add them to TOOLCHAIN_TARGET_TASK in the image recipe: TOOLCHAIN_TARGET_TASK_append = " libsomething.dev" Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/1] linux-rpi: clean .config in before do_configure step
Previously using bbappend files for linux-raspberrypi recipe did not allow to
use "kernel_configure_variable" function to set kernel config variables.
If user wanted to use it in his bbappend with "do_configure_prepend" it was
cleared afterwards. This patch moves cleaning to a separate step.
I'm unsure about whether CONF_SED_SCRIPT variable gets cleaned here. Please
verify this.
Signed-off-by: Piotr Lewicki
---
recipes-kernel/linux/linux-rpi.inc | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-rpi.inc
b/recipes-kernel/linux/linux-rpi.inc
index 95a9530..c665b9f 100644
--- a/recipes-kernel/linux/linux-rpi.inc
+++ b/recipes-kernel/linux/linux-rpi.inc
@@ -34,11 +34,13 @@ kernel_configure_variable() {
fi
}
-do_configure_prepend() {
+do_rpi_kconfig_clean() {
# Clean .config
-echo "" > ${B}/.config
+echo -n "" > ${B}/.config
CONF_SED_SCRIPT=""
+}
+do_configure_prepend() {
# oabi / eabi support
kernel_configure_variable AEABI y
if [ "${ARM_KEEP_OABI}" = "1" ] ; then
@@ -124,8 +126,11 @@ do_configure_prepend() {
# Keep this the last line
# Remove all modified configs and add the rest to .config
sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
+# Clean variable- useful when calling configure step multiple times
+CONF_SED_SCRIPT=""
yes '' | oe_runmake oldconfig
+
}
# Automatically depend on lzop-native if CONFIG_KERNEL_LZO is enabled
@@ -146,3 +151,5 @@ python () {
configfile.close()
}
+
+addtask rpi_kconfig_clean before do_configure after do_populate_lic
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] live" image: iso and ext4 artifacts
On 15 December 2016 at 09:30, Takashi Matsuzawa wrote: > > Hello Yocto. > > I am trying x86-64 BSP image (based on jethro version). > It has following root filesystem type, and it generats .hddimg file that I am using. > > > IMAGE_FSTYPES = "live" > > The issue is that in addition to .hddimg, it produces following image files and it sometimes cause lack of disk space error on my build PC. > > > 2422489088 -intel-corei7-64-20161215004421.hddimg > > 2402287616 -intel-corei7-64-20161215004421.iso > > 2368578560 -intel-corei7-64-20161215004421.rootfs.ext4 > > I do not need xxx.iso and .ext4 files as final output, though I understand that .ext4 file may have been used to produce xxx.hddimg file. I think you should be able to define NOISO=1. The rootfs is indeed used to produce the actual images, you could delete it afterwards... but before you spend valuable time writing shell scripts, consider a new SSD: 500GB is probably less than 150€ by now. Jussi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v1] u-boot/beaglebone: Select Beaglebone Black target specifically.
Oops, I should have submitted this to the poky list. My bad.
--
Kristian
On 16/12/16 07:58, Kristian Amlie wrote:
> The am335x_evm_config target has a subtle problem which is not present
> in the am335x_boneblack_config target: When booting from an external
> MMC card, the internal MMC is not accessible using the former target.
>
> This problem was introduced in U-Boot in commit 80b24fcd3083515e6b961,
> due to the addition of the CONFIG_DM_MMC option, and the
> am335x_boneblack_config target does not have this problem.
>
> Signed-off-by: Kristian Amlie
> ---
> meta-yocto-bsp/conf/machine/beaglebone.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf
> b/meta-yocto-bsp/conf/machine/beaglebone.conf
> index fc6a527..24a95b4 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> @@ -31,7 +31,7 @@ KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
>
> SPL_BINARY = "MLO"
> UBOOT_SUFFIX = "img"
> -UBOOT_MACHINE = "am335x_evm_config"
> +UBOOT_MACHINE = "am335x_boneblack_config"
> UBOOT_ENTRYPOINT = "0x80008000"
> UBOOT_LOADADDRESS = "0x80008000"
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
