Re: [yocto] do_patch through Yocto fails while "git am" succeed
On Fri, 2016-06-10 at 20:32 +0100, Burton, Ross wrote: > > On 10 June 2016 at 19:12, Michael Hu wrote: > > What could be the difference? > > > > > > bitbake uses quilt to apply patches, not git am, so if the patch > isn't exactly right then they'll behave differently. Stripping the > trailing CRs would be a start. > It's worth pointing out that you can tell the system to use a different tool to apply your patch by setting the PATCHTOOL variable in your recipe: http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-PAT CHTOOL i.e. PATCHTOOL = "git" Regards, Joshua-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder] [RFC] Add support for generate bitbake error reports
On Thu, 2016-06-09 at 16:23 -0500, Aníbal Limón wrote: > Hi folks, > > Currently we support to send error reports to errors.yoctoproject.org > about failing tasks on bitbake using SendErrorReport buildstep but we > have a lack of bitbake related errors like exceptions. > > A bug exist to implement this support into Error report web [1], i'm > working on it but for generate bitbake error reports there's a need > of > some process monitoring the bitbake output in this case the Yocto > Autobuilder. > > This email is for review my current implementation for generate > bitbake > error reports in the Autobuilder [2] next i'll try to explain how it > works. > > I aadded a BitbakeShellCommand [3] class for use in the buildsteps > that > executes bitbake the main objective of this class is to have common > operations to be made in bitbake commands like create error reports > if > fails. > > For create error reports this class add an stdio observer to look at > bitbake output and if bitbake fails review the bitbake output for > identify if the failure is an non-related task error [4]. If the > observer found bitbake error creates an Error report with the > information in the master controller. > > In order to send the bitbake error to Error report web the controller > transfer the report to the worker using a new DownloadDirectory > implementation that i made [5], the SendErrorReport buildstep works > on > the worker side so it's easy to transfer the reports from master to > worker instead of send it by master. > > Finally to complete with the job of have the bitbake errors reports > the > Error report web changes need (i'm working on it) to be integrated > first in order to don't break anything. > > Please review it and provide me feedback. > 1. fix the commit message to ea1d5b35bc77bad5d2 2. in same, why are you removing buildset-config.controller/poky- tiny.conf? I believe this is still supported (and even if it isn't in master, we maintain backwards compatibility) As a whole, I like what is being done here. I would like this put on the devel cluster before bringing it into production, just to smoke test this, both with nightly builds and single builds. I can't see anything that would obviously blow up though. cheers, -b -- Beth 'pidge' Flanagan toganlabs.com > Cheers, > alimon > > [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7583 > [2] > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=co > ntrib/alimon/devel > [3] > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/ > python2.7/site- > packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n92 > [4] > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/ > python2.7/site- > packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n53 > [5] > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?h > =contrib/alimon/devel&id=4022920bb0e56d1eef3dfe7c5e9b4699f801cdf1 > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to set KCONFIG_MODE for defconfig and fragments
On Sun, 12 Jun 2016 22:22:39 -0400
Bruce Ashfield wrote:
> On 2016-06-12 9:40 PM, Kunihiko Hayashi wrote:
> > Hello, all
> >
> > Now I'm trying to build my own kernel with linux-yocto recipe,
> > and I make kernel configuration fragments (".cfg" file) according to
> > "Linux Kernel Development Manual", and my fragments can't be applied
> > to the kernel at all.
> >
> > I find that linux-yocto recipe uses "allnoconfig" as default, and
> > configurations that my fragments depend on are disabled.
>
> Your fragments really should be specifying not only their options,
> but the dependencies as well, or you need to have them
> include other fragments that set those dependencies.
>
> If you don't, you are relying on the baseline configuration .. which
> is either a defconfig or ktype fragments in linux-yocto. That is also
> ok, just something to be aware of.
>
> >
> >> KCONFIG_MODE = "--allnoconfig"
> >
> > I assume that KCONFIG_MODE has the option of "configme" script,
> > but this option is undocumented on any manuals.
> >
> > If I apply "defconfig" and my additional fragments as it is,
> > how do I set KCONFIG_MODE in my recipe? (null string or another option?)
>
> KCONFIG_MODE is a variable like any other. In your kernel recipe,
> you can just set it to one of the valid options.
>
> KCONFIG_MODE = "..."
>
> Note: those valid options are only [--alldefconfig] [--allnoconfig],
> since that is what the kernel merge_config.sh script can process.
Thank you for your comment.
I understand that I need to solve all dependencies in the usual cases,
and KCONFIG_MODE is used for merge_config.sh. I think that to set
"--alldefconfig" to KCONFIG_MODE solves the question.
Regards,
---
Kunihiko Hayashi
:hayashi.kunih...@socionext.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] The build issue of ext2.gz and ext2.gz.u-boot rootfs
Hi all,
I try to use the master branch of poky to build ext2.gz and ext2.gz.u-boot
rootfs at the same time, the following error will appear. The same issue can be
reproduced for other machines as well.
[...snip...]
| Image Name: core-image-minimal-b4860qds-2016
| Created: Sun Jun 12 23:18:26 2016
| Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
| Data Size:50613518 Bytes = 49427.26 kB = 48.27 MB
| Load Address:
| Entry Point:
| mkimage: Can't open
/home/yocto/poky/b4860qds/tmp/deploy/images/b4860qds/core-image-minimal-b4860qds-20160613041724.rootfs.ext2.gz:
No such file or directory
The following is the definition of do_image_ext2, the ext2.gz file is cleaned
by the first "oe_mkimage ... gzip clean" before the second oe_mkimage
execution.
do_image_ext2() {
oe_mkext234fs ext2 -i 4096
cd /home/yocto/poky/b4860qds/tmp/deploy/images/b4860qds
gzip -f -9 -c
core-image-minimal-b4860qds-20160613042048.rootfs.ext2 >
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz
gzip -f -9 -c
core-image-minimal-b4860qds-20160613042048.rootfs.ext2 >
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz; oe_mkimage
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz gzip clean
oe_mkimage
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz none
rm core-image-minimal-b4860qds-20160613042048.rootfs.ext2
}
If change[1] is made for poky/meta/classes/image.bbclass, the isuse can be
reproduced every time, if change[2] is made for
poky/meta/classes/image.bbclass, the isuse can't be reproduced. Without change,
the sequence of ctypes is random, accordingly the build issue apprears randomly.
Change[1]:
-ctypes = set(d.getVar('COMPRESSIONTYPES', True).split())
+ctypes = sorted(set(d.getVar('COMPRESSIONTYPES', True).split()))
Change[2]:
-ctypes = set(d.getVar('COMPRESSIONTYPES', True).split())
+ctypes = sorted(set(d.getVar('COMPRESSIONTYPES', True).split()),
reverse=True)
I meet either the following two issues when I only build ext2.gz.u-boot, the
following is the error.
Taskhash mismatch issue:
ERROR: core-image-minimal-1.0-r0 do_image_ext2: Taskhash mismatch
bb5f9a754f83ef6534d62ca5ea64d631 verses c56d6505b35344945430e1d6cae3867c for
/home/yocto/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_ext2
ERROR: Taskhash mismatch bb5f9a754f83ef6534d62ca5ea64d631 verses
c56d6505b35344945430e1d6cae3867c for
/home/yocto/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_ext2
Ext2.gz remove issue:
| rm: cannot remove
'core-image-minimal-b4860qds-20160613044631.rootfs.ext2.gz': No such file or
directory
Any suggestion of how to fix such issues?
Best Regards,
Zhenhua
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Antwort: Re: License problems when switching form RPM to DEB - looking for a easy way to fix it
Hej
I deleted the tmp and rebuild it. But the error stays. I added a licence
file to the repro and added the
LICENSE="ESA"
LIC_FILES_CHKSUM="files://ESAlicense.txt;md5=.."
What's the connection between the LICENSE and LIC_FILES_CHKSUM field?
How the license manifest is build?
I think the error is releated to the point, that there is possibly no
LICENSE entry connected to "ESA" or "CLOSED".
Below the error print:
##
ERROR: core-image-minimal-1.0-r0 do_rootfs: Error executing a python
function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure
was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
0001:
*** 0002:license_create_manifest(d)
0003:
File: '/home/user/myTC/poky/meta/classes/license.bbclass', lineno: 48,
function: license_create_manifest
0044:pkg_dic = {}
0045:for pkg in sorted(image_list_installed_packages(d)):
0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR', True),
0047:'runtime-reverse', pkg)
*** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
0049:
0050:pkg_dic[pkg_name] =
oe.packagedata.read_pkgdatafile(pkg_info)
0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
0052:pkg_lic_name = "LICENSE_" + pkg_name
Exception: OSError: [Errno 2] No such file or directory:
'/home/user/myTC/poky/build/tmp/sysroots/sama5d3xek/pkgdata/runtime-reverse/mycontrol'
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed:
license_create_manifest
ERROR: Logfile of failure stored in:
/home/user/myTC/poky/build/tmp/work/sama5d3xek-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.22140
ERROR: Task 9
(/home/user/myTC/poky/meta/recipes-core/images/core-image-minimal.bb,
do_rootfs) failed with exit code '1'
##
Regards!
Stefan Jaritz
ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de
Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker
Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
erhalten
haben, informieren Sie bitte sofort den Absender und löschen Sie diese
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail
ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly
forbidden.
Von:"Burton, Ross"
An: s.jar...@esa-grimma.de
Kopie: "yocto@yoctoproject.org"
Datum: 09.06.2016 18:21
Betreff:Re: [yocto] License problems when switching form RPM to
DEB - looking for a easy way to fix it
On 9 June 2016 at 15:52, wrote:
I switched from RPM to DEB because the board configuration should be
handled by a package manager. By doing so I ran into a QA problem. All the
software provided by my colleagues I maked with
Note that deb is the least-tested package manager, we generally recommend
rpm or opkg over deb. If you switched to deb because of the size of the
tools on the target compared to rpm (as smart pulls in Python, it's not
small) then you'll really like opkg.
LICENSE = "CLOSED"
because they do not provide a license file. This works fine with the rpm
generator, but when I use the debian generator - the QA from the
"do_rootfs" fails with:
[snip]
Very interesting, and I have seen this occasionally. Does deleting your
tmp/ and rebuilding from sstate solve this?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-rpi: ensure config file is closed
Hello,
On Sun, Jun 05, 2016 at 01:38:52AM +1000, Jonathan Liu wrote:
> Avoids warnings like this with python3:
>
> WARNING:
> .../meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_3.18.bb:
> :16: ResourceWarning: unclosed file <_io.TextIOWrapper
> name='.../meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig'
> mode='r' encoding='UTF-8'>
>
> Signed-off-by: Jonathan Liu
> ---
> recipes-kernel/linux/linux-rpi.inc | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/recipes-kernel/linux/linux-rpi.inc
> b/recipes-kernel/linux/linux-rpi.inc
> index 1755685..4b65fc2 100644
> --- a/recipes-kernel/linux/linux-rpi.inc
> +++ b/recipes-kernel/linux/linux-rpi.inc
> @@ -133,4 +133,6 @@ python () {
> if 'CONFIG_KERNEL_LZO=y\n' in configfile.readlines():
> depends = d.getVar('DEPENDS', False)
> d.setVar('DEPENDS', depends + ' lzop-native')
> +
> +configfile.close()
> }
> https://lists.yoctoproject.org/listinfo/yocto
Merged to master. Thank you.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The build issue of ext2.gz and ext2.gz.u-boot rootfs
I have submitted a patch, please review.
http://patchwork.openembedded.org/patch/124761/.
Best Regards,
Zhenhua
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Zhenhua Luo
Sent: Monday, June 13, 2016 5:53 PM
To: yocto@yoctoproject.org
Subject: [yocto] The build issue of ext2.gz and ext2.gz.u-boot rootfs
Hi all,
I try to use the master branch of poky to build ext2.gz and ext2.gz.u-boot
rootfs at the same time, the following error will appear. The same issue can be
reproduced for other machines as well.
[...snip...]
| Image Name: core-image-minimal-b4860qds-2016
| Created: Sun Jun 12 23:18:26 2016
| Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
| Data Size:50613518 Bytes = 49427.26 kB = 48.27 MB
| Load Address:
| Entry Point:
| mkimage: Can't open
/home/yocto/poky/b4860qds/tmp/deploy/images/b4860qds/core-image-minimal-b4860qds-20160613041724.rootfs.ext2.gz:
No such file or directory
The following is the definition of do_image_ext2, the ext2.gz file is cleaned
by the first "oe_mkimage ... gzip clean" before the second oe_mkimage
execution.
do_image_ext2() {
oe_mkext234fs ext2 -i 4096
cd /home/yocto/poky/b4860qds/tmp/deploy/images/b4860qds
gzip -f -9 -c
core-image-minimal-b4860qds-20160613042048.rootfs.ext2 >
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz
gzip -f -9 -c
core-image-minimal-b4860qds-20160613042048.rootfs.ext2 >
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz; oe_mkimage
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz gzip clean
oe_mkimage
core-image-minimal-b4860qds-20160613042048.rootfs.ext2.gz none
rm core-image-minimal-b4860qds-20160613042048.rootfs.ext2
}
If change[1] is made for poky/meta/classes/image.bbclass, the isuse can be
reproduced every time, if change[2] is made for
poky/meta/classes/image.bbclass, the isuse can't be reproduced. Without change,
the sequence of ctypes is random, accordingly the build issue apprears randomly.
Change[1]:
-ctypes = set(d.getVar('COMPRESSIONTYPES', True).split())
+ctypes = sorted(set(d.getVar('COMPRESSIONTYPES', True).split()))
Change[2]:
-ctypes = set(d.getVar('COMPRESSIONTYPES', True).split())
+ctypes = sorted(set(d.getVar('COMPRESSIONTYPES', True).split()),
reverse=True)
I meet either the following two issues when I only build ext2.gz.u-boot, the
following is the error.
Taskhash mismatch issue:
ERROR: core-image-minimal-1.0-r0 do_image_ext2: Taskhash mismatch
bb5f9a754f83ef6534d62ca5ea64d631 verses c56d6505b35344945430e1d6cae3867c for
/home/yocto/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_ext2
ERROR: Taskhash mismatch bb5f9a754f83ef6534d62ca5ea64d631 verses
c56d6505b35344945430e1d6cae3867c for
/home/yocto/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_ext2
Ext2.gz remove issue:
| rm: cannot remove
'core-image-minimal-b4860qds-20160613044631.rootfs.ext2.gz': No such file or
directory
Any suggestion of how to fix such issues?
Best Regards,
Zhenhua
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Issue creating systemd service recipe
On Sat, Jun 11, 2016 at 10:32 AM, Alexis Lothoré
wrote:
> Hello Matt,
> thank you for your answer, I was typing a mail to, I found this fix too
> minutes before your answer ^^
> However, I do not understand why the first syntax did not work, since the
> systemd class seems to seek the service file here to. Here is the code which
> make me think of that possibility, in systemd.bbclass :
Yes, the search code does work; I have some recipes that install
systemd services into /etc/systemd/system. I think the problem was in
your do_install().
[...]
>> do_install () {
>> install -d ${D}{sysconfdir}/systemd/system
>> install -d ${D}/opt/lowpan
>> install -m 0755 ${WORKDIR}/lowpan.service
>> ${D}{sysconfdir}/systemd/system
^--- missing '$' here
>> install -m 0755 ${WORKDIR}/init.sh ${D}/opt/lowpan
>> }
-Matt
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH] powercap / RAPL: disable the 2nd power limit properly
From: Seiichi Ikarashi
Let rapl_unregister_powercap() disable the second power limit
only if it exists.
Intel64 SDM Vol.3 14.9 says that the package domain has it
but neither the power plane domain nor the DRAM domain has it.
Signed-off-by: Seiichi Ikarashi
Signed-off-by: Rafael J. Wysocki
(cherry picked from commit 5021282cc483d4126c1704942adb74806f7d15d6)
Signed-off-by: Yu, Ong Hock
---
drivers/powercap/intel_rapl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 085b272..784f31e 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1147,9 +1147,11 @@ static int rapl_unregister_powercap(void)
pr_debug("remove package, undo power limit on %d: %s\n",
rp->id, rd->name);
rapl_write_data_raw(rd, PL1_ENABLE, 0);
- rapl_write_data_raw(rd, PL2_ENABLE, 0);
rapl_write_data_raw(rd, PL1_CLAMP, 0);
- rapl_write_data_raw(rd, PL2_CLAMP, 0);
+ if (find_nr_power_limit(rd) > 1) {
+ rapl_write_data_raw(rd, PL2_ENABLE, 0);
+ rapl_write_data_raw(rd, PL2_CLAMP, 0);
+ }
if (rd->id == RAPL_DOMAIN_PACKAGE) {
rd_package = rd;
continue;
--
1.9.1
--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [yocto-autobuilder] [RFC] Add support for generate bitbake error reports
On 06/13/2016 03:48 AM, Beth 'pidge' Flanagan wrote: > On Thu, 2016-06-09 at 16:23 -0500, Aníbal Limón wrote: >> Hi folks, >> >> Currently we support to send error reports to errors.yoctoproject.org >> about failing tasks on bitbake using SendErrorReport buildstep but we >> have a lack of bitbake related errors like exceptions. >> >> A bug exist to implement this support into Error report web [1], i'm >> working on it but for generate bitbake error reports there's a need >> of >> some process monitoring the bitbake output in this case the Yocto >> Autobuilder. >> >> This email is for review my current implementation for generate >> bitbake >> error reports in the Autobuilder [2] next i'll try to explain how it >> works. >> >> I aadded a BitbakeShellCommand [3] class for use in the buildsteps >> that >> executes bitbake the main objective of this class is to have common >> operations to be made in bitbake commands like create error reports >> if >> fails. >> >> For create error reports this class add an stdio observer to look at >> bitbake output and if bitbake fails review the bitbake output for >> identify if the failure is an non-related task error [4]. If the >> observer found bitbake error creates an Error report with the >> information in the master controller. >> >> In order to send the bitbake error to Error report web the controller >> transfer the report to the worker using a new DownloadDirectory >> implementation that i made [5], the SendErrorReport buildstep works >> on >> the worker side so it's easy to transfer the reports from master to >> worker instead of send it by master. >> >> Finally to complete with the job of have the bitbake errors reports >> the >> Error report web changes need (i'm working on it) to be integrated >> first in order to don't break anything. >> >> Please review it and provide me feedback. >> > > > 1. fix the commit message to ea1d5b35bc77bad5d2 > 2. in same, why are you removing buildset-config.controller/poky- > tiny.conf? I believe this is still supported (and even if it isn't in > master, we maintain backwards compatibility) Thanks for notice the removal of poky-tiny it wasn't my intention, i did an script to update the buildsets and seems that don't work well. I'll fix the last commit message ea1d5b35bc77bad5d2 and also include the poky-tiny buildset. > > > As a whole, I like what is being done here. I would like this put on > the devel cluster before bringing it into production, just to smoke > test this, both with nightly builds and single builds. I can't see > anything that would obviously blow up though. > > cheers, > > > -b > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder] [RFC] Add support for generate bitbake error reports
On Mon, 2016-06-13 at 10:09 -0500, Aníbal Limón wrote: > > On 06/13/2016 03:48 AM, Beth 'pidge' Flanagan wrote: > > > > On Thu, 2016-06-09 at 16:23 -0500, Aníbal Limón wrote: > > > > > > Hi folks, > > > > > > Currently we support to send error reports to > > > errors.yoctoproject.org > > > about failing tasks on bitbake using SendErrorReport buildstep > > > but we > > > have a lack of bitbake related errors like exceptions. > > > > > > A bug exist to implement this support into Error report web [1], > > > i'm > > > working on it but for generate bitbake error reports there's a > > > need > > > of > > > some process monitoring the bitbake output in this case the Yocto > > > Autobuilder. > > > > > > This email is for review my current implementation for generate > > > bitbake > > > error reports in the Autobuilder [2] next i'll try to explain how > > > it > > > works. > > > > > > I aadded a BitbakeShellCommand [3] class for use in the > > > buildsteps > > > that > > > executes bitbake the main objective of this class is to have > > > common > > > operations to be made in bitbake commands like create error > > > reports > > > if > > > fails. > > > > > > For create error reports this class add an stdio observer to look > > > at > > > bitbake output and if bitbake fails review the bitbake output for > > > identify if the failure is an non-related task error [4]. If the > > > observer found bitbake error creates an Error report with the > > > information in the master controller. > > > > > > In order to send the bitbake error to Error report web the > > > controller > > > transfer the report to the worker using a new DownloadDirectory > > > implementation that i made [5], the SendErrorReport buildstep > > > works > > > on > > > the worker side so it's easy to transfer the reports from master > > > to > > > worker instead of send it by master. > > > > > > Finally to complete with the job of have the bitbake errors > > > reports > > > the > > > Error report web changes need (i'm working on it) to be > > > integrated > > > first in order to don't break anything. > > > > > > Please review it and provide me feedback. > > > > > > > 1. fix the commit message to ea1d5b35bc77bad5d2 > > 2. in same, why are you removing buildset-config.controller/poky- > > tiny.conf? I believe this is still supported (and even if it isn't > > in > > master, we maintain backwards compatibility) > Thanks for notice the removal of poky-tiny it wasn't my intention, i > did > an script to update the buildsets and seems that don't work well. > I'll > fix the last commit message ea1d5b35bc77bad5d2 and also include the > poky-tiny buildset. > Great, if you can get this onto a dev cluster (halstead should have info here on connection), I'd be interested in seeing what a nightly and a nightly-arm do. -b > > > > > > > > As a whole, I like what is being done here. I would like this put > > on > > the devel cluster before bringing it into production, just to smoke > > test this, both with nightly builds and single builds. I can't see > > anything that would obviously blow up though. > > > > cheers, > > > > > > -b > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project Status WW24
On 06/10/2016 08:21 AM, Jolley, Stephen K wrote: > Current Dev Position: YP 2.2 M1 > > Next Deadline: YP 2.2 cut off: June 13, 2016 [3 days - Monday!] > > > SWAT team rotation: Jussi -> Maxim > > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team > > > Key Status/Updates: > > *We continue to see various python v3 issues however these are on the > most part comparatively minor. > > *The Centos 7 auobuilder issues look to have been caused by XFS, > switching to ext4 seems to have resolved it. > > *We're expecting some large patchsets for toaster bootstrap v2 -> v3 > and changes to move OE-Core/Sato to gtk3+, am hoping to get these into M1. > > *Richard is starting a discussion on multi-configuration builds on > the openembedded-architecture list. > > *YP 2.0.2 was released last week > > *We're now working on 2.1.1 with trial builds in preparation for a > release Can I get a sense of when this might happen? when is a code freeze for this. I am wondering if I have time for another pass through master and submitted patches. As the Yocto Project follows a more formalized process, I am hoping I can get a heads up on when a new release is going to happen. - armin > > *2.2 M1 is due next week > > > Key YP 2.2 Dates: > > *YP 2.2 M1 cut off would be: 6/13/16 > > *YP 2.2 M1 release would be: 6/24/16 > > *YP 2.2 M2 cut off would be: 7/18/16 > > *YP 2.2 M2 release would be: 7/29/16 > > *YP 2.2 M3 cut off would be: 8/29/16 > > *YP 2.2 M3 release would be: 9/9/16 > > *YP 2.2 M4 cut off would be: 10/3/16 > > *YP 2.2 M4 release would be: 10/28/16 > > > Tracking Metrics: > > WDD 2599 (last week 2622) > > (https://wiki.yoctoproject.org/charts/combo.html) > > > Key Status Links for YP: > > https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status > > https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule > > https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features > > [If anyone has suggestions for other information you'd like to see on this > weekly status update, let us know!] > > Thanks, > > Stephen K. Jolley > Yocto Project Program Manager > INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 > * Work Telephone:(503) 712-0534 > *Cell: (208) 244-4460 > * Email:stephen.k.jol...@intel.com > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] IPMI server using OpenIPMI ?
This OpenIPMI recipe (https://layers.openembedded.org/layerindex/recipe/24126/) is enabled by the OpenClovis layer. While OpenIPMI is a framework for implementing an IPMI management "client" tool, it does provide a "lanserv" module. This module acts as an IPMI simulator (on qemu) which helps in verifying/testing OpenIPMI client itself. I am currently evaluating the usage of "lanserv" module within OpenIPMI for implementing an IPMI server on the BMC(baseboard management controller) for the OpenBMC project (https://github.com/openbmc). Can this list comment/provide guidance on :a) are there openembedded/yocto based projects which use OpenIPMI (lanserv) to build an IPMI server ?b) alternate opensource IPMI toolkit/framework for implementing the IPMI server on the BMC ? Thanks in advance,Hari ! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Script being installed under /etc/init.d instead of /usr/lib/systemd folder
Hi, I am trying to use the systemd init system from the existing system. I have added the following to my conf file: DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" I have also added the 'systemd' binary to the INSTALL_APPEND. When I boot the resulting image, I do see systemd up and running and I am able to start and stop services. However, I do have a script recipe which is currently placed as a bbappend to initscripts (meta/recipes-core/initscripts/initscript_..bb) in my custom meta layer. This script even after shifting to systemd, is being placed in the /etc/init.d/ folder, and hence doesn't run on boot. I want this to be placed in the /usr/lib/system.d/ folder instead. How would I be able to do this? Is it because this script is an append to initscripts, it by default gets installed under /etc/init.d? If so, where should I place the recipe? Thanks, Megha -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[meta-xilinx-community][PATCH] 1/2] Create a new independant recipe for ze7000 kernel
Upgrade to yocto 2.0 jethro brings compatibility issues between
the default xilinx-kernel configuration and it extention for
for ZE7000 machine.
Signed-off-by: Alexandre Bard
---
conf/machine/ze7000-zynq7.conf| 4 ++--
recipes-kernel/linux/linux-xlnx_3.10.bbappend | 16 --
recipes-kernel/linux/linux-xlnx_3.14.bb | 30 +++
recipes-kernel/linux/linux-xlnx_3.14.bbappend | 24 -
4 files changed, 32 insertions(+), 42 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-xlnx_3.10.bbappend
create mode 100644 recipes-kernel/linux/linux-xlnx_3.14.bb
delete mode 100644 recipes-kernel/linux/linux-xlnx_3.14.bbappend
diff --git a/conf/machine/ze7000-zynq7.conf b/conf/machine/ze7000-zynq7.conf
index 7bd2eab..027f1a1 100644
--- a/conf/machine/ze7000-zynq7.conf
+++ b/conf/machine/ze7000-zynq7.conf
@@ -9,7 +9,7 @@ MACHINE_DEVICETREE := " \
ze7000/ze7000-zynq7.dts \
"
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx"
-PREFERRED_VERSION_linux-xlnx ?= "3.14%"
+PREFERRED_PROVIDER_virtual/kernel = "linux-xlnx"
+PREFERRED_VERSION_linux-xlnx = "3.14%"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-xilinx-emacps"
diff --git a/recipes-kernel/linux/linux-xlnx_3.10.bbappend
b/recipes-kernel/linux/linux-xlnx_3.10.bbappend
deleted file mode 100644
index 69253c7..000
--- a/recipes-kernel/linux/linux-xlnx_3.10.bbappend
+++ /dev/null
@@ -1,16 +0,0 @@
-DESCRIPTION = "Xilinx linux kernel support for Zynq-7 Base TRD 14.5"
-
-MACHINE_DEVICETREE_zc702-zynq7 := " \
-zc702/zc702-zynq7-board.dtsi \
-zc702/zc702-zynq7.dts \
-common/zynq7-base-trd.dtsi \
-zc702/zc702-zynq7-base-trd.dts \
-"
-MACHINE_KCONFIG_zc702-zynq7:=
"common/linux/zynq/xilinx_zynq_base_trd_defconfig_${LINUX_VERSION}.cfg"
-
-MACHINE_DEVICETREE_zc706-zynq7 := " \
-zc706/zc706-zynq7-board.dtsi \
-zc706/zc706-zynq7.dts \
-zc706/zc706-zynq7-pcie-trd-qspi.dts \
-"
-MACHINE_KCONFIG_zc706-zynq7:=
"common/linux/zynq/xilinx_zynq_base_trd_defconfig_${LINUX_VERSION}.cfg"
diff --git a/recipes-kernel/linux/linux-xlnx_3.14.bb
b/recipes-kernel/linux/linux-xlnx_3.14.bb
new file mode 100644
index 000..b258cb2
--- /dev/null
+++ b/recipes-kernel/linux/linux-xlnx_3.14.bb
@@ -0,0 +1,30 @@
+require recipes-kernel/linux/linux-yocto.inc
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+
+### ZE7000 machine configuration ###
+KBRANCH_ze7000-zynq7 = "zx3-v3.14"
+SRCREV_ze7000-zynq7 = "${AUTOREV}"
+SRC_URI_ze7000-zynq7 =
"git://github.com/netmodule/kernel-zx3.git;protocol=https;branch=${KBRANCH}"
+
+SRC_URI_append_ze7000-zynq7 = " \
+file://defconfig \
+"
+
+
+### PM3 machine configuration ###
+KBRANCH_zx3-pm3-zynq7 = "zx3-v3.14"
+SRCREV_zx3-pm3-zynq7 = "4ea440987eb3b5a9cb1f3fd50bb63c86703ef438"
+SRC_URI_zx3-pm3-zynq7 =
"git://github.com/netmodule/kernel-zx3.git;protocol=https;branch=${KBRANCH}"
+
+SRC_URI_append_zx3-pm3-zynq7 = " \
+file://defconfig \
+"
+
+
+
+do_configure_append() {
+ # Use a defconfig file if provided instead of appending again and again
+ [ -f ${WORKDIR}/defconfig ] && cp ${WORKDIR}/defconfig ${S}/.config
+}
diff --git a/recipes-kernel/linux/linux-xlnx_3.14.bbappend
b/recipes-kernel/linux/linux-xlnx_3.14.bbappend
deleted file mode 100644
index dd4c2bc..000
--- a/recipes-kernel/linux/linux-xlnx_3.14.bbappend
+++ /dev/null
@@ -1,24 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-### ZE7000 machine configuration ###
-KBRANCH_ze7000-zynq7 = "zx3-v3.14"
-SRCREV_ze7000-zynq7 = "${AUTOREV}"
-SRC_URI_ze7000-zynq7 =
"git://github.com/netmodule/kernel-zx3.git;protocol=https;branch=${KBRANCH}"
-
-SRC_URI_append_ze7000-zynq7 = " \
-file://defconfig \
-"
-
-### PM3 machine configuration ###
-KBRANCH_zx3-pm3-zynq7 = "zx3-v3.14"
-SRCREV_zx3-pm3-zynq7 = "4ea440987eb3b5a9cb1f3fd50bb63c86703ef438"
-SRC_URI_zx3-pm3-zynq7 =
"git://github.com/netmodule/kernel-zx3.git;protocol=https;branch=${KBRANCH}"
-
-SRC_URI_append_zx3-pm3-zynq7 = " \
-file://defconfig \
-"
-
-do_configure_append() {
- # Use a defconfig file if provided instead of appending again and again
- [ -f ${WORKDIR}/defconfig ] && cp ${WORKDIR}/defconfig ${S}/.config
-}
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[meta-xilinx-community][PATCH] 2/2] Remove useless copy of kernel config
Former code from daisy branch copied the kernel config
to the kernel source directory. This is now useless and
creates a issue when bitbake builds the kernel
Signed-off-by: Alexandre Bard
---
recipes-kernel/linux/linux-xlnx_3.14.bb | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/recipes-kernel/linux/linux-xlnx_3.14.bb
b/recipes-kernel/linux/linux-xlnx_3.14.bb
index b258cb2..9a9288b 100644
--- a/recipes-kernel/linux/linux-xlnx_3.14.bb
+++ b/recipes-kernel/linux/linux-xlnx_3.14.bb
@@ -1,5 +1,7 @@
require recipes-kernel/linux/linux-yocto.inc
+LINUX_VERSION_EXTENSION = "-netmodule"
+
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -22,9 +24,3 @@ SRC_URI_append_zx3-pm3-zynq7 = " \
file://defconfig \
"
-
-
-do_configure_append() {
- # Use a defconfig file if provided instead of appending again and again
- [ -f ${WORKDIR}/defconfig ] && cp ${WORKDIR}/defconfig ${S}/.config
-}
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] PL2303 instability on RPi 3 but not on RPi 2
Hi, I am testing an image on a system including a PL2303 (USB to serial bridge) and have noticed an issue on the Raspberry Pi 3. The system will run fine for an hour or two but then the kernel logs the following error: pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 After this there is no more data coming from the USB device and I have to either reboot or disconnect/connect the USB device - neither of which is acceptable in my application. This is on kernel 4.4.9 and it happens only on the Raspberry Pi 3. On Raspberry Pi 2 the exact same firmware runs flawlessly. Has anyone else come across this or have some suggestions on how to solve it? Or how to pinpoint the cause? Thanks, Martin Bergek -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] resolvconf nameserver
Hi, How do I add a dns nameserver ? I am able to ping 8.8.8.8 but not google.com I thought it would be the usual method as in other linux versions such as Ubuntu. But there is no /etc/resolv.conf file. I tried including "resolvconf" to my image. But that only created a directory called "resolv.conf.d" under /etc. The directory has two files called "base" and "head" which don't provide much information. Still trying to find where I could add a nameserver to resolve hostnames ? or there is no other way and I should just add them into /etc/hosts? Thanks, Monica -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Mounting USB drives on a "read-only-rootfs" based system
Hello, New to the list here, so I'm sorry if this question has been asked before, but I couldn't find a direct answer to it. I have a yocto image that was built using the following bb script line: IMAGE_FEATURES += " read-only-rootfs". As this image eventually resides on a static flash device, it must be read-only. However, the system hardware supports removable media (SD card and USB drives), and I'd like to be able to mount and write to those removable drives / partitions for data logging purposes. What needs to be done in order to make the /media directory auto-mountable when a "read-only" image is specified by the build script? Thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] resolvconf nameserver
On 13 June 2016 at 22:47, Rajasekaran, Monica < monica.rajaseka...@us.fujitsu.com> wrote: > I thought it would be the usual method as in other linux versions such as > Ubuntu. But there is no /etc/resolv.conf file. > > Did you try just creating a /etc/resolv.conf with the nameserver entries you want? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system
Afaik usb storage is already automounted by udev on /run/media/, so there's no need to use /media for that purpose. On Mon, Jun 13, 2016 at 2:22 PM, Jeffrey D Boyer wrote: > Hello, > > > > New to the list here, so I’m sorry if this question has been asked before, > but I couldn’t find a direct answer to it. > > > > I have a yocto image that was built using the following bb script line: > IMAGE_FEATURES += " read-only-rootfs". > > > > As this image eventually resides on a static flash device, it must be > read-only. However, the system hardware supports removable media (SD card > and USB drives), and I’d like to be able to mount and write to those > removable drives / partitions for data logging purposes. What needs to be > done in order to make the /media directory auto-mountable when a > “read-only” image is specified by the build script? > > > > Thanks. > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- 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] [[PATCH][error-report-web] 0/8] Allow other type of errors and django 1.8
The next patches enables support of django 1.8 LTS (two patches) and the other
are for enable to display other type of errors not only task related ones based
on design [1].
Also the changes could be reviewed at,
http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/log/?h=alimon/devel
[1] https://bugzilla.yoctoproject.org/attachment.cgi?id=3214
Aníbal Limón (8):
requirements.txt: Update requeriments for use 1.8 LTS Django version.
urls.py: RedirectView, fix warnings about change of default value in
django 1.9
Post/models.py: Increase the TASK field length
Post/migrations/0003_auto_20150603_0913.py: Replace tabs for spaces
Post/models.py: Build model add support for Error type.
Post/{models,parser}.py: Add support for receive/store error_type.
views/templates: Add support for display different type of errors
Post/{models,views}.py: Add FAILURE field on BuildFailure model
Post/migrations/0003_auto_20150603_0913.py | 6 +++---
Post/migrations/0004_auto_20160530_1126.py | 20
Post/migrations/0005_build_error_type.py | 19 +++
Post/migrations/0006_buildfailure_failure.py | 28
Post/models.py | 20 +++-
Post/parser.py | 17 ++---
Post/views.py| 17 ++---
project/urls.py | 4 ++--
requirements.txt | 2 +-
templates/error-details.html | 13 -
templates/latest-errors.html | 16
11 files changed, 132 insertions(+), 30 deletions(-)
create mode 100644 Post/migrations/0004_auto_20160530_1126.py
create mode 100644 Post/migrations/0005_build_error_type.py
create mode 100644 Post/migrations/0006_buildfailure_failure.py
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 1/8] requirements.txt: Update requeriments for use 1.8 LTS Django version.
[YOCTO #9733] Signed-off-by: Aníbal Limón --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 9521321..909d054 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,2 +1,2 @@ -Django==1.7.3 +Django<1.9 python-Levenshtein==0.12.0 -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 4/8] Post/migrations/0003_auto_20150603_0913.py: Replace tabs for spaces
When try to migrate using python3 it raises an exception because found tabs inside the migration. Signed-off-by: Aníbal Limón --- Post/migrations/0003_auto_20150603_0913.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Post/migrations/0003_auto_20150603_0913.py b/Post/migrations/0003_auto_20150603_0913.py index 321f09f..f936883 100644 --- a/Post/migrations/0003_auto_20150603_0913.py +++ b/Post/migrations/0003_auto_20150603_0913.py @@ -34,9 +34,9 @@ def add_lev_distance_data(apps, schema_editor): while offset < count: objs = BuildFailure.objects.all()[offset : offset + pagesize] for f in objs: - if f.LEV_DISTANCE is None: - f.LEV_DISTANCE = calc_lev_distance(f) - f.save() +if f.LEV_DISTANCE is None: +f.LEV_DISTANCE = calc_lev_distance(f) +f.save() del objs offset = offset + pagesize -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 5/8] Post/models.py: Build model add support for Error type.
In order to support other errors not only Recipe ones adds
a ERROR_TYPE field to the Build model defaults to "Recipe".
Add a class for store BuildErrorType currently supported
Recipe, Core, Bitbake selftest and OE selftest.
[YOCTO #7583]
Signed-off-by: Aníbal Limón
---
Post/migrations/0005_build_error_type.py | 19 +++
Post/models.py | 7 +++
2 files changed, 26 insertions(+)
create mode 100644 Post/migrations/0005_build_error_type.py
diff --git a/Post/migrations/0005_build_error_type.py
b/Post/migrations/0005_build_error_type.py
new file mode 100644
index 000..96cdf8c
--- /dev/null
+++ b/Post/migrations/0005_build_error_type.py
@@ -0,0 +1,19 @@
+# -*- coding: utf-8 -*-
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('Post', '0004_auto_20160530_1126'),
+]
+
+operations = [
+migrations.AddField(
+model_name='build',
+name='ERROR_TYPE',
+field=models.CharField(default=b'Recipe', max_length=64),
+),
+]
diff --git a/Post/models.py b/Post/models.py
index 84f8abf..f8d9916 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -11,6 +11,12 @@ from datetime import datetime
import Levenshtein
+class BuildErrorType(object):
+RECIPE = "Recipe"
+BITBAKE_CORE = "Core"
+BITBAKE_SELFTEST = "Bitbake selftest"
+OE_SELFTEST = "OE selftest"
+
# Create your models here.
class Build(models.Model):
DATE = models.DateTimeField('Submit date', blank=True, null=True)
@@ -25,6 +31,7 @@ class Build(models.Model):
NAME = models.CharField(max_length=50)
EMAIL = models.CharField(max_length=50)
LINK_BACK = models.TextField(max_length=300, blank=True, null=True)
+ERROR_TYPE = models.CharField(max_length=64, default=BuildErrorType.RECIPE)
class BuildFailure(models.Model):
TASK = models.CharField(max_length=1024)
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 6/8] Post/{models, parser}.py: Add support for receive/store error_type.
For compatibility reasons if error_type isn't specified in the JSON
payload use BuildErrorType.RECIPE by default.
[YOCTO #7584]
Signed-off-by: Aníbal Limón
---
Post/models.py | 10 ++
Post/parser.py | 11 +--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Post/models.py b/Post/models.py
index f8d9916..bec2abd 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -17,6 +17,16 @@ class BuildErrorType(object):
BITBAKE_SELFTEST = "Bitbake selftest"
OE_SELFTEST = "OE selftest"
+@staticmethod
+def is_supported(error_type):
+if error_type == BuildErrorType.RECIPE or \
+error_type == BuildErrorType.BITBAKE_CORE or \
+error_type == BuildErrorType.BITBAKE_SELFTEST or \
+error_type == BuildErrorType.OE_SELFTEST:
+return True
+
+return False
+
# Create your models here.
class Build(models.Model):
DATE = models.DateTimeField('Submit date', blank=True, null=True)
diff --git a/Post/parser.py b/Post/parser.py
index 599afde..295870f 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -8,7 +8,7 @@
# Licensed under the MIT license, see COPYING.MIT for details
import json, re
-from Post.models import Build, BuildFailure
+from Post.models import Build, BuildFailure, BuildErrorType
from django.conf import settings
from django.utils import timezone
from django.core.urlresolvers import reverse
@@ -40,6 +40,7 @@ class Parser:
if self.contains_tags(jsondata) == True:
return { 'error' : 'Invalid characters in json' }
+error_desc = ""
b = Build.objects.create()
try:
b.MACHINE = str(jsondata['machine'])
@@ -53,6 +54,12 @@ class Parser:
b.EMAIL = str(jsondata['email'])
b.LINK_BACK = jsondata.get("link_back", None)
+error_type = jsondata.get("error_type", None) or
BuildErrorType.RECIPE
+if not BuildErrorType.is_supported(error_type):
+error_desc = "Unsupported error_type %s" % error_type
+raise ""
+b.ERROR_TYPE = error_type
+
# Extract the branch and commit
g = re.match(r'(.*): (.*)', jsondata['branch_commit'])
@@ -68,7 +75,7 @@ class Parser:
b.save()
failures = jsondata['failures']
except:
-return { 'error' : "Problem reading json payload" }
+return { 'error' : "Problem reading json payload, %s" % error_desc
}
for fail in failures:
if len(fail) > int(settings.MAX_UPLOAD_SIZE):
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 2/8] urls.py: RedirectView, fix warnings about change of default value in django 1.9
RemovedInDjango19Warning: Default value of 'RedirectView.permanent' will
change from True to False in Django 1.9. Set an explicit value to
silence this warning.
url(r'^$', RedirectView.as_view(pattern_name="main")),
RemovedInDjango19Warning: Default value of 'RedirectView.permanent' will
change from True to False in Django 1.9. Set an explicit value to
silence this warning.
url(r'^Errors/Search/Args/$',
RedirectView.as_view(pattern_name="Post.views.search",query_string=True),
{'mode':results_mode.SEARCH }),
[YOCTO #9733]
Signed-off-by: Aníbal Limón
---
project/urls.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/project/urls.py b/project/urls.py
index 7b6f643..0e8f39c 100644
--- a/project/urls.py
+++ b/project/urls.py
@@ -37,7 +37,7 @@ urlpatterns = patterns('',
url(r'^(?i)ClientPost/JSON/$', 'Post.views.addData', { 'return_json' :
True }),
url(r'^(?i)Errors/$', 'Post.views.default', name="main"),
url(r'^(?i)Statistics/$', TemplateView.as_view(template_name="home.html"),
name = "statistics"),
-url(r'^$', RedirectView.as_view(pattern_name="main")),
+url(r'^$', RedirectView.as_view(pattern_name="main", permanent=True)),
# Url for backwards compatibility with old search links
-url(r'^Errors/Search/Args/$',
RedirectView.as_view(pattern_name="Post.views.search",query_string=True),
{'mode':results_mode.SEARCH }),
+url(r'^Errors/Search/Args/$',
RedirectView.as_view(pattern_name="Post.views.search",query_string=True,permanent=True),
{'mode':results_mode.SEARCH }),
)
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 3/8] Post/models.py: Increase the TASK field length
Now bitbake exception/errors can be published into ERW so
TASK in bitbake is the command line executed.
[YOCTO #7583]
Signed-off-by: Aníbal Limón
---
Post/migrations/0004_auto_20160530_1126.py | 20
Post/models.py | 2 +-
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644 Post/migrations/0004_auto_20160530_1126.py
diff --git a/Post/migrations/0004_auto_20160530_1126.py
b/Post/migrations/0004_auto_20160530_1126.py
new file mode 100644
index 000..936454d
--- /dev/null
+++ b/Post/migrations/0004_auto_20160530_1126.py
@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-
+from __future__ import unicode_literals
+
+from django.db import models, migrations
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('Post', '0003_auto_20150603_0913'),
+]
+
+operations = [
+migrations.AlterField(
+model_name='buildfailure',
+name='TASK',
+field=models.CharField(max_length=1024),
+preserve_default=True,
+),
+]
diff --git a/Post/models.py b/Post/models.py
index d1bae38..84f8abf 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -27,7 +27,7 @@ class Build(models.Model):
LINK_BACK = models.TextField(max_length=300, blank=True, null=True)
class BuildFailure(models.Model):
-TASK = models.CharField(max_length=200)
+TASK = models.CharField(max_length=1024)
RECIPE= models.CharField(max_length=250)
RECIPE_VERSION = models.CharField(max_length=200)
ERROR_DETAILS = models.TextField(max_length=int(settings.MAX_UPLOAD_SIZE))
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 7/8] views/templates: Add support for display different type of errors
Now we have a set of different type of errors not only Recipe ones
this change enable support for display it based on design did by
Belen Barros [1].
[YOCTO #7583]
[1] https://bugzilla.yoctoproject.org/attachment.cgi?id=3214
Signed-off-by: Aníbal Limón
---
Post/views.py| 16 +---
templates/error-details.html | 13 -
templates/latest-errors.html | 19 +++
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/Post/views.py b/Post/views.py
index 0455baa..6b57977 100644
--- a/Post/views.py
+++ b/Post/views.py
@@ -134,18 +134,13 @@ def search(request, mode=results_mode.LATEST, **kwargs):
'field' : 'BUILD__DATE',
'disable_toggle' : True,
},
-{'name': 'Recipe',
- 'clclass' : 'recipe',
- 'field' : 'RECIPE',
+{'name': 'Error type',
+ 'clclass' : 'error_type',
+ 'field' : 'BUILD__ERROR_TYPE',
'disable_toggle' : True,
},
-{'name': 'Recipe version',
- 'clclass': 'recipe_version',
- 'field' : 'RECIPE_VERSION',
-},
-{'name': 'Task',
- 'clclass': 'task',
- 'field' : 'TASK',
+{'name': 'Failure',
+ 'clclass': 'failure',
'disable_toggle' : True,
},
{'name': 'Machine',
@@ -156,7 +151,6 @@ def search(request, mode=results_mode.LATEST, **kwargs):
{'name': 'Distro',
'clclass': 'distro',
'field': 'BUILD__DISTRO',
- 'disable_toggle' : True,
},
{'name': 'Build system',
'clclass': 'build_sys',
diff --git a/templates/error-details.html b/templates/error-details.html
index 62ec75f..e5bf758 100644
--- a/templates/error-details.html
+++ b/templates/error-details.html
@@ -9,7 +9,11 @@
-{{detail.RECIPE}}-{{detail.RECIPE_VERSION}}
{{detail.TASK}}
+
+{% if detail.BUILD.ERROR_TYPE == "Recipe" %}
+{{detail.RECIPE}}-{{detail.RECIPE_VERSION}}
+{% endif %}
+{{detail.TASK}}
{{detail.ERROR_DETAILS}}
@@ -20,12 +24,19 @@
Submitted on:
{{ detail.BUILD.DATE|date:"d/m/y H:i"}}
+Error type:
+{{ detail.BUILD.ERROR_TYPE }}
+{% if detail.BUILD.ERROR_TYPE == "Recipe" %}
Task:
{{ detail.TASK }}
Recipe:
{{detail.RECIPE }}
Recipe version:
{{ detail.RECIPE_VERSION }}
+{% else %}
+Command:
+{{ detail.TASK }}
+{% endif %}
Machine:
{{ detail.BUILD.MACHINE }}
Distro:
diff --git a/templates/latest-errors.html b/templates/latest-errors.html
index 56f612a..77a54af 100644
--- a/templates/latest-errors.html
+++ b/templates/latest-errors.html
@@ -127,18 +127,21 @@
{% url "details" build_fail.id as details_url %}
{{
build_fail.BUILD.DATE|date:"d/m/y H:i"}}
-{{
build_fail.RECIPE }}
-
-
+
+{{
build_fail.BUILD.ERROR_TYPE }}
+
+
- 13 %}class="tooltip-me"
data-toggle="tooltip" title="{{ build_fail.RECIPE_VERSION }}"{%endif%}>{{
build_fail.RECIPE_VERSION|truncatechars:13 }}
-{{ build_fail.TASK
}}
-
-
-
+
+
+{% if build_fail.BUILD.ERROR_TYPE == "Recipe" %}
+{{ build_fail.RECIPE }}:
+{% endif %}
+{{ build_fail.TASK }}
+
{{
build_fail.BUILD.MACHINE }}
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [[PATCH][error-report-web] 8/8] Post/{models, views}.py: Add FAILURE field on BuildFailure model
In order to support filters using django Paginator adds a FAILURE
field by default contains "RECIPE: TASK" when ERROR_TYPE is Recipe
instead contains only "TASK".
[YOCTO #7583]
Signed-off-by: Aníbal Limón
---
Post/migrations/0006_buildfailure_failure.py | 28
Post/models.py | 1 +
Post/parser.py | 6 +-
Post/views.py| 1 +
templates/latest-errors.html | 5 +
5 files changed, 36 insertions(+), 5 deletions(-)
create mode 100644 Post/migrations/0006_buildfailure_failure.py
diff --git a/Post/migrations/0006_buildfailure_failure.py
b/Post/migrations/0006_buildfailure_failure.py
new file mode 100644
index 000..b3e30bf
--- /dev/null
+++ b/Post/migrations/0006_buildfailure_failure.py
@@ -0,0 +1,28 @@
+# -*- coding: utf-8 -*-
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+
+def populate_failure(apps, schema_editor):
+model = apps.get_model("Post", "BuildFailure")
+for build_failure in model.objects.all():
+if build_failure.BUILD.ERROR_TYPE == "Recipe":
+build_failure.FAILURE = "%s: %s" \
+(build_failure.RECIPE, build_failure.TASK)
+else:
+build_failure.FAILURE = build_failure.TASK
+build_failure.save()
+
+class Migration(migrations.Migration):
+dependencies = [
+('Post', '0005_build_error_type'),
+]
+
+operations = [
+migrations.AddField(
+model_name='buildfailure',
+name='FAILURE',
+field=models.CharField(max_length=1024, blank=True),
+),
+migrations.RunPython(populate_failure)
+]
diff --git a/Post/models.py b/Post/models.py
index bec2abd..07694fe 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -50,6 +50,7 @@ class BuildFailure(models.Model):
ERROR_DETAILS = models.TextField(max_length=int(settings.MAX_UPLOAD_SIZE))
BUILD = models.ForeignKey(Build)
LEV_DISTANCE = models.IntegerField(blank=True, null=True)
+FAILURE = models.CharField(max_length=1024, blank=True)
def get_similar_fails(self):
if self.LEV_DISTANCE is None:
diff --git a/Post/parser.py b/Post/parser.py
index 295870f..2ef35c1 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -92,7 +92,11 @@ class Parser:
recipe = package
recipe_version = "unknown"
-f = BuildFailure(TASK = str(fail['task']), RECIPE = recipe,
RECIPE_VERSION = recipe_version, ERROR_DETAILS = fail['log'].encode('utf-8'),
BUILD = b)
+if b.ERROR_TYPE = "Recipe":
+failure = "%s: %s" % (recipe, str(fail['task']))
+else:
+failure = str(fail['task'])
+f = BuildFailure(TASK = str(fail['task']), RECIPE = recipe,
RECIPE_VERSION = recipe_version, ERROR_DETAILS = fail['log'].encode('utf-8'),
BUILD = b, FAILURE = failure)
f.save()
diff --git a/Post/views.py b/Post/views.py
index 6b57977..41f0e2b 100644
--- a/Post/views.py
+++ b/Post/views.py
@@ -141,6 +141,7 @@ def search(request, mode=results_mode.LATEST, **kwargs):
},
{'name': 'Failure',
'clclass': 'failure',
+ 'field' : 'FAILURE',
'disable_toggle' : True,
},
{'name': 'Machine',
diff --git a/templates/latest-errors.html b/templates/latest-errors.html
index 77a54af..a4418b5 100644
--- a/templates/latest-errors.html
+++ b/templates/latest-errors.html
@@ -136,10 +136,7 @@
-{% if build_fail.BUILD.ERROR_TYPE == "Recipe" %}
-{{ build_fail.RECIPE }}:
-{% endif %}
-{{ build_fail.TASK }}
+{{ build_fail.FAILURE }}
{{
build_fail.BUILD.MACHINE }}
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system
Hi, you can adjust the mount behaviour for example in your udev mount script (if you use udev). If you have a fixed name/mountpoint for your media you can pre-create that folder (for example /media/data-logging) and let udev's mount.sh mount media which matches your criteria to that path. kind regards, richard On 06/13/2016 11:22 PM, Jeffrey D Boyer wrote: > Hello, > > > > New to the list here, so I’m sorry if this question has been asked > before, but I couldn’t find a direct answer to it. > > > > I have a yocto image that was built using the following bb script line: > IMAGE_FEATURES += " read-only-rootfs". > > > > As this image eventually resides on a static flash device, it must be > read-only. However, the system hardware supports removable media (SD > card and USB drives), and I’d like to be able to mount and write to > those removable drives / partitions for data logging purposes. What > needs to be done in order to make the /media directory auto-mountable > when a “read-only” image is specified by the build script? > > > > Thanks. > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
