Re: [yocto] Morty 2.2.1 build failure
On 22 March 2017 at 22:23, Greg Wilson-Lindberg wrote: > Hi Armin, et al, > > I tried it again this morning and it did get past the file not found > error. But when it gets above step 4000 somewhere it gets an error that > kills not just the yocto build but the full login session. I'm left staring > at the Linux Login screen. I originally saw this problem with a git clone > of 16.0.0, and figured it was a git problem, tried building from a download > of the 16.0.1 bz2 file when I ran into the file not found error. > The "file" git repo was broken twice in the past week but current poky master branch (current commit 49c2df5652d2) and morty branch (current commit e292e935b077) do fetch it correctly at the time of writing. Personally I recommend not using the tarball releases: stick to git branches (and remember to pull once in a while) as they are likely to get fixes to issues like these faster. HTH, Jussi > > At this point I'm not sure what I can pass on to the list to help find the > bug, if there are some switches that I can set to get more debug info, or > maybe something is already saved that I can send that will help? > > Regards, > Greg > > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of akuster808 > > Sent: Tuesday, March 21, 2017 7:07 PM > > To: yocto@yoctoproject.org > > Subject: Re: [yocto] Morty 2.2.1 build failure > > > > > > Greg, > > > > On 03/21/2017 04:29 PM, Greg Wilson-Lindberg wrote: > > > Hello List, > > > > > > I got a copy of the book "Embedded Linux Systems with the Yocto > Project" > > at the SCALE 15x conference and this prompted me to try building the > Yocto > > Poky build before getting the Boot to Qt Yocto build environment. > > > > > > I tried building on 2 x86 systems, a 64 bit system at work and a 32 > bit system > > at my home, both failed in the same way: > > > > > > gwilson 11:06:54:~/yocto/poky-morty-16.0.1$ source ./oe-init-build-env > > > You had no conf/local.conf file. This configuration file has therefore > > > been created for you with some default values. You may wish to edit it > > > to, for example, select a different MACHINE (target hardware). See > > > conf/local.conf for more information as common configuration options > are > > commented. > > > > > > You had no conf/bblayers.conf file. This configuration file has > > > therefore been created for you with some default values. To add > > > additional metadata layers into your configuration please add entries > to > > conf/bblayers.conf. > > > > > > The Yocto Project has extensive documentation about OE including a > > > reference manual which can be found at: > > > http://yoctoproject.org/documentation > > > > > > For more information about OpenEmbedded see their website: > > > http://www.openembedded.org/ > > > > > > > > > ### Shell environment set up for builds. ### > > > > > > You can now run 'bitbake ' > > > > > > Common targets are: > > > core-image-minimal > > > core-image-sato > > > meta-toolchain > > > meta-ide-support > > > > > > You can also run generated qemu images with a command like 'runqemu > > qemux86' > > > gwilson 11:07:08:~/yocto/poky-morty-16.0.1/build$ > > > gwilson 11:07:10:~/yocto/poky-morty-16.0.1/build$ > > > gwilson 11:07:11:~/yocto/poky-morty-16.0.1/build$ bitbake > > > core-image-sato Parsing recipes: 100% > > > > > |# > > ###| Time: 0:00:29 Parsing of 864 > > .bb files complete (0 cached, 864 parsed). 1318 targets, 50 skipped, 0 > masked, > > 0 errors. > > > NOTE: Resolving any missing task queue dependencies > > > > > > Build Configuration: > > > BB_VERSION= "1.32.0" > > > BUILD_SYS = "x86_64-linux" > > > NATIVELSBSTRING = "Ubuntu-14.04" > > > TARGET_SYS= "i586-poky-linux" > > > MACHINE = "qemux86" > > > DISTRO= "poky" > > > DISTRO_VERSION= "2.2.1" > > > TUNE_FEATURES = "m32 i586" > > > TARGET_FPU= "" > > > meta > > > meta-poky > > > meta-yocto-bsp= ":" > > > > > > NOTE: Fetching uninative binary shim from > > > http://downloads.yoctoproject.org/releases/uninative/1.4/x86_64-native > > > sdk- > > libc.tar.bz2;sha256sum=101ff8f2580c193488db9e76f9646fb6ed38b65fb76 > > > f403acb0e2178ce7127ca > > > --2017-03-20 11:07:57-- > > > http://downloads.yoctoproject.org/releases/uninative/1.4/x86_64-native > > > sdk-libc.tar.bz2 Resolving downloads.yoctoproject.org > > > (downloads.yoctoproject.org)... 198.145.20.127 Connecting to > > > downloads.yoctoproject.org > > (downloads.yoctoproject.org)|198.145.20.127|:80... connected. > > > HTTP request sent, awaiting response... 200 OK > > > Length: 2473216 (2.4M) [application/octet-stream] Saving to: > > > '/home/gwilson/yocto/poky-morty- > > 16.0.1/build/downloads/uninative/101ff8f2580c193488db9e76f9646fb6ed38b > > 65fb76f403acb0e2178ce7127ca/x86_64-nativesdk-libc.tar.bz2' > >
[yocto] ERROR: libreoffice-5.0.5.2-r0 do_package
Hi Everybody,
I am trying to build the libreoffice packages, but i am getting following
errors.
*ERROR: libreoffice-5.0.5.2-r0 do_package: QA Issue: File
'/usr/lib/libreoffice/share/extensions/mysql-connector-ooo/libmysqlclient_r.so'
from libreoffice was already stripped, this will prevent future debugging!
[already-stripped]*
WARNING: libreoffice-5.0.5.2-r0 do_package: libreoffice language file
pattern not found: /usr/lib/libreoffice/share/template/%{1}
*ERROR: libreoffice-5.0.5.2-r0 do_package: Fatal QA errors found, failing
task.ERROR: libreoffice-5.0.5.2-r0 do_package: Function failed:
do_packageERROR: Logfile of failure stored in:
/home/kamama-yocto/yocto/poky/build/tmp/work/cortexa15hf-neon-poky-linux-gnueabi/libreoffice/5.0.5.2-r0/temp/log.do_package.23588*
*ERROR: Task
(/home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice/libreoffice/libreoffice.bb:do_package)
failed with exit code '1'*
NOTE: Tasks Summary: Attempted 8443 tasks of which 8385 didn't need to be
rerun and 1 failed.
Summary: 1 task failed:
/home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice/libreoffice/libreoffice.bb:
do_package
Summary: There were 2 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
what is the issue and how to solve this ?
Best Regards,
Ravikiran
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Morty 2.2.1 build failure
On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg wrote: > I tried it again this morning and it did get past the file not found error. > But when it gets above step 4000 somewhere it gets an error that kills not > just the yocto build but the full login session. I'm left staring at the > Linux Login screen. Your machine isn't running out of RAM by any chance, triggering the OOM killer? Anything indicative in your system logs? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] should a BSP layer *really* ever need additional layers to be functional?
perusing current BSP Guide: "Some BSPs require additional layers on top of the BSP's root layer in order to be functional. For these cases, you also need to add those layers to the BBLAYERS variable in order to build the BSP." really? should a properly-designed BSP layer need additional layers to simply boot a simple image (say, core-image-minimal) to the command line? i always thought that using nothing more than a BSP layer (plus, of course, the underlying OE layers) should allow you to get to the command line. is that not true? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] BSP guide: better example for recursive layer structure than meta-intel?
pretty sure i asked this before, but again in BSP Guide: "Some layers function as a layer to hold other BSP layers. An example of this type of layer is the meta-intel layer, which contains a number of individual BSP sub-layers, as well as a directory named common/ full of common content across those layers. Another example is the meta-yocto-bsp layer mentioned earlier." um ... both of those claims are false. meta-intel *used* to have a multi-layer structure, but not so much anymore. is there a better example for that? and meta-yocto-bsp is, of course, just a simple layer, nothing recursive about it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should a BSP layer *really* ever need additional layers to be functional?
Hi, On 23.03.2017 11:35, Robert P. J. Day wrote: i always thought that using nothing more than a BSP layer (plus, of course, the underlying OE layers) should allow you to get to the command line. is that not true? I don't think that this generally holds true, as it would lead to significant duplication. Imagine a board based off something already in meta-ti or meta-intel. And maybe just needing a slightly modified bootloader. Greetz, -- Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] should a BSP layer *really* ever need additional layers to be functional?
On Thu, 23 Mar 2017, Josef Holzmayr wrote: > Hi, > > On 23.03.2017 11:35, Robert P. J. Day wrote: > > i always thought that using nothing more than a BSP layer (plus, of > > course, the underlying OE layers) should allow you to get to the > > command line. is that not true? > > I don't think that this generally holds true, as it would lead to > significant duplication. Imagine a board based off something already > in meta-ti or meta-intel. And maybe just needing a slightly modified > bootloader. true, but the wording in the BSP Guide is: "Some BSPs require additional layers on top of the BSP's root layer in ^ order to be functional. " that particular phrasing suggests that perhaps what's needed is more user space content of some kind. perhaps rewording that to say that a BSP layer might be based on top of other layers as a starting point would be clearer. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] tpm2.0-tss: install resourcemgr service
Install systemd resource.mgr service and it needed user/group.
Signed-off-by: Benjamin Gaignard
---
.../tpm2.0-tss/change-resourcemgr-location.patch | 23 ++
recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb | 22 ++---
2 files changed, 42 insertions(+), 3 deletions(-)
create mode 100644
recipes-tpm/tpm2.0-tss/tpm2.0-tss/change-resourcemgr-location.patch
diff --git
a/recipes-tpm/tpm2.0-tss/tpm2.0-tss/change-resourcemgr-location.patch
b/recipes-tpm/tpm2.0-tss/tpm2.0-tss/change-resourcemgr-location.patch
new file mode 100644
index 000..ba3775a
--- /dev/null
+++ b/recipes-tpm/tpm2.0-tss/tpm2.0-tss/change-resourcemgr-location.patch
@@ -0,0 +1,23 @@
+resourcemgr: change resourcemgr location
+
+Signed-off-by: Benjamin Gaignard
+---
+ contrib/resourcemgr.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/contrib/resourcemgr.service b/contrib/resourcemgr.service
+index 7f23739..e5b0900 100644
+--- a/contrib/resourcemgr.service
b/contrib/resourcemgr.service
+@@ -3,7 +3,7 @@ Description=TPM2 resource manager & access broker
+ Documentation=http://www.github.com/01org/TPM2.0-TSS
+
+ [Service]
+-ExecStart=/usr/local/sbin/resourcemgr
++ExecStart=/usr/sbin/resourcemgr
+ StandardOutput=null
+ User=tss
+ Group=tss
+--
+1.9.1
+
diff --git a/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
b/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
index a03559c..96b3d72 100644
--- a/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
+++ b/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
@@ -8,9 +8,10 @@ SRCREV = "8e25d0cbb287d30c93b2b77e99bc761dc67e31a9"
SRC_URI = " \
git://github.com/01org/TPM2.0-TSS.git;protocol=git;branch=master;name=TPM2.0-TSS;destsuffix=TPM2.0-TSS
\
file://ax_pthread.m4 \
-file://fix_musl_select_include.patch "
+file://fix_musl_select_include.patch \
+file://change-resourcemgr-location.patch "
-inherit autotools pkgconfig
+inherit autotools pkgconfig systemd
S = "${WORKDIR}/${@d.getVar('BPN',d).upper()}"
@@ -24,6 +25,21 @@ do_configure_prepend () {
cd $currentdir
}
+INHERIT += "extrausers"
+EXTRA_USERS_PARAMS = "\
+ useradd -p '' tss; \
+ groupadd tss; \
+ "
+
+SYSTEMD_PACKAGES += "resourcemgr"
+SYSTEMD_SERVICE_resourcemgr = "resourcemgr.service"
+SYSTEMD_AUTO_ENABLE_resourcemgr = "enable"
+
+do_install_append() {
+install -d ${D}${systemd_system_unitdir}
+install -m0644 ${S}/contrib/resourcemgr.service
${D}${systemd_system_unitdir}/resourcemgr.service
+}
+
PROVIDES = "${PACKAGES}"
PACKAGES = " \
${PN}-dbg \
@@ -64,4 +80,4 @@ FILES_libtctisocket-dev = " \
${libdir}/pkgconfig/tcti-socket.pc \
"
FILES_libtctisocket-staticdev = "${libdir}/libtcti-socket.*a"
-FILES_resourcemgr = "${sbindir}/resourcemgr"
+FILES_resourcemgr = "${sbindir}/resourcemgr
${systemd_system_unitdir}/resourcemgr.service"
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH RESEND] logrotate: Add systemd support
Currently, this recipe only supports daily scheduling via a cron job.
This commit adds support for systemd, including systemd service and
systemd timer. When the corresponding distro feature is enabled the
systemd timer will be used instead of the cron job.
Signed-off-by: Romain Perier
---
Note: I was not registered on the yocto and oe ML, I subscribed. So
I resend for this reason (my bad).
.../logrotate/logrotate/logrotate.service | 9 +
.../logrotate/logrotate/logrotate.timer| 7 +++
meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 22 --
3 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.service
create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.timer
diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.service
b/meta/recipes-extended/logrotate/logrotate/logrotate.service
new file mode 100644
index 000..3edb8ef
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
@@ -0,0 +1,9 @@
+[Unit]
+Description=Rotate log files
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
+Nice=19
+IOSchedulingClass=best-effort
+IOSchedulingPriority=7
diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.timer
b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
new file mode 100644
index 000..a92ba1e
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
@@ -0,0 +1,7 @@
+[Unit]
+Description=Daily rotation of log files
+
+[Timer]
+OnCalendar=daily
+AccuracySec=12h
+Persistent=true
diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
index 5f1a601..734d661 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
@@ -14,6 +14,8 @@ SRC_URI =
"https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.g
file://act-as-mv-when-rotate.patch \
file://update-the-manual.patch \
file://disable-check-different-filesystems.patch \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'file://logrotate.service', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'file://logrotate.timer', '', d)} \
"
SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
@@ -47,6 +49,14 @@ EXTRA_OEMAKE = "\
# INSTALL=install and BASEDIR=/usr.
OS_NAME = "Linux"
+inherit systemd
+
+SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_SERVICE_${PN} = "\
+${PN}.service \
+${PN}.timer \
+"
+
do_compile_prepend() {
# Make sure the recompile is OK
rm -f ${B}/.depend
@@ -55,9 +65,17 @@ do_compile_prepend() {
do_install(){
oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
mkdir -p ${D}${sysconfdir}/logrotate.d
-mkdir -p ${D}${sysconfdir}/cron.daily
mkdir -p ${D}${localstatedir}/lib
install -p -m 644 examples/logrotate-default
${D}${sysconfdir}/logrotate.conf
-install -p -m 755 examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
touch ${D}${localstatedir}/lib/logrotate.status
+
+# Install systemd unit files
+if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '',
d)}" = "systemd" ]; then
+install -d ${D}/${systemd_system_unitdir}
+install -m 0644 ${WORKDIR}/logrotate.service
${D}/${systemd_system_unitdir}/logrotate.service
+install -m 0644 ${WORKDIR}/logrotate.timer
${D}/${systemd_system_unitdir}/logrotate.timer
+else
+mkdir -p ${D}${sysconfdir}/cron.daily
+install -p -m 0755 examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
+fi
}
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is there a searchable, complete archive of the Yocto mailing lists?
I know I can subscribe to the mailing lists and I know I can download month-by-month archives from here: https://lists.yoctoproject.org/pipermail/yocto/ but these methods seem a bit cumbersome. So, does anyone know if there is a way to search online through *all* postings to *one* mailing list, or through *all* postings to *all* mailing lists? If not, are there any archives per year, instead of per month? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there a searchable, complete archive of the Yocto mailing lists?
On 23 March 2017 at 15:30, Alain Achkar wrote: > So, does anyone know if there is a way to search online through *all* > postings to *one* mailing list, or through *all* postings to *all* mailing > lists? > You can use the site: operator on google to search them. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to interpret the "Recipes reporting system" (e.g. for Python3 3.4, 3.5, 3.6)
Hello!
Is there any brief README or documentation about the "Recipe reporting
system" ?
For example: http://recipes.yoctoproject.org/rrs/recipedetail/297/
Is it automatically generated or manually maintained? (If you look at the
field Source URI, it points to Python-3.4.3.tar.xz but the Recipe file
points to python3_3.5.3.bb which contains:
SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
I am trying to understand how/if I can use it. For example, if I am using
Jethro and I want Python 3.5 or 3.6, how can I use the "Recipe reporting
system" to achieve this? (I don't want to upgrade to Krogoth or Morty)
In Jethro, I have:
*poky/meta/recipes-devtools/python/python3_3.4.3.bb
*
which of course builds Python 3.4
I know that if I download Morty, I get:
*poky/meta/recipes-devtools/python/python3_3.5.2.bb
*
so, I tried copying this recipe into my Jethro source tree (at the same
location) but I got too many errors (I think there are several patches that
are needed).
So, is it possible to use the "Recipe reporting system" to see changes in
another branch and bring them in to my branch?
Moreover, if Python 3.6 is not available in Morty, how can I make a recipe
for it?
Thanks!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH RESEND] logrotate: Add systemd support
Hello,
Please ignore this patch, I will send a v2 with improvements.
Regards,
Romain
Le 23/03/2017 à 15:52, Romain Perier a écrit :
> Currently, this recipe only supports daily scheduling via a cron job.
> This commit adds support for systemd, including systemd service and
> systemd timer. When the corresponding distro feature is enabled the
> systemd timer will be used instead of the cron job.
>
> Signed-off-by: Romain Perier
> ---
>
> Note: I was not registered on the yocto and oe ML, I subscribed. So
> I resend for this reason (my bad).
>
> .../logrotate/logrotate/logrotate.service | 9 +
> .../logrotate/logrotate/logrotate.timer| 7 +++
> meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 22
> --
> 3 files changed, 36 insertions(+), 2 deletions(-)
> create mode 100644
> meta/recipes-extended/logrotate/logrotate/logrotate.service
> create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.timer
>
> diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.service
> b/meta/recipes-extended/logrotate/logrotate/logrotate.service
> new file mode 100644
> index 000..3edb8ef
> --- /dev/null
> +++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=Rotate log files
> +
> +[Service]
> +Type=oneshot
> +ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
> +Nice=19
> +IOSchedulingClass=best-effort
> +IOSchedulingPriority=7
> diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.timer
> b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
> new file mode 100644
> index 000..a92ba1e
> --- /dev/null
> +++ b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
> @@ -0,0 +1,7 @@
> +[Unit]
> +Description=Daily rotation of log files
> +
> +[Timer]
> +OnCalendar=daily
> +AccuracySec=12h
> +Persistent=true
> diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> index 5f1a601..734d661 100644
> --- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> +++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
> @@ -14,6 +14,8 @@ SRC_URI =
> "https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.g
> file://act-as-mv-when-rotate.patch \
> file://update-the-manual.patch \
> file://disable-check-different-filesystems.patch \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
> 'file://logrotate.service', '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
> 'file://logrotate.timer', '', d)} \
> "
>
> SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
> @@ -47,6 +49,14 @@ EXTRA_OEMAKE = "\
> # INSTALL=install and BASEDIR=/usr.
> OS_NAME = "Linux"
>
> +inherit systemd
> +
> +SYSTEMD_AUTO_ENABLE = "disable"
> +SYSTEMD_SERVICE_${PN} = "\
> +${PN}.service \
> +${PN}.timer \
> +"
> +
> do_compile_prepend() {
> # Make sure the recompile is OK
> rm -f ${B}/.depend
> @@ -55,9 +65,17 @@ do_compile_prepend() {
> do_install(){
> oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
> mkdir -p ${D}${sysconfdir}/logrotate.d
> -mkdir -p ${D}${sysconfdir}/cron.daily
> mkdir -p ${D}${localstatedir}/lib
> install -p -m 644 examples/logrotate-default
> ${D}${sysconfdir}/logrotate.conf
> -install -p -m 755 examples/logrotate.cron
> ${D}${sysconfdir}/cron.daily/logrotate
> touch ${D}${localstatedir}/lib/logrotate.status
> +
> +# Install systemd unit files
> +if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '',
> d)}" = "systemd" ]; then
> +install -d ${D}/${systemd_system_unitdir}
> +install -m 0644 ${WORKDIR}/logrotate.service
> ${D}/${systemd_system_unitdir}/logrotate.service
> +install -m 0644 ${WORKDIR}/logrotate.timer
> ${D}/${systemd_system_unitdir}/logrotate.timer
> +else
> +mkdir -p ${D}${sysconfdir}/cron.daily
> +install -p -m 0755 examples/logrotate.cron
> ${D}${sysconfdir}/cron.daily/logrotate
> +fi
> }
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?
On Fri, Mar 03, 2017 at 01:55:24PM -, Andy Pont wrote: > Ross Burton wrote... > > >> it seems of limited value for YP to have a powerpc reference board, > >> mpc8315e-rdb, that is essentially impossible to procure. is there any > >> effort being made to look around for a newer powerpc reference board > >> that people could actually buy? > > > >Do you have any suggestions? > > If we are being strictly pedantic then is isn't PowerPC (at least in the > world that is Freescale / NXP / Whoever they are this week). > > I would look at one of the P10xx series QorIQ boards. Digi-Key list the > P1021RDB-PC-ND and P1024RDB-PA-ND as being active parts which are either > single or dual e500 cores. Well it is a decent powerpcspe reference, but I sure wouldn't consider it a powerpc reference. It isn't quite compatible with standard powerpc. Where I used to work we told freescale that nothing with the e500 was ever going to be of interest, since if wasn't compatible with our existing 83xx based stuff, nor anything in the future like the e5500/e6500 or even e500mc. Sure for some uses it is fine, but I consider it wrong to call it powerpc without clearly mentioning it is the SPE variant, not the traditional type one would be used to. -- Len Sorensen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: libreoffice-5.0.5.2-r0 do_package
Ravikiran,
>
>
> *ERROR: libreoffice-5.0.5.2-r0 do_package: QA Issue: File
> '/usr/lib/libreoffice/share/extensions/mysql-connector-ooo/libmysqlclient_r.
> so' from libreoffice was already stripped, this will prevent future
> debugging! [already-stripped]*
This error message is produced by the packaging QA. It means that the
libreoffice's build system (make files) has already stripped the debug symbols
from the library.
There are two ways to fix this:
The better way: Examine the make files to see where the debug symbols are
being stripped. Create a patch so that they are not stripped during the
regular build process. This will allow YP/OE to create the debug package with
binaries that include the debug symbols and the regular package with the
binaries without the debug symbols.
The quick fix: Skip this QA check by adding
INSANE_SKIP_libreoffice += "already-stripped"
to the libreoffice recipe.
:rjs
> WARNING: libreoffice-5.0.5.2-r0 do_package: libreoffice language file
> pattern not found: /usr/lib/libreoffice/share/template/%{1}
>
>
> *ERROR: libreoffice-5.0.5.2-r0 do_package: Fatal QA errors found, failing
> task.ERROR: libreoffice-5.0.5.2-r0 do_package: Function failed:
> do_packageERROR: Logfile of failure stored in:
> /home/kamama-yocto/yocto/poky/build/tmp/work/cortexa15hf-neon-poky-linux-gnu
> eabi/libreoffice/5.0.5.2-r0/temp/log.do_package.23588* *ERROR: Task
> (/home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice
> /libreoffice/libreoffice.bb:do_package) failed with exit code '1'*
> NOTE: Tasks Summary: Attempted 8443 tasks of which 8385 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /home/kamama-yocto/yocto/poky/meta-packages/meta-office/recipes-libreoffice/
> libreoffice/libreoffice.bb: do_package
> Summary: There were 2 WARNING messages shown.
> Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
>
>
> what is the issue and how to solve this ?
>
>
> Best Regards,
> Ravikiran
--
Rudolf J Streif
signature.asc
Description: This is a digitally signed message part.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there a searchable, complete archive of the Yocto mailing lists?
Thanks Ross, this is very helpful! On Thu, Mar 23, 2017 at 11:43 AM, Burton, Ross wrote: > > On 23 March 2017 at 15:30, Alain Achkar wrote: > >> So, does anyone know if there is a way to search online through *all* >> postings to *one* mailing list, or through *all* postings to *all* mailing >> lists? >> > > You can use the site: operator on google to search them. > > Ross > > -- > ___ > 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] Morty 2.2.1 build failure
Hi Paul, I looked in the logs from the failure yesterday and couldn't find anything, so I restarted the build and it ran for about another 1000 steps before crashing again. I still can't find anything in any of the logs, syslog, kern.log, auth.log, etc. Cheers, Greg > -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Thursday, March 23, 2017 2:49 AM > To: Greg Wilson-Lindberg > Cc: yocto@yoctoproject.org; akuster808 > Subject: Re: [yocto] Morty 2.2.1 build failure > > On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg wrote: > > I tried it again this morning and it did get past the file not found error. > > But when it gets above step 4000 somewhere it gets an error that kills > > not just the yocto build but the full login session. I'm left staring > > at the Linux Login screen. > > Your machine isn't running out of RAM by any chance, triggering the OOM > killer? Anything indicative in your system logs? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] logrotate: Add systemd support
Currently, this recipe only supports daily scheduling via a cron job.
This commit adds support for systemd, including systemd service and
systemd timer. When the corresponding distro feature is enabled the
systemd timer will be used instead of the cron job.
Signed-off-by: Romain Perier
---
.../logrotate/logrotate/logrotate.service | 9 +
.../logrotate/logrotate/logrotate.timer| 7 +++
meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 22 --
3 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.service
create mode 100644 meta/recipes-extended/logrotate/logrotate/logrotate.timer
diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.service
b/meta/recipes-extended/logrotate/logrotate/logrotate.service
new file mode 100644
index 000..3edb8ef
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.service
@@ -0,0 +1,9 @@
+[Unit]
+Description=Rotate log files
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/logrotate /etc/logrotate.conf
+Nice=19
+IOSchedulingClass=best-effort
+IOSchedulingPriority=7
diff --git a/meta/recipes-extended/logrotate/logrotate/logrotate.timer
b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
new file mode 100644
index 000..a92ba1e
--- /dev/null
+++ b/meta/recipes-extended/logrotate/logrotate/logrotate.timer
@@ -0,0 +1,7 @@
+[Unit]
+Description=Daily rotation of log files
+
+[Timer]
+OnCalendar=daily
+AccuracySec=12h
+Persistent=true
diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
index 5f1a601..734d661 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
@@ -14,6 +14,8 @@ SRC_URI =
"https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.g
file://act-as-mv-when-rotate.patch \
file://update-the-manual.patch \
file://disable-check-different-filesystems.patch \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'file://logrotate.service', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'file://logrotate.timer', '', d)} \
"
SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
@@ -47,6 +49,14 @@ EXTRA_OEMAKE = "\
# INSTALL=install and BASEDIR=/usr.
OS_NAME = "Linux"
+inherit systemd
+
+SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_SERVICE_${PN} = "\
+${PN}.service \
+${PN}.timer \
+"
+
do_compile_prepend() {
# Make sure the recompile is OK
rm -f ${B}/.depend
@@ -55,9 +65,17 @@ do_compile_prepend() {
do_install(){
oe_runmake install DESTDIR=${D} PREFIX=${D} MANDIR=${mandir}
mkdir -p ${D}${sysconfdir}/logrotate.d
-mkdir -p ${D}${sysconfdir}/cron.daily
mkdir -p ${D}${localstatedir}/lib
install -p -m 644 examples/logrotate-default
${D}${sysconfdir}/logrotate.conf
-install -p -m 755 examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
touch ${D}${localstatedir}/lib/logrotate.status
+
+# Install systemd unit files
+if [ "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '',
d)}" = "systemd" ]; then
+install -d ${D}/${systemd_system_unitdir}
+install -m 0644 ${WORKDIR}/logrotate.service
${D}/${systemd_system_unitdir}/logrotate.service
+install -m 0644 ${WORKDIR}/logrotate.timer
${D}/${systemd_system_unitdir}/logrotate.timer
+else
+mkdir -p ${D}${sysconfdir}/cron.daily
+install -p -m 0755 examples/logrotate.cron
${D}${sysconfdir}/cron.daily/logrotate
+fi
}
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-swupd] allow username/password encoded in SWUPD_VERSION_URL and SWUPD_CONTENT_URL
This patch allows basic authentication of swupd SWUPD_VERSION_URL and SWUPD_CONTENT_URL. swupd-client already support urlencoded username/password, but buildlayer does not. diff --git a/lib/swupd/bundles.py b/lib/swupd/bundles.py index b4c6f49..223fd3c 100644 --- a/lib/swupd/bundles.py +++ b/lib/swupd/bundles.py @@ -4,6 +4,8 @@ import subprocess import shutil import urllib.request import urllib.error +import urllib.parse +import re from bb.utils import export_proxies from oe.package_manager import RpmPM from oe.package_manager import OpkgPM @@ -164,6 +166,15 @@ def download_manifests(content_url, version, component, to_dir): base_versions = set() if not os.path.exists(target): bb.debug(1, 'Downloading %s -> %s' % (source, target)) +parsed_source = urllib.parse.urlsplit(source) +if( parsed_source.username != None): +new_source = ( parsed_source.scheme, re.sub( re.escape( parsed_source.username+':'+parsed_source.password+'@'), '',parsed_source.netloc), parsed_source.path, parsed_source.query, parsed_source.fragment) +source = urllib.parse.urlunsplit( new_source) +manager = urllib.request.HTTPPasswordMgrWithDefaultRealm() +manager.add_password(None, new_source, parsed_source.username, parsed_source.password) +authHandler = urllib.request.HTTPBasicAuthHandler(manager) +opener = urllib.request.build_opener(authHandler) +urllib.request.install_opener(opener) response = urllib.request.urlopen(source) archive = response.read() bb.utils.mkdirhier(to_dir) @@ -228,6 +239,15 @@ def download_old_versions(d): for format in range(3, current_format + 1): try: url = '%s/version/format%d/latest' % (content_url, format) +parsed_url = urllib.parse.urlsplit(url) +if( parsed_url.username != None): +new_url = ( parsed_url.scheme, re.sub( re.escape( parsed_url.username+':'+parsed_url.password+'@'), '',parsed_url.netloc), parsed_url.path, parsed_url.query, parsed_url.fragment) +url = urllib.parse.urlunsplit( new_url) +manager = urllib.request.HTTPPasswordMgrWithDefaultRealm() +manager.add_password(None, new_url, parsed_url.username, parsed_url.password) +authHandler = urllib.request.HTTPBasicAuthHandler(manager) +opener = urllib.request.build_opener(authHandler) +urllib.request.install_opener(opener) response = urllib.request.urlopen(url) version = int(response.read()) latest_versions[format] = version -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Morty 2.2.1 build failure
That's really bizarre. There shouldn't be anything in a bitbake build that could cause anything like this (other than possibly how intensive it is, which might trigger out-of-memory or an underlying hardware/software failure). Assuming the X session is ending is there anything in your ~/.xsession-errors or /var/log/Xorg.*.log? Cheers, Paul On Friday, 24 March 2017 5:58:24 AM NZDT Greg Wilson-Lindberg wrote: > Hi Paul, > > I looked in the logs from the failure yesterday and couldn't find anything, > so I restarted the build and it ran for about another 1000 steps before > crashing again. I still can't find anything in any of the logs, syslog, > kern.log, auth.log, etc. > > Cheers, > Greg > > > -Original Message- > > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > > Sent: Thursday, March 23, 2017 2:49 AM > > To: Greg Wilson-Lindberg > > Cc: yocto@yoctoproject.org; akuster808 > > Subject: Re: [yocto] Morty 2.2.1 build failure > > > > On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg wrote: > > > I tried it again this morning and it did get past the file not found > > > error. > > > But when it gets above step 4000 somewhere it gets an error that kills > > > not just the yocto build but the full login session. I'm left staring > > > at the Linux Login screen. > > > > Your machine isn't running out of RAM by any chance, triggering the OOM > > killer? Anything indicative in your system logs? > > > > Cheers, > > Paul > > > > -- > > > > Paul Eggleton > > Intel Open Source Technology Centre -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Morty 2.2.1 build failure
On 03/23/2017 12:25 PM, Paul Eggleton wrote: That's really bizarre. There shouldn't be anything in a bitbake build that could cause anything like this (other than possibly how intensive it is, which might trigger out-of-memory or an underlying hardware/software failure). I usually get my builds to reboot my system when I build on a loptop. I have not seen this on a tower style work station. You may want to play with the BB_NUMBER_THREADS=# and PARALLEL_MAKE = "-j #" settings in your local.conf. - armin Assuming the X session is ending is there anything in your ~/.xsession-errors or /var/log/Xorg.*.log? Cheers, Paul On Friday, 24 March 2017 5:58:24 AM NZDT Greg Wilson-Lindberg wrote: Hi Paul, I looked in the logs from the failure yesterday and couldn't find anything, so I restarted the build and it ran for about another 1000 steps before crashing again. I still can't find anything in any of the logs, syslog, kern.log, auth.log, etc. Cheers, Greg -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Thursday, March 23, 2017 2:49 AM To: Greg Wilson-Lindberg Cc: yocto@yoctoproject.org; akuster808 Subject: Re: [yocto] Morty 2.2.1 build failure On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg wrote: I tried it again this morning and it did get past the file not found error. But when it gets above step 4000 somewhere it gets an error that kills not just the yocto build but the full login session. I'm left staring at the Linux Login screen. Your machine isn't running out of RAM by any chance, triggering the OOM killer? Anything indicative in your system logs? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA Test Report for Yocto Project Release 2.3 M3 rc1
Hi Here is the report for Full QA Cycle on Release 2.3 M3 rc1 Full Report : https://wiki.yoctoproject.org/wiki/WW11_-_2017-03-15_-_Full_Test_Cycle_2.3_M3_rc1 Summary The QA cycle for point release 2.3 M3 rc1 .1 is complete. There are 12 new issues found, 4 of them are High and 5 are M+. 2 of the high were blocking Performance and Selftest execution and were quickly fixed and merged, hence those 2 test suites were executed in a different commit from the one tagged for M3 rc1. In total there are 20 bugs attached to 2.3 M3 rc1, 5 High, 7 M+ and 8 M. Also there are still 15 M+ to be implemented still tagged to 2.3 M3 release. Regarding to Performance there is huge improvements on rootfs measurements on both machines Fedora and Ubuntu and eSDK on Ubuntu, and some little regressions (around 3%) on both machines in different tasks. pTest shows improvements on acl and e2fsprogs moudles but also shows regression on other modules. QA Hints -There are still may high and M+ bugs that are opened against M3 rc1 -2 of the highest test suites (Selftest and Performance) were not executed against M3 rc1 commit, even when they did show up good results on the commit were tested on the commit tagged for 2.3 M3 rc1 are failing. -There are still 15 M+ tagged to be implemented on 2.3 M3, hence a decision should be taken about them, implemented for M4 or moved to 2.4 Based on above points the strategy to follow up form QA perspective is to have another release candidate when the blocker issues get solved and hence have a better quality on M3 and avoid High issues on M4. === Details === Bugs * New -High o 11154 - buildperf: Fedora machine failing on buildperf execution due could not find 'ip' tool [1] o 11172 - bitbake: Fetcher failure when building core-image-minimal with "ERROR: socat: not found" [2] o 11193 - runqemu cannot launch image if enable "rm_work" [3] o 11223 - devtool runqemu doesn't work in eSDK [4] -M+ o 11224 - Compliance: LTP, POSIX, LSB tests are not creating results file (.targz) [5] o 11222 - [eclipse] C compiler cannot create executables when reconfiguring project [6] o 11174 - Update yocto-bsp script for kernel 4.10 [7] o 11144 - Build Appliance : Toaster requires pod2man [8] o 11185 - selftest/devtool: failing when parsing "mraa" recipe [9] -M / Low o 11173 testimage: "test_dnf_install_from_http" is failing [10] o 11220 runqemu: Qemux86 not boot with Ubuntu [11] o 11225 Build from Command line fail when finish all the tasks [12] * High / M+ Not New -9 runqemu-extract-sdk is failing when extracting .tar.bz file [13] -11064 [Yocto 2.2.1] kernel version mismatched when using yocto-bsp to create custom qemu bsp [14] -11025 selftest/devtool: Build mdadm failing on Centos7 and Ubuntu 1404 [15] Full bugs Report : https://wiki.yoctoproject.org/wiki/WW11_-_2017-03-15_-_Full_Test_Cycle_2.3_M3_rc1#Bugs_Found_during_QA_Test Performance Performance measurements were huge improved for rootfs on both machines (Ubuntu around 30%, Fedora 20%) falling down the numbers to the average observed before the "recipe specific sysroot" implementation. On Ubuntu there was also a very good improvement on eSDK deploy time of around 12%, some other measurement times were up on around 3% on both machines, below are the tables with the times of the tests: -Ubuntu Test 2.3 M2 rc3 2.3 M3 rc1 % sato 1:11:47 1:10:15 -2.14 rootfs 4:02 2:28 -38.84 rmwork 1:05:56 1:05:28 -0.71 kernel 5:00 5:11 +3.67 eSDK 3:28 3:01 -12.98 -Fedora Test 2.3 M2 rc3 2.3 M3 rc1 % sato 1:12:58 1:12:34 -0.55 rootfs 3:19 2:40 -19.60 rmwork 1:04:50 1:07:10 +3.60 kernel 6:27 6:29 +0.52 eSDK 3:11 3:17 +3.14 Performance Charts : https://wiki.yoctoproject.org/charts/perf_milestone_GDC/performance_test.html pTest -There were improvemnte of pass rate for acl and e2fsprogs modules -Modules that decreased pass rate were glib-2.0, openssh, openssl, quilt, strace, valgrind -A new bug was raised to address quil failures [15] pTest full report : https://wiki.yoctoproject.org/wiki/WW11_-_2017-03-15_-_Full_Test_Cycle_2.3_M3_rc1#pTest_for_genericx86-64_on_NUC Kernel -to test case "TCTEMP_2.3_MANUAL_Kernel_dev_External_source" was run, however due an issue with git, currently there is no way to test with 100% of reliability. I also tested on different machines. An empty directory is released when you are trying to clone from remote and local. I tested it also with older kernel 4.4, 4.6 and I got the same issue. One month ago I could reproduce this properly. Links 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11154 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11172 3. https://bugzilla.yoctoproject.org
Re: [yocto] Morty 2.2.1 build failure
Hi Armin & Paul, First there is nothing in the X log files. I'm building on a desktop machine with 12GB of memory and an 8 core processor running Kubuntu 14.04. I added the PARALLEL_MAKE parameter set to 4, no effect, still built with 8 threads, crashed. Set BB_NUMBER_THREADS to 4, built with 4 threads, still crashed. Regards, Greg > -Original Message- > From: akuster [mailto:akus...@mvista.com] > Sent: Thursday, March 23, 2017 12:33 PM > To: Greg Wilson-Lindberg > Cc: Paul Eggleton ; yocto@yoctoproject.org > Subject: Re: [yocto] Morty 2.2.1 build failure > > > > On 03/23/2017 12:25 PM, Paul Eggleton wrote: > > That's really bizarre. There shouldn't be anything in a bitbake build > > that could cause anything like this (other than possibly how intensive > > it is, which might trigger out-of-memory or an underlying > hardware/software failure). > > I usually get my builds to reboot my system when I build on a loptop. I have > not seen this on a tower style work station. You may want to play with the > BB_NUMBER_THREADS=# and PARALLEL_MAKE = "-j #" settings in your > local.conf. > > - armin > > > > Assuming the X session is ending is there anything in your > > ~/.xsession-errors or /var/log/Xorg.*.log? > > > > Cheers, > > Paul > > > > On Friday, 24 March 2017 5:58:24 AM NZDT Greg Wilson-Lindberg wrote: > >> Hi Paul, > >> > >> I looked in the logs from the failure yesterday and couldn't find > >> anything, so I restarted the build and it ran for about another 1000 > >> steps before crashing again. I still can't find anything in any of > >> the logs, syslog, kern.log, auth.log, etc. > >> > >> Cheers, > >> Greg > >> > >>> -Original Message- > >>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > >>> Sent: Thursday, March 23, 2017 2:49 AM > >>> To: Greg Wilson-Lindberg > >>> Cc: yocto@yoctoproject.org; akuster808 > >>> Subject: Re: [yocto] Morty 2.2.1 build failure > >>> > >>> On Thursday, 23 March 2017 9:23:24 AM NZDT Greg Wilson-Lindberg > wrote: > I tried it again this morning and it did get past the file not > found error. > But when it gets above step 4000 somewhere it gets an error that > kills not just the yocto build but the full login session. I'm left > staring at the Linux Login screen. > >>> Your machine isn't running out of RAM by any chance, triggering the > >>> OOM killer? Anything indicative in your system logs? > >>> > >>> Cheers, > >>> Paul > >>> > >>> -- > >>> > >>> Paul Eggleton > >>> Intel Open Source Technology Centre > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to interpret the "Recipes reporting system" (e.g. for Python3 3.4, 3.5, 3.6)
Hi Alain,
On Friday, 24 March 2017 4:50:39 AM NZDT Alain Achkar wrote:
> Is there any brief README or documentation about the "Recipe reporting
> system" ?
>
> For example: http://recipes.yoctoproject.org/rrs/recipedetail/297/
>
> Is it automatically generated or manually maintained? (If you look at the
> field Source URI, it points to Python-3.4.3.tar.xz but the Recipe file
> points to python3_3.5.3.bb which contains:
>
> SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
Something is wrong there - the SRC_URI field must not be being updated. For
the most part the RRS is automatically populated. Anibal, any ideas?
> I am trying to understand how/if I can use it. For example, if I am using
> Jethro and I want Python 3.5 or 3.6, how can I use the "Recipe reporting
> system" to achieve this? (I don't want to upgrade to Krogoth or Morty)
>
> In Jethro, I have:
>
>
> *poky/meta/recipes-devtools/python/python3_3.4.3.bb
> *
>
> which of course builds Python 3.4
>
> I know that if I download Morty, I get:
>
> *poky/meta/recipes-devtools/python/python3_3.5.2.bb
> *
>
> so, I tried copying this recipe into my Jethro source tree (at the same
> location) but I got too many errors (I think there are several patches that
> are needed).
Backporting will require changes, definitely. You'll have to work through them
- you may be able to use the migration information in the reference manual (in
reverse, of course) to provide hints - the 2.2 (morty) and 2.1 (krogoth)
sections would be appropriate for your situation:
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration
You may also find the git history for the recipes in question to be
instructive in terms of what changes were made to bring them to their current
state in master.
> So, is it possible to use the "Recipe reporting system" to see changes in
> another branch and bring them in to my branch?
You'd do that by checking out the branch in git and copying the entire
directory, the RRS is just a reporting tool.
> Moreover, if Python 3.6 is not available in Morty, how can I make a recipe
> for it?
Since 3.6 isn't in master, there aren't any shortcuts I'm afraid, you would
have to try manually updating it - probably the safest thing to do would be to
copy the existing directory into your own custom layer and modify it there. I
suspect starting at 3.5.2 is going to be fastest, but of course you'll need to
backport that to jethro first.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Buildbot / Autobuilder / custom?
I followed http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder/tree/README-QUICKSTART and got: >0< alain@esxi-ub1 Thu Mar 23 05:34 PM [master] /media/data/yocto-autobuilder > *. ./yocto-autobuilder-setup* Creating yocto-controller/buildbot.tac from an example buildbot.tac Creating yocto-worker/buildbot.tac from an example buildbot.tac Creating yocto-controller/controller.cfg from an example controller.cfg # Setting envvars. In the future though please add the following to your shell environment: PYTHONPATH=/media/data/yocto-autobuilder/lib/python2.7/site-packages/:/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/:/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/buildsteps:$PYTHONPATH PATH=/media/data/yocto-autobuilder/bin:/media/data/yocto-autobuilder/yocto-autobuilder/scripts:$PATH YOCTO_AB_CONFIG=/media/data/yocto-autobuilder/buildset-config/yoctoAB.conf If you don't, you should source this script everytime you want start the autobuilder. Creating config/autobuilder.conf from an example autobuilder.conf Creating buildset-config from buildset-config.controller You've not setup the autobuilder before. Generating a server/client password combo for you. Client/Server Password = (deleted, on purpose) Modifying the following files with this password: /media/data/yocto-autobuilder/yocto-controller/controller.cfg /media/data/yocto-autobuilder/yocto-controller/buildbot.tac /media/data/yocto-autobuilder/yocto-worker/buildbot.tac Updating worker-init script used for google cloud building. If you wish to use your own generated username and password please modify the above files as needed. Please see the README for more information. Generating an .htpasswd file using your current username and (deleted, on purpose) at /media/data/yocto-autobuilder/.htpasswd # Please modify /media/data/yocto-autobuilder/config/autobuilder.conf if you wish to specify a different location in which to publish build artifacts, etc. # Ready to start the yocto autobuilder. The yocto-autobuilder runs buildbot 0.8.8 with some modifications and a different git fetcher (yoctogit.py) # checking basedir checking for running master checking controller.cfg LOADING CONFIG FILE *error while parsing config file:* Traceback (most recent call last): File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/Twisted-12.2.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/scripts/upgrade_master.py", line 169, in upgradeMaster master_cfg = loadConfig(config, configFile) File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/scripts/upgrade_master.py", line 53, in loadConfig config['basedir'], configFileName) --- --- File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/config.py", line 149, in loadConfig exec f in localDict File "/media/data/yocto-autobuilder/yocto-controller/controller.cfg", line 94, in yocto_buildsets.createBuildsets() File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/Autobuilder.py", line 65, in createBuildsets self.parseBuildSet(buildset) File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/Autobuilder.py", line 102, in parseBuildSet self.parseRepos(buildset) File "/media/data/yocto-autobuilder/lib/python2.7/site-packages/autobuilder/Autobuilder.py", line 127, in parseRepos if layer.iterkeys().next() not in self.repos: *exceptions.AttributeError: 'list' object has no attribute 'iterkeys'* Errors loading configuration: error while parsing config file: 'list' object has no attribute 'iterkeys' (traceback in logfile) To start the autobuilder: ./yocto-start-autobuilder To stop the autobuilder: ./yocto-stop-autobuilder >0< alain@esxi-ub1 Thu Mar 23 05:34 PM [master !?] /media/data/yocto-autobuilder > Any ideas on how to fix this? On Mon, Nov 14, 2016 at 1:40 PM, Bill Randle wrote: > Yes, the 2 TB is for everything you might do with an AutoBuilder. The > actual space used will be closer to your 35 GB, since you're building > only a single image / work product. People have used BuilBot directly > for automated builds, but using the AutoBuilder code (which runs > BuildBot underneath) gives you added flexibi
