Hello Team,
I need to use High availability cluster in my project. I'm generating OS for
Rpi using Ycot. I'm using dunfell poky version 3.1.3.
I'm adding *ntp tzdata pacemaker haveged* and *crmsh* command in my
*local.conf* file, where crmsh command is giving error while doing bitbake
saying
On Fri, 2020-12-18 at 16:51 -0500, Jérôme Carretero wrote:
> On Fri, 18 Dec 2020 20:34:01 +
> "Richard Purdie" wrote:
>
> > The challenge is that Yocto Project lets you build your own custom
> > software, which means you also end up in your own BoM situation. We
> > generally therefore
On Fri, 18 Dec 2020 20:34:01 +
"Richard Purdie" wrote:
> The challenge is that Yocto Project lets you build your own custom
> software, which means you also end up in your own BoM situation. We
> generally therefore provide tooling that can help you generate the
> information you need but
Hi,
On Fri, 2020-12-18 at 15:15 -0500, Jérôme Carretero wrote:
> Please correct me if I'm wrong but as far as I understand it, as of
> today the flow for generating SPDX data to build software BoMs,
> documented eg. in:
>
> - https://www.fossology.org/get-started/basic-workflow/
> -
>
Hi,
Please correct me if I'm wrong but as far as I understand it, as of
today the flow for generating SPDX data to build software BoMs,
documented eg. in:
- https://www.fossology.org/get-started/basic-workflow/
-
On Fri 2020-12-18 @ 08:36:28 AM, Khem Raj wrote:
> this patch is generic, perhaps should live with main recipe.
Okay.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51806): https://lists.yoctoproject.org/g/yocto/message/51806
Mute This Topic:
commit 1270d1d31e1674ed7012c3b4090bedf88add898f in paulmck/linux-rcu
With global support for a CPU list alias of "all", it seems to just make
sense to also trivially extend support for an opposite "none" specifier.
Signed-off-by: Paul Gortmaker
Signed-off-by: Paul E. McKenney
---
commit 1270d1d31e1674ed7012c3b4090bedf88add898f in paulmck/linux-rcu
It seems that a common configuration is to use the 1st couple cores
for housekeeping tasks, and or driving a busy peripheral that generates
a lot of interrupts, or something similar.
This tends to leave the remaining ones to
Bruce, Yocto kernel folks,
Here are backports for an ease-of-use enhancement, aimed at people doing
multiple identical Yocto image deployments on a group of systems with
possibly varying CPU counts.
To steal from the description in the mainline/lkml posting...
The basic objective here was to
commit 1270d1d31e1674ed7012c3b4090bedf88add898f in paulmck/linux-rcu
It is probably better that we don't have subsystem specific
abbreviations or aliases for generic CPU list specifications.
Hence we move the "all" from RCU out to lib/ so that it can be
used in any instance where CPU lists are
commit 1270d1d31e1674ed7012c3b4090bedf88add898f in paulmck/linux-rcu
In order to support convenience tokens like "all", and "none" and
"last" in CPU lists, we'll have to use string operations and expand
on what is currently a simple wrapper around the underlying bitmap
function call.
Rather than
On 12/17/20 9:03 PM, Trevor Woerner wrote:
Alyssa submitted this set of patches for glmark2 to fix/clarify glmark2's
handling of fp16 overflows in a shader (which succeed if the driver doesn't
handle fp16 and uses fp32 instead).
See: https://github.com/glmark2/glmark2/pull/132
This is added
>
> Why you doesn't use multilib?
Once the framework is in place adding addtional compile flags like
--enable-multilib is relatively easy.. see
https://github.com/peteasa/meta-exotic/blob/master/exotic-gc/exotic-gcc-configure-common.inc#L14
where I actually have used multilib. In addition
13 matches
Mail list logo
