[yocto] [meta-cgl][PATCH 0/1] Disable autostart of pacemaker
From: Kai Kang Patch to disable autostart of corosync is in review. Kai Kang (1): pacemaker: disable autostart meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb | 2 ++ 1 file changed, 2 insertions(+) -- 2.14.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-cgl][PATCH 1/1] pacemaker: disable autostart
From: Kai Kang
pacemaker requires corosync starts before it. But corosync could not start
without configuration and autostart is disabled. So disable autostart of
pacemaker too.
Signed-off-by: Kai Kang
---
meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
index 3a4a848..37c3b53 100755
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
@@ -88,6 +88,8 @@ FILES_${PN} += " ${datadir}/snmp \
FILES_${PN}-dbg += "${libdir}/corosync/lcrso/.debug"
RDEPENDS_${PN} = "bash python libqb"
+SYSTEMD_AUTO_ENABLE = "disable"
+
SYSTEMD_PACKAGES += "${PN}-remote"
SYSTEMD_SERVICE_${PN} += "pacemaker.service crm_mon.service"
SYSTEMD_SERVICE_${PN}-remote += "pacemaker_remote.service"
--
2.14.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono][PATCH] mono-4.xx: compiling mono 4 with btls requires cmake
>>> >>> Mono requires cmake to build the bundled BoringSSL library. I didn't look >>> why it works in detail but I currently assume that BoringSSL is standalone >>> enough that no additional >>> CMake toolchain settings are required to make it work. >>> >> yeah that probably is a case of bundling which is on rise at app level >> these days, >> >>> One option would be to disable it with `--disable-btls` but I fear that >>> would disable TLS1.2 support >>> (http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support). >>> But I have no way of checking that. >>> >> interesting, do they support any other TLS implementations ? >> > > It is disabled in 5.x builds by default as it breaks the build e.g. > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono/mono-5.4.0.201.inc > > It's probably time to look at a working build with it re-enabled. Patches > welcomed... > > (I did have a quick look at inheriting cmake but that breaks the build too) > I did some more testing. And adding "cmake-native" still doesn't build btls. I guess it need cmake to figure that out. But this means it was never enabled in the first place. So my proposal for the moment is to explicitly set "--disable-btls" for Mono 4 too, this way it builds and it is clear that it is disabled. If somebody figures out how to enable it again. I will send an updated Patch. Pascal -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere
Hi,
I'm trying to get yocto to build the kernel with an in-tree defconfig.
For that I found references to the variable KBUILD_DEFCONFIG_KMACHINE.
However, I've been experiencing that the kernel is being built with
some default defconfig, and not the in-tree one that came with the
kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.
I've looked through all yocto sources for where the
KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
kernel recipe. So I decided to dissect my recipe.
There is a:
inherit kernel
in my recipe for which, besides others, defines how the kernel config
will be selected.
Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
the kernel configuration happens:
kernel_do_configure() {
# fixes extra + in /lib/modules/2.6.37+
# $ scripts/setlocalversion . => +
# $ make kernelversion => 2.6.37
# $ make kernelrelease => 2.6.37+
touch ${B}/.scmversion ${S}/.scmversion
if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
"${B}/.config" ]; then
mv "${S}/.config" "${B}/.config"
fi
# Copy defconfig to .config if .config does not exist. This allows
# recipes to manage the .config themselves in do_configure_prepend().
if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi
${KERNEL_CONFIG_COMMAND}
}
I'm planning a workaround by overriding the do_configure in my recipe
to select the correct defconfig from the kernel. It does seem however
like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to do
the workarounds.
Anyone has experiences with successfully using KBUILD_DEFCONFIG_KMACHINE?
Is it a specific poky feature (I'm not using poky but specific open
embedded layers and bitbake)?
Be Well,
Alan
Ref.
https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono][PATCH] mono-4.xx: compiling mono 4 with btls requires cmake
On 07/11/2017 13:26, Pascal Bach wrote:
Mono requires cmake to build the bundled BoringSSL library. I didn't look why
it works in detail but I currently assume that BoringSSL is standalone enough
that no additional
CMake toolchain settings are required to make it work.
yeah that probably is a case of bundling which is on rise at app level
these days,
One option would be to disable it with `--disable-btls` but I fear that would
disable TLS1.2 support
(http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support).
But I have no way of checking that.
interesting, do they support any other TLS implementations ?
It is disabled in 5.x builds by default as it breaks the build e.g.
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono/mono-5.4.0.201.inc
It's probably time to look at a working build with it re-enabled. Patches
welcomed...
(I did have a quick look at inheriting cmake but that breaks the build too)
I did some more testing. And adding "cmake-native" still doesn't build btls. I
guess it need cmake to figure that out. But this means it was never enabled in the first
place.
So my proposal for the moment is to explicitly set "--disable-btls" for Mono 4
too, this way it builds and it is clear that it is disabled.
If somebody figures out how to enable it again. I will send an updated Patch.
Pascal
Pascal,
For now I've put a couple of commits into master which re-enable BTLS
for 5.8.022 and 5.4.0.201. Both of these seem to build with your cmake
dependency added.
After listening to the team at #OEDEM I've been working to add basic
Image Test support to core-image-mono and to get the Yocto Auto Builder
going so I can automate some testing of the yocto release vs mono
version vs mono features matrix
That's finally coming together at which point I'm hoping to genericise a
bit more.
There are currently just three basic run time tests which previous to
the image test support I've been performing manually
ref:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/lib/oeqa/runtime/cases/mono.py
If you have suggestions/patches for an image test for TLS (or indeed any
other tests) they'll be gratefully received.
At some point I want to extend this with ptest support for running the
Mono test suite on the target { qemu / real hardware etc }
ref: http://www.mono-project.com/community/contributing/test-suite/
Cheers,
Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Reminder: Yocto Project Technical Team Meeting
YPTM will be Nov. 7, 2017 at 8am PST. We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html https://www.yoctoproject.org/tools-resources/community/weekly-technical-call Conference Details: Company: WIND RIVER SYS - dial into: 1-800-262-0778/404-397-1527 - enter the bridge number: 88748961# The international numbers are: United States Toll 404-397-1527 US & Canada Toll Free 800-262-0778 Albania dial 00810+ 8558142509 Angola dial 80811+ 8558142510 Anguilla Toll Free 18003004779 Argentina Toll +541159844583 Argentina Toll Free 08004446354 Australia Toll +610386580431 Australia Toll Free 1800347095 Austria Toll Free 080088668498 Bahamas Toll Free 18003890740 Bahrain Toll Free 80006770 Bangladesh dial 1570011+8558142505 Barbados Toll Free 18002070056 Belarus Toll Free 882000110813 Belgium Toll+3227925498 Belgium Toll Free 080029896 Belize Toll Free18000130907 Bermuda Toll free 18002072792 Botswana Toll Free 002698003004981 Brazil Toll +5501149497489 Brazil Toll Free08008919885 British Virgin Islands Toll Free18002075710 Brunei Toll Free8014373 Bulgaria Toll +359024916371 Bulgaria Toll Free 008001201170 Cambodia Toll Free 1800209578 Cambodia Toll Free 1800209361 Canada Toll +14169810101 Cayman islands Toll Free18444305771 Chile Toll +56442080836 Chile Toll Free 12300206143 China Toll Free 4000342070 China Toll Free 8008709853 China Toll Free 4008877140 China Toll Free 8008768605 Colombia Toll +5714864720 Colombia Toll Free 18000129671 Costa Rica Toll 40017415 Croatia Toll+38517776838 Croatia Toll Free 08009975 Cuba dial 2935+ 8558142540 Cyprus Toll Free80096877 Czech Republic Toll Free0800701476 Denmark Toll+4536927940 Denmark Toll Free 80251209 Dominica Toll Free 18003004904 Dominican Republic Toll Free18887514588 Ecuador Toll Free 180314 Egypt Toll Free 0809493 Estonia Toll+3726867092 Estonia Toll Free 8000100708 Finland Toll+3580923195770 Finland Toll Free 0800774585 France Toll +33272249926 France Toll Free0800947235 French Guiana Toll Free 0800910113 Germany Toll+4930700150733 Germany Toll Free 08007238960 Ghana dial 0242426004+ 8553944954 Greece Toll +302111983414 Greece Toll Free0080016122059757 Grenada Toll Free 18003004905 Guatemala dial 001190+ 8553944634 Honduras Toll Free 80027919493 Hong Kong Toll +85230507540 Hong Kong Toll Free 800961673 Hungary Toll+40017789124 Hungary Toll Free 0680015494 India Toll +914466747384 India Toll Free 18002090252 Indonesia Toll Free 0078030114912 Ireland Toll+35316539376 Ireland Toll Free 1800948436 Israel Toll +97233762260 Israel Toll Free1809458778 Italy Toll +390200617793 Italy Toll Free 0800187234 Jamaica Toll Free 18002196874 Japan Toll +810345786573 Japan Toll Free 0120525303 Jordan Toll Free080022545 Kenya Toll Free 0800723004 Latvia Toll Free8002601 Lebanon dial 01426801+ 8558142511 Lithuania Toll +37052054804 Lithuania Toll Free 880031895 Luxembourg Toll +35228264835 Luxembourg Toll Free80023986 Macedonia Toll Free 080094382 Malaysia Toll +600377248228 Malta Toll +35627781438 Malta Toll Free 80062568 Martinique Toll Free0800910664 Mauritius Toll Free 8020440157 Mexico Toll +52015515001053 Mexico Toll Free018002530547 Moldavia Toll Free 080062305 Monaco Toll Free80094215 Morocco dial 002110011+ 8558142537 Netherlands Toll+310107994621 Netherlands Toll Free 08000200244 New Zealand Toll+64042806288 New Zealand Toll Free 0800441743 Norway Toll +4721034359 Norway Toll Free80058604 Oman Toll Free 80074218 Pakistan Toll +924238108753 Panama Toll +5078323301 Panama Toll Free008002267987 Paraguay Toll Free 009800110233 Peru Toll +51017017728 Peru Toll Free 080078493 Philippines Toll+6322312145 Philippines Toll Free 180011101073 Poland Toll +480223060270 Poland Toll Free800080328 Portugal Toll +351707201563 Portugal Toll Free 800788629 Qatar Toll Free 00800100142 Romania Toll+40215291752 Romania Toll Free 0800400068 Russia Toll +74993504823 Russia Toll Free81080026895011 Saudi Arabia Toll Free 8008442574 Saudi Arabia Toll Free 8008500370 Senegal dial 800103072+ 8558842521 Serbia Toll Free0800190975 Singapore Toll +6563494173 Singapore Toll Free 18005792882 Slovakia Toll +4210268622038 Slovakia Toll Free 0800606692 Slovenia Toll +38618281644 Slovenia Toll Free 080081438 South Africa Toll
[yocto] use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain
Hi, I am working on a yocto 2.0 based distro and we usually populate_sdk and use the toolchain included in SDK. But we also like to check the SDK into a SVN repo, and checkout it anywhere, and use it away right where it is checked out. And since the nativesdk binaries are based on a different glibc than native, and have the “dynamic loader” path hardcoded in them, so I have to patch the toolchain binaries’ .interp secion to point to a common place, and update the loader into that common place automatically in some way. Other than this, things works very good for us. Then I am thinking: is it a good practice, to use the native/cross toolchain directly from the tmp/sysroots/x86_64-native folder. I tried and succeeded, by just moving the sysroot to where the populated nativesdk toolchain was. An extra bonus about this is that we got a more populated sysroot for native platform too, for example a openssl dev package at the same version as that on target, that we can actually use to make the native platform a closer-to-target dev env for some “workbench” build. However I’m still wondering: is there any thing negative about this style? One thing known is that the SDK-using host need to be similar to the SDK-building host, but that is not an issue for us. But anything else, guys? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Customize SDKPATH
Hi Jonathan,
On 2017-11-02 17:43, Jonathan Poulin wrote:
Is there a way to set IMAGE_BASENAME to the image name used in the
command "bitbake -c populate_sdk " in a way that all package
recipe see it?
We use TOOLCHAIN_OUTPUTNAME, like this:
TOOLCHAIN_OUTPUTNAME =
"${PN}-${SDK_ARCH}-${SDK_OS}-${REAL_MULTIMACH_TARGET_SYS}"
--
MARTIN HUNDEBØLL, Prevas A/S
Software Developer
Hedeager 3, DK-8200 Aarhus N
Phone +45 87438070
Mobile +45 25562438
martin.hundeb...@prevas.dk
www.prevas.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oracle-java][PATCH] Don't preserve ownership when copying files
Don't preserve ownership when copying files. Instead let root be
owner of all files.
---
recipes-devtools/oracle-java/oracle-jse-jdk.inc | 3 ++-
recipes-devtools/oracle-java/oracle-jse.inc | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk.inc
b/recipes-devtools/oracle-java/oracle-jse-jdk.inc
index a7210d9..ca6af22 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk.inc
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk.inc
@@ -13,7 +13,8 @@ require oracle-jse.inc
do_install_class-native() {
install -d ${D}${libdir_jvm}
- cp -a ${S}/${JDK_JRE}${PV}_${PV_UPDATE} ${D}${JDK_HOME}
+ cp -a --no-preserve=ownership \
+ ${S}/${JDK_JRE}${PV}_${PV_UPDATE} ${D}${JDK_HOME}
install -d ${D}${bindir}
ln -sf ${JDK_HOME}/bin/java ${D}${bindir}
diff --git a/recipes-devtools/oracle-java/oracle-jse.inc
b/recipes-devtools/oracle-java/oracle-jse.inc
index 4346f23..5e5f406 100644
--- a/recipes-devtools/oracle-java/oracle-jse.inc
+++ b/recipes-devtools/oracle-java/oracle-jse.inc
@@ -19,7 +19,8 @@ JDK_HOME = "${libdir_jvm}/${JDK_DIR}"
do_install () {
install -d -m 0755 ${D}${libdir_jvm}
- cp -a ${S}/${JDK_JRE}${PV}_${PV_UPDATE} ${D}${JDK_HOME}
+ cp -a --no-preserve=ownership \
+ ${S}/${JDK_JRE}${PV}_${PV_UPDATE} ${D}${JDK_HOME}
}
# All the files are provided in a binaray package, and keeping all the
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting
Attendees: Stephen, Joshua L., Armin, Stephano, Michael, Brian, Richard, Joshua W., Mark, Patrick, Pascal, Randy, Saul, Manju, Agenda: * Yocto Project status - 5 min (Stephen/team) * YP 2.4 (Rocko) Final was released on Thursday Oct. 26th. It provides a number of key new features including upgrades to the kernel, gcc, glibc, and many new recipes. It also includes improvements to Python 3, go support, wic, devtool, Bitbake server and significant improvements to automated QA testing, both in coverage and performance. * YP 2.5 planning is in process, please get you enhancement requests into bugzilla. * YP 2.2.3 (Morty) is planned to be built and sent to QA shortly. * Opens - 10 min * Richard - Discussed issues of intermittent failures on the AutoBuilder. See Weekly Status report for details. Removed Fedora 25 build machines since it is EOL shortly and was failing. May have a fix for the SUSE builders' intermittent failures. Master and the other branches are not frozen, but it is making merging patches quite slow. * Team Sharing - 10 min * Richard - Discussed focus for YP 2.5 but not yet finalized the themes yet. Container improvements, YP compatible V2, Layer Setup efforts, Test automation improvements, software update tools. * Richard - Discussed removing gcc 6 from YP 2.5. * Randy - Discuss limiting supported kernels to 2 per release, but some have had 3 and Pyro had 4 which produced a lot of support issues. * Richard - Discussed distributed builds, but multi-config needs to be finished and we don't have the resources to complete at this time and don't want to do an incomplete job. * Richard - Would like to add more layers to our QA testing, but not sure we have the bandwidth at this time to do it. 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
Re: [yocto] [meta-mono][PATCH] mono-4.xx: compiling mono 4 with btls requires cmake
On Tue, Nov 7, 2017 at 5:26 AM, Pascal Bach wrote: > > Mono requires cmake to build the bundled BoringSSL library. I didn't look why it works in detail but I currently assume that BoringSSL is standalone enough that no additional CMake toolchain settings are required to make it work. >>> yeah that probably is a case of bundling which is on rise at app level >>> these days, >>> One option would be to disable it with `--disable-btls` but I fear that would disable TLS1.2 support (http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support). But I have no way of checking that. >>> interesting, do they support any other TLS implementations ? >>> >> >> It is disabled in 5.x builds by default as it breaks the build e.g. >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono/mono-5.4.0.201.inc >> >> It's probably time to look at a working build with it re-enabled. Patches >> welcomed... >> >> (I did have a quick look at inheriting cmake but that breaks the build too) >> > I did some more testing. And adding "cmake-native" still doesn't build btls. > I guess it need cmake to figure that out. But this means it was never enabled > in the first place. > > So my proposal for the moment is to explicitly set "--disable-btls" for Mono > 4 too, this way it builds and it is clear that it is disabled. that seems reasonable > > If somebody figures out how to enable it again. I will send an updated Patch. > > Pascal > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain
Hi, I am working on a yocto 2.0 based distro and we usually populate_sdk and use the toolchain included in SDK. But we also like to check the SDK into a SVN repo, and checkout it anywhere, and use it away right where it is checked out. And since the nativesdk binaries are based on a different glibc than native, and have the “dynamic loader” path hardcoded in them, I have to patch the toolchain binaries’ .interp secion to point to a common place, and update the loader into that common place automatically in some way. Other than this, things work very good for us. Then I was thinking: is it a good practice, to use the native/cross toolchain directly from the tmp/sysroots/x86_64-native folder. I tried and succeeded, by just moving the sysroot to where the checked-out nativesdk toolchain was. An extra bonus about this is that we got a more populated sysroot for native platform too, for example a openssl dev package at the same version as that on target, that we can actually use to make the native platform a closer-to-target dev env for some “workbench” build. However I’m still wondering: is there any thing negative about this style? One thing known is that the SDK-using host need to be similar to the SDK-building host, but that is not an issue for us. But anything else, guys? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere
On 11/07/2017 08:46 AM, Alan Martinovic wrote:
Hi,
I'm trying to get yocto to build the kernel with an in-tree defconfig.
For that I found references to the variable KBUILD_DEFCONFIG_KMACHINE.
However, I've been experiencing that the kernel is being built with
some default defconfig, and not the in-tree one that came with the
kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.
I've looked through all yocto sources for where the
KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in my
kernel recipe. So I decided to dissect my recipe.
What is your kernel recipe ? Something you wrote, or something
from a vendor ?
There is a:
inherit kernel
in my recipe for which, besides others, defines how the kernel config
will be selected.
Looking at the sources of oe/meta/classes/kernel.bbclass exposes how
the kernel configuration happens:
kernel_do_configure() {
# fixes extra + in /lib/modules/2.6.37+
# $ scripts/setlocalversion . => +
# $ make kernelversion => 2.6.37
# $ make kernelrelease => 2.6.37+
touch ${B}/.scmversion ${S}/.scmversion
if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
"${B}/.config" ]; then
mv "${S}/.config" "${B}/.config"
fi
# Copy defconfig to .config if .config does not exist. This allows
# recipes to manage the .config themselves in do_configure_prepend().
if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi
${KERNEL_CONFIG_COMMAND}
}
I'm planning a workaround by overriding the do_configure in my recipe
to select the correct defconfig from the kernel. It does seem however
like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to do
the workarounds.
Anyone has experiences with successfully using KBUILD_DEFCONFIG_KMACHINE?
Is it a specific poky feature (I'm not using poky but specific open
embedded layers and bitbake)?
That is a feature of kernel-yocto, so if your recipe is inheriting
kernel-yocto you can use what you are looking for.
But note, in the documentation you are referencing you have to replace
KMACHINE with your actual machine .. not use the string KMACHINE.
i.e. in your recipe (or bbappend)
# for cases where the KMACHINE (KERNEL MACHINE) and bitbake
# machine match, just do this:
KMACHINE=$MACHINE
KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"
i.e. it is just a standard bitbake variable with a machine OVERRIDE
to make it specific to the machine you are building.
Bruce
Be Well,
Alan
Ref.
https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][patch v3 0/1] recipes.html: Require keyword for recipe search
For v3, updated recipes.html to use bootstrap's error state and added the browse option for Classes. The following changes since commit 78c2561181f07b1c39f1dc3516a9110a39d874f2: templates/layerindex/classes.html: Add bbclass search (2017-11-07 16:54:46 +1300) are available in the git repository at: git://git.yoctoproject.org/layerindex-web abrindle/recipe_search http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=abrindle/recipe_search Amanda Brindle (1): recipes.html: Require keyword for recipe search layerindex/views.py| 15 --- templates/layerindex/classes.html | 3 ++- templates/layerindex/distros.html | 3 ++- templates/layerindex/machines.html | 3 ++- templates/layerindex/recipes.html | 27 +-- 5 files changed, 39 insertions(+), 12 deletions(-) -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][patch v3 1/1] recipes.html: Require keyword for recipe search
Use JavaScript to check if the search box for recipe search is
empty before querying the database. This will prevent the "502
Bad Gateway" error that occurs when the query takes too long due
to the large list of recipes. Since there are so many recipes
spread across the layers in the OE index, there's no point in
allowing a user to search without a keyword in order to browse
the list; it simply isn't digestible as a whole.
Add a browse button for the Machines, Classes, and Distros pages.
Fixes [YOCTO #11930]
Signed-off-by: Amanda Brindle
---
layerindex/views.py| 15 ---
templates/layerindex/classes.html | 3 ++-
templates/layerindex/distros.html | 3 ++-
templates/layerindex/machines.html | 3 ++-
templates/layerindex/recipes.html | 27 +--
5 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/layerindex/views.py b/layerindex/views.py
index 03d47f2..414c770 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -656,7 +656,10 @@ class MachineSearchView(ListView):
def get_queryset(self):
_check_url_branch(self.kwargs)
-query_string = self.request.GET.get('q', '')
+if self.request.GET.get('search', ''):
+query_string = self.request.GET.get('q', '')
+else:
+query_string = ""
init_qs =
Machine.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
if query_string.strip():
entry_query = simplesearch.get_query(query_string, ['name',
'description'])
@@ -705,7 +708,10 @@ class DistroSearchView(ListView):
def get_queryset(self):
_check_url_branch(self.kwargs)
-query_string = self.request.GET.get('q', '')
+if self.request.GET.get('search', ''):
+query_string = self.request.GET.get('q', '')
+else:
+query_string = ""
init_qs =
Distro.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
if query_string.strip():
entry_query = simplesearch.get_query(query_string, ['name',
'description'])
@@ -730,7 +736,10 @@ class ClassSearchView(ListView):
def get_queryset(self):
_check_url_branch(self.kwargs)
-query_string = self.request.GET.get('q', '')
+if self.request.GET.get('search', ''):
+query_string = self.request.GET.get('q', '')
+else:
+query_string = ""
init_qs =
BBClass.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
if query_string.strip():
entry_query = simplesearch.get_query(query_string, ['name'])
diff --git a/templates/layerindex/classes.html
b/templates/layerindex/classes.html
index 34ac5aa..574cdb8 100644
--- a/templates/layerindex/classes.html
+++ b/templates/layerindex/classes.html
@@ -35,7 +35,8 @@
-search
+search
+browse
diff --git a/templates/layerindex/distros.html
b/templates/layerindex/distros.html
index 5b6995a..3266bf6 100644
--- a/templates/layerindex/distros.html
+++ b/templates/layerindex/distros.html
@@ -35,7 +35,8 @@
-search
+search
+browse
diff --git a/templates/layerindex/machines.html
b/templates/layerindex/machines.html
index c0c6f33..e963376 100644
--- a/templates/layerindex/machines.html
+++ b/templates/layerindex/machines.html
@@ -34,7 +34,8 @@
-search
+search
+browse
diff --git a/templates/layerindex/recipes.html
b/templates/layerindex/recipes.html
index 1322750..5ff92ab 100644
--- a/templates/layerindex/recipes.html
+++ b/templates/layerindex/recipes.html
@@ -32,14 +32,20 @@
-
-
-
-search
-
-
+
+
+
+
+
+search
+
+
+
+
+
+
{% if recipe_list %}
@@ -88,5 +94,14 @@
$('.icon-hdd').tooltip({title:"Inherits image"});
$('.label-inverse').tooltip();
});
+
+
Re: [yocto] [layerindex-web][patch v3 1/1] recipes.html: Require keyword for recipe search
On 11/7/17 4:31 PM, Amanda Brindle wrote:
> Use JavaScript to check if the search box for recipe search is
> empty before querying the database. This will prevent the "502
> Bad Gateway" error that occurs when the query takes too long due
> to the large list of recipes. Since there are so many recipes
> spread across the layers in the OE index, there's no point in
> allowing a user to search without a keyword in order to browse
> the list; it simply isn't digestible as a whole.
>
> Add a browse button for the Machines, Classes, and Distros pages.
There are reasons to view all of the recipes, machines, classes, distros, etc.
(Not necessarily good reasons, but I know people do it.)
If the query is too long, it would be better to figure out a way to get a
partial response and formulate the first page based on partial responses...
having a multipage response that the user can look at.
--Mark
> Fixes [YOCTO #11930]
>
> Signed-off-by: Amanda Brindle
> ---
> layerindex/views.py| 15 ---
> templates/layerindex/classes.html | 3 ++-
> templates/layerindex/distros.html | 3 ++-
> templates/layerindex/machines.html | 3 ++-
> templates/layerindex/recipes.html | 27 +--
> 5 files changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/layerindex/views.py b/layerindex/views.py
> index 03d47f2..414c770 100644
> --- a/layerindex/views.py
> +++ b/layerindex/views.py
> @@ -656,7 +656,10 @@ class MachineSearchView(ListView):
>
> def get_queryset(self):
> _check_url_branch(self.kwargs)
> -query_string = self.request.GET.get('q', '')
> +if self.request.GET.get('search', ''):
> +query_string = self.request.GET.get('q', '')
> +else:
> +query_string = ""
> init_qs =
> Machine.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
> if query_string.strip():
> entry_query = simplesearch.get_query(query_string, ['name',
> 'description'])
> @@ -705,7 +708,10 @@ class DistroSearchView(ListView):
>
> def get_queryset(self):
> _check_url_branch(self.kwargs)
> -query_string = self.request.GET.get('q', '')
> +if self.request.GET.get('search', ''):
> +query_string = self.request.GET.get('q', '')
> +else:
> +query_string = ""
> init_qs =
> Distro.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
> if query_string.strip():
> entry_query = simplesearch.get_query(query_string, ['name',
> 'description'])
> @@ -730,7 +736,10 @@ class ClassSearchView(ListView):
>
> def get_queryset(self):
> _check_url_branch(self.kwargs)
> -query_string = self.request.GET.get('q', '')
> +if self.request.GET.get('search', ''):
> +query_string = self.request.GET.get('q', '')
> +else:
> +query_string = ""
> init_qs =
> BBClass.objects.filter(layerbranch__branch__name=self.kwargs['branch'])
> if query_string.strip():
> entry_query = simplesearch.get_query(query_string, ['name'])
> diff --git a/templates/layerindex/classes.html
> b/templates/layerindex/classes.html
> index 34ac5aa..574cdb8 100644
> --- a/templates/layerindex/classes.html
> +++ b/templates/layerindex/classes.html
> @@ -35,7 +35,8 @@
>
>
> id="appendedInputButtons" placeholder="Search classes" name="q" value="{{
> search_keyword }}" />
> -search
> + value="1">search
> + value="1">browse
>
>
>
> diff --git a/templates/layerindex/distros.html
> b/templates/layerindex/distros.html
> index 5b6995a..3266bf6 100644
> --- a/templates/layerindex/distros.html
> +++ b/templates/layerindex/distros.html
> @@ -35,7 +35,8 @@
>
>
> id="appendedInputButtons" placeholder="Search distros" name="q" value="{{
> search_keyword }}" />
> -search
> + value="1">search
> + value="1">browse
>
>
>
> diff --git a/templates/layerindex/machines.html
> b/templates/layerindex/machines.html
> index c0c6f33..e963376 100644
> --- a/templates/layerindex/machines.html
> +++ b/templates/layerindex/machines.html
> @@ -34,7 +34,8 @@
>
>
> id="appendedInputButtons" placeholder="Search machines" name="q" value="{{
> search_keyword }}" />
> -search
> + value="1">search
> + value="1">browse
>
>
>
Re: [yocto] [layerindex-web][patch v3 1/1] recipes.html: Require keyword for recipe search
On Wednesday, 8 November 2017 11:47:49 AM NZDT Mark Hatle wrote: > On 11/7/17 4:31 PM, Amanda Brindle wrote: > > Use JavaScript to check if the search box for recipe search is > > empty before querying the database. This will prevent the "502 > > Bad Gateway" error that occurs when the query takes too long due > > to the large list of recipes. Since there are so many recipes > > spread across the layers in the OE index, there's no point in > > allowing a user to search without a keyword in order to browse > > the list; it simply isn't digestible as a whole. > > > > Add a browse button for the Machines, Classes, and Distros pages. > > There are reasons to view all of the recipes, machines, classes, distros, > etc. (Not necessarily good reasons, but I know people do it.) > > If the query is too long, it would be better to figure out a way to get a > partial response and formulate the first page based on partial responses... > having a multipage response that the user can look at. I'm willing to be proven wrong, but unfortunately it looks to me like this will require major re-engineering to sort out for a fairly weak use case. If you consider this important, would you be able to look into making it work? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
