Re: [yocto] [OE-core] Yocto Project Status WW09’17
On 02/28/2017 04:09 AM, akuster808 wrote: >> o rpm v4/dnf to replace rpm v5/smart? >> > IMHO, we should include dnf in 2.3 so folks can start playing with it > and remove smart in 2.4. Apologies, but there will not be a transitional period for this. Making smart and dnf coexist is hard and will require months of work. Anyone who wants to play with dnf, can do it now: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/dnf-rpm4 Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project Status WW09’17
On 28 February 2017 at 02:09, akuster808 wrote: > o rpm v4/dnf to replace rpm v5/smart? > > IMHO, we should include dnf in 2.3 so folks can start playing with it and > remove smart in 2.4. Not possible: dnf requires rpm4. In the current work there is no attempt at letting the user pick rpm4 or rpm5. Personally I think we should leave this for 2.4M1. It's a major change and needs many eyes. > o Separate out elderly GPLv2 into a separate layer? > > yes, but maybe not for 2.3 if its a large effort. I suspect for 2.3 this would be a matter of moving a few recipes into another layer, which for testing purposes the autobuilder always includes. So that should just be a matter of move recipes, layer version bump, update autobuilder to conditionally fetch the layer. o Graphics stack vulkan changes? > > The "Go" changes hit before the vulkan. Both should have the same rules > applied which ever way the decision goes. They should be considered independently. Vulkan current requires a development snapshot of Mesa, needs tweaking of PACKAGECONFIG, and the only supported BSP doesn't work out of the box. Seeing it work is a great step forward but there's many open questions and whilst I'd love to put "Vulkan support" on the 2.3 release notes I'm not yet convinced we're ready. I guess it comes down to how long it takes the current queue to stabilise: the current fire is over the testing of minimal eSDKs. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] yocto-docs: kernel-dev, update "3.19" versions to "4.4"
On Mon, 27 Feb 2017, Bruce Ashfield wrote: > > > On Mon, Feb 27, 2017 at 5:07 AM, Robert P. J. Day > wrote: > > Update the remaining references to kernel version 3.19 to version 4.4, > restricted to the section "kernel-dev-common.xml". > > I just sent a patch to drop 4.4 from master. I'd suggest 4.9 as a > version to use that will persist in master for a bit longer. if my earlier patches for kernel-dev manual have not already been applied, feel free to toss them, and i'll resubmit a newer patch right from the beginning with updated version numbers and everything else. 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] Intermittent Kernel Boot Hang 4.8/Intel Z5 Atom
Advice on how to proceed with this? Current Yocto (morty) kernels include 4.1, 4.4 that work and 4.8 that doesn't. Intermittent hang during power-on kernel boots before/without any diagnostic output. Can I compile the kernel to output more than boot options allow? I could fix this BSP to 4.4 (if that will hang around) and this is old hardware so it won't hang around for more than a few years. I can't find anything that appears related to this on the web. Not sure about going through intermediate kernel versions with yocto other than going back to older versions of poky for ones that are missing. I thought about the Linux kernel site but nothing in bugzilla or archives and this may not be of sufficient interest without more information. Thanks, Chris From: yocto-boun...@yoctoproject.org on behalf of Chris Trobridge Sent: 24 February 2017 12:10 To: Yocto List Subject: [yocto] Intermittent Kernel Boot Hang 4.8/Intel Z5 Atom Since switching kernel to 4.8 (Morty) I have noticed that sometimes my Intel Atom hardware (Pokini) doesn't boot Linux. Specifically, syslinux runs fine and starts the kernel but this then hangs immediately after displaying "Booting the kernel.", producing no further output. This is typical output, with one of my attempts to produce more output from the kernel via serial: > /vmlinuz initrd=/initrd LABEL=boot root=/dev/ram0 video=efifb:off > video=640x480 console=ttyS0,115200 verbose Loading /vmlinuz... ok Loading /initrd...ok The issue seem to occur with some probability after powering the hardware but I've not seen it occur after a reboot. 4.1 and 4.4.36 are reliable and do not have any issues booting. I've been looking through bugs/issue but not found anything relevant. Does anyone know of issues that I might not have found that would apply? I've also been looking at how to get more diagnostics out of the boot. I've tried a few suggested kernel boot parameters but nothing has helped so far. It seems to go wrong too early. Do I need to re-build the kernel to produce more output at the early stage it fails? Thanks, Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto yocto Info Page lists.yoctoproject.org Discussion of all things about the Yocto Project. Read our Community Guidelines or learn more about how to participate in other community discussions. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] error while compiling external module in Krogoth branch
Hi,
I am using krogoth branch of meta-altera.
in meta/classes/kernel-yocto.bbclass file
SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches
do_kernel_configcheck do_kernel_checkout do_shared_workdir do_fetch
do_unpack do_patch"
if i remove "do_shared_workdir" . it worked. is this the right way.
Thanks.
On Tue, Feb 28, 2017 at 12:46 PM, Khem Raj wrote:
>
> On Tue, Feb 21, 2017 at 6:31 AM praveen vattipalli
> wrote:
>
>> Hi All,
>> I am using poky-krogoth source and meta-altera layer. I am building
>> kernel locally using externalsrc. while building external module i am
>> getting error.
>>
>
> Which branch of meta-altera are you using
>
>>
>>
>>
>> ERROR: Task do_make_scripts in /home/praveenk/source/
>> platform/build/../meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
>> depends
>> upon non-existent task do_shared_workdir in /home/praveenk/source/
>> platform/build/../meta-altera/recipes-kernel/linux/linux-
>> altera-ltsi_4.1.22.bb
>> ERROR: Command execution failed: 1
>>
>> linux.bb contains
>>
>> LINUX_VERSION = "4.1.22"
>> LINUX_VERSION_SUFFIX = "-ltsi"
>>
>> include linux-altera.inc
>>
>> SRC_URI = "file://${EXTERNALSRC}"
>>
>> LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=
>> d7810fab7487fb0aad327b76f1be7cd7"
>>
>> BUILD_DEFCONFIG = "socfpga_defconfig"
>> EXTERNALSRC = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
>> EXTERNALSRC_BUILD = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
>>
>> SRCREV_pn-${PN} = "${AUTOREV}"
>>
>> S= "${EXTERNALSRC}"
>>
>> hello-mod.bb contains
>>
>> SUMMARY = "Example of how to build an external Linux kernel module"
>> LICENSE = "GPLv2"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
>>
>> inherit module
>>
>> SRC_URI = "file://Makefile \
>>file://hello.c \
>>file://COPYING \
>> "
>>
>>
>> S = "${WORKDIR}"
>>
>> # The inherit of module.bbclass will automatically name module packages
>> with
>> # "kernel-module-" prefix as required by the oe-core build environment.
>> ~
>>
>>
>> Am I missing anything?
>>
>> Thanks,
>> Praveen.
>> --
>> ___
>> 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] error while compiling external module in Krogoth branch
On Tue, 2017-02-28 at 17:57 +0530, praveen vattipalli wrote:
> Hi,
> I am using krogoth branch of meta-altera.
> in meta/classes/kernel-yocto.bbclass file
> SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches
> do_kernel_configcheck do_kernel_checkout do_shared_workdir do_fetch
> do_unpack do_patch"
>
> if i remove "do_shared_workdir" . it worked. is this the right way.
> Thanks.
I think so, a similar change went into post-krogoth releases:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/kernel-yocto.bbclass?id=1373b528964e47c2b0a154e4ca749e64f7f1a341
Cheers,
Andre'
>
> On Tue, Feb 28, 2017 at 12:46 PM, Khem Raj wrote:
>
> >
> > On Tue, Feb 21, 2017 at 6:31 AM praveen vattipalli > om>
> > wrote:
> >
> > > Hi All,
> > > I am using poky-krogoth source and meta-altera layer. I am building
> > > kernel locally using externalsrc. while building external module i am
> > > getting error.
> > >
> >
> > Which branch of meta-altera are you using
> >
> > >
> > >
> > >
> > > ERROR: Task do_make_scripts in /home/praveenk/source/
> > > platform/build/../meta-skeleton/recipes-kernel/hello-mod/hello-
> > > mod_0.1.bb depends
> > > upon non-existent task do_shared_workdir in /home/praveenk/source/
> > > platform/build/../meta-altera/recipes-kernel/linux/linux-
> > > altera-ltsi_4.1.22.bb
> > > ERROR: Command execution failed: 1
> > >
> > > linux.bb contains
> > >
> > > LINUX_VERSION = "4.1.22"
> > > LINUX_VERSION_SUFFIX = "-ltsi"
> > >
> > > include linux-altera.inc
> > >
> > > SRC_URI = "file://${EXTERNALSRC}"
> > >
> > > LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=
> > > d7810fab7487fb0aad327b76f1be7cd7"
> > >
> > > BUILD_DEFCONFIG = "socfpga_defconfig"
> > > EXTERNALSRC = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
> > > EXTERNALSRC_BUILD = "${TOPDIR}/../meta-altera/recipes-
> > > kernel/linux/files"
> > >
> > > SRCREV_pn-${PN} = "${AUTOREV}"
> > >
> > > S= "${EXTERNALSRC}"
> > >
> > > hello-mod.bb contains
> > >
> > > SUMMARY = "Example of how to build an external Linux kernel module"
> > > LICENSE = "GPLv2"
> > > LIC_FILES_CHKSUM =
> > > "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
> > >
> > > inherit module
> > >
> > > SRC_URI = "file://Makefile \
> > > file://hello.c \
> > > file://COPYING \
> > > "
> > >
> > >
> > > S = "${WORKDIR}"
> > >
> > > # The inherit of module.bbclass will automatically name module
> > > packages
> > > with
> > > # "kernel-module-" prefix as required by the oe-core build
> > > environment.
> > > ~
> > >
> > >
> > > Am I missing anything?
> > >
> > > Thanks,
> > > Praveen.
> > > --
> > > ___
> > > 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] error while compiling external module in Krogoth branch
On Tue, Feb 28, 2017 at 5:27 AM praveen vattipalli
wrote:
> Hi,
> I am using krogoth branch of meta-altera.
> in meta/classes/kernel-yocto.bbclass file
> SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches
> do_kernel_configcheck do_kernel_checkout do_shared_workdir do_fetch
> do_unpack do_patch"
>
> if i remove "do_shared_workdir" . it worked. is this the right way.
>
Please send this as a patch
>
> Thanks.native']
> NOTE: Runtime target 'packagegroup-meshwifi' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['packagegroup-meshwifi',
> 'plumewifi', 'openvswitch-native', 'util-linux-uuidgen-native']
> ERROR: Required build target 'comcast-br
>
> On Tue, Feb 28, 2017 at 12:46 PM, Khem Raj wrote:
>
>
> On Tue, Feb 21, 2017 at 6:31 AM praveen vattipalli
> wrote:
>
> Hi All,
> I am using poky-krogoth source and meta-altera layer. I am building kernel
> locally using externalsrc. while building external module i am getting
> error.
>
>
> Which branch of meta-altera are you using
>
>
>
>
> ERROR: Task do_make_scripts in
> /home/praveenk/source/platform/build/../meta-skeleton/recipes-kernel/hello-mod/
> hello-mod_0.1.bb depends upon non-existent task do_shared_workdir in
> /home/praveenk/source/platform/build/../meta-altera/recipes-kernel/linux/
> linux-altera-ltsi_4.1.22.bb
> ERROR: Command execution failed: 1
>
> linux.bb contains
>
> LINUX_VERSION = "4.1.22"
> LINUX_VERSION_SUFFIX = "-ltsi"
>
> include linux-altera.inc
>
> SRC_URI = "file://${EXTERNALSRC}"
>
> LIC_FILES_CHKSUM =
> "file://${S}/COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>
> BUILD_DEFCONFIG = "socfpga_defconfig"
> EXTERNALSRC = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
> EXTERNALSRC_BUILD = "${TOPDIR}/../meta-altera/recipes-kernel/linux/files"
>
> SRCREV_pn-${PN} = "${AUTOREV}"
>
> S= "${EXTERNALSRC}"
>
> hello-mod.bb contains
>
> SUMMARY = "Example of how to build an external Linux kernel module"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
>
> inherit module
>
> SRC_URI = "file://Makefile \
>file://hello.c \
>file://COPYING \
> "
>
>
> S = "${WORKDIR}"
>
> # The inherit of module.bbclass will automatically name module packages
> with
> # "kernel-module-" prefix as required by the oe-core build environment.
> ~
>
>
> Am I missing anything?
>
> Thanks,
> Praveen.
> --
> ___
> 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] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> common.test_signatures: Test executed in BSP and DISTRO layers to review
> doesn't comes with recipes that changes the signatures.
I have a question about the goal for this test: is it meant to detect
layers which incorrectly change the signatures of allarch recipes or
recipes which share the same tune flags with other machines?
Let's take MACHINE=edison as an example.
Modifying allarch creates a conflict with basically all other machines
in a distro. Example for something not allowed:
VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo
\n"
This can be detected by comparing against OE-core, but only when testing
with MACHINE=edison.
More difficult to detect is modifying recipes with the same tune flags,
which is the majority of the recipes. MACHINE=edison and
MACHINE=intel-core2-32 both compile for the same target architecture, so
something like this is incorrect:
do_install_append_pn-base-files_edison () {
echo "Built for Edison" >>${D}${sysconfdir}/motd
}
This can only be detected when testing with both MACHINE=edison and
MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different
tune flags (haven't checked).
My point is, the test probably needs to be extended to run with a set of
machines, and that set of machines must be broad enough to cover a
variety of common tune flags.
The corresponding selftest, test_sstate_sametune_samesigs in
sstatetests.py, has the same limitation of its scope, i.e. doesn't
actually test with real machine definitions.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On 02/28/2017 02:09 PM, Patrick Ohly wrote:
> On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
>> common.test_signatures: Test executed in BSP and DISTRO layers to review
>> doesn't comes with recipes that changes the signatures.
>
> I have a question about the goal for this test: is it meant to detect
> layers which incorrectly change the signatures of allarch recipes or
> recipes which share the same tune flags with other machines?
The requirement is DISTRO and BSP layers aren't allowed to automatically
change the MACHINE or DISTRO variable that causes the signatures to change.
>
> Let's take MACHINE=edison as an example.
>
> Modifying allarch creates a conflict with basically all other machines
> in a distro. Example for something not allowed:
> VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo
> \n"
>
> This can be detected by comparing against OE-core, but only when testing
> with MACHINE=edison.
>
> More difficult to detect is modifying recipes with the same tune flags,
> which is the majority of the recipes. MACHINE=edison and
> MACHINE=intel-core2-32 both compile for the same target architecture, so
> something like this is incorrect:
> do_install_append_pn-base-files_edison () {
> echo "Built for Edison" >>${D}${sysconfdir}/motd
> }
>
> This can only be detected when testing with both MACHINE=edison and
> MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different
> tune flags (haven't checked).
>
> My point is, the test probably needs to be extended to run with a set of
> machines, and that set of machines must be broad enough to cover a
> variety of common tune flags.
It is expected to change recipe signatures when the machine change, this
leaves me other question. what signatures are expected to change when
set a different MACHINE?
Anibal
>
> The corresponding selftest, test_sstate_sametune_samesigs in
> sstatetests.py, has the same limitation of its scope, i.e. doesn't
> actually test with real machine definitions.
>
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4 0/2] Update LIC_FILES_CKHSUMs
The following two recipes use the OE-Core License file in additional to the COPYING.MIT, these are really purely MIT so don't use the OE-Core LICENSE file. This was discovered when a clarification statement was added to the OE-Core LICENSE file. Sau! Saul Wold (2): qt-demo-init: LICENSE is straight MIT so just use COPYING.MIT qt4e-demo-image: LICENSE is straight MIT so just use COPYING.MIT recipes-qt4/images/qt4e-demo-image.bb | 3 +-- recipes-qt4/qt-demo/qt-demo-init_0.1.bb | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4 1/2] qt-demo-init: LICENSE is straight MIT so just use COPYING.MIT
The OE-Core LICENSE is mostly MIT, but should not be used as a checksum
file for a purely MIT licensed package.
Signed-off-by: Saul Wold
---
recipes-qt4/qt-demo/qt-demo-init_0.1.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/recipes-qt4/qt-demo/qt-demo-init_0.1.bb
b/recipes-qt4/qt-demo/qt-demo-init_0.1.bb
index aa1b0b6..12b0cd9 100644
--- a/recipes-qt4/qt-demo/qt-demo-init_0.1.bb
+++ b/recipes-qt4/qt-demo/qt-demo-init_0.1.bb
@@ -3,8 +3,7 @@ LICENSE = "MIT"
SRC_URI = "file://qtdemo-init"
PR = "r3"
-LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
-
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
S = "${WORKDIR}"
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt4 2/2] qt4e-demo-image: LICENSE is straight MIT so just use COPYING.MIT
The OE-Core LICENSE is mostly MIT, but should not be used as a checksum
file for a purely MIT licensed package.
Signed-off-by: Saul Wold
---
recipes-qt4/images/qt4e-demo-image.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/recipes-qt4/images/qt4e-demo-image.bb
b/recipes-qt4/images/qt4e-demo-image.bb
index 4451848..22e1bf9 100644
--- a/recipes-qt4/images/qt4e-demo-image.bb
+++ b/recipes-qt4/images/qt4e-demo-image.bb
@@ -2,8 +2,7 @@ DESCRIPTION = "An image that will launch into the demo
application for the embed
LICENSE = "MIT"
PR = "r3"
-LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
-
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
IMAGE_INSTALL += "\
${CORE_IMAGE_BASE_INSTALL} \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Tue, 2017-02-28 at 14:33 -0600, Aníbal Limón wrote:
>
> On 02/28/2017 02:09 PM, Patrick Ohly wrote:
> > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> >> common.test_signatures: Test executed in BSP and DISTRO layers to review
> >> doesn't comes with recipes that changes the signatures.
> >
> > I have a question about the goal for this test: is it meant to detect
> > layers which incorrectly change the signatures of allarch recipes or
> > recipes which share the same tune flags with other machines?
>
> The requirement is DISTRO and BSP layers aren't allowed to automatically
> change the MACHINE or DISTRO variable that causes the signatures to change.
I do not fully understand this explanation. Can you give an example for
the kind of misbehavior what the test is meant to catch?
> > Let's take MACHINE=edison as an example.
> >
> > Modifying allarch creates a conflict with basically all other machines
> > in a distro. Example for something not allowed:
> > VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo
> > /var/foo \n"
> >
> > This can be detected by comparing against OE-core, but only when testing
> > with MACHINE=edison.
> >
> > More difficult to detect is modifying recipes with the same tune flags,
> > which is the majority of the recipes. MACHINE=edison and
> > MACHINE=intel-core2-32 both compile for the same target architecture, so
> > something like this is incorrect:
> > do_install_append_pn-base-files_edison () {
> > echo "Built for Edison" >>${D}${sysconfdir}/motd
> > }
> >
> > This can only be detected when testing with both MACHINE=edison and
> > MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different
> > tune flags (haven't checked).
> >
> > My point is, the test probably needs to be extended to run with a set of
> > machines, and that set of machines must be broad enough to cover a
> > variety of common tune flags.
>
> It is expected to change recipe signatures when the machine change, this
> leaves me other question. what signatures are expected to change when
> set a different MACHINE?
Everything that is machine-specific may change, for example image
recipes and kernel (although even that is a slight simplification, as
meta-intel intentionally shares kernels between different MACHINE
configs).
The real-world test is: can two BSP layers be combined in a single
distro so that one can build first for one MACHINE, then the other (or,
when using multiconfig, even in a single build)? If any shared package
changes as result of changing the MACHINE, then that won't work.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH 0/3] Support range select in patch-list
Selecting multiple items in a patch list must be done manually, one item at a time, providing a poor user experience. These changes add the jquery.tablecheckbox plugin and call it from the patch-list tables to allow users to select single / multiple / all table row(s) by clicking. A function specific to the series view is used to provide the mentioned feature too. [YOCTO #10819] Jose Lamego (3): series.js: support shift-select range jquery.tablecheckbox: add plugin for multiselect functionality patch-list: call tablecheckbox plugin from patch-list htdocs/js/jquery.tablecheckbox.js | 165 ++ htdocs/js/series.js | 31 + patchwork/templates/patchwork/patch-list.html | 2 + 3 files changed, 198 insertions(+) create mode 100644 htdocs/js/jquery.tablecheckbox.js -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH 1/3] series.js: support shift-select range
Selecting multiple patches in a range at the series view must be
performed on one-by-one basis, providing apoor user-experience.
This change allows to select patches in a range by clicking the
first patch, then shift-clicking the last patch in the desired range.
[YOCTO #10819]
Signed-off-by: Jose Lamego
---
htdocs/js/series.js | 31 +++
1 file changed, 31 insertions(+)
diff --git a/htdocs/js/series.js b/htdocs/js/series.js
index c4bbb0e..6571b0e 100644
--- a/htdocs/js/series.js
+++ b/htdocs/js/series.js
@@ -82,6 +82,37 @@ $(document).ready(function(){
})
})
+var lastChecked = null
+var $chkboxes = $( "input[name^='patch_id']" )
+
+$chkboxes.click(function(e){
+if(!lastChecked) {
+lastChecked = this;
+return;
+}
+
+if(e.shiftKey) {
+var start = $chkboxes.index(this);
+var end = $chkboxes.index(lastChecked);
+var min_val = Math.min(start,end)
+var max_val = Math.max(start,end)+1
+
+$chkboxes.slice(min_val, max_val).prop('checked',
lastChecked.checked);
+for (i=min_val; ihttps://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH 2/3] jquery.tablecheckbox: add plugin for multiselect functionality
Selecting multiple items in a patch list must be done manually,
one item at a time, resulting in a poor user experience.
This change adds the jquery.tablecheckbox.js plugin that allows
to select single / multiple / all table row(s) by clicking.
[YOCTO #10819]
Signed-off-by: Jose Lamego
---
htdocs/js/jquery.tablecheckbox.js | 165 ++
1 file changed, 165 insertions(+)
create mode 100644 htdocs/js/jquery.tablecheckbox.js
diff --git a/htdocs/js/jquery.tablecheckbox.js
b/htdocs/js/jquery.tablecheckbox.js
new file mode 100644
index 000..8a50541
--- /dev/null
+++ b/htdocs/js/jquery.tablecheckbox.js
@@ -0,0 +1,165 @@
+(function($) {
+/**
+ * A jQuery plugin that lets you easily enhance data tables with
selectable rows.
+ *
+ *
+ * @author Marco Kerwitz
+ * @seehttps://github.com/kerwitz/jquery.tablecheckbox
+ */
+$.fn.tablecheckbox = function(options) {
+var _private = {
+/**
+ * The configuration of this plugin.
+ *
+ * Overload with custom values when calling the plugin:
+ * $('table').tableCheckbox({selectedRowClass: 'selected-row'});
+ *
+ * @var object
+ */
+config: $.extend({
+// The class that will be applied to selected rows.
+selectedRowClass: 'warning',
+// The selector used to find the checkboxes on the table. You
may customize this in
+// order to match your table layout if it differs from the
assumed one.
+checkboxSelector: 'td:first-of-type
input[type="checkbox"],th:first-of-type input[type="checkbox"]',
+// A callback that is used to determine wether a checkbox is
selected or not.
+isChecked: function($checkbox) {
+return $checkbox.is(':checked');
+}
+}, options),
+/**
+ * Variables used across multiple tables.
+ *
+ * @var object
+ */
+registry: {
+shiftKeyIsPressed: false
+},
+helpers: {
+/**
+ * Returns the selection methods available in the current
browser.
+ *
+ * @author Grinn, http://stackoverflow.com/users/152648/grinn
+ * @author Gert Grenander,
http://stackoverflow.com/users/339850/gert-grenander
+ * @see
http://stackoverflow.com/questions/3169786/clear-text-selection-with-javascript
+ */
+selection: window.getSelection ? window.getSelection() :
document.selection ? document.selection : null,
+/**
+ * Removes any text selection the user made.
+ *
+ * @author Marco Kerwitz
+ */
+removeTextSelection: function() {
+if (!!_private.helpers.selection) {
+_private.helpers.selection.empty
+? _private.helpers.selection.empty()
+: _private.helpers.selection.removeAllRanges();
+}
+},
+/**
+ * Returns wether or not a text selection currently exists.
+ *
+ * @author Marco Kerwitz
+ * @todo This will return false positives when the user
selected text outside of
+ * the table and then tries to select rows.
+ * @return {boolean}
+ */
+hasSelection: function() {
+return !!_private.helpers.selection &&
_private.helpers.selection.toString().length;
+}
+}
+};
+// Initiate a event callback that we can use to tell wether the user
is pressing the shift
+// key or not.
+$(document).on('keydown.tsc keyup.tsc', function(e) {
+_private.registry.shiftKeyIsPressed = e.shiftKey;
+});
+return this.each(function() {
+var $table = $(this),
+$headCheckbox = $table.find('thead tr ' +
_private.config.checkboxSelector),
+$checkboxes = $table.find('tr ' +
_private.config.checkboxSelector).not($headCheckbox),
+$lastRow = [];
+// Listen for changes on the checkbox in the table header and
apply its current state
+// to all checkboxe on the table.
+$headCheckbox.on('change', function(e) {
+var $allRows = $table.find('tbody tr');
+$checkboxes
+.prop('checked', _private.config.isChecked($headCheckbox))
+.trigger('change');
+$table.trigger(
+_private.config.isChecked($headCheckbox) ?
'multirowselect' : 'multirowdeselect',
+
[yocto] [patchwork][PATCH 3/3] patch-list: call tablecheckbox plugin from patch-list
This change calls the tablecheckbox.js plugin to add functionality
in a patch-list to allow user to select single / multiple / all
table row(s) by clicking.
[YOCTO #10819]
Signed-off-by: Jose Lamego
---
patchwork/templates/patchwork/patch-list.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/patchwork/templates/patchwork/patch-list.html
b/patchwork/templates/patchwork/patch-list.html
index ec52231..fe6f99f 100644
--- a/patchwork/templates/patchwork/patch-list.html
+++ b/patchwork/templates/patchwork/patch-list.html
@@ -38,8 +38,10 @@
$(document).ready(function() {
$('#patchlist').stickyTableHeaders();
+$( '.table' ).tablecheckbox();
});
+
{% csrf_token %}
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > common.test_signatures: Test executed in BSP and DISTRO layers to > > review > > doesn't comes with recipes that changes the signatures. > I have a question about the goal for this test: is it meant to detect > layers which incorrectly change the signatures of allarch recipes or > recipes which share the same tune flags with other machines? > > Let's take MACHINE=edison as an example. The test is not for these things. Its using the sstate signatures for something different compared to those other tests. The idea is that if you have a set of layers and generate the signatures for world, then you add say a BSP layer but do not select that MACHINE, the signatures should remain unchanged. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] a new layer that support spdx
Hi all I have submitted a new layer named meta-spdxscanner that can be used to create spdx files to the OpenEmbedded layer index. Compared to the spdx module in oe-core, this layer has features as following: * Easy to use Dosocs2-native has been add into this meta, there is no need to install anything in build server. * Good performance It has better performance than the spdx module in current oe-core, especially in rebuilding. Best regards Lei Maohui -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 04:00 +, Richard Purdie wrote: > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > > > common.test_signatures: Test executed in BSP and DISTRO layers to > > > review > > > doesn't comes with recipes that changes the signatures. > > I have a question about the goal for this test: is it meant to detect > > layers which incorrectly change the signatures of allarch recipes or > > recipes which share the same tune flags with other machines? > > > > Let's take MACHINE=edison as an example. > > The test is not for these things. Its using the sstate signatures for > something different compared to those other tests. > > The idea is that if you have a set of layers and generate the > signatures for world, then you add say a BSP layer but do not select > that MACHINE, the signatures should remain unchanged. That's useful too, of course. Is the "build single distro for different machines" scenario that I described part of the Yocto Compliance 2.0? Should there be tests for it? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
