I think that the GitApplyTree patch implementation may not be quite
performing as expected when dealing with a non-default ${S} and patch
striplevels.
I'm not quite sure there aren't scenarios where we *do* want to honor
striplevel in GitApplyTree, even though it always appears to apply
patches
Don't pass a path removal parameter to git am/git apply since GitApplyTree
always applies patches from the root of the git repo, not from each
individual patchdir (like quilt).
GitApplyTree uses `git rev-parse --show-toplevel` to find the root of
the repo no matter which patchdir is passed into
Sorry, it has taken me a while to get back to this.
> If you changed the patch tool to git for those recipes, doesn't it fail
with this patch applied?
Even without my patch, I don't think bash works normally with PATCHTOOL =
"git" since we unpack it from a tgz. I added PATCHTOOL = "git" to the
Don't pass a path removal parameter to git am since it always applies
patches from the root of the git repo, not from each individual patchdir
(like quilt).
GitApplyTree uses `git rev-parse --show-toplevel` to find the root of
the repo no matter which patchdir is passed into the GitApplyTree
Here's an updated patch that I hope will be a little more clear. I've dropped
the change to git apply since that wasn't behaving as I expected, then added
a selftest on llvm that demonstrates the issue I'm trying to resolve. Without
the change in patch.py included here, the selftest that I'm
Don't pass a path removal parameter to git am since it always applies
patches from the root of the git repo, not from each individual patchdir
(like quilt).
GitApplyTree uses `git rev-parse --show-toplevel` to find the root of
the repo no matter which patchdir is passed into the GitApplyTree
I thought I had sent this out a month ago, but I can't find it in patchwork,
so I'm resending. This is an updated patch that addresses feedback on v1, and
should hopefully be more clear.
I've dropped the change to 'git apply' since that wasn't behaving as I
originally
thought, then I added a
On Mon, Jun 7, 2021 at 5:43 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10441
>
> This doesn't look quite right?
>
Yes, that's the one. I assumed this was what you meant by, "Another option
would be to have multiple
By having multiple uninative feeds based on host gcc version (rather than a
single uninative feed for all possible host gcc versions), we avoid a general
class of problems (as first observed in the bug below) where changes in native
gcc don't cause native sstate to regenerate. Below is another
This allows users running their own mirrors to store uninative tarballs
under versioned paths just like the default UNINATIVE_URL without having
to completely override UNINATIVE_URL in their distro configuration and
manually update the versioned URL on each upgrade.
The hashed subpath is left for
On Tue, Jun 8, 2021 at 7:16 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> > > There were specific issues with gcc 4.8 and 4.9 which required
> separate sstate. Do we
> > > know which gcc version switched the default and can we force older
> gcc's to use the
> > > same default
This allows the dynamic libgst* plugin packages and libgstrtspserver-1.0
to be used correctly in RDEPENDS.
All gstreamer1.0-plugins-* recipes and gstreamer1.0-rtsp-server include
gstreamer1.0-plugins-packaging.inc, which creates multiple libgst*
packages through split_gstreamer10_packages(), but
Otherwise, when rm_work is used, do_check may not execute before rm_work
causing do_check failures if the workdir has been removed underneath it.
Signed-off-by: Kyle Russell
---
meta/recipes-devtools/gcc/gcc-runtime.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
I see. I had forgotten that the autobuilders don't run do_check as part of
the normal build.
We have a customization in our distro layer to run do_check on normal
builds. Internally, we use that as a hook to allow per-package test suites
to fail our integration pipeline during our normal builds.
From: Steven Walter
Without this, bitbake complains that the license for cairo-gobject is
incorrect, because the license is set using ${PN}
Signed-off-by: Kyle Russell
---
meta/recipes-graphics/cairo/cairo_1.16.0.bb | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff
Is this the correct approach? Even the systemd-udev-settle.service man
pages recommends not using its service. Were the kernel modules really not
loaded when rngd started? Or is the original problem just a matter of
waiting for sufficient entropy?
On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine
Thanks, Claudius.
On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine wrote:
> Hi Kyle,
>
> On 2022-02-02 13:38, Kyle Russell wrote:
> > Is this the correct approach? Even the systemd-udev-settle.service man
> > pages recommends not using its service. Were the kernel modules really
> > not loaded
Thanks, Claudius. I really appreciate your responses. I'm not trying to
be pedantic. Since I don't have your test setup, I was just trying to make
sure I understood the context of the problem as I figure out how to deal
with issues this is causing in our setup.
I was also hoping one of the
rpmbuild can start processing random memory when processing the value
provided by XZ_THREADS, and unintentionally disable encoding for a
file descriptor that in fact requires encoding to be enabled in order
for lzwrite() to actually create an rpm.
*** Fdopen(0x7f2030002b30,w6T16.xzdio) | fdio
Ok, I see. I didn't realize I dropped that from the original line. Thanks
for the catch.
On Tue, Feb 8, 2022 at 5:30 AM Jose Quaresma
wrote:
> Hi,
>
> escreveu no dia terça, 8/02/2022 à(s) 03:50:
>
>> Ask git rev-parse to provide the path to the repo's hooks directory.
>>
>> This allows
Ask git rev-parse to provide the path to the repo's hooks directory.
This allows devtool to support git submodules, where only the
superproject contains a .git directory.
git submodules contain .git files pointing to their parent repo,
which confuses devtool when it tries to modify the commit
When applying a patch directly to a submodule, devtool doesn't need to
generate commits for updated submodule revisions, which may differ each
time a patch is applied to a devtool workspace. (submodule revision
commits would be effectively useless unless the patch is pushed to a
remote repo from
Ok, sorry about that. I can fixup and resend.
On Tue, Feb 8, 2022 at 5:09 AM Jose Quaresma
wrote:
> Hi,
>
> escreveu no dia terça, 8/02/2022 à(s) 03:42:
>
>> rpmbuild can start processing random memory when processing the value
>> provided by XZ_THREADS, and unintentionally disable encoding
rpmbuild can start processing random memory when processing the value
provided by XZ_THREADS, and unintentionally disable encoding for a
file descriptor that in fact requires encoding to be enabled in order
for lzwrite() to actually create an rpm.
*** Fdopen(0x7f2030002b30,w6T16.xzdio) | fdio
Ask git rev-parse to provide the path to the repo's hooks directory.
This allows devtool to support git submodules, where only the
superproject contains a .git directory.
git submodules contain .git files pointing to their parent repo,
which confuses devtool when it tries to modify the commit
When applying a patch directly to a submodule, devtool doesn't need to
generate commits for updated submodule revisions, which may differ each
time a patch is applied to a devtool workspace. (submodule revision
commits would be effectively useless unless the patch is pushed to a
remote repo from
Yes, we do use prelink. I think our use case primarily benefits from CoW
memory savings, rather than load times. Of course, GCCPIE can be
overridden in the distro layer, but seeing as image-prelink.bbclass still
exists upstream, the default definition should support configurations that
choose to
Since a prelinked rootfs is in conflict with PIE, don't attempt the latter
if the image enables prelink.
---
meta/conf/distro/include/security_flags.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/security_flags.inc
Avoids pulling in potential GPLv3 packages through python3-misc catch-all.
python3-core is the intended minimal RDEPENDS for packages requiring python3
support. Other python3 module dependencies should be listed explicitly.
Signed-off-by: Kyle Russell
---
29 matches
Mail list logo
