Function "contains_lfs" was only looking at the master branch when searching
for LFS
content. LFS may be configured in specific branches only, so we need to use the
correct branch.
Signed-off-by: Mauro Queiros
---
lib/bb/fetch2/git.py | 11 +--
1 file changed, 9 insertions(+), 2
The message "Repository %s has LFS content but it is not being fetched" was
being printed, even when Git-LFS was available and "lfs=1" was set. In those
situations, we want to fetch LFS content, so that message would not make sense.
Signed-off-by: Mauro Queiros
---
lib/bb/fetch2/git.py | 2 +-
Git-LFS objects were being fetched even when lfs=0 was not set.
This patch disables LFS smudging when lfs=0. That way, only the LFS pointers
are downloaded during checkout.
Signed-off-by: Mauro Queiros
---
lib/bb/fetch2/git.py | 3 +++
1 file changed, 3 insertions(+)
diff --git
Please ignore. This was meant to bitbake-devel mailing list.
Mauro Queiros escreveu no dia sexta, 29/05/2020
à(s) 11:02:
> Function "contains_lfs" was only looking at the master branch when
> searching for LFS
> content. LFS may be configured in specific branches only, so we need to
> use the
Please ignore. This was meant to bitbake-devel mailing list.
Mauro Queiros escreveu no dia sexta, 29/05/2020
à(s) 11:02:
> Git-LFS objects were being fetched even when lfs=0 was not set.
> This patch disables LFS smudging when lfs=0. That way, only the LFS
> pointers
> are downloaded during
Please ignore. This was meant to bitbake-devel mailing list.
Mauro Queiros escreveu no dia sexta, 29/05/2020
à(s) 11:02:
> The message "Repository %s has LFS content but it is not being fetched" was
> being printed, even when Git-LFS was available and "lfs=1" was set. In
> those
> situations,
== Series Details ==
Series: "[v2] git.py: skip smudging if ..." and 2 more
Revision: 1
URL : https://patchwork.openembedded.org/series/24383/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
Perhaps directly is simplest, with a note on their origin above SRC_URI.
Alex
On Thu, 28 May 2020 at 23:12, Gregor Zatko wrote:
> On Sun, 2020-05-24 at 16:24 +0100, Richard Purdie wrote:
>
> On Sat, 2020-05-23 at 21:12 +0200, Gregor Zatko wrote:
>
> From: Gregor Zatko <
>
> gza...@zoznam.sk
>
Signed-off-by: Zang Ruochen
---
...ython3-pygobject_3.34.0.bb => python3-pygobject_3.36.1.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-pygobject_3.34.0.bb =>
python3-pygobject_3.36.1.bb} (87%)
diff --git
Signed-off-by: Zang Ruochen
---
meta/recipes-devtools/python/python-setuptools.inc | 4 ++--
.../0001-change-shebang-to-python3.patch| 13 +
...tools_45.2.0.bb => python3-setuptools_47.1.1.bb} | 0
3 files changed, 3 insertions(+), 14 deletions(-)
rename
On 5/28/20 9:57 PM, Khem Raj wrote:
On Wed, May 27, 2020 at 6:48 AM Trevor Gamblin
wrote:
Signed-off-by: Trevor Gamblin
---
meta/recipes-devtools/llvm/llvm_git.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/llvm/llvm_git.bb
On Fri, May 29, 2020 at 03:12:14PM +, vygu via lists.openembedded.org wrote:
> After some investigation on the debian buildfarm, we can see in the
> build/tmp/work/x86_64-linux/qemu-system-native/4.2.0-r0/temp/log.do_configure
> "libnfs support yes". If we comment in
>
After some investigation on the debian buildfarm, we can see in the
build/tmp/work/x86_64-linux/qemu-system-native/4.2.0-r0/temp/log.do_configure
"libnfs support yes". If we comment in poky/meta/recipes-devtools/qemu/qemu.inc
all the prepend do_configure_prepend_class-native(), we obtain
Suppose that I want to cut a meta-toolchain build against a sysroot
sourced from a different Linux distribution. (Obviously I would be
responsible for ensuring that all required package dependencies exist in
the sysroot.) In other words... like an external toolchain, but
inverted. The purpose
On Thu, May 28, 2020 at 02:41:29PM +0200, Ming Liu wrote:
> From: Ming Liu
>
> It defaults to ${PN}-initial-env, no functional changes with current
> implementation, but this allows it to be changed in individual u-boot
> recipes.
>
> If UBOOT_INITIAL_ENV is empty, then no initial env would be
qemu will not build for -Og optimization because macros
in lockable.h do not work as expected. Override DEBUG_BUILD.
Signed-off-by: Joe Slater
---
meta/recipes-devtools/qemu/qemu_4.2.0.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/qemu/qemu_4.2.0.bb
Is this change really required for UBOOT_INITIAL_ENV? I think you are merging
several patch series together?
On Thu, May 28, 2020 at 02:41:27PM +0200, Ming Liu wrote:
> From: Ming Liu
>
> U-boot recipe supports .cfg files in SRC_URI, but they would be merged
> to .config during do_configure
* This reverts commit d9971f5dc8eb7de551fd6f5e058fd24770ef5d78.
* With the missing Subject line fixed in GitApplyTree.prepareCommit()
we should be able to revert, the fix which was trying to help it by
parsing GitApplyTree.patch_line_prefix ("%% original patch:") also
from Subject line, now
* I see a case where a tarball contains .gitignore and bunch of files
which are normally ignored in git, but still included in the tarball
(e.g. configure script next to configure.ac)
* when devtool is creating a git repo in workspace it won't include these
files from tarball in the initial
Signed-off-by: Martin Jansa
---
.../devtool/devtool-test-ignored.bb | 9 ++
.../devtool-test-ignored.patch| 7 +
.../devtool-test-ignored.patch.expected | 16 +++
.../devtool-test-ignored.tar.gz | Bin 0 -> 205 bytes
* also remove the extra blank lines which is often added to patches
when refreshed with devtool (GitApplyTree.patch_line_prefix lines
are ignored when refreshing .patch files, but newly added blank
lines aren't - the leading blank line wasneeded for patches with
just the subject line (to
Signed-off-by: Martin Jansa
---
.../devtool/devtool-test-long-filename.bb | 9 ++
...nly-if-devtool-lets-me-to-do-it-corr.patch | 7 +
...vtool-lets-me-to-do-it-corr.patch.expected | 16 +++
.../devtool-test-long-filename.tar.gz | Bin 0 -> 180 bytes
* this was discovered with
$ devtool finish --force-patch-refresh
where it was removing some patches and replacing them with
patch in filename called "patch:"
e.g. this .patch file:
== Series Details ==
Series: "devtool: use -f and don't use ..." and 5 more
Revision: 1
URL : https://patchwork.openembedded.org/series/24387/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
24 matches
Mail list logo
